* Re: [PATCH v3] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Kuninori Morimoto @ 2012-03-21 1:10 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87d38qwmi9.wl%kuninori.morimoto.gx@renesas.com>
Hi Florian
> > MERAM can be used for other IP blocks as well in the future.
> > It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> > This patch corrects dependency.
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
> > v2 -> v3
> >
> > - move config FB_SH_MOBILE_MERAM out of "choice"
>
> I am afraid but this is still not correct. The problem is that after
> your patch this config option has no longer any dependency on the
> framebuffer subsystem. As "FB" is a menuconfig option I guess the first
> config option without any direct or indirect dependency on FB terminates
> the menu. As I don't understand how this driver is used I don't know how
> I should resolve this: either leave it where it is and just add an
> dependency on "FB" or move it even further down, probably just before
> endmenu (AFAIK the first thing that breaks it is OMAP2).
Thank you for checking my patch.
And sorry for breaking menuconfig
As Laurent/Hayama-san said that the MERAM will be used
from VIDEO_SH_MOBILE_CEU (${LINUX}/drivers/media/video/Kconfig)
in the future.
I move it to before endmenu (without "FB" dependency)
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mipi_dsi: add extra phyctrl for sh_mipi_dsi_info
From: Kuninori Morimoto @ 2012-03-21 0:57 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87y5rdnmmu.wl%kuninori.morimoto.gx@renesas.com>
Hi Florian
Thank you for checking patch
> > sh_mipi uses some clocks, but the method of setup depends on CPU.
> >
> > Current SuperH (like sh73a0) can control all of these clocks
> > by CPG (Clock Pulse Generator).
> > It means we can control it by clock framework only.
> > But on sh7372, it needs CPG settings AND sh_mipi PHYCTRL::PLLDS,
> > and only sh7372 has PHYCTRL::PLLDS.
> >
> > But on current sh_mipi driver, PHYCTRL::PLLDS of sh7372 was
> > overwrote since the callback timing of clock setting was changed
> > by c2658b70f06108361aa5024798f9c1bf47c73374
> > (fbdev: sh_mipi_dsi: fixup setup timing of sh_mipi_setup()).
> >
> > The difference of PHYCTRL between current SuperH (=sh73a0) and
> > old SuperH (=sh7372) is not only PLLDS.
> > So this patch adds extra .phyctrl.
> >
> > It also adds detail explanation for unclear mipi settings for ap4evb.
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
(snip)
> > if (enable) {
> > + /*
> > + * DSIPCLK = 24MHz
> > + * D-PHY = DSIPCLK * ((0x6*2)+1) = 321MHz (see .phyctrl)
>
> Shouldn't this be 312?
Oops, indeed.
I fix it.
> > + * HsByteCLK = D-PHY/8 = 39MHz
> > + *
> > + * X * Y * FPS > > + * (544+72+600+16) * (961+8+8+2) * 30 = 36.1MHz
> > + */
> > clk_set_rate(pck, clk_round_rate(pck, 24000000));
> > - iowrite32(ioread32(phy) | (0xb << 8), phy);
>
> Here you remove writing a 0xb<<8 (0xb = 11 = 8+2+1)...
>
> > clk_enable(pck);
> > } else {
> > clk_disable(pck);
> > @@ -598,6 +603,7 @@ static struct sh_mipi_dsi_info mipidsi0_info = {
> > .lcd_chan = &lcdc_info.ch[0],
> > .lane = 2,
> > .vsynw_offset = 17,
> > + .phyctrl = 0x6 << 8,
>
> ...and here you set a 0x6<<8 (0x6 = 6 = 4+2). Looks suspicious, was this
> change intended?
Sorry. the git log didn't explain that this patch fixup it.
0x6 is correct here. This used for D-PHY.
D-PHY = DSIPCLK * ((0x6*2)+1) = 321MHz (see .phyctrl)
~~~
I add it on v2 patch.
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: Howto consolidate xgifb (staging) with sisfb
From: Alex Deucher @ 2012-03-20 21:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201203200002.40429.PeterHuewe@gmx.de>
On Tue, Mar 20, 2012 at 5:06 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> Hi,
>
> On Tue, Mar 20, 2012 at 12:02:39AM +0100, Peter Hüwe wrote:
>> I'm currently trying to improve the xgifb driver from staging a bit and my
>> final goal is to probably merge this driver with the sis driver (as both card
>> families seem to have a lot in common).
>>
>> However I'm a little bit unsure how to proceed here.
>
> I would first continue deleting unused dead code and definitions from the
> staging driver. We have already removed maybe 10000 lines of code without
> a loss of functionality, and I believe there is still more work to do.
>
> Then with the remaining code, we could start thinking how to consolidate
> the stuff with sisfb. Or even with the other fb drivers, I don't think
> stuff like bpp_to_var is specific to these two drivers.
>
> And once xgifb is cleaned up, the partial XGI support would be dropped
> from sisfb.
You could probably just add the pci ids to sisfb; The xgi chips were
just rebadged sis chips. IIRC, xgifb was just a fork of sisfb with
the strings changed. XGI was a combination of the old trident and sis
graphics teams. Most of the xgi cards were just rebadged sis cards
with the exception of the xp10 which was a trident variant and could
probably be merged with the tridentfb driver if there is one.
For reference see the X drivers:
Sis-based:
http://cgit.freedesktop.org/xorg/driver/xf86-video-sis
http://cgit.freedesktop.org/xorg/driver/xf86-video-xgi
Trident-based:
http://cgit.freedesktop.org/xorg/driver/xf86-video-trident
http://cgit.freedesktop.org/xorg/driver/xf86-video-xgixp
Alex
^ permalink raw reply
* Re: Howto consolidate xgifb (staging) with sisfb
From: Aaro Koskinen @ 2012-03-20 21:06 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201203200002.40429.PeterHuewe@gmx.de>
Hi,
On Tue, Mar 20, 2012 at 12:02:39AM +0100, Peter Hüwe wrote:
> I'm currently trying to improve the xgifb driver from staging a bit and my
> final goal is to probably merge this driver with the sis driver (as both card
> families seem to have a lot in common).
>
> However I'm a little bit unsure how to proceed here.
I would first continue deleting unused dead code and definitions from the
staging driver. We have already removed maybe 10000 lines of code without
a loss of functionality, and I believe there is still more work to do.
Then with the remaining code, we could start thinking how to consolidate
the stuff with sisfb. Or even with the other fb drivers, I don't think
stuff like bpp_to_var is specific to these two drivers.
And once xgifb is cleaned up, the partial XGI support would be dropped
from sisfb.
A.
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-20 18:55 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332241764.10557.329.camel@linux-s257.site>
> >From 5da43d2ee6c87dcf17fda34f0b50fe11b04a16bf Mon Sep 17 00:00:00 2001
> From: "Lee, Chun-Yi" <jlee@suse.com>
> Date: Tue, 20 Mar 2012 19:00:58 +0800
> Subject: [PATCH] acer-wmi: add quirk table for video backlight vendor mode
>
> There have some acer laptop have broken _BCM implemenation, the AML
> code wrote value to EC register but firmware didn't change brighenss.
>
> Fortunately, the brightness control works on those machines with
> vendor mode. So, add quirk table for video backlight vendor mode
> and unregister acpi video interface on those machines.
>
> Tested on Acer TravelMate 4750
>
> Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
> ---
> drivers/platform/x86/Kconfig | 4 ++++
> drivers/platform/x86/acer-wmi.c | 38 +++++++++++++++++++++++++++++++++++---
> 2 files changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 15dbd8c..fe3a494 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -26,6 +26,10 @@ config ACER_WMI
> depends on RFKILL || RFKILL = n
> depends on ACPI_WMI
> select INPUT_SPARSEKMAP
> + # Acer WMI depends on ACPI_VIDEO when ACPI is enabled
> + # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> + select VIDEO_OUTPUT_CONTROL if ACPI
> + select ACPI_VIDEO if ACPI
> ---help---
> This is a driver for newer Acer (and Wistron) laptops. It adds
> wireless radio and bluetooth control, and on some laptops,
> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> index 1e5290b..984a7b5 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -43,6 +43,7 @@
> #include <linux/input/sparse-keymap.h>
>
> #include <acpi/acpi_drivers.h>
> +#include <acpi/video.h>
>
> MODULE_AUTHOR("Carlos Corbacho");
> MODULE_DESCRIPTION("Acer Laptop WMI Extras Driver");
> @@ -478,6 +479,33 @@ static struct dmi_system_id acer_quirks[] = {
> {}
> };
>
> +static int video_set_backlight_video_vendor(const struct dmi_system_id *d)
> +{
> + interface->capability &= ~ACER_CAP_BRIGHTNESS;
> + pr_info("Brightness must be controlled by generic video driver\n");
> + return 0;
> +}
> +
> +static const struct dmi_system_id video_vendor_dmi_table[] = {
> + {
> + .callback = video_set_backlight_video_vendor,
> + .ident = "Acer Aspire 4736",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 4736"),
> + },
> + },
> + {
> + .callback = video_set_backlight_video_vendor,
> + .ident = "Acer TravelMate 4750",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
> + },
> + },
> + {}
> +};
> +
> /* Find which quirks are needed for a particular vendor/ model pair */
> static void find_quirks(void)
> {
> @@ -1981,9 +2009,13 @@ static int __init acer_wmi_init(void)
> set_quirks();
>
> if (acpi_video_backlight_support()) {
> - interface->capability &= ~ACER_CAP_BRIGHTNESS;
> - pr_info("Brightness must be controlled by "
> - "generic video driver\n");
> + if (dmi_check_system(video_vendor_dmi_table)) {
> + acpi_video_unregister();
> + } else {
> + interface->capability &= ~ACER_CAP_BRIGHTNESS;
> + pr_info("Brightness must be controlled by "
> + "acpi video driver\n");
> + }
> }
>
> if (wmi_has_guid(WMID_GUID3)) {
I tried out applied your patch . Boot message shows ,
[11.220410] acer_wmi: Brightness must be controlled by generic video
driver
Now 'acpi_video0' and 'intel_backlight' are present
inside /sys/class/backlight .Hot key works like earlier ( ie problem
after maximum level still exists).
I tried following commands ,
echo 5 > /sys/class/backlight/acpi_video0/brightness
echo 5 > /sys/class/backlight/intel_backlight/brightness
But it doesn't make any change .
In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
already starts working with 'acpi_osi=Linux' option.
cat /proc/cmdline gives ,
BOOT_IMAGE=/boot/vmlinuz-3.3.0+
root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
Thanks ,
Pradeep Subrahmanion
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-20 11:09 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332122514.10557.270.camel@linux-s257.site>
於 一，2012-03-19 於 10:01 +0800，joeyli 提到：
> 於 日，2012-03-18 於 10:40 +0530，Pradeep Subrahmanion 提到：
> > On Thu, 2012-03-15 at 16:05 +0800, joeyli wrote:
> > > Hi Pradeep,
> > >
> > > 於 三，2012-03-14 於 11:47 +0530，Pradeep Subrahmanion 提到：
> > > > On Wed, Mar 14, 2012 at 11:21 AM, joeyli <jlee@suse.com> wrote:
> > > > > 於 三，2012-03-14 於 08:13 +0530，Pradeep Subrahmanion 提到：
> > > > >> Hi Joey ,
> > > > >>
> > > > >> > Per my understood, EC firmware should change brightness but didn't do
> > > > >> > that, another
> > > > >> > way is touch i915 register in _BCM.
> > > > >>
> > > > >> how do we do this ? you mean change the _BCM implementation ?
> > > > >
> > > > > "BIOS guy" should do something like this:
> > > > >
> > > > > Method (AINT, 2, NotSerialized)
> > > > > {
> > > > > ...
> > > > > If (LEqual (Arg0, One))
> > > > > {
> > > > > Store (Divide (Multiply (Arg1, 0xFF), 0x64, ), BCLP)
> > > > > Or (BCLP, 0x80000000, BCLP) <== touch BCLP register
> > > > > Store (0x02, ASLC)
> > > > > }
> > > > >
> > > > > Method (_BCM, 1, NotSerialized)
> > > > > {
> > > > > If (LAnd (LGreaterEqual (Arg0, Zero), LLessEqual (Arg0, 0x64)))
> > > > > {
> > > > > AINT (One, Arg0) <== call AINT method
> > > > > Store (Arg0, BRTL)
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > > Just for reference, they should do that when EC didn't wire to
> > > > > backlight.
> > > > >
> > > > >> >
> > > > >> > Acer machine provide a broken _BCM implementation and they didn't test
> > > > >> > it.
> > > > >> >
> > > > >> > > > > By ' ACPI interface' , I mean 'acpi_video0' inside the
> > > > >> > > > > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
> > > > >> > > > > directly . I will try that also.
> > > > >> > > >
> > > > >> > > > So writing values into /sys/class/backlight/acpi_video0/brightness does
> > > > >> > > > nothing?
> > > > >> > >
> > > > >> > >
> > > > >> > > No change in value when writing
> > > > >> > > to /sys/class/backlight/acpi_video0/brightness.
> > > > >> > >
> > > > >> > > Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
> > > > >> > > in new kernel (3.3.0-rc7) , it shows following messages ,
> > > > >> > >
> > > > >> > > [ 8.350825] wmi: Mapper loaded
> > > > >> > > [ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
> > > > >> > > [ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
> > > > >> > > [ 10.396385] acer_wmi: Brightness must be controlled by generic video
> > > > >> > > driver
> > > > >> > >
> > > > >> > > Also there was no interface inside /sys/class/backlight for acer_wmi.
> > > > >> > >
> > > > >> >
> > > > >> > Yes, acer_wmi support backlight control with AMW0 interface, your
> > > > >> > machine didn't have AMW0 interface.
> > > > >> >
> > > > >> > Normally, backlight should control by standard acpi interface.
> > > > >> >
> > > > >> > > I also tried writing directly to Embedded controller register .But no
> > > > >> > > change.
> > > > >> >
> > > > >> > The machine has broken _BCM method, because EC should do something after
> > > > >> > _BCM changed EC register.
> > > > >>
> > > > >> Thanks ,
> > > > >>
> > > > >> Pradeep Subrahmanion
> > > > >
> > > > > Why they didn't find _BCM not work?
> > > > >
> > > > > My guess is:
> > > > >
> > > > > Because the backlight control is through WDDM driver on Windows platform
> > > > > but not through standard ACPI method _BCM. They only test Windows
> > > > > platform, so, they didn't find _BCM broken.
> > > > >
> > > > > And, they also didn't really follow Microsoft WDDM spec:
> > > > >
> > > > > http://msdn.microsoft.com/en-us/windows/hardware/gg487382.aspx
> > > > >
> > > > > Per spec,
> > > > > ODM should keep _BCM works fine for any other OS didn't support WDDM
> > > > > driver, but they didn't.
> > > > >
> > > > > At last year, I told Acer PM one time for this issue, they said will
> > > > > check but finally didn't response me.
> > > > >
> > > >
> > > > >
> > > > > Thanks
> > > > > Joey Lee
> > > > >
> > > >
> > > > So touching the PCI LBB register is the only feasible solution now
> > > > (even though it may not be a clean method) ?
> > > >
> > > > Thanks,
> > > > Pradeep Subrahmanion
> > >
> > > That will be better leave LBB register only touched by i915 driver.
> > >
> > > If 'acpi_backlight=vendor' works to you, maybe we can add a quirk to
> > > video_detect.c.
> > > You can try the following patch.
> >
> > Thanks . I tried your patch .acpi_backlight=vendor allows me to control
> > brightness with hot key.But there are problems with it like increasing
>
> OK, thanks for your testing, I will send out patch and add Cc. to you.
>
Could you please kindly try this new patch? I follow Matthew's kindly
suggestion put the quirk table to acer-wmi driver.
Please help to apply the following patch to acer-wmi and remember remove
my last patch of video_detect.c, then rebuild your kernel.
Hope this patch also can fix your problem.
Thanks a lot!
Joey Lee
From 5da43d2ee6c87dcf17fda34f0b50fe11b04a16bf Mon Sep 17 00:00:00 2001
From: "Lee, Chun-Yi" <jlee@suse.com>
Date: Tue, 20 Mar 2012 19:00:58 +0800
Subject: [PATCH] acer-wmi: add quirk table for video backlight vendor mode
There have some acer laptop have broken _BCM implemenation, the AML
code wrote value to EC register but firmware didn't change brighenss.
Fortunately, the brightness control works on those machines with
vendor mode. So, add quirk table for video backlight vendor mode
and unregister acpi video interface on those machines.
Tested on Acer TravelMate 4750
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
---
drivers/platform/x86/Kconfig | 4 ++++
drivers/platform/x86/acer-wmi.c | 38 +++++++++++++++++++++++++++++++++++---
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 15dbd8c..fe3a494 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -26,6 +26,10 @@ config ACER_WMI
depends on RFKILL || RFKILL = n
depends on ACPI_WMI
select INPUT_SPARSEKMAP
+ # Acer WMI depends on ACPI_VIDEO when ACPI is enabled
+ # but for select to work, need to select ACPI_VIDEO's dependencies, ick
+ select VIDEO_OUTPUT_CONTROL if ACPI
+ select ACPI_VIDEO if ACPI
---help---
This is a driver for newer Acer (and Wistron) laptops. It adds
wireless radio and bluetooth control, and on some laptops,
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 1e5290b..984a7b5 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -43,6 +43,7 @@
#include <linux/input/sparse-keymap.h>
#include <acpi/acpi_drivers.h>
+#include <acpi/video.h>
MODULE_AUTHOR("Carlos Corbacho");
MODULE_DESCRIPTION("Acer Laptop WMI Extras Driver");
@@ -478,6 +479,33 @@ static struct dmi_system_id acer_quirks[] = {
{}
};
+static int video_set_backlight_video_vendor(const struct dmi_system_id *d)
+{
+ interface->capability &= ~ACER_CAP_BRIGHTNESS;
+ pr_info("Brightness must be controlled by generic video driver\n");
+ return 0;
+}
+
+static const struct dmi_system_id video_vendor_dmi_table[] = {
+ {
+ .callback = video_set_backlight_video_vendor,
+ .ident = "Acer Aspire 4736",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 4736"),
+ },
+ },
+ {
+ .callback = video_set_backlight_video_vendor,
+ .ident = "Acer TravelMate 4750",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
+ },
+ },
+ {}
+};
+
/* Find which quirks are needed for a particular vendor/ model pair */
static void find_quirks(void)
{
@@ -1981,9 +2009,13 @@ static int __init acer_wmi_init(void)
set_quirks();
if (acpi_video_backlight_support()) {
- interface->capability &= ~ACER_CAP_BRIGHTNESS;
- pr_info("Brightness must be controlled by "
- "generic video driver\n");
+ if (dmi_check_system(video_vendor_dmi_table)) {
+ acpi_video_unregister();
+ } else {
+ interface->capability &= ~ACER_CAP_BRIGHTNESS;
+ pr_info("Brightness must be controlled by "
+ "acpi video driver\n");
+ }
}
if (wmi_has_guid(WMID_GUID3)) {
--
1.7.7
^ permalink raw reply related
* Re: Howto consolidate xgifb (staging) with sisfb
From: Thomas Winischhofer @ 2012-03-20 6:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201203200002.40429.PeterHuewe@gmx.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter Hüwe wrote:
> Hi,
>
> I'm currently trying to improve the xgifb driver from staging a bit and my
> final goal is to probably merge this driver with the sis driver (as both card
> families seem to have a lot in common).
>
> However I'm a little bit unsure how to proceed here.
>
> e.g. the sis and the xgifb driver have some nearly duplicated functions in
> common, e.g.
> static void XGIfb_bpp_to_var(struct xgifb_video_info *xgifb_info,
> struct fb_var_screeninfo *var)
> http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/staging/xgifb/XGI_main_26.c;hb=HEAD#l769
>
> and
> static void sisfb_bpp_to_var(struct sis_video_info *ivideo, struct
> fb_var_screeninfo *var)
> http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/video/sis/sis_main.c;hb=HEAD#l1129
>
>
> have the same semantics. (the only difference is the _video_info struct).
>
> -> Is there a way the xgifb driver can call the function from sis? (I know
> it's static and not EXPORT_SYMBOL'ed)
> Or how would you prepare the consolidation here ?
> (e.g. make the functions identical? and when the merge get's done sometime
> simply remove the duplicate?)
>
>
>
> And how would you proceed with functions that are nearly identical (but each
> function is missing some bits from the other card)
> e.g.
> static int sisfb_get_fix(struct fb_fix_screeninfo *fix, int con, struct
> fb_info *info)
> http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/video/sis/sis_main.c;hb=HEAD#l1839
> and
> static int XGIfb_get_fix(struct fb_fix_screeninfo *fix, int con, struct
> fb_info *info)
> http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/staging/xgifb/XGI_main_26.c;hb=HEAD#l1365
> could be easily merged, but in which direction? Add the new code to directly
> to sis or 'backport' sis stuff to xgifb? or both (i.e. make them identical
> like in the first case?)
>
>
>
> Thanks,
> Peter
>
>
I seem to remember that sisfb supported most of the XGI cards
(V3XT/V5/V8, Z7) as well.... What can xgifb do that sisfb can't? Merging
the blobs to support the Z9 and Z11 IMHO doesn't justify a separate driver.
Regards
Thomas
- --
Thomas Winischhofer
thomas AT winischhofer DOT net
The Online Photo Editor ***************** http://www.phixr.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFPaCZMzydIRAktyUcRArf4AJ9Sp16HV7j5BmoJnV1GtRIwWKnayACePBF3
1yNMXuxDnpL77ov0EwLs5m0=EMek
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Benjamin Herrenschmidt @ 2012-03-20 5:40 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: linux-fbdev, Florian Tobias Schandinat, Tony Breeds, linuxppc-dev
In-Reply-To: <CALT56yPjkPQOaXW4Eg8c-S4+a4Omou_YYacqrsCoTAYeXO0XkA@mail.gmail.com>
> >> That is interesting! Are those patches published or otherwise available
> >> somewhere? We are also very interested in enabling Canyonlands
> >> with Radeon KMS!
> >
> > You will run into additional problems with 460 due to the fact that it's
> > not cache coherent for DMA. Tony patches don't address that part of the
> > problem (they were used on a 476 based platform).
>
> Hmm. Could you please spill a little bit more of details? Also are those patches
> for 476 merged or present somewhere?
Well, DMA on 46x isn't cache coherent. The DRM plays interesting games
with mapping/unmapping pages for DMA by the chip and I don't think we
have the right hooks to do the appropriate cache flushing on these guys,
but Tony might be able to comment, I don't know whether he tried or not.
On the other hand 476 has fully cache coherent DMA so the only problem
there is the >32-bit physical address space.
As for the patches, you'll have to wait for Tony to respond (I'll poke
him locally).
Cheers,
Ben.
> >> > In fact, we could make the new structure such that it doesn't break
> >> > userspace compatibility with 64-bit architectures at all, ie, the "new"
> >> > and "compat" ioctl could remain entirely equivalent on 64-bit.
> >>
> >> I remember stuff about compat_ioctl, but I have never used/implemented
> >> that. Are there any details of requirements for the structures being passed?
> >
> > In that specific case, I meant something else. IE. The old ioctl could
> > remain unchanged, and the new ioctl make the same as the old one on
> > 64-bit platforms.
>
> I don't think this kind of magic would be good. I'd just stick to the new
> ioctl.
>
> >
> > Cheers,
> > Ben.
> >
> >
> >
>
>
>
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-20 3:55 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332156793.2964.3.camel@debian.Gayathri>
Hi Pradeep,
於 一，2012-03-19 於 17:03 +0530，Pradeep Subrahmanion 提到：
> > For the maximum level causes blank screen...
> >
> > Please kindly help to identify which driver handle the brightness
> > change, run the following 2 commands:
> >
> > # echo 5 > /sys/class/backlight/acer-wmi/brightness
> > # echo 5 > /sys/class/backlight/intel_backlight/brightness
> >
> > Which one works to change brightness on your machine?
>
> Both of them do not work for me.Only hot keys are working.
>
> Writing to /sys/class/backlight/acer-wmi/brightness
>
> and /sys/class/backlight/intel_backlight/brightness do not cause any
>
> change in brightness.
>
>
> Regards ,
>
> Pradeep Subrahmanion
A bit strange...
Could you please paste your /proc/cmdline ? Did you add
acpi_osi="Linux" ?
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mipi_dsi: add extra phyctrl for sh_mipi_dsi_info
From: Florian Tobias Schandinat @ 2012-03-20 0:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87y5rdnmmu.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
On 03/07/2012 02:57 AM, Kuninori Morimoto wrote:
> sh_mipi uses some clocks, but the method of setup depends on CPU.
>
> Current SuperH (like sh73a0) can control all of these clocks
> by CPG (Clock Pulse Generator).
> It means we can control it by clock framework only.
> But on sh7372, it needs CPG settings AND sh_mipi PHYCTRL::PLLDS,
> and only sh7372 has PHYCTRL::PLLDS.
>
> But on current sh_mipi driver, PHYCTRL::PLLDS of sh7372 was
> overwrote since the callback timing of clock setting was changed
> by c2658b70f06108361aa5024798f9c1bf47c73374
> (fbdev: sh_mipi_dsi: fixup setup timing of sh_mipi_setup()).
>
> The difference of PHYCTRL between current SuperH (=sh73a0) and
> old SuperH (=sh7372) is not only PLLDS.
> So this patch adds extra .phyctrl.
>
> It also adds detail explanation for unclear mipi settings for ap4evb.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> arch/arm/mach-shmobile/board-ap4evb.c | 12 +++++++++---
> drivers/video/sh_mipi_dsi.c | 2 +-
> include/video/sh_mipi_dsi.h | 1 +
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
> index b4718b0..ca075aa 100644
> --- a/arch/arm/mach-shmobile/board-ap4evb.c
> +++ b/arch/arm/mach-shmobile/board-ap4evb.c
> @@ -556,20 +556,25 @@ static struct platform_device keysc_device = {
> };
>
> /* MIPI-DSI */
> -#define PHYCTRL 0x0070
> static int sh_mipi_set_dot_clock(struct platform_device *pdev,
> void __iomem *base,
> int enable)
> {
> struct clk *pck = clk_get(&pdev->dev, "dsip_clk");
> - void __iomem *phy = base + PHYCTRL;
>
> if (IS_ERR(pck))
> return PTR_ERR(pck);
>
> if (enable) {
> + /*
> + * DSIPCLK = 24MHz
> + * D-PHY = DSIPCLK * ((0x6*2)+1) = 321MHz (see .phyctrl)
Shouldn't this be 312?
> + * HsByteCLK = D-PHY/8 = 39MHz
> + *
> + * X * Y * FPS > + * (544+72+600+16) * (961+8+8+2) * 30 = 36.1MHz
> + */
> clk_set_rate(pck, clk_round_rate(pck, 24000000));
> - iowrite32(ioread32(phy) | (0xb << 8), phy);
Here you remove writing a 0xb<<8 (0xb = 11 = 8+2+1)...
> clk_enable(pck);
> } else {
> clk_disable(pck);
> @@ -598,6 +603,7 @@ static struct sh_mipi_dsi_info mipidsi0_info = {
> .lcd_chan = &lcdc_info.ch[0],
> .lane = 2,
> .vsynw_offset = 17,
> + .phyctrl = 0x6 << 8,
...and here you set a 0x6<<8 (0x6 = 6 = 4+2). Looks suspicious, was this
change intended?
> .flags = SH_MIPI_DSI_SYNC_PULSES_MODE |
> SH_MIPI_DSI_HSbyteCLK,
> .set_dot_clock = sh_mipi_set_dot_clock,
> diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
> index 05151b8..214482c 100644
> --- a/drivers/video/sh_mipi_dsi.c
> +++ b/drivers/video/sh_mipi_dsi.c
> @@ -271,7 +271,7 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
> iowrite32(0x00000001, base + PHYCTRL);
> udelay(200);
> /* Deassert resets, power on */
> - iowrite32(0x03070001, base + PHYCTRL);
> + iowrite32(0x03070001 | pdata->phyctrl, base + PHYCTRL);
>
> /*
> * Default = ULPS enable |
> diff --git a/include/video/sh_mipi_dsi.h b/include/video/sh_mipi_dsi.h
> index 434d56b..06c67fb 100644
> --- a/include/video/sh_mipi_dsi.h
> +++ b/include/video/sh_mipi_dsi.h
> @@ -51,6 +51,7 @@ struct sh_mipi_dsi_info {
> int lane;
> unsigned long flags;
> u32 clksrc;
> + u32 phyctrl; /* for extra setting */
> unsigned int vsynw_offset;
> int (*set_dot_clock)(struct platform_device *pdev,
> void __iomem *base,
Thanks,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH v3] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Florian Tobias Schandinat @ 2012-03-20 0:21 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87d38qwmi9.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
sorry for taking so long to reply.
On 03/06/2012 01:23 AM, Kuninori Morimoto wrote:
> MERAM can be used for other IP blocks as well in the future.
> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> This patch corrects dependency.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> v2 -> v3
>
> - move config FB_SH_MOBILE_MERAM out of "choice"
I am afraid but this is still not correct. The problem is that after
your patch this config option has no longer any dependency on the
framebuffer subsystem. As "FB" is a menuconfig option I guess the first
config option without any direct or indirect dependency on FB terminates
the menu. As I don't understand how this driver is used I don't know how
I should resolve this: either leave it where it is and just add an
dependency on "FB" or move it even further down, probably just before
endmenu (AFAIK the first thing that breaks it is OMAP2).
Best regards,
Florian Tobias Schandinat
>
> drivers/video/Kconfig | 23 +++++++++++------------
> 1 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 8951cbd..36e8b06 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
> ---help---
> Driver for the on-chip SH-Mobile HDMI controller.
>
> -config FB_SH_MOBILE_MERAM
> - tristate "SuperH Mobile MERAM read ahead support for LCDC"
> - depends on FB_SH_MOBILE_LCDC
> - default y
> - ---help---
> - Enable MERAM support for the SH-Mobile LCD controller.
> -
> - This will allow for caching of the framebuffer to provide more
> - reliable access under heavy main memory bus traffic situations.
> - Up to 4 memory channels can be configured, allowing 4 RGB or
> - 2 YCbCr framebuffers to be configured.
> -
> config FB_TMIO
> tristate "Toshiba Mobile IO FrameBuffer support"
> depends on FB && MFD_CORE
> @@ -2332,6 +2320,17 @@ config FB_MB862XX_LIME
>
> endchoice
>
> +config FB_SH_MOBILE_MERAM
> + tristate "SuperH Mobile MERAM read ahead support"
> + depends on (SUPERH || ARCH_SHMOBILE)
> + ---help---
> + Enable MERAM support for the SuperH controller.
> +
> + This will allow for caching of the framebuffer to provide more
> + reliable access under heavy main memory bus traffic situations.
> + Up to 4 memory channels can be configured, allowing 4 RGB or
> + 2 YCbCr framebuffers to be configured.
> +
> config FB_MB862XX_I2C
> bool "Support I2C bus on MB862XX GDC"
> depends on FB_MB862XX && I2C
^ permalink raw reply
* Re: Howto consolidate xgifb (staging) with sisfb
From: Greg KH @ 2012-03-19 23:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201203200002.40429.PeterHuewe@gmx.de>
On Tue, Mar 20, 2012 at 12:02:39AM +0100, Peter Hüwe wrote:
> Hi,
>
> I'm currently trying to improve the xgifb driver from staging a bit and my
> final goal is to probably merge this driver with the sis driver (as both card
> families seem to have a lot in common).
>
> However I'm a little bit unsure how to proceed here.
>
> e.g. the sis and the xgifb driver have some nearly duplicated functions in
> common, e.g.
> static void XGIfb_bpp_to_var(struct xgifb_video_info *xgifb_info,
> struct fb_var_screeninfo *var)
> http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/staging/xgifb/XGI_main_26.c;hb=HEAD#l769
>
> and
> static void sisfb_bpp_to_var(struct sis_video_info *ivideo, struct
> fb_var_screeninfo *var)
> http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/video/sis/sis_main.c;hb=HEAD#l1129
>
>
> have the same semantics. (the only difference is the _video_info struct).
>
> -> Is there a way the xgifb driver can call the function from sis? (I know
> it's static and not EXPORT_SYMBOL'ed)
Declare it not static and EXPORT_SYMBOL it :)
> Or how would you prepare the consolidation here ?
> (e.g. make the functions identical? and when the merge get's done sometime
> simply remove the duplicate?)
How about moving things to a "library" module that both modules call
with these functions, pulling them from one of the drivers.
> And how would you proceed with functions that are nearly identical (but each
> function is missing some bits from the other card)
> e.g.
> static int sisfb_get_fix(struct fb_fix_screeninfo *fix, int con, struct
> fb_info *info)
> http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/video/sis/sis_main.c;hb=HEAD#l1839
> and
> static int XGIfb_get_fix(struct fb_fix_screeninfo *fix, int con, struct
> fb_info *info)
> http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/staging/xgifb/XGI_main_26.c;hb=HEAD#l1365
> could be easily merged, but in which direction? Add the new code to directly
> to sis or 'backport' sis stuff to xgifb? or both (i.e. make them identical
> like in the first case?)
Whatever you feel is best to do here.
greg k-h
^ permalink raw reply
* Howto consolidate xgifb (staging) with sisfb
From: Peter Hüwe @ 2012-03-19 23:02 UTC (permalink / raw)
To: linux-fbdev
Hi,
I'm currently trying to improve the xgifb driver from staging a bit and my
final goal is to probably merge this driver with the sis driver (as both card
families seem to have a lot in common).
However I'm a little bit unsure how to proceed here.
e.g. the sis and the xgifb driver have some nearly duplicated functions in
common, e.g.
static void XGIfb_bpp_to_var(struct xgifb_video_info *xgifb_info,
struct fb_var_screeninfo *var)
http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/staging/xgifb/XGI_main_26.c;hb=HEAD#l769
and
static void sisfb_bpp_to_var(struct sis_video_info *ivideo, struct
fb_var_screeninfo *var)
http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/video/sis/sis_main.c;hb=HEAD#l1129
have the same semantics. (the only difference is the _video_info struct).
-> Is there a way the xgifb driver can call the function from sis? (I know
it's static and not EXPORT_SYMBOL'ed)
Or how would you prepare the consolidation here ?
(e.g. make the functions identical? and when the merge get's done sometime
simply remove the duplicate?)
And how would you proceed with functions that are nearly identical (but each
function is missing some bits from the other card)
e.g.
static int sisfb_get_fix(struct fb_fix_screeninfo *fix, int con, struct
fb_info *info)
http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/video/sis/sis_main.c;hb=HEAD#l1839
and
static int XGIfb_get_fix(struct fb_fix_screeninfo *fix, int con, struct
fb_info *info)
http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=blob;f=drivers/staging/xgifb/XGI_main_26.c;hb=HEAD#l1365
could be easily merged, but in which direction? Add the new code to directly
to sis or 'backport' sis stuff to xgifb? or both (i.e. make them identical
like in the first case?)
Thanks,
Peter
^ permalink raw reply
* Re: Radeon fb issue: invalid framebuffer id kernel 3.2.12
From: Dave Airlie @ 2012-03-19 19:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CADpTngU6fL3r3cHsH3B6Hx68Bm4R_baoBeVmvGf6bUJPV3CXbA@mail.gmail.com>
> Hi all,
> I'm setting up a new laptot with Advanced Micro Devices [AMD] nee ATI
> Seymour [Radeon HD 6400M Series] card, using radeon drivers. I'm
> facing an issue for wich I found a lot of references but no actual
> solution, so I'm asking here for some help
the invalid framebuffer id isn't fatal, however it sounds like you
haven't got CONFIG_FRAMEBUFFER_CONSOLE
or haven't loaded fbcon.
Dave.
^ permalink raw reply
* Radeon fb issue: invalid framebuffer id kernel 3.2.12
From: Fabio Coatti @ 2012-03-19 18:25 UTC (permalink / raw)
To: linux-fbdev
Hi all,
I'm setting up a new laptot with Advanced Micro Devices [AMD] nee ATI
Seymour [Radeon HD 6400M Series] card, using radeon drivers. I'm
facing an issue for wich I found a lot of references but no actual
solution, so I'm asking here for some help
Basically it works quite fine, except for fb.
description of the issue:
at boot, once fb is fired up i get a black screen, afer some usual
boot messages. Connecting via ssh I can launch X and all works just
fine; however with ctrl-alt-F1 the screen freezes immediately with
this error in dmesg:
drm:drm_mode_getfb] *ERROR* invalid framebuffer id
some more debug lines:
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:23:VGA-1]
[drm:radeon_atom_dac_detect], Bios 0 scratch 40000 00000001
[drm:radeon_atombios_connected_scratch_regs], CRT1 disconnected
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:23:VGA-1] disconnected
[drm:radeon_lvds_set_property],
[drm:drm_mode_getfb] *ERROR* invalid framebuffer id
If I hit ctrl-alt-F7 all work just fine: screen unfreezes and I can
work without other issues.
Perfectly repeatable.
I can provide more debug logs and data, if needed; just place me in
CC: list as I'm not subscribed to this list.
Kernel: 3.2.12 3.2.12 #1 SMP PREEMPT Mon Mar 19 18:54:30 CET 2012
x86_64 Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz GenuineIntel GNU/Linux
dmesg excerpt:
Mar 19 19:01:58 calvin kernel: [drm] radeon kernel modesetting enabled.
Mar 19 19:01:58 calvin kernel: radeon 0000:01:00.0: PCI INT A -> GSI
16 (level, low) -> IRQ 16
Mar 19 19:01:58 calvin kernel: radeon 0000:01:00.0: setting latency timer to 64
Mar 19 19:01:58 calvin kernel: [drm] initializing kernel modesetting
(CAICOS 0x1002:0x6760 0x103C:0x161E).
Mar 19 19:01:58 calvin kernel: [drm] register mmio base: 0xD4400000
Mar 19 19:01:58 calvin kernel: [drm] register mmio size: 131072
Mar 19 19:01:58 calvin kernel: ATOM BIOS: HP
Mar 19 19:01:58 calvin kernel: radeon 0000:01:00.0: VRAM: 1024M
0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
Mar 19 19:01:58 calvin kernel: radeon 0000:01:00.0: GTT: 512M
0x0000000040000000 - 0x000000005FFFFFFF
Mar 19 19:01:58 calvin kernel: [drm] Detected VRAM RAM\x1024M, BAR%6M
Mar 19 19:01:58 calvin kernel: [drm] RAM width 64bits DDR
Mar 19 19:01:58 calvin kernel: [TTM] Zone kernel: Available graphics
memory: 4059236 kiB.
Mar 19 19:01:58 calvin kernel: [TTM] Zone dma32: Available graphics
memory: 2097152 kiB.
Mar 19 19:01:58 calvin kernel: [TTM] Initializing pool allocator.
Mar 19 19:01:58 calvin kernel: [drm] radeon: 1024M of VRAM memory ready
Mar 19 19:01:58 calvin kernel: [drm] radeon: 512M of GTT memory ready.
Mar 19 19:01:58 calvin kernel: [drm] Supports vblank timestamp caching
Rev 1 (10.10.2010).
Mar 19 19:01:58 calvin kernel: [drm] Driver supports precise vblank
timestamp query.
Mar 19 19:01:58 calvin kernel: radeon 0000:01:00.0: irq 54 for MSI/MSI-X
Mar 19 19:01:58 calvin kernel: radeon 0000:01:00.0: radeon: using MSI.
Mar 19 19:01:58 calvin kernel: [drm] radeon: irq initialized.
Mar 19 19:01:58 calvin kernel: [drm] GART: num cpu pages 131072, num
gpu pages 131072
Mar 19 19:01:58 calvin kernel: [drm] Loading CAICOS Microcode
[...]
Mar 19 19:01:58 calvin kernel: [drm] ring test succeeded in 3 usecs
Mar 19 19:01:58 calvin kernel: [drm] radeon: ib pool ready.
Mar 19 19:01:58 calvin kernel: [drm] ib test succeeded in 0 usecs
Mar 19 19:01:58 calvin kernel: [drm:radeon_process_aux_ch], dp_aux_ch
flags not zero
Mar 19 19:01:58 calvin kernel: [drm:radeon_process_aux_ch], dp_aux_ch
flags not zero
Mar 19 19:01:58 calvin kernel: [drm:radeon_process_aux_ch], dp_aux_ch
flags not zero
Mar 19 19:01:58 calvin kernel: [drm:radeon_process_aux_ch], dp_aux_ch
flags not zero
Mar 19 19:01:58 calvin kernel: [drm:radeon_dp_i2c_aux_ch], aux i2c too
many retries, giving up
Mar 19 19:01:58 calvin kernel: [drm:radeon_process_aux_ch], dp_aux_ch
flags not zero
Mar 19 19:01:58 calvin kernel: [drm:radeon_process_aux_ch], dp_aux_ch
flags not zero
[repeated several times]
Mar 19 19:01:58 calvin kernel: [drm:radeon_process_aux_ch], dp_aux_ch
flags not zero
Mar 19 19:01:58 calvin kernel: [drm:radeon_process_aux_ch], dp_aux_ch
flags not zero
Mar 19 19:01:58 calvin kernel: [drm:radeon_process_aux_ch], dp_aux_ch
flags not zero
Mar 19 19:01:58 calvin kernel: [drm:radeon_dp_i2c_aux_ch], aux i2c too
many retries, giving up
Mar 19 19:01:58 calvin kernel: [drm] Radeon Display Connectors
Mar 19 19:01:58 calvin kernel: [drm] Connector 0:
Mar 19 19:01:58 calvin kernel: [drm] LVDS
Mar 19 19:01:58 calvin kernel: [drm] DDC: 0x6430 0x6430 0x6434
0x6434 0x6438 0x6438 0x643c 0x643c
Mar 19 19:01:58 calvin kernel: [drm] Encoders:
Mar 19 19:01:58 calvin kernel: [drm] LCD1: INTERNAL_UNIPHY
Mar 19 19:01:58 calvin kernel: [drm] Connector 1:
Mar 19 19:01:58 calvin kernel: [drm] DisplayPort
Mar 19 19:01:58 calvin kernel: [drm] HPD1
Mar 19 19:01:58 calvin kernel: [drm] DDC: 0x6460 0x6460 0x6464
0x6464 0x6468 0x6468 0x646c 0x646c
Mar 19 19:01:58 calvin kernel: [drm] Encoders:
Mar 19 19:01:58 calvin kernel: [drm] DFP1: INTERNAL_UNIPHY1
Mar 19 19:01:58 calvin kernel: [drm] Connector 2:
Mar 19 19:01:58 calvin kernel: [drm] DisplayPort
Mar 19 19:01:58 calvin kernel: [drm] HPD2
Mar 19 19:01:58 calvin kernel: [drm] DDC: 0x6440 0x6440 0x6444
0x6444 0x6448 0x6448 0x644c 0x644c
Mar 19 19:01:58 calvin kernel: [drm] Encoders:
Mar 19 19:01:58 calvin kernel: [drm] DFP2: INTERNAL_UNIPHY1
Mar 19 19:01:58 calvin kernel: [drm] Connector 3:
Mar 19 19:01:58 calvin kernel: [drm] DisplayPort
Mar 19 19:01:58 calvin kernel: [drm] HPD3
Mar 19 19:01:58 calvin kernel: [drm] DDC: 0x6450 0x6450 0x6454
0x6454 0x6458 0x6458 0x645c 0x645c
Mar 19 19:01:58 calvin kernel: [drm] Encoders:
Mar 19 19:01:58 calvin kernel: [drm] DFP3: INTERNAL_UNIPHY2
Mar 19 19:01:58 calvin kernel: [drm] Connector 4:
Mar 19 19:01:58 calvin kernel: [drm] VGA
Mar 19 19:01:58 calvin kernel: [drm] DDC: 0x64d8 0x64d8 0x64dc
0x64dc 0x64e0 0x64e0 0x64e4 0x64e4
Mar 19 19:01:58 calvin kernel: [drm] Encoders:
Mar 19 19:01:58 calvin kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Mar 19 19:01:58 calvin kernel: [drm] Internal thermal controller with
fan control
Mar 19 19:01:58 calvin kernel: [drm] radeon: power management initialized
Mar 19 19:01:58 calvin kernel: [drm:radeon_atom_encoder_dpms], encoder
dpms 30 to mode 3, devices 00000002, active_devices 00000000
Thanks for any hint or pointer and forgive me if I missed some
obvious solution while googling :)
PS: just in case: CC:me as I'm not subscribed to this list. Thanks again.
--
Fabio
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.4
From: Arnd Bergmann @ 2012-03-19 16:24 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Florian Tobias Schandinat, linux-omap, linux-fbdev
In-Reply-To: <1332154865.2144.57.camel@deskari>
On Monday 19 March 2012, Tomi Valkeinen wrote:
> Here are the changes for OMAP DSS driver for v3.4.
>
> There's an issue with the dss driver that appears on arm-soc/for-next
> branch, which I'm still solving
> (http://marc.info/?l=linux-omap&m\x133214966902577&w=2). I hope to get
> fix for that ready and merged for -rc1, but I'm not sure if I can make
> it in time, so I wanted to sent this pull request already.
>
> Arnd, as discussed before, you can also merge this branch to solve the
> conflicts between arm-soc and omapdss trees.
>
> Note that this is the first pull request I've sent with a branch that I
> have not been rebasing, so please check that the branch looks sane.
Thanks Tomi,
I've looked at the specific conflicts again, and it seems that the only
conflicting commit in arm-soc is 2e3ee9f45b "ARM: OMAP1: Move most of
plat/io.h into local iomap.h". I'm planning to send that one very early,
as soon as Russell has his first set up patches merged, so I don't
actually have to resolve the conflict here unless Florian is also
there early.
Florian, if I end up being faster than you, feel free to pull the
omap/cleanup branch from git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
if you want to get a conflict resolution using the minimum set of patches
from upstream. Alternatively, pulling "cleanup" from
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap should give you
the same.
Arnd
^ permalink raw reply
* Re: [PATCH 2/2] OMAPDSS: TPO-TD03MTEA1: Correct comment for power on delay
From: Grazvydas Ignotas @ 2012-03-19 16:06 UTC (permalink / raw)
To: Mark Brown
Cc: Tomi Valkeinen, Florian Tobias Schandinat, linux-omap,
linux-fbdev
In-Reply-To: <1332169352-5076-2-git-send-email-broonie@opensource.wolfsonmicro.com>
On Mon, Mar 19, 2012 at 5:02 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> Since any power on stabilisation delay for the supply itself should be
> taken care of transparently by the regulator API when the regulator is
> enabled the additional delay that the TPO-TD03MTEA1 driver adds after
> that returned should be due to the requirements of the device itself
> rather than the supply (the delay is also suspicously long for one for
> a regulator to ramp).
True, it came from panel's datasheet which asks to wait for ">10ms + 7
vsyncs" after tuning on the supply and before switching the control
signal.
> Correct the comment to avoid misleading people
> taking this code as a reference.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> .../video/omap2/displays/panel-tpo-td043mtea1.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
FWIW:
Acked-by: Grazvydas Ignotas <notasas@gmail.com>
--
Gražvydas
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: TPO-TD03MTEA1: Check for errors from regulator_enable()
From: Grazvydas Ignotas @ 2012-03-19 16:01 UTC (permalink / raw)
To: Mark Brown
Cc: Tomi Valkeinen, Florian Tobias Schandinat, linux-omap,
linux-fbdev
In-Reply-To: <1332169352-5076-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On Mon, Mar 19, 2012 at 5:02 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> It is possible for regulator_enable() to fail and if it does fail that's
> generally a bad sign for anything we try to do with the hardware afterwards
> so check for and immediately return an error if regulator_enable() fails.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> .../video/omap2/displays/panel-tpo-td043mtea1.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
FWIW:
Acked-by: Grazvydas Ignotas <notasas@gmail.com>
--
Gražvydas
^ permalink raw reply
* [PATCH 2/2] OMAPDSS: TPO-TD03MTEA1: Correct comment for power on delay
From: Mark Brown @ 2012-03-19 15:02 UTC (permalink / raw)
To: Tomi Valkeinen, Florian Tobias Schandinat
Cc: Grazvydas Ignotas, linux-omap, linux-fbdev, Mark Brown
In-Reply-To: <1332169352-5076-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Since any power on stabilisation delay for the supply itself should be
taken care of transparently by the regulator API when the regulator is
enabled the additional delay that the TPO-TD03MTEA1 driver adds after
that returned should be due to the requirements of the device itself
rather than the supply (the delay is also suspicously long for one for
a regulator to ramp). Correct the comment to avoid misleading people
taking this code as a reference.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
.../video/omap2/displays/panel-tpo-td043mtea1.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 74c6b87..987cb84 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -281,7 +281,7 @@ static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
if (r != 0)
return r;
- /* wait for regulator to stabilize */
+ /* wait for panel to stabilize */
msleep(160);
if (gpio_is_valid(nreset_gpio))
--
1.7.9.1
^ permalink raw reply related
* [PATCH 1/2] OMAPDSS: TPO-TD03MTEA1: Check for errors from regulator_enable()
From: Mark Brown @ 2012-03-19 15:02 UTC (permalink / raw)
To: Tomi Valkeinen, Florian Tobias Schandinat
Cc: Grazvydas Ignotas, linux-omap, linux-fbdev, Mark Brown
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
.../video/omap2/displays/panel-tpo-td043mtea1.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 32f3fcd..74c6b87 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -272,11 +272,14 @@ static const struct omap_video_timings tpo_td043_timings = {
static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
{
int nreset_gpio = tpo_td043->nreset_gpio;
+ int r;
if (tpo_td043->powered_on)
return 0;
- regulator_enable(tpo_td043->vcc_reg);
+ r = regulator_enable(tpo_td043->vcc_reg);
+ if (r != 0)
+ return r;
/* wait for regulator to stabilize */
msleep(160);
--
1.7.9.1
^ permalink raw reply related
* [PATCH] OMAPDSS: VENC: Check for errors from regulator_enable()
From: Mark Brown @ 2012-03-19 14:56 UTC (permalink / raw)
To: Tomi Valkeinen, Florian Tobias Schandinat
Cc: linux-omap, linux-fbdev, Mark Brown
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/video/omap2/dss/venc.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 9c3daf7..abfbd4a 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -443,7 +443,9 @@ static int venc_power_on(struct omap_dss_device *dssdev)
dispc_set_digit_size(dssdev->panel.timings.x_res,
dssdev->panel.timings.y_res/2);
- regulator_enable(venc.vdda_dac_reg);
+ r = regulator_enable(venc.vdda_dac_reg);
+ if (r)
+ goto err;
if (dssdev->platform_enable)
dssdev->platform_enable(dssdev);
--
1.7.9.1
^ permalink raw reply related
* [PATCH] OMAP: DSS2: Remove suspicous and unused TAAL regulator API usage
From: Mark Brown @ 2012-03-19 14:50 UTC (permalink / raw)
To: Tomi Valkeinen, Florian Tobias Schandinat
Cc: linux-omap, linux-fbdev, Mark Brown
The TAAL driver contains some regulator support which is currently unused
(the code is there but the one panel supported by the driver doesn't have
any regulators provided). This code mostly looks like an open coded
version of the regulator core bulk API.
The only additional feature is that a voltage range can be set once when
the device is opened, though this is never varied at runtime. The general
expectation is that if the device is not actively managing the voltage of
the device (eg, doing DVFS) then any configuration will be done using the
constraints rather than by drivers, saving them code and ensuring that
they work well with systems where the voltage is not configurable.
If systems are added needing regulator support this can be added back in,
though it should be based on core features rather than open coding things.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/video/omap2/displays/panel-taal.c | 80 -----------------------------
1 files changed, 0 insertions(+), 80 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
index 0f21fa5..72d6307 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -30,7 +30,6 @@
#include <linux/gpio.h>
#include <linux/workqueue.h>
#include <linux/slab.h>
-#include <linux/regulator/consumer.h>
#include <linux/mutex.h>
#include <video/omapdss.h>
@@ -55,73 +54,6 @@ static int _taal_enable_te(struct omap_dss_device *dssdev, bool enable);
static int taal_panel_reset(struct omap_dss_device *dssdev);
-struct panel_regulator {
- struct regulator *regulator;
- const char *name;
- int min_uV;
- int max_uV;
-};
-
-static void free_regulators(struct panel_regulator *regulators, int n)
-{
- int i;
-
- for (i = 0; i < n; i++) {
- /* disable/put in reverse order */
- regulator_disable(regulators[n - i - 1].regulator);
- regulator_put(regulators[n - i - 1].regulator);
- }
-}
-
-static int init_regulators(struct omap_dss_device *dssdev,
- struct panel_regulator *regulators, int n)
-{
- int r, i, v;
-
- for (i = 0; i < n; i++) {
- struct regulator *reg;
-
- reg = regulator_get(&dssdev->dev, regulators[i].name);
- if (IS_ERR(reg)) {
- dev_err(&dssdev->dev, "failed to get regulator %s\n",
- regulators[i].name);
- r = PTR_ERR(reg);
- goto err;
- }
-
- /* FIXME: better handling of fixed vs. variable regulators */
- v = regulator_get_voltage(reg);
- if (v < regulators[i].min_uV || v > regulators[i].max_uV) {
- r = regulator_set_voltage(reg, regulators[i].min_uV,
- regulators[i].max_uV);
- if (r) {
- dev_err(&dssdev->dev,
- "failed to set regulator %s voltage\n",
- regulators[i].name);
- regulator_put(reg);
- goto err;
- }
- }
-
- r = regulator_enable(reg);
- if (r) {
- dev_err(&dssdev->dev, "failed to enable regulator %s\n",
- regulators[i].name);
- regulator_put(reg);
- goto err;
- }
-
- regulators[i].regulator = reg;
- }
-
- return 0;
-
-err:
- free_regulators(regulators, i);
-
- return r;
-}
-
/**
* struct panel_config - panel configuration
* @name: panel name
@@ -150,8 +82,6 @@ struct panel_config {
unsigned int low;
} reset_sequence;
- struct panel_regulator *regulators;
- int num_regulators;
};
enum {
@@ -977,11 +907,6 @@ static int taal_probe(struct omap_dss_device *dssdev)
atomic_set(&td->do_update, 0);
- r = init_regulators(dssdev, panel_config->regulators,
- panel_config->num_regulators);
- if (r)
- goto err_reg;
-
td->workqueue = create_singlethread_workqueue("taal_esd");
if (td->workqueue = NULL) {
dev_err(&dssdev->dev, "can't create ESD workqueue\n");
@@ -1075,8 +1000,6 @@ err_gpio:
err_bl:
destroy_workqueue(td->workqueue);
err_wq:
- free_regulators(panel_config->regulators, panel_config->num_regulators);
-err_reg:
kfree(td);
err:
return r;
@@ -1113,9 +1036,6 @@ static void __exit taal_remove(struct omap_dss_device *dssdev)
/* reset, to be sure that the panel is in a valid state */
taal_hw_reset(dssdev);
- free_regulators(td->panel_config->regulators,
- td->panel_config->num_regulators);
-
kfree(td);
}
--
1.7.9.1
^ permalink raw reply related
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Dmitry Eremin-Solenikov @ 2012-03-19 14:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-fbdev, Florian Tobias Schandinat, Tony Breeds, linuxppc-dev
In-Reply-To: <1332103797.3105.202.camel@pasglop>
On Mon, Mar 19, 2012 at 12:49 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sun, 2012-03-18 at 18:04 +0400, Dmitry Eremin-Solenikov wrote:
>> On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>> > On Sat, 2012-03-17 at 20:04 +0400, Dmitry Eremin-Solenikov wrote:
>> >> Hello,
>> >>
>> >> I'm trying to make framebuffer to work on PPC460EX board (canyonlands).
>> >>
>> >> The peculiarity of this platform is the fact that it has
>> >> sizeof(unsigned long) = 4,
>> >> but physical address on it is 36 bits width. It is a common to various pieces
>> >> of the code to expect that unsigned long variable is able to contain physical
>> >> address. Most of those places are easy to fix.
>> >
>> > Yes. In fact, Tony (CC) has some patches to fix a lot of the DRM
>> > infrastructure (we have radeon KMS working on a similar platform).
>>
>> That is interesting! Are those patches published or otherwise available
>> somewhere? We are also very interested in enabling Canyonlands
>> with Radeon KMS!
>
> You will run into additional problems with 460 due to the fact that it's
> not cache coherent for DMA. Tony patches don't address that part of the
> problem (they were used on a 476 based platform).
Hmm. Could you please spill a little bit more of details? Also are those patches
for 476 merged or present somewhere?
>
>> > In fact, we could make the new structure such that it doesn't break
>> > userspace compatibility with 64-bit architectures at all, ie, the "new"
>> > and "compat" ioctl could remain entirely equivalent on 64-bit.
>>
>> I remember stuff about compat_ioctl, but I have never used/implemented
>> that. Are there any details of requirements for the structures being passed?
>
> In that specific case, I meant something else. IE. The old ioctl could
> remain unchanged, and the new ioctl make the same as the old one on
> 64-bit platforms.
I don't think this kind of magic would be good. I'd just stick to the new
ioctl.
>
> Cheers,
> Ben.
>
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-19 11:45 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332122514.10557.270.camel@linux-s257.site>
> For the maximum level causes blank screen...
>
> Please kindly help to identify which driver handle the brightness
> change, run the following 2 commands:
>
> # echo 5 > /sys/class/backlight/acer-wmi/brightness
> # echo 5 > /sys/class/backlight/intel_backlight/brightness
>
> Which one works to change brightness on your machine?
Both of them do not work for me.Only hot keys are working.
Writing to /sys/class/backlight/acer-wmi/brightness
and /sys/class/backlight/intel_backlight/brightness do not cause any
change in brightness.
Regards ,
Pradeep Subrahmanion
>
>
> Thanks a lot!
> Joey Lee
^ permalink raw reply
* [GIT PULL] OMAP DSS for v3.4
From: Tomi Valkeinen @ 2012-03-19 11:01 UTC (permalink / raw)
To: Florian Tobias Schandinat, Arnd Bergmann; +Cc: linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 7590 bytes --]
Hi Florian, Arnd,
Here are the changes for OMAP DSS driver for v3.4.
There's an issue with the dss driver that appears on arm-soc/for-next
branch, which I'm still solving
(http://marc.info/?l=linux-omap&m=133214966902577&w=2). I hope to get
fix for that ready and merged for -rc1, but I'm not sure if I can make
it in time, so I wanted to sent this pull request already.
Arnd, as discussed before, you can also merge this branch to solve the
conflicts between arm-soc and omapdss trees.
Note that this is the first pull request I've sent with a branch that I
have not been rebasing, so please check that the branch looks sane.
Tomi
The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7:
Linux 3.3 (2012-03-18 16:15:34 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-3.4
Archit Taneja (2):
OMAPDSS: Features: Maintain dss_feats as a list
OMAPDSS: DISPC: Fix scaling constraints for OMAP4
Danny Kukawka (1):
OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4
Grazvydas Ignotas (2):
OMAPDSS: TPO-TD03MTEA1: fix suspend hang
OMAPDSS: TPO-TD03MTEA1: update default gamma
Julia Lawall (1):
OMAPDSS: use devm_ functions
Lajos Molnar (3):
OMAPDSS: DISPC: Fix OMAP4 supported color formats
OMAPDSS: DISPC: Fix FIR coefficients
OMAPDSS: MANAGER/APPLY: Add runtime_pm protection around wait_for_go/vsync functions
Mythri P K (6):
OMAPDSS: HDMI: remove duplicate video interface code
OMAPDSS: HDMI: update static timing table
OMAPDSS: HDMI: change the timing match logic
OMAPDSS: HDMI: remove duplicate code and mode parameter
OMAPDSS: HDMI: Move Avi-infoframe struct to hdmi_ip_data
OMAPDSS: HDMI: Add M2 divider while calculating clkout
Ricardo Neri (4):
OMAPDSS: HDMI: Correct source of the pixel clock in ACR calculation
OMAPDSS: Add DSS feature for HDMI MCLK for audio
OMAPDSS: HDMI: Implement initialization of MCLK
OMAPDSS: HDMI: Modify logic to configure MCLK
Tomi Valkeinen (29):
OMAPDSS: FEAT: Add FIFO_MERGE feature
OMAPDSS: APPLY: add fifo merge support funcs
OMAPDSS: APPLY: add fifo-merge support
OMAPDSS: DISPC: print fifo threshold values in bytes
OMAPDSS: DISPC: move fifo threhold calc to dispc.c
OMAPDSS: DISPC: Add naive threshold calc for fifomerge
Merge branch 'work/fifomerge'
Merge commit 'v3.3-rc4'
OMAPDSS: cleanup probe functions
OMAPFB: remove old blizzard driver
OMAPFB: Remove OMAP2/3 support from old omapfb driver
OMAPDSS: Remove video SRAM support
OMAPFB: Remove video SRAM support (old omapfb)
OMAP2+: remove unneeded #include omapfb.h
OMAP: N770: remove HWA742 platform data
OAMPFB: remove unused omapfb_set_ctrl_platform_data()
OMAPFB: remove early mem alloc from old omapfb
OMAPFB: remove mem info from platform_data
OMAPFB: remove unused fb_format_to_dss_mode()
OMAPFB: Move old omapfb private structs to a private include file
OMAPFB: remove omapfb_set_platform_data()
OMAP1: pass LCD config with omapfb_set_lcd_config()
OMAP: Remove OMAP_TAG_LCD and OMAP_TAG_FBMEM
OMAP1: Remove unused LCD devices from board files
OMAPFB: remove remaining OMAP arch checks
Merge branch 'work/old-omapfb-removal'
Merge commit 'v3.3-rc6'
OMAPDSS: APPLY: print warning if wait_pending_extra_info_updates fails
OMAPDSS: APPLY: fix clearing shadow dirty flag with manual update
Tony Lindgren (1):
ARM: OMAP2+: Fix compile error when FB_OMAP2 is not set
Yegor Yefremov (1):
OMAPDSS: add Innolux AT080TN52 display support
arch/arm/mach-omap1/board-ams-delta.c | 9 +-
arch/arm/mach-omap1/board-fsample.c | 15 +-
arch/arm/mach-omap1/board-h2.c | 15 +-
arch/arm/mach-omap1/board-h3.c | 9 +-
arch/arm/mach-omap1/board-htcherald.c | 9 +-
arch/arm/mach-omap1/board-innovator.c | 11 +-
arch/arm/mach-omap1/board-nokia770.c | 19 +-
arch/arm/mach-omap1/board-osk.c | 14 +-
arch/arm/mach-omap1/board-palmte.c | 10 +-
arch/arm/mach-omap1/board-palmtt.c | 10 +-
arch/arm/mach-omap1/board-palmz71.c | 10 +-
arch/arm/mach-omap1/board-perseus2.c | 15 +-
arch/arm/mach-omap1/board-sx1.c | 16 +-
arch/arm/mach-omap2/io.c | 1 -
arch/arm/plat-omap/common.c | 2 -
arch/arm/plat-omap/fb.c | 334 +----
arch/arm/plat-omap/fb.h | 10 -
arch/arm/plat-omap/include/plat/blizzard.h | 12 -
arch/arm/plat-omap/include/plat/board.h | 2 -
arch/arm/plat-omap/include/plat/hwa742.h | 8 -
arch/arm/plat-omap/include/plat/vram.h | 21 +-
drivers/video/omap/Kconfig | 16 +-
drivers/video/omap/Makefile | 12 +-
drivers/video/omap/blizzard.c | 1648 --------------------
drivers/video/omap/dispc.c | 1547 ------------------
drivers/video/omap/dispc.h | 46 -
drivers/video/omap/hwa742.c | 21 +-
drivers/video/omap/omapfb.h | 25 +-
drivers/video/omap/omapfb_main.c | 30 +-
drivers/video/omap/rfbi.c | 598 -------
drivers/video/omap2/displays/panel-generic-dpi.c | 23 +
.../video/omap2/displays/panel-tpo-td043mtea1.c | 153 ++-
drivers/video/omap2/dss/apply.c | 275 +++-
drivers/video/omap2/dss/dispc.c | 121 +-
drivers/video/omap2/dss/dispc_coefs.c | 9 +-
drivers/video/omap2/dss/display.c | 10 -
drivers/video/omap2/dss/dsi.c | 65 +-
drivers/video/omap2/dss/dss.c | 17 +-
drivers/video/omap2/dss/dss.h | 10 +-
drivers/video/omap2/dss/dss_features.c | 181 ++-
drivers/video/omap2/dss/dss_features.h | 54 +-
drivers/video/omap2/dss/hdmi.c | 278 ++--
drivers/video/omap2/dss/manager.c | 12 +-
drivers/video/omap2/dss/rfbi.c | 36 +-
drivers/video/omap2/dss/ti_hdmi.h | 56 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 94 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 47 -
drivers/video/omap2/dss/venc.c | 32 +-
drivers/video/omap2/omapfb/omapfb-ioctl.c | 2 +-
drivers/video/omap2/omapfb/omapfb-main.c | 101 +--
drivers/video/omap2/vram.c | 99 +--
include/linux/omapfb.h | 32 +-
52 files changed, 1001 insertions(+), 5201 deletions(-)
delete mode 100644 arch/arm/plat-omap/fb.h
delete mode 100644 arch/arm/plat-omap/include/plat/blizzard.h
delete mode 100644 arch/arm/plat-omap/include/plat/hwa742.h
delete mode 100644 drivers/video/omap/blizzard.c
delete mode 100644 drivers/video/omap/dispc.c
delete mode 100644 drivers/video/omap/dispc.h
delete mode 100644 drivers/video/omap/rfbi.c
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox