diff options
Diffstat (limited to 'wiki/Chat_log/20151106-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20151106-core-chatlog | 389 |
1 files changed, 389 insertions, 0 deletions
diff --git a/wiki/Chat_log/20151106-core-chatlog b/wiki/Chat_log/20151106-core-chatlog new file mode 100644 index 0000000..d3ad5ad --- /dev/null +++ b/wiki/Chat_log/20151106-core-chatlog @@ -0,0 +1,389 @@ +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! |