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

Tony Lindgren tony at atomide.com
Thu Nov 7 17:55:15 CET 2019


* H. Nikolaus Schaller <hns at goldelico.com> [191107 16:38]:
> > Am 07.11.2019 um 17:14 schrieb Tony Lindgren <tony at atomide.com>:
> > * H. Nikolaus Schaller <hns at goldelico.com> [191107 10:23]:
> >> 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.

Yes for sure.

> 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...

Yes and thanks for doing that!

> > 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.

OK

> > 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).

At least compatible + and maybe also the pvr-drv.h id trickery
is needed for mips/jz4780 if there are more than one version.

> > 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...

OK. I've added Merlijn to Cc, he's saying the maemo-leste
folks do have ompalfb patched and working on n900 with
the current kernels. So maybe the git tree omap3 branch
should contain those patches then.

> 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.

My guess is that there might be hardware differences between
various sgx530 versions needing microkernel. And currently
custom kernel module too. Otherwise it seems that there
should be no need for separate am335x and am437x userspace
like the TI DDK has if they both have sgx530.

> 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.

OK yeah.

> > 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

Oh nice, yeah let's do that. That way anybody needing the
old omap3 or omap5 branch can work on those and grepping
around will be easier for drivers/staging/pvr/1.9.

Regards,

Tony


More information about the openpvrsgx-devgroup mailing list