arm64: dts: exynos: gs101: add stable i2c aliases for gs101-oriole

  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(+)
  

Hi Andre,

On 01/30/2024, 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>

Tested-by: Will McVicker <willmcvicker@google.com>

> 
> ---
> 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(+)
> 
> 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;
>  	};
>  
> -- 
> 2.43.0.429.g432eaa2c6b-goog
> 

I verified this works on my device:

  # ls -l /sys/bus/i2c/devices/
  total 0
  <snip> 7-0050 -> ../../../devices/platform/soc@0/109700c0.usi/10970000.i2c/i2c-7/7-0050
  <snip> i2c-7 -> ../../../devices/platform/soc@0/109700c0.usi/10970000.i2c/i2c-7
  <snip> i2c-8 -> ../../../devices/platform/soc@0/10d500c0.usi/10d50000.i2c/i2c-8


Thanks,
Will
  

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