From: Vaishnav Achath <vaishnav.a@ti.com>
To: Andrew Lunn <andrew@lunn.ch>, Ayush Singh <ayushdevel1325@gmail.com>
Cc: Michael Walle <mwalle@kernel.org>,
open list <linux-kernel@vger.kernel.org>,
<jkridner@beagleboard.org>, <robertcnelson@beagleboard.org>,
<lorforlinux@beagleboard.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>, Nishanth Menon <nm@ti.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tero Kristo <kristo@kernel.org>,
Derek Kiernan <derek.kiernan@amd.com>,
Dragan Cvetic <dragan.cvetic@amd.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Brown <broonie@kernel.org>, Johan Hovold <johan@kernel.org>,
Alex Elder <elder@kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
"open list:SPI SUBSYSTEM" <linux-spi@vger.kernel.org>,
"moderated list:GREYBUS SUBSYSTEM" <greybus-dev@lists.linaro.org>,
Vaishnav M A <vaishnav@beagleboard.org>
Subject: Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector
Date: Tue, 19 Mar 2024 23:05:37 +0530 [thread overview]
Message-ID: <4b319264-bff7-48e5-85e8-201ca0bafec6@ti.com> (raw)
In-Reply-To: <b62915ca-c151-4e37-bb03-c92c569c84ff@lunn.ch>
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
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 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)
Thanks and Regards,
Vaishnav
>
> Andrew
next prev parent reply other threads:[~2024-03-19 17:36 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-17 19:37 [PATCH v4 0/5] misc: Add mikroBUS driver Ayush Singh
2024-03-17 19:37 ` [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector Ayush Singh
2024-03-18 12:22 ` Michael Walle
2024-03-18 17:20 ` Ayush Singh
2024-03-19 5:58 ` Krzysztof Kozlowski
2024-03-19 7:36 ` Ayush Singh
2024-03-19 9:38 ` Michael Walle
2024-03-19 11:36 ` Ayush Singh
2024-03-19 12:08 ` Michael Walle
2024-03-19 13:03 ` Ayush Singh
2024-03-19 14:21 ` Michael Walle
2024-03-19 17:19 ` Vaishnav Achath
2024-03-19 17:35 ` Ayush Singh
2024-03-19 19:32 ` Andrew Lunn
2024-03-20 16:39 ` Ayush Singh
2024-03-20 18:44 ` Andrew Lunn
2024-03-21 7:35 ` Vaishnav Achath
2024-03-21 12:31 ` Andrew Lunn
2024-03-19 12:25 ` Andrew Lunn
2024-03-19 17:35 ` Vaishnav Achath [this message]
2024-03-19 18:19 ` Conor Dooley
2024-03-21 6:30 ` Vaishnav Achath
2024-03-19 19:23 ` Andrew Lunn
2024-03-21 7:07 ` Vaishnav Achath
2024-03-21 9:38 ` Michael Walle
2024-03-21 11:55 ` Vaishnav Achath
2024-03-21 12:44 ` Michael Walle
2024-03-21 12:55 ` Andrew Lunn
2024-03-19 6:03 ` Krzysztof Kozlowski
2024-03-19 6:42 ` Ayush Singh
2024-03-19 19:37 ` Conor Dooley
2024-03-22 18:15 ` Ayush Singh
2024-03-22 18:51 ` Andrew Lunn
2024-03-17 19:37 ` [PATCH v4 2/5] spi: Make of_find_spi_controller_by_node() available Ayush Singh
2024-03-19 8:16 ` Markus Elfring
2024-03-17 19:37 ` [PATCH v4 3/5] greybus: Add mikroBUS manifest types Ayush Singh
2024-03-19 8:26 ` Vaishnav Achath
2024-03-17 19:37 ` [PATCH v4 4/5] mikrobus: Add mikroBUS driver Ayush Singh
2024-03-17 19:59 ` Randy Dunlap
2024-03-18 17:34 ` Markus Elfring
2024-03-18 17:58 ` Markus Elfring
2024-03-18 18:41 ` Alex Elder
2024-03-18 18:55 ` Greg Kroah-Hartman
2024-03-18 18:12 ` Markus Elfring
2024-03-19 6:04 ` Krzysztof Kozlowski
2024-03-19 6:47 ` Ayush Singh
2024-03-19 8:00 ` Vaishnav Achath
2024-03-20 7:33 ` Krzysztof Kozlowski
2024-03-19 8:49 ` Vaishnav Achath
2024-03-17 19:37 ` [PATCH v4 5/5] dts: ti: k3-am625-beagleplay: Add mikroBUS Ayush Singh
2024-03-19 5:59 ` Krzysztof Kozlowski
2024-03-19 6:34 ` Ayush Singh
2024-03-20 7:31 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4b319264-bff7-48e5-85e8-201ca0bafec6@ti.com \
--to=vaishnav.a@ti.com \
--cc=andrew@lunn.ch \
--cc=arnd@arndb.de \
--cc=ayushdevel1325@gmail.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=derek.kiernan@amd.com \
--cc=devicetree@vger.kernel.org \
--cc=dragan.cvetic@amd.com \
--cc=elder@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=greybus-dev@lists.linaro.org \
--cc=jkridner@beagleboard.org \
--cc=johan@kernel.org \
--cc=kristo@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=lorforlinux@beagleboard.org \
--cc=mwalle@kernel.org \
--cc=nm@ti.com \
--cc=robertcnelson@beagleboard.org \
--cc=robh@kernel.org \
--cc=vaishnav@beagleboard.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).