Hi Ville
Thanks for the patch.
Our understanding of private_flags was that we can use it within our
drivers to handle vendor specific features.
Hence we do have several features in our downstream drivers as well as
some planned work based on this.
This was the only method to pass around and
Hi Sakari,
On Sat, Apr 04, 2020 at 03:14:25AM +0300, Sakari Ailus wrote:
> On Fri, Apr 03, 2020 at 09:32:42PM +0300, Andy Shevchenko wrote:
> > On Fri, Apr 3, 2020 at 8:54 PM Joe Perches wrote:
> > > On Fri, 2020-04-03 at 19:32 +0200, Mauro Carvalho Chehab wrote:
> > > > Em Fri, 03 Apr 2020
Hi Andy,
On Fri, Apr 03, 2020 at 09:32:42PM +0300, Andy Shevchenko wrote:
> On Fri, Apr 3, 2020 at 8:54 PM Joe Perches wrote:
> > On Fri, 2020-04-03 at 19:32 +0200, Mauro Carvalho Chehab wrote:
> > > Em Fri, 03 Apr 2020 09:56:42 -0700
> > > Joe Perches escreveu:
>
> > It _might_ be useful to
On Sat, 2020-04-04 at 02:36 +0300, Sakari Ailus wrote:
> Hi Joe,
Hi Sakari.
> How would these be different in functionality? fmt[2] won't be accessed if
> fmt[1] is not 'c' (including '\0'), just like on the line above. I find the
> original easier to read.
Oops. You are right of course.
Hi Joe,
On Fri, Apr 03, 2020 at 11:38:29AM -0700, Joe Perches wrote:
> On Fri, 2020-04-03 at 13:47 +0300, Sakari Ailus wrote:
> > On Fri, Apr 03, 2020 at 01:24:49PM +0300, Laurent Pinchart wrote:
> > > On Fri, Apr 03, 2020 at 12:11:56PM +0300, Sakari Ailus wrote:
> > > > Add a printk modifier
Just some prep work before we rework the lifetime handling, which
requires replacing all the drm_dev_put in selftests by something else.
v2: Don't go with a static inline, upsets the header tests and
separation.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c
The big change is device_add so that device_del can auto-cleanup
devres resources. This allows us to use devm_drm_dev_alloc, which
removes the last user of drm_dev_init.
v2: Rebased
Signed-off-by: Daniel Vetter
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 33 +--
1 file
Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
made sense back when we still had to validate ports before accessing
them in order to (attempt to) avoid NULL dereferences. Since we have
proper reference counting that guarantees we always can safely access
the MST port,
Hi Ville,
Thank you for the patch.
On Fri, Apr 03, 2020 at 11:39:54PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with
From: Ville Syrjälä
There's no reason for I915_MODE_FLAG_INHERITED to exist as a flag
anymore. Just make it a boolean.
CC: Sam Ravnborg
Cc: Daniel Vetter
Cc: Emil Velikov
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
From: Ville Syrjälä
The last two uses of mode->private_flags (in i915 and gma500)
are now gone. So let's remove mode->private_flags entirely.
CC: Sam Ravnborg
Cc: Daniel Vetter
Cc: Emil Velikov
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 10 --
1 file changed, 10
From: Ville Syrjälä
gma500 only uses mode->private_flags to convey the sdvo pixel
multiplier from the encoder .mode_fixup() hook to the encoder
.mode_set() hook. Those always seems get called as a pair so
let's just stuff the pixel multiplier into the encoder itself
as there are no state objects
From: Ville Syrjälä
In order to shrink drm_display_mode below the magic two cacheline
mark in 64bit we need to shrink it by another 8 bytes. The easiest
thing to eliminate is the 'export_head' list head which is only
used during the getconnector ioctl to temporarly track which modes
on the
From: Ville Syrjälä
The driver never sets mode->private_flags so copying
it back and forth is entirely pointless. Stop doing it.
Also drop private_flags from the tracepoint.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Reviewed-by: Emil
From: Ville Syrjälä
Reorganize drm_display_mode to eliminate all the holes.
We'll put all the actual timings to the start of the
struct and all the extra junk to the end.
Gets the size down to 136 bytes on 64bit and 120 bytes on
32bit. With a bit more work we should be able to get this
below
From: Ville Syrjälä
Replace the use of mode->private_flags with a truly private bitmaks
in our own crtc state. We also need a copy in the crtc itself so the
vblank code can get at it. We already have scanline_offset in there
for a similar reason, as well as the vblank->hwmode which is assigned
From: Ville Syrjälä
We only have 7 bits defined for mode->type. Shrink the storage to u8.
Reviewed-by: Emil Velikov
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h
From: Ville Syrjälä
Store the timings (apart from the clock) as u16. The uapi mode
struct already uses u16 for everything so using something bigger
internally doesn't really help us.
Reviewed-by: Emil Velikov
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Remove the pointless whole-function indentation. Also don't
need to worry about negative values anymore since we switched
everything to u16.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 26 --
1 file
From: Ville Syrjälä
The mode flags are direclty exposed in the uapi as u32. Use the
same size type to store them internally.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
htotal*vtotal*vrefresh ~= clock. So just say "clock" when we mean it.
Cc: Linus Walleij
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/mcde/mcde_dsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c
From: Ville Syrjälä
Let's just calculate the hsync rate on demand. No point in wasting
space storing it and risking the cached value getting out of sync
with reality.
v2: Move drm_mode_hsync() next to its only users
Drop the TODO
Reviewed-by: Emil Velikov #v1
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
gma500 needs 4 bits (to store a pixel multiplier) in the
mode->private_flags, i915 currently has three bits defined.
No one else uses this. Reduce the size to u8.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1
From: Ville Syrjälä
The drrs code dereferences mode->vrefresh via some really long chain
of structures/pointers. Couldn't get coccinelle to see through all
that so let's add some local variables to help it.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Refreshed version of the mode diet.
New unseen stuff at the end:
- Nuke private_flags entirely
- Replace export_head with a bool to shrink the struct
below the magic two cachelines
I kept the intermediate "shrink private_flags to u8" step
because I didn't want to redo the
From: Ville Syrjälä
Instead of supporting ~2000km wide displayes let's limit ourselves
to ~65m. That seems plenty big enough to me.
Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
10*0xfff which fits into the 16 bits.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
On Fri, Apr 3, 2020 at 11:18 AM Aaron Ma wrote:
>
> On ARCTURUS and RENOIR, powerplay is not supported yet.
> When plug in or unplug power jack, ACPI event will issue.
> Then kernel NULL pointer BUG will be triggered.
> Check for NULL pointers before calling.
>
> Signed-off-by: Aaron Ma
First off, apologies if the functionality described already exists and I
just failed to find it, or if this isn't the correct venue for this
discussion. If so, pointers to the correct location would be appreciated.
I'm currently looking into the feasibility of developing a remote access
tool
Currently we only poll for an ACT up to 30 times, with a busy-wait delay
of 100µs between each attempt - giving us a timeout of 2900µs. While
this might seem sensible, it would appear that in certain scenarios it
can take dramatically longer then that for us to receive an ACT. On one
of the EVGA
Although it's not unexpected for drm_dp_check_act_status() to fail due
to DPCD read failures (as the hub may have just been unplugged
suddenly), timeouts are a bit more worrying as they either mean we need
a longer timeout value, or we aren't setting up payload allocations
properly. So, let's
Noticed this while fixing some unrelated issues with NAKs being dropped
- we don't wait nearly long enough to receive ACTs from MST hubs in some
situations. Also, we take the time to refactor this function a bit.
This fixes some ACT timeouts I observed on an EVGA MST hub with i915.
Lyude Paul
Just add a bit more line wrapping, get rid of some extraneous
whitespace, remove an unneeded goto label, and move around some variable
declarations. No functional changes here.
Signed-off-by: Lyude Paul
[this isn't a fix, but it's needed for the fix that comes after this]
Fixes: ad7f8a1f9ced
No functional changes.
Signed-off-by: Lyude Paul
Cc: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 10d0315af513..2b9ce965f044
It looks like that when we introduced the ability to handle multiple
down requests at once, we accidentally started dropping NAK replies -
causing sideband messages which got NAK'd to seemingly timeout and cause
all sorts of weirdness.
So, fix this by making sure we don't return from
On Fri, Apr 3, 2020 at 8:06 PM Daniel Dadap wrote:
>
>
> On 4/3/20 2:16 AM, Daniel Vetter wrote:
> > On Fri, Apr 3, 2020 at 8:54 AM Daniel Dadap wrote:
> >>
> >> On 4/2/20 6:39 AM, Lukas Wunner wrote:
> >>
> >>
> >> On Fri, Mar 27, 2020 at 04:25:19PM -0500, Daniel Dadap wrote:
> A number of
On Fri, 2020-04-03 at 13:47 +0300, Sakari Ailus wrote:
> On Fri, Apr 03, 2020 at 01:24:49PM +0300, Laurent Pinchart wrote:
> > On Fri, Apr 03, 2020 at 12:11:56PM +0300, Sakari Ailus wrote:
> > > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > > pixel formats denoted by
On Fri, Apr 3, 2020 at 8:54 PM Joe Perches wrote:
> On Fri, 2020-04-03 at 19:32 +0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 03 Apr 2020 09:56:42 -0700
> > Joe Perches escreveu:
> It _might_ be useful to use a CONFIG_MEDIA_SUPPORT guard
> in lib/vsprintf for this.
No need. FourCC, if Sakari
On 4/3/20 8:58 AM, Daniel Vetter wrote:
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: David Lechner
---
Acked-by: David Lechner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Fri, 2020-04-03 at 19:32 +0200, Mauro Carvalho Chehab wrote:
> Em Fri, 03 Apr 2020 09:56:42 -0700
> Joe Perches escreveu:
[]
> > How many instances of %p4cc could there be?
>
> That's hard to know... there are several places printing it
> with different ways:
>
> $ git grep -i -E
On Fri, Apr 3, 2020 at 6:59 AM Daniel Vetter wrote:
>
> Upcasting using a container_of macro is more typesafe, faster and
> easier for the compiler to optimize.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam
On Fri, Apr 3, 2020 at 6:58 AM Daniel Vetter wrote:
>
> And switch the helper over to container_of, which is a bunch faster
> than chasing a pointer. Plus allows gcc to see through this maze.
>
> Signed-off-by: Daniel Vetter
Acked-by: Eric Anholt
___
On Fri, Apr 3, 2020 at 6:58 AM Daniel Vetter wrote:
>
> Also allows us to simplify the unroll code since the drm_dev_put
> disappears.
>
> Signed-off-by: Daniel Vetter
Acked-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Fri, Apr 3, 2020 at 6:59 AM Daniel Vetter wrote:
>
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
Acked-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Fri, Apr 3, 2020 at 6:58 AM Daniel Vetter wrote:
>
> We already have it in v3d_dev->drm.dev with zero additional pointer
> chasing. Personally I don't like duplicated pointers like this
> because:
> - reviewers need to check whether the pointer is for the same or
> different objects if there's
On Fri, Apr 3, 2020 at 6:58 AM Daniel Vetter wrote:
>
> We already have it in v3d_dev->drm.dev with zero additional pointer
> chasing. Personally I don't like duplicated pointers like this
> because:
> - reviewers need to check whether the pointer is for the same or
> different objects if
On 4/3/20 8:58 AM, Daniel Vetter wrote:
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: David Lechner
---
Acked-by: David Lechner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Em Fri, 03 Apr 2020 09:56:42 -0700
Joe Perches escreveu:
> On Fri, 2020-04-03 at 14:10 +0200, Rasmus Villemoes wrote:
> > On 03/04/2020 11.11, Sakari Ailus wrote:
> > > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > > pixel formats denoted by 4ccs. The 4cc encoding
On 4/3/20 8:58 AM, Daniel Vetter wrote:
Already using devm_drm_dev_init, so very simple replacment.
Aside: There was an oddity in the old code, we allocated priv but in
the error path we've freed priv->dbidev ...
Signed-off-by: Daniel Vetter
Cc: David Lechner
---
Acked-by: David Lechner
On 4/3/20 8:58 AM, Daniel Vetter wrote:
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: "Noralf Trønnes"
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: David Lechner
---
Acked-by: David Lechner
Hi Daniel,
On Fri, Apr 03, 2020 at 06:43:20PM +0200, Daniel Lezcano wrote:
> On 18/03/2020 12:45, Lukasz Luba wrote:
> > From: Matthias Kaehlcke
> >
> > Now that devfreq supports limiting the frequency range of a device
> > through PM QoS make use of it instead of disabling OPPs that should
> >
On Fri, Apr 3, 2020 at 7:14 PM Linus Torvalds
wrote:
>
> On Fri, Apr 3, 2020 at 1:29 AM Daniel Vetter wrote:
> >
> > > Tested-by: Nathan Chancellor # build
> >
> > This works too, missed it when replying to Linus
> >
> > Reviewed-by: Daniel Vetter
> >
> > Linus I guess this one is better, but
On Fri, Apr 3, 2020 at 1:29 AM Daniel Vetter wrote:
>
> > Tested-by: Nathan Chancellor # build
>
> This works too, missed it when replying to Linus
>
> Reviewed-by: Daniel Vetter
>
> Linus I guess this one is better, but like I explained it really
> doesn't matter what we do with drm legacy
On Fri, 2020-04-03 at 14:10 +0200, Rasmus Villemoes wrote:
> On 03/04/2020 11.11, Sakari Ailus wrote:
> > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> > the same implementation can be used.
>
5 seconds on irc and I've found the splat ...
drm_properties need to be created at driver load time, upfront. You
can attach them to hotpluggable drm_connector objects later on, but
only before calling drm_connector_register().
The warning exists because i915 had the same bug :-)
-Daniel
On
On Fri, Apr 3, 2020 at 6:30 PM Michel Dänzer wrote:
>
>
> I'm getting the attached WARNING splats since amdgpu dropped its load
> callback. They're from
>
> WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb);
>
> in __drm_mode_object_add.
>
> I'm not sure how to address this,
I'm getting the attached WARNING splats since amdgpu dropped its load
callback. They're from
WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb);
in __drm_mode_object_add.
I'm not sure how to address this, since obj_free_cb is always NULL here,
and I don't think MST
[AMD Official Use Only - Internal Distribution Only]
> -Original Message-
> From: Guillaume Tucker
> Sent: Friday, April 3, 2020 10:14 AM
> To: Michael J. Ruhl ; Shane Francis
> ; Deucher, Alexander
>
> Cc: kerne...@groups.io; dri-devel@lists.freedesktop.org; linux-
>
On Fri, Apr 3, 2020 at 5:15 PM Daniel Vetter wrote:
>
> On Fri, Apr 3, 2020 at 5:06 PM Greg Kroah-Hartman
> wrote:
> >
> > On Fri, Apr 03, 2020 at 04:47:04PM +0200, Daniel Vetter wrote:
> > > On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Fri, Apr 03, 2020 at
Chunfeng Yun 於 2020年4月3日 週五 上午10:59寫道：
>
> On Thu, 2020-04-02 at 20:49 +0800, Chun-Kuang Hu wrote:
> > Hi, Matthias:
> >
> > Matthias Brugger 於 2020年4月1日 週三 下午11:53寫道：
> > >
> > >
> > >
> > > On 01/04/2020 04:16, Chunfeng Yun wrote:
> > > > On Tue, 2020-03-31 at 23:57 +0800, Chun-Kuang Hu wrote:
On Fri, Apr 3, 2020 at 5:06 PM Greg Kroah-Hartman
wrote:
>
> On Fri, Apr 03, 2020 at 04:47:04PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote:
> > > > In drm we've added nice
On Fri, Apr 03, 2020 at 04:47:04PM +0200, Daniel Vetter wrote:
> On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman
> wrote:
> >
> > On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote:
> > > In drm we've added nice drm_device (the main gpu driver thing, which
> > > also represents the
On Fri, Apr 03, 2020 at 04:51:33PM +0200, Daniel Vetter wrote:
> On Fri, Apr 3, 2020 at 4:47 PM Daniel Vetter wrote:
> >
> > On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote:
> > > > In drm we've added nice
On Fri, Apr 3, 2020 at 4:47 PM Daniel Vetter wrote:
>
> On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman
> wrote:
> >
> > On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote:
> > > In drm we've added nice drm_device (the main gpu driver thing, which
> > > also represents the userspace
On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman
wrote:
>
> On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote:
> > In drm we've added nice drm_device (the main gpu driver thing, which
> > also represents the userspace interfaces and has everything else
> > dangling off it) init
Hi Daniel.
On Fri, Apr 03, 2020 at 01:06:10PM +0200, Daniel Vetter wrote:
> It's empty!
>
> After more than 20 years of OS abstraction layer for pci devices, it's
> kinda gone now.
>
> Signed-off-by: Daniel Vetter
Looks good, and survived my build testing.
Acked-by: Sam Ravnborg
> ---
>
The feiyang,fy07024di26a30d.txt and sitronix,st7701.txt has been
converted to YAML schemas, update MAINTAINERS to match them again.
Signed-off-by: Jagan Teki
---
Changes for v3:
- none
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
Convert the sitronix,st7701 panel bindings to DT schema.
Signed-off-by: Jagan Teki
---
Changes for v3:
- update the licence, used (GPL-2.0-only OR BSD-2-Clause) since
I'm the author for old binding
- use panel-common.yaml
- mark true for common properties
- use maxItems: 1 for reg
- update
Convert the feiyang,fy07024di26a30d panel bindings to DT schema.
Signed-off-by: Jagan Teki
---
Changes for v3:
- update the licence, used (GPL-2.0-only OR BSD-2-Clause) since
I'm the author for old binding
- use panel-common.yaml
- mark true for common properties
- use maxItems: 1 for reg
-
On Fri, 2020-04-03 at 15:24 +0300, Pekka Paalanen wrote:
> On Fri, 03 Apr 2020 10:15:21 + Simon Ser wrote:
>
> > Additionally, I've heard Pekka saying that it would be nice to have
> > constants
> > for property names in the UAPI headers. Indeed, this would prevent
> > hard-to-debug typo
Em Fri, 3 Apr 2020 14:10:53 +0200
Rasmus Villemoes escreveu:
> On 03/04/2020 11.11, Sakari Ailus wrote:
> > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> > the same implementation can be used.
On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote:
> In drm we've added nice drm_device (the main gpu driver thing, which
> also represents the userspace interfaces and has everything else
> dangling off it) init functions using devres, devm_drm_dev_init and
> soon devm_drm_dev_alloc
Please see the bisection report below about a boot failure.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.
This bisection was run with exynos_defconfig but the issue can
also be reproduced with
On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> pre-merge CI.
Thanks for the suggestion! I implemented something like this for Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
--
Earthling Michel
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 4 ++--
drivers/gpu/drm/armada/armada_debugfs.c | 2 +-
drivers/gpu/drm/armada/armada_drm.h | 2
Following functions are only used internally, not by drivers:
- drm_dev_init
- devm_drm_dev_init
- drmm_add_final_kfree
Also, now that we have a very slick and polished way to allocate a
drm_device with devm_drm_dev_alloc, update all the docs to reflect the
new reality. Mostly this consists of
Also remove the now no longer needed build bug on since that's already
not needed anymore with drmm_add_final_kfree. Conversion to managed
drm_device cleanup is easy, the final drm_dev_put() is already the
last thing in both the bind unbind as in the unbind flow.
Also, this relies on component.c
Luckily we're already well set up in the main driver, with
drm_dev_put() being the last thing in both the unload error case and
the pci remove function.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 17 -
drivers/gpu/drm/i915/i915_pci.c | 2 --
2 files
The big change is device_add so that device_del can auto-cleanup
devres resources. This allows us to use devm_drm_dev_alloc, which
removes the last user of drm_dev_init.
Signed-off-by: Daniel Vetter
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 31 +--
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: "Noralf Trønnes"
Cc: Rob Herring
Cc: Thomas Zimmermann
Cc: virtualizat...@lists.linux-foundation.org
Cc: Emil Velikov
---
Entirely not used, just copypasta.
Signed-off-by: Daniel Vetter
Cc: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index bb62d8e93985..3386270cb8a3 100644
Komeda uses the component framework, which does open/close a new
devres group around all the bind callbacks. Which means we can use
devm_ functions for managing the drm_device cleanup, with leaking
stuff in case of deferred probes or other reasons to unbind
components, or the component_master.
Just some prep work before we rework the lifetime handling, which
requires replacing all the drm_dev_put in selftests by something else.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +-
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Trønnes"
Cc: Sam Ravnborg
Cc: Eric Anholt
Cc: Thomas Zimmermann
Cc:
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: David Lechner
---
drivers/gpu/drm/tiny/st7586.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c
index
Also need to remove the drm_dev_put from the remove hook.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_drv.c | 15 ---
drivers/gpu/drm/qxl/qxl_drv.h |
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: David Lechner
---
drivers/gpu/drm/tiny/ili9225.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
index
Also allows us to simplify the unroll code since the drm_dev_put
disappears.
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_drv.c | 31 ++-
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/tiny/hx8357d.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
index
Already using devm_drm_dev_init, so very simple replacment.
Aside: There was an oddity in the old code, we allocated priv but in
the error path we've freed priv->dbidev ...
Signed-off-by: Daniel Vetter
Cc: David Lechner
---
drivers/gpu/drm/tiny/st7735r.c | 13 -
1 file changed, 4
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/tiny/repaper.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
Also init the fbdev emulation before we register the device, that way
we can rely on the auto-cleanup and simplify the probe error code even
more.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Sean Paul
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Emil Velikov
Cc: Sam Ravnborg
Cc: Thomas
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_drv.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
---
drivers/gpu/drm/tiny/gm12u320.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git
We already have it in v3d_dev->drm.dev with zero additional pointer
chasing. Personally I don't like duplicated pointers like this
because:
- reviewers need to check whether the pointer is for the same or
different objects if there's multiple
- compilers have an easier time too
But also a bit a
We already have it in v3d_dev->drm.dev with zero additional pointer
chasing. Personally I don't like duplicated pointers like this
because:
- reviewers need to check whether the pointer is for the same or
different objects if there's multiple
- compilers have an easier time too
To avoid having to
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
---
drivers/gpu/drm/tiny/gm12u320.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
Not used anymore since the switch to suspend/resume helpers.
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.h
b/drivers/gpu/drm/tidss/tidss_drv.h
index
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: Kamlesh Gurudasani
---
drivers/gpu/drm/tiny/ili9486.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 7
1 - 100 of 169 matches
Mail list logo
