Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1334102 > unrolled thread

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support Daniel Kurtz <djkurtz@chromium.org> - 2016-02-15 03:20 +0100
    Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support Matthias Brugger <matthias.bgg@gmail.com> - 2016-02-17 18:10 +0100
      Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support Sascha Hauer <s.hauer@pengutronix.de> - 2016-02-18 12:00 +0100
        Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support Javi Merino <javi.merino@arm.com> - 2016-02-18 15:30 +0100
        Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support Eduardo Valentin <edubezval@gmail.com> - 2016-02-18 16:20 +0100
          Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support Sascha Hauer <s.hauer@pengutronix.de> - 2016-02-19 08:30 +0100

#1334102 — Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> Hi Eduardo, Sascha,
>
> On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>>
>> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
>> > Eduardo,
>> >
>> > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
>> > > Hi Eduardo,
>> > >
>> > > >
>> > > > That should remove the policy of computing the maximum from this driver.
>> > > > Please have a look on the work being done [1] to add grouping and
>> > > > aggregation of thermal zones. With that in place, you should be a matter
>> > > > of configuring the grouping and selecting max as the aggregation function,
>> > > > from the thermal core, instead in the driver. Which should give the
>> > > > system engineer, more flexibility to compose whatever policy based on
>> > > > the exposed sensors.
>> > >
>> > > I think the aggregation of thermal zones is quite useful when it comes
>> > > to putting different chips together to a system. I am not so sure how
>> > > useful it is to expose different thermal zones of a single SoC to the
>> > > device tree.
>> > > Currently the only control knob we have is the CPU frequency. When any
>> > > of the sensors on the SoC gets too hot then the only thing we can do is
>> > > to decrease the CPU frequency. This does not leave much space for
>> > > configuration in the device tree.
>> > > What I need to be able is to attach multiple sensors to one thermal
>> > > zone. The aggregation patch series only partly solves that and I think
>> > > is inconsistent, but I commented on the series directly.
>> >
>> > Any input on this? I really like to get this driver upstream as it is
>> > currently blocking other Mediatek drivers.
>> >
>>
>> Hi Eduardo,
>>
>> Do you have any comment about Sascha's response ? We really hope get
>> your comment since Mediatek thermal driver already reviewed in public
>> over half years, and we have other patches [0] [1] depend on thermal
>> driver.
>>
>> [0]:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
>> [1]:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
>
> Friendly ping on the Mediatek thermal driver.
> The "EFUSE" dependency has now landed in v4.5-rc4.

Actually, it landed in char-misc-next, not v4.5-rc4.

> So, AFAICT, the only thing left that may be blocking landing Mediatek
> thermal driver is resolution of this discussion about thermal zones.
> Can we kindly resolve this soon so we have a chance to land it in v4.6.
>
> Thanks,
> -Dan

[toc] | [next] | [standalone]

#1336583

On 15/02/16 03:14, Daniel Kurtz wrote:
> On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>> Hi Eduardo, Sascha,
>>
>> On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang@mediatek.com> wrote:
>>>
>>> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
>>>> Eduardo,
>>>>
>>>> On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
>>>>> Hi Eduardo,
>>>>>
>>>>>>
>>>>>> That should remove the policy of computing the maximum from this driver.
>>>>>> Please have a look on the work being done [1] to add grouping and
>>>>>> aggregation of thermal zones. With that in place, you should be a matter
>>>>>> of configuring the grouping and selecting max as the aggregation function,
>>>>>> from the thermal core, instead in the driver. Which should give the
>>>>>> system engineer, more flexibility to compose whatever policy based on
>>>>>> the exposed sensors.
>>>>>
>>>>> I think the aggregation of thermal zones is quite useful when it comes
>>>>> to putting different chips together to a system. I am not so sure how
>>>>> useful it is to expose different thermal zones of a single SoC to the
>>>>> device tree.
>>>>> Currently the only control knob we have is the CPU frequency. When any
>>>>> of the sensors on the SoC gets too hot then the only thing we can do is
>>>>> to decrease the CPU frequency. This does not leave much space for
>>>>> configuration in the device tree.
>>>>> What I need to be able is to attach multiple sensors to one thermal
>>>>> zone. The aggregation patch series only partly solves that and I think
>>>>> is inconsistent, but I commented on the series directly.
>>>>
>>>> Any input on this? I really like to get this driver upstream as it is
>>>> currently blocking other Mediatek drivers.
>>>>
>>>
>>> Hi Eduardo,
>>>
>>> Do you have any comment about Sascha's response ? We really hope get
>>> your comment since Mediatek thermal driver already reviewed in public
>>> over half years, and we have other patches [0] [1] depend on thermal
>>> driver.
>>>
>>> [0]:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
>>> [1]:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
>>
>> Friendly ping on the Mediatek thermal driver.
>> The "EFUSE" dependency has now landed in v4.5-rc4.
>
> Actually, it landed in char-misc-next, not v4.5-rc4.
>
>> So, AFAICT, the only thing left that may be blocking landing Mediatek
>> thermal driver is resolution of this discussion about thermal zones.
>> Can we kindly resolve this soon so we have a chance to land it in v4.6.
>>


I think the problem is, that Eduardo wants to see the hierachical 
thermal zones being used. But there is still a discussion ongoing [1].

[1] https://patchwork.kernel.org/patch/7699971/

[toc] | [prev] | [next] | [standalone]

#1337269

On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> 
> 
> On 15/02/16 03:14, Daniel Kurtz wrote:
> >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> >>Hi Eduardo, Sascha,
> >>
> >>>>Any input on this? I really like to get this driver upstream as it is
> >>>>currently blocking other Mediatek drivers.
> >>>>
> >>>
> >>>Hi Eduardo,
> >>>
> >>>Do you have any comment about Sascha's response ? We really hope get
> >>>your comment since Mediatek thermal driver already reviewed in public
> >>>over half years, and we have other patches [0] [1] depend on thermal
> >>>driver.
> >>>
> >>>[0]:
> >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> >>>[1]:
> >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> >>
> >>Friendly ping on the Mediatek thermal driver.
> >>The "EFUSE" dependency has now landed in v4.5-rc4.
> >
> >Actually, it landed in char-misc-next, not v4.5-rc4.
> >
> >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> >>thermal driver is resolution of this discussion about thermal zones.
> >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> >>
> 
> 
> I think the problem is, that Eduardo wants to see the hierachical thermal
> zones being used. But there is still a discussion ongoing [1].

It seems the original Author lost interest in the hierarchical thermal
zones. I am not convinced that we need hierarchical thermal zones for
the Mediatek driver since from the five sensors we only need the maximum
temperature (If this ever changes we could still rework it).

Given the current speed of communication I am not willing to add
another, possibly controversal, dependency to an otherwise simple
driver. I am even less willing when concerns like these come after *v12*
of this series.

Eduardo, it would really help to get a word from you.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[toc] | [prev] | [next] | [standalone]

#1337397

Hi Sascha,

On Thu, Feb 18, 2016 at 11:56:03AM +0100, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> > On 15/02/16 03:14, Daniel Kurtz wrote:
> > >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> > >>Hi Eduardo, Sascha,
> > >>
> > >>>>Any input on this? I really like to get this driver upstream as it is
> > >>>>currently blocking other Mediatek drivers.
> > >>>>
> > >>>
> > >>>Hi Eduardo,
> > >>>
> > >>>Do you have any comment about Sascha's response ? We really hope get
> > >>>your comment since Mediatek thermal driver already reviewed in public
> > >>>over half years, and we have other patches [0] [1] depend on thermal
> > >>>driver.
> > >>>
> > >>>[0]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> > >>>[1]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> > >>
> > >>Friendly ping on the Mediatek thermal driver.
> > >>The "EFUSE" dependency has now landed in v4.5-rc4.
> > >
> > >Actually, it landed in char-misc-next, not v4.5-rc4.
> > >
> > >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> > >>thermal driver is resolution of this discussion about thermal zones.
> > >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> > >>
> > 
> > 
> > I think the problem is, that Eduardo wants to see the hierachical thermal
> > zones being used. But there is still a discussion ongoing [1].
> 
> It seems the original Author lost interest in the hierarchical thermal
> zones. I am not convinced that we need hierarchical thermal zones for
> the Mediatek driver since from the five sensors we only need the maximum
> temperature (If this ever changes we could still rework it).

