Am Montag, den 14.04.2008, 19:56 +0200 schrieb Thomas Renninger:
> On Mon, 2008-04-14 at 19:18 +0200, nokos@xxxxxxx wrote:
> > 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)
>
> Hmm, you mean because NGTF has another value on your machine?
> Trying to get this solved automatically would be great...
I have not yet tried to readout the NGTF with a platform device. Hmm,
how do access fields like NGTF (All I have done so far was calling
functions like GBLL() and examining the return value).
According to the DSDT should FUNC(0x1004,1,4,0) switch off NGTF, but
then SBLL is still not working.
Where can I find some documentation of the DSL/ASL language? Are there
docs about the linux-acpi interface?
> I know there is an asus_acpi driver mailing list, I do not know about a
> Fujitu one.
>
> I do not have that much time currently, if you like I can go through the
> code again after you split it into two parts.
> Then it should be much easier to read...
already done ... will test it bit and then post it here.
> IMO we should also document our thinking, maybe not on a mailing list,
> but more on bugzilla.kernel.org.
> Then other Fujitsu users may show up testing or providing more DSDTs
> etc. and at after some code iterations Len might accept a new Fujitsu
> driver.
should I open a bug "fujitsu-laptop not working on S6410" or something
for further discussions?
> Not sure whether it's worth it, but possibly a fujitsu ACPI mailinglist
> on sourcefore or elsewhere might be worth it (but expect some amount of
> work...). Maybe you the author of the other fujitsu driver or others are
> willing to help...
>
> I wonder whether you have fan problems?
> I recently found this (probably older?) fujitsu bug:
> http://bugzilla.kernel.org/show_bug.cgi?id=8049
no, fan works as expected although I have no controls in /proc/acpi/fan/
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
