On Mon, Feb 13, 2012 at 02:18:09PM -0700, Grant Likely wrote: > On Mon, Feb 13, 2012 at 11:59:47AM +0530, Laxman Dewangan wrote: > > Adding details of open drain configuration of the gpio so that > > client can set the pin as open drain at the time of gpio request. > Implicitly, the gpio api already supports open-drain and several drivers > make use of it. Instead of being a separate flag; users who need open > drain will set the pin to input. For example, see the i2c-gpio driver. > I'm not convinced this is needed; but my opinion could be swayed. The actual idea is to provide support for doing the switch to input to drivers that just want to set a logic level and don't (at their level) care one way or another if it's a CMOS or open drain output but instead leaves it up to board configuration which mode is used. Laxman posted a patch for doing this to a regulator driver but looking at it the code for emulating open drain while also maintaining support for regular CMOS is fiddly enough that it seemed like it should be factored out of the individual drivers. > Also, you should include a patch to make i2c-gpio.c use this new > functionality as a proof-of-concept. You may not be able to test it, > but it will make it a lot easier to justify merging by showing how it > cleans up a gpio user. The regulator patch is one example - I think things that could be CMOS are probably more interesting here than drivers that always want open drain as they have more of a complexity hit from needing to decide if they'll use the emulation or not. We could also at some later point add support for hardware which can implement open drain mode itself though I'm not sure if there's enough problem with emulating to make it worth the effort.
Attachment:
signature.asc
Description: Digital signature
