Skip to contentSkip to conversation

linux-next: build failure after merge of the drm-xe tree

DISCUSSION Mark Brown 5 participants 15 messages Mar 11 – Mar 19 Linux-next tree

lore
Share & tools
lore

Mark Brown

author maintainer
#0 lore raw

Hi all,

After merging the drm-xe tree, today's linux-next build (KCONFIG_NAME) failed like this:

/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c: In function 'xe_lrc_ctx_init':
/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c:1554:43: error: implicit declaration of function '_MASKED_BIT_ENABLE'; did you mean 'REG_MASKED_FIELD_ENABLE'? [-Wimplicit-function-declaration]

 1554 |                 state_cache_perf_fix[2] = _MASKED_BIT_ENABLE(DISABLE_STATE_CACHE_PERF_FIX);
      |                                           ^~~~~~~~~~~~~~~~~~
      |                                           REG_MASKED_FIELD_ENABLE

Caused by commit

0e07b16371b6e (drm/xe: Allow per queue programming of COMMON_SLICE_CHICKEN3 bit13)

I have used the tree from next-20260310 instead.

#1 lore raw

Hi Rodrigo, can you help me here?

I think this issue was because
https://lore.kernel.org/all/49dc20448a12f3e03f5f8347540d167a281b8987.1772042022.git.jani.nikula@intel.com/
was merged in drm-intel-next.

If it was splitted into a i915 and a Xe KMD patches and merged each to its own tree I think we would have avoided the issue.
But I have not looked at that whole series to understand why that decision was made.

I don't know how to fix it, maybe rebase drm-xe-next on top of drm- intel-next and then a new commit fixing 0e07b16371b6e. Not sure what is the best option, can you help us here?

Thank you

Quoted 23 lines · Mark Brown

Hi all,

After merging the drm-xe tree, today's linux-next build (KCONFIG_NAME)
failed like this:

/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c: In function 'xe_lrc_ctx_init':
/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c:1554:43: error: implicit declaration of function '_MASKED_BIT_ENABLE'; did you mean 'REG_MASKED_FIELD_ENABLE'? [-Wimplicit-function-declaration] 1554 |                 state_cache_perf_fix[2] = _MASKED_BIT_ENABLE(DISABLE_STATE_CACHE_PERF_FIX);
      |                                           ^~~~~~~~~~~~~~~~~~ |
REG_MASKED_FIELD_ENABLE

Caused by commit

  0e07b16371b6e (drm/xe: Allow per queue programming of COMMON_SLICE_CHICKEN3 bit13)

I have used the tree from next-20260310 instead.

#2 lore raw
Quoted 6 lines · Jose

Hi Rodrigo, can you help me here?

I think this issue was because
https://lore.kernel.org/all/49dc20448a12f3e03f5f8347540d167a281b8987.1772042022.git.jani.nikula@intel.com/
was merged in drm-intel-next.

Quoted 8 lines

If it was splitted into a i915 and a Xe KMD patches and merged each to its own tree I think we would have avoided the issue.
But I have not looked at that whole series to understand why that decision was made.

I don't know how to fix it, maybe rebase drm-xe-next on top of drm- intel-next and then a new commit fixing 0e07b16371b6e. Not sure what is the best option, can you help us here?

This explains why the patch was not applying cleanly.
This is the reason why we should never ever edit the patch directly when merging.

If this is breaking the drm-tip build as well we should immediately revert the patch. But I'm considering this anyway.

The alternative to that is:

Jani needs to do a drm-intel-next Pull request towards drm-next. Then Sima and Dave picks that up.
Then Brost do a backmerge fixing the build issue in the merge commit. Once we fix it we let Mark know so the branch gets re-enabled in linux-next.

Let's revert and re-attempt after drm-intel-next and drm-xe-next are back in sync?

Quoted 28 lines

Thank you

Quoted 23 lines · Mark Brown

Hi all,

After merging the drm-xe tree, today's linux-next build (KCONFIG_NAME)
failed like this:

/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c: In function 'xe_lrc_ctx_init':
/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c:1554:43: error: implicit declaration of function '_MASKED_BIT_ENABLE'; did you mean 'REG_MASKED_FIELD_ENABLE'? [-Wimplicit-function-declaration] 1554 |                 state_cache_perf_fix[2] = _MASKED_BIT_ENABLE(DISABLE_STATE_CACHE_PERF_FIX);
      |                                           ^~~~~~~~~~~~~~~~~~ |
REG_MASKED_FIELD_ENABLE

Caused by commit

  0e07b16371b6e (drm/xe: Allow per queue programming of COMMON_SLICE_CHICKEN3 bit13)

I have used the tree from next-20260310 instead.

#3 lore raw
Quoted 27 lines · Rodrigo Vivi
Quoted 12 lines · Jose

Hi Rodrigo, can you help me here?

I think this issue was because
https://lore.kernel.org/all/49dc20448a12f3e03f5f8347540d167a281b8987.1772042022.git.jani.nikula@intel.com/
was merged in drm-intel-next.

If it was splitted into a i915 and a Xe KMD patches and merged each to
its own tree I think we would have avoided the issue. But I have not looked at that whole series to understand why that decision was made.

Quoted 3 lines

I don't know how to fix it, maybe rebase drm-xe-next on top of drm- intel-next and then a new commit fixing 0e07b16371b6e. Not sure what is the best option, can you help us here?

This explains why the patch was not applying cleanly. This is the reason why we should never ever edit the patch directly when merging.

If this is breaking the drm-tip build as well we should immediately revert the
patch. But I'm considering this anyway.

The alternative to that is:

Quoted 8 lines

Jani needs to do a drm-intel-next Pull request towards drm-next. Then Sima and Dave picks that up.
Then Brost do a backmerge fixing the build issue in the merge commit. Once we fix it we let Mark know so the branch gets re-enabled in linux-next.

Let's revert and re-attempt after drm-intel-next and drm-xe-next are back in sync?

drm-tip is not broken, Marteen fixed it in drm-rerere.

How long would it take to do this sync? If this is less than 30days I think we can revert and wait, if that is okay for Lionel that is working in the feature that depends on that patch.

Quoted 32 lines
Quoted 32 lines

Thank you

Quoted 25 lines · Mark Brown

Hi all,

After merging the drm-xe tree, today's linux-next build (KCONFIG_NAME)
failed like this:

/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c: In function 'xe_lrc_ctx_init':
/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c:1554:43: error:
implicit
declaration of function '_MASKED_BIT_ENABLE'; did you mean 'REG_MASKED_FIELD_ENABLE'? [-Wimplicit-function-declaration] 1554 |                 state_cache_perf_fix[2] = _MASKED_BIT_ENABLE(DISABLE_STATE_CACHE_PERF_FIX); |
^~~~~~~~~~~~~~~~~~
      |
REG_MASKED_FIELD_ENABLE

Caused by commit

  0e07b16371b6e (drm/xe: Allow per queue programming of COMMON_SLICE_CHICKEN3 bit13)

I have used the tree from next-20260310 instead.

#4 lore raw
Quoted 34 lines · Jose
Quoted 33 lines · Rodrigo Vivi
Quoted 12 lines · Jose

Hi Rodrigo, can you help me here?

I think this issue was because
https://lore.kernel.org/all/49dc20448a12f3e03f5f8347540d167a281b8987.1772042022.git.jani.nikula@intel.com/
was merged in drm-intel-next.

If it was splitted into a i915 and a Xe KMD patches and merged each to
its own tree I think we would have avoided the issue. But I have not looked at that whole series to understand why that decision was made.

Quoted 3 lines

I don't know how to fix it, maybe rebase drm-xe-next on top of drm- intel-next and then a new commit fixing 0e07b16371b6e. Not sure what is the best option, can you help us here?

