[PATCH 4/5] [omap1] Bluetooth device code common to HTC smartphones
Cory Maccarrone
darkstar6262 at gmail.com
Mon Aug 9 13:28:10 EDT 2010
On Mon, Aug 9, 2010 at 12:43 AM, Tony Lindgren <tony at atomide.com> wrote:
> * Cory Maccarrone <darkstar6262 at gmail.com> [100808 20:22]:
>> On Wed, Aug 4, 2010 at 3:15 AM, Tony Lindgren <tony at atomide.com> wrote:
>> > * Cory Maccarrone <darkstar6262 at gmail.com> [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?
- Cory
More information about the linux-arm-kernel
mailing list