path: root/wiki/Chat_log/20180906-core-chatlog

Core-chat-meeting-2018-09-06

09:37 < geertu> Welcome to Today's Core Group Meeting
09:38 < geertu> Agenda:
09:38 < geertu> 1. Status Updates
09:38 < geertu> 2. Discussion Topics
09:38 < Marex> shimoda: but I think this would be just a few transistors more and would make the software very happy
09:38 < Marex> shimoda: but maybe that's indeed it :)
09:38 < geertu> Marex: Changing software is easier than adding transistors ;-)
09:39 < geertu> Topic 1. Status updates
09:39 < Marex> shimoda: I'll keep you posted on the ATF news ASAP
09:39 < geertu> A) What have we done since last time:
09:39 < geertu> Kaneko-san got M3-N CPUFreq merged.
09:39 < geertu> Marek cleant up the TMU driver in U-Boot slightly.
09:39 < geertu> Morimoto-san worked on PeriJect and Ebisu-4D export (arrived at Simon/Geert).
09:39 < geertu> Niklas fixed the return type of dma_set_max_seg_size().
09:39 < geertu> Shimoda-san says the Renesas Vietnam test team finished testing of the new
09:39 < geertu> LTSI v4.14 snapshot, and he submitted a patch to revise usb2 properties on
09:39 < geertu> R-Car Gen3.
09:39 < geertu> Geert reviewed the second socfpga and additional rcar-i2c submissions for
09:39 < geertu> LTSI, worked on defconfig updates, tested s2ram on Ebisu-4D (fails), sent
09:39 < geertu> his first clk and pfc pull requests for v4.20, and worked through his
09:39 < geertu> holiday backlog.
09:39 < geertu> B) What we plan to do till next time:
09:39 < geertu> Morimoto-san will ship Ebisu-4D to Magnus.
09:39 < geertu> Shimoda-san says the Renesas Vietnam test team will test 4.14-ltsi-rc1 when
09:39 < geertu> released.
09:39 < geertu> Geert will continue QEMU GPIO virtualization, handle SYSC and PFC errata,
09:39 < geertu> and test 4.14-ltsi-rc1 when released.
09:40 < geertu> C) Problems we have currently:
09:40 < geertu> Morimoto-san wants the team to start using periject from October, but
09:40 < geertu> Magnus/Laurent haven't accepted it yet.
09:40 < geertu> Niklas is looking for a solution to control the SDn/SDnH clocks properly.
09:40 < geertu> Greg is too busy with normal stable updates, but promised to release
09:40 < geertu> 4.14-ltsi-rc1 this week.
09:40 < geertu> ---
09:40 < geertu> Anything I missed?
09:41 < pinchartl> geertu: do you want to discuss the periject topic ?
09:41 < geertu> pinchartl: Yes ;-) But let's do the technical one first?
09:42 < geertu> Topic 2. Discussion Topics
09:42 < geertu> A) SDn/SDnH clocks
09:42 < pinchartl> geertu: sure, I just wanted to know whether I should prepare myself mentally :-)
09:42 < geertu> pinchartl: Fetch the booze ;-)
09:42 < horms> What are the LTSI-4.14 backporting implications of the patch that Shimoda-san posted?
09:42 < geertu> horms: Which patch?
09:43 < geertu> USB2 properties?
09:43 < horms> Yes
09:44 < horms> Reading the above for a second time, perhaps LTSI and the USB2 properties patch are only related by virtue of being handled by Shimoda-san
09:44 < wsa_> neg: you there?
09:45 < neg> wsa_: yes
09:45 < shimoda> geertu: horms: usb2 properties patche is for mainline first, not LTSI only
09:45 < shimoda> s/patche/patch/
09:45 < horms> ok
09:45 < wsa_> neg: before I forget, HS400 on H3 ES1.0 is considered broken and we do not support it
09:45 < geertu> horms: USB2 properties come with DT binding updates, driver updates.
09:45 < wsa_> there should be a patch in the BSP for that, too
09:46 < neg> wsa_: OK good to know, will reduce the number of tests needed :-)
09:46 < horms> geertu: unerstood. I now recall the patches in question. I guess that means its not suitable for LTSI-4.14 at this point. But we can discuss if desired
09:46 < geertu> Some parts I don't fully grasp yet. And some additional clocks are not documented in the DT bindings?
09:46 < geertu> horms: Indeed. TBD when fully accepted.
09:46 < neg> wsa_: Then the clock issue only effects H3 ES2.0 and M3-W ES1.*
09:47 < wsa_> neg: right, the 4tap ones
09:47 < geertu> One issue is the SDnH clocks are referred nowhere.
09:47 < shimoda> horms: i agree this usb2 properties patch is not suitable for the LTSI
09:47 < geertu> Which is due to MSTP clocks being a single clock, while the "module stop" operation may apply to multiple clock signals provided to the module.
09:48 < shimoda> geertu: i posted https://patchwork.kernel.org/patch/10589889/ , but not enough? (especially host and phy?)
09:48 < wsa_> so, the problem with the SDHI clocks is that we want to request 200MHz for HS400 which needs different setting that 200MHz for SDR104 depending if we have a 4tap SoC or 8tap SoC, right?
09:50 < neg> wsa_: I have not looked at what setting SDR104 needs, but for HS400 on 4tap we need a different setting then on 8tap
09:50 < geertu> neg: 4tap or 8tap is a property of the SoC, not of the SDHI mode?
09:51 < geertu> shimoda: What about the added clocks to the ehci/ohci nodes?
09:51 < neg> geertu: yes 4tap = H3 ES1.* (broken no concern) ES2.0 and M3-W ES1.*
09:51 < wsa_> if you mean HS400 etc as "SDHI mode", then yes, it is a property of the SoC
09:51 < geertu> OK, so soc_device_match() can do?
09:52 < wsa_> neg: please take SDR104 into account as well, we need a complete solution
09:52 < geertu> I thought the clock settings depends on the HSx/SDRx mode, too, which the clock driver cannot lnow about.
09:52 < geertu> s/lnow/know/
09:52 < neg> wsa_: will do
09:53 < wsa_> the 4tap need a different setting for 200MHz depending on SDR104 or HS400
09:53 < wsa_> the BSP solves this by requesting 400MHz
09:53 < geertu> So the clock settings purely depend on (A) requested clock rate from SDHI driver and (B) SoC model and revision?
09:53 < wsa_> which looks as a workaround to me
09:54 < wsa_> clock rate, mode (SDR or HS), SoC revision
09:55 < wsa_> model & revision
09:55 < shimoda> geertu: for now, gen3 ehci/ohci is related to usb/usb-ehci.txt. But, should I add ehci-rcar for instance? Or, revise usb-ehci.txt somehow?
09:56 < geertu> wsa_: And the clock driver only knows clock rate and SoC revision, it doesn't know about SDR or HS, right?
09:56 < wsa_> yes
09:56 < wsa_> I wonder if exposing SDnH is the proper solution
09:57 < geertu> I was just going to ask about that...
09:57 < geertu> I don't fully understand the cpg_sd_div_table[]
09:57 < wsa_> Then, the driver can handle both clocks individually
09:57 < geertu> What's the physical clock difference between HS200 and HS400?
09:57 < wsa_> we need to take care of backward compatibility then
09:57 < Marex> geertu: SDR vs DDR
09:58 < wsa_> geertu: 0. It is DDR
09:58 < Marex> geertu: the bus runs at 200 MHz in both cases
09:58 < geertu> Marex: I mean the SDn and SDnH clock rates
09:59 < neg> for backward compability as SDnH is the parent of SDn can't we leave DT as is and have the driver get the parent of SDn (which it have access to today) and than control it's rate?
09:59 < Marex> geertu: they do differ, depends on SoC and revision, which is documented in the SDHI addendum
09:59 < geertu> shimoda: ehci/ohci DT bindings are very vague about clocks. I think adding an R-Car section may help.
09:59 < Marex> geertu: it's almost at the end of that document
10:00 < wsa_> neg: that might work. leaving dt as is would be much preferred
10:01 < geertu> Marex: Thx. So SDn=200 MHz, while SDnH=400 or 800 MHz
10:01 < wsa_> yup
10:02 < geertu> And the SD-IF module clock is based on SDn, while we could change that in the kernel to SDnH.
10:02 < shimoda> geertu: "adding an R-Car section" means into usb-ehci.txt? Or, as a new file?
10:02 < geertu> shimoda: Documentation/devicetree/bindings/usb/usb-ohci.txt and Documentation/devicetree/bindings/usb/usb-ehci.txt
10:03 < shimoda> geertu: Thanks! I'll add it.
10:04 < geertu> neg: You still need some heuristic to know if the Sdn divider is /2 or /4, right?
10:05 < neg> geertu: not following you
10:05 < geertu> Is there some table available listening all modes and according clocks rates?
10:06 < geertu> neg: If the driver request SDnH = 800 Mhz, it should program SDn to SDnH / 4
10:06 < geertu> neg: If the driver request SDnH = 400 Mhz, it should program SDn to SDnH / 2
10:07 < neg> geertu: yes, but if we expose SDnH as the parent clock of SDn the driver can control them both "independently" right?
10:07 < geertu> driver = clock driver or sdhi driver?
10:07 < neg> driver = sdhi
10:08 < neg> geertu: so first setting SDnH=800Mhz or 400Mhz and then SDn = 200Mhz would do the "right" thing?
10:08 < geertu> If the sdhi driver needs to see both, you have to update DT
10:08 < geertu> which may not be that unlogical ;-)
10:08 < neg> geertu: why can't I in the sdhi driver get the parent clock of SDn which is described in DT today?
10:10 < geertu> neg: DT describes SD-IFn, it's parent is SDn
10:11 < neg> geertu: ahh
10:11 < geertu> SDn's parent is SDSRC 9currently).
10:11 < geertu> You want to change that to SDSRC -> SDnH -> SDn -> SD-IFn.
10:12 < geertu> So the sdhi driver would get the parent of the parent of its clock, and modify that?
10:13 < neg> it would work but don't feel right :-)
10:13 < geertu> That's doable (clk_get_parent), but we need to modify all clock drivers at once.
10:13 < geertu> Exactly.
10:13 < wsa_> isn't SDnH derived from SDSRC as well? (don't have a datasheet handy at the moment)
10:13 < geertu> What about adding the SDnH clock to the clocks property of the SDHI nodes?
10:14 < wsa_> we could make HS400 dependent on the availability of this second clock
10:14 < wsa_> we haven't enabled it yet, so no regressions
10:14 < geertu> Yes, both are derived from SDSRC
10:14 < geertu> Exactly my thought.
10:15 < geertu> SDSRC -> 1/{1,2,4,8,16} -> SDnH -> 1/{2,4} -> SDn
10:15 < geertu> And we model (in the clock driver) SDn -> SD-IF
10:16 < geertu> Alternatively, we can model (in the clock driver) SDnH -> SD-IF, and use a heuristic (in the clock driver) to set the rate of SDn based on SDnH
10:16 < geertu> But before we do that, I'd like to see the full table of all modes and clock rates.
10:17 < geertu> What about impact on Gen2?
10:18  * geertu realizes we're running into the MM meeting time (and pinchartl is trembling)
10:18 < wsa_> Gen2 has no HS400
10:18 < wsa_> it has SDR104, though
10:18 < geertu> But it does have SDnH, which we don't model.
10:19 < pinchartl> geertu: if we want to discuss periject, that's core time ;-)
10:19 < pinchartl> (I'm not requesting that topic to be discussed, I was just enquiring)
10:19 < neg> seems like SDH and SDn have fixed freq on Gen2, but I just looked at the blockdiagram
10:21 < neg> To not spend anymore time on this topic it seems we have concensus that SDnH should be exposed on Gen3? So that will be the first step and I'm happy to have a direction for now :-)
10:22 < geertu> neg: Not according to SDCKCR, which controls SDH, SD0, and SD1
10:22 < geertu> Ugh, they share SDH for SD0 and SD1 on H2
10:22 < geertu> Let's move on to
10:23 < geertu> B) Periject
10:23 < wsa_> neg: yes, i think that direction looks worthwhile
10:25 < geertu> Do we have (silent) Magnus in the house?
10:25 < damm> yep
10:26 < pinchartl> mostly silent Laurent is here too
10:26 < pinchartl> damm: have you had a chance to discuss the process internally with Renesas ?
10:26 < geertu> Let's start speaking up ;-)
10:26 < damm> nope, i thought you wanted to finalize stuff internally first =)
10:27 < damm> in general i like your approach last meeting, but there were some loose ends i think
10:27 < damm> jacopo had some ideas
10:28 < pinchartl> damm:
10:28 < pinchartl> 11:05 < pinchartl> depending on the result of the internal discussions, I'll try to propose a format
10:28 < pinchartl> 11:06 < pinchartl> can that be our conclusion for today ?
10:28 < pinchartl> (from last meeting)
10:28 < pinchartl> 11:07 < damm> seems all good to me at least
10:28 < pinchartl> 11:01 < pinchartl> damm: would you like to take this internally and report the result of the discussions in the next meeting ? (or possibly before)
10:28 < pinchartl> (out of order, sorry)
10:28 < pinchartl> I thought internally meant inside Renesas
10:28 < damm> then we have a misunderstanding =)
10:28 < damm> i thought you were going to go over it once internally in our group =)
10:29 < pinchartl> 10:48 < damm> i think i should have a q&a with the renesas folks using the chat log until next time if someone could include the chat log in the report
10:29 < pinchartl> that's what I meant by internally -_-'
10:29 < damm> ok sorry, i have not done that
10:29 < damm> gotcha
10:29 < pinchartl> if we both wait for each other, lack of progress isn't surprising :-)
10:29 < damm> so no update from me, but i'll add it to my calendar
10:29 < damm> what's the plan with the opinion from jacopo?
10:29 < pinchartl> thanks
10:30 < pinchartl> which opinion ?
10:31 < damm> i recall he voiced his opinion (some ideas about the process) but we ran out of time
10:31 < damm> did you hear anything from him?
10:32 < damm> i did not. if neither one of us heard anything more then lets igore it to keep things simple
10:32 < pinchartl> I haven't
10:32 < pinchartl> jmondi: do you remember what your opinion was ? :-)
10:32 < jmondi> pinchartl: sort of :)
10:33 < jmondi> I basically asked for BSP to use $TOOL to clearly describe issues/features they try to solve, and then consider the patch series
10:33 < jmondi> not the other way around...
10:34 < jmondi> but there was quite a bit of push back, because BSP team do not want this burden, because, well, they do not care much about upstreaming
10:34 < jmondi> that's it
10:36 < pinchartl> I do agree that we need more information from the BSP team in many cases as commit messages are very terse
10:39 < pinchartl> that seems to be it for today ?
10:39 < damm> ok, so can we proceed with the process as-is as described by laurent?
10:39 < pinchartl> no issue on my side
10:39 < damm> i will check with renesas side and get back to you next meeting
10:39 < pinchartl> (I fortunately agree with my own proposal :-))
10:40 < damm> hehe
10:40 < pinchartl> damm: would you have time for a quick HO discussion after this meeting ?
10:40 < jmondi> damm: me too
10:40 < jmondi> :)
10:41 < wsa_> HO?
10:41 < damm> sure, just connect to me
10:41 < pinchartl> HO=hangout
10:42 < geertu> wsa_: https://www.urbandictionary.com/tags.php?tag=ho
10:42 < pinchartl> geertu: the mic is now yours to finish the core meeting
10:43 < geertu> Thanks ;-)
10:43 < geertu> Next meeting date? Will there be new contracts?
10:43 < ldts> Marex: https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/porting-guide.rst#extternal-abort-handling-and-ras-support
10:44 < geertu> I propose September 20th
10:44 < pinchartl> sounds good to m
10:44 < pinchartl> e
10:44 < wsa_> ack
10:45 < horms> Likewise
10:46 < neg> I also think new contracts sounds good :-)
10:47 < damm> fine here too of course
10:48 < geertu> Thanks for joining, and have a nice continued day!