[Openpvrsgx-devgroup] [PATCH] staging: pvr: Add a simplified pvr-drv.c as replacement for messy pvr_drm.c

H. Nikolaus Schaller hns at goldelico.com
Thu Nov 7 17:37:44 CET 2019

Hi TOny,

> Am 07.11.2019 um 17:14 schrieb Tony Lindgren <tony at atomide.com>:
> * H. Nikolaus Schaller <hns at goldelico.com> [191107 10:23]:
>>> Am 07.11.2019 um 08:43 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> I'll try asap and then comment.
>> I did and can only say: great work!
>> Just added the patch, rebuilt the kernel and was able to run the
>> gpu-demo on the omap5 Pyra.
> OK great good to hear :)
>> Then I added some printk and debugging to your code to verify that
>> it is really running and doing the work.
>> And it did work as well.
>> So I can add it to our openpvrsgx-devgroup repo.
> OK
>> And I like the approach to "move" rewritten driver code to
>> the final place. This allows to easily separate what has already
>> been worked on.
> Yeah I see no need for trying to fix up the Imagination DDK
> code. We tried that long time ago with the musb code vendor
> provided code, and it was a waste of time. Hundreds of clean-up
> patches to try to convert it into a proper Linux driver and
> it's still a source of regular problems. It's better to just
> understand and rewrite the parts we need for a Linux driver.

Ok, this may be a better alternative.

And with the existing code in the background we can easily
compare and detect bugs and regressions. That is the key benefit
of getting the DDK working first...

> So now we could remove the old files to avoid confusion:
> drivers/staging/pvr/1.14.3699939/eurasia_km/services4/srvkm/env/linux/pvr_drm.c
> drivers/staging/pvr/1.14.3699939/eurasia_km/services4/srvkm/env/linux/module.c

Yes. Or we just rename them to e.g. pvr_drm.c.old. So that they
are still there for reference.

On the other hand, they can also be found in the git history as well,
so that removing them now is better. I'll add a commit for that.

> The module.c above might still have some dependencies left
> though that should be obvious to fix now if removing it
> breaks compile or demos.

Ok. Maybe for other architectures (e.g. mips/jz4780).

> Those are probably best removed by some clean-up script you
> can run again later on too if we update the Imagination DDK.
> The new driver should do the right thing with current kernels
> with pretty much any version of the Imagination DDK, so
> updating should be easyish :) It should also be possible
> to make it work with the omap3 branch if somebody still
> needs it.

Oh, cool!

> But since you now have omap3 and omap5 working, can we
> just remove the old versions? That's the files at:
> drivers/staging/pvr/omap3
> drivers/staging/pvr/omap5
> Or do you only have the module loading still for omap3
> without the demos working?

Well, the status is that these versions assume that an
ompalfb driver can be built. This assumes the old omapfb
AFAIR which has been deprecated long ago.

So we have no working demo for them with a recent kernel.
But for v3.12...

It is still not clear if the user-space blobs for am335x
can be patched to handle omap3530/dm3730 like the jacinto6
works for omap5. Or if we need this older DDK for some
unknown reason.

BTW: a better name for them would be drivers/staging/pvr/1.9/
or similar, but that would mean a git filter-branch operation
I haven't done yet.

> At least for me it took quite a bit of grepping around and
> being confused with these around. And they can be brought
> back from the git repo if needed for comparing.

Well, it is even easier. It is possible just not to merge
them since they sit in a separate feature branch (letux/omap-pvr).

You should only notice a difference if SGX_114 isn't configured.

Recipie is to just merge:

letux-pvr := git merge letux/omap-sysc-prm-gfx letux/omap-pvr-soc-glue-v6 letux/latest-pvr /* letux/omap-pvr */ letux/omap-pvr-demo


More information about the openpvrsgx-devgroup mailing list