On Thu, Nov 29, 2012 at 11:38:11AM -0700, Stephen Warren wrote:

On 11/29/2012 04:47 AM, Thierry Reding wrote:

quoted

On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström wrote:

quoted

On 28.11.2012 23:23, Thierry Reding wrote:

quoted

This could be problematic. Since drivers/video and
drivers/gpu/drm are separate trees, this would entail a
continuous burden on keeping both trees synchronized. While I
realize that eventually it might be better to put the host1x
driver in a separate place to accomodate for its use by other
subsystems, I'm not sure moving it here right away is the best 
approach.

I understand your point, but I hope also that we'd end up with
something that can be used as basis for the downstream kernel to
migrate to upstream stack.

The key point here is to make the API between nvhost and tegradrm
as small and robust to changes as possible.

I agree. But I also fear that there will be changes eventually and 
having both go in via different tree requires those trees to be
merged in a specific order to avoid breakage should the API change.
This will be particularly ugly in linux-next.

That's why I explicitly proposed to take this into
drivers/gpu/drm/tegra for the time being, until we can be
reasonably sure that the API is fixed. Then I'm fine with moving it
wherever seems the best fit. Even then there might be the
occasional dependency, but they should get fewer and fewer as the
code matures.

It is acceptable for one maintainer to ack patches, and another
maintainer to merge a series that touches both "their own" code and
code owned by another tree. This should of course only be needed when
inter-module APIs change; changes to code within a module shouldn't
require this.

Yes, that's true. But it still makes things more complicated since each
of the maintainers will have to do extra work to test the changes.
Anyway we'll see how this plays out. The ideal case would of course be
to get the API right from the start. =)

Thierry