Re: DRM Inquiry
On Fri, 25 May 2018, John Sledge wrote:
> Hi Jani,
> I can now see /dev/drm_dp_aux*.
> I'm not familiar with dd command.Correct me if I'm wrong.
> Possible commands i tried and nothing happen:dd if=/dev/drm_dp_aux1 seek=723
> ibs=2dd of=/dev/drm_dp_aux1 seek=723 ibs=2
> dd if=/dev/drm_dp_aux2 seek=723 ibs=2dd of=/dev/drm_dp_aux2 seek=723 ibs=2
> I assumed I could read the brightness msb and lsb using the define in
> drm_dp_helper.h.
> #define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722#define
> DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723
You're mixing hex and decimal numbers, you should probably use bs=1
count=2, dd outputs binary so you probably need to pipe it to hexdump to
see anything, etc. Perhaps start experiments with reading at seek=0.
> From here, I was thinking if I could try to open \dev\drm_dp_aux* then read
> the brightness offset 0x723, though not sure how to proceed with it.I was
> able to successfully open \dev\drm_dp_aux1 and \dev\drm_dp_aux2 but I
> thinking I'm wrong when I proceed to ioctl because they all failed.
It's a character device, open, seek, read/write. Don't try any ioctls on
it.
Good luck.
BR,
Jani.
>
> #define BRIGHTNESS 0x723
> int main(int argc, char ** argv){ int fd; int retcode; char out[128];
> if((fd = open("/dev/drm_dp_aux1",O_RDWR)) >=0) { printf("open success");
> } else { printf("open failed");
> }
> if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl
> failed"); } else { printf("ioctl success");
> }
> // trying aux2 if((fd = open("/dev/drm_dp_aux2",O_RDWR)) >=0) {
> printf("open success"); } else { printf("open failed");
> }
> if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed");
> } else { printf("ioctl success");
> }
> return 0;}
> Thanks,John
>
> On Thursday, May 24, 2018, 8:38:02 PM GMT+8, Jani Nikula
> wrote:
>
> On Thu, 24 May 2018, John Sledge wrote:
>> I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV
>> in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also
>> add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I
>> could see that the kernel is now 4.6.
>
> If you're updating kernels, why not update to a recent kernel that's
> actually supported...?
>
>> How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure
>> it correctly?
>
> Boot the kernel, run 'ls /dev/drm_dp_aux*'. If you see stuff, you got it
> right.
>
>> It still unclear to me how to follow what you mean by using DRM DP AUX
>> interface and getting /dev/drm_dp_auxN node(s) that allows me to read
>> and write arbitrary DPCD offsets.
>
> The device is a char device you can open, seek to an offset (which would
> be the DPCD offset), and read. For testing, you can achieve the same
> using dd.
>
> BR,
> Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: Consistently use octal not symbolic permissions
On Fri, 2018-05-25 at 09:41 +0300, Jani Nikula wrote: > On Thu, 24 May 2018, Joe Perches wrote: > > There is currently a mixture of octal and symbolic permissions uses > > in files in drivers/gpu/drm and one file in drivers/gpu. > > > > There are ~270 existing octal uses and ~115 S_ uses. > > > > Convert all the S_ symbolic permissions to their octal equivalents > > as using octal and not symbolic permissions is preferred by many as more > > readable. > > > > see: https://lkml.org/lkml/2016/8/2/1945 > > > > Done with automated conversion via: > > $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace > > > > Miscellanea: > > > > o Wrapped modified multi-line calls to a single line where appropriate > > o Realign modified multi-line calls to open parenthesis > > o drivers/gpu/drm/msm/adreno/a5xx_debugfs.c has a world-writeable > > debug permission for "reset" - perhaps that should be modified > > Signed-off-by: Joe Perches > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 98 > > +++--- > > drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 3 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 9 +- > > drivers/gpu/drm/armada/armada_debugfs.c| 4 +- > > drivers/gpu/drm/drm_debugfs.c | 6 +- > > drivers/gpu/drm/drm_debugfs_crc.c | 4 +- > > drivers/gpu/drm/drm_sysfs.c| 2 +- > > drivers/gpu/drm/i915/gvt/firmware.c| 2 +- > > drivers/gpu/drm/i915/i915_debugfs.c| 8 +- > > drivers/gpu/drm/i915/i915_perf.c | 2 +- > > drivers/gpu/drm/i915/i915_sysfs.c | 22 ++--- > > drivers/gpu/drm/i915/intel_pipe_crc.c | 2 +- > > Please send at least i915 changes separately. There's zero reason to > make our lives harder for this change. The idea is to avoid unnecessary multiple patches for individual trees. But you could do that via something like: $ git am --include='drivers/gpu/drm/i915/*' cheers, Joe ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: Consistently use octal not symbolic permissions
Well I think we rejected that multiple times now.
At least I find the symbolic permissions easier to read and I absolutely
don't see any reason why we should only use one form.
Christian.
Am 24.05.2018 um 22:22 schrieb Joe Perches:
There is currently a mixture of octal and symbolic permissions uses
in files in drivers/gpu/drm and one file in drivers/gpu.
There are ~270 existing octal uses and ~115 S_ uses.
Convert all the S_ symbolic permissions to their octal equivalents
as using octal and not symbolic permissions is preferred by many as more
readable.
see: https://lkml.org/lkml/2016/8/2/1945
Done with automated conversion via:
$ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace
Miscellanea:
o Wrapped modified multi-line calls to a single line where appropriate
o Realign modified multi-line calls to open parenthesis
o drivers/gpu/drm/msm/adreno/a5xx_debugfs.c has a world-writeable
debug permission for "reset" - perhaps that should be modified
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 98 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 9 +-
drivers/gpu/drm/armada/armada_debugfs.c| 4 +-
drivers/gpu/drm/drm_debugfs.c | 6 +-
drivers/gpu/drm/drm_debugfs_crc.c | 4 +-
drivers/gpu/drm/drm_sysfs.c| 2 +-
drivers/gpu/drm/i915/gvt/firmware.c| 2 +-
drivers/gpu/drm/i915/i915_debugfs.c| 8 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_sysfs.c | 22 ++---
drivers/gpu/drm/i915/intel_pipe_crc.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 5 +-
drivers/gpu/drm/msm/msm_perf.c | 4 +-
drivers/gpu/drm/msm/msm_rd.c | 4 +-
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c| 11 ++-
.../drm/omapdrm/displays/panel-sony-acx565akm.c| 6 +-
.../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 10 +--
drivers/gpu/drm/radeon/radeon_pm.c | 26 +++---
drivers/gpu/drm/radeon/radeon_ttm.c| 4 +-
drivers/gpu/drm/sti/sti_drv.c | 2 +-
drivers/gpu/drm/tinydrm/mipi-dbi.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
drivers/gpu/drm/ttm/ttm_memory.c | 12 +--
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 6 +-
drivers/gpu/drm/udl/udl_fb.c | 4 +-
drivers/gpu/host1x/debug.c | 12 +--
30 files changed, 138 insertions(+), 146 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index f5fb93795a69..7b29febff511 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -830,7 +830,7 @@ int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
for (i = 0; i < ARRAY_SIZE(debugfs_regs); i++) {
ent = debugfs_create_file(debugfs_regs_names[i],
- S_IFREG | S_IRUGO, root,
+ S_IFREG | 0444, root,
adev, debugfs_regs[i]);
if (IS_ERR(ent)) {
for (j = 0; j < i; j++) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b455da487782..fa55d7e9e784 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -905,39 +905,39 @@ static ssize_t amdgpu_set_pp_power_profile_mode(struct
device *dev,
return -EINVAL;
}
-static DEVICE_ATTR(power_dpm_state, S_IRUGO | S_IWUSR, amdgpu_get_dpm_state, amdgpu_set_dpm_state);
-static DEVICE_ATTR(power_dpm_force_performance_level, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(power_dpm_state, 0644, amdgpu_get_dpm_state,
amdgpu_set_dpm_state);
+static DEVICE_ATTR(power_dpm_force_performance_level, 0644,
amdgpu_get_dpm_forced_performance_level,
amdgpu_set_dpm_forced_performance_level);
-static DEVICE_ATTR(pp_num_states, S_IRUGO, amdgpu_get_pp_num_states, NULL);
-static DEVICE_ATTR(pp_cur_state, S_IRUGO, amdgpu_get_pp_cur_state, NULL);
-static DEVICE_ATTR(pp_force_state, S_IRUGO | S_IWUSR,
- amdgpu_get_pp_force_state,
- amdgpu_set_pp_force_state);
-static DEVICE_ATTR(pp_table, S_IRUGO | S_IWUSR,
- amdgpu_get_pp_table,
- amdgpu_set_pp_table);
-static DEVICE_ATTR(pp_dpm_sclk, S_IRUGO | S_IWUSR,
- amdgpu_get_pp_dpm_sclk,
- amdgpu_set_pp_dp
Re: [PATCH] gpu: Consistently use octal not symbolic permissions
On Thu, 24 May 2018, Joe Perches wrote: > There is currently a mixture of octal and symbolic permissions uses > in files in drivers/gpu/drm and one file in drivers/gpu. > > There are ~270 existing octal uses and ~115 S_ uses. > > Convert all the S_ symbolic permissions to their octal equivalents > as using octal and not symbolic permissions is preferred by many as more > readable. > > see: https://lkml.org/lkml/2016/8/2/1945 > > Done with automated conversion via: > $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace > > Miscellanea: > > o Wrapped modified multi-line calls to a single line where appropriate > o Realign modified multi-line calls to open parenthesis > o drivers/gpu/drm/msm/adreno/a5xx_debugfs.c has a world-writeable > debug permission for "reset" - perhaps that should be modified > > Signed-off-by: Joe Perches > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 98 > +++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 3 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 9 +- > drivers/gpu/drm/armada/armada_debugfs.c| 4 +- > drivers/gpu/drm/drm_debugfs.c | 6 +- > drivers/gpu/drm/drm_debugfs_crc.c | 4 +- > drivers/gpu/drm/drm_sysfs.c| 2 +- > drivers/gpu/drm/i915/gvt/firmware.c| 2 +- > drivers/gpu/drm/i915/i915_debugfs.c| 8 +- > drivers/gpu/drm/i915/i915_perf.c | 2 +- > drivers/gpu/drm/i915/i915_sysfs.c | 22 ++--- > drivers/gpu/drm/i915/intel_pipe_crc.c | 2 +- Please send at least i915 changes separately. There's zero reason to make our lives harder for this change. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM Inquiry
Hi Jani,
I can now see /dev/drm_dp_aux*.
I'm not familiar with dd command.Correct me if I'm wrong.
Possible commands i tried and nothing happen:dd if=/dev/drm_dp_aux1 seek=723
ibs=2dd of=/dev/drm_dp_aux1 seek=723 ibs=2
dd if=/dev/drm_dp_aux2 seek=723 ibs=2dd of=/dev/drm_dp_aux2 seek=723 ibs=2
I assumed I could read the brightness msb and lsb using the define in
drm_dp_helper.h.
#define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722#define
DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723
>From here, I was thinking if I could try to open \dev\drm_dp_aux* then read
>the brightness offset 0x723, though not sure how to proceed with it.I was able
>to successfully open \dev\drm_dp_aux1 and \dev\drm_dp_aux2 but I thinking I'm
>wrong when I proceed to ioctl because they all failed.
#define BRIGHTNESS 0x723
int main(int argc, char ** argv){ int fd; int retcode; char out[128];
if((fd = open("/dev/drm_dp_aux1",O_RDWR)) >=0) { printf("open success"); }
else { printf("open failed");
}
if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed");
} else { printf("ioctl success");
}
// trying aux2 if((fd = open("/dev/drm_dp_aux2",O_RDWR)) >=0) {
printf("open success"); } else { printf("open failed");
}
if((retcode = ioctl(fd,BRIGHTNESS,&out)) < 0) { printf("ioctl failed");
} else { printf("ioctl success");
}
return 0;}
Thanks,John
On Thursday, May 24, 2018, 8:38:02 PM GMT+8, Jani Nikula
wrote:
On Thu, 24 May 2018, John Sledge wrote:
> I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV
> in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also
> add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I
> could see that the kernel is now 4.6.
If you're updating kernels, why not update to a recent kernel that's
actually supported...?
> How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure
> it correctly?
Boot the kernel, run 'ls /dev/drm_dp_aux*'. If you see stuff, you got it
right.
> It still unclear to me how to follow what you mean by using DRM DP AUX
> interface and getting /dev/drm_dp_auxN node(s) that allows me to read
> and write arbitrary DPCD offsets.
The device is a char device you can open, seek to an offset (which would
be the DPCD offset), and read. For testing, you can achieve the same
using dd.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL v2] exynos-drm-next
Hi Dave, Since previous git-pull request, it includes more HW overlays support of DECON controller and several fixups and one cleanup. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit bec923c50ab550d1d53b297dd4c753db18a13204: Merge tag 'exynos-drm-fixes-for-v4.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into exynos-drm-next (2018-05-09 09:27:08 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v4.18-v2 for you to fetch changes up to 19832055e2bf5e67f506bac62e4e07326fb545b7: drm/exynos: fimc: signedness bug in fimc_setup_clocks() (2018-05-25 14:47:40 +0900) Add more HW overlays support - It enables hardware overlay number 4 and 5. For this, this patch series adds required clocks. Several fixups - Fix default value of zpos according to real hardware overlay number. - Fix error value of exynos_Drm_crtc_get_by_type function correctly. - Fix static checker warning of scaler_task_done function. - Fix signedness bug in fimc_setup_clocks function. One cleanup - Disable framedone interrupt of DSI device which is not required. Andrzej Hajda (2): drm/exynos/dsi: remove mode_set callback drm/exynos/dsi: mask frame-done interrupt Andrzej Pietrasiewicz (1): drm/exynos: Add driver for Exynos Scaler module Dan Carpenter (1): drm/exynos: fimc: signedness bug in fimc_setup_clocks() Inki Dae (2): Merge tag 'exynos-drm-next-for-v4.18' of git://git.kernel.org/.../daeinki/drm-exynos into exynos-drm-next drm/exynos: scaler: fix static checker warning Marek Szyprowski (8): drm/exynos: ipp: Add IPP v2 framework drm/exynos: rotator: Convert driver to IPP v2 core API drm/exynos: gsc: Convert driver to IPP v2 core API drm/exynos: fimc: Convert driver to IPP v2 core API dt-bindings: exynos5433-decon: add more required clocks drm/exynos: decon: Add support for hardware windows no 4 and 5 drm/exynos: Fix error value in exynos_drm_crtc_get_by_type() drm/exynos: Fix default value for zpos plane property Paweł Chmiel (1): drm/exynos: Allow DRM_EXYNOS on s5pv210. Souptick Joarder (1): gpu: drm: exynos: Change return type to vm_fault_t Tomasz Figa (1): drm/exynos: fimd: Add support for S5PV210 FIMD variant .../bindings/display/exynos/exynos5433-decon.txt |9 +- .../devicetree/bindings/gpu/samsung-scaler.txt | 27 + drivers/gpu/drm/exynos/Kconfig | 18 +- drivers/gpu/drm/exynos/Makefile|2 + drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 21 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c |2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c| 35 +- drivers/gpu/drm/exynos/exynos_drm_drv.h| 10 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 46 +- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1080 +++- drivers/gpu/drm/exynos/exynos_drm_fimc.h | 23 - drivers/gpu/drm/exynos/exynos_drm_fimd.c |8 + drivers/gpu/drm/exynos/exynos_drm_gem.c| 21 +- drivers/gpu/drm/exynos/exynos_drm_gem.h|3 +- drivers/gpu/drm/exynos/exynos_drm_gsc.c| 1075 ++- drivers/gpu/drm/exynos/exynos_drm_gsc.h| 24 - drivers/gpu/drm/exynos/exynos_drm_ipp.c| 916 + drivers/gpu/drm/exynos/exynos_drm_ipp.h| 175 drivers/gpu/drm/exynos/exynos_drm_plane.c |9 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c| 758 -- drivers/gpu/drm/exynos/exynos_drm_scaler.c | 694 + drivers/gpu/drm/exynos/regs-scaler.h | 426 include/uapi/drm/exynos_drm.h | 240 + 23 files changed, 3459 insertions(+), 2163 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpu/samsung-scaler.txt delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.h delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h create mode 100644 drivers/gpu/drm/exynos/exynos_drm_scaler.c create mode 100644 drivers/gpu/drm/exynos/regs-scaler.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106561] ./libdrm_macros.h:26:5: error: 'HAVE_VISIBILITY' is not defined, evaluates to 0 [-Werror,-Wundef]
https://bugs.freedesktop.org/show_bug.cgi?id=106561 Tomasz Paweł Gajc changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #3 from Tomasz Paweł Gajc --- Fixed by compiling libdrm with meson. Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] TDA998x I2C driver CEC support
On 23 May 2018 at 19:13, Russell King wrote: > On Wed, May 23, 2018 at 10:48:15AM +0200, Daniel Vetter wrote: >> On Tue, May 22, 2018 at 09:27:07AM +0100, Russell King wrote: >> > On Tue, May 22, 2018 at 10:53:49AM +1000, Dave Airlie wrote: >> > > Sorry I missed this, just fell between the cracks, >> > > >> > > Any reason you can't/don't use git pull-request to generate pulls? we >> > > have some scripts that parse pulls for tracking now, but this pull >> > > didn't get into the system as it doesn't use the template. >> > >> > I've never used git pull-request, and it doesn't seem to be part of >> > the git installation I have: >> >> The command is called request-pull. Our scripting wraps it in >> pull-request, which I guess caused the confusion. > > [Adding Linus] > > Hmm, so where do people put the hand-written commentry in a git > request-pull formatted request that Linus likes to see when sending > such requests to Linus? > > I can understand other maintainers not caring about that, but whatever > solution I have to this must work for sending to Linus as well - the > format of my pull requests are based on an example format from Linus > in the early days of git before request-pull even existed. They also > satisfy Linus' other need which is that they need to be clearly > identifyable as truely being from the maintainer - I believe Linus > uses format and language in the request as part of that. > > The other thing I notice is that the request-pull format is very > impersonal, doesn't say what the summary of changes are (it probably > has no way to do so), and contains no gratitudes - its tone is very > much like an order than a request. Compare the one I sent in April > with this: If you look at any of the ones I send and Linus accepts they are all generated with the git script, I think Linus likes seeing things with the git script. I tend to just write a summary before the contents of the pull request that the script produces. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for v4.17-rc7
Hi Linus, Only two sets of drivers fixes, one rcar-du lvds regression fix, and a group of fixes for vmwgfx. Regards, Dave. The following changes since commit 771c577c23bac90597c685971d7297ea00f99d11: Linux 4.17-rc6 (2018-05-20 15:31:38 -0700) are available in the Git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.17-rc7 for you to fetch changes up to 4bc6f777952cf2d5b39e0c5a97a18caa743f03b7: Merge branch 'vmwgfx-fixes-4.17' of git://people.freedesktop.org/~thomash/linux into drm-fixes (2018-05-25 09:47:56 +1000) vmwgfx, rcar-du fixes Dave Airlie (2): Merge branch 'drm/du/fixes' of git://linuxtv.org/pinchartl/media into drm-fixes Merge branch 'vmwgfx-fixes-4.17' of git://people.freedesktop.org/~thomash/linux into drm-fixes Laurent Pinchart (1): drm: rcar-du: lvds: Fix crash in .atomic_check when disabling connector Thomas Hellstrom (3): drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macros drm/vmwgfx: Fix host logging / guestinfo reading error paths drm/vmwgfx: Schedule an fb dirty update after resume drivers/gpu/drm/rcar-du/rcar_lvds.c | 3 +++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 22 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 48 - drivers/gpu/drm/vmwgfx/vmwgfx_msg.h | 25 --- 6 files changed, 58 insertions(+), 46 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/xen-front: fix pointer casts
On 05/23/2018 02:46 PM, Juergen Gross wrote: On 23/05/18 13:36, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Building for a 32-bit target results in warnings from casting between a 32-bit pointer and a 64-bit integer. Fix the warnings by casting those pointers to uintptr_t first. Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Juergen Gross Thank you, applied to drm-misc-next Juergen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 8/8] drm/mediatek: add third ddp path
Hi, Stu: On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote: > From: Stu Hsieh > > This patch create third crtc by third ddp path > Apply this patch before the patch 'Add support for mediatek SOC MT2712' because this patch is necessary for mt2712. > Signed-off-by: Stu Hsieh > --- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > index b32c4cc8d051..3a866e1d6af4 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm) > if (ret < 0) > goto err_component_unbind; > > + ret = mtk_drm_crtc_create(drm, private->data->third_path, > + private->data->third_len); I think you should prevent doing this for mt8173 and mt2701 because that two SoC has only two ddp path. Regards, CK > + if (ret < 0) > + goto err_component_unbind; > + > /* Use OVL device for all DMA memory allocations */ > np = private->comp_node[private->data->main_path[0]] ?: >private->comp_node[private->data->ext_path[0]]; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/8] drm/mediatek: Add support for mediatek SOC MT2712
Hi, Stu:
I've some inline comment.
On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> From: Stu Hsieh
>
> This patch add support for the Mediatek MT2712 DISP subsystem.
> There are two OVL engine and three disp output in MT2712.
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 46
> +++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 8 +++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 42 --
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +++--
> 4 files changed, 94 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 0f568dd853d8..676726249ae0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -61,6 +61,24 @@
> #define MT8173_MUTEX_MOD_DISP_PWM1 24
> #define MT8173_MUTEX_MOD_DISP_OD 25
>
> +#define MT2712_MUTEX_MOD_DISP_OVL0 11
> +#define MT2712_MUTEX_MOD_DISP_OVL1 12
> +#define MT2712_MUTEX_MOD_DISP_RDMA0 13
> +#define MT2712_MUTEX_MOD_DISP_RDMA1 14
> +#define MT2712_MUTEX_MOD_DISP_RDMA2 15
> +#define MT2712_MUTEX_MOD_DISP_WDMA0 16
> +#define MT2712_MUTEX_MOD_DISP_WDMA1 17
> +#define MT2712_MUTEX_MOD_DISP_COLOR0 18
> +#define MT2712_MUTEX_MOD_DISP_COLOR1 19
> +#define MT2712_MUTEX_MOD_DISP_AAL0 20
> +#define MT2712_MUTEX_MOD_DISP_UFOE 22
> +#define MT2712_MUTEX_MOD_DISP_PWM0 23
> +#define MT2712_MUTEX_MOD_DISP_PWM1 24
> +#define MT2712_MUTEX_MOD_DISP_PWM2 10
> +#define MT2712_MUTEX_MOD_DISP_OD025
> +#define MT2712_MUTEX_MOD2_DISP_AAL1 33
> +#define MT2712_MUTEX_MOD2_DISP_OD1 34
I would like this to be in the order by index.
> +
> #define MT2701_MUTEX_MOD_DISP_OVL3
> #define MT2701_MUTEX_MOD_DISP_WDMA 6
> #define MT2701_MUTEX_MOD_DISP_COLOR 7
> @@ -75,6 +93,7 @@
>
> #define OVL0_MOUT_EN_COLOR0 0x1
> #define OD_MOUT_EN_RDMA0 0x1
> +#define OD1_MOUT_EN_RDMA1BIT(16)
> #define UFOE_MOUT_EN_DSI00x1
> #define COLOR0_SEL_IN_OVL0 0x1
> #define OVL1_MOUT_EN_COLOR1 0x1
> @@ -109,12 +128,32 @@ static const unsigned int
> mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> };
>
> +static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
> + [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
> + [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
> + [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
> + [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
> + [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
> + [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
> + [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
> + [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
> + [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
> + [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
> + [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
> + [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
> +};
> +
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> - [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> + [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
Move this to the patch 'add ddp component AAL1'.
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
> [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
> - [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
> + [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,
Move this to the patch 'add ddp component OD1'.
> [DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
> [DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
> [DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
> @@ -139,7 +178,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
> cur,
> } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
> *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> value = OVL_MOUT_EN_RDMA;
> - } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
> + } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
Move this to the patch 'add ddp component OD1'.
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD_MOUT_EN_RDMA0;
> } else if (cur == DDP_COMPONENT_UFOE && next =
[PATCH 1/3] drm/scheduler: fix a corner case in dependency optimization
When checking for a dependency fence for belonging to the same entity
compare it with scheduled as well finished fence. Earlier we were only
comparing it with the scheduled fence.
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index df1578d6f42e..44d480768dfe 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -349,8 +349,13 @@ static bool drm_sched_entity_add_dependency_cb(struct
drm_sched_entity *entity)
struct dma_fence * fence = entity->dependency;
struct drm_sched_fence *s_fence;
- if (fence->context == entity->fence_context) {
- /* We can ignore fences from ourself */
+ if (fence->context == entity->fence_context ||
+fence->context == entity->fence_context + 1) {
+/*
+ * Fence is a scheduled/finished fence from a job
+ * which belongs to the same entity, we can ignore
+ * fences from ourself
+ */
dma_fence_put(entity->dependency);
return false;
}
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/doc: add a chapter for gpu scheduler
Signed-off-by: Nayan Deshmukh --- Documentation/gpu/drm-mm.rst | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index b08e9dcd9177..96ebcc2a7b41 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -496,3 +496,21 @@ DRM Sync Objects .. kernel-doc:: drivers/gpu/drm/drm_syncobj.c :export: + +GPU Scheduler += + +Overview + + +.. kernel-doc:: drivers/gpu/drm/scheduler/gpu_scheduler.c + :doc: Overview + +Scheduler Function References +- + +.. kernel-doc:: include/drm/gpu_scheduler.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/scheduler/gpu_scheduler.c + :export: -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/scheduler: add documentation
convert existing raw comments into kernel-doc format as well
as add new documentation
Signed-off-by: Alex Deucher
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 214 --
include/drm/gpu_scheduler.h | 153 +
2 files changed, 296 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 44d480768dfe..c70c983e3e74 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -21,6 +21,29 @@
*
*/
+/**
+ * DOC: Overview
+ *
+ * The GPU scheduler provides entities which allow userspace to push jobs
+ * into software queues which are then scheduled on a hardware run queue.
+ * The software queues have a priority among them. The scheduler selects the
entities
+ * from the run queue using FIFO. The scheduler provides dependency handling
+ * features among jobs. The driver is supposed to provide functions for backend
+ * operations to the scheduler like submitting a job to hardware run queue,
+ * returning the dependency of a job etc.
+ *
+ * The organisation of the scheduler is the following:-
+ *
+ * 1. Each ring buffer has one scheduler
+ * 2. Each scheduler has multiple run queues with different priorities
+ *(i.e. HIGH_HW,HIGH_SW, KERNEL, NORMAL)
+ * 3. Each run queue has a queue of entities to schedule
+ * 4. Entities themselves maintain a queue of jobs that will be scheduled on
+ *the hardware.
+ *
+ * The jobs in a entity are always scheduled in the order that they were
pushed.
+ */
+
#include
#include
#include
@@ -39,7 +62,13 @@ static bool drm_sched_entity_is_ready(struct
drm_sched_entity *entity);
static void drm_sched_wakeup(struct drm_gpu_scheduler *sched);
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
*cb);
-/* Initialize a given run queue struct */
+/**
+ * drm_sched_rq_init - initialize a given run queue struct
+ *
+ * @rq: scheduler run queue
+ *
+ * Initializes a scheduler runqueue.
+ */
static void drm_sched_rq_init(struct drm_sched_rq *rq)
{
spin_lock_init(&rq->lock);
@@ -47,6 +76,14 @@ static void drm_sched_rq_init(struct drm_sched_rq *rq)
rq->current_entity = NULL;
}
+/**
+ * drm_sched_rq_add_entity - add an entity
+ *
+ * @rq: scheduler run queue
+ * @entity: scheduler entity
+ *
+ * Adds a scheduler entity to the run queue.
+ */
static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
struct drm_sched_entity *entity)
{
@@ -57,6 +94,14 @@ static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
spin_unlock(&rq->lock);
}
+/**
+ * drm_sched_rq_remove_entity - remove an entity
+ *
+ * @rq: scheduler run queue
+ * @entity: scheduler entity
+ *
+ * Removes a scheduler entity from the run queue.
+ */
static void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
struct drm_sched_entity *entity)
{
@@ -70,9 +115,9 @@ static void drm_sched_rq_remove_entity(struct drm_sched_rq
*rq,
}
/**
- * Select an entity which could provide a job to run
+ * drm_sched_rq_select_entity - Select an entity which could provide a job to
run
*
- * @rq The run queue to check.
+ * @rq: scheduler run queue to check.
*
* Try to find a ready entity, returns NULL if none found.
*/
@@ -112,15 +157,16 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
}
/**
- * Init a context entity used by scheduler when submit to HW ring.
+ * drm_sched_entity_init - Init a context entity used by scheduler when
+ * submit to HW ring.
*
- * @sched The pointer to the scheduler
- * @entity The pointer to a valid drm_sched_entity
- * @rq The run queue this entity belongs
- * @guilty atomic_t set to 1 when a job on this queue
- * is found to be guilty causing a timeout
+ * @sched: scheduler instance
+ * @entity: scheduler entity to init
+ * @rq: the run queue this entity belongs
+ * @guilty: atomic_t set to 1 when a job on this queue
+ * is found to be guilty causing a timeout
*
- * return 0 if succeed. negative error code on failure
+ * Returns 0 on success or a negative error code on failure.
*/
int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
struct drm_sched_entity *entity,
@@ -149,10 +195,10 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
EXPORT_SYMBOL(drm_sched_entity_init);
/**
- * Query if entity is initialized
+ * drm_sched_entity_is_initialized - Query if entity is initialized
*
- * @sched Pointer to scheduler instance
- * @entity The pointer to a valid scheduler entity
+ * @sched: Pointer to scheduler instance
+ * @entity: The pointer to a valid scheduler entity
*
* return true if entity is initialized, false otherwise
*/
@@ -164,11 +210,11 @@ static bool drm_sched_entity_is_initialized(struct
drm_gpu_
Re: [PATCH v3 4/8] drm/mediatek: add ddp component AAL1
Hi, Stu:
On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> From: Stu Hsieh
>
> This patch add component AAL1 and
> rename AAL to AAL0
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 0828cf8bf85c..eee3c0cc2632 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -41,7 +41,8 @@ enum mtk_ddp_comp_type {
> };
>
> enum mtk_ddp_comp_id {
> - DDP_COMPONENT_AAL,
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_AAL1,
Be sure compiling is success when you apply each patch of a series. I
think when you apply to this patch, it would cause compiling error
because some related modification is in the patch 'Add support for
mediatek SOC MT2712'. So move the modification from that patch to this
patch.
Regards,
CK
> DDP_COMPONENT_BLS,
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_COLOR1,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/8] drm/mediatek: add connection from OD1 to RDMA1
Hi, Stu:
On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> From: Stu Hsieh
>
> This patch add the connection from OD1 to RDMA1 for ext path.
>
Reviewed-by: CK Hu
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 47ffa240bd25..0f568dd853d8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -151,6 +151,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
> cur,
> } else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
> *addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
> value = GAMMA_MOUT_EN_RDMA1;
> + } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
> + *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> + value = OD1_MOUT_EN_RDMA1;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/8] drm/mediatek: support maximum 64 mutex mod
Hi, Stu:
On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> From: Stu Hsieh
>
> This patch support that if modules more than 32,
> add index more than 31 when using DISP_REG_MUTEX_MOD2 bit
>
Reviewed-by: CK Hu
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 75
> +-
> 1 file changed, 47 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8130f3dab661..47ffa240bd25 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -41,31 +41,32 @@
> #define DISP_REG_MUTEX_RST(n)(0x28 + 0x20 * (n))
> #define DISP_REG_MUTEX_MOD(n)(0x2c + 0x20 * (n))
> #define DISP_REG_MUTEX_SOF(n)(0x30 + 0x20 * (n))
> +#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
>
> #define INT_MUTEXBIT(1)
>
> -#define MT8173_MUTEX_MOD_DISP_OVL0 BIT(11)
> -#define MT8173_MUTEX_MOD_DISP_OVL1 BIT(12)
> -#define MT8173_MUTEX_MOD_DISP_RDMA0 BIT(13)
> -#define MT8173_MUTEX_MOD_DISP_RDMA1 BIT(14)
> -#define MT8173_MUTEX_MOD_DISP_RDMA2 BIT(15)
> -#define MT8173_MUTEX_MOD_DISP_WDMA0 BIT(16)
> -#define MT8173_MUTEX_MOD_DISP_WDMA1 BIT(17)
> -#define MT8173_MUTEX_MOD_DISP_COLOR0 BIT(18)
> -#define MT8173_MUTEX_MOD_DISP_COLOR1 BIT(19)
> -#define MT8173_MUTEX_MOD_DISP_AALBIT(20)
> -#define MT8173_MUTEX_MOD_DISP_GAMMA BIT(21)
> -#define MT8173_MUTEX_MOD_DISP_UFOE BIT(22)
> -#define MT8173_MUTEX_MOD_DISP_PWM0 BIT(23)
> -#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
> -#define MT8173_MUTEX_MOD_DISP_OD BIT(25)
> -
> -#define MT2701_MUTEX_MOD_DISP_OVLBIT(3)
> -#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
> -#define MT2701_MUTEX_MOD_DISP_COLOR BIT(7)
> -#define MT2701_MUTEX_MOD_DISP_BLSBIT(9)
> -#define MT2701_MUTEX_MOD_DISP_RDMA0 BIT(10)
> -#define MT2701_MUTEX_MOD_DISP_RDMA1 BIT(12)
> +#define MT8173_MUTEX_MOD_DISP_OVL0 11
> +#define MT8173_MUTEX_MOD_DISP_OVL1 12
> +#define MT8173_MUTEX_MOD_DISP_RDMA0 13
> +#define MT8173_MUTEX_MOD_DISP_RDMA1 14
> +#define MT8173_MUTEX_MOD_DISP_RDMA2 15
> +#define MT8173_MUTEX_MOD_DISP_WDMA0 16
> +#define MT8173_MUTEX_MOD_DISP_WDMA1 17
> +#define MT8173_MUTEX_MOD_DISP_COLOR0 18
> +#define MT8173_MUTEX_MOD_DISP_COLOR1 19
> +#define MT8173_MUTEX_MOD_DISP_AAL20
> +#define MT8173_MUTEX_MOD_DISP_GAMMA 21
> +#define MT8173_MUTEX_MOD_DISP_UFOE 22
> +#define MT8173_MUTEX_MOD_DISP_PWM0 23
> +#define MT8173_MUTEX_MOD_DISP_PWM1 24
> +#define MT8173_MUTEX_MOD_DISP_OD 25
> +
> +#define MT2701_MUTEX_MOD_DISP_OVL3
> +#define MT2701_MUTEX_MOD_DISP_WDMA 6
> +#define MT2701_MUTEX_MOD_DISP_COLOR 7
> +#define MT2701_MUTEX_MOD_DISP_BLS9
> +#define MT2701_MUTEX_MOD_DISP_RDMA0 10
> +#define MT2701_MUTEX_MOD_DISP_RDMA1 12
>
> #define MUTEX_SOF_SINGLE_MODE0
> #define MUTEX_SOF_DSI0 1
> @@ -278,6 +279,7 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
> struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
> mutex[mutex->id]);
> unsigned int reg;
> + unsigned int offset;
>
> WARN_ON(&ddp->mutex[mutex->id] != mutex);
>
> @@ -292,9 +294,17 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex
> *mutex,
> reg = MUTEX_SOF_DPI0;
> break;
> default:
> - reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
> - reg |= ddp->mutex_mod[id];
> - writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
> + if (ddp->mutex_mod[id] < 32) {
> + offset = DISP_REG_MUTEX_MOD(mutex->id);
> + reg = readl_relaxed(ddp->regs + offset);
> + reg |= 1 << ddp->mutex_mod[id];
> + writel_relaxed(reg, ddp->regs + offset);
> + } else {
> + offset = DISP_REG_MUTEX_MOD2(mutex->id);
> + reg = readl_relaxed(ddp->regs + offset);
> + reg |= 1 << (ddp->mutex_mod[id] - 32);
> + writel_relaxed(reg, ddp->regs + offset);
> + }
> return;
> }
>
> @@ -307,6 +317,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
> *mutex,
> struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
> mutex[mutex->id]);
> unsigned int reg;
> + unsigned int offset;
>
> WARN_ON(&ddp->mutex[mutex->id] != mutex);
>
> @@ -318,9 +329,17 @@ void m
Re: [PATCH v3 1/8] drm/mediatek: update dt-bindings for mt2712
Hi, Stu: On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote: > From: Stu Hsieh > > Update device tree binding documentation for the display subsystem for > Mediatek MT2712 SoCs. > I've acked v2 of this patch and v3 is the same as v2, so you should keep my ack in commit message. Regards, CK > Signed-off-by: Stu Hsieh > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > index 383183a89164..8469de510001 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > @@ -40,7 +40,7 @@ Required properties (all function blocks): > "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt > "mediatek,-disp-mutex" - display mutex > "mediatek,-disp-od"- overdrive > - the supported chips are mt2701 and mt8173. > + the supported chips are mt2701, mt2712 and mt8173. > - reg: Physical base address and length of the function block register space > - interrupts: The interrupt signal from the function block (required, except > for >merge and split function blocks). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed
Hi Heiko, Sandy, On Fri, May 25, 2018 at 7:07 AM Heiko Stübner wrote: > From: Sandy Huang > The vop irq is shared between vop and iommu and irq probing in the > iommu driver moved to the probe function recently. This can in some > cases lead to a stall if the irq is triggered while the vop driver > still has it disabled. > But there is no real need to disable the irq, as the vop can simply > also track its enabled state and ignore irqs in that case. > So remove the enable/disable handling and add appropriate condition > to the irq handler. > Signed-off-by: Sandy Huang > [added an actual commit message] > Signed-off-by: Heiko Stuebner > --- > Hi Ezequiel, > this patch came from a discussion I had with Rockchip people over the > iommu changes and resulting issues back in april, but somehow was > forgotten and not posted to the lists. Correcting that now. > So removing the enable/disable voodoo on the shared interrupt is > the preferred way. > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 ++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > index 510cdf0..61493d4 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > @@ -549,8 +549,6 @@ static int vop_enable(struct drm_crtc *crtc) > spin_unlock(&vop->reg_lock); > - enable_irq(vop->irq); > - While this one should be okay (+/- my comment for vop_isr()), because the hardware is already powered on and clocked at this point... > drm_crtc_vblank_on(crtc); > return 0; > @@ -596,8 +594,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc, > vop_dsp_hold_valid_irq_disable(vop); > - disable_irq(vop->irq); > - > vop->is_enabled = false; ...this one is more tricky. There might be an interrupt handler still running at this point. disable_irq() waits for any running handler to complete before disabling, so we might want to call synchronize_irq() after setting is_enabled to false. > /* > @@ -1168,6 +1164,13 @@ static irqreturn_t vop_isr(int irq, void *data) > int ret = IRQ_NONE; > /* > +* since the irq is shared with iommu, iommu irq is enabled before vop > +* enable, so before vop enable we do nothing. > +*/ > + if (!vop->is_enabled) > + return IRQ_NONE; This doesn't seem to be properly synchronized. We don't even call it under a spinlock, so no barriers are issued. Perhaps we should make this atomic_t? Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/8] drm/mediatek: support maximum 64 mutex mod
From: Stu Hsieh
This patch support that if modules more than 32,
add index more than 31 when using DISP_REG_MUTEX_MOD2 bit
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 75 +-
1 file changed, 47 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..47ffa240bd25 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -41,31 +41,32 @@
#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
#define DISP_REG_MUTEX_MOD(n) (0x2c + 0x20 * (n))
#define DISP_REG_MUTEX_SOF(n) (0x30 + 0x20 * (n))
+#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
#define INT_MUTEX BIT(1)
-#define MT8173_MUTEX_MOD_DISP_OVL0 BIT(11)
-#define MT8173_MUTEX_MOD_DISP_OVL1 BIT(12)
-#define MT8173_MUTEX_MOD_DISP_RDMA0BIT(13)
-#define MT8173_MUTEX_MOD_DISP_RDMA1BIT(14)
-#define MT8173_MUTEX_MOD_DISP_RDMA2BIT(15)
-#define MT8173_MUTEX_MOD_DISP_WDMA0BIT(16)
-#define MT8173_MUTEX_MOD_DISP_WDMA1BIT(17)
-#define MT8173_MUTEX_MOD_DISP_COLOR0 BIT(18)
-#define MT8173_MUTEX_MOD_DISP_COLOR1 BIT(19)
-#define MT8173_MUTEX_MOD_DISP_AAL BIT(20)
-#define MT8173_MUTEX_MOD_DISP_GAMMABIT(21)
-#define MT8173_MUTEX_MOD_DISP_UFOE BIT(22)
-#define MT8173_MUTEX_MOD_DISP_PWM0 BIT(23)
-#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
-#define MT8173_MUTEX_MOD_DISP_OD BIT(25)
-
-#define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
-#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
-#define MT2701_MUTEX_MOD_DISP_COLORBIT(7)
-#define MT2701_MUTEX_MOD_DISP_BLS BIT(9)
-#define MT2701_MUTEX_MOD_DISP_RDMA0BIT(10)
-#define MT2701_MUTEX_MOD_DISP_RDMA1BIT(12)
+#define MT8173_MUTEX_MOD_DISP_OVL0 11
+#define MT8173_MUTEX_MOD_DISP_OVL1 12
+#define MT8173_MUTEX_MOD_DISP_RDMA013
+#define MT8173_MUTEX_MOD_DISP_RDMA114
+#define MT8173_MUTEX_MOD_DISP_RDMA215
+#define MT8173_MUTEX_MOD_DISP_WDMA016
+#define MT8173_MUTEX_MOD_DISP_WDMA117
+#define MT8173_MUTEX_MOD_DISP_COLOR0 18
+#define MT8173_MUTEX_MOD_DISP_COLOR1 19
+#define MT8173_MUTEX_MOD_DISP_AAL 20
+#define MT8173_MUTEX_MOD_DISP_GAMMA21
+#define MT8173_MUTEX_MOD_DISP_UFOE 22
+#define MT8173_MUTEX_MOD_DISP_PWM0 23
+#define MT8173_MUTEX_MOD_DISP_PWM1 24
+#define MT8173_MUTEX_MOD_DISP_OD 25
+
+#define MT2701_MUTEX_MOD_DISP_OVL 3
+#define MT2701_MUTEX_MOD_DISP_WDMA 6
+#define MT2701_MUTEX_MOD_DISP_COLOR7
+#define MT2701_MUTEX_MOD_DISP_BLS 9
+#define MT2701_MUTEX_MOD_DISP_RDMA010
+#define MT2701_MUTEX_MOD_DISP_RDMA112
#define MUTEX_SOF_SINGLE_MODE 0
#define MUTEX_SOF_DSI0 1
@@ -278,6 +279,7 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int offset;
WARN_ON(&ddp->mutex[mutex->id] != mutex);
@@ -292,9 +294,17 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
reg = MUTEX_SOF_DPI0;
break;
default:
- reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
- reg |= ddp->mutex_mod[id];
- writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
+ if (ddp->mutex_mod[id] < 32) {
+ offset = DISP_REG_MUTEX_MOD(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg |= 1 << ddp->mutex_mod[id];
+ writel_relaxed(reg, ddp->regs + offset);
+ } else {
+ offset = DISP_REG_MUTEX_MOD2(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg |= 1 << (ddp->mutex_mod[id] - 32);
+ writel_relaxed(reg, ddp->regs + offset);
+ }
return;
}
@@ -307,6 +317,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
*mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int offset;
WARN_ON(&ddp->mutex[mutex->id] != mutex);
@@ -318,9 +329,17 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
*mutex,
ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
break;
default:
- reg = readl_relaxed(ddp->
[PATCH v3 6/8] drm/mediatek: add ddp component PWM2
From: Stu Hsieh
This patch add component PWM2
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 9b19fc4423f1..e00c2e798abd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -56,6 +56,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
+ DDP_COMPONENT_PWM2,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_RDMA1,
DDP_COMPONENT_RDMA2,
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/8] drm/mediatek: add third ddp path
From: Stu Hsieh This patch create third crtc by third ddp path Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index b32c4cc8d051..3a866e1d6af4 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm) if (ret < 0) goto err_component_unbind; + ret = mtk_drm_crtc_create(drm, private->data->third_path, + private->data->third_len); + if (ret < 0) + goto err_component_unbind; + /* Use OVL device for all DMA memory allocations */ np = private->comp_node[private->data->main_path[0]] ?: private->comp_node[private->data->ext_path[0]]; -- 2.12.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/8] Add support for mediatek SOC MT2712
From: Stu Hsieh This patch add support for the Mediatek MT2712 DISP subsystem. MT2712 is base on MT8173, there are some difference as following: MT2712 support three disp output(two ovl and one rdma) Change in v3: - Added patch for ddp component AAL1 - Added patch for ddp component OD1 - Added patch for ddp component PWM2 - Added patch to create third ddp path - Rebase patch "support maximum 64 mutex mod" before "Add support for mediatek SOC MT2712" - Rebase patch "add connection from OD1 to RDMA1" before "Add support for mediatek SOC MT2712" - Remove two definition about RDMA0 and RDMA2 - Change the definition about mutex module from bitwise to index Changes in v2: - update dt-bindings for mt2712 - Added patch to connection from OD1 to RDMA1 - Added patch to support maximum 64 mutex mod - rewrite mutex mod condition for reducing one byte - Change the component name AAL/OD to AAL0/OD0 for naming consistency - Move the compatible infomation about dpi to other patch which modify the dpi driver for mt2712 Stu Hsieh (8): drm/mediatek: update dt-bindings for mt2712 drm/mediatek: support maximum 64 mutex mod drm/mediatek: add connection from OD1 to RDMA1 drm/mediatek: add ddp component AAL1 drm/mediatek: add ddp component OD1 drm/mediatek: add ddp component PWM2 drm/mediatek: Add support for mediatek SOC MT2712 drm/mediatek: add third ddp path .../bindings/display/mediatek/mediatek,disp.txt| 2 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 124 +++-- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 8 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 7 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 +++- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +- 6 files changed, 155 insertions(+), 40 deletions(-) -- 2.12.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/8] drm/mediatek: add ddp component AAL1
From: Stu Hsieh
This patch add component AAL1 and
rename AAL to AAL0
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 0828cf8bf85c..eee3c0cc2632 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -41,7 +41,8 @@ enum mtk_ddp_comp_type {
};
enum mtk_ddp_comp_id {
- DDP_COMPONENT_AAL,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_AAL1,
DDP_COMPONENT_BLS,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/8] drm/mediatek: add ddp component OD1
From: Stu Hsieh
This patch add the component OD1 and
rename the OD to OD1
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index eee3c0cc2632..9b19fc4423f1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -50,7 +50,8 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_DSI0,
DDP_COMPONENT_DSI1,
DDP_COMPONENT_GAMMA,
- DDP_COMPONENT_OD,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_OD1,
DDP_COMPONENT_OVL0,
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/8] drm/mediatek: Add support for mediatek SOC MT2712
From: Stu Hsieh
This patch add support for the Mediatek MT2712 DISP subsystem.
There are two OVL engine and three disp output in MT2712.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 46 +++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 8 +++--
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 42 --
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +++--
4 files changed, 94 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 0f568dd853d8..676726249ae0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -61,6 +61,24 @@
#define MT8173_MUTEX_MOD_DISP_PWM1 24
#define MT8173_MUTEX_MOD_DISP_OD 25
+#define MT2712_MUTEX_MOD_DISP_OVL0 11
+#define MT2712_MUTEX_MOD_DISP_OVL1 12
+#define MT2712_MUTEX_MOD_DISP_RDMA013
+#define MT2712_MUTEX_MOD_DISP_RDMA114
+#define MT2712_MUTEX_MOD_DISP_RDMA215
+#define MT2712_MUTEX_MOD_DISP_WDMA016
+#define MT2712_MUTEX_MOD_DISP_WDMA117
+#define MT2712_MUTEX_MOD_DISP_COLOR0 18
+#define MT2712_MUTEX_MOD_DISP_COLOR1 19
+#define MT2712_MUTEX_MOD_DISP_AAL0 20
+#define MT2712_MUTEX_MOD_DISP_UFOE 22
+#define MT2712_MUTEX_MOD_DISP_PWM0 23
+#define MT2712_MUTEX_MOD_DISP_PWM1 24
+#define MT2712_MUTEX_MOD_DISP_PWM2 10
+#define MT2712_MUTEX_MOD_DISP_OD0 25
+#define MT2712_MUTEX_MOD2_DISP_AAL133
+#define MT2712_MUTEX_MOD2_DISP_OD1 34
+
#define MT2701_MUTEX_MOD_DISP_OVL 3
#define MT2701_MUTEX_MOD_DISP_WDMA 6
#define MT2701_MUTEX_MOD_DISP_COLOR7
@@ -75,6 +93,7 @@
#define OVL0_MOUT_EN_COLOR00x1
#define OD_MOUT_EN_RDMA0 0x1
+#define OD1_MOUT_EN_RDMA1 BIT(16)
#define UFOE_MOUT_EN_DSI0 0x1
#define COLOR0_SEL_IN_OVL0 0x1
#define OVL1_MOUT_EN_COLOR10x1
@@ -109,12 +128,32 @@ static const unsigned int
mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
};
+static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
+ [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
+ [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
+ [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
+ [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
+ [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
+ [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
+ [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
+ [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
+ [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
+ [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
+ [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
+};
+
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
+ [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
[DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
[DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
- [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
+ [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,
[DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
[DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
[DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
@@ -139,7 +178,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
cur,
} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
value = OVL_MOUT_EN_RDMA;
- } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
+ } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
} else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
@@ -429,6 +468,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
static const struct of_device_id ddp_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
+ { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
{ .compatible = "mediatek,mt8173-disp-m
[PATCH v3 3/8] drm/mediatek: add connection from OD1 to RDMA1
From: Stu Hsieh
This patch add the connection from OD1 to RDMA1 for ext path.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 47ffa240bd25..0f568dd853d8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -151,6 +151,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
cur,
} else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
value = GAMMA_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
+ *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
+ value = OD1_MOUT_EN_RDMA1;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
*addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
value = RDMA1_MOUT_DPI0;
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/8] drm/mediatek: update dt-bindings for mt2712
From: Stu Hsieh Update device tree binding documentation for the display subsystem for Mediatek MT2712 SoCs. Signed-off-by: Stu Hsieh --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 383183a89164..8469de510001 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -40,7 +40,7 @@ Required properties (all function blocks): "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt "mediatek,-disp-mutex" - display mutex "mediatek,-disp-od"- overdrive - the supported chips are mt2701 and mt8173. + the supported chips are mt2701, mt2712 and mt8173. - reg: Physical base address and length of the function block register space - interrupts: The interrupt signal from the function block (required, except for merge and split function blocks). -- 2.12.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add checks for atomic_[duplicate/destroy]_state with atomic drivers
On Thu, May 24, 2018, 9:26 PM Haneen Mohammed
wrote:
> This patch add checks for atomic_[duplicate/destroy]_state of
> drm_[connector/crtc/plane]_funcs for atomic drivers in the relevant
> drm_*_init functions since these callback are mandatory for atomic drivers.
>
> Update the kerneldoc comments for those callbacks.
>
> Signed-off-by: Haneen Mohammed
>
Reviewed-by: Sean Paul
---
> drivers/gpu/drm/drm_connector.c | 4
> drivers/gpu/drm/drm_crtc.c | 4
> drivers/gpu/drm/drm_plane.c | 4
> include/drm/drm_connector.h | 4
> include/drm/drm_crtc.h | 4
> include/drm/drm_plane.h | 4
> 6 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c
> b/drivers/gpu/drm/drm_connector.c
> index b3cde897cd80..ab291f4f339a 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -195,6 +195,10 @@ int drm_connector_init(struct drm_device *dev,
> struct ida *connector_ida =
> &drm_connector_enum_list[connector_type].ida;
>
> + WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
> + (!funcs->atomic_destroy_state ||
> +!funcs->atomic_duplicate_state));
> +
> ret = __drm_mode_object_add(dev, &connector->base,
> DRM_MODE_OBJECT_CONNECTOR,
> false, drm_connector_free);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 03583887cfec..d1933c5f2524 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -286,6 +286,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> struct drm_crtc *crtc,
> if (WARN_ON(config->num_crtc >= 32))
> return -EINVAL;
>
> + WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
> + (!funcs->atomic_destroy_state ||
> +!funcs->atomic_duplicate_state));
> +
> crtc->dev = dev;
> crtc->funcs = funcs;
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 6d2a6e428a3e..e0efb06eec31 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -177,6 +177,10 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> if (WARN_ON(config->num_total_plane >= 32))
> return -EINVAL;
>
> + WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
> + (!funcs->atomic_destroy_state ||
> +!funcs->atomic_duplicate_state));
> +
> ret = drm_mode_object_add(dev, &plane->base,
> DRM_MODE_OBJECT_PLANE);
> if (ret)
> return ret;
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 675cc3f8cf85..65b6c86ecd50 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -608,6 +608,8 @@ struct drm_connector_funcs {
> * cleaned up by calling the @atomic_destroy_state hook in this
> * structure.
> *
> +* This callback is mandatory for atomic drivers.
> +*
> * Atomic drivers which don't subclass &struct drm_connector_state
> should use
> * drm_atomic_helper_connector_duplicate_state(). Drivers that
> subclass the
> * state structure to extend it with driver-private state should
> use
> @@ -634,6 +636,8 @@ struct drm_connector_funcs {
> *
> * Destroy a state duplicated with @atomic_duplicate_state and
> release
> * or unreference all resources it references
> +*
> +* This callback is mandatory for atomic drivers.
> */
> void (*atomic_destroy_state)(struct drm_connector *connector,
> struct drm_connector_state *state);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a2d81d2907a9..26511d6775d7 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -503,6 +503,8 @@ struct drm_crtc_funcs {
> * cleaned up by calling the @atomic_destroy_state hook in this
> * structure.
> *
> +* This callback is mandatory for atomic drivers.
> +*
> * Atomic drivers which don't subclass &struct drm_crtc_state
> should use
> * drm_atomic_helper_crtc_duplicate_state(). Drivers that subclass
> the
> * state structure to extend it with driver-private state should
> use
> @@ -529,6 +531,8 @@ struct drm_crtc_funcs {
> *
> * Destroy a state duplicated with @atomic_duplicate_state and
> release
> * or unreference all resources it references
> +*
> +* This callback is mandatory for atomic drivers.
> */
> void (*atomic_destroy_state)(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index f7bf4a48b1c3..d6d68b466649 100644
> --- a/include/drm/drm
Re: [DPU PATCH v3] drm/msm: Use atomic private_obj instead of subclassing
On 2018-03-20 04:01, Archit Taneja wrote:
Hi,
On Tuesday 20 March 2018 01:28 AM, Sean Paul wrote:
Instead of subclassing atomic state, store driver private data in
private_obj/state. This allows us to remove the swap_state driver hook
for mdp5 and get closer to using the atomic helpers entirely.
Changes in v2:
- Use state->state in disp duplicate_state callback (Jeykumar)
Changes in v3:
- Update comment describing msm_kms_state (Jeykumar)
One difference w.r.t the patchset
"drm/msm/mdp5: Use the new private_obj state" is that this
adds the atomic private_obj for all kms backends, whereas the one
I'd done originally just added it for mdp5, so this patch set
is better in that respect.
The other difference is how we 'get' the private state. In this patch,
the helper drm_atomic_get_private_obj_state() is used every time to
get the private object state.
I'd tried to do the same initially, but I noticed that
drm_atomic_get_private_obj_state() doesn't return the correct
state post swapping of states. So, instead of relying on the helper,
I created a helper called mdp5_get_existing_global_state() that
returns the desired state(the state pointer in
msm_kms>state->base.state
in this patch) in all funcs that are called post-swap.
You could read about the issue on the the thread: "[RFC 1/3]
drm/msm/mdp5: Add global state as a private atomic object"
The problem was quite apparent with db410c, where SMP blocks are
assigned to planes. If the latest SMP state isn't referred when
configuring SMP registers, we see underruns immediately.
An easy way to reproduce this is to use modset on db410c. I think
it might occur with this patch too. It might be worth trying it
out.
Thanks,
Archit
Hello Archit, Now that I am trying to use the private obj to maintain
resource pool in DPU, I realize the need for retrieving existing / new
state API's. Don't you think this support is missing in the DRM core
fwk, considering how drm_atomic_get_existing__state,
drm_atomic_get_old__state, drm_atomic_get_new__state API's are
available for CRTC/PLANE and CONNECTORS but not for private_obj's?
Thanks,
Jeykumar S.
Cc: Jeykumar Sankaran
Reviewed-by: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 37 ++
drivers/gpu/drm/msm/msm_atomic.c | 30 ---
drivers/gpu/drm/msm/msm_drv.c| 65
++--
drivers/gpu/drm/msm/msm_drv.h| 4 +-
drivers/gpu/drm/msm/msm_kms.h| 27 +-
5 files changed, 94 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 6d8e3a9a6fc0..f1a248419655 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -74,36 +74,32 @@ struct mdp5_state *mdp5_get_state(struct
drm_atomic_state *s)
{
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
- struct msm_kms_state *state = to_kms_state(s);
- struct mdp5_state *new_state;
+ struct msm_kms_state *kms_state;
int ret;
- if (state->state)
- return state->state;
-
ret = drm_modeset_lock(&mdp5_kms->state_lock, s->acquire_ctx);
if (ret)
return ERR_PTR(ret);
- new_state = kmalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);
- if (!new_state)
- return ERR_PTR(-ENOMEM);
+ kms_state = msm_kms_get_state(s);
+ if (IS_ERR_OR_NULL(kms_state))
+ return (struct mdp5_state *)kms_state; /* casting ERR_PTR */
- /* Copy state: */
- new_state->hwpipe = mdp5_kms->state->hwpipe;
- new_state->hwmixer = mdp5_kms->state->hwmixer;
- if (mdp5_kms->smp)
- new_state->smp = mdp5_kms->state->smp;
+ return kms_state->state;
+}
- state->state = new_state;
+static void *mdp5_duplicate_state(void *state)
+{
+ if (!state)
+ return kzalloc(sizeof(struct mdp5_state), GFP_KERNEL);
- return new_state;
+ return kmemdup(state, sizeof(struct mdp5_state), GFP_KERNEL);
}
-static void mdp5_swap_state(struct msm_kms *kms, struct
drm_atomic_state *state)
+static void mdp5_destroy_state(void *state)
{
- struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
- swap(to_kms_state(state)->state, mdp5_kms->state);
+ struct mdp5_state *mdp_state = state;
+ kfree(mdp_state);
}
static void mdp5_prepare_commit(struct msm_kms *kms, struct
drm_atomic_state *state)
@@ -229,7 +225,8 @@ static const struct mdp_kms_funcs kms_funcs = {
.irq = mdp5_irq,
.enable_vblank = mdp5_enable_vblank,
.disable_vblank = mdp5_disable_vblank,
- .swap_state = mdp5_swap_state,
+ .duplicate_state = mdp5_duplicate_state,
+ .destroy_sta
[PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed
From: Sandy Huang The vop irq is shared between vop and iommu and irq probing in the iommu driver moved to the probe function recently. This can in some cases lead to a stall if the irq is triggered while the vop driver still has it disabled. But there is no real need to disable the irq, as the vop can simply also track its enabled state and ignore irqs in that case. So remove the enable/disable handling and add appropriate condition to the irq handler. Signed-off-by: Sandy Huang [added an actual commit message] Signed-off-by: Heiko Stuebner --- Hi Ezequiel, this patch came from a discussion I had with Rockchip people over the iommu changes and resulting issues back in april, but somehow was forgotten and not posted to the lists. Correcting that now. So removing the enable/disable voodoo on the shared interrupt is the preferred way. drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 ++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index 510cdf0..61493d4 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -549,8 +549,6 @@ static int vop_enable(struct drm_crtc *crtc) spin_unlock(&vop->reg_lock); - enable_irq(vop->irq); - drm_crtc_vblank_on(crtc); return 0; @@ -596,8 +594,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc, vop_dsp_hold_valid_irq_disable(vop); - disable_irq(vop->irq); - vop->is_enabled = false; /* @@ -1168,6 +1164,13 @@ static irqreturn_t vop_isr(int irq, void *data) int ret = IRQ_NONE; /* +* since the irq is shared with iommu, iommu irq is enabled before vop +* enable, so before vop enable we do nothing. +*/ + if (!vop->is_enabled) + return IRQ_NONE; + + /* * interrupt register has interrupt status, enable and clear bits, we * must hold irq_lock to avoid a race with enable/disable_vblank(). */ @@ -1586,9 +1588,6 @@ static int vop_bind(struct device *dev, struct device *master, void *data) if (ret) goto err_disable_pm_runtime; - /* IRQ is initially disabled; it gets enabled in power_on */ - disable_irq(vop->irq); - return 0; err_disable_pm_runtime: -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
On Thu, May 24, 2018 at 1:50 AM, Maxime Ripard
wrote:
> On Mon, May 21, 2018 at 07:27:46PM +0200, Jernej Škrabec wrote:
>> Hi,
>>
>> Dne ponedeljek, 21. maj 2018 ob 10:07:59 CEST je Maxime Ripard napisal(a):
>> > On Sat, May 19, 2018 at 08:31:18PM +0200, Jernej Skrabec wrote:
>> > > If SoC has TCON TOP unit, it has to be configured from TCON, since it
>> > > has all information needed. Additionally, if it is TCON TV, it must also
>> > > enable bus gate inside TCON TOP unit.
>> >
>> > Why?
>>
>> I'll explain my design decision below.
>>
>> >
>> > > Add support for such TCONs.
>> > >
>> > > Signed-off-by: Jernej Skrabec
>> > > ---
>> > >
>> > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 28
>> > > drivers/gpu/drm/sun4i/sun4i_tcon.h | 8
>> > > 2 files changed, 36 insertions(+)
>> > >
>> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..e0c562ce1c22
>> > > 100644
>> > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
>> > > *dev,
>> > >
>> > > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> > > return PTR_ERR(tcon->clk);
>> > >
>> > > }
>> > >
>> > > +
>> > > + if (tcon->quirks->needs_tcon_top && tcon->quirks->has_channel_1) {
>> > > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> > > + if (IS_ERR(tcon->top_clk)) {
>> > > + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
>> > > + return PTR_ERR(tcon->top_clk);
>> > > + }
>> > > + clk_prepare_enable(tcon->top_clk);
>> > > + }
>> > > +
>> > >
>> > > clk_prepare_enable(tcon->clk);
>> > >
>> > > if (tcon->quirks->has_channel_0) {
>> > >
>> > > @@ -712,6 +722,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
>> > >
>> > > static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
>> > > {
>> > >
>> > > clk_disable_unprepare(tcon->clk);
>> > >
>> > > + clk_disable_unprepare(tcon->top_clk);
>> > >
>> > > }
>> > >
>> > > static int sun4i_tcon_init_irq(struct device *dev,
>> > >
>> > > @@ -980,6 +991,23 @@ static int sun4i_tcon_bind(struct device *dev,
>> > > struct
>> > > device *master,>
>> > > tcon->id = engine->id;
>> > > tcon->quirks = of_device_get_match_data(dev);
>> > >
>> > > + if (tcon->quirks->needs_tcon_top) {
>> > > + struct device_node *np;
>> > > +
>> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top", 0);
>> > > + if (np) {
>> > > + struct platform_device *pdev;
>> > > +
>> > > + pdev = of_find_device_by_node(np);
>> > > + if (pdev)
>> > > + tcon->tcon_top = platform_get_drvdata(pdev);
>> > > + of_node_put(np);
>> > > +
>> > > + if (!tcon->tcon_top)
>> > > + return -EPROBE_DEFER;
>> > > + }
>> > > + }
>> > > +
>> >
>> > I might have missed it, but I've not seen the bindings additions for
>> > that property. This shouldn't really be done that way anyway, instead
>> > of using a direct phandle, you should be using the of-graph, with the
>> > TCON-top sitting where it belongs in the flow of data.
>>
>> Just to answer to the first question, it did describe it in "[PATCH 07/15]
>> dt-
>> bindings: display: sun4i-drm: Add R40 HDMI pipeline".
>>
>> As why I designed it that way - HW representation could be described that way
>> (ASCII art makes sense when fixed width font is used to view it):
>>
>> / LCD0/LVDS0
>> / TCON-LCD0
>> | \ MIPI DSI
>> mixer0 |
>>\/ TCON-LCD1 - LCD1/LVDS1
>> TCON-TOP
>>/\ TCON-TV0 - TVE0/RGB
>> mixer1 | \
>> | TCON-TOP - HDMI
>> | /
>> \ TCON-TV1 - TVE1/RGB
>>
>> This is a bit simplified, since there is also TVE-TOP, which is responsible
>> for sharing 4 DACs between both TVE encoders. You can have two TV outs (PAL/
>> NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even seems that you
>> can arbitrarly choose which DAC is responsible for which signal, so there is
>> a
>> ton of possible end combinations, but I'm not 100% sure.
>>
>> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
>> suggest more possibilities, although some of them seem wrong, like RGB
>> feeding
>> from LCD TCON. That is confirmed to be wrong when checking BSP code.
>>
>> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and LCD1
>> for
>> pin muxing, although I'm not sure why is that needed at all, since according
>> to R40 datasheet, TVE0 and TVE1 pins are dedicated and not on PORT D and PORT
>> H, respectively, as TCON-TOP documentation suggest. However, HSYNC and PSYNC
>> lines might be shared betw
[Bug 106441] Totem video playback stuttering and graphical artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=106441 --- Comment #5 from Richard B. Kreckel --- It must be Xorg. I've upgradee to Xorg 1.20 (without upgrading anything else) from Debian/experimental and this problem has disappeared for good. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106430] GPU hang when played video with acceleration (vaapi)
https://bugs.freedesktop.org/show_bug.cgi?id=106430 --- Comment #3 from mikhail.v.gavri...@gmail.com --- A very strange coincidence: Every time I reproduce the described bug case with GPU hangup while playing a video with VAAPI acceleration. The following messages will appear in the kernel log after reboot: [0.059000] mce: [Hardware Error]: Machine check events logged [0.059000] mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: fe800400 [0.059000] mce: [Hardware Error]: TSC 0 ADDR c07f31d5 MISC c07f31d5 [0.059000] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1527195880 SOCKET 0 APIC 0 microcode 24 [0.059000] Performance Events: PEBS fmt2+, Haswell events, 16-deep LBR, full-width counters, Intel PMU driver. [0.059000] ... version:3 [0.059000] ... bit width: 48 [0.059000] ... generic registers: 4 [0.059000] ... value mask: [0.059000] ... max period: 7fff [0.059000] ... fixed-purpose events: 3 [0.059000] ... event mask: 0007000f [0.059000] Hierarchical SRCU implementation. [0.059692] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter. [0.059740] smp: Bringing up secondary CPUs ... [0.060031] x86: Booting SMP configuration: [0.060035] node #0, CPUs: #1 [0.061563] mce: [Hardware Error]: Machine check events logged [0.061567] mce: [Hardware Error]: CPU 1: Machine Check: 0 Bank 3: be800400 [0.061583] mce: [Hardware Error]: TSC 0 ADDR 957932bb MISC 957932bb [0.061602] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1527195880 SOCKET 0 APIC 2 microcode 24 [0.061684] #2 [0.063341] mce: [Hardware Error]: CPU 2: Machine Check: 0 Bank 3: be800400 [0.063341] mce: [Hardware Error]: TSC 0 ADDR c02bd4e1 MISC c02bd4e1 [0.063341] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1527195880 SOCKET 0 APIC 4 microcode 24 [0.063471] #3 [0.065119] mce: [Hardware Error]: CPU 3: Machine Check: 0 Bank 3: be800400 [0.065125] mce: [Hardware Error]: TSC 0 ADDR c07f31d5 MISC c07f31d5 [0.065144] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1527195880 SOCKET 0 APIC 6 microcode 24 [0.065255] #4 #5 #6 #7 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106631] PALM: clpeak: Bus error (core dumped) & lots of GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=106631 --- Comment #10 from Jan Vesely --- (In reply to Ricardo Ribalda from comment #9) > (In reply to Ricardo Ribalda from comment #8) > > I am using llvm/clang from https://github.com/kraj/meta-clang . Can you > > point me to something to check if the debug mode is enabled or not? > > > > Thanks > > Answer to myself. Seems to be a Release build : > https://github.com/kraj/meta-clang/blob/master/recipes-devtools/clang/ > clang_git.bb#L78 > > But if you can tell me how to verify it in runtime I would love to try it $ llvm-config --assertion-mode and $ llvm-config --build-mode this won't change the GPU kernel running time, but it might speed up the kernel compilation time. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?
https://bugs.freedesktop.org/show_bug.cgi?id=106519 --- Comment #20 from mikhail.v.gavri...@gmail.com --- (In reply to Alex Deucher from comment #18) > > H.264 works fine. Not sure what's happening with your system. It turns out I was running the old version of mpv and not the new one which was advised build from the master branch. Now I see that acceleration work from verbose output. But now I able reproduce issue https://bugs.freedesktop.org/show_bug.cgi?id=106430 also in mpv player which first I met in Totem player when install gstreamer1-vaapi package for first time. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106597] [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3
https://bugs.freedesktop.org/show_bug.cgi?id=106597
Lukas Wunner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #34 from Lukas Wunner ---
Fixed with commit 009f8c90f571 ("ALSA: hda - Fix runtime PM") which is now
queued for 4.17-rc7:
https://git.kernel.org/tiwai/sound/c/009f8c90f571
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
https://bugzilla.kernel.org/show_bug.cgi?id=199425 --- Comment #6 from mikita.lip...@amd.com (mikita.lip...@amd.com) --- Created attachment 276173 --> https://bugzilla.kernel.org/attachment.cgi?id=276173&action=edit Patch to either dublicate or reuse an existing crtc state that might pervent use-after-free error in race condition Sorry, the previous patch is irrelevant and was attached by mistake! Please try the one above. Thanks -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106517] IGT commit rights
https://bugs.freedesktop.org/show_bug.cgi?id=106517 --- Comment #4 from Dhinakaran Pandiyan --- (In reply to arkadiusz.hi...@intel.com from comment #3) > Hey, > > Is this request for an freedesktop account at the same time? Because you > need one to get the commit rights. Yeah. > > Here's the guide to follow: https://www.freedesktop.org/wiki/AccountRequests/ I did follow that, I probably should have added that I need an account as well. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: Consistently use octal not symbolic permissions
There is currently a mixture of octal and symbolic permissions uses
in files in drivers/gpu/drm and one file in drivers/gpu.
There are ~270 existing octal uses and ~115 S_ uses.
Convert all the S_ symbolic permissions to their octal equivalents
as using octal and not symbolic permissions is preferred by many as more
readable.
see: https://lkml.org/lkml/2016/8/2/1945
Done with automated conversion via:
$ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace
Miscellanea:
o Wrapped modified multi-line calls to a single line where appropriate
o Realign modified multi-line calls to open parenthesis
o drivers/gpu/drm/msm/adreno/a5xx_debugfs.c has a world-writeable
debug permission for "reset" - perhaps that should be modified
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 98 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 9 +-
drivers/gpu/drm/armada/armada_debugfs.c| 4 +-
drivers/gpu/drm/drm_debugfs.c | 6 +-
drivers/gpu/drm/drm_debugfs_crc.c | 4 +-
drivers/gpu/drm/drm_sysfs.c| 2 +-
drivers/gpu/drm/i915/gvt/firmware.c| 2 +-
drivers/gpu/drm/i915/i915_debugfs.c| 8 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_sysfs.c | 22 ++---
drivers/gpu/drm/i915/intel_pipe_crc.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 5 +-
drivers/gpu/drm/msm/msm_perf.c | 4 +-
drivers/gpu/drm/msm/msm_rd.c | 4 +-
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c| 11 ++-
.../drm/omapdrm/displays/panel-sony-acx565akm.c| 6 +-
.../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 10 +--
drivers/gpu/drm/radeon/radeon_pm.c | 26 +++---
drivers/gpu/drm/radeon/radeon_ttm.c| 4 +-
drivers/gpu/drm/sti/sti_drv.c | 2 +-
drivers/gpu/drm/tinydrm/mipi-dbi.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
drivers/gpu/drm/ttm/ttm_memory.c | 12 +--
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 6 +-
drivers/gpu/drm/udl/udl_fb.c | 4 +-
drivers/gpu/host1x/debug.c | 12 +--
30 files changed, 138 insertions(+), 146 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index f5fb93795a69..7b29febff511 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -830,7 +830,7 @@ int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
for (i = 0; i < ARRAY_SIZE(debugfs_regs); i++) {
ent = debugfs_create_file(debugfs_regs_names[i],
- S_IFREG | S_IRUGO, root,
+ S_IFREG | 0444, root,
adev, debugfs_regs[i]);
if (IS_ERR(ent)) {
for (j = 0; j < i; j++) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b455da487782..fa55d7e9e784 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -905,39 +905,39 @@ static ssize_t amdgpu_set_pp_power_profile_mode(struct
device *dev,
return -EINVAL;
}
-static DEVICE_ATTR(power_dpm_state, S_IRUGO | S_IWUSR, amdgpu_get_dpm_state,
amdgpu_set_dpm_state);
-static DEVICE_ATTR(power_dpm_force_performance_level, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(power_dpm_state, 0644, amdgpu_get_dpm_state,
amdgpu_set_dpm_state);
+static DEVICE_ATTR(power_dpm_force_performance_level, 0644,
amdgpu_get_dpm_forced_performance_level,
amdgpu_set_dpm_forced_performance_level);
-static DEVICE_ATTR(pp_num_states, S_IRUGO, amdgpu_get_pp_num_states, NULL);
-static DEVICE_ATTR(pp_cur_state, S_IRUGO, amdgpu_get_pp_cur_state, NULL);
-static DEVICE_ATTR(pp_force_state, S_IRUGO | S_IWUSR,
- amdgpu_get_pp_force_state,
- amdgpu_set_pp_force_state);
-static DEVICE_ATTR(pp_table, S_IRUGO | S_IWUSR,
- amdgpu_get_pp_table,
- amdgpu_set_pp_table);
-static DEVICE_ATTR(pp_dpm_sclk, S_IRUGO | S_IWUSR,
- amdgpu_get_pp_dpm_sclk,
- amdgpu_set_pp_dpm_sclk);
-static DEVICE_ATTR(pp_dpm_mclk, S_IRUGO | S_IWUSR,
- amdgpu_get_pp_dpm_mclk,
- amdgpu_set_pp_dpm_mclk);
-static DEVICE_ATTR(pp_dpm_pcie, S_IRUGO | S_IWUSR,
- amdgpu_get_pp_dpm_pcie,
- amdgpu_set_pp_dpm_pc
[PATCH] drm/edid: Fix up edid_cea_modes[] formatting
From: Ville Syrjälä
Fix up a bunch of bad indentation and insconsistent comments
in edid_cea_modes[].
v2: Instead of stripping the aspect ratio comments let's
add them to all modes
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 268 ++---
1 file changed, 134 insertions(+), 134 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 82f1ab09169d..634a68a03b07 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -687,562 +687,562 @@ static const struct minimode extra_modes[] = {
static const struct drm_display_mode edid_cea_modes[] = {
/* 0 - dummy, VICs start at 1 */
{ },
- /* 1 - 640x480@60Hz */
+ /* 1 - 640x480@60Hz 4:3 */
{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
752, 800, 0, 480, 490, 492, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 2 - 720x480@60Hz */
+ /* 2 - 720x480@60Hz 4:3 */
{ DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000, 720, 736,
798, 858, 0, 480, 489, 495, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 3 - 720x480@60Hz */
+ /* 3 - 720x480@60Hz 16:9 */
{ DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000, 720, 736,
798, 858, 0, 480, 489, 495, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 4 - 1280x720@60Hz */
+ /* 4 - 1280x720@60Hz 16:9 */
{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
1430, 1650, 0, 720, 725, 730, 750, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 5 - 1920x1080i@60Hz */
+ /* 5 - 1920x1080i@60Hz 16:9 */
{ DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
2052, 2200, 0, 1080, 1084, 1094, 1125, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
- DRM_MODE_FLAG_INTERLACE),
+ DRM_MODE_FLAG_INTERLACE),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 6 - 720(1440)x480i@60Hz */
+ /* 6 - 720(1440)x480i@60Hz 4:3 */
{ DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
801, 858, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
- DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
+ DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 7 - 720(1440)x480i@60Hz */
+ /* 7 - 720(1440)x480i@60Hz 16:9 */
{ DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
801, 858, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
- DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
+ DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 8 - 720(1440)x240@60Hz */
+ /* 8 - 720(1440)x240@60Hz 4:3 */
{ DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
801, 858, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
- DRM_MODE_FLAG_DBLCLK),
+ DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 9 - 720(1440)x240@60Hz */
+ /* 9 - 720(1440)x240@60Hz 16:9 */
{ DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
801, 858, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
- DRM_MODE_FLAG_DBLCLK),
+ DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 10 - 2880x480i@60Hz */
+ /* 10 - 2880x480i@60Hz 4:3 */
{ DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
3204, 3432, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
- DRM_MODE_FLAG_INTERLACE),
+ DRM_MODE_FLAG_INTERLACE),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 11 - 2880x480i@60Hz */
+ /* 11 - 2880x480i@60Hz 16:9 */
{ DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
3204, 3432, 0, 480, 488, 494, 525, 0,
[RFC PATCH radeon-alex] drm/amdgpu: vcn_v1_0_is_idle() can be static
Fixes: 9b4c412a654c ("drm/amdgpu: Add static CG control for VCN on RV")
Signed-off-by: kbuild test robot
---
vcn_v1_0.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index 7a366418..2b4a789 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -686,14 +686,14 @@ static int vcn_v1_0_stop(struct amdgpu_device *adev)
return 0;
}
-bool vcn_v1_0_is_idle(void *handle)
+static bool vcn_v1_0_is_idle(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
return (RREG32_SOC15(VCN, 0, mmUVD_STATUS) == 0x2);
}
-int vcn_v1_0_wait_for_idle(void *handle)
+static int vcn_v1_0_wait_for_idle(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
int ret = 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-4.18-wip 114/129] drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c:689:6: sparse: symbol 'vcn_v1_0_is_idle' was not declared. Should it be static?
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip head: 27bd044dd054fed87166c831b6d38bc609e733cc commit: 9b4c412a654ce71ad0e81044d3300677a7668ac8 [114/129] drm/amdgpu: Add static CG control for VCN on RV reproduce: # apt-get install sparse git checkout 9b4c412a654ce71ad0e81044d3300677a7668ac8 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c:689:6: sparse: symbol >> 'vcn_v1_0_is_idle' was not declared. Should it be static? >> drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c:696:5: sparse: symbol >> 'vcn_v1_0_wait_for_idle' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
https://bugzilla.kernel.org/show_bug.cgi?id=199425 --- Comment #5 from mikita.lip...@amd.com (mikita.lip...@amd.com) --- Created attachment 276171 --> https://bugzilla.kernel.org/attachment.cgi?id=276171&action=edit Patch to either dublicate or reuse an existing crtc state that might pervent use-after-free error in race condition I wasn't able to reproduce the issue, but could you please try applying this patch and seeing if does any difference? Also could add a dmesg log with drm.debug=0x6 to see whats the chain of events that caused the issue Thanks -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI
https://bugs.freedesktop.org/show_bug.cgi?id=106548 --- Comment #7 from Francesco Balestrieri --- Created attachment 139741 --> https://bugs.freedesktop.org/attachment.cgi?id=139741&action=edit DMESG output Kernel logs -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106631] PALM: clpeak: Bus error (core dumped) & lots of GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=106631 --- Comment #9 from Ricardo Ribalda --- (In reply to Ricardo Ribalda from comment #8) > I am using llvm/clang from https://github.com/kraj/meta-clang . Can you > point me to something to check if the debug mode is enabled or not? > > Thanks Answer to myself. Seems to be a Release build : https://github.com/kraj/meta-clang/blob/master/recipes-devtools/clang/clang_git.bb#L78 But if you can tell me how to verify it in runtime I would love to try it -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106631] PALM: clpeak: Bus error (core dumped) & lots of GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=106631 --- Comment #8 from Ricardo Ribalda --- I am using llvm/clang from https://github.com/kraj/meta-clang . Can you point me to something to check if the debug mode is enabled or not? Thanks -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106631] PALM: clpeak: Bus error (core dumped) & lots of GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=106631 --- Comment #7 from Jan Vesely --- It looks like even 100s is not enough. Can you try running with no time limit? (set to 0). Looking at the numbers I think mesa's results are inflated by the kernel getting killed before finishing the computation. Looking at the numbers it can take significantly longer. Did you by any chance build llvm in debug mode? that can inflate kernel compile times significantly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106597] [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3
https://bugs.freedesktop.org/show_bug.cgi?id=106597 --- Comment #33 from taij...@posteo.de --- (In reply to Alex Deucher from comment #32) > (In reply to taijian from comment #30) > > Created attachment 139739 [details] [review] [review] > > patch that seems to fix things for me > > > > OK, going with Lukas' discovery, I have rebuild my kernel from > > drm-next-4.18-wip, applying the attached patch, reversing the atpx quirk > > discussed earlier, and also applying the debug patch (dmesg comes in the > > next post). > > > > And voilà: It seems to be fixed, AFAIK! YAY! > > Just to be clear, it works fine without the ATPX quirk if you apply the HDA > fix? Should I revert the ATPX quirk? Yes, as you suggested earlier in the thread, I reversed the atpx quirk patch when applying the hda fix, just to see if you were right that Lukas' vga_switcheroo work made that obsolete. And from my testing it does seem to be obsolete, so if no one else is objecting, please feel free to revert it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm/panel: Add support for Truly NT35597 panel
On Wed, May 23, 2018 at 06:44:00PM -0700, Abhinav Kumar wrote:
> Add support for Truly NT35597 panel used
> in MSM reference platforms.
>
> This panel supports both single DSI and dual DSI
> modes.
>
> However, this patch series adds support only for
> dual DSI mode.
>
> Changes in v3:
> - Changes to commit text
> - Separated the documentation from the driver itself
> - Improved the documentation to cover the port information
> - Formatting fixes and changes in delays in panel sequences
> - Cleaned up probe function
>
> Signed-off-by: Archit Taneja
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/panel/Kconfig | 8 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 588
>
> 3 files changed, 597 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 25682ff..2fcd9b1 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -177,4 +177,12 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TRULY_NT35597_WQXGA
> + tristate "Truly WQXGA"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> + help
> + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> DSI
> + Video Mode panel
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index f26efc1..056ea93 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> new file mode 100644
> index 000..529086b
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> @@ -0,0 +1,588 @@
> +// SPDX-License-Identifier: GPL-2.0
I know I prefer
/* SPDX-License-Identifier: GPL-2.0 */
but I haven't seen a definitive rulling one way or the other.
> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
One of the points of the SPDX tag is that you don't need to print the text of
the license anymore - just add the tag and the copyright notice.
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const char * const regulator_names[] = {
> + "vdda",
> + "vdispp",
> + "vdispn"
> +};
> +
> +static unsigned long regulator_enable_loads[] = {
> + 62000,
> + 10,
> + 10
Missing a comma after the last entry. These should be const if you can make them
so.
> +};
> +
> +static unsigned long regulator_disable_loads[] = {
> + 80,
> + 100,
> + 100
Same.
> +};
> +
> +struct truly_wqxga {
> + struct device *dev;
> + struct drm_panel panel;
> +
> + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *mode_gpio;
> +
> + struct backlight_device *backlight;
> + struct videomode vm;
> +
> + struct mipi_dsi_device *dsi[2];
> +
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline struct truly_wqxga *panel_to_truly_wqxga(struct drm_panel
> *panel)
> +{
> + return container_of(panel, struct truly_wqxga, panel);
> +}
Personal preference for me is to make these a macro since they take up less
space, but I'll leave the final decision to the maintainer.
> +static int truly_wqxga_power_on(struct truly_wqxga *ctx)
> +{
> + int ret, i;
> +
> + for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
> + ret = regulator_set_load(ctx->supplies[i].consumer,
> + regulator_enable_loads[i]);
> + if (ret)
> + return ret;
> + }
> *
> + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> + if (ret < 0)
> + re
[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?
https://bugs.freedesktop.org/show_bug.cgi?id=106519 --- Comment #19 from mikhail.v.gavri...@gmail.com --- (In reply to Alex Deucher from comment #18) > H.264 works fine. Not sure what's happening with your system. Which info needed? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106597] [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3
https://bugs.freedesktop.org/show_bug.cgi?id=106597 --- Comment #32 from Alex Deucher --- (In reply to taijian from comment #30) > Created attachment 139739 [details] [review] > patch that seems to fix things for me > > OK, going with Lukas' discovery, I have rebuild my kernel from > drm-next-4.18-wip, applying the attached patch, reversing the atpx quirk > discussed earlier, and also applying the debug patch (dmesg comes in the > next post). > > And voilà: It seems to be fixed, AFAIK! YAY! Just to be clear, it works fine without the ATPX quirk if you apply the HDA fix? Should I revert the ATPX quirk? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?
https://bugs.freedesktop.org/show_bug.cgi?id=106519 --- Comment #18 from Alex Deucher --- (In reply to mikhail.v.gavrilov from comment #17) > (In reply to Alex Deucher from comment #16) > > vega10 does not support VP9. > Here https://www.phoronix.com/scan.php?page=news_item&px=AMD-VP9-VAAPI-VCN > I am here that AMD Posts VP9 VA-API Video Acceleration For Gallium3D this is > > lie? > VP9 is supported on Raven. > > Anyway H264 should work, right? > Here in mpv issue tracker mention that vaapi for AMD is so buggy: > https://github.com/mpv-player/mpv/issues/5852#issuecomment-391785043 > > > It possible to fix? H.264 works fine. Not sure what's happening with your system. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?
https://bugs.freedesktop.org/show_bug.cgi?id=106519 --- Comment #17 from mikhail.v.gavri...@gmail.com --- (In reply to Alex Deucher from comment #16) > vega10 does not support VP9. Here https://www.phoronix.com/scan.php?page=news_item&px=AMD-VP9-VAAPI-VCN I am here that AMD Posts VP9 VA-API Video Acceleration For Gallium3D this is lie? Anyway H264 should work, right? Here in mpv issue tracker mention that vaapi for AMD is so buggy: https://github.com/mpv-player/mpv/issues/5852#issuecomment-391785043 It possible to fix? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 3/3] amdgpu: Destroy fd_hash table when the last device is removed.
On Fri, 2018-05-18 at 13:00 -0400, Jan Vesely wrote:
> Fixes memory leak on module unload.
> Analogous to mesa commit of the same name.
> Signed-off-by: Jan Vesely
> ---
> amdgpu/amdgpu_device.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
> index e23dd3b3..34ac95b8 100644
> --- a/amdgpu/amdgpu_device.c
> +++ b/amdgpu/amdgpu_device.c
> @@ -128,6 +128,10 @@ static void
> amdgpu_device_free_internal(amdgpu_device_handle dev)
> {
> pthread_mutex_lock(&fd_mutex);
> util_hash_table_remove(fd_tab, UINT_TO_PTR(dev->fd));
> + if (util_hash_table_count(fd_tab) == 0) {
> + util_hash_table_destroy(fd_tab);
> + fd_tab = NULL;
> + }
> close(dev->fd);
> if ((dev->flink_fd >= 0) && (dev->fd != dev->flink_fd))
> close(dev->flink_fd);
gentle ping.
Jan
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm: Begin an API for in-kernel clients
On 05/24/2018 12:14 PM, Daniel Vetter wrote: On Thu, May 24, 2018 at 11:25:04AM +0200, Thomas Hellstrom wrote: On 05/24/2018 10:32 AM, Daniel Vetter wrote: On Wed, May 23, 2018 at 11:45:00PM +0200, Thomas Hellstrom wrote: Hi, Noralf. A couple of issues below: On 05/23/2018 04:34 PM, Noralf Trønnes wrote: This the beginning of an API for in-kernel clients. First out is a way to get a framebuffer backed by a dumb buffer. Only GEM drivers are supported. The original idea of using an exported dma-buf was dropped because it also creates an anonomous file descriptor which doesn't work when the buffer is created from a kernel thread. The easy way out is to use drm_driver.gem_prime_vmap to get the virtual address, which requires a GEM object. This excludes the vmwgfx driver which is the only non-GEM driver apart from the legacy ones. A solution for vmwgfx will have to be worked out later if it wants to support the client API which it probably will when we have a bootsplash client. Couldn't you add vmap() and vunmap() to the dumb buffer API for in-kernel use rather than using GEM directly? But the main issue is pinning. It looks like the buffers are going to be vmapped() for a long time, which requires pinning, and that doesn't work for some drivers when they bind the framebuffer to a plane, since that might require pinning in another memory region and the vmap would have to be torn down. Besides, buffer pinning should really be avoided if possible: Since we can't page-fault vmaps, and setting up / tearing down vmaps is potentially an expensive operation, could we perhaps have a mapping api that allows the driver to cache vmaps? vmap() // Indicates that we want to map a bo begin_access() // Returns a virtual address which may vary between calls. Allows access. A fast operation. Behind the lines pins / reserves the bo and returns a cached vmap if the bo didn't move since last begin_access(), which is the typical case. end_access() // Disable access. Unpins / unreserves the bo. vunmap_cached() //Indicates that the map is no longer needed. The driver can release the cached map. The idea is that the API client would wrap all bo map accesses with begin_access() end_access(), allowing for the bo to be moved in between. So originally my ideas for the cpu side dma-buf interfaces where all meant to handle this. But then the first implementations bothered with none of this, but instead expected that stuff is pinned, and vmap Just Works. Which yeah doesn't work for vmwgfx and is a pain in a few other cases. I agree it'd be nice to fix all this, but it's also not a problem that this patch set here started. And since it's all optional (and vmwgfx isn't even using the current fb helper code) I think it's reasonable to address this post-merge (if someone gets around to it ever). What we'd need is is a fallback for when vmap doesn't exist (for fbdev that probably means a vmalloc'ed buffer + manual uploads, because fbdev), plus making sure dma-buf implementations actually implement it. My argument here is that, If I understand Noralf, this is intended to be an API exported outside of drm. In that case we shouldn't replicate the assumed behaviour of incomplete dma-buf implementations in a new API. Also the fact that vmwgfx currently isn't using the fbdev helpers isn't a good argument to design an API so that vmwgfx can _never_ use the fbdev helpers. The reason we aren't using them is that the kms implementation was so old that we didn't implement the necessary helper callbacks... Also, I might be misunderstanding the code a bit, but I doubt that vmwgfx is the only hardware with pinning restrictions on the framebuffer? I was under the assumption that most discrete hardware required the framebuffer to be pinned in VRAM? So the important question is, Is this a set of helpers for shared-memory GEM drivers to implement fbdev? Then I wouldn't bother, If it's intended to become an API for clients outside of DRM, then I would have to insist on the API being changed to reflect that. This is definitely not an api for anything outside of drm. Just an attempt to consolidate kernel-internal drm access like fbdev, a simple bootsplash or an emergency console would need to do. Having some limitations in the initial versions, as long as we have some idea how to handle them, seems perfectly fine to me. This isn't meant to be a mandatory replacement for anything - no intentions of exporting this to userspace. OK, yeah my concern is really for generic code and that there in the end would be too much code to change if we wanted to support this, but at least the generic code would be somewhat contained. But it seems like we're at least in agreement on the problematic areas, and as long as they are open for change I guess we can live with that. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/3] drm: Add writeback connector type
From: Brian Starkey Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the writeback-specific details on top of the normal functionality of drm_connector_init(). Writeback connectors have a WRITEBACK_FB_ID property, used to set the output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the supported writeback formats to userspace. When a framebuffer is attached to a writeback connector with the WRITEBACK_FB_ID property, it is used only once (for the commit in which it was included), and userspace can never read back the value of WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is attached to a CRTC. Changes since v1: - Added drm_writeback.c + documentation - Added helper to initialize writeback connector in one go - Added core checks - Squashed into a single commit - Dropped the client cap - Writeback framebuffers are no longer persistent Changes since v2: Daniel Vetter: - Subclass drm_connector to drm_writeback_connector - Relax check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Changes since v3: - Rebased - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS Chances since v4: - Embed a drm_encoder inside the drm_writeback_connector to reduce the amount of boilerplate code required from the drivers that are using it. Changes since v5: - Added Rob Clark's atomic_commit() vfunc to connector helper funcs, so that writeback jobs are commited from atomic helpers - Updated create_writeback_properties() signature to return an error code rather than a boolean false for failure. - Free writeback job with the connector state rather than when doing the cleanup_work() Changes since v7: - fix extraneous use of out_fence that is only introduced in a subsequent patch. Changes since v8: - whitespace changes pull from subsequent patch Reviewed-by: Eric Anholt Signed-off-by: Brian Starkey [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov [rebased and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark Signed-off-by: Liviu Dudau --- Documentation/gpu/drm-kms.rst| 9 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 128 drivers/gpu/drm/drm_atomic_helper.c | 30 +++ drivers/gpu/drm/drm_connector.c | 4 +- drivers/gpu/drm/drm_writeback.c | 255 +++ include/drm/drm_atomic.h | 3 + include/drm/drm_connector.h | 13 ++ include/drm/drm_mode_config.h| 15 ++ include/drm/drm_modeset_helper_vtables.h | 11 + include/drm/drm_writeback.h | 90 include/uapi/drm/drm_mode.h | 1 + 12 files changed, 559 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/drm_writeback.c create mode 100644 include/drm/drm_writeback.h diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 1dffd1ac4cd44..809d403087f95 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -373,6 +373,15 @@ Connector Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_connector.c :export: +Writeback Connectors + + +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c + :export: + Encoder Abstraction === diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index ef9f3dab287fd..69c13517ea3a6 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -18,7 +18,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \ drm_encoder.o drm_mode_object.o drm_property.o \ drm_plane.o drm_color_mgmt.o drm_print.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ - drm_syncobj.o drm_lease.o + drm_syncobj.o drm_lease.o drm_writeback.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o drm-$(CONFIG_DRM_VM) += drm_vm.o diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 895741e9cd7db..e32a93931c0dc 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include "drm_crtc_internal.h" @@ -676,6 +677,45 @@ static void drm_atomic_crtc_print_state(struct drm_printer *p, crtc->funcs->atomic_print_state(p, state); } +/** + * drm_atomic_connector_check - check connector state + * @connector: connector to check + * @state: connector state to check + * + * Pr
[PATCH v9 0/3] drm: Introduce writeback connectors
Hi, This is v9 of the writeback connector series. Compared to v8 I've addressed the comments from Eric Anholt, as well as Maarten Lankhorst's and Daniel Vetter's one on the client capabilities. Most importantly, I've also realised that Dave Airlie has moved the drm-next tree to fd.org and went and rebased the patches on top of the new tree, which had conflicts with this series as the aspect ration capability was introduced in the meanwhile. I will ask Gustavo to pull this series into drm-misc if there are no further comments. Best regards, Liviu Brian Starkey (2): drm: Add writeback connector type drm: writeback: Add out-fences for writeback connectors Liviu Dudau (1): drm: writeback: Add client capability for exposing writeback connectors Documentation/gpu/drm-kms.rst| 9 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 227 +- drivers/gpu/drm/drm_atomic_helper.c | 30 ++ drivers/gpu/drm/drm_connector.c | 4 +- drivers/gpu/drm/drm_ioctl.c | 7 + drivers/gpu/drm/drm_mode_config.c| 5 + drivers/gpu/drm/drm_writeback.c | 360 +++ include/drm/drm_atomic.h | 11 + include/drm/drm_connector.h | 13 + include/drm/drm_file.h | 7 + include/drm/drm_mode_config.h| 23 ++ include/drm/drm_modeset_helper_vtables.h | 11 + include/drm/drm_writeback.h | 129 include/uapi/drm/drm.h | 9 + include/uapi/drm/drm_mode.h | 1 + 16 files changed, 837 insertions(+), 11 deletions(-) create mode 100644 drivers/gpu/drm/drm_writeback.c create mode 100644 include/drm/drm_writeback.h -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 2/3] drm: writeback: Add out-fences for writeback connectors
From: Brian Starkey
Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
enable userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an out-fence without a
framebuffer attached to the connector.
A timeline is added to drm_writeback_connector for use by the writeback
out-fences.
In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
is set to -1.
Changes from v2:
- Rebase onto Gustavo Padovan's v9 explicit sync series
- Change out_fence_ptr type to s32 __user *
- Set *out_fence_ptr to -1 in drm_atomic_connector_set_property
- Store fence in drm_writeback_job
Gustavo Padovan:
- Move out_fence_ptr out of connector_state
- Signal fence from drm_writeback_signal_completion instead of
in driver directly
Changes from v3:
- Rebase onto commit 7e9081c5aac7 ("drm/fence: fix memory overwrite
when setting out_fence fd") (change out_fence_ptr to s32 __user *,
for real this time.)
- Update documentation around WRITEBACK_OUT_FENCE_PTR
Reviewed-by: Eric Anholt
Signed-off-by: Brian Starkey
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/drm_atomic.c| 99 ++---
drivers/gpu/drm/drm_writeback.c | 109 +++-
include/drm/drm_atomic.h| 8 +++
include/drm/drm_connector.h | 8 +--
include/drm/drm_mode_config.h | 8 +++
include/drm/drm_writeback.h | 41 +++-
6 files changed, 257 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e32a93931c0dc..3a635923c86c4 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -326,6 +326,35 @@ static s32 __user *get_out_fence_for_crtc(struct
drm_atomic_state *state,
return fence_ptr;
}
+static int set_out_fence_for_connector(struct drm_atomic_state *state,
+ struct drm_connector *connector,
+ s32 __user *fence_ptr)
+{
+ unsigned int index = drm_connector_index(connector);
+
+ if (!fence_ptr)
+ return 0;
+
+ if (put_user(-1, fence_ptr))
+ return -EFAULT;
+
+ state->connectors[index].out_fence_ptr = fence_ptr;
+
+ return 0;
+}
+
+static s32 __user *get_out_fence_for_connector(struct drm_atomic_state *state,
+ struct drm_connector *connector)
+{
+ unsigned int index = drm_connector_index(connector);
+ s32 __user *fence_ptr;
+
+ fence_ptr = state->connectors[index].out_fence_ptr;
+ state->connectors[index].out_fence_ptr = NULL;
+
+ return fence_ptr;
+}
+
/**
* drm_atomic_set_mode_for_crtc - set mode for CRTC
* @state: the CRTC whose incoming state to update
@@ -713,6 +742,12 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
return -EINVAL;
}
+ if (writeback_job->out_fence && !writeback_job->fb) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence
without framebuffer\n",
+connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
return 0;
}
@@ -1332,6 +1367,11 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
if (fb)
drm_framebuffer_unreference(fb);
return ret;
+ } else if (property == config->writeback_out_fence_ptr_property) {
+ s32 __user *fence_ptr = u64_to_user_ptr(val);
+
+ return set_out_fence_for_connector(state->state, connector,
+ fence_ptr);
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1416,6 +1456,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
+ } else if (property == config->writeback_out_fence_ptr_property) {
+ *val = 0;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
@@ -2289,7 +2331,7 @@ static int setup_out_fence(struct drm_out_fence_state
*fence_state,
return 0;
}
-static int prepare_crtc_signaling(struct drm_device *dev,
+static int prepare_signaling(struct drm_device *dev,
struct drm_atomic_state *state,
struct drm_mode_atomic *arg,
struct drm_file *file_priv,
@@ -2298,6 +2340,8 @@ static int prepare_crtc_
[PATCH v9 3/3] drm: writeback: Add client capability for exposing writeback connectors
Due to the fact that writeback connectors behave in a special way
in DRM (they always report being disconnected) we might confuse some
userspace. Add a client capability for writeback connectors that will
filter them out for clients that don't understand the capability.
Changelog:
- only accept the capability if the client has already set the
DRM_CLIENT_CAP_ATOMIC one.
- update the capability number to fix conflict with the aspect ratio
Reviewed-by: Eric Anholt
Re-requested-by: Sean Paul
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/drm_ioctl.c | 7 +++
drivers/gpu/drm/drm_mode_config.c | 5 +
include/drm/drm_file.h| 7 +++
include/uapi/drm/drm.h| 9 +
4 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 0d4cfb232576f..fe49fb0356b5a 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -334,6 +334,13 @@ drm_setclientcap(struct drm_device *dev, void *data,
struct drm_file *file_priv)
return -EINVAL;
file_priv->aspect_ratio_allowed = req->value;
break;
+ case DRM_CLIENT_CAP_WRITEBACK_CONNECTORS:
+ if (!file_priv->atomic)
+ return -EINVAL;
+ if (req->value > 1)
+ return -EINVAL;
+ file_priv->writeback_connectors = req->value;
+ break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index e5c653357024d..21e353bd3948e 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -145,6 +145,11 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
count = 0;
connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
drm_for_each_connector_iter(connector, &conn_iter) {
+ /* only expose writeback connectors if userspace understands
them */
+ if (!file_priv->writeback_connectors &&
+ (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK))
+ continue;
+
if (drm_lease_held(file_priv, connector->base.id)) {
if (count < card_res->count_connectors &&
put_user(connector->base.id, connector_id + count))
{
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 027ac16da3d15..26485acc51d79 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -192,6 +192,13 @@ struct drm_file {
*/
unsigned aspect_ratio_allowed:1;
+ /**
+* @writeback_connectors:
+*
+* True if client understands writeback connectors
+*/
+ unsigned writeback_connectors:1;
+
/**
* @is_master:
*
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 9c660e1688abe..300f336633f28 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -687,6 +687,15 @@ struct drm_get_cap {
*/
#define DRM_CLIENT_CAP_ASPECT_RATIO4
+/**
+ * DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
+ *
+ * If set to 1, the DRM core will expose special connectors to be used for
+ * writing back to memory the scene setup in the commit. Depends on client
+ * also supporting DRM_CLIENT_CAP_ATOMIC
+ */
+#define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS5
+
/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
struct drm_set_client_cap {
__u64 capability;
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106597] [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3
https://bugs.freedesktop.org/show_bug.cgi?id=106597 --- Comment #31 from taij...@posteo.de --- Created attachment 139740 --> https://bugs.freedesktop.org/attachment.cgi?id=139740&action=edit the promised dmesg output with the patch -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106597] [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3
https://bugs.freedesktop.org/show_bug.cgi?id=106597 --- Comment #30 from taij...@posteo.de --- Created attachment 139739 --> https://bugs.freedesktop.org/attachment.cgi?id=139739&action=edit patch that seems to fix things for me OK, going with Lukas' discovery, I have rebuild my kernel from drm-next-4.18-wip, applying the attached patch, reversing the atpx quirk discussed earlier, and also applying the debug patch (dmesg comes in the next post). And voilà: It seems to be fixed, AFAIK! YAY! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapdrm regression in v4.17-rc series
On 24/05/18 16:54, Tony Lindgren wrote:
> * Tomi Valkeinen [180524 08:00]:
>>
>> On 24/05/18 01:03, Tony Lindgren wrote:
>>> Hi all,
>>>
>>> I bisected the n900 LCD issue to commit 24aac6011f70 ("drm: omapdrm:
>>> sdi: Allocate the sdi private data structure dynamically"). Reverting
>>> this patch makes LCD work for me again on n900.
>>>
>>> Any ideas?
>>
>> This should help to get the SDI enabled.
>
> Thanks yes that fixes it:
>
> Fixes: 24aac6011f70 ("drm: omapdrm: sdi: Allocate the sdi private data
> structure dynamically")
> Reported-by: Tony Lindgren
> Tested-by: Tony Lindgren
>
Thanks, pushed to drm-misc-fixes.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106597] [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3
https://bugs.freedesktop.org/show_bug.cgi?id=106597 --- Comment #29 from taij...@posteo.de --- So a patch to try would look like: -static inline bool snd_hda_sync_power_state(struct hda_codec *codec, +static unsigned int snd_hda_sync_power_state(struct hda_codec *codec, ?? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapdrm regression in v4.17-rc series
Reviewed-by: Benoit Parrot
Tomi Valkeinen wrote on Thu [2018-May-24 10:58:25
+0300]:
>
> On 24/05/18 01:03, Tony Lindgren wrote:
> > Hi all,
> >
> > I bisected the n900 LCD issue to commit 24aac6011f70 ("drm: omapdrm:
> > sdi: Allocate the sdi private data structure dynamically"). Reverting
> > this patch makes LCD work for me again on n900.
> >
> > Any ideas?
>
> This should help to get the SDI enabled.
>
> Tomi
>
> From 4e96e6c2dedf366e081331c3825ff6fa8aabd85c Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen
> Date: Thu, 24 May 2018 10:53:24 +0300
> Subject: [PATCH] drm/omap: fix NULL deref crash with SDI displays
>
> Fix a NULL deref bug introduced in commit 24aac6011f70 ("drm: omapdrm:
> sdi: Allocate the sdi private data structure dynamically").
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/dss/sdi.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
> b/drivers/gpu/drm/omapdrm/dss/sdi.c
> index 68a40ae26f5b..1e2c931f6acf 100644
> --- a/drivers/gpu/drm/omapdrm/dss/sdi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
> @@ -82,7 +82,7 @@ static int sdi_calc_clock_div(struct sdi_device *sdi,
> unsigned long pclk,
> struct dispc_clock_info *dispc_cinfo)
> {
> int i;
> - struct sdi_clk_calc_ctx ctx = { .sdi = sdi };
> + struct sdi_clk_calc_ctx ctx;
>
> /*
>* DSS fclk gives us very few possibilities, so finding a good pixel
> @@ -95,6 +95,9 @@ static int sdi_calc_clock_div(struct sdi_device *sdi,
> unsigned long pclk,
> bool ok;
>
> memset(&ctx, 0, sizeof(ctx));
> +
> + ctx.sdi = sdi;
> +
> if (pclk > 1000 * i * i * i)
> ctx.pck_min = max(pclk - 1000 * i * i * i, 0lu);
> else
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106597] [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3
https://bugs.freedesktop.org/show_bug.cgi?id=106597 --- Comment #28 from Lukas Wunner --- Maybe a revert isn't necessary, I think I've spotted the problem: +static inline bool snd_hda_sync_power_state(struct hda_codec *codec, ... should be unsigned int. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106597] [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3
https://bugs.freedesktop.org/show_bug.cgi?id=106597
--- Comment #27 from Lukas Wunner ---
Okay the real culprit seems to be commit 3b5b899ca67d ("ALSA: hda: Make use of
core codec functions to sync power state"):
https://git.kernel.org/linus/3b5b899ca67d
If you revert that, does the issue go away?
I can see on my MacBook Pro that the return value is consistently 0x233 without
this commit when setting the power state to D3 (which is the correct return
value), and 0x1 with the commit. The commit went into 4.17. Given how late we
are in this cycle, I think a revert is in order. The commit breaks runtime
suspend for any HDA controller. Why the hell wasn't this discovered before,
this must have been in linux-next for > 4 months!?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, sched drm-next-4.18
Hi Dave, Last feature request for 4.18. Mostly vega20 support. - Vega20 support - clock and powergating for VCN - misc bug fixes The following changes since commit 315852b422972e6ebb1dfddaadada09e46a2681a: drm: rcar-du: Fix build failure (2018-05-17 15:03:40 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.18 for you to fetch changes up to b8f3439fa5358ac84d29fa2f4afa115500dec74c: drm/amd/display: Remove use of division operator for long longs (2018-05-24 10:07:56 -0500) Alex Deucher (16): drm/amdgpu/atomfirmware: add new gfx_info data table v2.4 (v2) drm/amdgpu/atomfirmware: add parser for gfx_info table drm/amdgpu: Use vbios table for gpu info on vega20 drm/amdgpu: add df 3.6 headers drm/amdgpu: flag Vega20 as experimental drm/amdgpu/display: remove VEGAM config option drm/amdgpu/display: remove VEGA20 config option drm/amdgpu/display: fix vega12/20 handling in dal_asic_id.h drm/amdgpu: count fences from all uvd instances in idle handler drm/amdgpu: Take uvd encode rings into account in idle work (v2) drm/amdgpu: Take vcn encode rings into account in idle work drm/amdgpu: add new DF 1.7 register defs drm/amdgpu: add new DF callback for ECC setup drm/amdgpu: add a df 1.7 implementation of enable_ecc_force_par_wr_rmw drm/amdgpu/gmc9: disable partial wr rmw if ECC is not enabled drm/amdgpu/pp: remove duplicate assignment Andrey Grodzovsky (3): drm/amdgpu: Skip drm_sched_entity related ops for KIQ ring. drm/scheduler: Remove obsolete spinlock. Remove calls to suspend/resume atomic helpers from amdgpu_device_gpu_recover. (v2) Anthony Koo (7): drm/amd/display: Cleanup unused SetPlaneConfig drm/amd/display: Make DisplayStats work with just DC DisplayStats minor drm/amd/display: Fix up dm logging functionality drm/amd/display: use macro for logs drm/amd/display: Add fullscreen transitions to log drm/amd/display: fix bug with index check drm/amd/display: fix memory leaks Charlene Liu (1): drm/amd/display: underflow/blankscreen recovery Christian König (7): drm/amdgpu: remove unused member drm/amdgpu: rework VM state machine lock handling v2 drm/amdgpu: cleanup amdgpu_vm_validate_pt_bos v2 drm/amdgpu: further optimize amdgpu_vm_handle_moved drm/amdgpu: kmap PDs/PTs in amdgpu_vm_update_directories drm/amdgpu: consistenly use VM moved flag drm/amdgpu: move VM BOs on LRU again Dan Carpenter (1): drm/amd/pp: missing curly braces in smu7_enable_sclk_mclk_dpm() David Francis (1): drm/amd/display: Remove use of division operator for long longs Dmytro Laktyushkin (7): drm/amd/display: get rid of 32.32 unsigned fixed point drm/amd/display: inline more of fixed point code drm/amd/display: add fixed point fractional bit truncation function drm/amd/display: truncate scaling ratios and inits to 19 bit precision drm/amd/display: fix 31_32_fixpt shift functions drm/amd/display: fix a 32 bit shift meant to be 64 warning drm/amd/display: update dml to allow sync with DV Emily Deng (1): drm/sched: add rcu_barrier after entity fini Eric Bernstein (2): drm/amd/display: Update HW sequencer initialization drm/amd/display: DCN1 link encoder Evan Quan (3): drm/amd/powerplay: new framework to honour DAL clock limits drm/amd/powerplay: add a framework for perfroming pre display configuration change settings drm/amd/powerplay: update vega20 cg flags (v2) Feifei Xu (37): drm/amdgpu/gfx9: Update golden setting for gfx9_0. drm/amdgpu: Drop the unused header files in soc15.c. drm/amdgpu: Fix hardcoded base offset of vram pages drm/amd: Add vega20_ip_offset.h headerfile for vega20. (v2) drm/amdgpu: Add vega20 to asic_type enum. drm/amdgpu: Add gpu_info firmware for vega20. (v2) drm/amdgpu: set asic family for vega20. drm/amdgpu: Add smu firmware support for vega20 drm/amdgpu/powerplay: Add initial vega20 support v2 drm/amdgpu/psp: Add initial psp support for vega20 drm/amdgpu: Add vega20 ucode loading method drm/amdgpu: Specify vega20 uvd firmware drm/amdgpu: Specify vega20 vce firmware drm/amdgpu/virtual_dce: Add vega20 support drm/amdgpu/gmc9: Add vega20 support drm/amdgpu/mmhub: Add clockgating support for vega20 drm/amdgpu/sdma4: Specify vega20 firmware drm/amdgpu/sdma4: Add vega20 golden settings (v3) drm/amdgpu/sdma4: Add clockgating support for vega20 drm/amdgpu/gfx9: Add support for vega20 firmware drm/amdgpu/gfx9: Add vega20 golden settings (v3) drm/amdgpu/gfx9: Add gfx config for vega20. (v4) drm/amdgpu/gfx9: Add support for vega20 drm/amdgpu/gfx9: Add clockgatti
[Bug 106639] System display has noise when amdgpu module is being loaded
https://bugs.freedesktop.org/show_bug.cgi?id=106639 --- Comment #2 from Michel Dänzer --- Does https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.18&id=ebdef28ebbcf767d9fa687acb1d02d97d834c628 help? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 07/24] drm/lima: add mali 4xx GPU hardware regs
On Wed, May 23, 2018 at 7:58 PM, Qiang Yu wrote: > On Thu, May 24, 2018 at 1:24 AM, Rob Herring wrote: >> On Fri, May 18, 2018 at 05:27:58PM +0800, Qiang Yu wrote: >>> From: Lima Project Developers >>> >>> Signed-off-by: Qiang Yu >>> Signed-off-by: Heiko Stuebner >>> --- >>> drivers/gpu/drm/lima/lima_regs.h | 304 +++ >>> 1 file changed, 304 insertions(+) >>> create mode 100644 drivers/gpu/drm/lima/lima_regs.h >>> >>> diff --git a/drivers/gpu/drm/lima/lima_regs.h >>> b/drivers/gpu/drm/lima/lima_regs.h >>> new file mode 100644 >>> index ..ea4a37d69b98 >>> --- /dev/null >>> +++ b/drivers/gpu/drm/lima/lima_regs.h >>> @@ -0,0 +1,304 @@ >>> +/* >>> + * Copyright (C) 2010-2017 ARM Limited. All rights reserved. >> >> I assume this came from ARM's out of tree kernel driver source. You >> should document what it was based on. > > Yes, I'll comment it. > >> >>> + * Copyright (C) 2017-2018 Lima Project >> >> IANAL, but is Lima Project a legal entity that can copyright things? > > I heard this second time. Seems it's not a good idea to write like > this. I'll change the copyright next time. > >> >>> + * >>> + * This program is free software and is provided to you under >>> + * the terms of the GNU General Public License version 2 as >>> + * published by the Free Software Foundation, and any use by >>> + * you of this program is subject to the terms of such GNU >>> + * licence. >>> + * >>> + * A copy of the licence is included with the program, and >>> + * can also be obtained from Free Software Foundation, Inc., >>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. >> >> You can use SPDX tags instead. > > If using SPDX, can I drop these license text? How about the copyright > text as I see SPDX header doesn't have it? License and copyright are 2 independent things. Yes, you can drop the license text, but keep the copyrights. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: Fix typo on kerneldoc
Den 24.05.2018 11.01, skrev Daniel Vetter:
Copypasta mistake.
Fixes: 742547b73d27 ("drm/fb_helper: Create wrappers for blit, copyarea and fillrect
funcs")
Cc: Archit Taneja
Cc: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0646b108030b..b7c5ae7f4bd6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1164,7 +1164,7 @@ EXPORT_SYMBOL(drm_fb_helper_sys_imageblit);
* @info: fbdev registered by the helper
* @rect: info about rectangle to fill
*
- * A wrapper around cfb_imageblit implemented by fbdev core
+ * A wrapper around cfb_fillrect implemented by fbdev core
*/
void drm_fb_helper_cfb_fillrect(struct fb_info *info,
const struct fb_fillrect *rect)
Acked-by: Noralf Trønnes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapdrm + etnaviv memory leak
Am Donnerstag, den 24.05.2018, 10:43 +0200 schrieb Lucas Stach: > Hi Tomi, > > Am Donnerstag, den 24.05.2018, 11:39 +0300 schrieb Tomi Valkeinen: > > Hi Lucas, > > > > On 23/05/18 11:53, Lucas Stach wrote: > > > > > > With each run, I can see buffers being left lying around, > > > > visible > > > > in > > > > both omapdrm's and etnaviv's 'gem' debugfs file. And they're > > > > there > > > > even after killing X. > > > > > > > > If I try to rmmod etnaviv, I get the warnings below. Unloading > > > > omapdrm is not possible, as it's being referenced by something > > > > (presumably by etnaviv having imported omapdrm's dmabufs). > > > > > > > > I haven't debugged this much yet, but we do use dmabuf import & > > > > export successfully with omapdrm and v4l2. Has etnaviv dmabuf > > > > import/export been tested? > > > > > > Yes, dma-buf import/export with etnaviv is extensively being > > > used, > > > as > > > we need to work with imx-drm on the scanout side and a V4L2 > > > driven > > > VPU > > > for video-decode. > > > > I managed to create a simple test case for this, and I can see the > > leak > > happen without omapdrm too, with etna + vgem combination. > > > > https://github.com/tomba/kmsxx/blob/etna-debug/utils/buftest.cpp > > > > With etna_bo_map(), buffers leak. > > Thanks, this is really helpful! I'll have a look. Digging in it seems that etnaviv mmap is pretty broken for anything which isn't a etnaviv shm buffer. I'll get back to you once I have a patchset ready for test. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm/psr: Fix missed entry in PSR setup time table.
On Fri, 11 May 2018, Dhinakaran Pandiyan wrote:
> Entry corresponding to 220 us setup time was missing. I am not aware of
> any specific bug this fixes, but this could potentially result in enabling
> PSR on a panel with a higher setup time requirement than supported by the
> hardware.
>
> I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a.
>
> Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä
> Cc: Jose Roberto de Souza
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Dhinakaran Pandiyan
Pushed to drm-misc-fixes with reviews picked up from the earlier posting
[1]. Doesn't look like the function is used by anyone other than i915,
so I didn't bother with further acks from non-Intel devs. Should be a
straightforward fix anyway.
BR,
Jani.
[1]
http://mid.mail-archive.com/20180511005419.11199-1-dhinakaran.pandiyan@intel.com
> ---
> drivers/gpu/drm/drm_dp_helper.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 36c7609a4bd5..a7ba602a43a8 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1159,6 +1159,7 @@ int drm_dp_psr_setup_time(const u8
> psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
> static const u16 psr_setup_time_us[] = {
> PSR_SETUP_TIME(330),
> PSR_SETUP_TIME(275),
> + PSR_SETUP_TIME(220),
> PSR_SETUP_TIME(165),
> PSR_SETUP_TIME(110),
> PSR_SETUP_TIME(55),
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106597] [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3
https://bugs.freedesktop.org/show_bug.cgi?id=106597 --- Comment #26 from Lukas Wunner --- So hda_call_codec_suspend() tries to set the codec's power state to D3 by calling hda_set_power_state(). The return value of that is the 32 bit response detailed on page 151 ff. of the HDA spec. hda_codec_runtime_suspend() then checks if the PS-ClkStopOk bit (bit 9) is set. Only then does it allow suspend of the codec. That bit is not set. It's also not set for the other two codecs of your machine (in the Intel HDA controller). And there's another oddity, the 32 bit response should contain the actual power state in bits 7:4, but those bits are always cleared, for all codecs and regardless whether the codec was put into D0 or D3. In other words, the codecs all remain in D0 even if we tell them to go to D3. Moreover, bits 0:3 of the response should contain the last power state set, but those bits are always either set to D0 or D1. But according to the power capabilities of the AMD HDA controller, it only supports D0 and D3, not D1. So this looks totally bogus. Let me test the debug patch on my own machine and check what the response looks like there. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t
On Wed, May 23, 2018 at 03:05:35PM +0530, Souptick Joarder wrote:
> On Mon, May 14, 2018 at 9:56 PM, Daniel Vetter wrote:
> > On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote:
> >> On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote:
> >> > Hi Sean,
> >> >
> >> > On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder
> >> > wrote:
> >> > > Use new return type vm_fault_t for fault handler.
> >> > >
> >> > > Signed-off-by: Souptick Joarder
> >> > > Reviewed-by: Matthew Wilcox
> >> > > ---
> >> > > drivers/gpu/drm/vgem/vgem_drv.c | 5 ++---
> >> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
> >> > > b/drivers/gpu/drm/vgem/vgem_drv.c
> >> > > index 2524ff1..c64a859 100644
> >> > > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> >> > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> >> > > @@ -61,13 +61,13 @@ static void vgem_gem_free_object(struct
> >> > > drm_gem_object *obj)
> >> > > kfree(vgem_obj);
> >> > > }
> >> > >
> >> > > -static int vgem_gem_fault(struct vm_fault *vmf)
> >> > > +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> >> > > {
> >> > > struct vm_area_struct *vma = vmf->vma;
> >> > > struct drm_vgem_gem_object *obj = vma->vm_private_data;
> >> > > /* We don't use vmf->pgoff since that has the fake offset */
> >> > > unsigned long vaddr = vmf->address;
> >> > > - int ret;
> >> > > + vm_fault_t ret = VM_FAULT_SIGBUS;
> >> > > loff_t num_pages;
> >> > > pgoff_t page_offset;
> >> > > page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
> >> > > @@ -77,7 +77,6 @@ static int vgem_gem_fault(struct vm_fault *vmf)
> >> > > if (page_offset > num_pages)
> >> > > return VM_FAULT_SIGBUS;
> >> > >
> >> > > - ret = -ENOENT;
> >> > > mutex_lock(&obj->pages_lock);
> >> > > if (obj->pages) {
> >> > > get_page(obj->pages[page_offset]);
> >> > > --
> >> > > 1.9.1
> >> > >
> >> >
> >> > Any further comment on this patch ?
> >>
> >> Patch looks good to me. My build test fails, though, since vm_fault_t
> >> doesn't
> >> exist in drm-misc-next yet.
> >
> > vm_fault_t is already in upstream, just needs Maarten to do a backmerge.
> > Which I think he's done by now ... Otherwise nag him more :-)
> > -Daniel
> >
> >>
> >> So, for now,
> >>
> >> Reviewed-by: Sean Paul
> >>
> >>
> >> --
> >> Sean Paul, Software Engineer, Google / Chromium OS
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> Daniel/ Sean, is this patch already merged for 4.18 ?
Nope, fell through the cracks. Thanks for the reminder, queued for 4.18
now.
-Daniel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
On Thu, May 24, 2018 at 5:41 PM, Christian König wrote: > Am 24.05.2018 um 11:24 schrieb Qiang Yu: >> >> On Thu, May 24, 2018 at 2:46 PM, Christian König >> wrote: >> [SNIP] >>> >>> Because of this we have a separate tracking in amdgpu so that we not only >>> know who is using which BO, who is using which VM. >> >> amdgpu's VM implementation seems too complicated for this simple mali GPU, >> but I may investigate it more to see if I can make it better. > > > Yeah, completely agree. > > The VM handling in amdgpu is really complicated because we had to tune it > for multiple use cases. E.g. partial resident textures, delayed updates etc > etc > > But you should at least be able to take the lessons learned we had with that > VM code and not make the same mistakes again. > >>> We intentionally removed the preclose callback to prevent certain use >>> cases, >>> bringing it back to allow your use case looks rather fishy to me. >> >> Seems other drivers do either the deffer or wait way to adopt the drop >> of preclose. I can do the same as you suggested, but just not understand >> why >> we make our life harder. Can I know what's the case you want to prevent? > > > I think what matters most for your case is the issue is that drivers should > handle closing a BO because userspace said so in the same way it handles > closing a BO because of a process termination, but see below. > >>> BTW: What exactly is the issue with using the postclose callback? >> >> The issue is, when Ctrl+C to terminate an application, if no wait or >> deffer >> unmap, buffer just gets unmapped before task is done, so kernel driver >> gets MMU fault and HW reset to recover the GPU. > > > Yeah, that sounds like exactly one of the reasons we had the callback in the > first place and worked on to removing it. > > See the intention is to have reliable handling, e.g. use the same code path > for closing a BO because of an IOCTL and closing a BO because of process > termination. > > In other words what happens when userspace closes a BO while the GPU is > still using it? Would you then run into a GPU reset as well? Yes, also a MMU fault and GPU reset when user space driver error usage like this. I think I don't need to avoid this case because it's user error usage which deserve a GPU reset, but process termination is not. But you remind me they indeed share the same code path if remove preclose now. Regards, Qiang > > I mean it's your driver stack, so I'm not against it as long as you can live > with it. But it's exactly the thing we wanted to avoid here. Seems > > Regards, > Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 10/11] media: vsp1: Support Interlaced display pipelines
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:21 EEST Kieran Bingham wrote:
> Calculate the top and bottom fields for the interlaced frames and
> utilise the extended display list command feature to implement the
> auto-field operations. This allows the DU to update the VSP2 registers
> dynamically based upon the currently processing field.
>
> Signed-off-by: Kieran Bingham
>
> ---
> v3:
> - Pass DL through partition calls to allow autocmd's to be retrieved
> - Document interlaced field in struct vsp1_du_atomic_config
>
> v2:
> - fix erroneous BIT value which enabled interlaced
> - fix field handling at frame_end interrupt
> ---
> drivers/media/platform/vsp1/vsp1_dl.c | 10 -
> drivers/media/platform/vsp1/vsp1_drm.c | 11 -
> drivers/media/platform/vsp1/vsp1_regs.h | 1 +-
> drivers/media/platform/vsp1/vsp1_rpf.c | 71 --
> drivers/media/platform/vsp1/vsp1_rwpf.h | 1 +-
> include/media/vsp1.h| 2 +-
> 6 files changed, 93 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index d33ae5f125bd..bbe9f3006f71
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -906,6 +906,8 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool
> internal) */
> unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
> {
> + struct vsp1_device *vsp1 = dlm->vsp1;
> + u32 status = vsp1_read(vsp1, VI6_STATUS);
> unsigned int flags = 0;
>
> spin_lock(&dlm->lock);
> @@ -931,6 +933,14 @@ unsigned int vsp1_dlm_irq_frame_end(struct
> vsp1_dl_manager *dlm) goto done;
>
> /*
> + * Progressive streams report only TOP fields. If we have a BOTTOM
> + * field, we are interlaced, and expect the frame to complete on the
> + * next frame end interrupt.
> + */
> + if (status & VI6_STATUS_FLD_STD(dlm->index))
> + goto done;
> +
> + /*
>* The device starts processing the queued display list right after the
>* frame end interrupt. The display list thus becomes active.
>*/
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> b/drivers/media/platform/vsp1/vsp1_drm.c index 2c3db8b8adce..cc29c9d96bb7
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -811,6 +811,17 @@ int vsp1_du_atomic_update(struct device *dev, unsigned
> int pipe_index, return -EINVAL;
> }
>
> + if (!(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)) && cfg->interlaced) {
Nitpicking, writing the condition as
if (cfg->interlaced && !(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)))
would match the comment better. You can also drop the parentheses around the
vsp1_feature() call.
> + /*
> + * Interlaced support requires extended display lists to
> + * provide the auto-fld feature with the DU.
> + */
> + dev_dbg(vsp1->dev, "Interlaced unsupported on this output\n");
Could we catch this in the DU driver to fail atomic test ?
> + return -EINVAL;
> + }
> +
> + rpf->interlaced = cfg->interlaced;
> +
> rpf->fmtinfo = fmtinfo;
> rpf->format.num_planes = fmtinfo->planes;
> rpf->format.plane_fmt[0].bytesperline = cfg->pitch;
> diff --git a/drivers/media/platform/vsp1/vsp1_regs.h
> b/drivers/media/platform/vsp1/vsp1_regs.h index d054767570c1..a2ac65cc5155
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
> @@ -28,6 +28,7 @@
> #define VI6_SRESET_SRTS(n) (1 << (n))
>
> #define VI6_STATUS 0x0038
> +#define VI6_STATUS_FLD_STD(n)(1 << ((n) + 28))
> #define VI6_STATUS_SYS_ACT(n)(1 << ((n) + 8))
>
> #define VI6_WPF_IRQ_ENB(n) (0x0048 + (n) * 12)
> diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c
> b/drivers/media/platform/vsp1/vsp1_rpf.c index 8fae7c485642..511b2e127820
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
> @@ -20,6 +20,20 @@
> #define RPF_MAX_WIDTH8190
> #define RPF_MAX_HEIGHT 8190
>
> +/* Pre extended display list command data structure */
> +struct vsp1_extcmd_auto_fld_body {
> + u32 top_y0;
> + u32 bottom_y0;
> + u32 top_c0;
> + u32 bottom_c0;
> + u32 top_c1;
> + u32 bottom_c1;
> + u32 reserved0;
> + u32 reserved1;
> +} __packed;
> +
> +#define VSP1_DL_EXT_AUTOFLD_INT BIT(0)
Should the bit definition be moved to vsp1_regs.h ?
> /*
> * Device Access
> */
> @@ -64,6 +78,14 @@ static void rpf_configure_stream(struct vsp1_entity
> *entity, pstride |= format->plane_fmt[1].bytesperline
> << VI6_RPF_SRCM_PSTRIDE_C_SHIFT;
omapdrm regression in v4.17-rc series
Hi all,
I bisected the n900 LCD issue to commit 24aac6011f70 ("drm: omapdrm:
sdi: Allocate the sdi private data structure dynamically"). Reverting
this patch makes LCD work for me again on n900.
Any ideas?
Regards,
Tony
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] TDA998x I2C driver CEC support
On Wed, May 23, 2018 at 10:48:15AM +0200, Daniel Vetter wrote: > On Tue, May 22, 2018 at 09:27:07AM +0100, Russell King wrote: > > On Tue, May 22, 2018 at 10:53:49AM +1000, Dave Airlie wrote: > > > Sorry I missed this, just fell between the cracks, > > > > > > Any reason you can't/don't use git pull-request to generate pulls? we > > > have some scripts that parse pulls for tracking now, but this pull > > > didn't get into the system as it doesn't use the template. > > > > I've never used git pull-request, and it doesn't seem to be part of > > the git installation I have: > > The command is called request-pull. Our scripting wraps it in > pull-request, which I guess caused the confusion. [Adding Linus] Hmm, so where do people put the hand-written commentry in a git request-pull formatted request that Linus likes to see when sending such requests to Linus? I can understand other maintainers not caring about that, but whatever solution I have to this must work for sending to Linus as well - the format of my pull requests are based on an example format from Linus in the early days of git before request-pull even existed. They also satisfy Linus' other need which is that they need to be clearly identifyable as truely being from the maintainer - I believe Linus uses format and language in the request as part of that. The other thing I notice is that the request-pull format is very impersonal, doesn't say what the summary of changes are (it probably has no way to do so), and contains no gratitudes - its tone is very much like an order than a request. Compare the one I sent in April with this: The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda: Linux 4.16 (2018-04-01 14:20:27 -0700) are available in the git repository at: git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel for you to fetch changes up to ba52762fb1430b2a2ea8127c1a292c15f13b8dac: dt-bindings: tda998x: add the calibration gpio (2018-04-24 10:44:36 +0100) Russell King (7): drm/i2c: tda998x: move mutex/waitqueue/timer/work init early drm/i2c: tda998x: fix error cleanup paths drm/i2c: tda998x: move CEC device initialisation later drm/i2c: tda998x: always disable and clear interrupts at probe drm/i2c: tda9950: add CEC driver drm/i2c: tda998x: add CEC support dt-bindings: tda998x: add the calibration gpio .../devicetree/bindings/display/bridge/tda998x.txt | 3 + drivers/gpu/drm/i2c/Kconfig| 6 + drivers/gpu/drm/i2c/Makefile | 1 + drivers/gpu/drm/i2c/tda9950.c | 509 + drivers/gpu/drm/i2c/tda998x_drv.c | 242 -- include/linux/platform_data/tda9950.h | 16 + 6 files changed, 750 insertions(+), 27 deletions(-) create mode 100644 drivers/gpu/drm/i2c/tda9950.c create mode 100644 include/linux/platform_data/tda9950.h -- Russell King ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] gpu: drm: gma500: Change return type to vm_fault_t
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_{pfn,mixed} returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_{pfn,mixed} will replace this inefficiency by
returning VM_FAULT_* type.
vmf_error() is the newly introduce inline function
in 4.17-rc6.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
v2: updated the change log
drivers/gpu/drm/gma500/framebuffer.c | 14 +-
drivers/gpu/drm/gma500/gem.c | 27 ++-
drivers/gpu/drm/gma500/psb_drv.h | 3 ++-
3 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index cb0a2ae..7635ce8 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -111,7 +111,7 @@ static int psbfb_pan(struct fb_var_screeninfo *var, struct
fb_info *info)
return 0;
}
-static int psbfb_vm_fault(struct vm_fault *vmf)
+static vm_fault_t psbfb_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct psb_framebuffer *psbfb = vma->vm_private_data;
@@ -120,7 +120,7 @@ static int psbfb_vm_fault(struct vm_fault *vmf)
int page_num;
int i;
unsigned long address;
- int ret;
+ vm_fault_t ret;
unsigned long pfn;
unsigned long phys_addr = (unsigned long)dev_priv->stolen_base +
psbfb->gtt->offset;
@@ -133,18 +133,14 @@ static int psbfb_vm_fault(struct vm_fault *vmf)
for (i = 0; i < page_num; i++) {
pfn = (phys_addr >> PAGE_SHIFT);
- ret = vm_insert_mixed(vma, address,
+ ret = vmf_insert_mixed(vma, address,
__pfn_to_pfn_t(pfn, PFN_DEV));
- if (unlikely((ret == -EBUSY) || (ret != 0 && i > 0)))
+ if (unlikely(ret & VM_FAULT_ERROR))
break;
- else if (unlikely(ret != 0)) {
- ret = (ret == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
- return ret;
- }
address += PAGE_SIZE;
phys_addr += PAGE_SIZE;
}
- return VM_FAULT_NOPAGE;
+ return ret;
}
static void psbfb_vm_open(struct vm_area_struct *vma)
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 1312397..e7be5c9 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -134,12 +134,13 @@ int psb_gem_dumb_create(struct drm_file *file, struct
drm_device *dev,
* vma->vm_private_data points to the GEM object that is backing this
* mapping.
*/
-int psb_gem_fault(struct vm_fault *vmf)
+vm_fault_t psb_gem_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj;
struct gtt_range *r;
- int ret;
+ int err;
+ vm_fault_t ret;
unsigned long pfn;
pgoff_t page_offset;
struct drm_device *dev;
@@ -158,9 +159,10 @@ int psb_gem_fault(struct vm_fault *vmf)
/* For now the mmap pins the object and it stays pinned. As things
stand that will do us no harm */
if (r->mmapping == 0) {
- ret = psb_gtt_pin(r);
- if (ret < 0) {
- dev_err(dev->dev, "gma500: pin failed: %d\n", ret);
+ err = psb_gtt_pin(r);
+ if (err < 0) {
+ dev_err(dev->dev, "gma500: pin failed: %d\n", err);
+ ret = vmf_error(err);
goto fail;
}
r->mmapping = 1;
@@ -175,18 +177,9 @@ int psb_gem_fault(struct vm_fault *vmf)
pfn = (dev_priv->stolen_base + r->offset) >> PAGE_SHIFT;
else
pfn = page_to_pfn(r->pages[page_offset]);
- ret = vm_insert_pfn(vma, vmf->address, pfn);
-
+ ret = vmf_insert_pfn(vma, vmf->address, pfn);
fail:
mutex_unlock(&dev_priv->mmap_mutex);
- switch (ret) {
- case 0:
- case -ERESTARTSYS:
- case -EINTR:
- return VM_FAULT_NOPAGE;
- case -ENOMEM:
- return VM_FAULT_OOM;
- default:
- return VM_FAULT_SIGBUS;
- }
+
+ return ret;
}
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index e8300f5..93d2f40 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -21,6 +21,7 @@
#define _PSB_DRV_H_
#include
+#include
#include
#include
@@ -749,7 +750,7 @@ extern int psb_gem_get_aperture(struct drm_device *dev,
void *data,
struct drm
[PATCH v7 5/5] drm/rockchip: support dp training outside dp firmware
DP firmware uses fixed phy config values to do training, but some
boards need to adjust these values to fit for their unique hardware
design. So get phy config values from dts and use software link training
instead of relying on firmware, if software training fail, keep firmware
training as a fallback if sw training fails.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
Reviewed-by: Sean Paul
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- use variable fw_training instead sw_training_success
- base on DP SPCE, if training fail use lower link rate to retry training
Changes in v4:
- improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow
Sean suggest
Changes in v5:
- fix some whitespcae issue
Changes in v6:
- None
Changes in v7:
- None
drivers/gpu/drm/rockchip/Makefile | 3 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
6 files changed, 505 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index a314e21..b932f62 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
+ cdn-dp-link-training.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index cce64c1..783d57a 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder
*encoder)
goto out;
}
}
-
- ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
- goto out;
+ if (dp->use_fw_training) {
+ ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev,
+ "Failed to idle video %d\n", ret);
+ goto out;
+ }
}
ret = cdn_dp_config_video(dp);
@@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder
*encoder)
goto out;
}
- ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
- goto out;
+ if (dp->use_fw_training) {
+ ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev,
+ "Failed to valid video %d\n", ret);
+ goto out;
+ }
}
+
out:
mutex_unlock(&dp->lock);
}
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index 46159b2..77a9793 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -84,6 +84,7 @@ struct cdn_dp_device {
bool connected;
bool active;
bool suspended;
+ bool use_fw_training;
const struct firmware *fw; /* cdn dp firmware */
unsigned int fw_version;/* cdn fw version */
@@ -106,6 +107,7 @@ struct cdn_dp_device {
u8 ports;
u8 lanes;
int active_port;
+ u8 train_set[4];
u8 dpcd[DP_RECEIVER_CAP_SIZE];
bool sink_has_audio;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
new file mode 100644
index 000..73c3290
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
@@ -0,0 +1,420 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong
+ */
+
+#include
+#include
+#include
+#include
+
+#include "cdn-dp-core.h"
+#include "cdn-dp-reg.h"
+
+static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
+{
+ struct cdn_dp_port *port = dp->port[dp->active_port];
+ struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
+
+
Re: [PATCH v4 2/2] drm/panel: Add device_link from panel device to drm device
On 2018-05-23 14:38, Andrzej Hajda wrote: > On 23.05.2018 12:46, Peter Rosin wrote: >> On 2018-05-23 11:39, Andrzej Hajda wrote: >> >> *snip* >> >>> Panels are managed by dsi host only if dsi host implements it, and it is >>> up to dsi host author, it is not mandatory. The only case I am aware of >>> is exynos-dsi. I guess most developers are not aware of the problem, or >>> they do not care, or ... whatever. This patch shows it very clearly. >> *snip* >> >>> With such approach you do not protect dsi hosts without dynamic panel >>> management support. As I said earlier: it is matter of panel consumers >>> (for example dsi host), ie if it implements dynamic panel management, it >>> should attach panel without creating device_links, as it take care of >>> disappearing panels. If it does not perform dynamic management it should >>> rely on default behavior - links should be created, to protect drm >>> device from using dangling pointers. >> So, you're saying that the only place that needs to be patched to call >> drm_panel_attach_without_link is exynos_dsi_host_attach()? > > It should be at least there, but I suppose only there. > >> >> What about the dw-mipi-dsi driver in rockchip/dw-mipi-dsi.c? It also >> calls drm_panel_attach/drm_panel_detach in its dw_mipi_dsi_host_attach >> and dw_mipi_dsi_host_detach functions. > > dw_mipi_dsi_host_detach calls only drm_panel_detach, dangling pointer > will stay in dsi->panel, and nothing prevents from using it. I guess it > is just buggy code. Yeah, now I see it. >> >> Similar thing in bridge/synopsis/dw-mipi-dsi.c, but it calls the >> wrappers drm_panel_bridge_add/remove to create an implicit bridge >> that in turn handles the panel. So, do we need a to add a >> drm_panel_bridge_add_without_link too? > > Again looks like a buggy code, before panel removal it should be turned > off, it should be performed under lock, Yeah, that looks like crap code. >> >> What about tegra/dsi.c? It also calls drm_panel_attach in its >> tegra_dsi_host_attach function? But that one doesn't detach the >> panel in its tegra_dsi_host_detach. Is that a bug? > > Also looks like a bug, but this is dual-channel device so I am not so sure. It's very confusing and hard to get a grip on how things are supposed to be done when everything appears to be riddled with misunderstandings... While browsing the code base I originally thought many more sites needed the drm_panel_attach_without_link variant, but that appears to not be the case. Thanks for your patient explanations! Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/5] phy: rockchip-typec: support variable phy config value
the phy config values used to fix in dp firmware, but some boards
need change these values to do training and get the better eye diagram
result. So support that in phy driver.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- delete need_software_training variable
- add default phy config value, if dts do not define phy config value, use
these value
Changes in v4:
- rename variable config to tcphy_default_config
Changes in v5:
- None
Changes in v6:
- split the header file to new patch
Changes in v7:
- add default case when check link rate
- move struct rockchip_typec_phy new element to this patch
drivers/phy/rockchip/phy-rockchip-typec.c | 263 --
include/soc/rockchip/rockchip_phy_typec.h | 8 +
2 files changed, 218 insertions(+), 53 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c
b/drivers/phy/rockchip/phy-rockchip-typec.c
index 795055f..69af90e 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -324,21 +324,29 @@
* clock 0: PLL 0 div 1
* clock 1: PLL 1 div 2
*/
-#define CLK_PLL_CONFIG 0X30
+#define CLK_PLL1_DIV1 0x20
+#define CLK_PLL1_DIV2 0x30
#define CLK_PLL_MASK 0x33
#define CMN_READY BIT(0)
+#define DP_PLL_CLOCK_ENABLE_ACKBIT(3)
#define DP_PLL_CLOCK_ENABLEBIT(2)
+#define DP_PLL_ENABLE_ACK BIT(1)
#define DP_PLL_ENABLE BIT(0)
#define DP_PLL_DATA_RATE_RBR ((2 << 12) | (4 << 8))
#define DP_PLL_DATA_RATE_HBR ((2 << 12) | (4 << 8))
#define DP_PLL_DATA_RATE_HBR2 ((1 << 12) | (2 << 8))
+#define DP_PLL_DATA_RATE_MASK 0xff00
-#define DP_MODE_A0 BIT(4)
-#define DP_MODE_A2 BIT(6)
-#define DP_MODE_ENTER_A0 0xc101
-#define DP_MODE_ENTER_A2 0xc104
+#define DP_MODE_MASK 0xf
+#define DP_MODE_ENTER_A0 BIT(0)
+#define DP_MODE_ENTER_A2 BIT(2)
+#define DP_MODE_ENTER_A3 BIT(3)
+#define DP_MODE_A0_ACK BIT(4)
+#define DP_MODE_A2_ACK BIT(6)
+#define DP_MODE_A3_ACK BIT(7)
+#define DP_LINK_RESET_DEASSERTED BIT(8)
#define PHY_MODE_SET_TIMEOUT 10
@@ -350,6 +358,8 @@
#define MODE_DFP_USB BIT(1)
#define MODE_DFP_DPBIT(2)
+#define DP_DEFAULT_RATE162000
+
struct phy_reg {
u16 value;
u32 addr;
@@ -372,15 +382,15 @@ struct phy_reg usb3_pll_cfg[] = {
{ 0x8, CMN_DIAG_PLL0_LF_PROG },
};
-struct phy_reg dp_pll_cfg[] = {
+struct phy_reg dp_pll_rbr_cfg[] = {
{ 0xf0, CMN_PLL1_VCOCAL_INIT },
{ 0x18, CMN_PLL1_VCOCAL_ITER },
{ 0x30b9, CMN_PLL1_VCOCAL_START },
- { 0x21c,CMN_PLL1_INTDIV },
+ { 0x87, CMN_PLL1_INTDIV },
{ 0,CMN_PLL1_FRACDIV },
- { 0x5, CMN_PLL1_HIGH_THR },
- { 0x35, CMN_PLL1_SS_CTRL1 },
- { 0x7f1e, CMN_PLL1_SS_CTRL2 },
+ { 0x22, CMN_PLL1_HIGH_THR },
+ { 0x8000, CMN_PLL1_SS_CTRL1 },
+ { 0,CMN_PLL1_SS_CTRL2 },
{ 0x20, CMN_PLL1_DSM_DIAG },
{ 0,CMN_PLLSM1_USER_DEF_CTRL },
{ 0,CMN_DIAG_PLL1_OVRD },
@@ -391,9 +401,52 @@ struct phy_reg dp_pll_cfg[] = {
{ 0x8, CMN_DIAG_PLL1_LF_PROG },
{ 0x100,CMN_DIAG_PLL1_PTATIS_TUNE1 },
{ 0x7, CMN_DIAG_PLL1_PTATIS_TUNE2 },
- { 0x4, CMN_DIAG_PLL1_INCLK_CTRL },
+ { 0x1, CMN_DIAG_PLL1_INCLK_CTRL },
};
+struct phy_reg dp_pll_hbr_cfg[] = {
+ { 0xf0, CMN_PLL1_VCOCAL_INIT },
+ { 0x18, CMN_PLL1_VCOCAL_ITER },
+ { 0x30b4, CMN_PLL1_VCOCAL_START },
+ { 0xe1, CMN_PLL1_INTDIV },
+ { 0,CMN_PLL1_FRACDIV },
+ { 0x5, CMN_PLL1_HIGH_THR },
+ { 0x8000, CMN_PLL1_SS_CTRL1 },
+ { 0,CMN_PLL1_SS_CTRL2 },
+ { 0x20, CMN_PLL1_DSM_DIAG },
+ { 0x1000, CMN_PLLSM1_USER_DEF_CTRL },
+ { 0,CMN_DIAG_PLL1_OVRD },
+ { 0,CMN_DIAG_PLL1_FBH_OVRD },
+ { 0,CMN_DIAG_PLL1_FBL_OVRD },
+ { 0x7, CMN_DIAG_PLL1_V2I_TUNE },
+ { 0x45, CMN_DIAG_PLL1_CP_TUNE },
+ { 0x8, CMN_DIAG_PLL1_LF_PROG },
+ { 0x1, CMN_DIAG_PLL1_PTATIS_TUNE1 },
+ { 0x1, CMN_DIAG_PLL1_PTATIS_TUNE2 },
+ { 0x1, CMN_DIAG_PLL1_INCLK_CTRL },
+};
+
+struct phy_reg dp_pll_hbr2_cfg[] = {
+ { 0xf0, CMN_PLL1_VCOCAL_INIT },
+ { 0x18, CMN_PLL1_VCOCAL_ITER },
+ { 0x30b4, CMN_PLL1_VCOCAL_STAR
Re: [PATCH v2 2/3] drm/vkms: Add basic CRTC initialization
On Wed, May 23, 2018 at 10:53:33AM +0200, Daniel Vetter wrote:
> On Sun, May 20, 2018 at 09:22:31AM +0300, Haneen Mohammed wrote:
> > On Wed, May 16, 2018 at 08:56:21PM -0300, Rodrigo Siqueira wrote:
> > > This commit adds the essential infrastructure for around CRTCs which
> > > is composed of: a new data struct for output data information, a
> > > function for creating planes, and a simple encoder attached to the
> > > connector. Finally, due to the introduction of a new initialization
> > > function, connectors were moved from vkms_drv.c to vkms_display.c.
> > >
> > > Signed-off-by: Rodrigo Siqueira
> > > ---
> > > drivers/gpu/drm/vkms/Makefile | 2 +-
> > > drivers/gpu/drm/vkms/vkms_crtc.c | 35
> > > drivers/gpu/drm/vkms/vkms_drv.c| 60 ++--
> > > drivers/gpu/drm/vkms/vkms_drv.h| 24 +++-
> > > drivers/gpu/drm/vkms/vkms_output.c | 91 ++
> > > drivers/gpu/drm/vkms/vkms_plane.c | 46 +++
> > > 6 files changed, 211 insertions(+), 47 deletions(-)
> > > create mode 100644 drivers/gpu/drm/vkms/vkms_crtc.c
> > > create mode 100644 drivers/gpu/drm/vkms/vkms_output.c
> > > create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c
> > >
> > > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> > > index 2aef948d3a34..3f774a6a9c58 100644
> > > --- a/drivers/gpu/drm/vkms/Makefile
> > > +++ b/drivers/gpu/drm/vkms/Makefile
> > > @@ -1,3 +1,3 @@
> > > -vkms-y := vkms_drv.o
> > > +vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o
> > >
> > > obj-$(CONFIG_DRM_VKMS) += vkms.o
> > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > new file mode 100644
> > > index ..bf76cd39ece7
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > @@ -0,0 +1,35 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include "vkms_drv.h"
> > > +#include
> > > +#include
> > > +
> > > +static const struct drm_crtc_funcs vkms_crtc_funcs = {
> > > + .set_config = drm_atomic_helper_set_config,
> > > + .destroy= drm_crtc_cleanup,
> > > + .page_flip = drm_atomic_helper_page_flip,
> > > + .reset = drm_atomic_helper_crtc_reset,
> > > + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> > > + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> > > +};
> > > +
> > > +int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> > > +struct drm_plane *primary, struct drm_plane *cursor)
> > > +{
> > > + int ret;
> > > +
> >
> > Just as a follow up, I have noticed that vkms breaks when inspecting
> > its state in the debugfs, also when running igt tests with kms and core
> > filters, and adding the following fixed that issue:
> >
> > 1) a drm_crtc_helper_funcs with dummy atomic_check.
>
> We're trying to make callbacks as optional as possible, this was probably
> just an oversight. Can you try to find the place where this is called, and
> add suitable checks for NULL _funcs pointer?
>
> Thanks, Daniel
Sure, I'll look for that.
> >
> > > + ret = drm_crtc_init_with_planes(dev, crtc, primary, cursor,
> > > + &vkms_crtc_funcs, NULL);
> > > + if (ret) {
> > > + DRM_ERROR("Failed to init CRTC\n");
> > > + return ret;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> > > b/drivers/gpu/drm/vkms/vkms_drv.c
> > > index aec3f180f96d..070613e32934 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > @@ -6,7 +6,6 @@
> > > */
> > >
> > > #include
> > > -#include
> > > #include
> > > #include
> > > #include
> > > @@ -59,25 +58,24 @@ static struct drm_driver vkms_driver = {
> > > .minor = DRIVER_MINOR,
> > > };
> > >
> > > -static const u32 vkms_formats[] = {
> > > - DRM_FORMAT_XRGB,
> > > +static const struct drm_mode_config_funcs vkms_mode_funcs = {
> > > + .atomic_check = drm_atomic_helper_check,
> > > + .atomic_commit = drm_atomic_helper_commit,
> > > };
> > >
> > > -static void vkms_connector_destroy(struct drm_connector *connector)
> > > +static int vkms_modeset_init(struct vkms_device *vkmsdev)
> > > {
> > > - drm_connector_unregister(connector);
> > > - drm_connector_cleanup(connector);
> > > -}
> > > + struct drm_device *dev = &vkmsdev->drm;
> > >
> > > -static const struct drm_connector_funcs vkms_connector_funcs = {
> > > - .fill_modes = drm_helper_probe_single_connector_modes,
> > > - .destroy = vkms_connector_destroy,
> > > -};
> > > + drm_mode_confi
Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t
On Mon, May 14, 2018 at 9:56 PM, Daniel Vetter wrote:
> On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote:
>> On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote:
>> > Hi Sean,
>> >
>> > On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder
>> > wrote:
>> > > Use new return type vm_fault_t for fault handler.
>> > >
>> > > Signed-off-by: Souptick Joarder
>> > > Reviewed-by: Matthew Wilcox
>> > > ---
>> > > drivers/gpu/drm/vgem/vgem_drv.c | 5 ++---
>> > > 1 file changed, 2 insertions(+), 3 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
>> > > b/drivers/gpu/drm/vgem/vgem_drv.c
>> > > index 2524ff1..c64a859 100644
>> > > --- a/drivers/gpu/drm/vgem/vgem_drv.c
>> > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
>> > > @@ -61,13 +61,13 @@ static void vgem_gem_free_object(struct
>> > > drm_gem_object *obj)
>> > > kfree(vgem_obj);
>> > > }
>> > >
>> > > -static int vgem_gem_fault(struct vm_fault *vmf)
>> > > +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
>> > > {
>> > > struct vm_area_struct *vma = vmf->vma;
>> > > struct drm_vgem_gem_object *obj = vma->vm_private_data;
>> > > /* We don't use vmf->pgoff since that has the fake offset */
>> > > unsigned long vaddr = vmf->address;
>> > > - int ret;
>> > > + vm_fault_t ret = VM_FAULT_SIGBUS;
>> > > loff_t num_pages;
>> > > pgoff_t page_offset;
>> > > page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
>> > > @@ -77,7 +77,6 @@ static int vgem_gem_fault(struct vm_fault *vmf)
>> > > if (page_offset > num_pages)
>> > > return VM_FAULT_SIGBUS;
>> > >
>> > > - ret = -ENOENT;
>> > > mutex_lock(&obj->pages_lock);
>> > > if (obj->pages) {
>> > > get_page(obj->pages[page_offset]);
>> > > --
>> > > 1.9.1
>> > >
>> >
>> > Any further comment on this patch ?
>>
>> Patch looks good to me. My build test fails, though, since vm_fault_t doesn't
>> exist in drm-misc-next yet.
>
> vm_fault_t is already in upstream, just needs Maarten to do a backmerge.
> Which I think he's done by now ... Otherwise nag him more :-)
> -Daniel
>
>>
>> So, for now,
>>
>> Reviewed-by: Sean Paul
>>
>>
>> --
>> Sean Paul, Software Engineer, Google / Chromium OS
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Daniel/ Sean, is this patch already merged for 4.18 ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu: drm: udl: Adding new typedef vm_fault_t
On Wed, May 23, 2018 at 2:19 PM, Daniel Vetter wrote:
> On Mon, May 21, 2018 at 10:27:44AM +0530, Souptick Joarder wrote:
>> On Thu, May 10, 2018 at 7:18 PM, Souptick Joarder
>> wrote:
>> > On Wed, Apr 25, 2018 at 10:29 AM, Souptick Joarder
>> > wrote:
>> >> Use new return type vm_fault_t for fault and huge_fault
>> >> handler. For now, this is just documenting that the
>> >> function returns a VM_FAULT value rather than an errno.
>> >> Once all instances are converted, vm_fault_t will become
>> >> a distinct type.
>> >>
>> >> Commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>> >>
>> >> Previously vm_insert_page() returns err which driver
>> >> mapped into VM_FAULT_* type. The new function vmf_
>> >> insert_page() will replace this inefficiency by
>> >> returning VM_FAULT_* type.
>> >>
>> >> Signed-off-by: Souptick Joarder
>> >> Reviewed-by: Matthew Wilcox
>> >> ---
>> >> v2: Updated the change log
>> >>
>> >> drivers/gpu/drm/udl/udl_drv.h | 3 ++-
>> >> drivers/gpu/drm/udl/udl_gem.c | 15 ++-
>> >> 2 files changed, 4 insertions(+), 14 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
>> >> index 2a75ab8..11151c4 100644
>> >> --- a/drivers/gpu/drm/udl/udl_drv.h
>> >> +++ b/drivers/gpu/drm/udl/udl_drv.h
>> >> @@ -16,6 +16,7 @@
>> >>
>> >> #include
>> >> #include
>> >> +#include
>> >>
>> >> #define DRIVER_NAME"udl"
>> >> #define DRIVER_DESC"DisplayLink"
>> >> @@ -134,7 +135,7 @@ struct drm_gem_object *udl_gem_prime_import(struct
>> >> drm_device *dev,
>> >> int udl_gem_vmap(struct udl_gem_object *obj);
>> >> void udl_gem_vunmap(struct udl_gem_object *obj);
>> >> int udl_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
>> >> -int udl_gem_fault(struct vm_fault *vmf);
>> >> +vm_fault_t udl_gem_fault(struct vm_fault *vmf);
>> >>
>> >> int udl_handle_damage(struct udl_framebuffer *fb, int x, int y,
>> >> int width, int height);
>> >> diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
>> >> index dee6bd9..cf5fe35 100644
>> >> --- a/drivers/gpu/drm/udl/udl_gem.c
>> >> +++ b/drivers/gpu/drm/udl/udl_gem.c
>> >> @@ -100,13 +100,12 @@ int udl_drm_gem_mmap(struct file *filp, struct
>> >> vm_area_struct *vma)
>> >> return ret;
>> >> }
>> >>
>> >> -int udl_gem_fault(struct vm_fault *vmf)
>> >> +vm_fault_t udl_gem_fault(struct vm_fault *vmf)
>> >> {
>> >> struct vm_area_struct *vma = vmf->vma;
>> >> struct udl_gem_object *obj = to_udl_bo(vma->vm_private_data);
>> >> struct page *page;
>> >> unsigned int page_offset;
>> >> - int ret = 0;
>> >>
>> >> page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
>> >>
>> >> @@ -114,17 +113,7 @@ int udl_gem_fault(struct vm_fault *vmf)
>> >> return VM_FAULT_SIGBUS;
>> >>
>> >> page = obj->pages[page_offset];
>> >> - ret = vm_insert_page(vma, vmf->address, page);
>> >> - switch (ret) {
>> >> - case -EAGAIN:
>> >> - case 0:
>> >> - case -ERESTARTSYS:
>> >> - return VM_FAULT_NOPAGE;
>> >> - case -ENOMEM:
>> >> - return VM_FAULT_OOM;
>> >> - default:
>> >> - return VM_FAULT_SIGBUS;
>> >> - }
>> >> + return vmf_insert_page(vma, vmf->address, page);
>> >> }
>> >>
>> >> int udl_gem_get_pages(struct udl_gem_object *obj)
>> >> --
>> >> 1.9.1
>> >>
>> >
>> > Any comment on this patch ?
>>
>> If no comment, we would like to get this patch in queue
>> for 4.18.
>
> 4.18 is done already, queued up for 4.19 in drm-misc-next.
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Thanks :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: etnaviv: Change return type to vm_fault_t
> A non-fatal signal being delivered to a task which is > in the middle of a page fault may well end up in an > infinite loop, attempting to handle the page fault and > failing forever. > > On seeing NOPAGE, the fault handler believes the PTE > is in the page table, so does nothing before it returns > to arch code. It will end up returning to userspace if > the signal is non-fatal, at which point it'll go right > back into the page fault handler, and mutex_lock_interruptible() > will immediately fail. So we've converted a sleeping lock > into the most expensive spinlock. > > I don't think the graphics drivers really want to be > interrupted by any signal. I think they want to be > interruptible by fatal signals and should use the > mutex_lock_killable / fatal_signal_pending family of > functions. So mutex_lock_interruptible() is replaced > by mutex_lock_killable() > Matthew, are we going to fix similar issues in all drivers as part of this clean up ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: ttm: Adding new return type vm_fault_t
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_{mixed,pfn} returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_{mixed,pfn} will replace this inefficiency by
returning VM_FAULT_* type.
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 45 -
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 8eba95b..2d13f03 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -43,10 +43,11 @@
#define TTM_BO_VM_NUM_PREFAULT 16
-static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
+static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
struct vm_fault *vmf)
{
- int ret = 0;
+ int err = 0;
+ vm_fault_t ret = 0;
if (likely(!bo->moving))
goto out_unlock;
@@ -77,9 +78,9 @@ static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
/*
* Ordinary wait.
*/
- ret = dma_fence_wait(bo->moving, true);
- if (unlikely(ret != 0)) {
- ret = (ret != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
+ err = dma_fence_wait(bo->moving, true);
+ if (unlikely(err != 0)) {
+ ret = (err != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
VM_FAULT_NOPAGE;
goto out_unlock;
}
@@ -104,7 +105,7 @@ static unsigned long ttm_bo_io_mem_pfn(struct
ttm_buffer_object *bo,
+ page_offset;
}
-static int ttm_bo_vm_fault(struct vm_fault *vmf)
+static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
@@ -115,8 +116,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
unsigned long pfn;
struct ttm_tt *ttm = NULL;
struct page *page;
- int ret;
+ int err;
int i;
+ vm_fault_t ret = VM_FAULT_NOPAGE;
unsigned long address = vmf->address;
struct ttm_mem_type_manager *man =
&bdev->man[bo->mem.mem_type];
@@ -128,9 +130,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
* for reserve, and if it fails, retry the fault after waiting
* for the buffer to become unreserved.
*/
- ret = ttm_bo_reserve(bo, true, true, NULL);
- if (unlikely(ret != 0)) {
- if (ret != -EBUSY)
+ err = ttm_bo_reserve(bo, true, true, NULL);
+ if (unlikely(err != 0)) {
+ if (err != -EBUSY)
return VM_FAULT_NOPAGE;
if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
@@ -162,8 +164,8 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
}
if (bdev->driver->fault_reserve_notify) {
- ret = bdev->driver->fault_reserve_notify(bo);
- switch (ret) {
+ err = bdev->driver->fault_reserve_notify(bo);
+ switch (err) {
case 0:
break;
case -EBUSY:
@@ -191,13 +193,13 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
goto out_unlock;
}
- ret = ttm_mem_io_lock(man, true);
- if (unlikely(ret != 0)) {
+ err = ttm_mem_io_lock(man, true);
+ if (unlikely(err != 0)) {
ret = VM_FAULT_NOPAGE;
goto out_unlock;
}
- ret = ttm_mem_io_reserve_vm(bo);
- if (unlikely(ret != 0)) {
+ err = ttm_mem_io_reserve_vm(bo);
+ if (unlikely(err != 0)) {
ret = VM_FAULT_SIGBUS;
goto out_io_unlock;
}
@@ -265,23 +267,20 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
}
if (vma->vm_flags & VM_MIXEDMAP)
- ret = vm_insert_mixed(&cvma, address,
+ ret = vmf_insert_mixed(&cvma, address,
__pfn_to_pfn_t(pfn, PFN_DEV));
else
- ret = vm_insert_pfn(&cvma, address, pfn);
+ ret = vmf_insert_pfn(&cvma, address, pfn);
/*
* Somebody beat us to this PTE or prefaulting to
* an already populated PTE, or prefaulting error.
*/
- if (unlikely((ret == -EBUSY) || (ret != 0 && i > 0)))
+ if (unlikely((ret == VM_FAULT_NOPAGE && i > 0)))
break;
- else if (unlikely(ret != 0)) {
- ret =
- (ret == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
+
Re: [PATCH v4 2/2] drm/panel: Add device_link from panel device to drm device
On 2018-05-22 17:03, Peter Rosin wrote:
> On 2018-05-22 11:45, Andrzej Hajda wrote:
>> On 22.05.2018 09:36, Peter Rosin wrote:
>>> On 2018-05-22 08:29, Andrzej Hajda wrote:
On 21.05.2018 23:56, Peter Rosin wrote:
> On 2018-05-21 11:21, Andrzej Hajda wrote:
>> On 21.05.2018 10:53, Peter Rosin wrote:
>>> On 2018-05-21 10:15, Andrzej Hajda wrote:
On 19.05.2018 18:48, Peter Rosin wrote:
> On 2018-05-18 13:51, Andrzej Hajda wrote:
>> On 26.04.2018 10:07, Jyri Sarha wrote:
>>> Add device_link from panel device (supplier) to drm device
>>> (consumer)
>>> when drm_panel_attach() is called. This patch should protect the
>>> master drm driver if an attached panel driver unbinds while it is in
>>> use. The device_link should make sure the drm device is unbound
>>> before
>>> the panel driver becomes unavailable.
>>>
>>> The device_link is removed when drm_panel_detach() is called. The
>>> drm_panel_detach() should be called by the consumer DRM driver, not
>>> the
>>> panel driver, otherwise both drivers are racing to delete the same
>>> link.
>>>
>>> Signed-off-by: Jyri Sarha
>>> Reviewed-by: Eric Anholt
>> Hi Jyri,
>>
>> This patch breaks few platforms: tm2, tm2e, trats2 - ie all platforms
>> using exynos_drm_dsi and dsi panels.
>> Exynos-DSI properly handles panels unbind - ie references to panel
>> are
>> properly removed on panels removal and respective drm_connector
>> enters
>> disconnected state, without destroying whole drm device.
>> And again on panel driver re-bind drm_panel is properly attached to
>> exynos-dsi and panel pipeline is working again.
>> This patch will break this behavior, ie it will destroy whole drm
>> device.
>>
>> Making device_links for panels optional seems to me the best
>> solution,
>> what do you think?
>>
>> The funny thing is that due to bug in device link code, your patch
>> has
>> no effect on these platforms. So it does not hurt these platform yet,
>> but the bug will be fixed sooner or later.
> Ah, that's a pretty strong hint that we are doing something unusual.
> So,
> I had a deeper look and I think that device-links (with state, i.e.
> not
> DL_FLAG_STATELESS links) are assumed to be created by the .probe
> function
> of either the consumer or the supplier. Then it seems to works as
> expected.
> And that makes some sense too, because a link indicates that there
> exist
> a dependency between the two and that the consumer cannot really exist
> without the supplier. This is also what happens for the drm devices
> (panel/bridge consumers) Jyri and I are working with; they call panel
> or
> bridge attach during their probe. But this is not the case for exynos,
> which calls panel/bridge attach at some later stage, and that
> obviously
> violates the assumption that the device-link consumer cannot exist w/o
> the supplier ("obviously" since the drm driver has managed to
> successfully
> probe without the supplier).
>
> So, when the panel/bridge supplier is probed after the consumer is
> bound, the link starts out as DL_STATE_DORMANT, and progresses to
> DL_STATE_AVAILABLE once the panel/bridge has finished the probe. This
> is
> not what *we* want.
And this is also incorrect from Documentation PoV:
* @DL_STATE_DORMANT: None of the supplier/consumer drivers is present.
* @DL_STATE_AVAILABLE: The supplier driver is present, but the
consumer
is not.
> So, one idea I have is to, on panel/bridge attach, verify if the
> consumer is in its probe, and only create the link if that is the
> case. So, the link would be optional, but it would all be automatic.
Making it automatic looks tempting, but also error prone. In case of
component framework bind callbacks can be called from probe of any
component, so sometimes it can be called also from exynos-dsi probe,
sometimes not (depending on order of probing, which we cannot rely on).
So in some cases we will end-up with links, sometimes without. Ie
following scenarios are possible in drm_panel_attach:
1. exynos-dsi bound, panel during probe.
2. exynos-dsi during probe, panel during probe.
>>> 2. exynos-dsi during probe, panel bound? Or is this case 3, and 2
>>> happens
>>> when drivers probe in parallel?
>> Panel is always probed not earlier than the end of exynos-dsi bind, so
>> only scenarios 1 and
[PATCH v5 3/7] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
This beats the heuristic that the connector is involved in what format
should be output for cases where this fails.
E.g. if there is a bridge that changes format between the encoder and the
connector, or if some of the RGB pins between the lcd controller and the
encoder are not routed on the PCB.
This is critical for the devices that have the "conflicting output
formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
RGB bits move around depending on the selected output mode. For
devices that do not have the "conflicting output formats" issue
(SAMA5D2, SAMA5D4), this is completely irrelevant.
Acked-by: Boris Brezillon
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 70 +---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 1 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 67 ---
3 files changed, 111 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d73281095fac..c38a479ada98 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -226,6 +226,55 @@ static void atmel_hlcdc_crtc_atomic_enable(struct drm_crtc
*c,
#define ATMEL_HLCDC_RGB888_OUTPUT BIT(3)
#define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
+static int atmel_hlcdc_connector_output_mode(struct drm_connector_state *state)
+{
+ struct drm_connector *connector = state->connector;
+ struct drm_display_info *info = &connector->display_info;
+ struct drm_encoder *encoder;
+ unsigned int supported_fmts = 0;
+ int j;
+
+ encoder = state->best_encoder;
+ if (!encoder)
+ encoder = connector->encoder;
+
+ switch (atmel_hlcdc_encoder_get_bus_fmt(encoder)) {
+ case 0:
+ break;
+ case MEDIA_BUS_FMT_RGB444_1X12:
+ return ATMEL_HLCDC_RGB444_OUTPUT;
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ return ATMEL_HLCDC_RGB565_OUTPUT;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ return ATMEL_HLCDC_RGB666_OUTPUT;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ return ATMEL_HLCDC_RGB888_OUTPUT;
+ default:
+ return -EINVAL;
+ }
+
+ for (j = 0; j < info->num_bus_formats; j++) {
+ switch (info->bus_formats[j]) {
+ case MEDIA_BUS_FMT_RGB444_1X12:
+ supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
+ break;
+ default:
+ break;
+ }
+ }
+
+ return supported_fmts;
+}
+
static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
{
unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
@@ -238,31 +287,12 @@ static int atmel_hlcdc_crtc_select_output_mode(struct
drm_crtc_state *state)
crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
for_each_new_connector_in_state(state->state, connector, cstate, i) {
- struct drm_display_info *info = &connector->display_info;
unsigned int supported_fmts = 0;
- int j;
if (!cstate->crtc)
continue;
- for (j = 0; j < info->num_bus_formats; j++) {
- switch (info->bus_formats[j]) {
- case MEDIA_BUS_FMT_RGB444_1X12:
- supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
- break;
- case MEDIA_BUS_FMT_RGB565_1X16:
- supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
- break;
- case MEDIA_BUS_FMT_RGB666_1X18:
- supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
- break;
- case MEDIA_BUS_FMT_RGB888_1X24:
- supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
- break;
- default:
- break;
- }
- }
+ supported_fmts = atmel_hlcdc_connector_output_mode(cstate);
if (crtc->dc->desc->conflicting_output_formats)
output_fmts &= supported_fmts;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 60c937f42114..4cc1e03f0ae
Re: [PATCH v2] drm/xen-front: fix pointer casts
On 23/05/18 13:36, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Building for a 32-bit target results in warnings from casting > between a 32-bit pointer and a 64-bit integer. Fix the warnings > by casting those pointers to uintptr_t first. > > Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Juergen Gross Juergen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 0/3] Expanding the basic vkms features
On Wed, May 23, 2018 at 11:15:18AM +0200, Daniel Vetter wrote: > On Mon, May 21, 2018 at 10:04:23PM -0300, Rodrigo Siqueira wrote: > > This series of patches add a centralized initialization mechanism, a > > single CRTC with a plane, an encoder, and extra module information. > > > > Changes in v2: > > - Remove unused definitions > > - Improve file names > > - Improve code separation > > - Remove unnecessary formats > > Oops, I merged v2 already. I think we need follow-up patches. > > > Changes in v3: > > - Adds drm_crtc_helper_funcs with a simple atomic_check > > Sorry for the late comment on v2, but I think we need to figure out why > this goes boom first. It imo shouldn't. > > > - Adds extra hooks for drm_connector_funcs hooks (reset, > >atomic_duplicate_state, atomic_destroy_state) > > Hm, reset shouldn't be required. Why do you need it? > I've checked the code, and I think the memory for [plane/connector/crtc] states that are used later in duplicate/destroy are allocated in drm_atomic_helper_*_reset. Otherwise checking /sys/kernel/debug/dri/0/state or running the igt tests causes null pointer dereference error. > Wrt duplicate/destroy state, those are mandatory. I think it'd be good to > have checks for those in the drm_*_init functions, but only for atomic > drivers. You can use drm_drv_uses_atomic_modeset() and WARN_ON(). There's > a bunch of examples already for checking for this stuff, see e.g. > dma_fence_init(). > > > - Adds drm_connector_helper_funcs > > - Adds drm_plane_helper_funcs > > Same here, would be good to add WARN_ON to the relevant _init() functions > to make sure all the mandatory stuff is there to begin with. > > Since Rodrigo has typed the fixes to vkms already, could you Haneen look > into adding these checks to the core drm core? > Sure, I'll work on that. > Thanks, Daniel > > > - Changes in the commit messages > > > > Rodrigo Siqueira (3): > > drm/vkms: Add mode_config initialization > > drm/vkms: Add basic CRTC initialization > > drm/vkms: Add extra information about vkms > > > > drivers/gpu/drm/Kconfig| 8 +- > > drivers/gpu/drm/vkms/Makefile | 2 +- > > drivers/gpu/drm/vkms/vkms_crtc.c | 47 > > drivers/gpu/drm/vkms/vkms_drv.c| 55 +- > > drivers/gpu/drm/vkms/vkms_drv.h| 33 +++- > > drivers/gpu/drm/vkms/vkms_output.c | 118 + > > drivers/gpu/drm/vkms/vkms_plane.c | 62 +++ > > 7 files changed, 285 insertions(+), 40 deletions(-) > > create mode 100644 drivers/gpu/drm/vkms/vkms_crtc.c > > create mode 100644 drivers/gpu/drm/vkms/vkms_output.c > > create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c > > > > -- > > 2.17.0 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 07/24] drm/lima: add mali 4xx GPU hardware regs
On Wed, May 23, 2018 at 10:24 AM, Rob Herring wrote: > On Fri, May 18, 2018 at 05:27:58PM +0800, Qiang Yu wrote: >> From: Lima Project Developers >> >> Signed-off-by: Qiang Yu >> Signed-off-by: Heiko Stuebner >> --- >> drivers/gpu/drm/lima/lima_regs.h | 304 +++ >> 1 file changed, 304 insertions(+) >> create mode 100644 drivers/gpu/drm/lima/lima_regs.h >> >> diff --git a/drivers/gpu/drm/lima/lima_regs.h >> b/drivers/gpu/drm/lima/lima_regs.h >> new file mode 100644 >> index ..ea4a37d69b98 >> --- /dev/null >> +++ b/drivers/gpu/drm/lima/lima_regs.h >> @@ -0,0 +1,304 @@ >> +/* >> + * Copyright (C) 2010-2017 ARM Limited. All rights reserved. > > I assume this came from ARM's out of tree kernel driver source. You > should document what it was based on. > >> + * Copyright (C) 2017-2018 Lima Project > > IANAL, but is Lima Project a legal entity that can copyright things? AFAIR it's not a legal entity, and I believe Qiang can simply replace "Lima Project" with his name in kernel driver. I don't think that anyone else made contribution to the kernel driver that is significant enough to copyright it. Luc Verhaegen may hold copyright for REed data structures if there're any in kernel driver - but I believe only userspace parts took something from limare. >> + * >> + * This program is free software and is provided to you under >> + * the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation, and any use by >> + * you of this program is subject to the terms of such GNU >> + * licence. >> + * >> + * A copy of the licence is included with the program, and >> + * can also be obtained from Free Software Foundation, Inc., >> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > > You can use SPDX tags instead. > > Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage
On Wed, May 23, 2018 at 5:36 PM, Ben Skeggs wrote: > On Thu, May 24, 2018 at 8:48 AM, Kees Cook wrote: >> On Thu, Apr 26, 2018 at 4:25 PM, Kees Cook wrote: >>> On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs wrote: On 14 March 2018 at 21:08, Thierry Reding wrote: > On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wvla, remove VLA. In this particular >> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local >> variable cmdline_size. Also, remove cmdline_size as it is not >> actually useful anymore. >> >> The use of stack Variable Length Arrays needs to be avoided, as they >> can be a vector for stack exhaustion, which can be both a runtime bug >> or a security flaw. Also, in general, as code evolves it is easy to >> lose track of how big a VLA can get. Thus, we can end up having runtime >> failures that are hard to debug. >> >> Also, fixed as part of the directive to remove all VLAs from >> the kernel: https://lkml.org/lkml/2018/3/7/621 >> >> Signed-off-by: Gustavo A. R. Silva >> --- >> Changes in v2: >> - Use sizeof(buf) instead of NVKM_MSGQUEUE_CMDLINE_SIZE. This change >>is based on the feedback provided by David Laight. Thanks David. >> >> drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_msgqueue.c | 7 >> +++ >> 1 file changed, 3 insertions(+), 4 deletions(-) > > Reviewed-by: Thierry Reding Thanks everyone. I've taken the patch in my tree. >>> >>> Hi! >>> >>> Just checking in on this -- I don't see this patch in linux-next. Is >>> this queued somewhere else? >> >> Hi, it's been another month; I still don't see this in linux-next. >> Daniel, can this go via drm-misc? > It's already queued in drm-next. Ah-ha, great, thanks! Looks like I just got unlucky with linux-next pausing on the 17th and this getting committed on the 18th. :) But, yes, I see it now: https://cgit.freedesktop.org/drm/drm/commit/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_msgqueue.c?id=7bf5b70befd7817b9e42acbd2291b2042ea1bf81 -Kees -- Kees Cook Pixel Security ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM Inquiry
On Thu, 24 May 2018, John Sledge wrote: > I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV > in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also > add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I > could see that the kernel is now 4.6. If you're updating kernels, why not update to a recent kernel that's actually supported...? > How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure > it correctly? Boot the kernel, run 'ls /dev/drm_dp_aux*'. If you see stuff, you got it right. > It still unclear to me how to follow what you mean by using DRM DP AUX > interface and getting /dev/drm_dp_auxN node(s) that allows me to read > and write arbitrary DPCD offsets. The device is a char device you can open, seek to an offset (which would be the DPCD offset), and read. For testing, you can achieve the same using dd. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106597] [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3
https://bugs.freedesktop.org/show_bug.cgi?id=106597 --- Comment #24 from Lukas Wunner --- (In reply to taijian from comment #22) > $ grep . /sys/bus/hdaudio/devices/hdaudioC1D0/widgets/*/power_caps > /sys/bus/hdaudio/devices/hdaudioC1D0/widgets/01/power_caps:0xc009 According to the HDA specification r1.0a, page 209 (https://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/high-definition-audio-specification.pdf) this decodes as: EPSS supported CLKSTOP supported D3 supported D0 supported Hm, looks fine at first glance. I think I'll need dmesg output with the 3rd debug patch to understand what's going wrong. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 6/6] media: platform: Add ChromeOS EC CEC driver
The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address and handles
all the messages retries and will only expose Success or Error.
The controller will be tied to the HDMI CEC notifier by using the platform
DMI Data and the i915 device name and connector name.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
---
drivers/media/platform/Kconfig | 11 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/cros-ec-cec/Makefile | 1 +
drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++
4 files changed, 361 insertions(+)
create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8..bc37ecf 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
if CEC_PLATFORM_DRIVERS
+config VIDEO_CROS_EC_CEC
+ tristate "ChromeOS EC CEC driver"
+ depends on MFD_CROS_EC || COMPILE_TEST
+ select CEC_CORE
+ select CEC_NOTIFIER
+ ---help---
+ If you say yes here you will get support for the
+ ChromeOS Embedded Controller's CEC.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
config VIDEO_MESON_AO_CEC
tristate "Amlogic Meson AO CEC driver"
depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515d..830696f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+=
qcom/camss-8x16/
obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
obj-y += meson/
+
+obj-y += cros-ec-cec/
diff --git a/drivers/media/platform/cros-ec-cec/Makefile
b/drivers/media/platform/cros-ec-cec/Makefile
new file mode 100644
index 000..9ce97f9
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
new file mode 100644
index 000..7bc4d8a
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -0,0 +1,347 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for ChromeOS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "cros-ec-cec"
+
+/**
+ * struct cros_ec_cec - Driver data for EC CEC
+ *
+ * @cros_ec: Pointer to EC device
+ * @notifier: Notifier info for responding to EC events
+ * @adap: CEC adapter
+ * @notify: CEC notifier pointer
+ * @rx_msg: storage for a received message
+ */
+struct cros_ec_cec {
+ struct cros_ec_device *cros_ec;
+ struct notifier_block notifier;
+ struct cec_adapter *adap;
+ struct cec_notifier *notify;
+ struct cec_msg rx_msg;
+};
+
+static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint8_t *cec_message = cros_ec->event_data.data.cec_message;
+ unsigned int len = cros_ec->event_size;
+
+ cros_ec_cec->rx_msg.len = len;
+ memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
+
+ cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
+}
+
+static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint32_t events = cros_ec->event_data.data.cec_events;
+
+ if (events & EC_MKBP_CEC_SEND_OK)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_OK);
+
+ /* FW takes care of all retries, tell core to avoid more retries */
+ if (events & EC_MKBP_CEC_SEND_FAILED)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_suspend,
+void *_notify)
+{
+ struct cros_ec_cec *cros_ec_cec;
+ struct cros_ec_device *cros_ec;
+
+ cros_ec_cec = container_of(nb, struct cros_ec_cec,
Re: [PATCH v4 08/11] media: vsp1: Add support for extended display list headers
Hi Kieran,
Thank you for the patch.
On Thursday, 3 May 2018 16:36:19 EEST Kieran Bingham wrote:
> Extended display list headers allow pre and post command lists to be
> executed by the VSP pipeline. This provides the base support for
> features such as AUTO_FLD (for interlaced support) and AUTO_DISP (for
> supporting continuous camera preview pipelines.
>
> Signed-off-by: Kieran Bingham
>
> ---
>
> v2:
> - remove __packed attributes
> ---
> drivers/media/platform/vsp1/vsp1.h | 1 +-
> drivers/media/platform/vsp1/vsp1_dl.c | 83 +-
> drivers/media/platform/vsp1/vsp1_dl.h | 29 -
> drivers/media/platform/vsp1/vsp1_drv.c | 7 +-
> drivers/media/platform/vsp1/vsp1_regs.h | 5 +-
> 5 files changed, 116 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1.h
> b/drivers/media/platform/vsp1/vsp1.h index f0d21cc8e9ab..56c62122a81a
> 100644
> --- a/drivers/media/platform/vsp1/vsp1.h
> +++ b/drivers/media/platform/vsp1/vsp1.h
> @@ -53,6 +53,7 @@ struct vsp1_uif;
> #define VSP1_HAS_HGO (1 << 7)
> #define VSP1_HAS_HGT (1 << 8)
> #define VSP1_HAS_BRS (1 << 9)
> +#define VSP1_HAS_EXT_DL (1 << 10)
>
> struct vsp1_device_info {
> u32 version;
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index 56514cd51c51..b64d32535edc
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -22,6 +22,9 @@
> #define VSP1_DLH_INT_ENABLE (1 << 1)
> #define VSP1_DLH_AUTO_START (1 << 0)
>
> +#define VSP1_DLH_EXT_PRE_CMD_EXEC(1 << 9)
> +#define VSP1_DLH_EXT_POST_CMD_EXEC (1 << 8)
> +
> struct vsp1_dl_header_list {
> u32 num_bytes;
> u32 addr;
> @@ -34,11 +37,34 @@ struct vsp1_dl_header {
> u32 flags;
> };
>
> +struct vsp1_dl_ext_header {
> + u32 reserved0; /* alignment padding */
> +
> + u16 pre_ext_cmd_qty;
Should this be called pre_ext_dl_num_cmd to match the datasheet ?
> + u16 flags;
Aren't the flags supposed to come before the pre_ext_dl_num_cmd field ?
> + u32 pre_ext_cmd_plist;
And pre_ext_dl_plist ?
> +
> + u32 post_ext_cmd_qty;
> + u32 post_ext_cmd_plist;
Similar comments for these variables.
> +};
> +
> +struct vsp1_dl_header_extended {
> + struct vsp1_dl_header header;
> + struct vsp1_dl_ext_header ext;
> +};
> +
> struct vsp1_dl_entry {
> u32 addr;
> u32 data;
> };
>
> +struct vsp1_dl_ext_cmd_header {
Isn't this referred to in the datasheet as a body entry, not a header ? How
about naming it vsp1_dl_ext_cmd_entry ? Or just vsp1_dl_ext_cmd (in which case
the other structure that goes by the same name would need to be renamed) ?
> + u32 cmd;
> + u32 flags;
> + u32 data;
> + u32 reserved;
The datasheet documents this as two 64-bit fields, shouldn't we handle the
structure the same way ?
> +};
> +
> /**
> * struct vsp1_dl_body - Display list body
> * @list: entry in the display list list of bodies
> @@ -95,9 +121,12 @@ struct vsp1_dl_body_pool {
> * @list: entry in the display list manager lists
> * @dlm: the display list manager
> * @header: display list header
> + * @extended: extended display list header. NULL for normal lists
Should we name this extension instead of extended ?
> * @dma: DMA address for the header
> * @body0: first display list body
> * @bodies: list of extra display list bodies
> + * @pre_cmd: pre cmd to be issued through extended dl header
> + * @post_cmd: post cmd to be issued through extended dl header
I think you can spell command in full.
> * @has_chain: if true, indicates that there's a partition chain
> * @chain: entry in the display list partition chain
> * @internal: whether the display list is used for internal purpose
> @@ -107,11 +136,15 @@ struct vsp1_dl_list {
> struct vsp1_dl_manager *dlm;
>
> struct vsp1_dl_header *header;
> + struct vsp1_dl_ext_header *extended;
> dma_addr_t dma;
>
> struct vsp1_dl_body *body0;
> struct list_head bodies;
>
> + struct vsp1_dl_ext_cmd *pre_cmd;
> + struct vsp1_dl_ext_cmd *post_cmd;
> +
> bool has_chain;
> struct list_head chain;
>
> @@ -496,6 +529,14 @@ int vsp1_dl_list_add_chain(struct vsp1_dl_list *head,
> return 0;
> }
>
> +static void vsp1_dl_ext_cmd_fill_header(struct vsp1_dl_ext_cmd *cmd)
> +{
> + cmd->cmds[0].cmd = cmd->cmd_opcode;
> + cmd->cmds[0].flags = cmd->flags;
> + cmd->cmds[0].data = cmd->data_dma;
> + cmd->cmds[0].reserved = 0;
> +}
> +
> static void vsp1_dl_list_fill_header(struct vsp1_dl_list *dl, bool is_last)
> {
> struct vsp1_dl_manager *dlm = dl->dlm;
> @@ -548,6 +589,27 @@ static void vsp1_dl_list_fill_header(struct
> vsp1_dl_list *dl, bool is_last) */
> dl->header->flags = VSP1_DLH_INT_ENABLE;
> }
> +
> + if (!dl->extended)
> + return;
>
Re: [PATCH 7/9] drm/cma-helper: Use the generic fbdev emulation
On Wed, May 23, 2018 at 04:34:09PM +0200, Noralf Trønnes wrote:
> This switches the CMA helper drivers that use its fbdev emulation over
> to the generic fbdev emulation. It's the first phase of using generic
> fbdev. A later phase will use DRM client callbacks for the
> lastclose/hotplug/remove callbacks.
>
> There are currently 2 fbdev init/fini functions:
> - drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
> - drm_fbdev_cma_init/drm_fbdev_cma_fini
>
> This is because the work on generic fbdev came up during a fbdev
> refactoring and thus wasn't completed. No point in completing that
> refactoring when drivers will soon move to drm_fb_helper_generic_probe().
>
> tinydrm uses drm_fb_cma_fbdev_init_with_funcs().
>
> Cc: Laurent Pinchart
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 365
> +---
Yay for the diffstat! Has my ack, but would be good to get Laurent's
review.
-Daniel
> include/drm/drm_fb_cma_helper.h | 3 -
> 2 files changed, 47 insertions(+), 321 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 186d00adfb5f..76e2f799 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -18,6 +18,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -26,11 +27,8 @@
> #include
> #include
>
> -#define DEFAULT_FBDEFIO_DELAY_MS 50
> -
> struct drm_fbdev_cma {
> struct drm_fb_helperfb_helper;
> - const struct drm_framebuffer_funcs *fb_funcs;
> };
>
> /**
> @@ -44,36 +42,6 @@ struct drm_fbdev_cma {
> *
> * An fbdev framebuffer backed by cma is also available by calling
> * drm_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down.
> - * If the &drm_framebuffer_funcs.dirty callback is set, fb_deferred_io will
> be
> - * set up automatically. &drm_framebuffer_funcs.dirty is called by
> - * drm_fb_helper_deferred_io() in process context (&struct delayed_work).
> - *
> - * Example fbdev deferred io code::
> - *
> - * static int driver_fb_dirty(struct drm_framebuffer *fb,
> - *struct drm_file *file_priv,
> - *unsigned flags, unsigned color,
> - *struct drm_clip_rect *clips,
> - *unsigned num_clips)
> - * {
> - * struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
> - * ... push changes ...
> - * return 0;
> - * }
> - *
> - * static struct drm_framebuffer_funcs driver_fb_funcs = {
> - * .destroy = drm_gem_fb_destroy,
> - * .create_handle = drm_gem_fb_create_handle,
> - * .dirty = driver_fb_dirty,
> - * };
> - *
> - * Initialize::
> - *
> - * fbdev = drm_fb_cma_fbdev_init_with_funcs(dev, 16,
> - * dev->mode_config.num_crtc,
> - * dev->mode_config.num_connector,
> - * &driver_fb_funcs);
> - *
> */
>
> static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper
> *helper)
> @@ -131,153 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> drm_framebuffer *fb,
> }
> EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
>
> -static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
> -{
> - return dma_mmap_writecombine(info->device, vma, info->screen_base,
> - info->fix.smem_start, info->fix.smem_len);
> -}
> -
> -static struct fb_ops drm_fbdev_cma_ops = {
> - .owner = THIS_MODULE,
> - DRM_FB_HELPER_DEFAULT_OPS,
> - .fb_fillrect= drm_fb_helper_sys_fillrect,
> - .fb_copyarea= drm_fb_helper_sys_copyarea,
> - .fb_imageblit = drm_fb_helper_sys_imageblit,
> - .fb_mmap= drm_fb_cma_mmap,
> -};
> -
> -static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
> - struct vm_area_struct *vma)
> -{
> - fb_deferred_io_mmap(info, vma);
> - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> -
> - return 0;
> -}
> -
> -static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
> - struct drm_gem_cma_object *cma_obj)
> -{
> - struct fb_deferred_io *fbdefio;
> - struct fb_ops *fbops;
> -
> - /*
> - * Per device structures are needed because:
> - * fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
> - * fbdefio: individual delays
> - */
> - fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
> - fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
> - if (!fbdefio || !fbops) {
> - kfree(fbdefio);
> - kfree(fbops);
> - return -ENOMEM;
> - }
> -
> - /* can't be offset from vaddr since dirty() uses cma_obj */
> - fbi->screen_buffer = cma_obj->vaddr;
> -
