[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3223f90-6e7c-4fdc-905a-770c474445e2@gmail.com>
Date: Wed, 20 Mar 2024 22:09:05 +0530
From: Ayush Singh <ayushdevel1325@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Vaishnav Achath <vaishnav.a@...com>, Michael Walle <mwalle@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
open list <linux-kernel@...r.kernel.org>, jkridner@...gleboard.org,
robertcnelson@...gleboard.org, lorforlinux@...gleboard.org,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Nishanth Menon <nm@...com>,
Vignesh Raghavendra <vigneshr@...com>, Tero Kristo <kristo@...nel.org>,
Derek Kiernan <derek.kiernan@....com>, Dragan Cvetic
<dragan.cvetic@....com>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Mark Brown <broonie@...nel.org>, Johan Hovold <johan@...nel.org>,
Alex Elder <elder@...nel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
"moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE"
<linux-arm-kernel@...ts.infradead.org>,
"open list:SPI SUBSYSTEM" <linux-spi@...r.kernel.org>,
"moderated list:GREYBUS SUBSYSTEM" <greybus-dev@...ts.linaro.org>,
Vaishnav M A <vaishnav@...gleboard.org>
Subject: Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector
On 3/20/24 01:02, Andrew Lunn wrote:
>> Yes, after discussion with Vaishnav and trying to brainstorm some way to do
>> the same thing with dt overlays, it seems that trying to use dt overlays
>> will mean need to have completely separate implementation of mikroBUS for
>> local ports and mikroBUS over greybus.
> Could you explain why please?
>
> Are greybus I2C bus masters different from physical I2C bus masters?
> Are greybus SPI bus masters different from physical SPI bus masters?
Well, they are virtual, so they are not declared in the device tree. I
have linked the greybus i2c implementation. It basically allocates an
i2c_adpater and then adds it using `i2c_add_adapter` method. This
adapter can then be passed to say mikroBUS driver where it can be used
as a normal i2c_adapter, and we can register the device to it.
>> Additionally, trying to put dt overlays in EEPROM would mean they
>> will be incompatible with use in local ports and vice versa.
> I don't think you need to put the DT overlay in the EEPROM. All you
> need to do is translate the manifest into DT for those simple devices
> which can be described by the limited manifest format. For more
> complex devices, you use the ID to go find a DT fragment which
> describes the board, and skip the manifest to DT transformation.
>
> Andrew
I am not familiar enough to know if the device tree can work with
virtual devices created by greybus subsystem.
Maybe the problem stems from the fact that mikroBUS does not have a
physical controller (and my inability to explain the patch properly).
However, the purpose of this patchset is to in fact provide a virtual
mikroBUS controller to allow us to register a mikroBUS addon board
described by board_info struct similar to how it is possible to create
and register an i2c device on an i2c adapter using
`i2c_new_client_device` or spi device using `spi_new_device`. The
manifest is used to populate this board_info struct, but it will be
possible to use something other than mikroBUS manifest if someone wants
to. I can make the necessary adjustments by moving manifest support to
its own config option.
Link:
https://elixir.bootlin.com/linux/latest/source/drivers/staging/greybus/i2c.c#L230
Greybus i2c
Ayush Singh
Powered by blists - more mailing lists