[GIT PULL] Renesas ARM-based SoC fix for v3.6

[GIT PULL] Renesas ARM-based SoC fix for v3.6

[Rafael J. Wysocki]

Hi,

Please pull from the git repository at

  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git fixes

to receive one fix for the sh73a0 SoC support code as commit
6c0274cbe63ec265f842537825684a619e6cce93

  ARM: shmobile: sh73a0: fixup RELOC_BASE of intca_irq_pins_desc

on top of commit d9875690d9b89a866022ff49e3fcea892345ad92

  Linux 3.6-rc2

It fixes an IRQ configuration issue uncovered by the addition of
preliminary irqdomain support.

Thanks!


 arch/arm/mach-shmobile/intc-sh73a0.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

---------------

Kuninori Morimoto (1):
      ARM: shmobile: sh73a0: fixup RELOC_BASE of intca_irq_pins_desc

Re: [GIT PULL] Renesas ARM-based SoC fix for v3.6

[Olof Johansson]

On Fri, Aug 24, 2012 at 01:18:16AM +0200, Rafael J. Wysocki wrote:
> Hi,
> 
> Please pull from the git repository at
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git fixes
> 
> to receive one fix for the sh73a0 SoC support code as commit
> 6c0274cbe63ec265f842537825684a619e6cce93
> 
>   ARM: shmobile: sh73a0: fixup RELOC_BASE of intca_irq_pins_desc
> 
> on top of commit d9875690d9b89a866022ff49e3fcea892345ad92
> 
>   Linux 3.6-rc2

Thanks, pulled.

-Olof

[GIT PULL] Renesas ARM-based SoC fix for v3.6

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following boot-failure fix for the Marzen board from
Morimoto-san for inclusion in 3.6.

----------------------------------------------------------------
The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:

  Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git fixes

for you to fetch changes up to 497dcf6fc355f0734faf851662b6957386715d24:

  ARM: shmobile: marzen: fixup smsc911x id for regulator (2012-08-30 14:10:08 +0900)

----------------------------------------------------------------
Kuninori Morimoto (1):
      ARM: shmobile: marzen: fixup smsc911x id for regulator

 arch/arm/mach-shmobile/board-marzen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] ARM: shmobile: marzen: fixup smsc911x id for regulator

[Simon Horman]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

