From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20160315-core-chatlog | 328 ++++++++++++++++++++++++++++++++++++ 1 file changed, 328 insertions(+) create mode 100644 wiki/Chat_log/20160315-core-chatlog (limited to 'wiki/Chat_log/20160315-core-chatlog') 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 -- cgit v1.2.3