[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: btuart and SOCKET Bluetooth CF
On Mon, 25 Jan 2010, KIYOHARA Takashi wrote:
> > However, I'm not sure if it is permitted to use cfdata->cf_flags in this
> > manner? There seem to be some rare instances of similar use but there is
> > no mention in the API specification..
> Oops. I can't agree your patch. :-<
> DTL always has the header. It is a big penalty to check this by all
> packets. And, btuart(4) is used perhaps on a very slow machine. So it
> is a slow machine without usb(ubt(4)) perhaps.
> # My main machine is hpcsh 100MHz with PCMCIA. ;-)
> # It not have Cardbus and USB.
I don't know if some test each packet would be significant for Bluetooth.
At this stage, even with 2.0 + EDR device I managed only 80KiB/s with
L2CAP direct connection (two radios but one computer so could be
interference). but I think the Nokia DTL 1/4 device is older spec also?
but in that case please consider my suggestion as two parts "input" and
"output" path. On the input at least I think it would be more efficient
to just use the sc_drop flag instead of adding the pad byte into the mbuf
and using m_adj to remove it later - mbuf operations can be quite
expensive in this manner.. for the output you also cannot sleep at this
time, so must deal with failure to prepend/append data to the mbuf.
> In my understanding, the cfdata->cf_flags is a flag that each driver
> can use. You can find it used in arch/PORT/conf/GENERIC by wdc(4)
> and wd(4).
imo all of cfdata is not for drivers to set
I suggested previously about changing config_attach_pseduo() to accept an
argument (to pass through to driver_attach) but found no positive reaction
at that time (and, I found a better method for the usage I wanted)
Main Index |
Thread Index |