Re: [PATCH] tidspbridge: Fix compilation

[Omar Ramirez Luna]

Hi,

On Thu, Feb 28, 2013 at 11:51 AM, Pali Rohár  wrote:
> Fix includes and use clk_prepare_enable/clk_disable_unprepare
>
> Signed-off-by: Pali Rohár 
> Signed-off-by: Joni Lapilainen 
> ---
>  drivers/staging/tidspbridge/core/dsp-clock.c  |   16 
>  drivers/staging/tidspbridge/core/tiomap3430.c |2 ++
>  drivers/staging/tidspbridge/core/tiomap_io.c  |2 ++
>  drivers/staging/tidspbridge/core/wdt.c|8 
>  4 files changed, 16 insertions(+), 12 deletions(-)

AFAIK, this has been taken care in the past by:

e16a922a staging: tidspbridge: use prepare/unprepare on dsp clocks
fe025085 staging: tidspbridge: Fix build breakage due to splitting CM functions

Would you mind pointing the target for your patches? Perhaps stable?

Cheers,

Omar
--
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] tidspbridge: Fix compilation

[Omar Ramirez Luna]

Hi,

On Thu, Feb 28, 2013 at 11:51 AM, Pali Rohár pali.ro...@gmail.com wrote:
 Fix includes and use clk_prepare_enable/clk_disable_unprepare

 Signed-off-by: Pali Rohár pali.ro...@gmail.com
 Signed-off-by: Joni Lapilainen joni.lapilai...@gmail.com
 ---
  drivers/staging/tidspbridge/core/dsp-clock.c  |   16 
  drivers/staging/tidspbridge/core/tiomap3430.c |2 ++
  drivers/staging/tidspbridge/core/tiomap_io.c  |2 ++
  drivers/staging/tidspbridge/core/wdt.c|8 
  4 files changed, 16 insertions(+), 12 deletions(-)

AFAIK, this has been taken care in the past by:

e16a922a staging: tidspbridge: use prepare/unprepare on dsp clocks
fe025085 staging: tidspbridge: Fix build breakage due to splitting CM functions

Would you mind pointing the target for your patches? Perhaps stable?

Cheers,

Omar
--
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/9] mailbox: OMAP: introduce mailbox framework

[Omar Ramirez Luna]

On Wed, Jan 9, 2013 at 6:29 AM, Loic PALLARDY  wrote:
> Hi Vaibhav,
>
> On 01/09/2013 01:11 PM, Bedia, Vaibhav wrote:
>> Hi Loic,
>>
>> On Fri, Dec 21, 2012 at 16:23:24, Loic PALLARDY wrote:
>>>
>>>
>>> On 12/21/2012 11:49 AM, Bedia, Vaibhav wrote:
 On Fri, Dec 21, 2012 at 14:24:26, Loic PALLARDY wrote:
>
 I have a few patches which are dependent on this patch series.
 Could you please keep me in cc for the future versions.

>>> Sure, I'll.
>>>
>>
>> When do you plan to post an updated version of these patches?
> I'm synchronizing with Omar to include TI RPMsg and tidspbridge patches
> in next update.
> So I plan update for end of the week, beginning of next week.

Here are my patches, I didn't post them to the list since they are
meant to be squashed, I also prepared a squashed version of the
original set, in case it is easier to take that one, all rebased into
3.8-rc1. Branches: mailbox-3.8-rc1-separate-changes and
mailbox-3.8-rc1, respectively.

>From tree: https://github.com/omarrmz/upstream-wip

Cheers,

Omar
--
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/9] mailbox: OMAP: introduce mailbox framework

[Omar Ramirez Luna]

On Wed, Jan 9, 2013 at 6:29 AM, Loic PALLARDY loic.palla...@st.com wrote:
 Hi Vaibhav,

 On 01/09/2013 01:11 PM, Bedia, Vaibhav wrote:
 Hi Loic,

 On Fri, Dec 21, 2012 at 16:23:24, Loic PALLARDY wrote:


 On 12/21/2012 11:49 AM, Bedia, Vaibhav wrote:
 On Fri, Dec 21, 2012 at 14:24:26, Loic PALLARDY wrote:

 I have a few patches which are dependent on this patch series.
 Could you please keep me in cc for the future versions.

 Sure, I'll.


 When do you plan to post an updated version of these patches?
 I'm synchronizing with Omar to include TI RPMsg and tidspbridge patches
 in next update.
 So I plan update for end of the week, beginning of next week.

Here are my patches, I didn't post them to the list since they are
meant to be squashed, I also prepared a squashed version of the
original set, in case it is easier to take that one, all rebased into
3.8-rc1. Branches: mailbox-3.8-rc1-separate-changes and
mailbox-3.8-rc1, respectively.

From tree: https://github.com/omarrmz/upstream-wip

Cheers,

Omar
--
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] mfd, TWL4030: TWL4030 need select REGMAP_I2C

[Omar Ramirez Luna]

On Thu, Jan 10, 2013 at 4:07 AM, Omar Ramirez Luna
 wrote:
> Hi,
>
> On Mon, Dec 31, 2012 at 4:03 AM, Peter Ujfalusi  wrote:
>> On 12/24/2012 03:19 PM, Chuansheng Liu wrote:
>>> This patch fix the below build error:
>>> drivers/built-in.o: In function `twl_probe':
>>> drivers/mfd/twl-core.c:1256: undefined reference to `devm_regmap_init_i2c'
>>> make: *** [vmlinux] Error 1
>>
>> Thanks Liu, I have missed this one.
>>
>> Acked-by: Peter Ujfalusi 
>
> Mind taking mine, it was sent before this one :)
>
> https://patchwork.kernel.org/patch/1908991/

Actually it looks like Liu beat me by a few hours, so please ignore
mine and the noise.

Cheers,

Omar
--
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] mfd, TWL4030: TWL4030 need select REGMAP_I2C

[Omar Ramirez Luna]

Hi,

On Mon, Dec 31, 2012 at 4:03 AM, Peter Ujfalusi  wrote:
> On 12/24/2012 03:19 PM, Chuansheng Liu wrote:
>> This patch fix the below build error:
>> drivers/built-in.o: In function `twl_probe':
>> drivers/mfd/twl-core.c:1256: undefined reference to `devm_regmap_init_i2c'
>> make: *** [vmlinux] Error 1
>
> Thanks Liu, I have missed this one.
>
> Acked-by: Peter Ujfalusi 

Mind taking mine, it was sent before this one :)

https://patchwork.kernel.org/patch/1908991/

Cheers,

Omar
--
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] mfd, TWL4030: TWL4030 need select REGMAP_I2C

[Omar Ramirez Luna]

Hi,

On Mon, Dec 31, 2012 at 4:03 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 On 12/24/2012 03:19 PM, Chuansheng Liu wrote:
 This patch fix the below build error:
 drivers/built-in.o: In function `twl_probe':
 drivers/mfd/twl-core.c:1256: undefined reference to `devm_regmap_init_i2c'
 make: *** [vmlinux] Error 1

 Thanks Liu, I have missed this one.

 Acked-by: Peter Ujfalusi peter.ujfal...@ti.com

Mind taking mine, it was sent before this one :)

https://patchwork.kernel.org/patch/1908991/

Cheers,

Omar
--
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] mfd, TWL4030: TWL4030 need select REGMAP_I2C

[Omar Ramirez Luna]

On Thu, Jan 10, 2013 at 4:07 AM, Omar Ramirez Luna
omar.rami...@copitl.com wrote:
 Hi,

 On Mon, Dec 31, 2012 at 4:03 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 On 12/24/2012 03:19 PM, Chuansheng Liu wrote:
 This patch fix the below build error:
 drivers/built-in.o: In function `twl_probe':
 drivers/mfd/twl-core.c:1256: undefined reference to `devm_regmap_init_i2c'
 make: *** [vmlinux] Error 1

 Thanks Liu, I have missed this one.

 Acked-by: Peter Ujfalusi peter.ujfal...@ti.com

 Mind taking mine, it was sent before this one :)

 https://patchwork.kernel.org/patch/1908991/

Actually it looks like Liu beat me by a few hours, so please ignore
mine and the noise.

Cheers,

Omar
--
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: [Suggestion] drivers/staging/tidspbridge: strcpy and strncpy, src length checking issue.

[Omar Ramirez Luna]

Hi,

On Thu, Dec 13, 2012 at 9:50 PM, Chen Gang  wrote:
>   in drivers/staging/tidspbridge/rmgr/proc.c:
>
> if strlen(drv_datap->base_img) == size, will pass checking (line 397)
> the size is the full length of exec_file (line 382, line 468..469)
> strcpy causes issue: src len is strlen(drv_datap->base_img) + '\0'. (line 
> 400)

Good catch.

> strncpy seems also has issue: need use size instead of strlen(iva_img) + 
> 1. (line 402..403)

This code is not used, it is best to remove it.

Cheers,

Omar
--
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: [Suggestion] drivers/staging/tidspbridge: strcpy and strncpy, src length checking issue.

[Omar Ramirez Luna]

Hi,

On Sun, Dec 30, 2012 at 9:28 PM, Chen Gang  wrote:
>   is it suitable to send a patch for it, by me ?

Thanks for your suggestions, I have created the patches and will
submit them soon, but feel free to submit patches for any other
suggestions in future.

Cheers,

Omar
--
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: [Suggestion] drivers/staging/tidspbridge: strcpy and strncpy, src length checking issue.

[Omar Ramirez Luna]

Hi,

On Sun, Dec 30, 2012 at 9:28 PM, Chen Gang gang.c...@asianux.com wrote:
   is it suitable to send a patch for it, by me ?

Thanks for your suggestions, I have created the patches and will
submit them soon, but feel free to submit patches for any other
suggestions in future.

Cheers,

Omar
--
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: [Suggestion] drivers/staging/tidspbridge: strcpy and strncpy, src length checking issue.

[Omar Ramirez Luna]

Hi,

On Thu, Dec 13, 2012 at 9:50 PM, Chen Gang gang.c...@asianux.com wrote:
   in drivers/staging/tidspbridge/rmgr/proc.c:

 if strlen(drv_datap-base_img) == size, will pass checking (line 397)
 the size is the full length of exec_file (line 382, line 468..469)
 strcpy causes issue: src len is strlen(drv_datap-base_img) + '\0'. (line 
 400)

Good catch.

 strncpy seems also has issue: need use size instead of strlen(iva_img) + 
 1. (line 402..403)

This code is not used, it is best to remove it.

Cheers,

Omar
--
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: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).

[Omar Ramirez Luna]

On Tue, Dec 25, 2012 at 7:56 PM, Chen Gang  wrote:
> 于 2012年12月24日 22:26, Omar Ramirez Luna 写道:
>>>   b: version merging issue:
>>> > in drivers/staging/tidspbridge/core/_tiomap.h
>>> > need use "#include " instead of "#include 
>>> > "
>>> > the macro OMAP3430_CM_AUTOIDLE_PLL has already move from 
>>> > cm2xxx_3xxx.h to cm3xxx.h.
>>> >   (it seems arch/arm/mach-omap2/ is not a suitable place for 
>>> > including, but we have to)
>>> > if not change, compiling will be failed.
>
>   also please help checking this issue, thanks.

I also sent a patch for this:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82565.html

However, I just saw this one which was sent 6 days ago:

https://patchwork.kernel.org/patch/1895081/

The latter includes the new header file, mine just the definitions
needed, any approach is fine by me as they both fix the compile break.

Cheers,

Omar
--
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: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).

[Omar Ramirez Luna]

On Tue, Dec 25, 2012 at 7:56 PM, Chen Gang gang.c...@asianux.com wrote:
 于 2012年12月24日 22:26, Omar Ramirez Luna 写道:
   b: version merging issue:
  in drivers/staging/tidspbridge/core/_tiomap.h
  need use #include mach-omap2/cm3xxx.h instead of #include 
  mach-omap2/cm2xxx_3xxx.h
  the macro OMAP3430_CM_AUTOIDLE_PLL has already move from 
  cm2xxx_3xxx.h to cm3xxx.h.
(it seems arch/arm/mach-omap2/ is not a suitable place for 
  including, but we have to)
  if not change, compiling will be failed.

   also please help checking this issue, thanks.

I also sent a patch for this:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82565.html

However, I just saw this one which was sent 6 days ago:

https://patchwork.kernel.org/patch/1895081/

The latter includes the new header file, mine just the definitions
needed, any approach is fine by me as they both fix the compile break.

Cheers,

Omar
--
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: [Suggestion] drivers/staging/tidspbridge: strcpy and strncpy, src length checking issue.

[Omar Ramirez Luna]

Hi Gchen,

On Mon, Dec 17, 2012 at 8:40 PM, Chen Gang  wrote:
> Hello Omar Ramirez Luna:
>
>   excuse me to bother you (maybe you are busy in these days).
>   please help checking this suggestion when you have free time.

Yes, I'm checking your suggestions, I was a little busy last week, for
the compile breaks I had a patch but I was waiting for them to show on
staging 3.8-rc1.

> By the way:
>   this week, I need work for 2 patches which relative with usb sub-system.
>   if still get no reply for tidspbridge until next week.
> I should work for it, it is my duty (since I have provided 'suggestion' 
> to it).
> "work for it" means:
>if tidspbridge is still useful
>  I need construct relative environments for unit test.
>  then provide relative patches.
>else (useless)
>  I need delete it from Open Source.
>  (since it can not pass compiling, and no response from *@ti.com, it 
> almost means useless)

Please DON'T assume it's useless if you don't get replies from @ti.com .

>  (at least, fix the 2 compiling issues which I have suggested, can 
> pass compiling)

Done.

Cheers,

Omar
--
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: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).

[Omar Ramirez Luna]

Hi,

On Thu, Dec 13, 2012 at 7:30 PM, Chen Gang  wrote:
>   also another suggestions:
> I built ti otmap with ti dsp bridge by arm cross-compiler under i386 
> platform.
> the version tag is next-20121213
> I met 2 compiling issues.
>
>   a: module dependency:
> Multifunction device drivers --> Texas Instruments 
> TWL/4030/TWL5030 is required for TI OTMAP.
> it need depend on CONFIG_REGMAP (maybe also inculde CONFIG_REGMAP*)
> if CONFIG_REGMAP* not defined, building will be failed.

This is not related to tidspbridge, I sent a patch anyway as it looks
to be a valid build dependency bug.

>   b: version merging issue:
> in drivers/staging/tidspbridge/core/_tiomap.h
> need use "#include " instead of "#include 
> "
> the macro OMAP3430_CM_AUTOIDLE_PLL has already move from 
> cm2xxx_3xxx.h to cm3xxx.h.
>   (it seems arch/arm/mach-omap2/ is not a suitable place for 
> including, but we have to)
> if not change, compiling will be failed.

Done.

Cheers,

Omar
--
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] mfd: twl4030: TWL4030_CORE needs REGMAP and REGMAP_I2C

[Omar Ramirez Luna]

Selecting REGMAP_I2C defaults REGMAP to "y", no need to
explicitly select it.

This fixes:

- Because of REGMAP, a bunch of:
drivers/mfd/twl-core.c:221:29:
error: array type has incomplete element type
drivers/mfd/twl-core.c:224:3:
error: field name not in record or union initializer
drivers/mfd/twl-core.c:224:3:
error: (near initialization for 'twl4030_regmap_config')

- Because of REGMAP_I2C:
drivers/mfd/twl-core.c: In function 'twl_probe':
drivers/mfd/twl-core.c:1256:3: error: implicit declaration of function
'devm_regmap_init_i2c' [-Werror=implicit-function-declaration]

Reported-by: Chen Gang 
Signed-off-by: Omar Ramirez Luna 
---
 drivers/mfd/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 1c0abd4..47ad4e2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -292,6 +292,7 @@ config TWL4030_CORE
bool "Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support"
depends on I2C=y && GENERIC_HARDIRQS
select IRQ_DOMAIN
+   select REGMAP_I2C
help
  Say yes here if you have TWL4030 / TWL6030 family chip on your board.
  This core driver provides register access and IRQ handling
-- 
1.7.4.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/

[PATCH] mfd: twl4030: TWL4030_CORE needs REGMAP and REGMAP_I2C

[Omar Ramirez Luna]

Selecting REGMAP_I2C defaults REGMAP to y, no need to
explicitly select it.

This fixes:

- Because of REGMAP, a bunch of:
drivers/mfd/twl-core.c:221:29:
error: array type has incomplete element type
drivers/mfd/twl-core.c:224:3:
error: field name not in record or union initializer
drivers/mfd/twl-core.c:224:3:
error: (near initialization for 'twl4030_regmap_config')

- Because of REGMAP_I2C:
drivers/mfd/twl-core.c: In function 'twl_probe':
drivers/mfd/twl-core.c:1256:3: error: implicit declaration of function
'devm_regmap_init_i2c' [-Werror=implicit-function-declaration]

Reported-by: Chen Gang gang.c...@asianux.com
Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---
 drivers/mfd/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 1c0abd4..47ad4e2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -292,6 +292,7 @@ config TWL4030_CORE
bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support
depends on I2C=y  GENERIC_HARDIRQS
select IRQ_DOMAIN
+   select REGMAP_I2C
help
  Say yes here if you have TWL4030 / TWL6030 family chip on your board.
  This core driver provides register access and IRQ handling
-- 
1.7.4.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: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).

[Omar Ramirez Luna]

Hi,

On Thu, Dec 13, 2012 at 7:30 PM, Chen Gang gang.c...@asianux.com wrote:
   also another suggestions:
 I built ti otmap with ti dsp bridge by arm cross-compiler under i386 
 platform.
 the version tag is next-20121213
 I met 2 compiling issues.

   a: module dependency:
 Multifunction device drivers -- Texas Instruments 
 TWL/4030/TWL5030 is required for TI OTMAP.
 it need depend on CONFIG_REGMAP (maybe also inculde CONFIG_REGMAP*)
 if CONFIG_REGMAP* not defined, building will be failed.

This is not related to tidspbridge, I sent a patch anyway as it looks
to be a valid build dependency bug.

   b: version merging issue:
 in drivers/staging/tidspbridge/core/_tiomap.h
 need use #include mach-omap2/cm3xxx.h instead of #include 
 mach-omap2/cm2xxx_3xxx.h
 the macro OMAP3430_CM_AUTOIDLE_PLL has already move from 
 cm2xxx_3xxx.h to cm3xxx.h.
   (it seems arch/arm/mach-omap2/ is not a suitable place for 
 including, but we have to)
 if not change, compiling will be failed.

Done.

Cheers,

Omar
--
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: [Suggestion] drivers/staging/tidspbridge: strcpy and strncpy, src length checking issue.

[Omar Ramirez Luna]

Hi Gchen,

On Mon, Dec 17, 2012 at 8:40 PM, Chen Gang gang.c...@asianux.com wrote:
 Hello Omar Ramirez Luna:

   excuse me to bother you (maybe you are busy in these days).
   please help checking this suggestion when you have free time.

Yes, I'm checking your suggestions, I was a little busy last week, for
the compile breaks I had a patch but I was waiting for them to show on
staging 3.8-rc1.

 By the way:
   this week, I need work for 2 patches which relative with usb sub-system.
   if still get no reply for tidspbridge until next week.
 I should work for it, it is my duty (since I have provided 'suggestion' 
 to it).
 work for it means:
if tidspbridge is still useful
  I need construct relative environments for unit test.
  then provide relative patches.
else (useless)
  I need delete it from Open Source.
  (since it can not pass compiling, and no response from *@ti.com, it 
 almost means useless)

Please DON'T assume it's useless if you don't get replies from @ti.com .

  (at least, fix the 2 compiling issues which I have suggested, can 
 pass compiling)

Done.

Cheers,

Omar
--
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/9] drivers: mailbox: framework creation

[Omar Ramirez Luna]

Hi Loic/Ohad,

On Fri, Dec 21, 2012 at 2:52 AM, Loic PALLARDY  wrote:
>
>
> On 12/21/2012 08:31 AM, Ohad Ben-Cohen wrote:
>> On Thu, Dec 20, 2012 at 9:19 PM, Olof Johansson  wrote:
>>> While we can make the branch stable, would it make sense to make
>>> remoteproc for omap depend on !multiplatform during the transition, to
>>> reduce dependencies a little? Either way works, but it'd be nice to
>>> keep them independent if we can.
>>
>> I'm not sure multiplatform is the culprit; OMAP's remoteproc driver
>> heavily depends on this mailbox code, and obviously breaks with this
>> patch-set if only for the the naming changes. We'll need this patch
>> set to update omap's remoteproc as well so at least we don't break
>> bisectibility, though running a sanity test before merging would be
>> even nicer (Loic I can help if you don't have a panda board).
>
> Hi Ohad,
> Yes tidspbridge and remoteproc must be adapted.
> This new mailbox fw has been tested on TI environment by Omar, who did
> adaptation at least for tidspbridge.
>
> Omar, do you have patch series ready for TI adaptations to new mailbox
> framework?
> Else I can do it, but I won't be able to test it (no panda board)

Yes, I made the changes, for tidspbridge and remoteproc, I will submit
both for review, based on this series.

Cheers,

Omar
--
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/9] drivers: mailbox: framework creation

[Omar Ramirez Luna]

Hi Loic/Ohad,

On Fri, Dec 21, 2012 at 2:52 AM, Loic PALLARDY loic.palla...@st.com wrote:


 On 12/21/2012 08:31 AM, Ohad Ben-Cohen wrote:
 On Thu, Dec 20, 2012 at 9:19 PM, Olof Johanssono...@lixom.net  wrote:
 While we can make the branch stable, would it make sense to make
 remoteproc for omap depend on !multiplatform during the transition, to
 reduce dependencies a little? Either way works, but it'd be nice to
 keep them independent if we can.

 I'm not sure multiplatform is the culprit; OMAP's remoteproc driver
 heavily depends on this mailbox code, and obviously breaks with this
 patch-set if only for the the naming changes. We'll need this patch
 set to update omap's remoteproc as well so at least we don't break
 bisectibility, though running a sanity test before merging would be
 even nicer (Loic I can help if you don't have a panda board).

 Hi Ohad,
 Yes tidspbridge and remoteproc must be adapted.
 This new mailbox fw has been tested on TI environment by Omar, who did
 adaptation at least for tidspbridge.

 Omar, do you have patch series ready for TI adaptations to new mailbox
 framework?
 Else I can do it, but I won't be able to test it (no panda board)

Yes, I made the changes, for tidspbridge and remoteproc, I will submit
both for review, based on this series.

Cheers,

Omar
--
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: Re: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).

[Omar Ramirez Luna]

Hi Chen,

Thanks for your report.

On Wed, Dec 12, 2012 at 4:12 AM, Chen Gang  wrote:
>   excuse me,  I have to forward this mail to you.
>   I have sent it to Omar Ramirez Luna , but failed.
>(get mail delivery failed )

Please contact me with my new address (this one).

I'll take a look at these.

Cheers,

Omar
--
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: Re: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).

[Omar Ramirez Luna]

Hi Chen,

Thanks for your report.

On Wed, Dec 12, 2012 at 4:12 AM, Chen Gang gang.c...@asianux.com wrote:
   excuse me,  I have to forward this mail to you.
   I have sent it to Omar Ramirez Luna omar.rami...@ti.com, but failed.
(get mail delivery failed )

Please contact me with my new address (this one).

I'll take a look at these.

Cheers,

Omar
--
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: linux-next: manual merge of the arm-soc tree with the iommu tree

[Omar Ramirez Luna]

Hi Paul,

On Thu, Dec 6, 2012 at 6:59 PM, Paul Walmsley  wrote:
> Hi Omar,
>
> On Thu, 6 Dec 2012, Omar Ramirez Luna wrote:
>
>> I have checked next-20121206, it's OK to delete that file as the patch
>> from Paul is doing that for common clock framework migration; now the
>> only missing hunk from my original patch should apply to
>> arch/arm/mach-omap2/cclock44xx_data.c which is the file that now has
>> ipu_fck and dsp_fck (unused) clocks, I can send a patch to remove them
>> through linux-omap tree.
>
> OK, will you add the mach-omap2/omap_hwmod_44xx_data.c changes in the same
> patch?

I was planning to wait until linux-omap had the changes from iommu
tree (probably at rc1), if the merge conflict resulted in
arch/arm/mach-omap2/cclock44xx_data.c still having ipu and dsp clocks,
in this case the hwmod data changes wouldn't be needed in the patch.

Cheers,

Omar
--
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: linux-next: manual merge of the arm-soc tree with the iommu tree

[Omar Ramirez Luna]

Hi All,

On Tue, Dec 4, 2012 at 5:10 AM, Ohad Ben-Cohen  wrote:
> On Tue, Dec 4, 2012 at 1:06 PM, Joerg Roedel  wrote:
>> On Tue, Dec 04, 2012 at 03:42:03PM +1100, Stephen Rothwell wrote:
>>> Today's linux-next merge of the arm-soc tree got a conflict in
>>> arch/arm/mach-omap2/clock44xx_data.c between commit 298ea44f211d ("ARM:
>>> OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf
>>> clocks") from the iommu tree and commit 13a5b6228679 ("ARM: OMAP44xx:
>>> clock: drop obsolete clock data") from the arm-soc tree.
>>>
>>> I just deleted the file as the latter did and can carry the fix as
>>> necessary (no action is required).
>>
>> Ohad, Omar, any comment on this?
>
> I'd prefer Omar or Paul to have a look here. Looping in Tony as well.

I have checked next-20121206, it's OK to delete that file as the patch
from Paul is doing that for common clock framework migration; now the
only missing hunk from my original patch should apply to
arch/arm/mach-omap2/cclock44xx_data.c which is the file that now has
ipu_fck and dsp_fck (unused) clocks, I can send a patch to remove them
through linux-omap tree.

Cheers,

Omar
--
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: linux-next: manual merge of the arm-soc tree with the iommu tree

[Omar Ramirez Luna]

Hi All,

On Tue, Dec 4, 2012 at 5:10 AM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Tue, Dec 4, 2012 at 1:06 PM, Joerg Roedel j...@8bytes.org wrote:
 On Tue, Dec 04, 2012 at 03:42:03PM +1100, Stephen Rothwell wrote:
 Today's linux-next merge of the arm-soc tree got a conflict in
 arch/arm/mach-omap2/clock44xx_data.c between commit 298ea44f211d (ARM:
 OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf
 clocks) from the iommu tree and commit 13a5b6228679 (ARM: OMAP44xx:
 clock: drop obsolete clock data) from the arm-soc tree.

 I just deleted the file as the latter did and can carry the fix as
 necessary (no action is required).

 Ohad, Omar, any comment on this?

 I'd prefer Omar or Paul to have a look here. Looping in Tony as well.

I have checked next-20121206, it's OK to delete that file as the patch
from Paul is doing that for common clock framework migration; now the
only missing hunk from my original patch should apply to
arch/arm/mach-omap2/cclock44xx_data.c which is the file that now has
ipu_fck and dsp_fck (unused) clocks, I can send a patch to remove them
through linux-omap tree.

Cheers,

Omar
--
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: linux-next: manual merge of the arm-soc tree with the iommu tree

[Omar Ramirez Luna]

Hi Paul,

On Thu, Dec 6, 2012 at 6:59 PM, Paul Walmsley p...@pwsan.com wrote:
 Hi Omar,

 On Thu, 6 Dec 2012, Omar Ramirez Luna wrote:

 I have checked next-20121206, it's OK to delete that file as the patch
 from Paul is doing that for common clock framework migration; now the
 only missing hunk from my original patch should apply to
 arch/arm/mach-omap2/cclock44xx_data.c which is the file that now has
 ipu_fck and dsp_fck (unused) clocks, I can send a patch to remove them
 through linux-omap tree.

 OK, will you add the mach-omap2/omap_hwmod_44xx_data.c changes in the same
 patch?

I was planning to wait until linux-omap had the changes from iommu
tree (probably at rc1), if the merge conflict resulted in
arch/arm/mach-omap2/cclock44xx_data.c still having ipu and dsp clocks,
in this case the hwmod data changes wouldn't be needed in the patch.

Cheers,

Omar
--
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 v5 0/5] OMAP: iommu: hwmod, reset handling and runtime PM

[Omar Ramirez Luna]

These patches are needed for remoteproc to work on OMAP4.

Introduced iommu hwmod support for OMAP3 (iva, isp) and
OMAP4 (ipu, dsp), along with the corresponding runtime PM
and routines to deassert reset lines, enable/disable clocks
and configure sysc registers.

A couple of patches were added (first two) to be clearer on
the reasons for such changes, they were previosuly bundled as part
of runtime PM changes. The last patch corresponds to a change in the
leaf clocks used and it depends on this series to work properly.

Due to single Image support, I rebased these on top of k3.7-rc5 and
DEPEND on:

[PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu
http://thread.gmane.org/gmane.linux.kernel/1387788

Minor rebasing might be needed if these are included on top of
linux-omap, since they are affected by changes on headers being
moved to include/linux/platform_data and arch/arm/mach-omap2.

Omar Ramirez Luna (5):
  iommu/omap: remove redundant clock handling on ISR
  iommu/omap: keep mmu enabled when requested
  iommu/omap: migrate to hwmod framework
  iommu/omap: adapt to runtime pm
  ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of
leaf clocks

 arch/arm/mach-omap2/clock44xx_data.c   |   22 
 arch/arm/mach-omap2/devices.c  |2 +-
 arch/arm/mach-omap2/omap-iommu.c   |  167 ++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 +-
 drivers/iommu/omap-iommu.c |   68 ++-
 drivers/iommu/omap-iommu.h |3 -
 drivers/iommu/omap-iommu2.c|   36 --
 include/linux/platform_data/iommu-omap.h   |9 +-
 8 files changed, 84 insertions(+), 227 deletions(-)

-- 
1.7.4.1

--
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 v5 2/5] iommu/omap: keep mmu enabled when requested

[Omar Ramirez Luna]

The purpose of the mmu is to handle the memory accesses requested by
its users. Typically, the mmu is bundled with the processing unit in
a single IP block, which makes them to share the same clock to be
functional.

Currently, iommu code assumes that its user will be indirectly
clocking it, but being a separate mmu driver, it should handle
its own clocks, so as long as the mmu is requested it will be
powered ON and once detached it will be powered OFF.

The remaining clock handling out of iommu_enable and iommu_disable
corresponds to paths that can be accessed through debugfs, some of
them doesn't work if the module is not enabled first, but in future
if the mmu is idled withouth freeing, these are needed to debug.

Signed-off-by: Omar Ramirez Luna 
---
 drivers/iommu/omap-iommu.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 6b1288c..f8082da 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -154,7 +154,6 @@ static int iommu_enable(struct omap_iommu *obj)
 
err = arch_iommu->enable(obj);
 
-   clk_disable(obj->clk);
return err;
 }
 
@@ -163,8 +162,6 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj)
return;
 
-   clk_enable(obj->clk);
-
arch_iommu->disable(obj);
 
clk_disable(obj->clk);
-- 
1.7.4.1

--
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 v5 4/5] iommu/omap: adapt to runtime pm

[Omar Ramirez Luna]

Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.

Due to reset sequence, pm_runtime_[get|put]_sync must be used, to
avoid possible operations with the module under reset. Because of
this and given that the driver uses spin_locks to protect their
critical sections, we must use pm_runtime_irq_safe in order for the
runtime ops to be happy, otherwise might_sleep_if checks in runtime
framework will complain.

The remaining pm_runtime out of iommu_enable and iommu_disable
corresponds to paths that can be accessed through debugfs, some of
them doesn't work if the module is not enabled first, but in future
if the mmu is idled withouth freeing, these are needed to debug.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/omap-iommu.c |1 -
 drivers/iommu/omap-iommu.c   |   40 ++---
 drivers/iommu/omap-iommu.h   |3 --
 drivers/iommu/omap-iommu2.c  |   17 
 include/linux/platform_data/iommu-omap.h |1 -
 5 files changed, 19 insertions(+), 43 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02726a6..7642fc4 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -31,7 +31,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh, 
void *unused)
return -ENOMEM;
 
pdata->name = oh->name;
-   pdata->clk_name = oh->main_clk;
pdata->nr_tlb_entries = a->nr_tlb_entries;
pdata->da_start = a->da_start;
pdata->da_end = a->da_end;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index af9b4f3..18108c14 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,13 +16,13 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -160,7 +160,7 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
 
err = arch_iommu->enable(obj);
 
@@ -177,7 +177,7 @@ static void iommu_disable(struct omap_iommu *obj)
 
arch_iommu->disable(obj);
 
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
 
if (pdata->assert_reset)
pdata->assert_reset(pdev, pdata->reset_name);
@@ -303,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
if (!obj || !obj->nr_tlb_entries || !e)
return -EINVAL;
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
 
iotlb_lock_get(obj, );
if (l.base == obj->nr_tlb_entries) {
@@ -333,7 +333,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
 
cr = iotlb_alloc_cr(obj, e);
if (IS_ERR(cr)) {
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
return PTR_ERR(cr);
}
 
@@ -347,7 +347,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
l.vict = l.base;
iotlb_lock_set(obj, );
 out:
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
return err;
 }
 
@@ -377,7 +377,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
int i;
struct cr_regs cr;
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
 
for_each_iotlb_cr(obj, obj->nr_tlb_entries, i, cr) {
u32 start;
@@ -396,7 +396,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
 
if (i == obj->nr_tlb_entries)
dev_dbg(obj->dev, "%s: no page for %08x\n", __func__, da);
@@ -410,7 +410,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
 {
struct iotlb_lock l;
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
 
l.base = 0;
l.vict = 0;
@@ -418,7 +418,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
 
iommu_write_reg(obj, 1, MMU_GFLUSH);
 
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
 }
 
 #if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
@@ -428,11 +428,11 @@ ssize_t omap_iommu_dump_ctx(struct omap_iommu *obj, char 
*buf, ssize_t bytes)
if (!obj || !buf)
return -EINVAL;
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
 
bytes = arch_iommu->dump_ctx(obj, buf, bytes);
 
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
 
  

[PATCH v5 5/5] ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks

[Omar Ramirez Luna]

This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path
from enabling modulemode inside CLKCTRL using its clk->enable_reg
field. Instead is left to _omap4_enable_module though soc_ops, as
the one in charge of this setting.

According to comments received[1] for related patches the idea is
to get rid of leaf clocks in future. So remove these two while at it.

[1] http://lkml.org/lkml/2012/8/20/226

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/clock44xx_data.c   |   22 --
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++--
 2 files changed, 2 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 6efc30c..067c486 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1316,16 +1316,6 @@ static struct clk dmic_fck = {
.clkdm_name = "abe_clkdm",
 };
 
-static struct clk dsp_fck = {
-   .name   = "dsp_fck",
-   .ops= _omap2_dflt,
-   .enable_reg = OMAP4430_CM_TESLA_TESLA_CLKCTRL,
-   .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
-   .clkdm_name = "tesla_clkdm",
-   .parent = _iva_m4x2_ck,
-   .recalc = _recalc,
-};
-
 static struct clk dss_sys_clk = {
.name   = "dss_sys_clk",
.ops= _omap2_dflt,
@@ -1696,16 +1686,6 @@ static struct clk i2c4_fck = {
.recalc = _recalc,
 };
 
-static struct clk ipu_fck = {
-   .name   = "ipu_fck",
-   .ops= _omap2_dflt,
-   .enable_reg = OMAP4430_CM_DUCATI_DUCATI_CLKCTRL,
-   .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
-   .clkdm_name = "ducati_clkdm",
-   .parent = _clk_mux_ck,
-   .recalc = _recalc,
-};
-
 static struct clk iss_ctrlclk = {
.name   = "iss_ctrlclk",
.ops= _omap2_dflt,
@@ -3151,7 +3131,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL,   "div_ts_ck",_ts_ck, 
CK_446X),
CLK(NULL,   "dmic_sync_mux_ck", _sync_mux_ck,  
CK_443X),
CLK(NULL,   "dmic_fck", _fck,  
CK_443X),
-   CLK(NULL,   "dsp_fck",  _fck,   
CK_443X),
CLK(NULL,   "dss_sys_clk",  _sys_clk,   
CK_443X),
CLK(NULL,   "dss_tv_clk",   _tv_clk,
CK_443X),
CLK(NULL,   "dss_48mhz_clk",_48mhz_clk, 
CK_443X),
@@ -3183,7 +3162,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL,   "i2c2_fck", _fck,  
CK_443X),
CLK(NULL,   "i2c3_fck", _fck,  
CK_443X),
CLK(NULL,   "i2c4_fck", _fck,  
CK_443X),
-   CLK(NULL,   "ipu_fck",  _fck,   
CK_443X),
CLK(NULL,   "iss_ctrlclk",  _ctrlclk,   
CK_443X),
CLK(NULL,   "iss_fck",  _fck,   
CK_443X),
CLK(NULL,   "iva_fck",  _fck,   
CK_443X),
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index aab5c12..1f61093 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -650,7 +650,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.mpu_irqs   = omap44xx_dsp_irqs,
.rst_lines  = omap44xx_dsp_resets,
.rst_lines_cnt  = ARRAY_SIZE(omap44xx_dsp_resets),
-   .main_clk   = "dsp_fck",
+   .main_clk   = "dpll_iva_m4x2_ck",
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_TESLA_TESLA_CLKCTRL_OFFSET,
@@ -1677,7 +1677,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
.mpu_irqs   = omap44xx_ipu_irqs,
.rst_lines  = omap44xx_ipu_resets,
.rst_lines_cnt  = ARRAY_SIZE(omap44xx_ipu_resets),
-   .main_clk   = "ipu_fck",
+   .main_clk   = "ducati_clk_mux_ck",
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
-- 
1.7.4.1

--
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 v5 3/5] iommu/omap: migrate to hwmod framework

[Omar Ramirez Luna]

Use hwmod data and device attributes to build and register an
omap device for iommu driver.

 - Update the naming convention in isp module.
 - Remove unneeded check for number of resources, as this is now
   handled by omap_device and prevents driver from loading.
 - Now unused, remove platform device and resource data, handling
   of sysconfig register for softreset purposes, use default
   latency structure.
 - Use hwmod API for reset handling.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/devices.c|2 +-
 arch/arm/mach-omap2/omap-iommu.c |  168 +++---
 drivers/iommu/omap-iommu.c   |   23 +++-
 drivers/iommu/omap-iommu2.c  |   19 
 include/linux/platform_data/iommu-omap.h |8 ++-
 5 files changed, 64 insertions(+), 156 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1002ff8..28d73c0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
 };
 
 static struct omap_iommu_arch_data omap3_isp_iommu = {
-   .name = "isp",
+   .name = "mmu_isp",
 };
 
 int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index a6a4ff8..02726a6 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,61 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include 
+#include 
+#include 
 
