Extending wdt-gpio to be used on non-of (no DT) platforms

Extending wdt-gpio to be used on non-of (no DT) platforms

[Rafał Miłecki]

Hi guys,

I've noticed gpio_wdt was added to the kernel to support some devices
based on devicetree.
We used to have our own (not mainlined) gpio_wdt in OpenWrt project:
http://git.openwrt.org/?p=openwrt.git;a=blob;f=target/linux/generic/patches-3.10/990-gpio_wdt.patch;hb=HEAD

The main difference is that the mainlined one uses OF, while OpenWrt's
one uses plain platform API (with struct gpio_wdt_platform_data).

I wanted to bring a topic of mainlining OpenWrt's solution. We
definitely need that and at the same time our device(s) don't use OF /
DT.

Do you think we should extend wdt-gpio to handle that? Or do you think
this driver is so small, it's not worth it and we should submit a
separated one?

Apart from API being used, one other difference I see is OpenWrt
supports different values for "first tick" and "interval". But that
could be easily handled.

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Extending wdt-gpio to be used on non-of (no DT) platforms

[Alexander Shiyan]

Sat, 29 Mar 2014 12:54:40 +0100 от Rafał Miłecki <zajec5@gmail.com>:
> Hi guys,
> 
> I've noticed gpio_wdt was added to the kernel to support some devices
> based on devicetree.
> We used to have our own (not mainlined) gpio_wdt in OpenWrt project:
> http://git.openwrt.org/?p=openwrt.git;a=blob;f=target/linux/generic/patches-3.10/990-gpio_wdt.patch;hb=HEAD
> 
> The main difference is that the mainlined one uses OF, while OpenWrt's
> one uses plain platform API (with struct gpio_wdt_platform_data).
> 
> I wanted to bring a topic of mainlining OpenWrt's solution. We
> definitely need that and at the same time our device(s) don't use OF /
> DT.
> 
> Do you think we should extend wdt-gpio to handle that? Or do you think
> this driver is so small, it's not worth it and we should submit a
> separated one?
> 
> Apart from API being used, one other difference I see is OpenWrt
> supports different values for "first tick" and "interval". But that
> could be easily handled.

In fact, this driver can be extended to non-DT support without adding
any platform_data headers. This can be implemented by convert driver
to using descriptor-based GPIO functions (gpiod_{}).
HW timeout value in this case can be taken with module_param().

---

Re: Extending wdt-gpio to be used on non-of (no DT) platforms

[Hauke Mehrtens]

On 03/29/2014 01:29 PM, Alexander Shiyan wrote:
> Sat, 29 Mar 2014 12:54:40 +0100 от Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> Hi guys,
>>
>> I've noticed gpio_wdt was added to the kernel to support some devices
>> based on devicetree.
>> We used to have our own (not mainlined) gpio_wdt in OpenWrt project:
>> http://git.openwrt.org/?p=openwrt.git;a=blob;f=target/linux/generic/patches-3.10/990-gpio_wdt.patch;hb=HEAD
>>
>> The main difference is that the mainlined one uses OF, while OpenWrt's
>> one uses plain platform API (with struct gpio_wdt_platform_data).
>>
>> I wanted to bring a topic of mainlining OpenWrt's solution. We
>> definitely need that and at the same time our device(s) don't use OF /
>> DT.
>>
>> Do you think we should extend wdt-gpio to handle that? Or do you think
>> this driver is so small, it's not worth it and we should submit a
>> separated one?
>>
>> Apart from API being used, one other difference I see is OpenWrt
>> supports different values for "first tick" and "interval". But that
>> could be easily handled.
> 
> In fact, this driver can be extended to non-DT support without adding
> any platform_data headers. This can be implemented by convert driver
> to using descriptor-based GPIO functions (gpiod_{}).
> HW timeout value in this case can be taken with module_param().

The Huawei E970, the only device with a bcm47xx SoC which uses this gpio
watchdog I know of, needs the gpio driver very early. It is not possible
to deactivate the watchdogs, so it has to get trigged very early in the
boot process. Module load time is too late. I think wdt-gpio should be
extended to support the old platform device interface with a own
platform_data header.

I added Mathias Adam, the author of the patch in OpenWrt.

Hauke
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Extending wdt-gpio to be used on non-of (no DT) platforms

[Alexander Shiyan]

