Re: [PATCH v5 09/13] drm/tegra: Use regular fbdev I/O helpers

[Thierry Reding]

On Tue, May 30, 2023 at 05:12:24PM +0200, Thomas Zimmermann wrote:
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> helpers. Tegra does not use damage handling, so DRM's fbdev helpers
> are mere wrappers around the fbdev code.
> 
> By using fbdev helpers directly within each DRM fbdev emulation,
> we can eventually remove DRM's wrapper functions entirely.
> 
> v4:
>   * use initializer macros for struct fb_ops
> v2:
>   * use FB_SYS_HELPERS option
> 
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: Mikko Perttunen 
> Cc: Jonathan Hunter 
> ---
>  drivers/gpu/drm/tegra/Kconfig | 1 +
>  drivers/gpu/drm/tegra/fbdev.c | 8 +++-
>  2 files changed, 4 insertions(+), 5 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH] drm: Rename headers to match DP2.1 spec

[Thierry Reding]

On Mon, Feb 06, 2023 at 02:37:08PM -0500, jdhillon wrote:
> This patch changes the headers defined in drm_dp.h to match
> the DP 2.1 spec.
> 
> Signed-off-by: Jasdeep Dhillon 
> ---
>  drivers/gpu/drm/tegra/dp.c   |  2 +-
>  include/drm/display/drm_dp.h | 13 +++--
>  2 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
> index 08fbd8f151a1..f33e468ece0a 100644
> --- a/drivers/gpu/drm/tegra/dp.c
> +++ b/drivers/gpu/drm/tegra/dp.c
> @@ -499,7 +499,7 @@ static int drm_dp_link_apply_training(struct drm_dp_link 
> *link)
>   for (i = 0; i < lanes; i++)
>   values[i / 2] |= DP_LANE_POST_CURSOR(i, pc[i]);
>  
> - err = drm_dp_dpcd_write(aux, DP_TRAINING_LANE0_1_SET2, values,
> + err = drm_dp_dpcd_write(aux, DP_LINK_SQUARE_PATTERN, values,
>   DIV_ROUND_UP(lanes, 2));
>   if (err < 0) {
>   DRM_ERROR("failed to set post-cursor: %d\n", err);
> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> index ed10e6b6f99d..2093c1f8d8e0 100644
> --- a/include/drm/display/drm_dp.h
> +++ b/include/drm/display/drm_dp.h
> @@ -641,12 +641,11 @@
>  # define DP_LINK_QUAL_PATTERN_CUSTOM0x40
>  # define DP_LINK_QUAL_PATTERN_SQUARE0x48
>  
> -#define DP_TRAINING_LANE0_1_SET2 0x10f
> -#define DP_TRAINING_LANE2_3_SET2 0x110
> -# define DP_LANE02_POST_CURSOR2_SET_MASK(3 << 0)
> -# define DP_LANE02_MAX_POST_CURSOR2_REACHED (1 << 2)
> -# define DP_LANE13_POST_CURSOR2_SET_MASK(3 << 4)
> -# define DP_LANE13_MAX_POST_CURSOR2_REACHED (1 << 6)
> +#define DP_LINK_SQUARE_PATTERN   0x10f

I think it'd be better to add new definitions for these rather than
replace the existing ones. DP v1.2 calls these TRAINING_LANE0_1_SET2 and
TRAINING_LANE2_3_SET2, respectively, so within the context of DP v1.2
hardware the new names don't make any sense.

While at it, maybe add a comment to the new definitions that the old
ones were deprecated in DP v1.3 and have been repurposed in v2.0 and
v2.1, respectively.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v3 21/27] drm/tegra: Don't set struct drm_device.irq_enabled

[Thierry Reding]

On Thu, Jun 24, 2021 at 09:29:10AM +0200, Thomas Zimmermann wrote:
> The field drm_device.irq_enabled is only used by legacy drivers
> with userspace modesetting. Don't set it in tegra.
> 
> Signed-off-by: Thomas Zimmermann 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/tegra/drm.c | 7 ---
>  1 file changed, 7 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 04/27] drm: Don't test for IRQ support in VBLANK ioctls

[Thierry Reding]

On Thu, Jun 24, 2021 at 11:07:57AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 24.06.21 um 10:51 schrieb Jani Nikula:
> > On Thu, 24 Jun 2021, Thomas Zimmermann  wrote:
> > > Hi
> > > 
> > > Am 24.06.21 um 10:06 schrieb Jani Nikula:
> > > > On Thu, 24 Jun 2021, Thomas Zimmermann  wrote:
> > > > > diff --git a/drivers/gpu/drm/drm_vblank.c 
> > > > > b/drivers/gpu/drm/drm_vblank.c
> > > > > index 3417e1ac7918..10fe16bafcb6 100644
> > > > > --- a/drivers/gpu/drm/drm_vblank.c
> > > > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > > > @@ -1748,8 +1748,16 @@ int drm_wait_vblank_ioctl(struct drm_device 
> > > > > *dev, void *data,
> > > > >   unsigned int pipe_index;
> > > > >   unsigned int flags, pipe, high_pipe;
> > > > > - if (!dev->irq_enabled)
> > > > > - return -EOPNOTSUPP;
> > > > > +#if defined(CONFIG_DRM_LEGACY)
> > > > > + if  (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY))) {
> > > > > + if (!dev->irq_enabled)
> > > > > + return -EOPNOTSUPP;
> > > > > + } else /* if DRIVER_MODESET */
> > > > > +#endif
> > > > > + {
> > > > > + if (!drm_dev_has_vblank(dev))
> > > > > + return -EOPNOTSUPP;
> > > > > + }
> > > > 
> > > > Sheesh I hate this kind of inline #ifdefs.
> > > > 
> > > > Two alternate suggestions that I believe should be as just efficient:
> > > 
> > > Or how about:
> > > 
> > > static bool drm_wait_vblank_supported(struct drm_device *dev)
> > > 
> > > {
> > > 
> > > if defined(CONFIG_DRM_LEGACY)
> > >   if  (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY)))
> > > 
> > >   return dev->irq_enabled;
> > > 
> > > #endif
> > >   return drm_dev_has_vblank(dev);
> > > 
> > > }
> > > 
> > > 
> > > ?
> > > 
> > > It's inline, but still readable.
> > 
> > It's definitely better than the original, but it's unclear to me why
> > you'd prefer this over option 2) below. I guess the only reason I can
> > think of is emphasizing the conditional compilation. However,
> > IS_ENABLED() is widely used in this manner specifically to avoid inline
> > #if, and the compiler optimizes it away.
> 
> It's simply more readable to me as the condition is simpler. But option 2 is
> also ok.

Perhaps do something like this, then:

if (IS_ENABLED(CONFIG_DRM_LEGACY)) {
if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY)))
return dev->irq_enabled;
}

return drm_dev_has_vblank(dev);

That's about just as readable as the variant involving the preprocessor
but has all the benefits of not using the preprocessor.

Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini

[Thierry Reding]

On Thu, Apr 22, 2021 at 01:18:09PM -0400, Lyude Paul wrote:
> On Tue, 2021-04-20 at 02:16 +0300, Ville Syrjälä wrote:
> > 
> > The init vs. register split is intentional. Registering the thing
> > and allowing userspace access to it before the rest of the driver
> > is ready isn't particularly great. For a while now we've tried to
> > move towards an architecture where the driver is fully initialzied
> > before anything gets exposed to userspace.
> 
> Yeah-thank you for pointing this out. Thierry - do you think there's an
> alternate solution we could go with in Tegra to fix the get_device() issue
> that wouldn't require us trying to expose the i2c adapter early?

I suppose we could do it in a hackish way that grabs a reference to the
I2C adapter only upon registration. We can't do that for the regular I2C
DDC case where the I2C controller is an external one because by the time
we get to registration it could've gone again. This would make both code
paths asymmetric, so I'd prefer not to do it. Perhaps it could serve as
an stop-gap solution until something better is in place, though.

Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini

[Thierry Reding]

On Fri, Apr 23, 2021 at 12:11:06AM -0400, Lyude Paul wrote:
> On Thu, 2021-04-22 at 18:33 -0400, Lyude Paul wrote:
> > OK - talked with Ville a bit on this and did some of my own research, I
> > actually think that moving i2c to drm_dp_aux_init() is the right decision
> > for
> > the time being. The reasoning behind this being that as shown by my previous
> > work of fixing drivers that call drm_dp_aux_register() too early - it seems
> > like there's already been drivers that have been working just fine with
> > setting up the i2c device before DRM registration. 
> > 
> > In the future, it'd probably be better if we can split up i2c_add_adapter()
> > into an init and register function - but we'll have to talk with the i2c
> > maintainers to see if this is acceptable w/ them
> 
> Actually - I think adding the ability to refcount dp aux adapters might be a
> better solution so I'm going to try that!

I'm curious: how is a DP AUX adapter reference count going to solve the
issue of potentially registering devices too early (i.e. before the DRM
is registered)?

Is it because registering too early could cause a reference count
problem if somebody get a hold of the DP AUX adapter before the parent
DRM device is around?

Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini

[Thierry Reding]

On Thu, Apr 22, 2021 at 06:33:44PM -0400, Lyude Paul wrote:
> OK - talked with Ville a bit on this and did some of my own research, I
> actually think that moving i2c to drm_dp_aux_init() is the right decision for
> the time being. The reasoning behind this being that as shown by my previous
> work of fixing drivers that call drm_dp_aux_register() too early - it seems
> like there's already been drivers that have been working just fine with
> setting up the i2c device before DRM registration. 
> 
> In the future, it'd probably be better if we can split up i2c_add_adapter()
> into an init and register function - but we'll have to talk with the i2c
> maintainers to see if this is acceptable w/ them

Yeah, that sounds like a better long-term solution. We could leave
i2c_add_adapter() in place, since it's already half-way split up into
some initialization code and i2c_register_adapter(), so it shouldn't be
all that difficult to split out an i2c_init_adapter() so that outside
users can do the split setup.

Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 03/30] drm/tegra: Don't register DP AUX channels before connectors

[Thierry Reding]

On Fri, Feb 19, 2021 at 04:52:59PM -0500, Lyude Paul wrote:
> As pointed out by the documentation for drm_dp_aux_register(),
> drm_dp_aux_init() should be used in situations where the AUX channel for a
> display driver can potentially be registered before it's respective DRM
> driver. This is the case with Tegra, since the DP aux channel exists as a
> platform device instead of being a grandchild of the DRM device.
> 
> Since we're about to add a backpointer to a DP AUX channel's respective DRM
> device, let's fix this so that we don't potentially allow userspace to use
> the AUX channel before we've associated it with it's DRM connector.
> 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/tegra/dpaux.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
> index 105fb9cdbb3b..ea56c6ec25e4 100644
> --- a/drivers/gpu/drm/tegra/dpaux.c
> +++ b/drivers/gpu/drm/tegra/dpaux.c
> @@ -534,9 +534,7 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
>   dpaux->aux.transfer = tegra_dpaux_transfer;
>   dpaux->aux.dev = >dev;
>  
> - err = drm_dp_aux_register(>aux);
> - if (err < 0)
> - return err;
> + drm_dp_aux_init(>aux);

I just noticed that this change causes an error on some setups that I
haven't seen before. The problem is that the SOR driver tries to grab a
reference to the I2C device to make sure it doesn't go away while it has
a pointer to it.

However, since now the I2C adapter hasn't been registered yet, I get
this:

[   15.013969] kobject: '(null)' (5c903e43): is not 
initialized, yet kobject_get() is being called.

I recall that you wanted to make this change so that a backpointer to
the DRM device could be added (I think that's patch 15 of the series),
but I didn't see that patch get merged, so it's a bit difficult to try
and fix this up.

Has the situation changed? Do we no longer need the backpointer? If we
still want it, what's the plan for merging the change? Should I work
under the assumption that patch will make it in sometime and try to fix
this on top of that?

I'm thinking that perhaps we can move the I2C adapter registration into
drm_dp_aux_init() since that's independent of the DRM device. It would
also make a bit more sense from the Tegra driver's point of view where
all devices would be created during the ->probe() path, and only during
the ->init() path would the connection between DRM device and DRM DP AUX
device be established.

Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 05/20] drm/dp: Add backpointer to drm_device in drm_dp_aux

[Thierry Reding]

On Fri, Mar 26, 2021 at 04:37:52PM -0400, Lyude Paul wrote:
> This is something that we've wanted for a while now: the ability to
> actually look up the respective drm_device for a given drm_dp_aux struct.
> This will also allow us to transition over to using the drm_dbg_*() helpers
> for debug message printing, as we'll finally have a drm_device to reference
> for doing so.
> 
> Note that there is one limitation with this - because some DP AUX adapters
> exist as platform devices which are initialized independently of their
> respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be
> non-NULL until drm_dp_aux_register() has been called. We make sure to point
> this out in the documentation for struct drm_dp_aux.
> 
> Signed-off-by: Lyude Paul 
> ---
[...]
>  drivers/gpu/drm/tegra/dpaux.c            | 1 +
[...]

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 02/20] drm/tegra: Don't register DP AUX channels before connectors

[Thierry Reding]

On Fri, Mar 26, 2021 at 04:37:49PM -0400, Lyude Paul wrote:
> As pointed out by the documentation for drm_dp_aux_register(),
> drm_dp_aux_init() should be used in situations where the AUX channel for a
> display driver can potentially be registered before it's respective DRM
> driver. This is the case with Tegra, since the DP aux channel exists as a
> platform device instead of being a grandchild of the DRM device.
> 
> Since we're about to add a backpointer to a DP AUX channel's respective DRM
> device, let's fix this so that we don't potentially allow userspace to use
> the AUX channel before we've associated it with it's DRM connector.
> 
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/tegra/dpaux.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 00/19] [Set 1] Rid W=1 warnings from GPU

[Thierry Reding]

On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
> 
> There are 5000 warnings to work through.
> 
> It will take a couple more sets.
> 
> Lee Jones (19):
>   gpu: host1x: bus: Add missing description for 'driver'
>   gpu: ipu-v3: ipu-di: Strip out 2 unused 'di_sync_config' entries
>   gpu: drm: imx: ipuv3-plane: Mark 'crtc_state' as __always_unused
>   gpu: drm: omapdrm: omap_irq: Fix a couple of doc-rot issues
>   gpu: drm: selftests: test-drm_mm: Mark 'hole_end' as always_unused
>   gpu: drm: scheduler: sched_main: Provide missing description for
> 'sched' paramter
>   gpu: drm: scheduler: sched_entity: Demote non-conformant kernel-doc
> headers
>   gpu: drm: omapdrm: dss: dsi: Rework and remove a few unused variables
>   gpu: drm: selftests: test-drm_framebuffer: Remove set but unused
> variable 'fb'
>   gpu: drm: ttm: ttm_bo: Fix one function header - demote lots of
> kernel-doc abuses
>   gpu: drm: panel: panel-simple: Fix 'struct panel_desc's header
>   gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function
> 'analogix_dp_write_byte_to_dpcd'
>   gpu: drm: ttm: ttm_tt: Demote kernel-doc header format abuses
>   gpu: drm: selftests: test-drm_dp_mst_helper: Place 'struct
> drm_dp_sideband_msg_req_body' onto the heap
>   gpu: drm: radeon: radeon_drv: Remove unused variable 'ret'
>   gpu: drm: panel: panel-ilitek-ili9322: Demote non-conformant
> kernel-doc header
>   gpu: drm: radeon: radeon_device: Fix a bunch of kernel-doc
> misdemeanours
>   gpu: drm: amd: amdgpu: amdgpu: Mark global variables as __maybe_unused
>   gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function
> 'analogix_dp_start_aux_transaction'

As commented on the other patches, the subject prefixes on most of these
look wrong, but it's generally a nice cleanup.

Thanks!
Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 14/21] drm/tegra: Introduce GEM object functions

[Thierry Reding]

On Tue, Sep 15, 2020 at 04:59:51PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in tegra.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/tegra/drm.c | 4 
>  drivers/gpu/drm/tegra/gem.c | 8 
>  2 files changed, 8 insertions(+), 4 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node

[Thierry Reding]

On Sat, Sep 07, 2019 at 09:58:46PM -0400, Ilia Mirkin wrote:
> On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding  
> wrote:
> >
> > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote:
> > > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann  wrote:
> > > >
> > > >   Hi,
> > > >
> > > > > > Changing the order doesn't look hard.  Patch attached (untested, 
> > > > > > have no
> > > > > > test hardware).  But maybe I missed some detail ...
> > > > >
> > > > > I came up with something very similar by splitting up nouveau_bo_new()
> > > > > into allocation and initialization steps, so that when necessary the 
> > > > > GEM
> > > > > object can be initialized in between. I think that's slightly more
> > > > > flexible and easier to understand than a boolean flag.
> > > >
> > > > Yes, that should work too.
> > > >
> > > > Acked-by: Gerd Hoffmann 
> > > Acked-by: Ben Skeggs 
> >
> > Thanks guys, applied to drm-misc-next.
> 
> Hi Thierry,
> 
> Initial investigations suggest that this commit currently in drm-next
> 
> commit 019cbd4a4feb3aa3a917d78e7110e3011bbff6d5
> Author: Thierry Reding 
> Date:   Wed Aug 14 11:00:48 2019 +0200
> 
> drm/nouveau: Initialize GEM object before TTM object
> 
> breaks nouveau userspace which tries to allocate GEM objects with a
> non-page-aligned size. Previously nouveau_gem_new would just call
> nouveau_bo_init which would call nouveau_bo_fixup_align before
> initializing the GEM object. With this change, it is done after. What
> do you think -- OK to just move that bit of logic into the new
> nouveau_bo_alloc() (and make size/align be pointers so that they can
> be fixed up?)

Hi Ilia,

sorry, got side-tracked earlier and forgot to send this out. I'll turn
this into a proper patch, but if you manage to find the time to test
this while I work out the userspace issues that are preventing me from
testing this more thoroughly, that'd be great.

Thierry

--- >8 ---
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index e918b437af17..7d5ede756711 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -186,8 +186,8 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
 }
 
 struct nouveau_bo *
-nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32 flags, u32 tile_mode,
-u32 tile_flags)
+nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 flags,
+u32 tile_mode, u32 tile_flags)
 {
struct nouveau_drm *drm = cli->drm;
struct nouveau_bo *nvbo;
@@ -195,8 +195,8 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32 
flags, u32 tile_mode,
struct nvif_vmm *vmm = cli->svm.cli ? >svm.vmm : >vmm.vmm;
int i, pi = -1;
 
-   if (!size) {
-   NV_WARN(drm, "skipped size %016llx\n", size);
+   if (!*size) {
+   NV_WARN(drm, "skipped size %016llx\n", *size);
return ERR_PTR(-EINVAL);
}
 
@@ -266,7 +266,7 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32 
flags, u32 tile_mode,
pi = i;
 
/* Stop once the buffer is larger than the current page size. */
-   if (size >= 1ULL << vmm->page[i].shift)
+   if (*size >= 1ULL << vmm->page[i].shift)
break;
}
 
@@ -281,6 +281,8 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32 
flags, u32 tile_mode,
}
nvbo->page = vmm->page[pi].shift;
 
+   nouveau_bo_fixup_align(nvbo, flags, align, size);
+
return nvbo;
 }
 
@@ -292,12 +294,11 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int 
align, u32 flags,
size_t acc_size;
int ret;
 
-   acc_size = ttm_bo_dma_acc_size(nvbo->bo.bdev, size, sizeof(*nvbo));
-
-   nouveau_bo_fixup_align(nvbo, flags, , );
nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
nouveau_bo_placement_set(nvbo, flags, 0);
 
+   acc_size = ttm_bo_dma_acc_size(nvbo->bo.bdev, size, sizeof(*nvbo));
+
ret = ttm_bo_init(nvbo->bo.bdev, >bo, size, type,
  >placement, align >> PAGE_SHIFT, false,
  acc_size, sg, robj, nouveau_bo_del_ttm);
@@ -318,7 +319,8 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
struct nouveau_bo *nvbo;
int ret;
 
-   nvbo = nouveau_bo_alloc(cli, size, flags, tile_mode, tile_flags);
+   nvbo = nouveau_bo_alloc(cli, , , flags, tile_mode,
+   tile_flags);
if (IS_ERR(nvbo))
   

Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node

[Thierry Reding]

On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote:
> On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann  wrote:
> >
> >   Hi,
> >
> > > > Changing the order doesn't look hard.  Patch attached (untested, have no
> > > > test hardware).  But maybe I missed some detail ...
> > >
> > > I came up with something very similar by splitting up nouveau_bo_new()
> > > into allocation and initialization steps, so that when necessary the GEM
> > > object can be initialized in between. I think that's slightly more
> > > flexible and easier to understand than a boolean flag.
> >
> > Yes, that should work too.
> >
> > Acked-by: Gerd Hoffmann 
> Acked-by: Ben Skeggs 

Thanks guys, applied to drm-misc-next.

Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node

[Thierry Reding]

On Wed, Aug 14, 2019 at 07:58:27AM +0200, Gerd Hoffmann wrote:
> > Hi Gerd,
> > 
> > I've been seeing a regression on Nouveau with recent linux-next releases
> > and git bisect points at this commit as the first bad one. If I revert
> > it (there's a tiny conflict with a patch that was merged subsequently),
> > things are back to normal.
> > 
> > I think the reason for this issue is that Nouveau doesn't use GEM
> > objects for all buffer objects,
> 
> That shouldn't be a problem ...
> 
> > and even when it uses GEM objects, the
> > code will not initialize the GEM object until after the buffer objects
> > and the backing TTM objects have been created.
> 
> ... but the initialization order is.
> 
> ttm_bo_uses_embedded_gem_object() assumes gem gets initialized first.
> 
> drm_gem_object_init() init calling drm_vma_node_reset() again is
> probably the root cause for the breakage.
> 
> > I tried to fix that by making sure drm_gem_object_init() gets called by
> > Nouveau before ttm_bo_init(), but the changes are fairly involved and I
> > was unable to get the GEM reference counting right. I can look into the
> > proper fix some more, but it might be worth reverting this patch for
> > now to get Nouveau working again.
> 
> Changing the order doesn't look hard.  Patch attached (untested, have no
> test hardware).  But maybe I missed some detail ...
> 
> The other patch attached works around the issue with a flag, to avoid
> drm_vma_node_reset() being called twice.

I came up with something very similar by splitting up nouveau_bo_new()
into allocation and initialization steps, so that when necessary the GEM
object can be initialized in between. I think that's slightly more
flexible and easier to understand than a boolean flag.

Thierry
From a1130a6affcb7c00133e89f3e498cb6757f5bb51 Mon Sep 17 00:00:00 2001
From: Thierry Reding 
Date: Wed, 14 Aug 2019 11:00:48 +0200
Subject: [PATCH] drm/nouveau: Initialize GEM object before TTM object

TTM assumes that drivers initialize the embedded GEM object before
calling the ttm_bo_init() function. This is not currently the case
in the Nouveau driver. Fix this by splitting up nouveau_bo_new()
into nouveau_bo_alloc() and nouveau_bo_init() so that the GEM can
be initialized before TTM BO initialization when necessary.

Fixes: b96f3e7c8069 ("drm/ttm: use gem vma_node")
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c| 69 -
 drivers/gpu/drm/nouveau/nouveau_bo.h|  4 ++
 drivers/gpu/drm/nouveau/nouveau_gem.c   | 29 ++-
 drivers/gpu/drm/nouveau/nouveau_prime.c | 16 --
 4 files changed, 77 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 99e391be9370..b3d3e07de1af 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -185,31 +185,24 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
*size = roundup_64(*size, PAGE_SIZE);
 }
 
-int
-nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
-  uint32_t flags, uint32_t tile_mode, uint32_t tile_flags,
-  struct sg_table *sg, struct reservation_object *robj,
-  struct nouveau_bo **pnvbo)
+struct nouveau_bo *
+nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32 flags, u32 tile_mode,
+u32 tile_flags)
 {
struct nouveau_drm *drm = cli->drm;
struct nouveau_bo *nvbo;
struct nvif_mmu *mmu = >mmu;
struct nvif_vmm *vmm = cli->svm.cli ? >svm.vmm : >vmm.vmm;
-   size_t acc_size;
-   int type = ttm_bo_type_device;
-   int ret, i, pi = -1;
+   int i, pi = -1;
 
if (!size) {
NV_WARN(drm, "skipped size %016llx\n", size);
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
}
 
-   if (sg)
-   type = ttm_bo_type_sg;
-
nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL);
if (!nvbo)
-   return -ENOMEM;
+   return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(>head);
INIT_LIST_HEAD(>entry);
INIT_LIST_HEAD(>vma_list);
@@ -231,7 +224,7 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
nvbo->kind = (tile_flags & 0xff00) >> 8;
if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
kfree(nvbo);
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
}
 
nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
@@ -241,7 +234,7 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
nvbo->comp = (tile_flags & 0x0003) >> 16;
if (!nvi

Re: [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node

[Thierry Reding]

On Mon, Aug 05, 2019 at 04:01:10PM +0200, Gerd Hoffmann wrote:
> Drop vma_node from ttm_buffer_object, use the gem struct
> (base.vma_node) instead.
> 
> Signed-off-by: Gerd Hoffmann 
> Reviewed-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
>  drivers/gpu/drm/qxl/qxl_object.h   | 2 +-
>  drivers/gpu/drm/radeon/radeon_object.h | 2 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.h   | 2 +-
>  include/drm/ttm/ttm_bo_api.h   | 4 
>  drivers/gpu/drm/drm_gem_vram_helper.c  | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_display.c  | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c  | 2 +-
>  drivers/gpu/drm/ttm/ttm_bo.c   | 8 
>  drivers/gpu/drm/ttm/ttm_bo_util.c  | 2 +-
>  drivers/gpu/drm/ttm/ttm_bo_vm.c| 9 +
>  drivers/gpu/drm/virtio/virtgpu_prime.c | 3 ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c| 4 ++--
>  14 files changed, 21 insertions(+), 27 deletions(-)

Hi Gerd,

I've been seeing a regression on Nouveau with recent linux-next releases
and git bisect points at this commit as the first bad one. If I revert
it (there's a tiny conflict with a patch that was merged subsequently),
things are back to normal.

I think the reason for this issue is that Nouveau doesn't use GEM
objects for all buffer objects, and even when it uses GEM objects, the
code will not initialize the GEM object until after the buffer objects
and the backing TTM objects have been created.

I tried to fix that by making sure drm_gem_object_init() gets called by
Nouveau before ttm_bo_init(), but the changes are fairly involved and I
was unable to get the GEM reference counting right. I can look into the
proper fix some more, but it might be worth reverting this patch for
now to get Nouveau working again.

Thierry

> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> index 645a189d365c..113fb2feb437 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> @@ -191,7 +191,7 @@ static inline unsigned 
> amdgpu_bo_gpu_page_alignment(struct amdgpu_bo *bo)
>   */
>  static inline u64 amdgpu_bo_mmap_offset(struct amdgpu_bo *bo)
>  {
> - return drm_vma_node_offset_addr(>tbo.vma_node);
> + return drm_vma_node_offset_addr(>tbo.base.vma_node);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/qxl/qxl_object.h 
> b/drivers/gpu/drm/qxl/qxl_object.h
> index b812d4ae9d0d..8ae54ba7857c 100644
> --- a/drivers/gpu/drm/qxl/qxl_object.h
> +++ b/drivers/gpu/drm/qxl/qxl_object.h
> @@ -60,7 +60,7 @@ static inline unsigned long qxl_bo_size(struct qxl_bo *bo)
>  
>  static inline u64 qxl_bo_mmap_offset(struct qxl_bo *bo)
>  {
> - return drm_vma_node_offset_addr(>tbo.vma_node);
> + return drm_vma_node_offset_addr(>tbo.base.vma_node);
>  }
>  
>  static inline int qxl_bo_wait(struct qxl_bo *bo, u32 *mem_type,
> diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
> b/drivers/gpu/drm/radeon/radeon_object.h
> index 9ffd8215d38a..e5554bf9140e 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.h
> +++ b/drivers/gpu/drm/radeon/radeon_object.h
> @@ -116,7 +116,7 @@ static inline unsigned 
> radeon_bo_gpu_page_alignment(struct radeon_bo *bo)
>   */
>  static inline u64 radeon_bo_mmap_offset(struct radeon_bo *bo)
>  {
> - return drm_vma_node_offset_addr(>tbo.vma_node);
> + return drm_vma_node_offset_addr(>tbo.base.vma_node);
>  }
>  
>  extern int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type,
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index f4ecea6054ba..e28829661724 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -396,7 +396,7 @@ static inline void virtio_gpu_object_unref(struct 
> virtio_gpu_object **bo)
>  
>  static inline u64 virtio_gpu_object_mmap_offset(struct virtio_gpu_object *bo)
>  {
> - return drm_vma_node_offset_addr(>tbo.vma_node);
> + return drm_vma_node_offset_addr(>tbo.base.vma_node);
>  }
>  
>  static inline int virtio_gpu_object_reserve(struct virtio_gpu_object *bo,
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index fa050f0328ab..7ffc50a3303d 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -152,7 +152,6 @@ struct ttm_tt;
>   * @ddestroy: List head for the delayed destroy list.
>   * @swap: List head for swap LRU list.
>   * @moving: Fence set when BO is moving
> - * @vma_node: Address space manager node.
>   * @offset: The current GPU offset, which can have different meanings
>   * depending on the memory type. For SYSTEM type memory, it should be 0.
>   * @cur_placement: Hint of current placement.
> @@ -219,9 +218,6 @@ struct ttm_buffer_object {
>*/
>  
>   struct dma_fence *moving;
> -
> - struct drm_vma_offset_node vma_node;
> -
>   unsigned 

Re: [PATCH 09/59] drm/prime: Align gem_prime_export with obj_funcs.export

[Thierry Reding]

On Fri, Jun 14, 2019 at 10:35:25PM +0200, Daniel Vetter wrote:
> The idea is that gem_prime_export is deprecated in favor of
> obj_funcs.export. That's much easier to do if both have matching
> function signatures.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Russell King 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Tomi Valkeinen 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Dave Airlie 
> Cc: Eric Anholt 
> Cc: "Michel Dänzer" 
> Cc: Chris Wilson 
> Cc: Huang Rui 
> Cc: Felix Kuehling 
> Cc: Hawking Zhang 
> Cc: Feifei Xu 
> Cc: Jim Qu 
> Cc: Evan Quan 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 
> Cc: Thomas Zimmermann 
> Cc: Kate Stewart 
> Cc: Sumit Semwal 
> Cc: Jilayne Lovejoy 
> Cc: Thomas Gleixner 
> Cc: Mikulas Patocka 
> Cc: Greg Kroah-Hartman 
> Cc: Junwei Zhang 
> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c  | 7 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h  | 3 +--
>  drivers/gpu/drm/armada/armada_gem.c  | 5 ++---
>  drivers/gpu/drm/armada/armada_gem.h  | 3 +--
>  drivers/gpu/drm/drm_prime.c  | 9 -
>  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 5 ++---
>  drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 
>  drivers/gpu/drm/i915/gvt/dmabuf.c| 2 +-
>  drivers/gpu/drm/i915/i915_drv.h  | 3 +--
>  drivers/gpu/drm/omapdrm/omap_gem.h   | 3 +--
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c| 5 ++---
>  drivers/gpu/drm/radeon/radeon_drv.c  | 3 +--
>  drivers/gpu/drm/radeon/radeon_prime.c| 5 ++---
>  drivers/gpu/drm/tegra/gem.c  | 7 +++
>  drivers/gpu/drm/tegra/gem.h  | 3 +--
>  drivers/gpu/drm/udl/udl_dmabuf.c | 5 ++---
>  drivers/gpu/drm/udl/udl_drv.h| 3 +--
>  drivers/gpu/drm/vc4/vc4_bo.c | 5 ++---
>  drivers/gpu/drm/vc4/vc4_drv.h| 3 +--
>  drivers/gpu/drm/vgem/vgem_fence.c    | 2 +-
>  include/drm/drm_drv.h| 4 ++--
>  include/drm/drm_prime.h  | 3 +--
>  22 files changed, 39 insertions(+), 57 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 7/7] drm: Split out drm_probe_helper.h

[Thierry Reding]

/gpu/drm/rockchip/rockchip_drm_fbdev.c |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.c   |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_lvds.c  |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_rgb.c   |  2 +-
>  drivers/gpu/drm/sti/sti_crtc.c|  2 +-
>  drivers/gpu/drm/sti/sti_drv.c |  2 +-
>  drivers/gpu/drm/sti/sti_dvo.c |  2 +-
>  drivers/gpu/drm/sti/sti_hda.c |  2 +-
>  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>  drivers/gpu/drm/sti/sti_tvout.c   |  2 +-
>  drivers/gpu/drm/stm/drv.c |  2 +-
>  drivers/gpu/drm/stm/ltdc.c|  2 +-
>  drivers/gpu/drm/sun4i/sun4i_backend.c |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_crtc.c|  2 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c|  2 +-
>  drivers/gpu/drm/sun4i/sun4i_lvds.c|  2 +-
>  drivers/gpu/drm/sun4i/sun4i_rgb.c |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c|  2 +-
>  drivers/gpu/drm/sun4i/sun4i_tv.c  |  2 +-
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c|  2 +-
>  drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c |  2 +-
>  drivers/gpu/drm/sun4i/sun8i_mixer.c   |  2 +-
>  drivers/gpu/drm/sun4i/sun8i_ui_layer.c|  2 +-
>  drivers/gpu/drm/sun4i/sun8i_vi_layer.c|  2 +-
>  drivers/gpu/drm/tegra/drm.h   |  2 +-
>  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>  drivers/gpu/drm/tegra/hub.c   |  2 +-
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c   |  2 +-
>  drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c   |  2 +-
>  drivers/gpu/drm/tve200/tve200_drv.c   |  2 +-
>  drivers/gpu/drm/udl/udl_connector.c   |  1 +
>  drivers/gpu/drm/udl/udl_drv.c |  1 +
>  drivers/gpu/drm/udl/udl_main.c|  1 +
>  drivers/gpu/drm/vc4/vc4_crtc.c|  2 +-
>  drivers/gpu/drm/vc4/vc4_dpi.c |  2 +-
>  drivers/gpu/drm/vc4/vc4_dsi.c |  2 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>  drivers/gpu/drm/vc4/vc4_kms.c |  2 +-
>  drivers/gpu/drm/vc4/vc4_txp.c |  2 +-
>  drivers/gpu/drm/vc4/vc4_vec.c |  2 +-
>  drivers/gpu/drm/virtio/virtgpu_display.c  |  2 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.h  |  2 +-
>  drivers/gpu/drm/vkms/vkms_crtc.c  |  2 +-
>  drivers/gpu/drm/vkms/vkms_drv.c   |  2 +-
>  drivers/gpu/drm/vkms/vkms_output.c|  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |  2 +-
>  drivers/gpu/drm/xen/xen_drm_front.c   |  2 +-
>  drivers/gpu/drm/xen/xen_drm_front_conn.c  |  2 +-
>  drivers/gpu/drm/xen/xen_drm_front_gem.c   |  2 +-
>  drivers/gpu/drm/xen/xen_drm_front_kms.c   |  2 +-
>  drivers/gpu/drm/zte/zx_drm_drv.c  |  2 +-
>  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>  drivers/gpu/drm/zte/zx_tvenc.c|  2 +-
>  drivers/gpu/drm/zte/zx_vga.c  |  2 +-
>  drivers/gpu/drm/zte/zx_vou.c  |  2 +-
>  drivers/staging/vboxvideo/vbox_irq.c  |  2 +-
>  drivers/staging/vboxvideo/vbox_mode.c |  2 +-
>  include/drm/drm_crtc_helper.h | 16 --
>  include/drm/drm_probe_helper.h| 50 +++
>  208 files changed, 256 insertions(+), 200 deletions(-)
>  create mode 100644 include/drm/drm_probe_helper.h

Looks good to me:

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions

[Thierry Reding]

On Tue, Nov 20, 2018 at 06:13:42PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Make life easier for drivers by simply passing the connector
> to drm_hdmi_avi_infoframe_from_display_mode() and
> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
> need to worry about is_hdmi2_sink mess.
> 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Russell King 
> Cc: CK Hu 
> Cc: Philipp Zabel 
> Cc: Rob Clark 
> Cc: Ben Skeggs 
> Cc: Tomi Valkeinen 
> Cc: Sandy Huang 
> Cc: "Heiko Stübner" 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Thierry Reding 
> Cc: Eric Anholt 
> Cc: Shawn Guo 
> Cc: Ilia Mirkin 
> Cc: amd-gfx@lists.freedesktop.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  3 ++-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  5 ++--
>  drivers/gpu/drm/bridge/sii902x.c  |  3 ++-
>  drivers/gpu/drm/bridge/sil-sii8620.c  |  3 +--
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  3 ++-
>  drivers/gpu/drm/drm_edid.c| 33 ++-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  3 ++-
>  drivers/gpu/drm/i2c/tda998x_drv.c |  3 ++-
>  drivers/gpu/drm/i915/intel_hdmi.c | 14 +-
>  drivers/gpu/drm/i915/intel_lspcon.c   | 15 ++-
>  drivers/gpu/drm/i915/intel_sdvo.c | 10 ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
>  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c|  3 ++-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  7 +++--
>  drivers/gpu/drm/omapdrm/omap_encoder.c|  5 ++--
>  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  4 ++-
>  drivers/gpu/drm/sti/sti_hdmi.c|  3 ++-
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c|  3 ++-
>  drivers/gpu/drm/tegra/hdmi.c  |  3 ++-
>  drivers/gpu/drm/tegra/sor.c   |  3 ++-
>  drivers/gpu/drm/vc4/vc4_hdmi.c| 11 +---
>  drivers/gpu/drm/zte/zx_hdmi.c |  4 ++-
>  include/drm/drm_edid.h|  8 +++---
>  27 files changed, 94 insertions(+), 66 deletions(-)

That's actually a lot nicer:

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere

[Thierry Reding]

On Mon, Nov 12, 2018 at 04:01:14PM +0100, Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
> 
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: David Airlie 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Cc: Mali DP Maintainers 
> Cc: Boris Brezillon 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Ludovic Desroches 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Philipp Zabel 
> Cc: CK Hu 
> Cc: Matthias Brugger 
> Cc: Rob Clark 
> Cc: Ben Skeggs 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> Cc: Kieran Bingham 
> Cc: Sandy Huang 
> Cc: "Heiko Stübner" 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Eric Anholt 
> Cc: VMware Graphics 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Cc: Tony Cheng 
> Cc: Shirish S 
> Cc: Mikita Lipski 
> Cc: Bhawanpreet Lakha 
> Cc: David Francis 
> Cc: Anthony Koo 
> Cc: Jeykumar Sankaran 
> Cc: Jordan Crouse 
> Cc: Bruce Wang 
> Cc: Sravanthi Kollukuduru 
> Cc: Archit Taneja 
> Cc: Steve Kowalik 
> Cc: Carsten Behling 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Mahesh Kumar 
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  4 +--
>  drivers/gpu/drm/arm/malidp_crtc.c |  5 +--
>  .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c|  5 +--
>  drivers/gpu/drm/drm_atomic_state_helper.c | 31 ---
>  drivers/gpu/drm/i915/intel_display.c  |  2 +-
>  drivers/gpu/drm/imx/ipuv3-crtc.c  |  5 +--
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c   |  5 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 12 ++-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  6 +---
>  drivers/gpu/drm/nouveau/dispnv50/head.c   | 13 ++--
>  drivers/gpu/drm/omapdrm/omap_crtc.c   |  7 ++---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  4 +--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |  7 +++--
>  drivers/gpu/drm/tegra/dc.c|  5 +--
>  drivers/gpu/drm/vc4/vc4_crtc.c        |  8 ++---
>  drivers/gpu/drm/vkms/vkms_crtc.c  |  7 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  9 +-
>  include/drm/drm_atomic_state_helper.h |  2 ++
>  18 files changed, 56 insertions(+), 81 deletions(-)

Looks good to me:

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 24/24] drm/amdgpu: Move GEM BO to drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:38PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone <dani...@collabora.com>
> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Cc: Christian König <christian.koe...@amd.com>
> Cc: David (ChunMing) Zhou <david1.z...@amd.com>
> Cc: amd-gfx@lists.freedesktop.org
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  6 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 36 
> +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 10 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 17 ---
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 17 ---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 17 ---
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 17 ---
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  4 +--
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++
>  10 files changed, 40 insertions(+), 96 deletions(-)

Reviewed-by: Thierry Reding <tred...@nvidia.com>


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 23/24] drm/radeon: radeon_framebuffer -> drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:37PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone <dani...@collabora.com>
> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Cc: Christian König <christian.koe...@amd.com>
> Cc: David (ChunMing) Zhou <david1.z...@amd.com>
> Cc: amd-gfx@lists.freedesktop.org
> ---
>  drivers/gpu/drm/radeon/atombios_crtc.c  | 32 
> -
>  drivers/gpu/drm/radeon/radeon_device.c  |  6 +++---
>  drivers/gpu/drm/radeon/radeon_display.c | 30 ---
>  drivers/gpu/drm/radeon/radeon_fb.c  | 20 +-
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 11 +++---
>  drivers/gpu/drm/radeon/radeon_mode.h|  7 +--
>  6 files changed, 39 insertions(+), 67 deletions(-)

Reviewed-by: Thierry Reding <tred...@nvidia.com>


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 22/24] drm/radeon: Move GEM BO to drm_framebuffer

[Thierry Reding]

On Fri, Mar 30, 2018 at 03:11:36PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
> 
> Signed-off-by: Daniel Stone <dani...@collabora.com>
> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Cc: Christian König <christian.koe...@amd.com>
> Cc: David (ChunMing) Zhou <david1.z...@amd.com>
> Cc: amd-gfx@lists.freedesktop.org
> ---
>  drivers/gpu/drm/radeon/atombios_crtc.c  | 10 +-
>  drivers/gpu/drm/radeon/radeon_device.c  |  4 ++--
>  drivers/gpu/drm/radeon/radeon_display.c | 31 
> +++--
>  drivers/gpu/drm/radeon/radeon_fb.c  |  8 
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 11 --
>  drivers/gpu/drm/radeon/radeon_mode.h    |  1 -
>  6 files changed, 22 insertions(+), 43 deletions(-)

Reviewed-by: Thierry Reding <tred...@nvidia.com>


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/core: Remove drm_dev_unref() and it's uses

[Thierry Reding]

On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref() with drm_dev_put and remove
> the function itself.
> 
> Coccinelle was used for mass-patching.
> 
> Signed-off-by: Vaishali Thakkar <vthakkar1...@gmail.com>

Yes, please.

Acked-by: Thierry Reding <tred...@nvidia.com>


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Thierry Reding]

On Wed, Apr 25, 2018 at 09:30:39AM +0200, Daniel Vetter wrote:
> On Wed, Apr 25, 2018 at 12:09:05AM -0700, Christoph Hellwig wrote:
> > On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote:
> > > Can we please not nack everything right away? Doesn't really motivate
> > > me to show you all the various things we're doing in gpu to make the
> > > dma layer work for us. That kind of noodling around in lower levels to
> > > get them to do what we want is absolutely par-for-course for gpu
> > > drivers. If you just nack everything I point you at for illustrative
> > > purposes, then I can't show you stuff anymore.
> > 
> > No, it's not.  No driver (and that includes the magic GPUs) has
> > any business messing with dma ops directly.
> > 
> > A GPU driver imght have a very valid reason to disable the IOMMU,
> > but the code to do so needs to be at least in the arch code, maybe
> > in the dma-mapping/iommu code, not in the driver.
> > 
> > As a first step to get the discussion started we'll simply need
> > to move the code Thierry wrote into a helper in arch/arm and that
> > alone would be a massive improvement.  I'm not even talking about
> > minor details like actually using arm_get_dma_map_ops instead
> > of duplicating it.
> > 
> > And doing this basic trivial work really helps to get this whole
> > mess under control.
> 
> Ah ok. It did sound a bit like a much more cathegorical NAK than an "ack
> in principle, but we need to shuffle the implementation into the right
> place first". In the past we generally got a principled NAK on anything
> funny we've been doing with the dma api, and the dma api maintainer
> steaming off telling us we're incompetent idiots. I guess I've been
> branded a bit on this topic :-/
> 
> Really great that this is changing now.
> 
> On the patch itself: It might not be the right thing in all cases, since
> for certain compression formats the nv gpu wants larger pages (easy to
> allocate from vram, not so easy from main memory), so might need the iommu
> still. But currently that's not implemented:
> 
> https://www.spinics.net/lists/dri-devel/msg173932.html

To clarify: we do want to use the IOMMU, but we want to use it
explicitly via the IOMMU API rather than hiding it behind the DMA API.
We do the same thing in Tegra DRM where we don't want to use the DMA API
because it doesn't allow us to share the same mapping between multiple
display controllers in the same way the IOMMU API does. We've also been
thinking about using the IOMMU API directly in order to support process
isolation for devices that accept command streams from userspace.

Fortunately the issue I'm seeing with Nouveau doesn't happen with Tegra
DRM, which seems to be because we have an IOMMU group with multiple
devices and that prevents the DMA API from "hijacking" the IOMMU domain
for the group.

And to add to the confusion, none of this seems to be an issue on 64-bit
ARM where the generic DMA/IOMMU code from drivers/iommu/dma-iommu.c is
used.

Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Thierry Reding]

On Tue, Apr 24, 2018 at 11:43:35PM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote:
> > For more fun:
> > 
> > https://www.spinics.net/lists/dri-devel/msg173630.html
> > 
> > Yeah, sometimes we want to disable the iommu because the on-gpu
> > pagetables are faster ...
> 
> I am not on this list, but remote NAK from here.  This needs an
> API from the iommu/dma-mapping code.  Drivers have no business poking
> into these details.

The interfaces that the above patch uses are all EXPORT_SYMBOL_GPL,
which is rather misleading if they are not meant to be used by drivers
directly.

> Thierry, please resend this with at least the iommu list and
> linux-arm-kernel in Cc to have a proper discussion on the right API.

I'm certainly open to help with finding a correct solution, but the
patch above was purposefully terse because this is something that I
hope we can get backported to v4.16 to unbreak Nouveau. Coordinating
such a backport between ARM and DRM trees does not sound like something
that would help getting this fixed in v4.16.

The fundamental issue here is that the DMA/IOMMU integration is
something that has caused a number of surprising regressions in the past
because it tends to sneak in unexpectedly. For example the current
regression shows up only if CONFIG_ARM_DMA_USE_IOMMU=y because the DMA
API will then transparently create a second mapping and mess things up.
Everything works fine if that option is disabled. This is ultimately why
we didn't notice, since we don't enable that option by default. I do
have a patch that I plan to apply to the Tegra tree that will always
enable CONFIG_ARM_DMA_USE_IOMMU=y on Tegra to avoid any such surprises
in the future, but I can obviously only apply that once the above patch
is applied to Nouveau, otherwise we'll break Nouveau unconditionally.

Granted, this issue could've been caught with a little more testing, but
in retrospect I think it would've been a lot better if ARM_DMA_USE_IOMMU
was just enabled unconditionally if it has side-effects that platforms
don't opt in to but have to explicitly opt out of.

Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Thierry Reding]

On Wed, Apr 25, 2018 at 12:09:05AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote:
> > Can we please not nack everything right away? Doesn't really motivate
> > me to show you all the various things we're doing in gpu to make the
> > dma layer work for us. That kind of noodling around in lower levels to
> > get them to do what we want is absolutely par-for-course for gpu
> > drivers. If you just nack everything I point you at for illustrative
> > purposes, then I can't show you stuff anymore.
> 
> No, it's not.  No driver (and that includes the magic GPUs) has
> any business messing with dma ops directly.
> 
> A GPU driver imght have a very valid reason to disable the IOMMU,
> but the code to do so needs to be at least in the arch code, maybe
> in the dma-mapping/iommu code, not in the driver.
> 
> As a first step to get the discussion started we'll simply need
> to move the code Thierry wrote into a helper in arch/arm and that
> alone would be a massive improvement.  I'm not even talking about
> minor details like actually using arm_get_dma_map_ops instead
> of duplicating it.
> 
> And doing this basic trivial work really helps to get this whole
> mess under control.

That's a good idea and I can prepare patches for this, but I'd like to
make those changes on top of the fix to keep the option of getting this
into v4.16 if at all possible.

Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: Remove duplicate setting of ->need_swiotlb

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

There's no need to set this before the number of DMA bits has been
properly determined.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 9a170e37fbe7..9cc849f829d0 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -1086,7 +1086,6 @@ static int gmc_v8_0_sw_init(void *handle)
 */
