mbox series

[v3,00/10] qcom: pm8150: add support for thermal monitoring

Message ID 20200910140000.324091-1-dmitry.baryshkov@linaro.org (mailing list archive)
Headers show
Series qcom: pm8150: add support for thermal monitoring | expand

Message

Dmitry Baryshkov Sept. 10, 2020, 1:59 p.m. UTC
This patch serie adds support for thermal monitoring block on Qualcomm's
PMIC5 chips. PM8150{,b,l} and sm8250-mtp board device trees are extended
to support thermal zones provided by this thermal monitoring block.
Unlike the rest of PMIC thermal senses, these thermal zones describe
particular thermistors, which differ between from board to board.

Changes since v3:
 - Fix DT description to spell "thermal monitoring" instead of just TM
 - Fix warnings in DT example
 - Add EXPORT_SYMBOL_GPL(of_iio_channel_get_by_name)
 - Fixed whitespace chanes in qcom-vadc-common.c
 - Removed error message if IIO chanel get returns -EPROBE_DEFER

Changes since v2:
 - IIO: export of_iio_channel_get_by_name() function
 - dt-bindings: move individual io-channels to each thermal monitoring
   channel rather than listing them all in device node
 - added fallback defaults to of_device_get_match_data calls in
   qcom-spmi-adc5 and qcom-spmi-adc-tm5 drivers
 - minor typo fixes

Changes since v1:
 - Introduce fixp_linear_interpolate() by Craig Tatlor
 - Lots of syntax/whitespace changes
 - Cleaned up register definitions per Jonathan's suggestion
 - Implemented most of the suggestions from Bjorn's and Jonathan's
   review

Comments

Jonathan Cameron Sept. 13, 2020, 10:21 a.m. UTC | #1
On Thu, 10 Sep 2020 16:59:50 +0300
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:

> This patch serie adds support for thermal monitoring block on Qualcomm's
> PMIC5 chips. PM8150{,b,l} and sm8250-mtp board device trees are extended
> to support thermal zones provided by this thermal monitoring block.
> Unlike the rest of PMIC thermal senses, these thermal zones describe
> particular thermistors, which differ between from board to board.
> 

As far as I am concerned this series is now ready to go up to one or two
things in patch 8.  So on to the normal question based on the assumption
it will pick up other necessary reviews shortly...

What route do we want this to take? 
I can do an immutable branch in IIO if that works for patches 1-8 and assume
the dt file changes will got via usual SoC path?  We are getting a fair way
into this cycle, so this may well end up happening next cycle depending
on how quick reviews come in.

Thanks,

Jonathan

> Changes since v3:
>  - Fix DT description to spell "thermal monitoring" instead of just TM
>  - Fix warnings in DT example
>  - Add EXPORT_SYMBOL_GPL(of_iio_channel_get_by_name)
>  - Fixed whitespace chanes in qcom-vadc-common.c
>  - Removed error message if IIO chanel get returns -EPROBE_DEFER
> 
> Changes since v2:
>  - IIO: export of_iio_channel_get_by_name() function
>  - dt-bindings: move individual io-channels to each thermal monitoring
>    channel rather than listing them all in device node
>  - added fallback defaults to of_device_get_match_data calls in
>    qcom-spmi-adc5 and qcom-spmi-adc-tm5 drivers
>  - minor typo fixes
> 
> Changes since v1:
>  - Introduce fixp_linear_interpolate() by Craig Tatlor
>  - Lots of syntax/whitespace changes
>  - Cleaned up register definitions per Jonathan's suggestion
>  - Implemented most of the suggestions from Bjorn's and Jonathan's
>    review
> 
> 
>
Dmitry Baryshkov Sept. 14, 2020, 3:45 p.m. UTC | #2
On 13/09/2020 13:21, Jonathan Cameron wrote:
> On Thu, 10 Sep 2020 16:59:50 +0300
> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> 
>> This patch serie adds support for thermal monitoring block on Qualcomm's
>> PMIC5 chips. PM8150{,b,l} and sm8250-mtp board device trees are extended
>> to support thermal zones provided by this thermal monitoring block.
>> Unlike the rest of PMIC thermal senses, these thermal zones describe
>> particular thermistors, which differ between from board to board.
>>
> 
> As far as I am concerned this series is now ready to go up to one or two
> things in patch 8.  So on to the normal question based on the assumption
> it will pick up other necessary reviews shortly...

Sending v5 right now, fixing issues in patch 8.

> 
> What route do we want this to take?
> I can do an immutable branch in IIO if that works for patches 1-8 and assume
> the dt file changes will got via usual SoC path?  We are getting a fair way
> into this cycle, so this may well end up happening next cycle depending
> on how quick reviews come in.

I think this makes sense. Thank you for your reviews.