renesas/periject.git - Renesas periject clone

diff options

author	Geert Uytterhoeven <geert+renesas@glider.be>	2021-04-01 09:10:20 +0200
committer	Geert Uytterhoeven <geert+renesas@glider.be>	2021-04-01 09:14:12 +0200
commit	829b6f4e506c9c3c5c2d1242585923b5894090d0 (patch)
tree	9204e240347df7232342cd0393c5dc25c16d53cf /wiki/2016-10-miniperi/out_6.jpg
parent	cc7f3c21e1174cfe37602c31abf4da8b437b2b93 (diff)

farm: magnus: Remove bogus H3 in M3-W+ entry

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Diffstat (limited to 'wiki/2016-10-miniperi/out_6.jpg')

0 files changed, 0 insertions, 0 deletions

Core-chat-meeting-2017-07-06 Before Lunch/Dinner 10:52 < geertu> Welcome to today's Core Group Chat! 10:52 < geertu> Let's start with the status updates 10:53 < geertu> Just like with MultiMedia, feel free to ask questions if there's anything you find unclear, but please keep the questions limited to task status reporting and planning 10:54 < geertu> First is Jacopo 10:54 < jmondi> here I am 10:54 < jmondi> very few core work from my side lately 10:54 < jmondi> A) 10:55 < jmondi> - RZ pinctrl finally part of v4.13 pull request 10:55 < geertu> Yeah! 10:55 < wsa_> cool 10:55 < jmondi> finally, yes :) 10:55 < jmondi> B) 10:55 < jmondi> add to GR-Peach pinctrl nodes 10:56 < jmondi> ping Simon for deferred patches for genmai's dts 10:56 < jmondi> C) 10:56 -!- horms [~horms@softbank126083087124.bbtec.net] has joined #periperi 10:56 < jmondi> none strictly for core 10:56 < jmondi> --eot-- 10:57 < geertu> Thank you, Jacopo 10:57 < geertu> Next one is Simon 10:57 < horms> Hi, sorry about my poor connection today 10:57 < horms> I have no updaes for the core group as I have no tasks at this time. Geert asked me to look into CPUFreq next quarter and I intend to make a start on that too. 10:57 < horms> s/too/soon/ 10:58 < geertu> Thank you, Simon 10:58 < geertu> Next is Niklas 11:00 < neg> A) 11:00 < neg> - Not much, I tested some of Geerts clock suspend/resume patches 11:00 < neg> together with RAVB WoL and it works. 11:00 < neg> B) 11:00 < neg> - Not much, if stuff is blocked in Multimedia land I will work with 11:00 < neg> core tasks. Either on my proposed additional task of emergency 11:00 < neg> shutdown or starting to execute the plan to improve dmaengine for 11:00 < neg> rcar-dmac test case (see [periperi] test for races in rcar-dmac). 11:00 < neg> C) 11:00 < neg> - Not sure if I should repost my RAVB WoL patch with a work around for 11:00 < neg> the clock or wait untill Geerts suspend/resume work for clocks is 11:00 < neg> picked up. I know I asked this before but I have lagged in posting 11:00 < neg> the driver with the workaround and since then Geerts patches have 11:00 < neg> made progress. 11:00 < neg> --EOT-- 11:01 < geertu> Regarding C, I still think having a workaround for now would allow it to make progress. 11:01 < geertu> Independent of clock fixes. 11:01 < neg> OK then I will include the fix and repost once I also tested it on the new board I recived the other day 11:02 < geertu> Without it, the RAVB WoL support can only enter one cycle after the clock fixes, which would be v4.15 at earliest 11:02 < geertu> Thanks, Niklas! 11:02 < geertu> Next is Laurent 11:04 < pinchartl> nothing on my side 11:04 < pinchartl> although I've been pinged by Rob Clark 11:04 < pinchartl> who wanted to know if we could exchange review on IOMMU drivers 11:04 < pinchartl> he has a patch series he needs to get reviewed, and we have IPMMU patches 11:04 < pinchartl> but I won't have time for that 11:05 < geertu> This is for non-Renesas hardware? 11:07 < pinchartl> yes 11:08 < pinchartl> that's the idea behind trading reviews :-) 11:08 < geertu> Sure 11:08 < geertu> If you don't have time, perhaps Magnus can review them? 11:08 < dammsan> sure 11:08 < dammsan> i also need to review some code from laurent, but adding it to the list is good 11:09 < geertu> OK. 11:09 < geertu> Thanks Laurent! 11:09 < geertu> Next is Geert 11:09 < geertu> A) What have I done since last time 11:09 < geertu> - Second RFC for CPG/MSSR module clock restore during resume 11:09 < geertu> - Fixed SMP on R-Car E2 11:09 < geertu> - Started missing DT descriptions for R-Car Gen2 11:09 < geertu> - Additional task preparations 11:10 < geertu> B) What I plan to do till next time 11:10 < geertu> - Continue missing DT descriptions for R-Car Gen2 11:10 < geertu> - Suspend/resume for PFC 11:10 < geertu> - CPG/MSSR for R-Car D3 11:10 < geertu> - Mark periupport priority < H commits that are in linux-next 11:10 < geertu> C) Problems I have currently 11:10 < geertu> - Proper R-Car Gen2 Generic Counter init may need a bootloader shim 11:11 < dammsan> shall we discuss that topic later? 11:11 < geertu> --EOT-- 11:11 < geertu> Sure. 11:11 < geertu> Next is Shimoda-san 11:11 < shimoda> A) 11:11 < shimoda> - Make USB2.0 clock selector driver as a CCF driver. 11:11 < shimoda> B) 11:11 < shimoda> - Continue to improve USB2.0 clock selector driver because it got some feedback from community. 11:11 < shimoda> - Need reply about R-Car D3's CPG things to Geert-san 11:11 < shimoda> C) 11:11 < shimoda> - Nothing 11:11 < shimoda> -- EOT -- 11:12 < geertu> Thanks, Shimoda-san! 11:12 < geertu> Next is Morimoto-san 11:12 < morimoto> A) = B) = C) = NULL, sir 11:12 < morimoto> --EOT-- 11:13 < geertu> Thank you, Morimoto-san! 11:13 < geertu> Next is Marek 11:13 < marex-cloud> A) continue on DT conversion of U-Boot, SH SDHI is converted to DM and probes from DT 11:13 < marex-cloud> B) NULL 11:13 < marex-cloud> C) MFD maintainer is difficult and blocks the Rohm PMIC patches for no good reason 11:13 < marex-cloud> Question: Is SH SDHI a Renesas/Hitachi block or is that bought from somewhere, ev. where ? I recently found during my plumbing in the U-Boot SDHI driver that Socionext Uniphier has the same block in it ... 11:14 < geertu> You also posted VC6 patches, right? 11:14 < marex-cloud> geertu: that's core or IO again ? 11:14 < geertu> clocks are core 11:14 < marex-cloud> U-Boot now has two drivers -- SH SDHI and Uniphier SD -- for the same block, we need to fix this 11:14 < dammsan> it is matsushita IP i think 11:14 < marex-cloud> also, I'm in touch with Socionext acquitance and he was about to send uniphier SD driver for linux, yet we already have SH MMCIF driver for the same block 11:15 < marex-cloud> dammsan: ah ... 11:15 < geertu> drivers/mmc/host/tmio_mmc.c says Toshiba? 11:15 < geertu> Linux:drivers/mmc/host/tmio_mmc.c says Toshiba? 11:15 < dammsan> it was reverse engineered from toshia 11:15 < wsa_> the oldest datasheet i have is also from toshiba 11:15 * marex-cloud rolls eyes ... 11:16 < geertu> Regarding C, kbingham will meet Lee on Monday? Should we discuss this later today? 11:16 < marex-cloud> geertu: but what's sh_mmcif.c about ? 11:16 < marex-cloud> geertu: gladly 11:16 < wsa_> wait, mmcif is something else 11:17 < geertu> Too many Renesas ancestors... (Toshiba and Matsushita even aren't) 11:17 < wsa_> Gen2 had SDHI for SD and MMCIF for MMC (simply spoken) 11:17 < marex-cloud> http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/uniphier-sd.c;h=3c462bd5835e9e4efae745791fdaaff80a4c2af5;hb=HEAD 11:17 < marex-cloud> here is a better register description ^ 11:17 < wsa_> Gen3 has only SDHI which gained MMC support 11:18 < geertu> Isn't this I/O? :-) (oh, U-Boot is core) 11:18 < kbingham> marex-cloud: geertu: If C) is causing problems I can see if I can help somewhere yes. Can someone send me a patch reference / ML links please ? 11:19 < marex-cloud> kbingham: https://patchwork.kernel.org/patch/9707899/ 11:19 < marex-cloud> wsa_: I only have Gen3 , so I'm talking about SDHI 11:20 < jmondi> I need to be away for ~15 mins... If IO report starts and I'm named, I may reply a bit late (No IO updates btw).. sorry about this 11:20 < marex-cloud> wsa_: which looks like the same block that's in Uniphier ... see above 11:20 < geertu> Let's continue with core... 11:20 < geertu> Thank Marek! 11:20 < geertu> Next is Magnus 11:20 < marex-cloud> geertu: so uh, I'd like to know which block it is ^_^' 11:20 < marex-cloud> we can do that later 11:21 < dammsan> [1;5Dno special update from me thanks 11:22 < geertu> Thank you, Magnus! 11:22 < geertu> Next is Ulrich 11:22 < uli___> nothing to report here 11:22 < dammsan> regarding SDHI, search for mn5774 for perhaps related panasonic IP 11:22 < marex-cloud> [11:22:28] <Masahiro Yamada> I asked some hardware engineers. Looks like Panasonic/Matsushita IP. 11:22 < geertu> Thank you, Uli! 11:22 < marex-cloud> dammsan: thank you 11:23 < geertu> So far for status reporting from the regular core members. 11:23 < marex-cloud> dammsan: might be worth adding that piece of trivia to the driver / DT 11:23 < geertu> Anything core-related from Wolfram or Kieran? 11:24 < wsa_> nope 11:24 < kbingham> geertu: I've ordered a new BusBlaster 11:24 < kbingham> I can't get my existing one working with OpenOCD (its an IMG varient ... ugh ) 11:24 < wsa_> marex-cloud: the register description in the link above is definately SDHI 11:24 < geertu> v4? 11:25 < kbingham> geertu: Actually I've ordered the v3 ... for better compatibility - With a desire that I should hope to see how to get JTAG connected at somepoint using OpenOCD. 11:25 < kbingham> But it's a desire rather than a task at present. 11:25 < marex-cloud> wsa_: roger 11:25 < geertu> OK. Then I think we can continue with I/O? 11:26 < geertu> wsa_: The mic is yours 11:26 < wsa_> oh, one question: any estimate for SDHI PFC settings for Salvator-XS? 11:26 < dammsan> geertu: if no further update is needed for additional tasks then i will submit, is that ok? 11:27 < geertu> wsa_: PFC for I/O devices is typically handled by the person doing the I/O device. Use BSP as a reference. 11:27 < wsa_> geertu: i see. ok, thanks 11:27 < geertu> dammsan: Fine for me (I had no feedback from Niklas and Simon?). 11:27 < dammsan> good, thanks 11:28 < neg> geertu: I'm sorry my mail that stated I was happy with the draft is stuck in my draft folder for som reasnon. Sorry about that 11:28 < geertu> neg: No problem, as long as it was a happy response ;) After Lunch/Dinner 14:09 < geertu> dammsan: I take it you're the expert on early (boot-time wise) R-Car Gen2 hacks? 14:10 < dammsan> yes i believe so 14:10 < geertu> Or not, from the lack of comments on my patches? ;-) 14:10 < dammsan> hehe, i am ducking too much 14:11 < dammsan> you were talking about arch timer? 14:11 < geertu> and generic counter 14:11 < dammsan> i have little knowledge about the latter 14:11 < dammsan> did it use a different name earlier? 14:12 < dammsan> there is global timer too 14:12 < geertu> not AFAIK 14:12 < dammsan> i recall 14:12 < dammsan> what is it? 14:12 < jmondi> I'm bothering neg in private now, if my point on device tree shuffling was the only one to discuss about this afternoon 14:12 < dammsan> some sort of timer i guess? per-cpu? 14:13 < geertu> I think it's the real counter behind the arch timer 14:14 < geertu> It has the CNTFID0 and CNTCR register, being accessed in rcar_gen2_timer_init() 14:14 < dammsan> ok i see. different from arch timer and twd 14:14 < geertu> If it doesn't run, arch timer also doesn't work 14:14 < dammsan> i see 14:14 < dammsan> i guess that code was developed without global timer in mind 14:15 < dammsan> focus on arch timer instead 14:15 < geertu> unlike arch timer it's memory mapped 14:15 < geertu> using a hardcoded address 14:16 < geertu> The good news is that Mark Rutland doesn't want it to have DT bindings, nor to appear in DT 14:16 < geertu> ;-) 14:16 < dammsan> ok, but how is that different from say GIC 14:16 < geertu> However, according to him it should be handled in the boot loader/firmware 14:16 < dammsan> it is not preset at base_addr + offset? 14:16 < geertu> or a bootloader shim 14:17 < dammsan> is it available on single code cortex-a9? 14:17 < dammsan> s/code/core/g 14:17 < geertu> /* Remap "armgcnt address map" space */ 14:17 < geertu> base = ioremap(0xe6080000, PAGE_SIZE); 14:18 < geertu> I don't know. Perhaps not. We only need to play with it on Gen2, i.e. A15/A7 14:18 < dammsan> ok, however the upstream global timer driver mentions cortex-a9 14:18 < dammsan> so we may be able to use it on rz/a1 14:18 < dammsan> but anyway 14:19 < geertu> It's not global timer, but generic counter' 14:19 < dammsan> i think that 0xe6080000 is base address + 0x80000 14:19 < dammsan> where base happens to be 0xe6000000 on r-car gen2 14:20 < dammsan> probably matches gic and other arm peripherals 14:20 < dammsan> i may be wrong 14:20 < dammsan> but usually there is a single base address for the arm stuff 14:20 < geertu> GIC is @f1001000 14:20 < dammsan> hm 14:20 < dammsan> arch timer same? 14:20 < geertu> See R-Car Gen2 Section 9.2 14:21 < geertu> No, arch timer uses mrc/cr asm, not mmio 14:21 < geertu> It refers to DDI0406C2c_arm_architecture_reference_manual Appendix D.3 Counter module control and status registers. 14:21 < geertu> but it's App. D.5 in later revisions of that document 14:21 < dammsan> right, and we are not using twd on those more recent 32-bit socs 14:22 < geertu> BTW, it's also mentioned in the Gen3 docs 14:22 < geertu> Both say: Set bit 0 in CNTCR to 1 to start the Generic Counter when the CPU is placed in the secure mode. 14:23 < geertu> which is not done on Gen2 boards. 14:23 < dammsan> interesting 14:24 < dammsan> i recall that one of the timer workarounds were related to undocumented clock frequency dividing based on the MD pins 14:24 < dammsan> maybe that is different than the issue you are mentioning 14:24 < geertu> Yes, the frequency depends on the crystal (H2/M2) or ZS clock (V2H/E2), which is somehow related to MD settings (set MD according to crystal) 14:25 < geertu> U-boot inits it on iMX in arch/arm/imx-common/syscounter.c 14:25 < geertu> We can fix U-Boot, but I guess we needs backwards-compatibility with whatever is in use 14:27 < dammsan> i think we want to avoid breaking stuff 14:27 < geertu> Indeed. 14:28 < geertu> So either we keep the existing code, or move it to a "bootloader shim" 14:28 < geertu> As it doesn't involve DT, I think the easiest is to keep the existing code ;-)


context:
space:
mode: