* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-18 5:24 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1331798740.10557.245.camel@linux-s257.site>
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
brightness after maximum level causes blank screen.So I am trying it
sort it out.
Thank you ,
Pradeep Subrahmanion
>
>
> Thanks a lot!
> Joey Lee
>
>
> >From 038bd3c4e53b7195f34e9d46c999b8dcb279da5e Mon Sep 17 00:00:00 2001
> From: "Lee, Chun-Yi" <jlee@suse.com>
> Date: Thu, 15 Mar 2012 16:03:45 +0800
> Subject: [PATCH] acer-wmi: Add quirk table for video backlight vendor mode
>
> Add quirk table for video backlight vendor mode
>
> Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
> ---
> drivers/acpi/video_detect.c | 27 +++++++++++++++++++++++++++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index f3f0fe7..acb15d6 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -132,6 +132,32 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv)
> return AE_OK;
> }
>
> +static int video_set_backlight_vendor(const struct dmi_system_id *d)
> +{
> + acpi_video_support |= ACPI_VIDEO_BACKLIGHT_DMI_VENDOR;
> + return 0;
> +}
> +
> +static const struct dmi_system_id video_vendor_dmi_table[] = {
> + {
> + .callback = video_set_backlight_vendor,
> + .ident = "Acer Aspire 4736",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 4736"),
> + },
> + },
> + {
> + .callback = video_set_backlight_vendor,
> + .ident = "Acer TravelMate 4750",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
> + },
> + },
> + {}
> +};
> +
> /*
> * Returns the video capabilities of a specific ACPI graphics device
> *
> @@ -164,6 +190,7 @@ long acpi_video_get_capabilities(acpi_handle graphics_handle)
> * ACPI_VIDEO_BACKLIGHT_DMI_VENDOR;
> *}
> */
> + dmi_check_system(video_vendor_dmi_table);
> } else {
> status = acpi_bus_get_device(graphics_handle, &tmp_dev);
> if (ACPI_FAILURE(status)) {
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Dmitry Eremin-Solenikov @ 2012-03-18 14:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-fbdev, Florian Tobias Schandinat, Tony Breeds, linuxppc-dev
In-Reply-To: <1332031585.3105.197.camel@pasglop>
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!
>
>> The problem I'm stuck with is a fb_mmap() code. To find a right memory to map
>> it uses information from struct fb_fix_screeninfo provided by the driver.
>> This structure uses two unsigned long fields to hold physical addresses
>> (smem_start and mmio_start). It would be easy to change that structure
>> to use phys_addr_t instead of unsigned long, but this structure is a part
>> of userspace ABI. It is returned to userspace on FBIOGET_FSCREENINFO ioctl.
>> And now I'm stuck with it.
>
> It's an old problem, which I think we described a while back on the
> list. Back then the conclusion was to make a new version with a proper
> __u64, a new ioctl to access is, and a "compatible" ioctl that blanks
> the address fields (or fails) if they contain a value >32-bit.
>
> We just never got to actually implement it.
I see. I will try to prepare patches.
>
> 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?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Benjamin Herrenschmidt @ 2012-03-18 20:49 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: linux-fbdev, Florian Tobias Schandinat, Tony Breeds, linuxppc-dev
In-Reply-To: <CALT56yOaxfWYwxvBDbo9dpWo9y37dO0iGge4x6kciZp1oXXHVw@mail.gmail.com>
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).
> > 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.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Jingoo Han @ 2012-03-18 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEYLNCpJU_5uVa-jo5HUNY8Av6eYaiow1gEZtHCiQZ5oKkGoMQ@mail.gmail.com>
> -----Original Message-----
> From: linux-samsung-soc-owner@vger.kernel.org [mailto:linux-samsung-soc-owner@vger.kernel.org] On Behalf
> Of Darius Augulis
> Sent: Friday, March 16, 2012 7:19 PM
> To: Jingoo Han
> Cc: Thomas Abraham; linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-
> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; ben-linux@fluff.org; patches@linaro.org;
> kgene.kim@samsung.com; Kyungmin Park; JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter
> Korsgaard; Maurus Cuelenaere; Tushar Behera
> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>
> On Fri, Mar 16, 2012 at 11:48 AM, Jingoo Han <jg1.han@samsung.com> wrote:
> >> > It's just bug.
> >> >
> >> > struct s3c_fb_pd_win should be used for windows of FIMD IP.
> >> > It should not be used for selecting multi-LCDs.
> >>
> >> why not? s3c_fb_pd_win contains timing values which depend directly on
> >> LCD size and resolution.
> >> Please look into the code again - mini6410 doesn't use platform data
> >> so select different LCD sizes.
> >> It has only single window in platform data - exactly what you want.
> >> Now tell my, why you are arguing, that this platform data cannot be
> >> rewritten dynamically by board setup routines at kernel startup time?
> >> Many ARM architectures are doing the same - takes kernel command line
> >> argument to select LCD and passes necessary data for its fb drivers
> >> via platform data structures. It not a bug, it's correct approach to
> >> support different sizes of LCD display for the same board.
> >
> >
> > Hey, it is not my point.
> > To take kernel command line is not problem to support multiple LCDs.
> >
> > My point is that s3c_fb_pd_win should not include variable LCD option.
> > So, if you want to support multiple LCDs, you should use another variable,
> > instead of using s3c_fb_pd_win[0] and s3c_fb_pd_win[1] as 4.3" LCD, 7.0" LCD.
>
> But I use s3c_fb_pd_win only as container to hold timing values in
> board setup code.
> s3c-fb platform data has only single window and does not perform any
> LCD selection.
> What is wrong here? You suggest to declare some custom structure to
> hold these timing values? What's the point?
>
> >
> > You use s3c_fb_pd_win[0], s3c_fb_pd_win[1] as 4.3" LCD, 7.0" LCD.
> > However, s3c_fb_pd_win[0], s3c_fb_pd_win[1] means the windows of FIMD IP.
>
> There is no multiple windows in platform data! driver sees only single
> window. And this wont change in any way if you drop LCD selection from
> board setup code.
> Driver will see the same single window. So - your are arguing, that
> board setup code sets platform data in bad way. I don't accept your
> opinion, because tens of boards are doing the same and nobody call it
> bug.
Because there are not multiple windows and driver sees only single window as you mentiond,
Only 'struct s3c_fb_pd_win mini6410_fb_win[0]' should be used and
'struct s3c_fb_pd_win mini6410_fb_win[1]' should not be used.
s3c_fb_pd_win[0] means window 0 of FIMD IP, s3c_fb_pd_win[1] means window 1 of FIMD IP.
Therefore, if mini6410_fb_win[0] and mini6410_fb_win[1] are included, it means that
2 windows of FIMD IP are used in single LCD.
If you want to support multiple LCDs, you should use struct s3c_fb_platdata[0], struct s3c_fb_platdata[1],
because 'struct s3c_fb_platdata' means LCD panel.
If you understand the purpose of s3c_fb_platdata and s3c_fb_pd_win, you should do, at least, as below.
static struct s3c_fb_pd_win mini6410_fb_lcd0_win[] = {
{
.win_mode = { /* 4.3" 480x272 */
.left_margin = 3,
.right_margin = 2,
.upper_margin = 1,
.lower_margin = 1,
.hsync_len = 40,
.vsync_len = 1,
.xres = 480,
.yres = 272,
},
.max_bpp = 32,
.default_bpp = 16,
},
};
static struct s3c_fb_platdata mini6410_lcd_pdata[0] __initdata = {
.setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
.win[0] = &mini6410_fb_lcd0_win[0],
.vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
.vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
};
static struct s3c_fb_pd_win mini6410_fb_lcd1_win[] = {
{
.win_mode = { /* 7.0" 800x480 */
.left_margin = 8,
.right_margin = 13,
.upper_margin = 7,
.lower_margin = 5,
.hsync_len = 3,
.vsync_len = 1,
.xres = 800,
.yres = 480,
},
.max_bpp = 32,
.default_bpp = 16,
},
};
static struct s3c_fb_platdata mini6410_lcd_pdata[1] __initdata = {
.setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
.win[0] = &mini6410_fb_lcd1_win[0],
.vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
.vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
};
Each struct means:
mini6410_lcd_pdata[0]: 4.3" 480x272 LCD
mini6410_fb_lcd0_win[0]: window 0 used for 4.3" 480x272 LCD
mini6410_lcd_pdata[1]: 7.0" 800x480 LCD
mini6410_fb_lcd1_win[0]: window 0 used for 7.0" 800x480 LCD
In this case, 4.3" or 7.0" LCD can be selected using mini6410_lcd_pdata[], instead of selecting mini6410_fb_win[0] or
mini6410_fb_win[1].
My point is that 's3c_fb_platdata and s3c_fb_pd_win should be used exactly'.
>
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: Wang YanQing @ 2012-03-19 0:30 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, Michal Januszewski,
Florian Tobias Schandinat, linux-fbdev, x86, Andrew Morton
In-Reply-To: <4F5FAE63.3090908@xenotime.net>
On Tue, Mar 13, 2012 at 01:30:27PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Export 'pcibios_enabled' so that when uvesafb is built as a
> loadable module (on X86_32), the build will succeed.
>
> ERROR: "pcibios_enabled" [drivers/video/uvesafb.ko] undefined!
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Cc: Michal Januszewski <spock@gentoo.org>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: x86@kernel.org
> ---
> Applies to mainline; found in linux-next.
>
> arch/x86/pci/pcbios.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20120313.orig/arch/x86/pci/pcbios.c
> +++ linux-next-20120313/arch/x86/pci/pcbios.c
> @@ -27,6 +27,7 @@
> #define PCIBIOS_HW_TYPE2_SPEC 0x20
>
> int pcibios_enabled;
> +EXPORT_SYMBOL(pcibios_enabled);
>
> /* According to the BIOS specification at:
> * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
> --
> 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/
Hi, could you resend this patch as EXPORT_SYMBOL_GPL to x86 architecture maintainer?
Looks at the MAINTAINERS for the below:
X86 ARCHITECTURE (32-BIT AND 64-BIT)
M: Thomas Gleixner <tglx@linutronix.de>
M: Ingo Molnar <mingo@redhat.com>
M: "H. Peter Anvin" <hpa@zytor.com>
M: x86@kernel.org
^ permalink raw reply
* [PATCH v2] x86: export 'pcibios_enabled' as GPL
From: Randy Dunlap @ 2012-03-19 1:03 UTC (permalink / raw)
To: Wang YanQing, Stephen Rothwell, linux-next, LKML,
Michal Januszewski, Florian Tobias Schandinat, linux-fbdev, x86,
Andrew Morton
In-Reply-To: <20120319003044.GA3744@udknight>
From: Randy Dunlap <rdunlap@xenotime.net>
Export 'pcibios_enabled' so that when uvesafb is built as a
loadable module (on X86_32), the build will succeed.
ERROR: "pcibios_enabled" [drivers/video/uvesafb.ko] undefined!
Patch v2 uses EXPORT_SYMBOL_GPL() as requested.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Michal Januszewski <spock@gentoo.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Cc: x86@kernel.org
---
arch/x86/pci/pcbios.c | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20120313.orig/arch/x86/pci/pcbios.c
+++ linux-next-20120313/arch/x86/pci/pcbios.c
@@ -27,6 +27,7 @@
#define PCIBIOS_HW_TYPE2_SPEC 0x20
int pcibios_enabled;
+EXPORT_SYMBOL_GPL(pcibios_enabled);
/* According to the BIOS specification at:
* http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-19 2:01 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332047432.6304.13.camel@debian.Gayathri>
於 日，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.
> brightness after maximum level causes blank screen.So I am trying it
> sort it out.
>
> Thank you ,
>
> 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?
Thanks a lot!
Joey Lee
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Darius Augulis @ 2012-03-19 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwQmJvx_uGZKbAJ9uds-ciLs2VDqcifhoqB-P0M5uhO-nA@mail.gmail.com>
Hi,
On Mon, Mar 19, 2012 at 9:29 AM, Thomas Abraham
<thomas.abraham@linaro.org> wrote:
> Hi Darius,
>
> On 19 March 2012 05:16, Jingoo Han <jg1.han@samsung.com> wrote:
> [...]
>
>>
>> Because there are not multiple windows and driver sees only single window as you mentiond,
>> Only 'struct s3c_fb_pd_win mini6410_fb_win[0]' should be used and
>> 'struct s3c_fb_pd_win mini6410_fb_win[1]' should not be used.
>> s3c_fb_pd_win[0] means window 0 of FIMD IP, s3c_fb_pd_win[1] means window 1 of FIMD IP.
>>
>> Therefore, if mini6410_fb_win[0] and mini6410_fb_win[1] are included, it means that
>> 2 windows of FIMD IP are used in single LCD.
>>
>> If you want to support multiple LCDs, you should use struct s3c_fb_platdata[0], struct s3c_fb_platdata[1],
>> because 'struct s3c_fb_platdata' means LCD panel.
>>
>> If you understand the purpose of s3c_fb_platdata and s3c_fb_pd_win, you should do, at least, as below.
>>
>> static struct s3c_fb_pd_win mini6410_fb_lcd0_win[] = {
>> {
>> .win_mode = { /* 4.3" 480x272 */
>> .left_margin = 3,
>> .right_margin = 2,
>> .upper_margin = 1,
>> .lower_margin = 1,
>> .hsync_len = 40,
>> .vsync_len = 1,
>> .xres = 480,
>> .yres = 272,
>> },
>> .max_bpp = 32,
>> .default_bpp = 16,
>> },
>> };
>>
>> static struct s3c_fb_platdata mini6410_lcd_pdata[0] __initdata = {
>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
>> .win[0] = &mini6410_fb_lcd0_win[0],
>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>> };
>>
>> static struct s3c_fb_pd_win mini6410_fb_lcd1_win[] = {
>> {
>> .win_mode = { /* 7.0" 800x480 */
>> .left_margin = 8,
>> .right_margin = 13,
>> .upper_margin = 7,
>> .lower_margin = 5,
>> .hsync_len = 3,
>> .vsync_len = 1,
>> .xres = 800,
>> .yres = 480,
>> },
>> .max_bpp = 32,
>> .default_bpp = 16,
>> },
>> };
>>
>> static struct s3c_fb_platdata mini6410_lcd_pdata[1] __initdata = {
>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
>> .win[0] = &mini6410_fb_lcd1_win[0],
>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>> };
>>
>> Each struct means:
>> mini6410_lcd_pdata[0]: 4.3" 480x272 LCD
>> mini6410_fb_lcd0_win[0]: window 0 used for 4.3" 480x272 LCD
>>
>> mini6410_lcd_pdata[1]: 7.0" 800x480 LCD
>> mini6410_fb_lcd1_win[0]: window 0 used for 7.0" 800x480 LCD
>>
>> In this case, 4.3" or 7.0" LCD can be selected using mini6410_lcd_pdata[], instead of selecting mini6410_fb_win[0] or
>> mini6410_fb_win[1].
>>
>> My point is that 's3c_fb_platdata and s3c_fb_pd_win should be used exactly'.
>
> I agree with solution which Jingoo Han has proposed. Instead of
> selecting one instance of s3c_fb_pd_win over the other at runtime, the
> features->lcd_index can be used to select one of the instances of
> platform data for s3c-fb driver.
I agree with it too. Would you make such patch based on your s3c-fb patch set?
Somebody should make it and definitely not to remove multiple LCD
suport for these boards.
>
> s3c_fb_pd_win is used to describe a window supported by the fimd
> controller. It is not meant to carry lcd timing information. The lcd
> panel timing remains the same irrespective of the window sizes. And
> this patchset is a step towards untangling window information and
> video timing.
Right now s3c_fb_pd_win contains exactly LCD timing values.
Your patch will move these timing values to struct fb_videomode.
I could make necessary patch for that too, but I think you will spend
less time doing it by yourself than syncing with me.
What do you think?
regards,
Darius
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Thomas Abraham @ 2012-03-19 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001501cd0561$57c642b0$0752c810$%han@samsung.com>
Hi Darius,
On 19 March 2012 05:16, Jingoo Han <jg1.han@samsung.com> wrote:
[...]
>
> Because there are not multiple windows and driver sees only single window as you mentiond,
> Only 'struct s3c_fb_pd_win mini6410_fb_win[0]' should be used and
> 'struct s3c_fb_pd_win mini6410_fb_win[1]' should not be used.
> s3c_fb_pd_win[0] means window 0 of FIMD IP, s3c_fb_pd_win[1] means window 1 of FIMD IP.
>
> Therefore, if mini6410_fb_win[0] and mini6410_fb_win[1] are included, it means that
> 2 windows of FIMD IP are used in single LCD.
>
> If you want to support multiple LCDs, you should use struct s3c_fb_platdata[0], struct s3c_fb_platdata[1],
> because 'struct s3c_fb_platdata' means LCD panel.
>
> If you understand the purpose of s3c_fb_platdata and s3c_fb_pd_win, you should do, at least, as below.
>
> static struct s3c_fb_pd_win mini6410_fb_lcd0_win[] = {
> {
> .win_mode = { /* 4.3" 480x272 */
> .left_margin = 3,
> .right_margin = 2,
> .upper_margin = 1,
> .lower_margin = 1,
> .hsync_len = 40,
> .vsync_len = 1,
> .xres = 480,
> .yres = 272,
> },
> .max_bpp = 32,
> .default_bpp = 16,
> },
> };
>
> static struct s3c_fb_platdata mini6410_lcd_pdata[0] __initdata = {
> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
> .win[0] = &mini6410_fb_lcd0_win[0],
> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> };
>
> static struct s3c_fb_pd_win mini6410_fb_lcd1_win[] = {
> {
> .win_mode = { /* 7.0" 800x480 */
> .left_margin = 8,
> .right_margin = 13,
> .upper_margin = 7,
> .lower_margin = 5,
> .hsync_len = 3,
> .vsync_len = 1,
> .xres = 800,
> .yres = 480,
> },
> .max_bpp = 32,
> .default_bpp = 16,
> },
> };
>
> static struct s3c_fb_platdata mini6410_lcd_pdata[1] __initdata = {
> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
> .win[0] = &mini6410_fb_lcd1_win[0],
> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> };
>
> Each struct means:
> mini6410_lcd_pdata[0]: 4.3" 480x272 LCD
> mini6410_fb_lcd0_win[0]: window 0 used for 4.3" 480x272 LCD
>
> mini6410_lcd_pdata[1]: 7.0" 800x480 LCD
> mini6410_fb_lcd1_win[0]: window 0 used for 7.0" 800x480 LCD
>
> In this case, 4.3" or 7.0" LCD can be selected using mini6410_lcd_pdata[], instead of selecting mini6410_fb_win[0] or
> mini6410_fb_win[1].
>
> My point is that 's3c_fb_platdata and s3c_fb_pd_win should be used exactly'.
I agree with solution which Jingoo Han has proposed. Instead of
selecting one instance of s3c_fb_pd_win over the other at runtime, the
features->lcd_index can be used to select one of the instances of
platform data for s3c-fb driver.
s3c_fb_pd_win is used to describe a window supported by the fimd
controller. It is not meant to carry lcd timing information. The lcd
panel timing remains the same irrespective of the window sizes. And
this patchset is a step towards untangling window information and
video timing.
(Apologizes for the delayed reply. I was out of office for last 4 days.)
Thanks,
Thomas.
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Thomas Abraham @ 2012-03-19 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEYLNCo0zyH9Nsf59UU-J4m=km+mKH1ym5a-9s7WthFpos6D+w@mail.gmail.com>
On 19 March 2012 13:10, Darius Augulis <augulis.darius@gmail.com> wrote:
> Hi,
>
> On Mon, Mar 19, 2012 at 9:29 AM, Thomas Abraham
> <thomas.abraham@linaro.org> wrote:
>> Hi Darius,
>>
>> On 19 March 2012 05:16, Jingoo Han <jg1.han@samsung.com> wrote:
>> [...]
>>
>>>
>>> Because there are not multiple windows and driver sees only single window as you mentiond,
>>> Only 'struct s3c_fb_pd_win mini6410_fb_win[0]' should be used and
>>> 'struct s3c_fb_pd_win mini6410_fb_win[1]' should not be used.
>>> s3c_fb_pd_win[0] means window 0 of FIMD IP, s3c_fb_pd_win[1] means window 1 of FIMD IP.
>>>
>>> Therefore, if mini6410_fb_win[0] and mini6410_fb_win[1] are included, it means that
>>> 2 windows of FIMD IP are used in single LCD.
>>>
>>> If you want to support multiple LCDs, you should use struct s3c_fb_platdata[0], struct s3c_fb_platdata[1],
>>> because 'struct s3c_fb_platdata' means LCD panel.
>>>
>>> If you understand the purpose of s3c_fb_platdata and s3c_fb_pd_win, you should do, at least, as below.
>>>
>>> static struct s3c_fb_pd_win mini6410_fb_lcd0_win[] = {
>>> {
>>> .win_mode = { /* 4.3" 480x272 */
>>> .left_margin = 3,
>>> .right_margin = 2,
>>> .upper_margin = 1,
>>> .lower_margin = 1,
>>> .hsync_len = 40,
>>> .vsync_len = 1,
>>> .xres = 480,
>>> .yres = 272,
>>> },
>>> .max_bpp = 32,
>>> .default_bpp = 16,
>>> },
>>> };
>>>
>>> static struct s3c_fb_platdata mini6410_lcd_pdata[0] __initdata = {
>>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
>>> .win[0] = &mini6410_fb_lcd0_win[0],
>>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
>>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>>> };
>>>
>>> static struct s3c_fb_pd_win mini6410_fb_lcd1_win[] = {
>>> {
>>> .win_mode = { /* 7.0" 800x480 */
>>> .left_margin = 8,
>>> .right_margin = 13,
>>> .upper_margin = 7,
>>> .lower_margin = 5,
>>> .hsync_len = 3,
>>> .vsync_len = 1,
>>> .xres = 800,
>>> .yres = 480,
>>> },
>>> .max_bpp = 32,
>>> .default_bpp = 16,
>>> },
>>> };
>>>
>>> static struct s3c_fb_platdata mini6410_lcd_pdata[1] __initdata = {
>>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
>>> .win[0] = &mini6410_fb_lcd1_win[0],
>>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
>>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>>> };
>>>
>>> Each struct means:
>>> mini6410_lcd_pdata[0]: 4.3" 480x272 LCD
>>> mini6410_fb_lcd0_win[0]: window 0 used for 4.3" 480x272 LCD
>>>
>>> mini6410_lcd_pdata[1]: 7.0" 800x480 LCD
>>> mini6410_fb_lcd1_win[0]: window 0 used for 7.0" 800x480 LCD
>>>
>>> In this case, 4.3" or 7.0" LCD can be selected using mini6410_lcd_pdata[], instead of selecting mini6410_fb_win[0] or
>>> mini6410_fb_win[1].
>>>
>>> My point is that 's3c_fb_platdata and s3c_fb_pd_win should be used exactly'.
>>
>> I agree with solution which Jingoo Han has proposed. Instead of
>> selecting one instance of s3c_fb_pd_win over the other at runtime, the
>> features->lcd_index can be used to select one of the instances of
>> platform data for s3c-fb driver.
>
> I agree with it too. Would you make such patch based on your s3c-fb patch set?
> Somebody should make it and definitely not to remove multiple LCD
> suport for these boards.
Sure. I will make a patch for that. I did not notice the way two lcd's
were supported in your code while preparing this patchset. Thanks for
bringing up this point.
>
>>
>> s3c_fb_pd_win is used to describe a window supported by the fimd
>> controller. It is not meant to carry lcd timing information. The lcd
>> panel timing remains the same irrespective of the window sizes. And
>> this patchset is a step towards untangling window information and
>> video timing.
>
> Right now s3c_fb_pd_win contains exactly LCD timing values.
> Your patch will move these timing values to struct fb_videomode.
>
> I could make necessary patch for that too, but I think you will spend
> less time doing it by yourself than syncing with me.
> What do you think?
Yes, I will prepare an additional patch in this series that will
maintain backward compatibility for real6410 and mini6410 with the
approach suggested by Jingoo Han. As I do not have either of these
boards, an ack from you would be very helpful when the next version of
this patchset is posted.
Thanks,
Thomas.
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Darius Augulis @ 2012-03-19 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwQY6C-+NUuYfmDyGoh0ahVa8_x1cai8MCfN_JjWh1k1Gg@mail.gmail.com>
On Mon, Mar 19, 2012 at 9:49 AM, Thomas Abraham
<thomas.abraham@linaro.org> wrote:
> On 19 March 2012 13:10, Darius Augulis <augulis.darius@gmail.com> wrote:
>> Right now s3c_fb_pd_win contains exactly LCD timing values.
>> Your patch will move these timing values to struct fb_videomode.
>>
>> I could make necessary patch for that too, but I think you will spend
>> less time doing it by yourself than syncing with me.
>> What do you think?
>
> Yes, I will prepare an additional patch in this series that will
> maintain backward compatibility for real6410 and mini6410 with the
> approach suggested by Jingoo Han. As I do not have either of these
> boards, an ack from you would be very helpful when the next version of
> this patchset is posted.
It's fine - I will review and probably test it.
^ 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
* 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
* 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
* [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
* [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 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 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
* 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
* 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: [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
* 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: 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
* 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: 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
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