On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote:

On 02/06/2021 10:52, Thierry Reding wrote:

quoted

On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:

quoted

On 02/06/2021 09:33, Krzysztof Kozlowski wrote:

quoted

On 01/06/2021 20:08, Thierry Reding wrote:

quoted

On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:

quoted

On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:

quoted

On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:

quoted

From: Thierry Reding <redacted>

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.

The SMMU series here depends on the unification series, so the
unification series needs to go first. It'd be a fair bit of work to
reverse that because the ->probe_device() callback implemented by the
first patch of this SMMU series is part of the tegra_mc_ops structure
that's introduced in the unification series.

Thierry