From: Dmitry Osipenko <digetx@gmail.com>
To: Olof Johansson <olof@lixom.net>,
Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org, arm@kernel.org,
linux-arm-kernel@lists.infradead.org,
Jon Hunter <jonathanh@nvidia.com>
Subject: Re: [GIT PULL 2/5] memory: tegra: Changes for v4.18-rc1
Date: Fri, 25 May 2018 15:45:59 +0300 [thread overview]
Message-ID: <de40dfa2-90cf-01f6-dc58-3a60afcf4e39@gmail.com> (raw)
In-Reply-To: <20180525121158.dk5hv525ilakmshz@localhost>
On 25.05.2018 15:11, Olof Johansson wrote:
> On Fri, May 18, 2018 at 04:22:42PM +0200, Thierry Reding wrote:
>> Hi ARM SoC maintainers,
>>
>> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>>
>> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-memory
>>
>> for you to fetch changes up to bef89a8d81ca97aca864778746b110cf52847868:
>>
>> memory: tegra: Remove Tegra114 SATA and AFI reset definitions (2018-05-18 12:33:02 +0200)
>>
>> Thanks,
>> Thierry
>>
>> ----------------------------------------------------------------
>> memory: tegra: Changes for v4.18-rc1
>>
>> This contains some cleanup of the memory controller driver as well as
>> unification work to share more code between Tegra20 and later SoC
>> generations. Also included are an implementation for the hot resets
>> functionality by the memory controller which is required to properly
>> reset busy hardware.
>>
>> ----------------------------------------------------------------
>> Dmitry Osipenko (14):
>> dt-bindings: memory: tegra: Add hot resets definitions
>> memory: tegra: Do not handle spurious interrupts
>> memory: tegra: Setup interrupts mask before requesting IRQ
>> memory: tegra: Apply interrupts mask per SoC
>> memory: tegra: Remove unused headers inclusions
>> memory: tegra: Squash tegra20-mc into common tegra-mc driver
>> memory: tegra: Introduce memory client hot reset
>> memory: tegra: Add Tegra20 memory controller hot resets
>> memory: tegra: Add Tegra30 memory controller hot resets
>> memory: tegra: Add Tegra114 memory controller hot resets
>> memory: tegra: Add Tegra124 memory controller hot resets
>> memory: tegra: Register SMMU after MC driver became ready
>> dt-bindings: memory: tegra: Remove Tegra114 SATA and AFI reset definitions
>> memory: tegra: Remove Tegra114 SATA and AFI reset definitions
>>
>> Thierry Reding (1):
>> memory: tegra: Add Tegra210 memory controller hot resets
>
> Looks like this is just additional/proper resets, are there any backwards
> compatibility concerns with older device trees or new assumptions of properties
> that should be handled?
Hello Olof,
AFAIK, memory resets never been used anywhere before. The device drivers would
have to take into account the backwards compatibility, like for example we do in
the proposed video-decoder patch that optionally utilizes the MC reset [0].
[0] https://patchwork.ozlabs.org/patch/917176/
WARNING: multiple messages have this Message-ID (diff)
From: digetx@gmail.com (Dmitry Osipenko)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL 2/5] memory: tegra: Changes for v4.18-rc1
Date: Fri, 25 May 2018 15:45:59 +0300 [thread overview]
Message-ID: <de40dfa2-90cf-01f6-dc58-3a60afcf4e39@gmail.com> (raw)
In-Reply-To: <20180525121158.dk5hv525ilakmshz@localhost>
On 25.05.2018 15:11, Olof Johansson wrote:
> On Fri, May 18, 2018 at 04:22:42PM +0200, Thierry Reding wrote:
>> Hi ARM SoC maintainers,
>>
>> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>>
>> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-memory
>>
>> for you to fetch changes up to bef89a8d81ca97aca864778746b110cf52847868:
>>
>> memory: tegra: Remove Tegra114 SATA and AFI reset definitions (2018-05-18 12:33:02 +0200)
>>
>> Thanks,
>> Thierry
>>
>> ----------------------------------------------------------------
>> memory: tegra: Changes for v4.18-rc1
>>
>> This contains some cleanup of the memory controller driver as well as
>> unification work to share more code between Tegra20 and later SoC
>> generations. Also included are an implementation for the hot resets
>> functionality by the memory controller which is required to properly
>> reset busy hardware.
>>
>> ----------------------------------------------------------------
>> Dmitry Osipenko (14):
>> dt-bindings: memory: tegra: Add hot resets definitions
>> memory: tegra: Do not handle spurious interrupts
>> memory: tegra: Setup interrupts mask before requesting IRQ
>> memory: tegra: Apply interrupts mask per SoC
>> memory: tegra: Remove unused headers inclusions
>> memory: tegra: Squash tegra20-mc into common tegra-mc driver
>> memory: tegra: Introduce memory client hot reset
>> memory: tegra: Add Tegra20 memory controller hot resets
>> memory: tegra: Add Tegra30 memory controller hot resets
>> memory: tegra: Add Tegra114 memory controller hot resets
>> memory: tegra: Add Tegra124 memory controller hot resets
>> memory: tegra: Register SMMU after MC driver became ready
>> dt-bindings: memory: tegra: Remove Tegra114 SATA and AFI reset definitions
>> memory: tegra: Remove Tegra114 SATA and AFI reset definitions
>>
>> Thierry Reding (1):
>> memory: tegra: Add Tegra210 memory controller hot resets
>
> Looks like this is just additional/proper resets, are there any backwards
> compatibility concerns with older device trees or new assumptions of properties
> that should be handled?
Hello Olof,
AFAIK, memory resets never been used anywhere before. The device drivers would
have to take into account the backwards compatibility, like for example we do in
the proposed video-decoder patch that optionally utilizes the MC reset [0].
[0] https://patchwork.ozlabs.org/patch/917176/
next prev parent reply other threads:[~2018-05-25 12:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 14:22 [GIT PULL 1/5] dt-bindings: tegra: Changes for v4.18-rc1 Thierry Reding
2018-05-18 14:22 ` Thierry Reding
2018-05-18 14:22 ` [GIT PULL 2/5] memory: " Thierry Reding
2018-05-18 14:22 ` Thierry Reding
2018-05-18 20:43 ` Thierry Reding
2018-05-18 20:43 ` Thierry Reding
2018-05-25 12:13 ` Olof Johansson
2018-05-25 12:13 ` Olof Johansson
2018-05-18 21:58 ` [GIT PULL v2 " Thierry Reding
2018-05-18 21:58 ` Thierry Reding
2018-05-25 12:14 ` Olof Johansson
2018-05-25 12:14 ` Olof Johansson
2018-05-25 12:11 ` [GIT PULL " Olof Johansson
2018-05-25 12:11 ` Olof Johansson
2018-05-25 12:45 ` Dmitry Osipenko [this message]
2018-05-25 12:45 ` Dmitry Osipenko
2018-05-18 14:22 ` [GIT PULL 3/5] ARM: tegra: Core changes " Thierry Reding
2018-05-18 14:22 ` Thierry Reding
2018-05-25 12:15 ` Olof Johansson
2018-05-25 12:15 ` Olof Johansson
2018-05-18 14:22 ` [GIT PULL 4/5] ARM: tegra: Device tree " Thierry Reding
2018-05-18 14:22 ` Thierry Reding
2018-05-25 12:15 ` Olof Johansson
2018-05-25 12:15 ` Olof Johansson
2018-05-18 14:22 ` [GIT PULL 5/5] arm64: " Thierry Reding
2018-05-18 14:22 ` Thierry Reding
2018-05-25 12:16 ` Olof Johansson
2018-05-25 12:16 ` Olof Johansson
2018-05-25 12:08 ` [GIT PULL 1/5] dt-bindings: tegra: Changes " Olof Johansson
2018-05-25 12:08 ` Olof Johansson
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=de40dfa2-90cf-01f6-dc58-3a60afcf4e39@gmail.com \
--to=digetx@gmail.com \
--cc=arm@kernel.org \
--cc=jonathanh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=olof@lixom.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.