All of lore.kernel.org
 help / color / mirror / Atom feed
* node modification by overlay does not trigger probe
@ 2016-06-22 20:52 Michal Suchanek
  0 siblings, 0 replies; only message in thread
From: Michal Suchanek @ 2016-06-22 20:52 UTC (permalink / raw)
  To: devicetree

Hello,

I have been experimenting with overlays a bit.

I have a board with SPI interface on an external header.

The first use was like this:

------------board file excerpt:
&spi2 {
        pinctrl-names = "default";
        pinctrl-0 = <&spi2_pins_a>,
                    <&spi2_cs0_pins_a>;
        status = "okay";
};

------------overlay:
/dts-v1/;
/plugin/;

/ {
    compatible = "olimex,a10s-olinuxino-micro";

    /* identification */
    part-number = "A10S-SPI2";

    fragment@0 {
        target = <&spi2>;
        __overlay__ {
            #address-cells = <1>;
            #size-cells = <0>;
            flash: m25p80@0 {
                #address-cells = <1>;
                #size-cells = <1>;
                compatible = "spidev";
                reg = <0>;
                spi-max-frequency = <40000000>;
                   };
        };
    };
};

This is copied from some random example and modified for this use
case. It adds the whole SPI slave device node and specifies the CS in
the overlay.

Later I tried this approach with CS in board file which gives more
generic overlay:
-----------board:
&spi2 {
        pinctrl-names = "default";
        pinctrl-0 = <&spi2_pins_a>,
                    <&spi2_cs0_pins_a>;
        status = "okay";

        uext_spi: spi@uext {
                reg = <0>;
                spi-max-frequency = <40000000>;
                status = "disabled";
        };
};
----------overlay:
/dts-v1/;
/plugin/;

/ {
  compatible = "olimex,uext";

  /* identification */
  part-number = "Olimex-UEXT";

  fragment@0 {
    target = <&uext_spi>;
    __overlay__ {
      compatible = "spidev";
      spi-max-frequency = <40000000>;
      status = "okay";
    };
  };
};

This works so long as I have status = "disabled" frobbed to "okay" by
the overlay. Without the status lines in the board and overlay file
the SPI driver needs to be reloaded for the change to take effect.

It's not entirely out of question to specify the status. However,
there are problems

 - the SPI CS along with the other SPI pins are used on a connector so
they should not have the "disabled" status reserved for unused
hardware. When a patch for automagic binding of spidev to every CS was
proposed a concern was raised that the unused CS lines could cause
other hardware malfunction when triggered. So in that spirit the CS
which *is* used by the connector should be marked as enabled.

- I want to get rid of the spoidev log spam caused by this overlay by
making the spidev binding implicit. That is for each spi slave the
spidev device is created automagically. For that the slave must be
marked as enabled in the board file and that precludes loading another
driver for the slave through overlay because the re-probe is not
triggered when the device was already enabled.

Is there a reasonable way to fix this? Re-probing modified nodes
should be possible. I am not aware of anything that would break given
facilities for actually loading overlays are not mainlined so far.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2016-06-22 20:52 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-22 20:52 node modification by overlay does not trigger probe Michal Suchanek

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.