From: Ville Syrjälä
Let's be nice and interrupt the dpcd aux-dev reads/writes when there's
a signal pending. Much nicer if the user can hit ^C instead of having to
sit around waiting for the read/write to finish.
time dd if=/dev/drm_dp_aux0 bs=$((1024*1024))
^C
before:
real 0m34.681s
user
From: Ville Syrjälä
This series aims to clean up the way we fill out the display_info
structure a bit. Mainly doing a clean separation of the audio and
video related bits.
My aim is getting i915 to respect the HDMI sink TMDS clock limit
(currently we respect only the DP++ dongle limit, and th
From: Ville Syrjälä
Clear out stale audio latency information (potentially from a previous
EDID) before constructing the ELD from the EDID.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/dr
From: Ville Syrjälä
Clear out old max_tmds_clock and dvi_dual information (possibly from a
previous EDID) before parsing the current EDID. Tne current EDID might
not even have these in its HDMI VSDB, which would mean that we'd leave
the old stale values in place.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
We generally store clocks in kHz, so let's do that for the
HDMI max TMDS clock value as well. Less surpising.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +-
drivers/gpu/drm/drm_edid.c
From: Ville Syrjälä
Instead of parsing parts of the CEA extension block in two places
to determine supported color formats and whatnot, let's just
consolidate it to one function. This also makes it possible to neatly
flatten drm_assign_hdmi_deep_color_info().
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
We have the drm_display_info for storing information about the sink, so
let's move dvi_dual and max_tmds_clock in there.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 4 ++--
drivers/gpu/drm/
From: Ville Syrjälä
It's not a good idea to leave stale cea_rev in the drm_display_info. The
current EDID might not even have a CEA ext block in which case we'd end
up leaving the stale value in place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 1 +
1 file changed, 1 ins
From: Ville Syrjälä
drm_edid_to_eld() is just mean to cook up the ELD for the audio driver,
so having it parse non-audio related stuff seems just wrong, and
potentially could lead to that information not being even filled out
if the function doesn't even get called. Let's move that stuff to the
From: Ville Syrjälä
We already pass the connector to drm_add_display_info() and
drm_assign_hdmi_deep_color_info(), so passing the
connector->display_info also is pointless.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 11 ---
1 file changed, 4 insertions(+), 7 dele
From: Ville Syrjälä
Reduce the eyesore with a local variable.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.
From: Ville Syrjälä
It's perfectly legal for the sink to support 12bpc only for
some lower resolution modes, while the higher resolution modes
can only be used with 8bpc. So let's take the sink's max TMDS clock
into account before we go and decide that a particular mode can
be used with 12bpc.
From: Ville Syrjälä
Add a version of drm_plane_helper_check_update() which takes a plane
state instead of having the caller pass in everything.
And to reduce code duplication, let's reimplement
drm_plane_helper_check_update() in terms of the new function, by
having a tempororary plane state on
From: Ville Syrjälä
We don't want all planes to be added to the state whenever a
plane with fixed zpos gets enabled/disabled. This is true
especially for eg. cursor planes on i915, as we want cursor
updates to go through w/o throttling. Same holds for drivers
that don't support zpos at all (i91
From: Ville Syrjälä
We don't want all planes to be added to the state whenever a
plane with fixed zpos gets enabled/disabled. This is true
especially for eg. cursor planes on i915, as we want cursor
updates to go through w/o throttling. Same holds for drivers
that don't support zpos at all (i91
From: Ville Syrjälä
Here's a repost of my PSR fixes, and one straggler from Daniel.
One interesting thing I noticed is that my SKL actually hits the PSR setup
time vs. vblank length check, so after these patches that machine won't
actually use PSR. The panel does support a lower refresh rate t
From: Ville Syrjälä
Add a small helper to parse the PSR setup time from the DPCD PSR
capabilities and return the value in microseconds.
v2: Don't waste so many bytes on the psr_setup_time_us[] table
Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gp
From: Ville Syrjälä
Add a small helper to parse from the DPCD whether link training
is required when exiting PSR main-link off mode.
v2: Rebased
Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 14 ++
include/drm
From: Ville Syrjälä
Bspec says:
"Restriction : SRD must not be enabled when the PSR Setup time from DPCD
00071h is greater than the time for vertical blank minus one line."
Let's check for that and disallow PSR if we exceed the limit.
Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
Signed-off-
From: Daniel Vetter
Not sure we can trust VBT on this one, but let's try.
Cc: Rodrigo Vivi
Cc: Sonika Jindal
Cc: Durgadoss R
Signed-off-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_psr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm
From: Ville Syrjälä
The sink can tell us if link training needs to be performed when
exiting PSR main-link off mode. Currently we get that information
from the VBT, but at least on my HSW the VBT says one thing, the sink
another. And in practice the sink doesn't seem to notice any screen
update
From: Ville Syrjälä
Determine the value of psr.link_standby at runtime rather than at init
time. This helps in testing since you can change between link-off and
link-standby at runtime.
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_psr.c | 41 +
From: Ville Syrjälä
This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.
Adding new mode flags willy nilly breaks existing userspace. We need to
coordinate this better, potentially with a new client cap that only
exposes the aspect ratio flags when userspace is prepared for them
(simi
From: Ville Syrjälä
This reverts commit 6dffd431e2296cda08e7e4f0242e02df1d1698cd.
Adding new mode flags willy nilly breaks existing userspace. We need to
coordinate this better, potentially with a new client cap that only
exposes the aspect ratio flags when userspace is prepared for them
(simi
From: Ville Syrjälä
All the VICs apart from 58 and 59 have the word "Hz" included in the
comment. Include it for 59 and 59 as well.
Cc: Shashank Sharma
Cc: Andrzej Hajda
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Ville Syrjälä
CEA-861 specifies that the vertical front porch may vary by one or two
lines for specific VICs. Up to now we've only considered a mode to match
the VIC if it matched the shortest possible vertical front porch length
(as that is the variant we store in cea_modes[]). Let's all
From: Ville Syrjälä
Existing userspace expected the mode flags to match the xrandr
definitions 1:1, and even adding new flags in he previously unused
bits is likely to break existing userspace. Add a comment warning
people about this potential trap.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Aka
From: Ville Syrjälä
It has been suggested that having per-plane modifiers is making life
more difficult for userspace, so let's just retire modifier[1-3] and
use modifier[0] to apply to the entire framebuffer.
Obviosuly this means that if individual planes need different tiling
layouts and wha
From: Ville Syrjälä
This series aims to remove the duplicated format information stored under
drm_framebuffer (depth,bits_per_pixel,pixel_format), and instead we just
use the drm_format_info structure. And we store a pointer to the approriate
drm_format_info under drm_framebuffer so that we don
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
While at it switch over to using the pixel format rather than
depth+bpp.
Cc: intel-gfx at lists.freedesktop.org
Signed-off
From: Ville Syrjälä
Use DIV_ROUND_UP() instead of hand rolling it. Just a drive-by change.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/radeon/r100.c
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/ast/ast_mode.c | 15 ++-
1 file changed,
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 9 +
1 file changed, 5
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Patrik Jakobsson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/gma500/gma_display.c | 13 +++--
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 17 +
1 file
From: Ville Syrjälä
So it looks like the code is trying to pick between the passed in fb and
crtc->primary->fb based on that funky 'bool atomic'. But later it will
mix uses of both drm_fb (which was picked by the aforementioned logic)
and crtc->primary->fb. So looks like a bug to me. Let's make
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Ben Skeggs
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
drivers/gpu/drm/nou
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my ppor
coccinelle skills later.
In some places the local variable was already there, just not used
consistently.
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: M
From: Ville Syrjälä
drm_framebuffer_init() will start to check that fb->dev is already
populated, so let's to that manually since vmwgfx isn't using
drm_helper_mode_fill_fb_struct().
Cc: linux-graphics-maintainer at vmware.com
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Signed-off-by: Ville Syrjä
From: Ville Syrjälä
Pass the drm_device to drm_helper_mode_fill_fb_struct() so that we can
populate fb->dev early. Will make it easier to use the fb before we
register it.
@@
identifier fb, mode_cmd;
@@
void drm_helper_mode_fill_fb_struct(
+struct drm_devic
From: Ville Syrjälä
Stuff something semi-reasonable into fb->pixel_format. I had to guess
as to which formats we should pick. Did I guess correctly?
We can't quite use drm_mode_legacy_fb_format() due to the ARGB1555
vs. XRGB155 mess. However use of 'A' formats should imply per-pixel
alpha blen
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my ppor
coccinelle skills later.
Cc: Alexey Brodkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 3 ++-
1 file changed, 2 inser
From: Ville Syrjälä
We want framebuffers to be mostly useable already before
drm_framebuffer_init() is called, and so we will start demanding that
all the interesting format/size/etc. information be filled in before
drm_framebuffer_init(). drm_helper_mode_fill_fb_struct() will do that
for us, s
From: Ville Syrjälä
We want framebuffers to be mostly useable already before
drm_framebuffer_init() get called, and so we will start demanding that
all the interesting format/size/etc. information be filled in before
drm_framebuffer_init(). drm_helper_mode_fill_fb_struct() will do that
for us,
From: Ville Syrjälä
To avoid having to look up the format information struct every time,
let's just store a pointer to it under drm_framebuffer.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_framebuffer.c| 4 +++-
drivers/gpu/drm/drm_modeset_helper.c | 1 +
include/drm/drm_frame
From: Ville Syrjälä
Populate the fb->format to point at the correct format information
structure.
Cc: linux-graphics-maintainer at vmware.com
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 ++
1 file changed, 2 insertions(+)
From: Ville Syrjälä
We want the fbs inherited from the BIOS to be more or less fully working
prior to actually registering them. This will allow us to just pass the
fb to various helper function instead of having to pass all the
different parameters separately.
Cc: intel-gfx at lists.freedeskt
From: Ville Syrjälä
Populating fb->dev before drm_framebuffer_init() allows us to use
fb->dev already while validating the framebuffer. Let's have
drm_helper_mode_fill_fb_struct() do that for us.
Also make drm_framebuffer_init() warn us if a different device
pointer is passed to it than was pa
From: Ville Syrjälä
MAke sure the framebuffer format info is available as early as possible
for fbs we inherit from the BIOS. This will allow us to use the fb as
if it was fully formed before we register it.
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gp
From: Ville Syrjälä
Avoid the format info lookup and just use the pointer stored under
drm_framebuffer.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomi
From: Ville Syrjälä
Rather than store the pixel format and look up the format info as
needed, let's just store a pointer to the format info directly
and speed up our lookups.
Cc: Paulo Zanoni
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i91
From: Ville Syrjälä
Get the format information via the neat fb->format pointer rather than
doing a linear search over all the format info structures.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fb_cma_helper.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a
From: Ville Syrjälä
Let's use the pointer to the format information cached under
drm_framebuffer rather than look it up manually.
Cc: Ben Skeggs
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/nouveau/nv50_display.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff
From: Ville Syrjälä
Add variants of drm_format_plane_{width,height}() that take an entire fb
object instead of just the format. These should be more efficent as they
can just look up the format info from the fb->format pointer rather than
having to look it up (using a linear search based on the
From: Ville Syrjälä
Avoid the fb format information lookups when we already have the
fb->format pointer at hand.
@@
struct drm_framebuffer *fb;
expression E;
@@
- drm_format_plane_cpp(fb->pixel_format, E)
+ fb->format->cpp[E]
@@
struct drm_framebuffer fb;
expression E;
@@
- drm_format_plane_c
From: Ville Syrjälä
No need to look up the format info to get the number of planes, just
use fb->format->num_planes directly.
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ville Syrjälä
Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8.
Less duplicated information is a good thing.
Note that I didn't put parens around the cpp*8 in the below cocci script,
on account of not wanting spurious parens all over the place. Instead I
did the unsafe way, a
From: Ville Syrjälä
Replace uses of fb->depth with fb->format->depth. Less duplicate
information is a good thing.
@@
struct drm_framebuffer *fb;
expression E1, E2;
@@
drm_helper_mode_fill_fb_struct(...) {
...
- fb->depth = E1;
...
}
@@
struct vmw_framebuffer_surface *v
From: Ville Syrjälä
Replace drm_format_plane_{width,height}() usage with
drm_framebuffer_plane_{width,height}() to avoid the lookup of the format
info.
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 5 ++---
1 file changed, 2
From: Ville Syrjälä
Replace uses of fb->bits_per_pixel with fb->format->format.
Less duplicated information is a good thing.
Note that coccinelle failed to eliminate the
"/* fourcc format */" comment from drm_framebuffer.h, so I had
to do that part manually.
@@
struct drm_framebuffer *fb;
exp
From: Ville Syrjälä
Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8.
Less duplicated information is a good thing.
Note that I didn't put parens around the cpp*8 in the below cocci script,
on account of not wanting spurious parens all over the place. Instead I
did the unsafe way, a
From: Ville Syrjälä
Second installment of my effort to remove the duplicated
depth/bpp/pixel_format from drm_framebuffer and just use
struct drm_format_info instead.
I tried to address all of the review feedback, and collect
up all the r-bs I already got. Thanks for the review, guys.
Changes
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
While at it switch over to using the pixel format rather than
depth+bpp.
Cc: intel-gfx at lists.freedesktop.org
Signed-off
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/r
From: Ville Syrjälä
Use DIV_ROUND_UP() instead of hand rolling it. Just a drive-by change.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletio
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 17 +
1 file
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/ast/ast_mode.c | 15 ++-
1 file changed,
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my ppor
coccinelle skills later.
Cc: Alexey Brodkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 3 ++-
1 file changed, 2 inser
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my ppor
coccinelle skills later.
In some places the local variable was already there, just not used
consistently.
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: M
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 9 +
1 file changed, 5
From: Ville Syrjälä
So it looks like the code is trying to pick between the passed in fb and
crtc->primary->fb based on that funky 'bool atomic'. But later it will
mix uses of both drm_fb (which was picked by the aforementioned logic)
and crtc->primary->fb. So looks like a bug to me. Let's make
From: Ville Syrjälä
drm_framebuffer_init() will start to check that fb->dev is already
populated, so let's to that manually since vmwgfx isn't using
drm_helper_mode_fill_fb_struct().
Cc: linux-graphics-maintainer at vmware.com
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Signed-off-by: Ville Syrjä
From: Ville Syrjälä
Pass the drm_device to drm_helper_mode_fill_fb_struct() so that we can
populate fb->dev early. Will make it easier to use the fb before we
register it.
@@
identifier fb, mode_cmd;
@@
void drm_helper_mode_fill_fb_struct(
+struct drm_devic
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Patrik Jakobsson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/gma500/gma_display.c | 13 +++--
From: Ville Syrjälä
Stuff something semi-reasonable into fb->pixel_format. I had to guess
as to which formats we should pick. Did I guess correctly?
We can't quite use drm_mode_legacy_fb_format() due to the ARGB1555
vs. XRGB155 mess. However use of 'A' formats should imply per-pixel
alpha blen
From: Ville Syrjälä
We want framebuffers to be mostly useable already before
drm_framebuffer_init() is called, and so we will start demanding that
all the interesting format/size/etc. information be filled in before
drm_framebuffer_init(). drm_helper_mode_fill_fb_struct() will do that
for us, s
From: Ville Syrjälä
We want the fbs inherited from the BIOS to be more or less fully working
prior to actually registering them. This will allow us to just pass the
fb to various helper function instead of having to pass all the
different parameters separately.
Cc: intel-gfx at lists.freedeskt
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Ben Skeggs
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
drivers/gpu/drm/nou
From: Ville Syrjälä
We want framebuffers to be mostly useable already before
drm_framebuffer_init() get called, and so we will start demanding that
all the interesting format/size/etc. information be filled in before
drm_framebuffer_init(). drm_helper_mode_fill_fb_struct() will do that
for us,
From: Ville Syrjälä
To avoid having to look up the format information struct every time,
let's just store a pointer to it under drm_framebuffer.
v2: Don't populate the fb->format pointer in drm_framebuffer_init().
instead we'll treat a NULL format as an error later
Cc: Laurent Pinchart
S
From: Ville Syrjälä
Make sure the framebuffer format info is available as early as possible
for fbs we inherit from the BIOS. This will allow us to use the fb as
if it was fully formed before we register it.
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gp
From: Ville Syrjälä
Populating fb->dev before drm_framebuffer_init() allows us to use
fb->dev already while validating the framebuffer. Let's have
drm_helper_mode_fill_fb_struct() do that for us.
Also make drm_framebuffer_init() warn us if a different device
pointer is passed to it than was pa
From: Ville Syrjälä
Populate the fb->format to point at the correct format information
structure.
Cc: linux-graphics-maintainer at vmware.com
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 ++
1 file changed, 2 insertions(+)
From: Ville Syrjälä
Any framebuffer that doesn't have proper format information when
drm_framebuffer_init() is called is a bug. Let's warn and return
an error to avoid oopsing the kernel later due to dereferencing the
NULL fb->format pointer.
Cc: Laurent Pinchart
Suggested-by: Laurent Pinchar
From: Ville Syrjälä
Don't access plane_state->fb until we know the plane to be visible.
It it's visible, it will have an fb, and thus we don't have to
consider the NULL fb case. Makes the code look nicer.
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/d
From: Ville Syrjälä
Get the format information via the neat fb->format pointer rather than
doing a linear search over all the format info structures.
Signed-off-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/drm_fb_cma_helper.c | 5 +
1 file changed, 1 insertion(+
From: Ville Syrjälä
Replace drm_format_num_planes(fb->pixel_format) with just
fb->format->num_planes. Avoids the expensive format info lookup.
@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
@@
(
- drm_format_num_planes(a->pixel_format)
+ a->format->num_planes
|
- drm_format_num_planes
From: Ville Syrjälä
Rather than store the pixel format and look up the format info as
needed, let's just store a pointer to the format info directly
and speed up our lookups.
Cc: Paulo Zanoni
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i91
From: Ville Syrjälä
Add variants of drm_format_plane_{width,height}() that take an entire fb
object instead of just the format. These should be more efficent as they
can just look up the format info from the fb->format pointer rather than
having to look it up (using a linear search based on the
From: Ville Syrjälä
Let's use the pointer to the format information cached under
drm_framebuffer rather than look it up manually.
Cc: Ben Skeggs
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/nouveau/nv50_display.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff
From: Ville Syrjälä
Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8.
Less duplicated information is a good thing.
Note that I didn't put parens around the cpp*8 in the below cocci script,
on account of not wanting spurious parens all over the place. Instead I
did the unsafe way, a
From: Ville Syrjälä
Rather than compare the format u32s of two format infos, we can direclty
compare the format info pointers themselves. Noramlly all the ->format
pointers all point to somwehere in the big array, so this is a valid
way to test for equality.
Also drivers may want to point ->fo
From: Ville Syrjälä
Replace uses of fb->depth with fb->format->depth. Less duplicate
information is a good thing.
@@
struct drm_framebuffer *fb;
expression E1, E2;
@@
drm_helper_mode_fill_fb_struct(...) {
...
- fb->depth = E1;
...
}
@@
struct vmw_framebuffer_surface *v
From: Ville Syrjälä
Replace drm_format_plane_cpp(fb->pixel_format) with just
fb->format->cpp[]. Avoids the expensive format info lookup.
@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
expression E;
@@
(
- drm_format_plane_cpp(a->pixel_format, E)
+ a->format->cpp[E]
|
- drm_format_plan
From: Ville Syrjälä
By providing our own format information for the CCS formats, we should
be able to make framebuffer_check() do the right thing for the CCS
surface as well.
Note that we'll return the same format info for both Y and Yf tiled
format as that's what happens with the non-CCS Y vs
From: Ville Syrjälä
Replace uses of fb->pixel_format with fb->format->format.
Less duplicated information is a good thing.
Note that coccinelle failed to eliminate the
"/* fourcc format */" comment from drm_framebuffer.h, so I had
to do that part manually.
@@
struct drm_framebuffer *fb;
expre
From: Ville Syrjälä
Allow drivers to return a custom drm_format_info structure for special
fb layouts. We'll use this for the compression control surface in i915.
Cc: Ben Widawsky
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fb_cma_helper.c
From: Ville Syrjälä
Replace drm_format_plane_{width,height}() usage with
drm_framebuffer_plane_{width,height}() to avoid the lookup of the format
info.
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 5 ++---
1 file changed, 2
From: Ville Syrjälä
No point in spamming the log whenever a non-RGB fb is being
constructed. And since there's nothing to do anymore that
fb->bits_per_pixel and fb->depth are gone, we can just kill
off this entire piece of code.
Cc: Laurent Pinchart
Suggested-by: Laurent Pinchart
Signed-off-
1 - 100 of 933 matches
Mail list logo
