On 15.02.19 13:58, Paweł Chmiel wrote:
pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> napisał(a):
Hi Philipp,
Am 14.02.2019 um 19:55 schrieb Philipp Rossak <embed3d@xxxxxxxxx>:
On 14.02.19 19:28, Tony Lindgren wrote:
* Philipp Rossak <embed3d@xxxxxxxxx> [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@xxxxxxxxxxxxxxx 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
