diff mbox

[v10,01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver

Message ID 1476783556-2501-2-git-send-email-peter.griffin@linaro.org (mailing list archive)
State New, archived
Headers show

Commit Message

Peter Griffin Oct. 18, 2016, 9:39 a.m. UTC
slim core is used as a basis for many IPs in the STi
chipsets such as fdma and demux. To avoid duplicating
the elf loading code in each device driver a slim
rproc driver has been created.

This driver is designed to be used by other device drivers
such as fdma, or demux whose IP is based around a slim core.
The device driver can call slim_rproc_alloc() to allocate
a slim rproc and slim_rproc_put() when finished.

This driver takes care of ioremapping the slim
registers (dmem, imem, slimcore, peripherals), whose offsets
and sizes can change between IP's. It also obtains and enables
any clocks used by the device. This approach avoids having
a double mapping of the registers as slim_rproc does not register
its own platform device. It also maps well to device tree
abstraction as it allows us to have one dt node for the whole
device.

All of the generic rproc elf loading code can be reused, and
we provide start() stop() hooks to start and stop the slim
core once the firmware has been loaded. This has been tested
successfully with fdma driver.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/remoteproc/Kconfig               |   7 +-
 drivers/remoteproc/Makefile              |   1 +
 drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
 include/linux/remoteproc/st_slim_rproc.h |  58 +++++
 4 files changed, 428 insertions(+), 2 deletions(-)
 create mode 100644 drivers/remoteproc/st_slim_rproc.c
 create mode 100644 include/linux/remoteproc/st_slim_rproc.h

Comments

Bjorn Andersson Nov. 3, 2016, 9:37 p.m. UTC | #1
On Tue 18 Oct 02:39 PDT 2016, Peter Griffin wrote:

> slim core is used as a basis for many IPs in the STi
> chipsets such as fdma and demux. To avoid duplicating
> the elf loading code in each device driver a slim
> rproc driver has been created.
> 
> This driver is designed to be used by other device drivers
> such as fdma, or demux whose IP is based around a slim core.
> The device driver can call slim_rproc_alloc() to allocate
> a slim rproc and slim_rproc_put() when finished.
> 
> This driver takes care of ioremapping the slim
> registers (dmem, imem, slimcore, peripherals), whose offsets
> and sizes can change between IP's. It also obtains and enables
> any clocks used by the device. This approach avoids having
> a double mapping of the registers as slim_rproc does not register
> its own platform device. It also maps well to device tree
> abstraction as it allows us to have one dt node for the whole
> device.
> 
> All of the generic rproc elf loading code can be reused, and
> we provide start() stop() hooks to start and stop the slim
> core once the firmware has been loaded. This has been tested
> successfully with fdma driver.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  drivers/remoteproc/Kconfig               |   7 +-
>  drivers/remoteproc/Makefile              |   1 +
>  drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
>  include/linux/remoteproc/st_slim_rproc.h |  58 +++++
>  4 files changed, 428 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/remoteproc/st_slim_rproc.c
>  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index f396bfe..9270c8e 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -58,7 +58,6 @@ config DA8XX_REMOTEPROC
>  	tristate "DA8xx/OMAP-L13x remoteproc support"
>  	depends on ARCH_DAVINCI_DA8XX
>  	select CMA if MMU
> -	select REMOTEPROC

No, this is an unrelated change to this patch.

>  	select RPMSG_VIRTIO
>  	help
>  	  Say y here to support DA8xx/OMAP-L13x remote processors via the
> @@ -99,10 +98,10 @@ config QCOM_WCNSS_PIL
>  	tristate "Qualcomm WCNSS Peripheral Image Loader"
>  	depends on OF && ARCH_QCOM
>  	depends on QCOM_SMEM
> +	depends on REMOTEPROC
>  	select QCOM_MDT_LOADER
>  	select QCOM_SCM
>  	select QCOM_WCNSS_IRIS
> -	select REMOTEPROC

Dito.


As you now make changes to the entire remoteproc Kconfig file, rather
than simply add a Kconfig symbol we can't bring this in via Vinod's tree
without providing Linus with a messy merge conflict.

So the remoteproc parts now has to go through my tree.

>  	help
>  	  Say y here to support the Peripheral Image Loader for the Qualcomm
>  	  Wireless Connectivity Subsystem.
> @@ -116,4 +115,8 @@ config ST_REMOTEPROC
>  	  processor framework.
>  	  This can be either built-in or a loadable module.
>  
> +config ST_SLIM_REMOTEPROC
> +	tristate
> +	select REMOTEPROC
> +
>  endmenu
[..]
> diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
[..]
> +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> +				char *fw_name)
> +{
[..]
> +	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> +			fw_name, sizeof(*slim_rproc));
[..]
> +	rproc_put(rproc);

