* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tony Lindgren @ 2012-05-09 23:37 UTC (permalink / raw)
To: Russ Dill; +Cc: linux-omap, linux-fbdev, Tomi Valkeinen
In-Reply-To: <CA+Bv8Xa+1RJ5QTn=vO4GSw1VtUZc3xX0J5qBVshvV5Dj+9uZVA@mail.gmail.com>
* Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
> >> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> >> an I2C attached chip which means setting the GPIO can sleep. Code that
> >> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
> >
> > What's the error without this patch? Or just no display?
> >
> > Just wondering if it's safe to merge Tomi's clean up series to
> > arm-soc tree..
>
> The only platform that has a problem is Beagleboard xM, and that is
> only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
> Since the context actually can sleep, the only consequence is a
> WARN_ON statement.
>
> So yes, it should be safe.
Well since I have not actually merged it with other branches yet, I'll wait
for Tomi to apply that and repull his for-l-o-3.5 branch.
Tony
^ permalink raw reply
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Russ Dill @ 2012-05-09 22:50 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev
In-Reply-To: <20120509221447.GY5088@atomide.com>
On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
>> The Beagleboard xM gpio used for TFP410 powerdown is connected through
>> an I2C attached chip which means setting the GPIO can sleep. Code that
>> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
>
> What's the error without this patch? Or just no display?
>
> Just wondering if it's safe to merge Tomi's clean up series to
> arm-soc tree..
The only platform that has a problem is Beagleboard xM, and that is
only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
Since the context actually can sleep, the only consequence is a
WARN_ON statement.
So yes, it should be safe.
>> Signed-off-by: Russ Dill <Russ.Dill@ti.com>
>> ---
>> drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
>> index 52637fa..1266520 100644
>> --- a/drivers/video/omap2/displays/panel-tfp410.c
>> +++ b/drivers/video/omap2/displays/panel-tfp410.c
>> @@ -68,7 +68,7 @@ static int tfp410_power_on(struct omap_dss_device *dssdev)
>> goto err0;
>>
>> if (gpio_is_valid(ddata->pd_gpio))
>> - gpio_set_value(ddata->pd_gpio, 1);
>> + gpio_set_value_cansleep(ddata->pd_gpio, 1);
>>
>> return 0;
>> err0:
>> @@ -83,7 +83,7 @@ static void tfp410_power_off(struct omap_dss_device *dssdev)
>> return;
>>
>> if (gpio_is_valid(ddata->pd_gpio))
>> - gpio_set_value(ddata->pd_gpio, 0);
>> + gpio_set_value_cansleep(ddata->pd_gpio, 0);
>>
>> omapdss_dpi_display_disable(dssdev);
>> }
>> --
>> 1.7.10
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tony Lindgren @ 2012-05-09 22:14 UTC (permalink / raw)
To: Russ Dill; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336601288-27848-1-git-send-email-Russ.Dill@ti.com>
* Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> an I2C attached chip which means setting the GPIO can sleep. Code that
> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
What's the error without this patch? Or just no display?
Just wondering if it's safe to merge Tomi's clean up series to
arm-soc tree..
Tony
> Signed-off-by: Russ Dill <Russ.Dill@ti.com>
> ---
> drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
> index 52637fa..1266520 100644
> --- a/drivers/video/omap2/displays/panel-tfp410.c
> +++ b/drivers/video/omap2/displays/panel-tfp410.c
> @@ -68,7 +68,7 @@ static int tfp410_power_on(struct omap_dss_device *dssdev)
> goto err0;
>
> if (gpio_is_valid(ddata->pd_gpio))
> - gpio_set_value(ddata->pd_gpio, 1);
> + gpio_set_value_cansleep(ddata->pd_gpio, 1);
>
> return 0;
> err0:
> @@ -83,7 +83,7 @@ static void tfp410_power_off(struct omap_dss_device *dssdev)
> return;
>
> if (gpio_is_valid(ddata->pd_gpio))
> - gpio_set_value(ddata->pd_gpio, 0);
> + gpio_set_value_cansleep(ddata->pd_gpio, 0);
>
> omapdss_dpi_display_disable(dssdev);
> }
> --
> 1.7.10
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Russ Dill @ 2012-05-09 22:08 UTC (permalink / raw)
To: linux-omap; +Cc: linux-fbdev, Russ Dill
The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
---
drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index 52637fa..1266520 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -68,7 +68,7 @@ static int tfp410_power_on(struct omap_dss_device *dssdev)
goto err0;
if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value(ddata->pd_gpio, 1);
+ gpio_set_value_cansleep(ddata->pd_gpio, 1);
return 0;
err0:
@@ -83,7 +83,7 @@ static void tfp410_power_off(struct omap_dss_device *dssdev)
return;
if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value(ddata->pd_gpio, 0);
+ gpio_set_value_cansleep(ddata->pd_gpio, 0);
omapdss_dpi_display_disable(dssdev);
}
--
1.7.10
^ permalink raw reply related
* Re: [PATCH 01/25] OMAPDSS: panel-dvi: add PD gpio handling
From: Tomi Valkeinen @ 2012-05-09 17:32 UTC (permalink / raw)
To: Russ Dill; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <CA+Bv8XZSpBJ4_DD=uTkX1zD+Hj31MehCVATjNKo0Bo4aHUfnNA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]
On Wed, 2012-05-09 at 09:50 -0700, Russ Dill wrote:
> On Thu, May 3, 2012 at 6:57 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > The driver for the TFP410 chip should handle the power-down signal of
> > the chip, instead of the current way of handling it in the board files.
> >
> > This patch adds power_down_gpio into the device's platform data, and
> > adds the necessary code in the driver to request and handle the GPIO.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > ---
> > drivers/video/omap2/displays/panel-dvi.c | 31 ++++++++++++++++++++++++++++++
> > include/video/omap-panel-dvi.h | 2 ++
> > 2 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/video/omap2/displays/panel-dvi.c b/drivers/video/omap2/displays/panel-dvi.c
> > index 03eb14a..876b798 100644
> > --- a/drivers/video/omap2/displays/panel-dvi.c
> > +++ b/drivers/video/omap2/displays/panel-dvi.c
> > @@ -21,6 +21,7 @@
> > #include <linux/slab.h>
> > #include <video/omapdss.h>
> > #include <linux/i2c.h>
> > +#include <linux/gpio.h>
> > #include <drm/drm_edid.h>
> >
> > #include <video/omap-panel-dvi.h>
> > @@ -44,6 +45,8 @@ struct panel_drv_data {
> > struct omap_dss_device *dssdev;
> >
> > struct mutex lock;
> > +
> > + int pd_gpio;
> > };
> >
> > static inline struct panel_dvi_platform_data
> > @@ -54,6 +57,7 @@ static inline struct panel_dvi_platform_data
> >
> > static int panel_dvi_power_on(struct omap_dss_device *dssdev)
> > {
> > + struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> > struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
> > int r;
> >
> > @@ -70,6 +74,9 @@ static int panel_dvi_power_on(struct omap_dss_device *dssdev)
> > goto err1;
> > }
> >
> > + if (gpio_is_valid(ddata->pd_gpio))
> > + gpio_set_value(ddata->pd_gpio, 1);
> > +
>
> On Beagleboard xM, this GPIO is connected though an I2C chip so it
> sleeps. Can you change these to gpio_set_value_cansleep?
This patch has already been applied, so we have to do follow up patches
for this. I can look at this tomorrow, but if you update your "ARM:
OMAP: Cleanup Beagleboard DVI reset gpio" patch, will you take a look at
this also?
The applied patches can be found from here, so the follow up patches
should be based on this: git://gitorious.org/linux-omap-dss2/linux.git
for-l-o-3.5
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 01/25] OMAPDSS: panel-dvi: add PD gpio handling
From: Russ Dill @ 2012-05-09 16:50 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1336053481-25433-2-git-send-email-tomi.valkeinen@ti.com>
On Thu, May 3, 2012 at 6:57 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> The driver for the TFP410 chip should handle the power-down signal of
> the chip, instead of the current way of handling it in the board files.
>
> This patch adds power_down_gpio into the device's platform data, and
> adds the necessary code in the driver to request and handle the GPIO.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/displays/panel-dvi.c | 31 ++++++++++++++++++++++++++++++
> include/video/omap-panel-dvi.h | 2 ++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/video/omap2/displays/panel-dvi.c b/drivers/video/omap2/displays/panel-dvi.c
> index 03eb14a..876b798 100644
> --- a/drivers/video/omap2/displays/panel-dvi.c
> +++ b/drivers/video/omap2/displays/panel-dvi.c
> @@ -21,6 +21,7 @@
> #include <linux/slab.h>
> #include <video/omapdss.h>
> #include <linux/i2c.h>
> +#include <linux/gpio.h>
> #include <drm/drm_edid.h>
>
> #include <video/omap-panel-dvi.h>
> @@ -44,6 +45,8 @@ struct panel_drv_data {
> struct omap_dss_device *dssdev;
>
> struct mutex lock;
> +
> + int pd_gpio;
> };
>
> static inline struct panel_dvi_platform_data
> @@ -54,6 +57,7 @@ static inline struct panel_dvi_platform_data
>
> static int panel_dvi_power_on(struct omap_dss_device *dssdev)
> {
> + struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
> int r;
>
> @@ -70,6 +74,9 @@ static int panel_dvi_power_on(struct omap_dss_device *dssdev)
> goto err1;
> }
>
> + if (gpio_is_valid(ddata->pd_gpio))
> + gpio_set_value(ddata->pd_gpio, 1);
> +
On Beagleboard xM, this GPIO is connected though an I2C chip so it
sleeps. Can you change these to gpio_set_value_cansleep?
> return 0;
> err1:
> omapdss_dpi_display_disable(dssdev);
> @@ -79,11 +86,15 @@ err0:
>
> static void panel_dvi_power_off(struct omap_dss_device *dssdev)
> {
> + struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
>
> if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
> return;
>
> + if (gpio_is_valid(ddata->pd_gpio))
> + gpio_set_value(ddata->pd_gpio, 0);
> +
Same with this one.
> if (pdata->platform_disable)
> pdata->platform_disable(dssdev);
>
> @@ -92,7 +103,9 @@ static void panel_dvi_power_off(struct omap_dss_device *dssdev)
>
> static int panel_dvi_probe(struct omap_dss_device *dssdev)
> {
> + struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
> struct panel_drv_data *ddata;
> + int r;
>
> ddata = kzalloc(sizeof(*ddata), GFP_KERNEL);
> if (!ddata)
> @@ -104,6 +117,21 @@ static int panel_dvi_probe(struct omap_dss_device *dssdev)
> ddata->dssdev = dssdev;
> mutex_init(&ddata->lock);
>
> + if (pdata)
> + ddata->pd_gpio = pdata->power_down_gpio;
> + else
> + ddata->pd_gpio = -1;
> +
> + if (gpio_is_valid(ddata->pd_gpio)) {
> + r = gpio_request_one(ddata->pd_gpio, GPIOF_OUT_INIT_LOW,
> + "tfp410 pd");
> + if (r) {
> + dev_err(&dssdev->dev, "Failed to request PD GPIO %d\n",
> + ddata->pd_gpio);
> + ddata->pd_gpio = -1;
> + }
> + }
> +
> dev_set_drvdata(&dssdev->dev, ddata);
>
> return 0;
> @@ -115,6 +143,9 @@ static void __exit panel_dvi_remove(struct omap_dss_device *dssdev)
>
> mutex_lock(&ddata->lock);
>
> + if (gpio_is_valid(ddata->pd_gpio))
> + gpio_free(ddata->pd_gpio);
> +
> dev_set_drvdata(&dssdev->dev, NULL);
>
> mutex_unlock(&ddata->lock);
> diff --git a/include/video/omap-panel-dvi.h b/include/video/omap-panel-dvi.h
> index 87ad567b..4ad41fc 100644
> --- a/include/video/omap-panel-dvi.h
> +++ b/include/video/omap-panel-dvi.h
> @@ -27,11 +27,13 @@ struct omap_dss_device;
> * @platform_enable: platform specific panel enable function
> * @platform_disable: platform specific panel disable function
> * @i2c_bus_num: i2c bus id for the panel
> + * @power_down_gpio: gpio number for PD pin (or -1 if not available)
> */
> struct panel_dvi_platform_data {
> int (*platform_enable)(struct omap_dss_device *dssdev);
> void (*platform_disable)(struct omap_dss_device *dssdev);
> u16 i2c_bus_num;
> + int power_down_gpio;
> };
>
> #endif /* __OMAP_PANEL_DVI_H */
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
From: Tony Lindgren @ 2012-05-09 15:45 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1336550949.3962.2.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120509 01:12]:
>
> Below is the pull request for board file related changes. Tested on
> panda & 4430sdp.
Thanks, I've merged that into clenaup-dss branch and will send it
along with other still pending cleanup branches.
> How should I manage my tree related to this... Should I rebase my
> original DT preparation series on top of this new branch, or can I just
> ignore the new branch for now, as long as I merge it at some point
> before sending a pull request to mainline?
Yes you need to rebase on this now. And not touch these commits.
Otherwise we'll end up with duplicate commits in the mainline tree,
which is a big no-no. If something shows up that needs fixing in this
series, it must now be separate patches on top of this series.
When doing pull requests we both just have to make note that there's
a dependency to this branch, and it will find it's way to mainline
via arm-soc pull request. Or if no conflicts need sorting out, then
it will just get merged with your pull request.
Regards,
Tony
> Tomi
>
> The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
>
> Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-omap-dss2/linux.git for-l-o-3.5
>
> for you to fetch changes up to e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07:
>
> OMAPDSS: DSI: implement generic DSI pin config (2012-05-09 10:53:05 +0300)
>
> ----------------------------------------------------------------
> Tomi Valkeinen (6):
> OMAPDSS: panel-dvi: add PD gpio handling
> OMAP: board-files: remove custom PD GPIO handling for DVI output
> OMAPDSS: TFP410: rename dvi -> tfp410
> OMAPDSS: TFP410: rename dvi files to tfp410
> OMAPDSS: Taal: move reset gpio handling to taal driver
> OMAPDSS: DSI: implement generic DSI pin config
>
> arch/arm/mach-omap2/board-3430sdp.c | 38 +-----
> arch/arm/mach-omap2/board-4430sdp.c | 37 ++----
> arch/arm/mach-omap2/board-am3517evm.c | 25 +---
> arch/arm/mach-omap2/board-cm-t35.c | 30 +----
> arch/arm/mach-omap2/board-devkit8000.c | 30 +----
> arch/arm/mach-omap2/board-igep0020.c | 32 +----
> arch/arm/mach-omap2/board-omap3beagle.c | 37 +-----
> arch/arm/mach-omap2/board-omap3evm.c | 29 +----
> arch/arm/mach-omap2/board-omap3stalker.c | 29 +----
> arch/arm/mach-omap2/board-omap4panda.c | 39 +-----
> arch/arm/mach-omap2/board-overo.c | 25 +---
> drivers/video/omap2/displays/Kconfig | 8 +-
> drivers/video/omap2/displays/Makefile | 2 +-
> drivers/video/omap2/displays/panel-taal.c | 22 ++++
> .../omap2/displays/{panel-dvi.c => panel-tfp410.c} | 134 +++++++++++---------
> drivers/video/omap2/dss/dsi.c | 133 +++++++++----------
> include/video/omap-panel-nokia-dsi.h | 3 +
> .../{omap-panel-dvi.h => omap-panel-tfp410.h} | 18 ++-
> include/video/omapdss.h | 28 ++--
> 19 files changed, 251 insertions(+), 448 deletions(-)
> rename drivers/video/omap2/displays/{panel-dvi.c => panel-tfp410.c} (63%)
> rename include/video/{omap-panel-dvi.h => omap-panel-tfp410.h} (63%)
>
^ permalink raw reply
* Re: [PATCH v2 1/4] mfd: add LM3533 lighting-power core driver
From: Samuel Ortiz @ 2012-05-09 14:42 UTC (permalink / raw)
To: Johan Hovold
Cc: Rob Landley, Richard Purdie, Jonathan Cameron, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Andrew Morton,
Mark Brown, linux-doc, linux-kernel, linux-iio, devel,
linux-fbdev
In-Reply-To: <1336040799-18433-2-git-send-email-jhovold@gmail.com>
Hi Johan
On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
> Add support for National Semiconductor / TI LM3533 lighting power chips.
>
> This is the core driver which provides register access over I2C and
> registers the ambient-light-sensor, LED and backlight sub-drivers.
>
> Signed-off-by: Johan Hovold <jhovold@gmail.com>
> ---
>
> v2:
> - add sysfs-ABI documentation
> - merge i2c implementation with core
> - use regmap and kill custom debugfs interface
>
>
> .../ABI/testing/sysfs-bus-i2c-devices-lm3533 | 38 +
> drivers/mfd/Kconfig | 13 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/lm3533-core.c | 717 ++++++++++++++++++++
> drivers/mfd/lm3533-ctrlbank.c | 134 ++++
> include/linux/mfd/lm3533.h | 89 +++
> 6 files changed, 992 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
> create mode 100644 drivers/mfd/lm3533-core.c
> create mode 100644 drivers/mfd/lm3533-ctrlbank.c
> create mode 100644 include/linux/mfd/lm3533.h
Patch applied to my for-next branch, thanks.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
From: Tomi Valkeinen @ 2012-05-09 11:51 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FAA53EA.7040400@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
On Wed, 2012-05-09 at 16:54 +0530, Archit Taneja wrote:
> On Wednesday 09 May 2012 04:43 PM, Tomi Valkeinen wrote:
> > On Wed, 2012-05-09 at 15:40 +0530, Archit Taneja wrote:
> >> An overlay manager's timings (the manager size, and blanking parameters if an
> >> LCD manager) are DISPC shadow registers, and they should hence follow the
> >> correct programming model.
> >>
> >> This set makes the timings an extra_info parameter in manager's private data .
> >> The interface drivers now apply the timings in instead of directly writing to
> >> registers.
> >>
> >> This change also prevents the need to use display resolution for overlay
> >> checks, hence making some of the APPLY functions less dependent on the display.
> >> Some DISPC functions that needed display width can also use these privately
> >> stored timings.
> >>
> >> Changes since v3:
> >>
> >> - Remove direct setting of go bit in dpi_set_timings()
> >> - Take some of the patches in "OMAPDSS: Misc fixes and cleanups" and make them a
> >> part of this series as they are more related.
> >> - Don't have an initial set of manager timings in private data, only check
> >> manager and overlay parameters once the manager is enabled.
> >>
> >> These patches apply over:
> >>
> >> git://gitorious.org/linux-omap-dss2/linux.git dev
> >>
> >> Reference tree containing this series:
> >>
> >> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2
> >>
> >> Tested on OMAP4 SDP and Panda.
> >
> > I did some quick tests on omap3 overo, worked fine. I'll merge to dss
> > master branch.
>
> Russ did some tests on more omap3 boards, the tree which he used has
> some slight changes comapred to what I have posted, but it's more or
> less the same.
>
> Could you add 'Tested-by: Russ.Dill@ti.com' if not too difficult, I
> missed out doing that.
Sorry, I could, but I already merged and pushed the series, so I can't
change it anymore.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
From: Archit Taneja @ 2012-05-09 11:36 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336561991.3962.31.camel@deskari>
On Wednesday 09 May 2012 04:43 PM, Tomi Valkeinen wrote:
> On Wed, 2012-05-09 at 15:40 +0530, Archit Taneja wrote:
>> An overlay manager's timings (the manager size, and blanking parameters if an
>> LCD manager) are DISPC shadow registers, and they should hence follow the
>> correct programming model.
>>
>> This set makes the timings an extra_info parameter in manager's private data .
>> The interface drivers now apply the timings in instead of directly writing to
>> registers.
>>
>> This change also prevents the need to use display resolution for overlay
>> checks, hence making some of the APPLY functions less dependent on the display.
>> Some DISPC functions that needed display width can also use these privately
>> stored timings.
>>
>> Changes since v3:
>>
>> - Remove direct setting of go bit in dpi_set_timings()
>> - Take some of the patches in "OMAPDSS: Misc fixes and cleanups" and make them a
>> part of this series as they are more related.
>> - Don't have an initial set of manager timings in private data, only check
>> manager and overlay parameters once the manager is enabled.
>>
>> These patches apply over:
>>
>> git://gitorious.org/linux-omap-dss2/linux.git dev
>>
>> Reference tree containing this series:
>>
>> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2
>>
>> Tested on OMAP4 SDP and Panda.
>
> I did some quick tests on omap3 overo, worked fine. I'll merge to dss
> master branch.
Russ did some tests on more omap3 boards, the tree which he used has
some slight changes comapred to what I have posted, but it's more or
less the same.
Could you add 'Tested-by: Russ.Dill@ti.com' if not too difficult, I
missed out doing that.
Thanks,
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
From: Tomi Valkeinen @ 2012-05-09 11:13 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
On Wed, 2012-05-09 at 15:40 +0530, Archit Taneja wrote:
> An overlay manager's timings (the manager size, and blanking parameters if an
> LCD manager) are DISPC shadow registers, and they should hence follow the
> correct programming model.
>
> This set makes the timings an extra_info parameter in manager's private data .
> The interface drivers now apply the timings in instead of directly writing to
> registers.
>
> This change also prevents the need to use display resolution for overlay
> checks, hence making some of the APPLY functions less dependent on the display.
> Some DISPC functions that needed display width can also use these privately
> stored timings.
>
> Changes since v3:
>
> - Remove direct setting of go bit in dpi_set_timings()
> - Take some of the patches in "OMAPDSS: Misc fixes and cleanups" and make them a
> part of this series as they are more related.
> - Don't have an initial set of manager timings in private data, only check
> manager and overlay parameters once the manager is enabled.
>
> These patches apply over:
>
> git://gitorious.org/linux-omap-dss2/linux.git dev
>
> Reference tree containing this series:
>
> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2
>
> Tested on OMAP4 SDP and Panda.
I did some quick tests on omap3 overo, worked fine. I'll merge to dss
master branch.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH v4 9/9] OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
The functions calc_fclk_five_taps() and check_horiz_timing_omap3() use the
function dispc_mgr_get_device() to get the omap_dss_device pointer to which
the manager is connected, the width of the panel is derived from it.
The manager's timing is stored in it's private data in APPLY. This contains
the latest timings applied to the manager. Pass these timings to
dispc_ovl_setup() and use them in the above functions. Remove the function
dispc_mgr_get_device() as it isn't used any more.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/apply.c | 6 ++--
drivers/video/omap2/dss/dispc.c | 51 +++++++++++++++++---------------------
drivers/video/omap2/dss/dss.h | 3 +-
3 files changed, 28 insertions(+), 32 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 15c070c..dd88b8f 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -548,11 +548,13 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
oi = &op->info;
+ mp = get_mgr_priv(ovl->manager);
+
replication = dss_use_replication(ovl->manager->device, oi->color_mode);
ilace = ovl->manager->device->type = OMAP_DISPLAY_TYPE_VENC;
- r = dispc_ovl_setup(ovl->id, oi, ilace, replication);
+ r = dispc_ovl_setup(ovl->id, oi, ilace, replication, &mp->timings);
if (r) {
/*
* We can't do much here, as this function can be called from
@@ -566,8 +568,6 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
return;
}
- mp = get_mgr_priv(ovl->manager);
-
op->info_dirty = false;
if (mp->updating)
op->shadow_info_dirty = true;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index cd0a397..727e15b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -413,14 +413,6 @@ static inline bool dispc_mgr_is_lcd(enum omap_channel channel)
return false;
}
-static struct omap_dss_device *dispc_mgr_get_device(enum omap_channel channel)
-{
- struct omap_overlay_manager *mgr - omap_dss_get_overlay_manager(channel);
-
- return mgr ? mgr->device : NULL;
-}
-
u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
{
switch (channel) {
@@ -1661,18 +1653,17 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
* This function is used to avoid synclosts in OMAP3, because of some
* undocumented horizontal position and timing related limitations.
*/
-static int check_horiz_timing_omap3(enum omap_channel channel, u16 pos_x,
+static int check_horiz_timing_omap3(enum omap_channel channel,
+ const struct omap_video_timings *t, u16 pos_x,
u16 width, u16 height, u16 out_width, u16 out_height)
{
int DS = DIV_ROUND_UP(height, out_height);
- struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
- struct omap_video_timings t = dssdev->panel.timings;
unsigned long nonactive, lclk, pclk;
static const u8 limits[3] = { 8, 10, 20 };
u64 val, blank;
int i;
- nonactive = t.x_res + t.hfp + t.hsw + t.hbp - out_width;
+ nonactive = t->x_res + t->hfp + t->hsw + t->hbp - out_width;
pclk = dispc_mgr_pclk_rate(channel);
if (dispc_mgr_is_lcd(channel))
lclk = dispc_mgr_lclk_rate(channel);
@@ -1684,7 +1675,7 @@ static int check_horiz_timing_omap3(enum omap_channel channel, u16 pos_x,
i++;
if (out_width < width)
i++;
- blank = div_u64((u64)(t.hbp + t.hsw + t.hfp) * lclk, pclk);
+ blank = div_u64((u64)(t->hbp + t->hsw + t->hfp) * lclk, pclk);
DSSDBG("blanking period + ppl = %llu (limit = %u)\n", blank, limits[i]);
if (blank <= limits[i])
return -EINVAL;
@@ -1715,7 +1706,8 @@ static int check_horiz_timing_omap3(enum omap_channel channel, u16 pos_x,
}
static unsigned long calc_core_clk_five_taps(enum omap_channel channel,
- u16 width, u16 height, u16 out_width, u16 out_height,
+ const struct omap_video_timings *mgr_timings, u16 width,
+ u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode)
{
u32 core_clk = 0;
@@ -1725,8 +1717,7 @@ static unsigned long calc_core_clk_five_taps(enum omap_channel channel,
return (unsigned long) pclk;
if (height > out_height) {
- struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
- unsigned int ppl = dssdev->panel.timings.x_res;
+ unsigned int ppl = mgr_timings->x_res;
tmp = pclk * height * out_width;
do_div(tmp, 2 * out_height * ppl);
@@ -1795,8 +1786,9 @@ static unsigned long calc_core_clk(enum omap_channel channel, u16 width,
}
static int dispc_ovl_calc_scaling(enum omap_plane plane,
- enum omap_channel channel, u16 width, u16 height,
- u16 out_width, u16 out_height,
+ enum omap_channel channel,
+ const struct omap_video_timings *mgr_timings,
+ u16 width, u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
int *x_predecim, int *y_predecim, u16 pos_x)
{
@@ -1871,11 +1863,13 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
do {
in_height = DIV_ROUND_UP(height, decim_y);
in_width = DIV_ROUND_UP(width, decim_x);
- core_clk = calc_core_clk_five_taps(channel, in_width,
- in_height, out_width, out_height, color_mode);
+ core_clk = calc_core_clk_five_taps(channel, mgr_timings,
+ in_width, in_height, out_width, out_height,
+ color_mode);
- error = check_horiz_timing_omap3(channel, pos_x,
- in_width, in_height, out_width, out_height);
+ error = check_horiz_timing_omap3(channel, mgr_timings,
+ pos_x, in_width, in_height, out_width,
+ out_height);
if (in_width > maxsinglelinewidth)
if (in_height > out_height &&
@@ -1900,8 +1894,8 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
} while (decim_x <= *x_predecim && decim_y <= *y_predecim
&& error);
- if (check_horiz_timing_omap3(channel, pos_x, width, height,
- out_width, out_height)){
+ if (check_horiz_timing_omap3(channel, mgr_timings, pos_x, width,
+ height, out_width, out_height)){
DSSERR("horizontal timing too tight\n");
return -EINVAL;
}
@@ -1959,7 +1953,8 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
}
int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
- bool ilace, bool replication)
+ bool ilace, bool replication,
+ const struct omap_video_timings *mgr_timings)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
bool five_taps = true;
@@ -2008,9 +2003,9 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
if (!dss_feat_color_mode_supported(plane, oi->color_mode))
return -EINVAL;
- r = dispc_ovl_calc_scaling(plane, channel, in_width, in_height,
- out_width, out_height, oi->color_mode, &five_taps,
- &x_predecim, &y_predecim, oi->pos_x);
+ r = dispc_ovl_calc_scaling(plane, channel, mgr_timings, in_width,
+ in_height, out_width, out_height, oi->color_mode,
+ &five_taps, &x_predecim, &y_predecim, oi->pos_x);
if (r)
return r;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index f3fa445..8e9e9a5 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -428,7 +428,8 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high);
void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
u32 *fifo_low, u32 *fifo_high, bool use_fifomerge);
int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
- bool ilace, bool replication);
+ bool ilace, bool replication,
+ const struct omap_video_timings *mgr_timings);
int dispc_ovl_enable(enum omap_plane plane, bool enable);
void dispc_ovl_set_channel_out(enum omap_plane plane,
enum omap_channel channel);
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 8/9] OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate()
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
The pixel clock rate for the TV manager is calculated by checking the device
type connected to the manager, and then requesting the VENC/HDMI interface for
the pixel clock rate.
Remove the use of omap_dss_device pointer from here by checking which interface
generates the pixel clock by reading the DSS_CTRL.VENC_HDMI_SWITCH bit.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 6eec084..cd0a397 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2643,13 +2643,14 @@ unsigned long dispc_mgr_pclk_rate(enum omap_channel channel)
return r / pcd;
} else {
- struct omap_dss_device *dssdev - dispc_mgr_get_device(channel);
+ enum dss_hdmi_venc_clk_source_select source;
- switch (dssdev->type) {
- case OMAP_DISPLAY_TYPE_VENC:
+ source = dss_get_hdmi_venc_clk_source();
+
+ switch (source) {
+ case DSS_VENC_TV_CLK:
return venc_get_pixel_clock();
- case OMAP_DISPLAY_TYPE_HDMI:
+ case DSS_HDMI_M_PCLK:
return hdmi_get_pixel_clock();
default:
BUG();
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 7/9] OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
The omap_dss_device pointer declared in dss_ovl_setup_fifo() isn't used. Remove
the pointer variable declaration and it's assignment.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/apply.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 0ffe4e1..15c070c 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -960,14 +960,11 @@ static void dss_ovl_setup_fifo(struct omap_overlay *ovl,
bool use_fifo_merge)
{
struct ovl_priv_data *op = get_ovl_priv(ovl);
- struct omap_dss_device *dssdev;
u32 fifo_low, fifo_high;
if (!op->enabled && !op->enabling)
return;
- dssdev = ovl->manager->device;
-
dispc_ovl_compute_fifo_thresholds(ovl->id, &fifo_low, &fifo_high,
use_fifo_merge);
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 6/9] OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
The DPI and HDMI interfaces use their 'set_timing' functions to take in a new
set of timings. If the panel is disabled, they do not disable and re-enable
the interface. Currently, the manager timings are applied in hdmi_power_on()
and dpi_set_mode() respectively, these are not called by set_timings if the
panel is disabled.
When checking overlay and manager data, the DSS driver uses the last applied
manager timings, and not the timings held by omap_dss_device struct. Hence,
there is a need to apply the new manager timings even if the panel is disabled.
Apply the manager timings if the panel is disabled. Eventually, there should be
one common place where the timings are applied independent of the state of the
panel.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dpi.c | 2 ++
drivers/video/omap2/dss/hdmi.c | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e01ab98..d6e8fe7 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -297,6 +297,8 @@ void dpi_set_timings(struct omap_dss_device *dssdev,
dispc_runtime_put();
dss_runtime_put();
+ } else {
+ dss_mgr_set_timings(dssdev->manager, timings);
}
}
EXPORT_SYMBOL(dpi_set_timings);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8d4ff8c..32ad712 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -435,6 +435,8 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device *dssdev)
r = hdmi_power_on(dssdev);
if (r)
DSSERR("failed to power on device\n");
+ } else {
+ dss_mgr_set_timings(dssdev->manager, &dssdev->panel.timings);
}
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 5/9] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.
Pass the manager's timings in private data to dss_mgr_check(). Remove the need
to pass omap_dss_device structs in the functions which check for the validity
of overlay and manager parameters.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/apply.c | 24 +++++++++++-------------
drivers/video/omap2/dss/dss.h | 7 ++++---
drivers/video/omap2/dss/manager.c | 6 +++---
drivers/video/omap2/dss/overlay.c | 10 ++++------
4 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index ad349b3..0ffe4e1 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -181,7 +181,7 @@ static bool mgr_manual_update(struct omap_overlay_manager *mgr)
}
static int dss_check_settings_low(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev, bool applying)
+ bool applying)
{
struct omap_overlay_info *oi;
struct omap_overlay_manager_info *mi;
@@ -214,26 +214,24 @@ static int dss_check_settings_low(struct omap_overlay_manager *mgr,
ois[ovl->id] = oi;
}
- return dss_mgr_check(mgr, dssdev, mi, ois);
+ return dss_mgr_check(mgr, mi, &mp->timings, ois);
}
/*
* check manager and overlay settings using overlay_info from data->info
*/
-static int dss_check_settings(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev)
+static int dss_check_settings(struct omap_overlay_manager *mgr)
{
- return dss_check_settings_low(mgr, dssdev, false);
+ return dss_check_settings_low(mgr, false);
}
/*
* check manager and overlay settings using overlay_info from ovl->info if
* dirty and from data->info otherwise
*/
-static int dss_check_settings_apply(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev)
+static int dss_check_settings_apply(struct omap_overlay_manager *mgr)
{
- return dss_check_settings_low(mgr, dssdev, true);
+ return dss_check_settings_low(mgr, true);
}
static bool need_isr(void)
@@ -687,7 +685,7 @@ static void dss_write_regs(void)
if (!mp->enabled || mgr_manual_update(mgr) || mp->busy)
continue;
- r = dss_check_settings(mgr, mgr->device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR("cannot write registers for manager %s: "
"illegal configuration\n", mgr->name);
@@ -754,7 +752,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr)
WARN_ON(mp->updating);
- r = dss_check_settings(mgr, mgr->device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR("cannot start manual update: illegal configuration\n");
spin_unlock_irqrestore(&data_lock, flags);
@@ -901,7 +899,7 @@ int omap_dss_mgr_apply(struct omap_overlay_manager *mgr)
spin_lock_irqsave(&data_lock, flags);
- r = dss_check_settings_apply(mgr, mgr->device);
+ r = dss_check_settings_apply(mgr);
if (r) {
spin_unlock_irqrestore(&data_lock, flags);
DSSERR("failed to apply settings: illegal configuration.\n");
@@ -1094,7 +1092,7 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr)
mp->enabled = true;
- r = dss_check_settings(mgr, mgr->device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR("failed to enable manager %d: check_settings failed\n",
mgr->id);
@@ -1466,7 +1464,7 @@ int dss_ovl_enable(struct omap_overlay *ovl)
op->enabling = true;
- r = dss_check_settings(ovl->manager, ovl->manager->device);
+ r = dss_check_settings(ovl->manager);
if (r) {
DSSERR("failed to enable overlay %d: check_settings failed\n",
ovl->id);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index a13b305..f3fa445 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -179,6 +179,7 @@ int dss_mgr_set_device(struct omap_overlay_manager *mgr,
int dss_mgr_unset_device(struct omap_overlay_manager *mgr);
void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
struct omap_video_timings *timings);
+const struct omap_video_timings *dss_mgr_get_timings(struct omap_overlay_manager *mgr);
bool dss_ovl_is_enabled(struct omap_overlay *ovl);
int dss_ovl_enable(struct omap_overlay *ovl);
@@ -211,8 +212,8 @@ int dss_mgr_simple_check(struct omap_overlay_manager *mgr,
int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
const struct omap_video_timings *timings);
int dss_mgr_check(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
+ const struct omap_video_timings *mgr_timings,
struct omap_overlay_info **overlay_infos);
/* overlay */
@@ -222,8 +223,8 @@ void dss_overlay_setup_dispc_manager(struct omap_overlay_manager *mgr);
void dss_recheck_connections(struct omap_dss_device *dssdev, bool force);
int dss_ovl_simple_check(struct omap_overlay *ovl,
const struct omap_overlay_info *info);
-int dss_ovl_check(struct omap_overlay *ovl,
- struct omap_overlay_info *info, struct omap_dss_device *dssdev);
+int dss_ovl_check(struct omap_overlay *ovl, struct omap_overlay_info *info,
+ const struct omap_video_timings *mgr_timings);
/* DSS */
int dss_init_platform_driver(void);
diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
index 566fbba..0cbcde4 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -666,8 +666,8 @@ int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
}
int dss_mgr_check(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
+ const struct omap_video_timings *mgr_timings,
struct omap_overlay_info **overlay_infos)
{
struct omap_overlay *ovl;
@@ -679,7 +679,7 @@ int dss_mgr_check(struct omap_overlay_manager *mgr,
return r;
}
- r = dss_mgr_check_timings(mgr, &dssdev->panel.timings);
+ r = dss_mgr_check_timings(mgr, mgr_timings);
if (r)
return r;
@@ -692,7 +692,7 @@ int dss_mgr_check(struct omap_overlay_manager *mgr,
if (oi = NULL)
continue;
- r = dss_ovl_check(ovl, oi, dssdev);
+ r = dss_ovl_check(ovl, oi, mgr_timings);
if (r)
return r;
}
diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
index 6e82181..0da5eb6 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -631,16 +631,14 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
return 0;
}
-int dss_ovl_check(struct omap_overlay *ovl,
- struct omap_overlay_info *info, struct omap_dss_device *dssdev)
+int dss_ovl_check(struct omap_overlay *ovl, struct omap_overlay_info *info,
+ const struct omap_video_timings *mgr_timings)
{
u16 outw, outh;
u16 dw, dh;
- if (dssdev = NULL)
- return 0;
-
- dssdev->driver->get_resolution(dssdev, &dw, &dh);
+ dw = mgr_timings->x_res;
+ dh = mgr_timings->y_res;
if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) = 0) {
outw = info->width;
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 4/9] OMAPDSS: APPLY: Don't check manager settings if it is disabled
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
If a manager is disabled, there is no guarantee at any point in time that all
it's parameters are configured. There is always a chance that some more
parameters are yet to be configured by a user of DSS, or by DSS itself.
However, when the manager is enabled, we can be certain that all the parameters
have been configured, as we can't enable a manager with an incomplete
configuration. Therefore, if a manager is disabled, don't check for the validity
of it's parameters or the parameters of the overlays connected to it. Only check
once it is enabled. Add a check in dss_check_settings_low() to achieve the same.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/apply.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 57686f6..ad349b3 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -192,6 +192,9 @@ static int dss_check_settings_low(struct omap_overlay_manager *mgr,
mp = get_mgr_priv(mgr);
+ if (!mp->enabled)
+ return 0;
+
if (applying && mp->user_info_dirty)
mi = &mp->user_info;
else
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 3/9] OMAPDSS: MANAGER: Create a function to check manager timings
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
Create a function dss_mgr_check_timings() which wraps around the function
dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
from interface drivers.
dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
takes the timings maintained in the omap_dss_device struct. This would be later
replaced by the timings stored in the manager's private data.
Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const
omap_video_timings pointer since these functions just check the timings.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 2 +-
drivers/video/omap2/dss/dpi.c | 2 +-
drivers/video/omap2/dss/dss.h | 4 +++-
drivers/video/omap2/dss/manager.c | 15 +++++++++++++++
4 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 82012d1..6eec084 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2479,7 +2479,7 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp, int hbp,
}
bool dispc_mgr_timings_ok(enum omap_channel channel,
- struct omap_video_timings *timings)
+ const struct omap_video_timings *timings)
{
bool timings_ok;
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e65cf1f..e01ab98 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -311,7 +311,7 @@ int dpi_check_timings(struct omap_dss_device *dssdev,
unsigned long pck;
struct dispc_clock_info dispc_cinfo;
- if (!dispc_mgr_timings_ok(dssdev->manager->id, timings))
+ if (dss_mgr_check_timings(dssdev->manager, timings))
return -EINVAL;
if (timings->pixel_clock = 0)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index b17a212..a13b305 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -208,6 +208,8 @@ int dss_init_overlay_managers(struct platform_device *pdev);
void dss_uninit_overlay_managers(struct platform_device *pdev);
int dss_mgr_simple_check(struct omap_overlay_manager *mgr,
const struct omap_overlay_manager_info *info);
+int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
+ const struct omap_video_timings *timings);
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
@@ -413,7 +415,7 @@ void dispc_enable_gamma_table(bool enable);
void dispc_set_loadmode(enum omap_dss_load_mode mode);
bool dispc_mgr_timings_ok(enum omap_channel channel,
- struct omap_video_timings *timings);
+ const struct omap_video_timings *timings);
unsigned long dispc_fclk_rate(void);
void dispc_find_clk_divs(bool is_tft, unsigned long req_pck, unsigned long fck,
struct dispc_clock_info *cinfo);
diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
index e736460..566fbba 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -654,6 +654,17 @@ static int dss_mgr_check_zorder(struct omap_overlay_manager *mgr,
return 0;
}
+int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
+ const struct omap_video_timings *timings)
+{
+ if (!dispc_mgr_timings_ok(mgr->id, timings)) {
+ DSSERR("check_manager: invalid timings\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
@@ -668,6 +679,10 @@ int dss_mgr_check(struct omap_overlay_manager *mgr,
return r;
}
+ r = dss_mgr_check_timings(mgr, &dssdev->panel.timings);
+ if (r)
+ return r;
+
list_for_each_entry(ovl, &mgr->overlays, list) {
struct omap_overlay_info *oi;
int r;
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 2/9] OMAPDSS: Apply manager timings instead of direct DISPC writes
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
interface drivers. The latter function ensures that the timing related DISPC
registers are configured according to the shadow register programming model.
Remove the call to dispc_mgr_go() in dpi_set_timings() as the manager's go bit
is now set by dss_mgr_set_timings().
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dpi.c | 3 +--
drivers/video/omap2/dss/dsi.c | 5 ++---
drivers/video/omap2/dss/hdmi.c | 2 +-
drivers/video/omap2/dss/rfbi.c | 4 ++--
drivers/video/omap2/dss/sdi.c | 2 +-
drivers/video/omap2/dss/venc.c | 2 +-
6 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index cec1166..e65cf1f 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -156,7 +156,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
t->pixel_clock = pck;
}
- dispc_mgr_set_timings(dssdev->manager->id, t);
+ dss_mgr_set_timings(dssdev->manager, t);
return 0;
}
@@ -294,7 +294,6 @@ void dpi_set_timings(struct omap_dss_device *dssdev,
}
dpi_set_mode(dssdev);
- dispc_mgr_go(dssdev->manager->id);
dispc_runtime_put();
dss_runtime_put();
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6c4b034..95bc996 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4215,13 +4215,12 @@ static int dsi_display_init_dispc(struct omap_dss_device *dssdev)
dispc_mgr_enable_stallmode(dssdev->manager->id, true);
dispc_mgr_enable_fifohandcheck(dssdev->manager->id, 1);
- dispc_mgr_set_timings(dssdev->manager->id, &timings);
+ dss_mgr_set_timings(dssdev->manager, &timings);
} else {
dispc_mgr_enable_stallmode(dssdev->manager->id, false);
dispc_mgr_enable_fifohandcheck(dssdev->manager->id, 0);
- dispc_mgr_set_timings(dssdev->manager->id,
- &dssdev->panel.timings);
+ dss_mgr_set_timings(dssdev->manager, &dssdev->panel.timings);
}
dispc_mgr_set_lcd_display_type(dssdev->manager->id,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 56f6e9c..8d4ff8c 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -376,7 +376,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
dispc_enable_gamma_table(0);
/* tv size */
- dispc_mgr_set_timings(dssdev->manager->id, &dssdev->panel.timings);
+ dss_mgr_set_timings(dssdev->manager, &dssdev->panel.timings);
hdmi.ip_data.ops->video_enable(&hdmi.ip_data, 1);
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index a81ffcb..feadfab 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -320,7 +320,7 @@ static void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
DSSDBG("rfbi_transfer_area %dx%d\n", width, height);
- dispc_mgr_set_timings(dssdev->manager->id, &timings);
+ dss_mgr_set_timings(dssdev->manager, &timings);
dispc_mgr_enable(dssdev->manager->id, true);
@@ -804,7 +804,7 @@ int omap_rfbi_prepare_update(struct omap_dss_device *dssdev,
if (*w = 0 || *h = 0)
return -EINVAL;
- dispc_mgr_set_timings(dssdev->manager->id, &timings);
+ dss_mgr_set_timings(dssdev->manager, &timings);
return 0;
}
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 741b834..67fbe7c 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -107,7 +107,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
}
- dispc_mgr_set_timings(dssdev->manager->id, t);
+ dss_mgr_set_timings(dssdev->manager, t);
r = dss_set_clock_div(&dss_cinfo);
if (r)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 6947f5b..9475e6e 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -444,7 +444,7 @@ static int venc_power_on(struct omap_dss_device *dssdev)
timings = dssdev->panel.timings;
timings.y_res /= 2;
- dispc_mgr_set_timings(dssdev->manager->id, &timings);
+ dss_mgr_set_timings(dssdev->manager, &timings);
r = regulator_enable(venc.vdda_dac_reg);
if (r)
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 1/9] OMAPDSS: APPLY: Add manager timings as extra_info in private data
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
DISPC manager size and DISPC manager blanking parameters(for LCD managers)
follow the shadow register programming model. Currently, they are programmed
directly by the interface drivers.
To configure manager timings using APPLY, there is a need to introduce extra
info flags for managers, similar to what is done for overlays. This is needed
because timings aren't a part of overlay_manager_info struct configured by a
user of DSS, they are configured internally by the interface or panel drivers.
Add dirty and shadow_dirty extra_info flags for managers, update these flags
at the appropriate places. Rewrite the function extra_info_update_ongoing()
slightly as checking for manager's extra_info flags can simplify the code a bit.
Create function dss_mgr_set_timings() which applies the new manager timings to
extra_info.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/apply.c | 96 +++++++++++++++++++++++++++++++++-----
drivers/video/omap2/dss/dss.h | 2 +
2 files changed, 85 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index b10b3bc..57686f6 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -99,6 +99,11 @@ struct mgr_priv_data {
/* If true, a display is enabled using this manager */
bool enabled;
+
+ bool extra_info_dirty;
+ bool shadow_extra_info_dirty;
+
+ struct omap_video_timings timings;
};
static struct {
@@ -261,6 +266,20 @@ static bool need_isr(void)
if (mp->shadow_info_dirty)
return true;
+ /*
+ * NOTE: we don't check extra_info flags for disabled
+ * managers, once the manager is enabled, the extra_info
+ * related manager changes will be taken in by HW.
+ */
+
+ /* to write new values to registers */
+ if (mp->extra_info_dirty)
+ return true;
+
+ /* to set GO bit */
+ if (mp->shadow_extra_info_dirty)
+ return true;
+
list_for_each_entry(ovl, &mgr->overlays, list) {
struct ovl_priv_data *op;
@@ -305,7 +324,7 @@ static bool need_go(struct omap_overlay_manager *mgr)
mp = get_mgr_priv(mgr);
- if (mp->shadow_info_dirty)
+ if (mp->shadow_info_dirty || mp->shadow_extra_info_dirty)
return true;
list_for_each_entry(ovl, &mgr->overlays, list) {
@@ -320,20 +339,16 @@ static bool need_go(struct omap_overlay_manager *mgr)
/* returns true if an extra_info field is currently being updated */
static bool extra_info_update_ongoing(void)
{
- const int num_ovls = omap_dss_get_num_overlays();
- struct ovl_priv_data *op;
- struct omap_overlay *ovl;
- struct mgr_priv_data *mp;
+ const int num_mgrs = dss_feat_get_num_mgrs();
int i;
- for (i = 0; i < num_ovls; ++i) {
- ovl = omap_dss_get_overlay(i);
- op = get_ovl_priv(ovl);
-
- if (!ovl->manager)
- continue;
+ for (i = 0; i < num_mgrs; ++i) {
+ struct omap_overlay_manager *mgr;
+ struct omap_overlay *ovl;
+ struct mgr_priv_data *mp;
- mp = get_mgr_priv(ovl->manager);
+ mgr = omap_dss_get_overlay_manager(i);
+ mp = get_mgr_priv(mgr);
if (!mp->enabled)
continue;
@@ -341,8 +356,15 @@ static bool extra_info_update_ongoing(void)
if (!mp->updating)
continue;
- if (op->extra_info_dirty || op->shadow_extra_info_dirty)
+ if (mp->extra_info_dirty || mp->shadow_extra_info_dirty)
return true;
+
+ list_for_each_entry(ovl, &mgr->overlays, list) {
+ struct ovl_priv_data *op = get_ovl_priv(ovl);
+
+ if (op->extra_info_dirty || op->shadow_extra_info_dirty)
+ return true;
+ }
}
return false;
@@ -601,6 +623,22 @@ static void dss_mgr_write_regs(struct omap_overlay_manager *mgr)
}
}
+static void dss_mgr_write_regs_extra(struct omap_overlay_manager *mgr)
+{
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ DSSDBGF("%d", mgr->id);
+
+ if (!mp->extra_info_dirty)
+ return;
+
+ dispc_mgr_set_timings(mgr->id, &mp->timings);
+
+ mp->extra_info_dirty = false;
+ if (mp->updating)
+ mp->shadow_extra_info_dirty = true;
+}
+
static void dss_write_regs_common(void)
{
const int num_mgrs = omap_dss_get_num_overlay_managers();
@@ -654,6 +692,7 @@ static void dss_write_regs(void)
}
dss_mgr_write_regs(mgr);
+ dss_mgr_write_regs_extra(mgr);
}
}
@@ -693,6 +732,7 @@ static void mgr_clear_shadow_dirty(struct omap_overlay_manager *mgr)
mp = get_mgr_priv(mgr);
mp->shadow_info_dirty = false;
+ mp->shadow_extra_info_dirty = false;
list_for_each_entry(ovl, &mgr->overlays, list) {
op = get_ovl_priv(ovl);
@@ -719,6 +759,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr)
}
dss_mgr_write_regs(mgr);
+ dss_mgr_write_regs_extra(mgr);
dss_write_regs_common();
@@ -1225,6 +1266,35 @@ err:
return r;
}
+static void dss_apply_mgr_timings(struct omap_overlay_manager *mgr,
+ struct omap_video_timings *timings)
+{
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ mp->timings = *timings;
+ mp->extra_info_dirty = true;
+}
+
+void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
+ struct omap_video_timings *timings)
+{
+ unsigned long flags;
+
+ mutex_lock(&apply_lock);
+
+ spin_lock_irqsave(&data_lock, flags);
+
+ dss_apply_mgr_timings(mgr, timings);
+
+ dss_write_regs();
+ dss_set_go_bits();
+
+ spin_unlock_irqrestore(&data_lock, flags);
+
+ wait_pending_extra_info_updates();
+
+ mutex_unlock(&apply_lock);
+}
int dss_ovl_set_info(struct omap_overlay *ovl,
struct omap_overlay_info *info)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 94d8234..b17a212 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -177,6 +177,8 @@ void dss_mgr_get_info(struct omap_overlay_manager *mgr,
int dss_mgr_set_device(struct omap_overlay_manager *mgr,
struct omap_dss_device *dssdev);
int dss_mgr_unset_device(struct omap_overlay_manager *mgr);
+void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
+ struct omap_video_timings *timings);
bool dss_ovl_is_enabled(struct omap_overlay *ovl);
int dss_ovl_enable(struct omap_overlay *ovl);
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1334561027-28569-1-git-send-email-archit@ti.com>
An overlay manager's timings (the manager size, and blanking parameters if an
LCD manager) are DISPC shadow registers, and they should hence follow the
correct programming model.
This set makes the timings an extra_info parameter in manager's private data .
The interface drivers now apply the timings in instead of directly writing to
registers.
This change also prevents the need to use display resolution for overlay
checks, hence making some of the APPLY functions less dependent on the display.
Some DISPC functions that needed display width can also use these privately
stored timings.
Changes since v3:
- Remove direct setting of go bit in dpi_set_timings()
- Take some of the patches in "OMAPDSS: Misc fixes and cleanups" and make them a
part of this series as they are more related.
- Don't have an initial set of manager timings in private data, only check
manager and overlay parameters once the manager is enabled.
These patches apply over:
git://gitorious.org/linux-omap-dss2/linux.git dev
Reference tree containing this series:
git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2
Tested on OMAP4 SDP and Panda.
Archit Taneja (9):
OMAPDSS: APPLY: Add manager timings as extra_info in private data
OMAPDSS: Apply manager timings instead of direct DISPC writes
OMAPDSS: MANAGER: Create a function to check manager timings
OMAPDSS: APPLY: Don't check manager settings if it is disabled
OMAPDSS: APPLY: Remove display dependency from overlay and manager
checks
OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
OMAPDSS: DISPC: Remove omap_dss_device pointer usage from
dispc_mgr_pclk_rate()
OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
drivers/video/omap2/dss/apply.c | 132 ++++++++++++++++++++++++++++---------
drivers/video/omap2/dss/dispc.c | 64 ++++++++----------
drivers/video/omap2/dss/dpi.c | 7 +-
drivers/video/omap2/dss/dsi.c | 5 +-
drivers/video/omap2/dss/dss.h | 16 +++--
drivers/video/omap2/dss/hdmi.c | 4 +-
drivers/video/omap2/dss/manager.c | 19 +++++-
drivers/video/omap2/dss/overlay.c | 10 +--
drivers/video/omap2/dss/rfbi.c | 4 +-
drivers/video/omap2/dss/sdi.c | 2 +-
drivers/video/omap2/dss/venc.c | 2 +-
11 files changed, 175 insertions(+), 90 deletions(-)
--
1.7.5.4
^ permalink raw reply
* Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Tomi Valkeinen @ 2012-05-09 10:15 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FAA3E8E.4000904@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3927 bytes --]
On Wed, 2012-05-09 at 15:23 +0530, Archit Taneja wrote:
> On Tuesday 08 May 2012 06:05 PM, Archit Taneja wrote:
> > On Tuesday 08 May 2012 05:25 PM, Tomi Valkeinen wrote:
> >> On Tue, 2012-05-08 at 16:52 +0530, Archit Taneja wrote:
> >>> On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote:
> >>
> >>>> Checking the validity of all the settings is a bit tricky, but
> >>>> currently
> >>>> I think, as a rule of thumb, we should accept any settings when things
> >>>> are disabled. So, until the interface driver sets the timings before
> >>>> enabling the output, all ovl/mgr settings should be allowed. And we
> >>>
> >>> We have 2 ways to go about this, one is to have an initial set of
> >>> 'always valid' values like I have done, the other option is to ignore
> >>> manager timing related checks if the manager is disabled, i.e all
> >>> configs are okay. To implement the second option, I think our function
> >>> dss_check_settings_low() would get more complicated. We would now have
> >>> to pass mp->enabled outside of apply, and pass it to dss_mgr_check()
> >>> which would further need to pass this to dss_ovl_check(). Hence I used
> >>> the first approach.
> >>
> >> I'm not sure about that. We already do it for overlay. In ovl.c we have
> >> dss_ovl_simple_check() and dss_ovl_check(). The simple check sees if the
> >> settings pass basic sanity check. The check sees if all the ovl& mgr
> >> settings are compatible with each other.
> >>
> >> Simple check is done when setting the config, called from
> >> dss_ovl_set_info(). The proper check is done later when the actual
> >> config is about to be taken into use.
> >>
> >> If mp->enabled == false, can't we just skip dss_check_settings_low()
> >> totally for that manager? We skip the check for ovls the same way.
> >
> > Okay, this would work better I guess. If someone tries to enable the
> > manager without setting the timings, that check should fail, and in my
> > approach, it would have passed, and would have led to bad stuff later.
>
> One change in behaviour with the patch series I see is with the
> following use case when connected to Pandaboad's DVI interface:
>
> - Bootup with 1080p resolution
> - Try to set 640x480 timings with sysfs.
>
> The older behaviour was that the timings were taken, and a skewed image
> was seen(because the overlay size is larger in deimension)
>
> The behaviour after this series is that the mgr_set_timings fails with
> the error:
>
> omapdss OVERLAY error: overlay 0 horizontally not inside the display
> area (0 + 1920 >= 640)
>
> I guess this is better in a way, a user of DSS is supposed to reallocate
> the framebuffer with the desired size and then change the timings.
Yes, I think it's better. I think it's undefined what happens if the
overlay is larger than the output. In theory the DSS HW could lock-up,
or something. So we have to prevent it.
omapdss could change the size of the overlay automatically, but I
dislike things like that. Low level drivers adjusting the configuration
from the user almost always brings problems. So yes, I also think that
the user of DSS is supposed to handle it correctly.
> But with DVI, the problem is that dpi_set_timings already does a ton of
> stuff before dss_mgr_set_timings() is called, so we change the dividers
> to get the new clock, and then realise that the overlay can't fit
> inside, and we are left nowhere. I guess this is a separate problem and
> we could tackle it later.
Ah, ok. Yes, I guess we need to roll back the settings in that case. Or,
I wonder, would a check function work, that would take the new timings
and check those but also check if they match the overlays.
Hmm, no, that doesn't solve it totally, as the overlay could be changed
after the check. Again a problem with dss locking, we can't do the
operation atomically...
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
From: Archit Taneja @ 2012-05-09 9:56 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FA912F5.9030604@ti.com>
On Tuesday 08 May 2012 06:05 PM, Archit Taneja wrote:
> On Tuesday 08 May 2012 05:25 PM, Tomi Valkeinen wrote:
>> On Tue, 2012-05-08 at 16:52 +0530, Archit Taneja wrote:
>>> On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote:
>>
>>>> Checking the validity of all the settings is a bit tricky, but
>>>> currently
>>>> I think, as a rule of thumb, we should accept any settings when things
>>>> are disabled. So, until the interface driver sets the timings before
>>>> enabling the output, all ovl/mgr settings should be allowed. And we
>>>
>>> We have 2 ways to go about this, one is to have an initial set of
>>> 'always valid' values like I have done, the other option is to ignore
>>> manager timing related checks if the manager is disabled, i.e all
>>> configs are okay. To implement the second option, I think our function
>>> dss_check_settings_low() would get more complicated. We would now have
>>> to pass mp->enabled outside of apply, and pass it to dss_mgr_check()
>>> which would further need to pass this to dss_ovl_check(). Hence I used
>>> the first approach.
>>
>> I'm not sure about that. We already do it for overlay. In ovl.c we have
>> dss_ovl_simple_check() and dss_ovl_check(). The simple check sees if the
>> settings pass basic sanity check. The check sees if all the ovl& mgr
>> settings are compatible with each other.
>>
>> Simple check is done when setting the config, called from
>> dss_ovl_set_info(). The proper check is done later when the actual
>> config is about to be taken into use.
>>
>> If mp->enabled = false, can't we just skip dss_check_settings_low()
>> totally for that manager? We skip the check for ovls the same way.
>
> Okay, this would work better I guess. If someone tries to enable the
> manager without setting the timings, that check should fail, and in my
> approach, it would have passed, and would have led to bad stuff later.
One change in behaviour with the patch series I see is with the
following use case when connected to Pandaboad's DVI interface:
- Bootup with 1080p resolution
- Try to set 640x480 timings with sysfs.
The older behaviour was that the timings were taken, and a skewed image
was seen(because the overlay size is larger in deimension)
The behaviour after this series is that the mgr_set_timings fails with
the error:
omapdss OVERLAY error: overlay 0 horizontally not inside the display
area (0 + 1920 >= 640)
I guess this is better in a way, a user of DSS is supposed to reallocate
the framebuffer with the desired size and then change the timings.
But with DVI, the problem is that dpi_set_timings already does a ton of
stuff before dss_mgr_set_timings() is called, so we change the dividers
to get the new clock, and then realise that the overlay can't fit
inside, and we are left nowhere. I guess this is a separate problem and
we could tackle it later.
Archit
>
>>
>>>> shouldn't even write any shadow registers until the moment the
>>>> output is
>>>> enabled.
>>>
>>> That's being done correctly even now I guess, with the checks for
>>> mp->enabled in wrtie_regs() and set_go_bits().
>>
>> Yes, for timings. I was thinking more about the other settings done in
>> dpi.c currently, like dispc_mgr_set_pol_freq(). That writes directly to
>> registers, so we need runtime_get for that.
>
> Ok.
>
> Archit
>
>>
>> Tomi
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
From: Tomi Valkeinen @ 2012-05-09 8:09 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <20120507174657.GF5088@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3954 bytes --]
On Mon, 2012-05-07 at 10:46 -0700, Tony Lindgren wrote:
> Hi,
>
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [120503 07:01]:
> > Hi,
> >
> > I started cleaning up and restructuring omapdss for device tree, and here's the
> > first set of patches from that ordeal. There's nothing DT specific in these
> > patches, but they are mostly generic cleanups that make sense even without DT.
> >
> > This is the second version of these patches, the previous version can be found
> > from: http://www.spinics.net/lists/linux-fbdev/msg05667.html
> >
> > The first 21 patches, which were in the previous version, have only gotten
> > minor cleanups (and, of course, more testing). The last 4 patches are new. The
> > most important of those patches is the DSI pin config patch, which makes it
> > possible for the panel driver to configure the DSI pins it needs.
> >
> > This series can also be found from:
> > git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base
>
> Nice clean up. Can you please put the first 12 arch/arm/*omap*/* touching
> patches (and the drivers/video dependencies needed) into a separate branch
> and send me a pull request. That is assuming those patches are now immutable.
>
> Then I can pull it into cleanup-dss branch that we both can merge as
> needed.
Below is the pull request for board file related changes. Tested on
panda & 4430sdp.
How should I manage my tree related to this... Should I rebase my
original DT preparation series on top of this new branch, or can I just
ignore the new branch for now, as long as I merge it at some point
before sending a pull request to mainline?
Tomi
The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-l-o-3.5
for you to fetch changes up to e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07:
OMAPDSS: DSI: implement generic DSI pin config (2012-05-09 10:53:05 +0300)
----------------------------------------------------------------
Tomi Valkeinen (6):
OMAPDSS: panel-dvi: add PD gpio handling
OMAP: board-files: remove custom PD GPIO handling for DVI output
OMAPDSS: TFP410: rename dvi -> tfp410
OMAPDSS: TFP410: rename dvi files to tfp410
OMAPDSS: Taal: move reset gpio handling to taal driver
OMAPDSS: DSI: implement generic DSI pin config
arch/arm/mach-omap2/board-3430sdp.c | 38 +-----
arch/arm/mach-omap2/board-4430sdp.c | 37 ++----
arch/arm/mach-omap2/board-am3517evm.c | 25 +---
arch/arm/mach-omap2/board-cm-t35.c | 30 +----
arch/arm/mach-omap2/board-devkit8000.c | 30 +----
arch/arm/mach-omap2/board-igep0020.c | 32 +----
arch/arm/mach-omap2/board-omap3beagle.c | 37 +-----
arch/arm/mach-omap2/board-omap3evm.c | 29 +----
arch/arm/mach-omap2/board-omap3stalker.c | 29 +----
arch/arm/mach-omap2/board-omap4panda.c | 39 +-----
arch/arm/mach-omap2/board-overo.c | 25 +---
drivers/video/omap2/displays/Kconfig | 8 +-
drivers/video/omap2/displays/Makefile | 2 +-
drivers/video/omap2/displays/panel-taal.c | 22 ++++
.../omap2/displays/{panel-dvi.c => panel-tfp410.c} | 134 +++++++++++---------
drivers/video/omap2/dss/dsi.c | 133 +++++++++----------
include/video/omap-panel-nokia-dsi.h | 3 +
.../{omap-panel-dvi.h => omap-panel-tfp410.h} | 18 ++-
include/video/omapdss.h | 28 ++--
19 files changed, 251 insertions(+), 448 deletions(-)
rename drivers/video/omap2/displays/{panel-dvi.c => panel-tfp410.c} (63%)
rename include/video/{omap-panel-dvi.h => omap-panel-tfp410.h} (63%)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 0/5] video: exynos mipi dsi: fixes some bugs and clean the codes
From: Donghwa Lee @ 2012-05-09 5:49 UTC (permalink / raw)
To: linux-arm-kernel
These patches fix some bugs and clean the codes for exynos mipi dsi
display driver.
video: exynos mipi dsi: enable interrupt again after sw reset
:I resend this patch by including this series.
You can refer the original patch by below url.
http://marc.info/?l=linux-fbdev&m\x133610770329570&w=2
video: exynos mipi dsi: Do not use deprecated suspend/resume callbacks
video: exynos mipi dsi: Avoid races in probe()
video: exynos mipi dsi: Properly interpret the interrupt source flags
video: exynos mipi dsi: support reverse panel type
Thank you,
Donghwa Lee
^ 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