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_Support
Is 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
