Hi Pavan, Sorry for not answering sooner. I've been on Christmas and New Year vacation. > -----Original Message----- > From: Pavan Savoy [mailto:pavan_savoy@xxxxxxxx] > Sent: den 23 december 2010 11:49 > To: Par-Gunnar HJALMDAHL > Cc: Vitaly Wool; Linus Walleij; Alan Cox; Arnd Bergmann; Samuel Ortiz; > Marcel Holtmann; linux-kernel@xxxxxxxxxxxxxxx; linux- > bluetooth@xxxxxxxxxxxxxxx; Lukasz Rymanowski; Par-Gunnar Hjalmdahl > Subject: Re: [PATCH 00/11] mfd and bluetooth: Add CG2900 support > > P-G, Vitaly, > > > > > I would say our design would map like this: > > common-hci-module: cg2900_core > > serial, spi, i2c,... : cg2900_uart together with hci_ldisc (for other > transports it would be different files) > > bt, ti-radio, st-e-radio,...: cg2900_chip together with btcg2900 and > other users per channel (cg2900_char_devices for users in User space) > > So it is not a 1-to-1 mapping for the upper parts. I would draw it > like this: > > > >                bt  st-e-radio Âst-e-gps > >                Â|     |     Â| > >                Â+---------+----------+ > >                     Â| > >          ti-xx        Âst-e cg2900... > >           |          Â| > >           +---------+----------+ > >                | > >            common-hci-module > >                | > >          +-----------+-----------+ > >          |    Â|    |   Â| > >         serial  Âspi   i2c  Â... > > regarding the architecture above suggested... > Is having the common-hci-module, only way ? > Why is this dependency on bluetooth at all? > The reason I use Bluetooth is that it is the only standardized Host-Controller interface in these controllers (at least in the CG2900 which I'm primarily addressing). > for example: today I don't compile my kernel with BT support, but > still want to use > the chip for FM & GPS, It should be possible correct ? Yes, I use the header files from the Bluetooth files inside the driver (for packet structures and protocol IDs). I do not use the BT binaries at all in the common-hci-module or in the st-e cg2900 module. So it should be OK to configure this out. The header files will be there any way. > Even in TI case, although the firmware download is HCI-VS way, we > don't use hci_core > to interpret the responses... > We don't use that either. We just use the structs and defines in the BT headers. The dependency is only in btcg2900.c which is only included if BT is configuration enabled. > 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 ? > In some way you then run into the same problem has I had in previous patch sets. The functionalities supported is really determined by each chip. You might or might not have for example GPS in a certain chip. So you do not want a central module to expose all possible channels to the stacks on top. You only want the actually supported features to be exposed to upper layers. Then the MFD system is pretty nice. It's easy and modularized to expose the different channels as MFD cells. Also note that the common-hci-module is only really used until the connected chip has been detected. The chip handler will then set the callback functions so actual data transmissions never pass the common-hci-module. They go directly from transport to chip handler. That is not really shown in the picture above. Just imagine that common-hci-module is removed after a chip has been connected and a chip handler has been determined. I hope I haven't misunderstood your question. I do not know much about the I2C system, but I tried to understand your question as best as I could. /P-G ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶ â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