I guess that "the original Author" refers to me.  I haven't lost
interest in the hierarchical thermal zones, I just don't have time to
work on it currently.  I'd like to address your review at some point
in the future and continue working on it.
 
> Given the current speed of communication I am not willing to add
> another, possibly controversal, dependency to an otherwise simple
> driver. I am even less willing when concerns like these come after *v12*
> of this series.

I agree.  I don't think we should make this driver depend on the
hierarchical thermal zones series.  When hierarchical thermal zones
get merged we can consider to change the driver to use them but
there's no point in waiting for that to happen.

Cheers,
Javi

[toc] | [prev] | [next] | [standalone]

#1337458

Folks,

On Thu, Feb 18, 2016 at 11:56:03AM +0100, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> > 
> > 
> > On 15/02/16 03:14, Daniel Kurtz wrote:
> > >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> > >>Hi Eduardo, Sascha,
> > >>
> > >>>>Any input on this? I really like to get this driver upstream as it is
> > >>>>currently blocking other Mediatek drivers.
> > >>>>
> > >>>
> > >>>Hi Eduardo,
> > >>>
> > >>>Do you have any comment about Sascha's response ? We really hope get
> > >>>your comment since Mediatek thermal driver already reviewed in public
> > >>>over half years, and we have other patches [0] [1] depend on thermal
> > >>>driver.
> > >>>
> > >>>[0]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> > >>>[1]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> > >>
> > >>Friendly ping on the Mediatek thermal driver.
> > >>The "EFUSE" dependency has now landed in v4.5-rc4.
> > >
> > >Actually, it landed in char-misc-next, not v4.5-rc4.
> > >
> > >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> > >>thermal driver is resolution of this discussion about thermal zones.
> > >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> > >>
> > 
> > 
> > I think the problem is, that Eduardo wants to see the hierachical thermal
> > zones being used. But there is still a discussion ongoing [1].
> 
> It seems the original Author lost interest in the hierarchical thermal
> zones. I am not convinced that we need hierarchical thermal zones for
> the Mediatek driver since from the five sensors we only need the maximum
> temperature (If this ever changes we could still rework it).
> 
> Given the current speed of communication I am not willing to add
> another, possibly controversal, dependency to an otherwise simple
> driver. I am even less willing when concerns like these come after *v12*
> of this series.
> 
> Eduardo, it would really help to get a word from you.

Apologize for the long delays here. In fact I want the hierarchical
support on this driver. But given that it is not really a strong
dependency and the hierarchical support is still an ongoing development,
I don't see why we should not merge this driver.

I also have had the chance to try it out in a board, and seams to work
for me. I am adding to my tree.

Thanks for the perseverance. :-)

> 
> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[toc] | [prev] | [next] | [standalone]

#1337939

On Thu, Feb 18, 2016 at 07:15:54AM -0800, Eduardo Valentin wrote:
> Folks,
> 
> > > I think the problem is, that Eduardo wants to see the hierachical thermal
> > > zones being used. But there is still a discussion ongoing [1].
> > 
> > It seems the original Author lost interest in the hierarchical thermal
> > zones. I am not convinced that we need hierarchical thermal zones for
> > the Mediatek driver since from the five sensors we only need the maximum
> > temperature (If this ever changes we could still rework it).
> > 
> > Given the current speed of communication I am not willing to add
> > another, possibly controversal, dependency to an otherwise simple
> > driver. I am even less willing when concerns like these come after *v12*
> > of this series.
> > 
> > Eduardo, it would really help to get a word from you.
> 
> Apologize for the long delays here. In fact I want the hierarchical
> support on this driver. But given that it is not really a strong
> dependency and the hierarchical support is still an ongoing development,
> I don't see why we should not merge this driver.
> 
> I also have had the chance to try it out in a board, and seams to work
> for me. I am adding to my tree.

Thanks for applying :)

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web