Core-chat-meeting-2017-09-21

09:02 < geertu> Welcome to today's Core Group Meeting
09:02 < geertu> Agenda
09:02 < geertu> 1. Status updates
09:03 < geertu> 2. Discussion Topics
09:03 < geertu> Topic 1. Status updates
09:03 < morimoto> hi
09:03 < geertu> Morimoto-san is first
09:03 < morimoto> OK
09:03 < morimoto> But I have no Core task
09:03 < morimoto> --EOF--
09:04 < geertu> Great!
09:04 < morimoto> Ahh,
09:04 < geertu> Laurent is next
09:04 < morimoto> but I found kernel WARNING issue
09:04 < morimoto> I reported it on ML
09:04 < morimoto> ML => PeriPeri ML
09:04 < morimoto> --EOF--
09:05 < pinchartl> geertu: same
09:05 < geertu> OK
09:05 < geertu> morimoto-san: https://www.spinics.net/lists/arm-kernel/msg603844.html
09:05 < geertu> Known issue, people are working on a fix
09:05 < geertu> "[PATCH 0/4] Fix check address limit on user-mode" might be the fix, haven't tried it ey
09:06 < morimoto> geertu: oh thanks
09:06 < geertu> Next is Geert
09:06 < geertu> A) What have I done since last time (last status updates):
09:06 < geertu>   - Sent pull requests for clk and pinctrl for v4.14,
09:06 < geertu>   - Published v2 of CPG/MSSR DT for R-Car Gen2, incl. resets,
09:06 < geertu>   - Brought up V3M/Eagle, using Sergei's clock patch,
09:06 < geertu>   - CNTVOFF initialization for R-Car E2 (and RZ/G1E) SMP,
09:06 < geertu>   - Took over CMT DT binding rework from Magnus, published update,
09:06 < geertu>   - Lots of reviews (RZ/G1, V3M, Kingfisher, ...),
09:06 < geertu>   - Core Additional Tasks for Q4.
09:06 < geertu> B) What I plan to do till next time:
09:06 < geertu>   - Suspend/resume for PFC,
09:06 < geertu>   - Mark periupport priority < H commits that are in linux-next,
09:06 < geertu> C) Problems I have currently:
09:06 < geertu>   - None.
09:06 < geertu>  --EOF--
09:06 < geertu> Next is Simon
09:06 < morimoto> geertu: do you know how to indicate it on renesas_defconfig ?
09:07 < morimoto> normal renesas_defconfig didn't indicate
09:07 < horms> * Core
09:07 < horms> A)
09:07 < horms>     - Began addressing review of CPUFreq patches
09:07 < horms> B)
09:07 < horms>     - Finalise above and repost
09:07 < horms> C, D)
09:07 < horms>     - None
09:08 < geertu> CONFIG_DEBUG_SPINLOCK=y?
09:09 < morimoto> geertu: it seems this URL and my issue is not same
09:10 < geertu> morimoto: Really? Both are about xprtiod vs. tk_work
09:10 < geertu> Thank you, Simon
09:10 < morimoto> Yeah, but my issue seems happen from
09:10 < geertu> Next is Jacopo
09:10 < morimoto> a1d14934ea4b9db816a8dbfeab1c3e7204a0d871
09:10 < morimoto> (workqueue/lockdep: 'Fix' flush_work() annotation)
09:10 < morimoto> But This URL indicate it was
09:11 < morimoto> 73ac5d6a
09:11 < jmondi> Not much from me
09:11 < geertu> 73ac5d6a = arm32 only
09:11 < geertu> a1d14934ea4b9db816a8dbfeab1c3e7204a0d871 = generic
09:11 -!- horms_ [~horms@217.111.208.18] has joined #periperi
09:11 < geertu> I guess on arm64 it bisects to the latter
09:11 < morimoto> Ahh, ok, I see
09:12 < jmondi> I just tried to have gr-peach working as background task, with no luck so far
09:12 < jmondi> ^ gr-peach ethernet
09:12 < jmondi> and no core tasks scheduled
09:12 < jmondi> --eot
09:12 < geertu> Thank you, Jacopo
09:13 < geertu> Next is Shimoda-san
09:14 < shimoda> < Core >
09:14 < shimoda> A)
09:14 < shimoda>  - Add usb device nodes for r8a7796.
09:14 < shimoda>  - My concern about u-boot/dts memory nodes was resolved by Marek-san (Thanks!).
09:14 < shimoda> B)
09:14 < shimoda>  - Add usb3.0 peripheral and usb3.0 phy device node for r8a779[56].dtsi.
09:14 < shimoda>  - Prepare M3-N Salvator-X board for remote access if I obtain the SiP.
09:14 < shimoda> C)
09:14 < shimoda>  - Nothing.
09:14 < shimoda> -- eot --
09:15 < geertu> Thank you, Shimoda-san!
09:15 < geertu> Next is Niklas
09:15 [Users #periperi]
09:15 [ geertu] [ jmondi     ] [ Marex      ] [ mturquette] [ shimoda] 
09:15 [ horms ] [ kbingham   ] [ marex-cloud] [ neg       ] [ wsa_   ] 
09:15 [ horms_] [ kbingham[m]] [ morimoto   ] [ pinchartl ] 
09:15 -!- Irssi: #periperi: Total of 14 nicks [0 ops, 0 halfops, 0 voices, 14 normal]
09:15 < neg> A)
09:15 < neg>     - [PATCH] thermal: rcar_gen3_thermal: fix initialization sequence for H3 ES2.0
09:15 < neg>     - [PATCH 0/2] arm64: dts: r8a7795: r8a7796: add thermal cooling management
09:15 < neg>     - [RFC 0/3] thermal: rcar_gen3_thermal: read calibration from hardware
09:15 < neg> B)
09:15 < neg>     - Send v2 of 'rcar_gen3_thermal: fix initialization sequence for H3 ES2.0'
09:15 < neg> C)
09:16 < neg>     - Not sure if I should go ahead with '[RFC 0/3] thermal: rcar_gen3_thermal:
09:16 < neg>       read calibration from hardware'. Before all registers are documented in
09:16 < neg> EOT
09:16 < neg>       datasheet or I can find hardware with fused calibration registers.
09:16 < neg>       What do core leader and Renesas think?
09:17 < geertu> I think it would be good to be able to test the fused calibration
09:17 < geertu> Is there any board that has it? If it could be put in Magnus' farm, it can be tested
09:18 < neg> I agree so then I will hold off on that patch as RFC untill I can find a board with have the calibration fused to test on
09:18 < neg> And yes if there is such a board today, testing it remote is fine :-)
09:18 < geertu> {morimoto,shimoda}-san?
09:19 < geertu> neg: Have you checked all Gen3 boards in Magnus' farm? (e.g. by a quick read of the fuse register from U-Boot)?
09:19 < geertu> Or are even all the ULCBs "hand prodcution" hardware?
09:20 < neg> geertu: I only have access to one board in Magnus farm (H3) and it did not have the values fused
09:20 < wsa_> Don't we have any information from HW team about that?
09:21 < wsa_> When/what is fused?
09:21 < neg> Yes ULCBs is a good idea I had not tought about that, I will ping magnus about access for that
09:21 < geertu> neg: If you tell me which register to check, I can check all boards I have access to
09:21 < neg> wsa_: All I know is derived from the dataheet which according to Morimot-san needs an update for the missing register and BSP code
09:22 < wsa_> Even if we find a board where the registers have some values, how can we know if we can trust them otherwise?
09:22 < geertu> wsa_: That's the second step ;-)
09:23 < wsa_> It would save some work if it was the first step :D
09:23 < wsa_> But you are free to choose, of course
09:23 < neg> geertu: thanks! I think the fastes check is just to boot with '[RFC 0/3] thermal: rcar_gen3_thermal: read calibration from hardware' applied and if it is booted on a board which have the registered fused it should print dev_info(dev, "Using fused calibration values\n");
09:24 < neg> wsa_: acording to the BSP code there is a flag in the undocumented register which signals if the fused values ar OK or not
09:25 < morimoto> neg: I think you are talking about the register which you asked me few weeks ago ?
09:25 < neg> morimoto: yes
09:25 < morimoto> And you want to modify it ?
09:26 < neg> No I want a datasheet update where it is documented :-)
09:26 < wsa_> neg: ok, nice
09:26 < morimoto> Ahh, OK. datasheet said that it will be updated in next (?) version
09:26 < morimoto> let me check latest info
09:27 < geertu> neg: I can no longer boot Linux on the ULCBs, only U-Boot
09:27 < geertu> Thanks Niklas
09:27 < neg> geertu: ohh, I will send you an email with the register info, thanks for checking
09:28 < geertu> Next is Ulrich, who is excused, and has nothing to report for core
09:28 < geertu> Marek is also excused, and provided this for U-Boot:
09:28 < geertu> A) What have I done since last time (U-Boot)
09:28 < geertu>    - Submitted:
09:28 < geertu>      - Improved the Gen3 clock driver (SDxCKCR config, RPC clock)
09:28 < geertu>      - RCar Gen3 R8A779{5,6} PFC pinmux driver
09:28 < geertu>      - RCar Gen3 GPIO driver
09:28 < geertu>      - Board cleanup (remove ad-hoc pinmux and gpio setup)
09:28 < geertu>      - Fix xHCI stack in U-Boot to work with renesas xhci controller
09:28 < geertu>    - Pending
09:28 < geertu>      - xHCI driver (firmware licensing discussion, see B) )
09:28 < geertu> B) What problems I have (U-Boot)
09:28 < geertu>    - SD/MMC maintainer is not responding for over a month, my switch
09:28 < geertu>      from sh-sdhi (horrible driver) to uniphier-sd (nice driver) is
09:28 < geertu>      blocked
09:28 < geertu>    - xHCI firmware discussion -- me, Geert and Tom Rini (u-boot head
09:28 < geertu>      maintainer) think it is OK to bundle the firmware with U-Boot as
09:28 < geertu>      the license permits it apparently.
09:28 < geertu> C) What will I do till next time (U-Boot)
09:28 < geertu>    - Pester SD/MMC maintainer more, escalate further
09:28 < geertu>    - Revisit SD/MMC HS200/H400/SDR104 patchset
09:28 < geertu>    - D3 support
09:28 < geertu>    - Post xHCI driver once the firmware discussion concludes
09:28 < geertu> ANy news from Magnus? On a plane to JP?
09:29 < geertu> Topic 2. Discussion Topics
09:29 < geertu> Anything to discuss during the last minute?
09:29 < morimoto> neg: can you show me its register name please ?
09:29 < shimoda> THSCP
09:29 < neg> morimoto: in BSP it is called THSCP
09:29 < morimoto> thanks
09:30 < neg> shimoda: :-)
09:32 < shimoda> :)
09:32 < shimoda> i checked errata doc, but it doesn't have it, so morimoto-san or i should ask hw team about this
09:33 < neg> shimoda: OK thanks
09:33 < geertu> We're slowly moving into the I/O area.
09:33  * geertu passes the mic to wsa_