As of v4.9 you need to rproc_free() rather than rproc_put() to undo
rproc_alloc().

Regards,
Bjorn
Peter Griffin Nov. 7, 2016, 1:57 p.m. UTC | #2
Hi Bjorn,

On Thu, 03 Nov 2016, Bjorn Andersson wrote:

> On Tue 18 Oct 02:39 PDT 2016, Peter Griffin wrote:
> 
> > slim core is used as a basis for many IPs in the STi
> > chipsets such as fdma and demux. To avoid duplicating
> > the elf loading code in each device driver a slim
> > rproc driver has been created.
> > 
> > This driver is designed to be used by other device drivers
> > such as fdma, or demux whose IP is based around a slim core.
> > The device driver can call slim_rproc_alloc() to allocate
> > a slim rproc and slim_rproc_put() when finished.
> > 
> > This driver takes care of ioremapping the slim
> > registers (dmem, imem, slimcore, peripherals), whose offsets
> > and sizes can change between IP's. It also obtains and enables
> > any clocks used by the device. This approach avoids having
> > a double mapping of the registers as slim_rproc does not register
> > its own platform device. It also maps well to device tree
> > abstraction as it allows us to have one dt node for the whole
> > device.
> > 
> > All of the generic rproc elf loading code can be reused, and
> > we provide start() stop() hooks to start and stop the slim
> > core once the firmware has been loaded. This has been tested
> > successfully with fdma driver.
> > 
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  drivers/remoteproc/Kconfig               |   7 +-
> >  drivers/remoteproc/Makefile              |   1 +
> >  drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
> >  include/linux/remoteproc/st_slim_rproc.h |  58 +++++
> >  4 files changed, 428 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/remoteproc/st_slim_rproc.c
> >  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> > 
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index f396bfe..9270c8e 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -58,7 +58,6 @@ config DA8XX_REMOTEPROC
> >  	tristate "DA8xx/OMAP-L13x remoteproc support"
> >  	depends on ARCH_DAVINCI_DA8XX
> >  	select CMA if MMU
> > -	select REMOTEPROC
> 
> No, this is an unrelated change to this patch.

Sorry that crept in as part of the rebase. Will fix.
> 
> >  	select RPMSG_VIRTIO
> >  	help
> >  	  Say y here to support DA8xx/OMAP-L13x remote processors via the
> > @@ -99,10 +98,10 @@ config QCOM_WCNSS_PIL
> >  	tristate "Qualcomm WCNSS Peripheral Image Loader"
> >  	depends on OF && ARCH_QCOM
> >  	depends on QCOM_SMEM
> > +	depends on REMOTEPROC
> >  	select QCOM_MDT_LOADER
> >  	select QCOM_SCM
> >  	select QCOM_WCNSS_IRIS
> > -	select REMOTEPROC
> 
> Dito.

Will fix.

> 
> 
> As you now make changes to the entire remoteproc Kconfig file, rather
> than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> without providing Linus with a messy merge conflict.
> 
> So the remoteproc parts now has to go through my tree.

OK, I think the best approach is for Vinod to create an immutable
branch with the entire fdma series on, and then both of you merge that branch into
your respective trees.

That way there won't be any conflicts and you can both accept further changes
for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
because they have dependencies on each other.

