Re: a problem about the two patches in bug 10724 & 11428

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2008-09-03 at 10:46 +0400, Alexey Starikovskiy wrote:
> Zhao Yakui wrote:
> > On Tue, 2008-09-02 at 00:59 +0400, Alexey Starikovskiy wrote:
> >> Alexey Starikovskiy wrote:
> > Hi, Alexey
> >     In this patch after the EC timeout happens, the EC_FLAGS_GPE_MODE of
> > ec->flags will be clear and EC_FLAGS_NO_GPE bit will be set. But the EC
> > GPE won't be disabled again. Right?
> Right
> >     In such case when  EC is accessed, EC will work in polling mode. At
> > the same time EC interrupt still can be triggered. But the
> > EC_FLAGS_GPE_MODE can't be set again. Right?
> Almost. EC by itself (hardware device) still will be working in its 
> "optimized gpe mode" as before, but EC driver (software) will be working in poll mode.
> Regards,
Thanks for the quick response.
Is it appropriate that EC always works in such mode? The mode switch
seems so complex.
When EC is accessed, EC will work in polling mode.
But EC GPE will be triggered. Maybe what we cared is EC notification
event(EC_SCI bit of EC status register).

thanks.
> Alex.
> > 
> > Thanks
> >     Yakui.
> >               
> >>> Henrique de Moraes Holschuh wrote:
> >>>> On Mon, 01 Sep 2008, Zhao Yakui wrote:
> >>>>>     Will the above two patches hit the upstream kernel? If the above 
> >>>>> two patches hits the upstream kernel, it seems that the boot option 
> >>>>> of "ec_intr=" comes back again and EC can't be switched from 
> >>>>> interrupt mode to polling mode if EC GPE interrupt is missing. In 
> >>>>> such case maybe the battery/AC/thermal driver can't work well if the 
> >>>>> info of
> >>>>> battery/AC/thermal is related with EC. Maybe there exists the 
> >>>>> regression on some laptops.
> >>>> Right now, the fact that it gives up on interrupt mode too easily IS 
> >>>> causing
> >>>> regressions on ThinkPads (like the T43 I own).  Since polling mode does
> >>>> work, it is just a performance regression, so you won't get many reports
> >>>> about it since most people don't look for such stuff in their kernel 
> >>>> logs.
> >>>>
> >>>> Some ECs trigger the interrupt/poll-mode checks just on small windows
> >>>> (typically during resume -- might even be a bug somewhere in ACPICA or
> >>>> Linux, and not on the EC).  We should not be giving up using interrupt 
> >>>> mode
> >>>> on these so easily.  Maybe retry enabling interrupt mode after some 
> >>>> seconds
> >>>> a few times (like 3 or 5)?  If it is a transient problem, that will avoid
> >>>> the permanent performance regression of polled mode.
> >>>>
> >>> How about such patch?
> >> Or even better (working?) patch ...
> >>> Regards,
> >>> Alex.
> >>>
> > 
> 

--
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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux