Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi Stephen,
On Wed, Nov 22, 2023 at 1:29 AM Stephen Rothwell wrote:
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/accel/ivpu/ivpu_hw_37xx.c
>
> between commit:
>
> 3f7c0634926d ("accel/ivpu/37xx: Fix hangs related to MMIO reset")
>
> from the drm-misc-fixes tree and commits:
>
> 3de6d9597892 ("accel/ivpu: Pass D0i3 residency time to the VPU firmware")
> cc19fedab8bd ("accel/ivpu/37xx: Print warning when VPUIP is not idle during
> power down")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks for your resolution!
> --- a/drivers/accel/ivpu/ivpu_hw_37xx.c
> +++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
> @@@ -720,14 -731,19 +733,14 @@@ static int ivpu_hw_37xx_power_down(stru
> {
> int ret = 0;
>
> - if (!ivpu_hw_37xx_is_idle(vdev))
> - ivpu_warn(vdev, "VPU not idle during power down\n");
> + ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
>
> - if (ivpu_hw_37xx_reset(vdev)) {
> - ivpu_err(vdev, "Failed to reset VPU\n");
> - ret = -EIO;
> + if (!ivpu_hw_37xx_is_idle(vdev)) {
> + ivpu_warn(vdev, "VPU not idle during power down\n");
> + if (ivpu_hw_37xx_reset(vdev))
> + ivpu_warn(vdev, "Failed to reset the VPU\n");
> }
>
> - if (ivpu_pll_disable(vdev)) {
> - ivpu_err(vdev, "Failed to disable PLL\n");
> - ret = -EIO;
> - }
> -
> if (ivpu_hw_37xx_d0i3_enable(vdev)) {
> ivpu_err(vdev, "Failed to enter D0I3\n");
> ret = -EIO;
I've just run into the same conflict, and I think you lost the split
into two if-statements in the last hunk of commit 3f7c0634926d
("accel/ivpu/37xx: Fix hangs related to MMIO reset")?
My resolution is:
--- a/drivers/accel/ivpu/ivpu_hw_37xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
@@@ -720,11 -731,16 +733,13 @@@ static int ivpu_hw_37xx_power_down(stru
{
int ret = 0;
+ ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
+
- if (!ivpu_hw_37xx_is_idle(vdev)) {
+ if (!ivpu_hw_37xx_is_idle(vdev))
ivpu_warn(vdev, "VPU not idle during power down\n");
- if (ivpu_hw_37xx_reset(vdev))
- ivpu_warn(vdev, "Failed to reset the VPU\n");
- }
- if (ivpu_pll_disable(vdev)) {
- ivpu_err(vdev, "Failed to disable PLL\n");
+ if (ivpu_hw_37xx_reset(vdev)) {
+ ivpu_err(vdev, "Failed to reset VPU\n");
ret = -EIO;
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/accel/ivpu/ivpu_hw_37xx.c
between commit:
3f7c0634926d ("accel/ivpu/37xx: Fix hangs related to MMIO reset")
from the drm-misc-fixes tree and commits:
3de6d9597892 ("accel/ivpu: Pass D0i3 residency time to the VPU firmware")
cc19fedab8bd ("accel/ivpu/37xx: Print warning when VPUIP is not idle during
power down")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/accel/ivpu/ivpu_hw_37xx.c
index 4ccf1994b97a,4ab1f14cf360..
--- a/drivers/accel/ivpu/ivpu_hw_37xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
@@@ -720,14 -731,19 +733,14 @@@ static int ivpu_hw_37xx_power_down(stru
{
int ret = 0;
- if (!ivpu_hw_37xx_is_idle(vdev))
- ivpu_warn(vdev, "VPU not idle during power down\n");
+ ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
- if (ivpu_hw_37xx_reset(vdev)) {
- ivpu_err(vdev, "Failed to reset VPU\n");
- ret = -EIO;
+ if (!ivpu_hw_37xx_is_idle(vdev)) {
+ ivpu_warn(vdev, "VPU not idle during power down\n");
+ if (ivpu_hw_37xx_reset(vdev))
+ ivpu_warn(vdev, "Failed to reset the VPU\n");
}
- if (ivpu_pll_disable(vdev)) {
- ivpu_err(vdev, "Failed to disable PLL\n");
- ret = -EIO;
- }
-
if (ivpu_hw_37xx_d0i3_enable(vdev)) {
ivpu_err(vdev, "Failed to enter D0I3\n");
ret = -EIO;
pgp5vGMhuDv9k.pgp
Description: OpenPGP digital signature
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/accel/ivpu/ivpu_fw.c
between commit:
645d694559ca ("accel/ivpu: Use cached buffers for FW loading")
from the drm-misc-fixes tree and commit:
53d98420f5f9 ("accel/ivpu: Move ivpu_fw_load() to ivpu_fw_init()")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/accel/ivpu/ivpu_fw.c
index 0191cf8e5964,d57e103aae1c..
--- a/drivers/accel/ivpu/ivpu_fw.c
+++ b/drivers/accel/ivpu/ivpu_fw.c
@@@ -331,9 -332,7 +333,7 @@@ void ivpu_fw_load(struct ivpu_device *v
memset(start, 0, size);
}
- wmb(); /* Flush WC buffers after writing fw->mem */
+ clflush_cache_range(fw->mem->kvaddr, fw->mem->base.size);
-
- return 0;
}
static void ivpu_fw_boot_params_print(struct ivpu_device *vdev, struct
vpu_boot_params *boot_params)
pgpN5s1NWNBZY.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
On Tue, 27 Jun 2023 11:54:32 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> include/drm/gpu_scheduler.h
>
> between commit:
>
> db8b4968a8d0 ("drm/sched: Call drm_sched_fence_set_parent() from
> drm_sched_fence_scheduled()")
>
> from the drm-misc-fixes tree and commit:
>
> 539f9ee4b52a ("drm/scheduler: properly forward fence errors")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc include/drm/gpu_scheduler.h
> index b29e347b10a9,e95b4837e5a3..
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@@ -581,16 -581,18 +581,17 @@@ void drm_sched_entity_push_job(struct d
> void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
> enum drm_sched_priority priority);
> bool drm_sched_entity_is_ready(struct drm_sched_entity *entity);
> + int drm_sched_entity_error(struct drm_sched_entity *entity);
>
> -void drm_sched_fence_set_parent(struct drm_sched_fence *s_fence,
> -struct dma_fence *fence);
> struct drm_sched_fence *drm_sched_fence_alloc(
> struct drm_sched_entity *s_entity, void *owner);
> void drm_sched_fence_init(struct drm_sched_fence *fence,
> struct drm_sched_entity *entity);
> void drm_sched_fence_free(struct drm_sched_fence *fence);
>
> -void drm_sched_fence_scheduled(struct drm_sched_fence *fence);
> +void drm_sched_fence_scheduled(struct drm_sched_fence *fence,
> + struct dma_fence *parent);
> - void drm_sched_fence_finished(struct drm_sched_fence *fence);
> + void drm_sched_fence_finished(struct drm_sched_fence *fence, int result);
>
> unsigned long drm_sched_suspend_timeout(struct drm_gpu_scheduler *sched);
> void drm_sched_resume_timeout(struct drm_gpu_scheduler *sched,
This is now a conflict between the drm-misc-fixes tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgptLYAKlrJOf.pgp
Description: OpenPGP digital signature
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
include/drm/gpu_scheduler.h
between commit:
db8b4968a8d0 ("drm/sched: Call drm_sched_fence_set_parent() from
drm_sched_fence_scheduled()")
from the drm-misc-fixes tree and commit:
539f9ee4b52a ("drm/scheduler: properly forward fence errors")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/drm/gpu_scheduler.h
index b29e347b10a9,e95b4837e5a3..
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@@ -581,16 -581,18 +581,17 @@@ void drm_sched_entity_push_job(struct d
void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
enum drm_sched_priority priority);
bool drm_sched_entity_is_ready(struct drm_sched_entity *entity);
+ int drm_sched_entity_error(struct drm_sched_entity *entity);
-void drm_sched_fence_set_parent(struct drm_sched_fence *s_fence,
- struct dma_fence *fence);
struct drm_sched_fence *drm_sched_fence_alloc(
struct drm_sched_entity *s_entity, void *owner);
void drm_sched_fence_init(struct drm_sched_fence *fence,
struct drm_sched_entity *entity);
void drm_sched_fence_free(struct drm_sched_fence *fence);
-void drm_sched_fence_scheduled(struct drm_sched_fence *fence);
+void drm_sched_fence_scheduled(struct drm_sched_fence *fence,
+ struct dma_fence *parent);
- void drm_sched_fence_finished(struct drm_sched_fence *fence);
+ void drm_sched_fence_finished(struct drm_sched_fence *fence, int result);
unsigned long drm_sched_suspend_timeout(struct drm_gpu_scheduler *sched);
void drm_sched_resume_timeout(struct drm_gpu_scheduler *sched,
pgpHTI_fnBgSK.pgp
Description: OpenPGP digital signature
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
between commit:
b09d6acba1d9 ("drm/amdgpu: handle gang submit before VMID")
from the drm-misc-fixes tree and commits:
c5093cddf56b ("drm/amdgpu: drop the fence argument from amdgpu_vmid_grab")
940ca22b7ea9 ("drm/amdgpu: drop amdgpu_sync from amdgpu_vmid_grab v2")
1b2d5eda5ad7 ("drm/amdgpu: move explicit sync check into the CS")
1728baa7e4e6 ("drm/amdgpu: use scheduler dependencies for CS")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index abb99cff8b4b,032651a655f0..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@@ -243,30 -242,18 +242,18 @@@ amdgpu_job_prepare_job(struct drm_sched
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_entity->rq->sched);
struct amdgpu_job *job = to_amdgpu_job(sched_job);
- struct amdgpu_vm *vm = job->vm;
- struct dma_fence *fence;
+ struct dma_fence *fence = NULL;
int r;
- fence = amdgpu_sync_get_fence(>sync);
- if (fence && drm_sched_dependency_optimized(fence, s_entity)) {
- r = amdgpu_sync_fence(>sched_sync, fence);
- if (r)
- DRM_ERROR("Error adding fence (%d)\n", r);
- }
-
- if (!fence && job->gang_submit)
++ if (job->gang_submit)
+ fence = amdgpu_device_switch_gang(ring->adev, job->gang_submit);
+
- while (fence == NULL && vm && !job->vmid) {
- r = amdgpu_vmid_grab(vm, ring, >sync,
->base.s_fence->finished,
-job);
+ while (!fence && job->vm && !job->vmid) {
+ r = amdgpu_vmid_grab(job->vm, ring, job, );
if (r)
DRM_ERROR("Error getting VM ID (%d)\n", r);
-
- fence = amdgpu_sync_get_fence(>sync);
}
- if (!fence && job->gang_submit)
- fence = amdgpu_device_switch_gang(ring->adev, job->gang_submit);
-
return fence;
}
pgp3SIRXZfmVg.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi Dave, On Wed, 27 Jul 2022 13:24:45 +1000 Dave Airlie wrote: > > My assumption is I fix this on sending my -next tree to Linus with a > resolution I create at that time? > > Is there another option, we have this fixed in out drm-tip tree already. Sounds good, no problem. -- Cheers, Stephen Rothwell pgpocrGW6ZOGp.pgp Description: OpenPGP digital signature
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
On Wed, 27 Jul 2022 at 12:55, Stephen Rothwell wrote:
>
> Hi all,
>
> On Mon, 18 Jul 2022 09:44:53 +1000 Stephen Rothwell
> wrote:
> >
> > On Mon, 11 Jul 2022 10:05:45 +0200 Christian König
> > wrote:
> > >
> > > Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> > > >
> > > > Today's linux-next merge of the drm tree got a conflict in:
> > > >
> > > >drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > > >
> > > > between commit:
> > > >
> > > >925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
> > > >
> > > > from the drm-misc-fixes tree and commit:
> > > >
> > > >5e3f1e7729ec ("drm/amdgpu: fix start calculation in
> > > > amdgpu_vram_mgr_new")
> > > >
> > > > from the drm tree.
> > > >
> > > > This is a mess :-( I have just reverted the above revert before mergin
> > > > the drm tree for today, please fix it up.
> > >
> > > Sorry for the noise, the patch "5e3f1e7729ec ("drm/amdgpu: fix start
> > > calculation in amdgpu_vram_mgr_new")" and another one is going to be
> > > reverted from the drm tree as well.
> > >
> > > It's just that -fixes patches where faster than -next patches.
> >
> > Here we are a week later, -rc7 has been released and as far as I can
> > tell (though I may have missed it), this is still a problem :-(
> >
> > I am still reverting 925b6e59138c (which is now in Linus' tree).
>
> Ping?
My assumption is I fix this on sending my -next tree to Linus with a
resolution I create at that time?
Is there another option, we have this fixed in out drm-tip tree already.
Dave.
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
On Mon, 18 Jul 2022 09:44:53 +1000 Stephen Rothwell
wrote:
>
> On Mon, 11 Jul 2022 10:05:45 +0200 Christian König
> wrote:
> >
> > Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> > >
> > > Today's linux-next merge of the drm tree got a conflict in:
> > >
> > >drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > >
> > > between commit:
> > >
> > >925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
> > >
> > > from the drm-misc-fixes tree and commit:
> > >
> > >5e3f1e7729ec ("drm/amdgpu: fix start calculation in
> > > amdgpu_vram_mgr_new")
> > >
> > > from the drm tree.
> > >
> > > This is a mess :-( I have just reverted the above revert before mergin
> > > the drm tree for today, please fix it up.
> >
> > Sorry for the noise, the patch "5e3f1e7729ec ("drm/amdgpu: fix start
> > calculation in amdgpu_vram_mgr_new")" and another one is going to be
> > reverted from the drm tree as well.
> >
> > It's just that -fixes patches where faster than -next patches.
>
> Here we are a week later, -rc7 has been released and as far as I can
> tell (though I may have missed it), this is still a problem :-(
>
> I am still reverting 925b6e59138c (which is now in Linus' tree).
Ping?
--
Cheers,
Stephen Rothwell
pgpBVQfsxVZp9.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi Stephen,
On Mon, Jul 18, 2022 at 1:49 AM Stephen Rothwell wrote:
> On Mon, 11 Jul 2022 10:05:45 +0200 Christian König
> wrote:
> > Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> > >
> > > Today's linux-next merge of the drm tree got a conflict in:
> > >
> > >drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > >
> > > between commit:
> > >
> > >925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
> > >
> > > from the drm-misc-fixes tree and commit:
> > >
> > >5e3f1e7729ec ("drm/amdgpu: fix start calculation in
> > > amdgpu_vram_mgr_new")
> > >
> > > from the drm tree.
> > >
> > > This is a mess :-( I have just reverted the above revert before mergin
> > > the drm tree for today, please fix it up.
> >
> > Sorry for the noise, the patch "5e3f1e7729ec ("drm/amdgpu: fix start
> > calculation in amdgpu_vram_mgr_new")" and another one is going to be
> > reverted from the drm tree as well.
> >
> > It's just that -fixes patches where faster than -next patches.
>
> Here we are a week later, -rc7 has been released and as far as I can
> tell (though I may have missed it), this is still a problem :-(
>
> I am still reverting 925b6e59138c (which is now in Linus' tree).
Thanks for the hint! After reverting that commit, drm-next (sort of[1])
merges cleanly into upstream again.
[1] There's still a small conflict due to the removal of
force_dpms_off, cfr. the difference between commits
3283c83eb6fcfbda and cc79950bf0904f58 ("drm/amd/display:
Ensure valid event timestamp for cursor-only commits") in
v5.19-rc7 resp. drm-next.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
On Mon, 11 Jul 2022 10:05:45 +0200 Christian König
wrote:
>
> Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> >
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> >drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> >
> > between commit:
> >
> >925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
> >
> > from the drm-misc-fixes tree and commit:
> >
> >5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
> >
> > from the drm tree.
> >
> > This is a mess :-( I have just reverted the above revert before mergin
> > the drm tree for today, please fix it up.
>
> Sorry for the noise, the patch "5e3f1e7729ec ("drm/amdgpu: fix start
> calculation in amdgpu_vram_mgr_new")" and another one is going to be
> reverted from the drm tree as well.
>
> It's just that -fixes patches where faster than -next patches.
Here we are a week later, -rc7 has been released and as far as I can
tell (though I may have missed it), this is still a problem :-(
I am still reverting 925b6e59138c (which is now in Linus' tree).
--
Cheers,
Stephen Rothwell
pgpd3jjPiQXon.pgp
Description: OpenPGP digital signature
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
between commit:
925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
from the drm-misc-fixes tree and commit:
5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
from the drm tree.
This is a mess :-( I have just reverted the above revert before mergin
the drm tree for today, please fix it up.
--
Cheers,
Stephen Rothwell
pgpc8y60in8al.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
On Fri, 18 Mar 2022 11:55:44 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/bridge/Kconfig
>
> between commit:
>
> 3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on
> DRM_KMS_HELPERS")
>
> from the drm-misc-fixes tree and commit:
>
> 803abfd8dda5 ("drm: bridge: fix unmet dependency on DRM_KMS_HELPER for
> DRM_PANEL_BRIDGE")
>
> from the drm tree.
>
> I fixed it up (I just used the latter) and can carry the fix as
But that failed during configuration, so I went back and used the
former change.
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgptFeyVzf484.pgp
Description: OpenPGP digital signature
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/bridge/Kconfig
between commit:
3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS")
from the drm-misc-fixes tree and commit:
803abfd8dda5 ("drm: bridge: fix unmet dependency on DRM_KMS_HELPER for
DRM_PANEL_BRIDGE")
from the drm tree.
I fixed it up (I just used the latter) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpkByDo038dK.pgp
Description: OpenPGP digital signature
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/nouveau/nouveau_fence.c
between commit:
67f74302f45d ("drm/nouveau: wait for the exclusive fence after the shared
ones v2")
from the drm-misc-fixes tree and commit:
40298cb45071 ("drm/nouveau: use the new iterator in nouveau_fence_sync")
from the drm tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpm9wv_3iwrC.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi Maxime,
On Tue, 30 Nov 2021 09:58:31 +0100 Maxime Ripard wrote:
>
> Unfortunately the merge resolution isn't entirely correct :/
>
> There's multiple conflicts between those two branches on that file, but
> things went wrong between 16e101051f32 and 0c980a006d3f
>
> The first one changes the logic a bit for the clk_set_min_rate argument,
> and the second moves the clk_set_min_rate around.
>
> However, the merge resolution reintroduced the initial clk_set_min_rate
> call line (line 373), without changing the logic of the proper call site
> (line 396).
>
> This is the patch to fix the resolution:
>
> -- >8 --
> --- a/drivers/gpu/drm/vc4/vc4_kms.c 2021-11-30 08:56:28.748524275 +0100
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c 2021-11-29 15:46:11.692151678 +0100
> @@ -365,14 +365,6 @@
> vc4_hvs_mask_underrun(dev, vc4_crtc_state->assigned_channel);
> }
>
> - if (vc4->hvs->hvs5) {
> - unsigned long core_rate = max_t(unsigned long,
> - 5,
> - new_hvs_state->core_clock_rate);
> -
> - clk_set_min_rate(hvs->core_clk, core_rate);
> - }
> -
> for (channel = 0; channel < HVS_NUM_CHANNELS; channel++) {
> struct drm_crtc_commit *commit;
> int ret;
> @@ -392,8 +384,13 @@
> old_hvs_state->fifo_state[channel].pending_commit = NULL;
> }
>
> - if (vc4->hvs->hvs5)
> - clk_set_min_rate(hvs->core_clk, 5);
> + if (vc4->hvs->hvs5) {
> + unsigned long core_rate = max_t(unsigned long,
> + 5,
> + new_hvs_state->core_clock_rate);
> +
> + clk_set_min_rate(hvs->core_clk, core_rate);
> + }
>
> drm_atomic_helper_commit_modeset_disables(dev, state);
> -- >8 --
Thanks, I have fixed that up in my resolution.
--
Cheers,
Stephen Rothwell
pgp0t_CrocJv_.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi Stephen,
On Tue, Nov 30, 2021 at 10:33:53AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/vc4/vc4_kms.c
>
> between commits:
>
> f927767978d2 ("drm/vc4: kms: Fix return code check")
> d354699e2292 ("drm/vc4: kms: Don't duplicate pending commit")
>
> from the drm-misc-fixes tree and commit:
>
> 16e101051f32 ("drm/vc4: Increase the core clock based on HVS load")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Unfortunately the merge resolution isn't entirely correct :/
There's multiple conflicts between those two branches on that file, but
things went wrong between 16e101051f32 and 0c980a006d3f
The first one changes the logic a bit for the clk_set_min_rate argument,
and the second moves the clk_set_min_rate around.
However, the merge resolution reintroduced the initial clk_set_min_rate
call line (line 373), without changing the logic of the proper call site
(line 396).
This is the patch to fix the resolution:
-- >8 --
--- a/drivers/gpu/drm/vc4/vc4_kms.c 2021-11-30 08:56:28.748524275 +0100
+++ b/drivers/gpu/drm/vc4/vc4_kms.c 2021-11-29 15:46:11.692151678 +0100
@@ -365,14 +365,6 @@
vc4_hvs_mask_underrun(dev, vc4_crtc_state->assigned_channel);
}
- if (vc4->hvs->hvs5) {
- unsigned long core_rate = max_t(unsigned long,
- 5,
- new_hvs_state->core_clock_rate);
-
- clk_set_min_rate(hvs->core_clk, core_rate);
- }
-
for (channel = 0; channel < HVS_NUM_CHANNELS; channel++) {
struct drm_crtc_commit *commit;
int ret;
@@ -392,8 +384,13 @@
old_hvs_state->fifo_state[channel].pending_commit = NULL;
}
- if (vc4->hvs->hvs5)
- clk_set_min_rate(hvs->core_clk, 5);
+ if (vc4->hvs->hvs5) {
+ unsigned long core_rate = max_t(unsigned long,
+ 5,
+ new_hvs_state->core_clock_rate);
+
+ clk_set_min_rate(hvs->core_clk, core_rate);
+ }
drm_atomic_helper_commit_modeset_disables(dev, state);
-- >8 --
I'm wondering though, do you have access to the drm-rerere tree? I've
fixed up the merge yesterday to deal with this conflict and the conflict
resolution should be stored there already.
Maxime
signature.asc
Description: PGP signature
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/vc4/vc4_kms.c
between commits:
f927767978d2 ("drm/vc4: kms: Fix return code check")
d354699e2292 ("drm/vc4: kms: Don't duplicate pending commit")
from the drm-misc-fixes tree and commit:
16e101051f32 ("drm/vc4: Increase the core clock based on HVS load")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/vc4/vc4_kms.c
index b61792d2aa65,79d4d9dd1394..
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@@ -337,12 -340,21 +340,21 @@@ static void vc4_atomic_commit_tail(stru
struct drm_device *dev = state->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_hvs *hvs = vc4->hvs;
- struct drm_crtc_state *old_crtc_state;
struct drm_crtc_state *new_crtc_state;
+ struct vc4_hvs_state *new_hvs_state;
struct drm_crtc *crtc;
struct vc4_hvs_state *old_hvs_state;
+ unsigned int channel;
int i;
+ old_hvs_state = vc4_hvs_get_old_global_state(state);
- if (WARN_ON(!old_hvs_state))
++ if (WARN_ON(IS_ERR(old_hvs_state)))
+ return;
+
+ new_hvs_state = vc4_hvs_get_new_global_state(state);
- if (WARN_ON(!new_hvs_state))
++ if (WARN_ON(IS_ERR(new_hvs_state)))
+ return;
+
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
struct vc4_crtc_state *vc4_crtc_state;
@@@ -353,32 -365,31 +365,36 @@@
vc4_hvs_mask_underrun(dev, vc4_crtc_state->assigned_channel);
}
- old_hvs_state = vc4_hvs_get_old_global_state(state);
- if (IS_ERR(old_hvs_state))
- return;
+ if (vc4->hvs->hvs5) {
+ unsigned long core_rate = max_t(unsigned long,
+ 5,
+ new_hvs_state->core_clock_rate);
+
+ clk_set_min_rate(hvs->core_clk, core_rate);
+ }
- for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
- struct vc4_crtc_state *vc4_crtc_state =
- to_vc4_crtc_state(old_crtc_state);
- unsigned int channel = vc4_crtc_state->assigned_channel;
+ for (channel = 0; channel < HVS_NUM_CHANNELS; channel++) {
+ struct drm_crtc_commit *commit;
int ret;
- if (channel == VC4_HVS_CHANNEL_DISABLED)
+ if (!old_hvs_state->fifo_state[channel].in_use)
continue;
- if (!old_hvs_state->fifo_state[channel].in_use)
+ commit = old_hvs_state->fifo_state[channel].pending_commit;
+ if (!commit)
continue;
- ret =
drm_crtc_commit_wait(old_hvs_state->fifo_state[channel].pending_commit);
+ ret = drm_crtc_commit_wait(commit);
if (ret)
drm_err(dev, "Timed out waiting for commit\n");
+
+ drm_crtc_commit_put(commit);
+ old_hvs_state->fifo_state[channel].pending_commit = NULL;
}
+ if (vc4->hvs->hvs5)
+ clk_set_min_rate(hvs->core_clk, 5);
+
drm_atomic_helper_commit_modeset_disables(dev, state);
vc4_ctm_commit(vc4, state);
@@@ -667,11 -673,19 +678,13 @@@ vc4_hvs_channels_duplicate_state(struc
__drm_atomic_helper_private_obj_duplicate_state(obj, >base);
-
for (i = 0; i < HVS_NUM_CHANNELS; i++) {
state->fifo_state[i].in_use = old_state->fifo_state[i].in_use;
+ state->fifo_state[i].fifo_load =
old_state->fifo_state[i].fifo_load;
-
- if (!old_state->fifo_state[i].pending_commit)
- continue;
-
- state->fifo_state[i].pending_commit =
-
drm_crtc_commit_get(old_state->fifo_state[i].pending_commit);
}
+ state->core_clock_rate = old_state->core_clock_rate;
+
return >base;
}
@@@ -826,6 -840,76 +839,76 @@@ static int vc4_pv_muxing_atomic_check(s
return 0;
}
+ static int
+ vc4_core_clock_atomic_check(struct drm_atomic_state *state)
+ {
+ struct vc4_dev *vc4 = to_vc4_dev(state->dev);
+ struct drm_private_state *priv_state;
+ struct vc4_hvs_state *hvs_new_state;
+ struct vc4_load_tracker_state *load_state;
+ struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct drm_crtc *crtc;
+ unsigned int num_outputs;
+ unsigned long pixel_rate;
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/drm_panel_orientation_quirks.c
between commit:
def0c3697287 ("drm: panel-orientation-quirks: Add quirk for Aya Neo 2021")
from the drm-misc-fixes tree and commits:
072e70d52372 ("drm: panel-orientation-quirks: Add quirk for the Chuwi Hi10
Pro")
63a4881572d7 ("drm: panel-orientation-quirks: Add quirk for the Chuwi HiBook")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/drm_panel_orientation_quirks.c
index 30c17a76f49a,62e8ccc7ab9c..
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@@ -134,12 -140,20 +140,26 @@@ static const struct dmi_system_id orien
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T103HAF"),
},
.driver_data = (void *)_rightside_up,
+ }, {/* AYA NEO 2021 */
+ .matches = {
+DMI_EXACT_MATCH(DMI_SYS_VENDOR, "AYADEVICE"),
+DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "AYA NEO 2021"),
+ },
+ .driver_data = (void *)_rightside_up,
+ }, {/* Chuwi HiBook (CWI514) */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ DMI_MATCH(DMI_BOARD_NAME, "Cherry Trail CR"),
+ /* Above matches are too generic, add bios-date match */
+ DMI_MATCH(DMI_BIOS_DATE, "05/07/2016"),
+ },
+ .driver_data = (void *)_rightside_up,
+ }, {/* Chuwi Hi10 Pro (CWI529) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Hi10 pro tablet"),
+ },
+ .driver_data = (void *)_rightside_up,
}, {/* GPD MicroPC (generic strings, also match on bios date) */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
pgpHKzPwgIQ_x.pgp
Description: OpenPGP digital signature
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/vc4/vc4_hdmi.c
between commit:
9984d6664ce9 ("drm/vc4: hdmi: Make sure the controller is powered in detect")
from the drm-misc-fixes tree and commit:
6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/vc4/vc4_hdmi.c
index 8106b5634fe1,3c4cc133e3df..
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@@ -159,12 -166,9 +166,11 @@@ vc4_hdmi_connector_detect(struct drm_co
struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
bool connected = false;
+ WARN_ON(pm_runtime_resume_and_get(_hdmi->pdev->dev));
+
- if (vc4_hdmi->hpd_gpio) {
- if (gpio_get_value_cansleep(vc4_hdmi->hpd_gpio) ^
- vc4_hdmi->hpd_active_low)
- connected = true;
+ if (vc4_hdmi->hpd_gpio &&
+ gpiod_get_value_cansleep(vc4_hdmi->hpd_gpio)) {
+ connected = true;
} else if (drm_probe_ddc(vc4_hdmi->ddc)) {
connected = true;
} else if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED) {
@@@ -787,16 -942,26 +945,18 @@@ static void vc4_hdmi_encoder_pre_crtc_c
return;
}
- ret = clk_prepare_enable(vc4_hdmi->hsm_clock);
- if (ret) {
- DRM_ERROR("Failed to turn on HSM clock: %d\n", ret);
- clk_disable_unprepare(vc4_hdmi->pixel_clock);
- return;
- }
-
vc4_hdmi_cec_update_clk_div(vc4_hdmi);
- /*
-* FIXME: When the pixel freq is 594MHz (4k60), this needs to be setup
-* at 300MHz.
-*/
- ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock,
- (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 :
7500));
+ if (pixel_rate > 29700)
+ bvb_rate = 3;
+ else if (pixel_rate > 14850)
+ bvb_rate = 15000;
+ else
+ bvb_rate = 7500;
+
+ ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock, bvb_rate);
if (ret) {
DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
- clk_disable_unprepare(vc4_hdmi->hsm_clock);
clk_disable_unprepare(vc4_hdmi->pixel_clock);
return;
}
pgpfLBcSG98TN.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/vc4/vc4_plane.c
between commit:
35d65ab3fdba ("drm/vc4: plane: Remove redundant assignment")
from the drm-misc-fixes tree and commit:
5ddb0bd4ddc3 ("drm/atomic: Pass the full state to planes async atomic check
and update")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/vc4/vc4_plane.c
index 1e9c84cf614a,c76e73a452e0..
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@@ -1133,31 -1135,34 +1135,33 @@@ void vc4_plane_async_set_fb(struct drm_
}
static void vc4_plane_atomic_async_update(struct drm_plane *plane,
- struct drm_plane_state *state)
+ struct drm_atomic_state *state)
{
+ struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state,
+
plane);
struct vc4_plane_state *vc4_state, *new_vc4_state;
- swap(plane->state->fb, state->fb);
- plane->state->crtc_x = state->crtc_x;
- plane->state->crtc_y = state->crtc_y;
- plane->state->crtc_w = state->crtc_w;
- plane->state->crtc_h = state->crtc_h;
- plane->state->src_x = state->src_x;
- plane->state->src_y = state->src_y;
- plane->state->src_w = state->src_w;
- plane->state->src_h = state->src_h;
- plane->state->alpha = state->alpha;
- plane->state->pixel_blend_mode = state->pixel_blend_mode;
- plane->state->rotation = state->rotation;
- plane->state->zpos = state->zpos;
- plane->state->normalized_zpos = state->normalized_zpos;
- plane->state->color_encoding = state->color_encoding;
- plane->state->color_range = state->color_range;
- plane->state->src = state->src;
- plane->state->dst = state->dst;
- plane->state->visible = state->visible;
-
- new_vc4_state = to_vc4_plane_state(state);
+ swap(plane->state->fb, new_plane_state->fb);
+ plane->state->crtc_x = new_plane_state->crtc_x;
+ plane->state->crtc_y = new_plane_state->crtc_y;
+ plane->state->crtc_w = new_plane_state->crtc_w;
+ plane->state->crtc_h = new_plane_state->crtc_h;
+ plane->state->src_x = new_plane_state->src_x;
+ plane->state->src_y = new_plane_state->src_y;
+ plane->state->src_w = new_plane_state->src_w;
+ plane->state->src_h = new_plane_state->src_h;
- plane->state->src_h = new_plane_state->src_h;
+ plane->state->alpha = new_plane_state->alpha;
+ plane->state->pixel_blend_mode = new_plane_state->pixel_blend_mode;
+ plane->state->rotation = new_plane_state->rotation;
+ plane->state->zpos = new_plane_state->zpos;
+ plane->state->normalized_zpos = new_plane_state->normalized_zpos;
+ plane->state->color_encoding = new_plane_state->color_encoding;
+ plane->state->color_range = new_plane_state->color_range;
+ plane->state->src = new_plane_state->src;
+ plane->state->dst = new_plane_state->dst;
+ plane->state->visible = new_plane_state->visible;
+
+ new_vc4_state = to_vc4_plane_state(new_plane_state);
vc4_state = to_vc4_plane_state(plane->state);
vc4_state->crtc_x = new_vc4_state->crtc_x;
pgpPiLVbo3fI_.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
On 18/03/2021 03:02, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/omapdrm/dss/dsi.c
between commit:
690911544275 ("drm/omap: dsi: fix unsigned expression compared with zero")
from the drm-misc-fixes tree and commit:
bbd13d6a7b2e ("drm/omap: dsi: fix unreachable code in dsi_vc_send_short()")
from the drm tree.
I fixed it up (these do basically the same thing, so I used the former
version) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
Yes, I messed that up. I accidentally merged a fix to drm-misc-fixes,
but almost similar fix was already in drm-misc-next. Sorry about that.
Tomi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/omapdrm/dss/dsi.c
between commit:
690911544275 ("drm/omap: dsi: fix unsigned expression compared with zero")
from the drm-misc-fixes tree and commit:
bbd13d6a7b2e ("drm/omap: dsi: fix unreachable code in dsi_vc_send_short()")
from the drm tree.
I fixed it up (these do basically the same thing, so I used the former
version) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpVu5Im69xoX.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/drm_gem.c
between commit:
8490d6a7e0a0 ("drm: hold gem reference until object is no longer accessed")
from the drm-misc-fixes tree and commit:
be6ee102341b ("drm: remove _unlocked suffix in drm_gem_object_put_unlocked")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/drm_gem.c
index ee2058ad482c,a57f5379fc08..
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@@ -901,9 -913,7 +909,9 @@@ drm_gem_open_ioctl(struct drm_device *d
args->handle = handle;
args->size = obj->size;
- return 0;
+err:
- drm_gem_object_put_unlocked(obj);
++ drm_gem_object_put(obj);
+ return ret;
}
/**
pgpfU11_Mj8Be.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
include/linux/dma-buf.h
between commit:
6f49c2515e22 ("dma-buf: fix documentation build warnings")
from the drm-misc-fixes tree and commit:
09606b5446c2 ("dma-buf: add peer2peer flag")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/dma-buf.h
index 57bcef6f988a,82e0a4a64601..
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@@ -333,8 -334,16 +333,16 @@@ struct dma_buf
* Attachment operations implemented by the importer.
*/
struct dma_buf_attach_ops {
+ /**
+* @allow_peer2peer:
+*
+* If this is set to true the importer must be able to handle peer
+* resources without struct pages.
+*/
+ bool allow_peer2peer;
+
/**
- * @move_notify
+ * @move_notify: [optional] notification that the DMA-buf is moving
*
* If this callback is provided the framework can avoid pinning the
* backing store while mappings exists.
pgplWNZQA3I5y.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/virtio/virtgpu_object.c
between commit:
6be7e0733548 ("drm/virtio: fix mmap page attributes")
from the drm-misc-fixes tree and commit:
18b39fb975b7 ("drm/virtio: add virtio_gpu_is_shmem helper")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/virtio/virtgpu_object.c
index 3af7ec80c7da,c5cad949eb8d..
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@@ -98,8 -123,7 +123,8 @@@ struct drm_gem_object *virtio_gpu_creat
if (!bo)
return NULL;
- bo->base.base.funcs = _gpu_gem_funcs;
+ bo->base.base.funcs = _gpu_shmem_funcs;
+ bo->base.map_cached = true;
return >base.base;
}
pgpLcHdLuf4nd.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
On Mon, Aug 26, 2019 at 01:06:37PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c
>
> between commit:
>
> 51a44a28eefd ("drm/komeda: Add missing of_node_get() call")
>
> from the drm-misc-fixes tree and commit:
>
> 8965ad8433ea ("drm/komeda: Enable dual-link support")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
Hi Stephen:
Sorry for the conflict, and thank you very much.
Regards
James
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 9d4d5075cc64,1ff7f4b2c620..
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@@ -127,7 -128,8 +129,8 @@@ static int komeda_parse_pipe_dt(struct
> pipe->of_output_port =
> of_graph_get_port_by_id(np, KOMEDA_OF_PORT_OUTPUT);
>
> + pipe->dual_link = pipe->of_output_links[0] && pipe->of_output_links[1];
> -pipe->of_node = np;
> +pipe->of_node = of_node_get(np);
>
> return 0;
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/arm/display/komeda/komeda_dev.c
between commit:
51a44a28eefd ("drm/komeda: Add missing of_node_get() call")
from the drm-misc-fixes tree and commit:
8965ad8433ea ("drm/komeda: Enable dual-link support")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 9d4d5075cc64,1ff7f4b2c620..
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@@ -127,7 -128,8 +129,8 @@@ static int komeda_parse_pipe_dt(struct
pipe->of_output_port =
of_graph_get_port_by_id(np, KOMEDA_OF_PORT_OUTPUT);
+ pipe->dual_link = pipe->of_output_links[0] && pipe->of_output_links[1];
- pipe->of_node = np;
+ pipe->of_node = of_node_get(np);
return 0;
}
pgpBLlehAUUML.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/meson/meson_crtc.c
between commit:
47ebfb6ed13e ("drm/meson: Fixes for drm_crtc_vblank_on/off support")
from the drm-misc-fixes tree and commit:
f9a2348196d1 ("drm/meson: Support Overlay plane for video rendering")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/meson/meson_crtc.c
index 191b314f9e9e,d78168f979db..
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@@ -126,8 -115,8 +131,10 @@@ static void meson_crtc_atomic_disable(s
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct meson_drm *priv = meson_crtc->priv;
+ DRM_DEBUG_DRIVER("\n");
+
+ drm_crtc_vblank_off(crtc);
+
priv->viu.osd1_enabled = false;
priv->viu.osd1_commit = false;
pgpWhrigdXsgY.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/sun4i/sun4i_tcon.c
between commit:
e742a17cd360 ("drm/sun4i: tcon: Reduce the scope of the LVDS error a bit")
from the drm-misc-fixes tree and commit:
34d698f6e349 ("drm/sun4i: Add has_channel_0 TCON quirk")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/sun4i/sun4i_tcon.c
index 2de586b7c98b,0d6c5ed44795..
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@@ -1143,11 -1155,15 +1164,16 @@@ static const struct sun4i_tcon_quirks s
};
static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
+ .has_channel_0 = true,
+ .supports_lvds = true,
};
+ static const struct sun4i_tcon_quirks sun8i_a83t_tv_quirks = {
+ .has_channel_1 = true,
+ };
+
static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
- /* nothing is supported */
+ .has_channel_0 = true,
};
/* sun4i_drv uses this list to check if a device node is a TCON */
pgpvqbnENgx86.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/drm_edid.c
between commit:
4b4df570b41d ("drm: Update edid-derived drm_display_info fields at edid
property set [v2]")
from the drm-misc-fixes tree and commit:
c945b8c14bb7 ("drm/edid: build ELD in drm_add_edid_modes()")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/drm_edid.c
index cb487148359a,524eace3d460..
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@@ -4653,6 -4645,10 +4671,8 @@@ int drm_add_edid_modes(struct drm_conne
return 0;
}
- quirks = edid_get_quirks(edid);
-
+ drm_edid_to_eld(connector, edid);
+
/*
* CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
* To avoid multiple parsing of same block, lets parse that map
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
include/drm/drm_atomic.h
between commit:
7e9081c5aac7 ("drm/fence: fix memory overwrite when setting out_fence fd")
from the drm-misc-fixes tree and commit:
bdc571464c49 ("drm/atomic: Clean up wait_for_vblanks, v2.")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/drm/drm_atomic.h
index 56814e8ae7ea,f96220ed4004..
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@@ -144,7 -144,8 +144,8 @@@ struct __drm_crtcs_state
struct drm_crtc *ptr;
struct drm_crtc_state *state;
struct drm_crtc_commit *commit;
- s64 __user *out_fence_ptr;
+ s32 __user *out_fence_ptr;
+ unsigned last_vblank_count;
};
struct __drm_connnectors_state {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
