[OpenWrt-Devel] [PATCH 2/4] ipq40xx: fix sleep clock

Павел be.dissent at gmail.com
Thu May 16 07:18:14 EDT 2019

чт, 16 мая 2019 г., 13:05 Sven Eckelmann <sven at narfation.org>:

> On Wednesday, 15 May 2019 19:16:51 CEST Павел wrote:
> [...]
> > > Is there any particular reason why
> > > this
> > > shouldn't be sent upstream and then backported to OpenWrt?
> > >
> >
> > There are no reasons why it shouldn't be sent upstream along with other
> > patches. I hope to find someone with datasheet beforehand to verify the
> > correct sleep clock rate.
> But you will most likely find the persons with the datasheet when you try
> to
> upstream it via
> * Andy Gross <agross at kernel.org> (maintainer:ARM/QUALCOMM SUPPORT)
> * David Brown <david.brown at linaro.org> (maintainer:ARM/QUALCOMM SUPPORT)
> * linux-arm-msm at vger.kernel.org (open list:ARM/QUALCOMM SUPPORT)
> And maybe some of these guys also know how to find the ipq40xx clock
> controller reference or hardware reference. Because I was only able to
> verify
> for IPQ8072 that it had a 32.768 KHz sleep clock. But the

If you are completely sure about that, then I guess that they have
(un)intentionally messed with the clock in QSDK, because they state that
ipq807x has the same 32000 khz crystal.

Furthermore, it has been upstreamed...

So I'm confused actually what path to choose now. Probably it depends on
your level of confidence that ipq8072 definitely has a 32.768 khz rate - it
will mean that qsdk is not trustworthy on this matter.

"IPQ4018/IPQ4028/IPQ4019/IPQ4029 Watchdog" document states that the
> watchdog
> runs on a 32 KHz sleep clock. And according to the device tree, the clock
> you
> modified here is connected to the watchdog.
> And for the device tree bindings:
> * devicetree at vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
> * Rob Herring <robh+dt at kernel.org> (maintainer:OPEN FIRMWARE AND
> * Mark Rutland <mark.rutland at arm.com> (maintainer:OPEN FIRMWARE AND
> > Besides upstreaming a patch takes time while the next openwrt release
> > should be out soon I suppose.
> Good reason to try to upstream it at the same time to OpenWrt and upstream
> :)
> At least then we could get some feedback from upstream before OpenWrt
> ships
> something which potentially has negative effects.
> Kind regards,
>         Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190516/463c063f/attachment.htm>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list