[RFC 11/13] drm/dp: Add helper to dump DPCD

2015-09-04 Thread Daniel Vetter 
On Thu, Sep 03, 2015 at 10:49:34AM -0700, Rafael Antognolli wrote:
> Hi, I'm back from vacation, so I'll be looking at this again.
> 
> On Thu, Aug 20, 2015 at 04:26:42PM -0700, Rafael Antognolli wrote:
> > On Mon, Aug 17, 2015 at 10:02:04AM +0300, Jani Nikula wrote:
> > > On Fri, 14 Aug 2015, Rafael Antognolli  
> > > wrote:
> > > > On Fri, Aug 14, 2015 at 02:56:55PM +0300, Jani Nikula wrote:
> > > >> On Wed, 12 Aug 2015, Thierry Reding  
> > > >> wrote:
> > > >> > From: Thierry Reding 
> > > >> >
> > > >> > The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a
> > > >> > seq_file and can be used to make the DPCD available via debugfs for
> > > >> > example.
> > > >> 
> > > >> See i915/i915_debugfs.c for one DPCD dump implementation.
> > > >> 
> > > >> Around the time that was added, there was also some discussion (and
> > > >> patches [1]) to expose a read/write debugfs interface to DPCD, letting
> > > >> userspace access arbitrary DPCD registers.
> > > >> 
> > > >> Just this week there was some discussion about revisiting that. It was
> > > >> about accessing some proprietary panel features, but there's also the
> > > >> ease of debugging without having to keep updating the kernel to dump
> > > >> more.
> > > >> 
> > > >> I think it would be great to agree on a common debugfs interface to
> > > >> access DPCD arbitrarily. Last time I checked, the blocker to that was
> > > >> access to the aux channel from generic code; it's always driver
> > > >> specific. SMOP. ;)
> > > >
> > > > Do you mean it would require the generic code/interface to somehow route
> > > > this to the driver specific code? I am not sure yet how this works (if
> > > > there's something like it around), but I'll take a look.
> > > 
> > > Drivers can choose to support DP AUX any way they like, and they don't
> > > have to use the common helpers to do so. It's pretty much an
> > > implementation detail. I think we could require the use of the common
> > > helpers to support generic DPCD access from debugfs, but we'd still have
> > > to come up with a way to get hold of struct drm_dp_aux (again, driver
> > > internals) given a drm_connector in generic debugfs code.
> > 
> > I was under the assumption they always used the helpers, but I
> > understand that's not always the case.
> > 
> > Anyway, I was going to propose a new helper to "store" the drm_dp_aux
> > inside the drm_connector. And just expose something on debugfs if it was
> > used. Something like:
> > 
> > int drm_dp_aux_store(struct drm_dp_aux *aux,
> >  struct drm_connector *connector);
> > 
> > The helpers don't seem to know about drm_connector's though, so I'm not sure
> > this is a good approach.
> > 
> > > Thierry, do you see any problems with having a connector function to get
> > > hold of its drm_dp_aux?
> > 
> > Would this be a new function pointer inside struct drm_connector_funcs?
> > If so, I'm fine with this approach too.
> > 
> > Regarding the interface, you mentioned that you didn't like it because
> > it had a state. What about just dumping the content of the register into
> > dmesg when one tries to read it, and use a different sintaxe for
> > writing, passing both the register addr and the value?
> > 
> > Daniel had another suggestion, regarding an ioctl in debugfs, but I'm
> > not sure I clearly understand that yet.
> 
> Regarding the interface, this is the comment Daniel did a while ago:
> 
> "As mentioned in another thread I think the right approach here is to
> expose the dp aux interface through some ioctls in debugfs or dev
> somewhere, and then add simple tools on top of that. Similar to what we
> have with i2c. That would allow us to implement additional things on top
> like mst inspection or using the i2c-over-dp-aux sidechannel."
> 
> If exposing through an ioctl, shouldn't it be yet another DRM ioctl? And
> if not, then I should create another /dev node/file specifically for this
> purpose, right?
> 
> And if we are going with ioctls, I still don't understand exactly how it
> relates to debugfs.

ioctl on some file, either a /dev chardev or just something in debugfs.
And imo it doesn't make sense to have it as an ioctl on the drm device
node since then we'd need to add some form of multiplexing to select the
right dp aux bus (and with dp mst there's new ones for each port on a
downstream hub). I'd just go with copying the i2c design of a chardev for
each master.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC 11/13] drm/dp: Add helper to dump DPCD

