* Luciano Coelho <coelho@xxxxxx> [130118 11:12]: > On Fri, 2013-01-18 at 09:36 -0800, Tony Lindgren wrote: > > * Luciano Coelho <coelho@xxxxxx> [130118 01:03]: > > > On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote: > > > > * Luciano Coelho <coelho@xxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
