* Cory Maccarrone <darkstar6262@xxxxxxxxx> [100809 20:21]: > On Mon, Aug 9, 2010 at 12:43 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > * Cory Maccarrone <darkstar6262@xxxxxxxxx> [100808 20:22]: > >> On Wed, Aug 4, 2010 at 3:15 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >> > * Cory Maccarrone <darkstar6262@xxxxxxxxx> [100802 18:23]: > >> >> This change adds in a bluetooth controld driver/rfkill > >> >> interface to the serial bluetooth controller found on many > >> >> HTC smartphones such as the HTC Herald and HTC Wizard. > >> > > >> > To me it looks like most of this should be in drivers/bluetooth/omap7xx.c > >> > or something like that. Then you can just pass it the gpio numbers in > >> > the platform_data. > >> > > >> > >> Not sure I agree that it fits there. The driver isn't really a > >> bluetooth driver -- it's really just an RFKILL interface, and some > >> code to toggle UART clocks on and off, plus GPIO work on a > >> board-specific level. In principle, the gpios could be set and the > >> clocks enabled in the board files, and this driver wouldn't be > >> necessary to get working bluetooth (as we'd use hciattach on > >> /dev/ttyS*). But then, we can't toggle it off for power saving. > >> Maybe a better place would be plat-omap/? But it really is more > >> specific to these HTC boards, not the architecture itself. > > > > Hmm well what we've used earlier is to set something like set_power > > function pointer in the platform data, then call that in the driver > > if set. But in this case the driver is 8250.c, so let's not mess > > with that.. > > > > This issue should get properly solved with the omap specific serial > > driver once we get that merged as then we can have hooks for set_power > > in addition to cutting serial clocks when idle. > > > >> So really, the only point of this driver is to be able to power on and > >> off the external bluetooth chip, which is why I submitted it as helper > >> code to the board files. > > > > Yeah. Can you take a look at the omap specific serial driver to get > > it working on omap1? > > > > Then you can have your GPIO functions set in the board-*.c file > > as set_power or similar, and the UART driver can idle properly. > > > > I can look at it. Where is the code for that, arch/arm/mach-omap2/serial.c? It's been floating on the list for a while now, here's the latest version: http://www.spinics.net/lists/linux-omap/msg31786.html Probably doing the platform data initialization is the biggest part that needs to be done for omap1, the driver itself should not need much changes. Regards, 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