2015-09-03 Thread Rafael Antognolli 
Hi, I'm back from vacation, so I'll be looking at this again.

On Thu, Aug 20, 2015 at 04:26:42PM -0700, Rafael Antognolli wrote:
> On Mon, Aug 17, 2015 at 10:02:04AM +0300, Jani Nikula wrote:
> > On Fri, 14 Aug 2015, Rafael Antognolli  
> > wrote:
> > > On Fri, Aug 14, 2015 at 02:56:55PM +0300, Jani Nikula wrote:
> > >> On Wed, 12 Aug 2015, Thierry Reding  wrote:
> > >> > From: Thierry Reding 
> > >> >
> > >> > The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a
> > >> > seq_file and can be used to make the DPCD available via debugfs for
> > >> > example.
> > >> 
> > >> See i915/i915_debugfs.c for one DPCD dump implementation.
> > >> 
> > >> Around the time that was added, there was also some discussion (and
> > >> patches [1]) to expose a read/write debugfs interface to DPCD, letting
> > >> userspace access arbitrary DPCD registers.
> > >> 
> > >> Just this week there was some discussion about revisiting that. It was
> > >> about accessing some proprietary panel features, but there's also the
> > >> ease of debugging without having to keep updating the kernel to dump
> > >> more.
> > >> 
> > >> I think it would be great to agree on a common debugfs interface to
> > >> access DPCD arbitrarily. Last time I checked, the blocker to that was
> > >> access to the aux channel from generic code; it's always driver
> > >> specific. SMOP. ;)
> > >
> > > Do you mean it would require the generic code/interface to somehow route
> > > this to the driver specific code? I am not sure yet how this works (if
> > > there's something like it around), but I'll take a look.
> > 
> > Drivers can choose to support DP AUX any way they like, and they don't
> > have to use the common helpers to do so. It's pretty much an
> > implementation detail. I think we could require the use of the common
> > helpers to support generic DPCD access from debugfs, but we'd still have
> > to come up with a way to get hold of struct drm_dp_aux (again, driver
> > internals) given a drm_connector in generic debugfs code.
> 
> I was under the assumption they always used the helpers, but I
> understand that's not always the case.
> 
> Anyway, I was going to propose a new helper to "store" the drm_dp_aux
> inside the drm_connector. And just expose something on debugfs if it was
> used. Something like:
> 
> int drm_dp_aux_store(struct drm_dp_aux *aux,
>  struct drm_connector *connector);
> 
> The helpers don't seem to know about drm_connector's though, so I'm not sure
> this is a good approach.
> 
> > Thierry, do you see any problems with having a connector function to get
> > hold of its drm_dp_aux?
> 
> Would this be a new function pointer inside struct drm_connector_funcs?
> If so, I'm fine with this approach too.
> 
> Regarding the interface, you mentioned that you didn't like it because
> it had a state. What about just dumping the content of the register into
> dmesg when one tries to read it, and use a different sintaxe for
> writing, passing both the register addr and the value?
> 
> Daniel had another suggestion, regarding an ioctl in debugfs, but I'm
> not sure I clearly understand that yet.

Regarding the interface, this is the comment Daniel did a while ago:

"As mentioned in another thread I think the right approach here is to
expose the dp aux interface through some ioctls in debugfs or dev
somewhere, and then add simple tools on top of that. Similar to what we
have with i2c. That would allow us to implement additional things on top
like mst inspection or using the i2c-over-dp-aux sidechannel."

If exposing through an ioctl, shouldn't it be yet another DRM ioctl? And
if not, then I should create another /dev node/file specifically for this
purpose, right?

And if we are going with ioctls, I still don't understand exactly how it
relates to debugfs.

Thanks,
Rafael

[RFC 11/13] drm/dp: Add helper to dump DPCD

2015-08-20 Thread Rafael Antognolli 
On Mon, Aug 17, 2015 at 10:02:04AM +0300, Jani Nikula wrote:
> On Fri, 14 Aug 2015, Rafael Antognolli  wrote:
> > On Fri, Aug 14, 2015 at 02:56:55PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Aug 2015, Thierry Reding  wrote:
> >> > From: Thierry Reding 
> >> >
> >> > The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a
> >> > seq_file and can be used to make the DPCD available via debugfs for
> >> > example.
> >> 
> >> See i915/i915_debugfs.c for one DPCD dump implementation.
> >> 
> >> Around the time that was added, there was also some discussion (and
> >> patches [1]) to expose a read/write debugfs interface to DPCD, letting
> >> userspace access arbitrary DPCD registers.
> >> 
> >> Just this week there was some discussion about revisiting that. It was
> >> about accessing some proprietary panel features, but there's also the
> >> ease of debugging without having to keep updating the kernel to dump
> >> more.
> >> 
> >> I think it would be great to agree on a common debugfs interface to
> >> access DPCD arbitrarily. Last time I checked, the blocker to that was
> >> access to the aux channel from generic code; it's always driver
> >> specific. SMOP. ;)
> >
> > Do you mean it would require the generic code/interface to somehow route
> > this to the driver specific code? I am not sure yet how this works (if
> > there's something like it around), but I'll take a look.
> 
> Drivers can choose to support DP AUX any way they like, and they don't
> have to use the common helpers to do so. It's pretty much an
> implementation detail. I think we could require the use of the common
> helpers to support generic DPCD access from debugfs, but we'd still have
> to come up with a way to get hold of struct drm_dp_aux (again, driver
> internals) given a drm_connector in generic debugfs code.

I was under the assumption they always used the helpers, but I
understand that's not always the case.

Anyway, I was going to propose a new helper to "store" the drm_dp_aux
inside the drm_connector. And just expose something on debugfs if it was
used. Something like:

int drm_dp_aux_store(struct drm_dp_aux *aux,
 struct drm_connector *connector);

The helpers don't seem to know about drm_connector's though, so I'm not sure
this is a good approach.

> Thierry, do you see any problems with having a connector function to get
> hold of its drm_dp_aux?

Would this be a new function pointer inside struct drm_connector_funcs?
If so, I'm fine with this approach too.

Regarding the interface, you mentioned that you didn't like it because
it had a state. What about just dumping the content of the register into
dmesg when one tries to read it, and use a different sintaxe for
writing, passing both the register addr and the value?

Daniel had another suggestion, regarding an ioctl in debugfs, but I'm
not sure I clearly understand that yet.

Thanks,
Rafael

[RFC 11/13] drm/dp: Add helper to dump DPCD

2015-08-17 Thread Jani Nikula 
On Fri, 14 Aug 2015, Rafael Antognolli  wrote:
> On Fri, Aug 14, 2015 at 02:56:55PM +0300, Jani Nikula wrote:
>> On Wed, 12 Aug 2015, Thierry Reding  wrote:
>> > From: Thierry Reding 
>> >
>> > The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a
>> > seq_file and can be used to make the DPCD available via debugfs for
>> > example.
>> 
>> See i915/i915_debugfs.c for one DPCD dump implementation.
>> 
>> Around the time that was added, there was also some discussion (and
>> patches [1]) to expose a read/write debugfs interface to DPCD, letting
>> userspace access arbitrary DPCD registers.
>> 
>> Just this week there was some discussion about revisiting that. It was
>> about accessing some proprietary panel features, but there's also the
>> ease of debugging without having to keep updating the kernel to dump
>> more.
>> 
>> I think it would be great to agree on a common debugfs interface to
>> access DPCD arbitrarily. Last time I checked, the blocker to that was
>> access to the aux channel from generic code; it's always driver
>> specific. SMOP. ;)
>
> Do you mean it would require the generic code/interface to somehow route
> this to the driver specific code? I am not sure yet how this works (if
> there's something like it around), but I'll take a look.

Drivers can choose to support DP AUX any way they like, and they don't
have to use the common helpers to do so. It's pretty much an
implementation detail. I think we could require the use of the common
helpers to support generic DPCD access from debugfs, but we'd still have
to come up with a way to get hold of struct drm_dp_aux (again, driver
internals) given a drm_connector in generic debugfs code.

Thierry, do you see any problems with having a connector function to get
hold of its drm_dp_aux?

>> I could put some effort into this (maybe Rafael too?), as long as we
>> could agree on the interface. As I wrote in the referenced thread, I
>> wasn't thrilled about what was proposed.
>> 
>
> Yes, I'm willing to put effort into this, for sure. Any help pointing to
> which direction to follow is greatly appreciated.

Great!

BR,
Jani.


>
> Thanks,
> Rafael
>
>> 
>> 
>> [1] http://mid.gmane.org/1428493301-20293-1-git-send-email-durgadoss.r at 
>> intel.com
>> 
>> 
>> 
>> >
>> > Signed-off-by: Thierry Reding 
>> > ---
>> >  drivers/gpu/drm/drm_dp_helper.c | 146 
>> > 
>> >  include/drm/drm_dp_helper.h |   2 +
>> >  2 files changed, 148 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> > b/drivers/gpu/drm/drm_dp_helper.c
>> > index 8968201ea93c..ea74884c9cb3 100644
>> > --- a/drivers/gpu/drm/drm_dp_helper.c
>> > +++ b/drivers/gpu/drm/drm_dp_helper.c
>> > @@ -27,6 +27,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >  #include 
>> >  #include 
>> >  
>> > @@ -292,6 +293,151 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux 
>> > *aux,
>> >  }
>> >  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>> >  
>> > +/**
>> > + * drm_dp_dpcd_dump() - dump DPCD content
>> > + * @aux: DisplayPort AUX channel
>> > + * @s: destination for DPCD dump
>> > + *
>> > + * Reads registers from the DPCD via a DisplayPort AUX channel and dumps 
>> > them
>> > + * to a seq_file.
>> > + */
>> > +void drm_dp_dpcd_dump(struct drm_dp_aux *aux, struct seq_file *s)
>> > +{
>> > +#define DUMP_REG(aux, offset) ({  \
>> > +  u8 value;   \
>> > +  int err;\
>> > +  err = drm_dp_dpcd_readb(aux, offset, );   \
>> > +  if (err < 0) {  \
>> > +  dev_err((aux)->dev, "failed to read %s: %d\n",  \
>> > +  #offset, err);  \
>> > +  return; \
>> > +  }   \
>> > +  seq_printf(s, "%-35s 0x%04x 0x%02x\n", #offset, offset, \
>> > + value);  \
>> > +  })
>> > +
>> > +  DUMP_REG(aux, DP_DPCD_REV);
>> > +  DUMP_REG(aux, DP_MAX_LINK_RATE);
>> > +  DUMP_REG(aux, DP_MAX_LANE_COUNT);
>> > +  DUMP_REG(aux, DP_MAX_DOWNSPREAD);
>> > +  DUMP_REG(aux, DP_NORP);
>> > +  DUMP_REG(aux, DP_DOWNSTREAMPORT_PRESENT);
>> > +  DUMP_REG(aux, DP_MAIN_LINK_CHANNEL_CODING);
>> > +  DUMP_REG(aux, DP_DOWN_STREAM_PORT_COUNT);
>> > +  DUMP_REG(aux, DP_RECEIVE_PORT_0_CAP_0);
>> > +  DUMP_REG(aux, DP_RECEIVE_PORT_0_BUFFER_SIZE);
>> > +  DUMP_REG(aux, DP_RECEIVE_PORT_1_CAP_0);
>> > +  DUMP_REG(aux, DP_RECEIVE_PORT_1_BUFFER_SIZE);
>> > +  DUMP_REG(aux, DP_I2C_SPEED_CAP);
>> > +  DUMP_REG(aux, DP_EDP_CONFIGURATION_CAP);
>> > +  DUMP_REG(aux, DP_TRAINING_AUX_RD_INTERVAL);
>> > +  DUMP_REG(aux, DP_ADAPTER_CAP);
>> > +  DUMP_REG(aux, DP_SUPPORTED_LINK_RATES);
>> > +  DUMP_REG(aux, DP_FAUX_CAP);
>> > +

