Mailinglist Archive: radeonhd (408 mails)

< Previous Next >
Re: [radeonhd] [PATCH] Somehow /force/ backlight control
  • From: Alex Deucher <alexdeucher@xxxxxxxxx>
  • Date: Mon, 29 Jun 2009 14:11:32 -0400
  • Message-id: <a728f9f90906291111y54a8c35cte5ebf53e28113d09@xxxxxxxxxxxxxx>
2009/6/29 Rafał Miłecki <zajec5@xxxxxxxxx>:
W dniu 29 czerwca 2009 18:08 użytkownik Egbert Eich <eich@xxxxxxx> napisał:
Rafa? Mi?ecki writes:
 > Currently we don't try to control backlight after detecting
 > (RHDRegRead(Output, RV620_LVTMA_BL_MOD_CNTL) & LVTMA_BL_MOD_EN) == 0
 >
 > This assumption is quite wrong, because in some (many?) cases we can
 > just change this one bit and control backlight without problem.
 > Confirmed to work on M82==RV620.

This is possible but there is no guarantee. It could also be controlled
by some OEM specific mechanism. In those cases we cannot control backlight,
if at all it can be controlled over ACPI.

What do you mean by "OEM specific mechanism"? Just ACPI? Or something more?


Some oems use the on-chip backlight control, others use some other
method (gpio control, separate controller on the motherboard, etc.).
The acpi method should work unless it requires access to the vga io
space which IIRC radeonhd disables (at least it used to, not sure if
it still does).

What will happen if we try to control (change) backlight on system
where it is already controled by ACPI? Can this cause any unstability?
Can ACPI control backlight using something else that registers we
touch in radeonhd's code?

Yes. See above. The driver code in question only works for oem
systems that use the on-chip backlight controller; not all oems do.


To not expose a backlight property
if we cannot control it anyway I had decided to use this check.

I can control backlight this way anyway. So this is not right check.
It cuts off control on system where it actually works fine. And we
already know it's not only my specific case.

The problem is we don't know which systems uses which method.


We could fall back to AtomBIOS controlled backlight in cases where we are
not sure as this might be programmed correctly for the system in question
- however to implement this would require some extra work as in the hard
coded cases the needed data structures have not been set up.

Why AtomBIOS would be safer to use than using registers? What AtomBIOS
command would you actually like to call? That whole AtomBIOSScratch
code looks really messy for me.

It may work for more cases depending on how the oem has chosen to wire
up the backlight. IIRC, it's controlled by LCD1OutputControl on
pre-DCE3 chips, and DIG2TransmitterControl on DCE3 and newer chips.
As I recall, you set the requested level in one of the bios scratch
regs and then execute the table with the action set to the appropriate
LCD_BLOFF/BLON/BL_BRIGHTNESS_CONTROL for the table. See atombios.h.

Alex
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups