diff options
Diffstat (limited to 'wiki')
| -rw-r--r-- | wiki/Chat_log/20200903-core-chatlog | 137 |
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! |