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.