| Age | Commit message (Collapse) | Author |
|---|
|
DRM_FORMAT_MOD_LINEAR is the more sensible name for
DRM_FORMAT_MOD_NONE. Use the better name.
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
As KMS tests on IGT are officially supported on multiple SoCs
and there is an active development on it. So, KMS tests are
meant to be generic and if we need to test few things specific
to Intel, we can use igt_require_intel(). But if the whole test
is Intel specific, then the best place for the test would be
tests/i915.
This patch will
* Move all Intel specific kms tests to tests/i915 directory.
* Update the tests those are generic but still open the driver
as 'drm_open_driver_master(DRIVER_INTEL);'.
V2:
* Few more tests
V3:
* Remove cleanups (will submit separate patch later)
* Move few more tests to i915 dir (Karthik)
V4:
* Move kms_big_joiner.c to i915 dir (Karthik)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mark Yacoub <markyacoub@chromium.org>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Vidya Srinivas <vidya.srinivas@intel.com>
Cc: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
Reviewed-by: Mark Yacoub <markyacoub@chromium.org>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
|
Use the definition from kernel headers.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
Display code should check the display version of the platform rather
than the graphics version; on some platforms these versions won't be the
same.
v2:
- Continue to use intel_gen() in draw_rect_blt() since it's checking
the version of the blitter engine (graphics) rather than the display
version. (Jose)
- Rename some gen -> display_ver in kms_universal_plane too. (Jose)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
|
We've seen cases in which /proc/asound doesn't exist (e.g. with the new SOF
framework). We've also seen cases in which no soundcard is exposed by ALSA (see
bugzilla link). Last, some audio drivers din't support ELDs (non-Intel
drivers). In all of these cases, skipping the tests depending on ELD support
makes more sense and makes it clearer what happens.
v2: also check that the driver supports ELDs entries in procfs
Signed-off-by: Simon Ser <simon.ser@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102370
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Comments say that a connector can only be forced if it's disconnected. This was
a wrong assumption which has been fixed, but the comments went out of sync.
Fixes: dc3a0934a177 ("tests/kms_hdmi_inject: Accept any HDMI connector")
Signed-off-by: Simon Ser <simon.ser@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
This has several advantages:
* No more need to convert back and forth between these two (everybody should
use struct edid, the exception being lib/tests/igt_edid which performs sanity
checks)
* Makes it clearer that users can call edid_get_size on a returned EDID blob
* Improves type safety (it's more obvious is a random blob is used as an EDID)
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Connector forcing works just fine even if it already has
something physically connected. So accept any HDMI connector
for the test.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Simon Ser <simon.ser@intel.com>
|
|
On pre-HSW we have separate encoders for the DP and HDMI ports,
but both can't be enabled at the same time. The test fails to
account for that and can thus fail when the kernel rejects
the modeset. We can avoid that by turning off all the ports
beforehand.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105595
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Simon Ser <simon.ser@intel.com>
|
|
This test is quite simple which makes it perfect for the first real
world example of igt_describe usage.
v2: keep the original comment (Simon)
Cc: Simon Ser <simon.ser@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Simon Ser <simon.ser@intel.com>
|
|
The new EDID has been byte-by-byte checked to be exactly the same as before.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Given an EDID, computing the size is trivial. Instead of having one size
constant per EDID and hope the callers use the right one (ie. *not* EDID_LENGTH
when there's an extension), we can make functions that take EDIDs compute the
size if they need it.
We have tests in lib/tests/igt_edid.c which assert the number of extensions
present in the EDID anyway.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Prior to this commit, we were using the Chamelium's default EDID for DP audio.
This relies on the fact that this EDID supports audio and has correct audio
paremeters for our testing.
Generating our own EDID is less error-prone and will allow us to test different
audio parameters.
v2:
- Replace {HDMI,DP}_AUDIO_EDID_LENGTH with AUDIO_EDID_LENGTH (Arek)
- Don't hardcode EDIDs array length (Arek)
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
There are two reasons why I want to introduce this library:
- I want to use it from the Chamelium tests for DisplayPort
- I want to expand it to also check that audio parameters parsed by ALSA are
correct (formats, sampling rates, sample sizes and so on)
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This new function uses igt_edid to generate an EDID suitable for testing HDMI
audio. It's imported from kms_chamelium with minor edits, it's used there and
in kms_hdmi_inject. A (unexported for now) generate_hdmi_audio_edid function
enables generation of EDIDs with arbitrary SAD and speaker blocks.
This obsoletes kmstest_edid_add_audio.
The sanity check for the HDMI audio EDID has been moved from
lib/tests/igt_hdmi_inject.c to lib/tests/igt_edid.c.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
It's not immediately obvious what injection and ELDs are, and what is tested.
This commit adds a few comments to help readers understand this test. In case
the test breaks, this could help.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
If KMS is not supported on the device, drmModeGetResources() will return
NULL, often this is an indication that we should not attempt to run the
test. Although it would be preferred to use something like
igt_require_display() as the canonical check and assert that
drmModeGetResources() did not hit an error, it is not always practical
as the tests do not utilize the common igt_display abstraction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Original author: Marius Vlad. Includes fixes below.
v5: Convert unit tests to lib selftest.
v4: Add a unit test to make sure synthetic EDID blocks generated by
IGT is valid (suggested by Petri).
v3: Make audio injection work.
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
|