Sat, 29 Mar 2014 14:16:40 +0100 от Hauke Mehrtens <hauke@hauke-m.de>:
> On 03/29/2014 01:29 PM, Alexander Shiyan wrote:
> > Sat, 29 Mar 2014 12:54:40 +0100 от Rafał Miłecki <zajec5@gmail.com>:
> >> Hi guys,
> >>
> >> I've noticed gpio_wdt was added to the kernel to support some devices
> >> based on devicetree.
> >> We used to have our own (not mainlined) gpio_wdt in OpenWrt project:
> >> http://git.openwrt.org/?p=openwrt.git;a=blob;f=target/linux/generic/patches-3.10/990-gpio_wdt.patch;hb=HEAD
> >>
> >> The main difference is that the mainlined one uses OF, while OpenWrt's
> >> one uses plain platform API (with struct gpio_wdt_platform_data).
> >>
> >> I wanted to bring a topic of mainlining OpenWrt's solution. We
> >> definitely need that and at the same time our device(s) don't use OF /
> >> DT.
> >>
> >> Do you think we should extend wdt-gpio to handle that? Or do you think
> >> this driver is so small, it's not worth it and we should submit a
> >> separated one?
> >>
> >> Apart from API being used, one other difference I see is OpenWrt
> >> supports different values for "first tick" and "interval". But that
> >> could be easily handled.
> > 
> > In fact, this driver can be extended to non-DT support without adding
> > any platform_data headers. This can be implemented by convert driver
> > to using descriptor-based GPIO functions (gpiod_{}).
> > HW timeout value in this case can be taken with module_param().
> 
> The Huawei E970, the only device with a bcm47xx SoC which uses this gpio
> watchdog I know of, needs the gpio driver very early. It is not possible
> to deactivate the watchdogs, so it has to get trigged very early in the

Why it cannot be deactivated?
The driver has been designed for ADM70x ICs, where watchdog is
deactivated by set GPIO to tristate.

---

Re: Extending wdt-gpio to be used on non-of (no DT) platforms

[Rafał Miłecki]

2014-03-29 14:33 GMT+01:00 Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org>:
> Sat, 29 Mar 2014 14:16:40 +0100 от Hauke Mehrtens <hauke@hauke-m.de>:
>> The Huawei E970, the only device with a bcm47xx SoC which uses this gpio
>> watchdog I know of, needs the gpio driver very early. It is not possible
>> to deactivate the watchdogs, so it has to get trigged very early in the
>
> Why it cannot be deactivated?
> The driver has been designed for ADM70x ICs, where watchdog is
> deactivated by set GPIO to tristate.

I'm not sure how to achieve tri-state with Broadcom SoC. Our code is in:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/bcma/driver_gpio.c

We have bcma_chipco_gpio_control that sets if GPIO is controlled by
ChipCommon (part of the SoC, one of many cores).
Maybe setting GPIO to be *not* controlled by ChipCommon will make it tri-state?

Any other ideas?

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Extending wdt-gpio to be used on non-of (no DT) platforms

[Alexander Shiyan]

Sat, 29 Mar 2014 14:51:34 +0100 от Rafał Miłecki <zajec5@gmail.com>:
> 2014-03-29 14:33 GMT+01:00 Alexander Shiyan <shc_work@mail.ru>:
> > Sat, 29 Mar 2014 14:16:40 +0100 от Hauke Mehrtens <hauke@hauke-m.de>:
> >> The Huawei E970, the only device with a bcm47xx SoC which uses this gpio
> >> watchdog I know of, needs the gpio driver very early. It is not possible
> >> to deactivate the watchdogs, so it has to get trigged very early in the
> >
> > Why it cannot be deactivated?
> > The driver has been designed for ADM70x ICs, where watchdog is
> > deactivated by set GPIO to tristate.
> 
> I'm not sure how to achieve tri-state with Broadcom SoC. Our code is in:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/bcma/driver_gpio.c
> 
> We have bcma_chipco_gpio_control that sets if GPIO is controlled by
> ChipCommon (part of the SoC, one of many cores).
> Maybe setting GPIO to be *not* controlled by ChipCommon will make it tri-state?
> 
> Any other ideas?

Usually this should be done by setup GPIO direction to input.

---

Re: Extending wdt-gpio to be used on non-of (no DT) platforms

[Guenter Roeck]

On Sat, Mar 29, 2014 at 12:54:40PM +0100, Rafał Miłecki wrote:
> Hi guys,
> 
> I've noticed gpio_wdt was added to the kernel to support some devices
> based on devicetree.
> We used to have our own (not mainlined) gpio_wdt in OpenWrt project:
> http://git.openwrt.org/?p=openwrt.git;a=blob;f=target/linux/generic/patches-3.10/990-gpio_wdt.patch;hb=HEAD
> 
> The main difference is that the mainlined one uses OF, while OpenWrt's
> one uses plain platform API (with struct gpio_wdt_platform_data).
> 
> I wanted to bring a topic of mainlining OpenWrt's solution. We
> definitely need that and at the same time our device(s) don't use OF /
> DT.
> 
> Do you think we should extend wdt-gpio to handle that? Or do you think
> this driver is so small, it's not worth it and we should submit a
> separated one?
> 
> Apart from API being used, one other difference I see is OpenWrt
> supports different values for "first tick" and "interval". But that
> could be easily handled.
> 
If you can sort out those differences, I would suggest to add platform data
support to the existing upstream driver.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html