Re: [PATCH 4/7] usb: otg: twl4030-usb: poll for ID disconnect
Hi
just one comment.
On 10/03/13 02:07, Grazvydas Ignotas wrote:
On pandora, STS_USB interrupt doesn't arrive on USB host cable disconnect
for some reason while VBUS is driven by twl itself, but STS_HW_CONDITIONS
is updated correctly. It does work fine when PHY is powered down though.
To work around that we have to poll.
TI PSP kernels have similar workarounds, so (many?) more boards are likely
affected.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/otg/twl4030-usb.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 90a19ff..2c1c27e 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -163,6 +163,8 @@ struct twl4030_usb {
boolvbus_supplied;
u8 asleep;
boolirq_enabled;
+
+ struct delayed_work id_workaround_work;
};
/* internal define on top of container_of */
@@ -412,6 +414,16 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
__twl4030_phy_resume(twl);
twl-asleep = 0;
dev_dbg(twl-dev, %s\n, __func__);
+
+ /*
+ * XXX When VBUS gets driven after musb goes to A mode,
+ * ID_PRES related interrupts no longer arrive, why?
+ * Register itself is updated fine though, so we must poll.
+ */
+ if (twl-linkstat == OMAP_MUSB_ID_GROUND) {
+ cancel_delayed_work(twl-id_workaround_work);
+ schedule_delayed_work(twl-id_workaround_work, HZ);
+ }
}
static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
@@ -513,6 +525,28 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
return IRQ_HANDLED;
}
+static void twl4030_id_workaround_work(struct work_struct *work)
+{
+ struct twl4030_usb *twl = container_of(work, struct twl4030_usb,
+ id_workaround_work.work);
+ enum omap_musb_vbus_id_status status_prev = twl-linkstat;
+ enum omap_musb_vbus_id_status status;
+
+ status = twl4030_usb_linkstat(twl);
+ if (status != status_prev) {
+ dev_dbg(twl-dev, handle missing status change: %d-%d\n,
+ status_prev, status);
+ twl-linkstat = status_prev;
+ twl4030_usb_irq(0, twl);
As I understand from the subject this happen in Pandora board and
many boards can be affected.
do you need any protection between the worker and the irq when
the irq arrive as expected?
+ }
+
+ /* don't schedule during sleep - irq works right then */
+ if (status == OMAP_MUSB_ID_GROUND !twl-asleep) {
+ cancel_delayed_work(twl-id_workaround_work);
+ schedule_delayed_work(twl-id_workaround_work, HZ);
+ }
+}
+
static void twl4030_usb_phy_init(struct twl4030_usb *twl)
{
enum omap_musb_vbus_id_status status;
@@ -613,6 +647,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
+ INIT_DELAYED_WORK(twl-id_workaround_work, twl4030_id_workaround_work);
+
err = twl4030_usb_ldo_init(twl);
if (err) {
dev_err(pdev-dev, ldo init failed\n);
@@ -653,6 +689,7 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
struct twl4030_usb *twl = platform_get_drvdata(pdev);
int val;
+ cancel_delayed_work(twl-id_workaround_work);
free_irq(twl-irq, twl);
device_remove_file(twl-dev, dev_attr_vbus);
Michael
--
To unsubscribe 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 4/7] usb: otg: twl4030-usb: poll for ID disconnect
On Sun, Mar 10, 2013 at 1:03 PM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
Hi
just one comment.
On 10/03/13 02:07, Grazvydas Ignotas wrote:
On pandora, STS_USB interrupt doesn't arrive on USB host cable disconnect
for some reason while VBUS is driven by twl itself, but STS_HW_CONDITIONS
is updated correctly. It does work fine when PHY is powered down though.
To work around that we have to poll.
TI PSP kernels have similar workarounds, so (many?) more boards are likely
affected.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/otg/twl4030-usb.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 90a19ff..2c1c27e 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
...
@@ -513,6 +525,28 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
return IRQ_HANDLED;
}
+static void twl4030_id_workaround_work(struct work_struct *work)
+{
+ struct twl4030_usb *twl = container_of(work, struct twl4030_usb,
+ id_workaround_work.work);
+ enum omap_musb_vbus_id_status status_prev = twl-linkstat;
+ enum omap_musb_vbus_id_status status;
+
+ status = twl4030_usb_linkstat(twl);
+ if (status != status_prev) {
+ dev_dbg(twl-dev, handle missing status change: %d-%d\n,
+ status_prev, status);
+ twl-linkstat = status_prev;
+ twl4030_usb_irq(0, twl);
As I understand from the subject this happen in Pandora board and
many boards can be affected.
do you need any protection between the worker and the irq when
the irq arrive as expected?
Hmm I guess i do, I'll add some locking in v2, which I'll send after
collecting more feedback.
Michael
--
Gražvydas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ARM: OMAP: gpmc: request CS address space for ethernet chips
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the GPMC as a data bus.
The actual mapping between the GPMC address space and OMAP2+
address space is made using the GPMC DT ranges property.
But also a explicit call to gpmc_cs_request() is needed.
So, this patch allows an ethernet chip to be defined as an
GPMC child node an its chip-select memory address be requested.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Jon,
This patch assumes that we have solved somehow the issue that a
call to request_irq() is needed before before using a GPIO as an
IRQ and this is no longer the case when using from Device Trees.
Anyway, this is independent as how we solve this, whether is
using Jan's patch [1], adding a .request function pointer to
irq_chip as suggested by Stephen [2], or any other approach.
[1]: https://patchwork.kernel.org/patch/2009331/
[2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
arch/arm/mach-omap2/gpmc.c | 45
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4fe9ee7..d1bf48b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -29,6 +29,7 @@
#include linux/of.h
#include linux/of_mtd.h
#include linux/of_device.h
+#include linux/of_address.h
#include linux/mtd/nand.h
#include linux/platform_data/mtd-nand-omap2.h
@@ -1296,6 +1297,42 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static int gpmc_probe_ethernet_child(struct platform_device *pdev,
+struct device_node *child)
+{
+ int ret, cs;
+ unsigned long base;
+ struct resource res;
+ struct platform_device *of_dev;
+
+ if (of_property_read_u32(child, reg, cs) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(child, 0, res)) {
+ dev_err(pdev-dev, %s has malformed 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ ret = gpmc_cs_request(cs, resource_size(res), base);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(pdev-dev, cannot request GPMC CS %d\n, cs);
+ return ret;
+ }
+
+ of_dev = of_platform_device_create(child, NULL, pdev-dev);
+ if (!of_dev) {
+ dev_err(pdev-dev, cannot create platform device for %s\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1326,6 +1363,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
}
+
+ for_each_node_by_name(child, ethernet) {
+ ret = gpmc_probe_ethernet_child(pdev, child);
+ if (ret 0) {
+ of_node_put(child);
+ return ret;
+ }
+ }
return 0;
}
#else
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] ARM: OMAP5: PM: Enables ES2 PM mode by default
On Monday 04 March 2013 11:59 PM, Nishanth Menon wrote: On 11:17-20130302, Santosh Shilimkar wrote: On Saturday 02 March 2013 01:07 AM, Nishanth Menon wrote: On 17:40-20130301, Santosh Shilimkar wrote: Enables MPUSS ES2 power management mode using ES2_PM_MODE in AMBA_IF_MODE register. [..] diff --git a/arch/arm/mach-omap2/omap-wakeupgen.h b/arch/arm/mach-omap2/omap-wakeupgen.h index b0fd16f..b3c8ecc 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.h +++ b/arch/arm/mach-omap2/omap-wakeupgen.h @@ -27,6 +27,7 @@ #define OMAP_WKG_ENB_E_1 0x420 #define OMAP_AUX_CORE_BOOT_0 0x800 #define OMAP_AUX_CORE_BOOT_1 0x804 +#define OMAP_AMBA_IF_MODE 0x80c #define OMAP_PTMSYNCREQ_MASK 0xc00 #define OMAP_PTMSYNCREQ_EN0xc04 #define OMAP_TIMESTAMPCYCLELO 0xc08 Curious, I see OMAP5_AMBA_IF_MODE_OFFSET in arch/arm/mach-omap2/omap4-sar-layout.h if we dont save new modified contents there, Wont restore logic just reset it back to 0? It is already restored in the wakeup-gen restore code. I apologize, I do not see it in: https://github.com/SantoshShilimkar/linux/blob/testing/3.10/omap5-int-rebuild/arch/arm/mach-omap2/omap-wakeupgen.c I might have expected an save of val to sar offset to ensure this is done, but since you indicate this is in wakeupgen restore logic, which I presume is done by ROM, we might expect an write to sar_base + OMAP5_AMBA_IF_MODE_OFFSET with the val for it to function? Arr.. Looks like I missed the hunk while updating the patches. Will fix the appropriate patch which updates the wakeupgen SAR offsets. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: hwmod data: disable MIDLEMODE control for musb
Hi Gražvydas, On Sun, 10 Mar 2013, Grazvydas Ignotas wrote: For some unknown reason, allowing hwmod to control MIDLEMODE causes core_pwrdm to not hit idle states for musb in DM3730 at least. I've verified that setting any MIDLEMODE value other than force standby before enabling the device causes subsequent suspend attempts to fail with core_pwrdm not entering idle states, even if the driver is unloaded and force standby is restored before suspend attempt. Ugh sounds like a broken bootloader/previous OS could easily block full chip idle in this case :-( Does that match your understanding? That, even if the new kernel does everything right in terms of initialization and reset, the PRCM's perception of whether the device is in STANDBY is permanently stuck? Keeping the register set at force standby (reset value) makes it work and device still functions properly. musb has driver-controlled OTG_FORCESTDBY register that controls MSTANDBY signal, so perhaps MIDLEMODE is not even needed? Note that TI PSP kernels also have similar workarounds. Would like to get your opinion on a different implementation. For other situations where IP blocks don't work in the standard, expected way, we've defined hwmod flags for those situations, like HWMOD_SWSUP_*, and HWMOD_NO_OCP_AUTOIDLE. The motivation is to affirmatively mark IP blocks that don't work as expected, rather than changing the existing, documented hardware bits, which are ideally autogenerated. So what do you think about adding a hwmod flag, HWMOD_FORCE_MSTDBY, and using that in the hwmod code to program the MSTDBYMODE to FORCE_STANDBY and then skipping all other attempts to write to it? - Paul
Re: OMAP4 PM bootloader dependency problems
Hi Jon, sorry for the delay, On Tue, 5 Feb 2013, Jon Hunter wrote: I noticed on my OMAP4430 SDP that in suspend L3INIT was failing to enter retention state. I am not sure if this is the same problem that you are seeing or not. However, I found that the reason the L3INIT was not entering retention on this board was because the USB DPLL was not locked by the bootloader on this board. On my panda the USB DPLL is locked the L3INIT is entering suspend. I crafted the following which is working on my omap4430 panda, sdp and omap4460 panda. Let me know what you think ... Looks fine to me. It doesn't fix the problem I'm seeing with OMAP4 L3INIT, unfortunately. But it sounds like it fixes a problem for you -- which means it probably fixes something for other people too. Queued for v3.9-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
Hi Jon,
On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter jon-hun...@ti.com wrote:
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM and uses the TWL4030 power management IC.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3430-sdp.dts | 46
2 files changed, 47 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..89013ed 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+ omap3430-sdp.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
new file mode 100644
index 000..be0650d
--- /dev/null
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = TI OMAP3430 SDP;
+ compatible = ti,omap3430-sdp, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
No need of interrupt-parent = intc as it is with root node
already.
Thanks,
Anil
[...]
--
To unsubscribe 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 4/8] memory: emif: Handle devices which are not rated for 85C
From: Nishanth Menon n...@ti.com
As per JESD209-2E specification for LPDDR2,
http://www.jedec.org/standards-documents/results/jesd209-2E
Table 73, LPDDR2 memories come in two flavors - Standard and
Extended. The Standard types can operate from -25C to +85C
However, beyond that and upto +105C can only be supported by
Extended types.
Unfortunately, it seems there is no info in MR0(device info) or
MR[1,2](device feature) for run time detection of this capability
as far as seen on the spec. Hence, we provide a custom_config
flag to be populated by platforms which have these extended
type memories.
For the Standard memories, we need to consider MR4 notifications
of temperature triggers 85C as equivalent to thermal shutdown
events (equivalent to Spec specified thermal shutdown events for
extended parts).
Reported-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c | 27 +++
include/linux/platform_data/emif_plat.h |1 +
2 files changed, 28 insertions(+)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 37e0c77..927fb55 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -914,6 +914,7 @@ static irqreturn_t handle_temp_alert(void __iomem *base,
struct emif_data *emif)
{
u32 old_temp_level;
irqreturn_t ret = IRQ_HANDLED;
+ struct emif_custom_configs *custom_configs;
spin_lock_irqsave(emif_lock, irq_state);
old_temp_level = emif-temperature_level;
@@ -926,6 +927,29 @@ static irqreturn_t handle_temp_alert(void __iomem *base,
struct emif_data *emif)
goto out;
}
+ custom_configs = emif-plat_data-custom_configs;
+
+ /*
+* IF we detect higher than nominal rating from DDR sensor
+* on an unsupported DDR part, shutdown system
+*/
+ if (custom_configs !(custom_configs-mask
+ EMIF_CUSTOM_CONFIG_EXTENDED_TEMP_PART)) {
+ if (emif-temperature_level = SDRAM_TEMP_HIGH_DERATE_REFRESH) {
+ dev_err(emif-dev,
+ %s:NOT Extended temperature capable memory.
+ Converting MR4=0x%02x as shutdown event\n,
+ __func__, emif-temperature_level);
+ /*
+* Temperature far too high - do kernel_power_off()
+* from thread context
+*/
+ emif-temperature_level = SDRAM_TEMP_VERY_HIGH_SHUTDOWN;
+ ret = IRQ_WAKE_THREAD;
+ goto out;
+ }
+ }
+
if (emif-temperature_level old_temp_level ||
emif-temperature_level == SDRAM_TEMP_VERY_HIGH_SHUTDOWN) {
/*
@@ -1224,6 +1248,9 @@ static void __init_or_module of_get_custom_configs(struct
device_node *np_emif,
cust_cfgs-temp_alert_poll_interval_ms = *poll_intvl;
}
+ if (of_find_property(np_emif, extended-temp-part, len))
+ cust_cfgs-mask |= EMIF_CUSTOM_CONFIG_EXTENDED_TEMP_PART;
+
if (!is_custom_config_valid(cust_cfgs, emif-dev)) {
devm_kfree(emif-dev, cust_cfgs);
return;
diff --git a/include/linux/platform_data/emif_plat.h
b/include/linux/platform_data/emif_plat.h
index 03378ca..5c19a2a 100644
--- a/include/linux/platform_data/emif_plat.h
+++ b/include/linux/platform_data/emif_plat.h
@@ -40,6 +40,7 @@
/* Custom config requests */
#define EMIF_CUSTOM_CONFIG_LPMODE 0x0001
#define EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL0x0002
+#define EMIF_CUSTOM_CONFIG_EXTENDED_TEMP_PART 0x0004
#ifndef __ASSEMBLY__
/**
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] memory: emif: fix timings initialization issue
From: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
The issue was that only the first timings table was added to the
emif platform data at the emif driver registration. All other
timings tables was filled with zeros. Now all emif timings table
are added to the platform data.
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 02a94fc..f75806a 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -1463,7 +1463,7 @@ static struct emif_data *__init_or_module
get_device_details(
if (pd-timings) {
temp = devm_kzalloc(dev, size, GFP_KERNEL);
if (temp) {
- memcpy(temp, pd-timings, sizeof(*pd-timings));
+ memcpy(temp, pd-timings, size);
pd-timings = temp;
} else {
dev_warn(dev, %s:%d: allocation error\n, __func__,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] memory: emif: Load the correct custom config values from dt
of_get_property returns value in Big Endian format.
Before using this value it should be converted to little endian
using be32_to_cpup().
Custom configs of emif are read from dt using of_get_property,
but these are not converted to litte endian format.
Correcting the same here.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 119503a..4866f1b 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -1258,7 +1258,7 @@ static void __init_or_module of_get_custom_configs(struct
device_node *np_emif,
{
struct emif_custom_configs *cust_cfgs = NULL;
int len;
- const int *lpmode, *poll_intvl;
+ const __be32*lpmode, *poll_intvl;
lpmode = of_get_property(np_emif, low-power-mode, len);
poll_intvl = of_get_property(np_emif, temp-alert-poll-interval, len);
@@ -1272,7 +1272,7 @@ static void __init_or_module of_get_custom_configs(struct
device_node *np_emif,
if (lpmode) {
cust_cfgs-mask |= EMIF_CUSTOM_CONFIG_LPMODE;
- cust_cfgs-lpmode = *lpmode;
+ cust_cfgs-lpmode = be32_to_cpup(lpmode);
of_property_read_u32(np_emif,
low-power-mode-timeout-performance,
cust_cfgs-lpmode_timeout_performance);
@@ -1287,7 +1287,8 @@ static void __init_or_module of_get_custom_configs(struct
device_node *np_emif,
if (poll_intvl) {
cust_cfgs-mask |=
EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL;
- cust_cfgs-temp_alert_poll_interval_ms = *poll_intvl;
+ cust_cfgs-temp_alert_poll_interval_ms =
+ be32_to_cpup(poll_intvl);
}
if (of_find_property(np_emif, extended-temp-part, len))
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] memory: emif: handle overflow for timing for LP mode
From: Nishanth Menon n...@ti.com
In case the custom timings provide values which overflow
the maximum possible field value, warn and use maximum
permissible value.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 16f5089..37e0c77 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -715,6 +715,8 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
u32 timeout_perf= EMIF_LP_MODE_TIMEOUT_PERFORMANCE;
u32 timeout_pwr = EMIF_LP_MODE_TIMEOUT_POWER;
u32 freq_threshold = EMIF_LP_MODE_FREQ_THRESHOLD;
+ u32 mask;
+ u8 shift;
struct emif_custom_configs *cust_cfgs = emif-plat_data-custom_configs;
@@ -739,27 +741,45 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
switch (lpmode) {
case EMIF_LP_MODE_CLOCK_STOP:
- pwr_mgmt_ctrl = (timeout CS_TIM_SHIFT) |
- SR_TIM_MASK | PD_TIM_MASK;
+ shift = CS_TIM_SHIFT;
+ mask = CS_TIM_MASK;
break;
case EMIF_LP_MODE_SELF_REFRESH:
/* Workaround for errata i735 */
if (timeout 6)
timeout = 6;
- pwr_mgmt_ctrl = (timeout SR_TIM_SHIFT) |
- CS_TIM_MASK | PD_TIM_MASK;
+ shift = SR_TIM_SHIFT;
+ mask = SR_TIM_MASK;
break;
case EMIF_LP_MODE_PWR_DN:
- pwr_mgmt_ctrl = (timeout PD_TIM_SHIFT) |
- CS_TIM_MASK | SR_TIM_MASK;
+ shift = PD_TIM_SHIFT;
+ mask = PD_TIM_MASK;
break;
case EMIF_LP_MODE_DISABLE:
default:
- pwr_mgmt_ctrl = CS_TIM_MASK |
- PD_TIM_MASK | SR_TIM_MASK;
+ mask = 0;
+ shift = 0;
+ break;
+ }
+ /* Round to maximum in case of overflow, BUT warn! */
+ if (lpmode != EMIF_LP_MODE_DISABLE timeout mask shift) {
+ pr_err(TIMEOUT Overflow - lpmode=%d perf=%d pwr=%d freq=%d\n,
+ lpmode,
+ timeout_perf,
+ timeout_pwr,
+ freq_threshold);
+ WARN(1, timeout=0x%02x greater than 0x%02x. Using max\n,
+timeout, mask shift);
+ timeout = mask shift;
}
+ /* Setup required timing */
+ pwr_mgmt_ctrl = (timeout shift) mask;
+ /* setup a default mask for rest of the modes */
+ pwr_mgmt_ctrl |= (SR_TIM_MASK | CS_TIM_MASK | PD_TIM_MASK)
+ ~mask;
+
/* No CS_TIM in EMIF_4D5 */
if (ip_rev == EMIF_4D5)
pwr_mgmt_ctrl = ~CS_TIM_MASK;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] memory: emif: use restart if power_off not present when out of spec
From: Nishanth Menon n...@ti.com
Some machine or kernel variants might have missed implementation
of power off handlers. We DONOT want to let the system be in
out of spec state in this condition. So, WARN and attempt
a machine restart in the hopes of clearing the out-of-spec
temperature condition.
NOTE: This is not the safest option, but safer than leaving the
system in unstable conditions.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 927fb55..02a94fc 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -25,6 +25,7 @@
#include linux/module.h
#include linux/list.h
#include linux/spinlock.h
+#include linux/pm.h
#include memory/jedec_ddr.h
#include emif.h
#include of_memory.h
@@ -1011,7 +1012,13 @@ static irqreturn_t emif_threaded_isr(int irq, void
*dev_id)
if (emif-temperature_level == SDRAM_TEMP_VERY_HIGH_SHUTDOWN) {
dev_emerg(emif-dev, SDRAM temperature exceeds operating
limit.. Needs shut down!!!\n);
- kernel_power_off();
+ /* If we have Power OFF ability, use it, else try restarting */
+ if (pm_power_off) {
+ kernel_power_off();
+ } else {
+ WARN(1, FIXME: NO pm_power_off!!! trying restart\n);
+ kernel_restart(SDRAM Over-temp Emergency restart);
+ }
return IRQ_HANDLED;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] memory: emif: miscellaneous bug fixes for EMIF driver
This series resolves a few minor issues for EMIF driver. Tested all patches on OMAP4430-sdp. Patch : memory: emif: setup LP settings on freq update is tested on a local tree, since freq update cannot be tested on mainline. Ambresh K (1): memory: emif: setup LP settings on freq update Grygorii Strashko (1): memory: emif: errata i743: Prohibit usage of Power-Down mode Lokesh Vutla (2): memory: emif: Correct the lpmode timeout calculation memory: emif: Load the correct custom config values from dt Nishanth Menon (3): memory: emif: handle overflow for timing for LP mode memory: emif: Handle devices which are not rated for 85C memory: emif: use restart if power_off not present when out of spec Oleksandr Dmytryshyn (1): memory: emif: fix timings initialization issue drivers/memory/emif.c | 122 +++ include/linux/platform_data/emif_plat.h |1 + 2 files changed, 108 insertions(+), 15 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] memory: emif: setup LP settings on freq update
From: Ambresh K ambr...@ti.com Program the power management shadow register on freq update Else the concept of threshold frequencies dont really matter as the system always uses the performance mode timing for LP which is programmed in at init time. Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Ambresh K ambr...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- drivers/memory/emif.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c index 622638c..16f5089 100644 --- a/drivers/memory/emif.c +++ b/drivers/memory/emif.c @@ -815,6 +815,8 @@ static void setup_registers(struct emif_data *emif, struct emif_regs *regs) writel(regs-sdram_tim2_shdw, base + EMIF_SDRAM_TIMING_2_SHDW); writel(regs-phy_ctrl_1_shdw, base + EMIF_DDR_PHY_CTRL_1_SHDW); + writel(regs-pwr_mgmt_ctrl_shdw, + base + EMIF_POWER_MANAGEMENT_CTRL_SHDW); /* Settings specific for EMIF4D5 */ if (emif-plat_data-ip_rev != EMIF_4D5) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] memory: emif: errata i743: Prohibit usage of Power-Down mode
From: Grygorii Strashko grygorii.stras...@ti.com
ERRATA DESCRIPTION :
The EMIF supports power-down state for low power. The EMIF
automatically puts the SDRAM into power-down after the memory is
not accessed for a defined number of cycles and the
EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set to 0x4.
As the EMIF supports automatic output impedance calibration, a ZQ
calibration long command is issued every time it exits active
power-down and precharge power-down modes. The EMIF waits and
blocks any other command during this calibration.
The EMIF does not allow selective disabling of ZQ calibration upon
exit of power-down mode. Due to very short periods of power-down
cycles, ZQ calibration overhead creates bandwidth issues and
increases overall system power consumption. On the other hand,
issuing ZQ calibration long commands when exiting self-refresh is
still required.
WORKAROUND :
Because there is no power consumption benefit of the power-down due
to the calibration and there is a performance risk, the guideline
is to not allow power-down state and, therefore, to not have set
the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
Signed-off-by: Vitaly Chernooky vitaly.cherno...@ti.com
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index f75806a..119503a 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -257,6 +257,41 @@ static void set_lpmode(struct emif_data *emif, u8 lpmode)
u32 temp;
void __iomem *base = emif-base;
+ /*
+* Workaround for errata i743 - LPDDR2 Power-Down State is Not
+* Efficient
+*
+* i743 DESCRIPTION:
+* The EMIF supports power-down state for low power. The EMIF
+* automatically puts the SDRAM into power-down after the memory is
+* not accessed for a defined number of cycles and the
+* EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set to 0x4.
+* As the EMIF supports automatic output impedance calibration, a ZQ
+* calibration long command is issued every time it exits active
+* power-down and precharge power-down modes. The EMIF waits and
+* blocks any other command during this calibration.
+* The EMIF does not allow selective disabling of ZQ calibration upon
+* exit of power-down mode. Due to very short periods of power-down
+* cycles, ZQ calibration overhead creates bandwidth issues and
+* increases overall system power consumption. On the other hand,
+* issuing ZQ calibration long commands when exiting self-refresh is
+* still required.
+*
+* WORKAROUND
+* Because there is no power consumption benefit of the power-down due
+* to the calibration and there is a performance risk, the guideline
+* is to not allow power-down state and, therefore, to not have set
+* the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.
+*/
+ if ((emif-plat_data-ip_rev == EMIF_4D)
+ (EMIF_LP_MODE_PWR_DN == lpmode)) {
+ WARN_ONCE(1,
+ REG_LP_MODE = LP_MODE_PWR_DN(4) is prohibited by
+ erratum i743 switch to LP_MODE_SELF_REFRESH(2)\n);
+ /* rallback LP_MODE to Self-refresh mode */
+ lpmode = EMIF_LP_MODE_SELF_REFRESH;
+ }
+
temp = readl(base + EMIF_POWER_MANAGEMENT_CONTROL);
temp = ~LP_MODE_MASK;
temp |= (lpmode LP_MODE_SHIFT);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] memory: emif: Correct the lpmode timeout calculation
The driver tries to round up the specified timeout cycles to
the next power of 2 value. But this is done wrongly.
Correcting this here.
Reported-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index df08736..622638c 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -732,9 +732,9 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
if (timeout 16) {
timeout = 0;
} else {
- timeout = __fls(timeout) - 3;
if (timeout (timeout - 1))
- timeout++;
+ timeout = 1;
+ timeout = __fls(timeout) - 3;
}
switch (lpmode) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] memory: emif: Correct the lpmode timeout calculation
minor nit.
$subject
s/Correct/Fix
On Monday 11 March 2013 10:35 AM, Lokesh Vutla wrote:
The driver tries to round up the specified timeout cycles to
the next power of 2 value. But this is done wrongly.
Correcting this here.
Change needs to be improved here. See below.
Reported-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index df08736..622638c 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -732,9 +732,9 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
if (timeout 16) {
timeout = 0;
} else {
- timeout = __fls(timeout) - 3;
if (timeout (timeout - 1))
So from the change, it appears that, the timeout
check for power of 2 should be done before updating
the variable which seems to be the right fix.
- timeout++;
+ timeout = 1;
+ timeout = __fls(timeout) - 3;
}
switch (lpmode) {
So just make changelog verbose as well as add a
comment about the calculation in the code.
Otherwise, patch looks fine to me.
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 2/8] memory: emif: setup LP settings on freq update
On Monday 11 March 2013 10:35 AM, Lokesh Vutla wrote: From: Ambresh K ambr...@ti.com Program the power management shadow register on freq update Else the concept of threshold frequencies dont really matter as the system always uses the performance mode timing for LP which is programmed in at init time. Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Ambresh K ambr...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- 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 3/8] memory: emif: handle overflow for timing for LP mode
On Monday 11 March 2013 10:36 AM, Lokesh Vutla wrote: From: Nishanth Menon n...@ti.com In case the custom timings provide values which overflow the maximum possible field value, warn and use maximum permissible value. Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- 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 10/20] OMAPDSS: Resolve channels for outputs
Hi,
On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
The DISPC channel used for each output is currently passed in panel
platform data from the board files.
To simplify this, and to make the panel drivers less dependent on OMAP,
this patch changes omapdss to resolve the channel independently. The
channel is resolved based on the OMAP version and, in case of DSI, the
DSI module id.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 37 ++-
drivers/video/omap2/dss/dsi.c | 48
drivers/video/omap2/dss/rfbi.c |2 ++
drivers/video/omap2/dss/sdi.c |2 ++
4 files changed, 84 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e282456..3261644 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
platform_device *dsidev)
return 0;
}
+/*
+ * Return a hardcoded channel for the DPI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dpi_get_channel(void)
+{
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
+ return OMAP_DSS_CHANNEL_LCD;
+
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ return OMAP_DSS_CHANNEL_LCD2;
+
+ case OMAPDSS_VER_OMAP5:
+ return OMAP_DSS_CHANNEL_LCD2;
+
+ default:
+ DSSWARN(unsupported DSS version\n);
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+}
+
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev;
DSSDBG(init_display\n);
+ dssdev-channel = dpi_get_channel();
In patch 14 of the series, we remove these dssdev-channel assignments.
I don't see the point of adding them in this patch in the first place.
The dssdev-channel assignments will not be modified in this series, so
we don't need to worry about a kernel crash or something after this patch.
I feel this patch should only add the dpi_get_channel and
dsi_get_channel funcs.
+
if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
dpi.vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
@@ -416,11 +448,6 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
dpi.vdds_dsi_reg = vdds_dsi;
}
- /*
-* XXX We shouldn't need dssdev-channel for this. The dsi pll clock
-* source for DPI is SoC integration detail, not something that should
-* be configured in the dssdev
-*/
dsidev = dpi_get_dsidev(dssdev-channel);
if (dsidev dpi_verify_dsi_pll(dsidev)) {
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 1a6ad6f..c39ca86 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4946,6 +4946,52 @@ void omapdss_dsi_set_videomode_timings(struct
omap_dss_device *dssdev,
}
EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
+/*
+ * Return a hardcoded channel for the DSI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dsi_get_channel(int module_id)
+{
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
We should remove the above case so that we hit the default case and get
a warning about omap2 not having DSI.
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
snip
Archit
--
To unsubscribe 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 4/8] memory: emif: Handle devices which are not rated for 85C
On Monday 11 March 2013 10:36 AM, Lokesh Vutla wrote: From: Nishanth Menon n...@ti.com As per JESD209-2E specification for LPDDR2, http://www.jedec.org/standards-documents/results/jesd209-2E Table 73, LPDDR2 memories come in two flavors - Standard and Extended. The Standard types can operate from -25C to +85C However, beyond that and upto +105C can only be supported by Extended types. right. Unfortunately, it seems there is no info in MR0(device info) or MR[1,2](device feature) for run time detection of this capability as far as seen on the spec. Hence, we provide a custom_config flag to be populated by platforms which have these extended type memories. For the Standard memories, we need to consider MR4 notifications of temperature triggers 85C as equivalent to thermal shutdown events (equivalent to Spec specified thermal shutdown events for extended parts). Make sense. Reported-by: Richard Woodruff r-woodru...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- Thanks for the fix. 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 5/8] memory: emif: use restart if power_off not present when out of spec
On Monday 11 March 2013 10:36 AM, Lokesh Vutla wrote:
From: Nishanth Menon n...@ti.com
Some machine or kernel variants might have missed implementation
of power off handlers. We DONOT want to let the system be in
out of spec state in this condition. So, WARN and attempt
a machine restart in the hopes of clearing the out-of-spec
temperature condition.
NOTE: This is not the safest option, but safer than leaving the
system in unstable conditions.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 927fb55..02a94fc 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -25,6 +25,7 @@
#include linux/module.h
#include linux/list.h
#include linux/spinlock.h
+#include linux/pm.h
#include memory/jedec_ddr.h
#include emif.h
#include of_memory.h
@@ -1011,7 +1012,13 @@ static irqreturn_t emif_threaded_isr(int irq, void
*dev_id)
if (emif-temperature_level == SDRAM_TEMP_VERY_HIGH_SHUTDOWN) {
dev_emerg(emif-dev, SDRAM temperature exceeds operating
limit.. Needs shut down!!!\n);
- kernel_power_off();
Extra line here would be good here.
+ /* If we have Power OFF ability, use it, else try restarting */
+ if (pm_power_off) {
+ kernel_power_off();
+ } else {
+ WARN(1, FIXME: NO pm_power_off!!! trying restart\n);
+ kernel_restart(SDRAM Over-temp Emergency restart);
+ }
return IRQ_HANDLED;
}
Otherwise,
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 6/8] memory: emif: fix timings initialization issue
$subject is too vague. What issue ?
Some thing like Fix the incorrect 'size' parameter in memcpy' etc
On Monday 11 March 2013 10:36 AM, Lokesh Vutla wrote:
From: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
The issue was that only the first timings table was added to the
emif platform data at the emif driver registration. All other
timings tables was filled with zeros. Now all emif timings table
are added to the platform data.
Luckily, most of the cases, first table has been re-used for
symmetric configuration.
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 02a94fc..f75806a 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -1463,7 +1463,7 @@ static struct emif_data *__init_or_module
get_device_details(
if (pd-timings) {
temp = devm_kzalloc(dev, size, GFP_KERNEL);
if (temp) {
- memcpy(temp, pd-timings, sizeof(*pd-timings));
+ memcpy(temp, pd-timings, size);
pd-timings = temp;
} else {
dev_warn(dev, %s:%d: allocation error\n, __func__,
Patch as such looks good to me.
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 7/8] memory: emif: errata i743: Prohibit usage of Power-Down mode
On Monday 11 March 2013 10:36 AM, Lokesh Vutla wrote:
From: Grygorii Strashko grygorii.stras...@ti.com
ERRATA DESCRIPTION :
The EMIF supports power-down state for low power. The EMIF
automatically puts the SDRAM into power-down after the memory is
not accessed for a defined number of cycles and the
EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set to 0x4.
As the EMIF supports automatic output impedance calibration, a ZQ
calibration long command is issued every time it exits active
power-down and precharge power-down modes. The EMIF waits and
blocks any other command during this calibration.
The EMIF does not allow selective disabling of ZQ calibration upon
exit of power-down mode. Due to very short periods of power-down
cycles, ZQ calibration overhead creates bandwidth issues and
increases overall system power consumption. On the other hand,
issuing ZQ calibration long commands when exiting self-refresh is
still required.
WORKAROUND :
Because there is no power consumption benefit of the power-down due
to the calibration and there is a performance risk, the guideline
is to not allow power-down state and, therefore, to not have set
the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
Signed-off-by: Vitaly Chernooky vitaly.cherno...@ti.com
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Nice changelog.
drivers/memory/emif.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index f75806a..119503a 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -257,6 +257,41 @@ static void set_lpmode(struct emif_data *emif, u8 lpmode)
u32 temp;
void __iomem *base = emif-base;
+ /*
+ * Workaround for errata i743 - LPDDR2 Power-Down State is Not
+ * Efficient
+ *
+ * i743 DESCRIPTION:
+ * The EMIF supports power-down state for low power. The EMIF
+ * automatically puts the SDRAM into power-down after the memory is
+ * not accessed for a defined number of cycles and the
+ * EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set to 0x4.
+ * As the EMIF supports automatic output impedance calibration, a ZQ
+ * calibration long command is issued every time it exits active
+ * power-down and precharge power-down modes. The EMIF waits and
+ * blocks any other command during this calibration.
+ * The EMIF does not allow selective disabling of ZQ calibration upon
+ * exit of power-down mode. Due to very short periods of power-down
+ * cycles, ZQ calibration overhead creates bandwidth issues and
+ * increases overall system power consumption. On the other hand,
+ * issuing ZQ calibration long commands when exiting self-refresh is
+ * still required.
+ *
+ * WORKAROUND
+ * Because there is no power consumption benefit of the power-down due
+ * to the calibration and there is a performance risk, the guideline
+ * is to not allow power-down state and, therefore, to not have set
+ * the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.
+ */
+ if ((emif-plat_data-ip_rev == EMIF_4D)
+ (EMIF_LP_MODE_PWR_DN == lpmode)) {
Ok. So the errata is limited to only 'EMIF_4D' version and not applicable
for next EMIF version used in OMAP5 devices, right ? If yes, would be good
to just mention that in already good changelog.
+ WARN_ONCE(1,
+ REG_LP_MODE = LP_MODE_PWR_DN(4) is prohibited by
+ erratum i743 switch to LP_MODE_SELF_REFRESH(2)\n);
+ /* rallback LP_MODE to Self-refresh mode */
s/rallback/rollback ?
With above updates,
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 8/8] memory: emif: Load the correct custom config values from dt
On Monday 11 March 2013 10:36 AM, Lokesh Vutla wrote: of_get_property returns value in Big Endian format. Before using this value it should be converted to little endian using be32_to_cpup(). Custom configs of emif are read from dt using of_get_property, but these are not converted to litte endian format. Correcting the same here. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- Looks fine. 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 10/20] OMAPDSS: Resolve channels for outputs
On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
The DISPC channel used for each output is currently passed in panel
platform data from the board files.
To simplify this, and to make the panel drivers less dependent on OMAP,
this patch changes omapdss to resolve the channel independently. The
channel is resolved based on the OMAP version and, in case of DSI, the
DSI module id.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 37 ++-
drivers/video/omap2/dss/dsi.c | 48
drivers/video/omap2/dss/rfbi.c |2 ++
drivers/video/omap2/dss/sdi.c |2 ++
4 files changed, 84 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e282456..3261644 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
platform_device *dsidev)
return 0;
}
+/*
+ * Return a hardcoded channel for the DPI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dpi_get_channel(void)
+{
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
+ return OMAP_DSS_CHANNEL_LCD;
+
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ return OMAP_DSS_CHANNEL_LCD2;
+
+ case OMAPDSS_VER_OMAP5:
+ return OMAP_DSS_CHANNEL_LCD2;
+
+ default:
+ DSSWARN(unsupported DSS version\n);
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+}
I had another comment for this patch. On OMAP5, it makes sense for us to
not use LCD2 as the recommended channel. LCD2_CLK's only source is
DSS_CLK from PRCM. So it's not a very flexible channel to use. We could
use LCD3 (at the cost of not using DSI2).
We also need to fix dpi_get_dsidev() for OMAP5. Currently, it assumes
that LCD2_CLK can be sourced from DSI2 PLL, we need to ensure DPI has a
dsidev only if it's LCD1 or LCD3.
Archit
+
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev;
DSSDBG(init_display\n);
+ dssdev-channel = dpi_get_channel();
+
if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
dpi.vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
@@ -416,11 +448,6 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
dpi.vdds_dsi_reg = vdds_dsi;
}
- /*
-* XXX We shouldn't need dssdev-channel for this. The dsi pll clock
-* source for DPI is SoC integration detail, not something that should
-* be configured in the dssdev
-*/
dsidev = dpi_get_dsidev(dssdev-channel);
if (dsidev dpi_verify_dsi_pll(dsidev)) {
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 1a6ad6f..c39ca86 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4946,6 +4946,52 @@ void omapdss_dsi_set_videomode_timings(struct
omap_dss_device *dssdev,
}
EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
+/*
+ * Return a hardcoded channel for the DSI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dsi_get_channel(int module_id)
+{
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
+ return OMAP_DSS_CHANNEL_LCD;
+
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ switch (module_id) {
+ case 0:
+ return OMAP_DSS_CHANNEL_LCD;
+ case 1:
+ return OMAP_DSS_CHANNEL_LCD2;
+ default:
+ DSSWARN(unsupported module id\n);
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+
+ case OMAPDSS_VER_OMAP5:
+ switch (module_id) {
+ case 0:
+ return OMAP_DSS_CHANNEL_LCD;
+ case 1:
+ return OMAP_DSS_CHANNEL_LCD3;
+ default:
+ DSSWARN(unsupported module id\n);
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+
+ default:
+
