[Intel-gfx] [PATCH 1/7] drm: Renaming DP training vswing pre emph defines

Thierry Reding thierry.reding at gmail.com
Wed Aug 27 15:11:08 CEST 2014


On Wed, Aug 27, 2014 at 08:47:54AM +0100, Damien Lespiau wrote:
> On Tue, Aug 26, 2014 at 01:28:19PM +0200, Thierry Reding wrote:
> > On Fri, Aug 08, 2014 at 04:23:40PM +0530, sonika.jindal at intel.com wrote:
> > > From: Sonika Jindal <sonika.jindal at intel.com>
> > > 
> > > Adding new defines, older one will be removed in the last patch in the series.
> > > This is to rename the defines to have levels instead of values for vswing and
> > > pre-emph levels as the values may differ in other scenarios like low vswing of
> > > eDP1.4 where the values are different.
> > > 
> > > Done using following cocci patch for each define:
> > > @@
> > > @@
> > > 
> > >  # define DP_TRAIN_VOLTAGE_SWING_400     (0 << 0)
> > > + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0     (0 << 0)
> > 
> > Could this perhaps be simply:
> > 
> > 	#define DP_TRAIN_VOLTAGE_SWING(x) ((x) << 0)
> > 
> > As it is, there's no information about the value within the symbolic
> > name anyway, so _LEVEL_* really isn't that useful and keeping several
> > macros for each value seems isn't either.
> 
> The _LEVEL_ part is quite important IMHO, that's what changes between those
> different defines, controlling a level shifter, somewhere.
> 
> So we're left with
> 
>   #define DP_TRAIN_VOLTAGE_SWING_LEVEL_0     (0 << 0)
> 
> Vs
> 
>   #define DP_TRAIN_VOLTAGE_SWING_LEVEL(x)     ((x) << 0)
> 
> The second variant doesn't really bring much more clarity? Can we just
> go with the first?

I think the parameterized version is more convenient, especially if you
want to use that during training sequences and iterate over the levels.

But I don't feel too strongly about it, so either way is fine with me.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140827/9d65e935/attachment.sig>


More information about the Intel-gfx mailing list