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!