Re: [PATCHv3 2/4] Input: keypad: Add smsc ece1099 keypad driver

[Poddar, Sourav]

Hi Dmitry,

On Tue, Oct 2, 2012 at 11:48 AM, Dmitry Torokhov
 wrote:
> Hi Sourav,
>
> On Mon, Oct 01, 2012 at 04:31:50PM +0530, Sourav Poddar wrote:
>> From: G, Manjunath Kondaiah 
>>
>> SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
>> supports a keypad scan matrix of 23*8.This driver uses this
>> device as a keypad driver.
>>
>> Tested on omap5430 evm with 3.6-rc6 custom kernel.
>>
>> Cc: Dmitry Torokhov 
>> Cc: Benoit Cousson 
>> Cc: Felipe Balbi 
>> Cc: Santosh Shilimkar 
>> Signed-off-by: G, Manjunath Kondaiah 
>> Signed-off-by: Sourav Poddar 
>> Acked-by: Felipe Balbi 
>> ---
>> Changes since v2:
>>  - Replace magic numbers through driver variable.
>>  - Provide comments for some initialisation done in probe.
>>  drivers/input/keyboard/Kconfig   |   11 +
>>  drivers/input/keyboard/Makefile  |1 +
>>  drivers/input/keyboard/smsc-ece1099-keypad.c |  304 
>> ++
>>  3 files changed, 316 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
>>
>> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
>> index c50fa75..b03a39c 100644
>> --- a/drivers/input/keyboard/Kconfig
>> +++ b/drivers/input/keyboard/Kconfig
>> @@ -593,6 +593,17 @@ config KEYBOARD_TWL4030
>> To compile this driver as a module, choose M here: the
>> module will be called twl4030_keypad.
>>
>> +config KEYBOARD_SMSC
>> +   tristate "SMSC ECE1099 keypad support"
>
> Should also select INPUT_MATRIXKMAP.
>
Yes, will include in the next version.
>> +   depends on I2C
>> +   help
>> + Say Y here if your board use the smsc keypad controller
>> + for omap5 defconfig. It's safe to say enable this
>> + even on boards that don't use the keypad controller.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called smsc-ece1099-keypad.
>> +
>>  config KEYBOARD_XTKBD
>>   tristate "XT keyboard"
>>   select SERIO
>> diff --git a/drivers/input/keyboard/Makefile 
>> b/drivers/input/keyboard/Makefile
>> index 44e7600..0f2aa26 100644
>> --- a/drivers/input/keyboard/Makefile
>> +++ b/drivers/input/keyboard/Makefile
>> @@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X)  += 
>> tc3589x-keypad.o
>>  obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
>>  obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
>>  obj-$(CONFIG_KEYBOARD_TWL4030)   += twl4030_keypad.o
>> +obj-$(CONFIG_KEYBOARD_SMSC)+= smsc-ece1099-keypad.o
>>  obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
>>  obj-$(CONFIG_KEYBOARD_W90P910)   += w90p910_keypad.o
>> diff --git a/drivers/input/keyboard/smsc-ece1099-keypad.c 
>> b/drivers/input/keyboard/smsc-ece1099-keypad.c
>> new file mode 100644
>> index 000..15dc147
>> --- /dev/null
>> +++ b/drivers/input/keyboard/smsc-ece1099-keypad.c
>> @@ -0,0 +1,304 @@
>> +/*
>> + * SMSC_ECE1099 Keypad driver
>> + *
>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define KEYPRESS_TIME  200
>> +
>> +struct smsc_keypad {
>> + struct smsc *smsc;
>> + struct matrix_keymap_data *keymap_data;
>> + unsigned int last_key_state[16];
>> + unsigned int last_col;
>> + unsigned int last_key_ms[16];
>> + unsigned short *keymap;
>> + struct i2c_client *client;
>> + struct input_dev *input;
>> + int rows, cols;
>> + int row_shift;
>> + bool no_autorepeat;
>> + unsignedirq;
>> + struct device *dev;
>> +};
>> +
>> +static void smsc_kp_scan(struct smsc_keypad *kp)
>> +{
>> + struct input_dev *input = kp->input;
>> + int i, j;
>> + int row, col;
>> + int temp, code;
>> + unsigned int new_state[16];
>> + unsigned int bits_changed;
>> + int this_ms;
>> +
>> + smsc_write(kp->dev, SMSC_KP_INT_MASK, 0x00);
>> + smsc_write(kp->dev, SMSC_KP_INT_STAT, 0xFF);
>> +
>> + /* Scan for row and column */
>> + for (i = 0; i < kp->cols; i++) {
>> + smsc_write(kp->dev, SMSC_KP_OUT, SMSC_KSO_EVAL + i);
>> + /* Read Row Status */
>> + smsc_read(kp->dev, SMSC_KP_IN, &temp);
>> + if (temp == 0xFF)
>> + continue;
>> +
>> + col = i;
>> + for (j = 0; j < kp->rows; j++) {
>> + if ((temp & 0x01) != 0x00) {
>> + temp = temp >> 1;
>> + continue;
>> + }
>> +

Re: [PATCH 5/6] ARM: OMAP: remove plat/clock.h

[Paul Walmsley]

On Tue, 2 Oct 2012, Tony Lindgren wrote:

> But you can see where the duplicates are with:
> 
> $ grep -rc 'include "clock.h"' arch/arm/*omap*/* | grep ":2"

OK thanks.  Updated the patch here, and planning to wait until 3.7-rc1 is 
out before sending a pull request for 3.8 cleanup.


- Paul

From: Paul Walmsley 
Date: Wed, 26 Sep 2012 17:55:04 -0600
Subject: [PATCH] ARM: OMAP: remove plat/clock.h

Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
The goal here is to facilitate ARM single image kernels by removing
includes via the "plat/" symlink.

Signed-off-by: Paul Walmsley 
[t...@atomide.com: fixed to remove duplicate clock.h includes]
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap1/board-nokia770.c |2 +-
 arch/arm/mach-omap1/clock.c  |1 -
 arch/arm/mach-omap1/clock.h  |  153 -
 arch/arm/mach-omap1/clock_data.c |1 -
 arch/arm/mach-omap1/pm.c |2 +-
 arch/arm/mach-omap2/clkt2xxx_apll.c  |1 -
 arch/arm/mach-omap2/clkt2xxx_dpll.c  |2 -
 arch/arm/mach-omap2/clkt2xxx_dpllcore.c  |1 -
 arch/arm/mach-omap2/clkt2xxx_osc.c   |2 -
 arch/arm/mach-omap2/clkt2xxx_sys.c   |2 -
 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |1 -
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c   |1 -
 arch/arm/mach-omap2/clkt_clksel.c|2 -
 arch/arm/mach-omap2/clkt_dpll.c  |2 -
 arch/arm/mach-omap2/clkt_iclk.c  |1 -
 arch/arm/mach-omap2/clock.c  |1 -
 arch/arm/mach-omap2/clock.h  |  284 ++-
 arch/arm/mach-omap2/clock2430.c  |2 -
 arch/arm/mach-omap2/clock2xxx.c  |2 -
 arch/arm/mach-omap2/clock34xx.c  |2 -
 arch/arm/mach-omap2/clock3517.c  |2 -
 arch/arm/mach-omap2/clock36xx.c  |2 -
 arch/arm/mach-omap2/clock3xxx.c  |2 -
 arch/arm/mach-omap2/clockdomain.c|2 +-
 arch/arm/mach-omap2/clockdomain.h|2 +-
 arch/arm/mach-omap2/common.c |2 +-
 arch/arm/mach-omap2/dpll3xxx.c   |2 -
 arch/arm/mach-omap2/dpll44xx.c   |2 -
 arch/arm/mach-omap2/omap_hwmod.c |2 +-
 arch/arm/mach-omap2/pm-debug.c   |2 +-
 arch/arm/mach-omap2/pm24xx.c |2 +-
 arch/arm/mach-omap2/sdram-nokia.c|2 +-
 arch/arm/mach-omap2/sdrc.c   |2 +-
 arch/arm/mach-omap2/sdrc2xxx.c   |1 -
 arch/arm/plat-omap/counter_32k.c |1 -
 arch/arm/plat-omap/include/plat/clock.h  |  309 --
 arch/arm/plat-omap/omap_device.c |1 -
 37 files changed, 445 insertions(+), 358 deletions(-)
 delete mode 100644 arch/arm/plat-omap/include/plat/clock.h

diff --git a/arch/arm/mach-omap1/board-nokia770.c 
b/arch/arm/mach-omap1/board-nokia770.c
index ec01f03..fef0a93 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -29,7 +29,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "clock.h"
 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 76c3f13..3bd98d6 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -24,7 +24,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/arm/mach-omap1/clock.h b/arch/arm/mach-omap1/clock.h
index 3d04f4f..155ddd9 100644
--- a/arch/arm/mach-omap1/clock.h
+++ b/arch/arm/mach-omap1/clock.h
@@ -14,8 +14,159 @@
 #define __ARCH_ARM_MACH_OMAP1_CLOCK_H
 
 #include 
+#include 
 
-#include 
+struct module;
+struct clk;
+
+/* Temporary, needed during the common clock framework conversion */
+#define __clk_get_name(clk)(clk->name)
+#define __clk_get_parent(clk)  (clk->parent)
+#define __clk_get_rate(clk)(clk->rate)
+
+/**
+ * struct clkops - some clock function pointers
+ * @enable: fn ptr that enables the current clock in hardware
+ * @disable: fn ptr that enables the current clock in hardware
+ * @find_idlest: function returning the IDLEST register for the clock's IP blk
+ * @find_companion: function returning the "companion" clk reg for the clock
+ * @allow_idle: fn ptr that enables autoidle for the current clock in hardware
+ * @deny_idle: fn ptr that disables autoidle for the current clock in hardware
+ *
+ * A "companion" clk is an accompanying clock to the one being queried
+ * that must be enabled for the IP module connected to the clock to
+ * become accessible by the hardware.  Neither @find_idlest nor
+ * @find_companion should be needed; that information is IP
+ * block-specific; the hwmod code has been created to handle this, but
+ * until hwmod data is ready and drivers have been converted to use PM
+ * runtime calls in place of clk_enable()/clk

[PATCH] ARM: arch timer: Export 'read_current_timer' symbol

[Mark A. Greer]

From: "Mark A. Greer" 

Commit 923df96b9f31b7d08d8438ff9677326d9537accf
(ARM: 7451/1: arch timer: implement read_current_timer and get_cycles)
modifies get_cycles() such that it calls read_current_timer().
Unfortunately, the 'read_current_timer' symbol is not exported so when
a driver that calls get_cycles() is built as a module, an undefined
reference error occurs.

A good example is the crypto/tcrypt.c (CONFIG_CRYPTO_TEST) driver
because it calls get_cycles() and can only be built as a module.

Fix this error by exporting the 'read_current_timer' symbol.

CC: Will Deacon 
CC: Russell King 
Signed-off-by: Mark A. Greer 
---

This patch applies against current arm-soc/for-next branch.

 arch/arm/kernel/armksyms.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 60d3b73..e7a29fe 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -156,3 +156,7 @@ EXPORT_SYMBOL(__gnu_mcount_nc);
 #ifdef CONFIG_ARM_PATCH_PHYS_VIRT
 EXPORT_SYMBOL(__pv_phys_offset);
 #endif
+
+#ifdef CONFIG_ARM_ARCH_TIMER
+EXPORT_SYMBOL(read_current_timer);
+#endif
-- 
1.7.12

--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

[Kevin Hilman]

"Poddar, Sourav"  writes:

> Hi,
>
> On Tue, Sep 25, 2012 at 2:51 PM, Russell King - ARM Linux
>  wrote:
>> On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
>>> On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote:
>>> > On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote:
>>> > > On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux 
>>> > > wrote:
>>> > > > How is this happening?  I think that needs proper investigation - or 
>>> > > > if
>>> > > > it's had more investigation, then the results needs to be included in
>>> > > > the commit description so that everyone can understand the issue here.
>>> > > >
>>> > > > We should not be resuming a device which hasn't been suspended.  Maybe
>>> > > > the runtime PM enable sequence is wrong, and that's what should be 
>>> > > > fixed
>>> > > > instead?
>>> > > >
>>> > > > This sequence in the probe() function:
>>> > > >
>>> > > > pm_runtime_irq_safe(&pdev->dev);
>>> > > > pm_runtime_enable(&pdev->dev);
>>> > > > pm_runtime_get_sync(&pdev->dev);
>>> > > >
>>> > > > would enable runtime PM while the s/w state indicates that it's 
>>> > > > disabled,
>>> > > > and then that pm_runtime_get_sync() will want to resume the device.  
>>> > > > See
>>> > > > the section "5. Runtime PM Initialization, Device Probing and Removal"
>>> > > > in Documentation/power/runtime_pm.txt, specifically the second 
>>> > > > paragraph
>>> > > > of that section.
>>> > >
>>> > > that was tested. It worked in pandaboard but didn't work on beagleboard
>>> > > XM. Sourav tried to start a discussion about that, but it simply died...
>>> > >
>>> > > In any case, pm_runtime_get_sync() in probe will always call
>>> > > runtime_resume callback, right ?
>>> >
>>> > Well, if the runtime PM state says it's suspended, and then you enable
>>> > runtime PM, the first call to pm_runtime_get_sync() will trigger a resume
>>> > attempt.  The patch description is complaining about resume events without
>>> > there being a preceding suspend event.
>>> >
>>> > This could well be why.
>>>
>>> that's most likely, of course. But should we cause a regression to
>>> beagleboard XM because of that ?
>>
>> What would cause a regression on beagleboard XM?  I have not suggested
>> any change other than more investigation of the issue and a fuller patch
>> description - yet you're screaming (idiotically IMHO) that mere
>> investigation would break beagleboard.
>>
>> Well, if it's _that_ fragile, that mere investigation of this issue by
>> someone elsewhere on the planet would break your beagleboard, maybe it
>> deserves to be broken!
>
> The issue was observed at serial init itself in the N800 board and the
> log does not
> show up much.
> http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
>  What we thought the problem might be with n800 is that it tries to
> resume when it didn't suspend before.
>
> There are two ways through which we thought of handling this issue:
>
> a) set device as active before enabling pm (which will prevent
>
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
>
> OR
>
> b) adding a "suspended" flag to struct omap_uart_port which gets set on
> suspend and cleared on resume. Then on resume you can check:
>
> if (!up->suspended)
> return 0;
>
> But using "pm_runtime_set_active" approach breaks things even on
> beagle board xm,  though
> it works fine on Panda.
> Therefore, we used the "suspended" flag approach.
>
> So. I just wanted to get some feedback from community about how using
> "pm_runtime_set_active"
> behaves differently in omap3 and omap4.

As Russell has already pointed out in great detail, the difference is
simply a mismatch between assumed HW stated and actual hardware state
between various boards.  Put simply, the driver assumes the HW is
disabled (runtime suspended) when it loads, and the first runtime resume
is meant to enable the HW.  If that assumption is wrong, it needs to be
fixed.

Have you figured out why the HW is already active on OMAP2?  (probably
bootloader?)  

That being said, already active HW should not cause this problem.  In
fact, because of possible early console use, the hwmod init of the UART
hwmods does not idle/reset them on boot, so they are left in the state
that the bootloader set them in.  

When the hwmod is later enabled for real during probe, the hwmod muxing
is done for that IP.  So, I suspect what is really happening is that the
mux settings are not right for the UARTS on n800, so when the probe
happens, the UART mux settings are changed and you lose the UART.

Can you double check the UART mux settings for that board?  You might
need some different mux settings in the board file.

Kevin

--
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 5/6] ARM: OMAP: remove plat/clock.h

[Tony Lindgren]

* Paul Walmsley  [120927 09:37]:
> Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
> arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
> The goal here is to facilitate ARM single image kernels by removing
> includes via the "plat/" symlink.

Looks like this adds some duplicate #include "clock.h",
we already have it in many places, so plat/clock.h changes
can be just dropped.

I've applied your patches locally with the other plat
header cleanup and fixed up the issue keeping the existing
clock.h. Updated patch below for what I have, probably
won't apply to your branch without conflicts right now.

But you can see where the duplicates are with:

$ grep -rc 'include "clock.h"' arch/arm/*omap*/* | grep ":2"

Anyways, let's wait few days before we do some immutable
branch as we still have the late patches missing from
the mainline kernel.

Regards,

Tony


From: Paul Walmsley 
Date: Thu, 27 Sep 2012 10:33:34 -0600
Subject: [PATCH] ARM: OMAP: remove plat/clock.h

Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
The goal here is to facilitate ARM single image kernels by removing
includes via the "plat/" symlink.

Signed-off-by: Paul Walmsley 
[t...@atomide.com: fixed to remove duplicate clock.h includes]
Signed-off-by: Tony Lindgren 

diff --git a/arch/arm/mach-omap1/board-nokia770.c 
b/arch/arm/mach-omap1/board-nokia770.c
index 8b3b60a..3e8ead67 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -29,12 +29,12 @@
 #include 
 
 #include 
-#include 
 
 #include 
 #include 
 
 #include "common.h"
+#include "clock.h"
 #include "mmc.h"
 
 #define ADS7846_PENDOWN_GPIO   15
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index f46206e..306772c 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -24,7 +24,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/arch/arm/mach-omap1/clock.h b/arch/arm/mach-omap1/clock.h
index 3d04f4f..155ddd92 100644
--- a/arch/arm/mach-omap1/clock.h
+++ b/arch/arm/mach-omap1/clock.h
@@ -14,8 +14,159 @@
 #define __ARCH_ARM_MACH_OMAP1_CLOCK_H
 
 #include 
+#include 
 
-#include 
+struct module;
+struct clk;
+
+/* Temporary, needed during the common clock framework conversion */
+#define __clk_get_name(clk)(clk->name)
+#define __clk_get_parent(clk)  (clk->parent)
+#define __clk_get_rate(clk)(clk->rate)
+
+/**
+ * struct clkops - some clock function pointers
+ * @enable: fn ptr that enables the current clock in hardware
+ * @disable: fn ptr that enables the current clock in hardware
+ * @find_idlest: function returning the IDLEST register for the clock's IP blk
+ * @find_companion: function returning the "companion" clk reg for the clock
+ * @allow_idle: fn ptr that enables autoidle for the current clock in hardware
+ * @deny_idle: fn ptr that disables autoidle for the current clock in hardware
+ *
+ * A "companion" clk is an accompanying clock to the one being queried
+ * that must be enabled for the IP module connected to the clock to
+ * become accessible by the hardware.  Neither @find_idlest nor
+ * @find_companion should be needed; that information is IP
+ * block-specific; the hwmod code has been created to handle this, but
+ * until hwmod data is ready and drivers have been converted to use PM
+ * runtime calls in place of clk_enable()/clk_disable(), @find_idlest and
+ * @find_companion must, unfortunately, remain.
+ */
+struct clkops {
+   int (*enable)(struct clk *);
+   void(*disable)(struct clk *);
+   void(*find_idlest)(struct clk *, void __iomem **,
+  u8 *, u8 *);
+   void(*find_companion)(struct clk *, void __iomem **,
+ u8 *);
+   void(*allow_idle)(struct clk *);
+   void(*deny_idle)(struct clk *);
+};
+
+/*
+ * struct clk.flags possibilities
+ *
+ * XXX document the rest of the clock flags here
+ *
+ * CLOCK_CLKOUTX2: (OMAP4 only) DPLL CLKOUT and CLKOUTX2 GATE_CTRL
+ * bits share the same register.  This flag allows the
+ * omap4_dpllmx*() code to determine which GATE_CTRL bit field
+ * should be used.  This is a temporary solution - a better approach
+ * would be to associate clock type-specific data with the clock,
+ * similar to the struct dpll_data approach.
+ */
+#define ENABLE_REG_32BIT   (1 << 0)/* Use 32-bit access */
+#define CLOCK_IDLE_CONTROL (1 << 1)
+#define CLOCK_NO_IDLE_PARENT   (1 << 2)
+#define ENABLE_ON_INIT (1 << 3)/* Enable upon framework init */
+#define INVERT_ENABLE  (1 << 4)/* 0 enables, 1 disables */
+#define CLOCK_CLKOUTX2 (1 << 5)
+
+/**
+ * struct clk - OMAP struct clk
+ * @node: list_head connecting this clock into 

Re: [PATCH 2/2] ARM: OMAP: SmartReflex: pass device dependent data via platform data

[Kevin Hilman]

Hi Jean,

Jean Pihet  writes:

> Remove the device dependent settings (cpu_is_xxx(), IP fck etc.)
> from the driver code and pass them instead via the platform
> data.
> This allows a clean separation of the driver code and the platform
> code, as required by the move of the platform header files to
> include/linux/platform_data.
>
> Signed-off-by: Jean Pihet 

Could you make pdata change and the clock change should be two different
patches?  Also, your previous patch to align SR clock names should be
combined with the changes made here.

Some comments on the clock change below...

> ---
>  arch/arm/mach-omap2/sr_device.c   |   13 
>  drivers/power/avs/smartreflex.c   |   40 ++--
>  include/linux/power/smartreflex.h |   14 +++-
>  3 files changed, 36 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
> index d033a65..2885a77 100644
> --- a/arch/arm/mach-omap2/sr_device.c
> +++ b/arch/arm/mach-omap2/sr_device.c
> @@ -122,6 +122,19 @@ static int __init sr_dev_init(struct omap_hwmod *oh, 
> void *user)
>   sr_data->senn_mod = 0x1;
>   sr_data->senp_mod = 0x1;
>  
> + if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
> + sr_data->err_weight = OMAP3430_SR_ERRWEIGHT;
> + sr_data->err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
> + sr_data->accum_data = OMAP3430_SR_ACCUMDATA;
> + if (!(strcmp(sr_data->name, "smartreflex_mpu"))) {
> + sr_data->senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
> + sr_data->senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
> + } else {
> + sr_data->senn_avgweight = OMAP3430_SR2_SENNAVGWEIGHT;
> + sr_data->senp_avgweight = OMAP3430_SR2_SENPAVGWEIGHT;
> + }
> + }
> +
>   sr_data->voltdm = voltdm_lookup(sr_dev_attr->sensor_voltdm_name);
>   if (IS_ERR(sr_data->voltdm)) {
>   pr_err("%s: Unable to get voltage domain pointer for VDD %s\n",
> diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
> index 92f6728..7c03c90 100644
> --- a/drivers/power/avs/smartreflex.c
> +++ b/drivers/power/avs/smartreflex.c
> @@ -128,17 +128,16 @@ static irqreturn_t sr_interrupt(int irq, void *data)
>  
>  static void sr_set_clk_length(struct omap_sr *sr)
>  {
> + char fck_name[16]; /* "smartreflex.0" fits in 16 chars */
>   struct clk *sys_ck;
>   u32 sys_clk_speed;
>  
> - if (cpu_is_omap34xx())
> - sys_ck = clk_get(NULL, "sys_ck");
> - else
> - sys_ck = clk_get(NULL, "sys_clkin_ck");
> + sprintf(fck_name, "smartreflex.%d", sr->srid);

hmm, isn't this the same as dev_name(&sr->pdev.dev) ?

Combined with your earlier patch to align clock names, this should just
be:

sys_ck = clk_get(&sr->pdev.dev, "fck");

Also note that you've changed this from sys_clk to the SR functional
clock, which seems to be the same clock on 34xx and 44xx, but that change
should be clearly documented in the changelog.

Kevin
--
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: hwmod: align the SmartReflex fck names

[Kevin Hilman]

On 10/02/2012 02:49 PM, Kevin Hilman wrote:

Jean Pihet  writes:


Rename the smartreflex fck names for consistency and better readability;
rename the clock aliases for use by the SmartReflex driver, with the
"smartreflex.%d" format.


hmm, do we even need the clkdev nodes anymore?  The driver isn't
directly accessing the fclk at all, so it seems like these could be
removed now.


Please ignore this comment, I see what you're doing in the other series 
now.  See my comments there.


Kevin
--
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 1/2] ARM: OMAP: SmartReflex: fix error path in init function

[Kevin Hilman]

Jean Pihet  writes:

> Fix the error handling path in omap_sr_probe to correctly
> de-allocate resources in case of problems.
>
> Signed-off-by: Jean Pihet 

Thanks, queuing this one as a fix for v3.7-rc

Kevin
--
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: SmartReflex: select CONFIG_POWER_SUPPLY in Kconfig

[Kevin Hilman]

jean.pi...@newoldbits.com writes:

> From: Jean Pihet 
>
> Select POWER_SUPPLY from POWER_AVS_OMAP entry in Kconfig.
>
> This avoids the following build problems using a randconfig
> that has CONFIG_POWER_SUPPLY not set:
>
>   LD  init/built-in.o
> arch/arm/mach-omap2/built-in.o: In function `sr_class3_configure':
> arch/arm/mach-omap2/smartreflex-class3.c:44: undefined reference to 
> `sr_configure_errgen'
> arch/arm/mach-omap2/built-in.o: In function `sr_class3_disable':
> arch/arm/mach-omap2/smartreflex-class3.c:33: undefined reference to 
> `sr_disable_errgen'
> arch/arm/mach-omap2/smartreflex-class3.c:35: undefined reference to 
> `sr_disable'
> arch/arm/mach-omap2/built-in.o: In function `sr_class3_enable':
> arch/arm/mach-omap2/smartreflex-class3.c:28: undefined reference to 
> `sr_enable'
> arch/arm/mach-omap2/built-in.o: In function `sr_class3_init':
> arch/arm/mach-omap2/smartreflex-class3.c:59: undefined reference to 
> `sr_register_class'
> make: *** [vmlinux] Error 1
>
> Signed-off-by: Jean Pihet 

Thanks, queuing for v3.7-rc

Kevin

> ---
>  arch/arm/plat-omap/Kconfig |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> index dd36eba..001a795 100644
> --- a/arch/arm/plat-omap/Kconfig
> +++ b/arch/arm/plat-omap/Kconfig
> @@ -48,6 +48,7 @@ config OMAP_DEBUG_LEDS
>  config POWER_AVS_OMAP
>   bool "AVS(Adaptive Voltage Scaling) support for OMAP IP versions 1&2"
>   depends on POWER_AVS && (ARCH_OMAP3 || ARCH_OMAP4) && PM
> + select POWER_SUPPLY
>   help
> Say Y to enable AVS(Adaptive Voltage Scaling)
> support on OMAP containing the version 1 or
--
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: hwmod: align the SmartReflex fck names

[Kevin Hilman]

Jean Pihet  writes:

> Rename the smartreflex fck names for consistency and better readability;
> rename the clock aliases for use by the SmartReflex driver, with the
> "smartreflex.%d" format.

hmm, do we even need the clkdev nodes anymore?  The driver isn't
directly accessing the fclk at all, so it seems like these could be
removed now.

Kevin

> Signed-off-by: Jean Pihet 
> ---
>  arch/arm/mach-omap2/clock33xx_data.c   |   12 ++--
>  arch/arm/mach-omap2/clock3xxx_data.c   |   12 ++--
>  arch/arm/mach-omap2/clock44xx_data.c   |6 +++---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 
>  4 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock33xx_data.c 
> b/arch/arm/mach-omap2/clock33xx_data.c
> index 25bbcc7..a328f12 100644
> --- a/arch/arm/mach-omap2/clock33xx_data.c
> +++ b/arch/arm/mach-omap2/clock33xx_data.c
> @@ -548,16 +548,16 @@ static struct clk mcasp1_fck = {
>   .recalc = &followparent_recalc,
>  };
>  
> -static struct clk smartreflex0_fck = {
> - .name   = "smartreflex0_fck",
> +static struct clk smartreflex_mpu_fck = {
> + .name   = "smartreflex_mpu_fck",
>   .clkdm_name = "l4_wkup_clkdm",
>   .parent = &sys_clkin_ck,
>   .ops= &clkops_null,
>   .recalc = &followparent_recalc,
>  };
>  
> -static struct clk smartreflex1_fck = {
> - .name   = "smartreflex1_fck",
> +static struct clk smartreflex_core_fck = {
> + .name   = "smartreflex_core_fck",
>   .clkdm_name = "l4_wkup_clkdm",
>   .parent = &sys_clkin_ck,
>   .ops= &clkops_null,
> @@ -1034,8 +1034,8 @@ static struct omap_clk am33xx_clks[] = {
>   CLK("davinci-mcasp.1",  NULL,   &mcasp1_fck,CK_AM33XX),
>   CLK("NULL", "mmc2_fck", &mmc2_fck,  CK_AM33XX),
>   CLK(NULL,   "mmu_fck",  &mmu_fck,   CK_AM33XX),
> - CLK(NULL,   "smartreflex0_fck", &smartreflex0_fck,  
> CK_AM33XX),
> - CLK(NULL,   "smartreflex1_fck", &smartreflex1_fck,  
> CK_AM33XX),
> + CLK(NULL,   "smartreflex.0",&smartreflex_mpu_fck,   
> CK_AM33XX),
> + CLK(NULL,   "smartreflex.1",&smartreflex_core_fck,  
> CK_AM33XX),
>   CLK(NULL,   "gpt1_fck", &timer1_fck,CK_AM33XX),
>   CLK(NULL,   "gpt2_fck", &timer2_fck,CK_AM33XX),
>   CLK(NULL,   "gpt3_fck", &timer3_fck,CK_AM33XX),
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
> b/arch/arm/mach-omap2/clock3xxx_data.c
> index 83bed9a..a197cf2 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3050,8 +3050,8 @@ static struct clk traceclk_fck = {
>  /* SR clocks */
>  
>  /* SmartReflex fclk (VDD1) */
> -static struct clk sr1_fck = {
> - .name   = "sr1_fck",
> +static struct clk smartreflex_mpu_iva_fck = {
> + .name   = "smartreflex_mpu_iva_fck",
>   .ops= &clkops_omap2_dflt_wait,
>   .parent = &sys_ck,
>   .enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
> @@ -3061,8 +3061,8 @@ static struct clk sr1_fck = {
>  };
>  
>  /* SmartReflex fclk (VDD2) */
> -static struct clk sr2_fck = {
> - .name   = "sr2_fck",
> +static struct clk smartreflex_core_fck = {
> + .name   = "smartreflex_core_fck",
>   .ops= &clkops_omap2_dflt_wait,
>   .parent = &sys_ck,
>   .enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
> @@ -3447,8 +3447,8 @@ static struct omap_clk omap3xxx_clks[] = {
>   CLK(NULL,   "atclk_fck",&atclk_fck, CK_3XXX),
>   CLK(NULL,   "traceclk_src_fck", &traceclk_src_fck, CK_3XXX),
>   CLK(NULL,   "traceclk_fck", &traceclk_fck,  CK_3XXX),
> - CLK(NULL,   "sr1_fck",  &sr1_fck,   CK_34XX | CK_36XX),
> - CLK(NULL,   "sr2_fck",  &sr2_fck,   CK_34XX | CK_36XX),
> + CLK(NULL,   "smartreflex.0",&smartreflex_mpu_iva_fck,   
> CK_34XX | CK_36XX),
> + CLK(NULL,   "smartreflex.1",&smartreflex_core_fck,  CK_34XX 
> | CK_36XX),
>   CLK(NULL,   "sr_l4_ick",&sr_l4_ick, CK_34XX | CK_36XX),
>   CLK(NULL,   "secure_32k_fck", &secure_32k_fck, CK_3XXX),
>   CLK(NULL,   "gpt12_fck",&gpt12_fck, CK_3XXX),
> diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
> b/arch/arm/mach-omap2/clock44xx_data.c
> index d7f55e4..9cc1112 100644
> --- a/arch/arm/mach-omap2/clock44xx_data.c
> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> @@ -3224,9 +3224,9 @@ static struct omap_clk omap44xx_clks[] = {
>   CLK(NULL,   "slimbus2_fclk_0",  &slimbus2_fclk_0,   
> CK_443X),
>   CLK(NULL,   "slimbus2_slimbus_clk", &slimbus2_slimbus_clk,  
> CK_443X),
>   CLK(NULL,   "slimbus2_fck", &slimbus2

Re: [PATCH] ARM: OMAP2+: PM: fix return value check in omap2_set_init_voltage()

[Kevin Hilman]

Jean Pihet  writes:

> On Thu, Sep 27, 2012 at 7:54 AM, Wei Yongjun  wrote:
>> From: Wei Yongjun 
>>
>> In case of error, the function voltdm_lookup() returns NULL
>> not ERR_PTR(). The IS_ERR() test in the return value check
>> should be replaced with NULL test.
>>
>> dpatch engine is used to auto generate this patch.
>> (https://github.com/weiyj/dpatch)
>>
>> Signed-off-by: Wei Yongjun 
>> ---
>>  arch/arm/mach-omap2/pm.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
>> index 9cb5ced..ab15e5c 100644
>> --- a/arch/arm/mach-omap2/pm.c
>> +++ b/arch/arm/mach-omap2/pm.c
>> @@ -176,7 +176,7 @@ static int __init omap2_set_init_voltage(char *vdd_name, 
>> char *clk_name,
>> }
>>
>> voltdm = voltdm_lookup(vdd_name);
>> -   if (IS_ERR(voltdm)) {
>> +   if (!voltdm) {
>> pr_err("%s: unable to get vdd pointer for vdd_%s\n",
>> __func__, vdd_name);
>> goto exit;
>
> This looks good, so here is the ack:
> Acked-by: Jean Pihet 

Thanks, queuing this one for v3.7-rc.

Kevin
--
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+: SmartReflex: fix return value check in sr_dev_init()

[Kevin Hilman]

Jean Pihet  writes:

> Hello,
>
> On Thu, Sep 27, 2012 at 7:54 AM, Wei Yongjun  wrote:
>> From: Wei Yongjun 
>>
>> In case of error, the function voltdm_lookup() returns NULL
>> not ERR_PTR(). The IS_ERR() test in the return value check
>> should be replaced with NULL test.
>>
>> dpatch engine is used to auto generate this patch.
>> (https://github.com/weiyj/dpatch)
>>
>> Signed-off-by: Wei Yongjun 
>> ---
>>  arch/arm/mach-omap2/sr_device.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/sr_device.c 
>> b/arch/arm/mach-omap2/sr_device.c
>> index d033a65..c248b30 100644
>> --- a/arch/arm/mach-omap2/sr_device.c
>> +++ b/arch/arm/mach-omap2/sr_device.c
>> @@ -123,7 +123,7 @@ static int __init sr_dev_init(struct omap_hwmod *oh, 
>> void *user)
>> sr_data->senp_mod = 0x1;
>>
>> sr_data->voltdm = voltdm_lookup(sr_dev_attr->sensor_voltdm_name);
>> -   if (IS_ERR(sr_data->voltdm)) {
>> +   if (!sr_data->voltdm) {
>> pr_err("%s: Unable to get voltage domain pointer for VDD 
>> %s\n",
>> __func__, sr_dev_attr->sensor_voltdm_name);
>> goto exit;
>
> This looks good, so here is the ack:
> Acked-by: Jean Pihet 
>

Thanks, queuing this one for v3.7-rc.

Kevin
--
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: omap_device: fix return value check in omap_device_build_ss()

[Kevin Hilman]

Wei Yongjun  writes:

> From: Wei Yongjun 
>
> In case of error, the function omap_device_alloc() returns ERR_PTR()
> and never returns NULL pointer. The NULL test in the return value
> check should be replaced with IS_ERR().
>
> dpatch engine is used to auto generated this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun 

Thanks, queueing this for v3.7-rc.

Kevin
--
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: fix return value check in beagle_opp_init()

[Kevin Hilman]

Wei Yongjun  writes:

> From: Wei Yongjun 
>
> In case of error, the function omap_device_get_by_hwmod_name()
> returns ERR_PTR() not NULL pointer. The NULL test in the return
> value check should be replaced with IS_ERR().
>
> dpatch engine is used to auto generated this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun 

Thanks, queueing this up for v3.7-rc.

Kevin

> ---
>  arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index 6202fc7..a548d70 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -466,7 +466,7 @@ static void __init beagle_opp_init(void)
>   mpu_dev = omap_device_get_by_hwmod_name("mpu");
>   iva_dev = omap_device_get_by_hwmod_name("iva");
>  
> - if (!mpu_dev || !iva_dev) {
> + if (IS_ERR(mpu_dev) || IS_ERR(iva_dev)) {
>   pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
>   __func__, mpu_dev, iva_dev);
>   return;
>
>
> --
> 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 v2 8/9] ARM: OMAP: iommu: add device tree support

[Matt Porter]

On Wed, Sep 12, 2012 at 02:45:51PM -0500, Omar Ramirez Luna wrote:
> Adapt driver to use DT if provided.

Hi Omar,

I'm interested in making use of the assert/deassert APIs you exposed in
this series on AM335x for the pruss hwmod which has one hardreset
line. I have the same situation where I need to get it deasserted before
I do any runtime PM. See my comments below...

> +static int __devinit
> +iommu_add_platform_data_from_dt(struct platform_device *pdev)
> +{
> + struct iommu_platform_data *pdata;
> + struct device_node *node = pdev->dev.of_node;
> + struct omap_hwmod *oh;
> + struct omap_mmu_dev_attr *a;
> + int ret = 0;
> +
> + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + of_property_read_string(node, "ti,hwmods", &pdata->name);
> + oh = omap_hwmod_lookup(pdata->name);
> + if (!oh) {
> + dev_err(&pdev->dev, "Cannot lookup hwmod '%s'\n", pdata->name);
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + a = (struct omap_mmu_dev_attr *)oh->dev_attr;
> + pdata->nr_tlb_entries = a->nr_tlb_entries;
> + pdata->da_start = a->da_start;
> + pdata->da_end = a->da_end;
> +
> + if (oh->rst_lines_cnt == 1) {
> + pdata->reset_name = oh->rst_lines->name;
> + pdata->assert_reset = omap_device_assert_hardreset;
> + pdata->deassert_reset = omap_device_deassert_hardreset;
> + }
> +
> + ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
> + if (ret)
> + dev_err(&pdev->dev, "Cannot add pdata for %s\n", pdata->name);
> +
> +out:
> + kfree(pdata);
> +
> + return ret;
> +}

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

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

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

I'm curious if you or others have thought about where this needs to go
next. When I first thought about a reset subsystem it seemed to trivial
to bother with but looking at the reasoning behind the power_seq
subsystem, it seems to have similar justification to get this machine
specific logic out of the platform code and under standardized control
of the driver. We have resources that are manipulated outside of the IP
block but need to be controlled at the driver level and probably should
have a common driver API that isn't OMAP specific and tied to pdata.

-Matt
--
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: Convert to use snd_soc_register_card()

[Janusz Krzysztofik]

Dnia niedziela, 16 września 2012 21:17:03 Janusz Krzysztofik pisze:
> The old method of registering with the ASoC core by creating a
> "soc-audio" platform device no longer works for Amstrad Delta sound card
> after recent changes to drvdata handling (commit
> 0998d0631001288a5974afc0b2a5f568bcdecb4d, 'device-core: Ensure drvdata =
> NULL when no driver is bound'.
> 
> Use snd_soc_register_card() method instead, as suggested by the ASoC
> core generated warning message, and move both the card and codec
> platform device registration to the arch board file where those belong.

Hi Mark,
Is something wrong with this patch? Any chance for it to find its way into 3.7?

Thanks,
Janusz

> Created and tested against linux-3.6-rc5.
> 
> Signed-off-by: Janusz Krzysztofik 
> ---
> On Thu, 6 Sep 2012 15:36:35 Mark Brown wrote:
> > On Sat, Sep 01, 2012 at 11:09:18AM +0200, Janusz Krzysztofik wrote:
> > 
> > > I see your point, however for now I can see no better way of referencing 
> > > the data (of type struct snd_soc_card) then passing it to 
> > > snd_soc_register_card(). But for this to work, I would have to register 
> > > successfully an ams-delta specific platform device first, not the soc-
> > > audio. This, even if still done from the sound/soc/omap/ams-delta.c, not 
> > > from an arch board file, would require now not existing ams-delta ASoC 
> > > platform driver probe/remove callbacks at least. I'm still not convinced 
> > > if such modification would be acceptable in the middle of the rc cycle.
> > 
> > > If there is a simpler, less intrusive way to do this, then sorry, I 
> > > still can't see it.
> > 
> > Like I already said just make it a static variable.
> 
> Mark,
> Sorry, I was still not able to understand what you actually meant, and
> to come out with a working fix other than I initially proposed. If what
> I've prepared now is not acceptable as a fix, than hard luck, please
> consider queueing it for 3.7, and 3.6 must go with Amstrad Delta sound
> not working unless someone else is still able to fix it.
> 
> Tony,
> Please give your ack on the arch/arm/mach-omap1 bits if acceptable. I
> believe there should be no merge conflicts if this change goes through
> sound/soc.
> 
> Thanks,
> Janusz
> 
>  arch/arm/mach-omap1/board-ams-delta.c |   12 ++
>  sound/soc/omap/ams-delta.c|   63 +++-
>  2 files changed, 42 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
> b/arch/arm/mach-omap1/board-ams-delta.c
> index c534698..5ab9c6b 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -444,16 +444,28 @@ static struct omap1_cam_platform_data 
> ams_delta_camera_platform_data = {
>   .lclk_khz_max   = 1334, /* results in 5fps CIF, 10fps QCIF */
>  };
>  
> +static struct platform_device ams_delta_audio_device = {
> + .name   = "ams-delta-audio",
> + .id = -1,
> +};
> +
> +static struct platform_device cx20442_codec_device = {
> + .name   = "cx20442-codec",
> + .id = -1,
> +};
> +
>  static struct platform_device *ams_delta_devices[] __initdata = {
>   &latch1_gpio_device,
>   &latch2_gpio_device,
>   &ams_delta_kp_device,
>   &ams_delta_camera_device,
> + &ams_delta_audio_device,
>  };
>  
>  static struct platform_device *late_devices[] __initdata = {
>   &ams_delta_nand_device,
>   &ams_delta_lcd_device,
> + &cx20442_codec_device,
>  };
>  
>  static void __init ams_delta_init(void)
> diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
> index 7d4fa8e..7b18b74 100644
> --- a/sound/soc/omap/ams-delta.c
> +++ b/sound/soc/omap/ams-delta.c
> @@ -575,56 +575,53 @@ static struct snd_soc_card ams_delta_audio_card = {
>  };
>  
>  /* Module init/exit */
> -static struct platform_device *ams_delta_audio_platform_device;
> -static struct platform_device *cx20442_platform_device;
> -
> -static int __init ams_delta_module_init(void)
> +static __devinit int ams_delta_probe(struct platform_device *pdev)
>  {
> + struct snd_soc_card *card = &ams_delta_audio_card;
>   int ret;
>  
> - if (!(machine_is_ams_delta()))
> - return -ENODEV;
> -
> - ams_delta_audio_platform_device =
> - platform_device_alloc("soc-audio", -1);
> - if (!ams_delta_audio_platform_device)
> - return -ENOMEM;
> + card->dev = &pdev->dev;
>  
> - 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.
> -  */
> - cx20442_platform_device =
> - platform_device_register_simple("cx20442-codec", -1, NULL, 0);
> + ret = snd

Re: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver

[ABRAHAM, KISHON VIJAY]

Hi,

On Tue, Oct 2, 2012 at 6:08 PM, Mark Brown
 wrote:
> On Mon, Oct 01, 2012 at 08:54:23PM +0530, ABRAHAM, KISHON VIJAY wrote:
>> On Mon, Oct 1, 2012 at 5:39 PM, Mark Brown
>
>> > Why would that be helpful?  Most platforms don't support DT at all, and
>
>> I'm not sure how to put it correctly. All I'm trying to tell is mfd is
>> a framework that exposes a set of API's to create and remove a device
>> among others. If a mfd child device is not created using mfd API,
>> it'll be unfair to expect that child be removed properly using mfd
>> API. Like in this patch, the device is created using
>> of_platform_populate (not a mfd API) but is removed using
>> mfd_remove_devices (mfd API) [which should result in an abort].
>
> That doesn't sound terribly clever, no, though it's not immediately
> clear to me if the non-clever bit is using mfd_remove_devices() or
> of_platform_populate().
>
>> This means mfd framework does not have an API to create a device from
>> dt data or so do I think since of_platform_populate() is used. Thats
>> why I suggested the idea of extending mfd_add_devices() (or adding a
>> new API in mfd framework) to create child devices from dt data so that
>> we'll have API's in mfd framework to both create and delete a device.
>
> The trouble that always exists with representing MFD children in DT is
> that unless you've got a usefully reusable IP block which is clearly
> separate from the chip integration you end up essentially just dumping
> the Linux data structures into DT which often doesn't leave you with
> something which describes the hardware.

indeed!

Thanks
Kishon
--
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 v2 2/5] iommu/omap: Merge iommu2.h into iommu.h

[Tony Lindgren]

* Ido Yariv  [121001 15:48]:
> Since iommu is not supported on OMAP1 and will not likely to ever be
> supported, merge plat/iommu2.h into iommu.h so only one file would have
> to move to platform_data/ as part of the single zImage effort.

Thanks I'll be applying patches 2 - 5 once we have -rc1 available.

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 v2 1/5] [media] omap3isp: Fix compilation error in ispreg.h

[Tony Lindgren]

* Ido Yariv  [121001 15:48]:
> Commit c49f34bc ("ARM: OMAP2+ Move SoC specific headers to be local to
> mach-omap2") moved omap34xx.h to mach-omap2. This broke omap3isp, as it
> includes omap34xx.h.
> 
> Instead of moving omap34xx to platform_data, simply add the two
> definitions the driver needs and remove the include altogether.
> 
> Signed-off-by: Ido Yariv 

I'm assuming that Mauro picks this one up, sorry
for breaking it.

Acked-by: Tony Lindgren 

> ---
>  drivers/media/platform/omap3isp/ispreg.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/omap3isp/ispreg.h 
> b/drivers/media/platform/omap3isp/ispreg.h
> index 084ea77..e2c57f3 100644
> --- a/drivers/media/platform/omap3isp/ispreg.h
> +++ b/drivers/media/platform/omap3isp/ispreg.h
> @@ -27,13 +27,13 @@
>  #ifndef OMAP3_ISP_REG_H
>  #define OMAP3_ISP_REG_H
>  
> -#include 
> -
> -
>  #define CM_CAM_MCLK_HZ   17280   /* Hz */
>  
>  /* ISP Submodules offset */
>  
> +#define L4_34XX_BASE 0x4800
> +#define OMAP3430_ISP_BASE(L4_34XX_BASE + 0xBC000)
> +
>  #define OMAP3ISP_REG_BASEOMAP3430_ISP_BASE
>  #define OMAP3ISP_REG(offset) (OMAP3ISP_REG_BASE + (offset))
>  
> -- 
> 1.7.11.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
--
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 v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Matt Porter]

On Tue, Oct 02, 2012 at 04:43:59PM +0530, Sekhar Nori wrote:
> On 10/1/2012 7:20 PM, Ben Gardiner wrote:
> > On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter  wrote:
> >> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> >>> Hi Matt,
> >>>
> >>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>  L3RAM (shared SRAM) is needed for use by several drivers.
>  This creates a genalloc pool and a hook for the platform code
>  to provide the struct gen_pool * in platform data.
> 
>  Signed-off-by: Matt Porter 
> >>>
> >>> I am not sure if any of the DaVinci devices have a need to allocate from
> >>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> >>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> >>> if there is much point in trying to allocate from there.
> >>>
> >>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> >>> allocation on DA850 makes sense for your case? If yes, can you repost
> >>> with Ben's patch included in your series instead of this patch? I would
> >>> prefer that over creating a new pool for shared RAM.
> >>
> >> Hrm, I did look at Ben's earlier patch. The reason I added a separate
> >> pool mostly was so I didn't have to touch the PM code at all. That can
> >> continue using the private SRAM API with the ARM RAM as it is now. The
> >> idea here was to allow that to be separate since no other bus masters
> >> can access the ARM RAM anyway and do something that didn't require
> >> regression testing PM. Also, I figured there's really no reason to use
> >> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> >> and working fine for that use case.
> >> [...]
> > 
> > I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
> > you said, Sekhar) in any fashion is preferable to moving suspend
> > support into shared RAM. There is more of it (128K on L138) but also
> > more pressure on allocations there since there are more clients.
> 
> There is where I would like to see more information on who the potential
> clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138,
> there should be more than enough for PM, Audio and PRU. I haven't
> checked the PM code size lately but it should be fairly small and I can
> check the actual number if that helps. So, adding a new pool just to
> save on those bytes doesn't sound like helping a lot.

The only wildcard is PRU usage due to the small per-PRU memory on PRUss
v1...though no sense in speculating further until somebody demonstrates a
need.

> > I appreciate that you are trying to preserve prior efforts in
> > attempted merging of SRAM support -- thank you for that; however, that
> > patch [1] was just an import of Subashish Ghosh's patch [2]  -- I
> > chose _that_ implementation option then mainly because I imagined it
> > would be the least risky to get accepted upstream and not because of
> > any particular technical merits.
> 
> Its not a question of prior effort since Matt has already put in the
> effort too. I am yet unconvinced that we need to add support to manage
> two blocks of SoC internal RAM on DA850 in the kernel today. That's all.

Yeah, I've come to agree with that. If somebody ends up needing that
extra 8K of local ram on L138 then they can add support.

-Matt
--
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 v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Matt Porter]

On Tue, Oct 02, 2012 at 03:32:55PM +0530, Sekhar Nori wrote:
> On 10/1/2012 6:02 PM, Matt Porter wrote:
> > On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> >> Hi Matt,
> >>
> >> On 9/29/2012 1:07 AM, Matt Porter wrote:
> >>> L3RAM (shared SRAM) is needed for use by several drivers.
> >>> This creates a genalloc pool and a hook for the platform code
> >>> to provide the struct gen_pool * in platform data.
> >>>
> >>> Signed-off-by: Matt Porter 
> >>
> >> I am not sure if any of the DaVinci devices have a need to allocate from
> >> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> >> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> >> if there is much point in trying to allocate from there.
> >>
> >> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> >> allocation on DA850 makes sense for your case? If yes, can you repost
> >> with Ben's patch included in your series instead of this patch? I would
> >> prefer that over creating a new pool for shared RAM.
> > 
> > Hrm, I did look at Ben's earlier patch. The reason I added a separate
> > pool mostly was so I didn't have to touch the PM code at all. That can
> > continue using the private SRAM API with the ARM RAM as it is now. The
> 
> But you dont have to touch the PM code. PM code can continue using SRAM
> API. I have verified in the past that PM can work using shared RAM.
> 
> > idea here was to allow that to be separate since no other bus masters
> > can access the ARM RAM anyway and do something that didn't require
> > regression testing PM. Also, I figured there's really no reason to use
> > even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> > and working fine for that use case.
> 
> I see no reason why PM would break with shared RAM. I have not even seen
> reports of shared RAM being short of size so we need to save space by
> having PM code in ARM RAM. I can test the changes before the code is
> committed and it will get tested in linux-next as well.

Ok, sounds good to me.

> > The other thing is that Ben's patch needs to be rewritten to at least
> > have the hook I added so we can provide the gen_pool in platform data.
> > If you prefer this path still, I can add the needed hook on top of his
> > original patch. Ultimately, I only *need* genalloc support for the
> > shared sram so I can remove the private SRAM API from uio_pruss...so I'm
> > happy with any way to get at it.
> 
> Right, I prefer just adding the hook so that genalloc can be used along
> with SRAM API.
 
Ok.

> > Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
> > remove the private SRAM API usage from the davinci ASoC driver too.
> 
> Audio can use the shared RAM too. And once all users of the SRAM API are
> gone, only the hook to help pass the gen_pool as platform data needs to
> remain.

Right, I think we are on the same page now. I'll post an update to Ben's
original patch with required gen_pool hook for pdata use.

I noticed the beginning of DT support for davinci and the DT-based
genalloc driver, https://patchwork.kernel.org/patch/1421961/, fits
into that well.

-Matt
--
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 v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Ben Gardiner]

On Tue, Oct 2, 2012 at 7:13 AM, Sekhar Nori  wrote:
> On 10/1/2012 7:20 PM, Ben Gardiner wrote:
>> On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter  wrote:
>>> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
 Hi Matt,

 On 9/29/2012 1:07 AM, Matt Porter wrote:
> L3RAM (shared SRAM) is needed for use by several drivers.
> This creates a genalloc pool and a hook for the platform code
> to provide the struct gen_pool * in platform data.
>
> Signed-off-by: Matt Porter 

 I am not sure if any of the DaVinci devices have a need to allocate from
 *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
 devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
 if there is much point in trying to allocate from there.

 Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
 allocation on DA850 makes sense for your case? If yes, can you repost
 with Ben's patch included in your series instead of this patch? I would
 prefer that over creating a new pool for shared RAM.
>>>
>>> Hrm, I did look at Ben's earlier patch. The reason I added a separate
>>> pool mostly was so I didn't have to touch the PM code at all. That can
>>> continue using the private SRAM API with the ARM RAM as it is now. The
>>> idea here was to allow that to be separate since no other bus masters
>>> can access the ARM RAM anyway and do something that didn't require
>>> regression testing PM. Also, I figured there's really no reason to use
>>> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
>>> and working fine for that use case.
>>> [...]
>>
>> I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
>> you said, Sekhar) in any fashion is preferable to moving suspend
>> support into shared RAM. There is more of it (128K on L138) but also
>> more pressure on allocations there since there are more clients.
>
> There is where I would like to see more information on who the potential
> clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138,
> there should be more than enough for PM, Audio and PRU. I haven't
> checked the PM code size lately but it should be fairly small and I can
> check the actual number if that helps. So, adding a new pool just to
> save on those bytes doesn't sound like helping a lot.

Good points. I suppose that the list would decrease also on L138 if
davinci-pcm ping-pong buffers were removed from SRAM.

>> I appreciate that you are trying to preserve prior efforts in
>> attempted merging of SRAM support -- thank you for that; however, that
>> patch [1] was just an import of Subashish Ghosh's patch [2]  -- I
>> chose _that_ implementation option then mainly because I imagined it
>> would be the least risky to get accepted upstream and not because of
>> any particular technical merits.
>
> Its not a question of prior effort since Matt has already put in the
> effort too. I am yet unconvinced that we need to add support to manage
> two blocks of SoC internal RAM on DA850 in the kernel today. That's all.

Understood. Thank you, Sekhar.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca
--
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: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver

[Felipe Balbi]

Hi,

On Tue, Oct 02, 2012 at 01:58:20PM +0100, Mark Brown wrote:
> On Tue, Oct 02, 2012 at 03:43:22PM +0300, Felipe Balbi wrote:
> 
> > BTW, OTOH writing all children into the DT actually describes the HW,
> > no ? And depending on the device I feel it'd be better to write that
> 
> Well, it depends on the hardware.  Some hardware has a bunch of nice,
> neat IPs which can usefully be reproduced and which map sensibly onto OS
> abstractions but a lot of it doesn't and frequently the abstractions
> which Linux wants to use don't bear a huge resemblance to the hardware
> (and Linux's ideas can change over time, as with the clock API being
> factored out for example).
> 
> > data to DT. Think of twl (TI's PMICs), we might have completely
> > unrelated drivers using one of TWL's GPIO lines as an interrupt source.
> 
> > If that particular children isn't listed in DT, it can't be used as an
> > interrupt-parent, right ?
> 
> You can have the interrupt controller there without having to list every
> IP in the device, just make the parent device the interrupt controller
> to DT.

fair enough, thanks ;-)

-- 
balbi


signature.asc
Description: Digital signature

Belangrijk bericht van de Webmaster‏

[Bakker-van Lieshout, Willie]

Uw web-mail quota heeft overschreden de set quotum dat is 2 GB. u op dit moment

draait op 2.3GB.To re-activeren en het verhogen van uw web-mail quota controleer

en uw web-mail account Om opnieuw te activeren en het verhogen van uw web-mail

quota op de link hieronder te werken.

https://docs.google.com/a/maine.edu/spreadsheet/viewform?formkey=dDFKRENaTDlBWVNldkRlaGREeTFxd0E6MQ

Doet u dit niet kan leiden tot de annulering van uw web-mail account.

Bedankt, en sorry voor het ongemak

Admin / Web-master / lokale host
--
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: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver

[Mark Brown]

On Tue, Oct 02, 2012 at 03:43:22PM +0300, Felipe Balbi wrote:

> BTW, OTOH writing all children into the DT actually describes the HW,
> no ? And depending on the device I feel it'd be better to write that

Well, it depends on the hardware.  Some hardware has a bunch of nice,
neat IPs which can usefully be reproduced and which map sensibly onto OS
abstractions but a lot of it doesn't and frequently the abstractions
which Linux wants to use don't bear a huge resemblance to the hardware
(and Linux's ideas can change over time, as with the clock API being
factored out for example).

> data to DT. Think of twl (TI's PMICs), we might have completely
> unrelated drivers using one of TWL's GPIO lines as an interrupt source.

> If that particular children isn't listed in DT, it can't be used as an
> interrupt-parent, right ?

You can have the interrupt controller there without having to list every
IP in the device, just make the parent device the interrupt controller
to DT.
--
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: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver

[Felipe Balbi]

Hi,

coming late to the discussion, so bear with me

On Tue, Oct 02, 2012 at 01:38:56PM +0100, Mark Brown wrote:
> > This means mfd framework does not have an API to create a device from
> > dt data or so do I think since of_platform_populate() is used. Thats
> > why I suggested the idea of extending mfd_add_devices() (or adding a
> > new API in mfd framework) to create child devices from dt data so that
> > we'll have API's in mfd framework to both create and delete a device.
> 
> The trouble that always exists with representing MFD children in DT is
> that unless you've got a usefully reusable IP block which is clearly
> separate from the chip integration you end up essentially just dumping
> the Linux data structures into DT which often doesn't leave you with
> something which describes the hardware.

do you mean to say that children creation should be left into the driver
(outside dt) ? That should be doable, indeed.

BTW, OTOH writing all children into the DT actually describes the HW,
no ? And depending on the device I feel it'd be better to write that
data to DT. Think of twl (TI's PMICs), we might have completely
unrelated drivers using one of TWL's GPIO lines as an interrupt source.

If that particular children isn't listed in DT, it can't be used as an
interrupt-parent, right ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver

[Mark Brown]

On Mon, Oct 01, 2012 at 08:54:23PM +0530, ABRAHAM, KISHON VIJAY wrote:
> On Mon, Oct 1, 2012 at 5:39 PM, Mark Brown

> > Why would that be helpful?  Most platforms don't support DT at all, and

> I'm not sure how to put it correctly. All I'm trying to tell is mfd is
> a framework that exposes a set of API's to create and remove a device
> among others. If a mfd child device is not created using mfd API,
> it'll be unfair to expect that child be removed properly using mfd
> API. Like in this patch, the device is created using
> of_platform_populate (not a mfd API) but is removed using
> mfd_remove_devices (mfd API) [which should result in an abort].

That doesn't sound terribly clever, no, though it's not immediately
clear to me if the non-clever bit is using mfd_remove_devices() or
of_platform_populate().

> This means mfd framework does not have an API to create a device from
> dt data or so do I think since of_platform_populate() is used. Thats
> why I suggested the idea of extending mfd_add_devices() (or adding a
> new API in mfd framework) to create child devices from dt data so that
> we'll have API's in mfd framework to both create and delete a device.

The trouble that always exists with representing MFD children in DT is
that unless you've got a usefully reusable IP block which is clearly
separate from the chip integration you end up essentially just dumping
the Linux data structures into DT which often doesn't leave you with
something which describes the hardware.
--
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: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

[Vinod Koul]

On Mon, 2012-10-01 at 12:39 -0400, Matt Porter wrote:
> Anything you can show at this point? ;) I'd be happy to drop the
> half-hack
> for a real API. If not, I'm going to carry that to v2 atm. 

This is what I had done sometime back. Feel free to update

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9c02a45..94ae006 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -86,11 +86,11 @@ enum dma_transaction_type {
  * @DMA_DEV_TO_DEV: Slave mode & From Device to Device
  */
 enum dma_transfer_direction {
-   DMA_MEM_TO_MEM,
-   DMA_MEM_TO_DEV,
-   DMA_DEV_TO_MEM,
-   DMA_DEV_TO_DEV,
-   DMA_TRANS_NONE,
+   DMA_MEM_TO_MEM  = 0x01,
+   DMA_MEM_TO_DEV  = 0x02,
+   DMA_DEV_TO_MEM  = 0x04,
+   DMA_DEV_TO_DEV  = 0x08,
+   DMA_TRANS_NONE  = 0x10,
 };
 
 /**
@@ -371,6 +371,41 @@ struct dma_slave_config {
unsigned int slave_id;
 };
 
+enum dmaengine_apis {
+   DMAENGINE_MEMCPY= 0x0001,
+   DMAENGINE_XOR   = 0x0002,
+   DMAENGINE_XOR_VAL   = 0x0004,
+   DMAENGINE_PQ= 0x0008,
+   DMAENGINE_PQ_VAL= 0x0010,
+   DMAENGINE_MEMSET= 0x0020,
+   DMAENGINE_SLAVE = 0x0040,
+   DMAENGINE_CYCLIC= 0x0080,
+   DMAENGINE_INTERLEAVED   = 0x0100,
+   DMAENGINE_SG= 0x0200,
+};
+
+/* struct dmaengine_chan_caps - expose capability of a channel
+ * Note: each channel can have same or different capabilities
+ *
+ * This primarily classifies capabilities into
+ * a) APIs/ops supported
+ * b) channel physical capabilities
+ *
+ * @ops: or'ed api capability
+ * @widths: channel widths supported
+ * @dirn: channel directions supported
+ * @bursts: bitmask of burst lengths supported
+ * @mux: configurable slave id or hard wired
+ * -1 for hard wired, otherwise valid positive slave id (including zero)
+ */
+struct dmaengine_chan_caps {
+   enum dmaengine_apis ops;
+   enum dma_slave_buswidth widths;
+   enum dma_transfer_direction dirn;
+   unsigned int dma_bursts;
+   int mux;
+};
+
 static inline const char *dma_chan_name(struct dma_chan *chan)
 {
return dev_name(&chan->dev->device);
@@ -534,6 +569,7 @@ struct dma_tx_state {
  * struct with auxiliary transfer status information, otherwise the call
  * will just return a simple status code
  * @device_issue_pending: push pending transactions to hardware
+ * @device_channel_caps: return the capablities of channel
  */
 struct dma_device {
 
@@ -602,6 +638,9 @@ struct dma_device {
dma_cookie_t cookie,
struct dma_tx_state *txstate);
void (*device_issue_pending)(struct dma_chan *chan);
+
+   struct dmaengine_chan_caps *(*device_channel_caps)(
+   struct dma_chan *chan);
 };
 
 static inline int dmaengine_device_control(struct dma_chan *chan,


-- 
~Vinod

--
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 v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Sekhar Nori]

On 10/1/2012 7:20 PM, Ben Gardiner wrote:
> On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter  wrote:
>> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>>> Hi Matt,
>>>
>>> On 9/29/2012 1:07 AM, Matt Porter wrote:
 L3RAM (shared SRAM) is needed for use by several drivers.
 This creates a genalloc pool and a hook for the platform code
 to provide the struct gen_pool * in platform data.

 Signed-off-by: Matt Porter 
>>>
>>> I am not sure if any of the DaVinci devices have a need to allocate from
>>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
>>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
>>> if there is much point in trying to allocate from there.
>>>
>>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
>>> allocation on DA850 makes sense for your case? If yes, can you repost
>>> with Ben's patch included in your series instead of this patch? I would
>>> prefer that over creating a new pool for shared RAM.
>>
>> Hrm, I did look at Ben's earlier patch. The reason I added a separate
>> pool mostly was so I didn't have to touch the PM code at all. That can
>> continue using the private SRAM API with the ARM RAM as it is now. The
>> idea here was to allow that to be separate since no other bus masters
>> can access the ARM RAM anyway and do something that didn't require
>> regression testing PM. Also, I figured there's really no reason to use
>> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
>> and working fine for that use case.
>> [...]
> 
> I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
> you said, Sekhar) in any fashion is preferable to moving suspend
> support into shared RAM. There is more of it (128K on L138) but also
> more pressure on allocations there since there are more clients.

There is where I would like to see more information on who the potential
clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138,
there should be more than enough for PM, Audio and PRU. I haven't
checked the PM code size lately but it should be fairly small and I can
check the actual number if that helps. So, adding a new pool just to
save on those bytes doesn't sound like helping a lot.

> I appreciate that you are trying to preserve prior efforts in
> attempted merging of SRAM support -- thank you for that; however, that
> patch [1] was just an import of Subashish Ghosh's patch [2]  -- I
> chose _that_ implementation option then mainly because I imagined it
> would be the least risky to get accepted upstream and not because of
> any particular technical merits.

Its not a question of prior effort since Matt has already put in the
effort too. I am yet unconvinced that we need to add support to manage
two blocks of SoC internal RAM on DA850 in the kernel today. That's all.

Thanks,
Sekhar
--
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 v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Sekhar Nori]

On 10/1/2012 6:02 PM, Matt Porter wrote:
> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>> Hi Matt,
>>
>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>>> L3RAM (shared SRAM) is needed for use by several drivers.
>>> This creates a genalloc pool and a hook for the platform code
>>> to provide the struct gen_pool * in platform data.
>>>
>>> Signed-off-by: Matt Porter 
>>
>> I am not sure if any of the DaVinci devices have a need to allocate from
>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
>> if there is much point in trying to allocate from there.
>>
>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
>> allocation on DA850 makes sense for your case? If yes, can you repost
>> with Ben's patch included in your series instead of this patch? I would
>> prefer that over creating a new pool for shared RAM.
> 
> Hrm, I did look at Ben's earlier patch. The reason I added a separate
> pool mostly was so I didn't have to touch the PM code at all. That can
> continue using the private SRAM API with the ARM RAM as it is now. The

But you dont have to touch the PM code. PM code can continue using SRAM
API. I have verified in the past that PM can work using shared RAM.

> idea here was to allow that to be separate since no other bus masters
> can access the ARM RAM anyway and do something that didn't require
> regression testing PM. Also, I figured there's really no reason to use
> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> and working fine for that use case.

I see no reason why PM would break with shared RAM. I have not even seen
reports of shared RAM being short of size so we need to save space by
having PM code in ARM RAM. I can test the changes before the code is
committed and it will get tested in linux-next as well.

> The other thing is that Ben's patch needs to be rewritten to at least
> have the hook I added so we can provide the gen_pool in platform data.
> If you prefer this path still, I can add the needed hook on top of his
> original patch. Ultimately, I only *need* genalloc support for the
> shared sram so I can remove the private SRAM API from uio_pruss...so I'm
> happy with any way to get at it.

Right, I prefer just adding the hook so that genalloc can be used along
with SRAM API.

> Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
> remove the private SRAM API usage from the davinci ASoC driver too.

Audio can use the shared RAM too. And once all users of the SRAM API are
gone, only the hook to help pass the gen_pool as platform data needs to
remain.

Thanks,
Sekhar
--
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: OMAP baseline test results for v3.6-rc7

[Igor Grinberg]

On 10/02/12 01:28, Paul Walmsley wrote:
> On Thu, 27 Sep 2012, Igor Grinberg wrote:
> 
>> Have you tried the nohlt boot parameter?
>> It looks like the wfi is killing those SoCs once you use EMAC.
> 
> Just tried with nohlt.  Didn't help on CM-T3517 with either NFS or MMC 
> root, nor with the 3517EVM with NFS root.  But I was able to get the 
> 3517EVM booting to userspace with MMC root.  Looks like the CM-T3517 board 
> file is missing the MMC setup code, so would guess that adding that back 
> in would help.

It never had the MMC in mainline...
I have some patches for that, based on v3.5,
but it should not be a problem to rebase those on a more recent git.
I will send them in a week or so, and if Tony will agree to merge them,
we will have the MMC on CM-T3517 mainline.


-- 
Regards,
Igor.
--
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