Am Montag, den 14.04.2008, 12:46 +0200 schrieb Thomas Renninger:
> >
> > +static int get_irb(void)
> > +{
> > + unsigned long state = 0;
> > + acpi_status status = AE_OK;
> > +
> > + status =
> > + acpi_evaluate_integer(fujitsu->acpi_handle_e3, "GIRB", NULL,
> > + &state);
> This is ugly, but often done/needed in vendor specific ACPI drivers.
> Guessing the used functions by trial and error...
> Have a closer look whether there are more "upper level" functions you
> could use to access the same info which might stay stable for this
> specific fujitsu device.
> Same for other functions below.
looking through the DSDT it is only use in the S002 function and this
one is only used in FUNC (which seems to be some kind of frontend for
all the S000 - S009 functions with even more cryptic parameters, ie.
FUNC(0x1002,1,0,0) is the same as GIRB())
The other functions used are SBL2, which is the same as SBLL except the
Method (SBLL, 1, NotSerialized)
{
If (NGTF)
{
Store (Arg0, LSBL)
Return (Zero)
}
...
clause which seems to stop SBLL from working and GBLS which is a variant of GBLL with similar problem.
The whole point of the parameter use_alt_lcd_levels was to have an easy way to switch between
SBLL/GBLL (not working on S6410) and SBL2/GBLS (working on S6410)
Peter
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
