Re: [PATCH v12 7/7] drm/kmb: Build files for KeemBay Display driver
Hi Anitha,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc2
next-20201103]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Anitha-Chrisanthus/Add-support-for-KeemBay-DRM-driver/20201104-072844
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-randconfig-r023-20201104 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
a6d15d40701ad38f29e4ff93703b3ffa7b204611)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
#
https://github.com/0day-ci/linux/commit/060e5099db380b6f351791e410a9d6d89c2ffeab
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Anitha-Chrisanthus/Add-support-for-KeemBay-DRM-driver/20201104-072844
git checkout 060e5099db380b6f351791e410a9d6d89c2ffeab
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/kmb/kmb_drv.c:28:5: warning: no previous prototype for
>> function 'kmb_display_clk_enable' [-Wmissing-prototypes]
int kmb_display_clk_enable(struct kmb_drm_private *kmb)
^
drivers/gpu/drm/kmb/kmb_drv.c:28:1: note: declare 'static' if the function
is not intended to be used outside of this translation unit
int kmb_display_clk_enable(struct kmb_drm_private *kmb)
^
static
>> drivers/gpu/drm/kmb/kmb_drv.c:41:5: warning: no previous prototype for
>> function 'kmb_initialize_clocks' [-Wmissing-prototypes]
int kmb_initialize_clocks(struct kmb_drm_private *kmb, struct device *dev)
^
drivers/gpu/drm/kmb/kmb_drv.c:41:1: note: declare 'static' if the function
is not intended to be used outside of this translation unit
int kmb_initialize_clocks(struct kmb_drm_private *kmb, struct device *dev)
^
static
2 warnings generated.
--
>> drivers/gpu/drm/kmb/kmb_plane.c:103:14: warning: no previous prototype for
>> function 'get_pixel_format' [-Wmissing-prototypes]
unsigned int get_pixel_format(u32 format)
^
drivers/gpu/drm/kmb/kmb_plane.c:103:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
unsigned int get_pixel_format(u32 format)
^
static
>> drivers/gpu/drm/kmb/kmb_plane.c:193:14: warning: no previous prototype for
>> function 'get_bits_per_pixel' [-Wmissing-prototypes]
unsigned int get_bits_per_pixel(const struct drm_format_info *format)
^
drivers/gpu/drm/kmb/kmb_plane.c:193:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
unsigned int get_bits_per_pixel(const struct drm_format_info *format)
^
static
2 warnings generated.
vim +/kmb_display_clk_enable +28 drivers/gpu/drm/kmb/kmb_drv.c
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 27
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 @28 int
kmb_display_clk_enable(struct kmb_drm_private *kmb)
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 29 {
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 30 int ret = 0;
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 31
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 32 ret =
clk_prepare_enable(kmb->kmb_clk.clk_lcd);
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 33 if (ret) {
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 34
drm_err(>drm, "Failed to enable LCD clock: %d\n", ret);
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 35 return ret;
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 36 }
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 37 DRM_INFO("SUCCESS :
enabled LCD clocks\n");
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 38 return 0;
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 39 }
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 40
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 @41 int
kmb_initialize_clocks(struct kmb_drm_private *kmb, struct device *dev)
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 42 {
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 43 int ret = 0;
ef228657da9c1a3 Anitha Chrisanthus 2020-11-03 44 struct reg
[Bug 209939] radeontop causes kernel panic
https://bugzilla.kernel.org/show_bug.cgi?id=209939 --- Comment #5 from Janpieter Sollie (janpieter.sol...@edpnet.be) --- Also tried (thanks to hint from Gentoo) netconsole when using netconsole, no output is logged: while the kernel buffer from before 'radeontop' is printed correctly, no other output is passed during "kernel panic", apparently the kernel does not live long enough to push it to netconsole, or it's a bug in radeontop causing hardware freeze -- 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
Re: [PATCH v2] drm/edid: Fix uninitialized variable in drm_cvt_modes()
Hi Lyude, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master v5.10-rc2 next-20201103] [cannot apply to drm/drm-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Lyude-Paul/drm-edid-Fix-uninitialized-variable-in-drm_cvt_modes/20201104-061621 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-a011-20201104 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/ca77ba73371e528e2bb9e631817c614717b4f794 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Lyude-Paul/drm-edid-Fix-uninitialized-variable-in-drm_cvt_modes/20201104-061621 git checkout ca77ba73371e528e2bb9e631817c614717b4f794 # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> drivers/gpu/drm/drm_edid.o: warning: objtool: do_cvt_mode() falls through to >> next function drm_mode_std.isra.0() --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.103
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 libdrm mostly for new hw and ame names. Aaron Liu (7): tests/amdgpu: expand secure param for exec_cs_helper (v2) tests/amdgpu: add atomic_mem cp_packet to verify the secure buffer tests/amdgpu: add test to submit a gfx command with secure context tests/amdgpu: add atomic dma command to verify the secure buffer (v2) tests/amdgpu: add test to submit a sdma command with secure context test/amdgpu: add drm version checking for security suite test/amdgpu: enable security suite tests Adam Miszczak (1): intel: sync i915_pciids.h with kernel Alex Deucher (4): amdgpu: add marketing names from 20.10 amdgpu: add marketing names from 20.40 amdgpu: sync up amdgpu_drm.h with latest from kernel amdgpu: only enable security tests on raven family Carsten Haitzler (1): tests: add komeda to list of modules to look for for testing Dave Airlie (1): Bump version to 2.4.103 Eric Engestrom (1): core: use `O_RDONLY` instead of ambiguous `0` flag Heiko Thiery (1): xf86drm.c: fix build failure Huang Rui (5): tests/amdgpu: add security test suite (v2) tests/amdgpu: add secure buffer allocation test for system memory tests/amdgpu: add secure buffer allocation test for invisible VRAM tests/amdgpu: expand write linear helper for security (v3) tests/amdgpu: add device handle as input param for exec_cs_helper and write_linear_helper (v4) James Zhu (1): tests/amdgpu/vcn: add Arcturus decode test support Jeremy Cline (1): man: Update the bug URL to gitlab.freedesktop.org José Roberto de Souza (1): intel: sync i915_pciids.h with kernel Le Ma (5): tests/amdgpu: add function to check Asic is Arcturus tests/amdgpu: create Active function for basic test suite tests/amdgpu: disable gfx engine basic test cases for Arcturus tests/amdgpu: move arcturus asic check function to common place tests/amdgpu: disable unsupported test cases for Arcturus Leo Liu (3): tests/amdgpu: add VCN3.0 regs support tests/amdgpu: clear msg decode flag tests/amdgpu: clear the extension flag Luben Tuikov (2): tests/amdgpu: Remove forward declarations tests/amdgpu: Secure bounce test (v4) Lucas Stach (1): tests/util: Add imx-dcss driver Paul Gofman (1): xf86drm.c: Use integer logarithm. Pavan Kumar Ramayanam (1): amdgpu: Add Device IDs for Embedded Raven2 platforms Tapani Pälli (1): intel: add INTEL_DG1_IDS to the pciids list Tianci.Yin (1): tests/amdgpu: disable VCN test if no VCN ring available(v2) sitanliu (1): amdgpu: add device IDs for Raven, Picasso and Renoir sunil kumar dora sermsity (1): intel: Add PCI ID support to RKL platform git tag: libdrm-2.4.103 https://dri.freedesktop.org/libdrm/libdrm-2.4.103.tar.xz SHA256: 3fe0affdba6460166a7323290c18cf68e9b59edcb520722826cb244e9cb50222 libdrm-2.4.103.tar.xz SHA512: 15b098b962008271400692b6b15ecb7e22676f8698e0220ad969735ac2315ccc737d19558afb6abda82bae15117e5f306c048184a2369f434b85ecaa670ca885 libdrm-2.4.103.tar.xz PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.103.tar.xz.sig -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAl+iH0kACgkQDHTzWXnE hr6HjRAAlxmfXbpDl5+aNH5NdcwEiEQ63Y4szehQ+lEcqwBEYt/aek/+xVmvNslc ctqycv+F61O82g81Wcs+ElO7OhnhNH/L4vgPpnx+EN3E+5LLmeN2J/z7l//Exq0F ta5AesHJCTSButXIyPvgX9GFqbhydLCJetsBK8SLH6AELbeNZ+Gx9lnZVGEUncyV wZeJYy3gYim0+SuT3Exbh4/qvYkMHLxuZkZN41tRAyAcpVp1tKrqrddVNVYszYVP AHxGryEdmdbJ4dW24o2m9umsQmLFOxvzm1rhcIuNVwFrTYFzJbaoEy83POrnWEGh TFYyg/XtYbD8rfXvTOo8GpSejjffg6hwAkUOzMQMLbhEvb+PszQimIrQtyeBRrEm 1TiPyCXIzE8KQWCILLH1kOvefl069pdIna6tcdEEbqoP2NpltrERU3GAIKjuls/Y OsX36NswUM+RYXO/nk8Qtqf1jrL38xvUwa/lrlOibF9NumrgFC9eJ/mhYkRoHOOH 5JxHlgzp0PMmZuGSsA71vGjL+7nKnfEaUC5dgxxlhqXmFlAnKom7TKF1UVSWahl5 TRY9HoeJWz4nHTi/Qznvpmtl06wemS2DWTbxbGxieVxmdmxtktxrecehTq3CR896 xJZ7OujPh4Lw3qIHwvMflFgXu0qOSeO99eKmena4+rqZs/PsEbI= =ucD2 -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] drm/vc4: kms: Don't disable the muxing of an active CRTC
Hi Maxime,
On 10/28/20 9:41 PM, Maxime Ripard wrote:
> The current HVS muxing code will consider the CRTCs in a given state to
> setup their muxing in the HVS, and disable the other CRTCs muxes.
>
> However, it's valid to only update a single CRTC with a state, and in this
> situation we would mux out a CRTC that was enabled but left untouched by
> the new state.
>
> Fix this by setting a flag on the CRTC state when the muxing has been
> changed, and only change the muxing configuration when that flag is there.
>
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard
I checked all patches well works.
All patches:
Reviewed-by: Hoegeun Kwon
Tested-by: Hoegeun Kwon
Best regards,
Hoegeun
> ---
> drivers/gpu/drm/vc4/vc4_drv.h | 1 +-
> drivers/gpu/drm/vc4/vc4_kms.c | 84 +---
> 2 files changed, 50 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index c6208b040f77..c074c0538e57 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -523,6 +523,7 @@ struct vc4_crtc_state {
> struct drm_mm_node mm;
> bool feed_txp;
> bool txp_armed;
> + bool needs_muxing;
> unsigned int assigned_channel;
>
> struct {
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 2aa726b7422c..409aeb19d210 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -224,10 +224,7 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
> {
> struct drm_crtc_state *crtc_state;
> struct drm_crtc *crtc;
> - unsigned char dsp2_mux = 0;
> - unsigned char dsp3_mux = 3;
> - unsigned char dsp4_mux = 3;
> - unsigned char dsp5_mux = 3;
> + unsigned char mux;
> unsigned int i;
> u32 reg;
>
> @@ -235,50 +232,59 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev
> *vc4,
> struct vc4_crtc_state *vc4_state =
> to_vc4_crtc_state(crtc_state);
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>
> - if (!crtc_state->active)
> + if (!vc4_state->needs_muxing)
> continue;
>
> switch (vc4_crtc->data->hvs_output) {
> case 2:
> - dsp2_mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
> + mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
> + reg = HVS_READ(SCALER_DISPECTRL);
> + HVS_WRITE(SCALER_DISPECTRL,
> + (reg & ~SCALER_DISPECTRL_DSP2_MUX_MASK) |
> + VC4_SET_FIELD(mux,
> SCALER_DISPECTRL_DSP2_MUX));
> break;
>
> case 3:
> - dsp3_mux = vc4_state->assigned_channel;
> + if (vc4_state->assigned_channel ==
> VC4_HVS_CHANNEL_DISABLED)
> + mux = 3;
> + else
> + mux = vc4_state->assigned_channel;
> +
> + reg = HVS_READ(SCALER_DISPCTRL);
> + HVS_WRITE(SCALER_DISPCTRL,
> + (reg & ~SCALER_DISPCTRL_DSP3_MUX_MASK) |
> + VC4_SET_FIELD(mux, SCALER_DISPCTRL_DSP3_MUX));
> break;
>
> case 4:
> - dsp4_mux = vc4_state->assigned_channel;
> + if (vc4_state->assigned_channel ==
> VC4_HVS_CHANNEL_DISABLED)
> + mux = 3;
> + else
> + mux = vc4_state->assigned_channel;
> +
> + reg = HVS_READ(SCALER_DISPEOLN);
> + HVS_WRITE(SCALER_DISPEOLN,
> + (reg & ~SCALER_DISPEOLN_DSP4_MUX_MASK) |
> + VC4_SET_FIELD(mux, SCALER_DISPEOLN_DSP4_MUX));
> +
> break;
>
> case 5:
> - dsp5_mux = vc4_state->assigned_channel;
> + if (vc4_state->assigned_channel ==
> VC4_HVS_CHANNEL_DISABLED)
> + mux = 3;
> + else
> + mux = vc4_state->assigned_channel;
> +
> + reg = HVS_READ(SCALER_DISPDITHER);
> + HVS_WRITE(SCALER_DISPDITHER,
> + (reg & ~SCALER_DISPDITHER_DSP5_MUX_MASK) |
> + VC4_SET_FIELD(mux,
> SCALER_DISPDITHER_DSP5_MUX));
> break;
>
> default:
> break;
> }
> }
> -
> - reg = HVS_READ(SCALER_DISPECTRL);
> - HVS_WRITE(SCALER_DISPECTRL,
> - (reg & ~SCALER_DISPECTRL_DSP2_MUX_MASK) |
> - VC4_SET_FIELD(dsp2_mux, SCALER_DISPECTRL_DSP2_MUX));
> -
> - reg
[PATCH 2/2] drm/amdgpu: Make struct drm_driver const
Make the definition of struct drm_driver
a constant, to follow the latest developments
in the DRM layer.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 32 +
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 25 +--
2 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index e5bee56e06d1..be304df7a8c2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -40,6 +40,7 @@
#include "amdgpu.h"
#include "amdgpu_irq.h"
#include "amdgpu_dma_buf.h"
+#include "amdgpu_sched.h"
#include "amdgpu_amdkfd.h"
@@ -1105,7 +1106,7 @@ static const struct pci_device_id pciidlist[] = {
MODULE_DEVICE_TABLE(pci, pciidlist);
-static struct drm_driver kms_driver;
+static const struct drm_driver amdgpu_kms_driver;
static int amdgpu_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
@@ -1183,7 +1184,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
adev->dev = >dev;
adev->pdev = pdev;
ddev = adev_to_drm(adev);
- ret = drm_dev_init(ddev, _driver, >dev);
+ ret = drm_dev_init(ddev, _kms_driver, >dev);
if (ret)
goto err_free;
@@ -1528,7 +1529,30 @@ int amdgpu_file_to_fpriv(struct file *filp, struct
amdgpu_fpriv **fpriv)
return 0;
}
-static struct drm_driver kms_driver = {
+int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
*filp);
+
+const struct drm_ioctl_desc amdgpu_ioctls_kms[] = {
+ DRM_IOCTL_DEF_DRV(AMDGPU_GEM_CREATE, amdgpu_gem_create_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_CTX, amdgpu_ctx_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_VM, amdgpu_vm_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_SCHED, amdgpu_sched_ioctl, DRM_MASTER),
+ DRM_IOCTL_DEF_DRV(AMDGPU_BO_LIST, amdgpu_bo_list_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_FENCE_TO_HANDLE,
amdgpu_cs_fence_to_handle_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
+ /* KMS */
+ DRM_IOCTL_DEF_DRV(AMDGPU_GEM_MMAP, amdgpu_gem_mmap_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_GEM_WAIT_IDLE, amdgpu_gem_wait_idle_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_CS, amdgpu_cs_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_INFO, amdgpu_info_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_WAIT_CS, amdgpu_cs_wait_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_WAIT_FENCES, amdgpu_cs_wait_fences_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_GEM_METADATA, amdgpu_gem_metadata_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl,
DRM_MASTER)
+};
+
+static const struct drm_driver amdgpu_kms_driver = {
.driver_features =
DRIVER_ATOMIC |
DRIVER_GEM |
@@ -1539,6 +1563,7 @@ static struct drm_driver kms_driver = {
.lastclose = amdgpu_driver_lastclose_kms,
.irq_handler = amdgpu_irq_handler,
.ioctls = amdgpu_ioctls_kms,
+ .num_ioctls = ARRAY_SIZE(amdgpu_ioctls_kms),
.gem_free_object_unlocked = amdgpu_gem_object_free,
.gem_open_object = amdgpu_gem_object_open,
.gem_close_object = amdgpu_gem_object_close,
@@ -1597,7 +1622,6 @@ static int __init amdgpu_init(void)
goto error_fence;
DRM_INFO("amdgpu kernel modesetting enabled.\n");
- kms_driver.num_ioctls = amdgpu_max_kms_ioctl;
amdgpu_register_atpx_handler();
/* Ignore KFD init failures. Normal when CONFIG_HSA_AMD is not set. */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index bf01744a38f8..4f72c096b3c8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -29,7 +29,6 @@
#include "amdgpu.h"
#include
#include
-#include "amdgpu_sched.h"
#include "amdgpu_uvd.h"
#include "amdgpu_vce.h"
#include "atom.h"
@@ -484,7 +483,7 @@ static int amdgpu_hw_ip_info(struct amdgpu_device *adev,
* etc. (all asics).
* Returns 0 on success, -EINVAL on failure.
*/
-static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct
drm_file *filp)
+int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
*filp)
{
struct amdgpu_device *adev = drm_to_adev(dev);
struct drm_amdgpu_info *info = data;
@@ -1247,28 +1246,6 @@ void amdgpu_disable_vblank_kms(struct drm_crtc
[PATCH 1/2] drm/amdgpu/virt: fix handling of the atomic flag
From: Alex Deucher
Use the per device drm driver feature flags rather than the
global one. This way we can make the drm driver struct const.
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index d0aea5e39531..8aff6ef50f91 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -47,11 +47,13 @@ bool amdgpu_virt_mmio_blocked(struct amdgpu_device *adev)
void amdgpu_virt_init_setting(struct amdgpu_device *adev)
{
+ struct drm_device *ddev = adev_to_drm(adev);
+
/* enable virtual display */
if (adev->mode_info.num_crtc == 0)
adev->mode_info.num_crtc = 1;
adev->enable_virtual_display = true;
- adev_to_drm(adev)->driver->driver_features &= ~DRIVER_ATOMIC;
+ ddev->driver_features &= ~DRIVER_ATOMIC;
adev->cg_flags = 0;
adev->pg_flags = 0;
}
--
2.29.2.154.g7f7ebe054a
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] amdgpu's drm_driver becomes const
Hi Daniel, These two patches follow up your latest DRM work to make definitions of struct drm_driver in DRM low-level drivers, constant, in amdgpu. This set doesn't descend from my previous patch "drm/amdgpu: Convert to using devm_drm_dev_alloc() (v2)", since our branch doesn't have it, and I can see that your const patches aren't in drm-next yet, but they are based on my conversion patch. Perhaps you can graft these two patches locally and dispatch them via drm-next. (There'll be a one-line conflict, namely the devm_drm_dev_alloc().) Thanks and Regards, Luben Alex Deucher (1): drm/amdgpu/virt: fix handling of the atomic flag Luben Tuikov (1): drm/amdgpu: Make struct drm_driver const drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 32 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 25 +- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 ++- 3 files changed, 32 insertions(+), 29 deletions(-) -- 2.29.2.154.g7f7ebe054a ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-intel-fixes tree
On Wed, Nov 04, 2020 at 09:37:05AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'gen12_emit_fini_breadcrumb':
> drivers/gpu/drm/i915/gt/intel_lrc.c:4998:31: error: implicit declaration of
> function '__gen8_emit_flush_dw'; did you mean 'gen8_emit_flush'?
> [-Werror=implicit-function-declaration]
> 4998 | cs = emit_xcs_breadcrumb(rq, __gen8_emit_flush_dw(cs, 0, 0, 0));
> | ^~~~
> | gen8_emit_flush
> drivers/gpu/drm/i915/gt/intel_lrc.c:4998:31: warning: passing argument 2 of
> 'emit_xcs_breadcrumb' makes pointer from integer without a cast
> [-Wint-conversion]
> 4998 | cs = emit_xcs_breadcrumb(rq, __gen8_emit_flush_dw(cs, 0, 0, 0));
> | ^
> | |
> | int
> drivers/gpu/drm/i915/gt/intel_lrc.c:4902:63: note: expected 'u32 *' {aka
> 'unsigned int *'} but argument is of type 'int'
> 4902 | static u32 *emit_xcs_breadcrumb(struct i915_request *rq, u32 *cs)
> | ~^~
>
> Caused by commit
>
> c94d65d2ff6d ("drm/i915/gt: Flush xcs before tgl breadcrumbs")
>
> I have reverted that commit for today.
Sorry for the trouble. Dependency picked to drm-intel-fixes now.
Thanks for reporting,
Rodrigo.
>
> --
> Cheers,
> Stephen Rothwell
> ___
> 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
RE: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as user memory region
> -Original Message- > From: Daniel Vetter > Sent: Tuesday, November 03, 2020 12:43 PM > To: Xiong, Jianxin > Cc: Jason Gunthorpe ; linux-rdma ; > dri-devel ; Leon > Romanovsky ; Doug Ledford ; Vetter, > Daniel ; Christian Koenig > > Subject: Re: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as user > memory region > > On Tue, Nov 3, 2020 at 6:36 PM Xiong, Jianxin wrote: > > > > > > > -Original Message- > > > From: Daniel Vetter > > > Sent: Friday, October 23, 2020 6:45 PM > > > To: Jason Gunthorpe > > > Cc: Xiong, Jianxin ; linux-rdma > > > ; dri-devel > > > ; Leon Romanovsky > > > ; Doug Ledford ; Vetter, > > > Daniel ; Christian Koenig > > > > > > Subject: Re: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as > > > user memory region > > > > > > > > > + > > > > > > +#ifdef CONFIG_DMA_VIRT_OPS > > > > > > + if (device->dma_device->dma_ops == _virt_ops) > > > > > > + return ERR_PTR(-EINVAL); #endif > > > > > > > > > > Maybe I'm confused, but should we have this check in > > > > > dma_buf_attach, or at least in dma_buf_dynamic_attach? The > > > > > p2pdma functions use that too, and I can't imagine how zerocopy > > > > > should work (which is like the entire point of > > > > > dma-buf) when we have dma_virt_ops. > > > > > > > > The problem is we have RDMA drivers that assume SGL's have a valid > > > > struct page, and these hacky/wrong P2P sgls that DMABUF creates > > > > cannot be passed into those drivers. > > > > > > > > But maybe this is just a 'drivers are using it wrong' if they call > > > > this function and expect struct pages.. > > > > > > > > The check in the p2p stuff was done to avoid this too, but it was > > > > on a different flow. > > > > > > Yeah definitely don't call dma_buf_map_attachment and expect a page > > > back. In practice you'll get a page back fairly often, but I don't think > > > we want to bake that in, maybe we eventually get to non-hacky > dma_addr_t only sgl. > > > > > > What I'm wondering is whether dma_buf_attach shouldn't reject such > > > devices directly, instead of each importer having to do that. > > > > Come back here to see if consensus can be reached on who should do the > > check. My thinking is that it could be over restrictive for > > dma_buf_attach to always reject dma_virt_ops. According to dma-buf > > documentation the back storage would be moved to system area upon > > mapping unless p2p is requested and can be supported by the exporter. The > > sg_list for system memory would have struct page present. > > So I'm not clear on what this dma_virt_ops stuff is for, but if it's an > entirely virtual device with cpu access, then you shouldn't do > dma_buf_map_attachment, and then peek at the struct page in the sgl. This is the key, thanks for pointing that out. I was assuming the importer could use the struct page if it exists. > Instead you need to use dma_buf_vmap/vunmap and dma_buf_begin/end_cpu_access. > Otherwise the coherency managed is all potentially > busted. Also note that cpu access from the kernel to dma-buf is a rather > niche feature (only some usb device drivers use it), so expect warts. > dma_virt_ops is a set of dma mapping operations that map page/sgl to virtual addresses instead of dma addresses. Drivers that use dma_virt_ops would use the mapping result for cpu access (to emulate DMA) instead of real DMA, and thus the dma mapping returned from dma-buf is not compatible with the expectation of such drivers. If these drivers are not allowed to peek into the struct page of the sgl, they have no way to correctly use the sgl. In this sense I agree that drivers that use dma_virt_ops should not call dma_buf_attach(). They should use dma_buf_vmap() et al to get cpu access. > If this is the case, then I think dma_buf_attach should check for this and > reject such imports, since that's an importer bug. So here we go. I will move the check to dma_buf_dynamic_attach (and dma_buf_attach is a wrapper over that). > > If it's otoh something rdma specific, then I guess rdma checking for this is > ok. > > As a third option, if it's something about the connectivity between the > importing and exporting device, then this should be checked in the > ->attach callback the exporter can provide, like the p2p check. The > idea here is that for device specific remapping units (mostly found ond SoC, > and not something like a standard iommu managed by the dma- > api), some of which can even do funny stuff like rotation of 2d images, can > be access by some, but not other. And only the exporter is > aware of these restrictions. > > Now I dunno which case this one here is. > -Daniel > -- > 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
[PATCH v12 3/7] dt-bindings: display: bridge: Intel KeemBay DSI
This patch adds bindings for Intel KeemBay MIPI DSI
v2: corrected description for port
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
Reviewed-by: Neil Armstrong
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Rob Herring
---
.../bindings/display/bridge/intel,keembay-dsi.yaml | 101 +
1 file changed, 101 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
new file mode 100644
index 000..ab5be26
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/intel,keembay-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devicetree bindings for Intel Keem Bay mipi dsi controller
+
+maintainers:
+ - Anitha Chrisanthus
+ - Edmond J Dea
+
+properties:
+ compatible:
+const: intel,keembay-dsi
+
+ reg:
+items:
+ - description: MIPI registers range
+
+ reg-names:
+items:
+ - const: mipi
+
+ clocks:
+items:
+ - description: MIPI DSI clock
+ - description: MIPI DSI econfig clock
+ - description: MIPI DSI config clock
+
+ clock-names:
+items:
+ - const: clk_mipi
+ - const: clk_mipi_ecfg
+ - const: clk_mipi_cfg
+
+ ports:
+type: object
+
+properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ port@0:
+type: object
+description: MIPI DSI input port.
+
+ port@1:
+type: object
+description: DSI output port.
+
+required:
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+mipi-dsi@2090 {
+compatible = "intel,keembay-dsi";
+reg = <0x2090 0x4000>;
+reg-names = "mipi";
+clocks = <_clk 0x86>,
+ <_clk 0x88>,
+ <_clk 0x89>;
+clock-names = "clk_mipi", "clk_mipi_ecfg",
+ "clk_mipi_cfg";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dsi_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+dsi_out: endpoint {
+remote-endpoint = <_input>;
+};
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 5/7] drm/kmb: Add support for KeemBay Display
This is a basic KMS atomic modesetting display driver for KeemBay family of
SOCs. Driver has no 2D or 3D graphics. It calls into the ADV bridge
driver at the connector level.
Single CRTC with LCD controller->mipi DSI->ADV bridge
Only 1080p resolution and single plane is supported at this time.
v2: moved extern to .h, removed license text
use drm_dev_init, upclassed dev_private, removed HAVE_IRQ.(Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
moved clocks under kmb_clock, consolidated clk initializations
use drmm functions
use DRM_GEM_CMA_DRIVER_OPS_VMAP
v5: corrected spellings
v6: corrected checkpatch warnings
v7: review changes Sam Ravnborg and Thomas Zimmerman
removed kmb_crtc.h kmb_crtc_cleanup (Thomas)
renamed mode_set, kmb_load, inlined unload (Thomas)
moved remaining logging to drm_*(Thomas)
re-orged driver initialization (Thomas)
moved plane_status to drm_private (Sam)
removed unnecessary logs and defines and ifdef codes (Sam)
call helper_check in plane_atomic_check (Sam)
renamed set to get for bpp and format functions(Sam)
use drm helper functions for reset, duplicate/destroy state instead
of kmb functions (Sam)
removed kmb_priv from kmb_plane and removed kmb_plane_state (Sam)
v8: get clk_pll0 from display node in dt
v9: moved csc_coef_lcd to plane.c (Daniel Vetter)
call drm_atomic_helper_shutdown in remove (Daniel V)
use drm_crtc_handle_vblank (Daniel V)
renamed kmb_dsi_hw_init to kmb_dsi_mode_set (Daniel V)
complimentary changes to device tree changes (Rob)
v10: call drm_crtc_arm_vblank_event in atomic_flush (Daniel V)
moved global vars to kmb_private and added locks (Daniel V)
changes in driver to accommodate changes in DT to separate DSI
entries (Sam R)
review changes to separate mipi DSI (Sam R)
v11: review changes to separate msscam (Neil A,Sam R)
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Daniel Vetter
---
drivers/gpu/drm/kmb/kmb_crtc.c | 219 +++
drivers/gpu/drm/kmb/kmb_drv.c | 602
drivers/gpu/drm/kmb/kmb_drv.h | 88 ++
drivers/gpu/drm/kmb/kmb_plane.c | 490
drivers/gpu/drm/kmb/kmb_plane.h | 99 +++
5 files changed, 1498 insertions(+)
create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c
create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c
create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h
create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c
create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h
diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c b/drivers/gpu/drm/kmb/kmb_crtc.c
new file mode 100644
index 000..887b6d7
--- /dev/null
+++ b/drivers/gpu/drm/kmb/kmb_crtc.c
@@ -0,0 +1,219 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2018-2020 Intel Corporation
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "kmb_drv.h"
+#include "kmb_dsi.h"
+#include "kmb_plane.h"
+#include "kmb_regs.h"
+
+struct kmb_crtc_timing {
+ u32 vfront_porch;
+ u32 vback_porch;
+ u32 vsync_len;
+ u32 hfront_porch;
+ u32 hback_porch;
+ u32 hsync_len;
+};
+
+static int kmb_crtc_enable_vblank(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct kmb_drm_private *kmb = to_kmb(dev);
+
+ /* Clear interrupt */
+ kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
+ /* Set which interval to generate vertical interrupt */
+ kmb_write_lcd(kmb, LCD_VSTATUS_COMPARE,
+ LCD_VSTATUS_COMPARE_VSYNC);
+ /* Enable vertical interrupt */
+ kmb_set_bitmask_lcd(kmb, LCD_INT_ENABLE,
+ LCD_INT_VERT_COMP);
+ return 0;
+}
+
+static void kmb_crtc_disable_vblank(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct kmb_drm_private *kmb = to_kmb(dev);
+
+ /* Clear interrupt */
+ kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
+ /* Disable vertical interrupt */
+ kmb_clr_bitmask_lcd(kmb, LCD_INT_ENABLE,
+ LCD_INT_VERT_COMP);
+}
+
+static const struct drm_crtc_funcs kmb_crtc_funcs = {
+ .destroy = drm_crtc_cleanup,
+ .set_config = drm_atomic_helper_set_config,
+ .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,
+ .enable_vblank = kmb_crtc_enable_vblank,
+ .disable_vblank = kmb_crtc_disable_vblank,
+};
+
+static void kmb_crtc_set_mode(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_display_mode *m =
[PATCH v12 2/7] dt-bindings: display: Intel KeemBay MSSCAM
This patch add bindings for Intel KeemBay MSSCAM syscon
v2: fixed compatible (Sam R.)
Signed-off-by: Anitha Chrisanthus
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Rob Herring
---
.../bindings/display/intel,keembay-msscam.yaml | 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
diff --git
a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
new file mode 100644
index 000..40caa61
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/intel,keembay-msscam.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devicetree bindings for Intel Keem Bay MSSCAM
+
+maintainers:
+ - Anitha Chrisanthus
+ - Edmond J Dea
+
+description: |
+ MSSCAM controls local clocks in the display subsystem namely LCD clocks and
+ MIPI DSI clocks. It also configures the interconnect between LCD and
+ MIPI DSI.
+
+properties:
+ compatible:
+items:
+ - const: intel,keembay-msscam
+ - const: syscon
+
+ reg:
+maxItems: 1
+
+ reg-io-width:
+const: 4
+
+required:
+ - compatible
+ - reg
+ - reg-io-width
+
+additionalProperties: false
+
+examples:
+ - |
+msscam:msscam@2091 {
+compatible = "intel,keembay-msscam", "syscon";
+reg = <0x2091 0x30>;
+reg-io-width = <4>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 6/7] drm/kmb: Mipi DSI part of the display driver
Initializes Mipi DSI and sets up connects to ADV bridge
v2: removed license text
upclassed dev_private, removed HAVE_IRQ. (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7: review changes Sam Ravnborg and Thomas Zimmerman
removed unnecessary logs and defines and ifdef codes (Sam)
split dphy_init_sequence smaller (Sam)
removed redundant checks in kmb_dsi (Sam)
changed kmb_dsi_init to drm_bridge_connector_init and
drm_connector_attach_encoder to bridge's connector (Sam)
v8: call drm_bridge_attach with DRM_BRIDGE_ATTACH_NO_CONNECTOR
v9: renamed kmb_dsi_hw_init to kmb_dsi_mode_set (Daniel V)
v10: changes in driver to accommodate changes in DT to separate DSI
entries (Sam R)
added comments to clarify empty dsi host functions
review changes from Sam to separate out DSI part,
removed dependencies on drm side (Sam R)
v11: review changes for separate msscam node (Sam R, Neil A)
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Daniel Vetter
---
drivers/gpu/drm/kmb/kmb_dsi.c | 1562 +
drivers/gpu/drm/kmb/kmb_dsi.h | 387 ++
2 files changed, 1949 insertions(+)
create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c
create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.h
diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c b/drivers/gpu/drm/kmb/kmb_dsi.c
new file mode 100644
index 000..a24723d
--- /dev/null
+++ b/drivers/gpu/drm/kmb/kmb_dsi.c
@@ -0,0 +1,1562 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2019-2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "kmb_dsi.h"
+#include "kmb_regs.h"
+
+static struct mipi_dsi_host *dsi_host;
+static struct mipi_dsi_device *dsi_device;
+static struct drm_bridge *adv_bridge;
+
+/* Default setting is 1080p, 4 lanes */
+#define IMG_HEIGHT_LINES 1080
+#define IMG_WIDTH_PX 1920
+#define MIPI_TX_ACTIVE_LANES 4
+
+static struct mipi_tx_frame_section_cfg mipi_tx_frame0_sect_cfg = {
+ .width_pixels = IMG_WIDTH_PX,
+ .height_lines = IMG_HEIGHT_LINES,
+ .data_type = DSI_LP_DT_PPS_RGB888_24B,
+ .data_mode = MIPI_DATA_MODE1,
+ .dma_packed = 0
+};
+
+static struct mipi_tx_frame_cfg mipitx_frame0_cfg = {
+ .sections[0] = _tx_frame0_sect_cfg,
+ .sections[1] = NULL,
+ .sections[2] = NULL,
+ .sections[3] = NULL,
+ .vsync_width = 5,
+ .v_backporch = 36,
+ .v_frontporch = 4,
+ .hsync_width = 44,
+ .h_backporch = 148,
+ .h_frontporch = 88
+};
+
+static const struct mipi_tx_dsi_cfg mipitx_dsi_cfg = {
+ .hfp_blank_en = 0,
+ .eotp_en = 0,
+ .lpm_last_vfp_line = 0,
+ .lpm_first_vsa_line = 0,
+ .sync_pulse_eventn = DSI_VIDEO_MODE_NO_BURST_EVENT,
+ .hfp_blanking = SEND_BLANK_PACKET,
+ .hbp_blanking = SEND_BLANK_PACKET,
+ .hsa_blanking = SEND_BLANK_PACKET,
+ .v_blanking = SEND_BLANK_PACKET,
+};
+
+static struct mipi_ctrl_cfg mipi_tx_init_cfg = {
+ .active_lanes = MIPI_TX_ACTIVE_LANES,
+ .lane_rate_mbps = MIPI_TX_LANE_DATA_RATE_MBPS,
+ .ref_clk_khz = MIPI_TX_REF_CLK_KHZ,
+ .cfg_clk_khz = MIPI_TX_CFG_CLK_KHZ,
+ .tx_ctrl_cfg = {
+ .frames[0] = _frame0_cfg,
+ .frames[1] = NULL,
+ .frames[2] = NULL,
+ .frames[3] = NULL,
+ .tx_dsi_cfg = _dsi_cfg,
+ .line_sync_pkt_en = 0,
+ .line_counter_active = 0,
+ .frame_counter_active = 0,
+ .tx_always_use_hact = 1,
+ .tx_hact_wait_stop = 1,
+ }
+};
+
+struct mipi_hs_freq_range_cfg {
+ u16 default_bit_rate_mbps;
+ u8 hsfreqrange_code;
+};
+
+struct vco_params {
+ u32 freq;
+ u32 range;
+ u32 divider;
+};
+
+static const struct vco_params vco_table[] = {
+ {52, 0x3f, 8},
+ {80, 0x39, 8},
+ {105, 0x2f, 4},
+ {160, 0x29, 4},
+ {210, 0x1f, 2},
+ {320, 0x19, 2},
+ {420, 0x0f, 1},
+ {630, 0x09, 1},
+ {1100, 0x03, 1},
+ {0x, 0x01, 1},
+};
+
+static const struct mipi_hs_freq_range_cfg
+mipi_hs_freq_range[MIPI_DPHY_DEFAULT_BIT_RATES] = {
+ {.default_bit_rate_mbps = 80, .hsfreqrange_code = 0x00},
+ {.default_bit_rate_mbps = 90, .hsfreqrange_code = 0x10},
+ {.default_bit_rate_mbps = 100, .hsfreqrange_code = 0x20},
+ {.default_bit_rate_mbps = 110, .hsfreqrange_code = 0x30},
+ {.default_bit_rate_mbps = 120, .hsfreqrange_code = 0x01},
+ {.default_bit_rate_mbps = 130, .hsfreqrange_code = 0x11},
+
[PATCH v12 0/7] Add support for KeemBay DRM driver
This is a new DRM driver for Intel's KeemBay SOC. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This driver is tested with the KMB EVM board which is the reference baord for Keem Bay SOC. The SOC's display pipeline is as follows +--++-++---+ |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | +--++-++---+ LCD controller and Mipi DSI transmitter are part of the SOC and mipi to HDMI converter is ADV7535 for KMB EVM board. The DRM driver is a basic KMS atomic modesetting display driver and has no 2D or 3D graphics.It calls into the ADV bridge driver at the connector level. Only 1080p resolution and single plane is supported at this time. The usecase is for debugging video and camera outputs. Device tree patches are under review here https://lore.kernel.org/linux-arm-kernel/20200708175020.194436-1-daniele.alessandre...@linux.intel.com/T/ Changes since v1: - Removed redundant license text, updated license - Rearranged include blocks - renamed global vars and removed extern in c - Used upclassing for dev_private - Used drm_dev_init in drm device create - minor cleanups Changes since v2: - squashed all commits to a single commit - logging changed to drm_info, drm_dbg etc. - used devm_drm_dev_alloc() - removed commented out sections and general cleanup Changes since v3: - renamed dev_p to kmb - moved clocks under kmb_clock, consolidated clk initializations - use drmm functions - use DRM_GEM_CMA_DRIVER_OPS_VMAP - more cleanups Changes since v4: - corrected spellings Changes since v5: - corrected checkpatch warnings/checks -Please ignore checkpatch checks on Camelcase - this is how it is named in the databook - Please ignore checkpatch warnings on misspelled for hsa, dout, widthn etc. - they are spelled as in the databook - Please ignore checkpatch checks on macro arguments reuse - its confirmed ok Changes since v6: - review changes Sam Ravnborg and Thomas Zimmerman split patch into 4 parts, part1 register definitions, part2 display driver files, part3 mipi dsi, part4 build files (Sam) removed kmb_crtc.h kmb_crtc_cleanup (Thomas) renamed mode_set, kmb_load, inlined unload (Thomas) moved remaining logging to drm_*(Thomas) re-orged driver initialization (Thomas) moved plane_status to drm_private (Sam) removed unnecessary logs and defines and ifdef codes (Sam) split dphy_init_sequence smaller (Sam) removed redundant checks in kmb_dsi (Sam) changed kmb_dsi_init to drm_bridge_connector_init and drm_connector_attach_encoder to bridge's connector (Sam) call helper_check in plane_atomic_check (Sam) renamed set to get for bpp and format functions(Sam) use drm helper functions for reset, duplicate/destroy state instead of kmb functions (Sam) removed kmb_priv from kmb_plane and removed kmb_plane_state (Sam) Changes since v7: - tested with 5.9 kernel and made the following changes get clk_pll0 from display node in dt call drm_bridge_attach with DRM_BRIDGE_ATTACH_NO_CONNECTOR Also added Maintainer entry Changes since v8: DT review changes (Rob) renamed kmb_dsi_hw_init to kmb_dsi_mode_set (Daniel V) moved csc_coef_lcd to plane.c (Daniel Vetter) call drm_atomic_helper_shutdown in remove (Daniel V) use drm_crtc_handle_vblank (Daniel V) renamed kmb_dsi_hw_init to kmb_dsi_mode_set (Daniel V) complimentary changes to device tree changes (Rob) removed redundant definitions in kmb_dsi.h Changes since v9: Review changes from Sam Ravnborg which are: DT is separated to display and Mipi DSI as per Sam suggestion and the driver has changes to reflect this separation. Also most of the MIPI DSI code is isolated and separated from the main driver, worked closely with Sam on these changes. This split is to ease review and driver is only buildable after the last patch (build files). call drm_crtc_arm_vblank_event in atomic_flush (Daniel V) moved global vars to kmb_private and added locks (Daniel V) added comments to clarify empty dsi host functions (Daniel V) Changes since v10: Created separate DT binding for msscam as syscon(Neil Armstrong, Sam) Msscam is used for clocks and also for connecting mipi and lcd. Corresponding driver changes for the above change (Neil Armstrong, Sam) corrected description for port in dsi DT bindings file updated reviewed by in commits. Changes since v11: corrected compatible in msscam dt bindings and added description (Sam R) Anitha Chrisanthus (7): dt-bindings: display: Add support for Intel KeemBay Display dt-bindings: display: Intel KeemBay MSSCAM dt-bindings: display: bridge: Intel KeemBay DSI
[PATCH v12 1/7] dt-bindings: display: Add support for Intel KeemBay Display
This patch adds bindings for Intel KeemBay Display
v2: review changes from Rob Herring
v3: review changes from Sam Ravnborg (removed mipi dsi entries, and
encoder entry, connect port to dsi)
MSSCAM is part of the display submodule and its used to reset LCD
and MIPI DSI clocks, so its best to be on this device tree.
v4: review changes from Neil Armstrong and Sam - removed msscam
entries
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Rob Herring
---
.../bindings/display/intel,keembay-display.yaml| 72 ++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/intel,keembay-display.yaml
diff --git
a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
new file mode 100644
index 000..0a697d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devicetree bindings for Intel Keem Bay display controller
+
+maintainers:
+ - Anitha Chrisanthus
+ - Edmond J Dea
+
+properties:
+ compatible:
+const: intel,keembay-display
+
+ reg:
+items:
+ - description: LCD registers range
+
+ reg-names:
+items:
+ - const: lcd
+
+ clocks:
+items:
+ - description: LCD controller clock
+ - description: pll0 clock
+
+ clock-names:
+items:
+ - const: clk_lcd
+ - const: clk_pll0
+
+ interrupts:
+maxItems: 1
+
+ port:
+type: object
+description: Display output node to DSI.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@2093 {
+compatible = "intel,keembay-display";
+reg = <0x2093 0x3000>;
+reg-names = "lcd";
+interrupts = ;
+clocks = <_clk 0x83>,
+ <_clk 0x0>;
+clock-names = "clk_lcd", "clk_pll0";
+
+port {
+disp_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 4/7] drm/kmb: Keem Bay driver register definition
Register definitions for Keem Bay display driver v2: removed license text (Sam) v3: Squashed all 59 commits to one v4: review changes from Sam Ravnborg renamed dev_p to kmb v5: corrected spellings v6: corrected checkpatch warnings v7: removed redundant definitions v8: removed redundant definitions, clean up (Sam R) Signed-off-by: Anitha Chrisanthus Reviewed-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: Daniel Vetter --- drivers/gpu/drm/kmb/kmb_regs.h | 725 + 1 file changed, 725 insertions(+) create mode 100644 drivers/gpu/drm/kmb/kmb_regs.h diff --git a/drivers/gpu/drm/kmb/kmb_regs.h b/drivers/gpu/drm/kmb/kmb_regs.h new file mode 100644 index 000..4815056 --- /dev/null +++ b/drivers/gpu/drm/kmb/kmb_regs.h @@ -0,0 +1,725 @@ +/* SPDX-License-Identifier: GPL-2.0-only + * + * Copyright © 2018-2020 Intel Corporation + */ + +#ifndef __KMB_REGS_H__ +#define __KMB_REGS_H__ + +/*** + *LCD controller control register defines + ***/ +#define LCD_CONTROL(0x4 * 0x000) +#define LCD_CTRL_PROGRESSIVE (0 << 0) +#define LCD_CTRL_INTERLACED BIT(0) +#define LCD_CTRL_ENABLE BIT(1) +#define LCD_CTRL_VL1_ENABLE BIT(2) +#define LCD_CTRL_VL2_ENABLE BIT(3) +#define LCD_CTRL_GL1_ENABLE BIT(4) +#define LCD_CTRL_GL2_ENABLE BIT(5) +#define LCD_CTRL_ALPHA_BLEND_VL1 (0 << 6) +#define LCD_CTRL_ALPHA_BLEND_VL2 BIT(6) +#define LCD_CTRL_ALPHA_BLEND_GL1 (2 << 6) +#define LCD_CTRL_ALPHA_BLEND_GL2 (3 << 6) +#define LCD_CTRL_ALPHA_TOP_VL1 (0 << 8) +#define LCD_CTRL_ALPHA_TOP_VL2 BIT(8) +#define LCD_CTRL_ALPHA_TOP_GL1 (2 << 8) +#define LCD_CTRL_ALPHA_TOP_GL2 (3 << 8) +#define LCD_CTRL_ALPHA_MIDDLE_VL1(0 << 10) +#define LCD_CTRL_ALPHA_MIDDLE_VL2BIT(10) +#define LCD_CTRL_ALPHA_MIDDLE_GL1(2 << 10) +#define LCD_CTRL_ALPHA_MIDDLE_GL2(3 << 10) +#define LCD_CTRL_ALPHA_BOTTOM_VL1(0 << 12) +#define LCD_CTRL_ALPHA_BOTTOM_VL2BIT(12) +#define LCD_CTRL_ALPHA_BOTTOM_GL1(2 << 12) +#define LCD_CTRL_ALPHA_BOTTOM_GL2(3 << 12) +#define LCD_CTRL_TIM_GEN_ENABLE BIT(14) +#define LCD_CTRL_CONTINUOUS (0 << 15) +#define LCD_CTRL_ONE_SHOTBIT(15) +#define LCD_CTRL_PWM0_EN BIT(16) +#define LCD_CTRL_PWM1_EN BIT(17) +#define LCD_CTRL_PWM2_EN BIT(18) +#define LCD_CTRL_OUTPUT_DISABLED (0 << 19) +#define LCD_CTRL_OUTPUT_ENABLED BIT(19) +#define LCD_CTRL_BPORCH_ENABLE BIT(21) +#define LCD_CTRL_FPORCH_ENABLE BIT(22) +#define LCD_CTRL_PIPELINE_DMABIT(28) +#define LCD_CTRL_VHSYNC_IDLE_LVL BIT(31) + +/* interrupts */ +#define LCD_INT_STATUS (0x4 * 0x001) +#define LCD_INT_EOF BIT(0) +#define LCD_INT_LINE_CMP BIT(1) +#define LCD_INT_VERT_COMPBIT(2) +#define LAYER0_DMA_DONE BIT(3) +#define LAYER0_DMA_IDLE BIT(4) +#define LAYER0_DMA_FIFO_OVERFLOW BIT(5) +#define LAYER0_DMA_FIFO_UNDERFLOWBIT(6) +#define LAYER0_DMA_CB_FIFO_OVERFLOW BIT(7) +#define LAYER0_DMA_CB_FIFO_UNDERFLOW BIT(8) +#define LAYER0_DMA_CR_FIFO_OVERFLOW BIT(9) +#define LAYER0_DMA_CR_FIFO_UNDERFLOW BIT(10) +#define LAYER1_DMA_DONE BIT(11) +#define LAYER1_DMA_IDLE BIT(12) +#define LAYER1_DMA_FIFO_OVERFLOW BIT(13) +#define LAYER1_DMA_FIFO_UNDERFLOWBIT(14) +#define LAYER1_DMA_CB_FIFO_OVERFLOW BIT(15) +#define LAYER1_DMA_CB_FIFO_UNDERFLOW BIT(16) +#define LAYER1_DMA_CR_FIFO_OVERFLOW BIT(17) +#define LAYER1_DMA_CR_FIFO_UNDERFLOW BIT(18) +#define LAYER2_DMA_DONE BIT(19) +#define LAYER2_DMA_IDLE BIT(20) +#define LAYER2_DMA_FIFO_OVERFLOW BIT(21) +#define LAYER2_DMA_FIFO_UNDERFLOWBIT(22) +#define LAYER3_DMA_DONE BIT(23) +#define LAYER3_DMA_IDLE BIT(24) +#define LAYER3_DMA_FIFO_OVERFLOW BIT(25) +#define LAYER3_DMA_FIFO_UNDERFLOW
[PATCH v12 7/7] drm/kmb: Build files for KeemBay Display driver
v2: Added Maintainer entry v3: Added one more Maintainer entry v3: drop videomode_helpers Cc: Sam Ravnborg Signed-off-by: Anitha Chrisanthus Reviewed-by: Sam Ravnborg --- MAINTAINERS | 7 +++ drivers/gpu/drm/Kconfig | 2 ++ drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/kmb/Kconfig | 12 drivers/gpu/drm/kmb/Makefile | 2 ++ 5 files changed, 24 insertions(+) create mode 100644 drivers/gpu/drm/kmb/Kconfig create mode 100644 drivers/gpu/drm/kmb/Makefile diff --git a/MAINTAINERS b/MAINTAINERS index 71e29dc..c82ea76 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8961,6 +8961,13 @@ M: Deepak Saxena S: Maintained F: drivers/char/hw_random/ixp4xx-rng.c +INTEL KEEMBAY DRM DRIVER +M: Anitha Chrisanthus +M: Edmund Dea +S: Maintained +F: Documentation/devicetree/bindings/display/intel,kmb_display.yaml +F: drivers/gpu/drm/kmb/ + INTEL MANAGEMENT ENGINE (mei) M: Tomas Winkler L: linux-ker...@vger.kernel.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 64376dd..3dc293c 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -268,6 +268,8 @@ source "drivers/gpu/drm/nouveau/Kconfig" source "drivers/gpu/drm/i915/Kconfig" +source "drivers/gpu/drm/kmb/Kconfig" + config DRM_VGEM tristate "Virtual GEM provider" depends on DRM diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 8156900..fefaff4c 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/ obj-$(CONFIG_DRM_MGA) += mga/ obj-$(CONFIG_DRM_I810) += i810/ obj-$(CONFIG_DRM_I915) += i915/ +obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ diff --git a/drivers/gpu/drm/kmb/Kconfig b/drivers/gpu/drm/kmb/Kconfig new file mode 100644 index 000..2dd7e68 --- /dev/null +++ b/drivers/gpu/drm/kmb/Kconfig @@ -0,0 +1,12 @@ +config DRM_KMB_DISPLAY + tristate "INTEL KEEMBAY DISPLAY" + depends on DRM && OF && (ARM || ARM64) + depends on COMMON_CLK + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + help + Choose this option if you have Intel's KeemBay SOC which integrates + an ARM Cortex A53 CPU with an Intel Movidius VPU. + + If M is selected the module will be called kmb-drm. diff --git a/drivers/gpu/drm/kmb/Makefile b/drivers/gpu/drm/kmb/Makefile new file mode 100644 index 000..527d737 --- /dev/null +++ b/drivers/gpu/drm/kmb/Makefile @@ -0,0 +1,2 @@ +kmb-drm-y := kmb_crtc.o kmb_drv.o kmb_plane.o kmb_dsi.o +obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb-drm.o -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the drm-intel-fixes tree
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'gen12_emit_fini_breadcrumb':
drivers/gpu/drm/i915/gt/intel_lrc.c:4998:31: error: implicit declaration of
function '__gen8_emit_flush_dw'; did you mean 'gen8_emit_flush'?
[-Werror=implicit-function-declaration]
4998 | cs = emit_xcs_breadcrumb(rq, __gen8_emit_flush_dw(cs, 0, 0, 0));
| ^~~~
| gen8_emit_flush
drivers/gpu/drm/i915/gt/intel_lrc.c:4998:31: warning: passing argument 2 of
'emit_xcs_breadcrumb' makes pointer from integer without a cast
[-Wint-conversion]
4998 | cs = emit_xcs_breadcrumb(rq, __gen8_emit_flush_dw(cs, 0, 0, 0));
| ^
| |
| int
drivers/gpu/drm/i915/gt/intel_lrc.c:4902:63: note: expected 'u32 *' {aka
'unsigned int *'} but argument is of type 'int'
4902 | static u32 *emit_xcs_breadcrumb(struct i915_request *rq, u32 *cs)
| ~^~
Caused by commit
c94d65d2ff6d ("drm/i915/gt: Flush xcs before tgl breadcrumbs")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpztz9ibfYV_.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/edid: Fix uninitialized variable in drm_cvt_modes()
On Tue, Nov 3, 2020 at 5:15 PM Lyude Paul wrote:
>
> Noticed this when trying to compile with -Wall on a kernel fork. We
> potentially
> don't set width here, which causes the compiler to complain about width
> potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
>
> Changes since v1:
> * Don't emit an error as this code isn't reachable, just mark it as such
>
> Signed-off-by: Lyude Paul
>
> Cc: # v5.9+
> Fixes: 3f649ab728cd ("treewide: Remove uninitialized_var() usage")
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_edid.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 631125b46e04..0643b98c6383 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3094,6 +3094,7 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
>
> for (i = 0; i < 4; i++) {
> int width, height;
> + u8 cvt_aspect_ratio;
>
> cvt = &(timing->data.other_data.data.cvt[i]);
>
> @@ -3101,7 +3102,8 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
> continue;
>
> height = (cvt->code[0] + ((cvt->code[1] & 0xf0) << 4) + 1) *
> 2;
> - switch (cvt->code[1] & 0x0c) {
> + cvt_aspect_ratio = cvt->code[1] & 0x0c;
The temp var doesn't do anything now right? Previously you were using
it in the print, but now you can drop these two hunks, I think?
-ilia
> + switch (cvt_aspect_ratio) {
> case 0x00:
> width = height * 4 / 3;
> break;
> @@ -3114,6 +3116,8 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
> case 0x0c:
> width = height * 15 / 9;
> break;
> + default:
> + unreachable();
> }
>
> for (j = 1; j < 5; j++) {
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next pull for 5.10-rc1
On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote:
> drm/nouveau/kms: Search for encoders' connectors properly
This commit (09838c4efe9a) broke boot for me. These two hunks in
particular:
@ -2066,7 +2120,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state
*state)
outp->clr.mask, outp->set.mask);
if (outp->clr.mask) {
- help->disable(encoder);
+ help->atomic_disable(encoder, state);
interlock[NV50_DISP_INTERLOCK_CORE] |= 1;
if (outp->flush_disable) {
nv50_disp_atomic_commit_wndw(state, interlock);
@@ -2105,7 +2159,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state
*state)
outp->set.mask, outp->clr.mask);
if (outp->set.mask) {
- help->enable(encoder);
+ help->atomic_enable(encoder, state);
interlock[NV50_DISP_INTERLOCK_CORE] = 1;
}
I hacked up patch to use help->disable/help->enable if atomic_ versions
are NULL. It worked.
In my setup I stepped onto nv50_msto_help->atomic_enable == NULL. But
there are two more drm_encoder_helper_funcs in dispnv50/disp.c that don't
have atomic_enable/disable set: nv50_dac_help, nv50_pior_help.
--
Kirill A. Shutemov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/virt: fix handling of the atomic flag
On 2020-11-03 4:54 p.m., Alex Deucher wrote:
> Use the per device drm driver feature flags rather than the
> global one. This way we can make the drm driver struct const.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
Yeah, that's a good change.
Regards,
Luben
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index d0aea5e39531..8aff6ef50f91 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -47,11 +47,13 @@ bool amdgpu_virt_mmio_blocked(struct amdgpu_device *adev)
>
> void amdgpu_virt_init_setting(struct amdgpu_device *adev)
> {
> + struct drm_device *ddev = adev_to_drm(adev);
> +
> /* enable virtual display */
> if (adev->mode_info.num_crtc == 0)
> adev->mode_info.num_crtc = 1;
> adev->enable_virtual_display = true;
> - adev_to_drm(adev)->driver->driver_features &= ~DRIVER_ATOMIC;
> + ddev->driver_features &= ~DRIVER_ATOMIC;
> adev->cg_flags = 0;
> adev->pg_flags = 0;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/edid: Fix uninitialized variable in drm_cvt_modes()
Noticed this when trying to compile with -Wall on a kernel fork. We potentially
don't set width here, which causes the compiler to complain about width
potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
Changes since v1:
* Don't emit an error as this code isn't reachable, just mark it as such
Signed-off-by: Lyude Paul
Cc: # v5.9+
Fixes: 3f649ab728cd ("treewide: Remove uninitialized_var() usage")
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_edid.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 631125b46e04..0643b98c6383 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3094,6 +3094,7 @@ static int drm_cvt_modes(struct drm_connector *connector,
for (i = 0; i < 4; i++) {
int width, height;
+ u8 cvt_aspect_ratio;
cvt = &(timing->data.other_data.data.cvt[i]);
@@ -3101,7 +3102,8 @@ static int drm_cvt_modes(struct drm_connector *connector,
continue;
height = (cvt->code[0] + ((cvt->code[1] & 0xf0) << 4) + 1) * 2;
- switch (cvt->code[1] & 0x0c) {
+ cvt_aspect_ratio = cvt->code[1] & 0x0c;
+ switch (cvt_aspect_ratio) {
case 0x00:
width = height * 4 / 3;
break;
@@ -3114,6 +3116,8 @@ static int drm_cvt_modes(struct drm_connector *connector,
case 0x0c:
width = height * 15 / 9;
break;
+ default:
+ unreachable();
}
for (j = 1; j < 5; j++) {
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 11/15] PCI: Obey iomem restrictions for procfs mmap
On Tue, Nov 3, 2020 at 1:28 PM Bjorn Helgaas wrote:
>
> On Fri, Oct 30, 2020 at 11:08:11AM +0100, Daniel Vetter wrote:
> > There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
> > files, and the old proc interface. Two check against
> > iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
> > this starts to matter, since we don't want random userspace having
> > access to PCI BARs while a driver is loaded and using it.
> >
> > Fix this by adding the same iomem_is_exclusive() check we already have
> > on the sysfs side in pci_mmap_resource().
> >
> > References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
> > Signed-off-by: Daniel Vetter
>
> This is OK with me but it looks like IORESOURCE_EXCLUSIVE is currently
> only used in a few places:
>
> e1000_probe() calls pci_request_selected_regions_exclusive(),
> ne_pci_probe() calls pci_request_regions_exclusive(),
> vmbus_allocate_mmio() calls request_mem_region_exclusive()
>
> which raises the question of whether it's worth keeping
> IORESOURCE_EXCLUSIVE at all. I'm totally fine with removing it
> completely.
Now that CONFIG_IO_STRICT_DEVMEM upgrades IORESOURCE_BUSY to
IORESOURCE_EXCLUSIVE semantics the latter has lost its meaning so I'd
be in favor of removing it as well.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu/virt: fix handling of the atomic flag
Use the per device drm driver feature flags rather than the
global one. This way we can make the drm driver struct const.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index d0aea5e39531..8aff6ef50f91 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -47,11 +47,13 @@ bool amdgpu_virt_mmio_blocked(struct amdgpu_device *adev)
void amdgpu_virt_init_setting(struct amdgpu_device *adev)
{
+ struct drm_device *ddev = adev_to_drm(adev);
+
/* enable virtual display */
if (adev->mode_info.num_crtc == 0)
adev->mode_info.num_crtc = 1;
adev->enable_virtual_display = true;
- adev_to_drm(adev)->driver->driver_features &= ~DRIVER_ATOMIC;
+ ddev->driver_features &= ~DRIVER_ATOMIC;
adev->cg_flags = 0;
adev->pg_flags = 0;
}
--
2.25.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 15/15] PCI: Revoke mappings like devmem
On Fri, Oct 30, 2020 at 11:08:15AM +0100, Daniel Vetter wrote:
> Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> the region") /dev/kmem zaps ptes when the kernel requests exclusive
> acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> the default for all driver uses.
>
> Except there's two more ways to access PCI BARs: sysfs and proc mmap
> support. Let's plug that hole.
>
> For revoke_devmem() to work we need to link our vma into the same
> address_space, with consistent vma->vm_pgoff. ->pgoff is already
> adjusted, because that's how (io_)remap_pfn_range works, but for the
> mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
> to adjust this at at ->open time:
>
> - for sysfs this is easy, now that binary attributes support this. We
> just set bin_attr->mapping when mmap is supported
> - for procfs it's a bit more tricky, since procfs pci access has only
> one file per device, and access to a specific resources first needs
> to be set up with some ioctl calls. But mmap is only supported for
> the same resources as sysfs exposes with mmap support, and otherwise
> rejected, so we can set the mapping unconditionally at open time
> without harm.
>
> A special consideration is for arch_can_pci_mmap_io() - we need to
> make sure that the ->f_mapping doesn't alias between ioport and iomem
> space. There's only 2 ways in-tree to support mmap of ioports: generic
> pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
> architecture hand-rolling. Both approach support ioport mmap through a
> special pfn range and not through magic pte attributes. Aliasing is
> therefore not a problem.
>
> The only difference in access checks left is that sysfs PCI mmap does
> not check for CAP_RAWIO. I'm not really sure whether that should be
> added or not.
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: Greg Kroah-Hartman
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Daniel Vetter
Acked-by: Bjorn Helgaas
> --
> v2:
> - Totally new approach: Adjust filp->f_mapping at open time. Note that
> this now works on all architectures, not just those support
> ARCH_GENERIC_PCI_MMAP_RESOURCE
> ---
> drivers/pci/pci-sysfs.c | 4
> drivers/pci/proc.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index d15c881e2e7e..3f1c31bc0b7c 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -929,6 +929,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> b->legacy_io->read = pci_read_legacy_io;
> b->legacy_io->write = pci_write_legacy_io;
> b->legacy_io->mmap = pci_mmap_legacy_io;
> + b->legacy_io->mapping = iomem_get_mapping();
> pci_adjust_legacy_attr(b, pci_mmap_io);
> error = device_create_bin_file(>dev, b->legacy_io);
> if (error)
> @@ -941,6 +942,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> b->legacy_mem->size = 1024*1024;
> b->legacy_mem->attr.mode = 0600;
> b->legacy_mem->mmap = pci_mmap_legacy_mem;
> + b->legacy_io->mapping = iomem_get_mapping();
> pci_adjust_legacy_attr(b, pci_mmap_mem);
> error = device_create_bin_file(>dev, b->legacy_mem);
> if (error)
> @@ -1156,6 +1158,8 @@ static int pci_create_attr(struct pci_dev *pdev, int
> num, int write_combine)
> res_attr->mmap = pci_mmap_resource_uc;
> }
> }
> + if (res_attr->mmap)
> + res_attr->mapping = iomem_get_mapping();
> res_attr->attr.name = res_attr_name;
> res_attr->attr.mode = 0600;
> res_attr->size = pci_resource_len(pdev, num);
> diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
> index 3a2f90beb4cb..9bab07302bbf 100644
> --- a/drivers/pci/proc.c
> +++ b/drivers/pci/proc.c
> @@ -298,6 +298,7 @@ static int proc_bus_pci_open(struct inode *inode, struct
> file *file)
> fpriv->write_combine = 0;
>
> file->private_data = fpriv;
> + file->f_mapping = iomem_get_mapping();
>
> return 0;
> }
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 11/15] PCI: Obey iomem restrictions for procfs mmap
On Fri, Oct 30, 2020 at 11:08:11AM +0100, Daniel Vetter wrote:
> There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
> files, and the old proc interface. Two check against
> iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
> this starts to matter, since we don't want random userspace having
> access to PCI BARs while a driver is loaded and using it.
>
> Fix this by adding the same iomem_is_exclusive() check we already have
> on the sysfs side in pci_mmap_resource().
>
> References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
> Signed-off-by: Daniel Vetter
This is OK with me but it looks like IORESOURCE_EXCLUSIVE is currently
only used in a few places:
e1000_probe() calls pci_request_selected_regions_exclusive(),
ne_pci_probe() calls pci_request_regions_exclusive(),
vmbus_allocate_mmio() calls request_mem_region_exclusive()
which raises the question of whether it's worth keeping
IORESOURCE_EXCLUSIVE at all. I'm totally fine with removing it
completely.
But if you want it,
Acked-by: Bjorn Helgaas
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Daniel Vetter
> --
> v2: Improve commit message (Bjorn)
> ---
> drivers/pci/proc.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
> index d35186b01d98..3a2f90beb4cb 100644
> --- a/drivers/pci/proc.c
> +++ b/drivers/pci/proc.c
> @@ -274,6 +274,11 @@ static int proc_bus_pci_mmap(struct file *file, struct
> vm_area_struct *vma)
> else
> return -EINVAL;
> }
> +
> + if (dev->resource[i].flags & IORESOURCE_MEM &&
> + iomem_is_exclusive(dev->resource[i].start))
> + return -EINVAL;
> +
> ret = pci_mmap_page_range(dev, i, vma,
> fpriv->mmap_state, write_combine);
> if (ret < 0)
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 2/7] dt-bindings: display: Intel KeemBay MSSCAM
Hi Anitha.
On Tue, Nov 03, 2020 at 11:34:28AM -0800, Anitha Chrisanthus wrote:
> This patch add bindings for Intel KeemBay MSSCAM syscon
>
> Signed-off-by: Anitha Chrisanthus
> Cc: Sam Ravnborg
> Cc: Neil Armstrong
> Cc: Rob Herring
> ---
> .../bindings/display/intel,keembay-msscam.yaml | 36
> ++
> 1 file changed, 36 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
> b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
> new file mode 100644
> index 000..10ed8d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
> @@ -0,0 +1,36 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/intel,keembay-msscam.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Devicetree bindings for Intel Keem Bay MSSCAM
Here I had expected a short description of what it is used for.
And maybe even an explanation for the msscam abbrevation it this can be
made public.
> +
> +maintainers:
> + - Anitha Chrisanthus
> + - Edmond J Dea
> +
> +properties:
> + compatible:
> +const: intel,keembay-msscam, syscon
This will not work - it needs to look something like:
compatible:
items:
- const: intel,keembay-msscam
- const: syscon
See for example arm/freescale/fsl,imx7ulp-sim.yaml
Other than the above it looks good.
Sam
> +
> + reg:
> +maxItems: 1
> +
> + reg-io-width:
> +const: 4
> +
> +required:
> + - compatible
> + - reg
> + - reg-io-width
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +msscam:msscam@2091 {
> +compatible = "intel,keembay-msscam", "syscon";
> +reg = <0x2091 0x30>;
> +reg-io-width = <4>;
> +};
> --
> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bugreport] [5.10-rc1] Oops: 0000 [#1] SMP NOPTI bug which always starts as page allocation failure
Hi folks. I observed hard reproductible the set of bugs. It always started as 1) kworker/u64:2: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 Continious as: 2) WARNING: CPU: 21 PID: 806649 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7505 amdgpu_dm_atomic_commit_tail+0x23bd/0x24e0 [amdgpu] And ended as: 3) BUG: unable to handle page fault for address: 00012488 Which annoing because lead to completely computer hang. Example of one log: [11561.927250] kworker/u64:10: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 [11561.927472] CPU: 18 PID: 39985 Comm: kworker/u64:10 Not tainted 5.10.0-0.rc1.20201028gited8780e3f2ec.57.fc34.x86_64 #1 [11561.927475] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 2802 10/21/2020 [11561.927485] Workqueue: events_unbound commit_work [drm_kms_helper] [11561.927489] Call Trace: [11561.927496] dump_stack+0x8b/0xb0 [11561.927501] warn_alloc.cold+0x75/0xd9 [11561.927507] ? _cond_resched+0x16/0x50 [11561.927512] ? __alloc_pages_direct_compact+0x159/0x180 [11561.927518] __alloc_pages_slowpath.constprop.0+0x103f/0x1070 [11561.927531] __alloc_pages_nodemask+0x37d/0x400 [11561.927538] kmalloc_order+0x33/0xc0 [11561.927542] kmalloc_order_trace+0x19/0x110 [11561.927614] dc_create_state+0x26/0x60 [amdgpu] [11561.927677] amdgpu_dm_atomic_commit_tail+0x1cee/0x24e0 [amdgpu] [11561.927686] ? find_busiest_group+0x33/0x350 [11561.927698] ? __lock_acquire+0x3b0/0x21f0 [11561.927707] ? lock_acquire+0xc8/0x400 [11561.927710] ? wait_for_completion_timeout+0x3b/0xf0 [11561.927715] ? mark_held_locks+0x50/0x80 [11561.927719] ? lockdep_hardirqs_on_prepare+0xff/0x180 [11561.927722] ? _raw_spin_unlock_irq+0x24/0x40 [11561.927726] ? _raw_spin_unlock_irq+0x24/0x40 [11561.927729] ? wait_for_completion_timeout+0xdb/0xf0 [11561.927740] commit_tail+0x94/0x130 [drm_kms_helper] [11561.927745] process_one_work+0x27d/0x5b0 [11561.927753] worker_thread+0x55/0x3c0 [11561.927756] ? process_one_work+0x5b0/0x5b0 [11561.927760] kthread+0x13a/0x150 [11561.927763] ? __kthread_bind_mask+0x60/0x60 [11561.927769] ret_from_fork+0x22/0x30 [11561.927809] Mem-Info: [11561.927816] active_anon:933848 inactive_anon:4558268 isolated_anon:118 active_file:154021 inactive_file:80446 isolated_file:0 unevictable:1586 dirty:32469 writeback:700 slab_reclaimable:185330 slab_unreclaimable:176202 mapped:514440 shmem:592199 pagetables:81732 bounce:0 free:99082 free_pcp:2104 free_cma:0 [11561.927820] Node 0 active_anon:3735392kB inactive_anon:18233072kB active_file:616084kB inactive_file:321784kB unevictable:6344kB isolated(anon):472kB isolated(file):0kB mapped:2057760kB dirty:129876kB writeback:2800kB shmem:2368796kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:8kB kernel_stack:96608kB all_unreclaimable? no [11561.927824] Node 0 DMA free:11800kB min:32kB low:44kB high:56kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15900kB mlocked:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [11561.927829] lowmem_reserve[]: 0 3136 31809 31809 31809 [11561.927839] Node 0 DMA32 free:142632kB min:26264kB low:29472kB high:32680kB reserved_highatomic:0KB active_anon:131568kB inactive_anon:1625184kB active_file:57556kB inactive_file:13532kB unevictable:0kB writepending:2428kB present:3317760kB managed:3317572kB mlocked:0kB pagetables:25624kB bounce:0kB free_pcp:1764kB local_pcp:0kB free_cma:0kB [11561.927844] lowmem_reserve[]: 0 0 28673 28673 28673 [11561.927854] Node 0 Normal free:241896kB min:240300kB low:269660kB high:299020kB reserved_highatomic:2048KB active_anon:3603472kB inactive_anon:16607812kB active_file:558660kB inactive_file:308056kB unevictable:6344kB writepending:130596kB present:30133248kB managed:29370624kB mlocked:6344kB pagetables:301304kB bounce:0kB free_pcp:6656kB local_pcp:60kB free_cma:0kB [11561.927859] lowmem_reserve[]: 0 0 0 0 0 [11561.927871] Node 0 DMA: 0*4kB 1*8kB (U) 1*16kB (U) 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 2*4096kB (M) = 11800kB [11561.927900] Node 0 DMA32: 15432*4kB (UME) 4963*8kB (UME) 2169*16kB (UME) 201*32kB (UM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 142568kB [11561.927923] Node 0 Normal: 49027*4kB (UMEH) 5656*8kB (MH) 20*16kB (H) 10*32kB (H) 2*64kB (H) 2*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 242380kB [11561.927951] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [11561.927954] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [11561.927956] 847580 total pagecache pages [11561.927967] 19862 pages in swap cache
[PATCH 5.9 267/391] drm/shme-helpers: Fix dma_buf_mmap forwarding bug
From: Daniel Vetter
commit f49a51bfdc8ea717c97ccd4cc98b7e6daaa5553a upstream.
When we forward an mmap to the dma_buf exporter, they get to own
everything. Unfortunately drm_gem_mmap_obj() overwrote
vma->vm_private_data after the driver callback, wreaking the
exporter complete. This was noticed because vb2_common_vm_close blew
up on mali gpu with panfrost after commit 26d3ac3cb04d
("drm/shmem-helpers: Redirect mmap for imported dma-buf").
Unfortunately drm_gem_mmap_obj also acquires a surplus reference that
we need to drop in shmem helpers, which is a bit of a mislayer
situation. Maybe the entire dma_buf_mmap forwarding should be pulled
into core gem code.
Note that the only two other drivers which forward mmap in their own
code (etnaviv and exynos) get this somewhat right by overwriting the
gem mmap code. But they seem to still have the leak. This might be a
good excuse to move these drivers over to shmem helpers completely.
Reviewed-by: Boris Brezillon
Acked-by: Christian König
Cc: Christian König
Cc: Sumit Semwal
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf")
Cc: Boris Brezillon
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Cc: Rob Herring
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: # v5.9+
Reported-and-tested-by: piotr.oniszc...@gmail.com
Cc: piotr.oniszc...@gmail.com
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201027214922.3566743-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_gem.c |4 ++--
drivers/gpu/drm/drm_gem_shmem_helper.c |7 ++-
2 files changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1085,6 +1085,8 @@ int drm_gem_mmap_obj(struct drm_gem_obje
*/
drm_gem_object_get(obj);
+ vma->vm_private_data = obj;
+
if (obj->funcs && obj->funcs->mmap) {
ret = obj->funcs->mmap(obj, vma);
if (ret) {
@@ -1107,8 +1109,6 @@ int drm_gem_mmap_obj(struct drm_gem_obje
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
}
- vma->vm_private_data = obj;
-
return 0;
}
EXPORT_SYMBOL(drm_gem_mmap_obj);
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -594,8 +594,13 @@ int drm_gem_shmem_mmap(struct drm_gem_ob
/* Remove the fake offset */
vma->vm_pgoff -= drm_vma_node_start(>vma_node);
- if (obj->import_attach)
+ if (obj->import_attach) {
+ /* Drop the reference drm_gem_mmap_obj() acquired.*/
+ drm_gem_object_put(obj);
+ vma->vm_private_data = NULL;
+
return dma_buf_mmap(obj->dma_buf, vma, 0);
+ }
shmem = to_drm_gem_shmem_obj(obj);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as user memory region
On Tue, Nov 3, 2020 at 6:36 PM Xiong, Jianxin wrote: > > > > -Original Message- > > From: Daniel Vetter > > Sent: Friday, October 23, 2020 6:45 PM > > To: Jason Gunthorpe > > Cc: Xiong, Jianxin ; linux-rdma > > ; dri-devel ; > > Leon > > Romanovsky ; Doug Ledford ; Vetter, > > Daniel ; Christian Koenig > > > > Subject: Re: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as user > > memory region > > > > > > > + > > > > > +#ifdef CONFIG_DMA_VIRT_OPS > > > > > + if (device->dma_device->dma_ops == _virt_ops) > > > > > + return ERR_PTR(-EINVAL); #endif > > > > > > > > Maybe I'm confused, but should we have this check in dma_buf_attach, > > > > or at least in dma_buf_dynamic_attach? The p2pdma functions use that > > > > too, and I can't imagine how zerocopy should work (which is like the > > > > entire point of > > > > dma-buf) when we have dma_virt_ops. > > > > > > The problem is we have RDMA drivers that assume SGL's have a valid > > > struct page, and these hacky/wrong P2P sgls that DMABUF creates cannot > > > be passed into those drivers. > > > > > > But maybe this is just a 'drivers are using it wrong' if they call > > > this function and expect struct pages.. > > > > > > The check in the p2p stuff was done to avoid this too, but it was on a > > > different flow. > > > > Yeah definitely don't call dma_buf_map_attachment and expect a page back. > > In practice you'll get a page back fairly often, but I don't think > > we want to bake that in, maybe we eventually get to non-hacky dma_addr_t > > only sgl. > > > > What I'm wondering is whether dma_buf_attach shouldn't reject such devices > > directly, instead of each importer having to do that. > > Come back here to see if consensus can be reached on who should do the check. > My > thinking is that it could be over restrictive for dma_buf_attach to always > reject > dma_virt_ops. According to dma-buf documentation the back storage would be > moved to system area upon mapping unless p2p is requested and can be supported > by the exporter. The sg_list for system memory would have struct page present. So I'm not clear on what this dma_virt_ops stuff is for, but if it's an entirely virtual device with cpu access, then you shouldn't do dma_buf_map_attachment, and then peek at the struct page in the sgl. Instead you need to use dma_buf_vmap/vunmap and dma_buf_begin/end_cpu_access. Otherwise the coherency managed is all potentially busted. Also note that cpu access from the kernel to dma-buf is a rather niche feature (only some usb device drivers use it), so expect warts. If this is the case, then I think dma_buf_attach should check for this and reject such imports, since that's an importer bug. If it's otoh something rdma specific, then I guess rdma checking for this is ok. As a third option, if it's something about the connectivity between the importing and exporting device, then this should be checked in the ->attach callback the exporter can provide, like the p2p check. The idea here is that for device specific remapping units (mostly found ond SoC, and not something like a standard iommu managed by the dma-api), some of which can even do funny stuff like rotation of 2d images, can be access by some, but not other. And only the exporter is aware of these restrictions. Now I dunno which case this one here is. -Daniel -- 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] drm/edid: Fix uninitialized variable in drm_cvt_modes()
On Tue, 2020-11-03 at 14:53 -0500, Ilia Mirkin wrote:
> On Tue, Nov 3, 2020 at 2:47 PM Lyude Paul wrote:
> >
> > Sorry! Thought I had responded to this but apparently not, comments down
> > below
> >
> > On Thu, 2020-10-22 at 14:04 -0400, Ilia Mirkin wrote:
> > > On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote:
> > > >
> > > > Noticed this when trying to compile with -Wall on a kernel fork. We
> > > > potentially
> > > > don't set width here, which causes the compiler to complain about width
> > > > potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
> > > >
> > > > Signed-off-by: Lyude Paul
> > > >
> > > > Cc: # v5.9+
> > > > Fixes: 3f649ab728cd ("treewide: Remove uninitialized_var() usage")
> > > > Signed-off-by: Lyude Paul
> > > > ---
> > > > drivers/gpu/drm/drm_edid.c | 8 +++-
> > > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index 631125b46e04..2da158ffed8e 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -3094,6 +3094,7 @@ static int drm_cvt_modes(struct drm_connector
> > > > *connector,
> > > >
> > > > for (i = 0; i < 4; i++) {
> > > > int width, height;
> > > > + u8 cvt_aspect_ratio;
> > > >
> > > > cvt = &(timing->data.other_data.data.cvt[i]);
> > > >
> > > > @@ -3101,7 +3102,8 @@ static int drm_cvt_modes(struct drm_connector
> > > > *connector,
> > > > continue;
> > > >
> > > > height = (cvt->code[0] + ((cvt->code[1] & 0xf0) << 4) +
> > > > 1) *
> > > > 2;
> > > > - switch (cvt->code[1] & 0x0c) {
> > > > + cvt_aspect_ratio = cvt->code[1] & 0x0c;
> > > > + switch (cvt_aspect_ratio) {
> > > > case 0x00:
> > > > width = height * 4 / 3;
> > > > break;
> > > > @@ -3114,6 +3116,10 @@ static int drm_cvt_modes(struct drm_connector
> > > > *connector,
> > > > case 0x0c:
> > > > width = height * 15 / 9;
> > > > break;
> > > > + default:
> > >
> > > What value would cvt->code[1] have such that this gets hit?
> > >
> > > Or is this a "compiler is broken, so let's add more code" situation?
> > > If so, perhaps the code added could just be enough to silence the
> > > compiler (unreachable, etc)?
> >
> > I mean, this information comes from the EDID which inherently means it's
> > coming
> > from an untrusted source so the value could be literally anything as long as
> > the
> > EDID has a valid checksum. Note (assuming I'm understanding this code
> > correctly):
> >
> > drm_add_edid_modes() → add_cvt_modes() → drm_for_each_detailed_block() →
> > do_cvt_mode() → drm_cvt_modes()
> >
> > So afaict this isn't a broken compiler but a legitimate uninitialized
> > variable.
>
> The value can be anything, but it has to be something. The switch is
> on "unknown & 0x0c", so only 4 cases are possible, which are
> enumerated in the switch.
oops, you're completely right lol. will figure out what the unreachable macro in
the kernel is and use that in a respin of this patch
>
> -ilia
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Fix uninitialized variable in drm_cvt_modes()
On Tue, Nov 3, 2020 at 2:47 PM Lyude Paul wrote:
>
> Sorry! Thought I had responded to this but apparently not, comments down below
>
> On Thu, 2020-10-22 at 14:04 -0400, Ilia Mirkin wrote:
> > On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote:
> > >
> > > Noticed this when trying to compile with -Wall on a kernel fork. We
> > > potentially
> > > don't set width here, which causes the compiler to complain about width
> > > potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
> > >
> > > Signed-off-by: Lyude Paul
> > >
> > > Cc: # v5.9+
> > > Fixes: 3f649ab728cd ("treewide: Remove uninitialized_var() usage")
> > > Signed-off-by: Lyude Paul
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 8 +++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 631125b46e04..2da158ffed8e 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3094,6 +3094,7 @@ static int drm_cvt_modes(struct drm_connector
> > > *connector,
> > >
> > > for (i = 0; i < 4; i++) {
> > > int width, height;
> > > + u8 cvt_aspect_ratio;
> > >
> > > cvt = &(timing->data.other_data.data.cvt[i]);
> > >
> > > @@ -3101,7 +3102,8 @@ static int drm_cvt_modes(struct drm_connector
> > > *connector,
> > > continue;
> > >
> > > height = (cvt->code[0] + ((cvt->code[1] & 0xf0) << 4) +
> > > 1) *
> > > 2;
> > > - switch (cvt->code[1] & 0x0c) {
> > > + cvt_aspect_ratio = cvt->code[1] & 0x0c;
> > > + switch (cvt_aspect_ratio) {
> > > case 0x00:
> > > width = height * 4 / 3;
> > > break;
> > > @@ -3114,6 +3116,10 @@ static int drm_cvt_modes(struct drm_connector
> > > *connector,
> > > case 0x0c:
> > > width = height * 15 / 9;
> > > break;
> > > + default:
> >
> > What value would cvt->code[1] have such that this gets hit?
> >
> > Or is this a "compiler is broken, so let's add more code" situation?
> > If so, perhaps the code added could just be enough to silence the
> > compiler (unreachable, etc)?
>
> I mean, this information comes from the EDID which inherently means it's
> coming
> from an untrusted source so the value could be literally anything as long as
> the
> EDID has a valid checksum. Note (assuming I'm understanding this code
> correctly):
>
> drm_add_edid_modes() → add_cvt_modes() → drm_for_each_detailed_block() →
> do_cvt_mode() → drm_cvt_modes()
>
> So afaict this isn't a broken compiler but a legitimate uninitialized
> variable.
The value can be anything, but it has to be something. The switch is
on "unknown & 0x0c", so only 4 cases are possible, which are
enumerated in the switch.
-ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/nouveau: Add a dedicated mutex for the clients list
Rather than protecting the nouveau_drm clients list with the lock within
the "client" nouveau_cli, add a dedicated lock to serialize access to
the list. This is both clearer and necessary to avoid lockdep being
upset with us when we need to iterate through all the clients in the
list and potentially lock their mutex, which is the same class as the
lock protecting the entire list.
Signed-off-by: Jeremy Cline
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +
drivers/gpu/drm/nouveau/nouveau_drv.h | 5 +
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 4fe4d664c5f2..d182b877258a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -557,6 +557,7 @@ nouveau_drm_device_init(struct drm_device *dev)
nvkm_dbgopt(nouveau_debug, "DRM");
INIT_LIST_HEAD(>clients);
+ mutex_init(>clients_lock);
spin_lock_init(>tile.lock);
/* workaround an odd issue on nvc1 by disabling the device's
@@ -1089,9 +1090,9 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file
*fpriv)
fpriv->driver_priv = cli;
- mutex_lock(>client.mutex);
+ mutex_lock(>clients_lock);
list_add(>head, >clients);
- mutex_unlock(>client.mutex);
+ mutex_unlock(>clients_lock);
done:
if (ret && cli) {
@@ -1117,9 +1118,9 @@ nouveau_drm_postclose(struct drm_device *dev, struct
drm_file *fpriv)
nouveau_abi16_fini(cli->abi16);
mutex_unlock(>mutex);
- mutex_lock(>client.mutex);
+ mutex_lock(>clients_lock);
list_del(>head);
- mutex_unlock(>client.mutex);
+ mutex_unlock(>clients_lock);
nouveau_cli_fini(cli);
kfree(cli);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 9d04d1b36434..550e5f335146 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -141,6 +141,11 @@ struct nouveau_drm {
struct list_head clients;
+ /**
+* @clients_lock: Protects access to the @clients list of
nouveau_cli.
+*/
+ struct mutex clients_lock;
+
u8 old_pm_cap;
struct {
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/nouveau: fix a use-after-free in postclose()
This series fixes a number of use-after-frees in nouveau's postclose() handler. It was discovered by pointing IGT's core_hotunplug tests at a nouveau device, but the steps to reproduce it are simple: 1. Open the device file 2. Unbind the driver or remove the device 3. Close the file opened in step 1. During the device removal, the nouveau_drm structure is de-allocated, but is dereferenced in the postclose() handler. One obvious solution is to ensure all the operations in the postclose() handler are valid by extending the lifetime of the nouveau_drm structure. This is possible with the new devm_drm_dev_alloc() interface, but the change is somewhat invasive so I thought it best to submit that work separately. Instead, we make use of the drm_dev_unplug() API, clean up all clients in the device removal call, and check to make sure the device has not been unplugged in the postclose() handler. While this does not enable hot-unplug support for nouveau, it's enough to avoid crashing the kernel and leads to all the core_hotunplug tests to pass. Jeremy Cline (3): drm/nouveau: use drm_dev_unplug() during device removal drm/nouveau: Add a dedicated mutex for the clients list drm/nouveau: clean up all clients on device removal drivers/gpu/drm/nouveau/nouveau_drm.c | 39 +++ drivers/gpu/drm/nouveau/nouveau_drv.h | 5 2 files changed, 39 insertions(+), 5 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/nouveau: use drm_dev_unplug() during device removal
Nouveau does not currently support hot-unplugging, but it still makes sense to switch from drm_dev_unregister() to drm_dev_unplug(). drm_dev_unplug() calls drm_dev_unregister() after marking the device as unplugged, but only after any device critical sections are finished. Since nouveau isn't using drm_dev_enter() and drm_dev_exit(), there are no critical sections so this is nearly functionally equivalent. However, the DRM layer does check to see if the device is unplugged, and if it is returns appropriate error codes. In the future nouveau can add critical sections in order to truly support hot-unplugging. Signed-off-by: Jeremy Cline --- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index d141a5f004af..4fe4d664c5f2 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -792,7 +792,7 @@ nouveau_drm_device_remove(struct drm_device *dev) struct nvkm_client *client; struct nvkm_device *device; - drm_dev_unregister(dev); + drm_dev_unplug(dev); dev->irq_enabled = false; client = nvxx_client(>client.base); -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/nouveau: clean up all clients on device removal
The postclose handler can run after the device has been removed (or the
driver has been unbound) since userspace clients are free to hold the
file open the file as long as they want. Because the device removal
callback frees the entire nouveau_drm structure, any reference to it in
the postclose handler will result in a use-after-free.
To reproduce this, one must simply open the device file, unbind the
driver (or physically remove the device), and then close the device
file. This was found and can be reproduced easily with the IGT
core_hotunplug tests.
To avoid this, all clients are cleaned up in the device finialization
rather than deferring it to the postclose handler, and the postclose
handler is protected by a critical section which ensures the
drm_dev_unplug() and the postclose handler won't race.
This is not an ideal fix, since as I understand the proposed plan for
the kernel<->userspace interface for hotplug support, destroying the
client before the file is closed will cause problems. However, I believe
to properly fix this issue, the lifetime of the nouveau_drm structure
needs to be extended to match the drm_device, and this proved to be a
rather invasive change. Thus, I've broken this out so the fix can be
easily backported.
Signed-off-by: Jeremy Cline
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 30 +++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index d182b877258a..74fab777f4d0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -628,6 +628,7 @@ nouveau_drm_device_init(struct drm_device *dev)
static void
nouveau_drm_device_fini(struct drm_device *dev)
{
+ struct nouveau_cli *cli, *temp_cli;
struct nouveau_drm *drm = nouveau_drm(dev);
if (nouveau_pmops_runtime()) {
@@ -652,6 +653,24 @@ nouveau_drm_device_fini(struct drm_device *dev)
nouveau_ttm_fini(drm);
nouveau_vga_fini(drm);
+ /*
+* There may be existing clients from as-yet unclosed files. For now,
+* clean them up here rather than deferring until the file is closed,
+* but this likely not correct if we want to support hot-unplugging
+* properly.
+*/
+ mutex_lock(>clients_lock);
+ list_for_each_entry_safe(cli, temp_cli, >clients, head) {
+ list_del(>head);
+ mutex_lock(>mutex);
+ if (cli->abi16)
+ nouveau_abi16_fini(cli->abi16);
+ mutex_unlock(>mutex);
+ nouveau_cli_fini(cli);
+ kfree(cli);
+ }
+ mutex_unlock(>clients_lock);
+
nouveau_cli_fini(>client);
nouveau_cli_fini(>master);
nvif_parent_dtor(>parent);
@@ -1110,6 +1129,16 @@ nouveau_drm_postclose(struct drm_device *dev, struct
drm_file *fpriv)
{
struct nouveau_cli *cli = nouveau_cli(fpriv);
struct nouveau_drm *drm = nouveau_drm(dev);
+ int dev_index;
+
+ /*
+* The device is gone, and as it currently stands all clients are
+* cleaned up in the removal codepath. In the future this may change
+* so that we can support hot-unplugging, but for now we immediately
+* return to avoid a double-free situation.
+*/
+ if (!drm_dev_enter(dev, _index))
+ return;
pm_runtime_get_sync(dev->dev);
@@ -1126,6 +1155,7 @@ nouveau_drm_postclose(struct drm_device *dev, struct
drm_file *fpriv)
kfree(cli);
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
+ drm_dev_exit(dev_index);
}
static const struct drm_ioctl_desc
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Fix uninitialized variable in drm_cvt_modes()
Sorry! Thought I had responded to this but apparently not, comments down below
On Thu, 2020-10-22 at 14:04 -0400, Ilia Mirkin wrote:
> On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote:
> >
> > Noticed this when trying to compile with -Wall on a kernel fork. We
> > potentially
> > don't set width here, which causes the compiler to complain about width
> > potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
> >
> > Signed-off-by: Lyude Paul
> >
> > Cc: # v5.9+
> > Fixes: 3f649ab728cd ("treewide: Remove uninitialized_var() usage")
> > Signed-off-by: Lyude Paul
> > ---
> > drivers/gpu/drm/drm_edid.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 631125b46e04..2da158ffed8e 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3094,6 +3094,7 @@ static int drm_cvt_modes(struct drm_connector
> > *connector,
> >
> > for (i = 0; i < 4; i++) {
> > int width, height;
> > + u8 cvt_aspect_ratio;
> >
> > cvt = &(timing->data.other_data.data.cvt[i]);
> >
> > @@ -3101,7 +3102,8 @@ static int drm_cvt_modes(struct drm_connector
> > *connector,
> > continue;
> >
> > height = (cvt->code[0] + ((cvt->code[1] & 0xf0) << 4) + 1) *
> > 2;
> > - switch (cvt->code[1] & 0x0c) {
> > + cvt_aspect_ratio = cvt->code[1] & 0x0c;
> > + switch (cvt_aspect_ratio) {
> > case 0x00:
> > width = height * 4 / 3;
> > break;
> > @@ -3114,6 +3116,10 @@ static int drm_cvt_modes(struct drm_connector
> > *connector,
> > case 0x0c:
> > width = height * 15 / 9;
> > break;
> > + default:
>
> What value would cvt->code[1] have such that this gets hit?
>
> Or is this a "compiler is broken, so let's add more code" situation?
> If so, perhaps the code added could just be enough to silence the
> compiler (unreachable, etc)?
I mean, this information comes from the EDID which inherently means it's coming
from an untrusted source so the value could be literally anything as long as the
EDID has a valid checksum. Note (assuming I'm understanding this code
correctly):
drm_add_edid_modes() → add_cvt_modes() → drm_for_each_detailed_block() →
do_cvt_mode() → drm_cvt_modes()
So afaict this isn't a broken compiler but a legitimate uninitialized variable.
>
> -ilia
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 5/7] drm/kmb: Add support for KeemBay Display
This is a basic KMS atomic modesetting display driver for KeemBay family of
SOCs. Driver has no 2D or 3D graphics. It calls into the ADV bridge
driver at the connector level.
Single CRTC with LCD controller->mipi DSI->ADV bridge
Only 1080p resolution and single plane is supported at this time.
v2: moved extern to .h, removed license text
use drm_dev_init, upclassed dev_private, removed HAVE_IRQ.(Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
moved clocks under kmb_clock, consolidated clk initializations
use drmm functions
use DRM_GEM_CMA_DRIVER_OPS_VMAP
v5: corrected spellings
v6: corrected checkpatch warnings
v7: review changes Sam Ravnborg and Thomas Zimmerman
removed kmb_crtc.h kmb_crtc_cleanup (Thomas)
renamed mode_set, kmb_load, inlined unload (Thomas)
moved remaining logging to drm_*(Thomas)
re-orged driver initialization (Thomas)
moved plane_status to drm_private (Sam)
removed unnecessary logs and defines and ifdef codes (Sam)
call helper_check in plane_atomic_check (Sam)
renamed set to get for bpp and format functions(Sam)
use drm helper functions for reset, duplicate/destroy state instead
of kmb functions (Sam)
removed kmb_priv from kmb_plane and removed kmb_plane_state (Sam)
v8: get clk_pll0 from display node in dt
v9: moved csc_coef_lcd to plane.c (Daniel Vetter)
call drm_atomic_helper_shutdown in remove (Daniel V)
use drm_crtc_handle_vblank (Daniel V)
renamed kmb_dsi_hw_init to kmb_dsi_mode_set (Daniel V)
complimentary changes to device tree changes (Rob)
v10: call drm_crtc_arm_vblank_event in atomic_flush (Daniel V)
moved global vars to kmb_private and added locks (Daniel V)
changes in driver to accommodate changes in DT to separate DSI
entries (Sam R)
review changes to separate mipi DSI (Sam R)
v11: review changes to separate msscam (Neil A,Sam R)
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Daniel Vetter
---
drivers/gpu/drm/kmb/kmb_crtc.c | 219 +++
drivers/gpu/drm/kmb/kmb_drv.c | 602
drivers/gpu/drm/kmb/kmb_drv.h | 88 ++
drivers/gpu/drm/kmb/kmb_plane.c | 490
drivers/gpu/drm/kmb/kmb_plane.h | 99 +++
5 files changed, 1498 insertions(+)
create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c
create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c
create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h
create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c
create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h
diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c b/drivers/gpu/drm/kmb/kmb_crtc.c
new file mode 100644
index 000..887b6d7
--- /dev/null
+++ b/drivers/gpu/drm/kmb/kmb_crtc.c
@@ -0,0 +1,219 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2018-2020 Intel Corporation
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "kmb_drv.h"
+#include "kmb_dsi.h"
+#include "kmb_plane.h"
+#include "kmb_regs.h"
+
+struct kmb_crtc_timing {
+ u32 vfront_porch;
+ u32 vback_porch;
+ u32 vsync_len;
+ u32 hfront_porch;
+ u32 hback_porch;
+ u32 hsync_len;
+};
+
+static int kmb_crtc_enable_vblank(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct kmb_drm_private *kmb = to_kmb(dev);
+
+ /* Clear interrupt */
+ kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
+ /* Set which interval to generate vertical interrupt */
+ kmb_write_lcd(kmb, LCD_VSTATUS_COMPARE,
+ LCD_VSTATUS_COMPARE_VSYNC);
+ /* Enable vertical interrupt */
+ kmb_set_bitmask_lcd(kmb, LCD_INT_ENABLE,
+ LCD_INT_VERT_COMP);
+ return 0;
+}
+
+static void kmb_crtc_disable_vblank(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct kmb_drm_private *kmb = to_kmb(dev);
+
+ /* Clear interrupt */
+ kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
+ /* Disable vertical interrupt */
+ kmb_clr_bitmask_lcd(kmb, LCD_INT_ENABLE,
+ LCD_INT_VERT_COMP);
+}
+
+static const struct drm_crtc_funcs kmb_crtc_funcs = {
+ .destroy = drm_crtc_cleanup,
+ .set_config = drm_atomic_helper_set_config,
+ .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,
+ .enable_vblank = kmb_crtc_enable_vblank,
+ .disable_vblank = kmb_crtc_disable_vblank,
+};
+
+static void kmb_crtc_set_mode(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_display_mode *m =
[PATCH v11 4/7] drm/kmb: Keem Bay driver register definition
Register definitions for Keem Bay display driver v2: removed license text (Sam) v3: Squashed all 59 commits to one v4: review changes from Sam Ravnborg renamed dev_p to kmb v5: corrected spellings v6: corrected checkpatch warnings v7: removed redundant definitions v8: removed redundant definitions, clean up (Sam R) Signed-off-by: Anitha Chrisanthus Reviewed-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: Daniel Vetter --- drivers/gpu/drm/kmb/kmb_regs.h | 725 + 1 file changed, 725 insertions(+) create mode 100644 drivers/gpu/drm/kmb/kmb_regs.h diff --git a/drivers/gpu/drm/kmb/kmb_regs.h b/drivers/gpu/drm/kmb/kmb_regs.h new file mode 100644 index 000..4815056 --- /dev/null +++ b/drivers/gpu/drm/kmb/kmb_regs.h @@ -0,0 +1,725 @@ +/* SPDX-License-Identifier: GPL-2.0-only + * + * Copyright © 2018-2020 Intel Corporation + */ + +#ifndef __KMB_REGS_H__ +#define __KMB_REGS_H__ + +/*** + *LCD controller control register defines + ***/ +#define LCD_CONTROL(0x4 * 0x000) +#define LCD_CTRL_PROGRESSIVE (0 << 0) +#define LCD_CTRL_INTERLACED BIT(0) +#define LCD_CTRL_ENABLE BIT(1) +#define LCD_CTRL_VL1_ENABLE BIT(2) +#define LCD_CTRL_VL2_ENABLE BIT(3) +#define LCD_CTRL_GL1_ENABLE BIT(4) +#define LCD_CTRL_GL2_ENABLE BIT(5) +#define LCD_CTRL_ALPHA_BLEND_VL1 (0 << 6) +#define LCD_CTRL_ALPHA_BLEND_VL2 BIT(6) +#define LCD_CTRL_ALPHA_BLEND_GL1 (2 << 6) +#define LCD_CTRL_ALPHA_BLEND_GL2 (3 << 6) +#define LCD_CTRL_ALPHA_TOP_VL1 (0 << 8) +#define LCD_CTRL_ALPHA_TOP_VL2 BIT(8) +#define LCD_CTRL_ALPHA_TOP_GL1 (2 << 8) +#define LCD_CTRL_ALPHA_TOP_GL2 (3 << 8) +#define LCD_CTRL_ALPHA_MIDDLE_VL1(0 << 10) +#define LCD_CTRL_ALPHA_MIDDLE_VL2BIT(10) +#define LCD_CTRL_ALPHA_MIDDLE_GL1(2 << 10) +#define LCD_CTRL_ALPHA_MIDDLE_GL2(3 << 10) +#define LCD_CTRL_ALPHA_BOTTOM_VL1(0 << 12) +#define LCD_CTRL_ALPHA_BOTTOM_VL2BIT(12) +#define LCD_CTRL_ALPHA_BOTTOM_GL1(2 << 12) +#define LCD_CTRL_ALPHA_BOTTOM_GL2(3 << 12) +#define LCD_CTRL_TIM_GEN_ENABLE BIT(14) +#define LCD_CTRL_CONTINUOUS (0 << 15) +#define LCD_CTRL_ONE_SHOTBIT(15) +#define LCD_CTRL_PWM0_EN BIT(16) +#define LCD_CTRL_PWM1_EN BIT(17) +#define LCD_CTRL_PWM2_EN BIT(18) +#define LCD_CTRL_OUTPUT_DISABLED (0 << 19) +#define LCD_CTRL_OUTPUT_ENABLED BIT(19) +#define LCD_CTRL_BPORCH_ENABLE BIT(21) +#define LCD_CTRL_FPORCH_ENABLE BIT(22) +#define LCD_CTRL_PIPELINE_DMABIT(28) +#define LCD_CTRL_VHSYNC_IDLE_LVL BIT(31) + +/* interrupts */ +#define LCD_INT_STATUS (0x4 * 0x001) +#define LCD_INT_EOF BIT(0) +#define LCD_INT_LINE_CMP BIT(1) +#define LCD_INT_VERT_COMPBIT(2) +#define LAYER0_DMA_DONE BIT(3) +#define LAYER0_DMA_IDLE BIT(4) +#define LAYER0_DMA_FIFO_OVERFLOW BIT(5) +#define LAYER0_DMA_FIFO_UNDERFLOWBIT(6) +#define LAYER0_DMA_CB_FIFO_OVERFLOW BIT(7) +#define LAYER0_DMA_CB_FIFO_UNDERFLOW BIT(8) +#define LAYER0_DMA_CR_FIFO_OVERFLOW BIT(9) +#define LAYER0_DMA_CR_FIFO_UNDERFLOW BIT(10) +#define LAYER1_DMA_DONE BIT(11) +#define LAYER1_DMA_IDLE BIT(12) +#define LAYER1_DMA_FIFO_OVERFLOW BIT(13) +#define LAYER1_DMA_FIFO_UNDERFLOWBIT(14) +#define LAYER1_DMA_CB_FIFO_OVERFLOW BIT(15) +#define LAYER1_DMA_CB_FIFO_UNDERFLOW BIT(16) +#define LAYER1_DMA_CR_FIFO_OVERFLOW BIT(17) +#define LAYER1_DMA_CR_FIFO_UNDERFLOW BIT(18) +#define LAYER2_DMA_DONE BIT(19) +#define LAYER2_DMA_IDLE BIT(20) +#define LAYER2_DMA_FIFO_OVERFLOW BIT(21) +#define LAYER2_DMA_FIFO_UNDERFLOWBIT(22) +#define LAYER3_DMA_DONE BIT(23) +#define LAYER3_DMA_IDLE BIT(24) +#define LAYER3_DMA_FIFO_OVERFLOW BIT(25) +#define LAYER3_DMA_FIFO_UNDERFLOW
[PATCH v11 2/7] dt-bindings: display: Intel KeemBay MSSCAM
This patch add bindings for Intel KeemBay MSSCAM syscon
Signed-off-by: Anitha Chrisanthus
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Rob Herring
---
.../bindings/display/intel,keembay-msscam.yaml | 36 ++
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
diff --git
a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
new file mode 100644
index 000..10ed8d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/intel,keembay-msscam.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devicetree bindings for Intel Keem Bay MSSCAM
+
+maintainers:
+ - Anitha Chrisanthus
+ - Edmond J Dea
+
+properties:
+ compatible:
+const: intel,keembay-msscam, syscon
+
+ reg:
+maxItems: 1
+
+ reg-io-width:
+const: 4
+
+required:
+ - compatible
+ - reg
+ - reg-io-width
+
+additionalProperties: false
+
+examples:
+ - |
+msscam:msscam@2091 {
+compatible = "intel,keembay-msscam", "syscon";
+reg = <0x2091 0x30>;
+reg-io-width = <4>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 7/7] drm/kmb: Build files for KeemBay Display driver
v2: Added Maintainer entry v3: Added one more Maintainer entry v3: drop videomode_helpers Cc: Sam Ravnborg Signed-off-by: Anitha Chrisanthus Reviewed-by: Sam Ravnborg --- MAINTAINERS | 7 +++ drivers/gpu/drm/Kconfig | 2 ++ drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/kmb/Kconfig | 12 drivers/gpu/drm/kmb/Makefile | 2 ++ 5 files changed, 24 insertions(+) create mode 100644 drivers/gpu/drm/kmb/Kconfig create mode 100644 drivers/gpu/drm/kmb/Makefile diff --git a/MAINTAINERS b/MAINTAINERS index 71e29dc..c82ea76 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8961,6 +8961,13 @@ M: Deepak Saxena S: Maintained F: drivers/char/hw_random/ixp4xx-rng.c +INTEL KEEMBAY DRM DRIVER +M: Anitha Chrisanthus +M: Edmund Dea +S: Maintained +F: Documentation/devicetree/bindings/display/intel,kmb_display.yaml +F: drivers/gpu/drm/kmb/ + INTEL MANAGEMENT ENGINE (mei) M: Tomas Winkler L: linux-ker...@vger.kernel.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 64376dd..3dc293c 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -268,6 +268,8 @@ source "drivers/gpu/drm/nouveau/Kconfig" source "drivers/gpu/drm/i915/Kconfig" +source "drivers/gpu/drm/kmb/Kconfig" + config DRM_VGEM tristate "Virtual GEM provider" depends on DRM diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 8156900..fefaff4c 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/ obj-$(CONFIG_DRM_MGA) += mga/ obj-$(CONFIG_DRM_I810) += i810/ obj-$(CONFIG_DRM_I915) += i915/ +obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ diff --git a/drivers/gpu/drm/kmb/Kconfig b/drivers/gpu/drm/kmb/Kconfig new file mode 100644 index 000..2dd7e68 --- /dev/null +++ b/drivers/gpu/drm/kmb/Kconfig @@ -0,0 +1,12 @@ +config DRM_KMB_DISPLAY + tristate "INTEL KEEMBAY DISPLAY" + depends on DRM && OF && (ARM || ARM64) + depends on COMMON_CLK + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + help + Choose this option if you have Intel's KeemBay SOC which integrates + an ARM Cortex A53 CPU with an Intel Movidius VPU. + + If M is selected the module will be called kmb-drm. diff --git a/drivers/gpu/drm/kmb/Makefile b/drivers/gpu/drm/kmb/Makefile new file mode 100644 index 000..527d737 --- /dev/null +++ b/drivers/gpu/drm/kmb/Makefile @@ -0,0 +1,2 @@ +kmb-drm-y := kmb_crtc.o kmb_drv.o kmb_plane.o kmb_dsi.o +obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb-drm.o -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 3/7] dt-bindings: display: bridge: Intel KeemBay DSI
This patch adds bindings for Intel KeemBay MIPI DSI
v2: corrected description for port
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
Reviewed-by: Neil Armstrong
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Rob Herring
---
.../bindings/display/bridge/intel,keembay-dsi.yaml | 101 +
1 file changed, 101 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
new file mode 100644
index 000..ab5be26
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/intel,keembay-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devicetree bindings for Intel Keem Bay mipi dsi controller
+
+maintainers:
+ - Anitha Chrisanthus
+ - Edmond J Dea
+
+properties:
+ compatible:
+const: intel,keembay-dsi
+
+ reg:
+items:
+ - description: MIPI registers range
+
+ reg-names:
+items:
+ - const: mipi
+
+ clocks:
+items:
+ - description: MIPI DSI clock
+ - description: MIPI DSI econfig clock
+ - description: MIPI DSI config clock
+
+ clock-names:
+items:
+ - const: clk_mipi
+ - const: clk_mipi_ecfg
+ - const: clk_mipi_cfg
+
+ ports:
+type: object
+
+properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ port@0:
+type: object
+description: MIPI DSI input port.
+
+ port@1:
+type: object
+description: DSI output port.
+
+required:
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+mipi-dsi@2090 {
+compatible = "intel,keembay-dsi";
+reg = <0x2090 0x4000>;
+reg-names = "mipi";
+clocks = <_clk 0x86>,
+ <_clk 0x88>,
+ <_clk 0x89>;
+clock-names = "clk_mipi", "clk_mipi_ecfg",
+ "clk_mipi_cfg";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dsi_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+dsi_out: endpoint {
+remote-endpoint = <_input>;
+};
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 0/7] Add support for KeemBay DRM driver
This is a new DRM driver for Intel's KeemBay SOC. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This driver is tested with the KMB EVM board which is the reference baord for Keem Bay SOC. The SOC's display pipeline is as follows +--++-++---+ |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | +--++-++---+ LCD controller and Mipi DSI transmitter are part of the SOC and mipi to HDMI converter is ADV7535 for KMB EVM board. The DRM driver is a basic KMS atomic modesetting display driver and has no 2D or 3D graphics.It calls into the ADV bridge driver at the connector level. Only 1080p resolution and single plane is supported at this time. The usecase is for debugging video and camera outputs. Device tree patches are under review here https://lore.kernel.org/linux-arm-kernel/20200708175020.194436-1-daniele.alessandre...@linux.intel.com/T/ Changes since v1: - Removed redundant license text, updated license - Rearranged include blocks - renamed global vars and removed extern in c - Used upclassing for dev_private - Used drm_dev_init in drm device create - minor cleanups Changes since v2: - squashed all commits to a single commit - logging changed to drm_info, drm_dbg etc. - used devm_drm_dev_alloc() - removed commented out sections and general cleanup Changes since v3: - renamed dev_p to kmb - moved clocks under kmb_clock, consolidated clk initializations - use drmm functions - use DRM_GEM_CMA_DRIVER_OPS_VMAP - more cleanups Changes since v4: - corrected spellings Changes since v5: - corrected checkpatch warnings/checks -Please ignore checkpatch checks on Camelcase - this is how it is named in the databook - Please ignore checkpatch warnings on misspelled for hsa, dout, widthn etc. - they are spelled as in the databook - Please ignore checkpatch checks on macro arguments reuse - its confirmed ok Changes since v6: - review changes Sam Ravnborg and Thomas Zimmerman split patch into 4 parts, part1 register definitions, part2 display driver files, part3 mipi dsi, part4 build files (Sam) removed kmb_crtc.h kmb_crtc_cleanup (Thomas) renamed mode_set, kmb_load, inlined unload (Thomas) moved remaining logging to drm_*(Thomas) re-orged driver initialization (Thomas) moved plane_status to drm_private (Sam) removed unnecessary logs and defines and ifdef codes (Sam) split dphy_init_sequence smaller (Sam) removed redundant checks in kmb_dsi (Sam) changed kmb_dsi_init to drm_bridge_connector_init and drm_connector_attach_encoder to bridge's connector (Sam) call helper_check in plane_atomic_check (Sam) renamed set to get for bpp and format functions(Sam) use drm helper functions for reset, duplicate/destroy state instead of kmb functions (Sam) removed kmb_priv from kmb_plane and removed kmb_plane_state (Sam) Changes since v7: - tested with 5.9 kernel and made the following changes get clk_pll0 from display node in dt call drm_bridge_attach with DRM_BRIDGE_ATTACH_NO_CONNECTOR Also added Maintainer entry Changes since v8: DT review changes (Rob) renamed kmb_dsi_hw_init to kmb_dsi_mode_set (Daniel V) moved csc_coef_lcd to plane.c (Daniel Vetter) call drm_atomic_helper_shutdown in remove (Daniel V) use drm_crtc_handle_vblank (Daniel V) renamed kmb_dsi_hw_init to kmb_dsi_mode_set (Daniel V) complimentary changes to device tree changes (Rob) removed redundant definitions in kmb_dsi.h Changes since v9: Review changes from Sam Ravnborg which are: DT is separated to display and Mipi DSI as per Sam suggestion and the driver has changes to reflect this separation. Also most of the MIPI DSI code is isolated and separated from the main driver, worked closely with Sam on these changes. This split is to ease review and driver is only buildable after the last patch (build files). call drm_crtc_arm_vblank_event in atomic_flush (Daniel V) moved global vars to kmb_private and added locks (Daniel V) added comments to clarify empty dsi host functions (Daniel V) Changes since v10: Created separate DT binding for msscam as syscon(Neil Armstrong, Sam) Msscam is used for clocks and also for connecting mipi and lcd. Corresponding driver changes for the above change (Neil Armstrong, Sam) corrected description for port in dsi DT bindings file updated reviewed by in commits. Anitha Chrisanthus (7): dt-bindings: display: Add support for Intel KeemBay Display dt-bindings: display: Intel KeemBay MSSCAM dt-bindings: display: bridge: Intel KeemBay DSI drm/kmb: Keem Bay driver register definition drm/kmb: Add support for KeemBay Display drm/kmb: Mipi
[PATCH v11 6/7] drm/kmb: Mipi DSI part of the display driver
Initializes Mipi DSI and sets up connects to ADV bridge
v2: removed license text
upclassed dev_private, removed HAVE_IRQ. (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7: review changes Sam Ravnborg and Thomas Zimmerman
removed unnecessary logs and defines and ifdef codes (Sam)
split dphy_init_sequence smaller (Sam)
removed redundant checks in kmb_dsi (Sam)
changed kmb_dsi_init to drm_bridge_connector_init and
drm_connector_attach_encoder to bridge's connector (Sam)
v8: call drm_bridge_attach with DRM_BRIDGE_ATTACH_NO_CONNECTOR
v9: renamed kmb_dsi_hw_init to kmb_dsi_mode_set (Daniel V)
v10: changes in driver to accommodate changes in DT to separate DSI
entries (Sam R)
added comments to clarify empty dsi host functions
review changes from Sam to separate out DSI part,
removed dependencies on drm side (Sam R)
v11: review changes for separate msscam node (Sam R, Neil A)
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Daniel Vetter
---
drivers/gpu/drm/kmb/kmb_dsi.c | 1562 +
drivers/gpu/drm/kmb/kmb_dsi.h | 387 ++
2 files changed, 1949 insertions(+)
create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c
create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.h
diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c b/drivers/gpu/drm/kmb/kmb_dsi.c
new file mode 100644
index 000..a24723d
--- /dev/null
+++ b/drivers/gpu/drm/kmb/kmb_dsi.c
@@ -0,0 +1,1562 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2019-2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "kmb_dsi.h"
+#include "kmb_regs.h"
+
+static struct mipi_dsi_host *dsi_host;
+static struct mipi_dsi_device *dsi_device;
+static struct drm_bridge *adv_bridge;
+
+/* Default setting is 1080p, 4 lanes */
+#define IMG_HEIGHT_LINES 1080
+#define IMG_WIDTH_PX 1920
+#define MIPI_TX_ACTIVE_LANES 4
+
+static struct mipi_tx_frame_section_cfg mipi_tx_frame0_sect_cfg = {
+ .width_pixels = IMG_WIDTH_PX,
+ .height_lines = IMG_HEIGHT_LINES,
+ .data_type = DSI_LP_DT_PPS_RGB888_24B,
+ .data_mode = MIPI_DATA_MODE1,
+ .dma_packed = 0
+};
+
+static struct mipi_tx_frame_cfg mipitx_frame0_cfg = {
+ .sections[0] = _tx_frame0_sect_cfg,
+ .sections[1] = NULL,
+ .sections[2] = NULL,
+ .sections[3] = NULL,
+ .vsync_width = 5,
+ .v_backporch = 36,
+ .v_frontporch = 4,
+ .hsync_width = 44,
+ .h_backporch = 148,
+ .h_frontporch = 88
+};
+
+static const struct mipi_tx_dsi_cfg mipitx_dsi_cfg = {
+ .hfp_blank_en = 0,
+ .eotp_en = 0,
+ .lpm_last_vfp_line = 0,
+ .lpm_first_vsa_line = 0,
+ .sync_pulse_eventn = DSI_VIDEO_MODE_NO_BURST_EVENT,
+ .hfp_blanking = SEND_BLANK_PACKET,
+ .hbp_blanking = SEND_BLANK_PACKET,
+ .hsa_blanking = SEND_BLANK_PACKET,
+ .v_blanking = SEND_BLANK_PACKET,
+};
+
+static struct mipi_ctrl_cfg mipi_tx_init_cfg = {
+ .active_lanes = MIPI_TX_ACTIVE_LANES,
+ .lane_rate_mbps = MIPI_TX_LANE_DATA_RATE_MBPS,
+ .ref_clk_khz = MIPI_TX_REF_CLK_KHZ,
+ .cfg_clk_khz = MIPI_TX_CFG_CLK_KHZ,
+ .tx_ctrl_cfg = {
+ .frames[0] = _frame0_cfg,
+ .frames[1] = NULL,
+ .frames[2] = NULL,
+ .frames[3] = NULL,
+ .tx_dsi_cfg = _dsi_cfg,
+ .line_sync_pkt_en = 0,
+ .line_counter_active = 0,
+ .frame_counter_active = 0,
+ .tx_always_use_hact = 1,
+ .tx_hact_wait_stop = 1,
+ }
+};
+
+struct mipi_hs_freq_range_cfg {
+ u16 default_bit_rate_mbps;
+ u8 hsfreqrange_code;
+};
+
+struct vco_params {
+ u32 freq;
+ u32 range;
+ u32 divider;
+};
+
+static const struct vco_params vco_table[] = {
+ {52, 0x3f, 8},
+ {80, 0x39, 8},
+ {105, 0x2f, 4},
+ {160, 0x29, 4},
+ {210, 0x1f, 2},
+ {320, 0x19, 2},
+ {420, 0x0f, 1},
+ {630, 0x09, 1},
+ {1100, 0x03, 1},
+ {0x, 0x01, 1},
+};
+
+static const struct mipi_hs_freq_range_cfg
+mipi_hs_freq_range[MIPI_DPHY_DEFAULT_BIT_RATES] = {
+ {.default_bit_rate_mbps = 80, .hsfreqrange_code = 0x00},
+ {.default_bit_rate_mbps = 90, .hsfreqrange_code = 0x10},
+ {.default_bit_rate_mbps = 100, .hsfreqrange_code = 0x20},
+ {.default_bit_rate_mbps = 110, .hsfreqrange_code = 0x30},
+ {.default_bit_rate_mbps = 120, .hsfreqrange_code = 0x01},
+ {.default_bit_rate_mbps = 130, .hsfreqrange_code = 0x11},
+
[PATCH v11 1/7] dt-bindings: display: Add support for Intel KeemBay Display
This patch adds bindings for Intel KeemBay Display
v2: review changes from Rob Herring
v3: review changes from Sam Ravnborg (removed mipi dsi entries, and
encoder entry, connect port to dsi)
MSSCAM is part of the display submodule and its used to reset LCD
and MIPI DSI clocks, so its best to be on this device tree.
v4: review changes from Neil Armstrong and Sam - removed msscam
entries
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Rob Herring
---
.../bindings/display/intel,keembay-display.yaml| 72 ++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/intel,keembay-display.yaml
diff --git
a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
new file mode 100644
index 000..0a697d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devicetree bindings for Intel Keem Bay display controller
+
+maintainers:
+ - Anitha Chrisanthus
+ - Edmond J Dea
+
+properties:
+ compatible:
+const: intel,keembay-display
+
+ reg:
+items:
+ - description: LCD registers range
+
+ reg-names:
+items:
+ - const: lcd
+
+ clocks:
+items:
+ - description: LCD controller clock
+ - description: pll0 clock
+
+ clock-names:
+items:
+ - const: clk_lcd
+ - const: clk_pll0
+
+ interrupts:
+maxItems: 1
+
+ port:
+type: object
+description: Display output node to DSI.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@2093 {
+compatible = "intel,keembay-display";
+reg = <0x2093 0x3000>;
+reg-names = "lcd";
+interrupts = ;
+clocks = <_clk 0x83>,
+ <_clk 0x0>;
+clock-names = "clk_lcd", "clk_pll0";
+
+port {
+disp_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] MAINTAINERS: add Dan Murphy as TI LP8xxx drivers maintainer
On 11/3/20, 11:28 AM, Krzysztof Kozlowski wrote: > > Milo Kim's email in TI bounces with permanent error (550: Invalid > recipient). Last email from him on LKML was in 2017. Move Milo Kim to > credits and add Dan Murphy from TI to look after: > - TI LP855x backlight driver, > - TI LP8727 charger driver, > - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers. > > Signed-off-by: Krzysztof Kozlowski > Cc: Dan Murphy > Acked-by: Dan Murphy > Acked-by: Jonathan Cameron > Acked-by: Sebastian Reichel Acked-by: Jingoo Han Best regards, Jingoo Han [...] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch V3 22/37] highmem: High implementation details and document API
On Tue, Nov 3, 2020 at 2:33 AM Thomas Gleixner wrote:
>
> +static inline void *kmap(struct page *page)
> +{
> + void *addr;
> +
> + might_sleep();
> + if (!PageHighMem(page))
> + addr = page_address(page);
> + else
> + addr = kmap_high(page);
> + kmap_flush_tlb((unsigned long)addr);
> + return addr;
> +}
> +
> +static inline void kunmap(struct page *page)
> +{
> + might_sleep();
> + if (!PageHighMem(page))
> + return;
> + kunmap_high(page);
> +}
I have no complaints about the patch, but it strikes me that if people
want to actually have much better debug coverage, this is where it
should be (I like the "every other address" thing too, don't get me
wrong).
In particular, instead of these PageHighMem(page) tests, I think
something like this would be better:
#ifdef CONFIG_DEBUG_HIGHMEM
#define page_use_kmap(page) ((page),1)
#else
#define page_use_kmap(page) PageHighMem(page)
#endif
adn then replace those "if (!PageHighMem(page))" tests with "if
(!page_use_kmap())" instead.
IOW, in debug mode, it would _always_ remap the page, whether it's
highmem or not. That would really stress the highmem code and find any
fragilities.
No?
Anyway, this is all sepatrate from the series, which still looks fine
to me. Just a reaction to seeing the patch, and Thomas' earlier
mention that the highmem debugging doesn't actually do much.
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as user memory region
> -Original Message- > From: Daniel Vetter > Sent: Friday, October 23, 2020 6:45 PM > To: Jason Gunthorpe > Cc: Xiong, Jianxin ; linux-rdma > ; dri-devel ; > Leon > Romanovsky ; Doug Ledford ; Vetter, > Daniel ; Christian Koenig > > Subject: Re: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as user > memory region > > > > > + > > > > +#ifdef CONFIG_DMA_VIRT_OPS > > > > + if (device->dma_device->dma_ops == _virt_ops) > > > > + return ERR_PTR(-EINVAL); #endif > > > > > > Maybe I'm confused, but should we have this check in dma_buf_attach, > > > or at least in dma_buf_dynamic_attach? The p2pdma functions use that > > > too, and I can't imagine how zerocopy should work (which is like the > > > entire point of > > > dma-buf) when we have dma_virt_ops. > > > > The problem is we have RDMA drivers that assume SGL's have a valid > > struct page, and these hacky/wrong P2P sgls that DMABUF creates cannot > > be passed into those drivers. > > > > But maybe this is just a 'drivers are using it wrong' if they call > > this function and expect struct pages.. > > > > The check in the p2p stuff was done to avoid this too, but it was on a > > different flow. > > Yeah definitely don't call dma_buf_map_attachment and expect a page back. In > practice you'll get a page back fairly often, but I don't think > we want to bake that in, maybe we eventually get to non-hacky dma_addr_t only > sgl. > > What I'm wondering is whether dma_buf_attach shouldn't reject such devices > directly, instead of each importer having to do that. Come back here to see if consensus can be reached on who should do the check. My thinking is that it could be over restrictive for dma_buf_attach to always reject dma_virt_ops. According to dma-buf documentation the back storage would be moved to system area upon mapping unless p2p is requested and can be supported by the exporter. The sg_list for system memory would have struct page present. -Jianxin > -Daniel > -- > 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 v3] MAINTAINERS: add Dan Murphy as TI LP8xxx drivers maintainer
On Tue, Nov 03, 2020 at 05:28:32PM +0100, Krzysztof Kozlowski wrote: > Milo Kim's email in TI bounces with permanent error (550: Invalid > recipient). Last email from him on LKML was in 2017. Move Milo Kim to > credits and add Dan Murphy from TI to look after: > - TI LP855x backlight driver, > - TI LP8727 charger driver, > - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers. Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: a5xx: Make preemption reset case reentrant
On Mon, Nov 02, 2020 at 09:02:25PM +0100, Marijn Suijten wrote:
> nr_rings is reset to 1, but when this function is called for a second
> (and third!) time nr_rings > 1 is false, thus the else case is entered
> to set up a buffer for the RPTR shadow and consequently written to
> RB_RPTR_ADDR, hanging platforms without WHERE_AM_I firmware support.
>
> Restructure the condition in such a way that shadow buffer setup only
> ever happens when has_whereami is true; otherwise preemption is only
> finalized when the number of ring buffers has not been reset to 1 yet.
>
> Fixes: 8907afb476ac ("drm/msm: Allow a5xx to mark the RPTR shadow as
> privileged")
> Signed-off-by: Marijn Suijten
> Tested-by: AngeloGioacchino Del Regno
>
Way better. Thanks for doing this.
Reviewed-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index d6804a802355..9a202a7da131 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -755,12 +755,8 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
> gpu_write(gpu, REG_A5XX_CP_RB_CNTL,
> MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
>
> - /* Disable preemption if WHERE_AM_I isn't available */
> - if (!a5xx_gpu->has_whereami && gpu->nr_rings > 1) {
> - a5xx_preempt_fini(gpu);
> - gpu->nr_rings = 1;
> - } else {
> - /* Create a privileged buffer for the RPTR shadow */
> + /* Create a privileged buffer for the RPTR shadow */
> + if (a5xx_gpu->has_whereami) {
> if (!a5xx_gpu->shadow_bo) {
> a5xx_gpu->shadow = msm_gem_kernel_new(gpu->dev,
> sizeof(u32) * gpu->nr_rings,
> @@ -774,6 +770,10 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
>
> gpu_write64(gpu, REG_A5XX_CP_RB_RPTR_ADDR,
> REG_A5XX_CP_RB_RPTR_ADDR_HI, shadowptr(a5xx_gpu,
> gpu->rb[0]));
> + } else if (gpu->nr_rings > 1) {
> + /* Disable preemption if WHERE_AM_I isn't available */
> + a5xx_preempt_fini(gpu);
> + gpu->nr_rings = 1;
> }
>
> a5xx_preempt_hw_init(gpu);
> --
> 2.29.2
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
On 03.11.2020 15:12, Chanwoo Choi wrote: >>> I have a question about exynos_icc_get_parent(). >>> As I checked, this function returns the only one icc_node >>> as parent node. But, bus_display dt node in the exynos4412.dtsi >>> specifies the two interconnect node as following with bus_leftbus, bus_dmc, >>> >>> When I checked the return value of exynos_icc_get_parent() >>> during probing for bus_display device, exynos_icc_get_parent() function >>> only returns 'bus_leftbus' icc_node. Do you need to add two phandle >>> of icc node? >> Yes, as we use the interconnect consumer bindings we need to specify a path, >> i.e. a pair. When the provider node initializes it will >> link itself to that path. Currently the provider driver uses just the first >> phandle. > As I knew, the interconnect consumer bindings use the two phandles > in the interconnect core as you commented. But, in case of this, > even if add two phandles with interconnect consuming binding style, > the exynos interconnect driver only uses the first phandle. > > Instead, I think we better explain this case into a dt-binding > document for users. Fair enough, I'll try to improve the description, do you perhaps have any suggestions? The DT binding reflects how the hardware structure looks like and the fact that the driver currently uses only one of the phandles could be considered an implementation detail. -- Regards, Sylwester ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/6] dt-bindings: display: Add support for Intel KeemBay Display
Hi Neil, > > msscam is used to enable clocks both for the display driver and the > mipi-dsi part. > >>> > >>> If just clocks, then the msscam should be a clock provider possibly. > >>> If not, then the below looks right. > > > > I am feeling a little clueless here - sorry. > > > > Can you help with any example that does this? > > > > Everything I looked up in bindings/clock/ had a "#clock-cells" which is > > not relevant for msscam - or so I think at least. > > Looking at the code make it clear it's not relevant to implement it as clock > controller. > > The syscon is enough. Thanks, I think Anitha is going to send a v11 today with the sysconf change. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: sor: Don't warn on probe deferral
On 03/11/2020 11:44, Jon Hunter wrote:
> Deferred probe is an expected return value for tegra_output_probe().
> Given that the driver deals with it properly, there's no need to output
> a warning that may potentially confuse users.
>
> Signed-off-by: Jon Hunter
> ---
> drivers/gpu/drm/tegra/sor.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index e88a17c2937f..5a232055b8cc 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -3765,7 +3765,7 @@ static int tegra_sor_probe(struct platform_device *pdev)
>
> err = tegra_output_probe(>output);
> if (err < 0) {
> - dev_err(>dev, "failed to probe output: %d\n", err);
> + dev_err_probe(>dev, "failed to probe output: %d\n", err);
> return err;
> }
Sorry this is not right. I will fix this in V2.
Jon
--
nvpublic
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] MAINTAINERS: add Dan Murphy as TI LP8xxx drivers maintainer
On Tue, Nov 03, 2020 at 05:28:32PM +0100, Krzysztof Kozlowski wrote: > Milo Kim's email in TI bounces with permanent error (550: Invalid > recipient). Last email from him on LKML was in 2017. Move Milo Kim to > credits and add Dan Murphy from TI to look after: > - TI LP855x backlight driver, > - TI LP8727 charger driver, > - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers. > > Signed-off-by: Krzysztof Kozlowski > Cc: Dan Murphy > Acked-by: Dan Murphy > Acked-by: Jonathan Cameron > Acked-by: Sebastian Reichel > > --- > > Dear Lee, > > Could you take care about this patch? Just in case Lee wants it: Acked-by: Daniel Thompson Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers: drm: fix msm_drv.h warning
Should be fixed by: https://patchwork.freedesktop.org/patch/397039/?series=83038=1 On Mon, Nov 2, 2020 at 7:44 PM dev god wrote: > > Hi > > fix implicit declaration of function error. > > >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1229:7: error: implicit > >> declaration of function 'msm_dp_display_pre_disable' > >> [-Werror,-Wimplicit-function-declaration] >if (msm_dp_display_pre_disable(priv->dp, drm_enc)) >^ >drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1229:7: note: did you mean > 'msm_dp_display_disable'? >drivers/gpu/drm/msm/msm_drv.h:420:19: note: 'msm_dp_display_disable' > declared here >static inline int msm_dp_display_disable(struct msm_dp *dp, > ^ >1 error generated. > > Signed-off-by: Gah0 > Reported-by: kernel test robot > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c > index f7f5c258b553..52d9a82fb64f 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c > @@ -14,7 +14,7 @@ > #include > #include > > -#include "msm_drv.h" > +#include "../../msm_drv.h" > #include "dpu_kms.h" > #include "dpu_hwio.h" > #include "dpu_hw_catalog.h" > -- > 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/amdgpu: Paper over the drm_driver mangling for virt
On Sun, Nov 1, 2020 at 5:01 AM Daniel Vetter wrote:
>
> On Sat, Oct 31, 2020 at 2:57 PM Daniel Vetter wrote:
> >
> > On Fri, Oct 30, 2020 at 7:47 PM Alex Deucher wrote:
> > >
> > > On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter
> > > wrote:
> > > >
> > > > Prep work to make drm_device->driver const.
> > > >
> > > > Signed-off-by: Daniel Vetter
> > > > Cc: Alex Deucher
> > > > Cc: "Christian König"
> > > > Cc: Evan Quan
> > > > Cc: Felix Kuehling
> > > > Cc: Hawking Zhang
> > > > Cc: Andrey Grodzovsky
> > > > Cc: Luben Tuikov
> > > > Cc: Thomas Zimmermann
> > > > Cc: Monk Liu
> > > > Cc: Yintian Tao
> > > > Cc: Dennis Li
> > > > Cc: shaoyunl
> > > > Cc: Bokun Zhang
> > > > Cc: "Stanley.Yang"
> > > > Cc: Wenhui Sheng
> > > > Cc: chen gong
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 12 +++-
> > > > 2 files changed, 15 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > index 024c3b70b1aa..3d337f13ae4e 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > @@ -1093,7 +1093,7 @@ static const struct pci_device_id pciidlist[] = {
> > > >
> > > > MODULE_DEVICE_TABLE(pci, pciidlist);
> > > >
> > > > -static struct drm_driver kms_driver;
> > > > +struct drm_driver amdgpu_kms_driver;
> > > >
> > > > static int amdgpu_pci_probe(struct pci_dev *pdev,
> > > > const struct pci_device_id *ent)
> > > > @@ -1164,7 +1164,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> > > > if (ret)
> > > > return ret;
> > > >
> > > > - adev = devm_drm_dev_alloc(>dev, _driver,
> > > > typeof(*adev), ddev);
> > > > + adev = devm_drm_dev_alloc(>dev, _kms_driver,
> > > > typeof(*adev), ddev);
> > > > if (IS_ERR(adev))
> > > > return PTR_ERR(adev);
> > > >
> > > > @@ -1508,7 +1508,7 @@ int amdgpu_file_to_fpriv(struct file *filp,
> > > > struct amdgpu_fpriv **fpriv)
> > > > return 0;
> > > > }
> > > >
> > > > -static struct drm_driver kms_driver = {
> > > > +struct drm_driver amdgpu_kms_driver = {
> > > > .driver_features =
> > > > DRIVER_ATOMIC |
> > > > DRIVER_GEM |
> > > > @@ -1571,7 +1571,7 @@ static int __init amdgpu_init(void)
> > > > goto error_fence;
> > > >
> > > > DRM_INFO("amdgpu kernel modesetting enabled.\n");
> > > > - kms_driver.num_ioctls = amdgpu_max_kms_ioctl;
> > > > + amdgpu_kms_driver.num_ioctls = amdgpu_max_kms_ioctl;
> > > > amdgpu_register_atpx_handler();
> > > >
> > > > /* Ignore KFD init failures. Normal when CONFIG_HSA_AMD is not
> > > > set. */
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > > index d0aea5e39531..dde4c449c284 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > > @@ -45,13 +45,23 @@ bool amdgpu_virt_mmio_blocked(struct amdgpu_device
> > > > *adev)
> > > > return RREG32_NO_KIQ(0xc040) == 0x;
> > > > }
> > > >
> > > > +extern struct drm_driver amdgpu_kms_driver;
> > > > +
> > > > void amdgpu_virt_init_setting(struct amdgpu_device *adev)
> > > > {
> > > > /* enable virtual display */
> > > > if (adev->mode_info.num_crtc == 0)
> > > > adev->mode_info.num_crtc = 1;
> > > > adev->enable_virtual_display = true;
> > > > - adev_to_drm(adev)->driver->driver_features &= ~DRIVER_ATOMIC;
> > > > +
> > > > + /*
> > > > +* FIXME: Either make virt support atomic or make sure you have
> > > > two
> > > > +* drm_driver structs, these kind of tricks are only ok when
> > > > there's
> > > > +* guaranteed only a single device per system. This should also
> > > > be done
> > > > +* before struct drm_device is initialized.
> > > > +*/
> > > > + amdgpu_kms_driver.driver_features &= ~DRIVER_ATOMIC;
> > >
> > > There is additional DRIVER_ATOMIC in amdgpu_pci_probe() for older
> > > chips without atomic support.
> >
> > That would need to be fixed for making the amdgpu drm_driver
> > structures constant, but that's not what I'm doing here. I'm only
> > removing the usage of the drm_device->driver pointer, to allow that to
> > become constant. Untangling the flow to make the amdgpu_kms_driver
> > const looked a bit more involved than just a simple patch.
>
> On second look, this changes the drm_device->driver_features flag,
> which was added to avoid having to change the drm_driver one. So
> that's actually all ok (and just the virt code here is broken). But
> amdgpu also updates num_ioctl and other stuff, and that's a fairly
> invasive patch.
We don't
Re: [PATCH v4 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
On Tue, 2020-11-03 at 16:56 +0200, Sakari Ailus wrote:
> On Tue, Nov 03, 2020 at 04:47:47PM +0200, Andy Shevchenko wrote:
> > On Tue, Nov 03, 2020 at 03:34:00PM +0200, Sakari Ailus wrote:
> > > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > > pixel formats denoted by fourccs. The fourcc encoding is the same for both
> > > so the same implementation can be used.
> >
> > ...
> >
> > > +static noinline_for_stack
> > > +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> > > + struct printf_spec spec, const char *fmt)
> > > +{
> > > + char output[sizeof("(xx)(xx)(xx)(xx) little-endian (0x01234567)")];
> >
> > I would add a comment that there is another possibility, i.e. big-endian,
> > but
> > it occupies less space.
I think it's unnecessary as it's obvious and similarly done in other
_string type functions.
> > > + p = special_hex_number(p, output + sizeof(output) - 2, *fourcc,
> > > +sizeof(u32));
> >
> > I would go with one line here.
>
> It's wrapped since the result would be over 80 otherwise.
Perhaps simpler as
p = special_hex_number(p, p + 10, *fourcc, sizeof(u32));
> > The (theoretical) problem is here that the case when buffer size is not
> > enough
> > to print a value will be like '(0xabc)' but should be rather '(0xabcd' like
> > snprintf() does in general.
Isn't the stack buffer known to be large enough?
> > > + *p++ = ')';
> > > + *p = '\0';
> > > +
> > > + return string(buf, end, output, spec);
Isn't the actual output buffer used here truncating output?
If the general problem is someone using a limited length pointer
output like %10p4cc, then all the output is getting truncated no?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On Mon, Nov 2, 2020 at 9:47 PM Viresh Kumar wrote:
>
> On 27-10-20, 17:05, Viresh Kumar wrote:
> > It isn't that straight forward unfortunately, we need to make sure the
> > table doesn't get allocated for the same device twice, so
> > find+allocate needs to happen within a locked region.
> >
> > I have taken, not so straight forward, approach to fixing this issue,
> > lets see if this fixes it or not.
> >
> > -8<-
> >
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index 4ac4e7ce6b8b..6f4a73a6391f 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> > @@ -29,6 +29,8 @@
> > LIST_HEAD(opp_tables);
> > /* Lock to allow exclusive modification to the device and opp lists */
> > DEFINE_MUTEX(opp_table_lock);
> > +/* Flag indicating that opp_tables list is being updated at the moment */
> > +static bool opp_tables_busy;
> >
> > static struct opp_device *_find_opp_dev(const struct device *dev,
> > struct opp_table *opp_table)
> > @@ -1036,8 +1038,8 @@ static void _remove_opp_dev(struct opp_device
> > *opp_dev,
> > kfree(opp_dev);
> > }
> >
> > -static struct opp_device *_add_opp_dev_unlocked(const struct device *dev,
> > - struct opp_table *opp_table)
> > +struct opp_device *_add_opp_dev(const struct device *dev,
> > + struct opp_table *opp_table)
> > {
> > struct opp_device *opp_dev;
> >
> > @@ -1048,7 +1050,9 @@ static struct opp_device *_add_opp_dev_unlocked(const
> > struct device *dev,
> > /* Initialize opp-dev */
> > opp_dev->dev = dev;
> >
> > + mutex_lock(_table->lock);
> > list_add(_dev->node, _table->dev_list);
> > + mutex_unlock(_table->lock);
> >
> > /* Create debugfs entries for the opp_table */
> > opp_debug_register(opp_dev, opp_table);
> > @@ -1056,18 +1060,6 @@ static struct opp_device
> > *_add_opp_dev_unlocked(const struct device *dev,
> > return opp_dev;
> > }
> >
> > -struct opp_device *_add_opp_dev(const struct device *dev,
> > - struct opp_table *opp_table)
> > -{
> > - struct opp_device *opp_dev;
> > -
> > - mutex_lock(_table->lock);
> > - opp_dev = _add_opp_dev_unlocked(dev, opp_table);
> > - mutex_unlock(_table->lock);
> > -
> > - return opp_dev;
> > -}
> > -
> > static struct opp_table *_allocate_opp_table(struct device *dev, int index)
> > {
> > struct opp_table *opp_table;
> > @@ -1121,8 +1113,6 @@ static struct opp_table *_allocate_opp_table(struct
> > device *dev, int index)
> > INIT_LIST_HEAD(_table->opp_list);
> > kref_init(_table->kref);
> >
> > - /* Secure the device table modification */
> > - list_add(_table->node, _tables);
> > return opp_table;
> >
> > err:
> > @@ -1135,27 +1125,64 @@ void _get_opp_table_kref(struct opp_table
> > *opp_table)
> > kref_get(_table->kref);
> > }
> >
> > +/*
> > + * We need to make sure that the OPP table for a device doesn't get added
> > twice,
> > + * if this routine gets called in parallel with the same device pointer.
> > + *
> > + * The simplest way to enforce that is to perform everything (find existing
> > + * table and if not found, create a new one) under the opp_table_lock, so
> > only
> > + * one creator gets access to the same. But that expands the critical
> > section
> > + * under the lock and may end up causing circular dependencies with
> > frameworks
> > + * like debugfs, interconnect or clock framework as they may be direct or
> > + * indirect users of OPP core.
> > + *
> > + * And for that reason we have to go for a bit tricky implementation here,
> > which
> > + * uses the opp_tables_busy flag to indicate if another creator is in the
> > middle
> > + * of adding an OPP table and others should wait for it to finish.
> > + */
> > static struct opp_table *_opp_get_opp_table(struct device *dev, int index)
> > {
> > struct opp_table *opp_table;
> >
> > - /* Hold our table modification lock here */
> > +again:
> > mutex_lock(_table_lock);
> >
> > opp_table = _find_opp_table_unlocked(dev);
> > if (!IS_ERR(opp_table))
> > goto unlock;
> >
> > + /*
> > + * The opp_tables list or an OPP table's dev_list is getting updated
> > by
> > + * another user, wait for it to finish.
> > + */
> > + if (unlikely(opp_tables_busy)) {
> > + mutex_unlock(_table_lock);
> > + cpu_relax();
> > + goto again;
> > + }
> > +
> > + opp_tables_busy = true;
> > opp_table = _managed_opp(dev, index);
> > +
> > + /* Drop the lock to reduce the size of critical section */
> > + mutex_unlock(_table_lock);
> > +
> > if (opp_table) {
> > - if (!_add_opp_dev_unlocked(dev, opp_table)) {
> > + if (!_add_opp_dev(dev, opp_table)) {
> >
RE: [PATCH] dma-buf: Fix static checker warning
> -Original Message-
> From: Christian König
> Sent: Monday, November 02, 2020 11:57 PM
> To: Xiong, Jianxin ; dri-devel@lists.freedesktop.org
> Cc: Sumit Semwal ; Vetter, Daniel
>
> Subject: Re: [PATCH] dma-buf: Fix static checker warning
>
> Am 03.11.20 um 04:51 schrieb Jianxin Xiong:
> > Here is the warning message:
> >
> > drivers/dma-buf/dma-buf.c:917 dma_buf_map_attachment()
> > error: 'sg_table' dereferencing possible ERR_PTR()
> >
> > Fix by adding error checking before dereferencing the pointer.
> >
> > Fixes: ac80cd17a615 ("dma-buf: Clarify that dma-buf sg lists are page
> > aligned")
> > Reported-by: Dan Carpenter
> > Signed-off-by: Jianxin Xiong
>
> Reviewed-by: Christian König
>
> Do you have commit access to drm-misc-next or should I push it?
I don't have commit access.
>
> > ---
> > drivers/dma-buf/dma-buf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 556f62e..0eb80c1 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -908,7 +908,7 @@ struct sg_table *dma_buf_map_attachment(struct
> > dma_buf_attachment *attach,
> > }
> >
> > #ifdef CONFIG_DMA_API_DEBUG
> > - {
> > + if (!IS_ERR(sg_table)) {
> > struct scatterlist *sg;
> > u64 addr;
> > int len;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] MAINTAINERS: add Dan Murphy as TI LP8xxx drivers maintainer
Milo Kim's email in TI bounces with permanent error (550: Invalid recipient). Last email from him on LKML was in 2017. Move Milo Kim to credits and add Dan Murphy from TI to look after: - TI LP855x backlight driver, - TI LP8727 charger driver, - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers. Signed-off-by: Krzysztof Kozlowski Cc: Dan Murphy Acked-by: Dan Murphy Acked-by: Jonathan Cameron Acked-by: Sebastian Reichel --- Dear Lee, Could you take care about this patch? Best regards, Krzysztof Changes since v2: 1. Fix subject (TP -> TI) Changes since v1: 1. Add Dan Murphy, do not remove the entries. --- CREDITS | 3 +++ MAINTAINERS | 6 +++--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/CREDITS b/CREDITS index cb02b9923a52..2a214a47c67a 100644 --- a/CREDITS +++ b/CREDITS @@ -1910,6 +1910,9 @@ S: 660 Harvard Ave. #7 S: Santa Clara, CA 95051 S: USA +N: Milo Kim +D: TI LP855x, LP8727 and LP8788 drivers + N: Russell King E: r...@arm.linux.org.uk D: Linux/arm integrator, maintainer & hacker diff --git a/MAINTAINERS b/MAINTAINERS index e73636b75f29..9d74b222f9ad 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17529,20 +17529,20 @@ F:sound/soc/codecs/isabelle* F: sound/soc/codecs/lm49453* TI LP855x BACKLIGHT DRIVER -M: Milo Kim +M: Dan Murphy S: Maintained F: Documentation/driver-api/backlight/lp855x-driver.rst F: drivers/video/backlight/lp855x_bl.c F: include/linux/platform_data/lp855x.h TI LP8727 CHARGER DRIVER -M: Milo Kim +M: Dan Murphy S: Maintained F: drivers/power/supply/lp8727_charger.c F: include/linux/platform_data/lp8727.h TI LP8788 MFD DRIVER -M: Milo Kim +M: Dan Murphy S: Maintained F: drivers/iio/adc/lp8788_adc.c F: drivers/leds/leds-lp8788.c -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: Use state helper instead of CRTC state pointer
On Tue, Nov 03, 2020 at 05:15:51PM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Mon, Nov 02, 2020 at 06:04:06PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 02, 2020 at 02:38:33PM +0100, Maxime Ripard wrote:
> > > Many drivers reference the crtc->pointer in order to get the current CRTC
> > > state in their atomic_begin or atomic_flush hooks, which would be the new
> > > CRTC state in the global atomic state since _swap_state happened when
> > > those
> > > hooks are run.
> > >
> > > Use the drm_atomic_get_new_crtc_state helper to get that state to make it
> > > more obvious.
> > >
> > > This was made using the coccinelle script below:
> > >
> > > @ crtc_atomic_func @
> > > identifier helpers;
> > > identifier func;
> > > @@
> > >
> > > (
> > > static struct drm_crtc_helper_funcs helpers = {
> > > ...,
> > > .atomic_begin = func,
> > > ...,
> > > };
> > > |
> > > static struct drm_crtc_helper_funcs helpers = {
> > > ...,
> > > .atomic_flush = func,
> > > ...,
> > > };
> > > )
> > >
> > > @@
> > > identifier crtc_atomic_func.func;
> > > identifier crtc, state;
> > > symbol crtc_state;
> > > expression e;
> > > @@
> > >
> > > func(struct drm_crtc *crtc, struct drm_atomic_state *state) {
> > > ...
> > > - struct tegra_dc_state *crtc_state = e;
> > > + struct tegra_dc_state *dc_state = e;
> > > <+...
> > > - crtc_state
> > > + dc_state
> > > ...+>
> > > }
> > >
> > > @@
> > > identifier crtc_atomic_func.func;
> > > identifier crtc, state;
> > > symbol crtc_state;
> > > expression e;
> > > @@
> > >
> > > func(struct drm_crtc *crtc, struct drm_atomic_state *state) {
> > > ...
> > > - struct mtk_crtc_state *crtc_state = e;
> > > + struct mtk_crtc_state *mtk_crtc_state = e;
> > > <+...
> > > - crtc_state
> > > + mtk_crtc_state
> > > ...+>
> > > }
> >
> > These reanames seem a bit out of scpe for this patch. But I guess you
> > needed then to get the rest of the cocci to work on some drivers?
>
> Yeah, those two drivers already had a variable named crtc_state, calling
> container_of on crtc->state
>
> It was cleaner to me to have an intermediate variable storing the result
> of drm_atomic_get_new_crtc_state, but then the most obvious name was
> taken so I had to rename those two variables before doing so.
>
> > The basic idea looks good:
> > Reviewed-by: Ville Syrjälä
> >
> > But I guess up to the individual driver folks to bikeshed the variable
> > naming and whatnot.
> >
> > One thing I spotted is that a few drivers now gained two aliasing crtc
> > state pointers in the function: one with the drm type, the other with
> > a driver specific type. That's something we've outlawed in i915 since
> > it was making life rather confusing. In i915 we now prefer to use only
> > the i915 specific types in most places.
>
> I didn't spot any of those cases, do you have an example of where it
> happened?
eg. ast:
+ struct drm_crtc_state *crtc_state =
drm_atomic_get_new_crtc_state(state,
+
crtc);
struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
crtc);
struct ast_private *ast = to_ast_private(crtc->dev);
- struct ast_crtc_state *ast_crtc_state = to_ast_crtc_state(crtc->state);
+ struct ast_crtc_state *ast_crtc_state = to_ast_crtc_state(crtc_state);
So here both 'crtc_state' and 'ast_crtc_state' are basically the same
thing, which can get a bit confusing especially within larger functions
with lots of variables.
In i915 we would just have
struct intel_crtc_state *crtc_state = whatever;
and any access to the base class would be done via crtc_state->base.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
On Tue, Nov 03, 2020 at 02:50:40PM +, Deucher, Alexander wrote: > [AMD Public Use] > > > -Original Message- > > From: Greg KH > > Sent: Tuesday, November 3, 2020 1:53 AM > > To: Koenig, Christian > > Cc: Alex Deucher ; Deepak R Varma > > ; David Airlie ; LKML > ker...@vger.kernel.org>; Maling list - DRI developers > de...@lists.freedesktop.org>; Melissa Wen ; > > amd-gfx list ; Daniel Vetter > > ; Daniel Vetter ; Deucher, > > Alexander > > Subject: Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or > > NULL > > > > On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote: > > > Am 02.11.20 um 20:43 schrieb Alex Deucher: > > > > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma > > wrote: > > > > > Initializing global variable to 0 or NULL is not necessary and > > > > > should be avoided. Issue reported by checkpatch script as: > > > > > ERROR: do not initialise globals to 0 (or NULL). > > > > I agree that this is technically correct, but a lot of people don't > > > > seem to know that so we get a lot of comments about this code for > > > > the variables that are not explicitly set. Seems less confusing to > > > > initialize them even if it not necessary. I don't have a > > > > particularly strong opinion on it however. > > > > > > Agree with Alex. > > > > > > Especially for the module parameters we should have a explicit init > > > value for documentation purposes, even when it is 0. > > > > Why is this one tiny driver somehow special compared to the entire rest of > > the kernel? (hint, it isn't...) > > > > Please follow the normal coding style rules, there's no reason to ignore > > them > > unless you like to constantly reject patches like this that get sent to you. > > > > I'll apply the patch, but as a data point, this is the first time I've > gotten a patch to make this change. I get several bug reports or > patches every year to explicitly set values to global variables > because users assume they are not initialized. So it will always be a > trade off as to which patches you want to NACK. Are you all not running your patches through checkpatch.pl to tell you simple things like this? If no, I suggest you start doing that :) thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
Hi Andy,
On Tue, Nov 03, 2020 at 04:47:47PM +0200, Andy Shevchenko wrote:
> On Tue, Nov 03, 2020 at 03:34:00PM +0200, Sakari Ailus wrote:
> > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by fourccs. The fourcc encoding is the same for both
> > so the same implementation can be used.
>
> ...
>
> > +static noinline_for_stack
> > +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> > + struct printf_spec spec, const char *fmt)
> > +{
> > + char output[sizeof("(xx)(xx)(xx)(xx) little-endian (0x01234567)")];
>
> I would add a comment that there is another possibility, i.e. big-endian, but
> it occupies less space.
This string is here to represent the longest possible output of the
function. Most of the time it's less. Saying that might make sense but it's
fairly clear already. Either way works for me though.
>
> > + char *p = output;
> > + unsigned int i;
> > + u32 val;
> > +
> > + if (fmt[1] != 'c' || fmt[2] != 'c')
> > + return error_string(output, end, "(%p4?)", spec);
> > +
> > + if (check_pointer(, end, fourcc, spec))
> > + return buf;
> > +
> > + val = *fourcc & ~BIT(31);
> > +
> > + for (i = 0; i < sizeof(*fourcc); i++) {
> > + unsigned char c = val >> (i * 8);
> > +
> > + /* Weed out spaces */
> > + if (c == ' ')
> > + continue;
> > +
> > + /* Print non-control ASCII characters as-is */
> > + if (isascii(c) && isprint(c)) {
> > + *p++ = c;
> > + continue;
> > + }
> > +
> > + *p++ = '(';
> > + p = hex_byte_pack(p, c);
> > + *p++ = ')';
> > + }
>
> I guess above loop can be still optimized, but I have to think about it.
>
> > + strcpy(p, *fourcc & BIT(31) ? " big-endian" : " little-endian");
> > + p += strlen(p);
> > +
> > + *p++ = ' ';
> > + *p++ = '(';
> > + /* subtract parenthesis and the space from the size */
>
> This comment misleading. What you are subtracting is a room for closing
> parenthesis and NUL.
Agreed, I'll update it for v5.
>
> > + p = special_hex_number(p, output + sizeof(output) - 2, *fourcc,
> > + sizeof(u32));
>
> I would go with one line here.
It's wrapped since the result would be over 80 otherwise.
>
> The (theoretical) problem is here that the case when buffer size is not enough
> to print a value will be like '(0xabc)' but should be rather '(0xabcd' like
> snprintf() does in general.
>
> > + *p++ = ')';
> > + *p = '\0';
> > +
> > + return string(buf, end, output, spec);
> > +}
>
--
Regards,
Sakari Ailus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
[AMD Public Use] > -Original Message- > From: Greg KH > Sent: Tuesday, November 3, 2020 1:53 AM > To: Koenig, Christian > Cc: Alex Deucher ; Deepak R Varma > ; David Airlie ; LKML ker...@vger.kernel.org>; Maling list - DRI developers de...@lists.freedesktop.org>; Melissa Wen ; > amd-gfx list ; Daniel Vetter > ; Daniel Vetter ; Deucher, > Alexander > Subject: Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or > NULL > > On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote: > > Am 02.11.20 um 20:43 schrieb Alex Deucher: > > > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma > wrote: > > > > Initializing global variable to 0 or NULL is not necessary and > > > > should be avoided. Issue reported by checkpatch script as: > > > > ERROR: do not initialise globals to 0 (or NULL). > > > I agree that this is technically correct, but a lot of people don't > > > seem to know that so we get a lot of comments about this code for > > > the variables that are not explicitly set. Seems less confusing to > > > initialize them even if it not necessary. I don't have a > > > particularly strong opinion on it however. > > > > Agree with Alex. > > > > Especially for the module parameters we should have a explicit init > > value for documentation purposes, even when it is 0. > > Why is this one tiny driver somehow special compared to the entire rest of > the kernel? (hint, it isn't...) > > Please follow the normal coding style rules, there's no reason to ignore them > unless you like to constantly reject patches like this that get sent to you. > I'll apply the patch, but as a data point, this is the first time I've gotten a patch to make this change. I get several bug reports or patches every year to explicitly set values to global variables because users assume they are not initialized. So it will always be a trade off as to which patches you want to NACK. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/shme-helpers: Fix dma_buf_mmap forwarding bug" has been added to the 5.9-stable tree
This is a note to let you know that I've just added the patch titled
drm/shme-helpers: Fix dma_buf_mmap forwarding bug
to the 5.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-shme-helpers-fix-dma_buf_mmap-forwarding-bug.patch
and it can be found in the queue-5.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From f49a51bfdc8ea717c97ccd4cc98b7e6daaa5553a Mon Sep 17 00:00:00 2001
From: Daniel Vetter
Date: Tue, 27 Oct 2020 22:49:22 +0100
Subject: drm/shme-helpers: Fix dma_buf_mmap forwarding bug
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Daniel Vetter
commit f49a51bfdc8ea717c97ccd4cc98b7e6daaa5553a upstream.
When we forward an mmap to the dma_buf exporter, they get to own
everything. Unfortunately drm_gem_mmap_obj() overwrote
vma->vm_private_data after the driver callback, wreaking the
exporter complete. This was noticed because vb2_common_vm_close blew
up on mali gpu with panfrost after commit 26d3ac3cb04d
("drm/shmem-helpers: Redirect mmap for imported dma-buf").
Unfortunately drm_gem_mmap_obj also acquires a surplus reference that
we need to drop in shmem helpers, which is a bit of a mislayer
situation. Maybe the entire dma_buf_mmap forwarding should be pulled
into core gem code.
Note that the only two other drivers which forward mmap in their own
code (etnaviv and exynos) get this somewhat right by overwriting the
gem mmap code. But they seem to still have the leak. This might be a
good excuse to move these drivers over to shmem helpers completely.
Reviewed-by: Boris Brezillon
Acked-by: Christian König
Cc: Christian König
Cc: Sumit Semwal
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf")
Cc: Boris Brezillon
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Cc: Rob Herring
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: # v5.9+
Reported-and-tested-by: piotr.oniszc...@gmail.com
Cc: piotr.oniszc...@gmail.com
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201027214922.3566743-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_gem.c |4 ++--
drivers/gpu/drm/drm_gem_shmem_helper.c |7 ++-
2 files changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1085,6 +1085,8 @@ int drm_gem_mmap_obj(struct drm_gem_obje
*/
drm_gem_object_get(obj);
+ vma->vm_private_data = obj;
+
if (obj->funcs && obj->funcs->mmap) {
ret = obj->funcs->mmap(obj, vma);
if (ret) {
@@ -1107,8 +1109,6 @@ int drm_gem_mmap_obj(struct drm_gem_obje
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
}
- vma->vm_private_data = obj;
-
return 0;
}
EXPORT_SYMBOL(drm_gem_mmap_obj);
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -594,8 +594,13 @@ int drm_gem_shmem_mmap(struct drm_gem_ob
/* Remove the fake offset */
vma->vm_pgoff -= drm_vma_node_start(>vma_node);
- if (obj->import_attach)
+ if (obj->import_attach) {
+ /* Drop the reference drm_gem_mmap_obj() acquired.*/
+ drm_gem_object_put(obj);
+ vma->vm_private_data = NULL;
+
return dma_buf_mmap(obj->dma_buf, vma, 0);
+ }
shmem = to_drm_gem_shmem_obj(obj);
Patches currently in stable-queue which might be from daniel.vet...@ffwll.ch are
queue-5.9/drm-ast-separate-drm-driver-from-pci-code.patch
queue-5.9/drm-shme-helpers-fix-dma_buf_mmap-forwarding-bug.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/ttm: replace context flags with bools v2
The ttm_operation_ctx structure has a mixture of flags and bools. Drop the
flags and replace them with bools as well.
v2: fix typos, improve comments
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c| 3 +--
drivers/gpu/drm/ttm/ttm_memory.c | 3 ++-
drivers/gpu/drm/ttm/ttm_resource.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 13 ++---
7 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d50b63a93d37..8466558d0d93 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -404,8 +404,7 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
struct ttm_operation_ctx ctx = {
.interruptible = true,
.no_wait_gpu = false,
- .resv = bo->tbo.base.resv,
- .flags = 0
+ .resv = bo->tbo.base.resv
};
uint32_t domain;
int r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 4e9dfbea31c6..e1f64ef8c765 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -518,9 +518,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
.no_wait_gpu = bp->no_wait_gpu,
/* We opt to avoid OOM on system pages allocations */
.gfp_retry_mayfail = true,
- .resv = bp->resv,
- .flags = bp->type != ttm_bo_type_kernel ?
- TTM_OPT_FLAG_ALLOW_RES_EVICT : 0
+ .allow_res_evict = bp->type != ttm_bo_type_kernel,
+ .resv = bp->resv
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c63b7ea1cd5d..e2a124b3affb 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -637,7 +637,7 @@ static bool ttm_bo_evict_swapout_allowable(struct
ttm_buffer_object *bo,
if (bo->base.resv == ctx->resv) {
dma_resv_assert_held(bo->base.resv);
- if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT)
+ if (ctx->allow_res_evict)
ret = true;
*locked = false;
if (busy)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index eeaca5d1efe3..2944fa0af493 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -315,8 +315,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
struct ttm_operation_ctx ctx = {
.interruptible = false,
.no_wait_gpu = false,
- .flags = TTM_OPT_FLAG_FORCE_ALLOC
-
+ .force_alloc = true
};
ttm = bo->ttm;
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index f9a90bfaa3c1..5ed1fc8f2ace 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -542,7 +542,8 @@ ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
{
int64_t available;
- if (ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC)
+ /* We allow over commit during suspend */
+ if (ctx->force_alloc)
return false;
available = get_nr_swap_pages() + si_mem_available();
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 4ebc043e2867..b60699bf4816 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -89,7 +89,7 @@ int ttm_resource_manager_evict_all(struct ttm_bo_device *bdev,
struct ttm_operation_ctx ctx = {
.interruptible = false,
.no_wait_gpu = false,
- .flags = TTM_OPT_FLAG_FORCE_ALLOC
+ .force_alloc = true
};
struct ttm_bo_global *glob = _bo_glob;
struct dma_fence *fence;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 4637357ba856..5ddad88ae6ed 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -196,8 +196,11 @@ struct ttm_bo_kmap_obj {
* @interruptible: Sleep interruptible if sleeping.
* @no_wait_gpu: Return immediately if the GPU is busy.
* @gfp_retry_mayfail: Set the __GFP_RETRY_MAYFAIL when allocation pages.
+ * @allow_res_evict: Allow eviction of reserved BOs. Can be used when multiple
+ * BOs share the same reservation object.
+ * @force_alloc: Don't check the memory account during suspend or CPU page
+ * faults. Should only be used by TTM internally.
* @resv:
[PATCH 1/2] drm/ttm: rework no_retry handling v2
During eviction we do want to trigger the OOM killer.
Only while doing new allocations we should try to avoid that and
return -ENOMEM to the application.
v2: rename the flag to gfp_retry_mayfail.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ---
drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c | 7 ---
include/drm/ttm/ttm_bo_api.h | 2 ++
include/drm/ttm/ttm_bo_driver.h| 3 ---
6 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 1aa516429c80..4e9dfbea31c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -516,6 +516,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
struct ttm_operation_ctx ctx = {
.interruptible = (bp->type != ttm_bo_type_kernel),
.no_wait_gpu = bp->no_wait_gpu,
+ /* We opt to avoid OOM on system pages allocations */
+ .gfp_retry_mayfail = true,
.resv = bp->resv,
.flags = bp->type != ttm_bo_type_kernel ?
TTM_OPT_FLAG_ALLOW_RES_EVICT : 0
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index bd6e6641c3fc..c01c060e4ac5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1914,9 +1914,6 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
}
adev->mman.initialized = true;
- /* We opt to avoid OOM on system pages allocations */
- adev->mman.bdev.no_retry = true;
-
/* Initialize VRAM pool with all of VRAM divided into pages */
r = amdgpu_vram_mgr_init(adev);
if (r) {
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 1e50deefb5d5..44ec41aa78d6 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -367,7 +367,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
if (tt->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)
gfp_flags |= __GFP_ZERO;
- if (tt->page_flags & TTM_PAGE_FLAG_NO_RETRY)
+ if (ctx->gfp_retry_mayfail)
gfp_flags |= __GFP_RETRY_MAYFAIL;
if (pool->use_dma32)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 8861a74ac335..cfd633c7e764 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -51,9 +51,6 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool
zero_alloc)
if (bo->ttm)
return 0;
- if (bdev->no_retry)
- page_flags |= TTM_PAGE_FLAG_NO_RETRY;
-
switch (bo->type) {
case ttm_bo_type_device:
if (zero_alloc)
@@ -211,8 +208,6 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
swap_space = swap_storage->f_mapping;
gfp_mask = mapping_gfp_mask(swap_space);
- if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)
- gfp_mask |= __GFP_RETRY_MAYFAIL;
for (i = 0; i < ttm->num_pages; ++i) {
from_page = shmem_read_mapping_page_gfp(swap_space, i,
@@ -260,8 +255,6 @@ int ttm_tt_swapout(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
swap_space = swap_storage->f_mapping;
gfp_mask = mapping_gfp_mask(swap_space);
- if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)
- gfp_mask |= __GFP_RETRY_MAYFAIL;
for (i = 0; i < ttm->num_pages; ++i) {
from_page = ttm->pages[i];
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 37102e45e496..4637357ba856 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -195,6 +195,7 @@ struct ttm_bo_kmap_obj {
*
* @interruptible: Sleep interruptible if sleeping.
* @no_wait_gpu: Return immediately if the GPU is busy.
+ * @gfp_retry_mayfail: Set the __GFP_RETRY_MAYFAIL when allocation pages.
* @resv: Reservation object to allow reserved evictions with.
* @flags: Including the following flags
*
@@ -204,6 +205,7 @@ struct ttm_bo_kmap_obj {
struct ttm_operation_ctx {
bool interruptible;
bool no_wait_gpu;
+ bool gfp_retry_mayfail;
struct dma_resv *resv;
uint64_t bytes_moved;
uint32_t flags;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index e9f683fa72dc..da8208f43378 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -276,7 +276,6 @@ extern struct ttm_bo_global {
* @dev_mapping: A pointer to the struct address_space representing the
* device address space.
* @wq: Work queue structure for the delayed delete workqueue.
- * @no_retry: Don't retry allocation if it fails
*
*/
@@ -314,8 +313,6 @@
Re: [PATCH v7 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
Hi Sylwester,
On Tue, Nov 3, 2020 at 8:32 PM Sylwester Nawrocki
wrote:
>
> On 03.11.2020 10:37, Chanwoo Choi wrote:
> > On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
> >> This patch adds a generic interconnect driver for Exynos SoCs in order
> >> to provide interconnect functionality for each "samsung,exynos-bus"
> >> compatible device.
> >>
> >> The SoC topology is a graph (or more specifically, a tree) and its
> >> edges are specified using the 'samsung,interconnect-parent' in the
> >
> > samsung,interconnect-parent -> interconnects?
>
> Yes, I will rephrase the whole commit message as it's a bit outdated now.
>
> I've changed the sentence to:
> "The SoC topology is a graph (or more specifically, a tree) and its
> edges are described by specifying in the 'interconnects' property
> the interconnect consumer path for each interconnect provider DT node."
>
> >> DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
> >> propagated to ensure that the parent is probed before its children.
> >>
> >> Each bus is now an interconnect provider and an interconnect node as
> >> well (cf. Documentation/interconnect/interconnect.rst), i.e. every bus
> >> registers itself as a node. Node IDs are not hardcoded but rather
> >> assigned dynamically at runtime. This approach allows for using this
> >> driver with various Exynos SoCs.
> >>
> >> Frequencies requested via the interconnect API for a given node are
> >> propagated to devfreq using dev_pm_qos_update_request(). Please note
> >> that it is not an error when CONFIG_INTERCONNECT is 'n', in which
> >> case all interconnect API functions are no-op.
> >>
> >> The bus-width DT property is to determine the interconnect data
> >> width and traslate requested bandwidth to clock frequency for each
> >> bus.
> >>
> >> Signed-off-by: Artur Świgoń
> >> Signed-off-by: Sylwester Nawrocki
>
> >> +++ b/drivers/interconnect/exynos/exynos.c
>
> >> +struct exynos_icc_priv {
> >> +struct device *dev;
> >> +
> >> +/* One interconnect node per provider */
> >> +struct icc_provider provider;
> >> +struct icc_node *node;
> >> +
> >> +struct dev_pm_qos_request qos_req;
> >> +u32 bus_clk_ratio;
> >> +};
> >> +
> >> +static struct icc_node *exynos_icc_get_parent(struct device_node *np)
> >> +{
> >> +struct of_phandle_args args;
> >> +struct icc_node_data *icc_node_data;
> >> +struct icc_node *icc_node;
> >> +int num, ret;
> >> +
> >> +num = of_count_phandle_with_args(np, "interconnects",
> >> + "#interconnect-cells");
> >> +if (num < 1)
> >> +return NULL; /* parent nodes are optional */
> >> +
> >> +/* Get the interconnect target node */
> >> +ret = of_parse_phandle_with_args(np, "interconnects",
> >> +"#interconnect-cells", 0, );
> >> +if (ret < 0)
> >> +return ERR_PTR(ret);
> >> +
> >> +icc_node_data = of_icc_get_from_provider();
> >> +of_node_put(args.np);
> >> +
> >> +if (IS_ERR(icc_node_data))
> >> +return ERR_CAST(icc_node_data);
> >> +
> >> +icc_node = icc_node_data->node;
> >> +kfree(icc_node_data);
> >> +
> >> +return icc_node;
> >> +}
> >
> > I have a question about exynos_icc_get_parent().
> > As I checked, this function returns the only one icc_node
> > as parent node. But, bus_display dt node in the exynos4412.dtsi
> > specifies the two interconnect node as following with bus_leftbus, bus_dmc,
> >
> > When I checked the return value of exynos_icc_get_parent()
> > during probing for bus_display device, exynos_icc_get_parent() function
> > only returns 'bus_leftbus' icc_node. Do you need to add two phandle
> > of icc node?
>
> Yes, as we use the interconnect consumer bindings we need to specify a path,
> i.e. a pair. When the provider node initializes it will
> link itself to that path. Currently the provider driver uses just the first
> phandle.
As I knew, the interconnect consumer bindings use the two phandles
in the interconnect core as you commented. But, in case of this,
even if add two phandles with interconnect consumding binding style,
the exynos interconnect driver only uses the first phandle.
Instead, I think we better explain this case into a dt-binding
document for users.
> > +++ b/arch/arm/boot/dts/exynos4412.dtsi
> > @@ -472,7 +472,7 @@
> > clocks = < CLK_ACLK160>;
> > clock-names = "bus";
> > operating-points-v2 = <_display_opp_table>;
> > interconnects = <_leftbus _dmc>;
> > #interconnect-cells = <0>;
> > status = "disabled";
> > };
>
> --
> Regards,
> Sylwester
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Best Regards,
Chanwoo Choi
Re: [PATCH v7 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
Hi Sylwester, On Tue, Nov 3, 2020 at 9:32 PM Sylwester Nawrocki wrote: > > Hi Chanwoo, > > On 03.11.2020 11:45, Chanwoo Choi wrote: > > On 10/30/20 9:51 PM, Sylwester Nawrocki wrote: > >> This patch adds registration of a child platform device for the exynos > >> interconnect driver. It is assumed that the interconnect provider will > >> only be needed when #interconnect-cells property is present in the bus > >> DT node, hence the child device will be created only when such a property > >> is present. > >> > >> Signed-off-by: Sylwester Nawrocki > > >> drivers/devfreq/exynos-bus.c | 17 + > > > We don't need to add 'select INTERCONNECT_EXYNOS' in Kconfig? > > I think by doing so we could run into some dependency issues. > > > Do you want to remain it as optional according to user? > Yes, I would prefer to keep it selectable through defconfig. > Currently it's only needed by one 32-bit ARM board. OK. -- Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
pixel formats denoted by fourccs. The fourcc encoding is the same for both
so the same implementation can be used.
Suggested-by: Mauro Carvalho Chehab
Signed-off-by: Sakari Ailus
---
Hi folks,
I believe I've addressed comments from Rasmus, Joe and Andy --- variables
that don't need to be negative have remained unsigned though. Thanks for
the suggestions, I believe this is much cleaner than v3.
since v3:
- Remove use of WARN_ON, assume the code is correct instead. A side effect
of this is the code is much easier to understand.
- Check the modifier first before validating the buf pointer.
- Use isascii() and isprint() functions to weed out non-printable
characters.
- Use hex_byte_pack() for printing 8-bit hexadecimal numbers.
- Remove macros, and instead use plain strings.
- Use strcpy() to copy the endianness string, and then strlen() to add its
length.
- Strip the MSB (endianness bit), then use the value as such.
- Assign characters to the buffer and increment active pointer at the same
time.
- Drop __ from variable names.
- Add example to documentation.
Documentation/core-api/printk-formats.rst | 16 +++
lib/test_printf.c | 17
lib/vsprintf.c| 52 +++
3 files changed, 85 insertions(+)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentation/core-api/printk-formats.rst
index 6d26c5c6ac48..080262d2e030 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -565,6 +565,22 @@ For printing netdev_features_t.
Passed by reference.
+V4L2 and DRM FourCC code (pixel format)
+---
+
+::
+
+ %p4cc
+
+Print a FourCC code used by V4L2 or DRM, including format endianness and
+its numerical value as hexadecimal.
+
+Passed by reference.
+
+Examples::
+
+ %p4cc BG12 little-endian (0x32314742)
+
Thanks
==
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 7ac87f18a10f..7fb042542660 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -649,6 +649,22 @@ static void __init fwnode_pointer(void)
software_node_unregister([0]);
}
+static void __init fourcc_pointer(void)
+{
+ struct {
+ u32 code;
+ char *str;
+ } const try[] = {
+ { 0x20104646, "FF(10) little-endian (0x20104646)", },
+ { 0xa0104646, "FF(10) big-endian (0xa0104646)", },
+ { 0x10111213, "(13)(12)(11)(10) little-endian (0x10111213)", },
+ };
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(try); i++)
+ test(try[i].str, "%p4cc", [i].code);
+}
+
static void __init
errptr(void)
{
@@ -694,6 +710,7 @@ test_pointer(void)
flags();
errptr();
fwnode_pointer();
+ fourcc_pointer();
}
static void __init selftest(void)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 14c9a6af1b23..2be86b302c88 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1733,6 +1733,55 @@ char *netdev_bits(char *buf, char *end, const void *addr,
return special_hex_number(buf, end, num, size);
}
+static noinline_for_stack
+char *fourcc_string(char *buf, char *end, const u32 *fourcc,
+ struct printf_spec spec, const char *fmt)
+{
+ char output[sizeof("(xx)(xx)(xx)(xx) little-endian (0x01234567)")];
+ char *p = output;
+ unsigned int i;
+ u32 val;
+
+ if (fmt[1] != 'c' || fmt[2] != 'c')
+ return error_string(output, end, "(%p4?)", spec);
+
+ if (check_pointer(, end, fourcc, spec))
+ return buf;
+
+ val = *fourcc & ~BIT(31);
+
+ for (i = 0; i < sizeof(*fourcc); i++) {
+ unsigned char c = val >> (i * 8);
+
+ /* Weed out spaces */
+ if (c == ' ')
+ continue;
+
+ /* Print non-control ASCII characters as-is */
+ if (isascii(c) && isprint(c)) {
+ *p++ = c;
+ continue;
+ }
+
+ *p++ = '(';
+ p = hex_byte_pack(p, c);
+ *p++ = ')';
+ }
+
+ strcpy(p, *fourcc & BIT(31) ? " big-endian" : " little-endian");
+ p += strlen(p);
+
+ *p++ = ' ';
+ *p++ = '(';
+ /* subtract parenthesis and the space from the size */
+ p = special_hex_number(p, output + sizeof(output) - 2, *fourcc,
+ sizeof(u32));
+ *p++ = ')';
+ *p = '\0';
+
+ return string(buf, end, output, spec);
+}
+
static noinline_for_stack
char *address_val(char *buf, char *end, const void *addr,
struct printf_spec spec, const char *fmt)
@@ -2162,6 +2211,7 @@ char *fwnode_string(char *buf, char *end, struct
fwnode_handle *fwnode,
* correctness of the format string and va_list arguments.
Re: [RESEND PATCH v3 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
Hi Rasmus,
Thanks for the review.
On Mon, Apr 27, 2020 at 05:44:00PM +0200, Rasmus Villemoes wrote:
> On 27/04/2020 16.53, Sakari Ailus wrote:
> > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by fourccs. The fourcc encoding is the same for both
> > so the same implementation can be used.
> >
> > Suggested-by: Mauro Carvalho Chehab
> > Signed-off-by: Sakari Ailus
> > ---
> > since v2:
> >
> > - Add comments to explain why things are being done
> >
> > - Print characters under 32 (space) as hexadecimals in parenthesis.
> >
> > - Do not print spaces in the fourcc codes.
> >
> > - Make use of a loop over the fourcc characters instead of
> > put_unaligned_le32(). This is necessary to omit spaces in the output.
> >
> > - Use DRM style format instead of V4L2. This provides the precise code as
> > a numerical value as well as explicit endianness information.
> >
> > - Added WARN_ON_ONCE() sanity checks. Comments on these are welcome; I'd
> > expect them mostly be covered by the tests.
> >
> > - Added tests for %p4cc in lib/test_printf.c
> >
> > Documentation/core-api/printk-formats.rst | 12
> > lib/test_printf.c | 17 +
> > lib/vsprintf.c| 86 +++
> > 3 files changed, 115 insertions(+)
> >
> > diff --git a/Documentation/core-api/printk-formats.rst
> > b/Documentation/core-api/printk-formats.rst
> > index 8ebe46b1af39..7aa0451e06fb 100644
> > --- a/Documentation/core-api/printk-formats.rst
> > +++ b/Documentation/core-api/printk-formats.rst
> > @@ -545,6 +545,18 @@ For printing netdev_features_t.
> >
> > Passed by reference.
> >
> > +V4L2 and DRM FourCC code (pixel format)
> > +---
> > +
> > +::
> > +
> > + %p4cc
> > +
> > +Print a FourCC code used by V4L2 or DRM, including format endianness and
> > +its numerical value as hexadecimal.
> > +
> > +Passed by reference.
> > +
> > Thanks
> > ==
> >
> > diff --git a/lib/test_printf.c b/lib/test_printf.c
> > index 2d9f520d2f27..a14754086707 100644
> > --- a/lib/test_printf.c
> > +++ b/lib/test_printf.c
> > @@ -624,6 +624,22 @@ static void __init fwnode_pointer(void)
> > software_node_unregister_nodes(softnodes);
> > }
> >
> > +static void __init fourcc_pointer(void)
> > +{
> > + struct {
> > + u32 code;
> > + char *str;
> > + } const try[] = {
> > + { 0x20104646, "FF(10) little-endian (0x20104646)", },
> > + { 0xa0104646, "FF(10) big-endian (0xa0104646)", },
> > + { 0x10111213, "(13)(12)(11)(10) little-endian (0x10111213)", },
> > + };
> > + unsigned int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(try); i++)
> > + test(try[i].str, "%p4cc", [i].code);
> > +}
> > +
> > static void __init
> > errptr(void)
> > {
> > @@ -668,6 +684,7 @@ test_pointer(void)
> > flags();
> > errptr();
> > fwnode_pointer();
> > + fourcc_pointer();
> > }
> >
> > static void __init selftest(void)
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > index 7c488a1ce318..02e7906619c0 100644
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -1721,6 +1721,89 @@ char *netdev_bits(char *buf, char *end, const void
> > *addr,
> > return special_hex_number(buf, end, num, size);
> > }
> >
> > +static noinline_for_stack
> > +char *fourcc_string(char *buf, char *end, const u32 *__fourcc,
> > + struct printf_spec spec, const char *fmt)
> > +{
> > +#define FOURCC_HEX_CHAR_STR"(xx)"
> > +#define FOURCC_BIG_ENDIAN_STR " big-endian"
> > +#define FOURCC_LITTLE_ENDIAN_STR " little-endian"
> > +#define FOURCC_HEX_NUMBER " (0x01234567)"
> > +#define FOURCC_STRING_MAX \
> > + FOURCC_HEX_CHAR_STR FOURCC_HEX_CHAR_STR FOURCC_HEX_CHAR_STR \
> > + FOURCC_HEX_CHAR_STR FOURCC_LITTLE_ENDIAN_STR FOURCC_HEX_NUMBER
> > + struct printf_spec my_spec = {
> > + .type = FORMAT_TYPE_UINT,
> > + .field_width = 2,
> > + .flags = SMALL,
> > + .base = 16,
> > + .precision = -1,
> > + };
> > + char __s[sizeof(FOURCC_STRING_MAX)];
> > + char *s = __s;
> > + unsigned int i;
> > + /*
> > +* The 31st bit defines the endianness of the data, so save its printing
> > +* for later.
> > +*/
> > + u32 fourcc = *__fourcc & ~BIT(31);
> > + int ret;
>
> Dereference __fourcc ...
>
> > + if (check_pointer(, end, __fourcc, spec))
> > + return buf;
>
> .. and then sanity check it?
>
> > + if (fmt[1] != 'c' || fmt[2] != 'c')
> > + return error_string(buf, end, "(%p4?)", spec);
>
> Doesn't that want to come before everything else, including the
> check_pointer()?
Agreed on all three.
>
> > + for (i = 0; i < sizeof(fourcc); i++, fourcc >>= 8) {
> > + unsigned char c = fourcc;
> > +
> > + /* Weed out spaces */
> > +
Re: [PATCH v7 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
On Tue, 3 Nov 2020 at 13:32, Sylwester Nawrocki wrote: > > Hi Chanwoo, > > On 03.11.2020 11:45, Chanwoo Choi wrote: > > On 10/30/20 9:51 PM, Sylwester Nawrocki wrote: > >> This patch adds registration of a child platform device for the exynos > >> interconnect driver. It is assumed that the interconnect provider will > >> only be needed when #interconnect-cells property is present in the bus > >> DT node, hence the child device will be created only when such a property > >> is present. > >> > >> Signed-off-by: Sylwester Nawrocki > > >> drivers/devfreq/exynos-bus.c | 17 + > > > We don't need to add 'select INTERCONNECT_EXYNOS' in Kconfig? > > I think by doing so we could run into some dependency issues. > > > Do you want to remain it as optional according to user? > Yes, I would prefer to keep it selectable through defconfig. > Currently it's only needed by one 32-bit ARM board. I am fine with it as it is really optional. You could consider then "imply" but then you would need to check for dependencies (the same as with select). Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm/dp: do not notify audio subsystem if sink doesn't support audio
For sinks that do not support audio, there is no need to notify
audio subsystem of the connection event.
This will make sure that audio routes only to the primary display
when connected to such sinks.
changes in v2:
- Added fixes tag
- Removed nested if condition and removed usage of global pointer
Fixes: d13e36d7d222 ("drm/msm/dp: add audio support for Display Port on MSM")
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 2f72817ca24f..3f59ba8fcde5 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -549,7 +549,14 @@ static int dp_connect_pending_timeout(struct
dp_display_private *dp, u32 data)
static void dp_display_handle_plugged_change(struct msm_dp *dp_display,
bool plugged)
{
- if (dp_display->plugged_cb && dp_display->codec_dev)
+ struct dp_display_private *dp;
+
+ dp = container_of(dp_display,
+ struct dp_display_private, dp_display);
+
+ /* notify audio subsystem only if sink supports audio */
+ if (dp_display->plugged_cb && dp_display->codec_dev &&
+ dp->audio_supported)
dp_display->plugged_cb(dp_display->codec_dev, plugged);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/ingenic: Add option to alloc cached GEM buffers
On Tue, Nov 3, 2020 at 12:57 PM Paul Cercueil wrote:
>
> Hi Daniel,
>
> Le mar. 3 nov. 2020 à 11:17, Daniel Vetter a écrit :
> > On Mon, Nov 02, 2020 at 10:06:51PM +, Paul Cercueil wrote:
> >> With the module parameter ingenic-drm.cached_gem_buffers, it is
> >> possible
> >> to specify that we want GEM buffers backed by non-coherent memory.
> >>
> >> This dramatically speeds up software rendering on Ingenic SoCs,
> >> even for
> >> tasks where write-combine memory should in theory be faster (e.g.
> >> simple
> >> blits).
> >>
> >> Leave it disabled by default, since it is specific to one use-case
> >> (software rendering).
> >>
> >> Signed-off-by: Paul Cercueil
> >
> > Hm so maybe I'm making myself supremely unpopular here again with
> > being
> > very late, but we have dev->mode_config.prefer_shadow for this.
> > Drivers
> > should set this if software rendering is slow, and userspace should
> > follow
> > this.
> >
> > Now unfortunately it looks like most kms drivers don't bother setting
> > this, and we're a lot worse.
> >
> > So if "slow sw rendering" is the only reason, setting that flag is the
> > right option.
>
> The "prefer_shadow" is based on the assumption that rendering to a
> shadow buffer, then memcpy that buffer to the write-combine destination
> buffer, is faster than rendering to a non-coherent destination buffer
> and sync the data cache. This might be true on some hardware, but is
> not the case on Ingenic SoCs, where even simple blits (e.g. memcpy) are
> about three times faster using the second method.
Ah right, vague memories coming back, pretty sure I asked this before.
Please include this in your commit message (and ideally also in some
code comment somewhere), since otherwise I'll keep asking the same
question every single time you submit this or I stumble over it again
:-)
Cheers, Daniel
>
> -Paul
>
> > Now the other thing is fbdev, since fbdev doesn't have this hint at
> > all.
> > But we already have full generic fbdev shadow support (for defio), so
> > for
> > that I think the best option is adding a force_shadow option to fbdev.
> >
> > If we otoh do this here, and some drivers get a in-kernel shadow
> > support
> > for kms, while others don't, then we have a pretty supreme mess. I'd
> > like
> > to avoid that.
> >
> > So maybe the right solution here is that we make sure that when you
> > have
> > cma helpers set up that mode_config.prefer_shadow is set. Ideally only
> > when coherent dma memory is uncached/write-combine and hence slow for
> > sw
> > rendering. This might need a slight dma-api layering violation.
> >
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 58
> >> +--
> >> drivers/gpu/drm/ingenic/ingenic-drm.h | 4 ++
> >> drivers/gpu/drm/ingenic/ingenic-ipu.c | 12 -
> >> 3 files changed, 69 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> index b9c156e13156..1ec2ec2faa04 100644
> >> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> @@ -9,6 +9,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -22,6 +23,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -97,6 +99,11 @@ struct ingenic_drm {
> >> struct notifier_block clock_nb;
> >> };
> >>
> >> +static bool ingenic_drm_cached_gem_buf;
> >> +module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf,
> >> bool, 0400);
> >> +MODULE_PARM_DESC(cached_gem_buffers,
> >> +"Enable fully cached GEM buffers [default=false]");
> >> +
> >> static bool ingenic_drm_writeable_reg(struct device *dev, unsigned
> >> int reg)
> >> {
> >> switch (reg) {
> >> @@ -400,6 +407,8 @@ static int
> >> ingenic_drm_plane_atomic_check(struct drm_plane *plane,
> >> plane->state->fb->format->format !=
> >> state->fb->format->format))
> >> crtc_state->mode_changed = true;
> >>
> >> + drm_atomic_helper_check_plane_damage(state->state, state);
> >> +
> >> return 0;
> >> }
> >>
> >> @@ -531,6 +540,14 @@ static void ingenic_drm_update_palette(struct
> >> ingenic_drm *priv,
> >> }
> >> }
> >>
> >> +void ingenic_drm_sync_data(struct device *dev,
> >> + struct drm_plane_state *old_state,
> >> + struct drm_plane_state *state)
> >> +{
> >> + if (ingenic_drm_cached_gem_buf)
> >> + drm_gem_cma_sync_data(dev, old_state, state);
> >> +}
> >> +
> >> static void ingenic_drm_plane_atomic_update(struct drm_plane
> >> *plane,
> >> struct drm_plane_state *oldstate)
> >> {
> >> @@ -543,6 +560,8 @@ static void
> >> ingenic_drm_plane_atomic_update(struct drm_plane *plane,
> >>
Re: [PATCH] drm: unify formatting for color management documentation
On Tue, Nov 3, 2020 at 11:31 AM Simon Ser wrote: > > Other properties are documented with a colon character after the > property name. Consistently using a colon character allows the docs to > be machine-readable. > > Signed-off-by: Simon Ser > Cc: Daniel Vetter Acked-by: Daniel Vetter > --- > drivers/gpu/drm/drm_color_mgmt.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_color_mgmt.c > b/drivers/gpu/drm/drm_color_mgmt.c > index 138ff34b31db..3bcabc2f6e0e 100644 > --- a/drivers/gpu/drm/drm_color_mgmt.c > +++ b/drivers/gpu/drm/drm_color_mgmt.c > @@ -97,12 +97,12 @@ > * _plane specific COLOR_ENCODING and COLOR_RANGE properties. They > * are set up by calling drm_plane_create_color_properties(). > * > - * "COLOR_ENCODING" > + * "COLOR_ENCODING": > * Optional plane enum property to support different non RGB > * color encodings. The driver can provide a subset of standard > * enum values supported by the DRM plane. > * > - * "COLOR_RANGE" > + * "COLOR_RANGE": > * Optional plane enum property to support different non RGB > * color parameter ranges. The driver can provide a subset of > * standard enum values supported by the DRM plane. > -- > 2.29.2 > > -- 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 v7 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
Hi Chanwoo, On 03.11.2020 11:45, Chanwoo Choi wrote: > On 10/30/20 9:51 PM, Sylwester Nawrocki wrote: >> This patch adds registration of a child platform device for the exynos >> interconnect driver. It is assumed that the interconnect provider will >> only be needed when #interconnect-cells property is present in the bus >> DT node, hence the child device will be created only when such a property >> is present. >> >> Signed-off-by: Sylwester Nawrocki >> drivers/devfreq/exynos-bus.c | 17 + > We don't need to add 'select INTERCONNECT_EXYNOS' in Kconfig? I think by doing so we could run into some dependency issues. > Do you want to remain it as optional according to user? Yes, I would prefer to keep it selectable through defconfig. Currently it's only needed by one 32-bit ARM board. -- Regards, Sylwester ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-queued
Hi Dave & Daniel - Here's the first batch of i915 changes for v5.11. I'm trying out tagging and generating the pull request directly from drm-intel-next-queued in one step this time, skipping the previous two-step process. The idea is to ditch drm-intel-next-queued in the future, and do everything directly to/from drm-intel-next. BR, Jani. drm-intel-next-queued-2020-11-03: drm/i915 features for v5.11 Highlights: - More DG1 enabling (Lucas, Matt, Aditya, Anshuman, Clinton, Matt, Stuart, Venkata) - Integer scaling filter support (Pankaj Bharadiya) - Asynchronous flip support (Karthik) Generic: - Fix gen12 forcewake tables (Matt) - Haswell PCI ID updates (Alexei Podtelezhnikov) Display: - ICL+ DSI command mode enabling (Vandita) - Shutdown displays grafecully on reboot/shutdown (Ville) - Don't register display debugfs when there is no display (Lucas) - Fix RKL CDCLK table (Matt) - Limit EHL/JSL eDP to HBR2 (José) - Handle incorrectly set (by BIOS) PLLs and DP link rates at probe (Imre) - Fix mode valid check wrt bpp for "YCbCr 4:2:0 only" modes (Ville) - State checker and dump fixes (Ville) - DP AUX backlight updates (Aaron Ma, Sean Paul) - Add DP LTTPR non-transparent link training mode (Imre) - PSR2 selective fetch enabling (José) - VBT updates (José) - HDCP updates (Ramalingam) Cleanups and refactoring: - HPD pin, AUX channel, and Type-C port identifier cleanup (Ville) - Hotplug and irq refactoring (Ville) - Better DDI encoder and AUX channel names (Ville) - Color LUT code cleanups (Ville) - Combo PHY code cleanups (Ville) - LSPCON code cleanups (Ville) - Documentation fixes (Mauro, Chris) BR, Jani. The following changes since commit 8fea92536e3efff14fa4cde7ed37c595b40a52b5: drm/i915: Update DRIVER_DATE to 20200917 (2020-09-17 16:43:57 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-queued-2020-11-03 for you to fetch changes up to 139caf7ca2866cd0a45814ff938cb0c33920a266: drm/i915: Update DRIVER_DATE to 20201103 (2020-11-03 14:21:25 +0200) drm/i915 features for v5.11 Highlights: - More DG1 enabling (Lucas, Matt, Aditya, Anshuman, Clinton, Matt, Stuart, Venkata) - Integer scaling filter support (Pankaj Bharadiya) - Asynchronous flip support (Karthik) Generic: - Fix gen12 forcewake tables (Matt) - Haswell PCI ID updates (Alexei Podtelezhnikov) Display: - ICL+ DSI command mode enabling (Vandita) - Shutdown displays grafecully on reboot/shutdown (Ville) - Don't register display debugfs when there is no display (Lucas) - Fix RKL CDCLK table (Matt) - Limit EHL/JSL eDP to HBR2 (José) - Handle incorrectly set (by BIOS) PLLs and DP link rates at probe (Imre) - Fix mode valid check wrt bpp for "YCbCr 4:2:0 only" modes (Ville) - State checker and dump fixes (Ville) - DP AUX backlight updates (Aaron Ma, Sean Paul) - Add DP LTTPR non-transparent link training mode (Imre) - PSR2 selective fetch enabling (José) - VBT updates (José) - HDCP updates (Ramalingam) Cleanups and refactoring: - HPD pin, AUX channel, and Type-C port identifier cleanup (Ville) - Hotplug and irq refactoring (Ville) - Better DDI encoder and AUX channel names (Ville) - Color LUT code cleanups (Ville) - Combo PHY code cleanups (Ville) - LSPCON code cleanups (Ville) - Documentation fixes (Mauro, Chris) Aaron Ma (2): drm/i915/dpcd_bl: uncheck PWM_PIN_CAP when detect eDP backlight capabilities drm/i915: Force DPCD backlight mode for BOE 2270 panel Aditya Swarup (3): drm/i915/display: allow to skip certain power wells drm/i915/dg1: Add DPLL macros for DG1 drm/i915/dg1: Add and setup DPLLs for DG1 Alexei Podtelezhnikov (4): drm/i915: Update Haswell PCI IDs drm/i915: Reclassify SKL 0x192a as GT3 drm/i915: Reclassify SKL 0x1923 and 0x1927 as ULT drm/i915: Add SKL GT1.5 PCI IDs Anshuman Gupta (2): drm/i915/dg1: DG1 does not support DC6 drm/i915/dg1: Update DMC_DEBUG register Chris Wilson (5): drm/i915: Force VT'd workarounds when running as a guest OS drm/i915: Drop runtime-pm assert from vgpu io accessors drm/i915/display: Unkerneldoc cnl_program_nearest_filter_coefs drm/i915: Reset the interrupt mask on disabling interrupts drm/i915: Reduce severity for fixing up mistaken VBT tc->legacy_port Clinton A Taylor (1): drm/i915/dg1: invert HPD pins Imre Deak (12): drm/i915/skl: Work around incorrect BIOS WRPLL PDIV programming drm/i915: Move the initial fastset commit check to encoder hooks drm/i915: Check for unsupported DP link rates during initial commit drm/i915: Add an encoder hook to sanitize its state during init/resume drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock drm/i915: Fix DP link training pattern mask drm/i915: Simplify
Re: [patch V3 05/37] asm-generic: Provide kmap_size.h
On Tue, Nov 3, 2020 at 10:27 AM Thomas Gleixner wrote: > > kmap_types.h is a misnomer because the old atomic MAP based array does not > exist anymore and the whole indirection of architectures including > kmap_types.h is inconinstent and does not allow to provide guard page > debugging for this misfeature. > > Add a common header file which defines the mapping stack size for all > architectures. Will be used when converting architectures over to a > generic kmap_local/atomic implementation. > > The array size is chosen with the following constraints in mind: > > - The deepest nest level in one context is 3 according to code > inspection. > > - The worst case nesting for the upcoming reemptible version would be: > > 2 maps in task context and a fault inside > 2 maps in the fault handler > 3 maps in softirq > 2 maps in interrupt > > So a total of 16 is sufficient and probably overestimated. > > Signed-off-by: Thomas Gleixner Acked-by: Arnd Bergmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm/omap: rearrange includes in omapdss.h
Drop "uapi/" and rearrange alphabetically. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/dss/omapdss.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h b/drivers/gpu/drm/omapdrm/dss/omapdss.h index ab19d4af8de7..8e9a2019f173 100644 --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h @@ -7,13 +7,13 @@ #ifndef __OMAP_DRM_DSS_H #define __OMAP_DRM_DSS_H -#include +#include +#include #include #include -#include +#include #include -#include -#include +#include #define DISPC_IRQ_FRAMEDONE(1 << 0) #define DISPC_IRQ_VSYNC(1 << 1) -- 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
[PATCH v2 3/5] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix
From: Jyri Sarha
Implement CTM color management property for OMAP CRTC using DSS
overlay manager's Color Phase Rotation matrix. The CPR matrix does not
exactly match the CTM property documentation. On DSS the CPR matrix is
applied after gamma table look up. However, it seems stupid to add a
custom property just for that.
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index d40220b2f312..b2c251a8b404 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -391,6 +391,33 @@ static void omap_crtc_manual_display_update(struct
work_struct *data)
}
}
+static s16 omap_crtc_s31_32_to_s2_8(s64 coef)
+{
+ u64 sign_bit = 1ULL << 63;
+ u64 cbits = (u64)coef;
+
+ s16 ret = clamp_val(((cbits & ~sign_bit) >> 24), 0, 0x1ff);
+
+ if (cbits & sign_bit)
+ ret = -ret;
+
+ return ret;
+}
+
+static void omap_crtc_cpr_coefs_from_ctm(const struct drm_color_ctm *ctm,
+struct omap_dss_cpr_coefs *cpr)
+{
+ cpr->rr = omap_crtc_s31_32_to_s2_8(ctm->matrix[0]);
+ cpr->rg = omap_crtc_s31_32_to_s2_8(ctm->matrix[1]);
+ cpr->rb = omap_crtc_s31_32_to_s2_8(ctm->matrix[2]);
+ cpr->gr = omap_crtc_s31_32_to_s2_8(ctm->matrix[3]);
+ cpr->gg = omap_crtc_s31_32_to_s2_8(ctm->matrix[4]);
+ cpr->gb = omap_crtc_s31_32_to_s2_8(ctm->matrix[5]);
+ cpr->br = omap_crtc_s31_32_to_s2_8(ctm->matrix[6]);
+ cpr->bg = omap_crtc_s31_32_to_s2_8(ctm->matrix[7]);
+ cpr->bb = omap_crtc_s31_32_to_s2_8(ctm->matrix[8]);
+}
+
static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
{
struct omap_drm_private *priv = crtc->dev->dev_private;
@@ -402,7 +429,15 @@ static void omap_crtc_write_crtc_properties(struct
drm_crtc *crtc)
info.default_color = 0x00;
info.trans_enabled = false;
info.partial_alpha_enabled = false;
- info.cpr_enable = false;
+
+ if (crtc->state->ctm) {
+ struct drm_color_ctm *ctm = crtc->state->ctm->data;
+
+ info.cpr_enable = true;
+ omap_crtc_cpr_coefs_from_ctm(ctm, _coefs);
+ } else {
+ info.cpr_enable = false;
+ }
priv->dispc_ops->mgr_setup(priv->dispc, omap_crtc->channel, );
}
@@ -842,7 +877,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
if (priv->dispc_ops->mgr_gamma_size(priv->dispc, channel)) {
unsigned int gamma_lut_size = 256;
- drm_crtc_enable_color_mgmt(crtc, gamma_lut_size, false, 0);
+ drm_crtc_enable_color_mgmt(crtc, gamma_lut_size, true, 0);
drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
}
--
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
[PATCH v2 0/5] drm/omap: add color mgmt support
Hi, This is a resend of the v1, after adding Pekka's reviewed-by, rebasing to latest drm-misc, and re-testing. The cover letter from v1: This series is based on patches sent about a year ago: https://lists.freedesktop.org/archives/dri-devel/2019-September/233966.html https://lists.freedesktop.org/archives/dri-devel/2019-September/233967.html I've fixed the minor issues reported, and according to the recent discussions with Pekka and Daniel, I have changed how the gamma works. After these patches omapdrm will expose DEGAMMA_LUT (and no GAMMA_LUT), and the legacy gamma-set ioctl will use DEGAMMA_LUT underneath. And on top of that, we have the CTM and plane color mgmt. Tomi Jyri Sarha (2): drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes Tomi Valkeinen (3): drm: add legacy support for using degamma for gamma drm/omap: use degamma property for gamma table drm/omap: rearrange includes in omapdss.h drivers/gpu/drm/drm_atomic_helper.c | 81 +++- drivers/gpu/drm/omapdrm/dss/dispc.c | 104 -- drivers/gpu/drm/omapdrm/dss/omapdss.h | 12 ++- drivers/gpu/drm/omapdrm/omap_crtc.c | 51 +++-- drivers/gpu/drm/omapdrm/omap_plane.c | 30 include/drm/drm_atomic_helper.h | 4 + 6 files changed, 209 insertions(+), 73 deletions(-) -- 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
[PATCH v2 5/5] drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes
From: Jyri Sarha
Adds support for COLOR_ENCODING and COLOR_RANGE properties to
omap_plane.c and dispc.c. The supported encodings and ranges are
presets are:
For COLOR_ENCODING:
- YCbCr BT.601 (default)
- YCbCr BT.709
For COLOR_RANGE:
- YCbCr limited range
- YCbCr full range (default)
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 104 --
drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 +
drivers/gpu/drm/omapdrm/omap_plane.c | 30
3 files changed, 97 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 48593932bddf..bf0c9d293077 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -874,50 +874,67 @@ static void dispc_ovl_write_color_conv_coef(struct
dispc_device *dispc,
#undef CVAL
}
-static void dispc_wb_write_color_conv_coef(struct dispc_device *dispc,
- const struct csc_coef_rgb2yuv *ct)
-{
- const enum omap_plane_id plane = OMAP_DSS_WB;
-
-#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
+/* YUV -> RGB, ITU-R BT.601, full range */
+static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_full = {
+ 256, 0, 358, /* ry, rcb, rcr |1.000 0.000 1.402|*/
+ 256, -88, -182, /* gy, gcb, gcr |1.000 -0.344 -0.714|*/
+ 256, 452,0, /* by, bcb, bcr |1.000 1.772 0.000|*/
+ true, /* full range */
+};
- dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg,
ct->yr));
- dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr,
ct->yb));
- dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb,
ct->crg));
- dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg,
ct->cbr));
- dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
+/* YUV -> RGB, ITU-R BT.601, limited range */
+static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
+ 298,0, 409,/* ry, rcb, rcr |1.164 0.000 1.596|*/
+ 298, -100, -208,/* gy, gcb, gcr |1.164 -0.392 -0.813|*/
+ 298, 516,0,/* by, bcb, bcr |1.164 2.017 0.000|*/
+ false, /* limited range */
+};
- REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES(plane), ct->full_range, 11, 11);
+/* YUV -> RGB, ITU-R BT.709, full range */
+static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt709_full = {
+ 256,0, 402,/* ry, rcb, rcr |1.000 0.000 1.570|*/
+ 256, -48, -120,/* gy, gcb, gcr |1.000 -0.187 -0.467|*/
+ 256, 475,0,/* by, bcb, bcr |1.000 1.856 0.000|*/
+ true, /* full range */
+};
-#undef CVAL
-}
+/* YUV -> RGB, ITU-R BT.709, limited range */
+static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt709_lim = {
+ 298,0, 459,/* ry, rcb, rcr |1.164 0.000 1.793|*/
+ 298, -55, -136,/* gy, gcb, gcr |1.164 -0.213 -0.533|*/
+ 298, 541,0,/* by, bcb, bcr |1.164 2.112 0.000|*/
+ false, /* limited range */
+};
-static void dispc_setup_color_conv_coef(struct dispc_device *dispc)
+static int dispc_ovl_set_csc(struct dispc_device *dispc,
+enum omap_plane_id plane,
+enum drm_color_encoding color_encoding,
+enum drm_color_range color_range)
{
- int i;
- int num_ovl = dispc_get_num_ovls(dispc);
-
- /* YUV -> RGB, ITU-R BT.601, limited range */
- const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
- 298,0, 409,/* ry, rcb, rcr */
- 298, -100, -208,/* gy, gcb, gcr */
- 298, 516,0,/* by, bcb, bcr */
- false, /* limited range */
- };
+ const struct csc_coef_yuv2rgb *csc;
- /* RGB -> YUV, ITU-R BT.601, limited range */
- const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
-66, 129, 25, /* yr, yg, yb */
- -38, -74, 112, /* cbr, cbg, cbb */
- 112, -94, -18, /* crr, crg, crb */
- false, /* limited range */
- };
+ switch (color_encoding) {
+ case DRM_COLOR_YCBCR_BT601:
+ if (color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+ csc = _yuv2rgb_bt601_full;
+ else
+ csc = _yuv2rgb_bt601_lim;
+ break;
+ case DRM_COLOR_YCBCR_BT709:
+ if (color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+ csc = _yuv2rgb_bt709_full;
+ else
+ csc = _yuv2rgb_bt709_lim;
+ break;
+ default:
+ DSSERR("Unsupported CSC mode %d for
[PATCH v2 2/5] drm/omap: use degamma property for gamma table
omapdrm supports gamma via GAMMA_LUT property. However, the HW we have
is:
gamma -> ctm -> out
instead of what the model DRM framework uses:
ctm -> gamma -> out
As the following patches add CTM support for omapdrm, lets first fix the
gamma.
This patch changes the property from GAMMA_LUT to DEGAMMA_LUT, and uses
drm_atomic_helper_legacy_degamma_set for gamma_set helper. Thus we will
have:
degamma -> ctm -> out
and the legacy ioctl will continue working as before.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Pekka Paalanen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index d7442aa55f89..d40220b2f312 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -575,8 +575,8 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
crtc);
struct drm_plane_state *pri_state;
- if (crtc_state->color_mgmt_changed && crtc_state->gamma_lut) {
- unsigned int length = crtc_state->gamma_lut->length /
+ if (crtc_state->color_mgmt_changed && crtc_state->degamma_lut) {
+ unsigned int length = crtc_state->degamma_lut->length /
sizeof(struct drm_color_lut);
if (length < 2)
@@ -617,10 +617,10 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_color_lut *lut = NULL;
unsigned int length = 0;
- if (crtc->state->gamma_lut) {
+ if (crtc->state->degamma_lut) {
lut = (struct drm_color_lut *)
- crtc->state->gamma_lut->data;
- length = crtc->state->gamma_lut->length /
+ crtc->state->degamma_lut->data;
+ length = crtc->state->degamma_lut->length /
sizeof(*lut);
}
priv->dispc_ops->mgr_set_gamma(priv->dispc, omap_crtc->channel,
@@ -741,7 +741,7 @@ static const struct drm_crtc_funcs omap_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = omap_crtc_destroy,
.page_flip = drm_atomic_helper_page_flip,
- .gamma_set = drm_atomic_helper_legacy_gamma_set,
+ .gamma_set = drm_atomic_helper_legacy_degamma_set,
.atomic_duplicate_state = omap_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
.atomic_set_property = omap_crtc_atomic_set_property,
@@ -842,7 +842,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
if (priv->dispc_ops->mgr_gamma_size(priv->dispc, channel)) {
unsigned int gamma_lut_size = 256;
- drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
+ drm_crtc_enable_color_mgmt(crtc, gamma_lut_size, false, 0);
drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
}
--
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
[PATCH v2 1/5] drm: add legacy support for using degamma for gamma
We currently have drm_atomic_helper_legacy_gamma_set() helper which can
be used to handle legacy gamma-set ioctl.
drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
CTM and DEGAMMA_LUT. This works fine on HW where we have either:
degamma -> ctm -> gamma -> out
or
ctm -> gamma -> out
However, if the HW has gamma table before ctm, the atomic property
should be DEGAMMA_LUT, and thus we have:
degamma -> ctm -> out
This is fine for userspace which sets gamma table using the properties,
as the userspace can check for the existence of gamma & degamma, but the
legacy gamma-set ioctl does not work.
This patch adds a new helper, drm_atomic_helper_legacy_degamma_set(),
which can be used instead of drm_atomic_helper_legacy_gamma_set() when
the DEGAMMA_LUT is the underlying property that needs to be set.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Pekka Paalanen
---
drivers/gpu/drm/drm_atomic_helper.c | 81 ++---
include/drm/drm_atomic_helper.h | 4 ++
2 files changed, 65 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ddd0e3239150..23cbed541dc7 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3499,24 +3499,11 @@ int drm_atomic_helper_page_flip_target(struct drm_crtc
*crtc,
}
EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
-/**
- * drm_atomic_helper_legacy_gamma_set - set the legacy gamma correction table
- * @crtc: CRTC object
- * @red: red correction table
- * @green: green correction table
- * @blue: green correction table
- * @size: size of the tables
- * @ctx: lock acquire context
- *
- * Implements support for legacy gamma correction table for drivers
- * that support color management through the DEGAMMA_LUT/GAMMA_LUT
- * properties. See drm_crtc_enable_color_mgmt() and the containing chapter for
- * how the atomic color management and gamma tables work.
- */
-int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
- u16 *red, u16 *green, u16 *blue,
- uint32_t size,
- struct drm_modeset_acquire_ctx *ctx)
+static int legacy_gamma_degamma_set(struct drm_crtc *crtc,
+ u16 *red, u16 *green, u16 *blue,
+ uint32_t size,
+ struct drm_modeset_acquire_ctx *ctx,
+ bool use_degamma)
{
struct drm_device *dev = crtc->dev;
struct drm_atomic_state *state;
@@ -3555,9 +3542,11 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
}
/* Reset DEGAMMA_LUT and CTM properties. */
- replaced = drm_property_replace_blob(_state->degamma_lut, NULL);
+ replaced = drm_property_replace_blob(_state->degamma_lut,
+ use_degamma ? blob : NULL);
replaced |= drm_property_replace_blob(_state->ctm, NULL);
- replaced |= drm_property_replace_blob(_state->gamma_lut, blob);
+ replaced |= drm_property_replace_blob(_state->gamma_lut,
+ use_degamma ? NULL : blob);
crtc_state->color_mgmt_changed |= replaced;
ret = drm_atomic_commit(state);
@@ -3567,8 +3556,60 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
drm_property_blob_put(blob);
return ret;
}
+
+/**
+ * drm_atomic_helper_legacy_gamma_set - set the legacy gamma correction table
using gamma_lut
+ * @crtc: CRTC object
+ * @red: red correction table
+ * @green: green correction table
+ * @blue: green correction table
+ * @size: size of the tables
+ * @ctx: lock acquire context
+ *
+ * Implements support for legacy gamma correction table for drivers
+ * that support color management through the DEGAMMA_LUT/GAMMA_LUT
+ * properties. See drm_crtc_enable_color_mgmt() and the containing chapter for
+ * how the atomic color management and gamma tables work.
+ *
+ * This function uses GAMMA_LUT property for the gamma table. This function
+ * can be used when the driver exposes either only GAMMA_LUT or both GAMMA_LUT
+ * and DEGAMMA_LUT.
+ */
+int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
+ u16 *red, u16 *green, u16 *blue,
+ uint32_t size,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ return legacy_gamma_degamma_set(crtc, red, green, blue, size, ctx,
false);
+}
EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
+/**
+ * drm_atomic_helper_legacy_degamma_set - set the legacy gamma correction
table using degamma_lut
+ * @crtc: CRTC object
+ * @red: red correction table
+ * @green: green correction table
+ * @blue: green correction table
+ * @size: size of the tables
+ * @ctx: lock acquire context
+ *
+ * Implements support for legacy
Re: [PATCH v3] drm/panfrost: Move the GPU reset bits outside the timeout handler
On Tue, 3 Nov 2020 12:08:47 +0100
Daniel Vetter wrote:
> On Tue, Nov 03, 2020 at 12:03:26PM +0100, Boris Brezillon wrote:
> > On Tue, 3 Nov 2020 11:25:40 +0100
> > Daniel Vetter wrote:
> >
> > > On Tue, Nov 03, 2020 at 09:13:47AM +0100, Boris Brezillon wrote:
> > > > We've fixed many races in panfrost_job_timedout() but some remain.
> > > > Instead of trying to fix it again, let's simplify the logic and move
> > > > the reset bits to a separate work scheduled when one of the queue
> > > > reports a timeout.
> > > >
> > > > v3:
> > > > - Replace the atomic_cmpxchg() by an atomic_xchg() (Robin Murphy)
> > > > - Add Steven's R-b
> > > >
> > > > v2:
> > > > - Use atomic_cmpxchg() to conditionally schedule the reset work (Steven
> > > > Price)
> > > >
> > > > Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling")
> > > > Cc:
> > > > Signed-off-by: Boris Brezillon
> > > > Reviewed-by: Steven Price
> > >
> > > Sprinkling the dma_fence annotations over this would be really nice ...
> >
> > You mean something like that?
>
> That's just the irq annotations, i.e. the one that's already guaranteed by
> the irq vs. locks checks. So this does nothing.
>
> What I mean is annotating your new reset work (it's part of the critical
> path to complete batches, since it's holding up other batches that are
> stuck in the scheduler still), and the drm/scheduler annotations I've
> floated a while ago. The drm/scheduler annotations are stuck somewhat for
> lack of feedback from any of the driver teams using it though :-/
>
> The thing is pulling something out into a worker of it's own generally
> doesn't fix any deadlocks, it just hides them from lockdep.
Hm, except that's not exactly a deadlock we were trying to fix here (as
in, not a situation where 2 threads try to acquire locks in different
orders), just a situation where the scheduler stops dequeuing jobs
because it ends up in an inconsistent state (which is caused by a
bad/lack-of synchronization between timeout handlers). The problem here
is that we have 3 schedulers (one per HW queue) but when a timeout
occurs on one of them, we need to reset them all, thus requiring some
synchronization between the different timeout works. Moving the reset
logic to a separate work simplifies the synchronization.
> So it would be
> good to make sure lockdep can see through your maze again.
Okay, but it's not clear to me which part of the panfrost_reset()
function should be annotated. I mean, I probably call functions that
can signal fences, but I don't call dma_signal_fence() directly. Are
callers of the dma_sched_xxx() helpers expected to place such
annotations?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Add the new api to install irq
On Tue, Nov 03, 2020 at 12:25:06PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 03.11.20 um 11:55 schrieb Daniel Vetter:
> > On Tue, Nov 03, 2020 at 11:38:32AM +0100, Maxime Ripard wrote:
> >> On Tue, Nov 03, 2020 at 11:10:27AM +0100, Thomas Zimmermann wrote:
> >>> Hi
> >>>
> >>> Am 03.11.20 um 10:52 schrieb Maxime Ripard:
> On Tue, Nov 03, 2020 at 10:10:41AM +0800, Tian Tao wrote:
> > Add new api devm_drm_irq_install() to register interrupts,
> > no need to call drm_irq_uninstall() when the drm module is removed.
> >
> > v2:
> > fixed the wrong parameter.
> >
> > Signed-off-by: Tian Tao
> > ---
> > drivers/gpu/drm/drm_drv.c | 23 +++
> > include/drm/drm_drv.h | 3 ++-
> > 2 files changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index cd162d4..0fe5243 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -39,6 +39,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -678,6 +679,28 @@ static int devm_drm_dev_init(struct device *parent,
> > return ret;
> > }
> >
> > +static void devm_drm_dev_irq_uninstall(void *data)
> > +{
> > + drm_irq_uninstall(data);
> > +}
> > +
> > +int devm_drm_irq_install(struct device *parent,
> > +struct drm_device *dev, int irq)
> > +{
> > + int ret;
> > +
> > + ret = drm_irq_install(dev, irq);
> > + if (ret)
> > + return ret;
> > +
> > + ret = devm_add_action(parent, devm_drm_dev_irq_uninstall, dev);
> > + if (ret)
> > + devm_drm_dev_irq_uninstall(dev);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL(devm_drm_irq_install);
> > +
>
> Shouldn't we tie the IRQ to the drm device (so with drmm_add_action)
> instead of tying it to the underlying device?
> >>>
> >>> If the HW device goes away, there won't be any more interrupts. So it's
> >>> similar to devm_ functions for I/O memory. Why would you use the drmm_
> >>> interface?
> >>
> >> drm_irq_install/uninstall do more that just calling request_irq and
> >> free_irq though, they will also run (among other things) the irq-related
> >> hooks in the drm driver (irq_preinstall, irq_postinstall irq_uninstall)
> >> and wake anything waiting for a vblank to occur, so we need the DRM
> >> device and driver to still be around when we run drm_irq_uninstall.
> >> That's why (I assume) you have to pass the drm_device as an argument and
> >> not simply the device.
> >
> > drm_device is guaranteed to outlive devm_, plus the hooks are meant to
> > shut down hw. hw isn't around anymore when we do drmm_ cleanup, at least
> > not in full generality.
> >
> >> This probably works in most case since you would allocate the drm_device
> >> with devm_drm_dev_alloc, and then run drm_irq_install, so in the undoing
> >> phase you would have first drm_irq_uninstall to run, and everything is
> >> fine.
> >>
> >> However, if one doesn't use devm_drm_dev_alloc but would use
> >> devm_drm_irq_install, you would have first remove being called that
> >> would free the drm device, and then drm_irq_uninstall which will use a
> >> free'd pointer.
> >
> > Don't do that, it's broken :-)
>
> Umm, I just saw that hibmc doesn't use devm_drm_dev_alloc. So maybe we
> have to convert it first before using the managed irq function. OTOH
> converting it is a good idea in any case, so why not. :)
Yeah that doesn't work as-is.
I guess the second option would be if devm_drm_dev_irqinstall would take a
drm_dev_get() reference of its own. Not sure that's a good idea, but it
would make the thing a bit more flexible.
-Daniel
>
> Best regards
> Thomas
>
> >
> >> So yeah, even though the interrupt line itself is tied to the device,
> >> all the logic we have around the interrupt that is dealt with in
> >> drm_irq_install is really tied to the drm_device. And since we tie the
> >> life of drm_device to its underlying device already (either implicitly
> >> through devm_drm_dev_alloc, or explictly through manual allocation in
> >> probe and free in remove) we can't end up in a situation where the
> >> drm_device outlives its device.
> >
> > Most drivers get their drm_device lifetime completely wrong. That's why I
> > typed drmm_ stuff. So this isn't a surprise at all, but it might motiveate
> > a bunch more people to fix this up correctly.
> >
> > Also, these drm_irq functions are 100% optional helpers (should maybe
> > rename them to make this clearer) for modern drivers. They're only built
> > in for DRIVER_LEGACY, because hysterical raisins.
> > -Daniel
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
>
Re: [PATCH v2 0/3] drm: Store USB device in struct drm_device
Hi, On 11/3/20 12:30 PM, Thomas Zimmermann wrote: > Hi > > Am 03.11.20 um 12:09 schrieb Hans de Goede: >> Hi, >> >> On 11/3/20 11:36 AM, Thomas Zimmermann wrote: >>> The drivers gm12u320 and udl operate on USB devices. They leave the PCI >>> device in struct drm_device empty and store the USB device in their own >>> driver structure. It's expected that DRM core and helpers only touch the >>> PCI-device field for actual PCI devices. >>> >>> Fix this special case by upcasting struct drm_device.dev to the USB >>> device. The drivers' udev variables are being removed. >>> >>> v2: >>> * upcast USB device from struct drm_device.dev (Daniel) >>> >>> Thomas Zimmermann (3): >>> drm: Add USB helpers >>> drm/tiny/gm12u320: Retrieve USB device from struct drm_device.dev >>> drm/udl: Retrieve USB device from struct drm_device.dev >> >> Thanks. >> >> The entire series looks good to me: >> >> Reviewed-by: Hans de Goede > > Thanks! > >> >> Note you may want to wait with pushing this to drm-misc until the >> first patch gets at least one other review. > > Following Daniel's request, I'll drop the first patch and put the helper > into the drivers. Ok, that works for me. >> Or at least give others some time to possibly react :) > > Sure, I'll merge it later this week. My remark was mostly to give Daniel time to react... BTW I missed Daniel's reaction again. Now I have figured out why though for some reason RH's email system is marking Daniels mails as spam, so they were in my spam folder ? Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: sor: Don't warn on probe deferral
Deferred probe is an expected return value for tegra_output_probe().
Given that the driver deals with it properly, there's no need to output
a warning that may potentially confuse users.
Signed-off-by: Jon Hunter
---
drivers/gpu/drm/tegra/sor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index e88a17c2937f..5a232055b8cc 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3765,7 +3765,7 @@ static int tegra_sor_probe(struct platform_device *pdev)
err = tegra_output_probe(>output);
if (err < 0) {
- dev_err(>dev, "failed to probe output: %d\n", err);
+ dev_err_probe(>dev, "failed to probe output: %d\n", err);
return err;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/udl: Retrieve USB device from struct drm_device.dev
Drop the driver's udev field in favor of struct drm_device.dev. No
functional changes made.
v3:
* upcast dev with udl_to_usb_device()
v2:
* upcast dev with drm_dev_get_usb_device()
Signed-off-by: Thomas Zimmermann
Reviewed-by: Hans de Goede
Acked-by: Daniel Vetter
---
drivers/gpu/drm/udl/udl_connector.c | 8
drivers/gpu/drm/udl/udl_drv.c | 3 ---
drivers/gpu/drm/udl/udl_drv.h | 6 +-
drivers/gpu/drm/udl/udl_main.c | 23 ---
4 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_connector.c
b/drivers/gpu/drm/udl/udl_connector.c
index cdc1c42e1669..3750fd216131 100644
--- a/drivers/gpu/drm/udl/udl_connector.c
+++ b/drivers/gpu/drm/udl/udl_connector.c
@@ -20,6 +20,7 @@ static int udl_get_edid_block(void *data, u8 *buf, unsigned
int block,
int ret, i;
u8 *read_buff;
struct udl_device *udl = data;
+ struct usb_device *udev = udl_to_usb_device(udl);
read_buff = kmalloc(2, GFP_KERNEL);
if (!read_buff)
@@ -27,10 +28,9 @@ static int udl_get_edid_block(void *data, u8 *buf, unsigned
int block,
for (i = 0; i < len; i++) {
int bval = (i + block * EDID_LENGTH) << 8;
- ret = usb_control_msg(udl->udev,
- usb_rcvctrlpipe(udl->udev, 0),
- (0x02), (0x80 | (0x02 << 5)), bval,
- 0xA1, read_buff, 2, HZ);
+ ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ 0x02, (0x80 | (0x02 << 5)), bval,
+ 0xA1, read_buff, 2, HZ);
if (ret < 1) {
DRM_ERROR("Read EDID byte %d failed err %x\n", i, ret);
kfree(read_buff);
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 96d4317a2c1b..993469d152da 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -53,7 +53,6 @@ static struct drm_driver driver = {
static struct udl_device *udl_driver_create(struct usb_interface *interface)
{
- struct usb_device *udev = interface_to_usbdev(interface);
struct udl_device *udl;
int r;
@@ -62,8 +61,6 @@ static struct udl_device *udl_driver_create(struct
usb_interface *interface)
if (IS_ERR(udl))
return udl;
- udl->udev = udev;
-
r = udl_init(udl);
if (r)
return ERR_PTR(r);
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index b1461f30780b..875e73551ae9 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -50,7 +50,6 @@ struct urb_list {
struct udl_device {
struct drm_device drm;
struct device *dev;
- struct usb_device *udev;
struct drm_simple_display_pipe display_pipe;
@@ -66,6 +65,11 @@ struct udl_device {
#define to_udl(x) container_of(x, struct udl_device, drm)
+static inline struct usb_device *udl_to_usb_device(struct udl_device *udl)
+{
+ return interface_to_usbdev(to_usb_interface(udl->drm.dev));
+}
+
/* modeset */
int udl_modeset_init(struct drm_device *dev);
struct drm_connector *udl_connector_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index f5d27f2a5654..0e2a376cb075 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -26,10 +26,9 @@
#define GET_URB_TIMEOUTHZ
#define FREE_URB_TIMEOUT (HZ*2)
-static int udl_parse_vendor_descriptor(struct drm_device *dev,
- struct usb_device *usbdev)
+static int udl_parse_vendor_descriptor(struct udl_device *udl)
{
- struct udl_device *udl = to_udl(dev);
+ struct usb_device *udev = udl_to_usb_device(udl);
char *desc;
char *buf;
char *desc_end;
@@ -41,7 +40,7 @@ static int udl_parse_vendor_descriptor(struct drm_device *dev,
return false;
desc = buf;
- total_len = usb_get_descriptor(usbdev, 0x5f, /* vendor specific */
+ total_len = usb_get_descriptor(udev, 0x5f, /* vendor specific */
0, desc, MAX_VENDOR_DESCRIPTOR_SIZE);
if (total_len > 5) {
DRM_INFO("vendor descriptor length:%x data:%11ph\n",
@@ -98,19 +97,20 @@ static int udl_parse_vendor_descriptor(struct drm_device
*dev,
*/
static int udl_select_std_channel(struct udl_device *udl)
{
- int ret;
static const u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
0x1C, 0x88, 0x5E, 0x15,
0x60, 0xFE, 0xC6, 0x97,
0x16, 0x3D, 0x47, 0xF2};
+
void *sendbuf;
+ int ret;
+ struct usb_device *udev = udl_to_usb_device(udl);
sendbuf =
[PATCH v3 1/2] drm/tiny/gm12u320: Retrieve USB device from struct drm_device.dev
Drop the driver's udev field in favor of struct drm_device.dev. No
functional changes made.
v3:
* upcast dev with gm12u320_to_usb_device()
v2:
* upcast dev with drm_dev_get_usb_device()
Signed-off-by: Thomas Zimmermann
Reviewed-by: Hans de Goede
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/gm12u320.c | 56 -
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index cc397671f689..9c214a0f39ed 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -45,7 +45,7 @@ MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright,
more silent)");
#define GM12U320_BLOCK_COUNT 20
#define GM12U320_ERR(fmt, ...) \
- DRM_DEV_ERROR(>udev->dev, fmt, ##__VA_ARGS__)
+ DRM_DEV_ERROR(gm12u320->dev.dev, fmt, ##__VA_ARGS__)
#define MISC_RCV_EPT 1
#define DATA_RCV_EPT 2
@@ -85,7 +85,6 @@ struct gm12u320_device {
struct drm_devicedev;
struct drm_simple_display_pipe pipe;
struct drm_connector conn;
- struct usb_device *udev;
unsigned char *cmd_buf;
unsigned char *data_buf[GM12U320_BLOCK_COUNT];
struct {
@@ -155,6 +154,11 @@ static const char
data_block_footer[DATA_BLOCK_FOOTER_SIZE] = {
0x80, 0x00, 0x00, 0x4f
};
+static inline struct usb_device *gm12u320_to_usb_device(struct gm12u320_device
*gm12u320)
+{
+ return interface_to_usbdev(to_usb_interface(gm12u320->dev.dev));
+}
+
static int gm12u320_usb_alloc(struct gm12u320_device *gm12u320)
{
int i, block_size;
@@ -191,6 +195,7 @@ static int gm12u320_misc_request(struct gm12u320_device
*gm12u320,
u8 req_a, u8 req_b,
u8 arg_a, u8 arg_b, u8 arg_c, u8 arg_d)
{
+ struct usb_device *udev = gm12u320_to_usb_device(gm12u320);
int ret, len;
memcpy(gm12u320->cmd_buf, _misc, CMD_SIZE);
@@ -202,8 +207,7 @@ static int gm12u320_misc_request(struct gm12u320_device
*gm12u320,
gm12u320->cmd_buf[25] = arg_d;
/* Send request */
- ret = usb_bulk_msg(gm12u320->udev,
- usb_sndbulkpipe(gm12u320->udev, MISC_SND_EPT),
+ ret = usb_bulk_msg(udev, usb_sndbulkpipe(udev, MISC_SND_EPT),
gm12u320->cmd_buf, CMD_SIZE, , CMD_TIMEOUT);
if (ret || len != CMD_SIZE) {
GM12U320_ERR("Misc. req. error %d\n", ret);
@@ -211,8 +215,7 @@ static int gm12u320_misc_request(struct gm12u320_device
*gm12u320,
}
/* Read value */
- ret = usb_bulk_msg(gm12u320->udev,
- usb_rcvbulkpipe(gm12u320->udev, MISC_RCV_EPT),
+ ret = usb_bulk_msg(udev, usb_rcvbulkpipe(udev, MISC_RCV_EPT),
gm12u320->cmd_buf, MISC_VALUE_SIZE, ,
DATA_TIMEOUT);
if (ret || len != MISC_VALUE_SIZE) {
@@ -222,8 +225,7 @@ static int gm12u320_misc_request(struct gm12u320_device
*gm12u320,
/* cmd_buf[0] now contains the read value, which we don't use */
/* Read status */
- ret = usb_bulk_msg(gm12u320->udev,
- usb_rcvbulkpipe(gm12u320->udev, MISC_RCV_EPT),
+ ret = usb_bulk_msg(udev, usb_rcvbulkpipe(udev, MISC_RCV_EPT),
gm12u320->cmd_buf, READ_STATUS_SIZE, ,
CMD_TIMEOUT);
if (ret || len != READ_STATUS_SIZE) {
@@ -331,6 +333,7 @@ static void gm12u320_fb_update_work(struct work_struct
*work)
struct gm12u320_device *gm12u320 =
container_of(to_delayed_work(work), struct gm12u320_device,
fb_update.work);
+ struct usb_device *udev = gm12u320_to_usb_device(gm12u320);
int block, block_size, len;
int ret = 0;
@@ -350,43 +353,41 @@ static void gm12u320_fb_update_work(struct work_struct
*work)
gm12u320->cmd_buf[21] =
block | (gm12u320->fb_update.frame << 7);
- ret = usb_bulk_msg(gm12u320->udev,
- usb_sndbulkpipe(gm12u320->udev, DATA_SND_EPT),
- gm12u320->cmd_buf, CMD_SIZE, ,
- CMD_TIMEOUT);
+ ret = usb_bulk_msg(udev,
+ usb_sndbulkpipe(udev, DATA_SND_EPT),
+ gm12u320->cmd_buf, CMD_SIZE, ,
+ CMD_TIMEOUT);
if (ret || len != CMD_SIZE)
goto err;
/* Send data block to device */
- ret = usb_bulk_msg(gm12u320->udev,
- usb_sndbulkpipe(gm12u320->udev, DATA_SND_EPT),
- gm12u320->data_buf[block], block_size,
- , DATA_TIMEOUT);
+
[PATCH v3 0/2] drm: Store USB device in struct drm_device
The drivers gm12u320 and udl operate on USB devices. They leave the PCI device in struct drm_device empty and store the USB device in their own driver structure. It's expected that DRM core and helpers only touch the PCI-device field for actual PCI devices. Fix this special case by upcasting struct drm_device.dev to the USB device. The drivers' udev variables are being removed. v3: * drop USB helper in favor of driver-internal helpers (Daniel) v2: * upcast USB device from struct drm_device.dev (Daniel) Thomas Zimmermann (2): drm/tiny/gm12u320: Retrieve USB device from struct drm_device.dev drm/udl: Retrieve USB device from struct drm_device.dev drivers/gpu/drm/tiny/gm12u320.c | 56 ++--- drivers/gpu/drm/udl/udl_connector.c | 8 ++--- drivers/gpu/drm/udl/udl_drv.c | 3 -- drivers/gpu/drm/udl/udl_drv.h | 6 +++- drivers/gpu/drm/udl/udl_main.c | 23 ++-- 5 files changed, 49 insertions(+), 47 deletions(-) -- 2.29.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
On 03.11.2020 10:37, Chanwoo Choi wrote:
> On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
>> This patch adds a generic interconnect driver for Exynos SoCs in order
>> to provide interconnect functionality for each "samsung,exynos-bus"
>> compatible device.
>>
>> The SoC topology is a graph (or more specifically, a tree) and its
>> edges are specified using the 'samsung,interconnect-parent' in the
>
> samsung,interconnect-parent -> interconnects?
Yes, I will rephrase the whole commit message as it's a bit outdated now.
I've changed the sentence to:
"The SoC topology is a graph (or more specifically, a tree) and its
edges are described by specifying in the 'interconnects' property
the interconnect consumer path for each interconnect provider DT node."
>> DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
>> propagated to ensure that the parent is probed before its children.
>>
>> Each bus is now an interconnect provider and an interconnect node as
>> well (cf. Documentation/interconnect/interconnect.rst), i.e. every bus
>> registers itself as a node. Node IDs are not hardcoded but rather
>> assigned dynamically at runtime. This approach allows for using this
>> driver with various Exynos SoCs.
>>
>> Frequencies requested via the interconnect API for a given node are
>> propagated to devfreq using dev_pm_qos_update_request(). Please note
>> that it is not an error when CONFIG_INTERCONNECT is 'n', in which
>> case all interconnect API functions are no-op.
>>
>> The bus-width DT property is to determine the interconnect data
>> width and traslate requested bandwidth to clock frequency for each
>> bus.
>>
>> Signed-off-by: Artur Świgoń
>> Signed-off-by: Sylwester Nawrocki
>> +++ b/drivers/interconnect/exynos/exynos.c
>> +struct exynos_icc_priv {
>> +struct device *dev;
>> +
>> +/* One interconnect node per provider */
>> +struct icc_provider provider;
>> +struct icc_node *node;
>> +
>> +struct dev_pm_qos_request qos_req;
>> +u32 bus_clk_ratio;
>> +};
>> +
>> +static struct icc_node *exynos_icc_get_parent(struct device_node *np)
>> +{
>> +struct of_phandle_args args;
>> +struct icc_node_data *icc_node_data;
>> +struct icc_node *icc_node;
>> +int num, ret;
>> +
>> +num = of_count_phandle_with_args(np, "interconnects",
>> + "#interconnect-cells");
>> +if (num < 1)
>> +return NULL; /* parent nodes are optional */
>> +
>> +/* Get the interconnect target node */
>> +ret = of_parse_phandle_with_args(np, "interconnects",
>> +"#interconnect-cells", 0, );
>> +if (ret < 0)
>> +return ERR_PTR(ret);
>> +
>> +icc_node_data = of_icc_get_from_provider();
>> +of_node_put(args.np);
>> +
>> +if (IS_ERR(icc_node_data))
>> +return ERR_CAST(icc_node_data);
>> +
>> +icc_node = icc_node_data->node;
>> +kfree(icc_node_data);
>> +
>> +return icc_node;
>> +}
>
> I have a question about exynos_icc_get_parent().
> As I checked, this function returns the only one icc_node
> as parent node. But, bus_display dt node in the exynos4412.dtsi
> specifies the two interconnect node as following with bus_leftbus, bus_dmc,
>
> When I checked the return value of exynos_icc_get_parent()
> during probing for bus_display device, exynos_icc_get_parent() function
> only returns 'bus_leftbus' icc_node. Do you need to add two phandle
> of icc node?
Yes, as we use the interconnect consumer bindings we need to specify a path,
i.e. a pair. When the provider node initializes it will
link itself to that path. Currently the provider driver uses just the first
phandle.
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -472,7 +472,7 @@
> clocks = < CLK_ACLK160>;
> clock-names = "bus";
> operating-points-v2 = <_display_opp_table>;
> interconnects = <_leftbus _dmc>;
> #interconnect-cells = <0>;
> status = "disabled";
> };
--
Regards,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm: Store USB device in struct drm_device
Hi Am 03.11.20 um 12:09 schrieb Hans de Goede: > Hi, > > On 11/3/20 11:36 AM, Thomas Zimmermann wrote: >> The drivers gm12u320 and udl operate on USB devices. They leave the PCI >> device in struct drm_device empty and store the USB device in their own >> driver structure. It's expected that DRM core and helpers only touch the >> PCI-device field for actual PCI devices. >> >> Fix this special case by upcasting struct drm_device.dev to the USB >> device. The drivers' udev variables are being removed. >> >> v2: >> * upcast USB device from struct drm_device.dev (Daniel) >> >> Thomas Zimmermann (3): >> drm: Add USB helpers >> drm/tiny/gm12u320: Retrieve USB device from struct drm_device.dev >> drm/udl: Retrieve USB device from struct drm_device.dev > > Thanks. > > The entire series looks good to me: > > Reviewed-by: Hans de Goede Thanks! > > Note you may want to wait with pushing this to drm-misc until the > first patch gets at least one other review. Following Daniel's request, I'll drop the first patch and put the helper into the drivers. > > Or at least give others some time to possibly react :) Sure, I'll merge it later this week. Best regards Thomas > > Regards, > > Hans > > > > >> >> Documentation/gpu/drm-internals.rst | 5 +++ >> drivers/gpu/drm/tiny/gm12u320.c | 52 + >> drivers/gpu/drm/udl/udl_connector.c | 9 ++--- >> drivers/gpu/drm/udl/udl_drv.c | 3 -- >> drivers/gpu/drm/udl/udl_drv.h | 1 - >> drivers/gpu/drm/udl/udl_main.c | 25 -- >> include/drm/drm_usb_helper.h| 25 ++ >> 7 files changed, 73 insertions(+), 47 deletions(-) >> create mode 100644 include/drm/drm_usb_helper.h >> >> -- >> 2.29.0 >> > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Add the new api to install irq
Hi
Am 03.11.20 um 11:55 schrieb Daniel Vetter:
> On Tue, Nov 03, 2020 at 11:38:32AM +0100, Maxime Ripard wrote:
>> On Tue, Nov 03, 2020 at 11:10:27AM +0100, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 03.11.20 um 10:52 schrieb Maxime Ripard:
On Tue, Nov 03, 2020 at 10:10:41AM +0800, Tian Tao wrote:
> Add new api devm_drm_irq_install() to register interrupts,
> no need to call drm_irq_uninstall() when the drm module is removed.
>
> v2:
> fixed the wrong parameter.
>
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/drm_drv.c | 23 +++
> include/drm/drm_drv.h | 3 ++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index cd162d4..0fe5243 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -678,6 +679,28 @@ static int devm_drm_dev_init(struct device *parent,
> return ret;
> }
>
> +static void devm_drm_dev_irq_uninstall(void *data)
> +{
> + drm_irq_uninstall(data);
> +}
> +
> +int devm_drm_irq_install(struct device *parent,
> + struct drm_device *dev, int irq)
> +{
> + int ret;
> +
> + ret = drm_irq_install(dev, irq);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action(parent, devm_drm_dev_irq_uninstall, dev);
> + if (ret)
> + devm_drm_dev_irq_uninstall(dev);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(devm_drm_irq_install);
> +
Shouldn't we tie the IRQ to the drm device (so with drmm_add_action)
instead of tying it to the underlying device?
>>>
>>> If the HW device goes away, there won't be any more interrupts. So it's
>>> similar to devm_ functions for I/O memory. Why would you use the drmm_
>>> interface?
>>
>> drm_irq_install/uninstall do more that just calling request_irq and
>> free_irq though, they will also run (among other things) the irq-related
>> hooks in the drm driver (irq_preinstall, irq_postinstall irq_uninstall)
>> and wake anything waiting for a vblank to occur, so we need the DRM
>> device and driver to still be around when we run drm_irq_uninstall.
>> That's why (I assume) you have to pass the drm_device as an argument and
>> not simply the device.
>
> drm_device is guaranteed to outlive devm_, plus the hooks are meant to
> shut down hw. hw isn't around anymore when we do drmm_ cleanup, at least
> not in full generality.
>
>> This probably works in most case since you would allocate the drm_device
>> with devm_drm_dev_alloc, and then run drm_irq_install, so in the undoing
>> phase you would have first drm_irq_uninstall to run, and everything is
>> fine.
>>
>> However, if one doesn't use devm_drm_dev_alloc but would use
>> devm_drm_irq_install, you would have first remove being called that
>> would free the drm device, and then drm_irq_uninstall which will use a
>> free'd pointer.
>
> Don't do that, it's broken :-)
Umm, I just saw that hibmc doesn't use devm_drm_dev_alloc. So maybe we
have to convert it first before using the managed irq function. OTOH
converting it is a good idea in any case, so why not. :)
Best regards
Thomas
>
>> So yeah, even though the interrupt line itself is tied to the device,
>> all the logic we have around the interrupt that is dealt with in
>> drm_irq_install is really tied to the drm_device. And since we tie the
>> life of drm_device to its underlying device already (either implicitly
>> through devm_drm_dev_alloc, or explictly through manual allocation in
>> probe and free in remove) we can't end up in a situation where the
>> drm_device outlives its device.
>
> Most drivers get their drm_device lifetime completely wrong. That's why I
> typed drmm_ stuff. So this isn't a surprise at all, but it might motiveate
> a bunch more people to fix this up correctly.
>
> Also, these drm_irq functions are 100% optional helpers (should maybe
> rename them to make this clearer) for modern drivers. They're only built
> in for DRIVER_LEGACY, because hysterical raisins.
> -Daniel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] amdgpu/test: Enable deadlock test for CZ family (gfx8)
From: Rajib Mahapatra
It is enabling the test for Stoney ASIC.
Signed-off-by: Rajib Mahapatra
---
tests/amdgpu/deadlock_tests.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
index 248cc339..c89e51d9 100644
--- a/tests/amdgpu/deadlock_tests.c
+++ b/tests/amdgpu/deadlock_tests.c
@@ -136,7 +136,8 @@ CU_BOOL suite_deadlock_tests_enable(void)
*/
if (device_handle->info.family_id != AMDGPU_FAMILY_VI &&
device_handle->info.family_id != AMDGPU_FAMILY_AI &&
- device_handle->info.family_id != AMDGPU_FAMILY_CI) {
+ device_handle->info.family_id != AMDGPU_FAMILY_CI &&
+ device_handle->info.family_id != AMDGPU_FAMILY_CZ) {
printf("\n\nGPU reset is not enabled for the ASIC, deadlock
suite disabled\n");
enable = CU_FALSE;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/panfrost: Move the GPU reset bits outside the timeout handler
On Tue, Nov 03, 2020 at 12:03:26PM +0100, Boris Brezillon wrote:
> On Tue, 3 Nov 2020 11:25:40 +0100
> Daniel Vetter wrote:
>
> > On Tue, Nov 03, 2020 at 09:13:47AM +0100, Boris Brezillon wrote:
> > > We've fixed many races in panfrost_job_timedout() but some remain.
> > > Instead of trying to fix it again, let's simplify the logic and move
> > > the reset bits to a separate work scheduled when one of the queue
> > > reports a timeout.
> > >
> > > v3:
> > > - Replace the atomic_cmpxchg() by an atomic_xchg() (Robin Murphy)
> > > - Add Steven's R-b
> > >
> > > v2:
> > > - Use atomic_cmpxchg() to conditionally schedule the reset work (Steven
> > > Price)
> > >
> > > Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling")
> > > Cc:
> > > Signed-off-by: Boris Brezillon
> > > Reviewed-by: Steven Price
> >
> > Sprinkling the dma_fence annotations over this would be really nice ...
>
> You mean something like that?
That's just the irq annotations, i.e. the one that's already guaranteed by
the irq vs. locks checks. So this does nothing.
What I mean is annotating your new reset work (it's part of the critical
path to complete batches, since it's holding up other batches that are
stuck in the scheduler still), and the drm/scheduler annotations I've
floated a while ago. The drm/scheduler annotations are stuck somewhat for
lack of feedback from any of the driver teams using it though :-/
The thing is pulling something out into a worker of it's own generally
doesn't fix any deadlocks, it just hides them from lockdep. So it would be
good to make sure lockdep can see through your maze again.
-Daniel
>
> --->8---
> From 4f90ee2972eaec0332833ff6f9ea078acbfa899a Mon Sep 17 00:00:00 2001
> From: Boris Brezillon
> Date: Tue, 3 Nov 2020 12:01:09 +0100
> Subject: [PATCH] drm/panfrost: Annotate dma_fence signalling
>
> Annotate dma_fence signalling to help lockdep catch deadlocks.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_job.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> b/drivers/gpu/drm/panfrost/panfrost_job.c
> index 569a099dc10e..046cb3677332 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -482,7 +482,9 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
> *data)
>
> if (status & JOB_INT_MASK_DONE(j)) {
> struct panfrost_job *job;
> + bool cookie;
>
> + cookie = dma_fence_begin_signalling();
> spin_lock(>js->job_lock);
> job = pfdev->jobs[j];
> /* Only NULL if job timeout occurred */
> @@ -496,6 +498,7 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
> *data)
> pm_runtime_put_autosuspend(pfdev->dev);
> }
> spin_unlock(>js->job_lock);
> + dma_fence_end_signalling(cookie);
> }
>
> status &= ~mask;
--
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 v2 0/3] drm: Store USB device in struct drm_device
Hi, On 11/3/20 11:36 AM, Thomas Zimmermann wrote: > The drivers gm12u320 and udl operate on USB devices. They leave the PCI > device in struct drm_device empty and store the USB device in their own > driver structure. It's expected that DRM core and helpers only touch the > PCI-device field for actual PCI devices. > > Fix this special case by upcasting struct drm_device.dev to the USB > device. The drivers' udev variables are being removed. > > v2: > * upcast USB device from struct drm_device.dev (Daniel) > > Thomas Zimmermann (3): > drm: Add USB helpers > drm/tiny/gm12u320: Retrieve USB device from struct drm_device.dev > drm/udl: Retrieve USB device from struct drm_device.dev Thanks. The entire series looks good to me: Reviewed-by: Hans de Goede Note you may want to wait with pushing this to drm-misc until the first patch gets at least one other review. Or at least give others some time to possibly react :) Regards, Hans > > Documentation/gpu/drm-internals.rst | 5 +++ > drivers/gpu/drm/tiny/gm12u320.c | 52 + > drivers/gpu/drm/udl/udl_connector.c | 9 ++--- > drivers/gpu/drm/udl/udl_drv.c | 3 -- > drivers/gpu/drm/udl/udl_drv.h | 1 - > drivers/gpu/drm/udl/udl_main.c | 25 -- > include/drm/drm_usb_helper.h| 25 ++ > 7 files changed, 73 insertions(+), 47 deletions(-) > create mode 100644 include/drm/drm_usb_helper.h > > -- > 2.29.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/panfrost: Move the GPU reset bits outside the timeout handler
On Tue, 3 Nov 2020 11:25:40 +0100
Daniel Vetter wrote:
> On Tue, Nov 03, 2020 at 09:13:47AM +0100, Boris Brezillon wrote:
> > We've fixed many races in panfrost_job_timedout() but some remain.
> > Instead of trying to fix it again, let's simplify the logic and move
> > the reset bits to a separate work scheduled when one of the queue
> > reports a timeout.
> >
> > v3:
> > - Replace the atomic_cmpxchg() by an atomic_xchg() (Robin Murphy)
> > - Add Steven's R-b
> >
> > v2:
> > - Use atomic_cmpxchg() to conditionally schedule the reset work (Steven
> > Price)
> >
> > Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling")
> > Cc:
> > Signed-off-by: Boris Brezillon
> > Reviewed-by: Steven Price
>
> Sprinkling the dma_fence annotations over this would be really nice ...
You mean something like that?
--->8---
>From 4f90ee2972eaec0332833ff6f9ea078acbfa899a Mon Sep 17 00:00:00 2001
From: Boris Brezillon
Date: Tue, 3 Nov 2020 12:01:09 +0100
Subject: [PATCH] drm/panfrost: Annotate dma_fence signalling
Annotate dma_fence signalling to help lockdep catch deadlocks.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_job.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 569a099dc10e..046cb3677332 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -482,7 +482,9 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
*data)
if (status & JOB_INT_MASK_DONE(j)) {
struct panfrost_job *job;
+ bool cookie;
+ cookie = dma_fence_begin_signalling();
spin_lock(>js->job_lock);
job = pfdev->jobs[j];
/* Only NULL if job timeout occurred */
@@ -496,6 +498,7 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
*data)
pm_runtime_put_autosuspend(pfdev->dev);
}
spin_unlock(>js->job_lock);
+ dma_fence_end_signalling(cookie);
}
status &= ~mask;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/udl: Retrieve USB device from struct drm_device.dev
On Tue, Nov 03, 2020 at 11:36:56AM +0100, Thomas Zimmermann wrote:
> Drop the driver's udev field in favor of struct drm_device.dev. No
> functional changes made.
>
> v2:
> * upcast dev with drm_dev_get_usb_device()
Again, witht that helper either moved to udl_drv.h or to usb code:
Acked-by: Daniel Vetter
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/udl/udl_connector.c | 9 +
> drivers/gpu/drm/udl/udl_drv.c | 3 ---
> drivers/gpu/drm/udl/udl_drv.h | 1 -
> drivers/gpu/drm/udl/udl_main.c | 25 ++---
> 4 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_connector.c
> b/drivers/gpu/drm/udl/udl_connector.c
> index cdc1c42e1669..487e03e1727c 100644
> --- a/drivers/gpu/drm/udl/udl_connector.c
> +++ b/drivers/gpu/drm/udl/udl_connector.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> #include "udl_connector.h"
> #include "udl_drv.h"
> @@ -20,6 +21,7 @@ static int udl_get_edid_block(void *data, u8 *buf, unsigned
> int block,
> int ret, i;
> u8 *read_buff;
> struct udl_device *udl = data;
> + struct usb_device *udev = drm_dev_get_usb_device(>drm);
>
> read_buff = kmalloc(2, GFP_KERNEL);
> if (!read_buff)
> @@ -27,10 +29,9 @@ static int udl_get_edid_block(void *data, u8 *buf,
> unsigned int block,
>
> for (i = 0; i < len; i++) {
> int bval = (i + block * EDID_LENGTH) << 8;
> - ret = usb_control_msg(udl->udev,
> - usb_rcvctrlpipe(udl->udev, 0),
> - (0x02), (0x80 | (0x02 << 5)), bval,
> - 0xA1, read_buff, 2, HZ);
> + ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
> + 0x02, (0x80 | (0x02 << 5)), bval,
> + 0xA1, read_buff, 2, HZ);
> if (ret < 1) {
> DRM_ERROR("Read EDID byte %d failed err %x\n", i, ret);
> kfree(read_buff);
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 96d4317a2c1b..993469d152da 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -53,7 +53,6 @@ static struct drm_driver driver = {
>
> static struct udl_device *udl_driver_create(struct usb_interface *interface)
> {
> - struct usb_device *udev = interface_to_usbdev(interface);
> struct udl_device *udl;
> int r;
>
> @@ -62,8 +61,6 @@ static struct udl_device *udl_driver_create(struct
> usb_interface *interface)
> if (IS_ERR(udl))
> return udl;
>
> - udl->udev = udev;
> -
> r = udl_init(udl);
> if (r)
> return ERR_PTR(r);
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index b1461f30780b..889bfa21deb0 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -50,7 +50,6 @@ struct urb_list {
> struct udl_device {
> struct drm_device drm;
> struct device *dev;
> - struct usb_device *udev;
>
> struct drm_simple_display_pipe display_pipe;
>
> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
> index f5d27f2a5654..208505a39ace 100644
> --- a/drivers/gpu/drm/udl/udl_main.c
> +++ b/drivers/gpu/drm/udl/udl_main.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> #include "udl_drv.h"
>
> @@ -26,10 +27,10 @@
> #define GET_URB_TIMEOUT HZ
> #define FREE_URB_TIMEOUT (HZ*2)
>
> -static int udl_parse_vendor_descriptor(struct drm_device *dev,
> -struct usb_device *usbdev)
> +static int udl_parse_vendor_descriptor(struct udl_device *udl)
> {
> - struct udl_device *udl = to_udl(dev);
> + struct drm_device *dev = >drm;
> + struct usb_device *udev = drm_dev_get_usb_device(dev);
> char *desc;
> char *buf;
> char *desc_end;
> @@ -41,7 +42,7 @@ static int udl_parse_vendor_descriptor(struct drm_device
> *dev,
> return false;
> desc = buf;
>
> - total_len = usb_get_descriptor(usbdev, 0x5f, /* vendor specific */
> + total_len = usb_get_descriptor(udev, 0x5f, /* vendor specific */
> 0, desc, MAX_VENDOR_DESCRIPTOR_SIZE);
> if (total_len > 5) {
> DRM_INFO("vendor descriptor length:%x data:%11ph\n",
> @@ -98,19 +99,20 @@ static int udl_parse_vendor_descriptor(struct drm_device
> *dev,
> */
> static int udl_select_std_channel(struct udl_device *udl)
> {
> - int ret;
> static const u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
>0x1C, 0x88, 0x5E, 0x15,
>0x60, 0xFE, 0xC6, 0x97,
>0x16, 0x3D, 0x47, 0xF2};
> +
> void *sendbuf;
> + int
