From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Daniel Vetter" <daniel@ffwll.ch>
Cc: daniel.vetter@ffwll.ch, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/3] RFC: Add a drm_aux-dev module.
Date: Thu, 17 Sep 2015 10:01:38 +0300 [thread overview]
Message-ID: <87r3lxttpp.fsf@intel.com> (raw)
In-Reply-To: <20150916204721.GL26517@intel.com>
On Wed, 16 Sep 2015, Ville Syrjälä <ville.syrjala@linux.intel.com> 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.
Yeah, definitely don't reinvent the wheel for this.
BR,
Jani.
>
> 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.
>
> --
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-09-17 6:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 23:12 [PATCH 0/3] RFC: Add a drm_aux-dev module Rafael Antognolli
2015-09-14 23:12 ` [PATCH 1/3] drm/dp: Keep a list of drm_dp_aux helper Rafael Antognolli
2015-09-15 7:46 ` Ville Syrjälä
2015-09-15 16:27 ` Rafael Antognolli
2015-09-15 16:57 ` Ville Syrjälä
2015-09-16 20:06 ` Daniel Vetter
2015-09-14 23:12 ` [PATCH 2/3] drm/dp: Store the drm_connector device pointer on the helper Rafael Antognolli
2015-09-14 23:12 ` [PATCH 3/3] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers Rafael Antognolli
2015-09-15 7:35 ` [PATCH 0/3] RFC: Add a drm_aux-dev module Ville Syrjälä
2015-09-15 16:34 ` Rafael Antognolli
2015-09-15 16:41 ` Ville Syrjälä
2015-09-15 16:46 ` Ville Syrjälä
2015-09-15 17:03 ` Rafael Antognolli
2015-09-16 20:09 ` Daniel Vetter
2015-09-16 20:47 ` Ville Syrjälä
2015-09-16 20:51 ` Rafael Antognolli
2015-09-17 7:01 ` Jani Nikula [this message]
2015-09-17 14:42 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r3lxttpp.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.