* viafb cleanup patches - first round
From: Florian Tobias Schandinat @ 2011-03-23 21:47 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel
These series contains a first batch of cleanup patches for 2.6.40.
They should not change the behavior.
All patches are also available at
git://github.com/schandinat/linux-2.6.git viafb-cleanup
and will also show up in linux-next after the early rc's are done.
Thanks,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [trivial PATCH 1/2] treewide: Fix iomap resource size miscalculations
From: Florian Fainelli @ 2011-03-23 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4422b4a8ee132d3adac95fd86237c61b2f8b364.1300909446.git.joe@perches.com>
On Wednesday 23 March 2011 20:55:36 Joe Perches wrote:
> Convert off-by-1 r->end - r->start to resource_size(r)
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Florian Fainelli <florian@openwrt.org>
(for rb532 and bcm63xx_wdt)
> ---
> arch/arm/mach-ux500/mbox-db5500.c | 6 ++----
> arch/mips/rb532/gpio.c | 2 +-
> drivers/video/msm/mddi.c | 2 +-
> drivers/watchdog/bcm63xx_wdt.c | 2 +-
> 4 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/mbox-db5500.c
> b/arch/arm/mach-ux500/mbox-db5500.c index a4ffb9f..2b2d51c 100644
> --- a/arch/arm/mach-ux500/mbox-db5500.c
> +++ b/arch/arm/mach-ux500/mbox-db5500.c
> @@ -416,8 +416,7 @@ struct mbox *mbox_setup(u8 mbox_id, mbox_recv_cb_t
> *mbox_cb, void *priv) dev_dbg(&(mbox->pdev->dev),
> "Resource name: %s start: 0x%X, end: 0x%X\n",
> resource->name, resource->start, resource->end);
> - mbox->virtbase_peer > - ioremap(resource->start, resource->end - resource->start);
> + mbox->virtbase_peer = ioremap(resource->start, resource_size(resource));
> if (!mbox->virtbase_peer) {
> dev_err(&(mbox->pdev->dev), "Unable to ioremap peer mbox\n");
> mbox = NULL;
> @@ -440,8 +439,7 @@ struct mbox *mbox_setup(u8 mbox_id, mbox_recv_cb_t
> *mbox_cb, void *priv) dev_dbg(&(mbox->pdev->dev),
> "Resource name: %s start: 0x%X, end: 0x%X\n",
> resource->name, resource->start, resource->end);
> - mbox->virtbase_local > - ioremap(resource->start, resource->end - resource->start);
> + mbox->virtbase_local = ioremap(resource->start, resource_size(resource));
> if (!mbox->virtbase_local) {
> dev_err(&(mbox->pdev->dev), "Unable to ioremap local mbox\n");
> mbox = NULL;
> diff --git a/arch/mips/rb532/gpio.c b/arch/mips/rb532/gpio.c
> index 37de05d..6c47dfe 100644
> --- a/arch/mips/rb532/gpio.c
> +++ b/arch/mips/rb532/gpio.c
> @@ -185,7 +185,7 @@ int __init rb532_gpio_init(void)
> struct resource *r;
>
> r = rb532_gpio_reg0_res;
> - rb532_gpio_chip->regbase = ioremap_nocache(r->start, r->end - r->start);
> + rb532_gpio_chip->regbase = ioremap_nocache(r->start, resource_size(r));
>
> if (!rb532_gpio_chip->regbase) {
> printk(KERN_ERR "rb532: cannot remap GPIO register 0\n");
> diff --git a/drivers/video/msm/mddi.c b/drivers/video/msm/mddi.c
> index b66d86a..178b072 100644
> --- a/drivers/video/msm/mddi.c
> +++ b/drivers/video/msm/mddi.c
> @@ -679,7 +679,7 @@ static int __devinit mddi_probe(struct platform_device
> *pdev) printk(KERN_ERR "mddi: no associated mem resource!\n");
> return -ENOMEM;
> }
> - mddi->base = ioremap(resource->start, resource->end - resource->start);
> + mddi->base = ioremap(resource->start, resource_size(resource));
> if (!mddi->base) {
> printk(KERN_ERR "mddi: failed to remap base!\n");
> ret = -EINVAL;
> diff --git a/drivers/watchdog/bcm63xx_wdt.c
> b/drivers/watchdog/bcm63xx_wdt.c index 3c5045a..5064e83 100644
> --- a/drivers/watchdog/bcm63xx_wdt.c
> +++ b/drivers/watchdog/bcm63xx_wdt.c
> @@ -248,7 +248,7 @@ static int __devinit bcm63xx_wdt_probe(struct
> platform_device *pdev) return -ENODEV;
> }
>
> - bcm63xx_wdt_device.regs = ioremap_nocache(r->start, r->end - r->start);
> + bcm63xx_wdt_device.regs = ioremap_nocache(r->start, resource_size(r));
> if (!bcm63xx_wdt_device.regs) {
> dev_err(&pdev->dev, "failed to remap I/O resources\n");
> return -ENXIO;
^ permalink raw reply
* Re: [trivial PATCH 1/2] treewide: Fix iomap resource size miscalculations
From: Linus Walleij @ 2011-03-23 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4422b4a8ee132d3adac95fd86237c61b2f8b364.1300909446.git.joe@perches.com>
2011/3/23 Joe Perches <joe@perches.com>:
> Convert off-by-1 r->end - r->start to resource_size(r)
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
(for ux500)
Yours,
Linus Walleij
^ permalink raw reply
* [trivial PATCH 1/2] treewide: Fix iomap resource size miscalculations
From: Joe Perches @ 2011-03-23 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1300909445.git.joe@perches.com>
Convert off-by-1 r->end - r->start to resource_size(r)
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/arm/mach-ux500/mbox-db5500.c | 6 ++----
arch/mips/rb532/gpio.c | 2 +-
drivers/video/msm/mddi.c | 2 +-
drivers/watchdog/bcm63xx_wdt.c | 2 +-
4 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-ux500/mbox-db5500.c b/arch/arm/mach-ux500/mbox-db5500.c
index a4ffb9f..2b2d51c 100644
--- a/arch/arm/mach-ux500/mbox-db5500.c
+++ b/arch/arm/mach-ux500/mbox-db5500.c
@@ -416,8 +416,7 @@ struct mbox *mbox_setup(u8 mbox_id, mbox_recv_cb_t *mbox_cb, void *priv)
dev_dbg(&(mbox->pdev->dev),
"Resource name: %s start: 0x%X, end: 0x%X\n",
resource->name, resource->start, resource->end);
- mbox->virtbase_peer - ioremap(resource->start, resource->end - resource->start);
+ mbox->virtbase_peer = ioremap(resource->start, resource_size(resource));
if (!mbox->virtbase_peer) {
dev_err(&(mbox->pdev->dev), "Unable to ioremap peer mbox\n");
mbox = NULL;
@@ -440,8 +439,7 @@ struct mbox *mbox_setup(u8 mbox_id, mbox_recv_cb_t *mbox_cb, void *priv)
dev_dbg(&(mbox->pdev->dev),
"Resource name: %s start: 0x%X, end: 0x%X\n",
resource->name, resource->start, resource->end);
- mbox->virtbase_local - ioremap(resource->start, resource->end - resource->start);
+ mbox->virtbase_local = ioremap(resource->start, resource_size(resource));
if (!mbox->virtbase_local) {
dev_err(&(mbox->pdev->dev), "Unable to ioremap local mbox\n");
mbox = NULL;
diff --git a/arch/mips/rb532/gpio.c b/arch/mips/rb532/gpio.c
index 37de05d..6c47dfe 100644
--- a/arch/mips/rb532/gpio.c
+++ b/arch/mips/rb532/gpio.c
@@ -185,7 +185,7 @@ int __init rb532_gpio_init(void)
struct resource *r;
r = rb532_gpio_reg0_res;
- rb532_gpio_chip->regbase = ioremap_nocache(r->start, r->end - r->start);
+ rb532_gpio_chip->regbase = ioremap_nocache(r->start, resource_size(r));
if (!rb532_gpio_chip->regbase) {
printk(KERN_ERR "rb532: cannot remap GPIO register 0\n");
diff --git a/drivers/video/msm/mddi.c b/drivers/video/msm/mddi.c
index b66d86a..178b072 100644
--- a/drivers/video/msm/mddi.c
+++ b/drivers/video/msm/mddi.c
@@ -679,7 +679,7 @@ static int __devinit mddi_probe(struct platform_device *pdev)
printk(KERN_ERR "mddi: no associated mem resource!\n");
return -ENOMEM;
}
- mddi->base = ioremap(resource->start, resource->end - resource->start);
+ mddi->base = ioremap(resource->start, resource_size(resource));
if (!mddi->base) {
printk(KERN_ERR "mddi: failed to remap base!\n");
ret = -EINVAL;
diff --git a/drivers/watchdog/bcm63xx_wdt.c b/drivers/watchdog/bcm63xx_wdt.c
index 3c5045a..5064e83 100644
--- a/drivers/watchdog/bcm63xx_wdt.c
+++ b/drivers/watchdog/bcm63xx_wdt.c
@@ -248,7 +248,7 @@ static int __devinit bcm63xx_wdt_probe(struct platform_device *pdev)
return -ENODEV;
}
- bcm63xx_wdt_device.regs = ioremap_nocache(r->start, r->end - r->start);
+ bcm63xx_wdt_device.regs = ioremap_nocache(r->start, resource_size(r));
if (!bcm63xx_wdt_device.regs) {
dev_err(&pdev->dev, "failed to remap I/O resources\n");
return -ENXIO;
--
1.7.4.2.g597a6.dirty
^ permalink raw reply related
* [PATCH 0/2] Fix resource size miscalculations
From: Joe Perches @ 2011-03-23 19:55 UTC (permalink / raw)
To: linux-arm-kernel
Use resource_size a few places
Joe Perches (2):
trivial: treewide: Fix iomap resource size miscalculations
trivial: arm: mach-u300/gpio: Fix mem_region resource size miscalculations
arch/arm/mach-u300/gpio.c | 7 +++----
arch/arm/mach-ux500/mbox-db5500.c | 6 ++----
arch/mips/rb532/gpio.c | 2 +-
drivers/video/msm/mddi.c | 2 +-
drivers/watchdog/bcm63xx_wdt.c | 2 +-
5 files changed, 8 insertions(+), 11 deletions(-)
--
1.7.4.2.g597a6.dirty
^ permalink raw reply
* Re: [PATCH 09/20] video: msm: Split out MDP2.2 HW specific code.
From: Dima Zavin @ 2011-03-23 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300885912.6117.16.camel@m0nster>
>> +config MSM_MDP22
>> + bool
>> + depends on ARCH_MSM7X00A
>> + default y
>> +
>
> You should remove the "default y" and this should be moved to a Kconfig
> under video (shouldn't be added into mach-msm).
Additionally, please have the right MDP version directly 'select'ed by
the ARCH_XXXX definitions instead of doing the 'depends on' business.
--Dima
>
> Daniel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: Jesse Barnes @ 2011-03-23 15:18 UTC (permalink / raw)
To: K, Mythri P; +Cc: Dave Airlie, linux-fbdev, linux-omap, dri-devel, linux-media
In-Reply-To: <AANLkTinMUCbaEVjwZsHG9BxFVjx0YxS=Sw+3gViDJXhg@mail.gmail.com>
On Wed, 23 Mar 2011 18:58:27 +0530
"K, Mythri P" <mythripk@ti.com> wrote:
> Hi Dave,
>
> On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie <airlied@gmail.com> wrote:
> > On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K <mythripk@ti.com> wrote:
> >> Adding support for common EDID parsing in kernel.
> >>
> >> EDID - Extended display identification data is a data structure provided by
> >> a digital display to describe its capabilities to a video source, This a
> >> standard supported by CEA and VESA.
> >>
> >> There are several custom implementations for parsing EDID in kernel, some
> >> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
> >> parsing of EDID should be done in a library, which is agnostic of the
> >> framework (V4l2, DRM, FB) which is using the functionality, just based on
> >> the raw EDID pointer with size/segment information.
> >>
> >> With other RFC's such as the one below, which tries to standardize HDMI API's
> >> It would be better to have a common EDID code in one place.It also helps to
> >> provide better interoperability with variety of TV/Monitor may be even by
> >> listing out quirks which might get missed with several custom implementation
> >> of EDID.
> >> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
> >>
> >> This patch tries to add functions to parse some portion EDID (detailed timing,
> >> monitor limits, AV delay information, deep color mode support, Audio and VSDB)
> >> If we can align on this library approach i can enhance this library to parse
> >> other blocks and probably we could also add quirks from other implementation
> >> as well.
> >>
> >
> > If you want to take this approach, you need to start from the DRM EDID parser,
> > its the most well tested and I can guarantee its been plugged into more monitors
> > than any of the others. There is just no way we would move the DRM parser to a
> > library one that isn't derived from it + enhancements, as we'd throw away the
> > years of testing and the regression count would be way too high.
> >
> I had a look at the DRM EDID code, but for quirks it looks pretty much the same.
> yes i could take quirks and other DRM tested code and enhance, but
> still the code has to do away with struct drm_display_mode
> which is very much custom to DRM.
If that's the only issue you have, we could easily rename that
structure or add conversion funcs to a smaller structure if that's what
you need.
Dave's point is that we can't ditch the existing code without
introducing a lot of risk; it would be better to start a library-ized
EDID codebase from the most complete one we have already, i.e. the DRM
EDID code.
Do you really think the differences between your code and the existing
DRM code are irreconcilable?
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Robert Fekete @ 2011-03-23 14:09 UTC (permalink / raw)
To: Alex Deucher
Cc: Geert Uytterhoeven, dri-devel, timofonic timofonic,
Linux Fbdev development list, wayland-devel, linaro-dev,
linux-media
In-Reply-To: <AANLkTimqkA7GGdT52Ys0b+346Pxr3A=PtDpY0nJ+ycVO@mail.gmail.com>
On 21 March 2011 21:08, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>>> On Mon, 21 Mar 2011 19:19:43 +0000
>>> timofonic timofonic <timofonic@gmail.com> wrote:
>>>> So if KMS is so cool and provides many advantages over fbdev and
>>>> such... Why isn't more widely used intead of still relying on fbdev?
>>>> Why still using fbdev emulation (that is partial and somewhat broken,
>>>> it seems) instead using KMS directly?
>>>
>>> Used by what? All three major GPU device classes have KMS support
>>> (Intel, ATI, and nVidia). If you want it for a particular device, you
>>> can always port it over.
>>
>> The three major GPU device classes on PC...
>
> Sadly it gets worse. A lot of the SoC vendors are adding an fbdev
> emulation layer on top of v4l rather than using fbdev directly or
> using KMS and v4l has grown it's own edid, hdmi, and cec handling.
>
I agree, it is sad that as a SoC vendor there are different
kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say
a Display controller driver. One must also remember that there are big
differences between a desktop/PC multimedia/graphics system and the
ones present on an embedded SoC. It is two very different cultures and
HW designs now trying to merge into one Linux Kernel. Of course there
will be some overlaps but I believe it can be sorted out as soon as we
understand each others different possibilities/limitations. Doing
duplicate work like HDMI will not benefit any party.
Just to list some of the differences.
- Developments within V4L2 has mainly been driven by embedded devices
while DRM is a result of desktop Graphics cards. And for some extent
also solving different problems.
- Embedded devices usually have several different hw IP's managing
displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's,
2D blitters, Open GL ES hw, all of which have a separate device/driver
in the kernel, while on a desktop nowadays all this functionality
usually resides on ONE graphics card, hence one DRM device for all.
- DRM is closely developed in conjunction with desktop/Xorg, while X11
on an embedded device is not very 2011...wayland on the other hand is
:-), but do wayland really need the full potential of DRM/DRI or just
parts of it.
- Copying buffers is really bad for embedded devices due to lower
memory bandwidth and power consumption while on a Desktop memory
bandwidth is from an other galaxy (copying still bad but accepted it
seems), AND embedded devices of today records and plays/displays 1080p
content as well.
- Not all embedded devices have MMU's for each IP requiring physical
contiguous memory, while on a desktop MMU's have been present for
ages.
- Embedded devices are usually ARM based SoCs while x86 dominates the
Desktop/Laptop market, and functionality provided is soon the very
same.
- yada yada....The list can grow very long....There are also
similarities of course.
The outcome is that SoC vendors likes the embedded friendliness of
v4l2 and fbdev while "we" also glance at the DRM part due to its
de-facto standard on desktop environments. But from an embedded point
of view DRM lacks the support for interconnecting multiple
devices/drivers mentioned above, GEM/TTM is valid within a DRM device,
the execution/context management is not needed,, no overlays(or
similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but
the rest of DRM will likely not be heavily used on SoCs unless running
X11 as well. Most likely this worked on as well within the DRI
community. I can see good features all over the place(sometimes
duplicated) but not find one single guideline/API that solves all the
embedded SoC problems (which involves use-cases optimized for no-copy
cross media/drivers).
Last but not least...
On Linaro there is already discussions ongoing to solve one of the
biggest issues from a SoC point of view and that is a "System Wide
Memory manager" which manages buffer sharing and resolves no-copy use
cases between devices/drivers. Read more on the following thread:
http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html.
BR
/Robert Fekete
st-ericsson
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: K, Mythri P @ 2011-03-23 13:59 UTC (permalink / raw)
To: Paul Mundt; +Cc: Mauro Carvalho Chehab, linux-fbdev, linux-omap, linux-media
In-Reply-To: <20110322175810.GA32416@linux-sh.org>
Hi Paul,
On Tue, Mar 22, 2011 at 11:28 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Mar 22, 2011 at 02:52:59PM -0300, Mauro Carvalho Chehab wrote:
>> Em 22-03-2011 14:32, Mythri P K escreveu:
>> > Adding support for common EDID parsing in kernel.
>> >
>> > EDID - Extended display identification data is a data structure provided by
>> > a digital display to describe its capabilities to a video source, This a
>> > standard supported by CEA and VESA.
>> >
>> > There are several custom implementations for parsing EDID in kernel, some
>> > of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
>> > parsing of EDID should be done in a library, which is agnostic of the
>> > framework (V4l2, DRM, FB) which is using the functionality, just based on
>> > the raw EDID pointer with size/segment information.
>> >
>> > With other RFC's such as the one below, which tries to standardize HDMI API's
>> > It would be better to have a common EDID code in one place.It also helps to
>> > provide better interoperability with variety of TV/Monitor may be even by
>> > listing out quirks which might get missed with several custom implementation
>> > of EDID.
>> > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
>> >
>> > This patch tries to add functions to parse some portion EDID (detailed timing,
>> > monitor limits, AV delay information, deep color mode support, Audio and VSDB)
>> > If we can align on this library approach i can enhance this library to parse
>> > other blocks and probably we could also add quirks from other implementation
>> > as well.
>> >
>> > Signed-off-by: Mythri P K <mythripk@ti.com>
>> > ---
>> > arch/arm/include/asm/edid.h | 243 ++++++++++++++++++++++++++++++
>> > drivers/video/edid.c | 340 +++++++++++++++++++++++++++++++++++++++++++
>>
>> Hmm... if you want this to be agnostic, the header file should not be inside
>> arch/arm, but on some other place, like include/video/.
>>
> Ironically this adds a drivers/video/edid.c but completely ignores
> drivers/video/edid.h which already exists and already contains many of
> these definitions.
>
> I like the idea of a generalized library, but it would be nice to see the
> existing edid.h evolved and its users updated incrementally.
>
well yes , That could be enhanced and that would take care of Mauro's
comment too.
Thanks and regards,
Mythri.
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: K, Mythri P @ 2011-03-23 13:40 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-fbdev, linux-omap, linux-media, dri-devel
In-Reply-To: <AANLkTim61Xdo6ED7mr_SvpLuotso89RdR6Qaz-GCXOmJ@mail.gmail.com>
Hi Dave,
On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie <airlied@gmail.com> wrote:
> On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K <mythripk@ti.com> wrote:
>> Adding support for common EDID parsing in kernel.
>>
>> EDID - Extended display identification data is a data structure provided by
>> a digital display to describe its capabilities to a video source, This a
>> standard supported by CEA and VESA.
>>
>> There are several custom implementations for parsing EDID in kernel, some
>> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
>> parsing of EDID should be done in a library, which is agnostic of the
>> framework (V4l2, DRM, FB) which is using the functionality, just based on
>> the raw EDID pointer with size/segment information.
>>
>> With other RFC's such as the one below, which tries to standardize HDMI API's
>> It would be better to have a common EDID code in one place.It also helps to
>> provide better interoperability with variety of TV/Monitor may be even by
>> listing out quirks which might get missed with several custom implementation
>> of EDID.
>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
>>
>> This patch tries to add functions to parse some portion EDID (detailed timing,
>> monitor limits, AV delay information, deep color mode support, Audio and VSDB)
>> If we can align on this library approach i can enhance this library to parse
>> other blocks and probably we could also add quirks from other implementation
>> as well.
>>
>
> If you want to take this approach, you need to start from the DRM EDID parser,
> its the most well tested and I can guarantee its been plugged into more monitors
> than any of the others. There is just no way we would move the DRM parser to a
> library one that isn't derived from it + enhancements, as we'd throw away the
> years of testing and the regression count would be way too high.
>
I had a look at the DRM EDID code, but for quirks it looks pretty much the same.
yes i could take quirks and other DRM tested code and enhance, but
still the code has to do away with struct drm_display_mode
which is very much custom to DRM.
> Dave.
>
Thanks and regards,
Mythri.
^ permalink raw reply
* Re: [PATCH 09/20] video: msm: Split out MDP2.2 HW specific code.
From: Daniel Walker @ 2011-03-23 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485423-27281-1-git-send-email-carlv@codeaurora.org>
On Fri, 2011-03-18 at 14:57 -0700, Carl Vanderlip wrote:
> index df9d74e..d6e75c3 100644
> --- a/arch/arm/mach-msm/Kconfig
> +++ b/arch/arm/mach-msm/Kconfig
> @@ -76,6 +76,11 @@ config HAS_MSM_DEBUG_UART_PHYS
> config MSM_VIC
> bool
>
> +config MSM_MDP22
> + bool
> + depends on ARCH_MSM7X00A
> + default y
> +
You should remove the "default y" and this should be moved to a Kconfig
under video (shouldn't be added into mach-msm).
Daniel
^ permalink raw reply
* Re: [GIT PULL] viafb fixes for 2.6.39
From: Paul Mundt @ 2011-03-23 12:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <4D89E6B5.8080005@gmx.de>
On Wed, Mar 23, 2011 at 01:25:25PM +0100, Florian Tobias Schandinat wrote:
> please pull the viafb fixes below.
> They fix the handling of refresh rates which should now work (or at least
> work much better than it did before). Especially the initial refresh rate
> as passed in via module parameter is now handled correct. Before these
> patches this didn't work for higher refresh rates.
>
I half expected there to be another pull request while I was writing mine
up.. :-)
I'll pull them once Linus pulls and make sure they're lumped in for -rc2.
^ permalink raw reply
* [GIT PULL] fbdev updates for 2.6.39-rc1, part 2.
From: Paul Mundt @ 2011-03-23 12:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel
Here's the second batch of fbdev updates. The bulk of this is OMAP DSS
churn that had some dependencies on both the ARM and OMAP merges that
have since settled. The rest is basically random fixes, svgalib
modernization, and the usual smattering of driver updates.
This does not yet include Andy Whitcroft's registration locking or the
suspend/resume console locking fixes as we still need to make a few
changes and do some more testing (as well as getting confirmation that
things still work in both cases). My intention is to have that sorted out
for -rc2.
I noticed a few other fb drivers and churn popped up from various other
trees, but that should hopefully begin to slow down now that things are
for the most part being centrally maintained (the bulk of the ARM SoC trees
for example seem to prefer to lump all of their driver changes together
rather than going through subsystem trees -- basically all of them but
OMAP and SH/R-Mobile, but in general folks have been pretty good with
making sure patches still hit the lists and at least have some tentative
review, as with the unicore32 merge).
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/fbdev-2.6.git
Which contains:
Aaro Koskinen (6):
sisfb: POST should fail if R/W test fails
sisfb: move XGI POST RAM type detection into a subroutine
sisfb: add subroutine for detecting XGI Z9
sisfb: add RAM type detection for XGI Z9
sisfb: move XGI POST DDR2 bootup code into subroutines
sisfb: add support for XGI Z9 DDR2 POST
Andreas Bießmann (2):
atmel_lcdfb: implement inverted contrast pwm
atmel_lcdfb: add fb_blank function
Archit Taneja (15):
OMAP2PLUS: DSS2: Generalize naming of PRCM related clock enums in DSS driver
OMAP2PLUS: DSS2: Generalize external clock names in struct dss of dss.c
OMAP: DSS2: Have separate irq handlers for DISPC and DSI
OMAP2PLUS: DSS2: FEATURES: DISPC overlay code cleanup
OMAP2PLUS: DSS2: FEATURES: Function to Provide the max fck supported
OMAP2PLUS: DSS2: Make members of dss_clk_source generic
OMAP2PLUS: DSS2: Use dss features to get clock source names of current OMAP
OMAP2PLUS: DSS2: DSI: Generalize DSI PLL Clock Naming
OMAP: DSS2: Functions to request/release DSI VCs
OMAP: DSS2: Use request / release calls in Taal for DSI Virtual Channels.
OMAP2PLUS: DSS2: Cleanup clock source related code
OMAP4: DSS2: Clock source changes for OMAP4
OMAP2PLUS: DSS2: FEATURES: Fix usage of dss_reg_field and dss_clk_source_name
OMAP: DSS2: FEATURES: Functions to return min and max values of parameters
OMAP: DSS2: FEATURES: DSI PLL parameter cleanup
Axel Lin (7):
video: hpfb: use resource_size()
video: sh7760fb: use resource_size()
video: ffb: fix ffb_probe error path
video: s3c-fb: return proper error if clk_get fails
video: hecubafb: add __devexit_p around reference to hecubafb_remove
video: metronomefb: add __devexit_p around reference to metronomefb_remove
video: add missing framebuffer_release in error path
Dan Carpenter (1):
fbdev: sh_mobile_lcdc: checking NULL instead of IS_ERR()
Dave Airlie (1):
fbcon: fix situation where fbcon gets deinitialised and can't reinit.
David Miller (22):
svga: Use proper VGA register name macros in svga_wattr.
svga: Make svga_wattr take an iomem regbase pointer.
svga: Make svga_wcrt_multi take an iomem regbase pointer.
svga: Make svga_wseq_multi take an iomem regbase pointer.
svga: Make svga_set_default_gfx_regs take an iomem regbase pointer.
svga: Make svga_set_default_atc_regs take an iomem regbase pointer.
svga: Make svga_set_default_seq_regs take an iomem regbase pointer.
svga: Make svga_wseq_mask() take an iomem regbase pointer.
svga: Make svga_wcrt_mask() take an iomem regbase pointer.
svga: Make svga_set_default_crt_regs() take an iomem regbase pointer.
svga: Make svga_set_textmode_vga_regs() take an iomem regbase pointer.
svga: Make svga_tilecursor() take an iomem regbase pointer.
svga: Make svga_set_timings() take an iomem regbase pointer.
arkfb: Pass par->state.vgabase to vga_*() calls.
s3fb: Pass par->state.vgabase to vga_*() calls.
vt8623fb: Pass par->state.vgabase to vga_*() calls.
arkfb: Don't clobber par->state.vgabase during open method.
s3fb: Don't clobber par->state.vgabase during open method.
vt8623fb: Don't clobber par->state.vgabase during open method.
s3fb: Compute VGA base iomem pointer explicitly.
arkfb: Compute VGA base iomem pointer explicitly.
vt8623fb: Compute VGA base iomem pointer explicitly.
Heiko Schocher (3):
video, sm501: add I/O functions for use on powerpc
video, sm501: add edid and commandline support
video, sm501: add OF binding to support SM501
Henry Nestler (1):
fbcon: Bugfix soft cursor detection in Tile Blitting
Jani Nikula (1):
OMAP: DSS2: Fix def_disp module param description
Jarkko Nikula (1):
omapfb: Fix linker error in drivers/video/omap/lcd_2430sdp.c
Jean Delvare (1):
radeonfb: Let hwmon driver probe the "monid" I2C bus
Justin P. Mattock (1):
drivers:video:aty:radeon_base Fix typo occationally to occasionally
Kirill A. Shutemov (2):
omap: use list_move() instead of list_del()/list_add() combination
vmlfb: use list_move() instead of list_del()/list_add() combination
Martin Decky (1):
video: Fix EDID macros H_SYNC_WIDTH and H_SYNC_OFFSET
Mayuresh Janorkar (4):
OMAP2PLUS: DSS2: Add OMAP4 Kconfig support
OMAP4: DSS2: Add hwmod device names for OMAP4.
OMAPFB: Adding a check for timings in set_def_mode
OMAP: OMAPFB: Adding help for FB_OMAP_LCD_VGA option
Murthy, Raghuveer (5):
OMAP: DSS2: Adding dss_features for independent core clk divider
OMAP: DSS2: Renaming register macro DISPC_DIVISOR(ch)
OMAP4: DSS2: Using dss_features to set independent core clock divider
OMAP: DSS2: Implement OMAP4 DSS fclk support
OMAP4: PandaBoard: Adding DVI support
Mythri P K (10):
OMAP4: DSS2: Add display type HDMI to DSS2
OMAP4: DSS2: HDMI: Select between HDMI VENC clock source.
OMAP4: DSS2: HDMI: Dispc gamma enable set/reset function for TV.
OMAP4: DSS2: HDMI: HDMI driver header file addition
OMAP4: DSS2: HDMI: HDMI driver addition in the DSS
OMAP4: DSS2: HDMI: HDMI panel driver addition in the DSS
OMAP4: DSS2: HDMI: Add makefile and kconfig changes to enable HDMI in OMAP4
OMAP4: DSS: HDMI: Call to HDMI module init to register driver.
OMAP4: HDMI: Add HDMI structure in the board file for OMAP4 SDP
OMAP4: HDMI: Add HDMI structure in the board file for OMAP4 PANDA
Ondrej Zary (5):
s3fb: maximize virtual vertical size for fast scrolling
s3fb: add support for 86C365 Trio3D
s3fb: fix 15/16bpp modes with over 115MHz pixclocks on 86C365 Trio3D
s3fb: enable DTPC
s3fb: use new start address register
Paul Mundt (4):
mailmap: Update for OMAP DSS developers.
video: Move sm501fb devicetree binding documentation to a better place.
MAINTAINERS: Add file pattern for fb dt bindings.
MAINTAINERS: de-orphan fbdev.
Samreen (1):
OMAP2/3/4: DSS2: Enable Display SubSystem as modules
Senthilvadivu Guruswamy (9):
OMAP2,3: DSS2: Build omap_device for each DSS HWIP
OMAP2, 3: DSS2: DSS: create platform_driver, move init, exit to driver
OMAP2, 3: DSS2: Move clocks from core driver to dss driver
OMAP2, 3: DSS2: RFBI: create platform_driver, move init, exit to driver
OMAP2, 3: DSS2: DISPC: create platform_driver, move init, exit to driver
OMAP2, 3: DSS2: VENC: create platform_driver, move init, exit to driver
OMAP2, 3: DSS2: DSI: create platform_driver, move init, exit to driver
OMAP2,3: DSS2: Use platform device to get baseaddr
OMAP2,3: DSS2: Get DSS IRQ from platform device
Steve Sakoman (5):
OMAP: DSS2: Add support for LG Philips LB035Q02 panel
OMAP: DSS2: Add DSS2 support for Overo
omap: overo: Add regulator for ads7846
OMAP: Add gpio-leds support for Overo
OMAP: Add gpio-keys support for Overo
Sumit Semwal (6):
OMAP2, 3: DSS2: remove forced clk-disable from omap_dss_remove
OMAP2,3: DSS2: replace printk with dev_dbg in init
OMAP2PLUS: clocks: Align DSS clock names and roles
OMAP4: DSS2: clocks: Add ick as dummy clock
OMAP2PLUS:DSS2: add opt_clock_available in pdata
OMAP2PLUS:DSS2: Use opt_clock_available from pdata
Thomas Schlichter (1):
uvesafb,vesafb: create WC or WB PAT-entries
Tomi Valkeinen (25):
OMAP: 3430SDP: Remove unused vdda_dac supply
OMAP: DSS2: Delay regulator_get() calls
OMAP: DSS2: Support for Samsung LTE430WQ-F0C
MAINTAINERS: Update OMAP DSS maintainer
OMAP: DSS2: Clean up a switch-case
OMAP: DSS2: FEATURES: Remove SDI from 3630 displays
OMAP: DSS2: FEATURES: Remove DSI & SDI from OMAP2
OMAP: DSS2: Check for SDI HW before accessing SDI registers
OMAP: DSS2: Remove unused list
OMAP: DSS2: DSI: remove unused function
OMAP: DSS2: Remove FB_OMAP_BOOTLOADER_INIT support
OMAP: DSS2: Remove pdev argument from dpi_init
OMAP: DSS2: Move DPI & SDI init into DSS plat driver
OMAP: DSS2: Remove unneeded cpu_is_xxx checks
HACK: OMAP: DSS2: Fix OMAP2_DSS_USE_DSI_PLL
HACK: OMAP: DSS2: add delay after enabling clocks
OMAP: DSS2: fix omap_dispc_register_isr() fail path
HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to prevent crash
OMAP: DSS2: DSI: Restructure IRQ handler
OMAP: DSS2: DSI: Add ISR support
OMAP: DSS2: DSI: use ISR in send_bta_sync
OMAP: DSS2: DSI: use ISR for BTA in framedone
OMAP: DSS2: DSI: catch DSI errors in send_bta_sync
OMAP: DSS2: DSI: fix IRQ debug prints
OMAP: DSS2: Clean up for dpll4_m4_ck handling
.mailmap | 4 +
Documentation/devicetree/bindings/fb/sm501fb.txt | 34 +
Documentation/fb/sm501.txt | 10 +
MAINTAINERS | 8 +-
arch/arm/configs/omap2plus_defconfig | 11 +
arch/arm/mach-omap2/board-3430sdp.c | 6 +-
arch/arm/mach-omap2/board-4430sdp.c | 75 ++
arch/arm/mach-omap2/board-cm-t35.c | 2 +-
arch/arm/mach-omap2/board-devkit8000.c | 12 +-
arch/arm/mach-omap2/board-igep0020.c | 10 +-
arch/arm/mach-omap2/board-omap3beagle.c | 12 +-
arch/arm/mach-omap2/board-omap3evm.c | 12 +-
arch/arm/mach-omap2/board-omap3pandora.c | 3 +-
arch/arm/mach-omap2/board-omap3stalker.c | 12 +-
arch/arm/mach-omap2/board-omap4panda.c | 203 +++-
arch/arm/mach-omap2/board-overo.c | 357 +++++-
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c | 12 +-
arch/arm/mach-omap2/clock2420_data.c | 8 +-
arch/arm/mach-omap2/clock2430_data.c | 8 +-
arch/arm/mach-omap2/clock3xxx_data.c | 14 +-
arch/arm/mach-omap2/clock44xx_data.c | 15 +-
arch/arm/mach-omap2/display.c | 80 ++
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 13 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 12 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 23 +-
arch/arm/plat-omap/include/plat/display.h | 15 +-
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 2 +-
drivers/mfd/sm501.c | 134 +-
drivers/video/arkfb.c | 160 ++-
drivers/video/atmel_lcdfb.c | 31 +-
drivers/video/aty/radeon_base.c | 2 +-
drivers/video/aty/radeon_i2c.c | 3 +
drivers/video/cg14.c | 1 +
drivers/video/cg6.c | 1 +
drivers/video/console/fbcon.c | 4 +-
drivers/video/console/tileblit.c | 2 +-
drivers/video/edid.h | 4 +-
drivers/video/ffb.c | 2 +-
drivers/video/hecubafb.c | 2 +-
drivers/video/hpfb.c | 6 +-
drivers/video/metronomefb.c | 2 +-
drivers/video/omap/Kconfig | 7 +-
drivers/video/omap/blizzard.c | 3 +-
drivers/video/omap/hwa742.c | 3 +-
drivers/video/omap2/displays/Kconfig | 6 +
drivers/video/omap2/displays/Makefile | 1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 25 +
.../omap2/displays/panel-lgphilips-lb035q02.c | 279 ++++
drivers/video/omap2/displays/panel-taal.c | 123 +-
drivers/video/omap2/dss/Kconfig | 14 +-
drivers/video/omap2/dss/Makefile | 2 +
drivers/video/omap2/dss/core.c | 480 +-------
drivers/video/omap2/dss/dispc.c | 335 ++++--
drivers/video/omap2/dss/display.c | 35 +-
drivers/video/omap2/dss/dpi.c | 45 +-
drivers/video/omap2/dss/dsi.c | 967 +++++++++++----
drivers/video/omap2/dss/dss.c | 763 +++++++++--
drivers/video/omap2/dss/dss.h | 153 ++-
drivers/video/omap2/dss/dss_features.c | 163 ++-
drivers/video/omap2/dss/dss_features.h | 27 +
drivers/video/omap2/dss/hdmi.c | 1332 ++++++++++++++++++++
drivers/video/omap2/dss/hdmi.h | 415 ++++++
drivers/video/omap2/dss/hdmi_omap4_panel.c | 222 ++++
drivers/video/omap2/dss/manager.c | 13 +-
drivers/video/omap2/dss/overlay.c | 10 +-
drivers/video/omap2/dss/rfbi.c | 128 ++-
drivers/video/omap2/dss/sdi.c | 62 +-
drivers/video/omap2/dss/venc.c | 128 ++-
drivers/video/omap2/omapfb/Kconfig | 6 +-
drivers/video/omap2/omapfb/omapfb-main.c | 23 +-
drivers/video/s3c-fb.c | 1 +
drivers/video/s3fb.c | 341 +++--
drivers/video/sh7760fb.c | 4 +-
drivers/video/sh_mobile_lcdcfb.c | 5 +-
drivers/video/sis/sis.h | 1 +
drivers/video/sis/sis_main.c | 315 ++++--
drivers/video/sis/vgatypes.h | 1 +
drivers/video/sm501fb.c | 275 +++--
drivers/video/svgalib.c | 175 ++--
drivers/video/tcx.c | 1 +
drivers/video/uvesafb.c | 49 +-
drivers/video/vermilion/vermilion.c | 3 +-
drivers/video/vesafb.c | 44 +-
drivers/video/vt8623fb.c | 157 ++-
include/linux/sm501.h | 8 +
include/linux/svga.h | 34 +-
include/video/atmel_lcdc.h | 1 +
88 files changed, 6494 insertions(+), 2020 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/sm501fb.txt
create mode 100644 Documentation/fb/sm501.txt
create mode 100644 drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
create mode 100644 drivers/video/omap2/dss/hdmi.c
create mode 100644 drivers/video/omap2/dss/hdmi.h
create mode 100644 drivers/video/omap2/dss/hdmi_omap4_panel.c
^ permalink raw reply
* [GIT PULL] viafb fixes for 2.6.39
From: Florian Tobias Schandinat @ 2011-03-23 12:25 UTC (permalink / raw)
To: linux-fbdev
Hi Paul,
please pull the viafb fixes below.
They fix the handling of refresh rates which should now work (or at least work
much better than it did before). Especially the initial refresh rate as passed
in via module parameter is now handled correct. Before these patches this didn't
work for higher refresh rates.
Thanks,
Florian Tobias Schandinat
The following changes since commit 2563afa9ec6970f3545906382cc986ee012f60ec:
Florian Tobias Schandinat (1):
Merge branch 'viafb-pll' into viafb-next
are available in the git repository at:
git://github.com/schandinat/linux-2.6.git viafb-next
Florian Tobias Schandinat (2):
viafb: refresh rate bug collection
viafb: initialize margins correct
drivers/video/via/chip.h | 1 -
drivers/video/via/hw.c | 17 ++++------
drivers/video/via/hw.h | 3 +-
drivers/video/via/viafbdev.c | 74 +++++++++++++++++++++--------------------
4 files changed, 46 insertions(+), 49 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] omap display subsystem changes for 2.6.39
From: Tomi Valkeinen @ 2011-03-23 7:46 UTC (permalink / raw)
To: Felipe Contreras, Tony Lindgren
Cc: Paul Mundt, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org
In-Reply-To: <AANLkTimSoaxGhjbgMx6b3duAV75HwO0S+=1mJhOnEvvD@mail.gmail.com>
On Tue, 2011-03-22 at 13:49 -0500, Felipe Contreras wrote:
> On Mon, Mar 21, 2011 at 11:51 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a
> > bit of them, and many changes also in arch/arm/mach-omap2, which
> > unfortunately couldn't go through Tony's linux-omap tree due to
> > dependencies on DSS driver code.
>
> What about this one?
> http://article.gmane.org/gmane.linux.ports.arm.omap/44975
I seem to have missed that one. But I think that should go through
Tony's tree to avoid conflicts. Tony?
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: Dave Airlie @ 2011-03-23 0:46 UTC (permalink / raw)
To: Mythri P K; +Cc: linux-fbdev, linux-omap, linux-media, dri-devel
In-Reply-To: <1300815176-21206-1-git-send-email-mythripk@ti.com>
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K <mythripk@ti.com> wrote:
> Adding support for common EDID parsing in kernel.
>
> EDID - Extended display identification data is a data structure provided by
> a digital display to describe its capabilities to a video source, This a
> standard supported by CEA and VESA.
>
> There are several custom implementations for parsing EDID in kernel, some
> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
> parsing of EDID should be done in a library, which is agnostic of the
> framework (V4l2, DRM, FB) which is using the functionality, just based on
> the raw EDID pointer with size/segment information.
>
> With other RFC's such as the one below, which tries to standardize HDMI API's
> It would be better to have a common EDID code in one place.It also helps to
> provide better interoperability with variety of TV/Monitor may be even by
> listing out quirks which might get missed with several custom implementation
> of EDID.
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
>
> This patch tries to add functions to parse some portion EDID (detailed timing,
> monitor limits, AV delay information, deep color mode support, Audio and VSDB)
> If we can align on this library approach i can enhance this library to parse
> other blocks and probably we could also add quirks from other implementation
> as well.
>
If you want to take this approach, you need to start from the DRM EDID parser,
its the most well tested and I can guarantee its been plugged into more monitors
than any of the others. There is just no way we would move the DRM parser to a
library one that isn't derived from it + enhancements, as we'd throw away the
years of testing and the regression count would be way too high.
Dave.
^ permalink raw reply
* Re: [PATCH v6 0/6] powerpc, 52xx: add charon board support
From: Grant Likely @ 2011-03-22 20:58 UTC (permalink / raw)
To: Heiko Schocher
Cc: linuxppc-dev, Wolfram Sang, Benjamin Herrenschmidt, linux-fbdev,
devicetree-discuss, Ben Dooks, Vincent Sanders, Samuel Ortiz,
linux-kernel, Randy Dunlap, Wolfgang Denk, Paul Mundt
In-Reply-To: <1300782452-528-1-git-send-email-hs@denx.de>
On Tue, Mar 22, 2011 at 2:27 AM, Heiko Schocher <hs@denx.de> wrote:
> cc: Wolfram Sang <w.sang@pengutronix.de>
> cc: Grant Likely <grant.likely@secretlab.ca>
> cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> cc: linux-fbdev@vger.kernel.org
> cc: devicetree-discuss@ozlabs.org
> cc: Ben Dooks <ben@simtec.co.uk>
> cc: Vincent Sanders <vince@simtec.co.uk>
> cc: Samuel Ortiz <sameo@linux.intel.com>
> cc: linux-kernel@vger.kernel.org
> cc: Randy Dunlap <rdunlap@xenotime.net>
> cc: Wolfgang Denk <wd@denx.de>
> cc: Paul Mundt <lethal@linux-sh.org>
>
> changes since v5:
> - repost complete patchseries, as Paul Mundt suggested
> - rebased against current head
> - add Acked-by from Samuel Ortiz (MFD parts)
> http://www.spinics.net/lists/linux-fbdev/msg02550.html
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html
>
> and Benjamin Herrenschmidt (DTS parts)
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html
> - removed patch
> "powerpc, mpc5200: update mpc5200_defconfig to fit for charon board."
> therefore added
> "powerpc, tqm5200: update tqm5200_defconfig to fit for charon board."
Why? As Wolfram mentioned, I'd rather see mpc5200 defconfig used.
Eventually I'd like to remove tqm5200_defconfig
I'll look through the rest of the patches soon.
g.
^ permalink raw reply
* Re: [GIT PULL] omap display subsystem changes for 2.6.39
From: Felipe Contreras @ 2011-03-22 18:49 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Paul Mundt, linux-fbdev, linux-omap
In-Reply-To: <1300701083.2891.77.camel@deskari>
On Mon, Mar 21, 2011 at 11:51 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a
> bit of them, and many changes also in arch/arm/mach-omap2, which
> unfortunately couldn't go through Tony's linux-omap tree due to
> dependencies on DSS driver code.
What about this one?
http://article.gmane.org/gmane.linux.ports.arm.omap/44975
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: Alex Deucher @ 2011-03-22 18:32 UTC (permalink / raw)
To: Mythri P K
Cc: linux-fbdev, linux-omap, linux-media,
Maling list - DRI developers
In-Reply-To: <1300815176-21206-1-git-send-email-mythripk@ti.com>
Adding dri-devel.
On Tue, Mar 22, 2011 at 1:32 PM, Mythri P K <mythripk@ti.com> wrote:
> Adding support for common EDID parsing in kernel.
>
> EDID - Extended display identification data is a data structure provided by
> a digital display to describe its capabilities to a video source, This a
> standard supported by CEA and VESA.
>
> There are several custom implementations for parsing EDID in kernel, some
> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
> parsing of EDID should be done in a library, which is agnostic of the
> framework (V4l2, DRM, FB) which is using the functionality, just based on
> the raw EDID pointer with size/segment information.
>
> With other RFC's such as the one below, which tries to standardize HDMI API's
> It would be better to have a common EDID code in one place.It also helps to
> provide better interoperability with variety of TV/Monitor may be even by
> listing out quirks which might get missed with several custom implementation
> of EDID.
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
>
> This patch tries to add functions to parse some portion EDID (detailed timing,
> monitor limits, AV delay information, deep color mode support, Audio and VSDB)
> If we can align on this library approach i can enhance this library to parse
> other blocks and probably we could also add quirks from other implementation
> as well.
>
> Signed-off-by: Mythri P K <mythripk@ti.com>
> ---
> arch/arm/include/asm/edid.h | 243 ++++++++++++++++++++++++++++++
> drivers/video/edid.c | 340 +++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 583 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/include/asm/edid.h
> create mode 100644 drivers/video/edid.c
>
> diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h
> new file mode 100644
> index 0000000..843346a
> --- /dev/null
> +++ b/arch/arm/include/asm/edid.h
> @@ -0,0 +1,243 @@
> +/*
> + * edid.h
> + *
> + * Copyright (C) 2011 Texas Instruments
> + * Author: Mythri P K <mythripk@ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + * History:
> + */
> +
> +#ifndef _EDID_H_
> +#define _EDID_H_
> +
> +/* HDMI EDID Length */
> +#define HDMI_EDID_MAX_LENGTH 512
> +
> +/* HDMI EDID Extension Data Block Tags */
> +#define HDMI_EDID_EX_DATABLOCK_TAG_MASK 0xE0
> +#define HDMI_EDID_EX_DATABLOCK_LEN_MASK 0x1F
> +
> +#define EDID_TIMING_DESCRIPTOR_SIZE 0x12
> +#define EDID_DESCRIPTOR_BLOCK0_ADDRESS 0x36
> +#define EDID_DESCRIPTOR_BLOCK1_ADDRESS 0x80
> +#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
> +#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
> +
> +/* EDID Detailed Timing Info 0 begin offset */
> +#define HDMI_EDID_DETAILED_TIMING_OFFSET 0x36
> +
> +#define HDMI_EDID_PIX_CLK_OFFSET 0
> +#define HDMI_EDID_H_ACTIVE_OFFSET 2
> +#define HDMI_EDID_H_BLANKING_OFFSET 3
> +#define HDMI_EDID_V_ACTIVE_OFFSET 5
> +#define HDMI_EDID_V_BLANKING_OFFSET 6
> +#define HDMI_EDID_H_SYNC_OFFSET 8
> +#define HDMI_EDID_H_SYNC_PW_OFFSET 9
> +#define HDMI_EDID_V_SYNC_OFFSET 10
> +#define HDMI_EDID_V_SYNC_PW_OFFSET 11
> +#define HDMI_EDID_H_IMAGE_SIZE_OFFSET 12
> +#define HDMI_EDID_V_IMAGE_SIZE_OFFSET 13
> +#define HDMI_EDID_H_BORDER_OFFSET 15
> +#define HDMI_EDID_V_BORDER_OFFSET 16
> +#define HDMI_EDID_FLAGS_OFFSET 17
> +
> +/* HDMI EDID DTDs */
> +#define HDMI_EDID_MAX_DTDS 4
> +
> +/* HDMI EDID DTD Tags */
> +#define HDMI_EDID_DTD_TAG_MONITOR_NAME 0xFC
> +#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM 0xFF
> +#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS 0xFD
> +#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA 0xFA
> +#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA 0xFB
> +#define HDMI_EDID_DTD_TAG_ASCII_STRING 0xFE
> +
> +#define HDMI_IMG_FORMAT_MAX_LENGTH 20
> +#define HDMI_AUDIO_FORMAT_MAX_LENGTH 10
> +
> +/* HDMI EDID Extenion Data Block Values: Video */
> +#define HDMI_EDID_EX_VIDEO_NATIVE 0x80
> +#define HDMI_EDID_EX_VIDEO_MASK 0x7F
> +#define HDMI_EDID_EX_VIDEO_MAX 35
> +
> +#define STANDARD_HDMI_TIMINGS_NB 34
> +#define STANDARD_HDMI_TIMINGS_VESA_START 15
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +enum extension_edid_db {
> + DATABLOCK_AUDIO = 1,
> + DATABLOCK_VIDEO = 2,
> + DATABLOCK_VENDOR = 3,
> + DATABLOCK_SPEAKERS = 4,
> +};
> +
> +struct img_edid {
> + bool pref;
> + int code;
> +};
> +
> +struct image_format {
> + int length;
> + struct img_edid fmt[HDMI_IMG_FORMAT_MAX_LENGTH];
> +};
> +
> +struct audio_edid {
> + int num_of_ch;
> + int format;
> +};
> +
> +struct audio_format {
> + int length;
> + struct audio_edid fmt[HDMI_AUDIO_FORMAT_MAX_LENGTH];
> +};
> +
> +struct latency {
> + /* vid: if indicated, value=1+ms/2 with a max of 251 meaning 500ms */
> + int vid_latency;
> + int aud_latency;
> + int int_vid_latency;
> + int int_aud_latency;
> +};
> +
> +struct deep_color {
> + bool bit_30;
> + bool bit_36;
> + int max_tmds_freq;
> +};
> +
> +/* Video Descriptor Block */
> +struct HDMI_EDID_DTD_VIDEO {
> + u16 pixel_clock; /* 54-55 */
> + u8 horiz_active; /* 56 */
> + u8 horiz_blanking; /* 57 */
> + u8 horiz_high; /* 58 */
> + u8 vert_active; /* 59 */
> + u8 vert_blanking; /* 60 */
> + u8 vert_high; /* 61 */
> + u8 horiz_sync_offset; /* 62 */
> + u8 horiz_sync_pulse; /* 63 */
> + u8 vert_sync_pulse; /* 64 */
> + u8 sync_pulse_high; /* 65 */
> + u8 horiz_image_size; /* 66 */
> + u8 vert_image_size; /* 67 */
> + u8 image_size_high; /* 68 */
> + u8 horiz_border; /* 69 */
> + u8 vert_border; /* 70 */
> + u8 misc_settings; /* 71 */
> +};
> +
> +/* Monitor Limits Descriptor Block */
> +struct HDMI_EDID_DTD_MONITOR {
> + u16 pixel_clock; /* 54-55*/
> + u8 _reserved1; /* 56 */
> + u8 block_type; /* 57 */
> + u8 _reserved2; /* 58 */
> + u8 min_vert_freq; /* 59 */
> + u8 max_vert_freq; /* 60 */
> + u8 min_horiz_freq; /* 61 */
> + u8 max_horiz_freq; /* 62 */
> + u8 pixel_clock_mhz; /* 63 */
> + u8 GTF[2]; /* 64 -65 */
> + u8 start_horiz_freq; /* 66 */
> + u8 C; /* 67 */
> + u8 M[2]; /* 68-69 */
> + u8 K; /* 70 */
> + u8 J; /* 71 */
> +
> +} __packed;
> +
> +/* Text Descriptor Block */
> +struct HDMI_EDID_DTD_TEXT {
> + u16 pixel_clock; /* 54-55 */
> + u8 _reserved1; /* 56 */
> + u8 block_type; /* 57 */
> + u8 _reserved2; /* 58 */
> + u8 text[13]; /* 59-71 */
> +} __packed;
> +
> +/* DTD Union */
> +union HDMI_EDID_DTD {
> + struct HDMI_EDID_DTD_VIDEO video;
> + struct HDMI_EDID_DTD_TEXT monitor_name;
> + struct HDMI_EDID_DTD_TEXT monitor_serial_number;
> + struct HDMI_EDID_DTD_TEXT ascii;
> + struct HDMI_EDID_DTD_MONITOR monitor_limits;
> +} __packed;
> +
> +/* EDID struct */
> +struct HDMI_EDID {
> + u8 header[8]; /* 00-07 */
> + u16 manufacturerID; /* 08-09 */
> + u16 product_id; /* 10-11 */
> + u32 serial_number; /* 12-15 */
> + u8 week_manufactured; /* 16 */
> + u8 year_manufactured; /* 17 */
> + u8 edid_version; /* 18 */
> + u8 edid_revision; /* 19 */
> + u8 video_in_definition; /* 20 */
> + u8 max_horiz_image_size; /* 21 */
> + u8 max_vert_image_size; /* 22 */
> + u8 display_gamma; /* 23 */
> + u8 power_features; /* 24 */
> + u8 chroma_info[10]; /* 25-34 */
> + u8 timing_1; /* 35 */
> + u8 timing_2; /* 36 */
> + u8 timing_3; /* 37 */
> + u8 std_timings[16]; /* 38-53 */
> + union HDMI_EDID_DTD DTD[4]; /* 54-125 */
> + u8 extension_edid; /* 126 */
> + u8 checksum; /* 127 */
> + u8 extension_tag; /* 00 (extensions follow EDID) */
> + u8 extention_rev; /* 01 */
> + u8 offset_dtd; /* 02 */
> + u8 num_dtd; /* 03 */
> + u8 data_block[123]; /* 04 - 126 */
> + u8 extension_checksum; /* 127 */
> +
> + u8 ext_datablock[256];
> +} __packed;
> +
> +struct hdmi_timings {
> +
> + u16 x_res;
> + u16 y_res;
> + u32 pixel_clock; /* pixel clock in KHz */
> + u16 hsw; /* Horizontal synchronization pulse width */
> + u16 hfp; /* Horizontal front porch */
> + u16 hbp; /* Horizontal back porch */
> + u16 vsw; /* Vertical synchronization pulse width */
> + u16 vfp; /* Vertical front porch */
> + u16 vbp; /* Vertical back porch */
> +};
> +
> +int get_edid_timing_info(union HDMI_EDID_DTD *edid_dtd,
> + struct hdmi_timings *timings);
> +void get_eedid_timing_info(int current_descriptor_addrs, u8 *edid ,
> + struct hdmi_timings *timings);
> +int hdmi_get_datablock_offset(u8 *edid, enum extension_edid_db datablock,
> + int *offset);
> +int hdmi_get_image_format(u8 *edid, struct image_format *format);
> +int hdmi_get_audio_format(u8 *edid, struct audio_format *format);
> +void hdmi_get_av_delay(u8 *edid, struct latency *lat);
> +void hdmi_deep_color_support_info(u8 *edid, struct deep_color *format);
> +bool hdmi_tv_yuv_supported(u8 *edid);
> +
> +#ifdef __cplusplus
> +};
> +#endif
> +
> +#endif
> diff --git a/drivers/video/edid.c b/drivers/video/edid.c
> new file mode 100644
> index 0000000..4eb2074
> --- /dev/null
> +++ b/drivers/video/edid.c
> @@ -0,0 +1,340 @@
> +/*
> + * edid.c
> + *
> + * Copyright (C) 2011 Texas Instruments
> + * Author: Mythri P K <mythripk@ti.com>
> + * With EDID parsing for DVI Monitor from Rob Clark <rob@ti.com>
> + *
> + * EDID.c to parse the EDID content.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + * History:
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/err.h>
> +#include <linux/string.h>
> +#include <linux/slab.h>
> +#include <asm/edid.h>
> +
> +/* Standard HDMI/VESA timings */
> +const struct hdmi_timings standard_hdmi_timings[STANDARD_HDMI_TIMINGS_NB] = {
> + {640, 480, 25200, 96, 16, 48, 2, 10, 33},
> + {1280, 720, 74250, 40, 440, 220, 5, 5, 20},
> + {1280, 720, 74250, 40, 110, 220, 5, 5, 20},
> + {720, 480, 27027, 62, 16, 60, 6, 9, 30},
> + {2880, 576, 108000, 256, 48, 272, 5, 5, 39},
> + {1440, 240, 27027, 124, 38, 114, 3, 4, 15},
> + {1440, 288, 27000, 126, 24, 138, 3, 2, 19},
> + {1920, 540, 74250, 44, 528, 148, 5, 2, 15},
> + {1920, 540, 74250, 44, 88, 148, 5, 2, 15},
> + {1920, 1080, 148500, 44, 88, 148, 5, 4, 36},
> + {720, 576, 27000, 64, 12, 68, 5, 5, 39},
> + {1440, 576, 54000, 128, 24, 136, 5, 5, 39},
> + {1920, 1080, 148500, 44, 528, 148, 5, 4, 36},
> + {2880, 480, 108108, 248, 64, 240, 6, 9, 30},
> + {1920, 1080, 74250, 44, 638, 148, 5, 4, 36},
> + /* Vesa frome here */
> + {640, 480, 25175, 96, 16, 48, 2 , 11, 31},
> + {800, 600, 40000, 128, 40, 88, 4 , 1, 23},
> + {848, 480, 33750, 112, 16, 112, 8 , 6, 23},
> + {1280, 768, 79500, 128, 64, 192, 7 , 3, 20},
> + {1280, 800, 83500, 128, 72, 200, 6 , 3, 22},
> + {1360, 768, 85500, 112, 64, 256, 6 , 3, 18},
> + {1280, 960, 108000, 112, 96, 312, 3 , 1, 36},
> + {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38},
> + {1024, 768, 65000, 136, 24, 160, 6, 3, 29},
> + {1400, 1050, 121750, 144, 88, 232, 4, 3, 32},
> + {1440, 900, 106500, 152, 80, 232, 6, 3, 25},
> + {1680, 1050, 146250, 176 , 104, 280, 6, 3, 30},
> + {1366, 768, 85500, 143, 70, 213, 3, 3, 24},
> + {1920, 1080, 148500, 44, 88, 80, 5, 4, 36},
> + {1280, 768, 68250, 32, 48, 80, 7, 3, 12},
> + {1400, 1050, 101000, 32, 48, 80, 4, 3, 23},
> + {1680, 1050, 119000, 32, 48, 80, 6, 3, 21},
> + {1280, 800, 79500, 32, 48, 80, 6, 3, 14},
> + {1280, 720, 74250, 40, 110, 220, 5, 5, 20}
> +};
> +
> +int get_edid_timing_info(union HDMI_EDID_DTD *edid_dtd,
> + struct hdmi_timings *timings)
> +{
> + if (edid_dtd->video.pixel_clock) {
> + struct HDMI_EDID_DTD_VIDEO *vid = &edid_dtd->video;
> +
> + timings->pixel_clock = 10 * vid->pixel_clock;
> + timings->x_res = vid->horiz_active |
> + (((u16)vid->horiz_high & 0xf0) << 4);
> + timings->y_res = vid->vert_active |
> + (((u16)vid->vert_high & 0xf0) << 4);
> + timings->hfp = vid->horiz_sync_offset |
> + (((u16)vid->sync_pulse_high & 0xc0) << 2);
> + timings->hsw = vid->horiz_sync_pulse |
> + (((u16)vid->sync_pulse_high & 0x30) << 4);
> + timings->hbp = (vid->horiz_blanking |
> + (((u16)vid->horiz_high & 0x0f) << 8)) -
> + (timings->hfp + timings->hsw);
> + timings->vfp = ((vid->vert_sync_pulse & 0xf0) >> 4) |
> + ((vid->sync_pulse_high & 0x0f) << 2);
> + timings->vsw = (vid->vert_sync_pulse & 0x0f) |
> + ((vid->sync_pulse_high & 0x03) << 4);
> + timings->vbp = (vid->vert_blanking |
> + (((u16)vid->vert_high & 0x0f) << 8)) -
> + (timings->vfp + timings->vsw);
> + return 0;
> + }
> +
> + switch (edid_dtd->monitor_name.block_type) {
> + case HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA:
> + printk(KERN_INFO "standard timing data\n");
> + return -EINVAL;
> + case HDMI_EDID_DTD_TAG_COLOR_POINT_DATA:
> + printk(KERN_INFO "color point data\n");
> + return -EINVAL;
> + case HDMI_EDID_DTD_TAG_MONITOR_NAME:
> + printk(KERN_INFO "monitor name: %s\n",
> + edid_dtd->monitor_name.text);
> + return -EINVAL;
> + case HDMI_EDID_DTD_TAG_MONITOR_LIMITS:
> + {
> + int i, max_area = 0, best_idx = -1;
> + struct HDMI_EDID_DTD_MONITOR *limits > + &edid_dtd->monitor_limits;
> +
> + printk(KERN_DEBUG " monitor limits\n");
> + printk(KERN_DEBUG " min_vert_freq=%d\n",
> + limits->min_vert_freq);
> + printk(KERN_DEBUG " max_vert_freq=%d\n",
> + limits->max_vert_freq);
> + printk(KERN_DEBUG " min_horiz_freq=%d\n",
> + limits->min_horiz_freq);
> + printk(KERN_DEBUG " max_horiz_freq=%d\n",
> + limits->max_horiz_freq);
> + printk(KERN_DEBUG " pixel_clock_mhz=%d\n",
> + limits->pixel_clock_mhz * 10);
> +
> + /* find the highest matching resolution (w*h) */
> +
> + /*
> + * XXX since this is mainly for DVI monitors, should we only
> + * support VESA timings? My monitor at home would pick
> + * 1920x1080 otherwise, but that seems to not work well (monitor
> + * blanks out and comes back, and picture doesn't fill full
> + * screen, but leaves a black bar on left (native res is
> + * 2048x1152). However if I only consider VESA timings, it picks
> + * 1680x1050 and the picture is stable and fills whole screen
> + */
> + for (i = STANDARD_HDMI_TIMINGS_VESA_START;
> + i < STANDARD_HDMI_TIMINGS_NB; i++) {
> + const struct hdmi_timings *timings > + &standard_hdmi_timings[i];
> + int hz, hscan, pixclock;
> + int vtotal, htotal;
> + htotal = timings->hbp + timings->hfp +
> + timings->hsw + timings->x_res;
> + vtotal = timings->vbp + timings->vfp +
> + timings->vsw + timings->y_res;
> +
> + /* NOTE: We don't support interlaced mode for VESA */
> + pixclock = timings->pixel_clock * 1000;
> + hscan = (pixclock + htotal / 2) / htotal;
> + hscan = (hscan + 500) / 1000 * 1000;
> + hz = (hscan + vtotal / 2) / vtotal;
> + hscan /= 1000;
> + pixclock /= 1000000;
> + if ((pixclock < (limits->pixel_clock_mhz * 10)) &&
> + (limits->min_horiz_freq <= hscan) &&
> + (hscan <= limits->max_horiz_freq) &&
> + (limits->min_vert_freq <= hz) &&
> + (hz <= limits->max_vert_freq)) {
> + int area = timings->x_res * timings->y_res;
> + printk(KERN_INFO " -> %d: %dx%d\n", i,
> + timings->x_res, timings->y_res);
> + if (area > max_area) {
> + max_area = area;
> + best_idx = i;
> + }
> + }
> + }
> + if (best_idx > 0) {
> + *timings = standard_hdmi_timings[best_idx];
> + printk(KERN_DEBUG "found best resolution: %dx%d (%d)\n",
> + timings->x_res, timings->y_res, best_idx);
> + }
> + return 0;
> + }
> + case HDMI_EDID_DTD_TAG_ASCII_STRING:
> + printk(KERN_INFO "ascii string: %s\n", edid_dtd->ascii.text);
> + return -EINVAL;
> + case HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM:
> + printk(KERN_INFO "monitor serialnum: %s\n",
> + edid_dtd->monitor_serial_number.text);
> + return -EINVAL;
> + default:
> + printk(KERN_INFO "unsupported EDID descriptor block format\n");
> + return -EINVAL;
> + }
> +}
> +
> +void get_eedid_timing_info(int current_descriptor_addrs, u8 *edid ,
> + struct hdmi_timings *timings)
> +{
> + timings->x_res = (((edid[current_descriptor_addrs + 4] & 0xF0) << 4)
> + | edid[current_descriptor_addrs + 2]);
> + timings->y_res = (((edid[current_descriptor_addrs + 7] & 0xF0) << 4)
> + | edid[current_descriptor_addrs + 5]);
> + timings->pixel_clock = ((edid[current_descriptor_addrs + 1] << 8)
> + | edid[current_descriptor_addrs]);
> + timings->pixel_clock = 10 * timings->pixel_clock;
> + timings->hfp = edid[current_descriptor_addrs + 8];
> + timings->hsw = edid[current_descriptor_addrs + 9];
> + timings->hbp = (((edid[current_descriptor_addrs + 4] & 0x0F) << 8)
> + | edid[current_descriptor_addrs + 3]) -
> + (timings->hfp + timings->hsw);
> + timings->vfp = ((edid[current_descriptor_addrs + 10] & 0xF0) >> 4);
> + timings->vsw = (edid[current_descriptor_addrs + 10] & 0x0F);
> + timings->vbp = (((edid[current_descriptor_addrs + 7] & 0x0F) << 8)
> + | edid[current_descriptor_addrs + 6]) -
> + (timings->vfp + timings->vsw);
> +}
> +
> +int hdmi_get_datablock_offset(u8 *edid, enum extension_edid_db datablock,
> + int *offset)
> +{
> + int current_byte, disp, i = 0, length = 0;
> +
> + if (edid[0x7e] = 0x00)
> + return -EINVAL;
> +
> + disp = edid[(0x80) + 2];
> + if (disp = 0x4)
> + return -EINVAL;
> +
> + i = 0x80 + 0x4;
> + printk(KERN_INFO "%x\n", i);
> + while (i < (0x80 + disp)) {
> + current_byte = edid[i];
> + if ((current_byte >> 5) = datablock) {
> + *offset = i;
> + printk(KERN_INFO "datablock %d %d\n",
> + datablock, *offset);
> + return 0;
> + } else {
> + length = (current_byte &
> + HDMI_EDID_EX_DATABLOCK_LEN_MASK) + 1;
> + i += length;
> + }
> + }
> + return -EINVAL;
> +}
> +
> +int hdmi_get_image_format(u8 *edid, struct image_format *format)
> +{
> + int offset, current_byte, j = 0, length = 0;
> + enum extension_edid_db vsdb = DATABLOCK_VIDEO;
> + format->length = 0;
> +
> + memset(format->fmt, 0, sizeof(format->fmt));
> + if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
> + current_byte = edid[offset];
> + length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
> +
> + if (length >= HDMI_IMG_FORMAT_MAX_LENGTH)
> + format->length = HDMI_IMG_FORMAT_MAX_LENGTH;
> + else
> + format->length = length;
> +
> + for (j = 1 ; j < length ; j++) {
> + current_byte = edid[offset+j];
> + format->fmt[j-1].code = current_byte & 0x7F;
> + format->fmt[j-1].pref = current_byte & 0x80;
> + }
> + }
> + return 0;
> +}
> +
> +int hdmi_get_audio_format(u8 *edid, struct audio_format *format)
> +{
> + int offset, current_byte, j = 0, length = 0;
> + enum extension_edid_db vsdb = DATABLOCK_AUDIO;
> +
> + format->length = 0;
> + memset(format->fmt, 0, sizeof(format->fmt));
> +
> + if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
> + current_byte = edid[offset];
> + length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
> +
> + if (length >= HDMI_AUDIO_FORMAT_MAX_LENGTH)
> + format->length = HDMI_AUDIO_FORMAT_MAX_LENGTH;
> + else
> + format->length = length;
> +
> + for (j = 1 ; j < length ; j++) {
> + if (j%3 = 1) {
> + current_byte = edid[offset + j];
> + format->fmt[j-1].format = current_byte & 0x78;
> + format->fmt[j-1].num_of_ch > + (current_byte & 0x07) + 1;
> + }
> + }
> + }
> + return 0;
> +}
> +
> +void hdmi_get_av_delay(u8 *edid, struct latency *lat)
> +{
> + int offset, current_byte, length = 0;
> + enum extension_edid_db vsdb = DATABLOCK_VENDOR;
> +
> + if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
> + current_byte = edid[offset];
> + length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
> + if (length >= 8 && ((current_byte + 8) & 0x80)) {
> + lat->vid_latency = (edid[offset + 8] - 1) * 2;
> + lat->aud_latency = (edid[offset + 9] - 1) * 2;
> + }
> + if (length >= 8 && ((current_byte + 8) & 0xC0)) {
> + lat->int_vid_latency = (edid[offset + 10] - 1) * 2;
> + lat->int_aud_latency = (edid[offset + 11] - 1) * 2;
> + }
> + }
> +}
> +
> +void hdmi_deep_color_support_info(u8 *edid, struct deep_color *format)
> +{
> + int offset, current_byte, length = 0;
> + enum extension_edid_db vsdb = DATABLOCK_VENDOR;
> + memset(format, 0, sizeof(*format));
> +
> + if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
> + current_byte = edid[offset];
> + length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
> + if (length >= 6) {
> + format->bit_30 = (edid[offset + 6] & 0x10);
> + format->bit_36 = (edid[offset + 6] & 0x20);
> + }
> + if (length >= 7)
> + format->max_tmds_freq = (edid[offset + 7]) * 5;
> + }
> +}
> +
> +bool hdmi_tv_yuv_supported(u8 *edid)
> +{
> + if (edid[0x7e] != 0x00 && edid[0x83] & 0x30) {
> + printk(KERN_INFO "YUV supported");
> + return true;
> + }
> + return false;
> +}
> --
> 1.5.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" 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: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: Paul Mundt @ 2011-03-22 17:58 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Mythri P K, linux-fbdev, linux-omap, linux-media
In-Reply-To: <4D88E1FB.5070503@redhat.com>
On Tue, Mar 22, 2011 at 02:52:59PM -0300, Mauro Carvalho Chehab wrote:
> Em 22-03-2011 14:32, Mythri P K escreveu:
> > Adding support for common EDID parsing in kernel.
> >
> > EDID - Extended display identification data is a data structure provided by
> > a digital display to describe its capabilities to a video source, This a
> > standard supported by CEA and VESA.
> >
> > There are several custom implementations for parsing EDID in kernel, some
> > of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
> > parsing of EDID should be done in a library, which is agnostic of the
> > framework (V4l2, DRM, FB) which is using the functionality, just based on
> > the raw EDID pointer with size/segment information.
> >
> > With other RFC's such as the one below, which tries to standardize HDMI API's
> > It would be better to have a common EDID code in one place.It also helps to
> > provide better interoperability with variety of TV/Monitor may be even by
> > listing out quirks which might get missed with several custom implementation
> > of EDID.
> > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
> >
> > This patch tries to add functions to parse some portion EDID (detailed timing,
> > monitor limits, AV delay information, deep color mode support, Audio and VSDB)
> > If we can align on this library approach i can enhance this library to parse
> > other blocks and probably we could also add quirks from other implementation
> > as well.
> >
> > Signed-off-by: Mythri P K <mythripk@ti.com>
> > ---
> > arch/arm/include/asm/edid.h | 243 ++++++++++++++++++++++++++++++
> > drivers/video/edid.c | 340 +++++++++++++++++++++++++++++++++++++++++++
>
> Hmm... if you want this to be agnostic, the header file should not be inside
> arch/arm, but on some other place, like include/video/.
>
Ironically this adds a drivers/video/edid.c but completely ignores
drivers/video/edid.h which already exists and already contains many of
these definitions.
I like the idea of a generalized library, but it would be nice to see the
existing edid.h evolved and its users updated incrementally.
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: Mauro Carvalho Chehab @ 2011-03-22 17:52 UTC (permalink / raw)
To: Mythri P K; +Cc: linux-fbdev, linux-omap, linux-media
In-Reply-To: <1300815176-21206-1-git-send-email-mythripk@ti.com>
Em 22-03-2011 14:32, Mythri P K escreveu:
> Adding support for common EDID parsing in kernel.
>
> EDID - Extended display identification data is a data structure provided by
> a digital display to describe its capabilities to a video source, This a
> standard supported by CEA and VESA.
>
> There are several custom implementations for parsing EDID in kernel, some
> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
> parsing of EDID should be done in a library, which is agnostic of the
> framework (V4l2, DRM, FB) which is using the functionality, just based on
> the raw EDID pointer with size/segment information.
>
> With other RFC's such as the one below, which tries to standardize HDMI API's
> It would be better to have a common EDID code in one place.It also helps to
> provide better interoperability with variety of TV/Monitor may be even by
> listing out quirks which might get missed with several custom implementation
> of EDID.
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
>
> This patch tries to add functions to parse some portion EDID (detailed timing,
> monitor limits, AV delay information, deep color mode support, Audio and VSDB)
> If we can align on this library approach i can enhance this library to parse
> other blocks and probably we could also add quirks from other implementation
> as well.
>
> Signed-off-by: Mythri P K <mythripk@ti.com>
> ---
> arch/arm/include/asm/edid.h | 243 ++++++++++++++++++++++++++++++
> drivers/video/edid.c | 340 +++++++++++++++++++++++++++++++++++++++++++
Hmm... if you want this to be agnostic, the header file should not be inside
arch/arm, but on some other place, like include/video/.
> 2 files changed, 583 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/include/asm/edid.h
> create mode 100644 drivers/video/edid.c
>
> diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h
> new file mode 100644
> index 0000000..843346a
> --- /dev/null
> +++ b/arch/arm/include/asm/edid.h
> @@ -0,0 +1,243 @@
> +/*
> + * edid.h
> + *
> + * Copyright (C) 2011 Texas Instruments
> + * Author: Mythri P K <mythripk@ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + * History:
> + */
> +
> +#ifndef _EDID_H_
> +#define _EDID_H_
> +
> +/* HDMI EDID Length */
> +#define HDMI_EDID_MAX_LENGTH 512
> +
> +/* HDMI EDID Extension Data Block Tags */
> +#define HDMI_EDID_EX_DATABLOCK_TAG_MASK 0xE0
> +#define HDMI_EDID_EX_DATABLOCK_LEN_MASK 0x1F
> +
> +#define EDID_TIMING_DESCRIPTOR_SIZE 0x12
> +#define EDID_DESCRIPTOR_BLOCK0_ADDRESS 0x36
> +#define EDID_DESCRIPTOR_BLOCK1_ADDRESS 0x80
> +#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
> +#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
> +
> +/* EDID Detailed Timing Info 0 begin offset */
> +#define HDMI_EDID_DETAILED_TIMING_OFFSET 0x36
> +
> +#define HDMI_EDID_PIX_CLK_OFFSET 0
> +#define HDMI_EDID_H_ACTIVE_OFFSET 2
> +#define HDMI_EDID_H_BLANKING_OFFSET 3
> +#define HDMI_EDID_V_ACTIVE_OFFSET 5
> +#define HDMI_EDID_V_BLANKING_OFFSET 6
> +#define HDMI_EDID_H_SYNC_OFFSET 8
> +#define HDMI_EDID_H_SYNC_PW_OFFSET 9
> +#define HDMI_EDID_V_SYNC_OFFSET 10
> +#define HDMI_EDID_V_SYNC_PW_OFFSET 11
> +#define HDMI_EDID_H_IMAGE_SIZE_OFFSET 12
> +#define HDMI_EDID_V_IMAGE_SIZE_OFFSET 13
> +#define HDMI_EDID_H_BORDER_OFFSET 15
> +#define HDMI_EDID_V_BORDER_OFFSET 16
> +#define HDMI_EDID_FLAGS_OFFSET 17
> +
> +/* HDMI EDID DTDs */
> +#define HDMI_EDID_MAX_DTDS 4
> +
> +/* HDMI EDID DTD Tags */
> +#define HDMI_EDID_DTD_TAG_MONITOR_NAME 0xFC
> +#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM 0xFF
> +#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS 0xFD
> +#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA 0xFA
> +#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA 0xFB
> +#define HDMI_EDID_DTD_TAG_ASCII_STRING 0xFE
> +
> +#define HDMI_IMG_FORMAT_MAX_LENGTH 20
> +#define HDMI_AUDIO_FORMAT_MAX_LENGTH 10
> +
> +/* HDMI EDID Extenion Data Block Values: Video */
> +#define HDMI_EDID_EX_VIDEO_NATIVE 0x80
> +#define HDMI_EDID_EX_VIDEO_MASK 0x7F
> +#define HDMI_EDID_EX_VIDEO_MAX 35
> +
> +#define STANDARD_HDMI_TIMINGS_NB 34
> +#define STANDARD_HDMI_TIMINGS_VESA_START 15
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +enum extension_edid_db {
> + DATABLOCK_AUDIO = 1,
> + DATABLOCK_VIDEO = 2,
> + DATABLOCK_VENDOR = 3,
> + DATABLOCK_SPEAKERS = 4,
> +};
> +
> +struct img_edid {
> + bool pref;
> + int code;
> +};
> +
> +struct image_format {
> + int length;
> + struct img_edid fmt[HDMI_IMG_FORMAT_MAX_LENGTH];
> +};
> +
> +struct audio_edid {
> + int num_of_ch;
> + int format;
> +};
> +
> +struct audio_format {
> + int length;
> + struct audio_edid fmt[HDMI_AUDIO_FORMAT_MAX_LENGTH];
> +};
> +
> +struct latency {
> + /* vid: if indicated, value=1+ms/2 with a max of 251 meaning 500ms */
> + int vid_latency;
> + int aud_latency;
> + int int_vid_latency;
> + int int_aud_latency;
> +};
> +
> +struct deep_color {
> + bool bit_30;
> + bool bit_36;
> + int max_tmds_freq;
> +};
> +
> +/* Video Descriptor Block */
> +struct HDMI_EDID_DTD_VIDEO {
> + u16 pixel_clock; /* 54-55 */
> + u8 horiz_active; /* 56 */
> + u8 horiz_blanking; /* 57 */
> + u8 horiz_high; /* 58 */
> + u8 vert_active; /* 59 */
> + u8 vert_blanking; /* 60 */
> + u8 vert_high; /* 61 */
> + u8 horiz_sync_offset; /* 62 */
> + u8 horiz_sync_pulse; /* 63 */
> + u8 vert_sync_pulse; /* 64 */
> + u8 sync_pulse_high; /* 65 */
> + u8 horiz_image_size; /* 66 */
> + u8 vert_image_size; /* 67 */
> + u8 image_size_high; /* 68 */
> + u8 horiz_border; /* 69 */
> + u8 vert_border; /* 70 */
> + u8 misc_settings; /* 71 */
> +};
> +
> +/* Monitor Limits Descriptor Block */
> +struct HDMI_EDID_DTD_MONITOR {
> + u16 pixel_clock; /* 54-55*/
> + u8 _reserved1; /* 56 */
> + u8 block_type; /* 57 */
> + u8 _reserved2; /* 58 */
> + u8 min_vert_freq; /* 59 */
> + u8 max_vert_freq; /* 60 */
> + u8 min_horiz_freq; /* 61 */
> + u8 max_horiz_freq; /* 62 */
> + u8 pixel_clock_mhz; /* 63 */
> + u8 GTF[2]; /* 64 -65 */
> + u8 start_horiz_freq; /* 66 */
> + u8 C; /* 67 */
> + u8 M[2]; /* 68-69 */
> + u8 K; /* 70 */
> + u8 J; /* 71 */
> +
> +} __packed;
> +
> +/* Text Descriptor Block */
> +struct HDMI_EDID_DTD_TEXT {
> + u16 pixel_clock; /* 54-55 */
> + u8 _reserved1; /* 56 */
> + u8 block_type; /* 57 */
> + u8 _reserved2; /* 58 */
> + u8 text[13]; /* 59-71 */
> +} __packed;
> +
> +/* DTD Union */
> +union HDMI_EDID_DTD {
> + struct HDMI_EDID_DTD_VIDEO video;
> + struct HDMI_EDID_DTD_TEXT monitor_name;
> + struct HDMI_EDID_DTD_TEXT monitor_serial_number;
> + struct HDMI_EDID_DTD_TEXT ascii;
> + struct HDMI_EDID_DTD_MONITOR monitor_limits;
> +} __packed;
> +
> +/* EDID struct */
> +struct HDMI_EDID {
> + u8 header[8]; /* 00-07 */
> + u16 manufacturerID; /* 08-09 */
> + u16 product_id; /* 10-11 */
> + u32 serial_number; /* 12-15 */
> + u8 week_manufactured; /* 16 */
> + u8 year_manufactured; /* 17 */
> + u8 edid_version; /* 18 */
> + u8 edid_revision; /* 19 */
> + u8 video_in_definition; /* 20 */
> + u8 max_horiz_image_size; /* 21 */
> + u8 max_vert_image_size; /* 22 */
> + u8 display_gamma; /* 23 */
> + u8 power_features; /* 24 */
> + u8 chroma_info[10]; /* 25-34 */
> + u8 timing_1; /* 35 */
> + u8 timing_2; /* 36 */
> + u8 timing_3; /* 37 */
> + u8 std_timings[16]; /* 38-53 */
> + union HDMI_EDID_DTD DTD[4]; /* 54-125 */
> + u8 extension_edid; /* 126 */
> + u8 checksum; /* 127 */
> + u8 extension_tag; /* 00 (extensions follow EDID) */
> + u8 extention_rev; /* 01 */
> + u8 offset_dtd; /* 02 */
> + u8 num_dtd; /* 03 */
> + u8 data_block[123]; /* 04 - 126 */
> + u8 extension_checksum; /* 127 */
> +
> + u8 ext_datablock[256];
> +} __packed;
> +
> +struct hdmi_timings {
> +
> + u16 x_res;
> + u16 y_res;
> + u32 pixel_clock; /* pixel clock in KHz */
> + u16 hsw; /* Horizontal synchronization pulse width */
> + u16 hfp; /* Horizontal front porch */
> + u16 hbp; /* Horizontal back porch */
> + u16 vsw; /* Vertical synchronization pulse width */
> + u16 vfp; /* Vertical front porch */
> + u16 vbp; /* Vertical back porch */
> +};
> +
> +int get_edid_timing_info(union HDMI_EDID_DTD *edid_dtd,
> + struct hdmi_timings *timings);
> +void get_eedid_timing_info(int current_descriptor_addrs, u8 *edid ,
> + struct hdmi_timings *timings);
> +int hdmi_get_datablock_offset(u8 *edid, enum extension_edid_db datablock,
> + int *offset);
> +int hdmi_get_image_format(u8 *edid, struct image_format *format);
> +int hdmi_get_audio_format(u8 *edid, struct audio_format *format);
> +void hdmi_get_av_delay(u8 *edid, struct latency *lat);
> +void hdmi_deep_color_support_info(u8 *edid, struct deep_color *format);
> +bool hdmi_tv_yuv_supported(u8 *edid);
> +
> +#ifdef __cplusplus
> +};
> +#endif
> +
> +#endif
> diff --git a/drivers/video/edid.c b/drivers/video/edid.c
> new file mode 100644
> index 0000000..4eb2074
> --- /dev/null
> +++ b/drivers/video/edid.c
> @@ -0,0 +1,340 @@
> +/*
> + * edid.c
> + *
> + * Copyright (C) 2011 Texas Instruments
> + * Author: Mythri P K <mythripk@ti.com>
> + * With EDID parsing for DVI Monitor from Rob Clark <rob@ti.com>
> + *
> + * EDID.c to parse the EDID content.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + * History:
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/err.h>
> +#include <linux/string.h>
> +#include <linux/slab.h>
> +#include <asm/edid.h>
> +
> +/* Standard HDMI/VESA timings */
> +const struct hdmi_timings standard_hdmi_timings[STANDARD_HDMI_TIMINGS_NB] = {
> + {640, 480, 25200, 96, 16, 48, 2, 10, 33},
> + {1280, 720, 74250, 40, 440, 220, 5, 5, 20},
> + {1280, 720, 74250, 40, 110, 220, 5, 5, 20},
> + {720, 480, 27027, 62, 16, 60, 6, 9, 30},
> + {2880, 576, 108000, 256, 48, 272, 5, 5, 39},
> + {1440, 240, 27027, 124, 38, 114, 3, 4, 15},
> + {1440, 288, 27000, 126, 24, 138, 3, 2, 19},
> + {1920, 540, 74250, 44, 528, 148, 5, 2, 15},
> + {1920, 540, 74250, 44, 88, 148, 5, 2, 15},
> + {1920, 1080, 148500, 44, 88, 148, 5, 4, 36},
> + {720, 576, 27000, 64, 12, 68, 5, 5, 39},
> + {1440, 576, 54000, 128, 24, 136, 5, 5, 39},
> + {1920, 1080, 148500, 44, 528, 148, 5, 4, 36},
> + {2880, 480, 108108, 248, 64, 240, 6, 9, 30},
> + {1920, 1080, 74250, 44, 638, 148, 5, 4, 36},
> + /* Vesa frome here */
> + {640, 480, 25175, 96, 16, 48, 2 , 11, 31},
> + {800, 600, 40000, 128, 40, 88, 4 , 1, 23},
> + {848, 480, 33750, 112, 16, 112, 8 , 6, 23},
> + {1280, 768, 79500, 128, 64, 192, 7 , 3, 20},
> + {1280, 800, 83500, 128, 72, 200, 6 , 3, 22},
> + {1360, 768, 85500, 112, 64, 256, 6 , 3, 18},
> + {1280, 960, 108000, 112, 96, 312, 3 , 1, 36},
> + {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38},
> + {1024, 768, 65000, 136, 24, 160, 6, 3, 29},
> + {1400, 1050, 121750, 144, 88, 232, 4, 3, 32},
> + {1440, 900, 106500, 152, 80, 232, 6, 3, 25},
> + {1680, 1050, 146250, 176 , 104, 280, 6, 3, 30},
> + {1366, 768, 85500, 143, 70, 213, 3, 3, 24},
> + {1920, 1080, 148500, 44, 88, 80, 5, 4, 36},
> + {1280, 768, 68250, 32, 48, 80, 7, 3, 12},
> + {1400, 1050, 101000, 32, 48, 80, 4, 3, 23},
> + {1680, 1050, 119000, 32, 48, 80, 6, 3, 21},
> + {1280, 800, 79500, 32, 48, 80, 6, 3, 14},
> + {1280, 720, 74250, 40, 110, 220, 5, 5, 20}
> +};
> +
> +int get_edid_timing_info(union HDMI_EDID_DTD *edid_dtd,
> + struct hdmi_timings *timings)
> +{
> + if (edid_dtd->video.pixel_clock) {
> + struct HDMI_EDID_DTD_VIDEO *vid = &edid_dtd->video;
> +
> + timings->pixel_clock = 10 * vid->pixel_clock;
> + timings->x_res = vid->horiz_active |
> + (((u16)vid->horiz_high & 0xf0) << 4);
> + timings->y_res = vid->vert_active |
> + (((u16)vid->vert_high & 0xf0) << 4);
> + timings->hfp = vid->horiz_sync_offset |
> + (((u16)vid->sync_pulse_high & 0xc0) << 2);
> + timings->hsw = vid->horiz_sync_pulse |
> + (((u16)vid->sync_pulse_high & 0x30) << 4);
> + timings->hbp = (vid->horiz_blanking |
> + (((u16)vid->horiz_high & 0x0f) << 8)) -
> + (timings->hfp + timings->hsw);
> + timings->vfp = ((vid->vert_sync_pulse & 0xf0) >> 4) |
> + ((vid->sync_pulse_high & 0x0f) << 2);
> + timings->vsw = (vid->vert_sync_pulse & 0x0f) |
> + ((vid->sync_pulse_high & 0x03) << 4);
> + timings->vbp = (vid->vert_blanking |
> + (((u16)vid->vert_high & 0x0f) << 8)) -
> + (timings->vfp + timings->vsw);
> + return 0;
> + }
> +
> + switch (edid_dtd->monitor_name.block_type) {
> + case HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA:
> + printk(KERN_INFO "standard timing data\n");
> + return -EINVAL;
> + case HDMI_EDID_DTD_TAG_COLOR_POINT_DATA:
> + printk(KERN_INFO "color point data\n");
> + return -EINVAL;
> + case HDMI_EDID_DTD_TAG_MONITOR_NAME:
> + printk(KERN_INFO "monitor name: %s\n",
> + edid_dtd->monitor_name.text);
> + return -EINVAL;
> + case HDMI_EDID_DTD_TAG_MONITOR_LIMITS:
> + {
> + int i, max_area = 0, best_idx = -1;
> + struct HDMI_EDID_DTD_MONITOR *limits > + &edid_dtd->monitor_limits;
> +
> + printk(KERN_DEBUG " monitor limits\n");
> + printk(KERN_DEBUG " min_vert_freq=%d\n",
> + limits->min_vert_freq);
> + printk(KERN_DEBUG " max_vert_freq=%d\n",
> + limits->max_vert_freq);
> + printk(KERN_DEBUG " min_horiz_freq=%d\n",
> + limits->min_horiz_freq);
> + printk(KERN_DEBUG " max_horiz_freq=%d\n",
> + limits->max_horiz_freq);
> + printk(KERN_DEBUG " pixel_clock_mhz=%d\n",
> + limits->pixel_clock_mhz * 10);
> +
> + /* find the highest matching resolution (w*h) */
> +
> + /*
> + * XXX since this is mainly for DVI monitors, should we only
> + * support VESA timings? My monitor at home would pick
> + * 1920x1080 otherwise, but that seems to not work well (monitor
> + * blanks out and comes back, and picture doesn't fill full
> + * screen, but leaves a black bar on left (native res is
> + * 2048x1152). However if I only consider VESA timings, it picks
> + * 1680x1050 and the picture is stable and fills whole screen
> + */
> + for (i = STANDARD_HDMI_TIMINGS_VESA_START;
> + i < STANDARD_HDMI_TIMINGS_NB; i++) {
> + const struct hdmi_timings *timings > + &standard_hdmi_timings[i];
> + int hz, hscan, pixclock;
> + int vtotal, htotal;
> + htotal = timings->hbp + timings->hfp +
> + timings->hsw + timings->x_res;
> + vtotal = timings->vbp + timings->vfp +
> + timings->vsw + timings->y_res;
> +
> + /* NOTE: We don't support interlaced mode for VESA */
> + pixclock = timings->pixel_clock * 1000;
> + hscan = (pixclock + htotal / 2) / htotal;
> + hscan = (hscan + 500) / 1000 * 1000;
> + hz = (hscan + vtotal / 2) / vtotal;
> + hscan /= 1000;
> + pixclock /= 1000000;
> + if ((pixclock < (limits->pixel_clock_mhz * 10)) &&
> + (limits->min_horiz_freq <= hscan) &&
> + (hscan <= limits->max_horiz_freq) &&
> + (limits->min_vert_freq <= hz) &&
> + (hz <= limits->max_vert_freq)) {
> + int area = timings->x_res * timings->y_res;
> + printk(KERN_INFO " -> %d: %dx%d\n", i,
> + timings->x_res, timings->y_res);
> + if (area > max_area) {
> + max_area = area;
> + best_idx = i;
> + }
> + }
> + }
> + if (best_idx > 0) {
> + *timings = standard_hdmi_timings[best_idx];
> + printk(KERN_DEBUG "found best resolution: %dx%d (%d)\n",
> + timings->x_res, timings->y_res, best_idx);
> + }
> + return 0;
> + }
> + case HDMI_EDID_DTD_TAG_ASCII_STRING:
> + printk(KERN_INFO "ascii string: %s\n", edid_dtd->ascii.text);
> + return -EINVAL;
> + case HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM:
> + printk(KERN_INFO "monitor serialnum: %s\n",
> + edid_dtd->monitor_serial_number.text);
> + return -EINVAL;
> + default:
> + printk(KERN_INFO "unsupported EDID descriptor block format\n");
> + return -EINVAL;
> + }
> +}
> +
> +void get_eedid_timing_info(int current_descriptor_addrs, u8 *edid ,
> + struct hdmi_timings *timings)
> +{
> + timings->x_res = (((edid[current_descriptor_addrs + 4] & 0xF0) << 4)
> + | edid[current_descriptor_addrs + 2]);
> + timings->y_res = (((edid[current_descriptor_addrs + 7] & 0xF0) << 4)
> + | edid[current_descriptor_addrs + 5]);
> + timings->pixel_clock = ((edid[current_descriptor_addrs + 1] << 8)
> + | edid[current_descriptor_addrs]);
> + timings->pixel_clock = 10 * timings->pixel_clock;
> + timings->hfp = edid[current_descriptor_addrs + 8];
> + timings->hsw = edid[current_descriptor_addrs + 9];
> + timings->hbp = (((edid[current_descriptor_addrs + 4] & 0x0F) << 8)
> + | edid[current_descriptor_addrs + 3]) -
> + (timings->hfp + timings->hsw);
> + timings->vfp = ((edid[current_descriptor_addrs + 10] & 0xF0) >> 4);
> + timings->vsw = (edid[current_descriptor_addrs + 10] & 0x0F);
> + timings->vbp = (((edid[current_descriptor_addrs + 7] & 0x0F) << 8)
> + | edid[current_descriptor_addrs + 6]) -
> + (timings->vfp + timings->vsw);
> +}
> +
> +int hdmi_get_datablock_offset(u8 *edid, enum extension_edid_db datablock,
> + int *offset)
> +{
> + int current_byte, disp, i = 0, length = 0;
> +
> + if (edid[0x7e] = 0x00)
> + return -EINVAL;
> +
> + disp = edid[(0x80) + 2];
> + if (disp = 0x4)
> + return -EINVAL;
> +
> + i = 0x80 + 0x4;
> + printk(KERN_INFO "%x\n", i);
> + while (i < (0x80 + disp)) {
> + current_byte = edid[i];
> + if ((current_byte >> 5) = datablock) {
> + *offset = i;
> + printk(KERN_INFO "datablock %d %d\n",
> + datablock, *offset);
> + return 0;
> + } else {
> + length = (current_byte &
> + HDMI_EDID_EX_DATABLOCK_LEN_MASK) + 1;
> + i += length;
> + }
> + }
> + return -EINVAL;
> +}
> +
> +int hdmi_get_image_format(u8 *edid, struct image_format *format)
> +{
> + int offset, current_byte, j = 0, length = 0;
> + enum extension_edid_db vsdb = DATABLOCK_VIDEO;
> + format->length = 0;
> +
> + memset(format->fmt, 0, sizeof(format->fmt));
> + if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
> + current_byte = edid[offset];
> + length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
> +
> + if (length >= HDMI_IMG_FORMAT_MAX_LENGTH)
> + format->length = HDMI_IMG_FORMAT_MAX_LENGTH;
> + else
> + format->length = length;
> +
> + for (j = 1 ; j < length ; j++) {
> + current_byte = edid[offset+j];
> + format->fmt[j-1].code = current_byte & 0x7F;
> + format->fmt[j-1].pref = current_byte & 0x80;
> + }
> + }
> + return 0;
> +}
> +
> +int hdmi_get_audio_format(u8 *edid, struct audio_format *format)
> +{
> + int offset, current_byte, j = 0, length = 0;
> + enum extension_edid_db vsdb = DATABLOCK_AUDIO;
> +
> + format->length = 0;
> + memset(format->fmt, 0, sizeof(format->fmt));
> +
> + if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
> + current_byte = edid[offset];
> + length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
> +
> + if (length >= HDMI_AUDIO_FORMAT_MAX_LENGTH)
> + format->length = HDMI_AUDIO_FORMAT_MAX_LENGTH;
> + else
> + format->length = length;
> +
> + for (j = 1 ; j < length ; j++) {
> + if (j%3 = 1) {
> + current_byte = edid[offset + j];
> + format->fmt[j-1].format = current_byte & 0x78;
> + format->fmt[j-1].num_of_ch > + (current_byte & 0x07) + 1;
> + }
> + }
> + }
> + return 0;
> +}
> +
> +void hdmi_get_av_delay(u8 *edid, struct latency *lat)
> +{
> + int offset, current_byte, length = 0;
> + enum extension_edid_db vsdb = DATABLOCK_VENDOR;
> +
> + if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
> + current_byte = edid[offset];
> + length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
> + if (length >= 8 && ((current_byte + 8) & 0x80)) {
> + lat->vid_latency = (edid[offset + 8] - 1) * 2;
> + lat->aud_latency = (edid[offset + 9] - 1) * 2;
> + }
> + if (length >= 8 && ((current_byte + 8) & 0xC0)) {
> + lat->int_vid_latency = (edid[offset + 10] - 1) * 2;
> + lat->int_aud_latency = (edid[offset + 11] - 1) * 2;
> + }
> + }
> +}
> +
> +void hdmi_deep_color_support_info(u8 *edid, struct deep_color *format)
> +{
> + int offset, current_byte, length = 0;
> + enum extension_edid_db vsdb = DATABLOCK_VENDOR;
> + memset(format, 0, sizeof(*format));
> +
> + if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
> + current_byte = edid[offset];
> + length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
> + if (length >= 6) {
> + format->bit_30 = (edid[offset + 6] & 0x10);
> + format->bit_36 = (edid[offset + 6] & 0x20);
> + }
> + if (length >= 7)
> + format->max_tmds_freq = (edid[offset + 7]) * 5;
> + }
> +}
> +
> +bool hdmi_tv_yuv_supported(u8 *edid)
> +{
> + if (edid[0x7e] != 0x00 && edid[0x83] & 0x30) {
> + printk(KERN_INFO "YUV supported");
> + return true;
> + }
> + return false;
> +}
^ permalink raw reply
* [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: Mythri P K @ 2011-03-22 17:44 UTC (permalink / raw)
To: linux-fbdev, linux-omap, linux-media; +Cc: Mythri P K
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by
a digital display to describe its capabilities to a video source, This a
standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some
of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
parsing of EDID should be done in a library, which is agnostic of the
framework (V4l2, DRM, FB) which is using the functionality, just based on
the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's
It would be better to have a common EDID code in one place.It also helps to
provide better interoperability with variety of TV/Monitor may be even by
listing out quirks which might get missed with several custom implementation
of EDID.
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
This patch tries to add functions to parse some portion EDID (detailed timing,
monitor limits, AV delay information, deep color mode support, Audio and VSDB)
If we can align on this library approach i can enhance this library to parse
other blocks and probably we could also add quirks from other implementation
as well.
Signed-off-by: Mythri P K <mythripk@ti.com>
---
arch/arm/include/asm/edid.h | 243 ++++++++++++++++++++++++++++++
drivers/video/edid.c | 340 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 583 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/edid.h
create mode 100644 drivers/video/edid.c
diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h
new file mode 100644
index 0000000..843346a
--- /dev/null
+++ b/arch/arm/include/asm/edid.h
@@ -0,0 +1,243 @@
+/*
+ * edid.h
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Mythri P K <mythripk@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ * History:
+ */
+
+#ifndef _EDID_H_
+#define _EDID_H_
+
+/* HDMI EDID Length */
+#define HDMI_EDID_MAX_LENGTH 512
+
+/* HDMI EDID Extension Data Block Tags */
+#define HDMI_EDID_EX_DATABLOCK_TAG_MASK 0xE0
+#define HDMI_EDID_EX_DATABLOCK_LEN_MASK 0x1F
+
+#define EDID_TIMING_DESCRIPTOR_SIZE 0x12
+#define EDID_DESCRIPTOR_BLOCK0_ADDRESS 0x36
+#define EDID_DESCRIPTOR_BLOCK1_ADDRESS 0x80
+#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
+#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
+
+/* EDID Detailed Timing Info 0 begin offset */
+#define HDMI_EDID_DETAILED_TIMING_OFFSET 0x36
+
+#define HDMI_EDID_PIX_CLK_OFFSET 0
+#define HDMI_EDID_H_ACTIVE_OFFSET 2
+#define HDMI_EDID_H_BLANKING_OFFSET 3
+#define HDMI_EDID_V_ACTIVE_OFFSET 5
+#define HDMI_EDID_V_BLANKING_OFFSET 6
+#define HDMI_EDID_H_SYNC_OFFSET 8
+#define HDMI_EDID_H_SYNC_PW_OFFSET 9
+#define HDMI_EDID_V_SYNC_OFFSET 10
+#define HDMI_EDID_V_SYNC_PW_OFFSET 11
+#define HDMI_EDID_H_IMAGE_SIZE_OFFSET 12
+#define HDMI_EDID_V_IMAGE_SIZE_OFFSET 13
+#define HDMI_EDID_H_BORDER_OFFSET 15
+#define HDMI_EDID_V_BORDER_OFFSET 16
+#define HDMI_EDID_FLAGS_OFFSET 17
+
+/* HDMI EDID DTDs */
+#define HDMI_EDID_MAX_DTDS 4
+
+/* HDMI EDID DTD Tags */
+#define HDMI_EDID_DTD_TAG_MONITOR_NAME 0xFC
+#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM 0xFF
+#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS 0xFD
+#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA 0xFA
+#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA 0xFB
+#define HDMI_EDID_DTD_TAG_ASCII_STRING 0xFE
+
+#define HDMI_IMG_FORMAT_MAX_LENGTH 20
+#define HDMI_AUDIO_FORMAT_MAX_LENGTH 10
+
+/* HDMI EDID Extenion Data Block Values: Video */
+#define HDMI_EDID_EX_VIDEO_NATIVE 0x80
+#define HDMI_EDID_EX_VIDEO_MASK 0x7F
+#define HDMI_EDID_EX_VIDEO_MAX 35
+
+#define STANDARD_HDMI_TIMINGS_NB 34
+#define STANDARD_HDMI_TIMINGS_VESA_START 15
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+enum extension_edid_db {
+ DATABLOCK_AUDIO = 1,
+ DATABLOCK_VIDEO = 2,
+ DATABLOCK_VENDOR = 3,
+ DATABLOCK_SPEAKERS = 4,
+};
+
+struct img_edid {
+ bool pref;
+ int code;
+};
+
+struct image_format {
+ int length;
+ struct img_edid fmt[HDMI_IMG_FORMAT_MAX_LENGTH];
+};
+
+struct audio_edid {
+ int num_of_ch;
+ int format;
+};
+
+struct audio_format {
+ int length;
+ struct audio_edid fmt[HDMI_AUDIO_FORMAT_MAX_LENGTH];
+};
+
+struct latency {
+ /* vid: if indicated, value=1+ms/2 with a max of 251 meaning 500ms */
+ int vid_latency;
+ int aud_latency;
+ int int_vid_latency;
+ int int_aud_latency;
+};
+
+struct deep_color {
+ bool bit_30;
+ bool bit_36;
+ int max_tmds_freq;
+};
+
+/* Video Descriptor Block */
+struct HDMI_EDID_DTD_VIDEO {
+ u16 pixel_clock; /* 54-55 */
+ u8 horiz_active; /* 56 */
+ u8 horiz_blanking; /* 57 */
+ u8 horiz_high; /* 58 */
+ u8 vert_active; /* 59 */
+ u8 vert_blanking; /* 60 */
+ u8 vert_high; /* 61 */
+ u8 horiz_sync_offset; /* 62 */
+ u8 horiz_sync_pulse; /* 63 */
+ u8 vert_sync_pulse; /* 64 */
+ u8 sync_pulse_high; /* 65 */
+ u8 horiz_image_size; /* 66 */
+ u8 vert_image_size; /* 67 */
+ u8 image_size_high; /* 68 */
+ u8 horiz_border; /* 69 */
+ u8 vert_border; /* 70 */
+ u8 misc_settings; /* 71 */
+};
+
+/* Monitor Limits Descriptor Block */
+struct HDMI_EDID_DTD_MONITOR {
+ u16 pixel_clock; /* 54-55*/
+ u8 _reserved1; /* 56 */
+ u8 block_type; /* 57 */
+ u8 _reserved2; /* 58 */
+ u8 min_vert_freq; /* 59 */
+ u8 max_vert_freq; /* 60 */
+ u8 min_horiz_freq; /* 61 */
+ u8 max_horiz_freq; /* 62 */
+ u8 pixel_clock_mhz; /* 63 */
+ u8 GTF[2]; /* 64 -65 */
+ u8 start_horiz_freq; /* 66 */
+ u8 C; /* 67 */
+ u8 M[2]; /* 68-69 */
+ u8 K; /* 70 */
+ u8 J; /* 71 */
+
+} __packed;
+
+/* Text Descriptor Block */
+struct HDMI_EDID_DTD_TEXT {
+ u16 pixel_clock; /* 54-55 */
+ u8 _reserved1; /* 56 */
+ u8 block_type; /* 57 */
+ u8 _reserved2; /* 58 */
+ u8 text[13]; /* 59-71 */
+} __packed;
+
+/* DTD Union */
+union HDMI_EDID_DTD {
+ struct HDMI_EDID_DTD_VIDEO video;
+ struct HDMI_EDID_DTD_TEXT monitor_name;
+ struct HDMI_EDID_DTD_TEXT monitor_serial_number;
+ struct HDMI_EDID_DTD_TEXT ascii;
+ struct HDMI_EDID_DTD_MONITOR monitor_limits;
+} __packed;
+
+/* EDID struct */
+struct HDMI_EDID {
+ u8 header[8]; /* 00-07 */
+ u16 manufacturerID; /* 08-09 */
+ u16 product_id; /* 10-11 */
+ u32 serial_number; /* 12-15 */
+ u8 week_manufactured; /* 16 */
+ u8 year_manufactured; /* 17 */
+ u8 edid_version; /* 18 */
+ u8 edid_revision; /* 19 */
+ u8 video_in_definition; /* 20 */
+ u8 max_horiz_image_size; /* 21 */
+ u8 max_vert_image_size; /* 22 */
+ u8 display_gamma; /* 23 */
+ u8 power_features; /* 24 */
+ u8 chroma_info[10]; /* 25-34 */
+ u8 timing_1; /* 35 */
+ u8 timing_2; /* 36 */
+ u8 timing_3; /* 37 */
+ u8 std_timings[16]; /* 38-53 */
+ union HDMI_EDID_DTD DTD[4]; /* 54-125 */
+ u8 extension_edid; /* 126 */
+ u8 checksum; /* 127 */
+ u8 extension_tag; /* 00 (extensions follow EDID) */
+ u8 extention_rev; /* 01 */
+ u8 offset_dtd; /* 02 */
+ u8 num_dtd; /* 03 */
+ u8 data_block[123]; /* 04 - 126 */
+ u8 extension_checksum; /* 127 */
+
+ u8 ext_datablock[256];
+} __packed;
+
+struct hdmi_timings {
+
+ u16 x_res;
+ u16 y_res;
+ u32 pixel_clock; /* pixel clock in KHz */
+ u16 hsw; /* Horizontal synchronization pulse width */
+ u16 hfp; /* Horizontal front porch */
+ u16 hbp; /* Horizontal back porch */
+ u16 vsw; /* Vertical synchronization pulse width */
+ u16 vfp; /* Vertical front porch */
+ u16 vbp; /* Vertical back porch */
+};
+
+int get_edid_timing_info(union HDMI_EDID_DTD *edid_dtd,
+ struct hdmi_timings *timings);
+void get_eedid_timing_info(int current_descriptor_addrs, u8 *edid ,
+ struct hdmi_timings *timings);
+int hdmi_get_datablock_offset(u8 *edid, enum extension_edid_db datablock,
+ int *offset);
+int hdmi_get_image_format(u8 *edid, struct image_format *format);
+int hdmi_get_audio_format(u8 *edid, struct audio_format *format);
+void hdmi_get_av_delay(u8 *edid, struct latency *lat);
+void hdmi_deep_color_support_info(u8 *edid, struct deep_color *format);
+bool hdmi_tv_yuv_supported(u8 *edid);
+
+#ifdef __cplusplus
+};
+#endif
+
+#endif
diff --git a/drivers/video/edid.c b/drivers/video/edid.c
new file mode 100644
index 0000000..4eb2074
--- /dev/null
+++ b/drivers/video/edid.c
@@ -0,0 +1,340 @@
+/*
+ * edid.c
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Mythri P K <mythripk@ti.com>
+ * With EDID parsing for DVI Monitor from Rob Clark <rob@ti.com>
+ *
+ * EDID.c to parse the EDID content.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ * History:
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/err.h>
+#include <linux/string.h>
+#include <linux/slab.h>
+#include <asm/edid.h>
+
+/* Standard HDMI/VESA timings */
+const struct hdmi_timings standard_hdmi_timings[STANDARD_HDMI_TIMINGS_NB] = {
+ {640, 480, 25200, 96, 16, 48, 2, 10, 33},
+ {1280, 720, 74250, 40, 440, 220, 5, 5, 20},
+ {1280, 720, 74250, 40, 110, 220, 5, 5, 20},
+ {720, 480, 27027, 62, 16, 60, 6, 9, 30},
+ {2880, 576, 108000, 256, 48, 272, 5, 5, 39},
+ {1440, 240, 27027, 124, 38, 114, 3, 4, 15},
+ {1440, 288, 27000, 126, 24, 138, 3, 2, 19},
+ {1920, 540, 74250, 44, 528, 148, 5, 2, 15},
+ {1920, 540, 74250, 44, 88, 148, 5, 2, 15},
+ {1920, 1080, 148500, 44, 88, 148, 5, 4, 36},
+ {720, 576, 27000, 64, 12, 68, 5, 5, 39},
+ {1440, 576, 54000, 128, 24, 136, 5, 5, 39},
+ {1920, 1080, 148500, 44, 528, 148, 5, 4, 36},
+ {2880, 480, 108108, 248, 64, 240, 6, 9, 30},
+ {1920, 1080, 74250, 44, 638, 148, 5, 4, 36},
+ /* Vesa frome here */
+ {640, 480, 25175, 96, 16, 48, 2 , 11, 31},
+ {800, 600, 40000, 128, 40, 88, 4 , 1, 23},
+ {848, 480, 33750, 112, 16, 112, 8 , 6, 23},
+ {1280, 768, 79500, 128, 64, 192, 7 , 3, 20},
+ {1280, 800, 83500, 128, 72, 200, 6 , 3, 22},
+ {1360, 768, 85500, 112, 64, 256, 6 , 3, 18},
+ {1280, 960, 108000, 112, 96, 312, 3 , 1, 36},
+ {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38},
+ {1024, 768, 65000, 136, 24, 160, 6, 3, 29},
+ {1400, 1050, 121750, 144, 88, 232, 4, 3, 32},
+ {1440, 900, 106500, 152, 80, 232, 6, 3, 25},
+ {1680, 1050, 146250, 176 , 104, 280, 6, 3, 30},
+ {1366, 768, 85500, 143, 70, 213, 3, 3, 24},
+ {1920, 1080, 148500, 44, 88, 80, 5, 4, 36},
+ {1280, 768, 68250, 32, 48, 80, 7, 3, 12},
+ {1400, 1050, 101000, 32, 48, 80, 4, 3, 23},
+ {1680, 1050, 119000, 32, 48, 80, 6, 3, 21},
+ {1280, 800, 79500, 32, 48, 80, 6, 3, 14},
+ {1280, 720, 74250, 40, 110, 220, 5, 5, 20}
+};
+
+int get_edid_timing_info(union HDMI_EDID_DTD *edid_dtd,
+ struct hdmi_timings *timings)
+{
+ if (edid_dtd->video.pixel_clock) {
+ struct HDMI_EDID_DTD_VIDEO *vid = &edid_dtd->video;
+
+ timings->pixel_clock = 10 * vid->pixel_clock;
+ timings->x_res = vid->horiz_active |
+ (((u16)vid->horiz_high & 0xf0) << 4);
+ timings->y_res = vid->vert_active |
+ (((u16)vid->vert_high & 0xf0) << 4);
+ timings->hfp = vid->horiz_sync_offset |
+ (((u16)vid->sync_pulse_high & 0xc0) << 2);
+ timings->hsw = vid->horiz_sync_pulse |
+ (((u16)vid->sync_pulse_high & 0x30) << 4);
+ timings->hbp = (vid->horiz_blanking |
+ (((u16)vid->horiz_high & 0x0f) << 8)) -
+ (timings->hfp + timings->hsw);
+ timings->vfp = ((vid->vert_sync_pulse & 0xf0) >> 4) |
+ ((vid->sync_pulse_high & 0x0f) << 2);
+ timings->vsw = (vid->vert_sync_pulse & 0x0f) |
+ ((vid->sync_pulse_high & 0x03) << 4);
+ timings->vbp = (vid->vert_blanking |
+ (((u16)vid->vert_high & 0x0f) << 8)) -
+ (timings->vfp + timings->vsw);
+ return 0;
+ }
+
+ switch (edid_dtd->monitor_name.block_type) {
+ case HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA:
+ printk(KERN_INFO "standard timing data\n");
+ return -EINVAL;
+ case HDMI_EDID_DTD_TAG_COLOR_POINT_DATA:
+ printk(KERN_INFO "color point data\n");
+ return -EINVAL;
+ case HDMI_EDID_DTD_TAG_MONITOR_NAME:
+ printk(KERN_INFO "monitor name: %s\n",
+ edid_dtd->monitor_name.text);
+ return -EINVAL;
+ case HDMI_EDID_DTD_TAG_MONITOR_LIMITS:
+ {
+ int i, max_area = 0, best_idx = -1;
+ struct HDMI_EDID_DTD_MONITOR *limits + &edid_dtd->monitor_limits;
+
+ printk(KERN_DEBUG " monitor limits\n");
+ printk(KERN_DEBUG " min_vert_freq=%d\n",
+ limits->min_vert_freq);
+ printk(KERN_DEBUG " max_vert_freq=%d\n",
+ limits->max_vert_freq);
+ printk(KERN_DEBUG " min_horiz_freq=%d\n",
+ limits->min_horiz_freq);
+ printk(KERN_DEBUG " max_horiz_freq=%d\n",
+ limits->max_horiz_freq);
+ printk(KERN_DEBUG " pixel_clock_mhz=%d\n",
+ limits->pixel_clock_mhz * 10);
+
+ /* find the highest matching resolution (w*h) */
+
+ /*
+ * XXX since this is mainly for DVI monitors, should we only
+ * support VESA timings? My monitor at home would pick
+ * 1920x1080 otherwise, but that seems to not work well (monitor
+ * blanks out and comes back, and picture doesn't fill full
+ * screen, but leaves a black bar on left (native res is
+ * 2048x1152). However if I only consider VESA timings, it picks
+ * 1680x1050 and the picture is stable and fills whole screen
+ */
+ for (i = STANDARD_HDMI_TIMINGS_VESA_START;
+ i < STANDARD_HDMI_TIMINGS_NB; i++) {
+ const struct hdmi_timings *timings + &standard_hdmi_timings[i];
+ int hz, hscan, pixclock;
+ int vtotal, htotal;
+ htotal = timings->hbp + timings->hfp +
+ timings->hsw + timings->x_res;
+ vtotal = timings->vbp + timings->vfp +
+ timings->vsw + timings->y_res;
+
+ /* NOTE: We don't support interlaced mode for VESA */
+ pixclock = timings->pixel_clock * 1000;
+ hscan = (pixclock + htotal / 2) / htotal;
+ hscan = (hscan + 500) / 1000 * 1000;
+ hz = (hscan + vtotal / 2) / vtotal;
+ hscan /= 1000;
+ pixclock /= 1000000;
+ if ((pixclock < (limits->pixel_clock_mhz * 10)) &&
+ (limits->min_horiz_freq <= hscan) &&
+ (hscan <= limits->max_horiz_freq) &&
+ (limits->min_vert_freq <= hz) &&
+ (hz <= limits->max_vert_freq)) {
+ int area = timings->x_res * timings->y_res;
+ printk(KERN_INFO " -> %d: %dx%d\n", i,
+ timings->x_res, timings->y_res);
+ if (area > max_area) {
+ max_area = area;
+ best_idx = i;
+ }
+ }
+ }
+ if (best_idx > 0) {
+ *timings = standard_hdmi_timings[best_idx];
+ printk(KERN_DEBUG "found best resolution: %dx%d (%d)\n",
+ timings->x_res, timings->y_res, best_idx);
+ }
+ return 0;
+ }
+ case HDMI_EDID_DTD_TAG_ASCII_STRING:
+ printk(KERN_INFO "ascii string: %s\n", edid_dtd->ascii.text);
+ return -EINVAL;
+ case HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM:
+ printk(KERN_INFO "monitor serialnum: %s\n",
+ edid_dtd->monitor_serial_number.text);
+ return -EINVAL;
+ default:
+ printk(KERN_INFO "unsupported EDID descriptor block format\n");
+ return -EINVAL;
+ }
+}
+
+void get_eedid_timing_info(int current_descriptor_addrs, u8 *edid ,
+ struct hdmi_timings *timings)
+{
+ timings->x_res = (((edid[current_descriptor_addrs + 4] & 0xF0) << 4)
+ | edid[current_descriptor_addrs + 2]);
+ timings->y_res = (((edid[current_descriptor_addrs + 7] & 0xF0) << 4)
+ | edid[current_descriptor_addrs + 5]);
+ timings->pixel_clock = ((edid[current_descriptor_addrs + 1] << 8)
+ | edid[current_descriptor_addrs]);
+ timings->pixel_clock = 10 * timings->pixel_clock;
+ timings->hfp = edid[current_descriptor_addrs + 8];
+ timings->hsw = edid[current_descriptor_addrs + 9];
+ timings->hbp = (((edid[current_descriptor_addrs + 4] & 0x0F) << 8)
+ | edid[current_descriptor_addrs + 3]) -
+ (timings->hfp + timings->hsw);
+ timings->vfp = ((edid[current_descriptor_addrs + 10] & 0xF0) >> 4);
+ timings->vsw = (edid[current_descriptor_addrs + 10] & 0x0F);
+ timings->vbp = (((edid[current_descriptor_addrs + 7] & 0x0F) << 8)
+ | edid[current_descriptor_addrs + 6]) -
+ (timings->vfp + timings->vsw);
+}
+
+int hdmi_get_datablock_offset(u8 *edid, enum extension_edid_db datablock,
+ int *offset)
+{
+ int current_byte, disp, i = 0, length = 0;
+
+ if (edid[0x7e] = 0x00)
+ return -EINVAL;
+
+ disp = edid[(0x80) + 2];
+ if (disp = 0x4)
+ return -EINVAL;
+
+ i = 0x80 + 0x4;
+ printk(KERN_INFO "%x\n", i);
+ while (i < (0x80 + disp)) {
+ current_byte = edid[i];
+ if ((current_byte >> 5) = datablock) {
+ *offset = i;
+ printk(KERN_INFO "datablock %d %d\n",
+ datablock, *offset);
+ return 0;
+ } else {
+ length = (current_byte &
+ HDMI_EDID_EX_DATABLOCK_LEN_MASK) + 1;
+ i += length;
+ }
+ }
+ return -EINVAL;
+}
+
+int hdmi_get_image_format(u8 *edid, struct image_format *format)
+{
+ int offset, current_byte, j = 0, length = 0;
+ enum extension_edid_db vsdb = DATABLOCK_VIDEO;
+ format->length = 0;
+
+ memset(format->fmt, 0, sizeof(format->fmt));
+ if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
+ current_byte = edid[offset];
+ length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
+
+ if (length >= HDMI_IMG_FORMAT_MAX_LENGTH)
+ format->length = HDMI_IMG_FORMAT_MAX_LENGTH;
+ else
+ format->length = length;
+
+ for (j = 1 ; j < length ; j++) {
+ current_byte = edid[offset+j];
+ format->fmt[j-1].code = current_byte & 0x7F;
+ format->fmt[j-1].pref = current_byte & 0x80;
+ }
+ }
+ return 0;
+}
+
+int hdmi_get_audio_format(u8 *edid, struct audio_format *format)
+{
+ int offset, current_byte, j = 0, length = 0;
+ enum extension_edid_db vsdb = DATABLOCK_AUDIO;
+
+ format->length = 0;
+ memset(format->fmt, 0, sizeof(format->fmt));
+
+ if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
+ current_byte = edid[offset];
+ length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
+
+ if (length >= HDMI_AUDIO_FORMAT_MAX_LENGTH)
+ format->length = HDMI_AUDIO_FORMAT_MAX_LENGTH;
+ else
+ format->length = length;
+
+ for (j = 1 ; j < length ; j++) {
+ if (j%3 = 1) {
+ current_byte = edid[offset + j];
+ format->fmt[j-1].format = current_byte & 0x78;
+ format->fmt[j-1].num_of_ch + (current_byte & 0x07) + 1;
+ }
+ }
+ }
+ return 0;
+}
+
+void hdmi_get_av_delay(u8 *edid, struct latency *lat)
+{
+ int offset, current_byte, length = 0;
+ enum extension_edid_db vsdb = DATABLOCK_VENDOR;
+
+ if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
+ current_byte = edid[offset];
+ length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
+ if (length >= 8 && ((current_byte + 8) & 0x80)) {
+ lat->vid_latency = (edid[offset + 8] - 1) * 2;
+ lat->aud_latency = (edid[offset + 9] - 1) * 2;
+ }
+ if (length >= 8 && ((current_byte + 8) & 0xC0)) {
+ lat->int_vid_latency = (edid[offset + 10] - 1) * 2;
+ lat->int_aud_latency = (edid[offset + 11] - 1) * 2;
+ }
+ }
+}
+
+void hdmi_deep_color_support_info(u8 *edid, struct deep_color *format)
+{
+ int offset, current_byte, length = 0;
+ enum extension_edid_db vsdb = DATABLOCK_VENDOR;
+ memset(format, 0, sizeof(*format));
+
+ if (!hdmi_get_datablock_offset(edid, vsdb, &offset)) {
+ current_byte = edid[offset];
+ length = current_byte & HDMI_EDID_EX_DATABLOCK_LEN_MASK;
+ if (length >= 6) {
+ format->bit_30 = (edid[offset + 6] & 0x10);
+ format->bit_36 = (edid[offset + 6] & 0x20);
+ }
+ if (length >= 7)
+ format->max_tmds_freq = (edid[offset + 7]) * 5;
+ }
+}
+
+bool hdmi_tv_yuv_supported(u8 *edid)
+{
+ if (edid[0x7e] != 0x00 && edid[0x83] & 0x30) {
+ printk(KERN_INFO "YUV supported");
+ return true;
+ }
+ return false;
+}
--
1.5.6.3
^ permalink raw reply related
* Re: Future desktop on dumb frame buffers?
From: Michal Suchanek @ 2011-03-22 15:26 UTC (permalink / raw)
To: Jesse Barnes
Cc: timofonic timofonic, Geert Uytterhoeven,
Linux Fbdev development list,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20110321122518.6b7ec7e4@jbarnes-desktop>
On 21 March 2011 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 21 Mar 2011 19:19:43 +0000
> timofonic timofonic <timofonic@gmail.com> wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what? All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia). If you want it for a particular device, you
> can always port it over.
>
> As for fbdev emulation, what's still using it? There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.
The console and a few terminal emulators for it I guess.
Thanks
Michal
^ permalink raw reply
* Update Your E-Mail Details Account
From: Information Technology @ 2011-03-22 14:38 UTC (permalink / raw)
To: linux-fbdev
Confirm Your E-Mail Details
Dear Email User
This message is from Information Technology Services of This EMAIL to all our Staff. We are currently upgrading our database and e-mail center and this is our final notification to you.we have sent several messages to you without response.
We are deleting all unused Mail account to create space for new accounts. In order not to be suspended, you will have to update your account by providing the information listed below:
Confirm Your E-Mail Details..
Email.......................
User name: ..................
Password:..............
Re Confirm Password:.............
If you fail to confirm your continuous usage of our services by confirming your email password now, your account will be disable and you will not be able to access your email.
You should immediately reply this email: upgrading2010@mail.md and enter your password in the above password column.
Thanks for your understanding.
Regard,
IT Services
^ permalink raw reply
* Re: [PATCH v6 6/6] powerpc, tqm5200: update tqm5200_defconfig to
From: Wolfram Sang @ 2011-03-22 9:10 UTC (permalink / raw)
To: Heiko Schocher
Cc: linuxppc-dev, Grant Likely, Benjamin Herrenschmidt, linux-fbdev,
devicetree-discuss, Ben Dooks, Vincent Sanders, Samuel Ortiz,
linux-kernel, Randy Dunlap, Wolfgang Denk, Paul Mundt
In-Reply-To: <1300782452-528-7-git-send-email-hs@denx.de>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
> As this board is tqm5200 based, added necessary changes
> to the tqm5200_defconfig. In previous patchserie I added
> the changes to mpc5200_defconfig, as Wolfram Sang mentioned,
> but as tqm5200_defconfig is in mainline, and the board is
> tqm5200 based, I think, thats the appropriate place, as
I'd think the perfect solution would have been to merge the
tqm-defconfig into the mpc5200-defconfig entirely and get rid of it.
That being said, I don't think this issue is big enough to block this
series, so fine enough with me.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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