summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20160315-core-chatlog
diff options
context:
space:
mode:
authorKuninori Morimoto <kuninori.morimoto.gx@renesas.com>2019-12-23 14:27:52 +0900
committerKuninori Morimoto <kuninori.morimoto.gx@renesas.com>2019-12-23 14:27:52 +0900
commitdc71f3518c95f8d9d306e8a4e53bc9bd2e9928e3 (patch)
tree54552f6ba6cec40e16cef5c22043d9f510087e00 /wiki/Chat_log/20160315-core-chatlog
parentbb506a3f4c5441ecb212874077ad8b1bf335c936 (diff)
parent05040a728026b28ce7c6183d2adfa80218b306cb (diff)
Merge remote-tracking branch 'gitlab/wiki' into HEAD
Diffstat (limited to 'wiki/Chat_log/20160315-core-chatlog')
-rw-r--r--wiki/Chat_log/20160315-core-chatlog328
1 files changed, 328 insertions, 0 deletions
diff --git a/wiki/Chat_log/20160315-core-chatlog b/wiki/Chat_log/20160315-core-chatlog
new file mode 100644
index 0000000..70768e3
--- /dev/null
+++ b/wiki/Chat_log/20160315-core-chatlog
@@ -0,0 +1,328 @@
+Core-chat-meeting-2016-03-15
+
+2016-03-15 18:00:36 --> shimoda (~shimoda@relprex1.renesas.com) has joined #periperi
+2016-03-15 18:00:36 -- Topic for #periperi is "marzen lock holder = none / managed in-channel rather than in-topic"
+2016-03-15 18:00:36 -- Topic set by geertu on Thu, 01 Oct 2015 23:19:22
+2016-03-15 18:00:36 -- Nicks #periperi: [dammsan geertu morimoto mturquette narmstrong_ neg pinchart1 shimoda uli___]
+2016-03-15 18:00:36 -- Channel #periperi: 9 nicks (0 ops, 0 voices, 9 normals)
+2016-03-15 18:00:39 -- Mode #periperi [+cnt]
+2016-03-15 18:00:39 -- Channel created on Wed, 08 Jul 2015 19:41:24
+2016-03-15 18:02:11 geertu Welcome to the Core Group Chat
+2016-03-15 18:03:06 geertu Let's answer Magnus' question first
+2016-03-15 18:03:09 geertu Magnus: What is current state and next step of the IPMMU + SYS-DMAC framework bits?
+2016-03-15 18:03:31 geertu Vinod merged the patch to use phys_addr_t instead of dma_addr_t
+2016-03-15 18:03:41 geertu So everything's on track again
+2016-03-15 18:03:47 geertu No need to escalate
+2016-03-15 18:04:04 neg sort of
+2016-03-15 18:04:06 geertu dammsan: Does that answer your question?
+2016-03-15 18:04:32 dammsan geertu: sort of, but i got the impression that more framework changes are needed...
+2016-03-15 18:04:51 dammsan thanks for helping out to get that piece of the puzzle worked out though
+2016-03-15 18:05:46 dammsan i think a first nice goal could be to get IPMMU + SYS-DMAC working on R-Car Gen2
+2016-03-15 18:06:16 dammsan i'd love to kill off my dirty workaround patch =)
+2016-03-15 18:06:41 neg Now the isse have hit its next roadblock where the idea seems to be something new/else is needed then the dmamapping api since the assumtion there is that it's backed by a physical page
+2016-03-15 18:09:25 neg I'm talking with Christoph Hellwig but have yet to figure out a good way forward
+2016-03-15 18:11:00 dammsan thanks
+2016-03-15 18:12:31 --> horms (~horms@penelope-musen.kanocho.kobe.vergenet.net) has joined #periperi
+2016-03-15 18:12:39 <-- horms (~horms@penelope-musen.kanocho.kobe.vergenet.net) has left #periperi
+2016-03-15 18:12:39 neg I was hoping pinchart1 would review the series to put some weight behind it. He prommised he look at it last core meeting
+2016-03-15 18:13:05 --> horms (~horms@penelope-musen.kanocho.kobe.vergenet.net) has joined #periperi
+2016-03-15 18:13:10 geertu Welcome Simon
+2016-03-15 18:13:17 horms sorry to be late (again!)
+2016-03-15 18:13:57 horms The Gen2 documentation is too exciting for me to take my eyes off it!
+2016-03-15 18:14:17 dammsan neg: so the case w/o IPMMU, we currently assume we do not need to map anything?
+2016-03-15 18:14:58 dammsan i'm trying to understand what is so special about our situation =)
+2016-03-15 18:15:34 geertu Yeah, the x86 and PPC guys have used IOMMUs for ages
+2016-03-15 18:15:40 neg yes w/o a IPMMU the dma_addr_t is the same as phys_addr_t
+2016-03-15 18:15:51 geertu x86 IO is always special, but PPC should be similar
+2016-03-15 18:17:08 dammsan so we need to use the DMA API for this i guess
+2016-03-15 18:17:23 dammsan and no one else is doing that in a similar way i wonder?
+2016-03-15 18:17:47 dammsan stuck between DMA Engine and DMA API =)
+2016-03-15 18:19:53 dammsan so pinchartl is not attending?
+2016-03-15 18:20:03 geertu No, he's without network access today
+2016-03-15 18:20:13 horms i believe he is at linaro connect
+2016-03-15 18:20:24 geertu LC was last week, IIRC
+2016-03-15 18:20:28 horms ok
+2016-03-15 18:20:34 dammsan meh
+2016-03-15 18:20:42 horms in that case hopefully is is not at lc (any more!)
+2016-03-15 18:21:27 dammsan ok i guess we are blocked on him
+2016-03-15 18:21:49 dammsan shall we move to next?
+2016-03-15 18:21:51 neg not that I know of and there have been patches from Robin Murphy where he talk about toying with the same solution see http://article.gmane.org/gmane.linux.kernel.renesas-soc/404
+2016-03-15 18:22:44 geertu Topic 1. Upcoming Gen3 development for the Core group
+2016-03-15 18:24:02 geertu I posted a v3 of the PM Domain patch series last week, switching from a DT hierarchy to a C hierarchy again
+2016-03-15 18:24:08 geertu s/again//
+2016-03-15 18:24:11 geertu ;-)
+2016-03-15 18:24:16 dammsan hehe
+2016-03-15 18:24:35 horms shimoda-san: I'm wondering about PWM. Is it on your-list, done, or should I be looking at it?
+2016-03-15 18:24:38 geertu There are some details to resolve w.r.t. SH4 power areas
+2016-03-15 18:25:02 geertu After that I'll repost a v4.
+2016-03-15 18:25:13 horms :)
+2016-03-15 18:25:38 horms geertu: are you waiting on me for anything (e.g. to queue up any of your patches that are ready)?
+2016-03-15 18:25:42 geertu I have a few more cleanups in the pipeline for SoC-specific PM code under arch/arm/mach-shmobile/, those depend on DT PM Domains
+2016-03-15 18:25:47 geertu horms: Not yet
+2016-03-15 18:26:05 horms ok
+2016-03-15 18:26:23 geertu The code is in today's renesas-drivers, so it can be used by VSP users
+2016-03-15 18:26:48 geertu (and it was in an integration topic branch last week)
+2016-03-15 18:27:16 dammsan geertu: with the power domains, how do you work together with PSCI?
+2016-03-15 18:27:40 dammsan just assume the firmware are handling the cpu power domains?
+2016-03-15 18:27:52 geertu dammsan: The CPU power areas cannot be controlled from SYC for Gen2 and Gen3
+2016-03-15 18:28:02 geertu That's done through APMU.
+2016-03-15 18:28:08 geertu On Gen2 the C code does that
+2016-03-15 18:28:15 geertu On Gen3 PSCI does that
+2016-03-15 18:28:43 geertu However, the SYSC status bits don't indicate that the CPU power areas are powered down after CPU hot-unplug on Gen3
+2016-03-15 18:29:03 horms Is that a bug or a feature?
+2016-03-15 18:29:06 shimoda simon-san: sorry for the delayed response. about PWM integration for r8a7795, it seems ulrich-san sent upporting patches to the ML
+2016-03-15 18:29:11 geertu Replugging the CPU doesn't work on Salvator-X, perhaps related to the above.
+2016-03-15 18:29:42 horms shimoda-san: thanks, got it. I suppose we need to prod him a bit.
+2016-03-15 18:30:09 dammsan geertu: how about the snoop controller, i guess on gen2 it needs manual setup
+2016-03-15 18:30:17 geertu The link with controlling the Linux-view on the CPU PM Domains is not there. Lina Iyer is working on generic CPU PM Domain stuff
+2016-03-15 18:30:18 horms geert: ok, so this is related to a thread with morimoto-san on the periperi ML?
+2016-03-15 18:30:50 geertu dammsan: You mean the SCU power area?
+2016-03-15 18:30:55 dammsan yeah
+2016-03-15 18:31:07 dammsan psci is assumed to be in control i guess
+2016-03-15 18:31:15 geertu dammsan: It's already running when booting Linux
+2016-03-15 18:31:36 geertu and we never power down the first CPU core.
+2016-03-15 18:31:51 dammsan good. on gen2 it depended on boot loader version and if it the cores were booted in big or little mode
+2016-03-15 18:31:52 geertu H2 also doesn't have big.LITTLE enabled.
+2016-03-15 18:32:13 geertu There are no changes to CPU bring-up introduced by my series.
+2016-03-15 18:32:30 dammsan you csure, just curious about the assumptions
+2016-03-15 18:32:31 geertu The later cleanups have, and I have it running locally with your old APMU DT series.
+2016-03-15 18:32:40 dammsan ouch =)
+2016-03-15 18:33:07 geertu horms: Yes, discussing SH4 on various SoCs with Morimoto-san
+2016-03-15 18:33:48 dammsan so who is handling the non-working SMP CPU Hotplug bits?
+2016-03-15 18:34:07 geertu I sent an email to periperi about it last week.
+2016-03-15 18:34:08 dammsan hate to ask =)
+2016-03-15 18:34:23 geertu Secondary core bringup works once
+2016-03-15 18:34:37 geertu So after boot you have 4 x CA57
+2016-03-15 18:34:51 geertu If you power down a Ca57, you loose it forever (until next reboot)
+2016-03-15 18:35:17 geertu It seems India has a newer firmware?
+2016-03-15 18:35:28 dammsan of course it is up to you guys how you want to roll
+2016-03-15 18:35:29 geertu No idea if that helps. Firmware is black box to us ;-)
+2016-03-15 18:35:40 dammsan i would not merge any code unless it is working myself
+2016-03-15 18:36:07 horms is the code in question merged or not?
+2016-03-15 18:36:10 geertu There is no new non-working SMP code added.
+2016-03-15 18:36:38 dammsan is SMP including or excluding CPU Hotplug in your view? =)
+2016-03-15 18:36:51 dammsan it my mind CPU Hotplug is the only sane test bed for SMP =)
+2016-03-15 18:37:00 geertu Then it is broken.
+2016-03-15 18:37:03 dammsan otherwise how would you test power down?
+2016-03-15 18:37:13 dammsan ok
+2016-03-15 18:37:17 geertu It broke when adding the secondary CPU cores to DT, with enable-method = "psci"
+2016-03-15 18:37:19 dammsan so how can we fix this?
+2016-03-15 18:37:29 geertu Fix PSCI?
+2016-03-15 18:37:30 dammsan yes i assumed so
+2016-03-15 18:37:42 dammsan well, we need to fix it somehow
+2016-03-15 18:37:54 dammsan the rest of the organization is busy flippin burgers
+2016-03-15 18:37:55 geertu Who's developing PSCI?
+2016-03-15 18:38:18 dammsan i don't know to be sure
+2016-03-15 18:38:21 horms we can remove the dt nodes pending a working psci implementation
+2016-03-15 18:38:28 dammsan but i would check before i merged it if i had the chance
+2016-03-15 18:38:39 dammsan that would be my preferred way forward
+2016-03-15 18:38:44 dammsan not sure what you guys are thinking
+2016-03-15 18:39:02 geertu Well, adding the CPU nodes to DT did allow to use them after booting.
+2016-03-15 18:39:03 shimoda geertu: bootloader team develops the psci (arm-trasted-firmware) for gen3
+2016-03-15 18:39:35 dammsan geertu: then we have same support level as emev2 =)
+2016-03-15 18:39:36 shimoda it is a problem that i also don't know the detail of the psci firmware versioning
+2016-03-15 18:40:00 dammsan i propose that we don't enable upstream until we have something working
+2016-03-15 18:40:12 dammsan and put pressure on local people based on that
+2016-03-15 18:40:26 geertu In this case, the "something" was 4 running CPU cores.
+2016-03-15 18:40:27 dammsan i'm open to other suggestions though
+2016-03-15 18:40:37 shimoda i heard end of this month, a new version of the firmware released on the git hub
+2016-03-15 18:40:43 shimoda public git hub
+2016-03-15 18:40:44 geertu Actually we had 8 running, but it broke by upgrading firmware.
+2016-03-15 18:40:47 horms can i clarify if we are talking about 1) code that is already merged 2) code that posted but not merged or 3) code that is neither posted nor merged?
+2016-03-15 18:41:00 geertu 1 = 4 x CA57
+2016-03-15 18:41:05 geertu 2 = 8 x CA57
+2016-03-15 18:41:10 geertu 3 = PSCI ;-)
+2016-03-15 18:41:25 geertu s/8x CA57/4 x CA57 + 4 x CA53/
+2016-03-15 18:41:54 dammsan you can see that the release procedure of binaries is working well
+2016-03-15 18:42:04 dammsan at least we can generate some entropy
+2016-03-15 18:42:14 dammsan =)
+2016-03-15 18:42:21 dammsan so what shall we do?
+2016-03-15 18:43:36 geertu In the kernel, we revert something if it causes regressions.
+2016-03-15 18:43:54 shimoda I heard the current psci blocks CA53, however if we changes the boot mode we can use 8 core as the cpu0 as CA53 :)
+2016-03-15 18:43:58 dammsan this did not cause a regression really, but CPU hotplug did not work
+2016-03-15 18:43:59 geertu With firmware, it's more complicated
+2016-03-15 18:44:39 dammsan i think on 32-bit arm it became possible to block cpu hotplug at some point i think
+2016-03-15 18:44:47 horms does it cause a regression in the sense that reset no longer works?
+2016-03-15 18:44:51 geertu dammsan: Actually I do not know if CPU hotplug worked with the previous firmware. I never tried unplug/replug
+2016-03-15 18:45:06 dammsan same here
+2016-03-15 18:45:19 dammsan but previous firmware version does not matter really
+2016-03-15 18:45:24 dammsan it is too early to care
+2016-03-15 18:45:27 dammsan imo
+2016-03-15 18:45:29 geertu Reset doesn't work. We don't have reboot support.
+2016-03-15 18:45:56 dammsan but ordering wise, getting SMP and CPU hotplug working before system reset is one option
+2016-03-15 18:46:05 dammsan we can also change things around
+2016-03-15 18:46:29 dammsan i like that we test stuff before we merge though
+2016-03-15 18:47:00 horms ok, so perhaps its not a regression. but with the current firmware - which is all we support - SMP does not function as required because hotplug is broken. Correct?
+2016-03-15 18:47:23 geertu Correct.
+2016-03-15 18:47:33 horms If so it was an error (by me) to add the extra CPU nodes to DT. And I think we should revert the change until we have a good solution.
+2016-03-15 18:47:43 geertu dammsan: It was tested by checking if we have 4 CPU cores running after bootup.
+2016-03-15 18:48:03 dammsan right. next time please check with me that have been doing this for a while =)
+2016-03-15 18:48:16 horms The main down side is that Dirk @ Bosch will not be happy. But the code is still around if he wants to use it locally.
+2016-03-15 18:49:04 dammsan but he cant be the main motivator for us moving forward, can he?
+2016-03-15 18:49:29 dammsan must be more important to feed back issues to renesas and get them to fix the PSCI firmware
+2016-03-15 18:49:49 dammsan ideally satisfy both
+2016-03-15 18:49:52 geertu What has the biggest use case: habing 4 CPU cores running? Or being able to unplug and replug CPU cores after boot up?
+2016-03-15 18:50:00 horms He posted the patch. It was reviewed and accepted. Subsequently an issue came up. I think we should move on.
+2016-03-15 18:50:20 geertu Indeed.
+2016-03-15 18:51:27 dammsan i guess it depends on what our role is
+2016-03-15 18:51:40 dammsan just being integrator and push issues different ways
+2016-03-15 18:51:56 dammsan or try to tackle technical issues a bit more
+2016-03-15 18:52:04 dammsan i prefer to focus on the technical bits
+2016-03-15 18:52:10 dammsan but sure, lets move on
+2016-03-15 18:52:54 horms sure, we could have done a better job on this one.
+2016-03-15 18:53:41 dammsan no biggie, lets just fix it
+2016-03-15 18:53:49 horms agreed
+2016-03-15 18:55:08 dammsan shimoda: morimoto: can we report to renesas about PSCI failure somehow?
+2016-03-15 18:55:26 dammsan and then we need to push hard
+2016-03-15 18:55:38 shimoda dammsan: sure, i will ask bsp team or/and bootloader team about it
+2016-03-15 18:55:38 dammsan we hinted a couple of times already
+2016-03-15 18:55:44 dammsan thanks!
+2016-03-15 18:56:21 dammsan imagine hypervisors and virtualization on top of this swiss cheese =)
+2016-03-15 18:56:32 dammsan so it is good to push a bit more
+2016-03-15 18:57:10 dammsan geertu: can you include boot loader version in the commit log for the power domain bits?
+2016-03-15 18:57:27 geertu dammsan: Sure
+2016-03-15 18:57:29 dammsan (you may have already)
+2016-03-15 18:57:30 geertu v230
+2016-03-15 18:57:30 dammsan thanks
+2016-03-15 18:57:49 dammsan excellent
+2016-03-15 18:59:02 dammsan horms: is it possible to get information from the bosch guy about his environment and if cpu hotplug is working for him?
+2016-03-15 18:59:30 dammsan or maybe that is too detailed
+2016-03-15 19:00:07 dammsan horms: sorry for being slow, but what was the plan forward with the SMP and CPU Hotplug? Revert or wait for new firmware version?
+2016-03-15 19:00:29 dammsan im ok with anything
+2016-03-15 19:00:36 dammsan we just need to make sure it becomes better
+2016-03-15 19:00:57 horms dammsan: sure, i will try and get that information from Dirk
+2016-03-15 19:01:09 geertu Making it better implies not reverting basic SMP support...
+2016-03-15 19:01:12 horms my plan, which I am happy to change is as follows:
+2016-03-15 19:01:22 dammsan geertu: that is fine with me
+2016-03-15 19:01:26 dammsan as long as we can fix it
+2016-03-15 19:01:32 dammsan _somehow_
+2016-03-15 19:01:34 horms 1. post patch to revert the patch that added the extra cpu nodes to dt.
+2016-03-15 19:01:51 horms 2. queue it up for v4.6 and possibly v4.5-stable after suitable discussion on the ML
+2016-03-15 19:02:17 horms 3. discuss internally how a working psci implementation can be achieved
+2016-03-15 19:02:34 dammsan seems like a lot of work to me
+2016-03-15 19:02:53 horms how so?
+2016-03-15 19:03:06 geertu What about skipping steps 1 and 2?
+2016-03-15 19:03:13 dammsan like geert said, it does not really help anything for people just booting
+2016-03-15 19:03:39 horms personally i am comfortable with skipping 1 and 2
+2016-03-15 19:04:13 dammsan i dont think 1 and 2 helps us much at this point
+2016-03-15 19:04:32 dammsan but i think despite that we need to agree about a plan how to improve things
+2016-03-15 19:05:06 dammsan can we get some jinso members to test for us?
+2016-03-15 19:05:58 horms fwiw i just tested it on my board
+2016-03-15 19:06:09 horms which i suppose has the same fw revision as geert
+2016-03-15 19:06:20 horms we can ask dirk if he has seen hotplug working
+2016-03-15 19:06:30 horms and if we are lucky he may have a firmware version that works
+2016-03-15 19:06:47 dammsan we can perhaps use dirk to put customer pressure at renesas =)
+2016-03-15 19:06:53 horms which is information that might help the firmware developers to make it work in a future version
+2016-03-15 19:06:58 horms right
+2016-03-15 19:07:02 horms its clearly important to dirk
+2016-03-15 19:07:17 horms and dirk's employer is important to renesas (I imagine)
+2016-03-15 19:07:18 shimoda dammsan: of cause we can get some jinso members to test
+2016-03-15 19:07:19 geertu Given he added the CA53 nodes too, he's probably still using the older firmware
+2016-03-15 19:07:36 dammsan shimoda: it may be good to make a test case that can be reused on new SoCs
+2016-03-15 19:08:20 horms fwiw, this is my test case so far:
+2016-03-15 19:08:36 horms # echo 0 > /sys/bus/cpu/devices/cpu1/online
+2016-03-15 19:08:37 horms [ 42.358400] CPU1: shutdown
+2016-03-15 19:08:37 horms [ 42.359758] psci: CPU1 killed.
+2016-03-15 19:08:37 horms # cat /sys/bus/cpu/devices/cpu1/online
+2016-03-15 19:08:37 horms 0
+2016-03-15 19:08:37 horms # echo 1 > /sys/bus/cpu/devices/cpu1/online
+2016-03-15 19:08:39 horms [ 47.870239] CPU1: failed to come online
+2016-03-15 19:08:41 horms -bash: echo: write error: Input/output error
+2016-03-15 19:08:48 geertu Yep, that's it
+2016-03-15 19:09:09 dammsan i used to run these in a tight loop to test some older platforms
+2016-03-15 19:09:16 geertu Note that renesas-bsp/v4.2/rcar-3.0.x:arch/arm64/boot/dts/renesas/r8a7795.dtsi also has 8 CPU cores, with enable-method = "psci"
+2016-03-15 19:09:44 dammsan "tick-box: SMP working"
+2016-03-15 19:09:45 shimoda horms: thank you for the detail, i will ask bsp team or someone
+2016-03-15 19:10:21 horms ok, so far we seem to have:
+2016-03-15 19:10:26 horms * collect information from Dirk
+2016-03-15 19:10:27 geertu FWIW, the same sequence was in my email "CPU hotplug on Salvator-X"
+2016-03-15 19:10:33 horms * Get Jinso to test (their board?)
+2016-03-15 19:10:45 horms * Talk with Renesas about how important this is
+2016-03-15 19:11:49 shimoda geertu: oops, i missed your email...
+2016-03-15 19:12:42 dammsan geertu: thanks for pushing
+2016-03-15 19:12:53 dammsan horms: sounds good to me
+2016-03-15 19:13:49 horms Ok, i can talk to Dirk unless someone else wishes to. Perhaps Shimoda-san could take the other two items for now?
+2016-03-15 19:14:44 shimoda horms: yes, i will ask jinso and bsp team about 2 items
+2016-03-15 19:15:01 horms excellent
+2016-03-15 19:15:28 horms feel free to pass the Jinso guys on to me if you feel the need
+2016-03-15 19:17:43 shimoda horms: thanks
+2016-03-15 19:19:04 geertu Any other core things people are working on?
+2016-03-15 19:19:23 dammsan Trying to get the CMT DT bits over the edge
+2016-03-15 19:19:39 dammsan but thats about it
+2016-03-15 19:19:59 horms I have made a little progress on the dmac/bus mastering/32-bit+ support analysis as requested by Magnus in Lueven
+2016-03-15 19:20:30 horms Hopefully it will be complete enough to circulate something soon
+2016-03-15 19:20:57 dammsan thanks
+2016-03-15 19:21:00 neg going to post v2 of dmas pointing to all SYS-DMAC engines after this meeting
+2016-03-15 19:21:19 horms in a nutshell so far things seem very similar in gen3 to that of gen2
+2016-03-15 19:21:19 neg geertu: is it OK for me to add your Ack to the DT patch for i2c[6-8] on r8a7793 in this series? This patch was needed after rebasing on top of renesas-devel-20160315-v4.5 as you stated it would.
+2016-03-15 19:21:58 geertu neg: if the patch is correct, yes ;-)
+2016-03-15 19:22:26 geertu neg: Just email me the new hunk, and I'll have a look
+2016-03-15 19:22:51 neg ok
+2016-03-15 19:24:28 dammsan geertu: i'm also poking around with the gen3 ipmmu
+2016-03-15 19:24:30 geertu dammsan: BTW, I wanted to include your v2 of ipmmu-multi-arch in today;s renesas-drivers, but r8a7795-ipmmu-rfc no longer applies
+2016-03-15 19:24:45 dammsan geertu: thanks, yeah i know
+2016-03-15 19:24:56 dammsan i will make a new version of the r8a7795 patches
+2016-03-15 19:25:22 geertu dammsan: the CMT series didn't include the driver changes?
+2016-03-15 19:25:24 dammsan you gave me some feedback about bitfields and features, anything you feel strongly about?
+2016-03-15 19:25:32 dammsan geertu: that is correct
+2016-03-15 19:25:39 geertu dammsan: I think that was Laurent.
+2016-03-15 19:25:42 dammsan thought we would agree on DT bindigns first
+2016-03-15 19:25:54 geertu dammsan: you can also use a plain int or long. and ffs() and ffz()
+2016-03-15 19:26:39 geertu dammsan: OK, but you remove properties. Shouldn't that be done afer the driver supports the new stuff?
+2016-03-15 19:26:41 dammsan geertu: unless laurent is using your email address it was you =)
+2016-03-15 19:27:02 dammsan geertu: let me check
+2016-03-15 19:28:02 dammsan geertu: i believe i only remove stuff that is unused
+2016-03-15 19:28:21 geertu ok
+2016-03-15 19:28:26 dammsan regarding the compat strings at least
+2016-03-15 19:28:53 geertu Anyway, I'm still running with your previous version of the CMT series, so consider it tested
+2016-03-15 19:30:07 geertu Topic 2. Status check for tasks from last meeting - what is remaining?
+2016-03-15 19:30:27 dammsan geertu: thanks
+2016-03-15 19:31:23 dammsan eventually i need to get to r8a7795 CMT
+2016-03-15 19:31:46 dammsan not sure about other people
+2016-03-15 19:32:42 geertu Any plan about SMP,v4.6,public,magnus,Discuss SMP DT bindings with ARM SoC maintainers
+2016-03-15 19:33:04 dammsan not so much i'm afraid
+2016-03-15 19:33:48 dammsan perhaps that is not a battle i can win
+2016-03-15 19:34:35 shimoda no progress about "Investigate SYS-DMAC2" of my task, i'm afraid
+2016-03-15 19:35:04 horms dammsan: in that case perhaps we should consider a fall back position?
+2016-03-15 19:36:26 dammsan horms: sure
+2016-03-15 19:37:01 geertu enable-method = "renesas,apmu" is working fine here (and on remote Lager)
+2016-03-15 19:37:42 dammsan it is not so much a techincal problem, more that DT is used to describe software (PSCI) and overly verbose when not needed
+2016-03-15 19:38:23 geertu That happens when you put critical functionality in firmware
+2016-03-15 19:38:28 dammsan and we need to keep our existing support for some time instead of breaking DT ABI with non-enable method
+2016-03-15 19:38:53 geertu Actually I have an idea to handle backwards-compatbility there.
+2016-03-15 19:39:16 dammsan good, why dont you implement it?
+2016-03-15 19:39:24 geertu All we have to do is match on r8a779x, add apmu device nodes, and enable-method properties, right?
+2016-03-15 19:39:34 geertu dammsan: Time time time...
+2016-03-15 19:39:46 dammsan yeah i know
+2016-03-15 19:39:48 geertu it's on my list...
+2016-03-15 19:40:03 dammsan in my mind we dont need the enable-method at all
+2016-03-15 19:40:13 dammsan since we can use the apmu nodes by themselves
+2016-03-15 19:40:29 geertu True.
+2016-03-15 19:40:29 dammsan but that seems to the the "standard way" to do things
+2016-03-15 19:40:35 geertu But the PSCI fans don't have PSCI nodes
+2016-03-15 19:40:38 dammsan and thats what i wanted to discuss
+2016-03-15 19:40:42 dammsan right
+2016-03-15 19:40:50 geertu I'm afraid it's already too late for that
+2016-03-15 19:41:02 dammsan regarding PSCI for sure
+2016-03-15 19:41:15 dammsan but i wonder how it helps us to change the DT ABI?
+2016-03-15 19:41:25 dammsan seems like no big win with the enable method
+2016-03-15 19:41:31 dammsan i can see the point of the APMU bits
+2016-03-15 19:42:12 dammsan anyway, it is possible to do something
+2016-03-15 19:42:18 dammsan but feels like rather low priority IMO
+2016-03-15 19:42:33 dammsan it is along there with the JTAG SMP support =)
+2016-03-15 19:42:56 geertu That has a real use case ;-)
+2016-03-15 19:43:02 dammsan also question is how to handle APMU on Gen3
+2016-03-15 19:43:05 dammsan the hardware is there
+2016-03-15 19:43:14 dammsan just not accessible perhaps
+2016-03-15 19:44:10 geertu Hidden behind the PSCI curtain
+2016-03-15 19:44:28 dammsan it is supposed to be hidden at least =)
+2016-03-15 19:45:00 dammsan ParaSiteComputerInterface
+2016-03-15 19:45:20 geertu Anything else to discuss (without a beer/wine/cocktail)?
+2016-03-15 19:45:32 dammsan not from me
+2016-03-15 19:46:56 shimoda not from me
+2016-03-15 19:47:13 geertu ok
+2016-03-15 19:47:17 geertu thx for joining!
+2016-03-15 19:47:19 geertu bye!
+2016-03-15 19:47:24 neg thanks bye
+2016-03-15 19:47:34 shimoda thanks! bye!
+2016-03-15 19:47:45 dammsan thanks