Hi,
I've started to try solving this one, but it is not easy for me since I know
nothing about CardServices and what it does before/after issuing CS_EVENT_*
events.
I compared the dtl1_cs code to that of the orinoco_cs (wifi) driver, and I
guess the handling is about the same. What could be wrong in dtl1_cs ?
The fact that 'cardctl suspend' breaks the driver and 'cardctl eject ; cardctl
insert' fixes it, I'm certain this can be solved in software. Surely there
is a way that the driver can fully reset itself without it having to be done
externally by cardmgr. I know that suspend/resume actions are supposed to be
optimized versions of eject/insert, but since the current suspend/resume
functions _don't_ work, we may as well do a full and slow reset instead. No
sense in leaving it broken. Once someone comes along who understands how
suspend/resume works, the driver can be optimized.
Unfortunately, this isn't as easy as it appears on the surface. I tried a
simple and dirty hack of making suspend perform the eject code and resume to
perform the insert code (a cut and paste of just a few lines), but was
unsuccessful.
Clues please!
-Justin
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wednesday 24 September 2003 02:36 am, Marcel Holtmann wrote:
> Maybe you should ask Socket for the specs of the Nokia card. Last time
> they send me a NDA which I can't accept. Now they have the Rev. G card
> on the market and these old cards are not built anymore. Maybe they make
> the specs public if someone asks. Put me on CC if you write to them.
I have written you privately about this.
By the way, I have found a simpler way to break the driver. It seems that if
I do 'hciconfig hci0 down', then 'hciconfig hci0 up' will hang. This is
without issuing any cardctl commands. I'm not sure if this should be
considered surprising.
-Justin
Hi Justin,
> So Affix goes through some sort of serial library, while Bluez writes to the
> UART directly? I noticed calls like outb() in bluez, but no such calls in
> Affix, which probably explains some things..
at the time I have looked at the code it was even worse. But in general
they like to represent the UART as a serial interface ttyS16 or so and
use a ldisc for the Nokia transport protocol.
> > The register/unregister should also work with BlueZ, but you must make
> > sure that the UART is in the correct state, as I said previous.
>
> Right. I tried Affix tonight, and it does not properly function after a
> 'cardctl reset' either. However, it can be solved by typing 'btctl down ;
> btctl up'. This looks more like a bug in their hci side of things. In any
> case, the UART gets reset to the correct state somehow and the driver works.
>
> Now how to figure out what they are doing so we can have this in Bluez (minus
> the hci bug of course :)).
Maybe you should ask Socket for the specs of the Nokia card. Last time
they send me a NDA which I can't accept. Now they have the Rev. G card
on the market and these old cards are not built anymore. Maybe they make
the specs public if someone asks. Put me on CC if you write to them.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tuesday 23 September 2003 06:35 pm, Marcel Holtmann wrote:
> I only looked at the first Affix release and never looked again. But
> from what I know is that the core of the UART driver is based on
> serial_cs and they put more hacks into to get them working with the
> their own and other Bluetooth cards with serial interface. And the
> serial_cs driver itself is one of the "bad drivers" out their.
>
> The UART on the DTL-1 card is not a normal UART and it uses the ring
> indicator for some unusual flow control. So I decided to drive the UART
> by myself.
So Affix goes through some sort of serial library, while Bluez writes to the
UART directly? I noticed calls like outb() in bluez, but no such calls in
Affix, which probably explains some things..
> > Has anyone here used Affix, and can they claim that suspend/resume works
> > for the DTL1 card? I noticed the driver does have some handling
> > functions, like affix_uart_suspend() and affix_uart_resume(), which
> > appear to simply detach / reattach the driver from the HCI subsystem.
> > Under Bluez, such an action would do just about nothing (in my experience
> > anyway), but I think under Affix, the act of attaching to the hci
> > subsystem causes the hardware to be affected also. My guess is that
> > init_uart gets called somwhere down the line.
>
> The register/unregister should also work with BlueZ, but you must make
> sure that the UART is in the correct state, as I said previous.
Right. I tried Affix tonight, and it does not properly function after a
'cardctl reset' either. However, it can be solved by typing 'btctl down ;
btctl up'. This looks more like a bug in their hci side of things. In any
case, the UART gets reset to the correct state somehow and the driver works.
Now how to figure out what they are doing so we can have this in Bluez (minus
the hci bug of course :)).
-Justin
Hi Justin,
> I hadn't considered looking at Affix until you mentioned it just now. After
> looking through the code, I notice they do have more elaborate handling of
> the UART, for instance the init_uart() function found in
> affix-kernel/drivers/uart/btuart.c. What does the Bluez dtl1_cs use for the
> UART code? It does not appear as obvious.
I only looked at the first Affix release and never looked again. But
from what I know is that the core of the UART driver is based on
serial_cs and they put more hacks into to get them working with the
their own and other Bluetooth cards with serial interface. And the
serial_cs driver itself is one of the "bad drivers" out their.
The UART on the DTL-1 card is not a normal UART and it uses the ring
indicator for some unusual flow control. So I decided to drive the UART
by myself.
> Has anyone here used Affix, and can they claim that suspend/resume works for
> the DTL1 card? I noticed the driver does have some handling functions, like
> affix_uart_suspend() and affix_uart_resume(), which appear to simply detach /
> reattach the driver from the HCI subsystem. Under Bluez, such an action
> would do just about nothing (in my experience anyway), but I think under
> Affix, the act of attaching to the hci subsystem causes the hardware to be
> affected also. My guess is that init_uart gets called somwhere down the
> line.
The register/unregister should also work with BlueZ, but you must make
sure that the UART is in the correct state, as I said previous.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tuesday 23 September 2003 03:17 pm, Marcel Holtmann wrote:
> The Affix stack came with support of the DTL-1 card and I have started
> to read their code, which was very ugly by the way. After analysing the
> complete HCI abstraction and the driver itself, the driver divides into
> two parts. One is the HCI transport protocol which is not H:4, the other
> part is the correct way of driving the internal UART on the card. The
> Affix driver was not portable in any way, so I have started to write a
> driver for these cards from scratch.
I hadn't considered looking at Affix until you mentioned it just now. After
looking through the code, I notice they do have more elaborate handling of
the UART, for instance the init_uart() function found in
affix-kernel/drivers/uart/btuart.c. What does the Bluez dtl1_cs use for the
UART code? It does not appear as obvious.
Has anyone here used Affix, and can they claim that suspend/resume works for
the DTL1 card? I noticed the driver does have some handling functions, like
affix_uart_suspend() and affix_uart_resume(), which appear to simply detach /
reattach the driver from the HCI subsystem. Under Bluez, such an action
would do just about nothing (in my experience anyway), but I think under
Affix, the act of attaching to the hci subsystem causes the hardware to be
affected also. My guess is that init_uart gets called somwhere down the
line.
-Justin
Hi Justin,
> Ok, so it appears that the resetting of the card itself is the issue at hand.
I am not 100% sure, but this is what I got.
> How did you write the rest of the driver without the specs? It would seem if
> you were able to get this far, that deriving the reset function would be
> possible.
The Affix stack came with support of the DTL-1 card and I have started
to read their code, which was very ugly by the way. After analysing the
complete HCI abstraction and the driver itself, the driver divides into
two parts. One is the HCI transport protocol which is not H:4, the other
part is the correct way of driving the internal UART on the card. The
Affix driver was not portable in any way, so I have started to write a
driver for these cards from scratch.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tuesday 23 September 2003 02:37 pm, Marcel Holtmann wrote:
> the main problem is the reset of the card itself. I actually don't know
> how to do this and I don't have the specs for this card.
Ok, so it appears that the resetting of the card itself is the issue at hand.
How did you write the rest of the driver without the specs? It would seem if
you were able to get this far, that deriving the reset function would be
possible.
-Justin
Hi Justin,
> This is unfortunate, as it pretty much rules out this ever being fixed on the
> Zaurus. Do you think this problem is really a bug in the PCMCIA subsystem?
>
> From my work the other day, it appears that the card is not properly being
> reset. In fact, you can break the driver by running 'cardctl reset'. This
> used to leave bluez in a funny state: hci0 still considered UP, but 'hcitool
> scan' would hang or return odd results.
>
> One thing I tried was unregistering / registering the hci dev in response to a
> pcmcia reset event. This would clean things out on the bluez end, such that
> 'hcitool scan' would exit immediately saying there is no device. This is
> correct, as 'hciconfig' would report the device as DOWN. Issuing 'hciconfig
> hci0 up' would timeout. Interestingly, it seems bluez tries to bring the
> card up automatically, which is kind of cool (when I 'hciconfig' shortly
> after 'cardctl reset', I would see the state as "DOWN INIT RUNNING" or some
> such, and then moments later just "DOWN").
>
> So it seems what needs to be done is for the card to be reset completely. I
> don't know what kind of state 'cardctl reset' leaves the card in. It looks
> like it is a serial-based interface to the card, so even being off by one
> byte could be a problem. Perhaps the card still considers itself to be
> active and in mid-use, and so reregistering the hci dev causes bluez and the
> card to become out of sync. Unlike other hardware, such as memory cards, a
> bluetooth card is pretty much unusable after a suspend, so I think a full
> reset (of both bluez and the card itself) is in order.
>
> To reset the card, I tried calling: dtl1_release, dtl1_config. This didn't
> appear to solve anything. Then I tried putting that into the insertion event
> code, so it became "config, release, config". This failed also, making the
> driver unusable even upon card insert. This seems to imply that your code is
> not doing proper cleanup or resetting. Shouldn't it be safe to call "config,
> release, config, release, config, release, etc" any number of times?
the main problem is the reset of the card itself. I actually don't know
how to do this and I don't have the specs for this card. If you suspend
you also have to suspend the HCI device and resume it have resume. In
general a up/down toggle should work here. You can use hci_suspend_dev()
and hci_resume_dev() in conjunction with hotplug (bluetooth.agent) for
this job. But as you already noticed, you have to bring the UART on the
card in the correct state so that can it be reinit after resume.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tuesday 23 September 2003 05:19 am, Marcel Holtmann wrote:
> don't expect too much, because I think this problem is not solveable
> with 2.4 and I am waiting for the final 2.6 with the changes in the
> PCMCIA subsystem before I ever start working on this again.
This is unfortunate, as it pretty much rules out this ever being fixed on t=
he=20
Zaurus. Do you think this problem is really a bug in the PCMCIA subsystem?
=46rom my work the other day, it appears that the card is not properly bein=
g=20
reset. In fact, you can break the driver by running 'cardctl reset'. This=
=20
used to leave bluez in a funny state: hci0 still considered UP, but 'hcitoo=
l=20
scan' would hang or return odd results.
One thing I tried was unregistering / registering the hci dev in response t=
o a=20
pcmcia reset event. This would clean things out on the bluez end, such tha=
t=20
'hcitool scan' would exit immediately saying there is no device. This is=20
correct, as 'hciconfig' would report the device as DOWN. Issuing 'hciconfi=
g=20
hci0 up' would timeout. Interestingly, it seems bluez tries to bring the=20
card up automatically, which is kind of cool (when I 'hciconfig' shortly=20
after 'cardctl reset', I would see the state as "DOWN INIT RUNNING" or some=
=20
such, and then moments later just "DOWN").
So it seems what needs to be done is for the card to be reset completely. =
I=20
don't know what kind of state 'cardctl reset' leaves the card in. It looks=
=20
like it is a serial-based interface to the card, so even being off by one=20
byte could be a problem. Perhaps the card still considers itself to be=20
active and in mid-use, and so reregistering the hci dev causes bluez and th=
e=20
card to become out of sync. Unlike other hardware, such as memory cards, a=
=20
bluetooth card is pretty much unusable after a suspend, so I think a full=20
reset (of both bluez and the card itself) is in order.
To reset the card, I tried calling: dtl1_release, dtl1_config. This didn't=
=20
appear to solve anything. Then I tried putting that into the insertion eve=
nt=20
code, so it became "config, release, config". This failed also, making the=
=20
driver unusable even upon card insert. This seems to imply that your code =
is=20
not doing proper cleanup or resetting. Shouldn't it be safe to call "confi=
g,=20
release, config, release, config, release, etc" any number of times?
=2DJustin
On Tue, 2003-09-23 at 05:08 -0700, Justin Karneges wrote:
> I don't think I want to see another info->link or mod_timer again in my life.
>
> I hereby commend anyone who manages to do kernel development. Personally, I'd
> like to start throwing things out the window.
Most of the kernel is a _lot_ saner than the PCMCIA code.
As for the PCMCIA code, I heartily recommend printing it all out on
paper, ritually burning it, urinating on the ashes, and participating in
the rewrite that's going into 2.6 :)
--
dwmw2
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Justin,
> I've spent way too many hours on this now, probably 12 in the last two days,
> and still I have no solution. This is after crashing my Zaurus an
> uncountable number of times. I'm about to give up, simply because I can't
> waste away my time like this. What I wanted was to make this thing clean,
> but instead I spent probably more time in hacking then I'll ever do in
> ejecting and inserting of my Bluetooth card.
>
> I don't think I want to see another info->link or mod_timer again in my life.
>
> I hereby commend anyone who manages to do kernel development. Personally, I'd
> like to start throwing things out the window.
don't expect too much, because I think this problem is not solveable
with 2.4 and I am waiting for the final 2.6 with the changes in the
PCMCIA subsystem before I ever start working on this again.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Update...
I've spent way too many hours on this now, probably 12 in the last two days,
and still I have no solution. This is after crashing my Zaurus an
uncountable number of times. I'm about to give up, simply because I can't
waste away my time like this. What I wanted was to make this thing clean,
but instead I spent probably more time in hacking then I'll ever do in
ejecting and inserting of my Bluetooth card.
I don't think I want to see another info->link or mod_timer again in my life.
I hereby commend anyone who manages to do kernel development. Personally, I'd
like to start throwing things out the window.
Is it 5AM already?
-Justin
On Monday 22 September 2003 04:08 am, Justin Karneges wrote:
> Hi,
>
> I've started to try solving this one, but it is not easy for me since I
> know nothing about CardServices and what it does before/after issuing
> CS_EVENT_* events.
>
> I compared the dtl1_cs code to that of the orinoco_cs (wifi) driver, and I
> guess the handling is about the same. What could be wrong in dtl1_cs ?
>
> The fact that 'cardctl suspend' breaks the driver and 'cardctl eject ;
> cardctl insert' fixes it, I'm certain this can be solved in software.
> Surely there is a way that the driver can fully reset itself without it
> having to be done externally by cardmgr. I know that suspend/resume
> actions are supposed to be optimized versions of eject/insert, but since
> the current suspend/resume functions _don't_ work, we may as well do a full
> and slow reset instead. No sense in leaving it broken. Once someone comes
> along who understands how suspend/resume works, the driver can be
> optimized.
>
> Unfortunately, this isn't as easy as it appears on the surface. I tried a
> simple and dirty hack of making suspend perform the eject code and resume
> to perform the insert code (a cut and paste of just a few lines), but was
> unsuccessful.
>
> Clues please!
>
> -Justin
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel