* [PATCH linux-next] intelfb: intelfbhw_mode_to_hw: Silence m1/m2 'may be used uninitialized' warnings
From: Tim Gardner @ 2013-03-10 17:53 UTC (permalink / raw)
To: linux-kernel
Cc: Tim Gardner, Maik Broemme, Florian Tobias Schandinat, linux-fbdev
drivers/video/intelfb/intelfbhw.c: In function 'intelfbhw_mode_to_hw':
drivers/video/intelfb/intelfbhw.c:1144:35: warning: 'm2' may be used uninitialized in this function [-Wuninitialized]
drivers/video/intelfb/intelfbhw.c:1145:13: warning: 'm1' may be used uninitialized in this function [-Wuninitialized]
gcc version 4.6.3
Cc: Maik Broemme <mbroemme@plusserver.de>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
drivers/video/intelfb/intelfbhw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/intelfb/intelfbhw.c b/drivers/video/intelfb/intelfbhw.c
index fbad61d..cb05307 100644
--- a/drivers/video/intelfb/intelfbhw.c
+++ b/drivers/video/intelfb/intelfbhw.c
@@ -935,7 +935,7 @@ static int splitp(int index, unsigned int p, unsigned int *retp1,
static int calc_pll_params(int index, int clock, u32 *retm1, u32 *retm2,
u32 *retn, u32 *retp1, u32 *retp2, u32 *retclock)
{
- u32 m1, m2, n, p1, p2, n1, testm;
+ u32 m1 = 0, m2 = 0, n, p1, p2, n1, testm;
u32 f_vco, p, p_best = 0, m, f_out = 0;
u32 err_max, err_target, err_best = 10000000;
u32 n_best = 0, m_best = 0, f_best, f_err;
--
1.7.9.5
^ permalink raw reply related
* [PATCH linux-next] mfd: max8925: max8925_backlight_probe: Silence 'statement with no effect' warning
From: Tim Gardner @ 2013-03-10 18:12 UTC (permalink / raw)
To: linux-kernel
Cc: Tim Gardner, Richard Purdie, Florian Tobias Schandinat,
linux-fbdev
Commit 47ec340cb8e232671e7c4a4689ff32c3bdf329da 'mfd: max8925: Support dt for backlight'
caused a gcc warning if CONFIG_OF is not defined:
drivers/video/backlight/max8925_bl.c: In function 'max8925_backlight_probe':
drivers/video/backlight/max8925_bl.c:177:3: warning: statement with no effect [-Wunused-value]
gcc version 4.6.3
Convert max8925_backlight_dt_init() to an 'inline void' since it is only
called from one place where the return code is ignored. Protect the
guts of the function with '#ifdef CONFIG_OF'.
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
drivers/video/backlight/max8925_bl.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/max8925_bl.c b/drivers/video/backlight/max8925_bl.c
index 5ca11b0..199f887 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -101,10 +101,10 @@ static const struct backlight_ops max8925_backlight_ops = {
.get_brightness = max8925_backlight_get_brightness,
};
-#ifdef CONFIG_OF
-static int max8925_backlight_dt_init(struct platform_device *pdev,
+static inline void max8925_backlight_dt_init(struct platform_device *pdev,
struct max8925_backlight_pdata *pdata)
{
+#ifdef CONFIG_OF
struct device_node *nproot = pdev->dev.parent->of_node, *np;
int dual_string;
@@ -118,11 +118,8 @@ static int max8925_backlight_dt_init(struct platform_device *pdev,
of_property_read_u32(np, "maxim,max8925-dual-string", &dual_string);
pdata->dual_string = dual_string;
- return 0;
-}
-#else
-#define max8925_backlight_dt_init(x, y) (-1)
#endif
+}
static int max8925_backlight_probe(struct platform_device *pdev)
{
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH 2/3] video: backlight: lp855x_bl: fix compiler warning in lp855x_probe
From: Kim, Milo @ 2013-03-10 23:04 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1362771069-16345-2-git-send-email-devendra.aaru@gmail.com>
PiB3aGlsZSBkb2luZyB3aXRoIG1ha2UgVz0xIGdjYyAoZ2NjIChHQ0MpIDQuNy4yIDIwMTIxMTA5
IChSZWQgSGF0IDQuNy4yLQ0KPiA4KSkNCj4gDQo+IGZvdW5kDQo+IA0KPiBkcml2ZXJzL3ZpZGVv
L2JhY2tsaWdodC9scDg1NXhfYmwuYzogSW4gZnVuY3Rpb24g4oCYbHA4NTV4X3Byb2Jl4oCZOg0K
PiBkcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9scDg1NXhfYmwuYzozNDI6MzU6IHdhcm5pbmc6IHZh
cmlhYmxlIOKAmG1vZGXigJkNCj4gc2V0IGJ1dCBub3QgdXNlZCBbLVd1bnVzZWQtYnV0LXNldC12
YXJpYWJsZV0NCj4gDQo+IGZpeGVkIGJ5IHJlbW92aW5nIGl0IGFzIHNpbmNlIGl0cyBub3QgdXNl
ZCBhbnl3aGVyZQ0KDQpBY2tlZC1ieTogTWlsbyBLaW0gPG1pbG8ua2ltQHRpLmNvbT4NCg0K
^ permalink raw reply
* Re: [PATCH 1/3] video: backlight: adp5520: fix compiler warning in adp5520_show
From: Jingoo Han @ 2013-03-11 0:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1362771069-16345-1-git-send-email-devendra.aaru@gmail.com>
On Saturday, March 09, 2013 4:31 AM, Devendra Naga wrote:
>
> while compiling with make W=1 (gcc gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8))
>
> found the following warning
>
> drivers/video/backlight/adp5520_bl.c: In function ‘adp5520_show’:
> drivers/video/backlight/adp5520_bl.c:146:6: warning: variable ‘error’ set but not used [-Wunused-but-
> set-variable]
>
> fixed by removing the variable
>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Michael Hennerich <michael.hennerich@analog.com>
> Cc: Richard Purdie <rpurdie@rpsys.net>
>
> Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
> ---
> drivers/video/backlight/adp5520_bl.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/adp5520_bl.c b/drivers/video/backlight/adp5520_bl.c
> index a1e41d4..9f8b20b 100644
> --- a/drivers/video/backlight/adp5520_bl.c
> +++ b/drivers/video/backlight/adp5520_bl.c
> @@ -143,11 +143,10 @@ static int adp5520_bl_setup(struct backlight_device *bl)
> static ssize_t adp5520_show(struct device *dev, char *buf, int reg)
> {
> struct adp5520_bl *data = dev_get_drvdata(dev);
> - int error;
> uint8_t reg_val;
>
> mutex_lock(&data->lock);
> - error = adp5520_read(data->master, reg, ®_val);
> + adp5520_read(data->master, reg, ®_val);
> mutex_unlock(&data->lock);
Hi Devendra Naga,
I also agree with Andrew Morton's opinion.
It would be better to check return value from I2C read/write functions.
Best regards,
Jingoo Han
>
> return sprintf(buf, "%u\n", reg_val);
> --
> 1.8.1.2
^ permalink raw reply
* Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
From: Archit Taneja @ 2013-03-11 5:47 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1362743515-10152-11-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
> The DISPC channel used for each output is currently passed in panel
> platform data from the board files.
>
> To simplify this, and to make the panel drivers less dependent on OMAP,
> this patch changes omapdss to resolve the channel independently. The
> channel is resolved based on the OMAP version and, in case of DSI, the
> DSI module id.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dpi.c | 37 ++++++++++++++++++++++++++-----
> drivers/video/omap2/dss/dsi.c | 48 ++++++++++++++++++++++++++++++++++++++++
> drivers/video/omap2/dss/rfbi.c | 2 ++
> drivers/video/omap2/dss/sdi.c | 2 ++
> 4 files changed, 84 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index e282456..3261644 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct platform_device *dsidev)
> return 0;
> }
>
> +/*
> + * Return a hardcoded channel for the DPI output. This should work for
> + * current use cases, but this can be later expanded to either resolve
> + * the channel in some more dynamic manner, or get the channel as a user
> + * parameter.
> + */
> +static enum omap_channel dpi_get_channel(void)
> +{
> + switch (omapdss_get_version()) {
> + case OMAPDSS_VER_OMAP24xx:
> + case OMAPDSS_VER_OMAP34xx_ES1:
> + case OMAPDSS_VER_OMAP34xx_ES3:
> + case OMAPDSS_VER_OMAP3630:
> + case OMAPDSS_VER_AM35xx:
> + return OMAP_DSS_CHANNEL_LCD;
> +
> + case OMAPDSS_VER_OMAP4430_ES1:
> + case OMAPDSS_VER_OMAP4430_ES2:
> + case OMAPDSS_VER_OMAP4:
> + return OMAP_DSS_CHANNEL_LCD2;
> +
> + case OMAPDSS_VER_OMAP5:
> + return OMAP_DSS_CHANNEL_LCD2;
> +
> + default:
> + DSSWARN("unsupported DSS version\n");
> + return OMAP_DSS_CHANNEL_LCD;
> + }
> +}
> +
> static int __init dpi_init_display(struct omap_dss_device *dssdev)
> {
> struct platform_device *dsidev;
>
> DSSDBG("init_display\n");
>
> + dssdev->channel = dpi_get_channel();
In patch 14 of the series, we remove these dssdev->channel assignments.
I don't see the point of adding them in this patch in the first place.
The dssdev->channel assignments will not be modified in this series, so
we don't need to worry about a kernel crash or something after this patch.
I feel this patch should only add the dpi_get_channel and
dsi_get_channel funcs.
> +
> if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
> dpi.vdds_dsi_reg = NULL) {
> struct regulator *vdds_dsi;
> @@ -416,11 +448,6 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
> dpi.vdds_dsi_reg = vdds_dsi;
> }
>
> - /*
> - * XXX We shouldn't need dssdev->channel for this. The dsi pll clock
> - * source for DPI is SoC integration detail, not something that should
> - * be configured in the dssdev
> - */
> dsidev = dpi_get_dsidev(dssdev->channel);
>
> if (dsidev && dpi_verify_dsi_pll(dsidev)) {
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 1a6ad6f..c39ca86 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -4946,6 +4946,52 @@ void omapdss_dsi_set_videomode_timings(struct omap_dss_device *dssdev,
> }
> EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
>
> +/*
> + * Return a hardcoded channel for the DSI output. This should work for
> + * current use cases, but this can be later expanded to either resolve
> + * the channel in some more dynamic manner, or get the channel as a user
> + * parameter.
> + */
> +static enum omap_channel dsi_get_channel(int module_id)
> +{
> + switch (omapdss_get_version()) {
> + case OMAPDSS_VER_OMAP24xx:
We should remove the above case so that we hit the default case and get
a warning about omap2 not having DSI.
> + case OMAPDSS_VER_OMAP34xx_ES1:
> + case OMAPDSS_VER_OMAP34xx_ES3:
> + case OMAPDSS_VER_OMAP3630:
> + case OMAPDSS_VER_AM35xx:
<snip>
Archit
^ permalink raw reply
* Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
From: Archit Taneja @ 2013-03-11 5:54 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1362743515-10152-11-git-send-email-tomi.valkeinen@ti.com>
On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
> The DISPC channel used for each output is currently passed in panel
> platform data from the board files.
>
> To simplify this, and to make the panel drivers less dependent on OMAP,
> this patch changes omapdss to resolve the channel independently. The
> channel is resolved based on the OMAP version and, in case of DSI, the
> DSI module id.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dpi.c | 37 ++++++++++++++++++++++++++-----
> drivers/video/omap2/dss/dsi.c | 48 ++++++++++++++++++++++++++++++++++++++++
> drivers/video/omap2/dss/rfbi.c | 2 ++
> drivers/video/omap2/dss/sdi.c | 2 ++
> 4 files changed, 84 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index e282456..3261644 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct platform_device *dsidev)
> return 0;
> }
>
> +/*
> + * Return a hardcoded channel for the DPI output. This should work for
> + * current use cases, but this can be later expanded to either resolve
> + * the channel in some more dynamic manner, or get the channel as a user
> + * parameter.
> + */
> +static enum omap_channel dpi_get_channel(void)
> +{
> + switch (omapdss_get_version()) {
> + case OMAPDSS_VER_OMAP24xx:
> + case OMAPDSS_VER_OMAP34xx_ES1:
> + case OMAPDSS_VER_OMAP34xx_ES3:
> + case OMAPDSS_VER_OMAP3630:
> + case OMAPDSS_VER_AM35xx:
> + return OMAP_DSS_CHANNEL_LCD;
> +
> + case OMAPDSS_VER_OMAP4430_ES1:
> + case OMAPDSS_VER_OMAP4430_ES2:
> + case OMAPDSS_VER_OMAP4:
> + return OMAP_DSS_CHANNEL_LCD2;
> +
> + case OMAPDSS_VER_OMAP5:
> + return OMAP_DSS_CHANNEL_LCD2;
> +
> + default:
> + DSSWARN("unsupported DSS version\n");
> + return OMAP_DSS_CHANNEL_LCD;
> + }
> +}
I had another comment for this patch. On OMAP5, it makes sense for us to
not use LCD2 as the recommended channel. LCD2_CLK's only source is
DSS_CLK from PRCM. So it's not a very flexible channel to use. We could
use LCD3 (at the cost of not using DSI2).
We also need to fix dpi_get_dsidev() for OMAP5. Currently, it assumes
that LCD2_CLK can be sourced from DSI2 PLL, we need to ensure DPI has a
dsidev only if it's LCD1 or LCD3.
Archit
> +
> static int __init dpi_init_display(struct omap_dss_device *dssdev)
> {
> struct platform_device *dsidev;
>
> DSSDBG("init_display\n");
>
> + dssdev->channel = dpi_get_channel();
> +
> if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
> dpi.vdds_dsi_reg = NULL) {
> struct regulator *vdds_dsi;
> @@ -416,11 +448,6 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
> dpi.vdds_dsi_reg = vdds_dsi;
> }
>
> - /*
> - * XXX We shouldn't need dssdev->channel for this. The dsi pll clock
> - * source for DPI is SoC integration detail, not something that should
> - * be configured in the dssdev
> - */
> dsidev = dpi_get_dsidev(dssdev->channel);
>
> if (dsidev && dpi_verify_dsi_pll(dsidev)) {
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 1a6ad6f..c39ca86 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -4946,6 +4946,52 @@ void omapdss_dsi_set_videomode_timings(struct omap_dss_device *dssdev,
> }
> EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
>
> +/*
> + * Return a hardcoded channel for the DSI output. This should work for
> + * current use cases, but this can be later expanded to either resolve
> + * the channel in some more dynamic manner, or get the channel as a user
> + * parameter.
> + */
> +static enum omap_channel dsi_get_channel(int module_id)
> +{
> + switch (omapdss_get_version()) {
> + case OMAPDSS_VER_OMAP24xx:
> + case OMAPDSS_VER_OMAP34xx_ES1:
> + case OMAPDSS_VER_OMAP34xx_ES3:
> + case OMAPDSS_VER_OMAP3630:
> + case OMAPDSS_VER_AM35xx:
> + return OMAP_DSS_CHANNEL_LCD;
> +
> + case OMAPDSS_VER_OMAP4430_ES1:
> + case OMAPDSS_VER_OMAP4430_ES2:
> + case OMAPDSS_VER_OMAP4:
> + switch (module_id) {
> + case 0:
> + return OMAP_DSS_CHANNEL_LCD;
> + case 1:
> + return OMAP_DSS_CHANNEL_LCD2;
> + default:
> + DSSWARN("unsupported module id\n");
> + return OMAP_DSS_CHANNEL_LCD;
> + }
> +
> + case OMAPDSS_VER_OMAP5:
> + switch (module_id) {
> + case 0:
> + return OMAP_DSS_CHANNEL_LCD;
> + case 1:
> + return OMAP_DSS_CHANNEL_LCD3;
> + default:
> + DSSWARN("unsupported module id\n");
> + return OMAP_DSS_CHANNEL_LCD;
> + }
> +
> + default:
> + DSSWARN("unsupported DSS version\n");
> + return OMAP_DSS_CHANNEL_LCD;
> + }
> +}
> +
> static int __init dsi_init_display(struct omap_dss_device *dssdev)
> {
> struct platform_device *dsidev > @@ -4954,6 +5000,8 @@ static int __init dsi_init_display(struct omap_dss_device *dssdev)
>
> DSSDBG("DSI init\n");
>
> + dssdev->channel = dsi_get_channel(dsi->module_id);
> +
> if (dsi->vdds_dsi_reg = NULL) {
> struct regulator *vdds_dsi;
>
> diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
> index a47a9e5..04c4ab6 100644
> --- a/drivers/video/omap2/dss/rfbi.c
> +++ b/drivers/video/omap2/dss/rfbi.c
> @@ -945,6 +945,8 @@ EXPORT_SYMBOL(omapdss_rfbi_display_disable);
>
> static int __init rfbi_init_display(struct omap_dss_device *dssdev)
> {
> + dssdev->channel = OMAP_DSS_CHANNEL_LCD;
> +
> rfbi.dssdev[dssdev->phy.rfbi.channel] = dssdev;
> return 0;
> }
> diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
> index 0802927..d24e971 100644
> --- a/drivers/video/omap2/dss/sdi.c
> +++ b/drivers/video/omap2/dss/sdi.c
> @@ -186,6 +186,8 @@ static int __init sdi_init_display(struct omap_dss_device *dssdev)
> {
> DSSDBG("SDI init\n");
>
> + dssdev->channel = OMAP_DSS_CHANNEL_LCD;
> +
> if (sdi.vdds_sdi_reg = NULL) {
> struct regulator *vdds_sdi;
>
>
^ permalink raw reply
* Re: [PATCH 1/3] video: backlight: adp5520: fix compiler warning in adp5520_show
From: devendra.aaru @ 2013-03-11 6:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1362771069-16345-1-git-send-email-devendra.aaru@gmail.com>
On Fri, Mar 8, 2013 at 4:01 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Fri, 8 Mar 2013 14:31:07 -0500 Devendra Naga <devendra.aaru@gmail.com> wrote:
>
>> while compiling with make W=1 (gcc gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8))
>>
>> found the following warning
>>
>> drivers/video/backlight/adp5520_bl.c: In function ___adp5520_show___:
>> drivers/video/backlight/adp5520_bl.c:146:6: warning: variable ___error___ set but not used [-Wunused-but-set-variable]
>>
>> fixed by removing the variable
>>
>> ...
>>
>> --- a/drivers/video/backlight/adp5520_bl.c
>> +++ b/drivers/video/backlight/adp5520_bl.c
>> @@ -143,11 +143,10 @@ static int adp5520_bl_setup(struct backlight_device *bl)
>> static ssize_t adp5520_show(struct device *dev, char *buf, int reg)
>> {
>> struct adp5520_bl *data = dev_get_drvdata(dev);
>> - int error;
>> uint8_t reg_val;
>>
>> mutex_lock(&data->lock);
>> - error = adp5520_read(data->master, reg, ®_val);
>> + adp5520_read(data->master, reg, ®_val);
>> mutex_unlock(&data->lock);
>>
>> return sprintf(buf, "%u\n", reg_val);
>
> We shouldn't just ignore the error; with the code as it stands, a
> adp5520_read() failure will result in the kernel displaying
> uninitialised garbage.
>
> So it would be better to propagate the adp5520_read() return value back
> to the caller if it's negative.
>
>
> (This assumes that the i2c layer returns a sane return value - if it
> does, that would make i2c pretty unique :( We could get paranoid and
> return a hard-wired -EIO, but it would be bad of us to overwrite things
> like -ENOMEM).
>
> So I'd suggest this:
>
> --- a/drivers/video/backlight/adp5520_bl.c~video-backlight-adp5520-fix-compiler-warning-in-adp5520_show
> +++ a/drivers/video/backlight/adp5520_bl.c
> @@ -143,13 +143,15 @@ static int adp5520_bl_setup(struct backl
> static ssize_t adp5520_show(struct device *dev, char *buf, int reg)
> {
> struct adp5520_bl *data = dev_get_drvdata(dev);
> - int error;
> + int ret;
> uint8_t reg_val;
>
> mutex_lock(&data->lock);
> - error = adp5520_read(data->master, reg, ®_val);
> + ret = adp5520_read(data->master, reg, ®_val);
> mutex_unlock(&data->lock);
>
> + if (ret < 0)
> + return ret;
> return sprintf(buf, "%u\n", reg_val);
> }
>
Thanks for the suggestion, i will do the same and i will send you a
patch sooner.
or you can merge your change with my Acked By too :).
> _
>
^ permalink raw reply
* Re: [PATCH 18/20] OMAPDSS: DSI: delay dispc initialization
From: Archit Taneja @ 2013-03-11 6:17 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1362743515-10152-19-git-send-email-tomi.valkeinen@ti.com>
On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
> We currently setup both DSI and DISPC related things when the DSI bus is
> enabled. There's no need for DISPC related thing at that point, though,
> but only later when the video output is enabled.
>
> To make it possible to use the DSI bus before DISPC overlay manager is
> selected, this patch moves DSI's DISPC initialization to
> dsi_enable_video_output(), from omapdss_dsi_display_enable(). We also
> move the selection of DISPC's LCD clock to dsi_enable_video_output.
>
> This way there are no DISPC dependencies until the video output is
> enabled.
This is a good patch. I hope CDF also makes sure the Display controller
and DSI bus are made more independent in this manner.
One thing which we should eventually add is to ensure that
omap_dsi_update() for command mode panels is called only after
dsi_enable_video_output() is called. I think we manage this in our panel
driver, but maybe some sort of check could help there.
<snip>
Archit
^ permalink raw reply
* Re: [PATCH 1/3] video: backlight: adp5520: fix compiler warning in adp5520_show
From: devendra.aaru @ 2013-03-11 6:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1362771069-16345-1-git-send-email-devendra.aaru@gmail.com>
On Sun, Mar 10, 2013 at 8:56 PM, Jingoo Han <jg1.han@samsung.com> wrote:
> On Saturday, March 09, 2013 4:31 AM, Devendra Naga wrote:
>>
>> while compiling with make W=1 (gcc gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8))
>>
>> found the following warning
>>
>> drivers/video/backlight/adp5520_bl.c: In function ‘adp5520_show’:
>> drivers/video/backlight/adp5520_bl.c:146:6: warning: variable ‘error’ set but not used [-Wunused-but-
>> set-variable]
>>
>> fixed by removing the variable
>>
>> Cc: Jingoo Han <jg1.han@samsung.com>
>> Cc: Michael Hennerich <michael.hennerich@analog.com>
>> Cc: Richard Purdie <rpurdie@rpsys.net>
>>
>> Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
>> ---
>> drivers/video/backlight/adp5520_bl.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/backlight/adp5520_bl.c b/drivers/video/backlight/adp5520_bl.c
>> index a1e41d4..9f8b20b 100644
>> --- a/drivers/video/backlight/adp5520_bl.c
>> +++ b/drivers/video/backlight/adp5520_bl.c
>> @@ -143,11 +143,10 @@ static int adp5520_bl_setup(struct backlight_device *bl)
>> static ssize_t adp5520_show(struct device *dev, char *buf, int reg)
>> {
>> struct adp5520_bl *data = dev_get_drvdata(dev);
>> - int error;
>> uint8_t reg_val;
>>
>> mutex_lock(&data->lock);
>> - error = adp5520_read(data->master, reg, ®_val);
>> + adp5520_read(data->master, reg, ®_val);
>> mutex_unlock(&data->lock);
>
> Hi Devendra Naga,
>
> I also agree with Andrew Morton's opinion.
> It would be better to check return value from I2C read/write functions.
>
thanks, i will do and send a patch sooner or Andrew can merge his
patch with my Acked By.
> Best regards,
> Jingoo Han
>
>>
>> return sprintf(buf, "%u\n", reg_val);
>> --
>> 1.8.1.2
>
^ permalink raw reply
* Re: [PATCH 19/20] OMAPDSS: DSI: fix DSI channel source initialization
From: Archit Taneja @ 2013-03-11 6:22 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1362743515-10152-20-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
> During the initialization of the DSI protocol registers, we always set
> the sources of all DSI channels to L4. However, we don't update the
> value in the dsi_data, so we may end up with a different value in the
> register and in the dsi_data, leading to DSI problems.
>
> This patch fixes the issue by initializing also the channel source in
> the dsi_data.
We set in omap_dsihw_probe:
static int __init omap_dsihw_probe(struct platform_device *dsidev)
{
...
...
/* DSI VCs initialization */
for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
dsi->vc[i].source = DSI_VC_SOURCE_L4;
dsi->vc[i].dssdev = NULL;
dsi->vc[i].vc_id = 0;
}
...
...
}
<snip>
Archit
^ permalink raw reply
* Re: [PATCH 20/20] OMAPDSS: Taal: remove rotate & mirror support
From: Archit Taneja @ 2013-03-11 6:33 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1362743515-10152-21-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
> Taal panel driver has support to set rotation and mirroring. However,
> these features cannot be used without causing tearing, and are never
> used. The code is just extra bloat, so let's remove it.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
<snip>
> static ssize_t taal_num_errors_show(struct device *dev,
> @@ -1025,10 +973,6 @@ static int taal_power_on(struct omap_dss_device *dssdev)
> if (r)
> goto err;
>
> - r = taal_set_addr_mode(td, td->rotate, td->mirror);
> - if (r)
> - goto err;
> -
I'm curious if we need to set the address mode(to the default value) at
least once. It may not be a requirement for Taal, but if that's the
case, why did we have a set_addr_mode() call in taal_power_on() in the
first place? Is it because we can prepare rotation and mirroring before
we enable the panel?
Archit
^ permalink raw reply
* Re: [PATCH 14/20] OMAPDSS: remove dssdev->channel assignments
From: Archit Taneja @ 2013-03-11 6:36 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1362743515-10152-15-git-send-email-tomi.valkeinen@ti.com>
On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
> Now that the driver uses ooutput->recommended_channel, we can remove the
Typo above for 'output'. We could discard this patch if we don't add
dssdev->channel assignments in patch # 10.
Archit
^ permalink raw reply
* Re: [PATCH 20/20] OMAPDSS: Taal: remove rotate & mirror support
From: Tomi Valkeinen @ 2013-03-11 6:51 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <513D7807.2010509@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
On 2013-03-11 08:21, Archit Taneja wrote:
> Hi,
>
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> Taal panel driver has support to set rotation and mirroring. However,
>> these features cannot be used without causing tearing, and are never
>> used. The code is just extra bloat, so let's remove it.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> <snip>
>> static ssize_t taal_num_errors_show(struct device *dev,
>> @@ -1025,10 +973,6 @@ static int taal_power_on(struct omap_dss_device
>> *dssdev)
>> if (r)
>> goto err;
>>
>> - r = taal_set_addr_mode(td, td->rotate, td->mirror);
>> - if (r)
>> - goto err;
>> -
>
> I'm curious if we need to set the address mode(to the default value) at
> least once. It may not be a requirement for Taal, but if that's the
> case, why did we have a set_addr_mode() call in taal_power_on() in the
> first place? Is it because we can prepare rotation and mirroring before
> we enable the panel?
The panel resets its registers at HW reset, so in case we have changed
the rotation or mirroring, we need to set the addr more at power_on to
keep the user's rotation and mirroring after resuming from blanking. But
now that the rotation or mirroring is never changed, the default value
is always fine.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 19/20] OMAPDSS: DSI: fix DSI channel source initialization
From: Tomi Valkeinen @ 2013-03-11 7:02 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <513D754A.4000607@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]
On 2013-03-11 08:10, Archit Taneja wrote:
> Hi,
>
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> During the initialization of the DSI protocol registers, we always set
>> the sources of all DSI channels to L4. However, we don't update the
>> value in the dsi_data, so we may end up with a different value in the
>> register and in the dsi_data, leading to DSI problems.
>>
>> This patch fixes the issue by initializing also the channel source in
>> the dsi_data.
>
> We set in omap_dsihw_probe:
>
> static int __init omap_dsihw_probe(struct platform_device *dsidev)
> {
> ...
> ...
> /* DSI VCs initialization */
> for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
> dsi->vc[i].source = DSI_VC_SOURCE_L4;
> dsi->vc[i].dssdev = NULL;
> dsi->vc[i].vc_id = 0;
> }
> ...
> ...
> }
Hmm... I did have a bug related to this when prototyping CDF. Ah.
Consider this:
Panel powers up and uses DSI normally. A DSI VC is set to video mode.
Then the panel power down. Then it powers up again, and enables DSI. At
this time, dsi_vc_initial_config() is called again, setting the source
in the registers to L4. But the source in dsi_data is still VP.
So perhaps the whole piece of code from omap_dsihw_probe should be moved
to somewhere else (dsi_vc_initial_config() sounds like a good place), so
that they are initialized each time the registers are initialized.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* [PATCH] matrox: fix coccicheck warning in matroxfb_base.c
From: Silviu-Mihai Popescu @ 2013-03-11 7:32 UTC (permalink / raw)
To: linux-fbdev; +Cc: FlorianSchandinat, linux-kernel, Silviu-Mihai Popescu
This replaces a call to kmalloc() followed by memset() with just one
call to kzalloc().
Signed-off-by: Silviu-Mihai Popescu <silviupopescu1990@gmail.com>
---
drivers/video/matrox/matroxfb_base.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_base.c b/drivers/video/matrox/matroxfb_base.c
index 401a56e..2456529 100644
--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c
@@ -2029,10 +2029,9 @@ static int matroxfb_probe(struct pci_dev* pdev, const struct pci_device_id* dumm
return -1;
}
- minfo = kmalloc(sizeof(*minfo), GFP_KERNEL);
+ minfo = kzalloc(sizeof(*minfo), GFP_KERNEL);
if (!minfo)
return -1;
- memset(minfo, 0, sizeof(*minfo));
minfo->pcidev = pdev;
minfo->dead = 0;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 19/20] OMAPDSS: DSI: fix DSI channel source initialization
From: Tomi Valkeinen @ 2013-03-11 8:25 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <513D92A5.5050509@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]
On 2013-03-11 10:15, Archit Taneja wrote:
> On Monday 11 March 2013 12:32 PM, Tomi Valkeinen wrote:
>> On 2013-03-11 08:10, Archit Taneja wrote:
>>> Hi,
>>>
>>> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>>>> During the initialization of the DSI protocol registers, we always set
>>>> the sources of all DSI channels to L4. However, we don't update the
>>>> value in the dsi_data, so we may end up with a different value in the
>>>> register and in the dsi_data, leading to DSI problems.
>>>>
>>>> This patch fixes the issue by initializing also the channel source in
>>>> the dsi_data.
>>>
>>> We set in omap_dsihw_probe:
>>>
>>> static int __init omap_dsihw_probe(struct platform_device *dsidev)
>>> {
>>> ...
>>> ...
>>> /* DSI VCs initialization */
>>> for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
>>> dsi->vc[i].source = DSI_VC_SOURCE_L4;
>>> dsi->vc[i].dssdev = NULL;
>>> dsi->vc[i].vc_id = 0;
>>> }
>>> ...
>>> ...
>>> }
>>
>> Hmm... I did have a bug related to this when prototyping CDF. Ah.
>> Consider this:
>>
>> Panel powers up and uses DSI normally. A DSI VC is set to video mode.
>> Then the panel power down. Then it powers up again, and enables DSI. At
>> this time, dsi_vc_initial_config() is called again, setting the source
>> in the registers to L4. But the source in dsi_data is still VP.
>
> Oh ok.
>
>>
>> So perhaps the whole piece of code from omap_dsihw_probe should be moved
>> to somewhere else (dsi_vc_initial_config() sounds like a good place), so
>> that they are initialized each time the registers are initialized.
>
> VC source is something which seems fine to do in
> dsi_vc_initial_config(). I'm not sure about the dssdev and vc_id fields
> though, we would need to call omap_dsi_request_vc() and
> omap_dsi_set_vc_id() again after a power off. Currently, we do it only
> once in taal_probe().
Oh, right. Well, neither dssdev nor vc_id is written to registers, so
they won't have similar issues in any case. So I guess this patch is
fine as it is, and we do not need to touch dssdev nor vc_id.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 19/20] OMAPDSS: DSI: fix DSI channel source initialization
From: Archit Taneja @ 2013-03-11 8:27 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <513D8198.7070702@ti.com>
On Monday 11 March 2013 12:32 PM, Tomi Valkeinen wrote:
> On 2013-03-11 08:10, Archit Taneja wrote:
>> Hi,
>>
>> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>>> During the initialization of the DSI protocol registers, we always set
>>> the sources of all DSI channels to L4. However, we don't update the
>>> value in the dsi_data, so we may end up with a different value in the
>>> register and in the dsi_data, leading to DSI problems.
>>>
>>> This patch fixes the issue by initializing also the channel source in
>>> the dsi_data.
>>
>> We set in omap_dsihw_probe:
>>
>> static int __init omap_dsihw_probe(struct platform_device *dsidev)
>> {
>> ...
>> ...
>> /* DSI VCs initialization */
>> for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
>> dsi->vc[i].source = DSI_VC_SOURCE_L4;
>> dsi->vc[i].dssdev = NULL;
>> dsi->vc[i].vc_id = 0;
>> }
>> ...
>> ...
>> }
>
> Hmm... I did have a bug related to this when prototyping CDF. Ah.
> Consider this:
>
> Panel powers up and uses DSI normally. A DSI VC is set to video mode.
> Then the panel power down. Then it powers up again, and enables DSI. At
> this time, dsi_vc_initial_config() is called again, setting the source
> in the registers to L4. But the source in dsi_data is still VP.
Oh ok.
>
> So perhaps the whole piece of code from omap_dsihw_probe should be moved
> to somewhere else (dsi_vc_initial_config() sounds like a good place), so
> that they are initialized each time the registers are initialized.
VC source is something which seems fine to do in
dsi_vc_initial_config(). I'm not sure about the dssdev and vc_id fields
though, we would need to call omap_dsi_request_vc() and
omap_dsi_set_vc_id() again after a power off. Currently, we do it only
once in taal_probe().
Archit
^ permalink raw reply
* Re: [PATCH v2 2/2] video: imxfb: Add DT support
From: Mark Rutland @ 2013-03-11 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1362504608-15839-3-git-send-email-mpa@pengutronix.de>
Hi,
Any reason for not CCing devicetree-discuss?
I have a couple of comments on the binding and the way it's parsed.
On Tue, Mar 05, 2013 at 05:30:08PM +0000, Markus Pargmann wrote:
> Add devicetree support for imx framebuffer driver. It uses the generic
> display bindings and helper functions.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> ---
>
> Notes:
> Changes in v2:
> - Removed pwmr register property
> - Cleanup of devicetree binding documentation
> - Use default values for pwmr and lscr1
>
> .../devicetree/bindings/video/fsl,imx-fb.txt | 49 ++++++
> drivers/video/imxfb.c | 182 +++++++++++++++++----
> 2 files changed, 197 insertions(+), 34 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
>
> diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> new file mode 100644
> index 0000000..e1a53a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> @@ -0,0 +1,49 @@
> +Freescale imx21 Framebuffer
> +
> +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> +
> +Required properties:
> +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> +- reg : Should contain 1 register ranges(address and length)
> +- interrupts : One interrupt of the fb dev
> +
> +Required nodes:
> +- display: Phandle to a display node as described in
> + Documentation/devicetree/bindings/video/display-timing.txt
> + Additional, the display node has to define properties:
> + - bpp: Bits per pixel
> + - pcr: LCDC PCR value
As these are non-standard, it would be good to prefix them (e.g. "fsl,pcr").
If you need them, why are they not a good fit for the generic binding?
I'm not familiar with the hardware, what is the PCR exactly?
[...]
> -static int __init imxfb_probe(struct platform_device *pdev)
> +static int imxfb_of_read_mode(struct device_node *np,
> + struct imx_fb_videomode *imxfb_mode)
> +{
> + int ret;
> + struct fb_videomode *of_mode = &imxfb_mode->mode;
> + u32 bpp;
> + u32 pcr;
> +
> + ret = of_property_read_string(np, "model", &of_mode->name);
> + if (ret)
> + of_mode->name = NULL;
> +
> + ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32(np, "bpp", &bpp);
> + ret |= of_property_read_u32(np, "pcr", &pcr);
> +
> + if (ret)
> + return ret;
Is this return value used anywhere in anything more than an "if (!err)"
capacity? If so it may be worth having individual return value checks:
If one call returns -EINVAL (-22) and the other -ENODATA (-61), out the other
end we'd get -EISDIR (-21). If we don't care particularly about which error
code we actually pass on, we could always return a sensible code when ret is
nonzero:
if (ret)
return -EINVAL;
> +
> + if (bpp > 255)
> + return -EINVAL;
Might it also be worth checking for 0 here?
[...]
> @@ -837,15 +914,51 @@ static int __init imxfb_probe(struct platform_device *pdev)
>
> fbi = info->par;
>
> - if (!fb_mode)
> - fb_mode = pdata->mode[0].mode.name;
> -
> platform_set_drvdata(pdev, info);
>
> ret = imxfb_init_fbinfo(pdev);
> if (ret < 0)
> goto failed_init;
>
> + if (pdata) {
> + if (!fb_mode)
> + fb_mode = pdata->mode[0].mode.name;
> +
> + fbi->mode = pdata->mode;
> + fbi->num_modes = pdata->num_modes;
> + } else {
> + struct device_node *display_np;
> + fb_mode = NULL;
> +
> + display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
> + if (!display_np) {
> + dev_err(&pdev->dev, "No display defined in devicetree\n");
> + ret = -EINVAL;
> + goto failed_of_parse;
> + }
> +
> + /*
> + * imxfb does not support more modes, we choose only the native
> + * mode.
> + */
> + fbi->num_modes = 1;
> +
> + fbi->mode = devm_kzalloc(&pdev->dev,
> + sizeof(struct imx_fb_videomode), GFP_KERNEL);
> + if (!fbi->mode) {
> + ret = -ENOMEM;
> + goto failed_of_parse;
> + }
> +
> + ret = imxfb_of_read_mode(display_np, fbi->mode);
> + if (ret)
> + goto failed_of_parse;
> + }
> +
> + for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++)
> + info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> + m->mode.xres * m->mode.yres * m->bpp / 8);
Surely this is broken if bpp is not as multiple of 8?
If we can only handle multiples of 8, could we not sanity check this earlier?
If there's no strong preference for describing it in bits, could we not
describe it in bytes and side-step the issue?
[...]
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
From: Tomi Valkeinen @ 2013-03-11 11:02 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <513D6D06.7030902@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4497 bytes --]
On 2013-03-11 07:35, Archit Taneja wrote:
> Hi,
>
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> The DISPC channel used for each output is currently passed in panel
>> platform data from the board files.
>>
>> To simplify this, and to make the panel drivers less dependent on OMAP,
>> this patch changes omapdss to resolve the channel independently. The
>> channel is resolved based on the OMAP version and, in case of DSI, the
>> DSI module id.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> drivers/video/omap2/dss/dpi.c | 37 ++++++++++++++++++++++++++-----
>> drivers/video/omap2/dss/dsi.c | 48
>> ++++++++++++++++++++++++++++++++++++++++
>> drivers/video/omap2/dss/rfbi.c | 2 ++
>> drivers/video/omap2/dss/sdi.c | 2 ++
>> 4 files changed, 84 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dpi.c
>> b/drivers/video/omap2/dss/dpi.c
>> index e282456..3261644 100644
>> --- a/drivers/video/omap2/dss/dpi.c
>> +++ b/drivers/video/omap2/dss/dpi.c
>> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
>> platform_device *dsidev)
>> return 0;
>> }
>>
>> +/*
>> + * Return a hardcoded channel for the DPI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dpi_get_channel(void)
>> +{
>> + switch (omapdss_get_version()) {
>> + case OMAPDSS_VER_OMAP24xx:
>> + case OMAPDSS_VER_OMAP34xx_ES1:
>> + case OMAPDSS_VER_OMAP34xx_ES3:
>> + case OMAPDSS_VER_OMAP3630:
>> + case OMAPDSS_VER_AM35xx:
>> + return OMAP_DSS_CHANNEL_LCD;
>> +
>> + case OMAPDSS_VER_OMAP4430_ES1:
>> + case OMAPDSS_VER_OMAP4430_ES2:
>> + case OMAPDSS_VER_OMAP4:
>> + return OMAP_DSS_CHANNEL_LCD2;
>> +
>> + case OMAPDSS_VER_OMAP5:
>> + return OMAP_DSS_CHANNEL_LCD2;
>> +
>> + default:
>> + DSSWARN("unsupported DSS version\n");
>> + return OMAP_DSS_CHANNEL_LCD;
>> + }
>> +}
>> +
>> static int __init dpi_init_display(struct omap_dss_device *dssdev)
>> {
>> struct platform_device *dsidev;
>>
>> DSSDBG("init_display\n");
>>
>> + dssdev->channel = dpi_get_channel();
>
> In patch 14 of the series, we remove these dssdev->channel assignments.
> I don't see the point of adding them in this patch in the first place.
> The dssdev->channel assignments will not be modified in this series, so
> we don't need to worry about a kernel crash or something after this patch.
>
> I feel this patch should only add the dpi_get_channel and
> dsi_get_channel funcs.
Yes, you're right. It's just extra going back and forth. I think I'll
merge this with the patch adding recommended channel.
>> +
>> if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
>> dpi.vdds_dsi_reg == NULL) {
>> struct regulator *vdds_dsi;
>> @@ -416,11 +448,6 @@ static int __init dpi_init_display(struct
>> omap_dss_device *dssdev)
>> dpi.vdds_dsi_reg = vdds_dsi;
>> }
>>
>> - /*
>> - * XXX We shouldn't need dssdev->channel for this. The dsi pll clock
>> - * source for DPI is SoC integration detail, not something that
>> should
>> - * be configured in the dssdev
>> - */
>> dsidev = dpi_get_dsidev(dssdev->channel);
>>
>> if (dsidev && dpi_verify_dsi_pll(dsidev)) {
>> diff --git a/drivers/video/omap2/dss/dsi.c
>> b/drivers/video/omap2/dss/dsi.c
>> index 1a6ad6f..c39ca86 100644
>> --- a/drivers/video/omap2/dss/dsi.c
>> +++ b/drivers/video/omap2/dss/dsi.c
>> @@ -4946,6 +4946,52 @@ void omapdss_dsi_set_videomode_timings(struct
>> omap_dss_device *dssdev,
>> }
>> EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
>>
>> +/*
>> + * Return a hardcoded channel for the DSI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dsi_get_channel(int module_id)
>> +{
>> + switch (omapdss_get_version()) {
>> + case OMAPDSS_VER_OMAP24xx:
>
> We should remove the above case so that we hit the default case and get
> a warning about omap2 not having DSI.
Yep, I'll fix that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
From: Tomi Valkeinen @ 2013-03-11 11:54 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <513D716C.2050807@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2978 bytes --]
On 2013-03-11 07:53, Archit Taneja wrote:
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> The DISPC channel used for each output is currently passed in panel
>> platform data from the board files.
>>
>> To simplify this, and to make the panel drivers less dependent on OMAP,
>> this patch changes omapdss to resolve the channel independently. The
>> channel is resolved based on the OMAP version and, in case of DSI, the
>> DSI module id.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> drivers/video/omap2/dss/dpi.c | 37 ++++++++++++++++++++++++++-----
>> drivers/video/omap2/dss/dsi.c | 48
>> ++++++++++++++++++++++++++++++++++++++++
>> drivers/video/omap2/dss/rfbi.c | 2 ++
>> drivers/video/omap2/dss/sdi.c | 2 ++
>> 4 files changed, 84 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dpi.c
>> b/drivers/video/omap2/dss/dpi.c
>> index e282456..3261644 100644
>> --- a/drivers/video/omap2/dss/dpi.c
>> +++ b/drivers/video/omap2/dss/dpi.c
>> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
>> platform_device *dsidev)
>> return 0;
>> }
>>
>> +/*
>> + * Return a hardcoded channel for the DPI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dpi_get_channel(void)
>> +{
>> + switch (omapdss_get_version()) {
>> + case OMAPDSS_VER_OMAP24xx:
>> + case OMAPDSS_VER_OMAP34xx_ES1:
>> + case OMAPDSS_VER_OMAP34xx_ES3:
>> + case OMAPDSS_VER_OMAP3630:
>> + case OMAPDSS_VER_AM35xx:
>> + return OMAP_DSS_CHANNEL_LCD;
>> +
>> + case OMAPDSS_VER_OMAP4430_ES1:
>> + case OMAPDSS_VER_OMAP4430_ES2:
>> + case OMAPDSS_VER_OMAP4:
>> + return OMAP_DSS_CHANNEL_LCD2;
>> +
>> + case OMAPDSS_VER_OMAP5:
>> + return OMAP_DSS_CHANNEL_LCD2;
>> +
>> + default:
>> + DSSWARN("unsupported DSS version\n");
>> + return OMAP_DSS_CHANNEL_LCD;
>> + }
>> +}
>
> I had another comment for this patch. On OMAP5, it makes sense for us to
> not use LCD2 as the recommended channel. LCD2_CLK's only source is
> DSS_CLK from PRCM. So it's not a very flexible channel to use. We could
> use LCD3 (at the cost of not using DSI2).
Ok. Yes, this looks to be the case. I'll use LCD3 for DPI for now. In
the worst case we may need to pass some channel setup parameters via
omapdss DT data or platform data, but I'd really much like the driver to
be able to resolve the dispc channels by itself...
> We also need to fix dpi_get_dsidev() for OMAP5. Currently, it assumes
> that LCD2_CLK can be sourced from DSI2 PLL, we need to ensure DPI has a
> dsidev only if it's LCD1 or LCD3.
Right. I'll add if (OMAP5) there, and return DSI2 PLL for LCD3, and NULL
for LCD2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
From: Tomi Valkeinen @ 2013-03-11 12:01 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <513D716C.2050807@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4243 bytes --]
On 2013-03-11 07:53, Archit Taneja wrote:
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> The DISPC channel used for each output is currently passed in panel
>> platform data from the board files.
>>
>> To simplify this, and to make the panel drivers less dependent on OMAP,
>> this patch changes omapdss to resolve the channel independently. The
>> channel is resolved based on the OMAP version and, in case of DSI, the
>> DSI module id.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> drivers/video/omap2/dss/dpi.c | 37 ++++++++++++++++++++++++++-----
>> drivers/video/omap2/dss/dsi.c | 48
>> ++++++++++++++++++++++++++++++++++++++++
>> drivers/video/omap2/dss/rfbi.c | 2 ++
>> drivers/video/omap2/dss/sdi.c | 2 ++
>> 4 files changed, 84 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dpi.c
>> b/drivers/video/omap2/dss/dpi.c
>> index e282456..3261644 100644
>> --- a/drivers/video/omap2/dss/dpi.c
>> +++ b/drivers/video/omap2/dss/dpi.c
>> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
>> platform_device *dsidev)
>> return 0;
>> }
>>
>> +/*
>> + * Return a hardcoded channel for the DPI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dpi_get_channel(void)
>> +{
>> + switch (omapdss_get_version()) {
>> + case OMAPDSS_VER_OMAP24xx:
>> + case OMAPDSS_VER_OMAP34xx_ES1:
>> + case OMAPDSS_VER_OMAP34xx_ES3:
>> + case OMAPDSS_VER_OMAP3630:
>> + case OMAPDSS_VER_AM35xx:
>> + return OMAP_DSS_CHANNEL_LCD;
>> +
>> + case OMAPDSS_VER_OMAP4430_ES1:
>> + case OMAPDSS_VER_OMAP4430_ES2:
>> + case OMAPDSS_VER_OMAP4:
>> + return OMAP_DSS_CHANNEL_LCD2;
>> +
>> + case OMAPDSS_VER_OMAP5:
>> + return OMAP_DSS_CHANNEL_LCD2;
>> +
>> + default:
>> + DSSWARN("unsupported DSS version\n");
>> + return OMAP_DSS_CHANNEL_LCD;
>> + }
>> +}
>
> I had another comment for this patch. On OMAP5, it makes sense for us to
> not use LCD2 as the recommended channel. LCD2_CLK's only source is
> DSS_CLK from PRCM. So it's not a very flexible channel to use. We could
> use LCD3 (at the cost of not using DSI2).
>
> We also need to fix dpi_get_dsidev() for OMAP5. Currently, it assumes
> that LCD2_CLK can be sourced from DSI2 PLL, we need to ensure DPI has a
> dsidev only if it's LCD1 or LCD3.
I fixed it this way:
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Mon Mar 11 13:57:38 2013 +0200
OMAPDSS: DPI: fix dpi_get_dsidev() for omap5
On OMAP5 the DISPC channels and DSI PLLs are not connected the same way.
LCD2 on OMAP5 cannot use any DSI PLL as a source clock, but LCD3 can use
DSI2's PLL.
This patch fixes dpi_get_dsidev() by adding separate case for OMAP5 to
handle the difference.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 409e53b..433eff7 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -63,15 +63,29 @@ static struct platform_device *dpi_get_dsidev(enum omap_channel channel)
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
return NULL;
- default:
- break;
- }
- switch (channel) {
- case OMAP_DSS_CHANNEL_LCD:
- return dsi_get_dsidev_from_id(0);
- case OMAP_DSS_CHANNEL_LCD2:
- return dsi_get_dsidev_from_id(1);
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ return dsi_get_dsidev_from_id(0);
+ case OMAP_DSS_CHANNEL_LCD2:
+ return dsi_get_dsidev_from_id(1);
+ default:
+ return NULL;
+ }
+
+ case OMAPDSS_VER_OMAP5:
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ return dsi_get_dsidev_from_id(0);
+ case OMAP_DSS_CHANNEL_LCD3:
+ return dsi_get_dsidev_from_id(1);
+ default:
+ return NULL;
+ }
+
default:
return NULL;
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply related
* Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
From: Tomi Valkeinen @ 2013-03-11 12:05 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <513D6D06.7030902@ti.com>
[-- Attachment #1: Type: text/plain, Size: 11242 bytes --]
On 2013-03-11 07:35, Archit Taneja wrote:
> Hi,
>
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> The DISPC channel used for each output is currently passed in panel
>> platform data from the board files.
>>
>> To simplify this, and to make the panel drivers less dependent on OMAP,
>> this patch changes omapdss to resolve the channel independently. The
>> channel is resolved based on the OMAP version and, in case of DSI, the
>> DSI module id.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> drivers/video/omap2/dss/dpi.c | 37 ++++++++++++++++++++++++++-----
>> drivers/video/omap2/dss/dsi.c | 48
>> ++++++++++++++++++++++++++++++++++++++++
>> drivers/video/omap2/dss/rfbi.c | 2 ++
>> drivers/video/omap2/dss/sdi.c | 2 ++
>> 4 files changed, 84 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dpi.c
>> b/drivers/video/omap2/dss/dpi.c
>> index e282456..3261644 100644
>> --- a/drivers/video/omap2/dss/dpi.c
>> +++ b/drivers/video/omap2/dss/dpi.c
>> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
>> platform_device *dsidev)
>> return 0;
>> }
>>
>> +/*
>> + * Return a hardcoded channel for the DPI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dpi_get_channel(void)
>> +{
>> + switch (omapdss_get_version()) {
>> + case OMAPDSS_VER_OMAP24xx:
>> + case OMAPDSS_VER_OMAP34xx_ES1:
>> + case OMAPDSS_VER_OMAP34xx_ES3:
>> + case OMAPDSS_VER_OMAP3630:
>> + case OMAPDSS_VER_AM35xx:
>> + return OMAP_DSS_CHANNEL_LCD;
>> +
>> + case OMAPDSS_VER_OMAP4430_ES1:
>> + case OMAPDSS_VER_OMAP4430_ES2:
>> + case OMAPDSS_VER_OMAP4:
>> + return OMAP_DSS_CHANNEL_LCD2;
>> +
>> + case OMAPDSS_VER_OMAP5:
>> + return OMAP_DSS_CHANNEL_LCD2;
>> +
>> + default:
>> + DSSWARN("unsupported DSS version\n");
>> + return OMAP_DSS_CHANNEL_LCD;
>> + }
>> +}
>> +
>> static int __init dpi_init_display(struct omap_dss_device *dssdev)
>> {
>> struct platform_device *dsidev;
>>
>> DSSDBG("init_display\n");
>>
>> + dssdev->channel = dpi_get_channel();
>
> In patch 14 of the series, we remove these dssdev->channel assignments.
> I don't see the point of adding them in this patch in the first place.
> The dssdev->channel assignments will not be modified in this series, so
> we don't need to worry about a kernel crash or something after this patch.
>
> I feel this patch should only add the dpi_get_channel and
> dsi_get_channel funcs.
Here's the combined patch. I changed the recommended_channel to dispc_channel.
"recommended" was not that good name, as currently the channel cannot be changed
later, because, for example in DPI case, we store the DSI PLL which is based on
the channel.
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Wed Feb 13 11:23:54 2013 +0200
OMAPDSS: add output->dispc_channel
The DISPC channel used for each output is currently passed in panel
platform data from the board files.
To simplify this, and to make the panel drivers less dependent on OMAP,
this patch changes omapdss to resolve the channel independently. The
channel is resolved based on the OMAP version and, in case of DSI, the
DSI module id. This resolved channel is stored into a new field in
output, dispc_channel.
The few places where dssdev->channel was used are changed to use
output->recommended_channel. After this patch, dssdev->channel is
obsolete.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e282456..409e53b 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -396,6 +396,36 @@ static int __init dpi_verify_dsi_pll(struct platform_device *dsidev)
return 0;
}
+/*
+ * Return a hardcoded channel for the DPI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dpi_get_channel(void)
+{
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
+ return OMAP_DSS_CHANNEL_LCD;
+
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ return OMAP_DSS_CHANNEL_LCD2;
+
+ case OMAPDSS_VER_OMAP5:
+ return OMAP_DSS_CHANNEL_LCD3;
+
+ default:
+ DSSWARN("unsupported DSS version\n");
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+}
+
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev;
@@ -416,12 +446,7 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
dpi.vdds_dsi_reg = vdds_dsi;
}
- /*
- * XXX We shouldn't need dssdev->channel for this. The dsi pll clock
- * source for DPI is SoC integration detail, not something that should
- * be configured in the dssdev
- */
- dsidev = dpi_get_dsidev(dssdev->channel);
+ dsidev = dpi_get_dsidev(dpi.output.dispc_channel);
if (dsidev && dpi_verify_dsi_pll(dsidev)) {
dsidev = NULL;
@@ -513,6 +538,7 @@ static void __init dpi_init_output(struct platform_device *pdev)
out->id = OMAP_DSS_OUTPUT_DPI;
out->type = OMAP_DISPLAY_TYPE_DPI;
out->name = "dpi";
+ out->dispc_channel = dpi_get_channel();
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 1a6ad6f..28e0b99 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4946,6 +4946,55 @@ void omapdss_dsi_set_videomode_timings(struct omap_dss_device *dssdev,
}
EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
+/*
+ * Return a hardcoded channel for the DSI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dsi_get_channel(int module_id)
+{
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
+ DSSWARN("DSI not supported\n");
+ return OMAP_DSS_CHANNEL_LCD;
+
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
+ return OMAP_DSS_CHANNEL_LCD;
+
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ switch (module_id) {
+ case 0:
+ return OMAP_DSS_CHANNEL_LCD;
+ case 1:
+ return OMAP_DSS_CHANNEL_LCD2;
+ default:
+ DSSWARN("unsupported module id\n");
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+
+ case OMAPDSS_VER_OMAP5:
+ switch (module_id) {
+ case 0:
+ return OMAP_DSS_CHANNEL_LCD;
+ case 1:
+ return OMAP_DSS_CHANNEL_LCD3;
+ default:
+ DSSWARN("unsupported module id\n");
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+
+ default:
+ DSSWARN("unsupported DSS version\n");
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+}
+
static int __init dsi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev =
@@ -5184,6 +5233,7 @@ static void __init dsi_init_output(struct platform_device *dsidev)
out->type = OMAP_DISPLAY_TYPE_DSI;
out->name = dsi->module_id == 0 ? "dsi0" : "dsi1";
+ out->dispc_channel = dsi_get_channel(dsi->module_id);
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 888cfe3..e03619a 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1012,8 +1012,6 @@ static void __init hdmi_probe_pdata(struct platform_device *pdev)
hdmi.ls_oe_gpio = priv->ls_oe_gpio;
hdmi.hpd_gpio = priv->hpd_gpio;
- dssdev->channel = OMAP_DSS_CHANNEL_DIGIT;
-
r = hdmi_init_display(dssdev);
if (r) {
DSSERR("device %s init failed: %d\n", dssdev->name, r);
@@ -1047,6 +1045,7 @@ static void __init hdmi_init_output(struct platform_device *pdev)
out->id = OMAP_DSS_OUTPUT_HDMI;
out->type = OMAP_DISPLAY_TYPE_HDMI;
out->name = "hdmi";
+ out->dispc_channel = OMAP_DSS_CHANNEL_DIGIT;
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index a47a9e5..05c0646 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1026,6 +1026,7 @@ static void __init rfbi_init_output(struct platform_device *pdev)
out->id = OMAP_DSS_OUTPUT_DBI;
out->type = OMAP_DISPLAY_TYPE_DBI;
out->name = "rfbi";
+ out->dispc_channel = OMAP_DSS_CHANNEL_LCD;
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 0802927..5d37db5 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -279,6 +279,7 @@ static void __init sdi_init_output(struct platform_device *pdev)
out->id = OMAP_DSS_OUTPUT_SDI;
out->type = OMAP_DISPLAY_TYPE_SDI;
out->name = "sdi";
+ out->dispc_channel = OMAP_DSS_CHANNEL_LCD;
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index c8130f8..866e015 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -786,8 +786,6 @@ static void __init venc_probe_pdata(struct platform_device *vencdev)
dss_copy_device_pdata(dssdev, plat_dssdev);
- dssdev->channel = OMAP_DSS_CHANNEL_DIGIT;
-
r = venc_init_display(dssdev);
if (r) {
DSSERR("device %s init failed: %d\n", dssdev->name, r);
@@ -820,6 +818,7 @@ static void __init venc_init_output(struct platform_device *pdev)
out->id = OMAP_DSS_OUTPUT_VENC;
out->type = OMAP_DISPLAY_TYPE_VENC;
out->name = "venc";
+ out->dispc_channel = OMAP_DSS_CHANNEL_DIGIT;
dss_register_output(out);
}
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index ca585ef..f38348e 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2388,7 +2388,7 @@ static int omapfb_init_connections(struct omapfb2_device *fbdev,
struct omap_dss_device *dssdev = fbdev->displays[i].dssdev;
struct omap_dss_output *out = dssdev->output;
- mgr = omap_dss_get_overlay_manager(dssdev->channel);
+ mgr = omap_dss_get_overlay_manager(out->dispc_channel);
if (!mgr || !out)
continue;
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index ba9cea7..ec322a7 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -547,6 +547,9 @@ struct omap_dss_output {
/* display type supported by the output */
enum omap_display_type type;
+ /* DISPC channel for this output */
+ enum omap_channel dispc_channel;
+
/* output instance */
enum omap_dss_output_id id;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2] omapfb: fix broken build on Amstrad E3/Delta
From: Tomi Valkeinen @ 2013-03-11 12:22 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Aaro Koskinen, linux-fbdev, linux-omap
In-Reply-To: <20130304223911.GZ11806@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]
On 2013-03-05 00:39, Tony Lindgren wrote:
> Hi,
>
> * Aaro Koskinen <aaro.koskinen@iki.fi> [130304 13:08]:
>> Fix the following build regression in 3.9-rc1 by including
>> <machine/hardware.h>:
>>
>> drivers/video/omap/lcd_ams_delta.c: In function 'ams_delta_lcd_set_power':
>> drivers/video/omap/lcd_ams_delta.c:48:4: error: implicit declaration of function 'omap_writeb' [-Werror=implicit-function-declaration]
>> drivers/video/omap/lcd_ams_delta.c:49:6: error: 'OMAP_PWL_ENABLE' undeclared (first use in this function)
>> drivers/video/omap/lcd_ams_delta.c:49:6: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/video/omap/lcd_ams_delta.c:50:19: error: 'OMAP_PWL_CLK_ENABLE' undeclared (first use in this function)
>> drivers/video/omap/lcd_ams_delta.c: In function 'ams_delta_lcd_set_contrast':
>> drivers/video/omap/lcd_ams_delta.c:66:22: error: 'OMAP_PWL_ENABLE' undeclared (first use in this function)
>
> I have this already queued up in omap-for-v3.9-rc1/fixes as 0adcbaf78
> (ARM: OMAP1: Fix build related to kgdb.h no longer including serial_8250.h)
> and for lcd_osk.c as omap1_defconfig was broken.
>
> I don't anything for the first patch you posted, so I suggest
> Tomi applies that one.
Ok, I'll take the first patch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
From: Archit Taneja @ 2013-03-11 12:31 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <513DC870.3030908@ti.com>
On Monday 11 March 2013 05:35 PM, Tomi Valkeinen wrote:
> On 2013-03-11 07:35, Archit Taneja wrote:
>> Hi,
>>
>> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>>> The DISPC channel used for each output is currently passed in panel
>>> platform data from the board files.
>>>
>>> To simplify this, and to make the panel drivers less dependent on OMAP,
>>> this patch changes omapdss to resolve the channel independently. The
>>> channel is resolved based on the OMAP version and, in case of DSI, the
>>> DSI module id.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> drivers/video/omap2/dss/dpi.c | 37 ++++++++++++++++++++++++++-----
>>> drivers/video/omap2/dss/dsi.c | 48
>>> ++++++++++++++++++++++++++++++++++++++++
>>> drivers/video/omap2/dss/rfbi.c | 2 ++
>>> drivers/video/omap2/dss/sdi.c | 2 ++
>>> 4 files changed, 84 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/video/omap2/dss/dpi.c
>>> b/drivers/video/omap2/dss/dpi.c
>>> index e282456..3261644 100644
>>> --- a/drivers/video/omap2/dss/dpi.c
>>> +++ b/drivers/video/omap2/dss/dpi.c
>>> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
>>> platform_device *dsidev)
>>> return 0;
>>> }
>>>
>>> +/*
>>> + * Return a hardcoded channel for the DPI output. This should work for
>>> + * current use cases, but this can be later expanded to either resolve
>>> + * the channel in some more dynamic manner, or get the channel as a user
>>> + * parameter.
>>> + */
>>> +static enum omap_channel dpi_get_channel(void)
>>> +{
>>> + switch (omapdss_get_version()) {
>>> + case OMAPDSS_VER_OMAP24xx:
>>> + case OMAPDSS_VER_OMAP34xx_ES1:
>>> + case OMAPDSS_VER_OMAP34xx_ES3:
>>> + case OMAPDSS_VER_OMAP3630:
>>> + case OMAPDSS_VER_AM35xx:
>>> + return OMAP_DSS_CHANNEL_LCD;
>>> +
>>> + case OMAPDSS_VER_OMAP4430_ES1:
>>> + case OMAPDSS_VER_OMAP4430_ES2:
>>> + case OMAPDSS_VER_OMAP4:
>>> + return OMAP_DSS_CHANNEL_LCD2;
>>> +
>>> + case OMAPDSS_VER_OMAP5:
>>> + return OMAP_DSS_CHANNEL_LCD2;
>>> +
>>> + default:
>>> + DSSWARN("unsupported DSS version\n");
>>> + return OMAP_DSS_CHANNEL_LCD;
>>> + }
>>> +}
>>> +
>>> static int __init dpi_init_display(struct omap_dss_device *dssdev)
>>> {
>>> struct platform_device *dsidev;
>>>
>>> DSSDBG("init_display\n");
>>>
>>> + dssdev->channel = dpi_get_channel();
>>
>> In patch 14 of the series, we remove these dssdev->channel assignments.
>> I don't see the point of adding them in this patch in the first place.
>> The dssdev->channel assignments will not be modified in this series, so
>> we don't need to worry about a kernel crash or something after this patch.
>>
>> I feel this patch should only add the dpi_get_channel and
>> dsi_get_channel funcs.
>
> Here's the combined patch. I changed the recommended_channel to dispc_channel.
> "recommended" was not that good name, as currently the channel cannot be changed
> later, because, for example in DPI case, we store the DSI PLL which is based on
> the channel.
The patch looks fine now.
Reviewed-by: Archit Taneja <archit@ti.com>
Archit
>
>
> Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Wed Feb 13 11:23:54 2013 +0200
>
> OMAPDSS: add output->dispc_channel
>
> The DISPC channel used for each output is currently passed in panel
> platform data from the board files.
>
> To simplify this, and to make the panel drivers less dependent on OMAP,
> this patch changes omapdss to resolve the channel independently. The
> channel is resolved based on the OMAP version and, in case of DSI, the
> DSI module id. This resolved channel is stored into a new field in
> output, dispc_channel.
>
> The few places where dssdev->channel was used are changed to use
> output->recommended_channel. After this patch, dssdev->channel is
> obsolete.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index e282456..409e53b 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -396,6 +396,36 @@ static int __init dpi_verify_dsi_pll(struct platform_device *dsidev)
> return 0;
> }
>
> +/*
> + * Return a hardcoded channel for the DPI output. This should work for
> + * current use cases, but this can be later expanded to either resolve
> + * the channel in some more dynamic manner, or get the channel as a user
> + * parameter.
> + */
> +static enum omap_channel dpi_get_channel(void)
> +{
> + switch (omapdss_get_version()) {
> + case OMAPDSS_VER_OMAP24xx:
> + case OMAPDSS_VER_OMAP34xx_ES1:
> + case OMAPDSS_VER_OMAP34xx_ES3:
> + case OMAPDSS_VER_OMAP3630:
> + case OMAPDSS_VER_AM35xx:
> + return OMAP_DSS_CHANNEL_LCD;
> +
> + case OMAPDSS_VER_OMAP4430_ES1:
> + case OMAPDSS_VER_OMAP4430_ES2:
> + case OMAPDSS_VER_OMAP4:
> + return OMAP_DSS_CHANNEL_LCD2;
> +
> + case OMAPDSS_VER_OMAP5:
> + return OMAP_DSS_CHANNEL_LCD3;
> +
> + default:
> + DSSWARN("unsupported DSS version\n");
> + return OMAP_DSS_CHANNEL_LCD;
> + }
> +}
> +
> static int __init dpi_init_display(struct omap_dss_device *dssdev)
> {
> struct platform_device *dsidev;
> @@ -416,12 +446,7 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
> dpi.vdds_dsi_reg = vdds_dsi;
> }
>
> - /*
> - * XXX We shouldn't need dssdev->channel for this. The dsi pll clock
> - * source for DPI is SoC integration detail, not something that should
> - * be configured in the dssdev
> - */
> - dsidev = dpi_get_dsidev(dssdev->channel);
> + dsidev = dpi_get_dsidev(dpi.output.dispc_channel);
>
> if (dsidev && dpi_verify_dsi_pll(dsidev)) {
> dsidev = NULL;
> @@ -513,6 +538,7 @@ static void __init dpi_init_output(struct platform_device *pdev)
> out->id = OMAP_DSS_OUTPUT_DPI;
> out->type = OMAP_DISPLAY_TYPE_DPI;
> out->name = "dpi";
> + out->dispc_channel = dpi_get_channel();
>
> dss_register_output(out);
> }
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 1a6ad6f..28e0b99 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -4946,6 +4946,55 @@ void omapdss_dsi_set_videomode_timings(struct omap_dss_device *dssdev,
> }
> EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
>
> +/*
> + * Return a hardcoded channel for the DSI output. This should work for
> + * current use cases, but this can be later expanded to either resolve
> + * the channel in some more dynamic manner, or get the channel as a user
> + * parameter.
> + */
> +static enum omap_channel dsi_get_channel(int module_id)
> +{
> + switch (omapdss_get_version()) {
> + case OMAPDSS_VER_OMAP24xx:
> + DSSWARN("DSI not supported\n");
> + return OMAP_DSS_CHANNEL_LCD;
> +
> + case OMAPDSS_VER_OMAP34xx_ES1:
> + case OMAPDSS_VER_OMAP34xx_ES3:
> + case OMAPDSS_VER_OMAP3630:
> + case OMAPDSS_VER_AM35xx:
> + return OMAP_DSS_CHANNEL_LCD;
> +
> + case OMAPDSS_VER_OMAP4430_ES1:
> + case OMAPDSS_VER_OMAP4430_ES2:
> + case OMAPDSS_VER_OMAP4:
> + switch (module_id) {
> + case 0:
> + return OMAP_DSS_CHANNEL_LCD;
> + case 1:
> + return OMAP_DSS_CHANNEL_LCD2;
> + default:
> + DSSWARN("unsupported module id\n");
> + return OMAP_DSS_CHANNEL_LCD;
> + }
> +
> + case OMAPDSS_VER_OMAP5:
> + switch (module_id) {
> + case 0:
> + return OMAP_DSS_CHANNEL_LCD;
> + case 1:
> + return OMAP_DSS_CHANNEL_LCD3;
> + default:
> + DSSWARN("unsupported module id\n");
> + return OMAP_DSS_CHANNEL_LCD;
> + }
> +
> + default:
> + DSSWARN("unsupported DSS version\n");
> + return OMAP_DSS_CHANNEL_LCD;
> + }
> +}
> +
> static int __init dsi_init_display(struct omap_dss_device *dssdev)
> {
> struct platform_device *dsidev > @@ -5184,6 +5233,7 @@ static void __init dsi_init_output(struct platform_device *dsidev)
>
> out->type = OMAP_DISPLAY_TYPE_DSI;
> out->name = dsi->module_id = 0 ? "dsi0" : "dsi1";
> + out->dispc_channel = dsi_get_channel(dsi->module_id);
>
> dss_register_output(out);
> }
> diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
> index 888cfe3..e03619a 100644
> --- a/drivers/video/omap2/dss/hdmi.c
> +++ b/drivers/video/omap2/dss/hdmi.c
> @@ -1012,8 +1012,6 @@ static void __init hdmi_probe_pdata(struct platform_device *pdev)
> hdmi.ls_oe_gpio = priv->ls_oe_gpio;
> hdmi.hpd_gpio = priv->hpd_gpio;
>
> - dssdev->channel = OMAP_DSS_CHANNEL_DIGIT;
> -
> r = hdmi_init_display(dssdev);
> if (r) {
> DSSERR("device %s init failed: %d\n", dssdev->name, r);
> @@ -1047,6 +1045,7 @@ static void __init hdmi_init_output(struct platform_device *pdev)
> out->id = OMAP_DSS_OUTPUT_HDMI;
> out->type = OMAP_DISPLAY_TYPE_HDMI;
> out->name = "hdmi";
> + out->dispc_channel = OMAP_DSS_CHANNEL_DIGIT;
>
> dss_register_output(out);
> }
> diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
> index a47a9e5..05c0646 100644
> --- a/drivers/video/omap2/dss/rfbi.c
> +++ b/drivers/video/omap2/dss/rfbi.c
> @@ -1026,6 +1026,7 @@ static void __init rfbi_init_output(struct platform_device *pdev)
> out->id = OMAP_DSS_OUTPUT_DBI;
> out->type = OMAP_DISPLAY_TYPE_DBI;
> out->name = "rfbi";
> + out->dispc_channel = OMAP_DSS_CHANNEL_LCD;
>
> dss_register_output(out);
> }
> diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
> index 0802927..5d37db5 100644
> --- a/drivers/video/omap2/dss/sdi.c
> +++ b/drivers/video/omap2/dss/sdi.c
> @@ -279,6 +279,7 @@ static void __init sdi_init_output(struct platform_device *pdev)
> out->id = OMAP_DSS_OUTPUT_SDI;
> out->type = OMAP_DISPLAY_TYPE_SDI;
> out->name = "sdi";
> + out->dispc_channel = OMAP_DSS_CHANNEL_LCD;
>
> dss_register_output(out);
> }
> diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
> index c8130f8..866e015 100644
> --- a/drivers/video/omap2/dss/venc.c
> +++ b/drivers/video/omap2/dss/venc.c
> @@ -786,8 +786,6 @@ static void __init venc_probe_pdata(struct platform_device *vencdev)
>
> dss_copy_device_pdata(dssdev, plat_dssdev);
>
> - dssdev->channel = OMAP_DSS_CHANNEL_DIGIT;
> -
> r = venc_init_display(dssdev);
> if (r) {
> DSSERR("device %s init failed: %d\n", dssdev->name, r);
> @@ -820,6 +818,7 @@ static void __init venc_init_output(struct platform_device *pdev)
> out->id = OMAP_DSS_OUTPUT_VENC;
> out->type = OMAP_DISPLAY_TYPE_VENC;
> out->name = "venc";
> + out->dispc_channel = OMAP_DSS_CHANNEL_DIGIT;
>
> dss_register_output(out);
> }
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
> index ca585ef..f38348e 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -2388,7 +2388,7 @@ static int omapfb_init_connections(struct omapfb2_device *fbdev,
> struct omap_dss_device *dssdev = fbdev->displays[i].dssdev;
> struct omap_dss_output *out = dssdev->output;
>
> - mgr = omap_dss_get_overlay_manager(dssdev->channel);
> + mgr = omap_dss_get_overlay_manager(out->dispc_channel);
>
> if (!mgr || !out)
> continue;
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index ba9cea7..ec322a7 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -547,6 +547,9 @@ struct omap_dss_output {
> /* display type supported by the output */
> enum omap_display_type type;
>
> + /* DISPC channel for this output */
> + enum omap_channel dispc_channel;
> +
> /* output instance */
> enum omap_dss_output_id id;
>
>
>
^ permalink raw reply
* Re: [PATCH linux-next] mfd: max8925: max8925_backlight_probe: Silence 'statement with no effect' war
From: Arnd Bergmann @ 2013-03-11 15:29 UTC (permalink / raw)
To: Tim Gardner
Cc: linux-kernel, Richard Purdie, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <1362939145-88329-1-git-send-email-tim.gardner@canonical.com>
On Sunday 10 March 2013, Tim Gardner wrote:
> drivers/video/backlight/max8925_bl.c: In function 'max8925_backlight_probe':
> drivers/video/backlight/max8925_bl.c:177:3: warning: statement with no effect [-Wunused-value]
>
> gcc version 4.6.3
>
> Convert max8925_backlight_dt_init() to an 'inline void' since it is only
> called from one place where the return code is ignored. Protect the
> guts of the function with '#ifdef CONFIG_OF'.
>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> ---
> drivers/video/backlight/max8925_bl.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
I had already sent a better patch for this earlier, see "mfd: max8925:
fix trivial build warning for non-dt". Unfortunately when I looked into
the problem again, I found more problems with the original patches,
apparently the DT bindings were never properly reviewed. It may be
better to revert the original patch for 3.9 and do it better for 3.10.
Arnd
^ 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