Hi Andrew, On 20/03/24 00:53, Andrew Lunn wrote:
On Tue, Mar 19, 2024 at 11:05:37PM +0530, Vaishnav Achath wrote:Hi Andrew, On 19/03/24 17:55, Andrew Lunn wrote:The device tree defines the SPI controller associated with mikroBUS SPI pins. The driver on match queries and takes a reference to the SPI controller but does nothing with it. Once a mikroBUS add-on board is detected (by passing manifest using sysfs or reading from 1-wire EEPROM), the driver parses the manifest, and if it detects an SPI device in manifest, it registers SPI device along with setting properties such as `chip_select`, `max_speed_hz`, `mode`, etc.,How complex can the description of the hardware be in the manifest? Could i describe an SPI to I2C converter? And then a few temperature sensors, a fan controller, and a GPIO controller on that I2C bus? And the GPIO controller is then used for LEDs and a push button? DT overlays could describe that. Can the manifest?No, it cannot describe such complex hardware, it can only describe simple devices (sensors/displays .etc) on a standard mikroBUS add-on board, we did a analysis on what mikroBUS add-on boards have driver support in Linux and then noticed that most devices does not need this kind of complex description to work: https://elinux.org/MikroEClicks_with_Linux_SupportIs that because the current software support is too limited? Are there manufactures who want to create more complex designed, but are limited by what can be described in the manifest?
most mikroBUS add-on boards in production lies in the category of sensors, displays, connectivity, mixed signal (ADC/DAC .etc) and if you look at the existing bindings under bindings/iio/ , most devices need only simple descriptions and the properties are mainly standard bus properties (SPI/I2C properties), IRQ, named-gpios, named properties, regulators, clocks the extension to manifest was made taking this into account and the named property description interface just maps the manifest entries to the unified device property interface under include/linux/property.h
Do you have a list of boards without Linux support? Why do they not have Linux support? Is there a "vendor crap" driver which makes them work? Does it make them work by working around the manifest limitations?
I did the survey in 2020, close to 600 board did not have Linux support and 150 board had support then, the boards which did not have Linux support was mostly because there was no corresponding driver present and a lot of these were similar to the 150 that had support (IIO sensors, ADC, DACs .etc), there is no vendor(Example MikroElektronika) drivers being maintained, so I am not sure if there are drivers working around limitations of manifests , but for the 150 boards that we have tested support we never had to make any changes to the underlying device drivers to be supported.
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.I don't know anything about greybus, so let me ask a few background questions. Are these SPI and I2C controller plain Linux SPI and I2C controllers? They fit the usual device model, they appear in /sys/class/bus etc? Are the GPIO controllers also just plain Linux GPIO controllers? All the drivers have a bottom interface which uses greybus to perform some sort of RPC, but the top interface is standard Linux. So in fact they are not so different to I2C over USB, SPI over USB, GPIO over USB?
They are very similar and all the details you mentioned are correct, I will provide some comments on the DT proposal you made and why we could not implement that approach initially, primarily it is because PCIe and USB has OF device tree support and USB interface nodes are children of USB device nodes and there is some hardware parent we can tie USB interface to and share/derive the of_node, but in case of greybus we could not find such mapping - looking at your proposal that is more maintainable in the long term, have some doubts regarding the proposal will post in the other thread.
Thanks and Regards, Vaishnav
Andrew
_______________________________________________ greybus-dev mailing list -- greybus-dev@xxxxxxxxxxxxxxxx To unsubscribe send an email to greybus-dev-leave@xxxxxxxxxxxxxxxx
|