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

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