Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 29/11/16 16:02, Peter Rosin wrote: > On 2016-11-27 13:00, Jonathan Cameron wrote: >> On 23/11/16 11:47, Peter Rosin wrote: >>> On 2016-11-22 21:58, Lars-Peter Clausen wrote: On 11/21/2016 02:17 PM, Peter Rosin wrote: [...] > I have a piece of hardware that is using the same 3 GPIO pins > to control four 8-way muxes. Three of them control ADC lines > to an ADS1015 chip with an iio driver, and the last one > controls the SDA line of an i2c bus. We have some deployed > code to handle this, but you do not want to see it or ever > hear about it. I'm not sure why I even mention it. Anyway, > the situation has nagged me to no end for quite some time. > > So, after first getting more intimate with the i2c muxing code > and later discovering the drivers/iio/inkern.c file and > writing a couple of drivers making use of it, I came up with > what I think is an acceptable solution; add a generic mux > controller driver (and subsystem) that is shared between all > instances, and combine that with an iio mux driver and a new > generic i2c mux driver. The new i2c mux I called "simple" > since it is only hooking the i2c muxing and the new mux > controller (much like the alsa simple card driver does for ASoC). While abstracting this properly is all nice and good and the way it should be done, but it also adds a lot of complexity and the devicetree adds a lot of restrictions on what can actually be represented. >>> >>> This is a characterization without any specifics. But is the >>> characterization true? You have two complaints, complexity >>> and restrictions with bindings. >>> There is a certain point where the fabric on a PCB becomes so complex that it deserves to be a device on its own (like the audio fabric drivers). Especially when the hardware is built with a certain application in mind and the driver is supposed to impose policy which reflects this application. The latter can often not properly be described with the primitives the devicetree can offer. And I think your setup is very borderline what can be done in a declarative way only and it adds a lot of complexity over a more imperative solution in form of a driver. I think it is worth investigating about having a driver that is specific to your fabric and handles the interdependencies of the discrete components. >>> >>> So, there are three "new" concepts: >>> >>> 1. Sticking a mux in front of an AD-converter. That's not all that >>> novel, nor complex. Quite the opposite, I'd say. In fact, I find it >>> a bit amazing that there is no in-kernel support for it. >> As ever first person who needs it and has the skills to write it gets to do >> it ;) >> Congratulations Peter ;) >>> >>> 2. Reusing the same GPIO-pins to drive different muxes. There are >>> obviously chips that work this way (as Jonathan pointed out) and >>> these will at some point get used in Linux devices. I guess they >>> already are used, but that people handle them in userspace. Or >>> something? If this is complex, which I question, it will still need >>> support at some point. At least that's what I believe. >>> >>> 3. Using the same GPIO pins to mux things handled by different >>> subsystems. Right, this is a bit crazy, and I'd rather not have this >>> requirement, but this HW is what it is so I'll need to handle it in >>> some way. It is also what stops me from falling back to a userspace >>> solution, which is probably connected to why #1 and #2 is not supported >>> by the kernel; everybody probably does muxing in userspace. Which is >>> not necessarily a good idea, nor how it's supposed to be done... >>> >>> So, the only thing that's out of the ordinary (as I see it), is #3. >>> The question that then needs an answer is how the in-kernel solution >>> for #1 and #2 would look if we do not consider #3. >>> >>> And I claim that the desired solution to #1 and #2 is pretty close >>> to my proposal. >>> >>> A. You do not want mux-controller drivers in every subsystem that >>> needs them. >> Agreed. >>> >>> B. You do not want every mux-consumer to know the specifics of how to >>> operate every kind of mux; there are muxes that are not controlled >>> with GPIO pins... >>> >>> C. When you implement muxing in a subsystem, there will in some cases >>> be a need to handle parallel muxing, where there is a need to share >>> mux-controllers. >>> >>> It just feels right to separate out the mux-controller and refer to >>> it from where a mux is needed. It solves #1 and #2. And, of course, >>> as a bonus #3 is also solved. But my bias is obvious. >>> >>> And that leads us to the restrictions with the bindings. And the same >>> thing happens; the solution for #2 also solves #3. >>> >>> So how do you refer to a mux-controller from where it's needed? My >>> first proposal used a dt phandle, for the second round I put them in >>> the parent
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 29/11/16 16:02, Peter Rosin wrote: > On 2016-11-27 13:00, Jonathan Cameron wrote: >> On 23/11/16 11:47, Peter Rosin wrote: >>> On 2016-11-22 21:58, Lars-Peter Clausen wrote: On 11/21/2016 02:17 PM, Peter Rosin wrote: [...] > I have a piece of hardware that is using the same 3 GPIO pins > to control four 8-way muxes. Three of them control ADC lines > to an ADS1015 chip with an iio driver, and the last one > controls the SDA line of an i2c bus. We have some deployed > code to handle this, but you do not want to see it or ever > hear about it. I'm not sure why I even mention it. Anyway, > the situation has nagged me to no end for quite some time. > > So, after first getting more intimate with the i2c muxing code > and later discovering the drivers/iio/inkern.c file and > writing a couple of drivers making use of it, I came up with > what I think is an acceptable solution; add a generic mux > controller driver (and subsystem) that is shared between all > instances, and combine that with an iio mux driver and a new > generic i2c mux driver. The new i2c mux I called "simple" > since it is only hooking the i2c muxing and the new mux > controller (much like the alsa simple card driver does for ASoC). While abstracting this properly is all nice and good and the way it should be done, but it also adds a lot of complexity and the devicetree adds a lot of restrictions on what can actually be represented. >>> >>> This is a characterization without any specifics. But is the >>> characterization true? You have two complaints, complexity >>> and restrictions with bindings. >>> There is a certain point where the fabric on a PCB becomes so complex that it deserves to be a device on its own (like the audio fabric drivers). Especially when the hardware is built with a certain application in mind and the driver is supposed to impose policy which reflects this application. The latter can often not properly be described with the primitives the devicetree can offer. And I think your setup is very borderline what can be done in a declarative way only and it adds a lot of complexity over a more imperative solution in form of a driver. I think it is worth investigating about having a driver that is specific to your fabric and handles the interdependencies of the discrete components. >>> >>> So, there are three "new" concepts: >>> >>> 1. Sticking a mux in front of an AD-converter. That's not all that >>> novel, nor complex. Quite the opposite, I'd say. In fact, I find it >>> a bit amazing that there is no in-kernel support for it. >> As ever first person who needs it and has the skills to write it gets to do >> it ;) >> Congratulations Peter ;) >>> >>> 2. Reusing the same GPIO-pins to drive different muxes. There are >>> obviously chips that work this way (as Jonathan pointed out) and >>> these will at some point get used in Linux devices. I guess they >>> already are used, but that people handle them in userspace. Or >>> something? If this is complex, which I question, it will still need >>> support at some point. At least that's what I believe. >>> >>> 3. Using the same GPIO pins to mux things handled by different >>> subsystems. Right, this is a bit crazy, and I'd rather not have this >>> requirement, but this HW is what it is so I'll need to handle it in >>> some way. It is also what stops me from falling back to a userspace >>> solution, which is probably connected to why #1 and #2 is not supported >>> by the kernel; everybody probably does muxing in userspace. Which is >>> not necessarily a good idea, nor how it's supposed to be done... >>> >>> So, the only thing that's out of the ordinary (as I see it), is #3. >>> The question that then needs an answer is how the in-kernel solution >>> for #1 and #2 would look if we do not consider #3. >>> >>> And I claim that the desired solution to #1 and #2 is pretty close >>> to my proposal. >>> >>> A. You do not want mux-controller drivers in every subsystem that >>> needs them. >> Agreed. >>> >>> B. You do not want every mux-consumer to know the specifics of how to >>> operate every kind of mux; there are muxes that are not controlled >>> with GPIO pins... >>> >>> C. When you implement muxing in a subsystem, there will in some cases >>> be a need to handle parallel muxing, where there is a need to share >>> mux-controllers. >>> >>> It just feels right to separate out the mux-controller and refer to >>> it from where a mux is needed. It solves #1 and #2. And, of course, >>> as a bonus #3 is also solved. But my bias is obvious. >>> >>> And that leads us to the restrictions with the bindings. And the same >>> thing happens; the solution for #2 also solves #3. >>> >>> So how do you refer to a mux-controller from where it's needed? My >>> first proposal used a dt phandle, for the second round I put them in >>> the parent
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 2016-11-27 13:00, Jonathan Cameron wrote: > On 23/11/16 11:47, Peter Rosin wrote: >> On 2016-11-22 21:58, Lars-Peter Clausen wrote: >>> On 11/21/2016 02:17 PM, Peter Rosin wrote: >>> [...] I have a piece of hardware that is using the same 3 GPIO pins to control four 8-way muxes. Three of them control ADC lines to an ADS1015 chip with an iio driver, and the last one controls the SDA line of an i2c bus. We have some deployed code to handle this, but you do not want to see it or ever hear about it. I'm not sure why I even mention it. Anyway, the situation has nagged me to no end for quite some time. So, after first getting more intimate with the i2c muxing code and later discovering the drivers/iio/inkern.c file and writing a couple of drivers making use of it, I came up with what I think is an acceptable solution; add a generic mux controller driver (and subsystem) that is shared between all instances, and combine that with an iio mux driver and a new generic i2c mux driver. The new i2c mux I called "simple" since it is only hooking the i2c muxing and the new mux controller (much like the alsa simple card driver does for ASoC). >>> >>> While abstracting this properly is all nice and good and the way it should >>> be done, but it also adds a lot of complexity and the devicetree adds a lot >>> of restrictions on what can actually be represented. >> >> This is a characterization without any specifics. But is the >> characterization true? You have two complaints, complexity >> and restrictions with bindings. >> >>> There is a certain point where the fabric on a PCB becomes so complex that >>> it deserves to be a device on its own (like the audio fabric drivers). >>> Especially when the hardware is built with a certain application in mind and >>> the driver is supposed to impose policy which reflects this application. The >>> latter can often not properly be described with the primitives the >>> devicetree can offer. >>> >>> And I think your setup is very borderline what can be done in a declarative >>> way only and it adds a lot of complexity over a more imperative solution in >>> form of a driver. I think it is worth investigating about having a driver >>> that is specific to your fabric and handles the interdependencies of the >>> discrete components. >> >> So, there are three "new" concepts: >> >> 1. Sticking a mux in front of an AD-converter. That's not all that >> novel, nor complex. Quite the opposite, I'd say. In fact, I find it >> a bit amazing that there is no in-kernel support for it. > As ever first person who needs it and has the skills to write it gets to do > it ;) > Congratulations Peter ;) >> >> 2. Reusing the same GPIO-pins to drive different muxes. There are >> obviously chips that work this way (as Jonathan pointed out) and >> these will at some point get used in Linux devices. I guess they >> already are used, but that people handle them in userspace. Or >> something? If this is complex, which I question, it will still need >> support at some point. At least that's what I believe. >> >> 3. Using the same GPIO pins to mux things handled by different >> subsystems. Right, this is a bit crazy, and I'd rather not have this >> requirement, but this HW is what it is so I'll need to handle it in >> some way. It is also what stops me from falling back to a userspace >> solution, which is probably connected to why #1 and #2 is not supported >> by the kernel; everybody probably does muxing in userspace. Which is >> not necessarily a good idea, nor how it's supposed to be done... >> >> So, the only thing that's out of the ordinary (as I see it), is #3. >> The question that then needs an answer is how the in-kernel solution >> for #1 and #2 would look if we do not consider #3. >> >> And I claim that the desired solution to #1 and #2 is pretty close >> to my proposal. >> >> A. You do not want mux-controller drivers in every subsystem that >> needs them. > Agreed. >> >> B. You do not want every mux-consumer to know the specifics of how to >> operate every kind of mux; there are muxes that are not controlled >> with GPIO pins... >> >> C. When you implement muxing in a subsystem, there will in some cases >> be a need to handle parallel muxing, where there is a need to share >> mux-controllers. >> >> It just feels right to separate out the mux-controller and refer to >> it from where a mux is needed. It solves #1 and #2. And, of course, >> as a bonus #3 is also solved. But my bias is obvious. >> >> And that leads us to the restrictions with the bindings. And the same >> thing happens; the solution for #2 also solves #3. >> >> So how do you refer to a mux-controller from where it's needed? My >> first proposal used a dt phandle, for the second round I put them in >> the parent node. It would be super if it was possible for the mux- >> consumer to create the mux-controller device from the same dt >> node that is already
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 2016-11-27 13:00, Jonathan Cameron wrote: > On 23/11/16 11:47, Peter Rosin wrote: >> On 2016-11-22 21:58, Lars-Peter Clausen wrote: >>> On 11/21/2016 02:17 PM, Peter Rosin wrote: >>> [...] I have a piece of hardware that is using the same 3 GPIO pins to control four 8-way muxes. Three of them control ADC lines to an ADS1015 chip with an iio driver, and the last one controls the SDA line of an i2c bus. We have some deployed code to handle this, but you do not want to see it or ever hear about it. I'm not sure why I even mention it. Anyway, the situation has nagged me to no end for quite some time. So, after first getting more intimate with the i2c muxing code and later discovering the drivers/iio/inkern.c file and writing a couple of drivers making use of it, I came up with what I think is an acceptable solution; add a generic mux controller driver (and subsystem) that is shared between all instances, and combine that with an iio mux driver and a new generic i2c mux driver. The new i2c mux I called "simple" since it is only hooking the i2c muxing and the new mux controller (much like the alsa simple card driver does for ASoC). >>> >>> While abstracting this properly is all nice and good and the way it should >>> be done, but it also adds a lot of complexity and the devicetree adds a lot >>> of restrictions on what can actually be represented. >> >> This is a characterization without any specifics. But is the >> characterization true? You have two complaints, complexity >> and restrictions with bindings. >> >>> There is a certain point where the fabric on a PCB becomes so complex that >>> it deserves to be a device on its own (like the audio fabric drivers). >>> Especially when the hardware is built with a certain application in mind and >>> the driver is supposed to impose policy which reflects this application. The >>> latter can often not properly be described with the primitives the >>> devicetree can offer. >>> >>> And I think your setup is very borderline what can be done in a declarative >>> way only and it adds a lot of complexity over a more imperative solution in >>> form of a driver. I think it is worth investigating about having a driver >>> that is specific to your fabric and handles the interdependencies of the >>> discrete components. >> >> So, there are three "new" concepts: >> >> 1. Sticking a mux in front of an AD-converter. That's not all that >> novel, nor complex. Quite the opposite, I'd say. In fact, I find it >> a bit amazing that there is no in-kernel support for it. > As ever first person who needs it and has the skills to write it gets to do > it ;) > Congratulations Peter ;) >> >> 2. Reusing the same GPIO-pins to drive different muxes. There are >> obviously chips that work this way (as Jonathan pointed out) and >> these will at some point get used in Linux devices. I guess they >> already are used, but that people handle them in userspace. Or >> something? If this is complex, which I question, it will still need >> support at some point. At least that's what I believe. >> >> 3. Using the same GPIO pins to mux things handled by different >> subsystems. Right, this is a bit crazy, and I'd rather not have this >> requirement, but this HW is what it is so I'll need to handle it in >> some way. It is also what stops me from falling back to a userspace >> solution, which is probably connected to why #1 and #2 is not supported >> by the kernel; everybody probably does muxing in userspace. Which is >> not necessarily a good idea, nor how it's supposed to be done... >> >> So, the only thing that's out of the ordinary (as I see it), is #3. >> The question that then needs an answer is how the in-kernel solution >> for #1 and #2 would look if we do not consider #3. >> >> And I claim that the desired solution to #1 and #2 is pretty close >> to my proposal. >> >> A. You do not want mux-controller drivers in every subsystem that >> needs them. > Agreed. >> >> B. You do not want every mux-consumer to know the specifics of how to >> operate every kind of mux; there are muxes that are not controlled >> with GPIO pins... >> >> C. When you implement muxing in a subsystem, there will in some cases >> be a need to handle parallel muxing, where there is a need to share >> mux-controllers. >> >> It just feels right to separate out the mux-controller and refer to >> it from where a mux is needed. It solves #1 and #2. And, of course, >> as a bonus #3 is also solved. But my bias is obvious. >> >> And that leads us to the restrictions with the bindings. And the same >> thing happens; the solution for #2 also solves #3. >> >> So how do you refer to a mux-controller from where it's needed? My >> first proposal used a dt phandle, for the second round I put them in >> the parent node. It would be super if it was possible for the mux- >> consumer to create the mux-controller device from the same dt >> node that is already
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 23/11/16 11:47, Peter Rosin wrote: > On 2016-11-22 21:58, Lars-Peter Clausen wrote: >> On 11/21/2016 02:17 PM, Peter Rosin wrote: >> [...] >>> I have a piece of hardware that is using the same 3 GPIO pins >>> to control four 8-way muxes. Three of them control ADC lines >>> to an ADS1015 chip with an iio driver, and the last one >>> controls the SDA line of an i2c bus. We have some deployed >>> code to handle this, but you do not want to see it or ever >>> hear about it. I'm not sure why I even mention it. Anyway, >>> the situation has nagged me to no end for quite some time. >>> >>> So, after first getting more intimate with the i2c muxing code >>> and later discovering the drivers/iio/inkern.c file and >>> writing a couple of drivers making use of it, I came up with >>> what I think is an acceptable solution; add a generic mux >>> controller driver (and subsystem) that is shared between all >>> instances, and combine that with an iio mux driver and a new >>> generic i2c mux driver. The new i2c mux I called "simple" >>> since it is only hooking the i2c muxing and the new mux >>> controller (much like the alsa simple card driver does for ASoC). >> >> While abstracting this properly is all nice and good and the way it should >> be done, but it also adds a lot of complexity and the devicetree adds a lot >> of restrictions on what can actually be represented. > > This is a characterization without any specifics. But is the > characterization true? You have two complaints, complexity > and restrictions with bindings. > >> There is a certain point where the fabric on a PCB becomes so complex that >> it deserves to be a device on its own (like the audio fabric drivers). >> Especially when the hardware is built with a certain application in mind and >> the driver is supposed to impose policy which reflects this application. The >> latter can often not properly be described with the primitives the >> devicetree can offer. >> >> And I think your setup is very borderline what can be done in a declarative >> way only and it adds a lot of complexity over a more imperative solution in >> form of a driver. I think it is worth investigating about having a driver >> that is specific to your fabric and handles the interdependencies of the >> discrete components. > > So, there are three "new" concepts: > > 1. Sticking a mux in front of an AD-converter. That's not all that > novel, nor complex. Quite the opposite, I'd say. In fact, I find it > a bit amazing that there is no in-kernel support for it. As ever first person who needs it and has the skills to write it gets to do it ;) Congratulations Peter ;) > > 2. Reusing the same GPIO-pins to drive different muxes. There are > obviously chips that work this way (as Jonathan pointed out) and > these will at some point get used in Linux devices. I guess they > already are used, but that people handle them in userspace. Or > something? If this is complex, which I question, it will still need > support at some point. At least that's what I believe. > > 3. Using the same GPIO pins to mux things handled by different > subsystems. Right, this is a bit crazy, and I'd rather not have this > requirement, but this HW is what it is so I'll need to handle it in > some way. It is also what stops me from falling back to a userspace > solution, which is probably connected to why #1 and #2 is not supported > by the kernel; everybody probably does muxing in userspace. Which is > not necessarily a good idea, nor how it's supposed to be done... > > So, the only thing that's out of the ordinary (as I see it), is #3. > The question that then needs an answer is how the in-kernel solution > for #1 and #2 would look if we do not consider #3. > > And I claim that the desired solution to #1 and #2 is pretty close > to my proposal. > > A. You do not want mux-controller drivers in every subsystem that > needs them. Agreed. > > B. You do not want every mux-consumer to know the specifics of how to > operate every kind of mux; there are muxes that are not controlled > with GPIO pins... > > C. When you implement muxing in a subsystem, there will in some cases > be a need to handle parallel muxing, where there is a need to share > mux-controllers. > > It just feels right to separate out the mux-controller and refer to > it from where a mux is needed. It solves #1 and #2. And, of course, > as a bonus #3 is also solved. But my bias is obvious. > > And that leads us to the restrictions with the bindings. And the same > thing happens; the solution for #2 also solves #3. > > So how do you refer to a mux-controller from where it's needed? My > first proposal used a dt phandle, for the second round I put them in > the parent node. It would be super if it was possible for the mux- > consumer to create the mux-controller device from the same dt > node that is already bound to the mux-consumer. The problem is that > the mux-consumer should not hard-code which mux-controller device it > should create.
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 23/11/16 11:47, Peter Rosin wrote: > On 2016-11-22 21:58, Lars-Peter Clausen wrote: >> On 11/21/2016 02:17 PM, Peter Rosin wrote: >> [...] >>> I have a piece of hardware that is using the same 3 GPIO pins >>> to control four 8-way muxes. Three of them control ADC lines >>> to an ADS1015 chip with an iio driver, and the last one >>> controls the SDA line of an i2c bus. We have some deployed >>> code to handle this, but you do not want to see it or ever >>> hear about it. I'm not sure why I even mention it. Anyway, >>> the situation has nagged me to no end for quite some time. >>> >>> So, after first getting more intimate with the i2c muxing code >>> and later discovering the drivers/iio/inkern.c file and >>> writing a couple of drivers making use of it, I came up with >>> what I think is an acceptable solution; add a generic mux >>> controller driver (and subsystem) that is shared between all >>> instances, and combine that with an iio mux driver and a new >>> generic i2c mux driver. The new i2c mux I called "simple" >>> since it is only hooking the i2c muxing and the new mux >>> controller (much like the alsa simple card driver does for ASoC). >> >> While abstracting this properly is all nice and good and the way it should >> be done, but it also adds a lot of complexity and the devicetree adds a lot >> of restrictions on what can actually be represented. > > This is a characterization without any specifics. But is the > characterization true? You have two complaints, complexity > and restrictions with bindings. > >> There is a certain point where the fabric on a PCB becomes so complex that >> it deserves to be a device on its own (like the audio fabric drivers). >> Especially when the hardware is built with a certain application in mind and >> the driver is supposed to impose policy which reflects this application. The >> latter can often not properly be described with the primitives the >> devicetree can offer. >> >> And I think your setup is very borderline what can be done in a declarative >> way only and it adds a lot of complexity over a more imperative solution in >> form of a driver. I think it is worth investigating about having a driver >> that is specific to your fabric and handles the interdependencies of the >> discrete components. > > So, there are three "new" concepts: > > 1. Sticking a mux in front of an AD-converter. That's not all that > novel, nor complex. Quite the opposite, I'd say. In fact, I find it > a bit amazing that there is no in-kernel support for it. As ever first person who needs it and has the skills to write it gets to do it ;) Congratulations Peter ;) > > 2. Reusing the same GPIO-pins to drive different muxes. There are > obviously chips that work this way (as Jonathan pointed out) and > these will at some point get used in Linux devices. I guess they > already are used, but that people handle them in userspace. Or > something? If this is complex, which I question, it will still need > support at some point. At least that's what I believe. > > 3. Using the same GPIO pins to mux things handled by different > subsystems. Right, this is a bit crazy, and I'd rather not have this > requirement, but this HW is what it is so I'll need to handle it in > some way. It is also what stops me from falling back to a userspace > solution, which is probably connected to why #1 and #2 is not supported > by the kernel; everybody probably does muxing in userspace. Which is > not necessarily a good idea, nor how it's supposed to be done... > > So, the only thing that's out of the ordinary (as I see it), is #3. > The question that then needs an answer is how the in-kernel solution > for #1 and #2 would look if we do not consider #3. > > And I claim that the desired solution to #1 and #2 is pretty close > to my proposal. > > A. You do not want mux-controller drivers in every subsystem that > needs them. Agreed. > > B. You do not want every mux-consumer to know the specifics of how to > operate every kind of mux; there are muxes that are not controlled > with GPIO pins... > > C. When you implement muxing in a subsystem, there will in some cases > be a need to handle parallel muxing, where there is a need to share > mux-controllers. > > It just feels right to separate out the mux-controller and refer to > it from where a mux is needed. It solves #1 and #2. And, of course, > as a bonus #3 is also solved. But my bias is obvious. > > And that leads us to the restrictions with the bindings. And the same > thing happens; the solution for #2 also solves #3. > > So how do you refer to a mux-controller from where it's needed? My > first proposal used a dt phandle, for the second round I put them in > the parent node. It would be super if it was possible for the mux- > consumer to create the mux-controller device from the same dt > node that is already bound to the mux-consumer. The problem is that > the mux-consumer should not hard-code which mux-controller device it > should create.
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 2016-11-22 21:58, Lars-Peter Clausen wrote: > On 11/21/2016 02:17 PM, Peter Rosin wrote: > [...] >> I have a piece of hardware that is using the same 3 GPIO pins >> to control four 8-way muxes. Three of them control ADC lines >> to an ADS1015 chip with an iio driver, and the last one >> controls the SDA line of an i2c bus. We have some deployed >> code to handle this, but you do not want to see it or ever >> hear about it. I'm not sure why I even mention it. Anyway, >> the situation has nagged me to no end for quite some time. >> >> So, after first getting more intimate with the i2c muxing code >> and later discovering the drivers/iio/inkern.c file and >> writing a couple of drivers making use of it, I came up with >> what I think is an acceptable solution; add a generic mux >> controller driver (and subsystem) that is shared between all >> instances, and combine that with an iio mux driver and a new >> generic i2c mux driver. The new i2c mux I called "simple" >> since it is only hooking the i2c muxing and the new mux >> controller (much like the alsa simple card driver does for ASoC). > > While abstracting this properly is all nice and good and the way it should > be done, but it also adds a lot of complexity and the devicetree adds a lot > of restrictions on what can actually be represented. This is a characterization without any specifics. But is the characterization true? You have two complaints, complexity and restrictions with bindings. > There is a certain point where the fabric on a PCB becomes so complex that > it deserves to be a device on its own (like the audio fabric drivers). > Especially when the hardware is built with a certain application in mind and > the driver is supposed to impose policy which reflects this application. The > latter can often not properly be described with the primitives the > devicetree can offer. > > And I think your setup is very borderline what can be done in a declarative > way only and it adds a lot of complexity over a more imperative solution in > form of a driver. I think it is worth investigating about having a driver > that is specific to your fabric and handles the interdependencies of the > discrete components. So, there are three "new" concepts: 1. Sticking a mux in front of an AD-converter. That's not all that novel, nor complex. Quite the opposite, I'd say. In fact, I find it a bit amazing that there is no in-kernel support for it. 2. Reusing the same GPIO-pins to drive different muxes. There are obviously chips that work this way (as Jonathan pointed out) and these will at some point get used in Linux devices. I guess they already are used, but that people handle them in userspace. Or something? If this is complex, which I question, it will still need support at some point. At least that's what I believe. 3. Using the same GPIO pins to mux things handled by different subsystems. Right, this is a bit crazy, and I'd rather not have this requirement, but this HW is what it is so I'll need to handle it in some way. It is also what stops me from falling back to a userspace solution, which is probably connected to why #1 and #2 is not supported by the kernel; everybody probably does muxing in userspace. Which is not necessarily a good idea, nor how it's supposed to be done... So, the only thing that's out of the ordinary (as I see it), is #3. The question that then needs an answer is how the in-kernel solution for #1 and #2 would look if we do not consider #3. And I claim that the desired solution to #1 and #2 is pretty close to my proposal. A. You do not want mux-controller drivers in every subsystem that needs them. B. You do not want every mux-consumer to know the specifics of how to operate every kind of mux; there are muxes that are not controlled with GPIO pins... C. When you implement muxing in a subsystem, there will in some cases be a need to handle parallel muxing, where there is a need to share mux-controllers. It just feels right to separate out the mux-controller and refer to it from where a mux is needed. It solves #1 and #2. And, of course, as a bonus #3 is also solved. But my bias is obvious. And that leads us to the restrictions with the bindings. And the same thing happens; the solution for #2 also solves #3. So how do you refer to a mux-controller from where it's needed? My first proposal used a dt phandle, for the second round I put them in the parent node. It would be super if it was possible for the mux- consumer to create the mux-controller device from the same dt node that is already bound to the mux-consumer. The problem is that the mux-consumer should not hard-code which mux-controller device it should create. The best I can think of is some kind of 'mux-compatible' attribute, that works like the standard 'compatible' attribute. That would simplify the bindings for the normal case (#1) where the mux- controller isn't shared (#2 and #3). Maybe it's possible to fix this issue somehow? I simply don't know? Cheers,
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 2016-11-22 21:58, Lars-Peter Clausen wrote: > On 11/21/2016 02:17 PM, Peter Rosin wrote: > [...] >> I have a piece of hardware that is using the same 3 GPIO pins >> to control four 8-way muxes. Three of them control ADC lines >> to an ADS1015 chip with an iio driver, and the last one >> controls the SDA line of an i2c bus. We have some deployed >> code to handle this, but you do not want to see it or ever >> hear about it. I'm not sure why I even mention it. Anyway, >> the situation has nagged me to no end for quite some time. >> >> So, after first getting more intimate with the i2c muxing code >> and later discovering the drivers/iio/inkern.c file and >> writing a couple of drivers making use of it, I came up with >> what I think is an acceptable solution; add a generic mux >> controller driver (and subsystem) that is shared between all >> instances, and combine that with an iio mux driver and a new >> generic i2c mux driver. The new i2c mux I called "simple" >> since it is only hooking the i2c muxing and the new mux >> controller (much like the alsa simple card driver does for ASoC). > > While abstracting this properly is all nice and good and the way it should > be done, but it also adds a lot of complexity and the devicetree adds a lot > of restrictions on what can actually be represented. This is a characterization without any specifics. But is the characterization true? You have two complaints, complexity and restrictions with bindings. > There is a certain point where the fabric on a PCB becomes so complex that > it deserves to be a device on its own (like the audio fabric drivers). > Especially when the hardware is built with a certain application in mind and > the driver is supposed to impose policy which reflects this application. The > latter can often not properly be described with the primitives the > devicetree can offer. > > And I think your setup is very borderline what can be done in a declarative > way only and it adds a lot of complexity over a more imperative solution in > form of a driver. I think it is worth investigating about having a driver > that is specific to your fabric and handles the interdependencies of the > discrete components. So, there are three "new" concepts: 1. Sticking a mux in front of an AD-converter. That's not all that novel, nor complex. Quite the opposite, I'd say. In fact, I find it a bit amazing that there is no in-kernel support for it. 2. Reusing the same GPIO-pins to drive different muxes. There are obviously chips that work this way (as Jonathan pointed out) and these will at some point get used in Linux devices. I guess they already are used, but that people handle them in userspace. Or something? If this is complex, which I question, it will still need support at some point. At least that's what I believe. 3. Using the same GPIO pins to mux things handled by different subsystems. Right, this is a bit crazy, and I'd rather not have this requirement, but this HW is what it is so I'll need to handle it in some way. It is also what stops me from falling back to a userspace solution, which is probably connected to why #1 and #2 is not supported by the kernel; everybody probably does muxing in userspace. Which is not necessarily a good idea, nor how it's supposed to be done... So, the only thing that's out of the ordinary (as I see it), is #3. The question that then needs an answer is how the in-kernel solution for #1 and #2 would look if we do not consider #3. And I claim that the desired solution to #1 and #2 is pretty close to my proposal. A. You do not want mux-controller drivers in every subsystem that needs them. B. You do not want every mux-consumer to know the specifics of how to operate every kind of mux; there are muxes that are not controlled with GPIO pins... C. When you implement muxing in a subsystem, there will in some cases be a need to handle parallel muxing, where there is a need to share mux-controllers. It just feels right to separate out the mux-controller and refer to it from where a mux is needed. It solves #1 and #2. And, of course, as a bonus #3 is also solved. But my bias is obvious. And that leads us to the restrictions with the bindings. And the same thing happens; the solution for #2 also solves #3. So how do you refer to a mux-controller from where it's needed? My first proposal used a dt phandle, for the second round I put them in the parent node. It would be super if it was possible for the mux- consumer to create the mux-controller device from the same dt node that is already bound to the mux-consumer. The problem is that the mux-consumer should not hard-code which mux-controller device it should create. The best I can think of is some kind of 'mux-compatible' attribute, that works like the standard 'compatible' attribute. That would simplify the bindings for the normal case (#1) where the mux- controller isn't shared (#2 and #3). Maybe it's possible to fix this issue somehow? I simply don't know? Cheers,
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 11/21/2016 02:17 PM, Peter Rosin wrote: [...] > I have a piece of hardware that is using the same 3 GPIO pins > to control four 8-way muxes. Three of them control ADC lines > to an ADS1015 chip with an iio driver, and the last one > controls the SDA line of an i2c bus. We have some deployed > code to handle this, but you do not want to see it or ever > hear about it. I'm not sure why I even mention it. Anyway, > the situation has nagged me to no end for quite some time. > > So, after first getting more intimate with the i2c muxing code > and later discovering the drivers/iio/inkern.c file and > writing a couple of drivers making use of it, I came up with > what I think is an acceptable solution; add a generic mux > controller driver (and subsystem) that is shared between all > instances, and combine that with an iio mux driver and a new > generic i2c mux driver. The new i2c mux I called "simple" > since it is only hooking the i2c muxing and the new mux > controller (much like the alsa simple card driver does for ASoC). While abstracting this properly is all nice and good and the way it should be done, but it also adds a lot of complexity and the devicetree adds a lot of restrictions on what can actually be represented. There is a certain point where the fabric on a PCB becomes so complex that it deserves to be a device on its own (like the audio fabric drivers). Especially when the hardware is built with a certain application in mind and the driver is supposed to impose policy which reflects this application. The latter can often not properly be described with the primitives the devicetree can offer. And I think your setup is very borderline what can be done in a declarative way only and it adds a lot of complexity over a more imperative solution in form of a driver. I think it is worth investigating about having a driver that is specific to your fabric and handles the interdependencies of the discrete components.
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 11/21/2016 02:17 PM, Peter Rosin wrote: [...] > I have a piece of hardware that is using the same 3 GPIO pins > to control four 8-way muxes. Three of them control ADC lines > to an ADS1015 chip with an iio driver, and the last one > controls the SDA line of an i2c bus. We have some deployed > code to handle this, but you do not want to see it or ever > hear about it. I'm not sure why I even mention it. Anyway, > the situation has nagged me to no end for quite some time. > > So, after first getting more intimate with the i2c muxing code > and later discovering the drivers/iio/inkern.c file and > writing a couple of drivers making use of it, I came up with > what I think is an acceptable solution; add a generic mux > controller driver (and subsystem) that is shared between all > instances, and combine that with an iio mux driver and a new > generic i2c mux driver. The new i2c mux I called "simple" > since it is only hooking the i2c muxing and the new mux > controller (much like the alsa simple card driver does for ASoC). While abstracting this properly is all nice and good and the way it should be done, but it also adds a lot of complexity and the devicetree adds a lot of restrictions on what can actually be represented. There is a certain point where the fabric on a PCB becomes so complex that it deserves to be a device on its own (like the audio fabric drivers). Especially when the hardware is built with a certain application in mind and the driver is supposed to impose policy which reflects this application. The latter can often not properly be described with the primitives the devicetree can offer. And I think your setup is very borderline what can be done in a declarative way only and it adds a lot of complexity over a more imperative solution in form of a driver. I think it is worth investigating about having a driver that is specific to your fabric and handles the interdependencies of the discrete components.
[PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
Hi! The code depends on the _available work in iio which can be found in linux-next. v2 -> v3 changes - have the mux-controller in the parent node of any mux-controller consumer, to hopefully satisfy complaint from Rob about dt complexity. - improve commit message of the mux subsystem commit, making it more general, as requested by Jonathan. - remove priv member from struct mux_control and calculate it on the fly. /Jonathan. - make the function comments in mux-core.c kernel doc. /Jonathan - add devm_mux_control_* to Documentation/driver.model/devres.txt. /Jonathan - add common dt bindings for mux-controllers, refer to them from the mux-gpio bindings. - clarify how the gpio pins map to the mux state. - separate CONFIG_ variables for the mux core and the mux gpio driver. - improve Kconfig help texts. - make CONFIG_MUX_GPIO depend on CONFIG_GPIOLIB. - keep track of the number of mux states in the mux core. - since the iio channel number is used as mux state, it was possible to drop the state member from the mux_child struct. - cleanup dt bindings for i2c-mux-simple, it had some of copy-paste problems from ots origin (i2c-mux-gpio). - select the mux control subsystem in config for the i2c-mux-simple driver. - add entries to MAINTAINERS and my sign-off, I'm now satisfied and know nothing in this to be ashamed of. v1 -> v2 changes - fixup export of mux_control_put reported by kbuild - drop devicetree iio-ext-info property as noted by Lars-Peter, and replace the functionality by exposing all ext_info attributes of the parent channel for each of the muxed channels. A cache on top of that and each muxed channel gets its own view of the ext_info of the parent channel. - implement idle-state for muxes - clear out the cache on failure in order to force a mux update on the following use - cleanup the probe of i2c-mux-simple driver - fix a bug in the i2c-mux-simple driver, where failure in the selection of the mux caused a deadlock when the mux was later unconditionally deselected. I have a piece of hardware that is using the same 3 GPIO pins to control four 8-way muxes. Three of them control ADC lines to an ADS1015 chip with an iio driver, and the last one controls the SDA line of an i2c bus. We have some deployed code to handle this, but you do not want to see it or ever hear about it. I'm not sure why I even mention it. Anyway, the situation has nagged me to no end for quite some time. So, after first getting more intimate with the i2c muxing code and later discovering the drivers/iio/inkern.c file and writing a couple of drivers making use of it, I came up with what I think is an acceptable solution; add a generic mux controller driver (and subsystem) that is shared between all instances, and combine that with an iio mux driver and a new generic i2c mux driver. The new i2c mux I called "simple" since it is only hooking the i2c muxing and the new mux controller (much like the alsa simple card driver does for ASoC). My initial (private) version didn't add "mux" as a new bus, but I couldn't get decent type-checking and nice devicetree integration with that. It does however feel a bit rich to add a new bus for something as small as mux controllers? One thing that I would like to do, but don't see a solution for, is to move the mux control code that is present in various drivers in drivers/i2c/muxes to this new minimalistic muxing subsystem, thus converting all present i2c muxes (but perhaps not gates and arbitrators) to be i2c-mux-simple muxes. I'm using an rwsem to lock a mux, but that isn't really a perfect fit. Is there a better locking primitive that I don't know about that fits better? I had a mutex at one point, but that didn't allow any concurrent accesses at all. At least the rwsem allows concurrent access as long as all users agree on the mux state, but I suspect that the rwsem will degrade to the mutex situation pretty quickly if there is any contention. Also, the "mux" name feels a bit ambitious, there are many muxes in the world, and this tiny bit of code is probably not good enough to be a nice fit for all... Cheers, Peter Peter Rosin (7): dt-bindings: document devicetree bindings for mux-controllers and mux-gpio misc: minimal mux subsystem and gpio-based mux controller iio: inkern: api for manipulating ext_info of iio channels dt-bindings: iio: iio-mux: document iio-mux bindings iio: multiplexer: new iio category and iio-mux driver dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings i2c: i2c-mux-simple: new driver .../devicetree/bindings/i2c/i2c-mux-simple.txt | 76 .../bindings/iio/multiplexer/iio-mux.txt | 47 +++ .../devicetree/bindings/misc/mux-controller.txt| 76 .../devicetree/bindings/misc/mux-gpio.txt | 78 Documentation/driver-model/devres.txt | 6 +- MAINTAINERS| 14 + drivers/i2c/muxes/Kconfig |
[PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
Hi! The code depends on the _available work in iio which can be found in linux-next. v2 -> v3 changes - have the mux-controller in the parent node of any mux-controller consumer, to hopefully satisfy complaint from Rob about dt complexity. - improve commit message of the mux subsystem commit, making it more general, as requested by Jonathan. - remove priv member from struct mux_control and calculate it on the fly. /Jonathan. - make the function comments in mux-core.c kernel doc. /Jonathan - add devm_mux_control_* to Documentation/driver.model/devres.txt. /Jonathan - add common dt bindings for mux-controllers, refer to them from the mux-gpio bindings. - clarify how the gpio pins map to the mux state. - separate CONFIG_ variables for the mux core and the mux gpio driver. - improve Kconfig help texts. - make CONFIG_MUX_GPIO depend on CONFIG_GPIOLIB. - keep track of the number of mux states in the mux core. - since the iio channel number is used as mux state, it was possible to drop the state member from the mux_child struct. - cleanup dt bindings for i2c-mux-simple, it had some of copy-paste problems from ots origin (i2c-mux-gpio). - select the mux control subsystem in config for the i2c-mux-simple driver. - add entries to MAINTAINERS and my sign-off, I'm now satisfied and know nothing in this to be ashamed of. v1 -> v2 changes - fixup export of mux_control_put reported by kbuild - drop devicetree iio-ext-info property as noted by Lars-Peter, and replace the functionality by exposing all ext_info attributes of the parent channel for each of the muxed channels. A cache on top of that and each muxed channel gets its own view of the ext_info of the parent channel. - implement idle-state for muxes - clear out the cache on failure in order to force a mux update on the following use - cleanup the probe of i2c-mux-simple driver - fix a bug in the i2c-mux-simple driver, where failure in the selection of the mux caused a deadlock when the mux was later unconditionally deselected. I have a piece of hardware that is using the same 3 GPIO pins to control four 8-way muxes. Three of them control ADC lines to an ADS1015 chip with an iio driver, and the last one controls the SDA line of an i2c bus. We have some deployed code to handle this, but you do not want to see it or ever hear about it. I'm not sure why I even mention it. Anyway, the situation has nagged me to no end for quite some time. So, after first getting more intimate with the i2c muxing code and later discovering the drivers/iio/inkern.c file and writing a couple of drivers making use of it, I came up with what I think is an acceptable solution; add a generic mux controller driver (and subsystem) that is shared between all instances, and combine that with an iio mux driver and a new generic i2c mux driver. The new i2c mux I called "simple" since it is only hooking the i2c muxing and the new mux controller (much like the alsa simple card driver does for ASoC). My initial (private) version didn't add "mux" as a new bus, but I couldn't get decent type-checking and nice devicetree integration with that. It does however feel a bit rich to add a new bus for something as small as mux controllers? One thing that I would like to do, but don't see a solution for, is to move the mux control code that is present in various drivers in drivers/i2c/muxes to this new minimalistic muxing subsystem, thus converting all present i2c muxes (but perhaps not gates and arbitrators) to be i2c-mux-simple muxes. I'm using an rwsem to lock a mux, but that isn't really a perfect fit. Is there a better locking primitive that I don't know about that fits better? I had a mutex at one point, but that didn't allow any concurrent accesses at all. At least the rwsem allows concurrent access as long as all users agree on the mux state, but I suspect that the rwsem will degrade to the mutex situation pretty quickly if there is any contention. Also, the "mux" name feels a bit ambitious, there are many muxes in the world, and this tiny bit of code is probably not good enough to be a nice fit for all... Cheers, Peter Peter Rosin (7): dt-bindings: document devicetree bindings for mux-controllers and mux-gpio misc: minimal mux subsystem and gpio-based mux controller iio: inkern: api for manipulating ext_info of iio channels dt-bindings: iio: iio-mux: document iio-mux bindings iio: multiplexer: new iio category and iio-mux driver dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings i2c: i2c-mux-simple: new driver .../devicetree/bindings/i2c/i2c-mux-simple.txt | 76 .../bindings/iio/multiplexer/iio-mux.txt | 47 +++ .../devicetree/bindings/misc/mux-controller.txt| 76 .../devicetree/bindings/misc/mux-gpio.txt | 78 Documentation/driver-model/devres.txt | 6 +- MAINTAINERS| 14 + drivers/i2c/muxes/Kconfig |
