Merge remote-tracking branch 'gitlab/wiki' into HEAD

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