From: Ville Syrj?l?
Change drm_mode_object_get() to return -ENOMEM if idr_pre_get() fails,
and also handle -ENOSPC from idr_get_new_above().
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/
Mostly fixes for various bits and pieces that caught my eye while
reading the mode setting code.
From: Ville Syrj?l?
Make sure the requested CRTC viewport fits inside the
framebuffer.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_c
From: Ville Syrj?l?
The drm_display_mode type is a bitmask so it should be unsigned.
Signed-off-by: Ville Syrj?l?
---
include/drm/drm_crtc.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 2a0872c..31715bd 100644
-
From: Ville Syrj?l?
Add a helper function to copy a display mode. Use it in
drm_mode_duplicate() and nouveau mode_fixup hooks.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_modes.c| 28 +++-
drivers/gpu/drm/nouveau/nv50_dac.c |7 ++-
drivers/gpu
From: Ville Syrj?l?
Check drm_mode_object_get() return value everywhere.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c| 95 -
drivers/gpu/drm/drm_crtc_helper.c |2 +
include/drm/drm_crtc.h| 22
3 files chang
From: Ville Syrj?l?
The error handling code w.r.t. idr usage looks inconsistent.
In the case of drm_mode_object_get() and drm_ctxbitmap_next() the error
handling is also incomplete.
Unify the code to follow the same pattern always.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_context
From: Ville Syrj?l?
If there are pending page flips when the fd gets closed those page
flips may have events associated to them. When the page flip eventually
completes it will queue the event to file_priv->event_list, but that
may be too late and file_priv->event_list has already been cleaned up
From: Ville Syrj?l?
Warn when there are events on the file_priv->event_list just before
file_priv gets freed. This can occur if the driver doesn't clean up
pending page flip events in ->preclose().
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_fops.c | 2 ++
1 file changed, 2 insertions
From: Ville Syrj?l?
This is mostly a repost of the earlier series [1]. Most of the patches
have been reviewed, but I have added quite a few new ones to the end to
fix various issues.
[1] http://lists.freedesktop.org/archives/dri-devel/2014-May/060518.html
Ville Syrj?l? (19):
drm: Always rejec
From: Ville Syrj?l?
Make sure drm_vblank_get() never succeeds when called between
drm_vblank_off() and drm_vblank_on(). Borrow a trick from the
old drm_vblank_{pre,post}_modeset() functions and just bump
the refcount in drm_vblank_off() and drop it in drm_vblank_on().
When drm_vblank_get() encou
From: Ville Syrj?l?
v2: Drop the drm_vblank_off() (Daniel)
Use drm_crtc_vblank_{get,put}()
Reviewed-by: Matt Roper
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/
From: Ville Syrj?l?
Clearing the timestamps causes us to send zeroed timestamps to userspace
if they get sent out in response to the drm_vblank_off(). It's better
to send the very latest timestamp and count instead.
Testcase: igt/kms_flip/modeset-vs-vblank-race
Reviewed-by: Matt Roper
Reviewed-
From: Ville Syrj?l?
Move drm_update_vblank_count() to avoid forward a declaration.
No functional change.
Reviewed-by: Matt Roper
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 128 +++---
1 file changed, 64 insertions(+), 64 deletions(-)
From: Ville Syrj?l?
If the vblank irq has already been disabled (via the disable timer) when
we call drm_vblank_off() sample the counter and timestamp one last time.
This will make the sure that the user space visible counter will account
for time between vblank irq disable and drm_vblank_off().
From: Ville Syrj?l?
Declare a local struct drm_vblank_crtc * and use that
instead of having to do dig it out via 'dev->vblank[crtc]'
everywhere.
Performed with the following coccinelle incantation,
and a few manual whitespace cleanups:
@@
identifier func,member;
expression num_crtcs;
struct drm
From: Ville Syrj?l?
Currently it's possible that the following will happen:
1. drm_wait_vblank() calls drm_vblank_get()
2. drm_vblank_off() gets called
3. drm_wait_vblank() calls drm_queue_vblank_event() which
adds the event to the queue event though vblank interrupts
are currently disabled
From: Ville Syrj?l?
Make drm_vblank_put() disable the vblank interrupt immediately when the
refcount drops to zero and drm_vblank_offdelay<0.
v2: Preserve the current drm_vblank_offdelay==0 'never disable' behaviur
Reviewed-by: Matt Roper
Signed-off-by: Ville Syrj?l?
---
Documentation/DocBoo
From: Ville Syrj?l?
Currently both drm_irq.c and several drivers call drm_vblank_put()
while holding event_lock. Now that drm_vblank_put() can disable the
vblank interrupt directly it may need to grab vbl_lock and
vblank_time_lock. That causes deadlocks since we take the locks
in the opposite ord
From: Ville Syrj?l?
When drm_vblank_on() is called the hardware vblank counter may have
been reset, so we can't trust that the old values sampled prior to
drm_vblank_off() have anything to do with the new values.
So update the .last count in drm_vblank_on() to make the first
drm_vblank_enable()
From: Ville Syrj?l?
Add a flag to drm_device which will cause the vblank code to bypass the
disable timer and always disable the vblank interrupt immediately when
the last reference is dropped.
v2: Add some notes about the flag to the kernel doc
Reviewed-by: Matt Roper
Reviewed-by: Daniel Vett
From: Ville Syrj?l?
If the user is interested in getting accurate vblank sequence
numbers all the time they may disable the vblank disable timer
entirely. In that case it seems appropriate to kick start the
vblank interrupts already from drm_vblank_on().
v2: Adapt to the drm_vblank_offdelay ==0
From: Ville Syrj?l?
If we already have a timestamp for the current vblank counter, don't
update it with a new timestmap. Small errors can creep in between two
timestamp queries for the same vblank count, which could be confusing to
userspace when it queries the timestamp for the same vblank seque
From: Ville Syrj?l?
During vblank disable the code tries to guess based on the
timestamps whether we just missed one vblank or not. And if so
it increments the counter. However it forgets to store the new
timestamp to the approriate slot in our timestamp ring buffer.
So anyone querying the timest
From: Ville Syrj?l?
Now that the vblank races are plugged, we can opt out of using
the vblank disable timer and just let vblank interrupts get
disabled immediately when the last reference is dropped.
Gen2 is the exception since it has no hardware frame counter.
Reviewed-by: Matt Roper
Reviewed
From: Ville Syrj?l?
We should update the last in drm_update_vblank_count() to avoid applying
the diff more than once. This could occur eg. if drm_vblank_off() gets
called multiple times for the crtc.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 2 ++
1 file changed, 2 insertion
From: Ville Syrj?l?
We call drm_vblank_off() during crtc sanitation to make sure the
software and hardware states agree. However drm_vblank_off() will
try to update the vblank timestamp and sequence number which lands
us in some trouble.
As the pipe is disabled the hardware frame counter query w
From: Ville Syrj?l?
The kernel might mistakenly send out a zeroed vblank timestamp when
the vblank wait gets terminated early due to crtc disable. Add an
assertion to catch that.
Signed-off-by: Ville Syrj?l?
---
tests/kms_flip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/kms_
From: Ville Syrj?l?
Now that drm_update_vblank_count() can be called even when we're not
about to enable the vblank interrupts we shouldn't print debug messages
stating otherwise.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ville Syrj?l?
update_scanline_offset() in intel_sanitize_crtc() was supposed to
be called only for active crtcs. But due to some underrun patches it
now gets updated for all crtcs on gmch platforms.
Move the update_scanline_offset() to the very beginning of
intel_sanitize_crtc() where we u
From: Ville Syrj?l?
kms_flip_event_leak will issue a page flip and close the file
descriptor before the flip has finished. This may cause the kernel
to leak the page flip event. The test itself won't actually fail but
if the kernel notices the leak and WARNs piglit will report a failure.
Signed-
From: Ville Syrj?l?
drm_fb_get_bpp_depth() likes to complain about unsupported pixel formats
but doesn't bother telling us what the format was. Also format_check()
just returns an error when it encouters an invalid format, leaving the
user scratching his head trying to figure out why addfb failed
We're rather inconsistent in which error values we return to userspace
on failure. I want to unify the behaviour a bit and consistently return
ENOENT when mode object lookups fail. We already do that in a few places
but in most places we just return EINVAL.
I made a separate patch for each affect
From: Ville Syrj?l?
Return -ENOENT for framebuffers like we do for other mode objects that
can't be found.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/d
From: Ville Syrj?l?
We tend to return -EINVAL for everything. Let's try to help poor
userland developers a bit by at least returning -ENONET for missing
objects.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 32 ++--
1 file changed, 18 insertions(+),
From: Ville Syrj?l?
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/gma500/psb_drv.c | 4 ++--
drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma5
From: Ville Syrj?l?
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_displ
From: Ville Syrj?l?
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/radeon/r100.c| 2 +-
drivers/gpu/drm/radeon/r600_cs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gp
From: Ville Syrj?l?
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index fc
From: Ville Syrj?l?
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.
So I took another look at the vblank timestamping code, and got a bit
excited. The result is this patchset.
Summary of changes:
- kill crtc->hwmode dependency
- eliminate a bunch of 64bit math
- fix timestamps for stereo and interlaced modes (on i915 at least)
- move the "early vbl irq" hack into
From: Ville Syrj?l?
We don't really use hwmode anymore in i915, so eliminating its use
from the core code seems prudent. Just pass the appropriate mode
to drm_calc_timestamping_constants().
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c| 2 +-
drivers/gpu/drm/drm_irq.c
From: Ville Syrj?l?
Rather than using crtc->hwmode, just pass the relevant mode to
drm_calc_vbltimestamp_from_scanoutpos(). This removes the last hwmode
usage from core drm.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 6 +++---
drivers/gpu/drm/i915/i915_irq.c | 3
From: Ville Syrj?l?
drm core no longer uses crtc->hwmode, and neither does i915, so we can totally
ignore it
in i915.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
From: Ville Syrj?l?
Update the pixel/line/frame duration information when we switch to the
new pipe config. This will keep the timestamping constants in better
sync with the real hardware state.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 17 -
1 fil
From: Ville Syrj?l?
drm_calc_timestamping_constants() makes the math more complex
than necessary.
- multipying the dotclock by 1000 is pointless, just makes all the
numbers bigger
- div64_u64() is also pointless, div_u64 is enough
- pixeldur_ns doesn't need any 64bit math
Signed-off-by: Ville
From: Ville Syrj?l?
crtc_clock is now supposed to be the actual pixel clock corresponding to
the other crtc_ timing values. Populate crtc_clock appropriately in
radeon_atom_get_tv_timings().
This was the only obvious place where we frob with the crtc_ timigns
directly instead of calling drm_mode
From: Ville Syrj?l?
drm_calc_timestamping_constants() computes the pixel/line/frame
durations based on the crtc_ timing values. The corresponding pixel
clock is in mode->crtc_clock, so we need to use that instead of
mode->clock.
This should fix drm_calc_timestamping_constants() for frame packing
From: Ville Syrj?l?
Using s64 for the timestamping constants is wasteful. Signed 32bit
integers get us a range of over +-2 seconds. Presuming that no-one
wants to a vrefresh rate less than 0.5, we can switch to using int
for the timestamping constants. We save a few bytes in drm_crtc and
avoid a
From: Ville Syrj?l?
The scanline counter counts lines in the current field, not the entire
frame. But the crtc_ timings are the values for the entire frame. Divide
the vertical timings by 2 to make them match the scanline counter.
The rounding was carefully chosen to make it do the right thing w
From: Ville Syrj?l?
Preparation for moving the early vblank IRQ logic into
radeon_get_crtc_scanoutpos().
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 3 ++-
drivers/gpu/drm/radeon/radeon_display.c | 7 ---
driver
From: Ville Syrj?l?
Move the long blurp to into the body of the comment, leaving only
a short summary line at the top.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/driver
From: Ville Syrj?l?
We're currently miscalculating the line and pixel durations for
interlaced modes. crtc_htotal and crtc_vtotal are the full frame
timings, and so is crtc_clock, so we can compute the line
and pixel durations from those w/o any extra adjustments. But
we actually want framedur_ns
From: Ville Syrj?l?
On pre-PCH platforms ISR doesn't seem to be an actual ISR, at least as
far as display interrupts are concerned. Instead it sort of looks like
some ISR bits just directly reflect the corresponding bit from PIPESTAT.
The bit appears in the ISR only if the PIPESTAT interrupt is e
From: Ville Syrj?l?
i915 doesn't need this kludge for most platforms. Although we do
appear to need something similar on certain platforms, but we can
be more accurate when we apply the adjustment since we know exactly
why the scanline counter doesn't always quite match the vblank
status.
Also t
From: Ville Syrj?l?
Currently drm_cflush_virt_rage() takes a char* so the caller probably
has to do pointless casting to avoid compiler warnings. Make the
argument void* instead to avoid such issues.
v2: Use void* arithmetic (Chris)
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_cache.c
From: Ville Syrjälä
We had a bug in i915 land recently where X passed in a zeroed mode with
mode_valid=1 to setcrtc. That didn't go down so well and caused a
div-by-zero in i915.
For a long time I've been thinking that we need some real checks to
validate the modes we feed into the hardware. I
From: Ville Syrjälä
Make drm_mode_validate_size() and drm_mode_validate_flag() deal with a
single mode instead of having each iterate through the mode list.
The hope is that in the future we might be able to share various mode
validation functions between modeset and get_modes.
Signed-off-by:
From: Ville Syrjälä
Make sure the timings of probed modes at least pass some very basic
sanity checks.
The checks include:
- clock,hdisplay,vdisplay are non zero
- sync pulse fits within the blanking period
- htotal,vtotal are big enough
I have not checked all the drivers to see if the mod
From: Ville Syrjälä
Currently userspace is allowed to pass in basiclly any kind of garbage
to setcrtc. Try to catch the cases where the timings make no sense
by passing the mode through drm_mode_validate_basic().
One concern here is that we now start to block some modes that have
worked in the
From: Ville Syrj?l?
Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.
v2
From: Ville Syrj?l?
After playing around Sagar's primary plane rotation a bit, I decided that
extending that to full pipe rotation would be nice. Chris also seemed to
want that, but I'm not sure he does anymore :) But then I decided it's so
easy to implement that I can't leave it hanging. So here
From: Ville Syrj?l?
Allow rotation properties to have custom names.
TODO: maybe squash into "drm: Add drm_mode_create_rotation_property()"
Cc: Sagar Kamble
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 3 ++-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/
From: Ville Syrj?l?
I'd prefer have the crtc "rotation" property rotate the entire crtc
(planes and all). So for that reason we'd need to come up with some
other name for the "rotate the primary plane only" property.
Originally I had though that omapdrm had already made the decision for
us, but
From: Ville Syrj?l?
drm_rotation_chain() can be used to combine the plane and crtc rotations
to calculate the total rotation for a specific plane.
Cc: Sagar Kamble
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 42 ++
include/drm/drm_crtc
From: Ville Syrj?l?
The cursor plane also supports 180 degree rotation. Add a new
"cursor-rotation" property on the crtc which controls this.
Unlike sprites, the cursor has a fixed size, so if you have a small
cursor image with the rest of the bo filled by transparent pixels,
simply flipping the
From: Ville Syrj?l?
We can pretend that we can rotate the entire pipe by rotating all the
planes and adjusting their positions appropriately. Add a "rotation"
property on the crtc which will do this.
The main upshot of doing the full pipe rotation instead of rotating all
the planes individually
From: Ville Syrj?l?
I'm going to require vblank interrupts during modeset in i915 soon, however
the drm vblank code won't currently allow it. It simply refuses to re-enable
the vblank interrupts whenever they were disable and the refcount is
already elevated. That means anyone holding a vblank re
From: Peter Hurley
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/driver
From: Ville Syrj?l?
Currently there's one per-device vblank disable timer, and it gets
reset wheneven the vblank refcount for any crtc drops to zero. That
means that one crtc could accidentally be keeping the vblank interrupts
for other crtcs enabled even if there are no users for them. Make the
From: Ville Syrj?l?
If someone holds a vblank reference across the modeset, and after/during
the modeset someone tries to grab a vblank reference, the current code
won't re-enable the vblank interrupts. That's not good, so instead allow
the driver to choose whether drm_vblank_get() should always
From: Ville Syrj?l?
Tell the drm core vblank code to reject drm_vblank_get()s only between
drm_vblank_off() and drm_vblank_on() calls, and sprinkle the appropriate
drm_vblank_on() calls to the .crtc_enable() hooks. At this time I kept
the off calls in their current position, and added the on call
From: Ville Syrj?l?
Allow the driver to specify whether all new vblank requests after
drm_vblank_off() should be rejected. And add a counterpart called
drm_vblank_on() which will again allow vblank requests to come in.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/armada/armada_crtc.c |
From: Ville Syrj?l?
Use drm_fb_helper_restore_fbdev_mode() in drm_fb_helper_set_par() to
make sure extra planes get disabled whenever fbcon takes over.
Otherwise the code in drm_fb_helper_set_par() was already doing the
exact same thing as drm_fb_helper_restore_fbdev_mode(), so this doesn't
chan
This series adds a bunch of scaling and clipping related utility stuff to
drm core, and then implementes real clipping for intel sprite planes.
Most of this stuff was in my drm_atomic branch already for quite a while,
but I did do some minor changes here and there.
My glplane test app [1] can now
From: Ville Syrj?l?
These functions calculcate the scaling factor based on the source and
destination regions.
There are two version of the functions, the strict ones that will
return an error if the min/max scaling factor is exceeded, and the
relaxed versions that will adjust the src/dst region
From: Ville Syrj?l?
Add a debug function to print the region in a human readable format.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_region.c | 22 ++
include/drm/drm_region.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/drm_region.c
From: Ville Syrj?l?
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel boundary.
The scaling checks are don
From: Ville Syrj?l?
struct drm_region represents a two dimensional region. The utility
functions are there to help driver writers.
v2: Moved the region stuff into its own file, made the smaller funcs
static inline, used 64bit maths in the scaled clipping function to
avoid overflows (inst
This series tries fix and improve the 'Broadcast RGB' property on i915.
Currently the property takes has two values 'Full' and 'Limited 16:235'.
I'm adding a third option 'Automatic' that automagically changes between
full and limited range based on CEA-861 and DP1.2a rules.
I'm also adding suppo
From: Ville Syrj?l?
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
From: Ville Syrj?l?
intel_hdmi.has_hdmi_sink is tied into the force audio property, so it
doesn't seem like the correct way to detect HDMI monitors. Instead add
a new has_hdmi_monitor member which simply tells whether a HDMI monitor
was detected.
Not sure if this is the best way, or if we should
From: Ville Syrj?l?
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise ful
From: Ville Syrj?l?
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_edid.c | 33 +
From: Ville Syrj?l?
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforframe.
From: Ville Syrj?l?
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
From: Ville Syrj?l?
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforframe.
From: Ville Syrj?l?
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_edid.c | 33 +
Second attempt at handling the RGB quantization range for HDMI and DP.
The only change to the first set is that I dropped the
has_hdmi_monitor bool. has_hdmi_sink is used instead.
From: Ville Syrj?l?
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise ful
Third attempt at handling the RGB quantization range for HDMI and DP.
Changes since the last time:
- Addressed all of Paulo's review comments.
I think this is ready to go in, unless someone complains loudly.
From: Ville Syrj?l?
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
From: Ville Syrj?l?
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 [1] guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise
From: Ville Syrj?l?
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
v2: s/quantzation/quantization/ in the comment
Reviewed-by: Paulo Zanoni
Signed-off-by:
From: Ville Syrj?l?
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 [1] we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforfram
Looks like I accidentally broke 8bpp support in i915.
This series fixes the regression, as verified in the bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=59572#c18
There should be no negative effect on other drivers since they either
don't support 8bpp, or they don't bother with checkin
From: Ville Syrj?l?
Set depth/bits_per_pixel to 8 for C8 format.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9c797f6..ff7344c 100644
--- a/drivers/gpu/drm/drm_crtc.
From: Ville Syrj?l?
Support for real RGB332 is a rarity, most hardware only really support
C8. So use C8 instead of RGB332 when determining the format based on
depth/bpp.
This fixes 8bpp fbcon on i915, since i915 will only accept C8 and not
RGB332.
Bugzilla: https://bugs.freedesktop.org/show_bu
Just a few small items caught in my net while trawling the code.
From: Ville Syrj?l?
The rest of the code uses stdint types, so use them in
drm_property_change_is_valid() as well.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/dr
601 - 700 of 933 matches
Mail list logo
