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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html