A lot of recent BT chips intefaced by UART also tend to have another radio [mostly FM] on the same chip sharing the transport interface i.e the UART. [bcm4325 for example has bt, fm and wlan].
I just wanted to know, from the user-space the hci0 socket interface allows me to concurrently use the uart from several applications, but
is there a way in kernel to do the same ?
[say hci_h4 is also used by the fm core to understand some vendor specific commands ?]
or in an usb case - the fm has int endpoint for control data of fm [+ hci-event/cmd packets] and bulk for rds[+ acl] [assuming the audio data path - is isolated from all these ...]
regards,
Pavan
See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/
----- Original Message ----=0AFrom: Marcel Holtmann <[email protected]>=
=0ATo: Pavan Savoy <[email protected]>=0ACc: [email protected]=
nel.org=0ASent: Friday, 28 August, 2009 12:59:08 AM=0ASubject: Re: shared h=
ci transport=0A=0AHi Pavan,=0A=0Aplease don't do top-posting on this mailin=
g list. We want proper inline=0Aquoting.=0A=0A> sure.=0A> the bcm4325 has u=
art transport for BT [so I can make use of hci_h4, say by hciattach - like =
bcm2035].=0A> The FM core understands hci-vendor specific command.=0A> =0A>=
for example, I send HCI_VS opcode=3D0x20 to set the power of Rx to On.[The=
power on sequence also involves download of a firmware which is nothing bu=
t a file with ~10/20 hci-vendor specific commands with different opcodes].=
=0A> opcode 0x0a (say) to set the frequency and similarly in opcode 0x1d [a=
udio enable] I give an data arguement 0x01 or 0x02 to say to FM Rx to put o=
ut audio on either it's analog lines or digital [i2s] lines..=0A> =0A> Curr=
ently my fm stack, application is making use of hci_open_dev, send_cmd kind=
of hci lib calls to send commands.=0A> =0A> Now what should be my approach=
to send in same sort of commands from the kernel space ?=0A=0A>For the fir=
mware loading part, we have to change this whole driver model=0A>and add an=
init stage that allows configuration etc.=0A=0A>I am not sold on the whole=
in-kernel approach for FM yet. We need to=0A>talk more about it. Especiall=
y since vendor commands and messing with=0A>the flow control is tricky.=0A=
=0A>Regards=0A=0A>Marcel=0A=0AYes -- Sorry for top posting [unfortunately t=
his dumb mail editor doesn't give me much of choice]=0AIn any case,=0A=0AI =
was thinking more in terms of hci_device and hci_driver kind of a model, wh=
ere in there can be a hci_device for a transport [say HCI-UART] and multipl=
e hci_driver(s) for 1 such hci_device -- these hci_drivers get registered t=
o a main/single hci_device.=0A=0Ahci_device {=0Aopen,send_frame, notify, fl=
ush, close=0A}=0A=0Aand the new hci_driver {=0Apre/post_open, -- can be us=
ed for a f/w download=0Apre/post_send, -- can be used to packetize/depacket=
ize=0Apre/post_notify, -- events can be categorised to HCI [cmd complete] s=
ort of events or processed locally and not be notified to hci-user space la=
yer..=0Apre/post_flush and =0Apre/post_close=0A}=0A=0AIt would be same as u=
sing line discipline driver over uart. Every HCI transfer send or recieve c=
an have a pre/post function of an already registered "hci_driver" which nee=
ds to called.=0A=0AWe would kind of make use for plenty of other purpose al=
so, since the transports are being shared for all sort of devices nowadays =
[gps+bt on uart/usb, fm+bt on uart].=0A=0A=0A=0A--=0ATo unsubscribe from th=
is list: send the line "unsubscribe linux-bluetooth" in=0Athe body of a mes=
sage to [email protected]=0AMore majordomo info at http://vger.ker=
nel.org/majordomo-info.html=0A=0A=0A=0A Love Cricket? Check out live s=
cores, photos, video highlights and more. Click here http://cricket.yahoo.c=
om
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
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 ?
regards,
Pavan
----- Original Message ----
From: Marcel Holtmann <[email protected]>
To: Pavan Savoy <[email protected]>
Cc: [email protected]
Sent: Wednesday, 26 August, 2009 11:33:04 PM
Subject: Re: shared hci transport
Hi Pavan,
> A lot of recent BT chips intefaced by UART also tend to have another radio [mostly FM] on the same chip sharing the transport interface i.e the UART. [bcm4325 for example has bt, fm and wlan].
>
> I just wanted to know, from the user-space the hci0 socket interface allows me to concurrently use the uart from several applications, but
> is there a way in kernel to do the same ?
>
> [say hci_h4 is also used by the fm core to understand some vendor specific commands ?]
> or in an usb case - the fm has int endpoint for control data of fm [+ hci-event/cmd packets] and bulk for rds[+ acl] [assuming the audio data path - is isolated from all these ...]
this all depends on the actual transports. I would need the
specifications to tell you more on the right way to deal with it.
Regards
Marcel
Hi Pavan,
> A lot of recent BT chips intefaced by UART also tend to have another radio [mostly FM] on the same chip sharing the transport interface i.e the UART. [bcm4325 for example has bt, fm and wlan].
>
> I just wanted to know, from the user-space the hci0 socket interface allows me to concurrently use the uart from several applications, but
> is there a way in kernel to do the same ?
>
> [say hci_h4 is also used by the fm core to understand some vendor specific commands ?]
> or in an usb case - the fm has int endpoint for control data of fm [+ hci-event/cmd packets] and bulk for rds[+ acl] [assuming the audio data path - is isolated from all these ...]
this all depends on the actual transports. I would need the
specifications to tell you more on the right way to deal with it.
Regards
Marcel