Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Mon, Apr 16, 2012 at 10:16 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Keshava, On Wed, Apr 11, 2012 at 05:15:03PM +0530, Munegowda, Keshava wrote: On Tue, Mar 27, 2012 at 8:40 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 03/19/12 08:42, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Both EHCI ports worked on cm-t3730 previously and no regression is seen with this patch. Tested-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. Hi sameo Since I am not seeing this patch in linux-next labled 3.4.rc2 on 10th april 2012; please let me know your plan to queue this patch for the main line. I applied this one to my for-linus branch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ Thank a lot Samuel regards keshava -- To unsubscribe from this list: send the line unsubscribe 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: release correct resource
On Sat, Apr 14, 2012 at 7:11 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: res can be one of several resources, as this variable is re-used several times during probe. This can cause the wrong resource parameters to be passed to release_mem_region(). Get the original memory resource before calling release_mem_region(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/mmc/host/omap_hsmmc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index d12bdbe..4b2e1f0 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2027,7 +2027,9 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) err_alloc: omap_hsmmc_gpio_free(pdata); err: - release_mem_region(res-start, resource_size(res)); + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (res) + release_mem_region(res-start, resource_size(res)); return ret; } -- Thanks Russell. I'll send it to Chris to be queued for 3.4-fixes. -- To unsubscribe from this list: send the line unsubscribe 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: OMAP3: gpmc: add BCH ecc api and modes
This patch adds a simple BCH ecc computation api, similar to the
existing Hamming ecc api. It is intended to be used by the MTD layer.
It implements the following features:
- support 4-bit and 8-bit ecc computation
- do not protect user bytes in spare area, only data area is protected
- ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs
This last feature is obtained by adding a constant polynomial to
the hardware computed ecc. It allows to correct bitflips in blank pages
and is extremely useful to support filesystems such as UBIFS, which expect
erased pages to contain only 0xFFs.
This api has been tested on an OMAP3630 board.
Signed-off-by: Ivan Djelic ivan.dje...@parrot.com
---
arch/arm/mach-omap2/gpmc.c | 148
arch/arm/plat-omap/include/plat/gpmc.h | 10 +++
2 files changed, 158 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 00d5108..dc9a9a4 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -49,6 +49,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC_BCH_RESULT_0 0x240
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -920,3 +921,150 @@ int gpmc_calculate_ecc(int cs, const u_char *dat, u_char
*ecc_code)
return 0;
}
EXPORT_SYMBOL_GPL(gpmc_calculate_ecc);
+
+#ifdef CONFIG_ARCH_OMAP3
+
+/**
+ * gpmc_enable_hwecc_bch - enable hardware BCH ecc functionality
+ * @cs: chip select number
+ * @mode: read/write mode
+ * @dev_width: device bus width(1 for x16, 0 for x8)
+ * @nsectors: how many 512-byte sectors to process
+ * @nerrors: how many errors to correct per sector (4 or 8)
+ */
+int gpmc_enable_hwecc_bch(int cs, int mode, int dev_width, int nsectors,
+ int nerrors)
+{
+ unsigned int val;
+
+ /* check if ecc module is in use */
+ if (gpmc_ecc_used != -EINVAL)
+ return -EINVAL;
+
+ /*
+* FIXME: some OMAP3 revisions have a hardware bug which prevents
+* the 4-bit BCH mode to work properly. Such revisions should be
+* detected and rejected here.
+*/
+
+ gpmc_ecc_used = cs;
+
+ /* clear ecc and enable bits */
+ gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+
+ /*
+* When using BCH, sector size is hardcoded to 512 bytes.
+* Here we are using wrapping mode 6 both for reading and writing, with:
+* size0 = 0 (no additional protected byte in spare area)
+* size1 = 32 (skip 32 nibbles = 16 bytes per sector in spare area)
+*/
+ gpmc_write_reg(GPMC_ECC_SIZE_CONFIG, (32 22) | (0 12));
+
+ /* BCH configuration */
+ val = ((1 16) | /* enable BCH */
+ (((nerrors == 8) ? 1 : 0) 12) | /* 8 or 4 bits */
+ (0x06 8) | /* wrap mode = 6 */
+ (dev_width 7) | /* bus width */
+ (((nsectors-1) 0x7) 4) | /* number of sectors */
+ (cs 1) | /* ECC CS */
+ (0x1));/* enable ECC */
+
+ gpmc_write_reg(GPMC_ECC_CONFIG, val);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(gpmc_enable_hwecc_bch);
+
+/**
+ * gpmc_calculate_ecc_bch4 - Generate 7 ecc bytes per sector of 512 data bytes
+ * @cs: chip select number
+ * @dat: The pointer to data on which ecc is computed
+ * @ecc: The ecc output buffer
+ */
+int gpmc_calculate_ecc_bch4(int cs, const u_char *dat, u_char *ecc)
+{
+ int i;
+ unsigned long nsectors, reg, val1, val2;
+
+ if (gpmc_ecc_used != cs)
+ return -EINVAL;
+
+ nsectors = ((gpmc_read_reg(GPMC_ECC_CONFIG) 4) 0x7) + 1;
+
+ for (i = 0; i nsectors; i++) {
+
+ reg = GPMC_ECC_BCH_RESULT_0 + 16*i;
+
+ /* Read hw-computed remainder */
+ val1 = gpmc_read_reg(reg + 0);
+ val2 = gpmc_read_reg(reg + 4);
+
+ /*
+* Add constant polynomial to remainder, in order to get an ecc
+* sequence of 0xFFs for a buffer filled with 0xFFs; and
+* left-justify the resulting polynomial.
+*/
+ *ecc++ = 0x28 ^ ((val2 12) 0xFF);
+ *ecc++ = 0x13 ^ ((val2 4) 0xFF);
+ *ecc++ = 0xcc ^ (((val2 0xF) 4)|((val1 28) 0xF));
+ *ecc++ = 0x39 ^ ((val1 20) 0xFF);
+ *ecc++ = 0x96 ^ ((val1 12) 0xFF);
+ *ecc++ = 0xac ^ ((val1 4) 0xFF);
+ *ecc++ = 0x7f ^ ((val1 0xF) 4);
+ }
+
+ gpmc_ecc_used = -EINVAL;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(gpmc_calculate_ecc_bch4);
+
+/**
+ * gpmc_calculate_ecc_bch8 - Generate 13 ecc bytes per block of 512 data bytes
+ * @cs: chip select number
+ * @dat: The pointer to data on which ecc is computed
+ * @ecc:
Re: [PATCH 0/3] OMAP4: CPUidle: Add coupled idle support
On Mon, Apr 9, 2012 at 12:24 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Tuesday 03 April 2012 08:36 PM, Santosh Shilimkar wrote:
On Tuesday 03 April 2012 10:34 AM, Kevin Hilman wrote:
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
The series adds the coupled cpuidle support for OMAP4 based on the v2
series posted [1]. This makes OMAP4 to support SMP cpuidle and also
removes the hard dependency of off-lining CPU1 to trigger deeper
C-states.
I have put together a branch which is based on 3.3 kernel with
Len Browns next branch [2] which has time keeping and other cpuidle
patches which will mostly get merged by 3.4-rc1 and rebased coupled
idle series from [1].
Thanks for rebasing this.
git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
for_3.5/omap4_coupled_cpuidle-rebase
This branch by itself seems to work fine. However, when combining with
other stuff that has merged for v3.4, it hangs during boot. I haven't
yet isolated the problem, but it's easy to reproduce by combining your
branch with v3.4-rc1:
git checkout -b test/coupled-v3.4 v3.4-rc1
git merge -s recursive -X ours
santosh/for_3.5/omap4_coupled_cpuidle-rebase [1]
This hangs on boot, and it seems like a coupled state deadlock because
commenting out the coupled states in the C-state creation of
cpuidle44xx.c makes it boot just fine.
I managed to reproduce the issue. Just to ensure that any OMAP changes
have not introduced the regression I merged all Tony's pull request on
my branch and tried it out. OMAP changes are fine and coupled idle
continue to work.
Started bisecting the commits. For bisect I have to create a series
which is not dependent on Len's cpuidle updates. First round of bisect
was not successful so tried one more time. Was very close to narrowing
down on commit but then encountered set of commits where either CPUIDLE
itself is broken(deeper C-states are not getting attempted) or I get
softIRQ 08 pending error.
The last bad commit in bisect was ...
[8682df25ca9afd3aac30f2c72d00bd98de2118e8] Merge branch
'fortglx/3.4/rtc' of git://git.linaro.org/people/jstultz/linux into
timers/core
So far looks like, one of below series has introduced a race which is
getting highlighted with coupled cpuidle patchset.
9b612fa Merge branch 'fortglx/3.4/clocksource' of
git://git.linaro.org/people/jstultz/linux into timers/core
8682df2 Merge branch 'fortglx/3.4/rtc' of
git://git.linaro.org/people/jstultz/linux into timers/core
97ac984 Merge branch 'fortglx/3.4/time' of
git://git.linaro.org/people/jstultz/linux into timers/core
Finally managed to crack down the issue.
The broad-cast clock-event was remaining in shut-down mode and
hence we were loosing the OS tick after entering to low power
states. The cases where it use to work was mainly because of
external interrupts like NFS etc.
Have posted a patch [1] on LKML which fixes the issue. Waiting
for feedback from Thomas on it.
Based on the discussion on patch [1], I ended up creating another
patch(end of the email) for OMAP4 idle driver. Git tree is
updated accordingly and available here [2]
Regards,
Santosh
[1] https://lkml.org/lkml/2012/4/9/13
[2] git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
for_3.5/coupled_cpuidle-rebase
From d36a31b21e3d839ff0ae440186874bfeb6e7edc1 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Tue, 17 Apr 2012 15:09:20 +0530
Subject: [PATCH] ARM: OMAP4: CPUidle: Open broadcast clock-event device.
OMAP4 idle driver uses CLOCK_EVT_NOTIFY_BROADCAST_[ENTER/EXIT]
for broadcast clock events. But _ENTER/_EXIT doesn't really open
broadcast clock events and to explicitly setup the broadcast device,
CLOCK_EVT_NOTIFY_BROADCAST_ON should be used.
So far the broadcast device was opened up by generic code and hence
OMAP4 idle was working without explicit CLOCK_EVT_NOTIFY_BROADCAST_ON.
From commit 77b0d60 {clockevents: Leave the broadcast device in shutdown
mode}, the default setup is skipped so driver needs to open up the
broadcast device.
Without this patch, boot might hang since CPU enters deeper idle state in
which local timer stalls and broad cast timer is not armed.
Discussion thread :
https://lkml.org/lkml/2012/4/9/13
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index ccc8e82..cf804e9 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -259,6 +259,7 @@ int __init omap4_idle_init(void)
dev-state_count++;
drv-state_count++;
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, cpu_id);
cpuidle_register_driver(omap4_idle_driver);
if (cpuidle_register_device(dev)) {
--
1.7.5.4
--
To unsubscribe from this list: send the
Re: [PATCH 2/2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Tue, Apr 17, 2012 at 7:11 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
Few more comments below.
* Raja, Govindraj govindraj.r...@ti.com [120411 04:53]:
...
+static int __init omap_serial_fill_default_pads(struct omap_board_data
*bdata,
+ struct omap_uart_state *uart)
+{
+ struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
+ struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
+ char *rx_fmt, *tx_fmt;
+ int uart_nr = bdata-id + 1;
+
+ if (bdata-id != 2) {
+ rx_fmt = uart%d_rx.uart%d_rx;
+ tx_fmt = uart%d_tx.uart%d_tx;
+ } else {
+ rx_fmt = uart%d_rx_irrx.uart%d_rx_irrx;
+ tx_fmt = uart%d_tx_irtx.uart%d_tx_irtx;
+ }
+
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, rx_fmt,
+ uart_nr, uart_nr);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, tx_fmt,
+ uart_nr, uart_nr);
This naming won't work for the fourth port on 3630 as there are no uart4_rx
or uart4_tx mux entries, they are gpmc_wait2.uart4_tx and
gpmc_wait3.uart4_tx.
But uart4 is unused on 3630 boards and boards trying to use them
should configure them from board file.
(I thought we agreed on this approach where only if uarts are
available in mux mode0 those ports will be dynamically muxed for wakeup
others should use omap_serial_init_port)
@@ -289,8 +354,8 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
bdata.pads = NULL;
bdata.pads_cnt = 0;
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
+ if (omap_serial_fill_default_pads(bdata, uart))
+ continue;
if (!info)
omap_serial_init_port(bdata, NULL);
Can't the omap_serial_board_init() now be just be omap_serial_init(void)
as it's not used anywhere else?
Yes sure we can remove that.
Anyways, this is getting too complex for the -rc series as at least 2430sdp
is using alternative pins for the first uart. Let's patch to remove just
the uart4 entry for 3630 for the -rc and then we can properly fix this
for the next merge window.
Okay. in that case the earlier patch [1] should be fine to solve the
gpmc issue observed
and ehci issue on beagle-xm.
--
Thanks,
Govindraj.R
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/090961.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: [PATCHv8 04/18] I2C: OMAP: I2C register restore only if context is lost
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
OK, minor comment below.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
The definition is removed, but I don't see any of the users removed.
If the users were cleaned up earlier in the series, then the removal of
this should be done with that, or as a separate patch. I don't see why
it belongs with this patch.
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) {
-
[PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
A call to request_mem_region() has been introduced in the omap-gpio
driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
gpio/omap: Use devm_ API and add request_mem_region). This change
prevented the Amstrad Delta NAND driver, which was doing the same in
order to take control over OMAP MPU I/O lines that the NAND device hangs
off, from loading successfully.
There is another driver, omap-keypad, which also manipulates OMAP MPUIO
registers, but has never been calling request_mem_region() on startup,
so it's not affected by the change in the gpio-omap and works correctly.
Drop request_mem_region() call and related bits from ams-delta NAND
driver.
Created and tested against linux-3.4-rc3.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/mtd/nand/ams-delta.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 7341695..af76da3 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -212,18 +212,11 @@ static int __devinit ams_delta_init(struct
platform_device *pdev)
/* Link the private data with the MTD structure */
ams_delta_mtd-priv = this;
- if (!request_mem_region(res-start, resource_size(res),
- dev_name(pdev-dev))) {
- dev_err(pdev-dev, request_mem_region failed\n);
- err = -EBUSY;
- goto out_free;
- }
-
io_base = ioremap(res-start, resource_size(res));
if (io_base == NULL) {
dev_err(pdev-dev, ioremap failed\n);
err = -EIO;
- goto out_release_io;
+ goto out_free;
}
this-priv = io_base;
@@ -271,8 +264,6 @@ out_gpio:
platform_set_drvdata(pdev, NULL);
gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
iounmap(io_base);
-out_release_io:
- release_mem_region(res-start, resource_size(res));
out_free:
kfree(ams_delta_mtd);
out:
@@ -293,7 +284,6 @@ static int __devexit ams_delta_cleanup(struct
platform_device *pdev)
gpio_free_array(_mandatory_gpio, ARRAY_SIZE(_mandatory_gpio));
gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
iounmap(io_base);
- release_mem_region(res-start, resource_size(res));
/* Free the MTD device structure */
kfree(ams_delta_mtd);
--
1.7.3.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: PM related performance degradation on OMAP3
Grazvydas Ignotas nota...@gmail.com writes:
On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman khil...@ti.com wrote:
It would be helpful now to narrow down what are the big contributors to
the overhead in omap_sram_idle(). Most of the code there is skipped for
C1 because the next states for MPU and CORE are both ON.
Ok I did some tests, all in mostly idle system with just init, busybox
shell and dd doing a NAND read to /dev/null .
Hmm, I seem to get a hang using dd to read from NAND /dev/mtdX on my
Overo. I saw your patch 'mtd: omap2: fix resource leak in prefetch-busy
path' but that didn't seem to help my crash.
MB/s is throughput that
dd reports, mA and approx. current draw during the transfer, read from
fuel gauge that's onboard.
MB/s| mA|comment
3.7|218|mainline f549e088b80
3.8|224|nand qos PM_QOS_CPU_DMA_LATENCY 0 [1]
4.4|220|[1] + pwrdm_p*_transition commented [2]
3.8|225|[1] + omap34xx_do_sram_idle-cpu_do_idle [3]
4.2|210|[1] + pwrdm_set_next_pwrst(per_pd, PWRDM_POWER_ON) [4]
4.0|224|[1] + 'Deny idle' [5]
5.1|210|[2] + [4] + [5]
5.2|202|[5] + omap_sram_idle-cpu_do_idle [6]
5.5|243|!CONFIG_PM
6.1|282|busywait DMA end (for reference)
Thanks for the detailed experiments. This definitely confirms we have
some serious unwanted overhead for C1, and our C-state latency values
are clearly way off base, since they only account HW latency and not any
of the SW latency introduced in omap_sram_idle().
There are 2 primary differences that I see as possible causes. I list
them here with a couple more experiments for you to try to help us
narrow this down.
1) powerdomain accounting: pwrdm_pre_transition(), pwrdm_post_transition()
Could you try using omap_sram_idle() and just commenting out those
calls? Does that help performance? Those iterate over all the
powerdomains, so defintely add some overhead, but I don't think it
would be as significant as what you're seeing.
Seems to be taking good part of it.
Much more likely is...
2) jump to SRAM, SDRC self-refresh, SDRC errata workarounds
Could not notice any difference.
To me it looks like this results from many small things adding up..
Idle is called so often that pwrdm_p*_transition() and those
pwrdm_for_each_clkdm() walks start slowing everything down, perhaps
because they access lots of registers on slow buses?
Yes PRCM register accesses are unfortunately rather slow, and we've
known that for some time, but haven't done any detailed analysis of the
overhead.
Using the function_graph tracer, I was able to see that the pre/post
transition are taking an enormous amount of time:
- pwrdm pre-transition: 1400+ us at 600MHz (4000+ us at 125MHz)
- pwrdm post-transtion: 1600+ us at 600MHz (6000+ us at 125MHz)
Notice the big difference between 600MHz OPP and 125MHz OPP. Are you
using CPUfreq at all in your tests? If using cpufreq + ondemand
governor, you're probably running at low OPP due to lack of CPU activity
which will also affect the latencies in the idle path.
Maybe some register cache would help us there, or are those registers
expected to be changed by hardware often?
Yes, we've known that some sort of register cache here would be useful
for some time, but haven't got to implementing it.
Also trying to idle PER while transfer is ongoing (as reported in
previous mail) doesn't sound like a good idea and is one of the
reasons for slowdown. Seems to also causing more current drain,
ironically.
Agreed. Again, using the function_graph tracer, I get some pretty big
latencies from the GPIO pre/post idling process:
- gpio_prepare_for_idle(): 2400+ us at 600MHz (8200+ us at 125MHz)
- gpio_resume_from_idle(): 2200+ us at 600MHz (7600+ us at 125MHz)
Removing PER transtions as you did will get rid of those.
I'm looking into this in more detail know, and will likely have a few
patches for you to experiment with.
Thanks again for digging into this with us,
Kevin
changes (again, sorry for corrupted diffs, but they should be easy to
reproduce):
[2]:
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -307,7 +307,7 @@ void omap_sram_idle(void)
omap3_enable_io_chain();
}
- pwrdm_pre_transition();
+// pwrdm_pre_transition();
/* PER */
if (per_next_state PWRDM_POWER_ON) {
@@ -372,7 +373,7 @@ void omap_sram_idle(void)
}
omap3_intc_resume_idle();
- pwrdm_post_transition();
+// pwrdm_post_transition();
/* PER */
if (per_next_state PWRDM_POWER_ON) {
[3]:
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -347,7 +347,7 @@ void omap_sram_idle(void)
if (save_state == 1 || save_state == 3)
cpu_suspend(save_state, omap34xx_do_sram_idle);
else
- omap34xx_do_sram_idle(save_state);
+ cpu_do_idle();
/* Restore normal SDRC POWER settings */
if
Re: [PATCHv8 04/18] I2C: OMAP: I2C register restore only if context is lost
Hi Kevin,
Thanks for your review,
On Tue, Apr 17, 2012 at 7:15 PM, Kevin Hilman khil...@ti.com wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
OK, minor comment below.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
The definition is removed, but I don't see any of the users removed.
If the users were cleaned up earlier in the series, then the removal of
this should be done with that, or as a separate patch. I don't see why
it belongs with this patch.
I have not removed the users actually the macro was redefined.
I have instead used the definition in omap_hwmod.h which gets added
when I include omap_device.h
Let me know if you prefer a separate patch?
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);
@@
Re: [PATCH] ARM: OMAP: sram: fix BUG in dpll code for !PM case
* Tony Lindgren t...@atomide.com [120409 15:52]: * Grazvydas Ignotas nota...@gmail.com [120406 14:56]: _omap3_sram_configure_core_dpll is called when SDRC is reprogrammed, which is done regardless of CONFIG_PM setting, so we always need it's setup code too. Without this, we hit a BUG() on OMAP3 when kernel is built without CONFIG_PM: Reprogramming SDRC clock to 33200 Hz [ cut here ] kernel BUG at arch/arm/plat-omap/sram.c:342! Internal error: Oops - BUG: 0 [#1] ARM ... [c001c694] (omap3_configure_core_dpll+0x68/0x6c) from [c001b2dc] (omap3_core_dpll_m2_set_rate+0x1) [c001b2dc] (omap3_core_dpll_m2_set_rate+0x138/0x1b0) from [c001a478] (omap2_clk_set_rate+0x14/0x2) [c001a478] (omap2_clk_set_rate+0x14/0x20) from [c001c9dc] (clk_set_rate+0x54/0x74) [c001c9dc] (clk_set_rate+0x54/0x74) from [c022b9c8] (omap_sdrc_init+0x70/0x90) [c022b9c8] (omap_sdrc_init+0x70/0x90) from [c022f178] (omap3pandora_init+0x11c/0x164) [c022f178] (omap3pandora_init+0x11c/0x164) from [c022849c] (customize_machine+0x20/0x28) [c022849c] (customize_machine+0x20/0x28) from [c0225810] (do_one_initcall+0xa0/0x16c) [c0225810] (do_one_initcall+0xa0/0x16c) from [c02259e0] (kernel_init+0x104/0x1ac) [c02259e0] (kernel_init+0x104/0x1ac) from [c0009cec] (kernel_thread_exit+0x0/0x8) Looks like this was caused by the added ifdef CONFIG_PM from commit 3231fc88 (OMAP3: PM: restore SRAM functions after off-mode). Applying this into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL]: omap-serial updates for 3.4-rc
Hi, * Raja, Govindraj govindraj.r...@ti.com [120416 03:44]: The following changes since commit e816b57a337ea3b755de72bec38c10c864f23015: Linux 3.4-rc3 (2012-04-15 18:28:29 -0700) are available in the git repository at: git://gitorious.org/linux-3-x/omap-serial.git for_3.4/uart_fixes for you to fetch changes up to 381772fefe13e73fc3d01c462d401785767c3775: ARM: OMAP: serial: Fix the ocp smart idlemode handling bug (2012-04-16 15:46:26 +0530) Govindraj.R (5): OMAP2+: UART: Remove cpu checks for populating errata flags Not a fix. OMAP2+: UART: enable tx wakeup bit for wer reg Not a fix, and should get reviewed and merged via linux-serial mailing list. OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx Not a fix. OMAP2+: UART: Fix incorrect population of default uart pads I'll apply this directly with updated comments into fixes. OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup Not ready and too intrusive for -rc cycle. Santosh Shilimkar (1): ARM: OMAP: serial: Fix the ocp smart idlemode handling bug It seems this can wait as the wake-up events are anyways broken right now when we remove the muxing. So not pulling. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
* Raja, Govindraj govindraj.r...@ti.com [120417 05:51]:
On Tue, Apr 17, 2012 at 7:11 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
Few more comments below.
* Raja, Govindraj govindraj.r...@ti.com [120411 04:53]:
...
+static int __init omap_serial_fill_default_pads(struct omap_board_data
*bdata,
+ struct omap_uart_state *uart)
+{
+ struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
+ struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
+ char *rx_fmt, *tx_fmt;
+ int uart_nr = bdata-id + 1;
+
+ if (bdata-id != 2) {
+ rx_fmt = uart%d_rx.uart%d_rx;
+ tx_fmt = uart%d_tx.uart%d_tx;
+ } else {
+ rx_fmt = uart%d_rx_irrx.uart%d_rx_irrx;
+ tx_fmt = uart%d_tx_irtx.uart%d_tx_irtx;
+ }
+
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, rx_fmt,
+ uart_nr, uart_nr);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, tx_fmt,
+ uart_nr, uart_nr);
This naming won't work for the fourth port on 3630 as there are no
uart4_rx
or uart4_tx mux entries, they are gpmc_wait2.uart4_tx and
gpmc_wait3.uart4_tx.
But uart4 is unused on 3630 boards and boards trying to use them
should configure them from board file.
(I thought we agreed on this approach where only if uarts are
available in mux mode0 those ports will be dynamically muxed for wakeup
others should use omap_serial_init_port)
Right, but you're still trying to do mux_get_by_name on it to check
the pads, which will produce a warning on 3630.
@@ -289,8 +354,8 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
bdata.pads = NULL;
bdata.pads_cnt = 0;
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
+ if (omap_serial_fill_default_pads(bdata, uart))
+ continue;
if (!info)
omap_serial_init_port(bdata, NULL);
Can't the omap_serial_board_init() now be just be omap_serial_init(void)
as it's not used anywhere else?
Yes sure we can remove that.
OK
Anyways, this is getting too complex for the -rc series as at least 2430sdp
is using alternative pins for the first uart. Let's patch to remove just
the uart4 entry for 3630 for the -rc and then we can properly fix this
for the next merge window.
Okay. in that case the earlier patch [1] should be fine to solve the
gpmc issue observed and ehci issue on beagle-xm.
I'll just use your first patch to remove _all_ the muxing for
omap_serial_init().
That's really the only safe thing we can do for the -rc cycle.
This means we rely on bootloader settings for console muxing and wake-up
bits, but that's just what we need to live with until next merge window.
And for the next merge window, I think we should only automatically enable
the wake-up event bits if the port is in serial mode, and not do any other
muxing. Something like:
void __init omap_serial_init(void)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
list_for_each_entry(uart, uart_list, node) {
bdata.id = uart-num;
bdata.flags = 0;
bdata.pads = NULL;
bdata.pads_cnt = 0;
omap_serial_check_wakeup(bdata);
omap_serial_init_port(bdata, NULL);
}
omap_serial_board_init(NULL);
}
Where omap_serial_check_wakeup() just enables the wake-up if the
port is already muxed to uart mode. So it turns out we can't bail
out for unmuxed uarts because some boards use alternative pads like
2430sdp does for the first uart.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2+: UART: Fix incorrect population of default uart pads
* Russ Dill russ.d...@gmail.com [120413 16:17]:
On Tue, Apr 10, 2012 at 6:40 AM, Govindraj.R govindraj.r...@ti.com wrote:
From: Govindraj.R govindraj.r...@ti.com
The following commit:
(7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
added default pads for all uarts. But not all boards tend to
use all uarts and most of unused uart pins are muxed for
other purpose. This commit breaks the modules which where trying
to use unused uart pins on their boards.
So remove the default pads adding.
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Russ Dill russ.d...@gmail.com
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Russ Dill russ.d...@ti.com
Applying this into fixes with the updated comments as below.
Tony
From: Govindraj.R govindraj.r...@ti.com
Date: Tue, 17 Apr 2012 10:35:47 -0700
Subject: [PATCH] ARM: OMAP2+: UART: Fix incorrect population of default uart
pads
Commit (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
wrongly added muxing of default pads for all uarts. This causes
breakage on multiple boards using uart pins for alternate functions.
For example, on zoom3 random oopses can be seen with nfsroot as
the smsc911x ethernet FIFO timings on GPMC bus are controlled
by gpmc_wait2 and gpmc_wait3 pins. This means we can't mux these
pads to uart4 functionality as commit 7496ba3 was doing.
Not all boards tend to use all uarts and most of unused uart pins
are muxed for other purpose. This commit breaks the modules which
where trying to use unused uart pins on their boards.
So remove the default pad muxing. Note that this is not a complete
fix, as we now rely on bootloader set muxing for the uart wake-up
events. Further patching is needed to enable wake-up events for
uarts that are already muxed to uart mode.
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Acked-by: Russ Dill russ.d...@gmail.com
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
[t...@atomide.com: updated comments to describe oops on zoom3]
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..2e351f5 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,124 +120,8 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static struct omap_device_pad default_uart1_pads[] __initdata = {
- {
- .name = uart1_cts.uart1_cts,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_rts.uart1_rts,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_tx.uart1_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_rx.uart1_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
-};
-
-static struct omap_device_pad default_uart2_pads[] __initdata = {
- {
- .name = uart2_cts.uart2_cts,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_rts.uart2_rts,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_tx.uart2_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_rx.uart2_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
-};
-
-static struct omap_device_pad default_uart3_pads[] __initdata = {
- {
- .name = uart3_cts_rctx.uart3_cts_rctx,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart3_rts_sd.uart3_rts_sd,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart3_tx_irtx.uart3_tx_irtx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart3_rx_irrx.uart3_rx_irrx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
- },
-};
-
-static struct omap_device_pad default_omap36xx_uart4_pads[] __initdata = {
- {
- .name = gpmc_wait2.uart4_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = gpmc_wait3.uart4_rx,
-
Re: [PATCH] ARM: OMAP: serial: Fix the ocp smart idlemode handling bug
On Fri, 13 Apr 2012, Santosh Shilimkar wrote: The current serial UART code, while fidling with ocp idlemode bits, forget about the smart idle wakeup bit even if it is supported by UART IP block. This will lead to missing the module wakeup on OMAP's where the smart idle wakeup is supported. This was the root cause of the console sluggishness issue, I have been observing on OMAP4 devices and also can be potential reason for some other UART wakeup issues. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Govindraj.R govindraj.r...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Reviewed-by: Paul Walmsley p...@pwsan.com Of course, in the long term, these idlemode tweaking functions need to go through some kind of omap_bus/omap_device abstraction, since platform_data function pointers are going away with the DT conversion. But since a decent omap_bus/omap_device is still a ways off, this is an important interim step. - 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: [GIT PULL]: omap-serial updates for 3.4-rc
* Shilimkar, Santosh santosh.shilim...@ti.com [120417 11:27]: On Apr 17, 2012 11:05 PM, Tony Lindgren t...@atomide.com wrote: Santosh Shilimkar (1): ARM: OMAP: serial: Fix the ocp smart idlemode handling bug It seems this can wait as the wake-up events are anyways broken right now when we remove the muxing. This patch has no dependency on other patches in this series. It is an indepedent fix for uart module wakeup which solves the console slugishness. It should be taken and should even go to stable. But I let you decide on it. OK, will apply to fixes then with Cc stable. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: hwmod: second set of fixes for 3.4-rc
* Paul Walmsley p...@pwsan.com [120413 05:29]: Hi Tony, The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e: Linux 3.4-rc2 (2012-04-07 18:30:41 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending tags/omap-fixes-b-for-3.4rc for you to fetch changes up to 1f5e6247ca99287bac87aff4971a7eee9c2b223a: ARM: OMAP2/3: VENC hwmods: Remove OCPIF_SWSUP_IDLE flag from VENC slave interface (2012-04-13 05:28:34 -0600) A few OMAP hwmod fixes against v3.4-rc2. One of them is a reversion of a previous v3.4-rc patch that caused some regressions, and upon further review, appears not to be necessary. The other two are fairly minor. Thanks, this is now merged into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP2+: resolve some sparse, cppcheck warnings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e:
Linux 3.4-rc2 (2012-04-07 18:30:41 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending
tags/omap-cleanup-a-for-3.5
for you to fetch changes up to 0b93afd5d945a8c002f4d380a88b5d7a61c49289:
ARM: OMAP2+: clean up some cppcheck warnings (2012-04-13 06:34:32 -0600)
-
Resolve static analysis warnings generated by files in
arch/arm/mach-omap1, arch/arm/mach-omap2, and arch/arm/plat-omap.
Fixes all but one sparse warning and most of the useful
cppcheck warnings.
-
This series has been test-booted on 5912OSK, N800, CM-T3517, 3530ES3.0
Beagle, 37xx EVM, and 4430ES2 Panda. A few minor notes: N800 here is
not mounting MMC with or without this series, this is probably due to
a problem with my local N800 test setup which has recently changed.
Also CM-T3517 does not boot to userspace either with or without this
series.
Boot transcripts can be found at:
http://www.pwsan.com/omap/bootlogs/20120417/sparse_cppcheck_cleanup_3.5__0b93afd5d945a8c002f4d380a88b5d7a61c49289/
object size (delta in bytes from v3.4-rc2):
textdata bss total kernel
-84 +24 0 -60 5912osk_testconfig/vmlinux
-100 -8 0-108 n800_multi_omap2xxx/vmlinux
-68 -8 0 -76 n800_testconfig/vmlinux
-224 +56 -32-200 omap1_defconfig/vmlinux
-148 +32 0-116 omap2_4_testconfig/vmlinux
-212 0 0-212 omap2plus_defconfig/vmlinux
-148 0 0-148 omap2plus_no_pm/vmlinux
-152 0 0-152 omap3_4_testconfig/vmlinux
-100 -8 0-108 omap3_testconfig/vmlinux
-188 -24 0-212 omap4_testconfig/vmlinux
Paul Walmsley (12):
ARM: OMAP2+: declare file-local functions as static
ARM: OMAP: add includes for missing prototypes
ARM: OMAP1: OCPI: move to mach-omap1/
ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus
ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse
ARM: OMAP: fix 'using plain integer as NULL pointer' sparse warnings
ARM: OMAP: OCM RAM: use memset_io() when clearing SRAM
ARM: OMAP: DMA: use constant array maximum, drop some LCD DMA code
ARM: OMAP: USB: remove unnecessary sideways include
ARM: OMAP1: board files: deduplicate and clean some NAND-related code
ARM: OMAP1: DMTIMER: fix broken timer clock source selection
ARM: OMAP2+: clean up some cppcheck warnings
arch/arm/mach-omap1/Makefile | 13 +
arch/arm/mach-omap1/ams-delta-fiq.c |2 +-
arch/arm/mach-omap1/board-fsample.c | 16 +---
arch/arm/mach-omap1/board-h2.c | 17 +
arch/arm/mach-omap1/board-h3.c | 16 +---
arch/arm/mach-omap1/board-nand.c | 37
+
arch/arm/mach-omap1/board-palmz71.c |4 ++--
arch/arm/mach-omap1/board-perseus2.c | 16 +---
arch/arm/mach-omap1/clock.c |3 +--
arch/arm/mach-omap1/common.h | 11 ++-
arch/arm/mach-omap1/fpga.c |2 +-
arch/arm/mach-omap1/id.c |2 ++
arch/arm/mach-omap1/io.c |3 +--
arch/arm/mach-omap1/irq.c|2 ++
arch/arm/mach-omap1/lcd_dma.c|7 +--
arch/arm/{plat-omap = mach-omap1}/ocpi.c|7 +--
arch/arm/mach-omap1/pm.c |9 -
arch/arm/mach-omap1/reset.c |2 ++
arch/arm/mach-omap1/timer.c |7 +++
arch/arm/mach-omap1/usb.c|3 +++
arch/arm/mach-omap2/am35xx-emac.c| 37
+
arch/arm/mach-omap2/board-omap3evm.c |8
arch/arm/mach-omap2/board-omap4panda.c |8
arch/arm/mach-omap2/board-rx51-peripherals.c |4 ++--
arch/arm/mach-omap2/board-zoom-display.c |1 +
arch/arm/mach-omap2/common.h |2 --
arch/arm/mach-omap2/devices.c|7 +++
arch/arm/mach-omap2/gpio.c |2 +-
arch/arm/mach-omap2/gpmc-onenand.c |3 +--
arch/arm/mach-omap2/gpmc.c |3 +--
arch/arm/mach-omap2/hwspinlock.c |2 +-
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/irq.c|3 ++-
arch/arm/mach-omap2/mux.c|2 +-
arch/arm/mach-omap2/omap-secure.c|1 +
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm24xx.c
Re: [PATCH v4 11/12] ARM: OMAP1: DMTIMER: fix broken timer clock source selection
* Paul Walmsley p...@pwsan.com [120410 17:41]:
DMTIMER source selection on OMAP1 is broken. omap1_dm_timer_set_src()
tries to use __raw_{read,write}l() to read from and write to physical
addresses, but those functions take virtual addresses.
sparse caught this:
arch/arm/mach-omap1/timer.c:50:13: warning: incorrect type in argument 1
(different base types)
arch/arm/mach-omap1/timer.c:50:13:expected void const volatile [noderef]
asn:2*noident
arch/arm/mach-omap1/timer.c:50:13:got unsigned int
arch/arm/mach-omap1/timer.c:52:9: warning: incorrect type in argument 1
(different base types)
arch/arm/mach-omap1/timer.c:52:9:expected void const volatile [noderef]
asn:2*noident
arch/arm/mach-omap1/timer.c:52:9:got unsigned int
Fix by using omap_{read,writel}(), just like the other users of the
MOD_CONF_CTRL_1 register in the OMAP1 codebase. Of course, in the long term,
removing omap_{read,write}l() is the appropriate thing to do; but
this will take some work to do this cleanly.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Uhh looks like this was caused by commit 97933d6 (ARM: OMAP1: dmtimer:
conversion
to platform devices) moving code and changing it :(
I'll pick this to fixes.
Tony
---
arch/arm/mach-omap1/timer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 5536e04..64c65bc 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -47,9 +47,9 @@ static int omap1_dm_timer_set_src(struct platform_device
*pdev,
int n = (pdev-id - 1) 1;
u32 l;
- l = __raw_readl(MOD_CONF_CTRL_1) ~(0x03 n);
+ l = omap_readl(MOD_CONF_CTRL_1) ~(0x03 n);
l |= source n;
- __raw_writel(l, MOD_CONF_CTRL_1);
+ omap_writel(l, MOD_CONF_CTRL_1);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe 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 Tue, Apr 17, 2012 at 5:30 PM, Kevin Hilman khil...@ti.com wrote: Grazvydas Ignotas nota...@gmail.com writes: Ok I did some tests, all in mostly idle system with just init, busybox shell and dd doing a NAND read to /dev/null . Hmm, I seem to get a hang using dd to read from NAND /dev/mtdX on my Overo. I saw your patch 'mtd: omap2: fix resource leak in prefetch-busy path' but that didn't seem to help my crash. I see overo doesn't set 16bit flag, I think it has NAND on 16bit bus? Perhaps try this: --- a/arch/arm/mach-omap2/board-overo.c +++ b/arch/arm/mach-omap2/board-overo.c @@ -517,7 +517,7 @@ static void __init overo_init(void) omap_serial_init(); omap_sdrc_init(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params); - omap_nand_flash_init(0, overo_nand_partitions, + omap_nand_flash_init(NAND_BUSWIDTH_16, overo_nand_partitions, ARRAY_SIZE(overo_nand_partitions)); usb_musb_init(NULL); usbhs_init(usbhs_bdata); Also only pandora is using NAND DMA mode right now in mainline, the default polling mode won't exhibit the latency problem (with all other polling consequences like high CPU usage), so this is needed too for the test: --- a/arch/arm/mach-omap2/common-board-devices.c +++ b/arch/arm/mach-omap2/common-board-devices.c @@ -127,6 +127,7 @@ void __init omap_nand_flash_init(int options, struct mtd_partition *parts, nand_data.parts = parts; nand_data.nr_parts = nr_parts; nand_data.devsize = options; + nand_data.xfer_type = NAND_OMAP_PREFETCH_DMA; printk(KERN_INFO Registering NAND on CS%d\n, nandcs); if (gpmc_nand_init(nand_data) 0) I also forgot to mention I was using ubifs in my test (dd'ing large file from it), I don't think it has much effect, but if you want to try with that: .config CONFIG_MTD_UBI=y CONFIG_UBIFS_FS=y -- ubiformat /dev/mtdX -s 512 ubiattach /dev/ubi_ctrl -m X # X from mtdX ubimkvol /dev/ubi0 -m -N somename mount -t ubifs ubi0:somename /mnt To me it looks like this results from many small things adding up.. Idle is called so often that pwrdm_p*_transition() and those pwrdm_for_each_clkdm() walks start slowing everything down, perhaps because they access lots of registers on slow buses? Yes PRCM register accesses are unfortunately rather slow, and we've known that for some time, but haven't done any detailed analysis of the overhead. Using the function_graph tracer, I was able to see that the pre/post transition are taking an enormous amount of time: - pwrdm pre-transition: 1400+ us at 600MHz (4000+ us at 125MHz) - pwrdm post-transtion: 1600+ us at 600MHz (6000+ us at 125MHz) Hmm, with this it wouldn't be able to do ~500+ calls/sec I was seeing, so the tracer overhead is probably quite large too.. Notice the big difference between 600MHz OPP and 125MHz OPP. Are you using CPUfreq at all in your tests? If using cpufreq + ondemand governor, you're probably running at low OPP due to lack of CPU activity which will also affect the latencies in the idle path. I used performance governor in my tests, so it all was at 600MHz. I'm looking into this in more detail know, and will likely have a few patches for you to experiment with. Sounds good, -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 11/12] ARM: OMAP1: DMTIMER: fix broken timer clock source selection
On Tue, 17 Apr 2012, Tony Lindgren wrote: Uhh looks like this was caused by commit 97933d6 (ARM: OMAP1: dmtimer: conversion to platform devices) moving code and changing it :( I'll pick this to fixes. Sounds good, will drop this from my series and send a new pull request. - 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: serial: Fix the ocp smart idlemode handling bug
Santosh Shilimkar santosh.shilim...@ti.com writes:
The current serial UART code, while fidling with ocp idlemode bits,
forget about the smart idle wakeup bit even if it is supported by
UART IP block. This will lead to missing the module wakeup on OMAP's
where the smart idle wakeup is supported.
This was the root cause of the console sluggishness issue, I have been
observing on OMAP4 devices and also can be potential reason for some
other UART wakeup issues.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/serial.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index c9503a7..b28aae1 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -108,8 +108,14 @@ static void omap_uart_set_noidle(struct platform_device
*pdev)
static void omap_uart_set_smartidle(struct platform_device *pdev)
{
struct omap_device *od = to_omap_device(pdev);
+ u8 idlemode;
- omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_SMART);
+ if (od-hwmods[0]-class-sysc-idlemodes SIDLE_SMART_WKUP)
+ idlemode = HWMOD_IDLEMODE_SMART_WKUP;
+ else
+ idlemode = HWMOD_IDLEMODE_SMART;
+
+ omap_hwmod_set_slave_idlemode(od-hwmods[0], idlemode);
}
#else
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: omap_hwmod: Add interface to incorporate module level wakeup
Govindraj.R govindraj.r...@ti.com writes:
From: Govindraj.R govindraj.r...@ti.com
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs. The module level wakeups are enabled by
default from bootloader,
Which bootloader? what board?
We cannot make any assumptions about what bootloader does (or doesn't
do).
There is also some default init to these PM_WKEN values in prcm_setup_regs()
for OMAP3 as well, which could be removed (at least for the UARTs) when
this is handled by the UART init code.
Kevin
however the wakeups can be enabled/disabled
using sysfs entry example for uart:
echo disabled /sys/devices/platform/omap/omap_uart.X/power/wakeup
[X=0,1,2,3]
So expand omap2 prcm structure to incorporate the PM_WKEN reg offset
and bit mask to control the module level wakeup. This info from hwmod
data can be used hwmod framework omap_hwmod_enable/disable_wakeup.
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
arch/arm/plat-omap/include/plat/omap_hwmod.h |4
4 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a5409ce..676274b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -791,6 +791,8 @@ static struct omap_hwmod omap2420_uart1_hwmod = {
.module_bit = OMAP24XX_EN_UART1_SHIFT,
.idlest_reg_id = 1,
.idlest_idle_bit = OMAP24XX_EN_UART1_SHIFT,
+ .module_wakeup_offs = PM_WKEN1,
+ .module_wakeup_bit = OMAP24XX_ST_UART1_MASK,
},
},
.slaves = omap2420_uart1_slaves,
@@ -816,6 +818,8 @@ static struct omap_hwmod omap2420_uart2_hwmod = {
.module_bit = OMAP24XX_EN_UART2_SHIFT,
.idlest_reg_id = 1,
.idlest_idle_bit = OMAP24XX_EN_UART2_SHIFT,
+ .module_wakeup_offs = PM_WKEN1,
+ .module_wakeup_bit = OMAP24XX_ST_UART2_MASK,
},
},
.slaves = omap2420_uart2_slaves,
@@ -841,6 +845,8 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
.module_bit = OMAP24XX_EN_UART3_SHIFT,
.idlest_reg_id = 2,
.idlest_idle_bit = OMAP24XX_EN_UART3_SHIFT,
+ .module_wakeup_offs = OMAP24XX_PM_WKEN2,
+ .module_wakeup_bit = OMAP24XX_ST_UART3_MASK,
},
},
.slaves = omap2420_uart3_slaves,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c4f56cb..94d4463 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -864,6 +864,8 @@ static struct omap_hwmod omap2430_uart1_hwmod = {
.module_bit = OMAP24XX_EN_UART1_SHIFT,
.idlest_reg_id = 1,
.idlest_idle_bit = OMAP24XX_EN_UART1_SHIFT,
+ .module_wakeup_offs = PM_WKEN1,
+ .module_wakeup_bit = OMAP24XX_ST_UART1_MASK,
},
},
.slaves = omap2430_uart1_slaves,
@@ -889,6 +891,8 @@ static struct omap_hwmod omap2430_uart2_hwmod = {
.module_bit = OMAP24XX_EN_UART2_SHIFT,
.idlest_reg_id = 1,
.idlest_idle_bit = OMAP24XX_EN_UART2_SHIFT,
+ .module_wakeup_offs = PM_WKEN1,
+ .module_wakeup_bit = OMAP24XX_ST_UART2_MASK,
},
},
.slaves = omap2430_uart2_slaves,
@@ -914,6 +918,8 @@ static struct omap_hwmod omap2430_uart3_hwmod = {
.module_bit = OMAP24XX_EN_UART3_SHIFT,
.idlest_reg_id = 2,
.idlest_idle_bit = OMAP24XX_EN_UART3_SHIFT,
+ .module_wakeup_offs = OMAP24XX_PM_WKEN2,
+ .module_wakeup_bit = OMAP24XX_ST_UART3_MASK,
},
},
.slaves = omap2430_uart3_slaves,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 34b9766d..9ed038d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1248,6 +1248,8 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
.module_bit = OMAP3430_EN_UART1_SHIFT,
.idlest_reg_id = 1,
.idlest_idle_bit = OMAP3430_EN_UART1_SHIFT,
+
Re: [PATCH] tty: omap-serial: Keep the wakeup mechanism enabled by default
Govindraj.R govindraj.r...@ti.com writes:
From: Govindraj.R govindraj.r...@ti.com
The wakeups can be left enabled by default and should be disabled
only when disabled from sysfs and while entering suspend.
Left enabled? That assumes something else has initizlied them, but we
can't make that assumption.
First, wakeups should be disabled when -probe has finished. Then,
they should be enabled whenever driver is in use, and disabled when
the driver is not in use.
I'm not familiar enough with uart_ops, but it looks like they should
probably be enabled in uart_ops-startup and disabled in
uart_ops-shutdown.
I've hacked up a test patch[1] which was required for module-wakeups to
work for me. I tested module-level wakeups by disabling all C-states
except C1 using the new sysfs control for disabling C-states[2].
More comments below...
Thanks to Kevin Hilman khil...@ti.com for suggesting this.
Discussion References:
http://www.spinics.net/lists/linux-omap/msg67764.html
http://www.spinics.net/lists/linux-omap/msg67838.html
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
drivers/tty/serial/omap-serial.c | 30 +++---
1 files changed, 11 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index d00b38e..4a92447 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -930,13 +930,6 @@ serial_omap_pm(struct uart_port *port, unsigned int
state,
serial_out(up, UART_EFR, efr);
serial_out(up, UART_LCR, 0);
- if (!device_may_wakeup(up-pdev-dev)) {
- if (!state)
- pm_runtime_forbid(up-pdev-dev);
- else
- pm_runtime_allow(up-pdev-dev);
- }
-
pm_runtime_put(up-pdev-dev);
}
@@ -1184,10 +1177,16 @@ static struct uart_driver serial_omap_reg = {
static int serial_omap_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
+ struct omap_uart_port_info *pdata = dev-platform_data;
if (up) {
uart_suspend_port(serial_omap_reg, up-port);
flush_work_sync(up-qos_work);
+
+ if (!device_may_wakeup(dev)) {
+ pdata-enable_wakeup(up-pdev, false);
Should check for the presence of pdata-enable_wakeup() before calling.
Same thing below.
+ up-wakeups_enabled = false;
+ }
}
return 0;
@@ -1582,18 +1581,6 @@ static int serial_omap_runtime_suspend(struct device
*dev)
if (pdata-get_context_loss_count)
up-context_loss_cnt = pdata-get_context_loss_count(dev);
- if (device_may_wakeup(dev)) {
- if (!up-wakeups_enabled) {
- pdata-enable_wakeup(up-pdev, true);
- up-wakeups_enabled = true;
- }
- } else {
- if (up-wakeups_enabled) {
- pdata-enable_wakeup(up-pdev, false);
- up-wakeups_enabled = false;
- }
- }
-
/* Errata i291 */
if (up-use_dma pdata-set_forceidle
(up-errata UART_ERRATA_i291_DMA_FORCEIDLE))
@@ -1618,6 +1605,11 @@ static int serial_omap_runtime_resume(struct device
*dev)
serial_omap_restore_context(up);
}
+ if (!up-wakeups_enabled) {
+ pdata-enable_wakeup(up-pdev, true);
+ up-wakeups_enabled = true;
+ }
You put the disable in -suspend, but the enable in -runtime_resume.
Doesn't this belong in -resume ?
Kevin
/* Errata i291 */
if (up-use_dma pdata-set_noidle
(up-errata UART_ERRATA_i291_DMA_FORCEIDLE))
[1] Feel free to fold this into your original patch.
From 8a4a24998aaf35240f0010b172537da64351a7d6 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Tue, 17 Apr 2012 16:24:05 -0700
Subject: [PATCH] omap-serial: fix default wakeup settings
---
drivers/tty/serial/omap-serial.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 4a92447..6458ec9 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -511,6 +511,7 @@ static void serial_omap_break_ctl(struct uart_port *port,
int break_state)
static int serial_omap_startup(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
unsigned long flags = 0;
int retval;
@@ -525,6 +526,9 @@ static int serial_omap_startup(struct uart_port *port)
dev_dbg(up-port.dev, serial_omap_startup+%d\n, up-port.line);
[GIT PULL] ARM: OMAP2+: resolve some sparse, cppcheck warnings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e:
Linux 3.4-rc2 (2012-04-07 18:30:41 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending
tags/omap-cleanup-a2-for-3.5
for you to fetch changes up to eeb3711b89d68e147e05e7b43a49ecc5009dc157:
ARM: OMAP2+: clean up some cppcheck warnings (2012-04-17 15:50:47 -0600)
-
Resolve static analysis warnings generated by files in
arch/arm/mach-omap1, arch/arm/mach-omap2, and arch/arm/plat-omap.
Fixes all but one sparse warning and most of the useful
cppcheck warnings (excepting the warnings generated by the
dmtimer integration code which is going up via 3.4-rc fixes)
-
This version drops the OMAP1 dmtimer integration patch (ARM: OMAP1:
DMTIMER: fix broken timer clock source selection) that will go
upstream during 3.4-rc fixes. There are no other changes from the
previous branch.
The previous version of this series has been test-booted on 5912OSK,
N800, CM-T3517, 3530ES3.0 Beagle, 37xx EVM, and 4430ES2 Panda. A few
minor notes: N800 here is not mounting MMC with or without this
series, this is probably due to a problem with my local N800 test
setup which has recently changed. Also CM-T3517 does not boot to
userspace either with or without this series.
Boot transcripts of the previous version can be found at:
http://www.pwsan.com/omap/bootlogs/20120417/sparse_cppcheck_cleanup_3.5__0b93afd5d945a8c002f4d380a88b5d7a61c49289/
object size (delta in bytes from v3.4-rc2
(0034102808e0dbbf3a2394b82b1bb40b5778de9e)):
textdata bss total kernel
-76 +24 0 -52 5912osk_testconfig/vmlinux
-100 -8 0-108 n800_multi_omap2xxx/vmlinux
-68 -8 0 -76 n800_testconfig/vmlinux
-216 +56 -32-192 omap1_defconfig/vmlinux
-148 +32 0-116 omap2_4_testconfig/vmlinux
-212 0 0-212 omap2plus_defconfig/vmlinux
-148 0 0-148 omap2plus_no_pm/vmlinux
-152 0 0-152 omap3_4_testconfig/vmlinux
-100 -8 0-108 omap3_testconfig/vmlinux
-188 -24 0-212 omap4_testconfig/vmlinux
Paul Walmsley (11):
ARM: OMAP2+: declare file-local functions as static
ARM: OMAP: add includes for missing prototypes
ARM: OMAP1: OCPI: move to mach-omap1/
ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus
ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse
ARM: OMAP: fix 'using plain integer as NULL pointer' sparse warnings
ARM: OMAP: OCM RAM: use memset_io() when clearing SRAM
ARM: OMAP: DMA: use constant array maximum, drop some LCD DMA code
ARM: OMAP: USB: remove unnecessary sideways include
ARM: OMAP1: board files: deduplicate and clean some NAND-related code
ARM: OMAP2+: clean up some cppcheck warnings
arch/arm/mach-omap1/Makefile | 13 ++---
arch/arm/mach-omap1/ams-delta-fiq.c |2 +-
arch/arm/mach-omap1/board-fsample.c | 16 +--
arch/arm/mach-omap1/board-h2.c | 17 +---
arch/arm/mach-omap1/board-h3.c | 16 +--
arch/arm/mach-omap1/board-nand.c | 37 ++
arch/arm/mach-omap1/board-palmz71.c |4 +--
arch/arm/mach-omap1/board-perseus2.c | 16 +--
arch/arm/mach-omap1/clock.c |3 +--
arch/arm/mach-omap1/common.h | 11 +++-
arch/arm/mach-omap1/fpga.c |2 +-
arch/arm/mach-omap1/id.c |2 ++
arch/arm/mach-omap1/io.c |3 +--
arch/arm/mach-omap1/irq.c|2 ++
arch/arm/mach-omap1/lcd_dma.c|7 +
arch/arm/{plat-omap = mach-omap1}/ocpi.c|7 +++--
arch/arm/mach-omap1/pm.c |9 +++
arch/arm/mach-omap1/reset.c |2 ++
arch/arm/mach-omap1/timer.c |3 +--
arch/arm/mach-omap1/usb.c|3 +++
arch/arm/mach-omap2/am35xx-emac.c| 37 --
arch/arm/mach-omap2/board-omap3evm.c |8 +++---
arch/arm/mach-omap2/board-omap4panda.c |8 +++---
arch/arm/mach-omap2/board-rx51-peripherals.c |4 +--
arch/arm/mach-omap2/board-zoom-display.c |1 +
arch/arm/mach-omap2/common.h |2 --
arch/arm/mach-omap2/devices.c|7 +++--
arch/arm/mach-omap2/gpio.c |2 +-
arch/arm/mach-omap2/gpmc-onenand.c |3 +--
arch/arm/mach-omap2/gpmc.c |3 +--
arch/arm/mach-omap2/hwspinlock.c |2 +-
arch/arm/mach-omap2/io.c
Re: [PATCH 2/7] UART: OMAP: Cut the clock in the error cases
Shubhrajyoti D shubhrajy...@ti.com writes:
In the error cases the clock cut is missed. This patch intends to fix the
same.
Please change the references to 'cut clocks' in subject/changelog here
(and in other patches) to use runtime suspend instead. First, runtime PM
calls do more than cut clocks, but they only do so when
usecounting/autosuspend timeouts permit.
Cc: sta...@vger.kernel.org
Please hold off on Cc'ing stable until your patches are reviewed and accepted.
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/tty/serial/omap-serial.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index fe099bb..10e80bb 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -319,6 +319,8 @@ static void serial_omap_start_tx(struct uart_port *port)
if (ret 0) {
serial_omap_enable_ier_thri(up);
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
Why the autosuspend version here?
Kevin
return;
}
}
@@ -1029,8 +1031,10 @@ static int serial_omap_poll_get_char(struct uart_port
*port)
pm_runtime_get_sync(up-pdev-dev);
status = serial_in(up, UART_LSR);
- if (!(status UART_LSR_DR))
+ if (!(status UART_LSR_DR)) {
+ pm_runtime_put(up-pdev-dev);
return NO_POLL_CHAR;
+ }
status = serial_in(up, UART_RX);
pm_runtime_put(up-pdev-dev);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: OMAP: Add platform devices for ASoC HDMI drivers
This set of patches is intended to add the platform devices for the ASoC HDMI drivers when not using device tree. For this, I took an approach similar to DMIC and McPDM by creating a dedicated functions to create the devices. I included the device for the CPU DAI driver, omap-hdmi-audio-dai, and the device for the machine driver, omap-hdmi-audio, in devices.c to reflect the fact that any OMAP4 (and OMAP5 in the future) has HDMI IP. I put the device for the codec in the board file to reflect the fact that not necessarily all the boards with OMAP4/5 have the HDMI output wired. Best regards Ricardo Ricardo Neri (3): ARM: OMAP: devices: Register platform devices for HDMI audio ARM: OMAP4: board-4430sdp: Register platform device for HDMI audio codec ARM: OMAP4: board-omap4panda: Register platform device for HDMI audio codec arch/arm/mach-omap2/board-4430sdp.c|6 ++ arch/arm/mach-omap2/board-omap4panda.c |6 ++ arch/arm/mach-omap2/devices.c | 31 +++ 3 files changed, 43 insertions(+), 0 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 3/3] ARM: OMAP4: board-omap4panda: Register platform device for HDMI audio codec
Add platform device registratation for HDMI audio codec. This is to
be able to transmit audio through the HDMI output featured in Pandaboard
and PandaboardES boards.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d8c0e89..07dd0e4 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -116,6 +116,11 @@ static struct platform_device panda_abe_audio = {
},
};
+static struct platform_device panda_hdmi_audio_codec = {
+ .name = hdmi-audio-codec,
+ .id = -1,
+};
+
static struct platform_device btwilink_device = {
.name = btwilink,
.id = -1,
@@ -125,6 +130,7 @@ static struct platform_device *panda_devices[] __initdata =
{
leds_gpio,
wl1271_device,
panda_abe_audio,
+ panda_hdmi_audio_codec,
btwilink_device,
};
--
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/3] ARM: OMAP4: board-4430sdp: Register platform device for HDMI audio codec
Add platform device registratation for HDMI audio codec. This is to
be able to transmit audio through the HDMI output featured in SDP4430
and Blaze boards.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a39fc4b..3f26da2 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -383,6 +383,11 @@ static struct platform_device sdp4430_dmic_codec = {
.id = -1,
};
+static struct platform_device sdp4430_hdmi_audio_codec = {
+ .name = hdmi-audio-codec,
+ .id = -1,
+};
+
static struct omap_abe_twl6040_data sdp4430_abe_audio_data = {
.card_name = SDP4430,
.has_hs = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
@@ -417,6 +422,7 @@ static struct platform_device *sdp4430_devices[] __initdata
= {
sdp4430_vbat,
sdp4430_dmic_codec,
sdp4430_abe_audio,
+ sdp4430_hdmi_audio_codec,
};
static struct omap_musb_board_data musb_board_data = {
--
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] ALSA: Add definitions for CEA-861 Audio InfoFrames
Along with the IEC-60958 channel status word, CEA-861 Audio InfoFrames
are used in HDMI and DisplayPort to describe the parameters of the audio
stream. Hence, drivers for such devices may use these definitions to, for
instance, fill a CEA-861 data structure and pass it to a display driver
to configure an IP.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
include/sound/asound.h | 14 ++
include/sound/asoundef.h | 41 +
2 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/include/sound/asound.h b/include/sound/asound.h
index a2e4ff5..0876a1e 100644
--- a/include/sound/asound.h
+++ b/include/sound/asound.h
@@ -70,6 +70,20 @@ struct snd_aes_iec958 {
/
* *
+ *CEA-861 Audio InfoFrame. Used in HDMI and DisplayPort
*
+ * *
+ /
+
+struct snd_cea_861_aud_if {
+ unsigned char db1_ct_cc; /* coding type and channel count */
+ unsigned char db2_sf_ss; /* sample frequency and size */
+ unsigned char db3; /* not used, all zeros */
+ unsigned char db4_ca; /* channel allocation code */
+ unsigned char db5_dminh_lsv; /* downmix inhibit level-shit values */
+};
+
+/
+ * *
* Section for driver hardware dependent interface - /dev/snd/hw? *
* *
/
diff --git a/include/sound/asoundef.h b/include/sound/asoundef.h
index 20ebf32..bb05c02 100644
--- a/include/sound/asoundef.h
+++ b/include/sound/asoundef.h
@@ -170,6 +170,47 @@
#define IEC958_AES5_CON_CGMSA_COPYNOMORE (20)/* condition not be
used */
#define IEC958_AES5_CON_CGMSA_COPYNEVER(30) /* no copying is
permitted */
+/
+ * *
+ *CEA-861 Audio InfoFrame. Used in HDMI and DisplayPort
*
+ * *
+ /
+#define CEA861_AUDIO_INFOFRAME_DB1CC (70) /* mask - channel count
*/
+#define CEA861_AUDIO_INFOFRAME_DB1CT (0xf4) /* mask - coding type
*/
+#define CEA861_AUDIO_INFOFRAME_DB1CT_FROM_STREAM (04) /* refer to stream */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_IEC60958 (14) /* IEC-60958 L-PCM */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_AC3 (24) /* AC-3 */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_MPEG1 (34) /* MPEG1 Layers 1 2 */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_MP3 (44) /* MPEG1 Layer 3 */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_MPEG2_MULTICH (54) /* MPEG2
Multichannel */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_AAC (64) /* AAC */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_DTS (74) /* DTS */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_ATRAC (84) /* ATRAC */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_ONEBIT(94) /* One Bit Audio */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_DOLBY_DIG_PLUS (104) /* Dolby Digital +
*/
+#define CEA861_AUDIO_INFOFRAME_DB1CT_DTS_HD(114) /* DTS-HD */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_MAT (124) /* MAT (MLP) */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_DST (134) /* DST */
+#define CEA861_AUDIO_INFOFRAME_DB1CT_WMA_PRO (144) /* WMA Pro */
+#define CEA861_AUDIO_INFOFRAME_DB2SF (72) /* mask - sample
frequency */
+#define CEA861_AUDIO_INFOFRAME_DB2SF_FROM_STREAM (02) /* refer to stream */
+#define CEA861_AUDIO_INFOFRAME_DB2SF_32000 (12) /* 32kHz */
+#define CEA861_AUDIO_INFOFRAME_DB2SF_44100 (22) /* 44.1kHz */
+#define CEA861_AUDIO_INFOFRAME_DB2SF_48000 (32) /* 48kHz */
+#define CEA861_AUDIO_INFOFRAME_DB2SF_88200 (42) /* 88.2kHz */
+#define CEA861_AUDIO_INFOFRAME_DB2SF_96000 (52) /* 96kHz */
+#define CEA861_AUDIO_INFOFRAME_DB2SF_176400(62) /* 176.4kHz */
+#define CEA861_AUDIO_INFOFRAME_DB2SF_192000(72) /* 192kHz */
+#define CEA861_AUDIO_INFOFRAME_DB2SS (30) /* mask - sample size */
+#define CEA861_AUDIO_INFOFRAME_DB2SS_FROM_STREAM (00) /* refer to stream */
+#define CEA861_AUDIO_INFOFRAME_DB2SS_16BIT (10) /* 16 bits */
+#define CEA861_AUDIO_INFOFRAME_DB2SS_20BIT (20) /* 20 bits */
+#define CEA861_AUDIO_INFOFRAME_DB2SS_24BIT (30) /* 24 bits */
+#define CEA861_AUDIO_INFOFRAME_DB5_DM_INH (17) /* mask - inhibit
downmixing */
+#define CEA861_AUDIO_INFOFRAME_DB5_DM_INH_PERMITTED (07) /*
