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?
next prev parent 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).