1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
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!
|
