path: root/wiki/Chat_log/20150805-core-chatlog

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!