RE: [PATCH] pwm: ab8500: Fix trivial typo in dev_err message
> Signed-off-by: Axel Lin Acked-by: Arun Murthy Thanks and Regards, Arun R Murthy --
RE: [PATCH 02/25] ab8500_charger: don't use [delayed_]work_pending()
> > There's no need to test whether a (delayed) work item in pending > > before queueing, flushing or cancelling it. Most uses are unnecessary > > and quite a few of them are buggy. > > > > Remove unnecessary pending tests from ab8500_charger. Only compile > > tested. > > > > Signed-off-by: Tejun Heo > > Cc: Srinidhi Kasagar > > Cc: Linus Walleij Acked-By: Arun Murthy Thanks and Regards, Arun R Murthy -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] power/ab8500_charger: Use devm_regulator_get API
> devm_regulator_get() is device managed and makes error handling and code > cleanup simpler. > > Cc: Arun R Murthy > Signed-off-by: Sachin Kamat > --- > Compile tested using linux-next. > --- > drivers/power/ab8500_charger.c | 11 +++ > 1 files changed, 3 insertions(+), 8 deletions(-) > Acked-by: Arun Murthy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv5 1/4] modem_shm: Add Modem Access Framework
> On Mon, Oct 15, 2012 at 10:58:37AM +0530, Arun Murthy wrote:
>
> I'm going to ignore your .c logic, as there are things in it that I don't
> think is
> correct. But it all comes down to your data structures, if you fix them, then
> the .c logic will become correct:
>
> > --- /dev/null
> > +++ b/include/linux/modem_shm/modem.h
> > @@ -0,0 +1,59 @@
> > +/*
> > + * Copyright (C) ST-Ericsson SA 2011
> > + *
> > + * License Terms: GNU General Public License v2
> > + * Author: Kumar Sanghvi
> > + * Arun Murthy
> > + *
> > + * Heavily adapted from Regulator framework */ #ifndef __MODEM_H__
> > +#define __MODEM_H__
>
> __MODEM_SHM_MODEM_H__, right?
>
Done!
> > +
> > +#include
> > +
> > +struct clients {
> > + struct device *dev;
>
> Why is this a pointer? It should be embedded in the structure.
This is the pointer to the clients's device structure. There will be a
single entity for a modem but multiple clients. Hence this struct is
specific for each client.
>
> > + const char *name;
>
> Why is this needed? It should be the same as the device, right?
Ok, will remove this.
>
> > + atomic_t cnt;
>
> Why is this needed at all? And if it's needed, why is it an atomic?
> (hint, your use of atomic_t really isn't correct at all in this patch, it's
> not doing
> what you think it is doing...)
Basically the operation done by this, i.e modem access/release has a lot of
affect on the clients. Since we are accesing some modem registers without
this modem request it might lead to system freeze. Hence such cross over
scenarios are considered and the counter is increased/decreased after the
operation(modem access/release). And reading of these variable are done
especially during system suspend, where decision is taken based on the value
of the counter read, hence any modification done should preside over read.
Moreover since there are multiple clients, using atomic for a simple locking
mechanism.
>
> > +};
>
> Also, the name of the structure here is _VERY_ generic, that's not acceptable
> in the global kernel namespace. Hint, it probably isn't even needed to be
> defined in this .h file at all, right?
Yes, even I felt so yest while reviewing, will change it accordingly.
>
> > +
> > +struct modem_desc {
> > + int (*request)(struct modem_desc *);
> > + void (*release)(struct modem_desc *);
> > + int (*is_requested)(struct modem_desc *);
> > + struct clients *mclients;
>
> Why do you have a pointer to a device, and yet:
This pointer to device is for the clients device.
>
> > + struct device *dev;
>
> have a device here?
This pointer to device is the modem's device struct.
>
> > + char *name;
>
> Same *dev and name comment as above.
Ok will remove this.
>
> > + u8 no_clients;
> > + atomic_t use_cnt;
> > + atomic_t cli_cnt;
>
> Same question about these atomic_t variables, why are they here, and most
> importantly, why are they an atomic variable?
Explained above.
Thanks and Regards,
Arun R Murthy
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 0/4] modem_shm: U8500 SHaRed Memory driver(SHRM)
In u8500 platform the communication between the APE(Application Processor) and the modem subsystem(CMT) is by means of a shared DDR. The series of patches include a protocol called ShaRed Memory(SHRM) protocol for communicating between the APE and the CMT. Interrupt generation registers in CMT and PRCMU on APE side are used to support the shrm protocol. v2 - Included netdev mailing list v3 - Implemented comments from Alan Cox and Greg KH v4 - Re-worked on the ModemAccessFramework(MAF) part v5 - Added kernel doc for exported functions in MAF. Arun Murthy (4): modem_shm: Add Modem Access Framework modem_shm: Register u8500 client for MAF modem_shm: u8500-shm: U8500 Shared Memory Driver Doc: Add u8500_shrm document Documentation/DocBook/Makefile |2 +- Documentation/DocBook/shrm.tmpl | 125 +++ Documentation/modem_shm/u8500_shrm.txt | 254 + drivers/Kconfig |2 + drivers/Makefile|1 + drivers/modem_shm/Kconfig | 22 + drivers/modem_shm/Makefile |3 + drivers/modem_shm/modem_access.c| 413 +++ drivers/modem_shm/modem_u8500.c | 96 ++ drivers/modem_shm/u8500_shm/Kconfig | 43 + drivers/modem_shm/u8500_shm/Makefile|7 + drivers/modem_shm/u8500_shm/shrm.h | 23 + drivers/modem_shm/u8500_shm/shrm_char.c | 816 ++ drivers/modem_shm/u8500_shm/shrm_config.h | 114 ++ drivers/modem_shm/u8500_shm/shrm_driver.c | 733 drivers/modem_shm/u8500_shm/shrm_driver.h | 226 drivers/modem_shm/u8500_shm/shrm_fifo.c | 838 ++ drivers/modem_shm/u8500_shm/shrm_ioctl.h| 43 + drivers/modem_shm/u8500_shm/shrm_net.c | 313 ++ drivers/modem_shm/u8500_shm/shrm_net.h | 46 + drivers/modem_shm/u8500_shm/shrm_private.h | 184 +++ drivers/modem_shm/u8500_shm/shrm_protocol.c | 1591 +++ include/linux/modem_shm/modem.h | 64 ++ include/linux/modem_shm/modem_client.h | 55 + 24 files changed, 6013 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/shrm.tmpl create mode 100644 Documentation/modem_shm/u8500_shrm.txt create mode 100644 drivers/modem_shm/Kconfig create mode 100644 drivers/modem_shm/Makefile create mode 100644 drivers/modem_shm/modem_access.c create mode 100644 drivers/modem_shm/modem_u8500.c create mode 100644 drivers/modem_shm/u8500_shm/Kconfig create mode 100644 drivers/modem_shm/u8500_shm/Makefile create mode 100644 drivers/modem_shm/u8500_shm/shrm.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_char.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_config.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_driver.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_driver.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_fifo.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_ioctl.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_net.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_net.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_private.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_protocol.c create mode 100644 include/linux/modem_shm/modem.h create mode 100644 include/linux/modem_shm/modem_client.h -- 1.7.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 1/4] modem_shm: Add Modem Access Framework
Adds Modem Access Framework, which allows for registering platform specific
modem access mechanisms. The framework also exposes APIs for client drivers
for getting and releasing access to modem, regardless of the underlying
platform specific access mechanism.
Signed-off-by: Arun Murthy
---
drivers/Kconfig |2 +
drivers/Makefile |1 +
drivers/modem_shm/Kconfig|9 ++
drivers/modem_shm/Makefile |1 +
drivers/modem_shm/modem_access.c | 226 ++
include/linux/modem_shm/modem.h | 59 ++
6 files changed, 298 insertions(+), 0 deletions(-)
create mode 100644 drivers/modem_shm/Kconfig
create mode 100644 drivers/modem_shm/Makefile
create mode 100644 drivers/modem_shm/modem_access.c
create mode 100644 include/linux/modem_shm/modem.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ece958d..dc7c14a 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -152,4 +152,6 @@ source "drivers/vme/Kconfig"
source "drivers/pwm/Kconfig"
+source "drivers/modem_shm/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 5b42184..902dfec 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -139,3 +139,4 @@ obj-$(CONFIG_EXTCON)+= extcon/
obj-$(CONFIG_MEMORY) += memory/
obj-$(CONFIG_IIO) += iio/
obj-$(CONFIG_VME_BUS) += vme/
+obj-$(CONFIG_MODEM_SHM)+= modem_shm/
diff --git a/drivers/modem_shm/Kconfig b/drivers/modem_shm/Kconfig
new file mode 100644
index 000..f4b7e54
--- /dev/null
+++ b/drivers/modem_shm/Kconfig
@@ -0,0 +1,9 @@
+config MODEM_SHM
+bool "Modem Access Framework"
+default n
+help
+ Add support for Modem Access Framework. It allows different
+platform specific drivers to register modem access mechanisms
+and allows transparent access to modem to the client drivers.
+
+If unsure, say N.
diff --git a/drivers/modem_shm/Makefile b/drivers/modem_shm/Makefile
new file mode 100644
index 000..b77bcc0
--- /dev/null
+++ b/drivers/modem_shm/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MODEM_SHM):= modem_access.o
diff --git a/drivers/modem_shm/modem_access.c b/drivers/modem_shm/modem_access.c
new file mode 100644
index 000..e06c51a
--- /dev/null
+++ b/drivers/modem_shm/modem_access.c
@@ -0,0 +1,226 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Kumar Sanghvi
+ * Arun Murthy
+ *
+ * Heavily adapted from Regulator framework.
+ * Provides mechanisms for registering platform specific access
+ * mechanisms for modem.
+ * Also, exposes APIs for gettng/releasing the access and even
+ * query the access status, and the modem usage status.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static struct class *modem_class;
+
+static int __modem_get_usage(struct device *dev, void *data)
+{
+ struct modem_desc *mdesc = (struct modem_desc *)data;
+
+ if (!mdesc->mclients) {
+ printk(KERN_ERR "modem_access: modem description is NULL\n");
+ return 0;
+ }
+ return atomic_read(&mdesc->mclients->cnt);
+}
+
+/**
+ * modem_is_requested - check if modem access to APE is already enabled
+ * @mdesc: pointer to the struct modem_desc
+ *
+ * check if any of the client on ape has requested access to modem
+ * and return non-zero on success and zero on failure.
+ */
+int modem_get_usage(struct modem_desc *mdesc)
+{
+ return class_for_each_device(modem_class, NULL, (void *)mdesc,
__modem_get_usage);
+}
+
+/**
+ * modem_is_requested - check if modem access to APE is already enabled
+ * @mdesc: pointer to the struct modem_desc
+ *
+ * check for a particular client if ape has requested access to modem
+ * and return non-zero on success and zero on failure.
+ */
+int modem_is_requested(struct modem_desc *mdesc)
+{
+ return atomic_read(&mdesc->mclients->cnt);
+}
+
+/**
+ * modem_release - disable modem access for APE
+ * @mdesc: pointer to the struct modem_desc
+ *
+ * disable modem access to the APE. For a particluar client it checks if modem
+ * has already been releases and if so returns else will call the platform
+ * specific function to disable access to modem.
+ */
+int modem_release(struct modem_desc *mdesc)
+{
+ if (!mdesc->release)
+ return -EFAULT;
+
+ if (modem_is_requested(mdesc)) {
+ atomic_dec(&mdesc->mclients->cnt);
+ if (atomic_read(&mdesc->use_cnt) == 1) {
+ mdesc->release(mdesc);
+ atomic_dec(&mdesc->use_cnt);
+ }
+ } else
+ printk(KERN_WARNING
+ "modem_shm: client %s has not requested modem to
release\n",
+ mdesc->mcl
[PATCHv5 4/4] Doc: Add u8500_shrm document
Add document for u8500 shared memory(shrm)and kernel Docbook. Signed-off-by: Arun Murthy --- Documentation/DocBook/Makefile |2 +- Documentation/DocBook/shrm.tmpl| 125 Documentation/modem_shm/u8500_shrm.txt | 254 3 files changed, 380 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/shrm.tmpl create mode 100644 Documentation/modem_shm/u8500_shrm.txt diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index bc3d9f8..673ea06 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml + tracepoint.xml drm.xml media_api.xml shrm.xml include $(srctree)/Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/shrm.tmpl b/Documentation/DocBook/shrm.tmpl new file mode 100644 index 000..400f9b2 --- /dev/null +++ b/Documentation/DocBook/shrm.tmpl @@ -0,0 +1,125 @@ + +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> + + + + Shared Memory + + +Arun + Murthy + + + arun.mur...@stericsson.com + + + + + + + 2009-2010 + ST-Ericsson + + + + + Linux standard functions + + + + + + + Licence terms: GNU General Public Licence (GPL) version 2. + + + + + + +Introduction + + This Documentation describes the ST-Ericsson's adaptation on protocol used for CMT/APE communication when SHaRedMemory is used as IPC link. + + + + +Design + + The APE consists Cortex A9 dual core SMP, a multimedia DSP and PRCMU. Modem consists of 2 Cortex R4 ARM processor. + The exchange of messages between CMT(Cellular Mobile Terminal) and APE includes copying the data to a shared area DDR. + This region is accessible by both CMT and APE. The design includes 2 channels common and audio. Common channel is used for exchanging ISI, RPC and SECURITY messages. + udio channel is used for exchanging AUDIO messages. Each channel consists of 2 FIFO. One FIFO for sending message from CMT to APE and other from APE to CMT. + ach of these FIFO have write and read pointer shared between APE and CMT. Writer pointer is updated on copying the message to FIFO and reader will read the messages from the read pointer upto the writer pointer. Writer and reader notifications are used to notify the completion of read/write operation(seperate for APE and CMT). + river includes 4 queues. Once the messages are sent from CMT to APE it resides in the FIFO and then copied to one of the 4 queues based on the message type(ISI, RPC, AUDIO, SECURITY) and then the net/char device interface fetches this message from the queue and copies to the user space buffer. + + + + +Concepts + + The user space application sends ISI/RPC/AUDIO/SECURITY messages. ISI is sent through the phonet to shrm driver. For achieving this there are 2 interfaces to the shrm driver. Net interface used for exchanging the ISI message and char interface for RPC, AUDIO and SECURITY messages. On receiving any of these messages from the user space application, it is copied to a memory in kernel space. From here it is then copied to respective FIFO from where the CMT reads the message. + CMT(Cellular Mobile Terminal) writes messages to the respective FIFO and thereafter to respective queue. The net/char device copies this message from the queue to the user space buffer. + + + + + Known Bugs And Assumptions + + + + None + + + Assumptions + 1. ApeShmFifo#0 is of 128kB in size. As this is used for transmission except CS audio call data. Expected message size is 1.5kB with a max of 16kB. + 2. ApeShmFifo#1 is of 4kB in size. This is used for transmission of CS audio call data. Expected message size is 24kb. + 3. CmtShmFifo#0 is of 128kB in size. As this is used for transmission except CS audio call data. Expected message size is 1.5kB with a max of 16kB. + 4. CmtShmFifo#1 is of 4kB in size. This is used for transmission of CS audio call data. Expected message size is 24kb. + The total size of the FIFO is 264 kB. + + + + + + + + + Public Functions Provided + + This Section lists the API's provided by the SHRM driver to phonet drivers. + +!Edrivers/modem_shm/u8500_shm/shrm_fifo.c + + This Section lists the API's provided by the SHRM driver used in transmission of RPC, AUDIO and SECURITY messages. + +!Edrivers/modem_sh
[PATCHv5 2/4] modem_shm: Register u8500 client for MAF
Register with Modem Access Framework(MAF) for u8500 platform. This will provide
interface to enable and disable modem access and also provide the status.
Signed-off-by: Arun Murthy
---
drivers/modem_shm/Kconfig | 11 +
drivers/modem_shm/Makefile |1 +
drivers/modem_shm/modem_u8500.c | 91 +++
3 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 drivers/modem_shm/modem_u8500.c
diff --git a/drivers/modem_shm/Kconfig b/drivers/modem_shm/Kconfig
index f4b7e54..f59d3dc 100644
--- a/drivers/modem_shm/Kconfig
+++ b/drivers/modem_shm/Kconfig
@@ -7,3 +7,14 @@ config MODEM_SHM
and allows transparent access to modem to the client drivers.
If unsure, say N.
+
+config MODEM_U8500
+ bool "Modem Access driver for STE U8500 platform"
+ depends on MODEM_SHM
+ default n
+ help
+Add support for Modem Access driver on STE U8500 platform which
+uses Shared Memroy as IPC mechanism between Modem processor and
+Application processor.
+
+If unsure, say N.
diff --git a/drivers/modem_shm/Makefile b/drivers/modem_shm/Makefile
index b77bcc0..a9aac0f 100644
--- a/drivers/modem_shm/Makefile
+++ b/drivers/modem_shm/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_MODEM_SHM):= modem_access.o
+obj-$(CONFIG_MODEM_U8500) += modem_u8500.o
diff --git a/drivers/modem_shm/modem_u8500.c b/drivers/modem_shm/modem_u8500.c
new file mode 100644
index 000..924b6a2
--- /dev/null
+++ b/drivers/modem_shm/modem_u8500.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Kumar Sanghvi
+ * Arun Murthy
+ *
+ * Platform driver implementing access mechanisms to modem
+ * on U8500 which uses Shared Memroy as IPC between Application
+ * Processor and Modem processor.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int u8500_modem_request(struct modem_desc *mdesc)
+{
+ return prcmu_ac_wake_req();
+}
+
+static void u8500_modem_release(struct modem_desc *mdesc)
+{
+ prcmu_ac_sleep_req();
+}
+
+static int u8500_modem_is_requested(struct modem_desc *mdesc)
+{
+ return prcmu_is_ac_wake_requested();
+}
+
+static struct modem_desc u8500_modem_desc = {
+ .request = u8500_modem_request,
+ .release = u8500_modem_release,
+ .is_requested = u8500_modem_is_requested,
+ .name = "u8500-shrm-modem",
+ .no_clients = 2,
+ .cli_cnt = ATOMIC_INIT(0),
+ .use_cnt = ATOMIC_INIT(0),
+};
+
+static int __devinit u8500_modem_probe(struct platform_device *pdev)
+{
+ int err = 0;
+
+ u8500_modem_desc.dev = &pdev->dev;
+ err = modem_register(&pdev->dev, &u8500_modem_desc);
+ if (err) {
+ pr_err("failed to register %s: err %i\n",
+ u8500_modem_desc.name, err);
+ }
+
+ return err;
+}
+
+static int __devexit u8500_modem_remove(struct platform_device *pdev)
+{
+ modem_unregister(&u8500_modem_desc);
+ return 0;
+}
+
+static struct platform_driver u8500_modem_driver = {
+ .driver = {
+ .name = "u8500-modem",
+ .owner = THIS_MODULE,
+ },
+ .probe = u8500_modem_probe,
+ .remove = __devexit_p(u8500_modem_remove),
+};
+
+static int __init u8500_modem_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&u8500_modem_driver);
+ if (ret < 0) {
+ printk(KERN_ERR "u8500_modem: platform driver reg failed\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void __exit u8500_modem_exit(void)
+{
+ platform_driver_unregister(&u8500_modem_driver);
+}
+
+arch_initcall(u8500_modem_init);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
> On Tue, Oct 09, 2012 at 07:37:02AM +0200, Arun MURTHY wrote: > > Any further comments? > > I was waiting for you to address all of the previous ones with a new set of > patches before burdening you with anything new :) There are not any changes in the code, this review was more like just explaining our platform, protocol, few terminology and design approach. Thanks and Regards, Arun R Murthy -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
> > On Wed, Oct 03, 2012 at 05:54:08AM +0200, Arun MURTHY wrote:
> > > > On Mon, Oct 01, 2012 at 07:30:38AM +0200, Arun MURTHY wrote:
> > > > > > On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +
> > > > > > > +static struct class *modem_class;
> > > > > >
> > > > > > What's wrong with a bus_type instead?
> > > > >
> > > > > Can I know the advantage of using bus_type over class?
> > > >
> > > > You have devices living on a bus, and it's much more descriptive
> > > > than a class (which we are going to eventually get rid of one of
> > > > these
> > days...).
> > > >
> > > > Might I ask why you choose a class over a bus_type?
> > >
> > > Basically my requirement is to create a central entity for accessing
> > > and releasing modem from APE.
> >
> > What is an "APE"?
> >
> > And what do you mean by "accessing" and "releasing"?
>
> APE - Application Processor Engine
> There are two processors but on a single chip, one being the APE and other is
> the modem. So 'accessing' means requesting access or waking-up the co-
> processor and releasing means allowing the co-processor to sleep.
>
>
> >
> > > Since this is done by different clients the central entity should be
> > > able to handle the request and play safely, since this has more
> > > affect in system suspend and deep sleep. Using class helps me in
> > > achieving this and also create an entry to user space which can be
> > > used in the later parts. Moreover this not something like a bus or
> > > so, so I didn't use bus instead went with a simple class approach.
> >
> > But as you have devices that are "binding" to this "controller", a bus
> > might make more sense, right?
>
> Have explained above regarding the platform, the concept of bus doesn't
> come into picture at all. Here its just waking-up the modem and allowing it to
> go to sleep.
>
> >
> > I don't see how a class helps out for you here more than anything
> > else, what are you expecting from the class interface? You aren't
> > using the reference counting logic it provides, so why use it at all?
>
> I am using the reference counting logic in class such as
> class_for_each_device.
>
> >
> > Actually, why use the driver core at all in the first place if you
> > aren't needing the devices to show up in sysfs (as you don't have a
> > device, you are just a mediator)?
>
> Yes I am something like a mediator, but since this is associated with many
> clients, there should be some central entity to take inputs from all the
> clients
> and act accordingly. This MAF does that. Sysfs will also be created for this
> MAF in the coming versions.
>
> >
> > > > > > > +int modem_release(struct modem_desc *mdesc) {
> > > > > > > + if (!mdesc->release)
> > > > > > > + return -EFAULT;
> > > > > > > +
> > > > > > > + if (modem_is_requested(mdesc)) {
> > > > > > > + atomic_dec(&mdesc->mclients->cnt);
> > > > > > > + if (atomic_read(&mdesc->use_cnt) == 1) {
> > > > > > > + mdesc->release(mdesc);
> > > > > > > + atomic_dec(&mdesc->use_cnt);
> > > > > > > + }
> > > > > >
> > > > > > Eeek, why aren't you using the built-in reference counting
> > > > > > that the struct device provided to you, and instead are rolling your
> own?
> > > > > > This happens in many places, why?
> > > > >
> > > > > My usage of counters over here is for each modem there are many
> > clients.
> > > > > Each of the clients will have a ref to modem_desc. Each of them
> > > > > use this for requesting and releasing the modem. One counter for
> > > > > tracking the request and release for each client which is done
> > > > > by variable 'cnt' in
> > > > struct clients.
> > > > >
RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
> On Wed, Oct 03, 2012 at 05:54:08AM +0200, Arun MURTHY wrote:
> > > On Mon, Oct 01, 2012 at 07:30:38AM +0200, Arun MURTHY wrote:
> > > > > On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +
> > > > > > +static struct class *modem_class;
> > > > >
> > > > > What's wrong with a bus_type instead?
> > > >
> > > > Can I know the advantage of using bus_type over class?
> > >
> > > You have devices living on a bus, and it's much more descriptive
> > > than a class (which we are going to eventually get rid of one of these
> days...).
> > >
> > > Might I ask why you choose a class over a bus_type?
> >
> > Basically my requirement is to create a central entity for accessing
> > and releasing modem from APE.
>
> What is an "APE"?
>
> And what do you mean by "accessing" and "releasing"?
APE - Application Processor Engine
There are two processors but on a single chip, one being the APE and other
is the modem. So 'accessing' means requesting access or waking-up the
co-processor and releasing means allowing the co-processor to sleep.
>
> > Since this is done by different clients the central entity should be
> > able to handle the request and play safely, since this has more affect
> > in system suspend and deep sleep. Using class helps me in achieving
> > this and also create an entry to user space which can be used in the
> > later parts. Moreover this not something like a bus or so, so I didn't
> > use bus instead went with a simple class approach.
>
> But as you have devices that are "binding" to this "controller", a bus might
> make more sense, right?
Have explained above regarding the platform, the concept of bus doesn't
come into picture at all. Here its just waking-up the modem and allowing
it to go to sleep.
>
> I don't see how a class helps out for you here more than anything else, what
> are you expecting from the class interface? You aren't using the reference
> counting logic it provides, so why use it at all?
I am using the reference counting logic in class such as class_for_each_device.
>
> Actually, why use the driver core at all in the first place if you aren't
> needing
> the devices to show up in sysfs (as you don't have a device, you are just a
> mediator)?
Yes I am something like a mediator, but since this is associated with many
clients, there should be some central entity to take inputs from all the clients
and act accordingly. This MAF does that. Sysfs will also be created for this
MAF in the coming versions.
>
> > > > > > +int modem_release(struct modem_desc *mdesc) {
> > > > > > + if (!mdesc->release)
> > > > > > + return -EFAULT;
> > > > > > +
> > > > > > + if (modem_is_requested(mdesc)) {
> > > > > > + atomic_dec(&mdesc->mclients->cnt);
> > > > > > + if (atomic_read(&mdesc->use_cnt) == 1) {
> > > > > > + mdesc->release(mdesc);
> > > > > > + atomic_dec(&mdesc->use_cnt);
> > > > > > + }
> > > > >
> > > > > Eeek, why aren't you using the built-in reference counting that
> > > > > the struct device provided to you, and instead are rolling your own?
> > > > > This happens in many places, why?
> > > >
> > > > My usage of counters over here is for each modem there are many
> clients.
> > > > Each of the clients will have a ref to modem_desc. Each of them
> > > > use this for requesting and releasing the modem. One counter for
> > > > tracking the request and release for each client which is done by
> > > > variable 'cnt' in
> > > struct clients.
> > > > The counter use_cnt is used for tracking the modem request/release
> > > > irrespective of the clients and counter cli_cnt is used for
> > > > restricting the modem_get to the no of clients defined in no_clients.
> > > >
> > > > So totally 3 counter one for restricting the usage of modem_get by
> > > > clients, second for restricting modem request/release at top
> > > > level, and 3rd for restricting modem release/
RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
> On Wed, Oct 3, 2012 at 9:24 AM, Arun MURTHY
> wrote:
> >> On Mon, Oct 01, 2012 at 07:30:38AM +0200, Arun MURTHY wrote:
> >> > > On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
> >> > > > +#include
> >> > > > +#include
> >> > > > +#include
> >> > > > +#include
> >> > > > +#include
> >> > > > +
> >> > > > +static struct class *modem_class;
> >> > >
> >> > > What's wrong with a bus_type instead?
> >> >
> >> > Can I know the advantage of using bus_type over class?
> >>
> >> You have devices living on a bus, and it's much more descriptive than
> >> a class (which we are going to eventually get rid of one of these days...).
> >>
> >> Might I ask why you choose a class over a bus_type?
> >
> > Basically my requirement is to create a central entity for accessing
> > and releasing modem from APE. Since this is done by different clients
> > the central entity should be able to handle the request and play
> > safely, since this has more affect in system suspend and deep sleep.
> > Using class helps me in achieving this and also create an entry to
> > user space which can be used in the later parts. Moreover
> You can have that same mechanism work for bus_type as well.
> > this not something like a bus or so, so I didn't use bus instead went
> > with a simple class approach.
> >
> >>
> >> > > > +int modem_release(struct modem_desc *mdesc) {
> >> > > > + if (!mdesc->release)
> >> > > > + return -EFAULT;
> >> > > > +
> >> > > > + if (modem_is_requested(mdesc)) {
> >> > > > + atomic_dec(&mdesc->mclients->cnt);
> >> > > > + if (atomic_read(&mdesc->use_cnt) == 1) {
> >> > > > + mdesc->release(mdesc);
> >> > > > + atomic_dec(&mdesc->use_cnt);
> >> > > > + }
> >> > >
> >> > > Eeek, why aren't you using the built-in reference counting that
> >> > > the struct device provided to you, and instead are rolling your own?
> >> > > This happens in many places, why?
> >> >
> >> > My usage of counters over here is for each modem there are many
> clients.
> >> > Each of the clients will have a ref to modem_desc. Each of them use
> >> > this for requesting and releasing the modem. One counter for
> >> > tracking the request and release for each client which is done by
> >> > variable 'cnt' in
> >> struct clients.
> >> > The counter use_cnt is used for tracking the modem request/release
> >> > irrespective of the clients and counter cli_cnt is used for
> >> > restricting the modem_get to the no of clients defined in no_clients.
> >> >
> >> > So totally 3 counter one for restricting the usage of modem_get by
> >> > clients, second for restricting modem request/release at top level,
> >> > and 3rd for restricting modem release/request for per client per
> >> > modem
> >> basis.
> >> >
> >> > Can you let me know if the same can be achieved by using built-in
> >> > ref counting?
> >>
> >> Yes, because you don't need all of those different levels, just stick
> >> with one and you should be fine. :)
> >>
> >
> > No, checks at all these levels are required, I have briefed out the need
> > also.
> > This will have effect on system power management, i.e suspend and deep
> > sleep.
> > We restrict that the drivers should request modem only once and
> > release only once, but we cannot rely on the clients hence a check for
> > the same has to be done in the MAF. Also the no of clients should be
> > defined and hence a check for the same is done in MAF. Apart from all
> > these the requests coming from all the clients is to be accumulated
> > and based on that modem release or access should be performed, hence
> so.
> I think best way to deal with this is:
> Define a new bus type and have your clients call the bus exposed
> functionality when ever they need a service.So in your case it would be
> request and release only AND when all of your clients have released the bus
> then you can do the cleanup i.e. switch off the modem and on added
> advantage of making it a bus_type would be that you can do the reference
> counting in your bus driver.
>
> Designing is not my forte but I feel this way you can solve the problem at
> hand.
> Please feel free to correct me.I would really appreciate it.
At the very first look itself this MAF is not a bus by its technical meaning, so
why to use bus_type is the point that I have.
Thanks and Regards,
Arun R Murthy
--
RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
> On Mon, Oct 01, 2012 at 07:30:38AM +0200, Arun MURTHY wrote:
> > > On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +static struct class *modem_class;
> > >
> > > What's wrong with a bus_type instead?
> >
> > Can I know the advantage of using bus_type over class?
>
> You have devices living on a bus, and it's much more descriptive than a class
> (which we are going to eventually get rid of one of these days...).
>
> Might I ask why you choose a class over a bus_type?
Basically my requirement is to create a central entity for accessing and
releasing
modem from APE. Since this is done by different clients the central entity
should
be able to handle the request and play safely, since this has more affect in
system suspend and deep sleep. Using class helps me in achieving this and
also create an entry to user space which can be used in the later parts.
Moreover
this not something like a bus or so, so I didn't use bus instead went with a
simple class approach.
>
> > > > +int modem_release(struct modem_desc *mdesc) {
> > > > + if (!mdesc->release)
> > > > + return -EFAULT;
> > > > +
> > > > + if (modem_is_requested(mdesc)) {
> > > > + atomic_dec(&mdesc->mclients->cnt);
> > > > + if (atomic_read(&mdesc->use_cnt) == 1) {
> > > > + mdesc->release(mdesc);
> > > > + atomic_dec(&mdesc->use_cnt);
> > > > + }
> > >
> > > Eeek, why aren't you using the built-in reference counting that the
> > > struct device provided to you, and instead are rolling your own?
> > > This happens in many places, why?
> >
> > My usage of counters over here is for each modem there are many clients.
> > Each of the clients will have a ref to modem_desc. Each of them use
> > this for requesting and releasing the modem. One counter for tracking
> > the request and release for each client which is done by variable 'cnt' in
> struct clients.
> > The counter use_cnt is used for tracking the modem request/release
> > irrespective of the clients and counter cli_cnt is used for
> > restricting the modem_get to the no of clients defined in no_clients.
> >
> > So totally 3 counter one for restricting the usage of modem_get by
> > clients, second for restricting modem request/release at top level,
> > and 3rd for restricting modem release/request for per client per modem
> basis.
> >
> > Can you let me know if the same can be achieved by using built-in ref
> > counting?
>
> Yes, because you don't need all of those different levels, just stick with one
> and you should be fine. :)
>
No, checks at all these levels are required, I have briefed out the need also.
This will have effect on system power management, i.e suspend and deep
sleep.
We restrict that the drivers should request modem only once and release
only once, but we cannot rely on the clients hence a check for the same has
to be done in the MAF. Also the no of clients should be defined and hence a
check for the same is done in MAF. Apart from all these the requests coming
from all the clients is to be accumulated and based on that modem release
or access should be performed, hence so.
Thanks and Regards,
Arun R Murthy
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
> >> >> > +int modem_release(struct modem_desc *mdesc) {
> >> >> > + if (!mdesc->release)
> >> >> > + return -EFAULT;
> >> >> > +
> >> >> > + if (modem_is_requested(mdesc)) {
> >> >> > + atomic_dec(&mdesc->mclients->cnt);
> >> >> > + if (atomic_read(&mdesc->use_cnt) == 1) {
> >> >> > + mdesc->release(mdesc);
> >> >> > + atomic_dec(&mdesc->use_cnt);
> >> >> > + }
> >> >>
> >> >> Eeek, why aren't you using the built-in reference counting that
> >> >> the struct device provided to you, and instead are rolling your own?
> >> >> This happens in many places, why?
> >> >
> >> > My usage of counters over here is for each modem there are many
> clients.
> >> > Each of the clients will have a ref to modem_desc. Each of them use
> >> > this for requesting and releasing the modem. One counter for
> >> > tracking the request and release for each client which is done by
> >> > variable 'cnt' in
> >> struct clients.
> >> > The counter use_cnt is used for tracking the modem request/release
> >> > irrespective of the clients and counter cli_cnt is used for
> >> > restricting the modem_get to the no of clients defined in no_clients.
> >> >
> >> > So totally 3 counter one for restricting the usage of modem_get by
> >> > clients, second for restricting modem request/release at top level,
> >> > and 3rd for restricting modem release/request for per client per
> >> > modem
> >> basis.
> >> >
> >> > Can you let me know if the same can be achieved by using built-in
> >> > ref counting?
> >> Is this your model:
> >> You have a modem device which can be requested by many clients.This
> >> clients can register for a particular service which this modem
> >> provides and then after that if it client doesn't need this service then
> >> it will
> call un-register.
> >
> > Let me correct a bit over here:
> > There are many clients, yes correct but the operations performed are
> > only two, i.e modem request and modem release. This is something like
> > waking up the modem and let modem to sleep.
> > The traffic of this request and release is too high.
> >
> > So irrespective of the requests/releases made to the MAF framework,
> > the MAF should perform the operation request/release only once.
> >
> > So each and every time handling list consumes time.
> > Let me brief the context, this is a single chip modem and ape,
> > basically used in mobile, tablets etc. So the traffic in ape-modem
> > communication is too high and also time critical. If it bound to
> > exceed the time, or delay might end up in buffer full. That’s the reason I
> have made it as simple as possible.
>
> So let me put it this way:
>Modem Client1 Client2Client3Client4
> State turn-on request
> State no-state-change request
> State no-state-change request
> State no-state-change
> request
> State no-state-change release
> State no-state-change release
> State no-state-change release
> State turn-off
> release
>
> So eventhough all the clients have requested the modem it is being turned
> on only once and when all of them have released then it will be turned-off.
>
> In this case it makes sense to use the atomic variables to track the requests
> and release but what will happen to sysfs incase the device is released when
> the last call to release has come from client4?Won't it lead to kernel panic
> or
> some unwanted behaviour?
>
Yes, you are right, so will add a check in modem_put and modem_unregister
to check if modem is requested and if so will release first and then go ahead.
But actually clients are not suppose to call modem_put/modem_unregister
unless modem is released but yes, in MAF we can take this precaution.
Thanks and Regards,
Arun R Murthy
-
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
> On Mon, Oct 1, 2012 at 11:00 AM, Arun MURTHY
> wrote:
> >> On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
> >> > +#include
> >> > +#include
> >> > +#include
> >> > +#include
> >> > +#include
> >> > +
> >> > +static struct class *modem_class;
> >>
> >> What's wrong with a bus_type instead?
> >
> > Can I know the advantage of using bus_type over class?
> >
> >>
> >> > +static int __modem_is_requested(struct device *dev, void *data) {
> >> > + struct modem_desc *mdesc = (struct modem_desc *)data;
> >> > +
> >> > + if (!mdesc->mclients) {
> >> > + printk(KERN_ERR "modem_access: modem description is
> >> NULL\n");
> >> > + return 0;
> >> > + }
> >> > + return atomic_read(&mdesc->mclients->cnt);
> >> > +}
> >> > +
> >> > +int modem_is_requested(struct modem_desc *mdesc) {
> >> > + return class_for_each_device(modem_class, NULL, (void *)mdesc,
> >> > +__modem_is_requested); }
> >>
> >> Where is the documentation for your public api functions like this?
> >
> > Sure will include this in the next patchset.
> >
> >>
> >> > +
> >> > +int modem_release(struct modem_desc *mdesc) {
> >> > + if (!mdesc->release)
> >> > + return -EFAULT;
> >> > +
> >> > + if (modem_is_requested(mdesc)) {
> >> > + atomic_dec(&mdesc->mclients->cnt);
> >> > + if (atomic_read(&mdesc->use_cnt) == 1) {
> >> > + mdesc->release(mdesc);
> >> > + atomic_dec(&mdesc->use_cnt);
> >> > + }
> >>
> >> Eeek, why aren't you using the built-in reference counting that the
> >> struct device provided to you, and instead are rolling your own?
> >> This happens in many places, why?
> >
> > My usage of counters over here is for each modem there are many clients.
> > Each of the clients will have a ref to modem_desc. Each of them use
> > this for requesting and releasing the modem. One counter for tracking
> > the request and release for each client which is done by variable 'cnt' in
> struct clients.
> > The counter use_cnt is used for tracking the modem request/release
> > irrespective of the clients and counter cli_cnt is used for
> > restricting the modem_get to the no of clients defined in no_clients.
> >
> > So totally 3 counter one for restricting the usage of modem_get by
> > clients, second for restricting modem request/release at top level,
> > and 3rd for restricting modem release/request for per client per modem
> basis.
> >
> > Can you let me know if the same can be achieved by using built-in ref
> > counting?
> Is this your model:
> You have a modem device which can be requested by many clients.This
> clients can register for a particular service which this modem provides and
> then after that if it client doesn't need this service then it will call
> un-register.
Let me correct a bit over here:
There are many clients, yes correct but the operations performed are only two,
i.e modem request and modem release. This is something like waking up the
modem and let modem to sleep.
The traffic of this request and release is too high.
So irrespective of the requests/releases made to the MAF framework, the MAF
should perform the operation request/release only once.
So each and every time handling list consumes time.
Let me brief the context, this is a single chip modem and ape, basically used in
mobile, tablets etc. So the traffic in ape-modem communication is too high and
also time critical. If it bound to exceed the time, or delay might end up in
buffer
full. That’s the reason I have made it as simple as possible.
Thanks and Regards,
Arun R Murthy
--
RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
> On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static struct class *modem_class;
>
> What's wrong with a bus_type instead?
Can I know the advantage of using bus_type over class?
>
> > +static int __modem_is_requested(struct device *dev, void *data) {
> > + struct modem_desc *mdesc = (struct modem_desc *)data;
> > +
> > + if (!mdesc->mclients) {
> > + printk(KERN_ERR "modem_access: modem description is
> NULL\n");
> > + return 0;
> > + }
> > + return atomic_read(&mdesc->mclients->cnt);
> > +}
> > +
> > +int modem_is_requested(struct modem_desc *mdesc) {
> > + return class_for_each_device(modem_class, NULL, (void *)mdesc,
> > +__modem_is_requested); }
>
> Where is the documentation for your public api functions like this?
Sure will include this in the next patchset.
>
> > +
> > +int modem_release(struct modem_desc *mdesc) {
> > + if (!mdesc->release)
> > + return -EFAULT;
> > +
> > + if (modem_is_requested(mdesc)) {
> > + atomic_dec(&mdesc->mclients->cnt);
> > + if (atomic_read(&mdesc->use_cnt) == 1) {
> > + mdesc->release(mdesc);
> > + atomic_dec(&mdesc->use_cnt);
> > + }
>
> Eeek, why aren't you using the built-in reference counting that the struct
> device provided to you, and instead are rolling your own? This happens in
> many places, why?
My usage of counters over here is for each modem there are many clients.
Each of the clients will have a ref to modem_desc. Each of them use this for
requesting and releasing the modem. One counter for tracking the request
and release for each client which is done by variable 'cnt' in struct clients.
The counter use_cnt is used for tracking the modem request/release irrespective
of the clients and counter cli_cnt is used for restricting the modem_get to
the no of clients defined in no_clients.
So totally 3 counter one for restricting the usage of modem_get by clients,
second for restricting modem request/release at top level, and 3rd for
restricting modem release/request for per client per modem basis.
Can you let me know if the same can be achieved by using built-in ref
counting?
Thanks and Regards,
Arun R Murthy
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 1/4] modem_shm: Add Modem Access Framework
Adds Modem Access Framework, which allows for registering platform specific
modem access mechanisms. The framework also exposes APIs for client drivers
for getting and releasing access to modem, regardless of the underlying
platform specific access mechanism.
Signed-off-by: Arun Murthy
---
drivers/Kconfig |2 +
drivers/Makefile |1 +
drivers/modem_shm/Kconfig|9 ++
drivers/modem_shm/Makefile |1 +
drivers/modem_shm/modem_access.c | 161 ++
include/linux/modem_shm/modem.h | 54 +
6 files changed, 228 insertions(+), 0 deletions(-)
create mode 100644 drivers/modem_shm/Kconfig
create mode 100644 drivers/modem_shm/Makefile
create mode 100644 drivers/modem_shm/modem_access.c
create mode 100644 include/linux/modem_shm/modem.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ece958d..dc7c14a 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -152,4 +152,6 @@ source "drivers/vme/Kconfig"
source "drivers/pwm/Kconfig"
+source "drivers/modem_shm/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 5b42184..902dfec 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -139,3 +139,4 @@ obj-$(CONFIG_EXTCON)+= extcon/
obj-$(CONFIG_MEMORY) += memory/
obj-$(CONFIG_IIO) += iio/
obj-$(CONFIG_VME_BUS) += vme/
+obj-$(CONFIG_MODEM_SHM)+= modem_shm/
diff --git a/drivers/modem_shm/Kconfig b/drivers/modem_shm/Kconfig
new file mode 100644
index 000..f4b7e54
--- /dev/null
+++ b/drivers/modem_shm/Kconfig
@@ -0,0 +1,9 @@
+config MODEM_SHM
+bool "Modem Access Framework"
+default n
+help
+ Add support for Modem Access Framework. It allows different
+platform specific drivers to register modem access mechanisms
+and allows transparent access to modem to the client drivers.
+
+If unsure, say N.
diff --git a/drivers/modem_shm/Makefile b/drivers/modem_shm/Makefile
new file mode 100644
index 000..b77bcc0
--- /dev/null
+++ b/drivers/modem_shm/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MODEM_SHM):= modem_access.o
diff --git a/drivers/modem_shm/modem_access.c b/drivers/modem_shm/modem_access.c
new file mode 100644
index 000..540234d
--- /dev/null
+++ b/drivers/modem_shm/modem_access.c
@@ -0,0 +1,161 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Kumar Sanghvi
+ * Arun Murthy
+ *
+ * Heavily adapted from Regulator framework.
+ * Provides mechanisms for registering platform specific access
+ * mechanisms for modem.
+ * Also, exposes APIs for gettng/releasing the access and even
+ * query the access status, and the modem usage status.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static struct class *modem_class;
+
+static int __modem_is_requested(struct device *dev, void *data)
+{
+ struct modem_desc *mdesc = (struct modem_desc *)data;
+
+ if (!mdesc->mclients) {
+ printk(KERN_ERR "modem_access: modem description is NULL\n");
+ return 0;
+ }
+ return atomic_read(&mdesc->mclients->cnt);
+}
+
+int modem_is_requested(struct modem_desc *mdesc)
+{
+ return class_for_each_device(modem_class, NULL, (void *)mdesc,
__modem_is_requested);
+}
+
+int modem_release(struct modem_desc *mdesc)
+{
+ if (!mdesc->release)
+ return -EFAULT;
+
+ if (modem_is_requested(mdesc)) {
+ atomic_dec(&mdesc->mclients->cnt);
+ if (atomic_read(&mdesc->use_cnt) == 1) {
+ mdesc->release(mdesc);
+ atomic_dec(&mdesc->use_cnt);
+ }
+ } else
+ printk(KERN_WARNING
+ "modem_shm: client %s has not requested modem to
release\n",
+ mdesc->mclients->name);
+ return 0;
+}
+
+int modem_request(struct modem_desc *mdesc)
+{
+ if (!mdesc->request)
+ return -EFAULT;
+
+ if (atomic_read(&mdesc->mclients->cnt) == 0) {
+ mdesc->request(mdesc);
+ atomic_inc(&mdesc->mclients->cnt);
+ atomic_inc(&mdesc->use_cnt);
+ if (atomic_read(&mdesc->use_cnt) > mdesc->no_clients) {
+ dev_warn(mdesc->dev,
+ "modem_shm: mismatch in the modem
count\n");
+ }
+ } else
+ dev_warn(mdesc->dev,
+ "modem_shm: client '%s' has already requested
modem\n",
+ dev_name(mdesc->mclients->dev));
+ return 0;
+}
+
+int modem_put(struct modem_desc *mdesc)
+{
+ if (atomic_read
[PATCHv4 2/4] modem_shm: Register u8500 client for MAF
Register with Modem Access Framework(MAF) for u8500 platform. This will provide
interface to enable and disable modem access and also provide the status.
Signed-off-by: Arun Murthy
---
drivers/modem_shm/Kconfig | 11 +
drivers/modem_shm/Makefile |1 +
drivers/modem_shm/modem_u8500.c | 91 +++
3 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 drivers/modem_shm/modem_u8500.c
diff --git a/drivers/modem_shm/Kconfig b/drivers/modem_shm/Kconfig
index f4b7e54..f59d3dc 100644
--- a/drivers/modem_shm/Kconfig
+++ b/drivers/modem_shm/Kconfig
@@ -7,3 +7,14 @@ config MODEM_SHM
and allows transparent access to modem to the client drivers.
If unsure, say N.
+
+config MODEM_U8500
+ bool "Modem Access driver for STE U8500 platform"
+ depends on MODEM_SHM
+ default n
+ help
+Add support for Modem Access driver on STE U8500 platform which
+uses Shared Memroy as IPC mechanism between Modem processor and
+Application processor.
+
+If unsure, say N.
diff --git a/drivers/modem_shm/Makefile b/drivers/modem_shm/Makefile
index b77bcc0..a9aac0f 100644
--- a/drivers/modem_shm/Makefile
+++ b/drivers/modem_shm/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_MODEM_SHM):= modem_access.o
+obj-$(CONFIG_MODEM_U8500) += modem_u8500.o
diff --git a/drivers/modem_shm/modem_u8500.c b/drivers/modem_shm/modem_u8500.c
new file mode 100644
index 000..924b6a2
--- /dev/null
+++ b/drivers/modem_shm/modem_u8500.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Kumar Sanghvi
+ * Arun Murthy
+ *
+ * Platform driver implementing access mechanisms to modem
+ * on U8500 which uses Shared Memroy as IPC between Application
+ * Processor and Modem processor.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int u8500_modem_request(struct modem_desc *mdesc)
+{
+ return prcmu_ac_wake_req();
+}
+
+static void u8500_modem_release(struct modem_desc *mdesc)
+{
+ prcmu_ac_sleep_req();
+}
+
+static int u8500_modem_is_requested(struct modem_desc *mdesc)
+{
+ return prcmu_is_ac_wake_requested();
+}
+
+static struct modem_desc u8500_modem_desc = {
+ .request = u8500_modem_request,
+ .release = u8500_modem_release,
+ .is_requested = u8500_modem_is_requested,
+ .name = "u8500-shrm-modem",
+ .no_clients = 2,
+ .cli_cnt = ATOMIC_INIT(0),
+ .use_cnt = ATOMIC_INIT(0),
+};
+
+static int __devinit u8500_modem_probe(struct platform_device *pdev)
+{
+ int err = 0;
+
+ u8500_modem_desc.dev = &pdev->dev;
+ err = modem_register(&pdev->dev, &u8500_modem_desc);
+ if (err) {
+ pr_err("failed to register %s: err %i\n",
+ u8500_modem_desc.name, err);
+ }
+
+ return err;
+}
+
+static int __devexit u8500_modem_remove(struct platform_device *pdev)
+{
+ modem_unregister(&u8500_modem_desc);
+ return 0;
+}
+
+static struct platform_driver u8500_modem_driver = {
+ .driver = {
+ .name = "u8500-modem",
+ .owner = THIS_MODULE,
+ },
+ .probe = u8500_modem_probe,
+ .remove = __devexit_p(u8500_modem_remove),
+};
+
+static int __init u8500_modem_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&u8500_modem_driver);
+ if (ret < 0) {
+ printk(KERN_ERR "u8500_modem: platform driver reg failed\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void __exit u8500_modem_exit(void)
+{
+ platform_driver_unregister(&u8500_modem_driver);
+}
+
+arch_initcall(u8500_modem_init);
--
1.7.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 4/4] Doc: Add u8500_shrm document
Add document for u8500 shared memory(shrm)and kernel Docbook. Signed-off-by: Arun Murthy --- Documentation/DocBook/Makefile |2 +- Documentation/DocBook/shrm.tmpl| 125 Documentation/modem_shm/u8500_shrm.txt | 254 3 files changed, 380 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/shrm.tmpl create mode 100644 Documentation/modem_shm/u8500_shrm.txt diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index bc3d9f8..673ea06 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml + tracepoint.xml drm.xml media_api.xml shrm.xml include $(srctree)/Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/shrm.tmpl b/Documentation/DocBook/shrm.tmpl new file mode 100644 index 000..400f9b2 --- /dev/null +++ b/Documentation/DocBook/shrm.tmpl @@ -0,0 +1,125 @@ + +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> + + + + Shared Memory + + +Arun + Murthy + + + arun.mur...@stericsson.com + + + + + + + 2009-2010 + ST-Ericsson + + + + + Linux standard functions + + + + + + + Licence terms: GNU General Public Licence (GPL) version 2. + + + + + + +Introduction + + This Documentation describes the ST-Ericsson's adaptation on protocol used for CMT/APE communication when SHaRedMemory is used as IPC link. + + + + +Design + + The APE consists Cortex A9 dual core SMP, a multimedia DSP and PRCMU. Modem consists of 2 Cortex R4 ARM processor. + The exchange of messages between CMT(Cellular Mobile Terminal) and APE includes copying the data to a shared area DDR. + This region is accessible by both CMT and APE. The design includes 2 channels common and audio. Common channel is used for exchanging ISI, RPC and SECURITY messages. + udio channel is used for exchanging AUDIO messages. Each channel consists of 2 FIFO. One FIFO for sending message from CMT to APE and other from APE to CMT. + ach of these FIFO have write and read pointer shared between APE and CMT. Writer pointer is updated on copying the message to FIFO and reader will read the messages from the read pointer upto the writer pointer. Writer and reader notifications are used to notify the completion of read/write operation(seperate for APE and CMT). + river includes 4 queues. Once the messages are sent from CMT to APE it resides in the FIFO and then copied to one of the 4 queues based on the message type(ISI, RPC, AUDIO, SECURITY) and then the net/char device interface fetches this message from the queue and copies to the user space buffer. + + + + +Concepts + + The user space application sends ISI/RPC/AUDIO/SECURITY messages. ISI is sent through the phonet to shrm driver. For achieving this there are 2 interfaces to the shrm driver. Net interface used for exchanging the ISI message and char interface for RPC, AUDIO and SECURITY messages. On receiving any of these messages from the user space application, it is copied to a memory in kernel space. From here it is then copied to respective FIFO from where the CMT reads the message. + CMT(Cellular Mobile Terminal) writes messages to the respective FIFO and thereafter to respective queue. The net/char device copies this message from the queue to the user space buffer. + + + + + Known Bugs And Assumptions + + + + None + + + Assumptions + 1. ApeShmFifo#0 is of 128kB in size. As this is used for transmission except CS audio call data. Expected message size is 1.5kB with a max of 16kB. + 2. ApeShmFifo#1 is of 4kB in size. This is used for transmission of CS audio call data. Expected message size is 24kb. + 3. CmtShmFifo#0 is of 128kB in size. As this is used for transmission except CS audio call data. Expected message size is 1.5kB with a max of 16kB. + 4. CmtShmFifo#1 is of 4kB in size. This is used for transmission of CS audio call data. Expected message size is 24kb. + The total size of the FIFO is 264 kB. + + + + + + + + + Public Functions Provided + + This Section lists the API's provided by the SHRM driver to phonet drivers. + +!Edrivers/modem_shm/u8500_shm/shrm_fifo.c + + This Section lists the API's provided by the SHRM driver used in transmission of RPC, AUDIO and SECURITY messages. + +!Edrivers/modem_sh
[PATCHv4 0/4] modem_shm: U8500 SHaRed Memory driver(SHRM)
In u8500 platform the communication between the APE(Application Processor) and the modem subsystem(CMT) is by means of a shared DDR. The series of patches include a protocol called ShaRed Memory(SHRM) protocol for communicating between the APE and the CMT. Interrupt generation registers in CMT and PRCMU on APE side are used to support the shrm protocol. v2 - Included netdev mailing list v3 - Implemented comments from Alan Cox and Greg KH v4 - Re-worked on the ModemAccessFramework(MAF) part Arun Murthy (4): modem_shm: Add Modem Access Framework modem_shm: Register u8500 client for MAF modem_shm: u8500-shm: U8500 Shared Memory Driver Doc: Add u8500_shrm document Documentation/DocBook/Makefile |2 +- Documentation/DocBook/shrm.tmpl | 125 +++ Documentation/modem_shm/u8500_shrm.txt | 254 + drivers/Kconfig |2 + drivers/Makefile|1 + drivers/modem_shm/Kconfig | 22 + drivers/modem_shm/Makefile |3 + drivers/modem_shm/modem_access.c| 413 +++ drivers/modem_shm/modem_u8500.c | 96 ++ drivers/modem_shm/u8500_shm/Kconfig | 43 + drivers/modem_shm/u8500_shm/Makefile|7 + drivers/modem_shm/u8500_shm/shrm.h | 23 + drivers/modem_shm/u8500_shm/shrm_char.c | 816 ++ drivers/modem_shm/u8500_shm/shrm_config.h | 114 ++ drivers/modem_shm/u8500_shm/shrm_driver.c | 733 drivers/modem_shm/u8500_shm/shrm_driver.h | 226 drivers/modem_shm/u8500_shm/shrm_fifo.c | 838 ++ drivers/modem_shm/u8500_shm/shrm_ioctl.h| 43 + drivers/modem_shm/u8500_shm/shrm_net.c | 313 ++ drivers/modem_shm/u8500_shm/shrm_net.h | 46 + drivers/modem_shm/u8500_shm/shrm_private.h | 184 +++ drivers/modem_shm/u8500_shm/shrm_protocol.c | 1591 +++ include/linux/modem_shm/modem.h | 64 ++ include/linux/modem_shm/modem_client.h | 55 + 24 files changed, 6013 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/shrm.tmpl create mode 100644 Documentation/modem_shm/u8500_shrm.txt create mode 100644 drivers/modem_shm/Kconfig create mode 100644 drivers/modem_shm/Makefile create mode 100644 drivers/modem_shm/modem_access.c create mode 100644 drivers/modem_shm/modem_u8500.c create mode 100644 drivers/modem_shm/u8500_shm/Kconfig create mode 100644 drivers/modem_shm/u8500_shm/Makefile create mode 100644 drivers/modem_shm/u8500_shm/shrm.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_char.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_config.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_driver.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_driver.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_fifo.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_ioctl.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_net.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_net.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_private.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_protocol.c create mode 100644 include/linux/modem_shm/modem.h create mode 100644 include/linux/modem_shm/modem_client.h -- 1.7.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] drivers/crypto/ux500/cryp/cryp_core.c: fix error return code
On Mon, Sep 17, 2012 at 10:58 PM, Peter Senna Tschudin
wrote:
> From: Peter Senna Tschudin
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> //
> (
> if@p1 (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
> //
>
> Signed-off-by: Peter Senna Tschudin
Reviewed-by: Arun Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] pwm-backlight: Take over maintenance
> Signed-off-by: Thierry Reding > Cc: Arun Murthy > Cc: Matthew Garrett > Cc: Robert Morell > Cc: Dilan Lee > Cc: Axel Lin > Cc: Mark Brown > Cc: Alexandre Courbot > Cc: Sachin Kamat > Cc: Andrew Morton > --- > Andrew: As previously discussed this patch makes me the new maintainer > for the pwm-backlight driver. I contacted Richard Purdie and requested his > Acked-by for this because he's the backlight subsystem maintainer. > Unfortunately he hasn't answered yet. Looking at the commit log, every > commit in the last 2+ years has gone through your tree, which seems to be > reason enough for me to take over this driver but I still wanted to get an > Acked-by at least from you so that this doesn't look like hijacking. I've also > Cc'ed a couple of people that have done work on the driver in the past to > give them a chance to object or send their Acked-by. Acked-by: Arun Murthy I hope now the review process will be fast instead of going through Andrew's tree. All the Best! Now I think I can re-start my pwm core driver thread, since I have a maintainer for this :-) Thanks and Regards, Arun R Murthy -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] pwm: Move AB8500 PWM driver to PWM framework
> On Fri, Sep 07, 2012 at 03:22:09PM +0200, Thierry Reding wrote: > > On Mon, Sep 03, 2012 at 01:28:44PM +0200, Arun MURTHY wrote: > > > > On Sun, Sep 2, 2012 at 12:30 PM, Thierry Reding > > > > wrote: > > > > > > > > > This commit moves the driver to drivers/pwm and converts it to > > > > > the new PWM framework. > > > > > > > > > > Signed-off-by: Thierry Reding > > > > > --- > > > > > Note: I'll take this through the PWM tree, but I'd like to have > > > > > it acknowledged by a few people who know the hardware and can > > > > > actually test whether this still works. > > > > > > > > Pls include Arun on these patches, he'll know best if it'll work or not. > > > > > > > > I have one generic question: will this alter the layout of sysfs > > > > so we need to change userspace? I had such issues before when > > > > moving drivers to new busses... > > > > > > > > > > Since this pwm framework is still a set of exported functions in a > > > header file, the file architecture doesn't really matter. > > > Using this driver, either leds-pwm and backlight-pwm is used to > > > register and this is where actual registration happens(sysfs entry is > created). > > > > Hi Arun, > > > > Have you been able to verify, then, that the driver still works after > > this patch? Can I add your Acked-by as well? > > Hi Arun, > > any news on this? > > Thierry Hi Thierry, Works with certain changes in platform data which I can manage to push it later. Acked-by: Arun Murthy Thanks and Regards, Arun R Murthy -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] pwm: Move AB8500 PWM driver to PWM framework
> On Sun, Sep 2, 2012 at 12:30 PM, Thierry Reding design.de> wrote: > > > This commit moves the driver to drivers/pwm and converts it to the new > > PWM framework. > > > > Signed-off-by: Thierry Reding > > --- > > Note: I'll take this through the PWM tree, but I'd like to have it > > acknowledged by a few people who know the hardware and can actually > > test whether this still works. > > Pls include Arun on these patches, he'll know best if it'll work or not. > > I have one generic question: will this alter the layout of sysfs so we need to > change userspace? I had such issues before when moving drivers to new > busses... > Since this pwm framework is still a set of exported functions in a header file, the file architecture doesn't really matter. Using this driver, either leds-pwm and backlight-pwm is used to register and this is where actual registration happens(sysfs entry is created). Thanks and Regards, Arun R Murthy -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 0/4] modem_shm: U8500 SHaRed Memory driver(SHRM)
In u8500 platform the communication between the APE(Application Processor) and the modem subsystem(CMT) is by means of a shared DDR. The series of patches include a protocol called ShaRed Memory(SHRM) protocol for communicating between the APE and the CMT. Interrupt generation registers in CMT and PRCMU on APE side are used to support the shrm protocol. v2 - Included netdev mailing list v3 - Implemented comments from Alan Cox and Greg KH Arun Murthy (4): modem_shm: Add Modem Access Framework modem_shm: Register u8500 client for MAF modem_shm: u8500-shm: U8500 Shared Memory Driver Doc: Add u8500_shrm document Documentation/DocBook/Makefile |2 +- Documentation/DocBook/shrm.tmpl | 125 +++ Documentation/modem_shm/u8500_shrm.txt | 254 + drivers/Kconfig |2 + drivers/Makefile|1 + drivers/modem_shm/Kconfig | 22 + drivers/modem_shm/Makefile |3 + drivers/modem_shm/modem_access.c| 413 +++ drivers/modem_shm/modem_u8500.c | 96 ++ drivers/modem_shm/u8500_shm/Kconfig | 43 + drivers/modem_shm/u8500_shm/Makefile|7 + drivers/modem_shm/u8500_shm/shrm.h | 23 + drivers/modem_shm/u8500_shm/shrm_char.c | 816 ++ drivers/modem_shm/u8500_shm/shrm_config.h | 114 ++ drivers/modem_shm/u8500_shm/shrm_driver.c | 733 drivers/modem_shm/u8500_shm/shrm_driver.h | 226 drivers/modem_shm/u8500_shm/shrm_fifo.c | 838 ++ drivers/modem_shm/u8500_shm/shrm_ioctl.h| 43 + drivers/modem_shm/u8500_shm/shrm_net.c | 313 ++ drivers/modem_shm/u8500_shm/shrm_net.h | 46 + drivers/modem_shm/u8500_shm/shrm_private.h | 184 +++ drivers/modem_shm/u8500_shm/shrm_protocol.c | 1591 +++ include/linux/modem_shm/modem.h | 64 ++ include/linux/modem_shm/modem_client.h | 55 + 24 files changed, 6013 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/shrm.tmpl create mode 100644 Documentation/modem_shm/u8500_shrm.txt create mode 100644 drivers/modem_shm/Kconfig create mode 100644 drivers/modem_shm/Makefile create mode 100644 drivers/modem_shm/modem_access.c create mode 100644 drivers/modem_shm/modem_u8500.c create mode 100644 drivers/modem_shm/u8500_shm/Kconfig create mode 100644 drivers/modem_shm/u8500_shm/Makefile create mode 100644 drivers/modem_shm/u8500_shm/shrm.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_char.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_config.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_driver.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_driver.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_fifo.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_ioctl.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_net.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_net.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_private.h create mode 100644 drivers/modem_shm/u8500_shm/shrm_protocol.c create mode 100644 include/linux/modem_shm/modem.h create mode 100644 include/linux/modem_shm/modem_client.h -- 1.7.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 4/4] Doc: Add u8500_shrm document
Add document for u8500 shared memory(shrm)and kernel Docbook. Signed-off-by: Arun Murthy --- Documentation/DocBook/Makefile |2 +- Documentation/DocBook/shrm.tmpl| 125 Documentation/modem_shm/u8500_shrm.txt | 254 3 files changed, 380 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/shrm.tmpl create mode 100644 Documentation/modem_shm/u8500_shrm.txt diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index bc3d9f8..673ea06 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml + tracepoint.xml drm.xml media_api.xml shrm.xml include $(srctree)/Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/shrm.tmpl b/Documentation/DocBook/shrm.tmpl new file mode 100644 index 000..400f9b2 --- /dev/null +++ b/Documentation/DocBook/shrm.tmpl @@ -0,0 +1,125 @@ + +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> + + + + Shared Memory + + +Arun + Murthy + + + arun.mur...@stericsson.com + + + + + + + 2009-2010 + ST-Ericsson + + + + + Linux standard functions + + + + + + + Licence terms: GNU General Public Licence (GPL) version 2. + + + + + + +Introduction + + This Documentation describes the ST-Ericsson's adaptation on protocol used for CMT/APE communication when SHaRedMemory is used as IPC link. + + + + +Design + + The APE consists Cortex A9 dual core SMP, a multimedia DSP and PRCMU. Modem consists of 2 Cortex R4 ARM processor. + The exchange of messages between CMT(Cellular Mobile Terminal) and APE includes copying the data to a shared area DDR. + This region is accessible by both CMT and APE. The design includes 2 channels common and audio. Common channel is used for exchanging ISI, RPC and SECURITY messages. + udio channel is used for exchanging AUDIO messages. Each channel consists of 2 FIFO. One FIFO for sending message from CMT to APE and other from APE to CMT. + ach of these FIFO have write and read pointer shared between APE and CMT. Writer pointer is updated on copying the message to FIFO and reader will read the messages from the read pointer upto the writer pointer. Writer and reader notifications are used to notify the completion of read/write operation(seperate for APE and CMT). + river includes 4 queues. Once the messages are sent from CMT to APE it resides in the FIFO and then copied to one of the 4 queues based on the message type(ISI, RPC, AUDIO, SECURITY) and then the net/char device interface fetches this message from the queue and copies to the user space buffer. + + + + +Concepts + + The user space application sends ISI/RPC/AUDIO/SECURITY messages. ISI is sent through the phonet to shrm driver. For achieving this there are 2 interfaces to the shrm driver. Net interface used for exchanging the ISI message and char interface for RPC, AUDIO and SECURITY messages. On receiving any of these messages from the user space application, it is copied to a memory in kernel space. From here it is then copied to respective FIFO from where the CMT reads the message. + CMT(Cellular Mobile Terminal) writes messages to the respective FIFO and thereafter to respective queue. The net/char device copies this message from the queue to the user space buffer. + + + + + Known Bugs And Assumptions + + + + None + + + Assumptions + 1. ApeShmFifo#0 is of 128kB in size. As this is used for transmission except CS audio call data. Expected message size is 1.5kB with a max of 16kB. + 2. ApeShmFifo#1 is of 4kB in size. This is used for transmission of CS audio call data. Expected message size is 24kb. + 3. CmtShmFifo#0 is of 128kB in size. As this is used for transmission except CS audio call data. Expected message size is 1.5kB with a max of 16kB. + 4. CmtShmFifo#1 is of 4kB in size. This is used for transmission of CS audio call data. Expected message size is 24kb. + The total size of the FIFO is 264 kB. + + + + + + + + + Public Functions Provided + + This Section lists the API's provided by the SHRM driver to phonet drivers. + +!Edrivers/modem_shm/u8500_shm/shrm_fifo.c + + This Section lists the API's provided by the SHRM driver used in transmission of RPC, AUDIO and SECURITY messages. + +!Edrivers/modem_sh
[PATCHv3 1/4] modem_shm: Add Modem Access Framework
Adds Modem Access Framework, which allows for registering platform specific
modem access mechanisms. The framework also exposes APIs for client drivers
for getting and releasing access to modem, regardless of the underlying
platform specific access mechanism.
Signed-off-by: Arun Murthy
---
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/modem_shm/Kconfig |9 +
drivers/modem_shm/Makefile |1 +
drivers/modem_shm/modem_access.c | 413
include/linux/modem_shm/modem.h| 64 +
include/linux/modem_shm/modem_client.h | 55 +
7 files changed, 545 insertions(+), 0 deletions(-)
create mode 100644 drivers/modem_shm/Kconfig
create mode 100644 drivers/modem_shm/Makefile
create mode 100644 drivers/modem_shm/modem_access.c
create mode 100644 include/linux/modem_shm/modem.h
create mode 100644 include/linux/modem_shm/modem_client.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ece958d..dc7c14a 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -152,4 +152,6 @@ source "drivers/vme/Kconfig"
source "drivers/pwm/Kconfig"
+source "drivers/modem_shm/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 5b42184..902dfec 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -139,3 +139,4 @@ obj-$(CONFIG_EXTCON)+= extcon/
obj-$(CONFIG_MEMORY) += memory/
obj-$(CONFIG_IIO) += iio/
obj-$(CONFIG_VME_BUS) += vme/
+obj-$(CONFIG_MODEM_SHM)+= modem_shm/
diff --git a/drivers/modem_shm/Kconfig b/drivers/modem_shm/Kconfig
new file mode 100644
index 000..f4b7e54
--- /dev/null
+++ b/drivers/modem_shm/Kconfig
@@ -0,0 +1,9 @@
+config MODEM_SHM
+bool "Modem Access Framework"
+default n
+help
+ Add support for Modem Access Framework. It allows different
+platform specific drivers to register modem access mechanisms
+and allows transparent access to modem to the client drivers.
+
+If unsure, say N.
diff --git a/drivers/modem_shm/Makefile b/drivers/modem_shm/Makefile
new file mode 100644
index 000..b77bcc0
--- /dev/null
+++ b/drivers/modem_shm/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MODEM_SHM):= modem_access.o
diff --git a/drivers/modem_shm/modem_access.c b/drivers/modem_shm/modem_access.c
new file mode 100644
index 000..b4bb4b7
--- /dev/null
+++ b/drivers/modem_shm/modem_access.c
@@ -0,0 +1,413 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Kumar Sanghvi
+ * Arun Murthy
+ *
+ * Heavily adapted from Regulator framework.
+ * Provides mechanisms for registering platform specific access
+ * mechanisms for modem.
+ * Also, exposes APIs for gettng/releasing the access and even
+ * query the access status, and the modem usage status.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static DEFINE_MUTEX(modem_list_mutex);
+static LIST_HEAD(modem_list);
+
+struct modem {
+ struct device *dev;
+ struct list_head list;
+ char *modem_name;
+ struct device_attribute dev_attr;
+ struct modem_dev *mdev;
+ atomic_t use;
+};
+
+static enum mod_state {
+ MOD_RELEASED,
+ MOD_ACCESSED,
+};
+
+static const char *mdev_get_name(struct modem_dev *mdev)
+{
+ if (mdev->desc->name)
+ return mdev->desc->name;
+ else
+ return "";
+}
+
+static int _modem_is_requested(struct modem_dev *mdev)
+{
+ /* If we don't know then assume that the modem is always on */
+ if (!mdev->desc->ops->is_requested)
+ return 0;
+
+ return mdev->desc->ops->is_requested(mdev);
+}
+
+/**
+ * modem_is_requested - check if modem access is requested
+ * @modem: modem device
+ *
+ * Checks whether modem is accessed or not by querying
+ * the underlying platform specific modem access
+ * implementation.
+ */
+int modem_is_requested(struct modem *modem)
+{
+ int ret;
+
+ mutex_lock(&modem->mdev->mutex);
+ ret = _modem_is_requested(modem->mdev);
+ mutex_unlock(&modem->mdev->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(modem_is_requested);
+
+static int _modem_request(struct modem_dev *mdev)
+{
+ int ret;
+
+ if (++mdev->use_count == 1) {
+ ret = _modem_is_requested(mdev);
+ if (ret == 0)
+ mdev->desc->ops->request(mdev);
+ }
+
+ return 0;
+}
+
+/**
+ * modem_request - Request access the modem
+ * @modem: modem device
+ *
+ * API to access the modem. It keeps a client
+ * specific check on whether the particular modem
+ * requested is accessed or not.
+ */
+int modem_request(struct modem *modem)
+{
+ struct modem_dev *
[PATCHv3 2/4] modem_shm: Register u8500 client for MAF
Register with Modem Access Framework(MAF) for u8500 platform. This will provide
interface to enable and disable modem access and also provide the status.
Signed-off-by: Arun Murthy
---
drivers/modem_shm/Kconfig | 11 +
drivers/modem_shm/Makefile |1 +
drivers/modem_shm/modem_u8500.c | 96 +++
3 files changed, 108 insertions(+), 0 deletions(-)
create mode 100644 drivers/modem_shm/modem_u8500.c
diff --git a/drivers/modem_shm/Kconfig b/drivers/modem_shm/Kconfig
index f4b7e54..f59d3dc 100644
--- a/drivers/modem_shm/Kconfig
+++ b/drivers/modem_shm/Kconfig
@@ -7,3 +7,14 @@ config MODEM_SHM
and allows transparent access to modem to the client drivers.
If unsure, say N.
+
+config MODEM_U8500
+ bool "Modem Access driver for STE U8500 platform"
+ depends on MODEM_SHM
+ default n
+ help
+Add support for Modem Access driver on STE U8500 platform which
+uses Shared Memroy as IPC mechanism between Modem processor and
+Application processor.
+
+If unsure, say N.
diff --git a/drivers/modem_shm/Makefile b/drivers/modem_shm/Makefile
index b77bcc0..a9aac0f 100644
--- a/drivers/modem_shm/Makefile
+++ b/drivers/modem_shm/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_MODEM_SHM):= modem_access.o
+obj-$(CONFIG_MODEM_U8500) += modem_u8500.o
diff --git a/drivers/modem_shm/modem_u8500.c b/drivers/modem_shm/modem_u8500.c
new file mode 100644
index 000..86966fc
--- /dev/null
+++ b/drivers/modem_shm/modem_u8500.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Kumar Sanghvi
+ * Arun Murthy
+ *
+ * Platform driver implementing access mechanisms to modem
+ * on U8500 which uses Shared Memroy as IPC between Application
+ * Processor and Modem processor.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static int u8500_modem_request(struct modem_dev *mdev)
+{
+ return prcmu_ac_wake_req();
+}
+
+static void u8500_modem_release(struct modem_dev *mdev)
+{
+ prcmu_ac_sleep_req();
+}
+
+static int u8500_modem_is_requested(struct modem_dev *mdev)
+{
+ return prcmu_is_ac_wake_requested();
+}
+
+static struct modem_ops u8500_modem_ops = {
+ .request = u8500_modem_request,
+ .release = u8500_modem_release,
+ .is_requested = u8500_modem_is_requested,
+};
+
+static struct modem_desc u8500_modem_desc = {
+ .name = "u8500-shrm-modem",
+ .id = 0,
+ .ops= &u8500_modem_ops,
+ .owner = THIS_MODULE,
+};
+
+
+static int __devinit u8500_modem_probe(struct platform_device *pdev)
+{
+ struct modem_dev *mdev;
+ int err;
+
+ mdev = modem_register(&u8500_modem_desc, &pdev->dev,
+ NULL);
+ if (IS_ERR(mdev)) {
+ err = PTR_ERR(mdev);
+ pr_err("failed to register %s: err %i\n",
+ u8500_modem_desc.name, err);
+ }
+
+ return 0;
+}
+
+static int __devexit u8500_modem_remove(struct platform_device *pdev)
+{
+
+ return 0;
+}
+
+static struct platform_driver u8500_modem_driver = {
+ .driver = {
+ .name = "u8500-modem",
+ .owner = THIS_MODULE,
+ },
+ .probe = u8500_modem_probe,
+ .remove = __devexit_p(u8500_modem_remove),
+};
+
+static int __init u8500_modem_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&u8500_modem_driver);
+ if (ret < 0) {
+ printk(KERN_ERR "u8500_modem: platform driver reg failed\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void __exit u8500_modem_exit(void)
+{
+ platform_driver_unregister(&u8500_modem_driver);
+}
+
+arch_initcall(u8500_modem_init);
--
1.7.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv2 1/4] modem_shm: Add Modem Access Framework
> > On Wed, Aug 08, 2012 at 05:36:05AM +0200, Arun MURTHY wrote: > > > > On Tue, Aug 07, 2012 at 12:24:28PM +0530, Arun Murthy wrote: > > > > > Adds Modem Access Framework, which allows for registering > > > > > platform > > > > specific > > > > > modem access mechanisms. The framework also exposes APIs for > > > > > client > > > > drivers > > > > > for getting and releasing access to modem, regardless of the > > > > underlying > > > > > platform specific access mechanism. > > > > > > > > The term "modems" here has a lot of legacy connotations. First of > > > > which is, userspace handles this today as tty devices, why aren't > > > > you doing the same here? Why does this have to be something > > > > "special"? > > > > > > > > > > The main focus over there the modem IPC. > > > > Over where? > > > > What "modem IPC"? > > > > I mean the dir which is added in this patch, "modem_shm" is added to have a > separate list of such modem access drivers. The modem that I am referring to is an on chip modem in embedded platforms. Applications of these being mobile, tablets etc. So the APE and modem resides on a single chip. Thanks and Regards, Arun R Murthy -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv2 3/4] modem_shm: u8500-shm: U8500 Shared Memory Driver
> > Basically it doesn't suit our protocol of having base addr, read/write
> > pointer, locking etc as the same set of structures and protocol will
> > be used on the modem side implementation.
>
> Ok. What happens about endianness or is the modem always the same
> endianness as the host ?
Yes its always the same endianess, because the same phonet protocol is
used on APE and modem side.
The flow on APE is like user space->kernel network->phonet->shrm
And on modem side its shrm->phonet->modem stack
>
>
> > > > + if (len <= 0)
> > > > + return -EFAULT;
> > >
> > > How can this occur ?
> >
> > Check for error condition
>
> So how can it occur ? The kernel char layer will never pass a negative length
> to a driver ?
>
Ok, will remove this.
> > > What happens with two parallel reads - I don't see what prevents
> > > corruption if that occurs or one racing read freeing the message
> > > before another has finished processing it.
> >
> > Two parallel reads for different L2 headers can happen, but within the
> > same L2 header is out of the scope. Since the client using this in
> > user space will not know about the message. i.e which msg is for which
> > client. Hence so that scenario is not considered.
>
> What stops a hostile application (or programmer error) from doing so
> deliberately ?
>
Will add checks over here so as to not to do so.
> > > > + if (len <= 0 || buf == NULL)
> > > > + return -EFAULT;
> > >
> > > len < 0 cannot occur, buf == NULL is not an error
> >
> > Error handling is for what which is not expected.
>
> Well buf = NULL is not an error (its weird but its not an error)
>
> Also length < 0 is never passed from the char layer to a driver.
>
Ok will remove.
> > > > + dev_err(shrm->dev, "Device not opened yet\n");
> > > > + mutex_unlock(&isa_lock);
> > > > + return -ENODEV;
> > > > + }
> > > > + atomic_set(&isa_context->is_open[idx], 1);
> > >
> > > How do you know it will always be one. Also given it's within the
> > > mutex in all uses I can see why is it an atomic ?
> > >
> >
> > As per our assumptions/protocol only one client per L2 header.
>
> So why use atomic. Also you can't make that assumption. If you need your
> device to have one user per channel and one write call at a time you must
> enforce it. There is nothing wrong with enforcing it but it needs to be done.
>
> That means your open path probably wants to do something (locked) like
>
> if (foo->users)
> return -EBUSY;
>
Done, will add check to restrict open for only one process at a time.
> you still then need to use a mutex or similar in read and write because a
> single open can pass to multiple processes (or multiple writes/reads occur at
> once in a multi-threaded app).
>
> User/Kernel is the security boundary so the kernel code must be robust
> against a hostile user rather than assuming a correctly functioning library.
>
> I suspect you simply need to wrap the read/write logic (except for a wait for
> new message) with a mutex and all will be well
>
That should be fine as far as the process is able to differentiate the messages.
> > > > + if (get_boot_state() != BOOT_DONE) {
> > > > + dev_err(shrm->dev, "Boot is not done\n");
> > > > + return -EBUSY;
> > > > + }
> > >
> > > Is it guaranteed that this is a one way path - ie a device never
> > > goes back into BOOT state ?
> >
> > No, on modem reset, everything happens from first.
>
> So what occurs if this modem reset happens between that test and the next
> line. You have no locking on it so you've got no guarantee that it won't reset
> during the test. So it covers the initial set up case but not a reset.
>
> It may not matter providing a reset wakes up things and it is handled later.
> It
> just looks suspicious.
>
That always remain open, there is no end for that suspection. What we need to
is to secure is the access to registers. Before access of any register we need
to
make sure that modem is awake and not reset.
> > > > + isadev = &isa_context->isadev[idx];
> > > > + if (filp != NULL)
> > > > + filp->private_data = isadev;
> > >
> > > How can filp be NULL ?
> >
> > :-) just a error condition check
>
> These tests are not useful, if anything they hide bugs. If you have a real
> reason to check (eg its a complicated internal path) then use
>
> WARN_ON(condition)
>
> or
>
> BUG_ON(condition)
>
> so it gets noticed. For core kernel things however there is no point checking.
> If the kernel ever passes you null as a file pointer the game is already over.
>
Done.
> > > > + for (no_dev = 0; no_dev < ISA_DEVICES; no_dev++) {
> > > > + atomic_set(&isa_context->is_open[no_dev], 1);
> > > > + device_create(isa_context->shm_class, NULL,
> > > > + MKDEV(MAJOR(dev_id),
> > > > + map_dev[no_dev].l2_header), NULL,
> > > > +
RE: [PATCHv2 1/4] modem_shm: Add Modem Access Framework
> On Wed, Aug 08, 2012 at 05:36:05AM +0200, Arun MURTHY wrote: > > > On Tue, Aug 07, 2012 at 12:24:28PM +0530, Arun Murthy wrote: > > > > Adds Modem Access Framework, which allows for registering platform > > > specific > > > > modem access mechanisms. The framework also exposes APIs for > > > > client > > > drivers > > > > for getting and releasing access to modem, regardless of the > > > underlying > > > > platform specific access mechanism. > > > > > > The term "modems" here has a lot of legacy connotations. First of > > > which is, userspace handles this today as tty devices, why aren't > > > you doing the same here? Why does this have to be something > > > "special"? > > > > > > > The main focus over there the modem IPC. > > Over where? > > What "modem IPC"? > I mean the dir which is added in this patch, "modem_shm" is added to have a separate list of such modem access drivers. > You need to really explain what you are doing here, as I have no idea. > And I have no idea why you still can't just use a tty device, why can't you? > Its not that tty can be used or cant be used, but just to separate out the modem related stuff in a separate folder. > > In doing so, there are some functionality like waking the modem, or > > releasing the modem etc. These will be used by the modem IPC drivers > > and also few others like sim driver and security drivers. > > What's a "sim driver", and what type of "security drivers" are you referring > to? SIM(Subscriber Identity Module) used in mobiles. TEE(security) driver > > > Since this is a shared call and hence has to be synchronized. Hence so > > a small framework like is being done to monitor the modem access > > related only operations. > > Again, why can't the tty layer do this for you? > Maybe tty can do this, but want to have all modem related separately. There are many such hardware and many drivers coming up in near future. Thanks and Regards, Arun R Murthy - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv2 3/4] modem_shm: u8500-shm: U8500 Shared Memory Driver
> > drivers/modem_shm/Kconfig|2 + > > drivers/modem_shm/Makefile |1 + > > drivers/modem_shm/u8500_shm/Kconfig | 43 + > > drivers/modem_shm/u8500_shm/Makefile |7 + > > drivers/modem_shm/u8500_shm/shrm_char.c | 895 > > drivers/modem_shm/u8500_shm/shrm_driver.c| 732 ++ > > drivers/modem_shm/u8500_shm/shrm_fifo.c | 837 > > drivers/modem_shm/u8500_shm/shrm_net.c | 312 + > > drivers/modem_shm/u8500_shm/shrm_protocol.c | 1590 > ++ > > include/linux/modem_shm/u8500_shm/shrm.h | 23 + > > include/linux/modem_shm/u8500_shm/shrm_config.h | 114 ++ > > include/linux/modem_shm/u8500_shm/shrm_driver.h | 225 +++ > > include/linux/modem_shm/u8500_shm/shrm_ioctl.h | 43 + > > include/linux/modem_shm/u8500_shm/shrm_net.h | 46 + > > include/linux/modem_shm/u8500_shm/shrm_private.h | 183 +++ > > Why do any of those .h files need to be in include/linux/*? Shouldn't > they just be in the same directory as the driver itself? Can be moved to the same dir. Will do that in the next ver of the patch. Thanks and Regards, Arun R Murthy - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv2 1/4] modem_shm: Add Modem Access Framework
> On Tue, Aug 07, 2012 at 12:24:28PM +0530, Arun Murthy wrote:
> > Adds Modem Access Framework, which allows for registering platform
> specific
> > modem access mechanisms. The framework also exposes APIs for client
> drivers
> > for getting and releasing access to modem, regardless of the
> underlying
> > platform specific access mechanism.
>
> The term "modems" here has a lot of legacy connotations. First of
> which
> is, userspace handles this today as tty devices, why aren't you doing
> the same here? Why does this have to be something "special"?
>
The main focus over there the modem IPC. In doing so, there are some
functionality like waking the modem, or releasing the modem etc. These
will be used by the modem IPC drivers and also few others like sim driver
and security drivers.
Since this is a shared call and hence has to be synchronized. Hence so a
small framework like is being done to monitor the modem access related only
operations.
> >
> > Signed-off-by: Arun Murthy
> > Acked-by: Linus Walleij
> > ---
> > drivers/Kconfig|2 +
> > drivers/Makefile |1 +
> > drivers/modem_shm/Kconfig |9 +
> > drivers/modem_shm/Makefile |1 +
> > drivers/modem_shm/modem_access.c | 419
>
>
> Any reason why this can't be under drivers/tty/ ?
No specific reason, other than to have a separate place for the modem
access related drivers. Many of the platforms have these functionality
and hence all of them can reside over here using a common framework(MAF)
>
> > include/linux/modem_shm/modem.h| 64 +
> > include/linux/modem_shm/modem_client.h | 55 +
>
> Why are both of these "public" like this? Why not just make one file?
> Would someone ever only need to include one of these?
modem.h is a header file used by the MAF, but modem_client.h includes
a structure that will be used by all clients registering to this MAF.
Hence the clients can only include only this header.
>
> > +config MODEM_SHM
> > +bool "Modem Access Framework"
> > +default y
>
> Unless it is needed to boot your machine, NEVER make the default y.
Oops,.. will change this.
>
> > +struct modem {
> > + struct device *dev;
> > + struct list_head list;
> > + char *modem_name;
>
> You already have a name in the struct device, why do you need another
> one?
>
> > + struct device_attribute dev_attr;
>
> Why is this in the structure?
>
> > + struct modem_dev *mdev;
> > + atomic_t use;
>
> What is this variable for?
This is used to monitor the number of requests received. Just to
balance the enable/disable process. Something like the regulator
framework.
>
> Why isn't this a 'struct device' itself?
>
> > +/**
> > + * modem_is_requested - check if modem access is requested
> > + * @modem: modem device
> > + *
> > + * Checks whether modem is accessed or not by querying
> > + * the underlying platform specific modem access
> > + * implementation.
> > + */
> > +int modem_is_requested(struct modem *modem)
> > +{
> > + int ret;
> > +
> > + mutex_lock(&modem->mdev->mutex);
> > + ret = _modem_is_requested(modem->mdev);
> > + mutex_unlock(&modem->mdev->mutex);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL(modem_is_requested);
>
> EXPORT_SYMBOL_GPL() for this, and the other apis perhaps?
OK.
>
> > +static struct modem *_modem_get(struct device *dev, const char *id,
> > + int exclusive)
> > +{
> > + struct modem_dev *mdev_ptr;
> > + struct modem *modem = ERR_PTR(-ENODEV);
> > + int ret;
> > +
> > + if (id == NULL) {
> > + pr_err("modem_get with no identifier\n");
> > + return modem;
> > + }
> > +
> > + mutex_lock(&modem_list_mutex);
> > + list_for_each_entry(mdev_ptr, &modem_list, modem_list) {
> > + if (strcmp(mdev_get_name(mdev_ptr), id) == 0)
> > + goto found;
> > + }
> > +
> > + goto out;
> > +
> > +found:
> > + if (!try_module_get(mdev_ptr->owner))
> > + goto out;
> > +
> > + modem = create_modem(mdev_ptr, dev, id);
> > + if (modem == NULL) {
> > + modem = ERR_PTR(-ENOMEM);
> > + module_put(mdev_ptr->owner);
> > + }
> > +
> > + mdev_ptr->open_count++;
> > +
RE: [PATCHv2 3/4] modem_shm: u8500-shm: U8500 Shared Memory Driver
tocol only one client per L2 header.
> > +
> > + switch (m) {
> > + case RPC_MESSAGING:
> > + dev_info(shrm->dev, "Close RPC_MESSAGING Device\n");
> > + break;
> > + case AUDIO_MESSAGING:
> > + dev_info(shrm->dev, "Close AUDIO_MESSAGING Device\n");
> > + break;
> > + case SECURITY_MESSAGING:
> > + dev_info(shrm->dev, "CLose SECURITY_MESSAGING Device\n");
> > + break;
> > + case COMMON_LOOPBACK_MESSAGING:
> > + kfree(isadev->addr);
> > + dev_info(shrm->dev, "Close COMMON_LOOPBACK_MESSAGING
> Device\n");
> > + break;
> > + case AUDIO_LOOPBACK_MESSAGING:
> > + kfree(isadev->addr);
> > + dev_info(shrm->dev, "Close AUDIO_LOOPBACK_MESSAGING
> Device\n");
> > + break;
> > + case CIQ_MESSAGING:
> > + kfree(isadev->addr);
> > + dev_info(shrm->dev, "Close CIQ_MESSAGING Device\n");
> > + break;
> > + case RTC_CAL_MESSAGING:
> > + dev_info(shrm->dev, "Close RTC_CAL_MESSAGING Device\n");
> > + break;
>
> kfree(NULL) is a no-op and guaranteed so, providing you see isadev-
> >addr
> = NULL properly in the open path you can delete all of this code and
> just
> do
> kfree(isadev->addr);
> mutex_unlock(...)
> return 0;
Ok, sounds good!
>
> > + if (get_boot_state() != BOOT_DONE) {
> > + dev_err(shrm->dev, "Boot is not done\n");
> > + return -EBUSY;
> > + }
>
> Is it guaranteed that this is a one way path - ie a device never goes
> back into BOOT state ?
No, on modem reset, everything happens from first.
>
> > + if (!atomic_dec_and_test(&isa_context->is_open[idx])) {
> > + atomic_inc(&isa_context->is_open[idx]);
> > + dev_err(shrm->dev, "Device already opened\n");
> > + mutex_unlock(&isa_lock);
> > + return -EBUSY;
>
> See comments earlier about the atomics
Replied above
>
> > + }
> > + isadev = &isa_context->isadev[idx];
> > + if (filp != NULL)
> > + filp->private_data = isadev;
>
> How can filp be NULL ?
:-) just a error condition check
>
> > +
> > + switch (m) {
> > + case RPC_MESSAGING:
> > + dev_info(shrm->dev, "Open RPC_MESSAGING Device\n");
> > + break;
> > + case AUDIO_MESSAGING:
> > + dev_info(shrm->dev, "Open AUDIO_MESSAGING Device\n");
> > + break;
> > + case SECURITY_MESSAGING:
> > + dev_info(shrm->dev, "Open SECURITY_MESSAGING Device\n");
> > + break;
> > + case COMMON_LOOPBACK_MESSAGING:
> > + isadev->addr = kzalloc(10 * 1024, GFP_KERNEL);
> > + if (!isadev->addr) {
> > + mutex_unlock(&isa_lock);
> > + return -ENOMEM;
> > + }
> > + dev_info(shrm->dev, "Open COMMON_LOOPBACK_MESSAGING
> Device\n");
> > + break;
> > + case AUDIO_LOOPBACK_MESSAGING:
> > + isadev->addr = kzalloc(10 * 1024, GFP_KERNEL);
> > + if (!isadev->addr) {
> > + mutex_unlock(&isa_lock);
> > + return -ENOMEM;
> > + }
> > + dev_info(shrm->dev, "Open AUDIO_LOOPBACK_MESSAGING
> Device\n");
> > + break;
> > + case CIQ_MESSAGING:
> > + isadev->addr = kzalloc(10 * 1024, GFP_KERNEL);
> > + if (!isadev->addr) {
> > + mutex_unlock(&isa_lock);
> > + return -ENOMEM;
> > + }
> > + dev_info(shrm->dev, "Open CIQ_MESSAGING Device\n");
> > + break;
> > + case RTC_CAL_MESSAGING:
> > + dev_info(shrm->dev, "Open RTC_CAL_MESSAGING Device\n");
> > + break;
> > + };
>
> So all of this could just be
>
> dev_dbg("Open device %d\n", m);
> switch (m) {
> case a
> case b
> case c
> isadev->addr =
> break;
> case e
> case f
> isadev->addr = NULL;
> break;
> default:
> error path
>
> also in your error case right now if you run out of memory you don't
>
[PATCHv2 1/4] modem_shm: Add Modem Access Framework
Adds Modem Access Framework, which allows for registering platform specific
modem access mechanisms. The framework also exposes APIs for client drivers
for getting and releasing access to modem, regardless of the underlying
platform specific access mechanism.
Signed-off-by: Arun Murthy
Acked-by: Linus Walleij
---
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/modem_shm/Kconfig |9 +
drivers/modem_shm/Makefile |1 +
drivers/modem_shm/modem_access.c | 419
include/linux/modem_shm/modem.h| 64 +
include/linux/modem_shm/modem_client.h | 55 +
7 files changed, 551 insertions(+), 0 deletions(-)
create mode 100644 drivers/modem_shm/Kconfig
create mode 100644 drivers/modem_shm/Makefile
create mode 100644 drivers/modem_shm/modem_access.c
create mode 100644 include/linux/modem_shm/modem.h
create mode 100644 include/linux/modem_shm/modem_client.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ece958d..dc7c14a 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -152,4 +152,6 @@ source "drivers/vme/Kconfig"
source "drivers/pwm/Kconfig"
+source "drivers/modem_shm/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 5b42184..902dfec 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -139,3 +139,4 @@ obj-$(CONFIG_EXTCON)+= extcon/
obj-$(CONFIG_MEMORY) += memory/
obj-$(CONFIG_IIO) += iio/
obj-$(CONFIG_VME_BUS) += vme/
+obj-$(CONFIG_MODEM_SHM)+= modem_shm/
diff --git a/drivers/modem_shm/Kconfig b/drivers/modem_shm/Kconfig
new file mode 100644
index 000..0e5fc7a
--- /dev/null
+++ b/drivers/modem_shm/Kconfig
@@ -0,0 +1,9 @@
+config MODEM_SHM
+bool "Modem Access Framework"
+default y
+help
+ Add support for Modem Access Framework. It allows different
+platform specific drivers to register modem access mechanisms
+and allows transparent access to modem to the client drivers.
+
+If unsure, say N.
diff --git a/drivers/modem_shm/Makefile b/drivers/modem_shm/Makefile
new file mode 100644
index 000..b77bcc0
--- /dev/null
+++ b/drivers/modem_shm/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MODEM_SHM):= modem_access.o
diff --git a/drivers/modem_shm/modem_access.c b/drivers/modem_shm/modem_access.c
new file mode 100644
index 000..ebb110c
--- /dev/null
+++ b/drivers/modem_shm/modem_access.c
@@ -0,0 +1,419 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Kumar Sanghvi
+ * Arun Murthy
+ *
+ * Heavily adapted from Regulator framework.
+ * Provides mechanisms for registering platform specific access
+ * mechanisms for modem.
+ * Also, exposes APIs for gettng/releasing the access and even
+ * query the access status, and the modem usage status.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static DEFINE_MUTEX(modem_list_mutex);
+static LIST_HEAD(modem_list);
+
+struct modem {
+ struct device *dev;
+ struct list_head list;
+ char *modem_name;
+ struct device_attribute dev_attr;
+ struct modem_dev *mdev;
+ atomic_t use;
+};
+
+static const char *mdev_get_name(struct modem_dev *mdev)
+{
+ if (mdev->desc->name)
+ return mdev->desc->name;
+ else
+ return "";
+}
+
+static int _modem_is_requested(struct modem_dev *mdev)
+{
+ /* If we don't know then assume that the modem is always on */
+ if (!mdev->desc->ops->is_requested)
+ return 0;
+
+ return mdev->desc->ops->is_requested(mdev);
+}
+
+/**
+ * modem_is_requested - check if modem access is requested
+ * @modem: modem device
+ *
+ * Checks whether modem is accessed or not by querying
+ * the underlying platform specific modem access
+ * implementation.
+ */
+int modem_is_requested(struct modem *modem)
+{
+ int ret;
+
+ mutex_lock(&modem->mdev->mutex);
+ ret = _modem_is_requested(modem->mdev);
+ mutex_unlock(&modem->mdev->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL(modem_is_requested);
+
+static int _modem_request(struct modem_dev *mdev)
+{
+ int ret;
+
+ if (++mdev->use_count == 1) {
+ ret = _modem_is_requested(mdev);
+ if (ret == 0)
+ mdev->desc->ops->request(mdev);
+ }
+
+ return 0;
+}
+
+/**
+ * modem_request - Request access the modem
+ * @modem: modem device
+ *
+ * API to access the modem. It keeps a client
+ * specific check on whether the particular modem
+ * requested is accessed or not.
+ */
+int modem_request(struct modem *modem)
+{
+ struct modem_dev *mdev = modem->mdev;
+ int ret = 0;
+
+
+ mutex_lock(&md
[PATCHv2 4/4] Doc: Add u8500_shrm document
Add document for u8500 shared memory(shrm)and kernel Docbook. Signed-off-by: Arun Murthy Acked-by: Linus Walleij --- Documentation/DocBook/Makefile |2 +- Documentation/DocBook/shrm.tmpl| 125 Documentation/modem_shm/u8500_shrm.txt | 254 3 files changed, 380 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/shrm.tmpl create mode 100644 Documentation/modem_shm/u8500_shrm.txt diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index bc3d9f8..673ea06 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml + tracepoint.xml drm.xml media_api.xml shrm.xml include $(srctree)/Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/shrm.tmpl b/Documentation/DocBook/shrm.tmpl new file mode 100644 index 000..79e099c --- /dev/null +++ b/Documentation/DocBook/shrm.tmpl @@ -0,0 +1,125 @@ + +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> + + + + Shared Memory + + +Arun + Murthy + + + arun.mur...@stericsson.com + + + + + + + 2009-2010 + ST-Ericsson + + + + + Linux standard functions + + + + + + + Licence terms: GNU General Public Licence (GPL) version 2. + + + + + + +Introduction + + This Documentation describes the ST-Ericsson's adaptation on protocol used for CMT/APE communication when SHaRedMemory is used as IPC link. + + + + +Design + + The APE consists Cortex A9 dual core SMP, a multimedia DSP and PRCMU. Modem consists of 2 Cortex R4 ARM processor. + The exchange of messages between CMT(Cellular Mobile Terminal) and APE includes copying the data to a shared area DDR. + This region is accessible by both CMT and APE. The design includes 2 channels common and audio. Common channel is used for exchanging ISI, RPC and SECURITY messages. + udio channel is used for exchanging AUDIO messages. Each channel consists of 2 FIFO. One FIFO for sending message from CMT to APE and other from APE to CMT. + ach of these FIFO have write and read pointer shared between APE and CMT. Writer pointer is updated on copying the message to FIFO and reader will read the messages from the read pointer upto the writer pointer. Writer and reader notifications are used to notify the completion of read/write operation(seperate for APE and CMT). + river includes 4 queues. Once the messages are sent from CMT to APE it resides in the FIFO and then copied to one of the 4 queues based on the message type(ISI, RPC, AUDIO, SECURITY) and then the net/char device interface fetches this message from the queue and copies to the user space buffer. + + + + +Concepts + + The user space application sends ISI/RPC/AUDIO/SECURITY messages. ISI is sent through the phonet to shrm driver. For achieving this there are 2 interfaces to the shrm driver. Net interface used for exchanging the ISI message and char interface for RPC, AUDIO and SECURITY messages. On receiving any of these messages from the user space application, it is copied to a memory in kernel space. From here it is then copied to respective FIFO from where the CMT reads the message. + CMT(Cellular Mobile Terminal) writes messages to the respective FIFO and thereafter to respective queue. The net/char device copies this message from the queue to the user space buffer. + + + + + Known Bugs And Assumptions + + + + None + + + Assumptions + 1. ApeShmFifo#0 is of 128kB in size. As this is used for transmission except CS audio call data. Expected message size is 1.5kB with a max of 16kB. + 2. ApeShmFifo#1 is of 4kB in size. This is used for transmission of CS audio call data. Expected message size is 24kb. + 3. CmtShmFifo#0 is of 128kB in size. As this is used for transmission except CS audio call data. Expected message size is 1.5kB with a max of 16kB. + 4. CmtShmFifo#1 is of 4kB in size. This is used for transmission of CS audio call data. Expected message size is 24kb. + The total size of the FIFO is 264 kB. + + + + + + + + + Public Functions Provided + + This Section lists the API's provided by the SHRM driver to phonet drivers. + +!Edrivers/modem_shm/u8500_shm/shrm_fifo.c + + This Section lists the API's provided by the SHRM driver used in transmission of RPC, AUDIO and SECURITY mess
[PATCHv2 2/4] modem_shm: Register u8500 client for MAF
Register with Modem Access Framework(MAF) for u8500 platform. This will provide
interface to enable and disable modem access and also provide the status.
Signed-off-by: Arun Murthy
Acked-by: Linus Walleij
---
drivers/modem_shm/Kconfig | 11 +
drivers/modem_shm/Makefile |1 +
drivers/modem_shm/modem_u8500.c | 96 +++
3 files changed, 108 insertions(+), 0 deletions(-)
create mode 100644 drivers/modem_shm/modem_u8500.c
diff --git a/drivers/modem_shm/Kconfig b/drivers/modem_shm/Kconfig
index 0e5fc7a..f2b36a9 100644
--- a/drivers/modem_shm/Kconfig
+++ b/drivers/modem_shm/Kconfig
@@ -7,3 +7,14 @@ config MODEM_SHM
and allows transparent access to modem to the client drivers.
If unsure, say N.
+
+config MODEM_U8500
+ bool "Modem Access driver for STE U8500 platform"
+ depends on MODEM_SHM
+ default n
+ help
+Add support for Modem Access driver on STE U8500 platform which
+uses Shared Memroy as IPC mechanism between Modem processor and
+Application processor.
+
+If unsure, say N.
diff --git a/drivers/modem_shm/Makefile b/drivers/modem_shm/Makefile
index b77bcc0..a9aac0f 100644
--- a/drivers/modem_shm/Makefile
+++ b/drivers/modem_shm/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_MODEM_SHM):= modem_access.o
+obj-$(CONFIG_MODEM_U8500) += modem_u8500.o
diff --git a/drivers/modem_shm/modem_u8500.c b/drivers/modem_shm/modem_u8500.c
new file mode 100644
index 000..86966fc
--- /dev/null
+++ b/drivers/modem_shm/modem_u8500.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Kumar Sanghvi
+ * Arun Murthy
+ *
+ * Platform driver implementing access mechanisms to modem
+ * on U8500 which uses Shared Memroy as IPC between Application
+ * Processor and Modem processor.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static int u8500_modem_request(struct modem_dev *mdev)
+{
+ return prcmu_ac_wake_req();
+}
+
+static void u8500_modem_release(struct modem_dev *mdev)
+{
+ prcmu_ac_sleep_req();
+}
+
+static int u8500_modem_is_requested(struct modem_dev *mdev)
+{
+ return prcmu_is_ac_wake_requested();
+}
+
+static struct modem_ops u8500_modem_ops = {
+ .request = u8500_modem_request,
+ .release = u8500_modem_release,
+ .is_requested = u8500_modem_is_requested,
+};
+
+static struct modem_desc u8500_modem_desc = {
+ .name = "u8500-shrm-modem",
+ .id = 0,
+ .ops= &u8500_modem_ops,
+ .owner = THIS_MODULE,
+};
+
+
+static int __devinit u8500_modem_probe(struct platform_device *pdev)
+{
+ struct modem_dev *mdev;
+ int err;
+
+ mdev = modem_register(&u8500_modem_desc, &pdev->dev,
+ NULL);
+ if (IS_ERR(mdev)) {
+ err = PTR_ERR(mdev);
+ pr_err("failed to register %s: err %i\n",
+ u8500_modem_desc.name, err);
+ }
+
+ return 0;
+}
+
+static int __devexit u8500_modem_remove(struct platform_device *pdev)
+{
+
+ return 0;
+}
+
+static struct platform_driver u8500_modem_driver = {
+ .driver = {
+ .name = "u8500-modem",
+ .owner = THIS_MODULE,
+ },
+ .probe = u8500_modem_probe,
+ .remove = __devexit_p(u8500_modem_remove),
+};
+
+static int __init u8500_modem_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&u8500_modem_driver);
+ if (ret < 0) {
+ printk(KERN_ERR "u8500_modem: platform driver reg failed\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void __exit u8500_modem_exit(void)
+{
+ platform_driver_unregister(&u8500_modem_driver);
+}
+
+arch_initcall(u8500_modem_init);
--
1.7.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 0/4] modem_shm: U8500 SHaRed Memory driver(SHRM)
In u8500 platform the communication between the APE(Application Processor) and the modem subsystem(CMT) is by means of a shared DDR. The series of patches include a protocol called ShaRed Memory(SHRM) protocol for communicating between the APE and the CMT. Interrupt generation registers in CMT and PRCMU on APE side are used to support the shrm protocol. Arun Murthy (4): modem_shm: Add Modem Access Framework modem_shm: Register u8500 client for MAF modem_shm: u8500-shm: U8500 Shared Memory Driver Doc: Add u8500_shrm document Documentation/DocBook/Makefile |2 +- Documentation/DocBook/shrm.tmpl | 125 ++ Documentation/modem_shm/u8500_shrm.txt | 254 drivers/Kconfig |2 + drivers/Makefile |1 + drivers/modem_shm/Kconfig| 22 + drivers/modem_shm/Makefile |3 + drivers/modem_shm/modem_access.c | 419 ++ drivers/modem_shm/modem_u8500.c | 96 ++ drivers/modem_shm/u8500_shm/Kconfig | 43 + drivers/modem_shm/u8500_shm/Makefile |7 + drivers/modem_shm/u8500_shm/shrm_char.c | 895 drivers/modem_shm/u8500_shm/shrm_driver.c| 732 ++ drivers/modem_shm/u8500_shm/shrm_fifo.c | 837 drivers/modem_shm/u8500_shm/shrm_net.c | 312 + drivers/modem_shm/u8500_shm/shrm_protocol.c | 1590 ++ include/linux/modem_shm/modem.h | 64 + include/linux/modem_shm/modem_client.h | 55 + include/linux/modem_shm/u8500_shm/shrm.h | 23 + include/linux/modem_shm/u8500_shm/shrm_config.h | 114 ++ include/linux/modem_shm/u8500_shm/shrm_driver.h | 225 +++ include/linux/modem_shm/u8500_shm/shrm_ioctl.h | 43 + include/linux/modem_shm/u8500_shm/shrm_net.h | 46 + include/linux/modem_shm/u8500_shm/shrm_private.h | 183 +++ 24 files changed, 6092 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/shrm.tmpl create mode 100644 Documentation/modem_shm/u8500_shrm.txt create mode 100644 drivers/modem_shm/Kconfig create mode 100644 drivers/modem_shm/Makefile create mode 100644 drivers/modem_shm/modem_access.c create mode 100644 drivers/modem_shm/modem_u8500.c create mode 100644 drivers/modem_shm/u8500_shm/Kconfig create mode 100644 drivers/modem_shm/u8500_shm/Makefile create mode 100644 drivers/modem_shm/u8500_shm/shrm_char.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_driver.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_fifo.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_net.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_protocol.c create mode 100644 include/linux/modem_shm/modem.h create mode 100644 include/linux/modem_shm/modem_client.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm_config.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm_driver.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm_ioctl.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm_net.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm_private.h -- 1.7.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] modem_shm: U8500 SHaRed Memory driver(SHRM)
> In u8500 platform the communication between the APE(Application > Processor) and > the modem subsystem(CMT) is by means of a shared DDR. The series of > patches > include a protocol called ShaRed Memory(SHRM) protocol for > communicating > between the APE and the CMT. > Interrupt generation registers in CMT and PRCMU on APE side are used to > support > the shrm protocol. > > Arun Murthy (4): > modem_shm: Add Modem Access Framework > modem_shm: Register u8500 client for MAF > modem_shm: u8500-shm: U8500 Shared Memory Driver > Doc: Add u8500_shrm document > > Documentation/DocBook/Makefile |2 +- > Documentation/DocBook/shrm.tmpl | 125 ++ > Documentation/modem_shm/u8500_shrm.txt | 254 > drivers/Kconfig |2 + > drivers/Makefile |1 + > drivers/modem_shm/Kconfig| 22 + > drivers/modem_shm/Makefile |3 + > drivers/modem_shm/modem_access.c | 419 ++ > drivers/modem_shm/modem_u8500.c | 96 ++ > drivers/modem_shm/u8500_shm/Kconfig | 43 + > drivers/modem_shm/u8500_shm/Makefile |7 + > drivers/modem_shm/u8500_shm/shrm_char.c | 895 > drivers/modem_shm/u8500_shm/shrm_driver.c| 732 ++ > drivers/modem_shm/u8500_shm/shrm_fifo.c | 837 > drivers/modem_shm/u8500_shm/shrm_net.c | 312 + > drivers/modem_shm/u8500_shm/shrm_protocol.c | 1590 > ++ > include/linux/modem_shm/modem.h | 64 + > include/linux/modem_shm/modem_client.h | 55 + > include/linux/modem_shm/u8500_shm/shrm.h | 23 + > include/linux/modem_shm/u8500_shm/shrm_config.h | 114 ++ > include/linux/modem_shm/u8500_shm/shrm_driver.h | 225 +++ > include/linux/modem_shm/u8500_shm/shrm_ioctl.h | 43 + > include/linux/modem_shm/u8500_shm/shrm_net.h | 46 + > include/linux/modem_shm/u8500_shm/shrm_private.h | 183 +++ > 24 files changed, 6092 insertions(+), 1 deletions(-) > create mode 100644 Documentation/DocBook/shrm.tmpl > create mode 100644 Documentation/modem_shm/u8500_shrm.txt > create mode 100644 drivers/modem_shm/Kconfig > create mode 100644 drivers/modem_shm/Makefile > create mode 100644 drivers/modem_shm/modem_access.c > create mode 100644 drivers/modem_shm/modem_u8500.c > create mode 100644 drivers/modem_shm/u8500_shm/Kconfig > create mode 100644 drivers/modem_shm/u8500_shm/Makefile > create mode 100644 drivers/modem_shm/u8500_shm/shrm_char.c > create mode 100644 drivers/modem_shm/u8500_shm/shrm_driver.c > create mode 100644 drivers/modem_shm/u8500_shm/shrm_fifo.c > create mode 100644 drivers/modem_shm/u8500_shm/shrm_net.c > create mode 100644 drivers/modem_shm/u8500_shm/shrm_protocol.c > create mode 100644 include/linux/modem_shm/modem.h > create mode 100644 include/linux/modem_shm/modem_client.h > create mode 100644 include/linux/modem_shm/u8500_shm/shrm.h > create mode 100644 include/linux/modem_shm/u8500_shm/shrm_config.h > create mode 100644 include/linux/modem_shm/u8500_shm/shrm_driver.h > create mode 100644 include/linux/modem_shm/u8500_shm/shrm_ioctl.h > create mode 100644 include/linux/modem_shm/u8500_shm/shrm_net.h > create mode 100644 include/linux/modem_shm/u8500_shm/shrm_private.h > > -- > 1.7.4.3 Any Comments? Thanks and Regards, Arun R Murthy - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] modem_shm: U8500 SHaRed Memory driver(SHRM)
In u8500 platform the communication between the APE(Application Processor) and the modem subsystem(CMT) is by means of a shared DDR. The series of patches include a protocol called ShaRed Memory(SHRM) protocol for communicating between the APE and the CMT. Interrupt generation registers in CMT and PRCMU on APE side are used to support the shrm protocol. Arun Murthy (4): modem_shm: Add Modem Access Framework modem_shm: Register u8500 client for MAF modem_shm: u8500-shm: U8500 Shared Memory Driver Doc: Add u8500_shrm document Documentation/DocBook/Makefile |2 +- Documentation/DocBook/shrm.tmpl | 125 ++ Documentation/modem_shm/u8500_shrm.txt | 254 drivers/Kconfig |2 + drivers/Makefile |1 + drivers/modem_shm/Kconfig| 22 + drivers/modem_shm/Makefile |3 + drivers/modem_shm/modem_access.c | 419 ++ drivers/modem_shm/modem_u8500.c | 96 ++ drivers/modem_shm/u8500_shm/Kconfig | 43 + drivers/modem_shm/u8500_shm/Makefile |7 + drivers/modem_shm/u8500_shm/shrm_char.c | 895 drivers/modem_shm/u8500_shm/shrm_driver.c| 732 ++ drivers/modem_shm/u8500_shm/shrm_fifo.c | 837 drivers/modem_shm/u8500_shm/shrm_net.c | 312 + drivers/modem_shm/u8500_shm/shrm_protocol.c | 1590 ++ include/linux/modem_shm/modem.h | 64 + include/linux/modem_shm/modem_client.h | 55 + include/linux/modem_shm/u8500_shm/shrm.h | 23 + include/linux/modem_shm/u8500_shm/shrm_config.h | 114 ++ include/linux/modem_shm/u8500_shm/shrm_driver.h | 225 +++ include/linux/modem_shm/u8500_shm/shrm_ioctl.h | 43 + include/linux/modem_shm/u8500_shm/shrm_net.h | 46 + include/linux/modem_shm/u8500_shm/shrm_private.h | 183 +++ 24 files changed, 6092 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/shrm.tmpl create mode 100644 Documentation/modem_shm/u8500_shrm.txt create mode 100644 drivers/modem_shm/Kconfig create mode 100644 drivers/modem_shm/Makefile create mode 100644 drivers/modem_shm/modem_access.c create mode 100644 drivers/modem_shm/modem_u8500.c create mode 100644 drivers/modem_shm/u8500_shm/Kconfig create mode 100644 drivers/modem_shm/u8500_shm/Makefile create mode 100644 drivers/modem_shm/u8500_shm/shrm_char.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_driver.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_fifo.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_net.c create mode 100644 drivers/modem_shm/u8500_shm/shrm_protocol.c create mode 100644 include/linux/modem_shm/modem.h create mode 100644 include/linux/modem_shm/modem_client.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm_config.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm_driver.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm_ioctl.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm_net.h create mode 100644 include/linux/modem_shm/u8500_shm/shrm_private.h -- 1.7.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] Doc: Add u8500_shrm document
Add document for u8500 shared memory(shrm)and kernel Docbook. Signed-off-by: Arun Murthy Acked-by: Linus Walleij --- Documentation/DocBook/Makefile |2 +- Documentation/DocBook/shrm.tmpl| 125 Documentation/modem_shm/u8500_shrm.txt | 254 3 files changed, 380 insertions(+), 1 deletions(-) create mode 100644 Documentation/DocBook/shrm.tmpl create mode 100644 Documentation/modem_shm/u8500_shrm.txt diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index bc3d9f8..673ea06 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml + tracepoint.xml drm.xml media_api.xml shrm.xml include $(srctree)/Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/shrm.tmpl b/Documentation/DocBook/shrm.tmpl new file mode 100644 index 000..79e099c --- /dev/null +++ b/Documentation/DocBook/shrm.tmpl @@ -0,0 +1,125 @@ + +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> + + + + Shared Memory + + +Arun + Murthy + + + arun.mur...@stericsson.com + + + + + + + 2009-2010 + ST-Ericsson + + + + + Linux standard functions + + + + + + + Licence terms: GNU General Public Licence (GPL) version 2. + + + + + + +Introduction + + This Documentation describes the ST-Ericsson's adaptation on protocol used for CMT/APE communication when SHaRedMemory is used as IPC link. + + + + +Design + + The APE consists Cortex A9 dual core SMP, a multimedia DSP and PRCMU. Modem consists of 2 Cortex R4 ARM processor. + The exchange of messages between CMT(Cellular Mobile Terminal) and APE includes copying the data to a shared area DDR. + This region is accessible by both CMT and APE. The design includes 2 channels common and audio. Common channel is used for exchanging ISI, RPC and SECURITY messages. + udio channel is used for exchanging AUDIO messages. Each channel consists of 2 FIFO. One FIFO for sending message from CMT to APE and other from APE to CMT. + ach of these FIFO have write and read pointer shared between APE and CMT. Writer pointer is updated on copying the message to FIFO and reader will read the messages from the read pointer upto the writer pointer. Writer and reader notifications are used to notify the completion of read/write operation(seperate for APE and CMT). + river includes 4 queues. Once the messages are sent from CMT to APE it resides in the FIFO and then copied to one of the 4 queues based on the message type(ISI, RPC, AUDIO, SECURITY) and then the net/char device interface fetches this message from the queue and copies to the user space buffer. + + + + +Concepts + + The user space application sends ISI/RPC/AUDIO/SECURITY messages. ISI is sent through the phonet to shrm driver. For achieving this there are 2 interfaces to the shrm driver. Net interface used for exchanging the ISI message and char interface for RPC, AUDIO and SECURITY messages. On receiving any of these messages from the user space application, it is copied to a memory in kernel space. From here it is then copied to respective FIFO from where the CMT reads the message. + CMT(Cellular Mobile Terminal) writes messages to the respective FIFO and thereafter to respective queue. The net/char device copies this message from the queue to the user space buffer. + + + + + Known Bugs And Assumptions + + + + None + + + Assumptions + 1. ApeShmFifo#0 is of 128kB in size. As this is used for transmission except CS audio call data. Expected message size is 1.5kB with a max of 16kB. + 2. ApeShmFifo#1 is of 4kB in size. This is used for transmission of CS audio call data. Expected message size is 24kb. + 3. CmtShmFifo#0 is of 128kB in size. As this is used for transmission except CS audio call data. Expected message size is 1.5kB with a max of 16kB. + 4. CmtShmFifo#1 is of 4kB in size. This is used for transmission of CS audio call data. Expected message size is 24kb. + The total size of the FIFO is 264 kB. + + + + + + + + + Public Functions Provided + + This Section lists the API's provided by the SHRM driver to phonet drivers. + +!Edrivers/modem_shm/u8500_shm/shrm_fifo.c + + This Section lists the API's provided by the SHRM driver used in transmission of RPC, AUDIO and SECURITY mess
[PATCH 1/4] modem_shm: Add Modem Access Framework
Adds Modem Access Framework, which allows for registering platform specific
modem access mechanisms. The framework also exposes APIs for client drivers
for getting and releasing access to modem, regardless of the underlying
platform specific access mechanism.
Signed-off-by: Arun Murthy
Acked-by: Linus Walleij
---
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/modem_shm/Kconfig |9 +
drivers/modem_shm/Makefile |1 +
drivers/modem_shm/modem_access.c | 419
include/linux/modem_shm/modem.h| 64 +
include/linux/modem_shm/modem_client.h | 55 +
7 files changed, 551 insertions(+), 0 deletions(-)
create mode 100644 drivers/modem_shm/Kconfig
create mode 100644 drivers/modem_shm/Makefile
create mode 100644 drivers/modem_shm/modem_access.c
create mode 100644 include/linux/modem_shm/modem.h
create mode 100644 include/linux/modem_shm/modem_client.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ece958d..dc7c14a 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -152,4 +152,6 @@ source "drivers/vme/Kconfig"
source "drivers/pwm/Kconfig"
+source "drivers/modem_shm/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 5b42184..902dfec 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -139,3 +139,4 @@ obj-$(CONFIG_EXTCON)+= extcon/
obj-$(CONFIG_MEMORY) += memory/
obj-$(CONFIG_IIO) += iio/
obj-$(CONFIG_VME_BUS) += vme/
+obj-$(CONFIG_MODEM_SHM)+= modem_shm/
diff --git a/drivers/modem_shm/Kconfig b/drivers/modem_shm/Kconfig
new file mode 100644
index 000..0e5fc7a
--- /dev/null
+++ b/drivers/modem_shm/Kconfig
@@ -0,0 +1,9 @@
+config MODEM_SHM
+bool "Modem Access Framework"
+default y
+help
+ Add support for Modem Access Framework. It allows different
+platform specific drivers to register modem access mechanisms
+and allows transparent access to modem to the client drivers.
+
+If unsure, say N.
diff --git a/drivers/modem_shm/Makefile b/drivers/modem_shm/Makefile
new file mode 100644
index 000..b77bcc0
--- /dev/null
+++ b/drivers/modem_shm/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MODEM_SHM):= modem_access.o
diff --git a/drivers/modem_shm/modem_access.c b/drivers/modem_shm/modem_access.c
new file mode 100644
index 000..ebb110c
--- /dev/null
+++ b/drivers/modem_shm/modem_access.c
@@ -0,0 +1,419 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Kumar Sanghvi
+ * Arun Murthy
+ *
+ * Heavily adapted from Regulator framework.
+ * Provides mechanisms for registering platform specific access
+ * mechanisms for modem.
+ * Also, exposes APIs for gettng/releasing the access and even
+ * query the access status, and the modem usage status.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static DEFINE_MUTEX(modem_list_mutex);
+static LIST_HEAD(modem_list);
+
+struct modem {
+ struct device *dev;
+ struct list_head list;
+ char *modem_name;
+ struct device_attribute dev_attr;
+ struct modem_dev *mdev;
+ atomic_t use;
+};
+
+static const char *mdev_get_name(struct modem_dev *mdev)
+{
+ if (mdev->desc->name)
+ return mdev->desc->name;
+ else
+ return "";
+}
+
+static int _modem_is_requested(struct modem_dev *mdev)
+{
+ /* If we don't know then assume that the modem is always on */
+ if (!mdev->desc->ops->is_requested)
+ return 0;
+
+ return mdev->desc->ops->is_requested(mdev);
+}
+
+/**
+ * modem_is_requested - check if modem access is requested
+ * @modem: modem device
+ *
+ * Checks whether modem is accessed or not by querying
+ * the underlying platform specific modem access
+ * implementation.
+ */
+int modem_is_requested(struct modem *modem)
+{
+ int ret;
+
+ mutex_lock(&modem->mdev->mutex);
+ ret = _modem_is_requested(modem->mdev);
+ mutex_unlock(&modem->mdev->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL(modem_is_requested);
+
+static int _modem_request(struct modem_dev *mdev)
+{
+ int ret;
+
+ if (++mdev->use_count == 1) {
+ ret = _modem_is_requested(mdev);
+ if (ret == 0)
+ mdev->desc->ops->request(mdev);
+ }
+
+ return 0;
+}
+
+/**
+ * modem_request - Request access the modem
+ * @modem: modem device
+ *
+ * API to access the modem. It keeps a client
+ * specific check on whether the particular modem
+ * requested is accessed or not.
+ */
+int modem_request(struct modem *modem)
+{
+ struct modem_dev *mdev = modem->mdev;
+ int ret = 0;
+
+
+ mutex_lock(&md
[PATCH 2/4] modem_shm: Register u8500 client for MAF
Register with Modem Access Framework(MAF) for u8500 platform. This will provide
interface to enable and disable modem access and also provide the status.
Signed-off-by: Arun Murthy
Acked-by: Linus Walleij
---
drivers/modem_shm/Kconfig | 11 +
drivers/modem_shm/Makefile |1 +
drivers/modem_shm/modem_u8500.c | 96 +++
3 files changed, 108 insertions(+), 0 deletions(-)
create mode 100644 drivers/modem_shm/modem_u8500.c
diff --git a/drivers/modem_shm/Kconfig b/drivers/modem_shm/Kconfig
index 0e5fc7a..f2b36a9 100644
--- a/drivers/modem_shm/Kconfig
+++ b/drivers/modem_shm/Kconfig
@@ -7,3 +7,14 @@ config MODEM_SHM
and allows transparent access to modem to the client drivers.
If unsure, say N.
+
+config MODEM_U8500
+ bool "Modem Access driver for STE U8500 platform"
+ depends on MODEM_SHM
+ default n
+ help
+Add support for Modem Access driver on STE U8500 platform which
+uses Shared Memroy as IPC mechanism between Modem processor and
+Application processor.
+
+If unsure, say N.
diff --git a/drivers/modem_shm/Makefile b/drivers/modem_shm/Makefile
index b77bcc0..a9aac0f 100644
--- a/drivers/modem_shm/Makefile
+++ b/drivers/modem_shm/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_MODEM_SHM):= modem_access.o
+obj-$(CONFIG_MODEM_U8500) += modem_u8500.o
diff --git a/drivers/modem_shm/modem_u8500.c b/drivers/modem_shm/modem_u8500.c
new file mode 100644
index 000..86966fc
--- /dev/null
+++ b/drivers/modem_shm/modem_u8500.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Kumar Sanghvi
+ * Arun Murthy
+ *
+ * Platform driver implementing access mechanisms to modem
+ * on U8500 which uses Shared Memroy as IPC between Application
+ * Processor and Modem processor.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static int u8500_modem_request(struct modem_dev *mdev)
+{
+ return prcmu_ac_wake_req();
+}
+
+static void u8500_modem_release(struct modem_dev *mdev)
+{
+ prcmu_ac_sleep_req();
+}
+
+static int u8500_modem_is_requested(struct modem_dev *mdev)
+{
+ return prcmu_is_ac_wake_requested();
+}
+
+static struct modem_ops u8500_modem_ops = {
+ .request = u8500_modem_request,
+ .release = u8500_modem_release,
+ .is_requested = u8500_modem_is_requested,
+};
+
+static struct modem_desc u8500_modem_desc = {
+ .name = "u8500-shrm-modem",
+ .id = 0,
+ .ops= &u8500_modem_ops,
+ .owner = THIS_MODULE,
+};
+
+
+static int __devinit u8500_modem_probe(struct platform_device *pdev)
+{
+ struct modem_dev *mdev;
+ int err;
+
+ mdev = modem_register(&u8500_modem_desc, &pdev->dev,
+ NULL);
+ if (IS_ERR(mdev)) {
+ err = PTR_ERR(mdev);
+ pr_err("failed to register %s: err %i\n",
+ u8500_modem_desc.name, err);
+ }
+
+ return 0;
+}
+
+static int __devexit u8500_modem_remove(struct platform_device *pdev)
+{
+
+ return 0;
+}
+
+static struct platform_driver u8500_modem_driver = {
+ .driver = {
+ .name = "u8500-modem",
+ .owner = THIS_MODULE,
+ },
+ .probe = u8500_modem_probe,
+ .remove = __devexit_p(u8500_modem_remove),
+};
+
+static int __init u8500_modem_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&u8500_modem_driver);
+ if (ret < 0) {
+ printk(KERN_ERR "u8500_modem: platform driver reg failed\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void __exit u8500_modem_exit(void)
+{
+ platform_driver_unregister(&u8500_modem_driver);
+}
+
+arch_initcall(u8500_modem_init);
--
1.7.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
