workqueue to be able to force a shutdown of the system when orderly
shutdown is not successful after a configurable time period.
Reported-by: Nishanth Menon
Signed-off-by: Keerthy
---
* Changed the comment style
* Added backup shutdown call before orderly_poweroff
drivers/thermal/Kconfig
.
Make sure that orderly_poweroff is called only once.
Reported-by: Nishanth Menon <n...@ti.com>
Signed-off-by: Keerthy <j-keer...@ti.com>
---
Changes in v2:
* Added a global mutex to serialize poweroff code sequence.
drivers/thermal/thermal_core.c | 9 -
1 file changed, 8 i
.
Make sure that orderly_poweroff is called only once.
Reported-by: Nishanth Menon
Signed-off-by: Keerthy
---
Changes in v2:
* Added a global mutex to serialize poweroff code sequence.
drivers/thermal/thermal_core.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/dri
On Thursday 13 April 2017 10:36 AM, Eduardo Valentin wrote:
> Hey,
>
> On Wed, Apr 12, 2017 at 02:42:12PM +0530, Keerthy wrote:
>> thermal_zone_device_check --> thermal_zone_device_update -->
>> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff
On Thursday 13 April 2017 10:36 AM, Eduardo Valentin wrote:
> Hey,
>
> On Wed, Apr 12, 2017 at 02:42:12PM +0530, Keerthy wrote:
>> thermal_zone_device_check --> thermal_zone_device_update -->
>> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff
Add power hold and power controller properties to palmas node.
This is needed to shutdown pmic correctly on boards with
powerhold set.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
arch/arm/boot/dts/dra7-evm.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-e
Add power hold and power controller properties to palmas node.
This is needed to shutdown pmic correctly on boards with
powerhold set.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/dra7-evm.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot
On Thursday 13 April 2017 12:13 AM, Tero Kristo wrote:
> On 12/04/17 20:24, Eduardo Valentin wrote:
>> On Wed, Apr 12, 2017 at 10:41:00PM +0530, Keerthy wrote:
>>>
>>>
>>> On Wednesday 12 April 2017 10:38 PM, Grygorii Strashko wrote:
>>>>
On Thursday 13 April 2017 12:13 AM, Tero Kristo wrote:
> On 12/04/17 20:24, Eduardo Valentin wrote:
>> On Wed, Apr 12, 2017 at 10:41:00PM +0530, Keerthy wrote:
>>>
>>>
>>> On Wednesday 12 April 2017 10:38 PM, Grygorii Strashko wrote:
>>>>
On Wednesday 12 April 2017 10:38 PM, Grygorii Strashko wrote:
>
>
> On 04/12/2017 11:44 AM, Keerthy wrote:
>>
>>
>> On Wednesday 12 April 2017 10:01 PM, Grygorii Strashko wrote:
>>>
>>>
>>> On 04/12/2017 10:44 AM, Eduardo Valentin
On Wednesday 12 April 2017 10:38 PM, Grygorii Strashko wrote:
>
>
> On 04/12/2017 11:44 AM, Keerthy wrote:
>>
>>
>> On Wednesday 12 April 2017 10:01 PM, Grygorii Strashko wrote:
>>>
>>>
>>> On 04/12/2017 10:44 AM, Eduardo Valentin
On Wednesday 12 April 2017 10:24 PM, Eduardo Valentin wrote:
> Keerthy,
>
> On Wed, Apr 12, 2017 at 10:14:36PM +0530, Keerthy wrote:
>>
>>
>> On Wednesday 12 April 2017 10:01 PM, Grygorii Strashko wrote:
>>>
>>>
>>> On 0
On Wednesday 12 April 2017 10:24 PM, Eduardo Valentin wrote:
> Keerthy,
>
> On Wed, Apr 12, 2017 at 10:14:36PM +0530, Keerthy wrote:
>>
>>
>> On Wednesday 12 April 2017 10:01 PM, Grygorii Strashko wrote:
>>>
>>>
>>> On 0
;>> for 2) Cancel all the scheduled work queues to monitor the
>>>> temperature.
>>>> I will take some more time to make it and test.
>>>>
>>>> Is that okay? Or you want me to send both together?
>>>>
>>> I think you can
;>> for 2) Cancel all the scheduled work queues to monitor the
>>>> temperature.
>>>> I will take some more time to make it and test.
>>>>
>>>> Is that okay? Or you want me to send both together?
>>>>
>>> I think you can
off in 2 seconds you still end up calling 4 to 8 times
depending on 500mS or 250mS delay.
>
>>>> If we're using orderly_poweroff() for emergency power off, we have
>>>> to
>>>> use it correctly.
>>>>
>
> I agree. But there it nothin
off in 2 seconds you still end up calling 4 to 8 times
depending on 500mS or 250mS delay.
>
>>>> If we're using orderly_poweroff() for emergency power off, we have
>>>> to
>>>> use it correctly.
>>>>
>
> I agree. But there it nothin
.
Make sure that orderly_poweroff is called only once.
Fixes: 0c01ebbfd3caf1d ("Thermal: Remove throttling logic out of thermal_sys.c")
Reported-by: Nishanth Menon <n...@ti.com>
Signed-off-by: Keerthy <j-keer...@ti.com>
---
drivers/thermal/thermal_core.c | 4 +++-
1 file changed, 3
.
Make sure that orderly_poweroff is called only once.
Fixes: 0c01ebbfd3caf1d ("Thermal: Remove throttling logic out of thermal_sys.c")
Reported-by: Nishanth Menon
Signed-off-by: Keerthy
---
drivers/thermal/thermal_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -
On Wednesday 12 April 2017 01:56 PM, Zhang Rui wrote:
> On Wed, 2017-04-12 at 13:25 +0530, Keerthy wrote:
>>
>> On Wednesday 12 April 2017 09:35 AM, Eduardo Valentin wrote:
>>>
>>> Keerthy,
>>>
>>> On Wed, Apr 12, 2017 at 09:09:36AM +0530, Keert
On Wednesday 12 April 2017 01:56 PM, Zhang Rui wrote:
> On Wed, 2017-04-12 at 13:25 +0530, Keerthy wrote:
>>
>> On Wednesday 12 April 2017 09:35 AM, Eduardo Valentin wrote:
>>>
>>> Keerthy,
>>>
>>> On Wed, Apr 12, 2017 at 09:09:36AM +0530, Keert
On Wednesday 12 April 2017 09:35 AM, Eduardo Valentin wrote:
> Keerthy,
>
> On Wed, Apr 12, 2017 at 09:09:36AM +0530, Keerthy wrote:
>>
>>
>> On Wednesday 12 April 2017 08:50 AM, Zhang Rui wrote:
>>> On Wed, 2017-04-12 at 08:19 +0530, Keerthy wrote:
>>
On Wednesday 12 April 2017 09:35 AM, Eduardo Valentin wrote:
> Keerthy,
>
> On Wed, Apr 12, 2017 at 09:09:36AM +0530, Keerthy wrote:
>>
>>
>> On Wednesday 12 April 2017 08:50 AM, Zhang Rui wrote:
>>> On Wed, 2017-04-12 at 08:19 +0530, Keerthy wrote:
>>
On Wednesday 12 April 2017 09:35 AM, Eduardo Valentin wrote:
> Keerthy,
>
> On Wed, Apr 12, 2017 at 09:09:36AM +0530, Keerthy wrote:
>>
>>
>> On Wednesday 12 April 2017 08:50 AM, Zhang Rui wrote:
>>> On Wed, 2017-04-12 at 08:19 +0530, Keerthy wrote:
>>
On Wednesday 12 April 2017 09:35 AM, Eduardo Valentin wrote:
> Keerthy,
>
> On Wed, Apr 12, 2017 at 09:09:36AM +0530, Keerthy wrote:
>>
>>
>> On Wednesday 12 April 2017 08:50 AM, Zhang Rui wrote:
>>> On Wed, 2017-04-12 at 08:19 +0530, Keerthy wrote:
>>
On Wednesday 12 April 2017 08:50 AM, Zhang Rui wrote:
> On Wed, 2017-04-12 at 08:19 +0530, Keerthy wrote:
>>
>> On Tuesday 11 April 2017 10:59 PM, Eduardo Valentin wrote:
>>>
>>> Hey,
>>>
>>> On Fri, Mar 31, 2017 at 12:00:20PM +0530, Keerthy
On Wednesday 12 April 2017 08:50 AM, Zhang Rui wrote:
> On Wed, 2017-04-12 at 08:19 +0530, Keerthy wrote:
>>
>> On Tuesday 11 April 2017 10:59 PM, Eduardo Valentin wrote:
>>>
>>> Hey,
>>>
>>> On Fri, Mar 31, 2017 at 12:00:20PM +0530, Keerthy
On Tuesday 11 April 2017 10:59 PM, Eduardo Valentin wrote:
> Hey,
>
> On Fri, Mar 31, 2017 at 12:00:20PM +0530, Keerthy wrote:
>> orderly_poweroff is triggered when a graceful shutdown
>> of system is desired. This may be used in many critical states of the
>> ker
On Tuesday 11 April 2017 10:59 PM, Eduardo Valentin wrote:
> Hey,
>
> On Fri, Mar 31, 2017 at 12:00:20PM +0530, Keerthy wrote:
>> orderly_poweroff is triggered when a graceful shutdown
>> of system is desired. This may be used in many critical states of the
>> ker
workqueue to be able to force a shutdown of the system when orderly
shutdown is not successful after a configurable time period.
Reported-by: Nishanth Menon <n...@ti.com>
Signed-off-by: Keerthy <j-keer...@ti.com>
---
drivers/thermal/Kconfig| 13 +
drivers/thermal/th
workqueue to be able to force a shutdown of the system when orderly
shutdown is not successful after a configurable time period.
Reported-by: Nishanth Menon
Signed-off-by: Keerthy
---
drivers/thermal/Kconfig| 13 +
drivers/thermal/thermal_core.c | 42
On Wednesday 29 March 2017 10:07 AM, Eduardo Valentin wrote:
> Keerthy,
>
> On Fri, Mar 24, 2017 at 07:26:10AM -0700, Tony Lindgren wrote:
>> * Keerthy <j-keer...@ti.com> [170323 20:29]:
>>>
>>>
>>> On Friday 24 March 2017 02:22 AM, Tony Lindgren
On Wednesday 29 March 2017 10:07 AM, Eduardo Valentin wrote:
> Keerthy,
>
> On Fri, Mar 24, 2017 at 07:26:10AM -0700, Tony Lindgren wrote:
>> * Keerthy [170323 20:29]:
>>>
>>>
>>> On Friday 24 March 2017 02:22 AM, Tony Lin
On Wednesday 29 March 2017 10:03 AM, Eduardo Valentin wrote:
> On Thu, Mar 09, 2017 at 01:35:57PM +0530, Keerthy wrote:
>> Currently the slope and offset values for calculating the
>> hot spot temperature of a particular thermal zone is part
>> of driver data. Pass them he
On Wednesday 29 March 2017 10:03 AM, Eduardo Valentin wrote:
> On Thu, Mar 09, 2017 at 01:35:57PM +0530, Keerthy wrote:
>> Currently the slope and offset values for calculating the
>> hot spot temperature of a particular thermal zone is part
>> of driver data. Pass them he
On Friday 24 March 2017 05:00 PM, Lee Jones wrote:
> On Fri, 24 Mar 2017, Keerthy wrote:
>
>>
>>
>> On Tuesday 22 November 2016 06:33 PM, Lee Jones wrote:
>>> On Thu, 10 Nov 2016, Keerthy wrote:
>>>
>>>> POWERHOLD signal has h
On Friday 24 March 2017 05:00 PM, Lee Jones wrote:
> On Fri, 24 Mar 2017, Keerthy wrote:
>
>>
>>
>> On Tuesday 22 November 2016 06:33 PM, Lee Jones wrote:
>>> On Thu, 10 Nov 2016, Keerthy wrote:
>>>
>>>> POWERHOLD signal has h
On Tuesday 22 November 2016 06:33 PM, Lee Jones wrote:
> On Thu, 10 Nov 2016, Keerthy wrote:
>
>> POWERHOLD signal has higher priority over the DEV_ON bit.
>> So power off will not happen if the POWERHOLD is held high.
>> Hence reset the MUX to GPIO_7 mode
On Tuesday 22 November 2016 06:33 PM, Lee Jones wrote:
> On Thu, 10 Nov 2016, Keerthy wrote:
>
>> POWERHOLD signal has higher priority over the DEV_ON bit.
>> So power off will not happen if the POWERHOLD is held high.
>> Hence reset the MUX to GPIO_7 mode
On Friday 24 March 2017 02:22 AM, Tony Lindgren wrote:
> * Keerthy <j-keer...@ti.com> [170321 20:45]:
>>
>>
>> On Thursday 09 March 2017 01:35 PM, Keerthy wrote:
>>> Currently the slope and offset values for calculating the
>>> hot spot tem
On Friday 24 March 2017 02:22 AM, Tony Lindgren wrote:
> * Keerthy [170321 20:45]:
>>
>>
>> On Thursday 09 March 2017 01:35 PM, Keerthy wrote:
>>> Currently the slope and offset values for calculating the
>>> hot spot temperature of a particular therma
On Thursday 09 March 2017 01:35 PM, Keerthy wrote:
> Currently the slope and offset values for calculating the
> hot spot temperature of a particular thermal zone is part
> of driver data. Pass them here instead and obtain the values
> while of node parsing.
>
> Te
On Thursday 09 March 2017 01:35 PM, Keerthy wrote:
> Currently the slope and offset values for calculating the
> hot spot temperature of a particular thermal zone is part
> of driver data. Pass them here instead and obtain the values
> while of node parsing.
>
> Te
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
arch/arm/boot/dts/omap443x.dtsi | 4
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/omap443x.dtsi | 4
1 file changed, 4
OMAP3 changes along with DRA7/OMAP4/OMAP5.
Keerthy (8):
arm: dts: omap3: Add cpu_thermal zone
ARM: DRA7: Thermal: Add slope and offset values
ARM: OMAP5: Thermal: Add slope and offset values
ARM: OMAP443x: Thermal: Add slope and offset values
ARM: OMAP4460: Thermal: Add slope and offset
OMAP3 changes along with DRA7/OMAP4/OMAP5.
Keerthy (8):
arm: dts: omap3: Add cpu_thermal zone
ARM: DRA7: Thermal: Add slope and offset values
ARM: OMAP5: Thermal: Add slope and offset values
ARM: OMAP443x: Thermal: Add slope and offset values
ARM: OMAP4460: Thermal: Add slope and offset
Currently slope and offset values for calculating the hot spot
temperature of a thermal zone is being taken directly from driver
data. So fetch them from device tree.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 4 ++--
1 file chan
Currently slope and offset values for calculating the hot spot
temperature of a thermal zone is being taken directly from driver
data. So fetch them from device tree.
Signed-off-by: Keerthy
---
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 4 ++--
1 file changed, 2 insertions(+), 2
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
arch/arm/boot/dts/omap4460.dtsi | 4
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/omap4460.dtsi | 4
1 file changed, 4
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 9 +
ti_thermal_expose_sensor always takes the
devm_thermal_zone_of_sensor_register call for registration
with the device tree nodes present for all the bandgap sensors
for omap3/4/5 and dra7 family. There are large chunks of unused
code. Removing all of them.
Signed-off-by: Keerthy <j-keer...@ti.
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/omap5.dtsi | 9 +
1 file changed, 9
ti_thermal_expose_sensor always takes the
devm_thermal_zone_of_sensor_register call for registration
with the device tree nodes present for all the bandgap sensors
for omap3/4/5 and dra7 family. There are large chunks of unused
code. Removing all of them.
Signed-off-by: Keerthy
---
drivers
Now that slope and offset data are being passed from
device tree no need to populate in driver data.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
drivers/thermal/ti-soc-thermal/dra752-thermal-data.c | 10 --
drivers/thermal/ti-soc-thermal/omap3-thermal-data.c | 4
drivers/t
Add cpu_thermal zone.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
arch/arm/boot/dts/omap3-cpu-thermal.dtsi | 20
arch/arm/boot/dts/omap34xx.dtsi | 8 ++--
arch/arm/boot/dts/omap36xx.dtsi | 8 ++--
3 files changed, 32 insertions(+), 4 del
Now that slope and offset data are being passed from
device tree no need to populate in driver data.
Signed-off-by: Keerthy
---
drivers/thermal/ti-soc-thermal/dra752-thermal-data.c | 10 --
drivers/thermal/ti-soc-thermal/omap3-thermal-data.c | 4
drivers/thermal/ti-soc-thermal
Add cpu_thermal zone.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/omap3-cpu-thermal.dtsi | 20
arch/arm/boot/dts/omap34xx.dtsi | 8 ++--
arch/arm/boot/dts/omap36xx.dtsi | 8 ++--
3 files changed, 32 insertions(+), 4 deletions(-)
create mode
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
arch/arm/boot/dts/dra7.dts
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/dra7.dtsi | 17 +
1 file changed
On Tuesday 07 March 2017 12:12 AM, Tony Lindgren wrote:
* Keerthy <j-keer...@ti.com> [170301 02:31]:
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while o
On Tuesday 07 March 2017 12:12 AM, Tony Lindgren wrote:
* Keerthy [170301 02:31]:
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Tested
On Saturday 04 March 2017 09:53 PM, Bartosz Golaszewski wrote:
This driver never frees the interrupt descriptors it allocates. Fix
it by using the resource managed version of irq_alloc_descs().
Acked-by: Keerthy <j-keer...@ti.com>
Signed-off-by: Bartosz Golaszewski <
On Saturday 04 March 2017 09:53 PM, Bartosz Golaszewski wrote:
This driver never frees the interrupt descriptors it allocates. Fix
it by using the resource managed version of irq_alloc_descs().
Acked-by: Keerthy
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/gpio-davinci.c | 2
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
arch/arm/boot/dts/omap4460.dtsi | 4
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/omap4460.dtsi | 4
1 file changed, 4
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Tested for the slope and constant values on DRA7-EVM.
Keerthy (7):
ARM: DRA7: Thermal: Add
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Tested for the slope and constant values on DRA7-EVM.
Keerthy (7):
ARM: DRA7: Thermal: Add
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
arch/arm/boot/dts/dra7.dts
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/dra7.dtsi | 17 +
1 file changed
Now that slope and offset data are being passed from
device tree no need to populate in driver data.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
drivers/thermal/ti-soc-thermal/dra752-thermal-data.c | 10 --
drivers/thermal/ti-soc-thermal/omap4-thermal-data.c | 4
drivers/t
Now that slope and offset data are being passed from
device tree no need to populate in driver data.
Signed-off-by: Keerthy
---
drivers/thermal/ti-soc-thermal/dra752-thermal-data.c | 10 --
drivers/thermal/ti-soc-thermal/omap4-thermal-data.c | 4
drivers/thermal/ti-soc-thermal
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
arch/arm/boot/dts/omap443x.dtsi | 4
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/omap443x.dtsi | 4
1 file changed, 4
Currently slope and offset values for calculating the hot spot
temperature of a thermal zone is being taken directly from driver
data. So try fetching it from device tree if not present only then
take it from driver data.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
drivers/thermal/
Currently slope and offset values for calculating the hot spot
temperature of a thermal zone is being taken directly from driver
data. So try fetching it from device tree if not present only then
take it from driver data.
Signed-off-by: Keerthy
---
drivers/thermal/ti-soc-thermal/ti-thermal
ti_thermal_expose_sensor always takes the
devm_thermal_zone_of_sensor_register call for registration
with the device tree nodes present for all the bandgap sensors
for omap3/4/5 and dra7 family. There are large chunks of unused
code. Removing all of them.
Signed-off-by: Keerthy <j-keer...@ti.
ti_thermal_expose_sensor always takes the
devm_thermal_zone_of_sensor_register call for registration
with the device tree nodes present for all the bandgap sensors
for omap3/4/5 and dra7 family. There are large chunks of unused
code. Removing all of them.
Signed-off-by: Keerthy
---
drivers
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy <j-keer...@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 9 +
Currently the slope and offset values for calculating the
hot spot temperature of a particular thermal zone is part
of driver data. Pass them here instead and obtain the values
while of node parsing.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/omap5.dtsi | 9 +
1 file changed, 9
On Friday 02 December 2016 02:35 PM, Keerthy wrote:
Currently the divider selection logic blindly divides the parent_rate
by the clk rate and gives the divider value for the divider clocks
which do not have the CLK_SET_RATE_PARENT flag set. Add the clk divider
table parsing to get the closest
On Friday 02 December 2016 02:35 PM, Keerthy wrote:
Currently the divider selection logic blindly divides the parent_rate
by the clk rate and gives the divider value for the divider clocks
which do not have the CLK_SET_RATE_PARENT flag set. Add the clk divider
table parsing to get the closest
Eduardo,
On Friday 06 January 2017 11:31 AM, Keerthy wrote:
Technical Reference Manual [1] mandates that software should
not be configuring the thermal shutdown thresholds. Hence
removing TSHUT_CONFIG.
Any comments on this?
- Keerthy
[1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf
Eduardo,
On Friday 06 January 2017 11:31 AM, Keerthy wrote:
Technical Reference Manual [1] mandates that software should
not be configuring the thermal shutdown thresholds. Hence
removing TSHUT_CONFIG.
Any comments on this?
- Keerthy
[1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf
On Tuesday 17 January 2017 09:49 PM, Keerthy wrote:
The Davinci GPIO driver is implemented to work with one monolithic
Davinci GPIO platform device which may have up to Y(144) gpios.
The Davinci GPIO driver instantiates number of GPIO chips with
max 32 gpio pins per each during initialization
On Tuesday 17 January 2017 09:49 PM, Keerthy wrote:
The Davinci GPIO driver is implemented to work with one monolithic
Davinci GPIO platform device which may have up to Y(144) gpios.
The Davinci GPIO driver instantiates number of GPIO chips with
max 32 gpio pins per each during initialization
With the current redesign of driver it's not necessary to have
custom .xlate() as the gpiolib will assign default of_gpio_simple_xlate().
Suggested-by: Grygorii Strashko <grygorii.stras...@ti.com>
Signed-off-by: Keerthy <j-keer...@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.
With the current redesign of driver it's not necessary to have
custom .xlate() as the gpiolib will assign default of_gpio_simple_xlate().
Suggested-by: Grygorii Strashko
Signed-off-by: Keerthy
Reviewed-by: Grygorii Strashko
---
drivers/gpio/gpio-davinci.c | 22 --
1 file
gpio2regs is written making an assumption that driver supports only
one instance of gpio controller. Removing this and adding a generic
array so as to support multiple instances of gpio controllers.
Signed-off-by: Keerthy <j-keer...@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.stras.
gpio2regs is written making an assumption that driver supports only
one instance of gpio controller. Removing this and adding a generic
array so as to support multiple instances of gpio controllers.
Signed-off-by: Keerthy
Reviewed-by: Grygorii Strashko
---
Changes in v2:
* Added a comment
Remove redundant blank line.
Signed-off-by: Keerthy <j-keer...@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.stras...@ti.com>
---
include/linux/platform_data/gpio-davinci.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/platform_data/gpio-davinci.h
b/i
Remove redundant blank line.
Signed-off-by: Keerthy
Reviewed-by: Grygorii Strashko
---
include/linux/platform_data/gpio-davinci.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/platform_data/gpio-davinci.h
b/include/linux/platform_data/gpio-davinci.h
index 44ca530..18127c4
Update GPIO driver to support Multiple GPIO controllers by updating
the base of subsequent GPIO chips with total of previous chips
gpio count so that gpio_add_chip gets unique numbers.
Signed-off-by: Keerthy <j-keer...@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.stras...@ti.com>
Update GPIO driver to support Multiple GPIO controllers by updating
the base of subsequent GPIO chips with total of previous chips
gpio count so that gpio_add_chip gets unique numbers.
Signed-off-by: Keerthy
Reviewed-by: Grygorii Strashko
---
drivers/gpio/gpio-davinci.c| 4
chip for all the ngpio
in the controller.
|- --|--- irq_domain (hwirq [0..143]).
The previous discussion on this can be found here:
https://www.spinics.net/lists/linux-omap/msg132869.html
Signed-off-by: Keerthy <j-keer...@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.stras.
chip for all the ngpio
in the controller.
|- --|--- irq_domain (hwirq [0..143]).
The previous discussion on this can be found here:
https://www.spinics.net/lists/linux-omap/msg132869.html
Signed-off-by: Keerthy
Reviewed-by: Grygorii Strashko
---
Changes in v2:
* Optimized irqdata
-design patch.
* Added couple of code clean ups after the re-design.
* Included v2 of https://patchwork.ozlabs.org/patch/710855/
Changes in v3:
* Removed one of the clean up patches. As the macros were needed.
Keerthy (5):
gpio: davinci: Remove gpio2regs function to accommodate multi
-design patch.
* Added couple of code clean ups after the re-design.
* Included v2 of https://patchwork.ozlabs.org/patch/710855/
Changes in v3:
* Removed one of the clean up patches. As the macros were needed.
Keerthy (5):
gpio: davinci: Remove gpio2regs function to accommodate multi
On Tuesday 17 January 2017 08:22 PM, Linus Walleij wrote:
On Wed, Jan 11, 2017 at 6:00 AM, Keerthy <j-keer...@ti.com> wrote:
The Davinci GPIO driver is implemented to work with one monolithic
Davinci GPIO platform device which may have up to Y(144) gpios.
I'm a bit co
901 - 1000 of 2181 matches
Mail list logo
