All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>, Jon Hunter <jonathanh@nvidia.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	Krishna Reddy <vdumpa@nvidia.com>,
	linux-tegra@vger.kernel.org, iommu@lists.linux-foundation.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults
Date: Wed, 2 Jun 2021 12:44:58 +0200	[thread overview]
Message-ID: <e2341ca1-7b6d-cc19-8c43-1ada0b1f5601@canonical.com> (raw)
In-Reply-To: <YLdGwD0dxfER4USn@orome.fritz.box>

On 02/06/2021 10:52, Thierry Reding wrote:
> On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
>> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
>>> On 01/06/2021 20:08, Thierry Reding wrote:
>>>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
>>>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
>>>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
>>>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>>>
>>>>> Probably best if I queue 3-6 on a separate branch once you send a v3,
>>>>> then Krzysztof can pull that in if he needs it.
>>>>
>>>> Patch 5 has a build-time dependency on patch 1, so they need to go in
>>>> together. The reason why I suggested Krzysztof pick these up is because
>>>> there is a restructuring series that this depends on, which will go into
>>>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other
>>>> and mostly unrelated stuff as well.
>>>
>>> I missed that part... what other series are needed for this one? Except
>>> Dmitry's power management set I do not have anything in my sight for
>>> Tegras memory controllers.
>>>
>>> Anyway, I can take the memory bits and provide a stable tag with these.
>>> Recently there was quite a lot work around Tegra memory controllers, so
>>> this makes especially sense if new patches appear.
>>
>> OK, I think I have now the patchset you talked about - "memory: tegra:
>> Driver unification" v2, right?
> 
> Yes, that's the one. That series is fairly self-contained, but Dmitry's
> power management set has dependencies that pull in the regulator, clock
> and ARM SoC trees.
> 
> I did a test merge of the driver unification series with a branch that
> has Dmitry's patches and all the dependencies and there are no conflicts
> so that, fortunately, doesn't further complicates things.
> 
> Do you want me to send you a pull request with Dmitry's memory
> controller changes? You could then apply the unification series on top,
> which should allow this SMMU series to apply cleanly on top of that.

Makes sense and it looks quite bulletproof for future changes. Let's do
like this. I will apply your patch 1/10 from this v2 on top of it and
driver unification later.

> I can also carry all these changes in the Tegra tree and send a PR in a
> few days once this has seen a bit more testing in linux-next, which also
> makes sure it's got a bit more testing in our internal test farm.
> 


Best regards,
Krzysztof

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Will Deacon <will@kernel.org>,
	iommu@lists.linux-foundation.org,
	Jon Hunter <jonathanh@nvidia.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	linux-tegra@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults
Date: Wed, 2 Jun 2021 12:44:58 +0200	[thread overview]
Message-ID: <e2341ca1-7b6d-cc19-8c43-1ada0b1f5601@canonical.com> (raw)
In-Reply-To: <YLdGwD0dxfER4USn@orome.fritz.box>

On 02/06/2021 10:52, Thierry Reding wrote:
> On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
>> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
>>> On 01/06/2021 20:08, Thierry Reding wrote:
>>>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
>>>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
>>>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
>>>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>>>
>>>>> Probably best if I queue 3-6 on a separate branch once you send a v3,
>>>>> then Krzysztof can pull that in if he needs it.
>>>>
>>>> Patch 5 has a build-time dependency on patch 1, so they need to go in
>>>> together. The reason why I suggested Krzysztof pick these up is because
>>>> there is a restructuring series that this depends on, which will go into
>>>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other
>>>> and mostly unrelated stuff as well.
>>>
>>> I missed that part... what other series are needed for this one? Except
>>> Dmitry's power management set I do not have anything in my sight for
>>> Tegras memory controllers.
>>>
>>> Anyway, I can take the memory bits and provide a stable tag with these.
>>> Recently there was quite a lot work around Tegra memory controllers, so
>>> this makes especially sense if new patches appear.
>>
>> OK, I think I have now the patchset you talked about - "memory: tegra:
>> Driver unification" v2, right?
> 
> Yes, that's the one. That series is fairly self-contained, but Dmitry's
> power management set has dependencies that pull in the regulator, clock
> and ARM SoC trees.
> 
> I did a test merge of the driver unification series with a branch that
> has Dmitry's patches and all the dependencies and there are no conflicts
> so that, fortunately, doesn't further complicates things.
> 
> Do you want me to send you a pull request with Dmitry's memory
> controller changes? You could then apply the unification series on top,
> which should allow this SMMU series to apply cleanly on top of that.

Makes sense and it looks quite bulletproof for future changes. Let's do
like this. I will apply your patch 1/10 from this v2 on top of it and
driver unification later.

> I can also carry all these changes in the Tegra tree and send a PR in a
> few days once this has seen a bit more testing in linux-next, which also
> makes sure it's got a bit more testing in our internal test farm.
> 


Best regards,
Krzysztof
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org>,
	iommu@lists.linux-foundation.org,
	Jon Hunter <jonathanh@nvidia.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	linux-tegra@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults
Date: Wed, 2 Jun 2021 12:44:58 +0200	[thread overview]
Message-ID: <e2341ca1-7b6d-cc19-8c43-1ada0b1f5601@canonical.com> (raw)
In-Reply-To: <YLdGwD0dxfER4USn@orome.fritz.box>

On 02/06/2021 10:52, Thierry Reding wrote:
> On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
>> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
>>> On 01/06/2021 20:08, Thierry Reding wrote:
>>>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
>>>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
>>>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
>>>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>>>
>>>>> Probably best if I queue 3-6 on a separate branch once you send a v3,
>>>>> then Krzysztof can pull that in if he needs it.
>>>>
>>>> Patch 5 has a build-time dependency on patch 1, so they need to go in
>>>> together. The reason why I suggested Krzysztof pick these up is because
>>>> there is a restructuring series that this depends on, which will go into
>>>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other
>>>> and mostly unrelated stuff as well.
>>>
>>> I missed that part... what other series are needed for this one? Except
>>> Dmitry's power management set I do not have anything in my sight for
>>> Tegras memory controllers.
>>>
>>> Anyway, I can take the memory bits and provide a stable tag with these.
>>> Recently there was quite a lot work around Tegra memory controllers, so
>>> this makes especially sense if new patches appear.
>>
>> OK, I think I have now the patchset you talked about - "memory: tegra:
>> Driver unification" v2, right?
> 
> Yes, that's the one. That series is fairly self-contained, but Dmitry's
> power management set has dependencies that pull in the regulator, clock
> and ARM SoC trees.
> 
> I did a test merge of the driver unification series with a branch that
> has Dmitry's patches and all the dependencies and there are no conflicts
> so that, fortunately, doesn't further complicates things.
> 
> Do you want me to send you a pull request with Dmitry's memory
> controller changes? You could then apply the unification series on top,
> which should allow this SMMU series to apply cleanly on top of that.

Makes sense and it looks quite bulletproof for future changes. Let's do
like this. I will apply your patch 1/10 from this v2 on top of it and
driver unification later.

> I can also carry all these changes in the Tegra tree and send a PR in a
> few days once this has seen a bit more testing in linux-next, which also
> makes sure it's got a bit more testing in our internal test farm.
> 


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-02 10:45 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20 17:26 [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults Thierry Reding
2021-04-20 17:26 ` Thierry Reding
2021-04-20 17:26 ` Thierry Reding
2021-04-20 17:26 ` [PATCH v2 01/10] memory: tegra: Implement SID override programming Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-26  8:28   ` Krzysztof Kozlowski
2021-04-26  8:28     ` Krzysztof Kozlowski
2021-04-26  8:28     ` Krzysztof Kozlowski
2021-04-26 12:13     ` Thierry Reding
2021-04-26 12:13       ` Thierry Reding
2021-04-26 12:13       ` Thierry Reding
2021-04-26 14:10       ` Krzysztof Kozlowski
2021-04-26 14:10         ` Krzysztof Kozlowski
2021-04-26 14:10         ` Krzysztof Kozlowski
2021-04-20 17:26 ` [PATCH v2 02/10] dt-bindings: arm-smmu: Add Tegra186 compatible string Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26 ` [PATCH v2 03/10] iommu/arm-smmu: Implement ->probe_finalize() Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26 ` [PATCH v2 04/10] iommu/arm-smmu: tegra: Detect number of instances at runtime Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 22:06   ` Krishna Reddy
2021-04-20 22:06     ` Krishna Reddy
2021-04-20 22:06     ` Krishna Reddy
2021-04-20 17:26 ` [PATCH v2 05/10] iommu/arm-smmu: tegra: Implement SID override programming Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26 ` [PATCH v2 06/10] iommu/arm-smmu: Use Tegra implementation on Tegra186 Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26 ` [PATCH v2 07/10] arm64: tegra: Use correct compatible string for Tegra186 SMMU Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26 ` [PATCH v2 08/10] arm64: tegra: Hook up memory controller to SMMU on Tegra186 Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26 ` [PATCH v2 09/10] arm64: tegra: Enable SMMU support on Tegra194 Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26 ` [PATCH v2 10/10] arm64: tegra: Enable SMMU support for display " Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-04-20 17:26   ` Thierry Reding
2021-05-28 17:05 ` [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults Thierry Reding
2021-05-28 17:05   ` Thierry Reding
2021-05-28 17:05   ` Thierry Reding
2021-06-01 12:26   ` Will Deacon
2021-06-01 12:26     ` Will Deacon
2021-06-01 12:26     ` Will Deacon
2021-06-01 18:08     ` Thierry Reding
2021-06-01 18:08       ` Thierry Reding
2021-06-01 18:08       ` Thierry Reding
2021-06-02  7:33       ` Krzysztof Kozlowski
2021-06-02  7:33         ` Krzysztof Kozlowski
2021-06-02  7:33         ` Krzysztof Kozlowski
2021-06-02  7:35         ` Krzysztof Kozlowski
2021-06-02  7:35           ` Krzysztof Kozlowski
2021-06-02  7:35           ` Krzysztof Kozlowski
2021-06-02  8:52           ` Thierry Reding
2021-06-02  8:52             ` Thierry Reding
2021-06-02  8:52             ` Thierry Reding
2021-06-02 10:44             ` Krzysztof Kozlowski [this message]
2021-06-02 10:44               ` Krzysztof Kozlowski
2021-06-02 10:44               ` Krzysztof Kozlowski
2021-06-02 11:40               ` Will Deacon
2021-06-02 11:40                 ` Will Deacon
2021-06-02 11:40                 ` Will Deacon
2021-06-02 14:58                 ` Thierry Reding
2021-06-02 14:58                   ` Thierry Reding
2021-06-02 14:58                   ` Thierry Reding
2021-06-02 14:58                   ` Krzysztof Kozlowski
2021-06-02 14:58                     ` Krzysztof Kozlowski
2021-06-02 14:58                     ` Krzysztof Kozlowski
2021-06-02 14:53               ` Thierry Reding
2021-06-02 14:53                 ` Thierry Reding
2021-06-02 14:53                 ` Thierry Reding
2021-06-02 14:57                 ` Krzysztof Kozlowski
2021-06-02 14:57                   ` Krzysztof Kozlowski
2021-06-02 14:57                   ` Krzysztof Kozlowski

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=e2341ca1-7b6d-cc19-8c43-1ada0b1f5601@canonical.com \
    --to=krzysztof.kozlowski@canonical.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=thierry.reding@gmail.com \
    --cc=vdumpa@nvidia.com \
    --cc=will@kernel.org \
    /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.