This uses two things that might be Linux specific,
__builtin_constant_p (might be gcc)
and
BUILD_BUG_ON. (maybe other dm's can have something similiar).
This saves 4k in the bw calcs code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
I've no idea if these are used on other platforms, but they
aren't used outside this file here, so make them static.
Drops 300 bytes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is similiar to previous patches, don't return when we don't
need to, also do error checking before allocating memory, makes
it simpler to cleanup after.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There was lots of return true, and error checking that was never used
in these paths.
Just remove it all.
v2: I missed one return true.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This adds ~50k to the driver text segment, and 10k to data segment.
text data bss dec hex filename
2385556 39681 1045 2426282 2505aa drivers/gpu/drm/amd/amdgpu/amdgpu.o
text data bss dec hex filename
2336593 28857 1045 2366495 241c1f drivers/gpu/drm/amd/amdgpu/amdgpu.o
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This code isn't used at all in the kernel tree, perhaps it can wait to
be imported when it is. It also does a lot of floating point calcs,
so probably good to drop it until it's needed and we can ensure
proper fpu accessors.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
While reviewing I2C in DC identified a few places. Added a couple to the
TODO list.
1) Connector info read
See get_ext_display_connection_info
On some boards the connector information has to be read through a
special I2C channel. This line is only used for this purpose and only on
driver init.
2) SCDC stuff
This should all be reworked to go through DRM's SCDC code. When this is
done some unnecessary I2C code can be retired as well.
3) Max TMDS clock read
See dal_ddc_service_i2c_query_dp_dual_mode_adaptor
This should happen in DRM as well. I haven't checked if there's
currently functionality in DRM. If not we can propose something.
4) HDMI retimer programming
Some boards have an HDMI retimer that we need to program to pass PHY
compliance.
1 & 3 might be a good exercise if someone is looking for things to do.
v2: Merge dp_dual_mode_adaptor TODO
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Ok, here's one more attempt at scrolling through 130k diff.
Overall verdict from me is that DC is big project, and like any big
project it's never done. So at least for me the goal isn't to make
things perfect, becaue if that's the hoop to jump through we wouldn't
have any gpu drivers at all. More important is whether merging a new
driver base will benefit the overall subsystem, and here this
primarily means whether the DC team understands how upstream works and
is designed, and whether the code is largely aligned with upstream
(especially the atomic modeset) architecture.
Looking back over the last two years I think that's the case now, so
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
for merging this pull.
While scrolling through the pull I spotted a bunch more things that
should be refactored, but most of these will be a real pain with DC
is out of tree, and much easier in tree since in many of these areas
the in-tree helpers aren't up to snuff yet for what DC needs. That
kind of work is best done when there's one tree with everything
integrated.
That's also why I think we should merge DC into drm-next directly, so
we can get started on the integration polish right away. That has a
bit higher risk of Linus having a spazz, so here's my recommendation
for merging:
- There's a few additions to drm_dp_helper.h sprinkled all over the
pull. I think those should be put into a patch of it's own, and
merged first. No need to rebase DC, git merge will dtrt and not end
up with duplicates.
- dm_alloc/realloc/free is something Dave Airlie noticed, and I agree
it's an easy red flag that might upset Linus. cocci can fix this
easy, so no real problem I think to patch up in one big patch (I
thought we've had a "remove malloc wrappers" todo item in the very
first review, apparently there was more than one such wrapper).
- The history is huge, but AMD folks want to keep it if possible, and
I see the value in that. Would be good to get an ack from Linus for
that (but shouldn't be an issue, not the first time we've merged the
full history of out-of-tree work).
Short&longer term TODO items are still tracked, might be a good idea
to integrate those the overall drm todo in our gpu documentation, for
more visibility.
So in a way this is kinda like staging, except not with the horribly
broken process of having an entirely separate tree for staging drivers
which just makes refactoring needlessly painful (which defeats the
point of staging really). So staging-within-the-subsystem. We've had
that before, with early nouveau.
And yes some of the files are utterly horrible to read and not
anything close to kernel coding style standards. But that's the point,
they're essentially gospel from hw engineers that happens to be
parseable by gcc.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In the scenario of setting underlay, dc_validate_global_state()
is called after constructing the context with all
relevant bottom_pipe related configurations in dm_update_planes_state().
Currently, in dc_validate_global_state(), without checking for bottom_pipe's
existence, the pipe_ctx structure is initialised to 0, hence
nullyfying the plane_state of bottom_pipe which shall be accessed
in populate_initial_data() called from bw_calcs().
Due to this null pointer access kernel panics and leads to reboot
when underlay is tried to set.
This patch fixes the issue by no longer clearing the top_pipe. This
workaround is no longer required.
Signed-off-by: Shirish S <shirish.s@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
