[PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
Hi, The i2c drivers also do not have to set 'owner' field because i2c_register_driver() will do it instead. 'owner' is removed from i2c drivers, which I was able to compile with allyesconfig (arm, arm64, i386, x86_64, ppc64). Only compile-tested. The coccinelle script which generated the patch was sent here: http://www.spinics.net/lists/kernel/msg2029903.html Best regards, Krzysztof Krzysztof Kozlowski (2): video: fbdev: Drop owner assignment from i2c_driver video: fbdev: Drop owner assignment from platform_driver drivers/video/fbdev/omap2/displays-new/encoder-opa362.c | 1 - drivers/video/fbdev/ssd1307fb.c | 1 - 2 files changed, 2 deletions(-) -- 1.9.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
[PATCH 1/2] video: fbdev: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/video/fbdev/ssd1307fb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 3e153c06131a..b6edd28b267f 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -719,7 +719,6 @@ static struct i2c_driver ssd1307fb_driver = {
.driver = {
.name = ssd1307fb,
.of_match_table = ssd1307fb_of_match,
- .owner = THIS_MODULE,
},
};
--
1.9.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
Re: [PATCH] mfd: Drop owner assignment from i2c_drivers
On Fri, 10 Jul 2015, Krzysztof Kozlowski wrote:
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/mfd/88pm800.c | 1 -
drivers/mfd/88pm805.c | 1 -
drivers/mfd/88pm860x-core.c | 1 -
drivers/mfd/aat2870-core.c| 1 -
drivers/mfd/ab3100-core.c | 1 -
drivers/mfd/adp5520.c | 1 -
drivers/mfd/arizona-i2c.c | 1 -
drivers/mfd/as3711.c | 1 -
drivers/mfd/as3722.c | 1 -
drivers/mfd/axp20x.c | 1 -
drivers/mfd/bcm590xx.c| 1 -
drivers/mfd/cros_ec_i2c.c | 1 -
drivers/mfd/da903x.c | 1 -
drivers/mfd/da9052-i2c.c | 1 -
drivers/mfd/da9055-i2c.c | 1 -
drivers/mfd/da9063-i2c.c | 1 -
drivers/mfd/intel_soc_pmic_core.c | 1 -
drivers/mfd/lm3533-core.c | 1 -
drivers/mfd/lp3943.c | 1 -
drivers/mfd/lp8788.c | 1 -
drivers/mfd/max14577.c| 1 -
drivers/mfd/max77686.c| 1 -
drivers/mfd/max77693.c| 1 -
drivers/mfd/max8907.c | 1 -
drivers/mfd/max8925-i2c.c | 1 -
drivers/mfd/max8997.c | 1 -
drivers/mfd/max8998.c | 1 -
drivers/mfd/mc13xxx-i2c.c | 1 -
drivers/mfd/palmas.c | 1 -
drivers/mfd/rc5t583.c | 1 -
drivers/mfd/retu-mfd.c| 1 -
drivers/mfd/sec-core.c| 1 -
drivers/mfd/si476x-i2c.c | 1 -
drivers/mfd/smsc-ece1099.c| 1 -
drivers/mfd/stmpe-i2c.c | 1 -
drivers/mfd/tc3589x.c | 1 -
drivers/mfd/tps6507x.c| 1 -
drivers/mfd/tps65090.c| 1 -
drivers/mfd/tps65217.c| 1 -
drivers/mfd/tps65218.c| 1 -
drivers/mfd/tps6586x.c| 1 -
drivers/mfd/tps65910.c| 1 -
drivers/mfd/tps65912-i2c.c| 1 -
drivers/mfd/tps80031.c| 1 -
drivers/mfd/twl6040.c | 1 -
drivers/mfd/wm831x-i2c.c | 1 -
drivers/mfd/wm8350-i2c.c | 1 -
drivers/mfd/wm8400-core.c | 1 -
drivers/mfd/wm8994-core.c | 1 -
49 files changed, 49 deletions(-)
Applied, thanks.
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 841717a2842c..f2d9fb4c4e8e 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -609,7 +609,6 @@ static int pm800_remove(struct i2c_client *client)
static struct i2c_driver pm800_driver = {
.driver = {
.name = 88PM800,
- .owner = THIS_MODULE,
.pm = pm80x_pm_ops,
},
.probe = pm800_probe,
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index e9d50644660c..39f2302e137b 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -267,7 +267,6 @@ static int pm805_remove(struct i2c_client *client)
static struct i2c_driver pm805_driver = {
.driver = {
.name = 88PM805,
- .owner = THIS_MODULE,
.pm = pm80x_pm_ops,
},
.probe = pm805_probe,
diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index e03b7f45b8f7..cb47d6e00ebe 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -1258,7 +1258,6 @@ MODULE_DEVICE_TABLE(of, pm860x_dt_ids);
static struct i2c_driver pm860x_driver = {
.driver = {
.name = 88PM860x,
- .owner = THIS_MODULE,
.pm = pm860x_pm_ops,
.of_match_table = pm860x_dt_ids,
},
diff --git a/drivers/mfd/aat2870-core.c b/drivers/mfd/aat2870-core.c
index 4e6e03d63e12..29b6a2d4ac72 100644
--- a/drivers/mfd/aat2870-core.c
+++ b/drivers/mfd/aat2870-core.c
@@ -500,7 +500,6 @@ MODULE_DEVICE_TABLE(i2c, aat2870_i2c_id_table);
static struct i2c_driver aat2870_i2c_driver = {
.driver = {
.name = aat2870,
- .owner = THIS_MODULE,
.pm = aat2870_pm_ops,
},
.probe = aat2870_i2c_probe,
diff --git a/drivers/mfd/ab3100-core.c b/drivers/mfd/ab3100-core.c
index 4659ac1db039..f0afb44271f8 100644
--- a/drivers/mfd/ab3100-core.c
+++ b/drivers/mfd/ab3100-core.c
@@ -972,7 +972,6 @@ MODULE_DEVICE_TABLE(i2c, ab3100_id);
static struct i2c_driver ab3100_driver = {
.driver = {
.name = ab3100,
- .owner = THIS_MODULE,
},
.id_table = ab3100_id,
.probe = ab3100_probe,
diff --git a/drivers/mfd/adp5520.c b/drivers/mfd/adp5520.c
index f495b8b57dd7..ae88654595dc 100644
--- a/drivers/mfd/adp5520.c
+++ b/drivers/mfd/adp5520.c
@@ -351,7 +351,6 @@ MODULE_DEVICE_TABLE(i2c, adp5520_id);
static struct i2c_driver
[PATCH 2/2] video: fbdev: Drop owner assignment from platform_driver
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/video/fbdev/omap2/displays-new/encoder-opa362.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
b/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
index a14d993f719d..8c246c213e06 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
@@ -266,7 +266,6 @@ static struct platform_driver opa362_driver = {
.remove = __exit_p(opa362_remove),
.driver = {
.name = amplifier-opa362,
- .owner = THIS_MODULE,
.of_match_table = opa362_of_match,
.suppress_bind_attrs = true,
},
--
1.9.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
Re: [RFC PATCH] i2c: busses: i2c-omap: Increase timeout for i2c interrupt
Hi Vignesh, On 10/07/15 07:09, ext Vignesh R wrote: When system is under load and there is an i2c transaction running following warning appears on the console: [ 730.003617] omap_i2c 4807.i2c: controller timed out [ 731.023643] omap_i2c 4807.i2c: controller timed out This is because, the completion() call, which is done in bottom half of the interrupt handler, happens after the timeout period(1s) has elapsed for the wait_for_completion_timeout() in omap_i2c_xfer_msg(). The interrupt is raised within a second but due to system load (or other interrupts), the bottom half does not get scheduled within a second. I would say, if your system cannot handle an interrupt within 1 second, you have more severe problems than just too small I2C timeout value. Hence even though the interrupt has happened within required time frame, due to delayed scheduling of bottom half, spurious timeout errors are reported on the console and i2c controller is reset. i2c timeout is a rare condition, hence increase timeout to 60s in order to avoid reporting false timeout events under load. 60 s sounds way too much and actually I simply don't believe this is the root cause. If I take a look into the driver, then I see, that the design is not really the best. The whole IRQ handling could be actually performed in hard IRQ handler, without threading overhead. Putting even 2 bytes in the controller FIFO should not be too heavy for the hard IRQ handler. Then these ridiculous spin_lock()s. What is the reason behind? The IRQ is flagged with ONESHOT, so thread and hardirq handler are anyway mutually excluded. But if this thread ever runs longer than it's allowed in IRQ context, then it anyway produces this IRQ latency because it locks spin_lock_irqsave() for the whole time! So the whole point of threaded interrupt is missing. I would propose you to throw away spinlocks. Convert threaded IRQ to just one hardirq handler. And continue debugging. You will reduce the load of the system with the above measures, maybe it will not happen any more, maybe you'll figure out that problem is somewhere else. Signed-off-by: Vignesh R vigne...@ti.com --- I reproduced this while running i2cdump in a loop and reading from flash using dd command. drivers/i2c/busses/i2c-omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index d1c22e3fdd14..fa7758f0302c 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -50,7 +50,7 @@ #define OMAP_I2C_REV_ON_4430_PLUS0x5042 /* timeout waiting for the controller to respond */ -#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000)) +#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(60 * 1000)) /* timeout for pm runtime autosuspend */ #define OMAP_I2C_PM_TIMEOUT 1000/* ms */ -- Best regards, Alexander Sverdlin. -- 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] i2c: busses: i2c-omap: Increase timeout for i2c interrupt
60 s sounds way too much and actually I simply don't believe this is the root cause. If I take a look into the driver, then I see, that I agree, this is just a workaround. the design is not really the best. The whole IRQ handling could be actually performed in hard IRQ handler, without threading overhead. Putting even 2 bytes in the controller FIFO should not be too heavy for the hard IRQ handler. Then these ridiculous spin_lock()s. What is the reason behind? The IRQ is flagged with ONESHOT, so thread and hardirq handler are anyway mutually excluded. But if this thread ever runs longer than it's allowed in IRQ context, then it anyway produces this IRQ latency because it locks spin_lock_irqsave() for the whole time! So the whole point of threaded interrupt is missing. Furthermore, this combination of threaded_irq and struct completion seems bogus to me. If you just want to ensure the irq happened before timeout, you just complete when the irq happened and do the bottom half after the completion returned? I would propose you to throw away spinlocks. Convert threaded IRQ to just one hardirq handler. And continue debugging. You will reduce the load of the system with the above measures, maybe it will not happen any more, maybe you'll figure out that problem is somewhere else. Or this. Felipe converted it to threaded_irq, maybe he has something to add? signature.asc Description: Digital signature
Re: [PATCH v3 02/11] usb: otg-fsm: support multiple instances
On Wed, Jul 08, 2015 at 01:19:28PM +0300, Roger Quadros wrote:
Move the state_changed variable into struct otg_fsm
so that we can support multiple instances.
I am not sure if multiple instances may happen since OTG protocol requires
only one OTG port can be equipped on OTG device.
Li Jun
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg-fsm.c | 10 --
include/linux/usb/otg-fsm.h | 1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c
b/drivers/usb/common/usb-otg-fsm.c
index 61d538a..42c6376 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -61,8 +61,6 @@ static int otg_set_protocol(struct otg_fsm *fsm, int
protocol)
return 0;
}
-static int state_changed;
-
/* Called when leaving a state. Do state clean up jobs here */
static void otg_leave_state(struct otg_fsm *fsm, enum usb_otg_state
old_state)
{
@@ -123,7 +121,7 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
usb_otg_state old_state)
/* Called when entering a state */
static int otg_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
{
- state_changed = 1;
+ fsm-state_changed = 1;
if (fsm-otg-state == new_state)
return 0;
fsm-state_changed = 1; should be put here, I think.
Li Jun
VDBG(Set state: %s\n, usb_otg_state_string(new_state));
@@ -248,7 +246,7 @@ int otg_statemachine(struct otg_fsm *fsm)
mutex_lock(fsm-lock);
state = fsm-otg-state;
- state_changed = 0;
+ fsm-state_changed = 0;
/* State machine state change judgement */
switch (state) {
@@ -361,7 +359,7 @@ int otg_statemachine(struct otg_fsm *fsm)
}
mutex_unlock(fsm-lock);
- VDBG(quit statemachine, changed = %d\n, state_changed);
- return state_changed;
+ VDBG(quit statemachine, changed = %d\n, fsm-state_changed);
+ return fsm-state_changed;
}
EXPORT_SYMBOL_GPL(otg_statemachine);
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index ca508c2..243274f 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -194,6 +194,7 @@ struct otg_fsm {
/* Current usb protocol used: 0:undefine; 1:host; 2:client */
int protocol;
struct mutex lock;
+ bool state_changed;
};
struct otg_fsm_ops {
--
2.1.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: musb-hdrc: Vbus off, timeout 1100 msec message does not belong in sysfs
On 07/09/2015 11:46 PM, Pavel Machek wrote: On Thu 2015-07-09 23:39:22, Pavel Machek wrote: Hi! Hi, sysfs should contain one value per file. This one has at least two, with nice english sentence as a bonus. root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto# cat vbus Vbus off, timeout 1100 msec :-(. Plus, documentation for this is nowhere to be seen: pavel@amd:/data/l/linux-n900$ grep -ri musb Documentation/ABI/ pavel@amd:/data/l/linux-n900$ that is a shame indeed. It is part of the driver since TUSB support was merged via commit 550a7375f (USB: Add MUSB and TUSB support) about 7 years ago. The parameter expects the timeout values which is used to poll the port for mode changes (host/device mode) since it can not be detected on its own. Felipe knows best if it is better to document it or remove it. I can't remember that I needed it on am335x. Pavel Sebastian -- 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] i2c: busses: i2c-omap: Increase timeout for i2c interrupt
Vignesh, On 10/07/15 08:09, Vignesh R wrote: When system is under load and there is an i2c transaction running following warning appears on the console: [ 730.003617] omap_i2c 4807.i2c: controller timed out [ 731.023643] omap_i2c 4807.i2c: controller timed out This is because, the completion() call, which is done in bottom half of the interrupt handler, happens after the timeout period(1s) has elapsed for the wait_for_completion_timeout() in omap_i2c_xfer_msg(). The interrupt is raised within a second but due to system load (or other interrupts), the bottom half does not get scheduled within a second. Hence even though the interrupt has happened within required time frame, due to delayed scheduling of bottom half, spurious timeout errors are reported on the console and i2c controller is reset. i2c timeout is a rare condition, hence increase timeout to 60s in order to avoid reporting false timeout events under load. why not 5s instead of 60s? cheers, -roger Signed-off-by: Vignesh R vigne...@ti.com --- I reproduced this while running i2cdump in a loop and reading from flash using dd command. drivers/i2c/busses/i2c-omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index d1c22e3fdd14..fa7758f0302c 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -50,7 +50,7 @@ #define OMAP_I2C_REV_ON_4430_PLUS0x5042 /* timeout waiting for the controller to respond */ -#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000)) +#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(60 * 1000)) /* timeout for pm runtime autosuspend */ #define OMAP_I2C_PM_TIMEOUT 1000/* ms */ -- 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 00/11] USB: OTG/DRD Core functionality
On Wed, Jul 08, 2015 at 01:19:26PM +0300, Roger Quadros wrote: Hi, This series centralizes OTG/Dual-role functionality in the kernel. As of now I've got Dual-role functionality working pretty reliably on dra7-evm and am437x-gp-evm. xhci side of things for OTG/DRD use are already in v4.2 Do you have any plan to implement OTG(HNP) on some of your platforms based on this OTG core? Li Jun http://thread.gmane.org/gmane.linux.kernel/1923161 DWC3 controller and platform related patches are sent separately. Changelog: -- 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 10/12] memory: omap-gpmc: Prevent mapping into 1st 16MB
We have been preventing mapping GPMC children in the
first 1MB but really it has to be the first 16MB as
the minimum GPMC partition size is 16MB.
Also print an error message if CS mapping fails
due to DT requesting address outside the GPMC
map.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/memory/omap-gpmc.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index f19edc2..8b434fc 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -80,6 +80,14 @@
#define GPMC_CS_SIZE 0x30
#defineGPMC_BCH_SIZE 0x10
+/*
+ * The first 1MB of GPMC address space is typically mapped to
+ * the internal ROM. Never allocate the first page, to
+ * facilitate bug detection; even if we didn't boot from ROM.
+ * As GPMC minimum partition size is 16MB we can only start from
+ * there.
+ */
+#define GPMC_MEM_START 0x100
#define GPMC_MEM_END 0x3FFF
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
@@ -1012,12 +1020,7 @@ static void gpmc_mem_init(void)
{
int cs;
- /*
-* The first 1MB of GPMC address space is typically mapped to
-* the internal ROM. Never allocate the first page, to
-* facilitate bug detection; even if we didn't boot from ROM.
-*/
- gpmc_mem_root.start = SZ_1M;
+ gpmc_mem_root.start = GPMC_MEM_START;
gpmc_mem_root.end = GPMC_MEM_END;
/* Reserve all regions that has been set up by bootloader */
@@ -1671,6 +1674,15 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
if (ret 0) {
dev_err(pdev-dev, cannot remap GPMC CS %d to %pa\n,
cs, res.start);
+ if (res.start GPMC_MEM_START) {
+ dev_info(pdev-dev,
+GPMC CS %d start cannot be lesser than
0x%x\n,
+cs, GPMC_MEM_START);
+ } else if (res.end GPMC_MEM_END) {
+ dev_info(pdev-dev,
+GPMC CS %d end cannot be greater than 0x%x\n,
+cs, GPMC_MEM_END);
+ }
goto err;
}
--
2.1.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 00/12] ARM: omap: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi, The OMAP GPMC IP is being used on non-OMAP platforms as well and this series aims at cleaning up device tree implementation for GPMC NAND so that it can be used on non-OMAP platforms. NAND is now treated as any other generic GPMC child and has to have its own compatible-id and address+interrupt resource. Tested NAND on following boards - dra7-evm - am437x-gp-evm - beagleboard C4 -- cheers, -roger Roger Quadros (12): ARM: OMAP2+: gpmc: Add platform data ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data mtd: nand: omap: Move IRQ handling from GPMC to NAND driver mtd: nand: omap: Move gpmc_update_nand_reg to nand driver mtd: nand: omap: Move NAND write protect code from GPMC to NAND driver mtd: nand: omap: Copy platform data parameters to omap_nand_info data mtd: nand: omap: Clean up device tree support mtd: nand: omap: Update DT binding documentation memory: omap-gpmc: use module_platform_driver() memory: omap-gpmc: Prevent mapping into 1st 16MB ARM: dts: OMAP2+: Fix NAND device nodes ARM: dts: omap3: Fix gpmc memory resource size .../devicetree/bindings/mtd/gpmc-nand.txt | 16 +- arch/arm/boot/dts/am335x-baltos-ir5221.dts | 9 +- arch/arm/boot/dts/am335x-chilisom.dtsi | 8 +- arch/arm/boot/dts/am335x-evm.dts | 8 +- arch/arm/boot/dts/am335x-igep0033.dtsi | 8 +- arch/arm/boot/dts/am437x-gp-evm.dts| 8 +- arch/arm/boot/dts/am43x-epos-evm.dts | 8 +- arch/arm/boot/dts/dm8168-evm.dts | 8 +- arch/arm/boot/dts/dra7-evm.dts | 8 +- arch/arm/boot/dts/dra72-evm.dts| 8 +- arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 9 +- arch/arm/boot/dts/omap3-beagle.dts | 7 +- arch/arm/boot/dts/omap3-cm-t3x.dtsi| 8 +- arch/arm/boot/dts/omap3-devkit8000.dts | 9 +- arch/arm/boot/dts/omap3-evm-37xx.dts | 10 +- arch/arm/boot/dts/omap3-gta04.dtsi | 8 +- arch/arm/boot/dts/omap3-igep.dtsi | 5 +- arch/arm/boot/dts/omap3-igep0020-common.dtsi | 5 +- arch/arm/boot/dts/omap3-igep0030-common.dtsi | 6 + arch/arm/boot/dts/omap3-ldp.dts| 10 +- arch/arm/boot/dts/omap3-lilly-a83x.dtsi| 8 +- arch/arm/boot/dts/omap3-lilly-dbb056.dts | 7 +- arch/arm/boot/dts/omap3-pandora-common.dtsi| 8 +- arch/arm/boot/dts/omap3-tao3530.dtsi | 8 +- arch/arm/boot/dts/omap3.dtsi | 2 +- arch/arm/boot/dts/omap3430-sdp.dts | 8 +- arch/arm/mach-omap2/gpmc-nand.c| 19 +- drivers/memory/omap-gpmc.c | 427 +++-- drivers/mtd/nand/omap2.c | 380 ++ include/linux/omap-gpmc.h | 148 +-- include/linux/platform_data/gpmc-omap.h| 169 include/linux/platform_data/mtd-nand-omap2.h | 10 +- 32 files changed, 705 insertions(+), 655 deletions(-) create mode 100644 include/linux/platform_data/gpmc-omap.h -- 2.1.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 05/12] mtd: nand: omap: Move NAND write protect code from GPMC to NAND driver
The write protect (WP) pin is only used for NAND devices. So move
the code into the NAND driver.
Get rid of gpmc_configure() as it is no longer used.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 4
drivers/memory/omap-gpmc.c | 30
drivers/mtd/nand/omap2.c | 23 +
include/linux/omap-gpmc.h| 3 ---
include/linux/platform_data/mtd-nand-omap2.h | 1 +
5 files changed, 24 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index ff578d4..9cb8ce6 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -117,10 +117,6 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
if (err 0)
goto out_free_cs;
- err = gpmc_configure(GPMC_CONFIG_WP, 0);
- if (err 0)
- goto out_free_cs;
-
if (!gpmc_hwecc_bch_capable(gpmc_nand_data-ecc_opt)) {
pr_err(omap2-nand: Unsupported NAND ECC scheme selected\n);
err = -EINVAL;
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index dd55a51..650f9b8 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -151,7 +151,6 @@
#define GPMC_DEVICETYPE_NOR0
#define GPMC_DEVICETYPE_NAND 2
-#define GPMC_CONFIG_WRITEPROTECT 0x0010
#define WR_RD_PIN_MONITORING 0x0060
/* ECC commands */
@@ -987,35 +986,6 @@ void gpmc_cs_free(int cs)
}
EXPORT_SYMBOL(gpmc_cs_free);
-/**
- * gpmc_configure - write request to configure gpmc
- * @cmd: command type
- * @wval: value to write
- * @return status of the operation
- */
-int gpmc_configure(int cmd, int wval)
-{
- u32 regval;
-
- switch (cmd) {
- case GPMC_CONFIG_WP:
- regval = gpmc_read_reg(GPMC_CONFIG);
- if (wval)
- regval = ~GPMC_CONFIG_WRITEPROTECT; /* WP is ON */
- else
- regval |= GPMC_CONFIG_WRITEPROTECT; /* WP is OFF */
- gpmc_write_reg(GPMC_CONFIG, regval);
- break;
-
- default:
- pr_err(%s: command not supported\n, __func__);
- return -EINVAL;
- }
-
- return 0;
-}
-EXPORT_SYMBOL(gpmc_configure);
-
void gpmc_get_mem_resource(struct resource *res)
{
res-start = phys_base;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 3d0f73c..25a3d05 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -140,6 +140,9 @@
#define GPMC_IRQ_FIFOEVENT BIT(0)
#define GPMC_IRQ_TERMCOUNT BIT(1)
+/* GPMC_CONFIG register bits */
+#define GPMC_CONFIG_WRITEPROTECT BIT(4)
+
/* GPMC register offsets */
#define GPMC_REVISION 0x00
#define GPMC_SYSCONFIG 0x10
@@ -215,6 +218,22 @@ struct omap_nand_info {
};
/**
+ * omap_nand_writeprotect - Control the WP line to the NAND chip
+ */
+static void omap_nand_writeprotect(struct omap_nand_info *info, bool on)
+{
+ u32 val;
+
+ val = readl(info-reg.gpmc_config);
+ if (on)
+ val = GPMC_CONFIG_WRITEPROTECT; /* WP pin is active low */
+ else
+ val |= GPMC_CONFIG_WRITEPROTECT;
+
+ writel(val, info-reg.gpmc_config);
+}
+
+/**
* omap_prefetch_enable - configures and starts prefetch transfer
* @cs: cs (chip select) number
* @fifo_th: fifo threshold to be used for read/ write
@@ -1713,6 +1732,7 @@ static void gpmc_update_nand_reg(struct omap_nand_info
*info)
int cs = info-gpmc_cs;
void __iomem *gpmc_base = info-gpmc_base;
+ reg-gpmc_config = gpmc_base + GPMC_CONFIG;
reg-gpmc_status = gpmc_base + GPMC_STATUS;
reg-gpmc_irqstatus = gpmc_base + GPMC_IRQSTATUS;
reg-gpmc_irqenable = gpmc_base + GPMC_IRQENABLE;
@@ -2141,6 +2161,9 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip-ecc.layout = ecclayout;
scan_tail:
+ /* turn off write protect */
+ omap_nand_writeprotect(info, false);
+
/* second phase scan */
if (nand_scan_tail(mtd)) {
err = -ENXIO;
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 36f33ba..d13e172 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -10,8 +10,6 @@
#include linux/platform_data/gpmc-omap.h
#include linux/ioport.h
-#define GPMC_CONFIG_WP 0x0005
-
extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
struct gpmc_settings *gpmc_s,
struct gpmc_device_timings *dev_t);
@@ -31,7 +29,6 @@ extern int gpmc_cs_set_timings(int cs, const struct
gpmc_timings *t,
extern int gpmc_cs_program_settings(int cs, struct gpmc_settings *p);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
[PATCH 01/12] ARM: OMAP2+: gpmc: Add platform data
Add a platform data structure for GPMC. It contains all the necessary
platform information that needs to be passed from platform init code
to GPMC driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
include/linux/omap-gpmc.h | 3 +--
include/linux/platform_data/gpmc-omap.h | 30 ++
2 files changed, 31 insertions(+), 2 deletions(-)
create mode 100644 include/linux/platform_data/gpmc-omap.h
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 7dee0014..5c79190 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -7,8 +7,7 @@
* option) any later version.
*/
-/* Maximum Number of Chip Selects */
-#define GPMC_CS_NUM8
+#include linux/platform_data/gpmc-omap.h
#define GPMC_CONFIG_WP 0x0005
diff --git a/include/linux/platform_data/gpmc-omap.h
b/include/linux/platform_data/gpmc-omap.h
new file mode 100644
index 000..d32d9de
--- /dev/null
+++ b/include/linux/platform_data/gpmc-omap.h
@@ -0,0 +1,30 @@
+/*
+ * OMAP GPMC Platform data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc. - http://www.ti.com
+ * Roger Quadros rog...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef _GPMC_OMAP_H_
+#define _GPMC_OMAP_H_
+
+/* Maximum Number of Chip Selects */
+#define GPMC_CS_NUM8
+
+/* Data for each chip select */
+struct gpmc_omap_cs_data {
+ bool valid; /* data is valid */
+ bool is_nand; /* device within this CS is NAND */
+ struct platform_device *pdev; /* device within this CS region */
+ unsigned pdata_size;
+};
+
+struct gpmc_omap_platform_data {
+ struct gpmc_omap_cs_data cs[GPMC_CS_NUM];
+};
+
+#endif /* _GPMC_OMAP_H */
--
2.1.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 12/12] ARM: dts: omap3: Fix gpmc memory resource size
The last register address is offset at 0x2d0 but is a
4 bit register. So total GPMC register resource size
is 0x2d4
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 69a40cf..f9623f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -714,7 +714,7 @@
gpmc: gpmc@6e00 {
compatible = ti,omap3430-gpmc;
ti,hwmods = gpmc;
- reg = 0x6e00 0x02d0;
+ reg = 0x6e00 0x02d4;
interrupts = 20;
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
--
2.1.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 04/12] mtd: nand: omap: Move gpmc_update_nand_reg to nand driver
GPMC and NAND drivers share the same register space but never use the
same registers. As there is no clear address seperation between the
registers for GPMC and NAND, we can't easily split it up into 2 regions
i.e. one for GPMC and other for NAND. Instead, we simply remap the entire
register space in both the drivers. The NAND driver doesn't re-request
the region as it is already requested by the GPMC driver (parent).
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 8 +-
drivers/memory/omap-gpmc.c | 54 +--
drivers/mtd/nand/omap2.c | 132 ---
include/linux/omap-gpmc.h| 3 +-
include/linux/platform_data/mtd-nand-omap2.h | 3 +-
5 files changed, 129 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index b960876..ff578d4 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -78,7 +78,8 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
struct gpmc_settings s;
struct platform_device *pdev;
struct resource gpmc_nand_res[] = {
- { .flags = IORESOURCE_MEM, },
+ { .flags = IORESOURCE_MEM, }, /* GPMC I/O space */
+ { .flags = IORESOURCE_MEM, }, /* GPMC register space */
{ .flags = IORESOURCE_IRQ, },
};
@@ -92,7 +93,8 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
return err;
}
gpmc_nand_res[0].end = gpmc_nand_res[0].start + NAND_IO_SIZE - 1;
- gpmc_nand_res[1].start = gpmc_get_irq();
+ gpmc_get_mem_resource(gpmc_nand_res[1]);
+ gpmc_nand_res[2].start = gpmc_get_irq();
memset(s, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data-of_node)
@@ -119,8 +121,6 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
if (err 0)
goto out_free_cs;
- gpmc_update_nand_reg(gpmc_nand_data-reg, gpmc_nand_data-cs);
-
if (!gpmc_hwecc_bch_capable(gpmc_nand_data-ecc_opt)) {
pr_err(omap2-nand: Unsupported NAND ECC scheme selected\n);
err = -EINVAL;
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 50806e7..dd55a51 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -54,17 +54,6 @@
#define GPMC_PREFETCH_CONFIG2 0x1e4
#define GPMC_PREFETCH_CONTROL 0x1ec
#define GPMC_PREFETCH_STATUS 0x1f0
-#define GPMC_ECC_CONFIG0x1f4
-#define GPMC_ECC_CONTROL 0x1f8
-#define GPMC_ECC_SIZE_CONFIG 0x1fc
-#define GPMC_ECC1_RESULT0x200
-#define GPMC_ECC_BCH_RESULT_0 0x240 /* not available on OMAP2 */
-#defineGPMC_ECC_BCH_RESULT_1 0x244 /* not available on OMAP2 */
-#defineGPMC_ECC_BCH_RESULT_2 0x248 /* not available on OMAP2 */
-#defineGPMC_ECC_BCH_RESULT_3 0x24c /* not available on OMAP2 */
-#defineGPMC_ECC_BCH_RESULT_4 0x300 /* not available on OMAP2 */
-#defineGPMC_ECC_BCH_RESULT_5 0x304 /* not available on OMAP2 */
-#defineGPMC_ECC_BCH_RESULT_6 0x308 /* not available on OMAP2 */
/* GPMC ECC control settings */
#define GPMC_ECC_CTRL_ECCCLEAR 0x100
@@ -117,9 +106,6 @@
#define GPMC_CS_CONFIG50x10
#define GPMC_CS_CONFIG60x14
#define GPMC_CS_CONFIG70x18
-#define GPMC_CS_NAND_COMMAND 0x1c
-#define GPMC_CS_NAND_ADDRESS 0x20
-#define GPMC_CS_NAND_DATA 0x24
#define GPMC_CONFIG1_WRAPBURST_SUPP (1 31)
#define GPMC_CONFIG1_READMULTIPLE_SUPP (1 30)
@@ -1030,44 +1016,10 @@ int gpmc_configure(int cmd, int wval)
}
EXPORT_SYMBOL(gpmc_configure);
-void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
+void gpmc_get_mem_resource(struct resource *res)
{
- int i;
-
- reg-gpmc_status = gpmc_base + GPMC_STATUS;
- reg-gpmc_irqstatus = gpmc_base + GPMC_IRQSTATUS;
- reg-gpmc_irqenable = gpmc_base + GPMC_IRQENABLE;
- reg-gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
- GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
- reg-gpmc_nand_address = gpmc_base + GPMC_CS0_OFFSET +
- GPMC_CS_NAND_ADDRESS + GPMC_CS_SIZE * cs;
- reg-gpmc_nand_data = gpmc_base + GPMC_CS0_OFFSET +
- GPMC_CS_NAND_DATA + GPMC_CS_SIZE * cs;
- reg-gpmc_prefetch_config1 = gpmc_base + GPMC_PREFETCH_CONFIG1;
- reg-gpmc_prefetch_config2 = gpmc_base + GPMC_PREFETCH_CONFIG2;
- reg-gpmc_prefetch_control = gpmc_base + GPMC_PREFETCH_CONTROL;
- reg-gpmc_prefetch_status = gpmc_base + GPMC_PREFETCH_STATUS;
- reg-gpmc_ecc_config = gpmc_base + GPMC_ECC_CONFIG;
- reg-gpmc_ecc_control = gpmc_base + GPMC_ECC_CONTROL;
- reg-gpmc_ecc_size_config = gpmc_base + GPMC_ECC_SIZE_CONFIG;
-
[PATCH 08/12] mtd: nand: omap: Update DT binding documentation
Add compatible id, interrupts and update reg property description.
As the NAND controller needs access to GPMC register space, we need
to pass a second memory resource to the NAND controller node.
Due to the weird way the reg property has been implemented (i.e.
CS number required in 1st number of reg property) we will need to
use a number outside the possible CS numbers for the GPMC register space.
As a SoC can have fewer than 10 chip selects, 255 seems like a safe
bet for the GPMC register space.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index fb733c4..3a8ebfa 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -13,7 +13,13 @@ Documentation/devicetree/bindings/mtd/nand.txt
Required properties:
+ - compatible: ti,omap2-nand
- reg:The CS line the peripheral is connected to
+ Should contain 2 resource specifiers
+ - range id (CS number), base offset and length of the
+ NAND I/O space
+ - range id, base offset and length of the GPMC register space.
+ - interrupts: Interrupt resource specifier for GPMC interrupt.
Optional properties:
@@ -55,17 +61,21 @@ Example for an AM33xx board:
gpmc: gpmc@5000 {
compatible = ti,am3352-gpmc;
ti,hwmods = gpmc;
- reg = 0x5000 0x100;
+ reg = 0x5000 0x36c;
interrupts = 100;
gpmc,num-cs = 8;
gpmc,num-waitpins = 2;
#address-cells = 2;
#size-cells = 1;
- ranges = 0 0 0x0800 0x2000; /* CS0: NAND */
+ ranges = 0 0 0x0800 0x100 /* CS0 space, 16MB */
+ 255 0 0x5000 0x36c; /* GPMC reg space */
elm_id = elm;
nand@0,0 {
- reg = 0 0 0; /* CS0, offset 0 */
+ compatible = ti,omap2-nand;
+ reg = 0 0 4/* CS0, offset 0, NAND I/O
window 4 */
+ 255 0 0x36c;/* GPMC reg space */
+ interrupts = 100;
nand-bus-width = 16;
ti,nand-ecc-opt = bch8;
ti,nand-xfer-type = polled;
--
2.1.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 06/12] mtd: nand: omap: Copy platform data parameters to omap_nand_info data
Copy all the platform data parameters to the driver's local data
structure 'omap_nand_info' and use it in the entire driver. This will
make it easer for device tree migration.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 25a3d05..407aecf9 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -191,15 +191,19 @@ static struct nand_hw_control omap_gpmc_controller = {
};
struct omap_nand_info {
- struct omap_nand_platform_data *pdata;
struct mtd_info mtd;
struct nand_chipnand;
struct platform_device *pdev;
int gpmc_cs;
+ booldev_ready;
+ enum nand_ioxfer_type;
+ int devsize;
+ enum omap_ecc ecc_opt;
+ struct device_node *elm_of_node;
+
unsigned long phys_base;
void __iomem*gpmc_base;
- enum omap_ecc ecc_opt;
struct completion comp;
struct dma_chan *dma;
int gpmc_irq;
@@ -1717,7 +1721,7 @@ static bool omap2_nand_ecc_check(struct omap_nand_info
*info,
CONFIG_MTD_NAND_OMAP_BCH not enabled\n);
return false;
}
- if (ecc_needs_elm !is_elm_present(info, pdata-elm_of_node)) {
+ if (ecc_needs_elm !is_elm_present(info, info-elm_of_node)) {
dev_err(info-pdev-dev, ELM not available\n);
return false;
}
@@ -1802,6 +1806,11 @@ static int omap_nand_probe(struct platform_device *pdev)
info-gpmc_cs = pdata-cs;
info-of_node = pdata-of_node;
info-ecc_opt = pdata-ecc_opt;
+ info-dev_ready = pdata-dev_ready;
+ info-xfer_type = pdata-xfer_type;
+ info-devsize = pdata-devsize;
+ info-elm_of_node = pdata-elm_of_node;
+
mtd = info-mtd;
mtd-priv = info-nand;
mtd-name = dev_name(pdev-dev);
@@ -1855,7 +1864,7 @@ static int omap_nand_probe(struct platform_device *pdev)
* chip delay which is slightly more than tR (AC Timing) of the NAND
* device and read status register until you get a failure or success
*/
- if (pdata-dev_ready) {
+ if (info-dev_ready) {
nand_chip-dev_ready = omap_dev_ready;
nand_chip-chip_delay = 0;
} else {
@@ -1869,15 +1878,16 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip-options |= NAND_SKIP_BBTSCAN;
/* scan NAND device connected to chip controller */
- nand_chip-options |= pdata-devsize NAND_BUSWIDTH_16;
+ nand_chip-options |= info-devsize NAND_BUSWIDTH_16;
if (nand_scan_ident(mtd, 1, NULL)) {
- dev_err(info-pdev-dev, scan failed, may be bus-width
mismatch\n);
+ dev_err(info-pdev-dev,
+ scan failed, may be bus-width mismatch\n);
err = -ENXIO;
goto return_error;
}
/* re-populate low-level callbacks based on xfer modes */
- switch (pdata-xfer_type) {
+ switch (info-xfer_type) {
case NAND_OMAP_PREFETCH_POLLED:
nand_chip-read_buf = omap_read_buf_pref;
nand_chip-write_buf = omap_write_buf_pref;
@@ -1940,7 +1950,7 @@ static int omap_nand_probe(struct platform_device *pdev)
default:
dev_err(pdev-dev,
- xfer_type(%d) not supported!\n, pdata-xfer_type);
+ xfer_type(%d) not supported!\n, info-xfer_type);
err = -EINVAL;
goto return_error;
}
--
2.1.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 09/12] memory: omap-gpmc: use module_platform_driver()
Stop registering driver at postcore and do it
the standard way.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/memory/omap-gpmc.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 995e9b8..f19edc2 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1914,19 +1914,7 @@ static struct platform_driver gpmc_driver = {
},
};
-static __init int gpmc_init(void)
-{
- return platform_driver_register(gpmc_driver);
-}
-
-static __exit void gpmc_exit(void)
-{
- platform_driver_unregister(gpmc_driver);
-
-}
-
-postcore_initcall(gpmc_init);
-module_exit(gpmc_exit);
+module_platform_driver(gpmc_driver);
static struct omap3_gpmc_regs gpmc_context;
--
2.1.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 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
Since the Interrupt Events are used only by the NAND driver,
there is no point in managing the Interrupt registers
in the GPMC driver and complicating it with irqchip modeling.
Let's manage the interrupt registers directly in the NAND driver
and get rid of irqchip model from GPMC driver.
Get rid of IRQ commands and unused commands from gpmc_configure() in
the GPMC driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 4 +-
drivers/memory/omap-gpmc.c | 176 ++-
drivers/mtd/nand/omap2.c | 76 ++--
include/linux/omap-gpmc.h| 5 +-
include/linux/platform_data/mtd-nand-omap2.h | 2 +
5 files changed, 56 insertions(+), 207 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 72918c4..b960876 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -80,7 +80,6 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
struct resource gpmc_nand_res[] = {
{ .flags = IORESOURCE_MEM, },
{ .flags = IORESOURCE_IRQ, },
- { .flags = IORESOURCE_IRQ, },
};
BUG_ON(gpmc_nand_data-cs = GPMC_CS_NUM);
@@ -93,8 +92,7 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
return err;
}
gpmc_nand_res[0].end = gpmc_nand_res[0].start + NAND_IO_SIZE - 1;
- gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
- gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
+ gpmc_nand_res[1].start = gpmc_get_irq();
memset(s, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data-of_node)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 3a27a84..50806e7 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -121,12 +121,6 @@
#define GPMC_CS_NAND_ADDRESS 0x20
#define GPMC_CS_NAND_DATA 0x24
-/* Control Commands */
-#define GPMC_CONFIG_RDY_BSY0x0001
-#define GPMC_CONFIG_DEV_SIZE 0x0002
-#define GPMC_CONFIG_DEV_TYPE 0x0003
-#define GPMC_SET_IRQ_STATUS0x0004
-
#define GPMC_CONFIG1_WRAPBURST_SUPP (1 31)
#define GPMC_CONFIG1_READMULTIPLE_SUPP (1 30)
#define GPMC_CONFIG1_READTYPE_ASYNC (0 29)
@@ -174,17 +168,11 @@
#define GPMC_CONFIG_WRITEPROTECT 0x0010
#define WR_RD_PIN_MONITORING 0x0060
-#define GPMC_ENABLE_IRQ0x000d
-
/* ECC commands */
#define GPMC_ECC_READ 0 /* Reset Hardware ECC for read */
#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
#define GPMC_ECC_READSYN 2 /* Reset before syndrom is read back */
-/* XXX: Only NAND irq has been considered,currently these are the only ones
used
- */
-#defineGPMC_NR_IRQ 2
-
enum gpmc_clk_domain {
GPMC_CD_FCLK,
GPMC_CD_CLK
@@ -199,11 +187,6 @@ struct gpmc_cs_data {
struct resource mem;
};
-struct gpmc_client_irq {
- unsignedirq;
- u32 bitmask;
-};
-
/* Structure to save gpmc cs context */
struct gpmc_cs_config {
u32 config1;
@@ -231,10 +214,6 @@ struct omap3_gpmc_regs {
struct gpmc_cs_config cs_context[GPMC_CS_NUM];
};
-static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
-static struct irq_chip gpmc_irq_chip;
-static int gpmc_irq_start;
-
static struct resource gpmc_mem_root;
static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -242,15 +221,13 @@ static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_num = GPMC_CS_NUM;
static unsigned int gpmc_nr_waitpins;
static struct device *gpmc_dev;
-static int gpmc_irq;
+static int gpmc_irq = -EINVAL;
static resource_size_t phys_base, mem_size;
static unsigned gpmc_capability;
static void __iomem *gpmc_base;
static struct clk *gpmc_l3_clk;
-static irqreturn_t gpmc_handle_irq(int irq, void *dev);
-
static void gpmc_write_reg(int idx, u32 val)
{
writel_relaxed(val, gpmc_base + idx);
@@ -1035,14 +1012,6 @@ int gpmc_configure(int cmd, int wval)
u32 regval;
switch (cmd) {
- case GPMC_ENABLE_IRQ:
- gpmc_write_reg(GPMC_IRQENABLE, wval);
- break;
-
- case GPMC_SET_IRQ_STATUS:
- gpmc_write_reg(GPMC_IRQSTATUS, wval);
- break;
-
case GPMC_CONFIG_WP:
regval = gpmc_read_reg(GPMC_CONFIG);
if (wval)
@@ -1066,6 +1035,8 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int
cs)
int i;
reg-gpmc_status = gpmc_base + GPMC_STATUS;
+ reg-gpmc_irqstatus = gpmc_base + GPMC_IRQSTATUS;
+ reg-gpmc_irqenable = gpmc_base + GPMC_IRQENABLE;
reg-gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
[PATCH 07/12] mtd: nand: omap: Clean up device tree support
Move NAND specific device tree parsing to NAND driver.
The NAND controller node must have a compatible id, register space
resource and interrupt resource.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 5 +-
drivers/memory/omap-gpmc.c | 133 ++-
drivers/mtd/nand/omap2.c | 133 +++
include/linux/platform_data/mtd-nand-omap2.h | 4 +-
4 files changed, 142 insertions(+), 133 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 9cb8ce6..d7b8dcc 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -97,10 +97,7 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_nand_res[2].start = gpmc_get_irq();
memset(s, 0, sizeof(struct gpmc_settings));
- if (gpmc_nand_data-of_node)
- gpmc_read_settings_dt(gpmc_nand_data-of_node, s);
- else
- gpmc_set_legacy(gpmc_nand_data, s);
+ gpmc_set_legacy(gpmc_nand_data, s);
s.device_nand = true;
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 650f9b8..995e9b8 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -29,7 +29,6 @@
#include linux/of_device.h
#include linux/of_platform.h
#include linux/omap-gpmc.h
-#include linux/mtd/nand.h
#include linux/pm_runtime.h
#include linux/platform_data/mtd-nand-omap2.h
@@ -1557,105 +1556,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
of_property_read_bool(np, gpmc,time-para-granularity);
}
-#if IS_ENABLED(CONFIG_MTD_NAND)
-
-static const char * const nand_xfer_types[] = {
- [NAND_OMAP_PREFETCH_POLLED] = prefetch-polled,
- [NAND_OMAP_POLLED] = polled,
- [NAND_OMAP_PREFETCH_DMA]= prefetch-dma,
- [NAND_OMAP_PREFETCH_IRQ]= prefetch-irq,
-};
-
-static int gpmc_probe_nand_child(struct platform_device *pdev,
-struct device_node *child)
-{
- u32 val;
- const char *s;
- struct gpmc_timings gpmc_t;
- struct omap_nand_platform_data *gpmc_nand_data;
-
- if (of_property_read_u32(child, reg, val) 0) {
- dev_err(pdev-dev, %s has no 'reg' property\n,
- child-full_name);
- return -ENODEV;
- }
-
- gpmc_nand_data = devm_kzalloc(pdev-dev, sizeof(*gpmc_nand_data),
- GFP_KERNEL);
- if (!gpmc_nand_data)
- return -ENOMEM;
-
- gpmc_nand_data-cs = val;
- gpmc_nand_data-of_node = child;
-
- /* Detect availability of ELM module */
- gpmc_nand_data-elm_of_node = of_parse_phandle(child, ti,elm-id, 0);
- if (gpmc_nand_data-elm_of_node == NULL)
- gpmc_nand_data-elm_of_node =
- of_parse_phandle(child, elm_id, 0);
-
- /* select ecc-scheme for NAND */
- if (of_property_read_string(child, ti,nand-ecc-opt, s)) {
- pr_err(%s: ti,nand-ecc-opt not found\n, __func__);
- return -ENODEV;
- }
-
- if (!strcmp(s, sw))
- gpmc_nand_data-ecc_opt = OMAP_ECC_HAM1_CODE_SW;
- else if (!strcmp(s, ham1) ||
-!strcmp(s, hw) || !strcmp(s, hw-romcode))
- gpmc_nand_data-ecc_opt =
- OMAP_ECC_HAM1_CODE_HW;
- else if (!strcmp(s, bch4))
- if (gpmc_nand_data-elm_of_node)
- gpmc_nand_data-ecc_opt =
- OMAP_ECC_BCH4_CODE_HW;
- else
- gpmc_nand_data-ecc_opt =
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
- else if (!strcmp(s, bch8))
- if (gpmc_nand_data-elm_of_node)
- gpmc_nand_data-ecc_opt =
- OMAP_ECC_BCH8_CODE_HW;
- else
- gpmc_nand_data-ecc_opt =
- OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
- else if (!strcmp(s, bch16))
- if (gpmc_nand_data-elm_of_node)
- gpmc_nand_data-ecc_opt =
- OMAP_ECC_BCH16_CODE_HW;
- else
- pr_err(%s: BCH16 requires ELM support\n, __func__);
- else
- pr_err(%s: ti,nand-ecc-opt invalid value\n, __func__);
-
- /* select data transfer mode for NAND controller */
- if (!of_property_read_string(child, ti,nand-xfer-type, s))
- for (val = 0; val ARRAY_SIZE(nand_xfer_types); val++)
- if (!strcasecmp(s, nand_xfer_types[val])) {
- gpmc_nand_data-xfer_type = val;
- break;
- }
-
-
[PATCH 11/12] ARM: dts: OMAP2+: Fix NAND device nodes
Add compatible id, GPMC register resource and interrupt
resource to NAND controller nodes.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am335x-baltos-ir5221.dts | 9 +++--
arch/arm/boot/dts/am335x-chilisom.dtsi | 8 ++--
arch/arm/boot/dts/am335x-evm.dts | 8 ++--
arch/arm/boot/dts/am335x-igep0033.dtsi | 8 ++--
arch/arm/boot/dts/am437x-gp-evm.dts | 8 ++--
arch/arm/boot/dts/am43x-epos-evm.dts | 8 ++--
arch/arm/boot/dts/dm8168-evm.dts | 8 ++--
arch/arm/boot/dts/dra7-evm.dts | 8 ++--
arch/arm/boot/dts/dra72-evm.dts | 8 ++--
arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 9 +++--
arch/arm/boot/dts/omap3-beagle.dts | 7 +--
arch/arm/boot/dts/omap3-cm-t3x.dtsi | 8 ++--
arch/arm/boot/dts/omap3-devkit8000.dts | 9 +++--
arch/arm/boot/dts/omap3-evm-37xx.dts | 10 +++---
arch/arm/boot/dts/omap3-gta04.dtsi | 8 ++--
arch/arm/boot/dts/omap3-igep.dtsi| 5 -
arch/arm/boot/dts/omap3-igep0020-common.dtsi | 5 +++--
arch/arm/boot/dts/omap3-igep0030-common.dtsi | 6 ++
arch/arm/boot/dts/omap3-ldp.dts | 10 +++---
arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 8 ++--
arch/arm/boot/dts/omap3-lilly-dbb056.dts | 7 ---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 8 ++--
arch/arm/boot/dts/omap3-tao3530.dtsi | 8 ++--
arch/arm/boot/dts/omap3430-sdp.dts | 8 ++--
24 files changed, 141 insertions(+), 48 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-baltos-ir5221.dts
b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
index 7d36601..9a504dd 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir5221.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
@@ -236,11 +236,16 @@
gpmc {
pinctrl-names = default;
pinctrl-0 = nandflash_pins_s0;
- ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+ ranges = 0 0 0x0800 0x1000, /* CS0: NAND */
+255 0 0x5000 0x36c; /* GPMC reg */
+
status = okay;
nand@0,0 {
- reg = 0 0 0; /* CS0, offset 0 */
+ compatible = ti,omap2-nand;
+ reg = 0 0 4, /* CS0, offset 0, IO size 4 */
+ 255 0 0x36c;/* GPMC reg */
+ interrupts = 100;
nand-bus-width = 8;
ti,nand-ecc-opt = bch8;
ti,nand-xfer-type = polled;
diff --git a/arch/arm/boot/dts/am335x-chilisom.dtsi
b/arch/arm/boot/dts/am335x-chilisom.dtsi
index 7e9a34d..e7a82ea 100644
--- a/arch/arm/boot/dts/am335x-chilisom.dtsi
+++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
@@ -206,9 +206,13 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = nandflash_pins;
- ranges = 0 0 0x0800 0x0100; /* CS0 0 @addr 0x0800, size
0x0100 */
+ ranges = 0 0 0x0800 0x0100, /* CS0 0 @addr 0x0800, size
0x0100 */
+255 0 0x5000 0x36c; /* GPMC reg */
nand@0,0 {
- reg = 0 0 4; /* CS0, offset 0, IO size 4 */
+ compatible = ti,omap2-nand;
+ reg = 0 0 4, /* CS0, offset 0, IO size 4 */
+ 255 0 0x36c;/* GPMC reg */
+ interrupts = 100;
ti,nand-ecc-opt = bch8;
ti,elm-id = elm;
nand-bus-width = 8;
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 765be27..11d536c 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -494,9 +494,13 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = nandflash_pins_s0;
- ranges = 0 0 0x0800 0x100;/* CS0: 16MB for NAND */
+ ranges = 0 0 0x0800 0x100,/* CS0: 16MB for NAND */
+255 0 0x5000 0x36c; /* GPMC reg */
nand@0,0 {
- reg = 0 0 4; /* CS0, offset 0, IO size 4 */
+ compatible = ti,omap2-nand;
+ reg = 0 0 4, /* CS0, offset 0, IO size 4 */
+ 255 0 0x36c;/* GPMC reg */
+ interrupts = 100;
ti,nand-ecc-opt = bch8;
ti,elm-id = elm;
nand-bus-width = 8;
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index c0e1135..6197dc6 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -126,10 +126,14 @@
pinctrl-names = default;
pinctrl-0 = nandflash_pins;
- ranges = 0 0 0x0800 0x100;/* CS0: 16MB for NAND */
+ ranges = 0 0 0x0800 0x100,/* CS0: 16MB for NAND */
+255 0 0x5000 0x36c; /* GPMC reg */
nand@0,0 {
- reg = 0 0 4; /* CS0, offset 0,
[PATCH 02/12] ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
Add device_timings, gpmc_timings and gpmc_setting to
gpmc platform data.
Signed-off-by: Roger Quadros rog...@ti.com
---
include/linux/omap-gpmc.h | 134 --
include/linux/platform_data/gpmc-omap.h | 139
2 files changed, 139 insertions(+), 134 deletions(-)
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 5c79190..2dcef1c 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -14,140 +14,6 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
-#define GPMC_BURST_4 4 /* 4 word burst */
-#define GPMC_BURST_8 8 /* 8 word burst */
-#define GPMC_BURST_16 16 /* 16 word burst */
-#define GPMC_DEVWIDTH_8BIT 1 /* 8-bit device width */
-#define GPMC_DEVWIDTH_16BIT2 /* 16-bit device width */
-#define GPMC_MUX_AAD 1 /* Addr-Addr-Data multiplex */
-#define GPMC_MUX_AD2 /* Addr-Data multiplex */
-
-/* bool type time settings */
-struct gpmc_bool_timings {
- bool cycle2cyclediffcsen;
- bool cycle2cyclesamecsen;
- bool we_extra_delay;
- bool oe_extra_delay;
- bool adv_extra_delay;
- bool cs_extra_delay;
- bool time_para_granularity;
-};
-
-/*
- * Note that all values in this struct are in nanoseconds except sync_clk
- * (which is in picoseconds), while the register values are in gpmc_fck cycles.
- */
-struct gpmc_timings {
- /* Minimum clock period for synchronous mode (in picoseconds) */
- u32 sync_clk;
-
- /* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
- u32 cs_on; /* Assertion time */
- u32 cs_rd_off; /* Read deassertion time */
- u32 cs_wr_off; /* Write deassertion time */
-
- /* ADV signal timings corresponding to GPMC_CONFIG3 */
- u32 adv_on; /* Assertion time */
- u32 adv_rd_off; /* Read deassertion time */
- u32 adv_wr_off; /* Write deassertion time */
-
- /* WE signals timings corresponding to GPMC_CONFIG4 */
- u32 we_on; /* WE assertion time */
- u32 we_off; /* WE deassertion time */
-
- /* OE signals timings corresponding to GPMC_CONFIG4 */
- u32 oe_on; /* OE assertion time */
- u32 oe_off; /* OE deassertion time */
-
- /* Access time and cycle time timings corresponding to GPMC_CONFIG5 */
- u32 page_burst_access; /* Multiple access word delay */
- u32 access; /* Start-cycle to first data valid delay */
- u32 rd_cycle; /* Total read cycle time */
- u32 wr_cycle; /* Total write cycle time */
-
- u32 bus_turnaround;
- u32 cycle2cycle_delay;
-
- u32 wait_monitoring;
- u32 clk_activation;
-
- /* The following are only on OMAP3430 */
- u32 wr_access; /* WRACCESSTIME */
- u32 wr_data_mux_bus;/* WRDATAONADMUXBUS */
-
- struct gpmc_bool_timings bool_timings;
-};
-
-/* Device timings in picoseconds */
-struct gpmc_device_timings {
- u32 t_ceasu;/* address setup to CS valid */
- u32 t_avdasu; /* address setup to ADV valid */
- /* XXX: try to combine t_avdp_r t_avdp_w. Issue is
-* of tusb using these timings even for sync whilst
-* ideally for adv_rd/(wr)_off it should have considered
-* t_avdh instead. This indirectly necessitates r/w
-* variations of t_avdp as it is possible to have one
-* sync other async
-*/
- u32 t_avdp_r; /* ADV low time (what about t_cer ?) */
- u32 t_avdp_w;
- u32 t_aavdh;/* address hold time */
- u32 t_oeasu;/* address setup to OE valid */
- u32 t_aa; /* access time from ADV assertion */
- u32 t_iaa; /* initial access time */
- u32 t_oe; /* access time from OE assertion */
- u32 t_ce; /* access time from CS asertion */
- u32 t_rd_cycle; /* read cycle time */
- u32 t_cez_r;/* read CS deassertion to high Z */
- u32 t_cez_w;/* write CS deassertion to high Z */
- u32 t_oez; /* OE deassertion to high Z */
- u32 t_weasu;/* address setup to WE valid */
- u32 t_wpl; /* write assertion time */
- u32 t_wph; /* write deassertion time */
- u32 t_wr_cycle; /* write cycle time */
-
- u32 clk;
- u32 t_bacc; /* burst access valid clock to output delay */
- u32 t_ces; /* CS setup time to clk */
- u32 t_avds; /* ADV setup time to clk */
- u32 t_avdh; /* ADV hold time from clk */
- u32 t_ach; /* address hold time from clk */
- u32 t_rdyo; /* clk to ready valid */
-
- u32 t_ce_rdyz; /* XXX: description ?, or use t_cez
Re: [PATCH v2 1/2] extcon: fix hang and extcon_get/set_cable_state().
Hi Roger,
Thanks for your working.
I'll review, test and apply it on next week because I'm on vacation now.
Thanks,
Chanwoo Choi
On Tue, Jul 7, 2015 at 3:06 PM, Roger Quadros rog...@ti.com wrote:
Users of find_cable_index_by_name() will cause a kernel hang
as the while loop counter is never incremented and end condition
is never reached.
extcon_get_cable_state() and extcon_set_cable_state() are broken
because they use cable index instead of cable id. This causes
the first cable state (cable.0) to be always invalid in sysfs
or extcon_get_cable_state() users.
Introduce a new function find_cable_id_by_name() that fixes
both of the above issues.
Fixes: commit 73b6ecdb93e8 (extcon: Redefine the unique id of supported
external connectors without 'enum extcon' type)
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/extcon/extcon.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 76157ab..987dd3c 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -124,22 +124,34 @@ static int find_cable_index_by_id(struct extcon_dev
*edev, const unsigned int id
return -EINVAL;
}
-static int find_cable_index_by_name(struct extcon_dev *edev, const char
*name)
+static int find_cable_id_by_name(struct extcon_dev *edev, const char *name)
{
- unsigned int id = EXTCON_NONE;
+ unsigned int id = -EINVAL;
int i = 0;
- if (edev-max_supported == 0)
- return -EINVAL;
-
- /* Find the the number of extcon cable */
+ /* Find the id of extcon cable */
while (extcon_name[i]) {
if (!strncmp(extcon_name[i], name, CABLE_NAME_MAX)) {
id = i;
break;
}
+
+ i++;
}
+ return id;
+};
+
+static int find_cable_index_by_name(struct extcon_dev *edev, const char
*name)
+{
+ unsigned int id = EXTCON_NONE;
+
+ if (edev-max_supported == 0)
+ return -EINVAL;
+
+ /* Find the the number of extcon cable */
+ id = find_cable_id_by_name(edev, name);
+
if (id == EXTCON_NONE)
return -EINVAL;
@@ -228,9 +240,11 @@ static ssize_t cable_state_show(struct device *dev,
struct extcon_cable *cable = container_of(attr, struct extcon_cable,
attr_state);
+ int i = cable-cable_index;
+
return sprintf(buf, %d\n,
extcon_get_cable_state_(cable-edev,
- cable-cable_index));
+
cable-edev-supported_cable[i]));
}
/**
@@ -341,6 +355,9 @@ int extcon_get_cable_state_(struct extcon_dev *edev,
const unsigned int id)
{
int index;
+ if (id == EXTCON_NONE)
+ return -EINVAL;
+
index = find_cable_index_by_id(edev, id);
if (index 0)
return index;
@@ -361,7 +378,7 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
*/
int extcon_get_cable_state(struct extcon_dev *edev, const char *cable_name)
{
- return extcon_get_cable_state_(edev, find_cable_index_by_name
+ return extcon_get_cable_state_(edev, find_cable_id_by_name
(edev, cable_name));
}
EXPORT_SYMBOL_GPL(extcon_get_cable_state);
@@ -380,6 +397,9 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
unsigned int id,
u32 state;
int index;
+ if (id == EXTCON_NONE)
+ return -EINVAL;
+
index = find_cable_index_by_id(edev, id);
if (index 0)
return index;
@@ -404,7 +424,7 @@ EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
int extcon_set_cable_state(struct extcon_dev *edev,
const char *cable_name, bool cable_state)
{
- return extcon_set_cable_state_(edev, find_cable_index_by_name
+ return extcon_set_cable_state_(edev, find_cable_id_by_name
(edev, cable_name), cable_state);
}
EXPORT_SYMBOL_GPL(extcon_set_cable_state);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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/3] PCI: host: pcie-designware: add support for suspend and resume
Hi Kishon, On Fri, Jul 10, 2015 at 8:19 PM, Kishon Vijay Abraham I kis...@ti.com wrote: [...] Have you tested with a card having IO space memory as well. I don't have any cards with IO space memory. Do you have any suggestion for cards with IO space memory? Sorry, I never used it either :( IIRC, then Tim and Marek (in cc) had reported long back with some issues of IO transaction with SKY2 based card. They may let you know about exact card ID. ~Pratyush -- 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/3] PCI: host: pcie-designware: add support for suspend and resume
On Friday, July 10, 2015 at 05:30:46 PM, Pratyush Anand wrote: Hi Kishon, Hi, On Fri, Jul 10, 2015 at 8:19 PM, Kishon Vijay Abraham I kis...@ti.com wrote: [...] Have you tested with a card having IO space memory as well. I don't have any cards with IO space memory. Do you have any suggestion for cards with IO space memory? Sorry, I never used it either :( IIRC, then Tim and Marek (in cc) had reported long back with some issues of IO transaction with SKY2 based card. They may let you know about exact card ID. That was Tim, I didn't ever try with SKY2 , sorry. Best regards, Marek Vasut -- 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/3] PCI: host: pcie-designware: add support for suspend and resume
Hi Kishon, On Fri, Jul 3, 2015 at 4:33 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Certain platforms require MSE bit to be cleared to set the master in standby mode. (In DRA7xx TRM_vE, section 24.9.4.5.2.2.1 PCIe Controller Master Standby Behavior advises to use the clearing of the local MSE bit to set the master in standby. Without this some of the clocks do not idle). Cleared the MSE bit on suspend and enabled it back on resume. This is required to get suspend/resume working. Have you tested with a card having IO space memory as well. I think you might need to require clear and enable PCI_COMMAND_IO in suspend and resume respectively. ~Pratyush -- 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] i2c: busses: i2c-omap: Increase timeout for i2c interrupt
Hi! On 10/07/15 15:17, ext Vignesh R wrote: I would propose you to throw away spinlocks. Convert threaded IRQ to just one hardirq handler. And continue debugging. You will reduce the load of the system with the above measures, maybe it will not happen any more, maybe you'll figure out that problem is somewhere else. Or this. I am not convinced with moving entire code at hardirq context. I believe its better to keep hardirq as small as possible. How deep is the controller's FIFO? 1 byte? 2 bytes? Other drivers can perfectly fill next byte in hardirq handler. If you need to do 10 opcodes more in hardirq handler, it's much better for the whole system than to trigger scheduler and thread and and and just because of these 10 opcodes. -- Best regards, Alexander Sverdlin. -- 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] i2c: busses: i2c-omap: Increase timeout for i2c interrupt
Hi, On 07/10/2015 06:56 PM, Alexander Sverdlin wrote: Hi! On 10/07/15 15:17, ext Vignesh R wrote: I would propose you to throw away spinlocks. Convert threaded IRQ to just one hardirq handler. And continue debugging. You will reduce the load of the system with the above measures, maybe it will not happen any more, maybe you'll figure out that problem is somewhere else. Or this. I am not convinced with moving entire code at hardirq context. I believe its better to keep hardirq as small as possible. How deep is the controller's FIFO? 1 byte? 2 bytes? As per AM57x TRM[1] section 24.1.4.8 max FIFO depth can be 64bytes. [1] http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf -- Regards Vignesh -- 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] i2c: busses: i2c-omap: Increase timeout for i2c interrupt
On 07/10/2015 02:39 PM, Wolfram Sang wrote: 60 s sounds way too much and actually I simply don't believe this is the root cause. If I take a look into the driver, then I see, that I agree, this is just a workaround. Yes, this is a workaround. I thought this is simpler change and can go into -rc while I work on the better fix. As you can see, the other suggestions need quite a significant change to the isr code. the design is not really the best. The whole IRQ handling could be actually performed in hard IRQ handler, without threading overhead. Putting even 2 bytes in the controller FIFO should not be too heavy for the hard IRQ handler. Then these ridiculous spin_lock()s. What is the reason behind? The IRQ is flagged with ONESHOT, so thread and hardirq handler are anyway mutually excluded. But if this thread ever runs longer than it's allowed in IRQ context, then it anyway produces this IRQ latency because it locks spin_lock_irqsave() for the whole time! So the whole point of threaded interrupt is missing. Furthermore, this combination of threaded_irq and struct completion seems bogus to me. If you just want to ensure the irq happened before timeout, you just complete when the irq happened and do the bottom half after the completion returned? This sounds good to me. I will try to implement this option. Thanks for the suggestion. I would propose you to throw away spinlocks. Convert threaded IRQ to just one hardirq handler. And continue debugging. You will reduce the load of the system with the above measures, maybe it will not happen any more, maybe you'll figure out that problem is somewhere else. Or this. I am not convinced with moving entire code at hardirq context. I believe its better to keep hardirq as small as possible. -- Regards Vignesh -- 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/3] PCI: host: pcie-designware: add support for suspend and resume
Hi Pratyush, On Friday 10 July 2015 06:52 PM, Pratyush Anand wrote: Hi Kishon, On Fri, Jul 3, 2015 at 4:33 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Certain platforms require MSE bit to be cleared to set the master in standby mode. (In DRA7xx TRM_vE, section 24.9.4.5.2.2.1 PCIe Controller Master Standby Behavior advises to use the clearing of the local MSE bit to set the master in standby. Without this some of the clocks do not idle). Cleared the MSE bit on suspend and enabled it back on resume. This is required to get suspend/resume working. Have you tested with a card having IO space memory as well. I don't have any cards with IO space memory. Do you have any suggestion for cards with IO space memory? I think you might need to require clear and enable PCI_COMMAND_IO in suspend and resume respectively. okay. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] i2c: busses: i2c-omap: Increase timeout for i2c interrupt
Hi Wolfram, On 07/10/2015 12:09 PM, Wolfram Sang wrote: 60 s sounds way too much and actually I simply don't believe this is the root cause. If I take a look into the driver, then I see, that I agree, this is just a workaround. the design is not really the best. The whole IRQ handling could be actually performed in hard IRQ handler, without threading overhead. Putting even 2 bytes in the controller FIFO should not be too heavy for the hard IRQ handler. Then these ridiculous spin_lock()s. What is the reason behind? The IRQ is flagged with ONESHOT, so thread and hardirq handler are anyway mutually excluded. But if this thread ever runs longer than it's allowed in IRQ context, then it anyway produces this IRQ latency because it locks spin_lock_irqsave() for the whole time! So the whole point of threaded interrupt is missing. Furthermore, this combination of threaded_irq and struct completion seems bogus to me. If you just want to ensure the irq happened before timeout, you just complete when the irq happened and do the bottom half after the completion returned? I'd very appreciated if You would be able to clarify your point a bit, pls? completion is used to indicate end of one message transfer (+check for msg timeout), so .master_xfer()-omap_i2c_xfer could switch to next msg. And there could be more than on IRQ triggered depending on msg length while one message is being transfered. -- regards, -grygorii -- 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 6/7] crypto: omap-aes: Add support for GCM mode
Hi Herbert,
On Wednesday 08 July 2015 09:48 AM, Herbert Xu wrote:
On Tue, Jul 07, 2015 at 09:01:48PM +0530, Lokesh Vutla wrote:
+static int omap_aes_gcm_copy_buffers(struct omap_aes_dev *dd,
+ struct aead_request *req)
[..snip..]
+static int do_encrypt_iv(struct aead_request *req, u32 *tag)
+{
+struct scatterlist iv_sg;
+struct ablkcipher_request *ablk_req;
+struct crypto_ablkcipher *tfm;
+struct tcrypt_result result;
+struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
+int ret = 0;
+
+tfm = crypto_alloc_ablkcipher(ctr(aes), 0, 0);
Ugh, you cannot allocate crypto transforms in the data path. You
should allocate it in init instead. Also using ctr(aes) is overkill.
Just use aes and do the xor by hand.
+static int omap_aes_gcm_crypt(struct aead_request *req, unsigned long mode)
+{
+struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
+struct omap_aes_reqctx *rctx = aead_request_ctx(req);
+struct crypto_aead *aead = crypto_aead_reqtfm(req);
+unsigned int authlen = crypto_aead_authsize(aead);
+struct omap_aes_dev *dd;
+__be32 counter = cpu_to_be32(1);
+int err;
+
+memset(ctx-auth_tag, 0, sizeof(ctx-auth_tag));
The ctx is shared memory and you must not write to it as multiple
requests can be called on the same tfm. Use rctx instead.
May be a dumb question.
If you don't mind can you elaborate more on the usage of rctx and ctx
in the driver?
Thanks and regards,
Lokesh
+memcpy(req-iv + 12, counter, 4);
The IV is only 12 bytes long so you're corrupting memory here.
You should use rctx here too.
+if (req-assoclen + req-cryptlen == 0) {
+scatterwalk_map_and_copy(ctx-auth_tag, req-dst, 0, authlen,
+ 1);
+return 0;
+}
How can this be right? Did you enable the selftest?
Cheers,
--
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] i2c: busses: i2c-omap: Increase timeout for i2c interrupt
On 07/10/2015 04:26 PM, Alexander Sverdlin wrote: Hi! On 10/07/15 15:17, ext Vignesh R wrote: I would propose you to throw away spinlocks. Convert threaded IRQ to Agree. Looks like spinlock is not needed. just one hardirq handler. And continue debugging. You will reduce the load of the system with the above measures, maybe it will not happen any more, maybe you'll figure out that problem is somewhere else. Or this. I am not convinced with moving entire code at hardirq context. I believe its better to keep hardirq as small as possible. How deep is the controller's FIFO? 1 byte? 2 bytes? Other drivers can perfectly fill next byte in hardirq handler. If you need to do 10 opcodes more in hardirq handler, it's much better for the whole system than to trigger scheduler and thread and and and just because of these 10 opcodes. 1) TRM: Built-in configurable FIFOs (8, 16, 32, 64 bytes) for buffered read or write. 2) We trying to be as much compatible with RT kernel as possible where all IRQ are threaded. And yes. This patch is u.. WA which tries to fix symptom and not an issue. -- regards, -grygorii -- 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 3/3] PCI: host: pci-dra7xx: add pm support to pci dra7xx
Hi,
On Friday 03 July 2015 05:34 PM, Grygorii Strashko wrote:
Hi Kishon,
On 07/03/2015 02:03 PM, Kishon Vijay Abraham I wrote:
Add PM support to pci-dra7xx so that PCI clocks can be disabled
during suspend and enabled back during resume without affecting
PCI functionality.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/pci/host/pci-dra7xx.c | 74
+
1 file changed, 74 insertions(+)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index d8b6d66..1f5c039 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -433,6 +433,79 @@ static int __exit dra7xx_pcie_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
[...]
+
+static const struct dev_pm_ops dra7xx_pcie_pm_ops = {
+.suspend_noirq = dra7xx_pcie_suspend_noirq,
+.suspend = dra7xx_pcie_suspend,
+.resume_noirq = dra7xx_pcie_resume_noirq,
+.resume = dra7xx_pcie_resume,
Could you use here SET_SYSTEM_SLEEP_PM_OPS()
and SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() macro, pls?
sure!
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add missing #iommu-cells on IOMMU nodes
Hi Tony, This series adds the #iommu-cells property to the existing IOMMU nodes on OMAP4 OMAP5. It was already fixed for OMAP3 in commit 2055088b5e17 (ARM: dts: omap3: Add #iommu-cells to isp and iva iommu). OMAP4 and OMAP5 do not yet have users for these IOMMUs (remoteproc nodes), so the warning as seen with the fix added for OMAP3 is not seen yet, but will as soon as a user is added. Patches based on 4.2-rc1. regards Suman Suman Anna (2): ARM: dts: OMAP4: Add #iommu-cells property to IOMMUs ARM: dts: OMAP5: Add #iommu-cells property to IOMMUs arch/arm/boot/dts/omap4.dtsi | 2 ++ arch/arm/boot/dts/omap5.dtsi | 2 ++ 2 files changed, 4 insertions(+) -- 2.4.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 2/2] ARM: dts: OMAP5: Add #iommu-cells property to IOMMUs
Add missing #iommu-cells property to the DSP and IPU IOMMU nodes
for OMAP5 platforms. This property is required as per the generic
iommu binding.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7d24ae0306b5..c8fd648a7108 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -612,6 +612,7 @@
reg = 0x4a066000 0x100;
interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmu_dsp;
+ #iommu-cells = 0;
};
mmu_ipu: mmu@55082000 {
@@ -619,6 +620,7 @@
reg = 0x55082000 0x100;
interrupts = GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmu_ipu;
+ #iommu-cells = 0;
ti,iommu-bus-err-back;
};
--
2.4.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 1/2] ARM: dts: OMAP4: Add #iommu-cells property to IOMMUs
Add missing #iommu-cells property to the DSP and IPU IOMMU nodes
for OMAP4 platforms. This property is required as per the generic
iommu binding.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index f884d6adb71e..7d31c6ff246f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -551,6 +551,7 @@
reg = 0x4a066000 0x100;
interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmu_dsp;
+ #iommu-cells = 0;
};
mmu_ipu: mmu@55082000 {
@@ -558,6 +559,7 @@
reg = 0x55082000 0x100;
interrupts = GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmu_ipu;
+ #iommu-cells = 0;
ti,iommu-bus-err-back;
};
--
2.4.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 v3] i2c: omap: improve duty cycle on SCL
On Thu, Jul 09, 2015 at 09:42:41PM +0200, Wolfram Sang wrote: On Thu, Jun 18, 2015 at 12:25:58PM -0500, Felipe Balbi wrote: On Thu, Jun 18, 2015 at 10:09:59AM +0200, Alexander Sverdlin wrote: Hello Felipe, On 17/06/15 21:31, ext Felipe Balbi wrote: With this patch we try to be as close to 50% duty cycle as possible. The reason for this is that some devices present an erratic behavior with certain duty cycles. One such example is TPS65218 PMIC which fails to change voltages when running @ 400kHz and duty cycle is lower than 34%. The idea of the patch is simple: calculate desired scl_period from requested scl and use 50% for tLow and 50% for tHigh. tLow is calculated with a DIV_ROUND_UP() to make sure it's slightly higher than tHigh and to make sure that we end up within I2C specifications. if you refuse to change the calculations to achieve maximum possible bus rate (as I've shown you with SCLL=9 and SCLH=9), maybe you want to change the description? Because you are doing something else than is written here. You are only in spec because you are not doing 50% duty cycle. And you didn't mention here that you lower the bus speed below 400kHz to achieve this. and there's a comment where the calculation goes which states as close to 50% as possible but we make sure tLow is higher than tHigh so we're still within spec. So, is that ready to go in for-next? should be. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] i2c: omap: abolish variable name confusion
Hi, On Thu, Jul 09, 2015 at 09:49:41PM +0200, Wolfram Sang wrote: On Thu, Jun 25, 2015 at 02:34:49PM -0500, Felipe Balbi wrote: struct device pointers are usually called dev. Calling our struct omap_i2c_dev pointers also dev has caused enough confusion. This is the result of a few simple sed rules to convert all struct omap_i2c_dev pointers to be called omap instead. Signed-off-by: Felipe Balbi ba...@ti.com I couldn't apply this one. On what was it based? it was v4.1 at the time, IIRC. I'll rebase again once I'm back in the office. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5] usb: dwc3: ep0: use _roundup_ to calculate the transfer size
Hi Felipe, On Tuesday 07 July 2015 12:30 AM, Felipe Balbi wrote: On Wed, Jun 10, 2015 at 02:48:48PM +0530, Kishon Vijay Abraham I wrote: No functional change. Used _roundup_ macro to calculate the transfer size aligned to maxpacket in dwc3_ep0_complete_data. It also makes it similar to how transfer size is calculated in __dwc3_ep0_do_control_data. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com doesn't apply, can you rebase on testing/next ? sure, will send it by early next week. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH stable/v4.0] ARM: OMAP3: Fix booting with thumb2 kernel
From: Tony Lindgren t...@atomide.com
We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)
The power management related assembly on omaps needs to interact with
ARM mode bootrom code, so we need to keep most of the related assembly
in ARM mode.
Turns out this error is because of missing ENDPROC for assembly code
as suggested by Stephen Boyd sb...@codeaurora.org. Let's fix the
problem by adding ENDPROC in two places to sleep34xx.S.
Let's also remove the now duplicate custom code for mode switching.
This has been unnecessary since commit 6ebbf2ce437b (ARM: convert
all mov.* pc, reg to bx reg for ARMv6+).
And let's also remove the comments about local variables, they are
now just confusing after the ENDPROC.
The reason why ENDPROC makes a difference is it sets .type and then
the compiler knows what to do with the thumb bit as explained at:
https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
(cherry picked from commit d8a50941c91a68da202aaa96a3dacd471ea9c693)
Cc: sta...@vger.kernel.org # v4.0+
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/mach-omap2/sleep34xx.S | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index d1dedc8195ed..eafd120b53f1 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -203,23 +203,8 @@ save_context_wfi:
*/
ldr r1, kernel_flush
blx r1
- /*
-* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
-* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
-* This sequence switches back to ARM. Note that .align may insert a
-* nop: bx pc needs to be word-aligned in order to work.
-*/
- THUMB(.thumb )
- THUMB(.align )
- THUMB(bx pc )
- THUMB(nop )
- .arm
-
b omap3_do_wfi
-
-/*
- * Local variables
- */
+ENDPROC(omap34xx_cpu_suspend)
omap3_do_wfi_sram_addr:
.word omap3_do_wfi_sram
kernel_flush:
@@ -364,10 +349,7 @@ exit_nonoff_modes:
* ===
*/
ldmfd sp!, {r4 - r11, pc} @ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
sdrc_power:
.word SDRC_POWER_V
cm_idlest1_core:
--
2.4.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 5/7] tty: 8250: workaround errata on disabling UART after using DMA
On 07/09/2015 10:15 AM, Sekhar Nori wrote:
On Thursday 09 July 2015 07:03 AM, Peter Hurley wrote:
[...]
@@ -1307,6 +1320,36 @@ static int omap8250_runtime_suspend(struct device
*dev)
return -EBUSY;
}
+ if (priv-habit UART_ERRATA_CLOCK_DISABLE) {
+ int sysc;
+ int syss;
+ int timeout = 100;
+
+ sysc = serial_in(up, UART_OMAP_SYSC);
+
+ /* softreset the UART */
+ sysc |= OMAP_UART_SYSC_SOFTRESET;
+ serial_out(up, UART_OMAP_SYSC, sysc);
+
+ /* By experiments, 1us enough for reset complete on AM335x */
+ do {
+ udelay(1);
+ syss = serial_in(up, UART_OMAP_SYSS);
+ } while (--timeout !(syss OMAP_UART_SYSS_RESETDONE));
If there is not a omap helper function to reset modules, there should be.
Open-coding the module reset is not appropriate.
There is work planned to have something implemented for OMAP as part of
drivers/reset/ API. AFAIK, this depends on some PRCM code clean-up
affecting multiple OMAP platforms and is couple of merge windows away
from taking shape.
Meanwhile, I think this is the best we can do. Other drivers like
i2c-omap have done something similar (see omap_i2c_reset()).
Ok, then please make the reset a separate local function
(returning success/failure?). omap_8250_reset()?
A TODO or FIXME above it explaining
the temporary nature of the function would be appreciated :)
+ if (!timeout) {
+ dev_err(dev, timed out waiting for reset done\n);
+ return -ETIMEDOUT;
+ }
+
+ /*
+* For UART module wake-up to work, MDR1.MODESELECT should
+* not be set to Disable, so update it.
+*/
+ if (device_may_wakeup(dev))
+ omap8250_update_mdr1(up, priv);
Should this be unconditional?
I do not see it doing any harm if done unconditionally. But it will be
unnecessary. Unless the UART is being used for wakeup, we don't need
MDR1 restored at this stage. And omap8250_restore_regs() will eventually
restore the register anyway.
Yeah, I understand that, but special-casing it isn't adding any value;
it's not as if you actually want the module to not be in UART mode.
And the comment could be single-line:
/* Restore to UART mode after reset (for wakeup) */
Regards,
Peter Hurley
--
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
OMAP baseline test results for v4.1
Here are some basic OMAP test results for Linux v4.1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1/20150626170101/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-stk-om44, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (14/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_oldconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 3730es12beaglexm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 3730es12beaglexm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 2/ 4): 37xxevm, 3730es12beaglexm Pass ( 2/ 4): 3530es3beagle, 3530es31beagle PM: chip off via dynamic idle: FAIL ( 2/ 4): 37xxevm, 3730es12beaglexm Pass ( 2/ 4): 3530es3beagle, 3530es31beagle Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.1-rc8 (0f57d86787d8b1076ea8f9cba2a46d534a27)): text data bsstotal kernel 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0 +80 +8 omap1_defconfig_5912osk_only -3200 -32 multi_v7_defconfig +6400 +64 omap2plus_defconfig +3200 +32 omap2plus_defconfig_2430sdp_only +6400 +64 omap2plus_defconfig_am33xx_only +6400 +64 omap2plus_defconfig_am43xx_only +6400 +64 omap2plus_defconfig_cpupm +6400 +64 omap2plus_defconfig_dra7xx_only -64
OMAP baseline test results for v4.2-rc1
Here are some basic OMAP test results for Linux v4.2-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc1/20150705171039/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-stk-om44, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.1 (b953c0d234bc72e8489d3bf51a276c5c4ec85345)): text data bsstotal kernel +49744 -60136 +10456 +64 omap1_defconfig +48684 -60136 +10456 -996 omap1_defconfig_1510innovator_only +49752 -56296 +10520+3976 omap1_defconfig_5912osk_only -319515 +45664+8640 -265211 multi_v7_defconfig +94414-8216+4992 +91190 omap2plus_defconfig +85692+4432+4856 +94980 omap2plus_defconfig_2430sdp_only +106074+5320+4928 +116322 omap2plus_defconfig_am33xx_only +101982+5448+4992 +112422 omap2plus_defconfig_am43xx_only +94414-8216+4928 +91126 omap2plus_defconfig_cpupm +103166+6472+4928 +114566 omap2plus_defconfig_dra7xx_only +37781+3952+4736 +46469 omap2plus_defconfig_n800_multi_omap2xxx +12695+3928+4200 +20823 omap2plus_defconfig_n800_only_a +92086-7392+5056 +89750 omap2plus_defconfig_no_pm +106498+6504+4864 +117866 omap2plus_defconfig_omap2_4_only +97350 -12312+4928 +89966
[PATCH] ARM: OMAP2+: Remove module references from IOMMU machine layer
The OMAP IOMMU driver has been adapted to the IOMMU framework
for a while now, and it no longer supports being built as a
module. Cleanup all the module related references both from
the code and in the build.
While at it, also relocate a comment around the initcall to
avoid a checkpatch strict warning about using a blank line
after function/struct/union/enum declarations.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +--
arch/arm/mach-omap2/omap-iommu.c | 13 +
2 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 903c85be2897..d4579f856b25 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -234,8 +234,7 @@ obj-$(CONFIG_SOC_DRA7XX)+= omap_hwmod_7xx_data.o
# EMU peripherals
obj-$(CONFIG_HW_PERF_EVENTS) += pmu.o
-iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
-obj-y += $(iommu-m) $(iommu-y)
+obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
# OMAP2420 MSDI controller integration support (MMC)
obj-$(CONFIG_SOC_OMAP2420) += msdi.o
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 4068350f9059..8867eb4025bf 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -11,7 +11,6 @@
*/
#include linux/of.h
-#include linux/module.h
#include linux/platform_device.h
#include linux/err.h
#include linux/slab.h
@@ -63,15 +62,5 @@ static int __init omap_iommu_init(void)
return omap_hwmod_for_each_by_class(mmu, omap_iommu_dev_init, NULL);
}
-/* must be ready before omap3isp is probed */
omap_subsys_initcall(omap_iommu_init);
-
-static void __exit omap_iommu_exit(void)
-{
- /* Do nothing */
-}
-module_exit(omap_iommu_exit);
-
-MODULE_AUTHOR(Hiroshi DOYU);
-MODULE_DESCRIPTION(omap iommu: omap device registration);
-MODULE_LICENSE(GPL v2);
+/* must be ready before omap3isp is probed */
--
2.4.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] ARM: OMAP2+: Add HAVE_ARM_SCU for AM43XX
CONFIG_HAVE_ARM_SCU only gets selected if CONFIG_SMP is selected in an OMAP system, however AM43XX needs this option regardless of CONFIG_SMP and also for an AM43XX only build as it is important for controlling power in the SoC. Without this we cannot suspend the CPU for SoC suspend or cpuidle. The ARM Cortex A9 needs SCU CPU Power Status bits to be set to off mode in order for the PRCM to transition the MPU to low power modes. Signed-off-by: Dave Gerlach d-gerl...@ti.com --- arch/arm/mach-omap2/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index ecc04ff..4a023e8 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -60,6 +60,7 @@ config SOC_AM43XX select ARM_GIC select MACH_OMAP_GENERIC select MIGHT_HAVE_CACHE_L2X0 + select HAVE_ARM_SCU config SOC_DRA7XX bool TI DRA7XX -- 2.4.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
