| Message ID | 20240130233700.2287442-1-andre.draszik@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | arm64: dts: exynos: gs101: add stable i2c aliases for gs101-oriole | expand |
On Tue, 30 Jan 2024 23:37:00 +0000, André Draszik wrote: > Now that we have more than i2c interface, add aliases to ensure > deterministic bus number assignment. > > So as to keep compatibility with existing Pixel userspace builds, use > the same bus numbers for hsi2c_8 and hsi2c_12 as the downstream > drivers with the intention to eventually add all the earlier busses as > well. > > [...] Applied, thanks! [1/1] arm64: dts: exynos: gs101: add stable i2c aliases for gs101-oriole https://git.kernel.org/krzk/linux/c/72ccd925dcbd2ad6935a4874679b6cf5b3de7156 Best regards,
Hi Krzysztof, On Thu, 2024-02-08 at 09:08 +0100, Krzysztof Kozlowski wrote: > > On Tue, 30 Jan 2024 23:37:00 +0000, André Draszik wrote: > > Now that we have more than i2c interface, add aliases to ensure > > deterministic bus number assignment. > > > > So as to keep compatibility with existing Pixel userspace builds, use > > the same bus numbers for hsi2c_8 and hsi2c_12 as the downstream > > drivers with the intention to eventually add all the earlier busses as > > well. > > > > [...] > > Applied, thanks! > > [1/1] arm64: dts: exynos: gs101: add stable i2c aliases for gs101-oriole > https://git.kernel.org/krzk/linux/c/72ccd925dcbd2ad6935a4874679b6cf5b3de7156 Is it too late to ask for this patch to be dropped please? It appears downstream has just changed all their aliases on Friday, whereas the point of this patch was to keep things aligned. I won't post anything similar until we start integrating with Android/AOSP at some point in the future. Thanks, Andre'
On 12/02/2024 11:17, André Draszik wrote: > Hi Krzysztof, > > On Thu, 2024-02-08 at 09:08 +0100, Krzysztof Kozlowski wrote: >> >> On Tue, 30 Jan 2024 23:37:00 +0000, André Draszik wrote: >>> Now that we have more than i2c interface, add aliases to ensure >>> deterministic bus number assignment. >>> >>> So as to keep compatibility with existing Pixel userspace builds, use >>> the same bus numbers for hsi2c_8 and hsi2c_12 as the downstream >>> drivers with the intention to eventually add all the earlier busses as >>> well. >>> >>> [...] >> >> Applied, thanks! >> >> [1/1] arm64: dts: exynos: gs101: add stable i2c aliases for gs101-oriole >> https://git.kernel.org/krzk/linux/c/72ccd925dcbd2ad6935a4874679b6cf5b3de7156 > > Is it too late to ask for this patch to be dropped please? It appears > downstream has just changed all their aliases on Friday, whereas the > point of this patch was to keep things aligned. > > I won't post anything similar until we start integrating with Android/AOSP > at some point in the future. I can drop it, but the actual problem is that what if downstream keeps changing aliases? They can do it... The aliases are not there to match with downstream, but to have stable interface matching SCHEMATICS. Best regards, Krzysztof
On Mon, 2024-02-12 at 12:18 +0100, Krzysztof Kozlowski wrote: > I can drop it, but the actual problem is that what if downstream keeps > changing aliases? They can do it... We won't care at that stage, downstream should have no reason to divert from upstream for numbering at some point in the future. > The aliases are not there to match > with downstream, but to have stable interface matching SCHEMATICS. Except the schematics don't refer to the i2c busses by number. Cheers, Andre'
On 12/02/2024 12:30, André Draszik wrote: > On Mon, 2024-02-12 at 12:18 +0100, Krzysztof Kozlowski wrote: >> I can drop it, but the actual problem is that what if downstream keeps >> changing aliases? They can do it... > > We won't care at that stage, downstream should have no reason to divert from > upstream for numbering at some point in the future. What do you mean by "no reason"? The reason is they can do whatever they want. Some project leader says: "I want this" and they will do it. They won't care about our upstream choice at all. And then what, you change it again? If downstream was caring, then they could pick as well aliases which we already committed. To remind: the downstream was released 3 years ago! So the downstream DTS is long past "beta" phase and should be considered stable. If they keep changing the aliases after three years, then they can keep doing it for next 20 years. Best regards, Krzysztof
On Mon, 2024-02-12 at 12:40 +0100, Krzysztof Kozlowski wrote: > On 12/02/2024 12:30, André Draszik wrote: > > On Mon, 2024-02-12 at 12:18 +0100, Krzysztof Kozlowski wrote: > > > I can drop it, but the actual problem is that what if downstream keeps > > > changing aliases? They can do it... > > > > We won't care at that stage, downstream should have no reason to divert from > > upstream for numbering at some point in the future. > > What do you mean by "no reason"? The reason is they can do whatever they > want. Some project leader says: "I want this" and they will do it. They > won't care about our upstream choice at all. > > And then what, you change it again? As I said above, we won't care if downstream changes again at that stage, so no, I wouldn't plan on changing again. Cheers, Andre'
On 12/02/2024 12:52, André Draszik wrote: > On Mon, 2024-02-12 at 12:40 +0100, Krzysztof Kozlowski wrote: >> On 12/02/2024 12:30, André Draszik wrote: >>> On Mon, 2024-02-12 at 12:18 +0100, Krzysztof Kozlowski wrote: >>>> I can drop it, but the actual problem is that what if downstream keeps >>>> changing aliases? They can do it... >>> >>> We won't care at that stage, downstream should have no reason to divert from >>> upstream for numbering at some point in the future. >> >> What do you mean by "no reason"? The reason is they can do whatever they >> want. Some project leader says: "I want this" and they will do it. They >> won't care about our upstream choice at all. >> >> And then what, you change it again? > > As I said above, we won't care if downstream changes again at that stage, so > no, I wouldn't plan on changing again. Then I am lost. What stage are you thinking? What differs between now and let's say 1 month for the GS101 which was released more than three years ago? BTW, the aliases I see in downstream DTS (gs101-usi.dtsi) - since beginning up to Android 14 are: hsi2c8 = &hsi2c_8; hsi2c9 = &hsi2c_9; hsi2c10 = &hsi2c_10; hsi2c11 = &hsi2c_11; hsi2c12 = &hsi2c_12; They were set like this in 2020 and never changed afterwards. Best regards, Krzysztof
On Mon, 2024-02-12 at 13:07 +0100, Krzysztof Kozlowski wrote: > On 12/02/2024 12:52, André Draszik wrote: > > As I said above, we won't care if downstream changes again at that stage, so > > no, I wouldn't plan on changing again. > > Then I am lost. What stage are you thinking? What differs between now > and let's say 1 month for the GS101 which was released more than three > years ago? The idea was to make the initial transition to using upstream easier, hence we added the same aliases as downstream (at the time). Given the transition is not happening right now, we might as well hold off with the aliases and add them later, with whatever downstream will be using at that time. If in the future somebody downstream decides 'I want this' (changed again), why should upstream care at that stage? Again, this patch was just trying to make initial transition easier, do you have a better recommendation? > BTW, the aliases I see in downstream DTS (gs101-usi.dtsi) - since > beginning up to Android 14 are: > > hsi2c8 = &hsi2c_8; > hsi2c9 = &hsi2c_9; > hsi2c10 = &hsi2c_10; > hsi2c11 = &hsi2c_11; > hsi2c12 = &hsi2c_12; > > They were set like this in 2020 and never changed afterwards. Those were incorrect and didn't actually work as intended, here's a better place to look: https://android.googlesource.com/kernel/google-modules/raviole-device/+log/refs/heads/android-gs-raviole-mainline and https://android.googlesource.com/kernel/google-modules/raviole-device/+/9864593c894da90cd8b631ab57f15c25f4e11465%5E%21/ Cheers, Andre'
On 12/02/2024 13:38, André Draszik wrote: > On Mon, 2024-02-12 at 13:07 +0100, Krzysztof Kozlowski wrote: >> On 12/02/2024 12:52, André Draszik wrote: >>> As I said above, we won't care if downstream changes again at that stage, so >>> no, I wouldn't plan on changing again. >> >> Then I am lost. What stage are you thinking? What differs between now >> and let's say 1 month for the GS101 which was released more than three >> years ago? > > The idea was to make the initial transition to using upstream easier, > hence we added the same aliases as downstream (at the time). > Given the transition is not happening right now, we might as well hold > off with the aliases and add them later, with whatever downstream will > be using at that time. Hm ok, I just did not understand what are the criteria of choosing point in time when you take the aliases from dowstream. > > If in the future somebody downstream decides 'I want this' (changed again), > why should upstream care at that stage? > > Again, this patch was just trying to make initial transition easier, do you > have a better recommendation? > >> BTW, the aliases I see in downstream DTS (gs101-usi.dtsi) - since >> beginning up to Android 14 are: >> >> hsi2c8 = &hsi2c_8; >> hsi2c9 = &hsi2c_9; >> hsi2c10 = &hsi2c_10; >> hsi2c11 = &hsi2c_11; >> hsi2c12 = &hsi2c_12; >> >> They were set like this in 2020 and never changed afterwards. > > Those were incorrect and didn't actually work as intended, here's a > better place to look: > > https://android.googlesource.com/kernel/google-modules/raviole-device/+log/refs/heads/android-gs-raviole-mainline > and > https://android.googlesource.com/kernel/google-modules/raviole-device/+/9864593c894da90cd8b631ab57f15c25f4e11465%5E%21/ Thanks, so it's like Qualcomm - DTS separate from the kernel, although here a bit confusing because partially overlapping. Best regards, Krzysztof
On 31/01/2024 00:37, André Draszik wrote: > Now that we have more than i2c interface, add aliases to ensure > deterministic bus number assignment. > > So as to keep compatibility with existing Pixel userspace builds, use > the same bus numbers for hsi2c_8 and hsi2c_12 as the downstream > drivers with the intention to eventually add all the earlier busses as > well. > > Suggested-by: Will McVicker <willmcvicker@google.com> > Signed-off-by: André Draszik <andre.draszik@linaro.org> > > --- > Note, this patch should only be applied after series > "[PATCH v3 0/7] gs101 oriole: peripheral block 1 (peric1) and i2c12 support" > https://lore.kernel.org/all/20240129174703.1175426-1-andre.draszik@linaro.org/ Dropped on request. Best regards, Krzysztof
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts index 6ccade2c8cb4..23314ed78c96 100644 --- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts @@ -18,6 +18,8 @@ / { compatible = "google,gs101-oriole", "google,gs101"; aliases { + i2c7 = &hsi2c_8; + i2c8 = &hsi2c_12; serial0 = &serial_0; };
Now that we have more than i2c interface, add aliases to ensure deterministic bus number assignment. So as to keep compatibility with existing Pixel userspace builds, use the same bus numbers for hsi2c_8 and hsi2c_12 as the downstream drivers with the intention to eventually add all the earlier busses as well. Suggested-by: Will McVicker <willmcvicker@google.com> Signed-off-by: André Draszik <andre.draszik@linaro.org> --- Note, this patch should only be applied after series "[PATCH v3 0/7] gs101 oriole: peripheral block 1 (peric1) and i2c12 support" https://lore.kernel.org/all/20240129174703.1175426-1-andre.draszik@linaro.org/ --- arch/arm64/boot/dts/exynos/google/gs101-oriole.dts | 2 ++ 1 file changed, 2 insertions(+)