This patch adds a driver for the ST-Ericsson CG2900 connectivity controller.
It has earlier been tried to add this driver to the mfd and bluetooth areas,
but due to continued discussions the driver is placed into staging for the moment.
Patch created on next-20110510.
Compared to v5 this patch has the following update:
- Updated driver after changes to MFD interfaces in linux-next (from mfd_data
to platform_data).
- Changed platform specific file dependencies (included correct nomadik file).
Par-Gunnar Hjalmdahl (1):
staging: Add ST-Ericsson CG2900 driver
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 1 +
drivers/staging/cg2900/Kconfig | 70 +
drivers/staging/cg2900/Makefile | 12 +
drivers/staging/cg2900/TODO | 23 +
drivers/staging/cg2900/bluetooth/Makefile | 9 +
drivers/staging/cg2900/bluetooth/btcg2900.c | 1209 ++++++++
drivers/staging/cg2900/bluetooth/cg2900_uart.c | 2074 +++++++++++++
drivers/staging/cg2900/bluetooth/hci_ldisc.c | 657 ++++
drivers/staging/cg2900/bluetooth/hci_uart.h | 105 +
drivers/staging/cg2900/board-mop500-cg2900.c | 202 ++
drivers/staging/cg2900/devices-cg2900.c | 342 +++
drivers/staging/cg2900/devices-cg2900.h | 31 +
drivers/staging/cg2900/include/cg2900.h | 278 ++
drivers/staging/cg2900/include/cg2900_audio.h | 473 +++
drivers/staging/cg2900/include/cg2900_hci.h | 19 +
drivers/staging/cg2900/mfd/Makefile | 18 +
drivers/staging/cg2900/mfd/cg2900_audio.c | 3462 ++++++++++++++++++++++
drivers/staging/cg2900/mfd/cg2900_char_devices.c | 707 +++++
drivers/staging/cg2900/mfd/cg2900_chip.c | 3415 +++++++++++++++++++++
drivers/staging/cg2900/mfd/cg2900_chip.h | 613 ++++
drivers/staging/cg2900/mfd/cg2900_core.c | 713 +++++
drivers/staging/cg2900/mfd/cg2900_core.h | 51 +
drivers/staging/cg2900/mfd/cg2900_lib.c | 281 ++
drivers/staging/cg2900/mfd/cg2900_lib.h | 61 +
drivers/staging/cg2900/mfd/cg2900_test.c | 402 +++
drivers/staging/cg2900/mfd/stlc2690_chip.c | 1653 +++++++++++
drivers/staging/cg2900/mfd/stlc2690_chip.h | 47 +
28 files changed, 16930 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/cg2900/Kconfig
create mode 100644 drivers/staging/cg2900/Makefile
create mode 100644 drivers/staging/cg2900/TODO
create mode 100644 drivers/staging/cg2900/bluetooth/Makefile
create mode 100644 drivers/staging/cg2900/bluetooth/btcg2900.c
create mode 100644 drivers/staging/cg2900/bluetooth/cg2900_uart.c
create mode 100644 drivers/staging/cg2900/bluetooth/hci_ldisc.c
create mode 100644 drivers/staging/cg2900/bluetooth/hci_uart.h
create mode 100644 drivers/staging/cg2900/board-mop500-cg2900.c
create mode 100644 drivers/staging/cg2900/devices-cg2900.c
create mode 100644 drivers/staging/cg2900/devices-cg2900.h
create mode 100644 drivers/staging/cg2900/include/cg2900.h
create mode 100644 drivers/staging/cg2900/include/cg2900_audio.h
create mode 100644 drivers/staging/cg2900/include/cg2900_hci.h
create mode 100644 drivers/staging/cg2900/mfd/Makefile
create mode 100644 drivers/staging/cg2900/mfd/cg2900_audio.c
create mode 100644 drivers/staging/cg2900/mfd/cg2900_char_devices.c
create mode 100644 drivers/staging/cg2900/mfd/cg2900_chip.c
create mode 100644 drivers/staging/cg2900/mfd/cg2900_chip.h
create mode 100644 drivers/staging/cg2900/mfd/cg2900_core.c
create mode 100644 drivers/staging/cg2900/mfd/cg2900_core.h
create mode 100644 drivers/staging/cg2900/mfd/cg2900_lib.c
create mode 100644 drivers/staging/cg2900/mfd/cg2900_lib.h
create mode 100644 drivers/staging/cg2900/mfd/cg2900_test.c
create mode 100644 drivers/staging/cg2900/mfd/stlc2690_chip.c
create mode 100644 drivers/staging/cg2900/mfd/stlc2690_chip.h
--
1.7.4.3
2011/5/10 Par-Gunnar Hjalmdahl <[email protected]>:
> Patch created on next-20110510.
> Compared to v5 this patch has the following update:
> ?- Updated driver after changes to MFD interfaces in linux-next (from mfd_data
> ? to platform_data).
> ?- Changed platform specific file dependencies (included correct nomadik file).
Sorry I don't know if all this will work, it's due to all the churn created by
the current push to get stuff out of the ARM tree so not much to do.
The Nomadik GPIO file was moved in next but I will take that code move
out today, because the GPIO maintainer has told me he couldn't
provide feedback on these patches in time for me to finalize the change
for kernel 2.6.40. Thus it won't go into 2.6.40 and I must remove it
from next.
The MFD changes will *probably* happen, if you're thinking about the
PRCMU movement etc.
To merge into the staging tree right now, you need to base it off
Gregs staging tree, which is where it'll be merged:
http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-2.6.git;a=summary
Sorry about all the confusion, I think it's actually nobodys fault,
it's just reflecting the fact that embedded drivers with deep
platform dependencies are *really* *hard* to manage in staging.
It works best for things like a standard-form driver on a local bus
(I2C, PCI, USB ...) without any bindings to a lot of platform stuff.
Maybe the device tree will fix all this. Sometime.
Yours,
Linus Walleij
On Sun, May 15, 2011 at 12:20:51PM +0200, Linus Walleij wrote:
> 2011/5/10 Par-Gunnar Hjalmdahl <[email protected]>:
>
> > Patch created on next-20110510.
> > Compared to v5 this patch has the following update:
> > ?- Updated driver after changes to MFD interfaces in linux-next (from mfd_data
> > ? to platform_data).
> > ?- Changed platform specific file dependencies (included correct nomadik file).
>
> Sorry I don't know if all this will work, it's due to all the churn created by
> the current push to get stuff out of the ARM tree so not much to do.
>
> The Nomadik GPIO file was moved in next but I will take that code move
> out today, because the GPIO maintainer has told me he couldn't
> provide feedback on these patches in time for me to finalize the change
> for kernel 2.6.40. Thus it won't go into 2.6.40 and I must remove it
> from next.
>
> The MFD changes will *probably* happen, if you're thinking about the
> PRCMU movement etc.
>
> To merge into the staging tree right now, you need to base it off
> Gregs staging tree, which is where it'll be merged:
> http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-2.6.git;a=summary
>
> Sorry about all the confusion, I think it's actually nobodys fault,
> it's just reflecting the fact that embedded drivers with deep
> platform dependencies are *really* *hard* to manage in staging.
That's why you should only use staging as a last resort, not as your
primary way of getting code into the kernel, especially for stuff with
a constantly changing in-kernel interface like you have pointed out
here.
Just do the "real work" first and get it merged the real way if at all
possible.
best of luck,
greg k-h
2011/5/15 Greg KH <[email protected]>:
> That's why you should only use staging as a last resort, not as your
> primary way of getting code into the kernel, especially for stuff with
> a constantly changing in-kernel interface like you have pointed out
> here.
Agree 100%
Trust me, we tried this already.
> Just do the "real work" first and get it merged the real way if at all
> possible.
This driver development has gone into statis due to conflicts and
endless discussions pertaining to the HCI transport layer
beneath it.
It was my recommendation to put it into staging, by doing this
people can talk about the architecture by submitting *patches*
to show how they want it instead of these fruitless discussions.
So this should be a case where staging really helps, at least in
my dreams.
Linus Walleij
On Sun, May 15, 2011 at 07:29:04PM +0200, Linus Walleij wrote:
> It was my recommendation to put it into staging, by doing this
> people can talk about the architecture by submitting *patches*
> to show how they want it instead of these fruitless discussions.
>
> So this should be a case where staging really helps, at least in
> my dreams.
Yes, that is where staging should help, hopefully we can get these build
dependancies worked out to get this merged properly. Perhaps for the
.41 merge window?
thanks,
greg k-h
2011/5/15 Greg KH <[email protected]>:
> On Sun, May 15, 2011 at 07:29:04PM +0200, Linus Walleij wrote:
>> It was my recommendation to put it into staging, by doing this
>> people can talk about the architecture by submitting *patches*
>> to show how they want it instead of these fruitless discussions.
>>
>> So this should be a case where staging really helps, at least in
>> my dreams.
>
> Yes, that is where staging should help, hopefully we can get these build
> dependancies worked out to get this merged properly. ?Perhaps for the
> .41 merge window?
Since one of the build dependencies is the GPIO rework that already
needed to be pushed from 2.6.40 to 2.6.41 due to shortage of
review power for drivers/gpio, and since I cannot merge the updates
to the current GPIO driver in arch/arm/plat-nomadik/gpio.c due to
the current ban on anything that grows arch/arm/* we will likely
have to postpone its merging to staging to 2.6.42.
Basically this driver has ended up in cross-subsystem dependency
hell :-)
But worse things have happened, and these are special times,
so let's let it rest for a while.
Linus Walleij