On Wed, May 06, 2015 at 01:27:03PM +0100, Dr. H. Nikolaus Schaller wrote:
> Hi Peter,
>
> Am 06.05.2015 um 14:05 schrieb Peter Hurley <pe...@hurleysoftware.com>:
>
> > On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
> >> No, I am not playing devil’s advocate (which would imply that I am doing
> >> this
> >> for fun to tease the dog), but I feel I have to be the advocate of future
> >> board
> >> designers who want to easily import an existing board DT and overwrite
> >> device
> >> tree nodes to describe design changes, i.e. what slave device is connected
> >> to
> >> which uart.
> >
> > I dont' see a big distinction at the DTS source level, so your concern is
> > wrt
> > binary dtbs?
>
> No. My concern is wrt including existing board files and making small
> modifications
> on source level (or overlays).
>
> We discuss:
>
> board1.dts:
>
> uart3 { // subnode of some SoC
> slave { // slave connected to uart3
> compatible = „…“;
> gpio = <&gpio5 12 0>
> };
> };
>
> vs.
>
> board1.dts:
>
> / {
> slave {
> compatible = „…“;
> gpio = <&gpio5 12 0>
> uart = &uart3; // slave connected to uart3
> };
> };
>
> uart3 { // subnode of some SoC
> };
>
> now let’s have a spin of the board design which just rewires the
> slave to uart4 (somtimes hardware engineers do such things).
>
> board2.dts:
>
> #include <board-variant1.dts>
>
> // reconnect device to uart4
>
> uart4 { // subnode of some SoC
> slave { // slave connected to uart4
> compatible = „…“;
> gpio = <&gpio5 12 0>
> };
> };
>
> uart3 { // subnode of some SoC
> slave { // slave connected to uart3
> compatible = „none“ // we can’t delete imported
> subnodes
> };
> };
>
> /// add another device to uart5?
>
> uart5 { // subnode of some SoC
> slave2 { // slave connected to uart5
> compatible = „…“;
> gpio = <&gpio5 13 0>
> };
> };
If this happens, you can move the slave device into a fragment that you
can include under the correct node. That's trivial.
If you have a large amount of variation within a given platform, that is
a problem with your platform.
> So the main difference is if the slave device tells to which uart it is
> connected
> or the uart which slave device it is connected to.
>
> And I think the second approach is easier and more straightforward (on DT
> level).
We already place child nodes under their respective busses for other
interfaces like SPI and I2C. I do not see a compelling reason to do
otherwise for devices hanging off of UARTs -- doing so would make things
less straightforward because you have a fundamentally different idiom.
Having the slave live under the UART node also gives you sane probe
ordering -- you must probe the parent before the slave as the parent
driver (perhaps via common code) will trigger the scan of children.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
