Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1626026
| From | Philipp Zabel <p.zabel@pengutronix.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux |
| Date | 2017-04-19 13:10 +0200 |
| Message-ID | <txVEK-2Kc-27@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <txyf8-4Ve-9@gated-at.bofh.it> <txyf8-4Ve-7@gated-at.bofh.it> <txTWi-1CP-15@gated-at.bofh.it> <txTWi-1CP-13@gated-at.bofh.it> <txVEK-2Kc-29@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, 2017-04-19 at 12:41 +0200, Peter Rosin wrote:
> On 2017-04-19 11:17, Philipp Zabel wrote:
> > On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
> >> If I got things wrong when I skimmed whatever I came across, and if the
> >> mmio register is the only mux control option in the stars, it becomes
> >> less obvious... It's of course still possible to hook into the mux
> >> subsystem, but the benefit is questionable. And you do get the extra
> >> device tree node. You could of course also implement a mux driver
> >> outside of drivers/mux and thus make use of the mux api, but it's tiny
> >> and any benefit is truly small.
> >
> > What I wondered mostly is whether it would be a good idea to move the
> > OF-graph ports into the mux controller node, and let the video capture
> > device be the consumer of the mux.
> > But this wouldn't fit well with the clear split between the mux
> > controller and the actual mux hardware in the mux DT bindings.
>
> I have tried to do something similar. I think. The current
> drivers/i2c/muxes/i2c-mux-gpio.c is a good candidate for the same thing
> IIUC.
>
> That dedicated driver and the general purpose i2c mux driver does pretty
> much the same thing with these two DT snippets:
>
> Dedicated i2c-mux-gpio DT snippet:
>
> i2c-mux {
> compatible = "i2c-mux-gpio";
> i2c-parent = <&i2c1>;
>
> mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> i2c@1 {
> ...
> };
>
> i2c@3 {
> ...
> };
> };
>
> General purpose mux DT snippet:
>
> mux: mux-controller {
> compatible = "gpio-mux";
> #mux-control-cells = <0>;
>
> mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
> };
>
> i2c-mux {
> compatible = "i2c-mux";
> i2c-parent = <&i2c1>;
>
> mux-controls = <&mux>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> i2c@1 {
> ...
> };
>
> i2c@3 {
> ...
> };
> };
Yes, replace i2c-mux with video-mux and the i2c@x nodes with port@x
nodes, and this is very close to what I am thinking about.
> I would love to find a way to cleanly get the mux framework to handle
> the first DT as well, and thus being able to obsolete the dedicated
> i2c-mux-gpio driver. I have not figured out how to accomplish that
> without abusing the driver-model to a point that it's not working.
> Help with that task is dearly appreciated.
>
> What I have stumbled on, I think, is that two drivers needs to be
> instantiated from the same DT node. At the same time, I need the
> mux framework to handle the current out-of-node thing with a
> phandle as well, so that several mux consumers can share a common
> mux controller. My understanding of these matters are apparently not
> deep enough...
Not necessarily, if the framework could export a function to create a
gpio/mmio mux_chip on a given device and the gpio-mux and *-mux-gpio
drivers just reuse that.
> I think you would like a DT that looks more like the first DT
> snippet but still enjoy the flexibility of the mux framework and w/o
> implementing a (another) full muxing sub-sub-system like the i2c
> sub-system has done. Correct?
Correct.
regards
Philipp
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux Philipp Zabel <p.zabel@pengutronix.de> - 2017-04-18 12:10 +0200
Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux Philipp Zabel <p.zabel@pengutronix.de> - 2017-04-19 11:20 +0200
Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux Philipp Zabel <p.zabel@pengutronix.de> - 2017-04-19 13:10 +0200
Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux Philipp Zabel <p.zabel@pengutronix.de> - 2017-04-19 18:40 +0200
csiph-web