From: Dmitry Osipenko <digetx@gmail.com>
To: Kejia Hu <kejia.hu@codethink.co.uk>,
linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2] tegra2/tegra3 automotive clock init
Date: Sun, 3 Mar 2019 17:14:40 +0300 [thread overview]
Message-ID: <e1fade71-03b4-1c45-efbd-26e25f66ddc7@gmail.com> (raw)
In-Reply-To: <20190301153540.14954-1-kejia.hu@codethink.co.uk>
01.03.2019 18:35, Kejia Hu пишет:
> This is a re-implementation of adding clock initialization for
> tegra2 and tegra3 automotive devices accroding to Dmitry Osipenko's
> feedback on version 1[0].
>
> We have moved the initialization from the clock driver to device
> tree, but instead of putting them into a dtsi file, we used
> dt overlay to patch the device tree at runtime, we believe the
> ability to dynamically detect the chipset and apply the right
> settings should be useful according to the discussion[1].
>
> Changes against v1:
> - use device tree overlay to introduce the automative clock configs
> - enable dt overlay for tegra20/30
> - move the condition "soc_is_tegra_auto" to be after applied
> clock init table.
>
> [0] https://www.spinics.net/lists/linux-tegra/msg38347.html
> [1] https://www.spinics.net/lists/arm-kernel/msg665373.html
>
Hello Kejia,
Thank you very much for your work! My point was that the clock-assignments should be moved into the board's DT file out from the kernel's driver, in this series you're not moving out the board-specific properties from the kernel sources and essential doing the same thing that was in the previous versions in a different way now. Please take a look at tegra124.dtsi / tegra124-nyan.dtsi / tegra124-nyan-big.dts for the example, in your case it could be something similar.. somewhat like tegra20.dtsi / tegra20-automotive.dtsi / tegra20-automotive-board.dts. Hence you won't need to touch kernel's code at all and could specify everything in the device-tree solely.
If you're trying to workaround the case where device-tree isn't easily changeable, then I'm afraid this is not going to work well in regards to upstreaming because upstream maintainers have no interest in supporting downstream. If it's not that case, then please try to explain what you're trying to achieve in more detail.
In overall you'll need to:
1) Upstream device-tree of the board.
2) Get all other required bits of kernel drivers upstream'ed.
3) Issue firmware update for the device that will contain new upstream-conformant device-tree and upstream kernel at once. Also note that kernel supports appending DTB (compiled device-tree binary) to the kernel's image, hence you may workaround locked-down bootloader that doesn't allow to replace (or doesn't support) device-tree.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-03-03 14:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-01 15:35 [PATCH v2] tegra2/tegra3 automotive clock init Kejia Hu
2019-03-01 15:35 ` [PATCH v2 1/6] soc/tegra: initial tegra-automotive detection Kejia Hu
2019-03-04 13:19 ` Thierry Reding
2019-03-01 15:35 ` [PATCH v2 2/6] soc/tegra: fuse: add is_automotive for tegra30 Kejia Hu
2019-03-01 15:35 ` [PATCH v2 3/6] soc/tegra: fuse: Add is_automotive for tegra20 Kejia Hu
2019-03-01 15:35 ` [PATCH v2 4/6] kconfig: build device tree overlay into tegra20/30 Kejia Hu
2019-03-01 15:35 ` [PATCH v2 5/6] clk: tegra20: add automotive specific clocks as dt overlay Kejia Hu
2019-03-01 15:35 ` [PATCH v2 6/6] clk: tegra30: " Kejia Hu
2019-03-03 14:14 ` Dmitry Osipenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e1fade71-03b4-1c45-efbd-26e25f66ddc7@gmail.com \
--to=digetx@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=kejia.hu@codethink.co.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).