Many drivers are populating encoder->possible_clones wrong. Let's
persuade them to get it right by adding some loud WARNs.
We'll cross check the bits between any two encoders. So either
both encoders can clone with the other, or neither can.
We'll also complain about effectively empty possible_clones, and
possible_clones containing bits for encoders that don't exist.
v2: encoder->possible_clones now includes the encoder itelf
v3: Move to drm_mode_config_validate() (Daniel)
Document that you get a WARN when this is wrong (Daniel)
Extract full_encoder_mask()
v4: !! instead of ! (Daniel)
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211162208.16224-6-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use the same approach for gma500.
Also the LVDS+LVDS and DSI+DSI cases probably don't really exist as
there is one of each at most.
This does mean we'll now leave possible_clones at 0 for these encoder
types whereas previosuly we included the encoder itself in the bitmask.
But that's fine as the core now treaks 0 as a special case and adds
the encoder itself into the final bitmask reported to userspace.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211162208.16224-3-ville.syrjala@linux.intel.com
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into drm_encoder_init() because drivers
will have to fill up possible_clones after adding all the relevant
encoders. Otherwise they wouldn't know the proper encoder indexes to
use. So we'll just do it just before registering the device.
v2: Don't set the bit if possible_clones!=0 so that the
validation (coming soon) will WARN (Thomas)
Fix up the docs to allow possible_clones==0 (Daniel)
.late_register() is too late, introduce drm_mode_config_validate()
which gets called _before_ we register the char device (Daniel)
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211162208.16224-2-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently the DispID tile block gets parsed in drm_get_edid(), which
is an odd place for it considering we parse nothing else there. Also
this doesn't work for override EDIDs since
drm_connector_update_edid_property() refuses to do its job twice
in such cases. Thus we never update the tile property with results
of the DispID tile block parsing during drm_get_edid().
To fix this let's just move the tile block parsing to happen during
drm_connector_update_edid_property(), which is where we parse a bunch
of other stuff as well (and where we update both the EDID and tile
properties).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-10-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Currently the code assumes that the entire EDID extesion block
can be taken up by the DispID blocks. That is not true. There
is at least always the DispID checksum, and potentially fill
bytes if the extension block uses the interior fill scheme
to pad out to fill EDID block size.
So let's not parse the checksum or the fill bytes as DispID
blocks by having drm_find_displayid_extension() return the
actual length of the DispID data to the caller.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-7-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The fact that the DispID starts at byte offset 1 is due to
the DispID coming from and EDID extension block (the first byte
being the extesion block tag). Instead of hadrdocoding that idx==1
assumptions all over let's just have drm_find_displayid_extension()
return it since it actually knows what it's talking about.
If at some point someone comes across a DispID which is not embedded
inside an EDID the function that returns the new type of DispID
can return it's own byte offset without having to updated all the
code.
TODO: should probably just get rid of that idx thing altogether
and just return the thing we want directly.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200313162054.16009-4-ville.syrjala@linux.intel.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Allow allocating a specialized version of struct drm_framebuffer
by moving the actual fb allocation out of drm_gem_fb_create_with_funcs();
the respective functions names are adjusted to reflect that fact.
Please note, though, that standard size checks are performed on buffers,
so the drm_gem_fb_init_with_funcs() is useful for cases where those
standard size checks are appropriate or at least don't conflict the
checks to be performed in the specialized case.
Thanks to this change the drivers can call drm_gem_fb_init_with_funcs()
having allocated their special version of struct drm_framebuffer, exactly
the way the new version of drm_gem_fb_create_with_funcs() does.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: James Qian Wang <james.qian.wang@arm.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200311145541.29186-2-andrzej.p@collabora.com
Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get initialized). Clang's automatic stack variable initialization
(via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
doesn't initialize such variables[1]. Note that these warnings (or silent
skipping) happen before the dead-store elimination optimization phase,
so even when the automatic initializations are later elided in favor of
direct initializations, the warnings remain.
To avoid these problems, lift such variables up into the next code
block.
drivers/gpu/drm/drm_edid.c: In function ‘drm_edid_to_eld’:
drivers/gpu/drm/drm_edid.c:4395:9: warning: statement will never be
executed [-Wswitch-unreachable]
4395 | int sad_count;
| ^~~~~~~~~
[1] https://bugs.llvm.org/show_bug.cgi?id=44916
v2: move into function block instead being switch-local (Ville Syrjälä)
Signed-off-by: Kees Cook <keescook@chromium.org>
[danvet: keep the changelog]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/202003060930.DDCCB6659@keescook
This fixes the following sparse warning:
drivers/gpu/drm/tiny/ili9486.c:61:16: sparse: sparse: incorrect type in assignment (different base types)
drivers/gpu/drm/tiny/ili9486.c:61:16: sparse: expected unsigned short [usertype]
drivers/gpu/drm/tiny/ili9486.c:61:16: sparse: got restricted __be16 [usertype]
drivers/gpu/drm/tiny/ili9486.c:71:32: sparse: sparse: incorrect type in assignment (different base types)
drivers/gpu/drm/tiny/ili9486.c:71:32: sparse: expected unsigned short [usertype]
drivers/gpu/drm/tiny/ili9486.c:71:32: sparse: got restricted __be16 [usertype]
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1583684084-4694-1-git-send-email-kamlesh.gurudasani@gmail.com
amd-drm-next-5.7-2020-03-10:
amdgpu:
- SR-IOV fixes
- Fix up fallout from drm load/unload callback removal
- Navi, renoir power management watermark fixes
- Refactor smu parameter handling
- Display FEC fixes
- Display DCC fixes
- HDCP fixes
- Add support for USB-C PD firmware updates
- Pollock detection fix
- Rework compute ring priority handling
- RAS fixes
- Misc cleanups
amdkfd:
- Consolidate more gfx config details in amdgpu
- Consolidate bo alloc flags
- Improve code comments
- SDMA MQD fixes
- Misc cleanups
gpu scheduler:
- Add suport for modifying the sched list
uapi:
- Clarify comments about GEM_CREATE flags that are not used by userspace.
The kernel driver has always prevented userspace from using these.
They are only used internally in the kernel driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310212748.4519-1-alexander.deucher@amd.com
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical
amongst every driver and don't do anything other than cleaning up the
connector((drm_connector_unregister()/drm_connector_put())) except for
amdgpu_dm driver where some amdgpu_dm specific code in there.
This connector cleaning up is now being handled in the drm core so
driver destroy_connector callbacks are not needed (except for
amdgpu_dm) hence remove them.
Removal is done with below sementic patch:
@r1@
identifier func, E;
@@
struct drm_dp_mst_topology_cbs E = {
...,
- .destroy_connector = func
};
@delete depends on r1@
identifier r1.func;
@@
- static void func(...){...}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-6-pankaj.laxminarayan.bharadiya@intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
drm_dp_mst_port_add_connector() directly calls the
drm_connector_register() now and
drm_dp_mst_topology_mgr_cbs.register_connector callback is not getting
called anymore.
Hence remove all drm_dp_mst_topology_mgr_cbs.register_connector
callbacks.
This is the preparatory step for removing the
drm_dp_mst_topology_mgr_cbs.register_connector callback hook.
The removal is done with below sementic patch:
@r1@
identifier func, E;
@@
struct drm_dp_mst_topology_cbs E = {
...,
- .register_connector = func
};
@delete depends on r1@
identifier r1.func;
@@
- static void func(...){...}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-3-pankaj.laxminarayan.bharadiya@intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
