[Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Paweł Chmiel]

pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller <hns at goldelico.com> napisał(a):
>
> Hi Philipp,
>
> > Am 14.02.2019 um 19:55 schrieb Philipp Rossak <embed3d at gmail.com>:
> >
> >
> >
> > On 14.02.19 19:28, Tony Lindgren wrote:
> >> * Philipp Rossak <embed3d at gmail.com> [190214 10:18]:
> >>> I set the displayed name to "OpenSGX Linux Driver Group" but that can be
> >>> changed later, if necessary.
> >> You might want to change it to something more specific like
> >> "OpenPVRSGX Linux Driver Group" :)
> >> There is already non-graphics related Intel SGX "opensgx":
> >> https://github.com/sslab-gatech/opensgx
> >> Regards,
> >> Tony
> > Thanks Tony!
> >
> > I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup
Only Two people in organization ? And is there anyone on irc ?
>
> Fine!
>
> I have tried to get in, but there seems to be no "request to join" button or something. So I'll send you my github user name
> by PM. Or if you can send a invitation by e-mails, just copy the list from this mail?
>
> Next, I had asked postmaster at vger.kernel.org to get a mailing list for us, but they declined with only stating "it is not appropriate"
> because it is for kernel related topics. I asked again that we work for the Linux kernel and want to get it into staging, but that
> is still not appropriate. No further details, so that I do not know what really would be appropriate. Does it need Linus' approval
> or must be decided on some core developer meeting? But that is just my guess.
>
> Finally, I have tested our omap3 version and it works fine in v4.15. But is broken in v4.16.17 and beyond. This problem did
> not get noticed in our automatic tests because they test only for module loading and /dev/pvrsrvkm existence and not for
> pvrsrvctl --start success.
>
> Now, I found one bug in my patch set that prevented running v4.17 and later because the code was not compatible with
> CONFIG_RESET_CONTROLLER=y (which we do have enabled since v4.17). After fixing this, it still returns an EFAULT in
> some ioctl() during firmware download.
>
> But I could reduce it to be introduced between v4.16.13 to v4.16.15. I am currently doing a bisect so that seems not to be
> far away from finding the problematic commit.
>
> BR,
> NIkolaus
>