Message ID | 1448883753-19068-3-git-send-email-s.hauer@pengutronix.de (mailing list archive) |
---|---|
State | Accepted |
Delegated to: | Eduardo Valentin |
Headers | show |
Sascha, Yeah, sorry for the long delay. I was planing on applying this patch for the next merge window, but it just came across one point, see below. On Mon, Nov 30, 2015 at 12:42:32PM +0100, Sascha Hauer wrote: > This adds support for the Mediatek thermal controller found on MT8173 > +static const int sensor_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 }; > + <big cut> > +/* > + * The MT8173 thermal controller has four banks. Each bank can read up to > + * four temperature sensors simultaneously. The MT8173 has a total of 5 > + * temperature sensors. We use each bank to measure a certain area of the > + * SoC. Since TS2 is located centrally in the SoC it is influenced by multiple > + * areas, hence is used in different banks. > + * > + * The thermal core only gets the maximum temperature of all banks, so > + * the bank concept wouldn't be necessary here. However, the SVS (Smart > + * Voltage Scaling) unit makes its decisions based on the same bank > + * data, and this indeed needs the temperatures of the individual banks > + * for making better decisions. > + */ > +static const struct mtk_thermal_bank_cfg bank_data[] = { > + { > + .num_sensors = 2, > + .sensors = { MT8173_TS2, MT8173_TS3 }, > + }, { > + .num_sensors = 2, > + .sensors = { MT8173_TS2, MT8173_TS4 }, > + }, { > + .num_sensors = 3, > + .sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB }, > + }, { > + .num_sensors = 1, > + .sensors = { MT8173_TS2 }, > + }, > +}; Why can't we expose all these as thermal zones? 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. BR, Eduardo Valentin [1] - https://lkml.org/lkml/2015/11/25/446 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Sascha, One nit below that can be fixed up later, or now if you don't plan to spin this driver to address Eduardo's feedback... On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > This adds support for the Mediatek thermal controller found on MT8173 > and likely other SoCs. > The controller is a bit special. It does not have its own ADC, instead > it controls the on-SoC AUXADC via AHB bus accesses. For this reason > we need the physical address of the AUXADC. Also it controls a mux > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell. > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> [snip] > +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt) > +{ > + struct nvmem_cell *cell; > + u32 *buf; > + size_t len; > + int i, ret = 0; > + > + /* Start with default values */ > + mt->adc_ge = 512; > + for (i = 0; i < MT8173_NUM_SENSORS; i++) > + mt->vts[i] = 260; > + mt->degc_cali = 40; > + mt->o_slope = 0; > + > + cell = nvmem_cell_get(dev, "calibration-data"); > + if (IS_ERR(cell)) { > + if (PTR_ERR(cell) == -EPROBE_DEFER) It is useful to know why the thermal driver is being probe defered, so I suggest here: dev_warn(dev, "Waiting for calibration data.\n"); > + return PTR_ERR(cell); > + return 0; > + } Thanks, -Dan -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Eduardo, On Thu, Dec 17, 2015 at 11:33:33AM -0800, Eduardo Valentin wrote: > Sascha, > > Yeah, sorry for the long delay. I was planing on applying this patch for > the next merge window, but it just came across one point, see below. > > On Mon, Nov 30, 2015 at 12:42:32PM +0100, Sascha Hauer wrote: > > This adds support for the Mediatek thermal controller found on MT8173 > > +static const int sensor_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 }; > > + > > <big cut> > > > +/* > > + * The MT8173 thermal controller has four banks. Each bank can read up to > > + * four temperature sensors simultaneously. The MT8173 has a total of 5 > > + * temperature sensors. We use each bank to measure a certain area of the > > + * SoC. Since TS2 is located centrally in the SoC it is influenced by multiple > > + * areas, hence is used in different banks. > > + * > > + * The thermal core only gets the maximum temperature of all banks, so > > + * the bank concept wouldn't be necessary here. However, the SVS (Smart > > + * Voltage Scaling) unit makes its decisions based on the same bank > > + * data, and this indeed needs the temperatures of the individual banks > > + * for making better decisions. > > + */ > > +static const struct mtk_thermal_bank_cfg bank_data[] = { > > + { > > + .num_sensors = 2, > > + .sensors = { MT8173_TS2, MT8173_TS3 }, > > + }, { > > + .num_sensors = 2, > > + .sensors = { MT8173_TS2, MT8173_TS4 }, > > + }, { > > + .num_sensors = 3, > > + .sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB }, > > + }, { > > + .num_sensors = 1, > > + .sensors = { MT8173_TS2 }, > > + }, > > +}; > > Why can't we expose all these as thermal zones? > > 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. Sascha
On Mon, Dec 21, 2015 at 12:07:58PM +0800, Daniel Kurtz wrote: > Hi Sascha, > > One nit below that can be fixed up later, or now if you don't plan to > spin this driver to > address Eduardo's feedback... > > On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > > This adds support for the Mediatek thermal controller found on MT8173 > > and likely other SoCs. > > The controller is a bit special. It does not have its own ADC, instead > > it controls the on-SoC AUXADC via AHB bus accesses. For this reason > > we need the physical address of the AUXADC. Also it controls a mux > > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell. > > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > > [snip] > > > +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt) > > +{ > > + struct nvmem_cell *cell; > > + u32 *buf; > > + size_t len; > > + int i, ret = 0; > > + > > + /* Start with default values */ > > + mt->adc_ge = 512; > > + for (i = 0; i < MT8173_NUM_SENSORS; i++) > > + mt->vts[i] = 260; > > + mt->degc_cali = 40; > > + mt->o_slope = 0; > > + > > + cell = nvmem_cell_get(dev, "calibration-data"); > > + if (IS_ERR(cell)) { > > + if (PTR_ERR(cell) == -EPROBE_DEFER) > > It is useful to know why the thermal driver is being probe defered, so > I suggest here: > dev_warn(dev, "Waiting for calibration data.\n"); The problem with that is that this message is not shown once but possibly many times and may not even show a problem because in the end the device may be probed successfully. In this case the last thing you see from the device is "Waiting for calibration data." and get annoyed by all this useless noise from the driver. Of course I agree that this information may be useful in the case you wonder why your device doesn't show up... Sascha
On Mon, Jan 4, 2016 at 10:31 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > On Mon, Dec 21, 2015 at 12:07:58PM +0800, Daniel Kurtz wrote: >> Hi Sascha, >> >> One nit below that can be fixed up later, or now if you don't plan to >> spin this driver to >> address Eduardo's feedback... >> >> On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: >> > This adds support for the Mediatek thermal controller found on MT8173 >> > and likely other SoCs. >> > The controller is a bit special. It does not have its own ADC, instead >> > it controls the on-SoC AUXADC via AHB bus accesses. For this reason >> > we need the physical address of the AUXADC. Also it controls a mux >> > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell. >> > >> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> >> >> [snip] >> >> > +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt) >> > +{ >> > + struct nvmem_cell *cell; >> > + u32 *buf; >> > + size_t len; >> > + int i, ret = 0; >> > + >> > + /* Start with default values */ >> > + mt->adc_ge = 512; >> > + for (i = 0; i < MT8173_NUM_SENSORS; i++) >> > + mt->vts[i] = 260; >> > + mt->degc_cali = 40; >> > + mt->o_slope = 0; >> > + >> > + cell = nvmem_cell_get(dev, "calibration-data"); >> > + if (IS_ERR(cell)) { >> > + if (PTR_ERR(cell) == -EPROBE_DEFER) >> >> It is useful to know why the thermal driver is being probe defered, so >> I suggest here: >> dev_warn(dev, "Waiting for calibration data.\n"); > > The problem with that is that this message is not shown once but > possibly many times and may not even show a problem because in the end > the device may be probed successfully. In this case the last thing you > see from the device is "Waiting for calibration data." and get annoyed > by all this useless noise from the driver. > > Of course I agree that this information may be useful in the case you > wonder why your device doesn't show up... The solution for this, then, is: dev_dbg() -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Sascha
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 Regards, Eddie -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 | -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 5aabc4b..503448a 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -348,6 +348,14 @@ config INTEL_PCH_THERMAL Thermal reporting device will provide temperature reading, programmable trip points and other information. +config MTK_THERMAL + tristate "Temperature sensor driver for mediatek SoCs" + depends on ARCH_MEDIATEK || COMPILE_TEST + default y + help + Enable this option if you want to have support for thermal management + controller present in Mediatek SoCs + menu "Texas Instruments thermal drivers" depends on ARCH_HAS_BANDGAP || COMPILE_TEST source "drivers/thermal/ti-soc-thermal/Kconfig" diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index 26f1608..5f979e7 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -45,3 +45,4 @@ obj-$(CONFIG_INTEL_PCH_THERMAL) += intel_pch_thermal.o obj-$(CONFIG_ST_THERMAL) += st/ obj-$(CONFIG_TEGRA_SOCTHERM) += tegra_soctherm.o obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o +obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c new file mode 100644 index 0000000..589a138 --- /dev/null +++ b/drivers/thermal/mtk_thermal.c @@ -0,0 +1,623 @@ +/* + * Copyright (c) 2015 MediaTek Inc. + * Author: Hanyi Wu <hanyi.wu@mediatek.com> + * Sascha Hauer <s.hauer@pengutronix.de> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/clk.h> +#include <linux/delay.h> +#include <linux/interrupt.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/nvmem-consumer.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/io.h> +#include <linux/thermal.h> +#include <linux/reset.h> +#include <linux/types.h> +#include <linux/nvmem-consumer.h> + +/* AUXADC Registers */ +#define AUXADC_CON0_V 0x000 +#define AUXADC_CON1_V 0x004 +#define AUXADC_CON1_SET_V 0x008 +#define AUXADC_CON1_CLR_V 0x00c +#define AUXADC_CON2_V 0x010 +#define AUXADC_DATA(channel) (0x14 + (channel) * 4) +#define AUXADC_MISC_V 0x094 + +#define AUXADC_CON1_CHANNEL(x) BIT(x) + +#define APMIXED_SYS_TS_CON1 0x604 + +/* Thermal Controller Registers */ +#define TEMP_MONCTL0 0x000 +#define TEMP_MONCTL1 0x004 +#define TEMP_MONCTL2 0x008 +#define TEMP_MONIDET0 0x014 +#define TEMP_MONIDET1 0x018 +#define TEMP_MSRCTL0 0x038 +#define TEMP_AHBPOLL 0x040 +#define TEMP_AHBTO 0x044 +#define TEMP_ADCPNP0 0x048 +#define TEMP_ADCPNP1 0x04c +#define TEMP_ADCPNP2 0x050 +#define TEMP_ADCPNP3 0x0b4 + +#define TEMP_ADCMUX 0x054 +#define TEMP_ADCEN 0x060 +#define TEMP_PNPMUXADDR 0x064 +#define TEMP_ADCMUXADDR 0x068 +#define TEMP_ADCENADDR 0x074 +#define TEMP_ADCVALIDADDR 0x078 +#define TEMP_ADCVOLTADDR 0x07c +#define TEMP_RDCTRL 0x080 +#define TEMP_ADCVALIDMASK 0x084 +#define TEMP_ADCVOLTAGESHIFT 0x088 +#define TEMP_ADCWRITECTRL 0x08c +#define TEMP_MSR0 0x090 +#define TEMP_MSR1 0x094 +#define TEMP_MSR2 0x098 +#define TEMP_MSR3 0x0B8 + +#define TEMP_SPARE0 0x0f0 + +#define PTPCORESEL 0x400 + +#define TEMP_MONCTL1_PERIOD_UNIT(x) ((x) & 0x3ff) + +#define TEMP_MONCTL2_FILTER_INTERVAL(x) (((x) & 0x3ff)) << 16 +#define TEMP_MONCTL2_SENSOR_INTERVAL(x) ((x) & 0x3ff) + +#define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x) (x) + +#define TEMP_ADCWRITECTRL_ADC_PNP_WRITE BIT(0) +#define TEMP_ADCWRITECTRL_ADC_MUX_WRITE BIT(1) + +#define TEMP_ADCVALIDMASK_VALID_HIGH BIT(5) +#define TEMP_ADCVALIDMASK_VALID_POS(bit) (bit) + +#define MT8173_TS1 0 +#define MT8173_TS2 1 +#define MT8173_TS3 2 +#define MT8173_TS4 3 +#define MT8173_TSABB 4 + +/* AUXADC channel 11 is used for the temperature sensors */ +#define MT8173_TEMP_AUXADC_CHANNEL 11 + +/* The total number of temperature sensors in the MT8173 */ +#define MT8173_NUM_SENSORS 5 + +/* The number of banks in the MT8173 */ +#define MT8173_NUM_ZONES 4 + +/* The number of sensing points per bank */ +#define MT8173_NUM_SENSORS_PER_ZONE 4 + +/* Layout of the fuses providing the calibration data */ +#define MT8173_CALIB_BUF0_VALID (1 << 0) +#define MT8173_CALIB_BUF1_ADC_GE(x) (((x) >> 22 ) & 0x3ff) +#define MT8173_CALIB_BUF0_VTS_TS1(x) (((x) >> 17 ) & 0x1ff) +#define MT8173_CALIB_BUF0_VTS_TS2(x) (((x) >> 8 ) & 0x1ff) +#define MT8173_CALIB_BUF1_VTS_TS3(x) (((x) >> 0 ) & 0x1ff) +#define MT8173_CALIB_BUF2_VTS_TS4(x) (((x) >> 23 ) & 0x1ff) +#define MT8173_CALIB_BUF2_VTS_TSABB(x) (((x) >> 14 ) & 0x1ff) +#define MT8173_CALIB_BUF0_DEGC_CALI(x) (((x) >> 1 ) & 0x3f) +#define MT8173_CALIB_BUF0_O_SLOPE(x) (((x) >> 26 ) & 0x3f) + +#define THERMAL_NAME "mtk-thermal" + +struct mtk_thermal; + +struct mtk_thermal_bank { + struct mtk_thermal *mt; + int id; +}; + +struct mtk_thermal { + struct device *dev; + void __iomem *thermal_base; + + struct clk *clk_peri_therm; + struct clk *clk_auxadc; + + struct mtk_thermal_bank banks[MT8173_NUM_ZONES]; + + struct mutex lock; + + /* Calibration values */ + s32 adc_ge; + s32 degc_cali; + s32 o_slope; + s32 vts[MT8173_NUM_SENSORS]; + + struct thermal_zone_device *tzd; +}; + +struct mtk_thermal_bank_cfg { + unsigned int num_sensors; + unsigned int sensors[MT8173_NUM_SENSORS_PER_ZONE]; +}; + +static const int sensor_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 }; + +/* + * The MT8173 thermal controller has four banks. Each bank can read up to + * four temperature sensors simultaneously. The MT8173 has a total of 5 + * temperature sensors. We use each bank to measure a certain area of the + * SoC. Since TS2 is located centrally in the SoC it is influenced by multiple + * areas, hence is used in different banks. + * + * The thermal core only gets the maximum temperature of all banks, so + * the bank concept wouldn't be necessary here. However, the SVS (Smart + * Voltage Scaling) unit makes its decisions based on the same bank + * data, and this indeed needs the temperatures of the individual banks + * for making better decisions. + */ +static const struct mtk_thermal_bank_cfg bank_data[] = { + { + .num_sensors = 2, + .sensors = { MT8173_TS2, MT8173_TS3 }, + }, { + .num_sensors = 2, + .sensors = { MT8173_TS2, MT8173_TS4 }, + }, { + .num_sensors = 3, + .sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB }, + }, { + .num_sensors = 1, + .sensors = { MT8173_TS2 }, + }, +}; + +struct mtk_thermal_sense_point { + int msr; + int adcpnp; +}; + +static const struct mtk_thermal_sense_point + sensing_points[MT8173_NUM_SENSORS_PER_ZONE] = { + { + .msr = TEMP_MSR0, + .adcpnp = TEMP_ADCPNP0, + }, { + .msr = TEMP_MSR1, + .adcpnp = TEMP_ADCPNP1, + }, { + .msr = TEMP_MSR2, + .adcpnp = TEMP_ADCPNP2, + }, { + .msr = TEMP_MSR3, + .adcpnp = TEMP_ADCPNP3, + }, +}; + +/** + * raw_to_mcelsius - convert a raw ADC value to mcelsius + * @mt: The thermal controller + * @raw: raw ADC value + * + * This converts the raw ADC value to mcelsius using the SoC specific + * calibration constants + */ +static int raw_to_mcelsius(struct mtk_thermal *mt, int sensno, s32 raw) +{ + s32 tmp; + + raw &= 0xfff; + + tmp = 203450520 << 3; + tmp /= 165 + mt->o_slope; + tmp /= 10000 + mt->adc_ge; + tmp *= raw - mt->vts[sensno] - 3350; + tmp >>= 3; + + return mt->degc_cali * 500 - tmp; +} + +/** + * mtk_thermal_get_bank - get bank + * @bank: The bank + * + * The bank registers are banked, we have to select a bank in the + * PTPCORESEL register to access it. + */ +static void mtk_thermal_get_bank(struct mtk_thermal_bank *bank) +{ + struct mtk_thermal *mt = bank->mt; + u32 val; + + mutex_lock(&mt->lock); + + val = readl(mt->thermal_base + PTPCORESEL); + val &= ~0xf; + val |= bank->id; + writel(val, mt->thermal_base + PTPCORESEL); +} + +/** + * mtk_thermal_put_bank - release bank + * @bank: The bank + * + * release a bank previously taken with mtk_thermal_get_bank, + */ +static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank) +{ + struct mtk_thermal *mt = bank->mt; + + mutex_unlock(&mt->lock); +} + +/** + * mtk_thermal_bank_temperature - get the temperature of a bank + * @bank: The bank + * + * The temperature of a bank is considered the maximum temperature of + * the sensors associated to the bank. + */ +static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank) +{ + struct mtk_thermal *mt = bank->mt; + int temp, i, max; + u32 raw; + + temp = max = INT_MIN; + + for (i = 0; i < bank_data[bank->id].num_sensors; i++) { + raw = readl(mt->thermal_base + sensing_points[i].msr); + + temp = raw_to_mcelsius(mt, bank_data[bank->id].sensors[i], raw); + + /* + * The first read of a sensor often contains very high bogus + * temperature value. Filter these out so that the system does + * not immediately shut down. + */ + if (temp > 200000) + temp = 0; + + if (temp > max) + max = temp; + } + + return max; +} + +static int mtk_read_temp(void *data, int *temperature) +{ + struct mtk_thermal *mt = data; + int i; + int tempmax = INT_MIN; + + for (i = 0; i < MT8173_NUM_ZONES; i++) { + struct mtk_thermal_bank *bank = &mt->banks[i]; + + mtk_thermal_get_bank(bank); + + tempmax = max(tempmax, mtk_thermal_bank_temperature(bank)); + + mtk_thermal_put_bank(bank); + } + + *temperature = tempmax; + + return 0; +} + +static const struct thermal_zone_of_device_ops mtk_thermal_ops = { + .get_temp = mtk_read_temp, +}; + +static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num, + u32 apmixed_phys_base, u32 auxadc_phys_base) +{ + struct mtk_thermal_bank *bank = &mt->banks[num]; + const struct mtk_thermal_bank_cfg *cfg = &bank_data[num]; + int i; + + bank->id = num; + bank->mt = mt; + + mtk_thermal_get_bank(bank); + + /* bus clock 66M counting unit is 12 * 15.15ns * 256 = 46.540us */ + writel(TEMP_MONCTL1_PERIOD_UNIT(12), mt->thermal_base + TEMP_MONCTL1); + + /* + * filt interval is 1 * 46.540us = 46.54us, + * sen interval is 429 * 46.540us = 19.96ms + */ + writel(TEMP_MONCTL2_FILTER_INTERVAL(1) | + TEMP_MONCTL2_SENSOR_INTERVAL(429), + mt->thermal_base + TEMP_MONCTL2); + + /* poll is set to 10u */ + writel(TEMP_AHBPOLL_ADC_POLL_INTERVAL(768), + mt->thermal_base + TEMP_AHBPOLL); + + /* temperature sampling control, 1 sample */ + writel(0x0, mt->thermal_base + TEMP_MSRCTL0); + + /* exceed this polling time, IRQ would be inserted */ + writel(0xffffffff, mt->thermal_base + TEMP_AHBTO); + + /* number of interrupts per event, 1 is enough */ + writel(0x0, mt->thermal_base + TEMP_MONIDET0); + writel(0x0, mt->thermal_base + TEMP_MONIDET1); + + /* + * The MT8173 thermal controller does not have its own ADC. Instead it + * uses AHB bus accesses to control the AUXADC. To do this the thermal + * controller has to be programmed with the physical addresses of the + * AUXADC registers and with the various bit positions in the AUXADC. + * Also the thermal controller controls a mux in the APMIXEDSYS register + * space. + */ + + /* + * this value will be stored to TEMP_PNPMUXADDR (TEMP_SPARE0) + * automatically by hw + */ + writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCMUX); + + /* AHB address for auxadc mux selection */ + writel(auxadc_phys_base + AUXADC_CON1_CLR_V, + mt->thermal_base + TEMP_ADCMUXADDR); + + /* AHB address for pnp sensor mux selection */ + writel(apmixed_phys_base + APMIXED_SYS_TS_CON1, + mt->thermal_base + TEMP_PNPMUXADDR); + + /* AHB value for auxadc enable */ + writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCEN); + + /* AHB address for auxadc enable (channel 0 immediate mode selected) */ + writel(auxadc_phys_base + AUXADC_CON1_SET_V, + mt->thermal_base + TEMP_ADCENADDR); + + /* AHB address for auxadc valid bit */ + writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL), + mt->thermal_base + TEMP_ADCVALIDADDR); + + /* AHB address for auxadc voltage output */ + writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL), + mt->thermal_base + TEMP_ADCVOLTADDR); + + /* read valid & voltage are at the same register */ + writel(0x0, mt->thermal_base + TEMP_RDCTRL); + + /* indicate where the valid bit is */ + writel(TEMP_ADCVALIDMASK_VALID_HIGH | TEMP_ADCVALIDMASK_VALID_POS(12), + mt->thermal_base + TEMP_ADCVALIDMASK); + + /* no shift */ + writel(0x0, mt->thermal_base + TEMP_ADCVOLTAGESHIFT); + + /* enable auxadc mux write transaction */ + writel(TEMP_ADCWRITECTRL_ADC_MUX_WRITE, + mt->thermal_base + TEMP_ADCWRITECTRL); + + for (i = 0; i < cfg->num_sensors; i++) + writel(sensor_mux_values[cfg->sensors[i]], + mt->thermal_base + sensing_points[i].adcpnp); + + writel((1 << cfg->num_sensors) - 1, mt->thermal_base + TEMP_MONCTL0); + + writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE | TEMP_ADCWRITECTRL_ADC_MUX_WRITE, + mt->thermal_base + TEMP_ADCWRITECTRL); + + mtk_thermal_put_bank(bank); +} + +static u64 of_get_phys_base(struct device_node *np) +{ + u64 size64; + const __be32 *regaddr_p; + + regaddr_p = of_get_address(np, 0, &size64, NULL); + if (!regaddr_p) + return OF_BAD_ADDR; + + return of_translate_address(np, regaddr_p); +} + +static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt) +{ + struct nvmem_cell *cell; + u32 *buf; + size_t len; + int i, ret = 0; + + /* Start with default values */ + mt->adc_ge = 512; + for (i = 0; i < MT8173_NUM_SENSORS; i++) + mt->vts[i] = 260; + mt->degc_cali = 40; + mt->o_slope = 0; + + cell = nvmem_cell_get(dev, "calibration-data"); + if (IS_ERR(cell)) { + if (PTR_ERR(cell) == -EPROBE_DEFER) + return PTR_ERR(cell); + return 0; + } + + buf = (u32 *)nvmem_cell_read(cell, &len); + + nvmem_cell_put(cell); + + if (IS_ERR(buf)) + return PTR_ERR(buf); + + if (len < 3 * sizeof(u32)) { + dev_warn(dev, "invalid calibration data\n"); + ret = -EINVAL; + goto out; + } + + if (buf[0] & MT8173_CALIB_BUF0_VALID) { + mt->adc_ge = MT8173_CALIB_BUF1_ADC_GE(buf[1]); + mt->vts[MT8173_TS1] = MT8173_CALIB_BUF0_VTS_TS1(buf[0]); + mt->vts[MT8173_TS2] = MT8173_CALIB_BUF0_VTS_TS2(buf[0]); + mt->vts[MT8173_TS3] = MT8173_CALIB_BUF1_VTS_TS3(buf[1]); + mt->vts[MT8173_TS4] = MT8173_CALIB_BUF2_VTS_TS4(buf[2]); + mt->vts[MT8173_TSABB] = MT8173_CALIB_BUF2_VTS_TSABB(buf[2]); + mt->degc_cali = MT8173_CALIB_BUF0_DEGC_CALI(buf[0]); + mt->o_slope = MT8173_CALIB_BUF0_O_SLOPE(buf[0]); + } else { + dev_info(dev, "Device not calibrated, using default calibration values\n"); + } + +out: + kfree(buf); + + return ret; +} + +static int mtk_thermal_probe(struct platform_device *pdev) +{ + int ret, i; + struct device_node *auxadc, *apmixedsys, *np = pdev->dev.of_node; + struct mtk_thermal *mt; + struct resource *res; + u64 auxadc_phys_base, apmixed_phys_base; + + mt = devm_kzalloc(&pdev->dev, sizeof(*mt), GFP_KERNEL); + if (!mt) + return -ENOMEM; + + mt->clk_peri_therm = devm_clk_get(&pdev->dev, "therm"); + if (IS_ERR(mt->clk_peri_therm)) + return PTR_ERR(mt->clk_peri_therm); + + mt->clk_auxadc = devm_clk_get(&pdev->dev, "auxadc"); + if (IS_ERR(mt->clk_auxadc)) + return PTR_ERR(mt->clk_auxadc); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + mt->thermal_base = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(mt->thermal_base)) + return PTR_ERR(mt->thermal_base); + + ret = mtk_thermal_get_calibration_data(&pdev->dev, mt); + if (ret) + return ret; + + mutex_init(&mt->lock); + + mt->dev = &pdev->dev; + + auxadc = of_parse_phandle(np, "mediatek,auxadc", 0); + if (!auxadc) { + dev_err(&pdev->dev, "missing auxadc node\n"); + return -ENODEV; + } + + auxadc_phys_base = of_get_phys_base(auxadc); + + of_node_put(auxadc); + + if (auxadc_phys_base == OF_BAD_ADDR) { + dev_err(&pdev->dev, "Can't get auxadc phys address\n"); + return -EINVAL; + } + + apmixedsys = of_parse_phandle(np, "mediatek,apmixedsys", 0); + if (!apmixedsys) { + dev_err(&pdev->dev, "missing apmixedsys node\n"); + return -ENODEV; + } + + apmixed_phys_base = of_get_phys_base(apmixedsys); + + of_node_put(apmixedsys); + + if (apmixed_phys_base == OF_BAD_ADDR) { + dev_err(&pdev->dev, "Can't get auxadc phys address\n"); + return -EINVAL; + } + + ret = clk_prepare_enable(mt->clk_auxadc); + if (ret) { + dev_err(&pdev->dev, "Can't enable auxadc clk: %d\n", ret); + return ret; + } + + ret = device_reset(&pdev->dev); + if (ret) + goto err_disable_clk_auxadc; + + ret = clk_prepare_enable(mt->clk_peri_therm); + if (ret) { + dev_err(&pdev->dev, "Can't enable peri clk: %d\n", ret); + goto err_disable_clk_auxadc; + } + + for (i = 0; i < MT8173_NUM_ZONES; i++) + mtk_thermal_init_bank(mt, i, apmixed_phys_base, auxadc_phys_base); + + platform_set_drvdata(pdev, mt); + + mt->tzd = thermal_zone_of_sensor_register(&pdev->dev, 0, mt, + &mtk_thermal_ops); + if (IS_ERR(mt->tzd)) + goto err_register; + + return 0; + +err_register: + clk_disable_unprepare(mt->clk_peri_therm); + +err_disable_clk_auxadc: + clk_disable_unprepare(mt->clk_auxadc); + + return ret; +} + +static int mtk_thermal_remove(struct platform_device *pdev) +{ + struct mtk_thermal *mt = platform_get_drvdata(pdev); + + thermal_zone_of_sensor_unregister(&pdev->dev, mt->tzd); + + clk_disable_unprepare(mt->clk_peri_therm); + clk_disable_unprepare(mt->clk_auxadc); + + return 0; +} + +static const struct of_device_id mtk_thermal_of_match[] = { + { + .compatible = "mediatek,mt8173-thermal", + }, { + }, +}; + +static struct platform_driver mtk_thermal_driver = { + .probe = mtk_thermal_probe, + .remove = mtk_thermal_remove, + .driver = { + .name = THERMAL_NAME, + .of_match_table = mtk_thermal_of_match, + }, +}; + +module_platform_driver(mtk_thermal_driver); + +MODULE_AUTHOR("Sascha Hauer <s.hauer@pengutronix.de"); +MODULE_AUTHOR("Hanyi Wu <hanyi.wu@mediatek.com>"); +MODULE_DESCRIPTION("Mediatek thermal driver"); +MODULE_LICENSE("GPL v2");
This adds support for the Mediatek thermal controller found on MT8173 and likely other SoCs. The controller is a bit special. It does not have its own ADC, instead it controls the on-SoC AUXADC via AHB bus accesses. For this reason we need the physical address of the AUXADC. Also it controls a mux using AHB bus accesses, so we need the APMIXEDSYS physical address aswell. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- drivers/thermal/Kconfig | 8 + drivers/thermal/Makefile | 1 + drivers/thermal/mtk_thermal.c | 623 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 632 insertions(+) create mode 100644 drivers/thermal/mtk_thermal.c