Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Mon, Apr 09, 2012 at 03:18:22PM -0500, Jon Hunter wrote: True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. Why? What if you want to have PM enabled, and you also want to use the kernels high resolution timers, or you want more accurate timing than the 30.5us tick interval of the 32k timer? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tuesday 10 April 2012 02:14 PM, Russell King - ARM Linux wrote: On Mon, Apr 09, 2012 at 03:18:22PM -0500, Jon Hunter wrote: True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. Why? What if you want to have PM enabled, and you also want to use the kernels high resolution timers, or you want more accurate timing than the 30.5us tick interval of the 32k timer? You might have missed the earlier comments on the thread. High resolution GP timer(sysclk) will stop in deeper power states and hence it can't be used with PM enabled usecases. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] Input: omap-keypad: dynamically handle register offsets
On Tue, Apr 03, 2012 at 10:52:26AM +0530, Sourav Poddar wrote:
+static int kbd_write_irqstatus(struct omap4_keypad *keypad_data,
+ u32 offset, u32 value)
+{
+ return __raw_writel(value, keypad_data-base + offset);
+}
+
+static int kbd_write_irqenable(struct omap4_keypad *keypad_data,
+ u32 offset, u32 value)
+{
+ return __raw_writel(value, keypad_data-base + offset);
+}
if this only writes to irqenable, why do you pass offset as an argument?
likewise for irqstatus.
--
balbi
signature.asc
Description: Digital signature
Re: Suspend broken on 3.3?
Hi Kevin, On Mon, Apr 9, 2012 at 10:40 PM, Kevin Hilman khil...@ti.com wrote: Paul Walmsley p...@pwsan.com writes: [...] I don't understand why a user would ever want to disable dynamic wakeups on an in-use serial port via the sysfs power/wakeup file. (Disabling wakeups from suspend is a different matter, of course.) The OMAP UART driver needs hardware wakeups to function for FIFO drain wakeups, etc. So to me it really doesn't make sense to disable those types of wakeup events, ever. But maybe you know of some use-case that I don't? No, I don't have a use-case in mind. The more I try to remember why we added support to use the sysfs wakeup attribute to manage idle, the more I think we can probably drop it now. IIRC, it was added because on most boards we used to blindly initialize all the UARTs, including default wakeup settings (we still do this on many boards.) However, now that we have a real PM-aware driver for OMAP UARTs, this should all be handled from the driver itself, so the sysfs wakeup attribute should go back to only managing wakeups from suspend and wakeups during idle should always be on for in-use UARTs. Just to summarize on how the behavior should be IIUC if user disables uart wakeup from sysfs and does system wide suspend it should _not_ wakeup from uart. And if the system is woken up from suspend due to keypad press and uart resumes we have keep module level wakeup enabled from here. We might need some minor changes in omap-serial to have this behavior which I plan to do once we are aligned on this. -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tue, Apr 10, 2012 at 02:27:36PM +0530, Santosh Shilimkar wrote: On Tuesday 10 April 2012 02:14 PM, Russell King - ARM Linux wrote: On Mon, Apr 09, 2012 at 03:18:22PM -0500, Jon Hunter wrote: True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. Why? What if you want to have PM enabled, and you also want to use the kernels high resolution timers, or you want more accurate timing than the 30.5us tick interval of the 32k timer? You might have missed the earlier comments on the thread. High resolution GP timer(sysclk) will stop in deeper power states and hence it can't be used with PM enabled usecases. Which means folk should be given the choice at boot time between running with the deeper power states and having a higher resolution timing source, rather than denying them the higher resolution timing source when PM is enabled. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tue, Apr 10, 2012 at 2:59 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Apr 10, 2012 at 02:27:36PM +0530, Santosh Shilimkar wrote: On Tuesday 10 April 2012 02:14 PM, Russell King - ARM Linux wrote: On Mon, Apr 09, 2012 at 03:18:22PM -0500, Jon Hunter wrote: True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. Why? What if you want to have PM enabled, and you also want to use the kernels high resolution timers, or you want more accurate timing than the 30.5us tick interval of the 32k timer? You might have missed the earlier comments on the thread. High resolution GP timer(sysclk) will stop in deeper power states and hence it can't be used with PM enabled usecases. Which means folk should be given the choice at boot time between running with the deeper power states and having a higher resolution timing source, rather than denying them the higher resolution timing source when PM is enabled. Good point. My point is such facilities is already part of the kernel and there is no need to add a new one. The last proposal was allowing user to choose gptimer as a clocksource and then you already have facility to disable C-state now so, all should work in general Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap-hsmmc build broken with OF enabled in latest kernel
This commit:
commit 46856a68dcb5f67c779d211fd6bcb5d7a2a7f19b
Author: Rajendra Nayak rna...@ti.com
Date: Mon Mar 12 20:32:37 2012 +0530
mmc: omap_hsmmc: Convert hsmmc driver to use device tree
Define dt bindings for the ti-omap-hsmmc, and adapt the driver to extract
data (which was earlier passed as platform_data) from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Chris Ball c...@laptop.org
breaks omap-hsmmc compilation:
drivers/mmc/host/omap_hsmmc.c:1745: error: expected ',' or ';' before 'extern'
+#ifdef CONFIG_OF
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
...
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
There should be a ';' after the }.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL]: omap-serial updates for 3.4-rc
Hi Tony, Please Pull the following omap uart changes. Changes basically involves getting rid of cpu checks for populating erratas and features and move the same from serial.c to omap-serial.c, MVR reg is used to find uart versions and errata flags are populated accordingly. -- Thanks, Govindraj.R The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e: Linux 3.4-rc2 (2012-04-07 18:30:41 -0700) are available in the git repository at: git://gitorious.org/linux-3-x/omap-serial.git for_3.4/uart_fixes for you to fetch changes up to 6c34f211069409ea6d08b900eeaf86ef8efd0dca: OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx (2012-04-10 15:14:58 +0530) Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 +--- arch/arm/plat-omap/include/plat/omap-serial.h |9 +++- drivers/tty/serial/omap-serial.c | 83 - 3 files changed, 91 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL]: omap-serial updates for 3.4-rc
CC'ing Linux-ARM On Tue, Apr 10, 2012 at 3:32 PM, Govindraj.R govindraj.r...@ti.com wrote: Hi Tony, Please Pull the following omap uart changes. Changes basically involves getting rid of cpu checks for populating erratas and features and move the same from serial.c to omap-serial.c, MVR reg is used to find uart versions and errata flags are populated accordingly. -- Thanks, Govindraj.R The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e: Linux 3.4-rc2 (2012-04-07 18:30:41 -0700) are available in the git repository at: git://gitorious.org/linux-3-x/omap-serial.git for_3.4/uart_fixes for you to fetch changes up to 6c34f211069409ea6d08b900eeaf86ef8efd0dca: OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx (2012-04-10 15:14:58 +0530) Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 +--- arch/arm/plat-omap/include/plat/omap-serial.h | 9 +++- drivers/tty/serial/omap-serial.c | 83 - 3 files changed, 91 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 RESEND] Input: omap-keypad: dynamically handle register offsets
On Tue, Apr 10, 2012 at 03:37:28PM +0530, Poddar, Sourav wrote:
Hi Felipe,
On Tue, Apr 10, 2012 at 2:54 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Apr 03, 2012 at 10:52:26AM +0530, Sourav Poddar wrote:
+static int kbd_write_irqstatus(struct omap4_keypad *keypad_data,
+ u32 offset, u32 value)
+{
+ return __raw_writel(value, keypad_data-base + offset);
+}
+
+static int kbd_write_irqenable(struct omap4_keypad *keypad_data,
+ u32 offset, u32 value)
+{
+ return __raw_writel(value, keypad_data-base + offset);
+}
if this only writes to irqenable, why do you pass offset as an argument?
likewise for irqstatus.
Actually, here the offset is the irqenable register addresss offset and
irqstatus register
address offset from the base address.
Since, the above two address are different in case of Omap4 and omap5, we are
passing an offset
depending on the particular revision of the keyboard selected during probe.
but you already have those in keypad_data-irqenable/irqstatus right ?
Meaning you can access them directly here and save on the arguments:
static int kbd_write_irqenable(struct omap4_keypad *keypad_data, u32 value)
{
return __raw_writel(value, keypad_data-base + keypad_data-irqenable);
}
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH RESEND] Input: omap-keypad: dynamically handle register offsets
Hi Felipe,
On Tue, Apr 10, 2012 at 3:46 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Apr 10, 2012 at 03:37:28PM +0530, Poddar, Sourav wrote:
Hi Felipe,
On Tue, Apr 10, 2012 at 2:54 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Apr 03, 2012 at 10:52:26AM +0530, Sourav Poddar wrote:
+static int kbd_write_irqstatus(struct omap4_keypad *keypad_data,
+ u32 offset, u32 value)
+{
+ return __raw_writel(value, keypad_data-base + offset);
+}
+
+static int kbd_write_irqenable(struct omap4_keypad *keypad_data,
+ u32 offset, u32 value)
+{
+ return __raw_writel(value, keypad_data-base + offset);
+}
if this only writes to irqenable, why do you pass offset as an argument?
likewise for irqstatus.
Actually, here the offset is the irqenable register addresss offset and
irqstatus register
address offset from the base address.
Since, the above two address are different in case of Omap4 and omap5, we
are
passing an offset
depending on the particular revision of the keyboard selected during probe.
but you already have those in keypad_data-irqenable/irqstatus right ?
Yes.
Meaning you can access them directly here and save on the arguments:
static int kbd_write_irqenable(struct omap4_keypad *keypad_data, u32 value)
{
return __raw_writel(value, keypad_data-base + keypad_data-irqenable);
}
Thanks a lot for pointing this out. Yes, we should be able to directly use
the driver data for the above api.
Will make the necessary change in the next version.
~Sourav
--
balbi
--
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/19] I2C updates
The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. v2 changes -Adds a patch to use devm_* functions -Also checks the return type of the get_sync and in case of errors prevents register access. - In case of i2c remove register access was done without any get_sync fix the same. - Adds a pdata function pointer to do context save restore v3 changes - Split the omap_i2c_isr to increase readability - Adds the restore flag patch for OMAP4 to the series - Make the i2c use SET_RUNTIME_PM_OPS v4 changes - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. v5 changes - Add consistency in the subject naming. v6 changes - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. [1] http://www.spinics.net/lists/linux-i2c/msg07607.html Tested on omap4sdp and omap3sdp. The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7: modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700) are available in the git repository at: g...@gitorious.org:linus-tree/linus-tree.git i2c_omap-next Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (16): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Remove reset at init I2C: OMAP: I2C register restore only if context is lost I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Optimise the remove code I2C: OMAP: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: use devm_* functions I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Use SET_RUNTIME_PM_OPS I2C: OMAP: make the read ready processing a separate function I2C: OMAP: Do not set the XUDF if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 ARM: OMAP4: hwmod data: I2C: add flag for context restore Tasslehoff Kjappfot (1): I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153 Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +- arch/arm/plat-omap/i2c.c |3 + drivers/i2c/busses/i2c-omap.c | 342 +++- include/linux/i2c-omap.h |1 + 4 files changed, 194 insertions(+), 155 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 19/19] ARM: OMAP4: hwmod data: I2C: add flag for context restore
Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Wamsley p...@pwsan.com
Reviewed-by: Kevin Hilman khil...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 08daa5e..cddce60 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2262,7 +2262,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
+ OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
};
/* i2c1 */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 11/19] I2C: OMAP: use devm_* functions
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_mem_region and
devm_ioremap for data that is allocated in the probe function of a platform
device and is only freed in the remove function.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 29 +
1 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 121c52e..86be475 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -995,17 +995,17 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem-start, resource_size(mem),
- pdev-name);
+ ioarea = devm_request_mem_region(pdev-dev, mem-start,
+ resource_size(mem), pdev-name);
if (!ioarea) {
dev_err(pdev-dev, I2C region already claimed\n);
return -EBUSY;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev_err(pdev-dev, Menory allocation failed\n);
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -1029,11 +1029,10 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq-start;
- dev-base = ioremap(mem-start, resource_size(mem));
- if (!dev-base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
+ dev-base = devm_ioremap(pdev-dev, mem-start, resource_size(mem));
+ if (!dev-base)
+ return -ENOMEM;
+
platform_set_drvdata(pdev, dev);
@@ -1121,13 +1120,8 @@ err_free_irq:
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
- iounmap(dev-base);
pm_runtime_disable(pdev-dev);
-err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem-start, resource_size(mem));
return r;
}
@@ -1135,7 +1129,6 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
platform_set_drvdata(pdev, NULL);
@@ -1143,10 +1136,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
i2c_del_adapter(dev-adapter);
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_disable(pdev-dev);
- iounmap(dev-base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 18/19] I2C: OMAP: Rename the 1p153 to the erratum id i462
The section number in the recent errata document has changed.
Rename the erratum 1p153 to the unique id i462 instead, so that
it is easier to reference. Also change the function name and comments
to reflect the same.
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a3160d1..7b24b44 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -170,7 +170,7 @@ enum {
/* Errata definitions */
#define I2C_OMAP_ERRATA_I207 (1 0)
-#define I2C_OMAP3_1P153(1 1)
+#define I2C_OMAP_ERRATA_I462 (1 1)
struct omap_i2c_dev {
struct device *dev;
@@ -751,11 +751,11 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
#endif
/*
- * OMAP3430 Errata 1.153: When an XRDY/XDR is hit, wait for XUDF before writing
+ * OMAP3430 Errata i462: When an XRDY/XDR is hit, wait for XUDF before writing
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
{
unsigned long timeout = 1;
@@ -918,8 +918,8 @@ complete:
break;
}
- if ((dev-errata I2C_OMAP3_1P153)
- errata_omap3_1p153(dev, stat, err))
+ if ((dev-errata I2C_OMAP_ERRATA_I462)
+ errata_omap3_i462(dev, stat, err))
goto complete;
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
@@ -1057,7 +1057,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-errata |= I2C_OMAP_ERRATA_I207;
if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
- dev-errata |= I2C_OMAP3_1P153;
+ dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
u16 s;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 17/19] I2C: OMAP: Do not set the XUDF if the underflow is not reached
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF flag is also set.
The flag is set after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Cc: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 51576d6..a3160d1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -763,7 +763,6 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- *err |= OMAP_I2C_STAT_XUDF;
return -ETIMEDOUT;
}
@@ -776,6 +775,7 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
return 0;
}
+ *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 07/19] I2C: OMAP: Optimise the remove code
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3670088..2096726 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1134,8 +1134,7 @@ err_release_region:
return r;
}
-static int
-omap_i2c_remove(struct platform_device *pdev)
+static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
struct resource *mem;
@@ -1228,7 +1227,7 @@ static struct dev_pm_ops omap_i2c_pm_ops = {
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
- .remove = omap_i2c_remove,
+ .remove = __devexit_p(omap_i2c_remove),
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 15/19] I2C: OMAP: make the read ready processing a separate function
No functional change. Makes the read ready processing a separate
function. This is to avoid extremely long level of indentation.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 86 +---
1 files changed, 45 insertions(+), 41 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a5b1ec1..c113f41 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -784,6 +784,49 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev,
u16 *stat, int *err)
return 0;
}
+static int process_read_rdy(struct omap_i2c_dev *dev)
+{
+ u8 num_bytes = 1;
+ u16 stat, w;
+
+ if (dev-errata I2C_OMAP_ERRATA_I207)
+ i2c_omap_errata_i207(dev, stat);
+
+ if (dev-fifo_size) {
+ if (stat OMAP_I2C_STAT_RRDY)
+ num_bytes = dev-fifo_size;
+ else/* read RXSTAT on RDR interrupt */
+ num_bytes = (omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG) 8) 0x3F;
+ }
+ while (num_bytes) {
+ num_bytes--;
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ if (dev-buf_len) {
+ *dev-buf++ = w;
+ dev-buf_len--;
+ /*
+* Data reg in 2430, omap3 and omap4 is 8 bit wide
+*/
+ if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
+ } else {
+ if (stat OMAP_I2C_STAT_RRDY)
+ dev_err(dev-dev,
+ RRDY IRQ while no data requested\n);
+ if (stat OMAP_I2C_STAT_RDR)
+ dev_err(dev-dev,
+ RDR IRQ while no data requested\n);
+ return -EIO;
+ }
+ }
+ return 0;
+}
+
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
{
@@ -834,48 +877,9 @@ complete:
return IRQ_HANDLED;
}
if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
- u8 num_bytes = 1;
-
- if (dev-errata I2C_OMAP_ERRATA_I207)
- i2c_omap_errata_i207(dev, stat);
+ if (process_read_rdy(dev) == -EIO)
+ break;
- if (dev-fifo_size) {
- if (stat OMAP_I2C_STAT_RRDY)
- num_bytes = dev-fifo_size;
- else/* read RXSTAT on RDR interrupt */
- num_bytes = (omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG)
-8) 0x3F;
- }
- while (num_bytes) {
- num_bytes--;
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- if (dev-buf_len) {
- *dev-buf++ = w;
- dev-buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
- }
- } else {
- if (stat OMAP_I2C_STAT_RRDY)
- dev_err(dev-dev,
- RRDY IRQ while no data
-requested\n);
- if (stat OMAP_I2C_STAT_RDR)
- dev_err(dev-dev,
- RDR IRQ while no data
-requested\n);
- break;
- }
- }
[PATCHv6 06/19] I2C: OMAP: Fix the mismatch of pm_runtime enable and disable
Currently the i2c driver calls the pm_runtime_enable and never the disable. This may cause a warning when pm_runtime_enable checks for the count match.Attempting to fix the same by calling pm_runtime_disable in the error and the remove path. Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 2769f67..3670088 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1124,6 +1124,7 @@ err_unuse_clocks: omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); pm_runtime_put(dev-dev); iounmap(dev-base); + pm_runtime_disable(pdev-dev); err_free_mem: platform_set_drvdata(pdev, NULL); kfree(dev); @@ -1144,6 +1145,7 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(dev); mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 02/19] I2C: OMAP: Remove reset at init
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
omap_i2c_reset is added in those places to effect the reset.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4f4188d..e402ebb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,15 +269,9 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static int omap_i2c_init(struct omap_i2c_dev *dev)
+static int omap_i2c_reset(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
- u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
- unsigned long fclk_rate = 1200;
unsigned long timeout;
- unsigned long internal_clk = 0;
- struct clk *fclk;
-
if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -325,6 +319,16 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-westate);
}
}
+}
+
+static int omap_i2c_init(struct omap_i2c_dev *dev)
+{
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
+ unsigned long fclk_rate = 1200;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
@@ -548,6 +552,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
return r;
if (r == 0) {
dev_err(dev-dev, controller timed out\n);
+ omap_i2c_reset(dev);
omap_i2c_init(dev);
return -ETIMEDOUT;
}
@@ -558,6 +563,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
/* We have an error */
if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
+ omap_i2c_reset(dev);
omap_i2c_init(dev);
return -EIO;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 04/19] I2C: OMAP: I2C register restore only if context is lost
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/i2c.c |3 ++
drivers/i2c/busses/i2c-omap.c | 52 ++--
include/linux/i2c-omap.h |1 +
3 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index db071bc..4ccab07 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -179,6 +179,9 @@ static inline int omap2_i2c_add_bus(int bus_id)
*/
if (cpu_is_omap34xx())
pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
+
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a882558..45389db 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,6 +43,7 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
+#include plat/omap_device.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -157,9 +158,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK(1 0)
-
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
#define SYSC_SIDLEMODE_MASK(0x3 3)
@@ -184,6 +182,7 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
+ int (*get_context_loss_count)(struct device *dev);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -206,6 +205,7 @@ struct omap_i2c_dev {
u16 syscstate;
u16 westate;
u16 errata;
+ int dev_lost_count;
};
static const u8 reg_map_ip_v1[] = {
@@ -1025,6 +1025,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-speed = pdata-clkrate;
dev-flags = pdata-flags;
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
+ dev-get_context_loss_count = pdata-get_context_loss_count;
dev-dtrev = pdata-rev;
}
@@ -1151,12 +1152,32 @@ omap_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_RUNTIME
+static void omap_i2c_restore(struct omap_i2c_dev *dev)
+{
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (dev-iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+
+}
static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
u16 iv;
+ if (_dev-get_context_loss_count)
+ _dev-dev_lost_count = _dev-get_context_loss_count(dev);
+
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
@@ -1179,24 +1200,19 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ int loss_cnt;
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG,
[PATCHv6 09/19] I2C: OMAP: Correct I2C revision for OMAP3
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a461097..959e97c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -50,8 +50,8 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
-#define OMAP_I2C_REV_ON_3430 0x3C
-#define OMAP_I2C_REV_ON_3530_4430 0x40
+#define OMAP_I2C_REV_ON_3430_3530 0x3C
+#define OMAP_I2C_REV_ON_3630_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
@@ -1051,7 +1051,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
- if (dev-rev = OMAP_I2C_REV_ON_3430)
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
dev-errata |= I2C_OMAP3_1P153;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
@@ -1069,7 +1069,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
+ if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 0; /* Disable hardware fixes */
else
dev-b_hw = 1; /* Enable hardware fixes */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 10/19] I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the wait_for_completion_timeout returns long.
Original patch is
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=ea02cece7bbc736e60c4188a11aaa74bc6e6
Cc : Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 959e97c..121c52e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -502,7 +502,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
struct i2c_msg *msg, int stop)
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
- int r;
+ unsigned long timeout;
u16 w;
dev_dbg(dev-dev, addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n,
@@ -570,12 +570,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
- r = wait_for_completion_timeout(dev-cmd_complete,
- OMAP_I2C_TIMEOUT);
+ timeout = wait_for_completion_timeout(dev-cmd_complete,
+ OMAP_I2C_TIMEOUT);
dev-buf_len = 0;
- if (r 0)
- return r;
- if (r == 0) {
+ if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_reset(dev);
omap_i2c_init(dev);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 12/19] I2C: OMAP: Fix the crash in i2c remove
In omap_i2c_remove we are accessing the I2C_CON register without enabling the clocks. Fix the same by enabling the clocks and disabling it. This fixes the following crash. [ 154.723022] [ cut here ] [ 154.725677] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:112 l3_interrupt_handler+0x1b4/0x1c4() [ 154.725677] L3 custom error: MASTER:MPU TARGET:L4 PER2 [ 154.742614] Modules linked in: i2c_omap(-) [ 154.746948] Backtrace: [ 154.746948] [c0013078] (dump_backtrace+0x0/0x110) from [c026c158] (dump_stack+0x18/0x1c) [ 154.752716] r6:0070 r5:c002c43c r4:df9b9e98 r3:df9b8000 [ 154.764465] [c026c140] (dump_stack+0x0/0x1c) from [c0041a2c] (warn_slowpath_common+0x5c/0x6c) [ 154.768341] [c00419d0] (warn_slowpath_common+0x0/0x6c) from [c0041ae0] (warn_slowpath_fmt+0x38/0x40) [ 154.776153] r8:0180 r7:c0361594 r6:c0379b48 r5:00080003 r4:e0838b00 [ 154.790771] r3:0009 [ 154.791778] [c0041aa8] (warn_slowpath_fmt+0x0/0x40) from [c002c43c] (l3_interrupt_handler+0x1b4/0x1c4) [ 154.803710] r3:c0361598 r2:c02ef74c [ 154.807403] [c002c288] (l3_interrupt_handler+0x0/0x1c4) from [c0085f44] (handle_irq_event_percpu+0x58/0 [ 154.818237] r8:002a r7: r6: r5:df808054 r4:df8893c0 [ 154.825378] [c0085eec] (handle_irq_event_percpu+0x0/0x188) from [c00860b8] (handle_irq_event+0x44/0x64) [ 154.835662] [c0086074] (handle_irq_event+0x0/0x64) from [c0088ec0] (handle_fasteoi_irq+0xa4/0x10c) [ 154.845458] r6:002a r5:df808054 r4:df808000 r3:c034a150 [ 154.846466] [c0088e1c] (handle_fasteoi_irq+0x0/0x10c) from [c0085ed0] (generic_handle_irq+0x30/0x38) [ 154.854278] r5:c034aa48 r4:002a [ 154.862091] [c0085ea0] (generic_handle_irq+0x0/0x38) from [c000fd38] (handle_IRQ+0x60/0xc0) [ 154.874450] r4:c034ea70 r3:01f8 [ 154.878234] [c000fcd8] (handle_IRQ+0x0/0xc0) from [c0008478] (gic_handle_irq+0x20/0x5c) [ 154.887023] r7:ff40 r6:df9b9fb0 r5:c034e2b4 r4:001a [ 154.887054] [c0008458] (gic_handle_irq+0x0/0x5c) from [c000ea80] (__irq_usr+0x40/0x60) [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) [ 154.907104] 9fa0: beaf1f04 4006be00 000f 000c [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 0007b8d7 [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- Cc: sta...@vger.kernel.org Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 86be475..8258597 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1134,7 +1134,9 @@ static int __devexit omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); + pm_runtime_get_sync(pdev-dev); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); return 0; } -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 16/19] I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153
From: Tasslehoff Kjappfot tasskj...@gmail.com i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again. Move the errata handling to i2c_probe. Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index c113f41..51576d6 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -431,11 +431,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1056,6 +1051,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430_3530) dev-errata |= I2C_OMAP3_1P153; -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 13/19] I2C: OMAP: Handle error check for pm runtime
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8258597..95f1b2f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -616,7 +616,9 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
int i;
int r;
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0)
+ return r;
r = omap_i2c_wait_for_bb(dev);
if (r 0)
@@ -1044,7 +1046,9 @@ omap_i2c_probe(struct platform_device *pdev)
dev-regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(dev-dev);
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0)
+ return r;
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
@@ -1129,12 +1133,15 @@ err_unuse_clocks:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
+ int ret;
platform_set_drvdata(pdev, NULL);
free_irq(dev-irq, dev);
i2c_del_adapter(dev-adapter);
- pm_runtime_get_sync(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret 0)
+ return ret;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 03/19] I2C: OMAP: Recover from Bus Busy condition
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0.
I acknowledge the contributions and suggestions of Jon and Hemant.
A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and typically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e402ebb..a882558 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -147,16 +147,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test enable */
#define OMAP_I2C_SYSTEST_FREE (1 14) /* Free running mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK(3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST(2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP(3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-#endif
/* OCP_SYSSTATUS bit definitions */
#define SYSS_RESETDONE_MASK(1 0)
@@ -319,6 +318,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
dev-westate);
}
}
+ return 0;
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -471,6 +471,31 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
}
/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+* Per the I2C specification, if we are stuck in a bus busy state
+* we can attempt a bus clear to try and recover the bus by sending
+* at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+* will output a continuous clock on SCL.
+*/
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, (OMAP_I2C_SYSTEST_ST_EN
+ | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_reset(dev);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
+
+/*
* Low level master read/write transaction.
*/
static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
@@ -597,6 +622,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 14/19] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 95f1b2f..a5b1ec1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1211,15 +1211,12 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
@@ -1227,7 +1224,7 @@ static struct platform_driver omap_i2c_driver = {
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
- .pm = OMAP_I2C_PM_OPS,
+ .pm = omap_i2c_pm_ops,
.of_match_table = of_match_ptr(omap_i2c_of_match),
},
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 08/19] I2C: OMAP: Fix the error handling
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
goto err_free_irq;
}
...
return 0;
err_free_irq:
free_irq(dev-irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
This may access the i2c registers without the clocks.
Attempting to fix the same by moving the pm_rintime_put after the error check.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2096726..a461097 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1095,8 +1095,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, pdev-id,
dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed);
- pm_runtime_put(dev-dev);
-
adap = dev-adapter;
i2c_set_adapdata(adap, dev);
adap-owner = THIS_MODULE;
@@ -1116,6 +1114,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
+ pm_runtime_put(dev-dev);
+
return 0;
err_free_irq:
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 01/19] I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not defined
CC arch/arm/mach-omap2/board-ti8168evm.o
drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not
used
drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used
CC net/ipv4/ip_forward.o
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 75 +---
1 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..4f4188d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,47 +269,6 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
-* Don't write to this register if the IE state is 0 as it can
-* cause deadlock.
-*/
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
-}
-
-static void omap_i2c_idle(struct omap_i2c_dev *dev)
-{
- u16 iv;
-
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
-
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
- } else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
-
- /* Flush posted write */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
-}
-
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
@@ -1163,8 +1122,22 @@ static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ u16 iv;
+
+ _dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
+ if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
+ iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ } else {
+ omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
- omap_i2c_idle(_dev);
+ /* Flush posted write */
+ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
+ }
return 0;
}
@@ -1174,7 +1147,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- omap_i2c_unidle(_dev);
+ if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
+
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (_dev-iestate)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
RE: [PATCH v3 1/9] ARM: OMAP2+: gpmc: driver conversion
Hi Jon,
On Tue, Apr 10, 2012 at 01:20:37, Hunter, Jon wrote:
Because num_irq (or available irqs for fictitious irq chip) is platform
specific.
Ok, so OMAP_GPMC_NR_IRQS is defined and will not vary from device to
device, so why pass this? Why not use it directly?
Because OMAP_GPMC_NR_IRQS is platform specific, final intention is to
not have any platform specific header files in GPMC driver, not sure
as of now whether it would be possible. So keeping platform specific
things away from the driver as much as possible.
And consider scenario where GPMC IP is used in other than OMAP family,
even though this a theoretical case, wanted to stress the point that
intention is to keep driver platform independent.
Or else dynamic allocation of irqs may have to be used.
Furthermore, GPMC_NR_IRQ is defined as 6 which is correct for OMAP2/3
but not for OMAP4/5, it is 5. Therefore, we need to detect whether we
are using an OMAP2/3 or OMAP4+ and set num_irqs based upon this. This
could be done in the probe and we can avoid passing this.
Is it dependent on OMAPX or GPMC IP version? if it is IP version, then driver
can be enhanced to handle it, if not, platform has to pass this information.
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (res == NULL)
+ dev_warn(gpmc-dev, Failed to get resource: irq\n);
+ else
+ gpmc-master_irq = res-start;
Why not return an error if the IRQ is not found? We don't know if anyone
will be trying to use them.
Why do you want to do that ?
Because this indicates a BUG :-)
I disagree, this need not be considered a bug always,
for eg. If gpmc irq is not connected to intc
If someone (say NAND) wants to work with irq, and if interrupt is not
available, NAND driver can fail, and suppose smsc911x ethernet is present
and he is not using gpmc irq, if we fail here, smsc911x also would
not work, which would have worked otherwise.
It is a different matter that even NAND setup will happen properly,
even if interrupt is not available, it is only when NAND is told to
work with IRQ, it fails, please see nand patches.
And as of now in mainline (with the code as is), there is not a single
board that will need gpmc irq for gpmc peripherals to work.
I feel we should try to get more devices working rather than preventing
more devices from working, when it could have.
I understand your point, but then you are hiding a BUG. If someone
introduces a BUG that causes this to fail, then it is easier to detect,
find and fix.
From my perspective get the resources should never fail and if it does
and break the driver for all devices, then so be it, because a BUG has
been introduced. Ok, this may not be critical at this point but still is
should not fail.
Agree for resources which are a must for device to work, not for resources
that can enhance its capability.
+ for (gdq = gp-device_pdata, gd = gpmc-device; *gdq; gdq++, i++) {
+ ret = gpmc_setup_device(*gdq, gd, gpmc);
+ if (IS_ERR_VALUE(ret))
+ dev_err(gpmc-dev, gpmc setup on %s failed\n,
+ (*gdq)-name);
+ else
+ gd++;
+ }
Would a while loop be simpler?
My preference is to go with for
Ok, just wondering if this could be cleaned up a little.
For travelling through array of pointers, for looks natural to me, if you
have a better way, please send it, it can be folded in next version.
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] I2C updates
On Tue, Apr 10, 2012 at 4:26 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. v2 changes -Adds a patch to use devm_* functions -Also checks the return type of the get_sync and in case of errors prevents register access. - In case of i2c remove register access was done without any get_sync fix the same. - Adds a pdata function pointer to do context save restore v3 changes - Split the omap_i2c_isr to increase readability - Adds the restore flag patch for OMAP4 to the series - Make the i2c use SET_RUNTIME_PM_OPS v4 changes - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. v5 changes - Add consistency in the subject naming. v6 changes - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. [1] http://www.spinics.net/lists/linux-i2c/msg07607.html Tested on omap4sdp and omap3sdp. The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7: modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700) are available in the git repository at: g...@gitorious.org:linus-tree/linus-tree.git i2c_omap-next Minor nit: You might want to indicate a git:// link instead of an ssh URL ? Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (16): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Remove reset at init I2C: OMAP: I2C register restore only if context is lost I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Optimise the remove code I2C: OMAP: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: use devm_* functions I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Use SET_RUNTIME_PM_OPS I2C: OMAP: make the read ready processing a separate function I2C: OMAP: Do not set the XUDF if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 ARM: OMAP4: hwmod data: I2C: add flag for context restore Tasslehoff Kjappfot (1): I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153 Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 3 +- arch/arm/plat-omap/i2c.c | 3 + drivers/i2c/busses/i2c-omap.c | 342 +++- include/linux/i2c-omap.h | 1 + 4 files changed, 194 insertions(+), 155 deletions(-) -- 1.7.4.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] I2C updates
On Tue, Apr 10, 2012 at 05:01:37PM +0530, S, Venkatraman wrote: On Tue, Apr 10, 2012 at 4:26 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. v2 changes -Adds a patch to use devm_* functions -Also checks the return type of the get_sync and in case of errors prevents register access. - In case of i2c remove register access was done without any get_sync fix the same. - Adds a pdata function pointer to do context save restore v3 changes - Split the omap_i2c_isr to increase readability - Adds the restore flag patch for OMAP4 to the series - Make the i2c use SET_RUNTIME_PM_OPS v4 changes - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. v5 changes - Add consistency in the subject naming. v6 changes - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. [1] http://www.spinics.net/lists/linux-i2c/msg07607.html Tested on omap4sdp and omap3sdp. The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7: modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700) are available in the git repository at: g...@gitorious.org:linus-tree/linus-tree.git i2c_omap-next Minor nit: You might want to indicate a git:// link instead of an ssh URL ? indeed, for those who haven't noticed git now has separate url and pushurl for every remote. Meaning you can pull and push with different urls. This solves this issue. -- balbi signature.asc Description: Digital signature
[PATCH 0/2] OMAP2+: UART: Fix usage of default mux pads
From: Govindraj.R govindraj.r...@ti.com We populating default uart mux pins if no mux data is provided by board files. But were not probing the availability of uart pins in tx/rx mode i.e. mux mode0. If particular pin is used for any other purpose then default pads were breaking those peripherals e.g. uart2 pin was used as gpio nreset pin ehci on beagle board. So remove the default adding procedure and probe the pins before using them as uart pins. Determine if uart pins are used in uart mux_mode0 then configure rx pin for wakeup capability. Testing updates: Boot tested on 3430SDP Tested on beagle-xm with ehci module which needs uart pin muxed as gpio line for nreset sequence. RX pad wakeup after enabling off mode in cpu_idle path and suspend path tested - 3430SDP Beagle-XM Govindraj.R (2): OMAP2+: UART: Fix incorrect population of default uart pads OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup arch/arm/mach-omap2/mux.c|3 +- arch/arm/mach-omap2/mux.h| 10 +++ arch/arm/mach-omap2/serial.c | 164 +- 3 files changed, 61 insertions(+), 116 deletions(-) -- 1.7.9 -- 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] OMAP2+: UART: Fix incorrect population of default uart pads
From: Govindraj.R govindraj.r...@ti.com
The following commit:
(7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
added default pads for all uarts. But not all boards tend to
use all uarts and most of unused uart pins are muxed for
other purpose. This commit breaks the modules which where trying
to use unused uart pins on their boards.
So remove the default pads adding.
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Russ Dill russ.d...@gmail.com
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 116 --
1 files changed, 0 insertions(+), 116 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index c9503a7..1554233 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,124 +120,8 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static struct omap_device_pad default_uart1_pads[] __initdata = {
- {
- .name = uart1_cts.uart1_cts,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_rts.uart1_rts,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_tx.uart1_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_rx.uart1_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
-};
-
-static struct omap_device_pad default_uart2_pads[] __initdata = {
- {
- .name = uart2_cts.uart2_cts,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_rts.uart2_rts,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_tx.uart2_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_rx.uart2_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
-};
-
-static struct omap_device_pad default_uart3_pads[] __initdata = {
- {
- .name = uart3_cts_rctx.uart3_cts_rctx,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart3_rts_sd.uart3_rts_sd,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart3_tx_irtx.uart3_tx_irtx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart3_rx_irrx.uart3_rx_irrx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
- },
-};
-
-static struct omap_device_pad default_omap36xx_uart4_pads[] __initdata = {
- {
- .name = gpmc_wait2.uart4_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = gpmc_wait3.uart4_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE2,
- .idle = OMAP_PIN_INPUT | OMAP_MUX_MODE2,
- },
-};
-
-static struct omap_device_pad default_omap4_uart4_pads[] __initdata = {
- {
- .name = uart4_tx.uart4_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart4_rx.uart4_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
- },
-};
-
static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
{
- switch (bdata-id) {
- case 0:
- bdata-pads = default_uart1_pads;
- bdata-pads_cnt = ARRAY_SIZE(default_uart1_pads);
- break;
- case 1:
- bdata-pads = default_uart2_pads;
- bdata-pads_cnt = ARRAY_SIZE(default_uart2_pads);
- break;
- case 2:
- bdata-pads = default_uart3_pads;
- bdata-pads_cnt = ARRAY_SIZE(default_uart3_pads);
- break;
- case 3:
- if (cpu_is_omap44xx()) {
- bdata-pads = default_omap4_uart4_pads;
- bdata-pads_cnt =
- ARRAY_SIZE(default_omap4_uart4_pads);
- } else
[PATCH 2/2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
From: Govindraj.R govindraj.r...@ti.com
Default pad populating procedure should first probe whether the uart
pins are available as uart tx/rx pins if yes then we can configure them
and use rx pin for wakeup capability.
Utilise the mux api available to probe the availability of mux pins
in uart mode.
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Russ Dill russ.d...@gmail.com
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c|3 +-
arch/arm/mach-omap2/mux.h| 10 +++
arch/arm/mach-omap2/serial.c | 56 -
3 files changed, 65 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..d937ddd 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -217,8 +217,7 @@ static int __init _omap_mux_get_by_name(struct
omap_mux_partition *partition,
return -ENODEV;
}
-static int __init
-omap_mux_get_by_name(const char *muxname,
+int __init omap_mux_get_by_name(const char *muxname,
struct omap_mux_partition **found_partition,
struct omap_mux **found_mux)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 69fe060..68927f1 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,18 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int
nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux);
#else
+static inline int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 1554233..7bb971e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,11 +120,63 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+
+#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
+static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
+ tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
+static struct omap_device_pad default_omap_uart_pads[2] __initdata;
+
+static void __init omap_serial_fill_default_pads(struct omap_board_data
*bdata)
{
+ struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
+ struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
+
+ if (bdata-id != 2) {
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+uart%d_rx.uart%d_rx, bdata-id + 1, bdata-id + 1);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+uart%d_tx.uart%d_tx, bdata-id + 1, bdata-id + 1);
+ } else {
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_rx_irrx.uart%d_rx_irrx, bdata-id + 1,
+ bdata-id + 1);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_tx_irtx.uart%d_tx_irtx, bdata-id + 1,
+ bdata-id + 1);
+ }
+
+ if (omap_mux_get_by_name(rx_pad_name, rx_partition, rx_mux) = 0
+ omap_mux_get_by_name
+ (tx_pad_name, tx_partition, tx_mux) = 0) {
+ u16 tx_mode, rx_mode;
+
+ tx_mode = omap_mux_read(tx_partition, tx_mux-reg_offset);
+ rx_mode = omap_mux_read(rx_partition, rx_mux-reg_offset);
+
+ /*
+* Check if uart is used in default tx/rx mode i.e. in mux mode0
+* if yes then configure rx pin for wake up capability
+*/
+ if (!(rx_mode 0x07) !(tx_mode 0x07)) {
+ default_omap_uart_pads[0].name = rx_pad_name;
+ default_omap_uart_pads[0].flags =
+ OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP;
+ default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+ default_omap_uart_pads[0].idle = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+
+ default_omap_uart_pads[1].name = tx_pad_name;
+ default_omap_uart_pads[1].enable = OMAP_PIN_OUTPUT |
+ OMAP_MUX_MODE0;
+ bdata-pads =
Re: omap-hsmmc build broken with OF enabled in latest kernel
Hi,
On Tue, Apr 10 2012, Russell King - ARM Linux wrote:
This commit:
commit 46856a68dcb5f67c779d211fd6bcb5d7a2a7f19b
Author: Rajendra Nayak rna...@ti.com
Date: Mon Mar 12 20:32:37 2012 +0530
mmc: omap_hsmmc: Convert hsmmc driver to use device tree
Define dt bindings for the ti-omap-hsmmc, and adapt the driver to extract
data (which was earlier passed as platform_data) from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Chris Ball c...@laptop.org
breaks omap-hsmmc compilation:
drivers/mmc/host/omap_hsmmc.c:1745: error: expected ',' or ';' before 'extern'
+#ifdef CONFIG_OF
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
...
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
There should be a ';' after the }.
Thanks, and sorry for breaking the build. I've pushed a fix to mmc-next
and will send it out to Linus.
Surprisingly, this patch does not break my build with gcc-4.6.0 --
and I've just checked that line 1745 is being compiled by purposefully
introducing an(other) error to it, which *did* break my build. I wonder
what's going on there; presumably it's the reason that no-one else saw
this earlier.
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap-hsmmc build broken with OF enabled in latest kernel
On Tue, Apr 10, 2012 at 7:33 PM, Chris Ball c...@laptop.org wrote:
Hi,
On Tue, Apr 10 2012, Russell King - ARM Linux wrote:
This commit:
commit 46856a68dcb5f67c779d211fd6bcb5d7a2a7f19b
Author: Rajendra Nayak rna...@ti.com
Date: Mon Mar 12 20:32:37 2012 +0530
mmc: omap_hsmmc: Convert hsmmc driver to use device tree
Define dt bindings for the ti-omap-hsmmc, and adapt the driver to extract
data (which was earlier passed as platform_data) from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Chris Ball c...@laptop.org
breaks omap-hsmmc compilation:
drivers/mmc/host/omap_hsmmc.c:1745: error: expected ',' or ';' before
'extern'
+#ifdef CONFIG_OF
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
...
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
There should be a ';' after the }.
Thanks, and sorry for breaking the build. I've pushed a fix to mmc-next
and will send it out to Linus.
Surprisingly, this patch does not break my build with gcc-4.6.0 --
and I've just checked that line 1745 is being compiled by purposefully
introducing an(other) error to it, which *did* break my build. I wonder
what's going on there; presumably it's the reason that no-one else saw
this earlier.
Build fails iff omap_hsmmc is built as a module.
Adding ';' fixes and uncovers another build error due to unexported
variable allnodes, will send a RFC patch shortly.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[3]: *** [__modpost] Error 1
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] I2C updates
On Tuesday 10 April 2012 05:11 PM, Felipe Balbi wrote: On Tue, Apr 10, 2012 at 05:01:37PM +0530, S, Venkatraman wrote: On Tue, Apr 10, 2012 at 4:26 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: [...] modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700) are available in the git repository at: g...@gitorious.org:linus-tree/linus-tree.git i2c_omap-next Minor nit: You might want to indicate a git:// link instead of an ssh URL ? indeed, for those who haven't noticed git now has separate url and pushurl for every remote. Meaning you can pull and push with different urls. This solves this issue. Thanks, Venkat , Felipe Here is the corrected pull request The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7: modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-next Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (16): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Remove reset at init I2C: OMAP: I2C register restore only if context is lost I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Optimise the remove code I2C: OMAP: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: use devm_* functions I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Use SET_RUNTIME_PM_OPS I2C: OMAP: make the read ready processing a separate function I2C: OMAP: Do not set the XUDF if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 ARM: OMAP4: hwmod data: I2C: add flag for context restore Tasslehoff Kjappfot (1): I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153 Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +- arch/arm/plat-omap/i2c.c |3 + drivers/i2c/busses/i2c-omap.c | 342 +++- include/linux/i2c-omap.h |1 + 4 files changed, 194 insertions(+), 155 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] dt: export of_have_populated_dt
If of_have_populated_dt is called from module, build fails with allnodes
undefined error, so remove inline and export of_have_populated_dt.
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/of/base.c |6 ++
include/linux/of.h |6 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5806449..dc1af42 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -186,6 +186,12 @@ struct property *of_find_property(const struct device_node
*np,
}
EXPORT_SYMBOL(of_find_property);
+bool of_have_populated_dt(void)
+{
+ return allnodes != NULL;
+}
+EXPORT_SYMBOL(of_have_populated_dt);
+
/**
* of_find_all_nodes - Get next node in global list
* @prev: Previous node or NULL to start iteration
diff --git a/include/linux/of.h b/include/linux/of.h
index fa7fb1d..28e933e 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -92,11 +92,6 @@ extern struct device_node *of_chosen;
extern struct device_node *of_aliases;
extern rwlock_t devtree_lock;
-static inline bool of_have_populated_dt(void)
-{
- return allnodes != NULL;
-}
-
static inline bool of_node_is_root(const struct device_node *node)
{
return node (node-parent == NULL);
@@ -112,6 +107,7 @@ static inline void of_node_set_flag(struct device_node *n,
unsigned long flag)
set_bit(flag, n-_flags);
}
+extern bool of_have_populated_dt(void);
extern struct device_node *of_find_all_nodes(struct device_node *prev);
/*
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
* Govindraj.R govindraj.r...@ti.com [120410 06:44]:
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,11 +120,63 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+
+#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
+static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
+ tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
+static struct omap_device_pad default_omap_uart_pads[2] __initdata;
Won't the default_omap_uart_pads get overwritten for each port?
We need that information in the driver too for each port? Why don't you
just allocate bdata.pads in omap_serial_board_init as we now assume it's
needed for each port?
+static void __init omap_serial_fill_default_pads(struct omap_board_data
*bdata)
{
+ struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
+ struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
+
+ if (bdata-id != 2) {
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_rx.uart%d_rx, bdata-id + 1, bdata-id + 1);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_tx.uart%d_tx, bdata-id + 1, bdata-id + 1);
+ } else {
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_rx_irrx.uart%d_rx_irrx, bdata-id + 1,
+ bdata-id + 1);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_tx_irtx.uart%d_tx_irtx, bdata-id + 1,
+ bdata-id + 1);
+ }
This would be simpler with something like this (untested):
char *rx_fmt, *tx_fmt;
int uart_nr = bdata-id + 1;
if (bdata-id == 2) {
rx_fmt = uart%d_rx.uart%d_rx;
tx_fmt = uart%d_tx.uart%d_tx;
} else {
rx_fmt = uart%d_rx_irrx.uart%d_rx_irrx;
tx_fmt = uart%d_tx_irtx.uart%d_tx_irtx;
}
snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, rx_fmt,
uart_nr, uart_nr);
snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, tx_fmt,
uart_nr, uart_nr);
+ if (omap_mux_get_by_name(rx_pad_name, rx_partition, rx_mux) = 0
+ omap_mux_get_by_name
+ (tx_pad_name, tx_partition, tx_mux) = 0) {
+ u16 tx_mode, rx_mode;
+
+ tx_mode = omap_mux_read(tx_partition, tx_mux-reg_offset);
+ rx_mode = omap_mux_read(rx_partition, rx_mux-reg_offset);
+
+ /*
+ * Check if uart is used in default tx/rx mode i.e. in mux mode0
+ * if yes then configure rx pin for wake up capability
+ */
+ if (!(rx_mode 0x07) !(tx_mode 0x07)) {
+ default_omap_uart_pads[0].name = rx_pad_name;
+ default_omap_uart_pads[0].flags =
+ OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP;
+ default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+ default_omap_uart_pads[0].idle = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+
+ default_omap_uart_pads[1].name = tx_pad_name;
+ default_omap_uart_pads[1].enable = OMAP_PIN_OUTPUT |
+ OMAP_MUX_MODE0;
+ bdata-pads = default_omap_uart_pads;
+ bdata-pads_cnt = ARRAY_SIZE(default_omap_uart_pads);
+ }
+ }
}
Then looking at omap_serial_board_init, it still looks wrong:
void __init omap_serial_board_init(struct omap_uart_port_info *info)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
list_for_each_entry(uart, uart_list, node) {
bdata.id = uart-num;
bdata.flags = 0;
bdata.pads = NULL;
bdata.pads_cnt = 0;
if (cpu_is_omap44xx() || cpu_is_omap34xx())
omap_serial_fill_default_pads(bdata);
Why don't you fill the pads for omap2? It has the same pads, although
it does not have the serial wake-up events working.
And why don't you exit if omap_serial_fill_default_pads fails for the
no info case?
Shouldn't it be something like:
if (!info) {
res = omap_serial_fill_default_pads(bdata);
if (!res)
return;
port = NULL;
} else {
port = info[uart-num];
}
Re: [RFC] dt: export of_have_populated_dt
Hi Balaji,
On 4/10/2012 5:11 PM, Balaji T K wrote:
If of_have_populated_dt is called from module, build fails with allnodes
undefined error, so remove inline and export of_have_populated_dt.
Is this function really called from the MMC driver?
Regards,
Benoit
Signed-off-by: Balaji T Kbalaj...@ti.com
---
drivers/of/base.c |6 ++
include/linux/of.h |6 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5806449..dc1af42 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -186,6 +186,12 @@ struct property *of_find_property(const struct device_node
*np,
}
EXPORT_SYMBOL(of_find_property);
+bool of_have_populated_dt(void)
+{
+ return allnodes != NULL;
+}
+EXPORT_SYMBOL(of_have_populated_dt);
+
/**
* of_find_all_nodes - Get next node in global list
* @prev: Previous node or NULL to start iteration
diff --git a/include/linux/of.h b/include/linux/of.h
index fa7fb1d..28e933e 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -92,11 +92,6 @@ extern struct device_node *of_chosen;
extern struct device_node *of_aliases;
extern rwlock_t devtree_lock;
-static inline bool of_have_populated_dt(void)
-{
- return allnodes != NULL;
-}
-
static inline bool of_node_is_root(const struct device_node *node)
{
return node (node-parent == NULL);
@@ -112,6 +107,7 @@ static inline void of_node_set_flag(struct device_node *n,
unsigned long flag)
set_bit(flag,n-_flags);
}
+extern bool of_have_populated_dt(void);
extern struct device_node *of_find_all_nodes(struct device_node *prev);
/*
--
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] dt: export of_have_populated_dt
Hi,
On Tue, Apr 10 2012, Cousson, Benoit wrote:
Hi Balaji,
On 4/10/2012 5:11 PM, Balaji T K wrote:
If of_have_populated_dt is called from module, build fails with allnodes
undefined error, so remove inline and export of_have_populated_dt.
Is this function really called from the MMC driver?
~/git/linux % git grep of_have_populated_dt drivers/
drivers/gpio/gpio-samsung.c:if (!of_have_populated_dt())
drivers/mmc/host/omap_hsmmc.c: if (of_have_populated_dt() !vdd)
drivers/mmc/host/omap_hsmmc.c: (!of_have_populated_dt())) {
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] Input: omap-keypad: dynamically handle register offsets
Hi Sourav,
On Tue, Apr 03, 2012 at 10:52:26AM +0530, Sourav Poddar wrote:
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
In addition to Felipe's comments.
@@ -76,11 +81,66 @@ struct omap4_keypad {
unsigned int rows;
unsigned int cols;
+ unsigned int revision;
+ u32 irqstatus;
+ u32 irqenable;
u32 reg_offset;
and you probably won't need revision field.
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ if (keypad_data-revision == KBD_REVISION_OMAP4)
+ return __raw_readl(keypad_data-base + offset);
+ else if (keypad_data-revision == KBD_REVISION_OMAP5)
+ return __raw_readl(keypad_data-base + offset + 0x10);
+
+ return -ENODEV;
Instead do:
return __raw_readl(keypad_data-base + keypad_data-reg_offset +
offset);
+}
+
+static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32
value)
+{
+ if (keypad_data-revision == KBD_REVISION_OMAP4)
+ __raw_writel(value, keypad_data-base + offset);
+ else if (keypad_data-revision == KBD_REVISION_OMAP5)
+ __raw_writel(value, keypad_data-base + offset + 0x10);
__raw_writel(value,
keypad_data-base + keypad_data-reg_offset + offset);
+}
+
+static int kbd_read_revision(struct omap4_keypad *keypad_data, u32 offset)
+{
+ int reg;
+ reg = __raw_readl(keypad_data-base + offset);
+ reg = 0x03 30;
+ reg = 30;
+
+ switch (reg) {
+ case 1:
+ return KBD_REVISION_OMAP5;
+ case 0:
+ return KBD_REVISION_OMAP4;
+ default:
+ return -ENODEV;
-EINVAL? -EIO?
+ }
+}
+
/* Interrupt handler */
static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
{
@@ -91,12 +151,11 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
u32 *new_state = (u32 *) key_state;
/* Disable interrupts */
- __raw_writel(OMAP4_VAL_IRQDISABLE,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqenable(keypad_data, keypad_data-irqenable,
+ OMAP4_VAL_IRQDISABLE);
- *new_state = __raw_readl(keypad_data-base + OMAP4_KBD_FULLCODE31_0);
- *(new_state + 1) = __raw_readl(keypad_data-base
- + OMAP4_KBD_FULLCODE63_32);
+ *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
+ *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
for (row = 0; row keypad_data-rows; row++) {
changed = key_state[row] ^ keypad_data-key_state[row];
@@ -121,12 +180,13 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
sizeof(keypad_data-key_state));
/* clear pending interrupts */
- __raw_writel(__raw_readl(keypad_data-base + OMAP4_KBD_IRQSTATUS),
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
+ kbd_write_irqstatus(keypad_data, keypad_data-irqstatus,
+ kbd_read_irqstatus(keypad_data, keypad_data-irqstatus));
/* enable interrupts */
- __raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN | OMAP4_DEF_IRQENABLE_LONGKEY,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqenable(keypad_data, keypad_data-irqenable,
+ OMAP4_DEF_IRQENABLE_EVENTEN |
+ OMAP4_DEF_IRQENABLE_LONGKEY);
return IRQ_HANDLED;
}
@@ -139,16 +199,30 @@ static int omap4_keypad_open(struct input_dev *input)
disable_irq(keypad_data-irq);
- __raw_writel(OMAP4_VAL_FUNCTIONALCFG,
- keypad_data-base + OMAP4_KBD_CTRL);
- __raw_writel(OMAP4_VAL_DEBOUNCINGTIME,
- keypad_data-base + OMAP4_KBD_DEBOUNCINGTIME);
- __raw_writel(OMAP4_VAL_IRQDISABLE,
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
- __raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN | OMAP4_DEF_IRQENABLE_LONGKEY,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
- __raw_writel(OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA,
- keypad_data-base + OMAP4_KBD_WAKEUPENABLE);
+ keypad_data-revision = kbd_read_revision(keypad_data,
+ OMAP4_KBD_REVISION);
switch()
+ if (keypad_data-revision == KBD_REVISION_OMAP4) {
+ keypad_data-irqstatus = OMAP4_KBD_IRQSTATUS;
+ keypad_data-irqenable = OMAP4_KBD_IRQENABLE;
+ } else if (keypad_data-revision == KBD_REVISION_OMAP5) {
+ keypad_data-irqstatus = OMAP4_KBD_IRQSTATUS + 0x0c;
+ keypad_data-irqenable = OMAP4_KBD_IRQENABLE +
Re: [RFC] dt: export of_have_populated_dt
Hi Chris,
On 4/10/2012 6:21 PM, Chris Ball wrote:
Hi,
On Tue, Apr 10 2012, Cousson, Benoit wrote:
Hi Balaji,
On 4/10/2012 5:11 PM, Balaji T K wrote:
If of_have_populated_dt is called from module, build fails with allnodes
undefined error, so remove inline and export of_have_populated_dt.
Is this function really called from the MMC driver?
~/git/linux % git grep of_have_populated_dt drivers/
drivers/gpio/gpio-samsung.c:if (!of_have_populated_dt())
drivers/mmc/host/omap_hsmmc.c: if (of_have_populated_dt() !vdd)
drivers/mmc/host/omap_hsmmc.c: (!of_have_populated_dt())) {
Gosh, twice... I should be in a wrong branch :-(
Then the next question to Rob...
Rob,
Does it make sense to use that in the driver? So far I was using that
only in the arch code to make the difference between the DT boot and the
non-DT boot.
I guess that a driver should rely on of_match_device or non-NULL
device_node to figure out that?
Thanks,
Benoit
--
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 RESEND] Input: omap-keypad: dynamically handle register offsets
On Tuesday, April 10, 2012 9:24 AM, Dmitry Torokhov wrote:
On Tue, Apr 03, 2012 at 10:52:26AM +0530, Sourav Poddar wrote:
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
In addition to Felipe's comments.
@@ -76,11 +81,66 @@ struct omap4_keypad {
unsigned int rows;
unsigned int cols;
+unsigned int revision;
+u32 irqstatus;
+u32 irqenable;
u32 reg_offset;
and you probably won't need revision field.
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+if (keypad_data-revision == KBD_REVISION_OMAP4)
+return __raw_readl(keypad_data-base + offset);
keypad_data-base is an ioremap'ed address. Shouldn't all the
__raw_{read,write}l be
{read,write}l instead?
Regards,
Hartley
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Tue, Apr 10, 2012 at 9:11 AM, Tony Lindgren t...@atomide.com wrote:
* Govindraj.R govindraj.r...@ti.com [120410 06:44]:
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,11 +120,63 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+
+#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
+static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
+ tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
+static struct omap_device_pad default_omap_uart_pads[2] __initdata;
Won't the default_omap_uart_pads get overwritten for each port?
We need that information in the driver too for each port? Why don't you
just allocate bdata.pads in omap_serial_board_init as we now assume it's
needed for each port?
Because of the way the function is used, it doesn't. It does seem
somewhat fragile though, with non-obvious breakage possible in the
future if someone changes the way omap_serial_fill_default_pads is
called.
+static void __init omap_serial_fill_default_pads(struct omap_board_data
*bdata)
{
+ struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
+ struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
+
+ if (bdata-id != 2) {
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_rx.uart%d_rx, bdata-id + 1, bdata-id + 1);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_tx.uart%d_tx, bdata-id + 1, bdata-id + 1);
+ } else {
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_rx_irrx.uart%d_rx_irrx, bdata-id + 1,
+ bdata-id + 1);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_tx_irtx.uart%d_tx_irtx, bdata-id + 1,
+ bdata-id + 1);
+ }
This would be simpler with something like this (untested):
char *rx_fmt, *tx_fmt;
int uart_nr = bdata-id + 1;
if (bdata-id == 2) {
rx_fmt = uart%d_rx.uart%d_rx;
tx_fmt = uart%d_tx.uart%d_tx;
} else {
rx_fmt = uart%d_rx_irrx.uart%d_rx_irrx;
tx_fmt = uart%d_tx_irtx.uart%d_tx_irtx;
}
snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, rx_fmt,
uart_nr, uart_nr);
snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, tx_fmt,
uart_nr, uart_nr);
+ if (omap_mux_get_by_name(rx_pad_name, rx_partition, rx_mux) = 0
+ omap_mux_get_by_name
+ (tx_pad_name, tx_partition, tx_mux) = 0) {
+ u16 tx_mode, rx_mode;
+
+ tx_mode = omap_mux_read(tx_partition, tx_mux-reg_offset);
+ rx_mode = omap_mux_read(rx_partition, rx_mux-reg_offset);
+
+ /*
+ * Check if uart is used in default tx/rx mode i.e. in mux
mode0
+ * if yes then configure rx pin for wake up capability
+ */
+ if (!(rx_mode 0x07) !(tx_mode 0x07)) {
+ default_omap_uart_pads[0].name = rx_pad_name;
+ default_omap_uart_pads[0].flags =
+ OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP;
+ default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+ default_omap_uart_pads[0].idle = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+
+ default_omap_uart_pads[1].name = tx_pad_name;
+ default_omap_uart_pads[1].enable = OMAP_PIN_OUTPUT |
+ OMAP_MUX_MODE0;
+ bdata-pads = default_omap_uart_pads;
+ bdata-pads_cnt = ARRAY_SIZE(default_omap_uart_pads);
+ }
+ }
}
Then looking at omap_serial_board_init, it still looks wrong:
void __init omap_serial_board_init(struct omap_uart_port_info *info)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
list_for_each_entry(uart, uart_list, node) {
bdata.id = uart-num;
bdata.flags = 0;
bdata.pads = NULL;
bdata.pads_cnt = 0;
if (cpu_is_omap44xx() || cpu_is_omap34xx())
omap_serial_fill_default_pads(bdata);
Why don't you fill the pads for omap2? It has the same pads, although
it does not have the serial wake-up events working.
And why don't you exit if omap_serial_fill_default_pads fails for the
no info case?
Shouldn't it be something like:
if (!info) {
Re: [RFC] dt: export of_have_populated_dt
On 04/10/2012 11:29 AM, Cousson, Benoit wrote:
Hi Chris,
On 4/10/2012 6:21 PM, Chris Ball wrote:
Hi,
On Tue, Apr 10 2012, Cousson, Benoit wrote:
Hi Balaji,
On 4/10/2012 5:11 PM, Balaji T K wrote:
If of_have_populated_dt is called from module, build fails with
allnodes
undefined error, so remove inline and export of_have_populated_dt.
Is this function really called from the MMC driver?
~/git/linux % git grep of_have_populated_dt drivers/
drivers/gpio/gpio-samsung.c:if (!of_have_populated_dt())
drivers/mmc/host/omap_hsmmc.c: if (of_have_populated_dt() !vdd)
drivers/mmc/host/omap_hsmmc.c:
(!of_have_populated_dt())) {
Gosh, twice... I should be in a wrong branch :-(
Then the next question to Rob...
Rob,
Does it make sense to use that in the driver? So far I was using that
only in the arch code to make the difference between the DT boot and the
non-DT boot.
I guess that a driver should rely on of_match_device or non-NULL
device_node to figure out that?
Agreed. of_match_device or device_node ptr check is the right approach.
Rob
Thanks,
Benoit
--
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] staging: drm/omap: dmabuf/prime support
On Thu, Apr 05, 2012 at 01:15:44PM -0500, Rob Clark wrote: From: Rob Clark r...@ti.com For now just implementing the exporting APIs, not yet importing. And kmap is rejected on tiled buffers (although the usefulness of that seems questionable, but could be added later if needed). -ENOSIGNEDOFFBY :( Care to resend? -- 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] dt: export of_have_populated_dt
On 04/10/2012 05:11 PM, Balaji T K wrote: If of_have_populated_dt is called from module, build fails with allnodes undefined error, so remove inline and export of_have_populated_dt. Why do you need this function at all? You should not need it. *I* introduced it because I need it early x86 setup code to figure out if there a DT available or not. A driver should not care about it. You do have your dev.of_node and this is it. 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: [PATCH RESEND] Input: omap-keypad: dynamically handle register offsets
On Tue, Apr 10, 2012 at 11:39:43AM -0500, H Hartley Sweeten wrote:
On Tuesday, April 10, 2012 9:24 AM, Dmitry Torokhov wrote:
On Tue, Apr 03, 2012 at 10:52:26AM +0530, Sourav Poddar wrote:
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
In addition to Felipe's comments.
@@ -76,11 +81,66 @@ struct omap4_keypad {
unsigned int rows;
unsigned int cols;
+ unsigned int revision;
+ u32 irqstatus;
+ u32 irqenable;
u32 reg_offset;
and you probably won't need revision field.
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ if (keypad_data-revision == KBD_REVISION_OMAP4)
+ return __raw_readl(keypad_data-base + offset);
keypad_data-base is an ioremap'ed address. Shouldn't all the
__raw_{read,write}l be
{read,write}l instead?
Hmm, does it need endian conversion?
--
Dmitry
--
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: Suspend broken on 3.3?
Raja, Govindraj govindraj.r...@ti.com writes: Hi Kevin, On Mon, Apr 9, 2012 at 10:40 PM, Kevin Hilman khil...@ti.com wrote: Paul Walmsley p...@pwsan.com writes: [...] I don't understand why a user would ever want to disable dynamic wakeups on an in-use serial port via the sysfs power/wakeup file. (Disabling wakeups from suspend is a different matter, of course.) The OMAP UART driver needs hardware wakeups to function for FIFO drain wakeups, etc. So to me it really doesn't make sense to disable those types of wakeup events, ever. But maybe you know of some use-case that I don't? No, I don't have a use-case in mind. The more I try to remember why we added support to use the sysfs wakeup attribute to manage idle, the more I think we can probably drop it now. IIRC, it was added because on most boards we used to blindly initialize all the UARTs, including default wakeup settings (we still do this on many boards.) However, now that we have a real PM-aware driver for OMAP UARTs, this should all be handled from the driver itself, so the sysfs wakeup attribute should go back to only managing wakeups from suspend and wakeups during idle should always be on for in-use UARTs. Just to summarize on how the behavior should be IIUC if user disables uart wakeup from sysfs and does system wide suspend it should _not_ wakeup from uart. Correct. And if the system is woken up from suspend due to keypad press and uart resumes we have keep module level wakeup enabled from here. Keypad press, or any other wakeup source, yes. Basically, UART wakeups (module and IO) should be enabled all the time, *except* when suspending and wakeups were disabled by sysfs control. We might need some minor changes in omap-serial to have this behavior which I plan to do once we are aligned on this. Sure, this changes previous behavior based on assumptions that are no longer true (namely, UARTs only disabled in idle path), so I would expect some changes. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 19/19] ARM: OMAP4: hwmod data: I2C: add flag for context restore
On Tue, 10 Apr 2012, Shubhrajyoti D wrote: Restore of context is not done for OMAP4. This patch adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4 hwmod data which activates the restore for OMAP4. Currently the OMAP4 does not hit device off still the driver may have support for it. Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Wamsley p...@pwsan.com Reviewed-by: Kevin Hilman khil...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Thanks, queued for 3.5. You can drop this from your series; it will likely cause merge conflicts if you don't. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: drm/omap: dmabuf/prime support
From: Rob Clark r...@ti.com
For now just implementing the exporting APIs, not yet importing. And
kmap is rejected on tiled buffers (although the usefulness of that seems
questionable, but could be added later if needed).
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/Makefile |1 +
drivers/staging/omapdrm/omap_drv.c|4 +-
drivers/staging/omapdrm/omap_drv.h|7 ++
drivers/staging/omapdrm/omap_gem.c| 26 +-
drivers/staging/omapdrm/omap_gem_dmabuf.c | 150 +
5 files changed, 186 insertions(+), 2 deletions(-)
create mode 100644 drivers/staging/omapdrm/omap_gem_dmabuf.c
diff --git a/drivers/staging/omapdrm/Makefile b/drivers/staging/omapdrm/Makefile
index d9cdc12..1ca0e00 100644
--- a/drivers/staging/omapdrm/Makefile
+++ b/drivers/staging/omapdrm/Makefile
@@ -13,6 +13,7 @@ omapdrm-y := omap_drv.o \
omap_fb.o \
omap_fbdev.o \
omap_gem.o \
+ omap_gem_dmabuf.o \
omap_dmm_tiler.o \
tcm-sita.o
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 620b8d5..1f559f4 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -746,7 +746,7 @@ static const struct file_operations omapdriver_fops = {
static struct drm_driver omap_drm_driver = {
.driver_features =
- DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM,
+ DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM |
DRIVER_PRIME,
.load = dev_load,
.unload = dev_unload,
.open = dev_open,
@@ -766,6 +766,8 @@ static struct drm_driver omap_drm_driver = {
.debugfs_init = omap_debugfs_init,
.debugfs_cleanup = omap_debugfs_cleanup,
#endif
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .gem_prime_export = omap_gem_prime_export,
.gem_init_object = omap_gem_init_object,
.gem_free_object = omap_gem_free_object,
.gem_vm_ops = omap_gem_vm_ops,
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index 3d22df7..2b41152 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -148,9 +148,16 @@ int omap_gem_roll(struct drm_gem_object *obj, uint32_t
roll);
int omap_gem_get_paddr(struct drm_gem_object *obj,
dma_addr_t *paddr, bool remap);
int omap_gem_put_paddr(struct drm_gem_object *obj);
+int omap_gem_get_pages(struct drm_gem_object *obj, struct page ***pages,
+ bool remap);
+int omap_gem_put_pages(struct drm_gem_object *obj);
+uint32_t omap_gem_flags(struct drm_gem_object *obj);
uint64_t omap_gem_mmap_offset(struct drm_gem_object *obj);
size_t omap_gem_mmap_size(struct drm_gem_object *obj);
+struct dma_buf * omap_gem_prime_export(struct drm_device *dev,
+ struct drm_gem_object *obj, int flags);
+
static inline int align_pitch(int pitch, int width, int bpp)
{
int bytespp = (bpp + 7) / 8;
diff --git a/drivers/staging/omapdrm/omap_gem.c
b/drivers/staging/omapdrm/omap_gem.c
index 921f058..c5ba334 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -266,6 +266,12 @@ static void omap_gem_detach_pages(struct drm_gem_object
*obj)
omap_obj-pages = NULL;
}
+/* get buffer flags */
+uint32_t omap_gem_flags(struct drm_gem_object *obj)
+{
+ return to_omap_bo(obj)-flags;
+}
+
/** get mmap offset */
static uint64_t mmap_offset(struct drm_gem_object *obj)
{
@@ -764,9 +770,27 @@ static int get_pages(struct drm_gem_object *obj, struct
page ***pages)
return 0;
}
-int omap_gem_get_pages(struct drm_gem_object *obj, struct page ***pages)
+/* if !remap, and we don't have pages backing, then fail, rather than
+ * increasing the pin count (which we don't really do yet anyways,
+ * because we don't support swapping pages back out). And 'remap'
+ * might not be quite the right name, but I wanted to keep it working
+ * similarly to omap_gem_get_paddr(). Note though that mutex is not
+ * aquired if !remap (because this can be called in atomic ctxt),
+ * but probably omap_gem_get_paddr() should be changed to work in the
+ * same way. If !remap, a matching omap_gem_put_pages() call is not
+ * required (and should not be made).
+ */
+int omap_gem_get_pages(struct drm_gem_object *obj, struct page ***pages,
+ bool remap)
{
int ret;
+ if (!remap) {
+ struct omap_gem_object *omap_obj = to_omap_bo(obj);
+ if (!omap_obj-pages)
+ return -ENOMEM;
+ *pages = omap_obj-pages;
+ return 0;
+ }
mutex_lock(obj-dev-struct_mutex);
ret = get_pages(obj, pages);
mutex_unlock(obj-dev-struct_mutex);
diff --git a/drivers/staging/omapdrm/omap_gem_dmabuf.c
Re: [PATCH v3 1/9] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal,
On 04/10/2012 06:00 AM, Mohammed, Afzal wrote:
Hi Jon,
On Tue, Apr 10, 2012 at 01:20:37, Hunter, Jon wrote:
Because num_irq (or available irqs for fictitious irq chip) is platform
specific.
Ok, so OMAP_GPMC_NR_IRQS is defined and will not vary from device to
device, so why pass this? Why not use it directly?
Because OMAP_GPMC_NR_IRQS is platform specific, final intention is to
not have any platform specific header files in GPMC driver, not sure
as of now whether it would be possible. So keeping platform specific
things away from the driver as much as possible.
And consider scenario where GPMC IP is used in other than OMAP family,
even though this a theoretical case, wanted to stress the point that
intention is to keep driver platform independent.
Or else dynamic allocation of irqs may have to be used.
I agree with your argument but I was thinking today only OMAP uses the
GPMC so we could not worry about this. Ok, leave as-is, but can we
modify the code as follows as the else if is not really needed...
if (gpmc-num_irq GPMC_NR_IRQ) {
dev_warn(gpmc-dev, Insufficient interrupts for device\n);
return -EINVAL;
}
gpmc-num_irq = GPMC_NR_IRQ;
Furthermore, GPMC_NR_IRQ is defined as 6 which is correct for OMAP2/3
but not for OMAP4/5, it is 5. Therefore, we need to detect whether we
are using an OMAP2/3 or OMAP4+ and set num_irqs based upon this. This
could be done in the probe and we can avoid passing this.
Is it dependent on OMAPX or GPMC IP version? if it is IP version, then driver
can be enhanced to handle it, if not, platform has to pass this information.
Here are the GPMC IP revisions ...
OMAP5430 = 0x0060
OMAP4430 = 0x0060
OMAP3630 = 0x0050
OMAP3430 = 0x0050
So this should work for OMAP. We should check OMAP2 as well. What about
the AMxxx devices?
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (res == NULL)
+ dev_warn(gpmc-dev, Failed to get resource: irq\n);
+ else
+ gpmc-master_irq = res-start;
Why not return an error if the IRQ is not found? We don't know if anyone
will be trying to use them.
Why do you want to do that ?
Because this indicates a BUG :-)
I disagree, this need not be considered a bug always,
for eg. If gpmc irq is not connected to intc
Ok, so for devices existing today this indicates a bug ;-)
At a minimum you need to improve the error handing here. If the
platform_get_resource fails you are still calling gpmc_setup_irq()
which appears to be pointless. It would be better if the gpmc irq chip
is not initialised in this case so that drivers attempting to request
these irqs failed.
Also in gpmc_setup_irq() you have two for loops incrementing through 0
to gpmc-num_irq, can these for loops be combined?
If someone (say NAND) wants to work with irq, and if interrupt is not
available, NAND driver can fail, and suppose smsc911x ethernet is present
and he is not using gpmc irq, if we fail here, smsc911x also would
not work, which would have worked otherwise.
It is a different matter that even NAND setup will happen properly,
even if interrupt is not available, it is only when NAND is told to
work with IRQ, it fails, please see nand patches.
And as of now in mainline (with the code as is), there is not a single
board that will need gpmc irq for gpmc peripherals to work.
I feel we should try to get more devices working rather than preventing
more devices from working, when it could have.
I understand your point, but then you are hiding a BUG. If someone
introduces a BUG that causes this to fail, then it is easier to detect,
find and fix.
From my perspective get the resources should never fail and if it does
and break the driver for all devices, then so be it, because a BUG has
been introduced. Ok, this may not be critical at this point but still is
should not fail.
Agree for resources which are a must for device to work, not for resources
that can enhance its capability.
If we can ensure that a device using the gpmc driver would fail when
requesting a specific gpmc irq (if the gpmc driver has failed to
initialise its irqs) then this would be ok. In other words, a device
calling request_irq for one of the pseudo gpmc irqs returns failure if
the gpmc itself failed to setup them up.
+ for (gdq = gp-device_pdata, gd = gpmc-device; *gdq; gdq++, i++) {
+ ret = gpmc_setup_device(*gdq, gd, gpmc);
+ if (IS_ERR_VALUE(ret))
+ dev_err(gpmc-dev, gpmc setup on %s failed\n,
+ (*gdq)-name);
+ else
+ gd++;
+ }
Would a while loop be simpler?
My preference is to go with for
Ok, just wondering if this could be cleaned up a little.
For travelling through array of pointers, for looks natural to me, if you
have a better way, please send it, it can be folded in next version.
Could you
Re: [PATCH v3 4/9] ARM: OMAP2+: gpmc-nand: populate gpmc configs
Hi Afzal,
On 04/05/2012 10:46 AM, Afzal Mohammed wrote:
Currently gpmc is configured in platform for nand.
As configuring gpmc has been moved to gpmc driver,
populate details needed for the driver to configure
gpmc. gpmc driver would configure based on this
information.
Signed-off-by: Afzal Mohammedaf...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c| 97 ++--
arch/arm/plat-omap/include/plat/nand.h |8 ++-
2 files changed, 48 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 386dec8..85de31f 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -21,24 +21,38 @@
#includeplat/board.h
#includeplat/gpmc.h
-static struct resource gpmc_nand_resource = {
- .flags = IORESOURCE_MEM,
+
+#defineGPMC_NAND_CONFIG_NUM4
Where does 4 come from?
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] dt: export of_have_populated_dt
On Tue, 10 Apr 2012 12:20:27 -0500, Rob Herring robherri...@gmail.com wrote:
On 04/10/2012 11:29 AM, Cousson, Benoit wrote:
Hi Chris,
On 4/10/2012 6:21 PM, Chris Ball wrote:
Hi,
On Tue, Apr 10 2012, Cousson, Benoit wrote:
Hi Balaji,
On 4/10/2012 5:11 PM, Balaji T K wrote:
If of_have_populated_dt is called from module, build fails with
allnodes
undefined error, so remove inline and export of_have_populated_dt.
Is this function really called from the MMC driver?
~/git/linux % git grep of_have_populated_dt drivers/
drivers/gpio/gpio-samsung.c:if (!of_have_populated_dt())
drivers/mmc/host/omap_hsmmc.c: if (of_have_populated_dt() !vdd)
drivers/mmc/host/omap_hsmmc.c:
(!of_have_populated_dt())) {
Gosh, twice... I should be in a wrong branch :-(
Then the next question to Rob...
Rob,
Does it make sense to use that in the driver? So far I was using that
only in the arch code to make the difference between the DT boot and the
non-DT boot.
I guess that a driver should rely on of_match_device or non-NULL
device_node to figure out that?
Agreed. of_match_device or device_node ptr check is the right approach.
Good; I can safely ignore this patch. :-)
g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On 04/10/2012 04:51 AM, Shilimkar, Santosh wrote: On Tue, Apr 10, 2012 at 2:59 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Apr 10, 2012 at 02:27:36PM +0530, Santosh Shilimkar wrote: On Tuesday 10 April 2012 02:14 PM, Russell King - ARM Linux wrote: On Mon, Apr 09, 2012 at 03:18:22PM -0500, Jon Hunter wrote: True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. Why? What if you want to have PM enabled, and you also want to use the kernels high resolution timers, or you want more accurate timing than the 30.5us tick interval of the 32k timer? You might have missed the earlier comments on the thread. High resolution GP timer(sysclk) will stop in deeper power states and hence it can't be used with PM enabled usecases. Which means folk should be given the choice at boot time between running with the deeper power states and having a higher resolution timing source, rather than denying them the higher resolution timing source when PM is enabled. Good point. My point is such facilities is already part of the kernel and there is no need to add a new one. The last proposal was allowing user to choose gptimer as a clocksource and then you already have facility to disable C-state now so, all should work in general Actually, thinking about this some more, you do not even need to disable c-states. By using a gptimer1 and configuring it to use the SYSCLK as it source, as long as the gptimer1 is not disabled, it will prevent SYSCLK from ever turning off. Probably for good measure in this case we should also disable auto clock gating of SYSCLK via the PRM_CLKSRC_CTRL (OMAP2/3) or PRM_CLKREQCTRL (OMAP4). Sounds like a good approach. Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: omap: hwmod: Make omap_hwmod_softreset wait for reset status
Hi Rajendra,
On Tue, 13 Mar 2012, Rajendra Nayak wrote:
omap_hwmod_softreset() does not seem to wait for reset status
after doing a softreset. Make it use _ocp_softreset() instead
which does this correctly.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Shubhrajyoti D shubhrajy...@ti.com
Just noticed that this change results in I2C softreset failed messages on
OMAP2/3/4 on v3.4-rc2. For example, on 2420:
[0.200378] omap_hwmod: i2c1: softreset failed (waited 1 usec)
[0.222076] omap_hwmod: i2c2: softreset failed (waited 1 usec)
Looking more closely at the code, I think the intention of the original
code was basically correct. HDQ and I2C both need to execute some custom
reset code after the SOFTRESET bit is set, but before the RESETDONE bit is
tested. After this patch, the internal hwmod code tries to wait for
RESETDONE to change, before the custom code runs -- and that is going to
fail.
Just out of curiosity, was the change in this patch prompted by some code
that needed the change? Or was this a theoretical problem, driven by a
code review? If the latter, we should probably revert this patch, and
maybe improve the documentation and omap_hwmod_softreset() function name
to clarify what it actually does. But if it's the former, it looks like
we'll need a way to support both the full, standard SOFTRESET sequence
(perhaps via omap_hwmod_reset() ?) while also supporting the HDQ/I2C
custom reset code.
regards,
- Paul
---
arch/arm/mach-omap2/omap_hwmod.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 6c0e7eb..0c64853 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2423,20 +2423,10 @@ void omap_hwmod_write(u32 v, struct omap_hwmod *oh,
u16 reg_offs)
*/
int omap_hwmod_softreset(struct omap_hwmod *oh)
{
- u32 v;
- int ret;
-
- if (!oh || !(oh-_sysc_cache))
+ if (!oh)
return -EINVAL;
- v = oh-_sysc_cache;
- ret = _set_softreset(oh, v);
- if (ret)
- goto error;
- _write_sysconfig(v, oh);
-
-error:
- return ret;
+ return _ocp_softreset(oh);
}
/**
--
1.7.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
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
Hi,
On Wed, Dec 14, 2011 at 5:55 AM, Rajendra Nayak rna...@ti.com wrote:
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.
...
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 63b5416..a508ed5 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);
- omap_serial_init();
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
--
1.7.1
I'm fairly new to DT and I'm trying to boot it with pandaboard and
k3.3, however above hunk deletes omap serial initialization, which
causes a panic on boot, because pdata is NULL:
static void serial_omap_start_tx(struct uart_port *port)
{
...
if (pdata-set_noidle)
Perhaps because this change skips the following path:
omap_serial_init-omap_serial_board_init-omap_serial_init_port
Where pdata is built in omap_device_build.
I'm just trying to confirm that I'm not alone or doing some silly
thing before getting in depth with the code.
Here it is the panic:
[2.024688] Unable to handle kernel NULL pointer dereference at
virtual address 0028
[2.031005] pgd = ed6f
[2.036315] [0028] *pgd=af339831, *pte=, *ppte=
[2.042907] Internal error: Oops: 17 [#1] SMP
[2.046630] Modules linked in:
[2.046630] CPU: 0Not tainted (3.3.0-2-gda19af1-dirty #11)
[2.046630] PC is at serial_omap_start_tx+0x1cc/0x218
[2.046630] LR is at serial_omap_start_tx+0x1b8/0x218
[2.067840] pc : [c02b3a54]lr : [c02b3a40]psr: 6193
[2.067840] sp : c21cbe70 ip : 0001 fp : a113
[2.073699] r10: ef107000 r9 : ed684600 r8 : 001c
[2.085327] r7 : 0002 r6 : 0007 r5 : r4 : ed684600
[2.086029] r3 : ef1281c0 r2 : fa02 r1 : 0004 r0 : c02b3a40
[2.086029] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment user
[2.101684] Control: 10c53c7d Table: ad6f004a DAC: 0015
[2.101684] Process S10udev (pid: 497, stack limit = 0xc21ca2f8)
[2.116973] Stack: (0xc21cbe70 to 0xc21cc000)
[2.123443] be60: a113
c0475b74 0002
[2.126007] be80: c02ac7e0 ef107000 ed684600 2113
c02ac830 ed690ad0
[2.139099] bea0: ed6e981c c02ae348 c02ae288 ef107000 c21ca000
001c ed6e9800 ef1074fc
[2.145385] bec0: c049cab4 ef1dcd80 ed6e9800 c0296aa8 6113
c02925e8 ef107194 ef107120
[2.152191] bee0: ef0003c0 ef1281c0 c0076214 ef1071b4
ef1071b4 ef1074b4 ef1dcd80
[2.159790] bf00: ef107000 b6f5c000 001c c21ca000 0400
c02968c8 c0292638
[2.159790] bf20: c06e3ea0 001c c02968c8 ef168b80 c21cbf80
ef1281c0 ef1dcd80
[2.175811] bf40: 001c b6f5c000 c21cbf80
c010841c
[2.188476] bf60: c0014400 ef1281c0 ef1dcd80 b6f5c000 001c
0004 c0108570
[2.195068] bf80: 001c 001c
b6f345c8 001c c00144a8
[2.195068] bfa0: c21ca000 c00142e0 001c b6f345c8 0001
b6f5c000 001c
[2.210723] bfc0: 001c b6f345c8 001c 0004 b6f5c000
0001
[2.210723] bfe0: be988948 b6e5ae98 b6eb7adc 6110
0001 89389af9 fef855e7
[2.226379] [c02b3a54] (serial_omap_start_tx+0x1cc/0x218) from
[c02ac830] (uart_start+0x68/0x6c)
[2.241973] [c02ac830] (uart_start+0x68/0x6c) from [c02ae348]
(uart_write+0xc0/0xe4)
[2.241973] [c02ae348] (uart_write+0xc0/0xe4) from [c0296aa8]
(n_tty_write+0x1e0/0x42c)
[2.257629] [c0296aa8] (n_tty_write+0x1e0/0x42c) from
[c0292638] (tty_write+0x140/0x23c)
[2.270446] [c0292638] (tty_write+0x140/0x23c) from [c010841c]
(vfs_write+0xb0/0x134)
[2.278594] [c010841c] (vfs_write+0xb0/0x134) from [c0108570]
(sys_write+0x40/0x70)
[2.281311] [c0108570] (sys_write+0x40/0x70) from [c00142e0]
(ret_fast_syscall+0x0/0x3c)
Regards,
Omar
--
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: PM related performance degradation on OMAP3
On Mon, Apr 9, 2012 at 10:03 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
While SD card performance loss is not that bad (~7%), NAND one is
worrying (~39%). I've tried disabling/enabling CONFIG_CPU_IDLE, also
cpuidle states over sysfs, it did not have any significant effect. Is
there something else to try?
Looks like we might need a PM QoS constraint when there is DMA activity
in progress.
You can try doing a pm_qos_add_request() for PM_QOS_CPU_DMA_LATENCY when
DMA transfers are active and I suspect that will help.
I've tried it and it didn't help much. It looks like the only thing it
does is limiting cpuidle c-states, I tried to set qos dma latency to 0
and it made it stay in C1 while transfer was ongoing (I watched
/sys/devices/system/cpu/cpu0/cpuidle/state*/usage), but performance
was still poor.
What I think is going on here is that omap_sram_idle() is taking too
much time because it's overhead is too large. I've added a counter
there and it seems to be called ~530 times per megabyte (DMA operates
in ~2K chunks so it makes sense), that's over 2000 calls per second.
Some quick measurement code shows ~243us spent for setting up in
omap_sram_idle() (before and after omap34xx_do_sram_idle()).
Could we perhaps have a lighter idle function for C1 that doesn't try
to switch all powerdomain states and maybe not enable RAM
self-refresh? As a quick test I've tried this in omap3_enter_idle():
/* Execute ARM wfi */
if (index == 0) {
clkdm_deny_idle(mpu_pd-pwrdm_clkdms[0]);
cpu_do_idle();
} else
omap_sram_idle();
..and it brought performance close to !CONFIG_PM case (cpu_do_idle()
is used as pm_idle on !CONFIG_PM). I don't know what side effects
something like this might have though.
Then there is omap3_do_wfi, it seems to be unconditionally putting
SDRC on self-refresh, would it make sense to just do wfi in higher
power states, like OMAP4 seems to be doing?
Not sure what you're referring to in OMAP4. There we do WFI in every
idle state.
What I meant is that OMAP3 idle code always tries to enable RAM
self-refresh (regardless of c-state) before doing wfi while OMAP4 can
do wfi without suspending RAM (although I might be misunderstanding
all that asm code).
--
Gražvydas
--
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 v4 00/12] ARM: OMAP: resolve some warnings
This is the latest version of the OMAP warnings cleanup series. This version fixes most of the warnings with arch/arm/mach-omap1, arch/arm/mach-omap2, and arch/arm/plat-omap. It also fixes some bugs discovered in the process. Boot-tested on 5912OSK, N800, 35xx BeagleBoard, 37xx EVM, and 4430 Pandaboard. Build-tested on the configs listed below, which are available from git://git.pwsan.com/omap_kconfigs. This series is also available from git://git.pwsan.com/linux-2.6 in the branch 'sparse_cppcheck_cleanup_3.5'. Felipe, one of the patches in this branch touches drivers/usb/host/ohci-omap.c - could you ack it for me if you are okay with the change? - Paul --- object size (delta in bytes from v3.4-rc2): textdata bss total kernel -84 +24 0 -60 5912osk_testconfig/vmlinux -100 -8 0-108 n800_multi_omap2xxx/vmlinux -68 -8 0 -76 n800_testconfig/vmlinux -224 +56 -32-200 omap1_defconfig/vmlinux -148 +32 0-116 omap2_4_testconfig/vmlinux -212 0 0-212 omap2plus_defconfig/vmlinux -148 0 0-148 omap2plus_no_pm/vmlinux -152 0 0-152 omap3_4_testconfig/vmlinux -100 -8 0-108 omap3_testconfig/vmlinux -188 -24 -64-276 omap4_testconfig/vmlinux Paul Walmsley (12): ARM: OMAP2+: declare file-local functions as static ARM: OMAP: add includes for missing prototypes ARM: OMAP1: OCPI: move to mach-omap1/ ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse ARM: OMAP: fix 'using plain integer as NULL pointer' sparse warnings ARM: OMAP: OCM RAM: use memset_io() when clearing SRAM ARM: OMAP: DMA: use constant array maximum, drop some LCD DMA code ARM: OMAP: USB: remove unnecessary sideways include ARM: OMAP1: board files: deduplicate and clean some NAND-related code ARM: OMAP1: DMTIMER: fix broken timer clock source selection ARM: OMAP2+: clean up some cppcheck warnings arch/arm/mach-omap1/Makefile | 13 ++--- arch/arm/mach-omap1/ams-delta-fiq.c |2 + arch/arm/mach-omap1/board-fsample.c | 16 +-- arch/arm/mach-omap1/board-h2.c | 17 +-- arch/arm/mach-omap1/board-h3.c | 16 +-- arch/arm/mach-omap1/board-nand.c | 39 ++ arch/arm/mach-omap1/board-palmz71.c |4 +-- arch/arm/mach-omap1/board-perseus2.c | 16 +-- arch/arm/mach-omap1/clock.c |3 +- arch/arm/mach-omap1/common.h | 11 +++ arch/arm/mach-omap1/fpga.c |2 + arch/arm/mach-omap1/id.c |2 + arch/arm/mach-omap1/io.c |3 +- arch/arm/mach-omap1/irq.c|2 + arch/arm/mach-omap1/lcd_dma.c|7 + arch/arm/mach-omap1/ocpi.c |7 +++-- arch/arm/mach-omap1/pm.c |9 +++--- arch/arm/mach-omap1/reset.c |2 + arch/arm/mach-omap1/timer.c |7 ++--- arch/arm/mach-omap1/usb.c|3 ++ arch/arm/mach-omap2/am35xx-emac.c| 37 +++-- arch/arm/mach-omap2/board-omap3evm.c |8 +++-- arch/arm/mach-omap2/board-omap4panda.c |8 +++-- arch/arm/mach-omap2/board-rx51-peripherals.c |4 +-- arch/arm/mach-omap2/board-zoom-display.c |1 + arch/arm/mach-omap2/common.h |2 - arch/arm/mach-omap2/devices.c|7 ++--- arch/arm/mach-omap2/gpio.c |2 + arch/arm/mach-omap2/gpmc-onenand.c |3 +- arch/arm/mach-omap2/gpmc.c |3 +- arch/arm/mach-omap2/hwspinlock.c |2 + arch/arm/mach-omap2/io.c |1 + arch/arm/mach-omap2/irq.c|3 +- arch/arm/mach-omap2/mux.c|2 + arch/arm/mach-omap2/omap-secure.c|1 + arch/arm/mach-omap2/omap-wakeupgen.c |2 + arch/arm/mach-omap2/pm24xx.c |3 -- arch/arm/mach-omap2/pm34xx.c | 10 ++- arch/arm/mach-omap2/prm_common.c |4 ++- arch/arm/mach-omap2/serial.c |2 + arch/arm/mach-omap2/usb-tusb6010.c |2 + arch/arm/plat-omap/Makefile |3 -- arch/arm/plat-omap/common.c |1 + arch/arm/plat-omap/dma.c | 13 +++-- arch/arm/plat-omap/dmtimer.c |3 +- arch/arm/plat-omap/include/plat/board.h |2 + arch/arm/plat-omap/include/plat/common.h |2 + arch/arm/plat-omap/include/plat/dma.h|1 + arch/arm/plat-omap/include/plat/dmtimer.h|4 +--
[PATCH v4 01/12] ARM: OMAP2+: declare file-local functions as static
Several function declarations used only in the files in which they're
declared should include the static keyboard, but don't:
arch/arm/mach-omap2/serial.c:248:6: warning: symbol 'cmdline_find_option'
was not declared. Should it be static?
arch/arm/mach-omap2/omap-wakeupgen.c:259:6: warning: symbol 'irq_sar_clear'
was not declared. Should it be static?
arch/arm/mach-omap2/board-rx51-peripherals.c:878:27: warning: symbol
'rx51_vibra_data' was not declared. Should it be static?
arch/arm/mach-omap2/board-rx51-peripherals.c:882:27: warning: symbol
'rx51_audio_data' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:201:29: warning: symbol
'omap_panda_wlan_data' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:393:24: warning: symbol
'omap4_panda_dvi_device' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:403:12: warning: symbol
'omap4_panda_dvi_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:464:6: warning: symbol
'omap4_panda_display_init' was not declared. Should it be static?
arch/arm/mach-omap2/hsmmc.c:434:6: warning: symbol 'omap_init_hsmmc' was
not declared. Should it be static?
arch/arm/mach-omap2/hwspinlock.c:31:12: warning: symbol 'hwspinlocks_init'
was not declared. Should it be static?
arch/arm/mach-omap1/timer.c:58:12: warning: symbol 'omap1_dm_timer_init'
was not declared. Should it be static?
arch/arm/mach-omap1/fpga.c:90:6: warning: symbol 'innovator_fpga_IRQ_demux'
was not declared. Should it be static?
Mark all of these as static.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Govindraj R govindraj.r...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: David Anders x0132...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/fpga.c |2 +-
arch/arm/mach-omap1/timer.c |3 +--
arch/arm/mach-omap2/board-omap4panda.c |8
arch/arm/mach-omap2/board-rx51-peripherals.c |4 ++--
arch/arm/mach-omap2/hwspinlock.c |2 +-
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/serial.c |2 +-
7 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap1/fpga.c b/arch/arm/mach-omap1/fpga.c
index 76c67b3..29ec50f 100644
--- a/arch/arm/mach-omap1/fpga.c
+++ b/arch/arm/mach-omap1/fpga.c
@@ -87,7 +87,7 @@ static void fpga_mask_ack_irq(struct irq_data *d)
fpga_ack_irq(d);
}
-void innovator_fpga_IRQ_demux(unsigned int irq, struct irq_desc *desc)
+static void innovator_fpga_IRQ_demux(unsigned int irq, struct irq_desc *desc)
{
u32 stat;
int fpga_irq;
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 6e90665..5536e04 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -54,8 +54,7 @@ static int omap1_dm_timer_set_src(struct platform_device
*pdev,
return 0;
}
-
-int __init omap1_dm_timer_init(void)
+static int __init omap1_dm_timer_init(void)
{
int i;
int ret;
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d8c0e89..f864065 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -230,7 +230,7 @@ static struct platform_device omap_vwlan_device = {
},
};
-struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
+static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
/* PANDA ref clock is 38.4 MHz */
.board_ref_clock = 2,
};
@@ -439,7 +439,7 @@ static struct panel_dvi_platform_data omap4_dvi_panel = {
.i2c_bus_num = 3,
};
-struct omap_dss_device omap4_panda_dvi_device = {
+static struct omap_dss_device omap4_panda_dvi_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = dvi,
.driver_name= dvi,
@@ -449,7 +449,7 @@ struct omap_dss_device omap4_panda_dvi_device = {
.channel= OMAP_DSS_CHANNEL_LCD2,
};
-int __init omap4_panda_dvi_init(void)
+static int __init omap4_panda_dvi_init(void)
{
int r;
@@ -510,7 +510,7 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
.default_device = omap4_panda_dvi_device,
};
-void __init omap4_panda_display_init(void)
+static void __init omap4_panda_display_init(void)
{
int r;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index d87ee06..ae957c9 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -872,11 +872,11 @@ static struct twl4030_power_data rx51_t2scripts_data
__initdata = {
.resource_config = twl4030_rconfig,
};
-struct twl4030_vibra_data rx51_vibra_data __initdata = {
+static struct
[PATCH v4 09/12] ARM: OMAP: USB: remove unnecessary sideways include
Remove the include of mach-omap2/common.h from plat-omap/usb.c. It appears to be unneeded. Removing it also resolves the sparse warning: arch/arm/plat-omap/../mach-omap2/common.h:183:12: warning: symbol 'omap_intc_of_init' was not declared. Should it be static? Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/plat-omap/usb.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/plat-omap/usb.c b/arch/arm/plat-omap/usb.c index d2bbfd1..ab62388 100644 --- a/arch/arm/plat-omap/usb.c +++ b/arch/arm/plat-omap/usb.c @@ -31,8 +31,6 @@ #include mach/hardware.h -#include ../mach-omap2/common.h - #ifdef CONFIG_ARCH_OMAP_OTG void __init -- 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 v4 07/12] ARM: OMAP: OCM RAM: use memset_io() when clearing SRAM
We currently treat the OCM RAM memory as memory that hangs off an I/O bus, so use memset_io() to clear it rather than memset(). This also takes care of this sparse warning: arch/arm/plat-omap/sram.c:199:9: warning: cast removes address space of expression There is still one SRAM-related sparse warning, but it appears that fixing it correctly will take some time and thought. N.B., at some point, the OCM RAM IP block interface code should probably be reimplemented as an MTD device or something similar under drivers/. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/plat-omap/sram.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index eec98af..6beb79c 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -196,8 +196,8 @@ static void __init omap_map_sram(void) * Looks like we need to preserve some bootloader code at the * beginning of SRAM for jumping to flash for reboot to work... */ - memset((void *)omap_sram_base + SRAM_BOOTLOADER_SZ, 0, - omap_sram_size - SRAM_BOOTLOADER_SZ); + memset_io(omap_sram_base + SRAM_BOOTLOADER_SZ, 0, + omap_sram_size - SRAM_BOOTLOADER_SZ); } /* -- 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 v4 11/12] ARM: OMAP1: DMTIMER: fix broken timer clock source selection
DMTIMER source selection on OMAP1 is broken. omap1_dm_timer_set_src()
tries to use __raw_{read,write}l() to read from and write to physical
addresses, but those functions take virtual addresses.
sparse caught this:
arch/arm/mach-omap1/timer.c:50:13: warning: incorrect type in argument 1
(different base types)
arch/arm/mach-omap1/timer.c:50:13:expected void const volatile [noderef]
asn:2*noident
arch/arm/mach-omap1/timer.c:50:13:got unsigned int
arch/arm/mach-omap1/timer.c:52:9: warning: incorrect type in argument 1
(different base types)
arch/arm/mach-omap1/timer.c:52:9:expected void const volatile [noderef]
asn:2*noident
arch/arm/mach-omap1/timer.c:52:9:got unsigned int
Fix by using omap_{read,writel}(), just like the other users of the
MOD_CONF_CTRL_1 register in the OMAP1 codebase. Of course, in the long term,
removing omap_{read,write}l() is the appropriate thing to do; but
this will take some work to do this cleanly.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap1/timer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 5536e04..64c65bc 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -47,9 +47,9 @@ static int omap1_dm_timer_set_src(struct platform_device
*pdev,
int n = (pdev-id - 1) 1;
u32 l;
- l = __raw_readl(MOD_CONF_CTRL_1) ~(0x03 n);
+ l = omap_readl(MOD_CONF_CTRL_1) ~(0x03 n);
l |= source n;
- __raw_writel(l, MOD_CONF_CTRL_1);
+ omap_writel(l, MOD_CONF_CTRL_1);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/12] ARM: OMAP: DMA: use constant array maximum, drop some LCD DMA code
gcc can apparently handle stack-allocated arrays that use a dynamic
variable as the array maximum. Rather than using a mutable quantity,
simply use a constant maximum possible size. To me, code clarity is
improved; and it also avoids the following sparse warnings:
arch/arm/plat-omap/dma.c:886:40: error: bad constant expression
arch/arm/plat-omap/dma.c:892:17: error: cannot size expression
arch/arm/plat-omap/dma.c:970:40: error: bad constant expression
arch/arm/plat-omap/dma.c:972:17: error: cannot size expression
Also drop some dead code from the OMAP1 LCD DMA code:
arch/arm/mach-omap1/lcd_dma.c:80:6: warning: symbol 'omap_set_lcd_dma_src_port'
was not declared. Should it be static?
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap1/lcd_dma.c |5 -
arch/arm/plat-omap/dma.c | 13 +++--
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap1/lcd_dma.c b/arch/arm/mach-omap1/lcd_dma.c
index 86ace9a..9237576 100644
--- a/arch/arm/mach-omap1/lcd_dma.c
+++ b/arch/arm/mach-omap1/lcd_dma.c
@@ -77,11 +77,6 @@ void omap_set_lcd_dma_b1(unsigned long addr, u16 fb_xres,
u16 fb_yres,
}
EXPORT_SYMBOL(omap_set_lcd_dma_b1);
-void omap_set_lcd_dma_src_port(int port)
-{
- lcd_dma.src_port = port;
-}
-
void omap_set_lcd_dma_ext_controller(int external)
{
lcd_dma.ext_ctrl = external;
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index ecdb3da..612227e 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -41,6 +41,15 @@
#include plat/tc.h
+/*
+ * MAX_LOGICAL_DMA_CH_COUNT: the maximum number of logical DMA
+ * channels that an instance of the SDMA IP block can support. Used
+ * to size arrays. (The actual maximum on a particular SoC may be less
+ * than this -- for example, OMAP1 SDMA instances only support 17 logical
+ * DMA channels.)
+ */
+#define MAX_LOGICAL_DMA_CH_COUNT 32
+
#undef DEBUG
#ifndef CONFIG_ARCH_OMAP1
@@ -883,7 +892,7 @@ void omap_start_dma(int lch)
if (!omap_dma_in_1510_mode() dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch;
- char dma_chan_link_map[dma_lch_count];
+ char dma_chan_link_map[MAX_LOGICAL_DMA_CH_COUNT];
dma_chan_link_map[lch] = 1;
/* Set the link register of the first channel */
@@ -967,7 +976,7 @@ void omap_stop_dma(int lch)
if (!omap_dma_in_1510_mode() dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch = lch;
- char dma_chan_link_map[dma_lch_count];
+ char dma_chan_link_map[MAX_LOGICAL_DMA_CH_COUNT];
memset(dma_chan_link_map, 0, sizeof(dma_chan_link_map));
do {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 03/12] ARM: OMAP1: OCPI: move to mach-omap1/
Move the OMAP1 OCPI bus code to arch/arm/mach-omap1, since it is
only used on OMAP1 devices. In the long term, it probably makes sense
to move the OCPI bus code to somewhere under drivers/.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/Makefile |3 +++
arch/arm/mach-omap1/common.h |2 ++
arch/arm/mach-omap1/ocpi.c |7 +--
arch/arm/plat-omap/Makefile |3 ---
4 files changed, 10 insertions(+), 5 deletions(-)
rename arch/arm/{plat-omap/ocpi.c = mach-omap1/ocpi.c} (93%)
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 9923f92..20d65af 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -12,6 +12,9 @@ endif
obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o
+# OCPI interconnect support for 1710, 1610 and 5912
+obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
+
# Power Management
obj-$(CONFIG_PM) += pm.o sleep.o
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index ef656ff..a90b9d7 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -63,4 +63,6 @@ extern bool omap_32k_timer_init(void);
extern u32 omap_irq_flags;
+extern int ocpi_enable(void);
+
#endif /* __ARCH_ARM_MACH_OMAP1_COMMON_H */
diff --git a/arch/arm/plat-omap/ocpi.c b/arch/arm/mach-omap1/ocpi.c
similarity index 93%
rename from arch/arm/plat-omap/ocpi.c
rename to arch/arm/mach-omap1/ocpi.c
index ebe0c73..238170c 100644
--- a/arch/arm/plat-omap/ocpi.c
+++ b/arch/arm/mach-omap1/ocpi.c
@@ -4,6 +4,7 @@
* Minimal OCP bus support for omap16xx
*
* Copyright (C) 2003 - 2005 Nokia Corporation
+ * Copyright (C) 2012 Texas Instruments, Inc.
* Written by Tony Lindgren t...@atomide.com
*
* Modified for clock framework by Paul Mundt paul.mu...@nokia.com.
@@ -35,6 +36,8 @@
#include mach/hardware.h
+#include common.h
+
#define OCPI_BASE 0xfffec320
#define OCPI_FAULT (OCPI_BASE + 0x00)
#define OCPI_CMD_FAULT (OCPI_BASE + 0x04)
@@ -64,7 +67,7 @@ int ocpi_enable(void)
/* Enable access for OHCI in OCPI */
val = omap_readl(OCPI_PROT);
val = ~0xff;
- //val = (1 0); /* Allow access only to EMIFS */
+ /* val = (1 0); Allow access only to EMIFS */
omap_writel(val, OCPI_PROT);
val = omap_readl(OCPI_SEC);
@@ -86,7 +89,7 @@ static int __init omap_ocpi_init(void)
clk_enable(ocpi_ck);
ocpi_enable();
- printk(OMAP OCPI interconnect driver loaded\n);
+ pr_info(OMAP OCPI interconnect driver loaded\n);
return 0;
}
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index c0fe275..ed8605f 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -9,9 +9,6 @@ obj-m :=
obj-n :=
obj- :=
-# OCPI interconnect support for 1710, 1610 and 5912
-obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
-
# omap_device support (OMAP2+ only at the moment)
obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
--
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 v4 10/12] ARM: OMAP1: board files: deduplicate and clean some NAND-related code
The H2, H3, Perseus2, and FSample board files all contain the same
duplicated code to handle NAND commands. That code is missing
some casts around conversions from unsigned long to void __iomem *.
Consolidate the duplicated code into a new file,
arch/arm/mach-omap1/board-nand.c. Resolve the sparse warnings by
adding appropriate casts:
arch/arm/mach-omap1/board-h2.c:193:9: warning: incorrect type in argument 1
(different base types)
arch/arm/mach-omap1/board-h2.c:193:9:expected void const volatile [noderef]
asn:2*noident
arch/arm/mach-omap1/board-h2.c:193:9:got unsigned long
arch/arm/mach-omap1/board-perseus2.c:157:9: warning: incorrect type in argument
1 (different base types)
arch/arm/mach-omap1/board-perseus2.c:157:9:expected void const volatile
[noderef] asn:2*noident
arch/arm/mach-omap1/board-perseus2.c:157:9:got unsigned long
arch/arm/mach-omap1/board-fsample.c:199:9: warning: incorrect type in argument
1 (different base types)
arch/arm/mach-omap1/board-fsample.c:199:9:expected void const volatile
[noderef] asn:2*noident
arch/arm/mach-omap1/board-fsample.c:199:9:got unsigned long
arch/arm/mach-omap1/board-h3.c:195:9: warning: incorrect type in argument 1
(different base types)
arch/arm/mach-omap1/board-h3.c:195:9:expected void const volatile [noderef]
asn:2*noident
arch/arm/mach-omap1/board-h3.c:195:9:got unsigned long
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Brian Swetland swetl...@google.com
Cc: Imre Deak imre.d...@nokia.com
Cc: Greg Lonnon glon...@ridgerun.com
Cc: Kevin Hilman k...@hilman.org
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap1/Makefile | 10 +
arch/arm/mach-omap1/board-fsample.c | 16 +-
arch/arm/mach-omap1/board-h2.c | 17 +--
arch/arm/mach-omap1/board-h3.c | 16 +-
arch/arm/mach-omap1/board-nand.c | 39 ++
arch/arm/mach-omap1/board-perseus2.c | 16 +-
arch/arm/mach-omap1/common.h |4 +++
7 files changed, 53 insertions(+), 65 deletions(-)
create mode 100644 arch/arm/mach-omap1/board-nand.c
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 20d65af..398e9e5 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -31,13 +31,15 @@ usb-fs-$(CONFIG_USB):= usb.o
obj-y += $(usb-fs-m) $(usb-fs-y)
# Specific board support
-obj-$(CONFIG_MACH_OMAP_H2) += board-h2.o board-h2-mmc.o
+obj-$(CONFIG_MACH_OMAP_H2) += board-h2.o board-h2-mmc.o \
+ board-nand.o
obj-$(CONFIG_MACH_OMAP_INNOVATOR) += board-innovator.o
obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
-obj-$(CONFIG_MACH_OMAP_PERSEUS2) += board-perseus2.o
-obj-$(CONFIG_MACH_OMAP_FSAMPLE)+= board-fsample.o
+obj-$(CONFIG_MACH_OMAP_PERSEUS2) += board-perseus2.o board-nand.o
+obj-$(CONFIG_MACH_OMAP_FSAMPLE)+= board-fsample.o board-nand.o
obj-$(CONFIG_MACH_OMAP_OSK)+= board-osk.o
-obj-$(CONFIG_MACH_OMAP_H3) += board-h3.o board-h3-mmc.o
+obj-$(CONFIG_MACH_OMAP_H3) += board-h3.o board-h3-mmc.o \
+ board-nand.o
obj-$(CONFIG_MACH_VOICEBLUE) += board-voiceblue.o
obj-$(CONFIG_MACH_OMAP_PALMTE) += board-palmte.o
obj-$(CONFIG_MACH_OMAP_PALMZ71)+= board-palmz71.o
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 80bd43c..4a4afb3 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -185,20 +185,6 @@ static struct platform_device nor_device = {
.resource = nor_resource,
};
-static void nand_cmd_ctl(struct mtd_info *mtd, int cmd,unsigned int
ctrl)
-{
- struct nand_chip *this = mtd-priv;
- unsigned long mask;
-
- if (cmd == NAND_CMD_NONE)
- return;
-
- mask = (ctrl NAND_CLE) ? 0x02 : 0;
- if (ctrl NAND_ALE)
- mask |= 0x04;
- writeb(cmd, (unsigned long)this-IO_ADDR_W | mask);
-}
-
#define FSAMPLE_NAND_RB_GPIO_PIN 62
static int nand_dev_ready(struct mtd_info *mtd)
@@ -216,7 +202,7 @@ static struct platform_nand_data nand_data = {
.part_probe_types = part_probes,
},
.ctrl = {
- .cmd_ctrl = nand_cmd_ctl,
+ .cmd_ctrl = omap1_nand_cmd_ctl,
.dev_ready = nand_dev_ready,
},
};
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 553a2e5..057ec13 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -179,20 +179,6 @@ static struct mtd_partition h2_nand_partitions[] = {
},
};
-static void h2_nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
-{
-
[PATCH v4 02/12] ARM: OMAP: add includes for missing prototypes
Several C files in arch/arm/mach-omap* and arch/arm/plat-omap declare functions that are used by other files, but don't include the header file where the prototype is declared. This results in the following warnings from sparse: arch/arm/mach-omap2/irq.c:114:5: warning: symbol 'omap_irq_pending' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:186:13: warning: symbol 'omap2_init_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:191:13: warning: symbol 'omap3_init_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:196:13: warning: symbol 'ti81xx_init_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:233:39: warning: symbol 'omap2_intc_handle_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:242:6: warning: symbol 'omap_intc_save_context' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'omap_intc_restore_context' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:291:6: warning: symbol 'omap3_intc_suspend' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:297:6: warning: symbol 'omap3_intc_prepare_idle' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:306:6: warning: symbol 'omap3_intc_resume_idle' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:312:39: warning: symbol 'omap3_intc_handle_irq' was not declared. Should it be static? arch/arm/mach-omap2/omap-secure.c:59:12: warning: symbol 'omap_secure_ram_reserve_memblock' was not declared. Should it be static? arch/arm/mach-omap2/board-zoom-display.c:133:13: warning: symbol 'zoom_display_init' was not declared. Should it be static? arch/arm/plat-omap/common.c:73:13: warning: symbol 'omap_init_consistent_dma_size' was not declared. Should it be static? arch/arm/mach-omap1/irq.c:61:5: warning: symbol 'omap_irq_flags' was not declared. Should it be static? arch/arm/mach-omap1/irq.c:179:13: warning: symbol 'omap1_init_irq' was not declared. Should it be static? arch/arm/mach-omap1/reset.c:11:6: warning: symbol 'omap1_restart' was not declared. Should it be static? Fix by including the appropriate header files. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Senthilvadivu Guruswamy svad...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap1/common.h |5 - arch/arm/mach-omap1/id.c |2 ++ arch/arm/mach-omap1/io.c |3 +-- arch/arm/mach-omap1/irq.c|2 ++ arch/arm/mach-omap1/reset.c |2 ++ arch/arm/mach-omap2/board-zoom-display.c |1 + arch/arm/mach-omap2/common.h |2 -- arch/arm/mach-omap2/io.c |1 + arch/arm/mach-omap2/irq.c|1 + arch/arm/mach-omap2/omap-secure.c|1 + arch/arm/plat-omap/common.c |1 + arch/arm/plat-omap/include/plat/common.h |2 ++ arch/arm/plat-omap/include/plat/dma.h|1 + 13 files changed, 19 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h index af658ad..ef656ff 100644 --- a/arch/arm/mach-omap1/common.h +++ b/arch/arm/mach-omap1/common.h @@ -56,8 +56,11 @@ void omap1_init_early(void); void omap1_init_irq(void); void omap1_restart(char, const char *); +extern void __init omap_check_revision(void); + extern struct sys_timer omap1_timer; extern bool omap_32k_timer_init(void); -extern void __init omap_init_consistent_dma_size(void); + +extern u32 omap_irq_flags; #endif /* __ARCH_ARM_MACH_OMAP1_COMMON_H */ diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c index 2b28e1d..a1b846a 100644 --- a/arch/arm/mach-omap1/id.c +++ b/arch/arm/mach-omap1/id.c @@ -21,6 +21,8 @@ #include mach/hardware.h +#include common.h + #define OMAP_DIE_ID_0 0xfffe1800 #define OMAP_DIE_ID_1 0xfffe1804 #define OMAP_PRODUCTION_ID_0 0xfffe2000 diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c index d969a72..71ce017 100644 --- a/arch/arm/mach-omap1/io.c +++ b/arch/arm/mach-omap1/io.c @@ -18,13 +18,12 @@ #include plat/mux.h #include plat/tc.h +#include plat/dma.h #include iomap.h #include common.h #include clock.h -extern void omap_check_revision(void); - /* * The machine specific code may provide the extra mapping besides the * default mapping provided here. diff --git a/arch/arm/mach-omap1/irq.c b/arch/arm/mach-omap1/irq.c index 4448114..6995fb6 100644 --- a/arch/arm/mach-omap1/irq.c +++ b/arch/arm/mach-omap1/irq.c @@ -49,6 +49,8 @@ #include mach/hardware.h +#include common.h + #define IRQ_BANK(irq) ((irq) 5) #define IRQ_BIT(irq) ((irq) 0x1f) diff --git a/arch/arm/mach-omap1/reset.c b/arch/arm/mach-omap1/reset.c index f255b15..b177091 100644 --- a/arch/arm/mach-omap1/reset.c +++
[PATCH v4 06/12] ARM: OMAP: fix 'using plain integer as NULL pointer' sparse warnings
sparse warns when 0 is passed to a function expecting a pointer argument.
Resolve these warnings by replacing the 0 with NULL.
arch/arm/plat-omap/include/plat/dmtimer.h:319:34: warning: Using plain integer
as NULL pointer
arch/arm/plat-omap/include/plat/dmtimer.h:324:35: warning: Using plain integer
as NULL pointer
arch/arm/mach-omap2/irq.c:294:22: warning: Using plain integer as NULL pointer
arch/arm/mach-omap1/board-palmz71.c:292:50: warning: Using plain integer as
NULL pointer
arch/arm/mach-omap1/board-palmz71.c:295:73: warning: Using plain integer as
NULL pointer
arch/arm/mach-omap1/ams-delta-fiq.c:105:63: warning: Using plain integer as
NULL pointer
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap1/ams-delta-fiq.c |2 +-
arch/arm/mach-omap1/board-palmz71.c |4 ++--
arch/arm/mach-omap2/irq.c |2 +-
arch/arm/plat-omap/include/plat/dmtimer.h |4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap1/ams-delta-fiq.c
b/arch/arm/mach-omap1/ams-delta-fiq.c
index fcce7ff..31197bd 100644
--- a/arch/arm/mach-omap1/ams-delta-fiq.c
+++ b/arch/arm/mach-omap1/ams-delta-fiq.c
@@ -102,7 +102,7 @@ void __init ams_delta_init_fiq(void)
}
retval = request_irq(INT_DEFERRED_FIQ, deferred_fiq,
- IRQ_TYPE_EDGE_RISING, deferred_fiq, 0);
+ IRQ_TYPE_EDGE_RISING, deferred_fiq, NULL);
if (retval 0) {
pr_err(Failed to get deferred_fiq IRQ, ret=%d\n, retval);
release_fiq(fh);
diff --git a/arch/arm/mach-omap1/board-palmz71.c
b/arch/arm/mach-omap1/board-palmz71.c
index a2c5abc..61ed4f0 100644
--- a/arch/arm/mach-omap1/board-palmz71.c
+++ b/arch/arm/mach-omap1/board-palmz71.c
@@ -289,10 +289,10 @@ palmz71_gpio_setup(int early)
gpio_direction_input(PALMZ71_USBDETECT_GPIO);
if (request_irq(gpio_to_irq(PALMZ71_USBDETECT_GPIO),
palmz71_powercable, IRQF_SAMPLE_RANDOM,
- palmz71-cable, 0))
+ palmz71-cable, NULL))
printk(KERN_ERR
IRQ request for power cable
failed!\n);
- palmz71_powercable(gpio_to_irq(PALMZ71_USBDETECT_GPIO), 0);
+ palmz71_powercable(gpio_to_irq(PALMZ71_USBDETECT_GPIO), NULL);
}
}
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 14fbc78..80f3ced 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -335,7 +335,7 @@ void omap_intc_restore_context(void)
void omap3_intc_suspend(void)
{
/* A pending interrupt would prevent OMAP from entering suspend */
- omap_ack_irq(0);
+ omap_ack_irq(NULL);
}
void omap3_intc_prepare_idle(void)
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 9418f00..230ff91 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -316,12 +316,12 @@ static inline void __omap_dm_timer_init_regs(struct
omap_dm_timer *timer)
OMAP_TIMER_V1_SYS_STAT_OFFSET;
timer-irq_stat = timer-io_base + OMAP_TIMER_V1_STAT_OFFSET;
timer-irq_ena = timer-io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
- timer-irq_dis = 0;
+ timer-irq_dis = NULL;
timer-pend = timer-io_base + _OMAP_TIMER_WRITE_PEND_OFFSET;
timer-func_base = timer-io_base;
} else {
timer-revision = 2;
- timer-sys_stat = 0;
+ timer-sys_stat = NULL;
timer-irq_stat = timer-io_base + OMAP_TIMER_V2_IRQSTATUS;
timer-irq_ena = timer-io_base + OMAP_TIMER_V2_IRQENABLE_SET;
timer-irq_dis = timer-io_base + OMAP_TIMER_V2_IRQENABLE_CLR;
--
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 v4 04/12] ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus
The OMAP1 OHCI driver needs to enable the OCPI IP block before it can
work. Previously, the driver was simply calling a symbol defined in
the OMAP platform code, but this is incorrect: drivers should be fully
decoupled from platform and architecture code.
So instead, modify the driver to call through a platform_data function
pointer instead. We skip any DT aspect, since OMAP1 is not scheduled
to be converted to DT in the near future.
This resolves the following sparse warning:
It also gets rid of a cpu_is_omap16xx() call in a driver.
In the long term, it probably makes sense to move the OCPI bus code to
somewhere under drivers/. This should avoid the whole platform_data/DT
issue with this function.
Also interesting is that drivers/usb/host/ohci-nxp.c contains a stub
for ocpi_enable() - perhaps the NXP chips use a similar OCPI IP block?
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Roland Stigge sti...@antcom.de
Cc: Felipe Balbi ba...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap1/usb.c |3 +++
arch/arm/plat-omap/include/plat/board.h |2 ++
drivers/usb/host/ohci-omap.c|5 +++--
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 19de03b..e61afd9 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -29,6 +29,8 @@
#include plat/mux.h
#include plat/usb.h
+#include common.h
+
/* These routines should handle the standard chip-specific modes
* for usb0/1/2 ports, covering basic mux and transceiver setup.
*
@@ -138,6 +140,7 @@ static inline void ohci_device_init(struct omap_usb_config
*pdata)
if (cpu_is_omap7xx())
ohci_resources[1].start = INT_7XX_USB_HHC_1;
pdata-ohci_device = ohci_device;
+ pdata-ocpi_enable = ocpi_enable;
}
#else
diff --git a/arch/arm/plat-omap/include/plat/board.h
b/arch/arm/plat-omap/include/plat/board.h
index d5eb4c8..4814c5b 100644
--- a/arch/arm/plat-omap/include/plat/board.h
+++ b/arch/arm/plat-omap/include/plat/board.h
@@ -91,6 +91,8 @@ struct omap_usb_config {
u32 (*usb0_init)(unsigned nwires, unsigned is_device);
u32 (*usb1_init)(unsigned nwires);
u32 (*usb2_init)(unsigned nwires, unsigned alt_pingroup);
+
+ int (*ocpi_enable)(void);
};
struct omap_lcd_config {
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 96451e4..71229cb 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -205,8 +205,9 @@ static int ohci_omap_init(struct usb_hcd *hcd)
need_transceiver = need_transceiver
|| machine_is_omap_h2() || machine_is_omap_h3();
- if (cpu_is_omap16xx())
- ocpi_enable();
+ /* XXX OMAP16xx only */
+ if (config-ocpi_enable)
+ config-ocpi_enable();
#ifdef CONFIG_USB_OTG
if (need_transceiver) {
--
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 v4 05/12] ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse
arch/arm/mach-omap2/gpmc.c passes a return value from ioremap() as the fifth argument to request_irq() without casting it. This causes sparse to generate the following warning: arch/arm/mach-omap2/gpmc.c:759:63: warning: incorrect type in argument 5 (different address spaces) arch/arm/mach-omap2/gpmc.c:759:63:expected void *dev arch/arm/mach-omap2/gpmc.c:759:63:got void [noderef] asn:2*static [toplevel] [assigned] gpmc_base It turns out that it's not necessary to pass this. gpmc_base is a file-scoped static variable, the ISR is located in the same file ... and the ISR doesn't even touch the passed-in variable. So, just replace it with NULL in request_irq(). Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/gpmc.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 00d5108..580e684 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -755,8 +755,7 @@ static int __init gpmc_init(void) irq++; } - ret = request_irq(gpmc_irq, - gpmc_handle_irq, IRQF_SHARED, gpmc, gpmc_base); + ret = request_irq(gpmc_irq, gpmc_handle_irq, IRQF_SHARED, gpmc, NULL); if (ret) pr_err(gpmc: irq-%d could not claim: err %d\n, gpmc_irq, ret); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tue, Apr 10, 2012 at 5:51 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Tue, Apr 10, 2012 at 2:59 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Apr 10, 2012 at 02:27:36PM +0530, Santosh Shilimkar wrote: On Tuesday 10 April 2012 02:14 PM, Russell King - ARM Linux wrote: On Mon, Apr 09, 2012 at 03:18:22PM -0500, Jon Hunter wrote: True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. Why? What if you want to have PM enabled, and you also want to use the kernels high resolution timers, or you want more accurate timing than the 30.5us tick interval of the 32k timer? You might have missed the earlier comments on the thread. High resolution GP timer(sysclk) will stop in deeper power states and hence it can't be used with PM enabled usecases. Which means folk should be given the choice at boot time between running with the deeper power states and having a higher resolution timing source, rather than denying them the higher resolution timing source when PM is enabled. Good point. My point is such facilities is already part of the kernel and there is no need to add a new one. The last proposal was allowing user to choose gptimer as a clocksource and then you already have facility to disable C-state now so, all should work in general 'nohlt' in boot cmd should work to prevent CPU from entering deep C-state, which looks enough to make gptimer working well if system suspend isn't considered. Thanks, -- Ming Lei -- 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] mtd: omap2: fix resource leak in prefetch-busy path
If prefetch engine is busy, current code forgets to call dma_unmap_single(), which results in a deadlock later, so add it. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- drivers/mtd/nand/omap2.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index f745f00..7feb274 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -402,7 +402,7 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr, PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write); if (ret) /* PFPW engine is busy, use cpu copy method */ - goto out_copy; + goto out_copy_unmap; init_completion(info-comp); @@ -421,6 +421,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr, dma_unmap_single(info-pdev-dev, dma_addr, len, dir); return 0; +out_copy_unmap: + dma_unmap_single(info-pdev-dev, dma_addr, len, dir); out_copy: if (info-nand.options NAND_BUSWIDTH_16) is_write == 0 ? omap_read_buf16(mtd, (u_char *) addr, len) -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] dt: export of_have_populated_dt
On Tuesday 10 April 2012 10:50 PM, Rob Herring wrote: Rob, Does it make sense to use that in the driver? So far I was using that only in the arch code to make the difference between the DT boot and the non-DT boot. I guess that a driver should rely on of_match_device or non-NULL device_node to figure out that? Agreed. of_match_device or device_node ptr check is the right approach. Thanks Rob, I'll post a patch to fix that up. -- 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] dt: export of_have_populated_dt
On Tuesday 10 April 2012 08:41 PM, Balaji T K wrote:
If of_have_populated_dt is called from module, build fails with allnodes
undefined error, so remove inline and export of_have_populated_dt.
Thanks Balaji, for taking care of this while I was out.
But like Rob and Sebastian mentioned, looks like the usage of
of_have_populated_dt() itself is wrong in the first place.
So I will fix that up with a patch shortly.
Signed-off-by: Balaji T Kbalaj...@ti.com
---
drivers/of/base.c |6 ++
include/linux/of.h |6 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5806449..dc1af42 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -186,6 +186,12 @@ struct property *of_find_property(const struct device_node
*np,
}
EXPORT_SYMBOL(of_find_property);
+bool of_have_populated_dt(void)
+{
+ return allnodes != NULL;
+}
+EXPORT_SYMBOL(of_have_populated_dt);
+
/**
* of_find_all_nodes - Get next node in global list
* @prev: Previous node or NULL to start iteration
diff --git a/include/linux/of.h b/include/linux/of.h
index fa7fb1d..28e933e 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -92,11 +92,6 @@ extern struct device_node *of_chosen;
extern struct device_node *of_aliases;
extern rwlock_t devtree_lock;
-static inline bool of_have_populated_dt(void)
-{
- return allnodes != NULL;
-}
-
static inline bool of_node_is_root(const struct device_node *node)
{
return node (node-parent == NULL);
@@ -112,6 +107,7 @@ static inline void of_node_set_flag(struct device_node *n,
unsigned long flag)
set_bit(flag,n-_flags);
}
+extern bool of_have_populated_dt(void);
extern struct device_node *of_find_all_nodes(struct device_node *prev);
/*
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/9] ARM: OMAP2+: gpmc: driver conversion
Hi Jon,
On Wed, Apr 11, 2012 at 00:53:14, Hunter, Jon wrote:
I agree with your argument but I was thinking today only OMAP uses the
GPMC so we could not worry about this. Ok, leave as-is, but can we
modify the code as follows as the else if is not really needed...
if (gpmc-num_irq GPMC_NR_IRQ) {
dev_warn(gpmc-dev, Insufficient interrupts for device\n);
return -EINVAL;
}
gpmc-num_irq = GPMC_NR_IRQ;
Yes, it is better
Furthermore, GPMC_NR_IRQ is defined as 6 which is correct for OMAP2/3
but not for OMAP4/5, it is 5. Therefore, we need to detect whether we
are using an OMAP2/3 or OMAP4+ and set num_irqs based upon this. This
could be done in the probe and we can avoid passing this.
Is it dependent on OMAPX or GPMC IP version? if it is IP version, then
driver
can be enhanced to handle it, if not, platform has to pass this information.
Here are the GPMC IP revisions ...
OMAP5430 = 0x0060
OMAP4430 = 0x0060
OMAP3630 = 0x0050
OMAP3430 = 0x0050
So this should work for OMAP. We should check OMAP2 as well. What about
the AMxxx devices?
I badly needed this information, thanks.
AM3359 = 0x0060, it has only 2 waitpin interrupts
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (res == NULL)
+ dev_warn(gpmc-dev, Failed to get resource: irq\n);
+ else
+ gpmc-master_irq = res-start;
Why not return an error if the IRQ is not found? We don't know if anyone
will be trying to use them.
Why do you want to do that ?
Because this indicates a BUG :-)
I disagree, this need not be considered a bug always,
for eg. If gpmc irq is not connected to intc
Ok, so for devices existing today this indicates a bug ;-)
I do not want to consider that case to be bug enough for probe
to fail, there are other drivers which does similar enhancing
its use cases,
eg. 1e351a9 mfd: Make TPS65910 usable without interrupts
At a minimum you need to improve the error handing here. If the
platform_get_resource fails you are still calling gpmc_setup_irq()
which appears to be pointless. It would be better if the gpmc irq chip
is not initialised in this case so that drivers attempting to request
these irqs failed.
Please see gpmc_setup_irq, if irq is not present, it returns in the
beginning, and gpmc_irq_chip is not initialized in that case.
+ for (gdq = gp-device_pdata, gd = gpmc-device; *gdq; gdq++,
i++) {
+ ret = gpmc_setup_device(*gdq, gd, gpmc);
+ if (IS_ERR_VALUE(ret))
+ dev_err(gpmc-dev, gpmc setup on %s failed\n,
+
(*gdq)-name);
+ else
+ gd++;
+ }
Would a while loop be simpler?
My preference is to go with for
Ok, just wondering if this could be cleaned up a little.
For travelling through array of pointers, for looks natural to me, if you
have a better way, please send it, it can be folded in next version.
Could you have num_devices to indicate how many platform devices there
are and then a simple for-loop of 0 to num_devices?
This will cause coding to be done by platform to be less simple, and my
preference is not to use another variable
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 4/9] ARM: OMAP2+: gpmc-nand: populate gpmc configs
Hi Jon, On Wed, Apr 11, 2012 at 00:54:58, Hunter, Jon wrote: +#defineGPMC_NAND_CONFIG_NUM4 Where does 4 come from? It depends on the use case, for NAND, with the way it was being configured (or number of times gpmc_cs_configure was being called) 4 are needed. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 19/19] ARM: OMAP4: hwmod data: I2C: add flag for context restore
On Tuesday 10 April 2012 11:43 PM, Paul Walmsley wrote: On Tue, 10 Apr 2012, Shubhrajyoti D wrote: Restore of context is not done for OMAP4. This patch adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4 hwmod data which activates the restore for OMAP4. Currently the OMAP4 does not hit device off still the driver may have support for it. Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Wamsley p...@pwsan.com Reviewed-by: Kevin Hilman khil...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Thanks, queued for 3.5. You can drop this from your series; it will likely cause merge conflicts if you don't. Thanks Paul. Will drop this patch and resend. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
