From: Luciano Coelho <coelho@ti.com>
To: Tony Lindgren <tony@atomide.com>, "Cousson, Benoit" <b-cousson@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>, <balbi@ti.com>,
<linux-omap@vger.kernel.org>, <linux@arm.linux.org.uk>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
Date: Fri, 18 Jan 2013 10:58:53 +0200 [thread overview]
Message-ID: <1358499533.6252.80.camel@cumari.coelho.fi> (raw)
In-Reply-To: <20130117231608.GP14149@atomide.com>
On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
> * Luciano Coelho <coelho@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.
> 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.
> 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.
--
Luca.
WARNING: multiple messages have this Message-ID (diff)
From: Luciano Coelho <coelho@ti.com>
To: Tony Lindgren <tony@atomide.com>, "Cousson, Benoit" <b-cousson@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
balbi@ti.com, linux-omap@vger.kernel.org, linux@arm.linux.org.uk,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
Date: Fri, 18 Jan 2013 10:58:53 +0200 [thread overview]
Message-ID: <1358499533.6252.80.camel@cumari.coelho.fi> (raw)
In-Reply-To: <20130117231608.GP14149@atomide.com>
On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
> * Luciano Coelho <coelho@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.
> 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.
> 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.
--
Luca.
WARNING: multiple messages have this Message-ID (diff)
From: coelho@ti.com (Luciano Coelho)
To: linux-arm-kernel@lists.infradead.org
Subject: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
Date: Fri, 18 Jan 2013 10:58:53 +0200 [thread overview]
Message-ID: <1358499533.6252.80.camel@cumari.coelho.fi> (raw)
In-Reply-To: <20130117231608.GP14149@atomide.com>
On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
> * Luciano Coelho <coelho@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.
> 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.
> 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.
--
Luca.
next prev parent reply other threads:[~2013-01-18 8:59 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-16 21:45 [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions Luciano Coelho
2013-01-16 21:45 ` Luciano Coelho
2013-01-16 21:45 ` Luciano Coelho
2013-01-17 9:30 ` Peter Ujfalusi
2013-01-17 9:30 ` Peter Ujfalusi
2013-01-17 9:30 ` Peter Ujfalusi
2013-01-17 9:34 ` Felipe Balbi
2013-01-17 9:34 ` Felipe Balbi
2013-01-17 9:34 ` Felipe Balbi
2013-01-17 9:55 ` Peter Ujfalusi
2013-01-17 9:55 ` Peter Ujfalusi
2013-01-17 9:55 ` Peter Ujfalusi
2013-01-17 10:05 ` Felipe Balbi
2013-01-17 10:05 ` Felipe Balbi
2013-01-17 10:05 ` Felipe Balbi
2013-01-17 10:09 ` Felipe Balbi
2013-01-17 10:09 ` Felipe Balbi
2013-01-17 10:09 ` Felipe Balbi
2013-01-17 10:35 ` Luciano Coelho
2013-01-17 10:35 ` Luciano Coelho
2013-01-17 10:35 ` Luciano Coelho
2013-01-17 10:40 ` Peter Ujfalusi
2013-01-17 10:40 ` Peter Ujfalusi
2013-01-17 10:40 ` Peter Ujfalusi
2013-01-17 17:31 ` Tony Lindgren
2013-01-17 17:31 ` Tony Lindgren
2013-01-17 17:57 ` Luciano Coelho
2013-01-17 17:57 ` Luciano Coelho
2013-01-17 17:57 ` Luciano Coelho
2013-01-17 23:16 ` Tony Lindgren
2013-01-17 23:16 ` Tony Lindgren
2013-01-18 8:58 ` Luciano Coelho [this message]
2013-01-18 8:58 ` Luciano Coelho
2013-01-18 8:58 ` Luciano Coelho
2013-01-18 17:36 ` Tony Lindgren
2013-01-18 17:36 ` Tony Lindgren
2013-01-18 17:54 ` Felipe Balbi
2013-01-18 17:54 ` Felipe Balbi
2013-01-18 17:54 ` Felipe Balbi
2013-01-18 18:05 ` Tony Lindgren
2013-01-18 18:05 ` Tony Lindgren
2013-01-18 19:08 ` Luciano Coelho
2013-01-18 19:08 ` Luciano Coelho
2013-01-18 19:08 ` Luciano Coelho
2013-01-18 19:22 ` Tony Lindgren
2013-01-18 19:22 ` Tony Lindgren
2013-01-18 10:11 ` Peter Ujfalusi
2013-01-18 10:11 ` Peter Ujfalusi
2013-01-18 10:11 ` Peter Ujfalusi
2013-01-18 17:49 ` Tony Lindgren
2013-01-18 17:49 ` Tony Lindgren
2013-01-23 8:55 ` Peter Ujfalusi
2013-01-23 8:55 ` Peter Ujfalusi
2013-01-23 8:55 ` Peter Ujfalusi
2013-01-17 9:35 ` Luciano Coelho
2013-01-17 9:35 ` Luciano Coelho
2013-01-17 9:35 ` Luciano Coelho
2013-01-17 9:59 ` Peter Ujfalusi
2013-01-17 9:59 ` Peter Ujfalusi
2013-01-17 9:59 ` Peter Ujfalusi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1358499533.6252.80.camel@cumari.coelho.fi \
--to=coelho@ti.com \
--cc=b-cousson@ti.com \
--cc=balbi@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=peter.ujfalusi@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.