From: Tony Lindgren <tony@atomide.com> To: Luciano Coelho <coelho@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: Thu, 17 Jan 2013 15:16:08 -0800 [thread overview] Message-ID: <20130117231608.GP14149@atomide.com> (raw) In-Reply-To: <1358445456.6252.64.camel@cumari.coelho.fi> * Luciano Coelho <coelho@ti.com> [130117 10:04]: > Hi Tony, > > On Thu, 2013-01-17 at 09:31 -0800, Tony Lindgren wrote: > > * Peter Ujfalusi <peter.ujfalusi@ti.com> [130117 02:44]: > > > On 01/17/2013 11:35 AM, Luciano Coelho wrote: > > > > 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). > > > > > > I don't see better way to fix this either. In any case, I give you my: > > > > > > Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> > > > > So what is actually broken? The horrible bluetooth muxing over serial > > port? If so, let's rather fix it properly than even attempt to fix > > it as it seems that it's been broken for two merge windows now. > > Yes, it is the horrible Bluetooth muxing over serial that is broken. It > has been broken for two merge windows, because nobody seemed to care > until I started looking into it and tried to figure out how to get it to > work. :) Heh I see. > The implementation is really weak and there are loads of things I want > to start fixing/cleaning up. This patch was just my intention to start > with a relatively clean table (ie. horrible or not, at least working). > > > > Also, let's just do absolutely minimal board-*.c file fixes now. > > This thing should be just moved to use DT so we can flip over omap4 > > to be DT only and drop estimated 5k LOC from mach-omap2. > > I totally agree, I'll start looking into that next. > > 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. 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. What's your estimate of having minimal wl12xx WLAN DT binding available? Regards, Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren) To: linux-arm-kernel@lists.infradead.org Subject: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions Date: Thu, 17 Jan 2013 15:16:08 -0800 [thread overview] Message-ID: <20130117231608.GP14149@atomide.com> (raw) In-Reply-To: <1358445456.6252.64.camel@cumari.coelho.fi> * Luciano Coelho <coelho@ti.com> [130117 10:04]: > Hi Tony, > > On Thu, 2013-01-17 at 09:31 -0800, Tony Lindgren wrote: > > * Peter Ujfalusi <peter.ujfalusi@ti.com> [130117 02:44]: > > > On 01/17/2013 11:35 AM, Luciano Coelho wrote: > > > > 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). > > > > > > I don't see better way to fix this either. In any case, I give you my: > > > > > > Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> > > > > So what is actually broken? The horrible bluetooth muxing over serial > > port? If so, let's rather fix it properly than even attempt to fix > > it as it seems that it's been broken for two merge windows now. > > Yes, it is the horrible Bluetooth muxing over serial that is broken. It > has been broken for two merge windows, because nobody seemed to care > until I started looking into it and tried to figure out how to get it to > work. :) Heh I see. > The implementation is really weak and there are loads of things I want > to start fixing/cleaning up. This patch was just my intention to start > with a relatively clean table (ie. horrible or not, at least working). > > > > Also, let's just do absolutely minimal board-*.c file fixes now. > > This thing should be just moved to use DT so we can flip over omap4 > > to be DT only and drop estimated 5k LOC from mach-omap2. > > I totally agree, I'll start looking into that next. > > 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. 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. What's your estimate of having minimal wl12xx WLAN DT binding available? Regards, Tony
next prev parent reply other threads:[~2013-01-17 23:16 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 [this message] 2013-01-17 23:16 ` Tony Lindgren 2013-01-18 8:58 ` Luciano Coelho 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=20130117231608.GP14149@atomide.com \ --to=tony@atomide.com \ --cc=balbi@ti.com \ --cc=coelho@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 \ /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: linkBe 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.