This explains why the patch was not applying cleanly. This is the reason why we should never ever edit the patch directly when merging.

If this is breaking the drm-tip build as well we should immediately revert the
patch. But I'm considering this anyway.

The alternative to that is:

Jani needs to do a drm-intel-next Pull request towards drm-next. Then Sima and Dave picks that up.
Then Brost do a backmerge fixing the build issue in the merge commit. Once we fix it we let Mark know so the branch gets re-enabled in linux-next.

Quoted 8 lines
Quoted 2 lines

Let's revert and re-attempt after drm-intel-next and drm-xe-next are back in sync?

drm-tip is not broken, Marteen fixed it in drm-rerere.

How long would it take to do this sync? If this is less than 30days I think we can revert and wait, if that is okay for Lionel that is working in the feature that depends on that patch.

We are in -rc3. Jani might be sending a PR in 2 weeks from now. So, we might be in sync in 3 weeks. Worst case 30 days. But it can be speed up with the help of the maintainers I mentioned.

Lionel, what do you think?

Quoted 33 lines
Quoted 33 lines
Quoted 33 lines

Thank you

Quoted 25 lines · Mark Brown

Hi all,

After merging the drm-xe tree, today's linux-next build (KCONFIG_NAME)
failed like this:

/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c: In function 'xe_lrc_ctx_init':
/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c:1554:43: error:
implicit
declaration of function '_MASKED_BIT_ENABLE'; did you mean 'REG_MASKED_FIELD_ENABLE'? [-Wimplicit-function-declaration] 1554 |                 state_cache_perf_fix[2] = _MASKED_BIT_ENABLE(DISABLE_STATE_CACHE_PERF_FIX); |
^~~~~~~~~~~~~~~~~~
      |
REG_MASKED_FIELD_ENABLE

Caused by commit

  0e07b16371b6e (drm/xe: Allow per queue programming of COMMON_SLICE_CHICKEN3 bit13)

I have used the tree from next-20260310 instead.

#5 lore raw
Quoted 38 lines · Rodrigo Vivi
Quoted 37 lines · Jose
Quoted 26 lines · Rodrigo Vivi
Quoted 12 lines · Jose

Hi Rodrigo, can you help me here?

I think this issue was because
https://lore.kernel.org/all/49dc20448a12f3e03f5f8347540d167a281b8987.1772042022.git.jani.nikula@intel.com/
was merged in drm-intel-next.

If it was splitted into a i915 and a Xe KMD patches and merged each to
its own tree I think we would have avoided the issue. But I have not looked at that whole series to understand why that decision was made.

Quoted 3 lines

I don't know how to fix it, maybe rebase drm-xe-next on top of drm- intel-next and then a new commit fixing 0e07b16371b6e. Not sure what is the best option, can you help us here?

This explains why the patch was not applying cleanly. This is the reason why we should never ever edit the patch directly when merging.

If this is breaking the drm-tip build as well we should immediately revert the
patch. But I'm considering this anyway.

The alternative to that is:

Quoted 8 lines

Jani needs to do a drm-intel-next Pull request towards drm-next. Then Sima and Dave picks that up.
Then Brost do a backmerge fixing the build issue in the merge commit. Once we fix it we let Mark know so the branch gets re-enabled in linux-next.

Let's revert and re-attempt after drm-intel-next and drm-xe-next are back in sync?

drm-tip is not broken, Marteen fixed it in drm-rerere.

Quoted 8 lines
Quoted 3 lines

How long would it take to do this sync? If this is less than 30days I think we can revert and wait, if that is okay for Lionel that is working in the feature that depends on that patch.

We are in -rc3. Jani might be sending a PR in 2 weeks from now. So, we might be in sync in 3 weeks. Worst case 30 days. But it can be speed up with the help of the maintainers I mentioned.

Lionel, what do you think?

Is there no process to deal with kind of merge issues quickly?

If someone comes along and changes the bitmask macros again, do we have to wait another month after that?

-Lionel

Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines

Thank you

Quoted 25 lines · Mark Brown

Hi all,

After merging the drm-xe tree, today's linux-next build (KCONFIG_NAME)
failed like this:

/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c: In function 'xe_lrc_ctx_init':
/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c:1554:43: error:
implicit
declaration of function '_MASKED_BIT_ENABLE'; did you mean 'REG_MASKED_FIELD_ENABLE'? [-Wimplicit-function-declaration]
 1554 |                 state_cache_perf_fix[2] =
_MASKED_BIT_ENABLE(DISABLE_STATE_CACHE_PERF_FIX);
      |
^~~~~~~~~~~~~~~~~~
      |
REG_MASKED_FIELD_ENABLE

Caused by commit

  0e07b16371b6e (drm/xe: Allow per queue programming of
COMMON_SLICE_CHICKEN3 bit13)

I have used the tree from next-20260310 instead.

author maintainer
#6 lore raw
Quoted 6 lines · Lionel Landwerlin
Quoted 3 lines · Rodrigo Vivi

We are in -rc3. Jani might be sending a PR in 2 weeks from now. So, we might be in sync in 3 weeks. Worst case 30 days. But it can be speed up with the help of the maintainers I mentioned.

Quoted 6 lines
Quoted 1 line

Lionel, what do you think?

Is there no process to deal with kind of merge issues quickly?

If someone comes along and changes the bitmask macros again, do we have to wait another month after that?

The usual thing that normal trees would do would be to make a shared branch with just the API change in it that all the affected trees could merge and base their ongoing work off.

#7 lore raw
Quoted 9 lines · Mark Brown
Quoted 7 lines · Lionel Landwerlin
Quoted 5 lines · Rodrigo Vivi

We are in -rc3. Jani might be sending a PR in 2 weeks from now. So, we might be in sync in 3 weeks. Worst case 30 days. But it can be speed up with the help of the maintainers I mentioned.

Lionel, what do you think?

Quoted 8 lines
Quoted 4 lines

Is there no process to deal with kind of merge issues quickly?

If someone comes along and changes the bitmask macros again, do we have to wait another month after that?

The usual thing that normal trees would do would be to make a shared branch with just the API change in it that all the affected trees could merge and base their ongoing work off.

We can work with topic branch as well, but the backmerge is not a hard process for us. We should just not have rushed with this patch to start with, then we could had put the branch in sync.

My apologies for not identifying earlier that this was the case here when I first tried to apply the patch. I wrongly assumed the patch was not based on the right branch...

The pull-requests are already happening, so we should be back in sync soon, then you can re-enable the branch.

Sorry,
Rodrigo.

#8 lore raw
Quoted 35 lines · Rodrigo Vivi
Quoted 16 lines · Mark Brown
Quoted 7 lines · Lionel Landwerlin
Quoted 4 lines · Rodrigo Vivi

We are in -rc3. Jani might be sending a PR in 2 weeks from now. So, we might be in sync in 3 weeks. Worst case 30 days. But it can be speed up with the help of the maintainers I mentioned.

Quoted 7 lines
Quoted 1 line

Lionel, what do you think?

Is there no process to deal with kind of merge issues quickly?

If someone comes along and changes the bitmask macros again, do we have to
wait another month after that?

Quoted 5 lines

The usual thing that normal trees would do would be to make a shared
branch with just the API change in it that all the affected trees could
merge and base their ongoing work off.

We can work with topic branch as well, but the backmerge is not a hard process
for us. We should just not have rushed with this patch to start with, then
we could had put the branch in sync.

My apologies for not identifying earlier that this was the case here when I
first tried to apply the patch. I wrongly assumed the patch was not based
on the right branch...

Quoted 3 lines

The pull-requests are already happening, so we should be back in sync soon,
then you can re-enable the branch.

Couldn't we simply define the new macro name as an alias for the old one? We could then revert this change after the rebases are complete.

As Lionel pointed out, this macro mask is widely used within the Xe KMD driver.
Without this bridge, any developer working on a patch using that mask would be forced to delay their merge for several weeks.

Quoted 6 lines

Sorry,
Rodrigo.

author maintainer
#9 lore raw
In reply to Rodrigo Vivi
Quoted 9 lines · Rodrigo Vivi
Quoted 3 lines · Mark Brown

The usual thing that normal trees would do would be to make a shared branch with just the API change in it that all the affected trees could merge and base their ongoing work off.

We can work with topic branch as well, but the backmerge is not a hard process for us. We should just not have rushed with this patch to start with, then we could had put the branch in sync.

That also works.

Quoted 2 lines

The pull-requests are already happening, so we should be back in sync soon, then you can re-enable the branch.

To be clear when there's a build failure I don't remove branches, I merge whatever the last version that worked was. This means that every day the merge has to try the build, see that it failed, then I have to tell it to merge the old version, watch that get retried and then carry on with the merge.

#10 lore raw
In reply to Lionel Landwerlin
Quoted 46 lines · Lionel Landwerlin
Quoted 45 lines · Rodrigo Vivi
Quoted 33 lines · Jose
Quoted 32 lines · Rodrigo Vivi
Quoted 12 lines · Jose

Hi Rodrigo, can you help me here?

I think this issue was because
https://lore.kernel.org/all/49dc20448a12f3e03f5f8347540d167a281b8987.1772042022.git.jani.nikula@intel.com/
was merged in drm-intel-next.

If it was splitted into a i915 and a Xe KMD patches and merged each to
its own tree I think we would have avoided the issue. But I have not looked at that whole series to understand why that decision was made.

Quoted 3 lines

I don't know how to fix it, maybe rebase drm-xe-next on top of drm- intel-next and then a new commit fixing 0e07b16371b6e. Not sure what is the best option, can you help us here?

This explains why the patch was not applying cleanly. This is the reason why we should never ever edit the patch directly when merging.

If this is breaking the drm-tip build as well we should immediately revert the
patch. But I'm considering this anyway.

The alternative to that is:

Jani needs to do a drm-intel-next Pull request towards drm-next. Then Sima and Dave picks that up.
Then Brost do a backmerge fixing the build issue in the merge commit. Once we fix it we let Mark know so the branch gets re-enabled in linux-next.

Quoted 7 lines
Quoted 2 lines

Let's revert and re-attempt after drm-intel-next and drm-xe-next are back in sync?

drm-tip is not broken, Marteen fixed it in drm-rerere.

How long would it take to do this sync? If this is less than 30days I think we can revert and wait, if that is okay for Lionel that is working in the feature that depends on that patch.

We are in -rc3. Jani might be sending a PR in 2 weeks from now. So, we might be in sync in 3 weeks. Worst case 30 days. But it can be speed up with the help of the maintainers I mentioned.

Quoted 7 lines
Quoted 1 line

Lionel, what do you think?

Is there no process to deal with kind of merge issues quickly?

If someone comes along and changes the bitmask macros again, do we have to wait another month after that?

we should not had edited the patch while merging. That was the problem. It should never had happen. It should never happen again!

Quoted 38 lines

-Lionel

Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines

Thank you

Quoted 25 lines · Mark Brown

Hi all,

After merging the drm-xe tree, today's linux-next build (KCONFIG_NAME)
failed like this:

/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c: In function 'xe_lrc_ctx_init':
/tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c:1554:43: error:
implicit
declaration of function '_MASKED_BIT_ENABLE'; did you mean 'REG_MASKED_FIELD_ENABLE'? [-Wimplicit-function-declaration]
 1554 |                 state_cache_perf_fix[2] =
_MASKED_BIT_ENABLE(DISABLE_STATE_CACHE_PERF_FIX);
      |
^~~~~~~~~~~~~~~~~~
      |
REG_MASKED_FIELD_ENABLE

Caused by commit

  0e07b16371b6e (drm/xe: Allow per queue programming of
COMMON_SLICE_CHICKEN3 bit13)

I have used the tree from next-20260310 instead.

#11 lore raw
In reply to Lionel Landwerlin
Quoted 1 line · Lionel Landwerlin

Is there no process to deal with kind of merge issues quickly?

For us the main part of the process is: If the patch doesn't build after applying, talk to the maintainers to get the merges and backmerges going *before* pushing, *not* after.

Similar to linux-next, drm-tip is the early signal there's a conflict. If you develop on top of drm-tip, you'll find out about the conflicts when applying to the individual branches.

I'll try to get a drm-intel-next pull request going today, or Monday at the latest. Lots of changelog to write. Then it's drm-intel-next -> drm-next -> drm-xe-next merges/backmerges that need to happen.

BR,
Jani.

Signature · 1 line
Jani Nikula, Intel
author maintainer
#12 lore raw
Quoted 7 lines · Jani Nikula
Quoted 1 line · Lionel Landwerlin

Is there no process to deal with kind of merge issues quickly?

For us the main part of the process is: If the patch doesn't build after applying, talk to the maintainers to get the merges and backmerges going *before* pushing, *not* after.

Quoted 7 lines

Similar to linux-next, drm-tip is the early signal there's a conflict. If you develop on top of drm-tip, you'll find out about the conflicts when applying to the individual branches.

I'll try to get a drm-intel-next pull request going today, or Monday at the latest. Lots of changelog to write. Then it's drm-intel-next -> drm-next -> drm-xe-next merges/backmerges that need to happen.

Any news on this? We now have issues with the main drm tree interacting with drm-intel due to this change.

#13 lore raw
Quoted 12 lines · Mark Brown
Quoted 10 lines · Jani Nikula
Quoted 1 line · Lionel Landwerlin

Is there no process to deal with kind of merge issues quickly?

For us the main part of the process is: If the patch doesn't build after applying, talk to the maintainers to get the merges and backmerges going *before* pushing, *not* after.

Similar to linux-next, drm-tip is the early signal there's a conflict. If you develop on top of drm-tip, you'll find out about the conflicts when applying to the individual branches.

Quoted 6 lines
Quoted 3 lines

I'll try to get a drm-intel-next pull request going today, or Monday at the latest. Lots of changelog to write. Then it's drm-intel-next -> drm-next -> drm-xe-next merges/backmerges that need to happen.

Any news on this? We now have issues with the main drm tree interacting with drm-intel due to this change.

Matthew, please do the drm-intel -> drm-xe-next backmerge, and ensure the merge commit builds.

BR,
Jani.

Signature · 1 line
Jani Nikula, Intel
#14 lore raw
Quoted 17 lines · Jani Nikula
Quoted 16 lines · Mark Brown
Quoted 14 lines · Jani Nikula
Quoted 1 line · Lionel Landwerlin

Is there no process to deal with kind of merge issues quickly?

For us the main part of the process is: If the patch doesn't build after applying, talk to the maintainers to get the merges and backmerges going *before* pushing, *not* after.

Similar to linux-next, drm-tip is the early signal there's a conflict. If you develop on top of drm-tip, you'll find out about the conflicts when applying to the individual branches.

I'll try to get a drm-intel-next pull request going today, or Monday at the latest. Lots of changelog to write. Then it's drm-intel-next -> drm-next -> drm-xe-next merges/backmerges that need to happen.

Quoted 5 lines
Quoted 2 lines

Any news on this? We now have issues with the main drm tree interacting with drm-intel due to this change.

Matthew, please do the drm-intel -> drm-xe-next backmerge, and ensure the merge commit builds.

Argh, obviously drm-next -> drm-xe-next, *not* cross-merges between Intel trees. *facepalm*.

Signature · 1 line
Jani Nikula, Intel