Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 214 insertions, 0 deletions

diff --git a/wiki/Chat_log/20180906-core-chatlog b/wiki/Chat_log/20180906-core-chatlog
new file mode 100644
index 0000000..3b7adc7
--- /dev/null
+++ b/wiki/Chat_log/20180906-core-chatlog
@@ -0,0 +1,214 @@
+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!