diff options
Diffstat (limited to 'wiki/Chat_log/20150901-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20150901-core-chatlog | 454 |
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 :-) |