[U-Boot] [PATCH] mx5 iomux: Fix GPIO with SION

["Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>]

Hi Stefano,

> On 17/08/2012 18:21, Beno?t Th?baudeau wrote:
> > Hi Stefano,
> > 
> 
> Hi Beno?t,
> 
> >>
> >> So why should we use both SION and GPIO ?
> > 
> > No. See "A.3.2 SW Loopback through SION Bit" and "Figure A-3. IOMUX
> > Cell Block
> > Diagram" in the i.MX51 RM.
> > 
> > Whether SION is set or not, the selected IOMUX function will drive
> > the pin.
> 
> And this is clear..
> 
> > 
> > If SION is cleared, the input from the pin will be either disabled
> > or go to the
> > selected IOMUX function depending on the activation of the input by
> > this
> > function.
> 
> and also thi point is clear.
> 
> > 
> > If SION is set, the input from the pin is always enabled and goes
> > to all IOMUX
> > alternate functions at once (if their input connection to this pin
> > is activated
> > through the daisy chain).
> 
> but I am asking myself why I should do this, that is the function
> drive
> the pin, using the input as source for another funtion.
> 
> > 
> > So SION does not invalidate the function bit-field.
> > 
> > Then, you could wonder what kind of real life use case could be
> > useful with both
> > SION and GPIO set.
> 
> This is exactly the point !
> 
> > This could be used for instance as a workaround to an erratum
> > if an IOMUX function does not drive its output properly, but it
> > needs to read
> > back the pin status to work fine. Thus, the GPIO function output
> > could be used
> > to drive the pin, with SION set so that the flawed IOMUX function
> > can still
> > probe the pin and function properly internally. Note that it's only
> > a
> > theoretical example; I don't remember such an erratum.
> 
> I am really impressed about your attention reading the manuals, but
> we
> have the rule in u-boot that we add code / feature when we have a use
> case (the same is in kernel). At the moment, it is pure theory, and
> nobody will use it. We will reconsider this patch when its
> introduction
> will be required to fix a SOC bug, if any.

Sure, but this is neither new code nor a new feature. It is only a fix that
makes sure that the code won't break any potential use case in the future. This
is weird to keep a known issue in the code until someone gets in trouble because
of it and hence wastes time.

But anyway, this file will probably disappear in the near future because of the
new pin definitions, so that won't make a big difference.

Best regards,
Beno?t