[lkml]   [2020]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v6 00/19] Move PMC clocks into Tegra PMC driver
07.01.2020 19:50, Sowjanya Komatineni пишет:
> On 1/7/20 4:21 AM, Thierry Reding wrote:
>> On Mon, Jan 06, 2020 at 08:13:59PM -0800, Sowjanya Komatineni wrote:
>>> This patch series moves Tegra PMC clocks from clock driver to pmc driver
>>> along with the device trees changes and audio driver which uses one of
>>> the pmc clock for audio mclk.
>>> Tegra PMC has clk_out_1, clk_out_2, clk_out_3 and blink controls which
>>> are currently registered by Tegra clock driver using clk_regiser_mux and
>>> clk_register_gate which performs direct Tegra PMC register access.
>>> When Tegra PMC is in secure mode, any access from non-secure world will
>>> not go through.
>>> This patch series adds these Tegra PMC clocks and blink controls to
>>> Tegra
>>> PMC driver with PMC as clock provider and removes them from Tegra clock
>>> driver.
>>> PMC clock clk_out_1 is dedicated for audio mclk from Tegra30 thru
>>> Tegra210
>>> and clock driver does inital parent configuration for it and enables
>>> them.
>>> But this clock should be taken care by audio driver as there is no need
>>> to have this clock pre enabled.
>>> So, this series also includes patch that updates ASoC driver to take
>>> care of parent configuration for mclk if device tree don't specify
>>> initial parent configuration using assigned-clock-parents and controls
>>> audio mclk enable/disable during ASoC machine startup and shutdown.
>>> DTs are also updated to use clk_out_1 as audio mclk rather than extern1.
>>> This series also includes a patch for mclk fallback to extern1 when
>>> retrieving mclk fails to have this backward compatible of new DT with
>>> old kernels.
>> Hi Sowjanya,
>> this looks like it's almost ready to merge. Can you highlight if there
>> are any build-time or runtime dependencies between the patches? The
>> audio driver changes seem to be mostly isolated from the rest by the
>> fallback implementation for legacy device trees.
>> Is there anything that I need to keep in mind when applying these? And
>> would it be fine for Mark to pick up the ASoC patches separately from
>> the rest?
>> Thierry
> Yes, ASoC patches can be picked separately.
> dependencies are b/w clock and pmc driver patches.

Technically, the ASoC compatibility patches should be applied before the
CaR changes. But perhaps it's not critical if audio fails during git's

 \ /
  Last update: 2020-01-08 01:40    [W:0.088 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site