On Wed, Sep 16, 2015 at 11:47:21PM +0300, Ville Syrjälä wrote:
On Wed, Sep 16, 2015 at 01:09:54PM -0700, Daniel Vetter wrote:
On Tue, Sep 15, 2015 at 10:03:09AM -0700, Rafael Antognolli wrote:
On Tue, Sep 15, 2015 at 07:46:55PM +0300, Ville Syrjälä wrote:
On Tue, Sep 15, 2015 at 07:41:06PM +0300, Ville Syrjälä wrote:
On Tue, Sep 15, 2015 at 09:34:15AM -0700, Rafael Antognolli wrote:
On Tue, Sep 15, 2015 at 10:35:19AM +0300, Ville Syrjälä wrote: > On Mon, Sep 14, 2015 at 04:12:29PM -0700, Rafael Antognolli wrote: > > This is a tentative implementation of a module that allows reading/writing > > arbitrary dpcd registers, following the suggestion from Daniel Vetter. It > > assumes the drm aux helpers were used by the driver. > > > > I tried to follow the i2c-dev implementation as close as possible, but the only > > operations that are provided on the dev node are two different ioctl's, one for > > reading a register and another one for writing it. > > Why would you use ioctls instead of normal read/write syscalls? >
For writing, that should work fine, I can easily change that if you prefer.
For reading, one has to first tell which register address is going to be read.
seek()
Sorry typo. Make that lseek().
Oh, nice, I'll update the patch with this and remove the notifier stuff, thanks!
Well there's also other modes like i2c over aux, and that would be easier to support with an ioctl in a uniform way. So not sure how much value there is in reusing read/write for i2c ...
We already have i2c-dev for i2c. So not sure what you're after here.
i2c is a bit of a mess on the protocol level. Lots of devices do interesting things with it, so it can't really make do with just read/write/lseek. Apart from i2c-over-aux, the rest is all about DPCD access, and for that read/write/lseek is all you ever need.
I just noticed that I forgot to cc you guys, but yesterday I sent an updated version of the patch set to this list:
http://lists.freedesktop.org/archives/dri-devel/2015-September/090366.html
I also don't have a strong opinion about ioctl vs read/write/lseek, but at least my second implementation did get a little cleaner.
Thanks, Rafael