From: Ville Syrjälä
Utilize drm_mode_match() instead of hand rolling it when
looking for the DRRS downclock mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_panel.c | 49 +++---
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu
From: Ville Syrjälä
Rename intel_find_panel_downclock() to intel_panel_edid_downclock_mode()
to make it clear it's looking for the downclock mode in the EDID.
And while at it polish the implementation a bit as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c| 4 +---
From: Ville Syrjälä
DSI has its own convoluted way of grabbing the fixed mode from
the VBT. Change it to follow the path laid out by LVDS/eDP.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/icl_dsi.c | 14 ++
drivers/gpu/drm/i915/intel_dsi.h | 1 -
drivers/gpu/drm
From: Ville Syrjälä
I added the loop but neglected to actually pass the level to the
function. So we were just looping 8 times calculating the exact
same thing every time.
Fixes: df331de3f8aa ("drm/i915: Allocate enough DDB for the cursor")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915
From: Ville Syrjälä
Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.
The concensus seems to be that this quirk is a bit misguided
anyway so let's
From: Ville Syrjälä
The AGPBUSY thing doesn't work on i945gm anymore. This means
the gmch is incapable of waking the CPU from C3 when an interrupt
is generated. The interrupts just get postponed indefinitely until
something wakes up the CPU. This is rather annoying for vblank
interrupts as we are
From: Ville Syrjälä
The vblank timestamp->counter guesstimator seems to be
working sufficiently well, so there's no reason not to
disable vblank interrupts ASAP even on gen2.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 8 +---
1 file changed, 1 insertion(+), 7 deleti
From: Ville Syrjälä
If I'm reading the spec right AML 0x87CA is a Y SKU, so it
should be marked as ULX in our old style terminology.
Cc: sta...@vger.kernel.org
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Fixes: c0c46ca461f1 ("drm/i915/aml: Add new Amber Lake PCI ID")
Signed-
From: Ville Syrjälä
Add the "Broadcast RGB" property to MST connectors, and implement
the same logic for it as we have in the SST code.
v2: Extract and reuse intel_dp_limited_color_range()
Cc: Ivan Vlk
Tested-by: Ivan Vlk
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108821
Signed-of
From: Ville Syrjälä
Allow the user to limit the output bpc with DP MST.
Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
From: Ville Syrjälä
We already expose the force_audio property with SST. Do the same
with MST.
Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp_mst.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/in
From: Ville Syrjälä
Update the DP MSA MISC bits for fastsets. This is needed
when we change between limited and full range RGB output.
On HSW+ changing limited_range does not currently result in a
full modeset since we have don't have the readout code for it
(for DP we could, and probably should
From: Ville Syrjälä
Allow DP MST to output any color depth. This means deep color as
well as falling back to 6bpc if we would otherwise require too
much bandwidth.
TODO: We should probably extend bw_contstrained scheme to force
all streams on the link to 6bpc if we can't fit the new stream(s)
ot
From: Ville Syrjälä
6bpc is only legal for RGB and RAW pixel encodings. For the rest
the minimum is 8bpc. Set our lower limit accordingly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 10 +-
drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/int
From: Ville Syrjälä
Currently we enable FEC even when DSC is no used. While that is
theoretically valid supposedly there isn't much of a benefit from
this. But more importantly we do not account for the FEC link
bandwidth overhead (2.4%) in the non-DSC link bandwidth computations.
So the code may
From: Ville Syrjälä
No point in duplicating all this code when we can just
use a variable top hold the output bpp (the only thing
that differs between the two branches).
Cc: Anusha Srivatsa
Cc: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 27 --
From: Ville Syrjälä
drm_display_info.name is only ever set by a few panel drveirs but
never actually used anywhere except in i915 debugfs code. Trash it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c| 1 -
drivers/gpu/drm/panel/panel-arm-versatile.c
From: Ville Syrjälä
A set of 8 spaces has snuck in. Replace with a tab, and
toss in an extra newline while at it.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_connector.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_con
From: Ville Syrjälä
drm_display_info.pixel_clock is unused. Let's get rid of it.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_connector.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index bb3bd8e1633a..fcdca46e0c24 1006
From: Ville Syrjälä
Remove the unused DRM_DISPLAY_INFO_LEN from the uapi headers.
I presume the original plan was to expose the display name
via getconnector, but looks like that never happened. So we have
the define for the length of the string but no string anywhere.
A quick scan didn't seem t
From: Ville Syrjälä
Repost of the earlier series to clean up intel_color_check().
I tried to address all of Matt's review comments (thanks!).
All reviewed except patch 8.
Ville Syrjälä (10):
drm/i915: Extract check_luts()
drm/i915: Turn intel_color_check() into a vfunc
drm/i915: Extract i
From: Ville Syrjälä
The current intel_color_check() is a mess, and worse yet it is
in fact incorrect for several platforms. The hardware has
evolved quite a bit over the years, so let's just go for a clean
split between the platforms by turning this into a vfunc.
The actual work to split it up wi
From: Ville Syrjälä
In prepartion for per-platform color_check() functions extract the
common code into a separate function.
v2: Improve the C8 comment (Matt)
Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/intel_color.c | 68 ++
1 fi
From: Ville Syrjälä
Apart from CHV the other gmch platforms don't currently
require much work in .color_check(). So let's start by
extracting i9xx_color_check().
Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/intel_color.c | 33 +-
1
From: Ville Syrjälä
ICL is rather easy when it comes to .color_check() as it
finally provides us with a full color pipeline with
individual knobs for each stage.
We'll also start bypassing each LUT individually when
it is not needed.
Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
---
d
From: Ville Syrjälä
Provide a separate .color_check() for BDW+ where we currently
provide the split gamma mode etc.
Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/intel_color.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/d
From: Ville Syrjälä
Unlike the earlier platforms GLK has dedicated degamma and gamma
LUTs. And quite curiously the degamma LUT is actually controlled
via the PLANE_COLOR_CTL CSC enable bit. Hence we must compute
gamma_enable and csc_enable differently to pre-GLK platforms.
Signed-off-by: Ville S
From: Ville Syrjälä
With everything else moved out of the way only ilk+
remains using _intel_color_check(). Streamline the logic
into ilk_color_check().
v2: Add some comments explaining we that we don't expose
the full hardware capabilities currently (Matt)
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Since CHV has the CGM unit we require a custom implementation
of .color_check().
This fixes the computation of gamma_enable as previously we
left it enabled even when were using the CGM gamma instead.
Now we turn off the legacy LUT unless it's actually required.
v2: Add some
From: Ville Syrjälä
Don't load the linear degamma LUT on ICL. The hardware no longer
has any silly linkages between the CSC enable and degamma LUT
enable so the degamma LUT is only needed when it's actually
enabled.
Also add comments to explain the situation on GLK.
v2: Drop useless parens arou
From: Ville Syrjälä
We now bypass the legacy LUT when it's not needed, so
no point in filling it up with a linear LUT.
Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/intel_color.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --gi
From: Ville Syrjälä
Extract a helper to calculate the ILK+ 10it gamma LUT entry.
It's already duplicated twice, and soon we'll have more.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_color.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
dif
From: Ville Syrjälä
Using the split gamma mode when we don't have to has the annoying
requirement of loading a linear LUT to the unused half. Instead
let's make life simpler by switching to the 10bit gamma mode
and duplicating each entry.
This also allows us to load the software gamma LUT into t
From: Ville Syrjälä
This series exposes the GAMMA_LUT/GAMMA_LUT_SIZE props on all
platforms, finally getting us back to some kind of uniformity.
On i965+ we also gain the ability to gamma correct 10bpc data
without crusing it to 8bpc with the legacy LUT.
To go beyond this we'll need the new uapi
From: Ville Syrjälä
Reuse the bdw+ code to get split/10bit gamma for
ivb/hsw. The hardware is nearly identical. The
only slight snag is that on ivb/hsw the precision
palette auto increment mode does not work. So we
must increment the index manually. We'll probably
want to stick to the auto increm
From: Ville Syrjälä
Just so we don't leave gen2/3 out in the cold let's advertize the
legacy LUT via the GAMMA_LUT/GAMMA_LUT_SIZE props. Without the
GAMMA_LUT prop we can't actually load a LUT using the atomic ioctl
(in preparation for the day of 100% atomic driver).
Supposedly some gen2/3 platf
From: Ville Syrjälä
Plop in support for 10bit LUT on ilk/snb.
There is no split gamma mode on these platforms, so we have
to choose between degamma and gamma. That could be a runtime choice
but for now let's just advertize the gamma as having 1024 entries.
We'll also keep the ctm hidden for now.
From: Ville Syrjälä
i965+ have an interpolate 10bit LUT mode. Let's expose that so
that we can actually enjoy real 10bpc.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_pci.c| 6 +++
drivers/gpu/drm/i915/i915_reg.h| 4 ++
drivers/gpu/drm/i915/intel_color.c | 62 ++
From: Ville Syrjälä
Using the split gamma mode when we don't have to has the annoying
requirement of loading a linear LUT to the unused half. Instead
let's make life simpler by switching to the 10bit gamma mode
and duplicating each entry.
This also allows us to load the software gamma LUT into t
From: Ville Syrjälä
CH7511 doesn't update SINK_COUNT properly so in order to detect
the device as connected we have to ignore SINK_COUNT.
In order to have access to the quirk list early enough we
must move the drm_dp_read_desc() call to happen earlier.
We can also skip re-reading this on eDP sin
From: Ville Syrjälä
CH7511 eDP->LVDS bridge doesn't seem to set SINK_COUNT properly
causing i915 to detect it as disconnected. Add a quirk to ignore
SINK_COUNT on these devices.
Cc: David S.
Cc: Peteris Rudzusiks
Tested-by: Peteris Rudzusiks
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi
From: Ville Syrjälä
All sprite planes have a progammable gamma ramp. Set it up with
a linear ramp on all platforms. This actually matches the reset
value but soon we'll want to reprogram this ramp on some machines,
so let's just set it up across the board.
Note that on pre-IVB the hardware bypa
From: Ville Syrjälä
We don't currently have any use for the sprite gamma on ivb-bdw.
Let's disable it. We already do that on skl+.
On pre-ivb there is no way to disable the sprite gamma, and it
only affects YCbCr pixel formats, whereas on ivb+ it also
affects RGB formats.
Signed-off-by: Ville S
From: Ville Syrjälä
Plane B and C (note that we don't actually expose plane C currently)
on gen2/3 have a window generator, as does the primary plane on CHV
pipe B. So let's allow positioning of these planes freely within the
pipe source area.
Plane A on gen2/3 seems to have some kind of partial
From: Ville Syrjälä
Docs tell us that on g4x we have to compute the SR watermarks
using 4 bytes per pixel. I'm going to assume that only applies
to 1 and 2 byte per pixel formats, and not 8 byte per pixel
formats. That seems like a recipe for an insufficient watermark
which could lead to underrun
From: Ville Syrjälä
Split the format lists for different planes on skl/icl more cleanly.
On skl+ we have just two types of planes: those can do planar and
those that can't.
On icl we have three types of planes: hdr planes, sdr planes that
can do planar, and sdr planes that can't do planar. Thos
From: Ville Syrjälä
snb supports fp16 pixel formats on the sprite planes. Expose that
capability. Nothing special needs to be done, it just works.
v2: Rebase on top of icl fp16
Split snb+ sprite bits into a separate patch
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.
From: Ville Syrjälä
gen4+ supports fp16 pixel formats on the primary planes. Add the
relevant code.
On ivb fp16 scanout is slightly busted. The output from the plane will
have 1/4 the expected value. For the primary plane we would have to
use the pipe gamma or pipe csc to correct that which woul
From: Ville Syrjälä
skl+ supports fp16 pixel formats on all universal planes. Add the
necessary bits to expose that capability. The main different to
icl is that we can't scale fp16, so need to add the relevant
checks.
v2: Rebase on top of icl fp16
Split skl+ bits into a separate patch
Sign
From: Ville Syrjälä
One of the switch cases has the byte order vs. format bits
reversed to all the other cases. Appease the ocd and reorder
them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driver
From: Ville Syrjälä
ivb+ supports fp16 pixel formats on the sprite planes planes. Expose
that capability.
On ivb/hsw fp16 scanout is slightly busted. The output from the plane
will have 1/4 the expected value. For the sprite plane we can fix that
up with the plane gamma unit. This was fixed on b
From: Ville Syrjälä
We forgot to set .has_alpha=true for the A+CCS formats when the code
started to consult .has_alpha. This manifests as A+CCS being treated
as X+CCS which means no per-pixel alpha blending. Fix the format
list appropriately.
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst
Cc:
From: Ville Syrjälä
It's a bit silly to go through intel_dp.c to assign the
prepare_link_train vfunc for ddi platforms when we can just
assign it directly from intel_ddi.c.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 5 -
drivers/gpu/drm/i915/intel_ddi.h | 1 -
driv
From: Ville Syrjälä
intel_dp_link_down() is static and it's only called from the pre-ddi
DP functions, so having a WARN_ON(HAS_DDI) in there is quite pointless.
Remove it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/dri
From: Ville Syrjälä
Our PCH refclk init code currently assumes that the PCH SSC reference
can only be used for FDI. That is not true and it can be used by
SPLL/WRPLL for eDP SSC or clock bending as well. Before we go
reconfiguring it let's make sure no PLL is currently using the PCH
SSC reference
From: Ville Syrjälä
Give the PLL control register bits better names on HSW/BDW.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 37 ++-
drivers/gpu/drm/i915/intel_ddi.c | 16 ++--
drivers/gpu/drm/i915/intel_display.c | 8 +++---
d
From: Ville Syrjälä
On non-ULT HSW the "special" WRPLL reference clock select
actually means non-SSC. Take that into account when reading
out the WRPLL state.
Also the non-SSC reference may be either 24MHz or 135MHz,
which we can read out from FUSE_STRAP3. The BDW docs actually
say: "also indica
From: Ville Syrjälä
Only the non-SSC reference is truly supported for the LCPLL. Assert
that it is indeed selected.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display_power.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display_power.c
b/d
From: Ville Syrjälä
Get rid of the pointless LC_FREQ define.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 183f91abda19..fc9bc
From: Ville Syrjälä
Add a comma after the final entry to make diffs less obnoxious if
we have to add further entries past the last one.
Cc: Tvrtko Ursulin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_device_info.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
d
From: Ville Syrjälä
All AML parts are either KBL ULX or CFL ULX so there is no point
in keeping INTEL_SUBPLATFORM_AML around. As these are the only
CFL ULX parts (normal CFL didn't have Y SKUs) so we'll just
replace IS_AML_ULX with IS_CFL_ULX (it was already paired with
IS_KBL_ULX which accounts
From: Ville Syrjälä
When SAGV is forced to disabled/min/med/max in the BIOS pcode will
only hand us a single QGV point instead of the normal three. Fix
the code to deal with that instead declaring the bandwidth limit
to be 0 MB/s (and thus preventing any planes from being enabled).
Also shrink t
From: Ville Syrjälä
Respect the user's choice of depth/bpp for the fbdev framebuffer
and throw out the fb we inherited from the BIOS if it doesn't
match.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_fbdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers
From: Ville Syrjälä
If the user specifies zero width/height cmdline mode i915 will
blow up as the fbdev path will bypass the regular fb sanity
check that would otherwise have refused to create a framebuffer
with zero width/height.
The reason I thought to try this is so that I can force a specifi
From: Ville Syrjälä
drm_mode_create_from_cmdline_mode() can return NULL, so the caller
should check for that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fb_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/dr
From: Ville Syrjälä
i915 will now refuse to enable a C8 plane unless the gamma_lut
is already enabled (to avoid scanning out whatever garbage got
left in the hw LUT previously). So in order to make the fbdev
code work with C8 we need to program the gamma_lut already
during restore_fbdev_mode_atom
From: Ville Syrjälä
Give the PLL control register bits better names on HSW/BDW.
v2: Fix the copy paste fails in SPLL_REF defines (Maarten)
Cc: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 32 +--
drivers/gpu/drm/i915/intel
From: Ville Syrjälä
We're now calling intel_pipe_config_compare(..., true) uncoditionally
which means we're always going clobber the calculated M/N values with
the old values if the fuzzy M/N check passes. That causes problems
because the fuzzy check allows for a huge difference in the values.
I
From: Ville Syrjälä
Rename pipe_config_err() to pipe_config_mismatch(), and also print
whether we're doing the fastset check or the sw vs. hw state readout
check. Should make the logs a bit less confusing when they're not
filled with what looks like a real error.
Also rename the 'adjust' variabl
From: Ville Syrjälä
Now that intel_pipe_config_compare() no longer clobbers the passed
in state we can make both crtc states const. And while at we simplify
the calling convention, and clean up intel_compare_link_m_n() a bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.
From: Ville Syrjälä
We have full infoframe readout now so we can replace the
PIPE_CONF_CHECK_BOOL_INCOMPLETE(has_infoframe) with the normal
PIPE_CONF_CHECK_BOOL(has_infoframe).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
From: Ville Syrjälä
We're now calling intel_pipe_config_compare(..., true) uncoditionally
which means we're always going clobber the calculated M/N values with
the old values if the fuzzy M/N check passes. That causes problems
because the fuzzy check allows for a huge difference in the values.
I
From: Ville Syrjälä
Userspace may want stable identifiers for connectors. Let's try to
provide that via the PATH prop. I tried to make these somewhat abstract
by using just "port_type:index" type of approach, where we derive the
index from the physical instance of that hw block, so it should rema
From: Ville Syrjälä
Here's a possible apporoach for providing userspace with
some stable connector identifiers. Combine with the bus
name of the GPU and you should have some kind of real
physical path description. Unfortunately the ship has
sailed for MST connectors because userspace is already
p
From: Ville Syrjälä
The PATH blob is already being parsed by userspace for MST connectors
so the layout of the blob is now uabi. Let's document what it should
look like.
Also add a clear note saying non-MST connectors can have a PATH prop
too.
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Ilia Mir
From: Ville Syrjälä
Switch from the driver-wide vblank vfuncs to the per-crtc ones so that
we don't have so many platform specific vfuncs in the driver struct.
We still need to do something about the rest fo the irq vfuncs...
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel
From: Ville Syrjälä
I forgot to convert the tracepoints to the per-crtc
vfuncs in https://patchwork.freedesktop.org/series/62287/
Fortunately I had a patch ready for that in a branch (for gen2
originally) so I just refreshed that a bit. And since I had
to take another look at this stuff anyway I
From: Ville Syrjälä
Move the .get_vblank_timestamp() and .get_scanout_position()
initialization to happen at compile time. No point in delaying
it since we always assign the same functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
drivers/gpu/drm/i915/i915_irq
From: Ville Syrjälä
Stop using the irq vfuncs under drm_driver. That's not going to fly
in a mixed gen environment since the structure is shared between all
the devices.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 280 +++
From: Ville Syrjälä
Gen2 doesn't have a frame counter and apparently we no longer provide
a fake .get_vblank_counter() hook for it. That means all tracepoints
calling that hook will oops. Update the tracepoints to use
intel_crtc_get_vblank_counter() which will gracefully fall back to
using the so
From: Ville Syrjälä
Combined https://patchwork.freedesktop.org/series/62287/ and
https://patchwork.freedesktop.org/series/62317/ to make the
thing actually correct.
Ville Syrjälä (4):
drm/i915: Fix various tracepoints for gen2
drm/i915: Switch to per-crtc vblank vfuncs
drm/i915: Nuke drm_d
From: Ville Syrjälä
Gen2 doesn't have a frame counter and apparently we no longer provide
a fake .get_vblank_counter() hook for it. That means all tracepoints
calling that hook will oops. Update the tracepoints to use
intel_crtc_get_vblank_counter() which will gracefully fall back to
using the so
From: Ville Syrjälä
Switch from the driver-wide vblank vfuncs to the per-crtc ones so that
we don't have so many platform specific vfuncs in the driver struct.
We still need to do something about the rest fo the irq vfuncs...
v2: s/INTEL_GEN>=3/IS_GEN3/
Signed-off-by: Ville Syrjälä
---
drive
From: Ville Syrjälä
Move the .get_vblank_timestamp() and .get_scanout_position()
initialization to happen at compile time. No point in delaying
it since we always assign the same functions.
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
dr
From: Ville Syrjälä
Stop using the irq vfuncs under drm_driver. That's not going to fly
in a mixed gen environment since the structure is shared between all
the devices.
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i
From: Ville Syrjälä
The spec says:
"A value of 0 indicates that this buffer does not exist"
So we should not convert a hbuf_size of 0 into 1.
Also pull the relevant code into a helper to avoid making the
same mistake multiple times.
And while at it fix the debug prints to not say "hbuf_len" twi
From: Ville Syrjälä
Use named initializers to make it easier to associate the SDVO debug
prints with the SDVO command defines. Also switch to using ARRAY_SIZE()
instead of assuming that SDVO_CMD_STATUS_SCALING_NOT_SUPP is the last
command type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/
From: Ville Syrjälä
Drop the redundant "SDVO_CMD_" prefix from the command name
strings in sdvo_cmd_names[].
While at it throw away the unused struct name, and undef
SDVO_CMD_NAME_ENTRY() when we're done.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 219 +++
From: Ville Syrjälä
sdvo_cmd_names[] contains two entries for SET_INPUT_TIMINGS_PART1.
Remove one of them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
b/drivers/gpu/drm/
From: Ville Syrjälä
Add sdvo_cmd_name() and sdvo_cmd_status() helpers to avoid bothering
the callers with the implementation details of the storage for these
strings.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 40 +--
1 file changed, 30 ins
From: Ville Syrjälä
The strings we want to print to the on stack buffers should
be no more than
8 * 3 + strlen("(GET_SCALED_HDTV_RESOLUTION_SUPPORT)") + 1 = 61
bytes. So let's shrink the buffers down to 64 bytes.
Also switch the BUG_ON()s to WARN_ON()s if I made a mistake in
my arithmentic.
Sig
From: Ville Syrjälä
Stop using the irq vfuncs under drm_driver. That's not going to fly
in a mixed gen environment since the structure is shared between all
the devices.
v2: Allow intel_irq_uninstall() to be called twice due to
intel_modeset_cleanup() calling it as well. Toss in a
FIXME
From: Ville Syrjälä
Ilia pointed out some oddball crap in the i915 aspect ratio handling.
While looking at that I noticed a bunch of fail in the core as well.
This series aims to fix it all.
Cc: Ilia Mirkin
Ville Syrjälä (5):
drm: Do not use bitwise OR to set picure_aspect_ratio
drm: Do no
From: Ville Syrjälä
Don't let userspace feed us any old garbage in the mode aspect ratio
flags.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm
From: Ville Syrjälä
enum hdmi_picture_aspect is not a bitmask, so don't use bitwise OR
to populate it.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers
From: Ville Syrjälä
HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d
so no need to initialize conn_state->picture_aspect_ratio with it.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 1 -
drivers/gpu/drm/i915/display/intel_s
From: Ville Syrjälä
HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that
selected we should keep whatever aspect ratio the mode already has.
Also no point in checking for connector->is_hdmi in the SDVO code
since we only attach the property to HDMI connectors.
Cc: Ilia Mirkin
S
From: Ville Syrjälä
WARN if the incoming drm_display_mode has an illegal aspect ratio
when converting it to a user mode. This should never happen unless
the driver made a mistake and put an invalid value into the aspect
ratio.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/d
From: Ville Syrjälä
Currently the logs show nothing about the mode's aspect ratio.
Include that information in the normal mode dump.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c| 3 ++-
include/drm/drm_modes.h | 4 ++--
include/linux/hdmi.h| 3 +++
3 files cha
From: Ville Syrjälä
Decode the mode flags when printing the modeline so that I
no longer have to decode the hex number myself.
To do this neatly I made the caller provide a temporary
on stack buffer where we can produce the results. I choce 64
bytes as a reasonable size for this. The worst case
901 - 1000 of 9224 matches
Mail list logo