adev->need_dma32 = false;
dma_bits = adev->need_dma32 ? 32 : 40;
-   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
adev->need_dma32 = true;
-- 
2.15.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 00/13] remove_conflicting_framebuffers() cleanup

[Thierry Reding]

On Mon, Nov 27, 2017 at 11:30:44AM +0100, Daniel Vetter wrote:
> On Fri, Nov 24, 2017 at 06:53:25PM +0100, Michał Mirosław wrote:
> > This series cleans up duplicated code for replacing firmware FB
> > driver with proper DRI driver and adds handover support to
> > Tegra driver.
> > 
> > The last patch is here because it uses new semantics of
> > remove_conflicting_framebuffers() from this series. This
> > can be considered independently, though.
> 
> Except for that patches I've commented on:
> 
> Acked-by: Daniel Vetter 
> 
> Since this is for tegra and Thierry has drm-misc commit rights, it's
> probably simplest when Thierry pushes this all to drm-misc once driver
> maintainers had a chance to look at it.

Will do.

Thierry


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 06/18] drm: use ARRAY_SIZE

[Thierry Reding]

On Sun, Oct 01, 2017 at 03:30:44PM -0400, Jérémy Lefaure wrote:
> Using the ARRAY_SIZE macro improves the readability of the code. Also,
> it is not always useful to use a variable to store this constant
> calculated at compile time nor to re-invent the ARRAY_SIZE macro.
> 
> Found with Coccinelle with the following semantic patch:
> @r depends on (org || report)@
> type T;
> T[] E;
> position p;
> @@
> (
>  (sizeof(E)@p /sizeof(*E))
> |
>  (sizeof(E)@p /sizeof(E[...]))
> |
>  (sizeof(E)@p /sizeof(T))
> )
> 
> Signed-off-by: Jérémy Lefaure <jeremy.lefa...@lse.epita.fr>
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  9 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   |  9 +
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c |  9 -
>  drivers/gpu/drm/i915/gvt/vgpu.c |  3 ++-
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c |  7 ---
>  drivers/gpu/drm/via/via_verifier.c  | 10 ++++--
>  6 files changed, 24 insertions(+), 23 deletions(-)

Reviewed-by: Thierry Reding <tred...@nvidia.com>


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/ttm: Fix trace include path (v2)

[Thierry Reding]

On Fri, Sep 01, 2017 at 12:14:23PM -0400, Tom St Denis wrote:
> Signed-off-by: Tom St Denis <tom.stde...@amd.com>
> 
> (v2): Drop Makefile change too.
> ---
>  drivers/gpu/drm/ttm/Makefile| 2 +-
>  drivers/gpu/drm/ttm/ttm_trace.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Thierry Reding <tred...@nvidia.com>


signature.asc
Description: PGP signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/6] drm/amdgpu: Use correct path to trace include

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 drivers/gpu/drm/amd/amdgpu/Makefile   | 2 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 658bac0cdc5e..25a95c95df14 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -133,5 +133,3 @@ include $(FULL_AMD_PATH)/powerplay/Makefile
 amdgpu-y += $(AMD_POWERPLAY_FILES)
 
 obj-$(CONFIG_DRM_AMDGPU)+= amdgpu.o
-
-CFLAGS_amdgpu_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 1c88bd5e29ad..0ee2c97ae79e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -473,5 +473,5 @@ TRACE_EVENT(amdgpu_ttm_bo_move,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/amd/amdgpu
 #include 
-- 
2.13.3

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 5/6] drm/radeon: Use correct path to trace include

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 drivers/gpu/drm/radeon/Makefile   | 2 --
 drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 4acbb944bcd2..be16c6390216 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -109,5 +109,3 @@ radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
 radeon-$(CONFIG_ACPI) += radeon_acpi.o
 
 obj-$(CONFIG_DRM_RADEON)+= radeon.o
-
-CFLAGS_radeon_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h 
b/drivers/gpu/drm/radeon/radeon_trace.h
index fdce4062901f..815eaa8c394b 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -204,5 +204,5 @@ DEFINE_EVENT(radeon_semaphore_request, 
radeon_semaphore_wait,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/radeon
 #include 
-- 
2.13.3

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx