----- Original Message ----
From: Marcel Holtmann <marcel@xxxxxxxxxxxx>
To: Pavan Savoy <pavan_savoy@xxxxxxxxxxx>
Cc: linux-bluetooth@xxxxxxxxxxxxxxx
Sent: Friday, 28 August, 2009 12:59:08 AM
Subject: Re: shared hci transport
Hi Pavan,
please don't do top-posting on this mailing list. We want proper inline
quoting.
> sure.
> the bcm4325 has uart transport for BT [so I can make use of hci_h4, say by hciattach - like bcm2035].
> The FM core understands hci-vendor specific command.
>
> for example, I send HCI_VS opcode=0x20 to set the power of Rx to On.[The power on sequence also involves download of a firmware which is nothing but a file with ~10/20 hci-vendor specific commands with different opcodes].
> opcode 0x0a (say) to set the frequency and similarly in opcode 0x1d [audio enable] I give an data arguement 0x01 or 0x02 to say to FM Rx to put out audio on either it's analog lines or digital [i2s] lines..
>
> Currently my fm stack, application is making use of hci_open_dev, send_cmd kind of hci lib calls to send commands.
>
> Now what should be my approach to send in same sort of commands from the kernel space ?
>For the firmware loading part, we have to change this whole driver model
>and add an init stage that allows configuration etc.
>I am not sold on the whole in-kernel approach for FM yet. We need to
>talk more about it. Especially since vendor commands and messing with
>the flow control is tricky.
>Regards
>Marcel
Yes -- Sorry for top posting [unfortunately this dumb mail editor doesn't give me much of choice]
In any case,
I was thinking more in terms of hci_device and hci_driver kind of a model, where in there can be a hci_device for a transport [say HCI-UART] and multiple hci_driver(s) for 1 such hci_device -- these hci_drivers get registered to a main/single hci_device.
hci_device {
open,send_frame, notify, flush, close
}
and the new hci_driver {
pre/post_open, -- can be used for a f/w download
pre/post_send, -- can be used to packetize/depacketize
pre/post_notify, -- events can be categorised to HCI [cmd complete] sort of events or processed locally and not be notified to hci-user space layer..
pre/post_flush and
pre/post_close
}
It would be same as using line discipline driver over uart. Every HCI transfer send or recieve can have a pre/post function of an already registered "hci_driver" which needs to called.
We would kind of make use for plenty of other purpose also, since the transports are being shared for all sort of devices nowadays [gps+bt on uart/usb, fm+bt on uart].
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
