Re: [PATCH v2] tegra2/tegra3 automotive clock init

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux