Re: [PATCH 1/4] drm/amdgpu: fix -Wformat-truncation warning in amdgpu_gfx_kiq_init_ring()

[Alex Deucher]

On Thu, May 23, 2024 at 11:51 AM Jani Nikula  wrote:
>
> Enabling -Wformat-truncation yields the following warning:
>
> ../drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c: In function 
> ‘amdgpu_gfx_kiq_init_ring’:
> ../drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:332:61: error: ‘%d’ directive 
> output may be truncated writing between 1 and 10 bytes into a region of size 
> between 0 and 8 [-Werror=format-truncation=]
>   332 | snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d",
>   | ^~
> ../drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:332:50: note: directive argument 
> in the range [0, 2147483647]
>   332 | snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d",
>   |  ^
> ../drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:332:9: note: ‘snprintf’ output 
> between 12 and 41 bytes into a destination of size 16
>   332 | snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d",
>   | ^~~
>   333 |  xcc_id, ring->me, ring->pipe, ring->queue);
>   |  ~~
>
> Silence the warning by checking the snprintf() return value.
>

Already fixed with this patch:
https://patchwork.freedesktop.org/patch/594864/

Thanks,

Alex

> Signed-off-by: Jani Nikula 
>
> ---
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: Pan Xinhui 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> index 1d955652f3ba..92744d0d2c10 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> @@ -329,8 +329,10 @@ int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev, 
> int xcc_id)
>
> ring->eop_gpu_addr = kiq->eop_gpu_addr;
> ring->no_scheduler = true;
> -   snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d",
> -xcc_id, ring->me, ring->pipe, ring->queue);
> +   r = snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d",
> +xcc_id, ring->me, ring->pipe, ring->queue);
> +   if (r >= sizeof(ring->name))
> +   dev_warn(adev->dev, "kiq ring name truncated\n");
> r = amdgpu_ring_init(adev, ring, 1024, irq, AMDGPU_CP_KIQ_IRQ_DRIVER0,
>  AMDGPU_RING_PRIO_DEFAULT, NULL);
> if (r)
> --
> 2.39.2
>

Re: [RESEND 0/6] drm, nouveau/radeon/amdpgu: edid_blob_ptr cleanups

[Alex Deucher]

On Mon, May 13, 2024 at 8:20 AM Jani Nikula  wrote:
>
> On Fri, 10 May 2024, Alex Deucher  wrote:
> > On Fri, May 10, 2024 at 11:17 AM Jani Nikula  wrote:
> >>
> >> I've sent this some moths ago, let's try again...
> >>
> >> BR,
> >> Jani.
> >>
> >> Jani Nikula (6):
> >>   drm/nouveau: convert to using is_hdmi and has_audio from display info
> >>   drm/radeon: convert to using is_hdmi and has_audio from display info
> >>   drm/radeon: remove radeon_connector_edid() and stop using
> >> edid_blob_ptr
> >>   drm/amdgpu: remove amdgpu_connector_edid() and stop using
> >> edid_blob_ptr
> >>   drm/edid: add a helper for EDID sysfs property show
> >>   drm/connector: update edid_blob_ptr documentation
> >
> > Series is:
> > Acked-by: Alex Deucher 
>
> Thanks, do you want to pick these up via your tree? And do you expect a
> proper R-b before merging?

Feel free to take them via drm-misc if you'd prefer to land the whole
set together, otherwise, I can pick up the radeon/amdgpu patches.

Alex


>
> BR,
> Jani.
>
>
> >
> >>
> >>  .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 16 -
> >>  .../gpu/drm/amd/amdgpu/amdgpu_connectors.h|  1 -
> >>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  4 +--
> >>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  4 +--
> >>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  4 +--
> >>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  4 +--
> >>  drivers/gpu/drm/drm_crtc_internal.h   |  2 ++
> >>  drivers/gpu/drm/drm_edid.c| 33 +++
> >>  drivers/gpu/drm/drm_sysfs.c   | 24 ++
> >>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  8 ++---
> >>  drivers/gpu/drm/nouveau/dispnv50/head.c   |  8 +
> >>  drivers/gpu/drm/nouveau/nouveau_connector.c   |  2 +-
> >>  drivers/gpu/drm/radeon/atombios_encoders.c| 10 +++---
> >>  drivers/gpu/drm/radeon/evergreen_hdmi.c   |  5 ++-
> >>  drivers/gpu/drm/radeon/radeon_audio.c | 13 
> >>  drivers/gpu/drm/radeon/radeon_connectors.c| 27 ---
> >>  drivers/gpu/drm/radeon/radeon_display.c   |  2 +-
> >>  drivers/gpu/drm/radeon/radeon_encoders.c  |  4 +--
> >>  drivers/gpu/drm/radeon/radeon_mode.h  |  2 --
> >>  include/drm/drm_connector.h   |  6 +++-
> >>  20 files changed, 79 insertions(+), 100 deletions(-)
> >>
> >> --
> >> 2.39.2
> >>
>
> --
> Jani Nikula, Intel

Re: [RESEND 0/6] drm, nouveau/radeon/amdpgu: edid_blob_ptr cleanups

[Alex Deucher]

On Fri, May 10, 2024 at 11:17 AM Jani Nikula  wrote:
>
> I've sent this some moths ago, let's try again...
>
> BR,
> Jani.
>
> Jani Nikula (6):
>   drm/nouveau: convert to using is_hdmi and has_audio from display info
>   drm/radeon: convert to using is_hdmi and has_audio from display info
>   drm/radeon: remove radeon_connector_edid() and stop using
> edid_blob_ptr
>   drm/amdgpu: remove amdgpu_connector_edid() and stop using
> edid_blob_ptr
>   drm/edid: add a helper for EDID sysfs property show
>   drm/connector: update edid_blob_ptr documentation

Series is:
Acked-by: Alex Deucher 

>
>  .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 16 -
>  .../gpu/drm/amd/amdgpu/amdgpu_connectors.h|  1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  4 +--
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  4 +--
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  4 +--
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  4 +--
>  drivers/gpu/drm/drm_crtc_internal.h   |  2 ++
>  drivers/gpu/drm/drm_edid.c| 33 +++
>  drivers/gpu/drm/drm_sysfs.c   | 24 ++
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  8 ++---
>  drivers/gpu/drm/nouveau/dispnv50/head.c   |  8 +
>  drivers/gpu/drm/nouveau/nouveau_connector.c   |  2 +-
>  drivers/gpu/drm/radeon/atombios_encoders.c| 10 +++---
>  drivers/gpu/drm/radeon/evergreen_hdmi.c   |  5 ++-
>  drivers/gpu/drm/radeon/radeon_audio.c | 13 
>  drivers/gpu/drm/radeon/radeon_connectors.c| 27 ---
>  drivers/gpu/drm/radeon/radeon_display.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_encoders.c  |  4 +--
>  drivers/gpu/drm/radeon/radeon_mode.h  |  2 --
>  include/drm/drm_connector.h   |  6 +++-
>  20 files changed, 79 insertions(+), 100 deletions(-)
>
> --
> 2.39.2
>

Re: [PATCH v2 01/12] drm/amdgpu, drm/radeon: Make I2C terminology more inclusive

[Alex Deucher]

On Wed, May 8, 2024 at 4:12 PM Easwar Hariharan
 wrote:
>
> On 5/8/2024 7:53 AM, Alex Deucher wrote:
> > On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan
> >  wrote:
> >>
> >> On 5/3/2024 11:13 AM, Easwar Hariharan wrote:
> >>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced 
> >>> "master/slave"
> >>> with more appropriate terms. Inspired by and following on to Wolfram's
> >>> series to fix drivers/i2c/[1], fix the terminology for users of
> >>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> >>> in the specification.
> >>>
> >>> Compile tested, no functionality changes intended
> >>>
> >>> [1]: 
> >>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
> >>>
> >>> Signed-off-by: Easwar Hariharan 
> >>> ---
> >>>  .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c  |  8 +++---
> >>>  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c   | 10 +++
> >>>  drivers/gpu/drm/amd/amdgpu/atombios_i2c.c |  8 +++---
> >>>  drivers/gpu/drm/amd/amdgpu/atombios_i2c.h |  2 +-
> >>>  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++---
> >>>  .../gpu/drm/amd/display/dc/bios/bios_parser.c |  2 +-
> >>>  .../drm/amd/display/dc/bios/bios_parser2.c|  2 +-
> >>>  .../drm/amd/display/dc/core/dc_link_exports.c |  4 +--
> >>>  drivers/gpu/drm/amd/display/dc/dc.h   |  2 +-
> >>>  drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c  |  4 +--
> >>>  .../display/include/grph_object_ctrl_defs.h   |  2 +-
> >>>  drivers/gpu/drm/amd/include/atombios.h|  2 +-
> >>>  drivers/gpu/drm/amd/include/atomfirmware.h| 26 -
> >>>  .../powerplay/hwmgr/vega20_processpptables.c  |  4 +--
> >>>  .../amd/pm/powerplay/inc/smu11_driver_if.h|  2 +-
> >>>  .../inc/pmfw_if/smu11_driver_if_arcturus.h|  2 +-
> >>>  .../inc/pmfw_if/smu11_driver_if_navi10.h  |  2 +-
> >>>  .../pmfw_if/smu11_driver_if_sienna_cichlid.h  |  2 +-
> >>>  .../inc/pmfw_if/smu13_driver_if_aldebaran.h   |  2 +-
> >>>  .../inc/pmfw_if/smu13_driver_if_v13_0_0.h |  2 +-
> >>>  .../inc/pmfw_if/smu13_driver_if_v13_0_7.h |  2 +-
> >>>  .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c |  4 +--
> >>>  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   |  8 +++---
> >>>  drivers/gpu/drm/radeon/atombios.h | 16 +--
> >>>  drivers/gpu/drm/radeon/atombios_i2c.c |  4 +--
> >>>  drivers/gpu/drm/radeon/radeon_combios.c   | 28 +--
> >>>  drivers/gpu/drm/radeon/radeon_i2c.c   | 10 +++
> >>>  drivers/gpu/drm/radeon/radeon_mode.h  |  6 ++--
> >>>  28 files changed, 93 insertions(+), 93 deletions(-)
> >>>
> >>
> >> 
> >>
> >> Hello Christian, Daniel, David, others,
> >>
> >> Could you re-review v2 since the feedback provided in v0 [1] has now been 
> >> addressed? I can send v3 with
> >> all other feedback and signoffs from the other maintainers incorporated 
> >> when I have something for amdgpu
> >> and radeon.
> >
> > This seems like a lot of churn.  Additionally, a bunch of these
> > headers are shared with other OSes, so it's possible some of the
> > changes may end up getting reverted accidently when we sync up or we
> > may add new headers in new code with the old nomenclature and then
> > we'd need to make sure to adjust it to make sure everything was
> > aligned again.  I would just as soon leave things as is, but I'm open
> > to acking them if there is a strong desire to update things.
> >
> > Alex
>
> The way I see it, this is a small downpayment on the debt we have built up so 
> far. Internship
> programs like LF Outreachy to get more underrepresented groups involved in 
> open source are trying to
> change the open source community culture to be more inclusive, but 
> simultaneously rely on the culture
> being welcoming enough as well.
>
> I do see the challenge involved in preserving the changes and ensuring no new 
> code is added with
> outdated nomenclature (but see [1]), but culture changes one person at a 
> time, and I'd encourage the community
> to do the work needed so we can move past our (mostly) inadvertent role in 
> perpetuating it.
>
> That's my 2c (or your sub-unit currency of choice).

Fair enough.
Acked-by: Aex Deucher 

>
> Easwar
>
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

Re: [PATCH v2 01/12] drm/amdgpu, drm/radeon: Make I2C terminology more inclusive

[Alex Deucher]

On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan
 wrote:
>
> On 5/3/2024 11:13 AM, Easwar Hariharan wrote:
> > I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> > with more appropriate terms. Inspired by and following on to Wolfram's
> > series to fix drivers/i2c/[1], fix the terminology for users of
> > I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> > in the specification.
> >
> > Compile tested, no functionality changes intended
> >
> > [1]: 
> > https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
> >
> > Signed-off-by: Easwar Hariharan 
> > ---
> >  .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c  |  8 +++---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c   | 10 +++
> >  drivers/gpu/drm/amd/amdgpu/atombios_i2c.c |  8 +++---
> >  drivers/gpu/drm/amd/amdgpu/atombios_i2c.h |  2 +-
> >  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++---
> >  .../gpu/drm/amd/display/dc/bios/bios_parser.c |  2 +-
> >  .../drm/amd/display/dc/bios/bios_parser2.c|  2 +-
> >  .../drm/amd/display/dc/core/dc_link_exports.c |  4 +--
> >  drivers/gpu/drm/amd/display/dc/dc.h   |  2 +-
> >  drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c  |  4 +--
> >  .../display/include/grph_object_ctrl_defs.h   |  2 +-
> >  drivers/gpu/drm/amd/include/atombios.h|  2 +-
> >  drivers/gpu/drm/amd/include/atomfirmware.h| 26 -
> >  .../powerplay/hwmgr/vega20_processpptables.c  |  4 +--
> >  .../amd/pm/powerplay/inc/smu11_driver_if.h|  2 +-
> >  .../inc/pmfw_if/smu11_driver_if_arcturus.h|  2 +-
> >  .../inc/pmfw_if/smu11_driver_if_navi10.h  |  2 +-
> >  .../pmfw_if/smu11_driver_if_sienna_cichlid.h  |  2 +-
> >  .../inc/pmfw_if/smu13_driver_if_aldebaran.h   |  2 +-
> >  .../inc/pmfw_if/smu13_driver_if_v13_0_0.h |  2 +-
> >  .../inc/pmfw_if/smu13_driver_if_v13_0_7.h |  2 +-
> >  .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c |  4 +--
> >  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   |  8 +++---
> >  drivers/gpu/drm/radeon/atombios.h | 16 +--
> >  drivers/gpu/drm/radeon/atombios_i2c.c |  4 +--
> >  drivers/gpu/drm/radeon/radeon_combios.c   | 28 +--
> >  drivers/gpu/drm/radeon/radeon_i2c.c   | 10 +++
> >  drivers/gpu/drm/radeon/radeon_mode.h  |  6 ++--
> >  28 files changed, 93 insertions(+), 93 deletions(-)
> >
>
> 
>
> Hello Christian, Daniel, David, others,
>
> Could you re-review v2 since the feedback provided in v0 [1] has now been 
> addressed? I can send v3 with
> all other feedback and signoffs from the other maintainers incorporated when 
> I have something for amdgpu
> and radeon.

This seems like a lot of churn.  Additionally, a bunch of these
headers are shared with other OSes, so it's possible some of the
changes may end up getting reverted accidently when we sync up or we
may add new headers in new code with the old nomenclature and then
we'd need to make sure to adjust it to make sure everything was
aligned again.  I would just as soon leave things as is, but I'm open
to acking them if there is a strong desire to update things.

Alex

Re: [PATCH 0/9] drm: Annotate structs with __counted_by

[Alex Deucher]

On Mon, Oct 2, 2023 at 5:20 AM Christian König
 wrote:
>
> Am 29.09.23 um 21:33 schrieb Kees Cook:
> > On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote:
> >> This is a batch of patches touching drm for preparing for the coming
> >> implementation by GCC and Clang of the __counted_by attribute. Flexible
> >> array members annotated with __counted_by can have their accesses
> >> bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array
> >> indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions).
> >>
> >> As found with Coccinelle[1], add __counted_by to structs that would
> >> benefit from the annotation.
> >>
> >> [...]
> > Since this got Acks, I figure I should carry it in my tree. Let me know
> > if this should go via drm instead.
> >
> > Applied to for-next/hardening, thanks!
> >
> > [1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with 
> > __counted_by
> >https://git.kernel.org/kees/c/a6046ac659d6
>
> STOP! In a follow up discussion Alex and I figured out that this won't work.
>
> The value in the structure is byte swapped based on some firmware
> endianness which not necessary matches the CPU endianness.

SMU10 is APU only so the endianess of the SMU firmware and the CPU
will always match.

Alex

>
> Please revert that one from going upstream if it's already on it's way.
>
> And because of those reasons I strongly think that patches like this
> should go through the DRM tree :)
>
> Regards,
> Christian.
>
> > [2/9] drm/amdgpu/discovery: Annotate struct ip_hw_instance with __counted_by
> >https://git.kernel.org/kees/c/4df33089b46f
> > [3/9] drm/i915/selftests: Annotate struct perf_series with __counted_by
> >https://git.kernel.org/kees/c/ffd3f823bdf6
> > [4/9] drm/msm/dpu: Annotate struct dpu_hw_intr with __counted_by
> >https://git.kernel.org/kees/c/2de35a989b76
> > [5/9] drm/nouveau/pm: Annotate struct nvkm_perfdom with __counted_by
> >https://git.kernel.org/kees/c/188aeb08bfaa
> > [6/9] drm/vc4: Annotate struct vc4_perfmon with __counted_by
> >https://git.kernel.org/kees/c/59a54dc896c3
> > [7/9] drm/virtio: Annotate struct virtio_gpu_object_array with __counted_by
> >https://git.kernel.org/kees/c/5cd476de33af
> > [8/9] drm/vmwgfx: Annotate struct vmw_surface_dirty with __counted_by
> >https://git.kernel.org/kees/c/b426f2e5356a
> > [9/9] drm/v3d: Annotate struct v3d_perfmon with __counted_by
> >https://git.kernel.org/kees/c/dc662fa1b0e4
> >
> > Take care,
> >
>

Re: [Nouveau] [PATCH 1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by

[Alex Deucher]

On Mon, Sep 25, 2023 at 1:52 PM Kees Cook  wrote:
>
> On Mon, Sep 25, 2023 at 08:30:30AM +0200, Christian König wrote:
> > Am 22.09.23 um 19:41 schrieb Alex Deucher:
> > > On Fri, Sep 22, 2023 at 1:32 PM Kees Cook  wrote:
> > > > Prepare for the coming implementation by GCC and Clang of the 
> > > > __counted_by
> > > > attribute. Flexible array members annotated with __counted_by can have
> > > > their accesses bounds-checked at run-time checking via 
> > > > CONFIG_UBSAN_BOUNDS
> > > > (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> > > > functions).
> > > >
> > > > As found with Coccinelle[1], add __counted_by for struct 
> > > > smu10_voltage_dependency_table.
> > > >
> > > > [1] 
> > > > https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
> > > >
> > > > Cc: Evan Quan 
> > > > Cc: Alex Deucher 
> > > > Cc: "Christian König" 
> > > > Cc: "Pan, Xinhui" 
> > > > Cc: David Airlie 
> > > > Cc: Daniel Vetter 
> > > > Cc: Xiaojian Du 
> > > > Cc: Huang Rui 
> > > > Cc: Kevin Wang 
> > > > Cc: amd-...@lists.freedesktop.org
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Signed-off-by: Kees Cook 
> > > Acked-by: Alex Deucher 
> >
> > Mhm, I'm not sure if this is a good idea. That is a structure filled in by
> > the firmware, isn't it?
> >
> > That would imply that we might need to byte swap count before it is
> > checkable.
>
> The script found this instance because of this:
>
> static int smu10_get_clock_voltage_dependency_table(struct pp_hwmgr *hwmgr,
> struct smu10_voltage_dependency_table **pptable,
> uint32_t num_entry, const DpmClock_t 
> *pclk_dependency_table)
> {
> uint32_t i;
> struct smu10_voltage_dependency_table *ptable;
>
> ptable = kzalloc(struct_size(ptable, entries, num_entry), GFP_KERNEL);
> if (NULL == ptable)
> return -ENOMEM;
>
> ptable->count = num_entry;
>
> So the implication is that it's native byte order... but you tell me! I
> certainly don't want this annotation if it's going to break stuff. :)

In this case, the code is for an integrated GPU in an x86 CPU so the
firmware and driver endianness match.  You wouldn't find a stand alone
dGPU that uses this structure.  In this case it's ok.  False alarm.

Alex

Re: [Nouveau] [PATCH 1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by

[Alex Deucher]

On Mon, Sep 25, 2023 at 10:07 AM Alex Deucher  wrote:
>
> On Mon, Sep 25, 2023 at 2:30 AM Christian König
>  wrote:
> >
> > Am 22.09.23 um 19:41 schrieb Alex Deucher:
> > > On Fri, Sep 22, 2023 at 1:32 PM Kees Cook  wrote:
> > >> Prepare for the coming implementation by GCC and Clang of the 
> > >> __counted_by
> > >> attribute. Flexible array members annotated with __counted_by can have
> > >> their accesses bounds-checked at run-time checking via 
> > >> CONFIG_UBSAN_BOUNDS
> > >> (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> > >> functions).
> > >>
> > >> As found with Coccinelle[1], add __counted_by for struct 
> > >> smu10_voltage_dependency_table.
> > >>
> > >> [1] 
> > >> https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
> > >>
> > >> Cc: Evan Quan 
> > >> Cc: Alex Deucher 
> > >> Cc: "Christian König" 
> > >> Cc: "Pan, Xinhui" 
> > >> Cc: David Airlie 
> > >> Cc: Daniel Vetter 
> > >> Cc: Xiaojian Du 
> > >> Cc: Huang Rui 
> > >> Cc: Kevin Wang 
> > >> Cc: amd-...@lists.freedesktop.org
> > >> Cc: dri-de...@lists.freedesktop.org
> > >> Signed-off-by: Kees Cook 
> > > Acked-by: Alex Deucher 
> >
> > Mhm, I'm not sure if this is a good idea. That is a structure filled in
> > by the firmware, isn't it?
> >
> > That would imply that we might need to byte swap count before it is
> > checkable.
>
> True. Good point.  Same for the other amdgpu patch.

Actually the other patch is fine.  That's just a local structure.

Alex

>
> Alex
>
> >
> > Regards,
> > Christian.
> >
> > >
> > >> ---
> > >>   drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h | 2 +-
> > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h 
> > >> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
> > >> index 808e0ecbe1f0..42adc2a3dcbc 100644
> > >> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
> > >> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
> > >> @@ -192,7 +192,7 @@ struct smu10_clock_voltage_dependency_record {
> > >>
> > >>   struct smu10_voltage_dependency_table {
> > >>  uint32_t count;
> > >> -   struct smu10_clock_voltage_dependency_record entries[];
> > >> +   struct smu10_clock_voltage_dependency_record entries[] 
> > >> __counted_by(count);
> > >>   };
> > >>
> > >>   struct smu10_clock_voltage_information {
> > >> --
> > >> 2.34.1
> > >>
> >

Re: [PATCH 1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by

[Alex Deucher]

On Mon, Sep 25, 2023 at 2:30 AM Christian König
 wrote:
>
> Am 22.09.23 um 19:41 schrieb Alex Deucher:
> > On Fri, Sep 22, 2023 at 1:32 PM Kees Cook  wrote:
> >> Prepare for the coming implementation by GCC and Clang of the __counted_by
> >> attribute. Flexible array members annotated with __counted_by can have
> >> their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
> >> (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> >> functions).
> >>
> >> As found with Coccinelle[1], add __counted_by for struct 
> >> smu10_voltage_dependency_table.
> >>
> >> [1] 
> >> https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
> >>
> >> Cc: Evan Quan 
> >> Cc: Alex Deucher 
> >> Cc: "Christian König" 
> >> Cc: "Pan, Xinhui" 
> >> Cc: David Airlie 
> >> Cc: Daniel Vetter 
> >> Cc: Xiaojian Du 
> >> Cc: Huang Rui 
> >> Cc: Kevin Wang 
> >> Cc: amd-...@lists.freedesktop.org
> >> Cc: dri-de...@lists.freedesktop.org
> >> Signed-off-by: Kees Cook 
> > Acked-by: Alex Deucher 
>
> Mhm, I'm not sure if this is a good idea. That is a structure filled in
> by the firmware, isn't it?
>
> That would imply that we might need to byte swap count before it is
> checkable.

True. Good point.  Same for the other amdgpu patch.

Alex

>
> Regards,
> Christian.
>
> >
> >> ---
> >>   drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h 
> >> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
> >> index 808e0ecbe1f0..42adc2a3dcbc 100644
> >> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
> >> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
> >> @@ -192,7 +192,7 @@ struct smu10_clock_voltage_dependency_record {
> >>
> >>   struct smu10_voltage_dependency_table {
> >>  uint32_t count;
> >> -   struct smu10_clock_voltage_dependency_record entries[];
> >> +   struct smu10_clock_voltage_dependency_record entries[] 
> >> __counted_by(count);
> >>   };
> >>
> >>   struct smu10_clock_voltage_information {
> >> --
> >> 2.34.1
> >>
>

Re: [PATCH 2/9] drm/amdgpu/discovery: Annotate struct ip_hw_instance with __counted_by

[Alex Deucher]

On Fri, Sep 22, 2023 at 1:33 PM Kees Cook  wrote:
>
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
> (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> functions).
>
> As found with Coccinelle[1], add __counted_by for struct ip_hw_instance.
>
> [1] 
> https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "Pan, Xinhui" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Hawking Zhang 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Kees Cook 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> index d1bc7b212520..be4c97a3d7bf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> @@ -662,7 +662,7 @@ struct ip_hw_instance {
> u8  harvest;
>
> int num_base_addresses;
> -   u32 base_addr[];
> +   u32 base_addr[] __counted_by(num_base_addresses);
>  };
>
>  struct ip_hw_id {
> --
> 2.34.1
>

Re: [PATCH 1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by

[Alex Deucher]

On Fri, Sep 22, 2023 at 1:32 PM Kees Cook  wrote:
>
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
> (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> functions).
>
> As found with Coccinelle[1], add __counted_by for struct 
> smu10_voltage_dependency_table.
>
> [1] 
> https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
>
> Cc: Evan Quan 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "Pan, Xinhui" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Xiaojian Du 
> Cc: Huang Rui 
> Cc: Kevin Wang 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Kees Cook 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h 
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
> index 808e0ecbe1f0..42adc2a3dcbc 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
> @@ -192,7 +192,7 @@ struct smu10_clock_voltage_dependency_record {
>
>  struct smu10_voltage_dependency_table {
> uint32_t count;
> -   struct smu10_clock_voltage_dependency_record entries[];
> +   struct smu10_clock_voltage_dependency_record entries[] 
> __counted_by(count);
>  };
>
>  struct smu10_clock_voltage_information {
> --
> 2.34.1
>

Re: [Nouveau] [RFC, drm-misc-next v4 3/9] drm/radeon: Implement .be_primary() callback

[Alex Deucher]

On Tue, Sep 5, 2023 at 1:25 PM suijingfeng  wrote:
>
> Hi,
>
>
> On 2023/9/5 13:50, Christian König wrote:
> > Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
> >> From: Sui Jingfeng 
> >>
> >> On a machine with multiple GPUs, a Linux user has no control over
> >> which one
> >> is primary at boot time.
> >
> > Question is why is that useful? Should we give users the ability to
> > control that?
> >
> > I don't see an use case for this.
> >
>
> On a specific machine with multiple GPUs mounted, only the
> primary graphics get POST-ed (initialized) by the firmware.
> Therefore the DRM drivers for the rest video cards have to
> work without the prerequisite setups done by firmware, This
> is called as POST.

I think that should be regarded as a bug in the driver that should be
fixed and this would not help with that case.  If a driver can't
initialize a device without aid from the pre-OS environment, that
should be fixed in the driver.  This solution also doesn't fix which
device is selected as the primary by the pre-OS environment.  That can
only be fixed in the pre-OS environment code.

>
> One of the use cases is to test if a specific DRM driver
> would works properly, under the circumstance of not being
> POST-ed, The ast drm driver is the first one which refused
> to work if not being POST-ed by the firmware.
>
> Before apply this series, I was unable make drm/ast as the
> primary video card easily. The problem is that on a multiple
> video card configuration, the monitor connected with my
> AST2400 card not light up. While confusing, a naive programmer
> may suspect the PRIME is not working.
>
> After applied this series and passing ast.modeset=10 on the
> kernel cmd line, I found that the monitor connected with my
> ast2400 video card still black, It doesn't display and It
> doesn't show image to me.

The problem with adding modeset=10 is that it only helps when you have
one GPU driven by that driver in the system.  If you have multiple
GPUs driven by that driver, which one would that apply to?  E.g., what
if you have 2 AMD GPUs in the system.

>
> While in the process of study drm/ast, I know that drm/ast
> driver has the POST code shipped, See the ast_post_gpu() function.
> Then, I was wondering why this function doesn't works.
>
> After a short-time (hasty) debugging, I found that the ast_post_gpu()
> function didn't get run. Because it have something to do with the
> ast->config_mode. Without thinking too much, I hardcoded the
> ast->config_mode as ast_use_p2a, the key point is to force the
> ast_post_gpu() function to run.
>
>
> ```
>
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -132,6 +132,8 @@ static int ast_device_config_init(struct ast_device
> *ast)
>  }
>  }
>
> +   ast->config_mode = ast_use_p2a;
> +
>  switch (ast->config_mode) {
>  case ast_use_defaults:
>  drm_info(dev, "Using default configuration\n");
>
> ```
>
> Then, the monitor light up, it display the Ubuntu greeter to me. Therefore
> my patch is useful, at least for the Linux drm driver tester and developer.
> It allow programmers to test the specific part of a specific driver without
> changing a line of the source code and without the need of sudo authority.
>
> It improves the efficiency of the testing and patch verification. I know
> the PrimaryGPU option of Xorg conf, but this approach will remember the
> setup have been made, you need modify it with root authority each time
> you want to switch the primary. But on the process of rapid developing
> and/or testing for multiple video drivers, with only one computer hardware
> resource available. What we really want is a one-shot command, as provided
> by this series.  So, this is the first use case.
>
>
> The second use case is that sometime the firmware is not reliable.
> While there are thousands of ARM64, PowerPC and Mips servers machine,
> Most of them don't have a good UEFI firmware support. I haven't test the
> drm/amdgpu and drm/radeon at my ARM64 server yet. Because this ARM64
> server always use the platform(BMC) integrated display controller as primary.
> The UEFI firmware of it does not provide options menu to tune.
> So, for the first time, the discrete card because useless, despite more 
> powerful.
> I will take time to carry on the testing, so I will be able to tell more
> in the future.
>
>
> Even on X86, when select the PEG as primary on the UEFI BIOS menu.
> There is no way to tell the bios which one of my three
> discrete video be the primary. Not to mention some old UEFI
> firmware, which doesn't provide a setting at all.
> While the benefit of my approach is the flexibility.
> Yes the i915, amdgpu and radeon are good quality,
> but there may have programmers want to try nouveau.
>
>
> The third use case is that VGAARB is also not reliable, It will
> select a wrong device as primary. Especially on Arm64, Loongarch
> and mips arch etc. And the X server will use this 

Re: [Nouveau] [PATCH -next 1/7] drm/amdkfd: Remove unnecessary NULL values

[Alex Deucher]

Applied.  Thanks!

On Wed, Aug 9, 2023 at 2:15 AM Christian König  wrote:
>
> Am 09.08.23 um 05:44 schrieb Ruan Jinjie:
> > The NULL initialization of the pointers assigned by kzalloc() first is
> > not necessary, because if the kzalloc() failed, the pointers will be
> > assigned NULL, otherwise it works as usual. so remove it.
> >
> > Signed-off-by: Ruan Jinjie 
>
> Reviewed-by: Christian König  for this one,
> the amd display code and the radeon stuff.
>
> Thanks,
> Christian.
>
> > ---
> >   drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c 
> > b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
> > index 863cf060af48..d01bb57733b3 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
> > @@ -48,7 +48,7 @@ int pipe_priority_map[] = {
> >
> >   struct kfd_mem_obj *allocate_hiq_mqd(struct kfd_node *dev, struct 
> > queue_properties *q)
> >   {
> > - struct kfd_mem_obj *mqd_mem_obj = NULL;
> > + struct kfd_mem_obj *mqd_mem_obj;
> >
> >   mqd_mem_obj = kzalloc(sizeof(struct kfd_mem_obj), GFP_KERNEL);
> >   if (!mqd_mem_obj)
> > @@ -64,7 +64,7 @@ struct kfd_mem_obj *allocate_hiq_mqd(struct kfd_node 
> > *dev, struct queue_properti
> >   struct kfd_mem_obj *allocate_sdma_mqd(struct kfd_node *dev,
> >   struct queue_properties *q)
> >   {
> > - struct kfd_mem_obj *mqd_mem_obj = NULL;
> > + struct kfd_mem_obj *mqd_mem_obj;
> >   uint64_t offset;
> >
> >   mqd_mem_obj = kzalloc(sizeof(struct kfd_mem_obj), GFP_KERNEL);
>

Re: [Nouveau] [PATCH] drm/radeon: ERROR: "(foo*)" should be "(foo *)"

[Alex Deucher]

Applied.  Thanks.  I've applied all the patches you sent out, but all
of them had whitespace problems.  Please double check your mailer on
any future submissions.

Thanks,

Alex

On Mon, Jul 10, 2023 at 6:03 AM  wrote:
>
> Fix five occurrences of the checkpatch.pl error:
> ERROR: "(foo*)" should be "(foo *)"
>
> Signed-off-by: Ran Sun 
> ---
>   drivers/gpu/drm/radeon/radeon_kms.c | 10 +-
>   1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index e0214cf1b43b..a16590c6247f 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -444,7 +444,7 @@ int radeon_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file *filp)
>   DRM_DEBUG_KMS("timestamp is r6xx+ only!\n");
>   return -EINVAL;
>   }
> -value = (uint32_t*)
> +value = (uint32_t *)
>   value_size = sizeof(uint64_t);
>   value64 = radeon_get_gpu_clock_counter(rdev);
>   break;
> @@ -543,18 +543,18 @@ int radeon_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file *filp)
>   *value = rdev->vce.fb_version;
>   break;
>   case RADEON_INFO_NUM_BYTES_MOVED:
> -value = (uint32_t*)
> +value = (uint32_t *)
>   value_size = sizeof(uint64_t);
>   value64 = atomic64_read(>num_bytes_moved);
>   break;
>   case RADEON_INFO_VRAM_USAGE:
> -value = (uint32_t*)
> +value = (uint32_t *)
>   value_size = sizeof(uint64_t);
>   man = ttm_manager_type(>mman.bdev, TTM_PL_VRAM);
>   value64 = ttm_resource_manager_usage(man);
>   break;
>   case RADEON_INFO_GTT_USAGE:
> -value = (uint32_t*)
> +value = (uint32_t *)
>   value_size = sizeof(uint64_t);
>   man = ttm_manager_type(>mman.bdev, TTM_PL_TT);
>   value64 = ttm_resource_manager_usage(man);
> @@ -614,7 +614,7 @@ int radeon_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file *filp)
>   DRM_DEBUG_KMS("Invalid request %d\n", info->request);
>   return -EINVAL;
>   }
> -if (copy_to_user(value_ptr, (char*)value, value_size)) {
> +if (copy_to_user(value_ptr, (char *)value, value_size)) {
>   DRM_ERROR("copy_to_user %s:%u\n", __func__, __LINE__);
>   return -EFAULT;
>   }

Re: [Nouveau] [PATCH v7 2/8] PCI/VGA: Deal only with VGA class devices

[Alex Deucher]

On Fri, Jun 16, 2023 at 10:22 AM Sui Jingfeng  wrote:
>
>
> On 2023/6/16 21:41, Alex Deucher wrote:
> > On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng  
> > wrote:
> >> Hi,
> >>
> >> On 2023/6/16 05:11, Alex Deucher wrote:
> >>> On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng  
> >>> wrote:
> >>>> Hi,
> >>>>
> >>>> On 2023/6/13 11:01, Sui Jingfeng wrote:
> >>>>> From: Sui Jingfeng 
> >>>>>
> >>>>> Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
> >>>>> pci_get_subsys() function with pci_get_class(). Filter the non-PCI 
> >>>>> display
> >>>>> device(pdev->class != 0x0300) out. There no need to process the 
> >>>>> non-display
> >>>>> PCI device.
> >>>>>
> >>>>> Cc: Bjorn Helgaas 
> >>>>> Signed-off-by: Sui Jingfeng 
> >>>>> ---
> >>>>> drivers/pci/vgaarb.c | 22 --
> >>>>> 1 file changed, 12 insertions(+), 10 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
> >>>>> index c1bc6c983932..22a505e877dc 100644
> >>>>> --- a/drivers/pci/vgaarb.c
> >>>>> +++ b/drivers/pci/vgaarb.c
> >>>>> @@ -754,10 +754,6 @@ static bool vga_arbiter_add_pci_device(struct 
> >>>>> pci_dev *pdev)
> >>>>> struct pci_dev *bridge;
> >>>>> u16 cmd;
> >>>>>
> >>>>> - /* Only deal with VGA class devices */
> >>>>> - if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> >>>>> - return false;
> >>>>> -
> >>>> Hi, here is probably a bug fixing.
> >>>>
> >>>> For an example, nvidia render only GPU typically has 0x0380.
> >>>>
> >>>> as its PCI class number, but render only GPU should not participate in
> >>>> the arbitration.
> >>>>
> >>>> As it shouldn't snoop the legacy fixed VGA address.
> >>>>
> >>>> It(render only GPU) can not display anything.
> >>>>
> >>>>
> >>>> But 0x0380 >> 8 = 0x03, the filter  failed.
> >>>>
> >>>>
> >>>>> /* Allocate structure */
> >>>>> vgadev = kzalloc(sizeof(struct vga_device), GFP_KERNEL);
> >>>>> if (vgadev == NULL) {
> >>>>> @@ -1500,7 +1496,9 @@ static int pci_notify(struct notifier_block *nb, 
> >>>>> unsigned long action,
> >>>>> struct pci_dev *pdev = to_pci_dev(dev);
> >>>>> bool notify = false;
> >>>>>
> >>>>> - vgaarb_dbg(dev, "%s\n", __func__);
> >>>>> + /* Only deal with VGA class devices */
> >>>>> + if (pdev->class != PCI_CLASS_DISPLAY_VGA << 8)
> >>>>> + return 0;
> >>>> So here we only care 0x0300, my initial intent is to make an 
> >>>> optimization,
> >>>>
> >>>> nowadays sane display graphic card should all has 0x0300 as its PCI
> >>>> class number, is this complete right?
> >>>>
> >>>> ```
> >>>>
> >>>> #define PCI_BASE_CLASS_DISPLAY0x03
> >>>> #define PCI_CLASS_DISPLAY_VGA0x0300
> >>>> #define PCI_CLASS_DISPLAY_XGA0x0301
> >>>> #define PCI_CLASS_DISPLAY_3D0x0302
> >>>> #define PCI_CLASS_DISPLAY_OTHER0x0380
> >>>>
> >>>> ```
> >>>>
> >>>> Any ideas ?
> >>> I'm not quite sure what you are asking about here.
> >> To be honest, I'm worried about the PCI devices which has a
> >>
> >> PCI_CLASS_DISPLAY_XGA as its PCI class number.
> >>
> >> As those devices are very uncommon in the real world.
> >>
> >>
> >> $ find . -name "*.c" -type f | xargs grep "PCI_CLASS_DISPLAY_XGA"
> >>
> >>
> >> Grep the "PCI_CLASS_DISPLAY_XGA" in the linux kernel tree got ZERO,
> >>
> >> there no code reference this macro. So I think it seems safe to ignore
> >> the XGA ?
> >>
> >>
>

Re: [Nouveau] [PATCH v7 2/8] PCI/VGA: Deal only with VGA class devices

[Alex Deucher]

On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng  wrote:
>
> Hi,
>
> On 2023/6/16 05:11, Alex Deucher wrote:
> > On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng  
> > wrote:
> >> Hi,
> >>
> >> On 2023/6/13 11:01, Sui Jingfeng wrote:
> >>> From: Sui Jingfeng 
> >>>
> >>> Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
> >>> pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
> >>> device(pdev->class != 0x0300) out. There no need to process the 
> >>> non-display
> >>> PCI device.
> >>>
> >>> Cc: Bjorn Helgaas 
> >>> Signed-off-by: Sui Jingfeng 
> >>> ---
> >>>drivers/pci/vgaarb.c | 22 --
> >>>1 file changed, 12 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
> >>> index c1bc6c983932..22a505e877dc 100644
> >>> --- a/drivers/pci/vgaarb.c
> >>> +++ b/drivers/pci/vgaarb.c
> >>> @@ -754,10 +754,6 @@ static bool vga_arbiter_add_pci_device(struct 
> >>> pci_dev *pdev)
> >>>struct pci_dev *bridge;
> >>>u16 cmd;
> >>>
> >>> - /* Only deal with VGA class devices */
> >>> - if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> >>> - return false;
> >>> -
> >> Hi, here is probably a bug fixing.
> >>
> >> For an example, nvidia render only GPU typically has 0x0380.
> >>
> >> as its PCI class number, but render only GPU should not participate in
> >> the arbitration.
> >>
> >> As it shouldn't snoop the legacy fixed VGA address.
> >>
> >> It(render only GPU) can not display anything.
> >>
> >>
> >> But 0x0380 >> 8 = 0x03, the filter  failed.
> >>
> >>
> >>>/* Allocate structure */
> >>>vgadev = kzalloc(sizeof(struct vga_device), GFP_KERNEL);
> >>>if (vgadev == NULL) {
> >>> @@ -1500,7 +1496,9 @@ static int pci_notify(struct notifier_block *nb, 
> >>> unsigned long action,
> >>>struct pci_dev *pdev = to_pci_dev(dev);
> >>>bool notify = false;
> >>>
> >>> - vgaarb_dbg(dev, "%s\n", __func__);
> >>> + /* Only deal with VGA class devices */
> >>> + if (pdev->class != PCI_CLASS_DISPLAY_VGA << 8)
> >>> + return 0;
> >> So here we only care 0x0300, my initial intent is to make an optimization,
> >>
> >> nowadays sane display graphic card should all has 0x0300 as its PCI
> >> class number, is this complete right?
> >>
> >> ```
> >>
> >> #define PCI_BASE_CLASS_DISPLAY0x03
> >> #define PCI_CLASS_DISPLAY_VGA0x0300
> >> #define PCI_CLASS_DISPLAY_XGA0x0301
> >> #define PCI_CLASS_DISPLAY_3D0x0302
> >> #define PCI_CLASS_DISPLAY_OTHER0x0380
> >>
> >> ```
> >>
> >> Any ideas ?
> > I'm not quite sure what you are asking about here.
>
> To be honest, I'm worried about the PCI devices which has a
>
> PCI_CLASS_DISPLAY_XGA as its PCI class number.
>
> As those devices are very uncommon in the real world.
>
>
> $ find . -name "*.c" -type f | xargs grep "PCI_CLASS_DISPLAY_XGA"
>
>
> Grep the "PCI_CLASS_DISPLAY_XGA" in the linux kernel tree got ZERO,
>
> there no code reference this macro. So I think it seems safe to ignore
> the XGA ?
>
>
> PCI_CLASS_DISPLAY_3D and PCI_CLASS_DISPLAY_OTHER are used to annotate
> the render-only GPU.
>
> And render-only GPU can't decode the fixed VGA address space, it is safe
> to ignore them.
>
>
> >   For vga_arb, we
> > only care about VGA class devices since those should be on the only
> > ones that might have VGA routed to them.
>
> >   However, as VGA gets deprecated,
>
> We need the vgaarb for a system with multiple video card.
>
> Not only because some Legacy VGA devices implemented
>
> on PCI will typically have the same "hard-decoded" addresses;
>
> But also these video card need to participate in the arbitration,
>
> determine the default boot device.

But couldn't the boot device be determined via what whatever resources
were used by the pre-OS console?  I feel like that should be separate
from vgaarb.  vgaarb should handle PCI VGA routing an

Re: [Nouveau] [PATCH v7 2/8] PCI/VGA: Deal only with VGA class devices

[Alex Deucher]

On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng  wrote:
>
> Hi,
>
> On 2023/6/13 11:01, Sui Jingfeng wrote:
> > From: Sui Jingfeng 
> >
> > Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
> > pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
> > device(pdev->class != 0x0300) out. There no need to process the non-display
> > PCI device.
> >
> > Cc: Bjorn Helgaas 
> > Signed-off-by: Sui Jingfeng 
> > ---
> >   drivers/pci/vgaarb.c | 22 --
> >   1 file changed, 12 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
> > index c1bc6c983932..22a505e877dc 100644
> > --- a/drivers/pci/vgaarb.c
> > +++ b/drivers/pci/vgaarb.c
> > @@ -754,10 +754,6 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> > *pdev)
> >   struct pci_dev *bridge;
> >   u16 cmd;
> >
> > - /* Only deal with VGA class devices */
> > - if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> > - return false;
> > -
>
> Hi, here is probably a bug fixing.
>
> For an example, nvidia render only GPU typically has 0x0380.
>
> at its PCI class number, but  render only GPU should not participate in
> the arbitration.
>
> As it shouldn't snoop the legacy fixed VGA address.
>
> It(render only GPU) can not display anything.
>
>
> But 0x0380 >> 8 = 0x03, the filter  failed.
>
>
> >   /* Allocate structure */
> >   vgadev = kzalloc(sizeof(struct vga_device), GFP_KERNEL);
> >   if (vgadev == NULL) {
> > @@ -1500,7 +1496,9 @@ static int pci_notify(struct notifier_block *nb, 
> > unsigned long action,
> >   struct pci_dev *pdev = to_pci_dev(dev);
> >   bool notify = false;
> >
> > - vgaarb_dbg(dev, "%s\n", __func__);
> > + /* Only deal with VGA class devices */
> > + if (pdev->class != PCI_CLASS_DISPLAY_VGA << 8)
> > + return 0;
>
> So here we only care 0x0300, my initial intent is to make an optimization,
>
> nowadays sane display graphic card should all has 0x0300 as its PCI
> class number, is this complete right?
>
> ```
>
> #define PCI_BASE_CLASS_DISPLAY0x03
> #define PCI_CLASS_DISPLAY_VGA0x0300
> #define PCI_CLASS_DISPLAY_XGA0x0301
> #define PCI_CLASS_DISPLAY_3D0x0302
> #define PCI_CLASS_DISPLAY_OTHER0x0380
>
> ```
>
> Any ideas ?

I'm not quite sure what you are asking about here.  For vga_arb, we
only care about VGA class devices since those should be on the only
ones that might have VGA routed to them.  However, as VGA gets
deprecated, you'll have more non VGA PCI classes for devices which
could be the pre-OS console device.

Alex

>
> >   /* For now we're only intereted in devices added and removed. I didn't
> >* test this thing here, so someone needs to double check for the
> > @@ -1510,6 +1508,8 @@ static int pci_notify(struct notifier_block *nb, 
> > unsigned long action,
> >   else if (action == BUS_NOTIFY_DEL_DEVICE)
> >   notify = vga_arbiter_del_pci_device(pdev);
> >
> > + vgaarb_dbg(dev, "%s: action = %lu\n", __func__, action);
> > +
> >   if (notify)
> >   vga_arbiter_notify_clients();
> >   return 0;
> > @@ -1534,8 +1534,8 @@ static struct miscdevice vga_arb_device = {
> >
> >   static int __init vga_arb_device_init(void)
> >   {
> > + struct pci_dev *pdev = NULL;
> >   int rc;
> > - struct pci_dev *pdev;
> >
> >   rc = misc_register(_arb_device);
> >   if (rc < 0)
> > @@ -1545,11 +1545,13 @@ static int __init vga_arb_device_init(void)
> >
> >   /* We add all PCI devices satisfying VGA class in the arbiter by
> >* default */
> > - pdev = NULL;
> > - while ((pdev =
> > - pci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> > -PCI_ANY_ID, pdev)) != NULL)
> > + while (1) {
> > + pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev);
> > + if (!pdev)
> > + break;
> > +
> >   vga_arbiter_add_pci_device(pdev);
> > + }
> >
> >   pr_info("loaded\n");
> >   return rc;
>
> --
> Jingfeng
>

Re: [Nouveau] [PATCH drm-next 00/14] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI

[Alex Deucher]

On Wed, Jan 18, 2023 at 11:50 AM Danilo Krummrich  wrote:
>
>
>
> On 1/18/23 17:30, Alex Deucher wrote:
> > On Wed, Jan 18, 2023 at 11:19 AM Danilo Krummrich  wrote:
> >>
> >> On 1/18/23 16:37, Christian König wrote:
> >>> Am 18.01.23 um 16:34 schrieb Danilo Krummrich:
> >>>> Hi Christian,
> >>>>
> >>>> On 1/18/23 09:53, Christian König wrote:
> >>>>> Am 18.01.23 um 07:12 schrieb Danilo Krummrich:
> >>>>>> This patch series provides a new UAPI for the Nouveau driver in
> >>>>>> order to
> >>>>>> support Vulkan features, such as sparse bindings and sparse residency.
> >>>>>>
> >>>>>> Furthermore, with the DRM GPUVA manager it provides a new DRM core
> >>>>>> feature to
> >>>>>> keep track of GPU virtual address (VA) mappings in a more generic way.
> >>>>>>
> >>>>>> The DRM GPUVA manager is indented to help drivers implement
> >>>>>> userspace-manageable
> >>>>>> GPU VA spaces in reference to the Vulkan API. In order to achieve
> >>>>>> this goal it
> >>>>>> serves the following purposes in this context.
> >>>>>>
> >>>>>>   1) Provide a dedicated range allocator to track GPU VA
> >>>>>> allocations and
> >>>>>>  mappings, making use of the drm_mm range allocator.
> >>>>>
> >>>>> This means that the ranges are allocated by the kernel? If yes that's
> >>>>> a really really bad idea.
> >>>>
> >>>> No, it's just for keeping track of the ranges userspace has allocated.
> >>>
> >>> Ok, that makes more sense.
> >>>
> >>> So basically you have an IOCTL which asks kernel for a free range? Or
> >>> what exactly is the drm_mm used for here?
> >>
> >> Not even that, userspace provides both the base address and the range,
> >> the kernel really just keeps track of things. Though, writing a UAPI on
> >> top of the GPUVA manager asking for a free range instead would be
> >> possible by just adding the corresponding wrapper functions to get a
> >> free hole.
> >>
> >> Currently, and that's what I think I read out of your question, the main
> >> benefit of using drm_mm over simply stuffing the entries into a list or
> >> something boils down to easier collision detection and iterating
> >> sub-ranges of the whole VA space.
> >
> > Why not just do this in userspace?  We have a range manager in
> > libdrm_amdgpu that you could lift out into libdrm or some other
> > helper.
>
> The kernel still needs to keep track of the mappings within the various
> VA spaces, e.g. it silently needs to unmap mappings that are backed by
> BOs that get evicted and remap them once they're validated (or swapped
> back in).

Ok, you are just using this for maintaining the GPU VM space in the kernel.

Alex

>
> >
> > Alex
> >
> >
> >>
> >>>
> >>> Regards,
> >>> Christian.
> >>>
> >>>>
> >>>> - Danilo
> >>>>
> >>>>>
> >>>>> Regards,
> >>>>> Christian.
> >>>>>
> >>>>>>
> >>>>>>   2) Generically connect GPU VA mappings to their backing
> >>>>>> buffers, in
> >>>>>>  particular DRM GEM objects.
> >>>>>>
> >>>>>>   3) Provide a common implementation to perform more complex 
> >>>>>> mapping
> >>>>>>  operations on the GPU VA space. In particular splitting and
> >>>>>> merging
> >>>>>>  of GPU VA mappings, e.g. for intersecting mapping requests
> >>>>>> or partial
> >>>>>>  unmap requests.
> >>>>>>
> >>>>>> The new VM_BIND Nouveau UAPI build on top of the DRM GPUVA manager,
> >>>>>> itself
> >>>>>> providing the following new interfaces.
> >>>>>>
> >>>>>>   1) Initialize a GPU VA space via the new
> >>>>>> DRM_IOCTL_NOUVEAU_VM_INIT ioctl
> >>>>>>  for UMDs to specify the portion of VA space managed by the
> >>>>>> ke

Re: [Nouveau] [PATCH drm-next 00/14] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI

[Alex Deucher]

On Wed, Jan 18, 2023 at 11:19 AM Danilo Krummrich  wrote:
>
> On 1/18/23 16:37, Christian König wrote:
> > Am 18.01.23 um 16:34 schrieb Danilo Krummrich:
> >> Hi Christian,
> >>
> >> On 1/18/23 09:53, Christian König wrote:
> >>> Am 18.01.23 um 07:12 schrieb Danilo Krummrich:
>  This patch series provides a new UAPI for the Nouveau driver in
>  order to
>  support Vulkan features, such as sparse bindings and sparse residency.
> 
>  Furthermore, with the DRM GPUVA manager it provides a new DRM core
>  feature to
>  keep track of GPU virtual address (VA) mappings in a more generic way.
> 
>  The DRM GPUVA manager is indented to help drivers implement
>  userspace-manageable
>  GPU VA spaces in reference to the Vulkan API. In order to achieve
>  this goal it
>  serves the following purposes in this context.
> 
>   1) Provide a dedicated range allocator to track GPU VA
>  allocations and
>  mappings, making use of the drm_mm range allocator.
> >>>
> >>> This means that the ranges are allocated by the kernel? If yes that's
> >>> a really really bad idea.
> >>
> >> No, it's just for keeping track of the ranges userspace has allocated.
> >
> > Ok, that makes more sense.
> >
> > So basically you have an IOCTL which asks kernel for a free range? Or
> > what exactly is the drm_mm used for here?
>
> Not even that, userspace provides both the base address and the range,
> the kernel really just keeps track of things. Though, writing a UAPI on
> top of the GPUVA manager asking for a free range instead would be
> possible by just adding the corresponding wrapper functions to get a
> free hole.
>
> Currently, and that's what I think I read out of your question, the main
> benefit of using drm_mm over simply stuffing the entries into a list or
> something boils down to easier collision detection and iterating
> sub-ranges of the whole VA space.

Why not just do this in userspace?  We have a range manager in
libdrm_amdgpu that you could lift out into libdrm or some other
helper.

Alex


>
> >
> > Regards,
> > Christian.
> >
> >>
> >> - Danilo
> >>
> >>>
> >>> Regards,
> >>> Christian.
> >>>
> 
>   2) Generically connect GPU VA mappings to their backing
>  buffers, in
>  particular DRM GEM objects.
> 
>   3) Provide a common implementation to perform more complex mapping
>  operations on the GPU VA space. In particular splitting and
>  merging
>  of GPU VA mappings, e.g. for intersecting mapping requests
>  or partial
>  unmap requests.
> 
>  The new VM_BIND Nouveau UAPI build on top of the DRM GPUVA manager,
>  itself
>  providing the following new interfaces.
> 
>   1) Initialize a GPU VA space via the new
>  DRM_IOCTL_NOUVEAU_VM_INIT ioctl
>  for UMDs to specify the portion of VA space managed by the
>  kernel and
>  userspace, respectively.
> 
>   2) Allocate and free a VA space region as well as bind and
>  unbind memory
>  to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND
>  ioctl.
> 
>   3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.
> 
>  Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, make use
>  of the DRM
>  scheduler to queue jobs and support asynchronous processing with DRM
>  syncobjs
>  as synchronization mechanism.
> 
>  By default DRM_IOCTL_NOUVEAU_VM_BIND does synchronous processing,
>  DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.
> 
>  The new VM_BIND UAPI for Nouveau makes also use of drm_exec
>  (execution context
>  for GEM buffers) by Christian König. Since the patch implementing
>  drm_exec was
>  not yet merged into drm-next it is part of this series, as well as a
>  small fix
>  for this patch, which was found while testing this series.
> 
>  This patch series is also available at [1].
> 
>  There is a Mesa NVK merge request by Dave Airlie [2] implementing the
>  corresponding userspace parts for this series.
> 
>  The Vulkan CTS test suite passes the sparse binding and sparse
>  residency test
>  cases for the new UAPI together with Dave's Mesa work.
> 
>  There are also some test cases in the igt-gpu-tools project [3] for
>  the new UAPI
>  and hence the DRM GPU VA manager. However, most of them are testing
>  the DRM GPU
>  VA manager's logic through Nouveau's new UAPI and should be
>  considered just as
>  helper for implementation.
> 
>  However, I absolutely intend to change those test cases to proper
>  kunit test
>  cases for the DRM GPUVA manager, once and if we agree on it's
>  usefulness and
>  design.
> 
>  [1]
>  https://gitlab.freedesktop.org/nouvelles/kernel/-/tree/new-uapi-drm-next 
>  /
> 

Re: [Nouveau] [PATCH v3 0/3] drm/{amdgpu, i915, nouveau, radeon}: Fix fbdev and vga-switcheroo

[Alex Deucher]

On Mon, Jan 16, 2023 at 6:54 AM Thomas Zimmermann  wrote:
>
> (was: drm: Generic fbdev and vga-switcheroo)
>
> This patchset fixes how fbdev helpers interact with vga-switcheroo. The
> first two patches are bug fixes for the existing code. The third patch
> cleans up the drivers.
>
> Patch 1 fixes i915 to do the correct thing if the device has not been
> initialized yet. Switching to the device is only possible after the
> initialization, but switching away is always possible.
>
> Patch 2 is the original patch without the amdgpu changes. Installs
> the fbdev framebuffer in vga-switcheroo for the PCI device. Does
> nothing for drivers without vga-switcheroo.
>
> Patch 3 cleans up vga_switcheroo_process_delayed_switch() in amdgpu
> and the other related drivers (i.e., i915, nouveau and radeon). The
> call is now located at the end of drm_lastclose() and drivers do not
> need their own lastclose helpers any longer.
>
> I kept the r-bs from v1, but patch 1 is entirely new and patch 3 has
> significantly grown in size.

Series is:
Reviewed-by: Alex Deucher 

>
> v3:
> * include drm_fb_helper.h in radeon_drv.c
> v2:
> * expand to patch series
> * fix i915, nouveau and radeon
>
> Thomas Zimmermann (3):
>   drm/i915: Allow switching away via vga-switcheroo if uninitialized
>   drm/fb-helper: Set framebuffer for vga-switcheroo clients
>   drm: Call vga_switcheroo_process_delayed_switch() in drm_lastclose
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 13 -
>  drivers/gpu/drm/drm_fb_helper.c |  8 
>  drivers/gpu/drm/drm_file.c  |  3 +++
>  drivers/gpu/drm/i915/i915_driver.c  | 26 ++---
>  drivers/gpu/drm/i915/i915_switcheroo.c  |  6 +-
>  drivers/gpu/drm/nouveau/nouveau_drm.c   |  1 -
>  drivers/gpu/drm/nouveau/nouveau_vga.c   |  7 ---
>  drivers/gpu/drm/nouveau/nouveau_vga.h   |  1 -
>  drivers/gpu/drm/radeon/radeon_drv.c |  3 ++-
>  drivers/gpu/drm/radeon/radeon_drv.h |  1 -
>  drivers/gpu/drm/radeon/radeon_kms.c | 18 -
>  drivers/gpu/vga/vga_switcheroo.c|  4 ++--
>  14 files changed, 22 insertions(+), 72 deletions(-)
>
>
> base-commit: 68d139b609a97a83e7c231189d4864aba4e1679b
> prerequisite-patch-id: 0aa359f6144c4015c140c8a6750be19099c676fb
> prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
> prerequisite-patch-id: 3f204510fcbf9530d6540bd8e6128cce598988b6
> --
> 2.39.0
>

Re: [Nouveau] [PATCH 00/22] drm: Remove includes for drm_crtc_helper.h

[Alex Deucher]

On Mon, Jan 16, 2023 at 11:20 AM Jani Nikula
 wrote:
>
> On Mon, 16 Jan 2023, Thomas Zimmermann  wrote:
> > A lot of source files include drm_crtc_helper.h for its contained
> > include statements. This leads to excessive compile-time dependencies.
> >
> > Where possible, remove the include statements for drm_crtc_helper.h
> > and include the required source files directly. Also remove the
> > include statements from drm_crtc_helper.h itself, which doesn't need
> > most of them.
> >
> > I built this patchset on x86-64, aarch64 and arm. Hopefully I found
> > all include dependencies.
>
> I think this is the right direction and I support this. Personally I
> think it's enough to build test and fix any fallout afterwards.
>
> To that end, I did build test this myself with my config, and it was
> fine, though that probably doesn't add much coverage.
>
> FWIW,
>
> Acked-by: Jani Nikula 

Agreed.  I applied 1/22 since it was an unrelated cleanup, but the
rest of the series is:
Acked-by: Alex Deucher 

>
>
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Nouveau] [PATCH 01/22] drm/amdgpu: Fix coding style

[Alex Deucher]

Applied.  Thanks!
On Mon, Jan 16, 2023 at 8:13 AM Thomas Zimmermann  wrote:
>
> Align a closing brace and remove trailing whitespaces. No functional
> changes.
>
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index e47058c2c294..0993ee91fe18 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -5871,8 +5871,8 @@ void amdgpu_device_invalidate_hdp(struct amdgpu_device 
> *adev,
>  int amdgpu_in_reset(struct amdgpu_device *adev)
>  {
> return atomic_read(>reset_domain->in_gpu_reset);
> -   }
> -
> +}
> +
>  /**
>   * amdgpu_device_halt() - bring hardware to some kind of halt state
>   *
> --
> 2.39.0
>

Re: [Nouveau] [PATCH] drm/nouveau: Remove file nouveau_fbcon.c

[Alex Deucher]

On Mon, Jan 9, 2023 at 10:27 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 09.01.23 um 15:15 schrieb Alex Deucher:
> > On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann  
> > wrote:
> >>
> >> Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> >> converted nouveau to generic fbdev emulation. Also remove the internal
> >> implementation from the driver. No functional changes.
> >
> > Looking at 4a16dd9d18a0, it appears to have removed this file already.
> > I guess it somehow got re-added?
>
> OK, I tihnk I found it in the merge of drm-misc-next-2022-11-10-1 into
> drm-next. See
>
>https://cgit.freedesktop.org/drm/drm/commit/?id=4e291f2f5853
>
> There was a conflict between the removal and my rework of the some fbdev
> helpers.
>
> Do we use Fixes tags with merge commits?

Seems fine to me, but either way:
Reviewed-by: Alex Deucher 

Alex


>
> Best regards
> Thomas
>
> >
> > Alex
> >
> >
> >>
> >> Signed-off-by: Thomas Zimmermann 
> >> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> >> Cc: Ben Skeggs 
> >> Cc: Karol Herbst 
> >> Cc: Lyude Paul 
> >> Cc: Thomas Zimmermann 
> >> Cc: Javier Martinez Canillas 
> >> Cc: Sam Ravnborg 
> >> Cc: Jani Nikula 
> >> Cc: Dave Airlie 
> >> Cc: dri-de...@lists.freedesktop.org
> >> Cc: nouveau@lists.freedesktop.org
> >> ---
> >>   drivers/gpu/drm/nouveau/nouveau_fbcon.c | 613 
> >>   1 file changed, 613 deletions(-)
> >>   delete mode 100644 drivers/gpu/drm/nouveau/nouveau_fbcon.c
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> >> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> >> deleted file mode 100644
> >> index e87de7906f78..
> >> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> >> +++ /dev/null
> >> @@ -1,613 +0,0 @@
> >> -/*
> >> - * Copyright © 2007 David Airlie
> >> - *
> >> - * Permission is hereby granted, free of charge, to any person obtaining a
> >> - * copy of this software and associated documentation files (the 
> >> "Software"),
> >> - * to deal in the Software without restriction, including without 
> >> limitation
> >> - * the rights to use, copy, modify, merge, publish, distribute, 
> >> sublicense,
> >> - * and/or sell copies of the Software, and to permit persons to whom the
> >> - * Software is furnished to do so, subject to the following conditions:
> >> - *
> >> - * The above copyright notice and this permission notice (including the 
> >> next
> >> - * paragraph) shall be included in all copies or substantial portions of 
> >> the
> >> - * Software.
> >> - *
> >> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> >> EXPRESS OR
> >> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> >> MERCHANTABILITY,
> >> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> >> SHALL
> >> - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> >> OTHER
> >> - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >> - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> >> - * DEALINGS IN THE SOFTWARE.
> >> - *
> >> - * Authors:
> >> - * David Airlie
> >> - */
> >> -
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -#include 
> >> -
> >> -#include "nouveau_drv.h"
> >> -#include "nouveau_gem.h"
> >> -#include "nouveau_bo.h"
> >> -#include "nouveau_fbcon.h"
> >> -#include "nouveau_chan.h"
> >> -#include "nouveau_vmm.h"
> >> -
> >> -#include "nouveau_crtc.h"
> >> -
> >> -MODULE_PARM_DESC(nofbaccel, "Disable fbcon acceleration");
> >> -int nouveau_nofbaccel = 0;
> >> -module_param_named(nofbaccel, nouveau_nofbaccel, int, 0400);
> 

Re: [Nouveau] [PATCH] drm/nouveau: Remove file nouveau_fbcon.c

[Alex Deucher]

On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann  wrote:
>
> Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> converted nouveau to generic fbdev emulation. Also remove the internal
> implementation from the driver. No functional changes.

Looking at 4a16dd9d18a0, it appears to have removed this file already.
I guess it somehow got re-added?

Alex


>
> Signed-off-by: Thomas Zimmermann 
> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> Cc: Ben Skeggs 
> Cc: Karol Herbst 
> Cc: Lyude Paul 
> Cc: Thomas Zimmermann 
> Cc: Javier Martinez Canillas 
> Cc: Sam Ravnborg 
> Cc: Jani Nikula 
> Cc: Dave Airlie 
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> ---
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c | 613 
>  1 file changed, 613 deletions(-)
>  delete mode 100644 drivers/gpu/drm/nouveau/nouveau_fbcon.c
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> deleted file mode 100644
> index e87de7906f78..
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ /dev/null
> @@ -1,613 +0,0 @@
> -/*
> - * Copyright © 2007 David Airlie
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the next
> - * paragraph) shall be included in all copies or substantial portions of the
> - * Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> - * DEALINGS IN THE SOFTWARE.
> - *
> - * Authors:
> - * David Airlie
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include "nouveau_drv.h"
> -#include "nouveau_gem.h"
> -#include "nouveau_bo.h"
> -#include "nouveau_fbcon.h"
> -#include "nouveau_chan.h"
> -#include "nouveau_vmm.h"
> -
> -#include "nouveau_crtc.h"
> -
> -MODULE_PARM_DESC(nofbaccel, "Disable fbcon acceleration");
> -int nouveau_nofbaccel = 0;
> -module_param_named(nofbaccel, nouveau_nofbaccel, int, 0400);
> -
> -MODULE_PARM_DESC(fbcon_bpp, "fbcon bits-per-pixel (default: auto)");
> -static int nouveau_fbcon_bpp;
> -module_param_named(fbcon_bpp, nouveau_fbcon_bpp, int, 0400);
> -
> -static void
> -nouveau_fbcon_fillrect(struct fb_info *info, const struct fb_fillrect *rect)
> -{
> -   struct nouveau_fbdev *fbcon = info->par;
> -   struct nouveau_drm *drm = nouveau_drm(fbcon->helper.dev);
> -   struct nvif_device *device = >client.device;
> -   int ret;
> -
> -   if (info->state != FBINFO_STATE_RUNNING)
> -   return;
> -
> -   ret = -ENODEV;
> -   if (!in_interrupt() && !(info->flags & FBINFO_HWACCEL_DISABLED) &&
> -   mutex_trylock(>client.mutex)) {
> -   if (device->info.family < NV_DEVICE_INFO_V0_TESLA)
> -   ret = nv04_fbcon_fillrect(info, rect);
> -   else
> -   if (device->info.family < NV_DEVICE_INFO_V0_FERMI)
> -   ret = nv50_fbcon_fillrect(info, rect);
> -   else
> -   ret = nvc0_fbcon_fillrect(info, rect);
> -   mutex_unlock(>client.mutex);
> -   }
> -
> -   if (ret == 0)
> -   return;
> -
> -   if (ret != -ENODEV)
> -   nouveau_fbcon_gpu_lockup(info);
> -   drm_fb_helper_cfb_fillrect(info, rect);
> -}
> -
> -static void
> -nouveau_fbcon_copyarea(struct fb_info *info, const struct fb_copyarea *image)
> -{
> -   struct nouveau_fbdev *fbcon = info->par;
> -   struct nouveau_drm *drm = nouveau_drm(fbcon->helper.dev);
> -   struct nvif_device *device = >client.device;
> -   int ret;
> -
> -   if (info->state != FBINFO_STATE_RUNNING)
> -   return;
> -
> -   ret = -ENODEV;
> -   if (!in_interrupt() && !(info->flags & FBINFO_HWACCEL_DISABLED) &&
> -   mutex_trylock(>client.mutex)) {
> -   if (device->info.family < NV_DEVICE_INFO_V0_TESLA)
> -   ret = 

Re: [Nouveau] [PATCH v2 14/29] drm/radeon: Register ACPI video backlight when skipping radeon backlight registration

[Alex Deucher]

On Tue, Jul 12, 2022 at 3:40 PM Hans de Goede  wrote:
>
> Typically the acpi_video driver will initialize before radeon, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> radeon would register its own radeon_bl# device later. After which
> the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
> to avoid there being 2 backlight devices.
>
> This means that userspace used to briefly see 2 devices and the
> disappearing of acpi_video0 after a brief time confuses the systemd
> backlight level save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
>
> To fix this the ACPI video code has been modified to make backlight class
> device registration a separate step, relying on the drm/kms driver to
> ask for the acpi_video backlight registration after it is done setting up
> its native backlight device.
>
> Add a call to the new acpi_video_register_backlight() when radeon skips
> registering its own backlight device because of e.g. the firmware_flags
> or the acpi_video_get_backlight_type() return value. This ensures that
> if the acpi_video backlight device should be used, it will be available
> before the radeon drm_device gets registered with userspace.
>
> Signed-off-by: Hans de Goede 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
> b/drivers/gpu/drm/radeon/radeon_encoders.c
> index 46549d5179ee..c1cbebb51be1 100644
> --- a/drivers/gpu/drm/radeon/radeon_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_encoders.c
> @@ -30,6 +30,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  #include "radeon.h"
>  #include "radeon_atombios.h"
>  #include "radeon_legacy_encoders.h"
> @@ -167,7 +169,7 @@ static void radeon_encoder_add_backlight(struct 
> radeon_encoder *radeon_encoder,
> return;
>
> if (radeon_backlight == 0) {
> -   return;
> +   use_bl = false;
> } else if (radeon_backlight == 1) {
> use_bl = true;
> } else if (radeon_backlight == -1) {
> @@ -193,6 +195,13 @@ static void radeon_encoder_add_backlight(struct 
> radeon_encoder *radeon_encoder,
> else
> radeon_legacy_backlight_init(radeon_encoder, 
> connector);
> }
> +
> +   /*
> +* If there is no native backlight device (which may happen even when
> +* use_bl==true) try registering an ACPI video backlight device 
> instead.
> +*/
> +   if (!rdev->mode_info.bl_encoder)
> +   acpi_video_register_backlight();
>  }
>
>  void
> --
> 2.36.0
>

Re: [Nouveau] [PATCH v2 13/29] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration

[Alex Deucher]

On Tue, Jul 12, 2022 at 3:40 PM Hans de Goede  wrote:
>
> Typically the acpi_video driver will initialize before amdgpu, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> amdgpu would register its own amdgpu_bl# device later. After which
> the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
> to avoid there being 2 backlight devices.
>
> This means that userspace used to briefly see 2 devices and the
> disappearing of acpi_video0 after a brief time confuses the systemd
> backlight level save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
>
> To fix this the ACPI video code has been modified to make backlight class
> device registration a separate step, relying on the drm/kms driver to
> ask for the acpi_video backlight registration after it is done setting up
> its native backlight device.
>
> Add a call to the new acpi_video_register_backlight() when amdgpu skips
> registering its own backlight device because of either the firmware_flags
> or the acpi_video_get_backlight_type() return value. This ensures that
> if the acpi_video backlight device should be used, it will be available
> before the amdgpu drm_device gets registered with userspace.
>
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 9 +++--
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> index abf209e36fca..45cd9268b426 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> @@ -184,11 +184,11 @@ void amdgpu_atombios_encoder_init_backlight(struct 
> amdgpu_encoder *amdgpu_encode
> return;
>
> if (!(adev->mode_info.firmware_flags & 
> ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
> -   return;
> +   goto register_acpi_backlight;
>
> if (!acpi_video_backlight_use_native()) {
> DRM_INFO("Skipping amdgpu atom DIG backlight registration\n");
> -   return;
> +   goto register_acpi_backlight;
> }
>
> pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
> @@ -225,6 +225,11 @@ void amdgpu_atombios_encoder_init_backlight(struct 
> amdgpu_encoder *amdgpu_encode
>  error:
> kfree(pdata);
> return;
> +
> +register_acpi_backlight:
> +   /* Try registering an ACPI video backlight device instead. */
> +   acpi_video_register_backlight();
> +   return;

Can drop the return here.  Either way,
Acked-by: Alex Deucher 

>  }
>
>  void
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 3b03a95e59a8..a667e66a9842 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4054,6 +4054,8 @@ amdgpu_dm_register_backlight_device(struct 
> amdgpu_display_manager *dm)
>
> if (!acpi_video_backlight_use_native()) {
> DRM_INFO("Skipping amdgpu DM backlight registration\n");
> +   /* Try registering an ACPI video backlight device instead. */
> +   acpi_video_register_backlight();
> return;
> }
>
> --
> 2.36.0
>

Re: [Nouveau] [PATCH v2 09/29] ACPI: video: Make backlight class device registration a separate step

[Alex Deucher]

On Tue, Jul 12, 2022 at 3:40 PM Hans de Goede  wrote:
>
> On x86/ACPI boards the acpi_video driver will usually initializing before

initializing -> initialize

> the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
> to show up and then the kms driver registers its own native backlight
> device after which the drivers/acpi/video_detect.c code unregisters
> the acpi_video0 device (when acpi_video_get_backlight_type()==native).
>
> This means that userspace briefly sees 2 devices and the disappearing of
> acpi_video0 after a brief time confuses the systemd backlight level
> save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
>
> To fix this make backlight class device registration a separate step
> done by a new acpi_video_register_backlight() function. The intend is for
> this to be called by the drm/kms driver *after* it is done setting up its
> own native backlight device. So that acpi_video_get_backlight_type() knows
> if a native backlight will be available or not at acpi_video backlight
> registration time, avoiding the add + remove dance.
>
> Note the new acpi_video_register_backlight() function is also called from
> a delayed work to ensure that the acpi_video backlight devices does get
> registered if necessary even if there is no drm/kms driver or when it is
> disabled.
>
> Signed-off-by: Hans de Goede 
> ---
>  drivers/acpi/acpi_video.c | 45 ---
>  include/acpi/video.h  |  2 ++
>  2 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
> index 6944794797a5..c4c3a9e7ce69 100644
> --- a/drivers/acpi/acpi_video.c
> +++ b/drivers/acpi/acpi_video.c
> @@ -31,6 +31,12 @@
>  #define ACPI_VIDEO_BUS_NAME"Video Bus"
>  #define ACPI_VIDEO_DEVICE_NAME "Video Device"
>
> +/*
> + * Display probing is known to take up to 5 seconds, so delay the fallback
> + * backlight registration by 5 seconds + 3 seconds for some extra margin.
> + */
> +#define ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY(8 * HZ)
> +
>  #define MAX_NAME_LEN   20
>
>  MODULE_AUTHOR("Bruno Ducrot");
> @@ -81,6 +87,9 @@ static LIST_HEAD(video_bus_head);
>  static int acpi_video_bus_add(struct acpi_device *device);
>  static int acpi_video_bus_remove(struct acpi_device *device);
>  static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
> +static void acpi_video_bus_register_backlight_work(struct work_struct 
> *ignored);
> +static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
> +   acpi_video_bus_register_backlight_work);
>  void acpi_video_detect_exit(void);
>
>  /*
> @@ -1865,8 +1874,6 @@ static int acpi_video_bus_register_backlight(struct 
> acpi_video_bus *video)
> if (video->backlight_registered)
> return 0;
>
> -   acpi_video_run_bcl_for_osi(video);
> -
> if (acpi_video_get_backlight_type() != acpi_backlight_video)
> return 0;
>
> @@ -2092,7 +2099,11 @@ static int acpi_video_bus_add(struct acpi_device 
> *device)
> list_add_tail(>entry, _bus_head);
> mutex_unlock(_list_lock);
>
> -   acpi_video_bus_register_backlight(video);
> +   /*
> +* The userspace visible backlight_device gets registered separately
> +* from acpi_video_register_backlight().
> +*/
> +   acpi_video_run_bcl_for_osi(video);
> acpi_video_bus_add_notify_handler(video);
>
> return 0;
> @@ -2131,6 +2142,11 @@ static int acpi_video_bus_remove(struct acpi_device 
> *device)
> return 0;
>  }
>
> +static void acpi_video_bus_register_backlight_work(struct work_struct 
> *ignored)
> +{
> +   acpi_video_register_backlight();
> +}
> +
>  static int __init is_i740(struct pci_dev *dev)
>  {
> if (dev->device == 0x00D1)
> @@ -2241,6 +2257,17 @@ int acpi_video_register(void)
>  */
> register_count = 1;
>
> +   /*
> +* acpi_video_bus_add() skips registering the userspace visible
> +* backlight_device. The intend is for this to be registered by the
> +* drm/kms driver calling acpi_video_register_backlight() *after* it 
> is
> +* done setting up its own native backlight device. The delayed work
> +* ensures that acpi_video_register_backlight() always gets called
> +* eventually, in case there is no drm/kms driver or it is disabled.
> +*/
> +   schedule_delayed_work(_bus_register_backlight_work,
> + ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY);
> +
>  leave:
> mutex_unlock(_count_mutex);
> return ret;
> @@ -2251,6 +2278,7 @@ void acpi_video_unregister(void)
>  {
> mutex_lock(_count_mutex);
> if (register_count) {
> +   cancel_delayed_work_sync(_bus_register_backlight_work);
> acpi_bus_unregister_driver(_video_bus);
> register_count = 0;
> 

Re: [Nouveau] [PATCH v2 03/29] drm/amdgpu: Don't register backlight when another backlight should be used

[Alex Deucher]

On Wed, Jul 20, 2022 at 12:44 PM Alex Deucher  wrote:
>
> On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede  wrote:
> >
> > Before this commit when we want userspace to use the acpi_video backlight
> > device we register both the GPU's native backlight device and acpi_video's
> > firmware acpi_video# backlight device. This relies on userspace preferring
> > firmware type backlight devices over native ones.
> >
> > Registering 2 backlight devices for a single display really is
> > undesirable, don't register the GPU's native backlight device when
> > another backlight device should be used.
> >
> > Changes in v2:
> > - To avoid linker errors when amdgpu is builtin and video_detect.c is in
> >   a module, select ACPI_VIDEO and its deps if ACPI && X86 are enabled.
> >   When these are not set, ACPI_VIDEO is disabled, ensuring the stubs
> >   from acpi/video.h will be used.
> >
> > Signed-off-by: Hans de Goede 
>
> Acked-by: Alex Deucher 

Actually, can you use dev_info for the messages below rather than
DRM_INFO?  That makes it easier to tell which GPU is affected in a
multi-GPU system.  With that changed,
Acked-by: Alex Deucher 

>
> > ---
> >  drivers/gpu/drm/Kconfig   | 6 ++
> >  drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 7 +++
> >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
> >  3 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index aaa7ad1f0614..d65119860760 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -258,6 +258,12 @@ config DRM_AMDGPU
> > select HWMON
> > select BACKLIGHT_CLASS_DEVICE
> > select INTERVAL_TREE
> > +   # amdgpu depends on ACPI_VIDEO when X86 and ACPI are both enabled
> > +   # for select to work, ACPI_VIDEO's dependencies must also be 
> > selected
> > +   select INPUT if ACPI && X86
> > +   select X86_PLATFORM_DEVICES if ACPI && X86
> > +   select ACPI_WMI if ACPI && X86
> > +   select ACPI_VIDEO if ACPI && X86
> > help
> >   Choose this option if you have a recent AMD Radeon graphics card.
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
> > b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> > index fa7421afb9a6..abf209e36fca 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> > @@ -26,6 +26,8 @@
> >
> >  #include 
> >
> > +#include 
> > +
> >  #include 
> >  #include 
> >  #include "amdgpu.h"
> > @@ -184,6 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct 
> > amdgpu_encoder *amdgpu_encode
> > if (!(adev->mode_info.firmware_flags & 
> > ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
> > return;
> >
> > +   if (!acpi_video_backlight_use_native()) {
> > +   DRM_INFO("Skipping amdgpu atom DIG backlight 
> > registration\n");
> > +   return;
> > +   }
> > +
> > pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), 
> > GFP_KERNEL);
> > if (!pdata) {
> > DRM_ERROR("Memory allocation failed\n");
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 5eb111d35793..3b03a95e59a8 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -86,6 +86,8 @@
> >  #include 
> >  #include 
> >
> > +#include 
> > +
> >  #include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
> >
> >  #include "dcn/dcn_1_0_offset.h"
> > @@ -4050,6 +4052,11 @@ amdgpu_dm_register_backlight_device(struct 
> > amdgpu_display_manager *dm)
> > amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
> > dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
> >
> > +   if (!acpi_video_backlight_use_native()) {
> > +   DRM_INFO("Skipping amdgpu DM backlight registration\n");
> > +   return;
> > +   }
> > +
> > props.max_brightness = AMDGPU_MAX_BL_LEVEL;
> > props.brightness = AMDGPU_MAX_BL_LEVEL;
> > props.type = BACKLIGHT_RAW;
> > --
> > 2.36.0
> >

Re: [Nouveau] [PATCH v2 04/29] drm/radeon: Don't register backlight when another backlight should be used

[Alex Deucher]

On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede  wrote:
>
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
> firmware acpi_video# backlight device. This relies on userspace preferring
> firmware type backlight devices over native ones.
>
> Registering 2 backlight devices for a single display really is
> undesirable, don't register the GPU's native backlight device when
> another backlight device should be used.
>
> Changes in v2:
> - To avoid linker errors when radeon is builtin and video_detect.c is in
>   a module, select ACPI_VIDEO and its deps if ACPI && X86 are enabled.
>   When these are not set, ACPI_VIDEO is disabled, ensuring the stubs
>   from acpi/video.h will be used.
>
> Signed-off-by: Hans de Goede 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/Kconfig | 6 ++
>  drivers/gpu/drm/radeon/atombios_encoders.c  | 7 +++
>  drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 7 +++
>  3 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index d65119860760..a07b76e06f84 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -234,6 +234,12 @@ config DRM_RADEON
> select HWMON
> select BACKLIGHT_CLASS_DEVICE
> select INTERVAL_TREE
> +   # radeon depends on ACPI_VIDEO when X86 and ACPI are both enabled
> +   # for select to work, ACPI_VIDEO's dependencies must also be selected
> +   select INPUT if ACPI && X86
> +   select X86_PLATFORM_DEVICES if ACPI && X86
> +   select ACPI_WMI if ACPI && X86
> +   select ACPI_VIDEO if ACPI && X86
> help
>   Choose this option if you have an ATI Radeon graphics card.  There
>   are both PCI and AGP versions.  You don't need to choose this to
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index c93040e60d04..958920230d6f 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -32,6 +32,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  #include "atom.h"
>  #include "radeon_atombios.h"
>  #include "radeon.h"
> @@ -209,6 +211,11 @@ void radeon_atom_backlight_init(struct radeon_encoder 
> *radeon_encoder,
> if (!(rdev->mode_info.firmware_flags & 
> ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
> return;
>
> +   if (!acpi_video_backlight_use_native()) {
> +   DRM_INFO("Skipping radeon atom DIG backlight registration\n");
> +   return;
> +   }
> +
> pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
> if (!pdata) {
> DRM_ERROR("Memory allocation failed\n");
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index 1a66fb969ee7..d24cedf20c47 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -33,6 +33,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  #include "radeon.h"
>  #include "radeon_asic.h"
>  #include "radeon_legacy_encoders.h"
> @@ -387,6 +389,11 @@ void radeon_legacy_backlight_init(struct radeon_encoder 
> *radeon_encoder,
> return;
>  #endif
>
> +   if (!acpi_video_backlight_use_native()) {
> +   DRM_INFO("Skipping radeon legacy LVDS backlight 
> registration\n");
> +   return;
> +   }
> +
> pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
> if (!pdata) {
> DRM_ERROR("Memory allocation failed\n");
> --
> 2.36.0
>

Re: [Nouveau] [PATCH v2 03/29] drm/amdgpu: Don't register backlight when another backlight should be used

[Alex Deucher]

On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede  wrote:
>
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
> firmware acpi_video# backlight device. This relies on userspace preferring
> firmware type backlight devices over native ones.
>
> Registering 2 backlight devices for a single display really is
> undesirable, don't register the GPU's native backlight device when
> another backlight device should be used.
>
> Changes in v2:
> - To avoid linker errors when amdgpu is builtin and video_detect.c is in
>   a module, select ACPI_VIDEO and its deps if ACPI && X86 are enabled.
>   When these are not set, ACPI_VIDEO is disabled, ensuring the stubs
>   from acpi/video.h will be used.
>
> Signed-off-by: Hans de Goede 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/Kconfig   | 6 ++
>  drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 7 +++
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
>  3 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index aaa7ad1f0614..d65119860760 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -258,6 +258,12 @@ config DRM_AMDGPU
> select HWMON
> select BACKLIGHT_CLASS_DEVICE
> select INTERVAL_TREE
> +   # amdgpu depends on ACPI_VIDEO when X86 and ACPI are both enabled
> +   # for select to work, ACPI_VIDEO's dependencies must also be selected
> +   select INPUT if ACPI && X86
> +   select X86_PLATFORM_DEVICES if ACPI && X86
> +   select ACPI_WMI if ACPI && X86
> +   select ACPI_VIDEO if ACPI && X86
> help
>   Choose this option if you have a recent AMD Radeon graphics card.
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> index fa7421afb9a6..abf209e36fca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> @@ -26,6 +26,8 @@
>
>  #include 
>
> +#include 
> +
>  #include 
>  #include 
>  #include "amdgpu.h"
> @@ -184,6 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct 
> amdgpu_encoder *amdgpu_encode
> if (!(adev->mode_info.firmware_flags & 
> ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
> return;
>
> +   if (!acpi_video_backlight_use_native()) {
> +   DRM_INFO("Skipping amdgpu atom DIG backlight registration\n");
> +   return;
> +   }
> +
> pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
> if (!pdata) {
> DRM_ERROR("Memory allocation failed\n");
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5eb111d35793..3b03a95e59a8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -86,6 +86,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  #include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
>
>  #include "dcn/dcn_1_0_offset.h"
> @@ -4050,6 +4052,11 @@ amdgpu_dm_register_backlight_device(struct 
> amdgpu_display_manager *dm)
> amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
> dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
>
> +   if (!acpi_video_backlight_use_native()) {
> +   DRM_INFO("Skipping amdgpu DM backlight registration\n");
> +   return;
> +   }
> +
> props.max_brightness = AMDGPU_MAX_BL_LEVEL;
> props.brightness = AMDGPU_MAX_BL_LEVEL;
> props.type = BACKLIGHT_RAW;
> --
> 2.36.0
>

Re: [Nouveau] [RESEND RFC 17/18] drm/radeon: Drop legacy MST support

[Alex Deucher]

On Tue, Jun 7, 2022 at 3:39 PM Lyude Paul  wrote:
>
> Right now, radeon is technically the only non-atomic driver still making
> use of the MST helpers - and thus the final user of all of the legacy MST
> helpers. Originally I was going to look into seeing if we could move legacy
> MST into the radeon driver itself, however:
>
> * SI and CIK both can use amdgpu, which still supports MST
> * It currently doesn't work according to my own testing. I'm sure with some
>   troubleshooting we could likely fix it, but that brings me to point #2:
> * It was never actually enabled by default, and is still marked as
>   experimental in the module parameter description
> * If people were using it, someone probably would have probably seen a bug
>   report about how it is currently not functional by now. That certainly
>   doesn't appear to be the case, since before getting access to my own
>   hardware I had to go out of my way to try finding someone to help test
>   whether this legacy MST code even works - even amongst AMD employees.
> * Getting rid of this code and only having atomic versions of the MST
>   helpers to maintain is likely going to be a lot easier in the long run,
>   and will make it a lot easier for others contributing to this code to
>   follow along with what's happening.
>
> FWIW - if anyone still wants this code to be in the tree and has a good
> idea of how to support this without needing to maintain the legacy MST
> helpers (trying to move them would probably be acceptable), I'm happy to
> suggestions. But my hope is that we can just drop this code and forget
> about it. I've already run this idea by Harry Wentland and Alex Deucher a
> few times as well.
>
> Signed-off-by: Lyude Paul 
> Cc: Wayne Lin 
> Cc: Ville Syrjälä 
> Cc: Fangzhi Zuo 
> Cc: Jani Nikula 
> Cc: Imre Deak 
> Cc: Daniel Vetter 
> Cc: Sean Paul 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/Makefile|   2 +-
>  drivers/gpu/drm/radeon/atombios_crtc.c |  11 +-
>  drivers/gpu/drm/radeon/atombios_encoders.c |  59 --
>  drivers/gpu/drm/radeon/radeon_atombios.c   |   2 -
>  drivers/gpu/drm/radeon/radeon_connectors.c |  61 +-
>  drivers/gpu/drm/radeon/radeon_device.c |   1 -
>  drivers/gpu/drm/radeon/radeon_dp_mst.c | 778 -
>  drivers/gpu/drm/radeon/radeon_drv.c|   4 -
>  drivers/gpu/drm/radeon/radeon_encoders.c   |  14 +-
>  drivers/gpu/drm/radeon/radeon_irq_kms.c|  10 +-
>  drivers/gpu/drm/radeon/radeon_mode.h   |  40 --
>  11 files changed, 7 insertions(+), 975 deletions(-)
>  delete mode 100644 drivers/gpu/drm/radeon/radeon_dp_mst.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index ea5380e24c3c..b783ab39a075 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -49,7 +49,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
> trinity_dpm.o \
> trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
> ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o \
> -   radeon_sync.o radeon_audio.o radeon_dp_auxch.o radeon_dp_mst.o
> +   radeon_sync.o radeon_audio.o radeon_dp_auxch.o
>
>  radeon-$(CONFIG_MMU_NOTIFIER) += radeon_mn.o
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index c94e429e75f9..e27da31d4f62 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -616,13 +616,6 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> }
> }
>
> -   if (radeon_encoder->is_mst_encoder) {
> -   struct radeon_encoder_mst *mst_enc = radeon_encoder->enc_priv;
> -   struct radeon_connector_atom_dig *dig_connector = 
> mst_enc->connector->con_priv;
> -
> -   dp_clock = dig_connector->dp_clock;
> -   }
> -
> /* use recommended ref_div for ss */
> if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
> if (radeon_crtc->ss_enabled) {
> @@ -971,9 +964,7 @@ static bool atombios_crtc_prepare_pll(struct drm_crtc 
> *crtc, struct drm_display_
> radeon_crtc->bpc = 8;
> radeon_crtc->ss_enabled = false;
>
> -   if (radeon_encoder->is_mst_encoder) {
> -   radeon_dp_mst_prepare_pll(crtc, mode);
> -   } else if ((radeon_encoder->active_device & (ATOM_DEVICE_LCD_SUPPORT 
> | ATOM_DEVICE_DFP_SUPPORT)) ||
> +   if ((radeon_encoder->active_device & (ATOM_DEVICE_LCD_SUPPORT | 
> ATOM_DEVICE_DFP_SUPPORT))

Re: [Nouveau] Per file OOM badness

[Alex Deucher]

+ dri-devel

On Tue, May 31, 2022 at 6:00 AM Christian König
 wrote:
>
> Hello everyone,
>
> To summarize the issue I'm trying to address here: Processes can allocate
> resources through a file descriptor without being held responsible for it.
>
> Especially for the DRM graphics driver subsystem this is rather
> problematic. Modern games tend to allocate huge amounts of system memory
> through the DRM drivers to make it accessible to GPU rendering.
>
> But even outside of the DRM subsystem this problem exists and it is
> trivial to exploit. See the following simple example of
> using memfd_create():
>
>  fd = memfd_create("test", 0);
>  while (1)
>  write(fd, page, 4096);
>
> Compile this and you can bring down any standard desktop system within
> seconds.
>
> The background is that the OOM killer will kill every processes in the
> system, but just not the one which holds the only reference to the memory
> allocated by the memfd.
>
> Those problems where brought up on the mailing list multiple times now
> [1][2][3], but without any final conclusion how to address them. Since
> file descriptors are considered shared the process can not directly held
> accountable for allocations made through them. Additional to that file
> descriptors can also easily move between processes as well.
>
> So what this patch set does is to instead of trying to account the
> allocated memory to a specific process it adds a callback to struct
> file_operations which the OOM killer can use to query the specific OOM
> badness of this file reference. This badness is then divided by the
> file_count, so that every process using a shmem file, DMA-buf or DRM
> driver will get it's equal amount of OOM badness.
>
> Callbacks are then implemented for the two core users (memfd and DMA-buf)
> as well as 72 DRM based graphics drivers.
>
> The result is that the OOM killer can now much better judge if a process
> is worth killing to free up memory. Resulting a quite a bit better system
> stability in OOM situations, especially while running games.
>
> The only other possibility I can see would be to change the accounting of
> resources whenever references to the file structure change, but this would
> mean quite some additional overhead for a rather common operation.
>
> Additionally I think trying to limit device driver allocations using
> cgroups is orthogonal to this effort. While cgroups is very useful, it
> works on per process limits and tries to enforce a collaborative model on
> memory management while the OOM killer enforces a competitive model.
>
> Please comment and/or review, we have that problem flying around for years
> now and are not at a point where we finally need to find a solution for
> this.
>
> Regards,
> Christian.
>
> [1] 
> https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html
> [2] https://lkml.org/lkml/2018/1/18/543
> [3] https://lkml.org/lkml/2021/2/4/799
>
>

Re: [Nouveau] [PATCH v5 3/7] PCI: Drop the `is_thunderbolt` attribute from PCI core

[Alex Deucher]

On Thu, Feb 24, 2022 at 8:23 PM Bjorn Helgaas  wrote:
>
> On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> > The `is_thunderbolt` attribute originally had a well defined list of
> > quirks that it existed for, but it has been overloaded with more
> > meaning.
> >
> > Instead use the driver core removable attribute to indicate the
> > detail a device is attached to a thunderbolt or USB4 chain.
> >
> > Signed-off-by: Mario Limonciello 
> > ---
> >  drivers/pci/probe.c   | 2 +-
> >  drivers/platform/x86/apple-gmux.c | 2 +-
> >  include/linux/pci.h   | 5 ++---
> >  3 files changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 17a969942d37..1b752d425c47 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -1584,7 +1584,7 @@ static void set_pcie_thunderbolt(struct pci_dev *dev)
> >   /* Is the device part of a Thunderbolt controller? */
> >   vsec = pci_find_vsec_capability(dev, PCI_VENDOR_ID_INTEL, 
> > PCI_VSEC_ID_INTEL_TBT);
> >   if (vsec)
> > - dev->is_thunderbolt = 1;
> > + dev->external_facing = true;
>
> I assume there's a spec for the PCI_VSEC_ID_INTEL_TBT Capability.  Is
> that public?  Does the spec say that a device with that capability
> must be external-facing?
>
> Even if it's not public, I think a citation (name, revision, section)
> would be useful.
>
> >  }
> >
> >  static void set_pcie_untrusted(struct pci_dev *dev)
> > diff --git a/drivers/platform/x86/apple-gmux.c 
> > b/drivers/platform/x86/apple-gmux.c
> > index 57553f9b4d1d..da0c39b0 100644
> > --- a/drivers/platform/x86/apple-gmux.c
> > +++ b/drivers/platform/x86/apple-gmux.c
> > @@ -596,7 +596,7 @@ static int gmux_resume(struct device *dev)
> >
> >  static int is_thunderbolt(struct device *dev, void *data)
> >  {
> > - return to_pci_dev(dev)->is_thunderbolt;
> > + return to_pci_dev(dev)->external_facing;
>
> This looks ... sort of weird.  I don't know anything about
> apple-gmux.c, so I guess I don't care, but assuming any
> external-facing device must be a Thunderbolt device seems like a
> stretch.
>
> Ugh.  This is used via "bus_for_each_dev(_bus_type)", which means
> it's not hotplug-safe.  I'm sure we "know" implicitly that hotplug
> isn't an issue in apple-gmux, but it's better not to have examples
> that get copied to places where it *is* an issue.
>
> >  }
> >
> >  static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index 1e5b769e42fc..d9719eb14654 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -442,7 +442,6 @@ struct pci_dev {
> >   unsigned intis_virtfn:1;
> >   unsigned intis_hotplug_bridge:1;
> >   unsigned intshpc_managed:1; /* SHPC owned by shpchp */
> > - unsigned intis_thunderbolt:1;   /* Thunderbolt controller */
> >   unsigned intno_cmd_complete:1;  /* Lies about command 
> > completed events */
> >
> >   /*
> > @@ -2447,11 +2446,11 @@ static inline bool 
> > pci_is_thunderbolt_attached(struct pci_dev *pdev)
> >  {
> >   struct pci_dev *parent = pdev;
> >
> > - if (pdev->is_thunderbolt)
> > + if (dev_is_removable(>dev))
> >   return true;
> >
> >   while ((parent = pci_upstream_bridge(parent)))
> > - if (parent->is_thunderbolt)
> > + if (dev_is_removable(>dev))
> >   return true;
>
> I don't get this.  Plain old PCI devices can be removable, too.
>
> pci_is_thunderbolt_attached() is only used by GPU drivers.  What
> property of Thunderbolt do they care about?
>
> nouveau_vga_init() and radeon_device_init() use it to decide to
> register with vga_switcheroo.  So maybe that's something to do with
> removability?  Of course, that's not specific to Thunderbolt, because
> garden-variety PCIe devices are removable.
>
> amdgpu_driver_load_kms() and radeon_driver_load_kms() apparently use
> it for something related to power control.  I don't know what the
> Thunderbolt connection is.

For GPU drivers, we need to determine which dGPU on the system has
d3cold control via ACPI and which GPU would use a mux for display
switching between the iGPU and the dGPU for hybrid graphics platforms
(e.g., iGPU + dGPU built into a laptop or all-in-one PC).  The dGPU
built into the platform would be the one we want to use for mux
switching and ACPI power control.  You would not want that for the
dGPU connected via thunderbolt (or some other hot pluggable
interface).  I had suggested that we could check if there is an ACPI
device associated with the dGPU and use that to determine this, but I
think someone brought up a case where that didn't work.  We need to
know whether the dGPU uses platform power control to determine whether
the driver should let the platform manage the power state via ACPI or
if the driver should do it (e.g., for 

Re: [Nouveau] [PATCH v4 00/10] Overhaul `is_thunderbolt`

[Alex Deucher]

On Wed, Feb 16, 2022 at 9:34 AM Mika Westerberg
 wrote:
>
> Hi all,
>
> On Tue, Feb 15, 2022 at 01:07:00PM -0600, Limonciello, Mario wrote:
> > On 2/15/2022 01:29, Lukas Wunner wrote:
> > > On Mon, Feb 14, 2022 at 06:01:50PM -0600, Mario Limonciello wrote:
> > > >   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  2 +-
> > > >   drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c  |  2 +-
> > > >   drivers/gpu/drm/nouveau/nouveau_vga.c   |  4 +-
> > > >   drivers/gpu/drm/radeon/radeon_device.c  |  4 +-
> > > >   drivers/gpu/drm/radeon/radeon_kms.c |  2 +-
> > > >   drivers/pci/hotplug/pciehp_hpc.c|  6 +-
> > > >   drivers/pci/pci-acpi.c  | 15 -
> > > >   drivers/pci/pci.c   | 17 +++--
> > > >   drivers/pci/probe.c | 52 ++-
> > > >   drivers/pci/quirks.c| 84 +
> > > >   drivers/platform/x86/apple-gmux.c   |  2 +-
> > > >   drivers/thunderbolt/nhi.h   |  2 -
> > > >   include/linux/pci.h | 25 +---
> > > >   include/linux/pci_ids.h |  3 +
> > > >   14 files changed, 173 insertions(+), 47 deletions(-)
> > >
> > > That's an awful lot of additional LoC for what is primarily
> > > a refactoring job with the intent to simplify things.
> >
> > You may recall the first version of this series was just for adding
> > USB4 matches to the existing code paths, and that's when it was noted
> > that is_thunderbolt is a bit overloaded.
> >
> > >
> > > Honestly this looks like an attempt to fix something that
> > > isn't broken.  Specifically, the is_thunderbolt bit apparently
> > > can't be removed without adding new bits to struct pci_dev.
> > > Not sure if that can be called progress. >
> > > Thanks,
> > >
> > > Lukas
> >
> > Within this series there are two new material patches; setting up root ports
> > for both integrated and discrete USB4 controllers to behave well with all
> > the existing drivers that rely upon a hint of how they're connected to
> > configure devices differently.
> >
> > If y'all collectively prefer this direction to not refactor is_thunderbolt
> > and push into quirks, a simpler version of this series would be to leave all
> > the quirks in place, just drop dev->is_thunderbolt, and set
> > dev->external_facing on all 3 cases:
> >
> > * Intel TBT controller
> > * USB4 integrated PCIe tunneling root port/XHCI tunneling root port
> > * USB4 disctete PCIe tunneling root port/XHCI tunneling root port
> >
> > All the other drivers and symbols can stay the same then.
>
> If I understand correctly the original intention of this patch series is
> to be able to differentiate whether the device is "permanently"
> connected to the motherboard, or it is connected over some hot-pluggable
> bus (PCIe, USB, USB4 for example but I'm sure there are other buses that
> fit into this picture too). Specifically this is needed for discrete
> GPUs because of power management differences or so (please correct me if
> I'm mistaken).
>
> If we set the is_thunderbolt debate aside and concentrate on that issue,
> I think the way to do this is to check whether the root port the GPU is
> connected to has an ACPI power resource (returned from _PR3() method).
> IF it is present then most likely the platform has provided all the
> necessary wiring to move the GPU into D3cold (and the BIOS knows this).
> If it is not present then the device cannot even go into D3cold as there
> is not means to power of the device in PCIe spec.
>
> Perhaps we can simply use pci_pr3_present() here as nouveau is already
> doing? Granted it is not too elegant solution either but better than
> using is_thunderbolt IMHO. Since this seem to be common for many GPUs,
> perhaps we can have a helper in DRM core that handles this.

The tricky part is that there were AMD and NVIDIA specific proprietary
_PR3-like ACPI methods (plus whatever Apple did) prior to GPU power
control standardizing on _PR3.  Currently those methods are handled in
the drivers directly, sort of tangled up with vga_switcheroo.  I think
ideally that logic would move to the ACPI core and be handled the same
way as _PR3, but I'm not sure how well that would work because of the
various bios date checks around _PR3 and the lack of general _PR3
support in those older platforms.  So I think we still need some sort
of "is this soldered in" check.

Alex


>
> Then going back to is_thunderbolt debate :) I really don't think the
> drivers should care whether they are connected over a tunnel or not.
> They should work regardless of the underlying transport of the native
> protocol. They should also be prepared for the fact that the hardware
> can vanish under them at any point (e.g user unplugs the device). For
> this reason I don't really like to see is_thunderbolt to be used more
> and prefer to get rid if it completely if possible at all. If there is
> still need to differentiate whether the device can be hot-removed or
> not, I think 

Re: [Nouveau] [PATCH] drm/nouveau/acr: Fix undefined behavior in nvkm_acr_hsfw_load_bl()

[Alex Deucher]

On Fri, Jan 28, 2022 at 2:58 PM Karol Herbst  wrote:
>
> On Fri, Jan 28, 2022 at 8:54 PM Alex Deucher  wrote:
> >
> > On Fri, Jan 28, 2022 at 2:20 PM Lyude Paul  wrote:
> > >
> > > Sigh-thank you for catching this - I had totally forgot about the umn.edu 
> > > ban.
> > > I pushed this already but I will go ahead and send a revert for this 
> > > patch.
> > > Will cc you on it as well.
> >
> > This seems short-sighted.  If the patch is valid I see no reason to
> > not accept it.  I'm not trying to downplay the mess umn got into, but
> > as long as the patch is well scrutinized and fixes a valid issue, it
> > should be applied rather than leaving potential bugs in place.
> >
> > Alex
> >
>
> Even though knowing that malicious code can be introduced via
> perfectly fine looking patches, and sometimes one will never spot the
> problem, this patch isn't all that bad tbh.
>
> So should we reject patches out of "policies" or should we just be
> extra careful? But not addressing the concerns as Greg pointed out is
> also kind of a bad move, but also not knowing what the state of
> resolving this mess is anyway.

I think if the umn mess taught us anything, it's the need for more
careful scrutiny.  But I certainly don't have the time to retype every
valid patch if it comes from a umn source.  There are also ethical
implications to that as well.  You didn't actually write the patch.

Alex

>
> >
> > >
> > > On Fri, 2022-01-28 at 11:18 +0100, Greg KH wrote:
> > > > On Tue, Jan 25, 2022 at 12:58:55AM +0800, Zhou Qingyang wrote:
> > > > > In nvkm_acr_hsfw_load_bl(), the return value of kmalloc() is directly
> > > > > passed to memcpy(), which could lead to undefined behavior on failure
> > > > > of kmalloc().
> > > > >
> > > > > Fix this bug by using kmemdup() instead of kmalloc()+memcpy().
> > > > >
> > > > > This bug was found by a static analyzer.
> > > > >
> > > > > Builds with 'make allyesconfig' show no new warnings,
> > > > > and our static analyzer no longer warns about this code.
> > > > >
> > > > > Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace
> > > > > "secure boot"")
> > > > > Signed-off-by: Zhou Qingyang 
> > > > > ---
> > > > > The analysis employs differential checking to identify inconsistent
> > > > > security operations (e.g., checks or kfrees) between two code paths
> > > > > and confirms that the inconsistent operations are not recovered in the
> > > > > current function or the callers, so they constitute bugs.
> > > > >
> > > > > Note that, as a bug found by static analysis, it can be a false
> > > > > positive or hard to trigger. Multiple researchers have cross-reviewed
> > > > > the bug.
> > > > >
> > > > >  drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c | 9 +
> > > > >  1 file changed, 5 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> > > > > b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> > > > > index 667fa016496e..a6ea89a5d51a 100644
> > > > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> > > > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> > > > > @@ -142,11 +142,12 @@ nvkm_acr_hsfw_load_bl(struct nvkm_acr *acr, 
> > > > > const
> > > > > char *name, int ver,
> > > > >
> > > > > hsfw->imem_size = desc->code_size;
> > > > > hsfw->imem_tag = desc->start_tag;
> > > > > -   hsfw->imem = kmalloc(desc->code_size, GFP_KERNEL);
> > > > > -   memcpy(hsfw->imem, data + desc->code_off, desc->code_size);
> > > > > -
> > > > > +   hsfw->imem = kmemdup(data + desc->code_off, desc->code_size,
> > > > > GFP_KERNEL);
> > > > > nvkm_firmware_put(fw);
> > > > > -   return 0;
> > > > > +   if (!hsfw->imem)
> > > > > +   return -ENOMEM;
> > > > > +   else
> > > > > +   return 0;
> > > > >  }
> > > > >
> > > > >  int
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
> > > > As stated before, umn.edu is still not allowed to contribute to the
> > > > Linux kernel.  Please work with your administration to resolve this
> > > > issue.
> > > >
> > >
> > > --
> > > Cheers,
> > >  Lyude Paul (she/her)
> > >  Software Engineer at Red Hat
> > >
> >
>

Re: [Nouveau] [PATCH] drm/nouveau/acr: Fix undefined behavior in nvkm_acr_hsfw_load_bl()

[Alex Deucher]

On Fri, Jan 28, 2022 at 2:20 PM Lyude Paul  wrote:
>
> Sigh-thank you for catching this - I had totally forgot about the umn.edu ban.
> I pushed this already but I will go ahead and send a revert for this patch.
> Will cc you on it as well.

This seems short-sighted.  If the patch is valid I see no reason to
not accept it.  I'm not trying to downplay the mess umn got into, but
as long as the patch is well scrutinized and fixes a valid issue, it
should be applied rather than leaving potential bugs in place.

Alex


>
> On Fri, 2022-01-28 at 11:18 +0100, Greg KH wrote:
> > On Tue, Jan 25, 2022 at 12:58:55AM +0800, Zhou Qingyang wrote:
> > > In nvkm_acr_hsfw_load_bl(), the return value of kmalloc() is directly
> > > passed to memcpy(), which could lead to undefined behavior on failure
> > > of kmalloc().
> > >
> > > Fix this bug by using kmemdup() instead of kmalloc()+memcpy().
> > >
> > > This bug was found by a static analyzer.
> > >
> > > Builds with 'make allyesconfig' show no new warnings,
> > > and our static analyzer no longer warns about this code.
> > >
> > > Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace
> > > "secure boot"")
> > > Signed-off-by: Zhou Qingyang 
> > > ---
> > > The analysis employs differential checking to identify inconsistent
> > > security operations (e.g., checks or kfrees) between two code paths
> > > and confirms that the inconsistent operations are not recovered in the
> > > current function or the callers, so they constitute bugs.
> > >
> > > Note that, as a bug found by static analysis, it can be a false
> > > positive or hard to trigger. Multiple researchers have cross-reviewed
> > > the bug.
> > >
> > >  drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c | 9 +
> > >  1 file changed, 5 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> > > b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> > > index 667fa016496e..a6ea89a5d51a 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> > > @@ -142,11 +142,12 @@ nvkm_acr_hsfw_load_bl(struct nvkm_acr *acr, const
> > > char *name, int ver,
> > >
> > > hsfw->imem_size = desc->code_size;
> > > hsfw->imem_tag = desc->start_tag;
> > > -   hsfw->imem = kmalloc(desc->code_size, GFP_KERNEL);
> > > -   memcpy(hsfw->imem, data + desc->code_off, desc->code_size);
> > > -
> > > +   hsfw->imem = kmemdup(data + desc->code_off, desc->code_size,
> > > GFP_KERNEL);
> > > nvkm_firmware_put(fw);
> > > -   return 0;
> > > +   if (!hsfw->imem)
> > > +   return -ENOMEM;
> > > +   else
> > > +   return 0;
> > >  }
> > >
> > >  int
> > > --
> > > 2.25.1
> > >
> >
> > As stated before, umn.edu is still not allowed to contribute to the
> > Linux kernel.  Please work with your administration to resolve this
> > issue.
> >
>
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
>

Re: [Nouveau] [PATCH] drm/nouveau: fix dma_address check for CPU/GPU sync

[Alex Deucher]

On Tue, Jun 22, 2021 at 5:32 AM Christian König
 wrote:
>
> Ping? Does anybody wants to give me an rb or acked-by?
>
> AGP is basically broken on nouveu without this.

Looks correct to me.
Acked-by: Alex Deucher 

>
> Christian.
>
> Am 14.06.21 um 13:05 schrieb Christian König:
> > AGP for example doesn't have a dma_address array.
> >
> > Signed-off-by: Christian König 
> > ---
> >   drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index 3e09df0472ce..170aba99a110 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -546,7 +546,7 @@ nouveau_bo_sync_for_device(struct nouveau_bo *nvbo)
> >   struct ttm_tt *ttm_dma = (struct ttm_tt *)nvbo->bo.ttm;
> >   int i, j;
> >
> > - if (!ttm_dma)
> > + if (!ttm_dma || !ttm_dma->dma_address)
> >   return;
> >   if (!ttm_dma->pages) {
> >   NV_DEBUG(drm, "ttm_dma 0x%p: pages NULL\n", ttm_dma);
> > @@ -582,7 +582,7 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
> >   struct ttm_tt *ttm_dma = (struct ttm_tt *)nvbo->bo.ttm;
> >   int i, j;
> >
> > - if (!ttm_dma)
> > + if (!ttm_dma || !ttm_dma->dma_address)
> >   return;
> >   if (!ttm_dma->pages) {
> >   NV_DEBUG(drm, "ttm_dma 0x%p: pages NULL\n", ttm_dma);
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 4/8] drm/radeon: Implement mmap as GEM object function

[Alex Deucher]

On Tue, Apr 6, 2021 at 5:09 AM Thomas Zimmermann  wrote:
>
> Moving the driver-specific mmap code into a GEM object function allows
> for using DRM helpers for various mmap callbacks.
>
> This change also allows to support prime-based mmap via DRM's helper
> drm_gem_prime_mmap().
>
> Permission checks are implemented by drm_gem_mmap(), with an additional
> check for radeon_ttm_tt_has_userptr() in the GEM object function. The
> function radeon_verify_access() is now unused and has thus been removed.
>
> As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
> implemented in amdgpu's GEM code.

s/amdgpu/radeon/

Alex

>
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/radeon/radeon_drv.c |  3 +-
>  drivers/gpu/drm/radeon/radeon_gem.c | 52 +++
>  drivers/gpu/drm/radeon/radeon_ttm.c | 65 -
>  drivers/gpu/drm/radeon/radeon_ttm.h |  1 -
>  4 files changed, 54 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index efeb115ae70e..4039b6d71aa2 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -557,7 +557,7 @@ static const struct file_operations 
> radeon_driver_kms_fops = {
> .open = drm_open,
> .release = drm_release,
> .unlocked_ioctl = radeon_drm_ioctl,
> -   .mmap = radeon_mmap,
> +   .mmap = drm_gem_mmap,
> .poll = drm_poll,
> .read = drm_read,
>  #ifdef CONFIG_COMPAT
> @@ -632,6 +632,7 @@ static const struct drm_driver kms_driver = {
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
> +   .gem_prime_mmap = drm_gem_prime_mmap,
>
> .name = DRIVER_NAME,
> .desc = DRIVER_DESC,
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index 05ea2f39f626..71e8737bce01 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -44,6 +44,42 @@ void radeon_gem_prime_unpin(struct drm_gem_object *obj);
>
>  const struct drm_gem_object_funcs radeon_gem_object_funcs;
>
> +static vm_fault_t radeon_ttm_fault(struct vm_fault *vmf)
> +{
> +   struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
> +   struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
> +   vm_fault_t ret;
> +
> +   down_read(>pm.mclk_lock);
> +
> +   ret = ttm_bo_vm_reserve(bo, vmf);
> +   if (ret)
> +   goto unlock_mclk;
> +
> +   ret = radeon_bo_fault_reserve_notify(bo);
> +   if (ret)
> +   goto unlock_resv;
> +
> +   ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
> +  TTM_BO_VM_NUM_PREFAULT, 1);
> +   if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> +   goto unlock_mclk;
> +
> +unlock_resv:
> +   dma_resv_unlock(bo->base.resv);
> +
> +unlock_mclk:
> +   up_read(>pm.mclk_lock);
> +   return ret;
> +}
> +
> +static const struct vm_operations_struct radeon_ttm_vm_ops = {
> +   .fault = radeon_ttm_fault,
> +   .open = ttm_bo_vm_open,
> +   .close = ttm_bo_vm_close,
> +   .access = ttm_bo_vm_access
> +};
> +
>  static void radeon_gem_object_free(struct drm_gem_object *gobj)
>  {
> struct radeon_bo *robj = gem_to_radeon_bo(gobj);
> @@ -226,6 +262,20 @@ static int radeon_gem_handle_lockup(struct radeon_device 
> *rdev, int r)
> return r;
>  }
>
> +static int radeon_gem_object_mmap(struct drm_gem_object *obj, struct 
> vm_area_struct *vma)
> +{
> +   struct radeon_bo *bo = gem_to_radeon_bo(obj);
> +   struct radeon_device *rdev = radeon_get_rdev(bo->tbo.bdev);
> +
> +   if (!rdev)
> +   return -EINVAL;
> +
> +   if (radeon_ttm_tt_has_userptr(rdev, bo->tbo.ttm))
> +   return -EPERM;
> +
> +   return drm_gem_ttm_mmap(obj, vma);
> +}
> +
>  const struct drm_gem_object_funcs radeon_gem_object_funcs = {
> .free = radeon_gem_object_free,
> .open = radeon_gem_object_open,
> @@ -236,6 +286,8 @@ const struct drm_gem_object_funcs radeon_gem_object_funcs 
> = {
> .get_sg_table = radeon_gem_prime_get_sg_table,
> .vmap = drm_gem_ttm_vmap,
> .vunmap = drm_gem_ttm_vunmap,
> +   .mmap = radeon_gem_object_mmap,
> +   .vm_ops = _ttm_vm_ops,
>  };
>
>  /*
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 476ce9c24b9f..a5ce43a909a2 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -136,17 +136,6 @@ static void radeon_evict_flags(struct ttm_buffer_object 
> *bo,
> *placement = rbo->placement;
>  }
>
> -static int radeon_verify_access(struct ttm_buffer_object *bo, struct file 
> *filp)
> -{
> -   struct 

Re: [Nouveau] [PATCH 0/3] drm/ttm: constify static vm_operations_structs

[Alex Deucher]

On Wed, Feb 10, 2021 at 8:14 AM Daniel Vetter  wrote:
>
> On Wed, Feb 10, 2021 at 08:45:56AM +0100, Christian König wrote:
> > Reviewed-by: Christian König  for the series.
>
> Smash it into -misc?

@Christian Koenig did these ever land?  I don't see them in drm-misc.

Alex

> -Daniel
>
> >
> > Am 10.02.21 um 00:48 schrieb Rikard Falkeborn:
> > > Constify a few static vm_operations_struct that are never modified. Their
> > > only usage is to assign their address to the vm_ops field in the
> > > vm_area_struct, which is a pointer to const vm_operations_struct. Make 
> > > them
> > > const to allow the compiler to put them in read-only memory.
> > >
> > > With this series applied, all static struct vm_operations_struct in the
> > > kernel tree are const.
> > >
> > > Rikard Falkeborn (3):
> > >drm/amdgpu/ttm: constify static vm_operations_struct
> > >drm/radeon/ttm: constify static vm_operations_struct
> > >drm/nouveau/ttm: constify static vm_operations_struct
> > >
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
> > >   drivers/gpu/drm/nouveau/nouveau_ttm.c   | 2 +-
> > >   drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
> > >   3 files changed, 3 insertions(+), 3 deletions(-)
> > >
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces

[Alex Deucher]

On Wed, Dec 2, 2020 at 3:53 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 02.12.20 um 09:43 schrieb Christian König:
> > Am 02.12.20 um 08:59 schrieb Thomas Zimmermann:
> >> Hi
> >>
> >> Am 01.12.20 um 11:40 schrieb Christian König:
> >>> Reviewed-by: Christian König  on patch #1
> >>> and #15.
> >>>
> >>> Acked-by: Christian König  on patch #2 and
> >>> #16.
> >>
> >> Could you add these patches to the AMD tree?
> >
> > Alex is usually the one who picks such stuff up.
> >
> > But when people send out patch sets which mix changes from different
> > drivers it is more common to push them through drm-misc-next.
>
> I'm OK with drm-misc-next. I just don't want to add too many merge
> conflicts in your side.

Yeah, it doesn't matter to me.  I assumed you wanted to land this
whole series so you could move forward with further cleanups.  If we
merge via different trees, you'll have to wait for all of this to come
together again in drm-next.

Alex


>
> Best regards
> Thomas
>
> >
> > Regards,
> > Christian.
> >
> >>
> >> Best regards
> >> Thomas
> >>
> >>>
> >>> Regards,
> >>> Christian.
> >>>
> >>> Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:
> >>>> Adhere to kernel coding style.
> >>>>
> >>>> Signed-off-by: Thomas Zimmermann 
> >>>> Acked-by: Alex Deucher 
> >>>> Acked-by: Sam Ravnborg 
> >>>> Cc: Alex Deucher 
> >>>> Cc: Christian König 
> >>>> ---
> >>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
> >>>>   1 file changed, 3 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>>> index 5f304425c948..da23c0f21311 100644
> >>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>>> @@ -4922,8 +4922,8 @@ pci_ers_result_t
> >>>> amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta
> >>>>   case pci_channel_io_normal:
> >>>>   return PCI_ERS_RESULT_CAN_RECOVER;
> >>>>   /* Fatal error, prepare for slot reset */
> >>>> -case pci_channel_io_frozen:
> >>>> -/*
> >>>> +case pci_channel_io_frozen:
> >>>> +/*
> >>>>* Cancel and wait for all TDRs in progress if failing to
> >>>>* set  adev->in_gpu_reset in amdgpu_device_lock_adev
> >>>>*
> >>>> @@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct
> >>>> pci_dev *pdev)
> >>>>   goto out;
> >>>>   }
> >>>> -adev->in_pci_err_recovery = true;
> >>>> +adev->in_pci_err_recovery = true;
> >>>>   r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
> >>>>   adev->in_pci_err_recovery = false;
> >>>>   if (r)
> >>>
> >>
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 11/15] drm/radeon: Remove references to struct drm_device.pdev

[Alex Deucher]

On Tue, Nov 24, 2020 at 6:39 AM Thomas Zimmermann  wrote:
>
> Using struct drm_device.pdev is deprecated. Convert radeon to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Alex Deucher 
> Cc: Christian König 

There are a few unrelated whitespace changes.  Other than that, patch is:
Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/atombios_encoders.c|  6 +-
>  drivers/gpu/drm/radeon/r100.c | 27 +++---
>  drivers/gpu/drm/radeon/radeon.h   | 32 +++
>  drivers/gpu/drm/radeon/radeon_atombios.c  | 89 ++-
>  drivers/gpu/drm/radeon/radeon_bios.c  |  6 +-
>  drivers/gpu/drm/radeon/radeon_combios.c   | 55 ++--
>  drivers/gpu/drm/radeon/radeon_cs.c|  3 +-
>  drivers/gpu/drm/radeon/radeon_device.c| 17 ++--
>  drivers/gpu/drm/radeon/radeon_display.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_drv.c   |  3 +-
>  drivers/gpu/drm/radeon/radeon_fb.c|  2 +-
>  drivers/gpu/drm/radeon/radeon_gem.c   |  6 +-
>  drivers/gpu/drm/radeon/radeon_i2c.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_irq_kms.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_kms.c   | 20 ++---
>  .../gpu/drm/radeon/radeon_legacy_encoders.c   |  6 +-
>  drivers/gpu/drm/radeon/rs780_dpm.c|  7 +-
>  17 files changed, 144 insertions(+), 141 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index cc5ee1b3af84..a9ae8b6c5991 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -2065,9 +2065,9 @@ atombios_apply_encoder_quirks(struct drm_encoder 
> *encoder,
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
>
> /* Funky macbooks */
> -   if ((dev->pdev->device == 0x71C5) &&
> -   (dev->pdev->subsystem_vendor == 0x106b) &&
> -   (dev->pdev->subsystem_device == 0x0080)) {
> +   if ((rdev->pdev->device == 0x71C5) &&
> +   (rdev->pdev->subsystem_vendor == 0x106b) &&
> +   (rdev->pdev->subsystem_device == 0x0080)) {
> if (radeon_encoder->devices & ATOM_DEVICE_LCD1_SUPPORT) {
> uint32_t lvtma_bit_depth_control = 
> RREG32(AVIVO_LVTMA_BIT_DEPTH_CONTROL);
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 24c8db673931..984eeb893d76 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -2611,7 +2611,6 @@ int r100_asic_reset(struct radeon_device *rdev, bool 
> hard)
>
>  void r100_set_common_regs(struct radeon_device *rdev)
>  {
> -   struct drm_device *dev = rdev->ddev;
> bool force_dac2 = false;
> u32 tmp;
>
> @@ -2629,7 +2628,7 @@ void r100_set_common_regs(struct radeon_device *rdev)
>  * don't report it in the bios connector
>  * table.
>  */
> -   switch (dev->pdev->device) {
> +   switch (rdev->pdev->device) {
> /* RN50 */
> case 0x515e:
> case 0x5969:
> @@ -2639,17 +2638,17 @@ void r100_set_common_regs(struct radeon_device *rdev)
> case 0x5159:
> case 0x515a:
> /* DELL triple head servers */
> -   if ((dev->pdev->subsystem_vendor == 0x1028 /* DELL */) &&
> -   ((dev->pdev->subsystem_device == 0x016c) ||
> -(dev->pdev->subsystem_device == 0x016d) ||
> -(dev->pdev->subsystem_device == 0x016e) ||
> -(dev->pdev->subsystem_device == 0x016f) ||
> -(dev->pdev->subsystem_device == 0x0170) ||
> -(dev->pdev->subsystem_device == 0x017d) ||
> -(dev->pdev->subsystem_device == 0x017e) ||
> -(dev->pdev->subsystem_device == 0x0183) ||
> -(dev->pdev->subsystem_device == 0x018a) ||
> -(dev->pdev->subsystem_device == 0x019a)))
> +   if ((rdev->pdev->subsystem_vendor == 0x1028 /* DELL */) &&
> +   ((rdev->pdev->subsystem_device == 0x016c) ||
> +(rdev->pdev->subsystem_device == 0x016d) ||
> +(rdev->pdev->subsystem_device == 0x016e) ||
> +(rdev->pdev->subsystem_device == 0x016f) ||
> +(rdev->pdev->subsystem_device == 0x0170) ||
> +(rdev->pdev-&g

Re: [Nouveau] [PATCH 01/15] drm/amdgpu: Remove references to struct drm_device.pdev

[Alex Deucher]

On Tue, Nov 24, 2020 at 6:38 AM Thomas Zimmermann  wrote:
>
> Using struct drm_device.pdev is deprecated. Convert amdgpu to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Alex Deucher 
> Cc: Christian König 

There are a few unrelated whitespace changes.  Other than that, patch is:
Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 23 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  3 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 -
>  7 files changed, 25 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 7560b05e4ac1..d61715133825 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1404,9 +1404,9 @@ static void amdgpu_switcheroo_set_state(struct pci_dev 
> *pdev,
> /* don't suspend or resume card normally */
> dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
>
> -   pci_set_power_state(dev->pdev, PCI_D0);
> -   amdgpu_device_load_pci_state(dev->pdev);
> -   r = pci_enable_device(dev->pdev);
> +   pci_set_power_state(pdev, PCI_D0);
> +   amdgpu_device_load_pci_state(pdev);
> +   r = pci_enable_device(pdev);
> if (r)
> DRM_WARN("pci_enable_device failed (%d)\n", r);
> amdgpu_device_resume(dev, true);
> @@ -1418,10 +1418,10 @@ static void amdgpu_switcheroo_set_state(struct 
> pci_dev *pdev,
> drm_kms_helper_poll_disable(dev);
> dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
> amdgpu_device_suspend(dev, true);
> -   amdgpu_device_cache_pci_state(dev->pdev);
> +   amdgpu_device_cache_pci_state(pdev);
> /* Shut down the device */
> -   pci_disable_device(dev->pdev);
> -   pci_set_power_state(dev->pdev, PCI_D3cold);
> +   pci_disable_device(pdev);
> +   pci_set_power_state(pdev, PCI_D3cold);
> dev->switch_power_state = DRM_SWITCH_POWER_OFF;
> }
>  }
> @@ -1684,8 +1684,7 @@ static void amdgpu_device_enable_virtual_display(struct 
> amdgpu_device *adev)
> adev->enable_virtual_display = false;
>
> if (amdgpu_virtual_display) {
> -   struct drm_device *ddev = adev_to_drm(adev);
> -   const char *pci_address_name = pci_name(ddev->pdev);
> +   const char *pci_address_name = pci_name(adev->pdev);
> char *pciaddstr, *pciaddstr_tmp, *pciaddname_tmp, *pciaddname;
>
> pciaddstr = kstrdup(amdgpu_virtual_display, GFP_KERNEL);
> @@ -3375,7 +3374,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> }
> }
>
> -   pci_enable_pcie_error_reporting(adev->ddev.pdev);
> +   pci_enable_pcie_error_reporting(adev->pdev);
>
> /* Post card if necessary */
> if (amdgpu_device_need_post(adev)) {
> @@ -4922,8 +4921,8 @@ pci_ers_result_t amdgpu_pci_error_detected(struct 
> pci_dev *pdev, pci_channel_sta
> case pci_channel_io_normal:
> return PCI_ERS_RESULT_CAN_RECOVER;
> /* Fatal error, prepare for slot reset */
> -   case pci_channel_io_frozen:
> -   /*
> +   case pci_channel_io_frozen:
> +   /*
>  * Cancel and wait for all TDRs in progress if failing to
>  * set  adev->in_gpu_reset in amdgpu_device_lock_adev
>  *
> @@ -5014,7 +5013,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct pci_dev 
> *pdev)
> goto out;
> }
>
> -   adev->in_pci_err_recovery = true;
> +   adev->in_pci_err_recovery = true;
> r = amdgpu_device_pre_asic_reset(adev, NULL, _full_reset);
> adev->in_pci_err_recovery = false;
> if (r)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 2e8a8b57639f..77974c3981fa 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -721,13 +721,14 @@ amdgpu_display_user_framebuffer_create(struct 
> drm_device *dev,
>   

Re: [Nouveau] [PATCH 5/5] drm/: Constify struct drm_driver

[Alex Deucher]

On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter  wrote:
>
> Only the following drivers aren't converted:
> - amdgpu, because of the driver_feature mangling due to virt support
> - nouveau, because DRIVER_ATOMIC uapi is still not the default on the
>   platforms where it's supported (i.e. again driver_feature mangling)
> - vc4, again because of driver_feature mangling
> - qxl, because the ioctl table is somewhere else and moving that is
>   maybe a bit too much, hence the num_ioctls assignment prevents a
>   const driver structure.
> - arcpgu, because that is stuck behind a pending tiny-fication series
>   from me.
> - legacy drivers, because legacy requires non-const drm_driver.
>
> Note that for armada I also went ahead and made the ioctl array const.
>
> Only cc'ing the driver people who've not been converted (everyone else
> is way too much).
>
> v2: Fix one misplaced const static, should be static const (0day)
>
> v3:
> - Improve commit message (Sam)
>
> Acked-by: Sam Ravnborg 
> Cc: kernel test robot 
> Acked-by: Maxime Ripard 
> Signed-off-by: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Dave Airlie 
> Cc: Gerd Hoffmann 
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Eric Anholt 
> Cc: Maxime Ripard 
> Cc: Ben Skeggs 
> Cc: nouveau@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_kms.c  | 2 +-
>  drivers/gpu/drm/arm/hdlcd_drv.c  | 2 +-
>  drivers/gpu/drm/arm/malidp_drv.c | 2 +-
>  drivers/gpu/drm/armada/armada_drv.c  | 7 +++
>  drivers/gpu/drm/aspeed/aspeed_gfx_drv.c  | 2 +-
>  drivers/gpu/drm/ast/ast_drv.c| 2 +-
>  drivers/gpu/drm/ast/ast_drv.h| 2 +-
>  drivers/gpu/drm/ast/ast_main.c   | 2 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
>  drivers/gpu/drm/bochs/bochs_drv.c| 2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  | 2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++---
>  drivers/gpu/drm/gma500/psb_drv.c | 4 ++--
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 2 +-
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  | 2 +-
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h  | 2 +-
>  drivers/gpu/drm/i915/i915_drv.c  | 4 ++--
>  drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
>  drivers/gpu/drm/imx/dcss/dcss-kms.c  | 2 +-
>  drivers/gpu/drm/imx/imx-drm-core.c   | 2 +-
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +-
>  drivers/gpu/drm/lima/lima_drv.c  | 2 +-
>  drivers/gpu/drm/mcde/mcde_drv.c  | 2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   | 2 +-
>  drivers/gpu/drm/meson/meson_drv.c| 2 +-
>  drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +-
>  drivers/gpu/drm/msm/msm_drv.c| 4 ++--
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c   | 2 +-
>  drivers/gpu/drm/panfrost/panfrost_drv.c  | 2 +-
>  drivers/gpu/drm/pl111/pl111_drv.c| 2 +-
>  drivers/gpu/drm/radeon/radeon_drv.c  | 4 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c  | 4 ++--
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
>  drivers/gpu/drm/sti/sti_drv.c| 2 +-
>  drivers/gpu/drm/stm/drv.c| 2 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +-
>  drivers/gpu/drm/tegra/drm.c  | 5 ++---
>  drivers/gpu/drm/tidss/tidss_drv.c| 2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 4 ++--
>  drivers/gpu/drm/tiny/cirrus.c| 2 +-
>  drivers/gpu/drm/tiny/gm12u320.c  | 2 +-
>  drivers/gpu/drm/tiny/hx8357d.c   | 2 +-
>  drivers/gpu/drm/tiny/ili9225.c   | 2 +-
>  drivers/gpu/drm/tiny/ili9341.c   | 2 +-
>  drivers/gpu/drm/tiny/ili9486.c   | 2 +-
>  drivers/gpu/drm/tiny/mi0283qt.c  | 2 +-
>  drivers/gpu/drm/tiny/repaper.c   | 2 +-
>  drivers/gpu/drm/tiny/st7586.c| 2 +-
>  drivers/gpu/drm/tiny/st7735r.c   | 2 +-
>  drivers/gpu/drm/tve200/tve200_drv.c  | 2 +-
>  drivers/gpu/drm/udl/udl_drv.c| 2 +-
>  drivers/gpu/drm/v3d/v3d_drv.c| 2 +-
>  d

Re: [Nouveau] [PATCH 1/4] drm: retrieve EDID via ACPI _DDC method

[Alex Deucher]

On Wed, Aug 12, 2020 at 10:31 PM Daniel Dadap  wrote:
>
> Thanks, Lukas. I've incorporated your feedback into my local tree, but
> will wait for additional feedback from the individual DRM driver
> maintainers before sending out a series v2.
>
> On 8/8/20 5:11 PM, Lukas Wunner wrote:
> > On Mon, Jul 27, 2020 at 03:53:54PM -0500, Daniel Dadap wrote:
> >> + for (i = 0; i < num_dod_entries; i++) {
> >> + if (adr == dod_entries[i]) {
> >> + ret = do_acpi_ddc(child->handle);
> >> +
> >> + if (ret != NULL)
> >> + goto done;
> > I guess ideally we'd want to correlate the display objects with
> > drm_connectors or at least constrain the search to Display Type
> > "Internal/Integrated Digital Flat Panel" instead of picking the
> > first EDID found.  Otherwise we might erroneously use the DDC
> > for an externally attached display.
>
>
> Yes, we'd definitely need a way to do this if this functionality ever
> needs to be extended to systems with more than one _DDC method.
> Unfortunately, this will be much easier said than done, since I'm not
> aware of any way to reliably do map _DOD entries to connectors in a GPU
> driver, especially when we're talking about possibly correlating
> connectors on multiple GPUs which mux to the same internal display or
> external connector. All systems which I am aware of that implement ACPI
> _DDC do so for a single internal panel. I don't believe there's any
> reason to ever retrieve an EDID via ACPI _DDC for an external panel, but
> a hypothetical design with multiple internal panels, more than one of
> which needs to retrieve an EDID via ACPI _DDC, would certainly be
> problematic.
>
>
> On at least the system I'm working with for the various switcheroo and
> platform-x86 driver patches I've recently sent off, the dGPU has an ACPI
> _DOD table and one _DDC method corresponding to one of the _DOD entries,
> but the iGPU has neither a _DOD table nor a _DDC method. Either GPU can
> be connected to the internal panel via the dynamically switchable mux,
> and the internal panel's EDID is available via _DDC to allow a
> disconnected GPU to read the EDID. Since only the DGPU has _DOD and
> _DDC, and there's no obvious way to associate connectors on the iGPU
> with connectors on the dGPU, I've implemented the ACPI _DDC EDID
> retrieval with the "first available" implementation you see here. I'm
> open to other ideas if you have them, but didn't see a good way to
> search for the "right" _DDC implementation should there be more than one.
>
>
> As for preventing the ACPI EDID retrieval from being used for external
> panels, I've done this in the individual DRM drivers that call into the
> new drm_edid_acpi() API since it seemed that each DRM driver had its own
> way of distinguishing display connector types. If there's a good way to
> filter for internal panels in DRM core, I'd be happy to do that instead.

I can double check with our ACPI and vbios teams, but I'm not sure
that we ever used the _DDC method on any AMD platforms.  Even if we
did, the driver is still able to get the integrated panel's mode info
via other means.  In general, external connectors would always get the
EDID via i2c or aux.  The only use case we ever had to hardcoding an
EDID was for some really old server chips so they would always think
something was connected if you wanted to attach a crash cart.  That
EDID was stored in the vbios, not ACPI.

As for enumerating which displays were muxed or not and the local
mappings to acpi ids, etc., we had a whole set of ATPX methods to do
that if anyone is interested:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/include/amd_acpi.h

Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Alex Deucher]

On Fri, May 22, 2020 at 6:41 AM Christian König
 wrote:
>
> Am 20.05.20 um 18:18 schrieb Alex Deucher:
> > On Wed, May 20, 2020 at 10:43 AM Christian König
> >  wrote:
> >> Am 13.05.20 um 13:03 schrieb Christian König:
> >>> Unfortunately AGP is still to widely used as we could just drop support 
> >>> for using its GART.
> >>>
> >>> Not using the AGP GART also doesn't mean a loss in functionality since 
> >>> drivers will just fallback to the driver specific PCI GART.
> >>>
> >>> For now just deprecate the code and don't enable the AGP GART in TTM even 
> >>> when general AGP support is available.
> >> So I've used an ancient system (32bit) to setup a test box for this.
> >>
> >>
> >> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> >> 15 years old.
> >>
> >> What happens in AGP mode is that glxgears shows artifacts during
> >> rendering on this system.
> >>
> >> In PCI mode those rendering artifacts are gone and glxgears seems to
> >> draw everything correctly now.
> >>
> >> Performance is obviously not comparable, cause in AGP we don't render
> >> all triangles correctly.
> >>
> >>
> >> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
> >> which is more than 10 years old.
> >>
> >> As far as I can tell this one works in both AGP and PCIe mode perfectly
> >> fine.
> >>
> >> Since this is only a 32bit system I couldn't really test any OpenGL game
> >> that well.
> >>
> >> But for glxgears switching from AGP to PCIe mode seems to result in a
> >> roughly 5% performance drop.
> >>
> >> The surprising reason for this is not the better TLB performance, but
> >> the lack of USWC support for the PCIe GART in radeon.
> >>
> >>
> >> So if anybody wants to get his hands dirty and squeeze a bit more
> >> performance out of the old hardware, porting USWC from amdgpu to radeon
> >> shouldn't be to much of a problem.
> > We do support USWC on radeon, although I think we had separate flags
> > for cached and WC.  That said we had a lot of problems with WC on 32
> > bit (see radeon_bo_create()).  The other problem is that, at least on
> > the really old radeons, the PCI gart didn't support snooped and
> > unsnooped.  It was always snooped.  It wasn't until pcie that the gart
> > hw got support for both.  For AGP, the expectation was that AGP
> > provided the uncached memory.
>
> Oh, indeed. I didn't remembered that.
>
> Interesting is that in this case I have no idea where the performance
> difference is coming from.
>
> >
> >>
> >> Summing it up I'm still leaning towards disabling AGP completely by
> >> default for radeon and deprecate it in TTM as well.
> >>
> >> Thoughts? Especially Alex what do you think.
> > Works for me.
>
> I will take that as an rb and commit at least the first patch.

Yeah, Reviewed-by: Alex Deucher 

>
> Thanks,
> Christian.
>
> >
> > Alex
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Alex Deucher]

On Wed, May 20, 2020 at 10:43 AM Christian König
 wrote:
>
> Am 13.05.20 um 13:03 schrieb Christian König:
> > Unfortunately AGP is still to widely used as we could just drop support for 
> > using its GART.
> >
> > Not using the AGP GART also doesn't mean a loss in functionality since 
> > drivers will just fallback to the driver specific PCI GART.
> >
> > For now just deprecate the code and don't enable the AGP GART in TTM even 
> > when general AGP support is available.
>
> So I've used an ancient system (32bit) to setup a test box for this.
>
>
> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> 15 years old.
>
> What happens in AGP mode is that glxgears shows artifacts during
> rendering on this system.
>
> In PCI mode those rendering artifacts are gone and glxgears seems to
> draw everything correctly now.
>
> Performance is obviously not comparable, cause in AGP we don't render
> all triangles correctly.
>
>
> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
> which is more than 10 years old.
>
> As far as I can tell this one works in both AGP and PCIe mode perfectly
> fine.
>
> Since this is only a 32bit system I couldn't really test any OpenGL game
> that well.
>
> But for glxgears switching from AGP to PCIe mode seems to result in a
> roughly 5% performance drop.
>
> The surprising reason for this is not the better TLB performance, but
> the lack of USWC support for the PCIe GART in radeon.
>
>
> So if anybody wants to get his hands dirty and squeeze a bit more
> performance out of the old hardware, porting USWC from amdgpu to radeon
> shouldn't be to much of a problem.

We do support USWC on radeon, although I think we had separate flags
for cached and WC.  That said we had a lot of problems with WC on 32
bit (see radeon_bo_create()).  The other problem is that, at least on
the really old radeons, the PCI gart didn't support snooped and
unsnooped.  It was always snooped.  It wasn't until pcie that the gart
hw got support for both.  For AGP, the expectation was that AGP
provided the uncached memory.

>
>
> Summing it up I'm still leaning towards disabling AGP completely by
> default for radeon and deprecate it in TTM as well.
>
> Thoughts? Especially Alex what do you think.

Works for me.

Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/3] drm/radeon: remove AGP support

[Alex Deucher]

On Tue, May 12, 2020 at 4:52 PM Roy Spliet  wrote:
>
> Op 12-05-2020 om 14:36 schreef Alex Deucher:
> > On Tue, May 12, 2020 at 4:16 AM Michel Dänzer  wrote:
> >>
> >> On 2020-05-11 10:12 p.m., Alex Deucher wrote:
> >>> On Mon, May 11, 2020 at 1:17 PM Christian König
> >>>  wrote:
> >>>>
> >>>> AGP is deprecated for 10+ years now and not used any more on modern 
> >>>> hardware.
> >>>>
> >>>> Old hardware should continue to work in PCI mode.
> >>>
> >>> Might want to clarify that there is no loss of functionality here.
> >>> Something like:
> >>>
> >>> "There is no loss of functionality here.  GPUs will continue to
> >>> function.  This just drops the use of the AGP MMU in the chipset in
> >>> favor of the MMU on the device which has proven to be much more
> >>> reliable.  Due to its unreliability, AGP support has been disabled on
> >>> PowerPC for years already so there is no change on PowerPC."
> >>
> >> There's a difference between something being disabled by default or not
> >> being available at all. We may decide it's worth it anyway, but let's do
> >> it based on facts.
> >>
> >
> > I didn't mean to imply that AGP GART support was already removed.  But
> > for the vast majority of users the end result is the same.  If you
> > knew enough re-enable AGP GART, you probably wouldn't have been as
> > confused about what this patch set does either.  To reiterate, this
> > patch set does not remove support for AGP cards, it only removes the
> > support for AGP GART.  The cards will still be functional using the
> > device GART.  There may be performance tradeoffs there in some cases.
>
> I'll volunteer to be the one asking: how big is this performance
> difference? Have any benchmarks been run before and after removal of AGP
> GART code on affected nouveau/radeon systems? Or is this code being
> dropped _just_ because it's cumbersome, with no regard for metrics that
> determine the value of AGP GART support?
>

I don't think anyone has any solid numbers, just anecdotal from
memory.  I certainly don't have any functional AGP systems at this
point.  It's mostly just cumbersome and would allow us to clean ttm
and probably improve stability at the same time.  At least on the
radeon side, the only native AGP cards were r1xx, r2xx, and some of
the early r3xx boards.  Once we switched to pcie mid-way through r3xx,
everything was native pcie and the AGP cards used a pcie to AGP bridge
chip so they had a decent on chip MMU.  Those older cards topped out
at maybe 32 or 64 MB of vram, so they are going to be hard pressed to
deal with modern desktops anyway.  No idea what sort of GART
capabilities NV AGP hardware at this time had.

Alex

> Roy
>
> >
> > Alex
> > ___
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

[Alex Deucher]

On Tue, May 12, 2020 at 3:10 PM Thomas Zimmermann  wrote:
>
> Hi Alex
>
> Am 12.05.20 um 20:32 schrieb Alex Deucher:
> > On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann  
> > wrote:
> >>
> >> Hi
> >>
> >> Am 11.05.20 um 19:17 schrieb Christian König:
> >>> Hi guys,
> >>>
> >>> Well let's face it AGP is a total headache to maintain and dead for at 
> >>> least 10+ years.
> >>>
> >>> We have a lot of x86 specific stuff in the architecture independent 
> >>> graphics memory management to get the caching right, abusing the DMA API 
> >>> on multiple occasions, need to distinct between AGP and driver specific 
> >>> page tables etc etc...
> >>>
> >>> So the idea here is to just go ahead and remove the support from Radeon 
> >>> and Nouveau and then drop the necessary code from TTM.
> >>>
> >>> For Radeon this means that we just switch over to the driver specific 
> >>> page tables and everything should more or less continue to work.
> >>>
> >>> For Nouveau I'm not 100% sure, but from the code it of hand looks like we 
> >>> can do it similar to Radeon.
> >>>
> >>> Please comment what you think about this.
> >>
> >> There's some AGP support code in the DRM core. Can some of that declared
> >> as legacy?
> >>
> >> Specifically, what about these AGP-related ioctl calls? Can they be
> >> declared as legacy? It would appear to me that KMS-based drivers don't
> >> have to manage AGP by themselves. (?)
> >
> > The old drm core AGP code is mainly (only?) for the non-KMS drivers.
> > E.g., mach64, r128, sis, savage, etc.
>
> Exactly my point. There's one drm_agp_init() call left in radeon. The
> rest of the AGP code is apparently for legacy non-KMS drivers. Should
> the related ioctl calls be declared as legacy (i.e., listed with
> DRM_LEGACY_IOCTL_DEF instead of DRM_IOCTL_DEF)? If so, much of the AGP
> core code could probably be moved behind CONFIG_DRM_LEGACY as well.

Ah, I forgot about drm_agp_init().  I was just thinking the other AGP
stuff.  Yeah, I think we could make it legacy.

Alex


>
> Best regards
> Thomas
>
> >
> > Alex
> >
> >>
> >> Best regards
> >> Thomas
> >>
> >>>
> >>> Regards,
> >>> Christian.
> >>>
> >>>
> >>> ___
> >>> Nouveau mailing list
> >>> Nouveau@lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/nouveau
> >>>
> >>
> >> --
> >> Thomas Zimmermann
> >> Graphics Driver Developer
> >> SUSE Software Solutions Germany GmbH
> >> Maxfeldstr. 5, 90409 Nürnberg, Germany
> >> (HRB 36809, AG Nürnberg)
> >> Geschäftsführer: Felix Imendörffer
> >>
> >> ___
> >> amd-gfx mailing list
> >> amd-...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

[Alex Deucher]

On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 11.05.20 um 19:17 schrieb Christian König:
> > Hi guys,
> >
> > Well let's face it AGP is a total headache to maintain and dead for at 
> > least 10+ years.
> >
> > We have a lot of x86 specific stuff in the architecture independent 
> > graphics memory management to get the caching right, abusing the DMA API on 
> > multiple occasions, need to distinct between AGP and driver specific page 
> > tables etc etc...
> >
> > So the idea here is to just go ahead and remove the support from Radeon and 
> > Nouveau and then drop the necessary code from TTM.
> >
> > For Radeon this means that we just switch over to the driver specific page 
> > tables and everything should more or less continue to work.
> >
> > For Nouveau I'm not 100% sure, but from the code it of hand looks like we 
> > can do it similar to Radeon.
> >
> > Please comment what you think about this.
>
> There's some AGP support code in the DRM core. Can some of that declared
> as legacy?
>
> Specifically, what about these AGP-related ioctl calls? Can they be
> declared as legacy? It would appear to me that KMS-based drivers don't
> have to manage AGP by themselves. (?)

The old drm core AGP code is mainly (only?) for the non-KMS drivers.
E.g., mach64, r128, sis, savage, etc.

Alex

>
> Best regards
> Thomas
>
> >
> > Regards,
> > Christian.
> >
> >
> > ___
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/3] drm/radeon: remove AGP support

[Alex Deucher]

On Tue, May 12, 2020 at 2:20 PM Thomas Zimmermann  wrote:
>
> Hi Christian
>
> Am 11.05.20 um 19:17 schrieb Christian König:
> > AGP is deprecated for 10+ years now and not used any more on modern 
> > hardware.
> >
> > Old hardware should continue to work in PCI mode.
> >
> > Signed-off-by: Christian König 
> > ---
> >  drivers/gpu/drm/radeon/Makefile|   4 +-
> >  drivers/gpu/drm/radeon/evergreen.c |   7 -
> >  drivers/gpu/drm/radeon/r100.c  |  10 +-
> >  drivers/gpu/drm/radeon/r300.c  |   9 -
> >  drivers/gpu/drm/radeon/r420.c  |   9 -
> >  drivers/gpu/drm/radeon/r520.c  |   8 -
> >  drivers/gpu/drm/radeon/r600.c  |   6 -
> >  drivers/gpu/drm/radeon/radeon.h|  11 -
> >  drivers/gpu/drm/radeon/radeon_agp.c| 290 -
> >  drivers/gpu/drm/radeon/radeon_device.c |  23 +-
> >  drivers/gpu/drm/radeon/radeon_drv.c|   9 -
>
> In radeon_drv.c, the field drm_device.agp is still being initialized in
> radeon_pci_probe() and cleaned up in radeon_driver_unload_kms(). Is this
> intentional?
>
> Best regards
> Thomas
>
> >  drivers/gpu/drm/radeon/radeon_ttm.c|  39 
> >  drivers/gpu/drm/radeon/rv515.c |   9 -
> >  drivers/gpu/drm/radeon/rv770.c |   7 -
> >  14 files changed, 4 insertions(+), 437 deletions(-)
> >  delete mode 100644 drivers/gpu/drm/radeon/radeon_agp.c
> >
> > diff --git a/drivers/gpu/drm/radeon/Makefile 
> > b/drivers/gpu/drm/radeon/Makefile
> > index c693b2ca0329..77429cfd303e 100644
> > --- a/drivers/gpu/drm/radeon/Makefile
> > +++ b/drivers/gpu/drm/radeon/Makefile
> > @@ -61,8 +61,8 @@ radeon-y := radeon_drv.o
> >
> >  # add KMS driver
> >  radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> > - radeon_atombios.o radeon_agp.o atombios_crtc.o radeon_combios.o \
> > - atom.o radeon_fence.o radeon_ttm.o radeon_object.o radeon_gart.o \
> > + radeon_atombios.o atombios_crtc.o radeon_combios.o atom.o \
> > + radeon_fence.o radeon_ttm.o radeon_object.o radeon_gart.o \
> >   radeon_legacy_crtc.o radeon_legacy_encoders.o radeon_connectors.o \
> >   radeon_encoders.o radeon_display.o radeon_cursor.o radeon_i2c.o \
> >   radeon_clocks.o radeon_fb.o radeon_gem.o radeon_ring.o 
> > radeon_irq_kms.o \
> > diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> > b/drivers/gpu/drm/radeon/evergreen.c
> > index 14d90dc376e7..66b3d9a2c6dd 100644
> > --- a/drivers/gpu/drm/radeon/evergreen.c
> > +++ b/drivers/gpu/drm/radeon/evergreen.c
> > @@ -5216,12 +5216,6 @@ int evergreen_init(struct radeon_device *rdev)
> >   r = radeon_fence_driver_init(rdev);
> >   if (r)
> >   return r;
> > - /* initialize AGP */
> > - if (rdev->flags & RADEON_IS_AGP) {
> > - r = radeon_agp_init(rdev);
> > - if (r)
> > - radeon_agp_disable(rdev);
> > - }
> >   /* initialize memory controller */
> >   r = evergreen_mc_init(rdev);
> >   if (r)
> > @@ -5315,7 +5309,6 @@ void evergreen_fini(struct radeon_device *rdev)
> >   r600_vram_scratch_fini(rdev);
> >   radeon_gem_fini(rdev);
> >   radeon_fence_driver_fini(rdev);
> > - radeon_agp_fini(rdev);
> >   radeon_bo_fini(rdev);
> >   radeon_atombios_fini(rdev);
> >   kfree(rdev->bios);
> > diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> > index 24c8db673931..320b1b40a30a 100644
> > --- a/drivers/gpu/drm/radeon/r100.c
> > +++ b/drivers/gpu/drm/radeon/r100.c
> > @@ -3382,7 +3382,7 @@ void r100_bandwidth_update(struct radeon_device *rdev)
> >
> >   if (rdev->flags & RADEON_IS_AGP) {
> >   fixed20_12 agpmode_ff;
> > - agpmode_ff.full = dfixed_const(radeon_agpmode);
> > + agpmode_ff.full = dfixed_const(0);
> >   temp_ff.full = dfixed_const_666(16);
> >   sclk_eff_ff.full -= dfixed_mul(agpmode_ff, temp_ff);
> >   }
> > @@ -3992,7 +3992,6 @@ void r100_fini(struct radeon_device *rdev)
> >   radeon_gem_fini(rdev);
> >   if (rdev->flags & RADEON_IS_PCI)
> >   r100_pci_gart_fini(rdev);
> > - radeon_agp_fini(rdev);
> >   radeon_irq_kms_fini(rdev);
> >   radeon_fence_driver_fini(rdev);
> >   radeon_bo_fini(rdev);
> > @@ -4068,13 +4067,6 @@ int r100_init(struct radeon_device *rdev)
> >   r100_errata(rdev);
> >   /* Initialize clocks */
> >   radeon_get_clock_info(rdev->ddev);
> > - /* initialize AGP */
> > - if (rdev->flags & RADEON_IS_AGP) {
> > - r = radeon_agp_init(rdev);
> > - if (r) {
> > - radeon_agp_disable(rdev);
> > - }
> > - }
> >   /* initialize VRAM */
> >   r100_mc_init(rdev);
> >   /* Fence driver */
> > diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
> > index 3b7ead5be5bf..afd688629cf9 100644
> > --- a/drivers/gpu/drm/radeon/r300.c
> > +++ b/drivers/gpu/drm/radeon/r300.c
> > @@ -1498,7 +1498,6 @@ 

Re: [Nouveau] [PATCH 1/3] drm/radeon: remove AGP support

[Alex Deucher]

On Tue, May 12, 2020 at 4:16 AM Michel Dänzer  wrote:
>
> On 2020-05-11 10:12 p.m., Alex Deucher wrote:
> > On Mon, May 11, 2020 at 1:17 PM Christian König
> >  wrote:
> >>
> >> AGP is deprecated for 10+ years now and not used any more on modern 
> >> hardware.
> >>
> >> Old hardware should continue to work in PCI mode.
> >
> > Might want to clarify that there is no loss of functionality here.
> > Something like:
> >
> > "There is no loss of functionality here.  GPUs will continue to
> > function.  This just drops the use of the AGP MMU in the chipset in
> > favor of the MMU on the device which has proven to be much more
> > reliable.  Due to its unreliability, AGP support has been disabled on
> > PowerPC for years already so there is no change on PowerPC."
>
> There's a difference between something being disabled by default or not
> being available at all. We may decide it's worth it anyway, but let's do
> it based on facts.
>

I didn't mean to imply that AGP GART support was already removed.  But
for the vast majority of users the end result is the same.  If you
knew enough re-enable AGP GART, you probably wouldn't have been as
confused about what this patch set does either.  To reiterate, this
patch set does not remove support for AGP cards, it only removes the
support for AGP GART.  The cards will still be functional using the
device GART.  There may be performance tradeoffs there in some cases.

Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

[Alex Deucher]

On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir  wrote:
>
> On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > Hi guys,
>
> > Well let's face it AGP is a total headache to maintain and dead for at 
> > least 10+ years.
>
> > We have a lot of x86 specific stuff in the architecture independent
> > graphics memory management to get the caching right, abusing the DMA
> > API on multiple occasions, need to distinct between AGP and driver specific 
> > page tables etc etc...
>
> > So the idea here is to just go ahead and remove the support from
> > Radeon and Nouveau and then drop the necessary code from TTM.
>
> > For Radeon this means that we just switch over to the driver
> > specific page tables and everything should more or less continue to work.
>
> > For Nouveau I'm not 100% sure, but from the code it of hand looks
> > like we can do it similar to Radeon.
>
> > Please comment what you think about this.
>
> > Regards,
> > Christian.
>
> Christian,
>
> I would respectfully ask that this change be rejected.
>
> I'm  currently  an  end user on both Intel (32-bit and 64-bit) and PPC
> (Macs, IBM Power - BE and LE).
>
> Linux is not just used for modern hardware. There is also a subset of
> the user base that uses it for what is often termed retro-computing.
> No it's not commercial usage, but no one can seriously claim that that
> Linux is for business only.
>
> Often the old hardware is built far batter than the modern junk, and
> will continue to run for years to come. This group of folks either has
> existing hardware they wish to continue to use, or are acquiring the
> same because they are tired of generic locked-down hardware.
>
> A significant percentage of the video hardware that falls in the retro
> category uses the AGP video bus. Removing that support for those cases
> where it works would severely limit performance and in some cases
> functionality. This can mean the difference between being able to run
> an application, or having it fail.
>

Note there is no loss of functionality here, at least on radeon
hardware.  It just comes down to which MMU gets used for access to
system memory, the AGP MMU on the chipset or the MMU built into the
GPU.  On powerpc hardware, AGP has been particularly unstable, and AGP
has been disabled by default on radeon on powerpc for years now.  In
fact, this will probably make older hardware more reliable as it takes
AGP out of the equation.

Alex


> There are multiple active Linux distributions for PPC Macs. Many folks
> are moving from running an original Mac OS X because of the recent
> migration of most Web services to new encryption protocols (TLS 1.2,
> SSL, etc.) which can not be practically supported by browsers on that
> OS - even the open source ones. Linux on that same hardware provides
> the opportunity to work online with current protocols and ensure that
> they are reasonably secure.
>
> Another group that fits in the retro category is those folks with
> older PC hardware who are not migrating to the latest Microsoft OS,
> but instead want to move to Linux.
>
> Some folks suggest the retro folks use an older unmaintained Linux
> version. That's just not appropriate nor reasonable, again from either
> a security and protocol point of view.
>
> Myself? I'm a full-time C programmer and Electrical Engineer. My
> current work project is about 400KLOC. I've done some work on PC and
> embedded video hardware and software in the past.
>
> My aim is to start out by helping to test the video drivers (on both
> PC and MAC hardware), and as I gain more knowledge become part of the
> effort to bring the drivers to the older hardware into a better form
> (in kernel drivers VS user-space).
>
> Over the last few years I have been collecting a significant (~40)
> number of video cards of various flavors. Some PCI, but the majority
> evenly divided between AGP and PCI-X. Most are ATI/Radeon (Mach64+
> through R7) with some Nvidia, Matrox and a few others (Chrome and even
> a Number Nine). I try to have both PC and Mac variants of the same
> card where-ever possible to make comparisons across architectures
> easier. This year I have acquired some of the last Sapphire Radeon AGP
> cards (HD3xxx, HD4xxx). I'm a frequent flyer on eBay and Kijiji.
>
> I've got lots of Macs (PCI, AGP and PCI-X) and a number of full PC
> systems. I'm setting up a number of dedicated test bench rigs (and
> full systems) specifically for the video testing. Most are AMD 64-bit
> capable, but also Intel. Finally, there are a few embedded systems
> (AMD and a C3).
>
> From the programming side, Amazon has been a good source on older
> editions of computer graphics books, which should provide background
> knowledge to help me in my journey.
>
> One glitch is that I'm partway through eye surgery (cornea + cataracts),
> and my final operation is held up due to COVID-19.  After things get
> back to more of a normal state and that can be completed, my progress
> should be a lot smoother.
>
> I 

Re: [Nouveau] [PATCH 1/3] drm/radeon: remove AGP support

[Alex Deucher]

On Mon, May 11, 2020 at 1:17 PM Christian König
 wrote:
>
> AGP is deprecated for 10+ years now and not used any more on modern hardware.
>
> Old hardware should continue to work in PCI mode.

Might want to clarify that there is no loss of functionality here.
Something like:

"There is no loss of functionality here.  GPUs will continue to
function.  This just drops the use of the AGP MMU in the chipset in
favor of the MMU on the device which has proven to be much more
reliable.  Due to its unreliability, AGP support has been disabled on
PowerPC for years already so there is no change on PowerPC."

With that updated, patches 1, 3:
Reviewed-by: Alex Deucher 
patch 2:
Acked-by: Alex Deucher 

>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/radeon/Makefile|   4 +-
>  drivers/gpu/drm/radeon/evergreen.c |   7 -
>  drivers/gpu/drm/radeon/r100.c  |  10 +-
>  drivers/gpu/drm/radeon/r300.c  |   9 -
>  drivers/gpu/drm/radeon/r420.c  |   9 -
>  drivers/gpu/drm/radeon/r520.c  |   8 -
>  drivers/gpu/drm/radeon/r600.c  |   6 -
>  drivers/gpu/drm/radeon/radeon.h|  11 -
>  drivers/gpu/drm/radeon/radeon_agp.c| 290 -
>  drivers/gpu/drm/radeon/radeon_device.c |  23 +-
>  drivers/gpu/drm/radeon/radeon_drv.c|   9 -
>  drivers/gpu/drm/radeon/radeon_ttm.c|  39 
>  drivers/gpu/drm/radeon/rv515.c |   9 -
>  drivers/gpu/drm/radeon/rv770.c |   7 -
>  14 files changed, 4 insertions(+), 437 deletions(-)
>  delete mode 100644 drivers/gpu/drm/radeon/radeon_agp.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index c693b2ca0329..77429cfd303e 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -61,8 +61,8 @@ radeon-y := radeon_drv.o
>
>  # add KMS driver
>  radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> -   radeon_atombios.o radeon_agp.o atombios_crtc.o radeon_combios.o \
> -   atom.o radeon_fence.o radeon_ttm.o radeon_object.o radeon_gart.o \
> +   radeon_atombios.o atombios_crtc.o radeon_combios.o atom.o \
> +   radeon_fence.o radeon_ttm.o radeon_object.o radeon_gart.o \
> radeon_legacy_crtc.o radeon_legacy_encoders.o radeon_connectors.o \
> radeon_encoders.o radeon_display.o radeon_cursor.o radeon_i2c.o \
> radeon_clocks.o radeon_fb.o radeon_gem.o radeon_ring.o 
> radeon_irq_kms.o \
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 14d90dc376e7..66b3d9a2c6dd 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -5216,12 +5216,6 @@ int evergreen_init(struct radeon_device *rdev)
> r = radeon_fence_driver_init(rdev);
> if (r)
> return r;
> -   /* initialize AGP */
> -   if (rdev->flags & RADEON_IS_AGP) {
> -   r = radeon_agp_init(rdev);
> -   if (r)
> -   radeon_agp_disable(rdev);
> -   }
> /* initialize memory controller */
> r = evergreen_mc_init(rdev);
> if (r)
> @@ -5315,7 +5309,6 @@ void evergreen_fini(struct radeon_device *rdev)
> r600_vram_scratch_fini(rdev);
> radeon_gem_fini(rdev);
> radeon_fence_driver_fini(rdev);
> -   radeon_agp_fini(rdev);
> radeon_bo_fini(rdev);
> radeon_atombios_fini(rdev);
> kfree(rdev->bios);
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 24c8db673931..320b1b40a30a 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -3382,7 +3382,7 @@ void r100_bandwidth_update(struct radeon_device *rdev)
>
> if (rdev->flags & RADEON_IS_AGP) {
> fixed20_12 agpmode_ff;
> -   agpmode_ff.full = dfixed_const(radeon_agpmode);
> +   agpmode_ff.full = dfixed_const(0);
> temp_ff.full = dfixed_const_666(16);
> sclk_eff_ff.full -= dfixed_mul(agpmode_ff, temp_ff);
> }
> @@ -3992,7 +3992,6 @@ void r100_fini(struct radeon_device *rdev)
> radeon_gem_fini(rdev);
> if (rdev->flags & RADEON_IS_PCI)
> r100_pci_gart_fini(rdev);
> -   radeon_agp_fini(rdev);
> radeon_irq_kms_fini(rdev);
> radeon_fence_driver_fini(rdev);
> radeon_bo_fini(rdev);
> @@ -4068,13 +4067,6 @@ int r100_init(struct radeon_device *rdev)
> r100_errata(rdev);
> /* Initialize clocks */
> radeon_get_clock_info(rdev->ddev);
> -   /* initialize AGP */
> -   if (rdev->flags & RADEON_IS_AGP) {
> -  

Re: [Nouveau] [PATCH v4 05/22] drm/amdgpu: Convert to CRTC VBLANK callbacks

[Alex Deucher]

On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann  wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert amdgpu over.
>
> v2:
> * don't wrap existing functions; change signature instead
>
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  6 +++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  4 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  4 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 21 +++
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  4 
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  4 
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  4 
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  4 
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  4 
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +
>  10 files changed, 43 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index f42e8d467c12..2319fdfc42e5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1191,9 +1191,9 @@ void amdgpu_driver_postclose_kms(struct drm_device *dev,
>  int amdgpu_device_ip_suspend(struct amdgpu_device *adev);
>  int amdgpu_device_suspend(struct drm_device *dev, bool fbcon);
>  int amdgpu_device_resume(struct drm_device *dev, bool fbcon);
> -u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
> -int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
> -void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
> +u32 amdgpu_get_vblank_counter_kms(struct drm_crtc *crtc);
> +int amdgpu_enable_vblank_kms(struct drm_crtc *crtc);
> +void amdgpu_disable_vblank_kms(struct drm_crtc *crtc);
>  long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
>  unsigned long arg);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index a1e769d4417d..ad9c9546a64f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -99,7 +99,7 @@ static void amdgpu_display_flip_work_func(struct 
> work_struct *__work)
>  & (DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_IN_VBLANK)) ==
> (DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_IN_VBLANK) &&
> (int)(work->target_vblank -
> - amdgpu_get_vblank_counter_kms(adev->ddev, 
> amdgpu_crtc->crtc_id)) > 0) {
> + amdgpu_get_vblank_counter_kms(crtc)) > 0) {
> schedule_delayed_work(>flip_work, 
> usecs_to_jiffies(1000));
> return;
> }
> @@ -219,7 +219,7 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc 
> *crtc,
> if (!adev->enable_virtual_display)
> work->base = amdgpu_bo_gpu_offset(new_abo);
> work->target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
> -   amdgpu_get_vblank_counter_kms(dev, work->crtc_id);
> +   amdgpu_get_vblank_counter_kms(crtc);
>
> /* we borrow the event spin lock for protecting flip_wrok */
> spin_lock_irqsave(>dev->event_lock, flags);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 955b78f1bba4..bc2fa428013f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1388,10 +1388,6 @@ static struct drm_driver kms_driver = {
> .postclose = amdgpu_driver_postclose_kms,
> .lastclose = amdgpu_driver_lastclose_kms,
> .unload = amdgpu_driver_unload_kms,
> -   .get_vblank_counter = amdgpu_get_vblank_counter_kms,
> -   .enable_vblank = amdgpu_enable_vblank_kms,
> -   .disable_vblank = amdgpu_disable_vblank_kms,
> -   .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> .irq_handler = amdgpu_irq_handler,
> .ioctls = amdgpu_ioctls_kms,
> .gem_free_object_unlocked = amdgpu_gem_object_free,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 60591dbc2097..98c196de27a4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -1110,14 +1110,15 @@ void amdgpu_driver_postclose_kms(struct drm_device 
> *dev,
>  /**
>   * amdgpu_get_vblank_counter_kms - get frame count
>   *
> - * @dev: drm dev pointer
> - * @pipe: crtc to get the fram

Re: [Nouveau] [PATCH v4 04/22] drm/amdgpu: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

[Alex Deucher]

On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann  wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> amdgpu over.
>
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 12 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 11 ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  5 +
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  1 +
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  1 +
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  1 +
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  1 +
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  1 +
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 ++-
>  9 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 4e699071d144..a1e769d4417d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -914,3 +914,15 @@ int amdgpu_display_crtc_idx_to_irq_type(struct 
> amdgpu_device *adev, int crtc)
> return AMDGPU_CRTC_IRQ_NONE;
> }
>  }
> +
> +bool amdgpu_crtc_get_scanout_position(struct drm_crtc *crtc,
> +   bool in_vblank_irq, int *vpos,
> +   int *hpos, ktime_t *stime, ktime_t *etime,
> +   const struct drm_display_mode *mode)
> +{
> +   struct drm_device *dev = crtc->dev;
> +   unsigned int pipe = crtc->index;
> +
> +   return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> + stime, etime, mode);
> +}
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index a9c4edca70c9..955b78f1bba4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1377,16 +1377,6 @@ int amdgpu_file_to_fpriv(struct file *filp, struct 
> amdgpu_fpriv **fpriv)
> return 0;
>  }
>
> -static bool
> -amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
> -bool in_vblank_irq, int *vpos, int *hpos,
> -ktime_t *stime, ktime_t *etime,
> -const struct drm_display_mode *mode)
> -{
> -   return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> - stime, etime, mode);
> -}
> -
>  static struct drm_driver kms_driver = {
> .driver_features =
> DRIVER_USE_AGP | DRIVER_ATOMIC |
> @@ -1402,7 +1392,6 @@ static struct drm_driver kms_driver = {
> .enable_vblank = amdgpu_enable_vblank_kms,
> .disable_vblank = amdgpu_disable_vblank_kms,
> .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> -   .get_scanout_position = amdgpu_get_crtc_scanout_position,
> .irq_handler = amdgpu_irq_handler,
> .ioctls = amdgpu_ioctls_kms,
> .gem_free_object_unlocked = amdgpu_gem_object_free,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index eb9975f4decb..37ba07e2feb5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -612,6 +612,11 @@ void amdgpu_panel_mode_fixup(struct drm_encoder *encoder,
>  struct drm_display_mode *adjusted_mode);
>  int amdgpu_display_crtc_idx_to_irq_type(struct amdgpu_device *adev, int 
> crtc);
>
> +bool amdgpu_crtc_get_scanout_position(struct drm_crtc *crtc,
> +   bool in_vblank_irq, int *vpos,
> +   int *hpos, ktime_t *stime, ktime_t *etime,
> +   const struct drm_display_mode *mode);
> +
>  /* fbdev layer */
>  int amdgpu_fbdev_init(struct amdgpu_device *adev);
>  void amdgpu_fbdev_fini(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 40d2ac723dd6..bdc1e0f036d4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2685,6 +2685,7 @@ static const struct drm_crtc_helper_funcs 
> dce_v10_0_crtc_helper_funcs = {
> .prepare = dce_v10_0_crtc_prepare,
> .commit = dce_v10_0_crtc_commit,
> .disable = dce_v10_0_crtc_disable,
> +   .get_scanout_position = amdgpu_crtc_get_scanout_position,
>  };

Re: [Nouveau] [PATCH v4 10/22] drm/radeon: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

[Alex Deucher]

On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann  wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> radeon over.
>
> v4:
> * 80-character line fixes
>
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/atombios_crtc.c  |  1 +
>  drivers/gpu/drm/radeon/radeon_display.c | 13 +
>  drivers/gpu/drm/radeon/radeon_drv.c | 11 ---
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c |  3 ++-
>  drivers/gpu/drm/radeon/radeon_mode.h|  6 ++
>  5 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index be583695427a..91811757104c 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -2231,6 +2231,7 @@ static const struct drm_crtc_helper_funcs 
> atombios_helper_funcs = {
> .prepare = atombios_crtc_prepare,
> .commit = atombios_crtc_commit,
> .disable = atombios_crtc_disable,
> +   .get_scanout_position = radeon_get_crtc_scanout_position,
>  };
>
>  void radeon_atombios_init_crtc(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 856526cb2caf..2f641f3b39e7 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -1978,3 +1978,16 @@ int radeon_get_crtc_scanoutpos(struct drm_device *dev, 
> unsigned int pipe,
>
> return ret;
>  }
> +
> +bool
> +radeon_get_crtc_scanout_position(struct drm_crtc *crtc,
> +bool in_vblank_irq, int *vpos, int *hpos,
> +ktime_t *stime, ktime_t *etime,
> +const struct drm_display_mode *mode)
> +{
> +   struct drm_device *dev = crtc->dev;
> +   unsigned int pipe = crtc->index;
> +
> +   return radeon_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> + stime, etime, mode);
> +}
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index fd74e2611185..1f597f166bff 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -563,16 +563,6 @@ static const struct file_operations 
> radeon_driver_kms_fops = {
>  #endif
>  };
>
> -static bool
> -radeon_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
> -bool in_vblank_irq, int *vpos, int *hpos,
> -ktime_t *stime, ktime_t *etime,
> -const struct drm_display_mode *mode)
> -{
> -   return radeon_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> - stime, etime, mode);
> -}
> -
>  static struct drm_driver kms_driver = {
> .driver_features =
> DRIVER_USE_AGP | DRIVER_GEM | DRIVER_RENDER,
> @@ -585,7 +575,6 @@ static struct drm_driver kms_driver = {
> .enable_vblank = radeon_enable_vblank_kms,
> .disable_vblank = radeon_disable_vblank_kms,
> .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> -   .get_scanout_position = radeon_get_crtc_scanout_position,
> .irq_preinstall = radeon_driver_irq_preinstall_kms,
> .irq_postinstall = radeon_driver_irq_postinstall_kms,
> .irq_uninstall = radeon_driver_irq_uninstall_kms,
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c 
> b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
> index a1985a552794..8817fd033cd0 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
> @@ -,7 +,8 @@ static const struct drm_crtc_helper_funcs 
> legacy_helper_funcs = {
> .mode_set_base_atomic = radeon_crtc_set_base_atomic,
> .prepare = radeon_crtc_prepare,
> .commit = radeon_crtc_commit,
> -   .disable = radeon_crtc_disable
> +   .disable = radeon_crtc_disable,
> +   .get_scanout_position = radeon_get_crtc_scanout_position,
>  };
>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index fd470d6bf3f4..3a61530c1398 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -881,6 +881,12 @@ extern int radeon_get_crtc_scanoutpos(struct drm_device 
> *dev, unsigned int pipe,
>   ktime_t *stime, ktime_t *etime,
>

Re: [Nouveau] [PATCH 02/23] drm/amdgpu: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

[Alex Deucher]

On Fri, Jan 10, 2020 at 4:21 AM Thomas Zimmermann  wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> amdgpu over.
>

I would prefer to just change the signature of
amdgpu_display_get_crtc_scanoutpos() to match the new API rather than
wrapping it again.

Alex

> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 12 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 11 ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  5 +
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  1 +
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  1 +
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  1 +
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  1 +
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  1 +
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 ++-
>  9 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 4e699071d144..a1e769d4417d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -914,3 +914,15 @@ int amdgpu_display_crtc_idx_to_irq_type(struct 
> amdgpu_device *adev, int crtc)
> return AMDGPU_CRTC_IRQ_NONE;
> }
>  }
> +
> +bool amdgpu_crtc_get_scanout_position(struct drm_crtc *crtc,
> +   bool in_vblank_irq, int *vpos,
> +   int *hpos, ktime_t *stime, ktime_t *etime,
> +   const struct drm_display_mode *mode)
> +{
> +   struct drm_device *dev = crtc->dev;
> +   unsigned int pipe = crtc->index;
> +
> +   return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> + stime, etime, mode);
> +}
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 3f6f14ce1511..0749285dd1c7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1367,16 +1367,6 @@ int amdgpu_file_to_fpriv(struct file *filp, struct 
> amdgpu_fpriv **fpriv)
> return 0;
>  }
>
> -static bool
> -amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
> -bool in_vblank_irq, int *vpos, int *hpos,
> -ktime_t *stime, ktime_t *etime,
> -const struct drm_display_mode *mode)
> -{
> -   return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> - stime, etime, mode);
> -}
> -
>  static struct drm_driver kms_driver = {
> .driver_features =
> DRIVER_USE_AGP | DRIVER_ATOMIC |
> @@ -1391,7 +1381,6 @@ static struct drm_driver kms_driver = {
> .enable_vblank = amdgpu_enable_vblank_kms,
> .disable_vblank = amdgpu_disable_vblank_kms,
> .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> -   .get_scanout_position = amdgpu_get_crtc_scanout_position,
> .irq_handler = amdgpu_irq_handler,
> .ioctls = amdgpu_ioctls_kms,
> .gem_free_object_unlocked = amdgpu_gem_object_free,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index eb9975f4decb..37ba07e2feb5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -612,6 +612,11 @@ void amdgpu_panel_mode_fixup(struct drm_encoder *encoder,
>  struct drm_display_mode *adjusted_mode);
>  int amdgpu_display_crtc_idx_to_irq_type(struct amdgpu_device *adev, int 
> crtc);
>
> +bool amdgpu_crtc_get_scanout_position(struct drm_crtc *crtc,
> +   bool in_vblank_irq, int *vpos,
> +   int *hpos, ktime_t *stime, ktime_t *etime,
> +   const struct drm_display_mode *mode);
> +
>  /* fbdev layer */
>  int amdgpu_fbdev_init(struct amdgpu_device *adev);
>  void amdgpu_fbdev_fini(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 40d2ac723dd6..bdc1e0f036d4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2685,6 +2685,7 @@ static const struct drm_crtc_helper_funcs 
> dce_v10_0_crtc_helper_funcs = {
> .prepare = dce_v10_0_crtc_prepare,
> .commit = dce_v10_0_crtc_commit,
> .disable = dce_v10_0_crtc_disable,
> +   .get_scanout_position = amdgpu_crtc_get_scanout_position,
>  };
>
>  static int dce_v10_0_crtc_init(struct amdgpu_device *adev, int index)
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 

Re: [Nouveau] [PATCH 02/23] drm/amdgpu: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

[Alex Deucher]

On Wed, Jan 15, 2020 at 4:41 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 13.01.20 um 19:52 schrieb Alex Deucher:
> > On Fri, Jan 10, 2020 at 4:21 AM Thomas Zimmermann  
> > wrote:
> >>
> >> The callback struct drm_driver.get_scanout_position() is deprecated in
> >> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> >> amdgpu over.
> >>
> >
> > I would prefer to just change the signature of
> > amdgpu_display_get_crtc_scanoutpos() to match the new API rather than
> > wrapping it again.
>
> While trying to adapt the siganture, I found that
> amdgpu_display_get_crtc_scanoutpos() requires a flags argument that is
> not mappable to the callback API. That wrapper function is necessary.
>

No worries.  We can clean them up later.  Wrapping is fine.

Alex

> Best regards
> Thomas
>
> >
> > Alex
> >
> >> Signed-off-by: Thomas Zimmermann 
> >> ---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 12 
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 11 ---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  5 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  1 +
> >>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 ++-
> >>  9 files changed, 24 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> index 4e699071d144..a1e769d4417d 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> @@ -914,3 +914,15 @@ int amdgpu_display_crtc_idx_to_irq_type(struct 
> >> amdgpu_device *adev, int crtc)
> >> return AMDGPU_CRTC_IRQ_NONE;
> >> }
> >>  }
> >> +
> >> +bool amdgpu_crtc_get_scanout_position(struct drm_crtc *crtc,
> >> +   bool in_vblank_irq, int *vpos,
> >> +   int *hpos, ktime_t *stime, ktime_t *etime,
> >> +   const struct drm_display_mode *mode)
> >> +{
> >> +   struct drm_device *dev = crtc->dev;
> >> +   unsigned int pipe = crtc->index;
> >> +
> >> +   return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> >> + stime, etime, mode);
> >> +}
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> index 3f6f14ce1511..0749285dd1c7 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> @@ -1367,16 +1367,6 @@ int amdgpu_file_to_fpriv(struct file *filp, struct 
> >> amdgpu_fpriv **fpriv)
> >> return 0;
> >>  }
> >>
> >> -static bool
> >> -amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int 
> >> pipe,
> >> -bool in_vblank_irq, int *vpos, int *hpos,
> >> -ktime_t *stime, ktime_t *etime,
> >> -const struct drm_display_mode *mode)
> >> -{
> >> -   return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> >> - stime, etime, mode);
> >> -}
> >> -
> >>  static struct drm_driver kms_driver = {
> >> .driver_features =
> >> DRIVER_USE_AGP | DRIVER_ATOMIC |
> >> @@ -1391,7 +1381,6 @@ static struct drm_driver kms_driver = {
> >> .enable_vblank = amdgpu_enable_vblank_kms,
> >> .disable_vblank = amdgpu_disable_vblank_kms,
> >> .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> >> -   .get_scanout_position = amdgpu_get_crtc_scanout_position,
> >> .irq_handler = amdgpu_irq_handler,
> >> .ioctls = amdgpu_ioctls_kms,
> >> .gem_free_object_unlocked = amdgpu_gem_object_free,
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> >> index eb9975f4decb..37ba07e2feb5 100644
> >> --- a/drivers/gpu

Re: [Nouveau] [PATCH 12/23] drm/amdgpu: Convert to CRTC VBLANK callbacks

[Alex Deucher]

On Fri, Jan 10, 2020 at 4:22 AM Thomas Zimmermann  wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert amdgpu over.

I think I'd prefer to just update the signatures of the relevant
functions rather than wrapping them.

Alex

>
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  3 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  4 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 24 +++
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  4 
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  4 
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  4 
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  4 
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  4 
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 ++
>  9 files changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 81a531b652aa..c1262ab588c9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1197,6 +1197,9 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
> fbcon);
>  u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
>  int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
>  void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
> +u32 amdgpu_crtc_get_vblank_counter(struct drm_crtc *crtc);
> +int amdgpu_crtc_enable_vblank(struct drm_crtc *crtc);
> +void amdgpu_crtc_disable_vblank(struct drm_crtc *crtc);
>  long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
>  unsigned long arg);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 0749285dd1c7..9baa1ddf8693 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1377,10 +1377,6 @@ static struct drm_driver kms_driver = {
> .postclose = amdgpu_driver_postclose_kms,
> .lastclose = amdgpu_driver_lastclose_kms,
> .unload = amdgpu_driver_unload_kms,
> -   .get_vblank_counter = amdgpu_get_vblank_counter_kms,
> -   .enable_vblank = amdgpu_enable_vblank_kms,
> -   .disable_vblank = amdgpu_disable_vblank_kms,
> -   .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> .irq_handler = amdgpu_irq_handler,
> .ioctls = amdgpu_ioctls_kms,
> .gem_free_object_unlocked = amdgpu_gem_object_free,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 60591dbc2097..efe4671fb032 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -1174,6 +1174,14 @@ u32 amdgpu_get_vblank_counter_kms(struct drm_device 
> *dev, unsigned int pipe)
> return count;
>  }
>
> +u32 amdgpu_crtc_get_vblank_counter(struct drm_crtc *crtc)
> +{
> +   struct drm_device *dev = crtc->dev;
> +   unsigned int pipe = crtc->index;
> +
> +   return amdgpu_get_vblank_counter_kms(dev, pipe);
> +}
> +
>  /**
>   * amdgpu_enable_vblank_kms - enable vblank interrupt
>   *
> @@ -1191,6 +1199,14 @@ int amdgpu_enable_vblank_kms(struct drm_device *dev, 
> unsigned int pipe)
> return amdgpu_irq_get(adev, >crtc_irq, idx);
>  }
>
> +int amdgpu_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> +   struct drm_device *dev = crtc->dev;
> +   unsigned int pipe = crtc->index;
> +
> +   return amdgpu_enable_vblank_kms(dev, pipe);
> +}
> +
>  /**
>   * amdgpu_disable_vblank_kms - disable vblank interrupt
>   *
> @@ -1207,6 +1223,14 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
> unsigned int pipe)
> amdgpu_irq_put(adev, >crtc_irq, idx);
>  }
>
> +void amdgpu_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> +   struct drm_device *dev = crtc->dev;
> +   unsigned int pipe = crtc->index;
> +
> +   amdgpu_disable_vblank_kms(dev, pipe);
> +}
> +
>  const struct drm_ioctl_desc amdgpu_ioctls_kms[] = {
> DRM_IOCTL_DEF_DRV(AMDGPU_GEM_CREATE, amdgpu_gem_create_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(AMDGPU_CTX, amdgpu_ctx_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index bdc1e0f036d4..8e62f46f0bfd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2494,6 +2494,10 @@ static const struct drm_crtc_funcs 
> dce_v10_0_crtc_funcs = {
> .set_config = amdgpu_display_crtc_set_config,
> .destroy = dce_v10_0_crtc_destroy,
> .page_flip_target = amdgpu_display_crtc_page_flip_target,
> +   .get_vblank_counter = amdgpu_crtc_get_vblank_counter,
> +   .enable_vblank = amdgpu_crtc_enable_vblank,
> +   

Re: [Nouveau] [PATCH 17/23] drm/radeon: Convert to CRTC VBLANK callbacks

[Alex Deucher]

On Fri, Jan 10, 2020 at 4:22 AM Thomas Zimmermann  wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert radeon over.
>
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/radeon_display.c | 12 --
>  drivers/gpu/drm/radeon/radeon_drv.c |  7 --
>  drivers/gpu/drm/radeon/radeon_kms.c | 29 ++---
>  3 files changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 7187158b9963..9116975b6eb9 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -45,6 +45,10 @@
>  #include "atom.h"
>  #include "radeon.h"
>
> +u32 radeon_get_vblank_counter_kms(struct drm_crtc *crtc);
> +int radeon_enable_vblank_kms(struct drm_crtc *crtc);
> +void radeon_disable_vblank_kms(struct drm_crtc *crtc);
> +
>  static void avivo_crtc_load_lut(struct drm_crtc *crtc)
>  {
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> @@ -458,7 +462,7 @@ static void radeon_flip_work_func(struct work_struct 
> *__work)
> (DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_IN_VBLANK) &&
> (!ASIC_IS_AVIVO(rdev) ||
> ((int) (work->target_vblank -
> -   dev->driver->get_vblank_counter(dev, work->crtc_id)) > 0)))
> +   crtc->funcs->get_vblank_counter(crtc)) > 0)))
> usleep_range(1000, 2000);
>
> /* We borrow the event spin lock for protecting flip_status */
> @@ -574,7 +578,7 @@ static int radeon_crtc_page_flip_target(struct drm_crtc 
> *crtc,
> }
> work->base = base;
> work->target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
> -   dev->driver->get_vblank_counter(dev, work->crtc_id);
> +   crtc->funcs->get_vblank_counter(crtc);
>
> /* We borrow the event spin lock for protecting flip_work */
> spin_lock_irqsave(>dev->event_lock, flags);
> @@ -666,6 +670,10 @@ static const struct drm_crtc_funcs radeon_crtc_funcs = {
> .set_config = radeon_crtc_set_config,
> .destroy = radeon_crtc_destroy,
> .page_flip_target = radeon_crtc_page_flip_target,
> +   .get_vblank_counter = radeon_get_vblank_counter_kms,
> +   .enable_vblank = radeon_enable_vblank_kms,
> +   .disable_vblank = radeon_disable_vblank_kms,
> +   .get_vblank_timestamp = drm_crtc_calc_vbltimestamp_from_scanoutpos,
>  };
>
>  static void radeon_crtc_init(struct drm_device *dev, int index)
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 1f597f166bff..49ce2e7d5f9e 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -119,9 +119,6 @@ void radeon_driver_postclose_kms(struct drm_device *dev,
>  int radeon_suspend_kms(struct drm_device *dev, bool suspend,
>bool fbcon, bool freeze);
>  int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon);
> -u32 radeon_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
> -int radeon_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
> -void radeon_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
>  void radeon_driver_irq_preinstall_kms(struct drm_device *dev);
>  int radeon_driver_irq_postinstall_kms(struct drm_device *dev);
>  void radeon_driver_irq_uninstall_kms(struct drm_device *dev);
> @@ -571,10 +568,6 @@ static struct drm_driver kms_driver = {
> .postclose = radeon_driver_postclose_kms,
> .lastclose = radeon_driver_lastclose_kms,
> .unload = radeon_driver_unload_kms,
> -   .get_vblank_counter = radeon_get_vblank_counter_kms,
> -   .enable_vblank = radeon_enable_vblank_kms,
> -   .disable_vblank = radeon_disable_vblank_kms,
> -   .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> .irq_preinstall = radeon_driver_irq_preinstall_kms,
> .irq_postinstall = radeon_driver_irq_postinstall_kms,
> .irq_uninstall = radeon_driver_irq_uninstall_kms,
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index d24f23a81656..cab891f86dc0 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -739,14 +739,15 @@ void radeon_driver_postclose_kms(struct drm_device *dev,
>  /**
>   * radeon_get_vblank_counter_kms - get frame count
>   *
> - * @dev: drm dev pointer
&g

Re: [Nouveau] [PATCH 05/23] drm/radeon: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

[Alex Deucher]

On Fri, Jan 10, 2020 at 4:22 AM Thomas Zimmermann  wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> radeon over.
>

I'd prefer to just change the signature of
radeon_get_crtc_scanoutpos() to match the new API.

Alex

> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/radeon/atombios_crtc.c  |  1 +
>  drivers/gpu/drm/radeon/radeon_display.c | 13 +
>  drivers/gpu/drm/radeon/radeon_drv.c | 11 ---
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c |  3 ++-
>  drivers/gpu/drm/radeon/radeon_mode.h|  6 ++
>  5 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index da2c9e295408..447d74b78f19 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -2232,6 +2232,7 @@ static const struct drm_crtc_helper_funcs 
> atombios_helper_funcs = {
> .prepare = atombios_crtc_prepare,
> .commit = atombios_crtc_commit,
> .disable = atombios_crtc_disable,
> +   .get_scanout_position = radeon_get_crtc_scanout_position,
>  };
>
>  void radeon_atombios_init_crtc(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 962575e27cde..7187158b9963 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -1978,3 +1978,16 @@ int radeon_get_crtc_scanoutpos(struct drm_device *dev, 
> unsigned int pipe,
>
> return ret;
>  }
> +
> +bool
> +radeon_get_crtc_scanout_position(struct drm_crtc *crtc,
> +bool in_vblank_irq, int *vpos, int *hpos,
> +ktime_t *stime, ktime_t *etime,
> +const struct drm_display_mode *mode)
> +{
> +   struct drm_device *dev = crtc->dev;
> +   unsigned int pipe = crtc->index;
> +
> +   return radeon_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> + stime, etime, mode);
> +}
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index fd74e2611185..1f597f166bff 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -563,16 +563,6 @@ static const struct file_operations 
> radeon_driver_kms_fops = {
>  #endif
>  };
>
> -static bool
> -radeon_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
> -bool in_vblank_irq, int *vpos, int *hpos,
> -ktime_t *stime, ktime_t *etime,
> -const struct drm_display_mode *mode)
> -{
> -   return radeon_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> - stime, etime, mode);
> -}
> -
>  static struct drm_driver kms_driver = {
> .driver_features =
> DRIVER_USE_AGP | DRIVER_GEM | DRIVER_RENDER,
> @@ -585,7 +575,6 @@ static struct drm_driver kms_driver = {
> .enable_vblank = radeon_enable_vblank_kms,
> .disable_vblank = radeon_disable_vblank_kms,
> .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> -   .get_scanout_position = radeon_get_crtc_scanout_position,
> .irq_preinstall = radeon_driver_irq_preinstall_kms,
> .irq_postinstall = radeon_driver_irq_postinstall_kms,
> .irq_uninstall = radeon_driver_irq_uninstall_kms,
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c 
> b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
> index a1985a552794..8817fd033cd0 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
> @@ -,7 +,8 @@ static const struct drm_crtc_helper_funcs 
> legacy_helper_funcs = {
> .mode_set_base_atomic = radeon_crtc_set_base_atomic,
> .prepare = radeon_crtc_prepare,
> .commit = radeon_crtc_commit,
> -   .disable = radeon_crtc_disable
> +   .disable = radeon_crtc_disable,
> +   .get_scanout_position = radeon_get_crtc_scanout_position,
>  };
>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index fd470d6bf3f4..06c4c527d376 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -881,6 +881,12 @@ extern int radeon_get_crtc_scanoutpos(struct drm_device 
> *dev, unsigned int pipe,
>   ktime_t *stime, ktime_t *etime,
>   const struct drm_display_mode *mode);
>
> +extern bool radeon_get_crtc_scanout_position(struct drm_crtc *crtc,
> +bool in_vblank_irq, int *vpos,
> +int *hpos, ktime_t *stime,
> +   

Re: [Nouveau] [PATCH v2 23/27] drm/amdgpu: Iterate through DRM connectors correctly

[Alex Deucher]

On Fri, Sep 13, 2019 at 4:45 PM Alex Deucher  wrote:
>
> On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul  wrote:
> >
> > Currently, every single piece of code in amdgpu that loops through
> > connectors does it incorrectly and doesn't use the proper list iteration
> > helpers, drm_connector_list_iter_begin() and
> > drm_connector_list_iter_end(). Yeesh.
> >
> > So, do that.
>
> In fairness, I think the origin of this code predated the iterators.
> Reviewed-by: Alex Deucher 
>

Applied.  Thanks!

Alex

> >
> > Cc: Juston Li 
> > Cc: Imre Deak 
> > Cc: Ville Syrjälä 
> > Cc: Harry Wentland 
> > Cc: Daniel Vetter 
> > Signed-off-by: Lyude Paul 
> > ---
> >  .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 13 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 20 +++---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  5 ++-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c  | 40 +--
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c   |  5 ++-
> >  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 34 
> >  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 34 
> >  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 40 ++-
> >  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 34 
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 ---
> >  .../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 10 -
> >  11 files changed, 195 insertions(+), 73 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > index ece55c8fa673..bd31bb595c04 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > @@ -1022,8 +1022,12 @@ amdgpu_connector_dvi_detect(struct drm_connector 
> > *connector, bool force)
> >  */
> > if (amdgpu_connector->shared_ddc && (ret == 
> > connector_status_connected)) {
> > struct drm_connector *list_connector;
> > +   struct drm_connector_list_iter iter;
> > struct amdgpu_connector 
> > *list_amdgpu_connector;
> > -   list_for_each_entry(list_connector, 
> > >mode_config.connector_list, head) {
> > +
> > +   drm_connector_list_iter_begin(dev, );
> > +   drm_for_each_connector_iter(list_connector,
> > +   ) {
> > if (connector == list_connector)
> > continue;
> > list_amdgpu_connector = 
> > to_amdgpu_connector(list_connector);
> > @@ -1040,6 +1044,7 @@ amdgpu_connector_dvi_detect(struct drm_connector 
> > *connector, bool force)
> > }
> > }
> > }
> > +   drm_connector_list_iter_end();
> > }
> > }
> > }
> > @@ -1501,6 +1506,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> >  {
> > struct drm_device *dev = adev->ddev;
> > struct drm_connector *connector;
> > +   struct drm_connector_list_iter iter;
> > struct amdgpu_connector *amdgpu_connector;
> > struct amdgpu_connector_atom_dig *amdgpu_dig_connector;
> > struct drm_encoder *encoder;
> > @@ -1515,10 +1521,12 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> > return;
> >
> > /* see if we already added it */
> > -   list_for_each_entry(connector, >mode_config.connector_list, 
> > head) {
> > +   drm_connector_list_iter_begin(dev, );
> > +   drm_for_each_connector_iter(connector, ) {
> > amdgpu_connector = to_amdgpu_connector(connector);
> > if (amdgpu_connector->connector_id == connector_id) {
> > amdgpu_connector->devices |= supported_device;
> > +   drm_connector_list_iter_end();
> > return;
> > }
> > if (amdgpu_connector->ddc_bus && i2c_bus->valid) {
> > @@ -1533,6 +1541,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> > 

Re: [Nouveau] [PATCH TRIVIAL v2] gpu: Fix Kconfig indentation

[Alex Deucher]

On Mon, Oct 7, 2019 at 7:39 AM Jani Nikula  wrote:
>
> On Fri, 04 Oct 2019, Krzysztof Kozlowski  wrote:
> >  drivers/gpu/drm/i915/Kconfig |  12 +-
> >  drivers/gpu/drm/i915/Kconfig.debug   | 144 +++
>
> Please split these out to a separate patch. Can't speak for others, but
> the patch looks like it'll be conflicts galore and a problem to manage
> if merged in one big lump.

Yes, it would be nice to have the amd patch separate as well.

Alex

>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2 23/27] drm/amdgpu: Iterate through DRM connectors correctly

[Alex Deucher]

On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul  wrote:
>
> Currently, every single piece of code in amdgpu that loops through
> connectors does it incorrectly and doesn't use the proper list iteration
> helpers, drm_connector_list_iter_begin() and
> drm_connector_list_iter_end(). Yeesh.
>
> So, do that.

In fairness, I think the origin of this code predated the iterators.
Reviewed-by: Alex Deucher 

>
> Cc: Juston Li 
> Cc: Imre Deak 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Daniel Vetter 
> Signed-off-by: Lyude Paul 
> ---
>  .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 13 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 20 +++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  5 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c  | 40 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c   |  5 ++-
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 34 
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 34 
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 40 ++-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 34 
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 10 -
>  11 files changed, 195 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index ece55c8fa673..bd31bb595c04 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -1022,8 +1022,12 @@ amdgpu_connector_dvi_detect(struct drm_connector 
> *connector, bool force)
>  */
> if (amdgpu_connector->shared_ddc && (ret == 
> connector_status_connected)) {
> struct drm_connector *list_connector;
> +   struct drm_connector_list_iter iter;
> struct amdgpu_connector 
> *list_amdgpu_connector;
> -   list_for_each_entry(list_connector, 
> >mode_config.connector_list, head) {
> +
> +   drm_connector_list_iter_begin(dev, );
> +   drm_for_each_connector_iter(list_connector,
> +   ) {
> if (connector == list_connector)
> continue;
> list_amdgpu_connector = 
> to_amdgpu_connector(list_connector);
> @@ -1040,6 +1044,7 @@ amdgpu_connector_dvi_detect(struct drm_connector 
> *connector, bool force)
> }
> }
> }
> +   drm_connector_list_iter_end();
> }
> }
> }
> @@ -1501,6 +1506,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
>  {
> struct drm_device *dev = adev->ddev;
> struct drm_connector *connector;
> +   struct drm_connector_list_iter iter;
> struct amdgpu_connector *amdgpu_connector;
> struct amdgpu_connector_atom_dig *amdgpu_dig_connector;
> struct drm_encoder *encoder;
> @@ -1515,10 +1521,12 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> return;
>
> /* see if we already added it */
> -   list_for_each_entry(connector, >mode_config.connector_list, 
> head) {
> +   drm_connector_list_iter_begin(dev, );
> +   drm_for_each_connector_iter(connector, ) {
> amdgpu_connector = to_amdgpu_connector(connector);
> if (amdgpu_connector->connector_id == connector_id) {
> amdgpu_connector->devices |= supported_device;
> +   drm_connector_list_iter_end();
> return;
> }
> if (amdgpu_connector->ddc_bus && i2c_bus->valid) {
> @@ -1533,6 +1541,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> }
> }
> }
> +   drm_connector_list_iter_end();
>
> /* check if it's a dp bridge */
> list_for_each_entry(encoder, >mode_config.encoder_list, head) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 2f884699eaef..acd39ce9b08e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3004,6 +3004,7 @@ int amd

Re: [Nouveau] [PATCH v2 24/27] drm/amdgpu/dm: Resume short HPD IRQs before resuming MST topology

[Alex Deucher]

On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul  wrote:
>
> Since we're going to be reprobing the entire topology state on resume
> now using sideband transactions, we need to ensure that we actually have
> short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
> So, do that.
>
> Cc: Juston Li 
> Cc: Imre Deak 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Daniel Vetter 
> Signed-off-by: Lyude Paul 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 73630e2940d4..4d3c8bff77da 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1185,15 +1185,15 @@ static int dm_resume(void *handle)
> /* program HPD filter */
> dc_resume(dm->dc);
>
> -   /* On resume we need to  rewrite the MSTM control bits to enamble 
> MST*/
> -   s3_handle_mst(ddev, false);
> -
> /*
>  * early enable HPD Rx IRQ, should be done before set mode as short
>  * pulse interrupts are used for MST
>  */
> amdgpu_dm_irq_resume_early(adev);
>
> +   /* On resume we need to  rewrite the MSTM control bits to enamble 
> MST*/
> +   s3_handle_mst(ddev, false);
> +
> /* Do detection*/
> drm_connector_list_iter_begin(ddev, );
> drm_for_each_connector_iter(connector, ) {
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

[Alex Deucher]

On Thu, Sep 5, 2019 at 11:51 AM Karol Herbst  wrote:
>
> is there any update on the testing with my patches? On the hardware I
> had access to those patches helped, but I can't know if it also helped
> on the hardware for which those workarounds where actually added.
>
> On Mon, Aug 19, 2019 at 11:52 AM Rafael J. Wysocki  wrote:
> >
> > On Thursday, August 15, 2019 12:47:35 AM CEST Dave Airlie wrote:
> > > On Thu, 15 Aug 2019 at 07:31, Karol Herbst  wrote:
> > > >
> > > > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
> > > >
> > > > The original commit message didn't even make sense. AMD _does_ support 
> > > > it and
> > > > it works with Nouveau as well.
> > > >
> > > > Also what was the issue being solved here? No references to any bugs 
> > > > and not
> > > > even explaining any issue at all isn't the way we do things.
> > > >
> > > > And even if it means a muxed design, then the fix is to make it work 
> > > > inside the
> > > > driver, not adding some hacky workaround through ACPI tricks.
> > > >
> > > > And what out of tree drivers do or do not support we don't care one bit 
> > > > anyway.
> > > >
> > >
> > > I think the reverts should be merged via Rafael's tree as the original
> > > patches went in via there, and we should get them in asap.
> > >
> > > Acked-by: Dave Airlie 
> >
> > The _OSI strings are to be dropped when all of the needed support is there 
> > in
> > drivers, so they should go away along with the requisite driver changes.
> >
>
> that goes beside the point. firmware level workarounds for GPU driver
> issues were pushed without consulting with upstream GPU developers.
> That's something which shouldn't have happened in the first place. And
> yes, I am personally annoyed by the fact, that people know about
> issues, but instead of contacting the proper persons and working on a
> proper fix, we end up with stupid firmware level workarounds. I can't
> see why we ever would have wanted such workarounds in the first place.
>
> And I would be much happier if the next time something like that comes
> up, that the drm mailing list will be contacted as well or somebody
> involved.
>
> We could have also just disable the feature inside the driver (and
> probably we should have done that a long time ago, so that is
> essentially our fault, but still)

Generally these conversations happen between the OEM, the relevant
distro, and hw vendor prior to production so they can't always be
discussed in public.  These programs have power, feature, and distro
targets and not all of those align.  Sometimes fixing this at the
firmware level is the best way to make the product work well at launch
given the state of Linux at a particular time.  Windows already does
similar stuff so that older versions of windows will work properly on
newer hardware.  I agree that we should all strive to fix stuff
properly, but that's not always possible.

Alex

>
> > I'm all for dropping then when that's the case, so please feel free to add 
> > ACKs
> > from me to the patches in question at that point.
> >
> > Cheers,
> > Rafael
> >
> >
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

[Alex Deucher]

On Thu, Aug 15, 2019 at 12:19 PM  wrote:
>
> > -Original Message-
> > From: Takashi Iwai 
> > Sent: Thursday, August 15, 2019 9:57 AM
> > To: Alex Deucher
> > Cc: Karol Herbst; Limonciello, Mario; nouveau; Rafael J . Wysocki; LKML; 
> > dri-devel;
> > Linux ACPI Mailing List; Alex Hung; Ben Skeggs; David Airlie
> > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string 
> > to
> > enable dGPU direct output"
> >
> >
> > [EXTERNAL EMAIL]
> >
> > On Thu, 15 Aug 2019 16:37:05 +0200,
> > Alex Deucher wrote:
> > >
> > > On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst  wrote:
> > > >
> > > > On Thu, Aug 15, 2019 at 4:20 PM  wrote:
> > > > >
> > > > > > > There are definitely going to be regressions on machines in the 
> > > > > > > field
> > with the
> > > > > > > in tree drivers by reverting this.  I think we should have an 
> > > > > > > answer for all
> > of
> > > > > > those
> > > > > > > before this revert is accepted.
> > > > > > >
> > > > > > > Regarding systems with Intel+NVIDIA, we'll have to work with 
> > > > > > > partners
> > to
> > > > > > collect
> > > > > > > some information on the impact of reverting this.
> > > > > > >
> > > > > > > When this is used on a system with Intel+AMD the ASL configures 
> > > > > > > AMD
> > GPU to
> > > > > > use
> > > > > > > "Hybrid Graphics" when on Windows and "Power Express" and
> > "Switchable
> > > > > > Graphics"
> > > > > > > when on Linux.
> > > > > >
> > > > > > and what's exactly the difference between those? And what's the 
> > > > > > actual
> > > > > > issue here?
> > > > >
> > > > > DP/HDMI is not detected unless plugged in at bootup.  It's due to 
> > > > > missing
> > HPD
> > > > > events.
> > > > >
> > > >
> > > > afaik Lyude was working on fixing all that, at least for some drivers.
> > > > If there is something wrong, we still should fix the drivers, not
> > > > adding ACPI workarounds.
> > > >
> > > > Alex: do you know if there are remaining issues regarding that with 
> > > > amdgpu?
> > >
> > > There was an issue with hpd events not making it to the audio side
> > > when things were powered down that was fixed with this patch set:
> > > https://patchwork.freedesktop.org/patch/316793/
> > > Those patches depended on a bunch of alsa changes as well which may
> > > have not been available in the distro used for a particular OEM
> > > program.
> >
> > FYI, the corresponding commit for ALSA part is destined for 5.4
> > kernel:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=ade
> > 49db337a9d44ac5835cfce1ee873549011b27
> >
> > BTW, Nouveau should suffer from the same problem.  The patch to add
> > the audio component support is found at:
> >   https://patchwork.freedesktop.org/patch/319131/
> >
> >
>
> It sounds like 5.3rcX won't be a useful check then.
>
> So am I correct to understand that everything related to the AMD failures
> described in this thread should be in linux-next at this point?
>

Assuming you mean the missing audio hotplug events, then yes.

Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

[Alex Deucher]

On Thu, Aug 15, 2019 at 10:37 AM Alex Deucher  wrote:
>
> On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst  wrote:
> >
> > On Thu, Aug 15, 2019 at 4:20 PM  wrote:
> > >
> > > > > There are definitely going to be regressions on machines in the field 
> > > > > with the
> > > > > in tree drivers by reverting this.  I think we should have an answer 
> > > > > for all of
> > > > those
> > > > > before this revert is accepted.
> > > > >
> > > > > Regarding systems with Intel+NVIDIA, we'll have to work with partners 
> > > > > to
> > > > collect
> > > > > some information on the impact of reverting this.
> > > > >
> > > > > When this is used on a system with Intel+AMD the ASL configures AMD 
> > > > > GPU to
> > > > use
> > > > > "Hybrid Graphics" when on Windows and "Power Express" and "Switchable
> > > > Graphics"
> > > > > when on Linux.
> > > >
> > > > and what's exactly the difference between those? And what's the actual
> > > > issue here?
> > >
> > > DP/HDMI is not detected unless plugged in at bootup.  It's due to missing 
> > > HPD
> > > events.
> > >
> >
> > afaik Lyude was working on fixing all that, at least for some drivers.
> > If there is something wrong, we still should fix the drivers, not
> > adding ACPI workarounds.
> >
> > Alex: do you know if there are remaining issues regarding that with amdgpu?
>
> There was an issue with hpd events not making it to the audio side
> when things were powered down that was fixed with this patch set:
> https://patchwork.freedesktop.org/patch/316793/
> Those patches depended on a bunch of alsa changes as well which may
> have not been available in the distro used for a particular OEM
> program.
>
> >
> > > >
> > > > We already have the PRIME offloading in place and if that's not
> > > > enough, we should work on extending it, not adding some ACPI based
> > > > workarounds, because that's exactly how that looks like.
> > > >
> > > > Also, was this discussed with anybody involved in the drm subsystem?
> > > >
> > > > >
> > > > > I feel we need a knob and/or DMI detection to affect the changes that 
> > > > > the ASL
> > > > > normally performs.
> > > >
> > > > Why do we have to do that on a firmware level at all?
> > >
> > > Folks from AMD Graphics team recommended this approach.  From their 
> > > perspective
> > > it's not a workaround.  They view this as a different architecture for 
> > > AMD graphics driver on
> > > Windows and AMD graphics w/ amdgpu driver.  They have different ASL paths 
> > > used for
> > > each.
> >
> > @alex: is this true?
>
> I'm not familiar with this patches in particular, but I know we've
> done things with OEM programs to support Linux on platforms where
> Linux support is lacking for in new features for the target distros.
> E.g., when the first hybrid graphics laptops were coming out, Linux
> didn't support it too well or at all depending on the timing, so the
> bios exposed power express which was working well at the time if the
> OS told ACPI it was Linux.

FWIW, windows does something similar.  I don't think windows 7
supports hybrid graphics either so if the OS tells ACPI it's windows
7, it gets power express instead of hybrid graphics as well.  At least
on laptops that support windows 7 in the first place.

Alex

>
> Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

[Alex Deucher]

On Thu, Aug 15, 2019 at 10:30 AM  wrote:
>
> > On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst  wrote:
> > >
> > > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher 
> > wrote:
> > > >
> > > > On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst  
> > > > wrote:
> > > > >
> > > > > On Thu, Aug 15, 2019 at 3:56 PM  wrote:
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: linux-acpi-ow...@vger.kernel.org  > ow...@vger.kernel.org> On
> > > > > > > Behalf Of Dave Airlie
> > > > > > > Sent: Wednesday, August 14, 2019 5:48 PM
> > > > > > > To: Karol Herbst
> > > > > > > Cc: LKML; Linux ACPI; dri-devel; nouveau; Rafael J . Wysocki; 
> > > > > > > Alex Hung;
> > Ben
> > > > > > > Skeggs; Dave Airlie
> > > > > > > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM 
> > > > > > > _OSI
> > string to
> > > > > > > enable dGPU direct output"
> > > > > > >
> > > > > > > On Thu, 15 Aug 2019 at 07:31, Karol Herbst 
> > wrote:
> > > > > > > >
> > > > > > > > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
> > > > > > > >
> > > > > > > > The original commit message didn't even make sense. AMD _does_
> > support it and
> > > > > > > > it works with Nouveau as well.
> > > > > > > >
> > > > > > > > Also what was the issue being solved here? No references to any 
> > > > > > > > bugs
> > and not
> > > > > > > > even explaining any issue at all isn't the way we do things.
> > > > > > > >
> > > > > > > > And even if it means a muxed design, then the fix is to make it 
> > > > > > > > work
> > inside the
> > > > > > > > driver, not adding some hacky workaround through ACPI tricks.
> > > > > > > >
> > > > > > > > And what out of tree drivers do or do not support we don't care 
> > > > > > > > one
> > bit anyway.
> > > > > > > >
> > > > > > >
> > > > > > > I think the reverts should be merged via Rafael's tree as the 
> > > > > > > original
> > > > > > > patches went in via there, and we should get them in asap.
> > > > > > >
> > > > > > > Acked-by: Dave Airlie 
> > > > > > > Dave.
> > > > > >
> > > > > > There are definitely going to be regressions on machines in the 
> > > > > > field with
> > the
> > > > > > in tree drivers by reverting this.  I think we should have an 
> > > > > > answer for all
> > of those
> > > > > > before this revert is accepted.
> > > > > >
> > > > > > Regarding systems with Intel+NVIDIA, we'll have to work with 
> > > > > > partners to
> > collect
> > > > > > some information on the impact of reverting this.
> > > > > >
> > > > > > When this is used on a system with Intel+AMD the ASL configures AMD
> > GPU to use
> > > > > > "Hybrid Graphics" when on Windows and "Power Express" and
> > "Switchable Graphics"
> > > > > > when on Linux.
> > > > >
> > > > > and what's exactly the difference between those? And what's the actual
> > > > > issue here?
> > > >
> > > > Hybrid Graphics is the new "standard" way of handling these laptops.
> > > > It uses the standard _PR3 APCI method to handle dGPU power.  Support
> > > > for this was added to Linux relatively later compared to when the
> > > > laptops were launched.  "Power Express" used the other AMD specific
> > > > ATPX ACPI method to handle dGPU power.  The driver supports both so
> > > > either method will work.
> > > >
> > > > Alex
> > > >
> > >
> > > thanks for clarifying. But that still means that we won't need such
> > > workarounds for AMD users, right? amdgpu handles hybrid graphics just
> > > fine, right?
> >
> > Yeah it should, assuming you have a new enough kernel which supports
> > HG, which has been several years at this point IIRC.
> >
> > Alex
> >
>
> Can you define how new of a kernel is a new enough kernel?
>
> Looking on my side these problems were on new hardware (Precision 7740) and
> are checked as recently as start of this summer, w/ kernel 4.15.

I don't remember off hand.  It was before the _PR3 support in the pci
subsystem was upstream.  What was the problem you were seeing with
this system?

Alex

>
> We can arrange to have it checked again on 5.3rcX w/ the OSI disabled.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

[Alex Deucher]

On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst  wrote:
>
> On Thu, Aug 15, 2019 at 4:20 PM  wrote:
> >
> > > > There are definitely going to be regressions on machines in the field 
> > > > with the
> > > > in tree drivers by reverting this.  I think we should have an answer 
> > > > for all of
> > > those
> > > > before this revert is accepted.
> > > >
> > > > Regarding systems with Intel+NVIDIA, we'll have to work with partners to
> > > collect
> > > > some information on the impact of reverting this.
> > > >
> > > > When this is used on a system with Intel+AMD the ASL configures AMD GPU 
> > > > to
> > > use
> > > > "Hybrid Graphics" when on Windows and "Power Express" and "Switchable
> > > Graphics"
> > > > when on Linux.
> > >
> > > and what's exactly the difference between those? And what's the actual
> > > issue here?
> >
> > DP/HDMI is not detected unless plugged in at bootup.  It's due to missing 
> > HPD
> > events.
> >
>
> afaik Lyude was working on fixing all that, at least for some drivers.
> If there is something wrong, we still should fix the drivers, not
> adding ACPI workarounds.
>
> Alex: do you know if there are remaining issues regarding that with amdgpu?

There was an issue with hpd events not making it to the audio side
when things were powered down that was fixed with this patch set:
https://patchwork.freedesktop.org/patch/316793/
Those patches depended on a bunch of alsa changes as well which may
have not been available in the distro used for a particular OEM
program.

>
> > >
> > > We already have the PRIME offloading in place and if that's not
> > > enough, we should work on extending it, not adding some ACPI based
> > > workarounds, because that's exactly how that looks like.
> > >
> > > Also, was this discussed with anybody involved in the drm subsystem?
> > >
> > > >
> > > > I feel we need a knob and/or DMI detection to affect the changes that 
> > > > the ASL
> > > > normally performs.
> > >
> > > Why do we have to do that on a firmware level at all?
> >
> > Folks from AMD Graphics team recommended this approach.  From their 
> > perspective
> > it's not a workaround.  They view this as a different architecture for AMD 
> > graphics driver on
> > Windows and AMD graphics w/ amdgpu driver.  They have different ASL paths 
> > used for
> > each.
>
> @alex: is this true?

I'm not familiar with this patches in particular, but I know we've
done things with OEM programs to support Linux on platforms where
Linux support is lacking for in new features for the target distros.
E.g., when the first hybrid graphics laptops were coming out, Linux
didn't support it too well or at all depending on the timing, so the
bios exposed power express which was working well at the time if the
OS told ACPI it was Linux.

Alex

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

[Alex Deucher]

On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst  wrote:
>
> On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher  wrote:
> >
> > On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst  wrote:
> > >
> > > On Thu, Aug 15, 2019 at 3:56 PM  wrote:
> > > >
> > > > > -Original Message-
> > > > > From: linux-acpi-ow...@vger.kernel.org 
> > > > >  On
> > > > > Behalf Of Dave Airlie
> > > > > Sent: Wednesday, August 14, 2019 5:48 PM
> > > > > To: Karol Herbst
> > > > > Cc: LKML; Linux ACPI; dri-devel; nouveau; Rafael J . Wysocki; Alex 
> > > > > Hung; Ben
> > > > > Skeggs; Dave Airlie
> > > > > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI 
> > > > > string to
> > > > > enable dGPU direct output"
> > > > >
> > > > > On Thu, 15 Aug 2019 at 07:31, Karol Herbst  wrote:
> > > > > >
> > > > > > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
> > > > > >
> > > > > > The original commit message didn't even make sense. AMD _does_ 
> > > > > > support it and
> > > > > > it works with Nouveau as well.
> > > > > >
> > > > > > Also what was the issue being solved here? No references to any 
> > > > > > bugs and not
> > > > > > even explaining any issue at all isn't the way we do things.
> > > > > >
> > > > > > And even if it means a muxed design, then the fix is to make it 
> > > > > > work inside the
> > > > > > driver, not adding some hacky workaround through ACPI tricks.
> > > > > >
> > > > > > And what out of tree drivers do or do not support we don't care one 
> > > > > > bit anyway.
> > > > > >
> > > > >
> > > > > I think the reverts should be merged via Rafael's tree as the original
> > > > > patches went in via there, and we should get them in asap.
> > > > >
> > > > > Acked-by: Dave Airlie 
> > > > > Dave.
> > > >
> > > > There are definitely going to be regressions on machines in the field 
> > > > with the
> > > > in tree drivers by reverting this.  I think we should have an answer 
> > > > for all of those
> > > > before this revert is accepted.
> > > >
> > > > Regarding systems with Intel+NVIDIA, we'll have to work with partners 
> > > > to collect
> > > > some information on the impact of reverting this.
> > > >
> > > > When this is used on a system with Intel+AMD the ASL configures AMD GPU 
> > > > to use
> > > > "Hybrid Graphics" when on Windows and "Power Express" and "Switchable 
> > > > Graphics"
> > > > when on Linux.
> > >
> > > and what's exactly the difference between those? And what's the actual
> > > issue here?
> >
> > Hybrid Graphics is the new "standard" way of handling these laptops.
> > It uses the standard _PR3 APCI method to handle dGPU power.  Support
> > for this was added to Linux relatively later compared to when the
> > laptops were launched.  "Power Express" used the other AMD specific
> > ATPX ACPI method to handle dGPU power.  The driver supports both so
> > either method will work.
> >
> > Alex
> >
>
> thanks for clarifying. But that still means that we won't need such
> workarounds for AMD users, right? amdgpu handles hybrid graphics just
> fine, right?

Yeah it should, assuming you have a new enough kernel which supports
HG, which has been several years at this point IIRC.

Alex

>
> > >
> > > We already have the PRIME offloading in place and if that's not
> > > enough, we should work on extending it, not adding some ACPI based
> > > workarounds, because that's exactly how that looks like.
> > >
> > > Also, was this discussed with anybody involved in the drm subsystem?
> > >
> > > >
> > > > I feel we need a knob and/or DMI detection to affect the changes that 
> > > > the ASL
> > > > normally performs.
> > >
> > > Why do we have to do that on a firmware level at all?
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

[Alex Deucher]

On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst  wrote:
>
> On Thu, Aug 15, 2019 at 3:56 PM  wrote:
> >
> > > -Original Message-
> > > From: linux-acpi-ow...@vger.kernel.org  
> > > On
> > > Behalf Of Dave Airlie
> > > Sent: Wednesday, August 14, 2019 5:48 PM
> > > To: Karol Herbst
> > > Cc: LKML; Linux ACPI; dri-devel; nouveau; Rafael J . Wysocki; Alex Hung; 
> > > Ben
> > > Skeggs; Dave Airlie
> > > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI 
> > > string to
> > > enable dGPU direct output"
> > >
> > > On Thu, 15 Aug 2019 at 07:31, Karol Herbst  wrote:
> > > >
> > > > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
> > > >
> > > > The original commit message didn't even make sense. AMD _does_ support 
> > > > it and
> > > > it works with Nouveau as well.
> > > >
> > > > Also what was the issue being solved here? No references to any bugs 
> > > > and not
> > > > even explaining any issue at all isn't the way we do things.
> > > >
> > > > And even if it means a muxed design, then the fix is to make it work 
> > > > inside the
> > > > driver, not adding some hacky workaround through ACPI tricks.
> > > >
> > > > And what out of tree drivers do or do not support we don't care one bit 
> > > > anyway.
> > > >
> > >
> > > I think the reverts should be merged via Rafael's tree as the original
> > > patches went in via there, and we should get them in asap.
> > >
> > > Acked-by: Dave Airlie 
> > > Dave.
> >
> > There are definitely going to be regressions on machines in the field with 
> > the
> > in tree drivers by reverting this.  I think we should have an answer for 
> > all of those
> > before this revert is accepted.
> >
> > Regarding systems with Intel+NVIDIA, we'll have to work with partners to 
> > collect
> > some information on the impact of reverting this.
> >
> > When this is used on a system with Intel+AMD the ASL configures AMD GPU to 
> > use
> > "Hybrid Graphics" when on Windows and "Power Express" and "Switchable 
> > Graphics"
> > when on Linux.
>
> and what's exactly the difference between those? And what's the actual
> issue here?

Hybrid Graphics is the new "standard" way of handling these laptops.
It uses the standard _PR3 APCI method to handle dGPU power.  Support
for this was added to Linux relatively later compared to when the
laptops were launched.  "Power Express" used the other AMD specific
ATPX ACPI method to handle dGPU power.  The driver supports both so
either method will work.

Alex

>
> We already have the PRIME offloading in place and if that's not
> enough, we should work on extending it, not adding some ACPI based
> workarounds, because that's exactly how that looks like.
>
> Also, was this discussed with anybody involved in the drm subsystem?
>
> >
> > I feel we need a knob and/or DMI detection to affect the changes that the 
> > ASL
> > normally performs.
>
> Why do we have to do that on a firmware level at all?
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/15] amdgpu: remove CONFIG_DRM_AMDGPU_USERPTR

[Alex Deucher]

On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix  wrote:
>
> On 2019-08-06 13:44, Jason Gunthorpe wrote:
> > On Tue, Aug 06, 2019 at 07:05:53PM +0300, Christoph Hellwig wrote:
> >> The option is just used to select HMM mirror support and has a very
> >> confusing help text.  Just pull in the HMM mirror code by default
> >> instead.
> >>
> >> Signed-off-by: Christoph Hellwig 
> >> ---
> >>   drivers/gpu/drm/Kconfig |  2 ++
> >>   drivers/gpu/drm/amd/amdgpu/Kconfig  | 10 --
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  6 --
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 12 
> >>   4 files changed, 2 insertions(+), 28 deletions(-)
> > Felix, was this an effort to avoid the arch restriction on hmm or
> > something? Also can't see why this was like this.
>
> This option predates KFD's support of userptrs, which in turn predates
> HMM. Radeon has the same kind of option, though it doesn't affect HMM in
> that case.
>
> Alex, Christian, can you think of a good reason to maintain userptr
> support as an option in amdgpu? I suspect it was originally meant as a
> way to allow kernels with amdgpu without MMU notifiers. Now it would
> allow a kernel with amdgpu without HMM or MMU notifiers. I don't know if
> this is a useful thing to have.

Right.  There were people that didn't have MMU notifiers that wanted
support for the GPU.  For a lot of older APIs, a lack of userptr
support was not a big deal (it just disabled some optimizations and
API extensions), but as it becomes more relevant it may make sense to
just make it a requirement.

Alex

>
> Regards,
>Felix
>
> >
> > Reviewed-by: Jason Gunthorpe 
> >
> > Jason
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Nouveau] [PATCH] drm: Mark expected switch fall-throughs

[Alex Deucher]

On Fri, Feb 15, 2019 at 11:08 AM Gustavo A. R. Silva
 wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> Notice that, in some cases, the code comment is modified
> in accordance with what GCC is expecting to find.
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva 

Can you please split this up per driver?  A comment below as well.

> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   | 1 +
>  drivers/gpu/drm/amd/amdgpu/si_dpm.c | 2 ++
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c  | 2 ++
>  drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c  | 2 +-
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c| 2 ++
>  drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 +
>  drivers/gpu/drm/drm_vm.c| 4 ++--
>  drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
>  drivers/gpu/drm/radeon/ci_dpm.c | 2 ++
>  drivers/gpu/drm/radeon/evergreen_cs.c   | 1 +
>  drivers/gpu/drm/radeon/si_dpm.c | 2 ++
>  11 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index b8e50a34bdb3..02955e6e9dd9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -3236,6 +3236,7 @@ static void gfx_v8_0_tiling_mode_table_init(struct 
> amdgpu_device *adev)
> dev_warn(adev->dev,
>  "Unknown chip type (%d) in function 
> gfx_v8_0_tiling_mode_table_init() falling through to CHIP_CARRIZO\n",
>  adev->asic_type);
> +   /* fall through */
>
> case CHIP_CARRIZO:
> modearray[0] = (ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
> diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c 
> b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> index da58040fdbdc..41e01a7f57a4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> @@ -6216,10 +6216,12 @@ static void 
> si_request_link_speed_change_before_state_change(struct amdgpu_devic
> si_pi->force_pcie_gen = AMDGPU_PCIE_GEN2;
> if (current_link_speed == AMDGPU_PCIE_GEN2)
> break;
> +   /* fall through */
> case AMDGPU_PCIE_GEN2:
> if (amdgpu_acpi_pcie_performance_request(adev, 
> PCIE_PERF_REQ_PECI_GEN2, false) == 0)
> break;
>  #endif
> +   /* fall through */
> default:
> si_pi->force_pcie_gen = 
> si_get_current_pcie_speed(adev);
> break;
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> index a1c56f29cfeb..fd5266a58297 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> @@ -265,6 +265,7 @@ static struct atom_display_object_path_v2 
> *get_bios_object(
> && id.enum_id == obj_id.enum_id)
> return 
> >object_info_tbl.v1_4->display_path[i];
> }
> +   /* fall through */
> case OBJECT_TYPE_CONNECTOR:
> case OBJECT_TYPE_GENERIC:
> /* Both Generic and Connector Object ID
> @@ -277,6 +278,7 @@ static struct atom_display_object_path_v2 
> *get_bios_object(
> && id.enum_id == obj_id.enum_id)
> return 
> >object_info_tbl.v1_4->display_path[i];
> }
> +   /* fall through */
> default:
> return NULL;
> }
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> index 85686d917636..a24a2bda8656 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> @@ -479,7 +479,7 @@ static void program_grph_pixel_format(
> case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616F:
> sign = 1;
> floating = 1;
> -   /* no break */
> +   /* fall through */
> case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616F: /* shouldn't this get 
> float too? */
> case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616:
> grph_depth = 3;
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> index c8f5c00dd1e7..48187acac59e 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> +++ 

Re: [Nouveau] [PATCH] drm: Split out drm_probe_helper.h

[Alex Deucher]

On Tue, Jan 15, 2019 at 5:41 AM Daniel Vetter  wrote:
>
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
> drivers. And indeed, all atomic drivers are now free of
> drm_crtc_helper.h includes.
>
> v2: Make it compile. There was so much compile fail on arm drivers
> that I figured I'll better not include any of the acks on v1.
>
> v3: Massive rebase because i915 has lost a lot of drmP.h includes, but
> not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h
> there was still one, which this patch largely removes. Which means
> rolling out lots more includes all over.
>
> This will also conflict with ongoing drmP.h cleanup by others I
> expect.
>
> v3: Rebase on top of atomic bochs.
>
> Cc: Sam Ravnborg 
> Cc: Jani Nikula 
> Cc: Laurent Pinchart 
> Acked-by: Rodrigo Vivi  (v2)
> Acked-by: Benjamin Gaignard  (v2)
> Signed-off-by: Daniel Vetter 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: etna...@lists.freedesktop.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Cc: spice-de...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> Cc: linux-te...@vger.kernel.org
> Cc: xen-de...@lists.xen.org
> ---
> Merging this is going to be a bit a mess due to all the ongoing drmP.h
> cleanups. I think the following should work:
> - Apply Sam's prep patches for removing drmP.h from
>   drm_modeset_helper.h
> - Get the i915 drmP.h cleanup backmerged into drm-misc-next
> - Apply this patch.
> - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h
> - All through drm-misc-next, which has some potential for trivial
>   conflicts around #includes with other drivers unfortunately.
>
> I hope there's no other driver who'll blow up accidentally because
> someone else is doing a drmP.h cleanup. Laurent maybe?
>
> Jani, ack on this?
> -Daniel

amdgpu and radeon:
Acked-by: Alex Deucher 
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 4/7] drm: Move the legacy kms disable_all helper to crtc helpers

[Alex Deucher]

On Mon, Dec 10, 2018 at 5:04 AM Daniel Vetter  wrote:
>
> It's not a core function, and the matching atomic functions are also
> not in the core. Plus the suspend/resume helper is also already there.
>
> Needs a tiny bit of open-coding, but less midlayer beats that I think.
>
> Cc: Sam Bobroff 
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Ben Skeggs 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Rex Zhu 
> Cc: Andrey Grodzovsky 
> Cc: Huang Rui 
> Cc: Shaoyun Liu 
> Cc: Monk Liu 
> Cc: nouveau@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +-
>  drivers/gpu/drm/drm_crtc.c | 31 ---
>  drivers/gpu/drm/drm_crtc_helper.c  | 35 ++
>  drivers/gpu/drm/nouveau/nouveau_display.c  |  2 +-
>  drivers/gpu/drm/radeon/radeon_display.c|  2 +-
>  include/drm/drm_crtc.h |  2 --
>  include/drm/drm_crtc_helper.h  |  1 +
>  7 files changed, 39 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index c75badfa5c4c..e669297ffefb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2689,7 +2689,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
> amdgpu_irq_disable_all(adev);
> if (adev->mode_info.mode_config_initialized){
> if (!amdgpu_device_has_dc_support(adev))
> -   drm_crtc_force_disable_all(adev->ddev);
> +   drm_helper_force_disable_all(adev->ddev);
> else
> drm_atomic_helper_shutdown(adev->ddev);
> }
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f660819d406e..7dabbaf033a1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -104,37 +104,6 @@ int drm_crtc_force_disable(struct drm_crtc *crtc)
> return drm_mode_set_config_internal();
>  }
>
> -/**
> - * drm_crtc_force_disable_all - Forcibly turn off all enabled CRTCs
> - * @dev: DRM device whose CRTCs to turn off
> - *
> - * Drivers may want to call this on unload to ensure that all displays are
> - * unlit and the GPU is in a consistent, low power state. Takes modeset 
> locks.
> - *
> - * Note: This should only be used by non-atomic legacy drivers. For an atomic
> - * version look at drm_atomic_helper_shutdown().
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_crtc_force_disable_all(struct drm_device *dev)
> -{
> -   struct drm_crtc *crtc;
> -   int ret = 0;
> -
> -   drm_modeset_lock_all(dev);
> -   drm_for_each_crtc(crtc, dev)
> -   if (crtc->enabled) {
> -   ret = drm_crtc_force_disable(crtc);
> -   if (ret)
> -   goto out;
> -   }
> -out:
> -   drm_modeset_unlock_all(dev);
> -   return ret;
> -}
> -EXPORT_SYMBOL(drm_crtc_force_disable_all);
> -
>  static unsigned int drm_num_crtcs(struct drm_device *dev)
>  {
> unsigned int num = 0;
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index a3c81850e755..23159eb494f1 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -984,3 +984,38 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
> drm_modeset_unlock_all(dev);
>  }
>  EXPORT_SYMBOL(drm_helper_resume_force_mode);
> +
> +/**
> + * drm_helper_force_disable_all - Forcibly turn off all enabled CRTCs
> + * @dev: DRM device whose CRTCs to turn off
> + *
> + * Drivers may want to call this on unload to ensure that all displays are
> + * unlit and the GPU is in a consistent, low power state. Takes modeset 
> locks.
> + *
> + * Note: This should only be used by non-atomic legacy drivers. For an atomic
> + * version look at drm_atomic_helper_shutdown().
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_helper_force_disable_all(struct drm_device *dev)

Maybe put crtc somewhere in the function name so it's clear what we
are disabling.  With that fixed:
Reviewed-by: Alex Deucher 

> +{
> +   struct drm_crtc *crtc;
> +   int ret = 0;
> +
> +   drm_modeset_lock_all(dev);
> +   drm_for_each_crtc(crtc, dev)
> +   if (crtc->enabled) {
> +

Re: [Nouveau] [PATCH 4/7] drm: Move the legacy kms disable_all helper to crtc helpers

[Alex Deucher]

On Tue, Dec 11, 2018 at 10:53 AM Sean Paul  wrote:
>
> On Mon, Dec 10, 2018 at 10:58:20AM -0500, Alex Deucher wrote:
> > On Mon, Dec 10, 2018 at 5:04 AM Daniel Vetter  
> > wrote:
> > >
> > > It's not a core function, and the matching atomic functions are also
> > > not in the core. Plus the suspend/resume helper is also already there.
> > >
> > > Needs a tiny bit of open-coding, but less midlayer beats that I think.
> > >
> > > Cc: Sam Bobroff 
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Maarten Lankhorst 
> > > Cc: Maxime Ripard 
> > > Cc: Sean Paul 
> > > Cc: David Airlie 
> > > Cc: Ben Skeggs 
> > > Cc: Alex Deucher 
> > > Cc: "Christian König" 
> > > Cc: "David (ChunMing) Zhou" 
> > > Cc: Rex Zhu 
> > > Cc: Andrey Grodzovsky 
> > > Cc: Huang Rui 
> > > Cc: Shaoyun Liu 
> > > Cc: Monk Liu 
> > > Cc: nouveau@lists.freedesktop.org
> > > Cc: amd-...@lists.freedesktop.org
> > > ---
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +-
> > >  drivers/gpu/drm/drm_crtc.c | 31 ---
> > >  drivers/gpu/drm/drm_crtc_helper.c  | 35 ++
> > >  drivers/gpu/drm/nouveau/nouveau_display.c  |  2 +-
> > >  drivers/gpu/drm/radeon/radeon_display.c|  2 +-
> > >  include/drm/drm_crtc.h |  2 --
> > >  include/drm/drm_crtc_helper.h  |  1 +
> > >  7 files changed, 39 insertions(+), 36 deletions(-)
> > >
>
> /snip
>
> > > diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> > > b/drivers/gpu/drm/drm_crtc_helper.c
> > > index a3c81850e755..23159eb494f1 100644
> > > --- a/drivers/gpu/drm/drm_crtc_helper.c
> > > +++ b/drivers/gpu/drm/drm_crtc_helper.c
> > > @@ -984,3 +984,38 @@ void drm_helper_resume_force_mode(struct drm_device 
> > > *dev)
> > > drm_modeset_unlock_all(dev);
> > >  }
> > >  EXPORT_SYMBOL(drm_helper_resume_force_mode);
> > > +
> > > +/**
> > > + * drm_helper_force_disable_all - Forcibly turn off all enabled CRTCs
> > > + * @dev: DRM device whose CRTCs to turn off
> > > + *
> > > + * Drivers may want to call this on unload to ensure that all displays 
> > > are
> > > + * unlit and the GPU is in a consistent, low power state. Takes modeset 
> > > locks.
> > > + *
> > > + * Note: This should only be used by non-atomic legacy drivers. For an 
> > > atomic
> > > + * version look at drm_atomic_helper_shutdown().
> > > + *
> > > + * Returns:
> > > + * Zero on success, error code on failure.
> > > + */
> > > +int drm_helper_force_disable_all(struct drm_device *dev)
> >
> > Maybe put crtc somewhere in the function name so it's clear what we
> > are disabling.
>
> FWIW, I think it's more clear this way. set_config_internal will turn off
> everything attached to the crtc, so _everything_ will be disabled in this 
> case.

I'm not pressed.  RB either way for me as well.

Alex

>
> Either way,
>
> Reviewed-by: Sean Paul 
>
> Sean
>
> > With that fixed:
> > Reviewed-by: Alex Deucher 
> >
> > > +{
> > > +   struct drm_crtc *crtc;
> > > +   int ret = 0;
> > > +
> > > +   drm_modeset_lock_all(dev);
> > > +   drm_for_each_crtc(crtc, dev)
> > > +   if (crtc->enabled) {
> > > +   struct drm_mode_set set = {
> > > +   .crtc = crtc,
> > > +   };
> > > +
> > > +   ret = drm_mode_set_config_internal();
> > > +   if (ret)
> > > +   goto out;
> > > +   }
> > > +out:
> > > +   drm_modeset_unlock_all(dev);
> > > +   return ret;
> > > +}
> > > +EXPORT_SYMBOL(drm_helper_force_disable_all);
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> > > b/drivers/gpu/drm/nouveau/nouveau_display.c
> > > index f326ffd86766..5d273a655479 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> > > @@ -453,7 +453,7 @@ nouveau_display_fini(struct drm_device *dev, bool 
> > > suspend, bool runtime)
> > > if (drm_drv_uses_atomic_modeset(dev))
> > > dr

Re: [Nouveau] [PATCH (repost) 5/5] drm/amdgpu: add DisplayPort CEC-Tunneling-over-AUX support

[Alex Deucher]

On Fri, Aug 24, 2018 at 3:20 AM Hans Verkuil  wrote:
>
> On 08/23/2018 08:38 PM, Harry Wentland wrote:
> > On 2018-08-17 10:11 AM, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
> >>
> >> Signed-off-by: Hans Verkuil 
> >> Acked-by: Alex Deucher 
> >> ---
> >>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c   | 13 +++--
> >>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c |  2 ++
> >>  2 files changed, 13 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> >> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >> index 34f34823bab5..77898c95bef6 100644
> >> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >> @@ -898,6 +898,7 @@ amdgpu_dm_update_connector_after_detect(struct 
> >> amdgpu_dm_connector *aconnector)
> >>  aconnector->dc_sink = sink;
> >>  if (sink->dc_edid.length == 0) {
> >>  aconnector->edid = NULL;
> >> +drm_dp_cec_unset_edid(>dm_dp_aux.aux);
> >>  } else {
> >>  aconnector->edid =
> >>  (struct edid *) sink->dc_edid.raw_edid;
> >> @@ -905,10 +906,13 @@ amdgpu_dm_update_connector_after_detect(struct 
> >> amdgpu_dm_connector *aconnector)
> >>
> >>  drm_connector_update_edid_property(connector,
> >>  aconnector->edid);
> >> +drm_dp_cec_set_edid(>dm_dp_aux.aux,
> >> +aconnector->edid);
> >>  }
> >>  amdgpu_dm_add_sink_to_freesync_module(connector, 
> >> aconnector->edid);
> >>
> >>  } else {
> >> +drm_dp_cec_unset_edid(>dm_dp_aux.aux);
> >>  amdgpu_dm_remove_sink_from_freesync_module(connector);
> >>  drm_connector_update_edid_property(connector, NULL);
> >>  aconnector->num_modes = 0;
> >> @@ -1059,12 +1063,16 @@ static void handle_hpd_rx_irq(void *param)
> >>  drm_kms_helper_hotplug_event(dev);
> >>  }
> >>  }
> >> +
> >>  if ((dc_link->cur_link_settings.lane_count != LANE_COUNT_UNKNOWN) ||
> >> -(dc_link->type == dc_connection_mst_branch))
> >> +(dc_link->type == dc_connection_mst_branch)) {
> >>  dm_handle_hpd_rx_irq(aconnector);
> >> +}
> >
> > These lines don't really add anything functional.
>
> Oops, a left-over from debugging code. I'll remove this 'change' and post a v2
> with all the Acks/reviewed-bys.
>
> Any idea who would typically merge a patch series like this?

I (or anyone else with drm-misc rights) can push them for you, however
drm-misc is a committer tree so if you'd like access to apply patches
yourself, you could do that too.  Request access here:
https://www.freedesktop.org/wiki/AccountRequests/

Alex

>
> Regards,
>
> Hans
>
> >
> > Either way, this patch is
> > Reviewed-by: Harry Wentland 
> >
> > Harry
> >
> >>
> >> -if (dc_link->type != dc_connection_mst_branch)
> >> +if (dc_link->type != dc_connection_mst_branch) {
> >> +drm_dp_cec_irq(>dm_dp_aux.aux);
> >>  mutex_unlock(>hpd_lock);
> >> +}
> >>  }
> >>
> >>  static void register_hpd_handlers(struct amdgpu_device *adev)
> >> @@ -2732,6 +2740,7 @@ static void amdgpu_dm_connector_destroy(struct 
> >> drm_connector *connector)
> >>  dm->backlight_dev = NULL;
> >>  }
> >>  #endif
> >> +drm_dp_cec_unregister_connector(>dm_dp_aux.aux);
> >>  drm_connector_unregister(connector);
> >>  drm_connector_cleanup(connector);
> >>  kfree(connector);
> >> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> >> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> >> index 9a300732ba37..18a3a6e5ffa0 100644
> >> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> >> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> >> @@ -496,6 +496,8 @@ void amdgpu_dm_initialize_dp_connector(struct 
> >> amdgpu_display_manager *dm,
> >>  aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
> >>
> >>  drm_dp_aux_register(>dm_dp_aux.aux);
> >> +drm_dp_cec_register_connector(>dm_dp_aux.aux,
> >> +  aconnector->base.name, dm->adev->dev);
> >>  aconnector->mst_mgr.cbs = _mst_cbs;
> >>  drm_dp_mst_topology_mgr_init(
> >>  >mst_mgr,
> >>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 0/5] drm/nouveau+amdgpu: add DP CEC-Tunneling-over-AUX

[Alex Deucher]

On Thu, Aug 16, 2018 at 6:56 AM Hans Verkuil  wrote:
>
> From: Hans Verkuil 
>
> Now that the DisplayPort CEC-Tunneling-over-AUX drm+i915 support
> has been merged in the mainline kernel it is time to roll this
> out to nouveau and amdgpu as well.
>
> I combined both in the same patch series since both depend on the
> same first patch, the comments in this cover letter apply to both
> and the implementation is also very similar (and simple).
>
> As mentioned, the first patch is required for this: it adds checks that
> the drm_dp_cec functions are called with a working aux implementation.
> These checks weren't necessary for the i915, but nouveau and amdgpu
> require them.
>
> The next two patches update a comment in drm_dp_cec.c and fix a bug
> in sideband AUX handling that I found while researching CEC Tunneling
> over an MST hub. It's there to prevent others from stumbling over the
> same bug in the future.
>
> The fourth patch adds support for CEC to the nouveau driver.
>
> The last patch adds support for CEC to the amdgpu driver. However, there
> appear to be two classes of amdgpu hardware: as a discrete GPU or
> integrated. I only have a discrete GPU, so I can't test the integrated
> GPU support and I only implemented this for the discrete GPU case.
>
> If someone has the integrated GPU and wants to get this working and is
> willing to do some testing, then please contact me. It shouldn't be
> difficult. You will likely have to buy a working DP-to-HDMI adapter.
> See https://hverkuil.home.xs4all.nl/cec-status.txt for a (sadly very
> short) list of working adapters.

Actually you added support for APUs as well.  In amdgpu, there are two
sets of modesetting code, an older less featured version
(amd/amdgpu/dce*.c) and the newer more featured code (amd/display/*).
Newer asics (vega and raven) are only supported by DC.  Older asics
are supported by both.  Eventually we'd like to remove the older
modesetting code.  I'm not really a CEC expert, but the patches look
pretty straight forward to me.  Series is:
Acked-by: Alex Deucher 

>
> Note that I may be completely off-base regarding what atombios_dp.c
> does, it's the first time I ever looked at amdgpu code.
>
> Two notes on CEC-Tunneling-over-AUX:
>
> 1) You need to be very careful about which USB-C/DP/mini-DP to HDMI
>adapters you buy. Only a few support this feature correctly today.
>Known chipsets that support this are Parade PS175 & PS176 and
>MegaChips 2900. Unfortunately almost all Parade-based adapters
>do not hook up the HDMI CEC pin to the chip, making them useless
>for this. The Parade reference design was only recently changed
>to hook up this pin, so perhaps this situation will change for
>new Parade-based adapters.
>
>Adapters based on the new MegaChips 2900 fare much better: it
>appears that their reference design *does* hook up the CEC pin.
>Club3D has adapters using this device for USB-C, DP and mini-DP
>to HDMI, and they all work fine.
>
>If anyone finds other adapters that work besides those I list
>in https://hverkuil.home.xs4all.nl/cec-status.txt, please let
>me know and I'll add them to the list.
>
>Linux is the first OS that supports this feature, so I am
>not surprised that HW support for this has been poor. Hopefully
>this will change going forward. BTW, note the irony that CEC is
>now supported for DP-to-HDMI adapters, but not for the native
>HDMI ports on NVIDIA/AMD/Intel GPUs.
>
> 2) CEC-Tunneling does not work (yet?) if there is an MST hub in
>between. I'm still researching this but this might be a limitation
>of MST.
>
> Regards,
>
> Hans
>
> Hans Verkuil (5):
>   drm_dp_cec: check that aux has a transfer function
>   drm_dp_cec: add note about good MegaChips 2900 CEC support
>   drm_dp_mst_topology: fix broken
> drm_dp_sideband_parse_remote_dpcd_read()
>   drm/nouveau: add DisplayPort CEC-Tunneling-over-AUX support
>   drm/amdgpu: add DisplayPort CEC-Tunneling-over-AUX support
>
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 13 +++--
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c|  2 ++
>  drivers/gpu/drm/drm_dp_cec.c   | 18 +-
>  drivers/gpu/drm/drm_dp_mst_topology.c  |  1 +
>  drivers/gpu/drm/nouveau/nouveau_connector.c| 17 +++--
>  5 files changed, 46 insertions(+), 5 deletions(-)
>
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 3/8] drm/fb_helper: Introduce hotplug_suspend/resume()

[Alex Deucher]

On Mon, Aug 6, 2018 at 3:34 PM, Lukas Wunner  wrote:
> On Mon, Aug 06, 2018 at 03:15:31PM -0400, Lyude Paul wrote:
>> You did mention in the review of one of my other patches that we should avoid
>> disabling polling during runtime suspend, and you're definitely right. I feel
>> a bit silly for not remembering that since I was the one who made it so that
>> i915 does polling in runtime suspend for chips without RPM HPD detection in
>> the first place because it was causing people's displays not to come up on
>> vlv...
>> Anyway: I think if we just leave output polling enabled during runtime 
>> suspend
>> that might actually fix all of the fb_helper locking issues since we won't
>> need to wait on any of the output poll workers to finish, at least I think it
>> should: I'll confirm this when I get into the office
>
> Quoth Imre Deak:
>
>"In i915 polling is on during runtime suspend only if there are outputs
> without hotplug interrupt support. A special case is when an output has
> working HPD interrupts when in D0, but no interrupts when runtime
> suspended. For these we start polling (from a scheduled work) in the
> runtime suspend hook and stop it in the runtime resume hook (again from
> a scheduled work)."
> https://lkml.org/lkml/2018/2/12/330
>
> nouveau only uses runtime PM on discrete GPUs in dual GPU laptops.
> Resuming the GPU from D3cold to D0 every few seconds to poll the
> outputs would waste too much power on such machines.
>
> The question is, why is polling running at all, since all modern
> laptops have HPD-capable ports such as DP?
>

At least on AMD GPUs, the GPU has to be powered up for HPD interrupts
to work.  On hybrid graphics laptops, depending on the OEM
configuration, the hotplug events are caught by the ACPI controller on
the motherboard when the GPU is powered down and an ACPI event is
generated which the driver can listen for and then tell userspace.
I'm not sure how nvidia handles this.  Also, some display connections
(e.g., analog DACs) don't support hotplug interrupts in the first
place so the only way to go is polling.

Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [Intel-gfx] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Alex Deucher]

On Mon, Feb 19, 2018 at 9:54 AM, Daniel Vetter  wrote:
> On Mon, Feb 19, 2018 at 03:47:42PM +0100, Lukas Wunner wrote:
>> On Mon, Feb 19, 2018 at 03:05:53PM +0100, Daniel Vetter wrote:
>> > On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
>> > > On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
>> > > > Well, userspace expects hotplug events, even when we runtime suspend
>> > > > stuff. Hence waking shit up with polling. Imo ignoring hotplug events 
>> > > > is a
>> > > > pretty serious policy decision which is ok in the context of
>> > > > vga_switcheroo, but not really as an automatic thing. E.g. usb also 
>> > > > wakes
>> > > > up if you plug something in, even with all the runtime pm stuff 
>> > > > enabled.
>> > > > Same for sata and everything else.
>> > >
>> > > On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
>> > > the gmux controller, which sends an interrupt on hotplug even if the GPU
>> > > is powered down.
>> > >
>> > > Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.
>> >
>> > Yeah, for vga_switcheroo and gmux setups shutting down polling explicitly
>> > makes sense. I think ideally we'd stop polling in the gmux handler somehow
>> > (maybe by dropping the relevant DRM_CONNECTOR_POLL flags, or outright
>> > stopping it all). But not when runtime suspending the entire gpu (e.g.
>> > idle system that shuts down the screen and everything, before it decides
>> > a few minutes later to do a full system suspend).
>>
>> nouveau, radeon and amdgpu currently use runtime PM *only* on hybrid
>> graphics laptops.
>>
>> Should the drivers later be extended to also use runtime PM in other
>> scenarios (desktop machines, eGPUs), they can easily detect whether
>> to disable polling on runtime suspend by calling apple_gmux_present()
>> on Macs or the equivalent for Optimus/ATPX.
>
> Ah, then I think the current solution is ok (if not entirely clean imo,
> but that can be fixed up whenever it hurts). Implementing runtime pm for
> other cases is up to the driver authors really (probably more pressing
> when the gpu is on the same SoC).

On our APUs, we support fairly fine grained powergating so this mostly
happens auto-magically in hw; no need for runtimepm.  We haven't
supported native analog encoders in last 3 or 4 generations of display
hw, so polling is not much of an issue going forward.  On most
integrated platforms (e.g., laptops and all-in-ones), digital hotplug
is handled by the platform (we get an ACPI ATIF notification) so we
can wake the dGPU.

Alex

> -Daniel
>
>>
>> Thanks,
>>
>> Lukas
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Alex Deucher]

On Tue, Feb 13, 2018 at 3:17 AM, Lukas Wunner <lu...@wunner.de> wrote:
> On Mon, Feb 12, 2018 at 01:58:32PM -0500, Alex Deucher wrote:
>> On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner <lu...@wunner.de> wrote:
>> > On Mon, Feb 12, 2018 at 09:03:26AM +, Mike Lothian wrote:
>> >> On 12 February 2018 at 03:39, Lukas Wunner <lu...@wunner.de> wrote:
>> >> > On Mon, Feb 12, 2018 at 12:35:51AM +, Mike Lothian wrote:
>> >> > > I've not been able to reproduce the original problem you're trying to
>> >> > > solve on amdgpu thats with or without your patch set and the above
>> >> > > "trigger" too
>> >
>> > Okay the reason you're not seeing deadlocks is because the output poll
>> > worker is not enabled.  And the output poll worker is not enabled
>> > because your discrete GPU doesn't have any outputs:
>> >
>> > [0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
>> >
>> > The outputs are only polled if there are connectors which have the
>> > DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
>> > And that only ever seems to be the case for VGA and DVI.
>> >
>> > We know based on bugzilla reports that hybrid graphics laptops do exist
>> > which poll outputs with radeon and nouveau.  If there are no laptops
>> > supported by amdgpu whose discrete GPU has polled connectors, then
>> > patch [5/5] would be unnecessary.  That is for Alex to decide.
>>
>> Most hybrid laptops don't have display connectors on the dGPU and we
>> only use polling on analog connectors, so you are not likely to run
>> into this on recent laptops.  That said, I don't know if there is some
>> OEM system out there with a VGA port on the dGPU in a hybrid laptop.
>> I guess another option is to just disable polling on hybrid laptops.
>
> If we don't know for sure, applying patch [5/5] would seem to be the
> safest approach.  (Assuming it doesn't break anything else.)


I don't have any objections.  I see no reason to leave out the amdgpu changes.

Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Alex Deucher]

On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner  wrote:
> On Mon, Feb 12, 2018 at 09:03:26AM +, Mike Lothian wrote:
>> On 12 February 2018 at 03:39, Lukas Wunner  wrote:
>> > On Mon, Feb 12, 2018 at 12:35:51AM +, Mike Lothian wrote:
>> > > I've not been able to reproduce the original problem you're trying to
>> > > solve on amdgpu thats with or without your patch set and the above
>> > > "trigger" too
>> > >
>> > > Is anything else required to trigger it, I started multiple DRI_PRIME
>> > > glxgears, in parallel, serial waiting the 12 seconds and serial within
>> > > the 12 seconds and I couldn't reproduce it
>> >
>> > The discrete GPU needs to runtime suspend, that's the trigger,
>> > so no DRI_PRIME executables should be running.  Just let it
>> > autosuspend after boot.  Do you see "waiting 12 sec" messages
>> > in dmesg?  If not it's not autosuspending.
>>
>> Yes I'm seeing those messages, I'm just not seeing the hangs
>>
>> I've attached the dmesg in case you're interested
>
> Okay the reason you're not seeing deadlocks is because the output poll
> worker is not enabled.  And the output poll worker is not enabled
> because your discrete GPU doesn't have any outputs:
>
> [0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
>
> The outputs are only polled if there are connectors which have the
> DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
> And that only ever seems to be the case for VGA and DVI.
>
> We know based on bugzilla reports that hybrid graphics laptops do exist
> which poll outputs with radeon and nouveau.  If there are no laptops
> supported by amdgpu whose discrete GPU has polled connectors, then
> patch [5/5] would be unnecessary.  That is for Alex to decide.

Most hybrid laptops don't have display connectors on the dGPU and we
only use polling on analog connectors, so you are not likely to run
into this on recent laptops.  That said, I don't know if there is some
OEM system out there with a VGA port on the dGPU in a hybrid laptop.
I guess another option is to just disable polling on hybrid laptops.

Alex

>
> However that is very good to know, so thanks a lot for your testing
> efforts, much appreciated!
>
> Kind regards,
>
> Lukas
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] swiotlb buffer is full

[Alex Deucher]

On Wed, Jan 31, 2018 at 9:20 PM, Ilia Mirkin  wrote:
> Yeah, a lot of people were getting that, as a result of some drm/ttm
> hugepage usage.
>
> Christian, did a fix ever end up going out? If so, what kernel was it
> included in?

https://lkml.org/lkml/2018/1/16/106

Alex

>
>   -ilia
>
> On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger Sanchez
>  wrote:
>> Hello,
>>
>> I've noticed firefox got randomly stuck, and as sometimes that leads to a
>> complete system lock-up, I've checked dmesg and got this:
>>
>> [Jan29 10:49] nouveau :01:00.0: swiotlb buffer is full (sz: 2097152 
>> bytes)
>> [  +0.33] swiotlb: coherent allocation failed for device :01:00.0 
>> size=2097152
>> [  +0.04] CPU: 6 PID: 1023 Comm: Xorg Not tainted 4.15.0-rc8 #1
>> [  +0.03] Hardware name: Micro-Star International Co., Ltd. 
>> GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
>> [  +0.03] Call Trace:
>> [  +0.09]  dump_stack+0x9f/0xe1
>> [  +0.08]  swiotlb_alloc_coherent+0xdf/0x150
>> [  +0.10]  ttm_dma_pool_get_pages+0x1ec/0x4b0
>> [  +0.15]  ttm_dma_populate+0x24c/0x340
>> [  +0.11]  ttm_tt_bind+0x23/0x50
>> [  +0.06]  ttm_bo_handle_move_mem+0x58c/0x5c0
>> [  +0.15]  ttm_bo_validate+0x152/0x190
>> [  +0.04]  ? ttm_bo_init_reserved+0x3d8/0x490
>> [  +0.12]  ? mutex_trylock+0xcd/0xe0
>> [  +0.04]  ? ttm_bo_handle_move_mem+0x58/0x5c0
>> [  +0.07]  ttm_bo_init_reserved+0x3f4/0x490
>> [  +0.10]  ttm_bo_init+0x2f/0xa0
>> [  +0.09]  ? nouveau_bo_invalidate_caches+0x10/0x10
>> [  +0.05]  nouveau_bo_new+0x416/0x590
>> [  +0.07]  ? nouveau_bo_invalidate_caches+0x10/0x10
>> [  +0.09]  ? nouveau_gem_new+0x100/0x100
>> [  +0.04]  nouveau_gem_new+0x49/0x100
>> [  +0.09]  nouveau_gem_ioctl_new+0x41/0xc0
>> [  +0.09]  drm_ioctl_kernel+0x59/0xb0
>> [  +0.08]  drm_ioctl+0x2c1/0x350
>> [  +0.07]  ? nouveau_gem_new+0x100/0x100
>> [  +0.12]  ? _raw_spin_unlock_irqrestore+0x4d/0x90
>> [  +0.06]  ? preempt_count_sub+0x9b/0xd0
>> [  +0.05]  ? _raw_spin_unlock_irqrestore+0x6b/0x90
>> [  +0.08]  nouveau_drm_ioctl+0x64/0xc0
>> [  +0.09]  do_vfs_ioctl+0x8e/0x690
>> [  +0.07]  ? __fget+0x116/0x200
>> [  +0.10]  SyS_ioctl+0x74/0x80
>> [  +0.09]  entry_SYSCALL_64_fastpath+0x23/0x9a
>> [  +0.04] RIP: 0033:0x7f7860c70727
>> [  +0.03] RSP: 002b:7ffcb0d3b088 EFLAGS: 0246
>>
>> Uptime is about 14 days now and I don't think I've seen this trace before.
>>
>> Is this useful/worth chasing?
>>
>> Cheers,
>>
>> --
>> Ricardo Nabinger Sanchez   http://rnsanchez.wait4.org/
>> "You never learned anything by doing it right."
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v5 0/3] Allow ASYNC flip with atomic helpers.

[Alex Deucher]

On Thu, Feb 2, 2017 at 4:56 PM, Andrey Grodzovsky
<andrey.grodzov...@amd.com> wrote:
> This series is a folow-up on
> https://patchwork.kernel.org/patch/9501787/
>
> The first patch makes changes to atomic helpers to allow for drives with 
> ASYNC flip support to use them.
> Patch 2 is to use this in AMDGPU/DC.
> Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate the 
> helper as we did to support ASYNC flips.
>
> v2:
> Resend drm/atomic: Save flip flags in drm_plane_state since the original 
> patch was incomplete.
> Squash 2 AMD changes into one to not break compilation.
>
> v3:
> Following Daniel's comments, save flip flags in crtc_state instead of 
> plane_state.
>
> v4:
> Lauren's comment, reset flp flags before using again.
> Harry's comment, fix identation in amd/display.
>
> v5:
> Rename the flag, fix typo in header.

Looks good.  The series is:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>
Unless there are any objections I'll push to drm-misc today.

Thanks!

Alex

>
> Andrey Grodzovsky (3):
>   drm/atomic: Save flip flags in drm_crtc_state
>   drm/nouveau/kms/nv50: Switch to using atomic helper for flip.
>   drm/amd/display: Switch to using atomic_helper for flip.
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   1 -
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 
> +
>  drivers/gpu/drm/drm_atomic_helper.c|  20 ++--
>  drivers/gpu/drm/nouveau/nv50_display.c |  84 ++-
>  include/drm/drm_crtc.h |   9 +-
>  5 files changed, 48 insertions(+), 179 deletions(-)
>
> --
> 1.9.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v4 0/3] Allow ASYNC flip with atomic helpers.

[Alex Deucher]

On Wed, Feb 1, 2017 at 12:03 PM, Andrey Grodzovsky
<andrey.grodzov...@amd.com> wrote:
> This series is a folow-up on
> https://patchwork.kernel.org/patch/9501787/
>
> The first patch makes changes to atomic helpers to allow for drives with 
> ASYNC flip support to use them.
> Patch 2 is to use this in AMDGPU/DC.
> Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate the 
> helper as we did to support ASYNC flips.
>
> v2:
> Resend drm/atomic: Save flip flags in drm_plane_state since the original 
> patch was incomplete.
> Squash 2 AMD changes into one to not break compilation.
>
> v3:
> Following Daniel's comments, save flip flags in crtc_state instead of 
> plane_state.
>
> v4:
> Lauren's comment, reset flp flags before using again.
> Harry's comment, fix identation in amd/display.
>
> Andrey Grodzovsky (3):
>   drm/atomic: Save flip flags in drm_crtct_state
>   drm/nouveau/kms/nv50: Switch to using atomic helper for flip.
>   drm/amd/display: Switch to using atomic_helper for flip.


A few comments on patch 1.  WIth those addressed the series is:
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>

>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   1 -
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 
> +
>  drivers/gpu/drm/drm_atomic_helper.c|  20 ++--
>  drivers/gpu/drm/nouveau/nv50_display.c |  84 ++-
>  include/drm/drm_crtc.h |   9 +-
>  include/drm/drm_plane.h|   1 +
>  6 files changed, 49 insertions(+), 179 deletions(-)
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v4 1/3] drm/atomic: Save flip flags in drm_crtct_state

[Alex Deucher]

On Wed, Feb 1, 2017 at 12:03 PM, Andrey Grodzovsky
 wrote:
> Allows using atomic flip helpers for drivers
> using ASYNC flip.
> Remove ASYNC_FLIP restriction in helpers and
> caches the page flip flags in drm_crtc_state
> to be used in the low level drivers.
>
> v2:
> Resending the patch since the original was broken.
>
> v3:
> Save flag in crtc_state instead of plane_state
>
> v4:
> Reset the flag before using again.
>
> Change-Id: I0219c3ec3ecceb82143ee176d30cb50d9aa76bf0
> Signed-off-by: Andrey Grodzovsky 

typo in the patch title:
drm_crtct_state



> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
>  include/drm/drm_crtc.h  |  9 -
>  include/drm/drm_plane.h |  1 +
>  3 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a4e5477..f84b5aa 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2737,7 +2737,8 @@ static int page_flip_common(
> struct drm_atomic_state *state,
> struct drm_crtc *crtc,
> struct drm_framebuffer *fb,
> -   struct drm_pending_vblank_event *event)
> +   struct drm_pending_vblank_event *event,
> +   uint32_t flags)
>  {
> struct drm_plane *plane = crtc->primary;
> struct drm_plane_state *plane_state;
> @@ -2749,12 +2750,12 @@ static int page_flip_common(
> return PTR_ERR(crtc_state);
>
> crtc_state->event = event;
> +   crtc_state->pflip_flags = flags;
>
> plane_state = drm_atomic_get_plane_state(state, plane);
> if (IS_ERR(plane_state))
> return PTR_ERR(plane_state);
>
> -
> ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> if (ret != 0)
> return ret;
> @@ -2781,10 +2782,6 @@ static int page_flip_common(
>   * Provides a default _crtc_funcs.page_flip implementation
>   * using the atomic driver interface.
>   *
> - * Note that for now so called async page flips (i.e. updates which are not
> - * synchronized to vblank) are not supported, since the atomic interfaces 
> have
> - * no provisions for this yet.
> - *
>   * Returns:
>   * Returns 0 on success, negative errno numbers on failure.
>   *
> @@ -2800,9 +2797,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> struct drm_atomic_state *state;
> int ret = 0;
>
> -   if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> -   return -EINVAL;
> -
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> return -ENOMEM;
> @@ -2810,7 +2804,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
>
>  retry:
> -   ret = page_flip_common(state, crtc, fb, event);
> +   ret = page_flip_common(state, crtc, fb, event, flags);
> if (ret != 0)
> goto fail;
>
> @@ -2865,9 +2859,6 @@ int drm_atomic_helper_page_flip_target(
> struct drm_crtc_state *crtc_state;
> int ret = 0;
>
> -   if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> -   return -EINVAL;
> -
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> return -ENOMEM;
> @@ -2875,7 +2866,7 @@ int drm_atomic_helper_page_flip_target(
> state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
>
>  retry:
> -   ret = page_flip_common(state, crtc, fb, event);
> +   ret = page_flip_common(state, crtc, fb, event, flags);
> if (ret != 0)
> goto fail;
>
> @@ -3072,6 +3063,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
> drm_crtc *crtc,
> state->color_mgmt_changed = false;
> state->zpos_changed = false;
> state->event = NULL;
> +   state->pflip_flags = 0;
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5c77c3f..b74dbe1 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -162,10 +162,17 @@ struct drm_crtc_state {
>  * Target vertical blank period when a page flip
>  * should take effect.
>  */
> -
> u32 target_vblank;
>
> /**
> +* @pflip_flags:
> +*
> +* DRM_MODE_PAGE_FLIP_* flags, as passed to the page flip ioctl.
> +* Zero in any other case.
> +*/
> +   u32 pflip_flags;

I can go either way on whether we call this pflip or page_flip.  I
guess it's better to spell it out.

> +
> +   /**
>  * @event:
>  *
>  * Optional pointer to a DRM event to signal upon completion of the
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h

Re: [Nouveau] [PATCH v2 2/2] drm: Get atomic property value even if DRIVER_ATOMIC is not set

[Alex Deucher]

On Wed, Dec 21, 2016 at 3:12 PM, Dhinakaran Pandiyan
 wrote:
> i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and
> atomic_commit. drm_object_property_get_value() does not read the correct
> value of atomic properties if DRIVER_ATOMIC is not set. Checking whether
> the driver uses atomic modeset is a better check instead as the property
> values are tracked in the state structures.
>

I think we are in the same boat.  Adding Andrey and Harry.

Alex

> v2: Included header
>
> Cc: Daniel Vetter 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_mode_object.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_object.c 
> b/drivers/gpu/drm/drm_mode_object.c
> index 9f17085..14543ff 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "drm_crtc_internal.h"
>
> @@ -273,7 +274,7 @@ int drm_object_property_get_value(struct drm_mode_object 
> *obj,
>  * their value in obj->properties->values[].. mostly to avoid
>  * having to deal w/ EDID and similar props in atomic paths:
>  */
> -   if (drm_core_check_feature(property->dev, DRIVER_ATOMIC) &&
> +   if (drm_drv_uses_atomic_modeset(property->dev) &&
> !(property->flags & DRM_MODE_PROP_IMMUTABLE))
> return drm_atomic_get_property(obj, property, val);
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2] drm/nouveau/acpi: fix check for power resources support

[Alex Deucher]

On Tue, Nov 1, 2016 at 3:00 PM, Peter Wu <pe...@lekensteyn.nl> wrote:
> On Tue, Nov 01, 2016 at 09:24:23AM -0400, Alex Deucher wrote:
>> On Tue, Nov 1, 2016 at 12:55 AM, Dave Airlie <airl...@gmail.com> wrote:
>> > On 1 November 2016 at 08:48, Peter Wu <pe...@lekensteyn.nl> wrote:
>> >> Check whether the kernel really supports power resources for a device,
>> >> otherwise the power might not be removed when the device is runtime
>> >> suspended (DSM should still work in these cases where PR does not).
>> >>
>> >> This is a workaround for a problem where ACPICA and Windows 10 differ in
>> >> behavior. ACPICA does not correctly enumerate power resources within a
>> >> conditional block (due to delayed execution of such blocks) and as a
>> >> result power_resources is set to false even if _PR3 exists.
>> >>
>> >> Fixes: 692a17dcc292 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM")
>> >> Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398
>> >> Reported-and-tested-by: Rick Kerkhof <rick.2...@gmail.com>
>> >> Reviewed-by: Mika Westerberg <mika.westerb...@linux.intel.com>
>> >> Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
>> >
>> > I've appled it this and cc'ed stable to drm-fixes.
>> >
>> > Are we going to get ACPICA fixed?
>
> The ACPI folks are aware of the problem, see this thread and its
> follow-ups:
> http://www.spinics.net/lists/linux-acpi/msg70050.html
>
>> Looks like we may have hit this on radeon/amdgpu as well:
>> https://bugs.freedesktop.org/show_bug.cgi?id=98505
>>
>> Alex
>
> That log seems to suggest that resume fails while this nouveau issue is
> related to suspend not powering off a device. The root cause might be
> different.

Resume (from runtime suspend) is failing because the device is not
getting powered off.  Reverting the patch that enables the use of PR3
to power off the dGPU and falls back to the old ATPX power off method
fixes the issue.  So it would appear that PR3 is either not getting
enabled for this system (perhaps due to the date check in the pci
code) or due to some problem in the ACPICA.  Note that on A+I or A+A
systems, if PR3 is available (determined by the OSI setting), it
should be used so the date shouldn't really matter in the case of
those systems.  In practice ATPX generally still works on those
systems as well, but it's not a requirement so OEMs/ODMs may not
always make it available if PR3 is exposed.

Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2] drm/nouveau/acpi: fix check for power resources support

[Alex Deucher]

On Tue, Nov 1, 2016 at 12:55 AM, Dave Airlie  wrote:
> On 1 November 2016 at 08:48, Peter Wu  wrote:
>> Check whether the kernel really supports power resources for a device,
>> otherwise the power might not be removed when the device is runtime
>> suspended (DSM should still work in these cases where PR does not).
>>
>> This is a workaround for a problem where ACPICA and Windows 10 differ in
>> behavior. ACPICA does not correctly enumerate power resources within a
>> conditional block (due to delayed execution of such blocks) and as a
>> result power_resources is set to false even if _PR3 exists.
>>
>> Fixes: 692a17dcc292 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM")
>> Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398
>> Reported-and-tested-by: Rick Kerkhof 
>> Reviewed-by: Mika Westerberg 
>> Signed-off-by: Peter Wu 
>
> I've appled it this and cc'ed stable to drm-fixes.
>
> Are we going to get ACPICA fixed?

Looks like we may have hit this on radeon/amdgpu as well:
https://bugs.freedesktop.org/show_bug.cgi?id=98505

Alex

>
> Dave.
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)

[Alex Deucher]

On Fri, Jul 15, 2016 at 12:31 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Fri, Jul 15, 2016 at 12:27 PM, Alex Deucher <alexdeuc...@gmail.com> wrote:
>> On Fri, Jul 15, 2016 at 12:10 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu <pe...@lekensteyn.nl> wrote:
>>>> Hi,
>>>>
>>>> Here are two patches to fix an issue reported on kernel bugzilla (infinite 
>>>> loop
>>>> due to unchecked function) and a more important fix to fix hanging Optimus
>>>> machines when runtime PM is enabled (with pm/pci patches).
>>>>
>>>> These are the final patches targeting v4.8. Changes compared to v2[1]:
>>>> collected R-b from Hans and Mika and fixed a minor comment style issue.
>>>>
>>>> I recommend it to be merged before the pci/pm patches[2], otherwise there 
>>>> is a
>>>> window where newer Nvidia Optimus laptops might fail to runtime resume 
>>>> and/or
>>>> lock up.  Once the pci/pm branch is merged I will propose another patch to
>>>> improve reliability[3].
>>>>
>>>> Known issue with patch 4: when a Nvidia HDMI audio function is present, the
>>>> bridge will not suspend and hence the Nvidia card will still be powered. 
>>>> Fixing
>>>
>>> That's basically all optimus gpu's, right? Anything GT21x+ has a HDMI
>>> audio subfunction, and prior to that, the nvidia gpu tended to be the
>>> only gpu, or hard-muxed.
>>
>> I'd imagine there is a strap on the asic so the audio function is only
>> enabled if there is a connector actually wired to the dGPU.  It
>> doesn't make much sense to expose audio if there is no way to use it.
>
> A lot of the time, there actually is a connector wired up. A lot of
> the other time, there is no connector, but the display unit is still
> there. Very recently, NVIDIA gpu's have started coming out marked as
> "3d accelerator", which sometimes but not always means that there's no
> display unit, and for those, I would assume there is no audio
> subfunction.
>

Just because there is a display block, doesn't mean the audio function
is always enabled.  I suspect it is disabled by hardware straps on
systems with no display connectors or other specific OEM configs.

Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)

[Alex Deucher]

On Fri, Jul 15, 2016 at 12:10 PM, Ilia Mirkin  wrote:
> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu  wrote:
>> Hi,
>>
>> Here are two patches to fix an issue reported on kernel bugzilla (infinite 
>> loop
>> due to unchecked function) and a more important fix to fix hanging Optimus
>> machines when runtime PM is enabled (with pm/pci patches).
>>
>> These are the final patches targeting v4.8. Changes compared to v2[1]:
>> collected R-b from Hans and Mika and fixed a minor comment style issue.
>>
>> I recommend it to be merged before the pci/pm patches[2], otherwise there is 
>> a
>> window where newer Nvidia Optimus laptops might fail to runtime resume and/or
>> lock up.  Once the pci/pm branch is merged I will propose another patch to
>> improve reliability[3].
>>
>> Known issue with patch 4: when a Nvidia HDMI audio function is present, the
>> bridge will not suspend and hence the Nvidia card will still be powered. 
>> Fixing
>
> That's basically all optimus gpu's, right? Anything GT21x+ has a HDMI
> audio subfunction, and prior to that, the nvidia gpu tended to be the
> only gpu, or hard-muxed.

I'd imagine there is a strap on the asic so the audio function is only
enabled if there is a connector actually wired to the dGPU.  It
doesn't make much sense to expose audio if there is no way to use it.

Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2 00/15] Runtime pm ref leak bonanza

[Alex Deucher]

On Thu, Jun 9, 2016 at 2:50 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Wed, Jun 08, 2016 at 06:47:27PM +0200, Lukas Wunner wrote:
>> Second iteration of my endeavour to rid nouveau, radeon and amdgpu of
>> runtime pm ref leaks.
>>
>> Patches 1 to 8 are identical to v1.
>>
>> Patch 9 of v1 modified the DRM core to turn off all CRTCs on driver
>> unload. Based on feedback by Daniel Vetter, I've replaced this with
>> a helper to turn off all CRTCs, which is called by nouveau, radeon
>> and amdgpu on unload. In other words, this is now opt-in.
>> So patch 9 of v1 is replaced with new patches 9 to 12.
>>
>> A by-product of patch 9 is a helper which turns off a *single* CRTC.
>> This is open coded in three other places in the DRM tree and patches
>> 13 to 15 refactor those to use the new helper.
>
> Yeah I think this makes much more sense. Please poke amd/nouveau folks for
> reviews/acks, then I can merge.

The amdgpu, radeon, and drm patches are:
Acked-by: Alex Deucher <alexander.deuc...@amd.com>

> -Daniel
>
>>
>> To ease reviewing, I've pushed this series to GitHub:
>> https://github.com/l1k/linux/commits/drm_runpm_fixes_v2
>>
>> The discussion on v1 is archived here:
>> https://lists.freedesktop.org/archives/dri-devel/2016-May/thread.html#108278
>>
>> Thanks,
>>
>> Lukas
>>
>> Lukas Wunner (15):
>>   drm/nouveau: Don't leak runtime pm ref on driver unload
>>   drm/nouveau: Forbid runtime pm on driver unload
>>   drm/radeon: Don't leak runtime pm ref on driver unload
>>   drm/radeon: Don't leak runtime pm ref on driver load
>>   drm/radeon: Forbid runtime pm on driver unload
>>   drm/amdgpu: Don't leak runtime pm ref on driver unload
>>   drm/amdgpu: Don't leak runtime pm ref on driver load
>>   drm/amdgpu: Forbid runtime pm on driver unload
>>   drm: Add helpers to turn off CRTCs
>>   drm/nouveau: Turn off CRTCs on driver unload
>>   drm/radeon: Turn off CRTCs on driver unload
>>   drm/amdgpu: Turn off CRTCs on driver unload
>>   drm: Use helper to turn off CRTC
>>   drm/i2c/ch7006: Use helper to turn off CRTC
>>   drm/nouveau/dispnv04: Use helper to turn off CRTC
>>
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  1 +
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 12 +--
>>  drivers/gpu/drm/drm_crtc.c | 53 
>> ++
>>  drivers/gpu/drm/i2c/ch7006_drv.c   |  9 ++---
>>  drivers/gpu/drm/nouveau/dispnv04/disp.c| 10 --
>>  drivers/gpu/drm/nouveau/dispnv04/tvnv17.c  |  9 ++---
>>  drivers/gpu/drm/nouveau/nouveau_display.c  |  1 +
>>  drivers/gpu/drm/nouveau/nouveau_drm.c  |  6 +++-
>>  drivers/gpu/drm/radeon/radeon_device.c |  4 +++
>>  drivers/gpu/drm/radeon/radeon_display.c|  1 +
>>  drivers/gpu/drm/radeon/radeon_kms.c|  5 ++-
>>  include/drm/drm_crtc.h |  2 ++
>>  12 files changed, 77 insertions(+), 36 deletions(-)
>>
>> --
>> 2.8.1
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] AGP cards in PCI mode (fake slots like AGPro, AGP Express, AGI, AGX, XGP)

[Alex Deucher]

On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary  wrote:
> Hello,
> I have a PC Chips A31G board with AGPro slot and found that nouveau does not
> work properly with it. Console works but reverts to software mode, X11 hangs
> with mouse cursor only.
>
> The slot is physically AGP 1.5V but is wired to PCI bus as the chipset (SiS
> 761) does not support AGP cards. To further complicate things, the chipset has
> AGP capability - but only for the integrated video. You can see that in the
> lspci output below - the AGP card is on bus 0 and SiS card on bus 1 (AGP bus
> behind the AGP bridge). The SiS card is not used (can be disabled in BIOS but
> it does not improve things - as the AGP capability of the host bridge remains
> active).
>
> As seen in dmesg below, kernel tries to set AGP 8x mode for all AGP devices,
> including the AGP 4x TNT2 card which is not even connected to the AGP bridge.
>
> Setting nouveau.agpmode=0 makes it work but how can we make this case work
> automatically?
>
> Radeon driver does some "ring test" and if it fails, it disables AGP mode and
> retries. That seems to work a bit (with R7000 but not with R7200).

You can boot with radeon.agpmode=-1 to force pci mode.

Alex

>
> But I think that we shouldn't even touch the AGP registers of other devices
> in this case as it might break the integrated video.
> But how can we know that the card is connected to the AGP bus? There does not
> seem to be a reliable way...
>
> dmesg:
> [   22.015411] nouveau  [  DEVICE][:00:05.0] BOOT0  : 0x20154000
> [   22.015473] nouveau  [  DEVICE][:00:05.0] Chipset: NV05 (NV05)
> [   22.015527] nouveau  [  DEVICE][:00:05.0] Family : NV04
> [   22.041131] nouveau  [   VBIOS][:00:05.0] using image from PRAMIN
> [   22.041194] nouveau  [   VBIOS][:00:05.0] BMP version 5.6
> [   22.041382] nouveau  [   VBIOS][:00:05.0] version 02.05.20.02.00
> [   22.041561] nouveau W[   VBIOS][:00:05.0] DCB table not found
> [   22.041867] nouveau W[   VBIOS][:00:05.0] DCB table not found
> [   22.042079] nouveau W[   VBIOS][:00:05.0] DCB table not found
> [   22.042133] nouveau W[   VBIOS][:00:05.0] DCB table not found
> [   22.042245] nouveau W[  PTIMER][:00:05.0] unknown input clock freq
> [   22.042306] nouveau  [ PFB][:00:05.0] RAM type: SDRAM
> [   22.042360] nouveau  [ PFB][:00:05.0] RAM size: 32 MiB
> [   22.042413] nouveau  [ PFB][:00:05.0]ZCOMP: 0 tags
> [   22.047063] nouveau  [ CLK][:00:05.0] --:
> [   22.047137] nouveau W[   VBIOS][:00:05.0] DCB table not found
> [   22.047220] agpgart-amd64 :00:00.0: AGP 3.0 bridge
> [   22.047281] agpgart: systemd-udevd tried to set rate=x12. Setting to AGP3 
> x8 mode.
> [   22.047348] agpgart-amd64 :00:00.0: putting AGP V3 device into 8x mode
> [   22.047425] nouveau :00:05.0: putting AGP V3 device into 8x mode
> [   22.047503] pci :01:00.0: putting AGP V3 device into 8x mode
> [   22.047632] [TTM] Zone  kernel: Available graphics memory: 239112 kiB
> [   22.047685] [TTM] Initializing pool allocator
> [   22.047744] [TTM] Initializing DMA pool allocator
> [   22.047814] nouveau  [ DRM] VRAM: 31 MiB
> [   22.047865] nouveau  [ DRM] GART: 64 MiB
> [   22.047918] nouveau  [ DRM] BMP version 5.6
> [   22.047971] nouveau W[ DRM] No DCB data found in VBIOS
> [   22.051250] nouveau  [ DRM] Saving VGA fonts
> [   22.099912] nouveau W[ DRM] No DCB data found in VBIOS
> [   22.101006] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   22.101061] [drm] Driver supports precise vblank timestamp query.
> [   22.102645] nouveau  [ DRM] MM: using M2MF for buffer copies
> [   22.133344] nouveau  [ DRM] allocated 1280x1024 fb: 0x4000, bo db2d6c00
> [   22.133545] fbcon: nouveaufb (fb0) is primary device
> [   22.369387] nouveau E[ DRM] GPU lockup - switching to software fbcon
> [   22.378443] Console: switching to colour frame buffer device 160x64
> [   22.395704] nouveau :00:05.0: fb0: nouveaufb frame buffer device
> [   22.395808] nouveau :00:05.0: registered panic notifier
> [   22.396783] [drm] Initialized nouveau 1.2.2 20120801 for :00:05.0 on 
> minor 0
>
> lspci -vvnn:
> 00:00.0 Host bridge [0600]: Silicon Integrated Systems [SiS] 761/M761 Host 
> [1039:0761] (rev 01)
> Subsystem: Elitegroup Computer Systems Device [1019:0131]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 32
> Region 0: Memory at f000 (32-bit, non-prefetchable) [size=64M]
> Capabilities: [a0] AGP version 3.0
> Status: RQ=32 Iso- ArqSz=2 Cal=3 SBA+ ITACoh- GART64- HTrans- 
> 64bit- FW- AGP3+ Rate=x4,x8
> Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- 
> Rate=x8
> Capabilities: [d0] 

Re: [Nouveau] [Mesa-dev] gallium state tracker calls calloc for 0 sizes arrays ?

[Alex Deucher]

On Thu, Aug 27, 2015 at 1:55 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 27-08-15 15:46, Marek Olšák wrote:

 On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede hdego...@redhat.com
 wrote:

 Hi All,

 While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089

 I made a apitrace recording of the a single slide transition
 animation, and since I suspected memory corruption replayed
 it using ElectrFence + glretrace, this finds a 0 sized array
 allocation at src/mesa/state_tracker/st_glsl_to_tgsi.cpp: 5565:

 if (proginfo-Parameters) {
t-constants = (struct ureg_src *)
   calloc(proginfo-Parameters-NumParameters,
 sizeof(t-constants[0]));

 And if I protect the code against that one, another one at 5618:

 t-immediates = (struct ureg_src *)
calloc(program-num_immediates, sizeof(struct ureg_src));

 With the regular glibc malloc these both succeed as it actually
 returns a valid memory address (posix says it may also return NULL)

 I believe that the fragment program in question comes from:

 src/mesa/main/state.c update_program() and then from the

 else if (ctx-FragmentProgram._MaintainTexEnvProgram) {
/* Use fragment program generated from fixed-function state */

 }

 block.

 Interestingly enough if I allow malloc(0) to proceed from ElectricFence,
 then the glretrace runs fine, and even renders correctly, where as
 running the same gl command stream from libreoffice impress leads
 to missrendering on nv3c.

 So 2 questions:

 1) Is it normal / expected for st_translate_program() to get called
 with an empty but not NULL proginfo-Parameters resp. num_immediates == 0
 ?

 If not where would I begin to look for finding the culprit of this ?


 Yes, it's normal.


 OK, thanks for the clear answer on this.

 2) Since the glretrace does work outside of libreoffice impress, I think
 it may have something to do with the visual chosen by libreoffice
 impress,
 is there an easy way to find out what visual lo is choosing?


 No, it's not because of the visual. It seems to me that libreoffice
 changed the behavior of malloc and calloc.


 I'm pretty sure that this is not libreoffice changing malloc / calloc,
 it links normally to libc, and the same slide transition works fine
 with an nv84 card which also has a gallium based mesa driver.

 I really believe this is due to libreoffice doing something opengl
 related differently then glretrace, be it the visual or something else
 back buffer related ...


Does libreoffice use llvm?  I have vague recollections of there being
issues with llvm and libreoffice in the past because radeonsi uses
llvm as well.

Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2 09/17] drm/radeon: use common fence implementation for fences

[Alex Deucher]

On Wed, Jul 9, 2014 at 9:23 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 op 09-07-14 14:57, Deucher, Alexander schreef:
 snip
 +static const char *radeon_fence_get_timeline_name(struct fence *f)
 +{
 +struct radeon_fence *fence = to_radeon_fence(f);
 +switch (fence-ring) {
 +case RADEON_RING_TYPE_GFX_INDEX: return radeon.gfx;
 +case CAYMAN_RING_TYPE_CP1_INDEX: return radeon.cp1;
 +case CAYMAN_RING_TYPE_CP2_INDEX: return radeon.cp2;
 +case R600_RING_TYPE_DMA_INDEX: return radeon.dma;
 +case CAYMAN_RING_TYPE_DMA1_INDEX: return radeon.dma1;
 +case R600_RING_TYPE_UVD_INDEX: return radeon.uvd;
 Radeon supports vce rings on newer ascis.  Probably want to add the case for 
 those here too.

 Alex

 Indeed, how about this?

Looks good.  I'll let Christian comment on the rest of the changes.

Alex

 --8---
 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
 ---
  drivers/gpu/drm/radeon/radeon.h|  15 +--
  drivers/gpu/drm/radeon/radeon_device.c |  60 -
  drivers/gpu/drm/radeon/radeon_fence.c  | 225 
 +++--
  3 files changed, 250 insertions(+), 50 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
 index 29d9cc04c04e..03a5567f2c2f 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -64,6 +64,7 @@
  #include linux/wait.h
  #include linux/list.h
  #include linux/kref.h
 +#include linux/fence.h

  #include ttm/ttm_bo_api.h
  #include ttm/ttm_bo_driver.h
 @@ -116,9 +117,6 @@ extern int radeon_deep_color;
  #define RADEONFB_CONN_LIMIT4
  #define RADEON_BIOS_NUM_SCRATCH8

 -/* fence seq are set to this number when signaled */
 -#define RADEON_FENCE_SIGNALED_SEQ  0LL
 -
  /* internal ring indices */
  /* r1xx+ has gfx CP ring */
  #define RADEON_RING_TYPE_GFX_INDEX 0
 @@ -350,12 +348,15 @@ struct radeon_fence_driver {
  };

  struct radeon_fence {
 +   struct fence base;
 +
 struct radeon_device*rdev;
 -   struct kref kref;
 /* protected by radeon_fence.lock */
 uint64_tseq;
 /* RB, DMA, etc. */
 unsignedring;
 +
 +   wait_queue_t fence_wake;
  };

  int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
 @@ -2268,6 +2269,7 @@ struct radeon_device {
 struct radeon_mman  mman;
 struct radeon_fence_driver  fence_drv[RADEON_NUM_RINGS];
 wait_queue_head_t   fence_queue;
 +   unsignedfence_context;
 struct mutexring_lock;
 struct radeon_ring  ring[RADEON_NUM_RINGS];
 boolib_pool_ready;
 @@ -2358,11 +2360,6 @@ u32 cik_mm_rdoorbell(struct radeon_device *rdev, u32 
 index);
  void cik_mm_wdoorbell(struct radeon_device *rdev, u32 index, u32 v);

  /*
 - * Cast helper
 - */
 -#define to_radeon_fence(p) ((struct radeon_fence *)(p))
 -
 -/*
   * Registers read  write functions.
   */
  #define RREG8(reg) readb((rdev-rmmio) + (reg))
 diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
 b/drivers/gpu/drm/radeon/radeon_device.c
 index 03686fab842d..86699df7c8f3 100644
 --- a/drivers/gpu/drm/radeon/radeon_device.c
 +++ b/drivers/gpu/drm/radeon/radeon_device.c
 @@ -1213,6 +1213,7 @@ int radeon_device_init(struct radeon_device *rdev,
 for (i = 0; i  RADEON_NUM_RINGS; i++) {
 rdev-ring[i].idx = i;
 }
 +   rdev-fence_context = fence_context_alloc(RADEON_NUM_RINGS);

 DRM_INFO(initializing kernel modesetting (%s 0x%04X:0x%04X 
 0x%04X:0x%04X).\n,
 radeon_family_name[rdev-family], pdev-vendor, pdev-device,
 @@ -1607,6 +1608,54 @@ int radeon_resume_kms(struct drm_device *dev, bool 
 resume, bool fbcon)
 return 0;
  }

 +static uint32_t radeon_gpu_mask_sw_irq(struct radeon_device *rdev)
 +{
 +   uint32_t mask = 0;
 +   int i;
 +
 +   if (!rdev-ddev-irq_enabled)
 +   return mask;
 +
 +   /*
 +* increase refcount on sw interrupts for all rings to stop
 +* enabling interrupts in radeon_fence_enable_signaling during
 +* gpu reset.
 +*/
 +
 +   for (i = 0; i  RADEON_NUM_RINGS; ++i) {
 +   if (!rdev-ring[i].ready)
 +   continue;
 +
 +   atomic_inc(rdev-irq.ring_int[i]);
 +   mask |= 1  i;
 +   }
 +   return mask;
 +}
 +
 +static void radeon_gpu_unmask_sw_irq(struct radeon_device *rdev, uint32_t 
 mask)
 +{
 +   unsigned long irqflags;
 +   int i;
 +
 +   if (!mask)
 +   return;
 +
 +   /*
 +* undo refcount increase, and reset irqs to correct value.
 +*/
 +
 +   for (i = 0; i  RADEON_NUM_RINGS; ++i) {
 +   if (!(mask  (1  i)))
 + 

Re: [Nouveau] [PATCH] drm/nouveau/agp: add a quirk list to limit agp modes

[Alex Deucher]

On Sun, Oct 27, 2013 at 11:01 PM, Robert Hancock hancock...@gmail.com wrote:
 On 10/27/2013 09:54 AM, Ilia Mirkin wrote:

 Certain combinations of hardware can't actually support the maximum
 detected speed. Add a quirk list that lists pairs of hostbridge/chip pci
 ids and the mode that they should work with.

 See https://bugs.freedesktop.org/show_bug.cgi?id=20341


 It seems like this quirk is likely too specific. This almost certainly
 affects more than 5600 Ultra cards and probably not just NV cards either. It
 probably affects more VIA chipsets than this too.

 Given the amount of breakage that seems to exist with VIA AGP chipsets, I
 would think that being much more aggressive and forcing AGP mode to 2X
 maximum at the AGP driver level for all VIA chipsets doesn't seem like it
 would be a bad idea.

The tricky part with AGP in general is that lowering the mode does not
always improve stability.  There are a lot of cases where the only
stable mode is the one set up by the bios and lowering it causes more
instability.

Alex



 Reported-by: Jason Detring detri...@gmail.com
 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
 ---

 I didn't go as far as subdevice matching... IMO that's overkill for now.

   drivers/gpu/drm/nouveau/nouveau_agp.c | 44
 +++
   1 file changed, 39 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/nouveau_agp.c
 b/drivers/gpu/drm/nouveau/nouveau_agp.c
 index 6e7a55f..2953c4e 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_agp.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_agp.c
 @@ -11,10 +11,28 @@ MODULE_PARM_DESC(agpmode, AGP mode (0 to disable
 AGP));
   static int nouveau_agpmode = -1;
   module_param_named(agpmode, nouveau_agpmode, int, 0400);

 +struct nouveau_agpmode_quirk {
 +   u16 hostbridge_vendor;
 +   u16 hostbridge_device;
 +   u16 chip_vendor;
 +   u16 chip_device;
 +   int mode;
 +};
 +
 +static struct nouveau_agpmode_quirk nouveau_agpmode_quirk_list[] = {
 +   /* VIA Apollo PRO133x / GeForce FX 5600 Ultra, max agpmode 2, fdo
 #20341 */
 +   { PCI_VENDOR_ID_VIA, 0x0691, PCI_VENDOR_ID_NVIDIA, 0x0311, 2 },
 +
 +   {},
 +};
 +
   static unsigned long
 -get_agp_mode(struct nouveau_drm *drm, unsigned long mode)
 +get_agp_mode(struct nouveau_drm *drm, const struct drm_agp_info *info)
   {
 struct nouveau_device *device = nv_device(drm-device);
 +   struct nouveau_agpmode_quirk *quirk = nouveau_agpmode_quirk_list;
 +   int agpmode = nouveau_agpmode;
 +   unsigned long mode = info-mode;

 /*
  * FW seems to be broken on nv18, it makes the card lock up
 @@ -24,11 +42,27 @@ get_agp_mode(struct nouveau_drm *drm, unsigned long
 mode)
 mode = ~PCI_AGP_COMMAND_FW;

 /*
 +* Go through the quirks list and adjust the agpmode accordingly.
 +*/
 +   while (agpmode == -1  quirk-hostbridge_vendor) {
 +   if (info-id_vendor == quirk-hostbridge_vendor 
 +   info-id_device == quirk-hostbridge_device 
 +   device-pdev-vendor == quirk-chip_vendor 
 +   device-pdev-device == quirk-chip_device) {
 +   agpmode = quirk-mode;
 +   nv_info(device, Forcing agp mode to %dX. Use
 agpmode to override.\n,
 +   agpmode);
 +   break;
 +   }
 +   ++quirk;
 +   }
 +
 +   /*
  * AGP mode set in the command line.
  */
 -   if (nouveau_agpmode  0) {
 +   if (agpmode  0) {
 bool agpv3 = mode  0x8;
 -   int rate = agpv3 ? nouveau_agpmode / 4 : nouveau_agpmode;
 +   int rate = agpv3 ? agpmode / 4 : agpmode;

 mode = (mode  ~0x7) | (rate  0x7);
 }
 @@ -90,7 +124,7 @@ nouveau_agp_reset(struct nouveau_drm *drm)
 if (ret)
 return;

 -   mode.mode  = get_agp_mode(drm, info.mode);
 +   mode.mode  = get_agp_mode(drm, info);
 mode.mode = ~PCI_AGP_COMMAND_FW;

 ret = drm_agp_enable(dev, mode);
 @@ -139,7 +173,7 @@ nouveau_agp_init(struct nouveau_drm *drm)
 }

 /* see agp.h for the AGPSTAT_* modes available */
 -   mode.mode = get_agp_mode(drm, info.mode);
 +   mode.mode = get_agp_mode(drm, info);

 ret = drm_agp_enable(dev, mode);
 if (ret) {


 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 07/10] drm: extract dp link train delay functions from radeon

[Alex Deucher]

) {
 -   if (dp_info-rd_interval == 0)
 -   udelay(400);
 -   else
 -   mdelay(dp_info-rd_interval * 4);
 +   drm_dp_link_train_channel_eq_delay(dp_info-dpcd);

 if (!radeon_dp_get_link_status(dp_info-radeon_connector, 
 dp_info-link_status)) {
 DRM_ERROR(displayport link status failed\n);
 @@ -901,7 +895,6 @@ void radeon_dp_link_train(struct drm_encoder *encoder,
 else
 dp_info.enc_id |= ATOM_DP_CONFIG_LINK_A;

 -   dp_info.rd_interval = radeon_read_dpcd_reg(radeon_connector, 
 DP_TRAINING_AUX_RD_INTERVAL);
 tmp = radeon_read_dpcd_reg(radeon_connector, DP_MAX_LANE_COUNT);
 if (ASIC_IS_DCE5(rdev)  (tmp  DP_TPS3_SUPPORTED))
 dp_info.tp3_supported = true;

just below this part there is a memcpy that needs to be updated:

memcpy(dp_info.dpcd, dig_connector-dpcd, 8);

should be:

memcpy(dp_info.dpcd, dig_connector-dpcd, DP_RECEIVER_CAP_SIZE);

With that change:

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
 b/drivers/gpu/drm/radeon/radeon_mode.h
 index d569789..e5b668e 100644
 --- a/drivers/gpu/drm/radeon/radeon_mode.h
 +++ b/drivers/gpu/drm/radeon/radeon_mode.h
 @@ -403,7 +403,7 @@ struct radeon_connector_atom_dig {
 uint32_t igp_lane_info;
 /* displayport */
 struct radeon_i2c_chan *dp_i2c_bus;
 -   u8 dpcd[8];
 +   u8 dpcd[DP_RECEIVER_CAP_SIZE];
 u8 dp_sink_type;
 int dp_clock;
 int dp_lane_count;
 diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
 index 57e6dbd..60bd8d3 100644
 --- a/include/drm/drm_dp_helper.h
 +++ b/include/drm/drm_dp_helper.h
 @@ -25,6 +25,7 @@

  #include linux/types.h
  #include linux/i2c.h
 +#include linux/delay.h

  /*
   * Unless otherwise noted, all values are from the DP 1.1a spec.  Note that
 @@ -333,4 +334,8 @@ u8 drm_dp_get_adjust_request_voltage(u8 
 link_status[DP_LINK_STATUS_SIZE],
  u8 drm_dp_get_adjust_request_pre_emphasis(u8 
 link_status[DP_LINK_STATUS_SIZE],
   int lane);

 +#define DP_RECEIVER_CAP_SIZE   0xf
 +void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
 +void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
 +
  #endif /* _DRM_DP_HELPER_H_ */
 --
 1.7.11.4

 ___
 xorg-driver-ati mailing list
 xorg-driver-...@lists.x.org
 http://lists.x.org/mailman/listinfo/xorg-driver-ati
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 00/10] extract dp helper functions

[Alex Deucher]

On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 Hi all,

 I've frustrated myself the last few days yelling at our link training code.
 Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
 set of dp helper functions. So I've started to extract a few.

 There's lots more that we can do I think (link configuration selection, the 
 i2c
 over aux retry stuff which diverges already between i915 and radeon, maybe 
 more
 higher level parts of the training sequence). But there the drivers diverge
 quite a bit (e.g. the link configuration is driver by different things in each
 driver: coded link bw from the dp spec, link clock or required bw vs avialable
 bw), so that's more work and probably best done when reworking these functions
 for other reasons.

In theory we could provide a helper function to do the entire link
training in common code.  We'd just need a a couple of function
callbacks:

dp_aux_read()
dp_aux_write()
dp_link_train_init()
dp_set_src_training_pattern()
dp_link_train_fini()

Obviously some drivers may want to do their own thing, so it would
just be a helper.  Still for DP 1.2, it would be nice to have the
option of sharing more code.


 I've also tried to put the new helpers a bit to use in nouveau, but due to 
 lack
 of hw that part is untested.

 Comments and testing highly welcome.

 Yours, Daniel

 Daniel Vetter (10):
   drm: rename drm_dp_i2c_helper.c to drm_dp_helper.c
   drm: dp helper: extract drm_dp_channel_eq_ok
   drm: dp helper: extract drm_dp_clock_recovery_ok
   drm/nouveau: use the cr_ok/chanel_eq_ok helpers
   drm: extract helpers to compute new training values from sink request
   drm/nouveau: use dp link train request helper
   drm: extract dp link train delay functions from radeon
   drm/i915: use the new dp train delay helpers
   drm: extract dp link bw helpers
   drm: extract drm_dp_max_lane_count helper

  drivers/gpu/drm/Makefile |   2 +-
  drivers/gpu/drm/drm_dp_helper.c  | 328 
 +++
  drivers/gpu/drm/drm_dp_i2c_helper.c  | 208 --
  drivers/gpu/drm/i915/intel_dp.c  |  98 ++-
  drivers/gpu/drm/nouveau/nouveau_dp.c |  35 +---
  drivers/gpu/drm/radeon/atombios_dp.c | 147 ++--
  drivers/gpu/drm/radeon/radeon_mode.h |   2 +-
  include/drm/drm_dp_helper.h  |  31 
  8 files changed, 400 insertions(+), 451 deletions(-)
  create mode 100644 drivers/gpu/drm/drm_dp_helper.c
  delete mode 100644 drivers/gpu/drm/drm_dp_i2c_helper.c

 --
 1.7.11.4

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau