Core-chat-meeting-2015-11-06

10:04 < geertu> Agenda:
10:04 < geertu> 1. Upcoming Gen3 development for the Core group,
10:04 < geertu> 2. Gen3 integration - ARCH_R8A7795 / ARCH_RENESAS - serial0:115200n8 - GIC/GICH/GICV
10:04 < geertu> 3. Status check for tasks from last meeting - what is remaining?
10:04 < geertu> Topic 1: Upcoming Gen3 development for the Core group
10:04 < horms> I can also speak to some gen2 ingegration work if there is time
10:05 < geertu> OK, let's cover that with Topic 2.
10:05 < horms> With regards to topic 1, Morimiti-san, do you want to talk about sound?
10:05 < horms> wow, super bad typing. I meant morimoto`
10:06  * geertu thought it was modern Greek where all vowels became 'i'
10:06 < morimoto`> I posted sound patch-set to SH/ARM ML
10:06 < horms> ok, just now?
10:06 < morimoto`> It might have compile issue
10:06 < horms> ok, we can handle that on the ML. thanks for your emails earlier today
10:07 < morimoto`> But it seems nothing happen on latest ARM branch (?)
10:07 < morimoto`> np
10:07 < morimoto`> My issue is that there is DMA_OF wrong dependency issue
10:07 < morimoto`> I already posted fixup patches to DMA ML
10:07 < horms> i think the summary for the gruop is that sound for gen3 is moving forwards, but we have some tedious dependencies in the short term
10:08 < morimoto`> Vinod accepted it, but he decided it goes to topic branch instead of fixup branch
10:08 < horms> bother
10:08 < horms> can we ask him to reconsider?
10:09 < morimoto`> Him = Vinod ?
10:09 < geertu> It causes build errors, right?
10:09 < horms> Yes, Vinod.
10:09 < morimoto`> build error will happen if
10:09 < morimoto`> 1) .config has CONFIG_OF, but doesn't have DMA_OF
10:09 < morimoto`> but it seems latest branch defconfig have both.
10:10 < morimoto`> So, no build error I think
10:10 < morimoto`> But, I don't know which branch goes to Linus/master
10:10 < horms> not for the defconfig at least
10:10 < geertu> Is this topic branch queued for v4.4 or for v4.5?
10:10 < horms> probably randconfig can find something
10:11 < morimoto`> I believe it goes to v4.4
10:11 < horms> ok, so the breakage was added in v4.4 (pre-rc1) and the fix will probably make it to v4.4?
10:11 < geertu> So it will be upstream RSN?
10:12 < morimoto`> I believe so
10:13 < horms> It sounds to me that we can make a working system using defconfig and the non-defconfig case should be resolved in the not to distant future. So I think we are in good shape.
10:13 < geertu> So what's the problem? A small time window for a possible build failure of randconfig?
10:14 < dammsan> so it seems
10:15 < horms> I think we can move on
10:15 < geertu> yep.
10:15 < geertu> No more upcoming Gen3 development?
10:16 < geertu> s/more/other/
10:16 < dammsan> i'm dealing with IPMMU at the moment
10:16 < pinchartl> geertu: not for core on my side. plenty of multimedia development though :-)
10:17 < dammsan> FYI, to use the IPMMU the boot loader stack needs to be updated =\
10:18 < dammsan> i'll tackle IRQC some time in the not so distant future
10:18 < geertu> hooray
10:18 < pinchartl> dammsan: what's wrong with the boot loader ?
10:18 < dammsan> it may be easier to phrase the question the other way around
10:18 < geertu> what's wrong with the ipmmu?
10:19 < dammsan> for the IPMMU case, some piece of software is not letting through MMU interrupts
10:19 < dammsan> PMB interrupts are let through though
10:19 < geertu> (secure) firmware?
10:19 < dammsan> that's my bet
10:19 < pinchartl> nice...
10:19 < dammsan> i now have some code that can get interrupts
10:19 < dammsan> using more recent boot software
10:20 < dammsan> in such case DEBUG1 stops working too
10:20 < dammsan> so i've poked around with the loop back adapter as a plan C
10:20 < dammsan> it is a bit messy
10:20 < dammsan> expect IPMMU to take some time
10:21 < geertu> So that explains your interest in EXIO (H)SCIF ;-)
10:21 < horms> dammsan: do you have a fire extinguisher in your lab?
10:21 < dammsan> in case the printer is on fire? =)
10:21 < dammsan> the fans from the 2 salvator-x board should boost the fire well =)
10:21 < horms> thats not the use case i had in mind, but yes, in case of that too
10:22 < dammsan> if you have trouble with some hardware consider upgrading the boot loader software
10:22 < dammsan> but it is a PITA so i don't recommend it unless it is absolutely necessary
10:23 < dammsan> you will notice if you are blocked on that
10:23 < dammsan> let me know if so
10:24 < dammsan> no other activities planned here
10:25 < shimoda> dammsan: I guess if we have to use memory more (more 1GB), we have to upgrade the boot loader
10:25 < dammsan> yeah
10:25 < dammsan> SMP may need some help too
10:26 < shimoda> I think so
10:26 < dammsan> we should consider how to handle caches
10:26 < dammsan> both on gen2 and gen3
10:27 < dammsan> ideally before enabling SMP in my opinion
10:27 < dammsan> what does the mighty core group leader say?
10:27 < geertu> I have patches to describe the caches, as part of the SYSC PM Domain work
10:28 < geertu> That was a bit put aside due to the CPG rework
10:28 < dammsan> completely understandable
10:28 < dammsan> seems the bindings are in now
10:28 < geertu> Yes, CPG/MSSR bindings are in.
10:28 < geertu> Which brings us to Topic. Gen3 integration
10:28 < dammsan> very nice!
10:29 < horms> ok, so there are a few outstanding questions from the postings of v11 and v12 of the basic patchset; which I have been handling since ELCE
10:29 < geertu> Simon wanted to discuss 4 integration things
10:30 < geertu> a. ARCH_R8A7795 (and ARCH_RENESAS?)
10:30 < horms> overall I'm tempted to label them as bikeshedding. But none the less I7d like to get some consensus amongst us before moving
10:30 < dammsan> i agree and i agree =)
10:30 < geertu> Summarized: Catalin wants to get rid of SoC-specific Kconfig options. "Use SoC+driver0specific Kconfig options
10:31 < horms> See: http://www.spinics.net/lists/arm-kernel/msg457009.html
10:31 < horms> my reading is that he asked if we need ARCH_R8A7795
10:31 < geertu> Personally, ... ah, your link covers that
10:31 < horms> and given the way pfc and cpg work
10:31 < horms> i think the answer is yes, we need it
10:32 < geertu> Perhaps they like it more if we call it CONFIG_QUIRK_R8A7795? ;-)
10:32 < pinchartl> we only need it if we want to keep the kernel size reasonable
10:32 < geertu> yes
10:32 < horms> yes
10:32 < pinchartl> and that's a reasonable thing to do :-)
10:32 < dammsan> the newer boot loader has reduced the amount of memory =)
10:32 < geertu> So I like hiding it under CONFIG_EXPERT
10:32 < dammsan> geertu: i like that too
10:32 < horms> sure, that sounds fine to me
10:33 < horms> will you replay to Catalin or should I (next week)?
10:33 < dammsan> horms: i prefer if you can come to an agreement with him
10:34 < horms> sure, will do
10:34 < dammsan> thanks
10:34 < horms> shall we move to b.?
10:34 < geertu> I'd ike to ask about ARCH_RENESAS
10:34 < horms> sure
10:34 < horms> this serves two purposes.
10:34 < geertu> So the patch description mentioned it may also apply to SH
10:35 < horms> the technical one I tried to describe on the ML
10:35 < horms> and also a non-techincal one: a red-herring for the ARM-SoC maintainers desire to see cleanups
10:35 < horms> yes, it did mention that
10:35 < geertu> There's lots of overlap between arm64 and arm32
10:35 < geertu> less between arm32 and SH
10:35 < horms> yes
10:35 < horms> the reason i mentioned it is to cover that overlap
10:36 < geertu> even less between SH and H8 (e.g. SCI)
10:36 < horms> but perhaps it not needed
10:36 < geertu> any overlap with m32r?
10:36 < horms> ideally I'd like to see SHMOBILE disapear from drivers used by arm socs
10:36 < horms> i didn't investigate deeply, but grep didn't show any
10:36 < horms> the thing is that r-car, which is the focus for renesas, is neither SH nor mobile
10:37 < geertu> So for now the "RENESAS" flag would cover Renesas arm32 and arm64 SoCs
10:37 < horms> yes
10:37 < horms> and if that is sufficient that SHMOBILE is not used by those SoCs then the work can stop there
10:37 < horms> or it can keep going if there is some reason to
10:37 < geertu> Fine for me. But please drop the reference to SH?
10:38 < horms> Sure, can do
10:38 < horms> sorry for the confusion that generated
10:38 < geertu> NP
10:38 < horms> shall we move to c.?
10:39 < geertu> Subtopic b. serial0:115200n8
10:39 < horms> See: http://www.spinics.net/lists/linux-sh/msg46481.html
10:39 < horms> I'm inclinded to not add :115200n8. But I'd value your opinion.
10:40 < geertu> As DT describes "the hardware" (chosen describes configuration), I don't mind adding it.
10:40 < geertu> There's plenty of opportunity to fix this for v4.5
10:40 < horms> sure, that sounds reasonable
10:40 < horms> but what about earlycon. do we care? can it be compatibile?
10:41 < geertu> As the standard console parses stdout-patch correctly, I think earlycon should follow suit
10:41 < horms> ok, thats reasonable
10:41 < dammsan> sounds reasonable
10:41 < geertu> I'm still a bit puzzled by earlycon on arm32.
10:41 < geertu> Apparently it works on some platforms.
10:41 < horms> i'll see about adding :115200n8 to v13
10:41 < horms> what about gen2. do you want to talk about that?
10:41 < geertu> yes
10:41 < horms> s/gen2/32-bit arm/
10:42 < geertu> Earlycon is very valuable: it's intended to replace debug_ll ,which does not exist anymore on arm64
10:42 < horms> so i'm ok with updating our 32-bit SoCs. but is there a backwards compatibility issue?
10:42 < geertu> It helped me a lot debugging the L1_CACHE_BYTES issue on Salvator-X
10:42 < dammsan> i agree that early output is very valuable
10:42 < horms> i definately don't want to stand in the way of making useful tools work :)
10:42 < geertu> I don't see a backwards compatibility issue
10:43 < horms> ok, shall we move forwards on the 32-bit side too?
10:43 < geertu> For arm32, I think we need a "JTAG expert" to look into it
10:43 < horms> earlycon?
10:43 < geertu> yes
10:43 < horms> ok, but that is orthogonal to your proposed dts change, right?
10:44 < geertu> yes.
10:44 < horms> ok, got it. feel free to send that patch any time. if its rough i can clean it up.
10:44 < geertu> earlycon does an early mapping of the serial port. Apparently it maps something (no crash), but nothing is output on the serial potty
10:44 < geertu> s/potty/poty/
10:44 < geertu> s/potty/port/
10:44 < horms> with regards to jtag, perhaps morimoto-san could help out?
10:44 < geertu> or Ulrich?
10:45 < uli___> what exactly is the issue there?
10:46 < geertu> earlycon doesn't output anything on R-Car Gen2 (and other "shmobile", IIRC)
10:46 < dammsan> we had a different implementation for non-multiplatform earlier
10:46 < geertu> Until recently, it didn't work at all, as arm32 didn't have early fixmap support
10:46 < geertu> earlyprintk?
10:46 < dammsan> yeah
10:47 < uli___> ah, i see.  i remember using that, so i was wondering...
10:47 < uli___> which platforms are known to be broken?
10:47 < uli___> boards, i mean
10:47 < dammsan> all?
10:47 < pinchartl> do we need earlycon or is earlyprintk enough ?
10:47 < geertu> earlycon is platform-agnostic
10:48 < dammsan> earlyprintk used to be compatibile with SH
10:48 < geertu> and The Way Forward(tm)
10:48 < geertu> I think it's also "more early" than earlyprintk
10:48 < dammsan> but then earlycon came around =)
10:48 < horms> why use something that works when you can invent something new to spend years fixing?
10:48 < geertu> On last renesas-drivers, applying Sata-san's SCIF EARLYCON patch should give you working earlycon on Salvator-X
10:48 < geertu> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364178.html
10:49 < pinchartl> which of the two is the one that requires the assembly header with a couple of serial port functions ?
10:49 < geertu> debug_ll, which is something different
10:49 < geertu> no more debug_ll in arm64
10:49 < geertu> earlycon uses chosen/stdout-path
10:49 < geertu> so it's compatible with real multi-platform kernels and multi-plaform debugging
10:50 < dammsan> good
10:50 < geertu> So you have debug_ll, earlyprintk, and and earlycon
10:50 < pinchartl> ok
10:50 < pinchartl> sounds so simple :-)
10:50 < geertu> Going from most-platform dependent to platform-agnostic
10:50 < geertu> s/Sata-san/Sato-san/ (forgive today's typing)
10:51 < geertu> Just add "earlycon" to the kernel command line, and you get early debugging output on about everything 
10:52 < dammsan> nice
10:52 < geertu> well, that's the  idea
10:52 < dammsan> i suppose we need clocks relatively earl then
10:52 < dammsan> or maybe we can make assumptions
10:52 < horms> Nice, we can add it to dt and be back to where we were with earlyprintk on our 32-bit SoCs before DT came along :)
10:52 < geertu> No, it still depends on the bootloader to set up the serial port
10:53 < dammsan> gotcha
10:53 < geertu> But selection of the serial port is now done in "the same way" as the regular serial console
10:53 < geertu> i.e. chosen/stdout-path
10:54 < pinchartl> geertu: how is the serial port driver involved in earlycon ?
10:54 < morimoto`> (dammsan goes to other Renesas meeting)
10:54 < pinchartl> tell me there's no early platform device...
10:55 < geertu> OF_EARLYCON_DECLARE
10:55 < pinchartl> I should have guessed that :-/
10:55 < geertu> https://progressive-comp.com/?l=linux-sh&m=143366932126892&w=2
10:57 < geertu> Subtopic c. GIC/GICH/GICV
10:57 < horms> BTW, do you know who Sato-san is?
10:58 < geertu> The h8300 guy
10:58 < horms> c. is here http://www.spinics.net/lists/arm-kernel/msg457615.html
10:58 < horms> ok, makes sense
10:58 < geertu> who's using earlycon on h8 ;-)
10:58 < geertu> back where it all started?
10:58 < horms> so regarding GIC
10:58 < horms> do we need to do anything?
10:59 < geertu> Are the virtualiation regs documented in later versions (>0.5) of the datasheet?
10:59 < horms> I'm unsure. Shall we speculate and check later?
11:00 < horms> perhaps morimoto-san` or shimoda-san know
11:01 < shimoda> i greped the datasheet of rev0.5, "virtualization" is only in overview section
11:01 < shimoda> it is a function of CA57
11:02 < shimoda> so, i guess it is described in a documentation of ARM
11:02 < geertu> But the actual addresses of the register banks of the GIC are SoC-specific, right?
11:02 < geertu> And the Gen3 datasheet only describes banks 1 and 2
11:05 < shimoda> which page does it described?
11:05 < shimoda> about the bank
11:05 < geertu> 12A3
11:06 < geertu> 533
11:07 < geertu> INTC-AP H'F102 0000 √ √
11:07 < geertu> H'F101 0000 √ √
11:07 < geertu> CPU-IF
11:07 < geertu> INTC-AP
11:07 < geertu> ar
11:07 < geertu> Distributor-IF
11:07 < geertu> Someone edited the table, so Copy-'n-paste no longer grabs the cells in the "normal" order
11:08 < shimoda> thank you, I found it
11:10 < shimoda> and these CPU-IF and Distributor-IF are written into r8a7795.dtsi
11:11 < morimoto`> geertu: sorry what is your question/concern ? it should have more information ?
11:11 -!- shimoda [~shimoda@relprex2.renesas.com] has quit [Quit: WeeChat 0.4.2]
11:11 < geertu> Documentation/devicetree/bindings/arm/gic.txt
11:12 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi
11:12 < geertu> GIC virtualization extensions (VGIC) means 2 more register bankds
11:12 < geertu> s/bankds/banks/
11:12 < geertu> Documentation/devicetree/bindings/arm/gic.txt
11:15 < morimoto`> Does your question is that it should have bank 3, and 4 ?
11:17 < geertu> Yes, according to Mark Rutland
11:17 < geertu> Unless the H3 GIC doesn't have virtualization extensions, of course ;-)
11:18 < horms> do we also need to know the maintenance irq?
11:18 < geertu> I think so
11:19 < morimoto`> Actually, today we got errata sheet, and I checked it now. but it doesn't include this.
11:19 < morimoto`> So, I will ask to HW/Manual guys
11:19 < horms> thanks
11:20 < horms> it seems to me that we re blocking on this one
11:20 < geertu> yes
11:20 < horms> geertu is that your understanding?
11:20 < geertu> thanks for asking
11:20 < horms> ok
11:20 < morimoto`> Can I confirm ? bank 3/4 are because of 4 cpu ?
11:20 < geertu> so let's leave the dtsi like it is for now
11:20 < horms> i will likely not post v13 in the near future
11:20 < geertu> morimoto: no, because of virtualization extensions
11:20 < horms> unless there is a pressing need for it
11:21 < geertu> subtopic d. Gen2 integration
11:21 < morimoto`> OK, I see. thanks
11:21 < horms> ok, this i think we sould not spend much time on
11:21 < horms> I expect that in general it will be a topic that would be well named after a book I recently purchased "Argument Without End".
11:22 < horms> The quick summary is that Magnus has asked me to make sure we have more uniform coverage on the integration side for our various (32-bit) socs
11:22 < horms> I have started by focusing on R-Car Gen 2
11:22 < horms> and the thermal patch I sent earlier today is the first cab of the rank
11:23 < horms> in short lager and koelsch seem to be in pretty good shape
11:23 < horms> but it gets much thinner on the ground when looking at the other SoCs and boards
11:23 < geertu> It would be good if we could "share" more dtsis
11:24 < horms> yes, its quite repeditive
11:25 < horms> but the current dts files distinguish between the different socs in terms of defines (easy to resolve I suppose) and per-soc bindings (see title of book above!)
11:25 < horms> perhaps the dts files can be generated some how
11:26 < horms> anyway, i just wanted to mention i'm putting some energy into that
11:26 < geertu> Having more docs (incl. schematics) could help, too.
11:26 < pinchartl> horms: I'll refrain to comment on that last point :-)
11:27 < geertu> I can just guess that e.g. goose is similar to koelsch
11:27 < horms> i managed to get docs from morimoto-san earlier today
11:27 < horms> so i am guessing less now
11:27 < horms> there is also the gen2 bsp
11:28 < geertu> OK
11:28 < horms> in any case, i suggest we move on and come back to this another time: its likely to be around for a while and its very non-urgent
11:28 < geertu> We're running out of time. Can we continue
11:28 < geertu> ok
11:28 < geertu> Topic 3. Status check for tasks from last meeting - what is remaining?
11:29 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list
11:29 < geertu> Done:
11:29 < geertu>         pfc,v4.4,Add r8a7795 support
11:29 < geertu>         r8a7795,v4.4,Add gpio nodes to DT
11:29 < geertu> Ack's wanted:
11:29 < geertu> pfc,v4.4,Improve documentation
11:29 < geertu> (and a few more pfc patches)
11:30 < geertu> Now Simon is here: generic,v4.4,Propose API to obtain mode pin values in a generic way
11:31 < horms> yes, i think the main issue there is how to handle initcalls (or not)
11:34 < horms> http://www.spinics.net/lists/linux-sh/msg46246.html
11:34 < horms> From my pov the *_OF_DECLARE approach seems to give the cleanest code
11:34 < pinchartl> horms: I agree with you
11:35 < pinchartl> I dislike *_OF_DECLARE though
11:35 < pinchartl> as it's an initcall-like hack
11:35 < pinchartl> but I don't have a better solution at the moment
11:35 < geertu> And the person who encounters dependency issues has to fix it herself?
11:35 < horms> right, it seems to be faustian pact
11:36 < horms> the other approach was to allow users to directly initialse things if they are running before initcalls would have kicked in
11:36 < horms> its not so clean code
11:36 < horms> but its probably harder to get wrong
11:36 < horms> for gen2 the initcall bit might be omitted entirely
11:37 < horms> unless we figure out a way that it doesn't need the modepin before initcalls
11:37 < horms> are run
11:38 < geertu> OK, let's post it to a broader audience for discussion
11:38 < geertu> Or is that a bad idea during the merge window?
11:38 < horms> i don't see any problem with posting RFCs during the merge window
11:38 < horms> do you mean that I should see linux-arm-kernel?
11:39 < geertu> And if we delay, it may be too late for v4.5
11:39 < geertu> linux-arm-kernel and linux-kernel
11:39 < horms> ok
11:39 < geertu> perhaps Jon Corbet too, so it ends up on lwn.net?
11:39 < horms> i'll fix up the obvious problems with v1 but not convert it to *_OF_DECLARE
11:40 < horms> and probably add some text about *_OF_DECLARE being a possibility
11:40 < horms> perhaps if its going to lkml then wating for rc1 would be prudent
11:40 < horms> we don't want it to get shot down before is even been thought about
11:40 < geertu> Clearly mark it RFC
11:41 < horms> ok
11:41 < geertu> People don't (ordinarily) read lkml anyway
11:41 < horms> true
11:41 < horms> pinchartl: is the above reasonable from your pov?
11:42 < horms> I guess if its not he can ping me :)
11:43 < pinchartl> yes it's fine
11:43 < horms> thanks
11:43 < pinchartl> maybe you could mention *_OF_DECLARE as an option in the cover letter ?
11:43 < horms> btw, I would not be upset if you wanted to take your baby back under your wing :)
11:43 < horms> yes, that is what I had in mind
11:43 < pinchartl> I wish I had time to do that :-)
11:44 < horms> (does anyone read cover letters?)
11:44 < horms> understood. its an open offer
11:44 < pinchartl> thanks :-)
11:44 < horms> ok, i think we can move on
11:44 < horms> sorry for pushing things over time
11:44 < geertu> Any other topics?
11:45 < horms> not from me
11:45 < geertu> I have: [Linux Kernel development - Feature #XX] emails
11:45 < geertu> So yes, I'm receiving them
11:46 < horms> Was ist das?
11:46 < shimoda> geertu: not from me
11:46  * uli___ checks the universal translator switches
11:47 < geertu> uli: Don't speak German anymore?
11:47 < geertu> They are sent by oss-admin@lm.renesas.com
11:48 < horms> ok. do they relate to the todo lists, redmine, or something else?
11:48 < geertu> From Redmine. Am I the only one who's receiving them?
11:48 < horms> (obviously I haven't seen one)
11:48 < uli___> me neither
11:48 < pinchartl> neither have I
11:48 < geertu> OK, will forward one to periperi
11:49 < horms> good idea
11:49 < horms> i tweaked periperi so mainlan no longer enforces a message size limit
11:50 < horms> As magnus kept hitting it.
11:50 < horms> But the mail server istelf still has a limit, somwhere between 10 & 20Mb iirc
11:50 < horms> fwiw, gmail has a similar message size limit
11:53 < geertu> I guess that's why I haven't received new datasheets? ;-)
11:53 < geertu> No more topics?
11:53 < horms> I don't think it is related
11:53 < morimoto`> I got errata sheet form manual guys. do you want to have it ?
11:54 < morimoto`> for v0.5 datasheet
11:54 < geertu> yes please
11:54 < pinchartl> yes please !
11:54 < shimoda> I heard  new datasheet will come at early next year, I'm surprized
11:54 < morimoto`> OK. I will Me -> Jinso -> EuroPeri
11:54 < morimoto`> s/I/It/g
11:55 < morimoto`> and it will happen next week.
11:56 < geertu> thx!
11:56 < horms> likewise
11:57 < morimoto`> No more topic from me
11:57 < geertu> ok, then we're finished.
11:57 < geertu> Thanks for joining!