Message-ID: <CAK7LNARJhpz0AmLDL9j5c20cnv=+7CGiJMgGHhreJEd0rG3zSw@mail.gmail.com>
Date:	Fri, 16 Oct 2015 18:50:54 +0900
From:	Masahiro Yamada <yamada.masahiro@...ionext.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	arm@...nel.org, Russell King <linux@....linux.org.uk>,
	devicetree@...r.kernel.org, Kumar Gala <galak@...eaurora.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

Hi Arnd,

2015-10-16 18:18 GMT+09:00 Arnd Bergmann <arnd@...db.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.



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

Powered by blists - more mailing lists