Date: Sat, 15 Jul 2006 21:01:23 -0400 (EDT) From: john@utzweb.net To: "Bruno Ducrot" <ducrot@poupinou.org> Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: ch to fix this Re: Dell/acpi_video hw.acpi.video.out0 is probably a bug, and an important one. Re: Dell laptops Message-ID: <46050.69.93.78.27.1153011683.squirrel@69.93.78.27> In-Reply-To: <20060715183804.GN17014@poupinou.org> References: <Pine.GSO.4.64.0607112352430.27869@sea.ntplx.net> <200607122136.54293.mistry.7@osu.edu> <Pine.GSO.4.64.0607130824240.6165@sea.ntplx.net> <44B6401F.8050507@centtech.com> <Pine.GSO.4.64.0607130848190.6165@sea.ntplx.net> <44B641F2.2020500@centtech.com> <Pine.GSO.4.64.0607130900460.6165@sea.ntplx.net> <32884.69.93.78.27.1152831695.squirrel@69.93.78.27> <34247.69.93.78.27.1152835592.squirrel@69.93.78.27> <39062.69.93.78.27.1152857140.squirrel@69.93.78.27> <20060715183804.GN17014@poupinou.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi John,
Hello Bruno
> On Fri, Jul 14, 2006 at 02:05:40AM -0400, john@utzweb.net wrote:
>> acpi_video.c expects the lcd to be identified as 0x0110, but my Dell
>> Latitude C400 (and probably others) id's the lcd at 0x0400:
>>
>> Device (LCD)
>> {
>> Method (_ADR, 0, NotSerialized)
>> {
>> Return (0x0400)
>> }
>>
>>
>> so, acpi_video needs to account for this.
>>
>>
>> got this sorted, and now the display turns back on, here's the patch, i
>> already send-pr'd it
>
> Youre somewhat right, but your patch is wrong.
Thankyou for taking interest and reviewing my analysis and patch.
I would beg to differ with your assertions concerning the patch's
correctness, because the operation you mention below is handled a few
lines above the patch.
> Actually you have to check if ((adr & 0x0400) == 0x0400).
the & occurs at the top of the switch, here's the destroy case:
static void
acpi_video_vo_destroy(struct acpi_video_output *vo)
{
struct acpi_video_output_queue *voqh;
ACPI_SERIAL_ASSERT(video);
if (vo->vo_sysctl_tree != NULL) {
vo->vo_sysctl_tree = NULL;
sysctl_ctx_free(&vo->vo_sysctl_ctx);
}
if (vo->vo_levels != NULL)
AcpiOsFree(vo->vo_levels);
switch (vo->adr & DOD_DEVID_MASK) {
case DOD_DEVID_MONITOR:
voqh = &crt_units;
break;
case DOD_DEVID_PANEL:
case 0x400:
voqh = &lcd_units;
break;
case DOD_DEVID_TV:
voqh = &tv_units;
break;
default:
voqh = &other_units;
}
STAILQ_REMOVE(voqh, vo, acpi_video_output, vo_unit.next);
free(vo, M_ACPIVIDEO);
}
there is also the indisputable fact that it worked:
[spaz@minime /usr/home/spaz]$ sysctl hw.acpi.video
hw.acpi.video.crt0.active: 0
hw.acpi.video.lcd0.active: 1 <-- used to be out0
[spaz@minime /usr/home/spaz]$
> In fact, acpi_video.c is
> correct for ACPI spec2, but ACPI spec3 have changed in that regard, and
> only the value 0x110 (LCD internal panel) should be kept for
> backward compatility.
>
> Please look at the two specifications (v2.0c and v3) at the ACPI
> info website: http://www.acpi.info for more.
ah, the spec. thankyou!
i will take the time to read it carefully.
currently, i think that the next areas of despair with my dell are the
following:
from dmesg on boot:
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
ACPI: Found matching pin for 0.31.INTA at func 1: 255
ACPI: Found matching pin for 0.31.INTB at func 5: 11
pci_link1: BIOS IRQ 11 for 0.31.INTB is invalid
from dmesg post quitting xorg:
"Interrupt storm detected on irq 11; throttling interrupt source"
i would think that if i could figure out how to fix the invalid INTB, i'd
probably not get the interrupt storm
> (pseudo patch snipped)
>
> Cheers,
>
> --
> Bruno Ducrot
>
> -- Which is worse: ignorance or apathy?
> -- Don't know. Don't care.
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46050.69.93.78.27.1153011683.squirrel>