чт, 16 мая 2019 г., 13:05 Sven Eckelmann <s...@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 <agr...@kernel.org> (maintainer:ARM/QUALCOMM SUPPORT) > * David Brown <david.br...@linaro.org> (maintainer:ARM/QUALCOMM SUPPORT) > * linux-arm-...@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. https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/tree/arch/arm64/boot/dts/qcom/qcom-ipq807x-soc.dtsi?h=eggplant#n2055 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: > > * devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED > DEVICE TREE BINDINGS) > * Rob Herring <robh...@kernel.org> (maintainer:OPEN FIRMWARE AND > FLATTENED DEVICE TREE BINDINGS) > * Mark Rutland <mark.rutl...@arm.com> (maintainer:OPEN FIRMWARE AND > FLATTENED DEVICE TREE BINDINGS) > > > 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
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