-#include "soc.h"
-#include "common.h"
-
-struct iommu_device {
-   resource_size_t base;
-   int irq;
-   struct iommu_platform_data pdata;
-   struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
-   {
-   .base = 0x480bd400,
-   .irq = 24 + OMAP_INTC_START,
-   .pdata = {
-   .name = "isp",
-   .nr_tlb_entries = 8,
-   .clk_name = "cam_ick",
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
-   {
-   .base = 0x5d00,
-   .irq = 28 + OMAP_INTC_START,
-   .pdata = {
-   .name = "iva2",
-   .nr_tlb_entries = 32,
-   .clk_name = "iva2_ck",
-   .da_start = 0x1100,
-   .da_end = 0xF000,
-   },
-   },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices  NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev   NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
-   {
-   .base = OMAP4_MMU1_BASE,
-   .irq = 100 + OMAP44XX_IRQ_GIC_START,
-   .pdata = {
-   .name = "ducati",
-   .nr_tlb_entries = 32,
-   .clk_name = "ipu_fck",
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-   {
-   .base = OMAP4_MMU2_BASE,
-   .irq = 28 + OMAP44XX_IRQ_GIC_START,
-   .pdata = {
-   .name = "tesla",
-   .nr_tlb_entries = 32,
-   .clk_name = "dsp_fck",
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define omap4_devices  NULL
-#define NR_OMAP4_IOMMU_DEVICES 0
-#define omap4_iommu_pdev   NULL
-#endif
-
-static struct platform_device **omap_iommu_pdev;
-
-static int __init omap_iommu_init(void)
+static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
 {
-   int i, err;
-   struct resource res[] = {
-   { .flags = IORESOURCE_MEM },
-   { .flags = IORESOURCE_IRQ },
-   };
+   struct platform_device *pdev;
+   struct iommu_platform_data *pdata;
+   struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh->dev_attr;
+   static int i;
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   pdata->name = oh->name;
+   pdata->clk_name = oh->main_clk;
+   pdata->nr_tlb_entries = a->nr_tlb_entries;
+   pdata->da_start = a->da_start;
+   pdata->da

[PATCH v5 1/5] iommu/omap: remove redundant clock handling on ISR

[Omar Ramirez Luna]

For the interrupt to be generated, the mmu clock should be already
enabled while translating a virtual address, so, this call to clock
handling is just increasing/decreasing the counter.

This works now, because its users need the same clock and they
indirectly power the mmu, in this interrupt context the handling of
clocks inside the ISR doesn't seem to be needed nor helping.

Next patch should also correct the dependency on clients to handle
iommu clocks.

Signed-off-by: Omar Ramirez Luna 
---
 drivers/iommu/omap-iommu.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index badc17c..6b1288c 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -807,9 +807,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
if (!obj->refcount)
return IRQ_NONE;
 
-   clk_enable(obj->clk);
errs = iommu_report_fault(obj, );
-   clk_disable(obj->clk);
if (errs == 0)
return IRQ_HANDLED;
 
-- 
1.7.4.1

--
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 v5 1/5] iommu/omap: remove redundant clock handling on ISR

[Omar Ramirez Luna]

For the interrupt to be generated, the mmu clock should be already
enabled while translating a virtual address, so, this call to clock
handling is just increasing/decreasing the counter.

This works now, because its users need the same clock and they
indirectly power the mmu, in this interrupt context the handling of
clocks inside the ISR doesn't seem to be needed nor helping.

Next patch should also correct the dependency on clients to handle
iommu clocks.

Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
 drivers/iommu/omap-iommu.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index badc17c..6b1288c 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -807,9 +807,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
if (!obj-refcount)
return IRQ_NONE;
 
-   clk_enable(obj-clk);
errs = iommu_report_fault(obj, da);
-   clk_disable(obj-clk);
if (errs == 0)
return IRQ_HANDLED;
 
-- 
1.7.4.1

--
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 v5 3/5] iommu/omap: migrate to hwmod framework

[Omar Ramirez Luna]

Use hwmod data and device attributes to build and register an
omap device for iommu driver.

 - Update the naming convention in isp module.
 - Remove unneeded check for number of resources, as this is now
   handled by omap_device and prevents driver from loading.
 - Now unused, remove platform device and resource data, handling
   of sysconfig register for softreset purposes, use default
   latency structure.
 - Use hwmod API for reset handling.

Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
 arch/arm/mach-omap2/devices.c|2 +-
 arch/arm/mach-omap2/omap-iommu.c |  168 +++---
 drivers/iommu/omap-iommu.c   |   23 +++-
 drivers/iommu/omap-iommu2.c  |   19 
 include/linux/platform_data/iommu-omap.h |8 ++-
 5 files changed, 64 insertions(+), 156 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1002ff8..28d73c0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
 };
 
 static struct omap_iommu_arch_data omap3_isp_iommu = {
-   .name = isp,
+   .name = mmu_isp,
 };
 
 int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index a6a4ff8..02726a6 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,61 @@
 
 #include linux/module.h
 #include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
 
 #include linux/platform_data/iommu-omap.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
 
-#include soc.h
-#include common.h
-
-struct iommu_device {
-   resource_size_t base;
-   int irq;
-   struct iommu_platform_data pdata;
-   struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
-   {
-   .base = 0x480bd400,
-   .irq = 24 + OMAP_INTC_START,
-   .pdata = {
-   .name = isp,
-   .nr_tlb_entries = 8,
-   .clk_name = cam_ick,
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
-   {
-   .base = 0x5d00,
-   .irq = 28 + OMAP_INTC_START,
-   .pdata = {
-   .name = iva2,
-   .nr_tlb_entries = 32,
-   .clk_name = iva2_ck,
-   .da_start = 0x1100,
-   .da_end = 0xF000,
-   },
-   },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices  NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev   NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
-   {
-   .base = OMAP4_MMU1_BASE,
-   .irq = 100 + OMAP44XX_IRQ_GIC_START,
-   .pdata = {
-   .name = ducati,
-   .nr_tlb_entries = 32,
-   .clk_name = ipu_fck,
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-   {
-   .base = OMAP4_MMU2_BASE,
-   .irq = 28 + OMAP44XX_IRQ_GIC_START,
-   .pdata = {
-   .name = tesla,
-   .nr_tlb_entries = 32,
-   .clk_name = dsp_fck,
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define omap4_devices  NULL
-#define NR_OMAP4_IOMMU_DEVICES 0
-#define omap4_iommu_pdev   NULL
-#endif
-
-static struct platform_device **omap_iommu_pdev;
-
-static int __init omap_iommu_init(void)
+static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
 {
-   int i, err;
-   struct resource res[] = {
-   { .flags = IORESOURCE_MEM },
-   { .flags = IORESOURCE_IRQ },
-   };
+   struct platform_device *pdev;
+   struct iommu_platform_data *pdata;
+   struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh-dev_attr;
+   static int i;
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   pdata-name = oh-name;
+   pdata-clk_name = oh-main_clk;
+   pdata-nr_tlb_entries = a-nr_tlb_entries;
+   pdata-da_start = a-da_start;
+   pdata-da_end = a-da_end;
+
+   if (oh-rst_lines_cnt == 1

[PATCH v5 5/5] ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks

[Omar Ramirez Luna]

This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path
from enabling modulemode inside CLKCTRL using its clk-enable_reg
field. Instead is left to _omap4_enable_module though soc_ops, as
the one in charge of this setting.

According to comments received[1] for related patches the idea is
to get rid of leaf clocks in future. So remove these two while at it.

[1] http://lkml.org/lkml/2012/8/20/226

Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
 arch/arm/mach-omap2/clock44xx_data.c   |   22 --
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++--
 2 files changed, 2 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 6efc30c..067c486 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1316,16 +1316,6 @@ static struct clk dmic_fck = {
.clkdm_name = abe_clkdm,
 };
 
-static struct clk dsp_fck = {
-   .name   = dsp_fck,
-   .ops= clkops_omap2_dflt,
-   .enable_reg = OMAP4430_CM_TESLA_TESLA_CLKCTRL,
-   .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
-   .clkdm_name = tesla_clkdm,
-   .parent = dpll_iva_m4x2_ck,
-   .recalc = followparent_recalc,
-};
-
 static struct clk dss_sys_clk = {
.name   = dss_sys_clk,
.ops= clkops_omap2_dflt,
@@ -1696,16 +1686,6 @@ static struct clk i2c4_fck = {
.recalc = followparent_recalc,
 };
 
-static struct clk ipu_fck = {
-   .name   = ipu_fck,
-   .ops= clkops_omap2_dflt,
-   .enable_reg = OMAP4430_CM_DUCATI_DUCATI_CLKCTRL,
-   .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
-   .clkdm_name = ducati_clkdm,
-   .parent = ducati_clk_mux_ck,
-   .recalc = followparent_recalc,
-};
-
 static struct clk iss_ctrlclk = {
.name   = iss_ctrlclk,
.ops= clkops_omap2_dflt,
@@ -3151,7 +3131,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL,   div_ts_ck,div_ts_ck, 
CK_446X),
CLK(NULL,   dmic_sync_mux_ck, dmic_sync_mux_ck,  
CK_443X),
CLK(NULL,   dmic_fck, dmic_fck,  
CK_443X),
-   CLK(NULL,   dsp_fck,  dsp_fck,   
CK_443X),
CLK(NULL,   dss_sys_clk,  dss_sys_clk,   
CK_443X),
CLK(NULL,   dss_tv_clk,   dss_tv_clk,
CK_443X),
CLK(NULL,   dss_48mhz_clk,dss_48mhz_clk, 
CK_443X),
@@ -3183,7 +3162,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL,   i2c2_fck, i2c2_fck,  
CK_443X),
CLK(NULL,   i2c3_fck, i2c3_fck,  
CK_443X),
CLK(NULL,   i2c4_fck, i2c4_fck,  
CK_443X),
-   CLK(NULL,   ipu_fck,  ipu_fck,   
CK_443X),
CLK(NULL,   iss_ctrlclk,  iss_ctrlclk,   
CK_443X),
CLK(NULL,   iss_fck,  iss_fck,   
CK_443X),
CLK(NULL,   iva_fck,  iva_fck,   
CK_443X),
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index aab5c12..1f61093 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -650,7 +650,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.mpu_irqs   = omap44xx_dsp_irqs,
.rst_lines  = omap44xx_dsp_resets,
.rst_lines_cnt  = ARRAY_SIZE(omap44xx_dsp_resets),
-   .main_clk   = dsp_fck,
+   .main_clk   = dpll_iva_m4x2_ck,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_TESLA_TESLA_CLKCTRL_OFFSET,
@@ -1677,7 +1677,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
.mpu_irqs   = omap44xx_ipu_irqs,
.rst_lines  = omap44xx_ipu_resets,
.rst_lines_cnt  = ARRAY_SIZE(omap44xx_ipu_resets),
-   .main_clk   = ipu_fck,
+   .main_clk   = ducati_clk_mux_ck,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
-- 
1.7.4.1

--
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 v5 4/5] iommu/omap: adapt to runtime pm

[Omar Ramirez Luna]

Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.

Due to reset sequence, pm_runtime_[get|put]_sync must be used, to
avoid possible operations with the module under reset. Because of
this and given that the driver uses spin_locks to protect their
critical sections, we must use pm_runtime_irq_safe in order for the
runtime ops to be happy, otherwise might_sleep_if checks in runtime
framework will complain.

The remaining pm_runtime out of iommu_enable and iommu_disable
corresponds to paths that can be accessed through debugfs, some of
them doesn't work if the module is not enabled first, but in future
if the mmu is idled withouth freeing, these are needed to debug.

Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
 arch/arm/mach-omap2/omap-iommu.c |1 -
 drivers/iommu/omap-iommu.c   |   40 ++---
 drivers/iommu/omap-iommu.h   |3 --
 drivers/iommu/omap-iommu2.c  |   17 
 include/linux/platform_data/iommu-omap.h |1 -
 5 files changed, 19 insertions(+), 43 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02726a6..7642fc4 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -31,7 +31,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh, 
void *unused)
return -ENOMEM;
 
pdata-name = oh-name;
-   pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index af9b4f3..18108c14 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,13 +16,13 @@
 #include linux/slab.h
 #include linux/interrupt.h
 #include linux/ioport.h
-#include linux/clk.h
 #include linux/platform_device.h
 #include linux/iommu.h
 #include linux/omap-iommu.h
 #include linux/mutex.h
 #include linux/spinlock.h
 #include linux/io.h
+#include linux/pm_runtime.h
 
 #include asm/cacheflush.h
 
@@ -160,7 +160,7 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
err = arch_iommu-enable(obj);
 
@@ -177,7 +177,7 @@ static void iommu_disable(struct omap_iommu *obj)
 
arch_iommu-disable(obj);
 
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
 
if (pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
@@ -303,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
if (!obj || !obj-nr_tlb_entries || !e)
return -EINVAL;
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
iotlb_lock_get(obj, l);
if (l.base == obj-nr_tlb_entries) {
@@ -333,7 +333,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
 
cr = iotlb_alloc_cr(obj, e);
if (IS_ERR(cr)) {
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
return PTR_ERR(cr);
}
 
@@ -347,7 +347,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
l.vict = l.base;
iotlb_lock_set(obj, l);
 out:
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
return err;
 }
 
@@ -377,7 +377,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
int i;
struct cr_regs cr;
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
for_each_iotlb_cr(obj, obj-nr_tlb_entries, i, cr) {
u32 start;
@@ -396,7 +396,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
 
if (i == obj-nr_tlb_entries)
dev_dbg(obj-dev, %s: no page for %08x\n, __func__, da);
@@ -410,7 +410,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
 {
struct iotlb_lock l;
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
l.base = 0;
l.vict = 0;
@@ -418,7 +418,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
 
iommu_write_reg(obj, 1, MMU_GFLUSH);
 
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
 }
 
 #if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
@@ -428,11 +428,11 @@ ssize_t omap_iommu_dump_ctx(struct omap_iommu *obj, char 
*buf, ssize_t bytes)
if (!obj || !buf)
return -EINVAL;
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
bytes = arch_iommu-dump_ctx(obj, buf, bytes);
 
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev

[PATCH v5 2/5] iommu/omap: keep mmu enabled when requested

[Omar Ramirez Luna]

The purpose of the mmu is to handle the memory accesses requested by
its users. Typically, the mmu is bundled with the processing unit in
a single IP block, which makes them to share the same clock to be
functional.

Currently, iommu code assumes that its user will be indirectly
clocking it, but being a separate mmu driver, it should handle
its own clocks, so as long as the mmu is requested it will be
powered ON and once detached it will be powered OFF.

The remaining clock handling out of iommu_enable and iommu_disable
corresponds to paths that can be accessed through debugfs, some of
them doesn't work if the module is not enabled first, but in future
if the mmu is idled withouth freeing, these are needed to debug.

Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
 drivers/iommu/omap-iommu.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 6b1288c..f8082da 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -154,7 +154,6 @@ static int iommu_enable(struct omap_iommu *obj)
 
err = arch_iommu-enable(obj);
 
-   clk_disable(obj-clk);
return err;
 }
 
@@ -163,8 +162,6 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj)
return;
 
-   clk_enable(obj-clk);
-
arch_iommu-disable(obj);
 
clk_disable(obj-clk);
-- 
1.7.4.1

--
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 v5 0/5] OMAP: iommu: hwmod, reset handling and runtime PM

[Omar Ramirez Luna]

These patches are needed for remoteproc to work on OMAP4.

Introduced iommu hwmod support for OMAP3 (iva, isp) and
OMAP4 (ipu, dsp), along with the corresponding runtime PM
and routines to deassert reset lines, enable/disable clocks
and configure sysc registers.

A couple of patches were added (first two) to be clearer on
the reasons for such changes, they were previosuly bundled as part
of runtime PM changes. The last patch corresponds to a change in the
leaf clocks used and it depends on this series to work properly.

Due to single Image support, I rebased these on top of k3.7-rc5 and
DEPEND on:

[PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu
http://thread.gmane.org/gmane.linux.kernel/1387788

Minor rebasing might be needed if these are included on top of
linux-omap, since they are affected by changes on headers being
moved to include/linux/platform_data and arch/arm/mach-omap2.

Omar Ramirez Luna (5):
  iommu/omap: remove redundant clock handling on ISR
  iommu/omap: keep mmu enabled when requested
  iommu/omap: migrate to hwmod framework
  iommu/omap: adapt to runtime pm
  ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of
leaf clocks

 arch/arm/mach-omap2/clock44xx_data.c   |   22 
 arch/arm/mach-omap2/devices.c  |2 +-
 arch/arm/mach-omap2/omap-iommu.c   |  167 ++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 +-
 drivers/iommu/omap-iommu.c |   68 ++-
 drivers/iommu/omap-iommu.h |3 -
 drivers/iommu/omap-iommu2.c|   36 --
 include/linux/platform_data/iommu-omap.h   |9 +-
 8 files changed, 84 insertions(+), 227 deletions(-)

-- 
1.7.4.1

--
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 v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm

[Omar Ramirez Luna]

On 15 November 2012 11:39, Ohad Ben-Cohen  wrote:
>> I do agree description is missing, again I thought I had done this
>> somewhere but looks like I didn't, will update these. If you think
>> these should be different patches please let me know, otherwise I
>> would like to keep a single *documented* patch.
>
> It seems like there are 3 different logical changes here:
>
> 1. remove clk_* invocations from iommu_fault_handler()
> 2. keep clocks enabled as long as iommu is enabled
> 3. convert to runtime pm
>
> If we split this to three patches in this order, you won't have to add
> and remove runtime pm functions.
>
> Let's do it, please. It's a small nuisance now, but may be really
> helpful in the future when someone tries to debug stuff and understand
> the motivation behind these changes. It'd make it much easier for you
> to document the changes, too: you have an entire commit log per
> change.

Ok, not a problem then.

Cheers,

Omar
--
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 v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm

[Omar Ramirez Luna]

Hi Ohad,

On 14 November 2012 03:54, Ohad Ben-Cohen  wrote:
> Hi Omar,
>
> On Wed, Nov 14, 2012 at 4:34 AM, Omar Ramirez Luna  
> wrote:
>> Use runtime PM functionality interfaced with hwmod enable/idle
>> functions, to replace direct clock operations and sysconfig
>> handling.
>>
>> Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
>> possible operations with the module under reset.
>
> There are some changes here that might not be trivial to understand in
> hindsight; any chance you can add more explanations (even only in the
> commit log) regarding:

I have discussed exactly the same changes in the list with Felipe, but
yes I did forget to add the explanations (I thought I did in some
version of the patch or cover-letter), but will update this
description.

Below is the discussion just in case, I'll be replying to your
comments anyway ;)

https://patchwork.kernel.org/patch/1585741/

>> @@ -160,11 +160,10 @@ static int iommu_enable(struct omap_iommu *obj)
> ...
>> -   clk_enable(obj->clk);
>> +   pm_runtime_get_sync(obj->dev);
>>
>> err = arch_iommu->enable(obj);
>>
>> -   clk_disable(obj->clk);
>> return err;
>>  }
>
> Why do we remove clk_disable here (instead of replacing it with a _put
> variant) ?

Basically, with the previous clk management, the iommu driver assumes
that its clock is shared with its client, which is the case for ipu
and dsp, but I don't like that assumption. So by doing
clock_enable/disable, the functional clock required for translations
it is indirectly provided by the user of the iommu (let's say ipu).
E.g. IPU enables the iommu and maps, at the end of the maps the clock
will be disabled, but given that ipu clock is the same the mmu stays
functional.

By changing this to get_sync only, the mmu stays enabled as long as
the iommu has been requested (except for the power transitions).

>> @@ -306,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
>> struct iotlb_entry *e)
>> if (!obj || !obj->nr_tlb_entries || !e)
>> return -EINVAL;
>>
>> -   clk_enable(obj->clk);
>> +   pm_runtime_get_sync(obj->dev);
>
> If iommu_enable no longer disables obj->clk before returning, do we
> really need to call ->get here (and in all the other similar
> instances) ?

"You can access this paths through debugfs, some of them doesn't work
if the module is not enabled first, but in future if you just want to
idle the iommu without freeing, these are needed to debug."

>
>> @@ -816,9 +813,7 @@ static irqreturn_t iommu_fault_handler(int irq, void 
>> *data)
>> if (!obj->refcount)
>> return IRQ_NONE;
>>
>> -   clk_enable(obj->clk);
>> errs = iommu_report_fault(obj, );
>> -   clk_disable(obj->clk);
>
> Why do we remove the clk_ invocations here (instead of replacing them
> with get/put variants) ?

Because in order to get an interrupt from the mmu device it implies
that the mmu was functional already (with a clock), so I don't see how
clk_enable/disable are needed here. Even if you rely on the IPU to
maintain the clock enabled.

> Most of the above questions imply this patch not only converts the
> iommu to runtime PM, but may carry additional changes that may imply
> previous implementation is sub-optimal. I hope we can clearly document
> the motivation behind these changes too (maybe even consider
> extracting them to a different patch ?).

I didn't want to extract this changes into different patches since
they could be included in this one, otherwise it would look like lines
adding and then deleting runtime pm functions.

I do agree description is missing, again I thought I had done this
somewhere but looks like I didn't, will update these. If you think
these should be different patches please let me know, otherwise I
would like to keep a single *documented* patch.

>> @@ -990,6 +981,9 @@ static int __devinit omap_iommu_probe(struct 
>> platform_device *pdev)
>> goto err_irq;
>> platform_set_drvdata(pdev, obj);
>>
>> +   pm_runtime_irq_safe(obj->dev);
>
> Let's also document why _irq_safe is needed here ?

Ok.

Thanks for the comments,

Omar
--
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 v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm

[Omar Ramirez Luna]

Hi Ohad,

On 14 November 2012 03:54, Ohad Ben-Cohen o...@wizery.com wrote:
 Hi Omar,

 On Wed, Nov 14, 2012 at 4:34 AM, Omar Ramirez Luna omar.l...@linaro.org 
 wrote:
 Use runtime PM functionality interfaced with hwmod enable/idle
 functions, to replace direct clock operations and sysconfig
 handling.

 Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
 possible operations with the module under reset.

 There are some changes here that might not be trivial to understand in
 hindsight; any chance you can add more explanations (even only in the
 commit log) regarding:

I have discussed exactly the same changes in the list with Felipe, but
yes I did forget to add the explanations (I thought I did in some
version of the patch or cover-letter), but will update this
description.

Below is the discussion just in case, I'll be replying to your
comments anyway ;)

https://patchwork.kernel.org/patch/1585741/

 @@ -160,11 +160,10 @@ static int iommu_enable(struct omap_iommu *obj)
 ...
 -   clk_enable(obj-clk);
 +   pm_runtime_get_sync(obj-dev);

 err = arch_iommu-enable(obj);

 -   clk_disable(obj-clk);
 return err;
  }

 Why do we remove clk_disable here (instead of replacing it with a _put
 variant) ?

Basically, with the previous clk management, the iommu driver assumes
that its clock is shared with its client, which is the case for ipu
and dsp, but I don't like that assumption. So by doing
clock_enable/disable, the functional clock required for translations
it is indirectly provided by the user of the iommu (let's say ipu).
E.g. IPU enables the iommu and maps, at the end of the maps the clock
will be disabled, but given that ipu clock is the same the mmu stays
functional.

By changing this to get_sync only, the mmu stays enabled as long as
the iommu has been requested (except for the power transitions).

 @@ -306,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
 struct iotlb_entry *e)
 if (!obj || !obj-nr_tlb_entries || !e)
 return -EINVAL;

 -   clk_enable(obj-clk);
 +   pm_runtime_get_sync(obj-dev);

 If iommu_enable no longer disables obj-clk before returning, do we
 really need to call -get here (and in all the other similar
 instances) ?

You can access this paths through debugfs, some of them doesn't work
if the module is not enabled first, but in future if you just want to
idle the iommu without freeing, these are needed to debug.


 @@ -816,9 +813,7 @@ static irqreturn_t iommu_fault_handler(int irq, void 
 *data)
 if (!obj-refcount)
 return IRQ_NONE;

 -   clk_enable(obj-clk);
 errs = iommu_report_fault(obj, da);
 -   clk_disable(obj-clk);

 Why do we remove the clk_ invocations here (instead of replacing them
 with get/put variants) ?

Because in order to get an interrupt from the mmu device it implies
that the mmu was functional already (with a clock), so I don't see how
clk_enable/disable are needed here. Even if you rely on the IPU to
maintain the clock enabled.

 Most of the above questions imply this patch not only converts the
 iommu to runtime PM, but may carry additional changes that may imply
 previous implementation is sub-optimal. I hope we can clearly document
 the motivation behind these changes too (maybe even consider
 extracting them to a different patch ?).

I didn't want to extract this changes into different patches since
they could be included in this one, otherwise it would look like lines
adding and then deleting runtime pm functions.

I do agree description is missing, again I thought I had done this
somewhere but looks like I didn't, will update these. If you think
these should be different patches please let me know, otherwise I
would like to keep a single *documented* patch.

 @@ -990,6 +981,9 @@ static int __devinit omap_iommu_probe(struct 
 platform_device *pdev)
 goto err_irq;
 platform_set_drvdata(pdev, obj);

 +   pm_runtime_irq_safe(obj-dev);

 Let's also document why _irq_safe is needed here ?

Ok.

Thanks for the comments,

Omar
--
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 v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm

[Omar Ramirez Luna]

On 15 November 2012 11:39, Ohad Ben-Cohen o...@wizery.com wrote:
 I do agree description is missing, again I thought I had done this
 somewhere but looks like I didn't, will update these. If you think
 these should be different patches please let me know, otherwise I
 would like to keep a single *documented* patch.

 It seems like there are 3 different logical changes here:

 1. remove clk_* invocations from iommu_fault_handler()
 2. keep clocks enabled as long as iommu is enabled
 3. convert to runtime pm

 If we split this to three patches in this order, you won't have to add
 and remove runtime pm functions.

 Let's do it, please. It's a small nuisance now, but may be really
 helpful in the future when someone tries to debug stuff and understand
 the motivation behind these changes. It'd make it much easier for you
 to document the changes, too: you have an entire commit log per
 change.

Ok, not a problem then.

Cheers,

Omar
--
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 v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm

[Omar Ramirez Luna]

Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.

Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/omap-iommu.c |1 -
 drivers/iommu/omap-iommu.c   |   45 -
 drivers/iommu/omap-iommu.h   |3 --
 drivers/iommu/omap-iommu2.c  |   17 ---
 include/linux/platform_data/iommu-omap.h |1 -
 5 files changed, 19 insertions(+), 48 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02726a6..7642fc4 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -31,7 +31,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh, 
void *unused)
return -ENOMEM;
 
pdata->name = oh->name;
-   pdata->clk_name = oh->main_clk;
pdata->nr_tlb_entries = a->nr_tlb_entries;
pdata->da_start = a->da_start;
pdata->da_end = a->da_end;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 0a6a901..b42b3d1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,13 +16,13 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -160,11 +160,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
 
err = arch_iommu->enable(obj);
 
-   clk_disable(obj->clk);
return err;
 }
 
@@ -176,11 +175,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj || !pdata)
return;
 
-   clk_enable(obj->clk);
-
arch_iommu->disable(obj);
 
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
 
if (pdata->assert_reset)
pdata->assert_reset(pdev, pdata->reset_name);
@@ -306,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
if (!obj || !obj->nr_tlb_entries || !e)
return -EINVAL;
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
 
iotlb_lock_get(obj, );
if (l.base == obj->nr_tlb_entries) {
@@ -336,7 +333,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
 
cr = iotlb_alloc_cr(obj, e);
if (IS_ERR(cr)) {
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
return PTR_ERR(cr);
}
 
@@ -350,7 +347,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
l.vict = l.base;
iotlb_lock_set(obj, );
 out:
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
return err;
 }
 
@@ -380,7 +377,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
int i;
struct cr_regs cr;
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
 
for_each_iotlb_cr(obj, obj->nr_tlb_entries, i, cr) {
u32 start;
@@ -399,7 +396,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
 
if (i == obj->nr_tlb_entries)
dev_dbg(obj->dev, "%s: no page for %08x\n", __func__, da);
@@ -413,7 +410,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
 {
struct iotlb_lock l;
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
 
l.base = 0;
l.vict = 0;
@@ -421,7 +418,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
 
iommu_write_reg(obj, 1, MMU_GFLUSH);
 
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
 }
 
 #if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
@@ -431,11 +428,11 @@ ssize_t omap_iommu_dump_ctx(struct omap_iommu *obj, char 
*buf, ssize_t bytes)
if (!obj || !buf)
return -EINVAL;
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
 
bytes = arch_iommu->dump_ctx(obj, buf, bytes);
 
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
 
return bytes;
 }
@@ -449,7 +446,7 @@ __dump_tlb_entries(struct omap_iommu *obj, struct cr_regs 
*crs, int num)
struct cr_regs tmp;
struct cr_regs *p = crs;
 
-   clk_enable(obj->clk);
+   pm_runtime_get_sync(obj->dev);
iotlb_lock_get(obj, );
 
for_each_iotlb_cr(obj, num, i, tmp) {
@@ -459,7 +456

[PATCH v4 0/2] OMAP: iommu: hwmod, reset handling and runtime PM

[Omar Ramirez Luna]

These patches are needed for remoteproc to work on OMAP4.

Introduced iommu hwmod support for OMAP3 (iva, isp) and
OMAP4 (ipu, dsp), along with the corresponding runtime PM
and routines to deassert reset lines, enable/disable clocks
and configure sysc registers.

For this series I dropped the patches already included in
mainline, along with cleanup and refactoring patches for save and
restore of mmu context, and DT bindings.

Due to single Image support, I rebased these on top of k3.7-rc5 and
DEPEND on:

[PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu
http://thread.gmane.org/gmane.linux.kernel/1387788

Minor rebasing might be needed if these are included on top of
linux-omap, since they are affected by changes on headers being
moved to include/linux/platform_data and arch/arm/mach-omap2.

Omar Ramirez Luna (2):
  ARM: OMAP3/4: iommu: migrate to hwmod framework
  ARM: OMAP3/4: iommu: adapt to runtime pm

 arch/arm/mach-omap2/devices.c|2 +-
 arch/arm/mach-omap2/omap-iommu.c |  167 +++---
 drivers/iommu/omap-iommu.c   |   68 +++--
 drivers/iommu/omap-iommu.h   |3 -
 drivers/iommu/omap-iommu2.c  |   36 ---
 include/linux/platform_data/iommu-omap.h |9 ++-
 6 files changed, 82 insertions(+), 203 deletions(-)

-- 
1.7.4.1

--
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 v4 1/2] ARM: OMAP3/4: iommu: migrate to hwmod framework

[Omar Ramirez Luna]

Use hwmod data and device attributes to build and register an
omap device for iommu driver.

 - Update the naming convention in isp module.
 - Remove unneeded check for number of resources, as this is now
   handled by omap_device and prevents driver from loading.
 - Now unused, remove platform device and resource data, handling
   of sysconfig register for softreset purposes, use default
   latency structure.
 - Use hwmod API for reset handling.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/devices.c|2 +-
 arch/arm/mach-omap2/omap-iommu.c |  168 +++---
 drivers/iommu/omap-iommu.c   |   23 +++-
 drivers/iommu/omap-iommu2.c  |   19 
 include/linux/platform_data/iommu-omap.h |8 ++-
 5 files changed, 64 insertions(+), 156 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1002ff8..28d73c0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
 };
 
 static struct omap_iommu_arch_data omap3_isp_iommu = {
-   .name = "isp",
+   .name = "mmu_isp",
 };
 
 int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index a6a4ff8..02726a6 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,61 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include 
+#include 
+#include 
 
-#include "soc.h"
-#include "common.h"
-
-struct iommu_device {
-   resource_size_t base;
-   int irq;
-   struct iommu_platform_data pdata;
-   struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
-   {
-   .base = 0x480bd400,
-   .irq = 24 + OMAP_INTC_START,
-   .pdata = {
-   .name = "isp",
-   .nr_tlb_entries = 8,
-   .clk_name = "cam_ick",
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
-   {
-   .base = 0x5d00,
-   .irq = 28 + OMAP_INTC_START,
-   .pdata = {
-   .name = "iva2",
-   .nr_tlb_entries = 32,
-   .clk_name = "iva2_ck",
-   .da_start = 0x1100,
-   .da_end = 0xF000,
-   },
-   },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices  NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev   NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
-   {
-   .base = OMAP4_MMU1_BASE,
-   .irq = 100 + OMAP44XX_IRQ_GIC_START,
-   .pdata = {
-   .name = "ducati",
-   .nr_tlb_entries = 32,
-   .clk_name = "ipu_fck",
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-   {
-   .base = OMAP4_MMU2_BASE,
-   .irq = 28 + OMAP44XX_IRQ_GIC_START,
-   .pdata = {
-   .name = "tesla",
-   .nr_tlb_entries = 32,
-   .clk_name = "dsp_fck",
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define omap4_devices  NULL
-#define NR_OMAP4_IOMMU_DEVICES 0
-#define omap4_iommu_pdev   NULL
-#endif
-
-static struct platform_device **omap_iommu_pdev;
-
-static int __init omap_iommu_init(void)
+static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
 {
-   int i, err;
-   struct resource res[] = {
-   { .flags = IORESOURCE_MEM },
-   { .flags = IORESOURCE_IRQ },
-   };
+   struct platform_device *pdev;
+   struct iommu_platform_data *pdata;
+   struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh->dev_attr;
+   static int i;
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   pdata->name = oh->name;
+   pdata->clk_name = oh->main_clk;
+   pdata->nr_tlb_entries = a->nr_tlb_entries;
+   pdata->da_start = a->da_start;
+   pdata->da

[PATCH v4 1/2] ARM: OMAP3/4: iommu: migrate to hwmod framework

[Omar Ramirez Luna]

Use hwmod data and device attributes to build and register an
omap device for iommu driver.

 - Update the naming convention in isp module.
 - Remove unneeded check for number of resources, as this is now
   handled by omap_device and prevents driver from loading.
 - Now unused, remove platform device and resource data, handling
   of sysconfig register for softreset purposes, use default
   latency structure.
 - Use hwmod API for reset handling.

Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
 arch/arm/mach-omap2/devices.c|2 +-
 arch/arm/mach-omap2/omap-iommu.c |  168 +++---
 drivers/iommu/omap-iommu.c   |   23 +++-
 drivers/iommu/omap-iommu2.c  |   19 
 include/linux/platform_data/iommu-omap.h |8 ++-
 5 files changed, 64 insertions(+), 156 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1002ff8..28d73c0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
 };
 
 static struct omap_iommu_arch_data omap3_isp_iommu = {
-   .name = isp,
+   .name = mmu_isp,
 };
 
 int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index a6a4ff8..02726a6 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,61 @@
 
 #include linux/module.h
 #include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
 
 #include linux/platform_data/iommu-omap.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
 
-#include soc.h
-#include common.h
-
-struct iommu_device {
-   resource_size_t base;
-   int irq;
-   struct iommu_platform_data pdata;
-   struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
-   {
-   .base = 0x480bd400,
-   .irq = 24 + OMAP_INTC_START,
-   .pdata = {
-   .name = isp,
-   .nr_tlb_entries = 8,
-   .clk_name = cam_ick,
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
-   {
-   .base = 0x5d00,
-   .irq = 28 + OMAP_INTC_START,
-   .pdata = {
-   .name = iva2,
-   .nr_tlb_entries = 32,
-   .clk_name = iva2_ck,
-   .da_start = 0x1100,
-   .da_end = 0xF000,
-   },
-   },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices  NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev   NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
-   {
-   .base = OMAP4_MMU1_BASE,
-   .irq = 100 + OMAP44XX_IRQ_GIC_START,
-   .pdata = {
-   .name = ducati,
-   .nr_tlb_entries = 32,
-   .clk_name = ipu_fck,
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-   {
-   .base = OMAP4_MMU2_BASE,
-   .irq = 28 + OMAP44XX_IRQ_GIC_START,
-   .pdata = {
-   .name = tesla,
-   .nr_tlb_entries = 32,
-   .clk_name = dsp_fck,
-   .da_start = 0x0,
-   .da_end = 0xF000,
-   },
-   },
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define omap4_devices  NULL
-#define NR_OMAP4_IOMMU_DEVICES 0
-#define omap4_iommu_pdev   NULL
-#endif
-
-static struct platform_device **omap_iommu_pdev;
-
-static int __init omap_iommu_init(void)
+static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
 {
-   int i, err;
-   struct resource res[] = {
-   { .flags = IORESOURCE_MEM },
-   { .flags = IORESOURCE_IRQ },
-   };
+   struct platform_device *pdev;
+   struct iommu_platform_data *pdata;
+   struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh-dev_attr;
+   static int i;
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   pdata-name = oh-name;
+   pdata-clk_name = oh-main_clk;
+   pdata-nr_tlb_entries = a-nr_tlb_entries;
+   pdata-da_start = a-da_start;
+   pdata-da_end = a-da_end;
+
+   if (oh-rst_lines_cnt == 1

[PATCH v4 0/2] OMAP: iommu: hwmod, reset handling and runtime PM

[Omar Ramirez Luna]

These patches are needed for remoteproc to work on OMAP4.

Introduced iommu hwmod support for OMAP3 (iva, isp) and
OMAP4 (ipu, dsp), along with the corresponding runtime PM
and routines to deassert reset lines, enable/disable clocks
and configure sysc registers.

For this series I dropped the patches already included in
mainline, along with cleanup and refactoring patches for save and
restore of mmu context, and DT bindings.

Due to single Image support, I rebased these on top of k3.7-rc5 and
DEPEND on:

[PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu
http://thread.gmane.org/gmane.linux.kernel/1387788

Minor rebasing might be needed if these are included on top of
linux-omap, since they are affected by changes on headers being
moved to include/linux/platform_data and arch/arm/mach-omap2.

Omar Ramirez Luna (2):
  ARM: OMAP3/4: iommu: migrate to hwmod framework
  ARM: OMAP3/4: iommu: adapt to runtime pm

 arch/arm/mach-omap2/devices.c|2 +-
 arch/arm/mach-omap2/omap-iommu.c |  167 +++---
 drivers/iommu/omap-iommu.c   |   68 +++--
 drivers/iommu/omap-iommu.h   |3 -
 drivers/iommu/omap-iommu2.c  |   36 ---
 include/linux/platform_data/iommu-omap.h |9 ++-
 6 files changed, 82 insertions(+), 203 deletions(-)

-- 
1.7.4.1

--
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 v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm

[Omar Ramirez Luna]

Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.

Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.

Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
 arch/arm/mach-omap2/omap-iommu.c |1 -
 drivers/iommu/omap-iommu.c   |   45 -
 drivers/iommu/omap-iommu.h   |3 --
 drivers/iommu/omap-iommu2.c  |   17 ---
 include/linux/platform_data/iommu-omap.h |1 -
 5 files changed, 19 insertions(+), 48 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02726a6..7642fc4 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -31,7 +31,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh, 
void *unused)
return -ENOMEM;
 
pdata-name = oh-name;
-   pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 0a6a901..b42b3d1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,13 +16,13 @@
 #include linux/slab.h
 #include linux/interrupt.h
 #include linux/ioport.h
-#include linux/clk.h
 #include linux/platform_device.h
 #include linux/iommu.h
 #include linux/omap-iommu.h
 #include linux/mutex.h
 #include linux/spinlock.h
 #include linux/io.h
+#include linux/pm_runtime.h
 
 #include asm/cacheflush.h
 
@@ -160,11 +160,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
err = arch_iommu-enable(obj);
 
-   clk_disable(obj-clk);
return err;
 }
 
@@ -176,11 +175,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj || !pdata)
return;
 
-   clk_enable(obj-clk);
-
arch_iommu-disable(obj);
 
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
 
if (pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
@@ -306,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
if (!obj || !obj-nr_tlb_entries || !e)
return -EINVAL;
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
iotlb_lock_get(obj, l);
if (l.base == obj-nr_tlb_entries) {
@@ -336,7 +333,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
 
cr = iotlb_alloc_cr(obj, e);
if (IS_ERR(cr)) {
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
return PTR_ERR(cr);
}
 
@@ -350,7 +347,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct 
iotlb_entry *e)
l.vict = l.base;
iotlb_lock_set(obj, l);
 out:
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
return err;
 }
 
@@ -380,7 +377,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
int i;
struct cr_regs cr;
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
for_each_iotlb_cr(obj, obj-nr_tlb_entries, i, cr) {
u32 start;
@@ -399,7 +396,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
 
if (i == obj-nr_tlb_entries)
dev_dbg(obj-dev, %s: no page for %08x\n, __func__, da);
@@ -413,7 +410,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
 {
struct iotlb_lock l;
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
l.base = 0;
l.vict = 0;
@@ -421,7 +418,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
 
iommu_write_reg(obj, 1, MMU_GFLUSH);
 
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
 }
 
 #if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
@@ -431,11 +428,11 @@ ssize_t omap_iommu_dump_ctx(struct omap_iommu *obj, char 
*buf, ssize_t bytes)
if (!obj || !buf)
return -EINVAL;
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
bytes = arch_iommu-dump_ctx(obj, buf, bytes);
 
-   clk_disable(obj-clk);
+   pm_runtime_put_sync(obj-dev);
 
return bytes;
 }
@@ -449,7 +446,7 @@ __dump_tlb_entries(struct omap_iommu *obj, struct cr_regs 
*crs, int num)
struct cr_regs tmp;
struct cr_regs *p = crs;
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
iotlb_lock_get(obj, saved);
 
for_each_iotlb_cr(obj, num, i, tmp) {
@@ -459,7 +456,7

Re: [PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu

[Omar Ramirez Luna]

Hi,

On 11 November 2012 03:39, Ohad Ben-Cohen  wrote:
> On Fri, Nov 2, 2012 at 9:23 PM, Tony Lindgren  wrote:
>> We need to move the iommu code to live under drivers
>> for arm common zImage support.
>
> For the iommu changes in the entire series:
>
> Acked-by: Ohad Ben-Cohen 
>
> Joerg, it might relieve some pain if this will go through Tony's tree,
> as there are some OMAP platform iommu changes coming in from Omar as
> well (part of which might have already been merged in the omap
> branches). Hope it's ok with both of you guys?
>
> Omar, do you still have any iommu changes coming in ?

Yes, I have the hwmod and runtime pm changes for iommu, I was waiting
for Tony to publish a branch with these changes to submit (as per
Tony's suggestion), but I already have the patches rebased onto these.

I will submit them.

Cheers,

Omar
--
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 v5 0/6] Move rest of omap-iommu to live in drivers/iommu

[Omar Ramirez Luna]

Hi,

On 11 November 2012 03:39, Ohad Ben-Cohen o...@wizery.com wrote:
 On Fri, Nov 2, 2012 at 9:23 PM, Tony Lindgren t...@atomide.com wrote:
 We need to move the iommu code to live under drivers
 for arm common zImage support.

 For the iommu changes in the entire series:

 Acked-by: Ohad Ben-Cohen o...@wizery.com

 Joerg, it might relieve some pain if this will go through Tony's tree,
 as there are some OMAP platform iommu changes coming in from Omar as
 well (part of which might have already been merged in the omap
 branches). Hope it's ok with both of you guys?

 Omar, do you still have any iommu changes coming in ?

Yes, I have the hwmod and runtime pm changes for iommu, I was waiting
for Tony to publish a branch with these changes to submit (as per
Tony's suggestion), but I already have the patches rebased onto these.

I will submit them.

Cheers,

Omar
--
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 v2 2/2] mailbox: split internal header from API header

[Omar Ramirez Luna]

Hi Loic,

On 6 November 2012 06:53, Loic PALLARDY  wrote:
>
>
> On 11/06/2012 03:55 AM, Omar Ramirez Luna wrote:
>> Now internal structures can remain hidden to the user and just API
>> related functions and defines are made available.
>>
>> Signed-off-by: Omar Ramirez Luna
>> ---
>>   drivers/mailbox/mailbox.c |   34 
>>   drivers/mailbox/mailbox.h |   48 
>> +
>>   include/linux/mailbox.h   |   22 +++
> I agree with the file split but I think mailbox framework API should be
> more generic.
> omap_ prefix should not be used. mailbox_ prefix will be better.

Ok.

> Message type must be more opened like for example:
> struct mailbox_msg {
> int size;
> unsigned char   header;
> unsigned char   *pdata;
> };

We can analyze the requirement for having such structure, presumably
you expect variable size messages, in OMAP case it is a 4 byte value,
but I'm open to change in order to accommodate other users needs.

Cheers,

Omar
--
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 v2 1/2] mailbox: OMAP: introduce mailbox framework

[Omar Ramirez Luna]

Hi Greg,

On 6 November 2012 02:59, Greg Kroah-Hartman  wrote:
> On Tue, Nov 06, 2012 at 09:55:52AM +0100, Linus Walleij wrote:
>> On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren  wrote:
>>
>> > Is this a public interface to the driver? If so, shouldn't the header be
>> > in include/linux somewhere?
>>
>> I think the split out of the public header is done in patch 2/2.
>
> Yes, but the names are still omap_*, which doesn't make much sense here.

Ok, I have no problem with this...

I was under the impression that moving this code out of plat-omap was
blocking single zImage support hence the minimal changes to move it to
drivers/.

I will strip the generic portions from omap_ prefixes and resend.

Cheers,

Omar
--
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 v2 1/2] mailbox: OMAP: introduce mailbox framework

[Omar Ramirez Luna]

Hi Stephen,

On 5 November 2012 21:40, Stephen Warren  wrote:
> On 11/05/2012 07:55 PM, Omar Ramirez Luna wrote:
>> Actually moving it from plat-omap, as this framework/driver code is
>> supposed to be under drivers/ folder. The framework should work with
>> the current supported OMAP processors (OMAP1+) that have mailbox and
>> can be used as a method of interprocessor communication.
>>
>> The mailbox hardware (in OMAP) uses a queued mailbox-interrupt mechanism
>> that provides a communication channel between processors through a set of
>> registers and their associated interrupt signals by sending and receiving
>> messages.
>
>> diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h
>
> Is this a public interface to the driver? If so, shouldn't the header be
> in include/linux somewhere?
>
> Is this a generic interface to any mailbox driver? If so, then I don't
> think having "omap" in the symbol names is appropriate. If the header is
> specific to the OMAP driver, I don't think using the very generic
> filename "mailbox.h" is appropriate; use omap_mailbox.h instead?

It was a mixture between the two, the next patch splits the API from
the mailbox driver interfaces.

I kept the files named as plain mailbox.[ch], in hopes that we could
progress with the cleanup after moving the files from plat-omap, as it
seems they interfere with the current single Image effort, but if it
is preferred (as it seems to be) I can resend again after removing the
omap_ prefixes from the intended-to-be generic code.

Thanks,

Omar
--
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 v2 1/2] mailbox: OMAP: introduce mailbox framework

[Omar Ramirez Luna]

Hi Stephen,

On 5 November 2012 21:40, Stephen Warren swar...@wwwdotorg.org wrote:
 On 11/05/2012 07:55 PM, Omar Ramirez Luna wrote:
 Actually moving it from plat-omap, as this framework/driver code is
 supposed to be under drivers/ folder. The framework should work with
 the current supported OMAP processors (OMAP1+) that have mailbox and
 can be used as a method of interprocessor communication.

 The mailbox hardware (in OMAP) uses a queued mailbox-interrupt mechanism
 that provides a communication channel between processors through a set of
 registers and their associated interrupt signals by sending and receiving
 messages.

 diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h

 Is this a public interface to the driver? If so, shouldn't the header be
 in include/linux somewhere?

 Is this a generic interface to any mailbox driver? If so, then I don't
 think having omap in the symbol names is appropriate. If the header is
 specific to the OMAP driver, I don't think using the very generic
 filename mailbox.h is appropriate; use omap_mailbox.h instead?

It was a mixture between the two, the next patch splits the API from
the mailbox driver interfaces.

I kept the files named as plain mailbox.[ch], in hopes that we could
progress with the cleanup after moving the files from plat-omap, as it
seems they interfere with the current single Image effort, but if it
is preferred (as it seems to be) I can resend again after removing the
omap_ prefixes from the intended-to-be generic code.

Thanks,

Omar
--
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 v2 1/2] mailbox: OMAP: introduce mailbox framework

[Omar Ramirez Luna]

Hi Greg,

On 6 November 2012 02:59, Greg Kroah-Hartman gre...@linuxfoundation.org wrote:
 On Tue, Nov 06, 2012 at 09:55:52AM +0100, Linus Walleij wrote:
 On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren swar...@wwwdotorg.org wrote:

  Is this a public interface to the driver? If so, shouldn't the header be
  in include/linux somewhere?

 I think the split out of the public header is done in patch 2/2.

 Yes, but the names are still omap_*, which doesn't make much sense here.

Ok, I have no problem with this...

I was under the impression that moving this code out of plat-omap was
blocking single zImage support hence the minimal changes to move it to
drivers/.

I will strip the generic portions from omap_ prefixes and resend.

Cheers,

Omar
--
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 v2 2/2] mailbox: split internal header from API header

[Omar Ramirez Luna]

Hi Loic,

On 6 November 2012 06:53, Loic PALLARDY loic.palla...@st.com wrote:


 On 11/06/2012 03:55 AM, Omar Ramirez Luna wrote:
 Now internal structures can remain hidden to the user and just API
 related functions and defines are made available.

 Signed-off-by: Omar Ramirez Lunaomar.l...@linaro.org
 ---
   drivers/mailbox/mailbox.c |   34 
   drivers/mailbox/mailbox.h |   48 
 +
   include/linux/mailbox.h   |   22 +++
 I agree with the file split but I think mailbox framework API should be
 more generic.
 omap_ prefix should not be used. mailbox_ prefix will be better.

Ok.

 Message type must be more opened like for example:
 struct mailbox_msg {
 int size;
 unsigned char   header;
 unsigned char   *pdata;
 };

We can analyze the requirement for having such structure, presumably
you expect variable size messages, in OMAP case it is a 4 byte value,
but I'm open to change in order to accommodate other users needs.

Cheers,

Omar
--
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 v2 2/2] mailbox: split internal header from API header

[Omar Ramirez Luna]

Now internal structures can remain hidden to the user and just API
related functions and defines are made available.

Signed-off-by: Omar Ramirez Luna 
---
 drivers/mailbox/mailbox.c |   34 
 drivers/mailbox/mailbox.h |   48 +
 include/linux/mailbox.h   |   22 +
 3 files changed, 57 insertions(+), 47 deletions(-)
 create mode 100644 include/linux/mailbox.h

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 6346ad3..aab9a13 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -116,6 +116,40 @@ out:
 }
 EXPORT_SYMBOL(omap_mbox_msg_send);
 
+void omap_mbox_save_ctx(struct omap_mbox *mbox)
+{
+   if (!mbox->ops->save_ctx) {
+   dev_err(mbox->dev, "%s:\tno save\n", __func__);
+   return;
+   }
+
+   mbox->ops->save_ctx(mbox);
+}
+EXPORT_SYMBOL(omap_mbox_save_ctx);
+
+void omap_mbox_restore_ctx(struct omap_mbox *mbox)
+{
+   if (!mbox->ops->restore_ctx) {
+   dev_err(mbox->dev, "%s:\tno restore\n", __func__);
+   return;
+   }
+
+   mbox->ops->restore_ctx(mbox);
+}
+EXPORT_SYMBOL(omap_mbox_restore_ctx);
+
+void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+   mbox->ops->enable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_enable_irq);
+
+void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+   mbox->ops->disable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_disable_irq);
+
 static void mbox_tx_tasklet(unsigned long tx_data)
 {
struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h
index cc3921e..b05f64c 100644
--- a/drivers/mailbox/mailbox.h
+++ b/drivers/mailbox/mailbox.h
@@ -8,17 +8,7 @@
 #include 
 #include 
 #include 
-
-typedef u32 mbox_msg_t;
-struct omap_mbox;
-
-typedef int __bitwise omap_mbox_irq_t;
-#define IRQ_TX ((__force omap_mbox_irq_t) 1)
-#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-
-typedef int __bitwise omap_mbox_type_t;
-#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
-#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
+#include 
 
 struct omap_mbox_ops {
omap_mbox_type_ttype;
@@ -61,45 +51,9 @@ struct omap_mbox {
struct blocking_notifier_head   notifier;
 };
 
-int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
 void omap_mbox_init_seq(struct omap_mbox *);
 
-struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
-
 int omap_mbox_register(struct device *parent, struct omap_mbox **);
 int omap_mbox_unregister(void);
 
-static inline void omap_mbox_save_ctx(struct omap_mbox *mbox)
-{
-   if (!mbox->ops->save_ctx) {
-   dev_err(mbox->dev, "%s:\tno save\n", __func__);
-   return;
-   }
-
-   mbox->ops->save_ctx(mbox);
-}
-
-static inline void omap_mbox_restore_ctx(struct omap_mbox *mbox)
-{
-   if (!mbox->ops->restore_ctx) {
-   dev_err(mbox->dev, "%s:\tno restore\n", __func__);
-   return;
-   }
-
-   mbox->ops->restore_ctx(mbox);
-}
-
-static inline void omap_mbox_enable_irq(struct omap_mbox *mbox,
-   omap_mbox_irq_t irq)
-{
-   mbox->ops->enable_irq(mbox, irq);
-}
-
-static inline void omap_mbox_disable_irq(struct omap_mbox *mbox,
-omap_mbox_irq_t irq)
-{
-   mbox->ops->disable_irq(mbox, irq);
-}
-
 #endif /* MAILBOX_H */
diff --git a/include/linux/mailbox.h b/include/linux/mailbox.h
new file mode 100644
index 000..e8e4131
--- /dev/null
+++ b/include/linux/mailbox.h
@@ -0,0 +1,22 @@
+/* mailbox.h */
+
+typedef u32 mbox_msg_t;
+struct omap_mbox;
+
+typedef int __bitwise omap_mbox_irq_t;
+#define IRQ_TX ((__force omap_mbox_irq_t) 1)
+#define IRQ_RX ((__force omap_mbox_irq_t) 2)
+
+typedef int __bitwise omap_mbox_type_t;
+#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
+#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
+
+int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
+
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
+void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
+
+void omap_mbox_save_ctx(struct omap_mbox *mbox);
+void omap_mbox_restore_ctx(struct omap_mbox *mbox);
+void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
+void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
-- 
1.7.9.5

--
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 v2 0/2] drivers: mailbox: omap-mailbox out of plat code

[Omar Ramirez Luna]

As part of plat-omap code cleanup, move omap-mailbox framework to
a newly drivers/mailbox folder, right now this code is specific to
OMAP platforms, but with some clean up it could be the base for a
generic framework; living under drivers/mailbox could give it some
exposure for interested developers to give feedback and propose changes.

In the past there was a mailbox-like driver in mach-ux500, I was
hoping both could live under the same folder, however the platform
using it, was dropped a couple of kernel releases back and with it the
other similar mailbox implementation.

However and as per Loic's comments[1], it looks like there could be
another potential mailbox candidate to live under drivers/mailbox in the
works, along with some proposed changes that could make the original
framework to evolve towards a generic implementation.

So for now, lets move the mailbox code to drivers/mailbox and split
internal structures from common API for others to use.

Based on 3.7-rc4.

1. https://lkml.org/lkml/2012/10/31/123

Omar Ramirez Luna (2):
  mailbox: OMAP: introduce mailbox framework
  mailbox: split internal header from API header

 arch/arm/configs/omap1_defconfig  |3 +-
 arch/arm/mach-omap1/Makefile  |4 -
 arch/arm/mach-omap1/mailbox.c |  199 
 arch/arm/mach-omap2/Makefile  |3 -
 arch/arm/mach-omap2/devices.c |4 +-
 arch/arm/mach-omap2/mailbox.c |  430 --
 arch/arm/plat-omap/Kconfig|   16 -
 arch/arm/plat-omap/Makefile   |3 -
 arch/arm/plat-omap/include/plat/mailbox.h |  105 ---
 arch/arm/plat-omap/mailbox.c  |  435 --
 drivers/Kconfig   |2 +
 drivers/Makefile  |1 +
 drivers/mailbox/Kconfig   |   37 +++
 drivers/mailbox/Makefile  |4 +
 drivers/mailbox/mailbox-omap1.c   |  200 
 drivers/mailbox/mailbox-omap2.c   |  430 ++
 drivers/mailbox/mailbox.c |  469 +
 drivers/mailbox/mailbox.h |   59 
 include/linux/mailbox.h   |   22 ++
 19 files changed, 1228 insertions(+), 1198 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/mailbox.c
 delete mode 100644 arch/arm/mach-omap2/mailbox.c
 delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h
 delete mode 100644 arch/arm/plat-omap/mailbox.c
 create mode 100644 drivers/mailbox/Kconfig
 create mode 100644 drivers/mailbox/Makefile
 create mode 100644 drivers/mailbox/mailbox-omap1.c
 create mode 100644 drivers/mailbox/mailbox-omap2.c
 create mode 100644 drivers/mailbox/mailbox.c
 create mode 100644 drivers/mailbox/mailbox.h
 create mode 100644 include/linux/mailbox.h

-- 
1.7.9.5

--
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 v2 0/2] drivers: mailbox: omap-mailbox out of plat code

[Omar Ramirez Luna]

As part of plat-omap code cleanup, move omap-mailbox framework to
a newly drivers/mailbox folder, right now this code is specific to
OMAP platforms, but with some clean up it could be the base for a
generic framework; living under drivers/mailbox could give it some
exposure for interested developers to give feedback and propose changes.

In the past there was a mailbox-like driver in mach-ux500, I was
hoping both could live under the same folder, however the platform
using it, was dropped a couple of kernel releases back and with it the
other similar mailbox implementation.

However and as per Loic's comments[1], it looks like there could be
another potential mailbox candidate to live under drivers/mailbox in the
works, along with some proposed changes that could make the original
framework to evolve towards a generic implementation.

So for now, lets move the mailbox code to drivers/mailbox and split
internal structures from common API for others to use.

Based on 3.7-rc4.

1. https://lkml.org/lkml/2012/10/31/123

Omar Ramirez Luna (2):
  mailbox: OMAP: introduce mailbox framework
  mailbox: split internal header from API header

 arch/arm/configs/omap1_defconfig  |3 +-
 arch/arm/mach-omap1/Makefile  |4 -
 arch/arm/mach-omap1/mailbox.c |  199 
 arch/arm/mach-omap2/Makefile  |3 -
 arch/arm/mach-omap2/devices.c |4 +-
 arch/arm/mach-omap2/mailbox.c |  430 --
 arch/arm/plat-omap/Kconfig|   16 -
 arch/arm/plat-omap/Makefile   |3 -
 arch/arm/plat-omap/include/plat/mailbox.h |  105 ---
 arch/arm/plat-omap/mailbox.c  |  435 --
 drivers/Kconfig   |2 +
 drivers/Makefile  |1 +
 drivers/mailbox/Kconfig   |   37 +++
 drivers/mailbox/Makefile  |4 +
 drivers/mailbox/mailbox-omap1.c   |  200 
 drivers/mailbox/mailbox-omap2.c   |  430 ++
 drivers/mailbox/mailbox.c |  469 +
 drivers/mailbox/mailbox.h |   59 
 include/linux/mailbox.h   |   22 ++
 19 files changed, 1228 insertions(+), 1198 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/mailbox.c
 delete mode 100644 arch/arm/mach-omap2/mailbox.c
 delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h
 delete mode 100644 arch/arm/plat-omap/mailbox.c
 create mode 100644 drivers/mailbox/Kconfig
 create mode 100644 drivers/mailbox/Makefile
 create mode 100644 drivers/mailbox/mailbox-omap1.c
 create mode 100644 drivers/mailbox/mailbox-omap2.c
 create mode 100644 drivers/mailbox/mailbox.c
 create mode 100644 drivers/mailbox/mailbox.h
 create mode 100644 include/linux/mailbox.h

-- 
1.7.9.5

--
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 v2 2/2] mailbox: split internal header from API header

[Omar Ramirez Luna]

Now internal structures can remain hidden to the user and just API
related functions and defines are made available.

Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
 drivers/mailbox/mailbox.c |   34 
 drivers/mailbox/mailbox.h |   48 +
 include/linux/mailbox.h   |   22 +
 3 files changed, 57 insertions(+), 47 deletions(-)
 create mode 100644 include/linux/mailbox.h

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 6346ad3..aab9a13 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -116,6 +116,40 @@ out:
 }
 EXPORT_SYMBOL(omap_mbox_msg_send);
 
+void omap_mbox_save_ctx(struct omap_mbox *mbox)
+{
+   if (!mbox-ops-save_ctx) {
+   dev_err(mbox-dev, %s:\tno save\n, __func__);
+   return;
+   }
+
+   mbox-ops-save_ctx(mbox);
+}
+EXPORT_SYMBOL(omap_mbox_save_ctx);
+
+void omap_mbox_restore_ctx(struct omap_mbox *mbox)
+{
+   if (!mbox-ops-restore_ctx) {
+   dev_err(mbox-dev, %s:\tno restore\n, __func__);
+   return;
+   }
+
+   mbox-ops-restore_ctx(mbox);
+}
+EXPORT_SYMBOL(omap_mbox_restore_ctx);
+
+void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+   mbox-ops-enable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_enable_irq);
+
+void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+   mbox-ops-disable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_disable_irq);
+
 static void mbox_tx_tasklet(unsigned long tx_data)
 {
struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h
index cc3921e..b05f64c 100644
--- a/drivers/mailbox/mailbox.h
+++ b/drivers/mailbox/mailbox.h
@@ -8,17 +8,7 @@
 #include linux/interrupt.h
 #include linux/device.h
 #include linux/kfifo.h
-
-typedef u32 mbox_msg_t;
-struct omap_mbox;
-
-typedef int __bitwise omap_mbox_irq_t;
-#define IRQ_TX ((__force omap_mbox_irq_t) 1)
-#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-
-typedef int __bitwise omap_mbox_type_t;
-#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
-#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
+#include linux/mailbox.h
 
 struct omap_mbox_ops {
omap_mbox_type_ttype;
@@ -61,45 +51,9 @@ struct omap_mbox {
struct blocking_notifier_head   notifier;
 };
 
-int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
 void omap_mbox_init_seq(struct omap_mbox *);
 
-struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
-
 int omap_mbox_register(struct device *parent, struct omap_mbox **);
 int omap_mbox_unregister(void);
 
-static inline void omap_mbox_save_ctx(struct omap_mbox *mbox)
-{
-   if (!mbox-ops-save_ctx) {
-   dev_err(mbox-dev, %s:\tno save\n, __func__);
-   return;
-   }
-
-   mbox-ops-save_ctx(mbox);
-}
-
-static inline void omap_mbox_restore_ctx(struct omap_mbox *mbox)
-{
-   if (!mbox-ops-restore_ctx) {
-   dev_err(mbox-dev, %s:\tno restore\n, __func__);
-   return;
-   }
-
-   mbox-ops-restore_ctx(mbox);
-}
-
-static inline void omap_mbox_enable_irq(struct omap_mbox *mbox,
-   omap_mbox_irq_t irq)
-{
-   mbox-ops-enable_irq(mbox, irq);
-}
-
-static inline void omap_mbox_disable_irq(struct omap_mbox *mbox,
-omap_mbox_irq_t irq)
-{
-   mbox-ops-disable_irq(mbox, irq);
-}
-
 #endif /* MAILBOX_H */
diff --git a/include/linux/mailbox.h b/include/linux/mailbox.h
new file mode 100644
index 000..e8e4131
--- /dev/null
+++ b/include/linux/mailbox.h
@@ -0,0 +1,22 @@
+/* mailbox.h */
+
+typedef u32 mbox_msg_t;
+struct omap_mbox;
+
+typedef int __bitwise omap_mbox_irq_t;
+#define IRQ_TX ((__force omap_mbox_irq_t) 1)
+#define IRQ_RX ((__force omap_mbox_irq_t) 2)
+
+typedef int __bitwise omap_mbox_type_t;
+#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
+#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
+
+int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
+
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
+void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
+
+void omap_mbox_save_ctx(struct omap_mbox *mbox);
+void omap_mbox_restore_ctx(struct omap_mbox *mbox);
+void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
+void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
-- 
1.7.9.5

--
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/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers

[Omar Ramirez Luna]

Hi Greg,

On 30 October 2012 16:02, Greg Kroah-Hartman  wrote:
>> OK.
>>
>> Greg, do these patches look OK to you to move to live under
>> drivers/mailbox?
>
> Um, I don't know, I wasn't paying attention here, sorry.

As part of plat-omap code cleanup, I was planning to move omap-mailbox
framework to a newly drivers/mailbox folder, right now this code is
specific to OMAP platforms, but with some clean up it could be the
base for a generic framework. And living under drivers/mailbox could
give it some exposure for interested developers to give feedback and
propose changes.

In the past there was a mailbox-like driver in mach-ux500, I was
hoping both could live under the same folder, however the platform
using it, was dropped a couple of kernel releases back and with it the
other similar mailbox implementation.

So, here it is the thread with the patches:
http://thread.gmane.org/gmane.linux.kernel/1384603, if you think it is
OK for them to be moved under drivers/mailbox, I just need to re-spin
them to move the mailbox header file to include/linux/mailbox instead
of include/linux/platform_data.

Cheers,

Omar
--
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/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers

[Omar Ramirez Luna]

Hi Greg,

On 30 October 2012 16:02, Greg Kroah-Hartman gre...@linuxfoundation.org wrote:
 OK.

 Greg, do these patches look OK to you to move to live under
 drivers/mailbox?

 Um, I don't know, I wasn't paying attention here, sorry.

As part of plat-omap code cleanup, I was planning to move omap-mailbox
framework to a newly drivers/mailbox folder, right now this code is
specific to OMAP platforms, but with some clean up it could be the
base for a generic framework. And living under drivers/mailbox could
give it some exposure for interested developers to give feedback and
propose changes.

In the past there was a mailbox-like driver in mach-ux500, I was
hoping both could live under the same folder, however the platform
using it, was dropped a couple of kernel releases back and with it the
other similar mailbox implementation.

So, here it is the thread with the patches:
http://thread.gmane.org/gmane.linux.kernel/1384603, if you think it is
OK for them to be moved under drivers/mailbox, I just need to re-spin
them to move the mailbox header file to include/linux/mailbox instead
of include/linux/platform_data.

Cheers,

Omar
--
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/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers

[Omar Ramirez Luna]

Tony,

On 29 October 2012 12:52, Tony Lindgren  wrote:
>> --- /dev/null
>> +++ b/include/linux/platform_data/omap_mailbox.h
>> @@ -0,0 +1,105 @@
>
> This file should only contain pure platform data needed
> by the core omap code to pass to the mailbox driver.

Ok, looking at it closely, this header file is related to the API
itself, there is nothing that could be actually considered as pure
platform data, the structures are related with the mailbox framework
and even if I split this file into two, the additional header would
end up including the "platform_data" header unless I move
save/restore_ctx functions and then export them as symbols for the
API.

So, it might be better for the entire file to sit in
linux/include/mailbox/ then.

> The mailbox API header should be somewhere else,
> like include/linux/mailbox/mailbox-omap.h or similar.

Ok.

> But shouldn't this all now be handled by using the
> remoteproc framework?

Remoteproc doesn't handle the mailbox hardware directly, it still
relies in the mailbox framework for the low level communications.
E.g.: Proc1 has a message (virtqueue msg) queued to Proc2, uses
mailbox msg to generate an interrupt to Proc2, Proc2 queries the
message (virtqueue) based on the mailbox message received.

Regards,

Omar
--
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/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers

[Omar Ramirez Luna]

Tony,

On 29 October 2012 12:52, Tony Lindgren t...@atomide.com wrote:
 --- /dev/null
 +++ b/include/linux/platform_data/omap_mailbox.h
 @@ -0,0 +1,105 @@

 This file should only contain pure platform data needed
 by the core omap code to pass to the mailbox driver.

Ok, looking at it closely, this header file is related to the API
itself, there is nothing that could be actually considered as pure
platform data, the structures are related with the mailbox framework
and even if I split this file into two, the additional header would
end up including the platform_data header unless I move
save/restore_ctx functions and then export them as symbols for the
API.

So, it might be better for the entire file to sit in
linux/include/mailbox/ then.

 The mailbox API header should be somewhere else,
 like include/linux/mailbox/mailbox-omap.h or similar.

Ok.

 But shouldn't this all now be handled by using the
 remoteproc framework?

Remoteproc doesn't handle the mailbox hardware directly, it still
relies in the mailbox framework for the low level communications.
E.g.: Proc1 has a message (virtqueue msg) queued to Proc2, uses
mailbox msg to generate an interrupt to Proc2, Proc2 queries the
message (virtqueue) based on the mailbox message received.

Regards,

Omar
--
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 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers

[Omar Ramirez Luna]

CC: Greg Kroah-Hartman 
CC: de...@driverdev.osuosl.org
Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/mailbox.c  |2 +-
 arch/arm/plat-omap/include/plat/mailbox.h  |  105 
 arch/arm/plat-omap/mailbox.c   |2 +-
 .../tidspbridge/include/dspbridge/host_os.h|2 +-
 include/linux/platform_data/omap_mailbox.h |  105 
 5 files changed, 108 insertions(+), 108 deletions(-)
 delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h
 create mode 100644 include/linux/platform_data/omap_mailbox.h

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0d97456..f69e659 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include "soc.h"
 
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
b/arch/arm/plat-omap/include/plat/mailbox.h
deleted file mode 100644
index cc3921e..000
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ /dev/null
@@ -1,105 +0,0 @@
-/* mailbox.h */
-
-#ifndef MAILBOX_H
-#define MAILBOX_H
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-typedef u32 mbox_msg_t;
-struct omap_mbox;
-
-typedef int __bitwise omap_mbox_irq_t;
-#define IRQ_TX ((__force omap_mbox_irq_t) 1)
-#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-
-typedef int __bitwise omap_mbox_type_t;
-#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
-#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
-
-struct omap_mbox_ops {
-   omap_mbox_type_ttype;
-   int (*startup)(struct omap_mbox *mbox);
-   void(*shutdown)(struct omap_mbox *mbox);
-   /* fifo */
-   mbox_msg_t  (*fifo_read)(struct omap_mbox *mbox);
-   void(*fifo_write)(struct omap_mbox *mbox, mbox_msg_t msg);
-   int (*fifo_empty)(struct omap_mbox *mbox);
-   int (*fifo_full)(struct omap_mbox *mbox);
-   /* irq */
-   void(*enable_irq)(struct omap_mbox *mbox,
-   omap_mbox_irq_t irq);
-   void(*disable_irq)(struct omap_mbox *mbox,
-   omap_mbox_irq_t irq);
-   void(*ack_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
-   int (*is_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
-   /* ctx */
-   void(*save_ctx)(struct omap_mbox *mbox);
-   void(*restore_ctx)(struct omap_mbox *mbox);
-};
-
-struct omap_mbox_queue {
-   spinlock_t  lock;
-   struct kfifofifo;
-   struct work_struct  work;
-   struct tasklet_struct   tasklet;
-   struct omap_mbox*mbox;
-   bool full;
-};
-
-struct omap_mbox {
-   char*name;
-   unsigned intirq;
-   struct omap_mbox_queue  *txq, *rxq;
-   struct omap_mbox_ops*ops;
-   struct device   *dev;
-   void*priv;
-   int use_count;
-   struct blocking_notifier_head   notifier;
-};
-
-int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
-void omap_mbox_init_seq(struct omap_mbox *);
-
-struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
-
-int omap_mbox_register(struct device *parent, struct omap_mbox **);
-int omap_mbox_unregister(void);
-
-static inline void omap_mbox_save_ctx(struct omap_mbox *mbox)
-{
-   if (!mbox->ops->save_ctx) {
-   dev_err(mbox->dev, "%s:\tno save\n", __func__);
-   return;
-   }
-
-   mbox->ops->save_ctx(mbox);
-}
-
-static inline void omap_mbox_restore_ctx(struct omap_mbox *mbox)
-{
-   if (!mbox->ops->restore_ctx) {
-   dev_err(mbox->dev, "%s:\tno restore\n", __func__);
-   return;
-   }
-
-   mbox->ops->restore_ctx(mbox);
-}
-
-static inline void omap_mbox_enable_irq(struct omap_mbox *mbox,
-   omap_mbox_irq_t irq)
-{
-   mbox->ops->enable_irq(mbox, irq);
-}
-
-static inline void omap_mbox_disable_irq(struct omap_mbox *mbox,
-omap_mbox_irq_t irq)
-{
-   mbox->ops->disable_irq(mbox, irq);
-}
-
-#endif /* MAILBOX_H */
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 42377ef..cae8692 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 static struct omap_mbox **mboxes;
 
diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h 
b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
index 896f157..bff9e3a 100644
--- a/drivers/staging/tidspbrid

[PATCH 2/2] mailbox: OMAP: introduce mailbox framework

[Omar Ramirez Luna]

Actually moving it from plat-omap code as this is supposed to be
under drivers/ folder. This framework should work with the current
OMAP processors that have mailbox and can be used as a method of
interprocessor communication.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/plat-omap/Kconfig   |   16 --
 arch/arm/plat-omap/Makefile  |3 -
 arch/arm/plat-omap/mailbox.c |  435 --
 drivers/Kconfig  |2 +
 drivers/Makefile |1 +
 drivers/mailbox/Kconfig  |   28 +++
 drivers/mailbox/Makefile |1 +
 drivers/mailbox/mailbox.c|  435 ++
 8 files changed, 467 insertions(+), 454 deletions(-)
 delete mode 100644 arch/arm/plat-omap/mailbox.c
 create mode 100644 drivers/mailbox/Kconfig
 create mode 100644 drivers/mailbox/Makefile
 create mode 100644 drivers/mailbox/mailbox.c

diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 82fcb20..419648f 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -116,22 +116,6 @@ config OMAP_MUX_WARNINGS
  to change the pin multiplexing setup.  When there are no warnings
  printed, it's safe to deselect OMAP_MUX for your product.
 
-config OMAP_MBOX_FWK
-   tristate "Mailbox framework support"
-   depends on ARCH_OMAP
-   help
- Say Y here if you want to use OMAP Mailbox framework support for
- DSP, IVA1.0 and IVA2 in OMAP1/2/3.
-
-config OMAP_MBOX_KFIFO_SIZE
-   int "Mailbox kfifo default buffer size (bytes)"
-   depends on OMAP_MBOX_FWK
-   default 256
-   help
- Specify the default size of mailbox's kfifo buffers (bytes).
- This can also be changed at runtime (via the mbox_kfifo_size
- module parameter).
-
 config OMAP_IOMMU_IVA2
bool
 
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 4bd0ace..4702d1f 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -16,7 +16,4 @@ obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
 i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
 obj-y += $(i2c-omap-m) $(i2c-omap-y)
 
-# OMAP mailbox framework
-obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-
 obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
deleted file mode 100644
index cae8692..000
--- a/arch/arm/plat-omap/mailbox.c
+++ /dev/null
@@ -1,435 +0,0 @@
-/*
- * OMAP mailbox driver
- *
- * Copyright (C) 2006-2009 Nokia Corporation. All rights reserved.
- *
- * Contact: Hiroshi DOYU 
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-static struct omap_mbox **mboxes;
-
-static int mbox_configured;
-static DEFINE_MUTEX(mbox_configured_lock);
-
-static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
-module_param(mbox_kfifo_size, uint, S_IRUGO);
-MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
-
-/* Mailbox FIFO handle functions */
-static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
-{
-   return mbox->ops->fifo_read(mbox);
-}
-static inline void mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
-{
-   mbox->ops->fifo_write(mbox, msg);
-}
-static inline int mbox_fifo_empty(struct omap_mbox *mbox)
-{
-   return mbox->ops->fifo_empty(mbox);
-}
-static inline int mbox_fifo_full(struct omap_mbox *mbox)
-{
-   return mbox->ops->fifo_full(mbox);
-}
-
-/* Mailbox IRQ handle functions */
-static inline void ack_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
-   if (mbox->ops->ack_irq)
-   mbox->ops->ack_irq(mbox, irq);
-}
-static inline int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
-   return mbox->ops->is_irq(mbox, irq);
-}
-
-/*
- * message sender
- */
-static int __mbox_poll_for_space(struct omap_mbox *mbox)
-{
-   int ret = 0, i = 1000;
-
-   while (mbox_fifo_full(mbox)) {
-   if (mbox->ops->type == OMAP_MBOX_TYPE2)
-   return -1;
-   if (--i == 0)
-   return -1;
-   udelay(1);
-   }
-   return ret;
-}
-
-int omap_mbox_msg_send

[PATCH 0/2] ARM: OMAP: mailbox out of plat code

[Omar Ramirez Luna]

From: Omar Ramirez Luna 

Move Mailbox's headers and driver out of platform code as
per current plat-omap cleanup activities.

While at it move mailbox code out of platform and to drivers/
folder, given that this is an OMAP specific framework, some people
might frown upon this, however it seemed worth to try to move it now.
I was expecting this could also pull out the mailbox code from
ux-500 platform, but the platform with a similar mailbox mechanism
has been deleted during 3.5 rc cycle.

So, are there any other mailbox-like drivers out there?

Omar Ramirez Luna (2):
  ARM: OMAP2+: move mailbox.h out of plat-omap headers
  mailbox: OMAP: introduce mailbox framework

 arch/arm/mach-omap2/mailbox.c  |2 +-
 arch/arm/plat-omap/Kconfig |   16 -
 arch/arm/plat-omap/Makefile|3 -
 arch/arm/plat-omap/include/plat/mailbox.h  |  105 -
 arch/arm/plat-omap/mailbox.c   |  435 
 drivers/Kconfig|2 +
 drivers/Makefile   |1 +
 drivers/mailbox/Kconfig|   28 ++
 drivers/mailbox/Makefile   |1 +
 drivers/mailbox/mailbox.c  |  435 
 .../tidspbridge/include/dspbridge/host_os.h|2 +-
 include/linux/platform_data/omap_mailbox.h |  105 +
 12 files changed, 574 insertions(+), 561 deletions(-)
 delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h
 delete mode 100644 arch/arm/plat-omap/mailbox.c
 create mode 100644 drivers/mailbox/Kconfig
 create mode 100644 drivers/mailbox/Makefile
 create mode 100644 drivers/mailbox/mailbox.c
 create mode 100644 include/linux/platform_data/omap_mailbox.h

-- 
1.7.9.5

--
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/2] ARM: OMAP: mailbox out of plat code

[Omar Ramirez Luna]

From: Omar Ramirez Luna omar.rami...@copitl.com

Move Mailbox's headers and driver out of platform code as
per current plat-omap cleanup activities.

While at it move mailbox code out of platform and to drivers/
folder, given that this is an OMAP specific framework, some people
might frown upon this, however it seemed worth to try to move it now.
I was expecting this could also pull out the mailbox code from
ux-500 platform, but the platform with a similar mailbox mechanism
has been deleted during 3.5 rc cycle.

So, are there any other mailbox-like drivers out there?

Omar Ramirez Luna (2):
  ARM: OMAP2+: move mailbox.h out of plat-omap headers
  mailbox: OMAP: introduce mailbox framework

 arch/arm/mach-omap2/mailbox.c  |2 +-
 arch/arm/plat-omap/Kconfig |   16 -
 arch/arm/plat-omap/Makefile|3 -
 arch/arm/plat-omap/include/plat/mailbox.h  |  105 -
 arch/arm/plat-omap/mailbox.c   |  435 
 drivers/Kconfig|2 +
 drivers/Makefile   |1 +
 drivers/mailbox/Kconfig|   28 ++
 drivers/mailbox/Makefile   |1 +
 drivers/mailbox/mailbox.c  |  435 
 .../tidspbridge/include/dspbridge/host_os.h|2 +-
 include/linux/platform_data/omap_mailbox.h |  105 +
 12 files changed, 574 insertions(+), 561 deletions(-)
 delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h
 delete mode 100644 arch/arm/plat-omap/mailbox.c
 create mode 100644 drivers/mailbox/Kconfig
 create mode 100644 drivers/mailbox/Makefile
 create mode 100644 drivers/mailbox/mailbox.c
 create mode 100644 include/linux/platform_data/omap_mailbox.h

-- 
1.7.9.5

--
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 2/2] mailbox: OMAP: introduce mailbox framework

[Omar Ramirez Luna]

Actually moving it from plat-omap code as this is supposed to be
under drivers/ folder. This framework should work with the current
OMAP processors that have mailbox and can be used as a method of
interprocessor communication.

Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
 arch/arm/plat-omap/Kconfig   |   16 --
 arch/arm/plat-omap/Makefile  |3 -
 arch/arm/plat-omap/mailbox.c |  435 --
 drivers/Kconfig  |2 +
 drivers/Makefile |1 +
 drivers/mailbox/Kconfig  |   28 +++
 drivers/mailbox/Makefile |1 +
 drivers/mailbox/mailbox.c|  435 ++
 8 files changed, 467 insertions(+), 454 deletions(-)
 delete mode 100644 arch/arm/plat-omap/mailbox.c
 create mode 100644 drivers/mailbox/Kconfig
 create mode 100644 drivers/mailbox/Makefile
 create mode 100644 drivers/mailbox/mailbox.c

diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 82fcb20..419648f 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -116,22 +116,6 @@ config OMAP_MUX_WARNINGS
  to change the pin multiplexing setup.  When there are no warnings
  printed, it's safe to deselect OMAP_MUX for your product.
 
-config OMAP_MBOX_FWK
-   tristate Mailbox framework support
-   depends on ARCH_OMAP
-   help
- Say Y here if you want to use OMAP Mailbox framework support for
- DSP, IVA1.0 and IVA2 in OMAP1/2/3.
-
-config OMAP_MBOX_KFIFO_SIZE
-   int Mailbox kfifo default buffer size (bytes)
-   depends on OMAP_MBOX_FWK
-   default 256
-   help
- Specify the default size of mailbox's kfifo buffers (bytes).
- This can also be changed at runtime (via the mbox_kfifo_size
- module parameter).
-
 config OMAP_IOMMU_IVA2
bool
 
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 4bd0ace..4702d1f 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -16,7 +16,4 @@ obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
 i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
 obj-y += $(i2c-omap-m) $(i2c-omap-y)
 
-# OMAP mailbox framework
-obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-
 obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
deleted file mode 100644
index cae8692..000
--- a/arch/arm/plat-omap/mailbox.c
+++ /dev/null
@@ -1,435 +0,0 @@
-/*
- * OMAP mailbox driver
- *
- * Copyright (C) 2006-2009 Nokia Corporation. All rights reserved.
- *
- * Contact: Hiroshi DOYU hiroshi.d...@nokia.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include linux/interrupt.h
-#include linux/spinlock.h
-#include linux/mutex.h
-#include linux/delay.h
-#include linux/slab.h
-#include linux/kfifo.h
-#include linux/err.h
-#include linux/notifier.h
-#include linux/module.h
-
-#include linux/platform_data/omap_mailbox.h
-
-static struct omap_mbox **mboxes;
-
-static int mbox_configured;
-static DEFINE_MUTEX(mbox_configured_lock);
-
-static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
-module_param(mbox_kfifo_size, uint, S_IRUGO);
-MODULE_PARM_DESC(mbox_kfifo_size, Size of omap's mailbox kfifo (bytes));
-
-/* Mailbox FIFO handle functions */
-static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
-{
-   return mbox-ops-fifo_read(mbox);
-}
-static inline void mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
-{
-   mbox-ops-fifo_write(mbox, msg);
-}
-static inline int mbox_fifo_empty(struct omap_mbox *mbox)
-{
-   return mbox-ops-fifo_empty(mbox);
-}
-static inline int mbox_fifo_full(struct omap_mbox *mbox)
-{
-   return mbox-ops-fifo_full(mbox);
-}
-
-/* Mailbox IRQ handle functions */
-static inline void ack_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
-   if (mbox-ops-ack_irq)
-   mbox-ops-ack_irq(mbox, irq);
-}
-static inline int is_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
-{
-   return mbox-ops-is_irq(mbox, irq);
-}
-
-/*
- * message sender
- */
-static int __mbox_poll_for_space(struct omap_mbox *mbox)
-{
-   int ret = 0, i = 1000;
-
-   while (mbox_fifo_full(mbox)) {
-   if (mbox-ops-type == OMAP_MBOX_TYPE2)
-   return -1;
-   if (--i == 0

[PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers

[Omar Ramirez Luna]

CC: Greg Kroah-Hartman gre...@linuxfoundation.org
CC: de...@driverdev.osuosl.org
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
 arch/arm/mach-omap2/mailbox.c  |2 +-
 arch/arm/plat-omap/include/plat/mailbox.h  |  105 
 arch/arm/plat-omap/mailbox.c   |2 +-
 .../tidspbridge/include/dspbridge/host_os.h|2 +-
 include/linux/platform_data/omap_mailbox.h |  105 
 5 files changed, 108 insertions(+), 108 deletions(-)
 delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h
 create mode 100644 include/linux/platform_data/omap_mailbox.h

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0d97456..f69e659 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -17,7 +17,7 @@
 #include linux/io.h
 #include linux/pm_runtime.h
 
-#include plat/mailbox.h
+#include linux/platform_data/omap_mailbox.h
 
 #include soc.h
 
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
b/arch/arm/plat-omap/include/plat/mailbox.h
deleted file mode 100644
index cc3921e..000
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ /dev/null
@@ -1,105 +0,0 @@
-/* mailbox.h */
-
-#ifndef MAILBOX_H
-#define MAILBOX_H
-
-#include linux/spinlock.h
-#include linux/workqueue.h
-#include linux/interrupt.h
-#include linux/device.h
-#include linux/kfifo.h
-
-typedef u32 mbox_msg_t;
-struct omap_mbox;
-
-typedef int __bitwise omap_mbox_irq_t;
-#define IRQ_TX ((__force omap_mbox_irq_t) 1)
-#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-
-typedef int __bitwise omap_mbox_type_t;
-#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
-#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
-
-struct omap_mbox_ops {
-   omap_mbox_type_ttype;
-   int (*startup)(struct omap_mbox *mbox);
-   void(*shutdown)(struct omap_mbox *mbox);
-   /* fifo */
-   mbox_msg_t  (*fifo_read)(struct omap_mbox *mbox);
-   void(*fifo_write)(struct omap_mbox *mbox, mbox_msg_t msg);
-   int (*fifo_empty)(struct omap_mbox *mbox);
-   int (*fifo_full)(struct omap_mbox *mbox);
-   /* irq */
-   void(*enable_irq)(struct omap_mbox *mbox,
-   omap_mbox_irq_t irq);
-   void(*disable_irq)(struct omap_mbox *mbox,
-   omap_mbox_irq_t irq);
-   void(*ack_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
-   int (*is_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
-   /* ctx */
-   void(*save_ctx)(struct omap_mbox *mbox);
-   void(*restore_ctx)(struct omap_mbox *mbox);
-};
-
-struct omap_mbox_queue {
-   spinlock_t  lock;
-   struct kfifofifo;
-   struct work_struct  work;
-   struct tasklet_struct   tasklet;
-   struct omap_mbox*mbox;
-   bool full;
-};
-
-struct omap_mbox {
-   char*name;
-   unsigned intirq;
-   struct omap_mbox_queue  *txq, *rxq;
-   struct omap_mbox_ops*ops;
-   struct device   *dev;
-   void*priv;
-   int use_count;
-   struct blocking_notifier_head   notifier;
-};
-
-int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
-void omap_mbox_init_seq(struct omap_mbox *);
-
-struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
-
-int omap_mbox_register(struct device *parent, struct omap_mbox **);
-int omap_mbox_unregister(void);
-
-static inline void omap_mbox_save_ctx(struct omap_mbox *mbox)
-{
-   if (!mbox-ops-save_ctx) {
-   dev_err(mbox-dev, %s:\tno save\n, __func__);
-   return;
-   }
-
-   mbox-ops-save_ctx(mbox);
-}
-
-static inline void omap_mbox_restore_ctx(struct omap_mbox *mbox)
-{
-   if (!mbox-ops-restore_ctx) {
-   dev_err(mbox-dev, %s:\tno restore\n, __func__);
-   return;
-   }
-
-   mbox-ops-restore_ctx(mbox);
-}
-
-static inline void omap_mbox_enable_irq(struct omap_mbox *mbox,
-   omap_mbox_irq_t irq)
-{
-   mbox-ops-enable_irq(mbox, irq);
-}
-
-static inline void omap_mbox_disable_irq(struct omap_mbox *mbox,
-omap_mbox_irq_t irq)
-{
-   mbox-ops-disable_irq(mbox, irq);
-}
-
-#endif /* MAILBOX_H */
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 42377ef..cae8692 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -31,7 +31,7 @@
 #include linux/notifier.h
 #include linux/module.h
 
-#include plat/mailbox.h
+#include linux/platform_data/omap_mailbox.h
 
 static struct omap_mbox **mboxes;
 
diff

Re: [PATCH 0/6] staging: tidspbridge fixes for 3.7

[Omar Ramirez Luna]

Hi,

On Wed, Oct 24, 2012 at 5:28 PM, Greg Kroah-Hartman
 wrote:
> On Wed, Oct 24, 2012 at 05:09:14PM -0500, Omar Ramirez Luna wrote:
>> With 3.7-rc1 changes:
>>
>> - New irq numbering in OMAP3 broke the driver request for a mmu irq,
>>   until this is migrated to the common iommu framework we can only
>>   hardcode the new number.
>> - _raw_* accessors changed a type of one of their parameters with patch
>>   "195bbca ARM: 7500/1: io: avoid writeback addressing modes for
>>   __raw_ accessors", so the build system was filled with warnings from
>>   the old parameter usage.
>>
>> Omar Ramirez Luna (6):
>>   staging: tidspbridge: request the right irq for mmu
>>   staging: tidspbridge: drop const from custom mmu implementation
>>   staging: tidspbridge: change type to __iomem for per and core
>> addresses
>>   staging: tidspbridge: ioremap dsp sync addr
>>   staging: tidspbridge: ioremap physical address of the stack segment
>> in shm
>>   staging: tidspbridge: delete unused mmu functions
>
> Are the "fix up the compiler warning" patches really needed for 3.7?
> Are they new in 3.7-rc1?  Or were they there before in 3.6?

All are new in 3.7-rc1.

The "warning fixes" would be good to have and thought they could make
it given that the change was introduced during 3.7 rc cycle. So, the
warnings are not that critical.

Cheers,

Omar
--
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/6] staging: tidspbridge: ioremap dsp sync addr

[Omar Ramirez Luna]

Change the type of sync_addr to 'void __iomem *' and ioremap the
physical address in the shared memory so we can access it using
_raw_*. While at it, drop 'dw_' prefix.

Fix the warning associated with dsp's sync_addr:

warning: passing argument 2 of '__raw_writel' makes pointer from integer 
without a cast
../io.h:88: note: expected 'volatile void *' but argument is of type 'u32'

Signed-off-by: Omar Ramirez Luna 
---

Intended for 3.7 due to code changes during rc1.

 drivers/staging/tidspbridge/core/tiomap3430.c |   37 +
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 066a3ce..f619fb3 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -126,7 +126,8 @@ static int mem_map_vmalloc(struct bridge_dev_context 
*dev_context,
  u32 ul_num_bytes,
  struct hw_mmu_map_attrs_t *hw_attrs);
 
-bool wait_for_start(struct bridge_dev_context *dev_context, u32 dw_sync_addr);
+bool wait_for_start(struct bridge_dev_context *dev_context,
+   void __iomem *sync_addr);
 
 /*  --- Globals */
 
@@ -363,10 +364,11 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
 {
int status = 0;
struct bridge_dev_context *dev_context = dev_ctxt;
-   u32 dw_sync_addr = 0;
+   void __iomem *sync_addr;
u32 ul_shm_base;/* Gpp Phys SM base addr(byte) */
u32 ul_shm_base_virt;   /* Dsp Virt SM base addr */
u32 ul_tlb_base_virt;   /* Base of MMU TLB entry */
+   u32 shm_sync_pa;
/* Offset of shm_base_virt from tlb_base_virt */
u32 ul_shm_offset_virt;
s32 entry_ndx;
@@ -397,15 +399,22 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
/* Kernel logical address */
ul_shm_base = dev_context->atlb_entry[0].gpp_va + ul_shm_offset_virt;
 
+   /* SHM physical sync address */
+   shm_sync_pa = dev_context->atlb_entry[0].gpp_pa + ul_shm_offset_virt +
+   SHMSYNCOFFSET;
+
/* 2nd wd is used as sync field */
-   dw_sync_addr = ul_shm_base + SHMSYNCOFFSET;
+   sync_addr = ioremap(shm_sync_pa, SZ_32);
+   if (!sync_addr)
+   return -ENOMEM;
+
/* Write a signature into the shm base + offset; this will
 * get cleared when the DSP program starts. */
if ((ul_shm_base_virt == 0) || (ul_shm_base == 0)) {
pr_err("%s: Illegal SM base\n", __func__);
status = -EPERM;
} else
-   __raw_writel(0x, dw_sync_addr);
+   __raw_writel(0x, sync_addr);
 
if (!status) {
resources = dev_context->resources;
@@ -419,8 +428,10 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
 * function is made available.
 */
void __iomem *ctrl = ioremap(0x48002000, SZ_4K);
-   if (!ctrl)
+   if (!ctrl) {
+   iounmap(sync_addr);
return -ENOMEM;
+   }
 
(*pdata->dsp_prm_rmw_bits)(OMAP3430_RST1_IVA2_MASK,
OMAP3430_RST1_IVA2_MASK, 
OMAP3430_IVA2_MOD,
@@ -588,15 +599,15 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
(*pdata->dsp_prm_rmw_bits)(OMAP3430_RST1_IVA2_MASK, 0,
OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
 
-   dev_dbg(bridge, "Waiting for Sync @ 0x%x\n", dw_sync_addr);
+   dev_dbg(bridge, "Waiting for Sync @ 0x%x\n", *(u32 *)sync_addr);
dev_dbg(bridge, "DSP c_int00 Address =  0x%x\n", dsp_addr);
if (dsp_debug)
-   while (__raw_readw(dw_sync_addr))
+   while (__raw_readw(sync_addr))
;
 
/* Wait for DSP to clear word in shared memory */
/* Read the Location */
-   if (!wait_for_start(dev_context, dw_sync_addr))
+   if (!wait_for_start(dev_context, sync_addr))
status = -ETIMEDOUT;
 
dev_get_symbol(dev_context->dev_obj, "_WDT_enable", _en);
@@ -612,7 +623,7 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
/* Write the synchronization bit to indicate the
 * completion of OPP table update to DSP
 */
-   __raw_writel(0XCAFECAFE, dw_sync_addr);
+   __raw_writel(0XCAFECAFE, sync_addr);
 
/* 

[PATCH 3/6] staging: tidspbridge: change type to __iomem for per and core addresses

[Omar Ramirez Luna]

Currently per_pm_base and core_pm_base are declared as u32, however
_raw_* changed the data type, since:

195bbca ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors

This should fix warnings for per and core accesses:

warning: passing argument 2 of '__raw_writel' makes pointer from integer 
without a cast
../io.h:88: note: expected 'volatile void *' but argument is of type 'u32'

Signed-off-by: Omar Ramirez Luna 
---

Intended for 3.7 due to code changes during rc1.

 .../tidspbridge/include/dspbridge/cfgdefs.h|4 ++--
 drivers/staging/tidspbridge/rmgr/drv.c |8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h 
b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
index 60a2781..b32c756 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
@@ -53,8 +53,8 @@ struct cfg_hostres {
u32 chnl_buf_size;
u32 num_chnls;
void __iomem *per_base;
-   u32 per_pm_base;
-   u32 core_pm_base;
+   void __iomem *per_pm_base;
+   void __iomem *core_pm_base;
void __iomem *dmmu_base;
 };
 
diff --git a/drivers/staging/tidspbridge/rmgr/drv.c 
b/drivers/staging/tidspbridge/rmgr/drv.c
index 6795205..db1da28 100644
--- a/drivers/staging/tidspbridge/rmgr/drv.c
+++ b/drivers/staging/tidspbridge/rmgr/drv.c
@@ -667,10 +667,10 @@ int drv_request_bridge_res_dsp(void **phost_resources)
 OMAP_DSP_MEM3_SIZE);
host_res->per_base = ioremap(OMAP_PER_CM_BASE,
OMAP_PER_CM_SIZE);
-   host_res->per_pm_base = (u32) ioremap(OMAP_PER_PRM_BASE,
-OMAP_PER_PRM_SIZE);
-   host_res->core_pm_base = (u32) ioremap(OMAP_CORE_PRM_BASE,
- OMAP_CORE_PRM_SIZE);
+   host_res->per_pm_base = ioremap(OMAP_PER_PRM_BASE,
+   OMAP_PER_PRM_SIZE);
+   host_res->core_pm_base = ioremap(OMAP_CORE_PRM_BASE,
+   OMAP_CORE_PRM_SIZE);
host_res->dmmu_base = ioremap(OMAP_DMMU_BASE,
 OMAP_DMMU_SIZE);
 
-- 
1.7.9.5

--
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/6] staging: tidspbridge fixes for 3.7

[Omar Ramirez Luna]

With 3.7-rc1 changes:

- New irq numbering in OMAP3 broke the driver request for a mmu irq,
  until this is migrated to the common iommu framework we can only
  hardcode the new number.
- _raw_* accessors changed a type of one of their parameters with patch
  "195bbca ARM: 7500/1: io: avoid writeback addressing modes for
  __raw_ accessors", so the build system was filled with warnings from
  the old parameter usage.

Omar Ramirez Luna (6):
  staging: tidspbridge: request the right irq for mmu
  staging: tidspbridge: drop const from custom mmu implementation
  staging: tidspbridge: change type to __iomem for per and core
addresses
  staging: tidspbridge: ioremap dsp sync addr
  staging: tidspbridge: ioremap physical address of the stack segment
in shm
  staging: tidspbridge: delete unused mmu functions

 drivers/staging/tidspbridge/core/tiomap3430.c  |   37 +--
 drivers/staging/tidspbridge/hw/hw_mmu.c|  115 
 drivers/staging/tidspbridge/hw/hw_mmu.h|   31 +++---
 .../tidspbridge/include/dspbridge/cfgdefs.h|4 +-
 .../tidspbridge/include/dspbridge/host_os.h|4 +-
 drivers/staging/tidspbridge/rmgr/drv.c |8 +-
 drivers/staging/tidspbridge/rmgr/node.c|   21 +++-
 7 files changed, 83 insertions(+), 137 deletions(-)

-- 
1.7.9.5

--
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 5/6] staging: tidspbridge: ioremap physical address of the stack segment in shm

[Omar Ramirez Luna]

Due to data type change, readl can no longer receive a u32.

Signed-off-by: Omar Ramirez Luna 
---

Intended for 3.7 due to code changes during rc1.

 drivers/staging/tidspbridge/rmgr/node.c |   21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tidspbridge/rmgr/node.c 
b/drivers/staging/tidspbridge/rmgr/node.c
index c2fc613..294e9b4 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -304,8 +304,7 @@ int node_allocate(struct proc_object *hprocessor,
u32 pul_value;
u32 dynext_base;
u32 off_set = 0;
-   u32 ul_stack_seg_addr, ul_stack_seg_val;
-   u32 ul_gpp_mem_base;
+   u32 ul_stack_seg_val;
struct cfg_hostres *host_res;
struct bridge_dev_context *pbridge_context;
u32 mapped_addr = 0;
@@ -581,6 +580,9 @@ func_cont:
if (strcmp((char *)
   pnode->dcd_props.obj_data.node_obj.ndb_props.
   stack_seg_name, STACKSEGLABEL) == 0) {
+   void __iomem *stack_seg;
+   u32 stack_seg_pa;
+
status =
hnode_mgr->nldr_fxns.
get_fxn_addr(pnode->nldr_node_obj, "DYNEXT_BEG",
@@ -608,14 +610,21 @@ func_cont:
goto func_end;
}
 
-   ul_gpp_mem_base = (u32) host_res->mem_base[1];
off_set = pul_value - dynext_base;
-   ul_stack_seg_addr = ul_gpp_mem_base + off_set;
-   ul_stack_seg_val = readl(ul_stack_seg_addr);
+   stack_seg_pa = host_res->mem_phys[1] + off_set;
+   stack_seg = ioremap(stack_seg_pa, SZ_32);
+   if (!stack_seg) {
+   status = -ENOMEM;
+   goto func_end;
+   }
+
+   ul_stack_seg_val = readl(stack_seg);
+
+   iounmap(stack_seg);
 
dev_dbg(bridge, "%s: StackSegVal = 0x%x, StackSegAddr ="
" 0x%x\n", __func__, ul_stack_seg_val,
-   ul_stack_seg_addr);
+   host_res->mem_base[1] + off_set);
 
pnode->create_args.asa.task_arg_obj.stack_seg =
ul_stack_seg_val;
-- 
1.7.9.5

--
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 2/6] staging: tidspbridge: drop const from custom mmu implementation

[Omar Ramirez Luna]

Custom mmu functions receive a 'const void __iomem *', all the
callers pass a 'void __iomem *', so drop the const to fix the
warnings like:

warning: passing argument 2 of '__raw_writel' discards qualifiers from pointer 
target type
../io.h:88: note: expected 'volatile void *' but argument is of type 'const 
void *'

Signed-off-by: Omar Ramirez Luna 
---

Intended for 3.7 due to code changes during rc1.

 drivers/staging/tidspbridge/hw/hw_mmu.c |   40 +++
 drivers/staging/tidspbridge/hw/hw_mmu.h |   28 +++---
 2 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.c 
b/drivers/staging/tidspbridge/hw/hw_mmu.c
index 71cb822..a159450 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.c
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.c
@@ -78,7 +78,7 @@ static hw_status mmu_flush_entry(const void __iomem 
*base_address);
  * INPUTS:
  *
  *   Identifier  : base_address
- *   TypE  : const u32
+ *   Type   : void __iomem *
  *   Description : Base Address of instance of MMU module
  *
  *   Identifier  : page_sz
@@ -112,7 +112,7 @@ static hw_status mmu_flush_entry(const void __iomem 
*base_address);
  *
  * METHOD: : Check the Input parameters and set the CAM entry.
  */
-static hw_status mmu_set_cam_entry(const void __iomem *base_address,
+static hw_status mmu_set_cam_entry(void __iomem *base_address,
   const u32 page_sz,
   const u32 preserved_bit,
   const u32 valid_bit,
@@ -124,7 +124,7 @@ static hw_status mmu_set_cam_entry(const void __iomem 
*base_address,
  * INPUTS:
  *
  *   Identifier  : base_address
- *   Type  : const u32
+ *   Type   : void __iomem *
  *   Description : Base Address of instance of MMU module
  *
  *   Identifier  : physical_addr
@@ -157,7 +157,7 @@ static hw_status mmu_set_cam_entry(const void __iomem 
*base_address,
  *
  * METHOD:: Check the Input parameters and set the RAM entry.
  */
-static hw_status mmu_set_ram_entry(const void __iomem *base_address,
+static hw_status mmu_set_ram_entry(void __iomem *base_address,
   const u32 physical_addr,
   enum hw_endianism_t endianism,
   enum hw_element_size_t element_size,
@@ -165,7 +165,7 @@ static hw_status mmu_set_ram_entry(const void __iomem 
*base_address,
 
 /* HW FUNCTIONS */
 
-hw_status hw_mmu_enable(const void __iomem *base_address)
+hw_status hw_mmu_enable(void __iomem *base_address)
 {
hw_status status = 0;
 
@@ -174,7 +174,7 @@ hw_status hw_mmu_enable(const void __iomem *base_address)
return status;
 }
 
-hw_status hw_mmu_disable(const void __iomem *base_address)
+hw_status hw_mmu_disable(void __iomem *base_address)
 {
hw_status status = 0;
 
@@ -183,7 +183,7 @@ hw_status hw_mmu_disable(const void __iomem *base_address)
return status;
 }
 
-hw_status hw_mmu_num_locked_set(const void __iomem *base_address,
+hw_status hw_mmu_num_locked_set(void __iomem *base_address,
u32 num_locked_entries)
 {
hw_status status = 0;
@@ -193,7 +193,7 @@ hw_status hw_mmu_num_locked_set(const void __iomem 
*base_address,
return status;
 }
 
-hw_status hw_mmu_victim_num_set(const void __iomem *base_address,
+hw_status hw_mmu_victim_num_set(void __iomem *base_address,
u32 victim_entry_num)
 {
hw_status status = 0;
@@ -203,7 +203,7 @@ hw_status hw_mmu_victim_num_set(const void __iomem 
*base_address,
return status;
 }
 
-hw_status hw_mmu_event_ack(const void __iomem *base_address, u32 irq_mask)
+hw_status hw_mmu_event_ack(void __iomem *base_address, u32 irq_mask)
 {
hw_status status = 0;
 
@@ -212,7 +212,7 @@ hw_status hw_mmu_event_ack(const void __iomem 
*base_address, u32 irq_mask)
return status;
 }
 
-hw_status hw_mmu_event_disable(const void __iomem *base_address, u32 irq_mask)
+hw_status hw_mmu_event_disable(void __iomem *base_address, u32 irq_mask)
 {
hw_status status = 0;
u32 irq_reg;
@@ -224,7 +224,7 @@ hw_status hw_mmu_event_disable(const void __iomem 
*base_address, u32 irq_mask)
return status;
 }
 
-hw_status hw_mmu_event_enable(const void __iomem *base_address, u32 irq_mask)
+hw_status hw_mmu_event_enable(void __iomem *base_address, u32 irq_mask)
 {
hw_status status = 0;
u32 irq_reg;
@@ -236,7 +236,7 @@ hw_status hw_mmu_event_enable(const void __iomem 
*base_address, u32 irq_mask)
return status;
 }
 
-hw_status hw_mmu_event_status(const void __iomem *base_address, u32 *irq_mask)
+hw_status hw_mmu_event_status(void __iomem *base_address, u32 *irq_mask)
 {
hw_status status = 0;
 
@@ -245,7 +245,7 @@ hw_status hw_mmu_event_status(const void __iomem

[PATCH 6/6] staging: tidspbridge: delete unused mmu functions

[Omar Ramirez Luna]

From: Omar Ramirez Luna 

This should get rid of warnings of the type:

warning: passing argument 1 of '' discards qualifiers from pointer target type
 note: expected 'void *' but argument is of type 'const void *'

Signed-off-by: Omar Ramirez Luna 
---

Intended for 3.7 due to code changes during rc1.

 drivers/staging/tidspbridge/hw/hw_mmu.c |   75 ---
 drivers/staging/tidspbridge/hw/hw_mmu.h |3 --
 2 files changed, 78 deletions(-)

diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.c 
b/drivers/staging/tidspbridge/hw/hw_mmu.c
index a159450..50244a4 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.c
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.c
@@ -48,31 +48,6 @@ enum hw_mmu_page_size_t {
 };
 
 /*
- * FUNCTION  : mmu_flush_entry
- *
- * INPUTS:
- *
- *   Identifier  : base_address
- *   Type  : const u32
- *   Description : Base Address of instance of MMU module
- *
- * RETURNS:
- *
- *   Type  : hw_status
- *   Description : 0-- No errors occurred
- *  RET_BAD_NULL_PARAM -- A Pointer
- * Parameter was set to NULL
- *
- * PURPOSE:  : Flush the TLB entry pointed by the
- * lock counter register
- * even if this entry is set protected
- *
- * METHOD:: Check the Input parameter and Flush a
- *  single entry in the TLB.
- */
-static hw_status mmu_flush_entry(const void __iomem *base_address);
-
-/*
  * FUNCTION  : mmu_set_cam_entry
  *
  * INPUTS:
@@ -285,44 +260,6 @@ hw_status hw_mmu_twl_disable(void __iomem *base_address)
return status;
 }
 
-hw_status hw_mmu_tlb_flush(const void __iomem *base_address, u32 virtual_addr,
-  u32 page_sz)
-{
-   hw_status status = 0;
-   u32 virtual_addr_tag;
-   enum hw_mmu_page_size_t pg_size_bits;
-
-   switch (page_sz) {
-   case HW_PAGE_SIZE4KB:
-   pg_size_bits = HW_MMU_SMALL_PAGE;
-   break;
-
-   case HW_PAGE_SIZE64KB:
-   pg_size_bits = HW_MMU_LARGE_PAGE;
-   break;
-
-   case HW_PAGE_SIZE1MB:
-   pg_size_bits = HW_MMU_SECTION;
-   break;
-
-   case HW_PAGE_SIZE16MB:
-   pg_size_bits = HW_MMU_SUPERSECTION;
-   break;
-
-   default:
-   return -EINVAL;
-   }
-
-   /* Generate the 20-bit tag from virtual address */
-   virtual_addr_tag = ((virtual_addr & MMU_ADDR_MASK) >> 12);
-
-   mmu_set_cam_entry(base_address, pg_size_bits, 0, 0, virtual_addr_tag);
-
-   mmu_flush_entry(base_address);
-
-   return status;
-}
-
 hw_status hw_mmu_tlb_add(void __iomem *base_address,
 u32 physical_addr,
 u32 virtual_addr,
@@ -503,18 +440,6 @@ hw_status hw_mmu_pte_clear(const u32 pg_tbl_va, u32 
virtual_addr, u32 page_size)
return status;
 }
 
-/* mmu_flush_entry */
-static hw_status mmu_flush_entry(const void __iomem *base_address)
-{
-   hw_status status = 0;
-   u32 flush_entry_data = 0x1;
-
-   /* write values to register */
-   MMUMMU_FLUSH_ENTRY_WRITE_REGISTER32(base_address, flush_entry_data);
-
-   return status;
-}
-
 /* mmu_set_cam_entry */
 static hw_status mmu_set_cam_entry(void __iomem *base_address,
   const u32 page_sz,
diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.h 
b/drivers/staging/tidspbridge/hw/hw_mmu.h
index 1cdd082..1c50bb3 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.h
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.h
@@ -76,9 +76,6 @@ extern hw_status hw_mmu_twl_enable(void __iomem 
*base_address);
 
 extern hw_status hw_mmu_twl_disable(void __iomem *base_address);
 
-extern hw_status hw_mmu_tlb_flush(const void __iomem *base_address,
- u32 virtual_addr, u32 page_sz);
-
 extern hw_status hw_mmu_tlb_add(void __iomem *base_address,
u32 physical_addr,
u32 virtual_addr,
-- 
1.7.9.5

--
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 1/6] staging: tidspbridge: request the right irq for mmu

[Omar Ramirez Luna]

Requested irq for mmu is currently conflicting with a DMA irq
due to recent changes to irq header files, now the offset for the
start of the interrupt controller numbering has changed.

This should be removed during a future migration to omap-iommu,
for now it is hardcoded.

Signed-off-by: Omar Ramirez Luna 
---

Intended for 3.7 due to code changes during rc1.

 .../tidspbridge/include/dspbridge/host_os.h|4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h 
b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
index ed00d3d..5e2f4d8 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
@@ -47,8 +47,8 @@
 #include 
 #include 
 
-/* TODO -- Remove, once BP defines them */
-#define INT_DSP_MMU_IRQ28
+/* TODO -- Remove, once omap-iommu is used */
+#define INT_DSP_MMU_IRQ(28 + NR_IRQS)
 
 #define PRCM_VDD1 1
 
-- 
1.7.9.5

--
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 1/6] staging: tidspbridge: request the right irq for mmu

[Omar Ramirez Luna]

Requested irq for mmu is currently conflicting with a DMA irq
due to recent changes to irq header files, now the offset for the
start of the interrupt controller numbering has changed.

This should be removed during a future migration to omap-iommu,
for now it is hardcoded.

Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---

Intended for 3.7 due to code changes during rc1.

 .../tidspbridge/include/dspbridge/host_os.h|4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h 
b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
index ed00d3d..5e2f4d8 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
@@ -47,8 +47,8 @@
 #include asm/cacheflush.h
 #include linux/dma-mapping.h
 
-/* TODO -- Remove, once BP defines them */
-#define INT_DSP_MMU_IRQ28
+/* TODO -- Remove, once omap-iommu is used */
+#define INT_DSP_MMU_IRQ(28 + NR_IRQS)
 
 #define PRCM_VDD1 1
 
-- 
1.7.9.5

--
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 6/6] staging: tidspbridge: delete unused mmu functions

[Omar Ramirez Luna]

From: Omar Ramirez Luna omar.l...@linaro.org

This should get rid of warnings of the type:

warning: passing argument 1 of '' discards qualifiers from pointer target type
 note: expected 'void *' but argument is of type 'const void *'

Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---

Intended for 3.7 due to code changes during rc1.

 drivers/staging/tidspbridge/hw/hw_mmu.c |   75 ---
 drivers/staging/tidspbridge/hw/hw_mmu.h |3 --
 2 files changed, 78 deletions(-)

diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.c 
b/drivers/staging/tidspbridge/hw/hw_mmu.c
index a159450..50244a4 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.c
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.c
@@ -48,31 +48,6 @@ enum hw_mmu_page_size_t {
 };
 
 /*
- * FUNCTION  : mmu_flush_entry
- *
- * INPUTS:
- *
- *   Identifier  : base_address
- *   Type  : const u32
- *   Description : Base Address of instance of MMU module
- *
- * RETURNS:
- *
- *   Type  : hw_status
- *   Description : 0-- No errors occurred
- *  RET_BAD_NULL_PARAM -- A Pointer
- * Parameter was set to NULL
- *
- * PURPOSE:  : Flush the TLB entry pointed by the
- * lock counter register
- * even if this entry is set protected
- *
- * METHOD:: Check the Input parameter and Flush a
- *  single entry in the TLB.
- */
-static hw_status mmu_flush_entry(const void __iomem *base_address);
-
-/*
  * FUNCTION  : mmu_set_cam_entry
  *
  * INPUTS:
@@ -285,44 +260,6 @@ hw_status hw_mmu_twl_disable(void __iomem *base_address)
return status;
 }
 
-hw_status hw_mmu_tlb_flush(const void __iomem *base_address, u32 virtual_addr,
-  u32 page_sz)
-{
-   hw_status status = 0;
-   u32 virtual_addr_tag;
-   enum hw_mmu_page_size_t pg_size_bits;
-
-   switch (page_sz) {
-   case HW_PAGE_SIZE4KB:
-   pg_size_bits = HW_MMU_SMALL_PAGE;
-   break;
-
-   case HW_PAGE_SIZE64KB:
-   pg_size_bits = HW_MMU_LARGE_PAGE;
-   break;
-
-   case HW_PAGE_SIZE1MB:
-   pg_size_bits = HW_MMU_SECTION;
-   break;
-
-   case HW_PAGE_SIZE16MB:
-   pg_size_bits = HW_MMU_SUPERSECTION;
-   break;
-
-   default:
-   return -EINVAL;
-   }
-
-   /* Generate the 20-bit tag from virtual address */
-   virtual_addr_tag = ((virtual_addr  MMU_ADDR_MASK)  12);
-
-   mmu_set_cam_entry(base_address, pg_size_bits, 0, 0, virtual_addr_tag);
-
-   mmu_flush_entry(base_address);
-
-   return status;
-}
-
 hw_status hw_mmu_tlb_add(void __iomem *base_address,
 u32 physical_addr,
 u32 virtual_addr,
@@ -503,18 +440,6 @@ hw_status hw_mmu_pte_clear(const u32 pg_tbl_va, u32 
virtual_addr, u32 page_size)
return status;
 }
 
-/* mmu_flush_entry */
-static hw_status mmu_flush_entry(const void __iomem *base_address)
-{
-   hw_status status = 0;
-   u32 flush_entry_data = 0x1;
-
-   /* write values to register */
-   MMUMMU_FLUSH_ENTRY_WRITE_REGISTER32(base_address, flush_entry_data);
-
-   return status;
-}
-
 /* mmu_set_cam_entry */
 static hw_status mmu_set_cam_entry(void __iomem *base_address,
   const u32 page_sz,
diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.h 
b/drivers/staging/tidspbridge/hw/hw_mmu.h
index 1cdd082..1c50bb3 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.h
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.h
@@ -76,9 +76,6 @@ extern hw_status hw_mmu_twl_enable(void __iomem 
*base_address);
 
 extern hw_status hw_mmu_twl_disable(void __iomem *base_address);
 
-extern hw_status hw_mmu_tlb_flush(const void __iomem *base_address,
- u32 virtual_addr, u32 page_sz);
-
 extern hw_status hw_mmu_tlb_add(void __iomem *base_address,
u32 physical_addr,
u32 virtual_addr,
-- 
1.7.9.5

--
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 2/6] staging: tidspbridge: drop const from custom mmu implementation

[Omar Ramirez Luna]

Custom mmu functions receive a 'const void __iomem *', all the
callers pass a 'void __iomem *', so drop the const to fix the
warnings like:

warning: passing argument 2 of '__raw_writel' discards qualifiers from pointer 
target type
../io.h:88: note: expected 'volatile void *' but argument is of type 'const 
void *'

Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---

Intended for 3.7 due to code changes during rc1.

 drivers/staging/tidspbridge/hw/hw_mmu.c |   40 +++
 drivers/staging/tidspbridge/hw/hw_mmu.h |   28 +++---
 2 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.c 
b/drivers/staging/tidspbridge/hw/hw_mmu.c
index 71cb822..a159450 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.c
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.c
@@ -78,7 +78,7 @@ static hw_status mmu_flush_entry(const void __iomem 
*base_address);
  * INPUTS:
  *
  *   Identifier  : base_address
- *   TypE  : const u32
+ *   Type   : void __iomem *
  *   Description : Base Address of instance of MMU module
  *
  *   Identifier  : page_sz
@@ -112,7 +112,7 @@ static hw_status mmu_flush_entry(const void __iomem 
*base_address);
  *
  * METHOD: : Check the Input parameters and set the CAM entry.
  */
-static hw_status mmu_set_cam_entry(const void __iomem *base_address,
+static hw_status mmu_set_cam_entry(void __iomem *base_address,
   const u32 page_sz,
   const u32 preserved_bit,
   const u32 valid_bit,
@@ -124,7 +124,7 @@ static hw_status mmu_set_cam_entry(const void __iomem 
*base_address,
  * INPUTS:
  *
  *   Identifier  : base_address
- *   Type  : const u32
+ *   Type   : void __iomem *
  *   Description : Base Address of instance of MMU module
  *
  *   Identifier  : physical_addr
@@ -157,7 +157,7 @@ static hw_status mmu_set_cam_entry(const void __iomem 
*base_address,
  *
  * METHOD:: Check the Input parameters and set the RAM entry.
  */
-static hw_status mmu_set_ram_entry(const void __iomem *base_address,
+static hw_status mmu_set_ram_entry(void __iomem *base_address,
   const u32 physical_addr,
   enum hw_endianism_t endianism,
   enum hw_element_size_t element_size,
@@ -165,7 +165,7 @@ static hw_status mmu_set_ram_entry(const void __iomem 
*base_address,
 
 /* HW FUNCTIONS */
 
-hw_status hw_mmu_enable(const void __iomem *base_address)
+hw_status hw_mmu_enable(void __iomem *base_address)
 {
hw_status status = 0;
 
@@ -174,7 +174,7 @@ hw_status hw_mmu_enable(const void __iomem *base_address)
return status;
 }
 
-hw_status hw_mmu_disable(const void __iomem *base_address)
+hw_status hw_mmu_disable(void __iomem *base_address)
 {
hw_status status = 0;
 
@@ -183,7 +183,7 @@ hw_status hw_mmu_disable(const void __iomem *base_address)
return status;
 }
 
-hw_status hw_mmu_num_locked_set(const void __iomem *base_address,
+hw_status hw_mmu_num_locked_set(void __iomem *base_address,
u32 num_locked_entries)
 {
hw_status status = 0;
@@ -193,7 +193,7 @@ hw_status hw_mmu_num_locked_set(const void __iomem 
*base_address,
return status;
 }
 
-hw_status hw_mmu_victim_num_set(const void __iomem *base_address,
+hw_status hw_mmu_victim_num_set(void __iomem *base_address,
u32 victim_entry_num)
 {
hw_status status = 0;
@@ -203,7 +203,7 @@ hw_status hw_mmu_victim_num_set(const void __iomem 
*base_address,
return status;
 }
 
-hw_status hw_mmu_event_ack(const void __iomem *base_address, u32 irq_mask)
+hw_status hw_mmu_event_ack(void __iomem *base_address, u32 irq_mask)
 {
hw_status status = 0;
 
@@ -212,7 +212,7 @@ hw_status hw_mmu_event_ack(const void __iomem 
*base_address, u32 irq_mask)
return status;
 }
 
-hw_status hw_mmu_event_disable(const void __iomem *base_address, u32 irq_mask)
+hw_status hw_mmu_event_disable(void __iomem *base_address, u32 irq_mask)
 {
hw_status status = 0;
u32 irq_reg;
@@ -224,7 +224,7 @@ hw_status hw_mmu_event_disable(const void __iomem 
*base_address, u32 irq_mask)
return status;
 }
 
-hw_status hw_mmu_event_enable(const void __iomem *base_address, u32 irq_mask)
+hw_status hw_mmu_event_enable(void __iomem *base_address, u32 irq_mask)
 {
hw_status status = 0;
u32 irq_reg;
@@ -236,7 +236,7 @@ hw_status hw_mmu_event_enable(const void __iomem 
*base_address, u32 irq_mask)
return status;
 }
 
-hw_status hw_mmu_event_status(const void __iomem *base_address, u32 *irq_mask)
+hw_status hw_mmu_event_status(void __iomem *base_address, u32 *irq_mask)
 {
hw_status status = 0;
 
@@ -245,7 +245,7 @@ hw_status

[PATCH 5/6] staging: tidspbridge: ioremap physical address of the stack segment in shm

[Omar Ramirez Luna]

Due to data type change, readl can no longer receive a u32.

Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---

Intended for 3.7 due to code changes during rc1.

 drivers/staging/tidspbridge/rmgr/node.c |   21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tidspbridge/rmgr/node.c 
b/drivers/staging/tidspbridge/rmgr/node.c
index c2fc613..294e9b4 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -304,8 +304,7 @@ int node_allocate(struct proc_object *hprocessor,
u32 pul_value;
u32 dynext_base;
u32 off_set = 0;
-   u32 ul_stack_seg_addr, ul_stack_seg_val;
-   u32 ul_gpp_mem_base;
+   u32 ul_stack_seg_val;
struct cfg_hostres *host_res;
struct bridge_dev_context *pbridge_context;
u32 mapped_addr = 0;
@@ -581,6 +580,9 @@ func_cont:
if (strcmp((char *)
   pnode-dcd_props.obj_data.node_obj.ndb_props.
   stack_seg_name, STACKSEGLABEL) == 0) {
+   void __iomem *stack_seg;
+   u32 stack_seg_pa;
+
status =
hnode_mgr-nldr_fxns.
get_fxn_addr(pnode-nldr_node_obj, DYNEXT_BEG,
@@ -608,14 +610,21 @@ func_cont:
goto func_end;
}
 
-   ul_gpp_mem_base = (u32) host_res-mem_base[1];
off_set = pul_value - dynext_base;
-   ul_stack_seg_addr = ul_gpp_mem_base + off_set;
-   ul_stack_seg_val = readl(ul_stack_seg_addr);
+   stack_seg_pa = host_res-mem_phys[1] + off_set;
+   stack_seg = ioremap(stack_seg_pa, SZ_32);
+   if (!stack_seg) {
+   status = -ENOMEM;
+   goto func_end;
+   }
+
+   ul_stack_seg_val = readl(stack_seg);
+
+   iounmap(stack_seg);
 
dev_dbg(bridge, %s: StackSegVal = 0x%x, StackSegAddr =
 0x%x\n, __func__, ul_stack_seg_val,
-   ul_stack_seg_addr);
+   host_res-mem_base[1] + off_set);
 
pnode-create_args.asa.task_arg_obj.stack_seg =
ul_stack_seg_val;
-- 
1.7.9.5

--
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/6] staging: tidspbridge fixes for 3.7

[Omar Ramirez Luna]

With 3.7-rc1 changes:

- New irq numbering in OMAP3 broke the driver request for a mmu irq,
  until this is migrated to the common iommu framework we can only
  hardcode the new number.
- _raw_* accessors changed a type of one of their parameters with patch
  195bbca ARM: 7500/1: io: avoid writeback addressing modes for
  __raw_ accessors, so the build system was filled with warnings from
  the old parameter usage.

Omar Ramirez Luna (6):
  staging: tidspbridge: request the right irq for mmu
  staging: tidspbridge: drop const from custom mmu implementation
  staging: tidspbridge: change type to __iomem for per and core
addresses
  staging: tidspbridge: ioremap dsp sync addr
  staging: tidspbridge: ioremap physical address of the stack segment
in shm
  staging: tidspbridge: delete unused mmu functions

 drivers/staging/tidspbridge/core/tiomap3430.c  |   37 +--
 drivers/staging/tidspbridge/hw/hw_mmu.c|  115 
 drivers/staging/tidspbridge/hw/hw_mmu.h|   31 +++---
 .../tidspbridge/include/dspbridge/cfgdefs.h|4 +-
 .../tidspbridge/include/dspbridge/host_os.h|4 +-
 drivers/staging/tidspbridge/rmgr/drv.c |8 +-
 drivers/staging/tidspbridge/rmgr/node.c|   21 +++-
 7 files changed, 83 insertions(+), 137 deletions(-)

-- 
1.7.9.5

--
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/6] staging: tidspbridge: ioremap dsp sync addr

[Omar Ramirez Luna]

Change the type of sync_addr to 'void __iomem *' and ioremap the
physical address in the shared memory so we can access it using
_raw_*. While at it, drop 'dw_' prefix.

Fix the warning associated with dsp's sync_addr:

warning: passing argument 2 of '__raw_writel' makes pointer from integer 
without a cast
../io.h:88: note: expected 'volatile void *' but argument is of type 'u32'

Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---

Intended for 3.7 due to code changes during rc1.

 drivers/staging/tidspbridge/core/tiomap3430.c |   37 +
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 066a3ce..f619fb3 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -126,7 +126,8 @@ static int mem_map_vmalloc(struct bridge_dev_context 
*dev_context,
  u32 ul_num_bytes,
  struct hw_mmu_map_attrs_t *hw_attrs);
 
-bool wait_for_start(struct bridge_dev_context *dev_context, u32 dw_sync_addr);
+bool wait_for_start(struct bridge_dev_context *dev_context,
+   void __iomem *sync_addr);
 
 /*  --- Globals */
 
@@ -363,10 +364,11 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
 {
int status = 0;
struct bridge_dev_context *dev_context = dev_ctxt;
-   u32 dw_sync_addr = 0;
+   void __iomem *sync_addr;
u32 ul_shm_base;/* Gpp Phys SM base addr(byte) */
u32 ul_shm_base_virt;   /* Dsp Virt SM base addr */
u32 ul_tlb_base_virt;   /* Base of MMU TLB entry */
+   u32 shm_sync_pa;
/* Offset of shm_base_virt from tlb_base_virt */
u32 ul_shm_offset_virt;
s32 entry_ndx;
@@ -397,15 +399,22 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
/* Kernel logical address */
ul_shm_base = dev_context-atlb_entry[0].gpp_va + ul_shm_offset_virt;
 
+   /* SHM physical sync address */
+   shm_sync_pa = dev_context-atlb_entry[0].gpp_pa + ul_shm_offset_virt +
+   SHMSYNCOFFSET;
+
/* 2nd wd is used as sync field */
-   dw_sync_addr = ul_shm_base + SHMSYNCOFFSET;
+   sync_addr = ioremap(shm_sync_pa, SZ_32);
+   if (!sync_addr)
+   return -ENOMEM;
+
/* Write a signature into the shm base + offset; this will
 * get cleared when the DSP program starts. */
if ((ul_shm_base_virt == 0) || (ul_shm_base == 0)) {
pr_err(%s: Illegal SM base\n, __func__);
status = -EPERM;
} else
-   __raw_writel(0x, dw_sync_addr);
+   __raw_writel(0x, sync_addr);
 
if (!status) {
resources = dev_context-resources;
@@ -419,8 +428,10 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
 * function is made available.
 */
void __iomem *ctrl = ioremap(0x48002000, SZ_4K);
-   if (!ctrl)
+   if (!ctrl) {
+   iounmap(sync_addr);
return -ENOMEM;
+   }
 
(*pdata-dsp_prm_rmw_bits)(OMAP3430_RST1_IVA2_MASK,
OMAP3430_RST1_IVA2_MASK, 
OMAP3430_IVA2_MOD,
@@ -588,15 +599,15 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
(*pdata-dsp_prm_rmw_bits)(OMAP3430_RST1_IVA2_MASK, 0,
OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
 
-   dev_dbg(bridge, Waiting for Sync @ 0x%x\n, dw_sync_addr);
+   dev_dbg(bridge, Waiting for Sync @ 0x%x\n, *(u32 *)sync_addr);
dev_dbg(bridge, DSP c_int00 Address =  0x%x\n, dsp_addr);
if (dsp_debug)
-   while (__raw_readw(dw_sync_addr))
+   while (__raw_readw(sync_addr))
;
 
/* Wait for DSP to clear word in shared memory */
/* Read the Location */
-   if (!wait_for_start(dev_context, dw_sync_addr))
+   if (!wait_for_start(dev_context, sync_addr))
status = -ETIMEDOUT;
 
dev_get_symbol(dev_context-dev_obj, _WDT_enable, wdt_en);
@@ -612,7 +623,7 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
/* Write the synchronization bit to indicate the
 * completion of OPP table update to DSP
 */
-   __raw_writel(0XCAFECAFE, dw_sync_addr);
+   __raw_writel(0XCAFECAFE, sync_addr);
 
/* update board state */
dev_context

[PATCH 3/6] staging: tidspbridge: change type to __iomem for per and core addresses

[Omar Ramirez Luna]

Currently per_pm_base and core_pm_base are declared as u32, however
_raw_* changed the data type, since:

195bbca ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors

This should fix warnings for per and core accesses:

warning: passing argument 2 of '__raw_writel' makes pointer from integer 
without a cast
../io.h:88: note: expected 'volatile void *' but argument is of type 'u32'

Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
---

Intended for 3.7 due to code changes during rc1.

 .../tidspbridge/include/dspbridge/cfgdefs.h|4 ++--
 drivers/staging/tidspbridge/rmgr/drv.c |8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h 
b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
index 60a2781..b32c756 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
@@ -53,8 +53,8 @@ struct cfg_hostres {
u32 chnl_buf_size;
u32 num_chnls;
void __iomem *per_base;
-   u32 per_pm_base;
-   u32 core_pm_base;
+   void __iomem *per_pm_base;
+   void __iomem *core_pm_base;
void __iomem *dmmu_base;
 };
 
diff --git a/drivers/staging/tidspbridge/rmgr/drv.c 
b/drivers/staging/tidspbridge/rmgr/drv.c
index 6795205..db1da28 100644
--- a/drivers/staging/tidspbridge/rmgr/drv.c
+++ b/drivers/staging/tidspbridge/rmgr/drv.c
@@ -667,10 +667,10 @@ int drv_request_bridge_res_dsp(void **phost_resources)
 OMAP_DSP_MEM3_SIZE);
host_res-per_base = ioremap(OMAP_PER_CM_BASE,
OMAP_PER_CM_SIZE);
-   host_res-per_pm_base = (u32) ioremap(OMAP_PER_PRM_BASE,
-OMAP_PER_PRM_SIZE);
-   host_res-core_pm_base = (u32) ioremap(OMAP_CORE_PRM_BASE,
- OMAP_CORE_PRM_SIZE);
+   host_res-per_pm_base = ioremap(OMAP_PER_PRM_BASE,
+   OMAP_PER_PRM_SIZE);
+   host_res-core_pm_base = ioremap(OMAP_CORE_PRM_BASE,
+   OMAP_CORE_PRM_SIZE);
host_res-dmmu_base = ioremap(OMAP_DMMU_BASE,
 OMAP_DMMU_SIZE);
 
-- 
1.7.9.5

--
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/6] staging: tidspbridge fixes for 3.7

[Omar Ramirez Luna]

Hi,

On Wed, Oct 24, 2012 at 5:28 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 On Wed, Oct 24, 2012 at 05:09:14PM -0500, Omar Ramirez Luna wrote:
 With 3.7-rc1 changes:

 - New irq numbering in OMAP3 broke the driver request for a mmu irq,
   until this is migrated to the common iommu framework we can only
   hardcode the new number.
 - _raw_* accessors changed a type of one of their parameters with patch
   195bbca ARM: 7500/1: io: avoid writeback addressing modes for
   __raw_ accessors, so the build system was filled with warnings from
   the old parameter usage.

 Omar Ramirez Luna (6):
   staging: tidspbridge: request the right irq for mmu
   staging: tidspbridge: drop const from custom mmu implementation
   staging: tidspbridge: change type to __iomem for per and core
 addresses
   staging: tidspbridge: ioremap dsp sync addr
   staging: tidspbridge: ioremap physical address of the stack segment
 in shm
   staging: tidspbridge: delete unused mmu functions

 Are the fix up the compiler warning patches really needed for 3.7?
 Are they new in 3.7-rc1?  Or were they there before in 3.6?

All are new in 3.7-rc1.

The warning fixes would be good to have and thought they could make
it given that the change was introduced during 3.7 rc cycle. So, the
warnings are not that critical.

Cheers,

Omar
--
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 v2 8/9] ARM: OMAP: iommu: add device tree support

[Omar Ramirez Luna]

Hi Matt,

On 2 October 2012 16:25, Matt Porter  wrote:
...
> I can see why you went this path with the iommu driver as it already had
> some integration code present here. I have some concerns going forward
> about how this should be long-term. Take any platform booting only with
> DT populated, we'd like to avoid having to use this approach where
> platform private APIs are called via pdata. In fact, it's going to makes
> thing ugly to carry any sort of pdata for a driver that's otherwise
> driven exclusively from DT.
>
> For AM335x, I can implement this approach, but it means adding some
> pruss specific integration code just to have it create the pdata for
> reset_name and assert/deassert.

Yes I agree, it looks a bit ugly for devices that have more than one
reset line name too, but right now there is no other way to keep the
reset names and also provide flexibility to the driver to control them
in a given order.

> From reading all the threads on hardresets and OMAP, it seems we may not
> be able to come up with a generic OMAP handler for these resets and
> that's really reflected in the fact that this API exists. So given that,
> it reasons that OMAP isn't the only one needing a reset API for drivers.
> I'm thinking that (as trivial as it may seem), this support may need to
> move to a reset subsystem such that drivers have a clean way to access
> reset resources in an SoC.

Well, there was a point where the OMAP hwmod code contained the reset
code and at least for me it was working fine, with iommu and ipu
processor, just with a minor misleading warning print... however then
this code got stripped out and since there appeared to be people
needing to handle their reset lines in unknown ways it was advised
that everybody should implement their own reset functions, but in my
case I could reuse most of the disabled code at the expense of almost
duplicating _enable (omap_hwmod) function while waiting all the reset
line users started asking for changes.

> I'm curious if you or others have thought about where this needs to go
> next.

I haven't planned for a reset subsystem or a more generic
implementation, although I have been looking for a way to avoid using
the pdata function pointers.

> When I first thought about a reset subsystem it seemed to trivial
> to bother with but looking at the reasoning behind the power_seq
> subsystem, it seems to have similar justification to get this machine
> specific logic out of the platform code and under standardized control
> of the driver.

IMHO, the reset code even if made a subsystem or a library, would
still need to interface with machine specific code and definitions
(say omap_hwmod), so I don't see much difference in making the
omap_device reset handlers as exported symbols for the time being,
with acceptance of the owners of omap_device code.

And then if power_seq makes it to mainline perhaps extending it to
handle deassert, assert and softreset events, but then again this
would have the same hooks to omap_hwmod which is the one with the prcm
information.

Regards,

Omar
--
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 v2 8/9] ARM: OMAP: iommu: add device tree support

[Omar Ramirez Luna]

Hi Matt,

On 2 October 2012 16:25, Matt Porter mpor...@ti.com wrote:
...
 I can see why you went this path with the iommu driver as it already had
 some integration code present here. I have some concerns going forward
 about how this should be long-term. Take any platform booting only with
 DT populated, we'd like to avoid having to use this approach where
 platform private APIs are called via pdata. In fact, it's going to makes
 thing ugly to carry any sort of pdata for a driver that's otherwise
 driven exclusively from DT.

 For AM335x, I can implement this approach, but it means adding some
 pruss specific integration code just to have it create the pdata for
 reset_name and assert/deassert.

Yes I agree, it looks a bit ugly for devices that have more than one
reset line name too, but right now there is no other way to keep the
reset names and also provide flexibility to the driver to control them
in a given order.

 From reading all the threads on hardresets and OMAP, it seems we may not
 be able to come up with a generic OMAP handler for these resets and
 that's really reflected in the fact that this API exists. So given that,
 it reasons that OMAP isn't the only one needing a reset API for drivers.
 I'm thinking that (as trivial as it may seem), this support may need to
 move to a reset subsystem such that drivers have a clean way to access
 reset resources in an SoC.

Well, there was a point where the OMAP hwmod code contained the reset
code and at least for me it was working fine, with iommu and ipu
processor, just with a minor misleading warning print... however then
this code got stripped out and since there appeared to be people
needing to handle their reset lines in unknown ways it was advised
that everybody should implement their own reset functions, but in my
case I could reuse most of the disabled code at the expense of almost
duplicating _enable (omap_hwmod) function while waiting all the reset
line users started asking for changes.

 I'm curious if you or others have thought about where this needs to go
 next.

I haven't planned for a reset subsystem or a more generic
implementation, although I have been looking for a way to avoid using
the pdata function pointers.

 When I first thought about a reset subsystem it seemed to trivial
 to bother with but looking at the reasoning behind the power_seq
 subsystem, it seems to have similar justification to get this machine
 specific logic out of the platform code and under standardized control
 of the driver.

IMHO, the reset code even if made a subsystem or a library, would
still need to interface with machine specific code and definitions
(say omap_hwmod), so I don't see much difference in making the
omap_device reset handlers as exported symbols for the time being,
with acceptance of the owners of omap_device code.

And then if power_seq makes it to mainline perhaps extending it to
handle deassert, assert and softreset events, but then again this
would have the same hooks to omap_hwmod which is the one with the prcm
information.

Regards,

Omar
--
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 v2 0/2] OMAP: mailbox initial device tree support

[Omar Ramirez Luna]

Hi Benoit,

On 12 September 2012 19:08, Omar Ramirez Luna  wrote:
> To allow mailbox driver to function with device tree.
>
> Tested in OMAP4 and OMAP3. OMAP2 untested.
>
> Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit
> however it seems it wasn't picked up, so resend.
>
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html
>
> Patch: OMAP: mailbox: add device tree support, there wasn't an
> opposition other than to cleanup the driver too, however I got
> quite some patches to send before continuing the cleanup.
>
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html
>
> Omar Ramirez Luna (2):
>   OMAP: mailbox: add device tree support
>   arm/dts: OMAP2+: Add mailbox nodes
>
>  .../devicetree/bindings/arm/omap/mailbox.txt   |9 +
>  arch/arm/boot/dts/omap2.dtsi   |5 +
>  arch/arm/boot/dts/omap3.dtsi   |5 +
>  arch/arm/boot/dts/omap4.dtsi   |5 +
>  arch/arm/mach-omap2/devices.c  |3 +++
>  arch/arm/mach-omap2/mailbox.c  |   12 
>  6 files changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt

Ping. I'm in the understanding that these go through your tree, am I right?

Regards,

Omar
--
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 v2 0/2] OMAP: mailbox initial device tree support

[Omar Ramirez Luna]

Hi Benoit,

On 12 September 2012 19:08, Omar Ramirez Luna omar.l...@linaro.org wrote:
 To allow mailbox driver to function with device tree.

 Tested in OMAP4 and OMAP3. OMAP2 untested.

 Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit
 however it seems it wasn't picked up, so resend.

 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html

 Patch: OMAP: mailbox: add device tree support, there wasn't an
 opposition other than to cleanup the driver too, however I got
 quite some patches to send before continuing the cleanup.

 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html

 Omar Ramirez Luna (2):
   OMAP: mailbox: add device tree support
   arm/dts: OMAP2+: Add mailbox nodes

  .../devicetree/bindings/arm/omap/mailbox.txt   |9 +
  arch/arm/boot/dts/omap2.dtsi   |5 +
  arch/arm/boot/dts/omap3.dtsi   |5 +
  arch/arm/boot/dts/omap4.dtsi   |5 +
  arch/arm/mach-omap2/devices.c  |3 +++
  arch/arm/mach-omap2/mailbox.c  |   12 
  6 files changed, 39 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt

Ping. I'm in the understanding that these go through your tree, am I right?

Regards,

Omar
--
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/2] The tidspbridge driver does not compile anymore (Some OMAP34XX CPU definitions are missing). I Added a header file for these definitions.

[Omar Ramirez Luna]

Hi,

On Mon, Sep 24, 2012 at 1:54 PM, selso  wrote:
> From: sli 
>
>
> Signed-off-by: sli 
> ---
>  drivers/staging/tidspbridge/core/dsp-clock.c   |3 ++
>  drivers/staging/tidspbridge/core/tiomap3430.c  |4 ++
>  drivers/staging/tidspbridge/core/wdt.c |2 +-
>  .../tidspbridge/include/dspbridge/omap34xx.h   |   33 
> 
>  4 files changed, 41 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/staging/tidspbridge/include/dspbridge/omap34xx.h

This is fixed with this patch:

https://patchwork.kernel.org/patch/1435311/

Thanks,

Omar
--
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/2] The tidspbridge driver does not compile anymore (Some OMAP34XX CPU definitions are missing). I Added a header file for these definitions.

[Omar Ramirez Luna]

Hi,

On Mon, Sep 24, 2012 at 1:54 PM, selso selso.liber...@gmail.com wrote:
 From: sli sli@SLI-V420.(none)


 Signed-off-by: sli sli@SLI-V420.(none)
 ---
  drivers/staging/tidspbridge/core/dsp-clock.c   |3 ++
  drivers/staging/tidspbridge/core/tiomap3430.c  |4 ++
  drivers/staging/tidspbridge/core/wdt.c |2 +-
  .../tidspbridge/include/dspbridge/omap34xx.h   |   33 
 
  4 files changed, 41 insertions(+), 1 deletions(-)
  create mode 100644 drivers/staging/tidspbridge/include/dspbridge/omap34xx.h

This is fixed with this patch:

https://patchwork.kernel.org/patch/1435311/

Thanks,

Omar
--
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 v2 7/9] ARM: OMAP: iommu: optimize save and restore routines

[Omar Ramirez Luna]

Hi Tony,

On 18 September 2012 13:04, Tony Lindgren  wrote:
> * Omar Ramirez Luna  [120912 12:47]:
>> --- a/arch/arm/plat-omap/include/plat/iommu.h
>> +++ b/arch/arm/plat-omap/include/plat/iommu.h
>> @@ -27,6 +27,13 @@ struct iotlb_entry {
>>   };
>>  };
>>
>> +/* context registers */
>> +struct iommu_regs {
>> + u32 irqen;
>> + u32 cntl;
>> + u32 ttb;
>> +};
>> +
>>  struct omap_iommu {
>>   const char  *name;
>>   struct module   *owner;
>> @@ -50,7 +57,8 @@ struct omap_iommu {
>>   struct list_headmmap;
>>   struct mutexmmap_lock; /* protect mmap */
>>
>> - void *ctx; /* iommu context: registres saved area */
>> + struct iommu_regs context;
>> + int ctx_loss_cnt;
>>   u32 da_start;
>>   u32 da_end;
>>  };
>> --- a/arch/arm/plat-omap/include/plat/iommu2.h
>> +++ b/arch/arm/plat-omap/include/plat/iommu2.h
>> @@ -35,8 +35,6 @@
>>  #define MMU_READ_RAM 0x6c
>>  #define MMU_EMU_FAULT_AD 0x70
>>
>> -#define MMU_REG_SIZE 256
>> -
>>  /*
>>   * MMU Register bit definitions
>>   */
>
> These headers should be moved to include/linux/platform_data/iommu-omap.h
> or something like that. Care to take care of that too?
>
> I guess there's no reason to have both iommu.h and iommuh2.h?

Agree, can this be made as part of a separate cleanup series? I was
hoping these could make it for 3.7 so we could have a usable rpmsg for
omap4.

Regards,

Omar
--
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 v2 7/9] ARM: OMAP: iommu: optimize save and restore routines

[Omar Ramirez Luna]

Hi Tony,

On 18 September 2012 13:04, Tony Lindgren t...@atomide.com wrote:
 * Omar Ramirez Luna omar.l...@linaro.org [120912 12:47]:
 --- a/arch/arm/plat-omap/include/plat/iommu.h
 +++ b/arch/arm/plat-omap/include/plat/iommu.h
 @@ -27,6 +27,13 @@ struct iotlb_entry {
   };
  };

 +/* context registers */
 +struct iommu_regs {
 + u32 irqen;
 + u32 cntl;
 + u32 ttb;
 +};
 +
  struct omap_iommu {
   const char  *name;
   struct module   *owner;
 @@ -50,7 +57,8 @@ struct omap_iommu {
   struct list_headmmap;
   struct mutexmmap_lock; /* protect mmap */

 - void *ctx; /* iommu context: registres saved area */
 + struct iommu_regs context;
 + int ctx_loss_cnt;
   u32 da_start;
   u32 da_end;
  };
 --- a/arch/arm/plat-omap/include/plat/iommu2.h
 +++ b/arch/arm/plat-omap/include/plat/iommu2.h
 @@ -35,8 +35,6 @@
  #define MMU_READ_RAM 0x6c
  #define MMU_EMU_FAULT_AD 0x70

 -#define MMU_REG_SIZE 256
 -
  /*
   * MMU Register bit definitions
   */

 These headers should be moved to include/linux/platform_data/iommu-omap.h
 or something like that. Care to take care of that too?

 I guess there's no reason to have both iommu.h and iommuh2.h?

Agree, can this be made as part of a separate cleanup series? I was
hoping these could make it for 3.7 so we could have a usable rpmsg for
omap4.

Regards,

Omar
--
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 v2 1/2] OMAP: mailbox: add device tree support

[Omar Ramirez Luna]

Adapt driver to use DT if provided.

Signed-off-by: Omar Ramirez Luna 
---
 .../devicetree/bindings/arm/omap/mailbox.txt   |9 +
 arch/arm/mach-omap2/devices.c  |3 +++
 arch/arm/mach-omap2/mailbox.c  |   12 
 3 files changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt

diff --git a/Documentation/devicetree/bindings/arm/omap/mailbox.txt 
b/Documentation/devicetree/bindings/arm/omap/mailbox.txt
new file mode 100644
index 000..c57c0d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/mailbox.txt
@@ -0,0 +1,9 @@
+OMAP Mailbox module
+
+Required properties:
+ compatible : should be "ti,omap2-mailbox" for OMAP2 mailbox
+ compatible : should be "ti,omap3-mailbox" for OMAP3 mailbox
+ compatible : should be "ti,omap4-mailbox" for OMAP4 mailbox
+
+Optional properties:
+ None
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c00c689..19093fb 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -279,6 +279,9 @@ static inline void __init omap_init_mbox(void)
struct omap_hwmod *oh;
struct platform_device *pdev;
 
+   if (of_have_populated_dt())
+   return;
+
oh = omap_hwmod_lookup("mailbox");
if (!oh) {
pr_err("%s: unable to find hwmod\n", __func__);
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 6875be8..80beadf 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -400,11 +401,22 @@ static int __devexit omap2_mbox_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_mailbox_of_match[] = {
+   { .compatible = "ti,omap2-mailbox" },
+   { .compatible = "ti,omap3-mailbox" },
+   { .compatible = "ti,omap4-mailbox" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+#endif
+
 static struct platform_driver omap2_mbox_driver = {
.probe = omap2_mbox_probe,
.remove = __devexit_p(omap2_mbox_remove),
.driver = {
.name = "omap-mailbox",
+   .of_match_table = of_match_ptr(omap_mailbox_of_match),
},
 };
 
-- 
1.7.9.5

--
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 v2 0/2] OMAP: mailbox initial device tree support

[Omar Ramirez Luna]

To allow mailbox driver to function with device tree.

Tested in OMAP4 and OMAP3. OMAP2 untested.

Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit
however it seems it wasn't picked up, so resend.

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html

Patch: OMAP: mailbox: add device tree support, there wasn't an
opposition other than to cleanup the driver too, however I got
quite some patches to send before continuing the cleanup.

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html

Omar Ramirez Luna (2):
  OMAP: mailbox: add device tree support
  arm/dts: OMAP2+: Add mailbox nodes

 .../devicetree/bindings/arm/omap/mailbox.txt   |9 +
 arch/arm/boot/dts/omap2.dtsi   |5 +
 arch/arm/boot/dts/omap3.dtsi   |5 +
 arch/arm/boot/dts/omap4.dtsi   |5 +
 arch/arm/mach-omap2/devices.c  |3 +++
 arch/arm/mach-omap2/mailbox.c  |   12 
 6 files changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt

-- 
1.7.9.5

--
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 v2 2/2] arm/dts: OMAP2+: Add mailbox nodes

[Omar Ramirez Luna]

Add nodes for mailbox DT, to interface with hwmods.

Signed-off-by: Omar Ramirez Luna 
Acked-by: Benoit Cousson 
---
 arch/arm/boot/dts/omap2.dtsi |5 +
 arch/arm/boot/dts/omap3.dtsi |5 +
 arch/arm/boot/dts/omap4.dtsi |5 +
 3 files changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 581cb08..372d55a 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -48,6 +48,11 @@
reg = <0x480FE000 0x1000>;
};
 
+   mailbox: mailbox@48094000 {
+   compatible = "ti,omap2-mailbox";
+   ti,hwmods = "mailbox";
+   };
+
uart1: serial@4806a000 {
compatible = "ti,omap2-uart";
ti,hwmods = "uart1";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..ce68604 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -168,6 +168,11 @@
ti,hwmods = "i2c3";
};
 
+   mailbox: mailbox@48094000 {
+   compatible = "ti,omap3-mailbox";
+   ti,hwmods = "mailbox";
+   };
+
mcspi1: spi@48098000 {
compatible = "ti,omap2-mcspi";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 04cbbcb..6677d80 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -210,6 +210,11 @@
ti,hwmods = "i2c4";
};
 
+   mailbox: mailbox@4a0f4000 {
+   compatible = "ti,omap4-mailbox";
+   ti,hwmods = "mailbox";
+   };
+
mcspi1: spi@48098000 {
compatible = "ti,omap4-mcspi";
#address-cells = <1>;
-- 
1.7.9.5

--
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 v2 0/2] OMAP: mailbox initial device tree support

[Omar Ramirez Luna]

To allow mailbox driver to function with device tree.

Tested in OMAP4 and OMAP3. OMAP2 untested.

Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit
however it seems it wasn't picked up, so resend.

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html

Patch: OMAP: mailbox: add device tree support, there wasn't an
opposition other than to cleanup the driver too, however I got
quite some patches to send before continuing the cleanup.

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html

Omar Ramirez Luna (2):
  OMAP: mailbox: add device tree support
  arm/dts: OMAP2+: Add mailbox nodes

 .../devicetree/bindings/arm/omap/mailbox.txt   |9 +
 arch/arm/boot/dts/omap2.dtsi   |5 +
 arch/arm/boot/dts/omap3.dtsi   |5 +
 arch/arm/boot/dts/omap4.dtsi   |5 +
 arch/arm/mach-omap2/devices.c  |3 +++
 arch/arm/mach-omap2/mailbox.c  |   12 
 6 files changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt

-- 
1.7.9.5

--
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/