diff options
Diffstat (limited to 'wiki/Chat_log/20170706-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20170706-core-chatlog | 336 |
1 files changed, 336 insertions, 0 deletions
diff --git a/wiki/Chat_log/20170706-core-chatlog b/wiki/Chat_log/20170706-core-chatlog new file mode 100644 index 0000000..5dd3dda --- /dev/null +++ b/wiki/Chat_log/20170706-core-chatlog @@ -0,0 +1,336 @@ +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 ;-) +14:28 < dammsan> i recall that some data sheet mentioned that the arch timer was supposed to run on say 13MHz fixed but in reality the MD pin setting divided it in two or so +14:29 < geertu> Yes, the register is programmed for 13 MHz, while reality is 10 or 32.5 MHz +14:29 < geertu> Aha, u-boot:include/configs/salvator-x.h:#define COUNTER_FREQUENCY 0xFE502A /* 16.66MHz from CPclk */ +14:29 < dammsan> ok that makes sense +14:29 < geertu> The current code probably breaks virtualization +14:30 < dammsan> i guess developing a parallel workaround in that "bootloader shim" doesnt hurt +14:30 < dammsan> especially if it can run in parallel with the existing code +14:30 < dammsan> then we can phase out the in-kernel workaround over time +14:30 < dammsan> also fixing u-boot makes sense +14:31 < geertu> Any examples of "bootloader shim" out there? +14:31 < dammsan> not sure myself +14:31 < dammsan> i don't even know what it is +14:33 < dammsan> my feeling is that this kind of workaround should be in the CPG or MD-pin code +14:33 < geertu> AFAIK it's something that runs after the bootloader, and before Linux +14:33 < dammsan> under compressed/? +14:33 < dammsan> but it is possible to boot vmlinux too, right? +14:34 < geertu> I think even separate from the kernel +14:34 < dammsan> hm, i'm not too fond of throwing stuff over the fence and breaking things just for the sake of cleanups +14:35 < geertu> me neither +14:35 < dammsan> also we used to boot linux directly from the reset vector +14:35 < dammsan> this disappeared with the multi-arch migration +14:36 < geertu> Documentation/arm64/booting.txt has requirements for the state before entering Linux +14:36 < geertu> - Architected timers +14:36 < geertu> CNTFRQ must be programmed with the timer frequency and CNTVOFF must +14:36 < geertu> be programmed with a consistent value on all CPUs. If entering the +14:36 < geertu> kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where +14:36 < geertu> available. +14:36 < dammsan> but if we could have a board-specific compressed header then that would be fine +14:36 < dammsan> it does not say "correct frequency" =) +14:37 < dammsan> even if i would have preferred that +14:37 < dammsan> and this is on 32-bit linux, right? +14:37 < geertu> Yes +14:37 < geertu> 32-bit +14:38 < dammsan> having a well documented state of boot is not a bad thing though +14:38 -!- horms [~horms@2001:470:fe2c:302::1000] has joined #periperi +14:38 < dammsan> but i doubt that existed on 32-bit arm? +14:39 < dammsan> we could argue that we want to boot RZ/A1 directly into linux +14:39 < dammsan> and because of that need to perform various setup early on +14:39 < dammsan> of course it can be argued that the code should be somewhere else +14:40 < dammsan> i guess it is up to the maintainers in the end +14:40 < geertu> RZ/A1? +14:40 < horms> coming in late here, but we could revive the early-boot linux work that magnus and I did some years ago to strengthen our hand if it makes sense +14:40 < geertu> This is al about R-Car Gen2 and RZ/G1 +14:40 < dammsan> that is also 32-bit cortex-a9 +14:41 < dammsan> yeah i understand, just thought it may be useful on cortex-a9 too, but perhaps that was the global timer instead +14:41 < dammsan> horms: yeah something like that may make sense +14:42 < dammsan> it is not so easy to go against the desire of the arm guys though +14:43 < dammsan> for the timers i would have preferred to use CCF and then MD pin detection for the clock frequency workaround +14:43 < geertu> dammsan: All of that runs way too late, I think +14:43 < dammsan> but instead a static DT property was preferred, or preprogrammed value +14:43 < dammsan> that might be so +14:43 < geertu> The arch timer frequency can be put in DT. That also works. +14:43 < geertu> However, it's deprecated, and breaks virtualization +14:44 < dammsan> doesn't it also create mismatch if the MD pin setting is different from DT? +14:44 < dammsan> so it seems dynamic to me +14:44 < geertu> dammsan: Yes, but if you change MD, you should change the crystal, too +14:45 < dammsan> so the existing code is working around an incorrect setup? +14:45 < geertu> But we stopped using MD to derive the arch timer frequency a long time ago. These days we look at the extal clock-frequency in DT +14:46 < geertu> On V2H/E2, the value is hardcoded. It's ZS/8, but ZS must be fixed at 260 MHz anyway (unless you e.g. change the crystal without updating MD, but that's out-of-spec) +14:47 < dammsan> hm... +14:47 < dammsan> so there is no divider in the hardware? +14:48 < geertu> Somewhere there is, but it's not programmable: arch timer freq is either extal/2, or zs/8 +14:48 < dammsan> and that selection is done run-time, or via static DT configuration? +14:49 < dammsan> sorry for being a bit unclear =) +14:50 < dammsan> just wondering if we could solve multiple issues by assuming the clock to be more dynamic +14:51 < geertu> dammsan: based on SoC compatible (H2/M2 use extal/2, V2H/E2 use ZS/8) +14:51 < dammsan> ok that makes sense +14:51 < dammsan> thanks! +14:52 < dammsan> so what to do? =) +14:53 < geertu> I'll have a look to see if the shim is doable +14:54 < dammsan> is this the only workaround that is left for 32-bit arm? +14:54 < dammsan> for our socs i mean? +14:54 < dammsan> if we could move multiple things to that shim then that would be nice +14:54 < geertu> The other one is the CNTVOFF thingy +14:55 < geertu> We currently do that on the boot CPU of CA7 systems only. +14:55 < geertu> E2 needs it on all CPU cores. +14:56 < shimoda> oops, i kept to join this, but i worked other things :) i go home now, byebye! +14:56 -!- shimoda [~shimoda@relprex3.renesas.com] has quit [Quit: WeeChat 0.4.2] +14:56 < dammsan> i see +14:56 < geertu> No idea if shims can easily run on all CPUs. Probably not, as it involves actually booting them. +14:56 < geertu> However, Marc Zyngier doesn't seem to be opposed to doing it in the kernel. +14:57 < dammsan> the tricky part is that the secondary cpu cores come up from reset +14:57 < dammsan> so we need to setup stuff for those anyway +14:57 < geertu> He did say we also need it on CA15, as A15/A7 are very similar, and that it's sheer luck it worked for us. +14:57 < dammsan> yes that is inline with what i've seen +14:57 < dammsan> the power-on-reset value happened to be correct on CA15 +14:58 < dammsan> or at least not wrong +14:58 < dammsan> or correct enough to boot =) +14:58 < geertu> Always doing these few asm instructions when a CPU core boot won't delay it too much... +14:59 < dammsan> thats right +14:59 < dammsan> there are also cache workarounds needed for secondary cpus +14:59 < geertu> BTW, how can you boot from CA7 on (remote) lager? +14:59 < geertu> The cache workarounds may be handled by generic code +14:59 < dammsan> maybe these days +15:00 < dammsan> they used to be local code in some bsp +15:00 < dammsan> eventually made it into upstream and then got consolidated i think +15:00 < dammsan> would you like to boot CA7 on lager? +15:00 < geertu> So if we don't have to describe the gneric counter in DT, the only piece missing is ICRAM for SMP bringup (patches sent) +15:01 < dammsan> only piece missing for what? +15:02 < geertu> Having everything described in DT, so we can boot without relying on any hardcoded address in the kernel +15:02 < dammsan> ok i see +15:02 < dammsan> sounds good to me! +15:02 < geertu> I want to have a single flag day for all of that for Gen2 (incl. CPG/MSSR, SYSC, RST), so we can drop all workaround code at once. +15:03 < dammsan> i guess this is part of dropping the code in the mach-shmobile directory? +15:03 < geertu> We have two more places that use hardcoded addresses, but the devices are described in DT, so they need kernel code changes only: +15:04 < geertu> Gen2,?,noplan,?,Use IRQC in DT for da9063/da9210 regulator quirk +15:04 < geertu> Gen2,?,noplan,?,Use RST in DT for secondary CPU bringup +15:04 < geertu> Dropping it completely is not so easy. +15:04 < geertu> Not relying on hardcoded addresses is my goal. |