renesas/periject.git - Renesas periject clone

diff options

author	Wolfram Sang <wsa+renesas@sang-engineering.com>	2021-09-02 10:07:03 +0200
committer	Wolfram Sang <wsa+renesas@sang-engineering.com>	2021-09-02 10:07:03 +0200
commit	1ef4e082260a4d6add7e2abe12547ac90a84885e (patch)
tree	960081b1dc5c52bcab4aae0ab1e22f423aa03179 /projects/uboot/wheat_dm_dt_conversion.yaml
parent	49d07403e8974b9f8fd37c7bbb96590a84dc60cc (diff)

wiki: Add I/O chatlog for 20210902

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Diffstat (limited to 'projects/uboot/wheat_dm_dt_conversion.yaml')

0 files changed, 0 insertions, 0 deletions

Core-chat-meeting-2015-12-15 10:03 < geertu> Agenda: 10:03 < geertu> 1. Upcoming Gen3 development for the Core group, 10:03 < geertu> 2. Status check for tasks from last meeting - what is remaining? 10:03 < geertu> 3. SMP enablement on Gen3 10:03 < geertu> 4. Cache enablement on Gen3 10:03 < geertu> 5. DMA-Engine framework development and SYS-DMAC on Gen3 10:03 < geertu> Topic 1. Upcoming Gen3 development for the Core group 10:05 < geertu> Nothing new, good ;-) 10:05 < dammsan> FYI, my plan is to push out a bunch of IPMMU patches for r8a7795 soon 10:05 < geertu> Nice! 10:06 < dammsan> Apart from that, I'd like to test them with the DU - but it was dropped in a recent renesas-devel release 10:06 < geertu> Yeah, too many issues with the media tree 10:07 < dammsan> understandable!! 10:07 < geertu> As I dropped media-next, perhaps you can just "git fetch git://linuxtv.org/pinchartl/media.git vsp1-kms-20151206 && git merge FETCH_HEAD~3" yourself? 10:08 < dammsan> i may simply not move forwards 10:08 < dammsan> for this test case 10:08 < geertu> That's another solution ;-) 10:08 * geertu shuffles agenda topics 10:08 < dammsan> i'm yet to poke with the external interrupt pins 10:08 < geertu> BUG_ON and NULL pointer dereference after merging media-next 10:08 < dammsan> yum 10:09 < geertu> and another one after merging in vsp1-kms-20151206 and solving the (many) conflicts 10:09 < dammsan> wolfram was talking about some lack of runtime pm in the gpio driver, do you know about that? 10:09 < dammsan> (sorry for not putting htat on the agenda) 10:09 < horms> dammsan: do you plan to follow up on "ARM: shmobile: IPMMU compat string SoC part number" > 10:09 < horms> ? 10:10 < dammsan> horms: i was actually not sure what the current state was - the DT binding was accepted I think? 10:10 < horms> i see an email from myself saying that i queued them up 10:11 < horms> i'll check 10:11 < geertu> dammsan: it's more a lack of runtime PM handling in the irq subsystem 10:11 < geertu> irq-renesas-irqc just does pm_runtime_get_sync() for its whole lifetime 10:11 < dammsan> geertu: sure - is it worth adding a task for that? 10:11 < dammsan> horms: thanks 10:12 < dammsan> geertu: yeah, irq-renesas-irqc is good and simple =) 10:12 < geertu> we can do the same in rcar-gpio, but then we loose al saving we did before 10:13 < geertu> AFAIK the Tegar people are working on it 10:13 < geertu> s/Tegar/Tegra/ 10:13 < dammsan> yeah, that seems a step in the wrong direction 10:13 < dammsan> we need some sort of handling for this 10:13 < horms> dammsan: ok, i see, i deffered them pending the driver update 10:13 < dammsan> eventually 10:13 < horms> has that happened? 10:14 < dammsan> the DT binding has been appied 10:14 < horms> ok 10:14 < horms> i was waiting on that 10:14 < dammsan> according to the maintainer 10:14 < dammsan> i'm not sure if it is in next or not 10:14 < horms> sorry if my email wasn't clear about me waiting on that 10:14 < dammsan> horms: sorry for not testing your gose GPIO yet 10:14 < geertu> Unfortunately the core ARM irqchip people don't seem to have much graps for Runtime PM and PM (power and clock) Domains 10:14 < dammsan> no worries 10:15 < horms> no problem! 10:15 < geertu> s/graps/grasp/ 10:15 < dammsan> s/for Runtime PM and PM/g 10:15 < dammsan> oh, and i found out that some of the IPMMU instances are located in power domains =) 10:16 < geertu> next-20151214 only has "renesas,ipmmu-vmsa" 10:16 < dammsan> so we need multiple IPMMUs with bindings together 10:16 < dammsan> it may take someeeeeeeeeeee time 10:17 < dammsan> geertu: how is the cpg-mssr driver merge looking? 10:17 < geertu> dammsan: Mike is hiding somewhere 10:17 < geertu> No review, no response to pull request 10:18 < geertu> (he's on #periperi now, so he may read everything we write ;-) 10:19 < uli___> morning. sorry, overslept... 10:20 * geertu added task "gpio-rcar,v4.6,noplan,?,Fix Runtime PM with GPIO interrupts 10:21 < dammsan> geertu: i ran into mike the other day, and he said he had looked over the code 10:21 < dammsan> lets see what happens 10:21 < geertu> dammsan: He's in Tokyo? 10:22 < dammsan> he was for a brief moment 10:22 < geertu> We should reduce his travel budget ;-) 10:22 < horms> dammsan: [off-topic] do you plan to revisit "[PATCH 00/08] clocksource: sh_cmt: DT binding rework"? 10:22 < dammsan> yes, eventually =) 10:23 < horms> thanks 10:23 < dammsan> and do the same for TMU 10:23 < dammsan> some of the DT bindings got acked 10:23 < horms> ok, for some reason TMU isn't on my radar 10:24 < dammsan> it may be low priority stuff 10:24 < horms> it would be moderately helpful if the series also covered r8a7793 and 92 10:24 < dammsan> i should really deal with that when i resend 10:24 < dammsan> oh, 10:24 < dammsan> that reminds me 10:24 < dammsan> do we need soc-part-number for the DMAC devices in DT? 10:25 < dammsan> i recall that they were missing 10:25 < horms> what do you mean? 10:25 < horms> if you are talking about compat strings 10:25 < horms> they are either done, in progress or on my list 10:25 < horms> i can check on a case by case basis if you need the information 10:25 < geertu> [PATCH] dmaengine: rcar-dmac: Document SoC specific bindings 10:26 < dammsan> yeah, but thing have improved 10:26 < dammsan> thanks!! 10:26 < horms> slowly the gaps are being filled in 10:26 < dammsan> please ignore my comment about DT DMAC 10:26 < dammsan> very nice 10:27 < horms> with cmt, the r8a7793 appears to be using an undocmented per-soc binding. i was going to fix it but noticed you are planning to change the world 10:27 < dammsan> yeah, that's the idea 10:27 < horms> ... and i finally got around to asking you about it 10:27 * geertu still has Magnus' CMT series in his local tree 10:28 < dammsan> yes 10:28 < dammsan> will fix 10:30 < dammsan> geertu: is it possible to work around the GPIO issue in the CPG-MSSR driver somehow? 10:30 < dammsan> for short term 10:30 < dammsan> keeping the clock enabled or something 10:30 < geertu> Yes, but that only helps r8a7795 10:30 < dammsan> i'm mainly concerned about that one for the short term 10:31 < dammsan> it is not super important 10:31 < dammsan> but i'd like the r8a7795 code to be rock solid 10:31 < geertu> Oops, next doesn't have CLK_ENABLE_HAND_OFF yet 10:32 < geertu> So if you add the GPIO clocks to r8a7795_crit_mod_clks[], they won't be registered 10:32 < geertu> and rcar-gpio won't work at all 10:33 < dammsan> ok, i was hoping on just increasing their use count temporarily 10:33 < dammsan> but no big deal 10:34 < geertu> yeah, that's what renesas-cpg-mssr.c really should do if CLK_ENABLE_HAND_OFF is not enabled, but I took a shortcut, as it doesn't matter for intc-ap 10:34 < geertu> Topic 2. SMP enablement on Gen3 10:34 < geertu> Seems we have it ;-) 10:35 < geertu> It works for the CA57s 10:35 < geertu> Haven't tried Dirk's newer patch for CA53 yet 10:35 < horms> ok, gerat 10:35 < geertu> (does anyone know who Dirk Behme is?) 10:35 < dammsan> so i'd like to order the enablement here somehow 10:35 < horms> no 10:36 < dammsan> because the cache, dmac and smp tie together 10:36 < dammsan> also, for SMP, if we enable CA53 then the system will become strange 10:36 < horms> i was kind of expecting some feedback to be given to dirk... 10:37 < geertu> big.LITTLE is strange? :-) 10:37 < dammsan> unless the big little patch stack has been merged 10:37 < dammsan> is the scheduler aware yet? 10:37 < dammsan> last time i bother checking ARM assigned summer interns to the scheduler work 10:37 < geertu> I don't know. There should be zillions of big.LITTLE SoCs in use by now 10:38 < dammsan> running upstream? 10:38 < dammsan> on r8a7790 we worked around it by only enabling the Big cores 10:38 < dammsan> by default 10:38 < dammsan> and if little boot mode was selected we used little only 10:38 < dammsan> this may not be needed with the current scheduler 10:39 < dammsan> but we should check before enabling both big + little 10:39 < geertu> Does it matter much that the scheduler is aware? 10:39 < geertu> I guess 4xCA57 + 4xCA53 is better than 1xCA57 10:39 < dammsan> if you execute something and it is not deterministic 10:39 < dammsan> and the tasks do not migrate 10:39 < dammsan> then it turns to poo IMO 10:40 < dammsan> I think the end goal should be 4 + 4 10:40 < dammsan> or whatever is on other Gen3 SoCs 10:40 < dammsan> so i feel we need to control the enablement somehow 10:41 < dammsan> but maybe you guys are already doing that, and i'm lost as usual? =) 10:41 < dammsan> what is the opinion? 10:41 < horms> I was hoping for feedback from you 10:41 < dammsan> i see 10:42 < horms> my opinion is, as yours, that we should be careful 10:42 < dammsan> i've been overfocusin on IPMMU due to sudden customer demand... 10:42 < dammsan> and i think i shared some "long term" plan for our upstream development


context:
space:
mode: