Re: linux-next: manual merge of the drm tree with Linus' tree
Hi Geert,
On Tue, 30 Mar 2021 09:36:57 +0200 Geert Uytterhoeven
wrote:
>
> On Mon, Mar 29, 2021 at 4:16 AM Stephen Rothwell
> wrote:
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >
> > between commits:
> >
> > 9adb125dde69 ("drm/amdgpu: re-enable suspend phase 2 for S0ix")
> > 4021229e32bd ("drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend")
> > 9bb735abcbd8 ("drm/amdgpu: update comments about s0ix suspend/resume")
> >
> > from Linus' tree and commit:
> >
> > e3c1b0712fdb ("drm/amdgpu: Reset the devices in the XGMI hive duirng
> > probe")
> >
> > from the drm tree.
> >
> > I fixed it up (I think - 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_device.c
> > index 8a5a8ff5d362,0f82c5d21237..
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@@ -2743,16 -2712,15 +2720,25 @@@ static int amdgpu_device_ip_suspend_pha
> > continue;
> > }
> >
> > + /* skip suspend of gfx and psp for S0ix
> > + * gfx is in gfxoff state, so on resume it will exit gfxoff
> > just
> > + * like at runtime. PSP is also part of the always on
> > hardware
> > + * so no need to suspend it.
> > + */
> > + if (adev->in_s0ix &&
> > + (adev->ip_blocks[i].version->type ==
> > AMD_IP_BLOCK_TYPE_PSP ||
> > + adev->ip_blocks[i].version->type ==
> > AMD_IP_BLOCK_TYPE_GFX))
> > + continue;
> > +
> > + /* skip unnecessary suspend if we do not initialize them
> > yet */
> > + if (adev->gmc.xgmi.pending_reset &&
> > + !(adev->ip_blocks[i].version->type ==
> > AMD_IP_BLOCK_TYPE_GMC ||
> > + adev->ip_blocks[i].version->type ==
> > AMD_IP_BLOCK_TYPE_SMC ||
> > + adev->ip_blocks[i].version->type ==
> > AMD_IP_BLOCK_TYPE_COMMON ||
> > + adev->ip_blocks[i].version->type ==
> > AMD_IP_BLOCK_TYPE_IH)) {
> > + adev->ip_blocks[i].status.hw = false;
> > + continue;
> > + }
> > /* XXX handle errors */
> > r = adev->ip_blocks[i].version->funcs->suspend(adev);
> > /* XXX handle errors */
>
> The above is not what you have in next-20210329?
> Your tree has a second copy of the first conflict block after the second:
>
> /* skip suspend of gfx and psp for S0ix
> [...]
> /* skip unnecessary suspend if we do not initialize them yet
> */
> [...]
> /* skip suspend of gfx and psp for S0ix
>
It happened because those commits in Linus' tree are also (as different
commits) in the amdgpu tree and so git happily did a new merge
resolution and ended up with what you see :-( I'll see if I can fix it
up for today.
--
Cheers,
Stephen Rothwell
Re: linux-next: manual merge of the drm tree with Linus' tree
Hi Stephen,
On Mon, Mar 29, 2021 at 4:16 AM Stephen Rothwell wrote:
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>
> between commits:
>
> 9adb125dde69 ("drm/amdgpu: re-enable suspend phase 2 for S0ix")
> 4021229e32bd ("drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend")
> 9bb735abcbd8 ("drm/amdgpu: update comments about s0ix suspend/resume")
>
> from Linus' tree and commit:
>
> e3c1b0712fdb ("drm/amdgpu: Reset the devices in the XGMI hive duirng probe")
>
> from the drm tree.
>
> I fixed it up (I think - 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_device.c
> index 8a5a8ff5d362,0f82c5d21237..
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@@ -2743,16 -2712,15 +2720,25 @@@ static int amdgpu_device_ip_suspend_pha
> continue;
> }
>
> + /* skip suspend of gfx and psp for S0ix
> + * gfx is in gfxoff state, so on resume it will exit gfxoff
> just
> + * like at runtime. PSP is also part of the always on hardware
> + * so no need to suspend it.
> + */
> + if (adev->in_s0ix &&
> + (adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_PSP ||
> + adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_GFX))
> + continue;
> +
> + /* skip unnecessary suspend if we do not initialize them yet
> */
> + if (adev->gmc.xgmi.pending_reset &&
> + !(adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_GMC ||
> + adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_SMC ||
> + adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_COMMON ||
> + adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_IH)) {
> + adev->ip_blocks[i].status.hw = false;
> + continue;
> + }
> /* XXX handle errors */
> r = adev->ip_blocks[i].version->funcs->suspend(adev);
> /* XXX handle errors */
The above is not what you have in next-20210329?
Your tree has a second copy of the first conflict block after the second:
/* skip suspend of gfx and psp for S0ix
[...]
/* skip unnecessary suspend if we do not initialize them yet */
[...]
/* skip suspend of gfx and psp for S0ix
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: linux-next: manual merge of the drm tree with Linus' tree
Hi all,
On Mon, 1 Feb 2021 12:30:12 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
>
> between commit:
>
> a119f87b86bc ("Revert "drm/amdgpu/swsmu: drop set_fan_speed_percent (v2)"")
>
> from Linus' tree and commit:
>
> d8a0b8dd690b ("drm/amd/pm: add pptable_funcs documentation (v3)")
>
> 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 drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
> index 0d797fa9f5cc,a087e00382e6..
> --- a/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
> +++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
> @@@ -551,39 -924,199 +924,201 @@@ struct pptable_funcs
> int (*display_clock_voltage_request)(struct smu_context *smu, struct
>pp_display_clock_request
>*clock_req);
> +
> + /**
> + * @get_fan_control_mode: Get the current fan control mode.
> + */
> uint32_t (*get_fan_control_mode)(struct smu_context *smu);
> +
> + /**
> + * @set_fan_control_mode: Set the fan control mode.
> + */
> int (*set_fan_control_mode)(struct smu_context *smu, uint32_t mode);
> +
> +int (*set_fan_speed_percent)(struct smu_context *smu, uint32_t speed);
> ++
> + /**
> + * @set_fan_speed_rpm: Set a static fan speed in RPM.
> + */
> int (*set_fan_speed_rpm)(struct smu_context *smu, uint32_t speed);
> +
> + /**
> + * @set_xgmi_pstate: Set inter-chip global memory interconnect pstate.
> + * &pstate: Pstate to set. D0 if Nonzero, D3 otherwise.
> + */
> int (*set_xgmi_pstate)(struct smu_context *smu, uint32_t pstate);
> +
> + /**
> + * @gfx_off_control: Enable/disable graphics engine poweroff.
> + */
> int (*gfx_off_control)(struct smu_context *smu, bool enable);
> +
> +
> + /**
> + * @get_gfx_off_status: Get graphics engine poweroff status.
> + *
> + * Return:
> + * 0 - GFXOFF(default).
> + * 1 - Transition out of GFX State.
> + * 2 - Not in GFXOFF.
> + * 3 - Transition into GFXOFF.
> + */
> uint32_t (*get_gfx_off_status)(struct smu_context *smu);
> +
> + /**
> + * @register_irq_handler: Register interupt request handlers.
> + */
> int (*register_irq_handler)(struct smu_context *smu);
> +
> + /**
> + * @set_azalia_d3_pme: Wake the audio decode engine from d3 sleep.
> + */
> int (*set_azalia_d3_pme)(struct smu_context *smu);
> +
> + /**
> + * @get_max_sustainable_clocks_by_dc: Get a copy of the max sustainable
> + *clock speeds table.
> + *
> + * Provides a way for the display component (DC) to get the max
> + * sustainable clocks from the SMU.
> + */
> int (*get_max_sustainable_clocks_by_dc)(struct smu_context *smu, struct
> pp_smu_nv_clock_table *max_clocks);
> +
> + /**
> + * @baco_is_support: Check if GPU supports BACO (Bus Active, Chip Off).
> + */
> bool (*baco_is_support)(struct smu_context *smu);
> +
> + /**
> + * @baco_get_state: Get the current BACO state.
> + *
> + * Return: Current BACO state.
> + */
> enum smu_baco_state (*baco_get_state)(struct smu_context *smu);
> +
> + /**
> + * @baco_set_state: Enter/exit BACO.
> + */
> int (*baco_set_state)(struct smu_context *smu, enum smu_baco_state
> state);
> +
> + /**
> + * @baco_enter: Enter BACO.
> + */
> int (*baco_enter)(struct smu_context *smu);
> +
> + /**
> + * @baco_exit: Exit Baco.
> + */
> int (*baco_exit)(struct smu_context *smu);
> +
> + /**
> + * @mode1_reset_is_support: Check if GPU supports mode1 reset.
> + */
> bool (*mode1_reset_is_support)(struct smu_context *smu);
> +
> + /**
> + * @mode1_reset: Perform mode1 reset.
> + *
> + * Complete GPU reset.
> + */
> int (*mode1_reset)(struct smu_context *smu);
> +
> + /**
> + * @mode2_reset: Perform mode2 reset.
> + *
> + * Mode2 reset generally does not reset as many IPs as mode1 reset. The
> + * IPs reset varies by asic.
> + */
> int (*mode2_reset)(struct smu_context *smu);
> +
> + /**
> + * @get_dpm_ultimate_freq: Get the hard frequency range of a clock
> + * domain in MHz.
> + */
> int (*get_dpm_ultimate_freq)(struct smu_context *smu, enum smu_clk_type
> clk_type, uint32_t *min, uint32_t *max);
> +
> + /**
> +
Re: linux-next: manual merge of the drm tree with Linus' tree
Hi all, On Thu, 22 Mar 2018 17:37:22 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the drm tree got conflicts in several amdgpu > files because there are a set of (mostly identical) patches that appear > Linus' tree and the drm tree. In each case I just used the version fo > the file from the drm tree. > > You should do a test merge between your tree and Linus' tree and see what > you want to do about the resolution (either do the back merge (I think > with v4.16-rc6), or provide Linus with branch that has the merge done). > Its a bit of a mess :-( I got a few more of these today. -- Cheers, Stephen Rothwell pgpqw3NCsq8IR.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the drm tree with Linus' tree
On Mon, Feb 19, 2018 at 10:10:50AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/intel_breadcrumbs.c
>
> between commit:
>
> 117172c8f9d4 ("drm/i915/breadcrumbs: Ignore unsubmitted signalers")
>
> from Linus' tree and commit:
>
> b7a3f33bd5ab ("drm/i915/breadcrumbs: Drop request reference for the
> signaler thread")
>
> from the drm tree.
>
> These are basically identical for the conflicting section except that
> the former added a line:
>
> GEM_BUG_ON(!i915_gem_request_completed(request));
>
> which I left in.
>
> I fixed it up (see above) 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.
For this and for the PMU one, I'm really sorry. I believe I should had
mentioned this to Dave when sending pull request for drm-intel-fixes.
I didn't mentioned because for what fixes is concerned this shouldn't
be a problem, but I totally forgot about linux-next. Please accept my
apologies.
Do you use any rerere on linux-next? I wonder if drm-rerere could be used
somehow here to simplify this process of propagating conflicts resolutions
like this.
Thanks,
Rodrigo.
>
> --
> Cheers,
> Stephen Rothwell
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm tree with Linus' tree
Hi all,
On Mon, 24 Jul 2017 12:06:05 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> MAINTAINERS
>
> between commit:
>
> 82abbea734d6 ("MAINTAINERS: fix alphabetical ordering")
>
> from Linus' tree and commit:
>
> 3589211e9b03 ("drm/tinydrm: Add RePaper e-ink driver")
>
> 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.
I did the resolution again after running Linus' script ...
--
Cheers,
Stephen Rothwell
diff --cc MAINTAINERS
index 55859cdde82a,9387e6aed3b8..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -4306,130 -4349,68 +4306,136 @@@ T: git git://anongit.freedesktop.org/dr
S:Maintained
F:drivers/gpu/drm/bochs/
-DRM DRIVER FOR QEMU'S CIRRUS DEVICE
+DRM DRIVER FOR INTEL I810 VIDEO CARDS
+S:Orphan / Obsolete
+F:drivers/gpu/drm/i810/
+F:include/uapi/drm/i810_drm.h
+
+DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS
+S:Orphan / Obsolete
+F:drivers/gpu/drm/mga/
+F:include/uapi/drm/mga_drm.h
+
+DRM DRIVER FOR MGA G200 SERVER GRAPHICS CHIPS
M:Dave Airlie
-M:Gerd Hoffmann
-L:virtualizat...@lists.linux-foundation.org
-T:git git://anongit.freedesktop.org/drm/drm-misc
-S:Obsolete
-W:
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
-F:drivers/gpu/drm/cirrus/
+S:Odd Fixes
+F:drivers/gpu/drm/mgag200/
-RADEON and AMDGPU DRM DRIVERS
-M:Alex Deucher
-M:Christian König
-L:amd-...@lists.freedesktop.org
-T:git git://people.freedesktop.org/~agd5f/linux
-S:Supported
-F:drivers/gpu/drm/radeon/
-F:include/uapi/drm/radeon_drm.h
-F:drivers/gpu/drm/amd/
-F:include/uapi/drm/amdgpu_drm.h
+DRM DRIVER FOR MI0283QT
+M:Noralf Trønnes
+S:Maintained
+F:drivers/gpu/drm/tinydrm/mi0283qt.c
+F:Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
-DRM PANEL DRIVERS
-M:Thierry Reding
+DRM DRIVER FOR MSM ADRENO GPU
+M:Rob Clark
+L:linux-arm-...@vger.kernel.org
L:dri-de...@lists.freedesktop.org
-T:git git://anongit.freedesktop.org/tegra/linux.git
+L:freedr...@lists.freedesktop.org
+T:git git://people.freedesktop.org/~robclark/linux
S:Maintained
-F:drivers/gpu/drm/drm_panel.c
-F:drivers/gpu/drm/panel/
-F:include/drm/drm_panel.h
-F:Documentation/devicetree/bindings/display/panel/
+F:drivers/gpu/drm/msm/
+F:include/uapi/drm/msm_drm.h
+F:Documentation/devicetree/bindings/display/msm/
-INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
-M:Daniel Vetter
-M:Jani Nikula
-L:intel-...@lists.freedesktop.org
-W:https://01.org/linuxgraphics/
-B:https://01.org/linuxgraphics/documentation/how-report-bugs
-C:irc://chat.freenode.net/intel-gfx
-Q:http://patchwork.freedesktop.org/project/intel-gfx/
-T:git git://anongit.freedesktop.org/drm-intel
+DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS
+M:Ben Skeggs
+L:dri-de...@lists.freedesktop.org
+L:nouv...@lists.freedesktop.org
+T:git git://github.com/skeggsb/linux
S:Supported
-F:drivers/gpu/drm/i915/
-F:include/drm/i915*
-F:include/uapi/drm/i915_drm.h
-F:Documentation/gpu/i915.rst
+F:drivers/gpu/drm/nouveau/
+F:include/uapi/drm/nouveau_drm.h
-INTEL GVT-g DRIVERS (Intel GPU Virtualization)
-M: Zhenyu Wang
-M: Zhi Wang
-L: intel-gvt-...@lists.freedesktop.org
-L: intel-...@lists.freedesktop.org
-W: https://01.org/igvt-g
-T: git https://github.com/01org/gvt-linux.git
-S: Supported
-F: drivers/gpu/drm/i915/gvt/
++DRM DRIVER FOR PERVASIVE DISPLAYS REPAPER PANELS
++M:Noralf Trønnes
++S:Maintained
++F:drivers/gpu/drm/tinydrm/repaper.c
++F:Documentation/devicetree/bindings/display/repaper.txt
+
-DRM DRIVERS FOR ATMEL HLCDC
-M:Boris Brezillon
+DRM DRIVER FOR QEMU'S CIRRUS DEVICE
+M:Dave Airlie
+M:Gerd Hoffmann
+L:virtualizat...@lists.linux-foundation.org
+T:git git://anongit.freedesktop.org/drm/drm-misc
+S:Obsolete
+W:
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
+F:drivers/gpu/drm/cirrus/
+
+DRM DRIVER FOR QXL VIRTUAL GPU
+M:Dave Airlie
+M:Gerd Hoffmann
+L:virtualizat...@lists.linux-foundation.org
+T:git git://anongit.freedesktop.org/drm/drm-misc
+S:Maintained
+F:drivers/gpu/drm/qxl/
+F:include/uapi/drm/qxl_drm.h
+
+DRM DRIVER FOR RAGE 128 VIDEO CARDS
+S:Orphan / Obsolete
+F:drivers/gpu/drm/r128/
+F:in
Re: linux-next: manual merge of the drm tree with Linus' tree
Hi Stephen,
Am Dienstag, den 20.09.2016, 12:42 +1000 schrieb Stephen Rothwell:
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/imx/ipuv3-crtc.c
>
> between commit:
>
> a474478642d5 ("drm/imx: fix crtc vblank state regression")
>
> from Linus' tree and commit:
>
> 5f4df0c769a9 ("drm/imx: Use DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag")
>
> from the drm tree.
>
> I fixed it up (I think - 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.
Thank you for the fix. It shouldn't be critical, but I'd put the
drm_crtc_vblank_off last, for symmetry reasons.
regards
Philipp
Re: linux-next: manual merge of the drm tree with Linus' tree
Stephen,
thanks a lot for addressing that conflict.
Replying top-style on purpose. In the future such type of conflicts should
be resolvable automatically through a git conflict resolution hook that
would use Coccinelle if present when it detects a patch with Coccinelle SmPL
grammar has been used with no required addendums. Such a tool and
further enhancements (automatic SmPL inference, if a patch did not have
the grammar spelled out in the commit log) are documented here:
http://kernelnewbies.org/KernelProjects/linux-oven
If you want this tomorrow consider funding Julia's R&D more :D
Luis
On Thu, Mar 17, 2016 at 11:45:16AM +1100, Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/sti/sti_hqvdp.c
>
> between commit:
>
> f6e45661f9be ("dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc()")
>
> from Linus' tree and commit:
>
> 52807ae90e76 ("drm/sti: use u32 to store DMA addresses")
>
> 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/sti/sti_hqvdp.c
> index 1d3c3d029603,d7c1f427811d..
> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> @@@ -617,9 -852,9 +852,8 @@@ static void sti_hqvdp_init(struct sti_h
>
> /* Allocate memory for the VDP commands */
> size = NB_VDP_CMD * sizeof(struct sti_hqvdp_cmd);
> - hqvdp->hqvdp_cmd = dma_alloc_wc(hqvdp->dev, size,
> - &hqvdp->hqvdp_cmd_paddr,
> -hqvdp->hqvdp_cmd = dma_alloc_writecombine(hqvdp->dev, size,
> - &dma_addr,
> - GFP_KERNEL | GFP_DMA);
> ++hqvdp->hqvdp_cmd = dma_alloc_wc(hqvdp->dev, size, &dma_addr,
> +GFP_KERNEL | GFP_DMA);
> if (!hqvdp->hqvdp_cmd) {
> DRM_ERROR("Failed to allocate memory for VDP cmd\n");
> return;
>
--
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg
Re: linux-next: manual merge of the drm tree with Linus' tree
Hi Stephen & Dave,
indeed RADEON_INFO_VA_UNMAP_WORKING was added to 4.1 to indicate that a
certain kernel bug is fixed now and we can remove the user space workaround.
And RADEON_INFO_GPU_RESET_COUNTER was stashed to be merged in 4.2 as new
feature.
Annoying but harmless and Stephen's resolve of the conflict looks valid
to me.
Regards,
Christian.
On 21.06.2015 05:50, Stephen Rothwell wrote:
Hi Dave,
Today's linux-next merge of the drm tree got conflicts in:
drivers/gpu/drm/radeon/radeon_kms.c
include/uapi/drm/radeon_drm.h
between commit:
3bc980bf19bb ("drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING query")
from Linus' tree and commit:
72b9076b2887 ("drm/radeon: add a GPU reset counter queryable by userspace")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the drm tree with Linus' tree
On 01/29/2015 04:17 AM, Stephen Rothwell wrote:
Hi Dave,
Today's linux-next merge of the drm tree got conflicts in
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c and
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h between commits
b8cbab042cd6 ("drm/amdkfd: Allow user to limit only queues per device")
and 9fa843e76d90 ("drm/amdkfd: Fix bug in call to init_pipelines()")
from Linus' tree and commits bcea30817574 ("drm/amdkfd: Add SDMA
user-mode queues support to QCM") and fe502804205e ("drm/amdkfd: Remove
call to deprecated init_memory interface") from the drm tree.
I fixed it up (hopefully - see below) and can carry the fix as
necessary (no action is required).
Looks fine, thanks!
Oded
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the drm tree with Linus' tree
Hi Dave, On Thu, 22 Jan 2015 02:31:06 + (GMT) Dave Airlie wrote: > > btw I pushed a drm-next with all these fixed in it a little while ago > > we must be racing! Yeah, I tend to collect all the trees first thing in the morning (around 9 - 10 am my time) and then spend the day merging them. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpXrZ5p73Lct.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the drm tree with Linus' tree
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in
> drivers/gpu/drm/radeon/radeon_kfd.c between commit b64b8afcca9d
> ("drm/amd: Fixing typos in kfd<->kgd interface") from Linus' tree and
> commit a84a9903b588 ("drm/radeon: Implement SDMA interface functions")
> from the drm tree.
btw I pushed a drm-next with all these fixed in it a little while ago
we must be racing!
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the drm tree with Linus' tree
On Mon, Nov 17, 2014 at 02:11:58PM +1100, Stephen Rothwell wrote:
> * PGP Signed by an unknown key
>
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in
> drivers/gpu/drm/tegra/dc.c between commit 8ff64c17f3be ("drm/tegra: dc:
> Add missing call to drm_vblank_on()") from Linus' tree and commits
> 205d48edee84 ("drm/tegra: dc: Factor out DC, window and cursor commit")
> and c7679306a923 ("drm/tegra: dc: Universal plane support") from the
> drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/gpu/drm/tegra/dc.c
> index 054a79f143ae,b957908aec73..
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@@ -751,7 -906,8 +906,8 @@@ static void tegra_crtc_disable(struct d
> }
> }
>
> -drm_vblank_off(drm, dc->pipe);
> +drm_crtc_vblank_off(crtc);
> + tegra_dc_commit(dc);
> }
>
> static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
> @@@ -934,15 -1090,9 +1090,9 @@@ static void tegra_crtc_prepare(struct d
> static void tegra_crtc_commit(struct drm_crtc *crtc)
> {
> struct tegra_dc *dc = to_tegra_dc(crtc);
> - unsigned long value;
> -
> - value = GENERAL_UPDATE | WIN_A_UPDATE;
> - tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> -
> - value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
> - tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
>
> -drm_vblank_post_modeset(crtc->dev, dc->pipe);
> +drm_crtc_vblank_on(crtc);
> + tegra_dc_commit(dc);
> }
>
> static void tegra_crtc_load_lut(struct drm_crtc *crtc)
Looks good.
Thanks,
Thierry
pgpslgAhELMhK.pgp
Description: PGP signature
Re: linux-next: manual merge of the drm tree with Linus' tree
On Mon, 24 Mar 2014, Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next merge of the drm tree got conflicts in
> drivers/gpu/drm/i915/intel_ddi.c and
> drivers/gpu/drm/i915/intel_dp.c between commit 825938307f81 ("Revert
> "drm/i915: don't touch the VDD when disabling the panel"") from Linus'
> tree and commits 4be7378004a0 ("drm/i915: drop ironlake_ prefix from edp
> panel/backlight functions"), dce56b3c626f ("drm/i915: save some time when
> waiting the eDP timings") and b3064154dfd3 ("drm/i915: Don't just say it,
> actually force edp vdd") from the drm tree.
>
> This latter commit in the drm tree seems to be solving the same problem
> as the one in Linus' tree (but slightly differently), so I just
> effectively dropped the patch from Linus' tree and can carry the fix as
> necessary (no action is required).
Ack. We took the long route in our -next to come to the conclusion that
a revert is the way to go, and that was then queued for 3.14.
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the drm tree with Linus' tree
On Fri, Aug 24, 2012 at 9:12 AM, Dave Airlie wrote:
> On Fri, Aug 24, 2012 at 5:13 PM, Jani Nikula wrote:
>> On Fri, 24 Aug 2012, Stephen Rothwell wrote:
>>> Hi Dave,
>>>
>>> Today's linux-next merge of the drm tree got a conflict in
>>> drivers/gpu/drm/i915/intel_modes.c between commit 4eab81366465
>>> ("drm/i915: extract connector update from intel_ddc_get_modes() for
>>> reuse") from Linus' tree and commit 451023dc32d4 ("drm: remove the
>>> raw_edid field from struct drm_display_info") from the drm tree.
>>
>> Ugh, both from me, sorry about that. Wasn't sure when or in what order
>> they'd go in.
>>
>>> I fixed it up (see below) and can carry the fix as necessary.
>>
>> I'm not quite sure what the patch below is against, but just removing
>> the reference to raw_edid from a slightly different place is the way to
>> go. Like you seem to do, so:
>>
>> Acked-by: Jani Nikula
>>
>> I can also provide a patch against drm-next if needed.
>
> That applied fine, I pulled it in for tomorrow -next.
>
Is that the correct fix for both issues reported by Stephen?
- Sedat -
> Dave.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
0001-drm-i915-Context-fixes.patch
Description: Binary data
Re: linux-next: manual merge of the drm tree with Linus' tree
On Fri, Aug 24, 2012 at 5:13 PM, Jani Nikula wrote:
> On Fri, 24 Aug 2012, Stephen Rothwell wrote:
>> Hi Dave,
>>
>> Today's linux-next merge of the drm tree got a conflict in
>> drivers/gpu/drm/i915/intel_modes.c between commit 4eab81366465
>> ("drm/i915: extract connector update from intel_ddc_get_modes() for
>> reuse") from Linus' tree and commit 451023dc32d4 ("drm: remove the
>> raw_edid field from struct drm_display_info") from the drm tree.
>
> Ugh, both from me, sorry about that. Wasn't sure when or in what order
> they'd go in.
>
>> I fixed it up (see below) and can carry the fix as necessary.
>
> I'm not quite sure what the patch below is against, but just removing
> the reference to raw_edid from a slightly different place is the way to
> go. Like you seem to do, so:
>
> Acked-by: Jani Nikula
>
> I can also provide a patch against drm-next if needed.
That applied fine, I pulled it in for tomorrow -next.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the drm tree with Linus' tree
On Fri, 24 Aug 2012, Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in
> drivers/gpu/drm/i915/intel_modes.c between commit 4eab81366465
> ("drm/i915: extract connector update from intel_ddc_get_modes() for
> reuse") from Linus' tree and commit 451023dc32d4 ("drm: remove the
> raw_edid field from struct drm_display_info") from the drm tree.
Ugh, both from me, sorry about that. Wasn't sure when or in what order
they'd go in.
> I fixed it up (see below) and can carry the fix as necessary.
I'm not quite sure what the patch below is against, but just removing
the reference to raw_edid from a slightly different place is the way to
go. Like you seem to do, so:
Acked-by: Jani Nikula
I can also provide a patch against drm-next if needed.
BR,
Jani.
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/gpu/drm/i915/intel_modes.c
> index 29b7259,7a5238f..000
> --- a/drivers/gpu/drm/i915/intel_modes.c
> +++ b/drivers/gpu/drm/i915/intel_modes.c
> @@@ -33,25 -33,6 +33,24 @@@
> #include "i915_drv.h"
>
> /**
> + * intel_connector_update_modes - update connector from edid
> + * @connector: DRM connector device to use
> + * @edid: previously read EDID information
> + */
> +int intel_connector_update_modes(struct drm_connector *connector,
> +struct edid *edid)
> +{
> +int ret;
> +
> +drm_mode_connector_update_edid_property(connector, edid);
> +ret = drm_add_edid_modes(connector, edid);
> +drm_edid_to_eld(connector, edid);
> - connector->display_info.raw_edid = NULL;
> +kfree(edid);
> +
> +return ret;
> +}
> +
> +/**
>* intel_ddc_get_modes - get modelist from monitor
>* @connector: DRM connector device to use
>* @adapter: i2c adapter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
