* Re: [PATCH 34/57] fbdev: sh_mobile_lcdc: Store the format in struct
From: Guennadi Liakhovetski @ 2011-12-15 22:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1323784972-24205-35-git-send-email-laurent.pinchart@ideasonboard.com>
On Tue, 13 Dec 2011, Laurent Pinchart wrote:
> Store the active format in the channel structure, and use it instead of
> parsing info->var all over the place when the format is needed.
Right, this is what I was wondering about, while looking at the previous
patch:-) But:
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/video/sh_mobile_lcdcfb.c | 21 ++++++++++-----------
> drivers/video/sh_mobile_lcdcfb.h | 4 +++-
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index c6b6b9d..9829e01 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
[snip]
> @@ -1350,6 +1345,8 @@ static int sh_mobile_set_par(struct fb_info *info)
> info->fix.line_length = info->var.xres
> * info->var.bits_per_pixel / 8;
>
> + ch->format = sh_mobile_format_info(sh_mobile_format_fourcc(&info->var));
Cannot this be NULL? As far as I could trace it back, I'm not sure with
hotplug bits_per_pixel would be initialised correctly along the lines of
sh_mobile_fb_reconfig().
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 33/57] fbdev: sh_mobile_lcdc: Add sh_mobile_format_info()
From: Guennadi Liakhovetski @ 2011-12-15 22:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1323784972-24205-34-git-send-email-laurent.pinchart@ideasonboard.com>
On Tue, 13 Dec 2011, Laurent Pinchart wrote:
> The function returns a pointer to a structure describing a format based
> on its fourcc. Use the function where applicable instead of hardcoded
> switch-case statements.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/video/sh_mobile_lcdcfb.c | 174 ++++++++++++++++++++++----------------
> 1 files changed, 102 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index 3bc82ae..c6b6b9d 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
[snip]
> @@ -665,37 +726,20 @@ static void __sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
>
> /* Setup geometry, format, frame buffer memory and operation mode. */
> for (k = 0; k < ARRAY_SIZE(priv->ch); k++) {
> + const struct sh_mobile_lcdc_format_info *format;
> + u32 fourcc;
> +
> ch = &priv->ch[k];
> if (!ch->enabled)
> continue;
>
> sh_mobile_lcdc_geometry(ch);
>
> - switch (sh_mobile_format_fourcc(&ch->info->var)) {
> - case V4L2_PIX_FMT_RGB565:
> - tmp = LDDFR_PKF_RGB16;
> - break;
> - case V4L2_PIX_FMT_BGR24:
> - tmp = LDDFR_PKF_RGB24;
> - break;
> - case V4L2_PIX_FMT_BGR32:
> - tmp = LDDFR_PKF_ARGB32;
> - break;
> - case V4L2_PIX_FMT_NV12:
> - case V4L2_PIX_FMT_NV21:
> - tmp = LDDFR_CC | LDDFR_YF_420;
> - break;
> - case V4L2_PIX_FMT_NV16:
> - case V4L2_PIX_FMT_NV61:
> - tmp = LDDFR_CC | LDDFR_YF_422;
> - break;
> - case V4L2_PIX_FMT_NV24:
> - case V4L2_PIX_FMT_NV42:
> - tmp = LDDFR_CC | LDDFR_YF_444;
> - break;
> - }
> + fourcc = sh_mobile_format_fourcc(&ch->info->var);
> + format = sh_mobile_format_info(fourcc);
> + tmp = format->lddfr;
Why don't you just store a pointer to the selected format struct per
channel in sh_mobile_lcdc_channel_init() to avoid recalculation here? If
OTOH this can be a new info here from a hotplug event, the above risks an
Oops?
>
> - if (sh_mobile_format_is_yuv(&ch->info->var)) {
> + if (format->yuv) {
> switch (ch->info->var.colorspace) {
> case V4L2_COLORSPACE_REC709:
> tmp |= LDDFR_CF1;
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 27/57] fbdev: sh_mobile_lcdc: Pass a video mode to the
From: Guennadi Liakhovetski @ 2011-12-15 19:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1323784972-24205-28-git-send-email-laurent.pinchart@ideasonboard.com>
On Tue, 13 Dec 2011, Laurent Pinchart wrote:
> Pass pointers to struct fb_videomode and struct fb_monspecs instead of
> struct fb_var_screeninfo to the notify callback.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/video/sh_mobile_hdmi.c | 59 +++++++++++++++++--------------------
> drivers/video/sh_mobile_lcdcfb.c | 40 ++++++++++++++-----------
> drivers/video/sh_mobile_lcdcfb.h | 3 +-
> 3 files changed, 51 insertions(+), 51 deletions(-)
[snip]
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index 21e5f10..4ec216e 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
[ditto]
> @@ -433,12 +432,17 @@ static int sh_mobile_lcdc_display_notify(struct sh_mobile_lcdc_chan *ch,
> }
> break;
>
> - case SH_MOBILE_LCDC_EVENT_DISPLAY_MODE:
> + case SH_MOBILE_LCDC_EVENT_DISPLAY_MODE: {
> + struct fb_var_screeninfo var;
> +
> /* Validate a proposed new mode */
> - var->bits_per_pixel = info->var.bits_per_pixel;
> - ret = info->fbops->fb_check_var(var, info);
> + fb_videomode_to_var(&var, mode);
> + var.bits_per_pixel = info->var.bits_per_pixel;
> + var.grayscale = info->var.grayscale;
> + ret = info->fbops->fb_check_var(&var, info);
> break;
> }
> + }
nitpick - please, realign:-)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH v4 REPOST 2/5] ARM: SMP: Refactor Kconfig to be more
From: David Brown @ 2011-12-15 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1323862781-3465-3-git-send-email-dave.martin@linaro.org>
On Wed, Dec 14, 2011 at 11:39:38AM +0000, Dave Martin wrote:
> Making SMP depend on (huge list of MACH_ and ARCH_ configs) is
> bothersome to maintain and likely to lead to merge conflicts.
>
> This patch moves the knowledge of which platforms are SMP-capable
> to the individual machines. To enable this, a new HAVE_SMP config
> option is introduced to allow machines to indicate that they can
> run in a SMP configuration.
There still seem to be several people and lists from the
get_maintainer.pl output that are missing. Russell should be
included, as well as the MSM maintainers and that list.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 24/57] fbdev: sh_mobile_lcdc: Return display connection
From: Guennadi Liakhovetski @ 2011-12-15 17:11 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1323784972-24205-25-git-send-email-laurent.pinchart@ideasonboard.com>
On Tue, 13 Dec 2011, Laurent Pinchart wrote:
> Return true if the display is connected and false otherwise. Set the fb
> info state to FBINFO_STATE_SUSPENDED in the sh_mobile_lcdc driver when
> the display is not connected.
Hmm... I'm not sure I like functions, that return either a negative error,
or _several_ non-negative success values. How about returning -ENODEV?
Thanks
Guennadi
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/video/sh_mipi_dsi.c | 2 +-
> drivers/video/sh_mobile_hdmi.c | 9 +++++----
> drivers/video/sh_mobile_lcdcfb.c | 3 +++
> drivers/video/sh_mobile_lcdcfb.h | 3 +++
> 4 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
> index 1ede247..5ff3742 100644
> --- a/drivers/video/sh_mipi_dsi.c
> +++ b/drivers/video/sh_mipi_dsi.c
> @@ -412,7 +412,7 @@ static int mipi_display_on(struct sh_mobile_lcdc_entity *entity)
>
> sh_mipi_dsi_enable(mipi, true);
>
> - return 0;
> + return SH_MOBILE_LCDC_DISPLAY_CONNECTED;
>
> mipi_display_on_fail1:
> pm_runtime_put_sync(&mipi->pdev->dev);
> diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
> index c22e123..1464abf 100644
> --- a/drivers/video/sh_mobile_hdmi.c
> +++ b/drivers/video/sh_mobile_hdmi.c
> @@ -1004,9 +1004,9 @@ static int sh_hdmi_display_on(struct sh_mobile_lcdc_entity *entity)
> {
> struct sh_hdmi *hdmi = entity_to_sh_hdmi(entity);
> struct sh_mobile_lcdc_chan *ch = entity->lcdc;
> - struct fb_info *info = ch->info;
>
> - dev_dbg(hdmi->dev, "%s(%p): state %x\n", __func__, hdmi, info->state);
> + dev_dbg(hdmi->dev, "%s(%p): state %x\n", __func__, hdmi,
> + hdmi->hp_state);
>
> /*
> * hp_state can be set to
> @@ -1021,12 +1021,13 @@ static int sh_hdmi_display_on(struct sh_mobile_lcdc_entity *entity)
> dev_dbg(hdmi->dev, "HDMI running\n");
> break;
> case HDMI_HOTPLUG_DISCONNECTED:
> - info->state = FBINFO_STATE_SUSPENDED;
> default:
> hdmi->var = ch->display_var;
> }
>
> - return 0;
> + return hdmi->hp_state = HDMI_HOTPLUG_DISCONNECTED
> + ? SH_MOBILE_LCDC_DISPLAY_DISCONNECTED
> + : SH_MOBILE_LCDC_DISPLAY_CONNECTED;
> }
>
> static void sh_hdmi_display_off(struct sh_mobile_lcdc_entity *entity)
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index 47108aa..4b03aa5 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -342,6 +342,9 @@ static void sh_mobile_lcdc_display_on(struct sh_mobile_lcdc_chan *ch)
> ret = ch->tx_dev->ops->display_on(ch->tx_dev);
> if (ret < 0)
> return;
> +
> + if (ret = SH_MOBILE_LCDC_DISPLAY_DISCONNECTED)
> + ch->info->state = FBINFO_STATE_SUSPENDED;
> }
>
> /* HDMI must be enabled before LCDC configuration */
> diff --git a/drivers/video/sh_mobile_lcdcfb.h b/drivers/video/sh_mobile_lcdcfb.h
> index b2cb8e6..6fb956c 100644
> --- a/drivers/video/sh_mobile_lcdcfb.h
> +++ b/drivers/video/sh_mobile_lcdcfb.h
> @@ -21,6 +21,9 @@ struct sh_mobile_lcdc_entity;
> struct sh_mobile_lcdc_priv;
> struct sh_mobile_lcdc_chan;
>
> +#define SH_MOBILE_LCDC_DISPLAY_DISCONNECTED 0
> +#define SH_MOBILE_LCDC_DISPLAY_CONNECTED 1
> +
> struct sh_mobile_lcdc_entity_ops {
> /* Display */
> int (*display_on)(struct sh_mobile_lcdc_entity *entity);
> --
> 1.7.3.4
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 21/57] sh_mobile_lcdc: Add an lcdc channel pointer to
From: Guennadi Liakhovetski @ 2011-12-15 16:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1323784972-24205-22-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Laurent
On Tue, 13 Dec 2011, Laurent Pinchart wrote:
> The field will be used by the transmitter drivers to access
> sh_mobile_lcdc_chan fields such as fb_info.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/video/sh_mobile_lcdcfb.c | 5 ++++-
> drivers/video/sh_mobile_lcdcfb.h | 2 ++
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index cb5ea3c..2dccfde 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -1497,8 +1497,10 @@ static int sh_mobile_lcdc_remove(struct platform_device *pdev)
> if (!info || !info->device)
> continue;
>
> - if (ch->tx_dev)
> + if (ch->tx_dev) {
> + ch->tx_dev->lcdc = NULL;
> module_put(ch->cfg.tx_dev->dev.driver->owner);
> + }
>
> if (ch->sglist)
> vfree(ch->sglist);
> @@ -1608,6 +1610,7 @@ sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_priv *priv,
> return -EINVAL;
> }
> ch->tx_dev = platform_get_drvdata(cfg->tx_dev);
> + ch->tx_dev->lcdc = ch;
I do not have a kernel, patched with your patches up to 20/57;-) so, I
cannot verify - can ch->tx_dev at this point not be NULL?
> }
>
> /* Iterate through the modes to validate them and find the highest
> diff --git a/drivers/video/sh_mobile_lcdcfb.h b/drivers/video/sh_mobile_lcdcfb.h
> index 9601b92..36cd564 100644
> --- a/drivers/video/sh_mobile_lcdcfb.h
> +++ b/drivers/video/sh_mobile_lcdcfb.h
> @@ -19,6 +19,7 @@ struct fb_info;
> struct module;
> struct sh_mobile_lcdc_entity;
> struct sh_mobile_lcdc_priv;
> +struct sh_mobile_lcdc_chan;
>
> struct sh_mobile_lcdc_entity_ops {
> /* Display */
> @@ -30,6 +31,7 @@ struct sh_mobile_lcdc_entity_ops {
> struct sh_mobile_lcdc_entity {
> struct module *owner;
> const struct sh_mobile_lcdc_entity_ops *ops;
> + struct sh_mobile_lcdc_chan *lcdc;
> };
>
> /*
> --
> 1.7.3.4
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH v5 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
From: Dave Martin @ 2011-12-15 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1323964434-6764-1-git-send-email-dave.martin@linaro.org>
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller
support built into the kernel, so this patch removes the dependency
on CACHE_L2X0.
This makes the l2x0 support optional, so that it can be turned off
when desired for debugging purposes etc.
Since SOC_IMX6Q already depends on ARCH_IMX_V6_V7 and
ARCH_IMX_V6_V7 selects MIGHT_HAVE_CACHE_L2X0, there is no need to
select that option explicitly from SOC_IMX6Q.
Thanks to Shawn Guo for this suggestion. [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
Changes:
v5: Don't select MIGHT_HAVE_CACHE_L2X0 directly from SOC_IMX6Q, but
instead select implicitly via ARCH_IMX_V6_V7 (which we expect
to be selected by other relevant SoCs). Thanks to Shawn for
this suggestion.
arch/arm/mach-imx/Kconfig | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 29a3d61..1530678 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -609,7 +609,6 @@ comment "i.MX6 family:"
config SOC_IMX6Q
bool "i.MX6 Quad support"
select ARM_GIC
- select CACHE_L2X0
select CPU_V7
select HAVE_ARM_SCU
select HAVE_IMX_GPC
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 4/5] highbank: Unconditionally require l2x0 L2 cache controller support
From: Dave Martin @ 2011-12-15 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1323964434-6764-1-git-send-email-dave.martin@linaro.org>
If running in the Normal World on a TrustZone-enabled SoC, Linux
does not have complete control over the L2 cache controller
configuration. The kernel cannot work reliably on such platforms
without the l2x0 cache support code built in.
This patch unconditionally enables l2x0 support for the Highbank
SoC.
Thanks to Rob Herring for this suggestion. [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
---
arch/arm/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index eca82f9..1792146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -340,12 +340,12 @@ config ARCH_HIGHBANK
select ARM_AMBA
select ARM_GIC
select ARM_TIMER_SP804
+ select CACHE_L2X0
select CLKDEV_LOOKUP
select CPU_V7
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU
select HAVE_SMP
- select MIGHT_HAVE_CACHE_L2X0
select USE_OF
help
Support for the Calxeda Highbank SoC based boards.
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
From: Dave Martin @ 2011-12-15 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1323964434-6764-1-git-send-email-dave.martin@linaro.org>
If running in the Normal World on a TrustZone-enabled SoC, Linux
does not have complete control over the L2 cache controller
configuration. The kernel cannot work reliably on such platforms
without the l2x0 cache support code built in.
This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
Thanks to Rob Herring for this suggestion. [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index bb1b670..94e568a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -41,11 +41,11 @@ config ARCH_OMAP4
bool "TI OMAP4"
default y
depends on ARCH_OMAP2PLUS
+ select CACHE_L2X0
select CPU_V7
select ARM_GIC
select HAVE_SMP
select LOCAL_TIMERS if SMP
- select MIGHT_HAVE_CACHE_L2X0
select PL310_ERRATA_588369
select PL310_ERRATA_727915
select ARM_ERRATA_720789
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 2/5] ARM: SMP: Refactor Kconfig to be more maintainable
From: Dave Martin @ 2011-12-15 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1323964434-6764-1-git-send-email-dave.martin@linaro.org>
Making SMP depend on (huge list of MACH_ and ARCH_ configs) is
bothersome to maintain and likely to lead to merge conflicts.
This patch moves the knowledge of which platforms are SMP-capable
to the individual machines. To enable this, a new HAVE_SMP config
option is introduced to allow machines to indicate that they can
run in a SMP configuration.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
(for nomadik, ux500)
Acked-by: Tony Lindgren <tony@atomide.com>
(for omap)
---
Changes:
v5: Minor change to the Kconfig help text to make it more
informative.
arch/arm/Kconfig | 18 ++++++++++++++----
arch/arm/mach-exynos/Kconfig | 1 +
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-msm/Kconfig | 1 +
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-realview/Kconfig | 4 ++++
arch/arm/mach-vexpress/Kconfig | 1 +
7 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 16a4b9e..eca82f9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -344,6 +344,7 @@ config ARCH_HIGHBANK
select CPU_V7
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU
+ select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
select USE_OF
help
@@ -636,6 +637,7 @@ config ARCH_TEGRA
select GENERIC_GPIO
select HAVE_CLK
select HAVE_SCHED_CLOCK
+ select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
select ARCH_HAS_CPUFREQ
help
@@ -706,6 +708,7 @@ config ARCH_SHMOBILE
select HAVE_CLK
select CLKDEV_LOOKUP
select HAVE_MACH_CLKDEV
+ select HAVE_SMP
select GENERIC_CLOCKEVENTS
select MIGHT_HAVE_CACHE_L2X0
select NO_IOPORT
@@ -909,6 +912,7 @@ config ARCH_U8500
select CLKDEV_LOOKUP
select ARCH_REQUIRE_GPIOLIB
select ARCH_HAS_CPUFREQ
+ select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
help
Support for ST-Ericsson's Ux500 architecture
@@ -1430,14 +1434,20 @@ menu "Kernel Features"
source "kernel/time/Kconfig"
+config HAVE_SMP
+ bool
+ help
+ This option should be selected by machines which have an SMP-
+ capable CPU.
+
+ The only effect of this option is to make the SMP-related
+ options available to the user for configuration.
+
config SMP
bool "Symmetric Multi-Processing"
depends on CPU_V6K || CPU_V7
depends on GENERIC_CLOCKEVENTS
- depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \
- MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \
- ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \
- ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE || ARCH_HIGHBANK || SOC_IMX6Q
+ depends on HAVE_SMP
depends on MMU
select USE_GENERIC_SMP_HELPERS
select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 7f2347b..e1efbca 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -17,6 +17,7 @@ choice
config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
+ select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
help
Samsung EXYNOS4 SoCs based systems
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 5f7f9c2..29a3d61 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -615,6 +615,7 @@ config SOC_IMX6Q
select HAVE_IMX_GPC
select HAVE_IMX_MMDC
select HAVE_IMX_SRC
+ select HAVE_SMP
select USE_OF
help
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index ebde97f..e6beaff 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -67,6 +67,7 @@ config MSM_SOC_REV_A
bool
config ARCH_MSM_SCORPIONMP
bool
+ select HAVE_SMP
config ARCH_MSM_ARM11
bool
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index c841578..bb1b670 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -43,6 +43,7 @@ config ARCH_OMAP4
depends on ARCH_OMAP2PLUS
select CPU_V7
select ARM_GIC
+ select HAVE_SMP
select LOCAL_TIMERS if SMP
select MIGHT_HAVE_CACHE_L2X0
select PL310_ERRATA_588369
diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index 3dd620f..c593be4 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -12,6 +12,7 @@ config REALVIEW_EB_A9MP
bool "Support Multicore Cortex-A9 Tile"
depends on MACH_REALVIEW_EB
select CPU_V7
+ select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
help
Enable support for the Cortex-A9MPCore tile fitted to the
@@ -22,6 +23,7 @@ config REALVIEW_EB_ARM11MP
depends on MACH_REALVIEW_EB
select CPU_V6K
select ARCH_HAS_BARRIERS if SMP
+ select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
help
Enable support for the ARM11MPCore tile fitted to the Realview(R)
@@ -41,6 +43,7 @@ config MACH_REALVIEW_PB11MP
select CPU_V6K
select ARM_GIC
select HAVE_PATA_PLATFORM
+ select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
select ARCH_HAS_BARRIERS if SMP
help
@@ -82,6 +85,7 @@ config MACH_REALVIEW_PBX
bool "Support RealView(R) Platform Baseboard Explore"
select ARM_GIC
select HAVE_PATA_PLATFORM
+ select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
select ARCH_SPARSEMEM_ENABLE if CPU_V7 && !REALVIEW_HIGH_PHYS_OFFSET
select ZONE_DMA if SPARSEMEM
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index a8aefc8..9b3d0fb 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -8,6 +8,7 @@ config ARCH_VEXPRESS_CA9X4
select ARM_ERRATA_720789
select ARM_ERRATA_751472
select ARM_ERRATA_753970
+ select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
endmenu
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 1/5] ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
From: Dave Martin @ 2011-12-15 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1323964434-6764-1-git-send-email-dave.martin@linaro.org>
Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs)
is bothersome to maintain and likely to lead to merge conflicts.
This patch moves the knowledge of which platforms have a L2x0 or
PL310 cache controller to the individual machines. To enable this,
a new MIGHT_HAVE_CACHE_L2X0 config option is introduced to allow
machines to indicate that they may have such a cache controller
independently of each other.
Boards/SoCs which cannot reliably operate without the L2 cache
controller support will need to select CACHE_L2X0 directly from
their own Kconfigs instead. This applies to some TrustZone-enabled
boards where Linux runs in the Normal World, for example.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
(for cns3xxx)
Acked-by: Tony Lindgren <tony@atomide.com>
(for omap)
---
Changes:
v5: Minor change to the Kconfig help text to make it more
informative.
arch/arm/Kconfig | 8 ++++++++
arch/arm/mach-exynos/Kconfig | 1 +
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-realview/Kconfig | 5 +++++
arch/arm/mach-vexpress/Kconfig | 1 +
arch/arm/mm/Kconfig | 23 ++++++++++++++++-------
arch/arm/plat-mxc/Kconfig | 1 +
7 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 44789ef..16a4b9e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -344,6 +344,7 @@ config ARCH_HIGHBANK
select CPU_V7
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU
+ select MIGHT_HAVE_CACHE_L2X0
select USE_OF
help
Support for the Calxeda Highbank SoC based boards.
@@ -361,6 +362,7 @@ config ARCH_CNS3XXX
select CPU_V6K
select GENERIC_CLOCKEVENTS
select ARM_GIC
+ select MIGHT_HAVE_CACHE_L2X0
select MIGHT_HAVE_PCI
select PCI_DOMAINS if PCI
help
@@ -381,6 +383,7 @@ config ARCH_PRIMA2
select GENERIC_CLOCKEVENTS
select CLKDEV_LOOKUP
select GENERIC_IRQ_CHIP
+ select MIGHT_HAVE_CACHE_L2X0
select USE_OF
select ZONE_DMA
help
@@ -633,6 +636,7 @@ config ARCH_TEGRA
select GENERIC_GPIO
select HAVE_CLK
select HAVE_SCHED_CLOCK
+ select MIGHT_HAVE_CACHE_L2X0
select ARCH_HAS_CPUFREQ
help
This enables support for NVIDIA Tegra based systems (Tegra APX,
@@ -703,6 +707,7 @@ config ARCH_SHMOBILE
select CLKDEV_LOOKUP
select HAVE_MACH_CLKDEV
select GENERIC_CLOCKEVENTS
+ select MIGHT_HAVE_CACHE_L2X0
select NO_IOPORT
select SPARSE_IRQ
select MULTI_IRQ_HANDLER
@@ -904,6 +909,7 @@ config ARCH_U8500
select CLKDEV_LOOKUP
select ARCH_REQUIRE_GPIOLIB
select ARCH_HAS_CPUFREQ
+ select MIGHT_HAVE_CACHE_L2X0
help
Support for ST-Ericsson's Ux500 architecture
@@ -914,6 +920,7 @@ config ARCH_NOMADIK
select CPU_ARM926T
select CLKDEV_LOOKUP
select GENERIC_CLOCKEVENTS
+ select MIGHT_HAVE_CACHE_L2X0
select ARCH_REQUIRE_GPIOLIB
help
Support for the Nomadik platform by ST-Ericsson
@@ -973,6 +980,7 @@ config ARCH_ZYNQ
select ARM_GIC
select ARM_AMBA
select ICST
+ select MIGHT_HAVE_CACHE_L2X0
select USE_OF
help
Support for Xilinx Zynq ARM Cortex A9 Platform
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 724ec0f..7f2347b 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -17,6 +17,7 @@ choice
config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
+ select MIGHT_HAVE_CACHE_L2X0
help
Samsung EXYNOS4 SoCs based systems
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5034147..c841578 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -44,6 +44,7 @@ config ARCH_OMAP4
select CPU_V7
select ARM_GIC
select LOCAL_TIMERS if SMP
+ select MIGHT_HAVE_CACHE_L2X0
select PL310_ERRATA_588369
select PL310_ERRATA_727915
select ARM_ERRATA_720789
diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index dba6d0c..3dd620f 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -12,6 +12,7 @@ config REALVIEW_EB_A9MP
bool "Support Multicore Cortex-A9 Tile"
depends on MACH_REALVIEW_EB
select CPU_V7
+ select MIGHT_HAVE_CACHE_L2X0
help
Enable support for the Cortex-A9MPCore tile fitted to the
Realview(R) Emulation Baseboard platform.
@@ -21,6 +22,7 @@ config REALVIEW_EB_ARM11MP
depends on MACH_REALVIEW_EB
select CPU_V6K
select ARCH_HAS_BARRIERS if SMP
+ select MIGHT_HAVE_CACHE_L2X0
help
Enable support for the ARM11MPCore tile fitted to the Realview(R)
Emulation Baseboard platform.
@@ -39,6 +41,7 @@ config MACH_REALVIEW_PB11MP
select CPU_V6K
select ARM_GIC
select HAVE_PATA_PLATFORM
+ select MIGHT_HAVE_CACHE_L2X0
select ARCH_HAS_BARRIERS if SMP
help
Include support for the ARM(R) RealView(R) Platform Baseboard for
@@ -51,6 +54,7 @@ config MACH_REALVIEW_PB1176
select CPU_V6
select ARM_GIC
select HAVE_TCM
+ select MIGHT_HAVE_CACHE_L2X0
help
Include support for the ARM(R) RealView(R) Platform Baseboard for
ARM1176JZF-S.
@@ -78,6 +82,7 @@ config MACH_REALVIEW_PBX
bool "Support RealView(R) Platform Baseboard Explore"
select ARM_GIC
select HAVE_PATA_PLATFORM
+ select MIGHT_HAVE_CACHE_L2X0
select ARCH_SPARSEMEM_ENABLE if CPU_V7 && !REALVIEW_HIGH_PHYS_OFFSET
select ZONE_DMA if SPARSEMEM
help
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 9311484..a8aefc8 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -8,5 +8,6 @@ config ARCH_VEXPRESS_CA9X4
select ARM_ERRATA_720789
select ARM_ERRATA_751472
select ARM_ERRATA_753970
+ select MIGHT_HAVE_CACHE_L2X0
endmenu
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 67f75a0..acb1c36 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -816,14 +816,23 @@ config CACHE_FEROCEON_L2_WRITETHROUGH
Say Y here to use the Feroceon L2 cache in writethrough mode.
Unless you specifically require this, say N for writeback mode.
+config MIGHT_HAVE_CACHE_L2X0
+ bool
+ help
+ This option should be selected by machines which have a L2x0
+ or PL310 cache controller, but where its use is optional.
+
+ The only effect of this option is to make CACHE_L2X0 and
+ related options available to the user for configuration.
+
+ Boards or SoCs which always require the cache controller
+ support to be present should select CACHE_L2X0 directly
+ instead of this option, thus preventing the user from
+ inadvertently configuring a broken kernel.
+
config CACHE_L2X0
- bool "Enable the L2x0 outer cache controller"
- depends on REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || MACH_REALVIEW_PB1176 || \
- REALVIEW_EB_A9MP || ARCH_IMX_V6_V7 || MACH_REALVIEW_PBX || \
- ARCH_NOMADIK || ARCH_OMAP4 || ARCH_EXYNOS4 || ARCH_TEGRA || \
- ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || ARCH_SHMOBILE || \
- ARCH_PRIMA2 || ARCH_ZYNQ || ARCH_CNS3XXX || ARCH_HIGHBANK
- default y
+ bool "Enable the L2x0 outer cache controller" if MIGHT_HAVE_CACHE_L2X0
+ default MIGHT_HAVE_CACHE_L2X0
select OUTER_CACHE
select OUTER_CACHE_SYNC
help
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index b3a1f2b..b30708e 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -20,6 +20,7 @@ config ARCH_IMX_V6_V7
bool "i.MX3, i.MX6"
select AUTO_ZRELADDR if !ZBOOT_ROM
select ARM_PATCH_PHYS_VIRT
+ select MIGHT_HAVE_CACHE_L2X0
help
This enables support for systems based on the Freescale i.MX3 and i.MX6
family.
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 0/5] Refactor common Kconfigs for easier maintenance
From: Dave Martin @ 2011-12-15 15:53 UTC (permalink / raw)
To: linux-arm-kernel
Common Kconfig options which depend on a long list of board- and
SoC- specific Kconfigs can be cumbersome to maintain, leading to
annoying merge conflicts (although rather trivial ones).
This series factors out the dependencies of CACHE_L2X0 and SMP so
that the knowledge about when these can be enabled is moved to the
relevant board/SoC Kconfig files instead. New
MIGHT_HAVE_CACHE_L2X0 and HAVE_SMP options are defined to mediate
the dependencies.
This series has been substantially reworked compared with the
previous post, and is now in two parts:
* The first two patches simply refactor the way the Kconfig
options for CACHE_L2X0 and SMP are implemented, without
making any other changes.
* The final three patches apply functional changes suggested by
the contributors to this series, to make the config
dependencies more correct for some specific boards.
Thanks to Rob Herring, Shawn Guo and Russell King for their
contributions to this series. Thanks also to David Brown for
pointing out the lack of a comprehensive CC list.
I have briefly build-tested on some of the affected boards, but any
further reviews or Tested-Bys would be much appreciated.
Dave Martin (5):
ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
ARM: SMP: Refactor Kconfig to be more maintainable
omap4: Unconditionally require l2x0 L2 cache controller support
highbank: Unconditionally require l2x0 L2 cache controller support
imx6q: Remove unconditional dependency on l2x0 L2 cache support
arch/arm/Kconfig | 26 ++++++++++++++++++++++----
arch/arm/mach-exynos/Kconfig | 2 ++
arch/arm/mach-imx/Kconfig | 2 +-
arch/arm/mach-msm/Kconfig | 1 +
arch/arm/mach-omap2/Kconfig | 2 ++
arch/arm/mach-realview/Kconfig | 9 +++++++++
arch/arm/mach-vexpress/Kconfig | 2 ++
arch/arm/mm/Kconfig | 23 ++++++++++++++++-------
arch/arm/plat-mxc/Kconfig | 1 +
9 files changed, 56 insertions(+), 12 deletions(-)
--
1.7.4.1
^ permalink raw reply
* Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on
From: Dave Martin @ 2011-12-15 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111215015414.GQ28768@b20223-02.ap.freescale.net>
On Thu, Dec 15, 2011 at 09:54:15AM +0800, Richard Zhao wrote:
> On Thu, Dec 15, 2011 at 09:46:20AM +0800, Shawn Guo wrote:
> > On Thu, Dec 15, 2011 at 09:02:20AM +0800, Richard Zhao wrote:
> > > On Wed, Dec 14, 2011 at 03:01:19PM +0000, Dave Martin wrote:
> > > > On Wed, Dec 14, 2011 at 10:05:04PM +0800, Richard Zhao wrote:
> > > > > On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote:
> > > > > > Hi Dave,
> > > > > >
> > > > > > Sorry for that I did not look into previous post to point it out.
> > > > > >
> > > > > > On Wed, Dec 14, 2011 at 11:39:41AM +0000, Dave Martin wrote:
> > > > > > > The i.MX6 Quad SoC will work without the l2x0 L2 cache controller
> > > > > > > support built into the kernel, so this patch removes the dependency
> > > > > > > on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead.
> > > > > > >
> > > > > > > This makes the l2x0 support optional, so that it can be turned off
> > > > > > > when desired for debugging purposes etc.
> > > > > > >
> > > > > > > Thanks to Shawn Guo for this suggestion. [1]
> > > > > > >
> > > > > > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > > > > > >
> > > > > > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
> > > > > > > ---
> > > > > > > arch/arm/mach-imx/Kconfig | 2 +-
> > > > > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > > > > >
> > > > > > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > > > > > > index 29a3d61..1fb93f2 100644
> > > > > > > --- a/arch/arm/mach-imx/Kconfig
> > > > > > > +++ b/arch/arm/mach-imx/Kconfig
> > > > > > > @@ -609,13 +609,13 @@ comment "i.MX6 family:"
> > > > > > > config SOC_IMX6Q
> > > > > > > bool "i.MX6 Quad support"
> > > > > > > select ARM_GIC
> > > > > > > - select CACHE_L2X0
> > > > > > > select CPU_V7
> > > > > > > select HAVE_ARM_SCU
> > > > > > > select HAVE_IMX_GPC
> > > > > > > select HAVE_IMX_MMDC
> > > > > > > select HAVE_IMX_SRC
> > > > > > > select HAVE_SMP
> > > > > > > + select MIGHT_HAVE_CACHE_L2X0
> > > > > >
> > > > > > The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected.
> > > > > > Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in
> > > > > > patch #1, this line seems redundant here.
> > > > > Would it be better keep this one and remove patch #1 one? imx5 doesn't have
> > > > > l2x0.
> > > >
> > > > Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select
> > > > it only from SOC_IMX6Q?
> > > Yes, I think it's more precise. Shawn?
> > >
> > No.
> >
> > * imx5 hardware does have L2, and it's just not set up in the kernel
> > (I do not know why).
> > * Currently, ARCH_IMX_V6_V7 only covers imx3 and imx6, and both are
> > calling l2x0 init function to set L2 up.
> > * When we merge mach-mx5 into mach-imx to have ARCH_IMX_V6_V7 cover
> > imx3, imx5 and imx6, there is no reason for us to not set L2 up for
> > imx5 too.
> >
> > So MIGHT_HAVE_CACHE_L2X0 really should be selected by ARCH_IMX_V6_V7.
> mx5/cortex-a8 don't use L2X0. But that's ok. MIGHT_HAVE_CACHE_L2X0 is just a hint.
> Please Shawn's suggestion.
OK, my local series has what I believe to be the correct change;
I will repost based on that.
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH 12/57] arm: mach-shmobile: Add LCDC tx_dev field to
From: Guennadi Liakhovetski @ 2011-12-15 14:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1323784972-24205-13-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Laurent
On Tue, 13 Dec 2011, Laurent Pinchart wrote:
> Make sure the transmitter devices get registered before the associated
> LCDC devices.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm/mach-shmobile/board-ap4evb.c | 272 ++++++++++++++++---------------
> arch/arm/mach-shmobile/board-mackerel.c | 66 ++++----
> 2 files changed, 176 insertions(+), 162 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
> index dca4860..e0a6b3d 100644
> --- a/arch/arm/mach-shmobile/board-ap4evb.c
> +++ b/arch/arm/mach-shmobile/board-ap4evb.c
> @@ -445,82 +445,6 @@ static struct platform_device usb1_host_device = {
> .resource = usb1_host_resources,
> };
>
> -static const struct fb_videomode ap4evb_lcdc_modes[] = {
> - {
> -#ifdef CONFIG_AP4EVB_QHD
> - .name = "R63302(QHD)",
> - .xres = 544,
> - .yres = 961,
> - .left_margin = 72,
> - .right_margin = 600,
> - .hsync_len = 16,
> - .upper_margin = 8,
> - .lower_margin = 8,
> - .vsync_len = 2,
> - .sync = FB_SYNC_VERT_HIGH_ACT | FB_SYNC_HOR_HIGH_ACT,
> -#else
> - .name = "WVGA Panel",
> - .xres = 800,
> - .yres = 480,
> - .left_margin = 220,
> - .right_margin = 110,
> - .hsync_len = 70,
> - .upper_margin = 20,
> - .lower_margin = 5,
> - .vsync_len = 5,
> - .sync = 0,
> -#endif
> - },
> -};
> -static struct sh_mobile_meram_cfg lcd_meram_cfg = {
> - .icb[0] = {
> - .marker_icb = 28,
> - .cache_icb = 24,
> - .meram_offset = 0x0,
> - .meram_size = 0x40,
> - },
> - .icb[1] = {
> - .marker_icb = 29,
> - .cache_icb = 25,
> - .meram_offset = 0x40,
> - .meram_size = 0x40,
> - },
> -};
> -
> -static struct sh_mobile_lcdc_info lcdc_info = {
> - .meram_dev = &meram_info,
> - .ch[0] = {
> - .chan = LCDC_CHAN_MAINLCD,
> - .fourcc = V4L2_PIX_FMT_RGB565,
> - .lcd_cfg = ap4evb_lcdc_modes,
> - .num_cfg = ARRAY_SIZE(ap4evb_lcdc_modes),
> - .meram_cfg = &lcd_meram_cfg,
> - }
> -};
> -
> -static struct resource lcdc_resources[] = {
> - [0] = {
> - .name = "LCDC",
> - .start = 0xfe940000, /* P4-only space */
> - .end = 0xfe943fff,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - .start = intcs_evt2irq(0x580),
> - .flags = IORESOURCE_IRQ,
> - },
> -};
> -
> -static struct platform_device lcdc_device = {
> - .name = "sh_mobile_lcdc_fb",
> - .num_resources = ARRAY_SIZE(lcdc_resources),
> - .resource = lcdc_resources,
> - .dev = {
> - .platform_data = &lcdc_info,
> - .coherent_dma_mask = ~0,
> - },
> -};
> -
> /*
> * QHD display
> */
> @@ -601,6 +525,8 @@ static struct resource mipidsi0_resources[] = {
> },
> };
>
> +static struct sh_mobile_lcdc_info lcdc_info;
> +
> static struct sh_mipi_dsi_info mipidsi0_info = {
> .data_format = MIPI_RGB888,
> .lcd_chan = &lcdc_info.ch[0],
> @@ -627,6 +553,86 @@ static struct platform_device *qhd_devices[] __initdata = {
> };
> #endif /* CONFIG_AP4EVB_QHD */
>
> +/* LCDC0 */
> +static const struct fb_videomode ap4evb_lcdc_modes[] = {
Hm, I must be missing something. I thought you were moving all the structs
around to make them available for reference _without_ forward
declarations. But you _do_ end up using a forward declaration anyway. Here
and for HDMI below too. So, what's the point? Why not just forward declare
that one struct, that's needed and leave the rest where it currently is
in the file?
> + {
> +#ifdef CONFIG_AP4EVB_QHD
> + .name = "R63302(QHD)",
> + .xres = 544,
> + .yres = 961,
> + .left_margin = 72,
> + .right_margin = 600,
> + .hsync_len = 16,
> + .upper_margin = 8,
> + .lower_margin = 8,
> + .vsync_len = 2,
> + .sync = FB_SYNC_VERT_HIGH_ACT | FB_SYNC_HOR_HIGH_ACT,
> +#else
> + .name = "WVGA Panel",
> + .xres = 800,
> + .yres = 480,
> + .left_margin = 220,
> + .right_margin = 110,
> + .hsync_len = 70,
> + .upper_margin = 20,
> + .lower_margin = 5,
> + .vsync_len = 5,
> + .sync = 0,
> +#endif
> + },
> +};
> +static struct sh_mobile_meram_cfg lcd_meram_cfg = {
> + .icb[0] = {
> + .marker_icb = 28,
> + .cache_icb = 24,
> + .meram_offset = 0x0,
> + .meram_size = 0x40,
> + },
> + .icb[1] = {
> + .marker_icb = 29,
> + .cache_icb = 25,
> + .meram_offset = 0x40,
> + .meram_size = 0x40,
> + },
> +};
> +
> +static struct sh_mobile_lcdc_info lcdc_info = {
> + .meram_dev = &meram_info,
> + .ch[0] = {
> + .chan = LCDC_CHAN_MAINLCD,
> + .fourcc = V4L2_PIX_FMT_RGB565,
> + .lcd_cfg = ap4evb_lcdc_modes,
> + .num_cfg = ARRAY_SIZE(ap4evb_lcdc_modes),
> + .meram_cfg = &lcd_meram_cfg,
> +#ifdef CONFIG_AP4EVB_QHD
> + .tx_dev = &mipidsi0_device,
> +#endif
> + }
> +};
> +
> +static struct resource lcdc_resources[] = {
> + [0] = {
> + .name = "LCDC",
> + .start = 0xfe940000, /* P4-only space */
> + .end = 0xfe943fff,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> + .start = intcs_evt2irq(0x580),
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct platform_device lcdc_device = {
> + .name = "sh_mobile_lcdc_fb",
> + .num_resources = ARRAY_SIZE(lcdc_resources),
> + .resource = lcdc_resources,
> + .dev = {
> + .platform_data = &lcdc_info,
> + .coherent_dma_mask = ~0,
> + },
> +};
> +
> /* FSI */
> #define IRQ_FSI evt2irq(0x1840)
> static int __fsi_set_rate(struct clk *clk, long rate, int enable)
> @@ -793,6 +799,62 @@ static struct platform_device fsi_device = {
> static struct platform_device fsi_ak4643_device = {
> .name = "sh_fsi2_a_ak4643",
> };
> +
> +/* LCDC1 */
> +static long ap4evb_clk_optimize(unsigned long target, unsigned long *best_freq,
> + unsigned long *parent_freq);
> +
> +static struct sh_mobile_lcdc_info sh_mobile_lcdc1_info;
> +
> +static struct sh_mobile_hdmi_info hdmi_info = {
> + .lcd_chan = &sh_mobile_lcdc1_info.ch[0],
> + .flags = HDMI_SND_SRC_SPDIF,
> + .clk_optimize_parent = ap4evb_clk_optimize,
> +};
> +
> +static struct resource hdmi_resources[] = {
> + [0] = {
> + .name = "HDMI",
> + .start = 0xe6be0000,
> + .end = 0xe6be00ff,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> + /* There's also an HDMI interrupt on INTCS @ 0x18e0 */
> + .start = evt2irq(0x17e0),
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct platform_device hdmi_device = {
> + .name = "sh-mobile-hdmi",
> + .num_resources = ARRAY_SIZE(hdmi_resources),
> + .resource = hdmi_resources,
> + .id = -1,
> + .dev = {
> + .platform_data = &hdmi_info,
> + },
> +};
> +
> +static long ap4evb_clk_optimize(unsigned long target, unsigned long *best_freq,
> + unsigned long *parent_freq)
> +{
> + struct clk *hdmi_ick = clk_get(&hdmi_device.dev, "ick");
> + long error;
> +
> + if (IS_ERR(hdmi_ick)) {
> + int ret = PTR_ERR(hdmi_ick);
> + pr_err("Cannot get HDMI ICK: %d\n", ret);
> + return ret;
> + }
> +
> + error = clk_round_parent(hdmi_ick, target, best_freq, parent_freq, 1, 64);
> +
> + clk_put(hdmi_ick);
> +
> + return error;
> +}
> +
> static struct sh_mobile_meram_cfg hdmi_meram_cfg = {
> .icb[0] = {
> .marker_icb = 30,
> @@ -818,6 +880,7 @@ static struct sh_mobile_lcdc_info sh_mobile_lcdc1_info = {
> .clock_divider = 1,
> .flags = LCDC_FLAGS_DWPOL,
> .meram_cfg = &hdmi_meram_cfg,
> + .tx_dev = &hdmi_device,
> }
> };
>
> @@ -845,63 +908,10 @@ static struct platform_device lcdc1_device = {
> },
> };
>
> -static long ap4evb_clk_optimize(unsigned long target, unsigned long *best_freq,
> - unsigned long *parent_freq);
> -
> -
> -static struct sh_mobile_hdmi_info hdmi_info = {
> - .lcd_chan = &sh_mobile_lcdc1_info.ch[0],
> - .flags = HDMI_SND_SRC_SPDIF,
> - .clk_optimize_parent = ap4evb_clk_optimize,
> -};
> -
> -static struct resource hdmi_resources[] = {
> - [0] = {
> - .name = "HDMI",
> - .start = 0xe6be0000,
> - .end = 0xe6be00ff,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - /* There's also an HDMI interrupt on INTCS @ 0x18e0 */
> - .start = evt2irq(0x17e0),
> - .flags = IORESOURCE_IRQ,
> - },
> -};
> -
> -static struct platform_device hdmi_device = {
> - .name = "sh-mobile-hdmi",
> - .num_resources = ARRAY_SIZE(hdmi_resources),
> - .resource = hdmi_resources,
> - .id = -1,
> - .dev = {
> - .platform_data = &hdmi_info,
> - },
> -};
> -
> static struct platform_device fsi_hdmi_device = {
> .name = "sh_fsi2_b_hdmi",
> };
>
> -static long ap4evb_clk_optimize(unsigned long target, unsigned long *best_freq,
> - unsigned long *parent_freq)
> -{
> - struct clk *hdmi_ick = clk_get(&hdmi_device.dev, "ick");
> - long error;
> -
> - if (IS_ERR(hdmi_ick)) {
> - int ret = PTR_ERR(hdmi_ick);
> - pr_err("Cannot get HDMI ICK: %d\n", ret);
> - return ret;
> - }
> -
> - error = clk_round_parent(hdmi_ick, target, best_freq, parent_freq, 1, 64);
> -
> - clk_put(hdmi_ick);
> -
> - return error;
> -}
> -
> static struct gpio_led ap4evb_leds[] = {
> {
> .name = "led4",
> @@ -1036,9 +1046,9 @@ static struct platform_device *ap4evb_devices[] __initdata = {
> &fsi_ak4643_device,
> &fsi_hdmi_device,
> &sh_mmcif_device,
> - &lcdc1_device,
> - &lcdc_device,
> &hdmi_device,
> + &lcdc_device,
> + &lcdc1_device,
> &ceu_device,
> &ap4evb_camera,
> &meram_device,
> diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
> index 4ed0138..ccdd9fc 100644
> --- a/arch/arm/mach-shmobile/board-mackerel.c
> +++ b/arch/arm/mach-shmobile/board-mackerel.c
> @@ -431,6 +431,38 @@ static struct platform_device lcdc_device = {
> },
> };
>
> +/* HDMI */
> +static struct sh_mobile_lcdc_info hdmi_lcdc_info;
> +
> +static struct sh_mobile_hdmi_info hdmi_info = {
> + .lcd_chan = &hdmi_lcdc_info.ch[0],
> + .flags = HDMI_SND_SRC_SPDIF,
> +};
> +
> +static struct resource hdmi_resources[] = {
> + [0] = {
> + .name = "HDMI",
> + .start = 0xe6be0000,
> + .end = 0xe6be00ff,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> + /* There's also an HDMI interrupt on INTCS @ 0x18e0 */
> + .start = evt2irq(0x17e0),
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct platform_device hdmi_device = {
> + .name = "sh-mobile-hdmi",
> + .num_resources = ARRAY_SIZE(hdmi_resources),
> + .resource = hdmi_resources,
> + .id = -1,
> + .dev = {
> + .platform_data = &hdmi_info,
> + },
> +};
> +
> static struct sh_mobile_meram_cfg hdmi_meram_cfg = {
> .icb[0] = {
> .marker_icb = 30,
> @@ -445,7 +477,7 @@ static struct sh_mobile_meram_cfg hdmi_meram_cfg = {
> .meram_size = 0x100,
> },
> };
> -/* HDMI */
> +
> static struct sh_mobile_lcdc_info hdmi_lcdc_info = {
> .meram_dev = &mackerel_meram_info,
> .clock_source = LCDC_CLK_EXTERNAL,
> @@ -456,6 +488,7 @@ static struct sh_mobile_lcdc_info hdmi_lcdc_info = {
> .clock_divider = 1,
> .flags = LCDC_FLAGS_DWPOL,
> .meram_cfg = &hdmi_meram_cfg,
> + .tx_dev = &hdmi_device,
> }
> };
>
> @@ -483,35 +516,6 @@ static struct platform_device hdmi_lcdc_device = {
> },
> };
>
> -static struct sh_mobile_hdmi_info hdmi_info = {
> - .lcd_chan = &hdmi_lcdc_info.ch[0],
> - .flags = HDMI_SND_SRC_SPDIF,
> -};
> -
> -static struct resource hdmi_resources[] = {
> - [0] = {
> - .name = "HDMI",
> - .start = 0xe6be0000,
> - .end = 0xe6be00ff,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - /* There's also an HDMI interrupt on INTCS @ 0x18e0 */
> - .start = evt2irq(0x17e0),
> - .flags = IORESOURCE_IRQ,
> - },
> -};
> -
> -static struct platform_device hdmi_device = {
> - .name = "sh-mobile-hdmi",
> - .num_resources = ARRAY_SIZE(hdmi_resources),
> - .resource = hdmi_resources,
> - .id = -1,
> - .dev = {
> - .platform_data = &hdmi_info,
> - },
> -};
> -
> static struct platform_device fsi_hdmi_device = {
> .name = "sh_fsi2_b_hdmi",
> };
> @@ -1313,8 +1317,8 @@ static struct platform_device *mackerel_devices[] __initdata = {
> &sh_mmcif_device,
> &ceu_device,
> &mackerel_camera,
> - &hdmi_lcdc_device,
> &hdmi_device,
> + &hdmi_lcdc_device,
> &meram_device,
> };
>
Sorry, could you elaborate, why this is needed? If this is really
important, then I'd prefer to test this before committing. If OTOH this is
unimportant, and my assumption, that normally it's the platform driver
registration order, that's important, not device registration order, is
correct, then you don't have to swap the order?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 48/57] fbdev: sh_mobile_meram: Allocate ICBs automatically
From: Laurent Pinchart @ 2011-12-15 11:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1323784972-24205-49-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Damian,
On Thursday 15 December 2011 03:58:12 Damian Hobson-Garcia wrote:
> Hi Laurent,
>
> On 2011/12/13 23:02, Laurent Pinchart wrote:
> > Instead of manually specifying the ICBs to use in platform data,
> > allocate them automatically at runtime.
> >
> > The MERAM registration function now returns a pointer to an opaque MERAM
> > object, which is passed to the update and unregistration functions.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
>
> So one concern that I have about this is in regards to sharing ICBs with
> user-space drivers. Since there are user space drivers (via UIO) for blocks
> like the VEU, that may want to have access to MERAM, we need a way to
> communicate which ICBs are free to user space. With the hard-coded platform
> data we could easily assume that kernel drivers would use, for example, the
> upper 16 ICBs and so user-space drivers were free to use the lower 16.
You're right, I forgot about that :-/
> One simple temporary workaround might be to provide a range of useable ICBs
> in the platform data. The MERAM memory allocation range can always easily be
> tweaked by using the meram_resources structure.
That sounds good to me. I'll implement that.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 47/57] fbdev: sh_mobile_meram: Use genalloc to manage MERAM allocation
From: Laurent Pinchart @ 2011-12-15 11:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1323784972-24205-48-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Damian,
Thanks for the review.
On Thursday 15 December 2011 03:43:06 Damian Hobson-Garcia wrote:
> On 2011/12/13 23:02, Laurent Pinchart wrote:
> > @@ -195,43 +196,40 @@ static int meram_check_overlap(struct
> > sh_mobile_meram_priv *priv,
> >
> > test_bit(new->cache_icb, &priv->used_icb))
> >
> > return 1;
> >
> > - for (i = 0; i < MERAM_ICB_NUM; i++) {
> > - if (!test_bit(i, &priv->used_icb))
> > - continue;
> > -
> > - used_start = MERAM_CACHE_START(priv->icbs[i].region);
> > - used_end = MERAM_CACHE_END(priv->icbs[i].region);
> > - meram_start = new->meram_offset;
> > - meram_end = new->meram_offset + new->meram_size;
> > -
> > - if ((meram_start >= used_start && meram_start < used_end) ||
> > - (meram_end > used_start && meram_end < used_end))
> > - return 1;
> > - }
> > -
> >
> > return 0;
> >
> > }
> >
> > -/* Mark the specified ICB as used. */
> > -static void meram_mark(struct sh_mobile_meram_priv *priv,
> > +/* Allocate memory for the ICBs and mark them as used. */
> > +static int meram_alloc(struct sh_mobile_meram_priv *priv,
> >
> > const struct sh_mobile_meram_icb_cfg *new,
> > int pixelformat)
> >
> > {
> >
> > + struct sh_mobile_meram_icb *marker = &priv->icbs[new->marker_icb];
> > + unsigned long mem;
> > +
> > + mem = gen_pool_alloc(priv->pool, new->meram_size * 1024);
> > + if (mem = 0)
> > + return -ENOMEM;
> > +
> >
> > __set_bit(new->marker_icb, &priv->used_icb);
> > __set_bit(new->cache_icb, &priv->used_icb);
> >
> > - priv->icbs[new->marker_icb].region = MERAM_CACHE_SET(new->meram_offset,
> > - new->meram_size);
> > - priv->icbs[new->cache_icb].region = MERAM_CACHE_SET(new->meram_offset,
> > - new->meram_size);
> > - priv->icbs[new->marker_icb].current_reg = 1;
> > - priv->icbs[new->marker_icb].pixelformat = pixelformat;
> > + marker->offset = mem - priv->meram;
>
> I might have missed this somewhere, but it doesn't look like priv->meram
> is assigned anywhere.
Oops. That got lost in a rebase operation :-/ I'll fix it.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 48/57] fbdev: sh_mobile_meram: Allocate ICBs automatically
From: Damian Hobson-Garcia @ 2011-12-15 2:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1323784972-24205-49-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 2011/12/13 23:02, Laurent Pinchart wrote:
> Instead of manually specifying the ICBs to use in platform data,
> allocate them automatically at runtime.
>
> The MERAM registration function now returns a pointer to an opaque MERAM
> object, which is passed to the update and unregistration functions.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
So one concern that I have about this is in regards to sharing ICBs with
user-space drivers. Since there are user space drivers (via UIO) for
blocks like the VEU, that may want to have access to MERAM, we need
a way to communicate which ICBs are free to user space. With the
hard-coded platform data we could easily assume that kernel drivers
would use, for example, the upper 16 ICBs and so user-space drivers were
free to use the lower 16.
One simple temporary workaround might be to provide a range of useable
ICBs in the platform data. The MERAM memory allocation range can always
easily be tweaked by using the meram_resources structure.
Thanks,
Damian
^ permalink raw reply
* Re: [PATCH 47/57] fbdev: sh_mobile_meram: Use genalloc to manage
From: Damian Hobson-Garcia @ 2011-12-15 2:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1323784972-24205-48-git-send-email-laurent.pinchart@ideasonboard.com>
On 2011/12/13 23:02, Laurent Pinchart wrote:
> @@ -195,43 +196,40 @@ static int meram_check_overlap(struct sh_mobile_meram_priv *priv,
> test_bit(new->cache_icb, &priv->used_icb))
> return 1;
>
> - for (i = 0; i < MERAM_ICB_NUM; i++) {
> - if (!test_bit(i, &priv->used_icb))
> - continue;
> -
> - used_start = MERAM_CACHE_START(priv->icbs[i].region);
> - used_end = MERAM_CACHE_END(priv->icbs[i].region);
> - meram_start = new->meram_offset;
> - meram_end = new->meram_offset + new->meram_size;
> -
> - if ((meram_start >= used_start && meram_start < used_end) ||
> - (meram_end > used_start && meram_end < used_end))
> - return 1;
> - }
> -
> return 0;
> }
>
> -/* Mark the specified ICB as used. */
> -static void meram_mark(struct sh_mobile_meram_priv *priv,
> +/* Allocate memory for the ICBs and mark them as used. */
> +static int meram_alloc(struct sh_mobile_meram_priv *priv,
> const struct sh_mobile_meram_icb_cfg *new,
> int pixelformat)
> {
> + struct sh_mobile_meram_icb *marker = &priv->icbs[new->marker_icb];
> + unsigned long mem;
> +
> + mem = gen_pool_alloc(priv->pool, new->meram_size * 1024);
> + if (mem = 0)
> + return -ENOMEM;
> +
> __set_bit(new->marker_icb, &priv->used_icb);
> __set_bit(new->cache_icb, &priv->used_icb);
>
> - priv->icbs[new->marker_icb].region = MERAM_CACHE_SET(new->meram_offset,
> - new->meram_size);
> - priv->icbs[new->cache_icb].region = MERAM_CACHE_SET(new->meram_offset,
> - new->meram_size);
> - priv->icbs[new->marker_icb].current_reg = 1;
> - priv->icbs[new->marker_icb].pixelformat = pixelformat;
> + marker->offset = mem - priv->meram;
I might have missed this somewhere, but it doesn't look like priv->meram
is assigned anywhere.
Damian
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ permalink raw reply
* Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on
From: Richard Zhao @ 2011-12-15 1:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111215014619.GB3259@S2101-09.ap.freescale.net>
On Thu, Dec 15, 2011 at 09:46:20AM +0800, Shawn Guo wrote:
> On Thu, Dec 15, 2011 at 09:02:20AM +0800, Richard Zhao wrote:
> > On Wed, Dec 14, 2011 at 03:01:19PM +0000, Dave Martin wrote:
> > > On Wed, Dec 14, 2011 at 10:05:04PM +0800, Richard Zhao wrote:
> > > > On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote:
> > > > > Hi Dave,
> > > > >
> > > > > Sorry for that I did not look into previous post to point it out.
> > > > >
> > > > > On Wed, Dec 14, 2011 at 11:39:41AM +0000, Dave Martin wrote:
> > > > > > The i.MX6 Quad SoC will work without the l2x0 L2 cache controller
> > > > > > support built into the kernel, so this patch removes the dependency
> > > > > > on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead.
> > > > > >
> > > > > > This makes the l2x0 support optional, so that it can be turned off
> > > > > > when desired for debugging purposes etc.
> > > > > >
> > > > > > Thanks to Shawn Guo for this suggestion. [1]
> > > > > >
> > > > > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > > > > >
> > > > > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
> > > > > > ---
> > > > > > arch/arm/mach-imx/Kconfig | 2 +-
> > > > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > > > > > index 29a3d61..1fb93f2 100644
> > > > > > --- a/arch/arm/mach-imx/Kconfig
> > > > > > +++ b/arch/arm/mach-imx/Kconfig
> > > > > > @@ -609,13 +609,13 @@ comment "i.MX6 family:"
> > > > > > config SOC_IMX6Q
> > > > > > bool "i.MX6 Quad support"
> > > > > > select ARM_GIC
> > > > > > - select CACHE_L2X0
> > > > > > select CPU_V7
> > > > > > select HAVE_ARM_SCU
> > > > > > select HAVE_IMX_GPC
> > > > > > select HAVE_IMX_MMDC
> > > > > > select HAVE_IMX_SRC
> > > > > > select HAVE_SMP
> > > > > > + select MIGHT_HAVE_CACHE_L2X0
> > > > >
> > > > > The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected.
> > > > > Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in
> > > > > patch #1, this line seems redundant here.
> > > > Would it be better keep this one and remove patch #1 one? imx5 doesn't have
> > > > l2x0.
> > >
> > > Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select
> > > it only from SOC_IMX6Q?
> > Yes, I think it's more precise. Shawn?
> >
> No.
>
> * imx5 hardware does have L2, and it's just not set up in the kernel
> (I do not know why).
> * Currently, ARCH_IMX_V6_V7 only covers imx3 and imx6, and both are
> calling l2x0 init function to set L2 up.
> * When we merge mach-mx5 into mach-imx to have ARCH_IMX_V6_V7 cover
> imx3, imx5 and imx6, there is no reason for us to not set L2 up for
> imx5 too.
>
> So MIGHT_HAVE_CACHE_L2X0 really should be selected by ARCH_IMX_V6_V7.
mx5/cortex-a8 don't use L2X0. But that's ok. MIGHT_HAVE_CACHE_L2X0 is just a hint.
Please Shawn's suggestion.
Thanks
Richard
>
> --
> Regards,
> Shawn
^ permalink raw reply
* Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on
From: Shawn Guo @ 2011-12-15 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111215010219.GP28768@b20223-02.ap.freescale.net>
On Thu, Dec 15, 2011 at 09:02:20AM +0800, Richard Zhao wrote:
> On Wed, Dec 14, 2011 at 03:01:19PM +0000, Dave Martin wrote:
> > On Wed, Dec 14, 2011 at 10:05:04PM +0800, Richard Zhao wrote:
> > > On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote:
> > > > Hi Dave,
> > > >
> > > > Sorry for that I did not look into previous post to point it out.
> > > >
> > > > On Wed, Dec 14, 2011 at 11:39:41AM +0000, Dave Martin wrote:
> > > > > The i.MX6 Quad SoC will work without the l2x0 L2 cache controller
> > > > > support built into the kernel, so this patch removes the dependency
> > > > > on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead.
> > > > >
> > > > > This makes the l2x0 support optional, so that it can be turned off
> > > > > when desired for debugging purposes etc.
> > > > >
> > > > > Thanks to Shawn Guo for this suggestion. [1]
> > > > >
> > > > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > > > >
> > > > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
> > > > > ---
> > > > > arch/arm/mach-imx/Kconfig | 2 +-
> > > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > > > > index 29a3d61..1fb93f2 100644
> > > > > --- a/arch/arm/mach-imx/Kconfig
> > > > > +++ b/arch/arm/mach-imx/Kconfig
> > > > > @@ -609,13 +609,13 @@ comment "i.MX6 family:"
> > > > > config SOC_IMX6Q
> > > > > bool "i.MX6 Quad support"
> > > > > select ARM_GIC
> > > > > - select CACHE_L2X0
> > > > > select CPU_V7
> > > > > select HAVE_ARM_SCU
> > > > > select HAVE_IMX_GPC
> > > > > select HAVE_IMX_MMDC
> > > > > select HAVE_IMX_SRC
> > > > > select HAVE_SMP
> > > > > + select MIGHT_HAVE_CACHE_L2X0
> > > >
> > > > The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected.
> > > > Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in
> > > > patch #1, this line seems redundant here.
> > > Would it be better keep this one and remove patch #1 one? imx5 doesn't have
> > > l2x0.
> >
> > Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select
> > it only from SOC_IMX6Q?
> Yes, I think it's more precise. Shawn?
>
No.
* imx5 hardware does have L2, and it's just not set up in the kernel
(I do not know why).
* Currently, ARCH_IMX_V6_V7 only covers imx3 and imx6, and both are
calling l2x0 init function to set L2 up.
* When we merge mach-mx5 into mach-imx to have ARCH_IMX_V6_V7 cover
imx3, imx5 and imx6, there is no reason for us to not set L2 up for
imx5 too.
So MIGHT_HAVE_CACHE_L2X0 really should be selected by ARCH_IMX_V6_V7.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on
From: Richard Zhao @ 2011-12-15 1:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111214150119.GD2568@linaro.org>
On Wed, Dec 14, 2011 at 03:01:19PM +0000, Dave Martin wrote:
> On Wed, Dec 14, 2011 at 10:05:04PM +0800, Richard Zhao wrote:
> > On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote:
> > > Hi Dave,
> > >
> > > Sorry for that I did not look into previous post to point it out.
> > >
> > > On Wed, Dec 14, 2011 at 11:39:41AM +0000, Dave Martin wrote:
> > > > The i.MX6 Quad SoC will work without the l2x0 L2 cache controller
> > > > support built into the kernel, so this patch removes the dependency
> > > > on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead.
> > > >
> > > > This makes the l2x0 support optional, so that it can be turned off
> > > > when desired for debugging purposes etc.
> > > >
> > > > Thanks to Shawn Guo for this suggestion. [1]
> > > >
> > > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > > >
> > > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
> > > > ---
> > > > arch/arm/mach-imx/Kconfig | 2 +-
> > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > > > index 29a3d61..1fb93f2 100644
> > > > --- a/arch/arm/mach-imx/Kconfig
> > > > +++ b/arch/arm/mach-imx/Kconfig
> > > > @@ -609,13 +609,13 @@ comment "i.MX6 family:"
> > > > config SOC_IMX6Q
> > > > bool "i.MX6 Quad support"
> > > > select ARM_GIC
> > > > - select CACHE_L2X0
> > > > select CPU_V7
> > > > select HAVE_ARM_SCU
> > > > select HAVE_IMX_GPC
> > > > select HAVE_IMX_MMDC
> > > > select HAVE_IMX_SRC
> > > > select HAVE_SMP
> > > > + select MIGHT_HAVE_CACHE_L2X0
> > >
> > > The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected.
> > > Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in
> > > patch #1, this line seems redundant here.
> > Would it be better keep this one and remove patch #1 one? imx5 doesn't have
> > l2x0.
>
> Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select
> it only from SOC_IMX6Q?
Yes, I think it's more precise. Shawn?
Thansk
Richard
>
> Cheers
> ---Dave
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2
From: Tony Lindgren @ 2011-12-14 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EE90EB5.9070502@gmail.com>
* Rob Herring <robherring2@gmail.com> [111214 12:30]:
>
> On 12/14/2011 12:39 PM, Tony Lindgren wrote:
> >
> > I think we should keep L2 configurable for omaps until we have some
> > way of getting the configuration dynamically or from device tree.
> >
>
> This already exists with l2x0_of_init. OMAP just needs to start using
> it. It will initialize the l2 if present in the DT and skip it if not
> present.
That's great, that will allow doing the right thing with setting
up how to enable and disable it :) Considering that, this patch
should be OK to apply:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed
From: Rafael J. Wysocki @ 2011-12-14 21:36 UTC (permalink / raw)
To: Ulf Hansson
Cc: Guennadi Liakhovetski, linux-mmc@vger.kernel.org,
linux-pm@vger.kernel.org, Chris Ball, linux-sh@vger.kernel.org
In-Reply-To: <4EE8849D.1010401@stericsson.com>
On Wednesday, December 14, 2011, Ulf Hansson wrote:
>
> >> You have a point. But I am not convinced. :-)
> >>
> >> Some host drivers already make use of autosuspend. I think this is most
> >> straightforward solution to this problem right now.
> >
> > The problem is not about _when_ to suspend (which autosuspend is about),
> > but _what_ _state_ to go when suspended. That's quite a different issue.
>
> I was kind of taking a more simple approach, I were considering
> runtime_suspend as _one_ state. Right now there is no host driver having
> different levels of runtime_suspend state, if I am correct. But ofcourse
> that could be the future.
Yes, there is, or more precisely there's going to be shortly. We have
PM domains on SH7372 and when we enable all of them to be powered off
at run time, there will be many power states for the controller which
is located in one of them. Hence the $subject patch. :-)
> Moreover, I definitely do not think that a fixed timeout of 100us is
> applicable for all use cases, this must at least be configurable.
Well, this isn't a timeout. Have you read my reply to Linus?
I agree that it should be configurable _eventually_, but no one seems to
know how to implement that configurability. Ideally, that value should
result from some user space input, possibly after a conversion by the
driver to a useful number, but we don't seem to have any agreement as to
what the interface for passing that user space input to the driver should
look like.
> >> However, we could also do pm_runtime_get_sync of the host device in
> >> claim host and vice verse in release host, thus preventing the host
> >> driver from triggering runtime_suspend|resume for every request. Though,
> >> I am not 100% sure this is really what you want either.
> >
> > No, I don't want that. I want the device to be suspended when possible,
> > but I don't want that to cause the system to go into an overly deep power
> > state as a result.
>
> Before just skipping my proposal, I think you should know some more
> background to why I suggested this:
>
> 1.
> mmc_claim_host is using mmc_host_enable, which kind of mean the same
> thing for a host driver as doing get_sync. Vice verse for mmc_release_host.
>
> 2.
> When executing mmc/sd commands/requests the host must always be claimed
> (and thus the host is always enabled). But more important some mmc/sd
> commands must be executed as a sequence, without the host being disabled
> in between the commands (since a disable might mean that the clock to
> card gets disabled). To solve this, the mmc_claim_host is used, to make
> sure the host is enabled during the complete command sequence.
>
> I happily continue this discussion, to see if someone more can break the
> idea about having get_sync in mmc_host_enable. :-)
I'll leave this one to Guennadi, if you don't mind. :-)
> >> Using PM QoS as you propose, might prevent some hosts from doing
> >> runtime_suspend|resume completely and thus those might not fulfill power
> >> consumption requirements instead.
> >
> > I'm not sure what scenario you have in mind. Care to elaborate?
>
> Well, suppose a the host drivers start considering the PM QoS
> requirement, but never can fulfill the requirement of 100us for it's
> runtime_suspend callback function...
OK, that's a valid concern. This means there should be a way for user space
to specify the constraint somehow, because it's a user space's role to define
policies.
> >> I do not think we can take this decision at this level. Is performance more
> >> important than power save, that is kind of the question.
> >
> > Yes, it is. Also, the number used here is somewhat arbitrary.
>
> For you maybe power management is less important, but I doubt everybody
> else agree to that. It is a more complex balance I believe.
You're right.
> > However, since no one except for SH7372 is now using device PM QoS, no one
> > else will be affected by this change at the moment.
>
> True, but that is not a good reason for adding more stuff to the mmc core.
Good point.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2
From: Rob Herring @ 2011-12-14 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111214183952.GG32251@atomide.com>
On 12/14/2011 12:39 PM, Tony Lindgren wrote:
> * Dave Martin <dave.martin@linaro.org> [111214 09:58]:
>> On Wed, Dec 14, 2011 at 10:14:25AM -0800, Tony Lindgren wrote:
>>> * Dave Martin <dave.martin@linaro.org> [111214 03:08]:
>>>> If running in the Normal World on a TrustZone-enabled SoC, Linux
>>>> does not have complete control over the L2 cache controller
>>>> configuration. The kernel cannot work reliably on such platforms
>>>> without the l2x0 cache support code built in.
>>>
>>> There are HS and GP omaps (High Security and General Purpose).
>>> GP omaps do have full control of the L2. Also HS omaps most likely
>>> provide control over enabling and disabling L2 depending how the
>>> secure code is implemented.
>>>
>>> BTW, the real problem is that because the secure code is implemented
>>> in various ways, we don't really have any handling for it in Linux.
>>>
>>> The SMI instruction numbers don't seem to be standardized at all,
>>> and can mean different things on different boards, even different
>>> board versions :(
>>>
>>> Sounds like devicetree is the only safe way to deal with the L2
>>> control options.
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>>
>>>> This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
>>>>
>>>> Thanks to Rob Herring for this suggestion. [1]
>>>>
>>>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>>>>
>>>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
>>>> ---
>>>> arch/arm/mach-omap2/Kconfig | 2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>>>> index bb1b670..94e568a 100644
>>>> --- a/arch/arm/mach-omap2/Kconfig
>>>> +++ b/arch/arm/mach-omap2/Kconfig
>>>> @@ -41,11 +41,11 @@ config ARCH_OMAP4
>>>> bool "TI OMAP4"
>>>> default y
>>>> depends on ARCH_OMAP2PLUS
>>>> + select CACHE_L2X0
>>>> select CPU_V7
>>>> select ARM_GIC
>>>> select HAVE_SMP
>>>> select LOCAL_TIMERS if SMP
>>>> - select MIGHT_HAVE_CACHE_L2X0
>>>> select PL310_ERRATA_588369
>>>> select PL310_ERRATA_727915
>>>> select ARM_ERRATA_720789
>>>> --
>>>> 1.7.4.1
>>>>
>>
>> To clarify, are you suggesting we retain this patch, or not?
>
> I think we should keep L2 configurable for omaps until we have some
> way of getting the configuration dynamically or from device tree.
>
This already exists with l2x0_of_init. OMAP just needs to start using
it. It will initialize the l2 if present in the DT and skip it if not
present.
Rob
>> (If we only know what l2x0 support will be needed once the dts is
>> parsed at runtime, there could be an argument for keeping the
>> select CACHE_L2X0 here -- unless we have specific kconfigs for
>> the different security variants of omap.)
>
> Well we can detect if it's an HS omap, but we may not know what
> SMI it uses for enabling and disabling L2.. That can depend on
> the board version.
>
> Is there some problem keeping MIGHT_HAVE_CACHE_L2X0? This is
> pretty important from debugging cache issues point of view.
>
> Regards,
>
> Tony
^ permalink raw reply
* Re: [PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2
From: Tony Lindgren @ 2011-12-14 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111214183030.GB9331@linaro.org>
* Dave Martin <dave.martin@linaro.org> [111214 09:58]:
> On Wed, Dec 14, 2011 at 10:14:25AM -0800, Tony Lindgren wrote:
> > * Dave Martin <dave.martin@linaro.org> [111214 03:08]:
> > > If running in the Normal World on a TrustZone-enabled SoC, Linux
> > > does not have complete control over the L2 cache controller
> > > configuration. The kernel cannot work reliably on such platforms
> > > without the l2x0 cache support code built in.
> >
> > There are HS and GP omaps (High Security and General Purpose).
> > GP omaps do have full control of the L2. Also HS omaps most likely
> > provide control over enabling and disabling L2 depending how the
> > secure code is implemented.
> >
> > BTW, the real problem is that because the secure code is implemented
> > in various ways, we don't really have any handling for it in Linux.
> >
> > The SMI instruction numbers don't seem to be standardized at all,
> > and can mean different things on different boards, even different
> > board versions :(
> >
> > Sounds like devicetree is the only safe way to deal with the L2
> > control options.
> >
> > Regards,
> >
> > Tony
> >
> >
> > > This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
> > >
> > > Thanks to Rob Herring for this suggestion. [1]
> > >
> > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > >
> > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
> > > ---
> > > arch/arm/mach-omap2/Kconfig | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> > > index bb1b670..94e568a 100644
> > > --- a/arch/arm/mach-omap2/Kconfig
> > > +++ b/arch/arm/mach-omap2/Kconfig
> > > @@ -41,11 +41,11 @@ config ARCH_OMAP4
> > > bool "TI OMAP4"
> > > default y
> > > depends on ARCH_OMAP2PLUS
> > > + select CACHE_L2X0
> > > select CPU_V7
> > > select ARM_GIC
> > > select HAVE_SMP
> > > select LOCAL_TIMERS if SMP
> > > - select MIGHT_HAVE_CACHE_L2X0
> > > select PL310_ERRATA_588369
> > > select PL310_ERRATA_727915
> > > select ARM_ERRATA_720789
> > > --
> > > 1.7.4.1
> > >
>
> To clarify, are you suggesting we retain this patch, or not?
I think we should keep L2 configurable for omaps until we have some
way of getting the configuration dynamically or from device tree.
> (If we only know what l2x0 support will be needed once the dts is
> parsed at runtime, there could be an argument for keeping the
> select CACHE_L2X0 here -- unless we have specific kconfigs for
> the different security variants of omap.)
Well we can detect if it's an HS omap, but we may not know what
SMI it uses for enabling and disabling L2.. That can depend on
the board version.
Is there some problem keeping MIGHT_HAVE_CACHE_L2X0? This is
pretty important from debugging cache issues point of view.
Regards,
Tony
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox