On Thu, Apr 21, 2022 at 11:44:21AM +0200, Michael Walle wrote:
> On 21/04/2022 11:11, Jerry Huang wrote:
> >> Please also answer Michael's comments.
> >>
> >> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
> >> BLE P click: https://www.mikroe.com/ble-p-click
> >> BEE click: https://www.mikroe.com/bee-click
> >> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
> >> So the name "semtech sx1301" is not correct for this node.
> >
> > I asked to remove the words "Devicetree bindings" and this was not finished.
> >
> > Now you mention that entire name of device is wrong... It's confusing. I
> > don't know what device you are describing here. I expect you know. :)
> >
> > What is this binding about exactly?
>
> I *think* it's just exposing the mikrobus connector as an spidev device.
> There was a former attempt by Vladimir here [1]. Now as it the nature
> of such a connector that you can connect a myriad of devices there, it
> doesn't really make sense to have a just particular one described. What
> happens if that one will switch from spidev to a real driver in the
> kernel? So using "spidev" for the compatible would be the first reflex.
> But as described in the spidev driver this is plain wrong (and also causes
> a warning/info message it) because it should describe the actual hardware.
>
> Thus I proposed to use DT overlays which are loaded according to what
> is actually attached to the header, so a real driver could be loaded.
>
> But there *could* be a sane default which then could be replaced in
> an DT overlay. Like "mirkobus-socket" or similar, which might expose
> spidev. Actually it is more than just SPI, there is GPIO and resets and
> I2C. Maybe it should be an MFD? I don't know. But that is something for
> the DT maintainers to decide if they'll allow such "generic" devices.
generic devices, no. MFD, no.
What's needed here is a connector node (and driver) for the mikrobus
socket. The connector node's purpose is to decouple the host DT from
add-on board overlay DT. Something like this:
connector {
// And a more specific compatible if pins can have alt funcs?
// Spec version needed?
compatible = "mikrobus-socket";
// Will need regulators defined if child devices expect
// regulators
vcc-33-supply = <®33>;
vcc-5-supply = <®5v>;
i2c-parent = <&i2c1>; // Already a defined property
spi-parent = <&spi0>; // New
// RST pin
reset-gpios = <&gpio 4 0>;
// remap 'INT' (index 0) to host interrupt
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-map = <0 0 &gpio 3 0>;
spi {
//devices
};
i2c {
};
};
The DT spec defines 'foo-map' properties extending interrupt-map.
Currently only GPIO is defined. We might want to do the same thing for
PWM. Or we make the connector node both a PWM consumer and provider.
Rob
Am 2022-04-21 16:23, schrieb Rob Herring:
> What's needed here is a connector node (and driver) for the mikrobus
> socket. The connector node's purpose is to decouple the host DT from
> add-on board overlay DT. Something like this:
Funny I had a similar idea to have a connector with all the
properties, but I failed to see how that would be of any help.
Do you mind an example of such an overlay? Judging by the spi
and i2c subnode, I guess it will amend the connector node and
fill in it's devices?
And all the child device properties will reference the connector,
correct?
> connector {
> // And a more specific compatible if pins can have alt funcs?
> // Spec version needed?
> compatible = "mikrobus-socket";
>
> // Will need regulators defined if child devices expect
> // regulators
> vcc-33-supply = <®33>;
> vcc-5-supply = <®5v>;
>
> i2c-parent = <&i2c1>; // Already a defined property
> spi-parent = <&spi0>; // New
uart/serial needed too?
>
> // RST pin
> reset-gpios = <&gpio 4 0>;
>
> // remap 'INT' (index 0) to host interrupt
> #interrupt-cells = <2>;
> #address-cells = <0>;
> interrupt-map = <0 0 &gpio 3 0>;
>
> spi {
For example:
my-device@0 {
reg = <0>; // really needed? there is only one SPI CS line
compatible = "my-device";
reset-gpios = // may be left unset if it's optional, but what
// what if it is a required property and in hardware
// its connected to the RST pin of the module?
other-gpios = <&connector 2>;
vdd-supply = // what comes here? <&connector VCC_33>?
interrupts-extended = <&connector 0 ..>;
}
-michael
> //devices
> };
>
> i2c {
>
> };
> };
>
> The DT spec defines 'foo-map' properties extending interrupt-map.
> Currently only GPIO is defined. We might want to do the same thing for
> PWM. Or we make the connector node both a PWM consumer and provider.
>
> Rob
On Thu, Apr 21, 2022 at 10:16 AM Michael Walle <[email protected]> wrote:
>
> Am 2022-04-21 16:23, schrieb Rob Herring:
>
> > What's needed here is a connector node (and driver) for the mikrobus
> > socket. The connector node's purpose is to decouple the host DT from
> > add-on board overlay DT. Something like this:
>
> Funny I had a similar idea to have a connector with all the
> properties, but I failed to see how that would be of any help.
>
> Do you mind an example of such an overlay? Judging by the spi
> and i2c subnode, I guess it will amend the connector node and
> fill in it's devices?
Right.
>
> And all the child device properties will reference the connector,
> correct?
Right.
>
> > connector {
> > // And a more specific compatible if pins can have alt funcs?
> > // Spec version needed?
> > compatible = "mikrobus-socket";
> >
> > // Will need regulators defined if child devices expect
> > // regulators
> > vcc-33-supply = <®33>;
> > vcc-5-supply = <®5v>;
> >
> > i2c-parent = <&i2c1>; // Already a defined property
> > spi-parent = <&spi0>; // New
>
> uart/serial needed too?
Yes. Serial has the extra issue in the kernel that tty vs. serdev are
mutually exclusive and decided by presence or not of a child node for
the UART. That would need some work to dynamically switch. I think I
have some old patches doing that, but they probably break some aspects
of TTY expectations.
>
> >
> > // RST pin
> > reset-gpios = <&gpio 4 0>;
> >
> > // remap 'INT' (index 0) to host interrupt
> > #interrupt-cells = <2>;
> > #address-cells = <0>;
> > interrupt-map = <0 0 &gpio 3 0>;
> >
> > spi {
>
> For example:
>
> my-device@0 {
> reg = <0>; // really needed? there is only one SPI CS line
Yes, needed.
> compatible = "my-device";
> reset-gpios = // may be left unset if it's optional, but what
> // what if it is a required property and in hardware
> // its connected to the RST pin of the module?
Probably should not be required and the connector driver manages it.
> other-gpios = <&connector 2>;
> vdd-supply = // what comes here? <&connector VCC_33>?
That has to be figured out, but *-supply doesn't take arg cells
currently. Probably the connector needs to define its own regulator
nodes.
> interrupts-extended = <&connector 0 ..>;
> }
Rob