[[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions

[Tony Lindgren]

* Luciano Coelho <coelho at ti.com> [130118 11:12]:
> On Fri, 2013-01-18 at 09:36 -0800, Tony Lindgren wrote:
> > * Luciano Coelho <coelho at ti.com> [130118 01:03]:
> > > On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
> > > > * Luciano Coelho <coelho at ti.com> [130117 10:04]:
> > > > > But this patch is pretty small and simple, so why not include it to at
> > > > > least fix the breakage in 3.7 and 3.8? Whether you take it or not now
> > > > > won't make any difference in the 5k LOC in these kernel versions.
> > > > 
> > > > Well we are planning to drop the non-DT support for omap4 as soon as it's
> > > > usable with DT. For omap4 we are only carrying SDP and panda support to
> > > > make this transition easier. The only bindings missing AFAIK are wl12xx and
> > > > USB.
> > > 
> > > In my view this is a regression and it should be fixed with as simple a
> > > patch as possible.  The alternative to my solution is to revert the
> > > patch that removed the enable/disable from the ti-st driver *and* fix
> > > u-boot, because if it doesn't mux the UART2 pins properly (and it
> > > doesn't) the shared transport still won't work.
> > 
> > Fixing the muxing here makes sense naturally as we cannot do that in the driver
> > until we've flipped things over to use DT.
> > 
> > But I don't think we should fix the driver regression by adding more platform
> > callbacks as we are getting rid of them anyways.
> 
> Okay, you're right.  We need at least to pass the GPIO number from the
> board file to the driver so that it knows what to switch.  This is also
> something that it will need from DT in the future.

Yes I agree, the GPIO number needs to be passed in the fix. 
 
> > > > If we add this, then it implies we're somehow supporting it, which is not
> > > > the way to go IMHO as we need to get rid of these platform callbacks instead.
> > > 
> > > It's a regression fix, not a new feature.  I also think these callbacks
> > > are silly, but it's the quickest solution I found for 3.7 and 3.8.
> > 
> > Right, so how about let's fix the regression in the driver, and add the
> > muxing to platform init code? 
> 
> Agreed.  I'll cook up a patch to revert the changes in eccf2979 (it
> doesn't revert cleanly) and change the panda board file to do the muxing
> and set the gpio number in the pdata for the driver to use.

OK thanks. 
  
> > > > What's your estimate of having minimal wl12xx WLAN DT binding available?
> > > 
> > > To tell you the truth, I haven't even started looking into DT for wl12xx
> > > myself.  So I have no idea when it will be ready.  Benoit has been
> > > looking into it, but I don't know how far he is.
> > 
> > If it's going to take long we should just init the platform data for
> > it temporarily even in the DT boot case until the binding is available.
> 
> I'll start looking into this now.  It's not going to be that simple, I'm
> sure, but I need to look more into DT in general to be able to say
> something more accurate.  I'll let you know as soon as I know more. :)

OK thanks!

Tony