I will send a v11 series in a moment which includes the feedback in this email
and also include the additional fixes which Vinod has applied since the driver
has been in linux-next.

> 
> >  	help
> >  	  Say y here to support the Peripheral Image Loader for the Qualcomm
> >  	  Wireless Connectivity Subsystem.
> > @@ -116,4 +115,8 @@ config ST_REMOTEPROC
> >  	  processor framework.
> >  	  This can be either built-in or a loadable module.
> >  
> > +config ST_SLIM_REMOTEPROC
> > +	tristate
> > +	select REMOTEPROC
> > +
> >  endmenu
> [..]
> > diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> [..]
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > +				char *fw_name)
> > +{
> [..]
> > +	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> > +			fw_name, sizeof(*slim_rproc));
> [..]
> > +	rproc_put(rproc);
> 
> As of v4.9 you need to rproc_free() rather than rproc_put() to undo
> rproc_alloc().

Will fix.

regards,

Peter.
Vinod Koul Nov. 14, 2016, 5:18 a.m. UTC | #3
On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > 
> > As you now make changes to the entire remoteproc Kconfig file, rather
> > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > without providing Linus with a messy merge conflict.
> > 
> > So the remoteproc parts now has to go through my tree.
> 
> OK, I think the best approach is for Vinod to create an immutable
> branch with the entire fdma series on, and then both of you merge that branch into
> your respective trees.

my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
tag, please do let me know

> 
> That way there won't be any conflicts and you can both accept further changes
> for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
> because they have dependencies on each other.
> 
> I will send a v11 series in a moment which includes the feedback in this email
> and also include the additional fixes which Vinod has applied since the driver
> has been in linux-next.

WHY.. Stuff is already merged twice! Please send updated on top of already
merged code! This is how kernel developement is done...
Peter Griffin Nov. 14, 2016, 11:42 a.m. UTC | #4
Hi Vinod,

On Mon, 14 Nov 2016, Vinod Koul wrote:

> On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > 
> > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > without providing Linus with a messy merge conflict.
> > > 
> > > So the remoteproc parts now has to go through my tree.
> > 
> > OK, I think the best approach is for Vinod to create an immutable
> > branch with the entire fdma series on, and then both of you merge that branch into
> > your respective trees.
> 
> my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> tag, please do let me know

OK.

> 
> > 
> > That way there won't be any conflicts and you can both accept further changes
> > for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
> > because they have dependencies on each other.
> > 
> > I will send a v11 series in a moment which includes the feedback in this email
> > and also include the additional fixes which Vinod has applied since the driver
> > has been in linux-next.
> 
> WHY.. Stuff is already merged twice!

When the feedback is "there is an unrelated change in this patch", the only way
you can fix that is by having a new version of the patch.

>Please send updated on top of already
> merged code!

You have dropped the remoteproc parts which were updated in v11, so
it is no longer merged. Bjorn can now pick the v11 versions if he chooses which
incporporates his feedback.

>This is how kernel developement is done...

regards,

Peter.
Vinod Koul Nov. 16, 2016, 3:32 a.m. UTC | #5
On Mon, Nov 14, 2016 at 11:42:16AM +0000, Peter Griffin wrote:
> Hi Vinod,
> 
> On Mon, 14 Nov 2016, Vinod Koul wrote:
> 
> > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > > 
> > > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > > without providing Linus with a messy merge conflict.
> > > > 
> > > > So the remoteproc parts now has to go through my tree.
> > > 
> > > OK, I think the best approach is for Vinod to create an immutable
> > > branch with the entire fdma series on, and then both of you merge that branch into
> > > your respective trees.
> > 
> > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> > tag, please do let me know
> 
> OK.
> 
> > 
> > > 
> > > That way there won't be any conflicts and you can both accept further changes
> > > for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
> > > because they have dependencies on each other.
> > > 
> > > I will send a v11 series in a moment which includes the feedback in this email
> > > and also include the additional fixes which Vinod has applied since the driver
> > > has been in linux-next.
> > 
> > WHY.. Stuff is already merged twice!
> 
> When the feedback is "there is an unrelated change in this patch", the only way
> you can fix that is by having a new version of the patch.

