Re: [PATCH for 3.4] MFD: twl6040: Convert to i2c driver, and separate it from twl core
Hi Samuel, Liam, Tony,
Now rc2 is out, and the the OMAP4 audio is still broken.
Can you please queue this patch for 3.4?
The patch applies on top of mainline cleanly, and I also pushed a new
branch just in case:
The following changes since commit f549e088b806f44b6ab6eeef0cb71ced1d2488dd:
Merge tag 'rdma-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
(2012-04-11 13:24:52 -0700)
are available in the git repository at:
g...@gitorious.org:omap-audio/linux-audio.git peter/upstream/for-3.4-rc3
Peter Ujfalusi (1):
MFD: twl6040: Convert to i2c driver, and separate it from twl core
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(-)
Thank you very much,
Péter
On 04/03/2012 11:56 AM, Peter Ujfalusi wrote:
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=
Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver
On Thursday 12 April 2012 08:30 AM, Greg KH wrote: On Wed, Apr 11, 2012 at 08:44:39PM -0600, Paul Walmsley wrote: Cc Mark Greer, Mark Salter Hi Greg, Aneesh, On Sat, 17 Mar 2012, Aneesh V wrote: Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. Just checking to see what the current state of this series is. Greg, are you considering this for merging, or are there remaining issues? Aneesh, do you have any remaining issues to resolve with this set? What about the review comment about devfreq? Devfreq is not suitable for this driver. I already replied on this thread [1] Acting on frequency change is just one function of the controller driver and that too need not bed to attached with devfreq. The driver has features like temperature handling as per JDEC specs, active power managements modes, system wide suspend power management like self refresh and also configuration which can help memory hotplug for power savings and initialising the DDR timings to avoid boot-loader defaults.The controller IP works in conjunction with PRCM (OMAP Power IP) block to achieve some of this functionality. I was hoping that we will have some thing like drivers/memory/* but since it doesn't exist, we used drivers/misc. Regards Santosh [1] https://lkml.org/lkml/2012/3/19/178 This is useful not only for OMAP4 and AM3517/3505, but also will probably be useful for the C6x chips that Mark Salter is working on. It's still in my to-review queue, that I'm slowly making my way through. So it's not lost, but I would like to get the devfreq interface question cleared up first. Let us know if you need more clarification on devfreq part. Thanks for looking into it. 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 3/9] ARM: at91: add at91sam9g20ek boards dt support
+ omap ml
Hi Jean, Andrew, Nicolas,
On Wed, Apr 11, 2012 at 21:31:13, Jean-Christophe PLAGNIOL-VILLARD wrote:
+ ahb {
+ apb {
+ dbgu: serial@f200 {
+ status = okay;
+ };
+
+ usart0: serial@fffb {
+ status = okay;
+ };
+
+ usart1: serial@fffb4000 {
+ status = okay;
+ };
+
+ macb0: ethernet@fffc4000 {
+ phy-mode = rmii;
+ status = okay;
+ };
+
+ usb1: gadget@fffa4000 {
+ atmel,vbus-gpio = pioC 5 0;
+ status = okay;
+ };
+ };
+
+ nand0: nand@4000 {
+ nand-bus-width = 8;
+ nand-ecc-mode = soft;
+ nand-on-flash-bbt;
+ status = okay;
I have a few queries about handling static memory controller (SMC) of ATMEL
1. How is SMC configured when DT is used ?
2. With d6a0166 atmel/nand: add DT support, ek_add_device_nand() is no more
present (which was earlier configuring SMC), so is SMC configuration handled
by Kernel on DT boot or is it done by bootloader when DT ?
3. How ek_add_device_dm9000() is going to be achieved with DT ?
4. Is there any plan to create a driver out of SMC code use DT with it ?
Reason for bringing these queries is that TI OMAP chips have GPMC [1], SMC in
ATMEL
seems somewhat similar and currently GPMC is configured in platform code,
we are creating a driver out of that code [2]. There are different views on
where
GPMC driver should go, mfd, misc folders etc, but could not yet get concrete
suggestions even with a loud cry.
If ATMEL is also going driver way, then probably our voice together may be
heard and hopefully it will expedite the matter.
Regards
Afzal
[1]
GPMC (General Purpose Memory Controller) in brief:
GPMC is an unified memory controller dedicated to interfacing external
memory devices like
Asynchronous SRAM like memories and application specific integrated circuit
devices.
Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash
Pseudo-SRAM devices
GPMC has to be configured as required by timings of the connected
peripheral. It needs to be configured only initially. Once it is
configured it can be used to handle different protocols like NAND,
NOR. Various kinds of devices like ethernet, uart, usb, fpga etc
can work using GPMC interface. GPMC has a seperate additional
functionality of NAND handling
[2] https://lkml.org/lkml/2012/4/5/210
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] Input: omap-keypad: dynamically handle register offsets
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Tested on omap4430 sdp with 3.4-rc2.
Tested on omap5430evm with 3.1-custom kernel.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Changes since v1:
- Fix Felipe's comment about getting rid
of one argument from irqstatus/irqenable api
- Fix Dmitry's comment:
- get rid of revision check in readl/writel
- Relace ENODEV with proper macro.
- Use switch statement
drivers/input/keyboard/Kconfig|6 +-
drivers/input/keyboard/omap4-keypad.c | 115 ++---
2 files changed, 95 insertions(+), 26 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index f354813..9a0e1a9 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -511,10 +511,10 @@ config KEYBOARD_OMAP
To compile this driver as a module, choose M here: the
module will be called omap-keypad.
-config KEYBOARD_OMAP4
- tristate TI OMAP4 keypad support
+config KEYBOARD_OMAP4+
+ tristate TI OMAP4+ keypad support
help
- Say Y here if you want to use the OMAP4 keypad.
+ Say Y here if you want to use the OMAP4+ keypad.
To compile this driver as a module, choose M here: the
module will be called omap4-keypad.
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index e809ac0..8e46563 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -68,6 +68,11 @@
#define OMAP4_MASK_IRQSTATUSDISABLE0x
+enum {
+ KBD_REVISION_OMAP4 = 0,
+ KBD_REVISION_OMAP5,
+};
+
struct omap4_keypad {
struct input_dev *input;
@@ -76,11 +81,61 @@ struct omap4_keypad {
unsigned int rows;
unsigned int cols;
+ unsigned int revision;
+ u32 irqstatus;
+ u32 irqenable;
+ u32 reg_offset;
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_read_irqstatus(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base + offset);
+}
+
+static int kbd_write_irqstatus(struct omap4_keypad *keypad_data,
+ u32 value)
+{
+ return __raw_writel(value, keypad_data-base + keypad_data-irqstatus);
+}
+
+static int kbd_write_irqenable(struct omap4_keypad *keypad_data,
+ u32 value)
+{
+ return __raw_writel(value, keypad_data-base + keypad_data-irqenable);
+}
+
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base +
+ keypad_data-reg_offset + offset);
+}
+
+static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32 value)
+{
+ __raw_writel(value, keypad_data-base +
+ keypad_data-reg_offset + offset);
+}
+
+static int kbd_read_revision(struct omap4_keypad *keypad_data, u32 offset)
+{
+ int reg;
+ reg = __raw_readl(keypad_data-base + offset);
+ reg = 0x03 30;
+ reg = 30;
+
+ switch (reg) {
+ case 1:
+ return KBD_REVISION_OMAP5;
+ case 0:
+ return KBD_REVISION_OMAP4;
+ default:
+ return -EINVAL;
+ }
+}
+
/* Interrupt handler */
static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
{
@@ -91,12 +146,10 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
u32 *new_state = (u32 *) key_state;
/* Disable interrupts */
- __raw_writel(OMAP4_VAL_IRQDISABLE,
-keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqenable(keypad_data, OMAP4_VAL_IRQDISABLE);
- *new_state = __raw_readl(keypad_data-base + OMAP4_KBD_FULLCODE31_0);
- *(new_state + 1) = __raw_readl(keypad_data-base
- + OMAP4_KBD_FULLCODE63_32);
+ *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
+ *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
for (row = 0; row keypad_data-rows; row++) {
changed = key_state[row] ^ keypad_data-key_state[row];
@@ -121,12 +174,12 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
sizeof(keypad_data-key_state));
/* clear pending interrupts */
- __raw_writel(__raw_readl(keypad_data-base + OMAP4_KBD_IRQSTATUS),
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
+ kbd_write_irqstatus(keypad_data,
+ kbd_read_irqstatus(keypad_data, keypad_data-irqstatus));
/* enable interrupts */
-
Re: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
Hello Vaibhav, On Fri, 30 Mar 2012, Vaibhav Hiremath wrote: After some healthy discussion, now we have come to the conclusion and decided to handle AM33XX PRM/CM part separately; as AM33XX-PRCM module is different than OMAP3 and OMAP4 architecture. Have been reviewing these patch sets here. Are these associated with any board file? I had to hand-apply several patch sets due to some differences in mach-omap2/io.c. Upon looking more closely, and looking at your GitHub branch: https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm it seems that internally you've been modifying the AM3517 EVM board file to test the BeagleBone? But due to the init_early changes, this is presumably not going to work if we want to keep the AM3517EVM working -- is this your understanding as well? I'm kind of wondering how we're to test these... ... BTW, the branch that I'm experimenting with is at git://git.pwsan.com/linux-2.6 -- branch name 'am33xx_support_3.5' -- I am still reviewing the patches there. - 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 for 3.4] MFD: twl6040: Convert to i2c driver, and separate it from twl core
Hi Peter, On Thu, Apr 12, 2012 at 09:39:28AM +0300, Peter Ujfalusi wrote: Hi Samuel, Liam, Tony, Now rc2 is out, and the the OMAP4 audio is still broken. Can you please queue this patch for 3.4? I'm busy this week, but I'll queue this one up beginning of next week. I have several MFD fixes pending, so I'll send a pull request before rc4 I hope. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP2+: dmtimer: remove redundant sysconfig context restore
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
v2: removed tiocp_cfg from struct timer_regs {}
arch/arm/plat-omap/dmtimer.c |2 --
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 652139c..15e7882 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -82,8 +82,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- __raw_writel(timer-context.tiocp_cfg,
- timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
if (timer-revision == 1)
__raw_writel(timer-context.tistat, timer-sys_stat);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 9418f00..a4c08d0 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -75,7 +75,6 @@ struct clk;
struct timer_regs {
u32 tidr;
- u32 tiocp_cfg;
u32 tistat;
u32 tisr;
u32 tier;
--
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] mmc: omap_hsmmc: set dto to 14 for all devices
On 04/06/2012 05:24 AM, Chris Ball wrote: Hi Paul, On Thu, Apr 05 2012, Paul Walmsley wrote: I'm really sorry for the long delay! On Thu, 5 Apr 2012, Chris Ball wrote: Thanks. Paul, just waiting for your Signed-off-by. Signed-off-by: Paul Walmsley p...@pwsan.com Thanks, no problem! Pushed to mmc-next for 3.4. - Chris. With this patch, I continuously get following message on my console. (Tested on Origen board, based on EXYNOS4210). mmc0: Too large timeout requested for CMD25! So, with this change, should we update sdhci_calc_timeout() also? -- Tushar Behera -- To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP2+: dmtimer: remove redundant sysconfig context restore
On Thursday 12 April 2012 03:13 PM, Tarun Kanti DebBarma wrote:
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
v2: removed tiocp_cfg from struct timer_regs {}
Acked-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: [PATCH] iommu: OMAP: device detach on domain destroy
On Fri, Mar 30, 2012 at 11:03:49AM -0500, Omar Ramirez Luna wrote: 'domain_destroy with devices attached' case isn't yet handled, instead code assumes that the device was already detached. If the domain is destroyed the hardware still has access to invalid pointers to its page table and internal iommu object. In order to detach the users we need to track devices using the iommu, current use cases only have one user of iommu per instance. When required this can evolve to a list with the devices using the iommu_dev. Reported-by: Joerg Roedel j...@8bytes.org Reviewed-by: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org Doesn't apply against 3.4-rc2. Please rebase and send a new version. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: OMAP4: Remove un-used control module headers and defines.
Benoit, On Monday 27 February 2012 04:02 PM, Santosh Shilimkar wrote: Most of the OMAP4 control module register defines are not used and can be removed. Keep only needed defines and move them to common control module header just like other OMAP versions. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- What do you think about this patch ? 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: PM related performance degradation on OMAP3
On 2012-04-11 13:17, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: [...] I fear I'm seeing similar problems with 3.3. I have my board (similar to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network performance on 3.3. For example, if I use TFTP to download a large file (~35MB), I get this: 3.0: 42.5 sec 3.3: 625.0 sec That's a factor of 15 worse! This might not be the same problem. What is the NIC being used, and does it have GPIO interrupts? My board uses SMSC911x with GPIO interrupt signal. If it's using GPIO interrupts, then you likely need this patch from mainline (v3.4-rc1) I tried to just pick up the patch you [sort of] quoted below, but had a hard time applying it to my kernel. I've tried to just pick up the latest files from the mainline kernel, but so far I've nothing that builds - too many dependencies. These are the files I've pulled in # modified: arch/arm/mach-omap2/cpuidle34xx.c # modified: arch/arm/mach-omap2/gpio.c # modified: arch/arm/mach-omap2/pm34xx.c # modified: arch/arm/plat-omap/include/plat/gpio.h # modified: drivers/gpio/gpio-omap.c but it fails with these errors: /local/linux-3.3/arch/arm/mach-omap2/pm34xx.c:34:29: error: asm/system_misc.h: No such file or directory /local/linux-3.3/arch/arm/mach-omap2/pm34xx.c: In function 'omap3_pm_init': /local/linux-3.3/arch/arm/mach-omap2/pm34xx.c:744: error: 'omap_pm_clkdms_setup' undeclared (first use in this function) /local/linux-3.3/arch/arm/mach-omap2/pm34xx.c:744: error: (Each undeclared identifier is reported only once /local/linux-3.3/arch/arm/mach-omap2/pm34xx.c:744: error: for each function it appears in.) /local/linux-3.3/arch/arm/mach-omap2/pm34xx.c:767: error: 'arm_pm_idle' undeclared (first use in this function) Is this a viable path towards getting the GPIO changes into my kernel? It's hard for me to update the whole kernel as there are some other dependencies (OMAP3ISP and video in particular), so I'd like to stay with this 3.3-ish base. Thanks for any ideas If that doesn't work, or you're not using GPIO interrupts, could you confirm if the patch below[2] (based on idea from Grasvydas) increases performance for you when CONFIG_PM=y. Kevin [1] Author: Kevin Hilmankhil...@ti.com 2012-03-05 15:10:04 Committer: Grant Likelygrant.lik...@secretlab.ca 2012-03-12 09:16:11 Parent: 25db711df3258d125dc1209800317e5c0ef3c870 (gpio/omap: Fix IRQ handling for SPARSE_IRQ) Child: 8805f410e4fb88a56552c1af42d61b38837a38fd (gpio/omap: Fix section warning for omap_mpuio_alloc_gc()) Branches: many (66) Follows: v3.3-rc7 Precedes: v3.4-rc1 gpio/omap: fix wakeups on level-triggered GPIOs While both level- and edge-triggered GPIOs are capable of generating interrupts, only edge-triggered GPIOs are capable of generating a module-level wakeup to the PRCM (c.f. 34xx NDA TRM section 25.5.3.2.) In order to ensure that devices using level-triggered GPIOs as interrupts can also cause wakeups (e.g. from idle), this patch enables edge-triggering for wakeup-enabled, level-triggered GPIOs when a GPIO bank is runtime-suspended (which also happens during idle.) This fixes a problem found in GPMC-connected network cards with GPIO interrupts (e.g. smsc911x on Zoom3, Overo, ...) where network booting with NFSroot was very slow since the GPIO IRQs used by the NIC were not generating PRCM wakeups, and thus not waking the system from idle. NOTE: until v3.3, this boot-time problem was somewhat masked because the UART init prevented WFI during boot until the full serial driver was available. Preventing WFI allowed regular GPIO interrupts to fire and this problem was not seen. After the UART runtime PM cleanups, we no longer avoid WFI during boot, so GPIO IRQs that were not causing wakeups resulted in very slow IRQ response times. Tested on platforms using level-triggered GPIOs for network IRQs using the SMSC911x NIC: 3530/Overo and 3630/Zoom3. Reported-by: Tony Lindgrent...@atomide.com Tested-by: Tarun Kanti DebBarmatarun.ka...@ti.com Tested-by: Tony Lindgrent...@atomide.com Signed-off-by: Kevin Hilmankhil...@ti.com Signed-off-by: Grant Likelygrant.lik...@secretlab.ca [2] diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 413aac4..ace4bf6 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -120,7 +120,10 @@ static int __omap3_enter_idle(struct cpuidle_device *dev, cpu_pm_enter(); /* Execute ARM wfi */ - omap_sram_idle(); + if (index == 0) + cpu_do_idle(); + else + omap_sram_idle(); /* * Call idle CPU PM enter notifier chain to restore -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More
[PATCH 0/2] ARM: mm: Add v7_flush_dcache_by_level() API
Couple of patches on the ARMv7 cache code. First patch adds v7_flush_dcache_by_level() API and second patch updates the setup function to use the same. R Sricharan (1): ARM: mm: Add v7_flush_dcache_by_level() API. Santosh Shilimkar (1): ARM: mm: Flush only CPU local cache instead of all cache levels. arch/arm/mm/cache-v7.S | 56 ++- arch/arm/mm/proc-v7.S |3 +- 2 files changed, 47 insertions(+), 12 deletions(-) -- 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
[PATCH 1/2] ARM: mm: Add v7_flush_dcache_by_level() API.
From: R Sricharan r.sricha...@ti.com
On ARMv7 based SOC with an integrated L2 cache, there is a need
to have a flush API to operate on each cache level. In few low
power modes, L2 cache is retained where as L1 is lost. The current
v7_flush_dcache_all(), flushes all the levels and it would be quite
expensive.
So introduce v7_flush_dcache_by_level() API which takes a
parameter (cache level), and flush only on that level.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/cache-v7.S | 56 ++-
1 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index a655d3d..cbeff42 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -43,12 +43,32 @@ ENDPROC(v7_flush_icache_all)
*/
ENTRY(v7_flush_dcache_all)
dmb @ ensure ordering with previous
memory accesses
+ mov r8, lr @ store lr
mrc p15, 1, r0, c0, c0, 1 @ read clidr
andsr3, r0, #0x700 @ extract loc from clidr
mov r3, r3, lsr #23 @ left align loc bit field
beq finished@ if loc is 0, then no need to
clean
mov r10, #0 @ start clean at cache level 0
loop1:
+ bl v7_flush_dcache_current_level
+skip:
+ add r10, r10, #2@ increment cache number
+ cmp r3, r10 @
+ bgt loop1
+finished:
+ mov r10, #0 @ swith back to cache level 0
+ mcr p15, 2, r10, c0, c0, 0 @ select current cache level in
cssr
+ dsb
+ isb
+ mov pc, r8 @ restore lr
+ENDPROC(v7_flush_dcache_all)
+/*
+ * v7_flush_dcache_current_level()
+ *
+ * Flush the D-cache by specifed level like l1, l2 etc.
+ * Corrupted registers: r0-r7, r9-r11 (r6 only in Thumb mode)
+ */
+ENTRY(v7_flush_dcache_current_level)
add r2, r10, r10, lsr #1@ work out 3x current cache
level
mov r1, r0, lsr r2 @ extract cache type bits from
clidr
and r1, r1, #7 @ mask of the bits for current
cache only
@@ -84,17 +104,31 @@ loop3:
bge loop3
subsr7, r7, #1 @ decrement the index
bge loop2
-skip:
- add r10, r10, #2@ increment cache number
- cmp r3, r10
- bgt loop1
-finished:
+ mov pc, lr
+ENDPROC(v7_flush_dcache_current_level)
+
+/*
+ * v7_flush_dcache_by_level()
+ * r0 - cache level to be flushed
+ *
+ * Flush the D-cache by specifed level like l1, l2 etc.
+ * Corrupted registers: r0-r7, r9-r11 (r6 only in Thumb mode)
+ */
+ENTRY(v7_flush_dcache_by_level)
+ dmb @ ensure ordering with previous
memory accesses
+ mov r8, lr @ store the lr
+ mov r10, r0 @ temp storage
+ sub r10, r10, #1
+ mov r10, r10, lsl #1
+ mrc p15, 1, r0, c0, c0, 1 @ read clidr
+ bl v7_flush_dcache_current_level
+finished1:
mov r10, #0 @ swith back to cache level 0
mcr p15, 2, r10, c0, c0, 0 @ select current cache level in
cssr
dsb
isb
- mov pc, lr
-ENDPROC(v7_flush_dcache_all)
+ mov pc, r8 @ restore lr
+ENDPROC(v7_flush_dcache_by_level)
/*
* v7_flush_cache_all()
@@ -108,14 +142,14 @@ ENDPROC(v7_flush_dcache_all)
*
*/
ENTRY(v7_flush_kern_cache_all)
- ARM( stmfd sp!, {r4-r5, r7, r9-r11, lr})
- THUMB(stmfd sp!, {r4-r7, r9-r11, lr})
+ ARM( stmfd sp!, {r4-r5, r7-r11, lr})
+ THUMB(stmfd sp!, {r4-r11, lr} )
bl v7_flush_dcache_all
mov r0, #0
ALT_SMP(mcr p15, 0, r0, c7, c1, 0) @ invalidate I-cache inner
shareable
ALT_UP(mcr p15, 0, r0, c7, c5, 0) @ I+BTB cache invalidate
- ARM( ldmfd sp!, {r4-r5, r7, r9-r11, lr})
- THUMB(ldmfd sp!, {r4-r7, r9-r11, lr})
+ ARM( ldmfd sp!, {r4-r5, r7-r11, lr})
+ THUMB(ldmfd sp!, {r4-r11, lr} )
mov pc, lr
ENDPROC(v7_flush_kern_cache_all)
--
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
[PATCH 2/2] ARM: mm: Flush only CPU local cache instead of all cache levels.
The ARMv7 processor setup functions clean and invalidates the
cpu cache before enabling MMU. The intention here is to start
with clean CPU local cache.
But on architectures like Cortex-[A15/A8], this code will end
up flushing the L2 cache as well which undesirable and incorrect.
The setup functions are used in CPU hotplug scenario's too and
hence flushing all cache levels should be avoided.
Fix this code by restricting the cache flush to local cpu
cache or L1.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/proc-v7.S |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index f1c8486..96cfc31 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -172,7 +172,8 @@ __v7_ca15mp_setup:
__v7_setup:
adr r12, __v7_setup_stack @ the local stack
stmia r12, {r0-r5, r7, r9, r11, lr}
- bl v7_flush_dcache_all
+ mov r0, #0x1
+ bl v7_flush_dcache_by_level
ldmia r12, {r0-r5, r7, r9, r11, lr}
mrc p15, 0, r0, c0, c0, 0 @ read main ID register
--
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
Re: Suspend broken on 3.3?
On Thu, Apr 12, 2012 at 1:04 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
a few brief comments based on a quick scan:
On Wed, 11 Apr 2012, Raja, Govindraj wrote:
Here is the patch [1] to do the same.
- I don't see where it affects I/O wakeups for the UART. If I/O wakeups
are still set on the UART pads, won't that still wake the chip up from
suspend, even if module-level wakeups are disabled?
pdata-enable_wakeup = omap_uart_enable_wakeup
was disabling both module level and pad wakeup.
omap_uart_enable_wakeup = has enabling/disabling both
module level and pad wakeup together.
- The UART driver and integration code should not be reading from or
writing to registers outside the UART IP block. PRM register reads and
writes belong in the PRM code, which should then export a higher-level
interface to the calling code. This is because, aside from making the
code easier to read and debug, we're trying to move the PRM and CM code to
drivers/.
okay.
- The code to change the PM_WKEN* and test the PM_WKST* bits should
probably be called from omap_hwmod_{enable,disable}_wakeup(), not the UART
code directly. The UART code shouldn't need to care about the hardware
details; it should just ask the integration layer to enable or disable
module-level wakeups.
To implement this I plan to extend the omap_hwmod_omap2_prcm structure
like this:
(unaligned tmp code snippet)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8070145..5c7711b 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -343,6 +343,8 @@ struct omap_hwmod_class_sysconfig {
* @idlest_reg_id: IDLEST register ID (e.g., 3 for CM_IDLEST3)
* @idlest_idle_bit: register bit shift for CM_IDLEST slave idle bit
* @idlest_stdby_bit: register bit shift for CM_IDLEST master standby bit
+ * @module_wakeup_offs: PRCM register offset for PM_WKEN
+ * @module_wakeup_bit: regiter bit mask for PM_WKEN
*
* @prcm_reg_id and @module_bit are specific to the AUTOIDLE, WKST,
* WKEN, GRPSEL registers. In an ideal world, no extra information
@@ -357,6 +359,8 @@ struct omap_hwmod_omap2_prcm {
u8 idlest_reg_id;
u8 idlest_idle_bit;
u8 idlest_stdby_bit;
+ s16 module_wakeup_offs;
+ u32 module_wakeup_bit;
};
As you work on these changes, please split them up into several different
topic series - one for the PRM changes, one for hwmod code/data changes,
and one for the UART driver/integration changes. Just note the
dependencies in the series description E-mails. That way, we can avoid
merge conflicts.
Yes fine. Since most changes will be on /mach-omap2/omap_hwmod*.c
Do you prefer the patches to be on any particular tree/branch where hwmod fixes
are already queued.
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
On 07:06 Thu 12 Apr , Mohammed, Afzal wrote:
+ omap ml
Hi Jean, Andrew, Nicolas,
On Wed, Apr 11, 2012 at 21:31:13, Jean-Christophe PLAGNIOL-VILLARD wrote:
+ ahb {
+ apb {
+ dbgu: serial@f200 {
+ status = okay;
+ };
+
+ usart0: serial@fffb {
+ status = okay;
+ };
+
+ usart1: serial@fffb4000 {
+ status = okay;
+ };
+
+ macb0: ethernet@fffc4000 {
+ phy-mode = rmii;
+ status = okay;
+ };
+
+ usb1: gadget@fffa4000 {
+ atmel,vbus-gpio = pioC 5 0;
+ status = okay;
+ };
+ };
+
+ nand0: nand@4000 {
+ nand-bus-width = 8;
+ nand-ecc-mode = soft;
+ nand-on-flash-bbt;
+ status = okay;
I have a few queries about handling static memory controller (SMC) of ATMEL
1. How is SMC configured when DT is used ?
2. With d6a0166 atmel/nand: add DT support, ek_add_device_nand() is no more
present (which was earlier configuring SMC), so is SMC configuration handled
by Kernel on DT boot or is it done by bootloader when DT ?
3. How ek_add_device_dm9000() is going to be achieved with DT ?
4. Is there any plan to create a driver out of SMC code use DT with it ?
Reason for bringing these queries is that TI OMAP chips have GPMC [1], SMC in
ATMEL
seems somewhat similar and currently GPMC is configured in platform code,
we are creating a driver out of that code [2]. There are different views on
where
GPMC driver should go, mfd, misc folders etc, but could not yet get concrete
suggestions even with a loud cry.
put me in ccc I'll take a look
If ATMEL is also going driver way, then probably our voice together may be
heard and hopefully it will expedite the matter.
I'm going to add it too my idea was to create something similiar as the
pintrl
you register the ddifferent bank supported buy the SoC and then the driver
request the bank for the dev_name
at soc level you will set the default timings and then the drvier may
manipulate them
I already update the API of sam9_smc to abstract the access to the register.
I expect the code for the request to be generic but handling of the timing IP
specific
Evenif the GPMC is smiliar as the SMC I do not expect a generic API to manage
it easly (for the timings).
Best Regrds,
J
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
Hi Jean, On Thu, Apr 12, 2012 at 17:15:59, Jean-Christophe PLAGNIOL-VILLARD wrote: If ATMEL is also going driver way, then probably our voice together may be heard and hopefully it will expedite the matter. I'm going to add it too my idea was to create something similiar as the pintrl you register the ddifferent bank supported buy the SoC and then the driver request the bank for the dev_name at soc level you will set the default timings and then the drvier may manipulate them I already update the API of sam9_smc to abstract the access to the register. Is SMC code being converted to driver ? Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
wl1271: communication fails with kernel 3.4-rc2 and firmware series 4
I have a problem with WLAN driver wl12xx and 3.4-rc2. I made tests both on AM3517 + W7310 and Pandaboard. Both have wl1271 chip inside. Previous kernels 2.6.37 and 3.3-rc7 made no problem: I could associate with my AP and then reach every host in my LAN. With 3.4-rc2 I can only associate, but IP pings can't be received/sent. This is my discussion on linux-wireless mailing list: http://thread.gmane.org/gmane.linux.kernel.wireless.general/88659 Am I missing some important patches? Can someone try and confirm my observations? Thanks, Yegor -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: OMAP4: Remove un-used control module headers and defines.
Hi Santosh, On 4/12/2012 12:31 PM, Santosh Shilimkar wrote: Benoit, On Monday 27 February 2012 04:02 PM, Santosh Shilimkar wrote: Most of the OMAP4 control module register defines are not used and can be removed. Keep only needed defines and move them to common control module header just like other OMAP versions. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com --- What do you think about this patch ? I'm fine with it. I'm just wondering if we have to send it right now or along with the control module driver implementation we've just started. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: omap: hwmod: Make omap_hwmod_softreset wait for reset status
Hi Paul, On Thursday 12 April 2012 12:29 AM, Paul Walmsley wrote: That approach sounds fine to me, but I don't think Fernando's patch will help with I2C.. Since it uses a custom reset function omap_i2c_reset(), the delay will actually need to go there. While working on fixing this I stumbled upon a couple of other things which don't seem right. The i2c custom reset funtion (omap_i2c_reset) uses a hwmod exposed api to set the SOFTRESET bit, however it then accesses the hwmod internal structure to poll on RESETDONE status bit. Should there be another function exposed to poll on RESETDONE too? _reset() function documents its return value to be -ETIMEDOUT, if the module fails to reset in time, and hence expects the custom reset function to return the same in such cases. The omap_i2c_reset() function seems to return 0 even in cases of timeout. However looking more closely the return value from _reset() does not seem to be used in the framework today. The comment in _ocp_softreset() suggests the intent was to add a new state to the hwmod state machine. /* * XXX add _HWMOD_STATE_WEDGED for modules that don't come back from * _wait_target_ready() or _reset() */ is it still the case, or should _reset() just return a void? regards, Rajendra -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 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.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
[PATCHv8 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 | 34 +-
1 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 121c52e..76b7b62 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -976,7 +976,7 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq, *ioarea;
+ struct resource *mem, *irq;
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
@@ -995,17 +995,16 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem-start, resource_size(mem),
- pdev-name);
- if (!ioarea) {
- dev_err(pdev-dev, I2C region already claimed\n);
- return -EBUSY;
+ dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(pdev-dev, Menory allocation failed\n);
+ return -ENOMEM;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
- if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev-base = devm_request_and_ioremap(pdev-dev, mem);
+ if (!dev-base) {
+ dev_err(pdev-dev, I2C region already claimed\n);
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -1029,11 +1028,6 @@ 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;
- }
platform_set_drvdata(pdev, dev);
@@ -1121,13 +1115,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 +1124,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 +1131,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
i2c_del_adapter(dev-adapter);
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_disable(pdev-dev);
- iounmap(dev-base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 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.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
[PATCHv8 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.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
[PATCHv8 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.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
[PATCHv8 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.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
[PATCHv8 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.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
[PATCHv8 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 95fb9f9..4815528 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1149,6 +1149,7 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
#ifdef CONFIG_PM_RUNTIME
static void omap_i2c_restore(struct omap_i2c_dev *dev)
{
@@ -1212,15 +1213,16 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
+#endif /* CONFIG_PM_RUNTIME */
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
+#endif /* CONFIG_PM */
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
--
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
[PATCHv8 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 fbf65e2..2976a7e 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 | @@ -1055,6 +1050,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430_3530) dev-errata |= I2C_OMAP3_1P153; -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 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.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
[PATCHv8 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,
[PATCHv8 18/18] I2C: OMAP: Rename the 1p153 to the erratum id i462
The section number in the recent errata document has changed.
Rename the erratum 1p153 to the unique id i462 instead, so that
it is easier to reference. Also change the function name and comments
to reflect the same.
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9239e9c..c592497 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -170,7 +170,7 @@ enum {
/* Errata definitions */
#define I2C_OMAP_ERRATA_I207 (1 0)
-#define I2C_OMAP3_1P153(1 1)
+#define I2C_OMAP_ERRATA_I462 (1 1)
struct omap_i2c_dev {
struct device *dev;
@@ -753,11 +753,11 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
#endif
/*
- * OMAP3430 Errata 1.153: When an XRDY/XDR is hit, wait for XUDF before writing
+ * OMAP3430 Errata i462: When an XRDY/XDR is hit, wait for XUDF before writing
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
{
unsigned long timeout = 1;
@@ -920,8 +920,8 @@ complete:
break;
}
- if ((dev-errata I2C_OMAP3_1P153)
- errata_omap3_1p153(dev, stat, err))
+ if ((dev-errata I2C_OMAP_ERRATA_I462)
+ errata_omap3_i462(dev, stat, err))
goto complete;
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
@@ -1056,7 +1056,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-errata |= I2C_OMAP_ERRATA_I207;
if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
- dev-errata |= I2C_OMAP3_1P153;
+ dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
u16 s;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 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.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
[PATCHv8 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. - Adds a patch to use devm_* functions - Also checks the return type of the get_sync and in case of errors prevents register access, also print the cause of failure in case of errors. - 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 - Split the omap_i2c_isr to increase readability - Make the i2c use SET_RUNTIME_PM_OPS - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. - As discussed in [2], Paul has queued the flag for context restore patch, removing it from the series. v8 Fix Felipe's comments and use devm_request_and_ioremap. [1] http://www.spinics.net/lists/linux-i2c/msg07607.html [2] http://www.spinics.net/lists/linux-i2c/msg07685.html Tested on omap4sdp and omap3sdp. The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7: modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-next 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 I2C: OMAP: Rename the 1p153 to the erratum id i462 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/plat-omap/i2c.c |3 + drivers/i2c/busses/i2c-omap.c | 350 +++-- include/linux/i2c-omap.h |1 + 3 files changed, 199 insertions(+), 155 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 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.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
[PATCHv8 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 4815528..fbf65e2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -786,6 +786,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)
{
@@ -836,48 +879,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;
- }
- }
[PATCHv8 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. Add a error message in case
of failure with the cause of the failure.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index edc4826..95fb9f9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -616,7 +616,11 @@ 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) {
+ dev_err(dev-dev, pm_runtime_get_sync failed %d\n, r);
+ return r;
+ }
r = omap_i2c_wait_for_bb(dev);
if (r 0)
@@ -1039,7 +1043,11 @@ 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) {
+ dev_err(dev-dev, pm_runtime_get_sync failed:%d\n, r);
+ return r;
+ }
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
@@ -1124,12 +1132,17 @@ 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) {
+ dev_err(dev-dev, pm_runtime_get_sync failed %d\n, ret);
+ return ret;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 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
Acked-by: 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 2976a7e..9239e9c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -765,7 +765,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;
}
@@ -778,6 +777,7 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
return 0;
}
+ *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv8 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 76b7b62..edc4826 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1129,7 +1129,9 @@ static int __devexit omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); + pm_runtime_get_sync(pdev-dev); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); return 0; } -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver
On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote: I was hoping that we will have some thing like drivers/memory/* but since it doesn't exist, we used drivers/misc. Why not create it? I have no objection to that, it makes it more obvious as to what this really is. greg k-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
Re: [PATCH 2/2] ARM: mm: Flush only CPU local cache instead of all cache levels.
Hi Santosh,
just posted a series whose aim is the same, please have a look and
let's try to merge the two approaches.
On Thu, Apr 12, 2012 at 12:29:47PM +0100, Santosh Shilimkar wrote:
The ARMv7 processor setup functions clean and invalidates the
cpu cache before enabling MMU. The intention here is to start
with clean CPU local cache.
But on architectures like Cortex-[A15/A8], this code will end
up flushing the L2 cache as well which undesirable and incorrect.
Undesirable agreed, can you define incorrect please ?
The setup functions are used in CPU hotplug scenario's too and
hence flushing all cache levels should be avoided.
Agreed, but this is also true for __cpu_disable() if we consider hotplug into
the picture. The difference is that __cpu_disable is not v7 specific
that's what I tried to address with my series, a more generic (and of course
arguable) approach.
Fix this code by restricting the cache flush to local cpu
cache or L1.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/proc-v7.S |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index f1c8486..96cfc31 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -172,7 +172,8 @@ __v7_ca15mp_setup:
__v7_setup:
adr r12, __v7_setup_stack @ the local stack
stmia r12, {r0-r5, r7, r9, r11, lr}
- bl v7_flush_dcache_all
+ mov r0, #0x1
+ bl v7_flush_dcache_by_level
I did not post my patch here that is similar but basically the idea here is
to clean/invalidate up to Level of Unification Inner Shareable.
That hardcoded 0x1 must be explained, it might work for most of the v7 systems
but I think it should be generalized.
Thanks,
Lorenzo
--
To unsubscribe from this list: send the line unsubscribe 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 v4 0/7] Add TI EMIF SDRAM controller driver
Hi Greg, On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote: On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote: I was hoping that we will have some thing like drivers/memory/* but since it doesn't exist, we used drivers/misc. Why not create it? I have no objection to that, it makes it more obvious as to what this really is. There is another memory controller used in a few TI SoCs, namely GPMC [1], do you prefer having it too there. As of now it is not a driver, platform code handles GPMC, a patch series for converting it into a driver (but still residing in platform folder) was sent a few days back [2,3]. Regards Afzal [1] GPMC (General Purpose Memory Controller) in brief: GPMC is an unified memory controller dedicated to interfacing external memory devices like Asynchronous SRAM like memories and application specific integrated circuit devices. Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash Pseudo-SRAM devices GPMC has to be configured as required by timings of the connected peripheral. It needs to be configured only initially. Once it is configured it can be used to handle different protocols like NAND, NOR. Various kinds of devices like ethernet, uart, usb, fpga etc can work using GPMC interface. GPMC has a seperate additional functionality of NAND handling [2] https://lkml.org/lkml/2012/4/5/210 [3] https://lkml.org/lkml/2012/4/5/212 -- To unsubscribe from this list: send the line unsubscribe 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: hwmod: warn only when clkdm is missing from both clk and hwmod
On OMAP4+, the clkdm association is moved to hwmod while on older OMAPs' its associated with a clk. Hence look for a clkdm in both clk and hwmod and warn only when its missing in both. Also fix the pr_warning() to print the correct hwmod name. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 2c27fdb..83d56df 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -566,9 +566,9 @@ static int _init_main_clk(struct omap_hwmod *oh) return -EINVAL; } - if (!oh-_clk-clkdm) + if (!oh-_clk-clkdm !oh-clkdm_name) pr_warning(omap_hwmod: %s: missing clockdomain for %s.\n, - oh-main_clk, oh-_clk-name); + oh-name, oh-_clk-name); return ret; } -- 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: [PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
On 12:14 Thu 12 Apr , Mohammed, Afzal wrote: Hi Jean, On Thu, Apr 12, 2012 at 17:15:59, Jean-Christophe PLAGNIOL-VILLARD wrote: If ATMEL is also going driver way, then probably our voice together may be heard and hopefully it will expedite the matter. I'm going to add it too my idea was to create something similiar as the pintrl you register the ddifferent bank supported buy the SoC and then the driver request the bank for the dev_name at soc level you will set the default timings and then the drvier may manipulate them I already update the API of sam9_smc to abstract the access to the register. Is SMC code being converted to driver ? no I'm busy on pinctrl I just cereate an abstracted API Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe 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 v4 0/7] Add TI EMIF SDRAM controller driver
On Thu, Apr 12, 2012 at 01:34:15PM +, Mohammed, Afzal wrote: Hi Greg, On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote: On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote: I was hoping that we will have some thing like drivers/memory/* but since it doesn't exist, we used drivers/misc. Why not create it? I have no objection to that, it makes it more obvious as to what this really is. There is another memory controller used in a few TI SoCs, namely GPMC [1], do you prefer having it too there. Sure, why not? As of now it is not a driver, platform code handles GPMC, a patch series for converting it into a driver (but still residing in platform folder) was sent a few days back [2,3]. People are moving things out of the platform folder, so drivers/memory makes sense. thanks, greg k-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
Re: PM related performance degradation on OMAP3
Gary Thomas g...@mlbassoc.com writes: On 2012-04-11 13:17, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: [...] I fear I'm seeing similar problems with 3.3. I have my board (similar to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network performance on 3.3. For example, if I use TFTP to download a large file (~35MB), I get this: 3.0: 42.5 sec 3.3: 625.0 sec That's a factor of 15 worse! This might not be the same problem. What is the NIC being used, and does it have GPIO interrupts? My board uses SMSC911x with GPIO interrupt signal. OK, then your problem is almost certainly solved by my GPIO triggering fix, and not related to Grazvytas' problem. If it's using GPIO interrupts, then you likely need this patch from mainline (v3.4-rc1) I tried to just pick up the patch you [sort of] quoted below, but had a hard time applying it to my kernel. I've tried to just pick up the latest files from the mainline kernel, but so far I've nothing that builds Oh, right. Sorry about that. Yeah, that patch actually has dependencies on other GPIO changes that were queued for v3.4 (and not in v3.3.) If you're on v3.3, just pull the branch below[1] which is based on v3.3-rc2. Pulling that into a v3.3 should build just fine. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/fixes/gpio -- To unsubscribe from this list: send the line unsubscribe 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 v4 0/7] Add TI EMIF SDRAM controller driver
Hi Greg, On Thu, Apr 12, 2012 at 19:40:50, Greg KH wrote: There is another memory controller used in a few TI SoCs, namely GPMC [1], do you prefer having it too there. Sure, why not? Thanks a lot, we were struggling to find a suitable location for the driver. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver
On Thu, Apr 12, 2012 at 6:40 PM, Greg KH g...@kroah.com wrote: On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote: I was hoping that we will have some thing like drivers/memory/* but since it doesn't exist, we used drivers/misc. Why not create it? I have no objection to that, it makes it more obvious as to what this really is. Looks like I should have this question earlier. EMIF driver is perfect candidate for drivers/memory/ Thanks Greg for suggestion. We will go ahead and create drivers/memory and have EMIF drivers 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 v4 0/7] Add TI EMIF SDRAM controller driver
Mohammed, Afzal af...@ti.com writes: Hi Greg, On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote: On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote: I was hoping that we will have some thing like drivers/memory/* but since it doesn't exist, we used drivers/misc. Why not create it? I have no objection to that, it makes it more obvious as to what this really is. There is another memory controller used in a few TI SoCs, namely GPMC [1], do you prefer having it too there. As of now it is not a driver, platform code handles GPMC, a patch series for converting it into a driver (but still residing in platform folder) was sent a few days back [2,3]. IMO, wherever EMIF ends up, GPMC should as well. Kevin [1] GPMC (General Purpose Memory Controller) in brief: GPMC is an unified memory controller dedicated to interfacing external memory devices like Asynchronous SRAM like memories and application specific integrated circuit devices. Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash Pseudo-SRAM devices GPMC has to be configured as required by timings of the connected peripheral. It needs to be configured only initially. Once it is configured it can be used to handle different protocols like NAND, NOR. Various kinds of devices like ethernet, uart, usb, fpga etc can work using GPMC interface. GPMC has a seperate additional functionality of NAND handling [2] https://lkml.org/lkml/2012/4/5/210 [3] https://lkml.org/lkml/2012/4/5/212 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP2+: dmtimer: remove redundant sysconfig context restore
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
v2: removed tiocp_cfg from struct timer_regs {}
Acked-by: Kevin Hilman khil...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: mm: Flush only CPU local cache instead of all cache levels.
On Thu, Apr 12, 2012 at 6:57 PM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
Hi Santosh,
just posted a series whose aim is the same, please have a look and
let's try to merge the two approaches.
Sure ...
On Thu, Apr 12, 2012 at 12:29:47PM +0100, Santosh Shilimkar wrote:
The ARMv7 processor setup functions clean and invalidates the
cpu cache before enabling MMU. The intention here is to start
with clean CPU local cache.
But on architectures like Cortex-[A15/A8], this code will end
up flushing the L2 cache as well which undesirable and incorrect.
Undesirable agreed, can you define incorrect please ?
I was mainly visualizing mainly the hotplug scenario where one CPU
is middle of accessing shared data and other CPU in it's way up path
flush L1 + L2. After thinking bit more, looks like it might work without
issues so incorrect may not be write word.
The setup functions are used in CPU hotplug scenario's too and
hence flushing all cache levels should be avoided.
Agreed, but this is also true for __cpu_disable() if we consider hotplug into
the picture. The difference is that __cpu_disable is not v7 specific
that's what I tried to address with my series, a more generic (and of course
arguable) approach.
Fix this code by restricting the cache flush to local cpu
cache or L1.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/proc-v7.S | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index f1c8486..96cfc31 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -172,7 +172,8 @@ __v7_ca15mp_setup:
__v7_setup:
adr r12, __v7_setup_stack @ the local stack
stmia r12, {r0-r5, r7, r9, r11, lr}
- bl v7_flush_dcache_all
+ mov r0, #0x1
+ bl v7_flush_dcache_by_level
I did not post my patch here that is similar but basically the idea here is
to clean/invalidate up to Level of Unification Inner Shareable.
ok.
That hardcoded 0x1 must be explained, it might work for most of the v7 systems
but I think it should be generalized.
Agree. I just looked at current V7 processors and thought that #1 should be
fine.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM related performance degradation on OMAP3
On 2012-04-12 08:14, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: On 2012-04-11 13:17, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: [...] I fear I'm seeing similar problems with 3.3. I have my board (similar to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network performance on 3.3. For example, if I use TFTP to download a large file (~35MB), I get this: 3.0: 42.5 sec 3.3: 625.0 sec That's a factor of 15 worse! This might not be the same problem. What is the NIC being used, and does it have GPIO interrupts? My board uses SMSC911x with GPIO interrupt signal. OK, then your problem is almost certainly solved by my GPIO triggering fix, and not related to Grazvytas' problem. If it's using GPIO interrupts, then you likely need this patch from mainline (v3.4-rc1) I tried to just pick up the patch you [sort of] quoted below, but had a hard time applying it to my kernel. I've tried to just pick up the latest files from the mainline kernel, but so far I've nothing that builds Oh, right. Sorry about that. Yeah, that patch actually has dependencies on other GPIO changes that were queued for v3.4 (and not in v3.3.) If you're on v3.3, just pull the branch below[1] which is based on v3.3-rc2. Pulling that into a v3.3 should build just fine. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/fixes/gpio This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. I am interested in having PM working as I'm designing a battery powered portable unit, so I need to keep pursuing this. Note: I noticed that when I built with CONFIG_PM off and no other changes, my EHCI USB didn't work properly. Should this be the case? Thanks again for your help -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap3, sccb
Hello, is SCCB (Serial camera control bus, Omnivision's I2C variant) supported in the Linux driver for OMAP3? more specifically, I'm looking at the 2-wire interface on the beagleboard-xm camera expansion port any plan to make it work? thanks, regards, p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM related performance degradation on OMAP3
+Felipe for EHCI question Gary Thomas g...@mlbassoc.com writes: [...] This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. And does a CONFIG_PM=n kernel get you back to your v3.0 performance? I am interested in having PM working as I'm designing a battery powered portable unit, so I need to keep pursuing this. So do I. :) Note: I noticed that when I built with CONFIG_PM off and no other changes, my EHCI USB didn't work properly. Should this be the case? Probably not, but haven't tested EHCI USB. I've Cc'd Felipe to see if he has any ideas why EHCI wouldn't work with CONFIG_PM=n. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver
Hi On Thu, 12 Apr 2012, Mohammed, Afzal wrote: On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote: On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote: I was hoping that we will have some thing like drivers/memory/* but since it doesn't exist, we used drivers/misc. Why not create it? I have no objection to that, it makes it more obvious as to what this really is. There is another memory controller used in a few TI SoCs, namely GPMC [1], do you prefer having it too there. As of now it is not a driver, platform code handles GPMC, a patch series for converting it into a driver (but still residing in platform folder) was sent a few days back [2,3]. Probably the GPMC driver should go into a slightly different place than SDRC/EMIF. GPMC is actually a general-purpose parallel bus driver. It's used to interface Ethernet controllers, UARTs, FPGAs, NAND/NOR flash, SRAM, etc. It cannot be used to control DRAM, at least not without a separate DRAM controller chip. SDRC/EMIF are both DRAM controllers. That's all they do. They can't be used to control anything else. They implement DRAM refresh, etc. So perhaps something like drivers/memory/dram/ for the SDRAM controllers, and maybe drivers/memory/ for the GPMC? - 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] ARM: omap: hwmod: warn only when clkdm is missing from both clk and hwmod
Hi On Thu, 12 Apr 2012, Rajendra Nayak wrote: On OMAP4+, the clkdm association is moved to hwmod while on older OMAPs' its associated with a clk. Sounds like this should be conditional based on the platform, then, rather than weakening the warning for all platforms ? Hence look for a clkdm in both clk and hwmod and warn only when its missing in both. Also fix the pr_warning() to print the correct hwmod name. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 2c27fdb..83d56df 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -566,9 +566,9 @@ static int _init_main_clk(struct omap_hwmod *oh) return -EINVAL; } - if (!oh-_clk-clkdm) + if (!oh-_clk-clkdm !oh-clkdm_name) pr_warning(omap_hwmod: %s: missing clockdomain for %s.\n, -oh-main_clk, oh-_clk-name); +oh-name, oh-_clk-name); return ret; } -- 1.7.1 - 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: PM related performance degradation on OMAP3
On 2012-04-12 10:57, Kevin Hilman wrote: +Felipe for EHCI question Gary Thomasg...@mlbassoc.com writes: [...] This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. And does a CONFIG_PM=n kernel get you back to your v3.0 performance? Correct. I am interested in having PM working as I'm designing a battery powered portable unit, so I need to keep pursuing this. So do I. :) Note: I noticed that when I built with CONFIG_PM off and no other changes, my EHCI USB didn't work properly. Should this be the case? Probably not, but haven't tested EHCI USB. I've Cc'd Felipe to see if he has any ideas why EHCI wouldn't work with CONFIG_PM=n. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: omap: hwmod: Make omap_hwmod_softreset wait for reset status
Hi Rajendra, On Thu, 12 Apr 2012, Rajendra Nayak wrote: On Thursday 12 April 2012 12:29 AM, Paul Walmsley wrote: That approach sounds fine to me, but I don't think Fernando's patch will help with I2C.. Since it uses a custom reset function omap_i2c_reset(), the delay will actually need to go there. While working on fixing this I stumbled upon a couple of other things which don't seem right. The i2c custom reset funtion (omap_i2c_reset) uses a hwmod exposed api to set the SOFTRESET bit, however it then accesses the hwmod internal structure to poll on RESETDONE status bit. Should there be another function exposed to poll on RESETDONE too? Sure, something like that would make sense for 3.5. _reset() function documents its return value to be -ETIMEDOUT, if the module fails to reset in time, and hence expects the custom reset function to return the same in such cases. The omap_i2c_reset() function seems to return 0 even in cases of timeout. However looking more closely the return value from _reset() does not seem to be used in the framework today. The comment in _ocp_softreset() suggests the intent was to add a new state to the hwmod state machine. /* * XXX add _HWMOD_STATE_WEDGED for modules that don't come back from * _wait_target_ready() or _reset() */ is it still the case, or should _reset() just return a void? There's a patch queued to pass along the return status from _reset(): http://marc.info/?l=linux-omapm=133417544011862w=2 As far as the new state goes, if you'd like to add a new state to indicate an IP block that fails _reset()/_wait_target_ready() and should be blocked from further use, that sounds good to me... regards, - 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] mmc: omap_hsmmc: set dto to 14 for all devices
Hello Tushar, On Thu, 12 Apr 2012, Tushar Behera wrote: With this patch, I continuously get following message on my console. (Tested on Origen board, based on EXYNOS4210). mmc0: Too large timeout requested for CMD25! So, with this change, should we update sdhci_calc_timeout() also? Looks like most of the host drivers that range-check the timeout value silently clamp it at the hardware-supported maximum value: drivers/mmc/host/atmel-mci.c drivers/mmc/host/davinci_mmc.c drivers/mmc/host/mvsdio.c drivers/mmc/host/omap_hsmmc.c drivers/mmc/host/wbsd.c drivers/mmc/host/tifm_sd.c So maybe try the same thing for your driver? Of course it seems that some drivers don't range-check the timeout value at all :-( drivers/mmc/host/bfin_sdh.c drivers/mmc/host/mmci.c drivers/mmc/host/msm_sdcc.c drivers/mmc/host/pxamci.c drivers/mmc/host/mxs-mmc.c drivers/mmc/host/omap.c - 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: PM related performance degradation on OMAP3
Gary Thomas g...@mlbassoc.com writes: On 2012-04-12 10:57, Kevin Hilman wrote: +Felipe for EHCI question Gary Thomasg...@mlbassoc.com writes: [...] This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. And does a CONFIG_PM=n kernel get you back to your v3.0 performance? Correct. OK, I just tried your TFTP experiment on a 3530/Overo board with the same smsc911x NIC that has GPIO interrupts, and I don't see much difference between a PM-enabled v3.0 and a PM-enabled v3.3. Are you TFTP'ing the file to an MMC filesystem?Can you try to a ramdisk[1]? If you're using MMC, it could be MMC driver changes since v3.0 that are actually causing your performance hit. In my experiment, I TFTP'd a 24Mb file to a ramdisk, to make sure no other drivers were invovled, and didn't see any major differences between v3.0, v3.3, and v3.3 CONFIG_PM disabled. Below are my results. As you can see, all the results seem to be pretty close to the same. This test was not on a controlled, isolated network, so the differences are probably explained by other network activity: - v3.0 vanilla: PM enabled, CPUidle enabled - Received 25362406 bytes in 35.5 seconds - Received 25362406 bytes in 44.9 seconds - Received 25362406 bytes in 49.0 seconds - Received 25362406 bytes in 36.2 seconds - Received 25362406 bytes in 56.3 seconds - Received 25362406 bytes in 65.2 seconds - Received 25362406 bytes in 37.0 seconds - v3.3: PM enabled, CPUidle enabled + GPIO fix (my for_3.4/fixes/gpio branch) + smsc911x regulator boot fix (Tony's omap/fix-smsc911x-regulator branch) - Received 25362406 bytes in 32.1 seconds - Received 25362406 bytes in 29.8 seconds - Received 25362406 bytes in 33.5 seconds - Received 25362406 bytes in 44.5 seconds - Received 25362406 bytes in 39.2 seconds - Received 25362406 bytes in 57.0 seconds - Received 25362406 bytes in 49.6 seconds - v3.3: CONFIG_PM=n + branches above + fix from Grazvydas for !CONFIG_PM case: [PATCH] ARM: OMAP: sram: fix BUG in dpll code for !PM case + disable CONFIG_OMAP_WATCHDOG which fails to boot when CONFIG_PM=y - Received 25362406 bytes in 34.1 seconds - Received 25362406 bytes in 33.9 seconds - Received 25362406 bytes in 34.9 seconds - Received 25362406 bytes in 37.8 seconds - Received 25362406 bytes in 40.0 seconds - Received 25362406 bytes in 37.6 seconds - Received 25362406 bytes in 34.4 seconds Kevin [1] simple steps to make a ramdisk mkfs.ext2 /dev/ram0 mkdir /tmp/rd mount /dev/ram0 /tmp/rd cd /tmp/rd then TFTP file here -- To unsubscribe from this list: send the line unsubscribe 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] mmc: omap_hsmmc: set dto to 14 for all devices
Hi, On Thu, Apr 12 2012, Paul Walmsley wrote: With this patch, I continuously get following message on my console. (Tested on Origen board, based on EXYNOS4210). mmc0: Too large timeout requested for CMD25! So, with this change, should we update sdhci_calc_timeout() also? Looks like most of the host drivers that range-check the timeout value silently clamp it at the hardware-supported maximum value: If I understand correctly, the only problem here is the presence of the warning, so I'm leaning towards just removing it (which we've already had another request for) or making it pr_debug() instead. Sound okay? Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver
+ Felipe, Hi Paul, On 4/12/2012 7:00 PM, Paul Walmsley wrote: Hi On Thu, 12 Apr 2012, Mohammed, Afzal wrote: On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote: On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote: I was hoping that we will have some thing like drivers/memory/* but since it doesn't exist, we used drivers/misc. Why not create it? I have no objection to that, it makes it more obvious as to what this really is. There is another memory controller used in a few TI SoCs, namely GPMC [1], do you prefer having it too there. As of now it is not a driver, platform code handles GPMC, a patch series for converting it into a driver (but still residing in platform folder) was sent a few days back [2,3]. Probably the GPMC driver should go into a slightly different place than SDRC/EMIF. GPMC is actually a general-purpose parallel bus driver. It's used to interface Ethernet controllers, UARTs, FPGAs, NAND/NOR flash, SRAM, etc. It cannot be used to control DRAM, at least not without a separate DRAM controller chip. SDRC/EMIF are both DRAM controllers. That's all they do. They can't be used to control anything else. They implement DRAM refresh, etc. The LPDDR2 spec does consider as well NVM (Non Volatile Memory), so I think we should stick to driver/memory for EMIF. So perhaps something like drivers/memory/dram/ for the SDRAM controllers, and maybe drivers/memory/ for the GPMC? In fact Felipe was considering something else for that kind of general purpose bus driver like GMPC, C2C and LLI... ... But I do not remember the name :-) Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM related performance degradation on OMAP3
On 2012-04-12 12:08, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: On 2012-04-12 10:57, Kevin Hilman wrote: +Felipe for EHCI question Gary Thomasg...@mlbassoc.com writes: [...] This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. And does a CONFIG_PM=n kernel get you back to your v3.0 performance? Correct. OK, I just tried your TFTP experiment on a 3530/Overo board with the same smsc911x NIC that has GPIO interrupts, and I don't see much difference between a PM-enabled v3.0 and a PM-enabled v3.3. Are you TFTP'ing the file to an MMC filesystem?Can you try to a ramdisk[1]? If you're using MMC, it could be MMC driver changes since v3.0 that are actually causing your performance hit. I'm testing to a ramdisk, so we're on the same page. Could you send me your config file so I can compare? Maybe I have something dumb in my settings that aggravates things. Also, what's your performance on 3.4-rc2? The linux-media tree I started from is a bit post v3.3, so there might be something else causing this. In my experiment, I TFTP'd a 24Mb file to a ramdisk, to make sure no other drivers were invovled, and didn't see any major differences between v3.0, v3.3, and v3.3 CONFIG_PM disabled. Below are my results. As you can see, all the results seem to be pretty close to the same. This test was not on a controlled, isolated network, so the differences are probably explained by other network activity: - v3.0 vanilla: PM enabled, CPUidle enabled - Received 25362406 bytes in 35.5 seconds - Received 25362406 bytes in 44.9 seconds - Received 25362406 bytes in 49.0 seconds - Received 25362406 bytes in 36.2 seconds - Received 25362406 bytes in 56.3 seconds - Received 25362406 bytes in 65.2 seconds - Received 25362406 bytes in 37.0 seconds - v3.3: PM enabled, CPUidle enabled + GPIO fix (my for_3.4/fixes/gpio branch) + smsc911x regulator boot fix (Tony's omap/fix-smsc911x-regulator branch) - Received 25362406 bytes in 32.1 seconds - Received 25362406 bytes in 29.8 seconds - Received 25362406 bytes in 33.5 seconds - Received 25362406 bytes in 44.5 seconds - Received 25362406 bytes in 39.2 seconds - Received 25362406 bytes in 57.0 seconds - Received 25362406 bytes in 49.6 seconds - v3.3: CONFIG_PM=n + branches above + fix from Grazvydas for !CONFIG_PM case: [PATCH] ARM: OMAP: sram: fix BUG in dpll code for !PM case + disable CONFIG_OMAP_WATCHDOG which fails to boot when CONFIG_PM=y - Received 25362406 bytes in 34.1 seconds - Received 25362406 bytes in 33.9 seconds - Received 25362406 bytes in 34.9 seconds - Received 25362406 bytes in 37.8 seconds - Received 25362406 bytes in 40.0 seconds - Received 25362406 bytes in 37.6 seconds - Received 25362406 bytes in 34.4 seconds Kevin [1] simple steps to make a ramdisk mkfs.ext2 /dev/ram0 mkdir /tmp/rd mount /dev/ram0 /tmp/rd cd /tmp/rd then TFTP file here -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe 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 v4 0/7] Add TI EMIF SDRAM controller driver
Hi Benoît, On Thu, 12 Apr 2012, Cousson, Benoit wrote: The LPDDR2 spec does consider as well NVM (Non Volatile Memory), so I think we should stick to driver/memory for EMIF. Hmm good point! So perhaps something like drivers/memory/dram/ for the SDRAM controllers, and maybe drivers/memory/ for the GPMC? In fact Felipe was considering something else for that kind of general purpose bus driver like GMPC, C2C and LLI... ... But I do not remember the name :-) It would be nice if we could separate IP blocks that can drive an Ethernet controller or modem chip from the DRAM controllers; they are quite different beasts from a common API standpoint. - Paul
Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver
On 4/12/2012 9:15 PM, Paul Walmsley wrote: Hi Benoît, On Thu, 12 Apr 2012, Cousson, Benoit wrote: The LPDDR2 spec does consider as well NVM (Non Volatile Memory), so I think we should stick to driver/memory for EMIF. Hmm good point! So perhaps something like drivers/memory/dram/ for the SDRAM controllers, and maybe drivers/memory/ for the GPMC? In fact Felipe was considering something else for that kind of general purpose bus driver like GMPC, C2C and LLI... ... But I do not remember the name :-) It would be nice if we could separate IP blocks that can drive an Ethernet controller or modem chip from the DRAM controllers; they are quite different beasts from a common API standpoint. Yep, fully agree. In fact Felipe's suggestion was something like drivers/ocd for off-chip devices, but maybe something like drivers/gpbus will highlight a little bit more the bus controller aspect of such driver. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 10/14] drivers/rtc/rtc-twl.c: use static register while reading time
From: Konstantin Shlyakhovoy x0155...@ti.com
Subject: drivers/rtc/rtc-twl.c: use static register while reading time
RTC stores time and date in several registers. Due to the fact that these
registers can't be read instantaneously, there is a chance that reading
from counting registers gives an error of one minute, one hour, one day,
etc.
To address this issue, the RTC has hardware support to copy the RTC
counting registers to static shadowed registers. The current
implementation does not use this feature, and in a stress test, we can
reproduce this error at a rate of around two times per 30 readings.
Fix the implementation to ensure that the right snapshot of time is
captured.
Signed-off-by: Konstantin Shlyakhovoy x0155...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: Benoit Cousson b-cous...@ti.com
Cc: linux-omap linux-omap@vger.kernel.org
Acked-by: Mykola Oleksiienko x0174...@ti.com
Acked-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
Acked-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/rtc/rtc-twl.c | 43 +++-
1 file changed, 38 insertions(+), 5 deletions(-)
diff -puN
drivers/rtc/rtc-twl.c~drivers-rtc-rtc-twlc-use-static-register-while-reading-time
drivers/rtc/rtc-twl.c
---
a/drivers/rtc/rtc-twl.c~drivers-rtc-rtc-twlc-use-static-register-while-reading-time
+++ a/drivers/rtc/rtc-twl.c
@@ -112,6 +112,7 @@ static const u8 twl6030_rtc_reg_map[] =
#define BIT_RTC_CTRL_REG_TEST_MODE_M 0x10
#define BIT_RTC_CTRL_REG_SET_32_COUNTER_M0x20
#define BIT_RTC_CTRL_REG_GET_TIME_M 0x40
+#define BIT_RTC_CTRL_REG_RTC_V_OPT 0x80
/* RTC_STATUS_REG bitfields */
#define BIT_RTC_STATUS_REG_RUN_M 0x02
@@ -235,25 +236,57 @@ static int twl_rtc_read_time(struct devi
unsigned char rtc_data[ALL_TIME_REGS + 1];
int ret;
u8 save_control;
+ u8 rtc_control;
ret = twl_rtc_read_u8(save_control, REG_RTC_CTRL_REG);
- if (ret 0)
+ if (ret 0) {
+ dev_err(dev, %s: reading CTRL_REG, error %d\n, __func__, ret);
return ret;
+ }
+ /* for twl6030/32 make sure BIT_RTC_CTRL_REG_GET_TIME_M is clear */
+ if (twl_class_is_6030()) {
+ if (save_control BIT_RTC_CTRL_REG_GET_TIME_M) {
+ save_control = ~BIT_RTC_CTRL_REG_GET_TIME_M;
+ ret = twl_rtc_write_u8(save_control, REG_RTC_CTRL_REG);
+ if (ret 0) {
+ dev_err(dev, %s clr GET_TIME, error %d\n,
+ __func__, ret);
+ return ret;
+ }
+ }
+ }
- save_control |= BIT_RTC_CTRL_REG_GET_TIME_M;
+ /* Copy RTC counting registers to static registers or latches */
+ rtc_control = save_control | BIT_RTC_CTRL_REG_GET_TIME_M;
- ret = twl_rtc_write_u8(save_control, REG_RTC_CTRL_REG);
- if (ret 0)
+ /* for twl6030/32 enable read access to static shadowed registers */
+ if (twl_class_is_6030())
+ rtc_control |= BIT_RTC_CTRL_REG_RTC_V_OPT;
+
+ ret = twl_rtc_write_u8(rtc_control, REG_RTC_CTRL_REG);
+ if (ret 0) {
+ dev_err(dev, %s: writing CTRL_REG, error %d\n, __func__, ret);
return ret;
+ }
ret = twl_i2c_read(TWL_MODULE_RTC, rtc_data,
(rtc_reg_map[REG_SECONDS_REG]), ALL_TIME_REGS);
if (ret 0) {
- dev_err(dev, rtc_read_time error %d\n, ret);
+ dev_err(dev, %s: reading data, error %d\n, __func__, ret);
return ret;
}
+ /* for twl6030 restore original state of rtc control register */
+ if (twl_class_is_6030()) {
+ ret = twl_rtc_write_u8(save_control, REG_RTC_CTRL_REG);
+ if (ret 0) {
+ dev_err(dev, %s: restore CTRL_REG, error %d\n,
+ __func__, ret);
+ return ret;
+ }
+ }
+
tm-tm_sec = bcd2bin(rtc_data[0]);
tm-tm_min = bcd2bin(rtc_data[1]);
tm-tm_hour = bcd2bin(rtc_data[2]);
_
--
To unsubscribe from this list: send the line unsubscribe 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 v4 0/7] Add TI EMIF SDRAM controller driver
Hi Greg, On Wed, Apr 11, 2012 at 8:00 PM, Greg KH g...@kroah.com wrote: On Wed, Apr 11, 2012 at 08:44:39PM -0600, Paul Walmsley wrote: Cc Mark Greer, Mark Salter Hi Greg, Aneesh, On Sat, 17 Mar 2012, Aneesh V wrote: Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. Just checking to see what the current state of this series is. Greg, are you considering this for merging, or are there remaining issues? Aneesh, do you have any remaining issues to resolve with this set? What about the review comment about devfreq? I see that Santosh has already commented on this. My views are similar, that frequency update is only one of the many functions of the driver. This is useful not only for OMAP4 and AM3517/3505, but also will probably be useful for the C6x chips that Mark Salter is working on. It's still in my to-review queue, that I'm slowly making my way through. So it's not lost, but I would like to get the devfreq interface question cleared up first. Thanks. I will wait for your review then. Once I have your comments I will re-work and submit in the new directory structure proposed. thanks, Aneesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM related performance degradation on OMAP3
Gary Thomas g...@mlbassoc.com writes: On 2012-04-12 12:08, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: On 2012-04-12 10:57, Kevin Hilman wrote: +Felipe for EHCI question Gary Thomasg...@mlbassoc.com writes: [...] This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. And does a CONFIG_PM=n kernel get you back to your v3.0 performance? Correct. OK, I just tried your TFTP experiment on a 3530/Overo board with the same smsc911x NIC that has GPIO interrupts, and I don't see much difference between a PM-enabled v3.0 and a PM-enabled v3.3. Are you TFTP'ing the file to an MMC filesystem?Can you try to a ramdisk[1]? If you're using MMC, it could be MMC driver changes since v3.0 that are actually causing your performance hit. I'm testing to a ramdisk, so we're on the same page. Could you send me your config file so I can compare? Maybe I have something dumb in my settings that aggravates things. Below is the Kconfig snippet[1] I append to a default omap2plus_defconfig to enable CPUidle, CPUfreq and some debug. Rebuild with that appended and these settings override the default ones. I used omap2plus_defcnfig plus this snippit for v3.0, v3.3 and v3.4-rc2 tests. Also, what's your performance on 3.4-rc2? The linux-media tree I started from is a bit post v3.3, so there might be something else causing this. I just tried with vanilla v3.4-rc2, and I see basically the same results. Between 35 and 50 seconds for the 24Mb file transfer, which is similar to the v3.0 and v3.3 results. Kevin [1] CONFIG_CPU_IDLE=y CONFIG_PM_ADVANCED_DEBUG=y CONFIG_PM_SLEEP_ADVANCED_DEBUG=y CONFIG_PM_GENERIC_DOMAINS=y CONFIG_OMAP_SMARTREFLEX=y CONFIG_OMAP_SMARTREFLEX_CLASS3=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_ARM_OMAP2PLUS_CPUFREQ=y CONFIG_REGULATOR_OMAP_SMPS=y CONFIG_DEBUG_LL=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_USER=y CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_SECTION_MISMATCH=y -- To unsubscribe from this list: send the line unsubscribe 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 08/12] arm: omap3: am35x: Fix clockdomain dependencies
On Wed, Apr 11, 2012 at 08:29:51PM -0600, Paul Walmsley wrote: On Wed, 11 Apr 2012, Mark A. Greer wrote: Okay, I'll get rid of the commas (fwiw, gfx_sgx_3xxx_wkdeps[] has commas in k.o, the others don't). Okay thanks, that's just an oversight in the mainline data. If you're so inclined, feel free to clean that up in your patch... I am and I will. :) Mark -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: PM related performance degradation on OMAP3
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Grazvydas Ignotas Sent: Tuesday, April 10, 2012 7:30 PM What I think is going on here is that omap_sram_idle() is taking too much time because it's overhead is too large. I've added a counter there and it seems to be called ~530 times per megabyte (DMA operates in ~2K chunks so it makes sense), that's over 2000 calls per second. Some quick measurement code shows ~243us spent for setting up in omap_sram_idle() (before and after omap34xx_do_sram_idle()). 243uS is really a long time for C1. For some reason has grown a lot since last time I captured path in ETM. Your analysis correlates well to reports from a couple years back. N900 folks did report that the non-clock gated C1 was needed (as exists in code today). IIRC the NAND stack did have small-uS spins on NAND status or something which having higher clock stop penalty resulted in big performance dip. You needed like 10uS for C1 or bit hit. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe 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 11/12] arm: omap3: am35x: Add do_wfi routine for EMIF4 submodules
On Wed, Apr 11, 2012 at 04:36:25PM -0600, Paul Walmsley wrote: Hi just a few comments based on a quick look On Wed, 11 Apr 2012, Mark A. Greer wrote: diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 1f62f23..22aac4c 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -391,6 +401,52 @@ wait_dll_lock_counter: ENTRY(omap3_do_wfi_sz) .word . - omap3_do_wfi +/* + * Do WFI instruction (SDRC module has EMIF4 submodule) + * + * This code gets copied to internal SRAM and is accessible + * from both SDRAM and SRAM: + * - executed from SRAM for non-off modes (omap3_emif4_do_wfi_sram), + * - executed from SDRAM for OFF mode (omap3_emif4_do_wfi). + */ + .align 3 +ENTRY(omap3_emif4_do_wfi) + /* Put EMIF in self-refresh */ Hmm, I guess this comment isn't quite right; it just tells it to go to self-refresh when it's idle ? (see below) + ldr r4, pwr_mgmt_ctrl + ldr r5, [r4] + orr r5, r5, #0x200 Maybe use a macro here in place of the #0x200 to indicate what it's trying to set... Do you happen to know what idle means in the context of SPRUGR0B Section 9.2.3.4.5.1 SDRAM Self-Refresh Mode ? Is it referring to target module-level idle, e.g. SIdleReq; or is it referring to an internal definition of idle, e.g., something like no reads or writes from/to the SDRAM ? Am wondering if this should just be set once during EMIF initialization. I can't tell from tne manual. I assumed it meant the latter of the choices you listed. I just tested a kernel with it set up during EMIF init (value of 0x8200) and removed the related bits from omap3_emif4_do_wfi() and it booted and returned from suspend-to-RAM just fine. So, it seems that it can be moved to EMIF init. [I swear I tested this some time ago and discovered that it was needed in omap3_emif4_do_wfi(). Oh well...] + str r5, [r4] Might be good to do a readback after this to ensure that the store has made it to the EMIF. Also, scanning SPRUGR0B, it looks like this setting is dependent partially on the REG_PM_TIM field in the same register. Might be good to set REG_PM_TIM during EMIF init to avoid any bootloader dependency. True but moot now since I'll move the code to EMIF init. + + dsb + dmb + + wfi + + nop + nop + nop + nop + nop + nop + nop + nop + nop + nop Are these NOPs necessary? Is the number of NOPs dependent on CPU or bus speed or some ARM parameter? After looking through the am35x errata, I don't think so. AFAICT, they are there to work around--from omap3535 errata (sprz278f.pdf)-- Advisory 3.1.1.75, IVA2: CAM/SGX Dependencies (OMAP3530/25 only). I don't see that or any other errata that requires a nop in the am35x errata so I'll get rid of them. [As I went through the errata again, I noticed talk about the device going into RET state. Sigh...] Mark -- -- To unsubscribe from this list: send the line unsubscribe 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 02/12] arm: omap3: Only sleep during cpu_idle if I/O wake-ups work
On Wed, Apr 11, 2012 at 06:42:44PM -0500, Jon Hunter wrote: Hi Mark, On 04/11/2012 02:05 PM, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com Currently in the OMAP3 code, cpu_idle() calls pm_idle(), which is a function pointer set to omap3_pm_idle()). omap3_pm_idle() calls omap_sram_idle() which eventually causes a 'wfi' instruction to be executed effectively putting the system to sleep. It is assumed that an I/O wake-up event will occur to wake the system up again. This doesn't work on systems that don't support I/O wake-ups (indicated by omap3_has_io_wakeup() returning false). Leaving pm_idle() pointing to default_idle() won't work either because the cpu_processor_do_idle() routine which is eventually called may also execute a 'wfi' instruction (e.g., cpu_v7_do_idle()). So with this change you will never execute wfi? Correct. I would have thought a timer or peripheral interrupt would be able to bring you out of wfi. It occasionally wakes up so I'm guessing its a timer interrupt. It seems that peripheral interrupts aren't waking it up. Perhaps something isn't configured correctly but everything I've looked at looks okay (AFAICT). IO wake-ups would only be needed for very low power states. At least that is how it is on OMAP devices. I am not sure how the AMxxx devices differ. The am35x isn't supposed to have them so there's no real info on it but I'm sure its the same as regular OMAP devices. Mark -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM related performance degradation on OMAP3
On 2012-04-12 16:03, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: On 2012-04-12 12:08, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: On 2012-04-12 10:57, Kevin Hilman wrote: +Felipe for EHCI question Gary Thomasg...@mlbassoc.comwrites: [...] This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. And does a CONFIG_PM=n kernel get you back to your v3.0 performance? Correct. OK, I just tried your TFTP experiment on a 3530/Overo board with the same smsc911x NIC that has GPIO interrupts, and I don't see much difference between a PM-enabled v3.0 and a PM-enabled v3.3. Are you TFTP'ing the file to an MMC filesystem?Can you try to a ramdisk[1]? If you're using MMC, it could be MMC driver changes since v3.0 that are actually causing your performance hit. I'm testing to a ramdisk, so we're on the same page. Could you send me your config file so I can compare? Maybe I have something dumb in my settings that aggravates things. Below is the Kconfig snippet[1] I append to a default omap2plus_defconfig to enable CPUidle, CPUfreq and some debug. Rebuild with that appended and these settings override the default ones. I used omap2plus_defcnfig plus this snippit for v3.0, v3.3 and v3.4-rc2 tests. Also, what's your performance on 3.4-rc2? The linux-media tree I started from is a bit post v3.3, so there might be something else causing this. I just tried with vanilla v3.4-rc2, and I see basically the same results. Between 35 and 50 seconds for the 24Mb file transfer, which is similar to the v3.0 and v3.3 results. Kevin [1] CONFIG_CPU_IDLE=y CONFIG_PM_ADVANCED_DEBUG=y CONFIG_PM_SLEEP_ADVANCED_DEBUG=y CONFIG_PM_GENERIC_DOMAINS=y CONFIG_OMAP_SMARTREFLEX=y CONFIG_OMAP_SMARTREFLEX_CLASS3=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_ARM_OMAP2PLUS_CPUFREQ=y CONFIG_REGULATOR_OMAP_SMPS=y CONFIG_DEBUG_LL=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_USER=y CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_SECTION_MISMATCH=y These settings made no difference. I just reverified my results to xfer a 39MB file to ramdisk: 3.0 + PM = 39sec 3.3 + PM = 70sec 3.3 - PM = 48sec so it's not quite the same as 3.0 was, but closer. BTW, your results normalized to mine would be 3.3 + PM = 56sec I wish I knew why I'm seeing a big difference between +PM/-PM and you don't. Is there some way to compare your source tree (the one you built for v3.3) and mine? I'm not very good with GIT so I'm not quite sure how to do it. Sorry for being so much trouble, I'm just in search of all the performance I can get out of my system :-) Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
