On Tue, Aug 21, 2012 at 09:51:46AM -0400, Alex Deucher wrote:
> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti
> wrote:
> > Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
> > the machine. The likely culprit is commit 023e188e:
>
> yeah, vram is
On Tue, Aug 21, 2012 at 09:51:46AM -0400, Alex Deucher wrote:
> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
> > Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
> > the machine. The likely culprit is commit 023e188e:
>
> yeah, vram is locked
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
> > I see a big slow down during radeon driver initialization when the
> > screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
> > screen j
On Thu, Aug 16, 2012 at 11:51:10AM -0400, Alex Deucher wrote:
> I've gathered up the various outstanding radeon patches and put them
> up in a tree for testing:
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip
> Some of these may end up in -fixes, but most of them are -next
> mate
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
> > I see a big slow down during radeon driver initialization when the
> > screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
> > screen j
On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher wrote:
> I admit I'm not really an ACPI expert, but thinking about this more,
> I'm wondering if maybe we should just send the appropriate brightness
> change, switch display, etc. event to userspace rather than handling
> it directly in the radeon driv
On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote:
> On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
> > AMD ACPI interface may overload the standard event
> > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> > cases we don't
On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher wrote:
> I admit I'm not really an ACPI expert, but thinking about this more,
> I'm wondering if maybe we should just send the appropriate brightness
> change, switch display, etc. event to userspace rather than handling
> it directly in the radeon driv
On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote:
> On 三, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
> > AMD ACPI interface may overload the standard event
> > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> > cases we don't
which usually changes the
display configuration and messes up a dual-screen setup).
This patch gives the radeon driver the chance to examine the event and
block the keypress if the event is an "AMD event".
Signed-off-by: Luca Tettamanti
---
Any comment from ACPI front?
drive
k.
Looks ok, I lost one fix along the road though, I'm attaching the patch.
Luca
-- next part --
>From 0f71d5b56b9e5eee3194b5b926767511281ea0a6 Mon Sep 17 00:00:00 2001
From: Luca Tettamanti
Date: Wed, 1 Aug 2012 10:53:19 +0200
Subject: [PATCH] drm/radeon: fix, enabl
which usually changes the
display configuration and messes up a dual-screen setup).
This patch gives the radeon driver the chance to examine the event and
block the keypress if the event is an "AMD event".
Signed-off-by: Luca Tettamanti
---
Any comment from ACPI front?
drive
k.
Looks ok, I lost one fix along the road though, I'm attaching the patch.
Luca
>From 0f71d5b56b9e5eee3194b5b926767511281ea0a6 Mon Sep 17 00:00:00 2001
From: Luca Tettamanti
Date: Wed, 1 Aug 2012 10:53:19 +0200
Subject: [PATCH] drm/radeon: fix, enable notifications with device specific
On Tue, Jul 31, 2012 at 09:58:04AM -0400, Alex Deucher wrote:
> On Tue, Jul 31, 2012 at 5:16 AM, Luca Tettamanti
> wrote:
> > On Mon, Jul 30, 2012 at 10:45 PM, Alex Deucher
> > wrote:
> >> Regarding patches 3 and 4, it might be easier to just store a pointer
> &
I'm putting back the CC and adding Alex.
On Tue, Jul 31, 2012 at 5:07 PM, Pali Roh?r wrote:
> Thanks, now working. When I write to acpi video brightness file
> it change brightness and in dmesg is:
>
> [ 47.200998] [drm:radeon_atif_handler], event, device_class =
> video, type = 0xd0
> [ 47.2
On Tue, Jul 31, 2012 at 09:58:04AM -0400, Alex Deucher wrote:
> On Tue, Jul 31, 2012 at 5:16 AM, Luca Tettamanti wrote:
> > On Mon, Jul 30, 2012 at 10:45 PM, Alex Deucher
> > wrote:
> >> Regarding patches 3 and 4, it might be easier to just store a pointer
> >>
On Sat, Jul 28, 2012 at 4:47 PM, Pali Roh?r wrote:
> Hello, I have some good news. Radeon patches from this post
> http://lists.freedesktop.org/archives/dri-devel/2012-July/025535.html
> export brightness file /sys/class/backlight/radeon_bl/brightness
> And finally with these patches I'm able to c
On Mon, Jul 30, 2012 at 10:45 PM, Alex Deucher wrote:
> Regarding patches 3 and 4, it might be easier to just store a pointer
> to the relevant encoder when you verify ATIF rather than walking the
> encoder list every time.
Makes sense, I was unsure about the lifetime of the encoders, but
AFAICS
I'm putting back the CC and adding Alex.
On Tue, Jul 31, 2012 at 5:07 PM, Pali Rohár wrote:
> Thanks, now working. When I write to acpi video brightness file
> it change brightness and in dmesg is:
>
> [ 47.200998] [drm:radeon_atif_handler], event, device_class =
> video, type = 0xd0
> [ 47.2
On Sat, Jul 28, 2012 at 4:47 PM, Pali Rohár wrote:
> Hello, I have some good news. Radeon patches from this post
> http://lists.freedesktop.org/archives/dri-devel/2012-July/025535.html
> export brightness file /sys/class/backlight/radeon_bl/brightness
> And finally with these patches I'm able to c
On Mon, Jul 30, 2012 at 10:45 PM, Alex Deucher wrote:
> Regarding patches 3 and 4, it might be easier to just store a pointer
> to the relevant encoder when you verify ATIF rather than walking the
> encoder list every time.
Makes sense, I was unsure about the lifetime of the encoders, but
AFAICS
On Mon, Jul 30, 2012 at 10:30 PM, Alex Deucher wrote:
> On Mon, Jul 30, 2012 at 4:24 PM, Luca Tettamanti
> wrote:
>> On Mon, Jul 30, 2012 at 10:20:15AM -0400, Alex Deucher wrote:
>>> Supported DWORD Bit vector providing supported functions
>>> information. Ea
On Mon, Jul 30, 2012 at 10:20:15AM -0400, Alex Deucher wrote:
> On Sun, Jul 29, 2012 at 9:06 AM, Luca Tettamanti
> wrote:
> > On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
> >> On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti
> >> wrote:
> &g
On Mon, Jul 30, 2012 at 04:32:47PM +0800, joeyli wrote:
> ? ??2012-07-29 ? 15:10 +0200?Luca Tettamanti ???
> > On Sun, Jul 29, 2012 at 11:51:48AM +0800, joeyli wrote:
> > > Hi Luca,
> > >
> > > ? ??2012-07-28 ? 16:56 +0200?Luca Tettamanti ???
> > >
On Mon, Jul 30, 2012 at 10:30 PM, Alex Deucher wrote:
> On Mon, Jul 30, 2012 at 4:24 PM, Luca Tettamanti wrote:
>> On Mon, Jul 30, 2012 at 10:20:15AM -0400, Alex Deucher wrote:
>>> Supported DWORD Bit vector providing supported functions
>>> information. Each
On Mon, Jul 30, 2012 at 10:20:15AM -0400, Alex Deucher wrote:
> On Sun, Jul 29, 2012 at 9:06 AM, Luca Tettamanti wrote:
> > On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
> >> On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti
> >> wrote:
> >&
On Mon, Jul 30, 2012 at 04:32:47PM +0800, joeyli wrote:
> 於 日，2012-07-29 於 15:10 +0200，Luca Tettamanti 提到：
> > On Sun, Jul 29, 2012 at 11:51:48AM +0800, joeyli wrote:
> > > Hi Luca,
> > >
> > > 於 六，2012-07-28 於 16:56 +0200，Luca Tettamanti 提到：
> > >
Hi,
I'm attaching a first draft of my work. The first 3 patches are
infrastructure work, the fourth wires the notification handler and
retrieves the requests from the system BIOS, but it does not actually
change brightness yet.
The problem here is how to get the correct encoder: should I just scan
On Sun, Jul 29, 2012 at 11:51:48AM +0800, joeyli wrote:
> Hi Luca,
>
> ? ??2012-07-28 ? 16:56 +0200?Luca Tettamanti ???
> > I just found the first problem (probably a BIOS bug):
> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
> On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti
> wrote:
> > I just found the first problem (probably a BIOS bug):
> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
>
ly pointer
arithmetics, but it _might_ make it easier to read past the buffer if
one does not check the size before using the struct. What do you think?
Luca
>From e485a3a4075c25ba1747ad61f6168c3734d5f0a9 Mon Sep 17 00:00:00 2001
From: Luca Tettamanti
Date: Sun, 29 Jul 2012 17:04:43 +0200
Subject: [P
On Sun, Jul 29, 2012 at 11:51:48AM +0800, joeyli wrote:
> Hi Luca,
>
> 於 六，2012-07-28 於 16:56 +0200，Luca Tettamanti 提到：
> > I just found the first problem (probably a BIOS bug):
> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
> On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti wrote:
> > I just found the first problem (probably a BIOS bug):
> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
> &
On Thu, Jul 26, 2012 at 03:42:26PM -0400, Alex Deucher wrote:
> On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti
> wrote:
> > On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote:
> >> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti
> >> wrote:
> >
On Thu, Jul 26, 2012 at 03:42:26PM -0400, Alex Deucher wrote:
> On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti wrote:
> > On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote:
> >> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti
> >> wrote:
> >&g
On Fri, Jul 27, 2012 at 12:46:50PM +0800, joeyli wrote:
> ? ??2012-07-26 ? 23:31 -0400?Alex Deucher ???
> > On Thu, Jul 26, 2012 at 10:50 PM, joeyli wrote:
> > > ? ??2012-07-26 ? 14:58 +0200?Luca Tettamanti ???
> > >> - again ACPI video module gets
On Fri, Jul 27, 2012 at 12:46:50PM +0800, joeyli wrote:
> 於 四，2012-07-26 於 23:31 -0400，Alex Deucher 提到：
> > On Thu, Jul 26, 2012 at 10:50 PM, joeyli wrote:
> > > 於 四，2012-07-26 於 14:58 +0200，Luca Tettamanti 提到：
> > >> - again ACPI video module gets
On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote:
> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti
> wrote:
> > The other missing bit is how to actually change the brightness... Alex,
> > do you know what registers to poke?
>
> You need to check if the GP
On Wed, Jul 25, 2012 at 01:38:09PM -0400, alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> Add a new header that defines the AMD ACPI interface used
> for laptops, PowerXpress, and chipset specific functionality
> and update the current code to use it.
Great! Now my DSDT makes sense ;)
On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote:
> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti wrote:
> > The other missing bit is how to actually change the brightness... Alex,
> > do you know what registers to poke?
>
> You need to check if the GPU cont
On Wed, Jul 25, 2012 at 01:38:09PM -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Add a new header that defines the AMD ACPI interface used
> for laptops, PowerXpress, and chipset specific functionality
> and update the current code to use it.
Great! Now my DSDT makes sense ;)
> T
Hello,
I'm trying to figure out how to control the brightness of the screen of my
laptop, a Toshiba L885-10W.
The ACPI DSDT table contains the standard control methods, the setter (_BCM),
however, only sets a value in the record returned by ATIF method and send out a
notification:
CreateByteField
Hello,
I'm trying to figure out how to control the brightness of the screen of my
laptop, a Toshiba L885-10W.
The ACPI DSDT table contains the standard control methods, the setter (_BCM),
however, only sets a value in the record returned by ATIF method and send out a
notification:
CreateByteField
On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis
wrote:
> On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> wrote:
>> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler >> > ellipt
On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis wrote:
> On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> wrote:
>> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler
>>> > wrot
Hi Jerome,
On Wed, Apr 25, 2012 at 9:03 PM, wrote:
> From: Jerome Glisse
>
> This add a command buffer dumping facilities, that will
> dump command buffer and all associated bo that most likely
> triggered a lockup.
[cut]
I spotted this:
> +void radeon_fence_blob_faulty_ib(struct radeon_devic
Hi Jerome,
On Wed, Apr 25, 2012 at 9:03 PM, wrote:
> From: Jerome Glisse
>
> This add a command buffer dumping facilities, that will
> dump command buffer and all associated bo that most likely
> triggered a lockup.
[cut]
I spotted this:
> +void radeon_fence_blob_faulty_ib(struct radeon_devic
Hi Rob,
I've a couple of (minor) comments:
On Wed, Mar 21, 2012 at 01:00:36PM -0500, Rob Clark wrote:
> --- /dev/null
> +++ b/omap/omap_drm.c
[...]
> +/* allocate a new (un-tiled) buffer object */
> +struct omap_bo * omap_bo_new(struct omap_device *dev,
> + uint32_t size, uint32_t flag
Hi Rob,
I've a couple of (minor) comments:
On Wed, Mar 21, 2012 at 01:00:36PM -0500, Rob Clark wrote:
> --- /dev/null
> +++ b/omap/omap_drm.c
[...]
> +/* allocate a new (un-tiled) buffer object */
> +struct omap_bo * omap_bo_new(struct omap_device *dev,
> + uint32_t size, uint32_t flag
On Mon, Dec 13, 2010 at 5:27 AM, Alex Deucher wrote:
> Seems to cause problems on certain laptops
>
> Fixes:
> https://bugzilla.kernel.org/show_bug.cgi?id=24462
>
> Signed-off-by: Alex Deucher
Tested-by: Luca Tettamanti
> ---
> ?drivers/gpu/drm/radeon/atombios_crtc.
On Mon, Dec 13, 2010 at 5:27 AM, Alex Deucher wrote:
> Seems to cause problems on certain laptops
>
> Fixes:
> https://bugzilla.kernel.org/show_bug.cgi?id=24462
>
> Signed-off-by: Alex Deucher
Tested-by: Luca Tettamanti
> ---
> drivers/gpu/drm/radeon/atombios_crtc.
On Fri, Aug 13, 2010 at 11:39 PM, Dan Carpenter wrote:
> Smatch thinks there is a buffer overflow in nvc0_instmem_suspend() and
> I've looked at it, but I don't understand the code.
>
> drivers/gpu/drm/nouveau/nvc0_instmem.c +152 nvc0_instmem_suspend(10)
> ? ? ? ?error: buffer overflow 'dev_priv->
On Fri, Aug 13, 2010 at 11:39 PM, Dan Carpenter wrote:
> Smatch thinks there is a buffer overflow in nvc0_instmem_suspend() and
> I've looked at it, but I don't understand the code.
>
> drivers/gpu/drm/nouveau/nvc0_instmem.c +152 nvc0_instmem_suspend(10)
> error: buffer overflow 'dev_priv->
On Wed, Aug 11, 2010 at 10:50 AM, Dave Airlie wrote:
> On Wed, Aug 11, 2010 at 6:48 PM, Luca Tettamanti
> wrote:
>> Hi Arnd,
>> this commit:
>>
>> commit 58374713c9dfb4d231f8c56cac089f6fbdedc2ec
>> Author: Arnd Bergmann
>> Date: ? Sat Jul 10 23:51
On Wed, Aug 11, 2010 at 10:50 AM, Dave Airlie wrote:
> On Wed, Aug 11, 2010 at 6:48 PM, Luca Tettamanti wrote:
>> Hi Arnd,
>> this commit:
>>
>> commit 58374713c9dfb4d231f8c56cac089f6fbdedc2ec
>> Author: Arnd Bergmann
>> Date: Sat Jul 10 23:51:39 2010 +
55 matches
Mail list logo