It can be reverted and clean patch applied..
Bjorn Andersson Nov. 17, 2016, 6:36 a.m. UTC | #6
On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:

> On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > 
> > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > without providing Linus with a messy merge conflict.
> > > 
> > > So the remoteproc parts now has to go through my tree.
> > 
> > OK, I think the best approach is for Vinod to create an immutable
> > branch with the entire fdma series on, and then both of you merge that branch into
> > your respective trees.
> 
> my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> tag, please do let me know
> 

Hi Vinod,

It looks like you reverted the wrong Kconfig fix, the one I objected to
was the change in drivers/remoteproc, not the one in drivers/dma.

The ST_FMDA depends on functions exposed by REMOTEPROC and
ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
guys made user selectable - and as such should not be selected - but I
think we should move forward and get everything merged and then we can
go back and figure out how this should be addressed (or left alone?).

I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
now broken drivers/remoteproc/Kconfig.

We do however both need to revert the revert or there will be link
errors if you build the dma driver with remoteproc=n. If you do this I
can merge the topic once more and we'll keep the set of changes in sync.

Regards,
Bjorn
Vinod Koul Nov. 17, 2016, 9:52 a.m. UTC | #7
On Wed, Nov 16, 2016 at 10:36:46PM -0800, Bjorn Andersson wrote:
> On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:
> 
> > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > > 
> > > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > > without providing Linus with a messy merge conflict.
> > > > 
> > > > So the remoteproc parts now has to go through my tree.
> > > 
> > > OK, I think the best approach is for Vinod to create an immutable
> > > branch with the entire fdma series on, and then both of you merge that branch into
> > > your respective trees.
> > 
> > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> > tag, please do let me know
> > 
> 
> Hi Vinod,
> 
> It looks like you reverted the wrong Kconfig fix, the one I objected to
> was the change in drivers/remoteproc, not the one in drivers/dma.
> 
> The ST_FMDA depends on functions exposed by REMOTEPROC and
> ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
> guys made user selectable - and as such should not be selected - but I
> think we should move forward and get everything merged and then we can
> go back and figure out how this should be addressed (or left alone?).
> 
> I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
> now broken drivers/remoteproc/Kconfig.
> 
> We do however both need to revert the revert or there will be link
> errors if you build the dma driver with remoteproc=n. If you do this I
> can merge the topic once more and we'll keep the set of changes in sync.

Oops my bad, thanks for letting me know. I have reverted this now and
pushing out. Please do let me know if this was fine

Thanks
Bjorn Andersson Nov. 18, 2016, 4:40 p.m. UTC | #8
On Thu 17 Nov 01:52 PST 2016, Vinod Koul wrote:

> On Wed, Nov 16, 2016 at 10:36:46PM -0800, Bjorn Andersson wrote:
> > On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:
> > 
> > > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > > > 
> > > > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > > > without providing Linus with a messy merge conflict.
> > > > > 
> > > > > So the remoteproc parts now has to go through my tree.
> > > > 
> > > > OK, I think the best approach is for Vinod to create an immutable
> > > > branch with the entire fdma series on, and then both of you merge that branch into
> > > > your respective trees.
> > > 
> > > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> > > tag, please do let me know
> > > 
> > 
> > Hi Vinod,
> > 
> > It looks like you reverted the wrong Kconfig fix, the one I objected to
> > was the change in drivers/remoteproc, not the one in drivers/dma.
> > 
> > The ST_FMDA depends on functions exposed by REMOTEPROC and
> > ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
> > guys made user selectable - and as such should not be selected - but I
> > think we should move forward and get everything merged and then we can
> > go back and figure out how this should be addressed (or left alone?).
> > 
> > I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
> > now broken drivers/remoteproc/Kconfig.
> > 
> > We do however both need to revert the revert or there will be link
> > errors if you build the dma driver with remoteproc=n. If you do this I
> > can merge the topic once more and we'll keep the set of changes in sync.
> 
> Oops my bad, thanks for letting me know. I have reverted this now and
> pushing out. Please do let me know if this was fine
> 

Thanks for the update Vinod, I've merged in your updated branch into
mine, so now we should be good.

Regards,
Bjorn
diff mbox

Patch

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f396bfe..9270c8e 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -58,7 +58,6 @@  config DA8XX_REMOTEPROC
 	tristate "DA8xx/OMAP-L13x remoteproc support"
 	depends on ARCH_DAVINCI_DA8XX
 	select CMA if MMU
-	select REMOTEPROC
 	select RPMSG_VIRTIO
 	help
 	  Say y here to support DA8xx/OMAP-L13x remote processors via the
@@ -99,10 +98,10 @@  config QCOM_WCNSS_PIL
 	tristate "Qualcomm WCNSS Peripheral Image Loader"
 	depends on OF && ARCH_QCOM
 	depends on QCOM_SMEM
+	depends on REMOTEPROC
 	select QCOM_MDT_LOADER
 	select QCOM_SCM
 	select QCOM_WCNSS_IRIS
-	select REMOTEPROC
 	help
 	  Say y here to support the Peripheral Image Loader for the Qualcomm
 	  Wireless Connectivity Subsystem.
@@ -116,4 +115,8 @@  config ST_REMOTEPROC
 	  processor framework.
 	  This can be either built-in or a loadable module.
 
+config ST_SLIM_REMOTEPROC
+	tristate
+	select REMOTEPROC
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 6dfb62e..924f0cb 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -16,3 +16,4 @@  obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
 obj-$(CONFIG_QCOM_WCNSS_IRIS)		+= qcom_wcnss_iris.o
 obj-$(CONFIG_QCOM_WCNSS_PIL)		+= qcom_wcnss.o
 obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
+obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
new file mode 100644
index 0000000..1484e97
--- /dev/null
+++ b/drivers/remoteproc/st_slim_rproc.c
@@ -0,0 +1,364 @@ 
+/*
+ * SLIM core rproc driver
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ *
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+#include <linux/remoteproc/st_slim_rproc.h>
+#include "remoteproc_internal.h"
+
+/* SLIM core registers */
+#define SLIM_ID_OFST		0x0
+#define SLIM_VER_OFST		0x4
+
+#define SLIM_EN_OFST		0x8
+#define SLIM_EN_RUN			BIT(0)
+
+#define SLIM_CLK_GATE_OFST	0xC
+#define SLIM_CLK_GATE_DIS		BIT(0)
+#define SLIM_CLK_GATE_RESET		BIT(2)
+
+#define SLIM_SLIM_PC_OFST	0x20
+
+/* DMEM registers */
+#define SLIM_REV_ID_OFST	0x0
+#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
+#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
+#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
+#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
+
+
+/* peripherals registers */
+#define SLIM_STBUS_SYNC_OFST	0xF88
+#define SLIM_STBUS_SYNC_DIS		BIT(0)
+
+#define SLIM_INT_SET_OFST	0xFD4
+#define SLIM_INT_CLR_OFST	0xFD8
+#define SLIM_INT_MASK_OFST	0xFDC
+
+#define SLIM_CMD_CLR_OFST	0xFC8
+#define SLIM_CMD_MASK_OFST	0xFCC
+
+static const char *mem_names[ST_SLIM_MEM_MAX] = {
+	[ST_SLIM_DMEM]	= "dmem",
+	[ST_SLIM_IMEM]	= "imem",
+};
+
+static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
+{
+	int clk, err;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
+		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
+		if (IS_ERR(slim_rproc->clks[clk])) {
+			err = PTR_ERR(slim_rproc->clks[clk]);
+			if (err == -EPROBE_DEFER)
+				goto err_put_clks;
+			slim_rproc->clks[clk] = NULL;
+			break;
+		}
+	}
+
+	return 0;
+
+err_put_clks:
+	while (--clk >= 0)
+		clk_put(slim_rproc->clks[clk]);
+
+	return err;
+}
+
+static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
+{
+	int clk;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
+		clk_disable_unprepare(slim_rproc->clks[clk]);
+}
+
+static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
+{
+	int clk, ret;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
+		ret = clk_prepare_enable(slim_rproc->clks[clk]);
+		if (ret)
+			goto err_disable_clks;
+	}
+
+	return 0;
+
+err_disable_clks:
+	while (--clk >= 0)
+		clk_disable_unprepare(slim_rproc->clks[clk]);
+
+	return ret;
+}
+
+/*
+ * Remoteproc slim specific device handlers
+ */
+static int slim_rproc_start(struct rproc *rproc)
+{
+	struct device *dev = &rproc->dev;
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	unsigned long hw_id, hw_ver, fw_rev;
+	u32 val;
+
+	/* disable CPU pipeline clock & reset CPU pipeline */
+	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
+	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	/* disable SLIM core STBus sync */
+	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
+
+	/* enable cpu pipeline clock */
+	writel(!SLIM_CLK_GATE_DIS,
+		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	/* clear int & cmd mailbox */
+	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
+	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
+
+	/* enable all channels cmd & int */
+	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
+	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
+
+	/* enable cpu */
+	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
+
+	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
+	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
+
+	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
+			SLIM_REV_ID_OFST);
+
+	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
+		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
+		 hw_id, hw_ver);
+
+	return 0;
+}
+
+static int slim_rproc_stop(struct rproc *rproc)
+{
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	u32 val;
+
+	/* mask all (cmd & int) channels */
+	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
+	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
+
+	/* disable cpu pipeline clock */
+	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
+
+	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
+	if (val & SLIM_EN_RUN)
+		dev_warn(&rproc->dev, "Failed to disable SLIM");
+
+	dev_dbg(&rproc->dev, "slim stopped\n");
+
+	return 0;
+}
+
+static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+{
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	void *va = NULL;
+	int i;
+
+	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
+		if (da != slim_rproc->mem[i].bus_addr)
+			continue;
+
+		if (len <= slim_rproc->mem[i].size) {
+			/* __force to make sparse happy with type conversion */
+			va = (__force void *)slim_rproc->mem[i].cpu_addr;
+			break;
+		}
+	}
+
+	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
+
+	return va;
+}
+
+static struct rproc_ops slim_rproc_ops = {
+	.start		= slim_rproc_start,
+	.stop		= slim_rproc_stop,
+	.da_to_va       = slim_rproc_da_to_va,
+};
+
+/*
+ * Firmware handler operations: sanity, boot address, load ...
+ */
+
+static struct resource_table empty_rsc_tbl = {
+	.ver = 1,
+	.num = 0,
+};
+
+static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
+					       const struct firmware *fw,
+					       int *tablesz)
+{
+	*tablesz = sizeof(empty_rsc_tbl);
+	return &empty_rsc_tbl;
+}
+
+static struct rproc_fw_ops slim_rproc_fw_ops = {
+	.find_rsc_table = slim_rproc_find_rsc_table,
+};
+
+/**
+ * st_slim_rproc_alloc() - allocate and initialise slim rproc
+ * @pdev: Pointer to the platform_device struct
+ * @fw_name: Name of firmware for rproc to use
+ *
+ * Function for allocating and initialising a slim rproc for use by
+ * device drivers whose IP is based around the SLIM core. It
+ * obtains and enables any clocks required by the SLIM core and also
+ * ioremaps the various IO.
+ *
+ * Returns st_slim_rproc pointer or PTR_ERR() on error.
+ */
+
+struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
+				char *fw_name)
+{
+	struct device *dev = &pdev->dev;
+	struct st_slim_rproc *slim_rproc;
+	struct device_node *np = dev->of_node;
+	struct rproc *rproc;
+	struct resource *res;
+	int err, i;
+	const struct rproc_fw_ops *elf_ops;
+
+	if (!fw_name)
+		return ERR_PTR(-EINVAL);
+
+	if (!of_device_is_compatible(np, "st,slim-rproc"))
+		return ERR_PTR(-EINVAL);
+
+	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
+			fw_name, sizeof(*slim_rproc));
+	if (!rproc)
+		return ERR_PTR(-ENOMEM);
+
+	rproc->has_iommu = false;
+
+	slim_rproc = rproc->priv;
+	slim_rproc->rproc = rproc;
+
+	elf_ops = rproc->fw_ops;
+	/* Use some generic elf ops */
+	slim_rproc_fw_ops.load = elf_ops->load;
+	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
+
+	rproc->fw_ops = &slim_rproc_fw_ops;
+
+	/* get imem and dmem */
+	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
+		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+						mem_names[i]);
+
+		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
+		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
+			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
+			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
+			goto err;
+		}
+		slim_rproc->mem[i].bus_addr = res->start;
+		slim_rproc->mem[i].size = resource_size(res);
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
+	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
+	if (IS_ERR(slim_rproc->slimcore)) {
+		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
+		err = PTR_ERR(slim_rproc->slimcore);
+		goto err;
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
+	slim_rproc->peri = devm_ioremap_resource(dev, res);
+	if (IS_ERR(slim_rproc->peri)) {
+		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
+		err = PTR_ERR(slim_rproc->peri);
+		goto err;
+	}
+
+	err = slim_clk_get(slim_rproc, dev);
+	if (err)
+		goto err;
+
+	err = slim_clk_enable(slim_rproc);
+	if (err) {
+		dev_err(dev, "Failed to enable clocks\n");
+		goto err_clk_put;
+	}
+
+	/* Register as a remoteproc device */
+	err = rproc_add(rproc);
+	if (err) {
+		dev_err(dev, "registration of slim remoteproc failed\n");
+		goto err_clk_dis;
+	}
+
+	return slim_rproc;
+
+err_clk_dis:
+	slim_clk_disable(slim_rproc);
+err_clk_put:
+	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
+		clk_put(slim_rproc->clks[i]);
+err:
+	rproc_put(rproc);
+	return ERR_PTR(err);
+}
+EXPORT_SYMBOL(st_slim_rproc_alloc);
+
+/**
+  * st_slim_rproc_put() - put slim rproc resources
+  * @slim_rproc: Pointer to the st_slim_rproc struct
+  *
+  * Function for calling respective _put() functions on slim_rproc resources.
+  *
+  */
+void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
+{
+	int clk;
+
+	if (!slim_rproc)
+		return;
+
+	slim_clk_disable(slim_rproc);
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
+		clk_put(slim_rproc->clks[clk]);
+
+	rproc_del(slim_rproc->rproc);
+	rproc_put(slim_rproc->rproc);
+}
+EXPORT_SYMBOL(st_slim_rproc_put);
+
+MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
+MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
new file mode 100644
index 0000000..4155556
--- /dev/null
+++ b/include/linux/remoteproc/st_slim_rproc.h
@@ -0,0 +1,58 @@ 
+/*
+ * SLIM core rproc driver header
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ *
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef _ST_REMOTEPROC_SLIM_H
+#define _ST_REMOTEPROC_SLIM_H
+
+#define ST_SLIM_MEM_MAX 2
+#define ST_SLIM_MAX_CLK 4
+
+enum {
+	ST_SLIM_DMEM,
+	ST_SLIM_IMEM,
+};
+
+/**
+ * struct st_slim_mem - slim internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @size: Size of the memory region
+ */
+struct st_slim_mem {
+	void __iomem *cpu_addr;
+	phys_addr_t bus_addr;
+	size_t size;
+};
+
+/**
+ * struct st_slim_rproc - SLIM slim core
+ * @rproc: rproc handle
+ * @mem: slim memory information
+ * @slimcore: slim slimcore regs
+ * @peri: slim peripheral regs
+ * @clks: slim clocks
+ */
+struct st_slim_rproc {
+	struct rproc *rproc;
+	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
+	void __iomem *slimcore;
+	void __iomem *peri;
+
+	/* st_slim_rproc private */
+	struct clk *clks[ST_SLIM_MAX_CLK];
+};
+
+struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
+					char *fw_name);
+void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
+
+#endif