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

[Philipp Rossak]

On 15.02.19 13:58, Paweł Chmiel wrote:
> 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 ?
Sorry I was busy the whole day. All current group members have admin 
rights. So feel free to add others.

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

Regards,
Philipp