Hi,
the current hci_uart.o driver supports H4 and BCSP HCI protocols and the
code from it should be reusable by the other drivers two. For example
most PCMCIA cards are a kind of serial cards with an UART on it. The
only difference is how the UART would be used to talk to the Bluetooth
chips and many times you need some extra code. If this Bluetooth chip is
one from CSR their are two protocols available two use and you can
switch between them if you like (and autodetection would be great). So
it should be possible to reuse the H4 and the BCSP code, which will make
some PCCARD drivers a little bit smaller.
The current driver which can reuse the code are:
bluecard_cs: H4
bt3c_cs: H4
btuart_cs: H4 and BCSP
bt950_cs: H4 and BCSP
hci_uart: H4 and BCSP
At the moment I see two ways of doing this, but maybe there are more of
them.
1. Let the hci_uart driver export some function to let the drivers
register. Maybe something like:
hci_register_uart (which later calls hci_register_dev)
hci_unregister_uart (which later calls hci_unregister_dev)
2. Make the code in hci_h4.c and hci_bcsp.c linkable against the driver.
Both versions have advantages and disadvantages. The first one keeps the
size of the driver module small, but you always need another module to
interface with the HCI core. The second one need no other modules, but
the code for the UART protocols are in every driver.
>From me personal view of it I don't like to have too much modules and I
would go with the second possibility. But anyway for both methods some
parts of the BCSP init code have to be moved to the kernel space.
Please comment on this. Anyone who will start with this?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
[email protected] said:
> And it should be possible to put some quirks into the serial_cs to
> let it work with all cards supported by the bt950_cs and btuart_cs
> driver, but from my point this is the wrong way, because the serial_cs
> is a very messy beast.
Btw, I have a patch from rmk which fixes the 8250 driver so it works with my
OXCF950 (Cyber-blue) card and btuart_cs is no longer necessary. What other
cards currently still require btuart_cs and why?
--
dwmw2
Hi Max,
> >this will be possible for the btuart_cs and bt950_cs driver, but it will
> >not be a good idea for the bluecard_cs and bt3c_cs. These two drivers
> >should not look like a TTY and they only share the H4 protocol.
> So it's impossible to switch them to BCSP ?
> If that's the case then it's ok to keep them stand alone.
for the bluecard_cs this is right, because it is an Ericsson chip and I
think it is also true for the bt3c_cs because they use another kind
firmware. But the point is not implementing H4, because this is easy and
the code is very small. So we can keep (and I actually will) keep these
drivers standalone. But if I can reuse the existing H4 code like in #2 I
am also happy.
And in the case of BCSP it makes really sense to maintain the code at
one central point :)
> >And I don't want to make them work like the bluetooth.o driver from Greg.
> USB is different. bluetty _emulates_ serial interface, where is in this
> case all those cards have real UARTs and drivers would _reuse_ existing
> serial interface (i.e. TTY) provided by the kernel.
This is exactly what I wanted to say. If they don't have real UART, like
16650A or an OX950 or something else it is not good to emulate a TTY.
> >And it should be possible to put some quirks into the serial_cs to let it work
> >with all cards supported by the bt950_cs and btuart_cs driver, but from my point
> >this is the wrong way, because the serial_cs is a very messy beast.
> bt950 doesn't have to talk to serial_cs. It be nice if it can reuse 16650A code
> but if it can't it should be standalone TTY.
> What cards are supported by btuart_cs that are not supported by serial_cs ?
The serial.o have a register_serial function and I want to start playing
with it. And yes we have one card that works with btuart_cs, but not
with serial_cs. I was told that the "magic initialization" of serial_cs
(or serial.o) causes the hciattach to fail, but the minimal things in
btuart_cs keep it happy and the device will work.
> #2 is already there. All you have do in your driver is provide following
> interfaces:
> - struct hci_uart
> H4 and BCSP don't use tty field, so may by NULL
> - hci_uart_register_proto() / hci_uart_register_proto()
>
> - Call h4_init() and bcsp_init() during initialization.
>
> That's it. Once you have that you can just link hci_h4.o and hci_bcsp.o
> into your driver.
> btw We should probably just drop this register/unregister interface. It's
> not dynamic anyway.
I will start playing with it. Have anyone done this before and can share
some experiences?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
>> 3. Move H4 and BCSP to a separate module hci_uart_proto (or whatever) and
>> export
>> hci_uart_get_proto(XXX)
>> hci_uart_put_proto(XXX)
>> etc
>
>sounds for me similar to the number 1. But you pull the code outside the
>hci_uart driver. My problem with this is (like with number 1) you need
>another module to let the driver interface with the HCI core.
But you already have it. I mean you keep most of the bluecard_cs (or whatever)
and simply off load H4/BCSP processing.
>> 4. Make all H4/BCSP _cs look like normal TTY (with minimal TTY functionality)
>> and use hciattach + hci_uart.o
>
>this will be possible for the btuart_cs and bt950_cs driver, but it will
>not be a good idea for the bluecard_cs and bt3c_cs. These two drivers
>should not look like a TTY and they only share the H4 protocol.
So it's impossible to switch them to BCSP ?
If that's the case then it's ok to keep them stand alone.
>And I don't want to make them work like the bluetooth.o driver from Greg.
USB is different. bluetty _emulates_ serial interface, where is in this
case all those cards have real UARTs and drivers would _reuse_ existing
serial interface (i.e. TTY) provided by the kernel.
>This is the wrong way I think. For the btuart_cs you can use the serial_cs
>driver and than use hciattach and the hci_uart driver.
Yep.
>And it should be possible to put some quirks into the serial_cs to let it work
>with all cards supported by the bt950_cs and btuart_cs driver, but from my point
>this is the wrong way, because the serial_cs is a very messy beast.
bt950 doesn't have to talk to serial_cs. It be nice if it can reuse 16650A code
but if it can't it should be standalone TTY.
What cards are supported by btuart_cs that are not supported by serial_cs ?
>> Believe it or not but I actually prefer #4 :). I know I know, I was the one who
>> said that we should try to avoid TTY layers if possible. But it's becoming
>> more and more troublesome. I don't like the idea of moving BCSP initialization
>> and H4/BCSP auto-detection into the kernel. In order to keep it in the user space
>> we need some interface for hciattach. And TTY provides perfect interface
>> for what hciattach needs to do.
>> So far I haven't seen any Bluetooth HCI performance issues related to the
>> TTY layer. We set tty->low_latency flag and get data right of the ring buffer.
>> And we don't have to support complete TTY functionally, just stuff that we need
>> i.e. set baudrate, read/write, etc.
>> btw In 2.5.x TTY layer has been cleaned up and doesn't look as bad as in 2.4.
>>
>> #1 Is essentially reinventing TTY interface. i.e. HW drivers register to a
>> generic layer i.e. TTY (or HCI in our case).
>> #2 Is unnecessary bloating. I'd rather do #3.
>>
>> But the biggest disadvantage of 1,2 and 3 is lack of interface for the user space.
>> If you remember BCSP discussions, there was an issue of properly resetting HCI device
>> (i.e. HCI and all the way up) if HW problems were detected. With hciattach it's easy,
>> hci_uart sends SIGHUP -> hciattach closes TTY -> HCI device unregistered -> hciattach
>> reopens TTY. It's not that simple without hciattach.
>
>I will take the weekend to do some test with the serial_cs driver and
>try to get the bt950_cs register a TTY and start playing with it. Maybe
>we should do something like #2 and #4. So the code can be linked into
>another driver like for bluecard_cs and bt3c_cs and maybe if some people
>need a special driver for some embedded devices. On the embedded side
>the bloat of #2 wouldn't count because you will only have one hardware
>driver. With using number #2 for it we can maintain the H4 and BCSP
>source code at one point and it can be reused. So we only use them in
>the hci_uart, bluecard_cs and bt3c_cs driver, but it can be used by
>special drivers in the future, if needed.
#2 is already there. All you have do in your driver is provide following
interfaces:
- struct hci_uart
H4 and BCSP don't use tty field, so may by NULL
- hci_uart_register_proto() / hci_uart_register_proto()
- Call h4_init() and bcsp_init() during initialization.
That's it. Once you have that you can just link hci_h4.o and hci_bcsp.o
into your driver.
btw We should probably just drop this register/unregister interface. It's
not dynamic anyway.
Max
Hi Max,
> >the current hci_uart.o driver supports H4 and BCSP HCI protocols and the
> >code from it should be reusable by the other drivers two. For example
> >most PCMCIA cards are a kind of serial cards with an UART on it. The
> >only difference is how the UART would be used to talk to the Bluetooth
> >chips and many times you need some extra code. If this Bluetooth chip is
> >one from CSR their are two protocols available two use and you can
> >switch between them if you like (and autodetection would be great). So
> >it should be possible to reuse the H4 and the BCSP code, which will make
> >some PCCARD drivers a little bit smaller.
> >
> >The current driver which can reuse the code are:
> >
> >bluecard_cs: H4
> >bt3c_cs: H4
> >btuart_cs: H4 and BCSP
> >bt950_cs: H4 and BCSP
> >hci_uart: H4 and BCSP
> >
> >At the moment I see two ways of doing this, but maybe there are more of
> >them.
> >
> >1. Let the hci_uart driver export some function to let the drivers
> >register. Maybe something like:
> >
> > hci_register_uart (which later calls hci_register_dev)
> > hci_unregister_uart (which later calls hci_unregister_dev)
> >
> >2. Make the code in hci_h4.c and hci_bcsp.c linkable against the driver.
> >
> >Both versions have advantages and disadvantages. The first one keeps the
> >size of the driver module small, but you always need another module to
> >interface with the HCI core. The second one need no other modules, but
> >the code for the UART protocols are in every driver.
>
> 3. Move H4 and BCSP to a separate module hci_uart_proto (or whatever) and
> export
> hci_uart_get_proto(XXX)
> hci_uart_put_proto(XXX)
> etc
sounds for me similar to the number 1. But you pull the code outside the
hci_uart driver. My problem with this is (like with number 1) you need
another module to let the driver interface with the HCI core.
> 4. Make all H4/BCSP _cs look like normal TTY (with minimal TTY functionality)
> and use hciattach + hci_uart.o
this will be possible for the btuart_cs and bt950_cs driver, but it will
not be a good idea for the bluecard_cs and bt3c_cs. These two drivers
should not look like a TTY and they only share the H4 protocol. And I
don't want to make them work like the bluetooth.o driver from Greg. This
is the wrong way I think. For the btuart_cs you can use the serial_cs
driver and than use hciattach and the hci_uart driver. And it should be
possible to put some quirks into the serial_cs to let it work with all
cards supported by the bt950_cs and btuart_cs driver, but from my point
this is the wrong way, because the serial_cs is a very messy beast.
> Believe it or not but I actually prefer #4 :). I know I know, I was the one who
> said that we should try to avoid TTY layers if possible. But it's becoming
> more and more troublesome. I don't like the idea of moving BCSP initialization
> and H4/BCSP auto-detection into the kernel. In order to keep it in the user space
> we need some interface for hciattach. And TTY provides perfect interface
> for what hciattach needs to do.
> So far I haven't seen any Bluetooth HCI performance issues related to the
> TTY layer. We set tty->low_latency flag and get data right of the ring buffer.
> And we don't have to support complete TTY functionally, just stuff that we need
> i.e. set baudrate, read/write, etc.
> btw In 2.5.x TTY layer has been cleaned up and doesn't look as bad as in 2.4.
>
> #1 Is essentially reinventing TTY interface. i.e. HW drivers register to a
> generic layer i.e. TTY (or HCI in our case).
> #2 Is unnecessary bloating. I'd rather do #3.
>
> But the biggest disadvantage of 1,2 and 3 is lack of interface for the user space.
> If you remember BCSP discussions, there was an issue of properly resetting HCI device
> (i.e. HCI and all the way up) if HW problems were detected. With hciattach it's easy,
> hci_uart sends SIGHUP -> hciattach closes TTY -> HCI device unregistered -> hciattach
> reopens TTY. It's not that simple without hciattach.
I will take the weekend to do some test with the serial_cs driver and
try to get the bt950_cs register a TTY and start playing with it. Maybe
we should do something like #2 and #4. So the code can be linked into
another driver like for bluecard_cs and bt3c_cs and maybe if some people
need a special driver for some embedded devices. On the embedded side
the bloat of #2 wouldn't count because you will only have one hardware
driver. With using number #2 for it we can maintain the H4 and BCSP
source code at one point and it can be reused. So we only use them in
the hci_uart, bluecard_cs and bt3c_cs driver, but it can be used by
special drivers in the future, if needed.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
>the current hci_uart.o driver supports H4 and BCSP HCI protocols and the
>code from it should be reusable by the other drivers two. For example
>most PCMCIA cards are a kind of serial cards with an UART on it. The
>only difference is how the UART would be used to talk to the Bluetooth
>chips and many times you need some extra code. If this Bluetooth chip is
>one from CSR their are two protocols available two use and you can
>switch between them if you like (and autodetection would be great). So
>it should be possible to reuse the H4 and the BCSP code, which will make
>some PCCARD drivers a little bit smaller.
>
>The current driver which can reuse the code are:
>
>bluecard_cs: H4
>bt3c_cs: H4
>btuart_cs: H4 and BCSP
>bt950_cs: H4 and BCSP
>hci_uart: H4 and BCSP
>
>At the moment I see two ways of doing this, but maybe there are more of
>them.
>
>1. Let the hci_uart driver export some function to let the drivers
>register. Maybe something like:
>
> hci_register_uart (which later calls hci_register_dev)
> hci_unregister_uart (which later calls hci_unregister_dev)
>
>2. Make the code in hci_h4.c and hci_bcsp.c linkable against the driver.
>
>Both versions have advantages and disadvantages. The first one keeps the
>size of the driver module small, but you always need another module to
>interface with the HCI core. The second one need no other modules, but
>the code for the UART protocols are in every driver.
3. Move H4 and BCSP to a separate module hci_uart_proto (or whatever) and
export
hci_uart_get_proto(XXX)
hci_uart_put_proto(XXX)
etc
4. Make all H4/BCSP _cs look like normal TTY (with minimal TTY functionality)
and use hciattach + hci_uart.o
>>>From me personal view of it I don't like to have too much modules and I
>would go with the second possibility. But anyway for both methods some
>parts of the BCSP init code have to be moved to the kernel space.
Believe it or not but I actually prefer #4 :). I know I know, I was the one who
said that we should try to avoid TTY layers if possible. But it's becoming
more and more troublesome. I don't like the idea of moving BCSP initialization
and H4/BCSP auto-detection into the kernel. In order to keep it in the user space
we need some interface for hciattach. And TTY provides perfect interface
for what hciattach needs to do.
So far I haven't seen any Bluetooth HCI performance issues related to the
TTY layer. We set tty->low_latency flag and get data right of the ring buffer.
And we don't have to support complete TTY functionally, just stuff that we need
i.e. set baudrate, read/write, etc.
btw In 2.5.x TTY layer has been cleaned up and doesn't look as bad as in 2.4.
#1 Is essentially reinventing TTY interface. i.e. HW drivers register to a
generic layer i.e. TTY (or HCI in our case).
#2 Is unnecessary bloating. I'd rather do #3.
But the biggest disadvantage of 1,2 and 3 is lack of interface for the user space.
If you remember BCSP discussions, there was an issue of properly resetting HCI device
(i.e. HCI and all the way up) if HW problems were detected. With hciattach it's easy,
hci_uart sends SIGHUP -> hciattach closes TTY -> HCI device unregistered -> hciattach
reopens TTY. It's not that simple without hciattach.
Max
On Thu, 28 Nov 2002, [email protected] said:
> The serial.o have a register_serial function and I want to start
> playing with it. And yes we have one card that works with btuart_cs,
> but not with serial_cs. I was told that the "magic initialization" of
> serial_cs (or serial.o) causes the hciattach to fail, but the minimal
> things in btuart_cs keep it happy and the device will work.
Having fixed the 8250 driver so it doesn't screw up the extended
functionality of the Oxford Semi OXCF950 on startup, it transpires that all
we were actually losing was the extra magic baud rate divisor. Using the old
serial driver from 2.4 and setting baud_base to 1152000 to compensate allows
you to use the line discipline code with the standard serial driver.
--
dwmw2