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

1 files changed, 562 insertions, 0 deletions

diff --git a/wiki/Chat_log/20150805-core-chatlog b/wiki/Chat_log/20150805-core-chatlog
new file mode 100644
index 0000000..7a06f48
--- /dev/null
+++ b/wiki/Chat_log/20150805-core-chatlog
@@ -0,0 +1,562 @@
+11:00 #periperi: < geertu> Agenda: 1. CPG/MSTP Domain 2. Consider enabling CMA as default in the shmobile_defconfig 3. Topic versioning
+11:00 #periperi: < geertu>   4. Status check for tasks from last meeting - what is remaining?
+11:01 #periperi: < geertu>   5. Upcoming Gen3 development for the Core group
+11:01 #periperi: < geertu>   6. SoC Bus topology in DT
+11:01 #periperi: < geertu> Topic 1. CPG/MSTP Domain
+11:02 #periperi: < geertu> It seems this has been resolved by using the arm-soc deadline hammer?
+11:02 #periperi: < horms> maybe!
+11:02 #periperi: < dammsan> geertu: does this affect gen3?
+11:03 #periperi: < geertu> Not yet, but I think gen3 should follow suit
+11:03 #periperi: < horms> geertu: let me know if you want me to give the stauts of the patches queued up
+11:03 #periperi: < dammsan> ok
+11:04 #periperi: < geertu> horms: good idea. I don't think everyone follows your branches that closely.
+11:05 #periperi: < horms> sure
+11:05 #periperi: < horms> I have euqued up the base clk driver changes and the dtsi changes that go on top of them for v4.3
+11:05 #periperi: < horms> these are on top of the dt branch, as they change nodes added there
+11:06 #periperi: < horms> wihch is not ideal because generally its not good to add stuff on the dt branch
+11:06 #periperi: < horms> but we will see how it goes
+11:06 #periperi: < geertu> Hence all new nodes with mstp clocks should have power-domains properties
+11:06 #periperi: < horms> the next few patches touch sh-drivers and i have queued them up to send directly to linux
+11:06 #periperi: < horms> the next few patches touch sh-drivers and i have queued them up to send directly to linus
+11:07 #periperi: < horms> after the clk driver and abovementioned dt changes hit his tree
+11:07 #periperi: < horms> that should be around v4.2-rc2
+11:07 #periperi: < horms> and so all the above shold make it into v4.3 (or be rejected!)
+11:07 #periperi: < horms> then there are a few trailing cleanup patches which i have queued up for v4.4.
+11:08 #periperi: < horms> Basically the patches for v4.3 should be in the next branch and the ones for v4.4 should be in the devel branch
+11:08 #periperi: < horms> though thinking about it I might have only added the sh-driver patches to devel, i'll check that later
+11:08 #periperi: < horms> --- end ---
+11:09 #periperi: < geertu> No, everything seems to be in renesas-devel-20150805-v4.2-rc5
+11:10 #periperi: < geertu> git cherry -v base renesas-devel-20150805-v4.2-rc5 linus/master
+11:10 #periperi: < horms> ok, but some should also be in renesas-next-20150805-v4.2-rc1
+11:10 #periperi: < geertu> (with base being my base, i.e. renesas-drivers)
+11:10 #periperi: < horms> i wasn't as clear as i might have been
+11:10 #periperi: < horms> everything should be in renesas-devel
+11:11 #periperi: < horms> and the bits for v4.3 should also be in renesas-next
+11:11 #periperi: < geertu> (this show all new commits in renesas-devel-20150805-v4.2-rc5 since base, ignoring things already in upstream = linus/master)
+11:12 #periperi: < horms> i checked, the sh-driver bits are in renesas-next-20150805-v4.2-rc1
+11:12 #periperi: < horms> I plan to send my pull requests on Friday
+11:12 #periperi: < geertu> yes, everything looks fine. thx
+11:13 #periperi: < horms> we can then see what Olof has to say
+11:13 #periperi: < geertu> BTW, as Linus said something about needing an extra -rc, arm-soc may relax, too
+11:13 #periperi: < horms> ok
+11:13 #periperi: < horms> i think they usually allow a respin
+11:13 #periperi: < horms> but we'll see
+11:14 #periperi: < horms> but good to know there will be an extra rc
+11:14 #periperi: < horms> should i be expecing any more work in this area in the near term (e.g. for v4.4) ?
+11:15 #periperi: < geertu> Not for CPG/MSTP clock domain (except for H3)
+11:15 #periperi: < horms> ok, great
+11:15 #periperi: < geertu> Next PM Domain will be R-Car SYSC
+11:15 #periperi: < geertu> and we'll see what Lina is doing with CPU PM Domains
+11:16 #periperi: < geertu> BTW, did anyone test this on Gen1 or RZ?
+11:16 #periperi: < horms> i tested that the boards still boot to a userspace prompt
+11:16 #periperi: < geertu> OK, thx
+11:16 #periperi: < horms> i can do more detailed testing if needed
+11:17 #periperi: < geertu> Should be Good Enough (TM)
+11:17 #periperi: < dammsan> geertu: did not do any testing myself, but can give you remote access to marzen
+11:18 -!- Irssi: Starting query in freenode with dammsan
+11:18 <geertu> That could be useful for L2 DT cache
+11:18 #periperi: < horms> excellent
+11:18 #periperi: < geertu> Next topic?
+11:18 #periperi: < horms> fine by me
+11:18 #periperi: < geertu> Topic 2. Consider enabling CMA as default in the shmobile_defconfig
+11:19 #periperi: < horms> What is the motivation for this?
+11:19 #periperi: < geertu> dammsan? IOMMU with highmem?
+11:20 #periperi: < dammsan> right, CMA
+11:20 #periperi: < dammsan> the motivation is to do the first step to get turnkey support for HDMI
+11:20 #periperi: < dammsan> in the defconfig
+11:20 #periperi: < horms> sounds like a good reason
+11:21 #periperi: < dammsan> today there are various bits missing, including DU and HDMI specific bits
+11:21 #periperi: < geertu> What does CMA have to do with HDMI?
+11:21 #periperi: < horms> what are the complicatinos?
+11:21 #periperi: < dammsan> but to support large HD resultion frames
+11:21 #periperi: < geertu> ok
+11:21 #periperi: < horms> i.e. what fall out might we see?
+11:21 #periperi: < dammsan> the non-CMA allocator does not provide enough
+11:21 #periperi: < dammsan> memory
+11:21 #periperi: < dammsan> oh anything is possible
+11:21 #periperi: < horms> ok
+11:21 #periperi: < horms> so how about we queue it up for v4.4 now, in devel
+11:21 #periperi: < dammsan> the entire internal DMA API memory allocator path is changed
+11:21 #periperi: < horms> so it can get lots of exposure
+11:22 #periperi: < dammsan> good plan
+11:22 #periperi: < horms> seeing as everyone uses that defconfig :^)
+11:22 #periperi: < dammsan> we can mitigate the risk by comparing with say some common ARM v7 defconfig and see what they use
+11:22 #periperi: < dammsan> I think using CMA makes sense either way
+11:22 #periperi:  * geertu almost never uses shmobile_defconfig for booting
+11:22 #periperi: < horms> geertu: I was being facetious
+11:22 #periperi: < dammsan> but enabling it in a controlled manner makes sense
+11:23 #periperi: < geertu> multi_v7_defconfig already has CONFIG_CMA=y
+11:23 #periperi: < dammsan> ok great
+11:23 #periperi: < dammsan> can we add a task for this?
+11:23 #periperi: < horms> do you use that config often?
+11:24 #periperi: < geertu> horms: not really, it's broken a lot
+11:24 #periperi: < horms> ok
+11:24 #periperi: < geertu> horms: and fails to boot on anything but Gen2 due to (assumed) kernel image size limits in various boot loaders
+11:24 #periperi: < horms> awesome
+11:25 #periperi: < dammsan> geertu: we should really fix the size limitations
+11:25 #periperi: < geertu> dammsan: task for enabling CONFIG_CMA=y and verifying that it doesn't break anything?
+11:25 #periperi: < dammsan> i guess one by one
+11:25 #periperi: < dammsan> geertu: i think simply enabling it is fine
+11:25 #periperi: < dammsan> we will notice if something goes wrong
+11:25 #periperi: < geertu> horms: multi_v7 is also incomaptible with kzm9g for anothe reason (have to dig it up)
+11:26 #periperi: < dammsan> geertu: isn't that fixed by your removal of the reserved memory space?
+11:26 #periperi: < horms> geertu: kevin hilman probaly knows
+11:26 #periperi: < dammsan> horms: kevin has kzm9d not g
+11:26 #periperi: < horms> oops
+11:26 #periperi: < horms> i fall for that one every time
+11:26 #periperi: < dammsan> but close enough =)
+11:27 #periperi: < geertu> Yeah, "D" stands for "dual", but the "G" is dual-core too ;-)
+11:27 #periperi: < geertu> "G" stands for?
+11:27 #periperi: < horms> GT
+11:27 #periperi: < geertu> Gran Turismo
+11:27 #periperi: < dammsan> Maybe related to "genesis" code name
+11:28 #periperi: < geertu> Ah, I love git history ;-)
+11:28 #periperi: < geertu>       - sh73a0/kzm9g:
+11:28 #periperi: < geertu>           - zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n,
+11:28 #periperi: < dammsan> used for ARM based SoCs targeting  mobile devices
+11:28 #periperi: < geertu> multi_v7 has CONFIG_ARM_ATAG_DTB_COMPAT=y
+11:29 #periperi: < dammsan> i see, they assume that the boot loader will pass something that makes sense
+11:29 #periperi: < geertu> Task "shmobile_defconfig,v4.4,Enable CONFIG_CMA=y" added
+11:29 #periperi: < dammsan> must be different corporate culture
+11:29 #periperi: < dammsan> geertu: thanks!
+11:29 #periperi: < geertu> Next topic?
+11:29 #periperi: < horms> yes!
+11:30 #periperi:  * geertu likes the perfect timing
+11:30 #periperi: < geertu> Topic 3. Topic versioning
+11:30 #periperi: < geertu> Simon uses topic/...
+11:30 #periperi: < geertu> E.g. topic/arm64-rcar-gen3-v3
+11:31 #periperi: < horms> the reason being to make it different from branches targeted at mainline
+11:31 #periperi: < geertu> I had used before (in renesas-drivers-2015-07-14-v4.2-rc2) arm64-rcar-gen3-v2
+11:31 #periperi: < horms> though it could be different in other ways
+11:31 #periperi: < geertu> But adding the topic indeed makes sense
+11:32 #periperi: < geertu> For branches merged through git I depend on the creator of the branch
+11:32 #periperi: < geertu> E.g. drm/du/vsp1-kms didn't have any versioning information (and changed)
+11:32 #periperi: < geertu> In the mean time it has changed again...
+11:32 #periperi: < dammsan> (multiple times, and seems to keep on changing)
+11:33 #periperi: < geertu> Now, we do have versioning due to the exact version being available in renesas-drivers-2015-08-04-v4.2-rc5 git history
+11:33 #periperi: < dammsan> accorting to laurent he will start versioning when it is stable
+11:33 #periperi: < geertu> So personally I don't mind much (for now)
+11:33 #periperi: < dammsan> s/stable/working/g
+11:34 #periperi: < dammsan> geertu: did you notice the build error?
+11:34 #periperi: < geertu> No
+11:34 #periperi: < horms> from my pov if we have a version on the merge branch
+11:35 #periperi: < horms> then we have enough to work with
+11:35 #periperi: < dammsan> geertu: the shmobile_defconfig does not build, but we can chat about that later
+11:35 #periperi: < geertu> So the broken code was not enabled in my own configs, nor in shmobile_defconfig, nor in multi_v7_defconfig?
+11:35 #periperi: < geertu> zero-day build also didn't complain
+11:37 #periperi: < horms> other than adding errors is there a way to find out what is being checked by zero-day?
+11:37 #periperi: < geertu> Yes
+11:37 #periperi: < dammsan> geertu: i'm using shmobile_defconfig without any modifications
+11:37 #periperi: < geertu> You can ask Fengguang for receiving reports when he has build your repo
+11:38 #periperi: < horms> thanks
+11:38 #periperi: < dammsan> geertu: i get "drivers/media/platform/vsp1/vsp1_drv.c:26:22: fatal error: vsp1_drm.h: No such f
+11:38 #periperi: < dammsan> ile or directory
+11:38 #periperi: < geertu> Quoting Fengguang on ksummit-discuss
+11:38 -!- Irssi: Pasting 6 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
+11:38 #periperi: < geertu> Just send me an email and say something like
+11:38 #periperi: < geertu>         I'd like to get build completion notification for git URLs
+11:38 #periperi: < geertu>             git://neil.brown.name/md
+11:38 #periperi: < geertu>             git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git
+11:39 #periperi: < dammsan> sorry for going into offtopic and with compile errors
+11:39 #periperi: < dammsan> lets deal with those later
+11:39 #periperi: < geertu> (Interesting)
+11:39 #periperi: < geertu> Full list of 0-day is at https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/repo/linux
+11:42 #periperi: < geertu> Oops, I do have the same build error, but missed it. Oops
+11:42 #periperi: < geertu> Which brings me to another issue:
+11:42 #periperi: < geertu> renesas-drivers is no longer suitable for upstream development, as it contains code that is not ready for submission yet
+11:42 #periperi: < geertu> I.e. you can no longer base your work for submission on that
+11:43 #periperi: < shimoda> now i fetched laurent-san repo, it has vsp1_drm.h
+11:43 #periperi: < dammsan> geertu: this is why i sort of wanted you to have two separate releases =)
+11:43 #periperi: < geertu> Yeah, I'll have to keep the "unstable" stuff on a separate branch
+11:43 #periperi: < geertu> It does mean it will receive less testing
+11:44 #periperi: < horms> fwiw, its also why i left the topic branch out of devel
+11:44 #periperi: < geertu> yeah yeah, I know ;-)
+11:44 #periperi: < geertu> So now we have a collection of rotten patches no one dares to use ;-)
+11:44 #periperi: < dammsan> geertu: how difficult is it to make a new release?
+11:45 #periperi: < dammsan> according to laurent he fixed the build error
+11:45 #periperi: < geertu> If nothing new was broken, less than one hour
+11:46 #periperi: < dammsan> geertu: can you add a simple test with shmobile_defconfig build?
+11:46 #periperi: < geertu> Shall I make a new renesas-drivers + separate "snapshot1b" for today?
+11:46 #periperi: < geertu> I was supposed to build shmobile_defconfig
+11:47 #periperi: < dammsan> i would simply make a new snapshot release without any special suffix
+11:47 #periperi: < geertu> But too many windows, and I though it was multi_v7_defconfig (which had a known issue) i.s.o. shmobile_defconfig that failed
+11:48 #periperi: < dammsan> if you dont mind then including unstable code for a little while seems our only choice
+11:48 #periperi: < dammsan> changing our process may confuse the internal customer
+11:48 #periperi: < geertu> Sure, but submitters have to learn how to rebase from "snapshotX" --onto renesas-drivers-Y
+11:49 #periperi: < dammsan> from my side, if we find some issue then unless it is too much trouble then doing a new release makes sense
+11:49 #periperi: < geertu> agreed
+11:49 #periperi: < dammsan> geertu: if your condern is to create a stable base for upstream development
+11:49 #periperi: < dammsan> and now when renesas-drivers is not
+11:50 #periperi: < dammsan> then i think the correct approach for people is to do initial development on a recent renesas-drivers release
+11:50 #periperi: < geertu> renesas-drivers is not 100% stable, as it is rebased
+11:50 #periperi: < dammsan> and then move to the subsystem -next tree for the final adjustment
+11:50 #periperi: < dammsan> sure
+11:50 #periperi: < geertu> the subsystem -next tree should already be included in rensas-drivers
+11:51 #periperi: < dammsan> i'm trying to get internal teams to rebase on a weekly basis
+11:51 #periperi: < dammsan> yeah
+11:51 #periperi: < geertu> It's e.g. i2c hacks in dtsi. I couldn't base the cpg/mstp clock domain patches on that
+11:51 #periperi: < dammsan> when you say "base" do you mean for upstream submission?
+11:52 #periperi: < geertu> yes
+11:52 #periperi: < dammsan> fsure, so you should use the subsystem tree for that
+11:52 #periperi: < dammsan> but for integration i think renesas-drivers makes sense
+11:52 #periperi: < dammsan> ideally any hacks should be excluded
+11:52 #periperi: < dammsan> in my opinion
+11:53 #periperi: < geertu> So I will create a new renesas-drivers-2015-08-05-v4.2-rc5 today
+11:54 #periperi: < geertu> and a separate renesas-snapshot-1 containing the topic/* stuff?
+11:56 #periperi: < dammsan> i think creating a new renesas-drivers release makes sense - but including laruents stuff
+11:56 #periperi: < dammsan> and i think we should also ask him to separate his hacks from the more stable bits
+11:56 #periperi: < geertu> Hence one release
+11:57 #periperi: < dammsan> and the hack portion has to be dealt with somehow
+11:57 #periperi: < dammsan> but your proposal sounds quite fine too
+11:57 #periperi: < dammsan> with the two releases
+11:58 #periperi: < dammsan> i guess it boils down to what the purpose of renesas-drivers is
+11:58 #periperi: < geertu> Usually it doesn't matter if there's one realease
+11:58 #periperi: < dammsan> right exactly
+11:58 #periperi: < dammsan> one release is simple and good
+11:58 #periperi: < geertu> as long as people are not stepping on each other's toes
+11:59 #periperi: < dammsan> so how about doing one more of them now
+11:59 #periperi: < geertu> but I always seem to attract the work that e.g. touches all device nodes in dt ;-)
+11:59 #periperi: < dammsan> and we need to discuss with laurent how to handle his hacks
+11:59 #periperi: < dammsan> geertu: yes =)
+11:59 #periperi: < pinchartl> what hacks ? :-)
+11:59 #periperi: < geertu> .. and the work that involves lockstepping dt and c code
+12:00 #periperi: < pinchartl> (sorry, I've missed the beginning of the conversation)
+12:00 #periperi: < geertu> #ifdefs in dtsi
+12:00 #periperi: < dammsan> pinchartl: please split upstream-targetting code from local DT changes and other short term hacks
+12:01 #periperi: < pinchartl> are you referring to any local DT change in particular ?
+12:01 #periperi: < dammsan> this is probably the same reason why ARM-SoC guys asks for several split out branches
+12:02 #periperi: < dammsan> pinchartl: we need to simplify integration somehow i think, but i have no detail. maybe geert has
+12:02 #periperi: < dammsan> geertu: can you describe hte issue?
+12:03 #periperi: < geertu> pinchartl: as renesas-drivers now contains code that is not ready for submission yet
+12:04 #periperi: < geertu> you can no longer use it for upstream development and for preparing patches for upstream submission
+12:04 #periperi: < pinchartl> right
+12:04 #periperi: < geertu> however, as long as people are not stepping on each other's toes, it's still fine
+12:05 #periperi: < dammsan> geertu: so we shall keep out the koelsch-specific I2C prototype patch for HDMI enablement?
+12:06 #periperi: < dammsan> if we want to be able to develop DTS changes for Koelsch I2C portion?
+12:06 #periperi: < geertu> dammsan: You will teach the gen3 developers how to rebase ("git rebase --onto renesas-drivers-$new renesas-drivers-$old master")?
+12:06 #periperi: < horms> geertu: that is the general idea
+12:06 #periperi: < dammsan> geertu: yes, that's the idea
+12:07 #periperi: < geertu> For now, let's keep the hack in
+12:07 #periperi: < geertu> I'll try to stop touching all device nodes for a while :-)
+12:07 #periperi: < dammsan> pinchart: would it be possible for you to adjust to keep more unstable stuff in a separate topic branch later?
+12:08 #periperi: < dammsan> perhaps this is only an issue during early development phase too
+12:08 #periperi: < geertu> We're running out of time
+12:09 #periperi: < dammsan> so can we break out the topic branch discussion to later?
+12:09 #periperi: < dammsan> and move on?
+12:09 #periperi: < dammsan> when are we supposed to end again?
+12:09 #periperi: < horms> 21 min
+12:10 #periperi: < horms> in 21 min, iirc
+12:10 #periperi: < geertu> 3 more topics
+12:10 #periperi: < geertu> 21 / 3 = 7
+12:10 #periperi: < geertu> Topic 4. Status check for tasks from last meeting - what is remaining?
+12:10 #periperi: < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list
+12:10 #periperi: < pinchartl> dammsan: I keep the I2C hack in a separate branch, I've only merged it into the vsp-du-kms branch because it's a prototype
+12:10 #periperi: < geertu> magnus: You received coffee?
+12:10 #periperi: < dammsan> pinchartl: gotcha
+12:10 #periperi: < dammsan> yes, thanks a lot!
+12:11 #periperi: < dammsan> and i did fix up r8a7779 and Marzen, not sure if all is done yet due to merge order issues
+12:11 #periperi: < geertu> pinchartl: when will you kick it out, so I can create another release?
+12:11 #periperi: < horms> geertu: i did some analysis of marzen, then dammsan removed it. so that seems to be case-closed
+12:11 #periperi: < horms> geertu: i belive the bockw situation has moved forwards but needs more work. ulrich is handling that i believe
+12:11 #periperi: < geertu> BTW, what do we do with closed tasks? Just remove?
+12:11 #periperi: < dammsan> is ulrich around?
+12:12 #periperi: < uli___> i think an ack on the SD pull-up stuff by laurent and/or geert would help to move this forward
+12:12 #periperi: < dammsan> geertu: i think removing them is fine
+12:12 #periperi: < geertu> IPMMU+DMAC prototype was done, using identity mapping?
+12:12 #periperi: < dammsan> uli___: what is blocking your progress on consolidating DTS files?
+12:12 #periperi: < dammsan> geertu: yes, i believe so
+12:13 #periperi: < pinchartl> geertu: end of the day^H^H^Hnight today :-)
+12:13 #periperi: < uli___> the sd stuff; if it's not in, functionality is lost until it is.  not sure how much of a problem that is...
+12:13 #periperi: < dammsan> i say no problem
+12:13 #periperi: < uli___> well then...
+12:14 #periperi: < geertu> Identify missing support is done for both '78 and '79, right?
+12:14 #periperi: < dammsan> we can have a vote: all people with bock-w hardware in front of them gets to vote:
+12:14 #periperi: < dammsan> i vote no
+12:14 #periperi: < uli___> vote on what?
+12:14 #periperi: < dammsan> if we need to keep it stable =)
+12:14 #periperi: < geertu> r8a7778 r8a7779,v4.2,Vote which missing support is valuable
+12:14 #periperi: < horms> i vote that we don't make bockw unstable
+12:14 #periperi: < dammsan> geertu: right, i think it would make sense to fix up the USB bits
+12:15 #periperi: < horms> and that we move forwards with removing legacy asap
+12:15 #periperi: < horms> both would make my life beter immediately
+12:15 #periperi: < dammsan> horms: why dont you and ulrich make it happen?
+12:15 #periperi: < uli___> horms: aren't those conflicting?
+12:16 #periperi: < horms> perhaps not
+12:16 #periperi: < geertu> Is anything valuable still missing on r8a779/marzen?
+12:16 #periperi: < dammsan> USB
+12:17 #periperi: < dammsan> (but without access to real hardware development is difficult)
+12:17 #periperi: < geertu> USB on bockw or marzen?
+12:17 #periperi: < dammsan> I only care about Marzen
+12:17 #periperi: < dammsan> I think the creators of Bock-W has to care about them
+12:17 #periperi: < horms> uli___: right now bockw-multiplatform seems to work, for some limited feature set. I'd like it to stay working even if that means it gets features slower (or never)
+12:17 #periperi: < dammsan> if they don't then we can slowly phase them out
+12:18 #periperi: < uli___> horms: that should be possible
+12:18 #periperi: < horms> dammsan: I'd like to avoid silos in gen-1 land
+12:19 #periperi: < dammsan> silos?
+12:19 #periperi: < horms> i mean, i think we should work togeher on both boards because surely they must have a lot of commonality
+12:19 #periperi: < geertu> Milan, Geuze, and Silverstone?
+12:20 #periperi: < dammsan> horms: no, gen1 has little common sense
+12:20 #periperi: < horms> i do agree that we should remove boards that it is no long appropriate for us to support
+12:20 #periperi: < dammsan> i mean commonality
+12:20 #periperi: < geertu> Blanche, Stout?
+12:20 #periperi: < horms> ok
+12:20 #periperi: < dammsan> horms: it is not difficult to support, someone just has to do it
+12:20 #periperi: < dammsan> horms: so please work with ulrich and make sure it moves forward
+12:20 #periperi: < horms> ok
+12:21 #periperi: < geertu> So we can drop bockw-{legacy,reference}?
+12:21 #periperi: < dammsan> if i can fix up marzen on my spare time then the two of you must be able to move if forward too
+12:21 #periperi: < geertu> next topic?
+12:21 #periperi: < dammsan> geertu: i think keeping the reference
+12:21 #periperi: < uli___> why that?
+12:21 #periperi: < dammsan> but same state as current marzen - ie DT-only board support
+12:22 #periperi: < dammsan> i don't want to whine, but i fail to see what the real problem is?
+12:22 #periperi: < geertu> all bockw-reference has is the fpga 
+12:22 #periperi: < geertu> pinctrl"
+12:22 #periperi: < uli___> throwing out the c code makes reference pretty much equivalent with MP
+12:22 #periperi: < dammsan> and that is blocking merging of DT files?
+12:22 #periperi: < geertu> Topic 5. Upcoming Gen3 development for the Core group
+12:23 #periperi: < dammsan> geertu: right
+12:23 #periperi: < geertu> (I think we can live with a fake pinctrl abstraction in dt)
+12:23 #periperi: < dammsan> does shimoda-san or morimoto-san have anything to share with us?
+12:23 #periperi: < geertu> Are they here? ;-)
+12:24 #periperi: < dammsan> geertu: we can also drop some features and re-develop later if needed
+12:24 #periperi: < horms> at least shimoda-san was here
+12:24 #periperi: < dammsan> shimoda: hellou?
+12:25 #periperi: < shimoda> sorry
+12:25 #periperi: < morimoto> hi
+12:26 #periperi: < morimoto> sorry, I'm working for Gen3 right now
+12:26 #periperi: < dammsan> hi guys, can you please let us know a bit more about the Core poriton about gen3 development this month?
+12:26 #periperi: < morimoto> I'm creating bootable kernel patch set
+12:26 #periperi: < morimoto> but, today, BSP team used Geert's latest release for it
+12:26 #periperi: < morimoto> and it doesn't work on H3
+12:27 #periperi: < morimoto> (it works previous release)
+12:27 #periperi: < dammsan> morimoto: it seems that it does not compile, and it is not ready for gen2 either
+12:27 #periperi: < dammsan> morimoto: so internal guys should wait a bit it seems
+12:27 #periperi: < morimoto> OK
+12:28 #periperi: < morimoto> I don't know detail (because I don't have board)
+12:28 #periperi: < dammsan> so, we need to explain about the gen3 development plan
+12:28 #periperi: < geertu> arm64_defconfig definitely compiles
+12:28 #periperi: < morimoto> but, it seems they could compile
+12:28 #periperi: < shimoda> until 11th, we need IRQC.
+12:28 #periperi: < dammsan> this plan assumed we had hardware access
+12:28 #periperi: < shimoda> until 18th, we need PFC and GPIO
+12:29 #periperi: < dammsan> ok, so we need 3 new tasks it seems
+12:29 #periperi: < dammsan> 1. IRQC
+12:29 #periperi: < geertu> IRQC (INTC-EX): Looks identical to Gen2
+12:29 #periperi: < dammsan> 2.GPIO
+12:29 #periperi: < dammsan> 3. PFC
+12:29 #periperi: < geertu> GPIO: Looks identical to Gen2
+12:29 #periperi: < geertu> PFC: New driver support (at least the pin/groups/function tables)
+12:29 #periperi: < dammsan> geertu: sure, needs DT compat string changes nevertheless
+12:29 #periperi: < geertu> (quoting from email "Gen3 work")
+12:29 #periperi: < geertu> dammsan: of course
+12:30 #periperi: < dammsan> so ulrich posted PFC earlier?
+12:31 #periperi: < geertu> no, gpio
+12:31 #periperi: < uli___> gpio has been picked up
+12:31 #periperi: < geertu> Tasks "gpio,v4.2,Add r8a7795 support" not added
+12:32 #periperi: < geertu> Task "irqc,v4.2,Add r8a7795 support" added
+12:32 #periperi: < dammsan> ok, thanks for the clarification =)
+12:32 #periperi: < geertu> Task "pfc,v4.2,Add r8a7795 support" added
+12:32 #periperi: < dammsan> thanks!
+12:32 #periperi: < geertu> (v4.2 is due to the internal target date)
+12:33 #periperi: < dammsan> geertu: i don't understand the internal target i'm afraid
+12:33 #periperi: < dammsan> i thought we tracked when we thought it would be merged upstream
+12:33 #periperi: < geertu> "11th" and "18th"?
+12:33 #periperi: < geertu> v4.4
+12:33 #periperi: < geertu> updated
+12:33 #periperi: < dammsan> thanks
+12:34 #periperi: < geertu> I think "Topic 6. SoC Bus topology in DT" is related?
+12:34 #periperi: < dammsan> those dates are the upcoming snapshot dates
+12:34 #periperi: < geertu> and can be handled together in the last -4 minutes?
+12:34 #periperi: < dammsan> i think so, but will take forever i think?
+12:34 #periperi: < dammsan> geertu and horms: i asked morimoto-san to fix up some CPG related bits in the Gen3 series and resent V4
+12:35 #periperi: < dammsan> this without dealing with the topology
+12:35 #periperi: < horms> so there will be a v5 soon?
+12:35 #periperi: < pinchartl> speaking of bus topology, I haven't seen a block diagram that shows the bus topology in the Gen3 datasheet. have I just missed it ?
+12:35 #periperi: < dammsan> i doubt we can reach some concensus soon on the topology
+12:36 #periperi: < dammsan> if you can tie in the CCI, GIC and CPU clusters with the rest of the topology let me know
+12:36 #periperi: < geertu> pinchartl: You need acid and an electron microscope
+12:36 #periperi: < dammsan> especially with not so much documentation
+12:36 #periperi: < dammsan> i think we need to deal with it bus-by-bus somehow
+12:36 #periperi: < pinchartl> I have a bottle of vinegar and a couple of lemons in my fridge. will it do ?
+12:36 #periperi: < pinchartl> I think we can start with just one bus, that should be enough
+12:37 #periperi: < pinchartl> ideally it should be an AMBA bus
+12:37 #periperi: < dammsan> but blocking the series on it seems a bit slow moving, no?
+12:37 #periperi: < geertu> indeed
+12:37 #periperi: < geertu> just continue
+12:37 #periperi: < dammsan> is there any reason why we can't deal with that incrementally?
+12:37 #periperi: < shimoda> pinchartl: section 5 AXI-bus is mentioned some diagram
+12:38 #periperi: < dammsan> pinchartl: in the end it seems to boil down to trying to describe a non-tree topology as a tree
+12:39 #periperi: < shimoda> oops, section 15, not 5
+12:39 #periperi: < pinchartl> some diagrams mention AXI4, others mention APB
+12:39 #periperi: < pinchartl> I expect the real bus topology to be quite complex
+12:39 #periperi: < dammsan> how about we fix Gen2 first? =)
+12:39 #periperi: < pinchartl> and I don't think we really need to describe it fully in DT
+12:39 #periperi: < dammsan> at least we have a some chance due to half-stable documentation
+12:40 #periperi: < dammsan> as opposed to gen3
+12:40 #periperi: < pinchartl> I'd be fine with just a single bus
+12:40 #periperi: < geertu> dammsan And make it not backwards-compatible with the bsp?
+12:40 #periperi: < dammsan> geertu: do you mean on a source code level?
+12:41 #periperi: < dammsan> geertu: the DT ABI is unaffected, no?
+12:41 #periperi: < pinchartl> it would be great if it could be an "arm,amba-bus" but that will require changes to drivers I believe
+12:41 #periperi: < dammsan> pinchartl: why don't we begin with a single bus for now then
+12:41 #periperi: < pinchartl> dammsan: yes, a single bus is fine
+12:41 #periperi: < dammsan> like today?
+12:41 #periperi: < pinchartl> what bothered me was the nodes directly under the DT root node
+12:42 #periperi: < dammsan> is that different compared to Gen2?
+12:42 #periperi: < pinchartl> if we group them in a simple-bus that should be fine
+12:42 #periperi: < pinchartl> gen2 has everything at the root
+12:42 #periperi: < dammsan> morimoto: did you get that?
+12:42 #periperi: < pinchartl> I'd like to avoid repeating that mistake
+12:42 #periperi: < pinchartl> it should be very easy to fix
+12:42 #periperi: < dammsan> what makes it difficult to move?
+12:43 #periperi: < pinchartl> just create a node compatible with simple-bux
+12:43 #periperi: < pinchartl> move all memory-mapped IPs there
+12:43 #periperi: < pinchartl> and that's it
+12:43 #periperi: < dammsan> sure
+12:43 #periperi: < geertu> s/simple-bux/simple-bus/
+12:43 #periperi: < pinchartl> simple-bug :-)
+12:43 #periperi: < dammsan> but that should be doable for gen2 as well without any odd side effects, no?
+12:43 #periperi: < pinchartl> yes it should be doable
+12:43 #periperi: < dammsan> you speak bruxells lingo =)
+12:44 #periperi: < pinchartl> :-)
+12:44 #periperi: < pinchartl> moving to an amba bus would be correct, bus also more complex
+12:44 #periperi: < dammsan> sure, but we better be sure what we want at that point
+12:44 #periperi: < pinchartl> so let's start with simple bus now
+12:45 #periperi: < dammsan> geertu: can we add a task to add simple-bux for Gen3 =)
+12:45 #periperi: < geertu> agreed
+12:46 #periperi: < geertu> Added "r8a7795,v4.4,Group on-SoC devices under a simple-bus node on r8a7795"
+12:46 #periperi: < dammsan> wondeful, thanks!
+12:47 #periperi: < geertu> Finished?
+12:47 #periperi: < geertu> I mean "any other things to discuss?" :-)
+12:47 #periperi: < dammsan> i'm ok for overall stuff, but if people have time left then do we need to bang our head against the topic-branch somehow?
+12:47 #periperi: < dammsan> what was the conclusion there again?
+12:48 #periperi: < geertu> renesas-drivers will contain the "unstable" stuff, too.
+12:48 #periperi: < geertu> But Laurent will remove the hacks for next week's release
+12:49 #periperi: < dammsan> as for this week, what will happen?
+12:49 #periperi: < geertu> I will create a new unified release using current drm/du/vsp1-kms
+12:49 #periperi: < geertu> (after lunch)
+12:49 #periperi: < pinchartl> if I remove the hacks (I2C hack and #include of the panel .dtsi), Renesas will need to add them for testing. are they aware of that ?
+12:49 #periperi: < dammsan> i think we can manage on this side
+12:50 #periperi: < dammsan> especially if you have a local topic branch with that stuff somewhere =)
+12:50 #periperi: < dammsan> i mean not local, but separate
+12:50 #periperi: < dammsan> we will manage regardless
+12:50 #periperi: < dammsan> but it would be nice to see those things somewhere
+12:51 #periperi: < dammsan> geertu: sounds good about the release after lunch! thank you!
+12:52 #periperi: < dammsan> pinchartl: if you prefer not to publish the hacks separately then thats fine too
+12:52 #periperi: < pinchartl> I can push two branches, that's fine
+12:52 #periperi: < dammsan> thanks, that's great!
+12:53 #periperi: < dammsan> can you drop me an mail once you've gone over to two-branch mode?
+12:53 #periperi: < dammsan> i'll inform people
+12:54 #periperi: < dammsan> also
+12:54 #periperi: < horms> dammsan: can we come back to m1, either here or privately? I'd like to clarify some things.
+12:54 #periperi: < dammsan> once we get real gen3 hardware working in the remote access i'll notify the periperi mailing list
+12:55 #periperi: < dammsan> horms: sure!
+12:55 #periperi: < dammsan> any time
+12:55 #periperi: < horms> how about now? :)
+12:55 #periperi: < dammsan> sure! =)
+12:55 #periperi: < horms> great
+12:55 #periperi: < geertu> I'm out for lunch. Bye!
+12:55 #periperi: < horms> so i think we almost agreed to remove legacy
+12:55 #periperi: < dammsan> geertu: thanks
+12:55 #periperi: < dammsan> bon apetit
+12:56 #periperi: < horms> but i'm unsure what you want to happen to reference in the short term
+12:56 #periperi: < horms> geertu: enjoy
+12:56 #periperi: < dammsan> ok i see
+12:56 #periperi: < dammsan> i may misunderstand things
+12:56 #periperi: < horms> from my pov it should go too
+12:56 #periperi: < horms> i.e. be deleted
+12:56 #periperi: < dammsan> but the only thing i see at this point is a lot of blocking and not so many patches
+12:56 #periperi: < horms> right, that we need to change
+12:57 #periperi: < dammsan> i mean, i can do it myself but then what is the point of all this?
+12:58 #periperi: < horms> i think i have a clear picture now
+12:58 #periperi: < horms> i'll work with uli___ to move things forwards
+12:58 #periperi: < dammsan> so is it possible to move forward with the conversion?
+12:58 #periperi: < dammsan> i mean, you guys saw my Bock-W patches
+12:58 #periperi: < dammsan> i mean Marzen
+12:58 #periperi: < dammsan> brain fart
+12:58 #periperi: < uli___> since we have come to the conclusion that missing features are not that important, we can go ahead, i guess
+12:59 #periperi: < horms> uli___: agreed
+12:59 #periperi: < dammsan> auli___: sure that's one important thing
+12:59 #periperi: < dammsan> but from my side it looks like you can move forward more without blocking too...
+12:59 #periperi: < dammsan> why can't you merge the board DTS files for instance?
+12:59 #periperi: < dammsan> is it lack of focus or time
+13:00 #periperi: < dammsan> or a technical reason to block it?
+13:00 #periperi: < uli___> no, it's just that there is nothing to merge.  everything worth keeping is in the other file already.
+13:00 #periperi: < uli___> the difference is only in c code
+13:00 #periperi: < horms> ok, so we can remove one of the dt files?
+13:00 #periperi: < dammsan> so why do we still have two files?
+13:01 #periperi: < uli___> because reference needs it.
+13:01 #periperi: < dammsan> this portion i don't understand. =)
+13:01 #periperi: < dammsan> why can't a single file work?
+13:01 #periperi: < dammsan> it did for all other platforms
+13:01 #periperi: < dammsan> during transition
+13:02 #periperi: < uli___> what for?  let's just dump reference altogether.
+13:02 #periperi: < dammsan> i realize you have that FPGA thing
+13:02 #periperi: < dammsan> uli: but that's wha you are doing if you are merging the DTS files into a single one
+13:03 #periperi: < uli___> well, there are a few other things that need to be touched up, but i didn't do this because i considered the missing features to be blockers
+13:03 #periperi: < dammsan> everytime i look at the xxx-reference file in arch/arm/boot/dts i wonder why we still have two files for bock-w
+13:03 #periperi: < dammsan> ok
+13:03 #periperi: < dammsan> but i think we discussed this before, and i pointed out that you can move forward regardless
+13:04 #periperi: < dammsan> but anyway
+13:04 #periperi: < dammsan> so would it be possible for you to work with simon and finalize the Bock-W bits?
+13:05 #periperi: < uli___> sure thing, i have all the patches here.  only need to reorder them to "dump first, add features later"
+13:05 #periperi: < horms> excellent
+13:05 #periperi: < dammsan> uli___: but merging the DTS does not result in any dumping, does it?
+13:05 #periperi: < horms> the begining of a merge cycle is an excellent time for remving code. and that means now because i've already started taking patches for v4.4
+13:06 #periperi: < dammsan> uli___: but i understand you mean removing legacy before having equivalent feature support in multiplatform, right?
+13:06 #periperi: < uli___> legacy and reference
+13:07 #periperi: < uli___> i'd start with reference, it's smaller.  but that's just a matter of taste, i guess
+13:07 #periperi: < dammsan> horms: so which order do you want stuff?
+13:07 #periperi: < dammsan> i probably did the wrong order with the r8a7779 and marzen bits
+13:07 #periperi: < dammsan> i did cleanup of -reference first
+13:07 #periperi: < dammsan> followed by a legacy removal
+13:07 #periperi: < uli___> that's what i thought to do as well
+13:08 #periperi: < dammsan> uli___: so i thought you could do a similar series for the -reference cleanup
+13:08 #periperi: < dammsan> but without causing any degradation of the multiplatform feature support
+13:08 #periperi: < dammsan> (this is the bit i don't understand why it has not happened, but never mind)
+13:09 #periperi: < horms> i think that makes sense
+13:09 #periperi: < uli___> yes
+13:09 #periperi: < horms> its not ideal from a merge pov, but we don't want multiplatform to go backwards
+13:10 #periperi: < horms> so i think it is the way to go
+13:11 #periperi: < horms> uli___: can you make it so?
+13:11 #periperi: < uli___> can do.
+13:12 #periperi: < horms> excellent
+13:12 #periperi: < horms> please let me know if you hit any snags
+13:12 #periperi: < dammsan> uli___: do you have a local board?
+13:12 #periperi: < dammsan> (bock-w i mean)
+13:12 #periperi: < uli___> nope, i'm using yours.  but for removal, that should not be strictly necessary. :)
+13:13 #periperi: < dammsan> ok, will remember that you are still using that!
+13:13 #periperi: < horms> well, multiplatform will still need to be tested
+13:13 #periperi: < horms> btw, i am also using that board
+13:13 #periperi: < dammsan> sure
+13:13 #periperi: < horms> lets try not to step on each others toes :)
+13:13 #periperi: < uli___> unlikely, given the time zone difference, i'd say :)
+13:14 #periperi: < horms> yes, agreed
+13:14 #periperi: < dammsan> so will you fix it up until next meeting?
+13:14 #periperi: < dammsan> i fixed up r8a7779 and the IPMMU prototype last time
+13:15 #periperi: < uli___> which is when, btw?
+13:15 #periperi: < dammsan> i suppose geert will announce that
+13:15 #periperi: < dammsan> my guess would be 2 weeks
+13:15 #periperi: < horms> that is my guess too
+13:15 #periperi: < uli___> sure
+13:16 #periperi: < dammsan> great - that means in 2 weeks i can look forward to no more legacy!
+13:16 #periperi: < uli___> whatever makes you happy ;)
+13:17 #periperi: < dammsan> reduced whining from ARM-SoC is always a good thing
+13:17 #periperi: < dammsan> and reduced whining from me must be nice too =)
+13:18 #periperi: < uli___> i'm not going to comment :)
+13:18 #periperi: < dammsan> hahah
+13:18 #periperi: < uli___> but i will go and have lunch now
+13:18 #periperi: < dammsan> sure, have a nice one
+13:18 #periperi: < horms> yes
+13:18 #periperi: < horms> lets close this for now
+13:18 #periperi: < horms> i'm looking forward to seeing some patches
+13:19 #periperi: < dammsan> horms: lets continue the remote access discussion tomorrow or friday
+13:19 #periperi: < horms> dammsan: i'll be coming and going tomorrow
+13:19 #periperi: < horms> friday is probably better for me
+13:19 #periperi: < dammsan> sure no worries
+13:19 #periperi: < dammsan> have a nice evening and a pleasant tomorrow then =)
+13:20 #periperi: < dammsan> see ya later
+13:20 #periperi: < horms> thanks you too
+13:20 #periperi: < uli___> good night
+13:20 #periperi: < dammsan> bye!