[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v2 5/5] drm: Add NVIDIA Tegra support
- Subject: Re: [RFC v2 5/5] drm: Add NVIDIA Tegra support
- From: Terje Bergström <tbergstrom@xxxxxxxxxx>
- Date: Tue, 22 May 2012 09:19:23 +0300
- Cc: Stephen Warren <swarren@xxxxxxxxxxxxx>, Roedel <joerg.roedel@xxxxxxx>, "devicetree-discuss@xxxxxxxxxxxxxxxx" <devicetree-discuss@xxxxxxxxxxxxxxxx>, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, Joerg@xxxxxxxxxxxxxxx, "dri-devel@xxxxxxxxxxxxxxxxxxxxx" <dri-devel@xxxxxxxxxxxxxxxxxxxxx>, Wolfram Sang <w.sang@xxxxxxxxxxxxxx>, Grant Likely <grant.likely@xxxxxxxxxxxx>, "iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx" <iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx>, "linux-i2c@xxxxxxxxxxxxxxx" <linux-i2c@xxxxxxxxxxxxxxx>, Rob Herring <rob.herring@xxxxxxxxxxx>, Ben Dooks <ben-linux@xxxxxxxxx>, Colin Cross <ccross@xxxxxxxxxxx>, "linux-tegra@xxxxxxxxxxxxxxx" <linux-tegra@xxxxxxxxxxxxxxx>, Jon Mayo <jmayo@xxxxxxxxxx>, Liam Girdwood <lrg@xxxxxx>, Hiroshi Doyu <hdoyu@xxxxxxxxxx>
- Delivered-to: dri-devel@xxxxxxxxxxxxxxxxxxxxx
- In-reply-to: <20120521135838.GA15046@avionic-0098.mockup.avionic-design.de>
- References: <firstname.lastname@example.org> <email@example.com> <4FA78CBD.firstname.lastname@example.org> <4FA7F80F.email@example.com> <20120521110514.GC27686@avionic-0098.mockup.avionic-design.de> <4FBA28FD.firstname.lastname@example.org> <20120521135838.GA15046@avionic-0098.mockup.avionic-design.de>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
On 21.05.2012 16:58, Thierry Reding wrote:
> I agree that reflecting the hardware hierarchy within the device tree makes
> sense. I'll need to add some code to tear down child devices in the cleanup
> path, but that shouldn't be too difficult.
> However, adding a whole bus_type implementation would pretty much duplicate
> the platform bus code. I guess host1x could just provide struct host1x_client
> a set of corresponding APIs to create them, request channels, etc.
There is a reason for existence of bus_type in Linux kernel. It exposes
the various busses to developers, and give a framework for drivers to
work in. It just makes the drivers easier to develop, and makes the big
picture easier to understand.
The problem is that bus_type is cumbersome to implement, and most
implementations seem to duplicate significant amount of code from
platform bus. This is the problem that we should tackle.
If I manage to get the boilerplate code in nvhost for bus_type small
enough, that's the structure we should use. If bus_type is just
inherently fat and broken, I'll need to migrate nvhost away from it.
dri-devel mailing list
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Free Online Dating]
[Big List of Linux Books]