* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: K, Mythri P @ 2011-03-24 9:52 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Dave Airlie, linux-fbdev, linux-omap, dri-devel, linux-media
In-Reply-To: <20110323081820.5b37d169@jbarnes-desktop>
Hi Jesse,
On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> 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.
>
This sounds good. If we can remove the DRM dependent portion to have a
library-ized EDID code,
That would be perfect. The main Intention to have a library is,
Instead of having several different Implementation in kernel, all
doing the same EDID parsing , if we could have one single
implementation , it would help in better testing and interoperability.
> Do you really think the differences between your code and the existing
> DRM code are irreconcilable?
>
On the contrary if there is a library-ized EDID parsing using the
drm_edid, and there is any delta / fields( Parsing the video block in
CEA extension for Short Video Descriptor, Vendor block for AV delay
/Deep color information etc) that are parsed with the RFC i posted i
would be happy to add.
Thanks and regards,
Mythri.
> --
> Jesse Barnes, Intel Open Source Technology Center
>
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Laurent Pinchart @ 2011-03-24 11:05 UTC (permalink / raw)
To: Robert Fekete
Cc: Alex Deucher, Geert Uytterhoeven, dri-devel, timofonic timofonic,
Linux Fbdev development list, wayland-devel, linaro-dev,
linux-media
In-Reply-To: <AANLkTi=fWKt=v5O9A7XivDiFaJyki6H90k1=Jfcmw2dN@mail.gmail.com>
On Wednesday 23 March 2011 15:09:54 Robert Fekete wrote:
> On 21 March 2011 21:08, Alex Deucher <alexdeucher@gmail.com> wrote:
> > On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven wrote:
> >> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes wrote:
> >>> On Mon, 21 Mar 2011 19:19:43 +0000 timofonic timofonic 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.
We're also evaluating the possibility of providing a generic fbdev emulation
layer on top of V4L2 without requiring any device-specific fbdev code. fbdev
isn't maintained and hasn't really evolved for quite some time now.
> 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.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* viafb clock patches - second round
From: Florian Tobias Schandinat @ 2011-03-24 15:57 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel
Here are the remaining clock patches which finally put it in a good
shape. Most of the clock and PLL went into an extra file making the
codebase more structured. Only the PLL table and related code was
left out as it is not yet in a desirable state as this table is only
usable for the X1 source as the limits are frequency dependend.
All patches (including first round) are also available at
git://github.com/schandinat/linux-2.6.git viafb-pll
and will also show up in linux-nexxt after the early rc's are done.
Thanks,
Florian Tobias Schandinat
^ permalink raw reply
* [PATCH 1/3] viafb: add primary/secondary clock on/off switches
From: Florian Tobias Schandinat @ 2011-03-24 15:57 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300983180-7343-1-git-send-email-FlorianSchandinat@gmx.de>
This patch adds functions to enable/disable the display clocks.
It also fixes a tiny bug that slipped in with a previous commit but
could not yet have caused any problems.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 38 +++++++++++++++++++++++++++++++++++++-
1 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index b38d3b4..712348d 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1409,6 +1409,42 @@ void viafb_load_FIFO_reg(int set_iga, int hor_active, int ver_active)
}
+static void set_primary_clock_state(u8 state)
+{
+ u8 value;
+
+ switch (state) {
+ case VIA_STATE_ON:
+ value = 0x20;
+ break;
+ case VIA_STATE_OFF:
+ value = 0x00;
+ break;
+ default:
+ return;
+ }
+
+ via_write_reg_mask(VIASR, 0x1B, value, 0x30);
+}
+
+static void set_secondary_clock_state(u8 state)
+{
+ u8 value;
+
+ switch (state) {
+ case VIA_STATE_ON:
+ value = 0x80;
+ break;
+ case VIA_STATE_OFF:
+ value = 0x00;
+ break;
+ default:
+ return;
+ }
+
+ via_write_reg_mask(VIASR, 0x1B, value, 0xC0);
+}
+
static void set_primary_pll_state(u8 state)
{
u8 value;
@@ -1442,7 +1478,7 @@ static void set_secondary_pll_state(u8 state)
return;
}
- via_write_reg_mask(VIASR, 0x2D, value, 0x08);
+ via_write_reg_mask(VIASR, 0x2D, value, 0x0C);
}
static u32 cle266_encode_pll(struct pll_config pll)
--
1.6.3.2
^ permalink raw reply related
* [PATCH 3/3] viafb: add VIA slapping capability
From: Florian Tobias Schandinat @ 2011-03-24 15:57 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300983180-7343-1-git-send-email-FlorianSchandinat@gmx.de>
This patch introduces dummy functions to execute when we don't know
what we should do (due to missing documentation). They do nothing
but print a nice message in the log explaining the situation.
To trigger this message initial power management support is
activated which might save a bit energy by disabling PLL and clock
if no device is configured to use them.
Note: The message is only shown for the oldest IGPs CLE266 and K400
as for the other platforms there are reasonable assumptions
how it does (hopefully) work.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 19 +++++++++++++++++++
drivers/video/via/via_clock.c | 30 ++++++++++++++++++++++++------
2 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index f1eff0b..df84251 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -2289,6 +2289,25 @@ int viafb_setmode(struct VideoModeTable *vmode_tbl, int video_bpp,
get_sync(viafbinfo1));
}
+ clock.set_primary_clock_source(VIA_CLKSRC_X1, true);
+ clock.set_secondary_clock_source(VIA_CLKSRC_X1, true);
+
+ if (viaparinfo->shared->iga1_devices) {
+ clock.set_primary_pll_state(VIA_STATE_ON);
+ clock.set_primary_clock_state(VIA_STATE_ON);
+ } else {
+ clock.set_primary_pll_state(VIA_STATE_OFF);
+ clock.set_primary_clock_state(VIA_STATE_OFF);
+ }
+
+ if (viaparinfo->shared->iga2_devices) {
+ clock.set_secondary_pll_state(VIA_STATE_ON);
+ clock.set_secondary_clock_state(VIA_STATE_ON);
+ } else {
+ clock.set_secondary_pll_state(VIA_STATE_OFF);
+ clock.set_secondary_clock_state(VIA_STATE_OFF);
+ }
+
via_set_state(devices, VIA_STATE_ON);
device_screen_on();
return 1;
diff --git a/drivers/video/via/via_clock.c b/drivers/video/via/via_clock.c
index 29afe4c..a1f9039 100644
--- a/drivers/video/via/via_clock.c
+++ b/drivers/video/via/via_clock.c
@@ -29,6 +29,9 @@
#include "global.h"
#include "debug.h"
+const char *via_slap = "Please slap VIA Technologies to motivate them "
+ "releasing full documentation for your platform!\n";
+
static inline u32 cle266_encode_pll(struct via_pll_config pll)
{
return (pll.multiplier << 8)
@@ -229,19 +232,34 @@ static void set_secondary_clock_source(enum via_clksrc source, bool use_pll)
via_write_reg_mask(VIACR, 0x6C, data, 0x0F);
}
+static void dummy_set_clock_state(u8 state)
+{
+ printk(KERN_INFO "Using undocumented set clock state.\n%s", via_slap);
+}
+
+static void dummy_set_clock_source(enum via_clksrc source, bool use_pll)
+{
+ printk(KERN_INFO "Using undocumented set slock soure.\n%s", via_slap);
+}
+
+static void dummy_set_pll_state(u8 state)
+{
+ printk(KERN_INFO "Using undocumented set PLL state.\n%s", via_slap);
+}
+
void via_clock_init(struct via_clock *clock, int gfx_chip)
{
switch (gfx_chip) {
case UNICHROME_CLE266:
case UNICHROME_K400:
- clock->set_primary_clock_state = NULL;
- clock->set_primary_clock_source = NULL;
- clock->set_primary_pll_state = NULL;
+ clock->set_primary_clock_state = dummy_set_clock_state;
+ clock->set_primary_clock_source = dummy_set_clock_source;
+ clock->set_primary_pll_state = dummy_set_pll_state;
clock->set_primary_pll = cle266_set_primary_pll;
- clock->set_secondary_clock_state = NULL;
- clock->set_secondary_clock_source = NULL;
- clock->set_secondary_pll_state = NULL;
+ clock->set_secondary_clock_state = dummy_set_clock_state;
+ clock->set_secondary_clock_source = dummy_set_clock_source;
+ clock->set_secondary_pll_state = dummy_set_pll_state;
clock->set_secondary_pll = cle266_set_secondary_pll;
break;
case UNICHROME_K800:
--
1.6.3.2
^ permalink raw reply related
* [PATCH 2/3] viafb: split clock and PLL code to an extra file
From: Florian Tobias Schandinat @ 2011-03-24 15:57 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300983180-7343-1-git-send-email-FlorianSchandinat@gmx.de>
This patch is a huge move operation with some rename and introduces
an interface to still use the functions. This should be a step in
the right direction to reuse the code whenever possible but cleanly
separate code that differs on different platform and keeping the
complexity as low as possible.
pll_config was renamed to via_pll_config to keep the naming scheme.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/Makefile | 2 +-
drivers/video/via/hw.c | 288 ++---------------------------------------
drivers/video/via/hw.h | 6 -
drivers/video/via/via_clock.c | 280 +++++++++++++++++++++++++++++++++++++++
drivers/video/via/via_clock.h | 73 +++++++++++
5 files changed, 368 insertions(+), 281 deletions(-)
create mode 100644 drivers/video/via/via_clock.c
create mode 100644 drivers/video/via/via_clock.h
diff --git a/drivers/video/via/Makefile b/drivers/video/via/Makefile
index 96f01ee..5108136 100644
--- a/drivers/video/via/Makefile
+++ b/drivers/video/via/Makefile
@@ -6,4 +6,4 @@ obj-$(CONFIG_FB_VIA) += viafb.o
viafb-y :=viafbdev.o hw.o via_i2c.o dvi.o lcd.o ioctl.o accel.o \
via_utility.o vt1636.o global.o tblDPASetting.o viamode.o \
- via-core.o via-gpio.o via_modesetting.o
+ via-core.o via-gpio.o via_modesetting.o via_clock.o
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 712348d..f1eff0b 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -21,6 +21,7 @@
#include <linux/via-core.h>
#include "global.h"
+#include "via_clock.h"
static struct pll_limit cle266_pll_limits[] = {
{19, 19, 4, 0},
@@ -484,6 +485,9 @@ static struct via_device_mapping device_mapping[] = {
{VIA_LVDS2, "LVDS2"}
};
+/* structure with function pointers to support clock control */
+static struct via_clock clock;
+
static void load_fix_bit_crtc_reg(void);
static void __devinit init_gfx_chip_info(int chip_type);
static void __devinit init_tmds_chip_info(void);
@@ -1409,230 +1413,10 @@ void viafb_load_FIFO_reg(int set_iga, int hor_active, int ver_active)
}
-static void set_primary_clock_state(u8 state)
-{
- u8 value;
-
- switch (state) {
- case VIA_STATE_ON:
- value = 0x20;
- break;
- case VIA_STATE_OFF:
- value = 0x00;
- break;
- default:
- return;
- }
-
- via_write_reg_mask(VIASR, 0x1B, value, 0x30);
-}
-
-static void set_secondary_clock_state(u8 state)
-{
- u8 value;
-
- switch (state) {
- case VIA_STATE_ON:
- value = 0x80;
- break;
- case VIA_STATE_OFF:
- value = 0x00;
- break;
- default:
- return;
- }
-
- via_write_reg_mask(VIASR, 0x1B, value, 0xC0);
-}
-
-static void set_primary_pll_state(u8 state)
-{
- u8 value;
-
- switch (state) {
- case VIA_STATE_ON:
- value = 0x20;
- break;
- case VIA_STATE_OFF:
- value = 0x00;
- break;
- default:
- return;
- }
-
- via_write_reg_mask(VIASR, 0x2D, value, 0x30);
-}
-
-static void set_secondary_pll_state(u8 state)
-{
- u8 value;
-
- switch (state) {
- case VIA_STATE_ON:
- value = 0x08;
- break;
- case VIA_STATE_OFF:
- value = 0x00;
- break;
- default:
- return;
- }
-
- via_write_reg_mask(VIASR, 0x2D, value, 0x0C);
-}
-
-static u32 cle266_encode_pll(struct pll_config pll)
-{
- return (pll.multiplier << 8)
- | (pll.rshift << 6)
- | pll.divisor;
-}
-
-static u32 k800_encode_pll(struct pll_config pll)
-{
- return ((pll.divisor - 2) << 16)
- | (pll.rshift << 10)
- | (pll.multiplier - 2);
-}
-
-static u32 vx855_encode_pll(struct pll_config pll)
-{
- return (pll.divisor << 16)
- | (pll.rshift << 10)
- | pll.multiplier;
-}
-
-static inline void cle266_set_primary_pll_encoded(u32 data)
-{
- via_write_reg_mask(VIASR, 0x40, 0x02, 0x02); /* enable reset */
- via_write_reg(VIASR, 0x46, data & 0xFF);
- via_write_reg(VIASR, 0x47, (data >> 8) & 0xFF);
- via_write_reg_mask(VIASR, 0x40, 0x00, 0x02); /* disable reset */
-}
-
-static inline void k800_set_primary_pll_encoded(u32 data)
-{
- via_write_reg_mask(VIASR, 0x40, 0x02, 0x02); /* enable reset */
- via_write_reg(VIASR, 0x44, data & 0xFF);
- via_write_reg(VIASR, 0x45, (data >> 8) & 0xFF);
- via_write_reg(VIASR, 0x46, (data >> 16) & 0xFF);
- via_write_reg_mask(VIASR, 0x40, 0x00, 0x02); /* disable reset */
-}
-
-static inline void cle266_set_secondary_pll_encoded(u32 data)
-{
- via_write_reg_mask(VIASR, 0x40, 0x04, 0x04); /* enable reset */
- via_write_reg(VIASR, 0x44, data & 0xFF);
- via_write_reg(VIASR, 0x45, (data >> 8) & 0xFF);
- via_write_reg_mask(VIASR, 0x40, 0x00, 0x04); /* disable reset */
-}
-
-static inline void k800_set_secondary_pll_encoded(u32 data)
-{
- via_write_reg_mask(VIASR, 0x40, 0x04, 0x04); /* enable reset */
- via_write_reg(VIASR, 0x4A, data & 0xFF);
- via_write_reg(VIASR, 0x4B, (data >> 8) & 0xFF);
- via_write_reg(VIASR, 0x4C, (data >> 16) & 0xFF);
- via_write_reg_mask(VIASR, 0x40, 0x00, 0x04); /* disable reset */
-}
-
-static void cle266_set_primary_pll(struct pll_config config)
-{
- cle266_set_primary_pll_encoded(cle266_encode_pll(config));
-}
-
-static void k800_set_primary_pll(struct pll_config config)
-{
- k800_set_primary_pll_encoded(k800_encode_pll(config));
-}
-
-static void vx855_set_primary_pll(struct pll_config config)
-{
- k800_set_primary_pll_encoded(vx855_encode_pll(config));
-}
-
-static void cle266_set_secondary_pll(struct pll_config config)
-{
- cle266_set_secondary_pll_encoded(cle266_encode_pll(config));
-}
-
-static void k800_set_secondary_pll(struct pll_config config)
-{
- k800_set_secondary_pll_encoded(k800_encode_pll(config));
-}
-
-static void vx855_set_secondary_pll(struct pll_config config)
-{
- k800_set_secondary_pll_encoded(vx855_encode_pll(config));
-}
-
-enum via_clksrc {
- VIA_CLKSRC_X1 = 0,
- VIA_CLKSRC_TVX1,
- VIA_CLKSRC_TVPLL,
- VIA_CLKSRC_DVP1TVCLKR,
- VIA_CLKSRC_CAP0,
- VIA_CLKSRC_CAP1,
-};
-
-static inline u8 set_clock_source_common(enum via_clksrc source, bool use_pll)
-{
- u8 data = 0;
-
- switch (source) {
- case VIA_CLKSRC_X1:
- data = 0x00;
- break;
- case VIA_CLKSRC_TVX1:
- data = 0x02;
- break;
- case VIA_CLKSRC_TVPLL:
- data = 0x04; /* 0x06 should be the same */
- break;
- case VIA_CLKSRC_DVP1TVCLKR:
- data = 0x0A;
- break;
- case VIA_CLKSRC_CAP0:
- data = 0xC;
- break;
- case VIA_CLKSRC_CAP1:
- data = 0x0E;
- break;
- }
-
- if (!use_pll)
- data |= 1;
-
- return data;
-}
-
-static void set_primary_clock_source(enum via_clksrc source, bool use_pll)
-{
- u8 data = set_clock_source_common(source, use_pll) << 4;
- via_write_reg_mask(VIACR, 0x6C, data, 0xF0);
-}
-
-static void set_secondary_clock_source(enum via_clksrc source, bool use_pll)
-{
- u8 data = set_clock_source_common(source, use_pll);
- via_write_reg_mask(VIACR, 0x6C, data, 0x0F);
-}
-
-static inline u32 get_pll_internal_frequency(u32 ref_freq,
- struct pll_config pll)
-{
- return ref_freq / pll.divisor * pll.multiplier;
-}
-
-static inline u32 get_pll_output_frequency(u32 ref_freq, struct pll_config pll)
-{
- return get_pll_internal_frequency(ref_freq, pll)>>pll.rshift;
-}
-
-static struct pll_config get_pll_config(struct pll_limit *limits, int size,
+static struct via_pll_config get_pll_config(struct pll_limit *limits, int size,
int clk)
{
- struct pll_config cur, up, down, best = {0, 1, 0};
+ struct via_pll_config cur, up, down, best = {0, 1, 0};
const u32 f0 = 14318180; /* X1 frequency */
int i, f;
@@ -1662,9 +1446,9 @@ static struct pll_config get_pll_config(struct pll_limit *limits, int size,
return best;
}
-static struct pll_config get_best_pll_config(int clk)
+static struct via_pll_config get_best_pll_config(int clk)
{
- struct pll_config config;
+ struct via_pll_config config;
switch (viaparinfo->chip_info->gfx_chip_name) {
case UNICHROME_CLE266:
@@ -1700,57 +1484,12 @@ static struct pll_config get_best_pll_config(int clk)
/* Set VCLK*/
void viafb_set_vclock(u32 clk, int set_iga)
{
- struct pll_config config = get_best_pll_config(clk);
+ struct via_pll_config config = get_best_pll_config(clk);
- if (set_iga = IGA1) {
- /* Change D,N FOR VCLK */
- switch (viaparinfo->chip_info->gfx_chip_name) {
- case UNICHROME_CLE266:
- case UNICHROME_K400:
- cle266_set_primary_pll(config);
- break;
- case UNICHROME_K800:
- case UNICHROME_PM800:
- case UNICHROME_CN700:
- case UNICHROME_CX700:
- case UNICHROME_CN750:
- case UNICHROME_K8M890:
- case UNICHROME_P4M890:
- case UNICHROME_P4M900:
- case UNICHROME_VX800:
- k800_set_primary_pll(config);
- break;
- case UNICHROME_VX855:
- case UNICHROME_VX900:
- vx855_set_primary_pll(config);
- break;
- }
- }
-
- if (set_iga = IGA2) {
- /* Change D,N FOR LCK */
- switch (viaparinfo->chip_info->gfx_chip_name) {
- case UNICHROME_CLE266:
- case UNICHROME_K400:
- cle266_set_secondary_pll(config);
- break;
- case UNICHROME_K800:
- case UNICHROME_PM800:
- case UNICHROME_CN700:
- case UNICHROME_CX700:
- case UNICHROME_CN750:
- case UNICHROME_K8M890:
- case UNICHROME_P4M890:
- case UNICHROME_P4M900:
- case UNICHROME_VX800:
- k800_set_secondary_pll(config);
- break;
- case UNICHROME_VX855:
- case UNICHROME_VX900:
- vx855_set_secondary_pll(config);
- break;
- }
- }
+ if (set_iga = IGA1)
+ clock.set_primary_pll(config);
+ if (set_iga = IGA2)
+ clock.set_secondary_pll(config);
/* Fire! */
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
@@ -2059,6 +1798,7 @@ void viafb_fill_crtc_timing(struct crt_mode_table *crt_table,
void __devinit viafb_init_chip_info(int chip_type)
{
+ via_clock_init(&clock, chip_type);
init_gfx_chip_info(chip_type);
init_tmds_chip_info();
init_lvds_chip_info();
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 2cdce9b..7e9f51a 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -732,12 +732,6 @@ struct _lcd_scaling_factor {
struct _lcd_ver_scaling_factor lcd_ver_scaling_factor;
};
-struct pll_config {
- u16 multiplier;
- u8 divisor;
- u8 rshift;
-};
-
struct pll_limit {
u16 multiplier_min;
u16 multiplier_max;
diff --git a/drivers/video/via/via_clock.c b/drivers/video/via/via_clock.c
new file mode 100644
index 0000000..29afe4c
--- /dev/null
+++ b/drivers/video/via/via_clock.c
@@ -0,0 +1,280 @@
+/*
+ * Copyright 1998-2008 VIA Technologies, Inc. All Rights Reserved.
+ * Copyright 2001-2008 S3 Graphics, Inc. All Rights Reserved.
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; 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, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * clock and PLL management functions
+ */
+
+#include <linux/kernel.h>
+#include <linux/via-core.h>
+#include "via_clock.h"
+#include "global.h"
+#include "debug.h"
+
+static inline u32 cle266_encode_pll(struct via_pll_config pll)
+{
+ return (pll.multiplier << 8)
+ | (pll.rshift << 6)
+ | pll.divisor;
+}
+
+static inline u32 k800_encode_pll(struct via_pll_config pll)
+{
+ return ((pll.divisor - 2) << 16)
+ | (pll.rshift << 10)
+ | (pll.multiplier - 2);
+}
+
+static inline u32 vx855_encode_pll(struct via_pll_config pll)
+{
+ return (pll.divisor << 16)
+ | (pll.rshift << 10)
+ | pll.multiplier;
+}
+
+static inline void cle266_set_primary_pll_encoded(u32 data)
+{
+ via_write_reg_mask(VIASR, 0x40, 0x02, 0x02); /* enable reset */
+ via_write_reg(VIASR, 0x46, data & 0xFF);
+ via_write_reg(VIASR, 0x47, (data >> 8) & 0xFF);
+ via_write_reg_mask(VIASR, 0x40, 0x00, 0x02); /* disable reset */
+}
+
+static inline void k800_set_primary_pll_encoded(u32 data)
+{
+ via_write_reg_mask(VIASR, 0x40, 0x02, 0x02); /* enable reset */
+ via_write_reg(VIASR, 0x44, data & 0xFF);
+ via_write_reg(VIASR, 0x45, (data >> 8) & 0xFF);
+ via_write_reg(VIASR, 0x46, (data >> 16) & 0xFF);
+ via_write_reg_mask(VIASR, 0x40, 0x00, 0x02); /* disable reset */
+}
+
+static inline void cle266_set_secondary_pll_encoded(u32 data)
+{
+ via_write_reg_mask(VIASR, 0x40, 0x04, 0x04); /* enable reset */
+ via_write_reg(VIASR, 0x44, data & 0xFF);
+ via_write_reg(VIASR, 0x45, (data >> 8) & 0xFF);
+ via_write_reg_mask(VIASR, 0x40, 0x00, 0x04); /* disable reset */
+}
+
+static inline void k800_set_secondary_pll_encoded(u32 data)
+{
+ via_write_reg_mask(VIASR, 0x40, 0x04, 0x04); /* enable reset */
+ via_write_reg(VIASR, 0x4A, data & 0xFF);
+ via_write_reg(VIASR, 0x4B, (data >> 8) & 0xFF);
+ via_write_reg(VIASR, 0x4C, (data >> 16) & 0xFF);
+ via_write_reg_mask(VIASR, 0x40, 0x00, 0x04); /* disable reset */
+}
+
+static void cle266_set_primary_pll(struct via_pll_config config)
+{
+ cle266_set_primary_pll_encoded(cle266_encode_pll(config));
+}
+
+static void k800_set_primary_pll(struct via_pll_config config)
+{
+ k800_set_primary_pll_encoded(k800_encode_pll(config));
+}
+
+static void vx855_set_primary_pll(struct via_pll_config config)
+{
+ k800_set_primary_pll_encoded(vx855_encode_pll(config));
+}
+
+static void cle266_set_secondary_pll(struct via_pll_config config)
+{
+ cle266_set_secondary_pll_encoded(cle266_encode_pll(config));
+}
+
+static void k800_set_secondary_pll(struct via_pll_config config)
+{
+ k800_set_secondary_pll_encoded(k800_encode_pll(config));
+}
+
+static void vx855_set_secondary_pll(struct via_pll_config config)
+{
+ k800_set_secondary_pll_encoded(vx855_encode_pll(config));
+}
+
+static void set_primary_pll_state(u8 state)
+{
+ u8 value;
+
+ switch (state) {
+ case VIA_STATE_ON:
+ value = 0x20;
+ break;
+ case VIA_STATE_OFF:
+ value = 0x00;
+ break;
+ default:
+ return;
+ }
+
+ via_write_reg_mask(VIASR, 0x2D, value, 0x30);
+}
+
+static void set_secondary_pll_state(u8 state)
+{
+ u8 value;
+
+ switch (state) {
+ case VIA_STATE_ON:
+ value = 0x08;
+ break;
+ case VIA_STATE_OFF:
+ value = 0x00;
+ break;
+ default:
+ return;
+ }
+
+ via_write_reg_mask(VIASR, 0x2D, value, 0x0C);
+}
+
+static void set_primary_clock_state(u8 state)
+{
+ u8 value;
+
+ switch (state) {
+ case VIA_STATE_ON:
+ value = 0x20;
+ break;
+ case VIA_STATE_OFF:
+ value = 0x00;
+ break;
+ default:
+ return;
+ }
+
+ via_write_reg_mask(VIASR, 0x1B, value, 0x30);
+}
+
+static void set_secondary_clock_state(u8 state)
+{
+ u8 value;
+
+ switch (state) {
+ case VIA_STATE_ON:
+ value = 0x80;
+ break;
+ case VIA_STATE_OFF:
+ value = 0x00;
+ break;
+ default:
+ return;
+ }
+
+ via_write_reg_mask(VIASR, 0x1B, value, 0xC0);
+}
+
+static inline u8 set_clock_source_common(enum via_clksrc source, bool use_pll)
+{
+ u8 data = 0;
+
+ switch (source) {
+ case VIA_CLKSRC_X1:
+ data = 0x00;
+ break;
+ case VIA_CLKSRC_TVX1:
+ data = 0x02;
+ break;
+ case VIA_CLKSRC_TVPLL:
+ data = 0x04; /* 0x06 should be the same */
+ break;
+ case VIA_CLKSRC_DVP1TVCLKR:
+ data = 0x0A;
+ break;
+ case VIA_CLKSRC_CAP0:
+ data = 0xC;
+ break;
+ case VIA_CLKSRC_CAP1:
+ data = 0x0E;
+ break;
+ }
+
+ if (!use_pll)
+ data |= 1;
+
+ return data;
+}
+
+static void set_primary_clock_source(enum via_clksrc source, bool use_pll)
+{
+ u8 data = set_clock_source_common(source, use_pll) << 4;
+ via_write_reg_mask(VIACR, 0x6C, data, 0xF0);
+}
+
+static void set_secondary_clock_source(enum via_clksrc source, bool use_pll)
+{
+ u8 data = set_clock_source_common(source, use_pll);
+ via_write_reg_mask(VIACR, 0x6C, data, 0x0F);
+}
+
+void via_clock_init(struct via_clock *clock, int gfx_chip)
+{
+ switch (gfx_chip) {
+ case UNICHROME_CLE266:
+ case UNICHROME_K400:
+ clock->set_primary_clock_state = NULL;
+ clock->set_primary_clock_source = NULL;
+ clock->set_primary_pll_state = NULL;
+ clock->set_primary_pll = cle266_set_primary_pll;
+
+ clock->set_secondary_clock_state = NULL;
+ clock->set_secondary_clock_source = NULL;
+ clock->set_secondary_pll_state = NULL;
+ clock->set_secondary_pll = cle266_set_secondary_pll;
+ break;
+ case UNICHROME_K800:
+ case UNICHROME_PM800:
+ case UNICHROME_CN700:
+ case UNICHROME_CX700:
+ case UNICHROME_CN750:
+ case UNICHROME_K8M890:
+ case UNICHROME_P4M890:
+ case UNICHROME_P4M900:
+ case UNICHROME_VX800:
+ clock->set_primary_clock_state = set_primary_clock_state;
+ clock->set_primary_clock_source = set_primary_clock_source;
+ clock->set_primary_pll_state = set_primary_pll_state;
+ clock->set_primary_pll = k800_set_primary_pll;
+
+ clock->set_secondary_clock_state = set_secondary_clock_state;
+ clock->set_secondary_clock_source = set_secondary_clock_source;
+ clock->set_secondary_pll_state = set_secondary_pll_state;
+ clock->set_secondary_pll = k800_set_secondary_pll;
+ break;
+ case UNICHROME_VX855:
+ case UNICHROME_VX900:
+ clock->set_primary_clock_state = set_primary_clock_state;
+ clock->set_primary_clock_source = set_primary_clock_source;
+ clock->set_primary_pll_state = set_primary_pll_state;
+ clock->set_primary_pll = vx855_set_primary_pll;
+
+ clock->set_secondary_clock_state = set_secondary_clock_state;
+ clock->set_secondary_clock_source = set_secondary_clock_source;
+ clock->set_secondary_pll_state = set_secondary_pll_state;
+ clock->set_secondary_pll = vx855_set_secondary_pll;
+ break;
+
+ }
+}
diff --git a/drivers/video/via/via_clock.h b/drivers/video/via/via_clock.h
new file mode 100644
index 0000000..f213a7a
--- /dev/null
+++ b/drivers/video/via/via_clock.h
@@ -0,0 +1,73 @@
+/*
+ * Copyright 1998-2008 VIA Technologies, Inc. All Rights Reserved.
+ * Copyright 2001-2008 S3 Graphics, Inc. All Rights Reserved.
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; 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, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * clock and PLL management functions
+ */
+
+#ifndef __VIA_CLOCK_H__
+#define __VIA_CLOCK_H__
+
+#include <linux/types.h>
+
+enum via_clksrc {
+ VIA_CLKSRC_X1 = 0,
+ VIA_CLKSRC_TVX1,
+ VIA_CLKSRC_TVPLL,
+ VIA_CLKSRC_DVP1TVCLKR,
+ VIA_CLKSRC_CAP0,
+ VIA_CLKSRC_CAP1,
+};
+
+struct via_pll_config {
+ u16 multiplier;
+ u8 divisor;
+ u8 rshift;
+};
+
+struct via_clock {
+ void (*set_primary_clock_state)(u8 state);
+ void (*set_primary_clock_source)(enum via_clksrc src, bool use_pll);
+ void (*set_primary_pll_state)(u8 state);
+ void (*set_primary_pll)(struct via_pll_config config);
+
+ void (*set_secondary_clock_state)(u8 state);
+ void (*set_secondary_clock_source)(enum via_clksrc src, bool use_pll);
+ void (*set_secondary_pll_state)(u8 state);
+ void (*set_secondary_pll)(struct via_pll_config config);
+};
+
+
+static inline u32 get_pll_internal_frequency(u32 ref_freq,
+ struct via_pll_config pll)
+{
+ return ref_freq / pll.divisor * pll.multiplier;
+}
+
+static inline u32 get_pll_output_frequency(u32 ref_freq,
+ struct via_pll_config pll)
+{
+ return get_pll_internal_frequency(ref_freq, pll) >> pll.rshift;
+}
+
+void via_clock_init(struct via_clock *clock, int gfx_chip);
+
+#endif /* __VIA_CLOCK_H__ */
--
1.6.3.2
^ permalink raw reply related
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: Corbin Simpson @ 2011-03-24 19:06 UTC (permalink / raw)
To: K, Mythri P; +Cc: Jesse Barnes, linux-fbdev, linux-omap, dri-devel, linux-media
In-Reply-To: <AANLkTinYHzCgXe9yw1rGHZA0uM=-VrY+Mktpn-HvfRyR@mail.gmail.com>
On Thu, Mar 24, 2011 at 2:51 AM, K, Mythri P <mythripk@ti.com> wrote:
> Hi Jesse,
>
> On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> 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.
>>
> This sounds good. If we can remove the DRM dependent portion to have a
> library-ized EDID code,
> That would be perfect. The main Intention to have a library is,
> Instead of having several different Implementation in kernel, all
> doing the same EDID parsing , if we could have one single
> implementation , it would help in better testing and interoperability.
>
>> Do you really think the differences between your code and the existing
>> DRM code are irreconcilable?
>>
> On the contrary if there is a library-ized EDID parsing using the
> drm_edid, and there is any delta / fields( Parsing the video block in
> CEA extension for Short Video Descriptor, Vendor block for AV delay
> /Deep color information etc) that are parsed with the RFC i posted i
> would be happy to add.
Something just occurred to me. Why do video input drivers need EDID?
Perhaps I'm betraying my youth here, but none of my TV tuners have the
ability to read EDIDs in from the other side of the coax/RCA jack, and
IIUC they really only care about whether they're receiving NTSC or
PAL. The only drivers that should be parsing EDIDs are FB and KMS
drivers, right?
So why should this be a common library? Most kernel code doesn't need
it. Or is there a serious need for video input to parse EDIDs?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
<MostAwesomeDude@gmail.com>
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: Guennadi Liakhovetski @ 2011-03-24 19:13 UTC (permalink / raw)
To: K, Mythri P
Cc: Jesse Barnes, Dave Airlie, linux-fbdev, linux-omap, dri-devel,
linux-media
In-Reply-To: <AANLkTinYHzCgXe9yw1rGHZA0uM=-VrY+Mktpn-HvfRyR@mail.gmail.com>
On Thu, 24 Mar 2011, K, Mythri P wrote:
> Hi Jesse,
>
> On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > 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.
Does the DRM EDID-parser also process blocks beyond the first one and
also parses SVD entries similar to what I've recently added to fbdev? Yes,
we definitely need a common EDID parses, and maybe we'll have to collect
various pieces from different implementations.
Thanks
Guennadi
> >
> This sounds good. If we can remove the DRM dependent portion to have a
> library-ized EDID code,
> That would be perfect. The main Intention to have a library is,
> Instead of having several different Implementation in kernel, all
> doing the same EDID parsing , if we could have one single
> implementation , it would help in better testing and interoperability.
>
> > Do you really think the differences between your code and the existing
> > DRM code are irreconcilable?
> >
> On the contrary if there is a library-ized EDID parsing using the
> drm_edid, and there is any delta / fields( Parsing the video block in
> CEA extension for Short Video Descriptor, Vendor block for AV delay
> /Deep color information etc) that are parsed with the RFC i posted i
> would be happy to add.
>
> Thanks and regards,
> Mythri.
> > --
> > Jesse Barnes, Intel Open Source Technology Center
> >
> --
> 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
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: Alex Deucher @ 2011-03-24 19:22 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: K, Mythri P, Jesse Barnes, Dave Airlie, linux-fbdev, linux-omap,
dri-devel, linux-media
In-Reply-To: <Pine.LNX.4.64.1103242001460.21914@axis700.grange>
On Thu, Mar 24, 2011 at 3:13 PM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> On Thu, 24 Mar 2011, K, Mythri P wrote:
>
>> Hi Jesse,
>>
>> On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> > 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.
>
> Does the DRM EDID-parser also process blocks beyond the first one and
> also parses SVD entries similar to what I've recently added to fbdev? Yes,
> we definitely need a common EDID parses, and maybe we'll have to collect
> various pieces from different implementations.
At the moment there is only limited support for looking up things like
the hdmi block and checking for audio.
Alex
>
> Thanks
> Guennadi
>
>> >
>> This sounds good. If we can remove the DRM dependent portion to have a
>> library-ized EDID code,
>> That would be perfect. The main Intention to have a library is,
>> Instead of having several different Implementation in kernel, all
>> doing the same EDID parsing , if we could have one single
>> implementation , it would help in better testing and interoperability.
>>
>> > Do you really think the differences between your code and the existing
>> > DRM code are irreconcilable?
>> >
>> On the contrary if there is a library-ized EDID parsing using the
>> drm_edid, and there is any delta / fields( Parsing the video block in
>> CEA extension for Short Video Descriptor, Vendor block for AV delay
>> /Deep color information etc) that are parsed with the RFC i posted i
>> would be happy to add.
>>
>> Thanks and regards,
>> Mythri.
>> > --
>> > Jesse Barnes, Intel Open Source Technology Center
>> >
>> --
>> 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
>>
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> 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: [PATCH 3/3] viafb: add VIA slapping capability
From: Xavier Bachelot @ 2011-03-24 19:47 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <1300983180-7343-4-git-send-email-FlorianSchandinat@gmx.de>
On 03/24/2011 05:13 PM, Florian Tobias Schandinat wrote:
> This patch introduces dummy functions to execute when we don't know
> what we should do (due to missing documentation). They do nothing
> but print a nice message in the log explaining the situation.
> To trigger this message initial power management support is
> activated which might save a bit energy by disabling PLL and clock
> if no device is configured to use them.
>
> Note: The message is only shown for the oldest IGPs CLE266 and K400
> as for the other platforms there are reasonable assumptions
> how it does (hopefully) work.
>
> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> ---
> +static void dummy_set_clock_source(enum via_clksrc source, bool use_pll)
> +{
> + printk(KERN_INFO "Using undocumented set slock soure.\n%s", via_slap);
2 typos above.
Regards,
Xavier
^ permalink raw reply
* [PATCH] fbcon: Remove unused 'display *p' variable from
From: Sergey Senozhatsky @ 2011-03-24 20:50 UTC (permalink / raw)
To: Paul Mundt
Cc: Andrew Morton, Dave Airlie, Jesse Barnes, linux-fbdev,
linux-kernel
fbcon: Remove unused 'display *p' variable from fb_flashcursor()
Signed-of-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
drivers/video/console/fbcon.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index c583934..8745637 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -370,7 +370,6 @@ static void fb_flashcursor(struct work_struct *work)
{
struct fb_info *info = container_of(work, struct fb_info, queue);
struct fbcon_ops *ops = info->fbcon_par;
- struct display *p;
struct vc_data *vc = NULL;
int c;
int mode;
@@ -386,7 +385,6 @@ static void fb_flashcursor(struct work_struct *work)
return;
}
- p = &fb_display[vc->vc_num];
c = scr_readw((u16 *) vc->vc_pos);
mode = (!ops->cursor_flash || ops->cursor_state.enable) ?
CM_ERASE : CM_DRAW;
^ permalink raw reply related
* Re: [PATCH 3/3] viafb: add VIA slapping capability
From: Florian Tobias Schandinat @ 2011-03-24 21:11 UTC (permalink / raw)
To: Xavier Bachelot; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <4D8B9FBE.6030207@bachelot.org>
Xavier Bachelot schrieb:
> On 03/24/2011 05:13 PM, Florian Tobias Schandinat wrote:
>> This patch introduces dummy functions to execute when we don't know
>> what we should do (due to missing documentation). They do nothing
>> but print a nice message in the log explaining the situation.
>> To trigger this message initial power management support is
>> activated which might save a bit energy by disabling PLL and clock
>> if no device is configured to use them.
>>
>> Note: The message is only shown for the oldest IGPs CLE266 and K400
>> as for the other platforms there are reasonable assumptions
>> how it does (hopefully) work.
>>
>> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
>> ---
>
>> +static void dummy_set_clock_source(enum via_clksrc source, bool use_pll)
>> +{
>> + printk(KERN_INFO "Using undocumented set slock soure.\n%s", via_slap);
>
> 2 typos above.
Indeed. Thanks for pointing it out, fixed.
> Regards,
> Xavier
Regards,
Florian Tobias Schandinat
^ permalink raw reply
* [PATCH v2] viafb: add VIA slapping capability
From: Florian Tobias Schandinat @ 2011-03-24 21:32 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <4D8B9FBE.6030207@bachelot.org>
This patch introduces dummy functions to execute when we don't know
what we should do (due to missing documentation). They do nothing
but print a nice message in the log explaining the situation.
To trigger this message initial power management support is
activated which might save a bit energy by disabling PLL and clock
if no device is configured to use them.
Note: The message is only shown for the oldest IGPs CLE266 and K400
as for the other platforms there are reasonable assumptions
how it does (hopefully) work.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
v2: fixed 2 annoying typos
---
drivers/video/via/hw.c | 19 +++++++++++++++++++
drivers/video/via/via_clock.c | 30 ++++++++++++++++++++++++------
2 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index f1eff0b..df84251 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -2289,6 +2289,25 @@ int viafb_setmode(struct VideoModeTable *vmode_tbl, int video_bpp,
get_sync(viafbinfo1));
}
+ clock.set_primary_clock_source(VIA_CLKSRC_X1, true);
+ clock.set_secondary_clock_source(VIA_CLKSRC_X1, true);
+
+ if (viaparinfo->shared->iga1_devices) {
+ clock.set_primary_pll_state(VIA_STATE_ON);
+ clock.set_primary_clock_state(VIA_STATE_ON);
+ } else {
+ clock.set_primary_pll_state(VIA_STATE_OFF);
+ clock.set_primary_clock_state(VIA_STATE_OFF);
+ }
+
+ if (viaparinfo->shared->iga2_devices) {
+ clock.set_secondary_pll_state(VIA_STATE_ON);
+ clock.set_secondary_clock_state(VIA_STATE_ON);
+ } else {
+ clock.set_secondary_pll_state(VIA_STATE_OFF);
+ clock.set_secondary_clock_state(VIA_STATE_OFF);
+ }
+
via_set_state(devices, VIA_STATE_ON);
device_screen_on();
return 1;
diff --git a/drivers/video/via/via_clock.c b/drivers/video/via/via_clock.c
index 29afe4c..a829a24 100644
--- a/drivers/video/via/via_clock.c
+++ b/drivers/video/via/via_clock.c
@@ -29,6 +29,9 @@
#include "global.h"
#include "debug.h"
+const char *via_slap = "Please slap VIA Technologies to motivate them "
+ "releasing full documentation for your platform!\n";
+
static inline u32 cle266_encode_pll(struct via_pll_config pll)
{
return (pll.multiplier << 8)
@@ -229,19 +232,34 @@ static void set_secondary_clock_source(enum via_clksrc source, bool use_pll)
via_write_reg_mask(VIACR, 0x6C, data, 0x0F);
}
+static void dummy_set_clock_state(u8 state)
+{
+ printk(KERN_INFO "Using undocumented set clock state.\n%s", via_slap);
+}
+
+static void dummy_set_clock_source(enum via_clksrc source, bool use_pll)
+{
+ printk(KERN_INFO "Using undocumented set clock source.\n%s", via_slap);
+}
+
+static void dummy_set_pll_state(u8 state)
+{
+ printk(KERN_INFO "Using undocumented set PLL state.\n%s", via_slap);
+}
+
void via_clock_init(struct via_clock *clock, int gfx_chip)
{
switch (gfx_chip) {
case UNICHROME_CLE266:
case UNICHROME_K400:
- clock->set_primary_clock_state = NULL;
- clock->set_primary_clock_source = NULL;
- clock->set_primary_pll_state = NULL;
+ clock->set_primary_clock_state = dummy_set_clock_state;
+ clock->set_primary_clock_source = dummy_set_clock_source;
+ clock->set_primary_pll_state = dummy_set_pll_state;
clock->set_primary_pll = cle266_set_primary_pll;
- clock->set_secondary_clock_state = NULL;
- clock->set_secondary_clock_source = NULL;
- clock->set_secondary_pll_state = NULL;
+ clock->set_secondary_clock_state = dummy_set_clock_state;
+ clock->set_secondary_clock_source = dummy_set_clock_source;
+ clock->set_secondary_pll_state = dummy_set_pll_state;
clock->set_secondary_pll = cle266_set_secondary_pll;
break;
case UNICHROME_K800:
--
1.6.3.2
^ permalink raw reply related
* Re: [trivial PATCH 1/2] treewide: Fix iomap resource size
From: Ralf Baechle @ 2011-03-24 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4422b4a8ee132d3adac95fd86237c61b2f8b364.1300909446.git.joe@perches.com>
On Wed, Mar 23, 2011 at 12:55:36PM -0700, Joe Perches wrote:
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: Florian Tobias Schandinat @ 2011-03-24 22:43 UTC (permalink / raw)
To: Corbin Simpson
Cc: K, Mythri P, Jesse Barnes, linux-fbdev, linux-omap, dri-devel,
linux-media
In-Reply-To: <AANLkTi=Yc0Pg9uCZcTei45PLbERutoRc7XyoFghwS=KV@mail.gmail.com>
Corbin Simpson schrieb:
> On Thu, Mar 24, 2011 at 2:51 AM, K, Mythri P <mythripk@ti.com> wrote:
>> Hi Jesse,
>>
>> On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>>> 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.
>>>
>> This sounds good. If we can remove the DRM dependent portion to have a
>> library-ized EDID code,
>> That would be perfect. The main Intention to have a library is,
>> Instead of having several different Implementation in kernel, all
>> doing the same EDID parsing , if we could have one single
>> implementation , it would help in better testing and interoperability.
>>
>>> Do you really think the differences between your code and the existing
>>> DRM code are irreconcilable?
>>>
>> On the contrary if there is a library-ized EDID parsing using the
>> drm_edid, and there is any delta / fields( Parsing the video block in
>> CEA extension for Short Video Descriptor, Vendor block for AV delay
>> /Deep color information etc) that are parsed with the RFC i posted i
>> would be happy to add.
>
> Something just occurred to me. Why do video input drivers need EDID?
> Perhaps I'm betraying my youth here, but none of my TV tuners have the
> ability to read EDIDs in from the other side of the coax/RCA jack, and
> IIUC they really only care about whether they're receiving NTSC or
> PAL. The only drivers that should be parsing EDIDs are FB and KMS
> drivers, right?
Traditional TV (PAL/NTSC) supports only a very limited amount of modes and
furthermore within one country it's about 1 or 2 different ones that are
typically needed. It looks like todays TVs support most of those but I've also
seen some terrible cropping or a wrong aspect ratio on TVs. Let's say that had a
relative simple job and they didn't do it always too well, so getting the
information via EDID is better than forcing the user type the info in via a
remote or doing it wrong.
> So why should this be a common library? Most kernel code doesn't need
> it. Or is there a serious need for video input to parse EDIDs?
It's true that most kernel code does not need it as it is only useful for
display output systems (and only the ones that can be connected to something
sending EDID data) but it would be good anyway.
Because sharing code that should fulfill the same purpose is always a good idea.
But of course only if the scope is clearly limited as we don't want to end up
with a mess that nobody dares touching again as it became to complex. So I
totally agree that we should share the common stuff we all need and adding the
extras one needs in the subsystem/driver.
This is good because it looks like we'll have 3 display subsystems within the
kernel for a long future and with a common library the same patch would not need
to be done 3 times but only once. Or even more often if drivers have there
private EDID implementation which I just throw out of mine to replace it later
with a common one.
Regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH 0/2] Fix resource size miscalculations
From: Joe Perches @ 2011-03-24 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1300909445.git.joe@perches.com>
On Wed, 2011-03-23 at 12:55 -0700, Joe Perches wrote:
> Use resource_size a few places
Perhaps this relatively common error is too common.
It seems to be poor style. A possible better style for
struct resource uses could be inline function(s) like:
static inline void __iomem *resource_ioremap(struct resource *r)
{
return ioremap(r->start, resource_size(r));
}
and maybe
static inline struct resource *
resource_request_region(struct resource *r, const char *name)
{
return __request_region(&ioport_resource, r->start, resource_size(r), name, 0);
}
^ permalink raw reply
* Re: [GIT PULL] viafb fixes for 2.6.39
From: Paul Mundt @ 2011-03-24 22:53 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.
>
Pulled, thanks.
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: K, Mythri P @ 2011-03-25 13:46 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Jesse Barnes, Dave Airlie, linux-fbdev, linux-omap, dri-devel,
linux-media
In-Reply-To: <Pine.LNX.4.64.1103242001460.21914@axis700.grange>
Hi Gunnedi,
<snip>
>> > 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.
>
> Does the DRM EDID-parser also process blocks beyond the first one and
> also parses SVD entries similar to what I've recently added to fbdev? Yes,
> we definitely need a common EDID parses, and maybe we'll have to collect
> various pieces from different implementations.
>
As far as I know , it does not parse SVD ,But it should not be that
difficult to add.
We could take the SVD parsing from your code . In the RFC i have
posted I parse for detailed timing and other VSDB blocks.
Also the parsing should be based on the extension type for multiple
128 byte blocks.
Thanks and regards,
Mythri.
> Thanks
> Guennadi
>
^ permalink raw reply
* Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
From: K, Mythri P @ 2011-03-25 15:33 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Corbin Simpson, Jesse Barnes, linux-fbdev, linux-omap, dri-devel,
linux-media
In-Reply-To: <4D8BC915.60400@gmx.de>
Hi Florian,
<snip>
>
>> So why should this be a common library? Most kernel code doesn't need
>> it. Or is there a serious need for video input to parse EDIDs?
>
> It's true that most kernel code does not need it as it is only useful for
> display output systems (and only the ones that can be connected to something
> sending EDID data) but it would be good anyway.
> Because sharing code that should fulfill the same purpose is always a good
> idea. But of course only if the scope is clearly limited as we don't want to
> end up with a mess that nobody dares touching again as it became to complex.
> So I totally agree that we should share the common stuff we all need and
> adding the extras one needs in the subsystem/driver.
> This is good because it looks like we'll have 3 display subsystems within
> the kernel for a long future and with a common library the same patch would
> not need to be done 3 times but only once. Or even more often if drivers
> have there private EDID implementation which I just throw out of mine to
> replace it later with a common one.
>
Precisely my point . Also if there are some bad TV models which
doesn't adhere to standard EDID, It would help to add quirks.
Anyone out there want to help me split the DRM code ? As i don't want
DRMer's to fret over changed code :).
Thanks and regards,
Mythri.
> Regards,
>
> Florian Tobias Schandinat
>
^ permalink raw reply
* vt & fbcon changes
From: Bruno Prémont @ 2011-03-28 14:38 UTC (permalink / raw)
To: linux-fbdev
Hi James,
How is your refactoring of vt (and fbcon) progressing?
Last commit visible in your GIT tree [1] dates back to last November...
I'm looking at resuming my ref-counted framebuffer work though would
like to avoid duplicate work with your vt changes (and/or big merging
conflicts).
From first glance registered_fb[] is the biggest source of conflict,
in your patches you are dropping (most) of its use as you kill con2fb_map[]
in fbcon.c -- on my side I am planning to convert con2fb_map from char
to struct fb_info*
Thanks,
Bruno
[1] http://git.infradead.org/users/jsimmons/linuxconsole-2.6.git
^ permalink raw reply
* Re: [PATCH] fbcon: Remove unused 'display *p' variable from
From: Jesse Barnes @ 2011-03-28 16:18 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Paul Mundt, Andrew Morton, Dave Airlie, linux-fbdev, linux-kernel
In-Reply-To: <20110324205052.GA4238@swordfish>
On Thu, 24 Mar 2011 22:50:52 +0200
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
> fbcon: Remove unused 'display *p' variable from fb_flashcursor()
>
> Signed-of-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>
> ---
>
> drivers/video/console/fbcon.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index c583934..8745637 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -370,7 +370,6 @@ static void fb_flashcursor(struct work_struct *work)
> {
> struct fb_info *info = container_of(work, struct fb_info, queue);
> struct fbcon_ops *ops = info->fbcon_par;
> - struct display *p;
> struct vc_data *vc = NULL;
> int c;
> int mode;
> @@ -386,7 +385,6 @@ static void fb_flashcursor(struct work_struct *work)
> return;
> }
>
> - p = &fb_display[vc->vc_num];
> c = scr_readw((u16 *) vc->vc_pos);
> mode = (!ops->cursor_flash || ops->cursor_state.enable) ?
> CM_ERASE : CM_DRAW;
Looks fine to me, is Paul the lucky owner of fbdev now?
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [GIT PULL] omap display subsystem changes for 2.6.39
From: Tony Lindgren @ 2011-03-28 21:07 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Felipe Contreras, Paul Mundt, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org
In-Reply-To: <1300866362.2613.5.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [110323 00:43]:
> 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>
Seems OK for -rc cycle.
Tony
^ permalink raw reply
* [patch] backlight/ld9040.c: testing the wrong variable in
From: Dan Carpenter @ 2011-03-29 3:19 UTC (permalink / raw)
To: linux-fbdev
We should be testing "bd" here instead of "ld". It's a copy and
paste bug.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/video/backlight/ld9040.c b/drivers/video/backlight/ld9040.c
index 7281b25..9e81d69 100644
--- a/drivers/video/backlight/ld9040.c
+++ b/drivers/video/backlight/ld9040.c
@@ -701,8 +701,8 @@ static int ld9040_probe(struct spi_device *spi)
bd = backlight_device_register("ld9040-bl", &spi->dev,
lcd, &ld9040_backlight_ops, NULL);
- if (IS_ERR(ld)) {
- ret = PTR_ERR(ld);
+ if (IS_ERR(bd)) {
+ ret = PTR_ERR(bd);
goto out_free_lcd;
}
^ permalink raw reply related
* [patch] backlight/pcf50633: check for NULL consistently in
From: Dan Carpenter @ 2011-03-29 3:20 UTC (permalink / raw)
To: linux-fbdev
We checked "pdata" for NULL at the start of the function so we should
check it here as well.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
Compile tested only. Please review.
diff --git a/drivers/video/backlight/pcf50633-backlight.c b/drivers/video/backlight/pcf50633-backlight.c
index ef5628d..0fe934f 100644
--- a/drivers/video/backlight/pcf50633-backlight.c
+++ b/drivers/video/backlight/pcf50633-backlight.c
@@ -136,7 +136,9 @@ static int __devinit pcf50633_bl_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, pcf_bl);
- pcf50633_reg_write(pcf_bl->pcf, PCF50633_REG_LEDDIM, pdata->ramp_time);
+ if (pdata)
+ pcf50633_reg_write(pcf_bl->pcf, PCF50633_REG_LEDDIM,
+ pdata->ramp_time);
/* Should be different from bl_props.brightness, so we do not exit
* update_status early the first time it's called */
^ permalink raw reply related
* Re: [PATCH] fbcon: Remove unused 'display *p' variable from fb_flashcursor()
From: Paul Mundt @ 2011-03-29 3:32 UTC (permalink / raw)
To: Jesse Barnes
Cc: Sergey Senozhatsky, Andrew Morton, Dave Airlie, linux-fbdev,
linux-kernel
In-Reply-To: <20110328091846.485dfef0@jbarnes-desktop>
On Mon, Mar 28, 2011 at 09:18:46AM -0700, Jesse Barnes wrote:
> On Thu, 24 Mar 2011 22:50:52 +0200
> Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
>
> > fbcon: Remove unused 'display *p' variable from fb_flashcursor()
> >
> > Signed-of-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> >
>
> Looks fine to me, is Paul the lucky owner of fbdev now?
>
Seems so. I'll roll the patch in with the next batch of fixes.
^ 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