wiki: Porting wiki: Porting Chat Log

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

1 files changed, 219 insertions, 0 deletions

diff --git a/wiki/Chat_log/20171005-core-chatlog b/wiki/Chat_log/20171005-core-chatlog
new file mode 100644
index 0000000..1c43b17
--- /dev/null
+++ b/wiki/Chat_log/20171005-core-chatlog
@@ -0,0 +1,219 @@
+Core-chat-meeting-2017-10-05
+
+09:48 < geertu> Welcome to today's core group meeting.
+09:48 < kbingham> and various people leave the room :D
+09:48  * pinchartl has to go for one hour
+09:48  * kbingham hides
+09:48 < geertu> Given the small amount of time left, OK if I just summarize the copy-and-paste received status reports?
+09:49 < geertu> A) What have I done since last time:
+09:49 < geertu>     
+09:49 < geertu>   Geert:
+09:49 < geertu>     - Sent patch to fix new unwind warnings with CONFIG_DEBUG_LOCK_ALLOC=y,
+09:49 < geertu>     - Sent v1 of sh-pfc suspend/resume,
+09:49 < geertu>     - Sent first pull requests for clk and pfc for v4.15,
+09:49 < geertu>   Jacopo: 
+09:49 < geertu>     - Some small patches for Gr-Peach
+09:49 < geertu>   Marek (U-Boot):
+09:49 < geertu>     - Got more patches applied to u-boot-sh/rmobile, PR pending
+09:49 < geertu>       http://git.denx.de/?p=u-boot/u-boot-sh.git;a=shortlog;h=refs/heads/rmobile
+09:49 < geertu>     - Worked on the SDIF SDR104/HS200 support based on out-of-tree
+09:49 < geertu>       patchset (for now):
+09:49 < geertu>         - added support for the SDR104/HS200 calibration to the uniphier-sd
+09:49 < geertu>           driver 
+09:49 < geertu>         - added support for pin voltage switching to PFC driver (POCCTRL)
+09:49 < geertu>         - added proper regulator handling to uniphier-sd
+09:49 < geertu>     - Worked on HS400, but that's still not ready
+09:49 < geertu>   Morimoto:
+09:49 < geertu>     - V3M/D3 shipping paper work
+09:49 < geertu>   Shimoda:
+09:49 < geertu>     - Submitted the following patches:
+09:49 < geertu>         * Add PWM entries of PFC for r8a77995.
+09:49 < geertu>         * Add USB3.0 entries of PFC for r8a7795{-es1} and merged.
+09:49 < geertu>         * Fix avb_pins for salvator-common, ulcb and draak.
+09:49 < geertu>       Remarks: "*" means merged into the subsystem repo.
+09:49 < geertu>     - I obtained a R-Car M3-N SiP, but I don't got bootloader yet.
+09:49 < geertu>   Simon:
+09:49 < geertu>     - Continued addressing review of CPUFreq patches 
+09:50 < geertu> B) What I plan to do till next time
+09:50 < geertu>   Geert:
+09:50 < geertu>     - v3 of cpg-mssr suspend/resume,
+09:50 < geertu>     - Fix genpd for wake-up devices.
+09:50 < geertu>   Marek (U-Boot):
+09:50 < geertu>     - Finish HS400 support
+09:50 < geertu>     - Finish sorting up remaining PCIe patches from the BSP (mostly
+09:50 < geertu>       suspend/resume support)
+09:50 < geertu>   Morimoto:
+09:50 < geertu>     - continue V3M/D3 paper work
+09:50 < geertu>   Niklas:
+09:50 < geertu>     - Send v2 of 'rcar_gen3_thermal: fix initialization sequence for H3 ES2.0'
+09:50 < geertu>   Shimoda:
+09:50 < geertu>     - Add usb3.0 phy device node for r8a779[56].dtsi after the usb3 peri
+09:50 < geertu>       supported a generic phy.
+09:50 < geertu>     - Prepare M3-N Salvator-X board for remote access if I obtain the
+09:50 < geertu>       bootloader.
+09:50 < geertu>   Simon:
+09:50 < geertu>     - Finalise addressing review of CPUFreq patches and repost
+09:50 < geertu> C) Problems I have currently
+09:50 < geertu> [Here I'll add breaks, in case people want to discuss]
+09:51 < geertu>   Jacopo:
+09:51 < geertu>     - Not really an issue to discuss with the whole group, but I keep seeing
+09:51 < geertu>       the GR-Peach hanging on sleeps longer than 1ms. I suspect this is also
+09:51 < geertu>       why ETHER is not working, and I had to substitute all sleep functions in
+09:51 < geertu>       the image sensor driver I am currently using to develop CEU with for
+09:51 < geertu>       loops of udelay(10). I blame XIP for this, but I'm currently not sure.
+09:51 < geertu>       Suggestions on how to debug and prove this are welcome :)
+09:51 < geertu> jacopo: ?
+09:51 < dammsan> use migo-r =)
+09:51 < geertu> Does it work on Genmai?
+09:51 < dammsan> (i don't dislike gr-peach support though)
+09:52 < jmondi> geertu: here I am
+09:52 < jmondi> never seen anything like this on genmai
+09:52 < jmondi> but seems like sleeps longer than 1ms hang the board
+09:53 < dammsan> which timer do you use?
+09:53 < geertu> Peach doesn't have rtc_x1_clk in the DTS?
+09:53 < jmondi> dammsan: as system clock?
+09:53 < jmondi> geertu: no, no RTC
+09:54 < geertu> The dmesg should tell you (compare genmai and peach)
+09:54 < jmondi> not just in dts, not RTC at all on the board
+09:54 < dammsan> rtc != clockevent != clocksource
+09:55 < wsa_> marex-cloud: the PCIE patches you mentioned, are these for U-Boot or Linux?
+09:55 < jmondi> let me look through dmesg
+09:55 < dammsan> a single clockevent used to be enough to run the kernel
+09:55 < Marex> wsa_: Linux, mostly suspend support
+09:55 < dammsan> but the twd on CA9 used to exist only in case of multi-core
+09:55 < dammsan> so instead of local timer i'm not sure what is used
+09:56 < geertu> rskrza1 and genmai enable mtu2, peach doesn't
+09:56 < dammsan> there you go
+09:56 < wsa_> Marex: nice! did you send out patches already? I don't see any on the renesas-soc list.
+09:56 < Marex> wsa_: I have them rebased to -next since a few days ago, I need to understand what some of them are doing
+09:56 < geertu> rskrza1 enables ostm[01], peach and genmai don't
+09:56 < wsa_> Marex: I can imagine :)
+09:57 < geertu> Ok, issue assumed fixed until proven otherwise soon :-)
+09:57 < Marex> wsa_: there's one which digs in the PCIe core , but not much details in the commit message
+09:57 < geertu>   Marek:
+09:57 < geertu>     - HS400 calibration doesn't pass on Salvator-XS for me in U-Boot,
+09:57 < geertu>       but that's because I'm doing something wrong, it works in Linux
+09:57 < jmondi> geertu: dammsan: I lost you two
+09:57 < jmondi> I'm so ignorant on this
+09:57 < geertu> Marex: if you want to discuss this, I think I/O is more appropriate
+09:58 < dammsan> jmondi: your timer configuration on gr-peach is incomplete
+09:58 < geertu> jmondi: seacrh for mtu and ostm in the varipus r7s72100 DTS
+09:58 < Marex> geertu: ACK, I have feedback from wsa_ , need to check it on real board
+09:58 < geertu> Marex: OK
+09:58 < geertu>   Shimoda:
+09:58 < geertu>     - I got a request from BSP team about upstreaming of MFIS hwspinlock
+09:58 < geertu>       feature.
+09:58 < geertu>         - But, the current implementation is not good for upstreaming, I think.
+09:58 < geertu>           I have 3 concerns:
+09:58 < geertu>              1) The device nodes ("mfis" and "mfis-lock") are duplicated like
+09:58 < geertu>                 below...
+09:58 < geertu>                 https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795.dtsi?h=v4.9/rcar-3.5.8#n875
+09:58 < geertu>              2) The BSP team would like to support "MFIS lock register 8" in
+09:58 < geertu>                 the future, but the register area is separated from "MFIS lock
+09:58 < geertu>                 register [0-7]".
+09:58 < geertu>              3) The "mfis" driver for rpmsg (Remote Processor Messaging) will
+09:58 < geertu>                 be not upstreaming for now.
+09:58 < geertu>         - This module has two (or more) features and BSP supports the following
+09:58 < geertu>           features:
+09:58 < geertu>             1) hwspinlock
+09:58 < geertu>             2) rpmsg (Remote Processor Messaging)
+09:58 < geertu>         - My concern point is how to make the device node for it.
+09:58 < geertu>             - In my opinion, it should be a mfd driver like below:
+09:58 < geertu>                  mfis {
+09:58 < geertu>                          reg = <0 0xe6260000 0 0x1000>;
+09:58 < geertu>                          hwspinlock {
+09:58 < geertu>                                  ...
+09:58 < geertu>                          };
+09:58 < geertu>                          rpmsg {
+09:58 < geertu>                                  ...
+09:58 < geertu>                          };
+09:58 < geertu>                  };
+09:58 < geertu>             - But, what do you think?
+09:58 < geertu> shimoda: I had a quick look at the DTS patch
+09:59 < geertu> mfis-lock covers lock registers 0-7
+09:59 < geertu> The mfis node covers all registers in the first 0x200 byts, but the only registers there are the same lock registers?
+09:59 < jmondi> dammsan: geert: will do.. in the meantime fyi: https://paste.debian.net/989118/
+10:00 < wsa_> Marex: and don't hesitate to forward questions to the BSP team via Shimoda-san or Morimoto-san
+10:00 < shimoda> geertu: the mfis node is for rpmsg
+10:00 < geertu> shimoda: Using the same lock registers? Or are there undocumented registers in that block?
+10:01 < geertu> You can have multiple register blocks in a single reg property, cfr. the gic nodes
+10:01 < Marex> wsa_: will do if anything pops up
+10:01 < shimoda> the out of tree driver of mfis driver for rpmsg will not use the same lock registers. Yes, there is undocumented registers for now
+10:01 < geertu> You can just have a single one, too (cfr. your "reg = <0 0xe6260000 0 0x1000>")
+10:02 < Marex> wsa_: the HS400 was just a quick test bolted on top of HS200
+10:02 < geertu> A single driver can be both a hwspinlock and and rpcmsg provider, without using MFD, I think.
+10:03 < geertu> Cfr. the CPG/MSSR driver, which is clk provider (for the clocks), genpd provider (for the clock domain), and reset controller (for module resets)
+10:05 < shimoda> geertu: but, they make two drivers (hwspinlock and rpmsg) and two device nodes now
+10:05 < geertu> shimoda: Two overlapping device nodes is a definite no-go
+10:06 < shimoda> geertu: yes, I know. but bsp team doesn't know...
+10:06 < geertu> shimoda: So you should tell them, so they know ;-)
+10:07 < shimoda> geertu: yes, I should do so :)
+10:07 < geertu> jmondi: timer_probe: no matching timers found
+10:07 < geertu> jmondi: while my last boot on genmai of v4.9 said:
+10:07 < geertu> sh_mtu2 fcff0000.timer: ch0: used for clock events
+10:07 < geertu> sh_mtu2 fcff0000.timer: ch0: used for periodic clock events
+10:08 < jmondi> geertu: yes... If I got this right, without MTU2 all clock events used for wake ups are not generated
+10:08 < jmondi> so the only working methof for sleeping is busy waiting, as udelay does
+10:09 < shimoda> about this mfis topic, bsp team don't want to make a single driver to support a hwspinlock and rpmsg, especially rpmsg. But, I'll forward this infor and discuss how do we do. Thanks!
+10:09 < geertu> shimoda: Do you need any special properties in the hwspinlock and rpmsg nodes from your proposal?
+10:09 < jmondi> I'm now testing it, just need to remove my workarounds in sensor driver code
+10:10 < dammsan> shimoda: isn't hwspinlock vs rpmsg assignment software policy?
+10:11 < shimoda> geertu: I don't need any special properties, I think. But, BSP team concern, M3-W and H3 ES1.x has only 8 locks, but other SoCs has 64 locks
+10:11 < shimoda> s/BSP team concern/BSP team has concern/
+10:11 < geertu> That can be handled by the driver based on the renesas,mfis-<soctype> compatible value, right?
+10:12 < geertu> (no, "renesas,<soctype>-mfis")
+10:12 < shimoda> dammsan: I think so, BSP team wants hwspinlock to go to upstream, but rpmsg is no-go because this is related to undocumented
+10:13 < jmondi> geertu: damsan: no more hangs... trying yout ETHER now... thank you both so far :)
+10:13 < dammsan> i see. i think mfis has existed even on mobile platforms
+10:13 < geertu> dammsan: Indeed, on all SoCs we still support, I think.
+10:13 < dammsan> register layout in such case seemed similar to msiof but it was used for mailbox communication between cou coes
+10:14 < dammsan> i mean cpu cores
+10:14 < shimoda> geertu: i think so. but also need soc_device_match for H3 ES2.0
+10:14 < dammsan> but anyway, good with hwspinlock
+10:14 < geertu> We're running out of time. Anything else related to this topic?
+10:14 < geertu>   Simon:
+10:14 < geertu>     - Correct handling of PLL dividor for CPUFreq
+10:15 < geertu> horms: Do you want to discuss this here?
+10:15 < horms> I think I should do some more investigation. Perhaps we can chat about it on this channel some time?
+10:16 < geertu> OK.
+10:16 < dammsan> FYI, i'm adding a silk board for remote access now
+10:16 < geertu> Anything I missed in the status reports?
+10:16  * Marex steals a bit of time, OK?
+10:17 < horms> dammsan: great, can you give me access if its not already oversubscribed?
+10:17 < dammsan> sure
+10:17 < dammsan> i'll announce the reshuffled boards via email, lets take it from there
+10:17 < geertu> Marex: Core related? I should hand over the mic to Wolfram...
+10:17 < Marex> shimoda: I sent out the xhci patch I plan to submit to the U-Boot list to the periperi list first, the license grant should be OK, can you double-check please ?
+10:18 < Marex> geertu: well it's inbetween, U-Boot is core and xhci is IO
+10:18 < shimoda> Marex: sure, I will check it
+10:18 < Marex> shimoda: thank you !
+10:18 < Marex> shimoda: it'd be convenient if this worked out, since now I can just type "usb reset" and it works :)
+10:19 < Marex> shimoda: it's hassle-free
+10:19 < shimoda> Marex: nice! :)
+10:20 < wsa_> geertu: don't worry, I am fine
+10:20 < Marex> shimoda: btw re HS200/400 and SDR104, I am a bit blocked by the SD/MMC maintainer in U-Boot, sorry about that
+10:20 < Marex> shimoda: he's not picking patches as fast as I'd like him to
+10:20 < Marex> shimoda: I'm looking for ways to ... uh ... expedite that process
+10:21 < shimoda> Marex: i got it. thanks!
+10:21 < Marex> shimoda: you're welcome, I'll keep you updated
+10:22 < wsa_> Marex: is yamada-san working on this, too?
+10:22 < Marex> wsa_: Masahiro Yamada-san ?
+10:22 < wsa_> hai
+10:22 < Marex> wsa_: he works for socionext, although he did implement the uniphier-sd which I now use on RCar Gen3
+10:22  * neg brb 2 min
+10:22 < Marex> wsa_: their block doesn't support the HS200/400/SDR104 modes though, that's renesas specific
+10:23 < Marex> wsa_: so he just reviews my uniphier-sd patches (which is nice) and makes sure they work on both
+10:23 < wsa_> I see
+10:24 < Marex> wsa_: the blocker really is the SD/MMC subsystem maintainer, he just doesn't respond much
+10:24 < Marex> wsa_: some not long time ago I was really tempted to just replace him and start handling the SDMMC stuff myself
+10:25 < Marex> wsa_: but then he came back, at like 5 mins to 12 and rolled out a PR ...
+10:25 < wsa_> how about co-maintaining?
+10:25 < Marex> wsa_: I feel like I'm hoarding functions ;-)
+10:26 < wsa_> I see
+10:26 < wsa_> that happens easily, yes
+10:26 < Marex> wsa_: right
+10:26  * neg back
+10:26 < Marex> wsa_: and since U-Boot isn't as prestigeous as linux, maintainers don't really queue up to do it
+10:27 < wsa_> okay
+10:27 < Marex> wsa_: anyway ... maybe we should continue rather than complain about lack of manpower all over the place ? :)
+10:27 < wsa_> ack