* [PATCH v2] udlfb: Fix invalid return codes in edid sysfs entry store function
From: Olivier Sobrie @ 2012-02-29 7:06 UTC (permalink / raw)
To: linux-fbdev
Return a negative errno instead of zero in the write function of
the sysfs entry in case of error.
Also add a check on the return value of dlfb_setup_modes().
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
---
drivers/video/udlfb.c | 19 +++++++++++--------
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index a197731..bfd2a56 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1427,19 +1427,22 @@ static ssize_t edid_store(
struct device *fbdev = container_of(kobj, struct device, kobj);
struct fb_info *fb_info = dev_get_drvdata(fbdev);
struct dlfb_data *dev = fb_info->par;
+ int ret;
/* We only support write of entire EDID at once, no offset*/
if ((src_size != EDID_LENGTH) || (src_off != 0))
- return 0;
+ return -EINVAL;
- dlfb_setup_modes(dev, fb_info, src, src_size);
+ ret = dlfb_setup_modes(dev, fb_info, src, src_size);
+ if (ret)
+ return ret;
- if (dev->edid && (memcmp(src, dev->edid, src_size) = 0)) {
- pr_info("sysfs written EDID is new default\n");
- dlfb_ops_set_par(fb_info);
- return src_size;
- } else
- return 0;
+ if (!dev->edid || memcmp(src, dev->edid, src_size))
+ return -EINVAL;
+
+ pr_info("sysfs written EDID is new default\n");
+ dlfb_ops_set_par(fb_info);
+ return src_size;
}
static ssize_t metrics_reset_store(struct device *fbdev,
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/2] OMAPDSS: small fixes for 3.3 rc
From: Tomi Valkeinen @ 2012-02-29 8:48 UTC (permalink / raw)
To: FlorianSchandinat, linux-fbdev, linux-omap; +Cc: Tomi Valkeinen
Hi,
Two small fixes for omapdss.
Florian, if the patches are ok, I guess it's easier if you just apply these
patches from email, instead of me sending a pull request?
Tomi
Tomi Valkeinen (2):
OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
OMAPDSS: APPLY: make ovl_enable/disable synchronous
drivers/video/omap2/displays/Kconfig | 2 +-
drivers/video/omap2/dss/apply.c | 6 ++++++
2 files changed, 7 insertions(+), 1 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH 1/2] OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
From: Tomi Valkeinen @ 2012-02-29 8:48 UTC (permalink / raw)
To: FlorianSchandinat, linux-fbdev, linux-omap; +Cc: Tomi Valkeinen
In-Reply-To: <1330505302-8258-1-git-send-email-tomi.valkeinen@ti.com>
panel-dvi uses i2c, but the Kconfig didn't have dependency on I2C. Add
it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig
index 74d29b5..408a992 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -12,7 +12,7 @@ config PANEL_GENERIC_DPI
config PANEL_DVI
tristate "DVI output"
- depends on OMAP2_DSS_DPI
+ depends on OMAP2_DSS_DPI && I2C
help
Driver for external monitors, connected via DVI. The driver uses i2c
to read EDID information from the monitor.
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
From: Tomi Valkeinen @ 2012-02-29 8:48 UTC (permalink / raw)
To: FlorianSchandinat, linux-fbdev, linux-omap; +Cc: Tomi Valkeinen
In-Reply-To: <1330505302-8258-1-git-send-email-tomi.valkeinen@ti.com>
ovl->enable/disable are meant to be synchronous so that they can handle
the configuration of fifo sizes. The current kernel doesn't configure
fifo sizes yet, and so the code doesn't need to block to function (from
omapdss driver's perspective).
However, for the users of omapdss a non-blocking ovl->disable is
confusing, because they don't know when the memory area is not used
any more.
Furthermore, when the fifo size configuration is added in the next merge
window, the change from non-blocking to blocking could cause side
effects to the users of omapdss. So by making the functions block
already will keep them behaving in the same manner.
And, while not the main purpose of this patch, this will also remove the
compile warning:
drivers/video/omap2/dss/apply.c:350: warning:
'wait_pending_extra_info_updates' defined but not used
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/apply.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 052dc87..87b3e25 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1276,6 +1276,9 @@ int dss_ovl_enable(struct omap_overlay *ovl)
spin_unlock_irqrestore(&data_lock, flags);
+ /* wait for overlay to be enabled */
+ wait_pending_extra_info_updates();
+
mutex_unlock(&apply_lock);
return 0;
@@ -1313,6 +1316,9 @@ int dss_ovl_disable(struct omap_overlay *ovl)
spin_unlock_irqrestore(&data_lock, flags);
+ /* wait for the overlay to be disabled */
+ wait_pending_extra_info_updates();
+
mutex_unlock(&apply_lock);
return 0;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 0/2] OMAPDSS: small fixes for 3.3 rc
From: Florian Tobias Schandinat @ 2012-02-29 9:56 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1330505302-8258-1-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> Hi,
>
> Two small fixes for omapdss.
>
> Florian, if the patches are ok, I guess it's easier if you just apply these
> patches from email, instead of me sending a pull request?
Yes, that's correct as those are only a few patches and as we are already in
late -rc's (and therefore I guess, I should take a better look at what I apply).
I'll add some comments to your patches in separate mails.
Best regards,
Florian Tobias Schandinat
>
> Tomi
>
> Tomi Valkeinen (2):
> OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
> OMAPDSS: APPLY: make ovl_enable/disable synchronous
>
> drivers/video/omap2/displays/Kconfig | 2 +-
> drivers/video/omap2/dss/apply.c | 6 ++++++
> 2 files changed, 7 insertions(+), 1 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
From: Florian Tobias Schandinat @ 2012-02-29 10:03 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1330505302-8258-2-git-send-email-tomi.valkeinen@ti.com>
On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> panel-dvi uses i2c, but the Kconfig didn't have dependency on I2C. Add
> it.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/displays/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig
> index 74d29b5..408a992 100644
> --- a/drivers/video/omap2/displays/Kconfig
> +++ b/drivers/video/omap2/displays/Kconfig
> @@ -12,7 +12,7 @@ config PANEL_GENERIC_DPI
>
> config PANEL_DVI
> tristate "DVI output"
> - depends on OMAP2_DSS_DPI
> + depends on OMAP2_DSS_DPI && I2C
It's just a matter of taste, but are you sure you want to "depend" on it and not
"select" it? Other drivers tend to use select for I2C, for me it doesn't really
matter.
Best regards,
Florian Tobias Schandinat
> help
> Driver for external monitors, connected via DVI. The driver uses i2c
> to read EDID information from the monitor.
^ permalink raw reply
* Re: [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
From: Florian Tobias Schandinat @ 2012-02-29 10:13 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1330505302-8258-3-git-send-email-tomi.valkeinen@ti.com>
On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> ovl->enable/disable are meant to be synchronous so that they can handle
> the configuration of fifo sizes. The current kernel doesn't configure
> fifo sizes yet, and so the code doesn't need to block to function (from
> omapdss driver's perspective).
>
> However, for the users of omapdss a non-blocking ovl->disable is
> confusing, because they don't know when the memory area is not used
> any more.
>
> Furthermore, when the fifo size configuration is added in the next merge
> window, the change from non-blocking to blocking could cause side
> effects to the users of omapdss. So by making the functions block
> already will keep them behaving in the same manner.
Is there any difference to doing it now?
I agree that this should be fixed but if we can't avoid breaking users I'd
prefer to break them in a merge window not in late rc stage. Or did we introduce
these functions just in the last merge window?
Best regards,
Florian Tobias Schandinat
>
> And, while not the main purpose of this patch, this will also remove the
> compile warning:
>
> drivers/video/omap2/dss/apply.c:350: warning:
> 'wait_pending_extra_info_updates' defined but not used
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/apply.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index 052dc87..87b3e25 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -1276,6 +1276,9 @@ int dss_ovl_enable(struct omap_overlay *ovl)
>
> spin_unlock_irqrestore(&data_lock, flags);
>
> + /* wait for overlay to be enabled */
> + wait_pending_extra_info_updates();
> +
> mutex_unlock(&apply_lock);
>
> return 0;
> @@ -1313,6 +1316,9 @@ int dss_ovl_disable(struct omap_overlay *ovl)
>
> spin_unlock_irqrestore(&data_lock, flags);
>
> + /* wait for the overlay to be disabled */
> + wait_pending_extra_info_updates();
> +
> mutex_unlock(&apply_lock);
>
> return 0;
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
From: Tomi Valkeinen @ 2012-02-29 10:21 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-omap
In-Reply-To: <4F4DF801.3000905@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
On Wed, 2012-02-29 at 10:03 +0000, Florian Tobias Schandinat wrote:
> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> > panel-dvi uses i2c, but the Kconfig didn't have dependency on I2C. Add
> > it.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > ---
> > drivers/video/omap2/displays/Kconfig | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig
> > index 74d29b5..408a992 100644
> > --- a/drivers/video/omap2/displays/Kconfig
> > +++ b/drivers/video/omap2/displays/Kconfig
> > @@ -12,7 +12,7 @@ config PANEL_GENERIC_DPI
> >
> > config PANEL_DVI
> > tristate "DVI output"
> > - depends on OMAP2_DSS_DPI
> > + depends on OMAP2_DSS_DPI && I2C
>
> It's just a matter of taste, but are you sure you want to "depend" on it and not
> "select" it? Other drivers tend to use select for I2C, for me it doesn't really
> matter.
Well, I'd like to "select", but I don't think that's correct. From
Documentation/kbuild/kconfig-language.txt:
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
But I do see quite many selects for I2C, so I'm not sure if all those
are wrong, or has it just been decided that I2C is a valid target for
select.
Using depend is in line with the other panel drivers in the same
directory. I've been thinking about the same thing from time to time,
and I'd rather select I2C, SPI and BACKLIGHT_CLASS_DEVICE than use
depend.
But, for example, using select to BACKLIGHT_CLASS_DEVICE is broken: if I
change a panel driver to select BACKLIGHT_CLASS_DEVICE, but then I
manually disable CONFIG_BACKLIGHT_LCD_SUPPORT (which the
BACKLIGHT_CLASS_DEVICE depends on) from the kernel config, this leads to
BACKLIGHT_CLASS_DEVICE being enabled, but CONFIG_BACKLIGHT_LCD_SUPPORT
being disabled, which is clearly broken.
So... As I see it, depending is a bit awkward, but it's correct.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
From: Tomi Valkeinen @ 2012-02-29 10:30 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-omap, Rob Clark
In-Reply-To: <4F4DFA30.2040503@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
On Wed, 2012-02-29 at 10:13 +0000, Florian Tobias Schandinat wrote:
> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> > ovl->enable/disable are meant to be synchronous so that they can handle
> > the configuration of fifo sizes. The current kernel doesn't configure
> > fifo sizes yet, and so the code doesn't need to block to function (from
> > omapdss driver's perspective).
> >
> > However, for the users of omapdss a non-blocking ovl->disable is
> > confusing, because they don't know when the memory area is not used
> > any more.
> >
> > Furthermore, when the fifo size configuration is added in the next merge
> > window, the change from non-blocking to blocking could cause side
> > effects to the users of omapdss. So by making the functions block
> > already will keep them behaving in the same manner.
>
> Is there any difference to doing it now?
> I agree that this should be fixed but if we can't avoid breaking users I'd
> prefer to break them in a merge window not in late rc stage. Or did we introduce
> these functions just in the last merge window?
Yes, these were introduced in the merge window. And I explicitly said
the functions are blocking so that they can perform their job. And just
to clarify, the functions already use a mutex, so in that sense they are
blocking. They just don't currently wait until the HW has finished with
the overlay.
The problem was raised by Rob Clark, who's writing the omapdrm driver,
as he doesn't have a way to ensure that the overlay has been truly
disabled and the memory is is no longer in use.
(I forgot to cc him for the patch, adding him now).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
From: Florian Tobias Schandinat @ 2012-02-29 10:48 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap, Rob Clark
In-Reply-To: <1330511438.1934.95.camel@deskari>
Hi Tomi,
On 02/29/2012 10:30 AM, Tomi Valkeinen wrote:
> On Wed, 2012-02-29 at 10:13 +0000, Florian Tobias Schandinat wrote:
>> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
>>> ovl->enable/disable are meant to be synchronous so that they can handle
>>> the configuration of fifo sizes. The current kernel doesn't configure
>>> fifo sizes yet, and so the code doesn't need to block to function (from
>>> omapdss driver's perspective).
>>>
>>> However, for the users of omapdss a non-blocking ovl->disable is
>>> confusing, because they don't know when the memory area is not used
>>> any more.
>>>
>>> Furthermore, when the fifo size configuration is added in the next merge
>>> window, the change from non-blocking to blocking could cause side
>>> effects to the users of omapdss. So by making the functions block
>>> already will keep them behaving in the same manner.
>>
>> Is there any difference to doing it now?
>> I agree that this should be fixed but if we can't avoid breaking users I'd
>> prefer to break them in a merge window not in late rc stage. Or did we introduce
>> these functions just in the last merge window?
>
> Yes, these were introduced in the merge window. And I explicitly said
> the functions are blocking so that they can perform their job. And just
> to clarify, the functions already use a mutex, so in that sense they are
> blocking. They just don't currently wait until the HW has finished with
> the overlay.
okay, than I'll apply this patch as is. I was just worried about asking Linus to
pull something that is labled as "Breaks existing users" now, but that doesn't
look like an issue here.
Best regards,
Florian Tobias Schandinat
>
> The problem was raised by Rob Clark, who's writing the omapdrm driver,
> as he doesn't have a way to ensure that the overlay has been truly
> disabled and the memory is is no longer in use.
>
> (I forgot to cc him for the patch, adding him now).
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
From: Florian Tobias Schandinat @ 2012-02-29 11:10 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1330510902.1934.76.camel@deskari>
Hi Tomi,
On 02/29/2012 10:21 AM, Tomi Valkeinen wrote:
> On Wed, 2012-02-29 at 10:03 +0000, Florian Tobias Schandinat wrote:
>> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
>>> panel-dvi uses i2c, but the Kconfig didn't have dependency on I2C. Add
>>> it.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> drivers/video/omap2/displays/Kconfig | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig
>>> index 74d29b5..408a992 100644
>>> --- a/drivers/video/omap2/displays/Kconfig
>>> +++ b/drivers/video/omap2/displays/Kconfig
>>> @@ -12,7 +12,7 @@ config PANEL_GENERIC_DPI
>>>
>>> config PANEL_DVI
>>> tristate "DVI output"
>>> - depends on OMAP2_DSS_DPI
>>> + depends on OMAP2_DSS_DPI && I2C
>>
>> It's just a matter of taste, but are you sure you want to "depend" on it and not
>> "select" it? Other drivers tend to use select for I2C, for me it doesn't really
>> matter.
>
> Well, I'd like to "select", but I don't think that's correct. From
> Documentation/kbuild/kconfig-language.txt:
>
> In general use select only for non-visible symbols
> (no prompts anywhere) and for symbols with no dependencies.
>
> But I do see quite many selects for I2C, so I'm not sure if all those
> are wrong, or has it just been decided that I2C is a valid target for
> select.
I'd say that the above is only a guideline but not absolute rule. For I2C I'd
argue that I probably wouldn't even know that my hardware has it if I weren't
the one writing the driver using it.
But it's true that select should be used with care as it is much easier to get
the config messed up by using it.
> Using depend is in line with the other panel drivers in the same
> directory. I've been thinking about the same thing from time to time,
> and I'd rather select I2C, SPI and BACKLIGHT_CLASS_DEVICE than use
> depend.
>
> But, for example, using select to BACKLIGHT_CLASS_DEVICE is broken: if I
> change a panel driver to select BACKLIGHT_CLASS_DEVICE, but then I
> manually disable CONFIG_BACKLIGHT_LCD_SUPPORT (which the
> BACKLIGHT_CLASS_DEVICE depends on) from the kernel config, this leads to
> BACKLIGHT_CLASS_DEVICE being enabled, but CONFIG_BACKLIGHT_LCD_SUPPORT
> being disabled, which is clearly broken.
Yes, as far as I understand the problem here is that we don't have any mechanism
to handle transitive dependencies (probably because we don't want it). So if one
wants to do select something I think the right way to do it would be to inherit
all its select/depend statements in the option.
> So... As I see it, depending is a bit awkward, but it's correct.
Yes, it certainly is correct.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
From: Rob Clark @ 2012-02-29 14:52 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: Tomi Valkeinen, linux-fbdev, linux-omap
In-Reply-To: <4F4E0294.6000406@gmx.de>
On Wed, Feb 29, 2012 at 4:48 AM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> Hi Tomi,
>
> On 02/29/2012 10:30 AM, Tomi Valkeinen wrote:
>> On Wed, 2012-02-29 at 10:13 +0000, Florian Tobias Schandinat wrote:
>>> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
>>>> ovl->enable/disable are meant to be synchronous so that they can handle
>>>> the configuration of fifo sizes. The current kernel doesn't configure
>>>> fifo sizes yet, and so the code doesn't need to block to function (from
>>>> omapdss driver's perspective).
>>>>
>>>> However, for the users of omapdss a non-blocking ovl->disable is
>>>> confusing, because they don't know when the memory area is not used
>>>> any more.
>>>>
>>>> Furthermore, when the fifo size configuration is added in the next merge
>>>> window, the change from non-blocking to blocking could cause side
>>>> effects to the users of omapdss. So by making the functions block
>>>> already will keep them behaving in the same manner.
>>>
>>> Is there any difference to doing it now?
>>> I agree that this should be fixed but if we can't avoid breaking users I'd
>>> prefer to break them in a merge window not in late rc stage. Or did we introduce
>>> these functions just in the last merge window?
>>
>> Yes, these were introduced in the merge window. And I explicitly said
>> the functions are blocking so that they can perform their job. And just
>> to clarify, the functions already use a mutex, so in that sense they are
>> blocking. They just don't currently wait until the HW has finished with
>> the overlay.
>
> okay, than I'll apply this patch as is. I was just worried about asking Linus to
> pull something that is labled as "Breaks existing users" now, but that doesn't
> look like an issue here.
>
I don't expect this change should break any existing users.. I think
it is safe to call this a bug fix
BR,
-R
> Best regards,
>
> Florian Tobias Schandinat
>
>>
>> The problem was raised by Rob Clark, who's writing the omapdrm driver,
>> as he doesn't have a way to ensure that the overlay has been truly
>> disabled and the memory is is no longer in use.
>>
>> (I forgot to cc him for the patch, adding him now).
>>
>> Tomi
>>
>
> --
> 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 0/2] OMAPDSS: small fixes for 3.3 rc
From: Florian Tobias Schandinat @ 2012-03-01 5:38 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1330505302-8258-1-git-send-email-tomi.valkeinen@ti.com>
On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> Hi,
>
> Two small fixes for omapdss.
Applied both.
Thanks,
Florian Tobias Schandinat
>
> Florian, if the patches are ok, I guess it's easier if you just apply these
> patches from email, instead of me sending a pull request?
>
> Tomi
>
> Tomi Valkeinen (2):
> OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
> OMAPDSS: APPLY: make ovl_enable/disable synchronous
>
> drivers/video/omap2/displays/Kconfig | 2 +-
> drivers/video/omap2/dss/apply.c | 6 ++++++
> 2 files changed, 7 insertions(+), 1 deletions(-)
>
^ permalink raw reply
* [PATCH 0/7] OMAPDSS: HDMI PHY burnout fix for 3.2 stable
From: Tomi Valkeinen @ 2012-03-01 12:26 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
The main patch in this set is the "PHY burnout fix", which implements a fix for
a hardware bug in the OMAP4 HDMI PHY which may cause physical damage to the
board if the HDMI PHY is already enabled when the HDMI cable is plugged in. The
possible damage breaks HDMI output hardware, otherwise the board is unaffected.
The preceding patches are small cleanups/fixes for HDMI GPIOs so that the fix
can be implemented. And the fix introduced a small bug with hot plug detect,
which is fixed by the patch from Rob. Rob's patch is not yet in upstream, but
has been accepted by fbdev maintainer.
Tomi
Rob Clark (1):
OMAPDSS: HDMI: hot plug detect fix
Tomi Valkeinen (6):
OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
OMAPDSS: remove wrong HDMI HPD muxing
OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
OMAP: 4430SDP/Panda: add HDMI HPD gpio
OMAPDSS: HDMI: PHY burnout fix
arch/arm/mach-omap2/board-4430sdp.c | 22 +++++---
arch/arm/mach-omap2/board-omap4panda.c | 22 +++++---
drivers/video/omap2/dss/hdmi.c | 3 +
drivers/video/omap2/dss/ti_hdmi.h | 4 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 77 ++++++++++++++++++++++++-----
include/video/omapdss.h | 5 ++
6 files changed, 105 insertions(+), 28 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH 1/7] OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
From: Tomi Valkeinen @ 2012-03-01 12:26 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
In-Reply-To: <1330604795-29156-1-git-send-email-tomi.valkeinen@ti.com>
Instead of freeing the GPIOs individually, use gpio_free_array().
Backported from 575753e3bea3b67eef8e454fb87f719e3f7da599
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 3 +--
arch/arm/mach-omap2/board-omap4panda.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 5156468..8434b0c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -628,8 +628,7 @@ static int sdp4430_panel_enable_hdmi(struct omap_dss_device *dssdev)
static void sdp4430_panel_disable_hdmi(struct omap_dss_device *dssdev)
{
- gpio_free(HDMI_GPIO_LS_OE);
- gpio_free(HDMI_GPIO_HPD);
+ gpio_free_array(sdp4430_hdmi_gpios, ARRAY_SIZE(sdp4430_hdmi_gpios));
}
static struct nokia_dsi_panel_data dsi1_panel = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index a8c2c42..1ac7a22 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -512,8 +512,7 @@ static int omap4_panda_panel_enable_hdmi(struct omap_dss_device *dssdev)
static void omap4_panda_panel_disable_hdmi(struct omap_dss_device *dssdev)
{
- gpio_free(HDMI_GPIO_LS_OE);
- gpio_free(HDMI_GPIO_HPD);
+ gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
}
static struct omap_dss_device omap4_panda_hdmi_device = {
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/7] OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
From: Tomi Valkeinen @ 2012-03-01 12:26 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
In-Reply-To: <1330604795-29156-1-git-send-email-tomi.valkeinen@ti.com>
The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in
the board files, but CT_CP_HPD, which is used to enable/disable HPD
functionality.
This patch renames the GPIO.
Backported from 3932a32fcf5393f8be70ac99dc718ad7ad0a415b
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 4 ++--
arch/arm/mach-omap2/board-omap4panda.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 8434b0c..4333115 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -52,7 +52,7 @@
#define ETH_KS8851_QUART 138
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
-#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
#define DLP_POWER_ON_GPIO 40
@@ -610,7 +610,7 @@ static void sdp4430_hdmi_mux_init(void)
}
static struct gpio sdp4430_hdmi_gpios[] = {
- { HDMI_GPIO_HPD, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_hpd" },
+ { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ct_cp_hpd" },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ls_oe" },
};
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 1ac7a22..d8e20f1 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -51,7 +51,7 @@
#define GPIO_HUB_NRESET 62
#define GPIO_WIFI_PMENA 43
#define GPIO_WIFI_IRQ 53
-#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
/* wl127x BT, FM, GPS connectivity chip */
@@ -494,7 +494,7 @@ static void omap4_panda_hdmi_mux_init(void)
}
static struct gpio panda_hdmi_gpios[] = {
- { HDMI_GPIO_HPD, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_hpd" },
+ { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ct_cp_hpd" },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ls_oe" },
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/7] OMAPDSS: remove wrong HDMI HPD muxing
From: Tomi Valkeinen @ 2012-03-01 12:26 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
In-Reply-To: <1330604795-29156-1-git-send-email-tomi.valkeinen@ti.com>
"hdmi_hpd" pin is muxed to INPUT and PULLUP, but the pin is not
currently used, and in the future when it is used, the pin is used as a
GPIO and is board specific, not an OMAP4 wide thing.
So remove the muxing for now.
Backported from 7bb122d155f742fe2d79849090c825be7b4a247e
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 4 ----
arch/arm/mach-omap2/board-omap4panda.c | 4 ----
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 4333115..385c1fd 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -597,12 +597,8 @@ static void __init omap_sfh7741prox_init(void)
static void sdp4430_hdmi_mux_init(void)
{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal("hdmi_hpd",
- OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal("hdmi_cec",
OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
omap_mux_init_signal("hdmi_ddc_scl",
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal("hdmi_ddc_sda",
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index d8e20f1..e0d0abc 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -481,12 +481,8 @@ int __init omap4_panda_dvi_init(void)
static void omap4_panda_hdmi_mux_init(void)
{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal("hdmi_hpd",
- OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal("hdmi_cec",
OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
omap_mux_init_signal("hdmi_ddc_scl",
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal("hdmi_ddc_sda",
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/7] OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
From: Tomi Valkeinen @ 2012-03-01 12:26 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
In-Reply-To: <1330604795-29156-1-git-send-email-tomi.valkeinen@ti.com>
The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured.
This patch configures them as output pins.
Backported from 78a1ad8f12db70b8b0a4548b90704de08ee216ce
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 3 +++
arch/arm/mach-omap2/board-omap4panda.c | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 385c1fd..7bcafb9 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -824,6 +824,9 @@ static void omap_4430sdp_display_init(void)
sdp4430_hdmi_mux_init();
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
+
+ omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index e0d0abc..27fc162 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -541,6 +541,9 @@ void omap4_panda_display_init(void)
omap4_panda_hdmi_mux_init();
omap_display_init(&omap4_panda_dss_data);
+
+ omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
}
static void __init omap4_panda_init(void)
--
1.7.4.1
^ permalink raw reply related
* [PATCH 5/7] OMAP: 4430SDP/Panda: add HDMI HPD gpio
From: Tomi Valkeinen @ 2012-03-01 12:26 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
In-Reply-To: <1330604795-29156-1-git-send-email-tomi.valkeinen@ti.com>
Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure
this GPIO in the board files.
Backported from aa74274b464d4aa24703963ac89a0ee942d5d267
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 3 +++
arch/arm/mach-omap2/board-omap4panda.c | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 7bcafb9..5c2aaa0 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -54,6 +54,7 @@
#define OMAP4_SFH7741_ENABLE_GPIO 188
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
#define DLP_POWER_ON_GPIO 40
@@ -608,6 +609,7 @@ static void sdp4430_hdmi_mux_init(void)
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ct_cp_hpd" },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ls_oe" },
+ { HDMI_GPIO_HPD, GPIOF_DIR_IN, "hdmi_gpio_hpd" },
};
static int sdp4430_panel_enable_hdmi(struct omap_dss_device *dssdev)
@@ -827,6 +829,7 @@ static void omap_4430sdp_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 27fc162..e913c80 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -53,6 +53,7 @@
#define GPIO_WIFI_IRQ 53
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
static int wl1271_gpios[] = {46, -1, -1};
@@ -492,6 +493,7 @@ static void omap4_panda_hdmi_mux_init(void)
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ct_cp_hpd" },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ls_oe" },
+ { HDMI_GPIO_HPD, GPIOF_DIR_IN, "hdmi_gpio_hpd" },
};
static int omap4_panda_panel_enable_hdmi(struct omap_dss_device *dssdev)
@@ -544,6 +546,7 @@ void omap4_panda_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
static void __init omap4_panda_init(void)
--
1.7.4.1
^ permalink raw reply related
* [PATCH 6/7] OMAPDSS: HDMI: PHY burnout fix
From: Tomi Valkeinen @ 2012-03-01 12:26 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
In-Reply-To: <1330604795-29156-1-git-send-email-tomi.valkeinen@ti.com>
A hardware bug in the OMAP4 HDMI PHY may cause physical damage to the
board if the HDMI PHY is already enabled when the HDMI cable is plugged
in. The possible damage breaks HDMI output, otherwise the board is
unaffected.
This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.
The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.
The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
"ticking" and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.
Backported from c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 5 ++
arch/arm/mach-omap2/board-omap4panda.c | 5 ++
drivers/video/omap2/dss/hdmi.c | 3 +
drivers/video/omap2/dss/ti_hdmi.h | 4 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 68 +++++++++++++++++++++++++++--
include/video/omapdss.h | 5 ++
6 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 5c2aaa0..02cd29a 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -742,6 +742,10 @@ static void sdp4430_lcd_init(void)
pr_err("%s: Could not get lcd2_reset_gpio\n", __func__);
}
+static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
static struct omap_dss_device sdp4430_hdmi_device = {
.name = "hdmi",
.driver_name = "hdmi_panel",
@@ -749,6 +753,7 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.platform_enable = sdp4430_panel_enable_hdmi,
.platform_disable = sdp4430_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = &sdp4430_hdmi_data,
};
static struct picodlp_panel_data sdp4430_picodlp_pdata = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index e913c80..51b1c93 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -513,6 +513,10 @@ static void omap4_panda_panel_disable_hdmi(struct omap_dss_device *dssdev)
gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
}
+static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
static struct omap_dss_device omap4_panda_hdmi_device = {
.name = "hdmi",
.driver_name = "hdmi_panel",
@@ -520,6 +524,7 @@ static struct omap_dss_device omap4_panda_hdmi_device = {
.platform_enable = omap4_panda_panel_enable_hdmi,
.platform_disable = omap4_panda_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = &omap4_panda_hdmi_data,
};
static struct omap_dss_device *omap4_panda_dss_devices[] = {
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c56378c..7099c31 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -490,6 +490,7 @@ bool omapdss_hdmi_detect(void)
int omapdss_hdmi_display_enable(struct omap_dss_device *dssdev)
{
+ struct omap_dss_hdmi_data *priv = dssdev->data;
int r = 0;
DSSDBG("ENTER hdmi_display_enable\n");
@@ -502,6 +503,8 @@ int omapdss_hdmi_display_enable(struct omap_dss_device *dssdev)
goto err0;
}
+ hdmi.ip_data.hpd_gpio = priv->hpd_gpio;
+
r = omap_dss_start_device(dssdev);
if (r) {
DSSERR("failed to start device\n");
diff --git a/drivers/video/omap2/dss/ti_hdmi.h b/drivers/video/omap2/dss/ti_hdmi.h
index 2c3443d..ec337b5d 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -121,6 +121,10 @@ struct hdmi_ip_data {
const struct ti_hdmi_ip_ops *ops;
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
+
+ /* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
+ int hpd_gpio;
+ bool phy_tx_enabled;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index e1a6ce5..3683404 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -28,6 +28,7 @@
#include <linux/delay.h>
#include <linux/string.h>
#include <linux/seq_file.h>
+#include <linux/gpio.h>
#include "ti_hdmi_4xxx_ip.h"
#include "dss.h"
@@ -223,6 +224,49 @@ void ti_hdmi_4xxx_pll_disable(struct hdmi_ip_data *ip_data)
hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
}
+static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
+{
+ unsigned long flags;
+ bool hpd;
+ int r;
+ /* this should be in ti_hdmi_4xxx_ip private data */
+ static DEFINE_SPINLOCK(phy_tx_lock);
+
+ spin_lock_irqsave(&phy_tx_lock, flags);
+
+ hpd = gpio_get_value(ip_data->hpd_gpio);
+
+ if (hpd = ip_data->phy_tx_enabled) {
+ spin_unlock_irqrestore(&phy_tx_lock, flags);
+ return 0;
+ }
+
+ if (hpd)
+ r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
+ else
+ r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+
+ if (r) {
+ DSSERR("Failed to %s PHY TX power\n",
+ hpd ? "enable" : "disable");
+ goto err;
+ }
+
+ ip_data->phy_tx_enabled = hpd;
+err:
+ spin_unlock_irqrestore(&phy_tx_lock, flags);
+ return r;
+}
+
+static irqreturn_t hpd_irq_handler(int irq, void *data)
+{
+ struct hdmi_ip_data *ip_data = data;
+
+ hdmi_check_hpd_state(ip_data);
+
+ return IRQ_HANDLED;
+}
+
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
@@ -232,10 +276,6 @@ int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data)
if (r)
return r;
- r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- if (r)
- return r;
-
/*
* Read address 0 in order to get the SCP reset done completed
* Dummy access performed to make sure reset is done
@@ -257,12 +297,32 @@ int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data)
/* Write to phy address 3 to change the polarity control */
REG_FLD_MOD(phy_base, HDMI_TXPHY_PAD_CFG_CTRL, 0x1, 27, 27);
+ r = request_threaded_irq(gpio_to_irq(ip_data->hpd_gpio),
+ NULL, hpd_irq_handler,
+ IRQF_DISABLED | IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING, "hpd", ip_data);
+ if (r) {
+ DSSERR("HPD IRQ request failed\n");
+ hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
+ return r;
+ }
+
+ r = hdmi_check_hpd_state(ip_data);
+ if (r) {
+ free_irq(gpio_to_irq(ip_data->hpd_gpio), ip_data);
+ hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
+ return r;
+ }
+
return 0;
}
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data)
{
+ free_irq(gpio_to_irq(ip_data->hpd_gpio), ip_data);
+
hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
+ ip_data->phy_tx_enabled = false;
}
static int hdmi_core_ddc_init(struct hdmi_ip_data *ip_data)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 378c7ed..6582c45 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -575,6 +575,11 @@ struct omap_dss_device {
int (*get_backlight)(struct omap_dss_device *dssdev);
};
+struct omap_dss_hdmi_data
+{
+ int hpd_gpio;
+};
+
struct omap_dss_driver {
struct device_driver driver;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 7/7] OMAPDSS: HDMI: hot plug detect fix
From: Tomi Valkeinen @ 2012-03-01 12:26 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Rob Clark, Tomi Valkeinen
In-Reply-To: <1330604795-29156-1-git-send-email-tomi.valkeinen@ti.com>
From: Rob Clark <rob@ti.com>
The "OMAPDSS: HDMI: PHY burnout fix" commit switched the HDMI driver
over to using a GPIO for plug detect. Unfortunately the ->detect()
method was not also updated, causing HDMI to no longer work for the
omapdrm driver (because it would actually check if a connection was
detected before attempting to enable display).
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 3683404..aad48a1 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -479,14 +479,7 @@ int ti_hdmi_4xxx_read_edid(struct hdmi_ip_data *ip_data,
bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
{
- int r;
-
- void __iomem *base = hdmi_core_sys_base(ip_data);
-
- /* HPD */
- r = REG_GET(base, HDMI_CORE_SYS_SYS_STAT, 1, 1);
-
- return r = 1;
+ return gpio_get_value(ip_data->hpd_gpio);
}
static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/7] OMAPDSS: HDMI PHY burnout fix for 3.0 stable
From: Tomi Valkeinen @ 2012-03-01 12:34 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
In-Reply-To: <1330604795-29156-1-git-send-email-tomi.valkeinen@ti.com>
This series is for 3.0 stable.
The main patch in this set is the "PHY burnout fix", which implements a fix for
a hardware bug in the OMAP4 HDMI PHY which may cause physical damage to the
board if the HDMI PHY is already enabled when the HDMI cable is plugged in. The
possible damage breaks HDMI output hardware, otherwise the board is unaffected.
The "use default dividers" patch fixes a problem with setting up the HDMI PLL
dividers on Pandaboard. Without the patch the HDMI output does not work at all
on Panda.
The preceding patches are small cleanups/fixes for HDMI GPIOs so that the fix
can be implemented.
Tomi
Tomi Valkeinen (7):
OMAP: DSS2: HDMI: use default dividers
OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
OMAPDSS: remove wrong HDMI HPD muxing
OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
OMAP: 4430SDP/Panda: add HDMI HPD gpio
OMAPDSS: HDMI: PHY burnout fix
arch/arm/mach-omap2/board-4430sdp.c | 31 +++++------
arch/arm/mach-omap2/board-omap4panda.c | 22 +++++---
drivers/video/omap2/dss/hdmi.c | 86 +++++++++++++++++++++++++++++--
include/video/omapdss.h | 5 ++
4 files changed, 113 insertions(+), 31 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH 1/7] OMAP: DSS2: HDMI: use default dividers
From: Tomi Valkeinen @ 2012-03-01 12:34 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen, Mythri P K
In-Reply-To: <1330605286-24166-1-git-send-email-tomi.valkeinen@ti.com>
Use default regn and regm2 dividers in the hdmi driver if the board file
does not define them.
Pandaboard's board file was missing the dividers, causing HDMI output
not to work, so this patch fixes the problem.
Backported from 8d88767a4377171752c22ac39bcb2b505eb751da
Cc: Mythri P K <mythripk@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 9 ---------
drivers/video/omap2/dss/hdmi.c | 15 +++++++++++++--
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 63de2d3..f515fa2 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -617,15 +617,6 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.name = "hdmi",
.driver_name = "hdmi_panel",
.type = OMAP_DISPLAY_TYPE_HDMI,
- .clocks = {
- .dispc = {
- .dispc_fclk_src = OMAP_DSS_CLK_SRC_FCK,
- },
- .hdmi = {
- .regn = 15,
- .regm2 = 1,
- },
- },
.platform_enable = sdp4430_panel_enable_hdmi,
.platform_disable = sdp4430_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index b0555f4..f3369cf 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -40,6 +40,9 @@
#include "hdmi.h"
#include "dss_features.h"
+#define HDMI_DEFAULT_REGN 15
+#define HDMI_DEFAULT_REGM2 1
+
static struct {
struct mutex lock;
struct omap_display_platform_data *pdata;
@@ -1069,7 +1072,11 @@ static void hdmi_compute_pll(struct omap_dss_device *dssdev, int phy,
* Input clock is predivided by N + 1
* out put of which is reference clk
*/
- pi->regn = dssdev->clocks.hdmi.regn;
+ if (dssdev->clocks.hdmi.regn = 0)
+ pi->regn = HDMI_DEFAULT_REGN;
+ else
+ pi->regn = dssdev->clocks.hdmi.regn;
+
refclk = clkin / (pi->regn + 1);
/*
@@ -1077,7 +1084,11 @@ static void hdmi_compute_pll(struct omap_dss_device *dssdev, int phy,
* Multiplying by 100 to avoid fractional part removal
*/
pi->regm = (phy * 100 / (refclk)) / 100;
- pi->regm2 = dssdev->clocks.hdmi.regm2;
+
+ if (dssdev->clocks.hdmi.regm2 = 0)
+ pi->regm2 = HDMI_DEFAULT_REGM2;
+ else
+ pi->regm2 = dssdev->clocks.hdmi.regm2;
/*
* fractional multiplier is remainder of the difference between
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/7] OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
From: Tomi Valkeinen @ 2012-03-01 12:34 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
In-Reply-To: <1330605286-24166-1-git-send-email-tomi.valkeinen@ti.com>
Instead of freeing the GPIOs individually, use gpio_free_array().
Backported from 575753e3bea3b67eef8e454fb87f719e3f7da599
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 3 +--
arch/arm/mach-omap2/board-omap4panda.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index f515fa2..7feefb8 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -609,8 +609,7 @@ static int sdp4430_panel_enable_hdmi(struct omap_dss_device *dssdev)
static void sdp4430_panel_disable_hdmi(struct omap_dss_device *dssdev)
{
- gpio_free(HDMI_GPIO_LS_OE);
- gpio_free(HDMI_GPIO_HPD);
+ gpio_free_array(sdp4430_hdmi_gpios, ARRAY_SIZE(sdp4430_hdmi_gpios));
}
static struct omap_dss_device sdp4430_hdmi_device = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 0cfe200..2e9a6f36 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -645,8 +645,7 @@ static int omap4_panda_panel_enable_hdmi(struct omap_dss_device *dssdev)
static void omap4_panda_panel_disable_hdmi(struct omap_dss_device *dssdev)
{
- gpio_free(HDMI_GPIO_LS_OE);
- gpio_free(HDMI_GPIO_HPD);
+ gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
}
static struct omap_dss_device omap4_panda_hdmi_device = {
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/7] OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
From: Tomi Valkeinen @ 2012-03-01 12:34 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
In-Reply-To: <1330605286-24166-1-git-send-email-tomi.valkeinen@ti.com>
The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in
the board files, but CT_CP_HPD, which is used to enable/disable HPD
functionality.
This patch renames the GPIO.
Backported from 3932a32fcf5393f8be70ac99dc718ad7ad0a415b
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 4 ++--
arch/arm/mach-omap2/board-omap4panda.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 7feefb8..d0a49c3 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -49,7 +49,7 @@
#define ETH_KS8851_QUART 138
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
-#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
static const int sdp4430_keymap[] = {
@@ -591,7 +591,7 @@ static void sdp4430_hdmi_mux_init(void)
}
static struct gpio sdp4430_hdmi_gpios[] = {
- { HDMI_GPIO_HPD, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_hpd" },
+ { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ct_cp_hpd" },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ls_oe" },
};
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 2e9a6f36..bc98749 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -52,7 +52,7 @@
#define GPIO_HUB_NRESET 62
#define GPIO_WIFI_PMENA 43
#define GPIO_WIFI_IRQ 53
-#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
/* wl127x BT, FM, GPS connectivity chip */
@@ -627,7 +627,7 @@ static void omap4_panda_hdmi_mux_init(void)
}
static struct gpio panda_hdmi_gpios[] = {
- { HDMI_GPIO_HPD, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_hpd" },
+ { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ct_cp_hpd" },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, "hdmi_gpio_ls_oe" },
};
--
1.7.4.1
^ permalink raw reply related
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