On Sun, Jan 9, 2011 at 7:12 PM, Pavan Savoy <pavan_savoy@xxxxxxxx> wrote: >> This sounds wrong for both TI and ST-E: AFAICT they are actually built >> around an HCI interface. It's unfortunate that the TI code actually got >> merged into the kernel like this. > > I am not sure what does built around HCI Interface mean? Also yes, in TI- code > we do refer to Bluetooth headers. I think that the first and the major problem with TI code is that it is _very_ dependent on the HCI-LL protocol. I urge you again to sort that out first and then the whole thing will get quite a bit clearer to all the parties. > However the fact that I wanted to point out to Par-Gunnar was, that we > don't want to use > hciattach and enable HCI-UART + HCI-H4 for enabling our driver or our > driver should not > depend on those modules as such... I really don't care _that_ much if we have to enable HCI interface to bring say the FM radio up. What I do care about is the startup time for the same FM radio, or GPS, which turns to be far longer if we go the awkward way of launching hciattach and friends which are not in fact needed at all. So I tend to agree with you here. > > The references to bluetooth headers in a certain way is inevitable > because as he pointed > out, firmware is downloaded as HCI-VS commands, too bad the firmware > doesn't have any other > means :(, But it sorts of allows violations, as in we can afford to > have HCI-VS commands sent after > disabling events, which would mean they need not be interpreted at all.. Well if we've got this common-hci-module Arnd was talking about, I believe that firmware download can be sort of abstracted. >>> > instead of common-hci-module, why not create a algo-driver layer 'ala >>> > i2c ? where individual drivers can register their receive handlers for >>> > data interpretation ? >> >> That would be what I suggested ;-) > > But even here too, the algos layer if you imagine which can be the > sort of the first > receiver of data from the transport would refer to BT headers to > interpret the data (not just BT, but FM/GPS) > and pass it onto other protocol/client drivers, > The only abstraction being that different adapter drivers can register > their own receive function > which the algo-driver can sort of call, (again all imagination....) > Let's keep things simple. Could you please come up with a step-by-step on how you would transform the existing TI solution for shared transport into something really generic? Or, the other option would IMHO be to start with sorting out some obvious shared transport flaws. Thanks, Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
