Re: Suspend broken on 3.3?
On Mon, Apr 2, 2012 at 6:07 PM, Joe Woodward j...@terrafix.co.uk wrote: -Original Message- From: Raja, Govindraj govindraj.r...@ti.com To: Joe Woodward j...@terrafix.co.uk, Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, ne...@suse.de Date: Mon, 2 Apr 2012 16:13:13 +0530 Subject: Re: Suspend broken on 3.3? On Fri, Mar 30, 2012 at 5:54 PM, Raja, Govindraj govindraj.r...@ti.com wrote: On Fri, Mar 30, 2012 at 4:34 PM, Joe Woodward j...@terrafix.co.uk wrote: -Original Message- From: Raja, Govindraj govindraj.r...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Paul Walmsley p...@pwsan.com, Kevin Hilman khil...@ti.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, ne...@suse.de Date: Fri, 30 Mar 2012 15:45:19 +0530 Subject: Re: Suspend broken on 3.3? On Fri, Mar 30, 2012 at 2:56 PM, Joe Woodward j...@terrafix.co.uk wrote: ...[snip]... Could you please try attached patch and let me know if this solves the rx issue as well, without using dma mode. Right, I think we've getting closer, but still not quite there... Firstly, the patch adds an include to iomap.h - but this doesn't exist in stock 3.3. Simply removing this include seemed to allow the compile to complete successfully. Sorry I forgot to specify this is needed for latest mainline. With this patch applied (and not in DMA mode) I now get the following: - If I leave wake-from-suspend enabled for the serial port then it works correctly (i.e. no lost/extra 0x00 characters). - If I disable wake-from-suspend for the serial port and go through a suspend cycle (i.e. suspend and then wake), then the serial port starts to misbehave as before. - If I then re-enable wake-from-suspend and go through a suspend cycle it starts to work correctly again. So the problem is still that if wake-from-suspend is disabled for a serial port, and a suspend cycle is performed then when woken the serial port will not function correctly if operating in interrupt-mode. I tried it on my 3430sdp but strangely I don't see a 0x00 char read after disabling uart wakeups and waking up by keypad press. Probably as a quick try we can try doing uart_insert_char only if data was read from rx fifo (Attached patch) Sadly the patch makes no difference. I'm suprised you aren't seeing similar effects. I've done more testing, and a simplified test case is as follows: - take a stock 3.3 kernel and apply your patch to allow disabling of wake-from-suspend for the serial ports. - disable wake-from-suspend for the console tty: echo disable /sys/devices/platform/omap/omap_uart.2/power/wakeup - perform a suspend (you'll need a button or something to wake you now that the console wont). echo mem /sys/power/state At this point the console is noticable/painfully slow. No characters are lost, but it's obvious something isn't right! Yes I see this behavior with console now it becomes very slow after we disable module level wakeups. One difference to note is : in 3.2 = full system PM is prevented in idle path if uart is active i.e, MPU will not hit retention in 3.3 = MPU will hit retention independently of uart is active or not. I think the way to get MPU qos for uart port activity while in irq mode is to use PM_WKEN1 reg settings, meaning enabling module level wakeup event generation. Disabling it is causing this slow response. Checking if we can workaround this scenario. As of now what I can think of is to update qos reqest to prevent MPU from transitioning in case of port activity if wakeup capability for port is disabled. Does that get us back to the same behaviour as in 3.2? If thats the best we can do, then I guess that'll have to do. yes, only if we are in non-dma mode with wakeup disabled. Will similar problems exist when in DMA-mode (as we I set the DMA flag it seemed to work ok)? In dma mode we might not need MPU for uart fifo ops and while in irq mode we need MPU for fifo ops, while mpu is hitting low power states way to get mpu qos for uart ops is by generating module level wakeup events, if module level wakeups are disabled and if uart does relies on mpu for fifo ops we have to prevent MPU from hitting low power states. It does seem a little strange from my naive point of view: surely what peripherals/pins are used to wake the device from suspend should not affect how the device chooses to enable/disable clocks/power-domains to save power when running? -- 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 for 3.4] MFD: twl6040: Convert to i2c driver, and separate it from twl core
Complete the separation of the twl6040 from the twl core since
it is a separate chip, not part of the twl6030 PMIC.
Make the needed Kconfig changes for the depending drivers at the same time to
avoid breaking the kernel build (vibra, ASoC components).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Mark Brown broo...@opensource.wolfsonicro.com
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
Acked-by: Dmitry Torokhov d...@mail.ru
---
Hi Samuel, Tony, Liam,
Due to some cross tree issues 3.4-rc1 have big regression in OMAP4 audio:
The twl6040 mfd driver (and codec, vibra) is no longer probe since the twl-core
now did not create the platform device for it. This means we do not have audio
working in rc1.
This patch meant to follow the twl-core change (to not probe the twll6040 as
platform device), but there were some glitch in the logistics so this patch is
not in 3.4-rc1.
I have forward ported it on top of 3.4-rc1, and you can also find the patch in:
g...@gitorious.org:omap-audio/linux-audio.git peter/upstream/for-3.4-rc2
Can someone take this patch further to be included in 3.4-rc2?
Thank you,
Peter
arch/arm/mach-omap2/board-4430sdp.c| 12 ++--
arch/arm/mach-omap2/board-generic.c|2 +-
arch/arm/mach-omap2/board-omap4panda.c | 13 ++--
arch/arm/mach-omap2/twl-common.c | 37 +--
arch/arm/mach-omap2/twl-common.h | 10 +--
drivers/input/misc/Kconfig |3 +-
drivers/input/misc/twl6040-vibra.c |4 +-
drivers/mfd/Kconfig| 11 +++-
drivers/mfd/twl6040-core.c | 114 +++-
include/linux/i2c/twl.h| 12
include/linux/mfd/twl6040.h| 27
sound/soc/codecs/Kconfig |3 +-
sound/soc/codecs/twl6040.c |3 +-
sound/soc/omap/Kconfig |2 +-
14 files changed, 159 insertions(+), 94 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a39fc4b..130ab00 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include linux/usb/otg.h
#include linux/spi/spi.h
#include linux/i2c/twl.h
+#include linux/mfd/twl6040.h
#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
@@ -560,7 +561,7 @@ static struct regulator_init_data sdp4430_vusim = {
},
};
-static struct twl4030_codec_data twl6040_codec = {
+static struct twl6040_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
.hs_left_step = 0x0f,
.hs_right_step = 0x0f,
@@ -568,7 +569,7 @@ static struct twl4030_codec_data twl6040_codec = {
.hf_right_step = 0x1d,
};
-static struct twl4030_vibra_data twl6040_vibra = {
+static struct twl6040_vibra_data twl6040_vibra = {
.vibldrv_res = 8,
.vibrdrv_res = 3,
.viblmotor_res = 10,
@@ -577,16 +578,14 @@ static struct twl4030_vibra_data twl6040_vibra = {
.vddvibr_uV = 0,/* fixed volt supply - VBAT */
};
-static struct twl4030_audio_data twl6040_audio = {
+static struct twl6040_platform_data twl6040_data = {
.codec = twl6040_codec,
.vibra = twl6040_vibra,
.audpwron_gpio = 127,
- .naudint_irq= OMAP44XX_IRQ_SYS_2N,
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
static struct twl4030_platform_data sdp4430_twldata = {
- .audio = twl6040_audio,
/* Regulators */
.vusim = sdp4430_vusim,
.vaux1 = sdp4430_vaux1,
@@ -617,7 +616,8 @@ static int __init omap4_i2c_init(void)
TWL_COMMON_REGULATOR_VCXIO |
TWL_COMMON_REGULATOR_VUSB |
TWL_COMMON_REGULATOR_CLK32KG);
- omap4_pmic_init(twl6030, sdp4430_twldata);
+ omap4_pmic_init(twl6030, sdp4430_twldata,
+ twl6040_data, OMAP44XX_IRQ_SYS_2N);
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 74e1687..098d183 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -137,7 +137,7 @@ static struct twl4030_platform_data sdp4430_twldata = {
static void __init omap4_i2c_init(void)
{
- omap4_pmic_init(twl6030, sdp4430_twldata);
+ omap4_pmic_init(twl6030, sdp4430_twldata, NULL, 0);
}
static void __init omap4_init(void)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d8c0e89..1b782ba 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -25,6 +25,7 @@
#include linux/gpio.h
#include
[PATCH] remove unused FB_OMAP_BOOTLOADER_INIT config option
From: Peter Meerwald p.meerw...@bct-electronic.com code depending on FB_OMAP_BOOTLOADER_INIT has been removed long before (e.g. Tomi Valkeinen, 03 Mar 2011: OMAP: DSS2: Remove FB_OMAP_BOOTLOADER_INIT support), but the option still exists Kconfig and has no use Signed-off-by: Peter Meerwald p.meerw...@bct-electronic.com --- drivers/video/omap/Kconfig |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig index 1e7536d..b48f95f 100644 --- a/drivers/video/omap/Kconfig +++ b/drivers/video/omap/Kconfig @@ -39,14 +39,6 @@ config FB_OMAP_LCD_MIPID the Mobile Industry Processor Interface DBI-C/DCS specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3) -config FB_OMAP_BOOTLOADER_INIT - bool Check bootloader initialization - depends on FB_OMAP - help - Say Y here if you want to enable checking if the bootloader has - already initialized the display controller. In this case the - driver will skip the initialization. - config FB_OMAP_CONSISTENT_DMA_SIZE int Consistent DMA memory size (MB) depends on FB_OMAP -- 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
Re: oprofile and ARM A9 hardware counter
Santosh,
On Wed, Jan 18, 2012 at 12:33:23PM +, Shilimkar, Santosh wrote:
On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei ming@canonical.com wrote:
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
NAK.
You don't need this patch. What you saw on CAMERA was indeed
a known bug but emulation domain has no such issues.
So the accesses to emulation register should continue to work
with the clock-domain being kept under hardware supervision.
But why can this patch make omap4 pmu work? Without the patch,
there are no CTI interrupts generated for pmu irq.
Interesting. For me debugger works which also relies on Emulation domain.
Need to see why CTI is behaving like this.
Did you ever get to the bottom of this? This change really is required in
order to generate PMU interrupts with the CTI and I don't know of any
alternative to the above.
Any suggestions?
Will
--
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: oprofile and ARM A9 hardware counter
On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon will.dea...@arm.com wrote:
Santosh,
On Wed, Jan 18, 2012 at 12:33:23PM +, Shilimkar, Santosh wrote:
On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei ming@canonical.com wrote:
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
NAK.
You don't need this patch. What you saw on CAMERA was indeed
a known bug but emulation domain has no such issues.
So the accesses to emulation register should continue to work
with the clock-domain being kept under hardware supervision.
But why can this patch make omap4 pmu work? Without the patch,
there are no CTI interrupts generated for pmu irq.
Interesting. For me debugger works which also relies on Emulation domain.
Need to see why CTI is behaving like this.
Did you ever get to the bottom of this? This change really is required in
order to generate PMU interrupts with the CTI and I don't know of any
alternative to the above.
Any suggestions?
Sorry I lost track of this one. There is one relevant patch in Kevin's queue
for 3.4/fixes. [1] which I generated for perf time stamp issue.
Can you try that patch and see if it helps the CTI issue as well ? There
is an outside chance that it might help. If it doesn't, we should commit
Ming Lei patch.
Regards
Santosh
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.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] OMAP4: Adding ID for OMAP4460 ES1.1
Hi Tony,
Could you please take this patch for the next merge? Thanks.
regards,
-roger
On 04/02/2012 11:59 AM, Roger Quadros wrote:
From: Chris Lalancette clalance...@gmail.com
Signed-off-by: Chris Lalancette clalance...@gmail.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/id.c |5 -
arch/arm/plat-omap/include/plat/cpu.h |1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 0e79b7b..f139817 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -478,9 +478,12 @@ void __init omap4xxx_check_revision(void)
case 0xb94e:
switch (rev) {
case 0:
- default:
omap_revision = OMAP4460_REV_ES1_0;
break;
+ case 2:
+ default:
+ omap_revision = OMAP4460_REV_ES1_1;
+ break;
}
break;
case 0xb975:
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index dc6a86b..4bdf14e 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -445,6 +445,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP446X_CLASS 0x44600044
#define OMAP4460_REV_ES1_0 (OMAP446X_CLASS | (0x10 8))
+#define OMAP4460_REV_ES1_1 (OMAP446X_CLASS | (0x11 8))
#define OMAP447X_CLASS 0x44700044
#define OMAP4470_REV_ES1_0 (OMAP447X_CLASS | (0x10 8))
--
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: oprofile and ARM A9 hardware counter
On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote: On Tue, Apr 03, 2012 at 10:42:30AM +0100, Shilimkar, Santosh wrote: On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon will.dea...@arm.com wrote: Did you ever get to the bottom of this? This change really is required in order to generate PMU interrupts with the CTI and I don't know of any alternative to the above. Any suggestions? Sorry I lost track of this one. There is one relevant patch in Kevin's queue for 3.4/fixes. [1] which I generated for perf time stamp issue. Thanks, I'll take a look. Can you try that patch and see if it helps the CTI issue as well ? There is an outside chance that it might help. If it doesn't, we should commit Ming Lei patch. It seems that they're both needed to get reliable PMU operation. Without the CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch below ([1]), it seems that we don't generate enough. So it looks like we need them both. I see. Can you please confirm if it is still the case with [1]. If yes then am nou sure how to proceed. because permanently setting EMU CD to CLKDM_CAN_SWSUP will break PM. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] PM: Create the AVS class of drivers
Hi Tony, Rafael, Here is a gentle ping on this series. Do you think this can go in the next rc? Regards, Jean On Mon, Mar 19, 2012 at 5:12 PM, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com AVS is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). AVS is also called SmartReflex on OMAP devices. To that end, create the AVS framework in drivers/power/avs and move the OMAP SmartReflex code to the new directory. In preparation to the move of the OMAP code the following changes have been made: - split the include files into generic and platform specific code, - fill in platform data from the device initialization code and pass it to the driver, - create CONFIG_AVS* config options accordingly. The platform integration data for SmartReflex is passed from hwmod and the voltage layer to the driver using pdata. Tested on OMAP3 Beagleboard using omap2plus_defconfig with the CONFIG_POWER_AVS* options set. Based on master branch of the l-o git tree (3.3.0-rc6) [1], commit 85244e0edd240da2004bb2ab7cbcbc67a336f20d. [1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git History: v2: rework after the comments on MLs . Keep the OMAP Kconfig options in the arch dir (Rafael), . Move the shared header file from plat-omap to include/linux/power/ (Tony) v1: initial revision Jean Pihet (9): ARM: OMAP3+: voltage: export functions to plat/voltage.h ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power ARM: OMAP3+: SmartReflex: class drivers should use struct omap_sr * ARM: OMAP2+: smartreflex: Use the names from hwmod data instead of voltage domains. ARM: OMAP3: hwmod: rename the smartreflex entries ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro ARM: OMAP2+: SmartReflex: Use per-OPP data structure ARM: OMAP2+: SmartReflex: add POWER_AVS Kconfig options ARM: OMAP: SmartReflex: Move smartreflex driver to drivers/ arch/arm/mach-omap2/Makefile | 4 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 3 +- arch/arm/mach-omap2/pm.h | 2 +- arch/arm/mach-omap2/smartreflex-class3.c | 60 -- arch/arm/mach-omap2/smartreflex.c | 1165 arch/arm/mach-omap2/smartreflex.h | 256 -- arch/arm/mach-omap2/sr_device.c | 38 +- arch/arm/mach-omap2/voltage.h | 1 - arch/arm/mach-omap2/vp.h | 2 - arch/arm/plat-omap/Kconfig | 30 +- arch/arm/plat-omap/include/plat/voltage.h | 3 + drivers/power/Kconfig | 2 + drivers/power/Makefile | 2 + drivers/power/avs/Kconfig | 12 + drivers/power/avs/Makefile | 2 + drivers/power/avs/smartreflex-class3.c | 61 ++ drivers/power/avs/smartreflex.c | 1118 ++ drivers/power/avs/smartreflex.h | 238 ++ include/linux/power/smartreflex.h | 97 +++ 20 files changed, 1590 insertions(+), 1518 deletions(-) delete mode 100644 arch/arm/mach-omap2/smartreflex-class3.c delete mode 100644 arch/arm/mach-omap2/smartreflex.c delete mode 100644 arch/arm/mach-omap2/smartreflex.h create mode 100644 drivers/power/avs/Kconfig create mode 100644 drivers/power/avs/Makefile create mode 100644 drivers/power/avs/smartreflex-class3.c create mode 100644 drivers/power/avs/smartreflex.c create mode 100644 drivers/power/avs/smartreflex.h create mode 100644 include/linux/power/smartreflex.h -- 1.7.5.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
[PATCHv4 01/18] 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.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
[PATCHv4 14/18] 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.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
[PATCHv4 00/18] 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. Tested on omap4sdp and omap3sdp. Following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: g...@gitorious.org:linus-tree/linus-tree.git i2c-v4 Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (15): I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME OMAP : I2C : Remove reset at init OMAP: I2C: I2C register restore only if context is lost OMAP: I2C: Fix the interrupt clearing in OMAP4 OMAP: I2C: Fix the mismatch of pm_runtime enable and disable OMAP: I2C: Optimise the remove code OMAP: I2C: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero OMAP : I2C : use devm_* functions I2C : OMAP : Fix the crash in i2c remove OMAP: I2C: Handle error check for pm runtime I2C : OMAP : Use SET_RUNTIME_PM_OPS OMAP4: hwmod data: I2C: add flag for context restore i2c: omap: make the read ready processing a separate function i2c: omap: Do not set the XUDF if the underflow is not reached 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 | 330 +++- include/linux/i2c-omap.h |1 + 4 files changed, 188 insertions(+), 149 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
[PATCHv4 17/18] 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.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
[PATCHv4 13/18] OMAP: I2C: 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.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
[PATCHv4 04/18] OMAP: I2C: 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,
[PATCHv4 11/18] OMAP : I2C : 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.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
[PATCHv4 05/18] OMAP: I2C: Fix the interrupt clearing in OMAP4
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch ...
- Does not use the IRQENABLE_CLR register to clear as it is not mentioned
to be legacy register IRQENABLE_CLR helps in atomically
setting/clearing specific interrupts, instead use the OMAP_I2C_IE_REG as we
are
clearing all interrupts.
Cc: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 45389db..2769f67 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1179,10 +1179,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
_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);
- else
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ 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 */
--
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
[PATCHv4 12/18] 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.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
[PATCHv4 10/18] 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.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
[PATCHv4 02/18] OMAP : I2C : 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
---
Todo:
Some of the cases like underflow the reset may be removed.
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.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
[PATCHv4 03/18] 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.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
[PATCHv4 16/18] 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;
- }
- }
[PATCHv4 06/18] OMAP: I2C: 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.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
[PATCHv4 15/18] 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.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
[PATCHv4 07/18] OMAP: I2C: 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.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
[PATCHv4 08/18] OMAP: I2C: 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.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
[PATCHv4 09/18] 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.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
[PATCHv4 18/18] 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.
Fix the same and set it 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.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
This patch adds the support for Bosch D_CAN controller. Bosch D_CAN controller is a full-CAN implementation compliant to CAN protocol version 2.0 part A and B. Bosch D_CAN user manual can be obtained from: http://www.semiconductors.bosch.de/media/ en/pdf/ipmodules_1/can/d_can_users_manual_111.pdf D_CAN device is used on many SoCs like AM335x, DM8148 and DM813x EVMs from TI, D_CAN details on AM335x can be accessed from: http://www.ti.com/lit/ug/spruh73c/spruh73c.pdf D_CAN can be configurable for 16, 32, 64 and 128 message objects. The driver implementation is based on 64 message objects. Following are the design choices made while writing the controller driver: 1. Interface Register set IF0 has be used for receive and IF1 is used for transmit message objects. 2. Out of the total Message objects available, half of it are kept aside for RX purposes and the rest for TX purposes. 3. NAPI implementation is such that both the TX and RX paths functions in polling mode. Signed-off-by: AnilKumar Ch anilku...@ti.com --- drivers/net/can/Kconfig| 14 + drivers/net/can/Makefile |1 + drivers/net/can/d_can.c| 1487 include/linux/can/platform/d_can.h | 40 + 4 files changed, 1542 insertions(+), 0 deletions(-) create mode 100644 drivers/net/can/d_can.c create mode 100644 include/linux/can/platform/d_can.h diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index bb709fd..2529cba 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -68,6 +68,20 @@ config CAN_TI_HECC Driver for TI HECC (High End CAN Controller) module found on many TI devices. The device specifications are available from www.ti.com +config CAN_D_CAN + tristate Bosch D_CAN Controller + depends on CAN_DEV + ---help--- + This driver adds support for the D_CAN device found in + many SoCs like am335x, dm814x and dm813x boards from TI. + + The device user guide can be accessed from + http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/ + can/d_can_users_manual_111.pdf + + To compile this driver as a module, choose M here: the + module will be called d_can. + config CAN_MCP251X tristate Microchip MCP251x SPI CAN controllers depends on CAN_DEV SPI HAS_DMA diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile index 938be37..4bd3a87 100644 --- a/drivers/net/can/Makefile +++ b/drivers/net/can/Makefile @@ -17,6 +17,7 @@ obj-$(CONFIG_CAN_C_CAN) += c_can/ obj-$(CONFIG_CAN_CC770)+= cc770/ obj-$(CONFIG_CAN_AT91) += at91_can.o obj-$(CONFIG_CAN_TI_HECC) += ti_hecc.o +obj-$(CONFIG_CAN_D_CAN)+= d_can.o obj-$(CONFIG_CAN_MCP251X) += mcp251x.o obj-$(CONFIG_CAN_BFIN) += bfin_can.o obj-$(CONFIG_CAN_JANZ_ICAN3) += janz-ican3.o diff --git a/drivers/net/can/d_can.c b/drivers/net/can/d_can.c new file mode 100644 index 000..51e2986 --- /dev/null +++ b/drivers/net/can/d_can.c @@ -0,0 +1,1487 @@ +/* + * CAN bus driver for Bosch D_CAN controller + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * Borrowed from C_CAN driver + * Copyright (C) 2010 ST Microelectronics + * - Bhupesh Sharma bhupesh.sha...@st.com + * + * Borrowed heavily from the C_CAN driver originally written by: + * Copyright (C) 2007 + * - Sascha Hauer, Marc Kleine-Budde, Pengutronix s.ha...@pengutronix.de + * - Simon Kallweit, intefo AG simon.kallw...@intefo.ch + * + * Bosch D_CAN controller is compliant to CAN protocol version 2.0 part A and B. + * Bosch D_CAN user manual can be obtained from: + * http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/can/ + * d_can_users_manual_111.pdf + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/interrupt.h +#include linux/netdevice.h +#include linux/errno.h +#include linux/skbuff.h +#include linux/jiffies.h +#include linux/pm_runtime.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/io.h + +#include linux/can/dev.h +#include linux/can/error.h +#include linux/can/platform/d_can.h + +#define D_CAN_DRV_NAME d_can +#define D_CAN_VERSION 1.0 +#define D_CAN_DRV_DESC CAN bus driver for Bosch D_CAN controller \ + D_CAN_VERSION + +/* TI D_CAN module registers */ +#define D_CAN_CTL 0x0 /* CAN control register */ +#define D_CAN_ES 0x4 /* Error and status */ +#define
Re: oprofile and ARM A9 hardware counter
On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote: On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote: It seems that they're both needed to get reliable PMU operation. Without the CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch below ([1]), it seems that we don't generate enough. So it looks like we need them both. I see. Can you please confirm if it is still the case with [1]. Right, ignore my previous comment, I was using a vanilla 3.3 kernel without realising and therefore what I thought were PMU/CTI interrupts were actually just from a timer. Sorry for the confusion. So I've gone back to basics. Here is a branch containing what I believe should be all the patches required for the OMAP4 PMU: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not acceptable. The problem is, trying to boot this on my pandaboard results in a hang (see dmesg below). Even worse, the problem isn't easily bisectable since rebuilding a working image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). Will Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.3.0-5-gcd122ab (will@mudshark) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #1 SMP Tue Apr 3 13:19:29 BST 2012 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES2.1 [0.00] PERCPU: Embedded 8 pages/cpu @c1025000 s11072 r8192 d13504 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [0.00] Kernel command line: console=ttyO2,115200 root=/dev/nfs nfsroot=10.1.79.58:/exports/linaro-11.11,tcp rw earlyprintk ip=dhcp [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 511MB = 511MB total [0.00] Memory: 506272k/506272k available, 18016k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc05ebf68 (6032 kB) [0.00] .init : 0xc05ec000 - 0xc0639b40 ( 311 kB) [0.00] .data : 0xc063a000 - 0xc06c6d50 ( 564 kB) [0.00].bss : 0xc06c6d74 - 0xc0c1cb5c (5464 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.056579] Calibrating delay loop... 2007.19 BogoMIPS (lpj=7839744) [0.129791] pid_max: default: 32768 minimum: 301 [0.135192] Security Framework initialized [0.139678] Mount-cache hash table entries: 512 [0.147979] CPU: Testing write buffer coherency: ok [0.153961] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.160278] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available [0.168853] Setting up static identity map for 0x8043ce60 - 0x8043ced0 [0.175689] L310 cache controller enabled [0.179931] l2x0: 16 ways, CACHE_ID 0x41c4, AUX_CTRL 0x7e47, Cache size: 1048576 B [0.190856] CPU1: Booted secondary processor [0.254028] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.254058] CPU1: Unknown IPI message
RE: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
Hi All, Subject line of this patch should be ARM: CAN: d_can: Add support for Bosch D_CAN controller Regards AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Tue, Apr 3, 2012 at 6:04 PM, Will Deacon will.dea...@arm.com wrote: On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote: On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote: It seems that they're both needed to get reliable PMU operation. Without the CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch below ([1]), it seems that we don't generate enough. So it looks like we need them both. I see. Can you please confirm if it is still the case with [1]. Right, ignore my previous comment, I was using a vanilla 3.3 kernel without realising and therefore what I thought were PMU/CTI interrupts were actually just from a timer. Sorry for the confusion. So I've gone back to basics. Here is a branch containing what I believe should be all the patches required for the OMAP4 PMU: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not acceptable. The problem is, trying to boot this on my pandaboard results in a hang (see dmesg below). Even worse, the problem isn't easily bisectable since rebuilding a working image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). I don't see anything abnormal in below boot log. Not sure why it hands around there. 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] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
On 04/03/2012 02:44 PM, Wolfgang Grandegger wrote: On 04/03/2012 02:32 PM, AnilKumar Ch wrote: This patch adds the support for Bosch D_CAN controller. Bosch D_CAN controller is a full-CAN implementation compliant to CAN protocol version 2.0 part A and B. Bosch D_CAN user manual can be obtained from: http://www.semiconductors.bosch.de/media/ en/pdf/ipmodules_1/can/d_can_users_manual_111.pdf D_CAN device is used on many SoCs like AM335x, DM8148 and DM813x EVMs from TI, D_CAN details on AM335x can be accessed from: http://www.ti.com/lit/ug/spruh73c/spruh73c.pdf D_CAN can be configurable for 16, 32, 64 and 128 message objects. The driver implementation is based on 64 message objects. Following are the design choices made while writing the controller driver: 1. Interface Register set IF0 has be used for receive and IF1 is used for transmit message objects. 2. Out of the total Message objects available, half of it are kept aside for RX purposes and the rest for TX purposes. 3. NAPI implementation is such that both the TX and RX paths functions in polling mode. Signed-off-by: AnilKumar Ch anilku...@ti.com Please explain why this CAN controller cannot be handled by the existing C_CAN driver, eventually with some extensions. The register layout seems almost identical, at least. ACK. Have a look at the recent at91_can driver. It has been improved to work with a flexible number of message objects. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
[PATCH-V3 0/3] ARM: OMAP3+: am33xx: Add CM, clock and clockdomain support
This patch series adds CM low-level api's, clockdomain data, respective clockdomain operations and complete Clock Tree for AM33XX family of devices. The earlier versions of patches submitted were, - Patch-RFC was complete set of patches adding separate implementation for all PRM, CM, Clockdomain, clock tree and HWMOD. - Patch-V2 was basically reusing existing OMAP4 cminst and clockdomain api's for AM33XX device (without clock tree). But as aligned and discussed on previous patch submission on AM33XX PRM, we have decided to implement/handle whole AM33xx separately. Please refer to the AM335x TRM available at - http://www.ti.com/product/am3359 I would like to bring same question again (but from CM context), Do we really want to implement CM and clockdomain api's separately? In case of AM33XX PRM implementation, the reason why we had to do it separately was, due to inconsistency of register offset and bit-offsets. But, it is not the case in CM implementation, we have some consistency there and existing OMAP4 code can be reused for AM33XX. I personally feel, we should consider Patch-V2 version here. IMO, the only change required there is to rename files, cminst44xx.c = cminst_33xx_44xx.c clockdomain44xx.c = clockdomain_33xx_44xx.c Vaibhav Hiremath (3): ARM: OMAP3+: cm33xx: Introduce AM33xx CM API's and register level details ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations ARM: OMAP3+: clock33xx: Add AM33XX clock tree data arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/clock33xx.h | 36 + arch/arm/mach-omap2/clock33xx_data.c | 2209 + arch/arm/mach-omap2/clockdomain.h |2 + arch/arm/mach-omap2/clockdomain33xx.c | 74 + arch/arm/mach-omap2/clockdomains33xx_data.c | 214 +++ arch/arm/mach-omap2/cm-regbits-33xx.h | 687 arch/arm/mach-omap2/cm33xx.c | 313 arch/arm/mach-omap2/cm33xx.h | 420 + arch/arm/mach-omap2/io.c |4 +- arch/arm/mach-omap2/omap_hwmod.c | 58 +- arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + 12 files changed, 4006 insertions(+), 18 deletions(-) create mode 100644 arch/arm/mach-omap2/clock33xx.h create mode 100644 arch/arm/mach-omap2/clock33xx_data.c create mode 100644 arch/arm/mach-omap2/clockdomain33xx.c create mode 100644 arch/arm/mach-omap2/clockdomains33xx_data.c create mode 100644 arch/arm/mach-omap2/cm-regbits-33xx.h create mode 100644 arch/arm/mach-omap2/cm33xx.c create mode 100644 arch/arm/mach-omap2/cm33xx.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V3 2/3] ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations
AM33XX PRCM module consist of, various clockdomains, in all
total we have 18 clockdomains available, with following
controlling options,
- NO Sleep: sleep transition can not be initiated,
- SW Sleep: sw forced sleep transition,
- SW Wakeup: sw forced wakeup transition,
- HW Auto: transitions are based upon hw conditions.
This patch adds all available clockdomain data, respective
clockdomain operations for AM33XX family of device, and also
integrates it into existing OMAP framework.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
CC: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile|2 +
arch/arm/mach-omap2/clockdomain.h |2 +
arch/arm/mach-omap2/clockdomain33xx.c | 74 +
arch/arm/mach-omap2/clockdomains33xx_data.c | 214 +++
arch/arm/mach-omap2/io.c|1 +
5 files changed, 293 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/clockdomain33xx.c
create mode 100644 arch/arm/mach-omap2/clockdomains33xx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1695dc8..13838df 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -135,6 +135,8 @@ obj-$(CONFIG_ARCH_OMAP3)+= clockdomain.o \
clockdomain2xxx_3xxx.o \
clockdomains2xxx_3xxx_data.o \
clockdomains3xxx_data.o
+obj-$(CONFIG_SOC_OMAPAM33XX) += clockdomain33xx.o \
+ clockdomains33xx_data.o
obj-$(CONFIG_ARCH_OMAP4) += clockdomain.o \
clockdomain44xx.o \
clockdomains44xx_data.o
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index f7b5860..72cb12b 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -195,6 +195,7 @@ int clkdm_hwmod_disable(struct clockdomain *clkdm, struct
omap_hwmod *oh);
extern void __init omap242x_clockdomains_init(void);
extern void __init omap243x_clockdomains_init(void);
extern void __init omap3xxx_clockdomains_init(void);
+extern void __init am33xx_clockdomains_init(void);
extern void __init omap44xx_clockdomains_init(void);
extern void _clkdm_add_autodeps(struct clockdomain *clkdm);
extern void _clkdm_del_autodeps(struct clockdomain *clkdm);
@@ -202,6 +203,7 @@ extern void _clkdm_del_autodeps(struct clockdomain *clkdm);
extern struct clkdm_ops omap2_clkdm_operations;
extern struct clkdm_ops omap3_clkdm_operations;
extern struct clkdm_ops omap4_clkdm_operations;
+extern struct clkdm_ops am33xx_clkdm_operations;
extern struct clkdm_dep gfx_24xx_wkdeps[];
extern struct clkdm_dep dsp_24xx_wkdeps[];
diff --git a/arch/arm/mach-omap2/clockdomain33xx.c
b/arch/arm/mach-omap2/clockdomain33xx.c
new file mode 100644
index 000..aca6388
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomain33xx.c
@@ -0,0 +1,74 @@
+/*
+ * AM33XX clockdomain control
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Vaibhav Hiremath hvaib...@ti.com
+ *
+ * Derived from mach-omap2/clockdomain44xx.c written by Rajendra Nayak
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+
+#include clockdomain.h
+#include cm33xx.h
+
+
+static int am33xx_clkdm_sleep(struct clockdomain *clkdm)
+{
+ am33xx_cm_clkdm_force_sleep(clkdm-cm_inst, clkdm-clkdm_offs);
+ return 0;
+}
+
+static int am33xx_clkdm_wakeup(struct clockdomain *clkdm)
+{
+ am33xx_cm_clkdm_force_wakeup(clkdm-cm_inst, clkdm-clkdm_offs);
+ return 0;
+}
+
+static void am33xx_clkdm_allow_idle(struct clockdomain *clkdm)
+{
+ am33xx_cm_clkdm_enable_hwsup(clkdm-cm_inst, clkdm-clkdm_offs);
+}
+
+static void am33xx_clkdm_deny_idle(struct clockdomain *clkdm)
+{
+ am33xx_cm_clkdm_disable_hwsup(clkdm-cm_inst, clkdm-clkdm_offs);
+}
+
+static int am33xx_clkdm_clk_enable(struct clockdomain *clkdm)
+{
+ if (clkdm-flags CLKDM_CAN_FORCE_WAKEUP)
+ return am33xx_clkdm_wakeup(clkdm);
+
+ return 0;
+}
+
+static int am33xx_clkdm_clk_disable(struct clockdomain *clkdm)
+{
+ bool hwsup = false;
+
+ hwsup =
Re: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
On 04/03/2012 02:32 PM, AnilKumar Ch wrote: This patch adds the support for Bosch D_CAN controller. Bosch D_CAN controller is a full-CAN implementation compliant to CAN protocol version 2.0 part A and B. Bosch D_CAN user manual can be obtained from: http://www.semiconductors.bosch.de/media/ en/pdf/ipmodules_1/can/d_can_users_manual_111.pdf D_CAN device is used on many SoCs like AM335x, DM8148 and DM813x EVMs from TI, D_CAN details on AM335x can be accessed from: http://www.ti.com/lit/ug/spruh73c/spruh73c.pdf D_CAN can be configurable for 16, 32, 64 and 128 message objects. The driver implementation is based on 64 message objects. Following are the design choices made while writing the controller driver: 1. Interface Register set IF0 has be used for receive and IF1 is used for transmit message objects. 2. Out of the total Message objects available, half of it are kept aside for RX purposes and the rest for TX purposes. 3. NAPI implementation is such that both the TX and RX paths functions in polling mode. Signed-off-by: AnilKumar Ch anilku...@ti.com Please explain why this CAN controller cannot be handled by the existing C_CAN driver, eventually with some extensions. The register layout seems almost identical, at least. Wolfgang. --- drivers/net/can/Kconfig| 14 + drivers/net/can/Makefile |1 + drivers/net/can/d_can.c| 1487 include/linux/can/platform/d_can.h | 40 + 4 files changed, 1542 insertions(+), 0 deletions(-) create mode 100644 drivers/net/can/d_can.c create mode 100644 include/linux/can/platform/d_can.h diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index bb709fd..2529cba 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -68,6 +68,20 @@ config CAN_TI_HECC Driver for TI HECC (High End CAN Controller) module found on many TI devices. The device specifications are available from www.ti.com +config CAN_D_CAN + tristate Bosch D_CAN Controller + depends on CAN_DEV + ---help--- + This driver adds support for the D_CAN device found in + many SoCs like am335x, dm814x and dm813x boards from TI. + + The device user guide can be accessed from + http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/ + can/d_can_users_manual_111.pdf + + To compile this driver as a module, choose M here: the + module will be called d_can. + config CAN_MCP251X tristate Microchip MCP251x SPI CAN controllers depends on CAN_DEV SPI HAS_DMA diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile index 938be37..4bd3a87 100644 --- a/drivers/net/can/Makefile +++ b/drivers/net/can/Makefile @@ -17,6 +17,7 @@ obj-$(CONFIG_CAN_C_CAN) += c_can/ obj-$(CONFIG_CAN_CC770) += cc770/ obj-$(CONFIG_CAN_AT91) += at91_can.o obj-$(CONFIG_CAN_TI_HECC)+= ti_hecc.o +obj-$(CONFIG_CAN_D_CAN) += d_can.o obj-$(CONFIG_CAN_MCP251X)+= mcp251x.o obj-$(CONFIG_CAN_BFIN) += bfin_can.o obj-$(CONFIG_CAN_JANZ_ICAN3) += janz-ican3.o diff --git a/drivers/net/can/d_can.c b/drivers/net/can/d_can.c new file mode 100644 index 000..51e2986 --- /dev/null +++ b/drivers/net/can/d_can.c @@ -0,0 +1,1487 @@ +/* + * CAN bus driver for Bosch D_CAN controller + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * Borrowed from C_CAN driver + * Copyright (C) 2010 ST Microelectronics + * - Bhupesh Sharma bhupesh.sha...@st.com + * + * Borrowed heavily from the C_CAN driver originally written by: + * Copyright (C) 2007 + * - Sascha Hauer, Marc Kleine-Budde, Pengutronix s.ha...@pengutronix.de + * - Simon Kallweit, intefo AG simon.kallw...@intefo.ch + * + * Bosch D_CAN controller is compliant to CAN protocol version 2.0 part A and B. + * Bosch D_CAN user manual can be obtained from: + * http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/can/ + * d_can_users_manual_111.pdf + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/interrupt.h +#include linux/netdevice.h +#include linux/errno.h +#include linux/skbuff.h +#include linux/jiffies.h +#include linux/pm_runtime.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/io.h + +#include linux/can/dev.h +#include linux/can/error.h +#include linux/can/platform/d_can.h + +#define
RE: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
Hi Wolfgang, Thanks for reviewing the patch On Tue, Apr 03, 2012 at 18:14:55, Wolfgang Grandegger wrote: On 04/03/2012 02:32 PM, AnilKumar Ch wrote: This patch adds the support for Bosch D_CAN controller. Bosch D_CAN controller is a full-CAN implementation compliant to CAN protocol version 2.0 part A and B. Bosch D_CAN user manual can be obtained from: http://www.semiconductors.bosch.de/media/ en/pdf/ipmodules_1/can/d_can_users_manual_111.pdf D_CAN device is used on many SoCs like AM335x, DM8148 and DM813x EVMs from TI, D_CAN details on AM335x can be accessed from: http://www.ti.com/lit/ug/spruh73c/spruh73c.pdf D_CAN can be configurable for 16, 32, 64 and 128 message objects. The driver implementation is based on 64 message objects. Following are the design choices made while writing the controller driver: 1. Interface Register set IF0 has be used for receive and IF1 is used for transmit message objects. 2. Out of the total Message objects available, half of it are kept aside for RX purposes and the rest for TX purposes. 3. NAPI implementation is such that both the TX and RX paths functions in polling mode. Signed-off-by: AnilKumar Ch anilku...@ti.com Please explain why this CAN controller cannot be handled by the existing C_CAN driver, eventually with some extensions. The register layout seems almost identical, at least. Wolfgang. These are the some of the pointers I can say, why I had gone for separate file instead of existing driver: * In case of D_CAN driver we can see all the registers are 32bit length but in case of C_CAN registers are in 16bit length. * Some of the registers, bit masks are different, so we have to add checks on every API for differentiating the kind of device * In case of D_CAN we have some extra features like direct message RAM access, DMA support, TX/RX pins can be used as GPIO lines (if applicable), more interrupt lines and three sets of interface registers. * Wait timings while init bit set/reset during bit-timing initialization are different in both the cases * bittiming configurations are different. Thanks AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] OMAP2+: UART: Remove cpu checks for populating errata flags
From: Govindraj.R govindraj.r...@ti.com
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
can be managed within the driver itself.
Cc: Jon Hunter jon-hun...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |8 ---
arch/arm/plat-omap/include/plat/omap-serial.h |1 -
drivers/tty/serial/omap-serial.c | 74 -
3 files changed, 73 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..6affdd4 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -355,14 +355,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
omap_up.dma_rx_poll_rate = info-dma_rx_poll_rate;
omap_up.autosuspend_timeout = info-autosuspend_timeout;
- /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
- if (!cpu_is_omap2420() !cpu_is_ti816x())
- omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
-
- /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
- if (cpu_is_omap34xx() || cpu_is_omap3630())
- omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
-
pdata = omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..1a52725 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -65,7 +65,6 @@ struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
upf_t flags; /* UPF_* flags */
- u32 errata;
unsigned intdma_rx_buf_size;
unsigned intdma_rx_timeout;
unsigned intautosuspend_timeout;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 0121486..0555c96 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -44,6 +44,13 @@
#include plat/dmtimer.h
#include plat/omap-serial.h
+#define UART_BUILD_REVISION(x, y) (((x) 8) | (y))
+
+#define OMAP_UART_REV_42 0x0402
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
+
#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
/* SCR register bitmasks */
@@ -53,6 +60,17 @@
#define OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT 6
#define OMAP_UART_FCR_RX_FIFO_TRIG_MASK(0x3 6)
+/* MVR register bitmasks */
+#define OMAP_UART_MVR_SCHEME_SHIFT 30
+
+#define OMAP_UART_LEGACY_MVR_MAJ_MASK 0xf0
+#define OMAP_UART_LEGACY_MVR_MAJ_SHIFT 4
+#define OMAP_UART_LEGACY_MVR_MIN_MASK 0x0f
+
+#define OMAP_UART_MVR_MAJ_MASK 0x700
+#define OMAP_UART_MVR_MAJ_SHIFT8
+#define OMAP_UART_MVR_MIN_MASK 0x3f
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -1346,6 +1364,59 @@ static void uart_tx_dma_callback(int lch, u16 ch_status,
void *data)
return;
}
+static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
+{
+ u32 mvr, scheme;
+ u16 revision, major, minor;
+
+ mvr = serial_in(up, UART_OMAP_MVER);
+
+ /* Check revision register scheme */
+ scheme = mvr OMAP_UART_MVR_SCHEME_SHIFT;
+
+ switch (scheme) {
+ case 0: /* Legacy Scheme: OMAP2/3 */
+ /* MINOR_REV[0:4], MAJOR_REV[4:7] */
+ major = (mvr OMAP_UART_LEGACY_MVR_MAJ_MASK)
+ OMAP_UART_LEGACY_MVR_MAJ_SHIFT;
+ minor = (mvr OMAP_UART_LEGACY_MVR_MIN_MASK);
+ break;
+ case 1:
+ /* New Scheme: OMAP4+ */
+ /* MINOR_REV[0:5], MAJOR_REV[8:10] */
+ major = (mvr OMAP_UART_MVR_MAJ_MASK)
+ OMAP_UART_MVR_MAJ_SHIFT;
+ minor = (mvr OMAP_UART_MVR_MIN_MASK);
+ break;
+ default:
+ dev_warn(up-pdev-dev,
+ Unknown %s revision, defaulting to highest\n,
+ up-name);
+ /* highest possible revision */
+ major = 0xff;
+ minor = 0xff;
+ }
+
+ /* normalize revision for the driver */
+ revision = UART_BUILD_REVISION(major, minor);
+
+ switch (revision) {
+ case OMAP_UART_REV_46:
+ up-errata |= (UART_ERRATA_i202_MDR1_ACCESS |
+
[PATCH] arm: omap4: hsmmc: check for null pointer
platform_device pdev can be NULL if CONFIG_MMC_OMAP_HS is not set.
Add check for NULL pointer
Fixes the following boot crash seen with omap4sdp and omap4panda
when MMC is disabled.
Unable to handle kernel NULL pointer dereference at virtual address 008c
pgd = c0004000
[008c] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0Not tainted (3.4.0-rc1-05971-ga4dfa82 #4)
PC is at omap_4430sdp_init+0x184/0x410
LR is at device_add+0x1a0/0x664
Signed-off-by: Balaji T K balaj...@ti.com
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|6 +-
arch/arm/mach-omap2/board-omap4panda.c |6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a39fc4b..1ce771d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -526,8 +526,12 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
struct omap2_hsmmc_info *c;
omap_hsmmc_init(controllers);
- for (c = controllers; c-mmc; c++)
+ for (c = controllers; c-mmc; c++) {
+ /* pdev can be null if CONFIG_MMC_OMAP_HS is not set */
+ if (!c-pdev)
+ continue;
omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
+ }
return 0;
}
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d8c0e89..104fd6d 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -278,8 +278,12 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
struct omap2_hsmmc_info *c;
omap_hsmmc_init(controllers);
- for (c = controllers; c-mmc; c++)
+ for (c = controllers; c-mmc; c++) {
+ /* pdev can be null if CONFIG_MMC_OMAP_HS is not set */
+ if (!c-pdev)
+ continue;
omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
+ }
return 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
On 04/03/2012 03:41 PM, AnilKumar, Chimata wrote: Hi Wolfgang, Thanks for reviewing the patch On Tue, Apr 03, 2012 at 18:14:55, Wolfgang Grandegger wrote: On 04/03/2012 02:32 PM, AnilKumar Ch wrote: This patch adds the support for Bosch D_CAN controller. Bosch D_CAN controller is a full-CAN implementation compliant to CAN protocol version 2.0 part A and B. Bosch D_CAN user manual can be obtained from: http://www.semiconductors.bosch.de/media/ en/pdf/ipmodules_1/can/d_can_users_manual_111.pdf D_CAN device is used on many SoCs like AM335x, DM8148 and DM813x EVMs from TI, D_CAN details on AM335x can be accessed from: http://www.ti.com/lit/ug/spruh73c/spruh73c.pdf D_CAN can be configurable for 16, 32, 64 and 128 message objects. The driver implementation is based on 64 message objects. Following are the design choices made while writing the controller driver: 1. Interface Register set IF0 has be used for receive and IF1 is used for transmit message objects. 2. Out of the total Message objects available, half of it are kept aside for RX purposes and the rest for TX purposes. 3. NAPI implementation is such that both the TX and RX paths functions in polling mode. Signed-off-by: AnilKumar Ch anilku...@ti.com Please explain why this CAN controller cannot be handled by the existing C_CAN driver, eventually with some extensions. The register layout seems almost identical, at least. Wolfgang. These are the some of the pointers I can say, why I had gone for separate file instead of existing driver: * In case of D_CAN driver we can see all the registers are 32bit length but in case of C_CAN registers are in 16bit length. How many bits in these 32 bit registers are used? * Some of the registers, bit masks are different, so we have to add checks on every API for differentiating the kind of device Which registers are this? Can you give us an example? * In case of D_CAN we have some extra features like direct message RAM access, DMA support, TX/RX pins can be used as GPIO lines (if applicable), more interrupt lines and three sets of interface registers. Which of these features are used in you driver? * Wait timings while init bit set/reset during bit-timing initialization are different in both the cases That's not the hot code path, so some ifs shouldn't hurt. * bittiming configurations are different. see above. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] arm: omap4: hsmmc: check for null pointer
On Tue, Apr 3, 2012 at 7:17 PM, Balaji T K balaj...@ti.com wrote: platform_device pdev can be NULL if CONFIG_MMC_OMAP_HS is not set. Add check for NULL pointer Fixes the following boot crash seen with omap4sdp and omap4panda when MMC is disabled. Unable to handle kernel NULL pointer dereference at virtual address 008c pgd = c0004000 [008c] *pgd= Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 Not tainted (3.4.0-rc1-05971-ga4dfa82 #4) PC is at omap_4430sdp_init+0x184/0x410 LR is at device_add+0x1a0/0x664 Signed-off-by: Balaji T K balaj...@ti.com Reported-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks for the fix Balaji. Tested-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will, Will Deacon will.dea...@arm.com writes: On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote: On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote: It seems that they're both needed to get reliable PMU operation. Without the CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch below ([1]), it seems that we don't generate enough. So it looks like we need them both. I see. Can you please confirm if it is still the case with [1]. Right, ignore my previous comment, I was using a vanilla 3.3 kernel without realising and therefore what I thought were PMU/CTI interrupts were actually just from a timer. Sorry for the confusion. So I've gone back to basics. Here is a branch containing what I believe should be all the patches required for the OMAP4 PMU: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not acceptable. The problem is, trying to boot this on my pandaboard results in a hang (see dmesg below). Even worse, the problem isn't easily bisectable since rebuilding a working image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). Not sure why it hangs for you, but it worked for me both with your branch on v3.3 and merging with v3.4-rc1[1] Below is a Kconfig snippet[2] which I append to my .config after building omap2plus_defconfig in order to build a perf/trace/PMU enabled kernel for my Panda. Kevin [1] # perf stat sleep 1 Performance counter stats for 'sleep 1': 9.582520 task-clock#0.009 CPUs utilized 1 context-switches #0.104 K/sec 0 CPU-migrations#0.000 K/sec 147 page-faults #0.015 M/sec 5096283 cycles#0.532 GHz 607876 stalled-cycles-frontend # 11.93% frontend cycles idle 3285045 stalled-cycles-backend# 64.46% backend cycles idle 2722485 instructions #0.53 insns per cycle #1.21 stalled cycles per insn 259247 branches # 27.054 M/sec 84274 branch-misses # 32.51% of all branches 1.015919088 seconds time elapsed [2] CONFIG_ARCH_OMAP2=n CONFIG_ARCH_OMAP3=n # need to disable OMAP3 for CPU_HAS_PMU support, needed for perf on OMAP4 CONFIG_USB_EHCI_HCD=y CONFIG_USB_NET_SMSC95XX=y CONFIG_PROFILING=y CONFIG_HW_PERF_EVENTS=y CONFIG_PERF_EVENTS=y CONFIG_PERF_COUNTERS=y CONFIG_TRACEPOINTS=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_ENABLE_DEFAULT_TRACERS=y CONFIG_STACK_TRACER=y CONFIG_SCHED_TRACER=y CONFIG_EVENT_POWER_TRACING_DEPRECATED=n -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
On Tue, Apr 03, 2012 at 19:19:32, Marc Kleine-Budde wrote: On 04/03/2012 03:41 PM, AnilKumar, Chimata wrote: Hi Wolfgang, Thanks for reviewing the patch On Tue, Apr 03, 2012 at 18:14:55, Wolfgang Grandegger wrote: On 04/03/2012 02:32 PM, AnilKumar Ch wrote: This patch adds the support for Bosch D_CAN controller. Bosch D_CAN controller is a full-CAN implementation compliant to CAN protocol version 2.0 part A and B. Bosch D_CAN user manual can be obtained from: http://www.semiconductors.bosch.de/media/ en/pdf/ipmodules_1/can/d_can_users_manual_111.pdf D_CAN device is used on many SoCs like AM335x, DM8148 and DM813x EVMs from TI, D_CAN details on AM335x can be accessed from: http://www.ti.com/lit/ug/spruh73c/spruh73c.pdf D_CAN can be configurable for 16, 32, 64 and 128 message objects. The driver implementation is based on 64 message objects. Following are the design choices made while writing the controller driver: 1. Interface Register set IF0 has be used for receive and IF1 is used for transmit message objects. 2. Out of the total Message objects available, half of it are kept aside for RX purposes and the rest for TX purposes. 3. NAPI implementation is such that both the TX and RX paths functions in polling mode. Signed-off-by: AnilKumar Ch anilku...@ti.com Please explain why this CAN controller cannot be handled by the existing C_CAN driver, eventually with some extensions. The register layout seems almost identical, at least. Wolfgang. These are the some of the pointers I can say, why I had gone for separate file instead of existing driver: * In case of D_CAN driver we can see all the registers are 32bit length but in case of C_CAN registers are in 16bit length. How many bits in these 32 bit registers are used? In some cases (D_CAN_TXRQ, D_CAN_INTPND, D_CAN_MSGVAL) I have used all the bits, in some cases used few bits. Roughly I can say that its (higher 16bits) % of usages is similar as compare to 16bits While checking the status of TXRequest registers and INT pending register, which is a hot code path, we have to put if checks for register access. * Some of the registers, bit masks are different, so we have to add checks on every API for differentiating the kind of device Which registers are this? Can you give us an example? I am pointing out some of the resisters * Single registers in case of D_CAN but multiple register in case of C_CAN So masks will change MASK, ARB, INTPND * D_CAN_IFCMD is the combination of COMM request and COMM mask registers * In case of D_CAN we have some extra features like direct message RAM access, DMA support, TX/RX pins can be used as GPIO lines (if applicable), more interrupt lines and three sets of interface registers. Which of these features are used in you driver? Right now I added only CAN functionality, in that I am using two set of interface registers (0 and 1). Based on other features status register are extended, we have to handle those as well. * Wait timings while init bit set/reset during bit-timing initialization are different in both the cases That's not the hot code path, so some ifs shouldn't hurt. * bittiming configurations are different. see above. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP4 TWL6030 uv_to_vsel warning
Dear mailing-list, I am working with the 3.3 kernel on an OMAP4430 with a TWL6030. I have many warning like the following: twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 I would like to clarify this and eventually remove this warning. I have checked omap_twl.c file. It seems that twl6030_uv_to_vsel() function have a special branch when uv is equal to 135 uV and when bigger than 135 uV it print the error message. On the same file I could see that on_volt (and the onlp_volt) are set by default to 1375000 uV for the OMAP4. On the datasheet of the TWL6030 I could see that the level is 1367400 uV. 135 nor than 1375000 are invalid level. Don't you thin that 1375000 and 135 should be the same value ? If we could change the default on_volt (and the onlp_volt) for the OMAP4 to 135 the Warning message will then be removed, and the effective level on the TWL6030 will still stay to 1367400 uV. Any comment are welcome ! Patrick -- 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 0/3] OMAP4: CPUidle: Add coupled idle support
On Tuesday 03 April 2012 10:34 AM, Kevin Hilman wrote: Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: The series adds the coupled cpuidle support for OMAP4 based on the v2 series posted [1]. This makes OMAP4 to support SMP cpuidle and also removes the hard dependency of off-lining CPU1 to trigger deeper C-states. I have put together a branch which is based on 3.3 kernel with Len Browns next branch [2] which has time keeping and other cpuidle patches which will mostly get merged by 3.4-rc1 and rebased coupled idle series from [1]. Thanks for rebasing this. git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/omap4_coupled_cpuidle-rebase This branch by itself seems to work fine. However, when combining with other stuff that has merged for v3.4, it hangs during boot. I haven't yet isolated the problem, but it's easy to reproduce by combining your branch with v3.4-rc1: git checkout -b test/coupled-v3.4 v3.4-rc1 git merge -s recursive -X ours santosh/for_3.5/omap4_coupled_cpuidle-rebase [1] This hangs on boot, and it seems like a coupled state deadlock because commenting out the coupled states in the C-state creation of cpuidle44xx.c makes it boot just fine. I managed to reproduce the issue. Just to ensure that any OMAP changes have not introduced the regression I merged all Tony's pull request on my branch and tried it out. OMAP changes are fine and coupled idle continue to work. Started bisecting the commits. For bisect I have to create a series which is not dependent on Len's cpuidle updates. First round of bisect was not successful so tried one more time. Was very close to narrowing down on commit but then encountered set of commits where either CPUIDLE itself is broken(deeper C-states are not getting attempted) or I get softIRQ 08 pending error. The last bad commit in bisect was ... [8682df25ca9afd3aac30f2c72d00bd98de2118e8] Merge branch 'fortglx/3.4/rtc' of git://git.linaro.org/people/jstultz/linux into timers/core So far looks like, one of below series has introduced a race which is getting highlighted with coupled cpuidle patchset. 9b612fa Merge branch 'fortglx/3.4/clocksource' of git://git.linaro.org/people/jstultz/linux into timers/core 8682df2 Merge branch 'fortglx/3.4/rtc' of git://git.linaro.org/people/jstultz/linux into timers/core 97ac984 Merge branch 'fortglx/3.4/time' of git://git.linaro.org/people/jstultz/linux into timers/core Will try to continue the debug tomorrow. let me know if you find some thing interesting in your day time. 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] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
On 04/03/2012 04:29 PM, AnilKumar, Chimata wrote: Please explain why this CAN controller cannot be handled by the existing C_CAN driver, eventually with some extensions. The register layout seems almost identical, at least. Wolfgang. These are the some of the pointers I can say, why I had gone for separate file instead of existing driver: * In case of D_CAN driver we can see all the registers are 32bit length but in case of C_CAN registers are in 16bit length. How many bits in these 32 bit registers are used? In some cases (D_CAN_TXRQ, D_CAN_INTPND, D_CAN_MSGVAL) I have used all the bits, in some cases used few bits. Roughly I can say that its (higher 16bits) % of usages is similar as compare to 16bits While checking the status of TXRequest registers and INT pending register, which is a hot code path, we have to put if checks for register access. The c_can already has a c_can_read_reg32() function. It's for example used in the rx_poll function. You can make it a function pointer (i.e. pric-read_reg32()) for easy abstraction. * Some of the registers, bit masks are different, so we have to add checks on every API for differentiating the kind of device Which registers are this? Can you give us an example? I am pointing out some of the resisters * Single registers in case of D_CAN but multiple register in case of C_CAN So masks will change MASK, ARB, INTPND * D_CAN_IFCMD is the combination of COMM request and COMM mask registers Maybe you can use the read_reg32 function on both c_can and d_can. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
RE: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tue, Apr 03, 2012 at 00:05:38, Hilman, Kevin wrote: Shilimkar, Santosh santosh.shilim...@ti.com writes: [...] I don't personally like to add features which hardly anybody use and fundamentally broken with full kernel. Let's keep sane defaults, but not make it unreasonable to tweak eaither. I suggest what has already been mentioned. Register both timers, but have the sync timer have a higher rating. On AMxxx where there is no sync timer, GPtimer will be used. This is another good option, I can change the rating of both the timers. With below description and given understanding/discussion/usability of both the timers, we can reverse the rating, 32K-sync counter = 300 GPTIMER = 250 Considering the fact that, 32k-sync counter is more usable than gptimer on OMAP platform. @include/linux/clocksource.h * @rating: rating value for selection (higher is better) * To avoid rating inflation the following * list should give you a guide as to how * to assign your clocksource a rating * 1-99: Unfit for real use * Only available for bootup and testing purposes. * 100-199: Base level usability. * Functional for real use, but not desired. * 200-299: Good. * A correct and usable clocksource. * 300-399: Desired. * A reasonably fast and accurate clocksource. * 400-499: Perfect * The ideal clocksource. A must-use where * available. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
On 03.04.2012 14:39, AnilKumar, Chimata wrote: Hi All, Subject line of this patch should be ARM: CAN: d_can: Add support for Bosch D_CAN controller No, the d_can IP core is generally not limited to ARM. can: Add support for Bosch D_CAN controller would be perfectly fine. The correct way is: 1. post your new CAN driver to linux-can ML 2. When the major reviews style fixes are done and the driver is fit for mainline you can post it on ti-omap ML too But an initial cross-posting of this CAN driver to netdev ML and linux-kernel ML does not help anyone - it only increases traffic confusion. See MAINTAINERS: http://lxr.linux.no/#linux+v3.3.1/MAINTAINERS#L1710 Thanks for following these hints, Oliver -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
On Tue, Apr 03, 2012 at 21:03:40, Marc Kleine-Budde wrote: On 04/03/2012 04:29 PM, AnilKumar, Chimata wrote: Please explain why this CAN controller cannot be handled by the existing C_CAN driver, eventually with some extensions. The register layout seems almost identical, at least. Wolfgang. These are the some of the pointers I can say, why I had gone for separate file instead of existing driver: * In case of D_CAN driver we can see all the registers are 32bit length but in case of C_CAN registers are in 16bit length. How many bits in these 32 bit registers are used? In some cases (D_CAN_TXRQ, D_CAN_INTPND, D_CAN_MSGVAL) I have used all the bits, in some cases used few bits. Roughly I can say that its (higher 16bits) % of usages is similar as compare to 16bits While checking the status of TXRequest registers and INT pending register, which is a hot code path, we have to put if checks for register access. The c_can already has a c_can_read_reg32() function. It's for example used in the rx_poll function. You can make it a function pointer (i.e. pric-read_reg32()) for easy abstraction. This won't fit for D_CAN case because offsets are different in c_can compared to d_can. For example if I read CONTROL_REG register (0x0) in case of d_can, which will read only control register. In case of c_can it will read CONTROL_REG + STATUS register values in single read * Some of the registers, bit masks are different, so we have to add checks on every API for differentiating the kind of device Which registers are this? Can you give us an example? I am pointing out some of the resisters * Single registers in case of D_CAN but multiple register in case of C_CAN So masks will change MASK, ARB, INTPND * D_CAN_IFCMD is the combination of COMM request and COMM mask registers Maybe you can use the read_reg32 function on both c_can and d_can. Above comment applies here as well regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 01/18] 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.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
[PATCHv5 00/18] 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. Tested on omap4sdp and omap3sdp. The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: g...@gitorious.org:linus-tree/linus-tree.git i2c-v5 Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (15): 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 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 | 330 +++- include/linux/i2c-omap.h |1 + 4 files changed, 188 insertions(+), 149 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
[PATCHv5 03/18] 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.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
[PATCHv5 02/18] 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.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
[PATCHv5 04/18] 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,
[PATCHv5 07/18] 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.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
[PATCHv5 10/18] 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.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
[PATCHv5 06/18] 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.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
[PATCHv5 11/18] 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.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
[PATCHv5 13/18] 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.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
[PATCHv5 14/18] 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.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
[PATCHv5 12/18] 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.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
[PATCHv5 15/18] 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;
- }
- }
[PATCHv5 16/18] 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.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
[PATCHv5 09/18] 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.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
[PATCHv5 05/18] I2C: OMAP: Fix the interrupt clearing in OMAP4
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch ...
- Does not use the IRQENABLE_CLR register to clear as it is not mentioned
to be legacy register IRQENABLE_CLR helps in atomically
setting/clearing specific interrupts, instead use the OMAP_I2C_IE_REG as we
are
clearing all interrupts.
Cc: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 45389db..2769f67 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1179,10 +1179,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
_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);
- else
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ 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 */
--
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
[PATCHv5 08/18] 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.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
[PATCHv5 18/18] 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.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
[PATCHv5 17/18] 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.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Tue, Apr 03, 2012 at 03:27:52PM +0100, Kevin Hilman wrote: Hi Will, Hi Kevin, Will Deacon will.dea...@arm.com writes: The problem is, trying to boot this on my pandaboard results in a hang (see dmesg below). Even worse, the problem isn't easily bisectable since rebuilding a working image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). Not sure why it hangs for you, but it worked for me both with your branch on v3.3 and merging with v3.4-rc1[1] Thanks for testing that. It turns out that updating my x-loader (it was pretty ancient) fixed the boot hang, though I'm not sure I want to know why! # perf stat sleep 1 Performance counter stats for 'sleep 1': 9.582520 task-clock#0.009 CPUs utilized 1 context-switches #0.104 K/sec 0 CPU-migrations#0.000 K/sec 147 page-faults #0.015 M/sec 5096283 cycles#0.532 GHz 607876 stalled-cycles-frontend # 11.93% frontend cycles idle 3285045 stalled-cycles-backend# 64.46% backend cycles idle 2722485 instructions #0.53 insns per cycle #1.21 stalled cycles per insn 259247 branches # 27.054 M/sec 84274 branch-misses # 32.51% of all branches Right. Can you confirm whether the PMU/CTI interrupts fire for you please? Just run perf top and look at /proc/interrupts while it's running. You should see a couple of arm-pmu entries in there and hopefully numbers 0. For me, my earlier mis-diagnosis has turned out to be true and I can only see PMU interrupts if I apply the SWSUSP patch, which Santosh says will break pm. Cheers, Will -- 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: [PATCHv5 17/18] I2C: OMAP: Do not set the XUDF if the underflow is not reached
Hi Moiz,
Thanks for your review.
On Tuesday 03 April 2012 09:41 PM, Sonasath, Moiz wrote:
Shubhrajyoti,
On Tue, Apr 3, 2012 at 11:02 AM, Shubhrajyoti D shubhrajy...@ti.com wrote:
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;
I think we should set the NACK|AL err flag here instead??
On return of negative values there is a goto and those flags are set there.
Did I miss something?
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;
Ack for this change.
Thanks.
--
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 05/12] Add dummy smsc911x regulators to cm-t35.
* Igor Grinberg grinb...@compulab.co.il [120330 08:26]: On 03/28/12 19:03, Tony Lindgren wrote: ..care to see if you have OMAP_GPIO_IRQ entry for your board? If so, we're still waiting for the cleanup-fixes branch to get merged that changes things to use gpio_to_irq() instead. Nope, no OMAP_GPIO_IRQ in the board code. Also, the GPIO - IRQ mapping for the smsc911x is done in gpmc-smsc911x.c and it uses gpio_to_irq() already. OK, maybe it's caused by spurious interrupts? Have you checked the GPIO interrupt edge/level setup is correct? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] Add dummy smsc911x regulators to cm-t35.
* Igor Grinberg grinb...@compulab.co.il [120327 23:37]:
On 03/27/12 20:32, Russ Dill wrote:
No objection.
10x Russ.
I've combined patches 5 - 12 into a single patch as they
pretty much do the same thing, and to cut down
the patch noise for fixes. Merging into fixes with the
updated patch below.
Regards,
Tony
From: Russ Dill russ.d...@ti.com
Date: Fri, 23 Mar 2012 02:21:37 -0700
Subject: [PATCH] ARM: OMAP2+: smsc911x: Add fixed board regulators
Initialize fixed regulators in the board files. Trying to
do this in a generic way in gpmc-smsc911x.c gets messy as
the regulator may be provided by drivers, such as twl4030,
for some boards.
Signed-off-by: Russ Dill russ.d...@ti.com
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
[t...@atomide.com: combined into one patch, updated comments]
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 41b0a2f..909a8b9 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -26,6 +26,7 @@
#include linux/i2c/at24.h
#include linux/i2c/twl.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/mmc/host.h
@@ -81,8 +82,23 @@ static struct omap_smsc911x_platform_data
sb_t35_smsc911x_cfg = {
.flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
};
+static struct regulator_consumer_supply cm_t35_smsc911x_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
+static struct regulator_consumer_supply sb_t35_smsc911x_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.1),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.1),
+};
+
static void __init cm_t35_init_ethernet(void)
{
+ regulator_register_fixed(0, cm_t35_smsc911x_supplies,
+ARRAY_SIZE(cm_t35_smsc911x_supplies));
+ regulator_register_fixed(1, sb_t35_smsc911x_supplies,
+ARRAY_SIZE(sb_t35_smsc911x_supplies));
+
gpmc_smsc911x_init(cm_t35_smsc911x_cfg);
gpmc_smsc911x_init(sb_t35_smsc911x_cfg);
}
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index e558800..930c0d3 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -634,8 +634,14 @@ static void __init igep_wlan_bt_init(void)
static inline void __init igep_wlan_bt_init(void) { }
#endif
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
static void __init igep_init(void)
{
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
/* Get IGEP2 hardware revision */
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index d50a562..1b60495 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -22,6 +22,7 @@
#include linux/err.h
#include linux/clk.h
#include linux/spi/spi.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
#include linux/io.h
@@ -410,8 +411,14 @@ static struct mtd_partition ldp_nand_partitions[] = {
};
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
static void __init omap_ldp_init(void)
{
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
ldp_init_smsc911x();
omap_i2c_init();
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index b90b319..49df127 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -623,9 +623,15 @@ static void __init omap3_evm_wl12xx_init(void)
#endif
}
+static struct regulator_consumer_supply dummy_supplies[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
static void __init omap3_evm_init(void)
{
omap3_evm_get_revision();
+ regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
if (cpu_is_omap3630())
omap3_mux_init(omap36x_board_mux, OMAP_PACKAGE_CBB);
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index 4a7d8c8..9b3c141 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -23,6 +23,7 @@
#include linux/io.h
#include linux/gpio.h
+#include linux/regulator/fixed.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
@@ -188,8 +189,14 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
+static struct regulator_consumer_supply dummy_supplies[] = {
+
Re: [PATCH v2] ARM: OMAP2+: Fix omap2+ build error.
* R Sricharan r.sricha...@ti.com [120330 02:00]: With CONFIG_OMAP4_ERRATA_I688 enabled, omap2+ build was broken as below. Thanks applying into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
Hi Oliver, Thanks for the comments, On Tue, Apr 03, 2012 at 21:24:23, Oliver Hartkopp wrote: On 03.04.2012 14:39, AnilKumar, Chimata wrote: Hi All, Subject line of this patch should be ARM: CAN: d_can: Add support for Bosch D_CAN controller No, the d_can IP core is generally not limited to ARM. can: Add support for Bosch D_CAN controller would be perfectly fine. Agree, I will change the subject line in my next version of patch The correct way is: 1. post your new CAN driver to linux-can ML 2. When the major reviews style fixes are done and the driver is fit for mainline you can post it on ti-omap ML too But an initial cross-posting of this CAN driver to netdev ML and linux-kernel ML does not help anyone - it only increases traffic confusion It's true, I will take care from next time onwards Thanks AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: fix section mismatches in usb-host.c
* Felipe Balbi ba...@ti.com [120327 01:57]: On Mon, Mar 26, 2012 at 04:51:10PM +0200, Igor Grinberg wrote: Fix the below section mismatch warning and alike: WARNING: vmlinux.o(.text+0x281d4): Section mismatch in reference from the function setup_ehci_io_mux() to the function .init.text:omap_mux_init_signal() The function setup_ehci_io_mux() references the function __init omap_mux_init_signal(). This is often because setup_ehci_io_mux lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. Signed-off-by: Igor Grinberg grinb...@compulab.co.il Acked-by: Felipe Balbi ba...@ti.com Thanks applying into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
* Govindraj.R govindraj.r...@ti.com [120321 03:06]: 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 all default pads except uart1/3 as most boards tend to use either uart1/3 as console port and use only tx/rx lines, declare only those pads for uart1/3. If any boards tend to use any other uart other uart1/3 the mux data should to passed from board file and init individual uart port using omap_serial_init_port api. This is still wrong. We can't mux any serial pins unless specifically requested from the board-*.c files. So please do a fix to get back to v3.2 behaviour where you basically revert 7496ba3. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] OMAP PM fixes for v3.4-rc
Tony, Please pull the following OMAP PM fixes for v3.4-rc1. Thanks, Kevin The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7: Linux 3.3 (2012-03-18 16:15:34 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/fixes/pm for you to fetch changes up to 4ba7c3c3c6567210bf46b1ab3d089134170c2762: ARM: OMAP3+: fix oops triggered in omap_prcm_register_chain_handler(v1) (2012-03-22 16:11:17 -0700) Mark A. Greer (2): arm: omap3: pm34xx.c: Fix omap3_pm_init() error out paths arm: omap3: pm34xx.c: Replace printk() with appropriate pr_*() Ming Lei (1): ARM: OMAP3+: fix oops triggered in omap_prcm_register_chain_handler(v1) Nishanth Menon (1): ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not present Santosh Shilimkar (1): ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer. arch/arm/mach-omap2/opp.c|4 ++-- arch/arm/mach-omap2/pm34xx.c | 38 -- arch/arm/mach-omap2/pm44xx.c | 10 -- arch/arm/mach-omap2/prm_common.c |2 +- 4 files changed, 31 insertions(+), 23 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 PM fixes for v3.4-rc
* Kevin Hilman khil...@ti.com [120403 11:33]: Tony, Please pull the following OMAP PM fixes for v3.4-rc1. Thanks pulling into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: PM: core support for SMPS regulators for v3.4
* Kevin Hilman khil...@ti.com [120312 16:30]: Mark Brown broo...@opensource.wolfsonmicro.com writes: On Mon, Mar 12, 2012 at 10:26:53AM -0700, Kevin Hilman wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: The branch itself is essentially stable but I'm not enthused about the idea of merging the whole thing via the OMAP tree. Right, I wasn't suggesting we merge it via OMAP tree. I was just looking for a stable point we could use as s dependency when merging everything together for the arm-soc tree. Well, if you don't base the OMAP changes that depend on it off the regulator changes then you'll break bisection as you'll have a bunch of commits which won't have all their dependencies present on a branch (since they're not present in the branch point and aren't otherwise merged in), if bisect goes down that branch it'll be miserable. That seems bad and while I've not run into it with OMAP in particular it's rather painful when it does happen. It's much better if the branch has the required changes merged into it prior to their being used. OK. Tony, updated pull request below. This includes all the TWL depencies merged from the 'topic/twl' tag in Mark's tree. Pulled in this into pm-regulator branch finally. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Will Deacon will.dea...@arm.com writes:
[...]
Right. Can you confirm whether the PMU/CTI interrupts fire for you please?
Just run perf top and look at /proc/interrupts while it's running. You
should see a couple of arm-pmu entries in there and hopefully numbers 0.
Ah, I see now (I'm a perf newbie.)
Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
order to see any interrupts and see anything in perf top. This isn't
really a mergeable workaround, so I'll look into this a little closer
with Santosh to see what we can do once we fully understand the HW
problem.
Kevin
[1]
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags= CLKDM_CAN_HWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
--
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: oprofile and ARM A9 hardware counter
Hi
On Tue, 3 Apr 2012, Kevin Hilman wrote:
Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
order to see any interrupts and see anything in perf top. This isn't
really a mergeable workaround, so I'll look into this a little closer
with Santosh to see what we can do once we fully understand the HW
problem.
Part of the problem is that the clockdomain data for the emu_sys
clockdomain is wrong. Here's something to try to fix it. It might just
be enough to get it to work.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Tue, 3 Apr 2012 17:13:48 -0600
Subject: [PATCH] ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm
CLKTRCTRL data
According to the 4430 ES2.0 TRM vX Table 3-744 CM_EMU_CLKSTCTRL,
the emu_sys clockdomain data in mainline is incorrect.
The emu_sys clockdomain does not support the DISABLE_AUTO state, and
instead it supports the FORCE_WAKEUP state.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/clockdomains44xx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..bd7ed13 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags= CLKDM_CAN_HWSUP,
+ .flags= CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_FORCE_WAKEUP,
};
static struct clockdomain l3_dma_44xx_clkdm = {
--
1.7.9.5
Re: [PATCH 1/2] ARM: OMAP: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
On Mon, 12 Mar 2012, Santosh Shilimkar wrote:
Commit b1cbdb00d{OMAP: clockdomain: Wait for powerdomain to be ON
when using clockdomain force wakeup} was assuming that pwrdm_state_switch()
does wait for the powerdomain transition which is not the case.
Fix this API by adding the pwrdm_wait_transition().
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Rajendra Nayak rna...@ti.com
CC: Paul Walmsley p...@pwsan.com
Thanks, queued for 3.4-rc.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP: powerdomain: Get rid off duplicate pwrdm_clkdm_state_switch() API
On Mon, 12 Mar 2012, Santosh Shilimkar wrote: With patch 'ARM: OMAP: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()', the pwrdm_clkdm_state_switch() API becomes duplicate of pwrdm_state_switch(). Get rid off duplicate pwrdm_clkdm_state_switch() and update the users of it with pwrdm_state_switch() Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com CC: Rajendra Nayak rna...@ti.com CC: Paul Walmsley p...@pwsan.com Thanks, queued for 3.5. - 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: oprofile and ARM A9 hardware counter
On Tue, 3 Apr 2012, Will Deacon wrote: I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). Might be worth booting with initcall_debug on the kernel command line. That will probably be easier than dealing with JTAG. - 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: oprofile and ARM A9 hardware counter
On Wed, Apr 4, 2012 at 7:29 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Tue, 3 Apr 2012, Kevin Hilman wrote:
Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
order to see any interrupts and see anything in perf top. This isn't
really a mergeable workaround, so I'll look into this a little closer
with Santosh to see what we can do once we fully understand the HW
problem.
Part of the problem is that the clockdomain data for the emu_sys
clockdomain is wrong. Here's something to try to fix it. It might just
be enough to get it to work.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Tue, 3 Apr 2012 17:13:48 -0600
Subject: [PATCH] ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm
CLKTRCTRL data
According to the 4430 ES2.0 TRM vX Table 3-744 CM_EMU_CLKSTCTRL,
the emu_sys clockdomain data in mainline is incorrect.
The emu_sys clockdomain does not support the DISABLE_AUTO state, and
instead it supports the FORCE_WAKEUP state.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/clockdomains44xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..bd7ed13 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_FORCE_WAKEUP,
I tested the patch just now, but unfortunately, the change still doesn't make
PMU to generate IRQs.
Mark the flags as CLKDM_CAN_SWSUP may work, but PMU will stop producing
IRQs after resuming from suspend.
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
RE: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
-Original Message- From: linux-can-ow...@vger.kernel.org [mailto:linux-can- ow...@vger.kernel.org] On Behalf Of AnilKumar, Chimata Sent: Tuesday, April 03, 2012 9:28 PM To: Marc Kleine-Budde Cc: Wolfgang Grandegger; socket...@hartkopp.net; m.kleine- bu...@pengutronix.de; linux-...@vger.kernel.org; net...@vger.kernel.org; linux-omap@vger.kernel.org; linux- ker...@vger.kernel.org; Gole, Anant; Nori, Sekhar Subject: RE: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller On Tue, Apr 03, 2012 at 21:03:40, Marc Kleine-Budde wrote: On 04/03/2012 04:29 PM, AnilKumar, Chimata wrote: Please explain why this CAN controller cannot be handled by the existing C_CAN driver, eventually with some extensions. The register layout seems almost identical, at least. Wolfgang. These are the some of the pointers I can say, why I had gone for separate file instead of existing driver: * In case of D_CAN driver we can see all the registers are 32bit length but in case of C_CAN registers are in 16bit length. How many bits in these 32 bit registers are used? In some cases (D_CAN_TXRQ, D_CAN_INTPND, D_CAN_MSGVAL) I have used all the bits, in some cases used few bits. Roughly I can say that its (higher 16bits) % of usages is similar as compare to 16bits While checking the status of TXRequest registers and INT pending register, which is a hot code path, we have to put if checks for register access. The c_can already has a c_can_read_reg32() function. It's for example used in the rx_poll function. You can make it a function pointer (i.e. pric-read_reg32()) for easy abstraction. This won't fit for D_CAN case because offsets are different in c_can compared to d_can. For example if I read CONTROL_REG register (0x0) in case of d_can, which will read only control register. In case of c_can it will read CONTROL_REG + STATUS register values in single read C_CAN core has both 16-bit as well as 32-bit registers. While the registers like NEWDATA and INTPND are 32-bit the others like Control and Status are 16-bit. These cases are handled by the present C_CAN driver already. If you will see the C_CAN driver then you will see that the normal read/write operations are 16-bit whereas a special variant is provided for 32-bit access. Are you sure you cannot use them as it is? * Some of the registers, bit masks are different, so we have to add checks on every API for differentiating the kind of device Which registers are this? Can you give us an example? I am pointing out some of the resisters * Single registers in case of D_CAN but multiple register in case of C_CAN So masks will change MASK, ARB, INTPND * D_CAN_IFCMD is the combination of COMM request and COMM mask registers Maybe you can use the read_reg32 function on both c_can and d_can. Above comment applies here as well This can be easily handled. I have worked on several drivers that do that. See for example the STMPE multi-function device driver (MFD), here [1] There are various variants of STMPE devices (like STMPE801 etc..) and they can be handled by using a common driver and passing different platform data intelligently that provides specific handling for a specific STMPE device. Regards, Bhupesh [1] http://lxr.linux.no/linux+v3.3.1/drivers/mfd/stmpe.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3EVM not booting on l-o master
Hi, OMAP3EVM is not booting on l-o master, with default configuration, HEAD @33fc21e Linux-omap rebuilt: Updated to v3.4-rc1, merged in most of pending branches. It was booting on l-o master two weeks old with same setup. Any clues on resolving this issue ? Regards Afzal Logs as follows, Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc1-11705-g33fc21e (af...@linux-psp-server.india.ext.ti.com) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Wed Apr 4 10:27:23 IST 2012 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP3 EVM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c0d0e000 s11456 r8192 d13120 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [0.00] Kernel command line: console=ttyO0,115200n8 root/dev/ram rw earlyprintk mem=128M initrd=0x81338000,0x1f6c2f [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 127MB = 127MB total [0.00] Memory: 114536k/114536k available, 16536k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc880 - 0xff00 ( 872 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc05d2e34 (5932 kB) [0.00] .init : 0xc05d3000 - 0xc0621cc0 ( 316 kB) [0.00] .data : 0xc0622000 - 0xc06b5958 ( 591 kB) [0.00].bss : 0xc06b597c - 0xc0c09be0 (5457 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001129] Calibrating delay loop... 497.82 BogoMIPS (lpj=1941504) [0.085906] pid_max: default: 32768 minimum: 301 [0.086883] Security Framework initialized [0.087249] Mount-cache hash table entries: 512 [0.093780] CPU: Testing write buffer coherency: ok [0.094970] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.095092] Setting up static identity map for 0x804278b8 - 0x80427928 [0.097442] Brought up 1 CPUs [0.097473] SMP: Total of 1 processors activated (497.82 BogoMIPS). [0.124389] dummy: [0.127258] NET: Registered protocol family 16 [0.128936] GPMC revision 5.0 [0.143035] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [0.143737] OMAP GPIO hardware version 2.5 [0.145141] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [0.147125] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [0.149536] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [0.151428] gpiochip_add: registered GPIOs 128 to 159 on device: gpio [0.153320] gpiochip_add: registered GPIOs 160 to 191 on device: gpio [0.163635] omap_mux_init: Add partition: #1: core, flags: 0 [0.182525] Reprogramming SDRC clock to 33200 Hz [0.290496] hw-breakpoint: debug architecture 0x4 unsupported. [0.310638] omap-mcbsp.2: alias fck already exists [0.311676] omap-mcbsp.3: alias fck already exists [0.318115] OMAP DMA hardware revision 4.0 [0.409606] bio: create slab bio-0 at 0 [0.414764] dummy: [0.414947] dummy: Failed to create debugfs directory [0.422912] SCSI subsystem initialized [0.425506] omap2_mcspi omap2_mcspi.1: master is unqueued, this is deprecated [0.429168] omap2_mcspi omap2_mcspi.2: master is unqueued, this is deprecated [0.431213]
