Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ARM: S5P: Add platform helpers for camera GPIO configuration
From: Sylwester Nawrocki @ 2011-02-25 13:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1297447665-19492-2-git-send-email-s.nawrocki@samsung.com>


On 02/11/2011 07:07 PM, Sylwester Nawrocki wrote:
> Add functions for the parallel camera GPIO interface
> configuration on S5PV210 and S5PV310 SoCs.
> 

Kukjin, are you OK with general concept of those?
I would probably need to rework the patches after recent
S5PV310 -> EXYNOS4 renaming. And move camera.h 
to arch/arm/plat-samsung/include/plat/?

What's your opinion?

Thanks,
-- 
Sylwester Nawrocki
Samsung Poland R&D Center

^ permalink raw reply

* [PATCH v4 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used by PRUSS UIO driver
From: Hans J. Koch @ 2011-02-25 13:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4D6796D6.5050008@mvista.com>

On Fri, Feb 25, 2011 at 02:47:34PM +0300, Sergei Shtylyov wrote:
> On 24-02-2011 17:06, Pratheesh Gangadhar wrote:
> 
> >This patch defines PRUSS, ECAP clocks, memory and IRQ resources
> >used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO
> 
>    It's OMAP-L138.

^ permalink raw reply

* [PATCH] eukrea-tlv320: fix platform_name
From: Mark Brown @ 2011-02-25 12:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298638066-4049-1-git-send-email-eric@eukrea.com>

On Fri, Feb 25, 2011 at 01:47:46PM +0100, Eric B?nard wrote:
> commit f0fba2ad1b6b53d5360125c41953b7afcd6deff0 included a mistake
> on the name of the platform in the snd_soc_dai_link structure.
> 
> Signed-off-by: Eric B?nard <eric@eukrea.com>

Applied now, thanks.

^ permalink raw reply

* [alsa-devel] [PATCH] eukrea-tlv320: fix platform_name
From: Liam Girdwood @ 2011-02-25 12:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20110225124957.GA12330@opensource.wolfsonmicro.com>

On Fri, 2011-02-25 at 12:49 +0000, Mark Brown wrote:
> On Fri, Feb 25, 2011 at 01:47:46PM +0100, Eric B?nard wrote:
> > commit f0fba2ad1b6b53d5360125c41953b7afcd6deff0 included a mistake
> 
> Always include the subject line of the commit in patches - readers are
> unlikely to have memorised commit IDs.
> 
> The patch itself looks OK but I'll wait for Liam's ack.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Both

Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>

^ permalink raw reply

* [PATCH 1/2] eukrea_mbimxsd25-baseboard: add SD card detect
From: Wolfram Sang @ 2011-02-25 12:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298638155-4128-1-git-send-email-eric@eukrea.com>

On Fri, Feb 25, 2011 at 01:49:14PM +0100, Eric B?nard wrote:
> Signed-off-by: Eric B?nard <eric@eukrea.com>

Please wait with those patches until the final driver modifications are
applied to mmc-next. mx51-issues may cause some changes.

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110225/3fb8c45b/attachment.sig>

^ permalink raw reply

* [PATCH 2/2] mx3/eukrea_mbimxsd-baseboard: add SD card detect support
From: Eric Bénard @ 2011-02-25 12:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298638198-4175-1-git-send-email-eric@eukrea.com>

Signed-off-by: Eric B?nard <eric@eukrea.com>
---
 arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c b/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
index 3f67eb6..2e288b3 100644
--- a/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
+++ b/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
@@ -43,6 +43,7 @@
 #include <mach/ipu.h>
 #include <mach/mx3fb.h>
 #include <mach/audmux.h>
+#include <mach/esdhc.h>
 
 #include "devices-imx35.h"
 #include "devices.h"
@@ -163,11 +164,14 @@ static iomux_v3_cfg_t eukrea_mbimxsd_pads[] = {
 	MX35_PAD_SD1_DATA1__ESDHC1_DAT1,
 	MX35_PAD_SD1_DATA2__ESDHC1_DAT2,
 	MX35_PAD_SD1_DATA3__ESDHC1_DAT3,
+	/* SD1 CD */
+	MX35_PAD_LD18__GPIO3_24,
 };
 
 #define GPIO_LED1	IMX_GPIO_NR(3, 29)
 #define GPIO_SWITCH1	IMX_GPIO_NR(3, 25)
 #define GPIO_LCDPWR	IMX_GPIO_NR(1, 4)
+#define GPIO_SD1CD	IMX_GPIO_NR(3, 24)
 
 static void eukrea_mbimxsd_lcd_power_set(struct plat_lcd_data *pd,
 				   unsigned int power)
@@ -254,6 +258,11 @@ struct imx_ssi_platform_data eukrea_mbimxsd_ssi_pdata __initconst = {
 	.flags = IMX_SSI_SYN | IMX_SSI_NET | IMX_SSI_USE_I2S_SLAVE,
 };
 
+static struct esdhc_platform_data sd1_pdata = {
+	.cd_gpio = GPIO_SD1CD,
+	.wp_gpio = -EINVAL,
+};
+
 /*
  * system init for baseboard usage. Will be called by cpuimx35 init.
  *
@@ -289,7 +298,7 @@ void __init eukrea_mbimxsd35_baseboard_init(void)
 	imx35_add_imx_ssi(0, &eukrea_mbimxsd_ssi_pdata);
 
 	imx35_add_flexcan1(NULL);
-	imx35_add_sdhci_esdhc_imx(0, NULL);
+	imx35_add_sdhci_esdhc_imx(0, &sd1_pdata);
 
 	gpio_request(GPIO_LED1, "LED1");
 	gpio_direction_output(GPIO_LED1, 1);
-- 
1.7.4

^ permalink raw reply related

* [PATCH] eukrea-tlv320: fix platform_name
From: Mark Brown @ 2011-02-25 12:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298638066-4049-1-git-send-email-eric@eukrea.com>

On Fri, Feb 25, 2011 at 01:47:46PM +0100, Eric B?nard wrote:
> commit f0fba2ad1b6b53d5360125c41953b7afcd6deff0 included a mistake

Always include the subject line of the commit in patches - readers are
unlikely to have memorised commit IDs.

The patch itself looks OK but I'll wait for Liam's ack.

^ permalink raw reply

* [PATCH 1/2] mx3/eukrea_mbimxsd-baseboard: fix gpio request
From: Eric Bénard @ 2011-02-25 12:49 UTC (permalink / raw)
  To: linux-arm-kernel

without this patch, we get :
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:99 gpio_ensure_requested+0x4c/0x104()
autorequest GPIO-4
.../...
[<c01bcfb0>] (platform_lcd_set_power+0x34/0x40) from [<c033954c>] (platform_lcd_probe+0xb8/0xd8)

Signed-off-by: Eric B?nard <eric@eukrea.com>
---
 arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c b/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
index 8076147..3f67eb6 100644
--- a/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
+++ b/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
@@ -167,7 +167,7 @@ static iomux_v3_cfg_t eukrea_mbimxsd_pads[] = {
 
 #define GPIO_LED1	IMX_GPIO_NR(3, 29)
 #define GPIO_SWITCH1	IMX_GPIO_NR(3, 25)
-#define GPIO_LCDPWR	(4)
+#define GPIO_LCDPWR	IMX_GPIO_NR(1, 4)
 
 static void eukrea_mbimxsd_lcd_power_set(struct plat_lcd_data *pd,
 				   unsigned int power)
@@ -301,7 +301,6 @@ void __init eukrea_mbimxsd35_baseboard_init(void)
 
 	gpio_request(GPIO_LCDPWR, "LCDPWR");
 	gpio_direction_output(GPIO_LCDPWR, 1);
-	gpio_free(GPIO_LCDPWR);
 
 	i2c_register_board_info(0, eukrea_mbimxsd_i2c_devices,
 				ARRAY_SIZE(eukrea_mbimxsd_i2c_devices));
-- 
1.7.4

^ permalink raw reply related

* [PATCH 2/2] i.MX25:  add sdma clock definitions
From: Eric Bénard @ 2011-02-25 12:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298638155-4128-1-git-send-email-eric@eukrea.com>

Signed-off-by: Eric B?nard <eric@eukrea.com>
---
 arch/arm/mach-imx/clock-imx25.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-imx/clock-imx25.c b/arch/arm/mach-imx/clock-imx25.c
index daa0165..a65838f 100644
--- a/arch/arm/mach-imx/clock-imx25.c
+++ b/arch/arm/mach-imx/clock-imx25.c
@@ -228,6 +228,7 @@ DEFINE_CLOCK(esdhc1_per_clk, 0, CCM_CGCR0,  3, get_rate_esdhc1,	 NULL,
 DEFINE_CLOCK(esdhc2_ahb_clk, 0, CCM_CGCR0, 22, get_rate_esdhc2,	 NULL, NULL);
 DEFINE_CLOCK(esdhc2_per_clk, 0, CCM_CGCR0,  4, get_rate_esdhc2,	 NULL,
 		&esdhc2_ahb_clk);
+DEFINE_CLOCK(sdma_ahb_clk, 0, CCM_CGCR0, 26, NULL,	 NULL, NULL);
 DEFINE_CLOCK(fec_ahb_clk, 0, CCM_CGCR0, 23, NULL,	 NULL, NULL);
 DEFINE_CLOCK(lcdc_ahb_clk, 0, CCM_CGCR0, 24, NULL,	 NULL, NULL);
 DEFINE_CLOCK(lcdc_per_clk, 0, CCM_CGCR0,  7, NULL,	 NULL, &lcdc_ahb_clk);
@@ -253,6 +254,7 @@ DEFINE_CLOCK(lcdc_clk,	 0, CCM_CGCR1, 29, get_rate_lcdc, NULL, &lcdc_per_clk);
 DEFINE_CLOCK(wdt_clk,    0, CCM_CGCR2, 19, get_rate_ipg, NULL,  NULL);
 DEFINE_CLOCK(ssi1_clk,  0, CCM_CGCR2, 11, get_rate_ssi1, NULL, &ssi1_per_clk);
 DEFINE_CLOCK(ssi2_clk,  1, CCM_CGCR2, 12, get_rate_ssi2, NULL, &ssi2_per_clk);
+DEFINE_CLOCK(sdma_clk, 0, CCM_CGCR2,  6, get_rate_ipg, NULL, &sdma_ahb_clk);
 DEFINE_CLOCK(esdhc1_clk,  0, CCM_CGCR1, 13, get_rate_esdhc1, NULL,
 		&esdhc1_per_clk);
 DEFINE_CLOCK(esdhc2_clk,  1, CCM_CGCR1, 14, get_rate_esdhc2, NULL,
@@ -304,6 +306,7 @@ static struct clk_lookup lookups[] = {
 	_REGISTER_CLOCK(NULL, "audmux", audmux_clk)
 	_REGISTER_CLOCK("flexcan.0", NULL, can1_clk)
 	_REGISTER_CLOCK("flexcan.1", NULL, can2_clk)
+	_REGISTER_CLOCK("imx-sdma", NULL, sdma_clk)
 };
 
 int __init mx25_clocks_init(void)
-- 
1.7.4

^ permalink raw reply related

* [PATCH 1/2] eukrea_mbimxsd25-baseboard: add SD card detect
From: Eric Bénard @ 2011-02-25 12:49 UTC (permalink / raw)
  To: linux-arm-kernel

Signed-off-by: Eric B?nard <eric@eukrea.com>
---
 arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c b/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c
index cb705c2..6269053 100644
--- a/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c
+++ b/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c
@@ -34,6 +34,7 @@
 #include <mach/mx25.h>
 #include <mach/imx-uart.h>
 #include <mach/audmux.h>
+#include <mach/esdhc.h>
 
 #include "devices-imx25.h"
 
@@ -242,6 +243,11 @@ struct imx_ssi_platform_data eukrea_mbimxsd_ssi_pdata __initconst = {
 	.flags = IMX_SSI_SYN | IMX_SSI_NET | IMX_SSI_USE_I2S_SLAVE,
 };
 
+static struct esdhc_platform_data sd1_pdata = {
+	.cd_gpio = GPIO_SD1CD,
+	.wp_gpio = -EINVAL,
+};
+
 /*
  * system init for baseboard usage. Will be called by cpuimx25 init.
  *
@@ -275,7 +281,7 @@ void __init eukrea_mbimxsd25_baseboard_init(void)
 	imx25_add_imx_ssi(0, &eukrea_mbimxsd_ssi_pdata);
 
 	imx25_add_flexcan1(NULL);
-	imx25_add_sdhci_esdhc_imx(0, NULL);
+	imx25_add_sdhci_esdhc_imx(0, &sd1_pdata);
 
 	gpio_request(GPIO_LED1, "LED1");
 	gpio_direction_output(GPIO_LED1, 1);
-- 
1.7.4

^ permalink raw reply related

* [PATCH] eukrea-tlv320: add MBIMXSD51 support
From: Eric Bénard @ 2011-02-25 12:48 UTC (permalink / raw)
  To: linux-arm-kernel

Signed-off-by: Eric B?nard <eric@eukrea.com>
---
 sound/soc/imx/Kconfig         |    3 ++-
 sound/soc/imx/eukrea-tlv320.c |    3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/sound/soc/imx/Kconfig b/sound/soc/imx/Kconfig
index 642270a..9eeb8f0 100644
--- a/sound/soc/imx/Kconfig
+++ b/sound/soc/imx/Kconfig
@@ -44,7 +44,8 @@ config SND_SOC_EUKREA_TLV320
 	tristate "Eukrea TLV320"
 	depends on MACH_EUKREA_MBIMX27_BASEBOARD \
 		|| MACH_EUKREA_MBIMXSD25_BASEBOARD \
-		|| MACH_EUKREA_MBIMXSD35_BASEBOARD
+		|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
+		|| MACH_EUKREA_MBIMXSD51_BASEBOARD
 	select SND_SOC_TLV320AIC23
 	select SND_MXC_SOC_SSI
 	select SND_MXC_SOC_FIQ
diff --git a/sound/soc/imx/eukrea-tlv320.c b/sound/soc/imx/eukrea-tlv320.c
index 1e9bcca..75fb4b8 100644
--- a/sound/soc/imx/eukrea-tlv320.c
+++ b/sound/soc/imx/eukrea-tlv320.c
@@ -98,7 +98,8 @@ static int __init eukrea_tlv320_init(void)
 	int ret;
 
 	if (!machine_is_eukrea_cpuimx27() && !machine_is_eukrea_cpuimx25sd()
-		&& !machine_is_eukrea_cpuimx35sd())
+		&& !machine_is_eukrea_cpuimx35sd()
+		&& !machine_is_eukrea_cpuimx51sd())
 		/* return happy. We might run on a totally different machine */
 		return 0;
 
-- 
1.7.4

^ permalink raw reply related

* [PATCH] eukrea-tlv320: fix platform_name
From: Eric Bénard @ 2011-02-25 12:47 UTC (permalink / raw)
  To: linux-arm-kernel

commit f0fba2ad1b6b53d5360125c41953b7afcd6deff0 included a mistake
on the name of the platform in the snd_soc_dai_link structure.

Signed-off-by: Eric B?nard <eric@eukrea.com>
---
 sound/soc/imx/eukrea-tlv320.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sound/soc/imx/eukrea-tlv320.c b/sound/soc/imx/eukrea-tlv320.c
index e20c9e1..1e9bcca 100644
--- a/sound/soc/imx/eukrea-tlv320.c
+++ b/sound/soc/imx/eukrea-tlv320.c
@@ -79,7 +79,7 @@ static struct snd_soc_dai_link eukrea_tlv320_dai = {
 	.name		= "tlv320aic23",
 	.stream_name	= "TLV320AIC23",
 	.codec_dai_name	= "tlv320aic23-hifi",
-	.platform_name	= "imx-pcm-audio.0",
+	.platform_name	= "imx-fiq-pcm-audio.0",
 	.codec_name	= "tlv320aic23-codec.0-001a",
 	.cpu_dai_name	= "imx-ssi.0",
 	.ops		= &eukrea_tlv320_snd_ops,
-- 
1.7.4

^ permalink raw reply related

* [PATCH] mtd: nand: fix one typo in the comments
From: Artem Bityutskiy @ 2011-02-25 12:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298610378-3105-1-git-send-email-r64343@freescale.com>

On Fri, 2011-02-25 at 13:06 +0800, Jason Liu wrote:
> In the function nand_do_write_oob, the comments
> has one typo, this patch fix it.
> 
> - /* Do not allow reads past end of device */
> + /* Do not allow write past end of device */
> if (unlikely(to >= mtd->size ||
> 	     ops->ooboffs + ops->ooblen >
> 		((mtd->size >> chip->page_shift) -
> 		 (to >> chip->page_shift)) * len)) {
> 	DEBUG(MTD_DEBUG_LEVEL0, "%s: Attempt write beyond "
> 			"end of device\n", __func__);
> 	return -EINVAL;
> }
> 
> Signed-off-by: Jason Liu <r64343@freescale.com>

Oh, please, do not copy the patch into the commit message! It is enough
to say that you fix a typo in a commentary.

But I've amended the commit message and pushed the patch to my
l2-mtd-2.6.git tree, thanks!

-- 
Best Regards,
Artem Bityutskiy (????? ????????)

^ permalink raw reply

* [PATCH] S3C64XX: Tone down SDHCI debugging
From: Ben Dooks @ 2011-02-25 12:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298578262-25391-1-git-send-email-broonie@opensource.wolfsonmicro.com>

On Thu, Feb 24, 2011 at 08:11:02PM +0000, Mark Brown wrote:
> The MMC core calls s3c6400_setup_sdhcp_cfg_card() very frequently, causing
> the log message in there at KERN_INFO to be displayed a lot which is slow
> and overly chatty. Convert the message into a pr_debug() to tone this down.

ok, will look at merging this for next kernel
 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>  arch/arm/mach-s3c64xx/setup-sdhci.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c64xx/setup-sdhci.c b/arch/arm/mach-s3c64xx/setup-sdhci.c
> index 1a94203..f344a22 100644
> --- a/arch/arm/mach-s3c64xx/setup-sdhci.c
> +++ b/arch/arm/mach-s3c64xx/setup-sdhci.c
> @@ -56,7 +56,7 @@ void s3c6400_setup_sdhci_cfg_card(struct platform_device *dev,
>  	else
>  		ctrl3 = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
>  
> -	printk(KERN_INFO "%s: CTRL 2=%08x, 3=%08x\n", __func__, ctrl2, ctrl3);
> +	pr_debug("%s: CTRL 2=%08x, 3=%08x\n", __func__, ctrl2, ctrl3);
>  	writel(ctrl2, r + S3C_SDHCI_CONTROL2);
>  	writel(ctrl3, r + S3C_SDHCI_CONTROL3);
>  }
> -- 
> 1.7.2.3
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.

^ permalink raw reply

* MMC quirks relating to performance/lifetime.
From: Arnd Bergmann @ 2011-02-25 12:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <AANLkTikWKk0kE=Hh4gfA6Mwt+-65TVFnBcOYy_eRuQfw@mail.gmail.com>

On Friday 25 February 2011, Andrei Warkentin wrote:
> Yup. I understand :-).  That's the strategy I'm going to follow. For
> page_size-alignment/splitting I'm looking at the block layer now. Is
> that the right approach or should I still submit a (cleaned up) patch
> to mmc/card/block.c for that performance improvement.

I guess it should live in block/cfq-iosched in the long run, but I don't
know how easy it is to implement it there for test purposes.

It may be easier to prototype it in the mmc code, since you are more
familiar with that already, post that patch together with benchmark
results and then do a new patch for the final solution. We'll need
more benchmarking to figure out if that should be applied for
all nonrotational storage, or if there are cases where it actually
hurts performance to split requests on page boundaries.

If it turns out to be a good idea in general, we won't even need a
sysfs interface for enabling it, just one for reading/writing the
underlying page size.

> The other (Toshiba quirk) is obviously a quirk belonging to mmc/card/block.c.

Makes sense.

	Arnd

^ permalink raw reply

* [PATCH 1/4] msm: scm: Mark inline asm as volatile
From: Will Deacon @ 2011-02-25 11:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298573085-23217-2-git-send-email-sboyd@codeaurora.org>

Hi Stephen,

On Thu, 2011-02-24 at 18:44 +0000, Stephen Boyd wrote:
> We don't want the compiler to remove these asm statements or
> reorder them in any way. Mark them as volatile to be sure.
> 
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>  arch/arm/mach-msm/scm.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-msm/scm.c b/arch/arm/mach-msm/scm.c
> index f4b9bc9..ba57b5a 100644
> --- a/arch/arm/mach-msm/scm.c
> +++ b/arch/arm/mach-msm/scm.c
> @@ -174,7 +174,7 @@ static u32 smc(u32 cmd_addr)
>         register u32 r0 asm("r0") = 1;
>         register u32 r1 asm("r1") = (u32)&context_id;
>         register u32 r2 asm("r2") = cmd_addr;
> -       asm(
> +       asm volatile(
>                 __asmeq("%0", "r0")
>                 __asmeq("%1", "r0")
>                 __asmeq("%2", "r1")
> @@ -271,7 +271,7 @@ u32 scm_get_version(void)
>                 return version;
> 
>         mutex_lock(&scm_lock);
> -       asm(
> +       asm volatile(
>                 __asmeq("%0", "r1")
>                 __asmeq("%1", "r0")
>                 __asmeq("%2", "r1")


These asm blocks all have sensible looking output constraints. Why
do they need to be marked volatile?

Will

^ permalink raw reply

* [PATCH] davinci: da850/omap-l138: Add Carrier Link OK check in Davinci RX Handler
From: Sergei Shtylyov @ 2011-02-25 11:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298627788-32339-1-git-send-email-vinay.hegde@ti.com>

Hello.

On 25-02-2011 12:56, Hegde, Vinay wrote:

    This is not a patch to arch/arm/mach-davinci/, so the summary prefix 
should not be "davinci: da850/omap-l138:" but rather "davinci_emac:" as you're 
patching this driver.

> This patch adds an additional check in the Davinci EMAC RX Handler,
> which tests the __LINK_STATE_NOCARRIER flag along with the
> __LINK_STATE_START flag as part EMAC shutting down procedure.

> This avoids
> WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf8/0x120()
> during rtcwake used to suspend the target for a specified duration.

> Signed-off-by: Hegde, Vinay <vinay.hegde@ti.com>

> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 2a628d1..7018bfe 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -1008,7 +1008,7 @@ static void emac_rx_handler(void *token, int len, int status)
>   	int			ret;
>
>   	/* free and bail if we are shutting down */
> -	if (unlikely(!netif_running(ndev))) {
> +	if (unlikely(!netif_running(ndev) || !netif_carrier_ok(ndev))) {
>   		dev_kfree_skb_any(skb);
>   		return;
>   	}

WBR, Sergei

^ permalink raw reply

* [PATCH v4 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used by PRUSS UIO driver
From: Sergei Shtylyov @ 2011-02-25 11:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298556402-26456-3-git-send-email-pratheesh@ti.com>

On 24-02-2011 17:06, Pratheesh Gangadhar wrote:

> This patch defines PRUSS, ECAP clocks, memory and IRQ resources
> used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO

    It's OMAP-L138.

> driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
> DDR buffer to user space. PRUSS has 8 host event interrupt lines
> mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
> with shared memory can be used to implement IPC between ARM9 and
> PRUSS.

> Signed-off-by: Pratheesh Gangadhar<pratheesh@ti.com>
[...]

> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 11f986b..bd85aa3 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1077,6 +1077,10 @@ static __init void da850_evm_init(void)
>   		pr_warning("da850_evm_init: i2c0 registration failed: %d\n",
>   				ret);
>
> +	ret = da8xx_register_pruss();
> +	if (ret)
> +		pr_warning("da850_evm_init: pruss registration failed: %d\n",
> +				ret);

    Use __func__ to print the function name.

>
>   	ret = da8xx_register_watchdog();
>   	if (ret)

    As I said, please put this into serpate patch.

> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 3443d97..0096d4f 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -238,6 +238,13 @@ static struct clk tptc2_clk = {
>   	.flags		= ALWAYS_ENABLED,
>   };
>
> +static struct clk pruss_clk = {
> +	.name		= "pruss",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC0_DMAX,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +

    This conflicts with previously posted patch.

>   static struct clk uart0_clk = {
>   	.name		= "uart0",
>   	.parent		=&pll0_sysclk2,
> @@ -359,6 +366,30 @@ static struct clk usb20_clk = {
>   	.gpsc		= 1,
>   };
>
> +static struct clk ecap0_clk = {
> +	.name		= "ecap0",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC1_ECAP,
> +	.flags		= DA850_CLK_ASYNC3,
> +	.gpsc		= 1,
> +};
> +
> +static struct clk ecap1_clk = {
> +	.name		= "ecap1",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC1_ECAP,
> +	.flags		= DA850_CLK_ASYNC3,
> +	.gpsc		= 1,
> +};
> +
> +static struct clk ecap2_clk = {
> +	.name		= "ecap2",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC1_ECAP,
> +	.flags		= DA850_CLK_ASYNC3,
> +	.gpsc		= 1,
> +};
> +

    This is worth separate patch too...

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index beda8a4..4ea3d1f 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
>
>   	return platform_device_register(&da8xx_cpuidle_device);
>   }
> +static struct resource pruss_resources[] = {
> +	[0] = {
> +		.start  = DA8XX_PRUSS_BASE,
> +		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
> +		.flags  = IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start  = DA8XX_L3RAM_BASE,
> +		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
> +		.flags  = IORESOURCE_MEM,
> +	},
> +	[2] = {
> +		.start  = 0,
> +		.end    = SZ_256K - 1,

    Huh? I don't see where it's filled...

> +		.flags  = IORESOURCE_MEM,
> +	},
> +
[...]
> +int __init da8xx_register_pruss()
> +{
> +	return platform_device_register(&pruss_device);
> +}
> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index cfcb223..3ed6ee0 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -60,6 +60,7 @@ extern unsigned int da850_max_speed;
>   #define DA8XX_PLL0_BASE		0x01c11000
>   #define DA8XX_TIMER64P0_BASE	0x01c20000
>   #define DA8XX_TIMER64P1_BASE	0x01c21000
> +#define DA8XX_PRUSS_BASE	0x01c30000
>   #define DA8XX_GPIO_BASE		0x01e26000
>   #define DA8XX_PSC1_BASE		0x01e27000
>   #define DA8XX_LCD_CNTRL_BASE	0x01e13000
> @@ -68,6 +69,7 @@ extern unsigned int da850_max_speed;
>   #define DA8XX_AEMIF_CS2_BASE	0x60000000
>   #define DA8XX_AEMIF_CS3_BASE	0x62000000
>   #define DA8XX_AEMIF_CTL_BASE	0x68000000
> +#define DA8XX_L3RAM_BASE	0x80000000

    There were already patches defining macros for these base addresses...

WBR, Sergei

^ permalink raw reply

* [TRIVIAL/PATCH] ARM: hw_breakpoint: Fix newlines in WARN messages
From: Will Deacon @ 2011-02-25 11:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <19815.20063.647326.437650@ipc1.ka-ro>

On Fri, 2011-02-25 at 06:38 +0000, Lothar Wa?mann wrote:
> Hi,
> 
Hello,

> Stephen Boyd writes:
> > These warnings are missing newlines and spaces causing confusing
> > looking output when they trigger.
> >
> > Cc: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> > ---
> >  arch/arm/kernel/hw_breakpoint.c |   13 +++++++------
> >  1 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
> > index d600bd3..5aab00e 100644
> > --- a/arch/arm/kernel/hw_breakpoint.c
> > +++ b/arch/arm/kernel/hw_breakpoint.c
> > @@ -238,8 +238,8 @@ static int enable_monitor_mode(void)
> >       ARM_DBG_READ(c1, 0, dscr);
> > 
> >       /* Ensure that halting mode is disabled. */
> > -     if (WARN_ONCE(dscr & ARM_DSCR_HDBGEN, "halting debug mode enabled."
> > -                             "Unable to access hardware resources.")) {
> > +     if (WARN_ONCE(dscr & ARM_DSCR_HDBGEN, "halting debug mode enabled. "
> > +                             "Unable to access hardware resources.\n")) {
> >
> I'd prefer the message text not to be line wrapped, even if it
> violates the general line length rule, because that makes it easier to
> grep for the message in the source code.


Ok, that's understandable. Moving the text onto its own line will limit
the damage to the line length too. Stephen - are you happy to make these
changes as part of your previous patch?

Thanks,

Will

^ permalink raw reply

* [PATCH v4] dmaengine: mxs-dma: add dma support for i.MX23/28
From: Shawn Guo @ 2011-02-25 11:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20110225105530.GA2178@pengutronix.de>

On Fri, Feb 25, 2011 at 11:55:30AM +0100, Wolfram Sang wrote:
> Hi Shawn,
> 
Hi Wolfram,

> On Fri, Feb 25, 2011 at 03:34:19PM +0800, Shawn Guo wrote:
> > This patch adds dma support for Freescale MXS-based SoC i.MX23/28,
> > including apbh-dma and apbx-dma.
> > 
> > * apbh-dma and apbx-dma are supported in the driver as two mxs-dma
> >   instances.
> > 
> > * apbh-dma is different between mx23 and mx28, hardware version
> >   register is used to differentiate.
> > 
> > * mxs-dma supports pio function besides data transfer.  The driver
> >   uses dma_data_direction DMA_NONE to identify the pio mode, and
> >   steals sgl and sg_len to get pio words and numbers from clients.
> > 
> > * mxs dmaengine has some very specific features, like sense function
> >   and the special NAND support (nand_lock, nand_wait4ready).  These
> >   are too specific to implemented in generic dmaengine driver.
> > 
> > * The driver refers to imx-sdma and only a single descriptor is
> >   statically assigned to each channel.
> > 
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> 
> What are (roughly) the changes since last version?
> 
Sorry, I did not give the change log.  Basically, it addressed the
comments below from Vinod and Lothar on v3.

======
> +#define HW_APBHX_CTRL0                         0x000
> +#define  BM_APBH_CTRL0_APB_BURST8_EN           (1 << 29)
> +#define  BM_APBH_CTRL0_APB_BURST_EN            (1 << 28)
> +#define  BP_APBH_CTRL0_CLKGATE_CHANNEL         (8)
> +#define  BP_APBH_CTRL0_RESET_CHANNEL           (16)
can you please use consistent spacing here...

> +static irqreturn_t mxs_dma_int_handler(int irq, void *dev_id)
> +{
> +       struct mxs_dma_engine *mxs_dma = dev_id;
> +       u32 stat1, stat2;
> +
> +       /* completion status */
> +       stat1 = readl(mxs_dma->base + HW_APBHX_CTRL1);
> +       stat1 &= 0xffff;
Magic number?

> +       writel(stat1, mxs_dma->base + HW_APBHX_CTRL1 + MXS_CLR_ADDR);
> +
> +       /* error status */
> +       stat2 = readl(mxs_dma->base + HW_APBHX_CTRL2);
> +       writel(stat2, mxs_dma->base + HW_APBHX_CTRL2 + MXS_CLR_ADDR);
> +
> +       /*
> +        * When both completion and error of termination bits set at the
> +        * same time, we do not take it as an error.  IOW, it only becomes
> +        * an error we need to handler here in case of ether it's an bus
> +        * error or a termination error with no completion.
> +        */
> +       stat2 = ((stat2 >> 16) & stat2) |          /* bus error */
> +               (~(stat2 >> 16) & stat2 & ~stat1); /* termination with no completion */
> +
> +       /* combine error and completion status for checking */
> +       stat1 = (stat2 << 16) | stat1;
would it be possible for you to avoid these magic number, will help you
when you add more controllers...

> > > +#define HW_APBHX_CTRL0                         0x000
> > > +#define  BM_APBH_CTRL0_APB_BURST8_EN           (1 << 29)
> > > +#define  BM_APBH_CTRL0_APB_BURST_EN            (1 << 28)
> > > +#define  BP_APBH_CTRL0_CLKGATE_CHANNEL         (8)
> > > +#define  BP_APBH_CTRL0_RESET_CHANNEL           (16)
>
There is no need to enclose bare number in macro definitions in
parenthesis.
...
=======

-- 
Regards,
Shawn

^ permalink raw reply

* MMC quirks relating to performance/lifetime.
From: Andrei Warkentin @ 2011-02-25 11:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201102241024.01437.arnd@arndb.de>

On Thu, Feb 24, 2011 at 3:24 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> Unlike the sysfs interface, the code does not need to be future-proof,
> it can always be changed if we feel the code becomes more maintainable
> by doing it another way.
>
> The approach that I'd like to see here is:
>
> * Start out with an ad-hoc patch for a quirk (like the one you already
> ?have).
> * Add a boolean variable to enable it per card.
> * Get performance data for this quirk to show that it's useful in
> ?real-world workloads for some cards but counterproductive for others
> * Get the patch into the mmc tree.
> * Repeat for the next quirk
> * When the code becomes overly complicated after adding all the quirks,
> ?decide on a good strategy to move the code around, and do a new patch.
>

Yup. I understand :-).  That's the strategy I'm going to follow. For
page_size-alignment/splitting I'm looking at the block layer now. Is
that the right approach or should I still submit a (cleaned up) patch
to mmc/card/block.c for that performance improvement? The other
(Toshiba quirk) is obviously a quirk belonging to mmc/card/block.c.

> I understand that you are convinced that you will need the indirect function
> calls in the end. That is fine, just don't add them before they are
> actually needed -- that would only make it harder for you to get the first
> patch included.
>
> Note that the situation is very different for user interfaces such as sysfs:
> You need to plan ahead because once the interface is merged upstream, it
> can never be changed. When you submit a patch that introduces a new sysfs
> interface, it has to be documented, and you have to convince the reviewers
> that it is sufficient to cover all the cases it is designed for, while
> at the same time it is the most simple way to achieve this.


Ok, thanks a lot for the explanation, I hadn't thought of it that way
(and should have).

A

^ permalink raw reply

* [PATCH v4] dmaengine: mxs-dma: add dma support for i.MX23/28
From: Wolfram Sang @ 2011-02-25 10:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298619259-14344-1-git-send-email-shawn.guo@freescale.com>

Hi Shawn,

On Fri, Feb 25, 2011 at 03:34:19PM +0800, Shawn Guo wrote:
> This patch adds dma support for Freescale MXS-based SoC i.MX23/28,
> including apbh-dma and apbx-dma.
> 
> * apbh-dma and apbx-dma are supported in the driver as two mxs-dma
>   instances.
> 
> * apbh-dma is different between mx23 and mx28, hardware version
>   register is used to differentiate.
> 
> * mxs-dma supports pio function besides data transfer.  The driver
>   uses dma_data_direction DMA_NONE to identify the pio mode, and
>   steals sgl and sg_len to get pio words and numbers from clients.
> 
> * mxs dmaengine has some very specific features, like sense function
>   and the special NAND support (nand_lock, nand_wait4ready).  These
>   are too specific to implemented in generic dmaengine driver.
> 
> * The driver refers to imx-sdma and only a single descriptor is
>   statically assigned to each channel.
> 
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---

What are (roughly) the changes since last version?

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110225/7415eff3/attachment.sig>

^ permalink raw reply

* [PATCH 1/3] pxa: Enable pxa-pcm-audio on pxa210/pxa25x platform
From: Dmitry Eremin-Solenikov @ 2011-02-25 10:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298417351-24727-1-git-send-email-dbaryshkov@gmail.com>

Eric, will it be possible to get at least this patch in the kernel?

Otherwise all ASoC-based audio on pxa25x isn't working.

On 2/23/11, Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> wrote:
> pxa25x platforms were left out of major ASoC Update patch.
> Since f0fba2ad1b a registration of pxa-pcm-audio device is required for
> ASoC to function on pxa platforms. Register one also for pxa210/pxa25x.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> ---
>  arch/arm/mach-pxa/pxa25x.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
> index fbc5b77..b166b1d 100644
> --- a/arch/arm/mach-pxa/pxa25x.c
> +++ b/arch/arm/mach-pxa/pxa25x.c
> @@ -347,6 +347,7 @@ static struct platform_device *pxa25x_devices[]
> __initdata = {
>  	&pxa25x_device_assp,
>  	&pxa25x_device_pwm0,
>  	&pxa25x_device_pwm1,
> +	&pxa_device_asoc_platform,
>  };
>
>  static struct sys_device pxa25x_sysdev[] = {
> --
> 1.7.2.3
>
>


-- 
With best wishes
Dmitry

^ permalink raw reply

* [PATCH V4 0/6] pxa3xx_nand update series set version 4
From: Artem Bityutskiy @ 2011-02-25 10:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298019428-7809-1-git-send-email-leiwen@marvell.com>

On Fri, 2011-02-18 at 16:57 +0800, Lei Wen wrote:
> Change from previous version:
> rework the patch set accroding to Eric's suggestion.
> Move the recode judgement to the after command execution.
> 
> Lei Wen (6):
>   pxa3xx_nand: make scan procedure more clear
>   pxa3xx_nand: rework irq logic
>   pxa3xx_nand: discard wait_for_event,write_cmd,__readid function
>   pxa3xx_nand: unify prepare command
>   pxa3xx_nand: mtd scan id process could be defined by driver itself
>   pxa3xx_nand: clean the keep configure code

Hi, could you please make checkpatch.pl happy and re-send the patches?

There are many issues. OK, some are fine, do not try to fix them, e.g.:

WARNING: line over 80 characters
#127: FILE: drivers/mtd/nand/pxa3xx_nand.c:221:
+{ "512MiB 16-bit", 0xcc2c,  64, 2048, 16, 16, 4096, &default_cmdset, &timing[2] },

but some are clearly stylistic errors:

ERROR: else should follow close brace '}'
#249: FILE: drivers/mtd/nand/pxa3xx_nand.c:539:
+                }
+                else {

etc.

Thanks!

-- 
Best Regards,
Artem Bityutskiy (????? ????????)

^ permalink raw reply

* [PATCH] ARM: hw_breakpoint: ensure debug logic is powered up on v7 cores
From: Will Deacon @ 2011-02-25 10:13 UTC (permalink / raw)
  To: linux-arm-kernel

ARMv7 allows the debug core logic to be powered down and provides the
DBGPRSR register so that software can power-up and check the status of
the logic.

This patch ensures that the debug logic is powered up on ARMv7 cores
before we attempt to access the extended debug registers.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/kernel/hw_breakpoint.c |   26 +++++++++++++++++++++++---
 1 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index d600bd3..44b84fe 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -836,9 +836,11 @@ static int hw_breakpoint_pending(unsigned long addr, unsigned int fsr,
 /*
  * One-time initialisation.
  */
-static void reset_ctrl_regs(void *unused)
+static void reset_ctrl_regs(void *info)
 {
-	int i;
+	int i, cpu = smp_processor_id();
+	u32 dbg_power;
+	cpumask_t *cpumask = info;
 
 	/*
 	 * v7 debug contains save and restore registers so that debug state
@@ -850,6 +852,17 @@ static void reset_ctrl_regs(void *unused)
 	 */
 	if (debug_arch >= ARM_DEBUG_ARCH_V7_ECP14) {
 		/*
+		 * Ensure sticky power-down is clear (i.e. debug logic is
+		 * powered up).
+		 */
+		asm volatile("mrc p14, 0, %0, c1, c5, 4" : "=r" (dbg_power));
+		if ((dbg_power & 0x1) == 0) {
+			pr_warning("CPU %d debug is powered down!\n", cpu);
+			cpumask_or(cpumask, cpumask, cpumask_of(cpu));
+			return;
+		}
+
+		/*
 		 * Unconditionally clear the lock by writing a value
 		 * other than 0xC5ACCE55 to the access register.
 		 */
@@ -887,6 +900,7 @@ static struct notifier_block __cpuinitdata dbg_reset_nb = {
 static int __init arch_hw_breakpoint_init(void)
 {
 	u32 dscr;
+	cpumask_t cpumask = { CPU_BITS_NONE };
 
 	debug_arch = get_debug_arch();
 
@@ -911,7 +925,13 @@ static int __init arch_hw_breakpoint_init(void)
 	 * Reset the breakpoint resources. We assume that a halting
 	 * debugger will leave the world in a nice state for us.
 	 */
-	on_each_cpu(reset_ctrl_regs, NULL, 1);
+	on_each_cpu(reset_ctrl_regs, &cpumask, 1);
+	if (!cpumask_empty(&cpumask)) {
+		core_num_brps = 0;
+		core_num_reserved_brps = 0;
+		core_num_wrps = 0;
+		return 0;
+	}
 
 	ARM_DBG_READ(c1, 0, dscr);
 	if (dscr & ARM_DSCR_HDBGEN) {
-- 
1.7.0.4

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox