Hi Manu,
On Thu, Mar 05, 2015 at 10:04:21AM +0100, Emmanuel MICHEL wrote:
Hello Joakim,
Thanks for this clear proposal.
This is not a global feedback, but just a specific point that first raise to my mind: As I understand, you want to set up a generic driver which would be independant of GP api. You propose to push all related GP encapsulation to user land, but some stuff must be done at kernel side (retrieve physical address of shm, cache management, ...). So if a follow your mind, this may be done in the specific driver. Is that ?
Yes, GP code will go into the user space client and the specific driver.
Is yes, that mean this this today factorized code shared to and use by the tz specific module and the st specific core module could be duplicated. Sure, we could imagine to have another modules to handle GP specificities shared by GP specific modules, but ... I don't know.
We should try to avoid code duplication as much as possible. To avoid this happening in specific driver we might end up having to leverage the specific driver from sub-driver also.
Perhaps we (?) have to draw all (known) use cases with your design proposal. And perhaps also do the exercise with other proposal, as having two (+) modules exposed to user side: a GP one, and a x one. I suppose we have to maturate all that.
I'm open for having a use case based discussion. However I'm afraid that we will just end up with a lot of discussions. After reading all responses in this thread yesterday I think we need to start with identifying the needed IOCTL's. Defining the IOCTL's will implicitly require us to think about use cases.
Cheers Manu