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

[Luciano Coelho]

On Thu, 2013-01-17 at 12:09 +0200, Felipe Balbi wrote:
> On Thu, Jan 17, 2013 at 12:05:10PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Jan 17, 2013 at 10:55:14AM +0100, Peter Ujfalusi wrote:
> > > On 01/17/2013 10:34 AM, Felipe Balbi wrote:
> > > >> I just wonder how this is going to work with DT... You are not going to have
> > > >> the ability to use callback in this form.
> > > >> I think the GPIO handling should be done in the driver itself rather than in
> > > >> the board file.
> > > > 
> > > > that can (should ?) be moved to ti-st eventually. In fact I don't know
> > > > why it was removed in the first place, we would need Pavan to help us
> > > > with that query.
> > > 
> > > Yes, this is a good question. I don't know what is the spacial thing platforms
> > > need to do in the callback..
> 
> hah! looks like I found the reason:
> 
> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-44xx-54xx-connectivity.c;h=e4852b93e91b6daa8f85cca91a1e7fbcc778f45b;hb=594aedd9e7da0491523411f8999efd98297f4fe4#l177
> 
> IMHO:
> 
> a) removing gpio handling wasn't necessary, we could just check
> 	if gpio_is_valid(nshutdown_gpio)
> 
> b) that whole omap_serial_ext_uart_enable() looks really hacky. I'm sure
> 	we can come up with something better.
> 

This out-of-tree code doesn't explain why we need to do the
enable/disable in the board file.  We just need to do things a bit
differently in the driver.  I'll start cleaning all this stuff up for
-next pretty soon.

For now, ie. 3.7 (stable) and 3.8, do we agree in taking this patch so
that TI-ST at least works on Panda? Simply reverting the gpio removal
patch doesn't help, because we also need to handle the UART2 muxing
(which my patch does as well).

--
Cheers,
Luca.