[RFC 11/13] drm/dp: Add helper to dump DPCD

2015-08-14 Thread Jani Nikula 
On Wed, 12 Aug 2015, Thierry Reding  wrote:
> From: Thierry Reding 
>
> The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a
> seq_file and can be used to make the DPCD available via debugfs for
> example.

See i915/i915_debugfs.c for one DPCD dump implementation.

Around the time that was added, there was also some discussion (and
patches [1]) to expose a read/write debugfs interface to DPCD, letting
userspace access arbitrary DPCD registers.

Just this week there was some discussion about revisiting that. It was
about accessing some proprietary panel features, but there's also the
ease of debugging without having to keep updating the kernel to dump
more.

I think it would be great to agree on a common debugfs interface to
access DPCD arbitrarily. Last time I checked, the blocker to that was
access to the aux channel from generic code; it's always driver
specific. SMOP. ;)

I could put some effort into this (maybe Rafael too?), as long as we
could agree on the interface. As I wrote in the referenced thread, I
wasn't thrilled about what was proposed.

BR,
Jani.


[1] http://mid.gmane.org/1428493301-20293-1-git-send-email-durgadoss.r at 
intel.com



>
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 146 
> 
>  include/drm/drm_dp_helper.h |   2 +
>  2 files changed, 148 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 8968201ea93c..ea74884c9cb3 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -292,6 +293,151 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
>  }
>  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>  
> +/**
> + * drm_dp_dpcd_dump() - dump DPCD content
> + * @aux: DisplayPort AUX channel
> + * @s: destination for DPCD dump
> + *
> + * Reads registers from the DPCD via a DisplayPort AUX channel and dumps them
> + * to a seq_file.
> + */
> +void drm_dp_dpcd_dump(struct drm_dp_aux *aux, struct seq_file *s)
> +{
> +#define DUMP_REG(aux, offset) ({ \
> + u8 value;   \
> + int err;\
> + err = drm_dp_dpcd_readb(aux, offset, );   \
> + if (err < 0) {  \
> + dev_err((aux)->dev, "failed to read %s: %d\n",  \
> + #offset, err);  \
> + return; \
> + }   \
> + seq_printf(s, "%-35s 0x%04x 0x%02x\n", #offset, offset, \
> +value);  \
> + })
> +
> + DUMP_REG(aux, DP_DPCD_REV);
> + DUMP_REG(aux, DP_MAX_LINK_RATE);
> + DUMP_REG(aux, DP_MAX_LANE_COUNT);
> + DUMP_REG(aux, DP_MAX_DOWNSPREAD);
> + DUMP_REG(aux, DP_NORP);
> + DUMP_REG(aux, DP_DOWNSTREAMPORT_PRESENT);
> + DUMP_REG(aux, DP_MAIN_LINK_CHANNEL_CODING);
> + DUMP_REG(aux, DP_DOWN_STREAM_PORT_COUNT);
> + DUMP_REG(aux, DP_RECEIVE_PORT_0_CAP_0);
> + DUMP_REG(aux, DP_RECEIVE_PORT_0_BUFFER_SIZE);
> + DUMP_REG(aux, DP_RECEIVE_PORT_1_CAP_0);
> + DUMP_REG(aux, DP_RECEIVE_PORT_1_BUFFER_SIZE);
> + DUMP_REG(aux, DP_I2C_SPEED_CAP);
> + DUMP_REG(aux, DP_EDP_CONFIGURATION_CAP);
> + DUMP_REG(aux, DP_TRAINING_AUX_RD_INTERVAL);
> + DUMP_REG(aux, DP_ADAPTER_CAP);
> + DUMP_REG(aux, DP_SUPPORTED_LINK_RATES);
> + DUMP_REG(aux, DP_FAUX_CAP);
> + DUMP_REG(aux, DP_MSTM_CAP);
> + DUMP_REG(aux, DP_NUMBER_OF_AUDIO_ENDPOINTS);
> + DUMP_REG(aux, DP_AV_GRANULARITY);
> + DUMP_REG(aux, DP_AUD_DEC_LAT0);
> + DUMP_REG(aux, DP_AUD_DEC_LAT1);
> + DUMP_REG(aux, DP_AUD_PP_LAT0);
> + DUMP_REG(aux, DP_AUD_PP_LAT1);
> + DUMP_REG(aux, DP_VID_INTER_LAT);
> + DUMP_REG(aux, DP_VID_PROG_LAT);
> + DUMP_REG(aux, DP_REP_LAT);
> + DUMP_REG(aux, DP_AUD_DEL_INS0);
> + DUMP_REG(aux, DP_AUD_DEL_INS1);
> + DUMP_REG(aux, DP_AUD_DEL_INS2);
> + DUMP_REG(aux, DP_RECEIVER_ALPM_CAP);
> + DUMP_REG(aux, DP_AUD_DEL_INS0);
> + DUMP_REG(aux, DP_GUID);
> + DUMP_REG(aux, DP_PSR_SUPPORT);
> + DUMP_REG(aux, DP_PSR_CAPS);
> + DUMP_REG(aux, DP_DOWNSTREAM_PORT_0);
> + DUMP_REG(aux, DP_LINK_BW_SET);
> + DUMP_REG(aux, DP_LANE_COUNT_SET);
> + DUMP_REG(aux, DP_TRAINING_PATTERN_SET);
> + DUMP_REG(aux, DP_TRAINING_LANE0_SET);
> + DUMP_REG(aux, DP_TRAINING_LANE1_SET);
> + DUMP_REG(aux, DP_TRAINING_LANE2_SET);
> + DUMP_REG(aux, DP_TRAINING_LANE3_SET);
> + DUMP_REG(aux, DP_DOWNSPREAD_CTRL);
> + DUMP_REG(aux, DP_MAIN_LINK_CHANNEL_CODING_SET);
> + DUMP_REG(aux,

[RFC 11/13] drm/dp: Add helper to dump DPCD

2015-08-14 Thread Rafael Antognolli 
On Fri, Aug 14, 2015 at 02:56:55PM +0300, Jani Nikula wrote:
> On Wed, 12 Aug 2015, Thierry Reding  wrote:
> > From: Thierry Reding 
> >
> > The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a
> > seq_file and can be used to make the DPCD available via debugfs for
> > example.
> 
> See i915/i915_debugfs.c for one DPCD dump implementation.
> 
> Around the time that was added, there was also some discussion (and
> patches [1]) to expose a read/write debugfs interface to DPCD, letting
> userspace access arbitrary DPCD registers.
> 
> Just this week there was some discussion about revisiting that. It was
> about accessing some proprietary panel features, but there's also the
> ease of debugging without having to keep updating the kernel to dump
> more.
> 
> I think it would be great to agree on a common debugfs interface to
> access DPCD arbitrarily. Last time I checked, the blocker to that was
> access to the aux channel from generic code; it's always driver
> specific. SMOP. ;)

Do you mean it would require the generic code/interface to somehow route
this to the driver specific code? I am not sure yet how this works (if
there's something like it around), but I'll take a look.

> I could put some effort into this (maybe Rafael too?), as long as we
> could agree on the interface. As I wrote in the referenced thread, I
> wasn't thrilled about what was proposed.
> 

Yes, I'm willing to put effort into this, for sure. Any help pointing to
which direction to follow is greatly appreciated.

Thanks,
Rafael

> 
> 
> [1] http://mid.gmane.org/1428493301-20293-1-git-send-email-durgadoss.r at 
> intel.com
> 
> 
> 
> >
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 146 
> > 
> >  include/drm/drm_dp_helper.h |   2 +
> >  2 files changed, 148 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 8968201ea93c..ea74884c9cb3 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -27,6 +27,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -292,6 +293,151 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux 
> > *aux,
> >  }
> >  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
> >  
> > +/**
> > + * drm_dp_dpcd_dump() - dump DPCD content
> > + * @aux: DisplayPort AUX channel
> > + * @s: destination for DPCD dump
> > + *
> > + * Reads registers from the DPCD via a DisplayPort AUX channel and dumps 
> > them
> > + * to a seq_file.
> > + */
> > +void drm_dp_dpcd_dump(struct drm_dp_aux *aux, struct seq_file *s)
> > +{
> > +#define DUMP_REG(aux, offset) ({   \
> > +   u8 value;   \
> > +   int err;\
> > +   err = drm_dp_dpcd_readb(aux, offset, );   \
> > +   if (err < 0) {  \
> > +   dev_err((aux)->dev, "failed to read %s: %d\n",  \
> > +   #offset, err);  \
> > +   return; \
> > +   }   \
> > +   seq_printf(s, "%-35s 0x%04x 0x%02x\n", #offset, offset, \
> > +  value);  \
> > +   })
> > +
> > +   DUMP_REG(aux, DP_DPCD_REV);
> > +   DUMP_REG(aux, DP_MAX_LINK_RATE);
> > +   DUMP_REG(aux, DP_MAX_LANE_COUNT);
> > +   DUMP_REG(aux, DP_MAX_DOWNSPREAD);
> > +   DUMP_REG(aux, DP_NORP);
> > +   DUMP_REG(aux, DP_DOWNSTREAMPORT_PRESENT);
> > +   DUMP_REG(aux, DP_MAIN_LINK_CHANNEL_CODING);
> > +   DUMP_REG(aux, DP_DOWN_STREAM_PORT_COUNT);
> > +   DUMP_REG(aux, DP_RECEIVE_PORT_0_CAP_0);
> > +   DUMP_REG(aux, DP_RECEIVE_PORT_0_BUFFER_SIZE);
> > +   DUMP_REG(aux, DP_RECEIVE_PORT_1_CAP_0);
> > +   DUMP_REG(aux, DP_RECEIVE_PORT_1_BUFFER_SIZE);
> > +   DUMP_REG(aux, DP_I2C_SPEED_CAP);
> > +   DUMP_REG(aux, DP_EDP_CONFIGURATION_CAP);
> > +   DUMP_REG(aux, DP_TRAINING_AUX_RD_INTERVAL);
> > +   DUMP_REG(aux, DP_ADAPTER_CAP);
> > +   DUMP_REG(aux, DP_SUPPORTED_LINK_RATES);
> > +   DUMP_REG(aux, DP_FAUX_CAP);
> > +   DUMP_REG(aux, DP_MSTM_CAP);
> > +   DUMP_REG(aux, DP_NUMBER_OF_AUDIO_ENDPOINTS);
> > +   DUMP_REG(aux, DP_AV_GRANULARITY);
> > +   DUMP_REG(aux, DP_AUD_DEC_LAT0);
> > +   DUMP_REG(aux, DP_AUD_DEC_LAT1);
> > +   DUMP_REG(aux, DP_AUD_PP_LAT0);
> > +   DUMP_REG(aux, DP_AUD_PP_LAT1);
> > +   DUMP_REG(aux, DP_VID_INTER_LAT);
> > +   DUMP_REG(aux, DP_VID_PROG_LAT);
> > +   DUMP_REG(aux, DP_REP_LAT);
> > +   DUMP_REG(aux, DP_AUD_DEL_INS0);
> > +   DUMP_REG(aux, DP_AUD_DEL_INS1);
> > +   DUMP_REG(aux, DP_AUD_DEL_INS2);
> > +   DUMP_REG(aux, DP_RECEIVER_ALPM_CAP);
> > +   DUMP_REG(aux, DP_AUD_DEL_INS0);
> > +   DUMP_REG(aux, DP_GUID);
> > +   DUMP_REG(aux,

[RFC 11/13] drm/dp: Add helper to dump DPCD

2015-08-12 Thread Thierry Reding 
From: Thierry Reding 

The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a
seq_file and can be used to make the DPCD available via debugfs for
example.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 146 
 include/drm/drm_dp_helper.h |   2 +
 2 files changed, 148 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8968201ea93c..ea74884c9cb3 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -292,6 +293,151 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
 }
 EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);

+/**
+ * drm_dp_dpcd_dump() - dump DPCD content
+ * @aux: DisplayPort AUX channel
+ * @s: destination for DPCD dump
+ *
+ * Reads registers from the DPCD via a DisplayPort AUX channel and dumps them
+ * to a seq_file.
+ */
+void drm_dp_dpcd_dump(struct drm_dp_aux *aux, struct seq_file *s)
+{
+#define DUMP_REG(aux, offset) ({   \
+   u8 value;   \
+   int err;\
+   err = drm_dp_dpcd_readb(aux, offset, );   \
+   if (err < 0) {  \
+   dev_err((aux)->dev, "failed to read %s: %d\n",  \
+   #offset, err);  \
+   return; \
+   }   \
+   seq_printf(s, "%-35s 0x%04x 0x%02x\n", #offset, offset, \
+  value);  \
+   })
+
+   DUMP_REG(aux, DP_DPCD_REV);
+   DUMP_REG(aux, DP_MAX_LINK_RATE);
+   DUMP_REG(aux, DP_MAX_LANE_COUNT);
+   DUMP_REG(aux, DP_MAX_DOWNSPREAD);
+   DUMP_REG(aux, DP_NORP);
+   DUMP_REG(aux, DP_DOWNSTREAMPORT_PRESENT);
+   DUMP_REG(aux, DP_MAIN_LINK_CHANNEL_CODING);
+   DUMP_REG(aux, DP_DOWN_STREAM_PORT_COUNT);
+   DUMP_REG(aux, DP_RECEIVE_PORT_0_CAP_0);
+   DUMP_REG(aux, DP_RECEIVE_PORT_0_BUFFER_SIZE);
+   DUMP_REG(aux, DP_RECEIVE_PORT_1_CAP_0);
+   DUMP_REG(aux, DP_RECEIVE_PORT_1_BUFFER_SIZE);
+   DUMP_REG(aux, DP_I2C_SPEED_CAP);
+   DUMP_REG(aux, DP_EDP_CONFIGURATION_CAP);
+   DUMP_REG(aux, DP_TRAINING_AUX_RD_INTERVAL);
+   DUMP_REG(aux, DP_ADAPTER_CAP);
+   DUMP_REG(aux, DP_SUPPORTED_LINK_RATES);
+   DUMP_REG(aux, DP_FAUX_CAP);
+   DUMP_REG(aux, DP_MSTM_CAP);
+   DUMP_REG(aux, DP_NUMBER_OF_AUDIO_ENDPOINTS);
+   DUMP_REG(aux, DP_AV_GRANULARITY);
+   DUMP_REG(aux, DP_AUD_DEC_LAT0);
+   DUMP_REG(aux, DP_AUD_DEC_LAT1);
+   DUMP_REG(aux, DP_AUD_PP_LAT0);
+   DUMP_REG(aux, DP_AUD_PP_LAT1);
+   DUMP_REG(aux, DP_VID_INTER_LAT);
+   DUMP_REG(aux, DP_VID_PROG_LAT);
+   DUMP_REG(aux, DP_REP_LAT);
+   DUMP_REG(aux, DP_AUD_DEL_INS0);
+   DUMP_REG(aux, DP_AUD_DEL_INS1);
+   DUMP_REG(aux, DP_AUD_DEL_INS2);
+   DUMP_REG(aux, DP_RECEIVER_ALPM_CAP);
+   DUMP_REG(aux, DP_AUD_DEL_INS0);
+   DUMP_REG(aux, DP_GUID);
+   DUMP_REG(aux, DP_PSR_SUPPORT);
+   DUMP_REG(aux, DP_PSR_CAPS);
+   DUMP_REG(aux, DP_DOWNSTREAM_PORT_0);
+   DUMP_REG(aux, DP_LINK_BW_SET);
+   DUMP_REG(aux, DP_LANE_COUNT_SET);
+   DUMP_REG(aux, DP_TRAINING_PATTERN_SET);
+   DUMP_REG(aux, DP_TRAINING_LANE0_SET);
+   DUMP_REG(aux, DP_TRAINING_LANE1_SET);
+   DUMP_REG(aux, DP_TRAINING_LANE2_SET);
+   DUMP_REG(aux, DP_TRAINING_LANE3_SET);
+   DUMP_REG(aux, DP_DOWNSPREAD_CTRL);
+   DUMP_REG(aux, DP_MAIN_LINK_CHANNEL_CODING_SET);
+   DUMP_REG(aux, DP_I2C_SPEED_CONTROL_STATUS);
+   DUMP_REG(aux, DP_EDP_CONFIGURATION_SET);
+   DUMP_REG(aux, DP_LINK_QUAL_LANE0_SET);
+   DUMP_REG(aux, DP_LINK_QUAL_LANE1_SET);
+   DUMP_REG(aux, DP_LINK_QUAL_LANE2_SET);
+   DUMP_REG(aux, DP_LINK_QUAL_LANE3_SET);
+   DUMP_REG(aux, DP_TRAINING_LANE0_1_SET2);
+   DUMP_REG(aux, DP_TRAINING_LANE2_3_SET2);
+   DUMP_REG(aux, DP_MSTM_CTRL);
+   DUMP_REG(aux, DP_AUDIO_DELAY0);
+   DUMP_REG(aux, DP_AUDIO_DELAY1);
+   DUMP_REG(aux, DP_AUDIO_DELAY2);
+   DUMP_REG(aux, DP_LINK_RATE_SET);
+   DUMP_REG(aux, DP_RECEIVER_ALPM_CONFIG);
+   DUMP_REG(aux, DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF);
+   DUMP_REG(aux, DP_UPSTREAM_DEVICE_DP_PWR_NEED);
+   DUMP_REG(aux, DP_AUX_FRAME_SYNC_VALUE);
+   DUMP_REG(aux, DP_PSR_EN_CFG);
+   DUMP_REG(aux, DP_ADAPTER_CTRL);
+   DUMP_REG(aux, DP_BRANCH_DEVICE_CTRL);
+   DUMP_REG(aux, DP_PAYLOAD_ALLOCATE_SET);
+   DUMP_REG(aux, DP_PAYLOAD_ALLOCATE_START_TIME_SLOT);
+   DUMP_REG(aux, DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT);
+