| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Simplify the calling convention of the skl+ watermark functions
by not passing around dev_priv needlessly. The callees have
what they need to dig it out anyway.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
|
|
Make a cleaner split between the skl+ and icl+ ways of computing
watermarks. This way skl_build_pipe_wm() doesn't have to know any
of the gritty details of icl+ master/slave planes.
We can also simplify a bunch of the lower level code by pulling
the plane visibility checks a bit higher up.
v2: WARN_ON(!visible) for the icl+ master plane case (Matt)
Cc: Matt Roper <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We have to pass both level 0 watermark struct and the transition
watermark struct to skl_compute_transition_wm(). Make life less
confusing by just passing the entire plane watermark struct that
contains both aforementioned structures.
Cc: Matt Roper <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
|
|
We memset(0) the entire watermark struct the start, so there's no
need to clear things later on.
v2: Rebase due to some stale w/a removal
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
|
|
If the level 0 latency is 0 we can't do anything. Return an error
rather than success.
While this can't happen due to WaWmMemoryReadLatency, it can
happen if the user clears out the level 0 latency via debugfs.
v2: Clarify how how we can end here with zero level 0 latency (Matt)
Cc: Matt Roper <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
|
|
We're going to need access to the new crtc state in ->disable_plane()
for SKL+ wm/ddb programming and pre-skl pipe gamma/csc control. Pass
the crtc state down.
We'll also try to make intel_crtc_disable_planes() do the right
thing as much as it's possible. The fact that we don't have a
separate crtc state for the disabled state when we're going to
re-enable the crtc later means we might end up poking at a few
extra planes in there. But that's harmless. I suppose one might
argue that we wouldn't have to care about proper ddb/wm/csc/gamma
if the pipe is going to permanently disable anyway, but the state
checker probably cares so we should try our best to make sure
everything is programmed correctly even in that case.
v2: Fix the commit message a bit (Matt)
Cc: Matt Roper <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
|
|
Keep track which planes need updating during the commit. For now
we set the bit for any plane that was or will be visible (including
icl+ nv12 slave planes). In the future I'll have need to update
invisible planes as well, for skl plane ddbs and for pre-skl pipe
gamma/csc control (which lives in the primary plane control register).
v2: Pimp the commit message to mention icl+ nv12 slave planes (Matt)
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The plane color correction registers are single buffered. So
ideally we would write them at the start of vblank just after the
double buffered plane registers have been latched. Since we have
no convenient way to do that for now let's at least move the
single buffered register writes to happen after the double
buffered registers have been written.
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
|
|
Some observations about the plane registers:
- the control register will self-arm if the plane is not already
enabled, thus we want to write it as close to (or ideally after)
the surface register
- tileoff/linoff/offset/aux_offset are self-arming as well so we want
them close to the surface register as well
- color keying registers we maybe self arming before SKL. Not 100%
sure but we can try to keep them near to the surface register
as well
- chv pipe b csc register are double buffered but self arming so
moving them down a bit
- the rest should be mostly armed by the surface register so we can
safely write them first, and to just for some consistency let's try
to follow keep them in order based on the register offset
None of this will have any effect of course unless the vblank evasion
fails (which it still does sometimes). Another potential future benefit
might be pulling the non-self armings registers outside the vblank
evasion since they won't latch until the arming register has been
written. This would make the critical section a bit lighter and thus
less likely to exceed the deadline.
v2: Rebase due to input CSC
v3: Swap LINOFF/TILEOFF and KEYMSK/KEYMAX to actually follow
the last rule above (Matt)
Add a bit more rationale to the commit message (Matt)
Cc: Matt Roper <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
|
|
of_find_node_by_path() acquires a reference to the node returned by it
and that reference needs to be dropped by its caller.
Signed-off-by: Yangtao Li <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Mark A0 as the one and only pre-production variant of Kabylake and
remove its couple of workarounds, consigning them to the annals of
history.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Acked-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
DSC specification defines linebuf_depth which contains the
line buffer bit depth used to generate the bitstream.
These values are defined as per Table 4.1 in DSC 1.2 spec
v2 (From Manasi):
* Rename as MAX_LINEBUF_DEPTH for DSC 1.1 and DSC 1.2
Cc: [email protected]
Cc: Jani Nikula <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Signed-off-by: Gaurav K Singh <[email protected]>
Signed-off-by: Manasi Navare <[email protected]>
Acked-by: Sean Paul <[email protected]> (For merging through
drm-intel)
Reviewed-by: Anusha Srivatsa <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
According to Display Stream compression spec 1.2, the picture
parameter set metadata is sent from source to sink device
using the DP Secondary data packet. An infoframe is formed
for the PPS SDP header and PPS SDP payload bytes.
This patch adds helpers to fill the PPS SDP header
and PPS SDP payload according to the DSC 1.2 specification.
v7:
* Use BUILD_BUG_ON() to protect changing struct size (Ville)
* Remove typecaseting (Ville)
* Include byteorder.h in drm_dsc.c (Ville)
* Correct kernel doc spacing (Anusha)
v6:
* Use proper sequence points for breaking down the
assignments (Chris Wilson)
* Use SPDX identifier
v5:
Do not use bitfields for DRM structs (Jani N)
v4:
* Use DSC constants for params that dont change across
configurations
v3:
* Add reference to added kernel-docs in
Documentation/gpu/drm-kms-helpers.rst (Daniel Vetter)
v2:
* Add EXPORT_SYMBOL for the drm functions (Manasi)
Cc: [email protected]
Cc: Jani Nikula <[email protected]>
Cc: Ville Syrjala <[email protected]>
Cc: Anusha Srivatsa <[email protected]>
Cc: Harry Wentland <[email protected]>
Signed-off-by: Manasi Navare <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Reviewed-by: Anusha Srivatsa <[email protected]>
Acked-by: Sean Paul <[email protected]> (For merging through
drm-intel)
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
DSC has some Rate Control values that remain constant
across all configurations. These are as per the DSC
standard.
v3:
* Define them in drm_dsc.h as they are
DSC constants (Manasi)
v2:
* Add DP_DSC_ prefix (Jani Nikula)
Cc: [email protected]
Cc: Manasi Navare <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Ville Syrjala <[email protected]>
Cc: Gaurav K Singh <[email protected]>
Cc: Harry Wentland <[email protected]>
Signed-off-by: Srivatsa, Anusha <[email protected]>
Signed-off-by: Manasi Navare <[email protected]>
Reviewed-by: Manasi Navare <[email protected]>
Acked-by: Sean Paul <[email protected]> (For merging through
drm-intel)
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This defines all the DSC parameters as per the VESA DSC spec
that will be required for DSC encoder/decoder
v6: (From Manasi)
* Add a bit mask for RANGE_BPG_OFFSET for 6 bits(Manasi)
v5 (From Manasi)
* Add the RC constants as per the spec
v4 (From Manasi)
* Add the DSC_MUX_WORD_SIZE constants (Manasi)
v3 (From Manasi)
* Remove the duplicate define (Suggested By:Harry Wentland)
v2: Define this struct in DRM (From Manasi)
* Changed the data types to u8/u16 instead of unsigned longs (Manasi)
* Remove driver specific fields (Manasi)
* Move this struct definition to DRM (Manasi)
* Define DSC 1.2 parameters (Manasi)
* Use DSC_NUM_BUF_RANGES (Manasi)
* Call it drm_dsc_config (Manasi)
Cc: [email protected]
Cc: Jani Nikula <[email protected]>
Cc: Ville Syrjala <[email protected]>
Cc: Anusha Srivatsa <[email protected]>
Cc: Harry Wentland <[email protected]>
Signed-off-by: Manasi Navare <[email protected]>
Signed-off-by: Gaurav K Singh <[email protected]>
Co-developed-by: Gaurav K Singh <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Acked-by: Sean Paul <[email protected]> (For merging through
drm-intel)
Reviewed-by: Anusha Srivatsa <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.
v4:
* Remove redundant blankline in doc (Ville)
* use drm_dsc namespace for all structs (Ville)
* Use packed struct (Ville)
v3:
* Add the SPDX shorthand (Chris Wilson)
v2:
* Do not use bitfields in the struct (Jani Nikula)
Cc: Gaurav K Singh <[email protected]>
Cc: [email protected]
Cc: Jani Nikula <[email protected]>
Cc: Ville Syrjala <[email protected]>
Cc: Anusha Srivatsa <[email protected]>
Cc: Harry Wentland <[email protected]>
Signed-off-by: Manasi Navare <[email protected]>
Acked-by: Sean Paul <[email protected]> (For merging through
drm-intel)
Reviewed-by: Harry Wentland <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
DSC DPCD color depth register advertises its color depth capabilities
by setting each of the bits that corresponding to a specific color
depth. This patch defines those specific color depths and adds
a helper to return an array of color depth capabilities.
v2:
* Simplify the logic (Ville)
Signed-off-by: Manasi Navare <[email protected]>
Cc: Ville Syrjala <[email protected]>
Acked-by: Sean Paul <[email protected]> (For merging through
drm-intel)
Reviewed-by: Ville Syrjala <[email protected]>
Reviewed-by: Anusha Srivatsa <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This is the same as the default drm_gem_dumb_map_offset()
implementation, except that this one missed the ban on userspace
mapping an imported dmabuf (which seems like intended common behavior
for drivers).
Signed-off-by: Eric Anholt <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Acked-by: Daniel Vetter <[email protected]>
|
|
The extra to_v3d_bo() calls came from copying this from the vc4
driver, which stored the cma gem object in the structs.
v2: Fix an unused var warning
Signed-off-by: Eric Anholt <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Boris Brezillon <[email protected]> (v1)
|
|
I merged bin and render's paths in a late refactoring.
Signed-off-by: Eric Anholt <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Boris Brezillon <[email protected]>
|
|
Signed-off-by: Eric Anholt <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Boris Brezillon <[email protected]>
|
|
This change is an attempt to handle the alternate clock for the CEA mode.
60Hz vs. 59.94Hz, 30Hz vs 29.97Hz or 24Hz vs 23.97Hz on the Amlogic Meson SoC
DRM Driver pixel clock generation.
The actual clock generation will be moved to the Common Clock framework once
all the video clock are handled by the Amlogic Meson SoC clock driver,
then these alternate timings will be handled in the same time in a cleaner
fashion.
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Maxime Jourdan <[email protected]>
[narmstrong: fix maybe-uninitialized warnings after applying]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add the timings for the HDMI 1.4 4K modes support :
- 3840x2160@30
- 3840x2160@25
- 3840x2160@24
Since the 297000Hz pixel clock is already managed and the modes are
compatible with the HDMI 1.4 current HDMI PHY+Controller support, only
the missing timings values needs to be added.
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Maxime Jourdan <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Noticed while reviewing a patch from Eric. Also add a todo for the
dumb_map_offset callbacks (it should be simple to do, but piles of
work). Plus fix up vbox, because vbox.
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Sean Paul <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Nicholas Mc Guire <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Fabio Rafael da Rosa <[email protected]>
Reviewed-by: Maxime Ripard <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
If the engine's seqno is already at our target seqno (most likely it
hasn't been used since the last reset), we can skip serialising the
engine and leave it as is.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
To prepare the introduction of tiled mode support, pass the framebuffer
format modifier to the helpers dealing with format support.
Since only linear mode is supported for now, add corresponding checks in
each helper.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This introduces support for the BGRX8888 output format for the frontend,
with its associated output format value definition.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Our hardware requires the pitch to be an even number when using YUV
formats with the frontend. Implement a driver-specific callback for GEM
dumb allocation that sets the pitch accordingly.
Since only the bpp is passed (and not the format), we cannot really
distinguish if this alignment is really required. Since it doesn't hurt
to align the pitch anyway, always do it.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The frontend comes with two "channels", that can be configured
independently. When used in YUV mode, the first channel (CH0) represents
the luminance component while the second channel (CH1) represents the
chrominance. In RGB mode, both have to be configured the same way.
Use variables (with the YUV terminology) for each channel's
dimensions, calculating the chroma dimensions from the luma dimensions
and the sub-sampling factors from the format description.
Since the configured size only has pixel precision, the fractional
fixed-point part of the source size is dropped for both components to
ensure that the scaling factors are accurate.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The values in the BT601 YUV to RGB colorspace translation are not
simply coded as multiples, but rather as fixed-point signed fractional
values on a given number of bits. Add an explanation about that.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This introduces support for the BGRX8888 input format for the frontend,
with its associated pixel sequence value definition. Other fields are
already configured correctly as they no longer depend on the format's
fourcc directly.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Use the number of planes associated with the DRM format to determine the
input mode configuration instead of the format iteself. This way, the
helper can be used for all packed formats without future changes.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This introduces proper definitions for the input and output format
configuration registers instead of a macro and raw values in the code,
with the intent to increase code readability and reduce indirections.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This introduces new helpers for retrieving the input data mode and pixel
sequence register field values based on the DRM format instead of
hardcoding these. This makes it easier to add support for more formats.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In order to support YUV to RGB conversion with the frontend (which is
generally used for connecting with the backend), the CSC block must not
be bypassed.
As a result, the bit to enable CSC bypass is moved from the runtime
resume routine to the format update routine, so that it can disabled
when introducing support for YUV formats later.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Since more formats can be supported by the frontend, rename the
variable listing the layer formats to avoid suggesting that the backend
itself supports all the listed formats.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Our hardware has a limited number of YUV planes (usually 1) that can be
supported using the backend only. However, YUV planes can also be
supported by the frontend and must then not be counted when checking for
that limitation.
Only count the YUV plane when the frontend is not used.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Before this patch, it is assumed that a plane is supported either
through the frontend or through the backend alone. However, the DRM
interface does not allow finely reporting our hardware capabilities
and there are cases where neither are support.
In particular, some plane formats are supported by the backend and not
the frontend, so they can only be supported without scaling.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Checking that scaling is in use is not sufficient as a condition to
decide to use the frontend.
Since not all layer formats are supported by the frontend, we need to
check for that support first. Then, the frontend must only be enabled
if the backend doesn't support the format or that scaling is required.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In order to check whether the frontend supports a specific format, an
explicit list and a related helper are introduced.
Just like in the backend, the prototype of the helper is added to the
frontend header so that it can be used later on. The helper is also
exported because it will be used outside of the frontend module.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In order to check whether the backend supports a specific format, an
explicit list and a related helper are introduced.
The prototype of this helper is added to the header so that it can be
called from sun4i_layer later (when introducing tiled mode support).
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The backend allows integer-only scaling but can handle alpha components,
unlike the frontend. It could be useful to add support for this
eventually, so add a short TODO comment describing the situation.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The frontend documentation (for the A33) mentions that ARGB is supported
as output, but with the alpha component always set to 0xff. In practice,
this means that the alpha component cannot be preserved when going
through the frontend. Since the information is lost, ARGB is not
properly supported.
As a result, expose the matching format supported by the frontend (both
for input and output) as XRGB instead of ARGB.
Since ARGB was the selected format for connecting the frontend to the
backend, change it to XRGB to reflect this as well.
The A31 and A80 SoCs apparently have a bit to enable proper alpha,
but this is not supported at this point (see the comment already in the
code).
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This adds a dedicated function for cleaning the video and YUV source
channel layer enable bits. This function is called first on layer atomic
update to make sure that there are no leftover bits from previous
plane configuration that were not cleaned until now.
It fixes issues when alternating between video and YUV planes, where
both bits would be set eventually, leading to broken plane display.
Signed-off-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
There is a spelling mistake in the module description text and
a comment too, fix them. Also line break overly long comment.
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Remove dce/dce_mem_input.h which is included more than once
Signed-off-by: Brajeswar Ghosh <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Remove gca/gfx_8_0_enum.h which is included more than once
Signed-off-by: Brajeswar Ghosh <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Remove drm/drm_fb_helper.h which is included more than once
Signed-off-by: Brajeswar Ghosh <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
ACPI ATIF has a function called query
backlight transfer characteristics. Among the
information returned by this function is
the minimum and maximum input signals for the
backlight
Call that function on ACPI init. When DM
backlight device is updated, copy over the
backlight caps into DM, but only once. Use
the backlight caps in the backlight-to-dc
calculation
Signed-off-by: David Francis <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
The ACPI interface in AMD was a few years out of date
and contained some unused and deprecated functions
Remove functions: Select Active Displays, Get Lid State,
Get TV Standard, Set TV Standard, Get Panel Expansion Mode,
Set Panel Expansion Mode, Get Graphics Device Types
Add functions: Query Backlight Transfer Characteristics,
Ready To Undock Notification
Changed functions: Get System Parameters,
Get System BIOS Requests
All changes are right from the standard
ATI ACPI Control Methods V0.44
Signed-off-by: David Francis <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|