Re: Issue with _are_all_hardreset_lines_asserted()
Hi,
On Tuesday 09 October 2012 11:08 AM, Paul Walmsley wrote:
cc Vaibhav due to the AM33xx change
Hi
On Thu, 4 Oct 2012, Archit Taneja wrote:
I was trying out the linux-next kernel, and I noticed that DSS MODULEMODE bits
are never cleared.
In _omap4_disable_module(), there is a check:
...
if (!_are_all_hardreset_lines_asserted(oh))
return 0;
/* MODULEMODE bits cleared here */
...
...
...
The function _are_all_hardreset_lines_asserted() returns false if
'oh->rst_lines_cnt == 0', so we bail out from _omap4_disable_module() before
clearing the MODULEMODE bits.
Is this correct behavior? This would prevent all hwmods who have rst_lines_cnt
as 0 to not get their MODULEMODE bits cleared.
You're right, that looks bogus. What do you think about the following
patch?
The patch looks fine to me. I tried it out for DSS(with an additional
patch to not represent DSS modulemode bits as a slave clock), and
modulemode is getting disabled correctly now.
Thanks,
Archit
- Paul
From: Paul Walmsley
Date: Mon, 8 Oct 2012 23:08:15 -0600
Subject: [PATCH] ARM: OMAP4/AM335x: hwmod: fix disable_module regression in
hardreset handling
Commit eb05f691290e99ee0bd1672317d6add789523c1e ("ARM: OMAP: hwmod:
partially un-reset hwmods might not be properly enabled") added code
to skip the IP block disable sequence if any hardreset lines were left
unasserted. But this did not handle the case when no hardreset lines
were associated with a module, which is the general case. In that
situation, the IP block would be skipped, which is likely to cause PM
regressions.
So, modify _omap4_disable_module() and _am33xx_disable_module() to
only bail out early if there are any hardreset lines asserted. And
move the AM33xx test above the actual module disable code to ensure
that the behavior is consistent.
Reported-by: Archit Taneja
Cc: Omar Ramirez Luna
Cc: Vaibhav Hiremath
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 299ca28..b969ab1 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1698,6 +1698,29 @@ static bool _are_all_hardreset_lines_asserted(struct
omap_hwmod *oh)
}
/**
+ * _are_any_hardreset_lines_asserted - return true if any part of @oh is
+ * hard-reset
+ * @oh: struct omap_hwmod *
+ *
+ * If any hardreset lines associated with @oh are asserted, then
+ * return true. Otherwise, if no hardreset lines associated with @oh
+ * are asserted, or if @oh has no hardreset lines, then return false.
+ * This function is used to avoid executing some parts of the IP block
+ * enable/disable sequence if any hardreset line is set.
+ */
+static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh)
+{
+ int rst_cnt = 0;
+ int i;
+
+ for (i = 0; i < oh->rst_lines_cnt && rst_cnt == 0; i++)
+ if (_read_hardreset(oh, oh->rst_lines[i].name) > 0)
+ rst_cnt++;
+
+ return (rst_cnt) ? true : false;
+}
+
+/**
* _omap4_disable_module - enable CLKCTRL modulemode on OMAP4
* @oh: struct omap_hwmod *
*
@@ -1715,7 +1738,7 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
* Since integration code might still be doing something, only
* disable if all lines are under hardreset.
*/
- if (!_are_all_hardreset_lines_asserted(oh))
+ if (_are_any_hardreset_lines_asserted(oh))
return 0;
pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__);
@@ -1749,12 +1772,12 @@ static int _am33xx_disable_module(struct omap_hwmod *oh)
pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__);
+ if (_are_any_hardreset_lines_asserted(oh))
+ return 0;
+
am33xx_cm_module_disable(oh->clkdm->cm_inst, oh->clkdm->clkdm_offs,
oh->prcm.omap4.clkctrl_offs);
- if (_are_all_hardreset_lines_asserted(oh))
- return 0;
-
v = _am33xx_wait_target_disable(oh);
if (v)
pr_warn("omap_hwmod: %s: _wait_target_disable failed\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
On Mon, 08 Oct 2012 10:35:57 -0700 Tony Lindgren wrote: > - omap-dma.c and omap-pcm.c can test the arch locally as > omap1 and omap2 cannot be compiled together because of > conflicting compiler flags ... > sound/soc/omap/omap-pcm.c |9 +++-- Build tested above for omap1 and omap2+. Acked-by: Jarkko Nikula -- 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 2/3] omap3isp: Add PHY routing configuration
Hi, Laurent!
Thanks for the comments!
On Tue, Oct 09, 2012 at 02:17:48AM +0200, Laurent Pinchart wrote:
...
> > @@ -32,6 +32,92 @@
> > #include "ispreg.h"
> > #include "ispcsiphy.h"
> >
> > +static void csiphy_routing_cfg_3630(struct isp_csiphy *phy, u32 iface,
> > + bool ccp2_strobe)
> > +{
> > + u32 cam_phy_ctrl =
>
> If you call the variable "value" or "ctrl" two statements below could fit on
> one line, but that's up to you :-)
I'll call it "reg". :)
> > + isp_reg_readl(phy->isp,
> > + OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
> > + u32 shift, mode;
> > +
> > + switch (iface) {
> > + case ISP_INTERFACE_CCP2B_PHY1:
> > + cam_phy_ctrl &=
> > + ~OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
> > + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
> > + break;
> > + case ISP_INTERFACE_CSI2C_PHY1:
> > + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
> > + mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
> > + break;
> > + case ISP_INTERFACE_CCP2B_PHY2:
> > + cam_phy_ctrl |=
> > + OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
> > + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
> > + break;
> > + case ISP_INTERFACE_CSI2A_PHY2:
> > + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
> > + mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
> > + break;
> > + default:
> > + pr_warn("bad iface %d\n", iface);
>
> As you already know, dev_warn() is a better idea. Can this actually happen ?
I don't think so; it's checked in isp.c in isp_register_entities().. I'll
remove it.
Cheers.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 3/3] omap3isp: Configure CSI-2 phy based on platform data
Hi Laurent, Thanks for the comments. On Tue, Oct 09, 2012 at 02:33:28AM +0200, Laurent Pinchart wrote: ... > > @@ -248,10 +203,56 @@ static int csiphy_config(struct isp_csiphy *phy, > > if (lanes->clk.pos == 0 || used_lanes & (1 << lanes->clk.pos)) > > return -EINVAL; > > > > - mutex_lock(&phy->mutex); > > - phy->dphy = *dphy; > > - phy->lanes = *lanes; > > - mutex_unlock(&phy->mutex); > > + csiphy_routing_cfg(phy, subdevs->interface, true, > > + subdevs->bus.ccp2.phy_layer); > > As the second argument is always true, it could make sense to remove it (or > to > add another call to csiphy_routing_cfg with on set to false). That's a good point. In principle another call should be added for 3430 to turn the PHY off. That's not being done on the N900. I'll see where it could be added. Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: Issue with _are_all_hardreset_lines_asserted()
cc Vaibhav due to the AM33xx change
Hi
On Thu, 4 Oct 2012, Archit Taneja wrote:
> I was trying out the linux-next kernel, and I noticed that DSS MODULEMODE bits
> are never cleared.
>
> In _omap4_disable_module(), there is a check:
>
> ...
>
> if (!_are_all_hardreset_lines_asserted(oh))
> return 0;
>
> /* MODULEMODE bits cleared here */
> ...
> ...
> ...
>
> The function _are_all_hardreset_lines_asserted() returns false if
> 'oh->rst_lines_cnt == 0', so we bail out from _omap4_disable_module() before
> clearing the MODULEMODE bits.
>
> Is this correct behavior? This would prevent all hwmods who have rst_lines_cnt
> as 0 to not get their MODULEMODE bits cleared.
You're right, that looks bogus. What do you think about the following
patch?
- Paul
From: Paul Walmsley
Date: Mon, 8 Oct 2012 23:08:15 -0600
Subject: [PATCH] ARM: OMAP4/AM335x: hwmod: fix disable_module regression in
hardreset handling
Commit eb05f691290e99ee0bd1672317d6add789523c1e ("ARM: OMAP: hwmod:
partially un-reset hwmods might not be properly enabled") added code
to skip the IP block disable sequence if any hardreset lines were left
unasserted. But this did not handle the case when no hardreset lines
were associated with a module, which is the general case. In that
situation, the IP block would be skipped, which is likely to cause PM
regressions.
So, modify _omap4_disable_module() and _am33xx_disable_module() to
only bail out early if there are any hardreset lines asserted. And
move the AM33xx test above the actual module disable code to ensure
that the behavior is consistent.
Reported-by: Archit Taneja
Cc: Omar Ramirez Luna
Cc: Vaibhav Hiremath
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 299ca28..b969ab1 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1698,6 +1698,29 @@ static bool _are_all_hardreset_lines_asserted(struct
omap_hwmod *oh)
}
/**
+ * _are_any_hardreset_lines_asserted - return true if any part of @oh is
+ * hard-reset
+ * @oh: struct omap_hwmod *
+ *
+ * If any hardreset lines associated with @oh are asserted, then
+ * return true. Otherwise, if no hardreset lines associated with @oh
+ * are asserted, or if @oh has no hardreset lines, then return false.
+ * This function is used to avoid executing some parts of the IP block
+ * enable/disable sequence if any hardreset line is set.
+ */
+static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh)
+{
+ int rst_cnt = 0;
+ int i;
+
+ for (i = 0; i < oh->rst_lines_cnt && rst_cnt == 0; i++)
+ if (_read_hardreset(oh, oh->rst_lines[i].name) > 0)
+ rst_cnt++;
+
+ return (rst_cnt) ? true : false;
+}
+
+/**
* _omap4_disable_module - enable CLKCTRL modulemode on OMAP4
* @oh: struct omap_hwmod *
*
@@ -1715,7 +1738,7 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
* Since integration code might still be doing something, only
* disable if all lines are under hardreset.
*/
- if (!_are_all_hardreset_lines_asserted(oh))
+ if (_are_any_hardreset_lines_asserted(oh))
return 0;
pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__);
@@ -1749,12 +1772,12 @@ static int _am33xx_disable_module(struct omap_hwmod *oh)
pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__);
+ if (_are_any_hardreset_lines_asserted(oh))
+ return 0;
+
am33xx_cm_module_disable(oh->clkdm->cm_inst, oh->clkdm->clkdm_offs,
oh->prcm.omap4.clkctrl_offs);
- if (_are_all_hardreset_lines_asserted(oh))
- return 0;
-
v = _am33xx_wait_target_disable(oh);
if (v)
pr_warn("omap_hwmod: %s: _wait_target_disable failed\n",
--
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 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use
Hi Jon, On Mon, 8 Oct 2012, Jon Hunter wrote: > I was looking at what got merged and it appears that the above code was > added to the omap2 clkdm enable/disable functions and not omap3. I believe > that is a mistake? If so the below fixes this. Yep looks like either a mismerge or a victim of a rebase -- queued for late 3.7 fixes -- thanks, - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
* Afzal Mohammed [121005 09:02]: > > Proposed generic routine has been tested on OneNAND (async) on > OMAP3EVM rev C (as mainline does not have the OneNAND support for this, > local patch were used to test). For other cases of custom timing > calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing > calculation routine was verified by simulating on OMAP3EVM. Have you tested to make sure this works if you change the L3 frequency? That should probably be tested as a sanity check. Maybe you can force the L3 for some test boots for this, I don't think we scale it by default. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: move old debug-devices.c and debug-leds.c to be OMAP2+ only for now
On Mon, 8 Oct 2012, Tony Lindgren wrote:
> * Paul Walmsley [121007 18:48]:
> >
> > Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 ("ARM: OMAP: move
> > debug_card_init() function") results in the following new sparse[1]
> > warning:
> >
> > arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init'
> > was not declared. Should it be static?
> >
> > Normally this could be fixed by including the appropriate header file
> > in plat-omap/debug-devices.c, but the header file now exists only in
> > mach-omap2/, so this would require a "sideways include" and is thus
> > impractical. It turns out that only code in mach-omap2/ currently
> > uses the debug-devices.c and debug-leds.c files, so move them there.
> > In the long term, these devices should be created by DT, and the code
> > should be moved into drivers/ somewhere.
>
> Hmm are you sure that omap1 is not using debug-leds.c?
> At least the initcall seems like it should run on omap1
> if enabled.
Will drop this one for now until we figure out what to do about it.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] omap3isp: Configure CSI-2 phy based on platform data
On Sunday 07 October 2012 23:07:52 Sakari Ailus wrote:
> Configure CSI-2 phy based on platform data in the ISP driver. For that, the
> new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
> was configured from the board code.
>
> This patch is dependent on "omap3: Provide means for changing CSI2 PHY
> configuration".
>
> Signed-off-by: Sakari Ailus
> Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.h |3 -
> drivers/media/platform/omap3isp/ispcsiphy.c | 140
> drivers/media/platform/omap3isp/ispcsiphy.h | 10 --
> 3 files changed, 70 insertions(+), 83 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index 6fed222..accb3b0 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -129,9 +129,6 @@ struct isp_reg {
>
> struct isp_platform_callback {
> u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
> - int (*csiphy_config)(struct isp_csiphy *phy,
> - struct isp_csiphy_dphy_cfg *dphy,
> - struct isp_csiphy_lanes_cfg *lanes);
> };
>
> /*
> diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
> b/drivers/media/platform/omap3isp/ispcsiphy.c index f13bfbd..4ac1081 100644
> --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> @@ -119,36 +119,6 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy,
> u32 iface, bool on, }
>
> /*
> - * csiphy_lanes_config - Configuration of CSIPHY lanes.
> - *
> - * Updates HW configuration.
> - * Called with phy->mutex taken.
> - */
> -static void csiphy_lanes_config(struct isp_csiphy *phy)
> -{
> - unsigned int i;
> - u32 reg;
> -
> - reg = isp_reg_readl(phy->isp, phy->cfg_regs, ISPCSI2_PHY_CFG);
> -
> - for (i = 0; i < phy->num_data_lanes; i++) {
> - reg &= ~(ISPCSI2_PHY_CFG_DATA_POL_MASK(i + 1) |
> - ISPCSI2_PHY_CFG_DATA_POSITION_MASK(i + 1));
> - reg |= (phy->lanes.data[i].pol <<
> - ISPCSI2_PHY_CFG_DATA_POL_SHIFT(i + 1));
> - reg |= (phy->lanes.data[i].pos <<
> - ISPCSI2_PHY_CFG_DATA_POSITION_SHIFT(i + 1));
> - }
> -
> - reg &= ~(ISPCSI2_PHY_CFG_CLOCK_POL_MASK |
> - ISPCSI2_PHY_CFG_CLOCK_POSITION_MASK);
> - reg |= phy->lanes.clk.pol << ISPCSI2_PHY_CFG_CLOCK_POL_SHIFT;
> - reg |= phy->lanes.clk.pos << ISPCSI2_PHY_CFG_CLOCK_POSITION_SHIFT;
> -
> - isp_reg_writel(phy->isp, reg, phy->cfg_regs, ISPCSI2_PHY_CFG);
> -}
> -
> -/*
> * csiphy_power_autoswitch_enable
> * @enable: Sets or clears the autoswitch function enable flag.
> */
> @@ -193,43 +163,28 @@ static int csiphy_set_power(struct isp_csiphy *phy,
> u32 power) }
>
> /*
> - * csiphy_dphy_config - Configure CSI2 D-PHY parameters.
> - *
> - * Called with phy->mutex taken.
> + * TCLK values are OK at their reset values
> */
> -static void csiphy_dphy_config(struct isp_csiphy *phy)
> -{
> - u32 reg;
> -
> - /* Set up ISPCSIPHY_REG0 */
> - reg = isp_reg_readl(phy->isp, phy->phy_regs, ISPCSIPHY_REG0);
> -
> - reg &= ~(ISPCSIPHY_REG0_THS_TERM_MASK |
> - ISPCSIPHY_REG0_THS_SETTLE_MASK);
> - reg |= phy->dphy.ths_term << ISPCSIPHY_REG0_THS_TERM_SHIFT;
> - reg |= phy->dphy.ths_settle << ISPCSIPHY_REG0_THS_SETTLE_SHIFT;
> -
> - isp_reg_writel(phy->isp, reg, phy->phy_regs, ISPCSIPHY_REG0);
> -
> - /* Set up ISPCSIPHY_REG1 */
> - reg = isp_reg_readl(phy->isp, phy->phy_regs, ISPCSIPHY_REG1);
> -
> - reg &= ~(ISPCSIPHY_REG1_TCLK_TERM_MASK |
> - ISPCSIPHY_REG1_TCLK_MISS_MASK |
> - ISPCSIPHY_REG1_TCLK_SETTLE_MASK);
> - reg |= phy->dphy.tclk_term << ISPCSIPHY_REG1_TCLK_TERM_SHIFT;
> - reg |= phy->dphy.tclk_miss << ISPCSIPHY_REG1_TCLK_MISS_SHIFT;
> - reg |= phy->dphy.tclk_settle << ISPCSIPHY_REG1_TCLK_SETTLE_SHIFT;
> +#define TCLK_TERM0
> +#define TCLK_MISS1
> +#define TCLK_SETTLE 14
>
> - isp_reg_writel(phy->isp, reg, phy->phy_regs, ISPCSIPHY_REG1);
> -}
> -
> -static int csiphy_config(struct isp_csiphy *phy,
> - struct isp_csiphy_dphy_cfg *dphy,
> - struct isp_csiphy_lanes_cfg *lanes)
> +static int omap3isp_csiphy_config(struct isp_csiphy *phy)
> {
> + struct isp_csi2_device *csi2 = phy->csi2;
> + struct isp_pipeline *pipe = to_isp_pipeline(&csi2->subdev.entity);
> + struct isp_v4l2_subdevs_group *subdevs = pipe->external->host_priv;
> + struct isp_csiphy_lanes_cfg *lanes;
> + int csi2_ddrclk_khz;
> unsigned int used_lanes = 0;
> unsigned int i;
> + u32 reg;
> +
> + if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY1
> + || subdevs->interface == ISP_INTERFACE_CCP2B_PHY2)
> + lanes = &subdevs->bus.ccp2.lanecfg;
> + else
> + lanes = &subdevs->bus.
Re: [PATCH v3 2/3] omap3isp: Add PHY routing configuration
Hi Sakari,
Thanks for the patch.
On Sunday 07 October 2012 23:07:51 Sakari Ailus wrote:
> Add PHY routing configuration for both 3430 and 3630. Also add register bit
> definitions of CSIRXFE and CAMERA_PHY_CTRL registers on OMAP 3430 and 3630,
> respectively.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/platform/omap3isp/ispcsiphy.c | 86
> drivers/media/platform/omap3isp/ispreg.h| 22 +++
> 2 files changed, 108 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
> b/drivers/media/platform/omap3isp/ispcsiphy.c index 348f67e..f13bfbd 100644
> --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> @@ -32,6 +32,92 @@
> #include "ispreg.h"
> #include "ispcsiphy.h"
>
> +static void csiphy_routing_cfg_3630(struct isp_csiphy *phy, u32 iface,
> + bool ccp2_strobe)
> +{
> + u32 cam_phy_ctrl =
If you call the variable "value" or "ctrl" two statements below could fit on
one line, but that's up to you :-)
> + isp_reg_readl(phy->isp,
> + OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
> + u32 shift, mode;
> +
> + switch (iface) {
> + case ISP_INTERFACE_CCP2B_PHY1:
> + cam_phy_ctrl &=
> + ~OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
> + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
> + break;
> + case ISP_INTERFACE_CSI2C_PHY1:
> + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
> + mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
> + break;
> + case ISP_INTERFACE_CCP2B_PHY2:
> + cam_phy_ctrl |=
> + OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
> + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
> + break;
> + case ISP_INTERFACE_CSI2A_PHY2:
> + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
> + mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
> + break;
> + default:
> + pr_warn("bad iface %d\n", iface);
As you already know, dev_warn() is a better idea. Can this actually happen ?
> + return;
> + }
> +
> + /* Select data/clock or data/strobe mode for CCP2 */
> + switch (iface) {
> + case ISP_INTERFACE_CCP2B_PHY1:
> + case ISP_INTERFACE_CCP2B_PHY2:
> + if (ccp2_strobe)
> + mode =
> OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_STROBE;
> + else
> + mode =
> OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_CLOCK;
> + }
> +
> + cam_phy_ctrl &=
> + ~(OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_MASK << shift);
> + cam_phy_ctrl |= mode << shift;
> +
> + isp_reg_writel(phy->isp, cam_phy_ctrl,
> +OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
> +}
> +
> +static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, u32 iface, bool
> on,
> + bool ccp2_strobe)
> +{
> + uint32_t csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
> + | OMAP343X_CONTROL_CSIRXFE_RESET;
> +
> + /* Nothing to configure here. */
> + if (iface == ISP_INTERFACE_CSI2A_PHY2)
> + return;
> +
> + if (iface != ISP_INTERFACE_CCP2B_PHY1)
> + return;
> +
> + if (!on) {
> + isp_reg_writel(phy->isp, 0,
> +OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
> + return;
> + }
> +
> + if (ccp2_strobe)
> + csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
> +
> + isp_reg_writel(phy->isp, csirxfe,
> +OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
> +}
> +
> +static void csiphy_routing_cfg(struct isp_csiphy *phy, u32 iface, bool on,
> +bool ccp2_strobe)
> +{
> + if (phy->isp->mmio_base[OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL]
> + && on)
> + return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
> + if (phy->isp->mmio_base[OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE])
> + return csiphy_routing_cfg_3430(phy, iface, on, ccp2_strobe);
> +}
> +
> /*
> * csiphy_lanes_config - Configuration of CSIPHY lanes.
> *
> diff --git a/drivers/media/platform/omap3isp/ispreg.h
> b/drivers/media/platform/omap3isp/ispreg.h index 084ea77..66d2b42 100644
> --- a/drivers/media/platform/omap3isp/ispreg.h
> +++ b/drivers/media/platform/omap3isp/ispreg.h
> @@ -1583,4 +1583,26 @@
> #define ISPCSIPHY_REG2_CCP2_SYNC_PATTERN_MASK\
> (0x7f << ISPCSIPHY_REG2_CCP2_SYNC_PATTERN_SHIFT)
>
> +/*
> ---
> -- + * CONTROL registers for CSI-2 phy routing
> + */
> +
> +/* OMAP343X_CONTROL_CSIRXFE */
> +#define OMAP343X_CONTROL_CSIRX
Re: [PATCH] AM35xx: Add missing hwmod entry for the HDQ/1-Wire present in AM3505/3517 CPUs.
On Mon, 17 Sep 2012, Raphael Assenat wrote: > This patch adds a missing hwmod entry for the HDQ/1-Wire module present > in the AM3505/17 CPUs. > > This restores 1-Wire support to our AM3505 boards. We think it probably > stopped working with commit 96b1b29d37b0ca3ecd424a1fe301406cf525fc04 > ARM: OMAP2+: HDQ1W: use omap_device > > Signed-off-by: Raphael Assenat Acked-by: Paul Walmsley - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use
Hi Paul,
On 08/01/2012 10:36 AM, Paul Walmsley wrote:
> Hi Jon et al,
>
> Here's what I'm planning to queue here. The only changes from what Jon
> posted are the patch changelog and some checkpatch fixes. If anyone
> has any final comments, please let me know.
>
>
> - Paul
>
> From: Paul Walmsley
> Date: Wed, 1 Aug 2012 09:11:20 -0600
> Subject: [PATCH] ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
> clockdomain idle problems
[snip]
> diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
> b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
> index f99e65c..3f4b04b 100644
> --- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
> +++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
> @@ -248,6 +248,17 @@ static int omap3xxx_clkdm_clk_enable(struct clockdomain
> *clkdm)
> if (!clkdm->clktrctrl_mask)
> return 0;
>
> + /*
> + * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
> + * more details on the unpleasant problem this is working
> + * around
> + */
> + if ((clkdm->flags & CLKDM_MISSING_IDLE_REPORTING) &&
> + (clkdm->flags & CLKDM_CAN_FORCE_WAKEUP)) {
> + omap3_clkdm_wakeup(clkdm);
> + return 0;
> + }
> +
> hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
> clkdm->clktrctrl_mask);
>
> @@ -271,6 +282,17 @@ static int omap3xxx_clkdm_clk_disable(struct clockdomain
> *clkdm)
> if (!clkdm->clktrctrl_mask)
> return 0;
>
> + /*
> + * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
> + * more details on the unpleasant problem this is working
> + * around
> + */
> + if (clkdm->flags & CLKDM_MISSING_IDLE_REPORTING &&
> + !(clkdm->flags & CLKDM_CAN_FORCE_SLEEP)) {
> + _enable_hwsup(clkdm);
> + return 0;
> + }
> +
> hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
> clkdm->clktrctrl_mask);
I was looking at what got merged and it appears that the above code was
added to the omap2 clkdm enable/disable functions and not omap3. I believe
that is a mistake? If so the below fixes this.
Cheers
Jon
>From 16db11f3373bc6e03254c4d1d92ee762f69cbacc Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Wed, 1 Aug 2012 09:36:13 -0600
Subject: [PATCH] ARM: OMAP3: fix workaround for EMU clockdomain
Commit b71c721 (ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
clockdomain idle problems) added a workaround for the EMU clock domain on
OMAP3/4 devices to prevent the clock domain for transitioning while it is
in use.
In the proposed patch [1] code was added to the omap3xxx_clkdm_clk_enable()
and omap3xxx_clkdm_clk_disable() functions to check for the flag
CLKDM_MISSING_IDLE_REPORTING and perform the appropriate action. However, in the
merged patch it appears that this code was added to the omap2_clkdm_clk_enable()
and omap2_clkdm_clk_disable() functions by mistake.
[1] http://marc.info/?l=linux-arm-kernel&m=134383567112518&w=2
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
index 9a7792a..70294f5 100644
--- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
@@ -183,17 +183,6 @@ static int omap2_clkdm_clk_enable(struct clockdomain
*clkdm)
if (!clkdm->clktrctrl_mask)
return 0;
- /*
-* The CLKDM_MISSING_IDLE_REPORTING flag documentation has
-* more details on the unpleasant problem this is working
-* around
-*/
- if (clkdm->flags & CLKDM_MISSING_IDLE_REPORTING &&
- !(clkdm->flags & CLKDM_CAN_FORCE_SLEEP)) {
- _enable_hwsup(clkdm);
- return 0;
- }
-
hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
clkdm->clktrctrl_mask);
@@ -217,17 +206,6 @@ static int omap2_clkdm_clk_disable(struct clockdomain
*clkdm)
if (!clkdm->clktrctrl_mask)
return 0;
- /*
-* The CLKDM_MISSING_IDLE_REPORTING flag documentation has
-* more details on the unpleasant problem this is working
-* around
-*/
- if ((clkdm->flags & CLKDM_MISSING_IDLE_REPORTING) &&
- (clkdm->flags & CLKDM_CAN_FORCE_WAKEUP)) {
- omap3_clkdm_wakeup(clkdm);
- return 0;
- }
-
hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
clkdm->clktrctrl_mask);
@@ -269,6 +247,17 @@ static int omap3xxx_clkdm_clk_enable(struct clockdomain
*clkdm)
if (!clkdm->clktrctrl_mask)
return 0;
+ /*
+* The CLKDM_MISSING_IDLE_REPORTING flag documentation has
+* more details on the
[GIT PULL] ARM: OMAP: PM fixes for v3.7-rc
Tony, Please pull the following OMAP PM fixes for v3.7-rc. Thanks, Kevin The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9: Linux 3.6 (2012-09-30 16:47:46 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.7-fixes-pm for you to fetch changes up to ce3810cdb4ca31238c87e095d2c494a5eaa4f65d: ARM: OMAP: SmartReflex: fix error path in init function (2012-10-02 14:55:31 -0700) OMAP PM related fixes for v3.7-rc Jean Pihet (2): ARM: OMAP: SmartReflex: select CONFIG_POWER_SUPPLY in Kconfig ARM: OMAP: SmartReflex: fix error path in init function Wei Yongjun (4): ARM: OMAP: fix return value check in beagle_opp_init() ARM: OMAP: omap_device: fix return value check in omap_device_build_ss() ARM: OMAP2+: SmartReflex: fix return value check in sr_dev_init() ARM: OMAP2+: PM: fix return value check in omap2_set_init_voltage() arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/pm.c|2 +- arch/arm/mach-omap2/sr_device.c |2 +- arch/arm/plat-omap/Kconfig |1 + arch/arm/plat-omap/omap_device.c|2 +- drivers/power/avs/smartreflex.c |8 6 files changed, 9 insertions(+), 8 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
[GIT PULL] ARM: OMAP: CPUfreq fixes for v3.7-rc
The following changes since commit 16642a2e7be23bbda013fc32d8f6c68982eab603: Merge tag 'pm-for-3.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm (2012-10-02 18:32:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.7-fixes-cpufreq for you to fetch changes up to 24d7b40a60cf19008334bcbcbd98da374d4d9c64: ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS (2012-10-08 14:59:04 -0700) This series a couple bug fixes and a couple fixes that make this driver support recently added OMAP-based SoCs. The 'get_cpu_device' patch is needed due to a change in the OMAP OMAP PM core code which enforces use of get_cpu_device() instead of a deprecated OMAP-specific API. The usage of plat/*.h headers breaks single zImage, so platforms are cleaning up and/or removing plat/*.h so the driver needs to be fixed accordingly. This series is based on the merge of Rafael's pm-for-3.7-rc1 tag into Linus' master branch: commit 16642a2e7be23bbda013fc32d8f6c68982eab603. Kevin Hilman (4): cpufreq: OMAP: ensure valid clock rate before scaling cpufreq: OMAP: remove unused cpufreq: OMAP: use get_cpu_device() instead of omap_device API ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS Paul Walmsley (1): cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/ includes arch/arm/mach-omap2/opp.c| 23 +-- arch/arm/mach-omap2/pm.c | 11 ++- arch/arm/mach-omap2/twl-common.c |2 +- drivers/cpufreq/omap-cpufreq.c | 36 4 files changed, 40 insertions(+), 32 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 v3 1/3] omap3isp: Add CSI configuration registers from control block to ISP resources
Moikka, On Mon, Oct 08, 2012 at 03:06:46PM -0700, Tony Lindgren wrote: > * Sakari Ailus [121007 13:09]: > > Add the registers used to configure the CSI-2 receiver PHY on OMAP3430 and > > 3630 and map them in the ISP driver. The register is part of the control > > block but it only is needed by the ISP driver. > > Just checking.. These do get reserved with request_mem_region() > in isp_map_mem_resource() before they get ioremapped, right? That's right. The code doing that can be found in drivers/media/platform/omap3isp/isp.c in a function called isp_map_mem_resource(). > And camera is the only user for these registers and they are > not shared with anything else? Correct. These registers only contain bits for configuring the CSI-2 PHY routing and CCP2 clock/strobe mode. > If so, then this is OK to merge via the media patches: > > Acked-by: Tony Lindgren Thanks! :-) -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: move old debug-devices.c and debug-leds.c to be OMAP2+ only for now
* Paul Walmsley [121007 18:48]:
>
> Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 ("ARM: OMAP: move
> debug_card_init() function") results in the following new sparse[1]
> warning:
>
> arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init'
> was not declared. Should it be static?
>
> Normally this could be fixed by including the appropriate header file
> in plat-omap/debug-devices.c, but the header file now exists only in
> mach-omap2/, so this would require a "sideways include" and is thus
> impractical. It turns out that only code in mach-omap2/ currently
> uses the debug-devices.c and debug-leds.c files, so move them there.
> In the long term, these devices should be created by DT, and the code
> should be moved into drivers/ somewhere.
Hmm are you sure that omap1 is not using debug-leds.c?
At least the initcall seems like it should run on omap1
if enabled.
The sideways include here is OK, it does not get exposed to
the drivers, it seems that plat-omap is still the right location
for at least debug-leds.c code.
> rename from arch/arm/plat-omap/debug-leds.c
> rename to arch/arm/mach-omap2/debug-leds.c
> index ea29bbe..c12350b 100644
> --- a/arch/arm/plat-omap/debug-leds.c
> +++ b/arch/arm/mach-omap2/debug-leds.c
> @@ -146,11 +146,8 @@ static struct platform_driver led_driver = {
>
> static int __init fpga_init(void)
> {
> - if (machine_is_omap_h4()
> - || machine_is_omap_h3()
> - || machine_is_omap_h2()
> - || machine_is_omap_perseus2()
> - )
> + if (machine_is_omap_h4() || machine_is_omap_h3() ||
> + machine_is_omap_h2() || machine_is_omap_perseus2())
> return platform_driver_register(&led_driver);
> return 0;
> }
This looks like it should work fine for the boards using
the debug leds on omap1 too.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap3isp: Add CSI configuration registers from control block to ISP resources
* Sakari Ailus [121007 13:09]:
> Add the registers used to configure the CSI-2 receiver PHY on OMAP3430 and
> 3630 and map them in the ISP driver. The register is part of the control
> block but it only is needed by the ISP driver.
Just checking.. These do get reserved with request_mem_region()
in isp_map_mem_resource() before they get ioremapped, right?
And camera is the only user for these registers and they are
not shared with anything else?
If so, then this is OK to merge via the media patches:
Acked-by: Tony Lindgren
> Signed-off-by: Sakari Ailus
> ---
> arch/arm/mach-omap2/devices.c | 10 ++
> drivers/media/platform/omap3isp/isp.c |6 --
> drivers/media/platform/omap3isp/isp.h |2 ++
> 3 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index c00c689..9e4d5da 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -201,6 +201,16 @@ static struct resource omap3isp_resources[] = {
> .flags = IORESOURCE_MEM,
> },
> {
> + .start = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
> + .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE
> + 3,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = OMAP343X_CTRL_BASE +
> OMAP3630_CONTROL_CAMERA_PHY_CTRL,
> + .end= OMAP343X_CTRL_BASE +
> OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> .start = INT_34XX_CAM_IRQ,
> .flags = IORESOURCE_IRQ,
> }
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c
> index d7aa513..88fba2c 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -100,7 +100,8 @@ static const struct isp_res_mapping isp_res_maps[] = {
> 1 << OMAP3_ISP_IOMEM_RESZ |
> 1 << OMAP3_ISP_IOMEM_SBL |
> 1 << OMAP3_ISP_IOMEM_CSI2A_REGS1 |
> -1 << OMAP3_ISP_IOMEM_CSIPHY2,
> +1 << OMAP3_ISP_IOMEM_CSIPHY2 |
> +1 << OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
> },
> {
> .isp_rev = ISP_REVISION_15_0,
> @@ -117,7 +118,8 @@ static const struct isp_res_mapping isp_res_maps[] = {
> 1 << OMAP3_ISP_IOMEM_CSI2A_REGS2 |
> 1 << OMAP3_ISP_IOMEM_CSI2C_REGS1 |
> 1 << OMAP3_ISP_IOMEM_CSIPHY1 |
> -1 << OMAP3_ISP_IOMEM_CSI2C_REGS2,
> +1 << OMAP3_ISP_IOMEM_CSI2C_REGS2 |
> +1 << OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
> },
> };
>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h
> index 8be7487..6fed222 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -72,6 +72,8 @@ enum isp_mem_resources {
> OMAP3_ISP_IOMEM_CSI2C_REGS1,
> OMAP3_ISP_IOMEM_CSIPHY1,
> OMAP3_ISP_IOMEM_CSI2C_REGS2,
> + OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
> + OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
> OMAP3_ISP_IOMEM_LAST
> };
>
> --
> 1.7.2.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: fix return value check in realtime_counter_init()
* Wei Yongjun [121007 07:00]:
> From: Wei Yongjun
>
> In case of error, the function clk_get() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value
> check should be replaced with IS_ERR().
Thanks applying into omap fixes.
Tony
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun
> ---
> arch/arm/mach-omap2/timer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 8847d6e..44f9aa7 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -378,7 +378,7 @@ static void __init realtime_counter_init(void)
> return;
> }
> sys_clk = clk_get(NULL, "sys_clkin_ck");
> - if (!sys_clk) {
> + if (IS_ERR(sys_clk)) {
> pr_err("%s: failed to get system clock handle\n", __func__);
> iounmap(base);
> return;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: remove duplicated include from board-omap3stalker.c
* Wei Yongjun [121007 06:26]: > From: Wei Yongjun > > Remove duplicated include. Thanks applying into omap fixes. Tony > dpatch engine is used to auto generate this patch. > (https://github.com/weiyj/dpatch) > > Signed-off-by: Wei Yongjun > --- > arch/arm/mach-omap2/board-omap3stalker.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-omap3stalker.c > b/arch/arm/mach-omap2/board-omap3stalker.c > index c7f3d02..731235e 100644 > --- a/arch/arm/mach-omap2/board-omap3stalker.c > +++ b/arch/arm/mach-omap2/board-omap3stalker.c > @@ -48,11 +48,6 @@ > #include > > #include > -#include > -#include > -#include > -#include > -#include > > #include "sdram-micron-mt46h32m32lf-6.h" > #include "mux.h" > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: Fix dependency for OMAP_DEBUG_LEDS
* Axel Lin [121007 03:14]: > This fixes below build error when CONFIG_LEDS_CLASS is not set. > > LD init/built-in.o > arch/arm/plat-omap/built-in.o: In function `fpga_probe': > arch/arm/plat-omap/debug-leds.c:113: undefined reference to > `led_classdev_register' > arch/arm/plat-omap/debug-leds.c:113: undefined reference to > `led_classdev_register' > arch/arm/plat-omap/debug-leds.c:113: undefined reference to > `led_classdev_register' > arch/arm/plat-omap/debug-leds.c:113: undefined reference to > `led_classdev_register' > arch/arm/plat-omap/debug-leds.c:113: undefined reference to > `led_classdev_register' > arch/arm/plat-omap/built-in.o:arch/arm/plat-omap/debug-leds.c:113: more > undefined references to `led_classdev_register' follow > make: *** [vmlinux] Error 1 > > Signed-off-by: Axel Lin Thanks looks like I have already an earlier version of the same patch from you already queued. Regards, Tony > --- > arch/arm/plat-omap/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig > index ca83a76..c262781 100644 > --- a/arch/arm/plat-omap/Kconfig > +++ b/arch/arm/plat-omap/Kconfig > @@ -43,6 +43,7 @@ config OMAP_DEBUG_DEVICES > > config OMAP_DEBUG_LEDS > def_bool y if NEW_LEDS > + select LEDS_CLASS > depends on OMAP_DEBUG_DEVICES > > config POWER_AVS_OMAP > -- > 1.7.9.5 > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: gpmc: annotate exit sections properly
* Afzal Mohammed [121004 01:33]: > compiler complained, > `gpmc_remove' referenced in section `.data' of > arch/arm/mach-omap2/built-in.o: defined in discarded section `.exit.text' of > arch/arm/mach-omap2/built-in.o > > Annotate gpmc_remove function and dependents with __devexit. Thanks applying into omap fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/omap: Replace board_ref_clock with enum values
* Pankaj Jangra [120927 19:25]: > Hi, > > On Wed, Sep 26, 2012 at 10:12 PM, Vikram Narayanan > wrote: > > Use the enum for board_ref_clock from linux/wl12xx.h > > > > Signed-off-by: Vikram Narayanan > > Cc: Tony Lindgren > > Cc: linux-omap@vger.kernel.org > > --- > > I'm not subscribed to the list. So please keep me in Cc for the replies. > > > > arch/arm/mach-omap2/board-omap4panda.c |3 +-- > > arch/arm/mach-omap2/board-zoom-peripherals.c |3 +-- > > 2 files changed, 2 insertions(+), 4 deletions(-) > > > > Looks good. > > Reviewed-by: Pankaj Jangra Thanks applying into omap fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: increase FORCE_MAX_ZONEORDER for TI AM33XX
* yegorsli...@googlemail.com [120925 01:45]: > From: Yegor Yefremov > > FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB > of consistent DMA memory (da8xx frame buffer driver). > > Signed-off-by: Dejan Gacnik > Signed-off-by: Yegor Yefremov Thanks for updating this, applying this into omap fixes. Regards, Tony > --- > arch/arm/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 2f88d8d..06d489e 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1768,6 +1768,7 @@ source "mm/Kconfig" > config FORCE_MAX_ZONEORDER > int "Maximum zone order" if ARCH_SHMOBILE > range 11 64 if ARCH_SHMOBILE > + default "12" if SOC_AM33XX > default "9" if SA > default "11" > help -- 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/4] cpufreq: OMAP: fixes for v3.7-rc2
"Rafael J. Wysocki" writes: > On Wednesday 03 of October 2012 16:00:25 Kevin Hilman wrote: >> From: Kevin Hilman >> >> Here's a series with a couple bug fixes and a couple fixes that >> make this driver support newer OMAP-based SoCs. >> >> The 'get_cpu_device' patch is needed due to a change in the OMAP >> OMAP PM core code which enforces use of get_cpu_device() instead of >> a deprecated OMAP-specific API. >> >> The usage of plat/*.h headers breaks single zImage, so platforms are >> cleaning up and/or removing plat/*.h so the driver needs to be fixed >> accordingly. >> >> This series is based on the merge of Rafael's pm-for-3.7-rc1 tag into >> Linus' master branch: commit 16642a2e7be23bbda013fc32d8f6c68982eab603. >> >> Tested CPUfreq on OMAP platforms: 3430/n900, 3530/Overo, >> 3730/OveroSTORM, 3730/Beagle-XM, 4430/Panda. >> >> Rafael, if you're OK with this series, I'll get a pull request >> ASAP so it can be included for v3.7-rc2. > > The patches are fine by me, but there may be a bit of a timing issue with > them, because I'll be travelling between October 12 and October 21 inclusive > and I won't be pushing stuff to kernel.org during that time. > > So I think it would be better to merge this material through the arm-soc tree, > if that's not a problem. If you decide to do so, please feel free to add my > ACK to the patches. Thanks, I'll get them queued. 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 v2] ARM: OMAP2+: Add am335x evm and bone targets to common Makefile
* Vaibhav Hiremath [120924 11:38]: > This adds am335x-evm and am335x-bone dtb targets to > 'make dtbs', just like other platforms. Thanks applying into omap fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: hsmmc: fix return value check in omap_hsmmc_init_one()
* Wei Yongjun [120920 23:31]: > From: Wei Yongjun > > In case of error, the function omap_device_alloc() returns ERR_PTR() > not NULL pointer. The NULL test in the return value check should > be replaced with IS_ERR(). Thanks applying into omap fixes. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: fix return value check in create_dss_pdev()
* Wei Yongjun [120920 23:29]: > From: Wei Yongjun > > In case of error, the function omap_device_alloc() returns ERR_PTR() > not NULL pointer. The NULL test in the return value check should > be replaced with IS_ERR(). Thanks applying into omap fixes. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] [media] omap3isp: Fix compilation error in ispreg.h
* Mauro Carvalho Chehab [121007 06:18]:
> Em Tue, 2 Oct 2012 09:31:58 -0700
> Tony Lindgren escreveu:
>
> > * Ido Yariv [121001 15:48]:
> > > Commit c49f34bc ("ARM: OMAP2+ Move SoC specific headers to be local to
> > > mach-omap2") moved omap34xx.h to mach-omap2. This broke omap3isp, as it
> > > includes omap34xx.h.
> > >
> > > Instead of moving omap34xx to platform_data, simply add the two
> > > definitions the driver needs and remove the include altogether.
> > >
> > > Signed-off-by: Ido Yariv
> >
> > I'm assuming that Mauro picks this one up, sorry
> > for breaking it.
>
> Picked, thanks.
>
> With regards to the other patches in this series, IMHO, it
> makes more sense to go through arm omap tree, so, for the
> patches on this series that touch at drivers/media/platform/*:
>
> Acked-by: Mauro Carvalho Chehab
Thanks yeah it's best that I pick up the rest. I can setup
a minimal branch that can also be pulled into iommu branch
after -rc1.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AM35xx: Add missing hwmod entry for the HDQ/1-Wire present in AM3505/3517 CPUs.
* Tony Lindgren [121008 14:12]: > * Raphael Assenat [120917 07:57]: > > This patch adds a missing hwmod entry for the HDQ/1-Wire module present > > in the AM3505/17 CPUs. > > > > This restores 1-Wire support to our AM3505 boards. We think it probably > > stopped working with commit 96b1b29d37b0ca3ecd424a1fe301406cf525fc04 > > ARM: OMAP2+: HDQ1W: use omap_device > > Thanks applying into fixes. Oops, this is something Paul and Benoit usually pick. I have it still in my fixes, let me know if I need to drop it. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arch/arm/mach-omap1/devices.c: Remove unecessary semicolon
* Peter Senna Tschudin [120918 09:37]:
> Found by http://coccinelle.lip6.fr/
>
> Signed-off-by: Peter Senna Tschudin
> ---
> arch/arm/mach-omap1/devices.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
> index fa1fa4d..688b23a 100644
> --- a/arch/arm/mach-omap1/devices.c
> +++ b/arch/arm/mach-omap1/devices.c
> @@ -232,7 +232,7 @@ void __init omap1_init_mmc(struct omap_mmc_platform_data
> **mmc_data,
>
> omap_mmc_add("mmci-omap", i, base, size, irq,
> rx_req, tx_req, mmc_data[i]);
> - };
> + }
> }
>
> #endif
Thanks applying into omap fixes branch.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arch/arm/plat-omap/omap-pm-noop.c: Remove unecessary semicolon
* Peter Senna Tschudin [120918 09:37]: > Found by http://coccinelle.lip6.fr/ > > Signed-off-by: Peter Senna Tschudin > --- > arch/arm/plat-omap/omap-pm-noop.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Thanks applying into omap fixes branch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arch/arm/mach-omap2: Remove unecessary semicolon
* Peter Senna Tschudin [120918 09:37]: > Found by http://coccinelle.lip6.fr/ > > Signed-off-by: Peter Senna Tschudin > --- > arch/arm/mach-omap2/board-flash.c | 2 +- > arch/arm/mach-omap2/clkt_clksel.c | 2 +- > arch/arm/mach-omap2/mux.c | 2 +- > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 6 +++--- > arch/arm/mach-omap2/pm-debug.c | 2 +- > 5 files changed, 7 insertions(+), 7 deletions(-) Thanks applying into omap fixes branch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: OMAP_DEBUG_LEDS needs to select LEDS_CLASS
* Bryan Wu [120918 01:03]: > On Tue, Sep 18, 2012 at 2:49 PM, Axel Lin wrote: > > 2012/9/18 Bryan Wu : > >> On Tue, Sep 18, 2012 at 11:30 AM, Axel Lin wrote: > >>> This fixes below build error when CONFIG_LEDS_CLASS is not set. > >>> > >>> LD init/built-in.o > >>> arch/arm/plat-omap/built-in.o: In function `fpga_probe': > >>> arch/arm/plat-omap/debug-leds.c:113: undefined reference to > >>> `led_classdev_register' > >>> make: *** [vmlinux] Error 1 > >>> > >> > >> Thanks for posting this. But I think Tony has already fixed it in mainline: > >> -- > >> commit 359f64f7b3997e94ee71039b5fcdc1278b9b77c4 > >> Author: Tony Lindgren > >> Date: Wed Sep 15 10:18:51 2010 -0700 > >> > >> omap: Fix compile dependency to LEDS_CLASS > >> > >> If we LEDS_CLASS is not selected, we will get undefined reference > >> to `led_classdev_register'. > >> > >> Signed-off-by: Tony Lindgren > > > > Commit 359f64f7b was commited on Sep 15 2010. > > This patch is against current linux-next tree. > > I got the build error on linux-next tree (next-20120917). > > > > Obviously, linux-next is not updated to latest mainline, -:D Thanks I'll apply this to fixes. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AM35xx: Add missing hwmod entry for the HDQ/1-Wire present in AM3505/3517 CPUs.
* Raphael Assenat [120917 07:57]: > This patch adds a missing hwmod entry for the HDQ/1-Wire module present > in the AM3505/17 CPUs. > > This restores 1-Wire support to our AM3505 boards. We think it probably > stopped working with commit 96b1b29d37b0ca3ecd424a1fe301406cf525fc04 > ARM: OMAP2+: HDQ1W: use omap_device Thanks applying into fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/7] ARM: OMAP2+: Add device-tree support for timers
* Jon Hunter [120928 14:48]: > > What is interesting is that it is the interrupt test that is failing for > timers 5-7. Any chance there is a problem with the interrupt mapping? I > checked the documentation for AM335x and I don't see anything obvious > that is wrong with the binding unless the documentation itself is wrong. This could also be caused by some timers not being able to wake up the system from idle? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: rx51: Fix a section mismatch warn
* Shubhrajyoti D [120912 07:38]: > rx51_si4713_dev is referenced only from rx51_init_si4713. > So the memory for rx51_si4713_dev can be safely freed after init. > Also it references rx51_si4713_board_info which is __initdata_or_module. Thanks applying into fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] ARM: OMAP2+: Round of the carve out memory requested to section_size
* Shilimkar, Santosh [120927 23:35]: > On Wed, Sep 12, 2012 at 12:44 PM, R Sricharan wrote: > > memblock_steal tries to reserve physical memory during boot. > > When the requested size is not aligned on the section size > > then, the remaining memory available for lowmem becomes > > unaligned on the section boundary. There is a issue with this, > > which is discussed in the thread below. > > > > https://lkml.org/lkml/2012/6/28/112 > > > > The final conclusion from the thread seems to > > be align the memblock_steal calls on the SECTION boundary. > > The issue comes out when LPAE is enabled, where the > > section size is 2MB. > > > > Boot tested this on OMAP5 evm with and without LPAE. > > > > Signed-off-by: R Sricharan > > --- > > [V2] Corrected the subject and added one more description line. > > > Looks good. > Acked-by : Santosh Shilimkar > > Tony, > Can you take this into your next "fixes-noncritical" queue please ? Applying it now into fixes for the -rc cycle. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] ARM: OMAP: counter: add locking to read_persistent_clock
* Tony Lindgren [120925 08:19]:
> * R, Sricharan [120925 00:44]:
> > Hi Tony,
> >
> > [snip..]
> >
> > >> > index dbf1e03..2bc51fb 100644
> > >> > --- a/arch/arm/plat-omap/counter_32k.c
> > >> > +++ b/arch/arm/plat-omap/counter_32k.c
> > >> > @@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
> > >> > * nsecs and adds to a monotonically increasing timespec.
> > >> > */
> > >> > static struct timespec persistent_ts;
> > >> > -static cycles_t cycles, last_cycles;
> > >> > +static cycles_t cycles;
> > >> > static unsigned int persistent_mult, persistent_shift;
> > >> > +static DEFINE_SPINLOCK(read_persistent_clock_lock);
> > >> > +
> > >> > static void omap_read_persistent_clock(struct timespec *ts)
> > >> > {
> > >> > unsigned long long nsecs;
> > >> > - cycles_t delta;
> > >> > - struct timespec *tsp = &persistent_ts;
> > >> > + cycles_t last_cycles;
> > >> > + unsigned long flags;
> > >> > +
> > >> > + spin_lock_irqsave(&read_persistent_clock_lock, flags);
> > >> >
> > >> > last_cycles = cycles;
> > >> > cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
> > >> > - delta = cycles - last_cycles;
> > >> >
> > >> > - nsecs = clocksource_cyc2ns(delta, persistent_mult,
> > >> > persistent_shift);
> > >> > + nsecs = clocksource_cyc2ns(cycles - last_cycles,
> > >> > + persistent_mult, persistent_shift);
> > >
> > > ..I think there's another bug here where cycles - last_cycles
> > > returns wrong value when the timer wraps around as cycles_t is
> > > 64 bits and the counter is 32 bits. It seems it's been there
> > > since when the read_persistent_clock was added with commit
> > > d92cfcbe (OMAP: timekeeping: time should not stop during suspend)?
> > >
> > > It seems that after this patch cycles should not be cycles_t
> > > but u32, and the result of cycles - last_cycles should also
> > > be u32.
> > >
> > cycles_t is defined as typedef unsigned long cycles_t;
> > Am i missing something here ?
>
> Oh right, cycles_t is unsigned long, it's OK then. Must
> have grepped for it from some other arch.
Applying to fixes with Cc stable.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX
* Dejan Gačnik [120927 07:13]: > > I and my colleagues have developed a brand new very enhanced board having > AM35xx CPU, 512MB DDR2, DVI, true dual Ethernet support (not using PRUSS), > CAN, SPI, I2C, 7 USBs, etc…Board is already materialized and operational. > > > According to our board we have create new machine type in the kernel > (version: linux-3.2-psp04.06.00.07.sdk) and all other required stuff to > support our board, modify some things, like adding support for dual eth, > etc. Our goal is to provide this new board to the market (let say with > large quantity) and therefore I am wondering how to start or if it is even > possible to transfer our kernel change the main stream of this distro? > During this kernel modification process we have been looking to not > changing anything in kernel, what could affect other machine types. For the mainline kernel, you should go with device tree based booting to start with, we are no longer adding new board-*.c files. For older distro kernels you need to maintain a separate board-*.c file until we have moved everything to use device tree and distros are using that kernel. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: Add option to configure output line for McSPI driver
* Stan Hu [120926 11:36]:
> McSPI driver previously assumed that D0 was input (MISO) and D1 was output
> (MOSI).
> This forces the hardware designer to wire all SPI peripherals in this way when
> it should be a software configuration option.
>
> Signed-off-by: Stan Hu
> ---
> arch/arm/plat-omap/include/plat/mcspi.h |2 ++
> drivers/spi/spi-omap2-mcspi.c | 11 +--
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
> b/arch/arm/plat-omap/include/plat/mcspi.h
> index a357eb2..0a6b790 100644
> --- a/arch/arm/plat-omap/include/plat/mcspi.h
> +++ b/arch/arm/plat-omap/include/plat/mcspi.h
> @@ -18,6 +18,8 @@ struct omap2_mcspi_dev_attr {
>
> struct omap2_mcspi_device_config {
> unsigned turbo_mode:1;
> + /* 1 -> [D0 = MOSI, D1 = MISO], otherwise vice versa */
> + unsigned d0_is_output:1;
> };
>
> #endif
FYI, if this did not yet get applied, this header has now been
moved to linux/platform_data/spi-omap2-mcspi.h. So you may want
to updated it and repost.
Also, you should probably Cc spi-devel-gene...@lists.sourceforge.net.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
* Marc Zyngier [121008 04:34]: > On 08/10/12 12:01, Dave Martin wrote: > > > > In an attempt to narrow this down... > > > > Can you follow this (i.e., _after_ a known successful switch to SVC mode) > > > > (a) > > mrs \reg, cpsr > > msr spsr_cxsf, \reg > > adr \reg, 3f > > movspc, lr > > 3: > > > > and (b) > > > > mrs \reg, cpsr > > orr \reg, \reg, #CPSR_A_BIT > > msr cpsr_cxsf, \reg > > > > and (c) > > > > mrs \reg, cpsr > > orr \reg, \reg, #CPSR_A_BIT > > msr spsr_cxsf, \reg > > adr \reg, 3f > > movspc, lr > > 3: > > > > > > > > > > If only (a) works, this would suggest that the attempt to set the A bit > > is causing the problem. > > > > If only (b) works, this suggests that the A bit is OK but that some > > invalid hardware state, or something else we don't understand, is causing > > exception returns to fail in general. > > > > If (a) and (b) work but (c) fails, this suggests that specifically > > trying to set the A bit via an exception return is problematic. > > > > If all of them work then this suggests some invalid hardware state or > > something else we don't understand, but which is cleared by the initial > > msr cpsr_c which clobbers the processor mode. Thanks it does not seem to be the A bit.. > Playing with an Integrator-CP with a 1136 tile, the only way I could > cause the thing to fail was to boot the thing in SYSTEM mode. > > Tony, can you possibly also try the attached patch? Yup you figured it out n800 is in system mode while 2430sdp is not.. I verified it with printhex2. Your patch fails to compile with: arch/arm/kernel/head.S: Assembler messages: arch/arm/kernel/head.S:336: Error: symbol `omgsys' is already defined Probably because it's included twice. Also, shouldn't it be bne omgsys instead of beq? Regards, Tony > diff --git a/arch/arm/include/asm/assembler.h > b/arch/arm/include/asm/assembler.h > index 683a1e6..7714ec7 100644 > --- a/arch/arm/include/asm/assembler.h > +++ b/arch/arm/include/asm/assembler.h > @@ -253,6 +253,8 @@ > mrs \reg , cpsr > mov lr , \reg > and lr , lr , #MODE_MASK > + cmp lr , #SYSTEM_MODE /* Yet another braindead platform? */ > + beq omgsys > cmp lr , #HYP_MODE > orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT > bic \reg , \reg , #MODE_MASK > @@ -264,6 +266,7 @@ THUMB(orr \reg , \reg , #PSR_T_BIT) > __MSR_ELR_HYP(14) > __ERET > 1: movspc, lr > +omgsys: msr cpsr_c, \reg > 2: > .endm > -- 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/gpio-omap: Use existing pointer to struct device
On Fri, Oct 5, 2012 at 11:37 AM, Tobias Klauser wrote: > A pointer to "pdev->dev" is already stored in "dev", so use it in > devm_kzalloc. > > Signed-off-by: Tobias Klauser Applied with Kevin's ACK, thanks! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
* Tony Lindgren [121008 10:37]: > Drivers should not use cpu_is_omap or cpu_class_is_omap macros, > they should be private to the platform init code. And we'll be > removing plat/cpu.h and only have a private soc.h for the > arch/arm/*omap* code. > > This patch is intended as preparation for the core omap changes > and removes the need to include plat/cpu.h from several drivers. > This is needed for the ARM common zImage support. > > These changes are OK to do because: > > - omap-rng.c and hsmmc.c don't need plat/cpu.h > > - omap-aes.c and omap-sham.c get the proper platform_data > passed to them so they don't need extra checks in the driver > > - omap-dma.c and omap-pcm.c can test the arch locally as > omap1 and omap2 cannot be compiled together because of > conflicting compiler flags > --- a/drivers/mmc/host/omap_hsmmc.c > +++ b/drivers/mmc/host/omap_hsmmc.c > @@ -40,7 +40,6 @@ > #include > #include > #include > -#include > > /* OMAP HSMMC Host Controller Registers */ > #define OMAP_HSMMC_SYSSTATUS 0x0014 Actually I'll fold this mmc change into an earlier patch I've posted as "ARM: OMAP: Split plat/mmc.h into local headers and platform_data". Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
Drivers should not use cpu_is_omap or cpu_class_is_omap macros,
they should be private to the platform init code. And we'll be
removing plat/cpu.h and only have a private soc.h for the
arch/arm/*omap* code.
This patch is intended as preparation for the core omap changes
and removes the need to include plat/cpu.h from several drivers.
This is needed for the ARM common zImage support.
These changes are OK to do because:
- omap-rng.c and hsmmc.c don't need plat/cpu.h
- omap-aes.c and omap-sham.c get the proper platform_data
passed to them so they don't need extra checks in the driver
- omap-dma.c and omap-pcm.c can test the arch locally as
omap1 and omap2 cannot be compiled together because of
conflicting compiler flags
Cc: Deepak Saxena
Cc: Matt Mackall
Cc: Herbert Xu
Cc: David S. Miller
Cc: Venkatraman S
Cc: Chris Ball
Cc: Vinod Koul
Cc: Dan Williams
Cc: Peter Ujfalusi
Cc: Jarkko Nikula
Cc: Liam Girdwood
Cc: Mark Brown
Cc: linux-cry...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Tony Lindgren
---
drivers/char/hw_random/omap-rng.c |2 --
drivers/crypto/omap-aes.c |6 --
drivers/crypto/omap-sham.c|8
drivers/dma/omap-dma.c|9 +++--
drivers/mmc/host/omap_hsmmc.c |1 -
sound/soc/omap/omap-pcm.c |9 +++--
6 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index a5effd8..45e467d 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -27,8 +27,6 @@
#include
-#include
-
#define RNG_OUT_REG0x00/* Output register */
#define RNG_STAT_REG 0x04/* Status register
[0] = STAT_BUSY */
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 3e61feb..649a146 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -29,7 +29,6 @@
#include
#include
-#include
#include
/* OMAP TRM gives bitfields as start:end, where start is the higher bit
@@ -941,11 +940,6 @@ static int __init omap_aes_mod_init(void)
{
pr_info("loading %s driver\n", "omap-aes");
- if (!cpu_class_is_omap2() || omap_type() != OMAP2_DEVICE_TYPE_SEC) {
- pr_err("Unsupported cpu\n");
- return -ENODEV;
- }
-
return platform_driver_register(&omap_aes_driver);
}
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 6d79695..d76fe06 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -37,7 +37,6 @@
#include
#include
-#include
#include
#include
@@ -1289,13 +1288,6 @@ static int __init omap_sham_mod_init(void)
{
pr_info("loading %s driver\n", "omap-sham");
- if (!cpu_class_is_omap2() ||
- (omap_type() != OMAP2_DEVICE_TYPE_SEC &&
- omap_type() != OMAP2_DEVICE_TYPE_EMU)) {
- pr_err("Unsupported cpu\n");
- return -ENODEV;
- }
-
return platform_driver_register(&omap_sham_driver);
}
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 0b4fa50..56d9253 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -19,9 +19,14 @@
#include "virt-dma.h"
-#include
#include
+#ifdef CONFIG_ARCH_OMAP2PLUS
+#define dma_omap2plus()1
+#else
+#define dma_omap2plus()0
+#endif
+
struct omap_dmadev {
struct dma_device ddev;
spinlock_t lock;
@@ -438,7 +443,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_dma_cyclic(
omap_disable_dma_irq(c->dma_ch, OMAP_DMA_BLOCK_IRQ);
}
- if (!cpu_class_is_omap1()) {
+ if (dma_omap2plus()) {
omap_set_dma_src_burst_mode(c->dma_ch, OMAP_DMA_DATA_BURST_16);
omap_set_dma_dest_burst_mode(c->dma_ch, OMAP_DMA_DATA_BURST_16);
}
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 85b164e..24df035 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -40,7 +40,6 @@
#include
#include
#include
-#include
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSSTATUS 0x0014
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 340874e..52977aa 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -32,9 +32,14 @@
#include
#include
-#include
#include "omap-pcm.h"
+#ifdef CONFIG_ARCH_OMAP1
+#define pcm_omap1510() cpu_is_omap1510()
+#else
+#define pcm_omap1510() 0
+#endif
+
static const struct snd_pcm_hardware omap_pcm_hardware = {
.info = SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
@@ -159,7 +164,7 @@ static snd_pcm_uframes_t omap_pcm_pointer(struct
snd_pcm_sub
[PATCH 2/2] ARM: OMAP: Split plat/cpu.h into local soc.h for mach-omap1 and mach-omap2
We want to remove plat/cpu.h. To do this, let's first split it to private soc.h to mach-omap1 and mach-omap2. We have to keep plat/cpu.h around until the remaining drivers are fixed, so let's include the local soc.h in plat/cpu.h and print a warning for drivers still including plat/cpu.h. Once the drivers are fixed not to include plat/cpu.h, we can remove the file (and the warning). This is needed for the ARM common zImage support. Signed-off-by: Tony Lindgren --- arch/arm/mach-omap1/clock.c |2 arch/arm/mach-omap1/clock_data.c|2 arch/arm/mach-omap1/i2c.c |2 arch/arm/mach-omap1/id.c|2 arch/arm/mach-omap1/include/mach/hardware.h |2 arch/arm/mach-omap1/include/mach/memory.h |2 arch/arm/mach-omap1/irq.c |2 arch/arm/mach-omap1/mcbsp.c |2 arch/arm/mach-omap1/soc.h | 229 +++ arch/arm/mach-omap2/board-3430sdp.c |1 arch/arm/mach-omap2/board-flash.c |2 arch/arm/mach-omap2/board-omap3beagle.c |1 arch/arm/mach-omap2/board-omap3evm.c|1 arch/arm/mach-omap2/board-zoom-display.c|1 arch/arm/mach-omap2/clock33xx_data.c|2 arch/arm/mach-omap2/clockdomain.c |1 arch/arm/mach-omap2/clockdomain.h |1 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |2 arch/arm/mach-omap2/clockdomains2420_data.c |1 arch/arm/mach-omap2/clockdomains2430_data.c |1 arch/arm/mach-omap2/clockdomains3xxx_data.c |1 arch/arm/mach-omap2/common.h|1 arch/arm/mach-omap2/display.c |1 arch/arm/mach-omap2/dma.c |1 arch/arm/mach-omap2/gpmc.c |1 arch/arm/mach-omap2/hsmmc.c |1 arch/arm/mach-omap2/i2c.c |1 arch/arm/mach-omap2/mux.c |1 arch/arm/mach-omap2/omap-mpuss-lowpower.c |1 arch/arm/mach-omap2/omap_hwmod.h|1 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |1 arch/arm/mach-omap2/omap_twl.c |1 arch/arm/mach-omap2/opp3xxx_data.c |1 arch/arm/mach-omap2/pm-debug.c |1 arch/arm/mach-omap2/pm.c|1 arch/arm/mach-omap2/pm24xx.c|1 arch/arm/mach-omap2/pm34xx.c|1 arch/arm/mach-omap2/pm44xx.c|1 arch/arm/mach-omap2/pmu.c |1 arch/arm/mach-omap2/powerdomain.h |2 arch/arm/mach-omap2/powerdomains2xxx_data.c |1 arch/arm/mach-omap2/prcm.c |1 arch/arm/mach-omap2/serial.c|1 arch/arm/mach-omap2/soc.h | 468 ++ arch/arm/mach-omap2/sr_device.c |2 arch/arm/mach-omap2/usb-host.c |1 arch/arm/mach-omap2/usb-musb.c |3 arch/arm/plat-omap/dma.c|4 arch/arm/plat-omap/i2c.c|4 arch/arm/plat-omap/include/plat/cpu.h | 562 --- arch/arm/plat-omap/sram.c |3 51 files changed, 749 insertions(+), 581 deletions(-) create mode 100644 arch/arm/mach-omap1/soc.h diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c index 4c895ef..9e74aa6 100644 --- a/arch/arm/mach-omap1/clock.c +++ b/arch/arm/mach-omap1/clock.c @@ -22,7 +22,7 @@ #include -#include +#include "soc.h" #include #include diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c index c78fb91..28aea55 100644 --- a/arch/arm/mach-omap1/clock_data.c +++ b/arch/arm/mach-omap1/clock_data.c @@ -22,7 +22,7 @@ #include /* for machine_is_* */ -#include +#include "soc.h" #include #include/* for OTG_BASE */ diff --git a/arch/arm/mach-omap1/i2c.c b/arch/arm/mach-omap1/i2c.c index a6f465a..32bcbb8 100644 --- a/arch/arm/mach-omap1/i2c.c +++ b/arch/arm/mach-omap1/i2c.c @@ -21,7 +21,7 @@ #include #include -#include +#include "soc.h" #include "../plat-omap/i2c.h" diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c index a1b846a..52de382 100644 --- a/arch/arm/mach-omap1/id.c +++ b/arch/arm/mach-omap1/id.c @@ -17,7 +17,7 @@ #include #include -#include +#include "soc.h" #include diff --git a/arch/arm/mach-omap1/include/mach/hardware.h b/arch/arm/mach-omap1/include/mach/hardware.h index 2a4eb19..dc3237b 100644 --- a/arch/arm/mach-omap1/include/mach/hardware.h +++ b/arch/arm/mach-omap1/include/mach/hardware.h @@ -39,7 +39,7 @@ #include #ifndef __ASSEMBLER__ #include -#include +#include "../../mach-omap1/soc.h" /* * NOTE: Please use ioremap + __raw_read/write where possible instead of these diff --git a/arch/arm/mach-omap1/include/mach/memory.h b/arch/arm/mach-omap1/include/mach/memory.h index 901082d..351ae4f 100644 --- a/arch/arm/ma
[PATCH 0/2] omap plat/cpu.h removal for v3.8 merge window
Hi all, These two patches for v3.8 merge window make plat/cpu.h local to mach-omap1 and mach-omap2. We'll have to keep plat/cpu.h around until the merge window so drivers are fixed, but after that it can be removed. These patches are based on current linux next with the following patches: - [PATCH 00/16] More omap plat header cleanup for v3.8 merge window - [PATCH V2 0/7] ARM: OMAP: Move plat/dma*.h,omap-secure.h headers as part of single zImage work - [PATCH v2 1/5] [media] omap3isp: Fix compilation error in ispreg.h ... [PATCH v2 5/5] arm: omap: Move iopgtable header to drivers/iommu/ - [PATCH 0/6] ARM: OMAP: remove clock files in arch/arm/plat-omap Regards, Tony --- Tony Lindgren (2): ARM: OMAP: Trivial driver changes to remove include plat/cpu.h ARM: OMAP: Split plat/cpu.h into local soc.h for mach-omap1 and mach-omap2 arch/arm/mach-omap1/clock.c |2 arch/arm/mach-omap1/clock_data.c|2 arch/arm/mach-omap1/i2c.c |2 arch/arm/mach-omap1/id.c|2 arch/arm/mach-omap1/include/mach/hardware.h |2 arch/arm/mach-omap1/include/mach/memory.h |2 arch/arm/mach-omap1/irq.c |2 arch/arm/mach-omap1/mcbsp.c |2 arch/arm/mach-omap1/soc.h | 229 +++ arch/arm/mach-omap2/board-3430sdp.c |1 arch/arm/mach-omap2/board-flash.c |2 arch/arm/mach-omap2/board-omap3beagle.c |1 arch/arm/mach-omap2/board-omap3evm.c|1 arch/arm/mach-omap2/board-zoom-display.c|1 arch/arm/mach-omap2/clock33xx_data.c|2 arch/arm/mach-omap2/clockdomain.c |1 arch/arm/mach-omap2/clockdomain.h |1 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |2 arch/arm/mach-omap2/clockdomains2420_data.c |1 arch/arm/mach-omap2/clockdomains2430_data.c |1 arch/arm/mach-omap2/clockdomains3xxx_data.c |1 arch/arm/mach-omap2/common.h|1 arch/arm/mach-omap2/display.c |1 arch/arm/mach-omap2/dma.c |1 arch/arm/mach-omap2/gpmc.c |1 arch/arm/mach-omap2/hsmmc.c |1 arch/arm/mach-omap2/i2c.c |1 arch/arm/mach-omap2/mux.c |1 arch/arm/mach-omap2/omap-mpuss-lowpower.c |1 arch/arm/mach-omap2/omap_hwmod.h|1 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |1 arch/arm/mach-omap2/omap_twl.c |1 arch/arm/mach-omap2/opp3xxx_data.c |1 arch/arm/mach-omap2/pm-debug.c |1 arch/arm/mach-omap2/pm.c|1 arch/arm/mach-omap2/pm24xx.c|1 arch/arm/mach-omap2/pm34xx.c|1 arch/arm/mach-omap2/pm44xx.c|1 arch/arm/mach-omap2/pmu.c |1 arch/arm/mach-omap2/powerdomain.h |2 arch/arm/mach-omap2/powerdomains2xxx_data.c |1 arch/arm/mach-omap2/prcm.c |1 arch/arm/mach-omap2/serial.c|1 arch/arm/mach-omap2/soc.h | 468 ++ arch/arm/mach-omap2/sr_device.c |2 arch/arm/mach-omap2/usb-host.c |1 arch/arm/mach-omap2/usb-musb.c |3 arch/arm/plat-omap/dma.c|4 arch/arm/plat-omap/i2c.c|4 arch/arm/plat-omap/include/plat/cpu.h | 562 --- arch/arm/plat-omap/sram.c |3 drivers/char/hw_random/omap-rng.c |2 drivers/crypto/omap-aes.c |6 drivers/crypto/omap-sham.c |8 drivers/dma/omap-dma.c |9 drivers/mmc/host/omap_hsmmc.c |1 sound/soc/omap/omap-pcm.c |9 57 files changed, 763 insertions(+), 602 deletions(-) create mode 100644 arch/arm/mach-omap1/soc.h -- 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
Re: [PATCH 2/2] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
* Tomi Valkeinen [121008 05:32]: > Now that vrfb driver is not omap dependent anymore, we can move vrfb.h > from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h. Once the request_mem_region in patch 1/2 are handled: Acked-by: Tony Lindgren Also, can you please do a minimal immutable branch on -rc1 that we both can use? I need these into my cleanup branch for v3.8 merge window. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: VRFB: convert vrfb to platform device
* Tomi Valkeinen [121008 05:31]:
> This patch converts vrfb library into a platform device, in an effort to
> remove omap dependencies.
>
> The platform device is registered in arch/arm/plat-omap/fb.c and
> assigned resources depending on whether running on omap2 or omap3.
>
> The vrfb driver will parse those resources and use them to access vrfb
> configuration registers and the vrfb virtual rotation areas.
>
> Signed-off-by: Tomi Valkeinen
> Cc: Tony Lindgren
> ---
> arch/arm/plat-omap/fb.c| 53 +++
> drivers/video/omap2/vrfb.c | 124
> +---
> 2 files changed, 157 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
> index dd6f92c..d231912 100644
> --- a/arch/arm/plat-omap/fb.c
> +++ b/arch/arm/plat-omap/fb.c
> @@ -35,6 +35,59 @@
>
> #include
>
> +#if defined(CONFIG_OMAP2_VRFB)
> +static const struct resource omap2_vrfb_resources[] = {
> + DEFINE_RES_MEM(0x68008000u, 0x40),
> + DEFINE_RES_MEM(0x7000u, 0x400),
> + DEFINE_RES_MEM(0x7400u, 0x400),
> + DEFINE_RES_MEM(0x7800u, 0x400),
> + DEFINE_RES_MEM(0x7c00u, 0x400),
> +};
> +
> +static const struct resource omap3_vrfb_resources[] = {
> + DEFINE_RES_MEM(0x6C000180u, 0xc0),
> + DEFINE_RES_MEM(0x7000u, 0x400),
> + DEFINE_RES_MEM(0x7400u, 0x400),
> + DEFINE_RES_MEM(0x7800u, 0x400),
> + DEFINE_RES_MEM(0x7c00u, 0x400),
> + DEFINE_RES_MEM(0xe000u, 0x400),
> + DEFINE_RES_MEM(0xe400u, 0x400),
> + DEFINE_RES_MEM(0xe800u, 0x400),
> + DEFINE_RES_MEM(0xec00u, 0x400),
> + DEFINE_RES_MEM(0xf000u, 0x400),
> + DEFINE_RES_MEM(0xf400u, 0x400),
> + DEFINE_RES_MEM(0xf800u, 0x400),
> + DEFINE_RES_MEM(0xfc00u, 0x400),
> +};
Maybe add comments describing what these register are in case
we have a framework handling them at some point later on?
> --- a/drivers/video/omap2/vrfb.c
> +++ b/drivers/video/omap2/vrfb.c
> +#define SMS_ROT_CONTROL(context) (0x0 + 0x10 * context)
> +#define SMS_ROT_SIZE(context)(0x4 + 0x10 * context)
> +#define SMS_ROT_PHYSICAL_BA(context) (0x8 + 0x10 * context)
> +#define SMS_ROT_VIRT_BASE(rot) (0x100 * (rot))
Can you please also remove the old SMS defines and functions
so other code won't start tinkering with them?
> +static int __init vrfb_probe(struct platform_device *pdev)
> +{
> + struct resource *mem;
> + int i;
> +
> + /* first resource is the register res, the rest are vrfb contexts */
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!mem) {
> + dev_err(&pdev->dev, "can't get vrfb base address\n");
> + return -EINVAL;
> + }
Now that we assume vrfb is the only user of this, so you must do
request_mem_region here as that's the only protection we have.
If that fails here, then we know something is wrong.
> + vrfb_base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
> + if (!vrfb_base) {
> + dev_err(&pdev->dev, "can't ioremap vrfb memory\n");
> + return -ENOMEM;
> + }
> +
> + num_ctxs = pdev->num_resources - 1;
> +
> + ctxs = devm_kzalloc(&pdev->dev,
> + sizeof(struct vrfb_ctx) * num_ctxs,
> + GFP_KERNEL);
> +
> + if (!ctxs)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_ctxs; ++i) {
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
> + if (!mem) {
> + dev_err(&pdev->dev, "can't get vrfb ctx %d address\n",
> + i);
> + return -EINVAL;
> + }
> +
> + ctxs[i].base = mem->start;
> + }
And request_mem_region must also be done for these registers to make
sure no other code is using them. Again, if it fails, something is
wrong.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] musb : remove generic_interrupt and have all drivers define the isr on their own. Remove some unneeded CONFIG_SOC_OMAP_3430 instances
* Philippe De Swert [121004 10:00]: > This patch is based on the discussion of a previous patch to fix an issue > where the omap2430 musb driver is not working for N9/N950. > > Moving all the interrupt handling to the devices. Avoids inclusion of generic > interrupt and breakage due to sometimes misleading CONFIG options. This makes > sure usb always works if on of the subdrivers is chosen. Tested on Nokia > N9/N950. > > Partially clean up CONFIG_SOC_OMAP3430 which is not necessary in the cases > where I removed it. Also helps with the removal work of those options that > Tony Lindgren predicted would happen at some point. Thanks looks OK to me: Acked-by: Tony Lindgren -- 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 07/16] ARM: OMAP: Make plat/sram.h local to plat-omap
* Jon Hunter [121005 07:00]: > Hi Tony, > > On 10/04/2012 05:04 PM, Tony Lindgren wrote: > > We can move this from plat to be local to plat-omap > > for common ARM zImage support. > > > > Signed-off-by: Tony Lindgren > > --- > > arch/arm/mach-omap1/clock.c |3 - > > arch/arm/mach-omap1/clock_data.c |3 - > > arch/arm/mach-omap1/devices.c|2 > > arch/arm/mach-omap1/pm.c |3 - > > arch/arm/mach-omap2/clkt2xxx_dpllcore.c |3 - > > arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |3 - > > arch/arm/mach-omap2/clkt34xx_dpll3m2.c |3 - > > arch/arm/mach-omap2/io.c |3 - > > arch/arm/mach-omap2/omap4-common.c |4 - > > arch/arm/mach-omap2/pm24xx.c |3 - > > arch/arm/mach-omap2/pm34xx.c |3 - > > arch/arm/mach-omap2/sdrc.c |2 > > arch/arm/mach-omap2/sdrc2xxx.c |2 > > arch/arm/mach-omap2/sleep34xx.S |2 > > arch/arm/plat-omap/common.h |2 > > arch/arm/plat-omap/include/plat/sram.h | 105 > > - > > arch/arm/plat-omap/sram.c|1 > > arch/arm/plat-omap/sram.h| 109 > > +- > > 18 files changed, 130 insertions(+), 126 deletions(-) > > delete mode 100644 arch/arm/plat-omap/include/plat/sram.h > > > > diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c > > index 638f407..b15d4ee 100644 > > --- a/arch/arm/mach-omap1/clock.c > > +++ b/arch/arm/mach-omap1/clock.c > > @@ -24,11 +24,12 @@ > > #include > > #include > > #include > > -#include > > #include > > > > #include > > > > +#include "../plat-omap/sram.h" > > Any reason why you did not put this in > arch/arm/plat-omap/include/plat-omap/ like we were discussing for dma > and dmtimers headers? Then it can be just "#include ". > Just curious ... Because plat-omap/sram.h is still available for (mis)use by drivers and there's no need to expose it. Eventually our plat-omap/sram.c will be converted to be just a device driver using the common sram driver. Then it will need a local sram.h and include/platform_data/sram-omap.h for the legacy non-dt boot. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/32 v3] USB: ohci: merge ohci_finish_controller_resume with ohci_resume
Merge ohci_finish_controller_resume with ohci_resume as suggested by Alan
Stern. Since ohci_finish_controller_resume no longer exists, update the
various OHCI drivers to call ohci_resume() instead. Some drivers used to set
themselves the bit HCD_FLAG_HW_ACCESSIBLE, which is now handled by
ohci_resume().
Acked-by: Jingoo Han
Acked-by: Nicolas Ferre
Signed-off-by: Florian Fainelli
---
Changes in v3:
- rebased against greg's latest usb-next
Changes in v2:
- added Nicolas and Jingoo's Acked-by
drivers/usb/host/ohci-at91.c |2 +-
drivers/usb/host/ohci-ep93xx.c |2 +-
drivers/usb/host/ohci-exynos.c |5 +
drivers/usb/host/ohci-hcd.c | 41 +++--
drivers/usb/host/ohci-hub.c | 42 --
drivers/usb/host/ohci-omap.c |2 +-
drivers/usb/host/ohci-platform.c |2 +-
drivers/usb/host/ohci-pxa27x.c |2 +-
drivers/usb/host/ohci-s3c2410.c |3 +--
drivers/usb/host/ohci-spear.c|2 +-
drivers/usb/host/ohci-tmio.c |2 +-
11 files changed, 48 insertions(+), 57 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 0bf72f9..908d84a 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -705,7 +705,7 @@ static int ohci_hcd_at91_drv_resume(struct platform_device
*pdev)
if (!clocked)
at91_start_clock();
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
#else
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index dbfbd1d..a982f04 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -194,7 +194,7 @@ static int ohci_hcd_ep93xx_drv_resume(struct
platform_device *pdev)
ep93xx_start_hc(&pdev->dev);
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
#endif
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 20a5008..929a494 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -252,10 +252,7 @@ static int exynos_ohci_resume(struct device *dev)
if (pdata && pdata->phy_init)
pdata->phy_init(pdev, S5P_USB_PHY_HOST);
- /* Mark hardware accessible again as we are out of D3 state by now */
- set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
-
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 31a4616..8e17f17 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1007,13 +1007,50 @@ static int __maybe_unused ohci_suspend(struct usb_hcd
*hcd, bool do_wakeup)
static int __maybe_unused ohci_resume(struct usb_hcd *hcd, bool hibernated)
{
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ int port;
+ boolneed_reinit = false;
+
set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
/* Make sure resume from hibernation re-enumerates everything */
if (hibernated)
- ohci_usb_reset(hcd_to_ohci(hcd));
+ ohci_usb_reset(ohci);
+
+ /* See if the controller is already running or has been reset */
+ ohci->hc_control = ohci_readl(ohci, &ohci->regs->control);
+ if (ohci->hc_control & (OHCI_CTRL_IR | OHCI_SCHED_ENABLES)) {
+ need_reinit = true;
+ } else {
+ switch (ohci->hc_control & OHCI_CTRL_HCFS) {
+ case OHCI_USB_OPER:
+ case OHCI_USB_RESET:
+ need_reinit = true;
+ }
+ }
+
+ /* If needed, reinitialize and suspend the root hub */
+ if (need_reinit) {
+ spin_lock_irq(&ohci->lock);
+ ohci_rh_resume(ohci);
+ ohci_rh_suspend(ohci, 0);
+ spin_unlock_irq(&ohci->lock);
+ }
+
+ /* Normally just turn on port power and enable interrupts */
+ else {
+ ohci_dbg(ohci, "powerup ports\n");
+ for (port = 0; port < ohci->num_ports; port++)
+ ohci_writel(ohci, RH_PS_PPS,
+ &ohci->regs->roothub.portstatus[port]);
+
+ ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrenable);
+ ohci_readl(ohci, &ohci->regs->intrenable);
+ msleep(20);
+ }
+
+ usb_hcd_resume_root_hub(hcd);
- ohci_finish_controller_resume(hcd);
return 0;
}
diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index 2f3619e..db09dae 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -316,48 +316,6 @@ static int ohci_bus_resume (struct usb_hcd *hcd)
return rc;
}
-/* Carry out the final steps of resuming the controller device */
-static void __maybe_unused
[PATCH 2/2] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.
Signed-off-by: Tomi Valkeinen
Cc: Tony Lindgren
Cc: Vaibhav Hiremath
---
arch/arm/plat-omap/include/plat/vrfb.h| 66 -
drivers/media/video/omap/omap_vout.c |2 +-
drivers/media/video/omap/omap_vout_vrfb.c |2 +-
drivers/media/video/omap/omap_voutdef.h |2 +-
drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +-
drivers/video/omap2/omapfb/omapfb-main.c |2 +-
drivers/video/omap2/omapfb/omapfb-sysfs.c |2 +-
drivers/video/omap2/vrfb.c|2 +-
include/video/omapvrfb.h | 66 +
9 files changed, 73 insertions(+), 73 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
create mode 100644 include/video/omapvrfb.h
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h
b/arch/arm/plat-omap/include/plat/vrfb.h
deleted file mode 100644
index 3792bde..000
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
- * VRFB Rotation Engine
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __OMAP_VRFB_H__
-#define __OMAP_VRFB_H__
-
-#define OMAP_VRFB_LINE_LEN 2048
-
-struct vrfb {
- u8 context;
- void __iomem *vaddr[4];
- unsigned long paddr[4];
- u16 xres;
- u16 yres;
- u16 xoffset;
- u16 yoffset;
- u8 bytespp;
- bool yuv_mode;
-};
-
-#ifdef CONFIG_OMAP2_VRFB
-extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
-extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
-extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
- u8 bytespp);
-extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
-extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
-extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
- u16 width, u16 height,
- unsigned bytespp, bool yuv_mode);
-extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
-extern void omap_vrfb_restore_context(void);
-
-#else
-static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
-static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
-static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
- u8 bytespp) {}
-static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
- { return 0; }
-static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
- { return 0; }
-static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
- u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
-static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
- { return 0; }
-static inline void omap_vrfb_restore_context(void) {}
-#endif
-#endif /* __VRFB_H */
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index f721fd2..940f39f 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -45,7 +45,7 @@
#include
#include
-#include
+#include
#include
#include "omap_voutlib.h"
diff --git a/drivers/media/video/omap/omap_vout_vrfb.c
b/drivers/media/video/omap/omap_vout_vrfb.c
index 4be26abf6c..6c37f92 100644
--- a/drivers/media/video/omap/omap_vout_vrfb.c
+++ b/drivers/media/video/omap/omap_vout_vrfb.c
@@ -17,7 +17,7 @@
#include
#include
-#include
+#include
#include "omap_voutdef.h"
#include "omap_voutlib.h"
diff --git a/drivers/media/video/omap/omap_voutdef.h
b/drivers/media/video/omap/omap_voutdef.h
index 27a95d2..9ccfe1f 100644
--- a/drivers/media/video/omap/omap_voutdef.h
+++ b/drivers/media/video/omap/omap_voutdef.h
@@ -12,7 +12,7 @@
#define OMAP_VOUTDEF_H
#include
-#include
+#include
#define YUYV_BPP2
#define RGB565_BPP 2
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 606b89f..55a39be 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -30,7 +30,7 @@
#include
#include
-#include
+#include
#include
#include "omapfb.h"
diff --
[PATCH 1/2] OMAP: VRFB: convert vrfb to platform device
This patch converts vrfb library into a platform device, in an effort to
remove omap dependencies.
The platform device is registered in arch/arm/plat-omap/fb.c and
assigned resources depending on whether running on omap2 or omap3.
The vrfb driver will parse those resources and use them to access vrfb
configuration registers and the vrfb virtual rotation areas.
Signed-off-by: Tomi Valkeinen
Cc: Tony Lindgren
---
arch/arm/plat-omap/fb.c| 53 +++
drivers/video/omap2/vrfb.c | 124 +---
2 files changed, 157 insertions(+), 20 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index dd6f92c..d231912 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -35,6 +35,59 @@
#include
+#if defined(CONFIG_OMAP2_VRFB)
+static const struct resource omap2_vrfb_resources[] = {
+ DEFINE_RES_MEM(0x68008000u, 0x40),
+ DEFINE_RES_MEM(0x7000u, 0x400),
+ DEFINE_RES_MEM(0x7400u, 0x400),
+ DEFINE_RES_MEM(0x7800u, 0x400),
+ DEFINE_RES_MEM(0x7c00u, 0x400),
+};
+
+static const struct resource omap3_vrfb_resources[] = {
+ DEFINE_RES_MEM(0x6C000180u, 0xc0),
+ DEFINE_RES_MEM(0x7000u, 0x400),
+ DEFINE_RES_MEM(0x7400u, 0x400),
+ DEFINE_RES_MEM(0x7800u, 0x400),
+ DEFINE_RES_MEM(0x7c00u, 0x400),
+ DEFINE_RES_MEM(0xe000u, 0x400),
+ DEFINE_RES_MEM(0xe400u, 0x400),
+ DEFINE_RES_MEM(0xe800u, 0x400),
+ DEFINE_RES_MEM(0xec00u, 0x400),
+ DEFINE_RES_MEM(0xf000u, 0x400),
+ DEFINE_RES_MEM(0xf400u, 0x400),
+ DEFINE_RES_MEM(0xf800u, 0x400),
+ DEFINE_RES_MEM(0xfc00u, 0x400),
+};
+
+static int __init omap_init_vrfb(void)
+{
+ struct platform_device *pdev;
+ const struct resource *res;
+ unsigned int num_res;
+
+ if (cpu_is_omap24xx()) {
+ res = omap2_vrfb_resources;
+ num_res = ARRAY_SIZE(omap2_vrfb_resources);
+ } else if (cpu_is_omap34xx()) {
+ res = omap3_vrfb_resources;
+ num_res = ARRAY_SIZE(omap3_vrfb_resources);
+ } else {
+ return 0;
+ }
+
+ pdev = platform_device_register_resndata(NULL, "omapvrfb", -1,
+ res, num_res, NULL, 0);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+ else
+ return 0;
+}
+
+arch_initcall(omap_init_vrfb);
+#endif
+
#if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE)
static bool omapfb_lcd_configured;
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 7e99022..c072e37 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -26,9 +26,9 @@
#include
#include
#include
+#include
#include
-#include
#ifdef DEBUG
#define DBG(format, ...) pr_debug("VRFB: " format, ## __VA_ARGS__)
@@ -36,10 +36,10 @@
#define DBG(format, ...)
#endif
-#define SMS_ROT_VIRT_BASE(context, rot) \
- (((context >= 4) ? 0xD000 : 0x7000) \
-+ (0x400 * (context)) \
-+ (0x100 * (rot)))
+#define SMS_ROT_CONTROL(context) (0x0 + 0x10 * context)
+#define SMS_ROT_SIZE(context) (0x4 + 0x10 * context)
+#define SMS_ROT_PHYSICAL_BA(context) (0x8 + 0x10 * context)
+#define SMS_ROT_VIRT_BASE(rot) (0x100 * (rot))
#define OMAP_VRFB_SIZE (2048 * 2048 * 4)
@@ -53,10 +53,16 @@
#define SMS_PW_OFFSET 4
#define SMS_PS_OFFSET 0
-#define VRFB_NUM_CTXS 12
/* bitmap of reserved contexts */
static unsigned long ctx_map;
+struct vrfb_ctx {
+ u32 base;
+ u32 physical_ba;
+ u32 control;
+ u32 size;
+};
+
static DEFINE_MUTEX(ctx_lock);
/*
@@ -65,17 +71,32 @@ static DEFINE_MUTEX(ctx_lock);
* we don't need locking, since no drivers will run until after the wake-up
* has finished.
*/
-static struct {
- u32 physical_ba;
- u32 control;
- u32 size;
-} vrfb_hw_context[VRFB_NUM_CTXS];
+
+static void __iomem *vrfb_base;
+
+static int num_ctxs;
+static struct vrfb_ctx *ctxs;
+
+static void omap2_sms_write_rot_control(u32 val, unsigned ctx)
+{
+ __raw_writel(val, vrfb_base + SMS_ROT_CONTROL(ctx));
+}
+
+static void omap2_sms_write_rot_size(u32 val, unsigned ctx)
+{
+ __raw_writel(val, vrfb_base + SMS_ROT_SIZE(ctx));
+}
+
+static void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
+{
+ __raw_writel(val, vrfb_base + SMS_ROT_PHYSICAL_BA(ctx));
+}
static inline void restore_hw_context(int ctx)
{
- omap2_sms_write_rot_control(vrfb_hw_context[ctx].control, ctx);
- omap2_sms_write_rot_size(vrfb_hw_context[ctx].size, ctx);
- omap2_sms_write_rot_physical_ba(vrfb_hw_context[ctx].physical_ba, ctx);
+ omap2_sms_write_rot_control(ctxs[ctx].control, ctx);
+ omap2_sms_write_rot_size(ctxs[ctx].size
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On Mon, Oct 08, 2012 at 12:01:09PM +0100, Dave Martin wrote: > On Sat, Oct 06, 2012 at 09:00:32AM -0700, Tony Lindgren wrote: > > * Marc Zyngier [121006 03:19]: > > > > > > If so, that indicates some side effect of the safe_svcmode_maskall macro, > > > and I suspect the "movs pc, lr" bit. > > > > > > Can you try the attached patch? It basically falls back to the previous > > > behaviour if not entered in HYP mode. > > ... > > > > > diff --git a/arch/arm/include/asm/assembler.h > > > b/arch/arm/include/asm/assembler.h > > > index 658a15d..b21b97f 100644 > > > --- a/arch/arm/include/asm/assembler.h > > > +++ b/arch/arm/include/asm/assembler.h > > > @@ -254,16 +254,17 @@ > > > mov lr , \reg > > > and lr , lr , #MODE_MASK > > > cmp lr , #HYP_MODE > > > - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT > > > + orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT > > > bic \reg , \reg , #MODE_MASK > > > orr \reg , \reg , #SVC_MODE > > > THUMB( orr \reg , \reg , #PSR_T_BIT) > > > - msr spsr_cxsf, \reg > > > - adr lr, BSYM(2f) > > > bne 1f > > > + orr \reg, \reg, #PSR_A_BIT > > > + adr lr, BSYM(2f) > > > + msr spsr_cxsf, \reg > > > __MSR_ELR_HYP(14) > > > __ERET > > > -1: movspc, lr > > > +1: msr cpsr_c, \reg > > > 2: > > > .endm > > > > > > > The minimal version of this that still boots on my n800 is just > > the last change of the above patch: > > > > --- a/arch/arm/include/asm/assembler.h > > +++ b/arch/arm/include/asm/assembler.h > > @@ -263,7 +263,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT) > > bne 1f > > __MSR_ELR_HYP(14) > > __ERET > > -1: movspc, lr > > +1: msr cpsr_c, \reg > > 2: > > .endm > > > > In an attempt to narrow this down... > > Can you follow this (i.e., _after_ a known successful switch to SVC mode) > > (a) > mrs \reg, cpsr > msr spsr_cxsf, \reg > adr \reg, 3f > movspc, lr > 3: > > and (b) > > mrs \reg, cpsr > orr \reg, \reg, #CPSR_A_BIT > msr cpsr_cxsf, \reg > > and (c) > > mrs \reg, cpsr > orr \reg, \reg, #CPSR_A_BIT > msr spsr_cxsf, \reg > adr \reg, 3f > movspc, lr > 3: > > > > > If only (a) works, this would suggest that the attempt to set the A bit > is causing the problem. > > If only (b) works, this suggests that the A bit is OK but that some > invalid hardware state, or something else we don't understand, is causing > exception returns to fail in general. > > If (a) and (b) work but (c) fails, this suggests that specifically > trying to set the A bit via an exception return is problematic. > > If all of them work then this suggests some invalid hardware state or > something else we don't understand, but which is cleared by the initial > msr cpsr_c which clobbers the processor mode. Marc Z also just pointed out to me that there is one architecturally valid explanation for why the movs route could fail: if the kernel is entered in System mode for some reason -- this causes msr spsr and movs pc to become UNPREDICTABLE. If this is the explanation, then (a), (b) and (c) should all work, provided the CPU has already been forced out of System mode. Of course, we're not supposed to be entered in System mode ... but since the whole purpose of this code is to force us into a sane state, we should work around it anyway. I think Marc is busy rolling a patch for that. Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On 08/10/12 12:01, Dave Martin wrote: > On Sat, Oct 06, 2012 at 09:00:32AM -0700, Tony Lindgren wrote: >> * Marc Zyngier [121006 03:19]: >>> >>> If so, that indicates some side effect of the safe_svcmode_maskall macro, >>> and I suspect the "movs pc, lr" bit. >>> >>> Can you try the attached patch? It basically falls back to the previous >>> behaviour if not entered in HYP mode. >> ... >> >>> diff --git a/arch/arm/include/asm/assembler.h >>> b/arch/arm/include/asm/assembler.h >>> index 658a15d..b21b97f 100644 >>> --- a/arch/arm/include/asm/assembler.h >>> +++ b/arch/arm/include/asm/assembler.h >>> @@ -254,16 +254,17 @@ >>> mov lr , \reg >>> and lr , lr , #MODE_MASK >>> cmp lr , #HYP_MODE >>> - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT >>> + orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT >>> bic \reg , \reg , #MODE_MASK >>> orr \reg , \reg , #SVC_MODE >>> THUMB( orr \reg , \reg , #PSR_T_BIT) >>> - msr spsr_cxsf, \reg >>> - adr lr, BSYM(2f) >>> bne 1f >>> + orr \reg, \reg, #PSR_A_BIT >>> + adr lr, BSYM(2f) >>> + msr spsr_cxsf, \reg >>> __MSR_ELR_HYP(14) >>> __ERET >>> -1: movspc, lr >>> +1: msr cpsr_c, \reg >>> 2: >>> .endm >>> >> >> The minimal version of this that still boots on my n800 is just >> the last change of the above patch: >> >> --- a/arch/arm/include/asm/assembler.h >> +++ b/arch/arm/include/asm/assembler.h >> @@ -263,7 +263,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT) >> bne 1f >> __MSR_ELR_HYP(14) >> __ERET >> -1: movspc, lr >> +1: msr cpsr_c, \reg >> 2: >> .endm >> > > In an attempt to narrow this down... > > Can you follow this (i.e., _after_ a known successful switch to SVC mode) > > (a) > mrs \reg, cpsr > msr spsr_cxsf, \reg > adr \reg, 3f > movspc, lr > 3: > > and (b) > > mrs \reg, cpsr > orr \reg, \reg, #CPSR_A_BIT > msr cpsr_cxsf, \reg > > and (c) > > mrs \reg, cpsr > orr \reg, \reg, #CPSR_A_BIT > msr spsr_cxsf, \reg > adr \reg, 3f > movspc, lr > 3: > > > > > If only (a) works, this would suggest that the attempt to set the A bit > is causing the problem. > > If only (b) works, this suggests that the A bit is OK but that some > invalid hardware state, or something else we don't understand, is causing > exception returns to fail in general. > > If (a) and (b) work but (c) fails, this suggests that specifically > trying to set the A bit via an exception return is problematic. > > If all of them work then this suggests some invalid hardware state or > something else we don't understand, but which is cleared by the initial > msr cpsr_c which clobbers the processor mode. Playing with an Integrator-CP with a 1136 tile, the only way I could cause the thing to fail was to boot the thing in SYSTEM mode. Tony, can you possibly also try the attached patch? Thanks, M. -- Jazz is not dead. It just smells funny...diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 683a1e6..7714ec7 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -253,6 +253,8 @@ mrs \reg , cpsr mov lr , \reg and lr , lr , #MODE_MASK + cmp lr , #SYSTEM_MODE /* Yet another braindead platform? */ + beq omgsys cmp lr , #HYP_MODE orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT bic \reg , \reg , #MODE_MASK @@ -264,6 +266,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT ) __MSR_ELR_HYP(14) __ERET 1: movs pc, lr +omgsys: msr cpsr_c, \reg 2: .endm
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On Sat, Oct 06, 2012 at 09:00:32AM -0700, Tony Lindgren wrote: > * Marc Zyngier [121006 03:19]: > > > > If so, that indicates some side effect of the safe_svcmode_maskall macro, > > and I suspect the "movs pc, lr" bit. > > > > Can you try the attached patch? It basically falls back to the previous > > behaviour if not entered in HYP mode. > ... > > > diff --git a/arch/arm/include/asm/assembler.h > > b/arch/arm/include/asm/assembler.h > > index 658a15d..b21b97f 100644 > > --- a/arch/arm/include/asm/assembler.h > > +++ b/arch/arm/include/asm/assembler.h > > @@ -254,16 +254,17 @@ > > mov lr , \reg > > and lr , lr , #MODE_MASK > > cmp lr , #HYP_MODE > > - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT > > + orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT > > bic \reg , \reg , #MODE_MASK > > orr \reg , \reg , #SVC_MODE > > THUMB( orr \reg , \reg , #PSR_T_BIT) > > - msr spsr_cxsf, \reg > > - adr lr, BSYM(2f) > > bne 1f > > + orr \reg, \reg, #PSR_A_BIT > > + adr lr, BSYM(2f) > > + msr spsr_cxsf, \reg > > __MSR_ELR_HYP(14) > > __ERET > > -1: movspc, lr > > +1: msr cpsr_c, \reg > > 2: > > .endm > > > > The minimal version of this that still boots on my n800 is just > the last change of the above patch: > > --- a/arch/arm/include/asm/assembler.h > +++ b/arch/arm/include/asm/assembler.h > @@ -263,7 +263,7 @@ THUMB(orr \reg , \reg , #PSR_T_BIT) > bne 1f > __MSR_ELR_HYP(14) > __ERET > -1: movspc, lr > +1: msr cpsr_c, \reg > 2: > .endm > In an attempt to narrow this down... Can you follow this (i.e., _after_ a known successful switch to SVC mode) (a) mrs \reg, cpsr msr spsr_cxsf, \reg adr \reg, 3f movspc, lr 3: and (b) mrs \reg, cpsr orr \reg, \reg, #CPSR_A_BIT msr cpsr_cxsf, \reg and (c) mrs \reg, cpsr orr \reg, \reg, #CPSR_A_BIT msr spsr_cxsf, \reg adr \reg, 3f movspc, lr 3: If only (a) works, this would suggest that the attempt to set the A bit is causing the problem. If only (b) works, this suggests that the A bit is OK but that some invalid hardware state, or something else we don't understand, is causing exception returns to fail in general. If (a) and (b) work but (c) fails, this suggests that specifically trying to set the A bit via an exception return is problematic. If all of them work then this suggests some invalid hardware state or something else we don't understand, but which is cleared by the initial msr cpsr_c which clobbers the processor mode. Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] usb: dwc3-omap: add dt support
This patch series adds dt support to dwc3 core and fixes few minor stuff in dwc3-omap glue to get dwc3 working. While at that it also uses *of_platform* to create the child device (dwc3-core) and fixes to use runtime API's to enable clock and write to SYSCONFIG register. Changes from v2: * Fixed Sergei comment to use of_property_read_u32 insted of of_get_property Changes from v1: * made device_for_each_child() as a seperate patch * made all other minor fixes wrt typos and function renames This patch series is developed on: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git dwc3 Kishon Vijay Abraham I (7): usb: dwc3-omap: use device_for_each_child to handle child removal usb: dwc3-omap: use of_platform API to create dwc3 core pdev usb: dwc3-omap: use runtime API's to enable clocks usb: dwc3-omap: Remove explicit writes to SYSCONFIG register usb: dwc3-omap: Add an API to write to dwc mailbox usb: dwc3-omap: Minor fixes to get dt working usb: dwc3: core: add dt support for dwc3 core Documentation/devicetree/bindings/usb/dwc3.txt | 23 drivers/usb/dwc3/core.c| 14 +- drivers/usb/dwc3/dwc3-omap.c | 173 +--- include/linux/usb/dwc3-omap.h | 30 4 files changed, 160 insertions(+), 80 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt create mode 100644 include/linux/usb/dwc3-omap.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/7] usb: dwc3-omap: Add an API to write to dwc mailbox
Add an API in the omap glue layer to write to the mailbox register which
can be used by comparator driver(twl). To pass the detection of the attached
device (signified by VBUS, ID) to the dwc3 core, dwc3 core has to write
to the mailbox regiter.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/dwc3-omap.c | 59 +
include/linux/usb/dwc3-omap.h | 30 +
2 files changed, 89 insertions(+)
create mode 100644 include/linux/usb/dwc3-omap.h
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index d417bec..c19affa 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -126,6 +127,8 @@ struct dwc3_omap {
u32 dma_status:1;
};
+struct dwc3_omap *_omap;
+
static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
{
return readl(base + offset);
@@ -136,6 +139,56 @@ static inline void dwc3_omap_writel(void __iomem *base,
u32 offset, u32 value)
writel(value, base + offset);
}
+void dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+{
+ u32 val;
+ struct dwc3_omap*omap = _omap;
+
+ switch (status) {
+ case OMAP_DWC3_ID_GROUND:
+ dev_dbg(omap->dev, "ID GND\n");
+
+ val = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
+ val &= ~(USBOTGSS_UTMI_OTG_STATUS_IDDIG
+ | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_SESSEND);
+ val |= USBOTGSS_UTMI_OTG_STATUS_SESSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_POWERPRESENT;
+ dwc3_omap_writel(omap->base, USBOTGSS_UTMI_OTG_STATUS, val);
+ break;
+
+ case OMAP_DWC3_VBUS_VALID:
+ dev_dbg(omap->dev, "VBUS Connect\n");
+
+ val = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
+ val &= ~USBOTGSS_UTMI_OTG_STATUS_SESSEND;
+ val |= USBOTGSS_UTMI_OTG_STATUS_IDDIG
+ | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_SESSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_POWERPRESENT;
+ dwc3_omap_writel(omap->base, USBOTGSS_UTMI_OTG_STATUS, val);
+ break;
+
+ case OMAP_DWC3_ID_FLOAT:
+ case OMAP_DWC3_VBUS_OFF:
+ dev_dbg(omap->dev, "VBUS Disconnect\n");
+
+ val = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
+ val &= ~(USBOTGSS_UTMI_OTG_STATUS_SESSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_POWERPRESENT);
+ val |= USBOTGSS_UTMI_OTG_STATUS_SESSEND
+ | USBOTGSS_UTMI_OTG_STATUS_IDDIG;
+ dwc3_omap_writel(omap->base, USBOTGSS_UTMI_OTG_STATUS, val);
+ break;
+
+ default:
+ dev_dbg(omap->dev, "ID float\n");
+ }
+
+ return;
+}
+EXPORT_SYMBOL_GPL(dwc3_omap_mailbox);
static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
{
@@ -256,6 +309,12 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
omap->irq = irq;
omap->base = base;
+ /*
+* REVISIT if we ever have two instances of the wrapper, we will be
+* in big trouble
+*/
+ _omap = omap;
+
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
diff --git a/include/linux/usb/dwc3-omap.h b/include/linux/usb/dwc3-omap.h
new file mode 100644
index 000..6ebcf73
--- /dev/null
+++ b/include/linux/usb/dwc3-omap.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2011-2012 by Texas Instruments
+ *
+ * The Inventra Controller Driver for Linux 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.
+ */
+
+#ifndef __DWC3_OMAP_H__
+#define __DWC3_OMAP_H__
+
+enum omap_dwc3_vbus_id_status {
+ OMAP_DWC3_UNKNOWN = 0,
+ OMAP_DWC3_ID_GROUND,
+ OMAP_DWC3_ID_FLOAT,
+ OMAP_DWC3_VBUS_VALID,
+ OMAP_DWC3_VBUS_OFF,
+};
+
+#if (defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_DWC3_MODULE))
+void dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status);
+#else
+static inline void dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+{
+ return;
+}
+#endif
+
+#endif /* __DWC3_OMAP_H__ */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/7] usb: dwc3: core: add dt support for dwc3 core
Added dwc3 support for dwc3 core and update the documentation with
device tree binding information.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/dwc3.txt | 23 +++
drivers/usb/dwc3/core.c| 14 --
2 files changed, 35 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
new file mode 100644
index 000..9ec9316
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -0,0 +1,23 @@
+synopsys DWC3 CORE
+
+DWC3- USB3 CONTROLLER
+
+Required properties:
+ - compatible: must be "synopsys,dwc3"
+ - reg : Address and length of the register set for the device
+ - interrupts: Interrupts used by the dwc3 controller.
+ - interrupt-parent: the phandle for the interrupt controller that
+ services interrupts for this device.
+
+Optional properties:
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+
+This is usually a subnode to DWC3 glue to which it is connected.
+
+dwc3@4a03 {
+ compatible = "synopsys,dwc3";
+ reg = <0x4a03 0xcfff>;
+ interrupts = <0 92 4>
+ interrupt-parent = <&gic>
+ tx-fifo-resize;
+};
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 08a5738..4335a17 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -484,8 +484,7 @@ static int __devinit dwc3_probe(struct platform_device
*pdev)
else
dwc->maximum_speed = DWC3_DCFG_SUPERSPEED;
- if (of_get_property(node, "tx-fifo-resize", NULL))
- dwc->needs_fifo_resize = true;
+ dwc->needs_fifo_resize = of_property_read_bool(node, "tx-fifo-resize");
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
@@ -602,11 +601,22 @@ static int __devexit dwc3_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id of_dwc3_match[] = {
+ {
+ .compatible = "synopsys,dwc3"
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_dwc3_match);
+#endif
+
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
.remove = __devexit_p(dwc3_remove),
.driver = {
.name = "dwc3",
+ .of_match_table = of_match_ptr(of_dwc3_match),
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/7] usb: dwc3-omap: Remove explicit writes to SYSCONFIG register
The runtime API's takes care of setting the SYSCONFIG register with
appropriate values. Hence explicit writes to SYSCONFIG register is
removed.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/dwc3-omap.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 850a0cf..d417bec 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -77,23 +77,6 @@
/* SYSCONFIG REGISTER */
#define USBOTGSS_SYSCONFIG_DMADISABLE (1 << 16)
-#define USBOTGSS_SYSCONFIG_STANDBYMODE(x) ((x) << 4)
-
-#define USBOTGSS_STANDBYMODE_FORCE_STANDBY 0
-#define USBOTGSS_STANDBYMODE_NO_STANDBY1
-#define USBOTGSS_STANDBYMODE_SMART_STANDBY 2
-#define USBOTGSS_STANDBYMODE_SMART_WAKEUP 3
-
-#define USBOTGSS_STANDBYMODE_MASK (0x03 << 4)
-
-#define USBOTGSS_SYSCONFIG_IDLEMODE(x) ((x) << 2)
-
-#define USBOTGSS_IDLEMODE_FORCE_IDLE 0
-#define USBOTGSS_IDLEMODE_NO_IDLE 1
-#define USBOTGSS_IDLEMODE_SMART_IDLE 2
-#define USBOTGSS_IDLEMODE_SMART_WAKEUP 3
-
-#define USBOTGSS_IDLEMODE_MASK (0x03 << 2)
/* IRQ_EOI REGISTER */
#define USBOTGSS_IRQ_EOI_LINE_NUMBER (1 << 0)
@@ -309,15 +292,6 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
omap->dma_status = !!(reg & USBOTGSS_SYSCONFIG_DMADISABLE);
- /* Set No-Idle and No-Standby */
- reg &= ~(USBOTGSS_STANDBYMODE_MASK
- | USBOTGSS_IDLEMODE_MASK);
-
- reg |= (USBOTGSS_SYSCONFIG_STANDBYMODE(USBOTGSS_STANDBYMODE_NO_STANDBY)
- | USBOTGSS_SYSCONFIG_IDLEMODE(USBOTGSS_IDLEMODE_NO_IDLE));
-
- dwc3_omap_writel(omap->base, USBOTGSS_SYSCONFIG, reg);
-
ret = devm_request_irq(dev, omap->irq, dwc3_omap_interrupt, 0,
"dwc3-omap", omap);
if (ret) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/7] usb: dwc3-omap: use runtime API's to enable clocks
Before accessing any register, runtime API's should be invoked to enable
the clocks. runtime API's are added here to prevent abort during register
access.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/dwc3-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index cb4037a..850a0cf 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -272,6 +273,13 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
omap->irq = irq;
omap->base = base;
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (ret < 0) {
+ dev_err(dev, "get_sync failed with err %d\n", ret);
+ return ret;
+ }
+
reg = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
utmi_mode = of_get_property(node, "utmi-mode", &size);
@@ -348,6 +356,8 @@ static int __devinit dwc3_omap_probe(struct platform_device
*pdev)
static int __devexit dwc3_omap_remove(struct platform_device *pdev)
{
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
device_for_each_child(&pdev->dev, NULL, dwc3_omap_remove_core);
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/7] usb: dwc3-omap: use of_platform API to create dwc3 core pdev
Used of_platform_populate() to populate dwc3 core platform_device
from device tree data. Since now the allocation of unique device id is
handled be of_*, removed the call to dwc3_get_device_id.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/dwc3-omap.c | 52 --
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index e335da3..cb4037a 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include "core.h"
@@ -130,7 +131,6 @@ struct dwc3_omap {
/* device lock */
spinlock_t lock;
- struct platform_device *dwc3;
struct device *dev;
int irq;
@@ -218,12 +218,10 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
struct dwc3_omap_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
- struct platform_device *dwc3;
struct dwc3_omap*omap;
struct resource *res;
struct device *dev = &pdev->dev;
- int devid;
int size;
int ret = -ENOMEM;
int irq;
@@ -260,34 +258,19 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
return -ENOMEM;
}
- devid = dwc3_get_device_id();
- if (devid < 0)
- return -ENODEV;
-
- dwc3 = platform_device_alloc("dwc3", devid);
- if (!dwc3) {
- dev_err(dev, "couldn't allocate dwc3 device\n");
- goto err1;
- }
-
context = devm_kzalloc(dev, resource_size(res), GFP_KERNEL);
if (!context) {
dev_err(dev, "couldn't allocate dwc3 context memory\n");
- goto err2;
+ return -ENOMEM;
}
spin_lock_init(&omap->lock);
- dma_set_coherent_mask(&dwc3->dev, dev->coherent_dma_mask);
- dwc3->dev.parent = dev;
- dwc3->dev.dma_mask = dev->dma_mask;
- dwc3->dev.dma_parms = dev->dma_parms;
omap->resource_size = resource_size(res);
omap->context = context;
omap->dev = dev;
omap->irq = irq;
omap->base = base;
- omap->dwc3 = dwc3;
reg = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
@@ -332,7 +315,7 @@ static int __devinit dwc3_omap_probe(struct platform_device
*pdev)
if (ret) {
dev_err(dev, "failed to request IRQ #%d --> %d\n",
omap->irq, ret);
- goto err2;
+ return ret;
}
/* enable all IRQs */
@@ -351,35 +334,20 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
dwc3_omap_writel(omap->base, USBOTGSS_IRQENABLE_SET_1, reg);
- ret = platform_device_add_resources(dwc3, pdev->resource,
- pdev->num_resources);
- if (ret) {
- dev_err(dev, "couldn't add resources to dwc3 device\n");
- goto err2;
- }
-
- ret = platform_device_add(dwc3);
- if (ret) {
- dev_err(dev, "failed to register dwc3 device\n");
- goto err2;
+ if (node) {
+ ret = of_platform_populate(node, NULL, NULL, dev);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to add create dwc3 core\n");
+ return ret;
+ }
}
return 0;
-
-err2:
- platform_device_put(dwc3);
-
-err1:
- dwc3_put_device_id(devid);
-
- return ret;
}
static int __devexit dwc3_omap_remove(struct platform_device *pdev)
{
- struct dwc3_omap*omap = platform_get_drvdata(pdev);
-
- dwc3_put_device_id(omap->dwc3->id);
device_for_each_child(&pdev->dev, NULL, dwc3_omap_remove_core);
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/7] usb: dwc3-omap: Minor fixes to get dt working
Includes few minor fixes in dwc3-omap like populating the compatible
string in a correct way, extracting the utmi-mode property properly and
changing the index of get_irq since irq of core is removed from hwmod
entry.
Also updated the documentation with dwc3-omap device tree binding
information.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/dwc3-omap.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index c19affa..e5af74b 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -259,11 +259,10 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
struct resource *res;
struct device *dev = &pdev->dev;
- int size;
int ret = -ENOMEM;
int irq;
- const u32 *utmi_mode;
+ u32 utmi_mode;
u32 reg;
void __iomem*base;
@@ -277,13 +276,13 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, omap);
- irq = platform_get_irq(pdev, 1);
+ irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "missing IRQ resource\n");
return -EINVAL;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "missing memory base resource\n");
return -EINVAL;
@@ -324,9 +323,8 @@ static int __devinit dwc3_omap_probe(struct platform_device
*pdev)
reg = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
- utmi_mode = of_get_property(node, "utmi-mode", &size);
- if (utmi_mode && size == sizeof(*utmi_mode)) {
- reg |= *utmi_mode;
+ if (!of_property_read_u32(node, "utmi-mode", &utmi_mode)) {
+ reg |= utmi_mode;
} else {
if (!pdata) {
dev_dbg(dev, "missing platform data\n");
@@ -398,7 +396,7 @@ static int __devexit dwc3_omap_remove(struct
platform_device *pdev)
static const struct of_device_id of_dwc3_matach[] = {
{
- "ti,dwc3",
+ .compatible = "ti,dwc3"
},
{ },
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] usb: dwc3-omap: use device_for_each_child to handle child removal
Used device_for_each_child() to handle child device (dwc3 core) removal
during devexit of dwc3 omap.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/dwc3-omap.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 479dc04..e335da3 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -204,6 +204,15 @@ static irqreturn_t dwc3_omap_interrupt(int irq, void
*_omap)
return IRQ_HANDLED;
}
+static int dwc3_omap_remove_core(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ platform_device_unregister(pdev);
+
+ return 0;
+}
+
static int __devinit dwc3_omap_probe(struct platform_device *pdev)
{
struct dwc3_omap_data *pdata = pdev->dev.platform_data;
@@ -370,9 +379,8 @@ static int __devexit dwc3_omap_remove(struct
platform_device *pdev)
{
struct dwc3_omap*omap = platform_get_drvdata(pdev);
- platform_device_unregister(omap->dwc3);
-
dwc3_put_device_id(omap->dwc3->id);
+ device_for_each_child(&pdev->dev, NULL, dwc3_omap_remove_core);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] More omap plat header cleanup for v3.8 merge window
On Monday 08 October 2012 02:22 PM, Santosh Shilimkar wrote: Tony, On Friday 05 October 2012 03:34 AM, Tony Lindgren wrote: Hi all, Here are some more patches for early merging after -rc1 for v3.8 merge window to remove more plat includes for the ARM common zImage support. These are based on top of current linux next + kevin's cpufreq fixes. Have scanned the series and movement looks fine. For the SRAM movement, I just wanted to to check if the builds are fine with errata WA enabled for OMAP4. Do you have a branch where you are stacking up these patches? Found the branch 'tmp-testing-header-cleanup' which had these patches. Did few build test along with the errata related build. No issues seen. Feel free to add my ack for the series. Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
On Sat, Oct 6, 2012 at 1:46 PM, Wolfram Sang wrote: > On Thu, Sep 20, 2012 at 06:08:03PM +0200, Jean Pihet wrote: >> Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat >> API to the new PM QoS API. >> Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY >> class of PM QoS. The resulting MPU constraints are used by cpuidle to >> decide the next power state of the MPU subsystem. >> >> The I2C device latency timing is derived from the FIFO size and the >> clock speed and so is applicable to all OMAP SoCs. >> >> Signed-off-by: Jean Pihet > > Applied to -next, thanks! Thanks! Jean > > -- > Pengutronix e.K. | Wolfram Sang| > Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] More omap plat header cleanup for v3.8 merge window
Tony, On Friday 05 October 2012 03:34 AM, Tony Lindgren wrote: Hi all, Here are some more patches for early merging after -rc1 for v3.8 merge window to remove more plat includes for the ARM common zImage support. These are based on top of current linux next + kevin's cpufreq fixes. Have scanned the series and movement looks fine. For the SRAM movement, I just wanted to to check if the builds are fine with errata WA enabled for OMAP4. Do you have a branch where you are stacking up these patches? 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
AW: Beagleboard xM crashes when being set to 800MHz with smartreflex on linux-omap-3.6-rc6
> -Ursprüngliche Nachricht- > Von: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Gesendet: Dienstag, 2. Oktober 2012 02:00 > An: Maximilian Schwerin > Cc: linux-omap@vger.kernel.org > Betreff: Re: Beagleboard xM crashes when being set to 800MHz > with smartreflex on linux-omap-3.6-rc6 > > "Maximilian Schwerin" writes: > > > Hi, > > > > I've just built a linux-omap kernel at 3.6-rc6 using > omap2plus_defconfig > > as basis for the kernel config. > > > > When I enable smartreflex and switch to 800MHz via > > > > echo 1 > /sys/kernel/debug/smartreflex/smartreflex_core/autocomp > > echo 1 > /sys/kernel/debug/smartreflex/smartreflex_mpu_iva/autocomp > > cpufreq-set -f 800MHz > > > > the board crashes. If I switch to 800MHz and enable > smartreflex later > > nothing happens. This used to work in my 3.3 based kernel. > > SmartReflex is kwown to be unstable in mainline and there are several > errata that still need fixing for it to be stable. > > I strongly recommend you simply leave SR disabled. > > Kevin > So what does this mean for 800MHz and 1GHz? Is this not usable at all? Is there another kernel branch, that supports both frequencies? My customer needs 800MHz and 1GHz. Cheers, m. pgpYDP6ZLKEvD.pgp Description: PGP signature
[PATCH 1/1] ARM: OMAP: Add maintainer entry for IGEP machines
Enric and I have been mantained this machine and while we are moving to device trees, it is good that people cc us when reporting bugs or regression on the board file until we have proper DT support. Signed-off-by: Javier Martinez Canillas --- MAINTAINERS |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 63ce2a2..6b3c58d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -818,6 +818,14 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git F: arch/arm/mach-sa1100/jornada720.c F: arch/arm/mach-sa1100/include/mach/jornada720.h +ARM/IGEP MACHINE SUPPORT +M: Enric Balletbo i Serra +M: Javier Martinez Canillas +L: linux-omap@vger.kernel.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: arch/arm/mach-omap2/board-igep0020.c + ARM/INCOME PXA270 SUPPORT M: Marek Vasut L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] ARM: dts/OMAP: Pinmux audio configuration for OMAP4+
On 10/06/2012 02:03 AM, Tony Lindgren wrote: > * Peter Ujfalusi [121004 04:57]: >> Hello, >> >> u-boot recently stopped configuring 'non essential' pin mux. This change >> leaves >> the audio essential pins in non configured state which prevents the use of >> audio. >> The following series makes sure that the needed pins are configured >> correctly by >> the kernel on OMAP4 and OMAP5. >> >> Tony: can this series queued for 3.7? > > Let's see if that's possible to avoid mysterious bug reports > of things not working. > > If we can't merge it, then it might be worth adding a warning > that bails out early after some pin is checked or similar. With new enough u-boot the twl6040 fails to probe (mux for nirq2 and power GPIO is not configured) which leads to no audio on OMAP4/5. Adding another warning - and check - does not going to help to clarify the situation IMHO. We can still enable the CONFIG_SYS_ENABLE_PADS_ALL in u-boot and recompile it, but this is disabled as default and to be frank there is no guaranty that this is going to be available let's say next week. -- Péter -- 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
