On Wednesday 23 November 2011 02:02:25 Igor Grinberg wrote: > On 11/22/11 23:07, Mike Frysinger wrote: > > On Tuesday 22 November 2011 03:15:47 Stefano Babic wrote: > >> On 21/11/2011 22:22, Mike Frysinger wrote: > >>>> Of course ... considering there's always one correct setting for > >>>> the pin to be in GPIO mode, which I suspect might not be > >>>> completely true today anymore. > >>> > >>> i find it hard to envision a pinmux system where individual pins > >>> would have different pinmux configurations to get it into GPIO > >>> mode. probably be saner to have gpio_request() do the right thing > >>> and wait for someone to come forward with the unusual setup -- > >>> worry about it then. > >> > >> In fact it would be nicer if gpio_request() takes care of the pinmux, > >> in the way I can see on the davinci SOCs. However, on the IMXs a > >> single GPIO can be connected (not at the same time, of course) to > >> different PADs, depending on a general setup (GPR register) or if the > >> daisy chain in the multiplexer is activated. > > > > if it's different physical pins, then perhaps it should be different GPIO > > numbers ? > > I think, currently, you are right, but if we look in some other > AF (Alternate Functions) (not GPIO), same AF can be available on > different physical pins. This means that in theory, same GPIO number > can also be connected to different physical pins. > I think it should be board controllable instead of gpiolib hard coded, > or of course pinmux controlled (which is board controllable).
i understand AF for peripheral pins, but i'm not seeing the same-gpio-number- for-different-pins part. > >> The second point I will arise is that, mainly due to the different > >> internal layout but also for historical reasons, the setup and the > >> provided function for the multiplexer is very different among the SOCs. > >> > >> Only mx35 and mx5 expone the same interface (mxc_request_iomux), while > >> mx31/mx25/mx27/mx28 have its own. Because we use and we want to use > >> the GPIO framework, the gpio driver, common to all IMX SOCs, should be > >> able to set up the multiplexer independently from the SOC type, that > >> means we should have the same interface for the multiplexer, and we > >> have not (yet ?). > > > > this is shaking out in Linux with the pinmux framework, so probably best > > to grit our teeth until that's done and then adopt what they implement. > > This is probably the best way and correct me if I'm wrong, > this means stick with board control over the pinmux > instead of gpiolib. *shrug* whatever the maintainer of the gpio/drivers want to do. as long as it's not common code, i won't worry about it for now. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot