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
What happens to the devices that fall outside of the "do not need a
complex description" category? Do you expect that those would be
described by a dt overlay?
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.
The greybus manifest extensions were made with the following things in mind
and three new descriptor were introduced:
1) mikrobus descriptor - pinmux/port state
2) device descriptor - contains information which is a superset of struct
i2c_board_info , struct spi_board_info .etc
3) property descriptor - to describe named properties of the types defined
under https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/property.h#n22
With these we were able to test around 150 add-on boards with corresponding
drivers in Linux :
https://github.com/MikroElektronika/click_id/tree/main/manifests
The mechanism is not as robust a device tree and should not be compared, the
Why not? You're suggesting this as a method for describing devices and you
seem to have extended the manifest to support more complex properties, why
shouldn't someone question make that comparison?
intent was not to create a new hardware description format, but extend the
existing greybus manifest format to be able to instantiate devices on the
greybus SPI/I2C/GPIO/ (mikroBUS)