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

1 files changed, 454 insertions, 0 deletions

diff --git a/wiki/Chat_log/20150901-core-chatlog b/wiki/Chat_log/20150901-core-chatlog
new file mode 100644
index 0000000..9dfc6a6
--- /dev/null
+++ b/wiki/Chat_log/20150901-core-chatlog
@@ -0,0 +1,454 @@
+11:02 #periperi: < geertu> Welcome to the Core Group Chat Session!
+11:02 #periperi: < uli___> good morning
+11:02 #periperi: < horms> Thanks, nice to be back
+11:02 #periperi: < geertu> Today's agenda:
+11:02 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
+11:02 #periperi: < geertu> 1. Upcoming Gen3 development for the Core group,
+11:02 #periperi: < geertu> 2. Topic/branch/merge organization of Gen3 work,
+11:02 #periperi: < geertu> 3. DMA topology,
+11:02 #periperi: < geertu> 4. CPG and boot mode via syscon (or not),
+11:02 #periperi: < geertu> 5. Status check for tasks from last meeting - what is remaining?
+11:03 #periperi: < morimoto> dammsan: which port is bock-w ?
+11:04 #periperi: < dammsan> morimoto: 8004
+11:04 #periperi: < morimoto> # this is not core topic, but now we have 2 board, and I will send it to Europe engineer
+11:05 #periperi: < morimoto> # but because of papwer work, it will be next week
+11:05 #periperi: < morimoto> dammsan: thanks
+11:06 #periperi: < horms> morimoto: i use bockw sometimes, so lets co-ordinate here if you want to use the board
+11:06 #periperi: < horms> uli___:
+11:06 #periperi: < horms> uli___ also uses it, but usually while we are ase
+11:06 #periperi: < horms> uli___ also uses it, but usually while we are ase
+11:06 #periperi: < horms> uli___ also uses it, but usually while we are asleep
+11:06 #periperi: < uli___> indeed
+11:06 #periperi: < horms> (typing disaster!)
+11:06 #periperi: < geertu> Topic 1. Upcoming Gen3 development for the Core group,
+11:07 #periperi: < dammsan> geertu: right
+11:07 #periperi: < dammsan> i intend to update the cpg series and the integration series
+11:08 #periperi: < dammsan> and also work on irqc
+11:08 #periperi: < dammsan> but i hope to keep the integration series small until we can stabilize the cpg and the pfc
+11:08 #periperi: < dammsan> so focus must be on stabilizing pfc and cpg
+11:09 #periperi: < geertu> Integration is the hardest w.r.t. merge conflicts (but that's actually topic 2)
+11:09 #periperi: < horms> I plan to put integration series's into topic branches as they appear; only addrssing apply and build time dependencies
+11:09 #periperi: < horms> (sorry, lets talk about that in topic2)
+11:10 #periperi: < dammsan> (yeah, sorry, so what shall we talk about for topic1?)
+11:10 #periperi: < geertu> Stabilize CPG and PFC
+11:10 #periperi: < dammsan> ok =)
+11:10 #periperi: < geertu> It seems dropping clock-output-names was not such a good idea...
+11:10 #periperi: < dammsan> i did it because it seemed that mike turquette wanted us to do so
+11:10 #periperi: < dammsan> but perhaps i misunderstood
+11:11 #periperi: < geertu> No respnse from Mike yet (although he's alive, sent pull request, and replied to me in other personal email)
+11:11 #periperi: < horms> I saw him last week; he was also alive then!
+11:11 #periperi: < dammsan> i think we can work around things by registering names using in-driver generated names
+11:11 #periperi: < dammsan> not exposing names in DT seems like a fine idea to me
+11:12 #periperi: < geertu> Nope, all fixed-factor-clocks rely on clock-output-names in the parent clocks
+11:12 #periperi: < dammsan> geertu: sure
+11:12 #periperi: < dammsan> but can't we work around that somehow?
+11:12 #periperi: < dammsan> by providing clock-output-name equivalent but from the driver?
+11:12 #periperi: < geertu> the scif driver "works" (for scif2) as it assumes 115200 baud and doesn't program registers
+11:13 #periperi: < dammsan> sure, i think that is the state of the entire CPG series
+11:13 #periperi: < geertu> clk_of_get_parent_clock_name() looks in DT, it doesn't follow in-kernel clock topology
+11:13 #periperi: < dammsan> maybe it should?
+11:13 #periperi: < geertu> That's one option.
+11:14 #periperi: < dammsan> so say it would work, then isn't omitting that parameter from DT a good idea?
+11:14 #periperi: < geertu> I think "no clock-output-names" is meant for clocks with a single output, where the node name can be used instead
+11:14 #periperi: < dammsan> ok i see
+11:14 #periperi: < dammsan> so we could have one node per clock instead
+11:14 #periperi: < geertu> It may be a good idea if the driver knows (like cpg)
+11:14 #periperi: < dammsan> or perhaps we should extend the core to support index?
+11:15 #periperi: < geertu> For mstp the driver doesn't know, so it comes up with mstp3.10
+11:15 #periperi: < geertu> I'd like to wait for the clock people's response
+11:15 #periperi: < dammsan> the cpg driver could do the same
+11:15 #periperi: < dammsan> since we have the strings there anyway
+11:15 #periperi: < geertu> Clocks work again just by re-adding clock-output-names to the dtsi only (no driver update needed)
+11:16 #periperi: < dammsan> waiting for maintainer feedback is of course a good plan
+11:16 #periperi: < dammsan> but is there something we could do in the meantime?
+11:16 #periperi: < dammsan> we could re-add clock-output-names like you say
+11:16 #periperi: < dammsan> or just fix the code in the cpg driver
+11:16 #periperi: < geertu> It's not a problem in the cpg driver
+11:16 #periperi: < geertu> and it can't be fixed there
+11:17 #periperi: < geertu> only in core clock code
+11:17 #periperi: < dammsan> oh, but this only triggers in the case of CPG and not in MSTP, right?
+11:17 #periperi: < geertu> It doesn't trigger in mstp, because the only users of mstp clocks are devices, where clk_get() will do the right thing.
+11:18 #periperi: < geertu> If you register e.g. a fixed-factor-clock as a child of an mstp clock, it will fail, too
+11:18 #periperi: < dammsan> ok then consider me convinced =)
+11:18 #periperi: < horms> +1
+11:19 #periperi: < geertu> Basically it fails for every clock in DT where the parent has multiple clock outputs
+11:19 #periperi: < dammsan> so we should wait for feedback?
+11:20 #periperi: < dammsan> or does anyone feel like cooking up some core CCF code? =)
+11:20 #periperi: < dammsan> maybe i simply misunderstood mike turquette
+11:20 #periperi: < geertu> Not me, because I think the "no clock-output-names rule" is flawed
+11:22 #periperi: < geertu> Any other upcoming gen3 work (irqc is already in the task list)?
+11:22 #periperi: < shimoda> we should prepare thermal driver in Sep.
+11:22 #periperi: < dammsan> does it make sense to pick up the GPIO stuff?
+11:23 #periperi: < geertu> I have it included in today's renesas-drivers
+11:23 #periperi: < dammsan> i think i prefer to keep the integration patch set small (and that's topic2 sorry)
+11:23 #periperi: < shimoda> gen3 thermal seems not compatible with gen2 :)
+11:23 #periperi: < geertu> Indeed, but thermal is I/O, not Core?
+11:25 #periperi: < dammsan> geertu: how shall we split the core work then?
+11:25 #periperi: < horms> possibly but the next I/O group meeting is not for 2 weeks, there won't be much September left then
+11:25 #periperi: < horms> perhaps it is a topic for email?
+11:25 #periperi: < shimoda> oops, my sheet is written as core
+11:25 #periperi: < geertu> gpio lacks power-domains properties, but for now that works due to an obsolete CONFIG_ARCH_SHMOBILE_MULTI check in drivers/sh/pm_runtime.c
+11:26 #periperi: < geertu> dammsan: what do you mean with "how shall we split the core work then?"
+11:27 #periperi: < shimoda> horms: I will send thermal topic to periperi ml
+11:27 #periperi: < geertu> I have PFC and CPG in renesas-drivers#topic/...
+11:27 #periperi: < dammsan> i can deal with igeertu: i meant how to handle development of PFC and CPG
+11:28 #periperi: < dammsan> morimoto: are you doing ok with PFC?
+11:28 #periperi: < dammsan> do you need any help?
+11:28 #periperi: < geertu> Simon has integration in renesas#topic/...
+11:28 #periperi: < morimoto> I think I can send next version of PFC tommorrow
+11:28 #periperi: < morimoto> I need to check PFC macro on BockW
+11:28 #periperi: < dammsan> morimoto: why don't you reorder things to add your cleanup as incremental patch?
+11:29 #periperi: < dammsan> or does the code become better if you make the cleanup first?
+11:29 #periperi: < geertu> TOpic 2. Topic/branch/merge organization of Gen3 work,
+11:29 #periperi: < dammsan> i guess i don't understand the need for the dependency
+11:29 #periperi: < dammsan> geertu: can we discuss CPG development later?
+11:29 #periperi: < geertu> The cleanup changes the name of a macro
+11:30 #periperi: < geertu> sure
+11:30 #periperi: < geertu> (in topic 4?)
+11:30 #periperi: < dammsan> sure, sorry!!
+11:31 #periperi: < dammsan> it is of course up to morimoto-san to decide about his cleanups
+11:31 #periperi: < geertu> Apart from the macro cleanup, I think PFC should switch to an incremental model, at least for inclusion in renesas-drivers
+11:31 #periperi: < geertu> same for integration
+11:32 #periperi: < horms> geertu: can you clarify what you mean by incremental?
+11:32 #periperi: < dammsan> geertu: from when?
+11:32 #periperi: < geertu> What's ultimately submitted would be an interactive rebase result of the initial patches and the incrementals
+11:32 #periperi: < dammsan> that means you consider it stable enough soon?
+11:32 #periperi: < geertu> It doesn't make sense to keep on resubmitting (almost) the same series to the list, with a few pingroup entries (pfc) or device nodes (dtsi) added
+11:33 #periperi: < horms> true
+11:33 #periperi: < geertu> No one's gonna take patches before rc1 is released
+11:33 #periperi: < horms> from my pov a small(ish) base patch is a good start that can be reviewed
+11:33 #periperi: < geertu> while we want to keep developing, not rebasing and resubmitting
+11:33 #periperi: < horms> as can any incremental patches that add needed support
+11:34 #periperi: < horms> that way we review what we are using (which is probably smaller than everything)
+11:34 #periperi: < horms> and by implication deffer reviewing the rest
+11:34 #periperi: < geertu> So I'm happy seeing e.g. topic/gen3-cpg-v5
+11:34 #periperi: < horms> in my opinion that makes sense particularly at this busy time
+11:35 #periperi: < dammsan> i'm confused
+11:35 #periperi: < dammsan> =)
+11:35 #periperi: < dammsan> so what would you prefer? can you repeat please?
+11:35 #periperi: < geertu> Of course we must make sure to have the base (refferred to by device nodes) covered, which is interrupts, clocks, and dmas
+11:36 #periperi: < dammsan> geertu: but the base is not yet stable right?
+11:36 #periperi: < geertu> It more or less is.
+11:36 #periperi: < geertu> Except for the pesky clock-output-names
+11:36 #periperi: < dammsan> yes, and that is used by every node =)
+11:36 #periperi: < geertu> if we have to re-add them to the mstp nodes, that means it affects many patches
+11:37 #periperi: < dammsan> right
+11:37 #periperi: < dammsan> PFC seems much close at this point
+11:37 #periperi: < geertu> indeed
+11:38 #periperi: < geertu> For supporting other devices, there are usually two parts:
+11:38 #periperi: < geertu> a. driver update (can be just a new DT compatible value added to the bindings)
+11:38 #periperi: < geertu> b. integration (dtsi and defconfig)
+11:38 #periperi: < geertu> a. is fairly independent, and I can take that in renesas-drivers#topic/...
+11:39 #periperi: < geertu> b. is for Simon's renesas#topic/...
+11:39 #periperi: < dammsan> b probably needs to be ordered right?
+11:39 #periperi: < geertu> but usually each new patch depends contextually on the previous one
+11:39 #periperi: < horms> yes, that seems likely
+11:39 #periperi: < geertu> which means it must be "correct" when Simon applies it.
+11:40 #periperi: < geertu> While a. I can easily update/replace
+11:41 #periperi: < dammsan> we need to expose both a and b to a larger audience IMO
+11:41 #periperi: < geertu> Right now the b.'s are stuck on clock-output-names
+11:41 #periperi: < dammsan> yes
+11:41 #periperi: < geertu> so all of them may need rework
+11:41 #periperi: < dammsan> i agree with that observation
+11:42 #periperi: < dammsan> but upstreaming of "a" can happen independently anyway
+11:42 #periperi: < geertu> The a.'s can follow the standard patch submission rules to maintainers when deemed stable
+11:42 #periperi: < geertu> yep
+11:42 #periperi: < dammsan> so where are we with the core driver bits ("a")?
+11:42 #periperi: < geertu> The b.'s have to go in through Simon's tree, right
+11:43 #periperi: < horms> that is their upstream path
+11:43 #periperi: < horms> for topic branches things are less fixed imho
+11:43 #periperi: < geertu> scif just needs a vinding update
+11:43 #periperi: < geertu> s/vinding/binding/
+11:43 #periperi: < geertu> so that can go upstream after rc1
+11:43 #periperi: < dammsan> geertu: the silliness of SCIF2 is that included in that summary? =)
+11:44 #periperi: < geertu> same for gpio
+11:44 #periperi: < shimoda> dammsan: some timers and dmaengnie?
+11:44 #periperi: < dammsan> shimoda: sure
+11:44 #periperi: < horms> is scif2 secret; if so should it be omitted from mainline?
+11:44 #periperi: < dammsan> secred irda, haha, what is this, 1984?
+11:44 #periperi: < geertu> it's the console. So we have a secret black box the user is interacting with :-)
+11:45 #periperi: < horms> figures
+11:45 #periperi: < dammsan> but seriously, how do we handle DT in case of SCIF2?
+11:45 #periperi: < dammsan> is that a I/O group problem perhaps? =)
+11:45 #periperi: < geertu> We have the missing interrupt from an older datasheet, and the driver needs it
+11:46 #periperi: < geertu> DT is integration, not I/O ;-)
+11:46 #periperi: < geertu> so byebye secrecy
+11:46 #periperi: < horms> sounds awkward
+11:46 #periperi: < dammsan> hm, i thought every per-driver DT binding doc was part of driver development
+11:47 #periperi: < dammsan> i was also hoping geert to make sure the r8a7795 SCIF DT binding doc went upstream
+11:47 #periperi: < dammsan> together with the DMA bits
+11:47 #periperi: < geertu> sure, after rc1
+11:47 #periperi: < dammsan> sure, no stress
+11:47 #periperi: < geertu> GregKH may already take scif-misc-v3, but only after rc1
+11:48 #periperi: < dammsan> ok
+11:48 #periperi: < horms> so this secreat irq, would be described in dt
+11:48 #periperi: < geertu> What special DT binding is there for SCIF2?
+11:48 #periperi: < geertu> The driver needs an IRQ
+11:48 #periperi: < dammsan> so we don't have any particular devices to focus on now except the CPG and PFC?
+11:48 #periperi: < horms> was that circulated publicly before we found out it was secret?
+11:48 #periperi: < horms> (we can punt this topic if you like)
+11:48 #periperi: < dammsan> geertu: i meant that we may have to special case it
+11:49 #periperi: < dammsan> in the DT binding doc
+11:49 #periperi: < dammsan> if it is special somehow
+11:49 #periperi: < dammsan> (reminds me that i have to resend that CMT series)
+11:49 #periperi: < geertu> v0.50 is from end of July, right?
+11:49 #periperi: < horms> yes, iirc
+11:49 #periperi: < horms> 21st July iirc
+11:50 #periperi: < geertu> First public scif2 in r8a7795.dtsi is from Aug 6
+11:50 #periperi: < dammsan> isn't it easy just to omit SCIF2?
+11:50 #periperi: < geertu> So Morimoto-san should have known ;-)
+11:50 #periperi: < dammsan> we can use HSCIF instead?
+11:50 #periperi: < geertu> It's the console
+11:50 #periperi: < dammsan> sometimes we can use other SCIF block on same pins
+11:51 #periperi: < geertu> No, serial-0 only does scif2, I think
+11:51 #periperi: < dammsan> wtf
+11:51 #periperi: < dammsan> so shall we aim for DEBUG1 then? =)
+11:52 #periperi: < dammsan> but seriously, what a mess
+11:52 #periperi: < geertu> we can bitbang SDHI2 WP/CD on those lines
+11:52 #periperi: < geertu> or GPIO ;-)
+11:52 #periperi: < geertu> U-boot uses scif2
+11:52 #periperi: < dammsan> hehe, must be better
+11:52 #periperi: < dammsan> but u-boot is not interrupt driven =)
+11:53 #periperi: < geertu> Obviously the interrupt is working
+11:53 #periperi: < horms> if a patch can already be found by google then it ain't no secret anymore
+11:53 #periperi: < dammsan> maybe we should just ask for update for the SCIF2 interrupt
+11:53 #periperi: < dammsan> update for the deocumentation
+11:53 #periperi: < dammsan> shimoda: morimoto: can we request update?
+11:53 #periperi: < dammsan> this is silly
+11:54 #periperi: < geertu> Are we actually using scif2, or are we using irda?
+11:54 #periperi: < geertu> The MSTP clock indicates irda
+11:54 #periperi: < geertu> and irda usually is scif-compatible
+11:54 #periperi: < dammsan> we have non-SCIF compatible IRDA as well
+11:54 #periperi: < shimoda> dammsan: sure, I or Morimoto-san request it
+11:55 #periperi: < dammsan> shimoda: thanks please check about SCIF2 interrupt
+11:55 #periperi: < dammsan> so it seems that the integration series is blocked on both CPG and SCIF2
+11:56 #periperi: < geertu> hurray
+11:56 #periperi: < geertu> Hence incrementals for now
+11:56 #periperi: < dammsan> at least we have hardware now
+11:56 #periperi: < geertu> BTW, who's "Europe engineer"?
+11:56 #periperi: < dammsan> geertu: i think i should do one major resend in v9
+11:57 #periperi: < dammsan> to fix up the things you requested
+11:57 #periperi: < horms> we just meed sw to complete the set
+11:57 #periperi: < dammsan> or do you prefer to get individual patches?
+11:57 #periperi: < dammsan> i mean incremental ones?
+11:58 #periperi: < geertu> v9 is integration, so that's up to Simon ;-)
+11:58 #periperi: < dammsan> ok, about CPG you prefer incremental then?
+11:58 #periperi: < horms> i prefer a fresh patchset if existing patches need updating
+11:58 #periperi: < dammsan> ok, fresh patchset it will be then
+11:58 #periperi: < horms> incremental is fine for new stuff
+11:59 #periperi: < horms> thanks
+11:59 #periperi: < geertu> For CPG, you would only update 2/5 clk: shmobile: Add Renesas R-Car Gen3 CPG support?
+11:59 #periperi: < geertu> I don't mind if you just send that one
+11:59 #periperi: < dammsan> sure, but i think i also missed your comment about 4/5 or something
+11:59 #periperi: < dammsan> so > 1 patch -> resend series
+12:00 #periperi: < geertu> yep
+12:00 #periperi: < geertu> sounds fine
+12:00 #periperi: < geertu> Next topic?
+12:00 #periperi: < dammsan> if <=1 patch - resend individual patch
+12:01 #periperi: < dammsan> sure
+12:01 #periperi: < geertu> Topic 3. DMA topology,
+12:02 #periperi: < geertu> we have dummy dma nodes now, so "dmas" can be added (albeit untested)
+12:02 -!- Irssi: Pasting 8 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
+12:02 #periperi: < geertu> R-Car Gen2 had two DMA controllers, which were equivalent.
+12:02 #periperi: < geertu> As we dropped the shdma dma-multiplexer when implementing rcar-dmac,
+12:02 #periperi: < geertu> DMA slaves were tied to a single DMA controller in .dtsi only.
+12:02 #periperi: < geertu> On R-Car Gen3 the three DMA controllers are not equivalent: some DMA slaves
+12:02 #periperi: < geertu> can be tied to channels 0-15 (the first instance) only, others can be tied to
+12:02 #periperi: < geertu> channels 16-47 (i.e. the second or third instance) only.
+12:02 #periperi: < geertu> For the latter, I used the second instance in .dtsi.
+12:03 #periperi: < geertu> Do we have a plan to use the third dmac (on Gen3), or the second dmac (on Gen2)
+12:03 #periperi: < geertu> ?
+12:03 #periperi: < geertu> Is Laurent here?
+12:03 #periperi: < dammsan> i have no special policy setting plan, but i'd like to describe the hardware via DT
+12:04 #periperi: < geertu> Which means "dmas" should link to all relevant dmac nodes
+12:04 #periperi: < geertu> and not just the first one
+12:04 #periperi: < dammsan> yes, isn't that what we said during the montpellier peripericon?
+12:04 #periperi: < dammsan> hurray for another unstable DTS bit! =)
+12:05 #periperi: < geertu> In Montpellier, we said we'd start with links to one dmac, and see how to resolve the rest later
+12:05 #periperi: < dammsan> now seems like a great time then
+12:06 #periperi: < dammsan> adding more links to DT without driver support does not hurt, does it?
+12:06 #periperi: < geertu> How?
+12:06 #periperi: < geertu> Now we have
+12:06 #periperi: < geertu> dmas = <&dmac1 0x31>, <&dmac1 0x30>;
+12:06 #periperi: < geertu> dma-names = "tx", "rx";
+12:07 #periperi: < geertu> We can't easily extend that
+12:07 #periperi: < geertu> Would this actually work?
+12:07 #periperi: < dammsan> we can not have multiple identical dma-names?
+12:07 #periperi: < geertu> dmas = <&dmac1 0x31>, <&dmac1 0x30>, <&dmac2 0x31>, <&dmac2 0x30>;
+12:07 #periperi: < geertu> dma-names = "tx", "rx", "tx", "rx";
+12:07 #periperi: < geertu> I'm afraid not
+12:07 #periperi: < dammsan> that's how i pictured it
+12:08 #periperi: < geertu> It's also related to DMA load balancing
+12:08 #periperi: < geertu> And the third dmac may be secret on Gen3 ;-)
+12:08 #periperi: < dammsan> we could add some "dma-peer" property to the dma controller to point to the peers
+12:08 #periperi: < geertu> Yes, that was one of the options we discussed in Montpellier
+12:09 #periperi: < geertu> Perhaps the only sane one
+12:09 #periperi: < geertu> Let's hope there are no "evil" DMA slaves that can be tied to the first and second dmac on gen3
+12:09 #periperi: < geertu> while all others tie to second and third
+12:10 #periperi: < geertu> or the the first exclusively
+12:10 #periperi: < geertu> Anyway, without Laurent I think we should postpone this?
+12:10 #periperi: < dammsan> the identical-dma-name proposal would support anything, right?
+12:10 #periperi: < geertu> Yes
+12:11 #periperi: < geertu> Probably needs updates the core DMA framework
+12:11 #periperi: < dammsan> probably yes
+12:12 #periperi: < geertu> Topic 4. CPG and boot mode via syscon (or not),
+12:12 #periperi: < geertu> Laurent wanted to have a generic (also for non-shmobile) framework to obtain a boot mode value
+12:13 #periperi: < geertu> instead
+12:14 #periperi: < dammsan> that could perhaps be in gen4 if we have done that upfront
+12:14 #periperi: < geertu> yeah
+12:14 #periperi: < dammsan> i thought your syscon idea was great
+12:15 #periperi: < geertu> The major disadvantage of the syscon idea is that we don't know yet how else we'll use the RST module
+12:15 #periperi: < dammsan> but this may slightly overlap with the ES revision bits
+12:15 #periperi: < geertu> w.r.t. CPU core management
+12:15 #periperi: < dammsan> right
+12:15 #periperi: < geertu> THE es bits in a different register on Gen3?
+12:15 #periperi: < dammsan> i'm also concerned about RST of I/O devices
+12:16 #periperi: < geertu> That's in the MSTP module?
+12:16 #periperi: < dammsan> maybe so
+12:16 #periperi: < geertu> i.e. more registers for each MSTP node
+12:16 #periperi: < dammsan> but how do we perform actual reset?
+12:17 #periperi: < dammsan> it is more of a question about how to perform reset instead of DT hardware description
+12:17 #periperi: < dammsan> and i think that is similar to the boot mode discussion
+12:17 #periperi: < dammsan> we need to figure out how to let the driver get the information
+12:17 #periperi: < dammsan> and separate from that
+12:17 #periperi: < dammsan> also need to figure out how to describe the hardware in DT
+12:17 #periperi: < geertu> You mean resetting individual I/O devices, not the whole system?
+12:17 #periperi: < dammsan> yes
+12:18 #periperi: < geertu> What's the use case for that?
+12:18 #periperi: < dammsan> similar to power domain, but without power savings
+12:18 #periperi: < dammsan> it may be nice to get a clean start before probe() =)
+12:19 #periperi: < dammsan> no special use case apart from that
+12:19 #periperi: < geertu> So each device would have a power-domains property linking to the (generalized) MSTPx.y, not only for clock, but also for reset handling?
+12:19 #periperi: < dammsan> at least for boot mode we have a need =)
+12:19 #periperi: < dammsan> reset-domains
+12:20 #periperi: < geertu> Actually we can have that in power-domains
+12:20 #periperi: < dammsan> there is certainly overlap
+12:20 #periperi: < geertu> Actually each MSTP clock has a corresponding module reset bit
+12:20 #periperi: < dammsan> maybe the MSTP driver an hook up a notifier if there are reset registers present
+12:21 #periperi: < geertu> perhaps
+12:21 #periperi: < geertu> Sounds like for Gen-4
+12:21 #periperi: < dammsan> and do stuff on BIND and UNBIND or similar
+12:21 #periperi: < dammsan> sure
+12:21 #periperi: < dammsan> but not _that_ difficult
+12:21 #periperi: < dammsan> so about boot mode
+12:21 #periperi: < dammsan> what do we do?
+12:22 #periperi: < geertu> We can do the syscon way now.
+12:22 #periperi: < geertu> Patches are available, need a small update for Gen3
+12:22 #periperi: < geertu> It's easy to decide, in the absence of Laurent
+12:22 #periperi: < geertu> ;-)
+12:22 #periperi: < dammsan> so with the ES version we decided to go with DT compat string suffix
+12:22 #periperi: < dammsan> to handle workarounds for special ES versions
+12:23 #periperi: < dammsan> we never got around to runtime modify the DT bits based on ES version though
+12:23 #periperi: < geertu> We haven't implemented changing the DT compat string based on probed ES version yet
+12:23 #periperi: < dammsan> bingo
+12:23 #periperi: < dammsan> =)
+12:23 #periperi: < geertu> Do we have a need for ES now?
+12:24 #periperi: < dammsan> so if we do that, then can we just deal with the boot mode there instead?
+12:24 #periperi: < dammsan> but using syscon may be better
+12:24 #periperi: < dammsan> no need for ES handling right now, but it may come up
+12:25 #periperi: < dammsan> i'm totally fine with syscon, especially if we use SoC specific compat strings
+12:25 #periperi: < geertu> "boot mode there" means purely in C, no DT update needed?
+12:25 #periperi: < dammsan> yeah, detecting boot mode from C and stashing it in DT while modifying for ES anyway
+12:25 #periperi: < geertu> I can update my syscon patch for Gen3, and resend?
+12:26 #periperi: < dammsan> sounds good!
+12:26 #periperi: < dammsan> so what is the risk for going the syscon route?
+12:26 #periperi: < dammsan> apart from ticking off laurent =)
+12:26 #periperi: < dammsan> you mentioned CPU reset
+12:27 #periperi: < geertu> +	rst: reset-controller@e616000 {
+12:27 #periperi: < geertu> +		compatible = "renesas,rst-r8a7790", "syscon";
+12:27 #periperi: < geertu> +		reg = <0 0xe6160000 0 0x0100>;
+12:27 #periperi: < geertu> +	};
+12:27 #periperi: < dammsan> looking good!!
+12:27 #periperi: < geertu> Does that pose a risk?
+12:27 #periperi: < geertu> for future RST use?
+12:28 #periperi: < dammsan> not what i can tell
+12:28 #periperi: < geertu> cpg node needs
+12:28 #periperi: < geertu> renesas,modemr = <&rst 0x60>;
+12:29 #periperi: < geertu> Will cook up an incremental patch
+12:29 #periperi: < dammsan> seems good to me
+12:29 #periperi: < dammsan> thanks!
+12:30 #periperi: < geertu> One minute left for
+12:30 #periperi: < geertu> Topic 5. Status check for tasks from last meeting - what is remaining?
+12:30 #periperi: < dammsan> thanks for uli___ and horms help with GPIO
+12:30 #periperi: < horms> i did little
+12:30 #periperi: < geertu> Add full (H)SCIF nodes to DT is partially done (need to re-add HSCIF pfc bits to make it work again)
+12:30 #periperi: < horms> but its nice to see it moving forwards
+12:30 #periperi: < geertu> Add gpio nodes to DT is done, modulo power-domains
+12:31 #periperi: < uli___> should i resend that with clock-output-names restored now? :)
+12:31 #periperi: < geertu> pfc Add r8a7795 support is wip
+12:31 #periperi: < geertu> uli___: please wait, unless you want to game mailing list statistics
+12:31 #periperi: < geertu> No changes for other tasks?
+12:32 #periperi: < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list
+12:33 #periperi: < dammsan> not from me
+12:34 #periperi: < shimoda> no update from me
+12:36 #periperi: < geertu> OK, thanks for joining!
+12:36 #periperi: < morimoto> geertu: my "Europe engineer" was 1st attack : for Laurent, Geert. 2nd attack Ulirch Wolfram
+12:36 #periperi: < morimoto> We can send one board to Simon, but there is no paper work for him :)
+12:37 #periperi: < dammsan> geertu: about CPG, i wonder what the next step really is
+12:37 #periperi: < geertu> No paperwork means no fun, less earned value ;-)
+12:37 #periperi: < geertu> dammsan: submit to clock maintainers?
+12:38 #periperi: < morimoto> No paperwork No life :P
+12:38 #periperi: < geertu> morimoto So Simon can just take a board on a plane?
+12:38 #periperi: < dammsan> geertu: about the clks array handling, i think a static array is just fine
+12:38 #periperi: < dammsan> in my mind apart from removing a spinlock
+12:39 #periperi: < dammsan> it is just about figuring out how to deal with(out) clock-output-names
+12:39 #periperi: < geertu> yeah, initially I though it was an array of "struct clk", not pointers
+12:39 #periperi: < geertu> s/though/thought/
+12:39 #periperi: < geertu> Wasting a few pointers isn't that important.
+12:39 #periperi: < dammsan> we will expand NR if needed on new SoCs ight?
+12:39 #periperi: < geertu> I also thought about dropping clock-indices, like Laurent suggested.
+12:39 #periperi: < dammsan> and may use a subset of the indices
+12:40 #periperi: < geertu> But the reason for them is future expansion, right?
+12:40 #periperi: < dammsan> i like having them there
+12:40 #periperi: < dammsan> yes
+12:40 #periperi: < geertu> Time for lunch here...
+12:40 #periperi: < geertu> Bye!
+12:40 #periperi: < dammsan> and i also like being able to search in DT files to figure out how things are connected
+12:40 #periperi: < dammsan> ok bye bye
+12:41 #periperi: < morimoto> geertu: Simon can get board from delivery car
+12:41 #periperi: < shimoda> bye!
+12:41 #periperi: < morimoto> bye
+12:41 -!- morimoto [~user@relprex2.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"]
+12:41 #periperi: < uli___> bye
+12:54 #periperi: < horms> sorry to miss the last few minutes of the meeting: i had a minor baby crisis to attend to
+13:46 -!- horms [~horms@121-80-213-238f1.hyg1.eonet.ne.jp] has quit [Quit: Leaving]
+13:58 #periperi: < pinchartl> geertu: what bothers me with syscon for boot mode handling is that the register isn't part of the syscon IP core
+13:59 #periperi:  * pinchartl is back in Finland now
+14:17 #periperi: < geertu> Welcome back (sort of)!
+14:22 #periperi: < pinchartl> sorry for missing today's meeting
+14:36 #periperi: < geertu> pinchartl: It is according to Figure 11.1   Block Diagram of RST (Gen3)
+14:36 #periperi: < geertu> And 11.1.1 11.1.1 Features
+14:36 #periperi: < geertu> The following functions are implemented by RST.
+14:36 #periperi: < geertu> Latching of the levels on mode pins when PRESET# is negated
+14:36 #periperi: < geertu> Mode monitoring register
+14:40 #periperi:  * geertu mutex_lock(salvator-x)
+14:42 -!- shimoda [~shimoda@relprex3.renesas.com] has quit [Quit: WeeChat 0.4.2]
+14:49 #periperi: < pinchartl> geertu: is RST a "syscon" ?
+14:49 #periperi: < pinchartl> we have a SYSC IP core
+14:49 #periperi: < pinchartl> that one is documented as system controller :-)
+14:50 #periperi: < pinchartl> although it looks like a power controller
+14:51 #periperi: < pinchartl> syscon is really a mean to stuff all kind of miscellaneous stuff in a catch-all API when standardizing an API would be difficult due to very system-specific features
+14:51 #periperi: < geertu> Documentation/devicetree/bindings/mfd/syscon.txt
+14:51 -!- Irssi: Pasting 8 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
+14:51 #periperi: < geertu> System controller node represents a register region containing a set
+14:51 #periperi: < geertu> of miscellaneous registers. The registers are not cohesive enough to
+14:51 #periperi: < geertu> represent as any specific type of device. The typical use-case is for
+14:51 #periperi: < geertu> some other node's driver, or platform-specific code, to acquire a
+14:51 #periperi: < geertu> reference to the syscon node (e.g. by phandle, node path, or search
+14:51 #periperi: < geertu> using a specific compatible value), interrogate the node (or associated
+14:51 #periperi: < geertu> OS driver) to determine the location of the registers, and access the
+14:51 #periperi: < geertu> registers directly.
+14:51 #periperi: < pinchartl> the boot mode pins, on the other hand, seems like a quite well-defined function to me
+14:51 #periperi: < pinchartl> yes, exactly
+14:51 #periperi: < geertu> The watchdog will need alink to one of the RST registers, too
+14:52 #periperi: < pinchartl> syscon is really a hack to access registers in unrelated IP cores when creating an API isn't worth it
+14:53 #periperi: < pinchartl> by the way
+14:53 #periperi: < pinchartl> the syscon driver is registered as a postcore_initcall()
+14:54 #periperi: < pinchartl> and the CPG driver uses CLK_OF_DECLARE()
+14:54 #periperi: < pinchartl> have you checked the ordering ?
+14:55 #periperi: < geertu> The syscon driver is not instantiated
+14:56 #periperi: < pinchartl> on ARM64, start_kernel() -> time_init() -> of_clk_init() -> CLK_OF_DECLARE callbacks
+14:56 #periperi: < geertu> See syscon_regmap_lookup_by_phandle
+14:57 #periperi: < pinchartl> indeed
+14:57 #periperi: < geertu> And the node will still bind to a future renesas,rst-r8a7795 driver
+14:58 #periperi: < pinchartl> there should be a big red flashing HACK sign in front of that code :-)