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

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 :-)