1 files changed, 137 insertions, 0 deletions
diff --git a/wiki/Chat_log/20200903-core-chatlog b/wiki/Chat_log/20200903-core-chatlog
new file mode 100644
index 0000000..cb355af
--- /dev/null
+++ b/wiki/Chat_log/20200903-core-chatlog
@@ -0,0 +1,137 @@
+09:31 < geertu> Welcome to today's Core Group Chat Meeting!
+09:31 < marex> wsa: nope
+09:31 < geertu> wsa: No (new) family duties for you?
+09:31 < wsa> (and I am not thinking of the sushi, honestly)
+09:31 < geertu> Agenda:
+09:31 < geertu> 1. Status Updates
+09:31 < geertu> 2. Discussion Topics
+09:31 < geertu> Topic 1. Status updates
+09:32 < wsa> geertu: sure, but I can still go away for 2 weeks once in a while
+09:32 < geertu> A) What have we done since last time:
+09:32 < geertu> Marek work on SH4 QEMU test hooks for U-Boot, multiple mem node parsing
+09:32 < geertu> for OpteeOS, and added basic R-Car Gen3 support to QEMU.
+09:32 < geertu> Morimoto-san posted menu Kconfig patches.
+09:32 < geertu> Shimoda-san started to develop initial support for R-Car V3U.
+09:32 < geertu> Geert attended LPC, converted pinctrl bindings to json-schema, worked on
+09:32 < geertu> head.S for RZ/A2, and kdump, and reviewed RZ/G patches.
+09:32 < geertu> B) What we plan to do till next time:
+09:32 < geertu> Marek plans to continue on QEMU.
+09:32 < geertu> Shimoda-san plans to continue initial support for R-Car V3U, convert the
+09:32 < geertu> usb2-clock doc to json-schema, and ping the hardware manual team about
+09:32 < geertu> sharing the R-Car V3U manual.
+09:32 < geertu> Geert plans to review more RZ/G patches, send pull request for v5.10,
+09:32 < geertu> rename drivers/pinctrl/sh-pfc/, and perhaps continue QEMU GPIO
+09:32 < geertu> virtualization.
+09:33 < geertu> C) Problems we have currently:
+09:33 < geertu> Geert suffers from failures in kernels booted through kexec.
+09:33 < geertu> --EOT--
+09:33 < geertu> Anything I missed?
+09:34 < marex> geertu: the gen3 qemu is still local and WIP
+09:34 < geertu> Initial R-Car V3U support can be in v5.10, if it is posted and reviewed in time (i.e, during the next 2 weeks)
+09:35 < wsa> no offence, but what do we need Gen3-QEMU for?
+09:35 < marex> wsa: same as sh4 qemu, CI
+09:35 < marex> wsa: and figuring out whether the bootrom can do switching between two copies of IPL somehow as a byproduct (for CI again)
+09:36 < marex> wsa: SH4 U-Boot is tested in QEMU on every push to the repository
+09:36 < geertu> Topic 2. Discussion Topics
+09:36 < wsa> so, it is basically on CPU core level? I mean, you won't recode all of the IPs present, or?
+09:37 < marex> wsa: I will model some subset of them
+09:37 < marex> wsa: well, there is another upside in that you can track IO accesses and possibly detect writes to bits which you shouldn't be writing, like in PFC/clock
+09:37 < wsa> yes, that's for sure
+09:38 < geertu> Especially writes done by the boot ROM...
+09:38 < marex> ... to registers which are undocumented ...
+09:38 < wsa> I just wondered becuase Gen3 is, you know, HUGE
+09:39 < marex> wsa: TFA/U-Boot doesn't use a large part of that, and Linux can also be reduced
+09:39 < wsa> but I see the values you pointed out
+09:39 < wsa> OK, I have a disucssion point
+09:39 < wsa> pinctrl switching to GPIO
+09:40 < wsa> major pain or small addition? :)
+09:40 < geertu> wsa: I think that'll be rather a major pain, as it involves pinctrl core.
+09:41 < geertu> Basically we need support for obtaining the GPIO corresponding to a function pin?
+09:41 < geertu> Shimoda-san had a try at that a while ago
+09:42 < wsa> Hmm, when I looked at other SoCs implementing bus recovery I had the impression they could do it using pinctrl. Am I wrong?
+09:43 < geertu> wsa: Do you have a pointer to an example?
+09:43 < marex> git grep pinctrl-1
+09:43 < damm> going back from pinctrl to GPIO?
+09:43 < damm> full circle if so
+09:44 < wsa> geertu: I am already checking
+09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts-                      i2c1: i2c@fc028000 {
+09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts-                              dmas = <0>, <0>;
+09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts-                              pinctrl-names = "default", "gpio";
+09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts-                              pinctrl-0 = <&pinctrl_i2c1_default>;
+09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts:                              pinctrl-1 = <&pinctrl_i2c1_gpio>;
+09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi-&i2c1 {
+09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi-  clock-frequency = <100000>;
+09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi-  pinctrl-names = "default", "gpio";
+09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi-  pinctrl-0 = <&pinctrl_i2c1>;
+09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi:  pinctrl-1 = <&pinctrl_i2c1_gpio>;
+09:45 < wsa> [PATCH 0/4] i2c: core: add generic GPIO bus recovery
+09:45 < damm> ah ok thanks for clarifying
+09:46 < marex> wsa: so yep, the solution should be to call pinctrl_set_state() or whatever that is called now , pick the pinctrl-1 , do recovery, then pick pinctrl-0
+09:46 < geertu> These allow to specify GPIO in a DT pinctrl node
+09:46 < geertu> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
+09:46 < geertu> pinmux = <PIN_PD21__TWD0> vs <PIN_PD21__GPIO>
+09:47 < geertu> Do we need support for function = "gpio" in sh-pfc?
+09:47 < wsa> marex: and this doesn't work for us
+09:47 < geertu> Or teach the pinctrl core to do function -> gpio setup?
+09:47 < marex> wsa: why ?
+09:47 < geertu> The core already knows how to do the reverse
+09:48 < wsa> marex: because we don't have 'function = "gpio"'
+09:48 < marex> ah
+09:49 < marex> wsa: shouldn't we ?
+09:49 < geertu> Having it in the core means that we don't have to describe a second pinctrl state in DT
+09:49 < geertu> The latter is basically superfluous, as the kernel already knows the mapping
+09:49 < wsa> marex: this is what we are discussing now :)
+09:50 < marex> wsa: it would make the behavior in-line with the other platforms at least
+09:50 < wsa> geertu: but not all pins can be switched to a GPIO, won't that make it more difficult?
+09:51 < wsa> Like IIC0 can't be switched to GPIO on Gen3
+09:51 < geertu> wsa: function would return -EINVAL?
+09:51 < damm> may i propose that in case a user tries to swith a non-valid function to GPIO then instead of returning error we can just return a random GPIO? =)
+09:52 < geertu> If the pin can't switch to GPIO, that can't be described in DT neither
+09:52 < marex> geertu: it can, you can write invalid DT, but then -EINVAL is the way to go
+09:53 < geertu> wsa: So all of that patch series has already been applied? Doh, just wanted to reply the kernel already knows the ampping...
+09:53 < wsa> geertu: so, what would you suggest? pinctrl_unset_stete() will bring back GPIO?
+09:53  * geertu kicks marex and damm
+09:54 < wsa> damm: it should return the CAN connection to your car
+09:54 < marex> wsa: well that sounds like a hack :)
+09:54 < marex> (unset_state -> gpio)
+09:55 < geertu> wsa: Hmm. The extra pinctrl state is superfluous, IMHO, but you still need to know which of the 2 GPIOs is SCL and which is SDA
+09:55 < marex> geertu: for that you have the {scl,sda}-gpios in the DT ?
+09:55 < geertu> For PWM it's simpler: just one pin ;-)
+09:56 < geertu> marex: yes
+09:56 < marex> but not for the pinmux if it's separate, hah
+09:56 < wsa> geertu: that binding is also still needed to stay generic. you could have two other gpios wired to the bus just for recovery
+09:56 < geertu> wsa: Good point.
+09:56 < geertu> So sh-pfc needs support for 'function = "gpio"' it is?
+09:57 < damm> this reminds me of uart flow control signals as gpio?
+09:57 < damm> and the software gpio cs for msiof
+09:57 < wsa> damm: and the zero-duty-cycle-GPIO for PWM
+09:57 < geertu> Now, how does rwquest_gpio() work if the pin is considered busy by pinctrl?
+09:58 < geertu> s/rwquest/requst/
+09:58 < wsa> -EBUSY
+09:58 < geertu> Indeed, so does it really work?
+09:59 < wsa> That's what I got when I tried the GPIO bus recovery with IIC on Lager
+09:59 < geertu> So you have to undo the pinctrl state manually, and request the GPIO afterwards? No pinctrl-1 needed?
+10:00 < wsa> that could work
+10:00 < geertu> Later, unrequest GPIO + pinctrl enable again?
+10:00 < wsa> this is what I meant above with "pinctrl_unset_state()"
+10:00 < geertu> How does it work for the other people? No -EBUSY?
+10:01 < wsa> they switch the state to GPIO
+10:02 < geertu> Yeah, but the pin is still busy, according to pinctrl? Or they don't track busy/idle state?
+10:03 < geertu> The pinctrl driver treats PIN_PD21__TWD0 vs PIN_PD21__GPIO the same, i.e. just as a value to write to a register
+10:03 < geertu> cfr. RZ/A1 and RZ/A2
+10:03 < geertu> wsa: Tried your genmai?
+10:04 < wsa> jmondi has the Genmai meanwhile
+10:04 < jmondi> wsa: do I ? :)
+10:04 < geertu> Or the peach ;)
+10:04 < jmondi> didn't I give it back to you ? I'll check
+10:04 < wsa> jmondi: I hope so! :D
+10:04 < geertu> Remote genmai @ Magnus?
+10:05 < jmondi> geertu: I use the peach for RZ/A1
+10:05 < jmondi> do you guys need any testing ?
+10:05 < damm> i can probably find such a board somewhere
+10:05 < geertu> Anyway, we're running late, violating MM space
+10:05 < geertu> Let's take it to the ML?
+10:05 < geertu> Anything else to discuss?
+10:05 < wsa> jmondi: did you? If not, it would be nice to get it back because it is interesting for i2c slave development
+10:06 < wsa> geertu: ack, let's take it to ML
+10:07 < geertu> Thanks for joining, and have a nice continued day!