dummy_supplies for smsc911x are registered as "smsc911x".
smsc911x driver needs id = -1

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/mach-shmobile/board-marzen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
index 3a528cf..fcf5a47 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -67,7 +67,7 @@ static struct smsc911x_platform_config smsc911x_platdata = {
 
 static struct platform_device eth_device = {
 	.name		= "smsc911x",
-	.id		= 0,
+	.id		= -1,
 	.dev  = {
 		.platform_data = &smsc911x_platdata,
 	},
-- 
1.7.10.2.484.gcd07cc5

Re: [GIT PULL] Renesas ARM-based SoC fix for v3.6

[Olof Johansson]

On Wed, Aug 29, 2012 at 10:38 PM, Simon Horman <horms@verge.net.au> wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following boot-failure fix for the Marzen board from
> Morimoto-san for inclusion in 3.6.
>
> ----------------------------------------------------------------
> The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:
>
>   Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git fixes

Pulled, thanks.


-Olof

[GIT PULL] Renesas ARM-based SoC fix for v3.6 #2

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following fixes for the Armadillo800 EVA and
Mackerel boards from Morimoto-san.

* "ARM: shmobile: armadillo800eva: fixup: sound card detection order"
  is a regression fix.
* "ARM: shmobile: mackerel: fixup usb module order"
  is a regression fix.
* "ARM: shmobile: armadillo800eva: enable rw rootfs mount"
  is a boot-loader compatibility fix.

All of the changes are aimed at improving the end-user experience.

Notes:

* This pull request is based on my previous
  "[GIT PULL] Renesas ARM-based SoC fix for v3.6" pull request
  which was recently pulled by Olof. Please let me know
  if you would like me to handle this a different way.

----------------------------------------------------------------
The following changes since commit 497dcf6fc355f0734faf851662b6957386715d24:

  ARM: shmobile: marzen: fixup smsc911x id for regulator (2012-08-30 14:10:08 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git fixes

for you to fetch changes up to 28e515878f8896b33c325ff9767cb0237210fb4c:

  ARM: shmobile: armadillo800eva: enable rw rootfs mount (2012-09-03 17:31:34 +0900)

----------------------------------------------------------------
Kuninori Morimoto (3):
      ARM: shmobile: armadillo800eva: fixup: sound card detection order
      ARM: shmobile: mackerel: fixup usb module order
      ARM: shmobile: armadillo800eva: enable rw rootfs mount

 arch/arm/configs/armadillo800eva_defconfig     |    2 +-
 arch/arm/mach-shmobile/board-armadillo800eva.c |    2 +-
 arch/arm/mach-shmobile/board-mackerel.c        |    3 ++-
 3 files changed, 4 insertions(+), 3 deletions(-)

[PATCH 1/3] ARM: shmobile: armadillo800eva: fixup: sound card detection order

[Simon Horman]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Since armadillo800eva has 2 sound cards,
and had reversed deferred probe order issue,
it was purposely registered in reverse order.

But it was solved by
1d29cfa57471a5e4b8a7c2a7433eeba170d3ad92
(driver core: fixup reversed deferred probe order)

armadillo800eva board is expecting that
FSI-WM8978 is the 1st, and FSI-HDMI is the 2nd sound card.
This patch fixes it up

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/mach-shmobile/board-armadillo800eva.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index cf10f92..ecd8136 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -901,8 +901,8 @@ static struct platform_device *eva_devices[] __initdata = {
 	&camera_device,
 	&ceu0_device,
 	&fsi_device,
-	&fsi_hdmi_device,
 	&fsi_wm8978_device,
+	&fsi_hdmi_device,
 };
 
 static void __init eva_clock_init(void)
-- 
1.7.10.4

[PATCH 1/3] ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

[Kuninori Morimoto]

Some errata for cache had not enabled on current
Armadillo800eva defconfig.
This patch enables these.
Special thanks to Ishiyama-san

Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 arch/arm/configs/armadillo800eva_defconfig |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 2e1a825..891318e 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -25,10 +25,15 @@ CONFIG_CACHE_L2X0=y
 CONFIG_ARM_ERRATA_430973=y
 CONFIG_ARM_ERRATA_458693=y
 CONFIG_ARM_ERRATA_460075=y
+CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_720789=y
+CONFIG_PL310_ERRATA_727915=y
 CONFIG_ARM_ERRATA_743622=y
 CONFIG_ARM_ERRATA_751472=y
+CONFIG_PL310_ERRATA_753970=y
 CONFIG_ARM_ERRATA_754322=y
+CONFIG_PL310_ERRATA_769419=y
+CONFIG_ARM_ERRATA_775420=y
 CONFIG_AEABI=y
 # CONFIG_OABI_COMPAT is not set
 CONFIG_FORCE_MAX_ZONEORDER\x13
-- 
1.7.9.5

Re: [PATCH 1/3] ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

[Simon Horman]

On Thu, Feb 21, 2013 at 08:45:57PM -0800, Kuninori Morimoto wrote:
> Some errata for cache had not enabled on current
> Armadillo800eva defconfig.
> This patch enables these.
> Special thanks to Ishiyama-san

It seems to me that it would be better to handle these in Kconfig
to enable them on an SoC or board basis.

The reason is that I would like to move away from per-board defconfigs
and towards a more consolidated defconfig. And in that case it will
be more difficult to know which ERRATA are needed for each board and SoC.

Obviously this thinking is open to review and it implies that
several board defconfigs should be updated.

> 
> Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  arch/arm/configs/armadillo800eva_defconfig |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
> index 2e1a825..891318e 100644
> --- a/arch/arm/configs/armadillo800eva_defconfig
> +++ b/arch/arm/configs/armadillo800eva_defconfig
> @@ -25,10 +25,15 @@ CONFIG_CACHE_L2X0=y
>  CONFIG_ARM_ERRATA_430973=y
>  CONFIG_ARM_ERRATA_458693=y
>  CONFIG_ARM_ERRATA_460075=y
> +CONFIG_PL310_ERRATA_588369=y
>  CONFIG_ARM_ERRATA_720789=y
> +CONFIG_PL310_ERRATA_727915=y
>  CONFIG_ARM_ERRATA_743622=y
>  CONFIG_ARM_ERRATA_751472=y
> +CONFIG_PL310_ERRATA_753970=y
>  CONFIG_ARM_ERRATA_754322=y
> +CONFIG_PL310_ERRATA_769419=y
> +CONFIG_ARM_ERRATA_775420=y
>  CONFIG_AEABI=y
>  # CONFIG_OABI_COMPAT is not set
>  CONFIG_FORCE_MAX_ZONEORDER\x13
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 1/3] ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

[Simon Horman]

On Fri, Feb 22, 2013 at 02:58:57PM -0800, Simon Horman wrote:
> On Thu, Feb 21, 2013 at 08:45:57PM -0800, Kuninori Morimoto wrote:
> > Some errata for cache had not enabled on current
> > Armadillo800eva defconfig.
> > This patch enables these.
> > Special thanks to Ishiyama-san
> 
> It seems to me that it would be better to handle these in Kconfig
> to enable them on an SoC or board basis.
> 
> The reason is that I would like to move away from per-board defconfigs
> and towards a more consolidated defconfig. And in that case it will
> be more difficult to know which ERRATA are needed for each board and SoC.
> 
> Obviously this thinking is open to review and it implies that
> several board defconfigs should be updated.

Ping.

> 
> > 
> > Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
> >  arch/arm/configs/armadillo800eva_defconfig |    5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
> > index 2e1a825..891318e 100644
> > --- a/arch/arm/configs/armadillo800eva_defconfig
> > +++ b/arch/arm/configs/armadillo800eva_defconfig
> > @@ -25,10 +25,15 @@ CONFIG_CACHE_L2X0=y
> >  CONFIG_ARM_ERRATA_430973=y
> >  CONFIG_ARM_ERRATA_458693=y
> >  CONFIG_ARM_ERRATA_460075=y
> > +CONFIG_PL310_ERRATA_588369=y
> >  CONFIG_ARM_ERRATA_720789=y
> > +CONFIG_PL310_ERRATA_727915=y
> >  CONFIG_ARM_ERRATA_743622=y
> >  CONFIG_ARM_ERRATA_751472=y
> > +CONFIG_PL310_ERRATA_753970=y
> >  CONFIG_ARM_ERRATA_754322=y
> > +CONFIG_PL310_ERRATA_769419=y
> > +CONFIG_ARM_ERRATA_775420=y
> >  CONFIG_AEABI=y
> >  # CONFIG_OABI_COMPAT is not set
> >  CONFIG_FORCE_MAX_ZONEORDER\x13
> > -- 
> > 1.7.9.5
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 1/3] ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

[Kuninori Morimoto]

Dear Simon

Sorry for my late response

> > > Some errata for cache had not enabled on current
> > > Armadillo800eva defconfig.
> > > This patch enables these.
> > > Special thanks to Ishiyama-san
> > 
> > It seems to me that it would be better to handle these in Kconfig
> > to enable them on an SoC or board basis.
> > 
> > The reason is that I would like to move away from per-board defconfigs
> > and towards a more consolidated defconfig. And in that case it will
> > be more difficult to know which ERRATA are needed for each board and SoC.
> > 
> > Obviously this thinking is open to review and it implies that
> > several board defconfigs should be updated.

We used defconfig selection for CPU/board settings before.
But Kconfig selection for ERRATA make sense.

Do you want to me to send v2 patch which use Kconfig ?
Or do you do that ?


Best regards
--
Kuninori Morimoto
 

Re: [PATCH 1/3] ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

[Simon Horman]

On Fri, Mar 01, 2013 at 07:01:17PM +0900, Kuninori Morimoto wrote:
> 
> Dear Simon
> 
> Sorry for my late response
> 
> > > > Some errata for cache had not enabled on current
> > > > Armadillo800eva defconfig.
> > > > This patch enables these.
> > > > Special thanks to Ishiyama-san
> > > 
> > > It seems to me that it would be better to handle these in Kconfig
> > > to enable them on an SoC or board basis.
> > > 
> > > The reason is that I would like to move away from per-board defconfigs
> > > and towards a more consolidated defconfig. And in that case it will
> > > be more difficult to know which ERRATA are needed for each board and SoC.
> > > 
> > > Obviously this thinking is open to review and it implies that
> > > several board defconfigs should be updated.
> 
> We used defconfig selection for CPU/board settings before.
> But Kconfig selection for ERRATA make sense.
> 
> Do you want to me to send v2 patch which use Kconfig ?
> Or do you do that ?

I'd like you to send v2 if possible.

Re: [PATCH 1/3] ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

[Kuninori Morimoto]

Hi Simon

> > > > > Some errata for cache had not enabled on current
> > > > > Armadillo800eva defconfig.
> > > > > This patch enables these.
> > > > > Special thanks to Ishiyama-san
> > > > 
> > > > It seems to me that it would be better to handle these in Kconfig
> > > > to enable them on an SoC or board basis.
> > > > 
> > > > The reason is that I would like to move away from per-board defconfigs
> > > > and towards a more consolidated defconfig. And in that case it will
> > > > be more difficult to know which ERRATA are needed for each board and SoC.
> > > > 
> > > > Obviously this thinking is open to review and it implies that
> > > > several board defconfigs should be updated.
> > 
> > We used defconfig selection for CPU/board settings before.
> > But Kconfig selection for ERRATA make sense.
> > 
> > Do you want to me to send v2 patch which use Kconfig ?
> > Or do you do that ?
> 
> I'd like you to send v2 if possible.

OK, but I noticed that it will be complex if we select these ERRATA on Kconfig,
Because, these ERRATAs dependency.

Ex)
config PL310_ERRATA_588369
	bool "PL310 errata: Clean & Invalidate maintenance operations do not invalidate clean lines"
	depends on CACHE_L2X0

It depends on CACHE_L2X0, but this CACHE_L2X0 selection is depend on user,
this means that there is no guarantee that CACHE_L2X0 is selected.
Then, the Kconfig will be...

        select PL310_ERRATA_588369 if CACHE_L2X0

And more complex ERRARA dependency is...

config ARM_ERRATA_742230
	bool "ARM errata: DMB operation may be faulty"
	depends on CPU_V7 && SMP
	depends on !ARCH_MULTIPLATFORM

Of course I can use above style on Kconfig,
but my worry is we will have unknown trouble
if someone updated these ERRATA implementation and dependency
in the future...

This is example, but I tested below.
This means we can select unnecessary settings on Kconfig ...

----------------
config ARM_ERRATA_326103
	bool "ARM errata: FSR write bit incorrect on a SWP to read-only memory"
=>	depends on CPU_V6
        ...

config ARCH_R8A7740
	bool "R-Mobile A1 (R8A77400)"
	select ARCH_WANT_OPTIONAL_GPIOLIB
=>	select CPU_V7
=>	select ARM_ERRATA_326103
        ...

> grep ERRATA .config
CONFIG_ARM_ERRATA_326103=y
----------------------

Best regards
---
Kuninori Morimoto

Re: [PATCH 1/3] ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

[Simon Horman]

On Sun, Mar 03, 2013 at 04:42:08PM -0800, Kuninori Morimoto wrote:
> 
> Hi Simon
> 
> > > > > > Some errata for cache had not enabled on current
> > > > > > Armadillo800eva defconfig.
> > > > > > This patch enables these.
> > > > > > Special thanks to Ishiyama-san
> > > > > 
> > > > > It seems to me that it would be better to handle these in Kconfig
> > > > > to enable them on an SoC or board basis.
> > > > > 
> > > > > The reason is that I would like to move away from per-board defconfigs
> > > > > and towards a more consolidated defconfig. And in that case it will
> > > > > be more difficult to know which ERRATA are needed for each board and SoC.
> > > > > 
> > > > > Obviously this thinking is open to review and it implies that
> > > > > several board defconfigs should be updated.
> > > 
> > > We used defconfig selection for CPU/board settings before.
> > > But Kconfig selection for ERRATA make sense.
> > > 
> > > Do you want to me to send v2 patch which use Kconfig ?
> > > Or do you do that ?
> > 
> > I'd like you to send v2 if possible.
> 
> OK, but I noticed that it will be complex if we select these ERRATA on Kconfig,
> Because, these ERRATAs dependency.

Thanks, I see this is indeed getting messy.

The reason that I asked is that I would like to consolidate the defconfigs.
Ideally one for shmobile. But more realistically one per SoC. And I thought
that avoiding adding ERRATAs to defconfigs would make that slightly easier
in the long run. But I don't think it justifies dealing with the mess
you describe below. So I will apply the patch as is.

> Ex)
> config PL310_ERRATA_588369
> 	bool "PL310 errata: Clean & Invalidate maintenance operations do not invalidate clean lines"
> 	depends on CACHE_L2X0
> 
> It depends on CACHE_L2X0, but this CACHE_L2X0 selection is depend on user,
> this means that there is no guarantee that CACHE_L2X0 is selected.
> Then, the Kconfig will be...
> 
>         select PL310_ERRATA_588369 if CACHE_L2X0
> 
> And more complex ERRARA dependency is...
> 
> config ARM_ERRATA_742230
> 	bool "ARM errata: DMB operation may be faulty"
> 	depends on CPU_V7 && SMP
> 	depends on !ARCH_MULTIPLATFORM
> 
> Of course I can use above style on Kconfig,
> but my worry is we will have unknown trouble
> if someone updated these ERRATA implementation and dependency
> in the future...
> 
> This is example, but I tested below.
> This means we can select unnecessary settings on Kconfig ...
> 
> ----------------
> config ARM_ERRATA_326103
> 	bool "ARM errata: FSR write bit incorrect on a SWP to read-only memory"
> =>	depends on CPU_V6
>         ...
> 
> config ARCH_R8A7740
> 	bool "R-Mobile A1 (R8A77400)"
> 	select ARCH_WANT_OPTIONAL_GPIOLIB
> =>	select CPU_V7
> =>	select ARM_ERRATA_326103
>         ...
> 
> > grep ERRATA .config
> CONFIG_ARM_ERRATA_326103=y
> ----------------------
> 
> Best regards
> ---
> Kuninori Morimoto
> 

Re: [PATCH 1/3] ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

[Simon Horman]

On Thu, Feb 21, 2013 at 08:45:57PM -0800, Kuninori Morimoto wrote:
> Some errata for cache had not enabled on current
> Armadillo800eva defconfig.
> This patch enables these.
> Special thanks to Ishiyama-san
> 
> Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Thanks, applied to the defconfig branch of the renesas tree
and thus included in its next branch and queued up for v3.10.

[PATCH 1/3] ARM: shmobile: armadillo800eva: Properly specify HDMI audio link format

[Lars-Peter Clausen]

The DAI link format should be specified for the whole link rather than just
one component on the link. So move the format specification for the HDMI
audio link from the CPU component to the link itself.

Since the sh-mobile-hdmi DAI driver doesn't implement the set_fmt() callback
in this case there is no functional difference between only specifying the
the format for the CPU side or for the whole link, but the later it will
allow us to remove support for just specifying the format for one component.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
 arch/arm/mach-shmobile/board-armadillo800eva.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 6d949f1..75de26c 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -1040,9 +1040,9 @@ static struct asoc_simple_card_info fsi2_hdmi_info = {
 	.card		= "FSI2B-HDMI",
 	.codec		= "sh-mobile-hdmi",
 	.platform	= "sh_fsi2",
+	.daifmt		= SND_SOC_DAIFMT_CBS_CFS,
 	.cpu_dai = {
 		.name	= "fsib-dai",
-		.fmt	= SND_SOC_DAIFMT_CBS_CFS,
 	},
 	.codec_dai = {
 		.name = "sh_mobile_hdmi-hifi",
-- 
1.8.0

[PATCH 2/3] ASoC: sh: fsi: Fix clock inversion

[Lars-Peter Clausen]

According to the sh7724 hardware user manual (Rev.2.00 Jan 2013) page 1851
to 1856 the FSI bit-clock is inverted to the bit-clock as specified by the
I2S standard. This means the bit clock inversion bit should be set for a
normal I2S clock and should not be set for an inverted I2S clock.

Similarly when operating in left-justified mode both the frame-clock and the
bit-clock need to be inverted to be standards compliant.

This means also that the extra clock inversion setting in the
armadillo800eva machine driver for CPU component should now be removed.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
I don't have the hardware but I'd like to get rid of the extra
SND_SOC_DAIFMT_IB_NF in simple-card platform data, so we can remove the fmt
field. Kuninori can you check if this works?
---
 arch/arm/mach-shmobile/board-armadillo800eva.c | 1 -
 sound/soc/sh/fsi.c                             | 7 +++++++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 75de26c..36aaeb1 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -1015,7 +1015,6 @@ static struct asoc_simple_card_info fsi_wm8978_info = {
 	.platform	= "sh_fsi2",
 	.daifmt		= SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBM_CFM,
 	.cpu_dai = {
-		.fmt	= SND_SOC_DAIFMT_IB_NF,
 		.name	= "fsia-dai",
 	},
 	.codec_dai = {
diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c
index b87b22e..dfb17f6 100644
--- a/sound/soc/sh/fsi.c
+++ b/sound/soc/sh/fsi.c
@@ -1594,6 +1594,12 @@ static int fsi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
 
 static int fsi_set_fmt_dai(struct fsi_priv *fsi, unsigned int fmt)
 {
+	/*
+	 * FSI bit clock is inverted to the I2S specification, so we invert it
+	 * when a non-inverted I2S clock was requested and vice versa.
+	 */
+	 fsi->bit_clk_inv = !fsi->bit_clk_inv;
+
 	switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
 	case SND_SOC_DAIFMT_I2S:
 		fsi->fmt = CR_I2S;
@@ -1602,6 +1608,7 @@ static int fsi_set_fmt_dai(struct fsi_priv *fsi, unsigned int fmt)
 	case SND_SOC_DAIFMT_LEFT_J:
 		fsi->fmt = CR_PCM;
 		fsi->chan_num = 2;
+		fsi->lr_clk_inv = !fsi->lr_clk_inv;
 		break;
 	default:
 		return -EINVAL;
-- 
1.8.0

Re: [PATCH 2/3] ASoC: sh: fsi: Fix clock inversion

[Sergei Shtylyov]

Hello.

On 1/19/2015 12:54 PM, Lars-Peter Clausen wrote:

> According to the sh7724 hardware user manual (Rev.2.00 Jan 2013) page 1851
> to 1856 the FSI bit-clock is inverted to the bit-clock as specified by the
> I2S standard. This means the bit clock inversion bit should be set for a
> normal I2S clock and should not be set for an inverted I2S clock.

> Similarly when operating in left-justified mode both the frame-clock and the
> bit-clock need to be inverted to be standards compliant.

> This means also that the extra clock inversion setting in the
> armadillo800eva machine driver for CPU component should now be removed.

> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>

[...]

> diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c
> index b87b22e..dfb17f6 100644
> --- a/sound/soc/sh/fsi.c
> +++ b/sound/soc/sh/fsi.c
> @@ -1594,6 +1594,12 @@ static int fsi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
>
>   static int fsi_set_fmt_dai(struct fsi_priv *fsi, unsigned int fmt)
>   {
> +	/*
> +	 * FSI bit clock is inverted to the I2S specification, so we invert it
> +	 * when a non-inverted I2S clock was requested and vice versa.
> +	 */
> +	 fsi->bit_clk_inv = !fsi->bit_clk_inv;

    One space too many here. :-)

[...]

WBR, Sergei

[PATCH 3/3] ASoC: simple-card: Remove support for setting differing DAI formats

[Lars-Peter Clausen]

Having to set different formats on the CPU side and the CODEC side of a DAI
link is usually indication that something is terribly wrong and in most
cases is a result of a broken driver that implements a set_fmt() callback
which does not follow the specification. In the past this feature has been
used to work around broken drivers, rather than fixing them. We don't really
want to encourage this, so remove support for setting different formats on
both ends of the link.

Along the way switch to static DAI format setup by setting the the dai_fmt
field of the snd_soc_dai_link rather than calling snd_soc_dai_fmt().

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
 include/sound/simple_card.h     |  1 -
 sound/soc/generic/simple-card.c | 29 +++++++----------------------
 2 files changed, 7 insertions(+), 23 deletions(-)

diff --git a/include/sound/simple_card.h b/include/sound/simple_card.h
index 1255ddb..b9b4f28 100644
--- a/include/sound/simple_card.h
+++ b/include/sound/simple_card.h
@@ -16,7 +16,6 @@
 
 struct asoc_simple_dai {
 	const char *name;
-	unsigned int fmt;
 	unsigned int sysclk;
 	int slots;
 	int slot_width;
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index f7c6734..d90a22e 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -125,14 +125,6 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai *dai,
 {
 	int ret;
 
-	if (set->fmt) {
-		ret = snd_soc_dai_set_fmt(dai, set->fmt);
-		if (ret && ret != -ENOTSUPP) {
-			dev_err(dai->dev, "simple-card: set_fmt error\n");
-			goto err;
-		}
-	}
-
 	if (set->sysclk) {
 		ret = snd_soc_dai_set_sysclk(dai, 0, set->sysclk, 0);
 		if (ret && ret != -ENOTSUPP) {
@@ -269,12 +261,10 @@ static int asoc_simple_card_parse_daifmt(struct device_node *node,
 					 struct device_node *codec,
 					 char *prefix, int idx)
 {
+	struct snd_soc_dai_link *dai_link = simple_priv_to_link(priv, idx);
 	struct device *dev = simple_priv_to_dev(priv);
 	struct device_node *bitclkmaster = NULL;
 	struct device_node *framemaster = NULL;
-	struct simple_dai_props *dai_props = simple_priv_to_props(priv, idx);
-	struct asoc_simple_dai *cpu_dai = &dai_props->cpu_dai;
-	struct asoc_simple_dai *codec_dai = &dai_props->codec_dai;
 	unsigned int daifmt;
 
 	daifmt = snd_soc_of_parse_daifmt(node, prefix,
@@ -289,8 +279,7 @@ static int asoc_simple_card_parse_daifmt(struct device_node *node,
 		 */
 		dev_dbg(dev, "Revert to legacy daifmt parsing\n");
 
-		cpu_dai->fmt = codec_dai->fmt -			snd_soc_of_parse_daifmt(codec, NULL, NULL, NULL) |
+		daifmt = snd_soc_of_parse_daifmt(codec, NULL, NULL, NULL) |
 			(daifmt & ~SND_SOC_DAIFMT_CLOCK_MASK);
 	} else {
 		if (codec = bitclkmaster)
@@ -299,11 +288,10 @@ static int asoc_simple_card_parse_daifmt(struct device_node *node,
 		else
 			daifmt |= (codec = framemaster) ?
 				SND_SOC_DAIFMT_CBS_CFM : SND_SOC_DAIFMT_CBS_CFS;
-
-		cpu_dai->fmt	= daifmt;
-		codec_dai->fmt	= daifmt;
 	}
 
+	dai_link->dai_fmt = daifmt;
+
 	of_node_put(bitclkmaster);
 	of_node_put(framemaster);
 
@@ -379,13 +367,11 @@ static int asoc_simple_card_dai_link_of(struct device_node *node,
 	dai_link->init = asoc_simple_card_dai_init;
 
 	dev_dbg(dev, "\tname : %s\n", dai_link->stream_name);
-	dev_dbg(dev, "\tcpu : %s / %04x / %d\n",
+	dev_dbg(dev, "\tcpu : %s / %d\n",
 		dai_link->cpu_dai_name,
-		dai_props->cpu_dai.fmt,
 		dai_props->cpu_dai.sysclk);
-	dev_dbg(dev, "\tcodec : %s / %04x / %d\n",
+	dev_dbg(dev, "\tcodec : %s / %d\n",
 		dai_link->codec_dai_name,
-		dai_props->codec_dai.fmt,
 		dai_props->codec_dai.sysclk);
 
 	/*
@@ -572,14 +558,13 @@ static int asoc_simple_card_probe(struct platform_device *pdev)
 		dai_link->codec_name	= cinfo->codec;
 		dai_link->cpu_dai_name	= cinfo->cpu_dai.name;
 		dai_link->codec_dai_name = cinfo->codec_dai.name;
+		dai_link->dai_fmt	= cinfo->daifmt;
 		dai_link->init		= asoc_simple_card_dai_init;
 		memcpy(&priv->dai_props->cpu_dai, &cinfo->cpu_dai,
 					sizeof(priv->dai_props->cpu_dai));
 		memcpy(&priv->dai_props->codec_dai, &cinfo->codec_dai,
 					sizeof(priv->dai_props->codec_dai));
 
-		priv->dai_props->cpu_dai.fmt	|= cinfo->daifmt;
-		priv->dai_props->codec_dai.fmt	|= cinfo->daifmt;
 	}
 
 	snd_soc_card_set_drvdata(&priv->snd_card, priv);
-- 
1.8.0

Re: [PATCH 3/3] ASoC: simple-card: Remove support for setting differing DAI formats

[Kuninori Morimoto]

Hi Lars

> Having to set different formats on the CPU side and the CODEC side of a DAI
> link is usually indication that something is terribly wrong and in most
> cases is a result of a broken driver that implements a set_fmt() callback
> which does not follow the specification. In the past this feature has been
> used to work around broken drivers, rather than fixing them. We don't really
> want to encourage this, so remove support for setting different formats on
> both ends of the link.
> 
> Along the way switch to static DAI format setup by setting the the dai_fmt
> field of the snd_soc_dai_link rather than calling snd_soc_dai_fmt().
> 
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> ---
(snip)
> +	dai_link->dai_fmt = daifmt;
> +
>  	of_node_put(bitclkmaster);
>  	of_node_put(framemaster);
>  
> @@ -379,13 +367,11 @@ static int asoc_simple_card_dai_link_of(struct device_node *node,
>  	dai_link->init = asoc_simple_card_dai_init;
>  
>  	dev_dbg(dev, "\tname : %s\n", dai_link->stream_name);
> -	dev_dbg(dev, "\tcpu : %s / %04x / %d\n",
> +	dev_dbg(dev, "\tcpu : %s / %d\n",
>  		dai_link->cpu_dai_name,
> -		dai_props->cpu_dai.fmt,
>  		dai_props->cpu_dai.sysclk);
> -	dev_dbg(dev, "\tcodec : %s / %04x / %d\n",
> +	dev_dbg(dev, "\tcodec : %s / %d\n",
>  		dai_link->codec_dai_name,
> -		dai_props->codec_dai.fmt,
>  		dai_props->codec_dai.sysclk);

Can you please indicate dai_fmt here anyway ?
I don't care "how to" or "where", but format information is useful for debugging

Best regards
---
Kuninori Morimoto

[PATCH 2/3] ARM: shmobile: mackerel: fixup usb module order

[Simon Horman]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

renesas_usbhs driver can play role as both Host and Gadget.
In case of Gadget, it requires not only renesas_usbhs
but also usb gadget module (like g_ether).
So, renesas_usbhs driver calls usb_add_gadget_udc() on probe time.

Because of this behavior,
Host port plays also Gadget role if kernel has both Host/Gadget support.

In mackerel case, from 0ada2da51800a4914887a9bcf22d563be80e50be
(ARM: mach-shmobile: mackerel: use renesas_usbhs instead of r8a66597_hcd)
usb0 plays Gadget role, and usb1 plays Host role,
and current mackerel board probes as usb1 -> usb0.
Thus, 1st installed usb gadget module (like g_ether) will be
assigned to usb1 (= usb Host port), and 2nd module to usb0 (= usb Gadget port).
It is very confusable for user.
This patch fixup usb modes probing order as usb0 -> usb1.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 7ea2b31..c129542 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -695,6 +695,7 @@ static struct platform_device usbhs0_device = {
  *  - J30 "open"
  *  - modify usbhs1_get_id() USBHS_HOST -> USBHS_GADGET
  *  - add .get_vbus = usbhs_get_vbus in usbhs1_private
+ *  - check usbhs0_device(pio)/usbhs1_device(irq) order in mackerel_devices.
  */
 #define IRQ8 evt2irq(0x0300)
 #define USB_PHY_MODE		(1 << 4)
@@ -1325,8 +1326,8 @@ static struct platform_device *mackerel_devices[] __initdata = {
 	&nor_flash_device,
 	&smc911x_device,
 	&lcdc_device,
-	&usbhs1_device,
 	&usbhs0_device,
+	&usbhs1_device,
 	&leds_device,
 	&fsi_device,
 	&fsi_ak4643_device,
-- 
1.7.10.4

[PATCH 3/3] ARM: shmobile: armadillo800eva: enable rw rootfs mount

[Simon Horman]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

armadillo800eva default boot loader is "hermit",
and it's tag->u.core.flags has flag when kernel boots.
Because of this, ${LINUX}/arch/arm/kernel/setup.c :: parse_tag_core()
didn't remove MS_RDONLY flag from root_mountflags.
Thus, the rootfs is mounted as "readonly".
This patch adds "rw" kernel parameter,
and enable read/write mounts for rootfs

Cc: Masahiro Nakai <nakai@atmark-techno.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 7d87184..90610c7 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -33,7 +33,7 @@ CONFIG_AEABI=y
 CONFIG_FORCE_MAX_ZONEORDER\x13
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize@96,wsize@96"
+CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize@96,wsize@96 rw"
 CONFIG_CMDLINE_FORCE=y
 CONFIG_KEXEC=y
 CONFIG_VFP=y
-- 
1.7.10.4

[PATCH 3/3] ARM: shmobile: armadillo800eva: enable NEON on defconfig

[Kuninori Morimoto]

The application / library will be stopped by illegal instruction
on current Armaddilo800eva board,
since defconfig doesn't have CONFIG_NEON.
This patch enabled it.
Special thanks to Ishiyama-san

Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 arch/arm/configs/armadillo800eva_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index dd1592b..a452f65 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -42,6 +42,7 @@ CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 i
 CONFIG_CMDLINE_FORCE=y
 CONFIG_KEXEC=y
 CONFIG_VFP=y
+CONFIG_NEON=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 # CONFIG_SUSPEND is not set
 CONFIG_NET=y
-- 
1.7.9.5

Re: [PATCH 3/3] ARM: shmobile: armadillo800eva: enable NEON on defconfig

[Simon Horman]

On Thu, Feb 21, 2013 at 08:46:40PM -0800, Kuninori Morimoto wrote:
> The application / library will be stopped by illegal instruction
> on current Armaddilo800eva board,
> since defconfig doesn't have CONFIG_NEON.
> This patch enabled it.
> Special thanks to Ishiyama-san

I assume this relates to using a userspace that makes use of NEON
instructions. As such I am quite happy to accept this change. But
I wonder if it is also relevant to other shmobile defconfigs.
Do any of the shmobile SoCs not support NEON (in a useful way)?

> Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  arch/arm/configs/armadillo800eva_defconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
> index dd1592b..a452f65 100644
> --- a/arch/arm/configs/armadillo800eva_defconfig
> +++ b/arch/arm/configs/armadillo800eva_defconfig
> @@ -42,6 +42,7 @@ CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 i
>  CONFIG_CMDLINE_FORCE=y
>  CONFIG_KEXEC=y
>  CONFIG_VFP=y
> +CONFIG_NEON=y
>  # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>  # CONFIG_SUSPEND is not set
>  CONFIG_NET=y
> -- 
> 1.7.9.5
> 

Re: [PATCH 3/3] ARM: shmobile: armadillo800eva: enable NEON on defconfig

[Kuninori Morimoto]

Hi Simon

> > The application / library will be stopped by illegal instruction
> > on current Armaddilo800eva board,
> > since defconfig doesn't have CONFIG_NEON.
> > This patch enabled it.
> > Special thanks to Ishiyama-san
> 
> I assume this relates to using a userspace that makes use of NEON
> instructions. As such I am quite happy to accept this change. But
> I wonder if it is also relevant to other shmobile defconfigs.
> Do any of the shmobile SoCs not support NEON (in a useful way)?

Thank you.
kzm9g_defconfig seems have NEON support,
but I'm not sure detail of other board.

Anyway, we can enable it on other SoC/board when we need it.

Best regards
---
Kuninori Morimoto

Re: [PATCH 3/3] ARM: shmobile: armadillo800eva: enable NEON on defconfig

[Kiyoshi Ishiyama]

Hi Kunimoto-san, Shimon-san

Acked-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>

BR
Ishi

> The application / library will be stopped by illegal instruction
> on current Armaddilo800eva board,
> since defconfig doesn't have CONFIG_NEON.
> This patch enabled it.
> Special thanks to Ishiyama-san
> 
> Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  arch/arm/configs/armadillo800eva_defconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
> index dd1592b..a452f65 100644
> --- a/arch/arm/configs/armadillo800eva_defconfig
> +++ b/arch/arm/configs/armadillo800eva_defconfig
> @@ -42,6 +42,7 @@ CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 i
>  CONFIG_CMDLINE_FORCE=y
>  CONFIG_KEXEC=y
>  CONFIG_VFP=y
> +CONFIG_NEON=y
>  # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>  # CONFIG_SUSPEND is not set
>  CONFIG_NET=y
> -- 
> 1.7.9.5

-- 
Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>

Re: [PATCH 3/3] ARM: shmobile: armadillo800eva: enable NEON on defconfig

[Simon Horman]

On Mon, Feb 25, 2013 at 09:21:18AM +0900, Kiyoshi Ishiyama wrote:
> Hi Kunimoto-san, Shimon-san
> 
> Acked-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>

Thanks, applied to the defconfig branch of the renesas tree
and thus included in its next branch and queued up for v3.10.

> 
> BR
> Ishi
> 
> > The application / library will be stopped by illegal instruction
> > on current Armaddilo800eva board,
> > since defconfig doesn't have CONFIG_NEON.
> > This patch enabled it.
> > Special thanks to Ishiyama-san
> > 
> > Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
> >  arch/arm/configs/armadillo800eva_defconfig |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
> > index dd1592b..a452f65 100644
> > --- a/arch/arm/configs/armadillo800eva_defconfig
> > +++ b/arch/arm/configs/armadillo800eva_defconfig
> > @@ -42,6 +42,7 @@ CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 i
> >  CONFIG_CMDLINE_FORCE=y
> >  CONFIG_KEXEC=y
> >  CONFIG_VFP=y
> > +CONFIG_NEON=y
> >  # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> >  # CONFIG_SUSPEND is not set
> >  CONFIG_NET=y
> > -- 
> > 1.7.9.5
> 
> -- 
> Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
> 

Re: [GIT PULL] Renesas ARM-based SoC fix for v3.6 #2

[Olof Johansson]

On Wed, Sep 05, 2012 at 10:34:50AM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> please consider the following fixes for the Armadillo800 EVA and
> Mackerel boards from Morimoto-san.
> 
> * "ARM: shmobile: armadillo800eva: fixup: sound card detection order"
>   is a regression fix.
> * "ARM: shmobile: mackerel: fixup usb module order"
>   is a regression fix.
> * "ARM: shmobile: armadillo800eva: enable rw rootfs mount"
>   is a boot-loader compatibility fix.
> 
> All of the changes are aimed at improving the end-user experience.
> 
> Notes:
> 
> * This pull request is based on my previous
>   "[GIT PULL] Renesas ARM-based SoC fix for v3.6" pull request
>   which was recently pulled by Olof. Please let me know
>   if you would like me to handle this a different way.

That's exactly the way to do it. In this case it meant I have two pulls after
each other from the same tree, and I suppose I could replace the older one with
the newer one but that means rebasing so I just pulled it in. Either way, you
just need to send a delta pull request like you did, the rest would be up to
us.

> 
> ----------------------------------------------------------------
> The following changes since commit 497dcf6fc355f0734faf851662b6957386715d24:
> 
>   ARM: shmobile: marzen: fixup smsc911x id for regulator (2012-08-30 14:10:08 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git fixes

Pulled, thanks!


-Olof

Re: [GIT PULL] Renesas ARM-based SoC fix for v3.6 #2

[Simon Horman]

On Tue, Sep 04, 2012 at 09:44:41PM -0700, Olof Johansson wrote:
> On Wed, Sep 05, 2012 at 10:34:50AM +0900, Simon Horman wrote:
> > Hi Olof, Hi Arnd,
> > 
> > please consider the following fixes for the Armadillo800 EVA and
> > Mackerel boards from Morimoto-san.
> > 
> > * "ARM: shmobile: armadillo800eva: fixup: sound card detection order"
> >   is a regression fix.
> > * "ARM: shmobile: mackerel: fixup usb module order"
> >   is a regression fix.
> > * "ARM: shmobile: armadillo800eva: enable rw rootfs mount"
> >   is a boot-loader compatibility fix.
> > 
> > All of the changes are aimed at improving the end-user experience.
> > 
> > Notes:
> > 
> > * This pull request is based on my previous
> >   "[GIT PULL] Renesas ARM-based SoC fix for v3.6" pull request
> >   which was recently pulled by Olof. Please let me know
> >   if you would like me to handle this a different way.
> 
> That's exactly the way to do it. In this case it meant I have two pulls
> after each other from the same tree, and I suppose I could replace the
> older one with the newer one but that means rebasing so I just pulled it
> in. Either way, you just need to send a delta pull request like you did,
> the rest would be up to us.

Thanks, its good to know what to do.

[GIT PULL] Renesas ARM-based SoC fix for v3.6 #3

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following fix for the KZM-A9-GT board for 3.6.

----------------------------------------------------------------
The following changes since commit 28e515878f8896b33c325ff9767cb0237210fb4c:

  ARM: shmobile: armadillo800eva: enable rw rootfs mount (2012-09-03 17:31:34 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git fixes

for you to fetch changes up to a704835d6a7a8254067a1be60d614cd5c0c73e44:

  ARM: shmobile: kzm9g: bugfix: correct mmcif interrupt settings (2012-09-18 11:19:44 +0900)

----------------------------------------------------------------
Tetsuyuki Kobayashi (1):
      ARM: shmobile: kzm9g: bugfix: correct mmcif interrupt settings

 arch/arm/mach-shmobile/board-kzm9g.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH] ARM: shmobile: kzm9g: bugfix: correct mmcif interrupt settings

[Simon Horman]

From: Tetsuyuki Kobayashi <koba@kmckk.co.jp>

Correct interrupt settings of sh_mmc:int and sh_mmc:error in board-kzm9g.c.

Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/mach-shmobile/board-kzm9g.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board-kzm9g.c
index 53b7ea9..3b8a017 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -346,11 +346,11 @@ static struct resource sh_mmcif_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= gic_spi(141),
+		.start	= gic_spi(140),
 		.flags	= IORESOURCE_IRQ,
 	},
 	[2] = {
-		.start	= gic_spi(140),
+		.start	= gic_spi(141),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
-- 
1.7.10.4

Re: [GIT PULL] Renesas ARM-based SoC fix for v3.6 #3

[Olof Johansson]

On Mon, Sep 17, 2012 at 9:46 PM, Simon Horman <horms@verge.net.au> wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following fix for the KZM-A9-GT board for 3.6.
>
> ----------------------------------------------------------------
> The following changes since commit 28e515878f8896b33c325ff9767cb0237210fb4c:
>
>   ARM: shmobile: armadillo800eva: enable rw rootfs mount (2012-09-03 17:31:34 +0900)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git fixes

Pulled, thanks!

-Olof

[PATCH] ARM: shmobile: kzm9g: bugfix: correct mmcif interrupt settings

[Tetsuyuki Kobayshi]

From: Tetsuyuki Kobayashi <koba@kmckk.co.jp>

Correct interrupt settings of sh_mmc:int and sh_mmc:error in board-kzm9g.c.

Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
---
Hello, morimoto-san

I found small bug in interrpt setting of sh_mmc in board-kzm9g.c.
According to SoC document, there are 2 interrupts for sh_mmc and smaller vector id is error. But the setting in board-kzm9g seems wrong.

Actually these 2 interrupts use the same interrupt handler. So this patch only affects the output of /proc/interrpts.

before this patch:
  ...
172:          3          0       GIC  sh_mmc:int
173:       9504          0       GIC  sh_mmc:error
  ...

after this patch:
  ...
172:          3          0       GIC  sh_mmc:error
173:       9454          0       GIC  sh_mmc:int
  ...

Morimoto-san, could you verify this?

 arch/arm/mach-shmobile/board-kzm9g.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board-kzm9g.c
index fd21fb6..87ec4ce 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -346,11 +346,11 @@ static struct resource sh_mmcif_resources[] = {
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
-		.start	= gic_spi(141),
+		.start	= gic_spi(140),
 		.flags	= IORESOURCE_IRQ,
 	},
 	[2] = {
-		.start	= gic_spi(140),
+		.start	= gic_spi(141),
 		.flags	= IORESOURCE_IRQ,
 	},
 };
-- 
1.7.9.5

Re: [PATCH] ARM: shmobile: kzm9g: bugfix: correct mmcif interrupt settings

[Kuninori Morimoto]

Hi Kobayshi-san

> From: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> 
> Correct interrupt settings of sh_mmc:int and sh_mmc:error in board-kzm9g.c.
> 
> Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> ---
> Hello, morimoto-san
> 
> I found small bug in interrpt setting of sh_mmc in board-kzm9g.c.
> According to SoC document, there are 2 interrupts for sh_mmc and smaller vector id is error. But the setting in board-kzm9g seems wrong.
> 
> Actually these 2 interrupts use the same interrupt handler. So this patch only affects the output of /proc/interrpts.
> 
> before this patch:
>   ...
> 172:          3          0       GIC  sh_mmc:int
> 173:       9504          0       GIC  sh_mmc:error
>   ...
> 
> after this patch:
>   ...
> 172:          3          0       GIC  sh_mmc:error
> 173:       9454          0       GIC  sh_mmc:int
>   ...
> 
> Morimoto-san, could you verify this?

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

> 
>  arch/arm/mach-shmobile/board-kzm9g.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board-kzm9g.c
> index fd21fb6..87ec4ce 100644
> --- a/arch/arm/mach-shmobile/board-kzm9g.c
> +++ b/arch/arm/mach-shmobile/board-kzm9g.c
> @@ -346,11 +346,11 @@ static struct resource sh_mmcif_resources[] = {
>  		.flags	= IORESOURCE_MEM,
>  	},
>  	[1] = {
> -		.start	= gic_spi(141),
> +		.start	= gic_spi(140),
>  		.flags	= IORESOURCE_IRQ,
>  	},
>  	[2] = {
> -		.start	= gic_spi(140),
> +		.start	= gic_spi(141),
>  		.flags	= IORESOURCE_IRQ,
>  	},
>  };
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Best regards
---
Kuninori Morimoto

Re: [PATCH] ARM: shmobile: kzm9g: bugfix: correct mmcif interrupt settings

[Simon Horman]

On Thu, Sep 06, 2012 at 05:47:14PM -0700, Kuninori Morimoto wrote:
> 
> Hi Kobayshi-san
> 
> > From: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> > 
> > Correct interrupt settings of sh_mmc:int and sh_mmc:error in board-kzm9g.c.
> > 
> > Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> > ---
> > Hello, morimoto-san
> > 
> > I found small bug in interrpt setting of sh_mmc in board-kzm9g.c.
> > According to SoC document, there are 2 interrupts for sh_mmc and smaller vector id is error. But the setting in board-kzm9g seems wrong.
> > 
> > Actually these 2 interrupts use the same interrupt handler. So this patch only affects the output of /proc/interrpts.
> > 
> > before this patch:
> >   ...
> > 172:          3          0       GIC  sh_mmc:int
> > 173:       9504          0       GIC  sh_mmc:error
> >   ...
> > 
> > after this patch:
> >   ...
> > 172:          3          0       GIC  sh_mmc:error
> > 173:       9454          0       GIC  sh_mmc:int
> >   ...
> > 
> > Morimoto-san, could you verify this?
> 
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Thanks, applied to fixes.
I will try and get this included in 3.6.