diff options
Diffstat (limited to 'wiki/Chat_log/20150914-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20150914-core-chatlog | 464 |
1 files changed, 464 insertions, 0 deletions
diff --git a/wiki/Chat_log/20150914-core-chatlog b/wiki/Chat_log/20150914-core-chatlog new file mode 100644 index 0000000..f0242cd --- /dev/null +++ b/wiki/Chat_log/20150914-core-chatlog @@ -0,0 +1,464 @@ +11:03 #periperi: < geertu> Welcome to the Core Group Chat! +11:03 -!- Irssi: Pasting 6 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +11:03 #periperi: < geertu> Agenda: +11:03 #periperi: < geertu> 1. Upcoming Gen3 development for the Core group, +11:03 #periperi: < geertu> 2. Pinctrl submaintenance, +11:03 #periperi: < geertu> 3. DMA topology, +11:03 #periperi: < geertu> 4. CPG and boot mode via syscon (or not), +11:03 #periperi: < geertu> 5. Status check for tasks from last meeting - what is remaining? +11:03 #periperi: < geertu> Topic 1: Upcoming Gen3 development for the Core group, +11:04 #periperi: < dammsan> for myself on my immediate todo i have CPG and IRQC +11:05 #periperi: < geertu> About CPG, I talked to mturquette on IRC +11:05 #periperi: < geertu> He's not on holodays, but "ignoring mailing lists during the merge window" +11:05 #periperi: < geertu> He promised to look into our patches and emails this week. +11:05 #periperi: < dammsan> sweet +11:05 #periperi: < dammsan> thanks +11:05 #periperi: < geertu> s/holodays/holidays/ +11:06 #periperi: < pinchartl> I can get hold of him next week at Linaro Connect if needed +11:06 #periperi: < geertu> Next week is Japanese holidays, too? +11:06 #periperi: < dammsan> yep +11:06 #periperi: < dammsan> i intend to bang my head against CPG later today +11:06 #periperi: < dammsan> have some ideas about how to improve the situation +11:07 #periperi: < dammsan> i will try to avoid updating the integration series this week +11:07 #periperi: < dammsan> unless it turns out to be necessary due to CPG dependencies +11:07 #periperi: < dammsan> seems ok? +11:08 #periperi: < geertu> looks fine, thanks +11:08 #periperi: < dammsan> pinchartl: checking with him face-to-face sounds good +11:08 #periperi: < dammsan> some sort of IRL prod +11:08 #periperi: < geertu> IRQC is used for PMIC only? +11:08 #periperi: < pinchartl> please update me at the end of the week and I'll make sure to check with him next week +11:09 #periperi: < dammsan> pincharl: will put "notify laurent about CPG" in my calendar +11:09 #periperi: < geertu> PMIC is BD9571MWV-M, no driver yet. +11:09 #periperi: < pinchartl> and no datasheet yet ? +11:09 #periperi: < dammsan> i've seen the cover page of the data sheet at some guys desk +11:09 #periperi: < dammsan> it says "PMIC for R-Car Gen3" =) +11:09 #periperi: < geertu> IRQ1n is available on EXIO-D though (QSE 8mm, cfr. Koelsch) +11:09 #periperi: < dammsan> seems like a custom chip +11:10 #periperi: < dammsan> right +11:10 #periperi: < dammsan> i've been wanting to get a bunch of those +11:10 #periperi: < dammsan> sorry for not managing that so far +11:11 #periperi: < dammsan> will put QSE adapter into my calendar on the 28th +11:11 #periperi: < dammsan> before that it is paper work hell including new task lists +11:11 #periperi: < shimoda> about PMIC datasheet, since ROHM needs an export control, we cannot send the datasheet for now +11:12 #periperi: < dammsan> another paper work hell =) +11:12 #periperi: < pinchartl> any estimate regarding when the datasheet will be available ? +11:12 #periperi: < geertu> But our IRQC developer who needs a way to trigger an IRQ is in Japan, right? +11:13 #periperi: < dammsan> yes i think so +11:13 #periperi: < shimoda> pinchartl: sorry I don't know when +11:13 #periperi: < dammsan> also, i'm not 100% sure if it makes sense for linux to support the PMIC +11:13 #periperi: < dammsan> with secure mode, trusted firmware, PSCI and virtualization +11:14 #periperi: < dammsan> but we need external interrupts for sure =) +11:15 #periperi: < dammsan> i intend to play with IPMMU early next month too +11:15 #periperi: < dammsan> but we most likely have a core group meeting before that +11:16 #periperi: < dammsan> everyone else is blocked on lack of physical hardware? +11:16 #periperi: < geertu> or confirmation of datasheets +11:17 #periperi: < geertu> E.g. SCIF DMA RX MID/RID don't work. +11:17 #periperi: < dammsan> right +11:17 #periperi: < pinchartl> no real blocker on my side for now +11:17 #periperi: < dammsan> i would like us to describe the SCIF clocks in more detail in DT if possible +11:17 #periperi: < pinchartl> (it's multimedia only this month as far as I'm concerned anyway) +11:17 #periperi: < dammsan> are we blocked on docs for that too? +11:17 #periperi: < geertu> Like the SCIF_CLK for the BRG? +11:17 #periperi: < geertu> No, not blocked. +11:18 #periperi: < dammsan> yeah, and i'm not sure if there are more clocks too +11:18 #periperi: < geertu> On my list, after SCIF DMA, which I'm working on again/ +11:18 #periperi: < dammsan> excellent +11:18 #periperi: < dammsan> thanks +11:18 #periperi: < pinchartl> SCIF clocks are a bit messed up in DT +11:18 #periperi: < pinchartl> the sci_ick name isn't right +11:18 #periperi: < dammsan> i recall an external SCIF clock on salvator-x +11:18 #periperi: < geertu> Yes, that's for external BRG +11:19 #periperi: < geertu> Same on Koelsch +11:19 #periperi: < pinchartl> I think I have patches for that, let me check +11:19 #periperi: < pinchartl> no, not for the external clock +11:20 #periperi: < pinchartl> but I have a patch that drops the interface clock from the driver +11:20 #periperi: < geertu> THat's a cleanup +11:20 #periperi: < pinchartl> yes +11:20 #periperi: < pinchartl> it breaks DT though as it renames the clock +11:20 #periperi: < pinchartl> but it won't be difficult to add backward compatibility code +11:21 #periperi: < dammsan> maybe we should try to do Gen3 correctly from the start? +11:21 #periperi: < dammsan> whatever that is =) +11:21 #periperi: < pinchartl> yes :-) +11:21 #periperi: < pinchartl> should I rebase the patches and send them ? +11:22 #periperi: < geertu> Yes please +11:22 #periperi: < pinchartl> and let someone take care of backward compatibility ? :-) +11:22 #periperi: < dammsan> can we handle that per-SoC? +11:22 #periperi: < geertu> That complicates the driver +11:22 #periperi: < dammsan> yes, so does DT =) +11:22 #periperi: < geertu> Backwards compatibility is already enough code +11:23 #periperi: < pinchartl> I don't see a need to handle that per-soc +11:23 #periperi: < geertu> Actually this is I/O Group work. right? ;-) +11:23 #periperi: < dammsan> ok, if we can avoid breakage +11:23 #periperi: < dammsan> yes +11:23 #periperi: < pinchartl> indeed +11:23 #periperi: < geertu> Any other upcoming core work? +11:24 #periperi: < dammsan> not from my side +11:24 #periperi: < geertu> THat's a cleanupTopic 2: Pinctrl submaintenance +11:24 #periperi: < horms> perhaps pfc for avb is core work +11:24 #periperi: < geertu> Topic 2: Pinctrl submaintenance +11:24 #periperi: < horms> it seems trivial enough +11:24 #periperi: < horms> i'll try an spin a patch this week +11:24 #periperi: < geertu> the initial pfc patch may have support for it. +11:24 #periperi: < horms> i certainly have a patch that includes it +11:25 #periperi: < geertu> easy +11:25 #periperi: < horms> probably the original public version did too +11:25 #periperi: < horms> i expect the only challange to be my own familiarity with the code +11:25 #periperi: < dammsan> so did you guys figure out who will funnel the code to linusw? +11:25 #periperi: < horms> lets move to topic 2 +11:26 #periperi: < horms> i thought we decided to decide that here :) +11:26 #periperi: < dammsan> right, and i thought we were on 2 already =) +11:26 #periperi: < geertu> As I have topic/r8a7795-pfc-v2, I can take care of that +11:26 #periperi: < geertu> It would be good to have some acks from the maintainer, though +11:26 #periperi: < dammsan> do you need review help? +11:27 #periperi: < dammsan> anything in particular that needs attention i mean? +11:27 #periperi: < geertu> I reviewed most of the incremental patches +11:27 #periperi: < pinchartl> I won't have time to review the data table patches in the near future I'm afraid +11:27 #periperi: < geertu> The initial set seems to work. +11:28 #periperi: < geertu> So I would focus on the incrementals +11:28 #periperi: < pinchartl> in order of decreasing importance, we need to pay attention during review to +11:28 #periperi: < pinchartl> 1. core PFC changes +11:28 #periperi: < geertu> And on questions about macro use (PINMUX_IPSR_NOGP()?) +11:28 #periperi: < pinchartl> 2. functions and groups lists +11:28 #periperi: < pinchartl> 3. data tables +11:28 #periperi: < pinchartl> the second one is part of the DT ABI +11:29 #periperi: < geertu> yep +11:29 #periperi: < dammsan> but we have local acks for most bits right? +11:30 #periperi: < horms> are there also non-gen3 patches floating around. e.g. from Sergei? +11:30 #periperi: < geertu> yes +11:30 #periperi: < geertu> and two bug fixes from me +11:30 #periperi: < horms> ok +11:31 #periperi: < horms> so are you proposing as acting as a submaintainer for all of sh-pfc? (that would be quite fine imho) +11:31 #periperi: < geertu> I can collect gen3 patches and send a PR later, but I would prefer for non-gen3 patches to go through LinusW directly +11:31 #periperi: < dammsan> so schedule wise for the CPG, when do we predict merge to happen? +11:31 #periperi: < dammsan> err s/CPG/PFC/g +11:31 #periperi: < dammsan> PFC for H3 seems quite stable to me +11:32 #periperi: < geertu> Let's say in two weeks (-rc3)? +11:32 #periperi: < dammsan> but i may be way off +11:32 #periperi: < geertu> directly => ack from Laurent, though +11:32 #periperi: < horms> geertu: that would be fine from my pov if Linus is happy with that. But he seemed to ask for a single point of contact for all renesas pfc work +11:32 #periperi: < pinchartl> I think Linus would like us to submaintain all PFC-related patches +11:32 #periperi: < pinchartl> not just the Gen3 patches +11:32 #periperi: < dammsan> geertu: -rc3 or so sounds good +11:33 #periperi: < geertu> OK, then I'll take all +11:33 #periperi: < dammsan> thanks Geert!! +11:33 #periperi: < horms> thanks! +11:34 #periperi: < shimoda> thanks! +11:34 #periperi: < horms> I think it would be best if you explained that to Linus, so he knows what is going on: And Sergei does too +11:34 #periperi: < dammsan> feel free to delegate review work! +11:34 #periperi: < geertu> pinchartl: Is this temporary, or should we update MAINTAINTERS? +11:35 #periperi: < pinchartl> it can be temporary +11:35 #periperi: < pinchartl> depending on what Magnus decides to put on my plate for the future :-) +11:35 #periperi: < morimoto> geertu: what does your "two bug fixes" mean? I know v1 lack 0xF IPSRx macro, but what is 2nd ? +11:36 #periperi: < geertu> bug fixes for non-gen3 +11:36 #periperi: < geertu> [PATCH] pinctrl: sh-pfc: r8a7791/r8a7793: Correct SCIFB1_B SCK MOD_SEL value +11:37 #periperi: < geertu> [PATCH] pinctrl: sh-pfc: r8a7794: Remove bogus SCIF0 SCK pin data +11:37 #periperi: < morimoto> Ahh, OK thanks +11:37 #periperi: < geertu> For gen3 there's also [PATCH 1/2] [RFC] pinctrl: sh-pfc: r8a7795: Add pinmux data for single-function pins +11:37 #periperi: < geertu> waiting for PINMUX_IPSR_NOGP() feedback +11:38 #periperi: < dammsan> pinchartl: i believe future PFC work will go though the core group +11:39 #periperi: < pinchartl> dammsan: I'm part of the core group. it depends on whether you'd like me to work on PFC or not +11:39 #periperi: < morimoto> geertu: waiting feedback from whom ? +11:39 #periperi: < geertu> E.g. the shmobile pintrl maintainer? ;-) +11:39 #periperi: < morimoto> OK, I see +11:40 #periperi: < pinchartl> :-) +11:40 #periperi: < pinchartl> which patch in particular ? +11:40 #periperi: < geertu> r8a7795: Add pinmux data for single-function pins +11:40 #periperi: < geertu> thx! +11:41 #periperi: < dammsan> pinchartl: it seems that your main focus in on multimedia these days, but we of course want some low-bandwidth help with the core stuff too +11:41 #periperi: < dammsan> in the end it much depends on what you like doing +11:41 #periperi: < dammsan> but we can discuss that some other time =) +11:42 #periperi: < pinchartl> dammsan: I'm fine maintaining the PFC driver if you're fine allocating time for the task :-) +11:42 #periperi: < pinchartl> sure +11:42 #periperi: < pinchartl> so let's not modify MAINTAINERS right now +11:42 #periperi: < pinchartl> "Adding some comments to the PINMUX_*() macros would be helpful..." +11:42 #periperi: < pinchartl> I agree with that +11:43 #periperi: < pinchartl> how about documenting the macros first, then it should be straightforward to know which one to use +11:43 #periperi: < pinchartl> _NOGP is used on r8a7778 only +11:44 #periperi: < dammsan> so who can help out with the documentation then? +11:46 #periperi: < pinchartl> (same for _NOGM) +11:46 #periperi: < pinchartl> I don't even remember what _NOGM means :-) +11:46 #periperi: * geertu thought it was just him... +11:47 #periperi: < geertu> Authored by Morimoto-san? +11:47 #periperi: < pinchartl> I'm sure we have pins without a GPIO function on other SoCs than R8A7778 +11:47 #periperi: < geertu> Task added: pfc,v4.4,Improvement documentation +11:47 #periperi: < geertu> Next topic? +11:48 #periperi: < geertu> Topic 3: DMA topology +11:48 #periperi: < geertu> We wanted to discuss this before, but Laurent was not available. +11:48 #periperi: < geertu> This is mostly about having multiple DMACs +11:49 #periperi: < geertu> On Gen2, all SYS-DMAC slaves can use both DMAC0 or DMAC1, but currently DT links them to a single instance only. +11:49 #periperi: < geertu> On Gen3, some SYS-DMAC slaves can work with DMAC0, others with DMAC1 or DMAC2. +11:49 #periperi: < geertu> So far we linked the ones from the second group to DMAC1 only. +11:50 #periperi: < pinchartl> right +11:50 #periperi: < geertu> I tried multiple dmas and dma-names for both "tx" and "rx", and it seems to work (it uses the first DMAC that's available). +11:50 #periperi: < geertu> That was on Gen2 though. +11:51 #periperi: < geertu> On Gen3, MSIOF doesn't seem to work with DMAC2 +11:51 #periperi: < pinchartl> there's a problem in the DMA engine API +11:51 #periperi: < pinchartl> drivers allocate channels too early +11:51 #periperi: < pinchartl> there's no efficient management of DMA channels at runtime +11:52 #periperi: < geertu> E.g. SCIF allocates channels at device (/dev/ttySC*) open time. +11:52 #periperi: < pinchartl> one option would be to allocate the channel only when starting transfers, but that would add an overhead +11:52 #periperi: < geertu> E.g. RSPI and MSIOF allocate them at probe time. +11:52 #periperi: < pinchartl> probe time is early +11:53 #periperi: < geertu> So SCIF supports some dynamic behavior. +11:53 #periperi: < pinchartl> but most drivers don't have a concept of open/close +11:53 #periperi: < pinchartl> especially I2C and SPI +11:53 #periperi: < pinchartl> so that's a core issue we'll need to tackle +11:54 #periperi: < pinchartl> it should be, in theory, independent from DMA description in DT +11:54 #periperi: < geertu> When I added "DMA topology" on the agenda originally, I didn't know yet that MSIOF doesn't work with DMAC2 on Gen3. +11:54 #periperi: < dammsan> geertu: that may be a hardware bug +11:54 #periperi: < geertu> So it may be premature. +11:55 #periperi: < pinchartl> listing all usable channels is one way to go +11:55 #periperi: < pinchartl> it makes DT quite verbose +11:55 #periperi: < pinchartl> but it shouldn't be too bad for Gen2 and Gen3 +11:55 #periperi: < dammsan> pinchartl: you mean in each DMAC DT node? +11:55 #periperi: < geertu> Is DMAC2 "special"? +11:55 #periperi: < geertu> In each slave node +11:55 #periperi: < pinchartl> no I mean in the DMA slave DT nodes +11:56 #periperi: < pinchartl> SCIF, RSPI, MSIOF, ... +11:56 #periperi: < geertu> That would describe the hardware. +11:56 #periperi: < geertu> Especially on Gen3, where you have pairing limits +11:56 #periperi: < geertu> How the software handles that is a different thing, and the complexity seems to lie in the software. +11:57 #periperi: < dammsan> geertu: your DMAC2 issues (or pairing issues) come from real life experience, or from the docs? +11:57 #periperi: < geertu> The DMAC2 issue with MSIOF was on Salvator-X +11:57 #periperi: < geertu> But the doc states which slaves work with DMAC0 (ch 0-15), and which with DMAC1/2 (ch 16-47) +11:57 #periperi: < dammsan> right, but that is a mismatch with the data sheet? +11:58 #periperi: < geertu> With "pairing limits", I meant the line above. +11:58 #periperi: < dammsan> so do we need to feedback something to the hardware guys? +11:58 #periperi: < geertu> I don't know, I haven't tried other DMA slaves. +11:59 #periperi: < geertu> with DMAC2, I mean +11:59 #periperi: < dammsan> ok, perhaps we need to tackle DMA on Gen3 as a separate topic later on +11:59 #periperi: < dammsan> independently of the DMA topology discussion +11:59 #periperi: < geertu> Yes, cfr. "[PATCH] [RFC] arm64: renesas: r8a7795: Complete SYS-DMAC nodes" continuation on periperi mailing list +11:59 #periperi: < dammsan> my assumption has been that Gen3 is not very different from Gen2 +12:00 #periperi: < geertu> Shall we add dmas for all DMACs from now on? +12:00 #periperi: < geertu> And also on Gen2? +12:00 #periperi: < geertu> Or be conservative? +12:01 #periperi: < dammsan> i think starting with Gen3 makes sense +12:01 #periperi: < dammsan> and waiting with Gen2 +12:01 #periperi: < geertu> On Gen2, we have some slaves pointing to DMAC0, and others to DMAC1 +12:01 #periperi: < dammsan> in case we run into issues then we can most likely get support for Gen3 +12:01 #periperi: < geertu> but that's completely arbitrary +12:01 #periperi: < dammsan> I dont think we can get same support level on Gen2 +12:01 #periperi: < dammsan> morimoto: what do you think? +12:02 #periperi: < dammsan> shimoda: what do you think? +12:02 #periperi: < geertu> morimoto-san is too busy with cs2000 ;-) +12:02 #periperi: < dammsan> can we get good support from the hardware guys for Gen2? +12:02 #periperi: < morimoto> about DMAC ? +12:02 #periperi: < dammsan> yeah +12:03 #periperi: < dammsan> i got the impression that everyone was focused on gen3 now so no one cares about gen2 +12:05 #periperi: < morimoto> Oops, do you want HW guys support ? +12:05 #periperi: < morimoto> Sorry what is your request now ? +12:05 #periperi: < dammsan> i want to ask you if you think we have good chance to get Gen2 support +12:06 #periperi: < dammsan> or if you think Gen3 has better chance for support from hardware guys? +12:07 #periperi: < geertu> Do we have Gen2 DMA issues, besides IPMMU? +12:07 #periperi: < shimoda> sorry I don't understand yet. who is the hardware guys? +12:08 #periperi: < dammsan> shimoda: people inside renesas that can answer our questions about DMA hardware for Gen2/Gen3 +12:08 #periperi: < dammsan> geertu: not that i am aware of +12:08 #periperi: < morimoto> I need to check DMA HW guy, but maybe we can ask them (?) +12:08 #periperi: < dammsan> morimoto: so Gen3 and Gen2 is same status? +12:09 #periperi: < morimoto> I don't know at this point +12:09 #periperi: < dammsan> ok, so it is not the same as MSIOF where hardware developer had quit =) +12:09 #periperi: < dammsan> anyway +12:10 #periperi: < dammsan> geertu: what do you think about DMAC DT nodes on Gen2 and/or Gen3? +12:10 #periperi: < geertu> I'd like to link slaves to all DMA engines that can handle it. +12:10 #periperi: < dammsan> i like that +12:11 #periperi: < geertu> As that descrives the hardware. +12:11 #periperi: < dammsan> right +12:11 #periperi: < pinchartl> I'm fine with that +12:11 #periperi: < geertu> My only issue there is DMAC2 +12:11 #periperi: < dammsan> why don't you begin on a board that you have physical access to? +12:11 #periperi: < pinchartl> we have at most two DMACs used by a peripheral, so it's not too bad +12:11 #periperi: < pinchartl> if we had 10 RIDs * 10 DMACs I'd start getting worried +12:12 #periperi: < dammsan> geertu: so what is the latest status about that DMAC2 issue? +12:12 #periperi: < geertu> Isn't that the audio DT? ;-) +12:12 #periperi: < dammsan> we may have to ping something...? +12:12 #periperi: < geertu> I'm afraid DMAC2 is "special", but not documented that way +12:12 #periperi: < geertu> dmac0: dma-controller@e6700000 +12:12 #periperi: < geertu> dmac1: dma-controller@e7300000 +12:12 #periperi: < geertu> dmac2: dma-controller@e7310000 +12:12 #periperi: < geertu> Weird addresses... +12:13 #periperi: < geertu> + DMAC2 didn't work with MSIOF +12:13 #periperi: < dammsan> right +12:13 #periperi: < pinchartl> does DMAC2 work with other peripherals ? +12:13 #periperi: < dammsan> i saw that you sent an email +12:13 #periperi: < geertu> I'll try hscif1 transmit with DMAC2 +12:13 #periperi: < dammsan> but we need to make sure it gets reported +12:13 #periperi: < dammsan> can you forward the report email to periperi once more? +12:14 #periperi: < geertu> Will do, after I've tried hscif2 +12:14 #periperi: < dammsan> thanks! +12:14 #periperi: < dammsan> can you add a task for DMAC2 on Gen3? +12:14 #periperi: < geertu> Will do +12:15 #periperi: < dammsan> thanks!! +12:15 #periperi: < geertu> r8a779[0-4],v4.5,Start adding dmas for all SYS-DMAC engines +12:15 #periperi: < geertu> r8a7795,v4.4,Investigate SYS-DMAC2 +12:16 #periperi: < dammsan> wunderschon +12:16 #periperi: < geertu> Next topic? +12:16 #periperi: < geertu> Topic 4: CPG and boot mode via syscon (or not) +12:16 #periperi: < morimoto> about DMAC we got request from customer +12:16 #periperi: < morimoto> previous BSP used sh-dmac, and customer got many issues. +12:16 #periperi: < dammsan> really? =) +12:17 #periperi: < morimoto> Current BSP is using rcar-dmac, but customer still have issues. +12:17 #periperi: < morimoto> So, customer requesting to us to re-review about rcar-dmac +12:17 #periperi: < dammsan> morimoto: Current BSP = 3.10 ? +12:17 #periperi: < morimoto> it seems 3.10 +12:17 #periperi: < dammsan> no chance +12:17 #periperi: < geertu> Which DMA slaves? SCIF? +12:17 #periperi: < dammsan> ask them to try latest upstream +12:18 #periperi: < morimoto> The issue happen in SDIO/SD +12:18 #periperi: < dammsan> haha +12:18 #periperi: < dammsan> no chance again +12:18 #periperi: < dammsan> tell them to build an open reference implemeentation +12:19 #periperi: < dammsan> (sorry for being harsh morimoto-san) +12:19 #periperi: < morimoto> I know 3.10 is no chance, but we can't tell it to customer +12:19 #periperi: < horms> we can talk to Komatsu-san in a less frank manner :) +12:20 #periperi: < pinchartl> morimoto: that's related to the e-mail you have sent me, right ? +12:20 #periperi: < pinchartl> "R-CarGen2 sdhi/rcar-dmac 不具合報告" +12:20 #periperi: < morimoto> Yes, it is one of them +12:21 #periperi: < morimoto> I don't know who should handle this (in Renesas, in upstream) +12:21 #periperi: < morimoto> This is just information for Core group +12:22 #periperi: < dammsan> morimoto: we need dedicated SD/MMC resource +12:22 #periperi: < dammsan> and 1 year of development +12:22 #periperi: < dammsan> after that we can talk again +12:22 #periperi: < dammsan> think gen4 =) +12:24 #periperi: < dammsan> morimoto: do we know any other DMAC issue? +12:24 #periperi: < morimoto> Sakato-san has details. +12:26 #periperi: < dammsan> morimoto: ok, thanks, i'll ask him during dinner next month +12:26 #periperi: < morimoto> thanks +12:26 #periperi: < geertu> We're running out of time... +12:26 #periperi: < geertu> Topic 4: CPG and boot mode via syscon (or not) +12:26 #periperi: < geertu> Do we proceed? +12:27 #periperi: < dammsan> i think the DT binding for the reset controller is a good thing without doubt +12:27 #periperi: < geertu> I think we can postpone the #reset-cells until we want to make use of it +12:28 #periperi: < dammsan> yeah +12:28 #periperi: < dammsan> using syscon would allow us to use DT for something relatively soon +12:28 #periperi: < dammsan> a special new API would take more time +12:28 #periperi: < dammsan> and would require us to either postpone stuff or do it incrementally +12:29 #periperi: < pinchartl> could we propose an API and see how that goes ? +12:29 #periperi: < dammsan> pinchartl: do you have time to work on a new API? +12:29 #periperi: < dammsan> i assume you are starved for time =) +12:30 #periperi: < pinchartl> have you seen at what time I've sent the DU+VSP release yesterday ? :-) +12:30 #periperi: < dammsan> i know i know +12:30 #periperi: < dammsan> thanks for that +12:30 #periperi: < geertu> Laurent only works during weekends ;-) +12:30 #periperi: < dammsan> so i feel that both you, geert and horms are pulling your weight as-is with Gen3 +12:30 #periperi: < pinchartl> oh, yes, and it was a Sunday +12:30 #periperi: < pinchartl> I tend to forget about days of the week :-) +12:31 #periperi: < dammsan> if we have some idle hands then perhaps those could help with that API? +12:31 #periperi: < geertu> You need kids to introduce structure and stability into your life ;-) +12:31 #periperi: < pinchartl> and sleep deprivation +12:31 #periperi: < horms> i have some cycles to donate to the cause +12:31 #periperi: < pinchartl> ah, wait, I have that already :-) +12:31 #periperi: < geertu> Don't drop the kids at school on Sunday morning ;-) +12:32 #periperi: < geertu> Topic 5: Status check for tasks from last meeting - what is remaining? +12:32 #periperi: < pinchartl> I think I'd rather fetch them from school on Sunday evening ;-) +12:32 #periperi: < geertu> I don't think there's any task we can really close. +12:32 #periperi: < pinchartl> so regarding the CPG, can someone propose an API ? +12:32 #periperi: < dammsan> geertu: i agree +12:32 #periperi: < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +12:32 #periperi: < dammsan> i will cook up an updated CPG series today +12:33 #periperi: < geertu> Many tasks are at 99%, but blocked by clock-output-names +12:33 #periperi: < dammsan> no shit +12:33 #periperi: < geertu> I'm a bit reluctant to resend patch series with just removed/added clock-output-names +12:34 #periperi: < geertu> before we have a conclusion +12:34 #periperi: < dammsan> me too +12:34 #periperi: < dammsan> i think it is fine to keep things as-is +12:34 #periperi: < dammsan> geertu: can you incorporate the patch series from laurent into your next release? +12:34 #periperi: < geertu> VSP I can +12:35 #periperi: < geertu> DU has an unknown base +12:35 #periperi: < geertu> Cfr. my email response +12:35 #periperi: < pinchartl> it's the 20150913 tag base :-) +12:35 #periperi: < pinchartl> I think it's the drm-next branch from Dave Airlie's tree +12:35 #periperi: < dammsan> hehe +12:35 #periperi: < geertu> Thanks, I'll include vsp1-kms-gen3-20150913 +12:35 #periperi: < pinchartl> I'll double-check that +12:35 #periperi: < geertu> drm-misc, but some patches from your previous vsp1-kms branch +12:36 #periperi: < pinchartl> there are two DRM core fixes in vsp1-kms-gen3-20150913 not part of the DU patch series sent to the mailing list +12:36 #periperi: < geertu> OK, I'll just take vsp1-kms-gen3-20150913 +12:36 #periperi: < geertu> dammsan: I'll do that after your CPG update? +12:36 #periperi: < pinchartl> would you like me to rebase everything on top of the latest upstream branches and tag vsp1-kms-gen3-20150914 ? +12:37 #periperi: < dammsan> geertu: give me until tomorrow +12:37 #periperi: < geertu> Then I'll update topic/gen3-latest with Laurent's vsp-kms first +12:37 #periperi: < dammsan> if i didn't manage to produce anything useful then please proceed without me =) +12:37 #periperi: < dammsan> sure +12:37 #periperi: < dammsan> sounds good +12:37 #periperi: < geertu> I guess vsp1-kms-gen3-20150913 is OK +12:39 #periperi: < dammsan> so what is the conclusion about CPG and boot mode? +12:40 #periperi: < geertu> Proceed +12:41 #periperi: < pinchartl> proceed with what ? :-) +12:41 #periperi: < geertu> syscon/rst +12:41 #periperi: < geertu> It's what syscon was invented for +12:42 #periperi: < geertu> I don't want to propose an API we can use next year +12:42 #periperi: < dammsan> so simon said he has some hands to lend +12:42 #periperi: < dammsan> it seems to me that syscon is short term +12:42 #periperi: < dammsan> and "the other API" is more long term +12:42 #periperi: < geertu> Oops, seems I missed that +12:43 #periperi: < pinchartl> nobody wants an API we can use in a year +12:43 #periperi: < pinchartl> but if we never propose one we'll never know when we can use it +12:43 #periperi: < pinchartl> it might be that it will go smoothly and quickly +12:43 #periperi: < dammsan> pinchartl: i agree +12:43 #periperi: < pinchartl> I'd like to at least try +12:43 #periperi: < dammsan> so pinchartl and horms can give it a go? +12:43 #periperi: < dammsan> and in the mean time? +12:43 #periperi: < pinchartl> if it ends up taking ages to solve the bikeshedding issues, sure, we can then go for plan B +12:44 #periperi: < horms> dammsan: sure +12:44 #periperi: < dammsan> so when is the cutoff date? +12:44 #periperi: < pinchartl> horms: if you can send an RFC and CC me I can follow up on it and assist during review. would that be ok ? +12:45 #periperi: < horms> sure, I'll see what i can do +12:45 #periperi: < geertu> OK, let's see +12:45 #periperi: < dammsan> so we are still aiming PFC at v4.4, right? +12:45 #periperi: < dammsan> and same for CPG i think? +12:46 #periperi: < geertu> yes +12:46 #periperi: < dammsan> does that mean that this new API needs to have some sort of agreement before that? +12:46 #periperi: < geertu> yes +12:47 #periperi: < geertu> else we'll have code for both on gen3 +12:47 #periperi: < dammsan> geertu: but your reset controller can be done in parallel with this, right? +12:47 #periperi: < geertu> and gen4 will be legacy-free +12:47 #periperi: < dammsan> geertu: i mean the DT bits +12:47 #periperi: < geertu> The rst node is OK +12:47 #periperi: < geertu> It's the syscon,modemr property we'll have to support in parallel +12:48 #periperi: < dammsan> that's plan B +12:48 #periperi: < dammsan> does this result in some tasks? =) +12:48 #periperi: < geertu> You want tasks? +12:48 #periperi: < dammsan> seems like a sane way to store our agreement? +12:48 #periperi: < pinchartl> I'm totally fine with using syscon internally for now, but I'd like to avoid pushing that upstream if we can come up with a proper API in a reasonable time frame +12:49 #periperi: < dammsan> pinchartl: so what is reasonable to you? +12:50 #periperi: < pinchartl> what is our current target ? v4.4 or v4.5 ? +12:50 #periperi: < geertu> "generic,v4.4,Propose API to obtain mode pin values in a a generic way" task added +12:50 #periperi: < geertu> v4.4 +12:50 #periperi: < pinchartl> let's see if it's possible for v4.4. the discussion needs to be started sooner than later then +12:51 #periperi: < pinchartl> and then let's decide based on the feedback +12:51 #periperi: < dammsan> oh yeah +12:51 #periperi: < geertu> ok +12:51 #periperi: < dammsan> we can agree that syscon is a good plan B? +12:52 #periperi: < pinchartl> well, it's the only backup plan I see :-) +12:52 #periperi: < dammsan> we have the built-in register access in the CPG right now +12:52 #periperi: < dammsan> which is ultra-short-term +12:53 #periperi: < dammsan> pinchartl: for the new API, can you target Gen2? +12:53 #periperi: < dammsan> the CPG there is also using the boot mode +12:53 #periperi: < pinchartl> built-in register access has the advantage of not creating DT backward compatibility problems +12:53 #periperi: < dammsan> i agree +12:53 #periperi: < pinchartl> in my opinion that would be better than syscon +12:54 #periperi: < pinchartl> if, for instance, the API can be merged for v4.5 +12:54 #periperi: < pinchartl> we could merge built-in register access for v4.4 and replace it in v4.5 +12:54 #periperi: < dammsan> it all depends on when the API is avaliable +12:54 #periperi: < pinchartl> if it's v4.20 then it's another story of course +12:54 #periperi: < pinchartl> sure, we can target Gen2 +12:54 #periperi: < dammsan> great! +12:54 #periperi: < dammsan> thanks +12:54 #periperi: < geertu> The original "[PATCH/RFC 00/11] ARM: shmobile: Let CPG use syscon for MD pin values" has backwards compatibilty on Gen2 +12:55 #periperi: < geertu> Time to terminate the meeting? +12:56 #periperi: < dammsan> you're getting hungry? =) +12:56 #periperi: < geertu> How do you gues that? +12:56 #periperi: < dammsan> hihi +12:56 #periperi: < geertu> The brain needs sugar to function ;-) +12:56 #periperi: < dammsan> well thanks for today +12:56 #periperi: < geertu> yes, thanks all for joining! +12:56 #periperi: < dammsan> enjoy your lunch +12:56 #periperi: < dammsan> bye bye +12:56 #periperi: < geertu> Enjoy your evening! +12:56 #periperi: < horms> dammsan: can we talk tomorrow? +12:57 #periperi: < shimoda> bye! +12:57 #periperi: < morimoto> bye +12:57 #periperi: < uli___> bye +12:57 #periperi: < pinchartl> morimoto: I'll send you a tentative (untested) fix for the rcar-dmac issue +12:57 #periperi: < morimoto> Thank you |