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

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