RE: [PATCHv3 13/15] Thermal: Remove throttling logic out of thermal_sys.c

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

 



Hi Rui,

> On 一, 2012-09-10 at 02:56 -0600, R, Durgadoss wrote:
> > Hi Rui,
> >
> > > -----Original Message-----
> > > From: Zhang, Rui
> > > Sent: Monday, September 10, 2012 2:14 PM
> > > To: R, Durgadoss
> > > Cc: lenb@xxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx;
> eduardo.valentin@xxxxxx
> > > Subject: Re: [PATCHv3 13/15] Thermal: Remove throttling logic out of
> > > thermal_sys.c
> > [cut.]
> >
> > > > +
> > > > +static void handle_non_critical_trips(struct thermal_zone_device *tz,
> > > > +			int trip, enum thermal_trip_type trip_type)
> > > > +{
> > > > +	tz->governor->throttle(tz, trip);
> > > > +}
> > > here is the problem, we must make sure every registered thermal zone
> > > have a governor when it is running, right?
> >
> > Yes, agree with you. Had some thoughts here, but wanted to get your
> opinion
> > before I implemented them.
> >
> > 1. We can make the default governor as 'user space', and make it load
> inside
> > thermal_sys.c (so that every zone will always have a default governor)
> >
> No, the default governor should be step wise so that it behaves the same
> as before. if we use userspace as default governor, most of the thermal
> driver will stop working with this patch set.

yes, I understand. Shall make step_wise default, and always loaded.

For user space, should we move it to a new .c file, and make it like
other governors or can we keep it as it is ?

Thanks,
Durga

> 
> IMO, we should make all of the governors configurable, but at least one
> of them must be selected as the default governor, that's why we need
> something below.
> 
> choice
>         prompt "Default thermal governor"
>         default THERMAL_DEFAULT_GOV_STEP_WISE
>         help
>           This option sets which thermal governor shall be loaded at
>           startup.
> 
> thanks,
> rui
> 
> > 2. All other governors, that are implemented in a separate .c file can be
> > optional i.e. left to the user to select/deselect.
> >
> > IMO, this will make our implementation easier and cleaner.
> > What do you think ?
> >
> > Thanks,
> > Durga
> >
> > >
> > > then the default governor must always be built in.
> > > We can have a Kconfig option for step_wise, but we should not make it
> > > configurable by users.
> > > or we can use prompt to get the default governor at build time. say
> > >
> > > choice
> > >         prompt "Default thermal governor"
> > >         default THERMAL_DEFAULT_GOV_STEP_WISE
> > >         help
> > >           This option sets which thermal governor shall be loaded at
> > >           startup.
> > >
> > > config THERMAL_DEFAULT_GOV_STEP_WISE
> > >         bool "step-wise"
> > >         select THERMAL_GOV_STEP_WISE
> > >         help
> > >           Use the thermal governor 'step-wise' as default.blabla
> > >
> > >
> > > thanks,
> > > rui
��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f



[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