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)
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ greybus-dev mailing list -- greybus-dev@xxxxxxxxxxxxxxxx To unsubscribe send an email to greybus-dev-leave@xxxxxxxxxxxxxxxx
|