Re: [PATCH] gpio/omap: ensure gpio context is initialised
On Thursday 18 April 2013 02:01 AM, Jon Hunter wrote:
Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.
This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.
Nevertheless we should ensure that the gpio context is initialised
during the probe for gpio banks that could lose their state regardless
of whether we are booting with device-tree or not.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Tested-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/gpio-omap.c | 53
+-
1 file changed, 43 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..0ba5cb9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
bool is_mpuio;
bool dbck_flag;
bool loses_context;
+ bool context_valid;
int stride;
u32 width;
int context_loss_count;
@@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
}
static const struct of_device_id omap_gpio_match[];
+static void omap_gpio_init_context(struct gpio_bank *p);
static int omap_gpio_probe(struct platform_device *pdev)
{
@@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device
*pdev)
omap_gpio_chip_init(bank);
omap_gpio_show_rev(bank);
- if (bank-loses_context)
+ if (bank-loses_context) {
bank-get_context_loss_count = pdata-get_context_loss_count;
+ omap_gpio_init_context(bank);
+ }
pm_runtime_put(bank-dev);
@@ -1269,6 +1273,14 @@ static int omap_gpio_runtime_resume(struct device *dev)
int c;
spin_lock_irqsave(bank-lock, flags);
+
+ /*
+ * On the first resume during the probe, the context has not
+ * been initialised and so if the context is not valid return.
+ */
+ if (!bank-context_valid)
+ goto done;
+
The use of 'context_valid' is just for the probe resume case and hence
adding a state variable for GPIO bank structures looks bit too much.
Ideally gpio_init_context() should make the first callback successful
as well if ordered correctly but then you need clocks for that
to happen which are enabled in runtime pm calls.
Do you really need that context_valid flag per bank ? I mean
every gpio bank which can loses_context, probe time context
validity is an issue, right ? In that case, won't just an
__init static variable do for all banks which can loose
context?
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
[PATCH] OMAPDSS: DPI: add dependency to DSI
Hi Tomi On Mon, 2013-04-15 at 13:57 +0300, Tomi Valkeinen wrote: Tomi Valkeinen (38): OMAPDSS: add fields to panels' platform data OMAPDSS: DSI: remove DSI DISPC clk divisors from dssdev OMAPDSS: HDMI: remove HDMI clk divisors from dssdev OMAPDSS: DPI: remove omap_dss_device uses OMAPDSS: DSI: remove omap_dss_device uses OMAPDSS: Taal: remove multi-panel support OMAPDSS: APPLY: remove dssdev from dss_mgr_wait_for_vsync OMAPDSS: add missing export for omap_dss_get_output() OMAPDSS: HDMI: init output earlier OMAPDSS: add output-name OMAPDSS: add output-dispc_channel OMAPDSS: DSI: delay dispc initialization OMAPDSS: DSI: fix DSI channel source initialization OMAPDSS: Taal: remove rotate mirror support OMAPDSS: DPI: fix dpi_get_dsidev() for omap5 OMAPDSS: DISPC: store core clk rate OMAPDSS: DSI: fix wrong unsigned long long use OMAPDSS: DSI: simplify dsi configuration OMAPDSS: DSI: get line buffer size at probe OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode OMAPDSS: DSI remove unneeded clk source setup code OMAPDSS: DISPC: add new clock calculation code OMAPDSS: DSS: add new clock calculation code OMAPDSS: DSI: add new clock calculation code OMAPDSS: SDI: use new clock calculation code OMAPDSS: DPI: use new clock calculation code With linux-next this patch breaks compiling here because DPI now depends on DSI - but my omap3 board here doesn't use DSI at all: drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’: drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function ‘dsi_hsdiv_calc’ drivers/video/omap2/dss/dpi.c: In function ‘dpi_dsi_clk_calc’: drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function ‘dsi_get_pll_clkin’ drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function ‘dsi_pll_calc’ Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be want to merge it? From: Christoph Fritz chf.fr...@googlemail.com Date: Thu, 18 Apr 2013 10:26:54 +0200 Subject: [PATCH] OMAPDSS: DPI: add dependency to DSI A dependency from DPI to DSI is introduced by commit 100c82623 OMAPDSS: DPI: use new clock calculation code. This patch adds the dependency also on Kconfig-Level. Signed-off-by: Christoph Fritz chf.fr...@googlemail.com --- drivers/video/omap2/dss/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig index cb0f145..b4211c5 100644 --- a/drivers/video/omap2/dss/Kconfig +++ b/drivers/video/omap2/dss/Kconfig @@ -36,6 +36,7 @@ config OMAP2_DSS_COLLECT_IRQ_STATS config OMAP2_DSS_DPI bool DPI support default y + select OMAP2_DSS_DSI help DPI Interface. This is the Parallel Display Interface. -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: OMAP2+: only search for GPMC DT child nodes on probe
On 04/18/2013 12:33 AM, Jon Hunter wrote:
On 04/17/2013 05:10 PM, Javier Martinez Canillas wrote:
On 04/17/2013 11:27 PM, Jon Hunter wrote:
On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
This means that any device node on the DT that is using any of the
GPMC child nodes names searched for will be returned even if they
are not connected to the GPMC, making the gpmc_probe_xxx_child()
function to fail.
Fix this by using the GPMC device node as the search root so the
search will be restricted to its children.
Reported-by: Lars Poeschel poesc...@lemonage.de
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1 (suggested by Jon Hunter):
- Split the search for GPMC child nodes and only warn if a
child probe fails on two different patches
- Don't probe all childs unnecesary if a previous matched
arch/arm/mach-omap2/gpmc.c | 33 ++---
1 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ed946df..6166847 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1520,32 +1520,19 @@ static int gpmc_probe_dt(struct platform_device
*pdev)
return ret;
}
- for_each_node_by_name(child, nand) {
- ret = gpmc_probe_nand_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ for_each_child_of_node(pdev-dev.of_node, child) {
- for_each_node_by_name(child, onenand) {
- ret = gpmc_probe_onenand_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ if (!child-name)
+ continue;
- for_each_node_by_name(child, nor) {
- ret = gpmc_probe_generic_child(pdev, child);
- if (ret 0) {
- of_node_put(child);
- return ret;
- }
- }
+ if (of_node_cmp(child-name, nand) == 0)
+ ret = gpmc_probe_nand_child(pdev, child);
+ else if (of_node_cmp(child-name, onenand) == 0)
+ ret = gpmc_probe_onenand_child(pdev, child);
+ else if (of_node_cmp(child-name, ethernet) == 0 ||
+ of_node_cmp(child-name, nor) == 0)
+ ret = gpmc_probe_generic_child(pdev, child);
- for_each_node_by_name(child, ethernet) {
- ret = gpmc_probe_generic_child(pdev, child);
if (ret 0) {
I think that we need to make sure that ret is initialised to 0 at the
beginning of the function. We should not have a case where the child
Hi Jon,
I didn't set ret to 0 at the beginning of the function since it is assigned
the
return value of a previous call to of_property_read_u32(). So ret should be 0
when execution reaches the for loop.
Yes you are right, I overlooked that.
name does not match but who knows. Actually that raises another point,
should we have an else clause at the end that WARNs on
unknown/unsupported child device?
Actually I thought about it when I was writing that patch and then I decided
to
not add a WARN for that case since nothing really fail in that case.
I mean if we want to check that a DT is well formed then I think we will
need to
add much more checks and I don't know if is worth it.
But I don't have a strong opinion on this so if you want I can add it an
send a v3.
Ok, that's fine. I am happy with this version, so no need then to re-do.
Great, thanks a lot for your feedback!
Best regards,
Javier
--
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] OMAPDSS: DPI: add dependency to DSI
On 2013-04-18 11:37, Christoph Fritz wrote: Hi Tomi On Mon, 2013-04-15 at 13:57 +0300, Tomi Valkeinen wrote: Tomi Valkeinen (38): OMAPDSS: add fields to panels' platform data OMAPDSS: DSI: remove DSI DISPC clk divisors from dssdev OMAPDSS: HDMI: remove HDMI clk divisors from dssdev OMAPDSS: DPI: remove omap_dss_device uses OMAPDSS: DSI: remove omap_dss_device uses OMAPDSS: Taal: remove multi-panel support OMAPDSS: APPLY: remove dssdev from dss_mgr_wait_for_vsync OMAPDSS: add missing export for omap_dss_get_output() OMAPDSS: HDMI: init output earlier OMAPDSS: add output-name OMAPDSS: add output-dispc_channel OMAPDSS: DSI: delay dispc initialization OMAPDSS: DSI: fix DSI channel source initialization OMAPDSS: Taal: remove rotate mirror support OMAPDSS: DPI: fix dpi_get_dsidev() for omap5 OMAPDSS: DISPC: store core clk rate OMAPDSS: DSI: fix wrong unsigned long long use OMAPDSS: DSI: simplify dsi configuration OMAPDSS: DSI: get line buffer size at probe OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode OMAPDSS: DSI remove unneeded clk source setup code OMAPDSS: DISPC: add new clock calculation code OMAPDSS: DSS: add new clock calculation code OMAPDSS: DSI: add new clock calculation code OMAPDSS: SDI: use new clock calculation code OMAPDSS: DPI: use new clock calculation code With linux-next this patch breaks compiling here because DPI now depends on DSI - but my omap3 board here doesn't use DSI at all: drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’: drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function ‘dsi_hsdiv_calc’ drivers/video/omap2/dss/dpi.c: In function ‘dpi_dsi_clk_calc’: drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function ‘dsi_get_pll_clkin’ drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function ‘dsi_pll_calc’ Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be want to merge it? Thanks for reporting this. We shouldn't make DPI depend on DSI. We should make dummy functions for the above when DSI is not enabled so that DPI compiles. I'll make a fix. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] OMAPDSS: DPI: add dependency to DSI
On 2013-04-18 12:09, Tomi Valkeinen wrote:
On 2013-04-18 11:37, Christoph Fritz wrote:
With linux-next this patch breaks compiling here because DPI now depends
on DSI - but my omap3 board here doesn't use DSI at all:
drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’:
drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function
‘dsi_hsdiv_calc’
drivers/video/omap2/dss/dpi.c: In function ‘dpi_dsi_clk_calc’:
drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function
‘dsi_get_pll_clkin’
drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function
‘dsi_pll_calc’
Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be
want to merge it?
Thanks for reporting this. We shouldn't make DPI depend on DSI. We
should make dummy functions for the above when DSI is not enabled so
that DPI compiles. I'll make a fix.
Patch below. Can you try it out? It works for me on Panda.
Tomi
From d91bf4127056c68e423109e7c9b46bd0f0b1673a Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Thu, 18 Apr 2013 12:16:39 +0300
Subject: [PATCH] OMAPDSS: DPI: fix compilation if DSI not compiled in
Commit 100c826235793345efe06b3558cc9d36166b1e26 (OMAPDSS: DPI: use new
clock calculation code) breaks dpi.c compilation if DSI is not enabled
in the kernel configuration.
Fix compilation by adding dummy inline functions for the ones that dpi.c
references. The functions will never be called, as dpi.c knows that
there is no DSI device available.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.h | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index faaf358..8475893 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -277,6 +277,12 @@ int sdi_init_platform_driver(void) __init;
void sdi_uninit_platform_driver(void) __exit;
/* DSI */
+
+typedef bool (*dsi_pll_calc_func)(int regn, int regm, unsigned long fint,
+ unsigned long pll, void *data);
+typedef bool (*dsi_hsdiv_calc_func)(int regm_dispc, unsigned long dispc,
+ void *data);
+
#ifdef CONFIG_OMAP2_DSS_DSI
struct dentry;
@@ -295,10 +301,6 @@ u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt);
unsigned long dsi_get_pll_clkin(struct platform_device *dsidev);
-typedef bool (*dsi_pll_calc_func)(int regn, int regm, unsigned long fint,
- unsigned long pll, void *data);
-typedef bool (*dsi_hsdiv_calc_func)(int regm_dispc, unsigned long dispc,
- void *data);
bool dsi_hsdiv_calc(struct platform_device *dsidev, unsigned long pll,
unsigned long out_min, dsi_hsdiv_calc_func func, void *data);
bool dsi_pll_calc(struct platform_device *dsidev, unsigned long clkin,
@@ -358,6 +360,27 @@ static inline struct platform_device
*dsi_get_dsidev_from_id(int module)
{
return NULL;
}
+
+static inline unsigned long dsi_get_pll_clkin(struct platform_device *dsidev)
+{
+ return 0;
+}
+
+static inline bool dsi_hsdiv_calc(struct platform_device *dsidev,
+ unsigned long pll, unsigned long out_min,
+ dsi_hsdiv_calc_func func, void *data)
+{
+ return false;
+}
+
+static inline bool dsi_pll_calc(struct platform_device *dsidev,
+ unsigned long clkin,
+ unsigned long pll_min, unsigned long pll_max,
+ dsi_pll_calc_func func, void *data)
+{
+ return false;
+}
+
#endif
/* DPI */
--
1.7.10.4
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
On 04/17/2013 10:16 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
(..)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..0c48f6b 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
(..)
@@ -135,6 +136,25 @@
0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
;
};
+
+ led_gpio_pins: pinmux_leds_pins {
+ pinctrl-single,pins =
+ ;
+ };
+};
Hi,
FYI, there was a recent discussion precisely on this topic, where Tomy
suggested to remove the empty section:
http://marc.info/?l=linux-omapm=136546635409232w=2
Apart from that, I just tested your patch on top of Tomy's
omap-for-v3.10/dt branch and it is working fine for me on PandaBoards
EA3, A4 and ES.
Tested-by: Vincent Stehlé v-ste...@ti.com
Best regards,
V.
--
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] OMAPDSS: DPI: add dependency to DSI
On Thu, 2013-04-18 at 12:21 +0300, Tomi Valkeinen wrote: On 2013-04-18 12:09, Tomi Valkeinen wrote: On 2013-04-18 11:37, Christoph Fritz wrote: With linux-next this patch breaks compiling here because DPI now depends on DSI - but my omap3 board here doesn't use DSI at all: drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’: drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function ‘dsi_hsdiv_calc’ drivers/video/omap2/dss/dpi.c: In function ‘dpi_dsi_clk_calc’: drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function ‘dsi_get_pll_clkin’ drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function ‘dsi_pll_calc’ Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be want to merge it? Thanks for reporting this. We shouldn't make DPI depend on DSI. We should make dummy functions for the above when DSI is not enabled so that DPI compiles. I'll make a fix. Patch below. Can you try it out? It works for me on Panda. Thanks, it compiles here fine too. and while booting I'm now getting as with 3.9-rc: [0.409729] OMAP DSS rev 2.0 [0.410980] omapdss DPI error: can't get VDDS_DSI regulator [0.410980] omapdss DPI error: device ips-056t init failed: -517 But here with linux-next (in contrast to 3.9-rc) removing all regulator dependencies from drivers/video/omap2/dss/dpi.c does not make the trick. The display stays dark :-( ... Thanks -- Christoph -- 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: [RFT/PATCH 2/6] driver: serial: mpc52xx_uart: Remove uart_console defintion
On Wed, Apr 17, 2013 at 05:04:23PM +0530, Sourav Poddar wrote: Since uart_console definition is now moved to serial core haeder file . Serial drivers need not define them. This needs to be part of patch 1. Having it separate may provoke compiler warnings. -- 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: [RFT/PATCH 2/6] driver: serial: mpc52xx_uart: Remove uart_console defintion
Hi Russell, On Thursday 18 April 2013 04:20 PM, Russell King - ARM Linux wrote: On Wed, Apr 17, 2013 at 05:04:23PM +0530, Sourav Poddar wrote: Since uart_console definition is now moved to serial core haeder file . Serial drivers need not define them. This needs to be part of patch 1. Having it separate may provoke compiler warnings. Ok. I will fold it in the first patch in my next version. Thanks, Sourav -- 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] ARM: OMAP2+: hwmod: Cleanup sidle/mstandby programming
Hi Paul, _enable_wakeup() and _disable_wakeup() are expected to program the OCP_SYSCONFIG.ENAWAKEUP bit. These functions were originally intended to take care of everything needed for the IP block to wake up the chip, including the PRCM WKEN programming. ENAWAKEUP is simply one part of that. Get rid of the additional sidle/mstandby programming in them, as its confusing (this is expected to be handled elsewhere as part of _enable_sysc()/__idle_sysc()) Sorry, why does the expectation exist for the code to enable and disable device wakeup to be part of _enable_sysc()/_idle_sysc(), rather than in functions called by _enable_sysc()/_idle_sysc()? It all comes down to if SIDLE_SMART_WKUP/MSTANDBY_SMART_WKUP programming be considered as 'idlemode' programming or 'enwakeup' programming. If you consider these are being part of 'enwakeup' progrmming, these should certainly be handled as part of _enable_wakeup() and _disable_wakeup(). Today, in some cases, these are *also* handled as part of _enable_sysc() and _idle_sysc(). The way _enable_wakeup() is invoked from _enable_sysc() is also very inconsistent. For instance, for any IP which supports SYSC_HAS_MIDLEMODE and SYSC_HAS_ENAWAKEUP, we invoke _enable_wakeup() regardless of the MIDLEMODE programmmed. While in case of the IP supporting SYSC_HAS_SIDLEMODE, _enable_wakeup() is invoked only when the SIDLEMODE programmed is SMART or SMART_WKUP. I understand the cleanups you are suggesting below as part of the movement of some of these things outside of mach-omap2. I was more looking at fixing the existing piece so its readable and does things more consistently. Do you have any further thoughts on how we should do about this? regards, Rajendra regards, Rajendra and unnecessary. So here's part of the reason why the module wakeup control functions should remain separate. When the kernel boots, all the PM features should be disabled. Then mach-omap2/pm*.c should enables PM features where they're needed. Right now, mach-omap2/pm34xx.c sets module WKEN bits. (These direct register accesses need to be moved as part of the cleanup work, of moving the PM/PRM/CM code into drivers.) But the list of IP blocks that should be allowed to wake the system is board-dependent. So really, what mach-omap2/pm34xx.c should do is to call into the hwmod enable-wakeups code to enable MPU wakeups for all the IP blocks that have some DT property set, something like 'enable-wakeups'. Then the hwmod code should ensure that the PRM wakeup-enable and GRPSEL bits are programmed (by calling into the PRM driver code) and should then either set the ENAWAKEUP bits or put the module into smart_wkup MSTANDBY/MIDLE. Similarly, when the PM driver is unloaded, it should set no-idle on all the IP blocks that were marked as wakeup-capable and disable the PRCM wakeup control bits, by calling some hwmod disable-wakeups code. Well, the _enable_sysc()/_idle_sysc() handled only the mstandby modes correctly. So fix them so they also handle the midle modes correctly If there's a fix here, please split that out into a separate patch. - 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: [RFC PATCH v2 0/6] ARM: OMAP3+: Introduce ABB driver
On 04/16/2013 10:18 PM, Kevin Hilman wrote:
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes:
Hi Kevin,
On 04/16/2013 12:53 AM, Kevin Hilman wrote:
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes:
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Following patch series introduces the Adaptive Body-Bias
LDO driver, which handles LDOs voltage during OPP change routine.
Current implementation is based on patch series from
Mike Turquette:
http://marc.info/?l=linux-omapm=134931341818379w=2
ABB transition is a part of OPP changing sequence.
ABB can operate in the following modes:
- Bypass mode: Activated when ABB is not required
- FBB mode: Fast Body Bias mode, used on fast OPPs
Fast? I thought the 'F' was for Forward?
You are right. Should be 'Forward' here.
- RBB mode: Reverse Body Bias mode, used on slow OPPs
In current implementation ABB is converted to regulator.
Standalone OPP table is used to store ABB mode, it is defined
in device tree for each ABB regulator. It has the following format:
operating-points =
/* uV ABB (0 - Bypass, 1 - FBB, 2 - RBB) */
88 0
106 1
125 1
126 1
;
ABB regulator is linked to regulator chain
In addition to Mike's comments (which I completely agree with), it would
be very helfpul to see how this is actually used. e.g, how the
regulators are chained together, how the proper ordering is managed,
etc. etc.
We would like to handle voltage scaling in the following way:
What I meant is that a detailed description of the use case should be
included in the changelog.
cpufreq_cpu0
clk_set_rate(cpu0)
|
|--set_voltage(ABB regulator) /* all ABB related stuff will be
handled here */
|
|--set_voltage(smps123 regulator) /* actual voltage
scaling */
-EASCII_ART_WRAP
This simple model will be extended to handle AVS as a part of the chain.
smps123 regulator may be changed to VP/VC regulator.
Following example is from integration branch, which already has
smps123 regulator.
I don't know what integration branch you're referring to, and I don't
know what the smps123 regulator is.
It demonstrates an example of linkage to chain. ABB regulator is
linked with smps123 and cpu0 inside device tree.
cpu0 calls set_voltage() function for ABB, and then ABB calls
set_voltage() function for smps123 to do actual voltage scaling.
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index bb5ee70..c8cbbee 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -36,7 +36,7 @@
cpus {
cpu@0 {
compatible = arm,cortex-a15;
- cpu0-supply = smps123_reg;
+ cpu0-supply = abb_mpu;
operating-points =
/* kHzuV */
/* Only for Nominal Samples */
@@ -94,6 +94,7 @@
reg = 0x4ae07cdc 0x8,
0x4ae06014 0x4;
ti,tranxdone_status_mask = 0x80;
+ avs-supply = smps123_reg;
operating-points =
/* uV ABB */
88 0
This RFC patch series is verified together with:
https://patchwork.kernel.org/patch/2445091/
Kevin, what do you think about this model in general? Does it fit to
regulator framework?
I don't know yet, because I don't think the use case has been described
well enough for me to fully understand it the motiviation behind the
series.
In addition, there are alternative approaches that seem to have been
ruled out without describing why. For example, the regulator framework
already allows you to override methods with custom hooks (as we do for
VC/VP controlled regulators already.) Without thinking about it too
deeply, it seems this approach could be used to manage the chain of
events you need as well. I can imagine there are limitations to this
approach for what you're trying to do, but I don't feel they have been
described in the changelog as part of the motivation for this series.
So for now, the guidance I have is this:
First, write changelogs (and cover letters) assuming your audience has
not been staring at the code as long as you have. Even if they have
been staring at the same code, assume they've been staring at mainline,
and not a random integration branch somewhere. My general advice is to
write changelogs in a way that you will understand what you wrote a year
from now after having forgotten all the details currently in your brains
cache. Even better, write them so that I will understand them in a year
since I forget much better than I remember.
Second, before inventing something new, start with the existing
framework. When the existing framework doesn't work, make an argument
for your new approach or extentions to the framework
[PATCH v2 1/2] ARM: dts: omap3-beagle-xm: Add USB Host support
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 61 +
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 5a31964..04376a6 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -57,6 +57,59 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio5 19 0; /* gpio_147 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 18 0;/* GPIO LEDA */
+ startup-delay-us = 7;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ vcc-supply = hsusb2_power;
+ };
+
+};
+
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusbb2_pins
+ ;
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins =
+ 0x5c0 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+ 0x5c2 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x5c4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x5c6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x5c8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x5cA 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x1a4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x1a6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x1a8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x1aa 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x1ac 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x1ae 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
};
i2c1 {
@@ -125,3 +178,11 @@
mode = 3;
power = 50;
};
+
+usbhshost {
+ port2-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy;
+};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: dts: omap3-beagle-xm: Add USB host supprot for Rev. Ax/Bx
Rev. Ax/Bx boards have reversed polarity for USBHOST_PWR_ENable
signal when compared to Rev. C boards.
We create a new dts file for Ax/Bx boards.
Also update model and compatible flags for Rev. C board.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm-ab.dts | 19 +++
arch/arm/boot/dts/omap3-beagle-xm.dts|4 ++--
2 files changed, 21 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-beagle-xm-ab.dts
diff --git a/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
new file mode 100644
index 000..041b40e
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
@@ -0,0 +1,19 @@
+/*
+ * 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.
+ */
+
+/include/ omap3-beagle-xm.dts
+
+/ {
+model = TI OMAP3 BeagleBoard xM Rev: Ax/Bx;
+compatible = ti,omap3-beagle-xm-ab, ti,omap3-beagle, ti,omap3;
+};
+
+/* On Rev A/B USBHOST_PWR_EN is active high */
+hsusb2_power {
+ enable-active-high;
+};
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 04376a6..8a46dc5 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -10,8 +10,8 @@
/include/ omap36xx.dtsi
/ {
- model = TI OMAP3 BeagleBoard xM;
- compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+ model = TI OMAP3 BeagleBoard xM Rev: C;
+ compatible = ti,omap3-beagle-xm-c, ti,omap3-beagle, ti,omap3;
cpus {
cpu@0 {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
On Tuesday 02 April 2013 06:10 PM, Vivek Gautam wrote:
Hi,
On Tue, Apr 2, 2013 at 5:40 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Apr 02, 2013 at 04:04:01PM +0530, Vivek Gautam wrote:
On Mon, Apr 01, 2013 at 07:24:00PM +0530, Vivek Gautam wrote:
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141 +++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
wrong indentation, also, I'm not sure we should allow calls with NULL
pointers. Perhaps a WARN() so we get API offenders early enough ?
True, bad coding style :-(
We should be handling dev_err with a NULL pointer.
Will just keep here:
if (WARN_ON(!x-dev))
return ;
right, but I guess:
if (WARN(!x || !x-dev, Invalid parameters\n))
return -EINVAL;
would be better ??
btw, shouldn't it be IS_ERR(x)?
Thanks
Kishon
--
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/6] driver: serial: omap: add prepare/complete callback for no_console_suspend case
Hi Felipe,
On Thursday 18 April 2013 09:28 AM, Felipe Balbi wrote:
Hi,
On Wed, Apr 17, 2013 at 05:04:24PM +0530, Sourav Poddar wrote:
@@ -1632,6 +1650,8 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(serial_omap_suspend, serial_omap_resume)
SET_RUNTIME_PM_OPS(serial_omap_runtime_suspend,
serial_omap_runtime_resume, NULL)
+ .prepare= serial_omap_prepare,
+ .complete = serial_omap_complete,
if CONFIG_PM_SLEEP isn't defined, this will break compilation.
True.
Then, will it not be a better idea to add a similar macro[1] in
include/linux/pm.h for
prepare/complete callback as it is present for suspend/resume ?.
[1]:
#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
.suspend = suspend_fn, \
.resume = resume_fn, \
.freeze = suspend_fn, \
.thaw = resume_fn, \
.poweroff = suspend_fn, \
.restore = resume_fn,
#else
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#endif
~Sourav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote: On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote: On 04/09/2013 12:16 AM, Stephen Warren wrote: On 04/08/2013 04:05 PM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt the #interrupt-cells property of an interrupt-controller is used to define the number of cells needed to specify a single interrupt. ... But the type is never returned so it can't be saved on the IRQ struct resource flags member. This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking back, I'm not sure if that was the right thing or whether I should have sent this same patch:-) Hi Stephen, I'm glad you agree :-) I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for the IRQ with irqd_get_trigger_type() but I prefer $subject because: irqd_get_trigger_type probably is not meant for outside of irqchips. Creating an irq_get_irq_type function which takes an irq number would be the right function as that does not expose struct irq_data. Hi Rob, I sent a patch-set a few days ago that adds an irq_get_irq_type() function [1] as you suggested and this function is used on the smsc911x driver probe function to get the edge/level flags [2]. It would be great if I can get your feedback on this. Thanks a lot and best regards, Javier [1]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/97117 [2]: http://permalink.gmane.org/gmane.linux.network/265587 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 0/6] ARM: OMAP3+: Introduce ABB driver
On 04/16/2013 10:07 PM, Mike Turquette wrote: Quoting Andrii Tseglytskyi (2013-04-16 05:40:44) On 04/16/2013 12:53 AM, Kevin Hilman wrote: In addition to Mike's comments (which I completely agree with), it would be very helfpul to see how this is actually used. e.g, how the regulators are chained together, how the proper ordering is managed, etc. etc. We would like to handle voltage scaling in the following way: I expanded the example below to include the SR AVS regulator. cpufreq_cpu0 clk_set_rate(cpu0) | |--set_voltage(ABB regulator) | |--set_voltage(AVS) | |--set_voltage(smps123 regulator) Hi Andrii, Why was regulator chaining chosen over a simple sequence of calls to regulator_set_voltage? Instead of nested calls into the regulator framework, why don't you just make the calls serially? E.g: regulator_set_voltage(abb_reg, foo_volt); regulator_set_voltage(avs_reg, bar_volt); regulator_set_voltage(smps123_reg, baz_volt); It is still to be determined where these calls originate from; maybe from clock notifiers, maybe directly from the cpufreq driver's .target() callback, or maybe somewhere else. Regardless, I do not see why regulator chaining is truly necessary here. You are just calling regulator_set_voltage in sequence on a few regulators, right? I think it would help me a lot to understand why regulator chaining is a requirement for this to work properly. Thanks, Mike Hi Mike, Kevin I'd like to provide some explanation regarding proposed TI DVFS design which we would like to follow (regulator chaining is part of it). The following two patch series was intended to prove the possibility of its implementation: - this one 'ARM: OMAP3+: Introduce ABB driver - and http://www.spinics.net/lists/linux-omap/msg90022.html - [RFC v1 0/1] introduce regulator chain locking scheme but, seems, we started to make it public from tail instead of 'head - sorry for that. While trying to move forward with TI DVFS we've taken into account following major points: - only DT should be used to configure DVFS; - no xxx_initcall, cpu_is_xx() function should be used; - DVFS should be scalable to fit wide SoC/platform’s and multiplatform kernel requirements; - minimize creation of TI specific API; Now, there are two entry points for DVFS in kernel: - CPUFreq - currently it's been decided to use cpufreq-cpu0 for all OMAPs in Main line; - CCF callbacks - have RFC DVFS implementation introduced here http://lwn.net/Articles/540422/. In both cases, the only one regulator need to be provided for CCF or CPUFreq for voltage changing proposes, so DVFS can done in the following way: || || --| RegulatorY |--| DVFS | || || \ \ \ \_ \\ |---| |---| |-| --| RegulatorX (PMIC) |--| Regulator AVS |--| ABB LDO |-- |---| |---| |-| /|\ | |__| Voltage adjustment 1) The following use-cases have been taken into account: - SoC/Platform don't need ABB/AVS (supports MPU OPPLOW/OPPNOM for example) - any regulator (VC-VP/I2C/SPI/GPIO ..) may be connected to DVFS - SoC/Platform need ABB - build chain in DT device-CCF-abb_regulator-any regulator(VC-VP/I2C/SPI..) - SoC/Platform need ABB+AVS - build chain in DT device-CCF-abb_regulator-avsX-any regulator(VC-VP/I2C..) 2) Implementation of each part of Voltage scale chain as Regulator will allow: - add each item one by one; - don't expose too much of custom TI API; - handle multi-voltage scaling requests to one rail (ganged rails) automatically (handled by regulator FW already). 3) The regulator chaining will allow: - easily configure DVFS form DT depending on current SoC/platform needs (using xxx-supply standard binding in DT); - continue use cpufreq-cpu0 for all OMAP to scale MPU domain; - use RFC DVFS implementation from http://lwn.net/Articles/540422/ for other domains (with some modifications - the most difficult thing will be multi-freq requests handling to one clock). In case, if regulator chaining approach is not accepted: - yes, it's possible to create some Super TI regulator which will handle ABB+AVS+VC/VP for most of current TI SoCs. - No, for the newest TI SoCs (like DRA7xxx without VC/VP) any regulator can be used as power supply (I2C/SPI/GPIO) and ABB is needed. a) As result, it will be impossible to use cpufreq-cpu0 driver for it, at least, and will need to drop cpufreq-cpu0 support for OMAPs and roll-back to omap-cpufreq. b) for other domains it's possible to create omap_dvfs.c in the similar way as it done in dvfs.c and hack it to handle ABB+AVS+I2C regulator. - will need to add custom TI
Re: [PATCH 3/6] driver: serial: omap: add prepare/complete callback for no_console_suspend case
Hi,
On Thu, Apr 18, 2013 at 05:37:48PM +0530, Sourav Poddar wrote:
Hi Felipe,
On Thursday 18 April 2013 09:28 AM, Felipe Balbi wrote:
Hi,
On Wed, Apr 17, 2013 at 05:04:24PM +0530, Sourav Poddar wrote:
@@ -1632,6 +1650,8 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops
= {
SET_SYSTEM_SLEEP_PM_OPS(serial_omap_suspend, serial_omap_resume)
SET_RUNTIME_PM_OPS(serial_omap_runtime_suspend,
serial_omap_runtime_resume, NULL)
+ .prepare= serial_omap_prepare,
+ .complete = serial_omap_complete,
if CONFIG_PM_SLEEP isn't defined, this will break compilation.
True.
Then, will it not be a better idea to add a similar macro[1] in
include/linux/pm.h for
prepare/complete callback as it is present for suspend/resume ?.
[1]:
#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
.suspend = suspend_fn, \
.resume = resume_fn, \
.freeze = suspend_fn, \
.thaw = resume_fn, \
.poweroff = suspend_fn, \
.restore = resume_fn,
#else
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#endif
might be :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] OMAPDSS: DPI: add dependency to DSI
On 2013-04-18 13:13, Christoph Fritz wrote: On Thu, 2013-04-18 at 12:21 +0300, Tomi Valkeinen wrote: On 2013-04-18 12:09, Tomi Valkeinen wrote: On 2013-04-18 11:37, Christoph Fritz wrote: With linux-next this patch breaks compiling here because DPI now depends on DSI - but my omap3 board here doesn't use DSI at all: drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’: drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function ‘dsi_hsdiv_calc’ drivers/video/omap2/dss/dpi.c: In function ‘dpi_dsi_clk_calc’: drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function ‘dsi_get_pll_clkin’ drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function ‘dsi_pll_calc’ Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be want to merge it? Thanks for reporting this. We shouldn't make DPI depend on DSI. We should make dummy functions for the above when DSI is not enabled so that DPI compiles. I'll make a fix. Patch below. Can you try it out? It works for me on Panda. Thanks, it compiles here fine too. and while booting I'm now getting as with 3.9-rc: [0.409729] OMAP DSS rev 2.0 [0.410980] omapdss DPI error: can't get VDDS_DSI regulator [0.410980] omapdss DPI error: device ips-056t init failed: -517 But here with linux-next (in contrast to 3.9-rc) removing all regulator dependencies from drivers/video/omap2/dss/dpi.c does not make the trick. The display stays dark :-( ... That's with your DT hacked kernel, right? Not the official supported one. I don't think anything changed related to regulators in omapdss. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW
On 15/04/13 18:34, Mugunthan V N wrote: On 4/15/2013 10:58 PM, Mark Jackson wrote: On 15/04/13 18:07, Mugunthan V N wrote: On 4/15/2013 12:46 AM, Mark Jackson wrote: snip Notice that at the end, the nfs link appears to come back ok, but the ps command never completes. Any ideas of what's going on ? I have tried ping on both the interface fine. Will verify with ps again later in this week. Can you provide below details details - Are you using EVMsk or custom build EVM? This is a custom board (based on the BeagleBone design) with dual Ethernet, NAND, NOR and FRAM. The dual emac thing is (one of) the last things to get signed off, so I'm willing to assist in tracking this down. After testing the scenario i may be able to send you an update later in this week. I have made some progress ... I realised I was missing a (clearly rather important !!) item in my .config file, namely CONFIG_TI_DAVINCI_EMAC. I am now able to ping from our board to other systems on the network (again, I've only tested eth0 at the moment). However, I am unable to ping everything I should be able to !! Here's my setup ... # cat /etc/network/interfaces # Configure Loopback auto lo eth0 eth1 iface lo inet loopback iface eth1 inet static address 10.1.101.111 netmask 255.255.0.0 gateway 10.1.0.1 iface eth0 inet static address 10.0.101.111 netmask 255.255.0.0 gateway 10.0.0.1 # ifconfig eth0 Link encap:Ethernet HWaddr C2:21:5E:B4:06:5E inet addr:10.0.101.111 Bcast:0.0.0.0 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:67 errors:0 dropped:0 overruns:0 frame:0 TX packets:62 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8848 (8.6 KiB) TX bytes:4290 (4.1 KiB) Interrupt:56 eth1 Link encap:Ethernet HWaddr D6:2F:CF:39:22:4E inet addr:10.1.101.111 Bcast:0.0.0.0 Mask:255.255.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:38 errors:0 dropped:0 overruns:0 frame:0 TX packets:38 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4022 (3.9 KiB) TX bytes:4022 (3.9 KiB) # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.0.0.10.0.0.0 UG0 00 eth0 10.0.0.00.0.0.0 255.255.0.0 U 0 00 eth0 10.1.0.00.0.0.0 255.255.0.0 U 0 00 eth1 I can ping a couple of units on 10.0.0.x ... # ping 10.0.0.120 PING 10.0.0.120 (10.0.0.120): 56 data bytes 64 bytes from 10.0.0.120: seq=0 ttl=64 time=0.955 ms 64 bytes from 10.0.0.120: seq=1 ttl=64 time=0.676 ms 64 bytes from 10.0.0.120: seq=2 ttl=64 time=0.732 ms 64 bytes from 10.0.0.120: seq=3 ttl=64 time=0.762 ms --- 10.0.0.120 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.676/0.781/0.955 ms # ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: seq=0 ttl=64 time=1.815 ms 64 bytes from 10.0.0.5: seq=1 ttl=64 time=0.458 ms 64 bytes from 10.0.0.5: seq=2 ttl=64 time=0.474 ms 64 bytes from 10.0.0.5: seq=3 ttl=64 time=0.345 ms 64 bytes from 10.0.0.5: seq=4 ttl=64 time=0.329 ms --- 10.0.0.5 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.329/0.684/1.815 ms But *not* my router on the same subnet ... # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes --- 10.0.0.1 ping statistics --- 15 packets transmitted, 0 packets received, 100% packet loss I am also unable to ping other equipment that exists:- # ping 10.0.101.2 PING 10.0.101.2 (10.0.101.2): 56 data bytes --- 10.0.101.2 ping statistics --- 6 packets transmitted, 0 packets received, 100% packet loss # ping 10.0.200.2 PING 10.0.200.2 (10.0.200.2): 56 data bytes --- 10.0.200.2 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss Just to prove these other item do exist, here's me pinging them from another Linux VM (working off the same physical switch):- mpfj@mpfj-nanobone:~/linux/linux-2.6$ ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:1e:0d:f5 inet addr:10.0.0.120 Bcast:10.0.255.255 Mask:255.255.0.0 inet6 addr: fe80::a00:27ff:fe1e:df5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:135935 errors:0 dropped:0 overruns:0 frame:0 TX packets:172692 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
Re: [RFC v1] regulator: core: introduce regulator chain locking scheme
On 04/15/2013 07:40 PM, Mark Brown wrote: On Mon, Apr 15, 2013 at 07:21:25PM +0300, Andrii Tseglytskyi wrote: On 04/15/2013 06:50 PM, Mark Brown wrote: In addition, such locking scheme allows to have access to the supplier regulator API from inside child's (consumer) regulator API. I've still not seen any use case articulated for doing this... Use case is introduced in ABB series: Sorry, I meant any sensible use case. Hi Mark, Thanks for you comments. I'll split it to 3 patches: - abstract locking out into helper functions; - introduce regulator chain locking scheme - allow reentrant calls into the regulator framework (with hope that is has future, may be can enable/disable it through constraints) I understand that Regulator FW is common and wide used and we should very careful here. Regards, - grygorii -- 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] gpio/omap: ensure gpio context is initialised
On 04/18/2013 03:22 AM, Santosh Shilimkar wrote:
On Thursday 18 April 2013 02:01 AM, Jon Hunter wrote:
Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.
This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.
Nevertheless we should ensure that the gpio context is initialised
during the probe for gpio banks that could lose their state regardless
of whether we are booting with device-tree or not.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Tested-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/gpio-omap.c | 53
+-
1 file changed, 43 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..0ba5cb9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
bool is_mpuio;
bool dbck_flag;
bool loses_context;
+bool context_valid;
int stride;
u32 width;
int context_loss_count;
@@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
}
static const struct of_device_id omap_gpio_match[];
+static void omap_gpio_init_context(struct gpio_bank *p);
static int omap_gpio_probe(struct platform_device *pdev)
{
@@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device
*pdev)
omap_gpio_chip_init(bank);
omap_gpio_show_rev(bank);
-if (bank-loses_context)
+if (bank-loses_context) {
bank-get_context_loss_count = pdata-get_context_loss_count;
+omap_gpio_init_context(bank);
+}
pm_runtime_put(bank-dev);
@@ -1269,6 +1273,14 @@ static int omap_gpio_runtime_resume(struct device
*dev)
int c;
spin_lock_irqsave(bank-lock, flags);
+
+/*
+ * On the first resume during the probe, the context has not
+ * been initialised and so if the context is not valid return.
+ */
+if (!bank-context_valid)
+goto done;
+
The use of 'context_valid' is just for the probe resume case and hence
adding a state variable for GPIO bank structures looks bit too much.
Yes it is not ideal. However, it is safe.
Ideally gpio_init_context() should make the first callback successful
as well if ordered correctly but then you need clocks for that
to happen which are enabled in runtime pm calls.
Right.
Do you really need that context_valid flag per bank ? I mean
every gpio bank which can loses_context, probe time context
validity is an issue, right ? In that case, won't just an
__init static variable do for all banks which can loose
context?
I think that it would be fragile to have a global for all banks. What
happens if one bank failed during the probe? Probably unlikely but still.
The best solution would be to be able to plug the pm-runtime
resume/suspend handlers at the end of the probe or be able to enable the
module without the callback handlers being calling during the probe. I
am not sure if there is a way to do this. May be Kevin knows.
Another option is to move the initialisation of the bank-loses_context
to after the call to pm_runtime_get_sync() in the probe. This would
prevent the context restore occurring during the initial runtime resume.
However, if you look at the runtime resume function there are still some
register writes that do occur (which is basically what happens today).
This works but it is a little fragile, however, we can do that if
preferred. May be I could add a comment to the probe to say why we
initialise bank-loses_context after the pm_runtime_get_sync() so no one
moves this in the future (and more importantly I don't forget!).
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: DPI: add dependency to DSI
On Thu, 2013-04-18 at 17:37 +0300, Tomi Valkeinen wrote: But here with linux-next (in contrast to 3.9-rc) removing all regulator dependencies from drivers/video/omap2/dss/dpi.c does not make the trick. The display stays dark :-( ... That's with your DT hacked kernel, right? Not the official supported one. yeah - it's fixed and working right now again. Thanks -- Christoph -- 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] few omap randconfig fixes for v3.10
Few trivial fixes for randconfig found issues. Regards, Tony --- Tony Lindgren (3): ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP ARM: OMAP2+: Fix unused variable warning for am3517 crane ARM: OMAP2+: Fix is_gpmc_muxed warning for H4 arch/arm/configs/omap2plus_defconfig|2 ++ arch/arm/mach-omap2/Kconfig |2 -- arch/arm/mach-omap2/board-am3517crane.c |2 -- arch/arm/mach-omap2/board-h4.c |4 ++-- 4 files changed, 4 insertions(+), 6 deletions(-) -- Signature -- 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/3] ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP
Commit 8a6201b9 (ARM: OMAP2+: Fix unmet direct dependencies for zoom for 8250 serial) fixed unmet direct dependencies for 8250, but failed to do the same for omap serial. This can cause the following warning: warning: (ARCH_OMAP2PLUS_TYPICAL) selects SERIAL_OMAP which has unmet direct dependencies (TTY HAS_IOMEM GENERIC_HARDIRQS ARCH_OMAP2PLUS). We should not select drivers, they should be selected by the user. Fix the issue by removing the select and adding them to omap2plus_defconfig instead. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/configs/omap2plus_defconfig |2 ++ arch/arm/mach-omap2/Kconfig |2 -- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 33903ca..51a20a4 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -137,6 +137,8 @@ CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y +CONFIG_SERIAL_OMAP=y +CONFIG_SERIAL_OMAP_CONSOLE=y CONFIG_HW_RANDOM=y CONFIG_I2C_CHARDEV=y CONFIG_SPI=y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index a897b44..03b0b27 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -37,8 +37,6 @@ config ARCH_OMAP2PLUS_TYPICAL select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5 select PM_RUNTIME select REGULATOR - select SERIAL_OMAP - select SERIAL_OMAP_CONSOLE select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 select VFP -- 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: OMAP2+: Fix unused variable warning for am3517 crane
Fix the following by removing the unused variable:
arch/arm/mach-omap2/board-am3517crane.c: In function ‘am3517_crane_init’:
arch/arm/mach-omap2/board-am3517crane.c:113: warning: unused variable ‘ret’
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-am3517crane.c |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index fc53911..0d499a1 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -110,8 +110,6 @@ static void __init am3517_crane_i2c_init(void)
static void __init am3517_crane_init(void)
{
- int ret;
-
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
omap_sdrc_init(NULL, NULL);
--
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: OMAP2+: Fix is_gpmc_muxed warning for H4
Fix the following error by moving the function to be within
the smc91x related ifdef as that's the only user:
arch/arm/mach-omap2/board-h4.c:238: warning: ‘is_gpmc_muxed’ defined but not
used
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-h4.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 69c0acf..f745cae 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -229,6 +229,8 @@ static u32 get_sysboot_value(void)
OMAP2_SYSBOOT_1_MASK | OMAP2_SYSBOOT_0_MASK));
}
+#if IS_ENABLED(CONFIG_SMC91X)
+
/* H4-2420's always used muxed mode, H4-2422's always use non-muxed
*
* Note: OMAP-GIT doesn't correctly do is_cpu_omap2422 and is_cpu_omap2423
@@ -246,8 +248,6 @@ static u32 is_gpmc_muxed(void)
return 0;
}
-#if IS_ENABLED(CONFIG_SMC91X)
-
static struct omap_smc91x_platform_data board_smc91x_data = {
.cs = 1,
.gpio_irq = 92,
--
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/6] driver: serial: omap: add prepare/complete callback for no_console_suspend case
Sourav Poddar sourav.pod...@ti.com writes:
The patch adapt the serial core/driver to take care of the case when
no_console_suspend
is used in the bootargs. The patch will remove dependency to set od-flags to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND in serial.c(non dt case) and
omap_device.c(dt case).
Prepare and complete callbacks will ensure that clocks remain active for the
console
uart when no_console_suspend is used in the bootargs.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
This changelog needs a rework. The driver itself was not aware of
od-flags and omap_device stuff in general, so it's not really
relevant. The driver is also not directly managing clocks, int's only
doing runtime PM callbacks.
What you want to say in the changelog is that the driver manages
no_console_suspend by preventing runtime PM during the suspend path,
which forces the console UART to stay awake.
---
drivers/tty/serial/omap-serial.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 08332f3..9ef80cf 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1278,6 +1278,24 @@ static struct uart_driver serial_omap_reg = {
};
#ifdef CONFIG_PM_SLEEP
+static int serial_omap_prepare(struct device *dev)
+{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+
+ if (!console_suspend_enabled uart_console(up-port))
+ pm_runtime_disable(dev);
+
+ return 0;
+}
+
+static void serial_omap_complete(struct device *dev)
+{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+
+ if (!console_suspend_enabled uart_console(up-port))
+ pm_runtime_enable(dev);
+}
+
For compilation with !CONFIG_PM_SLEEP, you'll also need:
#else
#define serial_omap_prepare NULL
#define serial_omap_prepare NULL
#endif /* CONFIG_PM_SLEEP */
static int serial_omap_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
@@ -1632,6 +1650,8 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops =
{
SET_SYSTEM_SLEEP_PM_OPS(serial_omap_suspend, serial_omap_resume)
SET_RUNTIME_PM_OPS(serial_omap_runtime_suspend,
serial_omap_runtime_resume, NULL)
+ .prepare= serial_omap_prepare,
+ .complete = serial_omap_complete,
};
#if defined(CONFIG_OF)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] arm: mach-omap2: remove OMAP_DEVICE_NO_IDLE_ON_SUSPEND check
Sourav Poddar sourav.pod...@ti.com writes:
Remove the OMAP_DEVICE_NO_IDLE_ON_SUSPEND check, since UART was the only
one making
use of it. Now serial core/driver takes care of the case when
no_console_suspend
is used in the bootargs and you need to keep the clock enable for console
even while suspend.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
NAK. This patch will break many things...
---
arch/arm/mach-omap2/omap_device.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 381be7a..d6dce8f 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -620,11 +620,8 @@ static int _od_suspend_noirq(struct device *dev)
ret = pm_generic_suspend_noirq(dev);
if (!ret !pm_runtime_status_suspended(dev)) {
- if (pm_generic_runtime_suspend(dev) == 0) {
- if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
- omap_device_idle(pdev);
Why did you remove the omap_device_idle() here?
+ if (pm_generic_runtime_suspend(dev) == 0)
od-flags |= OMAP_DEVICE_SUSPENDED;
- }
}
return ret;
@@ -638,8 +635,6 @@ static int _od_resume_noirq(struct device *dev)
if ((od-flags OMAP_DEVICE_SUSPENDED)
!pm_runtime_status_suspended(dev)) {
od-flags = ~OMAP_DEVICE_SUSPENDED;
- if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
- omap_device_enable(pdev);
And the _enable() here?
pm_generic_runtime_resume(dev);
}
Note that the check is for when the flag is *not* set, so this patch
changes behavior for all the drivers that do not use
_NO_IDLE_ON_SUSPEND. I think that's the opposite of what you intended.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] arm: mach-omap2: Remove no_console_suspend
Sourav Poddar sourav.pod...@ti.com writes:
Since the omap serial driver is now adapted to handle the
case where you dont need to cut the clock on suspend while
using no_console_suspend in the bootargs.
We can get rid of the previous implementation of setting the od-flags to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND from platform
and omap_device files.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Rajendra nayak rna...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Subject should be arm: omap2+: omap_device: remove no_idle_on_suspend
Also, you should remove the flag from omap_device.h.
Kevin
---
arch/arm/mach-omap2/omap_device.c |3 ---
arch/arm/mach-omap2/serial.c |7 ---
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index d6dce8f..c226946 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -170,9 +170,6 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
r-name = dev_name(pdev-dev);
}
- if (of_get_property(node, ti,no_idle_on_suspend, NULL))
- omap_device_disable_idle_on_suspend(pdev);
-
pdev-dev.pm_domain = omap_device_pm_domain;
odbfd_exit1:
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f660156..58d5b56 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -63,7 +63,6 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
static u8 console_uart_id = -1;
-static u8 no_console_suspend;
static u8 uart_debug;
#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate
(us) */
@@ -207,9 +206,6 @@ static int __init omap_serial_early_init(void)
uart_name, uart-num);
}
- if (cmdline_find_option(no_console_suspend))
- no_console_suspend = true;
-
/*
* omap-uart can be used for earlyprintk logs
* So if omap-uart is used as console then prevent
@@ -292,9 +288,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
return;
}
- if ((console_uart_id == bdata-id) no_console_suspend)
- omap_device_disable_idle_on_suspend(pdev);
-
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
if (console_uart_id == bdata-id) {
--
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/6] arm: mach-omap2: Remove no_console_suspend
Sourav Poddar sourav.pod...@ti.com writes:
Since the omap serial driver is now adapted to handle the
case where you dont need to cut the clock on suspend while
using no_console_suspend in the bootargs.
We can get rid of the previous implementation of setting the od-flags to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND from platform
and omap_device files.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Rajendra nayak rna...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
also, the serial.c change here should be a separate patch
subject: arm: omap2+: serial: remove no_console_suspend support
with a changelog stating that it's no longer handled in the core.
Kevin
---
arch/arm/mach-omap2/omap_device.c |3 ---
arch/arm/mach-omap2/serial.c |7 ---
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index d6dce8f..c226946 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -170,9 +170,6 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
r-name = dev_name(pdev-dev);
}
- if (of_get_property(node, ti,no_idle_on_suspend, NULL))
- omap_device_disable_idle_on_suspend(pdev);
-
pdev-dev.pm_domain = omap_device_pm_domain;
odbfd_exit1:
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f660156..58d5b56 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -63,7 +63,6 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
static u8 console_uart_id = -1;
-static u8 no_console_suspend;
static u8 uart_debug;
#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate
(us) */
@@ -207,9 +206,6 @@ static int __init omap_serial_early_init(void)
uart_name, uart-num);
}
- if (cmdline_find_option(no_console_suspend))
- no_console_suspend = true;
-
/*
* omap-uart can be used for earlyprintk logs
* So if omap-uart is used as console then prevent
@@ -292,9 +288,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
return;
}
- if ((console_uart_id == bdata-id) no_console_suspend)
- omap_device_disable_idle_on_suspend(pdev);
-
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
if (console_uart_id == bdata-id) {
--
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/6] driver: serial: omap: add prepare/complete callback for no_console_suspend case
Hi Kevin,
On Thursday 18 April 2013 11:26 PM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
The patch adapt the serial core/driver to take care of the case when
no_console_suspend
is used in the bootargs. The patch will remove dependency to set od-flags to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND in serial.c(non dt case) and omap_device.c(dt
case).
Prepare and complete callbacks will ensure that clocks remain active for the
console
uart when no_console_suspend is used in the bootargs.
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
This changelog needs a rework. The driver itself was not aware of
od-flags and omap_device stuff in general, so it's not really
relevant. The driver is also not directly managing clocks, int's only
doing runtime PM callbacks.
What you want to say in the changelog is that the driver manages
no_console_suspend by preventing runtime PM during the suspend path,
which forces the console UART to stay awake.
Yes, looks to the point. Will update the changelog in the next version.
---
drivers/tty/serial/omap-serial.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 08332f3..9ef80cf 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1278,6 +1278,24 @@ static struct uart_driver serial_omap_reg = {
};
#ifdef CONFIG_PM_SLEEP
+static int serial_omap_prepare(struct device *dev)
+{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+
+ if (!console_suspend_enabled uart_console(up-port))
+ pm_runtime_disable(dev);
+
+ return 0;
+}
+
+static void serial_omap_complete(struct device *dev)
+{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+
+ if (!console_suspend_enabled uart_console(up-port))
+ pm_runtime_enable(dev);
+}
+
For compilation with !CONFIG_PM_SLEEP, you'll also need:
#else
#define serial_omap_prepare NULL
#define serial_omap_prepare NULL
#endif /* CONFIG_PM_SLEEP */
Ok. Will change this.
Though, just a query/proposal on this, will it be correct if we try to
create a macro[1]
in include/linux/pm.h for prepare/complete as it is done for
suspend/resume. ?
[1]:
#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_PREP_COMP_OPS(prepare_fn, complete_fn) \
.prepare = prepare_fn, \
.complete = complete_fn, \
#else
#define SET_SYSTEM_SLEEP_PM_PREP_COMP_OPS(prepare_fn, complete_fn)
#endif
~Sourav
static int serial_omap_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
@@ -1632,6 +1650,8 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(serial_omap_suspend, serial_omap_resume)
SET_RUNTIME_PM_OPS(serial_omap_runtime_suspend,
serial_omap_runtime_resume, NULL)
+ .prepare= serial_omap_prepare,
+ .complete = serial_omap_complete,
};
#if defined(CONFIG_OF)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ARM: OMAP4+: Add a timer attribute for timers that can interrupt IPU
Jon,
On 04/17/2013 07:04 PM, Jon Hunter wrote:
On 04/17/2013 06:23 PM, Suman Anna wrote:
Some instances of the DMTIMER peripheral on OMAP4+ devices have the
ability to interrupt the on-chip image processor unit (IPU) subsystem
(a common name for the dual Cortex-M3 subsystem on OMAP4 or the dual
Cortex-M4 subsystem on OMAP5) in addition to the ARM CPU. Add a
DMTIMER attribute to indicate which timers can interrupt the IPU.
This patch is similar to the patch, 5c3e4ec (ARM: OMAP: Add a timer
attribute for timers that can interrupt the DSP) that adds a similar
capability for DSP.
DMTIMERs that have the ability to interrupt the IPU on OMAP devices
are as follows:
OMAP1/2/3 devices : not applicable
OMAP4/5 devices : DMTIMERs 3,4,9 11
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/devicetree/bindings/arm/omap/timer.txt | 3 +++
arch/arm/boot/dts/omap4.dtsi | 4
arch/arm/boot/dts/omap5.dtsi | 4
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16
++--
arch/arm/plat-omap/dmtimer.c | 2 ++
arch/arm/plat-omap/include/plat/dmtimer.h| 1 +
6 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
index 8732d4d..edaf664 100644
--- a/Documentation/devicetree/bindings/arm/omap/timer.txt
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -15,6 +15,9 @@ Optional properties:
- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
- ti,timer-dsp: Indicates the timer can interrupt the on-chip
DSP
in
addition to the ARM CPU.
+- ti,timer-ipu: Indicates the timer can interrupt the on-chip
IPU
(the
+ dual Cortex-M3/Cortex-M4 subsystem on
OMAP4/OMAP5) in
+ addition to the ARM CPU.
I am ok with adding a new property. However, reading the omap5
reference manual I see that the timers can interrupt the dsp, c2c and ipu.
Therefore, I am not sure if we should consider making this a property
with a value that is a mask of all other devices that can be
interrupted. For example, ti,timer-irqs.
Do you intend for this to be only a DT entry simplification, but re-use the
capability element in struct omap_dm_timer when parsing it and storing it? That
might be ok since the capability property is already a bit-mask. If the
intention is to add another element/property, then I feel it may not add that
much value.
- ti,timer-pwm: Indicates the timer can generate a PWM output.
- ti,timer-secure:Indicates the timer is reserved on a secure
OMAP device
and therefore cannot be used by the kernel.
diff --git a/arch/arm/boot/dts/omap4.dtsi
b/arch/arm/boot/dts/omap4.dtsi index 739bb79..55c633a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -460,6 +460,7 @@
reg = 0x48034000 0x80;
interrupts = 0 39 0x4;
ti,hwmods = timer3;
+ ti,timer-ipu;
};
timer4: timer@48036000 {
@@ -467,6 +468,7 @@
reg = 0x48036000 0x80;
interrupts = 0 40 0x4;
ti,hwmods = timer4;
+ ti,timer-ipu;
};
timer5: timer@40138000 {
@@ -511,6 +513,7 @@
reg = 0x4803e000 0x80;
interrupts = 0 45 0x4;
ti,hwmods = timer9;
+ ti,timer-ipu;
ti,timer-pwm;
};
@@ -527,6 +530,7 @@
reg = 0x48088000 0x80;
interrupts = 0 47 0x4;
ti,hwmods = timer11;
+ ti,timer-ipu;
ti,timer-pwm;
};
};
diff --git a/arch/arm/boot/dts/omap5.dtsi
b/arch/arm/boot/dts/omap5.dtsi index 0d155f5..c9ecdbe 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -406,6 +406,7 @@
reg = 0x48034000 0x80;
interrupts = 0 39 0x4;
ti,hwmods = timer3;
+ ti,timer-ipu;
};
timer4: timer@48036000 {
@@ -413,6 +414,7 @@
reg = 0x48036000 0x80;
interrupts = 0 40 0x4;
ti,hwmods = timer4;
+ ti,timer-ipu;
};
timer5: timer@40138000 {
@@ -459,6 +461,7 @@
reg = 0x4803e000 0x80;
interrupts = 0 45 0x4;
ti,hwmods = timer9;
+ ti,timer-ipu;
ti,timer-pwm;
};
@@ -475,6 +478,7 @@
Re: [PATCH 0/6] Serial Omap fixes and cleanups
Hi Sourav, Sourav Poddar sourav.pod...@ti.com writes: Hi, This patch series contains fixes and cleanups around the issue that the console UART should not idled on suspend while using no_console_suspend in bootargs. The direction of the series is right, thanks for the updated approach. I had a comple minor comments on specific patches, but the ordering of the series needs a little tweaking. It should be - core/driver changes [current 1-3/6 are ok] - remove usage from mach-omap2/serial.c (currently part of 4/6) - remove am33x DT usage (current 5/6 is ok) - remove entirely from omap_device (omap_device part of 4/6 and 6/6 should be combined) Kevin The approach thought of is to modify the serial core/serial driver to bypass runtime PM if the UART in contention is a console and we are using no_console_suspend in our bootargs. While fixing the above issue, there are other cleanups also done as part of this series which are no longer required. This cleanups mainly include getting rid of using omap_device_disable_idle_on_suspend api for both dt and non dt case as the serial driver will be self sufficient to handle the no_idle_on_suspend issue. Serial was the only one making use of omap_device_disable_idle_on_suspend Test info (except drivers: serial: mpc52xx_uart: Remove uart_console defintion): Omap4430sdp: - Tested wakeup from UART after suspend for dt and non dt case. Omap5430evm: - Tested wakeup from UART after suspend for dt case. There were discussions about how to handle no_idle_on_suspend issue and all the discussions are as follows: [v3]: https://lkml.org/lkml/2013/4/5/239 [v2]: https://lkml.org/lkml/2013/4/2/350 [v1]: https://lkml.org/lkml/2013/3/18/199 https://lkml.org/lkml/2013/3/18/295 Due to the amount of change in approach and other cleanups coming around it, I am posting this as a new series. This patches are based on 3.9-rc3 custom tree which has Santosh Shilimkar serial patch[1] [1]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/95828 Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Rajendra nayak rna...@ti.com Sourav Poddar (6): drivers: tty: serial: Move uart_console def to core header file. drivers: serial: mpc52xx_uart: Remove uart_console defintion driver: serial: omap: add prepare/complete callback for no_console_suspend case arm: mach-omap2: remove OMAP_DEVICE_NO_IDLE_ON_SUSPEND check arm: dts: am33xx: Remove ti,no_idle_on_suspend property. arm: mach-omap2: Remove no_console_suspend arch/arm/boot/dts/am33xx.dtsi |1 - arch/arm/mach-omap2/omap_device.c | 10 +- arch/arm/mach-omap2/serial.c |7 --- drivers/tty/serial/mpc52xx_uart.c | 10 -- drivers/tty/serial/omap-serial.c | 20 drivers/tty/serial/serial_core.c |6 -- include/linux/serial_core.h |6 ++ 7 files changed, 27 insertions(+), 33 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP4+: Add a timer attribute for timers that can interrupt IPU
On 04/18/2013 01:21 PM, Anna, Suman wrote:
Jon,
On 04/17/2013 07:04 PM, Jon Hunter wrote:
On 04/17/2013 06:23 PM, Suman Anna wrote:
Some instances of the DMTIMER peripheral on OMAP4+ devices have the
ability to interrupt the on-chip image processor unit (IPU) subsystem
(a common name for the dual Cortex-M3 subsystem on OMAP4 or the dual
Cortex-M4 subsystem on OMAP5) in addition to the ARM CPU. Add a
DMTIMER attribute to indicate which timers can interrupt the IPU.
This patch is similar to the patch, 5c3e4ec (ARM: OMAP: Add a timer
attribute for timers that can interrupt the DSP) that adds a similar
capability for DSP.
DMTIMERs that have the ability to interrupt the IPU on OMAP devices
are as follows:
OMAP1/2/3 devices : not applicable
OMAP4/5 devices : DMTIMERs 3,4,9 11
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/devicetree/bindings/arm/omap/timer.txt | 3 +++
arch/arm/boot/dts/omap4.dtsi | 4
arch/arm/boot/dts/omap5.dtsi | 4
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16
++--
arch/arm/plat-omap/dmtimer.c | 2 ++
arch/arm/plat-omap/include/plat/dmtimer.h| 1 +
6 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
index 8732d4d..edaf664 100644
--- a/Documentation/devicetree/bindings/arm/omap/timer.txt
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -15,6 +15,9 @@ Optional properties:
- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
- ti,timer-dsp: Indicates the timer can interrupt the on-chip
DSP
in
addition to the ARM CPU.
+- ti,timer-ipu: Indicates the timer can interrupt the on-chip
IPU
(the
+ dual Cortex-M3/Cortex-M4 subsystem on
OMAP4/OMAP5) in
+ addition to the ARM CPU.
I am ok with adding a new property. However, reading the omap5
reference manual I see that the timers can interrupt the dsp, c2c and ipu.
Therefore, I am not sure if we should consider making this a property
with a value that is a mask of all other devices that can be
interrupted. For example, ti,timer-irqs.
Do you intend for this to be only a DT entry simplification, but re-use the
capability element in struct omap_dm_timer when parsing it and storing it?
That might be ok since the capability property is already a bit-mask. If the
intention is to add another element/property, then I feel it may not add that
much value.
Yes DT only simplifcation.
- ti,timer-pwm: Indicates the timer can generate a PWM output.
- ti,timer-secure:Indicates the timer is reserved on a secure
OMAP device
and therefore cannot be used by the kernel.
diff --git a/arch/arm/boot/dts/omap4.dtsi
b/arch/arm/boot/dts/omap4.dtsi index 739bb79..55c633a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -460,6 +460,7 @@
reg = 0x48034000 0x80;
interrupts = 0 39 0x4;
ti,hwmods = timer3;
+ ti,timer-ipu;
};
timer4: timer@48036000 {
@@ -467,6 +468,7 @@
reg = 0x48036000 0x80;
interrupts = 0 40 0x4;
ti,hwmods = timer4;
+ ti,timer-ipu;
};
timer5: timer@40138000 {
@@ -511,6 +513,7 @@
reg = 0x4803e000 0x80;
interrupts = 0 45 0x4;
ti,hwmods = timer9;
+ ti,timer-ipu;
ti,timer-pwm;
};
@@ -527,6 +530,7 @@
reg = 0x48088000 0x80;
interrupts = 0 47 0x4;
ti,hwmods = timer11;
+ ti,timer-ipu;
ti,timer-pwm;
};
};
diff --git a/arch/arm/boot/dts/omap5.dtsi
b/arch/arm/boot/dts/omap5.dtsi index 0d155f5..c9ecdbe 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -406,6 +406,7 @@
reg = 0x48034000 0x80;
interrupts = 0 39 0x4;
ti,hwmods = timer3;
+ ti,timer-ipu;
};
timer4: timer@48036000 {
@@ -413,6 +414,7 @@
reg = 0x48036000 0x80;
interrupts = 0 40 0x4;
ti,hwmods = timer4;
+ ti,timer-ipu;
};
timer5: timer@40138000 {
@@ -459,6 +461,7 @@
reg = 0x4803e000 0x80;
interrupts = 0 45 0x4;
ti,hwmods = timer9;
+ ti,timer-ipu;
ti,timer-pwm;
};
@@ -475,6 +478,7 @@
reg = 0x48088000 0x80;
Re: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
On 04/18/2013 04:30 AM, Vincent Stehlé wrote:
On 04/17/2013 10:16 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
(..)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..0c48f6b 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
(..)
@@ -135,6 +136,25 @@
0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
;
};
+
+ led_gpio_pins: pinmux_leds_pins {
+ pinctrl-single,pins =
+ ;
+ };
+};
Hi,
FYI, there was a recent discussion precisely on this topic, where Tomy
suggested to remove the empty section:
http://marc.info/?l=linux-omapm=136546635409232w=2
Apart from that, I just tested your patch on top of Tomy's
omap-for-v3.10/dt branch and it is working fine for me on PandaBoards
EA3, A4 and ES.
Tested-by: Vincent Stehlé v-ste...@ti.com
Best regards,
V.
Thanks for testing Vincent
Is there a way to append the data to an already existing node?
I do not see a clean way.
Dan
--
--
Dan Murphy
--
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
ARM: dts: omap3: NAND support - how?
Hi
I'm trying to setup nand support for an omap3 board for linux-next
(next-20130417). This is my approach so far:
+gpmc {
+ ranges = 0 0 0x3000 0x100;
+ nand@0,0 {
+ reg = 0 0 0xff; /* - ? not sure about that */
+ nand-bus-width = 16;
+ ti,nand-ecc-opt = bch8;
+ /* no elm on omap3 */
+
+ gpmc,time-para-granularity = 0;
+ gpmc,mux-add-data = 0;
+ gpmc,device-nand = 1;
+ gpmc,device-width = 2;
+ gpmc,wait-pin = 0;
+ gpmc,wait-on-write = 0;
+ gpmc,wait-on-read = 0;
+ gpmc,burst-length= 4;
+ gpmc,sync-write = 0;
+ gpmc,burst-write = 0;
+ gpmc,sync-read = 0;
+ gpmc,burst-read = 0;
+ gpmc,burst-wrap = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-extra-delay = 0;
+ gpmc,cs-rd-off-ns = 0x14;
+ gpmc,cs-wr-off-ns = 0x14;
+ gpmc,adv-on-ns = 0;
+ gpmc,adv-extra-delay = 0;
+ gpmc,adv-rd-off-ns = 0x14;
+ gpmc,adv-wr-off-ns = 0x14;
+ gpmc,oe-on-ns = 0x1;
+ gpmc,oe-extra-delay = 0;
+ gpmc,oe-off-ns = 0xF;
+ gpmc,we-on-ns = 0x1;
+ gpmc,we-extra-delay = 0;
+ gpmc,we-off-ns = 0xF;
+ gpmc,rd-cycle-ns = 0x14;
+ gpmc,wr-cycle-ns = 0x14;
+ gpmc,access-ns = 0xC;
+ gpmc,page-burst-access-ns = 0x1;
+ gpmc,bus-turnaround-ns = 0x0;
+ gpmc,cycle2cycle-diffcsen = 0x0;
+ gpmc,cycle2cycle-samecsen = 0x1;
+ gpmc,cycle2cycle-delay-ns = 0xA;
+ gpmc,wr-data-mux-bus-ns = 0xF;
+ gpmc,wr-access-ns = 0x1F;
+
+ #address-cells = 1; /* - ? not sure about that */
+ #size-cells = 1; /* - ? not sure about that */
+ };
+};
+
I took the GPMC NAND config from u-boot where it's working correct.
Without the additional nand approach from above, the board is working
more or less fine. But with this patch I do get the following crash:
[1.372467] mtdoops: mtd device (mtddev=name/number) must be supplied
[1.380615] Missing elm_id property, fall back to Software BCH
[1.389373] enabling NAND BCH ecc with 8-bit correction
[1.394927] nand_read_byte16, 166, 0xc8852000
[1.403625] Unhandled fault: external abort on non-linefetch (0x1008) at
0xc8852000
[1.411651] Internal error: : 1008 [#1] PREEMPT ARM
[1.416778] Modules linked in:
[1.419982] CPU: 0Not tainted
(3.9.0-rc7-next-20130417-00036-ga693803-dirty #373)
[1.428283] PC is at nand_read_byte16+0x30/0x64
[1.433044] LR is at nand_read_byte16+0x2c/0x64
[1.437774] pc : [c032f358]lr : [c032f354]psr: 2113
[1.437774] sp : c7057dd8 ip : c7055440 fp :
[1.449798] r10: c7057e4c r9 : c7057e48 r8 :
[1.455291] r7 : c72ce370 r6 : c72ce370 r5 : c05f9bb8 r4 : c051c270
[1.462158] r3 : c7055440 r2 : c8852000 r1 : 0001 r0 : 0021
[1.468994] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
kernel
[1.476623] Control: 10c5387d Table: 80004019 DAC: 0015
[1.482635] Process swapper (pid: 1, stack limit = 0xc7056238)
[1.488739] Stack: (0xc7057dd8 to 0xc7058000)
[1.493316] 7dc0:
c72ce050 00ff
[1.501861] 7de0: c033194c c72ce370 c72ce050
c7057e18 c03320bc
[1.510437] 7e00: 0001 c72c7b80 c72ce000 c72ce050 0002
c0c74054
[1.519042] 7e20: c72ce370 c72ce050 0001 0002 008e
c0702a20 c0332674
[1.527648] 7e40: c7057e48 c0637790 0008 c72ce000
c72ce050 c700a690
[1.536285] 7e60: c0c74054 008e c0336300 c72c7f50
c7120ef0
[1.544921] 7e80: c0702a20 c0702a28 c0c73628 c072a57c c0702a20
c072a57c
[1.553527] 7ea0: c06d12fc c02ef658 c0c73628 c02ee32c c0702a20 c072a57c
c0702a54
[1.562133] 7ec0: c06c709c c02ee4e4 c0702a20 c072a57c c0702a54 c02ee590
c072a57c c02ee4fc
[1.570709] 7ee0: c7057ee8 c02ecc5c c704b2a8 c7115690 c704b2d8 c072a57c
c0723888 c72ba640
[1.579284] 7f00: c02ed504 c05fed1c c072a57c c073bd40 c06d12f4
c072a57c c073bd40
[1.587890] 7f20: c02eeb80 c06d12f4 c06db898 c073bd40
c06c709c c000874c
[1.596496] 7f40: c06d12f4 0006 c073bd40 c06d12f4 c06db898
c073bd40 0007
[1.605072] 7f60: c06aa3e8 c06aa2b0 0006 0006 c06aa3e8
c06db460 c06db460
[1.613616] 7f80: c06aa350
c04eb510
[1.622192] 7fa0: c04eb518 c0009ec8
[1.630767] 7fc0:
Re: [PATCH 4/6] arm: mach-omap2: remove OMAP_DEVICE_NO_IDLE_ON_SUSPEND check
On Thursday 18 April 2013 11:35 PM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
Remove the OMAP_DEVICE_NO_IDLE_ON_SUSPEND check, since UART was the only one
making
use of it. Now serial core/driver takes care of the case when
no_console_suspend
is used in the bootargs and you need to keep the clock enable for console even
while suspend.
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
NAK. This patch will break many things...
---
arch/arm/mach-omap2/omap_device.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 381be7a..d6dce8f 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -620,11 +620,8 @@ static int _od_suspend_noirq(struct device *dev)
ret = pm_generic_suspend_noirq(dev);
if (!ret !pm_runtime_status_suspended(dev)) {
- if (pm_generic_runtime_suspend(dev) == 0) {
- if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
- omap_device_idle(pdev);
Why did you remove the omap_device_idle() here?
This patch is used along with patch3 to get rid of the issue. I posted
them as a
seperate patch beacuse of the subject line as one goes under drivers/*
and the other
arm/mach-omap2/*..
This check was only valid for UART, and if od-flags is set to the
OMAP_DEVICE_NO_IDLE_ON_SUSPEND flag, then UART will not be idled. But now,
we no longer depend on od-flag value to prevent idling of our console
UART as the
prepare/complete apis will take care of them.
+ if (pm_generic_runtime_suspend(dev) == 0)
od-flags |= OMAP_DEVICE_SUSPENDED;
- }
}
return ret;
@@ -638,8 +635,6 @@ static int _od_resume_noirq(struct device *dev)
if ((od-flags OMAP_DEVICE_SUSPENDED)
!pm_runtime_status_suspended(dev)) {
od-flags= ~OMAP_DEVICE_SUSPENDED;
- if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
- omap_device_enable(pdev);
And the _enable() here?
pm_generic_runtime_resume(dev);
}
Note that the check is for when the flag is *not* set, so this patch
changes behavior for all the drivers that do not use
_NO_IDLE_ON_SUSPEND. I think that's the opposite of what you intended.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] arm: mach-omap2: Remove no_console_suspend
Hi Kevin,
On Thursday 18 April 2013 11:39 PM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
Since the omap serial driver is now adapted to handle the
case where you dont need to cut the clock on suspend while
using no_console_suspend in the bootargs.
We can get rid of the previous implementation of setting the od-flags to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND from platform
and omap_device files.
Cc: Santosh Shilimkarsantosh.shilim...@ti.com
Cc: Felipe Balbiba...@ti.com
Cc: Rajendra nayakrna...@ti.com
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
Subject should be arm: omap2+: omap_device: remove no_idle_on_suspend
Also, you should remove the flag from omap_device.h.
Kevin
Ok. Will change it in the next version.
~Sourav
---
arch/arm/mach-omap2/omap_device.c |3 ---
arch/arm/mach-omap2/serial.c |7 ---
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index d6dce8f..c226946 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -170,9 +170,6 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
r-name = dev_name(pdev-dev);
}
- if (of_get_property(node, ti,no_idle_on_suspend, NULL))
- omap_device_disable_idle_on_suspend(pdev);
-
pdev-dev.pm_domain =omap_device_pm_domain;
odbfd_exit1:
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f660156..58d5b56 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -63,7 +63,6 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
static u8 console_uart_id = -1;
-static u8 no_console_suspend;
static u8 uart_debug;
#define DEFAULT_RXDMA_POLLRATE1 /* RX DMA polling rate
(us) */
@@ -207,9 +206,6 @@ static int __init omap_serial_early_init(void)
uart_name, uart-num);
}
- if (cmdline_find_option(no_console_suspend))
- no_console_suspend = true;
-
/*
* omap-uart can be used for earlyprintk logs
* So if omap-uart is used as console then prevent
@@ -292,9 +288,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
return;
}
- if ((console_uart_id == bdata-id) no_console_suspend)
- omap_device_disable_idle_on_suspend(pdev);
-
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
if (console_uart_id == bdata-id) {
--
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/6] arm: mach-omap2: Remove no_console_suspend
Hi Kevin,
On Thursday 18 April 2013 11:41 PM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
Since the omap serial driver is now adapted to handle the
case where you dont need to cut the clock on suspend while
using no_console_suspend in the bootargs.
We can get rid of the previous implementation of setting the od-flags to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND from platform
and omap_device files.
Cc: Santosh Shilimkarsantosh.shilim...@ti.com
Cc: Felipe Balbiba...@ti.com
Cc: Rajendra nayakrna...@ti.com
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
also, the serial.c change here should be a separate patch
subject: arm: omap2+: serial: remove no_console_suspend support
with a changelog stating that it's no longer handled in the core.
Ok. Will create a seperate patch and update the changelog.
Kevin
---
arch/arm/mach-omap2/omap_device.c |3 ---
arch/arm/mach-omap2/serial.c |7 ---
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index d6dce8f..c226946 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -170,9 +170,6 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
r-name = dev_name(pdev-dev);
}
- if (of_get_property(node, ti,no_idle_on_suspend, NULL))
- omap_device_disable_idle_on_suspend(pdev);
-
pdev-dev.pm_domain =omap_device_pm_domain;
odbfd_exit1:
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f660156..58d5b56 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -63,7 +63,6 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
static u8 console_uart_id = -1;
-static u8 no_console_suspend;
static u8 uart_debug;
#define DEFAULT_RXDMA_POLLRATE1 /* RX DMA polling rate
(us) */
@@ -207,9 +206,6 @@ static int __init omap_serial_early_init(void)
uart_name, uart-num);
}
- if (cmdline_find_option(no_console_suspend))
- no_console_suspend = true;
-
/*
* omap-uart can be used for earlyprintk logs
* So if omap-uart is used as console then prevent
@@ -292,9 +288,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
return;
}
- if ((console_uart_id == bdata-id) no_console_suspend)
- omap_device_disable_idle_on_suspend(pdev);
-
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
if (console_uart_id == bdata-id) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Serial Omap fixes and cleanups
Hi Kevin, On Thursday 18 April 2013 11:53 PM, Kevin Hilman wrote: Hi Sourav, Sourav Poddarsourav.pod...@ti.com writes: Hi, This patch series contains fixes and cleanups around the issue that the console UART should not idled on suspend while using no_console_suspend in bootargs. The direction of the series is right, thanks for the updated approach. I had a comple minor comments on specific patches, but the ordering of the series needs a little tweaking. It should be - core/driver changes [current 1-3/6 are ok] - remove usage from mach-omap2/serial.c (currently part of 4/6) - remove am33x DT usage (current 5/6 is ok) - remove entirely from omap_device (omap_device part of 4/6 and 6/6 should be combined) Thanks a lot for your review and comments. I have replied to your comments on the respective patches. Will take care of the ordering which you mentioned above in the next version. Thanks Sourav Kevin The approach thought of is to modify the serial core/serial driver to bypass runtime PM if the UART in contention is a console and we are using no_console_suspend in our bootargs. While fixing the above issue, there are other cleanups also done as part of this series which are no longer required. This cleanups mainly include getting rid of using omap_device_disable_idle_on_suspend api for both dt and non dt case as the serial driver will be self sufficient to handle the no_idle_on_suspend issue. Serial was the only one making use of omap_device_disable_idle_on_suspend Test info (except drivers: serial: mpc52xx_uart: Remove uart_console defintion): Omap4430sdp: - Tested wakeup from UART after suspend for dt and non dt case. Omap5430evm: - Tested wakeup from UART after suspend for dt case. There were discussions about how to handle no_idle_on_suspend issue and all the discussions are as follows: [v3]: https://lkml.org/lkml/2013/4/5/239 [v2]: https://lkml.org/lkml/2013/4/2/350 [v1]: https://lkml.org/lkml/2013/3/18/199 https://lkml.org/lkml/2013/3/18/295 Due to the amount of change in approach and other cleanups coming around it, I am posting this as a new series. This patches are based on 3.9-rc3 custom tree which has Santosh Shilimkar serial patch[1] [1]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/95828 Cc: Santosh Shilimkarsantosh.shilim...@ti.com Cc: Felipe Balbiba...@ti.com Cc: Rajendra nayakrna...@ti.com Sourav Poddar (6): drivers: tty: serial: Move uart_console def to core header file. drivers: serial: mpc52xx_uart: Remove uart_console defintion driver: serial: omap: add prepare/complete callback for no_console_suspend case arm: mach-omap2: remove OMAP_DEVICE_NO_IDLE_ON_SUSPEND check arm: dts: am33xx: Remove ti,no_idle_on_suspend property. arm: mach-omap2: Remove no_console_suspend arch/arm/boot/dts/am33xx.dtsi |1 - arch/arm/mach-omap2/omap_device.c | 10 +- arch/arm/mach-omap2/serial.c |7 --- drivers/tty/serial/mpc52xx_uart.c | 10 -- drivers/tty/serial/omap-serial.c | 20 drivers/tty/serial/serial_core.c |6 -- include/linux/serial_core.h |6 ++ 7 files changed, 27 insertions(+), 33 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: dts: omap3: NAND support - how?
On 04/18/2013 02:03 PM, Christoph Fritz wrote:
Hi
I'm trying to setup nand support for an omap3 board for linux-next
(next-20130417). This is my approach so far:
+gpmc {
+ ranges = 0 0 0x3000 0x100;
+ nand@0,0 {
+ reg = 0 0 0xff; /* - ? not sure about that */
I had put the complete size in here so ...
+ reg = 0 0 0x100;
+ nand-bus-width = 16;
+ ti,nand-ecc-opt = bch8;
+ /* no elm on omap3 */
+
+ gpmc,time-para-granularity = 0;
This is a boolean parameter so you don't need the = 0.
+ gpmc,mux-add-data = 0;
This should be either 1 or 2.
+ gpmc,device-nand = 1;
This is a boolean parameter so you don't need the = 0.
+ gpmc,device-width = 2;
+ gpmc,wait-pin = 0;
+ gpmc,wait-on-write = 0;
This is a boolean parameter so you don't need the = 0.
+ gpmc,wait-on-read = 0;
This is a boolean parameter so you don't need the = 0.
+ gpmc,burst-length= 4;
+ gpmc,sync-write = 0;
This is a boolean parameter so you don't need the = 0.
+ gpmc,burst-write = 0;
This is a boolean parameter so you don't need the = 0.
+ gpmc,sync-read = 0;
This is a boolean parameter so you don't need the = 0.
+ gpmc,burst-read = 0;
This is a boolean parameter so you don't need the = 0.
+ gpmc,burst-wrap = 0;
This is a boolean parameter so you don't need the = 0.
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-extra-delay = 0;
+ gpmc,cs-rd-off-ns = 0x14;
+ gpmc,cs-wr-off-ns = 0x14;
+ gpmc,adv-on-ns = 0;
+ gpmc,adv-extra-delay = 0;
+ gpmc,adv-rd-off-ns = 0x14;
+ gpmc,adv-wr-off-ns = 0x14;
+ gpmc,oe-on-ns = 0x1;
+ gpmc,oe-extra-delay = 0;
+ gpmc,oe-off-ns = 0xF;
+ gpmc,we-on-ns = 0x1;
+ gpmc,we-extra-delay = 0;
+ gpmc,we-off-ns = 0xF;
+ gpmc,rd-cycle-ns = 0x14;
+ gpmc,wr-cycle-ns = 0x14;
+ gpmc,access-ns = 0xC;
+ gpmc,page-burst-access-ns = 0x1;
+ gpmc,bus-turnaround-ns = 0x0;
+ gpmc,cycle2cycle-diffcsen = 0x0;
+ gpmc,cycle2cycle-samecsen = 0x1;
+ gpmc,cycle2cycle-delay-ns = 0xA;
+ gpmc,wr-data-mux-bus-ns = 0xF;
+ gpmc,wr-access-ns = 0x1F;
+
+ #address-cells = 1; /* - ? not sure about that */
+ #size-cells = 1; /* - ? not sure about that */
This is just needed in case you wish to list partition info. Seeing as
you don't you can omit.
+ };
+};
+
I took the GPMC NAND config from u-boot where it's working correct.
Without the additional nand approach from above, the board is working
more or less fine. But with this patch I do get the following crash:
[1.372467] mtdoops: mtd device (mtddev=name/number) must be supplied
[1.380615] Missing elm_id property, fall back to Software BCH
[1.389373] enabling NAND BCH ecc with 8-bit correction
[1.394927] nand_read_byte16, 166, 0xc8852000
[1.403625] Unhandled fault: external abort on non-linefetch (0x1008) at
0xc8852000
[1.411651] Internal error: : 1008 [#1] PREEMPT ARM
[1.416778] Modules linked in:
[1.419982] CPU: 0Not tainted
(3.9.0-rc7-next-20130417-00036-ga693803-dirty #373)
[1.428283] PC is at nand_read_byte16+0x30/0x64
[1.433044] LR is at nand_read_byte16+0x2c/0x64
[1.437774] pc : [c032f358]lr : [c032f354]psr: 2113
[1.437774] sp : c7057dd8 ip : c7055440 fp :
[1.449798] r10: c7057e4c r9 : c7057e48 r8 :
[1.455291] r7 : c72ce370 r6 : c72ce370 r5 : c05f9bb8 r4 : c051c270
[1.462158] r3 : c7055440 r2 : c8852000 r1 : 0001 r0 : 0021
[1.468994] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
kernel
[1.476623] Control: 10c5387d Table: 80004019 DAC: 0015
[1.482635] Process swapper (pid: 1, stack limit = 0xc7056238)
[1.488739] Stack: (0xc7057dd8 to 0xc7058000)
[1.493316] 7dc0:
c72ce050 00ff
[1.501861] 7de0: c033194c c72ce370 c72ce050
c7057e18 c03320bc
[1.510437] 7e00: 0001 c72c7b80 c72ce000 c72ce050 0002
c0c74054
[1.519042] 7e20: c72ce370 c72ce050 0001 0002 008e
c0702a20 c0332674
[1.527648] 7e40: c7057e48 c0637790 0008 c72ce000
c72ce050 c700a690
[1.536285] 7e60: c0c74054 008e c0336300 c72c7f50
c7120ef0
[1.544921] 7e80: c0702a20 c0702a28 c0c73628 c072a57c c0702a20
c072a57c
[
Re: [PATCH] ARM: dts: omap4-panda: Add USB Host support
* Roger Quadros rog...@ti.com [130415 01:53]:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
The USB PHY needs AUXCLK3 to operate. Provide this information
as well.
Also provide pin multiplexer information for the USB host
pins.
This patch depends on OMAP clock binding introduced in
https://lkml.org/lkml/2013/4/12/407
Cool looks like EHCI works with this on my panda with linux
next booting with DT. One comment below.
Regards,
Tony
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 58
+
arch/arm/boot/dts/omap4.dtsi |5 ++
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..628f744 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -54,6 +54,38 @@
AFML, Line In,
AFMR, Line In;
};
+
+ /* HS USB Port 1 RESET */
+ hsusb1_reset: hsusb1_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio2 30 0; /* gpio_62 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio1 1 0;/* gpio_1 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ vcc-supply = hsusb1_power;
+ clocks = auxclk3;
+ clock-names = main_clk;
+ clock-frequency = 1920;
+ };
};
omap4_pmx_core {
@@ -64,6 +96,7 @@
mcbsp1_pins
dss_hdmi_pins
tpd12s015_pins
+ hsusbb1_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -108,6 +141,23 @@
;
};
+ hsusbb1_pins: pinmux_hsusbb1_pins {
+ pinctrl-single,pins =
+ 0x82 0x10C /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
+ 0x84 0x4/*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x86 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x88 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x8a 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x8c 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x8e 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x90 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x92 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x94 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x96 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x98 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
+
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins =
0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
Looks like your comments are wrong above, it's not PULLDOWN? Also
the naming should be mode0name.modename to be consistent. Here's
what I dumped out, please check and replace spaces with tabs:
0x82 0x10c /* usbb1_ulpitll_clk.usbb1_ulpiphy_clk
gpio84 INPUT_PULLDOWN | MODE4 */
0x84 0x4/* usbb1_ulpitll_stp.usbb1_ulpiphy_stp
gpio85 OUTPUT | MODE4 */
0x86 0x104 /* usbb1_ulpitll_dir.usbb1_ulpiphy_dir
gpio86 INPUT | MODE4 */
0x88 0x104 /* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt
gpio87 INPUT | MODE4 */
0x8a 0x104 /*
usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 gpio88 INPUT | MODE4 */
0x8c 0x104 /*
usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 gpio89 INPUT | MODE4 */
0x8e 0x104 /*
Re: ARM: dts: omap3: NAND support - how?
Hi Jon On Thu, 2013-04-18 at 14:39 -0500, Jon Hunter wrote: On 04/18/2013 02:03 PM, Christoph Fritz wrote: I had put the complete size in here so ... + reg = 0 0 0x100; Thanks. + nand-bus-width = 16; + ti,nand-ecc-opt = bch8; + /* no elm on omap3 */ + + gpmc,time-para-granularity = 0; This is a boolean parameter so you don't need the = 0. When I want to disable this boolean I thought I need to add the 0 (or not defining at all) otherwise a single gpmc,time-para-granularity would be interpreted as enabled. + gpmc,mux-add-data = 0; This should be either 1 or 2. In arch/arm/mach-omap2/gpmc.h it gets set by this: #define GPMC_CONFIG1_MUXTYPE(val) ((val 3) 8) but the TRM for AM/DM37x as well as the TRM for Omap35x says: |9 MUXADDDATA Enables the Address and data multiplexed protocol (Reset RW 0x- | value is CS0MUXDEVICE input pin sampled at IC reset for | CS0 and 0 for CS1-7) | 0x0: Non Multiplexed attached device | 0x1: Address and data multiplexed attached device From u-boot I got 0x1800 for register GPMC_CONFIG1. So Bit 9 is 0. Why should I set it here to non zero? + gpmc,device-nand = 1; This is a boolean parameter so you don't need the = 0. The nand here is attached by 16 lines. So I'm pretty sure I need the 1 or at least gpmc,device-nand; don't I? + + #address-cells = 1; /* - ? not sure about that */ + #size-cells = 1; /* - ? not sure about that */ This is just needed in case you wish to list partition info. Seeing as you don't you can omit. Thanks. Can you include the complete boot log? I am wondering if there were any errors seen during the gpmc probe. U-Boot SPL 2013.04-rc2-08894-g33f264f-dirty (Apr 17 2013 - 23:00:59) U-Boot 2013.04-rc2-08894-g33f264f-dirty (Apr 17 2013 - 23:00:59) OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 128 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 In:serial Out: serial Err: serial Read back SMSC id 0x9221 Die ID #017200029e3801683b051201102a Net: smc911x-0 Hit any key to stop autoboot: 0 OMAP3_EVM # md 0x6E60 7 6e60: 1800 00141400 00141400 0f010f01 6e70: 010c1414 1f0f0a80 0870 p... OMAP3_EVM # boot smc911x: detected LAN9221 controller smc911x: phy initialized smc911x: MAC 00:50:c2:0d:6a:63 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 172.16.21.17 Using smc911x-0 device TFTP from server 172.16.21.1; our IP address is 172.16.21.17 Filename 'uImage-lil'. Load address: 0x8200 Loading: # # # # # # # # # # # 2.8 MiB/s done Bytes transferred = 3841635 (3a9e63 hex) ## Booting kernel from Legacy Image at 8200 ... Image Name: next-20130417-38-g03de9e2 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3841571 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.9.0-rc7-next-20130417-00038-g03de9e2 (honschu@mars) (gcc version 4.4.5 (Debian 4.4.5-8) ) #374 PREEMPT Thu Apr 18 22:18:15 CEST 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP3 (Flattened Device Tree), model: INCOstartec LILLY-DBB056 (DM3730) [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] OMAP3630 ES1.2 (l2cache iva neon isp 192mhz_clk ) [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [0.00] Kernel command line: console=ttyO0,115200n8 vt.global_cursor_default=0 consoleblank=0 root=/dev/nfs ip=dhcp [0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
Re: [PATCH] gpio/omap: ensure gpio context is initialised
Hi Jon,
Jon Hunter jon-hun...@ti.com writes:
Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.
This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.
Nevertheless we should ensure that the gpio context is initialised
during the probe for gpio banks that could lose their state regardless
of whether we are booting with device-tree or not.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Tested-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/gpio-omap.c | 53
+-
1 file changed, 43 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..0ba5cb9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
bool is_mpuio;
bool dbck_flag;
bool loses_context;
+ bool context_valid;
int stride;
u32 width;
int context_loss_count;
@@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
}
static const struct of_device_id omap_gpio_match[];
+static void omap_gpio_init_context(struct gpio_bank *p);
static int omap_gpio_probe(struct platform_device *pdev)
{
@@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device
*pdev)
omap_gpio_chip_init(bank);
omap_gpio_show_rev(bank);
- if (bank-loses_context)
+ if (bank-loses_context) {
bank-get_context_loss_count = pdata-get_context_loss_count;
+ omap_gpio_init_context(bank);
+ }
pm_runtime_put(bank-dev);
@@ -1269,6 +1273,14 @@ static int omap_gpio_runtime_resume(struct device *dev)
int c;
spin_lock_irqsave(bank-lock, flags);
+
+ /*
+ * On the first resume during the probe, the context has not
+ * been initialised and so if the context is not valid return.
+ */
+ if (!bank-context_valid)
+ goto done;
Not sure I follow the reason to separate it here and in probe.
Also, this makes the first runtime_resume a special case and leaves
things in a strange semi-initialized state that is confusing IMO.
Why not just init context right here if bank-loses_context
!bank-context_valid?
Then the first resume can continue as expected, and everything is fully
initialized as expected also. IMO, this is much more readable (and
maintainable, but that's your job now, so you can decide ;)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] driver: serial: omap: add prepare/complete callback for no_console_suspend case
Sourav Poddar sourav.pod...@ti.com writes:
Hi Kevin,
On Thursday 18 April 2013 11:26 PM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
The patch adapt the serial core/driver to take care of the case when
no_console_suspend
is used in the bootargs. The patch will remove dependency to set od-flags
to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND in serial.c(non dt case) and
omap_device.c(dt case).
Prepare and complete callbacks will ensure that clocks remain active for
the console
uart when no_console_suspend is used in the bootargs.
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
This changelog needs a rework. The driver itself was not aware of
od-flags and omap_device stuff in general, so it's not really
relevant. The driver is also not directly managing clocks, int's only
doing runtime PM callbacks.
What you want to say in the changelog is that the driver manages
no_console_suspend by preventing runtime PM during the suspend path,
which forces the console UART to stay awake.
Yes, looks to the point. Will update the changelog in the next version.
---
drivers/tty/serial/omap-serial.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 08332f3..9ef80cf 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1278,6 +1278,24 @@ static struct uart_driver serial_omap_reg = {
};
#ifdef CONFIG_PM_SLEEP
+static int serial_omap_prepare(struct device *dev)
+{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+
+ if (!console_suspend_enabled uart_console(up-port))
+ pm_runtime_disable(dev);
+
+ return 0;
+}
+
+static void serial_omap_complete(struct device *dev)
+{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+
+ if (!console_suspend_enabled uart_console(up-port))
+ pm_runtime_enable(dev);
+}
+
For compilation with !CONFIG_PM_SLEEP, you'll also need:
#else
#define serial_omap_prepare NULL
#define serial_omap_prepare NULL
#endif /* CONFIG_PM_SLEEP */
Ok. Will change this.
Though, just a query/proposal on this, will it be correct if we try to
create a macro[1]
in include/linux/pm.h for prepare/complete as it is done for
suspend/resume. ?
Sure, you could do that, but personally I don't think it's as broadly
useful (otherwise, it would be there already.)
Kevin
[1]:
#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_PREP_COMP_OPS(prepare_fn, complete_fn) \
.prepare = prepare_fn, \
.complete = complete_fn, \
#else
#define SET_SYSTEM_SLEEP_PM_PREP_COMP_OPS(prepare_fn, complete_fn)
#endif
~Sourav
static int serial_omap_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
@@ -1632,6 +1650,8 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops
= {
SET_SYSTEM_SLEEP_PM_OPS(serial_omap_suspend, serial_omap_resume)
SET_RUNTIME_PM_OPS(serial_omap_runtime_suspend,
serial_omap_runtime_resume, NULL)
+ .prepare= serial_omap_prepare,
+ .complete = serial_omap_complete,
};
#if defined(CONFIG_OF)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] arm: mach-omap2: remove OMAP_DEVICE_NO_IDLE_ON_SUSPEND check
Sourav Poddar sourav.pod...@ti.com writes:
On Thursday 18 April 2013 11:35 PM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
Remove the OMAP_DEVICE_NO_IDLE_ON_SUSPEND check, since UART was the only
one making
use of it. Now serial core/driver takes care of the case when
no_console_suspend
is used in the bootargs and you need to keep the clock enable for console
even while suspend.
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
NAK. This patch will break many things...
---
arch/arm/mach-omap2/omap_device.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 381be7a..d6dce8f 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -620,11 +620,8 @@ static int _od_suspend_noirq(struct device *dev)
ret = pm_generic_suspend_noirq(dev);
if (!ret !pm_runtime_status_suspended(dev)) {
- if (pm_generic_runtime_suspend(dev) == 0) {
- if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
- omap_device_idle(pdev);
Why did you remove the omap_device_idle() here?
This patch is used along with patch3 to get rid of the issue. I posted
them as a
seperate patch beacuse of the subject line as one goes under drivers/*
and the other
arm/mach-omap2/*..
This check was only valid for UART, and if od-flags is set to the
OMAP_DEVICE_NO_IDLE_ON_SUSPEND flag, then UART will not be idled.
correct, but *every other device* would be idled (if not already idle.)
But now, we no longer depend on od-flag value to prevent idling of
our console UART as the prepare/complete apis will take care of them.
Right, so removing the check on od-flags is fine, but what I asked
about is why you removed the omap_device_idle() call.
Remember that this code is called for *every* omap_device during
suspend, not just UART.
What you did stops *every* device from being idled during suspend.
You didn't read my whole message. Specifically this part:
Note that the check is for when the flag is *not* set, so this patch
changes behavior for all the drivers that do not use
_NO_IDLE_ON_SUSPEND. I think that's the opposite of what you intended.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: dts: omap3: NAND support - how?
On 04/18/2013 03:23 PM, Christoph Fritz wrote: Hi Jon On Thu, 2013-04-18 at 14:39 -0500, Jon Hunter wrote: On 04/18/2013 02:03 PM, Christoph Fritz wrote: I had put the complete size in here so ... + reg = 0 0 0x100; Thanks. + nand-bus-width = 16; + ti,nand-ecc-opt = bch8; + /* no elm on omap3 */ + + gpmc,time-para-granularity = 0; This is a boolean parameter so you don't need the = 0. When I want to disable this boolean I thought I need to add the 0 (or not defining at all) otherwise a single gpmc,time-para-granularity would be interpreted as enabled. If you don't want to enable it, just don't define it at all. The code just checks for the presence of this property, so defining it as zero means you will enable it. + gpmc,mux-add-data = 0; This should be either 1 or 2. In arch/arm/mach-omap2/gpmc.h it gets set by this: #define GPMC_CONFIG1_MUXTYPE(val) ((val 3) 8) but the TRM for AM/DM37x as well as the TRM for Omap35x says: |9 MUXADDDATA Enables the Address and data multiplexed protocol (Reset RW 0x- | value is CS0MUXDEVICE input pin sampled at IC reset for | CS0 and 0 for CS1-7) | 0x0: Non Multiplexed attached device | 0x1: Address and data multiplexed attached device From u-boot I got 0x1800 for register GPMC_CONFIG1. So Bit 9 is 0. Why should I set it here to non zero? It should be either 1 or 2, or you should not define it. So if the bit is zero from the u-boot configuration, just leave it out this property. Setting to 0 is probably ok if you don't want to have address-data multiplexing, but it is also pointless. + gpmc,device-nand = 1; This is a boolean parameter so you don't need the = 0. The nand here is attached by 16 lines. So I'm pretty sure I need the 1 or at least gpmc,device-nand; don't I? This is a boolean property. You should just have gpmc,device-nand. + + #address-cells = 1; /* - ? not sure about that */ + #size-cells = 1; /* - ? not sure about that */ This is just needed in case you wish to list partition info. Seeing as you don't you can omit. Thanks. Can you include the complete boot log? I am wondering if there were any errors seen during the gpmc probe. U-Boot SPL 2013.04-rc2-08894-g33f264f-dirty (Apr 17 2013 - 23:00:59) U-Boot 2013.04-rc2-08894-g33f264f-dirty (Apr 17 2013 - 23:00:59) OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 128 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 In:serial Out: serial Err: serial Read back SMSC id 0x9221 Die ID #017200029e3801683b051201102a Net: smc911x-0 Hit any key to stop autoboot: 0 OMAP3_EVM # md 0x6E60 7 6e60: 1800 00141400 00141400 0f010f01 6e70: 010c1414 1f0f0a80 0870 p... OMAP3_EVM # boot smc911x: detected LAN9221 controller smc911x: phy initialized smc911x: MAC 00:50:c2:0d:6a:63 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 172.16.21.17 Using smc911x-0 device TFTP from server 172.16.21.1; our IP address is 172.16.21.17 Filename 'uImage-lil'. Load address: 0x8200 Loading: # # # # # # # # # # # 2.8 MiB/s done Bytes transferred = 3841635 (3a9e63 hex) ## Booting kernel from Legacy Image at 8200 ... Image Name: next-20130417-38-g03de9e2 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3841571 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.9.0-rc7-next-20130417-00038-g03de9e2 (honschu@mars) (gcc version 4.4.5 (Debian 4.4.5-8) ) #374 PREEMPT Thu Apr 18 22:18:15 CEST 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing
Re: [RFC PATCH v2 1/4] retu-mfd: support also Tahvo
Hi Aaro, On Tue, Apr 09, 2013 at 10:51:25PM +0300, Aaro Koskinen wrote: Tahvo is a multi-function device on Nokia 770, implementing USB transceiver and charge/battery control. It's so close to Retu that a single driver can support both. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/Kconfig |6 ++-- drivers/mfd/retu-mfd.c | 85 -- include/linux/mfd/retu.h |8 - 3 files changed, 85 insertions(+), 14 deletions(-) Simple and good enough, I applied this one. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: dts: omap3: NAND support - how?
On Thu, 2013-04-18 at 17:28 -0500, Jon Hunter wrote: On 04/18/2013 03:23 PM, Christoph Fritz wrote: OMAP3_EVM # md 0x6E60 7 6e60: 1800 00141400 00141400 0f010f01 6e70: 010c1414 1f0f0a80 0870 p... I don't see any other errors in the log. So I am wondering if the chip-select mapping is setup correctly. Can you share a dump of the gpmc registers from u-boot? I already did, please see the md 0x6E60 7 from above. Below is my work-sheet how I configured the values: --- To get the values right for dt-GPMC-NAND-Config, here are the GPMC config registers for chip-select 0, they are taken from u-boot by doing md 0x6E60 7 on the u-boot shell: GPMC_CONFIG1: 0x6e60: 0x1800 GPMC_CONFIG2: 0x6e64: 0x00141400 GPMC_CONFIG3: 0x6e68: 0x00141400 GPMC_CONFIG4: 0x6e6c: 0x0F010F01 GPMC_CONFIG5: 0x6e70: 0x010C1414 GPMC_CONFIG6: 0x6e74: 0x1F0F0A80 GPMC_CONFIG7: 0x6e78: 0x0870 and analyzed by datasheet (TRM page 2210): GPMC_CONFIG7 0x0870: |11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0| | 1| 0| 0| 0| 0| 1| 1| 1| 0| 0| 0| 0| 5:0 BASEADDR: 0x4 (reg addr: 0x3000) dT: not supported CSi base address 6CSVALID: 1 dT: not supported CS enable 11:8 MASKADDRESS: 0x1000: Chip-select size of 128 Mbytes dT: not supported CS mask address GPMC_CONFIG6 0x1F0F0A80: |31|30|29|28|27|26|25|24|23|22|21|20|19|18|17|16| | 0| 0| 0| 1| 1| 1| 1| 1| 0| 0| 0| 0| 1| 1| 1| 1| |15|14|13|12|11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0| | 0| 0| 0| 0| 1| 0| 1| 0| 1| 0| 0| 0| 0| 0| 0| 0| 28:24 WRACCESSTIME: 0x1F: 31 GPMC_FCLK cycles dT: gpmc,wr-access-ns = 0x1F; (0x0 to 0x1F) used by the attached memory for the first data capture 19:16 WRDATAONADMUXBUS: 0xF dT: gpmc,wr-data-mux-bus-ns = 0xF; (0x0 to 0xF) Specifies on which GPMC_FCLK rising edge the first data is driven in the add/data mux bus 11:8 CYCLE2CYCLEDELAY: 0xA GPMC_FCLK cycles dT: gpmc,cycle2cycle-delay-ns = 0xA; (0x0 to 0xF) Chip-select high pulse delay between successive accesses 7 CYCLE2CYCLESAMECSEN: 0x1: Add CYCLE2CYCLEDELAY dT: gpmc,cycle2cycle-samecsen = 0x1; (bool) Add CYCLE2CYCLEDELAY between successive accesses to the same CS (any access type) 6 CYCLE2CYCLEDIFFCSEN: 0x0: No delay between the two accesses dT: gpmc,cycle2cycle-diffcsen = 0x0; (bool) Add CYCLE2CYCLEDELAY between successive accesses to a different CS (any access type) 3:0 BUSTURNAROUND: 0x0: 0 GPMC_FCLK cycle dT: gpmc,bus-turnaround-ns = 0x0; (0x0 to 0xF) Bus turn around latency between successive accesses to the same CS (read to write) or to a different CS (read to read and read to write) GPMC_CONFIG5 0x010C1414: |31|30|29|28|27|26|25|24|23|22|21|20|19|18|17|16| | 0| 0| 0| 0| 0| 0| 0| 1| 0| 0| 0| 0| 1| 1| 0| 0| |15|14|13|12|11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0| | 0| 0| 0| 1| 0| 1| 0| 0| 0| 0| 0| 1| 0| 1| 0| 0| 27:24 PAGEBURSTACCESSTIME: 0x1: 1 GPMC_FCLK cycle dT: gpmc,page-burst-access-ns = 0x1; (0x0 to 0xF) Delay between successive words in a multiple access 20:16 RDACCESSTIME: 0xC: 12 GPMC_FCLK cycles dT: gpmc,access-ns = 0xC; (0x0 to 0x1F) Delay between start cycle time and first data valid 12:8 WRCYCLETIME: 0x14: 20 GPMC_FCLK cycles dT: gpmc,wr-cycle-ns = 0x14; (0x0 to 0x1F) Total write cycle time 4:0 RDCYCLETIME: 0x14: 20 GPMC_FCLK cycles dT: gpmc,rd-cycle-ns = 0x14; (0x0 to 0x1F) Total read cycle time GPMC_CONFIG4 0x0F010F01: |31|30|29|28|27|26|25|24|23|22|21|20|19|18|17|16| | 0| 0| 0| 0| 1| 1| 1| 1| 0| 0| 0| 0| 0| 0| 0| 1| |15|14|13|12|11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0| | 0| 0| 0| 0| 1| 1| 1| 1| 0| 0| 0| 0| 0| 0| 0| 1| 28:24 WEOFFTIME: 0xF: 16 GPMC_FCLK cycle dT: gpmc,we-off-ns = 0xF; (0x0 to 0x1F) nWE de-assertion time from start cycle time 23WEEXTRADELAY: 0x0: nWE Timing control signal is not delayed dT: gpmc,we-extra-delay = 0; (bool) nWE Add Extra Half GPMC_FCLK cycle 19:16 WEONTIME: 0x1: 1 GPMC_FCLK cycle dT: gpmc,we-on-ns = 0x1; (0x0 to 0x1F) nWE assertion time from start cycle time 12:8 OEOFFTIME: 0xF: 15 GPMC_FCLK cycles dT: gpmc,oe-off-ns = 0xF; (0x0 to 0x1F) nOE de-assertion
Re: [PATCH] gpio/omap: ensure gpio context is initialised
Hi Kevin,
On 04/18/2013 04:34 PM, Kevin Hilman wrote:
Hi Jon,
Jon Hunter jon-hun...@ti.com writes:
Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.
This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.
Nevertheless we should ensure that the gpio context is initialised
during the probe for gpio banks that could lose their state regardless
of whether we are booting with device-tree or not.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Tested-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/gpio-omap.c | 53
+-
1 file changed, 43 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..0ba5cb9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
bool is_mpuio;
bool dbck_flag;
bool loses_context;
+bool context_valid;
int stride;
u32 width;
int context_loss_count;
@@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
}
static const struct of_device_id omap_gpio_match[];
+static void omap_gpio_init_context(struct gpio_bank *p);
static int omap_gpio_probe(struct platform_device *pdev)
{
@@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device
*pdev)
omap_gpio_chip_init(bank);
omap_gpio_show_rev(bank);
-if (bank-loses_context)
+if (bank-loses_context) {
bank-get_context_loss_count = pdata-get_context_loss_count;
+omap_gpio_init_context(bank);
+}
pm_runtime_put(bank-dev);
@@ -1269,6 +1273,14 @@ static int omap_gpio_runtime_resume(struct device
*dev)
int c;
spin_lock_irqsave(bank-lock, flags);
+
+/*
+ * On the first resume during the probe, the context has not
+ * been initialised and so if the context is not valid return.
+ */
+if (!bank-context_valid)
+goto done;
Not sure I follow the reason to separate it here and in probe.
Also, this makes the first runtime_resume a special case and leaves
things in a strange semi-initialized state that is confusing IMO.
The first resume has always been a special case. The
bank-get_context_loss_count is not initialised until after the first
resume (due to another issue we had found - 7b86cef gpio/omap: fix
invalid context restore of gpio bank-0). This should not leave things in
a strange semi-init'ed state, as on the first resume nothing is really
done anyway because there is no context loss.
Why not just init context right here if bank-loses_context
!bank-context_valid?
Thanks for the suggestion.
Then the first resume can continue as expected, and everything is fully
initialized as expected also. IMO, this is much more readable (and
maintainable, but that's your job now, so you can decide ;)
If the context has not been lost, which it has not on the first resume,
then resume really does nothing. That's why I had just returned.
However, I would agree that is not completely readable.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: dts: omap3: NAND support - how?
On 04/18/2013 05:48 PM, Christoph Fritz wrote: On Thu, 2013-04-18 at 17:28 -0500, Jon Hunter wrote: On 04/18/2013 03:23 PM, Christoph Fritz wrote: OMAP3_EVM # md 0x6E60 7 6e60: 1800 00141400 00141400 0f010f01 6e70: 010c1414 1f0f0a80 0870 p... I don't see any other errors in the log. So I am wondering if the chip-select mapping is setup correctly. Can you share a dump of the gpmc registers from u-boot? I already did, please see the md 0x6E60 7 from above. Below is my work-sheet how I configured the values: Sorry I missed that. --- To get the values right for dt-GPMC-NAND-Config, here are the GPMC config registers for chip-select 0, they are taken from u-boot by doing md 0x6E60 7 on the u-boot shell: GPMC_CONFIG1: 0x6e60: 0x1800 GPMC_CONFIG2: 0x6e64: 0x00141400 GPMC_CONFIG3: 0x6e68: 0x00141400 GPMC_CONFIG4: 0x6e6c: 0x0F010F01 GPMC_CONFIG5: 0x6e70: 0x010C1414 GPMC_CONFIG6: 0x6e74: 0x1F0F0A80 GPMC_CONFIG7: 0x6e78: 0x0870 and analyzed by datasheet (TRM page 2210): GPMC_CONFIG7 0x0870: |11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0| | 1| 0| 0| 0| 0| 1| 1| 1| 0| 0| 0| 0| 5:0 BASEADDR: 0x4 (reg addr: 0x3000) Base address looks fine. dT: not supported CSi base address 6CSVALID: 1 dT: not supported CS enable 11:8 MASKADDRESS: 0x1000: Chip-select size of 128 Mbytes dT: not supported CS mask address GPMC_CONFIG6 0x1F0F0A80: |31|30|29|28|27|26|25|24|23|22|21|20|19|18|17|16| | 0| 0| 0| 1| 1| 1| 1| 1| 0| 0| 0| 0| 1| 1| 1| 1| |15|14|13|12|11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0| | 0| 0| 0| 0| 1| 0| 1| 0| 1| 0| 0| 0| 0| 0| 0| 0| 28:24 WRACCESSTIME: 0x1F: 31 GPMC_FCLK cycles dT: gpmc,wr-access-ns = 0x1F; (0x0 to 0x1F) used by the attached memory for the first data capture 19:16 WRDATAONADMUXBUS: 0xF dT: gpmc,wr-data-mux-bus-ns = 0xF; (0x0 to 0xF) Specifies on which GPMC_FCLK rising edge the first data is driven in the add/data mux bus 11:8 CYCLE2CYCLEDELAY: 0xA GPMC_FCLK cycles dT: gpmc,cycle2cycle-delay-ns = 0xA; (0x0 to 0xF) Chip-select high pulse delay between successive accesses 7 CYCLE2CYCLESAMECSEN: 0x1: Add CYCLE2CYCLEDELAY dT: gpmc,cycle2cycle-samecsen = 0x1; (bool) Add CYCLE2CYCLEDELAY between successive accesses to the same CS (any access type) 6 CYCLE2CYCLEDIFFCSEN: 0x0: No delay between the two accesses dT: gpmc,cycle2cycle-diffcsen = 0x0; (bool) Add CYCLE2CYCLEDELAY between successive accesses to a different CS (any access type) 3:0 BUSTURNAROUND: 0x0: 0 GPMC_FCLK cycle dT: gpmc,bus-turnaround-ns = 0x0; (0x0 to 0xF) Bus turn around latency between successive accesses to the same CS (read to write) or to a different CS (read to read and read to write) GPMC_CONFIG5 0x010C1414: |31|30|29|28|27|26|25|24|23|22|21|20|19|18|17|16| | 0| 0| 0| 0| 0| 0| 0| 1| 0| 0| 0| 0| 1| 1| 0| 0| |15|14|13|12|11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0| | 0| 0| 0| 1| 0| 1| 0| 0| 0| 0| 0| 1| 0| 1| 0| 0| 27:24 PAGEBURSTACCESSTIME: 0x1: 1 GPMC_FCLK cycle dT: gpmc,page-burst-access-ns = 0x1; (0x0 to 0xF) Delay between successive words in a multiple access 20:16 RDACCESSTIME: 0xC: 12 GPMC_FCLK cycles dT: gpmc,access-ns = 0xC; (0x0 to 0x1F) Delay between start cycle time and first data valid 12:8 WRCYCLETIME: 0x14: 20 GPMC_FCLK cycles dT: gpmc,wr-cycle-ns = 0x14; (0x0 to 0x1F) Total write cycle time 4:0 RDCYCLETIME: 0x14: 20 GPMC_FCLK cycles dT: gpmc,rd-cycle-ns = 0x14; (0x0 to 0x1F) Total read cycle time GPMC_CONFIG4 0x0F010F01: |31|30|29|28|27|26|25|24|23|22|21|20|19|18|17|16| | 0| 0| 0| 0| 1| 1| 1| 1| 0| 0| 0| 0| 0| 0| 0| 1| |15|14|13|12|11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0| | 0| 0| 0| 0| 1| 1| 1| 1| 0| 0| 0| 0| 0| 0| 0| 1| 28:24 WEOFFTIME: 0xF: 16 GPMC_FCLK cycle dT: gpmc,we-off-ns = 0xF; (0x0 to 0x1F) nWE de-assertion time from start cycle time 23WEEXTRADELAY: 0x0: nWE Timing control signal is not delayed dT: gpmc,we-extra-delay = 0; (bool) You should omit this property, the above will enable it as it is a boolean property. nWE Add Extra Half GPMC_FCLK cycle 19:16 WEONTIME: 0x1: 1 GPMC_FCLK cycle dT: gpmc,we-on-ns = 0x1; (0x0 to 0x1F) nWE assertion time from
Re: ARM: dts: omap3: NAND support - how?
On 04/18/2013 06:24 PM, Jon Hunter wrote: On 04/18/2013 05:48 PM, Christoph Fritz wrote: On Thu, 2013-04-18 at 17:28 -0500, Jon Hunter wrote: On 04/18/2013 03:23 PM, Christoph Fritz wrote: OMAP3_EVM # md 0x6E60 7 6e60: 1800 00141400 00141400 0f010f01 6e70: 010c1414 1f0f0a80 0870 p... I don't see any other errors in the log. So I am wondering if the chip-select mapping is setup correctly. Can you share a dump of the gpmc registers from u-boot? I already did, please see the md 0x6E60 7 from above. Below is my work-sheet how I configured the values: Sorry I missed that. --- To get the values right for dt-GPMC-NAND-Config, here are the GPMC config registers for chip-select 0, they are taken from u-boot by doing md 0x6E60 7 on the u-boot shell: GPMC_CONFIG1: 0x6e60: 0x1800 GPMC_CONFIG2: 0x6e64: 0x00141400 GPMC_CONFIG3: 0x6e68: 0x00141400 GPMC_CONFIG4: 0x6e6c: 0x0F010F01 GPMC_CONFIG5: 0x6e70: 0x010C1414 GPMC_CONFIG6: 0x6e74: 0x1F0F0A80 GPMC_CONFIG7: 0x6e78: 0x0870 I would advise you dump the gpmc registers at the end of the gpmc probe. I am sure you will see something completely different to the above based upon your dt configuration. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/omap: ensure gpio context is initialised
On 04/18/2013 06:10 PM, Jon Hunter wrote:
On 04/18/2013 04:34 PM, Kevin Hilman wrote:
...
Why not just init context right here if bank-loses_context
!bank-context_valid?
I really like this idea a lot. It can really clean-up the code
and really make it much more readable. Before we were playing
some tricks with when we init'ed the get_context_loss_count()
function pointer. How about the below?
Tony, care to re-test?
Cheers
Jon
From d7a940531d354e6be5e16ee50fa8344041df963a Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Mon, 15 Apr 2013 13:06:54 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.
This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.
Nevertheless we should ensure that the gpio context is initialised
on the first pm-runtime resume for gpio banks that could lose their
state regardless of whether we are booting with device-tree or not.
The context loss count was being initialised on the first pm-runtime
suspend following a resume, by populating the get_count_loss_count()
function pointer after the first pm-runtime resume. To make the code
more readable and logical, initialise the context loss count on the
first pm-runtime resume if the context is not yet valid.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/gpio/gpio-omap.c | 45 ++---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..db3c732 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
bool is_mpuio;
bool dbck_flag;
bool loses_context;
+ bool context_valid;
int stride;
u32 width;
int context_loss_count;
@@ -1129,6 +1130,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
bank-loses_context = true;
} else {
bank-loses_context = pdata-loses_context;
+ bank-get_context_loss_count = pdata-get_context_loss_count;
}
@@ -1179,9 +1181,6 @@ static int omap_gpio_probe(struct platform_device *pdev)
omap_gpio_chip_init(bank);
omap_gpio_show_rev(bank);
- if (bank-loses_context)
- bank-get_context_loss_count = pdata-get_context_loss_count;
-
pm_runtime_put(bank-dev);
list_add_tail(bank-node, omap_gpio_list);
@@ -1260,6 +1259,8 @@ update_gpio_context_count:
return 0;
}
+static void omap_gpio_init_context(struct gpio_bank *p);
+
static int omap_gpio_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -1269,6 +1270,20 @@ static int omap_gpio_runtime_resume(struct device *dev)
int c;
spin_lock_irqsave(bank-lock, flags);
+
+ /*
+* On the first resume during the probe, the context has not
+* been initialised and so initialise it now. Also initialise
+* the context loss count.
+*/
+ if (bank-loses_context !bank-context_valid) {
+ omap_gpio_init_context(bank);
+
+ if (bank-get_context_loss_count)
+ bank-context_loss_count =
+ bank-get_context_loss_count(bank-dev);
+ }
+
_gpio_dbck_enable(bank);
/*
@@ -1385,6 +1400,29 @@ void omap2_gpio_resume_after_idle(void)
}
#if defined(CONFIG_PM_RUNTIME)
+static void omap_gpio_init_context(struct gpio_bank *p)
+{
+ struct omap_gpio_reg_offs *regs = p-regs;
+ void __iomem *base = p-base;
+
+ p-context.ctrl = __raw_readl(base + regs-ctrl);
+ p-context.oe = __raw_readl(base + regs-direction);
+ p-context.wake_en = __raw_readl(base + regs-wkup_en);
+ p-context.leveldetect0 = __raw_readl(base + regs-leveldetect0);
+ p-context.leveldetect1 = __raw_readl(base + regs-leveldetect1);
+ p-context.risingdetect = __raw_readl(base + regs-risingdetect);
+ p-context.fallingdetect = __raw_readl(base + regs-fallingdetect);
+ p-context.irqenable1 = __raw_readl(base + regs-irqenable);
+ p-context.irqenable2 = __raw_readl(base + regs-irqenable2);
+
+ if (regs-set_dataout p-regs-clr_dataout)
+ p-context.dataout = __raw_readl(base + regs-set_dataout);
+ else
+ p-context.dataout = __raw_readl(base + regs-dataout);
+
+ p-context_valid = true;
+}
+
static void
Re: [PATCH] gpio/omap: ensure gpio context is initialised
On 04/18/2013 07:34 PM, Jon Hunter wrote:
On 04/18/2013 06:10 PM, Jon Hunter wrote:
On 04/18/2013 04:34 PM, Kevin Hilman wrote:
...
Why not just init context right here if bank-loses_context
!bank-context_valid?
I really like this idea a lot. It can really clean-up the code
and really make it much more readable. Before we were playing
some tricks with when we init'ed the get_context_loss_count()
function pointer. How about the below?
Tony, care to re-test?
Cheers
Jon
From d7a940531d354e6be5e16ee50fa8344041df963a Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Mon, 15 Apr 2013 13:06:54 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.
This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.
Nevertheless we should ensure that the gpio context is initialised
on the first pm-runtime resume for gpio banks that could lose their
state regardless of whether we are booting with device-tree or not.
The context loss count was being initialised on the first pm-runtime
suspend following a resume, by populating the get_count_loss_count()
function pointer after the first pm-runtime resume. To make the code
more readable and logical, initialise the context loss count on the
first pm-runtime resume if the context is not yet valid.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/gpio/gpio-omap.c | 45 ++---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..db3c732 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
bool is_mpuio;
bool dbck_flag;
bool loses_context;
+ bool context_valid;
int stride;
u32 width;
int context_loss_count;
@@ -1129,6 +1130,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
bank-loses_context = true;
} else {
bank-loses_context = pdata-loses_context;
+ bank-get_context_loss_count = pdata-get_context_loss_count;
Still need to check loses_context for populating
get_context_loss_count here. Updated patch below.
Jon
From d02ef7b7dfcf8e13bf019aedfdecb38ca3c6749f Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Mon, 15 Apr 2013 13:06:54 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.
This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.
Nevertheless we should ensure that the gpio context is initialised
on the first pm-runtime resume for gpio banks that could lose their
state regardless of whether we are booting with device-tree or not.
The context loss count was being initialised on the first pm-runtime
suspend following a resume, by populating the get_count_loss_count()
function pointer after the first pm-runtime resume. To make the code
more readable and logical, initialise the context loss count on the
first pm-runtime resume if the context is not yet valid.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/gpio/gpio-omap.c | 48 +++---
1 file changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..c3c3ffe 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
bool is_mpuio;
bool dbck_flag;
bool loses_context;
+ bool context_valid;
int stride;
u32 width;
int context_loss_count;
@@ -1129,6 +1130,10 @@ static int omap_gpio_probe(struct platform_device *pdev)
bank-loses_context = true;
} else {
bank-loses_context = pdata-loses_context;
+
+ if (bank-loses_context)
+ bank-get_context_loss_count =
+ pdata-get_context_loss_count;
}
@@
