Quoting Sandeep Panda (2018-06-04 22:40:15)
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> new file mode 100644
> index 000..add6e0f
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -0,0 +1,666 @@
> +// SPDX-License-Identifier
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/
Remove hand rolled msm property caching to handle DPU
custom properties. This change also cleans up all its
dependencies to cache and restore respective drm
states.
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31
Enable drm core zpos normalization for planes.
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/ms
Submitting a series of patches to further clean up DPU driver by stripping
down a list of custom properties supporting proprietary features. It
removes the property installers/handlers and cleans up relevant files of
of some of the advanced features. This series is based on the patch[1]
available
Cleanup residual connector property enumerations.
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm
changes in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/Makefile | 1 -
drivers/gpu/drm
Replace custom plane zpos property with drm core zpos
property. CRTC relies on the normalized zpos values
to configure blend stages of each plane.
changes in v2:
- Move out unrelated changes in plane init (Sean Paul)
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
remove unwanted dpu uapi headers exposing custom
payload layouts for custom properties
changs in v2:
- none
changes in v3:
- rebased on https://gitlab.freedesktop.org/seanpaul/
dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5
Signed-off-by: Jeykumar Sankaran
Reviewed
Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself. Add support for the
A6XX core code, the GMU and the HF
From: Sharat Masetty
Add initial register headers for A6XX targets.
Signed-off-by: Sharat Masetty
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1784 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 382 +
2 files changed, 2166 insertions(+
Add a helper function to parse the clock names and set up
the bulk data so we can take advantage of the bulk clock
functions instead of rolling our own. This is added
as a helper function so the upcoming a6xx GMU code can
also take advantage of it.
Signed-off-by: Jordan Crouse
---
drivers/gpu/dr
This is an initial version of support for the Adreno a6xx GPU family starting
with the a630 from the sdm845 SoC. This code is ahead of much of the sdm845
code that would be needed to actually bring up a device and it is also in
advance of any user side support for the a6xx GPU so this is mainly jus
Now that the IOMMU is the master of it's own power we don't need to bring
up the GPU to do IOMMU operations. This is good because bringing up a6xx
requires the GMU so calling pm_runtime_get_sync() too early in the process
gets us into some nasty circular dependency situations.
Signed-off-by: Jorda
Failure to load firwmare is the primary reason to fail adreno_load_gpu().
Try to load it first before going into the hardware initialization code and
unwinding it. This is important for a6xx because the GMU gets loaded from
the runtime power code and it is more costly to fail in that path because
o
On Fri, Jun 08, 2018 at 11:56:04AM +0530, Sharat Masetty wrote:
> This series re-factors the devfreq code a bit in preparation for the upcoming
> A6x related devfreq changes. The code applies cleanly on 4.17 and has been
> verified on DB820C.
>
> V2: Addressed code review comments from Jordan Crou
16 matches
Mail list logo