* 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: [trivial PATCH 1/2] treewide: Fix iomap resource size
From: Wim Van Sebroeck @ 2011-03-24 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4422b4a8ee132d3adac95fd86237c61b2f8b364.1300909446.git.joe@perches.com>
Hi Joe,
> 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(-)
Acked-by: Wim Van Sebroeck <wim@iguana.be>
Kind regards,
Wim.
^ permalink raw reply
* Re: [PATCH 09/20] video: msm: Split out MDP2.2 HW specific code.
From: David Brown @ 2011-03-23 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D8A5B44.9050306@codeaurora.org>
On Wed, Mar 23 2011, Carl Vanderlip wrote:
> On 03/23/2011 06:11 AM, Daniel Walker wrote:
>> 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
>>
> What about removing the 'depends on' and 'default y' and making it be
> selected by MSM7X00A?
But why should the feature be in the Kconfig for arch/arm/mach-msm when
the driver is under drivers/video/msm? If it does indeed need
configuration, why not put a Kconfig under drivers/video/msm?
The last patch does select this, so it shouldn't need to get a default.
Does the code work if both MDP22 and MDP31 are defined? Eventually, it
will be possible to enable multiple SOCs, so this driver will need to be
able to handle that determination at run-time.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [trivial PATCH 1/2] treewide: Fix iomap resource size miscalculations
From: David Brown @ 2011-03-23 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4422b4a8ee132d3adac95fd86237c61b2f8b364.1300909446.git.joe@perches.com>
On Wed, Mar 23 2011, Joe Perches wrote:
> Convert off-by-1 r->end - r->start to resource_size(r)
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/video/msm/mddi.c | 2 +-
Acked-by: David Brown <davidb@codeaurora.org>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 4/4] viafb: add clock source selection and PLL power management support
From: Florian Tobias Schandinat @ 2011-03-23 22:35 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300919734-3931-1-git-send-email-FlorianSchandinat@gmx.de>
This patch adds some support for clock source selection as well as
PLL power management. The code is unused at the moment but was
successfully tested as far as possible.
The implementation is according to the documentation for VX700,
VX800, VX855, VX900. Probably the source selection works like this
starting with K800 and the power managemennt at least since VX700.
(guessed based on the initialization in viamode.c)
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 88 insertions(+), 0 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index bd28e13..b38d3b4 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_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, 0x08);
+}
+
static u32 cle266_encode_pll(struct pll_config pll)
{
return (pll.multiplier << 8)
@@ -1494,6 +1530,58 @@ 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)
{
--
1.6.3.2
^ permalink raw reply related
* [PATCH 3/4] viafb: prepare for PLL separation
From: Florian Tobias Schandinat @ 2011-03-23 22:35 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300919734-3931-1-git-send-email-FlorianSchandinat@gmx.de>
This patch splits some functionality to extra functions.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 127 +++++++++++++++++++++++++++++++----------------
1 files changed, 84 insertions(+), 43 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index c28ae2e..bd28e13 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1430,6 +1430,70 @@ static u32 vx855_encode_pll(struct pll_config pll)
| 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));
+}
+
static inline u32 get_pll_internal_frequency(u32 ref_freq,
struct pll_config pll)
{
@@ -1474,21 +1538,21 @@ static struct pll_config get_pll_config(struct pll_limit *limits, int size,
return best;
}
-static u32 viafb_get_clk_value(int clk)
+static struct pll_config get_best_pll_config(int clk)
{
- u32 value = 0;
+ struct pll_config config;
switch (viaparinfo->chip_info->gfx_chip_name) {
case UNICHROME_CLE266:
case UNICHROME_K400:
- value = cle266_encode_pll(get_pll_config(cle266_pll_limits,
- ARRAY_SIZE(cle266_pll_limits), clk));
+ config = get_pll_config(cle266_pll_limits,
+ ARRAY_SIZE(cle266_pll_limits), clk);
break;
case UNICHROME_K800:
case UNICHROME_PM800:
case UNICHROME_CN700:
- value = k800_encode_pll(get_pll_config(k800_pll_limits,
- ARRAY_SIZE(k800_pll_limits), clk));
+ config = get_pll_config(k800_pll_limits,
+ ARRAY_SIZE(k800_pll_limits), clk);
break;
case UNICHROME_CX700:
case UNICHROME_CN750:
@@ -1496,38 +1560,31 @@ static u32 viafb_get_clk_value(int clk)
case UNICHROME_P4M890:
case UNICHROME_P4M900:
case UNICHROME_VX800:
- value = k800_encode_pll(get_pll_config(cx700_pll_limits,
- ARRAY_SIZE(cx700_pll_limits), clk));
+ config = get_pll_config(cx700_pll_limits,
+ ARRAY_SIZE(cx700_pll_limits), clk);
break;
case UNICHROME_VX855:
case UNICHROME_VX900:
- value = vx855_encode_pll(get_pll_config(vx855_pll_limits,
- ARRAY_SIZE(vx855_pll_limits), clk));
+ config = get_pll_config(vx855_pll_limits,
+ ARRAY_SIZE(vx855_pll_limits), clk);
break;
}
- return value;
+ return config;
}
/* Set VCLK*/
void viafb_set_vclock(u32 clk, int set_iga)
{
- u32 value = viafb_get_clk_value(clk);
-
- DEBUG_MSG(KERN_INFO "PLL=0x%x", value);
-
- /* H.W. Reset : ON */
- viafb_write_reg_mask(CR17, VIACR, 0x00, BIT7);
+ struct 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:
- via_write_reg(VIASR, SR46, (value & 0x00FF));
- via_write_reg(VIASR, SR47, (value & 0xFF00) >> 8);
+ cle266_set_primary_pll(config);
break;
-
case UNICHROME_K800:
case UNICHROME_PM800:
case UNICHROME_CN700:
@@ -1537,11 +1594,11 @@ void viafb_set_vclock(u32 clk, int set_iga)
case UNICHROME_P4M890:
case UNICHROME_P4M900:
case UNICHROME_VX800:
+ k800_set_primary_pll(config);
+ break;
case UNICHROME_VX855:
case UNICHROME_VX900:
- via_write_reg(VIASR, SR44, (value & 0x0000FF));
- via_write_reg(VIASR, SR45, (value & 0x00FF00) >> 8);
- via_write_reg(VIASR, SR46, (value & 0xFF0000) >> 16);
+ vx855_set_primary_pll(config);
break;
}
}
@@ -1551,10 +1608,8 @@ void viafb_set_vclock(u32 clk, int set_iga)
switch (viaparinfo->chip_info->gfx_chip_name) {
case UNICHROME_CLE266:
case UNICHROME_K400:
- via_write_reg(VIASR, SR44, (value & 0x00FF));
- via_write_reg(VIASR, SR45, (value & 0xFF00) >> 8);
+ cle266_set_secondary_pll(config);
break;
-
case UNICHROME_K800:
case UNICHROME_PM800:
case UNICHROME_CN700:
@@ -1564,29 +1619,15 @@ void viafb_set_vclock(u32 clk, int set_iga)
case UNICHROME_P4M890:
case UNICHROME_P4M900:
case UNICHROME_VX800:
+ k800_set_secondary_pll(config);
+ break;
case UNICHROME_VX855:
case UNICHROME_VX900:
- via_write_reg(VIASR, SR4A, (value & 0x0000FF));
- via_write_reg(VIASR, SR4B, (value & 0x00FF00) >> 8);
- via_write_reg(VIASR, SR4C, (value & 0xFF0000) >> 16);
+ vx855_set_secondary_pll(config);
break;
}
}
- /* H.W. Reset : OFF */
- viafb_write_reg_mask(CR17, VIACR, 0x80, BIT7);
-
- /* Reset PLL */
- if (set_iga = IGA1) {
- viafb_write_reg_mask(SR40, VIASR, 0x02, BIT1);
- viafb_write_reg_mask(SR40, VIASR, 0x00, BIT1);
- }
-
- if (set_iga = IGA2) {
- viafb_write_reg_mask(SR40, VIASR, 0x04, BIT2);
- viafb_write_reg_mask(SR40, VIASR, 0x00, BIT2);
- }
-
/* Fire! */
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
--
1.6.3.2
^ permalink raw reply related
* [PATCH 2/4] viafb: call viafb_get_clk_value only in viafb_set_vclock
From: Florian Tobias Schandinat @ 2011-03-23 22:35 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300919734-3931-1-git-send-email-FlorianSchandinat@gmx.de>
As no caller is interested in the result call viafb_get_clk_value
directly from viafb_set_vclock to encapsulate the hardware dependend
stuff there.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 32 +++++++++++++++++---------------
drivers/video/via/hw.h | 1 -
drivers/video/via/lcd.c | 7 ++-----
3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 063ff65..c28ae2e 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1474,7 +1474,7 @@ static struct pll_config get_pll_config(struct pll_limit *limits, int size,
return best;
}
-u32 viafb_get_clk_value(int clk)
+static u32 viafb_get_clk_value(int clk)
{
u32 value = 0;
@@ -1512,6 +1512,10 @@ u32 viafb_get_clk_value(int clk)
/* Set VCLK*/
void viafb_set_vclock(u32 clk, int set_iga)
{
+ u32 value = viafb_get_clk_value(clk);
+
+ DEBUG_MSG(KERN_INFO "PLL=0x%x", value);
+
/* H.W. Reset : ON */
viafb_write_reg_mask(CR17, VIACR, 0x00, BIT7);
@@ -1520,8 +1524,8 @@ void viafb_set_vclock(u32 clk, int set_iga)
switch (viaparinfo->chip_info->gfx_chip_name) {
case UNICHROME_CLE266:
case UNICHROME_K400:
- via_write_reg(VIASR, SR46, (clk & 0x00FF));
- via_write_reg(VIASR, SR47, (clk & 0xFF00) >> 8);
+ via_write_reg(VIASR, SR46, (value & 0x00FF));
+ via_write_reg(VIASR, SR47, (value & 0xFF00) >> 8);
break;
case UNICHROME_K800:
@@ -1535,9 +1539,9 @@ void viafb_set_vclock(u32 clk, int set_iga)
case UNICHROME_VX800:
case UNICHROME_VX855:
case UNICHROME_VX900:
- via_write_reg(VIASR, SR44, (clk & 0x0000FF));
- via_write_reg(VIASR, SR45, (clk & 0x00FF00) >> 8);
- via_write_reg(VIASR, SR46, (clk & 0xFF0000) >> 16);
+ via_write_reg(VIASR, SR44, (value & 0x0000FF));
+ via_write_reg(VIASR, SR45, (value & 0x00FF00) >> 8);
+ via_write_reg(VIASR, SR46, (value & 0xFF0000) >> 16);
break;
}
}
@@ -1547,8 +1551,8 @@ void viafb_set_vclock(u32 clk, int set_iga)
switch (viaparinfo->chip_info->gfx_chip_name) {
case UNICHROME_CLE266:
case UNICHROME_K400:
- via_write_reg(VIASR, SR44, (clk & 0x00FF));
- via_write_reg(VIASR, SR45, (clk & 0xFF00) >> 8);
+ via_write_reg(VIASR, SR44, (value & 0x00FF));
+ via_write_reg(VIASR, SR45, (value & 0xFF00) >> 8);
break;
case UNICHROME_K800:
@@ -1562,9 +1566,9 @@ void viafb_set_vclock(u32 clk, int set_iga)
case UNICHROME_VX800:
case UNICHROME_VX855:
case UNICHROME_VX900:
- via_write_reg(VIASR, SR4A, (clk & 0x0000FF));
- via_write_reg(VIASR, SR4B, (clk & 0x00FF00) >> 8);
- via_write_reg(VIASR, SR4C, (clk & 0xFF0000) >> 16);
+ via_write_reg(VIASR, SR4A, (value & 0x0000FF));
+ via_write_reg(VIASR, SR4B, (value & 0x00FF00) >> 8);
+ via_write_reg(VIASR, SR4C, (value & 0xFF0000) >> 16);
break;
}
}
@@ -1827,7 +1831,7 @@ void viafb_fill_crtc_timing(struct crt_mode_table *crt_table,
int i;
int index = 0;
int h_addr, v_addr;
- u32 pll_D_N, clock, refresh = viafb_refresh;
+ u32 clock, refresh = viafb_refresh;
if (viafb_SAMM_ON && set_iga = IGA2)
refresh = viafb_refresh1;
@@ -1884,9 +1888,7 @@ void viafb_fill_crtc_timing(struct crt_mode_table *crt_table,
clock = crt_reg.hor_total * crt_reg.ver_total
* crt_table[index].refresh_rate;
- pll_D_N = viafb_get_clk_value(clock);
- DEBUG_MSG(KERN_INFO "PLL=%x", pll_D_N);
- viafb_set_vclock(pll_D_N, set_iga);
+ viafb_set_vclock(clock, set_iga);
}
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 63d8d37..2cdce9b 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -935,7 +935,6 @@ void viafb_lock_crt(void);
void viafb_unlock_crt(void);
void viafb_load_fetch_count_reg(int h_addr, int bpp_byte, int set_iga);
void viafb_write_regx(struct io_reg RegTable[], int ItemNum);
-u32 viafb_get_clk_value(int clk);
void viafb_load_FIFO_reg(int set_iga, int hor_active, int ver_active);
void viafb_set_dpa_gfx(int output_interface, struct GFX_DPA_SETTING\
*p_gfx_dpa_setting);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 64bc7e7..284e681 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -562,7 +562,7 @@ void viafb_lcd_set_mode(struct crt_mode_table *mode_crt_table,
int set_vres = plvds_setting_info->v_active;
int panel_hres = plvds_setting_info->lcd_panel_hres;
int panel_vres = plvds_setting_info->lcd_panel_vres;
- u32 pll_D_N, clock;
+ u32 clock;
struct display_timing mode_crt_reg, panel_crt_reg;
struct crt_mode_table *panel_crt_table = NULL;
struct VideoModeTable *vmode_tbl = viafb_get_mode(panel_hres,
@@ -613,10 +613,7 @@ void viafb_lcd_set_mode(struct crt_mode_table *mode_crt_table,
viafb_load_FIFO_reg(set_iga, set_hres, set_vres);
fill_lcd_format();
-
- pll_D_N = viafb_get_clk_value(clock);
- DEBUG_MSG(KERN_INFO "PLL=0x%x", pll_D_N);
- viafb_set_vclock(pll_D_N, set_iga);
+ viafb_set_vclock(clock, set_iga);
lcd_patch_skew(plvds_setting_info, plvds_chip_info);
/* If K8M800, enable LCD Prefetch Mode. */
--
1.6.3.2
^ permalink raw reply related
* [PATCH 1/4] viafb: allow some pll calculations
From: Florian Tobias Schandinat @ 2011-03-23 22:35 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300919734-3931-1-git-send-email-FlorianSchandinat@gmx.de>
This patch allows calculating the pll multiplier within limits based
on the previous table. All available information supports that it
should be possible/sane to choose the multiplier free within some
ranges.
Storing the multiplier ranges instead of lots of pll configurations
reduces the memory needed and may as well improve the performance.
It is also expected to provide better pll values resulting in better
frequencies for the connected devices.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 377 +++++++++++++-----------------------------------
drivers/video/via/hw.h | 11 +-
2 files changed, 106 insertions(+), 282 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index dc4c778..063ff65 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -22,272 +22,80 @@
#include <linux/via-core.h>
#include "global.h"
-static struct pll_config cle266_pll_config[] = {
- {19, 4, 0},
- {26, 5, 0},
- {28, 5, 0},
- {31, 5, 0},
- {33, 5, 0},
- {55, 5, 0},
- {102, 5, 0},
- {53, 6, 0},
- {92, 6, 0},
- {98, 6, 0},
- {112, 6, 0},
- {41, 7, 0},
- {60, 7, 0},
- {99, 7, 0},
- {100, 7, 0},
- {83, 8, 0},
- {86, 8, 0},
- {108, 8, 0},
- {87, 9, 0},
- {118, 9, 0},
- {95, 12, 0},
- {115, 12, 0},
- {108, 13, 0},
- {83, 17, 0},
- {67, 20, 0},
- {86, 20, 0},
- {98, 20, 0},
- {121, 24, 0},
- {99, 29, 0},
- {33, 3, 1},
- {15, 4, 1},
- {23, 4, 1},
- {37, 5, 1},
- {83, 5, 1},
- {85, 5, 1},
- {94, 5, 1},
- {103, 5, 1},
- {109, 5, 1},
- {113, 5, 1},
- {121, 5, 1},
- {82, 6, 1},
- {31, 7, 1},
- {55, 7, 1},
- {84, 7, 1},
- {83, 8, 1},
- {76, 9, 1},
- {127, 9, 1},
- {33, 4, 2},
- {75, 4, 2},
- {119, 4, 2},
- {121, 4, 2},
- {91, 5, 2},
- {118, 5, 2},
- {83, 6, 2},
- {109, 6, 2},
- {90, 7, 2},
- {93, 2, 3},
- {53, 3, 3},
- {73, 4, 3},
- {89, 4, 3},
- {105, 4, 3},
- {117, 4, 3},
- {101, 5, 3},
- {121, 5, 3},
- {127, 5, 3},
- {99, 7, 3}
+static struct pll_limit cle266_pll_limits[] = {
+ {19, 19, 4, 0},
+ {26, 102, 5, 0},
+ {53, 112, 6, 0},
+ {41, 100, 7, 0},
+ {83, 108, 8, 0},
+ {87, 118, 9, 0},
+ {95, 115, 12, 0},
+ {108, 108, 13, 0},
+ {83, 83, 17, 0},
+ {67, 98, 20, 0},
+ {121, 121, 24, 0},
+ {99, 99, 29, 0},
+ {33, 33, 3, 1},
+ {15, 23, 4, 1},
+ {37, 121, 5, 1},
+ {82, 82, 6, 1},
+ {31, 84, 7, 1},
+ {83, 83, 8, 1},
+ {76, 127, 9, 1},
+ {33, 121, 4, 2},
+ {91, 118, 5, 2},
+ {83, 109, 6, 2},
+ {90, 90, 7, 2},
+ {93, 93, 2, 3},
+ {53, 53, 3, 3},
+ {73, 117, 4, 3},
+ {101, 127, 5, 3},
+ {99, 99, 7, 3}
};
-static struct pll_config k800_pll_config[] = {
- {22, 2, 0},
- {28, 3, 0},
- {81, 3, 1},
- {85, 3, 1},
- {98, 3, 1},
- {112, 3, 1},
- {86, 4, 1},
- {166, 4, 1},
- {109, 5, 1},
- {113, 5, 1},
- {121, 5, 1},
- {131, 5, 1},
- {143, 5, 1},
- {153, 5, 1},
- {66, 3, 2},
- {68, 3, 2},
- {95, 3, 2},
- {106, 3, 2},
- {116, 3, 2},
- {93, 4, 2},
- {119, 4, 2},
- {121, 4, 2},
- {133, 4, 2},
- {137, 4, 2},
- {117, 5, 2},
- {118, 5, 2},
- {120, 5, 2},
- {124, 5, 2},
- {132, 5, 2},
- {137, 5, 2},
- {141, 5, 2},
- {166, 5, 2},
- {170, 5, 2},
- {191, 5, 2},
- {206, 5, 2},
- {208, 5, 2},
- {30, 2, 3},
- {69, 3, 3},
- {82, 3, 3},
- {83, 3, 3},
- {109, 3, 3},
- {114, 3, 3},
- {125, 3, 3},
- {89, 4, 3},
- {103, 4, 3},
- {117, 4, 3},
- {126, 4, 3},
- {150, 4, 3},
- {161, 4, 3},
- {121, 5, 3},
- {127, 5, 3},
- {131, 5, 3},
- {134, 5, 3},
- {148, 5, 3},
- {169, 5, 3},
- {172, 5, 3},
- {182, 5, 3},
- {195, 5, 3},
- {196, 5, 3},
- {208, 5, 3},
- {66, 2, 4},
- {85, 3, 4},
- {141, 4, 4},
- {146, 4, 4},
- {161, 4, 4},
- {177, 5, 4}
+static struct pll_limit k800_pll_limits[] = {
+ {22, 22, 2, 0},
+ {28, 28, 3, 0},
+ {81, 112, 3, 1},
+ {86, 166, 4, 1},
+ {109, 153, 5, 1},
+ {66, 116, 3, 2},
+ {93, 137, 4, 2},
+ {117, 208, 5, 2},
+ {30, 30, 2, 3},
+ {69, 125, 3, 3},
+ {89, 161, 4, 3},
+ {121, 208, 5, 3},
+ {66, 66, 2, 4},
+ {85, 85, 3, 4},
+ {141, 161, 4, 4},
+ {177, 177, 5, 4}
};
-static struct pll_config cx700_pll_config[] = {
- {98, 3, 1},
- {86, 4, 1},
- {109, 5, 1},
- {110, 5, 1},
- {113, 5, 1},
- {121, 5, 1},
- {131, 5, 1},
- {135, 5, 1},
- {142, 5, 1},
- {143, 5, 1},
- {153, 5, 1},
- {187, 5, 1},
- {208, 5, 1},
- {68, 2, 2},
- {95, 3, 2},
- {116, 3, 2},
- {93, 4, 2},
- {119, 4, 2},
- {133, 4, 2},
- {137, 4, 2},
- {151, 4, 2},
- {166, 4, 2},
- {110, 5, 2},
- {112, 5, 2},
- {117, 5, 2},
- {118, 5, 2},
- {120, 5, 2},
- {132, 5, 2},
- {137, 5, 2},
- {141, 5, 2},
- {151, 5, 2},
- {166, 5, 2},
- {175, 5, 2},
- {191, 5, 2},
- {206, 5, 2},
- {174, 7, 2},
- {82, 3, 3},
- {109, 3, 3},
- {117, 4, 3},
- {150, 4, 3},
- {161, 4, 3},
- {112, 5, 3},
- {115, 5, 3},
- {121, 5, 3},
- {127, 5, 3},
- {129, 5, 3},
- {131, 5, 3},
- {134, 5, 3},
- {138, 5, 3},
- {148, 5, 3},
- {157, 5, 3},
- {169, 5, 3},
- {172, 5, 3},
- {190, 5, 3},
- {195, 5, 3},
- {196, 5, 3},
- {208, 5, 3},
- {141, 5, 4},
- {150, 5, 4},
- {166, 5, 4},
- {176, 5, 4},
- {177, 5, 4},
- {183, 5, 4},
- {202, 5, 4}
+static struct pll_limit cx700_pll_limits[] = {
+ {98, 98, 3, 1},
+ {86, 86, 4, 1},
+ {109, 208, 5, 1},
+ {68, 68, 2, 2},
+ {95, 116, 3, 2},
+ {93, 166, 4, 2},
+ {110, 206, 5, 2},
+ {174, 174, 7, 2},
+ {82, 109, 3, 3},
+ {117, 161, 4, 3},
+ {112, 208, 5, 3},
+ {141, 202, 5, 4}
};
-static struct pll_config vx855_pll_config[] = {
- {86, 4, 1},
- {108, 5, 1},
- {110, 5, 1},
- {113, 5, 1},
- {121, 5, 1},
- {131, 5, 1},
- {135, 5, 1},
- {142, 5, 1},
- {143, 5, 1},
- {153, 5, 1},
- {164, 5, 1},
- {187, 5, 1},
- {208, 5, 1},
- {110, 5, 2},
- {112, 5, 2},
- {117, 5, 2},
- {118, 5, 2},
- {124, 5, 2},
- {132, 5, 2},
- {137, 5, 2},
- {141, 5, 2},
- {149, 5, 2},
- {151, 5, 2},
- {159, 5, 2},
- {166, 5, 2},
- {167, 5, 2},
- {172, 5, 2},
- {189, 5, 2},
- {191, 5, 2},
- {194, 5, 2},
- {206, 5, 2},
- {208, 5, 2},
- {83, 3, 3},
- {88, 3, 3},
- {109, 3, 3},
- {112, 3, 3},
- {103, 4, 3},
- {105, 4, 3},
- {161, 4, 3},
- {112, 5, 3},
- {115, 5, 3},
- {121, 5, 3},
- {127, 5, 3},
- {134, 5, 3},
- {137, 5, 3},
- {148, 5, 3},
- {157, 5, 3},
- {169, 5, 3},
- {172, 5, 3},
- {182, 5, 3},
- {191, 5, 3},
- {195, 5, 3},
- {209, 5, 3},
- {142, 4, 4},
- {146, 4, 4},
- {161, 4, 4},
- {141, 5, 4},
- {150, 5, 4},
- {165, 5, 4},
- {176, 5, 4}
+static struct pll_limit vx855_pll_limits[] = {
+ {86, 86, 4, 1},
+ {108, 208, 5, 1},
+ {110, 208, 5, 2},
+ {83, 112, 3, 3},
+ {103, 161, 4, 3},
+ {112, 209, 5, 3},
+ {142, 161, 4, 4},
+ {141, 176, 5, 4}
};
/* according to VIA Technologies these values are based on experiment */
@@ -1633,17 +1441,34 @@ 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_config *config, int size,
+static struct pll_config get_pll_config(struct pll_limit *limits, int size,
int clk)
{
- struct pll_config best = config[0];
+ struct pll_config cur, up, down, best = {0, 1, 0};
const u32 f0 = 14318180; /* X1 frequency */
- int i;
-
- for (i = 1; i < size; i++) {
- if (abs(get_pll_output_frequency(f0, config[i]) - clk)
- < abs(get_pll_output_frequency(f0, best) - clk))
- best = config[i];
+ int i, f;
+
+ for (i = 0; i < size; i++) {
+ cur.rshift = limits[i].rshift;
+ cur.divisor = limits[i].divisor;
+ cur.multiplier = clk / ((f0 / cur.divisor)>>cur.rshift);
+ f = abs(get_pll_output_frequency(f0, cur) - clk);
+ up = down = cur;
+ up.multiplier++;
+ down.multiplier--;
+ if (abs(get_pll_output_frequency(f0, up) - clk) < f)
+ cur = up;
+ else if (abs(get_pll_output_frequency(f0, down) - clk) < f)
+ cur = down;
+
+ if (cur.multiplier < limits[i].multiplier_min)
+ cur.multiplier = limits[i].multiplier_min;
+ else if (cur.multiplier > limits[i].multiplier_max)
+ cur.multiplier = limits[i].multiplier_max;
+
+ f = abs(get_pll_output_frequency(f0, cur) - clk);
+ if (f < abs(get_pll_output_frequency(f0, best) - clk))
+ best = cur;
}
return best;
@@ -1656,14 +1481,14 @@ u32 viafb_get_clk_value(int clk)
switch (viaparinfo->chip_info->gfx_chip_name) {
case UNICHROME_CLE266:
case UNICHROME_K400:
- value = cle266_encode_pll(get_pll_config(cle266_pll_config,
- ARRAY_SIZE(cle266_pll_config), clk));
+ value = cle266_encode_pll(get_pll_config(cle266_pll_limits,
+ ARRAY_SIZE(cle266_pll_limits), clk));
break;
case UNICHROME_K800:
case UNICHROME_PM800:
case UNICHROME_CN700:
- value = k800_encode_pll(get_pll_config(k800_pll_config,
- ARRAY_SIZE(k800_pll_config), clk));
+ value = k800_encode_pll(get_pll_config(k800_pll_limits,
+ ARRAY_SIZE(k800_pll_limits), clk));
break;
case UNICHROME_CX700:
case UNICHROME_CN750:
@@ -1671,13 +1496,13 @@ u32 viafb_get_clk_value(int clk)
case UNICHROME_P4M890:
case UNICHROME_P4M900:
case UNICHROME_VX800:
- value = k800_encode_pll(get_pll_config(cx700_pll_config,
- ARRAY_SIZE(cx700_pll_config), clk));
+ value = k800_encode_pll(get_pll_config(cx700_pll_limits,
+ ARRAY_SIZE(cx700_pll_limits), clk));
break;
case UNICHROME_VX855:
case UNICHROME_VX900:
- value = vx855_encode_pll(get_pll_config(vx855_pll_config,
- ARRAY_SIZE(vx855_pll_config), clk));
+ value = vx855_encode_pll(get_pll_config(vx855_pll_limits,
+ ARRAY_SIZE(vx855_pll_limits), clk));
break;
}
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 8858593..63d8d37 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -738,12 +738,11 @@ struct pll_config {
u8 rshift;
};
-struct pll_map {
- u32 clk;
- struct pll_config cle266_pll;
- struct pll_config k800_pll;
- struct pll_config cx700_pll;
- struct pll_config vx855_pll;
+struct pll_limit {
+ u16 multiplier_min;
+ u16 multiplier_max;
+ u8 divisor;
+ u8 rshift;
};
struct rgbLUT {
--
1.6.3.2
^ permalink raw reply related
* viafb clock patches - first round
From: Florian Tobias Schandinat @ 2011-03-23 22:35 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel
These series contains a first batch of clock/PLL patches. There is
still a lot to do (and a lot which can't be done due to missing
documentation) but this should be enough to point in the direction
we are heading. More PLL values have been allowed (in fact as much
as can be done without complete documentation for each platform or
using the knowledge Luc encoded in the Unichrome driver).
A bit restructuring was done to allow later moving the PLL/clock
things to it's own file. Also code was added to manage PLL source
and power but is not used yet as it is platform specific (I think)
and we lack any useful abstraction for it at the moment. Some tests
were performed to verify the documentation is not completly wrong.
All patches are also available at
git://github.com/schandinat/linux-2.6.git viafb-pll
and will also show up in linux-next after the early rc's are done.
Thanks,
Florian Tobias Schandinat
^ permalink raw reply
* [PATCH 1/4] viafb: move initialization code
From: Florian Tobias Schandinat @ 2011-03-23 21:49 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300917792-3880-1-git-send-email-FlorianSchandinat@gmx.de>
This moves some mode independend initialization code to the function
where the other parts of the initialization are.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index dc4c778..a982718 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1162,6 +1162,8 @@ void via_odev_to_seq(struct seq_file *m, u32 odev)
static void load_fix_bit_crtc_reg(void)
{
+ viafb_unlock_crt();
+
/* always set to 1 */
viafb_write_reg_mask(CR03, VIACR, 0x80, BIT7);
/* line compare should set all bits = 1 (extend modes) */
@@ -1169,8 +1171,6 @@ static void load_fix_bit_crtc_reg(void)
/* line compare should set all bits = 1 (extend modes) */
viafb_write_reg_mask(CR07, VIACR, 0x10, BIT4);
/* line compare should set all bits = 1 (extend modes) */
- viafb_write_reg_mask(CR09, VIACR, 0x40, BIT6);
- /* line compare should set all bits = 1 (extend modes) */
viafb_write_reg_mask(CR35, VIACR, 0x10, BIT4);
/* line compare should set all bits = 1 (extend modes) */
viafb_write_reg_mask(CR33, VIACR, 0x06, BIT0 + BIT1 + BIT2);
@@ -1181,6 +1181,10 @@ static void load_fix_bit_crtc_reg(void)
viafb_write_reg(CR08, VIACR, 0x00);
/* extend mode always set to 0h */
viafb_write_reg(CR14, VIACR, 0x00);
+ viafb_write_reg_mask(CR09, VIACR, 0x40, 0xDF);
+ viafb_write_reg_mask(CR11, VIACR, 0x00, BIT4 + BIT5 + BIT6);
+
+ viafb_lock_crt();
/* If K8M800, enable Prefetch Mode. */
if ((viaparinfo->chip_info->gfx_chip_name = UNICHROME_K800)
@@ -2033,8 +2037,6 @@ void viafb_fill_crtc_timing(struct crt_mode_table *crt_table,
v_addr = crt_reg.ver_addr;
if (set_iga = IGA1) {
viafb_unlock_crt();
- viafb_write_reg(CR09, VIACR, 0x00); /*initial CR09=0 */
- viafb_write_reg_mask(CR11, VIACR, 0x00, BIT4 + BIT5 + BIT6);
viafb_write_reg_mask(CR17, VIACR, 0x00, BIT7);
}
@@ -2047,7 +2049,6 @@ void viafb_fill_crtc_timing(struct crt_mode_table *crt_table,
break;
}
- load_fix_bit_crtc_reg();
viafb_lock_crt();
viafb_write_reg_mask(CR17, VIACR, 0x80, BIT7);
viafb_load_fetch_count_reg(h_addr, bpp_byte, set_iga);
@@ -2432,6 +2433,7 @@ int viafb_setmode(struct VideoModeTable *vmode_tbl, int video_bpp,
}
}
+ load_fix_bit_crtc_reg();
via_set_primary_pitch(viafbinfo->fix.line_length);
via_set_secondary_pitch(viafb_dual_fb ? viafbinfo1->fix.line_length
: viafbinfo->fix.line_length);
--
1.6.3.2
^ permalink raw reply related
* [PATCH 3/4] viafb: kill crt_setting_information
From: Florian Tobias Schandinat @ 2011-03-23 21:48 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300917792-3880-1-git-send-email-FlorianSchandinat@gmx.de>
As the iga path is the only remaining information which is also
handled by the active devices there is no reason to keep it.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/chip.h | 4 ----
drivers/video/via/hw.c | 28 +++++++++++++---------------
drivers/video/via/viafbdev.c | 7 ++-----
drivers/video/via/viafbdev.h | 2 --
4 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/drivers/video/via/chip.h b/drivers/video/via/chip.h
index 29d7024..1aa0fb3 100644
--- a/drivers/video/via/chip.h
+++ b/drivers/video/via/chip.h
@@ -137,10 +137,6 @@ struct chip_information {
struct lvds_chip_information lvds_chip_info2;
};
-struct crt_setting_information {
- int iga_path;
-};
-
struct tmds_setting_information {
int iga_path;
int h_active;
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index c4d2136..0098270 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -770,13 +770,14 @@ static u32 get_lcd_devices(int output_interface)
/*Set IGA path for each device*/
void viafb_set_iga_path(void)
{
+ int crt_iga_path = 0;
if (viafb_SAMM_ON = 1) {
if (viafb_CRT_ON) {
if (viafb_primary_dev = CRT_Device)
- viaparinfo->crt_setting_info->iga_path = IGA1;
+ crt_iga_path = IGA1;
else
- viaparinfo->crt_setting_info->iga_path = IGA2;
+ crt_iga_path = IGA2;
}
if (viafb_DVI_ON) {
@@ -793,8 +794,7 @@ void viafb_set_iga_path(void)
UNICHROME_CLE266)) {
viaparinfo->
lvds_setting_info->iga_path = IGA2;
- viaparinfo->
- crt_setting_info->iga_path = IGA1;
+ crt_iga_path = IGA1;
viaparinfo->
tmds_setting_info->iga_path = IGA1;
} else
@@ -814,10 +814,10 @@ void viafb_set_iga_path(void)
viafb_SAMM_ON = 0;
if (viafb_CRT_ON && viafb_LCD_ON) {
- viaparinfo->crt_setting_info->iga_path = IGA1;
+ crt_iga_path = IGA1;
viaparinfo->lvds_setting_info->iga_path = IGA2;
} else if (viafb_CRT_ON && viafb_DVI_ON) {
- viaparinfo->crt_setting_info->iga_path = IGA1;
+ crt_iga_path = IGA1;
viaparinfo->tmds_setting_info->iga_path = IGA2;
} else if (viafb_LCD_ON && viafb_DVI_ON) {
viaparinfo->tmds_setting_info->iga_path = IGA1;
@@ -826,7 +826,7 @@ void viafb_set_iga_path(void)
viaparinfo->lvds_setting_info->iga_path = IGA2;
viaparinfo->lvds_setting_info2->iga_path = IGA2;
} else if (viafb_CRT_ON) {
- viaparinfo->crt_setting_info->iga_path = IGA1;
+ crt_iga_path = IGA1;
} else if (viafb_LCD_ON) {
viaparinfo->lvds_setting_info->iga_path = IGA2;
} else if (viafb_DVI_ON) {
@@ -837,7 +837,7 @@ void viafb_set_iga_path(void)
viaparinfo->shared->iga1_devices = 0;
viaparinfo->shared->iga2_devices = 0;
if (viafb_CRT_ON) {
- if (viaparinfo->crt_setting_info->iga_path = IGA1)
+ if (crt_iga_path = IGA1)
viaparinfo->shared->iga1_devices |= VIA_CRT;
else
viaparinfo->shared->iga2_devices |= VIA_CRT;
@@ -2072,8 +2072,6 @@ void __devinit viafb_init_chip_info(int chip_type)
init_tmds_chip_info();
init_lvds_chip_info();
- viaparinfo->crt_setting_info->iga_path = IGA1;
-
/*Set IGA path for each device */
viafb_set_iga_path();
@@ -2450,15 +2448,15 @@ int viafb_setmode(struct VideoModeTable *vmode_tbl, int video_bpp,
/* CRT set mode */
if (viafb_CRT_ON) {
- if (viafb_SAMM_ON && (viaparinfo->crt_setting_info->iga_path =
- IGA2)) {
+ if (viafb_SAMM_ON &&
+ viaparinfo->shared->iga2_devices & VIA_CRT) {
viafb_fill_crtc_timing(crt_timing1, vmode_tbl1,
- video_bpp1 / 8,
- viaparinfo->crt_setting_info->iga_path);
+ video_bpp1 / 8, IGA2);
} else {
viafb_fill_crtc_timing(crt_timing, vmode_tbl,
video_bpp / 8,
- viaparinfo->crt_setting_info->iga_path);
+ (viaparinfo->shared->iga1_devices & VIA_CRT)
+ ? IGA1 : IGA2);
}
/* Patch if set_hres is not 8 alignment (1366) to viafb_setmode
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 9d9bb9b..ed9bd79 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -930,10 +930,8 @@ static int get_primary_device(void)
/* Rule: device on iga1 path are the primary device. */
if (viafb_SAMM_ON) {
if (viafb_CRT_ON) {
- if (viaparinfo->crt_setting_info->iga_path = IGA1) {
- DEBUG_MSG(KERN_INFO "CRT IGA Path:%d\n",
- viaparinfo->
- crt_setting_info->iga_path);
+ if (viaparinfo->shared->iga1_devices & VIA_CRT) {
+ DEBUG_MSG(KERN_INFO "CRT IGA Path:%d\n", IGA1);
primary_device = CRT_Device;
}
}
@@ -1746,7 +1744,6 @@ int __devinit via_fb_pci_probe(struct viafb_dev *vdev)
viaparinfo->lvds_setting_info = &viaparinfo->shared->lvds_setting_info;
viaparinfo->lvds_setting_info2 &viaparinfo->shared->lvds_setting_info2;
- viaparinfo->crt_setting_info = &viaparinfo->shared->crt_setting_info;
viaparinfo->chip_info = &viaparinfo->shared->chip_info;
if (viafb_dual_fb)
diff --git a/drivers/video/via/viafbdev.h b/drivers/video/via/viafbdev.h
index d66f963..ff60e1d 100644
--- a/drivers/video/via/viafbdev.h
+++ b/drivers/video/via/viafbdev.h
@@ -50,7 +50,6 @@ struct viafb_shared {
/* All the information will be needed to set engine */
struct tmds_setting_information tmds_setting_info;
- struct crt_setting_information crt_setting_info;
struct lvds_setting_information lvds_setting_info;
struct lvds_setting_information lvds_setting_info2;
struct chip_information chip_info;
@@ -79,7 +78,6 @@ struct viafb_par {
/* All the information will be needed to set engine */
/* depreciated, use the ones in shared directly */
struct tmds_setting_information *tmds_setting_info;
- struct crt_setting_information *crt_setting_info;
struct lvds_setting_information *lvds_setting_info;
struct lvds_setting_information *lvds_setting_info2;
struct chip_information *chip_info;
--
1.6.3.2
^ permalink raw reply related
* [PATCH 2/4] viafb: no need to write CRTC values twice
From: Florian Tobias Schandinat @ 2011-03-23 21:48 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300917792-3880-1-git-send-email-FlorianSchandinat@gmx.de>
Later the correct values will be written so there is no need to
write early some values which might be wrong.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index a982718..c4d2136 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -2401,9 +2401,6 @@ int viafb_setmode(struct VideoModeTable *vmode_tbl, int video_bpp,
viafb_write_reg_mask(0x15, VIASR, 0xA2, 0xA2);
- /* Write CRTC */
- viafb_fill_crtc_timing(crt_timing, vmode_tbl, video_bpp / 8, IGA1);
-
/* Write Graphic Controller */
for (i = 0; i < StdGR; i++)
via_write_reg(VIAGR, i, VPIT.GR[i]);
--
1.6.3.2
^ permalink raw reply related
* [PATCH 4/4] viafb: remove unused max_hres/vres
From: Florian Tobias Schandinat @ 2011-03-23 21:48 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300917792-3880-1-git-send-email-FlorianSchandinat@gmx.de>
This patch removes the max_hres and max_vres which are not used at
the moment. In general they could be useful but it would be better
to get them via any standard EDID implementation and not the buggy
incomplete one currently used which is also removed as far as
possible.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/chip.h | 2 -
drivers/video/via/dvi.c | 138 +---------------------------------------------
2 files changed, 3 insertions(+), 137 deletions(-)
diff --git a/drivers/video/via/chip.h b/drivers/video/via/chip.h
index 1aa0fb3..3ebf20c 100644
--- a/drivers/video/via/chip.h
+++ b/drivers/video/via/chip.h
@@ -142,8 +142,6 @@ struct tmds_setting_information {
int h_active;
int v_active;
int max_pixel_clock;
- int max_hres;
- int max_vres;
};
struct lvds_setting_information {
diff --git a/drivers/video/via/dvi.c b/drivers/video/via/dvi.c
index 41ca198..3dbcd77 100644
--- a/drivers/video/via/dvi.c
+++ b/drivers/video/via/dvi.c
@@ -28,9 +28,6 @@ static int tmds_register_read_bytes(int index, u8 *buff, int buff_len);
static void __devinit dvi_get_panel_size_from_DDCv1(
struct tmds_chip_information *tmds_chip,
struct tmds_setting_information *tmds_setting);
-static void __devinit dvi_get_panel_size_from_DDCv2(
- struct tmds_chip_information *tmds_chip,
- struct tmds_setting_information *tmds_setting);
static int viafb_dvi_query_EDID(void);
static int check_tmds_chip(int device_id_subaddr, int device_id)
@@ -47,17 +44,8 @@ void __devinit viafb_init_dvi_size(struct tmds_chip_information *tmds_chip,
DEBUG_MSG(KERN_INFO "viafb_init_dvi_size()\n");
viafb_dvi_sense();
- switch (viafb_dvi_query_EDID()) {
- case 1:
+ if (viafb_dvi_query_EDID() = 1)
dvi_get_panel_size_from_DDCv1(tmds_chip, tmds_setting);
- break;
- case 2:
- dvi_get_panel_size_from_DDCv2(tmds_chip, tmds_setting);
- break;
- default:
- printk(KERN_WARNING "viafb_init_dvi_size: DVI panel size undetected!\n");
- break;
- }
return;
}
@@ -306,12 +294,7 @@ static int viafb_dvi_query_EDID(void)
return EDID_VERSION_1; /* Found EDID1 Table */
}
- data0 = (u8) tmds_register_read(0x00);
- viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr = restore;
- if (data0 = 0x20)
- return EDID_VERSION_2; /* Found EDID2 Table */
- else
- return false;
+ return false;
}
/* Get Panel Size Using EDID1 Table */
@@ -319,50 +302,15 @@ static void __devinit dvi_get_panel_size_from_DDCv1(
struct tmds_chip_information *tmds_chip,
struct tmds_setting_information *tmds_setting)
{
- int i, max_h = 0, tmp, restore;
- unsigned char rData;
+ int i, restore;
unsigned char EDID_DATA[18];
DEBUG_MSG(KERN_INFO "\n dvi_get_panel_size_from_DDCv1 \n");
restore = tmds_chip->tmds_chip_slave_addr;
tmds_chip->tmds_chip_slave_addr = 0xA0;
-
- rData = tmds_register_read(0x23);
- if (rData & 0x3C)
- max_h = 640;
- if (rData & 0xC0)
- max_h = 720;
- if (rData & 0x03)
- max_h = 800;
-
- rData = tmds_register_read(0x24);
- if (rData & 0xC0)
- max_h = 800;
- if (rData & 0x1E)
- max_h = 1024;
- if (rData & 0x01)
- max_h = 1280;
-
for (i = 0x25; i < 0x6D; i++) {
switch (i) {
- case 0x26:
- case 0x28:
- case 0x2A:
- case 0x2C:
- case 0x2E:
- case 0x30:
- case 0x32:
- case 0x34:
- rData = tmds_register_read(i);
- if (rData = 1)
- break;
- /* data = (data + 31) * 8 */
- tmp = (rData + 31) << 3;
- if (tmp > max_h)
- max_h = tmp;
- break;
-
case 0x36:
case 0x48:
case 0x5A:
@@ -383,91 +331,11 @@ static void __devinit dvi_get_panel_size_from_DDCv1(
}
}
- tmds_setting->max_hres = max_h;
- switch (max_h) {
- case 640:
- tmds_setting->max_vres = 480;
- break;
- case 800:
- tmds_setting->max_vres = 600;
- break;
- case 1024:
- tmds_setting->max_vres = 768;
- break;
- case 1280:
- tmds_setting->max_vres = 1024;
- break;
- case 1400:
- tmds_setting->max_vres = 1050;
- break;
- case 1440:
- tmds_setting->max_vres = 1050;
- break;
- case 1600:
- tmds_setting->max_vres = 1200;
- break;
- case 1920:
- tmds_setting->max_vres = 1080;
- break;
- default:
- DEBUG_MSG(KERN_INFO "Unknown panel size max resolution = %d ! "
- "set default panel size.\n", max_h);
- break;
- }
-
DEBUG_MSG(KERN_INFO "DVI max pixelclock = %d\n",
tmds_setting->max_pixel_clock);
tmds_chip->tmds_chip_slave_addr = restore;
}
-/* Get Panel Size Using EDID2 Table */
-static void __devinit dvi_get_panel_size_from_DDCv2(
- struct tmds_chip_information *tmds_chip,
- struct tmds_setting_information *tmds_setting)
-{
- int restore;
- unsigned char R_Buffer[2];
-
- DEBUG_MSG(KERN_INFO "\n dvi_get_panel_size_from_DDCv2 \n");
-
- restore = tmds_chip->tmds_chip_slave_addr;
- tmds_chip->tmds_chip_slave_addr = 0xA2;
-
- /* Horizontal: 0x76, 0x77 */
- tmds_register_read_bytes(0x76, R_Buffer, 2);
- tmds_setting->max_hres = R_Buffer[0] + (R_Buffer[1] << 8);
-
- switch (tmds_setting->max_hres) {
- case 640:
- tmds_setting->max_vres = 480;
- break;
- case 800:
- tmds_setting->max_vres = 600;
- break;
- case 1024:
- tmds_setting->max_vres = 768;
- break;
- case 1280:
- tmds_setting->max_vres = 1024;
- break;
- case 1400:
- tmds_setting->max_vres = 1050;
- break;
- case 1440:
- tmds_setting->max_vres = 1050;
- break;
- case 1600:
- tmds_setting->max_vres = 1200;
- break;
- default:
- DEBUG_MSG(KERN_INFO "Unknown panel size max resolution = %d! "
- "set default panel size.\n", tmds_setting->max_hres);
- break;
- }
-
- tmds_chip->tmds_chip_slave_addr = restore;
-}
-
/* If Disable DVI, turn off pad */
void viafb_dvi_disable(void)
{
--
1.6.3.2
^ permalink raw reply related
* 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
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