Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH RFC] i2c: omap: Fix the revision register read
From: Shubhrajyoti @ 2012-10-31 10:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121031101201.GB10094@arwen.pp.htv.fi>

On Wednesday 31 October 2012 03:42 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 31, 2012 at 02:29:19PM +0530, Shubhrajyoti D wrote:
>> The revision register on OMAP4 is a 16-bit lo and a 16-bit
>> hi. Currently the driver reads only the lower 8-bits.
>> Fix the same by preventing the truncating of the rev register
>> for OMAP4.
> very good, but you need to test this with OMAP2/3/4 (5 ??). How was this
> tested ?
>
>> Also use the scheme bit ie bit-14 of the hi register to know if it
>> is OMAP_I2C_IP_VERSION_2.
>>
>> On platforms previous to OMAP4 the offset 0x04 is IE register whose
>> bit-14 reset value is 0, the code uses the same to its advantage.
>>
>> The dev->regs is populated after reading the rev_hi. A NULL check
>> has been added in the resume handler to prevent the access before
>> the setting of the regs.
> this could get some rephrasing, I guess. At least to me it's difficult
> to understand what you mean :-s
>
>> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
>> ---
>> todo: some of the flag checks can be removed in favour of revision check.
>>
>>  drivers/i2c/busses/i2c-omap.c |   35 +++++++++++++++++++++++++----------
>>  1 files changed, 25 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
>> index db31eae..651a7f7 100644
>> --- a/drivers/i2c/busses/i2c-omap.c
>> +++ b/drivers/i2c/busses/i2c-omap.c
>> @@ -51,7 +51,8 @@
>>  /* I2C controller revisions present on specific hardware */
>>  #define OMAP_I2C_REV_ON_2430		0x36
>>  #define OMAP_I2C_REV_ON_3430_3530	0x3C
>> -#define OMAP_I2C_REV_ON_3630_4430	0x40
>> +#define OMAP_I2C_REV_ON_3630		0x40
>> +#define OMAP_I2C_REV_ON_4430_PLUS	0x5040
> I would rather see a proper decoding of the revision, meaning that you
> would:
>
> For omap2/3:
>
> rev major = rev >> 8;
> rev minor = rev & 0xff;
you mean

rev major = rev >> 4;
rev minor = rev & 0xf;

thats doable too. However that currently that is read together currently.

>
> For OMAP4/5:
>
> well, that's a lot more complex, but you have that data ;-)
>
>>  /* timeout waiting for the controller to respond */
>>  #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
>> @@ -202,7 +203,7 @@ struct omap_i2c_dev {
>>  						 * fifo_size==0 implies no fifo
>>  						 * if set, should be trsh+1
>>  						 */
>> -	u8			rev;
>> +	u16			rev;
> IMHO this should be u32, so you don't need rev_lo and rev_hi below.
>
>>  	unsigned		b_hw:1;		/* bad h/w fixes */
>>  	unsigned		receiver:1;	/* true when we're in receiver mode */
>>  	u16			iestate;	/* Saved interrupt register */
>> @@ -490,7 +491,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
>>  
>>  	omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
>>  
>> -	if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
>> +	if (dev->rev < OMAP_I2C_REV_ON_3630)
>>  		dev->b_hw = 1; /* Enable hardware fixes */
>>  
>>  	/* calculate wakeup latency constraint for MPU */
>> @@ -1064,6 +1065,8 @@ omap_i2c_probe(struct platform_device *pdev)
>>  	const struct of_device_id *match;
>>  	int irq;
>>  	int r;
>> +	u16 rev_lo;
>> +	u16 rev_hi;
>>  
>>  	/* NOTE: driver uses the static register mapping */
>>  	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> @@ -1117,11 +1120,6 @@ omap_i2c_probe(struct platform_device *pdev)
>>  
>>  	dev->reg_shift = (dev->flags >> OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) & 3;
>>  
>> -	if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
>> -		dev->regs = (u8 *)reg_map_ip_v2;
>> -	else
>> -		dev->regs = (u8 *)reg_map_ip_v1;
>> -
>>  	pm_runtime_enable(dev->dev);
>>  	pm_runtime_set_autosuspend_delay(dev->dev, OMAP_I2C_PM_TIMEOUT);
>>  	pm_runtime_use_autosuspend(dev->dev);
>> @@ -1130,7 +1128,21 @@ omap_i2c_probe(struct platform_device *pdev)
>>  	if (IS_ERR_VALUE(r))
>>  		goto err_free_mem;
>>  
>> -	dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>> +	/* Read the Rev hi bit-14 ie scheme this is 1 indicates ver2 or
>> +	* highlander.
> the "scheme" in highlander is a 2 bit value. In order to make this
> future proof, you need to read both bits (31:30).
Good point will fix it.
>
>> +	* On omap3 Offset 4 is IE Reg the bit 14 is XDR_IE which is 0 at reset.
>> +	*/
> please align the * characters.
yes will repost
>
>> +	rev_hi = __raw_readw(dev->base + 0x04);
> you should make omap_i2c_read_reg() work fine for this case too.
 
Just felt it is more readlable this way also I didnt want to use the
reg_shift etc.

which also may get cleaned up sometime.
>
>> +
>> +	if (rev_hi & 0x4000) {/* If scheme 1*/
> you should add a symbolic define for scheme, something like:
>
> switch (OMAP_I2C_SCHEME(rev)) {
> case OMAP_I2C_SCHEME_1:
> 	foo();
> 	break;
> case OMAP_I2C_SCHEME_2:
> 	/* FALLTHROUGH */
> default:
> 	bar();
> }
>
> note that this will also default to highest known scheme if another
> scheme is added. You need to make the driver behave like that to
> decrease amount of rework to support newest OMAPs.
OK.
>
>> +		dev->regs = (u8 *)reg_map_ip_v2;
>> +		dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_HI);
>> +		rev_lo = omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_LO);
>> +		dev_info(dev->dev, "the low rev %x\n", rev_lo);
>> +	} else {
>> +		dev->regs = (u8 *)reg_map_ip_v1;
>> +		dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>> +	}
>>  
>>  	dev->errata = 0;
>>  
>> @@ -1155,7 +1167,7 @@ omap_i2c_probe(struct platform_device *pdev)
>>  
>>  		dev->fifo_size = (dev->fifo_size / 2);
>>  
>> -		if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
>> +		if (dev->rev < OMAP_I2C_REV_ON_3630)
>>  			dev->b_hw = 1; /* Enable hardware fixes */
>>  
>>  		/* calculate wakeup latency constraint for MPU */
>> @@ -1264,6 +1276,9 @@ static int omap_i2c_runtime_resume(struct device *dev)
>>  	struct platform_device *pdev = to_platform_device(dev);
>>  	struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
>>  
>> +	if (!_dev->regs)
>> +		return 0;
> this is wrong, you need to make sure dev->regs is set early enough.

^ permalink raw reply

* AM33XX suspend-resume support (Was RE: pm: add suspend_mem and suspend_standby support)
From: Bedia, Vaibhav @ 2012-10-31 10:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5090FD01.1080709@gmail.com>

(Changed $SUBJECT to reflect the topic being discussed)

On Wed, Oct 31, 2012 at 15:57:13, Daniel Mack wrote:

[...]
> 
> May I ask whether there is anything yet I can test?

I am working on basic suspend-resume patches for AM33XX which builds on top of the
current linux-omap/master. Will be posting it later this week.

Regards,
Vaibhav

^ permalink raw reply

* [PATCH 4/4] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init
From: Paul Walmsley @ 2012-10-31 10:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121031103607.6557.64591.stgit@dusk.lan>

Resolve this kernel boot message:

omap_hwmod: mcpdm: cannot be enabled for reset (3)

The McPDM on OMAP4 can only receive its functional clock from an
off-chip source.  This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C.  This would
introduce a board dependency to the early hwmod code which it was not
designed to handle.  Also, neither the driver for this off-chip clock
provider nor the I2C code is available early in boot when the hwmod
code is attempting to enable and reset IP blocks.  This effectively
makes it impossible to enable and reset this device during hwmod init.

At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source.  (This is true for almost
every IP block on the chip.  As far as I know, McPDM is the only
exception.)  If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state.  Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.

This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag.  This prevents the hwmod
code from touching the device early during boot.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: P?ter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Beno?t Cousson <b-cousson@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..7bddfa5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2125,6 +2125,14 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
 	.name		= "mcpdm",
 	.class		= &omap44xx_mcpdm_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	/*
+	 * It's suspected that the McPDM requires an off-chip main
+	 * functional clock, controlled via I2C.  This IP block is
+	 * currently reset very early during boot, before I2C is
+	 * available, so it doesn't seem that we have any choice in
+	 * the kernel other than to avoid resetting it.
+	 */
+	.flags		= HWMOD_EXT_OPT_MAIN_CLK,
 	.mpu_irqs	= omap44xx_mcpdm_irqs,
 	.sdma_reqs	= omap44xx_mcpdm_sdma_reqs,
 	.main_clk	= "mcpdm_fck",

^ permalink raw reply related

* [PATCH 3/4] ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init
From: Paul Walmsley @ 2012-10-31 10:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121031103607.6557.64591.stgit@dusk.lan>

Add HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
dependent on an off-chip functional clock that is not guaranteed to be
present during initialization.  IP blocks marked with this flag are
left in the INITIALIZED state during kernel init.

This is a workaround for a hardware problem.  It should be possible to
guarantee that at least one clock source will be present and active
for any IP block's main functional clock.  This ensures that the hwmod
code can enable and reset the IP block.  Resetting the IP block during
kernel init prevents any bogus bootloader, ROM code, or previous OS
configuration from affecting the kernel.  Hopefully a clock
multiplexer can be added on future SoCs.

N.B., at some point in the future, it should be possible to query the
clock framework for this type of information.  Then this flag should
no longer be needed.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Beno?t Cousson <b-cousson@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c             |    3 +++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    6 ++++++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f9d8b2a..4529650 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2380,6 +2380,9 @@ static int __init _setup_reset(struct omap_hwmod *oh)
 	if (oh->_state != _HWMOD_STATE_INITIALIZED)
 		return -EINVAL;
 
+	if (oh->flags & HWMOD_EXT_OPT_MAIN_CLK)
+		return -EPERM;
+
 	if (oh->rst_lines_cnt == 0) {
 		r = _enable(oh);
 		if (r) {
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index b3349f7..1db0294 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -443,6 +443,11 @@ struct omap_hwmod_omap4_prcm {
  *     in order to complete the reset. Optional clocks will be disabled
  *     again after the reset.
  * HWMOD_16BIT_REG: Module has 16bit registers
+ * HWMOD_EXT_OPT_MAIN_CLK: The only main functional clock source for
+ *     this IP block comes from an off-chip source and is not always
+ *     enabled.  This prevents the hwmod code from being able to
+ *     enable and reset the IP block early.  XXX Eventually it should
+ *     be possible to query the clock framework for this information.
  */
 #define HWMOD_SWSUP_SIDLE			(1 << 0)
 #define HWMOD_SWSUP_MSTANDBY			(1 << 1)
@@ -453,6 +458,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_NO_IDLEST				(1 << 6)
 #define HWMOD_CONTROL_OPT_CLKS_IN_RESET		(1 << 7)
 #define HWMOD_16BIT_REG				(1 << 8)
+#define HWMOD_EXT_OPT_MAIN_CLK			(1 << 9)
 
 /*
  * omap_hwmod._int_flags definitions

^ permalink raw reply related

* [PATCH 2/4] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
From: Paul Walmsley @ 2012-10-31 10:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121031103607.6557.64591.stgit@dusk.lan>

From: Tero Kristo <t-kristo@ti.com>

When waking up from off-mode, some IP blocks are reset automatically by
hardware. For this reason, software must wait until the reset has
completed before attempting to access the IP block.

This patch fixes for example the bug introduced by commit
6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
to SYSCONFIG register"), in which the MMC IP block is reset during
off-mode entry, but the code expects the module to be already available
during the execution of context restore.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Venkatraman S <svenkatr@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
[paul at pwsan.com: moved softreset wait code into separate function; call
 from top of _enable_sysc() rather than the bottom]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   56 +++++++++++++++++++++++++++++---------
 1 file changed, 42 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b969ab1..f9d8b2a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -422,6 +422,38 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v)
 }
 
 /**
+ * _wait_softreset_complete - wait for an OCP softreset to complete
+ * @oh: struct omap_hwmod * to wait on
+ *
+ * Wait until the IP block represented by @oh reports that its OCP
+ * softreset is complete.  This can be triggered by software (see
+ * _ocp_softreset()) or by hardware upon returning from off-mode (one
+ * example is HSMMC).  Waits for up to MAX_MODULE_SOFTRESET_WAIT
+ * microseconds.  Returns the number of microseconds waited.
+ */
+static int _wait_softreset_complete(struct omap_hwmod *oh)
+{
+	struct omap_hwmod_class_sysconfig *sysc;
+	u32 softrst_mask;
+	int c = 0;
+
+	sysc = oh->class->sysc;
+
+	if (sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
+		omap_test_timeout((omap_hwmod_read(oh, sysc->syss_offs)
+				   & SYSS_RESETDONE_MASK),
+				  MAX_MODULE_SOFTRESET_WAIT, c);
+	else if (sysc->sysc_flags & SYSC_HAS_RESET_STATUS) {
+		softrst_mask = (0x1 << sysc->sysc_fields->srst_shift);
+		omap_test_timeout(!(omap_hwmod_read(oh, sysc->sysc_offs)
+				    & softrst_mask),
+				  MAX_MODULE_SOFTRESET_WAIT, c);
+	}
+
+	return c;
+}
+
+/**
  * _set_dmadisable: set OCP_SYSCONFIG.DMADISABLE bit in @v
  * @oh: struct omap_hwmod *
  *
@@ -1282,6 +1314,14 @@ static void _enable_sysc(struct omap_hwmod *oh)
 	if (!oh->class->sysc)
 		return;
 
+	/*
+	 * Wait until reset has completed, this is needed as the IP
+	 * block is reset automatically by hardware in some cases
+	 * (off-mode for example), and the drivers require the
+	 * IP to be ready when they access it
+	 */
+	_wait_softreset_complete(oh);
+
 	v = oh->_sysc_cache;
 	sf = oh->class->sysc->sysc_flags;
 
@@ -1804,7 +1844,7 @@ static int _am33xx_disable_module(struct omap_hwmod *oh)
  */
 static int _ocp_softreset(struct omap_hwmod *oh)
 {
-	u32 v, softrst_mask;
+	u32 v;
 	int c = 0;
 	int ret = 0;
 
@@ -1834,19 +1874,7 @@ static int _ocp_softreset(struct omap_hwmod *oh)
 	if (oh->class->sysc->srst_udelay)
 		udelay(oh->class->sysc->srst_udelay);
 
-	if (oh->class->sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
-		omap_test_timeout((omap_hwmod_read(oh,
-						    oh->class->sysc->syss_offs)
-				   & SYSS_RESETDONE_MASK),
-				  MAX_MODULE_SOFTRESET_WAIT, c);
-	else if (oh->class->sysc->sysc_flags & SYSC_HAS_RESET_STATUS) {
-		softrst_mask = (0x1 << oh->class->sysc->sysc_fields->srst_shift);
-		omap_test_timeout(!(omap_hwmod_read(oh,
-						     oh->class->sysc->sysc_offs)
-				   & softrst_mask),
-				  MAX_MODULE_SOFTRESET_WAIT, c);
-	}
-
+	c = _wait_softreset_complete(oh);
 	if (c == MAX_MODULE_SOFTRESET_WAIT)
 		pr_warning("omap_hwmod: %s: softreset failed (waited %d usec)\n",
 			   oh->name, MAX_MODULE_SOFTRESET_WAIT);

^ permalink raw reply related

* [PATCH 1/4] ARM: OMAP2+: clockdomain: Fix OMAP4 ISS clk domain to support only SWSUP
From: Paul Walmsley @ 2012-10-31 10:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121031103607.6557.64591.stgit@dusk.lan>

From: Miguel Vadillo <vadillo@ti.com>

Since CAM domain (ISS) has no module wake-up dependency
with any other clock domain of the device and the dynamic
dependency from L3_main_2 is always disabled, the domain
needs to be in force wakeup in order to be able to access
it for configure (sysconfig) it or use it.

Also since there is no clock in the domain managed automatically
by the hardware, there is no use to configure automatic
clock domain transition. SW should keep the SW_WKUP domain
transition as long as a module in the domain is required to
be functional.

Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
---
 arch/arm/mach-omap2/clockdomains44xx_data.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
index b56d06b..95192a0 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -359,7 +359,7 @@ static struct clockdomain iss_44xx_clkdm = {
 	.clkdm_offs	  = OMAP4430_CM2_CAM_CAM_CDOFFS,
 	.wkdep_srcs	  = iss_wkup_sleep_deps,
 	.sleepdep_srcs	  = iss_wkup_sleep_deps,
-	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+	.flags		  = CLKDM_CAN_SWSUP,
 };
 
 static struct clockdomain l3_dss_44xx_clkdm = {

^ permalink raw reply related

* [PATCH 0/4] ARM: OMAP: more hwmod/PRCM fixes for 3.7-rc
From: Paul Walmsley @ 2012-10-31 10:43 UTC (permalink / raw)
  To: linux-arm-kernel

A few more OMAP fixes for the 3.7-rc timeframe.  Mostly hwmod fixes.

Basic test logs are available here:

    http://www.pwsan.com/omap/testlogs/fixes_b_v3.7-rc/20121029222655/

However the v3.7-rc3 kernel is still missing fixes for several regressions,
which cause several tests to fail.  With several reverts, fixes, and workarounds
applied, the following test logs were obtained:

    http://www.pwsan.com/omap/testlogs/TEST_fixes_b_v3.7-rc/20121030185805/

 which indicate that the series tests cleanly.


- Paul

---

vmlinux object size
(delta in bytes from test_v3.7-rc3 (8f0d8163b50e01f398b14bcd4dc039ac5ab18d64)):
   text     data      bss    total  kernel
   -108       -8        0     -116  am33xx_only
    +56      +16        0      +72  n800_multi_omap2xxx
    +20      +16        0      +36  n800_only_a
      0        0        0        0  omap1_defconfig
      0        0        0        0  omap1_defconfig_1510innovator_only
      0        0        0        0  omap1_defconfig_5912osk_only
    -92      -16        0     -108  omap2plus_defconfig
    -96       -8        0     -104  omap2plus_defconfig_2430sdp_only
    -92      +16        0      -76  omap2plus_defconfig_cpupm
    -92      -16        0     -108  omap2plus_defconfig_no_pm
    -92      +16        0      -76  omap2plus_defconfig_omap2_4_only
   -172      +16        0     -156  omap2plus_defconfig_omap3_4_only
    +12      +16        0      +28  rmk_omap3430_ldp_oldconfig
    +44      +24        0      +68  rmk_omap4430_sdp_oldconfig


Miguel Vadillo (1):
      ARM: OMAP2+: clockdomain: Fix OMAP4 ISS clk domain to support only SWSUP

Paul Walmsley (2):
      ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init
      ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init

Tero Kristo (1):
      ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod


 arch/arm/mach-omap2/clockdomains44xx_data.c  |    2 -
 arch/arm/mach-omap2/omap_hwmod.c             |   59 ++++++++++++++++++++------
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c   |    8 ++++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    6 +++
 4 files changed, 60 insertions(+), 15 deletions(-)

^ permalink raw reply

* [PATCH v3 10/10] net/macb: add pinctrl consumer support
From: Nicolas Ferre @ 2012-10-31 10:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAGhQ9VxJ58ej3j9eEx1rex5h-ua_C53=Z4WwGk5YdjfaYTdHpw@mail.gmail.com>

On 10/30/2012 06:37 PM, Joachim Eastwood :
> On 30 October 2012 11:18, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>>
>> If no pinctrl available just report a warning as some architecture may not
>> need to do anything.
>>
>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>> [nicolas.ferre at atmel.com: adapt the error path]
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> Cc: netdev at vger.kernel.org
>> ---
>>  drivers/net/ethernet/cadence/macb.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
>> index 4d51877..eae3d74 100644
>> --- a/drivers/net/ethernet/cadence/macb.c
>> +++ b/drivers/net/ethernet/cadence/macb.c
>> @@ -26,6 +26,9 @@
>>  #include <linux/of.h>
>>  #include <linux/of_device.h>
>>  #include <linux/of_net.h>
>> +#include <linux/of_gpio.h>
>> +#include <linux/gpio.h>
> Why are these two headers added?
> I don't see anything from them used in the code added.
> 
> Wouldn't the pinctrl header by itself be sufficient?

It is: I will remove the two unneeded headers in my v4 patch series.

Thanks,

> 
>> +#include <linux/pinctrl/consumer.h>
>>
>>  #include "macb.h"
>>
>> @@ -1472,6 +1475,7 @@ static int __init macb_probe(struct platform_device *pdev)
>>         struct phy_device *phydev;
>>         u32 config;
>>         int err = -ENXIO;
>> +       struct pinctrl *pinctrl;
>>
>>         regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>         if (!regs) {
>> @@ -1479,6 +1483,15 @@ static int __init macb_probe(struct platform_device *pdev)
>>                 goto err_out;
>>         }
>>
>> +       pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
>> +       if (IS_ERR(pinctrl)) {
>> +               err = PTR_ERR(pinctrl);
>> +               if (err == -EPROBE_DEFER)
>> +                       goto err_out;
>> +
>> +               dev_warn(&pdev->dev, "No pinctrl provided\n");
>> +       }
>> +
>>         err = -ENOMEM;
>>         dev = alloc_etherdev(sizeof(*bp));
>>         if (!dev)

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply

* [PATCH v3 06/10] net/macb: clean up ring buffer logic
From: Nicolas Ferre @ 2012-10-31 10:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5090F67C.9020104@atmel.com>

On 10/31/2012 10:59 AM, Nicolas Ferre :
> On 10/30/2012 07:22 PM, H?vard Skinnemoen :
>> On Tue, Oct 30, 2012 at 4:12 AM, David Laight <David.Laight@aculab.com> wrote:
>>>> Instead of masking head and tail every time we increment them, just let them
>>>> wrap through UINT_MAX and mask them when subscripting. Add simple accessor
>>>> functions to do the subscripting properly to minimize the chances of messing
>>>> this up.
>>> ...
>>>> +static unsigned int macb_tx_ring_avail(struct macb *bp)
>>>> +{
>>>> +     return TX_RING_SIZE - (bp->tx_head - bp->tx_tail);
>>>> +}
>>>
>>> That one doesn't look quite right to me.
>>> Surely it should be masking with 'TX_RING_SIZE - 1'
>>
>> Why is that? head and tail can never be more than TX_RING_SIZE apart,
>> so it shouldn't make any difference.
> 
> Absolutely.

Well not so absolute, after having thinking twice ;-)

We should move to:

static unsigned int macb_tx_ring_avail(struct macb *bp)
{
	return (TX_RING_SIZE - (bp->tx_head - bp->tx_tail) & (TX_RING_SIZE - 1));
}

Thanks David!

(sorry for the noise) Bye,
-- 
Nicolas Ferre

^ permalink raw reply

* [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
From: Benoit Cousson @ 2012-10-31 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5090FA92.1080400@ti.com>


On 10/31/2012 11:16 AM, Benoit Cousson wrote:
> Hi Avinash,
> 
> On 10/30/2012 10:41 AM, Philip, Avinash wrote:
>> On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
>>> On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
>>>> Adds AM33XX SPI support for am335x-bone and am335x-evm.
>>
>> Matt,
>>
>> Can you build SPI DT patch with DMA support on top of SPI DT patch
>> I submitted [1]. With the patch [1] SPI can work on PIO mode.
>> So we can have basic SPI support available in 3.8.
>>
>> Benoit,
>> Can you accept the SPI DT patch [1]
> 
> Yes, I've just applied it in for_3.8/dts branch

Well, in fact I did not, it does not apply :-(

Can you rebase on top of the for_3.8/dts branch? I've just applied the
RTC patch on top that was OK.

Thanks,
Benoit

> 
>> In case if you want I will resubmit a patch with subject line modified.
> 
> No, that's fine.
> 
> Thanks,
> Benoit
> 
>>
>> Current subject line
>> arm/dts: AM33XX: Add SPI device tree data
>>
>> 1. https://patchwork.kernel.org/patch/1470661/
>>
>> Thanks
>> Avinash
>>
>>>>
>>>> Signed-off-by: Matt Porter <mporter@ti.com>
>>>> ---
>>>>  arch/arm/boot/dts/am335x-bone.dts |   17 +++++++++++++++
>>>>  arch/arm/boot/dts/am335x-evm.dts  |    9 ++++++++
>>>>  arch/arm/boot/dts/am33xx.dtsi     |   43 +++++++++++++++++++++++++++++++++++++
>>>>  3 files changed, 69 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>>> index 5510979..23edfd8 100644
>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>> @@ -18,6 +18,17 @@
>>>>  		reg = <0x80000000 0x10000000>; /* 256 MB */
>>>>  	};
>>>>  
>>>> +	am3358_pinmux: pinmux at 44e10800 {
>>>> +		spi1_pins: pinmux_spi1_pins {
>>>> +			pinctrl-single,pins = <
>>>> +				0x190 0x13	/* mcasp0_aclkx.spi1_sclk, OUTPUT_PULLUP | MODE3 */
>>>> +				0x194 0x33	/* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
>>>> +				0x198 0x13	/* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
>>>> +				0x19c 0x13	/* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
>>>> +			>;
>>>> +		};
>>>> +	};
>>>> +
>>>
>>> Change to am33xx_pinmux.
>>>
>>>>  	ocp {
>>>>  		uart1: serial at 44e09000 {
>>>>  			status = "okay";
>>>> @@ -84,3 +95,9 @@
>>>>  &mmc1 {
>>>>  	vmmc-supply = <&ldo3_reg>;
>>>>  };
>>>> +
>>>> +&spi1 {
>>>> +	status = "okay";
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&spi1_pins>;
>>>> +};
>>>> diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
>>>> index d63fce8..8d5f660 100644
>>>> --- a/arch/arm/boot/dts/am335x-evm.dts
>>>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>>>> @@ -124,3 +124,12 @@
>>>>  &mmc1 {
>>>>  	vmmc-supply = <&vmmc_reg>;
>>>>  };
>>>> +
>>>> +&spi0 {
>>>> +	status = "okay";
>>>> +	spi-flash at 0 {
>>>> +		compatible = "spansion,s25fl064k", "m25p80";
>>>> +		spi-max-frequency = <24000000>;
>>>> +		reg = <0>;
>>>> +	};
>>>> +};
>>>
>>> In AM335x-evm, SPI flash available in profile #2 (am335x evm specific profiles).
>>> So can you drop this changes as if I understood correctly, am335x-evm.dts will be
>>> populated for devices present only on profile #0.
>>>
>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>>> index 26a6af7..063ecea 100644
>>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>>> @@ -40,6 +40,15 @@
>>>>  		};
>>>>  	};
>>>>  
>>>> +	am3358_pinmux: pinmux at 44e10800 {
>>>> +		compatible = "pinctrl-single";
>>>> +		reg = <0x44e10800 0x0238>;
>>>> +		#address-cells = <1>;
>>>> +		#size-cells = <0>;
>>>> +		pinctrl-single,register-width = <32>;
>>>> +		pinctrl-single,function-mask = <0x7f>;
>>>> +	};
>>>> +
>>>
>>> Pin ctrl support already submitted
>>> http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=commitdiff;h=3e0603e905d9ba662e8c1885ecb1d28bc454e448
>>>
>>> Thanks
>>> Avinash
>>>
>>>>  	/*
>>>>  	 * XXX: Use a flat representation of the AM33XX interconnect.
>>>>  	 * The real AM33XX interconnect network is quite complex.Since
>>>> @@ -261,6 +270,40 @@
>>>>  			status = "disabled";
>>>>  		};
>>>>  
>>>> +		spi0: spi at 48030000 {
>>>> +			compatible = "ti,omap4-mcspi";
>>>> +			ti,hwmods = "spi0";
>>>> +			#address-cells = <1>;
>>>> +			#size-cells = <0>;
>>>> +			reg = <0x48030000 0x400>;
>>>> +			interrupt-parent = <&intc>;
>>>> +			interrupt = <65>;
>>>> +			dmas = <&edma 16
>>>> +				&edma 17
>>>> +				&edma 18
>>>> +				&edma 19>;
>>>> +			dma-names = "tx0", "rx0", "tx1", "rx1";
>>>> +			ti,spi-num-cs = <2>;
>>>> +			status = "disabled";
>>>> +		};
>>>> +
>>>> +		spi1: spi at 481a0000 {
>>>> +			compatible = "ti,omap4-mcspi";
>>>> +			ti,hwmods = "spi1";
>>>> +			#address-cells = <1>;
>>>> +			#size-cells = <0>;
>>>> +			reg = <0x481a0000 0x400>;
>>>> +			interrupt-parent = <&intc>;
>>>> +			interrupt = <125>;
>>>> +			dmas = <&edma 42
>>>> +				&edma 43
>>>> +				&edma 44
>>>> +				&edma 45>;
>>>> +			dma-names = "tx0", "rx0", "tx1", "rx1";
>>>> +			ti,spi-num-cs = <2>;
>>>> +			status = "disabled";
>>>> +		};
>>>> +
>>>>  		wdt2: wdt at 44e35000 {
>>>>  			compatible = "ti,omap3-wdt";
>>>>  			ti,hwmods = "wd_timer2";
>>>> -- 
>>>> 1.7.9.5
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>
>>>
>>>
>>
> 

^ permalink raw reply

* [RFC PATCH] dt: describe base reset signal binding
From: Mike Turquette @ 2012-10-31 10:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5090161D.2030702@wwwdotorg.org>

Quoting Stephen Warren (2012-10-30 11:02:05)
> On 10/29/2012 12:32 PM, Mike Turquette wrote:
> > Quoting Stephen Warren (2012-10-23 14:45:56)
> >> What do people think of this? Does it sound like a good idea to go ahead
> >> with a reset subsystem? Should we simply add a new API to the common clock
> >> subsystem instead (and assume that reset and clock domains match 1:1).
> >> Should this be implemented as part of the generic power management domains;
> >> see include/linux/pm_domain.h instead?
> >>
> > 
> > Hi Stephen,
> > 
> > I'm not sure a "reset subsystem" is necessary, but I also do not like
> > using clocks as the keys for IP reset.
> 
> I'm not sure what you're suggesting as an alternative to a reset
> subsystem (or API if you want something that sounds smaller!) :-)
> 

My point was that I do not know if a new subsystem is necessary or not.
Your suggestion to "simply add a new API to the common clock subsystem"
is an example of an alternative to a whole new subsystem.  However I
instinctively feel that the clock api is not the right place for
reseting devices.

> > I think it is more common to map IPs to struct device, no?
> 
> It is indeed probably common that there's a 1:1 mapping between IP
> blocks and struct device. However, I'm sure there are plenty of
> counter-examples; IP blocks with multiple reset domains (hence struct
> devices that encompass multiple reset domains, or reset domains that
> encompass multiple struct devices), just as there are many examples of
> non-1:1 mappings between struct device and struct clk.
> 

In OMAP code we handle IP resets through the hwmod code and I prefer
that IP-centric approach to associating IP resets with a clock node.
Perhaps the hwmod approach could serve as inspiration for a new generic
way to reset modules.

> Even ignoring that, we'd still need to API say device_reset(struct
> device *dev) or device_reset(struct device *dev, const char *conid)
> wouldn't we? That's really all I meant by a reset subsystem.
> 

Of course.  The api must exist.

> An alternative here would be to simply move Tegra's
> tegra_periph_reset_{de,}assert() function prototypes into a header in
> include/linux rather than mach-tegra/include/mach. However, I imagine at
> least some other SoC needs a similar API, so a common API might be useful?

I also agree.  I think that there was simply some confusion about how I
responded.  To reiterate, I'm not sure whether a new subsystem should be
created or if the API can find a home in some existing subsystem, but I
don't think the clock framework is the right place for it.

Regards,
Mike

^ permalink raw reply

* [PATCH 3/3] ARM: dts: cfa10049: Add the DH2228FV DAC to the DTS
From: Maxime Ripard @ 2012-10-31 10:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351679410-11026-1-git-send-email-maxime.ripard@free-electrons.com>

There is no driver for it yet, so it will use spidev.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10049.dts |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index 05c892e..2ef7ce6 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -29,6 +29,7 @@
 						0x01c1 /* MX28_PAD_GPMI_RESETN__SSP3_CMD */
 						0x0111 /* MX28_PAD_GPMI_CE1N__SSP3_D3 */
 						0x01a2 /* MX28_PAD_GPMI_ALE__SSP3_D4 */
+						0x01b2 /* MX28_PAD_GPMI_CLE__SSP3_D5 */
 					>;
 					fsl,drive-strength = <1>;
 					fsl,voltage = <1>;
@@ -60,6 +61,11 @@
 					spi-max-frequency = <100000>;
 				};
 
+				dac0: dh2228 at 2 {
+					compatible = "rohm,dh2228fv";
+					reg = <2>;
+					spi-max-frequency = <100000>;
+				};
 			};
 		};
 
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 2/3] spi: spidev: Add Rohm DH2228FV DAC compatible string
From: Maxime Ripard @ 2012-10-31 10:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351679410-11026-1-git-send-email-maxime.ripard@free-electrons.com>

Since we don't have a driver for it yet, use spidev instead.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/spi/spidev.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 9fc5788..e44abc9 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -645,6 +645,7 @@ static int __devexit spidev_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id spidev_dt_ids[] = {
+	{ .compatible = "rohm,dh2228fv" },
 	{},
 };
 
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 1/3] spi: spidev: Add device tree bindings
From: Maxime Ripard @ 2012-10-31 10:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351679410-11026-1-git-send-email-maxime.ripard@free-electrons.com>

This will allow to probe spidev from device tree by adding the
compatible string of each device to this array.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/spi/spidev.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 830adbe..9fc5788 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -31,6 +31,8 @@
 #include <linux/mutex.h>
 #include <linux/slab.h>
 #include <linux/compat.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
 
 #include <linux/spi/spi.h>
 #include <linux/spi/spidev.h>
@@ -642,10 +644,17 @@ static int __devexit spidev_remove(struct spi_device *spi)
 	return 0;
 }
 
+static const struct of_device_id spidev_dt_ids[] = {
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, spidev_dt_ids);
+
 static struct spi_driver spidev_spi_driver = {
 	.driver = {
 		.name =		"spidev",
 		.owner =	THIS_MODULE,
+		.of_match_table = of_match_ptr(spidev_dt_ids),
 	},
 	.probe =	spidev_probe,
 	.remove =	__devexit_p(spidev_remove),
-- 
1.7.9.5

^ permalink raw reply related

* [PATCHv2 0/3] Add spidev to the CFA-10049
From: Maxime Ripard @ 2012-10-31 10:30 UTC (permalink / raw)
  To: linux-arm-kernel

Hi everyone,

This patchset probes spidev on the SSP3 bus where on the CFA-10049 there is
a Rohm DH2228FV DAC.

It first adds the dt bindings for the spidev driver, and the proper node in
the CFA-10049 device tree file.

Maxime

Changes from v1:
  - Removed the linux,spidev compatible string and use the compatible strings
    of the devices instead.

Maxime Ripard (3):
  spi: spidev: Add device tree bindings
  spi: spidev: Add Rohm DH2228FV DAC compatible string
  ARM: dts: cfa10049: Add the DH2228FV DAC to the DTS

 arch/arm/boot/dts/imx28-cfa10049.dts |    6 ++++++
 drivers/spi/spidev.c                 |   10 ++++++++++
 2 files changed, 16 insertions(+)

-- 
1.7.9.5

^ permalink raw reply

* pm: add suspend_mem and suspend_standby support
From: Daniel Mack @ 2012-10-31 10:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB3AF86@DBDE01.ent.ti.com>

On 10.10.2012 11:29, Hiremath, Vaibhav wrote:
> On Wed, Oct 10, 2012 at 14:50:25, Daniel Mack wrote:
>> On 10.10.2012 09:17, Vaibhav Hiremath wrote:
>>> On 10/10/2012 3:42 AM, Rafael J. Wysocki wrote:
>>>> On Tuesday 09 of October 2012 17:17:04 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> On 07:58 Tue 09 Oct     , Greg Kroah-Hartman wrote:
>>>>>> On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>> On 22:02 Sun 07 Oct     , Rafael J. Wysocki wrote:
>>>>>>>> On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>>>> On 00:18 Sun 07 Oct     , Rafael J. Wysocki wrote:
>>>>>>>>>> On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
>>>>>>>>>>>
>>>>>>>>>>>   Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
>>>>>>>>>>>
>>>>>>>>>>> are available in the git repository at:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
>>>>>>>>>>>
>>>>>>>>>>> for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
>>>>>>>>>>>
>>>>>>>>>>>   arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>>>> pm: add suspend_mem and suspend_standby support
>>>>>>>>>>>
>>>>>>>>>>> Today when we go to suspend we can not knwon at drivers level if we go in
>>>>>>>>>>> STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
>>>>>>>>>>> suspend_standby.
>>>>>>>>>>
>>>>>>>>>> No way. Device drivers shouldn't be concerned about that.
>>>>>>>>> I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
>>>>>>>>> need special handling when switching to slow_clock
>>>>>>>>
>>>>>>>> Well, my answer to that is: please fix your platform code instead of
>>>>>>>> hacking the PM core to work around its problems.
>>>>>>> how can I fix drivers pm issue when I no way to known at driver level the
>>>>>>> real suspend, the PM core is supposed to proivde the right information to the
>>>>>>> drivers so the driver can put it's in the right pm mode. If the pm core can not
>>>>>>> provide such inforation the PM core is broken as we will have to do dirty
>>>>>>> hack.
>>>>>>
>>>>>> Why do you need to know the difference in your driver?  We used to
>>>>>> provide this information a long time ago, but it turned out to not be
>>>>>> needed at all and just caused problems.
>>>>> because on at91 I need to handle the mem standby at drviers level.
>>>>
>>>> This is not an answer.  You're basically saying "it has to be done this way,
>>>> because it has to be done this way".
>>>>
>>>>> We do it today already by a hack in different drivers at91_udc (usb device),
>>>>> atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
>>>>> to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
>>>>> clock - this is done at soc level - but those IP have issue and need specific
>>>>> care before doing so. Ohterwise when the SoC will wakeup but those IP will not
>>>>>
>>>>> in this patch series I send the update of those 3 drivers too
>>>>> and kill the hack
>>>>
>>>> Well, let's start over.  What's the difference between "suspend to RAM" (mem)
>>>> and "standby" on your platform?
>>>>
>>>>>>> Any generic framework is supposed to evolve for real user need here I've one
>>>>>>> so I udpate the core to mach a need
>>>>
>>>> Yes, if there are more users needing a change.  If there's only one, I think not
>>>> really.
>>>>
>>>
>>> We came across such a need while supporting various low-power modes in
>>> AM335x SoC. I also wanted to put similar proposal, its good that Jean
>>> submitted patches and we are having this discussion early.
>>>
>>> Let me try to describe the need and issue here,
>>>
>>> In case of AM33xx device, we have different low-power modes supported
>>> by HW, for this discussion I will just talk about DeepSleep-0 and
>>> StandBy mode supported by HW (few other modes also described in spec)-
>>>
>>> Below is the Spec definition of these two low-power modes,
>>
>> Thanks for this summary, which raises a question for me that might be
>> slightly unreleated to the general discussion, but still:
>>
>> I was just looking at the code that ships with the BSP kernel, and the
>> approach there is to load a binary firmare blob to the M3 UMEM and then
>> communicates with mailbox commands in order to put the system to suspend.
>>
> 
> Ohh, Great, then you are aware of AM33xx power management support.
> As you are aware, M3 here works as a soft-PRCM block, so certain things has 
> to be done on M3 while entering into low-power state.
> 
>> Is this how it should be done in mainline as well or are there any plans
>> to implement that behaviour natively?
>>
> 
> Yes, we will follow similar approach for Mainline, its under development and 
> soon you will see patches getting submitted to the list for review. The 
> first step is to get deepsleep-0 support in Mainline and then other will 
> follow.

May I ask whether there is anything yet I can test?


Thanks,
Daniel

^ permalink raw reply

* [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
From: Benoit Cousson @ 2012-10-31 10:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <518397C60809E147AF5323E0420B992E3E9D597B@DBDE01.ent.ti.com>

Hi Avinash,

On 10/30/2012 10:41 AM, Philip, Avinash wrote:
> On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
>> On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
>>> Adds AM33XX SPI support for am335x-bone and am335x-evm.
> 
> Matt,
> 
> Can you build SPI DT patch with DMA support on top of SPI DT patch
> I submitted [1]. With the patch [1] SPI can work on PIO mode.
> So we can have basic SPI support available in 3.8.
> 
> Benoit,
> Can you accept the SPI DT patch [1]

Yes, I've just applied it in for_3.8/dts branch

> In case if you want I will resubmit a patch with subject line modified.

No, that's fine.

Thanks,
Benoit

> 
> Current subject line
> arm/dts: AM33XX: Add SPI device tree data
> 
> 1. https://patchwork.kernel.org/patch/1470661/
> 
> Thanks
> Avinash
> 
>>>
>>> Signed-off-by: Matt Porter <mporter@ti.com>
>>> ---
>>>  arch/arm/boot/dts/am335x-bone.dts |   17 +++++++++++++++
>>>  arch/arm/boot/dts/am335x-evm.dts  |    9 ++++++++
>>>  arch/arm/boot/dts/am33xx.dtsi     |   43 +++++++++++++++++++++++++++++++++++++
>>>  3 files changed, 69 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>> index 5510979..23edfd8 100644
>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>> @@ -18,6 +18,17 @@
>>>  		reg = <0x80000000 0x10000000>; /* 256 MB */
>>>  	};
>>>  
>>> +	am3358_pinmux: pinmux at 44e10800 {
>>> +		spi1_pins: pinmux_spi1_pins {
>>> +			pinctrl-single,pins = <
>>> +				0x190 0x13	/* mcasp0_aclkx.spi1_sclk, OUTPUT_PULLUP | MODE3 */
>>> +				0x194 0x33	/* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
>>> +				0x198 0x13	/* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
>>> +				0x19c 0x13	/* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
>>> +			>;
>>> +		};
>>> +	};
>>> +
>>
>> Change to am33xx_pinmux.
>>
>>>  	ocp {
>>>  		uart1: serial at 44e09000 {
>>>  			status = "okay";
>>> @@ -84,3 +95,9 @@
>>>  &mmc1 {
>>>  	vmmc-supply = <&ldo3_reg>;
>>>  };
>>> +
>>> +&spi1 {
>>> +	status = "okay";
>>> +	pinctrl-names = "default";
>>> +	pinctrl-0 = <&spi1_pins>;
>>> +};
>>> diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
>>> index d63fce8..8d5f660 100644
>>> --- a/arch/arm/boot/dts/am335x-evm.dts
>>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>>> @@ -124,3 +124,12 @@
>>>  &mmc1 {
>>>  	vmmc-supply = <&vmmc_reg>;
>>>  };
>>> +
>>> +&spi0 {
>>> +	status = "okay";
>>> +	spi-flash at 0 {
>>> +		compatible = "spansion,s25fl064k", "m25p80";
>>> +		spi-max-frequency = <24000000>;
>>> +		reg = <0>;
>>> +	};
>>> +};
>>
>> In AM335x-evm, SPI flash available in profile #2 (am335x evm specific profiles).
>> So can you drop this changes as if I understood correctly, am335x-evm.dts will be
>> populated for devices present only on profile #0.
>>
>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>> index 26a6af7..063ecea 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -40,6 +40,15 @@
>>>  		};
>>>  	};
>>>  
>>> +	am3358_pinmux: pinmux at 44e10800 {
>>> +		compatible = "pinctrl-single";
>>> +		reg = <0x44e10800 0x0238>;
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +		pinctrl-single,register-width = <32>;
>>> +		pinctrl-single,function-mask = <0x7f>;
>>> +	};
>>> +
>>
>> Pin ctrl support already submitted
>> http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=commitdiff;h=3e0603e905d9ba662e8c1885ecb1d28bc454e448
>>
>> Thanks
>> Avinash
>>
>>>  	/*
>>>  	 * XXX: Use a flat representation of the AM33XX interconnect.
>>>  	 * The real AM33XX interconnect network is quite complex.Since
>>> @@ -261,6 +270,40 @@
>>>  			status = "disabled";
>>>  		};
>>>  
>>> +		spi0: spi at 48030000 {
>>> +			compatible = "ti,omap4-mcspi";
>>> +			ti,hwmods = "spi0";
>>> +			#address-cells = <1>;
>>> +			#size-cells = <0>;
>>> +			reg = <0x48030000 0x400>;
>>> +			interrupt-parent = <&intc>;
>>> +			interrupt = <65>;
>>> +			dmas = <&edma 16
>>> +				&edma 17
>>> +				&edma 18
>>> +				&edma 19>;
>>> +			dma-names = "tx0", "rx0", "tx1", "rx1";
>>> +			ti,spi-num-cs = <2>;
>>> +			status = "disabled";
>>> +		};
>>> +
>>> +		spi1: spi at 481a0000 {
>>> +			compatible = "ti,omap4-mcspi";
>>> +			ti,hwmods = "spi1";
>>> +			#address-cells = <1>;
>>> +			#size-cells = <0>;
>>> +			reg = <0x481a0000 0x400>;
>>> +			interrupt-parent = <&intc>;
>>> +			interrupt = <125>;
>>> +			dmas = <&edma 42
>>> +				&edma 43
>>> +				&edma 44
>>> +				&edma 45>;
>>> +			dma-names = "tx0", "rx0", "tx1", "rx1";
>>> +			ti,spi-num-cs = <2>;
>>> +			status = "disabled";
>>> +		};
>>> +
>>>  		wdt2: wdt at 44e35000 {
>>>  			compatible = "ti,omap3-wdt";
>>>  			ti,hwmods = "wd_timer2";
>>> -- 
>>> 1.7.9.5
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
>>
> 

^ permalink raw reply

* [PATCH RFC] i2c: omap: Fix the revision register read
From: Felipe Balbi @ 2012-10-31 10:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAM=Q2cssHRYFJprozOSJqXNgeCub27jyVXkhvvMaxz-Z44d_EA@mail.gmail.com>

Hi,

On Wed, Oct 31, 2012 at 03:02:57PM +0530, Shubhrajyoti Datta wrote:
> On Wed, Oct 31, 2012 at 2:29 PM, Shubhrajyoti D <shubhrajyoti@ti.com> wrote:
> > The revision register on OMAP4 is a 16-bit lo and a 16-bit
> > hi. Currently the driver reads only the lower 8-bits.
> > Fix the same by preventing the truncating of the rev register
> > for OMAP4.
> >
> > Also use the scheme bit ie bit-14 of the hi register to know if it
> > is OMAP_I2C_IP_VERSION_2.
> >
> > On platforms previous to OMAP4 the offset 0x04 is IE register whose
> > bit-14 reset value is 0, the code uses the same to its advantage.
> >
> > The dev->regs is populated after reading the rev_hi. A NULL check
> > has been added in the resume handler to prevent the access before
> > the setting of the regs.
> >
> tested on omap4sdp, omap3630 based beagle , omap3430sdp.

oh, now I see. You need to test on OMAP2 which has different revision
layout.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121031/feaae506/attachment.sig>

^ permalink raw reply

* [PATCH RFC] i2c: omap: Fix the revision register read
From: Felipe Balbi @ 2012-10-31 10:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351673959-5918-1-git-send-email-shubhrajyoti@ti.com>

Hi,

On Wed, Oct 31, 2012 at 02:29:19PM +0530, Shubhrajyoti D wrote:
> The revision register on OMAP4 is a 16-bit lo and a 16-bit
> hi. Currently the driver reads only the lower 8-bits.
> Fix the same by preventing the truncating of the rev register
> for OMAP4.

very good, but you need to test this with OMAP2/3/4 (5 ??). How was this
tested ?

> Also use the scheme bit ie bit-14 of the hi register to know if it
> is OMAP_I2C_IP_VERSION_2.
> 
> On platforms previous to OMAP4 the offset 0x04 is IE register whose
> bit-14 reset value is 0, the code uses the same to its advantage.
> 
> The dev->regs is populated after reading the rev_hi. A NULL check
> has been added in the resume handler to prevent the access before
> the setting of the regs.

this could get some rephrasing, I guess. At least to me it's difficult
to understand what you mean :-s

> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> ---
> todo: some of the flag checks can be removed in favour of revision check.
> 
>  drivers/i2c/busses/i2c-omap.c |   35 +++++++++++++++++++++++++----------
>  1 files changed, 25 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index db31eae..651a7f7 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -51,7 +51,8 @@
>  /* I2C controller revisions present on specific hardware */
>  #define OMAP_I2C_REV_ON_2430		0x36
>  #define OMAP_I2C_REV_ON_3430_3530	0x3C
> -#define OMAP_I2C_REV_ON_3630_4430	0x40
> +#define OMAP_I2C_REV_ON_3630		0x40
> +#define OMAP_I2C_REV_ON_4430_PLUS	0x5040

I would rather see a proper decoding of the revision, meaning that you
would:

For omap2/3:

rev major = rev >> 8;
rev minor = rev & 0xff;

For OMAP4/5:

well, that's a lot more complex, but you have that data ;-)

>  /* timeout waiting for the controller to respond */
>  #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
> @@ -202,7 +203,7 @@ struct omap_i2c_dev {
>  						 * fifo_size==0 implies no fifo
>  						 * if set, should be trsh+1
>  						 */
> -	u8			rev;
> +	u16			rev;

IMHO this should be u32, so you don't need rev_lo and rev_hi below.

>  	unsigned		b_hw:1;		/* bad h/w fixes */
>  	unsigned		receiver:1;	/* true when we're in receiver mode */
>  	u16			iestate;	/* Saved interrupt register */
> @@ -490,7 +491,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
>  
>  	omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
>  
> -	if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
> +	if (dev->rev < OMAP_I2C_REV_ON_3630)
>  		dev->b_hw = 1; /* Enable hardware fixes */
>  
>  	/* calculate wakeup latency constraint for MPU */
> @@ -1064,6 +1065,8 @@ omap_i2c_probe(struct platform_device *pdev)
>  	const struct of_device_id *match;
>  	int irq;
>  	int r;
> +	u16 rev_lo;
> +	u16 rev_hi;
>  
>  	/* NOTE: driver uses the static register mapping */
>  	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -1117,11 +1120,6 @@ omap_i2c_probe(struct platform_device *pdev)
>  
>  	dev->reg_shift = (dev->flags >> OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) & 3;
>  
> -	if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
> -		dev->regs = (u8 *)reg_map_ip_v2;
> -	else
> -		dev->regs = (u8 *)reg_map_ip_v1;
> -
>  	pm_runtime_enable(dev->dev);
>  	pm_runtime_set_autosuspend_delay(dev->dev, OMAP_I2C_PM_TIMEOUT);
>  	pm_runtime_use_autosuspend(dev->dev);
> @@ -1130,7 +1128,21 @@ omap_i2c_probe(struct platform_device *pdev)
>  	if (IS_ERR_VALUE(r))
>  		goto err_free_mem;
>  
> -	dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
> +	/* Read the Rev hi bit-14 ie scheme this is 1 indicates ver2 or
> +	* highlander.

the "scheme" in highlander is a 2 bit value. In order to make this
future proof, you need to read both bits (31:30).

> +	* On omap3 Offset 4 is IE Reg the bit 14 is XDR_IE which is 0 at reset.
> +	*/

please align the * characters.

> +	rev_hi = __raw_readw(dev->base + 0x04);

you should make omap_i2c_read_reg() work fine for this case too.

> +
> +	if (rev_hi & 0x4000) {/* If scheme 1*/

you should add a symbolic define for scheme, something like:

switch (OMAP_I2C_SCHEME(rev)) {
case OMAP_I2C_SCHEME_1:
	foo();
	break;
case OMAP_I2C_SCHEME_2:
	/* FALLTHROUGH */
default:
	bar();
}

note that this will also default to highest known scheme if another
scheme is added. You need to make the driver behave like that to
decrease amount of rework to support newest OMAPs.

> +		dev->regs = (u8 *)reg_map_ip_v2;
> +		dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_HI);
> +		rev_lo = omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_LO);
> +		dev_info(dev->dev, "the low rev %x\n", rev_lo);
> +	} else {
> +		dev->regs = (u8 *)reg_map_ip_v1;
> +		dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
> +	}
>  
>  	dev->errata = 0;
>  
> @@ -1155,7 +1167,7 @@ omap_i2c_probe(struct platform_device *pdev)
>  
>  		dev->fifo_size = (dev->fifo_size / 2);
>  
> -		if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
> +		if (dev->rev < OMAP_I2C_REV_ON_3630)
>  			dev->b_hw = 1; /* Enable hardware fixes */
>  
>  		/* calculate wakeup latency constraint for MPU */
> @@ -1264,6 +1276,9 @@ static int omap_i2c_runtime_resume(struct device *dev)
>  	struct platform_device *pdev = to_platform_device(dev);
>  	struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
>  
> +	if (!_dev->regs)
> +		return 0;

this is wrong, you need to make sure dev->regs is set early enough.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121031/78efcc5c/attachment-0001.sig>

^ permalink raw reply

* Two questions about streaming DMA flushing
From: Rajanikanth H.V @ 2012-10-31 10:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121031090821.GK21164@n2100.arm.linux.org.uk>

> > 2.
> > 345 ENTRY(v7_dma_unmap_area)
> > 346         add     r1, r1, r0
> > 347         teq     r2, #DMA_TO_DEVICE
> > 348         bne     v7_dma_inv_range
> > 349         mov     pc, lr
> > 350 ENDPROC(v7_dma_unmap_area)
> >
> > v7_dma_unmap_area, will invalidate corresponding cache line for
> > ?DMA_FROM_DEVICE?. But, at v7_dma_map_area, the invalidate has been done.
> > Why do this again?
>
> Cache prefetching.
>
Speculative prefetch?

>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121031/4ea66442/attachment-0001.html>

^ permalink raw reply

* [PATCH] slab : allow SLAB_RED_ZONE and SLAB_STORE_USER to work on arm
From: Matthieu CASTET @ 2012-10-31 10:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAOJsxLHQy7pshnskn+wMp=1D9+9wGQZBhFD+kjtbCSJvoW7q2Q@mail.gmail.com>

Pekka Enberg a ?crit :
> Hi,
> 
> (Adding more people to CC.)
> 
> On Tue, Oct 16, 2012 at 2:17 PM, Matthieu CASTET
> <matthieu.castet@parrot.com> wrote:
>> From: Matthieu CASTET <castet.matthieu@free.fr>
>>
>> on cortexA8 (omap3) ralign is 64 and __alignof__(unsigned long long) is 8.
>> So we always disable debug.
>>
>> This patch is based on 5c5e3b33b7cb959a401f823707bee006caadd76e, but fix
>> case were align < sizeof(unsigned long long).
>>
>> Signed-off-by: Matthieu Castet <matthieu.castet@parrot.com>
>> CC: Russell King <rmk@arm.linux.org.uk>
>> CC: Pekka Enberg <penberg@cs.helsinki.fi>
>> ---
>>  mm/slab.c |    8 +++-----
>>  1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/slab.c b/mm/slab.c
>> index c685475..8427901 100644
>> --- a/mm/slab.c
>> +++ b/mm/slab.c
>> @@ -2462,9 +2462,6 @@ __kmem_cache_create (const char *name, size_t size, size_t align,
>>         if (ralign < align) {
>>                 ralign = align;
>>         }
>> -       /* disable debug if necessary */
>> -       if (ralign > __alignof__(unsigned long long))
>> -               flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);
>>         /*
>>          * 4) Store it.
>>          */
>> @@ -2491,8 +2488,9 @@ __kmem_cache_create (const char *name, size_t size, size_t align,
>>          */
>>         if (flags & SLAB_RED_ZONE) {
>>                 /* add space for red zone words */
>> -               cachep->obj_offset += sizeof(unsigned long long);
>> -               size += 2 * sizeof(unsigned long long);
>> +               int offset = max(align, sizeof(unsigned long long));
>> +               cachep->obj_offset += offset;
>> +               size += offset + sizeof(unsigned long long);
>>         }
>>         if (flags & SLAB_STORE_USER) {
>>                 /* user store requires one word storage behind the end of
> 
> This piece of code tends to break in peculiar ways every time someone
> touches it. I could use some more convincing in the changelog this
> time it won't...
> 
Ok, is the following changelog is ok ?

The current slab code only allow to put redzone( and user store) info if "buffer
alignment(ralign) <= __alignof__(unsigned long long)". This was done because we
want to keep the buffer aligned for user even after adding redzone@the
beginning of the buffer (the user store is stored after user buffer) [1]

But instead of disabling this feature when "ralign > __alignof__(unsigned long
long)", we can force the alignment by allocating ralign before user buffer.

This is done by setting ralign in obj_offset when "ralign > __alignof__(unsigned
long long)" and keeping the old behavior when  "ralign <= __alignof__(unsigned
long long)" (we set sizeof(unsigned long long)).

The 5c5e3b33b7cb959a401f823707bee006caadd76e commit wasn't handling "ralign <=
__alignof__(unsigned long long)", that's why it broked some configuration.

This was tested on omap3 (ralign is 64 and __alignof__(unsigned long long) is 8)


[1]
/*
 * memory layout of objects:
 * 0        : objp
 * 0 .. cachep->obj_offset - BYTES_PER_WORD - 1: padding. This ensures that
 *      the end of an object is aligned with the end of the real
 *      allocation. Catches writes behind the end of the allocation.
 * cachep->obj_offset - BYTES_PER_WORD .. cachep->obj_offset - 1:
 *      redzone word.
 * cachep->obj_offset: The real object.
 * cachep->buffer_size - 2* BYTES_PER_WORD: redzone word [BYTES_PER_WORD long]
 * cachep->buffer_size - 1* BYTES_PER_WORD: last caller address
 *                  [BYTES_PER_WORD long]
 */

^ permalink raw reply

* [PATCH v3 06/10] net/macb: clean up ring buffer logic
From: Nicolas Ferre @ 2012-10-31  9:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACiLriQnQcoXFqrqNt3nkY47nR8FnXbqWjtPRp250gueHSMDmQ@mail.gmail.com>

On 10/30/2012 07:22 PM, H?vard Skinnemoen :
> On Tue, Oct 30, 2012 at 4:12 AM, David Laight <David.Laight@aculab.com> wrote:
>>> Instead of masking head and tail every time we increment them, just let them
>>> wrap through UINT_MAX and mask them when subscripting. Add simple accessor
>>> functions to do the subscripting properly to minimize the chances of messing
>>> this up.
>> ...
>>> +static unsigned int macb_tx_ring_avail(struct macb *bp)
>>> +{
>>> +     return TX_RING_SIZE - (bp->tx_head - bp->tx_tail);
>>> +}
>>
>> That one doesn't look quite right to me.
>> Surely it should be masking with 'TX_RING_SIZE - 1'
> 
> Why is that? head and tail can never be more than TX_RING_SIZE apart,
> so it shouldn't make any difference.

Absolutely.

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply

* [PATCH v3 06/10] net/macb: clean up ring buffer logic
From: David Laight @ 2012-10-31  9:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5090FFF5.6020109@atmel.com>

> 	return (TX_RING_SIZE - (bp->tx_head - bp->tx_tail) & (TX_RING_SIZE - 1));

Is equivalent to:

	return (bp->tx_tail - bp->tx_head) & (TX_RING_SIZE - 1));

	David

^ permalink raw reply

* [Patch v2 4/4] ASoC: sam9g20-wm8731: convert to device tree support
From: Nicolas Ferre @ 2012-10-31  9:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351668420-18447-4-git-send-email-voice.shen@atmel.com>

On 10/31/2012 08:27 AM, Bo Shen :
> convert sam9g20-wm8731 to device tree support.
> 
> Signed-off-by: Bo Shen <voice.shen@atmel.com>

Seems ok for AT91. But will certainly need more eyes for the audio part...

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

> ---
> Change since v1:
>   Add sam9g20-wm8731 binding document
> ---
>  .../bindings/sound/atmel-sam9g20-audio-wm8731.txt  |   21 ++++++++
>  arch/arm/boot/dts/at91sam9g20ek_common.dtsi        |   25 +++++++++-
>  sound/soc/atmel/Kconfig                            |    3 +-
>  sound/soc/atmel/sam9g20_wm8731.c                   |   51 +++++++++++++++++++-
>  4 files changed, 94 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9g20-audio-wm8731.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9g20-audio-wm8731.txt b/Documentation/devicetree/bindings/sound/atmel-sam9g20-audio-wm8731.txt
> new file mode 100644
> index 0000000..04a39dd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/atmel-sam9g20-audio-wm8731.txt
> @@ -0,0 +1,21 @@
> +* Atmel sam9g20ek audio complex
> +
> +Required properties:
> +  - compatible: "atmel,at91sam9g20-audio"
> +  - atmel,model: The user-visible name of this sound complex.
> +  - atmel,audio-routing: A list of the connections between audio components.
> +  - atmel,dai: The phandle of the dai based on SSC controller
> +  - atmel,audio-codec: The phandle of the WM8731 audio codec
> +
> +Example:
> +sound {
> +	compatible = "atmel,at91sam9g20-audio";
> +	atmel,model = "wm8731 @ sam9g20ek";
> +
> +	atmel,audio-routing =
> +		"Ext Spk", "LHPOUT",
> +		"Int MIC", "MICIN";
> +
> +	atmel,dai = <&dai>;
> +	atmel,audio-codec = <&wm8731>;
> +};
> diff --git a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
> index b06c0db..056ff33 100644
> --- a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
> @@ -51,6 +51,10 @@
>  				atmel,vbus-gpio = <&pioC 5 0>;
>  				status = "okay";
>  			};
> +
> +			ssc0: ssc at fffbc000 {
> +				status = "okay";
> +			};
>  		};
>  
>  		nand0: nand at 40000000 {
> @@ -114,8 +118,8 @@
>  			reg = <0x50>;
>  		};
>  
> -		wm8731 at 1b {
> -			compatible = "wm8731";
> +		wm8731: wm8731 at 1b {
> +			compatible = "wlf,wm8731";
>  			reg = <0x1b>;
>  		};
>  	};
> @@ -139,4 +143,21 @@
>  			gpio-key,wakeup;
>  		};
>  	};
> +
> +	dai: dai {
> +		compatible = "atmel,atmel-ssc-dai";
> +		atmel,dai-master = <&ssc0>;
> +	};
> +
> +	sound {
> +		compatible = "atmel,at91sam9g20-audio";
> +		atmel,model = "wm8731 @ sam9g20ek";
> +
> +		atmel,audio-routing =
> +			"Ext Spk", "LHPOUT",
> +			"Int Mic", "MICIN";
> +
> +		atmel,audio-codec = <&wm8731>;
> +		atmel,dai = <&dai>;
> +	};
>  };
> diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
> index 72b09cf..397ec75 100644
> --- a/sound/soc/atmel/Kconfig
> +++ b/sound/soc/atmel/Kconfig
> @@ -16,8 +16,7 @@ config SND_ATMEL_SOC_SSC
>  
>  config SND_AT91_SOC_SAM9G20_WM8731
>  	tristate "SoC Audio support for WM8731-based At91sam9g20 evaluation board"
> -	depends on ATMEL_SSC && ARCH_AT91SAM9G20 && SND_ATMEL_SOC && \
> -                   AT91_PROGRAMMABLE_CLOCKS
> +	depends on ATMEL_SSC && SND_ATMEL_SOC && AT91_PROGRAMMABLE_CLOCKS
>  	select SND_ATMEL_SOC_SSC
>  	select SND_SOC_WM8731
>  	help
> diff --git a/sound/soc/atmel/sam9g20_wm8731.c b/sound/soc/atmel/sam9g20_wm8731.c
> index c3e1df5..0a275d0 100644
> --- a/sound/soc/atmel/sam9g20_wm8731.c
> +++ b/sound/soc/atmel/sam9g20_wm8731.c
> @@ -197,13 +197,17 @@ static struct snd_soc_card snd_soc_at91sam9g20ek = {
>  
>  static int __devinit at91sam9g20ek_audio_probe(struct platform_device *pdev)
>  {
> +	struct device_node *np = pdev->dev.of_node;
> +	struct device_node *codec_np, *cpu_np;
>  	struct clk *pllb;
>  	struct snd_soc_card *card =&snd_soc_at91sam9g20ek;
>  	int ret;
>  
> -	if (!(machine_is_at91sam9g20ek() || machine_is_at91sam9g20ek_2mmc()))
> +	if (!np) {
> +		if (!(machine_is_at91sam9g20ek()
> +			|| machine_is_at91sam9g20ek_2mmc()))
>  		return -ENODEV;
> -
> +	}
>  	/*
>  	 * Codec MCLK is supplied by PCK0 - set it up.
>  	 */
> @@ -230,6 +234,40 @@ static int __devinit at91sam9g20ek_audio_probe(struct platform_device *pdev)
>  	clk_set_rate(mclk, MCLK_RATE);
>  
>  	card->dev = &pdev->dev;
> +
> +	/* Parse device node info */
> +	if (np) {
> +		ret = snd_soc_of_parse_card_name(card, "atmel,model");
> +		if (ret)
> +			goto err;
> +
> +		ret = snd_soc_of_parse_audio_routing(card,
> +						"atmel,audio-routing");
> +		if (ret)
> +			goto err;
> +
> +		/* Parse codec dai info */
> +		at91sam9g20ek_dai.codec_name = NULL;
> +		codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
> +		if (!codec_np) {
> +			dev_err(&pdev->dev, "codec info missing\n");
> +			return -EINVAL;
> +		}
> +		at91sam9g20ek_dai.codec_of_node = codec_np;
> +		at91sam9g20ek_dai.cpu_dai_name = NULL;
> +		at91sam9g20ek_dai.platform_name = NULL;
> +		cpu_np = of_parse_phandle(np, "atmel,dai", 0);
> +		if (!cpu_np) {
> +			dev_err(&pdev->dev, "dai info missing\n");
> +			return -EINVAL;
> +		}
> +		at91sam9g20ek_dai.cpu_of_node = cpu_np;
> +		at91sam9g20ek_dai.platform_of_node = cpu_np;
> +
> +		of_node_put(codec_np);
> +		of_node_put(cpu_np);
> +	}
> +
>  	ret = snd_soc_register_card(card);
>  	if (ret) {
>  		printk(KERN_ERR "ASoC: snd_soc_register_card() failed\n");
> @@ -255,10 +293,19 @@ static int __devexit at91sam9g20ek_audio_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id sam9g20ek_wm8731_dt_ids[] = {
> +	{ .compatible = "atmel,at91sam9g20-audio", },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, sam9g20ek_wm8731_dt_ids);
> +#endif
> +
>  static struct platform_driver at91sam9g20ek_audio_driver = {
>  	.driver = {
>  		.name	= "at91sam9g20ek-audio",
>  		.owner	= THIS_MODULE,
> +		.of_match_table = of_match_ptr(sam9g20ek_wm8731_dt_ids),
>  	},
>  	.probe	= at91sam9g20ek_audio_probe,
>  	.remove	= __devexit_p(at91sam9g20ek_audio_remove),
> 


-- 
Nicolas Ferre

^ permalink raw reply

* Two questions about streaming DMA flushing
From: Li Haifeng @ 2012-10-31  9:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121031090821.GK21164@n2100.arm.linux.org.uk>

2012/10/31 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Wed, Oct 31, 2012 at 10:15:04AM +0800, Li Haifeng wrote:
>> Sorry to disturb you.
>>
>> I have two questions for streaming DMA flushing @ arch/arm/mm/cache-v7.S.
>>
>> 1.
>> 332 ENTRY(v7_dma_map_area)
>> 333         add     r1, r1, r0
>> 334         teq     r2, #DMA_FROM_DEVICE
>> 335         beq     v7_dma_inv_range
>> 336         b       v7_dma_clean_range
>> 337 ENDPROC(v7_dma_map_area)
>>
>> The function of v7_dma_map_area will invalidate corresponding cache line
>> firstly and then clean the cache for ?DMA_FROM_DEVICE?. I am confused the
>> sequence of the operations. IMO, the invalidate should be followed by the
>> clean action. Is it right?
>
> Wrong.  beq is not a function call.

Yes, It's my wrong. sorry for my careless.

>
>> 2.
>> 345 ENTRY(v7_dma_unmap_area)
>> 346         add     r1, r1, r0
>> 347         teq     r2, #DMA_TO_DEVICE
>> 348         bne     v7_dma_inv_range
>> 349         mov     pc, lr
>> 350 ENDPROC(v7_dma_unmap_area)
>>
>> v7_dma_unmap_area, will invalidate corresponding cache line for
>> ?DMA_FROM_DEVICE?. But, at v7_dma_map_area, the invalidate has been done.
>> Why do this again?
>
> Cache prefetching.

Thanks!

^ permalink raw reply


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