Re: [PATCH v3 00/23] Unrestricted media entity ID range support
t; +static struct iss_subdev_i2c_board_info panda_camera_subdevs[] = {
> + {
> + .board_info = _camera_i2c_device,
> + .i2c_adapter_id = 3,
> + },
> +};
> +
> +static struct iss_v4l2_subdevs_group iss_subdevs[] = {
> + {
> + .subdevs = panda_camera_subdevs,
> + .interface = ISS_INTERFACE_CSI2A_PHY1,
> + .bus = {
> + .csi2 = {
> + .lanecfg = {
> + .clk = {
> + .pol = 0,
> + .pos = 2,
> + },
> + .data[0] = {
> + .pol = 0,
> + .pos = 1,
> + },
> + .data[1] = {
> + .pol = 0,
> + .pos = 3,
> + },
> + },
> + } },
> + },
> + { /* sentinel */ },
> +};
> +
> +static struct iss_platform_data iss_pdata = {
> + .subdevs = iss_subdevs,
> +};
> +
> +static struct platform_device omap4iss_device = {
> + .name = "omap4iss",
> + .id = -1,
> + .dev = {
> + .platform_data = _pdata,
> + },
> + .num_resources = ARRAY_SIZE(panda_iss_resource),
> + .resource = panda_iss_resource,
> +};
> +
> +static void __init omap4_panda_legacy_init(void)
> +{
> + platform_device_register(_device);
> +}
> +
> +#endif /* CONFIG_ARCH_OMAP4 */
> +
> #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
> static struct iommu_platform_data omap4_iommu_pdata = {
> .reset_name = "mmu_cache",
> @@ -539,6 +659,9 @@ static struct pdata_init pdata_quirks[] __initdata = {
> #ifdef CONFIG_SOC_TI81XX
> { "hp,t410", t410_abort_init, },
> #endif
> +#ifdef CONFIG_ARCH_OMAP4
> + { "ti,omap4-panda", omap4_panda_legacy_init, },
> +#endif
> #ifdef CONFIG_SOC_OMAP5
> { "ti,omap5-uevm", omap5_uevm_legacy_init, },
> #endif
>
> diff --git a/drivers/staging/media/omap4iss/iss.c
> b/drivers/staging/media/omap4iss/iss.c index 30b473cfb020..b528cacda17b
> 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -1412,6 +1412,9 @@ static int iss_probe(struct platform_device *pdev)
> unsigned int i;
> int ret;
>
> +
> +printk("%s: pdata=%p\n", __func__, pdata);
> +
> if (!pdata)
> return -EINVAL;
>
> @@ -1437,24 +1440,33 @@ static int iss_probe(struct platform_device *pdev)
> iss->syscon = syscon_regmap_lookup_by_compatible("syscon");
> if (IS_ERR(iss->syscon)) {
> ret = PTR_ERR(iss->syscon);
> + dev_err(iss->dev, "Unable to find syscon");
> goto error;
> }
>
> /* Clocks */
> ret = iss_map_mem_resource(pdev, iss, OMAP4_ISS_MEM_TOP);
> - if (ret < 0)
> + if (ret < 0) {
> + dev_err(iss->dev, "Unable to map memory resource\n");
> goto error;
> + }
>
> ret = iss_get_clocks(iss);
> - if (ret < 0)
> + if (ret < 0) {
> + dev_err(iss->dev, "Unable to get clocks\n");
> goto error;
> + }
>
> - if (!omap4iss_get(iss))
> + if (!omap4iss_get(iss)) {
> + dev_err(iss->dev, "Failed to acquire ISS resource\n");
> goto error;
> + }
>
> ret = iss_reset(iss);
> - if (ret < 0)
> + if (ret < 0) {
> + dev_err(iss->dev, "Unable to reset ISS\n");
> goto error_iss;
> + }
>
> iss->revision = iss_reg_read(iss, OMAP4_ISS_MEM_TOP, ISS_HL_REVISION);
> dev_info(iss->dev, "Revision %08x found\n", iss->revision);
--
Regards,
Laurent Pinchart
--
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] video:omapdrm: make omapdrm assume the tv-out cable is always connected
On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote:
> On 13/11/15 12:29, H. Nikolaus Schaller wrote:
> > Include VENC in the set of drivers where it is assimed that the cable
> > is always connected. Like DPI, DSI, DBI and SDI do.
> >
> > Otherwise, the VENC will return cable status "unknown" and is not enabled
> > by the X-server. So there is no video output signal.
> >
> > Tested on: BeagleBoard XM, GTA04 and OpenPandora
> >
> > Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
> > ---
> >
> > drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
> > b/drivers/gpu/drm/omapdrm/omap_connector.c index 83f2a91..98ddb5d 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> > @@ -120,6 +120,7 @@ static enum drm_connector_status
> > omap_connector_detect(
> > else
> > ret = connector_status_disconnected;
> > } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
> > + dssdev->type == OMAP_DISPLAY_TYPE_VENC ||
> > dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
> > dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
> > dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
>
> I have no idea why VENC is not working for you when using
> connector_status_unknown, but I just tested DPI with
> connector_status_unknown (i.e. changed the above func to return unknown
> for DPI), and it works fine with X and X omap driver. And xrandr
> confirms that the connection status is unknown:
>
> # xrandr
> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048
> HDMI-1 disconnected (normal left inverted right x axis y axis)
> None-1 unknown connection 1920x1200+0+0 (normal left inverted right x
> axis y axis) 0mm x 0mm
>1920x1200 60.00*+ 60.00 +
>
> Grep also shows that there are many drivers using
> connector_status_unknown, so I'm guessing it should work fine...
And beside it's not right to consider VENC as always connected, as it isn't.
The unknown status is there for a reason, to describe connectors for which we
can't get any status information. The situation is different for DPI, DBI, SDI
and DSI as those are on-board busses that connect to a non-removable panel, so
we can say with a good confidence that the panel is connected (the situation
could be changed with a hammer and a chisel, but that's unlikely to happen,
hence the confidence).
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation
Hi Tony, On Monday 12 October 2015 10:05:59 Tony Lindgren wrote: > * Tony Lindgren <t...@atomide.com> [150914 09:37]: > > * Suman Anna <s-a...@ti.com> [150914 09:33]: > >> On 09/03/2015 05:34 PM, Suman Anna wrote: > >>> On 07/16/2015 07:58 AM, Tony Lindgren wrote: > >>>> * Laurent Pinchart [150716 05:57]: > >>>> The OMAP3 ISP is now fully supported in DT, remove its instantiation > >>>>> from C code. > >>>> > >>>> Please feel to queue this along with the second patch in this series, > >>>> this should not cause any merge conflicts: > >>>> > >>>> Acked-by: Tony Lindgren <t...@atomide.com> > >>> > >>> Just wondering if you have already queued this, I see the v4l changes > >>> in linux-next, but not this patch. Also, can you confirm if this > >>> series is making it into 4.3? > >> > >> This patch is not in 4.3-rc1, can you pick this up for the next merge > >> window? I am gonna send out some additional cleanup patches (removing > >> legacy mailbox and iommu pieces) on top on this patch. The second patch > >> in this series did make it. > > > > OK tagging this one for next, will apply once I'm done with fixes. > > Applying into omap-for-v4.4/cleanup finally thanks. Is see that the patch is in your master branch but not your for-next branch. Will it make it to v4.4-rc1 ? -- Regards, Laurent Pinchart -- 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 12/13] [media] omap3isp: Support for deferred probing when requesting DMA channel
Hi Peter,
Thank you for the patch.
What happened to this patch series ? It looks like
dma_request_slave_channel_compat_reason() isn't in mainline, so I can't apply
this patch.
I'll mark this patch as deferred in patchwork, please resubmit it if you
resubmit the series (and by the look of it the issue you're trying to fix
still exists, so it would be nice if you could get it eventually fixed).
On Tuesday 26 May 2015 16:26:07 Peter Ujfalusi wrote:
> Switch to use ma_request_slave_channel_compat_reason() to request the DMA
> channel. Only fall back to pio mode if the error code returned is not
> -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> CC: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> CC: Mauro Carvalho Chehab <mche...@osg.samsung.com>
> ---
> drivers/media/platform/omap3isp/isphist.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isphist.c
> b/drivers/media/platform/omap3isp/isphist.c index
> 7138b043a4aa..e690ca13af0e 100644
> --- a/drivers/media/platform/omap3isp/isphist.c
> +++ b/drivers/media/platform/omap3isp/isphist.c
> @@ -499,14 +499,20 @@ int omap3isp_hist_init(struct isp_device *isp)
> if (res)
> sig = res->start;
>
> - hist->dma_ch = dma_request_slave_channel_compat(mask,
> + hist->dma_ch = dma_request_slave_channel_compat_reason(mask,
> omap_dma_filter_fn, , isp->dev, "hist");
> - if (!hist->dma_ch)
> + if (IS_ERR(hist->dma_ch)) {
> + ret = PTR_ERR(hist->dma_ch);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
> + hist->dma_ch = NULL;
> dev_warn(isp->dev,
>"hist: DMA channel request failed, using
> PIO\n");
> - else
> + } else {
> dev_dbg(isp->dev, "hist: using DMA channel %s\n",
> dma_chan_name(hist->dma_ch));
> + }
> }
>
> hist->ops = _ops;
--
Regards,
Laurent Pinchart
--
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: DISPC: Remove boolean comparisons
Hi Luis,
Thank you for the patch.
On Thursday 15 October 2015 13:29:38 Luis de Bethencourt wrote:
> Boolean tests do not need explicit comparison to true or false.
>
> Signed-off-by: Luis de Bethencourt <lui...@osg.samsung.com>
Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> ---
> drivers/video/fbdev/omap2/dss/dispc-compat.c | 6 +++---
> drivers/video/fbdev/omap2/dss/dispc.c| 6 +++---
> drivers/video/fbdev/omap2/dss/manager.c | 2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/dispc-compat.c
> b/drivers/video/fbdev/omap2/dss/dispc-compat.c index 633c461..0918b3b
> 100644
> --- a/drivers/video/fbdev/omap2/dss/dispc-compat.c
> +++ b/drivers/video/fbdev/omap2/dss/dispc-compat.c
> @@ -476,7 +476,7 @@ static void dispc_mgr_disable_lcd_out(enum omap_channel
> channel) int r;
> u32 irq;
>
> - if (dispc_mgr_is_enabled(channel) == false)
> + if (!dispc_mgr_is_enabled(channel))
> return;
>
> /*
> @@ -524,7 +524,7 @@ static void dispc_mgr_enable_digit_out(void)
> int r;
> u32 irq_mask;
>
> - if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT) == true)
> + if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT))
> return;
>
> /*
> @@ -562,7 +562,7 @@ static void dispc_mgr_disable_digit_out(void)
> u32 irq_mask;
> int num_irqs;
>
> - if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT) == false)
> + if (!dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT))
> return;
>
> /*
> diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
> b/drivers/video/fbdev/omap2/dss/dispc.c index be716c9..43b0367 100644
> --- a/drivers/video/fbdev/omap2/dss/dispc.c
> +++ b/drivers/video/fbdev/omap2/dss/dispc.c
> @@ -571,7 +571,7 @@ EXPORT_SYMBOL(dispc_mgr_go_busy);
>
> void dispc_mgr_go(enum omap_channel channel)
> {
> - WARN_ON(dispc_mgr_is_enabled(channel) == false);
> + WARN_ON(!dispc_mgr_is_enabled(channel));
> WARN_ON(dispc_mgr_go_busy(channel));
>
> DSSDBG("GO %s\n", mgr_desc[channel].name);
> @@ -3220,7 +3220,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
>
> DSSDBG("hsync %luHz, vsync %luHz\n", ht, vt);
> } else {
> - if (t.interlace == true)
> + if (t.interlace)
> t.y_res /= 2;
> }
>
> @@ -3237,7 +3237,7 @@ static void dispc_mgr_set_lcd_divisor(enum
> omap_channel channel, u16 lck_div, dispc_write_reg(DISPC_DIVISORo(channel),
> FLD_VAL(lck_div, 23, 16) | FLD_VAL(pck_div, 7, 0));
>
> - if (dss_has_feature(FEAT_CORE_CLK_DIV) == false &&
> + if (!dss_has_feature(FEAT_CORE_CLK_DIV) &&
> channel == OMAP_DSS_CHANNEL_LCD)
> dispc.core_clk_rate = dispc_fclk_rate() / lck_div;
> }
> diff --git a/drivers/video/fbdev/omap2/dss/manager.c
> b/drivers/video/fbdev/omap2/dss/manager.c index 1aac9b4..08a67f4 100644
> --- a/drivers/video/fbdev/omap2/dss/manager.c
> +++ b/drivers/video/fbdev/omap2/dss/manager.c
> @@ -210,7 +210,7 @@ static int dss_mgr_check_lcd_config(struct
> omap_overlay_manager *mgr, return -EINVAL;
>
> /* fifohandcheck should be used only with stallmode */
> - if (stallmode == false && fifohandcheck == true)
> + if (!stallmode && fifohandcheck)
> return -EINVAL;
>
> /*
--
Regards,
Laurent Pinchart
--
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/37] ARM: dts: Fix fixed regulators enable GPIO polarity
Hi Shawn, On Tuesday 13 October 2015 22:09:46 Shawn Guo wrote: > On Tue, Oct 13, 2015 at 12:12:29AM +0300, Laurent Pinchart wrote: > > Laurent Pinchart (37): > ... > > > ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property > > ... > > > ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity > > ... > > > ARM: dts: imx23-evk: Fix regulator enable GPIO polarity > > ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity > > ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity > > ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity > > ARM: dts: imx28-evk: Fix regulator enable GPIO polarity > > ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity > > ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity > > ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity > > ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity > > ARM: dts: imx53-m53evk: Fix regulator enable GPIO polarity > > ARM: dts: imx53-mba53: Fix regulator enable GPIO polarity > > ARM: dts: imx53-tx53: Fix regulator enable GPIO polarity > > ARM: dts: imx6q-dmo-edmqmx6: Fix regulator enable GPIO polarity > > Applied these 15 patches, thanks. There's ongoing discussions regarding whether this is the right thing to do. Please see http://www.spinics.net/lists/arm-kernel/msg451724.html. It's thus a bit early to apply the patches at this point I'm afraid. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap3-igep: Use OMAP3_CORE1_IOPAD pinmux macro
Use the macro instead of absolute register offsets to make the code more
readable as the values now match register addresses from the datasheet.
Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
---
arch/arm/boot/dts/omap3-igep.dtsi | 48 +++
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index a2f97928297d..09a438ebfbbe 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -35,60 +35,60 @@
_pmx_core {
uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
- 0x152 (PIN_INPUT | MUX_MODE0) /*
uart1_rx.uart1_rx */
- 0x14c (PIN_OUTPUT |MUX_MODE0) /*
uart1_tx.uart1_tx */
+ OMAP3_CORE1_IOPAD(0x2182, PIN_INPUT | MUX_MODE0)
/* uart1_rx.uart1_rx */
+ OMAP3_CORE1_IOPAD(0x217c, PIN_OUTPUT | MUX_MODE0)
/* uart1_tx.uart1_tx */
>;
};
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins = <
- 0x16e (PIN_INPUT | MUX_MODE0) /*
uart3_rx.uart3_rx */
- 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx.uart3_tx */
+ OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | MUX_MODE0)
/* uart3_rx.uart3_rx */
+ OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)
/* uart3_tx.uart3_tx */
>;
};
mcbsp2_pins: pinmux_mcbsp2_pins {
pinctrl-single,pins = <
- 0x10c (PIN_INPUT | MUX_MODE0) /*
mcbsp2_fsx.mcbsp2_fsx */
- 0x10e (PIN_INPUT | MUX_MODE0) /*
mcbsp2_clkx.mcbsp2_clkx */
- 0x110 (PIN_INPUT | MUX_MODE0) /*
mcbsp2_dr.mcbsp2.dr */
- 0x112 (PIN_OUTPUT | MUX_MODE0) /*
mcbsp2_dx.mcbsp2_dx */
+ OMAP3_CORE1_IOPAD(0x213c, PIN_INPUT | MUX_MODE0)
/* mcbsp2_fsx.mcbsp2_fsx */
+ OMAP3_CORE1_IOPAD(0x213e, PIN_INPUT | MUX_MODE0)
/* mcbsp2_clkx.mcbsp2_clkx */
+ OMAP3_CORE1_IOPAD(0x2140, PIN_INPUT | MUX_MODE0)
/* mcbsp2_dr.mcbsp2.dr */
+ OMAP3_CORE1_IOPAD(0x2142, PIN_OUTPUT | MUX_MODE0)
/* mcbsp2_dx.mcbsp2_dx */
>;
};
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
- 0x114 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_clk.sdmmc1_clk */
- 0x116 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_cmd.sdmmc1_cmd */
- 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat0.sdmmc1_dat0 */
- 0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat1.sdmmc1_dat1 */
- 0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat2.sdmmc1_dat2 */
- 0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat3.sdmmc1_dat3 */
+ OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_clk.sdmmc1_clk */
+ OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_cmd.sdmmc1_cmd */
+ OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat0.sdmmc1_dat0 */
+ OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat1.sdmmc1_dat1 */
+ OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat2.sdmmc1_dat2 */
+ OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc1_dat3.sdmmc1_dat3 */
>;
};
mmc2_pins: pinmux_mmc2_pins {
pinctrl-single,pins = <
- 0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_clk.sdmmc2_clk */
- 0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_cmd.sdmmc2_cmd */
- 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat0.sdmmc2_dat0 */
- 0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat1.sdmmc2_dat1 */
- 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat2.sdmmc2_dat2 */
- 0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat3.sdmmc2_dat3 */
+ OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_clk.sdmmc2_clk */
+ OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_cmd.sdmmc2_cmd */
+ OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat0.sdmmc2_dat0 */
+ OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat1.sdmmc2_dat1 */
+ OMAP3_COR
[PATCH 2/2] ARM: dts: omap3-igep0020: Remove duplicate uart2 pinmux
uart2 pinmux is already defined in omap3-igep0020-common.dtsi, remove
the duplicate node.
Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
---
arch/arm/boot/dts/omap3-igep0020.dts | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index fea7f7edb45d..5683b8bf3475 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -45,15 +45,6 @@
OMAP3_CORE1_IOPAD(0x216a, PIN_OUTPUT | MUX_MODE4)
/* sdmmc2_dat7.gpio_139 - RST_N_B */
>;
};
-
- uart2_pins: pinmux_uart2_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x2174, PIN_INPUT | MUX_MODE0)
/* uart2_cts.uart2_cts */
- OMAP3_CORE1_IOPAD(0x2176, PIN_OUTPUT | MUX_MODE0)
/* uart2_rts .uart2_rts*/
- OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE0)
/* uart2_tx.uart2_tx */
- OMAP3_CORE1_IOPAD(0x217a, PIN_INPUT | MUX_MODE0)
/* uart2_rx.uart2_rx */
- >;
- };
};
/* On board Wifi module */
--
Regards,
Laurent Pinchart
--
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: dts: omap3-igep: Fix indentation
Use tabs instead of spaces for indentation.
Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
---
arch/arm/boot/dts/omap3-igep.dtsi | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index d5e5cd449b16..0b4736f19eb5 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -161,7 +161,7 @@
twl_audio: audio {
compatible = "ti,twl4030-audio";
codec {
- };
+ };
};
};
};
@@ -181,11 +181,11 @@
};
{
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- vmmc-supply = <>;
- vmmc_aux-supply = <>;
- bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ vmmc-supply = <>;
+ vmmc_aux-supply = <>;
+ bus-width = <4>;
};
{
@@ -193,13 +193,13 @@
};
{
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
};
{
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
};
_gpio {
--
Regards,
Laurent Pinchart
--
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 01/37] ARM: dts: am437x-gp-evm: Remove unneeded regulator property
The enable-active-high regulator property only makes sense when an
enable GPIO is specified. Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
---
arch/arm/boot/dts/am437x-gp-evm.dts | 1 -
1 file changed, 1 deletion(-)
Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson <bcous...@baylibre.com>
Cc: Tony Lindgren <t...@atomide.com>
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 84aa30c3235a..a3cd413aebf0 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -29,7 +29,6 @@
regulator-name = "vmmcsd_fixed";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
- enable-active-high;
};
vtt_fixed: fixedregulator-vtt {
--
2.4.9
--
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 09/37] ARM: dts: omap3-tao3530: Remove invalid enable-active-low regulator property
The property isn't part of the regulator-fixed DT bindings and isn't used by the driver. Remove it. Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> --- arch/arm/boot/dts/omap3-tao3530.dtsi | 1 - 1 file changed, 1 deletion(-) Cc: linux-omap@vger.kernel.org Cc: Benoit Cousson <bcous...@baylibre.com> Cc: Tony Lindgren <t...@atomide.com> diff --git a/arch/arm/boot/dts/omap3-tao3530.dtsi b/arch/arm/boot/dts/omap3-tao3530.dtsi index 7bd8d9a4f67f..a520b4fdcf20 100644 --- a/arch/arm/boot/dts/omap3-tao3530.dtsi +++ b/arch/arm/boot/dts/omap3-tao3530.dtsi @@ -63,7 +63,6 @@ regulator-min-microvolt = <315>; regulator-max-microvolt = <315>; gpio = < 29 GPIO_ACTIVE_LOW>; /* gpio_157 */ - enable-active-low; startup-delay-us = <1>; }; }; -- 2.4.9 -- 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 33/37] ARM: dts: omap3-tao3530: Fix regulator enable GPIO polarity
The enable GPIO is active low, but is flagged as active high in the gpio property. As the gpio property flags are currently unused by the driver this doesn't cause any issue for now, but will break later if the driver starts making use of the flags. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> --- arch/arm/boot/dts/omap3-tao3530.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Cc: linux-omap@vger.kernel.org Cc: Benoit Cousson <bcous...@baylibre.com> Cc: Tony Lindgren <t...@atomide.com> diff --git a/arch/arm/boot/dts/omap3-tao3530.dtsi b/arch/arm/boot/dts/omap3-tao3530.dtsi index a520b4fdcf20..68f75be5d99a 100644 --- a/arch/arm/boot/dts/omap3-tao3530.dtsi +++ b/arch/arm/boot/dts/omap3-tao3530.dtsi @@ -37,7 +37,7 @@ regulator-name = "hsusb2_vbus"; regulator-min-microvolt = <330>; regulator-max-microvolt = <330>; - gpio = <_gpio 18 0>;/* GPIO LEDA */ + gpio = <_gpio 18 GPIO_ACTIVE_LOW>; /* GPIO LEDA */ startup-delay-us = <7>; }; -- 2.4.9 -- 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 08/37] ARM: dts: omap3-sb-t35: Remove invalid enable-active-low regulator property
The property isn't part of the regulator-fixed DT bindings and isn't used by the driver. Remove it. Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> --- arch/arm/boot/dts/omap3-sb-t35.dtsi | 1 - 1 file changed, 1 deletion(-) Cc: linux-omap@vger.kernel.org Cc: Benoit Cousson <bcous...@baylibre.com> Cc: Tony Lindgren <t...@atomide.com> diff --git a/arch/arm/boot/dts/omap3-sb-t35.dtsi b/arch/arm/boot/dts/omap3-sb-t35.dtsi index 827f614261f6..b77e25d20e07 100644 --- a/arch/arm/boot/dts/omap3-sb-t35.dtsi +++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi @@ -50,7 +50,6 @@ pinctrl-names = "default"; pinctrl-0 = <_t35_audio_amp>; gpio = < 29 GPIO_ACTIVE_LOW>; /* gpio_61 */ - enable-active-low; regulator-always-on; }; }; -- 2.4.9 -- 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 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity
Hello,
While working on regulators, GPIOs and DT I noticed that many of our DT source
files incorrectly describe fixed regulators. The common error patterns are
- Usage of the undefined (and never parsed) enable-active-low property
- Usage of the enable-active-high property without specifying an enable GPIO
- Typos in the enabl GPIO property name (gpios instead of gpio)
- Mismatch between the enable-active-high property (or the lack thereof) and
the enable GPIO flags
This patch series fixes those issues in all the DT sources after locating the
errors using the following script.
--
#!/bin/sh
echo $1
cat $1 | awk '
BEGIN {
open_drain = 0;
active_high = 0;
gpio = 0;
flags = 0;
}
match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
name = ary[1];
}
/compatible.*"regulator-fixed"/ {
found = 1;
}
/enable-active-high/ {
active_high = 1;
}
/gpio-open-drain/ {
open_drain = 1;
}
match($0, /gpio += <.* ([^ ]*)>/, ary) {
gpio = 1;
flags = ary[1];
if (flags == 0)
flags = "GPIO_ACTIVE_HIGH";
}
/}/ {
if (found) {
if (gpio) {
print "\t" name ": active high " active_high " " flags
" open drain " open_drain;
if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
(!active_high && flags == "GPIO_ACTIVE_HIGH"))
print "WARNING: enable-active-high and flags do
not match"
} else {
if (active_high)
print "WARNING: active high without GPIO"
if (open_drain)
print "WARNING: open drain without GPIO"
}
}
gpio = 0;
found = 0;
active_high = 0;
open_drain = 0;
flags = 0;
}
'
--
All patches except for the ones touching omap3-beagle-xm and omap3-overo-base
are untested as I lack test hardware.
As there's no dependency between the patches touching different source files
the appropriate maintainers could take their share of the patches in their
tree. Alternatively I could send a single pull request after collecting all
acks but that might be more complex.
Cc: devicet...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Benoit Cousson <bcous...@baylibre.com>
Cc: Tony Lindgren <t...@atomide.com>
Cc: Jason Cooper <ja...@lakedaemon.net>
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Gregory Clement <gregory.clem...@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
Cc: Kukjin Kim <kg...@kernel.org>
Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Cc: Shawn Guo <shawn...@kernel.org>
Cc: Sascha Hauer <ker...@pengutronix.de>
Cc: Stephen Warren <swar...@wwwdotorg.org>
Cc: Thierry Reding <thierry.red...@gmail.com>
Cc: Alexandre Courbot <gnu...@gmail.com>
Cc: Liam Girdwood <lgirdw...@gmail.com>
Cc: Mark Brown <broo...@kernel.org>
Cc: Linus Walleij <linus.wall...@linaro.org>
Laurent Pinchart (37):
ARM: dts: am437x-gp-evm: Remove unneeded regulator property
ARM: dts: am43xx-epos-evm: Remove unneeded regulator property
ARM: mvebu: Armada 388 GP: Remove unneeded regulator property
ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property
ARM: dts: s5pv210-aquila: Fix typo in regulator enable GPIO property
ARM: dts: s5pv210-goni: Fix typo in regulator enable GPIO property
ARM: dts: omap3-evm: Remove invalid enable-active-low regulator
property
ARM: dts: omap3-sb-t35: Remove invalid enable-active-low regulator
property
ARM: dts: omap3-tao3530: Remove invalid enable-active-low regulator
property
ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity
ARM: dts: dove-cm-a510: Fix regulator enable GPIO polarity
ARM: dts: dove-sbc-a510: Fix regulator enable GPIO polarity
ARM: dts: exynos5250-arndale: Fix regulator enable GPIO polarity
ARM: dts: imx23-evk: Fix regulator enable GPIO polarity
ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity
ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity
ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity
ARM: dts: imx28-evk: Fix regulator enable GPIO polarity
ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity
ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity
ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity
ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity
A
[PATCH 28/37] ARM: dts: omap4-duovero: Fix regulator enable GPIO polarity
The enable GPIO is active high, but is flagged as active low in the gpio property. As the gpio property flags are currently unused by the driver this doesn't cause any issue for now, but will break later if the driver starts making use of the flags. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> --- arch/arm/boot/dts/omap4-duovero.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Cc: linux-omap@vger.kernel.org Cc: Benoit Cousson <bcous...@baylibre.com> Cc: Tony Lindgren <t...@atomide.com> diff --git a/arch/arm/boot/dts/omap4-duovero.dtsi b/arch/arm/boot/dts/omap4-duovero.dtsi index f2a94fa62552..23c1a74f91ea 100644 --- a/arch/arm/boot/dts/omap4-duovero.dtsi +++ b/arch/arm/boot/dts/omap4-duovero.dtsi @@ -56,7 +56,7 @@ regulator-name = "w2cbw0015"; regulator-min-microvolt = <300>; regulator-max-microvolt = <300>; - gpio = < 11 GPIO_ACTIVE_LOW>; /* gpio_43 */ + gpio = < 11 GPIO_ACTIVE_HIGH>;/* gpio_43 */ startup-delay-us = <7>; enable-active-high; regulator-boot-on; -- 2.4.9 -- 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 02/37] ARM: dts: am43xx-epos-evm: Remove unneeded regulator property
The enable-active-high regulator property only makes sense when an
enable GPIO is specified. Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
---
arch/arm/boot/dts/am43x-epos-evm.dts | 1 -
1 file changed, 1 deletion(-)
Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson <bcous...@baylibre.com>
Cc: Tony Lindgren <t...@atomide.com>
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 795d68af6df9..705048bf17c5 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -28,7 +28,6 @@
regulator-name = "vmmcsd_fixed";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
- enable-active-high;
};
lcd0: display {
--
2.4.9
--
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 31/37] ARM: dts: omap3-beagle: Fix regulator enable GPIO polarity
The enable GPIO is active low, but is flagged as active high in the gpio property. As the gpio property flags are currently unused by the driver this doesn't cause any issue for now, but will break later if the driver starts making use of the flags. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> --- arch/arm/boot/dts/omap3-beagle.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Cc: linux-omap@vger.kernel.org Cc: Benoit Cousson <bcous...@baylibre.com> Cc: Tony Lindgren <t...@atomide.com> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts index a5474113cd50..0849035643fc 100644 --- a/arch/arm/boot/dts/omap3-beagle.dts +++ b/arch/arm/boot/dts/omap3-beagle.dts @@ -55,7 +55,7 @@ regulator-name = "hsusb2_vbus"; regulator-min-microvolt = <330>; regulator-max-microvolt = <330>; - gpio = <_gpio 18 0>;/* GPIO LEDA */ + gpio = <_gpio 18 GPIO_ACTIVE_LOW>; /* GPIO LEDA */ startup-delay-us = <7>; }; -- 2.4.9 -- 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 30/37] ARM: dts: omap3-beagle-xm: Fix regulator enable GPIO polarity
The enable GPIO is active low, but is flagged as active high in the gpio property. As the gpio property flags are currently unused by the driver this doesn't cause any issue for now, but will break later if the driver starts making use of the flags. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> --- arch/arm/boot/dts/omap3-beagle-xm.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Cc: linux-omap@vger.kernel.org Cc: Benoit Cousson <bcous...@baylibre.com> Cc: Tony Lindgren <t...@atomide.com> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts index 7c4dca122a91..f44f17673061 100644 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts @@ -80,7 +80,7 @@ regulator-name = "hsusb2_vbus"; regulator-min-microvolt = <330>; regulator-max-microvolt = <330>; - gpio = <_gpio 18 0>;/* GPIO LEDA */ + gpio = <_gpio 18 GPIO_ACTIVE_LOW>; /* GPIO LEDA */ startup-delay-us = <7>; }; -- 2.4.9 -- 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 32/37] ARM: dts: omap3-overo-base: Fix regulator enable GPIO polarity
The enable GPIO is active low, but is flagged as active high in the gpio property. As the gpio property flags are currently unused by the driver this doesn't cause any issue for now, but will break later if the driver starts making use of the flags. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> --- arch/arm/boot/dts/omap3-overo-base.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Cc: linux-omap@vger.kernel.org Cc: Benoit Cousson <bcous...@baylibre.com> Cc: Tony Lindgren <t...@atomide.com> diff --git a/arch/arm/boot/dts/omap3-overo-base.dtsi b/arch/arm/boot/dts/omap3-overo-base.dtsi index 18e1649681c1..1fa59d0e1e8a 100644 --- a/arch/arm/boot/dts/omap3-overo-base.dtsi +++ b/arch/arm/boot/dts/omap3-overo-base.dtsi @@ -65,7 +65,7 @@ regulator-name = "regulator-w3cbw003c-wifi-nreset"; regulator-min-microvolt = <330>; regulator-max-microvolt = <330>; - gpio = < 16 GPIO_ACTIVE_HIGH>;/* gpio_16: WiFi nReset */ + gpio = < 16 GPIO_ACTIVE_LOW>; /* gpio_16: WiFi nReset */ startup-delay-us = <1>; }; @@ -75,7 +75,7 @@ regulator-name = "regulator-w3cbw003c-bt-nreset"; regulator-min-microvolt = <330>; regulator-max-microvolt = <330>; - gpio = < 4 GPIO_ACTIVE_HIGH>; /* gpio_164: BT nReset */ + gpio = < 4 GPIO_ACTIVE_LOW>; /* gpio_164: BT nReset */ startup-delay-us = <1>; }; }; -- 2.4.9 -- 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 07/37] ARM: dts: omap3-evm: Remove invalid enable-active-low regulator property
The property isn't part of the regulator-fixed DT bindings and isn't
used by the driver. Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
---
arch/arm/boot/dts/omap3-evm-common.dtsi | 1 -
1 file changed, 1 deletion(-)
Cc: linux-omap@vger.kernel.org
Cc: Benoit Cousson <bcous...@baylibre.com>
Cc: Tony Lindgren <t...@atomide.com>
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi
b/arch/arm/boot/dts/omap3-evm-common.dtsi
index b2589f96d5f7..c55f256d014b 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -76,7 +76,6 @@
_3v3 {
gpio = < 25 GPIO_ACTIVE_LOW>; /* gpio153 */
- enable-active-low;
};
{
--
2.4.9
--
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: dts: omap3-igep: Fix indentation
Hi Javier, On Tuesday 13 October 2015 00:26:58 Javier Martinez Canillas wrote: > On Mon, Oct 12, 2015 at 10:46 PM, Laurent Pinchart wrote: > > Use tabs instead of spaces for indentation. > > > > Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > > Acked-by: Javier Martinez Canillas <jav...@osg.samsung.com> Thank you. Tony, could you please pick the series up for v4.4 ? -- Regards, Laurent Pinchart -- 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/37] ARM: dts: Fix fixed regulators enable GPIO polarity
Hi Javier,
On Tuesday 13 October 2015 00:19:20 Javier Martinez Canillas wrote:
> On 10/12/2015 11:46 PM, Tony Lindgren wrote:
> > * Laurent Pinchart <laurent.pinch...@ideasonboard.com> [151012 14:17]:
> >> Hello,
> >>
> >> While working on regulators, GPIOs and DT I noticed that many of our DT
> >> source files incorrectly describe fixed regulators. The common error
> >> patterns are
> >>
> >> - Usage of the undefined (and never parsed) enable-active-low property
> >> - Usage of the enable-active-high property without specifying an enable
> >> GPIO
> >> - Typos in the enabl GPIO property name (gpios instead of gpio)
> >> - Mismatch between the enable-active-high property (or the lack thereof)
> >> and the enable GPIO flags
> >>
> >> This patch series fixes those issues in all the DT sources after locating
> >> the errors using the following script.
> >>
> >> -
> >> !/bin/sh
> >>
> >> echo $1
> >> cat $1 | awk '
> >> BEGIN {
> >>open_drain = 0;
> >>active_high = 0;
> >>gpio = 0;
> >>flags = 0;
> >> }
> >>
> >> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
> >>name = ary[1];
> >> }
> >>
> >> /compatible.*"regulator-fixed"/ {
> >>found = 1;
> >> }
> >>
> >> /enable-active-high/ {
> >>active_high = 1;
> >> }
> >>
> >> /gpio-open-drain/ {
> >>open_drain = 1;
> >> }
> >>
> >> match($0, /gpio += <.* ([^ ]*)>/, ary) {
> >>gpio = 1;
> >>flags = ary[1];
> >>if (flags == 0)
> >>flags = "GPIO_ACTIVE_HIGH";
> >> }
> >>
> >> /}/ {
> >>if (found) {
> >>if (gpio) {
> >>print "\t" name ": active high " active_high " " flags
> >> " open
drain "
> >>open_drain;
> >>if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
> >>(!active_high && flags == "GPIO_ACTIVE_HIGH"))
> >>print "WARNING: enable-active-high and flags do
> >> not
match"
> >>} else {
> >>if (active_high)
> >>print "WARNING: active high without GPIO"
> >>if (open_drain)
> >>print "WARNING: open drain without GPIO"
> >>}
> >>}
> >>
> >>gpio = 0;
> >>found = 0;
> >>active_high = 0;
> >>open_drain = 0;
> >>flags = 0;
> >> }
> >> '
> >> -
> >>
> >> All patches except for the ones touching omap3-beagle-xm and
> >> omap3-overo-base are untested as I lack test hardware.
> >>
> >> As there's no dependency between the patches touching different source
> >> files the appropriate maintainers could take their share of the patches
> >> in their tree. Alternatively I could send a single pull request after
> >> collecting all acks but that might be more complex.
> >
> > Nice clean-up. For omaps, there's an earlier patch posted by
> > Javier Martinez Canillas <jav...@osg.samsung.com> as "[PATCH] ARM: dts:
> > Use defined GPIO constants in flags cell for OMAP2+ boards". Can you guys
> > do some cross checking and let me know which combination I should appluy
> > for omaps?
>
> Since Laurent's changes for OMAP are part of a bigger series and my patch
> was only for OMAP, probably makes sense for you to pick his patches and I
> can re-spin mine on top of that.
>
> BTW, I posted as a single patch since the changes were trivial but maybe
> that made handling these conflicts harder and I should split the changes
> instead, since I'll resend anyways.
>
> What do you prefer? a patch per SoC family (i.e: OMAP{2,3,4,5}) or patch
> per board DTS?
My series will likely miss the next merge window as more discussion is needed.
I'll thus respin the patches on top of yours, please proceed without caring
about this.
--
Regards,
Laurent Pinchart
--
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] dmaengine: omap-dma: Add support for memcpy
Hi Peter, Thank you for the patch. While trying to port the omap_vout driver to the DMA engine API I noticed that the driver makes use of double-indexed transfers, which are not supported by the omap-dma driver. I haven't checked in details what would be required, but the interleaved API might be a good candidate for this. Do you have any plan to add support for double-indexed transfers to the omap-dma driver ? On Wednesday 22 April 2015 10:34:29 Peter Ujfalusi wrote: > The sDMA controller is capable of performing memory copy operation. It need > to be configured to software triggered mode and without HW synchronization. > The sDMA can copy data which is aligned to 8, 16 or 32 bits. > > Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> > --- > drivers/dma/omap-dma.c | 51 +-- > 1 file changed, 49 insertions(+), 2 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] iommu/omap: Remove all module references
Hi Suman,
On Monday 20 July 2015 17:33:24 Suman Anna wrote:
The OMAP IOMMU driver has been adapted to the IOMMU framework
for a while now, and it does not support being built as a
module anymore. So, remove all the module references from the
OMAP IOMMU driver.
While at it, also relocate a comment around the subsys_initcall
to avoid a checkpatch strict warning about using a blank line
after function/struct/union/enum declarations.
Signed-off-by: Suman Anna s-a...@ti.com
I think this is one of the checkpatch warnings that can be safely ignored, but
it doesn't matter much. The comment will be removed after the OMAP3 ISP and
OMAP IOMMU drivers get support for a saner IOMMU probing dependency order
solution.
The code seems fine to me.
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index a22c33d6a486..eeecfc4073af 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -12,7 +12,6 @@
*/
#include linux/err.h
-#include linux/module.h
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
@@ -1089,7 +1088,6 @@ static const struct of_device_id omap_iommu_of_match[]
= { { .compatible = ti,dra7-iommu },
{},
};
-MODULE_DEVICE_TABLE(of, omap_iommu_of_match);
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
@@ -1405,20 +1403,5 @@ static int __init omap_iommu_init(void)
return platform_driver_register(omap_iommu_driver);
}
-/* must be ready before omap3isp is probed */
subsys_initcall(omap_iommu_init);
-
-static void __exit omap_iommu_exit(void)
-{
- kmem_cache_destroy(iopte_cachep);
-
- platform_driver_unregister(omap_iommu_driver);
-
- omap_iommu_debugfs_exit();
-}
-module_exit(omap_iommu_exit);
-
-MODULE_DESCRIPTION(omap iommu: tlb and pagetable primitives);
-MODULE_ALIAS(platform:omap-iommu);
-MODULE_AUTHOR(Hiroshi DOYU, Paul Mundt and Toshihiro Kobayashi);
-MODULE_LICENSE(GPL v2);
+/* must be ready before omap3isp is probed */
--
Regards,
Laurent Pinchart
--
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/11] iommu/omap: Remove unnecessary error traces on alloc failures
Hi Suman,
Thank you for the patch.
On Monday 20 July 2015 17:33:29 Suman Anna wrote:
Fix couple of checkpatch warnings of the type,
WARNING: Possible unnecessary 'out of memory' message
Signed-off-by: Suman Anna s-a...@ti.com
The commit message could also mention that the reason to remove the error
messages is that memory allocation failures will already be reported in the
kernel log by the memory management code. No big deal though,
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 0fc00f31c39d..4328d9855edb 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1093,16 +1093,12 @@ static struct iommu_domain
*omap_iommu_domain_alloc(unsigned type) return NULL;
omap_domain = kzalloc(sizeof(*omap_domain), GFP_KERNEL);
- if (!omap_domain) {
- pr_err(kzalloc failed\n);
+ if (!omap_domain)
goto out;
- }
omap_domain-pgtable = kzalloc(IOPGD_TABLE_SIZE, GFP_KERNEL);
- if (!omap_domain-pgtable) {
- pr_err(kzalloc failed\n);
+ if (!omap_domain-pgtable)
goto fail_nomem;
- }
/*
* should never fail, but please keep this around to ensure
--
Regards,
Laurent Pinchart
--
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 01/11] Documentation: dt: Add #iommu-cells info to OMAP iommu bindings
Hi Suman,
Thank you for the patch.
On Monday 20 July 2015 17:33:23 Suman Anna wrote:
The OMAP IOMMU bindings is updated to reflect the required #iommu-cells
property.
Signed-off-by: Suman Anna s-a...@ti.com
This brings the documentation in sync with both mainline DT sources and code
so it looks good to me.
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt index
42531dc387aa..869699925fd5 100644
--- a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -8,6 +8,11 @@ Required properties:
- ti,hwmods : Name of the hwmod associated with the IOMMU instance
- reg: Address space for the configuration registers
- interrupts : Interrupt specifier for the IOMMU instance
+- #iommu-cells : Should be 0. OMAP IOMMUs are all single-master devices,
+ and needs no additional data in the pargs specifier.
Please + also refer to the generic bindings document for
more info + on this property,
+ Documentation/devicetree/bindings/iommu/iommu.txt
Optional properties:
- ti,#tlb-entries : Number of entries in the translation look-aside buffer.
@@ -18,6 +23,7 @@ Optional properties:
Example:
/* OMAP3 ISP MMU */
mmu_isp: mmu@480bd400 {
+ #iommu-cells = 0;
compatible = ti,omap2-iommu;
reg = 0x480bd400 0x80;
interrupts = 24;
--
Regards,
Laurent Pinchart
--
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 04/11] iommu/omap: Protect omap-iopgtable.h against double inclusion
Hi Suman, Thank you for the patch. On Monday 20 July 2015 17:33:26 Suman Anna wrote: Protect the omap-pgtable.h header against double inclusion in source code by using the standard include guard mechanism. Signed-off-by: Suman Anna s-a...@ti.com Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/iommu/omap-iopgtable.h | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/iommu/omap-iopgtable.h b/drivers/iommu/omap-iopgtable.h index f891683e3f05..bfde5405f514 100644 --- a/drivers/iommu/omap-iopgtable.h +++ b/drivers/iommu/omap-iopgtable.h @@ -10,6 +10,9 @@ * published by the Free Software Foundation. */ +#ifndef _OMAP_IOPGTABLE_H +#define _OMAP_IOPGTABLE_H + /* * L2 table address mask and size definitions. */ @@ -93,3 +96,5 @@ static inline phys_addr_t omap_iommu_translate(u32 d, u32 va, u32 mask) /* to find an entry in the second-level page table. */ #define iopte_index(da) (((da) IOPTE_SHIFT) (PTRS_PER_IOPTE - 1)) #define iopte_offset(iopgd, da) (iopgd_page_vaddr(iopgd) + iopte_index(da)) + +#endif /* _OMAP_IOPGTABLE_H */ -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] omap3isp: Remove legacy platform data support
Hello, Now that all users of the OMAP3 ISP have switched to DT, this patch series removes support for legacy platform data support in the omap3isp driver. It also drops the OMAP3 ISP device instantiation board code that is now unused. Patch 2/2 depends on 1/2. From a conflict resolution point of view it would be easier to merge the whole series through the linux-media tree. Tony, would that be fine with you ? If so could you please ack patch 1/2 ? Laurent Pinchart (2): ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation v4l: omap3isp: Drop platform data support arch/arm/mach-omap2/devices.c | 53 -- arch/arm/mach-omap2/devices.h | 19 drivers/media/platform/Kconfig | 2 +- drivers/media/platform/omap3isp/isp.c | 133 --- drivers/media/platform/omap3isp/isp.h | 7 +- drivers/media/platform/omap3isp/ispcsiphy.h | 2 +- drivers/media/platform/omap3isp/ispvideo.c | 9 +- drivers/media/platform/omap3isp/omap3isp.h | 132 +++ include/media/omap3isp.h| 158 9 files changed, 158 insertions(+), 357 deletions(-) delete mode 100644 arch/arm/mach-omap2/devices.h create mode 100644 drivers/media/platform/omap3isp/omap3isp.h delete mode 100644 include/media/omap3isp.h -- Regards, Laurent Pinchart -- 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: OMAP2+: Remove legacy OMAP3 ISP instantiation
The OMAP3 ISP is now fully supported in DT, remove its instantiation
from C code.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/devices.c | 53 ---
arch/arm/mach-omap2/devices.h | 19
2 files changed, 72 deletions(-)
delete mode 100644 arch/arm/mach-omap2/devices.h
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index a69bd67e9028..9374da313e8e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -33,7 +33,6 @@
#include common.h
#include mux.h
#include control.h
-#include devices.h
#include display.h
#define L3_MODULES_MAX_LEN 12
@@ -67,58 +66,6 @@ static int __init omap3_l3_init(void)
}
omap_postcore_initcall(omap3_l3_init);
-#if defined(CONFIG_IOMMU_API)
-
-#include linux/platform_data/iommu-omap.h
-
-static struct resource omap3isp_resources[] = {
- {
- .start = OMAP3430_ISP_BASE,
- .end= OMAP3430_ISP_BASE + 0x12fc,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_BASE2,
- .end= OMAP3430_ISP_BASE2 + 0x0600,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = 24 + OMAP_INTC_START,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-static struct platform_device omap3isp_device = {
- .name = omap3isp,
- .id = -1,
- .num_resources = ARRAY_SIZE(omap3isp_resources),
- .resource = omap3isp_resources,
-};
-
-static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = mmu_isp,
-};
-
-int omap3_init_camera(struct isp_platform_data *pdata)
-{
- if (of_have_populated_dt())
- omap3_isp_iommu.name = 480bd400.mmu;
-
- omap3isp_device.dev.platform_data = pdata;
- omap3isp_device.dev.archdata.iommu = omap3_isp_iommu;
-
- return platform_device_register(omap3isp_device);
-}
-
-#else /* !CONFIG_IOMMU_API */
-
-int omap3_init_camera(struct isp_platform_data *pdata)
-{
- return 0;
-}
-
-#endif
-
#if defined(CONFIG_OMAP2PLUS_MBOX) || defined(CONFIG_OMAP2PLUS_MBOX_MODULE)
static inline void __init omap_init_mbox(void)
{
diff --git a/arch/arm/mach-omap2/devices.h b/arch/arm/mach-omap2/devices.h
deleted file mode 100644
index f61eb6e5d136..
--- a/arch/arm/mach-omap2/devices.h
+++ /dev/null
@@ -1,19 +0,0 @@
-/*
- * arch/arm/mach-omap2/devices.h
- *
- * OMAP2 platform device setup/initialization
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#ifndef __ARCH_ARM_MACH_OMAP_DEVICES_H
-#define __ARCH_ARM_MACH_OMAP_DEVICES_H
-
-struct isp_platform_data;
-
-int omap3_init_camera(struct isp_platform_data *pdata);
-
-#endif
--
2.3.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
[PATCH 2/2] v4l: omap3isp: Drop platform data support
Platforms using the OMAP3 ISP have all switched to DT, drop platform
data support.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/omap3isp/isp.c | 133 ---
drivers/media/platform/omap3isp/isp.h | 7 +-
drivers/media/platform/omap3isp/ispcsiphy.h | 2 +-
drivers/media/platform/omap3isp/ispvideo.c | 9 +-
drivers/media/platform/omap3isp/omap3isp.h | 132 +++
include/media/omap3isp.h| 158
7 files changed, 158 insertions(+), 285 deletions(-)
create mode 100644 drivers/media/platform/omap3isp/omap3isp.h
delete mode 100644 include/media/omap3isp.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f6bed197130c..ea07c6f793cb 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -86,7 +86,7 @@ config VIDEO_M32R_AR_M64278
config VIDEO_OMAP3
tristate OMAP 3 Camera support
depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API ARCH_OMAP3
- depends on HAS_DMA
+ depends on HAS_DMA OF
depends on OMAP_IOMMU
select ARM_DMA_USE_IOMMU
select VIDEOBUF2_DMA_CONTIG
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 12be830d704f..56e683b19a73 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -101,7 +101,6 @@ static const struct isp_res_mapping isp_res_maps[] = {
0x, /* csi2a, len 0x0170 */
0x0170, /* csiphy2, len 0x000c */
},
- .syscon_offset = 0xdc,
.phy_type = ISP_PHY_TYPE_3430,
},
{
@@ -124,7 +123,6 @@ static const struct isp_res_mapping isp_res_maps[] = {
0x0570, /* csiphy1, len 0x000c */
0x05c0, /* csi2c, len 0x0040 (2nd area) */
},
- .syscon_offset = 0x2f0,
.phy_type = ISP_PHY_TYPE_3630,
},
};
@@ -1796,47 +1794,6 @@ static void isp_unregister_entities(struct isp_device
*isp)
media_device_unregister(isp-media_dev);
}
-/*
- * isp_register_subdev - Register a sub-device
- * @isp: OMAP3 ISP device
- * @isp_subdev: platform data related to a sub-device
- *
- * Register an I2C sub-device which has not been registered by other
- * means (such as the Device Tree).
- *
- * Return a pointer to the sub-device if it has been successfully
- * registered, or NULL otherwise.
- */
-static struct v4l2_subdev *
-isp_register_subdev(struct isp_device *isp,
- struct isp_platform_subdev *isp_subdev)
-{
- struct i2c_adapter *adapter;
- struct v4l2_subdev *sd;
-
- if (isp_subdev-board_info == NULL)
- return NULL;
-
- adapter = i2c_get_adapter(isp_subdev-i2c_adapter_id);
- if (adapter == NULL) {
- dev_err(isp-dev,
- %s: Unable to get I2C adapter %d for device %s\n,
- __func__, isp_subdev-i2c_adapter_id,
- isp_subdev-board_info-type);
- return NULL;
- }
-
- sd = v4l2_i2c_new_subdev_board(isp-v4l2_dev, adapter,
- isp_subdev-board_info, NULL);
- if (sd == NULL) {
- dev_err(isp-dev, %s: Unable to register subdev %s\n,
- __func__, isp_subdev-board_info-type);
- return NULL;
- }
-
- return sd;
-}
-
static int isp_link_entity(
struct isp_device *isp, struct media_entity *entity,
enum isp_interface_type interface)
@@ -1910,8 +1867,6 @@ static int isp_link_entity(
static int isp_register_entities(struct isp_device *isp)
{
- struct isp_platform_data *pdata = isp-pdata;
- struct isp_platform_subdev *isp_subdev;
int ret;
isp-media_dev.dev = isp-dev;
@@ -1968,37 +1923,6 @@ static int isp_register_entities(struct isp_device *isp)
if (ret 0)
goto done;
- /*
-* Device Tree --- the external sub-devices will be registered
-* later. The same goes for the sub-device node registration.
-*/
- if (isp-dev-of_node)
- return 0;
-
- /* Register external entities */
- for (isp_subdev = pdata ? pdata-subdevs : NULL;
-isp_subdev isp_subdev-board_info; isp_subdev++) {
- struct v4l2_subdev *sd;
-
- sd = isp_register_subdev(isp, isp_subdev);
-
- /*
-* No bus information --- this is either a flash or a
-* lens subdev.
-*/
- if (!sd || !isp_subdev-bus)
- continue;
-
- sd-host_priv = isp_subdev-bus;
-
- ret = isp_link_entity(isp, sd-entity
Re: [PATCH 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation
Hi Sakari, On Thursday 16 July 2015 18:45:22 Sakari Ailus wrote: Laurent Pinchart wrote: The OMAP3 ISP is now fully supported in DT, remove its instantiation from C code. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- arch/arm/mach-omap2/devices.c | 53 -- arch/arm/mach-omap2/devices.h | 19 2 files changed, 72 deletions(-) delete mode 100644 arch/arm/mach-omap2/devices.h If you remove the definitions, arch/arm/mach-omap2/board-cm-t35.c will no longer compile. Could you remove the camera support there as well? My understanding is the board might be supported in DT but I'm not sure about camera. Cc Mike and Igor. commit 11cd7b8c2773d01e4b40e38568ae62c471a2ea10 Author: Tony Lindgren t...@atomide.com Date: Mon May 4 10:48:07 2015 -0700 ARM: OMAP2+: Remove legacy booting support for cm-t35 Merged in v4.2-rc1 :-) -- Regards, Laurent Pinchart -- 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] drm/tilcdc: Implement dma-buf support for tilcdc
Hi Jyri,
Thank you for the patch.
On Tuesday 30 June 2015 13:30:55 Jyri Sarha wrote:
There is nothing special about tilcdc HW when the video memory is
concerned. Just using the standard drm helpers for implementation is
enough.
Signed-off-by: Jyri Sarha jsa...@ti.com
This looks simple, I like it :-)
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 0f283a3..4908c1f 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -553,7 +553,8 @@ static const struct file_operations fops = {
};
static struct drm_driver tilcdc_driver = {
- .driver_features= DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET,
+ .driver_features= (DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET |
+DRIVER_PRIME),
.load = tilcdc_load,
.unload = tilcdc_unload,
.preclose = tilcdc_preclose,
@@ -571,6 +572,16 @@ static struct drm_driver tilcdc_driver = {
.dumb_create= drm_gem_cma_dumb_create,
.dumb_map_offset= drm_gem_cma_dumb_map_offset,
.dumb_destroy = drm_gem_dumb_destroy,
+
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_import = drm_gem_prime_import,
+ .gem_prime_export = drm_gem_prime_export,
+ .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+ .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+ .gem_prime_vmap = drm_gem_cma_prime_vmap,
+ .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
+ .gem_prime_mmap = drm_gem_cma_prime_mmap,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = tilcdc_debugfs_init,
.debugfs_cleanup= tilcdc_debugfs_cleanup,
--
Regards,
Laurent Pinchart
--
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/7] OMAPDSS: use components (fix probing problems)
Hi Tomi, Thank for the patches. On Tuesday 16 June 2015 13:16:22 Tomi Valkeinen wrote: Hi, I noticed that on some platforms omapdss did not probe successfully. Some resource was not available yet, but omapdss did not manage to handle deferred probing. The reason was the use of platform_driver_probe() in combination with how the omapdss module handles the drivers. To fix this properly, the component system felt fine for the job, and it seems to work nicely. Tomi Tomi Valkeinen (7): OMAPDSS: move 'dss_initialized' to dss driver OMAPDSS: refactor dss probe function OMAPDSS: fix dss_init_ports error handling OMAPDSS: remove uses of __init/__exit OMAPDSS: reorder uninit calls OMAPDSS: componentize omapdss OMAPDSS: simplify submodule reg/unreg code I've quickly reviewed the whole series and it looks good to me. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com drivers/video/fbdev/omap2/dss/core.c | 80 drivers/video/fbdev/omap2/dss/dispc.c | 42 +-- drivers/video/fbdev/omap2/dss/dpi.c | 36 -- drivers/video/fbdev/omap2/dss/dsi.c | 27 +++- drivers/video/fbdev/omap2/dss/dss.c | 223 --- drivers/video/fbdev/omap2/dss/dss.h | 32 ++--- drivers/video/fbdev/omap2/dss/hdmi4.c | 28 - drivers/video/fbdev/omap2/dss/hdmi5.c | 28 - drivers/video/fbdev/omap2/dss/rfbi.c | 32 - drivers/video/fbdev/omap2/dss/sdi.c | 35 -- drivers/video/fbdev/omap2/dss/venc.c | 31 +++-- 11 files changed, 396 insertions(+), 198 deletions(-) -- Regards, Laurent Pinchart -- 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] [media] omap4iss: avoid broken OMAP4 dependency
Hi Arnd,
Thank you for the patch.
On Friday 10 April 2015 22:20:20 Arnd Bergmann wrote:
The omap4iss driver uses an interface that used to be provided
by OMAP4 but has now been removed and replaced with a WARN_ON(1)
statement, which likely broke the iss_csiphy code at runtime.
It also broke compiling the driver when CONFIG_ARCH_OMAP2PLUS
is set, which is implied by OMAP4:
drivers/staging/media/omap4iss/iss_csiphy.c: In function
'omap4iss_csiphy_config':
drivers/staging/media/omap4iss/iss_csiphy.c:167:2: error: implicit
declaration of function 'omap4_ctrl_pad_writel'
[-Werror=implicit-function-declaration] omap4_ctrl_pad_writel(cam_rx_ctrl,
In turn, this broke ARM allyesconfig builds. Replacing the
omap4_ctrl_pad_writel call with WARN_ON(1) won't make the
situation any worse than it already is, but fixes the build
problem.
I've fixed the problem properly by switching to the syscon API. I'll send the
patch as a separate reply, let's discuss there how to handle the issue.
Signed-off-by: Arnd Bergmann a...@arndb.de
Fixes: efde234674d9 (ARM: OMAP4+: control: remove support for legacy pad
read/write)
---
diff --git a/drivers/staging/media/omap4iss/iss_csiphy.c
b/drivers/staging/media/omap4iss/iss_csiphy.c index
7c3d55d811ef..24f56ed90ac3 100644
--- a/drivers/staging/media/omap4iss/iss_csiphy.c
+++ b/drivers/staging/media/omap4iss/iss_csiphy.c
@@ -140,9 +140,7 @@ int omap4iss_csiphy_config(struct iss_device *iss,
* - bit [18] : CSIPHY1 CTRLCLK enable
* - bit [17:16] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
*/
- cam_rx_ctrl = omap4_ctrl_pad_readl(
- OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX);
-
+ cam_rx_ctrl = WARN_ON(1);
if (subdevs-interface == ISS_INTERFACE_CSI2A_PHY1) {
cam_rx_ctrl = ~(OMAP4_CAMERARX_CSI21_LANEENABLE_MASK |
@@ -166,8 +164,7 @@ int omap4iss_csiphy_config(struct iss_device *iss,
cam_rx_ctrl |= OMAP4_CAMERARX_CSI22_CTRLCLKEN_MASK;
}
- omap4_ctrl_pad_writel(cam_rx_ctrl,
- OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX);
+ WARN_ON(1);
/* Reset used lane count */
csi2-phy-used_data_lanes = 0;
--
Regards,
Laurent Pinchart
--
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] v4l: omap4iss: Replace outdated OMAP4 control pad API with syscon
The omap4_ctrl_pad_readl and omap4_ctrl_pad_writel functions have been
removed by commit efde234674d9 (ARM: OMAP4+: control: remove support
for legacy pad read/write) but are still used by the OMAP4 ISS driver,
resulting in a compilation breakage:
drivers/staging/media/omap4iss/iss_csiphy.c: In function
'omap4iss_csiphy_config':
drivers/staging/media/omap4iss/iss_csiphy.c:167:2: error: implicit declaration
of function 'omap4_ctrl_pad_writel' [-Werror=implicit-function-declaration]
omap4_ctrl_pad_writel(cam_rx_ctrl,
Fix the problem by using the syscon API to reaplace the control pad API.
Lookup the syscon instance by compatible name for now as the OMAP4 ISS
driver doesn't support DT yet.
Fixes: efde234674d9 (ARM: OMAP4+: control: remove support for legacy pad
read/write)
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/media/omap4iss/Kconfig | 1 +
drivers/staging/media/omap4iss/iss.c| 11 +++
drivers/staging/media/omap4iss/iss.h| 4
drivers/staging/media/omap4iss/iss_csiphy.c | 12 +++-
4 files changed, 23 insertions(+), 5 deletions(-)
Hi Arnd,
This patch doesn't depend nor conflict with the OMAP4 ISS patches scheduled to
be merged in v4.1. If Mauro is fine with that, and if it makes your life
easier, it could get merged through the arm-soc tree. Please let me know what
you prefer.
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig
index b78643f..072dac0 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -2,6 +2,7 @@ config VIDEO_OMAP4
bool OMAP 4 Camera support
depends on VIDEO_V4L2=y VIDEO_V4L2_SUBDEV_API I2C=y ARCH_OMAP4
depends on HAS_DMA
+ select MFD_SYSCON
select VIDEOBUF2_DMA_CONTIG
---help---
Driver for an OMAP 4 ISS controller.
diff --git a/drivers/staging/media/omap4iss/iss.c
b/drivers/staging/media/omap4iss/iss.c
index 44b81a2..cf22dd2 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -17,6 +17,7 @@
#include linux/dma-mapping.h
#include linux/i2c.h
#include linux/interrupt.h
+#include linux/mfd/syscon.h
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
@@ -1386,6 +1387,16 @@ static int iss_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, iss);
+ /*
+* TODO: When implementing DT support switch to syscon regmap lookup by
+* phandle.
+*/
+ iss-syscon = syscon_regmap_lookup_by_compatible(syscon);
+ if (IS_ERR(iss-syscon)) {
+ ret = PTR_ERR(iss-syscon);
+ goto error;
+ }
+
/* Clocks */
ret = iss_map_mem_resource(pdev, iss, OMAP4_ISS_MEM_TOP);
if (ret 0)
diff --git a/drivers/staging/media/omap4iss/iss.h
b/drivers/staging/media/omap4iss/iss.h
index 734cfee..35df8b4 100644
--- a/drivers/staging/media/omap4iss/iss.h
+++ b/drivers/staging/media/omap4iss/iss.h
@@ -29,6 +29,8 @@
#include iss_ipipe.h
#include iss_resizer.h
+struct regmap;
+
#define to_iss_device(ptr_module) \
container_of(ptr_module, struct iss_device, ptr_module)
#define to_device(ptr_module) \
@@ -79,6 +81,7 @@ struct iss_reg {
/*
* struct iss_device - ISS device structure.
+ * @syscon: Regmap for the syscon register space
* @crashed: Bitmask of crashed entities (indexed by entity ID)
*/
struct iss_device {
@@ -93,6 +96,7 @@ struct iss_device {
struct resource *res[OMAP4_ISS_MEM_LAST];
void __iomem *regs[OMAP4_ISS_MEM_LAST];
+ struct regmap *syscon;
u64 raw_dmamask;
diff --git a/drivers/staging/media/omap4iss/iss_csiphy.c
b/drivers/staging/media/omap4iss/iss_csiphy.c
index 7c3d55d..748607f 100644
--- a/drivers/staging/media/omap4iss/iss_csiphy.c
+++ b/drivers/staging/media/omap4iss/iss_csiphy.c
@@ -13,6 +13,7 @@
#include linux/delay.h
#include linux/device.h
+#include linux/regmap.h
#include ../../../../arch/arm/mach-omap2/control.h
@@ -140,9 +141,11 @@ int omap4iss_csiphy_config(struct iss_device *iss,
* - bit [18] : CSIPHY1 CTRLCLK enable
* - bit [17:16] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
*/
- cam_rx_ctrl = omap4_ctrl_pad_readl(
- OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX);
-
+ /*
+* TODO: When implementing DT support specify the CONTROL_CAMERA_RX
+* register offset in the syscon property instead of hardcoding it.
+*/
+ regmap_read(iss-syscon, 0x68, cam_rx_ctrl);
if (subdevs-interface == ISS_INTERFACE_CSI2A_PHY1) {
cam_rx_ctrl = ~(OMAP4_CAMERARX_CSI21_LANEENABLE_MASK |
@@ -166,8 +169,7 @@ int omap4iss_csiphy_config(struct iss_device *iss,
cam_rx_ctrl |= OMAP4_CAMERARX_CSI22_CTRLCLKEN_MASK
Re: [PATCH] v4l: omap4iss: Replace outdated OMAP4 control pad API with syscon
Hi Sakari, Thank you for the review. On Sunday 12 April 2015 17:31:09 Sakari Ailus wrote: On Sun, Apr 12, 2015 at 03:28:13PM +0300, Laurent Pinchart wrote: diff --git a/drivers/staging/media/omap4iss/iss_csiphy.c b/drivers/staging/media/omap4iss/iss_csiphy.c index 7c3d55d..748607f 100644 --- a/drivers/staging/media/omap4iss/iss_csiphy.c +++ b/drivers/staging/media/omap4iss/iss_csiphy.c @@ -13,6 +13,7 @@ #include linux/delay.h #include linux/device.h +#include linux/regmap.h #include ../../../../arch/arm/mach-omap2/control.h @@ -140,9 +141,11 @@ int omap4iss_csiphy_config(struct iss_device *iss, * - bit [18] : CSIPHY1 CTRLCLK enable * - bit [17:16] : CSIPHY1 config: 00 d-phy, 01/10 ccp2 */ - cam_rx_ctrl = omap4_ctrl_pad_readl( - OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX); - + /* +* TODO: When implementing DT support specify the CONTROL_CAMERA_RX +* register offset in the syscon property instead of hardcoding it. +*/ + regmap_read(iss-syscon, 0x68, cam_rx_ctrl); Do you use platform data now? I guess the address is the same on all SoCs that use the OMAP 4 ISS? Yes I use platform data for now. The address is the same on all SoCs on which I've tested the driver, which is a single SoC :-) I'll research that when implementing DT bindings. Acked-by: Sakari Alius sakari.ai...@iki.fi Thank you. -- Regards, Laurent Pinchart -- 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/14] media: omap3isp: remove unused clkdev
Hello Russell, On Sunday 05 April 2015 15:20:34 Russell King - ARM Linux wrote: On Sat, Apr 04, 2015 at 12:44:35AM +0300, Laurent Pinchart wrote: Hi Russell, Thank you for the patch; On Friday 03 April 2015 18:12:58 Russell King wrote: No merged platform supplies xclks via platform data. As we want to slightly change the clkdev interface, rather than fixing this unused code, remove it instead. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com with one caveat though : it conflicts with patches queued for v4.1 in the media tree. I'll post a rebased version in a reply to your e-mail. How would you like to handle the conflict ? How bad is the conflict? It's not too bad, it's mostly a context-related conflict. There are two additional lines to remove (plus the associated comment) from isp_xclk_init(), as your patch makes a loop now terminate with if (condition) continue;. Those two lines could be removed later, keeping them doesn't break anything. -- Regards, Laurent Pinchart -- 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/14] media: omap3isp: remove unused clkdev
Hi Russell, On Tuesday 07 April 2015 13:45:36 Russell King - ARM Linux wrote: On Tue, Apr 07, 2015 at 12:42:52PM +0300, Laurent Pinchart wrote: On Sunday 05 April 2015 15:20:34 Russell King - ARM Linux wrote: On Sat, Apr 04, 2015 at 12:44:35AM +0300, Laurent Pinchart wrote: Hi Russell, Thank you for the patch; On Friday 03 April 2015 18:12:58 Russell King wrote: No merged platform supplies xclks via platform data. As we want to slightly change the clkdev interface, rather than fixing this unused code, remove it instead. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com with one caveat though : it conflicts with patches queued for v4.1 in the media tree. I'll post a rebased version in a reply to your e-mail. How would you like to handle the conflict ? How bad is the conflict? It's not too bad, it's mostly a context-related conflict. There are two additional lines to remove (plus the associated comment) from isp_xclk_init(), as your patch makes a loop now terminate with if (condition) continue;. Those two lines could be removed later, keeping them doesn't break anything. I think it's fine to take it through the media tree as the series doesn't have any dependencies on this patch. It was merely attempting to get rid of stuff so that we could move closer to clkdev dealing with a clk_hw rather than a struct clk - but I never made it that far with the series. Maybe at a later date... :) :-) I'll take the patch and send a pull request. -- Regards, Laurent Pinchart -- 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 v1.1 07/14] media: omap3isp: remove unused clkdev
From: Russell King rmk+ker...@arm.linux.org.uk
No merged platform supplies xclks via platform data. As we want to
slightly change the clkdev interface, rather than fixing this unused
code, remove it instead.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.c | 24
drivers/media/platform/omap3isp/isp.h | 1 -
include/media/omap3isp.h | 6 --
3 files changed, 31 deletions(-)
In case this would be helpful, I've rebased the original patch on top of the
linuxtv master branch scheduled for merge in v4.1.
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index ff51c4f..18d0a87 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -304,7 +304,6 @@ static struct clk *isp_xclk_src_get(struct of_phandle_args
*clkspec, void *data)
static int isp_xclk_init(struct isp_device *isp)
{
- struct isp_platform_data *pdata = isp-pdata;
struct device_node *np = isp-dev-of_node;
struct clk_init_data init;
unsigned int i;
@@ -335,26 +334,6 @@ static int isp_xclk_init(struct isp_device *isp)
xclk-clk = clk_register(NULL, xclk-hw);
if (IS_ERR(xclk-clk))
return PTR_ERR(xclk-clk);
-
- /* When instantiated from DT we don't need to register clock
-* aliases.
-*/
- if (np)
- continue;
-
- if (!pdata || (pdata-xclks[i].con_id == NULL
- pdata-xclks[i].dev_id == NULL))
- continue;
-
- xclk-lookup = kzalloc(sizeof(*xclk-lookup), GFP_KERNEL);
- if (xclk-lookup == NULL)
- return -ENOMEM;
-
- xclk-lookup-con_id = pdata-xclks[i].con_id;
- xclk-lookup-dev_id = pdata-xclks[i].dev_id;
- xclk-lookup-clk = xclk-clk;
-
- clkdev_add(xclk-lookup);
}
if (np)
@@ -376,9 +355,6 @@ static void isp_xclk_cleanup(struct isp_device *isp)
if (!IS_ERR(xclk-clk))
clk_unregister(xclk-clk);
-
- if (xclk-lookup)
- clkdev_drop(xclk-lookup);
}
}
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 431224e..e579943 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -132,7 +132,6 @@ enum isp_xclk_id {
struct isp_xclk {
struct isp_device *isp;
struct clk_hw hw;
- struct clk_lookup *lookup;
struct clk *clk;
enum isp_xclk_id id;
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index 0f0c08b..048f8f9 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -150,13 +150,7 @@ struct isp_platform_subdev {
struct isp_bus_cfg *bus;
};
-struct isp_platform_xclk {
- const char *dev_id;
- const char *con_id;
-};
-
struct isp_platform_data {
- struct isp_platform_xclk xclks[2];
struct isp_platform_subdev *subdevs;
void (*set_constraints)(struct isp_device *isp, bool enable);
};
--
Regards,
Laurent Pinchart
--
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/14] media: omap3isp: remove unused clkdev
Hi Russell,
Thank you for the patch;
On Friday 03 April 2015 18:12:58 Russell King wrote:
No merged platform supplies xclks via platform data. As we want to
slightly change the clkdev interface, rather than fixing this unused
code, remove it instead.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
with one caveat though : it conflicts with patches queued for v4.1 in the
media tree. I'll post a rebased version in a reply to your e-mail. How would
you like to handle the conflict ?
---
drivers/media/platform/omap3isp/isp.c | 18 --
drivers/media/platform/omap3isp/isp.h | 1 -
include/media/omap3isp.h | 6 --
3 files changed, 25 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c index deca80903c3a..4d8078b9d010
100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -281,7 +281,6 @@ static const struct clk_init_data isp_xclk_init_data = {
static int isp_xclk_init(struct isp_device *isp)
{
- struct isp_platform_data *pdata = isp-pdata;
struct clk_init_data init;
unsigned int i;
@@ -311,20 +310,6 @@ static int isp_xclk_init(struct isp_device *isp)
xclk-clk = clk_register(NULL, xclk-hw);
if (IS_ERR(xclk-clk))
return PTR_ERR(xclk-clk);
-
- if (pdata-xclks[i].con_id == NULL
- pdata-xclks[i].dev_id == NULL)
- continue;
-
- xclk-lookup = kzalloc(sizeof(*xclk-lookup), GFP_KERNEL);
- if (xclk-lookup == NULL)
- return -ENOMEM;
-
- xclk-lookup-con_id = pdata-xclks[i].con_id;
- xclk-lookup-dev_id = pdata-xclks[i].dev_id;
- xclk-lookup-clk = xclk-clk;
-
- clkdev_add(xclk-lookup);
}
return 0;
@@ -339,9 +324,6 @@ static void isp_xclk_cleanup(struct isp_device *isp)
if (!IS_ERR(xclk-clk))
clk_unregister(xclk-clk);
-
- if (xclk-lookup)
- clkdev_drop(xclk-lookup);
}
}
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h index cfdfc8714b6b..d41c98bbdfe7
100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -122,7 +122,6 @@ enum isp_xclk_id {
struct isp_xclk {
struct isp_device *isp;
struct clk_hw hw;
- struct clk_lookup *lookup;
struct clk *clk;
enum isp_xclk_id id;
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index 398279dd1922..a9798525d01e 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -152,13 +152,7 @@ struct isp_v4l2_subdevs_group {
} bus; /* gcc 4.6.0 chokes on anonymous union initializers */
};
-struct isp_platform_xclk {
- const char *dev_id;
- const char *con_id;
-};
-
struct isp_platform_data {
- struct isp_platform_xclk xclks[2];
struct isp_v4l2_subdevs_group *subdevs;
void (*set_constraints)(struct isp_device *isp, bool enable);
};
--
Regards,
Laurent Pinchart
--
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 v1.1 14/15] omap3isp: Add support for the Device Tree
Hi Sakari,
Thank you for the patch. This looks good to me, except that there's one last
bug I've spotted. Please see below.
On Saturday 21 March 2015 00:05:04 Sakari Ailus wrote:
Add the ISP device to omap3 DT include file and add support to the driver to
use it.
Also obtain information on the external entities and the ISP configuration
related to them through the Device Tree in addition to the platform data.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
since v1:
- Print endpoint name in debug message when parsing an endpoint.
- Rename lane-polarity property as lane-polarities.
- Print endpoint name with the interface if the interface is invalid.
- Remove assignment to two variables at the same time.
- Fix multiple sub-device support in isp_of_parse_nodes().
- Put of_node properly in isp_of_parse_nodes() (requires Philipp Zabel's
patch of: Decrement refcount of previous endpoint in
of_graph_get_next_endpoint.
- Rename return value variable rval as ret to be consistent with the rest of
the driver.
- Read the register offset from the syscom property's first argument.
drivers/media/platform/omap3isp/isp.c | 218 ++--
drivers/media/platform/omap3isp/isp.h | 11 ++
drivers/media/platform/omap3isp/ispcsiphy.c |7 +
3 files changed, 224 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c index 992e74c..92a859e 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
[snip]
+static int isp_of_parse_nodes(struct device *dev,
+ struct v4l2_async_notifier *notifier)
+{
+ struct device_node *node;
+
+ notifier-subdevs = devm_kcalloc(
+ dev, ISP_MAX_SUBDEVS, sizeof(*notifier-subdevs), GFP_KERNEL);
+ if (!notifier-subdevs)
+ return -ENOMEM;
+
+ while ((node = of_graph_get_next_endpoint(dev-of_node, node))
+notifier-num_subdevs ISP_MAX_SUBDEVS) {
If the first condition evaluates to true and the second one to false, the loop
will be exited without releasing the reference to the DT node. You could just
switch the two conditions to fix this.
+ struct isp_async_subdev *isd;
+
+ isd = devm_kzalloc(dev, sizeof(*isd), GFP_KERNEL);
+ if (!isd) {
+ of_node_put(node);
+ return -ENOMEM;
+ }
+
+ notifier-subdevs[notifier-num_subdevs] = isd-asd;
+
+ if (isp_of_parse_node(dev, node, isd)) {
+ of_node_put(node);
+ return -EINVAL;
+ }
+
+ isd-asd.match.of.node = of_graph_get_remote_port_parent(node);
+ of_node_put(node);
+ if (!isd-asd.match.of.node) {
+ dev_warn(dev, bad remote port parent\n);
+ return -EINVAL;
+ }
+
+ isd-asd.match_type = V4L2_ASYNC_MATCH_OF;
+ notifier-num_subdevs++;
+ }
+
+ return notifier-num_subdevs;
+}
--
Regards,
Laurent Pinchart
--
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 v1.1 13/15] v4l: of: Read lane-polarities endpoint property
Hi Sakari,
Thank you for the patch.
On Saturday 21 March 2015 00:08:15 Sakari Ailus wrote:
Add lane_polarities field to struct v4l2_of_bus_mipi_csi2 and write the
contents of the lane-polarities property to it. The field tells the polarity
of the physical lanes starting from the first one. Any unused lanes are
ignored, i.e. only the polarity of the used lanes is specified.
Also rework reading the data-lanes property a little.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
since v1:
- Rename lane-polarity property as lane-polarities.
drivers/media/v4l2-core/v4l2-of.c | 41 ++
include/media/v4l2-of.h |3 +++
2 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c index b4ed9a9..58e401f 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -19,11 +19,10 @@
#include media/v4l2-of.h
-static void v4l2_of_parse_csi_bus(const struct device_node *node,
- struct v4l2_of_endpoint *endpoint)
+static int v4l2_of_parse_csi_bus(const struct device_node *node,
+ struct v4l2_of_endpoint *endpoint)
{
struct v4l2_of_bus_mipi_csi2 *bus = endpoint-bus.mipi_csi2;
- u32 data_lanes[ARRAY_SIZE(bus-data_lanes)];
struct property *prop;
bool have_clk_lane = false;
unsigned int flags = 0;
@@ -32,16 +31,34 @@ static void v4l2_of_parse_csi_bus(const struct
device_node *node, prop = of_find_property(node, data-lanes, NULL);
if (prop) {
const __be32 *lane = NULL;
- int i;
+ unsigned int i;
- for (i = 0; i ARRAY_SIZE(data_lanes); i++) {
- lane = of_prop_next_u32(prop, lane, data_lanes[i]);
+ for (i = 0; i ARRAY_SIZE(bus-data_lanes); i++) {
+ lane = of_prop_next_u32(prop, lane, v);
if (!lane)
break;
+ bus-data_lanes[i] = v;
}
bus-num_data_lanes = i;
- while (i--)
- bus-data_lanes[i] = data_lanes[i];
+ }
+
+ prop = of_find_property(node, lane-polarities, NULL);
+ if (prop) {
+ const __be32 *polarity = NULL;
+ unsigned int i;
+
+ for (i = 0; i ARRAY_SIZE(bus-lane_polarities); i++) {
+ polarity = of_prop_next_u32(prop, polarity, v);
+ if (!polarity)
+ break;
+ bus-lane_polarities[i] = v;
+ }
+
+ if (i 1 + bus-num_data_lanes /* clock + data */) {
+ pr_warn(%s: too few lane-polarities entries (need %u,
got
%u)\n,
+ node-full_name, 1 + bus-num_data_lanes, i);
+ return -EINVAL;
+ }
}
if (!of_property_read_u32(node, clock-lanes, v)) {
@@ -56,6 +73,8 @@ static void v4l2_of_parse_csi_bus(const struct device_node
*node,
bus-flags = flags;
endpoint-bus_type = V4L2_MBUS_CSI2;
+
+ return 0;
}
static void v4l2_of_parse_parallel_bus(const struct device_node *node,
@@ -127,11 +146,15 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node, int v4l2_of_parse_endpoint(const struct device_node
*node,
struct v4l2_of_endpoint *endpoint)
{
+ int rval;
+
of_graph_parse_endpoint(node, endpoint-base);
endpoint-bus_type = 0;
memset(endpoint-bus, 0, sizeof(endpoint-bus));
- v4l2_of_parse_csi_bus(node, endpoint);
+ rval = v4l2_of_parse_csi_bus(node, endpoint);
+ if (rval)
+ return rval;
/*
* Parse the parallel video bus properties only if none
* of the MIPI CSI-2 specific properties were found.
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 70fa7b7..2de42c5 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -29,12 +29,15 @@ struct device_node;
* @data_lanes: an array of physical data lane indexes
* @clock_lane: physical lane index of the clock lane
* @num_data_lanes: number of data lanes
+ * @lane_polarities: polarity of the lanes. The order is the same of
+ * the physical lanes.
*/
struct v4l2_of_bus_mipi_csi2 {
unsigned int flags;
unsigned char data_lanes[4];
unsigned char clock_lane;
unsigned short num_data_lanes;
+ bool lane_polarities[5];
};
/**
--
Regards,
Laurent Pinchart
--
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 14/15] omap3isp: Add support for the Device Tree
= 0;
ret = dma_coerce_mask_and_coherent(isp-dev, DMA_BIT_MASK(32));
@@ -2346,6 +2526,11 @@ static int isp_probe(struct platform_device *pdev)
goto error_isp;
}
+ if (!IS_ENABLED(CONFIG_OF) || !pdev-dev.of_node) {
+ isp-syscon_offset = isp_res_maps[m].syscon_offset;
+ isp-phy_type = isp_res_maps[m].phy_type;
+ }
+
for (i = 1; i OMAP3_ISP_IOMEM_CSI2A_REGS1; i++)
isp-mmio_base[i] =
isp-mmio_base[0] + isp_res_maps[m].offset[i];
@@ -2358,15 +2543,6 @@ static int isp_probe(struct platform_device *pdev)
isp-mmio_hist_base_phys =
mem-start + isp_res_maps[m].offset[OMAP3_ISP_IOMEM_HIST];
- isp-syscon = syscon_regmap_lookup_by_pdevname(syscon.0);
- if (IS_ERR(isp-syscon)) {
- ret = PTR_ERR(isp-syscon);
- goto error_isp;
- }
-
- isp-syscon_offset = isp_res_maps[m].syscon_offset;
- isp-phy_type = isp_res_maps[m].phy_type;
-
/* IOMMU */
ret = isp_attach_iommu(isp);
if (ret 0) {
@@ -2394,6 +2570,9 @@ static int isp_probe(struct platform_device *pdev)
if (ret 0)
goto error_iommu;
+ isp-notifier.bound = isp_subdev_notifier_bound;
+ isp-notifier.complete = isp_subdev_notifier_complete;
+
ret = isp_register_entities(isp);
if (ret 0)
goto error_modules;
@@ -2429,6 +2608,11 @@ static struct platform_device_id omap3isp_id_table[]
= { };
MODULE_DEVICE_TABLE(platform, omap3isp_id_table);
+static const struct of_device_id omap3isp_of_table[] = {
+ { .compatible = ti,omap3-isp },
+ { },
+};
+
static struct platform_driver omap3isp_driver = {
.probe = isp_probe,
.remove = isp_remove,
@@ -2436,6 +2620,7 @@ static struct platform_driver omap3isp_driver = {
.driver = {
.name = omap3isp,
.pm = omap3isp_pm_ops,
+ .of_match_table = omap3isp_of_table,
},
};
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h index dcb7d20..431224e 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -18,6 +18,7 @@
#define OMAP3_ISP_CORE_H
#include media/omap3isp.h
+#include media/v4l2-async.h
#include media/v4l2-device.h
#include linux/clk-provider.h
#include linux/device.h
@@ -178,6 +179,7 @@ struct isp_xclk {
*/
struct isp_device {
struct v4l2_device v4l2_dev;
+ struct v4l2_async_notifier notifier;
struct media_device media_dev;
struct device *dev;
u32 revision;
@@ -224,6 +226,15 @@ struct isp_device {
unsigned int sbl_resources;
unsigned int subclk_resources;
+
+#define ISP_MAX_SUBDEVS 8
+ struct v4l2_subdev *subdevs[ISP_MAX_SUBDEVS];
+};
+
+struct isp_async_subdev {
+ struct v4l2_subdev *sd;
+ struct isp_bus_cfg bus;
+ struct v4l2_async_subdev asd;
};
#define v4l2_dev_to_isp_device(dev) \
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c index d91dde1..495447d 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -173,6 +173,13 @@ static int omap3isp_csiphy_config(struct isp_csiphy
*phy) unsigned int i;
u32 reg;
+ if (!buscfg) {
+ struct isp_async_subdev *isd =
+ container_of(pipe-external-asd,
+ struct isp_async_subdev, asd);
+ buscfg = isd-bus;
+ }
+
if (buscfg-interface == ISP_INTERFACE_CCP2B_PHY1
|| buscfg-interface == ISP_INTERFACE_CCP2B_PHY2)
lanes = buscfg-bus.ccp2.lanecfg;
--
Regards,
Laurent Pinchart
--
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 15/15] omap3isp: Deprecate platform data support
Hi Sakari, Thank you for the patch. On Monday 16 March 2015 02:26:10 Sakari Ailus wrote: Print a warning when the driver is used with platform data. Existing platform data user should move to DT now. s/user/users/ Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/platform/omap3isp/isp.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index 0d6012a..82940fe 100644 --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -2447,6 +2447,8 @@ static int isp_probe(struct platform_device *pdev) isp-syscon = syscon_regmap_lookup_by_pdevname(syscon.0); if (IS_ERR(isp-syscon)) return PTR_ERR(isp-syscon); + dev_warn(pdev-dev, + Platform data support is deprecated! Please move to DT now! \n); } isp-autoidle = autoidle; -- Regards, Laurent Pinchart -- 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 12/15] dt: bindings: Add lane-polarity property to endpoint nodes
Hi Sakari, Thank you for the patch. On Monday 16 March 2015 02:26:07 Sakari Ailus wrote: Add lane-polarity property to endpoint nodes. This essentially tells that the order of the differential signal wires is inverted. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/devicetree/bindings/media/video-interfaces.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 571b4c6..27cfa4e 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -106,6 +106,12 @@ Optional endpoint properties - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array of 64-bit unsigned integers. +- lane-polarity: an array of polarities of the lanes starting from the clock + lane and followed by the data lanes in the same order as in data-lanes. + Valid values are 0 (normal) and 1 (inverted). The length of the array + should be the combined length of data-lanes and clock-lanes properties. + If the lane-polarity property is omitted, the value must be interpreted as 0 + (normal). This property is valid for serial busses only. Example -- Regards, Laurent Pinchart -- 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 13/15] v4l: of: Read lane-polarity endpoint property
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:26:08 Sakari Ailus wrote:
Add lane_polarity field to struct v4l2_of_bus_mipi_csi2 and write the
contents of the lane polarity property to it. The field tells the polarity
of the physical lanes starting from the first one. Any unused lanes are
ignored, i.e. only the polarity of the used lanes is specified.
Also rework reading the data-lanes property a little.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/v4l2-core/v4l2-of.c | 41 ++
include/media/v4l2-of.h |3 +++
2 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c index b4ed9a9..e44cc15 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -19,11 +19,10 @@
#include media/v4l2-of.h
-static void v4l2_of_parse_csi_bus(const struct device_node *node,
- struct v4l2_of_endpoint *endpoint)
+static int v4l2_of_parse_csi_bus(const struct device_node *node,
+ struct v4l2_of_endpoint *endpoint)
{
struct v4l2_of_bus_mipi_csi2 *bus = endpoint-bus.mipi_csi2;
- u32 data_lanes[ARRAY_SIZE(bus-data_lanes)];
struct property *prop;
bool have_clk_lane = false;
unsigned int flags = 0;
@@ -32,16 +31,34 @@ static void v4l2_of_parse_csi_bus(const struct
device_node *node, prop = of_find_property(node, data-lanes, NULL);
if (prop) {
const __be32 *lane = NULL;
- int i;
+ unsigned int i;
- for (i = 0; i ARRAY_SIZE(data_lanes); i++) {
- lane = of_prop_next_u32(prop, lane, data_lanes[i]);
+ for (i = 0; i ARRAY_SIZE(bus-data_lanes); i++) {
+ lane = of_prop_next_u32(prop, lane, v);
if (!lane)
break;
+ bus-data_lanes[i] = v;
}
bus-num_data_lanes = i;
- while (i--)
- bus-data_lanes[i] = data_lanes[i];
+ }
+
+ prop = of_find_property(node, lane-polarity, NULL);
+ if (prop) {
+ const __be32 *polarity = NULL;
+ unsigned int i;
+
+ for (i = 0; i ARRAY_SIZE(bus-lane_polarity); i++) {
+ polarity = of_prop_next_u32(prop, polarity, v);
+ if (!polarity)
+ break;
+ bus-lane_polarity[i] = v;
+ }
+
+ if (i 1 + bus-num_data_lanes /* clock + data */) {
+ pr_warn(bad size of lane-polarity array in node %s,
was %u,
should be
%u\n,
How about
pr_warn(%s: too few lane-polarity entries (need %u, got %u)\n,
node-full_name, 1 + bus-num_data_lanes, i);
+ node-full_name, i, 1 + bus-num_data_lanes);
+ return -EINVAL;
+ }
}
if (!of_property_read_u32(node, clock-lanes, v)) {
@@ -56,6 +73,8 @@ static void v4l2_of_parse_csi_bus(const struct device_node
*node,
bus-flags = flags;
endpoint-bus_type = V4L2_MBUS_CSI2;
+
+ return 0;
}
static void v4l2_of_parse_parallel_bus(const struct device_node *node,
@@ -127,11 +146,15 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node, int v4l2_of_parse_endpoint(const struct device_node
*node,
struct v4l2_of_endpoint *endpoint)
{
+ int rval;
+
of_graph_parse_endpoint(node, endpoint-base);
endpoint-bus_type = 0;
memset(endpoint-bus, 0, sizeof(endpoint-bus));
- v4l2_of_parse_csi_bus(node, endpoint);
+ rval = v4l2_of_parse_csi_bus(node, endpoint);
+ if (rval)
+ return rval;
/*
* Parse the parallel video bus properties only if none
* of the MIPI CSI-2 specific properties were found.
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 70fa7b7..a70eb52 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -29,12 +29,15 @@ struct device_node;
* @data_lanes: an array of physical data lane indexes
* @clock_lane: physical lane index of the clock lane
* @num_data_lanes: number of data lanes
+ * @lane_polarity: polarity of the lanes. The order is the same of
+ * the physical lanes.
*/
struct v4l2_of_bus_mipi_csi2 {
unsigned int flags;
unsigned char data_lanes[4];
unsigned char clock_lane;
unsigned short num_data_lanes;
+ bool lane_polarity[5];
A bit of bike-shedding here, should this be lane_polarities ? And, thinking
about it, should the DT property be renamed to lane-polarities as well ?
This would match data-lanes.
};
/**
--
Regards,
Laurent Pinchart
--
To unsubscribe from
Re: [PATCH 1/4] arm: dts: omap3: Extend the syscon register range
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:01:17 Sakari Ailus wrote:
The OMAP 3630 syscon register set was missing
OMAP3630_CONTROL_CAMERA_PHY_CTRL register at offset 0x2f0. This register
used to be mapped directly by the omap3isp driver, which is now moving to
use syscon instead. The omap3isp driver did not support DT so no driver
change is needed in this patch.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/boot/dts/omap3.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 01b7111..fe0b293 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -183,7 +183,7 @@
omap3_scm_general: tisyscon@48002270 {
compatible = syscon;
- reg = 0x48002270 0x2f0;
+ reg = 0x48002270 0x2f4;
};
pbias_regulator: pbias_regulator {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] arm: dts: omap3: Add DT entries for OMAP 3
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:01:19 Sakari Ailus wrote:
The resources the ISP needs are slightly different on 3[45]xx and 3[67]xx.
Especially the phy-type property is different.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/boot/dts/omap34xx.dtsi | 17 +
arch/arm/boot/dts/omap36xx.dtsi | 17 +
2 files changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/omap34xx.dtsi
b/arch/arm/boot/dts/omap34xx.dtsi index 3819c1e..7bc8c0f 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -8,6 +8,8 @@
* kind, whether express or implied.
*/
+#include dt-bindings/media/omap3-isp.h
+
#include omap3.dtsi
/ {
@@ -37,6 +39,21 @@
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0xff1f;
};
+
+ isp: isp@480bc000 {
+ compatible = ti,omap3-isp;
+ reg = 0x480bc000 0x12fc
+0x480bd800 0x017c;
+ interrupts = 24;
+ iommus = mmu_isp;
+ syscon = omap3_scm_general 0xdc;
+ ti,phy-type = OMAP3ISP_PHY_TYPE_COMPLEX_IO;
+ #clock-cells = 1;
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/omap36xx.dtsi
b/arch/arm/boot/dts/omap36xx.dtsi index 541704a..3502fe0 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -8,6 +8,8 @@
* kind, whether express or implied.
*/
+#include dt-bindings/media/omap3-isp.h
+
#include omap3.dtsi
/ {
@@ -69,6 +71,21 @@
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0xff1f;
};
+
+ isp: isp@480bc000 {
+ compatible = ti,omap3-isp;
+ reg = 0x480bc000 0x12fc
+0x480bd800 0x0600;
+ interrupts = 24;
+ iommus = mmu_isp;
+ syscon = omap3_scm_general 0x2f0;
+ ti,phy-type = OMAP3ISP_PHY_TYPE_CSIPHY;
+ #clock-cells = 1;
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+ };
};
};
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm: dts: n950, n9: Add primary camera support
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:01:20 Sakari Ailus wrote:
Add support for the primary camera of the Nokia N950 and N9.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
arch/arm/boot/dts/omap3-n9.dts | 37 +++
arch/arm/boot/dts/omap3-n950.dts | 37 +++
2 files changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
index 9938b5d..7711df1 100644
--- a/arch/arm/boot/dts/omap3-n9.dts
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -16,3 +16,40 @@
model = Nokia N9;
compatible = nokia,omap3-n9, ti,omap36xx, ti,omap3;
};
+
+i2c2 {
+ smia_1: camera@10 {
+ compatible = nokia,smia;
+ reg = 0x10;
+ /* No reset gpio */
+ vana-supply = vaux3;
+ clocks = isp 0;
+ clock-frequency = 960;
+ nokia,nvm-size = (16 * 64);
+ port {
+ smia_1_1: endpoint {
+ link-frequencies = /bits/ 64 19920
21000 49920;
+ clock-lanes = 0;
+ data-lanes = 1 2;
+ remote-endpoint = csi2a_ep;
+ };
+ };
+ };
+};
+
+isp {
+ vdd-csiphy1-supply = vaux2;
+ vdd-csiphy2-supply = vaux2;
+ ports {
+ port@2 {
+ reg = 2;
+ csi2a_ep: endpoint {
+ remote-endpoint = smia_1_1;
+ clock-lanes = 2;
+ data-lanes = 1 3;
+ crc = 1;
+ lane-polarity = 1 1 1;
+ };
+ };
+ };
+};
Wouldn't it make sense to move the common parts to arch/arm/boot/dts/omap3-
n950-n9.dtsi ?
diff --git a/arch/arm/boot/dts/omap3-n950.dts
b/arch/arm/boot/dts/omap3-n950.dts index 261c558..761f275 100644
--- a/arch/arm/boot/dts/omap3-n950.dts
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -16,3 +16,40 @@
model = Nokia N950;
compatible = nokia,omap3-n950, ti,omap36xx, ti,omap3;
};
+
+i2c2 {
+ smia_1: camera@10 {
+ compatible = nokia,smia;
+ reg = 0x10;
+ /* No reset gpio */
+ vana-supply = vaux3;
+ clocks = isp 0;
+ clock-frequency = 960;
+ nokia,nvm-size = (16 * 64);
+ port {
+ smia_1_1: endpoint {
+ link-frequencies = /bits/ 64 21000
33360 39840;
+ clock-lanes = 0;
+ data-lanes = 1 2;
+ remote-endpoint = csi2a_ep;
+ };
+ };
+ };
+};
+
+isp {
+ vdd-csiphy1-supply = vaux2;
+ vdd-csiphy2-supply = vaux2;
+ ports {
+ port@2 {
+ reg = 2;
+ csi2a_ep: endpoint {
+ remote-endpoint = smia_1_1;
+ clock-lanes = 2;
+ data-lanes = 3 1;
+ crc = 1;
+ lane-polarity = 1 1 1;
+ };
+ };
+ };
+};
--
Regards,
Laurent Pinchart
--
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/4] dt: bindings: Add bindings for omap3isp
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:01:18 Sakari Ailus wrote:
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
.../devicetree/bindings/media/ti,omap3isp.txt | 71 +
MAINTAINERS|1 +
include/dt-bindings/media/omap3-isp.h | 22 ++
3 files changed, 94 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/ti,omap3isp.txt
create mode 100644 include/dt-bindings/media/omap3-isp.h
diff --git a/Documentation/devicetree/bindings/media/ti,omap3isp.txt
b/Documentation/devicetree/bindings/media/ti,omap3isp.txt new file mode
100644
index 000..547b493
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,omap3isp.txt
@@ -0,0 +1,71 @@
+OMAP 3 ISP Device Tree bindings
+===
+
+The DT definitions can be found in include/dt-bindings/media/omap3-isp.h.
+
+Required properties
+===
+
+compatible : must contain ti,omap3-isp
+
+reg : the two registers sets (physical address and length) for the
+ ISP. The first set contains the core ISP registers up to
+ the end of the SBL block. The second set contains the
+ CSI PHYs and receivers registers.
+interrupts : the ISP interrupt specifier
+iommus : phandle and IOMMU specifier for the IOMMU that serves
the ISP
+syscon : the phandle and register offset to the Complex I/O or
CSI-PHY
+ register
+ti,phy-type : 0 -- OMAP3ISP_PHY_TYPE_COMPLEX_IO (e.g. 3430)
+ 1 -- OMAP3ISP_PHY_TYPE_CSIPHY (e.g. 3630)
+#clock-cells : Must be 1 --- the ISP provides two external clocks,
+ cam_xclka and cam_xclkb, at indices 0 and 1,
+ respectively. Please find more information on common
+ clock bindings in ../clock/clock-bindings.txt.
+
+Port nodes (optional)
+-
+
+More documentation on these bindings is available in
+video-interfaces.txt in the same directory.
+
+reg : The interface:
+ 0 - parallel (CCDC)
+ 1 - CSIPHY1 -- CSI2C / CCP2B on 3630;
+ CSI1 -- CSIb on 3430
+ 2 - CSIPHY2 -- CSI2A / CCP2B on 3630;
+ CSI2 -- CSIa on 3430
+
+Optional properties
+===
+
+vdd-csiphy1-supply : voltage supply of the CSI-2 PHY 1
+vdd-csiphy2-supply : voltage supply of the CSI-2 PHY 2
+
+Endpoint nodes
+--
+
+lane-polarity: lane polarity (required on CSI-2)
+ 0 -- not inverted; 1 -- inverted
+data-lanes : an array of data lanes from 1 to 3. The length can
+ be either 1 or 2. (required on CSI-2)
+clock-lanes : the clock lane (from 1 to 3). (required on CSI-2)
+
+
+Example
+===
+
+ isp@480bc000 {
+ compatible = ti,omap3-isp;
+ reg = 0x480bc000 0x12fc
+0x480bd800 0x0600;
+ interrupts = 24;
+ iommus = mmu_isp;
+ syscon = omap3_scm_general 0x2f0;
+ ti,phy-type = 1;
I would use OMAP3ISP_PHY_TYPE_CSIPHY instead of 1 here. Apart from that,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
+ #clock-cells = 1;
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index af8df65..a102624 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6949,6 +6949,7 @@ OMAP IMAGING SUBSYSTEM (OMAP3 ISP and OMAP4 ISS)
M: Laurent Pinchart laurent.pinch...@ideasonboard.com
L: linux-me...@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/media/ti,omap3isp.txt
F: drivers/media/platform/omap3isp/
F: drivers/staging/media/omap4iss/
diff --git a/include/dt-bindings/media/omap3-isp.h
b/include/dt-bindings/media/omap3-isp.h new file mode 100644
index 000..b18c60e
--- /dev/null
+++ b/include/dt-bindings/media/omap3-isp.h
@@ -0,0 +1,22 @@
+/*
+ * include/dt-bindings/media/omap3-isp.h
+ *
+ * Copyright (C) 2015 Sakari Ailus
+ *
+ * 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.
+ */
+
+#ifndef __DT_BINDINGS_OMAP3_ISP_H__
+#define __DT_BINDINGS_OMAP3_ISP_H__
+
+#define OMAP3ISP_PHY_TYPE_COMPLEX_IO 0
+#define OMAP3ISP_PHY_TYPE_CSIPHY 1
+
+#endif
Re: [PATCH] media: omap3isp: hist: Move histogram DMA to DMA engine
Hi Sakari,
Thank you for the review.
On Friday 13 March 2015 01:56:32 Sakari Ailus wrote:
On Sun, Mar 08, 2015 at 11:37:55PM +0200, Laurent Pinchart wrote:
...
@@ -198,24 +177,58 @@ static void hist_dma_cb(int lch, u16 ch_status, void
*data)
static int hist_buf_dma(struct ispstat *hist)
{
dma_addr_t dma_addr = hist-active_buf-dma_addr;
+ struct dma_async_tx_descriptor *tx;
+ struct dma_slave_config cfg;
+ dma_cookie_t cookie;
+ int ret;
if (unlikely(!dma_addr)) {
dev_dbg(hist-isp-dev, hist: invalid DMA buffer address\n);
- hist_reset_mem(hist);
- return STAT_NO_BUF;
+ goto error;
}
isp_reg_writel(hist-isp, 0, OMAP3_ISP_IOMEM_HIST, ISPHIST_ADDR);
isp_reg_set(hist-isp, OMAP3_ISP_IOMEM_HIST, ISPHIST_CNT,
ISPHIST_CNT_CLEAR);
omap3isp_flush(hist-isp);
- hist-dma_config.dst_start = dma_addr;
- hist-dma_config.elem_count = hist-buf_size / sizeof(u32);
- omap_set_dma_params(hist-dma_ch, hist-dma_config);
- omap_start_dma(hist-dma_ch);
+ memset(cfg, 0, sizeof(cfg));
+ cfg.src_addr = hist-isp-mmio_base_phys[OMAP3_ISP_IOMEM_HIST]
++ ISPHIST_DATA;
+ cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.src_maxburst = hist-buf_size / 4;
How about initialising the struct when you declare it instead? That might be
a matter of opinion though, but I think I prefer that. Up to you.
I sometimes agree with this argument, but in this case the separation between
initialization and usage of the structure would in my opinion impede
readability.
I've also checked the code generated by the compiler, and except for memset
being replaced by __memzero, initializing the structure at declaration time
doesn't make a difference.
Acked-by: Sakari Ailus sakari.ai...@iki.fi
--
Regards,
Laurent Pinchart
--
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] media: omap3isp: hist: Move histogram DMA to DMA engine
Replace the custom OMAP DMA API usage by DMA engine. Feature-wise the
driver has lost the ability to get notified of DMA transfers failure
through the completion handler, as the DMA engine API doesn't expose
that status information.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isph3a_aewb.c | 1 -
drivers/media/platform/omap3isp/isph3a_af.c | 1 -
drivers/media/platform/omap3isp/isphist.c | 128 --
drivers/media/platform/omap3isp/ispstat.c | 2 +-
drivers/media/platform/omap3isp/ispstat.h | 5 +-
5 files changed, 80 insertions(+), 57 deletions(-)
This patch conflicts with Sakari's omap3isp DT series, which should get merged
in v4.1. One of the two will need to be rebased. That shouldn't be a big issue
as the conflict is minor.
I've tested the patch on a Beagleboard-xM with the snapshot application from
omap3-isp-live (git://git.ideasonboard.org/omap3-isp-live.git, histogram
branch). Only histogram capture has been validated, the content of the
histogram hasn't been checked.
diff --git a/drivers/media/platform/omap3isp/isph3a_aewb.c
b/drivers/media/platform/omap3isp/isph3a_aewb.c
index b208c54..ccaf92f 100644
--- a/drivers/media/platform/omap3isp/isph3a_aewb.c
+++ b/drivers/media/platform/omap3isp/isph3a_aewb.c
@@ -297,7 +297,6 @@ int omap3isp_h3a_aewb_init(struct isp_device *isp)
aewb-ops = h3a_aewb_ops;
aewb-priv = aewb_cfg;
- aewb-dma_ch = -1;
aewb-event_type = V4L2_EVENT_OMAP3ISP_AEWB;
aewb-isp = isp;
diff --git a/drivers/media/platform/omap3isp/isph3a_af.c
b/drivers/media/platform/omap3isp/isph3a_af.c
index 8a83e19..92937f7 100644
--- a/drivers/media/platform/omap3isp/isph3a_af.c
+++ b/drivers/media/platform/omap3isp/isph3a_af.c
@@ -360,7 +360,6 @@ int omap3isp_h3a_af_init(struct isp_device *isp)
af-ops = h3a_af_ops;
af-priv = af_cfg;
- af-dma_ch = -1;
af-event_type = V4L2_EVENT_OMAP3ISP_AF;
af-isp = isp;
diff --git a/drivers/media/platform/omap3isp/isphist.c
b/drivers/media/platform/omap3isp/isphist.c
index ce822c3..738b946 100644
--- a/drivers/media/platform/omap3isp/isphist.c
+++ b/drivers/media/platform/omap3isp/isphist.c
@@ -16,20 +16,18 @@
*/
#include linux/delay.h
+#include linux/device.h
+#include linux/dmaengine.h
+#include linux/omap-dmaengine.h
#include linux/slab.h
#include linux/uaccess.h
-#include linux/device.h
#include isp.h
#include ispreg.h
#include isphist.h
-#define OMAP24XX_DMA_NO_DEVICE 0
-
#define HIST_CONFIG_DMA1
-#define HIST_USING_DMA(hist) ((hist)-dma_ch = 0)
-
/*
* hist_reset_mem - clear Histogram memory before start stats engine.
*/
@@ -62,20 +60,6 @@ static void hist_reset_mem(struct ispstat *hist)
hist-wait_acc_frames = conf-num_acc_frames;
}
-static void hist_dma_config(struct ispstat *hist)
-{
- struct isp_device *isp = hist-isp;
-
- hist-dma_config.data_type = OMAP_DMA_DATA_TYPE_S32;
- hist-dma_config.sync_mode = OMAP_DMA_SYNC_ELEMENT;
- hist-dma_config.frame_count = 1;
- hist-dma_config.src_amode = OMAP_DMA_AMODE_CONSTANT;
- hist-dma_config.src_start = isp-mmio_base_phys[OMAP3_ISP_IOMEM_HIST]
- + ISPHIST_DATA;
- hist-dma_config.dst_amode = OMAP_DMA_AMODE_POST_INC;
- hist-dma_config.src_or_dst_synch = OMAP_DMA_SRC_SYNC;
-}
-
/*
* hist_setup_regs - Helper function to update Histogram registers.
*/
@@ -176,17 +160,12 @@ static int hist_busy(struct ispstat *hist)
ISPHIST_PCR_BUSY;
}
-static void hist_dma_cb(int lch, u16 ch_status, void *data)
+static void hist_dma_cb(void *data)
{
struct ispstat *hist = data;
- if (ch_status ~OMAP_DMA_BLOCK_IRQ) {
- dev_dbg(hist-isp-dev, hist: DMA error. status = 0x%04x\n,
- ch_status);
- omap_stop_dma(lch);
- hist_reset_mem(hist);
- atomic_set(hist-buf_err, 1);
- }
+ /* FIXME: The DMA engine API can't report transfer errors :-/ */
+
isp_reg_clr(hist-isp, OMAP3_ISP_IOMEM_HIST, ISPHIST_CNT,
ISPHIST_CNT_CLEAR);
@@ -198,24 +177,58 @@ static void hist_dma_cb(int lch, u16 ch_status, void
*data)
static int hist_buf_dma(struct ispstat *hist)
{
dma_addr_t dma_addr = hist-active_buf-dma_addr;
+ struct dma_async_tx_descriptor *tx;
+ struct dma_slave_config cfg;
+ dma_cookie_t cookie;
+ int ret;
if (unlikely(!dma_addr)) {
dev_dbg(hist-isp-dev, hist: invalid DMA buffer address\n);
- hist_reset_mem(hist);
- return STAT_NO_BUF;
+ goto error;
}
isp_reg_writel(hist-isp, 0, OMAP3_ISP_IOMEM_HIST, ISPHIST_ADDR);
isp_reg_set(hist-isp, OMAP3_ISP_IOMEM_HIST, ISPHIST_CNT,
ISPHIST_CNT_CLEAR
Re: [RFC 10/18] omap3isp: Move the syscon register out of the ISP register maps
Hi Sakari,
Thank you for the patch.
(CC'ing linux-omap and Tony)
On Saturday 07 March 2015 23:41:07 Sakari Ailus wrote:
The syscon register isn't part of the ISP, use it through the syscom driver
regmap instead. The syscom block is considered to be from 343x on ISP
revision 2.0 whereas 15.0 is assumed to have 3630 syscon.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
arch/arm/boot/dts/omap3.dtsi|2 +-
arch/arm/mach-omap2/devices.c | 10 --
drivers/media/platform/omap3isp/isp.c | 19 +++
drivers/media/platform/omap3isp/isp.h | 19 +--
drivers/media/platform/omap3isp/ispcsiphy.c | 20 +---
You might be asked to split the patch into two, let's see what Tony says.
5 files changed, 42 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 01b7111..fe0b293 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -183,7 +183,7 @@
omap3_scm_general: tisyscon@48002270 {
compatible = syscon;
- reg = 0x48002270 0x2f0;
+ reg = 0x48002270 0x2f4;
};
pbias_regulator: pbias_regulator {
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1afb50d..e945957 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -143,16 +143,6 @@ 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 = 24 + OMAP_INTC_START,
.flags = IORESOURCE_IRQ,
}
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c index 68d7edfc..4ff4bbd 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -51,6 +51,7 @@
#include linux/dma-mapping.h
#include linux/i2c.h
#include linux/interrupt.h
+#include linux/mfd/syscon.h
#include linux/module.h
#include linux/omap-iommu.h
#include linux/platform_device.h
@@ -94,8 +95,9 @@ 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_343X_CONTROL_CSIRXFE,
+1 OMAP3_ISP_IOMEM_CSIPHY2,
+ .syscon_offset = 0xdc,
+ .phy_type = ISP_PHY_TYPE_3430,
},
{
.isp_rev = ISP_REVISION_15_0,
@@ -112,8 +114,9 @@ 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_3630_CONTROL_CAMERA_PHY_CTRL,
+1 OMAP3_ISP_IOMEM_CSI2C_REGS2,
+ .syscon_offset = 0x2f0,
+ .phy_type = ISP_PHY_TYPE_3630,
},
};
@@ -2352,6 +2355,14 @@ static int isp_probe(struct platform_device *pdev)
}
}
+ isp-syscon = syscon_regmap_lookup_by_pdevname(syscon.0);
+ isp-syscon_offset = isp_res_maps[m].syscon_offset;
+ isp-phy_type = isp_res_maps[m].phy_type;
You could move those two lines after the error check to keep the check closer
to the source of error.
Apart from that,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
+ if (IS_ERR(isp-syscon)) {
+ ret = PTR_ERR(isp-syscon);
+ goto error_isp;
+ }
+
/* IOMMU */
ret = isp_attach_iommu(isp);
if (ret 0) {
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h index 9535524..03d2129 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -59,8 +59,6 @@ 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
};
@@ -93,14 +91,25 @@ enum isp_subclk_resource {
/* ISP2P: OMAP 36xx */
#define ISP_REVISION_15_00xF0
Re: [RFC 11/18] omap3isp: Replace many MMIO regions by two
Hi Sakari,
Thank you for the patch.
(CC'ing linux-omap and Tony)
On Saturday 07 March 2015 23:41:08 Sakari Ailus wrote:
The omap3isp MMIO register block is contiguous in the MMIO register space
apart from the fact that the ISP IOMMU register block is in the middle of
the area. Ioremap it at two occasions, and keep the rest of the layout of
the register space internal to the omap3isp driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/devices.c | 66 +--
arch/arm/mach-omap2/omap34xx.h| 36 +--
Once again you might be asked to split this. However, it would be pretty
painful, so it would be nice if we could merge everything through the Linux
media tree. You will need an ack from Tony.
drivers/media/platform/omap3isp/isp.c | 113 --
drivers/media/platform/omap3isp/isp.h |4 +-
4 files changed, 66 insertions(+), 153 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index e945957..990338f 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -74,72 +74,12 @@ omap_postcore_initcall(omap3_l3_init);
static struct resource omap3isp_resources[] = {
{
.start = OMAP3430_ISP_BASE,
- .end= OMAP3430_ISP_END,
+ .end= OMAP3430_ISP_BASE + 0x12fc,
.flags = IORESOURCE_MEM,
},
{
- .start = OMAP3430_ISP_CCP2_BASE,
- .end= OMAP3430_ISP_CCP2_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_CCDC_BASE,
- .end= OMAP3430_ISP_CCDC_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_HIST_BASE,
- .end= OMAP3430_ISP_HIST_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_H3A_BASE,
- .end= OMAP3430_ISP_H3A_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_PREV_BASE,
- .end= OMAP3430_ISP_PREV_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_RESZ_BASE,
- .end= OMAP3430_ISP_RESZ_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_SBL_BASE,
- .end= OMAP3430_ISP_SBL_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_CSI2A_REGS1_BASE,
- .end= OMAP3430_ISP_CSI2A_REGS1_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3430_ISP_CSIPHY2_BASE,
- .end= OMAP3430_ISP_CSIPHY2_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3630_ISP_CSI2A_REGS2_BASE,
- .end= OMAP3630_ISP_CSI2A_REGS2_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3630_ISP_CSI2C_REGS1_BASE,
- .end= OMAP3630_ISP_CSI2C_REGS1_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3630_ISP_CSIPHY1_BASE,
- .end= OMAP3630_ISP_CSIPHY1_END,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP3630_ISP_CSI2C_REGS2_BASE,
- .end= OMAP3630_ISP_CSI2C_REGS2_END,
+ .start = OMAP3430_ISP_BASE2,
+ .end= OMAP3430_ISP_BASE2 + 0x0600,
.flags = IORESOURCE_MEM,
},
{
diff --git a/arch/arm/mach-omap2/omap34xx.h b/arch/arm/mach-omap2/omap34xx.h
index c0d1b4b..ed0024d 100644
--- a/arch/arm/mach-omap2/omap34xx.h
+++ b/arch/arm/mach-omap2/omap34xx.h
@@ -46,39 +46,9 @@
#define OMAP34XX_IC_BASE 0x4820
-#define OMAP3430_ISP_BASE(L4_34XX_BASE + 0xBC000)
-#define OMAP3430_ISP_CBUFF_BASE (OMAP3430_ISP_BASE + 0x0100)
-#define OMAP3430_ISP_CCP2_BASE (OMAP3430_ISP_BASE + 0x0400)
-#define OMAP3430_ISP_CCDC_BASE (OMAP3430_ISP_BASE + 0x0600)
-#define OMAP3430_ISP_HIST_BASE (OMAP3430_ISP_BASE + 0x0A00)
-#define OMAP3430_ISP_H3A_BASE(OMAP3430_ISP_BASE + 0x0C00)
-#define OMAP3430_ISP_PREV_BASE (OMAP3430_ISP_BASE + 0x0E00)
-#define OMAP3430_ISP_RESZ_BASE (OMAP3430_ISP_BASE + 0x1000)
-#define OMAP3430_ISP_SBL_BASE
Re: [PATCH 06/21] drm/omap: check CRTC color format earlier
Hi Tomi,
On Monday 02 March 2015 11:55:48 Tomi Valkeinen wrote:
On 27/02/15 14:07, Daniel Vetter wrote:
On Thu, Feb 26, 2015 at 03:20:14PM +0200, Tomi Valkeinen wrote:
When setting a color format to a DRM plane, the DRM core checks whether
the format is supported by the HW. However, it seems that when setting
the color format of a CRTC (i.e. a root plane), there's no checking
done. This causes omapdrm to configure omapdss with the bad color
format, which omapdss then rejects.
While the above is ok, the error message is a bit confusing, and the
configuring of omapdss happens asynchronously from the ioctl that does
the color format change.
This patch adds a color format check to omap_plane_mode_set() which
causes the ioctl to return an error for invalid color format. This means
that the userspace will get to know of the wrong setting, instead of the
current behavior where the error is not seen by the userspace.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c index 1f4f2b866379..bedd6f7af0f1
100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -207,6 +207,24 @@ int omap_plane_mode_set(struct drm_plane *plane,
{
struct omap_plane *omap_plane = to_omap_plane(plane);
struct omap_drm_window *win = omap_plane-win;
+ int i;
+
+ /*
+ * Check whether this plane supports the fb pixel format.
+ * I don't think this should really be needed, but it looks like the
+ * drm core only checks the format for planes, not for the crtc. So
+ * when setting the format for crtc, without this check we would
+ * get an error later when trying to program the color format into
the
+ * HW.
+ */
I think we should add a format check to the setcrtc ioctl if crtc-primary
is set. Atm the code is in __setplane_internal but could easily be shared
- there's already a copy in drm_atomi.c.
Omapdrm wouldn't benefit from this yet since it doesn't support universal
planes. But adding universal planes should be on your todo anyway ;-)
Laurent is working on universal planes and atomic modesetting for
omapdrm. In fact, I think universal planes is already done in his WIP
branch.
So, if this check is already done with universal planes (if I understood
correctly), I'm fine with dropping this patch.
Yes, I've implemented universal plane support. I'm currently rebasing your
patches on top of my bug fixes (excluding the more intrusive atomic update
rework). I'll push the resulting branch shortly and will send the patches for
review.
--
Regards,
Laurent Pinchart
--
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 06/21] drm/omap: check CRTC color format earlier
Hi Daniel,
On Friday 27 February 2015 13:07:57 Daniel Vetter wrote:
On Thu, Feb 26, 2015 at 03:20:14PM +0200, Tomi Valkeinen wrote:
When setting a color format to a DRM plane, the DRM core checks whether
the format is supported by the HW. However, it seems that when setting
the color format of a CRTC (i.e. a root plane), there's no checking
done. This causes omapdrm to configure omapdss with the bad color
format, which omapdss then rejects.
While the above is ok, the error message is a bit confusing, and the
configuring of omapdss happens asynchronously from the ioctl that does
the color format change.
This patch adds a color format check to omap_plane_mode_set() which
causes the ioctl to return an error for invalid color format. This means
that the userspace will get to know of the wrong setting, instead of the
current behavior where the error is not seen by the userspace.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c index 1f4f2b866379..bedd6f7af0f1
100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -207,6 +207,24 @@ int omap_plane_mode_set(struct drm_plane *plane,
{
struct omap_plane *omap_plane = to_omap_plane(plane);
struct omap_drm_window *win = omap_plane-win;
+ int i;
+
+ /*
+* Check whether this plane supports the fb pixel format.
+* I don't think this should really be needed, but it looks like the
+* drm core only checks the format for planes, not for the crtc. So
+* when setting the format for crtc, without this check we would
+* get an error later when trying to program the color format into
the
+* HW.
+*/
I think we should add a format check to the setcrtc ioctl if crtc-primary
is set. Atm the code is in __setplane_internal but could easily be shared
- there's already a copy in drm_atomi.c.
I'll submit a patch.
Omapdrm wouldn't benefit from this yet since it doesn't support universal
planes. But adding universal planes should be on your todo anyway ;-)
Soon, soon :-)
+ for (i = 0; i plane-format_count; i++)
+ if (fb-pixel_format == plane-format_types[i])
+ break;
+ if (i == plane-format_count) {
+ DBG(Invalid pixel format %s,
+ drm_get_format_name(fb-pixel_format));
+ return -EINVAL;
+ }
win-crtc_x = crtc_x;
win-crtc_y = crtc_y;
--
Regards,
Laurent Pinchart
--
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 01/10] media: omap3isp: remove unused clkdev
Hi Russell,
On Monday 02 March 2015 17:06:06 Russell King wrote:
No merged platform supplies xclks via platform data. As we want to
slightly change the clkdev interface, rather than fixing this unused
code, remove it instead.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
There are quite a few out of tree users that I know of that might be impacted.
On the other hand, out of tree isn't an excuse, and OMAP3 platforms should
move to DT. The good news is that DT support for the omap3isp driver is about
to get submitted, and hopefully merged in v4.1. I thus have no objection to
this patch.
Sakari, does it conflict with the omap3isp DT support ? If so, how would you
prefer to resolve the conflict ? Russell, would it be fine to merge this
through Mauro's tree ?
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.c | 18 --
drivers/media/platform/omap3isp/isp.h | 1 -
include/media/omap3isp.h | 6 --
3 files changed, 25 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c index deca80903c3a..4d8078b9d010
100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -281,7 +281,6 @@ static const struct clk_init_data isp_xclk_init_data = {
static int isp_xclk_init(struct isp_device *isp)
{
- struct isp_platform_data *pdata = isp-pdata;
struct clk_init_data init;
unsigned int i;
@@ -311,20 +310,6 @@ static int isp_xclk_init(struct isp_device *isp)
xclk-clk = clk_register(NULL, xclk-hw);
if (IS_ERR(xclk-clk))
return PTR_ERR(xclk-clk);
-
- if (pdata-xclks[i].con_id == NULL
- pdata-xclks[i].dev_id == NULL)
- continue;
-
- xclk-lookup = kzalloc(sizeof(*xclk-lookup), GFP_KERNEL);
- if (xclk-lookup == NULL)
- return -ENOMEM;
-
- xclk-lookup-con_id = pdata-xclks[i].con_id;
- xclk-lookup-dev_id = pdata-xclks[i].dev_id;
- xclk-lookup-clk = xclk-clk;
-
- clkdev_add(xclk-lookup);
}
return 0;
@@ -339,9 +324,6 @@ static void isp_xclk_cleanup(struct isp_device *isp)
if (!IS_ERR(xclk-clk))
clk_unregister(xclk-clk);
-
- if (xclk-lookup)
- clkdev_drop(xclk-lookup);
}
}
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h index cfdfc8714b6b..d41c98bbdfe7
100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -122,7 +122,6 @@ enum isp_xclk_id {
struct isp_xclk {
struct isp_device *isp;
struct clk_hw hw;
- struct clk_lookup *lookup;
struct clk *clk;
enum isp_xclk_id id;
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index 398279dd1922..a9798525d01e 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -152,13 +152,7 @@ struct isp_v4l2_subdevs_group {
} bus; /* gcc 4.6.0 chokes on anonymous union initializers */
};
-struct isp_platform_xclk {
- const char *dev_id;
- const char *con_id;
-};
-
struct isp_platform_data {
- struct isp_platform_xclk xclks[2];
struct isp_v4l2_subdevs_group *subdevs;
void (*set_constraints)(struct isp_device *isp, bool enable);
};
--
Regards,
Laurent Pinchart
--
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 01/10] media: omap3isp: remove unused clkdev
Hi Russell, On Monday 02 March 2015 23:54:35 Russell King - ARM Linux wrote: (Combining replies...) On Tue, Mar 03, 2015 at 12:53:37AM +0200, Sakari Ailus wrote: Hi Laurent and Russell, On Tue, Mar 03, 2015 at 12:33:44AM +0200, Laurent Pinchart wrote: Sakari, does it conflict with the omap3isp DT support ? If so, how would you prefer to resolve the conflict ? Russell, would it be fine to merge this through Mauro's tree ? As other changes will depend on this, I'd prefer not to. The whole make clk_get() return a unique struct clk wasn't well tested, and several places broke - and currently clk_add_alias() is broken as a result of that. I'm trying to get to the longer term solution, where clkdev internally uses a struct clk_hw pointer rather than a struct clk pointer, and I want to clean stuff up first. If omap3isp needs to keep this code, then so be it - I'll come up with a different patch improving its use of clkdev instead. I'm totally fine with removing clkdev from the omap3isp driver if that's easier for you, I'm just concerned about the merge conflict that will result. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain
Hi Grygorii,
I've found this mail deep inside my inbox :-)
On Wednesday 30 July 2014 16:25:31 Grygorii Strashko wrote:
On 07/30/2014 03:06 AM, Laurent Pinchart wrote:
On Monday 28 July 2014 23:52:34 Grant Likely wrote:
On Mon, Jul 28, 2014 at 11:47 AM, Grygorii Strashko wrote:
On 07/28/2014 05:05 PM, Grant Likely wrote:
On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko wrote:
Use clkops-clocks property to specify clocks handled by
clock_ops domain PM domain. Only clocks defined in clkops-clocks
set of clocks will be handled by Runtime PM through clock_ops
Pm domain.
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/of/of_clk.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
index 35f5e9f..5f9b90e 100644
--- a/drivers/of/of_clk.c
+++ b/drivers/of/of_clk.c
@@ -86,11 +86,8 @@ int of_clk_register_runtime_pm_clocks(struct
device_node *np,
struct clk *clk;
int error;
-for (i = 0; (clk = of_clk_get(np, i)) !IS_ERR(clk); i++) {
-if (!clk_may_runtime_pm(clk)) {
-clk_put(clk);
-continue;
-}
+for (i = 0; (clk = of_clk_get_from_set(np, clkops, i))
+ !IS_ERR(clk); i++) {
This really looks like an ABI break to me. What happens to all the
existing platforms who don't have this new clkops-clocks in their
device tree?
Agree. This patch as is will break such platforms.
As possible solution for above problem - the NULL can be used as clock's
prefix by default and platform code can configure new value of clock's
prefix during initialization.
In addition, to make this solution full the of_clk_get_by_name() will
need to be modified too.
But note pls, this is pure RFC patches which I did to find out the
answer on questions: - What is better: maintain Runtime PM clocks
configuration in DT or in code?
In code. I don't think it is workable to embed runtime PM behaviour
into the DT bindings. I think there will be too much variance in what
hardware requires. We can create helpers to make this simpler, but I
don't think it is a good idea to set it up automatically without any
control from the driver itself.
- Where and when to call of_clk_register_runtime_pm_clocks()?
Bus notifier/ platform core/ device drivers
I would say in device drivers.
I tend to agree with that.
It will help here to take a step back and remember what the problem we're
trying to solve is.
At the root is clock management. Our system comprise many clocks, and they
need to be handled. The Common Clock Framework nicely models the clocks,
and offers an API for drivers to retrieve device clocks and control them.
Drivers can thus implement clock management manually without much pain.
A clock can be managed in roughly three different ways :
- it can be enabled at probe time and disabled at remove time ;
- it can be enabled right before the device leaves its idle state and
disabled when the device goes back to idle ; or
- it can be enabled and disabled in a more fine-grained, device-specific
manner.
The selected clock management granularity depends on constraints specific
to the device and on how aggressive power saving needs to be. Enabling
the clocks at probe time and disabling them at remove time is enough for
most devices, but leads to a high power consumption. For that reason the
second clock management scheme is often desired.
Managing clocks manually in the driver is a valid option. However, when
adding runtime PM to the equation, and realizing that the clocks need to
be enabled in the runtime PM resume handler and disabled in the suspend
handler, the clock management code starts looking very similar in most
drivers. We're thus tempted to factorize it away from the drivers into a
shared location.
It's important to note at this point that the goal here is only to
simplify drivers. Moving clock management code out of the drivers doesn't
(unless I'm missing something) open the door to new possibilities, it just
serves as a simplification.
Now, as Grygorii mentioned, differences between how a given IP core is
integrated in various SoCs can make clock management SoC-dependent. In the
vast majority of cases (which is really what we need to target, given that
our target is simplifying drivers) SoC integration can be described as a
list of clocks that must be managed. That list can be common to all
devices in a given SoC, or can be device-dependent as well.
That's actually a problem - now we have static list of managed clocks
per-SoC and not per device.
Few locations can be used to express a per-device list of per-SoC clocks.
We can have clocks lists in a per-SoC and per-device location, per-device
clocks lists in an SoC-specific
Re: [RFC PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain
Hi Kevin, On Monday 08 September 2014 13:13:25 Kevin Hilman wrote: Laurent Pinchart laurent.pinch...@ideasonboard.com writes: On Monday 28 July 2014 23:52:34 Grant Likely wrote: On Mon, Jul 28, 2014 at 11:47 AM, Grygorii Strashko wrote: On 07/28/2014 05:05 PM, Grant Likely wrote: On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko wrote: [...] - Where and when to call of_clk_register_runtime_pm_clocks()? Bus notifier/ platform core/ device drivers I would say in device drivers. I tend to agree with that. It will help here to take a step back and remember what the problem we're trying to solve is. [jumping in late, after Grygorii ping'd me about looking at this] Laurent, thanks for summarizing the problem so well. It helped me catchup on the discussion. You're welcome. Sorry for the very late reply. At the root is clock management. Our system comprise many clocks, and they need to be handled. The Common Clock Framework nicely models the clocks, and offers an API for drivers to retrieve device clocks and control them. Drivers can thus implement clock management manually without much pain. A clock can be managed in roughly three different ways : - it can be enabled at probe time and disabled at remove time ; - it can be enabled right before the device leaves its idle state and disabled when the device goes back to idle ; or - it can be enabled and disabled in a more fine-grained, device-specific manner. The selected clock management granularity depends on constraints specific to the device and on how aggressive power saving needs to be. Enabling the clocks at probe time and disabling them at remove time is enough for most devices, but leads to a high power consumption. For that reason the second clock management scheme is often desired. Managing clocks manually in the driver is a valid option. However, when adding runtime PM to the equation, and realizing that the clocks need to be enabled in the runtime PM resume handler and disabled in the suspend handler, the clock management code starts looking very similar in most drivers. We're thus tempted to factorize it away from the drivers into a shared location. It's important to note at this point that the goal here is only to simplify drivers. Moving clock management code out of the drivers doesn't (unless I'm missing something) open the door to new possibilities, it just serves as a simplification. I disagree. Actually, it opens up the door to lots of new possibilities that are crucial for fine-grained PM with QoS. It is not just simplification. There are many good reasons that some SoCs have moved all the management of PM-related clocks *out* of device drivers. More on that below... Now, as Grygorii mentioned, differences between how a given IP core is integrated in various SoCs can make clock management SoC-dependent. In the vast majority of cases (which is really what we need to target, given that our target is simplifying drivers) SoC integration can be described as a list of clocks that must be managed. That list can be common to all devices in a given SoC, or can be device-dependent as well. If we care about fine-grained PM, this is a way-too oversimplified version of what SoC integragion means. There are lots of pieces which fall under SoC integration, for example: clock domains, power domains, voltage domains, SoC-specific wakeup capabilities, etc. etc. Then, for fun throw in QoS constraints, and things get really exciting. IOW, if you care about fine-grained PM and QoS, you simply can't reduce SoC integration down to a list of clocks to be managed. Of course. I was talking about SoC integration for clocks, not about SoC integration in general. QoS makes this interesting as well because a device driver's decision to gate its own clocks may have serious repercussions on the wakeup latency of *other* devices in the same power domain. For example, the clock gating of the last active device in a powerdomain may cause the enclosing power- domain to be power gated, having a major impact on the wakup latency of *all* devices in that power domain. So if we're going to manage the list of PM-related clocks in the device driver, we'll also keep track of all the other devices in the same power domain, whether or not they're active, whether or not they have QoS constraints, etc. etc. Hopefully you can see that we're quickly way outside the scope of the IP block that the device driver is intended to manage. All of this is SoC integration knowledge, and IMO doen't belong in the device drivers. It belongs at the SoC integration level, and in todays kernel frameworks that means pm_domain/genpd. Ok, there's more to it than I initially thought. Let's see how we can make this happen then :-) Few locations can be used to express a per-device list of per-SoC clocks. We can have clocks
Re: [PATCH v2 12/17] iommu/omap: Integrate omap-iommu-debug into omap-iommu
Hi Suman,
Thank you for the patch.
On Wednesday 22 October 2014 17:22:30 Suman Anna wrote:
The debugfs support for OMAP IOMMU is currently implemented
as a module, warranting certain OMAP-specific IOMMU API to
be exported. The OMAP IOMMU, when enabled, can only be built-in
into the kernel, so integrate the OMAP IOMMU debug module
into the OMAP IOMMU driver. This helps in eliminating the
need to export most of the current OMAP IOMMU API.
The following are the main changes:
- The debugfs directory and entry creation logic is reversed,
the calls are invoked by the OMAP IOMMU driver now.
- The current iffy circular logic of adding IOMMU archdata
to the IOMMU devices itself to get a pointer to the omap_iommu
object in the debugfs support code is replaced by directly
using the omap_iommu structure while creating the debugfs
entries.
- The debugfs root directory is renamed from the generic name
iommu to a specific name omap_iommu.
- Unneeded headers have also been cleaned up while at this.
- There will no longer be a omap-iommu-debug.ko module after
this patch.
- The OMAP_IOMMU_DEBUG Kconfig option is converted to boolean
only, the OMAP IOMMU debugfs support is built alongside the
OMAP IOMMU driver only when this option is enabled.
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/Kconfig| 12 ++---
drivers/iommu/omap-iommu-debug.c | 100 ++-
drivers/iommu/omap-iommu.c | 11 -
drivers/iommu/omap-iommu.h | 15 ++
4 files changed, 58 insertions(+), 80 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd51122..1d54996 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -144,13 +144,13 @@ config OMAP_IOMMU
select IOMMU_API
config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU internals in DebugFS
- depends on OMAP_IOMMU DEBUG_FS
- help
- Select this to see extensive information about
- the internal state of OMAP IOMMU in debugfs.
+ bool Export OMAP IOMMU internals in DebugFS
+ depends on OMAP_IOMMU DEBUG_FS
+ ---help---
+ Select this to see extensive information about
+ the internal state of OMAP IOMMU in debugfs.
- Say N unless you know you need this.
+ Say N unless you know you need this.
config TEGRA_IOMMU_GART
bool Tegra GART IOMMU Support
diff --git a/drivers/iommu/omap-iommu-debug.c
b/drivers/iommu/omap-iommu-debug.c index 28de657..4813d3a 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -10,15 +10,11 @@
* published by the Free Software Foundation.
*/
-#include linux/module.h
#include linux/err.h
-#include linux/clk.h
#include linux/io.h
#include linux/slab.h
#include linux/uaccess.h
-#include linux/platform_device.h
#include linux/debugfs.h
-#include linux/omap-iommu.h
#include linux/platform_data/iommu-omap.h
#include omap-iopgtable.h
@@ -31,8 +27,7 @@ static struct dentry *iommu_debug_root;
static ssize_t debug_read_regs(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ struct omap_iommu *obj = file-private_data;
char *p, *buf;
ssize_t bytes;
@@ -55,8 +50,7 @@ static ssize_t debug_read_regs(struct file *file, char
__user *userbuf, static ssize_t debug_read_tlb(struct file *file, char
__user *userbuf, size_t count, loff_t *ppos)
{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ struct omap_iommu *obj = file-private_data;
char *p, *buf;
ssize_t bytes, rest;
@@ -141,8 +135,7 @@ out:
static ssize_t debug_read_pagetable(struct file *file, char __user
*userbuf, size_t count, loff_t *ppos)
{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ struct omap_iommu *obj = file-private_data;
char *p, *buf;
size_t bytes;
@@ -181,93 +174,56 @@ DEBUG_FOPS_RO(pagetable);
#define __DEBUG_ADD_FILE(attr, mode) \
{ \
struct dentry *dent;\
- dent = debugfs_create_file(#attr, mode, parent, \
-dev, debug_##attr##_fops); \
+ dent = debugfs_create_file(#attr, mode, obj-debug_dir, \
+obj, debug_##attr##_fops); \
if (!dent) \
- return -ENOMEM; \
+ goto err
Re: [PATCH 12/17] iommu/omap: Integrate omap-iommu-debug into omap-iommu
Hi Suman,
Thank you for the patch.
On Tuesday 30 September 2014 16:16:07 Suman Anna wrote:
The debugfs support for OMAP IOMMU is currently implemented
as a module, warranting certain OMAP-specific IOMMU API to
be exported. The OMAP IOMMU, when enabled, can only be built-in
into the kernel, so integrate the OMAP IOMMU debug module
into the OMAP IOMMU driver. This helps in eliminating the
need to export most of the current OMAP IOMMU API.
The following are the main changes:
- The OMAP_IOMMU_DEBUG Kconfig option is eliminated, and
the OMAP IOMMU debugfs support is built alongside the OMAP
IOMMU driver, and enabled automatically only when debugfs
is enabled.
That's the part I'm unsure about. We're loosing the ability to save space by
not building the omap-iommu debugfs support when debugfs is enabled.
For the rest of the series,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
- The debugfs directory and entry creation logic is reversed,
the calls are invoked by the OMAP IOMMU driver now.
- The current iffy circular logic of adding IOMMU archdata
to the IOMMU devices itself to get a pointer to the omap_iommu
object in the debugfs support code is replaced by directly
using the omap_iommu structure while creating the debugfs
entries.
- The debugfs root directory is renamed from the generic name
iommu to a specific name omap_iommu.
- Unneeded headers have also been cleaned up while at this.
- There will no longer be a omap-iommu-debug.ko module after
this patch.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/iommu/Kconfig| 9
drivers/iommu/Makefile | 3 +-
drivers/iommu/omap-iommu-debug.c | 102
--- drivers/iommu/omap-iommu.c |
11 +++--
drivers/iommu/omap-iommu.h | 7 +++
5 files changed, 45 insertions(+), 87 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd51122..9724d4a 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,15 +143,6 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU internals in DebugFS
- depends on OMAP_IOMMU DEBUG_FS
- help
- Select this to see extensive information about
- the internal state of OMAP IOMMU in debugfs.
-
- Say N unless you know you need this.
-
config TEGRA_IOMMU_GART
bool Tegra GART IOMMU Support
depends on ARCH_TEGRA_2x_SOC
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 18fa446..e0a4fed 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -10,8 +10,7 @@ obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += iova.o intel-iommu.o
obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
-obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
-obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
+obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o omap-iommu-debug.o
obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
diff --git a/drivers/iommu/omap-iommu-debug.c
b/drivers/iommu/omap-iommu-debug.c index 28de657..54a0dc6 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -10,15 +10,11 @@
* published by the Free Software Foundation.
*/
-#include linux/module.h
#include linux/err.h
-#include linux/clk.h
#include linux/io.h
#include linux/slab.h
#include linux/uaccess.h
-#include linux/platform_device.h
#include linux/debugfs.h
-#include linux/omap-iommu.h
#include linux/platform_data/iommu-omap.h
#include omap-iopgtable.h
@@ -31,8 +27,7 @@ static struct dentry *iommu_debug_root;
static ssize_t debug_read_regs(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ struct omap_iommu *obj = file-private_data;
char *p, *buf;
ssize_t bytes;
@@ -55,8 +50,7 @@ static ssize_t debug_read_regs(struct file *file, char
__user *userbuf, static ssize_t debug_read_tlb(struct file *file, char
__user *userbuf, size_t count, loff_t *ppos)
{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ struct omap_iommu *obj = file-private_data;
char *p, *buf;
ssize_t bytes, rest;
@@ -141,8 +135,7 @@ out:
static ssize_t debug_read_pagetable(struct file *file, char __user
*userbuf, size_t count, loff_t *ppos)
{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ struct omap_iommu *obj = file-private_data;
char *p, *buf;
size_t bytes;
@@ -181,93 +174,58 @@ DEBUG_FOPS_RO(pagetable
Re: [PATCH 1/2] iommu/omap: Reverse dependency between omap-iommu and omap-iommu2
Hi Suman, On Tuesday 09 September 2014 17:31:44 Suman Anna wrote: On Tuesday 09 September 2014 16:33:11 Suman Anna wrote: On 09/09/2014 10:45 AM, Laurent Pinchart wrote: The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants by splitting the driver into a core module and a thin arch-specific operations module. (In practice only the OMAP2+ module omap-iommu2 is implemented, but let's not denigrate the effort.) Thank you for the patch. I had something similar in my list of cleanup TODO items on the OMAP IOMMU driver, but I was intending to cut down more and consolidate the omap-iommu.c and omap-iommu2.c files into a single one. This had been the case from the introduction of the driver going back to v2.6.30, and OMAP1 was never added and I doubt it would be added anytime in the foreseeable future. The arch-specific operations module registers itself with the OMAP IOMMU core module at initialization time. This initializes a module global arch-specific operations pointer, used at runtime by the IOMMU instances. This scheme causes several issues. In addition to making it impossible to support different OMAP IOMMU types in a single system (which in all fairness is quite unlikely to happen), Yep, except for a few enhancements (like reporting Fault PC address on OMAP4 DSPs, and dropping both endianness support), the core IOMMU functionality hasn't changed much between OMAP2 and the latest OMAP4+ SoCs. So, my plan was to completely get rid of the iommu_functions (it also eliminates the need for exporting most of the OMAP IOMMU API). So while I am ok with the current patch, I prefer consolidation than keeping the scalability alive, it can always be added if a need for that arises. What do you think? I agree with your approach, but in the meantime we have a problem to solve. How about applying this patch now (it goes in the right direction anyway), and then removing the iommu functions when you will have time ? Can you give the subsys_initcall solution a try to see if that resolves the problem at hand? That would be a much smaller change, if that doesn't work we can go with this patch. It seems to work. I will work on my cleanup list for 3.19. Does that schedule still hold ? If so I'll submit a simple subsys_initcall() patch for v3.18. it also causes initialization ordering issues by requiring the arch-specific operations module to be loaded before any IOMMU user. This results in a probe breakage with the OMAP3 ISP driver when not compiled as a module. This can be fixed if we make the current omap-iommu2.c as a subsys_initcall as well, right? regards Suman Fix the problem by inverting the dependency. Instead of having the omap-iommu2 module register itself to iommu-omap, make the iommu-omap retrieve the omap-iommu2 operations structure directly when probing the IOMMU device. This ensures that a probed IOMMU will always have valid arch-specific operations. As the arch-specific operations pointer is now initialized at probe time, this change requires turning it from a global variable into a per-device variable. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/iommu/omap-iommu-debug.c | 6 ++- drivers/iommu/omap-iommu.c | 94 + drivers/iommu/omap-iommu.h | 10 - drivers/iommu/omap-iommu2.c | 18 +--- 4 files changed, 45 insertions(+), 83 deletions(-) -- Regards, Laurent Pinchart -- 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] iommu/omap: Reverse dependency between omap-iommu and omap-iommu2
The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants
by splitting the driver into a core module and a thin arch-specific
operations module.
(In practice only the OMAP2+ module omap-iommu2 is implemented, but
let's not denigrate the effort.)
The arch-specific operations module registers itself with the OMAP IOMMU
core module at initialization time. This initializes a module global
arch-specific operations pointer, used at runtime by the IOMMU
instances.
This scheme causes several issues. In addition to making it impossible
to support different OMAP IOMMU types in a single system (which in all
fairness is quite unlikely to happen), it also causes initialization
ordering issues by requiring the arch-specific operations module to be
loaded before any IOMMU user. This results in a probe breakage with the
OMAP3 ISP driver when not compiled as a module.
Fix the problem by inverting the dependency. Instead of having the
omap-iommu2 module register itself to iommu-omap, make the iommu-omap
retrieve the omap-iommu2 operations structure directly when probing the
IOMMU device. This ensures that a probed IOMMU will always have valid
arch-specific operations.
As the arch-specific operations pointer is now initialized at probe
time, this change requires turning it from a global variable into a
per-device variable.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu-debug.c | 6 ++-
drivers/iommu/omap-iommu.c | 94 ++--
drivers/iommu/omap-iommu.h | 10 -
drivers/iommu/omap-iommu2.c | 18 +---
4 files changed, 45 insertions(+), 83 deletions(-)
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index 531658d..35a2c3a 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -33,7 +33,9 @@ static struct dentry *iommu_debug_root;
static ssize_t debug_read_ver(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- u32 ver = omap_iommu_arch_version();
+ struct device *dev = file-private_data;
+ struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ u32 ver = omap_iommu_arch_version(obj);
char buf[MAXCOLUMN], *p = buf;
p += sprintf(p, H/W version: %d.%d\n, (ver 4) 0xf , ver 0xf);
@@ -117,7 +119,7 @@ static ssize_t debug_write_pagetable(struct file *file,
return -EINVAL;
}
- omap_iotlb_cr_to_e(cr, e);
+ omap_iotlb_cr_to_e(obj, cr, e);
err = omap_iopgtable_store_entry(obj, e);
if (err)
dev_err(obj-dev, %s: fail to store cr\n, __func__);
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index df579f8..192c367 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -76,45 +76,10 @@ struct iotlb_lock {
short vict;
};
-/* accommodate the difference between omap1 and omap2/3 */
-static const struct iommu_functions *arch_iommu;
-
static struct platform_driver omap_iommu_driver;
static struct kmem_cache *iopte_cachep;
/**
- * omap_install_iommu_arch - Install archtecure specific iommu functions
- * @ops: a pointer to architecture specific iommu functions
- *
- * There are several kind of iommu algorithm(tlb, pagetable) among
- * omap series. This interface installs such an iommu algorighm.
- **/
-int omap_install_iommu_arch(const struct iommu_functions *ops)
-{
- if (arch_iommu)
- return -EBUSY;
-
- arch_iommu = ops;
- return 0;
-}
-EXPORT_SYMBOL_GPL(omap_install_iommu_arch);
-
-/**
- * omap_uninstall_iommu_arch - Uninstall archtecure specific iommu functions
- * @ops: a pointer to architecture specific iommu functions
- *
- * This interface uninstalls the iommu algorighm installed previously.
- **/
-void omap_uninstall_iommu_arch(const struct iommu_functions *ops)
-{
- if (arch_iommu != ops)
- pr_err(%s: not your arch\n, __func__);
-
- arch_iommu = NULL;
-}
-EXPORT_SYMBOL_GPL(omap_uninstall_iommu_arch);
-
-/**
* omap_iommu_save_ctx - Save registers for pm off-mode support
* @dev: client device
**/
@@ -122,7 +87,7 @@ void omap_iommu_save_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-save_ctx(obj);
+ obj-arch_iommu-save_ctx(obj);
}
EXPORT_SYMBOL_GPL(omap_iommu_save_ctx);
@@ -134,16 +99,16 @@ void omap_iommu_restore_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-restore_ctx(obj);
+ obj-arch_iommu-restore_ctx(obj);
}
EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx);
/**
* omap_iommu_arch_version - Return running iommu arch version
**/
-u32 omap_iommu_arch_version(void)
+u32 omap_iommu_arch_version(struct omap_iommu *obj)
{
- return arch_iommu-version;
+ return obj-arch_iommu-version;
}
EXPORT_SYMBOL_GPL
[PATCH 0/2] OMAP IOMMU cleanups
Hello, Those two patches clean up the OMAP IOMMU driver. Please see individual commit messages for more information. Laurent Pinchart (2): iommu/omap: Reverse dependency between omap-iommu and omap-iommu2 iommu/omap: Remove omap_iommu unused owner field drivers/iommu/omap-iommu-debug.c | 6 ++- drivers/iommu/omap-iommu.c | 103 --- drivers/iommu/omap-iommu.h | 11 +++-- drivers/iommu/omap-iommu2.c | 18 +-- 4 files changed, 44 insertions(+), 94 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] iommu/omap: Remove omap_iommu unused owner field
The owner field is never set. Remove it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 11 ---
drivers/iommu/omap-iommu.h | 1 -
2 files changed, 12 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 192c367..fdfe732 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -861,20 +861,11 @@ static struct omap_iommu *omap_iommu_attach(const char
*name, u32 *iopgd)
goto err_enable;
flush_iotlb_all(obj);
- if (!try_module_get(obj-owner)) {
- dev_err(obj-dev, %s: can't get owner\n, __func__);
- err = -ENODEV;
- goto err_module;
- }
-
spin_unlock(obj-iommu_lock);
dev_dbg(obj-dev, %s: %s\n, __func__, obj-name);
return obj;
-err_module:
- if (obj-refcount == 1)
- iommu_disable(obj);
err_enable:
obj-refcount--;
spin_unlock(obj-iommu_lock);
@@ -895,8 +886,6 @@ static void omap_iommu_detach(struct omap_iommu *obj)
if (--obj-refcount == 0)
iommu_disable(obj);
- module_put(obj-owner);
-
obj-iopgd = NULL;
spin_unlock(obj-iommu_lock);
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index 7a90800..2c3b85c 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -28,7 +28,6 @@ struct iotlb_entry {
struct omap_iommu {
const char *name;
- struct module *owner;
void __iomem*regbase;
struct device *dev;
void*isr_priv;
--
1.8.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] iommu/omap: Reverse dependency between omap-iommu and omap-iommu2
Hi Suman, On Tuesday 09 September 2014 16:33:11 Suman Anna wrote: On 09/09/2014 10:45 AM, Laurent Pinchart wrote: The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants by splitting the driver into a core module and a thin arch-specific operations module. (In practice only the OMAP2+ module omap-iommu2 is implemented, but let's not denigrate the effort.) Thank you for the patch. I had something similar in my list of cleanup TODO items on the OMAP IOMMU driver, but I was intending to cut down more and consolidate the omap-iommu.c and omap-iommu2.c files into a single one. This had been the case from the introduction of the driver going back to v2.6.30, and OMAP1 was never added and I doubt it would be added anytime in the foreseeable future. The arch-specific operations module registers itself with the OMAP IOMMU core module at initialization time. This initializes a module global arch-specific operations pointer, used at runtime by the IOMMU instances. This scheme causes several issues. In addition to making it impossible to support different OMAP IOMMU types in a single system (which in all fairness is quite unlikely to happen), Yep, except for a few enhancements (like reporting Fault PC address on OMAP4 DSPs, and dropping both endianness support), the core IOMMU functionality hasn't changed much between OMAP2 and the latest OMAP4+ SoCs. So, my plan was to completely get rid of the iommu_functions (it also eliminates the need for exporting most of the OMAP IOMMU API). So while I am ok with the current patch, I prefer consolidation than keeping the scalability alive, it can always be added if a need for that arises. What do you think? I agree with your approach, but in the meantime we have a problem to solve. How about applying this patch now (it goes in the right direction anyway), and then removing the iommu functions when you will have time ? it also causes initialization ordering issues by requiring the arch-specific operations module to be loaded before any IOMMU user. This results in a probe breakage with the OMAP3 ISP driver when not compiled as a module. This can be fixed if we make the current omap-iommu2.c as a subsys_initcall as well, right? regards Suman Fix the problem by inverting the dependency. Instead of having the omap-iommu2 module register itself to iommu-omap, make the iommu-omap retrieve the omap-iommu2 operations structure directly when probing the IOMMU device. This ensures that a probed IOMMU will always have valid arch-specific operations. As the arch-specific operations pointer is now initialized at probe time, this change requires turning it from a global variable into a per-device variable. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/iommu/omap-iommu-debug.c | 6 ++- drivers/iommu/omap-iommu.c | 94 +-- drivers/iommu/omap-iommu.h | 10 - drivers/iommu/omap-iommu2.c | 18 +--- 4 files changed, 45 insertions(+), 83 deletions(-) -- Regards, Laurent Pinchart -- 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] iommu/omap: Fix iommu archdata name for DT-based devices
Hi Suman,
On Thursday 04 September 2014 16:17:53 Suman Anna wrote:
Hi Laurent,
On Wednesday 03 September 2014 18:58:32 Suman Anna wrote:
A device is tied to an iommu through its archdata field. The archdata
is allocated on the fly for DT-based devices automatically through the
.add_device iommu ops. The current logic incorrectly assigned the name
of the IOMMU user device, instead of the name of the IOMMU device as
required by the attach logic. Fix this issue so that DT-based devices
can attach successfully to an IOMMU domain.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f245d51..f47ac03 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -26,6 +26,7 @@
#include linux/of.h
#include linux/of_iommu.h
#include linux/of_irq.h
+#include linux/of_platform.h
#include asm/cacheflush.h
@@ -1244,6 +1245,7 @@ static int omap_iommu_add_device(struct device
*dev)
{
struct omap_iommu_arch_data *arch_data;
struct device_node *np;
+ struct platform_device *pdev;
/*
* Allocate the archdata iommu structure for DT-based devices.
@@ -1258,13 +1260,19 @@ static int omap_iommu_add_device(struct device
*dev)
if (!np)
return 0;
+ pdev = of_find_device_by_node(np);
+ if (WARN_ON(!pdev)) {
+ of_node_put(np);
+ return -EINVAL;
+ }
I might be wrong, but I don't think there's a guarantee at this point that
the IOMMU device is already instantiated :-/
The omap_iommu_init which registers the iommu_ops is a subsys_initcall,
so the platform devices are guaranteed to be created by this point.
OK, no worries then.
My test on OMAP4 in fact has the dsp node created before the IOMMU node,
and this is not an issue. I have added the WARN_ON in case some one has
the IOMMU node disabled, but try to use it.
Will Deacon has posted patches that rework the IOMMU core for better DT
integration, have you seen them ?
Can you point out the thread? Are you talking about
http://marc.info/?l=linux-arm-kernelm=140968072117851w=2?
Yes that's the one.
--
Regards,
Laurent Pinchart
--
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: [PATCHv2 1/2] iommu/omap: Check for valid archdata in attach_dev
Hi Suman,
Thank you for the patch.
On Thursday 04 September 2014 17:27:29 Suman Anna wrote:
Any device requiring to be attached to an iommu_domain must have
valid archdata containing the necessary iommu information, which
is SoC-specific. Add a check in the omap_iommu_attach_dev to make
sure that the device has valid archdata before accessing
different SoC-specific fields of the archdata. This prevents a
NULL pointer dereference on any misconfigured devices.
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 02ef0ac..ea6e59d 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1090,6 +1090,11 @@ omap_iommu_attach_dev(struct iommu_domain *domain,
struct device *dev) struct omap_iommu_arch_data *arch_data =
dev-archdata.iommu;
int ret = 0;
+ if (!arch_data || !arch_data-name) {
+ dev_err(dev, device doesn't have an associated iommu\n);
+ return -EINVAL;
+ }
+
spin_lock(omap_domain-lock);
/* only a single device is supported per domain for now */
--
Regards,
Laurent Pinchart
--
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: [PATCHv2 2/2] iommu/omap: Fix iommu archdata name for DT-based devices
Hi Suman,
Thank you for the patch.
On Thursday 04 September 2014 17:27:30 Suman Anna wrote:
A device is tied to an iommu through its archdata field. The archdata
is allocated on the fly for DT-based devices automatically through the
.add_device iommu ops. The current logic incorrectly assigned the name
of the IOMMU user device, instead of the name of the IOMMU device as
required by the attach logic. Fix this issue so that DT-based devices
can attach successfully to an IOMMU domain.
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index ea6e59d..8cf8bf1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -26,6 +26,7 @@
#include linux/of.h
#include linux/of_iommu.h
#include linux/of_irq.h
+#include linux/of_platform.h
#include asm/cacheflush.h
@@ -1243,6 +1244,7 @@ static int omap_iommu_add_device(struct device *dev)
{
struct omap_iommu_arch_data *arch_data;
struct device_node *np;
+ struct platform_device *pdev;
/*
* Allocate the archdata iommu structure for DT-based devices.
@@ -1257,13 +1259,19 @@ static int omap_iommu_add_device(struct device *dev)
if (!np)
return 0;
+ pdev = of_find_device_by_node(np);
+ if (WARN_ON(!pdev)) {
+ of_node_put(np);
+ return -EINVAL;
+ }
+
arch_data = kzalloc(sizeof(*arch_data), GFP_KERNEL);
if (!arch_data) {
of_node_put(np);
return -ENOMEM;
}
- arch_data-name = kstrdup(dev_name(dev), GFP_KERNEL);
+ arch_data-name = kstrdup(dev_name(pdev-dev), GFP_KERNEL);
dev-archdata.iommu = arch_data;
of_node_put(np);
--
Regards,
Laurent Pinchart
--
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] iommu/omap: Check for valid archdata in attach_dev
Hi Suman,
Thank you for the patch.
On Wednesday 03 September 2014 18:58:31 Suman Anna wrote:
Any device requiring to be attached to an iommu_domain must have
valid archdata containing the necessary iommu information, which
is SoC-specific. Add a check in the omap_iommu_attach_dev to make
sure that the device has non-NULL archdata before accessing
different SoC-specific fields of the archdata. This prevents a
NULL pointer dereference on any misconfigured devices.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 02ef0ac..f245d51 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1092,6 +1092,12 @@ omap_iommu_attach_dev(struct iommu_domain *domain,
struct device *dev)
spin_lock(omap_domain-lock);
+ if (!arch_data) {
+ dev_err(dev, device doesn't have an associated iommu\n);
+ ret = -EINVAL;
+ goto out;
+ }
You can move this check outside of the spinlock-protected section. With that
change,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
+
/* only a single device is supported per domain for now */
if (omap_domain-iommu_dev) {
dev_err(dev, iommu domain is already attached\n);
--
Regards,
Laurent Pinchart
--
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] iommu/omap: Fix iommu archdata name for DT-based devices
Hi Suman,
Thank you for the patch.
On Wednesday 03 September 2014 18:58:32 Suman Anna wrote:
A device is tied to an iommu through its archdata field. The archdata
is allocated on the fly for DT-based devices automatically through the
.add_device iommu ops. The current logic incorrectly assigned the name
of the IOMMU user device, instead of the name of the IOMMU device as
required by the attach logic. Fix this issue so that DT-based devices
can attach successfully to an IOMMU domain.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f245d51..f47ac03 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -26,6 +26,7 @@
#include linux/of.h
#include linux/of_iommu.h
#include linux/of_irq.h
+#include linux/of_platform.h
#include asm/cacheflush.h
@@ -1244,6 +1245,7 @@ static int omap_iommu_add_device(struct device *dev)
{
struct omap_iommu_arch_data *arch_data;
struct device_node *np;
+ struct platform_device *pdev;
/*
* Allocate the archdata iommu structure for DT-based devices.
@@ -1258,13 +1260,19 @@ static int omap_iommu_add_device(struct device *dev)
if (!np)
return 0;
+ pdev = of_find_device_by_node(np);
+ if (WARN_ON(!pdev)) {
+ of_node_put(np);
+ return -EINVAL;
+ }
I might be wrong, but I don't think there's a guarantee at this point that the
IOMMU device is already instantiated :-/
Will Deacon has posted patches that rework the IOMMU core for better DT
integration, have you seen them ?
+
arch_data = kzalloc(sizeof(*arch_data), GFP_KERNEL);
if (!arch_data) {
of_node_put(np);
return -ENOMEM;
}
- arch_data-name = kstrdup(dev_name(dev), GFP_KERNEL);
+ arch_data-name = kstrdup(dev_name(pdev-dev), GFP_KERNEL);
dev-archdata.iommu = arch_data;
of_node_put(np);
--
Regards,
Laurent Pinchart
--
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] video: fix composite video connector compatible string
Hi Tomi,
Thank you for the patch.
On Tuesday 02 September 2014 10:35:46 Tomi Valkeinen wrote:
The quite-recently-added analog-tv-connector bindings say that the
compatible string for composite video connector is
composite-connector. That string is also used in the omap3-n900.dts
file. However, the connector driver uses composite-video-connector, so
this has never worked.
While changing the driver's compatible string to composite-connector
would be safer, as published DT bindings should not be changed, I'd
rather fix the bindings in this case for two reasons:
* composite-connector is a bit too generic name, as it doesn't even hint
at video.
* it's clear that this has never worked, which means no one has used
those bindings, which should make it safe to change this.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reported-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/devicetree/bindings/video/analog-tv-connector.txt | 4 ++--
arch/arm/boot/dts/omap3-n900.dts| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt
b/Documentation/devicetree/bindings/video/analog-tv-connector.txt index
0218fcdc1299..0c0970c210ab 100644
--- a/Documentation/devicetree/bindings/video/analog-tv-connector.txt
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -2,7 +2,7 @@ Analog TV Connector
===
Required properties:
-- compatible: composite-connector or svideo-connector
+- compatible: composite-video-connector or svideo-connector
Optional properties:
- label: a symbolic name for the connector
@@ -14,7 +14,7 @@ Example
---
tv: connector {
- compatible = composite-connector;
+ compatible = composite-video-connector;
label = tv;
port {
diff --git a/arch/arm/boot/dts/omap3-n900.dts
b/arch/arm/boot/dts/omap3-n900.dts index 1fe45d1f75ec..4361777a08d8 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -93,7 +93,7 @@
};
tv: connector {
- compatible = composite-connector;
+ compatible = composite-video-connector;
label = tv;
port {
--
Regards,
Laurent Pinchart
--
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: [PATCHv2 27/27] OMAPDSS: connector-analog-tv: Add DT support
Hi Tomi,
On Monday 16 December 2013 16:56:34 Tomi Valkeinen wrote:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../video/omap2/displays-new/connector-analog-tv.c | 66 ++-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c
b/drivers/video/omap2/displays-new/connector-analog-tv.c index
ccd9073f706f..ebed25a86487 100644
--- a/drivers/video/omap2/displays-new/connector-analog-tv.c
+++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/module.h
#include linux/platform_device.h
+#include linux/of.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -42,6 +43,12 @@ static const struct omap_video_timings tvc_pal_timings =
{ .interlace = true,
};
+static const struct of_device_id tvc_of_match[];
+
+struct tvc_of_data {
+ enum omap_dss_venc_type connector_type;
+};
+
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
static int tvc_connect(struct omap_dss_device *dssdev)
@@ -92,7 +99,10 @@ static int tvc_enable(struct omap_dss_device *dssdev)
in-ops.atv-set_timings(in, ddata-timings);
in-ops.atv-set_type(in, ddata-connector_type);
- in-ops.atv-invert_vid_out_polarity(in, ddata-invert_polarity);
+
+ if (!ddata-dev-of_node)
+ in-ops.atv-invert_vid_out_polarity(in,
+ ddata-invert_polarity);
r = in-ops.atv-enable(in);
if (r)
@@ -205,6 +215,35 @@ static int tvc_probe_pdata(struct platform_device
*pdev) return 0;
}
+static int tvc_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ const struct of_device_id *match;
+ const struct tvc_of_data *data;
+
+ match = of_match_node(tvc_of_match, pdev-dev.of_node);
+ if (!match) {
+ dev_err(pdev-dev, unsupported device\n);
+ return -ENODEV;
+ }
+
+ data = match-data;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ ddata-connector_type = data-connector_type;
+
+ return 0;
+}
+
static int tvc_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -222,6 +261,10 @@ static int tvc_probe(struct platform_device *pdev)
r = tvc_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = tvc_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -263,12 +306,33 @@ static int __exit tvc_remove(struct platform_device
*pdev) return 0;
}
+static const struct tvc_of_data tv_svideo_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static const struct tvc_of_data tv_composite_video_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+};
+
+static const struct of_device_id tvc_of_match[] = {
+ {
+ .compatible = svideo-connector,
+ .data = tv_svideo_data,
+ },
+ {
+ .compatible = composite-video-connector,
I've just noticed that this doesn't match the bindings that document the
compatible value to be composite-connector.
+ .data = tv_composite_video_data,
+ },
+ {},
+};
+
static struct platform_driver tvc_connector_driver = {
.probe = tvc_probe,
.remove = __exit_p(tvc_remove),
.driver = {
.name = connector-analog-tv,
.owner = THIS_MODULE,
+ .of_match_table = tvc_of_match,
},
};
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain
Hi Geert, On Monday 04 August 2014 13:28:32 Geert Uytterhoeven wrote: On Wed, Jul 30, 2014 at 2:06 AM, Laurent Pinchart wrote: The third option would require storing the clocks lists in device drivers. I believe this is our best option, as a trade-off between simplicity and versatility. Drivers that use runtime PM already need to enable it explicitly when probing devices. Passing a list of clock names to runtime PM at that point wouldn't complicate drivers much. When the clocks list isn't SoC- dependent it could be stored as static information. Otherwise it could be derived from DT (or any other source of hardware description) using C code, offering all the versatility we need. The only drawback of this solution I can think of right now is that the runtime PM core couldn't manage device clocks before probing the device. Specifically device clocks couldn't be managed if no driver is loaded for that device. I somehow recall that someone raised this as being a problem, but I can't remember why. Perhaps you're thinking of clocks that were enabled (by the boot loader or implicit reset state) before running Linux, and aren't disabled? That wasn't the reason, I know that clk_disable_unused() takes care of that problem (provided the clock drivers behave correctly, the commit you mention below shows that's not always the case, but that's an unrelated issue). That was fixed by commit bb178da701382a230e26d90cf94e8a24b280e0d9 (clk: shmobile: mstp: Fix the is_enabled() operation). -- Regards, Laurent Pinchart -- 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: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock
On Wednesday 30 July 2014 15:40:33 Tero Kristo wrote:
On 07/16/2014 03:29 AM, Laurent Pinchart wrote:
On Tuesday 15 July 2014 12:02:35 Stefan Herbrechtsmeier wrote:
Set 'ti,set-rate-parent' property for the dpll4_m5x2_ck clock, which
is used for the ISP functional clock. This fixes the OMAP3 ISP driver's
clock rate configuration on OMAP34xx, which needs the rate to be
propagated properly to the divider node (dpll4_m5_ck).
Signed-off-by: Stefan Herbrechtsmeier ste...@herbrechtsmeier.net
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Tony Lindgren t...@atomide.com
Cc: Tero Kristo t-kri...@ti.com
Cc: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tero, could you please process it for v3.17 if time still permits ?
This is too late for 3.17 merge window as I was on holiday last few
weeks. Queued for 3.17-rc early fixes though.
Kiitos.
---
arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi index e47ff69..5c37500 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -467,6 +467,7 @@
ti,bit-shift = 0x1e;
reg = 0x0d00;
ti,set-bit-to-disable;
+ ti,set-rate-parent;
};
dpll4_m6_ck: dpll4_m6_ck {
--
Regards,
Laurent Pinchart
--
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 0/2] usb: fix controller-PHY binding for OMAP3 platform
On Wednesday 23 July 2014 14:29:36 Kishon Vijay Abraham I wrote: On Monday 21 July 2014 08:45 PM, Felipe Balbi wrote: On Mon, Jul 21, 2014 at 05:04:57PM +0200, Laurent Pinchart wrote: Hi Felipe, What happened to these two patches ? looks like I lost them. On Monday 16 December 2013 17:48:29 Felipe Balbi wrote: On Mon, Dec 16, 2013 at 02:38:27PM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [131216 13:31]: On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote: After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. Did enumeration testing in omap3 beagle. Changes from v2: * Fixed the commit log Changes from v1: * refreshed to the latested mainline kernel * added musb_put_id from omap2430 remove. Tony, how do you want to handle this ? You want me to provide you a branch which we both merge ? Yes that would be great thanks. For the mach-omap2 touching parts: Acked-by: Tony Lindgren t...@atomide.com Here it is, let me know if you prefer a signed tag: The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git usb-phy-binding-omap3 for you to fetch changes up to 23ada3130cf4e56acb86fdff4c26113188d52d18: arm: omap: remove *.auto* from device names given in usb_bind_phy (2013-12-16 17:44:43 -0600) Kishon Vijay Abraham I (2): usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c arm: omap: remove *.auto* from device names given in usb_bind_phy Kishon, are these still valid ? Looks like board-2430sdp.c got removed. Apart from that the reset of the patch series is still applicable for non-dt boot. Felipe, do you plan to apply the patch without the baord-2430sdp.c change, or would you like Kishon to rebase and resubmit it ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain
being already present in DT in the clocks property. The second option calls for storing the lists in SoC code under arch/. As we're trying to minimize the amount of SoC code there (and even remove SoC code completely when possible) I don't think that's a good option. The third option would require storing the clocks lists in device drivers. I believe this is our best option, as a trade-off between simplicity and versatility. Drivers that use runtime PM already need to enable it explicitly when probing devices. Passing a list of clock names to runtime PM at that point wouldn't complicate drivers much. When the clocks list isn't SoC- dependent it could be stored as static information. Otherwise it could be derived from DT (or any other source of hardware description) using C code, offering all the versatility we need. The only drawback of this solution I can think of right now is that the runtime PM core couldn't manage device clocks before probing the device. Specifically device clocks couldn't be managed if no driver is loaded for that device. I somehow recall that someone raised this as being a problem, but I can't remember why. Also, May be platform dependent solution [1] can be acceptable for now? [1] https://lkml.org/lkml/2014/7/25/630 I need to look at the series before I comment. I've flagged it and will hopefully look at it tomorrow. -- Regards, Laurent Pinchart -- 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/3] iommu: Remove OMAP IOVMM driver
Hi Joerg, On Wednesday 23 July 2014 15:52:17 Joerg Roedel wrote: On Mon, Jul 21, 2014 at 11:19:29PM -0700, Tony Lindgren wrote: Tony, is there still time to get this (and especially patch 2/3, which touches arch/ code) in v3.17 ? Yes as long as Joerg is OK to merge that branch in :) Fine with me, I can take only patch 1 or all 3 into my arm/omap branch, given Tony's Acked-by. Then you guys can merge in this branch wherever you want :) Thank you. Assuming there's currently no conflict to be resolved, I believe the easiest would be for both you and Tony to merge my branch in your trees. -- Regards, Laurent Pinchart -- 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/3] iommu: Remove OMAP IOVMM driver
Hi Joerg, (Your attention is kindly requested in time for v3.17, please see below) On Monday 21 July 2014 23:19:29 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140721 11:17]: On Monday 21 July 2014 02:33:36 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140721 02:16]: On Friday 18 July 2014 11:53:56 Suman Anna wrote: On 07/18/2014 05:49 AM, Laurent Pinchart wrote: Hello, The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that is has been ported to the DMA API, remove the unused virtual memory manager. The removal is split in three patches to ease upstream merge. The first patch removes the omap-iovmm driver, the second patch removes setting of now unused platform data fields from arch code, and the last patch cleans up the platform data structure. Thanks for the revised series, it looks good. I have also tested the series on OMAP3, OMAP4 and OMAP5. For the changes in the entire series, Acked-by: Suman Anna s-a...@ti.com Thank you. I'd like to get at least the first patch merged in v3.17. To avoid splitting the series across three kernel versions, it would be nice to also merge at least the second patch for v3.17. If there's no risk of conflict everything could be merged in one go through the ARM SoC tree. Otherwise a stable branch with patch 1/3 will be needed to base the arch change on. Joerg, Tony, how would you like to proceed ? The v3.17 merge window is getting close, it's probably too late to merge patch 2/3. Joerg, could you please take 1/3 in your tree for v3.17 ? 2/3 and 3/3 would then get in v3.18. Tony, how would you like to proceed for those ? How about Joerg maybe do an immutable branch against v3.16-rc1 with just these three patches and merge it into your tree? That way I too can merge the minimal branch in if there are conflics. If that works for Joerg, then for arch/arm/*omap* changes: Acked-by: Tony Lindgren t...@atomide.com I've created an immutable branch (or, rather, immutable until the changes reach mainline, at which point I will remove the branch) on top of v3.16-rc1 with just the three patches from this series. You can find it at. git://linuxtv.org/pinchartl/media.git omap/iommu Tony, is there still time to get this (and especially patch 2/3, which touches arch/ code) in v3.17 ? Yes as long as Joerg is OK to merge that branch in :) Are you ? :-) -- Regards, Laurent Pinchart -- 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 0/2] usb: fix controller-PHY binding for OMAP3 platform
Hi Felipe, What happened to these two patches ? On Monday 16 December 2013 17:48:29 Felipe Balbi wrote: On Mon, Dec 16, 2013 at 02:38:27PM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [131216 13:31]: On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote: After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. Did enumeration testing in omap3 beagle. Changes from v2: * Fixed the commit log Changes from v1: * refreshed to the latested mainline kernel * added musb_put_id from omap2430 remove. Tony, how do you want to handle this ? You want me to provide you a branch which we both merge ? Yes that would be great thanks. For the mach-omap2 touching parts: Acked-by: Tony Lindgren t...@atomide.com Here it is, let me know if you prefer a signed tag: The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git usb-phy-binding-omap3 for you to fetch changes up to 23ada3130cf4e56acb86fdff4c26113188d52d18: arm: omap: remove *.auto* from device names given in usb_bind_phy (2013-12-16 17:44:43 -0600) Kishon Vijay Abraham I (2): usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c arm: omap: remove *.auto* from device names given in usb_bind_phy arch/arm/mach-omap2/board-2430sdp.c| 2 +- arch/arm/mach-omap2/board-3430sdp.c| 2 +- arch/arm/mach-omap2/board-cm-t35.c | 2 +- arch/arm/mach-omap2/board-devkit8000.c | 2 +- arch/arm/mach-omap2/board-ldp.c| 2 +- arch/arm/mach-omap2/board-omap3beagle.c| 2 +- arch/arm/mach-omap2/board-omap3logic.c | 2 +- arch/arm/mach-omap2/board-omap3pandora.c | 2 +- arch/arm/mach-omap2/board-omap3stalker.c | 2 +- arch/arm/mach-omap2/board-omap3touchbook.c | 2 +- arch/arm/mach-omap2/board-overo.c | 2 +- arch/arm/mach-omap2/board-rx51.c | 2 +- drivers/usb/musb/musb_core.c | 31 ++- drivers/usb/musb/musb_core.h | 2 ++ drivers/usb/musb/omap2430.c| 19 -- 15 files changed, 61 insertions(+), 15 deletions(-) -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
Hi Tony and Joerg, On Monday 21 July 2014 02:33:36 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140721 02:16]: Hi Suman, Joerg and Tony, On Friday 18 July 2014 11:53:56 Suman Anna wrote: On 07/18/2014 05:49 AM, Laurent Pinchart wrote: Hello, The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that is has been ported to the DMA API, remove the unused virtual memory manager. The removal is split in three patches to ease upstream merge. The first patch removes the omap-iovmm driver, the second patch removes setting of now unused platform data fields from arch code, and the last patch cleans up the platform data structure. Thanks for the revised series, it looks good. I have also tested the series on OMAP3, OMAP4 and OMAP5. For the changes in the entire series, Acked-by: Suman Anna s-a...@ti.com Thank you. I'd like to get at least the first patch merged in v3.17. To avoid splitting the series across three kernel versions, it would be nice to also merge at least the second patch for v3.17. If there's no risk of conflict everything could be merged in one go through the ARM SoC tree. Otherwise a stable branch with patch 1/3 will be needed to base the arch change on. Joerg, Tony, how would you like to proceed ? The v3.17 merge window is getting close, it's probably too late to merge patch 2/3. Joerg, could you please take 1/3 in your tree for v3.17 ? 2/3 and 3/3 would then get in v3.18. Tony, how would you like to proceed for those ? How about Joerg maybe do an immutable branch against v3.16-rc1 with just these three patches and merge it into your tree? That way I too can merge the minimal branch in if there are conflics. If that works for Joerg, then for arch/arm/*omap* changes: Acked-by: Tony Lindgren t...@atomide.com I've created an immutable branch (or, rather, immutable until the changes reach mainline, at which point I will remove the branch) on top of v3.16-rc1 with just the three patches from this series. You can find it at. git://linuxtv.org/pinchartl/media.git omap/iommu Tony, is there still time to get this (and especially patch 2/3, which touches arch/ code) in v3.17 ? If the above is too complicated, then how about Laurent resend patches 2 - 3 once the dependencies have cleared so I can pick them up. This is assuming nothing breaks with patchs 2 - 3 missing naturally :) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
Hello, The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that is has been ported to the DMA API, remove the unused virtual memory manager. The removal is split in three patches to ease upstream merge. The first patch removes the omap-iovmm driver, the second patch removes setting of now unused platform data fields from arch code, and the last patch cleans up the platform data structure. I'd like to get at least the first patch merged in v3.17. To avoid splitting the series across three kernel versions, it would be nice to also merge at least the second patch for v3.17. If there's no risk of conflict everything could be merged in one go through the ARM SoC tree. Otherwise a stable branch with patch 1/3 will be needed to base the arch change on. Joerg, Tony, how would you like to proceed ? Changes compared to v1: - Fix OMAP_IOMMU_DEBUG dependency on OMAP_IOMMU - Remove omap_iommu da_start and da_end fields - Added patches 2/3 and 3/3 Laurent Pinchart (3): iommu/omap: Remove virtual memory manager ARM: omap: Don't set iommu pdata da_start and da_end fields iommu/omap: Remove platform data da_start and da_end fields arch/arm/mach-omap2/omap-iommu.c | 2 - arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 - arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 - drivers/iommu/Kconfig | 10 +- drivers/iommu/Makefile | 1 - drivers/iommu/omap-iommu-debug.c | 114 - drivers/iommu/omap-iommu.c | 13 - drivers/iommu/omap-iommu.h | 8 +- drivers/iommu/omap-iovmm.c | 791 - include/linux/omap-iommu.h | 37 +- include/linux/platform_data/iommu-omap.h | 6 - 11 files changed, 8 insertions(+), 982 deletions(-) delete mode 100644 drivers/iommu/omap-iovmm.c -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] ARM: omap: Don't set iommu pdata da_start and da_end fields
The fields are not used by the driver and will be removed from platform
data. Don't set them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/omap-iommu.c | 2 --
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4
3 files changed, 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f1fab56..4068350 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -34,8 +34,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
pdata-name = oh-name;
pdata-nr_tlb_entries = a-nr_tlb_entries;
- pdata-da_start = a-da_start;
- pdata-da_end = a-da_end;
if (oh-rst_lines_cnt == 1) {
pdata-reset_name = oh-rst_lines-name;
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 1cd0cfd..e9516b4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -2986,8 +2986,6 @@ static struct omap_hwmod_class omap3xxx_mmu_hwmod_class =
{
/* mmu isp */
static struct omap_mmu_dev_attr mmu_isp_dev_attr = {
- .da_start = 0x0,
- .da_end = 0xf000,
.nr_tlb_entries = 8,
};
@@ -3026,8 +3024,6 @@ static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
/* mmu iva */
static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
- .da_start = 0x1100,
- .da_end = 0xf000,
.nr_tlb_entries = 32,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 41e54f7..b4acc0a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2084,8 +2084,6 @@ static struct omap_hwmod_class omap44xx_mmu_hwmod_class =
{
/* mmu ipu */
static struct omap_mmu_dev_attr mmu_ipu_dev_attr = {
- .da_start = 0x0,
- .da_end = 0xf000,
.nr_tlb_entries = 32,
};
@@ -2133,8 +2131,6 @@ static struct omap_hwmod omap44xx_mmu_ipu_hwmod = {
/* mmu dsp */
static struct omap_mmu_dev_attr mmu_dsp_dev_attr = {
- .da_start = 0x0,
- .da_end = 0xf000,
.nr_tlb_entries = 32,
};
--
1.8.5.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 v2 3/3] iommu/omap: Remove platform data da_start and da_end fields
The fields were used by the now gone omap-iovmm driver. They're not used
anymore, remove them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/platform_data/iommu-omap.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/platform_data/iommu-omap.h
b/include/linux/platform_data/iommu-omap.h
index 5b429c4..54a0a95 100644
--- a/include/linux/platform_data/iommu-omap.h
+++ b/include/linux/platform_data/iommu-omap.h
@@ -31,14 +31,10 @@ struct omap_iommu_arch_data {
/**
* struct omap_mmu_dev_attr - OMAP mmu device attributes for omap_hwmod
- * @da_start: device address where the va space starts.
- * @da_end:device address where the va space ends.
* @nr_tlb_entries:number of entries supported by the translation
* look-aside buffer (TLB).
*/
struct omap_mmu_dev_attr {
- u32 da_start;
- u32 da_end;
int nr_tlb_entries;
};
@@ -46,8 +42,6 @@ struct iommu_platform_data {
const char *name;
const char *reset_name;
int nr_tlb_entries;
- u32 da_start;
- u32 da_end;
int (*assert_reset)(struct platform_device *pdev, const char *name);
int (*deassert_reset)(struct platform_device *pdev, const char *name);
--
1.8.5.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 v2 1/3] iommu/omap: Remove virtual memory manager
The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that
is has been ported to the DMA API, remove the unused virtual memory
manager.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/Kconfig| 10 +-
drivers/iommu/Makefile | 1 -
drivers/iommu/omap-iommu-debug.c | 114 --
drivers/iommu/omap-iommu.c | 13 -
drivers/iommu/omap-iommu.h | 8 +-
drivers/iommu/omap-iovmm.c | 791 ---
include/linux/omap-iommu.h | 37 +-
7 files changed, 8 insertions(+), 966 deletions(-)
delete mode 100644 drivers/iommu/omap-iovmm.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d260605..154e5a8 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,16 +143,12 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOVMM
- tristate OMAP IO Virtual Memory Manager Support
- depends on OMAP_IOMMU
-
config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU/IOVMM internals in DebugFS
- depends on OMAP_IOVMM DEBUG_FS
+ tristate Export OMAP IOMMU internals in DebugFS
+ depends on OMAP_IOMMU DEBUG_FS
help
Select this to see extensive information about
- the internal state of OMAP IOMMU/IOVMM in debugfs.
+ the internal state of OMAP IOMMU in debugfs.
Say N unless you know you need this.
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 8893bad..6a4a00e 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o
-obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index 80fffba..531658d 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -213,116 +213,6 @@ static ssize_t debug_read_pagetable(struct file *file,
char __user *userbuf,
return bytes;
}
-static ssize_t debug_read_mmap(struct file *file, char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
- char *p, *buf;
- struct iovm_struct *tmp;
- int uninitialized_var(i);
- ssize_t bytes;
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
- p += sprintf(p, %-3s %-8s %-8s %6s %8s\n,
-No, start, end, size, flags);
- p += sprintf(p, -\n);
-
- mutex_lock(iommu_debug_lock);
-
- list_for_each_entry(tmp, obj-mmap, list) {
- size_t len;
- const char *str = %3d %08x-%08x %6x %8x\n;
- const int maxcol = 39;
-
- len = tmp-da_end - tmp-da_start;
- p += snprintf(p, maxcol, str,
- i, tmp-da_start, tmp-da_end, len, tmp-flags);
-
- if (PAGE_SIZE - (p - buf) maxcol)
- break;
- i++;
- }
-
- bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
-
- mutex_unlock(iommu_debug_lock);
- free_page((unsigned long)buf);
-
- return bytes;
-}
-
-static ssize_t debug_read_mem(struct file *file, char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- char *p, *buf;
- struct iovm_struct *area;
- ssize_t bytes;
-
- count = min_t(ssize_t, count, PAGE_SIZE);
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
- mutex_lock(iommu_debug_lock);
-
- area = omap_find_iovm_area(dev, (u32)ppos);
- if (!area) {
- bytes = -EINVAL;
- goto err_out;
- }
- memcpy(p, area-va, count);
- p += count;
-
- bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
-err_out:
- mutex_unlock(iommu_debug_lock);
- free_page((unsigned long)buf);
-
- return bytes;
-}
-
-static ssize_t debug_write_mem(struct file *file, const char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- struct iovm_struct *area;
- char *p, *buf;
-
- count = min_t(size_t, count, PAGE_SIZE);
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf
Re: [PATCH] iommu/omap: Remove virtual memory manager
Hi Suman,
Thank you for the review.
On Thursday 17 July 2014 10:53:03 Suman Anna wrote:
On 07/17/2014 06:09 AM, Laurent Pinchart wrote:
The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that
is has been ported to the DMA API, remove the unused virtual memory
manager.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Joerg, could you please pick this patch up for v3.17 if possible ?
Need one minor change as below, otherwise patch is good.
drivers/iommu/Kconfig| 10 +-
drivers/iommu/Makefile | 1 -
drivers/iommu/omap-iommu-debug.c | 114 --
drivers/iommu/omap-iommu.c | 2 -
drivers/iommu/omap-iommu.h | 6 +-
drivers/iommu/omap-iovmm.c | 791 --
include/linux/omap-iommu.h | 37 +-
7 files changed, 8 insertions(+), 953 deletions(-)
delete mode 100644 drivers/iommu/omap-iovmm.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d260605..a1f0fad 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,16 +143,12 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOVMM
- tristate OMAP IO Virtual Memory Manager Support
- depends on OMAP_IOMMU
-
config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU/IOVMM internals in DebugFS
- depends on OMAP_IOVMM DEBUG_FS
+ tristate Export OMAP IOMMU internals in DebugFS
+ depends on DEBUG_FS
This module is relevant only when OMAP_IOMMU is enabled, so this should
be depends on OMAP_IOMMU DEBUG_FS. The dependency is inherent before
through OMAP_IOVMM. Otherwise, this module can be built by itself and
results in some build errors.
Oops, my bad. I'll fix that in v2.
help
Select this to see extensive information about
- the internal state of OMAP IOMMU/IOVMM in debugfs.
+ the internal state of OMAP IOMMU in debugfs.
Say N unless you know you need this.
[snip]
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index ea920c3..36a85f3 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -46,9 +46,6 @@ struct omap_iommu {
int nr_tlb_entries;
- struct list_headmmap;
- struct mutexmmap_lock; /* protect mmap */
-
void *ctx; /* iommu context: registres saved area */
u32 da_start;
u32 da_end;
With the removal of omap-iovmm, the da_start and da_end can also be
removed. No need to block this patch for that, it can be done in a
separate patch.
I'll remove the fields from struct omap_iommu in v2. I'll also remove them
from the platform data, but I'll need to do so in a separate patch, as arch/
code needs to be touched as well.
--
Regards,
Laurent Pinchart
--
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] iommu/omap: Remove virtual memory manager
The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that
is has been ported to the DMA API, remove the unused virtual memory
manager.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Joerg, could you please pick this patch up for v3.17 if possible ?
drivers/iommu/Kconfig| 10 +-
drivers/iommu/Makefile | 1 -
drivers/iommu/omap-iommu-debug.c | 114 --
drivers/iommu/omap-iommu.c | 2 -
drivers/iommu/omap-iommu.h | 6 +-
drivers/iommu/omap-iovmm.c | 791 ---
include/linux/omap-iommu.h | 37 +-
7 files changed, 8 insertions(+), 953 deletions(-)
delete mode 100644 drivers/iommu/omap-iovmm.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d260605..a1f0fad 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,16 +143,12 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOVMM
- tristate OMAP IO Virtual Memory Manager Support
- depends on OMAP_IOMMU
-
config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU/IOVMM internals in DebugFS
- depends on OMAP_IOVMM DEBUG_FS
+ tristate Export OMAP IOMMU internals in DebugFS
+ depends on DEBUG_FS
help
Select this to see extensive information about
- the internal state of OMAP IOMMU/IOVMM in debugfs.
+ the internal state of OMAP IOMMU in debugfs.
Say N unless you know you need this.
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 8893bad..6a4a00e 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o
-obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index 80fffba..531658d 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -213,116 +213,6 @@ static ssize_t debug_read_pagetable(struct file *file,
char __user *userbuf,
return bytes;
}
-static ssize_t debug_read_mmap(struct file *file, char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
- char *p, *buf;
- struct iovm_struct *tmp;
- int uninitialized_var(i);
- ssize_t bytes;
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
- p += sprintf(p, %-3s %-8s %-8s %6s %8s\n,
-No, start, end, size, flags);
- p += sprintf(p, -\n);
-
- mutex_lock(iommu_debug_lock);
-
- list_for_each_entry(tmp, obj-mmap, list) {
- size_t len;
- const char *str = %3d %08x-%08x %6x %8x\n;
- const int maxcol = 39;
-
- len = tmp-da_end - tmp-da_start;
- p += snprintf(p, maxcol, str,
- i, tmp-da_start, tmp-da_end, len, tmp-flags);
-
- if (PAGE_SIZE - (p - buf) maxcol)
- break;
- i++;
- }
-
- bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
-
- mutex_unlock(iommu_debug_lock);
- free_page((unsigned long)buf);
-
- return bytes;
-}
-
-static ssize_t debug_read_mem(struct file *file, char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- char *p, *buf;
- struct iovm_struct *area;
- ssize_t bytes;
-
- count = min_t(ssize_t, count, PAGE_SIZE);
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
- mutex_lock(iommu_debug_lock);
-
- area = omap_find_iovm_area(dev, (u32)ppos);
- if (!area) {
- bytes = -EINVAL;
- goto err_out;
- }
- memcpy(p, area-va, count);
- p += count;
-
- bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
-err_out:
- mutex_unlock(iommu_debug_lock);
- free_page((unsigned long)buf);
-
- return bytes;
-}
-
-static ssize_t debug_write_mem(struct file *file, const char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- struct iovm_struct *area;
- char *p, *buf;
-
- count = min_t(size_t, count, PAGE_SIZE);
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf
Re: [PATCH] media:platform: OMAP3 camera support needs VIDEOBUF2_DMA_CONTIG
Hi Peter, Thank you for the patch. On Friday 04 July 2014 09:51:47 Peter Meerwald wrote: drivers/built-in.o: In function `isp_video_open': /src/linux/drivers/media/platform/omap3isp/ispvideo.c:1253: undefined reference to `vb2_dma_contig_memops' drivers/built-in.o: In function `omap3isp_video_init': /src/linux/drivers/media/platform/omap3isp/ispvideo.c:1344: undefined reference to `vb2_dma_contig_init_ctx' /src/linux/drivers/media/platform/omap3isp/ispvideo.c:1350: undefined reference to `vb2_dma_contig_cleanup_ctx' drivers/built-in.o: In function `omap3isp_video_cleanup': /src/linux/drivers/media/platform/omap3isp/ispvideo.c:1381: undefined reference to `vb2_dma_contig_cleanup_ctx' make: *** [vmlinux] Error 1 Signed-off-by: Peter Meerwald pme...@pmeerw.net Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com and applied to my tree, with the select VIDEOBUF2_DMA_CONTIG and select OMAP_IOMMU lines swapped below to keep them alphabetically sorted. --- not sure if this is the right way to fix, at least my kernel compiles drivers/media/platform/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 8108c69..e1ff228 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -95,6 +95,7 @@ config VIDEO_OMAP3 tristate OMAP 3 Camera support depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API ARCH_OMAP3 select ARM_DMA_USE_IOMMU + select VIDEOBUF2_DMA_CONTIG select OMAP_IOMMU ---help--- Driver for an OMAP 3 camera controller. -- Regards, Laurent Pinchart -- 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: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock
Hi Stefan,
Thank you for the patch.
On Tuesday 15 July 2014 12:02:35 Stefan Herbrechtsmeier wrote:
Set 'ti,set-rate-parent' property for the dpll4_m5x2_ck clock, which
is used for the ISP functional clock. This fixes the OMAP3 ISP driver's
clock rate configuration on OMAP34xx, which needs the rate to be
propagated properly to the divider node (dpll4_m5_ck).
Signed-off-by: Stefan Herbrechtsmeier ste...@herbrechtsmeier.net
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Tony Lindgren t...@atomide.com
Cc: Tero Kristo t-kri...@ti.com
Cc: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tero, could you please process it for v3.17 if time still permits ?
---
arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi index e47ff69..5c37500 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -467,6 +467,7 @@
ti,bit-shift = 0x1e;
reg = 0x0d00;
ti,set-bit-to-disable;
+ ti,set-rate-parent;
};
dpll4_m6_ck: dpll4_m6_ck {
--
Regards,
Laurent Pinchart
--
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] [media] staging: allow omap4iss to be modular
Hi Tony, On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 08:32]: On Thursday 12 June 2014 08:15:35 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 07:52]: On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote: These should just use either pinctrl-single.c instead for muxing. Or if they are not mux registers, we do have the syscon mapping available in omap4.dtsi that pbias-regulator.c is already using. Laurent, got any better ideas? The ISS driver needs to write a single register, which contains several independent fields. They thus need to be controlled by a single driver. Some of them might be considered to be related to pinmuxing (although I disagree on that), others are certainly not about muxing (there are clock gate bits for instance). Using the syscon mapping seems like the best option. I'll give it a try. OK if it's not strictly pinctrl related then let's not use pinctrl-single,bits for it. You may be able to implement one or more framework drivers for it for pinctrl/regulator/clock/transceiver whatever that register is doing. In any case it's best to have that handling in a separate helper driver somewhere as it's a separate piece of hardware from the camera module. If it does not fit into any existing frameworks then it's best to have it in a separate driver with the camera driver. The register contains the following fields that control the two CSI2 PHYs (PHY1 and PHY2). 31CAMERARX_CSI22_LANEENABLE2 PHY2 Lane 2 (CSI22_DX2, CSI22_DY2) Enable 30CAMERARX_CSI22_LANEENABLE1 PHY2 Lane 1 (CSI22_DX1, CSI22_DY1) Enable 29CAMERARX_CSI22_LANEENABLE0 PHY2 Lane 0 (CSI22_DX0, CSI22_DY0) Enable 28CAMERARX_CSI21_LANEENABLE4 PHY1 Lane 4 (CSI21_DX4, CSI21_DY4) Enable 27CAMERARX_CSI21_LANEENABLE3 PHY1 Lane 3 (CSI21_DX3, CSI21_DY3) Enable 26CAMERARX_CSI21_LANEENABLE2 PHY1 Lane 2 (CSI21_DX2, CSI21_DY2) Enable 25CAMERARX_CSI21_LANEENABLE1 PHY1 Lane 1 (CSI21_DX1, CSI21_DY1) Enable 24CAMERARX_CSI21_LANEENABLE0 PHY1 Lane 0 (CSI21_DX0, CSI21_DY0) Enable 21CAMERARX_CSI22_CTRLCLKEN PHY2 Clock Enable 20:19 CAMERARX_CSI22_CAMMODE PHY2 Mode (CCP2, CSI1, CSI2) 18CAMERARX_CSI21_CTRLCLKEN PHY1 Clock Enable 17:16 CAMERARX_CSI21_CAMMODE PHY1 Mode (CCP2, CSI1, CSI2) Bits 18 and 21 could be exposed through CCF. Bits 24 to 31 enable/disable the CSI2 lanes, so it could be argued that they could be exposed through the pinctrl framework. However, they need to be configured independently, possibly at runtime. I'm thus not sure pinctrl would be a good idea. Bits 17:16 and 20:19 don't fit in existing frameworks. OK thanks for the info. Sounds like drivers/phy might be the right location for it then and then the phy driver can use the syscon regmap. Given that this register is specific to the ISS, I think handling it as a separate device through a separate driver would only complicate the implementation without any real benefit. Even though it's one register, it shoud still be treated separately from the camera driver. The problems with keeping the register access to the control module in the camera driver are at least following: 1. They live in separate hardware modules that can be clocked separately Actually I don't think that's true. The CSI2 PHY is part of the camera device, with all its registers but the one above in the camera device register space. For some weird reason a couple of bits were pushed to the control module, but that doesn't make the CSI2 PHY itself a separate device. 2. Doing a read-back to flush a posted write in one hardware module most likely won't flush the write to other and that can lead into hard to find mysterious bugs The OMAP4 ISS driver can just read back the CAMERA_RX register, can't it ? 3. If we ever have a common system control module driver, we need to rewrite all the system control module register tinkering in the drivers Sure, but that's already the case today, as the OMAP4 ISS driver already accesses the control module register directly. I won't make that worse :-) So it's best to try to use an existing framework for it. That avoids tons of pain later on ;) I agree, but I don't think the PHY framework would be the right abstraction. As explained above the CSI2 PHY is part of the OMAP4 ISS, so modeling its single control module register as a PHY would be a hack. -- Regards, Laurent Pinchart -- 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] [media] staging: allow omap4iss to be modular
Hi Tony, On Friday 13 June 2014 00:53:25 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 23:48]: On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote: 1. They live in separate hardware modules that can be clocked separately Actually I don't think that's true. The CSI2 PHY is part of the camera device, with all its registers but the one above in the camera device register space. For some weird reason a couple of bits were pushed to the control module, but that doesn't make the CSI2 PHY itself a separate device. Yes they are separate. Anything in the system control module is a separate hardware module from the other devices. So in this case the CSI2 PHY is part of the system control module, not the camera module. Section 8.2.3 (ISS CSI2 PHY) of the OMAP4460 TRM (revision AA) documents the CSI2 PHY is being part of the ISS, with three PHY registers in the ISS register space (not counting the PHY interrupt and status bits in several other ISS registers) and one register in the system control module register space. It's far from clear which power domain(s) is (are) involved. 2. Doing a read-back to flush a posted write in one hardware module most likely won't flush the write to other and that can lead into hard to find mysterious bugs The OMAP4 ISS driver can just read back the CAMERA_RX register, can't it ? Right, but you would have to do readbacks both from the phy register and camera register to ensure writes get written. It's best to keep the logic completely separate especially considering that they can be clocked separately. 3. If we ever have a common system control module driver, we need to rewrite all the system control module register tinkering in the drivers Sure, but that's already the case today, as the OMAP4 ISS driver already accesses the control module register directly. I won't make that worse :-) Well it's in staging for a reason :) So it's best to try to use an existing framework for it. That avoids tons of pain later on ;) I agree, but I don't think the PHY framework would be the right abstraction. As explained above the CSI2 PHY is part of the OMAP4 ISS, so modeling its single control module register as a PHY would be a hack. Well that register belongs to the system control module, not the camera module. It's not like the camera IO space is out of registers or something! :) The PHY has 3 registers in the ISS I/O space and one register in the control module I/O space. I have no idea why they've split it that way. The clock enable bits are especially interested, the source clock (CAM_PHY_CTRL_FCLK) comes from the ISS as documented in section 8.1.1 (ISS Integration), is gated by the control module (the gated clock is called CTRLCLK) and then goes back to the ISS CSI2 PHY (it's mentioned in the CSI2 PHY REGISTER1 documentation). We're already handling similar control module phy cases, see for example drivers/phy/phy-omap-control.c. Maybe you have most of the code already there? I'm afraid not. For PHYs that are in the system control module that solution is perfectly fine, but the CSI2 PHY isn't (or at least not all of it). I would be fine with writing a separate PHY driver if the PHY was completely separate. As the documentation doesn't make it clear which part of the hardware belongs to which module, matching the software implementation with an unknown hardware implementation would be pretty difficult :-) If you have a couple of minutes to spare and can look at the CSI2 PHY documentation in the TRM, you might be more successful than me figuring out how the hardware is implemented. -- Regards, Laurent Pinchart -- 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] [media] staging: allow omap4iss to be modular
Hi Tony, On Friday 13 June 2014 04:10:12 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140613 03:30]: On Friday 13 June 2014 00:53:25 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 23:48]: On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote: 1. They live in separate hardware modules that can be clocked separately Actually I don't think that's true. The CSI2 PHY is part of the camera device, with all its registers but the one above in the camera device register space. For some weird reason a couple of bits were pushed to the control module, but that doesn't make the CSI2 PHY itself a separate device. Yes they are separate. Anything in the system control module is a separate hardware module from the other devices. So in this case the CSI2 PHY is part of the system control module, not the camera module. Section 8.2.3 (ISS CSI2 PHY) of the OMAP4460 TRM (revision AA) documents the CSI2 PHY is being part of the ISS, with three PHY registers in the ISS register space (not counting the PHY interrupt and status bits in several other ISS registers) and one register in the system control module register space. It's far from clear which power domain(s) is (are) involved. OK I see. The register in the system control module just contains some pin and clock related resources for the phy. And the configuration of the PHY mode (CCP2, CSI1 or CSI2). It really seems like random bits :-) 2. Doing a read-back to flush a posted write in one hardware module most likely won't flush the write to other and that can lead into hard to find mysterious bugs The OMAP4 ISS driver can just read back the CAMERA_RX register, can't it ? Right, but you would have to do readbacks both from the phy register and camera register to ensure writes get written. It's best to keep the logic completely separate especially considering that they can be clocked separately. 3. If we ever have a common system control module driver, we need to rewrite all the system control module register tinkering in the drivers Sure, but that's already the case today, as the OMAP4 ISS driver already accesses the control module register directly. I won't make that worse :-) Well it's in staging for a reason :) So it's best to try to use an existing framework for it. That avoids tons of pain later on ;) I agree, but I don't think the PHY framework would be the right abstraction. As explained above the CSI2 PHY is part of the OMAP4 ISS, so modeling its single control module register as a PHY would be a hack. Well that register belongs to the system control module, not the camera module. It's not like the camera IO space is out of registers or something! :) The PHY has 3 registers in the ISS I/O space and one register in the control module I/O space. I have no idea why they've split it that way. The clock enable bits are especially interested, the source clock (CAM_PHY_CTRL_FCLK) comes from the ISS as documented in section 8.1.1 (ISS Integration), is gated by the control module (the gated clock is called CTRLCLK) and then goes back to the ISS CSI2 PHY (it's mentioned in the CSI2 PHY REGISTER1 documentation). We're already handling similar control module phy cases, see for example drivers/phy/phy-omap-control.c. Maybe you have most of the code already there? I'm afraid not. For PHYs that are in the system control module that solution is perfectly fine, but the CSI2 PHY isn't (or at least not all of it). I would be fine with writing a separate PHY driver if the PHY was completely separate. As the documentation doesn't make it clear which part of the hardware belongs to which module, matching the software implementation with an unknown hardware implementation would be pretty difficult :-) Yeah it seems the phy driver would still have to use the pin resources in the system control module. If you have a couple of minutes to spare and can look at the CSI2 PHY documentation in the TRM, you might be more successful than me figuring out how the hardware is implemented. Took a look and it seems the phy is split into two parts. So probably using the syscon mapping for the register in scm are is a good start. At least then there's some protection from drivers tinkering directly with the system control modules. That's my plan. Maybe s ee what drivers/regulator/pbias-regulator.c is doing with syscon to see if that works? Moving that to some phy driver later on should be trivial if needed :) I'll have a look, but I'm not sure whether the same approach will be possible. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord
Re: [PATCH] [media] staging: allow omap4iss to be modular
Hi Arnd,
On Wednesday 11 June 2014 16:49:31 Arnd Bergmann wrote:
On Wednesday 11 June 2014 09:42:04 Nishanth Menon wrote:
On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
To work around that, we can export those symbols, but
that isn't really the correct solution, as we should not
have dependencies on platform code this way.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This is one of just two patches we currently need to get
'make allmodconfig' to build again on ARM.
diff --git a/arch/arm/mach-omap2/control.c
b/arch/arm/mach-omap2/control.c
index 751f354..05d2d98 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
{
return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
void omap4_ctrl_pad_writel(u32 val, u16 offset)
{
writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
#ifdef CONFIG_ARCH_OMAP3
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig index 78b0fba..0c3e3c1 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,5 +1,5 @@
config VIDEO_OMAP4
- bool OMAP 4 Camera support
+ tristate OMAP 4 Camera support
depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4
select VIDEOBUF2_DMA_CONTIG
---help---
This was discussed in detail here:
http://marc.info/?t=14019869251r=1w=2
Direct dependency from a staging driver to mach-omap2 driver is not
something we'd like, right?
So it was decided to just leave ARM allmodconfig broken?
Why not at least do this instead?
8
From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann a...@arndb.de
Date: Tue, 21 Jan 2014 09:32:43 +0100
Subject: [PATCH] [media] staging: tighten omap4iss dependencies
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
Instead, this patch just forbids the invalid configurations
and ensures that the driver can only be built if all its
dependencies are built-in.
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Should I take this in my tree for v3.17 or would you like to fast-track it ?
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig index 78b0fba..8afc6fe 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,6 +1,6 @@
config VIDEO_OMAP4
bool OMAP 4 Camera support
- depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4
+ depends on VIDEO_V4L2=y VIDEO_V4L2_SUBDEV_API I2C=y ARCH_OMAP4
select VIDEOBUF2_DMA_CONTIG
---help---
Driver for an OMAP 4 ISS controller.
--
Regards,
Laurent Pinchart
--
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] [media] staging: allow omap4iss to be modular
Hi Tony,
On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [140611 07:37]:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
That's good news, but let's not fix it this way.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
To work around that, we can export those symbols, but
that isn't really the correct solution, as we should not
have dependencies on platform code this way.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This is one of just two patches we currently need to get
'make allmodconfig' to build again on ARM.
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 751f354..05d2d98 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
{
return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
void omap4_ctrl_pad_writel(u32 val, u16 offset)
{
writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
#ifdef CONFIG_ARCH_OMAP3
Exporting these will likely cause immediate misuse in other
drivers all over the place.
These should just use either pinctrl-single.c instead for muxing.
Or if they are not mux registers, we do have the syscon mapping
available in omap4.dtsi that pbias-regulator.c is already using.
Laurent, got any better ideas?
The ISS driver needs to write a single register, which contains several
independent fields. They thus need to be controlled by a single driver. Some
of them might be considered to be related to pinmuxing (although I disagree on
that), others are certainly not about muxing (there are clock gate bits for
instance).
Using the syscon mapping seems like the best option. I'll give it a try.
--
Regards,
Laurent Pinchart
--
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] [media] staging: allow omap4iss to be modular
Hi Arnd, On Thursday 12 June 2014 16:28:39 Arnd Bergmann wrote: On Thursday 12 June 2014 07:25:15 Greg KH wrote: On Thu, Jun 12, 2014 at 04:15:32PM +0200, Arnd Bergmann wrote: On Thursday 12 June 2014 16:12:17 Laurent Pinchart wrote: From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann a...@arndb.de Date: Tue, 21 Jan 2014 09:32:43 +0100 Subject: [PATCH] [media] staging: tighten omap4iss dependencies The OMAP4 camera support depends on I2C and VIDEO_V4L2, both of which can be loadable modules. This causes build failures if we want the camera driver to be built-in. This can be solved by turning the option into tristate, which unfortunately causes another problem, because the driver incorrectly calls a platform-internal interface for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel. Instead, this patch just forbids the invalid configurations and ensures that the driver can only be built if all its dependencies are built-in. Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Should I take this in my tree for v3.17 or would you like to fast-track it ? I'd actually like to see it in 3.15 as a stable backport if possible, It's not stable material, sorry. To clarify, I was talking about second version of the patch, not the original one. It just does this: config VIDEO_OMAP4 bool OMAP 4 Camera support - depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4 + depends on VIDEO_V4L2=y VIDEO_V4L2_SUBDEV_API I2C=y ARCH_OMAP4 select VIDEOBUF2_DMA_CONTIG ---help--- Driver for an OMAP 4 ISS controller. which enforces that configurations that cannot be compiled will not be selectable in Kconfig, so we can have allmodconfig working. I thought that was ok for -stable. but definitely in 3.16. What is the normal path for staging/media but fix patches? Through Mauro's tree. Ok. I've applied the patch to my tree and will send a pull request to Mauro for v3.16 as soon as you reach an agreement with Greg on whether I should add CC: stable or not. -- Regards, Laurent Pinchart -- 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] [media] staging: allow omap4iss to be modular
Hi Tony, On Thursday 12 June 2014 08:15:35 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 07:52]: On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote: These should just use either pinctrl-single.c instead for muxing. Or if they are not mux registers, we do have the syscon mapping available in omap4.dtsi that pbias-regulator.c is already using. Laurent, got any better ideas? The ISS driver needs to write a single register, which contains several independent fields. They thus need to be controlled by a single driver. Some of them might be considered to be related to pinmuxing (although I disagree on that), others are certainly not about muxing (there are clock gate bits for instance). Using the syscon mapping seems like the best option. I'll give it a try. OK if it's not strictly pinctrl related then let's not use pinctrl-single,bits for it. You may be able to implement one or more framework drivers for it for pinctrl/regulator/clock/transceiver whatever that register is doing. In any case it's best to have that handling in a separate helper driver somewhere as it's a separate piece of hardware from the camera module. If it does not fit into any existing frameworks then it's best to have it in a separate driver with the camera driver. The register contains the following fields that control the two CSI2 PHYs (PHY1 and PHY2). 31CAMERARX_CSI22_LANEENABLE2 PHY2 Lane 2 (CSI22_DX2, CSI22_DY2) Enable 30CAMERARX_CSI22_LANEENABLE1 PHY2 Lane 1 (CSI22_DX1, CSI22_DY1) Enable 29CAMERARX_CSI22_LANEENABLE0 PHY2 Lane 0 (CSI22_DX0, CSI22_DY0) Enable 28CAMERARX_CSI21_LANEENABLE4 PHY1 Lane 4 (CSI21_DX4, CSI21_DY4) Enable 27CAMERARX_CSI21_LANEENABLE3 PHY1 Lane 3 (CSI21_DX3, CSI21_DY3) Enable 26CAMERARX_CSI21_LANEENABLE2 PHY1 Lane 2 (CSI21_DX2, CSI21_DY2) Enable 25CAMERARX_CSI21_LANEENABLE1 PHY1 Lane 1 (CSI21_DX1, CSI21_DY1) Enable 24CAMERARX_CSI21_LANEENABLE0 PHY1 Lane 0 (CSI21_DX0, CSI21_DY0) Enable 21CAMERARX_CSI22_CTRLCLKEN PHY2 Clock Enable 20:19 CAMERARX_CSI22_CAMMODE PHY2 Mode (CCP2, CSI1, CSI2) 18CAMERARX_CSI21_CTRLCLKEN PHY1 Clock Enable 17:16 CAMERARX_CSI21_CAMMODE PHY1 Mode (CCP2, CSI1, CSI2) Bits 18 and 21 could be exposed through CCF. Bits 24 to 31 enable/disable the CSI2 lanes, so it could be argued that they could be exposed through the pinctrl framework. However, they need to be configured independently, possibly at runtime. I'm thus not sure pinctrl would be a good idea. Bits 17:16 and 20:19 don't fit in existing frameworks. Given that this register is specific to the ISS, I think handling it as a separate device through a separate driver would only complicate the implementation without any real benefit. -- Regards, Laurent Pinchart -- 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: video_omap4 and control module access (was ... from opensuse-arm list)
Hi Nishanth, On Thursday 05 June 2014 11:47:19 Nishanth Menon wrote: Full thread in opensuse mailing list: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg4.html Moving this thread out of opensuse to kernel public lists +CC of maintainers relevant to the control module/clk. On 06/05/2014 11:17 AM, Nishanth Menon wrote: On 06/05/2014 10:56 AM, Laurent Pinchart wrote: On Thursday 05 June 2014 08:37:27 Nishanth Menon wrote: On 06/05/2014 08:29 AM, Takashi Iwai wrote: Alexander Graf wrote: On 04.06.14 09:28, Matwey V. Kornilov wrote: On 19.05.2014 14:02, Alexander Graf wrote: note: expected 'uint32_t *' but argument is of type 'dma_addr_t *' I've fixed that one, but can not figure out what is wrong now: https://build.opensuse.org/package/live_build_log/home:matwey:pcm051: 13.2/kernel-default/standard/armv7l If I had to guess I'd say someone forgot to put a few EXPORT_SYMBOLs into the code and never tested whether compiling his v4l / video driver actually works when it's compiled as a module. The problem is CONFIG_VIDEO_OMAP4=y while the whole V4L stuff is built as modules. You have to build V4L into kernel, too. That said, it's a Kconfig dependency issue. Looking at the code, though, omap4-iss driver itself is written to be built also as a module. But its Kconfig is bool, so the problem happens. Maybe a patch like below works? Takashi --- diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig index 78b0fba7047e..0c3e3c1acd4f 100644 --- a/drivers/staging/media/omap4iss/Kconfig +++ b/drivers/staging/media/omap4iss/Kconfig @@ -1,5 +1,5 @@ config VIDEO_OMAP4 -bool OMAP 4 Camera support +tristate OMAP 4 Camera support depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4 select VIDEOBUF2_DMA_CONTIG ---help--- +Sakari and Laurent. Full thread: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg4.html I agree, I see no reason for these to be bool. There's no good reason for the option to be a boolean, but there's a bad reason :-/ The OMAP4 ISS driver calls the omap4_ctrl_pad_readl() and omap4_ctrl_pad_writel() functions, which are not exported. The right way to fix this would be to implement a control module driver for the OMAP4, but that's not a straightforward task, and I don't have time to do so at the moment. a) control module: from: drivers/staging/media/omap4iss/iss_csiphy.c /* * SCM.CONTROL_CAMERA_RX * - bit [31] : CSIPHY2 lane 2 enable (4460+ only) * - bit [30:29] : CSIPHY2 per-lane enable (1 to 0) * - bit [28:24] : CSIPHY1 per-lane enable (4 to 0) * - bit [21] : CSIPHY2 CTRLCLK enable * - bit [20:19] : CSIPHY2 config: 00 d-phy, 01/10 ccp2 * - bit [18] : CSIPHY1 CTRLCLK enable * - bit [17:16] : CSIPHY1 config: 00 d-phy, 01/10 ccp2 */ cam_rx_ctrl = omap4_ctrl_pad_readl( OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX); Is'nt that what pinctrl does? And should be rather trivial to do, no? It's a bit of a grey area. While enabling/disabling CSI lanes could be considered as falling into the scope of pinctrl (but even there I have some doubts, as this is one level beyond pin muxing in my opinion), pushing clock enabling/disabling to pinctrl would require a really big shoehorn :-) The register also controls the CSI2 PHY mode of operation (CCP2, CSI1 or CSI2), which doesn't really look like pinctrl territory to me. Let's also keep in mind that the configuration currently hardcoded by the driver is a shortcut. We want to be able to control each field in the register dynamically and independently. We can't apply partial pinctrl configurations today, so we would need to declare one configuration for every field combination, which really doesn't scale. c) if there is something else that these bits do that I cant figure out, example: for specific stuff like control module bit for clock (which the above code kinda sounds similar to), like how we had for display recently - model it with dts clock[1] The TRM ISS section states that (vii) A dedicated internal clock gate control is present for each PHY. Enable or disable the internal CTRLCLK from the CAMERARX_CSI22_CTRLCLKE[21] CAMERARX_CSI22_CTRLCLKE bit or the [18] CAMERARX_CSI21_CTRLCLKE bit. Those two of the bits could probably be exposed through CCF, and [1] seems to go in the right direction for that. We will still need a solution for the other bits though, as we will need to handle all accesses to the register from a single driver in order to implement proper locking (although we could consider that the caller should handle access serialization, but that's a bit messy I believe). b) if you cannot use existing frameworks OR use pinctrl, last ditch way to do it in pdata-quirks in mach-omap2 with fops being
Re: [PATCHv2 resend 00/11] improve PWM lookup support without device tree
Hi Alexandre and Simon, On Tuesday 20 May 2014 07:39:13 Simon Horman wrote: [ CCed Laurent Pinchart ] The renesas and shmobile portions of this seem reasonable to me and I have checked that there do not seem to be any conflicts with changes I already have queued up for v3.16 (and v3.17). I have CCed Laurent Pinchart as I believe he most recently did work on the renesas and shmobile code in question. The series look sane to me. For the three patches that Simon has acked below, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com On Mon, May 19, 2014 at 10:42:31PM +0200, Alexandre Belloni wrote: Hi, Originally sent on Apr 14th, note that this series is blocking another 16 patches series, I would like it to be taken in 3.16 if we can agree on this implementation. A patch set as suggested by Thierry to make lookup with the lookup table instead of device tree behave more like when using device tree. The first patch adds a period and a polarity member to the lookup table and use those to set period and polarity. Patch 2, 4 and 5 are making use of those new members from the board files. Patch 3 removes useless code since setting the polarity is now handled by the PWM core. I couldn't decide on a good name for the extended PWM_LOOKUP macro and I believe we won't have to add members to that structure soon so: Patch 6 modifies the PWM_LOOKUP macro to also initialize period and polarity and Patch 7-9 are making use of the new PWM_LOOKUP macro in the board files Patch 10 and 11 are making the leds-pwm and pwm_bl drivers get the period from the PWM before using pwm_period_ns if it is not already set. Patch 10 will obviously conflict with the series of Russell reworking the leds-pwm probing. I can rebase if necessary The final goal would be to get rid of .pwm_period_ns in leds-pwm and pwm_bl after moving all the remaining users (still around 25) to pwm_lookup. Changes in v2: - correctly unlock the pwm_lookup_lock mutex before returning. - don't change PWM_LOOKUP atomically - remove tpu_pwm_platform_data and the associated header file - make the leds-pwm and pwm_bl drivers get the period from the PWM Alexandre Belloni (11): pwm: add period and polarity to struct pwm_lookup ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup members pwm: renesas-tpu: remove useless struct tpu_pwm_platform_data The above two patches: Acked-by: Simon Horman horms+rene...@verge.net.au ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members ARM: pxa: hx4700: initialize all the struct pwm_lookup members pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup ARM: shmobile: Armadillo 800 EVA: use PWM_LOOKUP to initialize struct pwm_lookup The above patch: Acked-by: Simon Horman horms+rene...@verge.net.au ARM: pxa: hx4700: use PWM_LOOKUP to initialize struct pwm_lookup leds: leds-pwm: retrieve configured pwm period backlight: pwm_bl: retrieve configured pwm period Documentation/pwm.txt | 3 ++- arch/arm/mach-omap2/board-omap3beagle.c| 3 ++- arch/arm/mach-pxa/hx4700.c | 3 ++- arch/arm/mach-shmobile/board-armadillo800eva.c | 14 +++--- drivers/leds/leds-pwm.c| 5 - drivers/pwm/core.c | 8 +++- drivers/pwm/pwm-renesas-tpu.c | 19 +++ drivers/video/backlight/pwm_bl.c | 8 +--- include/linux/platform_data/pwm-renesas-tpu.h | 16 include/linux/pwm.h| 6 +- 10 files changed, 33 insertions(+), 52 deletions(-) delete mode 100644 include/linux/platform_data/pwm-renesas-tpu.h -- Regards, Laurent Pinchart -- 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/2] ARM: dts: Fix OMAP3 ISP functional clock configuration
On Monday 12 May 2014 18:06:10 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140512 16:17]: On Thursday 08 May 2014 13:57:15 Tomi Valkeinen wrote: On 21/04/14 13:41, Laurent Pinchart wrote: Hello, This patch set enables rate propagation from the OMAP3 ISP functional clock to the DPLL4 M5 clock. It copies Tomi Valkeinen's similar patch set for the OMAP DSS functional clock from the OMAP: OMAP3 DSS related clock patches patch series. Laurent Pinchart (2): ARM: dts: use ti,fixed-factor-clock for dpll4_m5x2_mul_ck ARM: dts: set 'ti,set-rate-parent' for dpll4_m5 path arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +- arch/arm/boot/dts/omap3xxx-clocks.dtsi | 7 --- 2 files changed, 5 insertions(+), 4 deletions(-) These look fine to me. Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Thank you. Tony, could you please pick the patches up for v3.16 ? I'd like to see acks from Tero on these two, or Tero queue them along with other clock dts clock changes. I'm fine with Tero queuing the patches in his tree. Tero, could they go in v3.16 ? -- Regards, Laurent Pinchart -- 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
