Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1252572 > unrolled thread

Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support Masahiro Yamada <yamada.masahiro@socionext.com> - 2015-10-21 10:50 +0200
    Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support Arnd Bergmann <arnd@arndb.de> - 2015-10-23 22:20 +0200

#1252572 — Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

Hi Arnd,


2015-10-16 18:50 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> Hi Arnd,
>
> 2015-10-16 18:18 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>> On Friday 16 October 2015 14:24:30 Masahiro Yamada wrote:
>>>
>>> No, it is not a typo, but intentional.
>>>
>>>
>>> i2c0 - i2c3 are connected to the pads of the SoC package.
>>> On the other hand, i2c-4 - i2c-6 are connected to
>>> internal devices inside the SoC package.
>>>
>>> i2c-4 - i2c-6 are always connected to the same hardware
>>> devices and always used for the same purpose.
>>>
>>>
>>> My expected scenario is:
>>>
>>> [1] i2c0 - i2c3 are connected to the on-board devices
>>>     depending on board variants.
>>>     On some boards, their status is "okay" and
>>>     on some boards, their status is "disabled".
>>>
>>> [2] i2c4 - i2c6 are always used to communicate
>>>     with in-package devices.  The status is always "okay".
>>
>> I think you are getting confused because the data sheet uses
>> the same names as the kernel, but they are really different
>> things.
>>
>> How about boards that have i2c connectors that are labeled
>> differently?
>
>
> I guess it would rarely happen as it is confusing.
>
> The board connectors are generally named
> correspondingly to the hardware block ID in the SoC.
>
>
>
>> We want the aliases to match whatever is written on the
>> board normally, to make it easier for users.
>>
>>> [3] Some user-land applications may want to have access
>>>      through the same character devices,
>>>       /dev/i2c4, /dev/i2c5, /dev/i2c6
>>
>> That user space would however only work on boards with the
>> same SoC, which is not a safe assumption to make.
>
> Right.
>
>> Either
>> it should be specific to just one board which has a known
>> set of buses, or it should be done in a way that works
>> across SoC generations of families.
>>
>> Ideally the devices on the internal buses would have an
>> in-kernel driver that exports a high-level API to avoid this
>> problem. What devices are these?
>
> HDMI transmitter, TV signal demodulator, etc.
>
>
>
>>> If your way is adopted,
>>> the real hardware "i2c4" might be aligned to /dev/i2c1 on some boards,
>>> and /dev/i2c2 on others, etc.
>>
>> Right, I think that is how it should be. You could also make
>> the chip's i2c4 always link to user space /dev/i2c0 if you
>> want to keep those stable, but as I said that is still not
>> a good (software) system design.
>>
>
> Right.  In-kernel drivers can handle it nicely.
>
> Also, we can write a device tree that specifies device connection
> hierarchy like follows.
> The device names will appear under /sys/ directory and user-land
> applications can check them.
>
> &i2c4 {
>         demodulator {
>                  compatible = "...";
>
>         };
> };
>
> &i2c6 {
>          hdmi_tx {
>
>                    compatible = "...";
>          };
> }
>
>
> I understand that I2C bus number assumption is avoidable,
> but I am still not fully convinced.
>
> Matching /dev/i2c* and the real hardware block ID (this is written in
> the SoC spec book)
> makes things clearer, I think.
>


Anyway, this version is unacceptable, right?





-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1254994

On Wednesday 21 October 2015 17:49:12 Masahiro Yamada wrote:
> > Right.  In-kernel drivers can handle it nicely.
> >
> > Also, we can write a device tree that specifies device connection
> > hierarchy like follows.
> > The device names will appear under /sys/ directory and user-land
> > applications can check them.
> >
> > &i2c4 {
> >         demodulator {
> >                  compatible = "...";
> >
> >         };
> > };
> >
> > &i2c6 {
> >          hdmi_tx {
> >
> >                    compatible = "...";
> >          };
> > }
> >
> >
> > I understand that I2C bus number assumption is avoidable,
> > but I am still not fully convinced.
> >
> > Matching /dev/i2c* and the real hardware block ID (this is written in
> > the SoC spec book)
> > makes things clearer, I think.
> >
> 
> 
> Anyway, this version is unacceptable, right?

Sorry for the late reply.

I would not call it unacceptable, just a bit unpleasant. We can merge it
if you cannot come up with a nicer way to do this. It was a good idea
to split to resend the series without this patch, but the replacement
to delete the aliases also doesn't look nice. If we can't come up with
a better way to do this, I'd suggest you re-send this patch and add a
bit more explanation into the changelog as to why you want this to
be done in an unusual way.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web