On 3/19/24 22:49, Vaishnav Achath wrote:
A driver could call a user-space helper, which will read the EEPROM
content (or maybe the driver already passes the content to the
helper), translate it to a DT overlay, and load it. Wouldn't that
work?
I'm not saying that is the way to go, just evaluate some ideas.
This would work in most cases when we want to instantiate devices on a
physical mikroBUS port on the host running Linux, but another use case
we need to support is to instantiate devices on a virtual/greybus
mikroBUS port created through greybus, this is the case when a remote
microcontroller board (Example BeagleConnect Freedom) has mikroBUS
ports and through the magic of greybus these virtual ports
(corresponding to the physical remote ports) appear on the Linux host
- now we cannot use a device tree overlay to instantiate a Weather
click (BME280) sensor on this port, that is why the choice of
extending greybus manifest was chosen, another alternative here is to
go and add device tree as a description mechanism for greybus, please
let know if that is the recommended way forward?
The greybus manifest already is being used in the greybus susbystem
for describing an interface and there are already greybus controllers
(SPI/I2C .etc) being created according to the manifest contents, all
this driver does is to extend that format to be able to instantiate
devices on these buses. The primary goals for introducing the driver
for mikroBUS add-on boards are:
1) A way to isolate platform specific information from add-on board
specific information - so that each permutation of connecting the
add-on board on different ports on different board does not require a
new overlay.
2) A way to instantiate add-on boards on greybus created virtual
mikroBUS ports.
3) Both 1 and 2 should use the same add-on board description format.
Standard device tree overlays did not help to achieve this and that is
why the standard interface discovery mechanism in greybus, the
manifest was extended even though it is not the most optimal way to
describe hardware.
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. Additionally, trying
to put dt overlays in EEPROM would mean they will be incompatible with
use in local ports and vice versa.
Also, I feel like jumping to userspace can fail for all sorts of reasons
and undermine the plug and play support that clickID strives for.
The manual involvement of user space is only for non EEPROM boards
since
we do not have a way to identify the board without the user needing to
provide the manifest.
FWIW, I'm not talking about manual steps here. But more of
call_usermodehelper(). Or maybe udev can do it?
Btw, [1] mentions hot-plugging. Is that really hot-plugging while
the system is running? How would that work?
This should be corrected, it is not recommended to hot-plug the board
as the connector standard does not ensure any power sequencing and can
cause damage.
Yes, as long as local port is concerned, hot plugging is not
recommended. However, when using greybus, it is possible to hotplug the
node that mikroBUS is connected to.
Also how do you know whether there is an EEPROM
or not?
Set RST GPIO to low. clickID supported board will enter ID MODE, Then
check if CS line has a w1 gpio bus.
Ok.
3. Over Greybus
It is quite important to have mikroBUS over greybus for
BeagleConnect.
This is one of the major reasons why greybus manifest was chosen
for the
manifest format.
Also, it is important to note that mikroBUS manifest is being used
since
2020 now and thus manifests for a lot of boards (both supporting
clickID
and not supporting it exist). So I would prefer using it, unless of
course there are strong reasons not to.
And also here, I'm not really familiar with greybus. Could you give
a more complex example? My concern is that some driver might need
additional properties from DT (or software nodes) to function
properly. It might not only be a node with a compatible string but
also more advanced bindings. How would that play together with this?
My gut feeling is that you can handle any missing properties
easier/better (eg. for existing modules) in user space. But maybe
that is already solved in/with greybus?
Greybus is a communication protocol designed for modular electronic
devices. It allows different parts of a device to be hot plugged (added
or removed) while the device is still running. Greybus manifest is used
to describe the capabilities of a module in the greybus network. The
host then creates appropriate bidirectional unipro connections with the
module based on the cports described in the manifest. I have added a
link to lwn article that goes into more detail.
BeagleConnect simply allows using greybus over any bidirectional
transport, instead of just Unipro.
I cannot comment much about how greybus handles missing properties.
While greybus also works just in kernel space, greybus protocols are
inherently higher level than kernel driver, so it might have an easier
time with this.
I have also added a link to eLInux page which provides rational for the
mikroBUS manifest. But the crux seems to be that dynamic overlays were
not well-supported back then. Also, the use of mikroBUS using greybus
subsystem was already used. Hence the mikroBUS driver.
I see this as an opportunity to improve the in-kernel overlays :)
Greybus is not a big blocker from my perspective, since it is always
possible to introduce a new protocol for mikroBUS in Greybus spec. I
think as long as both EEPROM and non EEPROM boards can be supported by
mikroBUS driver and dt-bindings, are can be used outside of Linux (eg:
ZephyrRTOS, nuttx, etc), it is fine.
Here's a random one: the manifest [1] just lists the compatible
string apparently, but the actual DT binding has also reset-gpios,
some -supply and interrupt properties.
-michael
[1]
https://github.com/MikroElektronika/click_id/blob/main/manifests/WEATHER-CLICK.mnfs
Yes, the concern is valid. Support for validating the manifest is
nowhere near as good as devicetree overlays. But I think that would
be a
problem with the device rather than the responsibility of the
kernel. It
is up to the manufacturer to have valid manifests.
But does the manifest have the capabilities to express all that
information? To me it looks like just some kind of pinmux, some
vendor strings and a (DT) compatible string.
[coming back to this after seeing [2]: there are more properties,
but it seem just be a list of property=value]
What I'd like to avoid is some kind of in-kernel mapping list from
manifest to actual driver instantiation.
The property descriptor is implemented to account the properties under
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/property.h#n22
There is no in-kernel mapping that needs to be updated per driver, but
a generic mapping and some specific mapping depending on the bus the
device is connected (I2C/SPI/.etc)
I guess you'll get much of that with DT overlays already and if you
have some kind of automatic translation from manifest to DT overlay,
it will still be plug-and-play. You could fix up any missing
properties, etc. manually loading some manifests/dt overlays for
modules without EEPROMs.
Again, a more complex manifest file would really be appreciated
here. Not just a simple "there is exactly one trivial SPI device on
the bus".
FWIW, here is a more complex example [2] which uses the ssd1306
display driver. Dunno if that is a good example, as it seems to use
the fb_ssd1306 driver (at least that's what I'm deducing by reading
the driver-string-id) in staging and there is also ssd1307fb.c in
drivers/video/fbdev. But how are the additional information like
width and height translate to the properties of the driver (device
tree properties, swnode properties, platform_data*)?
The driver uses device_property_read_* helpers to fetch the
infromation and the mikroBUS driver populates the table of properties
fetching the information from manifest and combining with platform
information.
On a side note, does the manifest files use the (linux) kernel
module name for the driver-string-id?
The spi_device_id is used for the driver-string-id :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/fbtft/fbtft.h#n361
Thanks and Regards,
Vaishnav
-michael
[1] https://github.com/MikroElektronika/click_id/blob/main/README.md
[2]
https://github.com/MikroElektronika/click_id/blob/main/manifests/OLEDB-CLICK.mnfs
Link: https://lwn.net/Articles/715955/ Greybus
Link https://elinux.org/Mikrobus eLinux article
I apologize if I gave the wrong impression, but the ability to enable
mikroBUS over Greybus is extremely important here. I left out mikroBUS
over greybus support from this patchset to allow for easier upstreaming
of a new driver. However, that does not mean it is a secondary goal of
this patch.
The current mikroBUS manifest is compatible with Greybus manifest, and
thus is easy to integrate into standard Greybus. Anything suggested here
still needs to enable support of mikroBUS over Greybus.
Ayush Singh
