linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PULL] memory: tegra: Changes for v5.14-rc1
Date: Fri, 4 Jun 2021 15:51:34 +0300	[thread overview]
Message-ID: <3ed358ce-de98-0b42-2446-873af55ed825@gmail.com> (raw)
In-Reply-To: <YLnzQk+suAG5clzB@orome.fritz.box>

04.06.2021 12:32, Thierry Reding пишет:
> On Thu, Jun 03, 2021 at 10:56:29PM +0300, Dmitry Osipenko wrote:
>> 03.06.2021 17:37, Thierry Reding пишет:
>>> memory: tegra: Changes for v5.14-rc1
>>>
>>> This stable tag contains Dmitry's power domain work, including all the
>>> necessary dependencies from the regulator, clock and ARM SoC trees.
>>>
>>> ----------------------------------------------------------------
>>> Dmitry Osipenko (18):
>>>       clk: tegra30: Use 300MHz for video decoder by default
>>>       clk: tegra: Fix refcounting of gate clocks
>>>       clk: tegra: Ensure that PLLU configuration is applied properly
>>>       clk: tegra: Halve SCLK rate on Tegra20
>>>       clk: tegra: Don't allow zero clock rate for PLLs
>>>       clk: tegra: cclk: Handle thermal DIV2 CPU frequency throttling
>>>       clk: tegra: Mark external clocks as not having reset control
>>>       clk: tegra: Don't deassert reset on enabling clocks
>>>       regulator: core: Add regulator_sync_voltage_rdev()
>>
>>>       soc/tegra: regulators: Bump voltages on system reboot
>>
>> This patch is a build dependency prerequisite for the "soc/tegra:
>> regulators: Support core domain state syncing" patch. Will you send a
>> new PR to Krzysztof with the remaining soc/tegra patches?
> 
> soc/tegra patches usually go in through ARM SoC. This is merely included
> here because it was part of the set of patches that were needed to
> enable compile testing for the memory controller drivers.
> 
> I've applied the remaining soc/tegra patches (12-14 of the series) to my
> for-5.14/soc branch but ended up not pulling that part in because it was
> unnecessary for the memory controller patches.

Does this mean that if for-5.14/soc will be pulled first into mainline,
then the patches will be applied in a wrong order?

  reply	other threads:[~2021-06-04 12:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 14:37 [PULL] memory: tegra: Changes for v5.14-rc1 Thierry Reding
2021-06-03 19:45 ` Krzysztof Kozlowski
2021-06-03 19:56 ` Dmitry Osipenko
2021-06-04  9:32   ` Thierry Reding
2021-06-04 12:51     ` Dmitry Osipenko [this message]
2021-06-07  8:28       ` Krzysztof Kozlowski
2021-06-07 13:26         ` Thierry Reding
2021-06-07 13:41           ` Dmitry Osipenko

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=3ed358ce-de98-0b42-2446-873af55ed825@gmail.com \
    --to=digetx@gmail.com \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    /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).