* shared hci transport
@ 2009-08-26 11:36 Pavan Savoy
2009-08-26 18:03 ` Marcel Holtmann
0 siblings, 1 reply; 5+ messages in thread
From: Pavan Savoy @ 2009-08-26 11:36 UTC (permalink / raw)
To: linux-bluetooth
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/
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: shared hci transport 2009-08-26 11:36 shared hci transport Pavan Savoy @ 2009-08-26 18:03 ` Marcel Holtmann 2009-08-27 5:55 ` Pavan Savoy 0 siblings, 1 reply; 5+ messages in thread From: Marcel Holtmann @ 2009-08-26 18:03 UTC (permalink / raw) To: Pavan Savoy; +Cc: linux-bluetooth 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: shared hci transport 2009-08-26 18:03 ` Marcel Holtmann @ 2009-08-27 5:55 ` Pavan Savoy 2009-08-27 19:29 ` Marcel Holtmann 0 siblings, 1 reply; 5+ messages in thread From: Pavan Savoy @ 2009-08-27 5:55 UTC (permalink / raw) To: Marcel Holtmann; +Cc: linux-bluetooth 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 <marcel@holtmann.org> To: Pavan Savoy <pavan_savoy@yahoo.co.in> Cc: linux-bluetooth@vger.kernel.org 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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Thinking of ordering food? Find restaurant numbers on Yahoo! India Local http://in.local.yahoo.com/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: shared hci transport 2009-08-27 5:55 ` Pavan Savoy @ 2009-08-27 19:29 ` Marcel Holtmann 2009-08-28 5:27 ` Pavan Savoy 0 siblings, 1 reply; 5+ messages in thread From: Marcel Holtmann @ 2009-08-27 19:29 UTC (permalink / raw) To: Pavan Savoy; +Cc: linux-bluetooth 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: shared hci transport 2009-08-27 19:29 ` Marcel Holtmann @ 2009-08-28 5:27 ` Pavan Savoy 0 siblings, 0 replies; 5+ messages in thread From: Pavan Savoy @ 2009-08-28 5:27 UTC (permalink / raw) To: Marcel Holtmann; +Cc: linux-bluetooth ----- Original Message ----=0AFrom: Marcel Holtmann <marcel@holtmann.org>= =0ATo: Pavan Savoy <pavan_savoy@yahoo.co.in>=0ACc: linux-bluetooth@vger.ker= 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 majordomo@vger.kernel.org=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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-08-28 5:27 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-08-26 11:36 shared hci transport Pavan Savoy 2009-08-26 18:03 ` Marcel Holtmann 2009-08-27 5:55 ` Pavan Savoy 2009-08-27 19:29 ` Marcel Holtmann 2009-08-28 5:27 ` Pavan Savoy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox