Re: [PATCH v2 04/15] dmaengine: Pass no_wakeup parameter via device_prep_dma_cyclic() callback
On Thu, Sep 13, 2012 at 04:37:54PM +0300, Peter Ujfalusi wrote: Change the parameter list of device_prep_dma_cyclic() so the DMA drivers can receive the no_wakeup request coming from client drivers. This feature can be used during audio operation to disable all audio related interrupts. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com CC: Nicolas Ferre nicolas.fe...@atmel.com CC: Barry Song baohua.s...@csr.com CC: Srinidhi Kasagar srinidhi.kasa...@stericsson.com CC: Russell King - ARM Linux li...@arm.linux.org.uk CC: Vista Silicon javier.mar...@vista-silicon.com CC: Zhangfei Gao zhangfei@marvell.com CC: Shawn Guo shawn@linaro.org CC: Laxman Dewangan ldewan...@nvidia.com --- drivers/dma/at_hdmac.c| 3 ++- drivers/dma/ep93xx_dma.c | 4 +++- drivers/dma/imx-dma.c | 2 +- drivers/dma/imx-sdma.c| 2 +- drivers/dma/mmp_tdma.c| 2 +- drivers/dma/mxs-dma.c | 2 +- drivers/dma/omap-dma.c| 3 ++- drivers/dma/pl330.c | 2 +- drivers/dma/sa11x0-dma.c | 2 +- drivers/dma/sirf-dma.c| 2 +- drivers/dma/ste_dma40.c | 3 ++- drivers/dma/tegra20-apb-dma.c | 2 +- include/linux/dmaengine.h | 5 +++-- 13 files changed, 20 insertions(+), 14 deletions(-) API changes without updating users? Regards, Shawn -- 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 04/15] dmaengine: Pass no_wakeup parameter via device_prep_dma_cyclic() callback
On 09/17/2012 09:34 AM, Shawn Guo wrote: On Thu, Sep 13, 2012 at 04:37:54PM +0300, Peter Ujfalusi wrote: Change the parameter list of device_prep_dma_cyclic() so the DMA drivers can receive the no_wakeup request coming from client drivers. This feature can be used during audio operation to disable all audio related interrupts. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com CC: Nicolas Ferre nicolas.fe...@atmel.com CC: Barry Song baohua.s...@csr.com CC: Srinidhi Kasagar srinidhi.kasa...@stericsson.com CC: Russell King - ARM Linux li...@arm.linux.org.uk CC: Vista Silicon javier.mar...@vista-silicon.com CC: Zhangfei Gao zhangfei@marvell.com CC: Shawn Guo shawn@linaro.org CC: Laxman Dewangan ldewan...@nvidia.com --- drivers/dma/at_hdmac.c| 3 ++- drivers/dma/ep93xx_dma.c | 4 +++- drivers/dma/imx-dma.c | 2 +- drivers/dma/imx-sdma.c| 2 +- drivers/dma/mmp_tdma.c| 2 +- drivers/dma/mxs-dma.c | 2 +- drivers/dma/omap-dma.c| 3 ++- drivers/dma/pl330.c | 2 +- drivers/dma/sa11x0-dma.c | 2 +- drivers/dma/sirf-dma.c| 2 +- drivers/dma/ste_dma40.c | 3 ++- drivers/dma/tegra20-apb-dma.c | 2 +- include/linux/dmaengine.h | 5 +++-- 13 files changed, 20 insertions(+), 14 deletions(-) API changes without updating users? All users of this callback is updated with this patch. The public API (dmaengine_prep_dma_cyclic) is only used by ASoC, which has been updated by the previous patch. Note: this part has been updated for v3. -- Péter -- 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 04/15] dmaengine: Pass no_wakeup parameter via device_prep_dma_cyclic() callback
On Mon, Sep 17, 2012 at 10:16:53AM +0300, Peter Ujfalusi wrote: All users of this callback is updated with this patch. The public API (dmaengine_prep_dma_cyclic) is only used by ASoC, which has been updated by the previous patch. Ah, ok. You actually changed dmaengine_prep_dma_cyclic signature before this patch. Sorry, I overlooked that. -- Regards, Shawn -- 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 v3 4/4] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
Add lis331dlh device tree data to am335x-evm.dts. In AM335x EVM
lis331dlh accelerometer is connected to I2C2 bus. So this patch
change the status of I2C2 node to okay to use I2C2 bus. Also
added all the required platform data to am335x-evm.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 39 ++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9fb59c5..be309df 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -47,6 +47,39 @@
};
};
+ i2c2: i2c@4802a000 {
+ status = okay;
+ clock-frequency = 40;
+
+ lis331dlh: lis331dlh@18 {
+ compatible = st,lis331dlh, st,lis3lv02d;
+ reg = 0x18;
+ Vdd-supply = lis3_reg;
+ Vdd_IO-supply = lis3_reg;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = 10;
+ st,click-thresh-y = 10;
+ st,click-thresh-z = 10;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = 120;
+ st,min-limit-y = 120;
+ st,min-limit-z = 140;
+ st,max-limit-x = 550;
+ st,max-limit-y = 550;
+ st,max-limit-z = 750;
+ };
+ };
+
dcan1: d_can@481d {
status = okay;
pinctrl-names = default;
@@ -61,6 +94,12 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ lis3_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = lis3_reg;
+ regulator-boot-on;
+ };
};
/include/ tps65910.dtsi
--
1.7.9.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
[PATCH v3 0/4] lis3: lis3lv02d_i2c: Add device tree support
Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. Changes from v2: - Added documentation details specific to lis3lv02d_i2c driver with example node - Modified DTS node representation in .dts file - Removed -i2c string from compatible name Changes from v1: - Moved lis3lv02d_init_dt to individual drivers with some code clean-up. - Added lis331dlh compatible entry for lis331dlh parts AnilKumar Ch (4): lis3: lis3lv02d: remove lis3lv02d driver DT init lis3: lis3lv02d_spi: Add lis3lv02d device tree init lis3: lis3lv02d_i2c: Add lis3lv02d device tree init ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm Documentation/devicetree/bindings/misc/lis302.txt | 36 +++ arch/arm/boot/dts/am335x-evm.dts | 39 + drivers/misc/lis3lv02d/lis3lv02d.c|8 ++--- drivers/misc/lis3lv02d/lis3lv02d.h|1 + drivers/misc/lis3lv02d/lis3lv02d_i2c.c| 18 ++ drivers/misc/lis3lv02d/lis3lv02d_spi.c|8 +++-- 6 files changed, 101 insertions(+), 9 deletions(-) -- 1.7.9.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
[PATCH v3 2/4] lis3: lis3lv02d_spi: Add lis3lv02d device tree init
Add lis3lv02d device tree initialization code/API to take pdata
from device node. Also remove CONFIG_OF ifdef from the driver,
if CONFIG_OF is not defined then OF APIs returns 0.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/misc/lis3lv02d/lis3lv02d_spi.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
index 23f3986..e1db6f4 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
@@ -84,10 +84,12 @@ static int __devinit lis302dl_spi_probe(struct spi_device
*spi)
lis3_dev.ac = lis3lv02d_axis_normal;
lis3_dev.pdata = spi-dev.platform_data;
-#ifdef CONFIG_OF
- if (of_match_device(lis302dl_spi_dt_ids, spi-dev))
+ if (of_match_device(lis302dl_spi_dt_ids, spi-dev)) {
lis3_dev.of_node = spi-dev.of_node;
-#endif
+ ret = lis3lv02d_init_dt(lis3_dev);
+ if (ret)
+ return ret;
+ }
spi_set_drvdata(spi, lis3_dev);
--
1.7.9.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
[PATCH v3 3/4] lis3: lis3lv02d_i2c: Add lis3lv02d device tree init
Add lis3lv02d device tree initialization code/API to take pdata
from device node. Also adds device tree init matching table
support to lis3lv02d_i2c driver. If the driver data is passed
from device tree, then this driver picks up platform data
from device node through common/generic lis3lv02d.c driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Documentation/devicetree/bindings/misc/lis302.txt | 36 +
drivers/misc/lis3lv02d/lis3lv02d_i2c.c| 18 +++
2 files changed, 54 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/lis302.txt
b/Documentation/devicetree/bindings/misc/lis302.txt
index e18af9d..6def86f 100644
--- a/Documentation/devicetree/bindings/misc/lis302.txt
+++ b/Documentation/devicetree/bindings/misc/lis302.txt
@@ -11,6 +11,12 @@ Required properties for the SPI bindings:
constrained by external circuitry
- interrupts: the interrupt generated by the device
+Required properties for the I2C bindings:
+ - compatible: should be set to st,lis3lv02d
+ - reg:i2c slave address
+ - Vdd-supply: The input supply for Vdd
+ - Vdd_IO-supply: The input supply for Vdd_IO
+
Optional properties for all bus drivers:
@@ -74,3 +80,33 @@ Example for a SPI device node:
st,wakeup-z-hi;
};
+Example for a I2C device node:
+
+ lis331dlh: lis331dlh@18 {
+ compatible = st,lis331dlh, st,lis3lv02d;
+ reg = 0x18;
+ Vdd-supply = lis3_reg;
+ Vdd_IO-supply = lis3_reg;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = 10;
+ st,click-thresh-y = 10;
+ st,click-thresh-z = 10;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = 120;
+ st,min-limit-y = 120;
+ st,min-limit-z = 140;
+ st,max-limit-x = 550;
+ st,max-limit-y = 550;
+ st,max-limit-z = 750;
+ };
+
diff --git a/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
b/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
index 15255eb..43e3f29 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
@@ -31,6 +31,9 @@
#include linux/i2c.h
#include linux/pm_runtime.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_platform.h
+
#include lis3lv02d.h
#define DRV_NAME lis3lv02d_i2c
@@ -102,12 +105,26 @@ static int lis3_i2c_init(struct lis3lv02d *lis3)
static union axis_conversion lis3lv02d_axis_map =
{ .as_array = { LIS3_DEV_X, LIS3_DEV_Y, LIS3_DEV_Z } };
+static struct of_device_id lis3lv02d_i2c_dt_ids[] = {
+ { .compatible = st,lis3lv02d },
+ {}
+};
+MODULE_DEVICE_TABLE(of, lis3lv02d_i2c_dt_ids);
+
static int __devinit lis3lv02d_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
int ret = 0;
struct lis3lv02d_platform_data *pdata = client-dev.platform_data;
+ if (of_match_device(lis3lv02d_i2c_dt_ids, client-dev)) {
+ lis3_dev.of_node = client-dev.of_node;
+ ret = lis3lv02d_init_dt(lis3_dev);
+ if (ret)
+ return ret;
+ pdata = lis3_dev.pdata;
+ }
+
if (pdata) {
if ((pdata-driver_features LIS3_USE_BLOCK_READ)
(i2c_check_functionality(client-adapter,
@@ -255,6 +272,7 @@ static struct i2c_driver lis3lv02d_i2c_driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
.pm = lis3_pm_ops,
+ .of_match_table = of_match_ptr(lis3lv02d_i2c_dt_ids),
},
.probe = lis3lv02d_i2c_probe,
.remove = __devexit_p(lis3lv02d_i2c_remove),
--
1.7.9.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
[PATCH v3 1/4] lis3: lis3lv02d: remove lis3lv02d driver DT init
Remove lis3lv02d driver device tree initialization from core driver
and move it to individual drivers. With the current implementation
some pdata parameters are missing if we use lis3lv02d_init_device()
in lis3lv02d_i2c driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/misc/lis3lv02d/lis3lv02d.c |8 ++--
drivers/misc/lis3lv02d/lis3lv02d.h |1 +
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index 79349ec..026021e 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -944,7 +944,7 @@ static void lis3lv02d_8b_configure(struct lis3lv02d *lis3,
}
#ifdef CONFIG_OF
-static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
+int lis3lv02d_init_dt(struct lis3lv02d *lis3)
{
struct lis3lv02d_platform_data *pdata;
struct device_node *np = lis3-of_node;
@@ -1084,7 +1084,7 @@ static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
}
#else
-static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
+int lis3lv02d_init_dt(struct lis3lv02d *lis3)
{
return 0;
}
@@ -1100,10 +1100,6 @@ int lis3lv02d_init_device(struct lis3lv02d *lis3)
irq_handler_t thread_fn;
int irq_flags = 0;
- err = lis3lv02d_init_dt(lis3);
- if (err 0)
- return err;
-
lis3-whoami = lis3lv02d_read_8(lis3, WHO_AM_I);
switch (lis3-whoami) {
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.h
b/drivers/misc/lis3lv02d/lis3lv02d.h
index 4cf0779..b5505fa 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.h
+++ b/drivers/misc/lis3lv02d/lis3lv02d.h
@@ -326,5 +326,6 @@ void lis3lv02d_joystick_disable(struct lis3lv02d *lis3);
void lis3lv02d_poweroff(struct lis3lv02d *lis3);
int lis3lv02d_poweron(struct lis3lv02d *lis3);
int lis3lv02d_remove_fs(struct lis3lv02d *lis3);
+int lis3lv02d_init_dt(struct lis3lv02d *lis3);
extern struct lis3lv02d lis3_dev;
--
1.7.9.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 v9 3/3] ARM: OMAP2+: gpmc: minimal driver support
Hi Paul,
On Wed, Sep 12, 2012 at 22:04:16, Paul Walmsley wrote:
Two checkpatch warnings are added by this patch:
I did checkpatch earlier, but without --strict
I've fixed them here in the obvious way. But please make sure that all
your patches are clean with 'checkpatch.pl --strict'; saves us time and
frustration...
I am sorry for that, in future --strict will be part of my process
Perhaps it would be better to patch Documentation with a mention
of --strict for checkpatch
And seeing an unpleasant behavior with --strict, running
checkpatch over cached changes (for pre-commit hook) is
not making effect of --strict felt
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v9 1/3] ARM: OMAP2/3: hwmod data: add gpmc
Hi Paul, On Thu, Sep 13, 2012 at 03:45:27, Paul Walmsley wrote: + HWMOD_INIT_NO_RESET | As I understand it, this is not due to any GPMC-related reset bugs, but just because the kernel is relying on the bootloader GPMC timing data being preserved. Is that correct? Yes, it is due to Kernel relying on bootloader gpmc settings Assuming it is, ideally we wouldn't merge such a patch, but I guess this is somewhat complicated now with the DT transition. So those should be marked with comments so we know this is not a hardware bug... something like the following. Thanks Regards Afzal
[PATCH 2/4] drivers/mmc/host/omap.c: fix error return code
From: Peter Senna Tschudin peter.se...@gmail.com
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
(
if@p1 (\(ret 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// /smpl
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
---
drivers/mmc/host/omap.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 48ad361..d468f51 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1369,8 +1369,10 @@ static int __devinit mmc_omap_probe(struct
platform_device *pdev)
host-irq = irq;
host-phys_base = host-mem_res-start;
host-virt_base = ioremap(res-start, resource_size(res));
- if (!host-virt_base)
+ if (!host-virt_base) {
+ ret = -ENOMEM;
goto err_ioremap;
+ }
host-iclk = clk_get(pdev-dev, ick);
if (IS_ERR(host-iclk)) {
@@ -1438,8 +1440,10 @@ static int __devinit mmc_omap_probe(struct
platform_device *pdev)
host-reg_shift = (cpu_is_omap7xx() ? 1 : 2);
host-mmc_omap_wq = alloc_workqueue(mmc_omap, 0, 0);
- if (!host-mmc_omap_wq)
+ if (!host-mmc_omap_wq) {
+ err = -ENOMEM;
goto err_plat_cleanup;
+ }
for (i = 0; i pdata-nr_slots; i++) {
ret = mmc_omap_new_slot(host, i);
--
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
[PATCH 3/4] drivers/mmc/host/omap_hsmmc.c: fix error return code
From: Peter Senna Tschudin peter.se...@gmail.com
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
(
if@p1 (\(ret 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// /smpl
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e59ac62..c8a2b36 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1893,6 +1893,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
if (pdata-init(pdev-dev) != 0) {
dev_dbg(mmc_dev(host-mmc),
Unable to configure MMC IRQs\n);
+ ret = -ENXIO;
goto err_irq_cd_init;
}
}
--
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
RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
Hi Tony,
On Fri, Sep 14, 2012 at 15:50:02, Mohammed, Afzal wrote:
* Mohammed, Afzal: Wednesday, September 12, 2012 3:20 PM
But some of the tusb async values is less by one. I need
to get it right.
Reason has been identified. It was due to rounding error,
no changes are required in the expressions. Moving
completely to picoseconds resolves the issue.
Can you please try with the attached patch ?
Can you please try with patch attached in previous message
of this thread and check whether it makes n800 gpmc
peripherals work properly
Changes as in above mentioned patch has been pasted below again.
Regards
Afzal
---8
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index d8e5b08..e9d57db 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -289,11 +289,11 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
if (time == 0)
ticks = 0;
else
- ticks = gpmc_ns_to_ticks(time);
+ ticks = gpmc_ps_to_ticks(time);
nr_bits = end_bit - st_bit + 1;
if (ticks = 1 nr_bits) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d: %-10s* %3d ns, %3d ticks = %d\n,
+ pr_info(GPMC CS%d: %-10s* %3d ps, %3d ticks = %d\n,
cs, name, time, ticks, 1 nr_bits);
#endif
return -1;
@@ -302,10 +302,9 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
mask = (1 nr_bits) - 1;
l = gpmc_cs_read_reg(cs, reg);
#ifdef DEBUG
- printk(KERN_INFO
- GPMC CS%d: %-10s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n,
- cs, name, ticks, gpmc_get_fclk_period() * ticks / 1000,
- (l st_bit) mask, time);
+ pr_info(GPMC CS%d: %-10s: %3d ticks, %3lu ps (was %3i ticks) %3d ps\n,
+ cs, name, ticks, gpmc_get_fclk_period() * ticks,
+ (l st_bit) mask, time);
#endif
l = ~(mask st_bit);
l |= ticks st_bit;
@@ -385,8 +384,8 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
if (l (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
- cs, (div * gpmc_get_fclk_period()) / 1000, div);
+ pr_info(GPMC CS%d CLK period is %lu ps (div %d)\n,
+ cs, div * gpmc_get_fclk_period(), div);
#endif
l = ~0x03;
l |= (div - 1);
@@ -922,46 +921,42 @@ static int gpmc_calc_sync_read_timings(struct
gpmc_timings *gpmc_t,
* indirectly necessitates requirement of t_avdp_r t_avdp_w
* instead of having a single t_avdp
*/
- temp = max_t(u32, temp, gpmc_t-clk_activation * 1000 +
- dev_t-t_avdh);
- temp = max_t(u32,
- (gpmc_t-adv_on + gpmc_ticks_to_ns(1)) * 1000, temp);
+ temp = max_t(u32, temp, gpmc_t-clk_activation + dev_t-t_avdh);
+ temp = max_t(u32, gpmc_t-adv_on + gpmc_ticks_to_ps(1), temp);
}
- gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp) / 1000;
+ gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp);
/* oe_on */
temp = dev_t-t_oeasu; /* remove this ? */
if (mux) {
- temp = max_t(u32, temp,
- gpmc_t-clk_activation * 1000 + dev_t-t_ach);
- temp = max_t(u32, temp, (gpmc_t-adv_rd_off +
- gpmc_ticks_to_ns(dev_t-cyc_aavdh_oe)) * 1000);
+ temp = max_t(u32, temp, gpmc_t-clk_activation + dev_t-t_ach);
+ temp = max_t(u32, temp, gpmc_t-adv_rd_off +
+ gpmc_ticks_to_ps(dev_t-cyc_aavdh_oe));
}
- gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp) / 1000;
+ gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp);
/* access */
/* any scope for improvement ?, by combining oe_on clk_activation,
* need to check whether access = clk_activation + round to sync clk ?
*/
temp = max_t(u32, dev_t-t_iaa, dev_t-cyc_iaa * gpmc_t-sync_clk);
- temp += gpmc_t-clk_activation * 1000;
+ temp += gpmc_t-clk_activation;
if (dev_t-cyc_oe)
- temp = max_t(u32, temp, (gpmc_t-oe_on +
- gpmc_ticks_to_ns(dev_t-cyc_oe)) * 1000);
- gpmc_t-access = gpmc_round_ps_to_ticks(temp) / 1000;
+ temp = max_t(u32, temp, gpmc_t-oe_on +
+ gpmc_ticks_to_ps(dev_t-cyc_oe));
+ gpmc_t-access = gpmc_round_ps_to_ticks(temp);
- gpmc_t-oe_off = gpmc_t-access + gpmc_ticks_to_ns(1);
+ gpmc_t-oe_off = gpmc_t-access + gpmc_ticks_to_ps(1);
Re: [PATCH v3 02/15] dmaengine: omap: Add support for pause/resume in cyclic dma mode
Hi Vinod, On 09/17/2012 06:13 AM, Vinod Koul wrote: On Fri, 2012-09-14 at 15:05 +0300, Peter Ujfalusi wrote: - /* FIXME: not supported by platform private API */ - return -EINVAL; + /* Pause/Resume only allowed with cyclic mode */ + if (!c-cyclic) + return -EINVAL; This is not a dma restriction right? The pause/resume operation has been only used by audio. This might work with non cyclic modes as well but it has never been used/tested so to be safe I have added this restriction. -- Péter -- 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] [PATCH v3 00/15] ASoC: OMAP: Convert to use dmaengine
Hi Vinod, On 09/17/2012 06:17 AM, Vinod Koul wrote: On Fri, 2012-09-14 at 15:05 +0300, Peter Ujfalusi wrote: Hello, dmaengine parts look good to me. How do you want to get this merged, dmaengine or ASoC tree? Thank you, I would prefer it to go via ASoC if it is not a problem. It is possible to separate the dmaengine core related patches and the patches for the OMAP drivers but I think it is better to keep them together so we can have them in a same tree for testing it further. Regards, Péter -- 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 04/15] dmaengine: Pass no_wakeup parameter via device_prep_dma_cyclic() callback
On Thu, Sep 13, 2012 at 3:37 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: Change the parameter list of device_prep_dma_cyclic() so the DMA drivers can receive the no_wakeup request coming from client drivers. This feature can be used during audio operation to disable all audio related interrupts. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com CC: Nicolas Ferre nicolas.fe...@atmel.com CC: Barry Song baohua.s...@csr.com CC: Srinidhi Kasagar srinidhi.kasa...@stericsson.com CC: Russell King - ARM Linux li...@arm.linux.org.uk CC: Vista Silicon javier.mar...@vista-silicon.com CC: Zhangfei Gao zhangfei@marvell.com CC: Shawn Guo shawn@linaro.org CC: Laxman Dewangan ldewan...@nvidia.com After some discussion with clever people I know I have come to the conclusion that this is a good idea, so: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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] drivers: phy: add generic PHY framework
On 09/14/2012 03:06 PM, ABRAHAM, KISHON VIJAY wrote:
[...]
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 000..c55446a
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,437 @@
+/*
+ * phy-core.c -- Generic Phy framework.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/err.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/phy/phy.h
+
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
What about adding a struct phy_res, doing so,m you don't need these
casts, and it's easier to add more pointers if needed.
Wont we still need to do the cast since you get only a void pointer.
Maybe I'm not getting you.
As res is a void pointer, no need to hast to to a struct phy_res
pointer, if you think that's unclean code, you can still cast it. But
IMHO the code is far more readable.
+
+ phy_put(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+ return res == match_data;
+}
+
+static struct phy *phy_lookup(struct device *dev, u8 index)
+{
+ struct phy_bind *phy_bind = NULL;
+
+ list_for_each_entry(phy_bind, phy_bind_list, list) {
+ if (!(strcmp(phy_bind-dev_name, dev_name(dev)))
+ phy_bind-index == index)
+ return phy_bind-phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+static struct phy *of_phy_lookup(struct device *dev, struct device_node
*node)
+{
+ int index = 0;
+ struct phy *phy;
^^
Please remove that stray space.
Sure.
+ struct phy_bind *phy_map = NULL;
+
+ list_for_each_entry(phy_map, phy_bind_list, list)
+ if (!(strcmp(phy_map-dev_name, dev_name(dev
+ index++;
+
+ list_for_each_entry(phy, phy_list, head) {
+ if (node != phy-desc-of_node)
+ continue;
+
+ phy_map = phy_bind(dev_name(dev), index, dev_name(phy-dev));
+ if (!IS_ERR(phy_map)) {
+ phy_map-phy = phy;
+ phy_map-auto_bind = true;
+ }
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+/**
+ * devm_phy_get - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres
data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, u8 index)
+{
+ struct phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ phy = phy_get(dev, index);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
nitpick: when when if has { }, else should have, too.
Sure.
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * devm_phy_put - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+ int r;
+
+ r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+ dev_WARN_ONCE(dev, r, couldn't find PHY resource\n);
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * devm_of_phy_get - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @phandle: name of the property holding the phy phandle value
+ *
+ * Returns the phy driver associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy.
+ * While at that,
Re: [alsa-devel] [PATCH v3 00/15] ASoC: OMAP: Convert to use dmaengine
On Mon, 2012-09-17 at 11:44 +0300, Peter Ujfalusi wrote: Hi Vinod, On 09/17/2012 06:17 AM, Vinod Koul wrote: On Fri, 2012-09-14 at 15:05 +0300, Peter Ujfalusi wrote: Hello, dmaengine parts look good to me. How do you want to get this merged, dmaengine or ASoC tree? Thank you, I would prefer it to go via ASoC if it is not a problem. It is possible to separate the dmaengine core related patches and the patches for the OMAP drivers but I think it is better to keep them together so we can have them in a same tree for testing it further. Sure I think this is better way to do. -- ~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 v3 02/15] dmaengine: omap: Add support for pause/resume in cyclic dma mode
On Fri, 2012-09-14 at 15:05 +0300, Peter Ujfalusi wrote: The audio stack used omap_stop_dma/omap_start_dma to pause/resume the DMA. This method has been used for years on OMAP based products. We only allow pause/resume when the DMA has been configured in cyclic mode which is used by the audio stack. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com CC: Russell King rmk+ker...@arm.linux.org.uk --- Acked-by: Vinod Koul vinod.k...@linux.intel.com -- ~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 v3 03/15] dmaengine: Add flags parameter to dmaengine_prep_dma_cyclic()
On Fri, 2012-09-14 at 15:05 +0300, Peter Ujfalusi wrote: With this parameter added to dmaengine_prep_dma_cyclic() the API will be in sync with other dmaengine_prep_*() functions. The dmaengine_prep_dma_cyclic() function primarily used by audio for cyclic transfer required by ALSA, we use the from audio to ask dma drivers to suppress interrupts (if DMA_PREP_INTERRUPT is cleared) when it is supported on the platform. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com CC: Lars-Peter Clausen l...@metafoo.de --- Acked-by: Vinod Koul vinod.k...@linux.intel.com -- ~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 v3 04/15] dmaengine: Pass flags via device_prep_dma_cyclic() callback
On Fri, 2012-09-14 at 15:05 +0300, Peter Ujfalusi wrote: Change the parameter list of device_prep_dma_cyclic() so the DMA drivers can receive the flags coming from clients. This feature can be used during audio operation to disable all audio related interrupts when the DMA_PREP_INTERRUPT is cleared from the flags. Acked-by: Vinod Koul vinod.k...@linux.intel.com -- ~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 v3 05/15] dmaengine: omap-dma: Add support to suppress interrupts in cyclic mode
On Fri, 2012-09-14 at 15:05 +0300, Peter Ujfalusi wrote: When requested (DMA_PREP_INTERRUPT is cleared in flags) disable all DMA interrupts for the channel. In this mode user space does not expect periodic reports from kernel about the progress of the audio stream. PulseAudio for example support this type of mode. Acked-by: Vinod Koul vinod.k...@linux.intel.com -- ~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 v3 04/15] dmaengine: Pass flags via device_prep_dma_cyclic() callback
On 09/14/2012 02:05 PM, Peter Ujfalusi :
Change the parameter list of device_prep_dma_cyclic() so the DMA drivers
can receive the flags coming from clients.
This feature can be used during audio operation to disable all audio
related interrupts when the DMA_PREP_INTERRUPT is cleared from the flags.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Nicolas Ferre nicolas.fe...@atmel.com
CC: Barry Song baohua.s...@csr.com
CC: Srinidhi Kasagar srinidhi.kasa...@stericsson.com
CC: Russell King - ARM Linux li...@arm.linux.org.uk
CC: Vista Silicon javier.mar...@vista-silicon.com
CC: Zhangfei Gao zhangfei@marvell.com
CC: Shawn Guo shawn@linaro.org
CC: Laxman Dewangan ldewan...@nvidia.com
---
drivers/dma/at_hdmac.c| 3 ++-
For Atmel's driver:
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
drivers/dma/ep93xx_dma.c | 4 +++-
drivers/dma/imx-dma.c | 2 +-
drivers/dma/imx-sdma.c| 2 +-
drivers/dma/mmp_tdma.c| 2 +-
drivers/dma/mxs-dma.c | 2 +-
drivers/dma/omap-dma.c| 3 ++-
drivers/dma/pl330.c | 2 +-
drivers/dma/sa11x0-dma.c | 2 +-
drivers/dma/sirf-dma.c| 2 +-
drivers/dma/ste_dma40.c | 3 ++-
drivers/dma/tegra20-apb-dma.c | 2 +-
include/linux/dmaengine.h | 4 ++--
13 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 3934fcc..7e5f6b6 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -841,12 +841,13 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct
at_desc *desc,
* @buf_len: total number of bytes for the entire buffer
* @period_len: number of bytes for each period
* @direction: transfer direction, to or from device
+ * @flags: tx descriptor status flags
* @context: transfer context (ignored)
*/
static struct dma_async_tx_descriptor *
atc_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr, size_t
buf_len,
size_t period_len, enum dma_transfer_direction direction,
- void *context)
+ unsigned long flags, void *context)
{
struct at_dma_chan *atchan = to_at_dma_chan(chan);
struct at_dma_slave *atslave = chan-private;
diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
index c64917e..493735b 100644
--- a/drivers/dma/ep93xx_dma.c
+++ b/drivers/dma/ep93xx_dma.c
@@ -1120,6 +1120,7 @@ fail:
* @buf_len: length of the buffer (in bytes)
* @period_len: lenght of a single period
* @dir: direction of the operation
+ * @flags: tx descriptor status flags
* @context: operation context (ignored)
*
* Prepares a descriptor for cyclic DMA operation. This means that once the
@@ -1133,7 +1134,8 @@ fail:
static struct dma_async_tx_descriptor *
ep93xx_dma_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t dma_addr,
size_t buf_len, size_t period_len,
-enum dma_transfer_direction dir, void *context)
+enum dma_transfer_direction dir, unsigned long flags,
+void *context)
{
struct ep93xx_dma_chan *edmac = to_ep93xx_dma_chan(chan);
struct ep93xx_dma_desc *desc, *first;
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 5084975..41b4376 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -801,7 +801,7 @@ static struct dma_async_tx_descriptor
*imxdma_prep_slave_sg(
static struct dma_async_tx_descriptor *imxdma_prep_dma_cyclic(
struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction,
- void *context)
+ unsigned long flags, void *context)
{
struct imxdma_channel *imxdmac = to_imxdma_chan(chan);
struct imxdma_engine *imxdma = imxdmac-imxdma;
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 1dc2a4a..2c5fd3e 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1012,7 +1012,7 @@ err_out:
static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction,
- void *context)
+ unsigned long flags, void *context)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac-sdma;
diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c
index 8a15cf2..6d52bd4 100644
--- a/drivers/dma/mmp_tdma.c
+++ b/drivers/dma/mmp_tdma.c
@@ -358,7 +358,7 @@ struct mmp_tdma_desc *mmp_tdma_alloc_descriptor(struct
mmp_tdma_chan *tdmac)
static struct dma_async_tx_descriptor *mmp_tdma_prep_dma_cyclic(
struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction,
- void *context)
+
Re: [PATCH] mtd: nand: omap2: Fix the nand-disk led trigger
On Thu, Sep 13, 2012 at 6:06 PM, Raphael Assenat r...@8d.com wrote:
When the omap2 nand flash driver is used, the nand-disk led trigger does not
work due to nand_wait_ready not being called.
I think better solution is just to delete omap_wait() function, which
is just a copy of nand_wait() without LED and oops handling. If
waitfunc is not set by the driver, default nand_wait is used by the
core.
This patch exports the trigger from nand_base.c, letting specific drivers
such omap2 control the led as appropriate.
Signed-off-by: Raphael Assenat r...@8d.com
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index a11253a..b967c45 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -103,7 +103,7 @@ static int nand_do_write_oob(struct mtd_info *mtd, loff_t
to,
* For devices which display every fart in the system on a separate LED. Is
* compiled away when LED support is disabled.
*/
-DEFINE_LED_TRIGGER(nand_led_trigger);
+DEFINE_LED_TRIGGER_GLOBAL(nand_led_trigger);
static int check_offs_len(struct mtd_info *mtd,
loff_t ofs, uint64_t len)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index ac4fd75..6aa683f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -19,6 +19,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/leds.h
#include linux/omap-dma.h
#include linux/io.h
#include linux/slab.h
@@ -254,6 +255,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd,
u_char *buf, int len)
int ret = 0;
u32 *p = (u32 *)buf;
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
/* take care of subpage reads */
if (len % 4) {
if (info-nand.options NAND_BUSWIDTH_16)
@@ -284,6 +287,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd,
u_char *buf, int len)
/* disable and stop the PFPW engine */
gpmc_prefetch_reset(info-gpmc_cs);
}
+
+ led_trigger_event(nand_led_trigger, LED_OFF);
}
/**
@@ -302,6 +307,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
u16 *p = (u16 *)buf;
unsigned long tim, limit;
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
/* take care of subpage writes */
if (len % 2 != 0) {
writeb(*buf, info-nand.IO_ADDR_W);
@@ -335,6 +342,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
/* disable and stop the PFPW engine */
gpmc_prefetch_reset(info-gpmc_cs);
}
+
+ led_trigger_event(nand_led_trigger, LED_OFF);
}
/*
@@ -366,6 +375,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
unsigned n;
int ret;
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
if (addr = high_memory) {
struct page *p1;
@@ -417,6 +428,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
gpmc_prefetch_reset(info-gpmc_cs);
dma_unmap_sg(info-dma-device-dev, sg, 1, dir);
+
+ led_trigger_event(nand_led_trigger, LED_OFF);
return 0;
out_copy_unmap:
@@ -428,6 +441,9 @@ out_copy:
else
is_write == 0 ? omap_read_buf8(mtd, (u_char *) addr, len)
: omap_write_buf8(mtd, (u_char *) addr, len);
+
+ led_trigger_event(nand_led_trigger, LED_OFF);
+
return 0;
}
@@ -886,6 +902,8 @@ static int omap_wait(struct mtd_info *mtd, struct
nand_chip *chip)
else
timeo += (HZ * 20) / 1000;
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
gpmc_nand_write(info-gpmc_cs,
GPMC_NAND_COMMAND, (NAND_CMD_STATUS 0xFF));
while (time_before(jiffies, timeo)) {
@@ -894,6 +912,7 @@ static int omap_wait(struct mtd_info *mtd, struct
nand_chip *chip)
break;
cond_resched();
}
+ led_trigger_event(nand_led_trigger, LED_OFF);
status = gpmc_nand_read(info-gpmc_cs, GPMC_NAND_DATA);
return status;
@@ -909,6 +928,8 @@ static int omap_dev_ready(struct mtd_info *mtd)
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
val = gpmc_read_status(GPMC_GET_IRQ_STATUS);
if ((val 0x100) == 0x100) {
/* Clear IRQ Interrupt */
@@ -923,6 +944,8 @@ static int omap_dev_ready(struct mtd_info *mtd)
val = gpmc_read_status(GPMC_GET_IRQ_STATUS);
}
}
+
+ led_trigger_event(nand_led_trigger, LED_OFF);
return 1;
}
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index
Re: [PATCH v3 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Monday 17 September 2012, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. Looks good to me. Reviewed-by: Arnd Bergmann a...@arndb.de -- 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 2/2] dmaengine: add helper function to request a slave DMA channel
On Monday 17 September 2012, Vinod Koul wrote:
On Fri, 2012-09-14 at 17:41 -0500, Jon Hunter wrote:
+/**
+ * dma_request_slave_channel - try to allocate an exclusive slave
channel
+ * @dev: pointer to client device structure
+ * @name: slave channel name
+ */
+struct dma_chan *dma_request_slave_channel(struct device *dev, char *name)
+{
+ /* If device-tree is present get slave info from here */
+ if (dev-of_node)
+ return of_dma_request_slave_channel(dev-of_node, name);
+
Shouldn't this be conditionally compiled only when OF is built. I think
this might be problematic for systems which doesn't have device tree.
Or perhaps you can declare these symbols as dummy in of_dma.h when
device tree is not selected.
Right, good point. I'd prefer the dummy functions, since that is in line
with what a lot of other subsystems do:
#ifdef CONFIG_OF
extern int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data);
extern void of_dma_controller_free(struct device_node *np);
extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
char *name);
extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
{
return -ENODEV;
}
static inline void of_dma_controller_free(struct device_node *np)
{
}
static inline struct dma_chan *of_dma_request_slave_channel(struct device_node
*np,
char *name)
{
return NULL;
}
static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args
*dma_spec,
struct of_dma *ofdma)
{
return NULL;
}
#endif
I believe that Jon is on vacation this week, so if this is the only issue
holding up the merge, maybe you can change this in his patch directly, or
I can send an updated version if you prefer.
Arnd
--
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] drivers: phy: add generic PHY framework
On Mon, Sep 17, 2012 at 11:19:53AM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 17, 2012 at 6:50 AM, Chen Peter-B29397 b29...@freescale.com wrote: The PHY framework provides a set of API's for the PHY drivers to create/remove a PHY and the PHY users to obtain a reference to the PHY using or without using phandle. If the PHY users has to obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. What's an example of the same phy user binds to multiple phys? Single controller using multiple phys.. to be more specific here: any usb3 controller needs a USB2 PHY and USB3 PHY. -- balbi signature.asc Description: Digital signature
AW: [PATCH] ARM: Add config option DEBUG_DECOMPRESS_KERNEL
-Ursprüngliche Nachricht- Von: Domenico Andreoli [mailto:domenico.andreoli...@gmail.com] Im Auftrag von Domenico Andreoli Gesendet: Montag, 17. September 2012 15:17 An: Maximilian Schwerin Cc: linux-arm-ker...@lists.infradead.org Betreff: Re: [PATCH] ARM: Add config option DEBUG_DECOMPRESS_KERNEL On Mon, Sep 17, 2012 at 03:08:44PM +0200, Maximilian Schwerin wrote: This change allows preventing the message Uncompressing Linux... from being sent to serial port. This is necessary if the primary serial port is used for something other than kernel debugging (e.g. some external device controlled by serial commands). Disabling CONFIG_DEBUG_LL doesn't work? Regards, Domenico No (never had that enabled), but that may be a bug or omission in the platform (omap3) code?! Regards, m. pgp5UD3aStIpy.pgp Description: PGP signature
[PATCH] AM35xx: Add missing hwmod entry for the HDQ/1-Wire present in AM3505/3517 CPUs.
This patch adds a missing hwmod entry for the HDQ/1-Wire module present
in the AM3505/17 CPUs.
This restores 1-Wire support to our AM3505 boards. We think it probably
stopped working with commit 96b1b29d37b0ca3ecd424a1fe301406cf525fc04
ARM: OMAP2+: HDQ1W: use omap_device
Signed-off-by: Raphael Assenat r...@8d.com
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ce7e606..59a0d81 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3405,6 +3405,7 @@ static struct omap_hwmod_ocp_if *am35xx_hwmod_ocp_ifs[]
__initdata = {
omap3xxx_l4_core__usb_tll_hs,
omap3xxx_l4_core__es3plus_mmc1,
omap3xxx_l4_core__es3plus_mmc2,
+ omap3xxx_l4_core__hdq1w,
am35xx_mdio__l3,
am35xx_l4_core__mdio,
am35xx_emac__l3,
--
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: [GIT PULL 1/7] omap non-critical fixes for v3.7 merge window
* Olof Johansson o...@lixom.net [120916 20:18]: On Thu, Sep 13, 2012 at 07:34:04PM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120913 19:20]: The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217: Linux 3.6-rc5 (2012-09-08 16:43:45 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-fixes-noncritical-for-v3.7 for you to fetch changes up to 3c5dc4a7daa6e64e39412fe9c7daa298834de623: ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write (2012-09-12 21:14:34 -0700) Non critical omap fixes that we not considered necessary for the v3.6 -rc cycle. Oops forgot to push out some of the tags and only this one seems to got sent. Still a valid pull request, but I'll repost the whole series of them. Ah, I noticed this now. And it also explains why I got 4 copies of all pull requests, they all looked identical until the one that was missing a tag, I suppose. :) Yes sorry for the extra spam, looks like you already found the right tag for the am33xx changes. Thanks, 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: [omap:tmp-merge 31/47] drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory
* Fengguang Wu fengguang...@intel.com [120916 17:41]: Hi Tony, FYI, kernel build failed on tree: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git tmp-merge head: a742996f4643b4e9612fe081d146035964cfbd87 commit: 7d7e1eba7e92c2f9c76db80adc24836e7a114bfb [31/47] ARM: OMAP2+: Prepare for irqs.h removal config: x86_64-randconfig-s331 (attached as .config) All related error/warning messages: drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory compilation terminated. vim +49 drivers/mfd/twl-core.c 44#include linux/regulator/machine.h 45 46#include linux/i2c.h 47#include linux/i2c/twl.h 48 49#include plat/cpu.h 50 51#include twl-core.h 52 53/* 54 * The TWL4030 Triton 2 is one of a family of a multi-function Power OK thanks for letting me know. That include needs to be ifdeffed until we remove all cpu_is_omap usage from drivers. I'll take a look and will also check if other drivers may have the same issue. 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 2/2] ARM: OMAP2+: Enable pinctrl dummy states
On Tue, Sep 11, 2012 at 06:03:07PM -0700, Tony Lindgren wrote: * Matt Porter mpor...@ti.com [120911 12:05]: On Tue, Sep 11, 2012 at 11:35:22AM -0700, Tony Lindgren wrote: Added Linus Walleij to Cc as well. Now I think I really managed to add Linus W to Cc, sent too fast earlier. ... But do you get an error then if the desired pins are not found? If you do get an error, then sounds like it's OK to do. Hrm, no. In that case, it will be completely silent (assuming we took care of the pinmuxing in the bootloader) as it uses the dummy state. Only with debug on will you see the information that mcspi has used the dummy state as is the case with !DT. ... Well I think we should consider at least the following: 1. Always see warnings when device tree is populated with board-generic. If somebody wants to use bootloader only muxing with DT, they can patch in pinctrl_provide_dummies() somewhere. But let's assume we always want to see the warnings with board-generic.c and DT. Ok, this is clear. 2. For legacy booting without DT, we should not see any warnings from pinctrl-single.c as it's DT based. Right, except anything legacy booting without DT will require that dummy states be present otherwise it will fail probe. But I guess we should enable the dummy states only for other board-*.c files, not board-generic.c? 3. There may be other non-pinctrl drivers too that are not DT based, and in those cases we should see the warnings as well for in the non-DT case. I'm not sure what you mean here. non-pinctrl drivers means any driver that is not yet pinctrl or DT enabled? It's unclear to me how this case has a bearing on mcspi and pinctrl enablement across legacy board-foo.c !DT booting platforms. Right, sorry I meant non DT pinctrl drivers.. However, I think if the approach was modified by only calling pinctrl_provide_dummies() when we are booting with DT populated and using board-generic.c then it will satisfy all of your concerns. Thoughts? Hmm but shouldn't it be call pinctrl_provide_dummies() only for other boards except board-generic.c? And that is assuming we don't have any other non DT pinctrl drivers around. Yes, I've addressed this now in v2. i.e. the legacy !DT booting will have dummy states and continue along through mcspi the way it does today, relying on board-foo level pinmux calls (or bootloader pinmuxing). Meanwhile DT booting will now require that a mcspi instance also require pinctrl entry in this dts. Yes agreed, except let's just produce a warning for the pinctrl errors.. Sounds good, I changed this in v2 to use the same warning as leds-gpio. The only worrisome thing is the pinctrl requirement on DT booting is now an implicit requirement. ..as otherwise not much will work at this point :) :) For board-generic.c we always want to see the warnings. And some boards insist on doing all the muxing only in the bootloader. Which warnings are you saying we should see in the board-generic.c case? Sure, there's plenty of cases where this will be unused due to somebody setting all the muxes in the bootloader and then not using pinctrl data. I'll have to doublecheck but I believe that case is also fine as the -single driver can't override the dummy state if the DT has no pinctrl data for the spi driver. I suggest all pinctrl errors should show up as warnings with board-generic.c, but we should not exit out of the driver probe on errors. Ok, makes sense to me now. Thanks, 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
[PATCH v2 0/2] Add pinctrl support to omap2-mcspi
Changes since v1: - warns that pins are not configured by the driver rather than exiting - dummy states are only enabled for OMAP platforms where DT is not populated This series enables pinctrl support for McSPI. Platforms that boot only from DT and rely on pinctrl to set pinmuxes appropriately require this for omap2-mcspi operation. It has been tested on AM335x BeagleBone with an Adafruit SPI LCD attached and regression tested on Beagleboard xM booting in the !DT case, using board-omap3evm.c. The series applies on top of Tony's dt-devel branch. Matt Porter (2): spi: omap2-mcspi: add pinctrl support ARM: OMAP2+: Enable pinctrl dummy states arch/arm/mach-omap2/devices.c |5 + drivers/spi/spi-omap2-mcspi.c |8 2 files changed, 13 insertions(+) -- 1.7.9.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
[PATCH v2 1/2] spi: omap2-mcspi: add pinctrl support
Adds pinctrl support to support OMAP platforms that boot from DT
and rely on pinctrl support to set pinmuxes.
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b2fb141..9502566 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -38,6 +38,8 @@
#include linux/pm_runtime.h
#include linux/of.h
#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
#include linux/spi/spi.h
@@ -1124,6 +1126,7 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
static int bus_num = 1;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
+ struct pinctrl *pinctrl;
master = spi_alloc_master(pdev-dev, sizeof *mcspi);
if (master == NULL) {
@@ -1219,6 +1222,11 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
if (status 0)
goto dma_chnl_free;
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev,
+ pins are not configured from the driver\n);
+
pm_runtime_use_autosuspend(pdev-dev);
pm_runtime_set_autosuspend_delay(pdev-dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(pdev-dev);
--
1.7.9.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
[PATCH v2 2/2] ARM: OMAP2+: Enable pinctrl dummy states
Enable pinctrl dummy states for all OMAP platforms that don't
populate DT. This allows drivers to be converted to pinctrl
and not generate new warnings on platforms that do not provide
pinctrl data. These platforms already have pinmuxes configured
before the drivers probe.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/mach-omap2/devices.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1efa984..6ef4010 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
#include linux/err.h
#include linux/slab.h
#include linux/of.h
+#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include asm/mach-types.h
@@ -628,6 +629,10 @@ static inline void omap_init_vout(void) {}
static int __init omap2_init_devices(void)
{
+ /* Enable dummy states for those platforms without pinctrl support */
+ if (!of_have_populated_dt())
+ pinctrl_provide_dummies();
+
/*
* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
--
1.7.9.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 v2 0/2] Add pinctrl support to omap2-mcspi
On Mon, Sep 17, 2012 at 01:22:16PM -0400, Matt Porter wrote: Changes since v1: - warns that pins are not configured by the driver rather than exiting - dummy states are only enabled for OMAP platforms where DT is not populated This series enables pinctrl support for McSPI. Platforms that boot only from DT and rely on pinctrl to set pinmuxes appropriately require this for omap2-mcspi operation. It has been tested on AM335x BeagleBone with an Adafruit SPI LCD attached and regression tested on Beagleboard xM booting in the !DT case, using board-omap3evm.c. The series applies on top of Tony's dt-devel branch. *sigh*, that's devel-dt of course. -- 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/2] spi: omap2-mcspi: add pinctrl support
* Matt Porter mpor...@ti.com [120917 10:21]:
Adds pinctrl support to support OMAP platforms that boot from DT
and rely on pinctrl support to set pinmuxes.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/spi/spi-omap2-mcspi.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b2fb141..9502566 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -38,6 +38,8 @@
#include linux/pm_runtime.h
#include linux/of.h
#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
#include linux/spi/spi.h
@@ -1124,6 +1126,7 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
static int bus_num = 1;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
+ struct pinctrl *pinctrl;
master = spi_alloc_master(pdev-dev, sizeof *mcspi);
if (master == NULL) {
@@ -1219,6 +1222,11 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
if (status 0)
goto dma_chnl_free;
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev,
+ pins are not configured from the driver\n);
+
pm_runtime_use_autosuspend(pdev-dev);
pm_runtime_set_autosuspend_delay(pdev-dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(pdev-dev);
--
1.7.9.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 v2 2/2] ARM: OMAP2+: Enable pinctrl dummy states
* Matt Porter mpor...@ti.com [120917 10:21]:
Enable pinctrl dummy states for all OMAP platforms that don't
populate DT. This allows drivers to be converted to pinctrl
and not generate new warnings on platforms that do not provide
pinctrl data. These platforms already have pinmuxes configured
before the drivers probe.
Thanks this should do the trick until we've converted to use DT.
I'll queue this for the upcoming merge window.
Regards,
Tony
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/mach-omap2/devices.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1efa984..6ef4010 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
#include linux/err.h
#include linux/slab.h
#include linux/of.h
+#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include asm/mach-types.h
@@ -628,6 +629,10 @@ static inline void omap_init_vout(void) {}
static int __init omap2_init_devices(void)
{
+ /* Enable dummy states for those platforms without pinctrl support */
+ if (!of_have_populated_dt())
+ pinctrl_provide_dummies();
+
/*
* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
--
1.7.9.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 1/2] drm: support for rotated scanout
On Tue, Sep 04, 2012 at 11:35:56AM -0500, Rob Clark wrote: From: Rob Clark r...@ti.com For drivers that can support rotated scanout, the extra parameter checking in drm-core, while nice, tends to get confused. To solve this drivers can set the crtc or plane invert_dimensions field so that the dimension checking takes into account the rotation that the driver is performing. v1: original v2: remove invert_dimensions from plane, at Ville's suggestion. Userspace can give rotated src coordinates, so invert_dimensions is not required for planes. Signed-off-by: Rob Clark r...@ti.com Sorry for the delay Rob, I somehow missed this. In any case, the patch looks OK to me. Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com -- Ville Syrjälä Intel OTC -- 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 0/2] ARM: New cache API for iommu
Hi Russell, On Thu, Sep 13, 2012 at 12:39 PM, Gupta, Ramesh grgu...@ti.com wrote: From a00cbfadc0053a3c21812593997a1b7338234a9f Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Thu, 13 Sep 2012 11:43:20 +0530 Subject: [PATCH v6 0/2] ARM: New cache API for iommu This patch series is the next version to - add a new cache maintenance api to support non-coherent iommu drivers. - flush both L1 and L2 caches from OMAP iommu whenever the page table memory is updated. Changes since the previous patch set (v5) - Fixed the RMK's comments on the flush function names in omap-iommu to reflect the purpose. The implementation of the new api is based on the approach[1] discussed. [1]http://marc.info/?l=linux-kernelm=131316512713815w=2 Ramesh Gupta G (2): ARM: new cache maintenance api for iommu OMAP:IOMMU:flush L1 and L2 caches I have included your review comments in this series. Could you please pull these patches if every thing looks fine? thank you and regards Ramesh Gupta G -- 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:tmp-merge 31/47] drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory
Hi,
On Mon, Sep 17, 2012 at 09:56:43AM -0700, Tony Lindgren wrote:
* Fengguang Wu fengguang...@intel.com [120916 17:41]:
Hi Tony,
FYI, kernel build failed on
tree: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
tmp-merge
head: a742996f4643b4e9612fe081d146035964cfbd87
commit: 7d7e1eba7e92c2f9c76db80adc24836e7a114bfb [31/47] ARM: OMAP2+:
Prepare for irqs.h removal
config: x86_64-randconfig-s331 (attached as .config)
All related error/warning messages:
drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or
directory
compilation terminated.
vim +49 drivers/mfd/twl-core.c
44 #include linux/regulator/machine.h
45
46 #include linux/i2c.h
47 #include linux/i2c/twl.h
48
49 #include plat/cpu.h
50
51 #include twl-core.h
52
53 /*
54 * The TWL4030 Triton 2 is one of a family of a
multi-function Power
OK thanks for letting me know. That include needs to be ifdeffed until
we remove all cpu_is_omap usage from drivers. I'll take a look and will
also check if other drivers may have the same issue.
the only use of cpu_is_* in that driver is related to the osc_ck clock
name. Isn't this enough ?
From: Felipe Balbi ba...@ti.com
Subject: mfd: twl-core: drop cpu_is_* usage
NYET-Signed-off-by: Felipe Balbi ba...@ti.com
---
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index cacabb0..b2e6080 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1855,7 +1855,7 @@ static struct omap_clk omap2430_clks[] = {
/* external root sources */
CLK(NULL, func_32k_ck, func_32k_ck, CK_243X),
CLK(NULL, secure_32k_ck, secure_32k_ck, CK_243X),
- CLK(NULL, osc_ck, osc_ck,CK_243X),
+ CLK(NULL, osc_sys_ck, osc_ck,CK_243X),
CLK(NULL, sys_ck, sys_ck,CK_243X),
CLK(NULL, alt_ck, alt_ck,CK_243X),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_243X),
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 1c32afe..e4fff17 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -1132,11 +1132,7 @@ static void clocks_init(struct device *dev,
u32 rate;
u8 ctrl = HFCLK_FREQ_26_MHZ;
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
- if (cpu_is_omap2430())
- osc = clk_get(dev, osc_ck);
- else
- osc = clk_get(dev, osc_sys_ck);
+ osc = clk_get(dev, osc_sys_ck);
if (IS_ERR(osc)) {
printk(KERN_WARNING Skipping twl internal clock init and
@@ -1147,18 +1143,6 @@ static void clocks_init(struct device *dev,
rate = clk_get_rate(osc);
clk_put(osc);
-#else
- /* REVISIT for non-OMAP systems, pass the clock rate from
-* board init code, using platform_data.
-*/
- osc = ERR_PTR(-EIO);
-
- printk(KERN_WARNING Skipping twl internal clock init and
- using bootloader value (unknown osc rate)\n);
-
- return;
-#endif
-
switch (rate) {
case 1920:
ctrl = HFCLK_FREQ_19p2_MHZ;
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/4] drivers/mmc/host/omap_hsmmc.c: fix error return code
On Mon, Sep 17, 2012 at 1:45 PM, Peter Senna Tschudin
peter.se...@gmail.com wrote:
From: Peter Senna Tschudin peter.se...@gmail.com
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
(
if@p1 (\(ret 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// /smpl
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Looks good.
Acked-by: Venkatraman S svenk...@ti.com
--
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] mmc: omap_hsmmc: Pass on the suspend failure to the PM core
On Thu, Sep 13, 2012 at 12:01 PM, Hebbar, Gururaja
gururaja.heb...@ti.com wrote:
From: Vaibhav Bedia vaibhav.be...@ti.com
In some cases mmc_suspend_host() is not able to claim the
host and proceed with the suspend process. The core returns
-EBUSY to the host controller driver. Unfortunately, the
host controller driver does not pass on this information
to the PM core and hence the system suspend process continues.
ret = mmc_suspend_host(host-mmc);
if (ret) {
host-suspended = 0;
if (host-pdata-resume) {
ret = host-pdata-resume(dev, host-slot_id);
The return status from mmc_suspend_host() is overwritten by return
status from host-pdata-resume. So the original return status is lost.
In these cases the MMC core gets to an unexpected state
during resume and multiple issues related to MMC crop up.
1. Host controller driver starts accessing the device registers
before the clocks are enabled which leads to a prefetch abort.
2. A file copy thread which was launched before suspend gets
stuck due to the host not being reclaimed during resume.
To avoid such problems pass on the -EBUSY status to the PM core
from the host controller driver. With this change, MMC core
suspend might still fail but it does not end up making the
system unusable. Suspend gets aborted and the user can try
suspending the system again.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
This version is good.
Acked-by: Venkatraman S svenk...@ti.com
---
Changes from V1:
- Instead of forcibly returning -EBUSY on err, retain old
status and pass on the same to the caller.
- add more detail to commit message (explanation with code
snippet)
:100644 100644 9afdd20... d9af5f1... M drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/omap_hsmmc.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9afdd20..d9af5f1 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2050,8 +2050,7 @@ static int omap_hsmmc_suspend(struct device *dev)
if (ret) {
host-suspended = 0;
if (host-pdata-resume) {
- ret = host-pdata-resume(dev, host-slot_id);
- if (ret)
+ if (host-pdata-resume(dev, host-slot_id))
dev_dbg(dev, Unmask interrupt failed\n);
}
goto err;
--
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: [omap:tmp-merge 31/47] drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory
* Felipe Balbi ba...@ti.com [120917 11:05]:
Hi,
On Mon, Sep 17, 2012 at 09:56:43AM -0700, Tony Lindgren wrote:
* Fengguang Wu fengguang...@intel.com [120916 17:41]:
Hi Tony,
FYI, kernel build failed on
tree:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
tmp-merge
head: a742996f4643b4e9612fe081d146035964cfbd87
commit: 7d7e1eba7e92c2f9c76db80adc24836e7a114bfb [31/47] ARM: OMAP2+:
Prepare for irqs.h removal
config: x86_64-randconfig-s331 (attached as .config)
All related error/warning messages:
drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or
directory
compilation terminated.
vim +49 drivers/mfd/twl-core.c
44#include linux/regulator/machine.h
45
46#include linux/i2c.h
47#include linux/i2c/twl.h
48
49#include plat/cpu.h
50
51#include twl-core.h
52
53/*
54 * The TWL4030 Triton 2 is one of a family of a
multi-function Power
OK thanks for letting me know. That include needs to be ifdeffed until
we remove all cpu_is_omap usage from drivers. I'll take a look and will
also check if other drivers may have the same issue.
the only use of cpu_is_* in that driver is related to the osc_ck clock
name. Isn't this enough ?
Well there's a bit more to it, see below..
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1855,7 +1855,7 @@ static struct omap_clk omap2430_clks[] = {
/* external root sources */
CLK(NULL, func_32k_ck, func_32k_ck, CK_243X),
CLK(NULL, secure_32k_ck, secure_32k_ck, CK_243X),
- CLK(NULL, osc_ck, osc_ck,CK_243X),
+ CLK(NULL, osc_sys_ck, osc_ck,CK_243X),
CLK(NULL, sys_ck, sys_ck,CK_243X),
CLK(NULL, alt_ck, alt_ck,CK_243X),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_243X),
That's also in use in the pm24xx code.. And is not a generic name
for other SoCs potentially using it. I have something like this here,
but now MMC somehow breaks on 2430sdp that I need to figure out..
Tony
From 292156f6265e3b5446747de41038a19ef476b650 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Mon, 17 Sep 2012 10:47:16 -0700
Subject: [PATCH] mfd: Fix compile for twl-core.c by removing cpu_is_omap
usage
Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) broke
compile for non-omap as include plat/cpu.h was added. This header
was indirectly included earlier when SPARSE_IRQ was not set, but
does not exist on most platforms.
Fix the problem by removing the cpu_is_omap usage that should
not exist in drivers at all. We can do this by adding proper
clock aliases for the twl-core.c drivers, and drop separate
handling for cases when clock framework is not available as
the behaviour will stay the same.
Note that we need to add a platform device to avoid using the
i2c provided names that may be different on various omaps.
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 02fe1f2..7ea9139 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1856,6 +1856,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, func_32k_ck, func_32k_ck, CK_243X),
CLK(NULL, secure_32k_ck, secure_32k_ck, CK_243X),
CLK(NULL, osc_ck, osc_ck,CK_243X),
+ CLK(twl, fck, osc_ck,CK_243X),
CLK(NULL, sys_ck, sys_ck,CK_243X),
CLK(NULL, alt_ck, alt_ck,CK_243X),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 10a2398..700317a 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3226,6 +3226,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, virt_2600_ck, virt_2600_ck,
CK_3XXX),
CLK(NULL, virt_38_4m_ck, virt_38_4m_ck, CK_3XXX),
CLK(NULL, osc_sys_ck, osc_sys_ck,CK_3XXX),
+ CLK(twl, fck, osc_sys_ck,CK_3XXX),
CLK(NULL, sys_ck, sys_ck,CK_3XXX),
CLK(NULL, sys_altclk, sys_altclk,CK_3XXX),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_3XXX),
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index f462ff2..9d3a0bc 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -46,8 +46,6 @@
#include linux/i2c.h
#include linux/i2c/twl.h
-#include plat/cpu.h
-
#include twl-core.h
/*
@@ -1134,12 +1132,7 @@ static void clocks_init(struct device *dev,
u32 rate;
u8 ctrl = HFCLK_FREQ_26_MHZ;
-#if defined(CONFIG_ARCH_OMAP2) ||
Re: [omap:tmp-merge 31/47] drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory
* Tony Lindgren t...@atomide.com [120917 12:43]:
* Felipe Balbi ba...@ti.com [120917 11:05]:
Hi,
On Mon, Sep 17, 2012 at 09:56:43AM -0700, Tony Lindgren wrote:
* Fengguang Wu fengguang...@intel.com [120916 17:41]:
Hi Tony,
FYI, kernel build failed on
tree:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
tmp-merge
head: a742996f4643b4e9612fe081d146035964cfbd87
commit: 7d7e1eba7e92c2f9c76db80adc24836e7a114bfb [31/47] ARM: OMAP2+:
Prepare for irqs.h removal
config: x86_64-randconfig-s331 (attached as .config)
All related error/warning messages:
drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or
directory
compilation terminated.
vim +49 drivers/mfd/twl-core.c
44 #include linux/regulator/machine.h
45
46 #include linux/i2c.h
47 #include linux/i2c/twl.h
48
49 #include plat/cpu.h
50
51 #include twl-core.h
52
53 /*
54 * The TWL4030 Triton 2 is one of a family of a
multi-function Power
OK thanks for letting me know. That include needs to be ifdeffed until
we remove all cpu_is_omap usage from drivers. I'll take a look and will
also check if other drivers may have the same issue.
the only use of cpu_is_* in that driver is related to the osc_ck clock
name. Isn't this enough ?
Well there's a bit more to it, see below..
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1855,7 +1855,7 @@ static struct omap_clk omap2430_clks[] = {
/* external root sources */
CLK(NULL, func_32k_ck, func_32k_ck, CK_243X),
CLK(NULL, secure_32k_ck, secure_32k_ck, CK_243X),
- CLK(NULL, osc_ck, osc_ck,CK_243X),
+ CLK(NULL, osc_sys_ck, osc_ck,CK_243X),
CLK(NULL, sys_ck, sys_ck,CK_243X),
CLK(NULL, alt_ck, alt_ck,CK_243X),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_243X),
That's also in use in the pm24xx code.. And is not a generic name
for other SoCs potentially using it. I have something like this here,
but now MMC somehow breaks on 2430sdp that I need to figure out..
Never mind the MMC issue, that seems to be unrelated. Will send
out a proper patch.
Tony
From 292156f6265e3b5446747de41038a19ef476b650 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Mon, 17 Sep 2012 10:47:16 -0700
Subject: [PATCH] mfd: Fix compile for twl-core.c by removing cpu_is_omap
usage
Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) broke
compile for non-omap as include plat/cpu.h was added. This header
was indirectly included earlier when SPARSE_IRQ was not set, but
does not exist on most platforms.
Fix the problem by removing the cpu_is_omap usage that should
not exist in drivers at all. We can do this by adding proper
clock aliases for the twl-core.c drivers, and drop separate
handling for cases when clock framework is not available as
the behaviour will stay the same.
Note that we need to add a platform device to avoid using the
i2c provided names that may be different on various omaps.
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 02fe1f2..7ea9139 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1856,6 +1856,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, func_32k_ck, func_32k_ck, CK_243X),
CLK(NULL, secure_32k_ck, secure_32k_ck, CK_243X),
CLK(NULL, osc_ck, osc_ck,CK_243X),
+ CLK(twl, fck, osc_ck,CK_243X),
CLK(NULL, sys_ck, sys_ck,CK_243X),
CLK(NULL, alt_ck, alt_ck,CK_243X),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 10a2398..700317a 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3226,6 +3226,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, virt_2600_ck, virt_2600_ck,
CK_3XXX),
CLK(NULL, virt_38_4m_ck, virt_38_4m_ck, CK_3XXX),
CLK(NULL, osc_sys_ck, osc_sys_ck,CK_3XXX),
+ CLK(twl, fck, osc_sys_ck,CK_3XXX),
CLK(NULL, sys_ck, sys_ck,CK_3XXX),
CLK(NULL, sys_altclk, sys_altclk,CK_3XXX),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_3XXX),
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index f462ff2..9d3a0bc 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -46,8 +46,6 @@
#include linux/i2c.h
#include linux/i2c/twl.h
-#include plat/cpu.h
-
#include
[PATCH] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) broke
compile for non-omap as include plat/cpu.h was added:
drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory
This header was indirectly included earlier when SPARSE_IRQ was not
set, but does not exist on most platforms.
Fix the problem by removing the cpu_is_omap usage that should
not exist in drivers at all. We can do this by adding proper
clock aliases for the twl-core.c drivers, and drop separate
handling for cases when clock framework is not available as
the behaviour will stay the same.
Note that we need to add a platform device to avoid using the
i2c provided names that may be different on various omaps.
Reported-by: Fengguang Wu fengguang...@intel.com
Reported-by: Stephen Rothwell s...@canb.auug.org.au
Cc: Paul Walmsley p...@pwsan.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Olof Johansson o...@lixom.net
Signed-off-by: Tony Lindgren t...@atomide.com
---
Samuel, I'd like to queue this via arm-soc as that's where I have
the breaking patch is if this patch is OK with you.
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1856,6 +1856,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, func_32k_ck, func_32k_ck, CK_243X),
CLK(NULL, secure_32k_ck, secure_32k_ck, CK_243X),
CLK(NULL, osc_ck, osc_ck,CK_243X),
+ CLK(twl, fck, osc_ck,CK_243X),
CLK(NULL, sys_ck, sys_ck,CK_243X),
CLK(NULL, alt_ck, alt_ck,CK_243X),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_243X),
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3226,6 +3226,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, virt_2600_ck, virt_2600_ck,
CK_3XXX),
CLK(NULL, virt_38_4m_ck, virt_38_4m_ck, CK_3XXX),
CLK(NULL, osc_sys_ck, osc_sys_ck,CK_3XXX),
+ CLK(twl, fck, osc_sys_ck,CK_3XXX),
CLK(NULL, sys_ck, sys_ck,CK_3XXX),
CLK(NULL, sys_altclk, sys_altclk,CK_3XXX),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_3XXX),
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -46,8 +46,6 @@
#include linux/i2c.h
#include linux/i2c/twl.h
-#include plat/cpu.h
-
#include twl-core.h
/*
@@ -1134,12 +1132,7 @@ static void clocks_init(struct device *dev,
u32 rate;
u8 ctrl = HFCLK_FREQ_26_MHZ;
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
- if (cpu_is_omap2430())
- osc = clk_get(dev, osc_ck);
- else
- osc = clk_get(dev, osc_sys_ck);
-
+ osc = clk_get(dev, fck);
if (IS_ERR(osc)) {
printk(KERN_WARNING Skipping twl internal clock init and
using bootloader value (unknown osc rate)\n);
@@ -1149,18 +1142,6 @@ static void clocks_init(struct device *dev,
rate = clk_get_rate(osc);
clk_put(osc);
-#else
- /* REVISIT for non-OMAP systems, pass the clock rate from
-* board init code, using platform_data.
-*/
- osc = ERR_PTR(-EIO);
-
- printk(KERN_WARNING Skipping twl internal clock init and
- using bootloader value (unknown osc rate)\n);
-
- return;
-#endif
-
switch (rate) {
case 1920:
ctrl = HFCLK_FREQ_19p2_MHZ;
@@ -1222,10 +1203,23 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct twl4030_platform_data*pdata = client-dev.platform_data;
struct device_node *node = client-dev.of_node;
+ struct platform_device *pdev;
int irq_base = 0;
int status;
unsignedi, num_slaves;
+ pdev = platform_device_alloc(DRIVER_NAME, -1);
+ if (!pdev) {
+ dev_err(client-dev, can't alloc pdev\n);
+ return -ENOMEM;
+ }
+
+ status = platform_device_add(pdev);
+ if (status) {
+ platform_device_put(pdev);
+ return status;
+ }
+
if (node !pdata) {
/*
* XXX: Temporary pdata until the information is correctly
@@ -1234,23 +1228,30 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
pdata = devm_kzalloc(client-dev,
sizeof(struct twl4030_platform_data),
GFP_KERNEL);
- if (!pdata)
- return -ENOMEM;
+ if (!pdata) {
+ status = -ENOMEM;
+ goto free;
+ }
}
if (!pdata) {
dev_dbg(client-dev,
Re: OMAP4: crypto acceleration (AES, SHA, ...)
* Sebastian Reichel s...@debian.org [120913 14:58]: Hi, Are there plans to add crypto acceleration support to OMAP4? Has this hardware component been removed from OMAP4? I tried to load the code written for OMAP3 on my Pandaboard, but it just outputs platform not supported: [0.370513] omap_init_sham: platform not supported [0.375488] omap_init_aes: platform not supported I recall hearing at some point that these are now available only in the secure mode? Maybe somebody from TI could check this? 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 V6 1/2] of: Add generic device tree DMA helpers
On Saturday 15 September 2012, Russell King - ARM Linux wrote: On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: 3. Supporting legacy devices not using DMA Engine These devices present a problem, as there may not be a uniform way to easily support them with regard to device tree. Ideally, these should be migrated to DMA engine. However, if this is not possible, then they should still be able to use this binding, the only constaint imposed by this implementation is that when requesting a DMA channel via of_dma_request_slave_channel(), it will return a type of dma_chan. As far as devices not using DMA engine, the answer is we don't support their specification in the DT model. Note that the legacy OMAP DMA API is scheduled for removal next year, so it's not going to be around that much longer. There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge), and I agree that they are unlikely to see OF support, although if they did, it wouldn't be unreasonable to encode their DMA channels using the same binding. The other ones that are currently around with their own DMA implementation are bcmring -- platform is going away samsung -- gradually getting moved to dmaengine, already has its own binding that needs to be replaced with this one, so best do it at the same time. tegra -- old dma code gone in 3.7 pxa/mmp -- dmaengine implementation being worked on, should wait for that. msm -- dma implementation only used by two drivers (serial and mmc). Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their own dma APIs based on the ISA interfaces. I don't currently see any of them moving towards DT, but it's definitely possible. Among the above MSM seems to be the most likely candidate to use the binding before moving to DT. The msm_sdcc driver is (like much of the msm platform code) lagging far behind the internel version that qualcomm have, and the device tree binding they are using is incompatible with the common MMC binding (and of course the DMA binding here) as well. For getting MSM up to speed compared with the other platforms, they have to use proper DT bindings as well as proper DMA engine support. Between those two, I'd prefer fixing the DT binding first, in order to limit the amount of changes that have to be done to external device tree files. Arnd -- 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] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
On Monday 17 September 2012, Tony Lindgren wrote: Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) broke compile for non-omap as include plat/cpu.h was added: drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory This header was indirectly included earlier when SPARSE_IRQ was not set, but does not exist on most platforms. Fix the problem by removing the cpu_is_omap usage that should not exist in drivers at all. We can do this by adding proper clock aliases for the twl-core.c drivers, and drop separate handling for cases when clock framework is not available as the behaviour will stay the same. Note that we need to add a platform device to avoid using the i2c provided names that may be different on various omaps. Reported-by: Fengguang Wu fengguang...@intel.com Reported-by: Stephen Rothwell s...@canb.auug.org.au Cc: Paul Walmsley p...@pwsan.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Arnd Bergmann a...@arndb.de Cc: Olof Johansson o...@lixom.net Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Arnd Bergmann a...@arndb.de -- 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/29] Move OMAP2+ over to use COMMON clock
* Paul Walmsley p...@pwsan.com [120916 13:37]: On Tue, 11 Sep 2012, Paul Walmsley wrote: Then the branch was PM-tested to determine whether it can suspend and serial-resume properly, and whether dynamic idle works. These tests didn't go so well: - 3530ES3 Beagleboard here was able to enter retention-idle suspend, and leave it with serial wakeup, but the CORE powerdomain never entered a low-power state. Dynamic retention-idle with serial wakeup never resumed, and the test stopped there: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3530es3beagle/3530es3beagle_log.txt - 37xx EVM and 3730 Beagle XM fared better; they made it through the whole test program, but the CORE powerdomain also never entered a low-power state: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/37xxevm/37xxevm_log.txt http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3730beaglexm/3730beaglexm_log.txt Thanks to debugging work by some TI LDC engineers, these two issues have been resolved. Some clockdomain associations had been removed that were necessary for the OMAP power management code to function correctly. The obvious ones have been restored to the clock data, and the branch updated. That's good news. Does that mean we should try to merge these patches for v3.7 then? Or do we still have issues remaining? 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 2/2] ARM: OMAP5: Enable arch timer support
* Benoit Cousson b-cous...@ti.com [120913 01:57]: Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yes makes sense to me. 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 2/2] ARM: OMAP5: Enable arch timer support
* Tony Lindgren t...@atomide.com [120917 14:39]: * Benoit Cousson b-cous...@ti.com [120913 01:57]: Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yes makes sense to me. These may cause bad merge conflicts with Jon's timer patches though? 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 1/1] drivers: bus: Move the OMAP interconnect driver to drivers/bus/
* Santosh Shilimkar santosh.shilim...@ti.com [120914 02:21]: OMAP interconnect drivers are used for the interconnect error handling. Since they are bus driver, lets move it to newly created drivers/bus. Cc: Arnd Bergmann a...@arndb.de Cc: Tony Lindgren t...@atomide.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- Patch just moves OMAP interconnect drivers as is to the newly created driver/bus/* directory. Patch is generated against arm-soc/drivers/ocp2scp tree and test on all OMAP boards. Great, looks like this should not conflict with other omap patches queued, so Arnd should probably take this into the bus branch: Acked-by: Tony Lindgren t...@atomide.com -- 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] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
On Mon, 17 Sep 2012, Tony Lindgren wrote: Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) broke compile for non-omap as include plat/cpu.h was added: drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory This header was indirectly included earlier when SPARSE_IRQ was not set, but does not exist on most platforms. Fix the problem by removing the cpu_is_omap usage that should not exist in drivers at all. We can do this by adding proper clock aliases for the twl-core.c drivers, and drop separate handling for cases when clock framework is not available as the behaviour will stay the same. Note that we need to add a platform device to avoid using the i2c provided names that may be different on various omaps. Reported-by: Fengguang Wu fengguang...@intel.com Reported-by: Stephen Rothwell s...@canb.auug.org.au Cc: Paul Walmsley p...@pwsan.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Arnd Bergmann a...@arndb.de Cc: Olof Johansson o...@lixom.net Signed-off-by: Tony Lindgren t...@atomide.com --- Samuel, I'd like to queue this via arm-soc as that's where I have the breaking patch is if this patch is OK with you. It would be ideal if I could queue this one, due to the clock dependency. Still hoping that we can get the CCF conversion patches in 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 00/29] Move OMAP2+ over to use COMMON clock
On Mon, 17 Sep 2012, Tony Lindgren wrote: That's good news. Does that mean we should try to merge these patches for v3.7 then? Or do we still have issues remaining? There are still problems with the OMAP4 CCF implementation. Power management is broken on some bootloaders that the original data works fine with. It's still under debug. - 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] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
* Paul Walmsley p...@pwsan.com [120917 15:09]: On Mon, 17 Sep 2012, Tony Lindgren wrote: Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) broke compile for non-omap as include plat/cpu.h was added: drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory This header was indirectly included earlier when SPARSE_IRQ was not set, but does not exist on most platforms. Fix the problem by removing the cpu_is_omap usage that should not exist in drivers at all. We can do this by adding proper clock aliases for the twl-core.c drivers, and drop separate handling for cases when clock framework is not available as the behaviour will stay the same. Note that we need to add a platform device to avoid using the i2c provided names that may be different on various omaps. Reported-by: Fengguang Wu fengguang...@intel.com Reported-by: Stephen Rothwell s...@canb.auug.org.au Cc: Paul Walmsley p...@pwsan.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Arnd Bergmann a...@arndb.de Cc: Olof Johansson o...@lixom.net Signed-off-by: Tony Lindgren t...@atomide.com --- Samuel, I'd like to queue this via arm-soc as that's where I have the breaking patch is if this patch is OK with you. It would be ideal if I could queue this one, due to the clock dependency. Still hoping that we can get the CCF conversion patches in for 3.7. We need to queue this ASAP and before other patches to fix the build breakage in linux next. Then you can merge in that commit too, does that work for you? 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] ARM: OMAP: SmartReflex: pass device dependent data via platform data
Hi,
* jean.pi...@newoldbits.com jean.pi...@newoldbits.com [120914 02:40]:
From: Jean Pihet j-pi...@ti.com
Remove the device dependent settings (cpu_is_xxx(), IP clock name)
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.
Thanks for fixing this. Looks like this should be queued by the
drivers/power/avs maintainers and there should not be merge
conflicts with other omap changes queued.
Maybe do $ scripts/get_maintainer.pl -f drivers/power/avs
and resend both patches to the maintainers?
One comment below on the clocks though..
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -122,6 +122,26 @@ 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_iva))) {
+ 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;
+ }
+ }
+
+ if (cpu_is_omap34xx())
+ strncpy(sr_data-sys_clk_name, sys_ck,
+ sizeof(sr_data-sys_clk_name));
+ else
+ strncpy(sr_data-sys_clk_name, sys_clkin_ck,
+ sizeof(sr_data-sys_clk_name));
+
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,
Here you should not pass clocks around. The driver should be able to
clk_get(dev, fck) as long as you have the proper CLK() aliases set
in the arch/arm/mach-omap2/clock*_data.c files.
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] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
On Mon, 17 Sep 2012, Tony Lindgren wrote: We need to queue this ASAP and before other patches to fix the build breakage in linux next. Then you can merge in that commit too, does that work for you? That's fine, we'll just need a stable commit then that the CCF patches can be based on. - 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] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
* Paul Walmsley p...@pwsan.com [120917 15:25]: On Mon, 17 Sep 2012, Tony Lindgren wrote: We need to queue this ASAP and before other patches to fix the build breakage in linux next. Then you can merge in that commit too, does that work for you? That's fine, we'll just need a stable commit then that the CCF patches can be based on. OK cool, will let you know that once we hear from Samuel. Care to ack the clock related changes? There's pm24xx.c at least using osc_ck naming, so I added a new alias to keep it generic for the driver instead of using omap specific names. 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 4/4] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
On Mon, 17 Sep 2012 12:53:22 +0530 AnilKumar Ch anilku...@ti.com wrote: Add lis331dlh device tree data to am335x-evm.dts. In AM335x EVM lis331dlh accelerometer is connected to I2C2 bus. So this patch change the status of I2C2 node to okay to use I2C2 bus. Also added all the required platform data to am335x-evm. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/boot/dts/am335x-evm.dts | 39 ++ Your arch/arm/boot/dts/am335x-evm.dts differs significantly from the one in linux-next (it should not do so), so I didn't do anything with this patch. -- 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 2/2] dmaengine: add helper function to request a slave DMA channel
On Mon, Sep 17, 2012 at 11:59:27AM +, Arnd Bergmann wrote:
On Monday 17 September 2012, Vinod Koul wrote:
On Fri, 2012-09-14 at 17:41 -0500, Jon Hunter wrote:
+/**
+ * dma_request_slave_channel - try to allocate an exclusive slave
channel
+ * @dev: pointer to client device structure
+ * @name: slave channel name
+ */
+struct dma_chan *dma_request_slave_channel(struct device *dev, char
*name)
+{
+ /* If device-tree is present get slave info from here */
+ if (dev-of_node)
+ return of_dma_request_slave_channel(dev-of_node, name);
+
Shouldn't this be conditionally compiled only when OF is built. I think
this might be problematic for systems which doesn't have device tree.
Or perhaps you can declare these symbols as dummy in of_dma.h when
device tree is not selected.
Right, good point. I'd prefer the dummy functions, since that is in line
with what a lot of other subsystems do:
#ifdef CONFIG_OF
extern int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data);
extern void of_dma_controller_free(struct device_node *np);
extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
char *name);
extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
{
return -ENODEV;
}
static inline void of_dma_controller_free(struct device_node *np)
{
}
static inline struct dma_chan *of_dma_request_slave_channel(struct
device_node *np,
char *name)
{
return NULL;
}
static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args
*dma_spec,
struct of_dma *ofdma)
{
return NULL;
}
#endif
I believe that Jon is on vacation this week, so if this is the only issue
holding up the merge, maybe you can change this in his patch directly, or
I can send an updated version if you prefer.
I worry that too much is going on here too quickly. We have some people
working on changing the way DMA engine selects channels. Meanwhile we
have other people trying to create an OF DMA engine API.
It seems that Vinod's working on a way for platforms to specify bindings
to the DMA engine code, and the DMA engine code itself selects the
appropriate channel. This patch, on the other hand, introduces a set of
translation functions which need to be provided by platform code,
which returns the dma_chan pointer.
This sounds like a recipe for a total abortion of interfaces. Only one
of those two activities should be going on at any one time, or if they
have to occur, they need coordination so that the we don't end up with
two totally different schemes.
In the mad rush to DTify everything, don't make hasty decisions, because
it is very difficult to change it later - especially something like this
which defines how DT encodes this information.
--
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 af...@ti.com [120917 01:40]: Hi Tony, On Fri, Sep 14, 2012 at 15:50:02, Mohammed, Afzal wrote: * Mohammed, Afzal: Wednesday, September 12, 2012 3:20 PM But some of the tusb async values is less by one. I need to get it right. Reason has been identified. It was due to rounding error, no changes are required in the expressions. Moving completely to picoseconds resolves the issue. Can you please try with the attached patch ? Gave it a quick try and it seemed to work.. But when I tried rebasing my patches for the cbus to keep things working with the watchdog, I ran into multiple merge conflicts with current linux next and gave up. Care to repost this series updated against current linux next? I'm afraid I've pretty much lost track of all the patches and rather not start resolving the conflicts as I'm sure I'll break something else :) 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] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
Hi Tony, On Mon, Sep 17, 2012 at 01:29:44PM -0700, Tony Lindgren wrote: Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) broke compile for non-omap as include plat/cpu.h was added: drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory This header was indirectly included earlier when SPARSE_IRQ was not set, but does not exist on most platforms. Fix the problem by removing the cpu_is_omap usage that should not exist in drivers at all. We can do this by adding proper clock aliases for the twl-core.c drivers, and drop separate handling for cases when clock framework is not available as the behaviour will stay the same. Note that we need to add a platform device to avoid using the i2c provided names that may be different on various omaps. Reported-by: Fengguang Wu fengguang...@intel.com Reported-by: Stephen Rothwell s...@canb.auug.org.au Cc: Paul Walmsley p...@pwsan.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Arnd Bergmann a...@arndb.de Cc: Olof Johansson o...@lixom.net Signed-off-by: Tony Lindgren t...@atomide.com --- Samuel, I'd like to queue this via arm-soc as that's where I have the breaking patch is if this patch is OK with you. That's fine with me: Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 1/2] of: Add generic device tree DMA helpers
On Mon, Sep 17, 2012 at 08:42:11PM +, Arnd Bergmann wrote: On Saturday 15 September 2012, Russell King - ARM Linux wrote: On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: 3. Supporting legacy devices not using DMA Engine These devices present a problem, as there may not be a uniform way to easily support them with regard to device tree. Ideally, these should be migrated to DMA engine. However, if this is not possible, then they should still be able to use this binding, the only constaint imposed by this implementation is that when requesting a DMA channel via of_dma_request_slave_channel(), it will return a type of dma_chan. As far as devices not using DMA engine, the answer is we don't support their specification in the DT model. Note that the legacy OMAP DMA API is scheduled for removal next year, so it's not going to be around that much longer. There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge), and I agree that they are unlikely to see OF support, although if they did, it wouldn't be unreasonable to encode their DMA channels using the same binding. The other ones that are currently around with their own DMA implementation are bcmring -- platform is going away samsung -- gradually getting moved to dmaengine, already has its own binding that needs to be replaced with this one, so best do it at the same time. tegra -- old dma code gone in 3.7 pxa/mmp -- dmaengine implementation being worked on, should wait for that. msm -- dma implementation only used by two drivers (serial and mmc). Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their own dma APIs based on the ISA interfaces. I don't currently see any of them moving towards DT, but it's definitely possible. Among the above MSM seems to be the most likely candidate to use the binding before moving to DT. The msm_sdcc driver is (like much of the msm platform code) lagging far behind the internel version that qualcomm have, and the device tree binding they are using is incompatible with the common MMC binding (and of course the DMA binding here) as well. For getting MSM up to speed compared with the other platforms, they have to use proper DT bindings as well as proper DMA engine support. Between those two, I'd prefer fixing the DT binding first, in order to limit the amount of changes that have to be done to external device tree files. There is also a lot of similarity between the mmci hardware and the msm_sdcc hardware. Enough so, that it is probably better for us to make the mmci driver work with our hardware, rather than trying to keep msm_sdcc going. There is also an MSM nand device that appears to have not made it in. It is heavily dependent on the weird features of the DMA hardware. I don't have any current plans to support this device, since most boards using MSMs these days are using mmc/sd instead of bare NAND. Our DMA hardware is really weird, but should be a bit reasonable. It is also being gradually replaced in newer chips with a different DMA framework. As far as I'm concerned, I consider making our DMA driver(s) use the DMA engine API to be part of getting these platforms working with DT. It is planned, but there are quite a few things that need to be tackled first. David -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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
* Tony Lindgren t...@atomide.com [120917 15:54]: * Mohammed, Afzal af...@ti.com [120917 01:40]: Hi Tony, On Fri, Sep 14, 2012 at 15:50:02, Mohammed, Afzal wrote: * Mohammed, Afzal: Wednesday, September 12, 2012 3:20 PM But some of the tusb async values is less by one. I need to get it right. Reason has been identified. It was due to rounding error, no changes are required in the expressions. Moving completely to picoseconds resolves the issue. Can you please try with the attached patch ? Gave it a quick try and it seemed to work.. But when I tried rebasing my patches for the cbus to keep things working with the watchdog, I ran into multiple merge conflicts with current linux next and gave up. OK went back to my original branch without current linux next and with the new cbus + retu driver from Aaro applied. Confirmed it's now working on n800 tusb6010. Care to repost this series updated against current linux next? I'm afraid I've pretty much lost track of all the patches and rather not start resolving the conflicts as I'm sure I'll break something else :) You should still repost the whole updated series against linux next. 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
[PATCH] ARM: OMAP1: Include gpio-omap.h for board-h2 and board-h3
From de6ca33a96a6bf61fcb91d3d399703e19ead9d1e Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 17 Sep 2012 16:24:20 -0700 Subject: [PATCH] ARM: OMAP1: Include gpio-omap.h for board-h2 and board-h3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Merge of the LED related changes with omap sparse IRQ and hardware.h related changes causes a build issue otherwise: arch/arm/mach-omap1/board-h2.c:319: error: implicit declaration of function ‘OMAP_MPUIO’ arch/arm/mach-omap1/board-h2.c:319: error: initializer element is not constant arch/arm/mach-omap1/board-h2.c:319: error: (near initialization for ‘h2_gpio_led_pins[1].gpio’) Signed-off-by: Tony Lindgren t...@atomide.com --- Noticed this with current linux next and omap1_defconfig. The arm-soc drivers branch builds fine, but merged with omap-cleanup-sparseirq-for-v3.7 compile breaks. I'll queue this into cleanup-fixes branch on top of the omap-cleanup-sparseirq-for-v3.7 branch. --- a/arch/arm/mach-omap1/board-h2.c +++ b/arch/arm/mach-omap1/board-h2.c @@ -31,6 +31,7 @@ #include linux/i2c/tps65010.h #include linux/smc91x.h #include linux/omapfb.h +#include linux/platform_data/gpio-omap.h #include asm/mach-types.h #include asm/mach/arch.h --- a/arch/arm/mach-omap1/board-h3.c +++ b/arch/arm/mach-omap1/board-h3.c @@ -31,6 +31,7 @@ #include linux/i2c/tps65010.h #include linux/smc91x.h #include linux/omapfb.h +#include linux/platform_data/gpio-omap.h #include asm/setup.h #include asm/page.h -- 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] cpufreq: OMAP: Check IS_ERR() instead of NULL for omap_device_get_by_hwmod_name
omap_device_get_by_hwmod_name() returns ERR_PTR on error.
Signed-off-by: Axel Lin axel@gmail.com
---
drivers/cpufreq/omap-cpufreq.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 6e22f44..65f8e9a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -266,9 +266,9 @@ static int __init omap_cpufreq_init(void)
}
mpu_dev = omap_device_get_by_hwmod_name(mpu);
- if (!mpu_dev) {
+ if (IS_ERR(mpu_dev)) {
pr_warning(%s: unable to get the mpu device\n, __func__);
- return -EINVAL;
+ return PTR_ERR(mpu_dev);
}
mpu_reg = regulator_get(mpu_dev, vcc);
--
1.7.9.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
[GIT PULL] omap fixes for linux next for v3.7 merge window
Hi Arnd Olof, Here is the fix for the twl-core compile on non-omap platforms and few other fixes. This will probably cause a minor merge conflicts with the led changes merged in the arm-soc next/drivers branch as both linux/leds.h and linux/platform_data/gpio-omap.h now need to be included. Regards, Tony The following changes since commit 68cb700c59fae6cd539c9dc1e9f2584f671935a0: ARM: OMAP1: Move SoC specific headers from plat to mach for omap1 (2012-09-12 18:06:31 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/cleanup-fixes-for-v3.7 for you to fetch changes up to de6ca33a96a6bf61fcb91d3d399703e19ead9d1e: ARM: OMAP1: Include gpio-omap.h for board-h2 and board-h3 (2012-09-17 16:28:03 -0700) These fixes are needed to fix non-omap build breakage for twl-core driver and to fix omap1_defconfig compile when led driver changes and omap sparse IRQ changes are merged together. Also fix warnings for omaps not using pinctrl framework yet. Matt Porter (1): ARM: OMAP2+: Enable pinctrl dummy states Tony Lindgren (2): mfd: Fix compile for twl-core.c by removing cpu_is_omap usage ARM: OMAP1: Include gpio-omap.h for board-h2 and board-h3 arch/arm/mach-omap1/board-h2.c |1 + arch/arm/mach-omap1/board-h3.c |1 + arch/arm/mach-omap2/clock2430_data.c |1 + arch/arm/mach-omap2/clock3xxx_data.c |1 + arch/arm/mach-omap2/devices.c|5 +++ drivers/mfd/twl-core.c | 56 ++ 6 files changed, 39 insertions(+), 26 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] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
* Tony Lindgren t...@atomide.com [120917 15:27]: * Paul Walmsley p...@pwsan.com [120917 15:25]: On Mon, 17 Sep 2012, Tony Lindgren wrote: We need to queue this ASAP and before other patches to fix the build breakage in linux next. Then you can merge in that commit too, does that work for you? That's fine, we'll just need a stable commit then that the CCF patches can be based on. OK cool, will let you know that once we hear from Samuel. Care to ack the clock related changes? There's pm24xx.c at least using osc_ck naming, so I added a new alias to keep it generic for the driver instead of using omap specific names. Pushed out now with the ack from Samuel and sent the pull request. 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: [GIT PULL] omap fixes for linux next for v3.7 merge window
Hi, On Mon, Sep 17, 2012 at 7:28 PM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Here is the fix for the twl-core compile on non-omap platforms and few other fixes. This will probably cause a minor merge conflicts with the led changes merged in the arm-soc next/drivers branch as both linux/leds.h and linux/platform_data/gpio-omap.h now need to be included. Regards, Tony The following changes since commit 68cb700c59fae6cd539c9dc1e9f2584f671935a0: ARM: OMAP1: Move SoC specific headers from plat to mach for omap1 (2012-09-12 18:06:31 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/cleanup-fixes-for-v3.7 Thanks, pulled in on top of next/cleanup. We might have missed the -next train for the day though. -Olof -- 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 2/2] dmaengine: add helper function to request a slave DMA channel
On Mon, 2012-09-17 at 11:59 +, Arnd Bergmann wrote: On Monday 17 September 2012, Vinod Koul wrote: I believe that Jon is on vacation this week, so if this is the only issue holding up the merge, maybe you can change this in his patch directly, or I can send an updated version if you prefer. Yes that was my idea as well, we do similar stuff in dmaengine. Okay I think we are good for merging this, I will add the patch for this as well. If anyone has objection please speak up _now_ -- ~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
[GIT PULL] omap device tree changes for v3.7 merge window
The following changes since commit 68cb700c59fae6cd539c9dc1e9f2584f671935a0:
ARM: OMAP1: Move SoC specific headers from plat to mach for omap1 (2012-09-12
18:06:31 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-devel-dt-merged-for-v3.7
for you to fetch changes up to 6bfc82ff589a00e5fbc12b958c649d703d273c86:
Merge tag 'omap-cleanup-sparseirq-for-v3.7' into devel-dt (2012-09-16
15:35:06 -0700)
Device tree related changes for omaps.
Note that this branch is based on omap-cleanup-sparseirq-for-v3.7
to avoid merge conflicts with the sparseirq changes for gpio-twl4030
driver.
Aneesh V (3):
Documentation: dt: device tree bindings for LPDDR2 memories
Documentation: dt: emif: device tree bindings for TI's EMIF sdram
controller
ARM: dts: EMIF and LPDDR2 device tree data for OMAP4 boards
AnilKumar Ch (5):
arm/dts: regulator: Add tps65910 device tree data
arm/dts: regulator: Add tps65217 device tree data
arm/dts: Add tps65910 regulator DT data to am335x-evm.dts
arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
ARM: OMAP2+: select PINCTRL in Kconfig
Balaji T K (1):
arm/dts: omap5: Add mmc controller nodes and board data
Benoit Cousson (3):
ARM: dts: OMAP4: Cleanup and move GIC outside of the OCP
ARM: dts: omap3-beagle: Add heartbeat and mmc LEDs support
ARM: dts: OMAP4: Add reg and interrupts for every nodes
Florian Vaussard (5):
gpio/twl4030: get platform data from device tree
ARM: dts: omap3: Add gpio-twl4030 properties for BeagleBoard and omap3-EVM
ARM: dts: OMAP3: Add support for Gumstix Overo with Tobi expansion board
Documentation: dt: Update the OMAP documentation with Overo/Toby
ARM: dts: omap3-overo: Add support for the blue LED
Olof Johansson (1):
ARM: omap: add dtb targets
Peter Ujfalusi (9):
ARM: OMAP: omap_device: Fix up resource names when booted with devicetree
ARM: dts: omap2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
ARM: dts: omap2420-h4: Include omap2420.dtsi file instead the common omap2
ARM: dts: omap3: Add McBSP entries
ARM: dts: omap4: Add McBSP entries
ARM: dts: omap4: Add reg-names for McPDM and DMIC
ARM: dts: omap5: Add McBSP entries
ARM: dts: omap5: Add McPDM and DMIC section to the dtsi file
ARM: dts: omap3-beagle: Enable audio support
Rajendra Nayak (1):
arm/dts: Cleanup regulator naming and remove @0,1
Santosh Shilimkar (2):
ARM: OMAP4: Add L2 Cache Controller in Device Tree
ARM: OMAP4: Add local timer support for Device Tree
Sourav Poddar (6):
ARM: dts: omap5-evm: Add I2C support
ARM: dts: omap5-evm: Add tmp102 sensor support
ARM: dts: omap5-evm: Add keypad data
ARM: dts: omap5-evm: Add bmp085 sensor support
ARM: dts: omap4-sdp: Add keypad data
Documentation: dt: i2c: trivial-devices: Update for tmp102
Tony Lindgren (6):
Merge branch 'devel-dt-regulator' into devel-dt
Merge branch 'for_3.7/dts' of
git://git.kernel.org/.../bcousson/linux-omap-dt into devel-dt
arm/dts: Add omap36xx.dtsi file and rename omap3-beagle to omap3-beagle-xm
arm/dts: Add pinctrl driver entries for omap2/3/4
arm/dts: Mux uart pins for omap4-sdp
Merge tag 'omap-cleanup-sparseirq-for-v3.7' into devel-dt
Vaibhav Hiremath (4):
arm/dts: AM33XX: Set the default status of module to disabled state
ARM: OMAP: omap_device: Do not overwrite resources allocated by OF layer
ARM: dts: AM33XX: Convert all hex numbers to lower-case
ARM: dts: AM33XX: Specify reg and interrupt property for all nodes
.../devicetree/bindings/arm/omap/omap.txt |3 +
.../devicetree/bindings/gpio/gpio-twl4030.txt |6 +
.../devicetree/bindings/i2c/trivial-devices.txt|1 +
.../devicetree/bindings/lpddr2/lpddr2-timings.txt | 52 ++
.../devicetree/bindings/lpddr2/lpddr2.txt | 102 ++
.../bindings/memory-controllers/ti/emif.txt| 55 ++
arch/arm/boot/dts/am335x-bone.dts | 60 ++
arch/arm/boot/dts/am335x-evm.dts | 100 ++
arch/arm/boot/dts/am33xx.dtsi | 71 ++-
arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 +++
arch/arm/boot/dts/omap2420-h4.dts |2 +-
arch/arm/boot/dts/omap2420.dtsi| 48 +
arch/arm/boot/dts/omap2430.dtsi| 92 +
.../dts/{omap3-beagle.dts = omap3-beagle-xm.dts} | 54 +-
arch/arm/boot/dts/omap3-evm.dts| 13 ++
arch/arm/boot/dts/omap3-overo.dtsi | 57 ++
arch/arm/boot/dts/omap3-tobi.dts | 35
arch/arm/boot/dts/omap3.dtsi
Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel
On Mon, 2012-09-17 at 23:36 +0100, Russell King - ARM Linux wrote: I believe that Jon is on vacation this week, so if this is the only issue holding up the merge, maybe you can change this in his patch directly, or I can send an updated version if you prefer. I worry that too much is going on here too quickly. We have some people working on changing the way DMA engine selects channels. Meanwhile we have other people trying to create an OF DMA engine API. It seems that Vinod's working on a way for platforms to specify bindings to the DMA engine code, and the DMA engine code itself selects the appropriate channel. This patch, on the other hand, introduces a set of translation functions which need to be provided by platform code, which returns the dma_chan pointer. This sounds like a recipe for a total abortion of interfaces. Only one of those two activities should be going on at any one time, or if they have to occur, they need coordination so that the we don't end up with two totally different schemes. In the mad rush to DTify everything, don't make hasty decisions, because it is very difficult to change it later - especially something like this which defines how DT encodes this information. We discussed this in KS and IMHO we need to merge these two approaches. For DT bindings, I think the binding itself shouldn't change based on my work but I would like these same bindings to help build the DMA engine code mappings. Now would it make sense to NOT merge these changes for 3.7 and postpone to 3.8. I can host these patches on a topic branch and merge them when we are ready. I plan to spend some good amount of time on my work this week so we should be ready pretty soon. One these changes are merged, users can start moving to this scheme. -- ~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
[PATCH] ARM: OMAP: OMAP_DEBUG_LEDS needs to select LEDS_CLASS
This fixes below build error when CONFIG_LEDS_CLASS is not set. LD init/built-in.o arch/arm/plat-omap/built-in.o: In function `fpga_probe': arch/arm/plat-omap/debug-leds.c:113: undefined reference to `led_classdev_register' make: *** [vmlinux] Error 1 Signed-off-by: Axel Lin axel@gmail.com --- arch/arm/plat-omap/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index ca83a76..c262781 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -43,6 +43,7 @@ config OMAP_DEBUG_DEVICES config OMAP_DEBUG_LEDS def_bool y if NEW_LEDS + select LEDS_CLASS depends on OMAP_DEBUG_DEVICES config POWER_AVS_OMAP -- 1.7.9.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] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
On Mon, Sep 17, 2012 at 01:29:44PM -0700, Tony Lindgren wrote:
Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) broke
compile for non-omap as include plat/cpu.h was added:
drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or
directory
This header was indirectly included earlier when SPARSE_IRQ was not
set, but does not exist on most platforms.
Fix the problem by removing the cpu_is_omap usage that should
not exist in drivers at all. We can do this by adding proper
clock aliases for the twl-core.c drivers, and drop separate
handling for cases when clock framework is not available as
the behaviour will stay the same.
Note that we need to add a platform device to avoid using the
i2c provided names that may be different on various omaps.
Reported-by: Fengguang Wu fengguang...@intel.com
Reported-by: Stephen Rothwell s...@canb.auug.org.au
Cc: Paul Walmsley p...@pwsan.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Olof Johansson o...@lixom.net
Signed-off-by: Tony Lindgren t...@atomide.com
FWIW:
Reviewed-by: Felipe Balbi ba...@ti.com
---
Samuel, I'd like to queue this via arm-soc as that's where I have
the breaking patch is if this patch is OK with you.
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1856,6 +1856,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, func_32k_ck, func_32k_ck, CK_243X),
CLK(NULL, secure_32k_ck, secure_32k_ck, CK_243X),
CLK(NULL, osc_ck, osc_ck,CK_243X),
+ CLK(twl, fck, osc_ck,CK_243X),
CLK(NULL, sys_ck, sys_ck,CK_243X),
CLK(NULL, alt_ck, alt_ck,CK_243X),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_243X),
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3226,6 +3226,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, virt_2600_ck, virt_2600_ck,
CK_3XXX),
CLK(NULL, virt_38_4m_ck, virt_38_4m_ck, CK_3XXX),
CLK(NULL, osc_sys_ck, osc_sys_ck,CK_3XXX),
+ CLK(twl, fck, osc_sys_ck,CK_3XXX),
CLK(NULL, sys_ck, sys_ck,CK_3XXX),
CLK(NULL, sys_altclk, sys_altclk,CK_3XXX),
CLK(NULL, mcbsp_clks, mcbsp_clks,CK_3XXX),
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -46,8 +46,6 @@
#include linux/i2c.h
#include linux/i2c/twl.h
-#include plat/cpu.h
-
#include twl-core.h
/*
@@ -1134,12 +1132,7 @@ static void clocks_init(struct device *dev,
u32 rate;
u8 ctrl = HFCLK_FREQ_26_MHZ;
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
- if (cpu_is_omap2430())
- osc = clk_get(dev, osc_ck);
- else
- osc = clk_get(dev, osc_sys_ck);
-
+ osc = clk_get(dev, fck);
if (IS_ERR(osc)) {
printk(KERN_WARNING Skipping twl internal clock init and
using bootloader value (unknown osc rate)\n);
@@ -1149,18 +1142,6 @@ static void clocks_init(struct device *dev,
rate = clk_get_rate(osc);
clk_put(osc);
-#else
- /* REVISIT for non-OMAP systems, pass the clock rate from
- * board init code, using platform_data.
- */
- osc = ERR_PTR(-EIO);
-
- printk(KERN_WARNING Skipping twl internal clock init and
-using bootloader value (unknown osc rate)\n);
-
- return;
-#endif
-
switch (rate) {
case 1920:
ctrl = HFCLK_FREQ_19p2_MHZ;
@@ -1222,10 +1203,23 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct twl4030_platform_data*pdata = client-dev.platform_data;
struct device_node *node = client-dev.of_node;
+ struct platform_device *pdev;
int irq_base = 0;
int status;
unsignedi, num_slaves;
+ pdev = platform_device_alloc(DRIVER_NAME, -1);
+ if (!pdev) {
+ dev_err(client-dev, can't alloc pdev\n);
+ return -ENOMEM;
+ }
+
+ status = platform_device_add(pdev);
+ if (status) {
+ platform_device_put(pdev);
+ return status;
+ }
+
if (node !pdata) {
/*
* XXX: Temporary pdata until the information is correctly
@@ -1234,23 +1228,30 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
pdata = devm_kzalloc(client-dev,
sizeof(struct twl4030_platform_data),
GFP_KERNEL);
- if (!pdata)
- return -ENOMEM;
+ if (!pdata) {
+ status = -ENOMEM;
+
Re: [PATCH v2 1/2] spi: omap2-mcspi: add pinctrl support
On Monday 17 September 2012 10:52 PM, Matt Porter wrote:
Adds pinctrl support to support OMAP platforms that boot from DT
and rely on pinctrl support to set pinmuxes.
Signed-off-by: Matt Porter mpor...@ti.com
---
looks good to me.
you may want to repost with Mark in cc to review.
Acked-by: Shubhrajyoti D shubhrajy...@ti.com
drivers/spi/spi-omap2-mcspi.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b2fb141..9502566 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -38,6 +38,8 @@
#include linux/pm_runtime.h
#include linux/of.h
#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
#include linux/spi/spi.h
@@ -1124,6 +1126,7 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
static int bus_num = 1;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
+ struct pinctrl *pinctrl;
master = spi_alloc_master(pdev-dev, sizeof *mcspi);
if (master == NULL) {
@@ -1219,6 +1222,11 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
if (status 0)
goto dma_chnl_free;
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev,
+ pins are not configured from the driver\n);
+
pm_runtime_use_autosuspend(pdev-dev);
pm_runtime_set_autosuspend_delay(pdev-dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(pdev-dev);
--
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 v2] arm/dts: AM33XX: Add SPI device tree data
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Tested-by: Matt Porter mpor...@ti.com
---
Changes since v1:
- Corrected reg offset in reg DT entry.
:100644 100644 ff3badb... 065fd54... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index ff3badb..065fd54 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -219,5 +219,30 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt-parent = intc;
+ interrupt = 65;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi0;
+ status = disabled;
+
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt-parent = intc;
+ interrupt = 125;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi1;
+ status = disabled;
+ };
};
};
--
1.7.4.1
--
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
