If we need to restart the watchdog due to someone changing the timeout
interval, stop the watchdog before restarting it. Otherwise, the new
timeout doesn't seem to take.
Signed-off-by: Andrew Chew
---
drivers/watchdog/tegra_wdt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
-off-by: Andrew Chew
Reviewed-by: Guenter Roeck
Tested-by: Stephen Warren
Reviewed-by: Stephen Warren
---
Changes from v6:
Removed kref stuff. We can't think of why it's needed here.
Changes from v5:
Changed license to GPL v2 per Stephen Warren's guidance.
Changes from v4:
-off-by: Andrew Chew
Reviewed-by: Guenter Roeck
Tested-by: Stephen Warren
Reviewed-by: Stephen Warren
---
Changes from v5:
Changed license to GPL v2 per Stephen Warren's guidance.
Changes from v4:
Skip the error check from the platform_get_resources() call, because
devm_ioremap_res
> > +static void tegra_wdt_unref(struct watchdog_device *wdd) {
> > + struct tegra_wdt *wdt = watchdog_get_drvdata(wdd);
> > +
> > + kref_put(&wdt->kref, tegra_wdt_release_resources); }
>
> I forget why these were needed; they seem to do nothing.
The reason I did the whole kref thing was by f
> On 02/06/2014 05:54 PM, Andrew Chew wrote:
> > Add a driver for the hardware watchdogs in NVIDIA Tegra SoCs (Tegra30
> > and later). This driver will configure one watchdog timer that will
> > reset the system in the case of a watchdog timeout.
> >
> > This d
> On 02/06/2014 02:05 PM, Andrew Chew wrote:
> > Add a driver for the hardware watchdogs in NVIDIA Tegra SoCs (Tegra30
> > and later). This driver will configure one watchdog timer that will
> > reset the system in the case of a watchdog timeout.
> >
> > This d
-off-by: Andrew Chew
---
Changes from v4:
Skip the error check from the platform_get_resources() call, because
devm_ioremap_resource() correctly handles the case when res is NULL.
Changes from v3:
Applied Cuenter Roeck 's comments. In particular,
since tegra_wdt_start() and tegra_wdt
-off-by: Andrew Chew
---
Changes from v3:
Applied Cuenter Roeck 's comments. In particular,
since tegra_wdt_start() and tegra_wdt_stop() always return success, skip
error checking for these calls. Also, removed some unnecessarily verbose
logging around which watchdog and timer ID is being
-off-by: Andrew Chew
---
Changes from V2:
Applied all of Stephen Warren's comments.
Modified suspend callback by only stopping the watchdog timer if it was
currently active.
Added some logging during suspend/resume.
Documentation/watchdog/watchdog-parameters.txt | 5 +
drivers/watchdog/Kc
> > +/* Tegra 20 timers */
> > +#define TEGRA20_TIMER1_BASE0x0
> > +#define TEGRA20_TIMER2_BASE0x8
> > +#define TEGRA20_TIMER3_BASE0x50
> > +#define TEGRA20_TIMER4_BASE0x58
> > +
> > +/* Tegra 30 timers */
> > +#define TEGRA30_TIMER1_BASETEGRA20_TIMER1_BASE
>
> On 02/05/2014 01:06 PM, Andrew Chew wrote:
> >> On 02/03/2014 05:17 PM, Andrew Chew wrote:
> >>> There are some differences between tegra20's timer registers and
> >>> tegra30's (and later). For example, tegra30 has more timers. In
> &
> On 02/03/2014 05:17 PM, Andrew Chew wrote:
> > There are some differences between tegra20's timer registers and
> > tegra30's (and later). For example, tegra30 has more timers. In
> > addition, watchdogs are not present in tegra20.
> >
> > Add this
> > > On 01/31/2014 10:29 PM, Andrew Chew wrote:
> > > > There are some differences between tegra20's timer registers and
> > > > tegra30's (and later). For one thing, the watchdogs don't seem to
> > > > be present in tegra20.
> >
> From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
> Sent: Monday, February 03, 2014 11:55 PM
> To: Andrew Chew; t...@linutronix.de; swar...@wwwdotorg.org;
> thierry.red...@gmail.com; r...@landley.net; grant.lik...@linaro.org;
> robh...@kernel.org; abres...@chromium.org; dgr.
-off-by: Andrew Chew
---
Documentation/watchdog/watchdog-parameters.txt | 5 +
drivers/watchdog/Kconfig | 11 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/tegra_wdt.c | 372 +
4 files changed, 389
Added timers that are present in tegra30 and later, that are NOT in tegra20.
Also, some of these timer bases are needed in the tegra watchdog driver, so
separate them out into a header file that both the clocksource driver and
the watchdog driver can share them.
Signed-off-by: Andrew Chew
are there or not.
Signed-off-by: Andrew Chew
Acked-by: Stephen Warren
---
drivers/clocksource/tegra20_timer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clocksource/tegra20_timer.c
b/drivers/clocksource/tegra20_timer.c
index d1869f0..73cfa56 100644
--- a/drivers/c
y any device tree bindings and therefore don't need to review
dt changes separately. This way, everything can be seen within its complete
context.
Andrew Chew (3):
clocksource: tegra: Add nvidia,tegra30-timer compat
clocksource: tegra: Define timer bases in header file
watchdog:
> On 02/03/2014 02:16 PM, Andrew Chew wrote:
> >> On 02/03/2014 11:59 AM, Andrew Chew wrote:
> >>>> On Fri, Jan 31, 2014 at 09:46:51PM +, Andrew Chew wrote:
> >>>>> This optional property can be used to specify which timers are to
> >>>&
> On 02/03/2014 11:59 AM, Andrew Chew wrote:
> >> On Fri, Jan 31, 2014 at 09:46:51PM +0000, Andrew Chew wrote:
> >>> This optional property can be used to specify which timers are to be
> >>> used for hardware watchdog timeouts (via a tegra wdt driver).
> On Fri, Jan 31, 2014 at 09:46:51PM +0000, Andrew Chew wrote:
> > This optional property can be used to specify which timers are to be
> > used for hardware watchdog timeouts (via a tegra wdt driver).
>
> Is there any reason that a particular timer should be used?
I worry
> From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
> Sent: Monday, February 03, 2014 8:40 AM
> To: Andrew Chew; t...@linutronix.de; swar...@wwwdotorg.org;
> thierry.red...@gmail.com; abres...@chromium.org; dgr...@chromium.org;
> kati...@chromium.org
> Cc: linux-kernel@vger
This optional property can be used to specify which timers are to be used
for hardware watchdog timeouts (via a tegra wdt driver).
Signed-off-by: Andrew Chew
---
Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt | 8
1 file changed, 8 insertions(+)
diff --git a
There are some differences between tegra20's timer registers and tegra30's
(and later). For one thing, the watchdogs don't seem to be present in
tegra20. Add this compatibility string in order to be able to distinguish
whether the watchdogs are there or not.
Signed-off-
> On 07/27/2013 03:55 AM, Laxman Dewangan wrote:
> > On Saturday 27 July 2013 03:42 AM, Andrew Chew wrote:
> >> I wrote:
> >>> Andrew wrote:
> >>>> [adding a third pinmux configuration property to Palmas's DT]
> >>>
> >>
> How does this interact with the pinctrl driver that Laxman just
> sent for Palmas?
>
> https://lkml.org/lkml/2013/7/26/141
> [PATCH 0/2] pinctrl: palmas: add pincontrol driver
> >>>
> >>> Thanks for pointing this out. Given this:
> >>>
> >>> +Optional properties:
> >>> +
> >> How does this interact with the pinctrl driver that Laxman just sent
> >> for Palmas?
> >>
> >> https://lkml.org/lkml/2013/7/26/141
> >> [PATCH 0/2] pinctrl: palmas: add pincontrol driver
> >
> > Thanks for pointing this out. Given this:
> >
> > +Optional properties:
> > +- ti,palams-enable-d
> On 07/26/2013 02:41 PM, Andrew Chew wrote:
> > There exists a PRIMARY_SECONDARY_PAD3 in the same register base as
> > PRIMARY_SECONDARY_PAD2, which controls the function of certain pins.
> > Add a property for this setting.
>
> How does this interact with the pinc
There exists a PRIMARY_SECONDARY_PAD3 in the same register base as
PRIMARY_SECONDARY_PAD2, which controls the function of certain pins. Add
a property for this setting.
Signed-off-by: Andrew Chew
---
Documentation/devicetree/bindings/mfd/palmas.txt | 3 ++-
drivers/mfd/palmas.c
It seems that the value read back from the PALMAS_GPIO_DATA_IN register
isn't valid if the GPIO direction is out. When that's the case, we can
read back the PALMAS_GPIO_DATA_OUT register to get the proper output value.
Change-Id: Iaf877e538cfdb37a6759c45ec3c6e4ee31078709
Signed-off-
It seems that the value read back from the PALMAS_GPIO_DATA_IN register
isn't valid if the GPIO direction is out. When that's the case, we can
read back the PALMAS_GPIO_DATA_OUT register to get the proper output value.
Change-Id: Iaf877e538cfdb37a6759c45ec3c6e4ee31078709
Signed-off-
.
Enabled the VACG interrupt in tps65090_config_charger().
Cleared interrupts after processing, in tps65090_charger_isr().
Also removed unused variable "enable" in tps65090_enable_charging(),
and fixed a typo in one of the dev_err() prints.
Signed-off-by: Andrew Chew
---
drivers/powe
,
then a fixed regulator can be instantiated to control the GPIO.
The backlight enable regulator can be specified in the device tree node
for the backlight, or can be done with legacy board setup code in the
usual way.
Signed-off-by: Andrew Chew
Reviewed-by: Alexandre Courbot
---
Removed &qu
The backlight enable regulator is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew
---
Renamed en_supply to enable_supply to match the corresponding device tree
property.
Removed unnecessary check for pb->enable_supply validity. This supply
is mandatory, and pr
> From: Thierry Reding [mailto:thierry.red...@avionic-design.de]
> Sent: Thursday, March 07, 2013 3:27 AM
> To: Alex Courbot
> Cc: Andrew Chew; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/1 v4] pwm_bl: Add support for backlight enable
> regulator
>
> * PGP
> From: linux-tegra-ow...@vger.kernel.org [mailto:linux-tegra-
> ow...@vger.kernel.org] On Behalf Of Stephen Warren
> Sent: Wednesday, March 06, 2013 3:43 PM
> To: Andrew Chew
> Cc: Peter De Schrijver; linux-te...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Stephe
> Subject: [PATCH] clk: tegra: provide dummy cpu car ops
>
> tegra_boot_secondary() relies on some of the car ops. This means having an
> uninitialized tegra_cpu_car_ops will lead to an early boot panic.
> Providing a dummy struct avoids this and makes adding Tegra114 clock
> support in a bisectab
The backlight enable regulator is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew
---
Changed the name of the property from en-supply to enable-supply.
Made enable-supply a mandatory property. Changed the example in the
bindings documentation accordingly.
Moved
Thanks, Alex! Makes sense to me. There's one comment I'm not sure about,
though, described inline.
> On 03/06/2013 08:51 AM, Andrew Chew wrote:
> > The backlight enable regulator is specified in the device tree node
> > for backlight.
> >
> > Signed-off-by:
The backlight enable regulator is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew
---
Applied all recommendations from Thierry Reding and Alex Courbot, including
making pwm_bl take an optional regulator instead of a GPIO, which solves
the platform data issue (platform
I sent out a new patch that enables/disables the backlight enable gpio.
> On 03/05/2013 01:00 PM, Andrew Chew wrote:
> > I did come to the same conclusion regarding the platform data breakage.
> > I'm expecting that the use of platform data will go away, at least on
>
The backlight enable GPIO is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew
---
I decided to go ahead with disabling/enabling the backlight via GPIO as
needed. Note that I named the new functions pwm_backlight_enable() and
pwm_backlight_disable() (instead of
> From: Alex Courbot
> Sent: Monday, March 04, 2013 7:00 PM
> To: Thierry Reding
> Cc: Andrew Chew; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/1] pwm_bl: Add support for backlight enable GPIO
>
> On 03/05/2013 07:46 AM, Thierry Reding wrote:
> > * PGP Signed b
The backlight enable GPIO is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew
---
.../bindings/video/backlight/pwm-backlight.txt |2 ++
drivers/video/backlight/pwm_bl.c | 32 +---
include/linux/pwm_backlight.h
44 matches
Mail list logo
