Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
Make data/link N value power of two") from Linus' tree and commit
e3b95f1eb5b9 ("drm/i915: Apply OCD to data/link m/n register #defines")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Daniel, I assume all this stuff being added to the drm-intel tree is
going upstream very soon?
--
Cheers,
Stephen Rothwell [email protected]
diff --cc drivers/gpu/drm/i915/i915_reg.h
index 83f9c26,a470103..0000000
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@@ -2648,18 -2768,19 +2768,19 @@@
* which is after the LUTs, so we want the bytes for our color format.
* For our current usage, this is always 3, one byte for R, G and B.
*/
- #define _PIPEA_GMCH_DATA_M 0x70050
- #define _PIPEB_GMCH_DATA_M 0x71050
+ #define _PIPEA_DATA_M_G4X 0x70050
+ #define _PIPEB_DATA_M_G4X 0x71050
/* Transfer unit size for display port - 1, default is 0x3f (for TU size 64) */
-#define PIPE_GMCH_DATA_M_TU_SIZE_MASK (0x3f << 25)
-#define PIPE_GMCH_DATA_M_TU_SIZE_SHIFT 25
+#define TU_SIZE(x) (((x)-1) << 25) /* default size 64 */
+#define TU_SIZE_MASK (0x3f << 25)
+ #define TU_SIZE_SHIFT 25
-#define PIPE_GMCH_DATA_M_MASK (0xffffff)
+#define DATA_LINK_M_N_MASK (0xffffff)
+#define DATA_LINK_N_MAX (0x800000)
- #define _PIPEA_GMCH_DATA_N 0x70054
- #define _PIPEB_GMCH_DATA_N 0x71054
+ #define _PIPEA_DATA_N_G4X 0x70054
+ #define _PIPEB_DATA_N_G4X 0x71054
-#define PIPE_GMCH_DATA_N_MASK (0xffffff)
/*
* Computing Link M and N values for the Display Port link
@@@ -2672,16 -2793,18 +2793,16 @@@
* Attributes and VB-ID.
*/
- #define _PIPEA_DP_LINK_M 0x70060
- #define _PIPEB_DP_LINK_M 0x71060
+ #define _PIPEA_LINK_M_G4X 0x70060
+ #define _PIPEB_LINK_M_G4X 0x71060
-#define PIPEA_DP_LINK_M_MASK (0xffffff)
- #define _PIPEA_DP_LINK_N 0x70064
- #define _PIPEB_DP_LINK_N 0x71064
+ #define _PIPEA_LINK_N_G4X 0x70064
+ #define _PIPEB_LINK_N_G4X 0x71064
-#define PIPEA_DP_LINK_N_MASK (0xffffff)
- #define PIPE_GMCH_DATA_M(pipe) _PIPE(pipe, _PIPEA_GMCH_DATA_M, _PIPEB_GMCH_DATA_M)
- #define PIPE_GMCH_DATA_N(pipe) _PIPE(pipe, _PIPEA_GMCH_DATA_N, _PIPEB_GMCH_DATA_N)
- #define PIPE_DP_LINK_M(pipe) _PIPE(pipe, _PIPEA_DP_LINK_M, _PIPEB_DP_LINK_M)
- #define PIPE_DP_LINK_N(pipe) _PIPE(pipe, _PIPEA_DP_LINK_N, _PIPEB_DP_LINK_N)
+ #define PIPE_DATA_M_G4X(pipe) _PIPE(pipe, _PIPEA_DATA_M_G4X, _PIPEB_DATA_M_G4X)
+ #define PIPE_DATA_N_G4X(pipe) _PIPE(pipe, _PIPEA_DATA_N_G4X, _PIPEB_DATA_N_G4X)
+ #define PIPE_LINK_M_G4X(pipe) _PIPE(pipe, _PIPEA_LINK_M_G4X, _PIPEB_LINK_M_G4X)
+ #define PIPE_LINK_N_G4X(pipe) _PIPE(pipe, _PIPEA_LINK_N_G4X, _PIPEB_LINK_N_G4X)
/* Display & cursor control */
On Tue, May 7, 2013 at 3:27 AM, Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
> Make data/link N value power of two") from Linus' tree and commit
> e3b95f1eb5b9 ("drm/i915: Apply OCD to data/link m/n register #defines")
> from the drm-intel tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> Daniel, I assume all this stuff being added to the drm-intel tree is
> going upstream very soon?
Oops, no that is stuff for 3.11. Lazy me hoped I could sneak stuff
through (since we just keep on merging features to
drm-intel-next-queued to avoid stalls), but that's obviously not what
you want for linux-next. My apologies for that mess. I've now created
a for-linux-next branch which will not contain patches heading for
3.x+1 while 3.x-rc1 hasn't been released yet.
Can you please switch over to that branch for inclusion into linux-next?
Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Hi Daniel,
On Tue, 7 May 2013 10:43:17 +0200 Daniel Vetter <[email protected]> wrote:
>
> On Tue, May 7, 2013 at 3:27 AM, Stephen Rothwell <[email protected]> wrote:
> >
> > Daniel, I assume all this stuff being added to the drm-intel tree is
> > going upstream very soon?
>
> Oops, no that is stuff for 3.11. Lazy me hoped I could sneak stuff
> through (since we just keep on merging features to
> drm-intel-next-queued to avoid stalls), but that's obviously not what
> you want for linux-next. My apologies for that mess. I've now created
> a for-linux-next branch which will not contain patches heading for
> 3.x+1 while 3.x-rc1 hasn't been released yet.
>
> Can you please switch over to that branch for inclusion into linux-next?
Done. Thanks.
--
Cheers,
Stephen Rothwell [email protected]