Re: [PATCH 2/2] arm/dts: Cleanup regulator naming and remove @0,1..

[Rajendra Nayak]

Hi Tony,


* Rajendra Nayak  [120730 06:17]:

regulators do not have a 'reg' property, hence the regulator@0,
regulator@1 do not make sense. get rid of it.


Looks like this needs to be refreshed to apply. Care to
refresh against current devel-dt branch in case other
places need the same change?


Looks like devel-dt is missing the PATCH 1/2 from this series,
which you have already pushed in the -rc for merge.
With that applied, this ones applies cleanly too.

regards,
Rajendra



Regards,

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/4] arm/dts: AM33XX: Configure pinmuxs for D_CAN1 on AM335x-EVM

[Vaibhav Hiremath]

On 8/25/2012 1:44 AM, Tony Lindgren wrote:
> * AnilKumar Ch  [120816 05:20]:
>> Add D_CAN1 pinctrl node to am3358_pinmux master node to export
>> D_CAN functionality on AM335x EVM according to pinctrl-single
>> driver.
>>
>> Signed-off-by: AnilKumar Ch 
>> ---
>> Changes from v2:
>>  - Incorporated Vaibhav H's comments on v2
>>* Added dcan0 instances to am33xx.dtsi file
>>
>> Changes from v1:
>>  - These two patches separated from c_can DT support
>>patch series.
>>
>>  arch/arm/boot/dts/am335x-evm.dts |   12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am335x-evm.dts 
>> b/arch/arm/boot/dts/am335x-evm.dts
>> index 5dd8a6b..a64c30a 100644
>> --- a/arch/arm/boot/dts/am335x-evm.dts
>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>> @@ -18,6 +18,18 @@
>>  reg = <0x8000 0x1000>; /* 256 MB */
>>  };
>>  
>> +am3358_pinmux: pinmux@44E10800 {
> 
> This should be just &am3358_pinmux as you already include it.
> 

I think it won't work this way, it will result into syntax error.
The reason being is, unlike OMAP (and like other platforms, like, imx)
here we are again representing device hierarchy starting from root,

am335x-evm.dts:
/ {

ocp {
...
};

};

Although I am not too familiar with DTS compiler, but below code results
in syntax error:

am335x-evm.dts:
/ {

ocp {
...
&am3358_pinmux {
...
};
};

};


Thanks,
Vaibhav

>> +pinctrl-names = "default";
>> +pinctrl-0 = <&d_can1_pins>;
>> +
>> +d_can1_pins: pinmux_d_can_pins {
>> +pinctrl-single,pins = <
>> +0x168 0x2   /* uart0_ctsn.d_can1_tx, OUTPUT 
>> | MODE2 */
>> +0x16C 0x32  /* uart0_rtsn.d_can1_rx, 
>> INPUT_PULLUP | MODE2 */
>> +>;
>> +};
>> +};
>> +
> 
> It would better to claim these pins in the dcan driver entry
> rather than set them as pins enabled by the pinctrl driver.
> The reason is that in case you want to enable runtime PM related
> stuff, like some more advanced wake-up features, for the rx pin
> you can do it in the driver.
> 
> Then one nit.. Please lowercase all hex number in this series as that's the 
> style
> here.
> 
> Regards,
> 
> Tony
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts

[AnilKumar, Chimata]

Hi Koen,

On Fri, Aug 24, 2012 at 13:32:17, Koen Kooi wrote:
> 
> Op 24 aug. 2012, om 09:56 heeft Koen Kooi  het 
> volgende geschreven:
> 
> > 
> > Op 24 aug. 2012, om 09:26 heeft "AnilKumar, Chimata"  het 
> > volgende geschreven:
> > 
> >> Hi Koen,
> >> 
> >> On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote:
> >>> 
> >>> Op 24 aug. 2012, om 07:50 heeft "AnilKumar, Chimata"  
> >>> het volgende geschreven:
> >>> 
>  Hi Koen,
>  
>  On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote:
> > 
> > Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch  het 
> > volgende geschreven:
> > 
> >> Add tps65217 regulator device tree data to AM335x-Bone by adding
> >> regulator consumers with tightened constraints and regulator-name.
> >> TPS65217 regulator handle can be obtained by using this regulator
> >> name.
> >> 
> >> This patch also add I2C node with I2C frequency and tps65217 PMIC
> >> I2C slave address.
> >> 
> >> Signed-off-by: AnilKumar Ch 
> > 
> > I tried this and the kernel immediately crashes on my beaglebone. Could 
> > you upload the complete git tree and .config you used to test this to 
> > somewhere public please?
>  
>  Use this repo to test on beaglebone
>  https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl
>  
>  This wiki talks about how to build and use?
>  https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree
>  
>  Note: Enable tps65217 regulator in kernel config.
> >>> 
> >>> I used that repo and as a seperate test I rebased that to latest 
> >>> mainline, same thing: as soon as I turn on the TPS in the .config it 
> >>> crashes on boot. Is the pinctrl repo the *exact* repo you used to test 
> >>> the patches on beaglebone?
> >> 
> >> I tested on latest mainline after merging to
> >> am335x-upstream-staging-pinctrl (voltage also changing)
> >> 
> >> Can you share your .config and uImage?
> > 
> > Config: 
> > https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone
> > 
> >> My config details:- (After merge)
> >> 1. omap2plus_defconfig
> >> 2. Enable tps65217 MFD driver
> >> 3. Enable tps65217 regulator driver
> > 
> > 
> > I rebased onto latest mainline and refreshed the base patches from Vaibhav 
> > and I now get: 
> > 
> > [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1
> > 
> > So it boots! I don't know what made it break before, but it's working now :)
> 
> *sigh* I'm an idiot:
> 
> root@beaglebone:~# uname -a
> Linux beaglebone 3.6.0-rc3-00103-gfd02083 #86 SMP Fri Aug 24 09:45:54 CEST 
> 2012 armv7l GNU/Linux
> root@beaglebone:~# zcat /proc/config.gz | grep 217
> CONFIG_MFD_TPS65217=y
> # CONFIG_REGULATOR_TPS65217 is not set
> 
> Will retry with regulator driver actually turned on in a bit.

Is it working after enabling the regulator?

Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap: ratelimit omap_l3_smx error log spam

[Shilimkar, Santosh]

On Mon, Aug 27, 2012 at 4:26 PM, Aaro Koskinen  wrote:
> On Mon, Aug 27, 2012 at 03:12:07PM -0700, Shilimkar, Santosh wrote:
>> On Mon, Aug 27, 2012 at 3:02 PM, Aaro Koskinen  wrote:
>> > Hi,
>> >
>> > On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote:
>> >> > -   pr_err("%s seen by %s %s at address %x\n",
>> >> > +   pr_err_ratelimited("%s seen by %s %s at address %x\n",
>> >> > omap3_l3_code_string(code),
>> >> > omap3_l3_initiator_string(initid),
>> >> > multi ? "Multiple Errors" : "", address);
>> >> > -   WARN_ON(1);
>> >> > +   WARN_ON_ONCE(1);
>> >> >
>> >> The issue needs to be fixed instead of WARN_ON_ONCE() and then
>> >> just moving ahead. Interconnect in bad states is really bad state and you
>> >> won't have reliable operations post that on SOC.
>> >
>> > How printing megabytes of identical stack traces helps anything?
>> >
>> It just says repeatedly and  loudly... Fix the issue :-)
>>
>> > This has been there always (since the L3 driver was added) on every boot
>> > with N950/N9 (which BTW are HS devices, not sure if that has anything
>> > to do with it). There is no apparent effect on device functionality,
>> > at least nothing unusual has been observed...
>> >
>> I assumed this is secure device when I saw the SRAM memset is causing the
>> issue.
>>
>> > Is there any documentation how to interpret and debug this error report?
>> >
>> The issue could be, there is memset tried on Secure portion of SRAM or
>> CPU speculatively accessed adjacent SRAM region of public SRAM which
>> is secure and hence the error.
>
> Thanks, that makes sense.
>
>> If you just bypass the SRAM init [1], does the issue go away ?
>
> I tried bypassing the whole SRAM init, but the device does not seem to
> boot up at all.
>
> If I comment out the memset alone, then it boots and the issue is gone:
>
> +#if 0
> memset_io(omap_sram_base + SRAM_BOOTLOADER_SZ, 0,
>   omap_sram_size - SRAM_BOOTLOADER_SZ);
> +#endif
>
Good. So the issue is indeed direct or indirect access to the secure SRAM.
As security can dynamically resize the secure RAM size it is even harder
to fix this issue properly. One easier way to deal with the issue is map only
needed SRAM and leave rest for security.

For now, Can you check if reducing the size of the SRAM in init is helping you
to get way with the issue. Sorry it might need few iterations for you to get
a working SRAM size.

Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/5] hwrng/ARM: OMAP: convert to use runtime PM

[Paul Walmsley]

This series converts the OMAP hardware random number generator driver
to use runtime PM.  Hardware integration data is added for OMAP2xxx
systems.  I'm pretty sure this device is available on other OMAP chips
too, but may require some experimentation with the integration details.

There are still a few rough edges with this series.  Something is
still not right with the reset behavior on OMAP2430, at least.  But it
would be good to get acks from the hwrng folks for the three patches that
touch files in that directory.  Will continue with the testing process
here.


- Paul

---

Paul Walmsley (5):
  ARM: OMAP2/3: hwmod: add RNG integration data
  hwrng: OMAP: store per-device data in per-device variables, not file 
statics
  hwrng: OMAP: convert to use runtime PM
  ARM: OMAP: split OMAP1, OMAP2+ RNG device registration
  hwrng: OMAP: remove SoC restrictions from driver registration


 arch/arm/mach-omap1/devices.c  |   28 +
 arch/arm/mach-omap2/devices.c  |   18 +++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 
 .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c |   17 +++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |   37 ++
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |5 -
 arch/arm/plat-omap/Makefile|3 
 arch/arm/plat-omap/devices.c   |   92 ---
 drivers/char/hw_random/omap-rng.c  |  121 
 10 files changed, 176 insertions(+), 147 deletions(-)
 delete mode 100644 arch/arm/plat-omap/devices.c

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] hwrng: OMAP: convert to use runtime PM

[Paul Walmsley]

Convert the OMAP onboard hardware RNG driver to use runtime PM.

This allows us to remove some OMAP-specific cpu_is_omap*() calls from
the RNG driver.

Signed-off-by: Paul Walmsley 
Cc: Matt Mackall 
Cc: Herbert Xu 
---
 drivers/char/hw_random/omap-rng.c |   35 +--
 1 file changed, 9 insertions(+), 26 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index e0f0b98..748fcc8 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -18,12 +18,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -50,12 +50,10 @@
 /**
  * struct omap_rng_private_data - RNG IP block-specific data
  * @base: virtual address of the beginning of the RNG IP block registers
- * @clk: RNG clock
  * @mem_res: struct resource * for the IP block registers physical memory
  */
 struct omap_rng_private_data {
void __iomem *base;
-   struct clk *clk;
struct resource *mem_res;
 };
 
@@ -122,17 +120,6 @@ static int __devinit omap_rng_probe(struct platform_device 
*pdev)
omap_rng_ops.priv = (unsigned long)priv;
dev_set_drvdata(&pdev->dev, priv);
 
-   if (cpu_is_omap24xx()) {
-   priv->clk = clk_get(&pdev->dev, "ick");
-   if (IS_ERR(priv->clk)) {
-   dev_err(&pdev->dev, "Could not get rng_ick\n");
-   ret = PTR_ERR(priv->clk);
-   return ret;
-   } else {
-   clk_enable(priv->clk);
-   }
-   }
-
priv->mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!priv->mem_res) {
ret = -ENOENT;
@@ -146,6 +133,9 @@ static int __devinit omap_rng_probe(struct platform_device 
*pdev)
}
dev_set_drvdata(&pdev->dev, priv);
 
+   pm_runtime_enable(&pdev->dev);
+   pm_runtime_get_sync(&pdev->dev);
+
ret = hwrng_register(&omap_rng_ops);
if (ret)
goto err_register;
@@ -153,19 +143,14 @@ static int __devinit omap_rng_probe(struct 
platform_device *pdev)
dev_info(&pdev->dev, "OMAP Random Number Generator ver. %02x\n",
 omap_rng_read_reg(priv, RNG_REV_REG));
 
-
omap_rng_write_reg(priv, RNG_MASK_REG, 0x1);
 
return 0;
 
 err_register:
priv->base = NULL;
+   pm_runtime_disable(&pdev->dev);
 err_ioremap:
-   if (cpu_is_omap24xx()) {
-   clk_disable(priv->clk);
-   clk_put(priv->clk);
-   }
-
kfree(priv);
 
return ret;
@@ -179,12 +164,8 @@ static int __exit omap_rng_remove(struct platform_device 
*pdev)
 
omap_rng_write_reg(priv, RNG_MASK_REG, 0x0);
 
-   iounmap(priv->base);
-
-   if (cpu_is_omap24xx()) {
-   clk_disable(priv->clk);
-   clk_put(priv->clk);
-   }
+   pm_runtime_put_sync(&pdev->dev);
+   pm_runtime_disable(&pdev->dev);
 
release_mem_region(priv->mem_res->start, resource_size(priv->mem_res));
 
@@ -200,6 +181,7 @@ static int omap_rng_suspend(struct device *dev)
struct omap_rng_private_data *priv = dev_get_drvdata(dev);
 
omap_rng_write_reg(priv, RNG_MASK_REG, 0x0);
+   pm_runtime_put_sync(dev);
 
return 0;
 }
@@ -208,6 +190,7 @@ static int omap_rng_resume(struct device *dev)
 {
struct omap_rng_private_data *priv = dev_get_drvdata(dev);
 
+   pm_runtime_get_sync(dev);
omap_rng_write_reg(priv, RNG_MASK_REG, 0x1);
 
return 0;


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] ARM: OMAP: split OMAP1, OMAP2+ RNG device registration

[Paul Walmsley]

Move the OMAP1-specific RNG device creation off to mach-omap1/devices.c,
and create a omap_device-backed registration function for OMAP2+ devices
in mach-omap2/devices.c.

As a nice side-benefit, we can also get rid of
arch/arm/plat-omap/devices.c, thanks to some of the recent changes
from Tony.

One change from the previous behavior is that the RNG devices are now
registered unconditionally.  This should allow the RNG drivers to be
loaded as modules, even if the original kernel was not built that way.

Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap1/devices.c |   25 +++
 arch/arm/mach-omap2/devices.c |   18 
 arch/arm/plat-omap/Makefile   |3 -
 arch/arm/plat-omap/devices.c  |   92 -
 4 files changed, 44 insertions(+), 94 deletions(-)
 delete mode 100644 arch/arm/plat-omap/devices.c

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index fa1fa4d..7f3d9d2 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -358,6 +358,30 @@ static inline void omap_init_uwire(void) {}
 #endif
 
 
+#define OMAP1_RNG_BASE 0xfffe5000
+
+static struct resource omap1_rng_resources[] = {
+   {
+   .start  = OMAP1_RNG_BASE,
+   .end= OMAP1_RNG_BASE + 0x4f,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device omap1_rng_device = {
+   .name   = "omap_rng",
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(omap1_rng_resources),
+   .resource   = omap1_rng_resources,
+};
+
+static void omap1_init_rng(void)
+{
+   (void) platform_device_register(&omap1_rng_device);
+}
+
+/*-*/
+
 /*
  * This gets called after board-specific INIT_MACHINE, and initializes most
  * on-chip peripherals accessible on this board (except for few like USB):
@@ -396,6 +420,7 @@ static int __init omap1_init_devices(void)
omap_init_spi100k();
omap_init_sti();
omap_init_uwire();
+   omap1_init_rng();
 
return 0;
 }
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c00c689..bc62f1e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -464,6 +464,23 @@ static void omap_init_pmu(void)
platform_device_register(&omap_pmu_device);
 }
 
+/**
+ * omap_init_rng - bind the RNG hwmod to the RNG omap_device
+ *
+ * Bind the RNG hwmod to the RNG omap_device.  No return value.
+ */
+static void omap_init_rng(void)
+{
+   struct omap_hwmod *oh;
+   struct platform_device *pdev;
+
+   oh = omap_hwmod_lookup("rng");
+   if (!oh)
+   return;
+
+   pdev = omap_device_build("omap_rng", -1, oh, NULL, 0, NULL, 0, 0);
+   WARN(IS_ERR(pdev), "Can't build omap_device for omap_rng\n");
+}
 
 #if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) || 
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
 
@@ -647,6 +664,7 @@ static int __init omap2_init_devices(void)
}
omap_init_pmu();
omap_init_sti();
+   omap_init_rng();
omap_init_sham();
omap_init_aes();
omap_init_vout();
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 961bf85..a017e99 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -3,8 +3,7 @@
 #
 
 # Common support
-obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
-fb.o counter_32k.o
+obj-y := common.o sram.o clock.o dma.o mux.o fb.o counter_32k.o
 obj-m :=
 obj-n :=
 obj-  :=
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
deleted file mode 100644
index 1cba927..000
--- a/arch/arm/plat-omap/devices.c
+++ /dev/null
@@ -1,92 +0,0 @@
-/*
- * linux/arch/arm/plat-omap/devices.c
- *
- * Common platform device setup/initialization for OMAP1 and OMAP2
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/*-*/
-
-#if defined(CONFIG_HW_RANDOM_OMAP) || defined(CONFIG_HW_RANDOM_OMAP_MODULE)
-
-#ifdef CONFIG_ARCH_OMAP2
-#defineOMAP_RNG_BASE   0x480A
-#else
-#defineOMAP_RNG_BASE   0xfffe5000
-#endif
-
-static struct resource rng_resources[] = {
-   {
-   .start  = OMAP_RNG_BASE,
-   .end= OMAP_RNG_BASE + 0x4f,
-   .flags  = IORESOURCE_MEM,
-   },
-};
-
-static struct platform_device omap_rng_device = {
-   .name   

[PATCH 5/5] hwrng: OMAP: remove SoC restrictions from driver registration

[Paul Walmsley]

Remove the SoC restriction code from the OMAP RNG driver.  The
integration code in arch/arm/*omap* should handle this.  The device
shouldn't be created if it doesn't exist on the currently-booted SoC.

This allows us to remove some OMAP-specific cpu_is_omap*() calls from
the driver.  Also, if other OMAP chips have RNGs that can be used
by Linux, there will be no need to modify the driver.

Signed-off-by: Paul Walmsley 
Cc: Matt Mackall 
Cc: Herbert Xu 
---
 arch/arm/mach-omap1/devices.c |3 +++
 drivers/char/hw_random/omap-rng.c |3 ---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 7f3d9d2..aedd7a4 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -377,6 +377,9 @@ static struct platform_device omap1_rng_device = {
 
 static void omap1_init_rng(void)
 {
+   if (!cpu_is_omap16xx())
+   return;
+
(void) platform_device_register(&omap1_rng_device);
 }
 
diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index 748fcc8..a5effd8 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -220,9 +220,6 @@ static struct platform_driver omap_rng_driver = {
 
 static int __init omap_rng_init(void)
 {
-   if (!cpu_is_omap16xx() && !cpu_is_omap24xx())
-   return -ENODEV;
-
return platform_driver_register(&omap_rng_driver);
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] hwrng: OMAP: store per-device data in per-device variables, not file statics

[Paul Walmsley]

Encapsulate all of the RNG per-device state into a single per-device
structure record, as opposed to a set of per-driver file variables.

Signed-off-by: Paul Walmsley 
Cc: Matt Mackall 
Cc: Herbert Xu 
---
 drivers/char/hw_random/omap-rng.c |  115 +
 1 file changed, 77 insertions(+), 38 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index 4fbdceb..e0f0b98 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -46,26 +47,38 @@
 #define RNG_SYSSTATUS  0x44/* System status
[0] = RESETDONE */
 
-static void __iomem *rng_base;
-static struct clk *rng_ick;
-static struct platform_device *rng_dev;
+/**
+ * struct omap_rng_private_data - RNG IP block-specific data
+ * @base: virtual address of the beginning of the RNG IP block registers
+ * @clk: RNG clock
+ * @mem_res: struct resource * for the IP block registers physical memory
+ */
+struct omap_rng_private_data {
+   void __iomem *base;
+   struct clk *clk;
+   struct resource *mem_res;
+};
 
-static inline u32 omap_rng_read_reg(int reg)
+static inline u32 omap_rng_read_reg(struct omap_rng_private_data *priv, int 
reg)
 {
-   return __raw_readl(rng_base + reg);
+   return __raw_readl(priv->base + reg);
 }
 
-static inline void omap_rng_write_reg(int reg, u32 val)
+static inline void omap_rng_write_reg(struct omap_rng_private_data *priv,
+ int reg, u32 val)
 {
-   __raw_writel(val, rng_base + reg);
+   __raw_writel(val, priv->base + reg);
 }
 
 static int omap_rng_data_present(struct hwrng *rng, int wait)
 {
+   struct omap_rng_private_data *priv;
int data, i;
 
+   priv = (struct omap_rng_private_data *)rng->priv;
+
for (i = 0; i < 20; i++) {
-   data = omap_rng_read_reg(RNG_STAT_REG) ? 0 : 1;
+   data = omap_rng_read_reg(priv, RNG_STAT_REG) ? 0 : 1;
if (data || !wait)
break;
/* RNG produces data fast enough (2+ MBit/sec, even
@@ -80,9 +93,13 @@ static int omap_rng_data_present(struct hwrng *rng, int wait)
 
 static int omap_rng_data_read(struct hwrng *rng, u32 *data)
 {
-   *data = omap_rng_read_reg(RNG_OUT_REG);
+   struct omap_rng_private_data *priv;
+
+   priv = (struct omap_rng_private_data *)rng->priv;
+
+   *data = omap_rng_read_reg(priv, RNG_OUT_REG);
 
-   return 4;
+   return sizeof(u32);
 }
 
 static struct hwrng omap_rng_ops = {
@@ -93,69 +110,85 @@ static struct hwrng omap_rng_ops = {
 
 static int __devinit omap_rng_probe(struct platform_device *pdev)
 {
-   struct resource *res;
+   struct omap_rng_private_data *priv;
int ret;
 
-   /*
-* A bit ugly, and it will never actually happen but there can
-* be only one RNG and this catches any bork
-*/
-   if (rng_dev)
-   return -EBUSY;
+   priv = kzalloc(sizeof(struct omap_rng_private_data), GFP_KERNEL);
+   if (!priv) {
+   dev_err(&pdev->dev, "could not allocate memory\n");
+   return -ENOMEM;
+   };
+
+   omap_rng_ops.priv = (unsigned long)priv;
+   dev_set_drvdata(&pdev->dev, priv);
 
if (cpu_is_omap24xx()) {
-   rng_ick = clk_get(&pdev->dev, "ick");
-   if (IS_ERR(rng_ick)) {
+   priv->clk = clk_get(&pdev->dev, "ick");
+   if (IS_ERR(priv->clk)) {
dev_err(&pdev->dev, "Could not get rng_ick\n");
-   ret = PTR_ERR(rng_ick);
+   ret = PTR_ERR(priv->clk);
return ret;
-   } else
-   clk_enable(rng_ick);
+   } else {
+   clk_enable(priv->clk);
+   }
}
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   priv->mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!priv->mem_res) {
+   ret = -ENOENT;
+   goto err_ioremap;
+   }
 
-   rng_base = devm_request_and_ioremap(&pdev->dev, res);
-   if (!rng_base) {
+   priv->base = devm_request_and_ioremap(&pdev->dev, priv->mem_res);
+   if (!priv->base) {
ret = -ENOMEM;
goto err_ioremap;
}
-   dev_set_drvdata(&pdev->dev, res);
+   dev_set_drvdata(&pdev->dev, priv);
 
ret = hwrng_register(&omap_rng_ops);
if (ret)
goto err_register;
 
dev_info(&pdev->dev, "OMAP Random Number Generator ver. %02x\n",
-   omap_rng_read_reg(RNG_REV_REG));
-   omap_rng_write_reg(RNG_MASK_REG, 0x1);
+omap_rng_read_reg(priv, RNG_REV_REG));
+
 
-   rng_dev = pdev;
+   omap_rng_write_reg(priv, RNG_MASK

[PATCH 1/5] ARM: OMAP2/3: hwmod: add RNG integration data

[Paul Walmsley]

Add integration data for the hardware random number generator IP block
on some OMAP SoCs.  This appears to be present on OMAP2xxx and OMAP3xxx
SoCs, although it is not so easy to tell.  It may also be present on
other OMAP2+ SoCs.

Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 +
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 +
 .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c |   17 +
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |   37 
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |5 ++-
 5 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 50cfab6..5a53287 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -587,6 +587,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] 
__initdata = {
&omap2420_l4_core__mcbsp1,
&omap2420_l4_core__mcbsp2,
&omap2420_l4_core__msdi1,
+   &omap2xxx_l4_core__rng,
&omap2420_l4_core__hdq1w,
&omap2420_l4_wkup__counter_32k,
NULL,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 58b5bc1..256d8f6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -947,6 +947,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] 
__initdata = {
&omap2430_l4_core__mcbsp4,
&omap2430_l4_core__mcbsp5,
&omap2430_l4_core__hdq1w,
+   &omap2xxx_l4_core__rng,
&omap2430_l4_wkup__counter_32k,
NULL,
 };
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
index 5178e40..14dc5ca 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
@@ -129,6 +129,15 @@ struct omap_hwmod_addr_space omap2xxx_mcbsp2_addrs[] = {
{ }
 };
 
+static struct omap_hwmod_addr_space omap2_rng_addr_space[] = {
+   {
+   .pa_start   = 0x480a,
+   .pa_end = 0x480a004f,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
 /*
  * Common interconnect data
  */
@@ -372,3 +381,11 @@ struct omap_hwmod_ocp_if omap2xxx_l4_core__dss_venc = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_core -> rng */
+struct omap_hwmod_ocp_if omap2xxx_l4_core__rng = {
+   .master = &omap2xxx_l4_core_hwmod,
+   .slave  = &omap2xxx_rng_hwmod,
+   .clk= "l4_ck",
+   .addr   = omap2_rng_addr_space,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index afad69c..06a37db 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -745,3 +745,40 @@ struct omap_hwmod omap2xxx_counter_32k_hwmod = {
},
.class  = &omap2xxx_counter_hwmod_class,
 };
+
+/* RNG */
+
+static struct omap_hwmod_class_sysconfig omap2_rng_sysc = {
+   .rev_offs   = 0x3c,
+   .sysc_offs  = 0x40,
+   .syss_offs  = 0x44,
+   .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+  SYSS_HAS_RESET_STATUS),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2_rng_hwmod_class = {
+   .name   = "rng",
+   .sysc   = &omap2_rng_sysc,
+};
+
+static struct omap_hwmod_irq_info omap2_rng_mpu_irqs[] = {
+   { .irq = 52 },
+   { .irq = -1 }
+};
+
+struct omap_hwmod omap2xxx_rng_hwmod = {
+   .name   = "rng",
+   .mpu_irqs   = omap2_rng_mpu_irqs,
+   .main_clk   = "l4_ck",
+   .prcm   = {
+   .omap2 = {
+   .module_offs = CORE_MOD,
+   .prcm_reg_id = 4,
+   .module_bit = OMAP24XX_EN_RNG_SHIFT,
+   .idlest_reg_id = 4,
+   .idlest_idle_bit = OMAP24XX_ST_RNG_SHIFT,
+   },
+   },
+   .class  = &omap2_rng_hwmod_class,
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h 
b/arch/arm/mach-omap2/omap_hwmod_common_data.h
index e7e8eea..4363610 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
@@ -2,9 +2,8 @@
  * omap_hwmod_common_data.h - OMAP hwmod common macros and declarations
  *
  * Copyright (C) 2010-2011 Nokia Corporation
+ * Copyright (C) 2010-2012 Texas Instruments, Inc.
  * Paul Walmsley
- *
- * Copyright (C) 2010-2011 Texas Instruments, Inc.
  * Benoît Cousson
  *
  * This program is free software; you can redistribute it and/or modify
@@ -76,6 +7

Re: [PATCH] arm: omap: ratelimit omap_l3_smx error log spam

[Aaro Koskinen]

On Mon, Aug 27, 2012 at 03:12:07PM -0700, Shilimkar, Santosh wrote:
> On Mon, Aug 27, 2012 at 3:02 PM, Aaro Koskinen  wrote:
> > Hi,
> >
> > On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote:
> >> > -   pr_err("%s seen by %s %s at address %x\n",
> >> > +   pr_err_ratelimited("%s seen by %s %s at address %x\n",
> >> > omap3_l3_code_string(code),
> >> > omap3_l3_initiator_string(initid),
> >> > multi ? "Multiple Errors" : "", address);
> >> > -   WARN_ON(1);
> >> > +   WARN_ON_ONCE(1);
> >> >
> >> The issue needs to be fixed instead of WARN_ON_ONCE() and then
> >> just moving ahead. Interconnect in bad states is really bad state and you
> >> won't have reliable operations post that on SOC.
> >
> > How printing megabytes of identical stack traces helps anything?
> >
> It just says repeatedly and  loudly... Fix the issue :-)
> 
> > This has been there always (since the L3 driver was added) on every boot
> > with N950/N9 (which BTW are HS devices, not sure if that has anything
> > to do with it). There is no apparent effect on device functionality,
> > at least nothing unusual has been observed...
> >
> I assumed this is secure device when I saw the SRAM memset is causing the
> issue.
> 
> > Is there any documentation how to interpret and debug this error report?
> >
> The issue could be, there is memset tried on Secure portion of SRAM or
> CPU speculatively accessed adjacent SRAM region of public SRAM which
> is secure and hence the error.

Thanks, that makes sense.

> If you just bypass the SRAM init [1], does the issue go away ?

I tried bypassing the whole SRAM init, but the device does not seem to
boot up at all.

If I comment out the memset alone, then it boots and the issue is gone:

+#if 0
memset_io(omap_sram_base + SRAM_BOOTLOADER_SZ, 0,
  omap_sram_size - SRAM_BOOTLOADER_SZ);
+#endif

A.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] Assorted MMC / OMAP HSMMC patches

[Chris Ball]

Hi,

On Tue, Aug 21 2012, Felipe Balbi wrote:
> On Sat, Aug 18, 2012 at 12:22:20AM +0530, Venkatraman S wrote:
>> Essentially, a lot of cleanups leading up to adding a new
>> feature for OMAP HSMMC. The idea is to convert to the use
>> of software timer instead of IP timer for timekeeping, due
>> to the limitations of the counting range of the IP timer.
>> 
>> Also added myself as OMAP HSMMC maintainer.
>> 
>> Patch 9/10 is in draft state and needs more testing.
>> 
>> These patches are also available at
>>   git://github.com/svenkatr/linux.git my/mmc/3.6/hrtimer_updates
>
> other than the small comments I had to patch 9, this series looks very
> good:
>
> Acked-by: Felipe Balbi 

Thanks -- I've pushed everything except 9/10 to mmc-next for 3.7.
Venkat, please resubmit patch 9 individually whenever you're ready.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP: timer: obey the !CONFIG_OMAP_32K_TIMER

[Shilimkar, Santosh]

On Mon, Aug 27, 2012 at 3:26 PM, Igor Grinberg  wrote:
> Currently, omap2_sync32k_clocksource_init() function initializes the 32K
> timer as the system clock source regardless of the CONFIG_OMAP_32K_TIMER
> setting.
> Fix this by providing a default implementation for
> !CONFIG_OMAP_32K_TIMER case.
>
> Signed-off-by: Igor Grinberg 
> Reviewed-by: Paul Walmsley 
> ---
Acked-by: Santosh Shilimkar 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] MMC: OMAP MSDI: fix broken PIO mode

[Chris Ball]

Hi,

On Fri, Aug 24 2012, Paul Walmsley wrote:
> After commit 26b88520b80695a6fa5fd95b5d97c03f4daf87e0 ("mmc:
> omap_hsmmc: remove private DMA API implementation"), the Nokia N800
> here stopped booting:
>
> [2.086181] Waiting for root device /dev/mmcblk0p1...
> [2.324066] Unhandled fault: imprecise external abort (0x406) at 0x
> [2.331451] Internal error: : 406 [#1] ARM
> [2.335784] Modules linked in:
> [2.339050] CPU: 0Not tainted  (3.6.0-rc3 #60)
> [2.344146] PC is at default_idle+0x28/0x30
> [2.348602] LR is at trace_hardirqs_on_caller+0x15c/0x1b0
>
> ...
>
> This turned out to be due to memory corruption caused by long-broken
> PIO code in drivers/mmc/host/omap.c.  (Previously, this driver had
> been using DMA; but the above commit caused the MMC driver to fall
> back to PIO mode with an unmodified Kconfig.)
>
> The PIO code, added with the rest of the driver in commit
> 730c9b7e6630f786fcec026fb11d2e6f2c90fdcb ("[MMC] Add OMAP MMC host
> driver"), confused bytes with 16-bit words.  This bug caused memory
> located after the PIO transfer buffer to be corrupted with transfers
> larger than 32 bytes.  The driver also did not increment the buffer
> pointer after the transfer occurred.  This bug resulted in data
> corruption during any transfer larger than 64 bytes.
>
> Signed-off-by: Paul Walmsley 

Yuck.  Thanks for tracking that down, Paul -- pushed to mmc-next for 3.6.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP: timer: obey the !CONFIG_OMAP_32K_TIMER

[Igor Grinberg]

Currently, omap2_sync32k_clocksource_init() function initializes the 32K
timer as the system clock source regardless of the CONFIG_OMAP_32K_TIMER
setting.
Fix this by providing a default implementation for
!CONFIG_OMAP_32K_TIMER case.

Signed-off-by: Igor Grinberg 
Reviewed-by: Paul Walmsley 
---
 arch/arm/mach-omap2/timer.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 840929b..2cdbcc7 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -263,6 +263,7 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
 }
 
+#ifdef CONFIG_OMAP_32K_TIMER
 /* Setup free-running counter for clocksource */
 static int __init omap2_sync32k_clocksource_init(void)
 {
@@ -302,6 +303,12 @@ static int __init omap2_sync32k_clocksource_init(void)
 
return ret;
 }
+#else
+static inline int omap2_sync32k_clocksource_init(void)
+{
+   return -ENODEV;
+}
+#endif
 
 static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char *fck_source)
-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap: ratelimit omap_l3_smx error log spam

[Shilimkar, Santosh]

On Mon, Aug 27, 2012 at 3:02 PM, Aaro Koskinen  wrote:
> Hi,
>
> On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote:
>> > -   pr_err("%s seen by %s %s at address %x\n",
>> > +   pr_err_ratelimited("%s seen by %s %s at address %x\n",
>> > omap3_l3_code_string(code),
>> > omap3_l3_initiator_string(initid),
>> > multi ? "Multiple Errors" : "", address);
>> > -   WARN_ON(1);
>> > +   WARN_ON_ONCE(1);
>> >
>> The issue needs to be fixed instead of WARN_ON_ONCE() and then
>> just moving ahead. Interconnect in bad states is really bad state and you
>> won't have reliable operations post that on SOC.
>
> How printing megabytes of identical stack traces helps anything?
>
It just says repeatedly and  loudly... Fix the issue :-)

> This has been there always (since the L3 driver was added) on every boot
> with N950/N9 (which BTW are HS devices, not sure if that has anything
> to do with it). There is no apparent effect on device functionality,
> at least nothing unusual has been observed...
>
I assumed this is secure device when I saw the SRAM memset is causing the
issue.

> Is there any documentation how to interpret and debug this error report?
>
The issue could be, there is memset tried on Secure portion of SRAM or
CPU speculatively accessed adjacent SRAM region of public SRAM which
is secure and hence the error.

If you just bypass the SRAM init [1], does the issue go away ?

Regards
Santosh

[1]
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 766181c..305e6de 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -384,6 +384,7 @@ static inline int am33xx_sram_init(void)

 int __init omap_sram_init(void)
 {
+#if 0
omap_detect_sram();
omap_map_sram();

@@ -397,6 +398,6 @@ int __init omap_sram_init(void)
am33xx_sram_init();
else if (cpu_is_omap34xx())
omap34xx_sram_init();
-
+#endif
return 0;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ASoC: ams-delta: fix card initalization failure

[Janusz Krzysztofik]

Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d, 'device-core:
Ensure drvdata = NULL when no driver is bound', the Amstrad Delta sound
card no longer initializes correctly due to drvdata reset to NULL by an
upper layer before the codec device, required for successful card setup,
is registered. Fix this by moving the codec registration bits up, before
the card is probed for.

Created and tested against linux-3.6-rc3

Signed-off-by: Janusz Krzysztofik 
---
 sound/soc/omap/ams-delta.c |   18 ++
 1 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index 7d4fa8e..270de9c 100644
--- a/sound/soc/omap/ams-delta.c
+++ b/sound/soc/omap/ams-delta.c
@@ -590,20 +590,22 @@ static int __init ams_delta_module_init(void)
if (!ams_delta_audio_platform_device)
return -ENOMEM;
 
-   platform_set_drvdata(ams_delta_audio_platform_device,
-   &ams_delta_audio_card);
-
-   ret = platform_device_add(ams_delta_audio_platform_device);
-   if (ret)
-   goto err;
-
/*
 * Codec platform device could be registered from elsewhere (board?),
 * but I do it here as it makes sense only if used with the card.
+* Moreover, it must be registered before the card is probed for,
+* or the card setup fails due to drvdata reset by upper layers.
 */
cx20442_platform_device =
platform_device_register_simple("cx20442-codec", -1, NULL, 0);
-   return 0;
+
+   platform_set_drvdata(ams_delta_audio_platform_device,
+&ams_delta_audio_card);
+
+   ret = platform_device_add(ams_delta_audio_platform_device);
+   if (!ret)
+   return ret;
+
 err:
platform_device_put(ams_delta_audio_platform_device);
return ret;
-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap: ratelimit omap_l3_smx error log spam

[Aaro Koskinen]

Hi,

On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote:
> > -   pr_err("%s seen by %s %s at address %x\n",
> > +   pr_err_ratelimited("%s seen by %s %s at address %x\n",
> > omap3_l3_code_string(code),
> > omap3_l3_initiator_string(initid),
> > multi ? "Multiple Errors" : "", address);
> > -   WARN_ON(1);
> > +   WARN_ON_ONCE(1);
> >
> The issue needs to be fixed instead of WARN_ON_ONCE() and then
> just moving ahead. Interconnect in bad states is really bad state and you
> won't have reliable operations post that on SOC.

How printing megabytes of identical stack traces helps anything?

This has been there always (since the L3 driver was added) on every boot
with N950/N9 (which BTW are HS devices, not sure if that has anything
to do with it). There is no apparent effect on device functionality,
at least nothing unusual has been observed...

Is there any documentation how to interpret and debug this error report?

A.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ASoC: ams-delta: fix card initalization failure

[Mark Brown]

On Mon, Aug 27, 2012 at 11:28:30PM +0200, Janusz Krzysztofik wrote:

> - platform_set_drvdata(ams_delta_audio_platform_device,
> - &ams_delta_audio_card);
> -
> - ret = platform_device_add(ams_delta_audio_platform_device);
> - if (ret)
> - goto err;

The real fix here is that you should be using platform data here, not
driver data.  Is there some reason not to do that?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap: ratelimit omap_l3_smx error log spam

[Shilimkar, Santosh]

On Mon, Aug 27, 2012 at 2:03 PM, Aaro Koskinen  wrote:
>
> When booting kernel on RM-680/N950, the console is flooded with:
>
> [6.894348] In-band Error seen by MPU  at address 0
> [6.894348] [ cut here ]
> [6.894378] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162
> omap3_l3_app_irq+0xd4/0x12c()
> [6.894378] Modules linked in:
> [6.894409] Backtrace:
> [6.894409] [] (dump_backtrace+0x0/0x10c) from []
> (dump_stack+0x18/0x1c)
> [6.894439]  r6:c002de58 r5:0009 r4: r3:c0880180
> [6.894470] [] (dump_stack+0x0/0x1c) from []
> (warn_slowpath_common+0x54/0x6c)
> [6.894500] [] (warn_slowpath_common+0x0/0x6c) from
> [] (warn_slowpath_null+0x24/0x2c)
> [6.894500]  r8:000a r7: r6:f8001400 r5:
> r4:84001b00
> [6.894500] r3:0009
> [6.894561] [] (warn_slowpath_null+0x0/0x2c) from
> [] (omap3_l3_app_irq+0xd4/0x12c)
> [6.894561] [] (omap3_l3_app_irq+0x0/0x12c) from []
> (handle_irq_event_percpu+0x54/0x19c)
> [6.894592]  r7: r6: r5:c082c710 r4:ef072340
> [6.894622] [] (handle_irq_event_percpu+0x0/0x19c) from
> [] (handle_irq_event+0x60/0x80)
> [6.894653] [] (handle_irq_event+0x0/0x80) from []
> (handle_level_irq+0xb4/0x134)
> [6.894653]  r5:c082c710 r4:c082c6c0
> [6.894683] [] (handle_level_irq+0x0/0x134) from []
> (generic_handle_irq+0x2c/0x44)
> [6.894683]  r6:ef02c000 r5:c0829014 r4:c0841e18 r3:c008824c
> [6.894744] [] (generic_handle_irq+0x0/0x44) from
> [] (handle_IRQ+0x54/0xb8)
> [6.894744] [] (handle_IRQ+0x0/0xb8) from []
> (omap3_intc_handle_irq+0x68/0x7c)
> [6.894775]  r8:c08415cc r7:000a r6:c0898c38 r5:ef02de88
> r4:fa20
> [6.894775] r3:
> [6.894805] [] (omap3_intc_handle_irq+0x0/0x7c) from
> [] (__irq_svc+0x40/0x54)
> [6.894836] Exception stack(0xef02de88 to 0xef02ded0)
> [6.894836] de80:   f0048000  7000 
>  3035 f004bfca
> [6.894866] dea0:   c08415cc c0898140 ef02c000 ef02def4
> ef02 def8 ef02ded0
> [6.894866] dec0: c042b1dc c0016efc 2013 
> [6.894897]  r7:ef02debc r6: r5:2013 r4:c0016efc
> [6.894927] [] (_memset_io+0x0/0x50) from []
> (omap_sram_init+0x228/0x56c)
> [6.894927]  r8:c0445cf4 r7:c0417208 r6:c0898140 r5:c0899840
> r4:c0899a3c
> [6.894927] r3:f004f000
> [6.894989] [] (omap_sram_init+0x0/0x56c) from []
> (omap_sdrc_init+0x18/0xb8)
> [6.894989]  r6:c0898140 r5:c0899840 r4:c0899840 r3:0005e601
> [6.895019] [] (omap_sdrc_init+0x0/0xb8) from []
> (rm680_init+0x34/0xc0)
> [6.895050]  r5:c04518e0 r4:c0875da0
> [6.895080] [] (rm680_init+0x0/0xc0) from []
> (customize_machine+0x24/0x30)
> [6.895080]  r5:0003 r4:
> [6.895111] [] (customize_machine+0x0/0x30) from []
> (do_one_initcall+0x11c/0x184)
> [6.895141] [] (do_one_initcall+0x0/0x184) from []
> (kernel_init+0x100/0x1c4)
> [6.895141] [] (kernel_init+0x0/0x1c4) from []
> (do_exit+0x0/0x794)
> [6.895172] ---[ end trace 1b75b31a271a0d00 ]---
>
> This is repeated maybe a thousand times. While the root cause remains
> unknown (they seem to occur during SDRC and DMA init), the errors should
> be at least ratelimited so that user will also have chance to see other
> boot messages.
>
> Signed-off-by: Aaro Koskinen 
> ---
>  arch/arm/mach-omap2/omap_l3_smx.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_l3_smx.c
> b/arch/arm/mach-omap2/omap_l3_smx.c
> index acc2164..e3b4948 100644
> --- a/arch/arm/mach-omap2/omap_l3_smx.c
> +++ b/arch/arm/mach-omap2/omap_l3_smx.c
> @@ -155,11 +155,11 @@ static irqreturn_t omap3_l3_block_irq(struct
> omap3_l3 *l3,
> u8 multi = error & L3_ERROR_LOG_MULTI;
> u32 address = omap3_l3_decode_addr(error_addr);
>
> -   pr_err("%s seen by %s %s at address %x\n",
> +   pr_err_ratelimited("%s seen by %s %s at address %x\n",
> omap3_l3_code_string(code),
> omap3_l3_initiator_string(initid),
> multi ? "Multiple Errors" : "", address);
> -   WARN_ON(1);
> +   WARN_ON_ONCE(1);
>
The issue needs to be fixed instead of WARN_ON_ONCE() and then
just moving ahead. Interconnect in bad states is really bad state and you
won't have reliable operations post that on SOC.

Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] arm: omap: ratelimit omap_l3_smx error log spam

[Aaro Koskinen]

When booting kernel on RM-680/N950, the console is flooded with:

[6.894348] In-band Error seen by MPU  at address 0
[6.894348] [ cut here ]
[6.894378] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162 
omap3_l3_app_irq+0xd4/0x12c()
[6.894378] Modules linked in:
[6.894409] Backtrace:
[6.894409] [] (dump_backtrace+0x0/0x10c) from [] 
(dump_stack+0x18/0x1c)
[6.894439]  r6:c002de58 r5:0009 r4: r3:c0880180
[6.894470] [] (dump_stack+0x0/0x1c) from [] 
(warn_slowpath_common+0x54/0x6c)
[6.894500] [] (warn_slowpath_common+0x0/0x6c) from [] 
(warn_slowpath_null+0x24/0x2c)
[6.894500]  r8:000a r7: r6:f8001400 r5: r4:84001b00
[6.894500] r3:0009
[6.894561] [] (warn_slowpath_null+0x0/0x2c) from [] 
(omap3_l3_app_irq+0xd4/0x12c)
[6.894561] [] (omap3_l3_app_irq+0x0/0x12c) from [] 
(handle_irq_event_percpu+0x54/0x19c)
[6.894592]  r7: r6: r5:c082c710 r4:ef072340
[6.894622] [] (handle_irq_event_percpu+0x0/0x19c) from 
[] (handle_irq_event+0x60/0x80)
[6.894653] [] (handle_irq_event+0x0/0x80) from [] 
(handle_level_irq+0xb4/0x134)
[6.894653]  r5:c082c710 r4:c082c6c0
[6.894683] [] (handle_level_irq+0x0/0x134) from [] 
(generic_handle_irq+0x2c/0x44)
[6.894683]  r6:ef02c000 r5:c0829014 r4:c0841e18 r3:c008824c
[6.894744] [] (generic_handle_irq+0x0/0x44) from [] 
(handle_IRQ+0x54/0xb8)
[6.894744] [] (handle_IRQ+0x0/0xb8) from [] 
(omap3_intc_handle_irq+0x68/0x7c)
[6.894775]  r8:c08415cc r7:000a r6:c0898c38 r5:ef02de88 r4:fa20
[6.894775] r3:
[6.894805] [] (omap3_intc_handle_irq+0x0/0x7c) from [] 
(__irq_svc+0x40/0x54)
[6.894836] Exception stack(0xef02de88 to 0xef02ded0)
[6.894836] de80:   f0048000  7000   
3035 f004bfca
[6.894866] dea0:   c08415cc c0898140 ef02c000 ef02def4 ef02 
def8 ef02ded0
[6.894866] dec0: c042b1dc c0016efc 2013 
[6.894897]  r7:ef02debc r6: r5:2013 r4:c0016efc
[6.894927] [] (_memset_io+0x0/0x50) from [] 
(omap_sram_init+0x228/0x56c)
[6.894927]  r8:c0445cf4 r7:c0417208 r6:c0898140 r5:c0899840 r4:c0899a3c
[6.894927] r3:f004f000
[6.894989] [] (omap_sram_init+0x0/0x56c) from [] 
(omap_sdrc_init+0x18/0xb8)
[6.894989]  r6:c0898140 r5:c0899840 r4:c0899840 r3:0005e601
[6.895019] [] (omap_sdrc_init+0x0/0xb8) from [] 
(rm680_init+0x34/0xc0)
[6.895050]  r5:c04518e0 r4:c0875da0
[6.895080] [] (rm680_init+0x0/0xc0) from [] 
(customize_machine+0x24/0x30)
[6.895080]  r5:0003 r4:
[6.895111] [] (customize_machine+0x0/0x30) from [] 
(do_one_initcall+0x11c/0x184)
[6.895141] [] (do_one_initcall+0x0/0x184) from [] 
(kernel_init+0x100/0x1c4)
[6.895141] [] (kernel_init+0x0/0x1c4) from [] 
(do_exit+0x0/0x794)
[6.895172] ---[ end trace 1b75b31a271a0d00 ]---

This is repeated maybe a thousand times. While the root cause remains
unknown (they seem to occur during SDRC and DMA init), the errors should
be at least ratelimited so that user will also have chance to see other
boot messages.

Signed-off-by: Aaro Koskinen 
---
 arch/arm/mach-omap2/omap_l3_smx.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_l3_smx.c 
b/arch/arm/mach-omap2/omap_l3_smx.c
index acc2164..e3b4948 100644
--- a/arch/arm/mach-omap2/omap_l3_smx.c
+++ b/arch/arm/mach-omap2/omap_l3_smx.c
@@ -155,11 +155,11 @@ static irqreturn_t omap3_l3_block_irq(struct omap3_l3 *l3,
u8 multi = error & L3_ERROR_LOG_MULTI;
u32 address = omap3_l3_decode_addr(error_addr);
 
-   pr_err("%s seen by %s %s at address %x\n",
+   pr_err_ratelimited("%s seen by %s %s at address %x\n",
omap3_l3_code_string(code),
omap3_l3_initiator_string(initid),
multi ? "Multiple Errors" : "", address);
-   WARN_ON(1);
+   WARN_ON_ONCE(1);
 
return IRQ_HANDLED;
 }
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 07/10] ARM: OMAP2+: gpmc: generic timing calculation

[Jon Hunter]

Hi Afzal,

On 08/27/2012 05:37 AM, Mohammed, Afzal wrote:
> On Thu, Aug 23, 2012 at 08:28:44, Hunter, Jon wrote:

[snip]

>> I understand that this is based upon how timings for onenand and tusb
>> are being calculated today, but I am not sure that this is the way to go
>> for all devices. Personally, I would like to see us get away from how
>> those devices are calculating timings for any new device.
> 
> You cannot do away with many of the those, as logically they
> are right. Eg. read data should be available at access time,
> assuming a zero data hold time, we can very well derive an
> expression as,

I am not saying that we do away with them for current devices, just
maintain them as is.

> read de-assertion time (oe_off) = access time plus 1 gpmc clock,
> 
> and this is what the existing calculations do, and also the
> generic routine. There could be other constraints, but this
> certainly should be one (I do realize that oe_off could be
> optimized to be less than access time, by relying on read
> hold time, then again effect of it would be in similar way
> for different peripherals, but let's forget about
> optimization in the beginning)
> 
>> In general, I am concerned that we are abstracting the timings further
>> from the actual register fields. For example, the timings parameter
>> "t_ceasu" is described "address setup to CS valid" which is not
>> incorrect but this value is really just programming the CSONTIME field
>> and so why not call this cs_on?
> 
> Timing fields of struct gpmc_device_timings are selected such
> that they should be bindable by DT. At least one of the peripheral
> datasheet has these fields.

Right, but these are not applicable to every device and so I worry this
could be confusing. However, more documentation may help clear this up.

> If user knows timings in terms of
> gpmc values, he can directly use struct gpmc_timings, but
> then all the values should be updated in struct gpmc_timings.
> User should not update some of the values in terms of
> peripheral timings, others in terms of gpmc timings, that
> would make things complex and does not seem the right way
> to me.
> 
> cs_on and other gpmc aware timings could be binded by DT, not as
> peripheral timing, but as gpmc timing.
> 
> Bindings for peripheral DT timings should be something that
> can be obtained from peripheral datasheet, here accidentally
> it is same as gpmc timings, but not most timings are this way.
> Also there could be other constraints that can come for cs_on,
> even though I have not come across any till now.
> 
>>
>> So although this may consolidate how the timings are calculated today, I
>> am concerned it will be confusing to add timings for a new device. At
>> least if I am calculating timings, I am taking the timing information
>> for the device and translating that to the how I need to program the
>> gpmc register fields.
> 
> If I am not wrong, GPMC IP has been present for around a
> decade, and so far I have not come across any generic time
> calculation method that can be applied to all peripherals.

Yes not an easy problem to solve :-(

> Getting to work same peripheral for a different gpmc
> frequency is another problem.
> 
> Here we are trying to generalize based on the understanding of
> gpmc & peripheral timings, as well as by a kind of reverse
> engineering without most of the hardware or datasheet. Think of
> this as an attempt to create one, let it evolve and become a
> robust one. If a new user want to add a peripheral, let him add
> support, input timings are selected such that it is found in
> peripheral datasheet, if that does not work, let him try
> to add any new timing field or alter existing expression
> as he deems to be proper and verify that it does not break
> others. And I can help provided I am not heavily loaded
> with other works.

So long as it is maintainable ;-)

> And at least for initial users, they are expected to have
> some grasp on how to calculate timings, such a user will
> not be much worried about your 3 concerns above, anyway as
> of now they need to have a good grasp on it.

I would consider myself to be an initial user and I am concerned,
doesn't that count?

An example, would be the following where you have 4 timing parameters
for access time. You need to dig through the code to understand how
these are being used.

+   u32 t_aa;   /* access time from ADV assertion */
+   u32 t_iaa;  /* initial access time */
+   u32 t_oe;   /* access time from OE assertion */
+   u32 t_ce;   /* access time from CS asertion */

> Meanwhile I will try to document more.

Yes more documentation is definitely needed.

Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?

[Mark Brown]

On Fri, Aug 24, 2012 at 12:40:37PM +0530, Arun Raghavan wrote:

> It's been in shambles for an absurdly long time. Would be good to
> actually try to tackle it again at Plumbers or sth.

I think all this really needs is someone with the time to do the work -
it's more a coding problem with unifying the in kernel API than an issue
with working out what to do.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] ARM: AM33XX: clock: Add dcan clock aliases for device-tree

[Hiremath, Vaibhav]

On Tue, Aug 28, 2012 at 00:06:45, Paul Walmsley wrote:
> On Mon, 27 Aug 2012, Hiremath, Vaibhav wrote:
> 
> > On Mon, Aug 27, 2012 at 22:50:12, Paul Walmsley wrote:
> >
> > > Is the dcan driver present in v3.6-rc kernels?  
> > 
> > Multiple versions have been submitted already, I have validated using them.
> > Irrespective of this, it is independent change and required for the driver.
> 
> OK, will queue it for 3.7.
> 

Thanks Paul.

Thanks,
Vaibhav

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] ARM: AM33XX: clock: Add dcan clock aliases for device-tree

[Paul Walmsley]

On Mon, 27 Aug 2012, Hiremath, Vaibhav wrote:

> On Mon, Aug 27, 2012 at 22:50:12, Paul Walmsley wrote:
>
> > Is the dcan driver present in v3.6-rc kernels?  
> 
> Multiple versions have been submitted already, I have validated using them.
> Irrespective of this, it is independent change and required for the driver.

OK, will queue it for 3.7.

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] ARM: AM33XX: clock: Add dcan clock aliases for device-tree

[Hiremath, Vaibhav]

On Mon, Aug 27, 2012 at 22:50:12, Paul Walmsley wrote:
> Hi
> 
> On Mon, 27 Aug 2012, Vaibhav Hiremath wrote:
> 
> > Currently, the device names for the dcan module follows the
> > format "dcan.X", where 'X' is the dcan instance number.
> > On other side, driver may request for clock with/without con_id
> > and dev_id, and it is expected that platform should respect this
> > request and return the requested clock handle.
> > 
> > Now, when using device tree, the format of the device name created
> > by OF layer is different, ".",
> > assuming that the device-tree "reg" property is specified.
> > This causes the look-up failure for clock node in dcan driver
> > 
> > To fix this add new dcan clock alias for using device-tree.
> 
> Is the dcan driver present in v3.6-rc kernels?  

Multiple versions have been submitted already, I have validated using them.
Irrespective of this, it is independent change and required for the driver.

Thanks,
Vaibhav

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: AM33XX: clock: Add dcan clock aliases for device-tree

[Paul Walmsley]

Hi

On Mon, 27 Aug 2012, Vaibhav Hiremath wrote:

> Currently, the device names for the dcan module follows the
> format "dcan.X", where 'X' is the dcan instance number.
> On other side, driver may request for clock with/without con_id
> and dev_id, and it is expected that platform should respect this
> request and return the requested clock handle.
> 
> Now, when using device tree, the format of the device name created
> by OF layer is different, ".",
> assuming that the device-tree "reg" property is specified.
> This causes the look-up failure for clock node in dcan driver
> 
> To fix this add new dcan clock alias for using device-tree.

Is the dcan driver present in v3.6-rc kernels?  Doesn't look like it but 
maybe it's under an alias.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2+: am33xx: Fix the timer fck clock naming convention

[Paul Walmsley]

On Mon, 16 Jul 2012, Vaibhav Hiremath wrote:

> With commit ae6df418a21f3a361c5f9b878e32a8aba4e17692
> Sub: ARM: OMAP2+: dmtimer: cleanup fclk usage)
> The Timer functional clock naming convention has changed from
> gptX_fck => timerXfck, and so as the timer init function
> in mach-omap2/timer.c.
> OMAP4 clocktree also has changed accordingly.
> 
> AM33xx Clock Tree has been merged during rc3-4 timeframe,
> before above commit got merged, so similar change is required
> for AM33xx as well (Change the gptX_fck => timerX_fck).
> 
> Signed-off-by: Vaibhav Hiremath 

Thanks, queued for v3.6-rc.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] arm/dts: regulator: Add tps65910 device tree data

[Mark Brown]

On Fri, Aug 24, 2012 at 01:16:34PM -0700, Tony Lindgren wrote:
> * Mark Brown  [120821 11:09]:

> > The board shouldn't have to define the regulators, the regulator driver
> > really ought to be able to figure out that they're there by itself if
> > there's no configuration based purely on knowing which chip is there.
> > From that point of view it's OK for the chip .dtsi to have them (though
> > ideally the driver wouldn't *need* that either) which was what was
> > happening here.

> So I assume no changes needed here then?

Seems that way.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v6 00/10] OMAP-GPMC: generic time calc, prepare for driver

[Mohammed, Afzal]

Hi Daniel,

On Mon, Aug 27, 2012 at 19:00:32, Daniel Mack wrote:

> So the GPMC driver is the one that is matched from DT, and the NAND
> driver will the be instanciated from the (generic) GPMC driver?

I think you were referring to nand device being instantiated from
gpmc driver?, hence resulting in nand driver getting probed. What I
have in mind is to represent peripherals connected to gpmc as childs
of gpmc node. For devices like smsc911x, as they already have DT
bindings, creating an of device for childs by parsing DT hopefully
should relieve task of handling their platform data.

Similarly for nand, creating an of device is to be done by gpmc
driver.

Once the bigger issue of timing is resolved, I am planning to
implement DT as said above

Also for the existing boards on non-DT boot, plan is to keep the
existing interface as such, with no change needed in board files.

> 
> > No change would be needed for client drivers like smc91x ethernet drivers,
> > but NAND driver may need some change to live with DT as it is tightly
> > coupled with GPMC.
> 
> NAND drivers also typically parse partition entries that are children of
> the DT node the are owning.

Yes, in addition to the above, omap nand driver would need to determine a
few gpmc specific like transfer mode.

> I do have a beaglboard xM, but the board I'm currently working with is a
> custom one based on an AM33xx.

I was in need of a board like rx51, n800 that currently calculate gpmc
timings at runtime to test the generic timing function, np, thanks again

Regards
Afzal
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 00/10] OMAP-GPMC: generic time calc, prepare for driver

[Daniel Mack]

On 27.08.2012 14:38, Mohammed, Afzal wrote:
> On Mon, Aug 27, 2012 at 17:46:17, Daniel Mack wrote:
> 
>>> Such a generic routine would help create a driver out of gpmc platform
>>> code, which would be peripheral agnostic and thus lead to DT finally.
>>> Input to generic timing calculation routine would be gpmc peripheral
>>> timings, output - translated timings that gpmc can understand. Later,
>>> to DT'ify, gpmc peripheral timings could be passed through DT. Input
>>> timings that has been used here are selected such that it represents
>>> those that are present in peripheral timing datasheets.
>>
>> What I don't understand yet about this new approach is where the gpmc
>> client code should live in. In order to probe the drivers via DT, each
>> driver would need to call the gpmc support functions itself, right? Is
> 
> By gpmc client code, if you are referring to helper functions in
> mach-omap2/gpmc-*, if things go as per plan, with DT, they will go away
> and gpmc driver would handle those based on the information from DT.

So the GPMC driver is the one that is matched from DT, and the NAND
driver will the be instanciated from the (generic) GPMC driver?

> No change would be needed for client drivers like smc91x ethernet drivers,
> but NAND driver may need some change to live with DT as it is tightly
> coupled with GPMC.

NAND drivers also typically parse partition entries that are children of
the DT node the are owning.

>> the plan to obsolete helper functions like gpmc_nand_init() and move
>> that functionality to the drivers?
> 
> Yes, plan is to obsolete the functions like gpmc_nand_init, those tasks
> would be handled by gpmc driver
> 
>>
>> I applied these patches locally and would like to help get the NAND
>> controller on my AX33xx DT-driven board going. Let me know if I can do
>> anything here.
> 
> Thanks for offering the help, will take liberty to ask you for help
> when required. BTW, do you have any OMAP family boards ?

I do have a beaglboard xM, but the board I'm currently working with is a
custom one based on an AM33xx.


Thanks,
Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v6 00/10] OMAP-GPMC: generic time calc, prepare for driver

[Mohammed, Afzal]

Hi Daniel,

On Mon, Aug 27, 2012 at 17:46:17, Daniel Mack wrote:

> > Such a generic routine would help create a driver out of gpmc platform
> > code, which would be peripheral agnostic and thus lead to DT finally.
> > Input to generic timing calculation routine would be gpmc peripheral
> > timings, output - translated timings that gpmc can understand. Later,
> > to DT'ify, gpmc peripheral timings could be passed through DT. Input
> > timings that has been used here are selected such that it represents
> > those that are present in peripheral timing datasheets.
> 
> What I don't understand yet about this new approach is where the gpmc
> client code should live in. In order to probe the drivers via DT, each
> driver would need to call the gpmc support functions itself, right? Is

By gpmc client code, if you are referring to helper functions in
mach-omap2/gpmc-*, if things go as per plan, with DT, they will go away
and gpmc driver would handle those based on the information from DT.

No change would be needed for client drivers like smc91x ethernet drivers,
but NAND driver may need some change to live with DT as it is tightly
coupled with GPMC.

> the plan to obsolete helper functions like gpmc_nand_init() and move
> that functionality to the drivers?

Yes, plan is to obsolete the functions like gpmc_nand_init, those tasks
would be handled by gpmc driver

> 
> I applied these patches locally and would like to help get the NAND
> controller on my AX33xx DT-driven board going. Let me know if I can do
> anything here.

Thanks for offering the help, will take liberty to ask you for help
when required. BTW, do you have any OMAP family boards ?

Regards
Afzal
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] arm/dts: AM33XX: Specify reg and interrupt property for all nodes

[Vaibhav Hiremath]

The device/node resources (like, IORESOURCE_MEM and IORESOURCE_IRQ)
are overwritten by hwmod resources, due to all known reasons but
that should not be the reason for not providing all the information
in the DTS blob. Ideally we should use DTS resource and use HWMOD
framework wherever required and for only specific things.

Newer platforms like, OMAP5 and AM33XX, we only support DT boot mode,
so this patch is preparation for the future where we supposed to get
rid of hwmod dependency anyway.

Signed-off-by: Vaibhav Hiremath 
Cc: Tony Lindgren 
Cc: Benoit Cousson 
---
 arch/arm/boot/dts/am33xx.dtsi |   42 +
 1 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index be43511..f0642e1 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -69,6 +69,9 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
+   reg = <0x44e07000 0x1000>;
+   interrupt-parent = <&intc>;
+   interrupts = <96>;
};
 
gpio2: gpio@4804c000 {
@@ -78,6 +81,9 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
+   reg = <0x4804c000 0x1000>;
+   interrupt-parent = <&intc>;
+   interrupts = <98>;
};
 
gpio3: gpio@481ac000 {
@@ -87,6 +93,9 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
+   reg = <0x481ac000 0x1000>;
+   interrupt-parent = <&intc>;
+   interrupts = <32>;
};
 
gpio4: gpio@481ae000 {
@@ -96,12 +105,18 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
+   reg = <0x481ae000 0x1000>;
+   interrupt-parent = <&intc>;
+   interrupts = <62>;
};
 
uart1: serial@44e09000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart1";
clock-frequency = <4800>;
+   reg = <0x44e09000 0x2000>;
+   interrupt-parent = <&intc>;
+   interrupts = <72>;
status = "disabled";
};
 
@@ -109,6 +124,9 @@
compatible = "ti,omap3-uart";
ti,hwmods = "uart2";
clock-frequency = <4800>;
+   reg = <0x48022000 0x2000>;
+   interrupt-parent = <&intc>;
+   interrupts = <73>;
status = "disabled";
};
 
@@ -116,6 +134,9 @@
compatible = "ti,omap3-uart";
ti,hwmods = "uart3";
clock-frequency = <4800>;
+   reg = <0x48024000 0x2000>;
+   interrupt-parent = <&intc>;
+   interrupts = <74>;
status = "disabled";
};
 
@@ -123,6 +144,9 @@
compatible = "ti,omap3-uart";
ti,hwmods = "uart4";
clock-frequency = <4800>;
+   reg = <0x481a6000 0x2000>;
+   interrupt-parent = <&intc>;
+   interrupts = <44>;
status = "disabled";
};
 
@@ -130,6 +154,9 @@
compatible = "ti,omap3-uart";
ti,hwmods = "uart5";
clock-frequency = <4800>;
+   reg = <0x481a8000 0x2000>;
+   interrupt-parent = <&intc>;
+   interrupts = <45>;
status = "disabled";
};
 
@@ -137,6 +164,9 @@
compatible = "ti,omap3-uart";
ti,hwmods = "uart6";
clock-frequency = <4800>;
+   reg = <0x481aa000 0x2000>;
+   interrupt-parent = <&intc>;
+   interrupts = <46>;
status = "disabled";
};
 
@@ -145,6 +175,9 @@
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
+   reg = <0x44e0b000 0x1000>;
+   interrupt-parent = <&intc>;
+   interrupts = <70>;
status = "disabled";
};
 
@@ -153,6 +1

[PATCH 1/2] arm/dts: AM33XX: Convert all hex numbers to lower-case

[Vaibhav Hiremath]

To make it consistent, convert all hex number presentation
to lower-case from all am33xx specific nodes.

Signed-off-by: Vaibhav Hiremath 
Cc: Tony Lindgren 
---
 arch/arm/boot/dts/am335x-bone.dts |2 +-
 arch/arm/boot/dts/am335x-evm.dts  |2 +-
 arch/arm/boot/dts/am33xx.dtsi |   20 ++--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-bone.dts 
b/arch/arm/boot/dts/am335x-bone.dts
index a7906cb..c64f7fa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -19,7 +19,7 @@
};
 
ocp {
-   uart1: serial@44E09000 {
+   uart1: serial@44e09000 {
status = "okay";
};
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 5dd8a6b..8963f20 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -19,7 +19,7 @@
};
 
ocp {
-   uart1: serial@44E09000 {
+   uart1: serial@44e09000 {
status = "okay";
};
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index dde76f7..be43511 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -71,7 +71,7 @@
#interrupt-cells = <1>;
};
 
-   gpio2: gpio@4804C000 {
+   gpio2: gpio@4804c000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio2";
gpio-controller;
@@ -80,7 +80,7 @@
#interrupt-cells = <1>;
};
 
-   gpio3: gpio@481AC000 {
+   gpio3: gpio@481ac000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio3";
gpio-controller;
@@ -89,7 +89,7 @@
#interrupt-cells = <1>;
};
 
-   gpio4: gpio@481AE000 {
+   gpio4: gpio@481ae000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio4";
gpio-controller;
@@ -98,7 +98,7 @@
#interrupt-cells = <1>;
};
 
-   uart1: serial@44E09000 {
+   uart1: serial@44e09000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart1";
clock-frequency = <4800>;
@@ -119,28 +119,28 @@
status = "disabled";
};
 
-   uart4: serial@481A6000 {
+   uart4: serial@481a6000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart4";
clock-frequency = <4800>;
status = "disabled";
};
 
-   uart5: serial@481A8000 {
+   uart5: serial@481a8000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart5";
clock-frequency = <4800>;
status = "disabled";
};
 
-   uart6: serial@481AA000 {
+   uart6: serial@481aa000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart6";
clock-frequency = <4800>;
status = "disabled";
};
 
-   i2c1: i2c@44E0B000 {
+   i2c1: i2c@44e0b000 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
@@ -148,7 +148,7 @@
status = "disabled";
};
 
-   i2c2: i2c@4802A000 {
+   i2c2: i2c@4802a000 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
@@ -156,7 +156,7 @@
status = "disabled";
};
 
-   i2c3: i2c@4819C000 {
+   i2c3: i2c@4819c000 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] arm/dts: AM33XX: Add reg and interrupt property for all nodes

[Vaibhav Hiremath]

This series is trivial patch-series and should be considered as
preparation for the future where we supposed to get rid of
hwmod dependency.

1/2: Converts all hex numbers to lowercase, fixing inconsistency
2/2: Add reg and interrupt property  to all device/module nodes inside
 DTS files. 

Although currently hwmod overwrites resources, I have validated this
patch series by changing the omap_device layer to respect DT resources
and boot Tested on BeagleBone platform.
I will be submitting the changes for omap_device layer as well, still
needs to fix on certain things.

Vaibhav Hiremath (2):
  arm/dts: AM33XX: Convert all hex numbers to lower-case
  arm/dts: AM33XX: Specify reg and interrupt property for all nodes

 arch/arm/boot/dts/am335x-bone.dts |2 +-
 arch/arm/boot/dts/am335x-evm.dts  |2 +-
 arch/arm/boot/dts/am33xx.dtsi |   62 +++--
 3 files changed, 54 insertions(+), 12 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 00/10] OMAP-GPMC: generic time calc, prepare for driver

[Daniel Mack]

Hi Afzal,

On 21.08.2012 12:41, Afzal Mohammed wrote:
> This series provides a generic gpmc timing calculation routine. There
> were three peripherals (OneNAND, tusb6010, smc91x) using custom timing
> calculations, they are migrated to use the generic timing calculation.
> 
> Such a generic routine would help create a driver out of gpmc platform
> code, which would be peripheral agnostic and thus lead to DT finally.
> Input to generic timing calculation routine would be gpmc peripheral
> timings, output - translated timings that gpmc can understand. Later,
> to DT'ify, gpmc peripheral timings could be passed through DT. Input
> timings that has been used here are selected such that it represents
> those that are present in peripheral timing datasheets.

What I don't understand yet about this new approach is where the gpmc
client code should live in. In order to probe the drivers via DT, each
driver would need to call the gpmc support functions itself, right? Is
the plan to obsolete helper functions like gpmc_nand_init() and move
that functionality to the drivers?

I applied these patches locally and would like to help get the NAND
controller on my AX33xx DT-driven board going. Let me know if I can do
anything here.


Regards,
Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v6 07/10] ARM: OMAP2+: gpmc: generic timing calculation

[Mohammed, Afzal]

Hi Tony,

On Sat, Aug 25, 2012 at 01:24:47, Tony Lindgren wrote:

> Yes agreed. Also as some values make sense only in cycles, converting them
> back and forth to time is wrong. So at least some values should have an
> option to specify them in cycles directly, and then ignore any time based
> values.

Which values in struct gpmc_device_timings are you referring to ?

Values that need to have an option to specify in cycles has been provided
such an option, while not updating time based field value, you can
achieve what you mentioned above. But if you want that to be handled in
in generic routine, I will do so.

Regards
Afzal
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 7/8] ir-rx51: Convert latency constraints to PM QoS API

[Timo Kokkonen]

On 08/27/12 12:25, Jean Pihet wrote:
> Hi Timo,
> 
> On Fri, Aug 24, 2012 at 10:39 PM, Tony Lindgren  wrote:
>> * Timo Kokkonen  [120824 08:11]:
>>> Convert the driver from the obsolete omap_pm_set_max_mpu_wakeup_lat
>>> API to the new PM QoS API. This allows the callback to be removed from
>>> the platform data structure.
>>>
>>> The latency requirements are also adjusted to prevent the MPU from
>>> going into sleep mode. This is needed as the GP timers have no means
>>> to wake up the MPU once it has gone into sleep. The "side effect" is
>>> that from now on the driver actually works even if there is no
>>> background load keeping the MPU awake.
>>>
>>> Signed-off-by: Timo Kokkonen 
>>
>> This should get acked by Kevin ideally. Other than that:
>>
>> Acked-by: Tony Lindgren 
> 
> ...
> @@ -268,10 +270,14 @@ static ssize_t lirc_rx51_write(struct file
> *file, const char *buf,
> lirc_rx51->wbuf[count] = -1; /* Insert termination mark */
> 
> /*
> -* Adjust latency requirements so the device doesn't go in too
> -* deep sleep states
> +* If the MPU is going into too deep sleep state while we are
> +* transmitting the IR code, timers will not be able to wake
> +* up the MPU. Thus, we need to set a strict enough latency
> +* requirement in order to ensure the interrupts come though
> +* properly.
>  */
> -   lirc_rx51->pdata->set_max_mpu_wakeup_lat(lirc_rx51->dev, 50);
> +   pm_qos_add_request(&lirc_rx51->pm_qos_request,
> +   PM_QOS_CPU_DMA_LATENCY, 10);
> Minor remark: it would be nice to have more detail on where the
> latency number 10 comes from. Is it fixed, is it linked to the baud
> rate etc?
> 

Yeah, it was chosen to be low enough for the MPU to receive the IRQ from
the timers. 50us was good enough back then with the original n900
kernel, but nowadays it is not good enough from preventing the MPU from
going to sleep where the timer interrupts don't come through.

Yes, I should probably have stated that in the comment to make it clear.
Can I re-send just this one patch or should I send the entire set again?
I'm assuming these go in through Mauro's media tree as these depend on
stuff that's already there. So, which ever is easier for him I guess :)

Thanks!

-Timo

> Here is my ack for the PM QoS API part:
> Acked-by: Jean Pihet 
> 
> Regards,
> Jean
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/10] mmc: omap_hsmmc: remove access to SYSCONFIG register

[S, Venkatraman]

On Tue, Aug 21, 2012 at 9:08 PM, Shubhrajyoti Datta
 wrote:
> Hi Venkat,
> Some doubts below.
>
> On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S  wrote:
>> SYSCONFIG register of HSMMC IP is managed by the omap hwmod
>> abstraction layer.
>
> At init only right?
Yes.
>
>
>> Resetting the IP and configuring the correct
>> SYSCONFIG mode is centrally managed by hwmod.
>>
>> Remove code which manipulates IP reset and SYSCONFIG directly in the
>> driver.
>
> I am not sure if mmc needs a reset.
>
Actually it doesn't, as far as I know. That's why I propose it to be removed.

> However IMHO
> In case it needs a reset
>
> the hwmod way could be to use  omap_hwmod_reset
> However I  fear it may be an issue with dt.
> or
> may be sysc could be restored something like [1]
>
>
>
> if it doesnt need reset even the check for the SYSSTATUS could be
> considered for removal.
>
> [1] http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg12041.html
>
>
>
>>
>> Signed-off-by: Venkatraman S 
>> ---
>>  drivers/mmc/host/omap_hsmmc.c | 24 ++--
>>  1 file changed, 2 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index da4f5a7..4bc55ac 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -44,7 +44,6 @@
>>  #include 
>>
>>  /* OMAP HSMMC Host Controller Registers */
>> -#define OMAP_HSMMC_SYSCONFIG   0x0010
>>  #define OMAP_HSMMC_SYSSTATUS   0x0014
>>  #define OMAP_HSMMC_CON 0x002C
>>  #define OMAP_HSMMC_BLK 0x0104
>> @@ -576,21 +575,8 @@ static int omap_hsmmc_context_restore(struct 
>> omap_hsmmc_host *host)
>> if (host->context_loss == context_loss)
>> return 1;
>>
>> -   /* Wait for hardware reset */
>> -   timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
>> -   while ((OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE) != 
>> RESETDONE
>> -   && time_before(jiffies, timeout))
>> -   ;
>> -
>> -   /* Do software reset */
>> -   OMAP_HSMMC_WRITE(host->base, SYSCONFIG, SOFTRESET);
>> -   timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
>> -   while ((OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE) != 
>> RESETDONE
>> -   && time_before(jiffies, timeout))
>> -   ;
>> -
>> -   OMAP_HSMMC_WRITE(host->base, SYSCONFIG,
>> -   OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE);
>> +   if (!OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE)
>> +   return 1;
> Should this check be removed.
>
No - it's still needed to check that the IP is ready for use.

>>
>> if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
>> if (host->power_mode != MMC_POWER_OFF &&
>> @@ -1593,10 +1579,6 @@ static void omap_hsmmc_conf_bus_power(struct 
>> omap_hsmmc_host *host)
>> value = OMAP_HSMMC_READ(host->base, CAPA);
>> OMAP_HSMMC_WRITE(host->base, CAPA, value | capa);
>>
>> -   /* Set the controller to AUTO IDLE mode */
>> -   value = OMAP_HSMMC_READ(host->base, SYSCONFIG);
>> -   OMAP_HSMMC_WRITE(host->base, SYSCONFIG, value | AUTOIDLE);
>> -
>> /* Set SD bus power bit */
>> set_sd_bus_power(host);
>>  }
>> @@ -1654,8 +1636,6 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
>> void *data)
>>
>> pm_runtime_get_sync(host->dev);
>>
>> -   seq_printf(s, "SYSCONFIG:\t0x%08x\n",
>> -   OMAP_HSMMC_READ(host->base, SYSCONFIG));
>> seq_printf(s, "CON:\t\t0x%08x\n",
>> OMAP_HSMMC_READ(host->base, CON));
>> seq_printf(s, "HCTL:\t\t0x%08x\n",
>> --
>> 1.7.11.1.25.g0e18bef
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/10] mmc: omap_hsmmc: consolidate flush posted writes for HSMMC IRQs

[S, Venkatraman]

On Tue, Aug 21, 2012 at 8:51 PM, T Krishnamoorthy, Balaji
 wrote:
> On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S  wrote:
>> Flushing spurious IRQs from HSMMC IP is done twice in
>> omap_hsmmc_irq and omap_hsmmc_do_irq.
>
> spurious IRQ is flushed in start of omap_hsmmc_do_irq
> and irq acked at the end of omap_hsmmc_do_irq
>
>> Consolidate them to one location.
>
> if you wanted to consolidated ...
>
>>
>> Signed-off-by: Venkatraman S 
>> ---
>>  drivers/mmc/host/omap_hsmmc.c | 17 -
>>  1 file changed, 4 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 4bc55ac..20453c8 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -969,15 +969,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
>> *host, int status)
>> struct mmc_data *data;
>> int end_cmd = 0, end_trans = 0;
>>
>> -   if (!host->req_in_progress) {
>
> just do a return from here

I think it's still better to filter out the validation to the outer
function and let do_irq to just 'do' it.

>
>> -   do {
>> -   OMAP_HSMMC_WRITE(host->base, STAT, status);
>> -   /* Flush posted write */
>> -   status = OMAP_HSMMC_READ(host->base, STAT);
>> -   } while (status & INT_EN_MASK);
>> -   return;
>> -   }
>> -
>> data = host->data;
>> dev_vdbg(mmc_dev(host->mmc), "IRQ Status is %x\n", status);
>>
>> @@ -1028,8 +1019,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
>> *host, int status)
>> }
>> }
>>
>> -   OMAP_HSMMC_WRITE(host->base, STAT, status);
>> -
>> if (end_cmd || ((status & CC) && host->cmd))
>> omap_hsmmc_cmd_done(host, host->cmd);
>> if ((end_trans || (status & TC)) && host->mrq)
>> @@ -1045,11 +1034,13 @@ static irqreturn_t omap_hsmmc_irq(int irq, void 
>> *dev_id)
>> int status;
>>
>> status = OMAP_HSMMC_READ(host->base, STAT);
>> -   do {
>> +   while (status & INT_EN_MASK && host->req_in_progress) {
>
> and remove the check for host->req_in_progress
> I think do while loop can be retained as it will get executed once anyway.

It's a minor issue, and the consolidation of the check for
req_in_progress makes sure that it might
sometimes be not executed at all..


>
>> omap_hsmmc_do_irq(host, status);
>> +
>
>> /* Flush posted write */
>
> comment is misplaced
>
Ok. I'll remove.

>> +   OMAP_HSMMC_WRITE(host->base, STAT, status);
>> status = OMAP_HSMMC_READ(host->base, STAT);
>> -   } while (status & INT_EN_MASK);
>> +   }
>>
>> return IRQ_HANDLED;
>>  }
>> --
>> 1.7.11.1.25.g0e18bef
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v6 07/10] ARM: OMAP2+: gpmc: generic timing calculation

[Mohammed, Afzal]

Hi Jon,

On Thu, Aug 23, 2012 at 08:28:44, Hunter, Jon wrote:
> On 08/21/2012 05:45 AM, Afzal Mohammed wrote:

> > +/* can the cycles be avoided ? */
> 
> What is the above comment referring too?

This was added in the initial stages and refers to the usage of
cycles in struct gpmc_device_timings. I wanted to avoid usage
of cycles, but it seems it is required logically as well. This
was mentioned as a note for future to find out whether at any
future point of time this can be removed.

> > +/* Device timings in picoseconds */
> 
> Why pico seconds and not nanoseconds? I understand you may need to
> temporarily convert to pico-secs for rounding, but when providing timing
> it seems nano-secs is more suitable.

For more accuracy, if you see some of the tusb6010 calculation
are in picoseconds, this can be true for any device although
only tusb does so. If we hold on to picoseconds till the last
moment, value would be more accurate. For eg. 300 ps has to be
used in the case of tusb, and with ns, it can't be accounted for

> I am a little concerned about the above timings structure. For example,
> if I am adding support for a new devices it is not clear ...
> 
> 1. Which are required
> 2. Which are applicable for async, sync, address-data multiplexed etc.
> 3. Exactly how these relate to the fields in the gpmc registers.

Please see at the end

> 
> I understand that this is based upon how timings for onenand and tusb
> are being calculated today, but I am not sure that this is the way to go
> for all devices. Personally, I would like to see us get away from how
> those devices are calculating timings for any new device.

You cannot do away with many of the those, as logically they
are right. Eg. read data should be available at access time,
assuming a zero data hold time, we can very well derive an
expression as,

read de-assertion time (oe_off) = access time plus 1 gpmc clock,

and this is what the existing calculations do, and also the
generic routine. There could be other constraints, but this
certainly should be one (I do realize that oe_off could be
optimized to be less than access time, by relying on read
hold time, then again effect of it would be in similar way
for different peripherals, but let's forget about
optimization in the beginning)

> In general, I am concerned that we are abstracting the timings further
> from the actual register fields. For example, the timings parameter
> "t_ceasu" is described "address setup to CS valid" which is not
> incorrect but this value is really just programming the CSONTIME field
> and so why not call this cs_on?

Timing fields of struct gpmc_device_timings are selected such
that they should be bindable by DT. At least one of the peripheral
datasheet has these fields. If user knows timings in terms of
gpmc values, he can directly use struct gpmc_timings, but
then all the values should be updated in struct gpmc_timings.
User should not update some of the values in terms of
peripheral timings, others in terms of gpmc timings, that
would make things complex and does not seem the right way
to me.

cs_on and other gpmc aware timings could be binded by DT, not as
peripheral timing, but as gpmc timing.

Bindings for peripheral DT timings should be something that
can be obtained from peripheral datasheet, here accidentally
it is same as gpmc timings, but not most timings are this way.
Also there could be other constraints that can come for cs_on,
even though I have not come across any till now.

> 
> So although this may consolidate how the timings are calculated today, I
> am concerned it will be confusing to add timings for a new device. At
> least if I am calculating timings, I am taking the timing information
> for the device and translating that to the how I need to program the
> gpmc register fields.

If I am not wrong, GPMC IP has been present for around a
decade, and so far I have not come across any generic time
calculation method that can be applied to all peripherals.
Getting to work same peripheral for a different gpmc
frequency is another problem.

Here we are trying to generalize based on the understanding of
gpmc & peripheral timings, as well as by a kind of reverse
engineering without most of the hardware or datasheet. Think of
this as an attempt to create one, let it evolve and become a
robust one. If a new user want to add a peripheral, let him add
support, input timings are selected such that it is found in
peripheral datasheet, if that does not work, let him try
to add any new timing field or alter existing expression
as he deems to be proper and verify that it does not break
others. And I can help provided I am not heavily loaded
with other works.

And at least for initial users, they are expected to have
some grasp on how to calculate timings, such a user will
not be much worried about your 3 concerns above, anyway as
of now they need to have a good grasp on it.

Meanwhile I will try to document more.

Regards
Afzal
--
To unsubscribe from this list: 

[PATCH] ARM: AM33XX: clock: Add dcan clock aliases for device-tree

[Vaibhav Hiremath]

Currently, the device names for the dcan module follows the
format "dcan.X", where 'X' is the dcan instance number.
On other side, driver may request for clock with/without con_id
and dev_id, and it is expected that platform should respect this
request and return the requested clock handle.

Now, when using device tree, the format of the device name created
by OF layer is different, ".",
assuming that the device-tree "reg" property is specified.
This causes the look-up failure for clock node in dcan driver

To fix this add new dcan clock alias for using device-tree.

Signed-off-by: Vaibhav Hiremath 
Cc: Tony Lindgren 
Cc: Paul Walmsley 
Cc: Benoit Cousson 
Cc: Grant Likely 
Cc: Rob Herring 
---
 arch/arm/mach-omap2/clock33xx_data.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock33xx_data.c 
b/arch/arm/mach-omap2/clock33xx_data.c
index ae27de8..a4006b2 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -1027,7 +1027,9 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL,   "cefuse_fck",   &cefuse_fck,CK_AM33XX),
CLK(NULL,   "clkdiv32k_ick",&clkdiv32k_ick, CK_AM33XX),
CLK(NULL,   "dcan0_fck",&dcan0_fck, CK_AM33XX),
+   CLK("481cc000.d_can",   NULL,   &dcan0_fck, CK_AM33XX),
CLK(NULL,   "dcan1_fck",&dcan1_fck, CK_AM33XX),
+   CLK("481d.d_can",   NULL,   &dcan1_fck, CK_AM33XX),
CLK(NULL,   "debugss_ick",  &debugss_ick,   CK_AM33XX),
CLK(NULL,   "pruss_ocp_gclk",   &pruss_ocp_gclk,
CK_AM33XX),
CLK("davinci-mcasp.0",  NULL,   &mcasp0_fck,CK_AM33XX),
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAPDSS: Correct DISPC_IRQ bit definitions for LCD3

[Tomi Valkeinen]

On Mon, 2012-08-27 at 14:23 +0530, Chandrabhanu Mahapatra wrote:
> The DISPC_IRQ bit definitions pertaining to channel LCD3 as DISPC_IRQ_VSYNC3,
> DISPC_IRQ_SYNC_LOST3, DISPC_IRQ_ACBIAS_COUNT_STAT3 AND DISPC_IRQ_FRAMEDONE3
> which were incorrectly set in previous LCD3 patches have been corrected here.
> 
> Reported-by: Mark Tyler 
> Signed-off-by: Chandrabhanu Mahapatra 
> ---
>  include/video/omapdss.h |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index b868123..9c7cca3 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -48,10 +48,10 @@
>  #define DISPC_IRQ_FRAMEDONEWB(1 << 23)
>  #define DISPC_IRQ_FRAMEDONETV(1 << 24)
>  #define DISPC_IRQ_WBBUFFEROVERFLOW   (1 << 25)
> -#define DISPC_IRQ_FRAMEDONE3 (1 << 26)
> -#define DISPC_IRQ_VSYNC3 (1 << 27)
> -#define DISPC_IRQ_ACBIAS_COUNT_STAT3 (1 << 28)
> -#define DISPC_IRQ_SYNC_LOST3 (1 << 29)
> +#define DISPC_IRQ_SYNC_LOST3 (1 << 27)
> +#define DISPC_IRQ_VSYNC3 (1 << 28)
> +#define DISPC_IRQ_ACBIAS_COUNT_STAT3 (1 << 29)
> +#define DISPC_IRQ_FRAMEDONE3 (1 << 30)
>  
>  struct omap_dss_device;
>  struct omap_overlay_manager;

Thanks, applied.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCHv2 7/8] ir-rx51: Convert latency constraints to PM QoS API

[Jean Pihet]

Hi Timo,

On Fri, Aug 24, 2012 at 10:39 PM, Tony Lindgren  wrote:
> * Timo Kokkonen  [120824 08:11]:
>> Convert the driver from the obsolete omap_pm_set_max_mpu_wakeup_lat
>> API to the new PM QoS API. This allows the callback to be removed from
>> the platform data structure.
>>
>> The latency requirements are also adjusted to prevent the MPU from
>> going into sleep mode. This is needed as the GP timers have no means
>> to wake up the MPU once it has gone into sleep. The "side effect" is
>> that from now on the driver actually works even if there is no
>> background load keeping the MPU awake.
>>
>> Signed-off-by: Timo Kokkonen 
>
> This should get acked by Kevin ideally. Other than that:
>
> Acked-by: Tony Lindgren 

...
@@ -268,10 +270,14 @@ static ssize_t lirc_rx51_write(struct file
*file, const char *buf,
lirc_rx51->wbuf[count] = -1; /* Insert termination mark */

/*
-* Adjust latency requirements so the device doesn't go in too
-* deep sleep states
+* If the MPU is going into too deep sleep state while we are
+* transmitting the IR code, timers will not be able to wake
+* up the MPU. Thus, we need to set a strict enough latency
+* requirement in order to ensure the interrupts come though
+* properly.
 */
-   lirc_rx51->pdata->set_max_mpu_wakeup_lat(lirc_rx51->dev, 50);
+   pm_qos_add_request(&lirc_rx51->pm_qos_request,
+   PM_QOS_CPU_DMA_LATENCY, 10);
Minor remark: it would be nice to have more detail on where the
latency number 10 comes from. Is it fixed, is it linked to the baud
rate etc?

Here is my ack for the PM QoS API part:
Acked-by: Jean Pihet 

Regards,
Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] OMAPDSS: Correct DISPC_IRQ bit definitions for LCD3

[Chandrabhanu Mahapatra]

The DISPC_IRQ bit definitions pertaining to channel LCD3 as DISPC_IRQ_VSYNC3,
DISPC_IRQ_SYNC_LOST3, DISPC_IRQ_ACBIAS_COUNT_STAT3 AND DISPC_IRQ_FRAMEDONE3
which were incorrectly set in previous LCD3 patches have been corrected here.

Reported-by: Mark Tyler 
Signed-off-by: Chandrabhanu Mahapatra 
---
 include/video/omapdss.h |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index b868123..9c7cca3 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -48,10 +48,10 @@
 #define DISPC_IRQ_FRAMEDONEWB  (1 << 23)
 #define DISPC_IRQ_FRAMEDONETV  (1 << 24)
 #define DISPC_IRQ_WBBUFFEROVERFLOW (1 << 25)
-#define DISPC_IRQ_FRAMEDONE3   (1 << 26)
-#define DISPC_IRQ_VSYNC3   (1 << 27)
-#define DISPC_IRQ_ACBIAS_COUNT_STAT3   (1 << 28)
-#define DISPC_IRQ_SYNC_LOST3   (1 << 29)
+#define DISPC_IRQ_SYNC_LOST3   (1 << 27)
+#define DISPC_IRQ_VSYNC3   (1 << 28)
+#define DISPC_IRQ_ACBIAS_COUNT_STAT3   (1 << 29)
+#define DISPC_IRQ_FRAMEDONE3   (1 << 30)
 
 struct omap_dss_device;
 struct omap_overlay_manager;
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation

[Mohammed, Afzal]

Hi Tony,

On Sat, Aug 25, 2012 at 01:16:30, Tony Lindgren wrote:

> This hangs n800 during the boot.

Shall I read the above as n800 boot without patch 10/10,
but with the other patches in this series ?

As per the board file, n800 has tusb6010 as well as
OneNAND in sync read & async write mode, was OneNAND
working without 10/10.

Do you have any idea, which timing could have gone wrong,
can you please sent me DEBUG enabled gpmc log with and
without 10/10.

Regards
Afzal
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html