The old debugfs fields was not following a naming partern and it was
a bit confusing.
So it went from:
~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
Sink_Support: yes
PSR mode: PSR1
Enabled: yes
Busy frontbuffer bits: 0x000
Main link in standby mode: no
HW Enabled & Active bit: yes
Source PSR status: 0x24050006 [SRDONACK]
To:
~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
Sink support: yes [0x03]
PSR mode: PSR1 enabled
Source PSR ctl: enabled [0x81f00e26]
Source PSR status: IDLE [0x04010006]
Busy frontbuffer bits: 0x00000000
The 'Main link in standby mode' was removed as it is not useful but
if needed by someone the information is still in the register value
of 'Source PSR ctl' inside of the brackets, PSR mode and Enabled was
squashed into PSR mode, some renames and reorders and we have this
cleaner version. This will also make easy to parse debugfs for IGT
tests.
v2: Printing sink PSR version with only 2 hex digits as it is a byte
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190117205548.28378-2-jose.souza@intel.com
Move mipi_dsi_dcs_set_display_off() from innolux_panel_disable()
to innolux_panel_unprepare(), so they are consistent with
innolux_panel_enable() and innolux_panel_prepare().
This also fixes some mode check and irq timeout issue in MTK dsi code.
Since some dsi code (e.g. mtk_dsi) have following call trace:
1. drm_panel_disable(), which calls innolux_panel_disable()
2. switch to cmd mode
3. drm_panel_unprepare(), which calls innolux_panel_unprepare()
However, mtk_dsi needs to be in cmd mode to be able to send commands
(e.g. mipi_dsi_dcs_set_display_off() and mipi_dsi_dcs_enter_sleep_mode()),
so we need these functions to be called after the switch to cmd mode happens,
i.e. in innolux_panel_unprepare.
Signed-off-by: Hsin-Yi, Wang <hsinyi@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190109065922.231753-1-hsinyi@chromium.org
Before adding yet another copy of struct live_test and its handler,
refactor the existing code into a common framework for live selftests.
For many live selftests, we want to know if the GPU hung or otherwise
misbehaved during the execution of the test (beyond any infraction in
the behaviour under test), live_test provides this by comparing the
GPU state before and after, alerting if it unexpectedly changed (e.g.
the reset counter changed). It also ensures that the GPU is idle before
and after the test, so that residual code running on the GPU is flushed
before testing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190121222117.23305-5-chris@chris-wilson.co.uk
Some tests (e.g. igt_vma_pin1) presume that we have a completely clean
GGTT so that it can probe boundaries without fear that something is
already allocated there. However, the mock device is starting to get
complicated and following similar rules to the live device, i.e. we
can't guarantee that i915->ggtt remains clean, so create a temporary
address_space equivalent to the mock ggtt for the purpose.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190121222117.23305-7-chris@chris-wilson.co.uk
Although TMDS clock is required for HDMI to properly function,
nobody called clk_prepare_enable(). This fixes reference counting
issues and makes sure clock is running when it needs to be running.
Due to TDMS clock being parent clock for DDC clock, TDMS clock
was turned on/off for each EDID probe, causing spurious failures
for certain HDMI/DVI screens.
Fixes: 9c5681011a ("drm/sun4i: Add HDMI support")
Signed-off-by: Priit Laes <priit.laes@paf.com>
[Maxime: Moved the TMDS clock enable earlier]
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190122073232.7240-1-plaes@plaes.org
There are 3 problems with the dsi code's pipe_bpp handling for 6 bpc
pixel-formats which this commit addresses:
1) It assumes that the pipe_bpp is the same as the bpp going over the dsi
lanes. This assumption is not valid for MIPI_DSI_FMT_RGB666, where pipe_bpp
should be 18 so that we do proper dithering but we actually send 24 bpp
over the dsi lanes (MIPI_DSI_FMT_RGB666_PACKED sends 18 bpp).
This assumption is enforced by an assert in *_dsi_get_pclk(). This assert
triggers on the initial hw-state readback on BYT/CHT devices which use
MIPI_DSI_FMT_RGB666, such as the Prowise PT301 tablet. PIPECONF is set to
6BPC / 18 bpp by the GOP, while mipi_dsi_pixel_format_to_bpp() returns 24.
This commits switches the calculations in *_dsi_get_pclk() to use the bpp
from mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format) which
returns the bpp going over the mipi lanes and drops the assert.
2) On BXT bxt_dsi_get_pipe_config() wrongly overrides the pipe_bpp which
i9xx_get_pipe_config() reads from PIPECONF with the return value from
mipi_dsi_pixel_format_to_bpp(). This avoids the assert from 1. but is wrong
since the pipe is actually running at the value configured in PIPECONF.
This commit drops the override of pipe_bpp from bxt_dsi_get_pipe_config().
3) The dsi encoder's compute_config() never assigns a value to pipe_bpp,
unlike most other encoders. Falling back on compute_baseline_pipe_bpp()
which always picks 24. 24 is only correct for MIPI_DSI_FMT_RGB88 for the
others we should use 18 bpp so that we correctly do 6bpc color dithering.
This commit adds code to intel_dsi_compute_config() to properly set
pipe_bpp based on intel_dsi->pixel_format.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181201113148.23184-1-hdegoede@redhat.com
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/stm/ltdc.c: In function 'ltdc_plane_atomic_check':
drivers/gpu/drm/stm/ltdc.c:694:13: warning:
variable 'src_y' set but not used [-Wunused-but-set-variable]
u32 src_x, src_y, src_w, src_h;
^
^
drivers/gpu/drm/stm/ltdc.c:694:6: warning:
variable 'src_x' set but not used [-Wunused-but-set-variable]
u32 src_x, src_y, src_w, src_h;
^
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1538131180-34108-1-git-send-email-yuehaibing@huawei.com
Planar YUV formats come with 3 distinct planes, which requires
configuring the frontend line stride and address registers for the
third plane.
Our hardware only supports the YUV planes order and in order to support
formats with a YVU plane order, a helper is introduced to indicate
whether to invert the address of the two chroma planes.
Missing definitions for YUV411 and YUV444 input format configuration are
also introduced as support is added for these formats. For the input
sequence part, no configuration is required for planar YUV formats so
zero is returned in that case.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190118145133.21281-11-paul.kocialkowski@bootlin.com
Pull ACPI fixes from Rafael Wysocki:
"These fix an ACPI initialization ordering issue introduced in the 4.17
time frame and causing functional problems to appear on multiple
systems and fix some fallout of the recent change to enable building
kernels with ACPI support and without PCI.
Specifics:
- Restore the ACPI initialization ordering changed implicitly by the
module-level AML handling rework during the 4.17 development cycle
that caused the EC address space handler based on information from
ECDT to be set up before loading AML definition blocks, making it
effectively not accessible by AML on some systems that don't work
as expected any more (Rafael Wysocki).
- Add direct dependencies on PCI to Kconfig in multiple places for
code that depends on both ACPI and PCI, but the PCI dependency was
implicitly satisfied by the ACPI dependency before, to prevent
invalid configurations from being created, for example by
randconfig (Sinan Kaya)"
* tag 'acpi-5.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: EC: Look for ECDT EC after calling acpi_load_tables()
drivers: thermal: int340x_thermal: Make PCI dependency explicit
x86/intel/lpss: Make PCI dependency explicit
platform/x86: apple-gmux: Make PCI dependency explicit
platform/x86: intel_pmc: Make PCI dependency explicit
platform/x86: intel_ips: make PCI dependency explicit
vga-switcheroo: make PCI dependency explicit
ata: pata_acpi: Make PCI dependency explicit
ACPI / LPSS: Make PCI dependency explicit
