[PATCH v2 15/27] gpu: host1x: Add support for Tegra114

Thierry Reding thierry.reding at gmail.com
Tue Oct 15 10:03:25 CEST 2013


On Mon, Oct 14, 2013 at 12:07:33PM -0600, Stephen Warren wrote:
> On 10/12/2013 05:24 AM, Thierry Reding wrote:
> > On Fri, Oct 11, 2013 at 04:13:07PM -0600, Stephen Warren wrote:
> >> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> >>> Tegra114 uses a slightly updated version of host1x with an
> >>> additional syncpoint.
> >> 
> >>> drivers/gpu/host1x/hw/host1x02.c            |  42 +++++ 
> >>> drivers/gpu/host1x/hw/host1x02.h            |  26 +++ 
> >>> drivers/gpu/host1x/hw/hw_host1x02_channel.h | 121
> >>> ++++++++++++++ drivers/gpu/host1x/hw/hw_host1x02_sync.h    |
> >>> 243 ++++++++++++++++++++++++++++ 
> >>> drivers/gpu/host1x/hw/hw_host1x02_uclass.h  | 175
> >>> ++++++++++++++++++++
> >> 
> >> That seems like an awful lot of extra lines to support just one
> >> extra syncpoint. Are there other changes? If not, can the code
> >> be shared/parameterized somehow?
> > 
> > Yeah, I don't like very much how this is currently done. I mean
> > about half of this is actually duplicate code because of the static
> > inline functions used for register defines. As discussed elsewhere
> > this was originally meant to be used for coverage testing, but
> > nobody's done anything like that as far as I know. I'm also not
> > convinced that these would be very useful in coverage testing, but
> > adding Terje on Cc and unless he or anyone else has any (strong)
> > objections I'll go and remove the duplicate definitions and while
> > at it see if I can come up with a way to share more
> > code/definitions between versions of host1x.
> > 
> > Do you see this as a blocker for 3.13 or can I do the cleanup
> > after that? As far as I know Tegra124 has a more heavily modified
> > version of host1x so implementing Tegra124 support might be a good
> > opportunity to clean this up anyway.
> 
> I guess I'm unsure re: whether it's a blocker. It's certainly not some
> kind of ABI issue, so it's not like it forces our hand later; we can
> easily refactor the code later. However, I'm slightly worried that if
> we do actually intend to do that, it'll be seen as code-churn. Still,
> I guess if the main DRM maintainers don't object to this, I'm OK with it.

Adding Dave. Dave, do you have any objections to cleaning this up after
3.13? I'd prefer not to have to do it this cycle because I'd like to
focus on what patches I currently have. The plan is to upstream support
for the next SoC (Tegra124) for 3.14 and I'd much rather do the cleanup
along with that work.

Does that sound reasonable?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131015/45ccc7c8/attachment.pgp>


More information about the dri-devel mailing list