Re: [PATCH] drm/mediatek: cleanup coding style in mediatek a bit
Hi Bernard,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pza/reset/next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip linus/master
v5.7-rc3 next-20200430]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Bernard-Zhao/drm-mediatek-cleanup-coding-style-in-mediatek-a-bit/20200428-055750
base: https://git.pengutronix.de/git/pza/linux reset/next
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/mediatek/mtk_hdmi.c: In function
'mtk_hdmi_hw_send_info_frame':
>> drivers/gpu/drm/mediatek/mtk_hdmi.c:1807: error: unterminated argument list
>> invoking macro "dev_err"
1807 | MODULE_LICENSE("GPL v2");
|
>> drivers/gpu/drm/mediatek/mtk_hdmi.c:316:3: error: 'dev_err' undeclared
>> (first use in this function); did you mean '_dev_err'?
316 | dev_err(hdmi->dev, "Wrong frame len: %d\n", frame_len;
| ^~~
| _dev_err
drivers/gpu/drm/mediatek/mtk_hdmi.c:316:3: note: each undeclared identifier
is reported only once for each function it appears in
>> drivers/gpu/drm/mediatek/mtk_hdmi.c:316:10: error: expected ';' at end of
>> input
316 | dev_err(hdmi->dev, "Wrong frame len: %d\n", frame_len;
| ^
| ;
..
1807 | MODULE_LICENSE("GPL v2");
|
>> drivers/gpu/drm/mediatek/mtk_hdmi.c:316:3: error: expected declaration or
>> statement at end of input
316 | dev_err(hdmi->dev, "Wrong frame len: %d\n", frame_len;
| ^~~
>> drivers/gpu/drm/mediatek/mtk_hdmi.c:316:3: error: expected declaration or
>> statement at end of input
drivers/gpu/drm/mediatek/mtk_hdmi.c:308:6: warning: unused variable
'ctrl_frame_en' [-Wunused-variable]
308 | int ctrl_frame_en = 0;
| ^
drivers/gpu/drm/mediatek/mtk_hdmi.c:302:6: warning: unused variable 'i'
[-Wunused-variable]
302 | int i;
| ^
drivers/gpu/drm/mediatek/mtk_hdmi.c:301:6: warning: unused variable
'ctrl_reg' [-Wunused-variable]
301 | u32 ctrl_reg = GRL_CTRL;
| ^~~~
At top level:
drivers/gpu/drm/mediatek/mtk_hdmi.c:298:13: warning:
'mtk_hdmi_hw_send_info_frame' defined but not used [-Wunused-function]
298 | static void mtk_hdmi_hw_send_info_frame(struct mtk_hdmi *hdmi, u8
*buffer,
| ^~~
drivers/gpu/drm/mediatek/mtk_hdmi.c:293:13: warning:
'mtk_hdmi_hw_enable_dvi_mode' defined but not used [-Wunused-function]
293 | static void mtk_hdmi_hw_enable_dvi_mode(struct mtk_hdmi *hdmi, bool
enable)
| ^~~
drivers/gpu/drm/mediatek/mtk_hdmi.c:288:13: warning:
'mtk_hdmi_hw_write_int_mask' defined but not used [-Wunused-function]
288 | static void mtk_hdmi_hw_write_int_mask(struct mtk_hdmi *hdmi, u32
int_mask)
| ^~
drivers/gpu/drm/mediatek/mtk_hdmi.c:282:13: warning:
'mtk_hdmi_hw_enable_notice' defined but not used [-Wunused-function]
282 | static void mtk_hdmi_hw_enable_notice(struct mtk_hdmi *hdmi, bool
enable_notice)
| ^
drivers/gpu/drm/mediatek/mtk_hdmi.c:271:13: warning: 'mtk_hdmi_hw_reset'
defined but not used [-Wunused-function]
271 | static void mtk_hdmi_hw_reset(struct mtk_hdmi *hdmi)
| ^
drivers/gpu/drm/mediatek/mtk_hdmi.c:266:13: warning:
'mtk_hdmi_hw_aud_unmute' defined but not used [-Wunused-function]
266 | static void mtk_hdmi_hw_aud_unmute(struct mtk_hdmi *hdmi)
| ^~
drivers/gpu/drm/mediatek/mtk_hdmi.c:261:13: warning: 'mtk_hdmi_hw_aud_mute'
defined but not used [-Wunused-function]
261 | static void mtk_hdmi_hw_aud_mute(struct mtk_hdmi *hdmi)
| ^~~~
drivers/gpu/drm/mediatek/mtk_hdmi.c:255:13: warning:
'mtk_hdmi_hw_1p4_version_enable' defined but not used [-Wunused-function]
255 | static void mtk_hdmi_hw_1p4_version_enable(struct mtk_hdmi *hdmi,
bool enable)
| ^~~
linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
include/linux/dma-buf.h
between commit:
6f49c2515e22 ("dma-buf: fix documentation build warnings")
from the drm-misc-fixes tree and commit:
09606b5446c2 ("dma-buf: add peer2peer flag")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/dma-buf.h
index 57bcef6f988a,82e0a4a64601..
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@@ -333,8 -334,16 +333,16 @@@ struct dma_buf
* Attachment operations implemented by the importer.
*/
struct dma_buf_attach_ops {
+ /**
+* @allow_peer2peer:
+*
+* If this is set to true the importer must be able to handle peer
+* resources without struct pages.
+*/
+ bool allow_peer2peer;
+
/**
- * @move_notify
+ * @move_notify: [optional] notification that the DMA-buf is moving
*
* If this callback is provided the framework can avoid pinning the
* backing store while mappings exists.
pgpoIV1438DfZ.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH net-next] dpaa2-eth: fix error return code in setup_dpni()
From: Wei Yongjun Date: Mon, 27 Apr 2020 10:43:22 + > Fix to return negative error code -ENOMEM from the error handling > case instead of 0, as done elsewhere in this function. > > Signed-off-by: Wei Yongjun Applied, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH net-next] net: lpc-enet: fix error return code in lpc_mii_init()
From: Wei Yongjun
Date: Mon, 27 Apr 2020 12:15:07 +
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
> Signed-off-by: Wei Yongjun
Applied.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.7-rc4
Hi Linus, Regular scheduled fixes pull for graphics. Nothing to extreme bunch of amdgpu fixes, i915 and qxl fixes, along with some misc ones. All seems to be progressing normally. Dave. drm-fixes-2020-05-01: drm fixes for 5.7-rc4 core: - EDID off by one DTD fix - DP mst write return code fix dma-buf: - fix SET_NAME ioctl uapi - doc fixes amdgpu: - Fix a green screen on resume issue - PM fixes for SR-IOV - SDMA fix for navi - Renoir display fixes - Cursor and pageflip stuttering fixes - Misc additional display fixes - (uapi) Add additional DCC tiling flags for navi1x i915: - Fix selftest refcnt leak (Xiyu) - Fix gem vma lock (Chris) - Fix gt's i915_request.timeline acquire by checking if cacheline is valid (Chris) - Fix IRQ postinistall fault masks (Matt) qxl: - use after gree fix - fix lost kunmap - release leak fix virtio: - context destruction fix The following changes since commit 6a8b55ed4056ea5559ebe4f6a4b247f627870d4c: Linux 5.7-rc3 (2020-04-26 13:51:02 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-05-01 for you to fetch changes up to e3dcd86b3b4c045a4db17c02340138a4c514fe20: Merge tag 'amd-drm-fixes-5.7-2020-04-29' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-05-01 11:19:55 +1000) drm fixes for 5.7-rc4 core: - EDID off by one DTD fix - DP mst write return code fix dma-buf: - fix SET_NAME ioctl uapi - doc fixes amdgpu: - Fix a green screen on resume issue - PM fixes for SR-IOV SDMA fix for navi - Renoir display fixes - Cursor and pageflip stuttering fixes - Misc additional display fixes - (uapi) Add additional DCC tiling flags for navi1x i915: - Fix selftest refcnt leak (Xiyu) - Fix gem vma lock (Chris) - Fix gt's i915_request.timeline acquire by checking if cacheline is valid (Chris) - Fix IRQ postinistall fault masks (Matt) qxl: - use after gree fix - fix lost kunmap - release leak fix virtio: - context destruction fix Aric Cyr (1): drm/amd/display: Use cursor locking to prevent flip delays Aurabindo Pillai (1): drm/amd/display: DispalyPort: Write OUI only if panel supports it Chris Wilson (2): drm/i915/gem: Hold obj->vma.lock over for_each_ggtt_vma() drm/i915/gt: Check cacheline is valid before acquiring Daniel Vetter (1): dma-buf: Fix SET_NAME ioctl uapi Dave Airlie (3): Merge tag 'drm-misc-fixes-2020-04-30' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2020-04-30' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'amd-drm-fixes-5.7-2020-04-29' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Dmytro Laktyushkin (2): drm/amd/display: check if REFCLK_CNTL register is present drm/amd/display: fix rn soc bb update Gurchetan Singh (1): drm/virtio: only destroy created contexts Lyude Paul (1): drm/dp_mst: Fix drm_dp_send_dpcd_write() return code Marek Olšák (3): drm/amdgpu: add tiling flags from Mesa drm/amdgpu: invalidate L2 before SDMA IBs (v2) drm/amdgpu: bump version for invalidate L2 before SDMA IBs Matt Roper (1): drm/i915: Use proper fault mask in interrupt postinstall too Nicholas Kazlauskas (1): drm/amd/display: Defer cursor update around VUPDATE for all ASIC Randy Dunlap (1): dma-buf: fix documentation build warnings Rodrigo Siqueira (1): drm/amd/display: Fix green screen issue after suspend Sung Lee (1): drm/amd/display: Update downspread percent to match spreadsheet for DCN2.1 Tiecheng Zhou (2): Revert "drm/amd/powerplay: avoid using pm_en before it is initialized" drm/amd/powerplay: avoid using pm_en before it is initialized revised Vasily Averin (4): drm/qxl: qxl_release leak in qxl_draw_dirty_fb() drm/qxl: qxl_release leak in qxl_hw_surface_alloc() drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper() drm/qxl: qxl_release use after free Ville Syrjälä (1): drm/edid: Fix off-by-one in DispID DTD pixel clock Xiaodong Yan (1): drm/amd/display: blank dp stream before re-train the link Xiyu Yang (1): drm/i915/selftests: Fix i915_address_space refcnt leak drivers/dma-buf/dma-buf.c | 7 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 +- drivers/gpu/drm/amd/amdgpu/navi10_sdma_pkt_open.h | 16 + drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 14 +++- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 27 drivers/gpu/drm/amd/display/dc/core/dc_stream.c| 40 ++- .../amd/display/dc/dce110/dce110_hw_sequencer.c| 1 + .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 10 +++ .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.h | 1 +
Re: [PATCH 1/1] drm/dp_mst: Kill the second sideband tx slot, save the world
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper
(v0.6)").
The bot has tested the following trees: v5.6.7, v5.4.35, v4.19.118, v4.14.177,
v4.9.220, v4.4.220.
v5.6.7: Failed to apply! Possible dependencies:
1cfff5f01563 ("drm/dp_mst: Convert
drm_dp_mst_topology_mgr.is_waiting_for_dwn_reply to bitfield")
v5.4.35: Failed to apply! Possible dependencies:
14692a3637d4 ("drm/dp_mst: Add probe_lock")
2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests")
37dfdc55ffeb ("drm/dp_mst: Cleanup drm_dp_send_link_address() a bit")
50094b5dcd32 ("drm/dp_mst: Destroy topology_mgr mutexes")
5950f0b797fc ("drm/dp_mst: Move link address dumping into a function")
5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time")
60f9ae9d0d3d ("drm/dp_mst: Remove huge conditional in
drm_dp_mst_handle_up_req()")
7cb12d48314e ("drm/dp_mst: Destroy MSTBs asynchronously")
7cbce45d6243 ("drm/dp_mst: Move test_calc_pbn_mode() into an actual
selftest")
8b1e589d138c ("drm/dp_mst: Refactor drm_dp_mst_handle_down_rep()")
9408cc94eb04 ("drm/dp_mst: Handle UP requests asynchronously")
a29d881875fc ("drm/dp_mst: Refactor drm_dp_mst_handle_up_req()")
caf81ec6cd72 ("drm: Destroy the correct mutex name in
drm_dp_mst_topology_mgr_destroy")
e2839ff692c6 ("drm/dp_mst: Rename drm_dp_add_port and drm_dp_update_port")
v4.19.118: Failed to apply! Possible dependencies:
16bff572cc66 ("drm/dp-mst-helper: Remove hotplug callback")
19b85cfabf5c ("drm/bochs: move remaining fb bits to kms")
2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests")
2f69deb1d9a1 ("drm/arcpgu: prepare for drmP.h removal from
drm_modeset_helper.h")
48b442238250 ("drm/bochs: fix DRM_FORMAT_* handling for big endian
machines.")
562836a269e3 ("drm/dp_mst: Enable registration of AUX devices for MST
ports")
580fc13f3ee4 ("drm/dp: drmP.h include removal")
5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time")
6579c39594ae ("drm/bochs: atomic: switch planes to atomic, wire up
helpers.")
6abb49402a79 ("drm/bridge: cdns: prepare for drmP.h removal from
drm_modeset_helper.h")
6c76c0eb031f ("drm/bridge: ti-sn65dsi86: Fixup register names")
7780eb9ce80f ("bochs: convert to drm_dev_register")
86351de023dd ("drm/bochs: support changing byteorder at mode set time")
a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
b814ec6d4535 ("drm/bridge: ti-sn65dsi86: Implement AUX channel")
df2052cc9221 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown")
f38b7cca6d0e ("drm/bridge: tc358764: Add DSI to LVDS bridge driver")
fcd70cd36b9b ("drm: Split out drm_probe_helper.h")
fe1f664a3609 ("drm/arc: do not rely on drmP.h from drm_gem_cma_helper.h")
v4.14.177: Failed to apply! Possible dependencies:
1b0c0f9dc5ca ("drm/amdgpu: move userptr BOs to CPU domain during CS v2")
1ed3d2567c80 ("drm/amdgpu: keep the MMU lock until the update ends v4")
2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests")
3fe89771cb0a ("drm/amdgpu: stop reserving the BO in the MMU callback v3")
4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
562836a269e3 ("drm/dp_mst: Enable registration of AUX devices for MST
ports")
580fc13f3ee4 ("drm/dp: drmP.h include removal")
5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time")
60de1c1740f3 ("drm/amdgpu: use a rw_semaphore for MMU notifiers")
9a18999640fa ("drm/amdgpu: move MMU notifier related defines to
amdgpu_mn.h")
9cca0b8e5df0 ("drm/amdgpu: move amdgpu_cs_sysvm_access_required into
find_mapping")
a216ab09955d ("drm/amdgpu: fix userptr put_page handling")
b72cf4fca2bb ("drm/amdgpu: move taking mmap_sem into get_user_pages v2")
ca666a3c298f ("drm/amdgpu: stop using BO status for user pages")
fcd70cd36b9b ("drm: Split out drm_probe_helper.h")
v4.9.220: Failed to apply! Possible dependencies:
178e32c224d2 ("drm/atomic: Remove pointless private object NULL state
check")
1cec20f0ea0e ("dma-buf: Restart reservation_object_wait_timeout_rcu() after
writes")
2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests")
3941dae15ed9 ("drm_dp_aux_dev: switch to read_iter/write_iter")
3f3353b7e121 ("drm/dp: Introduce MST topology state to track available link
bandwidth")
562836a269e3 ("drm/dp_mst: Enable registration of AUX devices for MST
ports")
580fc13f3ee4 ("drm/dp: drmP.h include removal")
5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time")
6806cdf9aa1c ("drm/kms-helpers: Use recommened kerneldoc for struct member
refs")
78010cd9736e ("dma-buf/fence: add an lockdep_assert_held()")
9498c19b3f53 ("drm: Move tile group code into drm_connector.c")
9a83a71ac0d5 ("drm/fences: add DOC: for
Re: [PATCH v6 02/16] drm/i915: Clear the repeater bit on HDCP disable
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.6.7, v5.4.35, v4.19.118.
v5.6.7: Build failed! Errors:
drivers/gpu/drm/i915/display/intel_hdcp.c:780:2: error: implicit
declaration of function âintel_de_writeâ; did you mean
âintel_sbi_writeâ? [-Werror=implicit-function-declaration]
drivers/gpu/drm/i915/display/intel_hdcp.c:781:10: error: implicit
declaration of function âintel_de_readâ; did you mean âintel_sbi_readâ?
[-Werror=implicit-function-declaration]
v5.4.35: Failed to apply! Possible dependencies:
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
v4.19.118: Failed to apply! Possible dependencies:
0e39037b3165 ("drm/i915: Cache the error string")
16e4dd0342a8 ("drm/i915: Markup paired operations on wakerefs")
39e2f501c1b4 ("drm/i915: Split struct intel_context definition to its own
header")
408bd9178666 ("drm/i915: extract intel_hdcp.h from intel_drv.h")
52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context
interrupt tracking")
538ef96b9dae ("drm/i915/gem: Track the rpm wakerefs")
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
6b048706f407 ("drm/i915: Forcibly flush unwanted requests in drop-caches")
87f1ef225242 ("drm/i915: Record the sseu configuration per-context &
engine")
95fd94a645f7 ("drm/i915: avoid rebuilding i915_gpu_error.o on version
string updates")
c0a6aa7ec2c3 ("drm/i915: Show actual alongside requested frequency in
debugfs/i915_rps_boost_info")
c2400ec3b6d1 ("drm/i915: add Makefile magic for testing headers are
self-contained")
c44301fce614 ("drm/i915: Allow control of PSR at runtime through debugfs,
v6")
e0516e83640e ("drm/i915: Move sandybride pcode access to intel_sideband.c")
e1ef734eaec5 ("drm/i915: make intel_frontbuffer.h self-contained")
e6154e4cb8b0 ("drm/i915: Skip the ERR_PTR error state")
eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex")
fb6f0b64e455 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and
error capture")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 01/16] drm/i915: Fix sha_text population code
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.6.7, v5.4.35, v4.19.118.
v5.6.7: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging
macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
v5.4.35: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging
macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
v4.19.118: Failed to apply! Possible dependencies:
04707f971636 ("drm/i915: Initialize HDCP2.2")
09d56393c1d8 ("drm/i915: hdcp1.4 CP_IRQ handling and SW encryption
tracking")
2f80d7bd8d93 ("drm/i915: drop all drmP.h includes")
33b7f3ee6e00 ("drm/i915: Add CRTC output format YCBCR 4:2:0")
340a44bef234 ("drm/i915/icl: program MG_DP_MODE")
342ac601df64 ("drm/i915: hdcp_check_link only on CP_IRQ")
47658556da85 ("drm/i915/dp: Do not grab crtc modeset lock in
intel_dp_detect()")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
668b6c176c33 ("drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON")
7b610f1fbed2 ("drm/i915/dp: Add DSC params and DSC config to
intel_crtc_state")
9055aac76589 ("drm/i915: MEI interface implementation")
9844bc87cb7a ("drm/i915/dp: Fix duplication of DEVICE_SERVICE_IRQ handling")
bdc93fe0eb82 ("drm/i915/debugfs: hdcp capability of a sink")
cbfa8ac835cb ("drm/i915/dp: Kill intel_dp->detect_done flag")
d3dacc70797b ("drm/i915: wrapping all hdcp var into intel_hdcp")
d5acd97f5571 ("drm/i915/dp: Use a local variable for intel_encoder *")
d78aa650670d ("drm: Add drm/drm_util.h header file")
de25eb7f3075 ("drm/i915: introduce dp_to_i915() helper")
f106d1005ac7 ("drm/i915: Pullout the bksv read and validation")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/29] mm: remove the pgprot argument to __vmalloc
>> On Tue, Apr 14, 2020 at 03:13:40PM +0200, Christoph Hellwig wrote: >> > The pgprot argument to __vmalloc is always PROT_KERNEL now, so remove >> > it. Greetings; I recently noticed this change via the linux-next tree. It may not be possible to edit at this late date, but the change description refers to PROT_KERNEL, which is a symbol which does not appear to exist; perhaps PAGE_KERNEL was meant? The mismatch caused me and a couple other folks some confusion briefly until we decided it was supposed to be PAGE_KERNEL; if it's not too late, editing the description to clarify so would be nice. Many thanks. John Dorminy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/29] mm: remove the pgprot argument to __vmalloc
Greetings;
I recently noticed this change via the linux-next tree.
It may not be possible to edit at this late date, but the change
description refers to PROT_KERNEL, which is a symbol which does not appear
to exist; perhaps PAGE_KERNEL was meant? The mismatch caused me and a
couple other folks some confusion briefly until we decided it was supposed
to be PAGE_KERNEL; if it's not too late, editing the description to clarify
so would be nice.
Many thanks.
John Dorminy
On Tue, Apr 14, 2020 at 11:15 AM Wei Liu wrote:
> On Tue, Apr 14, 2020 at 03:13:40PM +0200, Christoph Hellwig wrote:
> > The pgprot argument to __vmalloc is always PROT_KERNEL now, so remove
> > it.
> >
> > Signed-off-by: Christoph Hellwig
> > Reviewed-by: Michael Kelley [hyperv]
> > Acked-by: Gao Xiang [erofs]
> > Acked-by: Peter Zijlstra (Intel)
> > ---
> > arch/x86/hyperv/hv_init.c | 3 +--
> [...]
> >
> > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> > index 5a4b363ba67b..a3d689dfc745 100644
> > --- a/arch/x86/hyperv/hv_init.c
> > +++ b/arch/x86/hyperv/hv_init.c
> > @@ -95,8 +95,7 @@ static int hv_cpu_init(unsigned int cpu)
> >* not be stopped in the case of CPU offlining and the VM will
> hang.
> >*/
> > if (!*hvp) {
> > - *hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL | __GFP_ZERO,
> > - PAGE_KERNEL);
> > + *hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL | __GFP_ZERO);
> > }
>
> Acked-by: Wei Liu
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, amdkfd drm-next-5.8
Hi Dave, Daniel, More new stuff for 5.8. The following changes since commit e748f07d00c1c4a9106acafac52df7ea4ecf6264: drm/amdgpu: retire legacy vega10 sos version check (2020-04-23 15:41:06 -0400) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.8-2020-04-30 for you to fetch changes up to b8020b0304c8f44e5e29f0b1a04d31e0bf68d26a: drm/amdkfd: Enable over-subscription with >1 GWS queue (2020-04-28 16:20:30 -0400) amd-drm-next-5.8-2020-04-30: amdgpu: - SR-IOV fixes - SDMA fix for Navi - VCN 2.5 DPG fixes - Display fixes - Display stuttering fixes for pageflip and cursor - Add support for handling encrypted GPU memory - Add UAPI for encrypted GPU memory - Rework IB pool handling amdkfd: - Expose asic revision in topology - Add UAPI for GWS (Global Wave Sync) resource management UAPI: - Add amdgpu UAPI for encrypted GPU memory Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4401 - Add amdkfd UAPI for GWS (Global Wave Sync) resource management Thunk usage of KFD ioctl: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/roc-2.8.0/src/queues.c#L840 ROCr usage of Thunk API: https://github.com/RadeonOpenCompute/ROCR-Runtime/blob/roc-3.1.0/src/core/runtime/amd_gpu_agent.cpp#L597 HCC code using ROCr API: https://github.com/RadeonOpenCompute/hcc/blob/98ee9f34945d3b5f572d7a4c15cbffa506487734/lib/hsa/mcwamp_hsa.cpp#L2161 HIP code using HCC API: https://github.com/ROCm-Developer-Tools/HIP/blob/cf8589b8c8a40ddcc55fa3a51e23390a49824130/src/hip_module.cpp#L567 Aaron Liu (5): drm/amdgpu: expand sdma copy_buffer interface with tmz parameter drm/amdgpu: expand amdgpu_copy_buffer interface with tmz parameter drm/amdgpu: enable TMZ bit in sdma copy pkt for sdma v4 drm/amdgpu: enable TMZ bit in sdma copy pkt for sdma v5 drm/amdgpu: enable TMZ bit in FRAME_CONTROL for gfx10 Alex Deucher (5): drm/amdgpu: add UAPI for creating encrypted buffers drm/amdgpu: define the TMZ bit for the PTE drm/amdgpu: set TMZ bits in PTEs for secure BO (v4) drm/amdgpu: move CS secure flag next the structs where it's used drm/amdgpu: check ring type for secure IBs Alex Sierra (1): drm/amdgpu: pass unlocked flag to params at amdgpu_vm_bo_update_mapping Anthony Koo (1): drm/amd/display: clean up some header paths Aric Cyr (4): drm/amd/display: 3.2.82 drm/amd/display: Use cursor locking to prevent flip delays drm/amd/display: 3.2.83 drm/amd/display: 3.2.83.1 Christian König (10): drm/amdgpu: also add the TMZ flag to GART drm/amdgpu: add TMZ handling to amdgpu_move_blit drm/amdgpu: stop evicting encrypted BOs to swap drm/amdgpu: cleanup amdgpu_ttm_copy_mem_to_mem and amdgpu_map_buffer v2 drm/amdgpu: add full TMZ support into amdgpu_ttm_map_buffer v2 drm/amdgpu: fix size calculation in amdgpu_ttm_copy_mem_to_mem drm/amdgpu: partial revert VM sync changes drm/amdgpu: cleanup IB pool handling a bit drm/amdgpu: rename direct to immediate for VM updates drm/amdgpu: add new unlocked flag for PTE updates Colin Ian King (3): drm/amd/display: remove redundant assignment to variable ret drm/amdgpu/gmc: Use consistent variable on unlocks amdgpu/dc: remove redundant assignment to variable 'option' Dmytro Laktyushkin (2): drm/amd/display: check if REFCLK_CNTL register is present drm/amd/display: fix rn soc bb update Evan Quan (2): drm/amdgpu: move kfd suspend after ip_suspend_phase1 drm/amdgpu: drop redundant cg/pg ungate on runpm enter Guchun Chen (2): drm/amdgpu: switch to SMN interface to operate RSMU index mode drm/amdgpu: decouple EccErrCnt query and clear operation Harry Wentland (1): drm/amd/display: Indicate use of TMZ buffers to DC Huang Rui (10): drm/amdgpu: add tmz feature parameter (v2) drm/amdgpu: add amdgpu_tmz data structure drm/amdgpu: add function to check tmz capability (v4) drm/amdgpu: add tmz bit in frame control packet drm/amdgpu: expand the emit tmz interface with trusted flag drm/amdgpu: expand the context control interface with trust flag drm/amdgpu: job is secure iff CS is secure (v5) drm/amdgpu: remove the alignment placeholder for secure buffer drm/amdgpu: fix the wrong logic checking when secure buffer is created (v3) drm/amdgpu: Fix per-IB secure flag GFX hang James Zhu (1): drm/amdgpu/vcn2.5: wait for tiles off after unpause Jason Yan (3): drm/amdgpu: remove conversion to bool in amdgpu_device.c drm/amd/display: remove conversion to bool in dcn20_mpc.c drm/amd/display: remove conversion to bool in dc_link_ddc.c Jonathan Kim (1): drm/amdgpu: sw pstate switch should only be for vega20
Re: [Nouveau] [PATCH] drm/nouveau/dispnv04: Remove dead code
Interesting. I do remember seeing some snow on NV5's overlay at high
resolutions. Wonder if it was because of this missing code...
On Thu, Apr 30, 2020 at 4:19 PM Souptick Joarder wrote:
>
> These are dead code since 3.10. If there is no plan to use
> it further, these can be removed forever.
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 28
> 1 file changed, 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index 1f08de4..ad0ef7d 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -269,31 +269,11 @@ static void nv_crtc_calc_state_ext(struct drm_crtc
> *crtc, struct drm_display_mod
> horizStart = horizTotal - 5;
> horizEnd = horizTotal - 2;
> horizBlankEnd = horizTotal + 4;
> -#if 0
> - if (dev->overlayAdaptor && drm->client.device.info.family >=
> NV_DEVICE_INFO_V0_CELSIUS)
> - /* This reportedly works around some video overlay
> bandwidth problems */
> - horizTotal += 2;
> -#endif
> }
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> vertTotal |= 1;
>
> -#if 0
> - ErrorF("horizDisplay: 0x%X \n", horizDisplay);
> - ErrorF("horizStart: 0x%X \n", horizStart);
> - ErrorF("horizEnd: 0x%X \n", horizEnd);
> - ErrorF("horizTotal: 0x%X \n", horizTotal);
> - ErrorF("horizBlankStart: 0x%X \n", horizBlankStart);
> - ErrorF("horizBlankEnd: 0x%X \n", horizBlankEnd);
> - ErrorF("vertDisplay: 0x%X \n", vertDisplay);
> - ErrorF("vertStart: 0x%X \n", vertStart);
> - ErrorF("vertEnd: 0x%X \n", vertEnd);
> - ErrorF("vertTotal: 0x%X \n", vertTotal);
> - ErrorF("vertBlankStart: 0x%X \n", vertBlankStart);
> - ErrorF("vertBlankEnd: 0x%X \n", vertBlankEnd);
> -#endif
> -
> /*
> * compute correct Hsync & Vsync polarity
> */
> @@ -492,14 +472,6 @@ static void nv_crtc_calc_state_ext(struct drm_crtc
> *crtc, struct drm_display_mod
> /* Except for rare conditions I2C is enabled on the primary crtc */
> if (nv_crtc->index == 0)
> regp->crtc_eng_ctrl |= NV_CRTC_FSEL_I2C;
> -#if 0
> - /* Set overlay to desired crtc. */
> - if (dev->overlayAdaptor) {
> - NVPortPrivPtr pPriv = GET_OVERLAY_PRIVATE(dev);
> - if (pPriv->overlayCRTC == nv_crtc->index)
> - regp->crtc_eng_ctrl |= NV_CRTC_FSEL_OVERLAY;
> - }
> -#endif
>
> /* ADDRESS_SPACE_PNVM is the same as setting HCUR_ASI */
> regp->cursor_cfg = NV_PCRTC_CURSOR_CONFIG_CUR_LINES_64 |
> --
> 1.9.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V1 04/10] arch/kunmap: Remove duplicate kunmap implementations
From: Ira Weiny
All architectures do exactly the same thing for kunmap(); remove all the
duplicate definitions and lift the call to the core.
This also has the benefit of changing kmap_unmap() on a number of
architectures to be an inline call rather than an actual function.
Signed-off-by: Ira Weiny
---
Changes from V0:
lift kunmap_high() declaration as well.
---
arch/arc/include/asm/highmem.h| 10 --
arch/arm/include/asm/highmem.h| 3 ---
arch/arm/mm/highmem.c | 9 -
arch/csky/include/asm/highmem.h | 3 ---
arch/csky/mm/highmem.c| 9 -
arch/microblaze/include/asm/highmem.h | 9 -
arch/mips/include/asm/highmem.h | 3 ---
arch/mips/mm/highmem.c| 9 -
arch/nds32/include/asm/highmem.h | 3 ---
arch/nds32/mm/highmem.c | 10 --
arch/powerpc/include/asm/highmem.h| 9 -
arch/sparc/include/asm/highmem.h | 10 --
arch/x86/include/asm/highmem.h| 4
arch/x86/mm/highmem_32.c | 9 -
arch/xtensa/include/asm/highmem.h | 10 --
include/linux/highmem.h | 9 +
16 files changed, 9 insertions(+), 110 deletions(-)
diff --git a/arch/arc/include/asm/highmem.h b/arch/arc/include/asm/highmem.h
index 96eb67c86961..8387a5596a91 100644
--- a/arch/arc/include/asm/highmem.h
+++ b/arch/arc/include/asm/highmem.h
@@ -32,7 +32,6 @@
extern void *kmap_atomic(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
-extern void kunmap_high(struct page *page);
extern void kmap_init(void);
@@ -41,15 +40,6 @@ static inline void flush_cache_kmaps(void)
flush_cache_all();
}
-static inline void kunmap(struct page *page)
-{
- might_sleep();
- if (!PageHighMem(page))
- return;
- kunmap_high(page);
-}
-
-
#endif
#endif
diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
index c917522541de..736f65283e7b 100644
--- a/arch/arm/include/asm/highmem.h
+++ b/arch/arm/include/asm/highmem.h
@@ -20,8 +20,6 @@
extern pte_t *pkmap_page_table;
-extern void kunmap_high(struct page *page);
-
/*
* The reason for kmap_high_get() is to ensure that the currently kmap'd
* page usage count does not decrease to zero while we're using its
@@ -62,7 +60,6 @@ static inline void *kmap_high_get(struct page *page)
* when CONFIG_HIGHMEM is not set.
*/
#ifdef CONFIG_HIGHMEM
-extern void kunmap(struct page *page);
extern void *kmap_atomic(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
extern void *kmap_atomic_pfn(unsigned long pfn);
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index e8ba37c36590..c700b32350ee 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -31,15 +31,6 @@ static inline pte_t get_fixmap_pte(unsigned long vaddr)
return *ptep;
}
-void kunmap(struct page *page)
-{
- might_sleep();
- if (!PageHighMem(page))
- return;
- kunmap_high(page);
-}
-EXPORT_SYMBOL(kunmap);
-
void *kmap_atomic(struct page *page)
{
unsigned int idx;
diff --git a/arch/csky/include/asm/highmem.h b/arch/csky/include/asm/highmem.h
index 9d0516e38110..be11c5b67122 100644
--- a/arch/csky/include/asm/highmem.h
+++ b/arch/csky/include/asm/highmem.h
@@ -30,11 +30,8 @@ extern pte_t *pkmap_page_table;
#define PKMAP_NR(virt) ((virt-PKMAP_BASE) >> PAGE_SHIFT)
#define PKMAP_ADDR(nr) (PKMAP_BASE + ((nr) << PAGE_SHIFT))
-extern void kunmap_high(struct page *page);
-
#define ARCH_HAS_KMAP_FLUSH_TLB
extern void kmap_flush_tlb(unsigned long addr);
-extern void kunmap(struct page *page);
extern void *kmap_atomic(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
extern void *kmap_atomic_pfn(unsigned long pfn);
diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
index 4a3c273bc8b9..e9952211264b 100644
--- a/arch/csky/mm/highmem.c
+++ b/arch/csky/mm/highmem.c
@@ -21,15 +21,6 @@ EXPORT_SYMBOL(kmap_flush_tlb);
EXPORT_SYMBOL(kmap);
-void kunmap(struct page *page)
-{
- might_sleep();
- if (!PageHighMem(page))
- return;
- kunmap_high(page);
-}
-EXPORT_SYMBOL(kunmap);
-
void *kmap_atomic(struct page *page)
{
unsigned long vaddr;
diff --git a/arch/microblaze/include/asm/highmem.h
b/arch/microblaze/include/asm/highmem.h
index 8c5bfd228bd8..0c94046f2d58 100644
--- a/arch/microblaze/include/asm/highmem.h
+++ b/arch/microblaze/include/asm/highmem.h
@@ -51,18 +51,9 @@ extern pte_t *pkmap_page_table;
#define PKMAP_NR(virt) ((virt - PKMAP_BASE) >> PAGE_SHIFT)
#define PKMAP_ADDR(nr) (PKMAP_BASE + ((nr) << PAGE_SHIFT))
-extern void kunmap_high(struct page *page);
extern void *kmap_atomic_prot(struct page *page, pgprot_t prot);
extern void __kunmap_atomic(void *kvaddr);
-static inline void kunmap(struct page *page)
-{
- might_sleep();
- if (!PageHighMem(page))
-
[PATCH V1 05/10] arch/kmap_atomic: Consolidate duplicate code
From: Ira Weiny
Every arch has the same code to ensure atomic operations and a check for
!HIGHMEM page.
Remove the duplicate code by defining a core kmap_atomic() which only
calls the arch specific kmap_atomic_high() when the page is high memory.
Signed-off-by: Ira Weiny
---
Changes from V0:
consolidate comments
Use a similar architecture to kmap() and define
kmap_atomic_high() for architecture specific
functionality
Fix 0-day build issue in arch/mips/mm/cache.c
---
arch/arc/include/asm/highmem.h| 2 +-
arch/arc/mm/highmem.c | 9 ++---
arch/arm/include/asm/highmem.h| 2 +-
arch/arm/mm/highmem.c | 9 ++---
arch/csky/include/asm/highmem.h | 2 +-
arch/csky/mm/highmem.c| 9 ++---
arch/microblaze/include/asm/highmem.h | 2 +-
arch/microblaze/mm/highmem.c | 6 --
arch/mips/include/asm/highmem.h | 2 +-
arch/mips/mm/cache.c | 2 +-
arch/mips/mm/highmem.c| 18 ++
arch/nds32/include/asm/highmem.h | 2 +-
arch/nds32/mm/highmem.c | 9 ++---
arch/powerpc/include/asm/highmem.h| 2 +-
arch/powerpc/mm/highmem.c | 11 ---
arch/sparc/include/asm/highmem.h | 2 +-
arch/sparc/mm/highmem.c | 9 ++---
arch/x86/include/asm/highmem.h| 7 +--
arch/x86/mm/highmem_32.c | 20
arch/xtensa/include/asm/highmem.h | 2 +-
arch/xtensa/mm/highmem.c | 9 ++---
include/linux/highmem.h | 22 ++
22 files changed, 51 insertions(+), 107 deletions(-)
diff --git a/arch/arc/include/asm/highmem.h b/arch/arc/include/asm/highmem.h
index 8387a5596a91..75bd0fa77fe2 100644
--- a/arch/arc/include/asm/highmem.h
+++ b/arch/arc/include/asm/highmem.h
@@ -30,7 +30,7 @@
#include
-extern void *kmap_atomic(struct page *page);
+extern void *kmap_atomic_high(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
extern void kmap_init(void);
diff --git a/arch/arc/mm/highmem.c b/arch/arc/mm/highmem.c
index 4db13a6b9f3b..0964b011c29f 100644
--- a/arch/arc/mm/highmem.c
+++ b/arch/arc/mm/highmem.c
@@ -49,16 +49,11 @@
extern pte_t * pkmap_page_table;
static pte_t * fixmap_page_table;
-void *kmap_atomic(struct page *page)
+void *kmap_atomic_high(struct page *page)
{
int idx, cpu_idx;
unsigned long vaddr;
- preempt_disable();
- pagefault_disable();
- if (!PageHighMem(page))
- return page_address(page);
-
cpu_idx = kmap_atomic_idx_push();
idx = cpu_idx + KM_TYPE_NR * smp_processor_id();
vaddr = FIXMAP_ADDR(idx);
@@ -68,7 +63,7 @@ void *kmap_atomic(struct page *page)
return (void *)vaddr;
}
-EXPORT_SYMBOL(kmap_atomic);
+EXPORT_SYMBOL(kmap_atomic_high);
void __kunmap_atomic(void *kv)
{
diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
index 736f65283e7b..4edb6db3a5c8 100644
--- a/arch/arm/include/asm/highmem.h
+++ b/arch/arm/include/asm/highmem.h
@@ -60,7 +60,7 @@ static inline void *kmap_high_get(struct page *page)
* when CONFIG_HIGHMEM is not set.
*/
#ifdef CONFIG_HIGHMEM
-extern void *kmap_atomic(struct page *page);
+extern void *kmap_atomic_high(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
extern void *kmap_atomic_pfn(unsigned long pfn);
#endif
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index c700b32350ee..075fdc235091 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -31,18 +31,13 @@ static inline pte_t get_fixmap_pte(unsigned long vaddr)
return *ptep;
}
-void *kmap_atomic(struct page *page)
+void *kmap_atomic_high(struct page *page)
{
unsigned int idx;
unsigned long vaddr;
void *kmap;
int type;
- preempt_disable();
- pagefault_disable();
- if (!PageHighMem(page))
- return page_address(page);
-
#ifdef CONFIG_DEBUG_HIGHMEM
/*
* There is no cache coherency issue when non VIVT, so force the
@@ -76,7 +71,7 @@ void *kmap_atomic(struct page *page)
return (void *)vaddr;
}
-EXPORT_SYMBOL(kmap_atomic);
+EXPORT_SYMBOL(kmap_atomic_high);
void __kunmap_atomic(void *kvaddr)
{
diff --git a/arch/csky/include/asm/highmem.h b/arch/csky/include/asm/highmem.h
index be11c5b67122..6807df1232f3 100644
--- a/arch/csky/include/asm/highmem.h
+++ b/arch/csky/include/asm/highmem.h
@@ -32,7 +32,7 @@ extern pte_t *pkmap_page_table;
#define ARCH_HAS_KMAP_FLUSH_TLB
extern void kmap_flush_tlb(unsigned long addr);
-extern void *kmap_atomic(struct page *page);
+extern void *kmap_atomic_high(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
extern void *kmap_atomic_pfn(unsigned long pfn);
extern struct page *kmap_atomic_to_page(void *ptr);
diff --git a/arch/csky/mm/highmem.c
[PATCH V1 08/10] arch/kmap: Don't hard code kmap_prot values
From: Ira Weiny To support kmap_atomic_prot() on all architectures each arch must support protections passed in to them. Change csky, mips, nds32 and xtensa to use their global kmap_prot value rather than a hard coded value which was equal. Signed-off-by: Ira Weiny --- arch/csky/mm/highmem.c | 2 +- arch/mips/mm/highmem.c | 2 +- arch/nds32/mm/highmem.c | 2 +- arch/xtensa/mm/highmem.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c index 0aafbbbe651c..f4311669b5bb 100644 --- a/arch/csky/mm/highmem.c +++ b/arch/csky/mm/highmem.c @@ -32,7 +32,7 @@ void *kmap_atomic_high(struct page *page) #ifdef CONFIG_DEBUG_HIGHMEM BUG_ON(!pte_none(*(kmap_pte - idx))); #endif - set_pte(kmap_pte-idx, mk_pte(page, PAGE_KERNEL)); + set_pte(kmap_pte-idx, mk_pte(page, kmap_prot)); flush_tlb_one((unsigned long)vaddr); return (void *)vaddr; diff --git a/arch/mips/mm/highmem.c b/arch/mips/mm/highmem.c index 155fbb107b35..87023bd1a33c 100644 --- a/arch/mips/mm/highmem.c +++ b/arch/mips/mm/highmem.c @@ -29,7 +29,7 @@ void *kmap_atomic_high(struct page *page) #ifdef CONFIG_DEBUG_HIGHMEM BUG_ON(!pte_none(*(kmap_pte - idx))); #endif - set_pte(kmap_pte-idx, mk_pte(page, PAGE_KERNEL)); + set_pte(kmap_pte-idx, mk_pte(page, kmap_prot)); local_flush_tlb_one((unsigned long)vaddr); return (void*) vaddr; diff --git a/arch/nds32/mm/highmem.c b/arch/nds32/mm/highmem.c index f6e6915c0d31..809f8c830f06 100644 --- a/arch/nds32/mm/highmem.c +++ b/arch/nds32/mm/highmem.c @@ -21,7 +21,7 @@ void *kmap_atomic_high(struct page *page) idx = type + KM_TYPE_NR * smp_processor_id(); vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); - pte = (page_to_pfn(page) << PAGE_SHIFT) | (PAGE_KERNEL); + pte = (page_to_pfn(page) << PAGE_SHIFT) | (kmap_prot); ptep = pte_offset_kernel(pmd_off_k(vaddr), vaddr); set_pte(ptep, pte); diff --git a/arch/xtensa/mm/highmem.c b/arch/xtensa/mm/highmem.c index f57a7770eb08..8c58c4c37033 100644 --- a/arch/xtensa/mm/highmem.c +++ b/arch/xtensa/mm/highmem.c @@ -48,7 +48,7 @@ void *kmap_atomic_high(struct page *page) #ifdef CONFIG_DEBUG_HIGHMEM BUG_ON(!pte_none(*(kmap_pte + idx))); #endif - set_pte(kmap_pte + idx, mk_pte(page, PAGE_KERNEL_EXEC)); + set_pte(kmap_pte + idx, mk_pte(page, kmap_prot)); return (void *)vaddr; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V1 07/10] arch/kmap: Ensure kmap_prot visibility
From: Ira Weiny
We want to support kmap_atomic_prot() on all architectures and it makes
sense to define kmap_atomic() to use the default kmap_prot.
So we ensure all arch's have a globally available kmap_prot either as a
define or exported symbol.
Signed-off-by: Ira Weiny
---
arch/microblaze/include/asm/highmem.h | 2 +-
arch/microblaze/mm/init.c | 3 ---
arch/powerpc/include/asm/highmem.h| 2 +-
arch/powerpc/mm/mem.c | 3 ---
arch/sparc/mm/highmem.c | 1 +
5 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/microblaze/include/asm/highmem.h
b/arch/microblaze/include/asm/highmem.h
index 5fc56b0107be..66521fdc3a47 100644
--- a/arch/microblaze/include/asm/highmem.h
+++ b/arch/microblaze/include/asm/highmem.h
@@ -25,8 +25,8 @@
#include
#include
+#define kmap_prot PAGE_KERNEL
extern pte_t *kmap_pte;
-extern pgprot_t kmap_prot;
extern pte_t *pkmap_page_table;
/*
diff --git a/arch/microblaze/mm/init.c b/arch/microblaze/mm/init.c
index 1ffbfa96b9b8..a467686c13af 100644
--- a/arch/microblaze/mm/init.c
+++ b/arch/microblaze/mm/init.c
@@ -49,8 +49,6 @@ unsigned long lowmem_size;
#ifdef CONFIG_HIGHMEM
pte_t *kmap_pte;
EXPORT_SYMBOL(kmap_pte);
-pgprot_t kmap_prot;
-EXPORT_SYMBOL(kmap_prot);
static inline pte_t *virt_to_kpte(unsigned long vaddr)
{
@@ -68,7 +66,6 @@ static void __init highmem_init(void)
pkmap_page_table = virt_to_kpte(PKMAP_BASE);
kmap_pte = virt_to_kpte(__fix_to_virt(FIX_KMAP_BEGIN));
- kmap_prot = PAGE_KERNEL;
}
static void highmem_setup(void)
diff --git a/arch/powerpc/include/asm/highmem.h
b/arch/powerpc/include/asm/highmem.h
index 1845fbd7ce61..d264aebcaa9b 100644
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -29,8 +29,8 @@
#include
#include
+#define kmap_prot PAGE_KERNEL
extern pte_t *kmap_pte;
-extern pgprot_t kmap_prot;
extern pte_t *pkmap_page_table;
/*
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 041ed7cfd341..3f642b058731 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -64,8 +64,6 @@ bool init_mem_is_free;
#ifdef CONFIG_HIGHMEM
pte_t *kmap_pte;
EXPORT_SYMBOL(kmap_pte);
-pgprot_t kmap_prot;
-EXPORT_SYMBOL(kmap_prot);
#endif
pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
@@ -245,7 +243,6 @@ void __init paging_init(void)
pkmap_page_table = virt_to_kpte(PKMAP_BASE);
kmap_pte = virt_to_kpte(__fix_to_virt(FIX_KMAP_BEGIN));
- kmap_prot = PAGE_KERNEL;
#endif /* CONFIG_HIGHMEM */
printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%llx\n",
diff --git a/arch/sparc/mm/highmem.c b/arch/sparc/mm/highmem.c
index 469786bc430f..9f06d75e88e1 100644
--- a/arch/sparc/mm/highmem.c
+++ b/arch/sparc/mm/highmem.c
@@ -33,6 +33,7 @@
#include
pgprot_t kmap_prot;
+EXPORT_SYMBOL(kmap_prot);
static pte_t *kmap_pte;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V1 02/10] arch/xtensa: Move kmap build bug out of the way
From: Ira Weiny
Move the kmap() build bug to kmap_init() to facilitate patches to lift
kmap() to the core.
Signed-off-by: Ira Weiny
---
arch/xtensa/include/asm/highmem.h | 5 -
arch/xtensa/mm/highmem.c | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/xtensa/include/asm/highmem.h
b/arch/xtensa/include/asm/highmem.h
index 413848cc1e56..a9587c85be85 100644
--- a/arch/xtensa/include/asm/highmem.h
+++ b/arch/xtensa/include/asm/highmem.h
@@ -68,11 +68,6 @@ void kunmap_high(struct page *page);
static inline void *kmap(struct page *page)
{
- /* Check if this memory layout is broken because PKMAP overlaps
-* page table.
-*/
- BUILD_BUG_ON(PKMAP_BASE <
-TLBTEMP_BASE_1 + TLBTEMP_SIZE);
might_sleep();
if (!PageHighMem(page))
return page_address(page);
diff --git a/arch/xtensa/mm/highmem.c b/arch/xtensa/mm/highmem.c
index 184ceadccc1a..711641c4d214 100644
--- a/arch/xtensa/mm/highmem.c
+++ b/arch/xtensa/mm/highmem.c
@@ -88,6 +88,11 @@ void __init kmap_init(void)
{
unsigned long kmap_vstart;
+ /* Check if this memory layout is broken because PKMAP overlaps
+* page table.
+*/
+ BUILD_BUG_ON(PKMAP_BASE <
+TLBTEMP_BASE_1 + TLBTEMP_SIZE);
/* cache the first kmap pte */
kmap_vstart = __fix_to_virt(FIX_KMAP_BEGIN);
kmap_pte = kmap_get_fixmap_pte(kmap_vstart);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V1 00/10] Remove duplicated kmap code
From: Ira Weiny The kmap infrastructure has been copied almost verbatim to every architecture. This series consolidates obvious duplicated code by defining core functions which call into the architectures only when needed. Some of the k[un]map_atomic() implementations have some similarities but the similarities were not sufficient to warrant further changes. In addition we remove a duplicate implementation of kmap() in DRM. Testing was done by 0day to cover all the architectures I can't readily build/test. --- Changes from V0: rebase to 5.7-rc4 Define kmap_flush_tlb() and make kmap() truely arch independent. Redefine the k[un]map_atomic_* code to call into the architectures for high mem pages Ensure all architectures define kmap_prot, use it appropriately, and define kmap_atomic_prot() Remove drm implementation of kmap_atomic() Ira Weiny (10): arch/kmap: Remove BUG_ON() arch/xtensa: Move kmap build bug out of the way arch/kmap: Remove redundant arch specific kmaps arch/kunmap: Remove duplicate kunmap implementations arch/kmap_atomic: Consolidate duplicate code arch/kunmap_atomic: Consolidate duplicate code arch/kmap: Ensure kmap_prot visibility arch/kmap: Don't hard code kmap_prot values arch/kmap: Define kmap_atomic_prot() for all arch's drm: Remove drm specific kmap_atomic code arch/arc/include/asm/highmem.h| 16 +-- arch/arc/mm/highmem.c | 28 +++-- arch/arm/include/asm/highmem.h| 9 +--- arch/arm/mm/highmem.c | 35 +++- arch/csky/include/asm/highmem.h | 11 ++--- arch/csky/mm/highmem.c| 43 +-- arch/microblaze/include/asm/highmem.h | 29 ++--- arch/microblaze/mm/highmem.c | 16 ++- arch/microblaze/mm/init.c | 3 -- arch/mips/include/asm/highmem.h | 11 ++--- arch/mips/mm/cache.c | 6 +-- arch/mips/mm/highmem.c| 49 -- arch/nds32/include/asm/highmem.h | 9 +--- arch/nds32/mm/highmem.c | 39 +++-- arch/parisc/include/asm/cacheflush.h | 4 +- arch/powerpc/include/asm/highmem.h| 30 ++ arch/powerpc/mm/highmem.c | 21 ++ arch/powerpc/mm/mem.c | 3 -- arch/sparc/include/asm/highmem.h | 23 +- arch/sparc/mm/highmem.c | 18 +++- arch/x86/include/asm/highmem.h| 11 + arch/x86/mm/highmem_32.c | 50 ++ arch/xtensa/include/asm/highmem.h | 28 + arch/xtensa/mm/highmem.c | 23 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 56 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 16 +++ include/drm/ttm/ttm_bo_api.h | 4 -- include/linux/highmem.h | 60 +-- 28 files changed, 159 insertions(+), 492 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V1 03/10] arch/kmap: Remove redundant arch specific kmaps
From: Ira Weiny
The kmap code for all the architectures is almost 100% identical.
Lift the common code to the core. Use ARCH_HAS_KMAP_FLUSH_TLB to
indicate if an arch defines kmap_flush_tlb() and call if if needed.
This also has the benefit of changing kmap() on a number of
architectures to be an inline call rather than an actual function.
Signed-off-by: Ira Weiny
---
Changes from V0:
Define kmap_flush_tlb() and define it in csky/mips
---
arch/arc/include/asm/highmem.h| 2 --
arch/arc/mm/highmem.c | 10 --
arch/arm/include/asm/highmem.h| 2 --
arch/arm/mm/highmem.c | 9 -
arch/csky/include/asm/highmem.h | 4 ++--
arch/csky/mm/highmem.c| 14 --
arch/microblaze/include/asm/highmem.h | 9 -
arch/mips/include/asm/highmem.h | 4 ++--
arch/mips/mm/highmem.c| 14 +++---
arch/nds32/include/asm/highmem.h | 2 --
arch/nds32/mm/highmem.c | 12
arch/powerpc/include/asm/highmem.h| 9 -
arch/sparc/include/asm/highmem.h | 9 -
arch/x86/include/asm/highmem.h| 2 --
arch/x86/mm/highmem_32.c | 9 -
arch/xtensa/include/asm/highmem.h | 9 -
include/linux/highmem.h | 18 ++
17 files changed, 29 insertions(+), 109 deletions(-)
diff --git a/arch/arc/include/asm/highmem.h b/arch/arc/include/asm/highmem.h
index 042e92921c4c..96eb67c86961 100644
--- a/arch/arc/include/asm/highmem.h
+++ b/arch/arc/include/asm/highmem.h
@@ -30,8 +30,6 @@
#include
-extern void *kmap(struct page *page);
-extern void *kmap_high(struct page *page);
extern void *kmap_atomic(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
extern void kunmap_high(struct page *page);
diff --git a/arch/arc/mm/highmem.c b/arch/arc/mm/highmem.c
index 39ef7b9a3aa9..4db13a6b9f3b 100644
--- a/arch/arc/mm/highmem.c
+++ b/arch/arc/mm/highmem.c
@@ -49,16 +49,6 @@
extern pte_t * pkmap_page_table;
static pte_t * fixmap_page_table;
-void *kmap(struct page *page)
-{
- might_sleep();
- if (!PageHighMem(page))
- return page_address(page);
-
- return kmap_high(page);
-}
-EXPORT_SYMBOL(kmap);
-
void *kmap_atomic(struct page *page)
{
int idx, cpu_idx;
diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
index eb4e4207cd3c..c917522541de 100644
--- a/arch/arm/include/asm/highmem.h
+++ b/arch/arm/include/asm/highmem.h
@@ -20,7 +20,6 @@
extern pte_t *pkmap_page_table;
-extern void *kmap_high(struct page *page);
extern void kunmap_high(struct page *page);
/*
@@ -63,7 +62,6 @@ static inline void *kmap_high_get(struct page *page)
* when CONFIG_HIGHMEM is not set.
*/
#ifdef CONFIG_HIGHMEM
-extern void *kmap(struct page *page);
extern void kunmap(struct page *page);
extern void *kmap_atomic(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index cc6eb79ef20c..e8ba37c36590 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -31,15 +31,6 @@ static inline pte_t get_fixmap_pte(unsigned long vaddr)
return *ptep;
}
-void *kmap(struct page *page)
-{
- might_sleep();
- if (!PageHighMem(page))
- return page_address(page);
- return kmap_high(page);
-}
-EXPORT_SYMBOL(kmap);
-
void kunmap(struct page *page)
{
might_sleep();
diff --git a/arch/csky/include/asm/highmem.h b/arch/csky/include/asm/highmem.h
index a345a2f2c22e..9d0516e38110 100644
--- a/arch/csky/include/asm/highmem.h
+++ b/arch/csky/include/asm/highmem.h
@@ -30,10 +30,10 @@ extern pte_t *pkmap_page_table;
#define PKMAP_NR(virt) ((virt-PKMAP_BASE) >> PAGE_SHIFT)
#define PKMAP_ADDR(nr) (PKMAP_BASE + ((nr) << PAGE_SHIFT))
-extern void *kmap_high(struct page *page);
extern void kunmap_high(struct page *page);
-extern void *kmap(struct page *page);
+#define ARCH_HAS_KMAP_FLUSH_TLB
+extern void kmap_flush_tlb(unsigned long addr);
extern void kunmap(struct page *page);
extern void *kmap_atomic(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
index 690d678649d1..4a3c273bc8b9 100644
--- a/arch/csky/mm/highmem.c
+++ b/arch/csky/mm/highmem.c
@@ -13,18 +13,12 @@ static pte_t *kmap_pte;
unsigned long highstart_pfn, highend_pfn;
-void *kmap(struct page *page)
+void kmap_flush_tlb(unsigned long addr)
{
- void *addr;
-
- might_sleep();
- if (!PageHighMem(page))
- return page_address(page);
- addr = kmap_high(page);
- flush_tlb_one((unsigned long)addr);
-
- return addr;
+ flush_tlb_one(addr);
}
+EXPORT_SYMBOL(kmap_flush_tlb);
+
EXPORT_SYMBOL(kmap);
void kunmap(struct page *page)
diff --git a/arch/microblaze/include/asm/highmem.h
b/arch/microblaze/include/asm/highmem.h
index
[PATCH V1 09/10] arch/kmap: Define kmap_atomic_prot() for all arch's
From: Ira Weiny
To support kmap_atomic_prot(), all architectures need to support
protections passed to their kmap_atomic_high() function. Pass
protections into kmap_atomic_high() and change the name to
kmap_atomic_high_prot() to match.
Then define kmap_atomic_prot() as a core function which calls
kmap_atomic_high_prot() when needed.
Finally, redefine kmap_atomic() as a wrapper of kmap_atomic_prot() with
the default kmap_prot exported by the architectures.
Signed-off-by: Ira Weiny
---
arch/arc/include/asm/highmem.h| 2 +-
arch/arc/mm/highmem.c | 6 +++---
arch/arm/include/asm/highmem.h| 2 +-
arch/arm/mm/highmem.c | 6 +++---
arch/csky/include/asm/highmem.h | 2 +-
arch/csky/mm/highmem.c| 6 +++---
arch/microblaze/include/asm/highmem.h | 7 +--
arch/microblaze/mm/highmem.c | 4 ++--
arch/mips/include/asm/highmem.h | 2 +-
arch/mips/mm/highmem.c| 6 +++---
arch/nds32/include/asm/highmem.h | 2 +-
arch/nds32/mm/highmem.c | 6 +++---
arch/powerpc/include/asm/highmem.h| 8 +---
arch/powerpc/mm/highmem.c | 4 ++--
arch/sparc/include/asm/highmem.h | 2 +-
arch/sparc/mm/highmem.c | 6 +++---
arch/x86/include/asm/highmem.h| 6 +-
arch/x86/mm/highmem_32.c | 4 ++--
arch/xtensa/include/asm/highmem.h | 2 +-
arch/xtensa/mm/highmem.c | 6 +++---
include/linux/highmem.h | 5 +++--
21 files changed, 40 insertions(+), 54 deletions(-)
diff --git a/arch/arc/include/asm/highmem.h b/arch/arc/include/asm/highmem.h
index e16531495620..09f86bde6809 100644
--- a/arch/arc/include/asm/highmem.h
+++ b/arch/arc/include/asm/highmem.h
@@ -30,7 +30,7 @@
#include
-extern void *kmap_atomic_high(struct page *page);
+extern void *kmap_atomic_high_prot(struct page *page, pgprot_t prot);
extern void kunmap_atomic_high(void *kvaddr);
extern void kmap_init(void);
diff --git a/arch/arc/mm/highmem.c b/arch/arc/mm/highmem.c
index 5d3eab4ac0b0..479b0d72d3cf 100644
--- a/arch/arc/mm/highmem.c
+++ b/arch/arc/mm/highmem.c
@@ -49,7 +49,7 @@
extern pte_t * pkmap_page_table;
static pte_t * fixmap_page_table;
-void *kmap_atomic_high(struct page *page)
+void *kmap_atomic_high_prot(struct page *page, pgprot_t prot)
{
int idx, cpu_idx;
unsigned long vaddr;
@@ -59,11 +59,11 @@ void *kmap_atomic_high(struct page *page)
vaddr = FIXMAP_ADDR(idx);
set_pte_at(_mm, vaddr, fixmap_page_table + idx,
- mk_pte(page, kmap_prot));
+ mk_pte(page, prot));
return (void *)vaddr;
}
-EXPORT_SYMBOL(kmap_atomic_high);
+EXPORT_SYMBOL(kmap_atomic_high_prot);
void kunmap_atomic_high(void *kv)
{
diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
index a9d5e9bce1cc..e35f2f73f6aa 100644
--- a/arch/arm/include/asm/highmem.h
+++ b/arch/arm/include/asm/highmem.h
@@ -60,7 +60,7 @@ static inline void *kmap_high_get(struct page *page)
* when CONFIG_HIGHMEM is not set.
*/
#ifdef CONFIG_HIGHMEM
-extern void *kmap_atomic_high(struct page *page);
+extern void *kmap_atomic_high_prot(struct page *page, pgprot_t prot);
extern void kunmap_atomic_high(void *kvaddr);
extern void *kmap_atomic_pfn(unsigned long pfn);
#endif
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index ac8394655a6e..e013f6b81328 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -31,7 +31,7 @@ static inline pte_t get_fixmap_pte(unsigned long vaddr)
return *ptep;
}
-void *kmap_atomic_high(struct page *page)
+void *kmap_atomic_high_prot(struct page *page, pgprot_t prot)
{
unsigned int idx;
unsigned long vaddr;
@@ -67,11 +67,11 @@ void *kmap_atomic_high(struct page *page)
* in place, so the contained TLB flush ensures the TLB is updated
* with the new mapping.
*/
- set_fixmap_pte(idx, mk_pte(page, kmap_prot));
+ set_fixmap_pte(idx, mk_pte(page, prot));
return (void *)vaddr;
}
-EXPORT_SYMBOL(kmap_atomic_high);
+EXPORT_SYMBOL(kmap_atomic_high_prot);
void kunmap_atomic_high(void *kvaddr)
{
diff --git a/arch/csky/include/asm/highmem.h b/arch/csky/include/asm/highmem.h
index 5bbbe59e60a9..59854c7ccf78 100644
--- a/arch/csky/include/asm/highmem.h
+++ b/arch/csky/include/asm/highmem.h
@@ -32,7 +32,7 @@ extern pte_t *pkmap_page_table;
#define ARCH_HAS_KMAP_FLUSH_TLB
extern void kmap_flush_tlb(unsigned long addr);
-extern void *kmap_atomic_high(struct page *page);
+extern void *kmap_atomic_high_prot(struct page *page, pgprot_t prot);
extern void kunmap_atomic_high(void *kvaddr);
extern void *kmap_atomic_pfn(unsigned long pfn);
extern struct page *kmap_atomic_to_page(void *ptr);
diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
index f4311669b5bb..3ae5c8cd7619 100644
--- a/arch/csky/mm/highmem.c
+++ b/arch/csky/mm/highmem.c
@@ -21,7 +21,7 @@
[PATCH V1 10/10] drm: Remove drm specific kmap_atomic code
From: Ira Weiny
kmap_atomic_prot() is now exported by all architectures. Use this
function rather than open coding a driver specific kmap_atomic.
Signed-off-by: Ira Weiny
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 56 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 16
include/drm/ttm/ttm_bo_api.h | 4 --
3 files changed, 12 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 52d2b71f1588..f09b096ba4fd 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -257,54 +257,6 @@ static int ttm_copy_io_page(void *dst, void *src, unsigned
long page)
return 0;
}
-#ifdef CONFIG_X86
-#define __ttm_kmap_atomic_prot(__page, __prot) kmap_atomic_prot(__page, __prot)
-#define __ttm_kunmap_atomic(__addr) kunmap_atomic(__addr)
-#else
-#define __ttm_kmap_atomic_prot(__page, __prot) vmap(&__page, 1, 0, __prot)
-#define __ttm_kunmap_atomic(__addr) vunmap(__addr)
-#endif
-
-
-/**
- * ttm_kmap_atomic_prot - Efficient kernel map of a single page with
- * specified page protection.
- *
- * @page: The page to map.
- * @prot: The page protection.
- *
- * This function maps a TTM page using the kmap_atomic api if available,
- * otherwise falls back to vmap. The user must make sure that the
- * specified page does not have an aliased mapping with a different caching
- * policy unless the architecture explicitly allows it. Also mapping and
- * unmapping using this api must be correctly nested. Unmapping should
- * occur in the reverse order of mapping.
- */
-void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot)
-{
- if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
- return kmap_atomic(page);
- else
- return __ttm_kmap_atomic_prot(page, prot);
-}
-EXPORT_SYMBOL(ttm_kmap_atomic_prot);
-
-/**
- * ttm_kunmap_atomic_prot - Unmap a page that was mapped using
- * ttm_kmap_atomic_prot.
- *
- * @addr: The virtual address from the map.
- * @prot: The page protection.
- */
-void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot)
-{
- if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
- kunmap_atomic(addr);
- else
- __ttm_kunmap_atomic(addr);
-}
-EXPORT_SYMBOL(ttm_kunmap_atomic_prot);
-
static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src,
unsigned long page,
pgprot_t prot)
@@ -316,13 +268,13 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void
*src,
return -ENOMEM;
src = (void *)((unsigned long)src + (page << PAGE_SHIFT));
- dst = ttm_kmap_atomic_prot(d, prot);
+ dst = kmap_atomic_prot(d, prot);
if (!dst)
return -ENOMEM;
memcpy_fromio(dst, src, PAGE_SIZE);
- ttm_kunmap_atomic_prot(dst, prot);
+ kunmap_atomic(dst);
return 0;
}
@@ -338,13 +290,13 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm, void
*dst,
return -ENOMEM;
dst = (void *)((unsigned long)dst + (page << PAGE_SHIFT));
- src = ttm_kmap_atomic_prot(s, prot);
+ src = kmap_atomic_prot(s, prot);
if (!src)
return -ENOMEM;
memcpy_toio(dst, src, PAGE_SIZE);
- ttm_kunmap_atomic_prot(src, prot);
+ kunmap_atomic(src);
return 0;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
index bb46ca0c458f..94d456a1d1a9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -374,12 +374,12 @@ static int vmw_bo_cpu_blit_line(struct
vmw_bo_blit_line_data *d,
copy_size = min_t(u32, copy_size, PAGE_SIZE - src_page_offset);
if (unmap_src) {
- ttm_kunmap_atomic_prot(d->src_addr, d->src_prot);
+ kunmap_atomic(d->src_addr);
d->src_addr = NULL;
}
if (unmap_dst) {
- ttm_kunmap_atomic_prot(d->dst_addr, d->dst_prot);
+ kunmap_atomic(d->dst_addr);
d->dst_addr = NULL;
}
@@ -388,8 +388,8 @@ static int vmw_bo_cpu_blit_line(struct
vmw_bo_blit_line_data *d,
return -EINVAL;
d->dst_addr =
- ttm_kmap_atomic_prot(d->dst_pages[dst_page],
-d->dst_prot);
+ kmap_atomic_prot(d->dst_pages[dst_page],
+d->dst_prot);
if (!d->dst_addr)
return -ENOMEM;
@@ -401,8 +401,8 @@ static int vmw_bo_cpu_blit_line(struct
vmw_bo_blit_line_data *d,
return -EINVAL;
d->src_addr =
-
[PATCH V1 01/10] arch/kmap: Remove BUG_ON()
From: Ira Weiny
Replace the use of BUG_ON(in_interrupt()) in the kmap() and kunmap()
in favor of might_sleep().
Besides the benefits of might_sleep(), this normalizes the
implementations such that they can be made generic in subsequent
patches.
Reviewed-by: Dan Williams
Signed-off-by: Ira Weiny
---
arch/arc/include/asm/highmem.h| 2 +-
arch/arc/mm/highmem.c | 2 +-
arch/arm/mm/highmem.c | 2 +-
arch/csky/mm/highmem.c| 2 +-
arch/microblaze/include/asm/highmem.h | 2 +-
arch/mips/mm/highmem.c| 2 +-
arch/nds32/mm/highmem.c | 2 +-
arch/powerpc/include/asm/highmem.h| 2 +-
arch/sparc/include/asm/highmem.h | 4 ++--
arch/x86/mm/highmem_32.c | 3 +--
arch/xtensa/include/asm/highmem.h | 4 ++--
11 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/arc/include/asm/highmem.h b/arch/arc/include/asm/highmem.h
index 1af00accb37f..042e92921c4c 100644
--- a/arch/arc/include/asm/highmem.h
+++ b/arch/arc/include/asm/highmem.h
@@ -45,7 +45,7 @@ static inline void flush_cache_kmaps(void)
static inline void kunmap(struct page *page)
{
- BUG_ON(in_interrupt());
+ might_sleep();
if (!PageHighMem(page))
return;
kunmap_high(page);
diff --git a/arch/arc/mm/highmem.c b/arch/arc/mm/highmem.c
index fc8849e4f72e..39ef7b9a3aa9 100644
--- a/arch/arc/mm/highmem.c
+++ b/arch/arc/mm/highmem.c
@@ -51,7 +51,7 @@ static pte_t * fixmap_page_table;
void *kmap(struct page *page)
{
- BUG_ON(in_interrupt());
+ might_sleep();
if (!PageHighMem(page))
return page_address(page);
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index a76f8ace9ce6..cc6eb79ef20c 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -42,7 +42,7 @@ EXPORT_SYMBOL(kmap);
void kunmap(struct page *page)
{
- BUG_ON(in_interrupt());
+ might_sleep();
if (!PageHighMem(page))
return;
kunmap_high(page);
diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
index 813129145f3d..690d678649d1 100644
--- a/arch/csky/mm/highmem.c
+++ b/arch/csky/mm/highmem.c
@@ -29,7 +29,7 @@ EXPORT_SYMBOL(kmap);
void kunmap(struct page *page)
{
- BUG_ON(in_interrupt());
+ might_sleep();
if (!PageHighMem(page))
return;
kunmap_high(page);
diff --git a/arch/microblaze/include/asm/highmem.h
b/arch/microblaze/include/asm/highmem.h
index 332c78e15198..99ced7278b5c 100644
--- a/arch/microblaze/include/asm/highmem.h
+++ b/arch/microblaze/include/asm/highmem.h
@@ -66,7 +66,7 @@ static inline void *kmap(struct page *page)
static inline void kunmap(struct page *page)
{
- BUG_ON(in_interrupt());
+ might_sleep();
if (!PageHighMem(page))
return;
kunmap_high(page);
diff --git a/arch/mips/mm/highmem.c b/arch/mips/mm/highmem.c
index d08e6d7d533b..edd889f6cede 100644
--- a/arch/mips/mm/highmem.c
+++ b/arch/mips/mm/highmem.c
@@ -28,7 +28,7 @@ EXPORT_SYMBOL(kmap);
void kunmap(struct page *page)
{
- BUG_ON(in_interrupt());
+ might_sleep();
if (!PageHighMem(page))
return;
kunmap_high(page);
diff --git a/arch/nds32/mm/highmem.c b/arch/nds32/mm/highmem.c
index 022779af6148..4c7c28e994ea 100644
--- a/arch/nds32/mm/highmem.c
+++ b/arch/nds32/mm/highmem.c
@@ -24,7 +24,7 @@ EXPORT_SYMBOL(kmap);
void kunmap(struct page *page)
{
- BUG_ON(in_interrupt());
+ might_sleep();
if (!PageHighMem(page))
return;
kunmap_high(page);
diff --git a/arch/powerpc/include/asm/highmem.h
b/arch/powerpc/include/asm/highmem.h
index a4b65b186ec6..529512f6d65a 100644
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -74,7 +74,7 @@ static inline void *kmap(struct page *page)
static inline void kunmap(struct page *page)
{
- BUG_ON(in_interrupt());
+ might_sleep();
if (!PageHighMem(page))
return;
kunmap_high(page);
diff --git a/arch/sparc/include/asm/highmem.h b/arch/sparc/include/asm/highmem.h
index 18d776925c45..7dd2d4b3f980 100644
--- a/arch/sparc/include/asm/highmem.h
+++ b/arch/sparc/include/asm/highmem.h
@@ -55,7 +55,7 @@ void kunmap_high(struct page *page);
static inline void *kmap(struct page *page)
{
- BUG_ON(in_interrupt());
+ might_sleep();
if (!PageHighMem(page))
return page_address(page);
return kmap_high(page);
@@ -63,7 +63,7 @@ static inline void *kmap(struct page *page)
static inline void kunmap(struct page *page)
{
- BUG_ON(in_interrupt());
+ might_sleep();
if (!PageHighMem(page))
return;
kunmap_high(page);
diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c
index 0a1898b8552e..8af66382672b 100644
--- a/arch/x86/mm/highmem_32.c
+++ b/arch/x86/mm/highmem_32.c
@@
[PATCH V1 06/10] arch/kunmap_atomic: Consolidate duplicate code
From: Ira Weiny
Every single architecture (including !CONFIG_HIGHMEM) calls...
pagefault_enable();
preempt_enable();
... before returning from __kunmap_atomic(). Lift this code into the
kunmap_atomic() macro.
While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
be consistent.
Signed-off-by: Ira Weiny
---
Changes from V0:
rename __kunmap_atomic() to kunmap_atomic_high()
Fix mips issue
---
arch/arc/include/asm/highmem.h| 2 +-
arch/arc/mm/highmem.c | 7 ++-
arch/arm/include/asm/highmem.h| 2 +-
arch/arm/mm/highmem.c | 6 ++
arch/csky/include/asm/highmem.h | 2 +-
arch/csky/mm/highmem.c| 9 +++--
arch/microblaze/include/asm/highmem.h | 2 +-
arch/microblaze/mm/highmem.c | 6 ++
arch/mips/include/asm/highmem.h | 2 +-
arch/mips/mm/cache.c | 4 ++--
arch/mips/mm/highmem.c| 6 ++
arch/nds32/include/asm/highmem.h | 2 +-
arch/nds32/mm/highmem.c | 6 ++
arch/parisc/include/asm/cacheflush.h | 4 +---
arch/powerpc/include/asm/highmem.h| 2 +-
arch/powerpc/mm/highmem.c | 6 ++
arch/sparc/include/asm/highmem.h | 2 +-
arch/sparc/mm/highmem.c | 6 ++
arch/x86/include/asm/highmem.h| 2 +-
arch/x86/mm/highmem_32.c | 7 ++-
arch/xtensa/include/asm/highmem.h | 2 +-
arch/xtensa/mm/highmem.c | 7 ++-
include/linux/highmem.h | 10 ++
23 files changed, 40 insertions(+), 64 deletions(-)
diff --git a/arch/arc/include/asm/highmem.h b/arch/arc/include/asm/highmem.h
index 75bd0fa77fe2..e16531495620 100644
--- a/arch/arc/include/asm/highmem.h
+++ b/arch/arc/include/asm/highmem.h
@@ -31,7 +31,7 @@
#include
extern void *kmap_atomic_high(struct page *page);
-extern void __kunmap_atomic(void *kvaddr);
+extern void kunmap_atomic_high(void *kvaddr);
extern void kmap_init(void);
diff --git a/arch/arc/mm/highmem.c b/arch/arc/mm/highmem.c
index 0964b011c29f..5d3eab4ac0b0 100644
--- a/arch/arc/mm/highmem.c
+++ b/arch/arc/mm/highmem.c
@@ -65,7 +65,7 @@ void *kmap_atomic_high(struct page *page)
}
EXPORT_SYMBOL(kmap_atomic_high);
-void __kunmap_atomic(void *kv)
+void kunmap_atomic_high(void *kv)
{
unsigned long kvaddr = (unsigned long)kv;
@@ -87,11 +87,8 @@ void __kunmap_atomic(void *kv)
kmap_atomic_idx_pop();
}
-
- pagefault_enable();
- preempt_enable();
}
-EXPORT_SYMBOL(__kunmap_atomic);
+EXPORT_SYMBOL(kunmap_atomic_high);
static noinline pte_t * __init alloc_kmap_pgtable(unsigned long kvaddr)
{
diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
index 4edb6db3a5c8..a9d5e9bce1cc 100644
--- a/arch/arm/include/asm/highmem.h
+++ b/arch/arm/include/asm/highmem.h
@@ -61,7 +61,7 @@ static inline void *kmap_high_get(struct page *page)
*/
#ifdef CONFIG_HIGHMEM
extern void *kmap_atomic_high(struct page *page);
-extern void __kunmap_atomic(void *kvaddr);
+extern void kunmap_atomic_high(void *kvaddr);
extern void *kmap_atomic_pfn(unsigned long pfn);
#endif
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index 075fdc235091..ac8394655a6e 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -73,7 +73,7 @@ void *kmap_atomic_high(struct page *page)
}
EXPORT_SYMBOL(kmap_atomic_high);
-void __kunmap_atomic(void *kvaddr)
+void kunmap_atomic_high(void *kvaddr)
{
unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
int idx, type;
@@ -95,10 +95,8 @@ void __kunmap_atomic(void *kvaddr)
/* this address was obtained through kmap_high_get() */
kunmap_high(pte_page(pkmap_page_table[PKMAP_NR(vaddr)]));
}
- pagefault_enable();
- preempt_enable();
}
-EXPORT_SYMBOL(__kunmap_atomic);
+EXPORT_SYMBOL(kunmap_atomic_high);
void *kmap_atomic_pfn(unsigned long pfn)
{
diff --git a/arch/csky/include/asm/highmem.h b/arch/csky/include/asm/highmem.h
index 6807df1232f3..5bbbe59e60a9 100644
--- a/arch/csky/include/asm/highmem.h
+++ b/arch/csky/include/asm/highmem.h
@@ -33,7 +33,7 @@ extern pte_t *pkmap_page_table;
#define ARCH_HAS_KMAP_FLUSH_TLB
extern void kmap_flush_tlb(unsigned long addr);
extern void *kmap_atomic_high(struct page *page);
-extern void __kunmap_atomic(void *kvaddr);
+extern void kunmap_atomic_high(void *kvaddr);
extern void *kmap_atomic_pfn(unsigned long pfn);
extern struct page *kmap_atomic_to_page(void *ptr);
diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
index 63d74b47eee6..0aafbbbe651c 100644
--- a/arch/csky/mm/highmem.c
+++ b/arch/csky/mm/highmem.c
@@ -39,13 +39,13 @@ void *kmap_atomic_high(struct page *page)
}
EXPORT_SYMBOL(kmap_atomic_high);
-void __kunmap_atomic(void *kvaddr)
+void kunmap_atomic_high(void *kvaddr)
{
unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Thu, Apr 30, 2020 at 3:44 AM Daniel Vetter wrote: > > On Tue, Apr 28, 2020 at 2:46 PM Peter Collingbourne wrote: > > > > Render nodes are not just useful for devices supporting GPU hardware > > acceleration. Even on devices that only support dumb frame buffers, > > they are useful in situations where composition (using software > > rasterization) and KMS are done in different processes with buffer > > sharing being used to send frame buffers between them. This is the > > situation on Android, where surfaceflinger is the compositor and the > > composer HAL uses KMS to display the buffers. Thus it is beneficial > > to expose render nodes on all devices that support buffer sharing. > > > > Because all drivers that currently support render nodes also support > > buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark > > devices as supporting render nodes, so remove it and just rely on > > the presence of a prime_handle_to_fd function pointer to determine > > whether buffer sharing is supported. > > The idea behind render nodes is that you can freely pass these to > unpriviledged users, and nothing bad happens. That's why we have gpu > reset code in drivers, proper pagetables, and also (in at least the > solid drivers) ban code so that repeat offenders from userspace who > constantly submit endless batch buffers and funny stuff like that > can't DOS the gpu. > > Ofc in practice there's hw issues and fun stuff like that sometimes, > and driver bugs, and all that. But that's the aspiration. > > Now many of these display-only drivers need contiguous buffers, and > there's not endless amounts of that around. So if you allow random > clients to allocate buffers, they can easily exhaust that, and not > just upset the render side of the gpu, but essentially make it > impossible for a compositor to allocate more framebuffers. I don't > think that's a good idea. > > I know there's hw like vc4 which needs contiguous buffers for > everything, but that's kinda the places where aspiration falls a bit > short. > > So from that pov I'm a rather worried with handing out render rights > to everyone for these display-only buffers. It's not entirely > harmless. This doesn't feel like a contiguous-mem-specific concern to me. We don't have resource limits on renderer GPU nodes today, you can allocate memory there to fill up and DOS the system, and unless something changed since last time I was looking, we don't even tell the OOM killer about our allocations so they can kill the right app! (my compositor always got picked, in my experience) And, keep in mind what we're fixing at a system level here: the current workaround is you either get your compositor to hand you a GPU fd, at which point you can DOS the system, or you open the master node yourself and try to drop master before the compositor comes up, then DOS the system. "But there are access controls for the compositor or the card node!" you say: yes, but there are for render nodes too. I know my distro doesn't default to open access to /dev/dri/render* ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/6] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
because of excessive debouncing in hardware. Specifically there is no
way to disable the debouncing and for eDP debouncing hurts you because
HPD is just used for knowing when the panel is ready, not for
detecting physical plug events.
Currently the driver in Linux just assumes that nobody has HPD hooked
up. It relies on folks setting the "no-hpd" property in the panel
node to specify that HPD isn't hooked up and then the panel driver
using this to add some worst case delays when turning on the panel.
Apparently it's also useful to specify "no-hpd" in the bridge node so
that the bridge driver can make sure it's doing the right thing
without peeking into the panel [1]. This would be used if anyone ever
found it useful to implement support for the HW HPD pin on the bridge.
Let's add this property to the bindings.
NOTES:
- This is somewhat of a backward-incompatible change. All current
known users of ti-sn65dsi86 didn't have "no-hpd" specified in the
bridge node yet none of them had HPD hooked up. This worked because
the current Linux driver just assumed that HPD was never hooked up.
We could make it less incompatible by saying that for this bridge
it's assumed HPD isn't hooked up _unless_ a property is defined, but
"no-hpd" is much more standard and it's unlikely to matter unless
someone quickly goes and implements HPD in the driver.
- It is sensible to specify "no-hpd" at the bridge chip level and
specify "hpd-gpios" at the panel level. That would mean HPD is
hooked up to some other GPIO in the system, just not the hardware
HPD pin on the bridge chip.
[1] https://lore.kernel.org/r/20200417180819.ge5...@pendragon.ideasonboard.com
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Reviewed-by: Linus Walleij
---
Changes in v4:
- Tacked on "or is otherwise unusable." to description.
Changes in v3:
- useful implement => useful to implement
Changes in v2:
- ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2.
.../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
index 6d7d40ad45ac..75c4e8b8e4b7 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -28,6 +28,12 @@ properties:
maxItems: 1
description: GPIO specifier for GPIO1 pin on bridge (active low).
+ no-hpd:
+type: boolean
+description:
+ Set if the HPD line on the bridge isn't hooked up to anything or is
+ otherwise unusable.
+
vccio-supply:
description: A 1.8V supply that powers the digital IOs.
@@ -207,6 +213,8 @@ examples:
clocks = < RPMH_LN_BB_CLK2>;
clock-names = "refclk";
+no-hpd;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.26.2.526.g744177e7f7-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/6] arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza
We don't have the HPD line hooked up to the bridge chip. Add it as
suggested in the patch ("dt-bindings: drm/bridge: ti-sn65dsi86:
Document no-hpd").
NOTE: this patch isn't expected to have any effect but just keeps us
cleaner for the future. Currently the driver in Linux just assumes
that nobody has HPD hooked up. This change allows us to later
implement HPD support in the driver without messing up sdm845-cheza.
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- ("arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza") new for v2.
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 9070be43a309..5938f8b2aa2f 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -548,6 +548,8 @@ sn65dsi86_bridge: bridge@2d {
clocks = < RPMH_LN_BB_CLK2>;
clock-names = "refclk";
+ no-hpd;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.26.2.526.g744177e7f7-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
be used as GPIOs in a system. Each pin can be configured as input,
output, or a special function for the bridge chip. These are:
- GPIO1: SUSPEND Input
- GPIO2: DSIA VSYNC
- GPIO3: DSIA HSYNC or VSYNC
- GPIO4: PWM
Let's expose these pins as GPIOs. A few notes:
- Access to ti-sn65dsi86 is via i2c so we set "can_sleep".
- These pins can't be configured for IRQ.
- There are no programmable pulls or other fancy features.
- Keeping the bridge chip powered might be expensive. The driver is
setup such that if all used GPIOs are only inputs we'll power the
bridge chip on just long enough to read the GPIO and then power it
off again. Setting a GPIO as output will keep the bridge powered.
- If someone releases a GPIO we'll implicitly switch it to an input so
we no longer need to keep the bridge powered for it.
Because of all of the above limitations we just need to implement a
bare-bones GPIO driver. The device tree bindings already account for
this device being a GPIO controller so we only need the driver changes
for it.
NOTE: Despite the fact that these pins are nominally muxable I don't
believe it makes sense to expose them through the pinctrl interface as
well as the GPIO interface. The special functions are things that the
bridge chip driver itself would care about and it can just configure
the pins as needed.
Signed-off-by: Douglas Anderson
Cc: Linus Walleij
Cc: Bartosz Golaszewski
Reviewed-by: Stephen Boyd
---
Changes in v4:
- Don't include gpio.h
- Use gpiochip_get_data() instead of container_of() to get data.
- GPIOF_DIR_XXX => GPIO_LINE_DIRECTION_XXX
- Use Linus W's favorite syntax to read a bit from a bitfield.
- Define and use SN_GPIO_MUX_MASK.
- Add a comment about why we use a bitmap for gchip_output.
Changes in v3:
- Becaue => Because
- Add a kernel-doc to our pdata to clarify double-duty of gchip_output.
- More comments about how powering off affects us (get_dir, dir_input).
- Cleanup tail of ti_sn_setup_gpio_controller() to avoid one "return".
- Use a bitmap rather than rolling my own.
Changes in v2:
- ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs")
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 195 ++
1 file changed, 195 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 6ad688b320ae..1a125423eb07 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -4,9 +4,11 @@
* datasheet: http://www.ti.com/lit/ds/symlink/sn65dsi86.pdf
*/
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -54,6 +56,14 @@
#define BPP_18_RGBBIT(0)
#define SN_HPD_DISABLE_REG 0x5C
#define HPD_DISABLE BIT(0)
+#define SN_GPIO_IO_REG 0x5E
+#define SN_GPIO_INPUT_SHIFT 4
+#define SN_GPIO_OUTPUT_SHIFT 0
+#define SN_GPIO_CTRL_REG 0x5F
+#define SN_GPIO_MUX_INPUT 0
+#define SN_GPIO_MUX_OUTPUT1
+#define SN_GPIO_MUX_SPECIAL 2
+#define SN_GPIO_MUX_MASK 0x3
#define SN_AUX_WDATA_REG(x)(0x64 + (x))
#define SN_AUX_ADDR_19_16_REG 0x74
#define SN_AUX_ADDR_15_8_REG 0x75
@@ -88,6 +98,34 @@
#define SN_REGULATOR_SUPPLY_NUM4
+#define SN_NUM_GPIOS 4
+
+/**
+ * struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver.
+ * @dev: Pointer to our device.
+ * @regmap: Regmap for accessing i2c.
+ * @aux: Our aux channel.
+ * @bridge: Our bridge.
+ * @connector:Our connector.
+ * @debugfs: Used for managing our debugfs.
+ * @host_node:Remote DSI node.
+ * @dsi: Our MIPI DSI source.
+ * @refclk: Our reference clock.
+ * @panel:Our panel.
+ * @enable_gpio: The GPIO we toggle to enable the bridge.
+ * @supplies: Data for bulk enabling/disabling our regulators.
+ * @dp_lanes: Count of dp_lanes we're using.
+ *
+ * @gchip:If we expose our GPIOs, this is used.
+ * @gchip_output: A cache of whether we've set GPIOs to output. This
+ *serves double-duty of keeping track of the direction and
+ *also keeping track of whether we've incremented the
+ *pm_runtime reference count for this pin, which we do
+ *whenever a pin is configured as an output. This is a
+ *bitmap so we can do atomic ops on it without an extra
+ *lock so concurrent users of our 4 GPIOs don't stomp on
+ *each other's read-modify-write.
+ */
struct ti_sn_bridge {
struct device *dev;
struct regmap *regmap;
@@ -102,6 +140,9 @@ struct
[PATCH v4 3/6] drm/panel-simple: Support hpd-gpios for delaying prepare()
People use panel-simple when they have panels that are builtin to
their device. In these cases the HPD (Hot Plug Detect) signal isn't
really used for hotplugging devices but instead is used for power
sequencing. Panel timing diagrams (especially for eDP panels) usually
have the HPD signal in them and it acts as an indicator that the panel
is ready for us to talk to it.
Sometimes the HPD signal is hooked up to a normal GPIO on a system.
In this case we need to poll it in the correct place to know that the
panel is ready for us. In some system designs the right place for
this is panel-simple.
When adding this support, we'll account for the case that there might
be a circular dependency between panel-simple and the provider of the
GPIO. The case this was designed for was for the "ti-sn65dsi86"
bridge chip. If HPD is hooked up to one of the GPIOs provided by the
bridge chip then in our probe function we'll always get back
-EPROBE_DEFER. Let's handle this by allowing this GPIO to show up
late if we saw -EPROBE_DEFER during probe. NOTE: since the
gpio_get_optional() is used, if the "hpd-gpios" isn't there our
variable will just be NULL and we won't do anything in prepare().
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Reviewed-by: Linus Walleij
---
Changes in v4: None
Changes in v3:
- Remind how gpio_get_optional() works in the commit message.
Changes in v2:
- ("simple...hpd-gpios") is 1/2 of replacement for ("Allow...bridge GPIOs")
drivers/gpu/drm/panel/panel-simple.c | 53
1 file changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 3ad828eaefe1..f816e2aa29cd 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
#include
@@ -108,6 +109,7 @@ struct panel_simple {
struct i2c_adapter *ddc;
struct gpio_desc *enable_gpio;
+ struct gpio_desc *hpd_gpio;
struct drm_display_mode override_mode;
};
@@ -259,11 +261,37 @@ static int panel_simple_unprepare(struct drm_panel *panel)
return 0;
}
+static int panel_simple_get_hpd_gpio(struct device *dev,
+struct panel_simple *p, bool from_probe)
+{
+ int err;
+
+ p->hpd_gpio = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN);
+ if (IS_ERR(p->hpd_gpio)) {
+ err = PTR_ERR(p->hpd_gpio);
+
+ /*
+* If we're called from probe we won't consider '-EPROBE_DEFER'
+* to be an error--we'll leave the error code in "hpd_gpio".
+* When we try to use it we'll try again. This allows for
+* circular dependencies where the component providing the
+* hpd gpio needs the panel to init before probing.
+*/
+ if (err != -EPROBE_DEFER || !from_probe) {
+ dev_err(dev, "failed to get 'hpd' GPIO: %d\n", err);
+ return err;
+ }
+ }
+
+ return 0;
+}
+
static int panel_simple_prepare(struct drm_panel *panel)
{
struct panel_simple *p = to_panel_simple(panel);
unsigned int delay;
int err;
+ int hpd_asserted;
if (p->prepared)
return 0;
@@ -282,6 +310,26 @@ static int panel_simple_prepare(struct drm_panel *panel)
if (delay)
msleep(delay);
+ if (p->hpd_gpio) {
+ if (IS_ERR(p->hpd_gpio)) {
+ err = panel_simple_get_hpd_gpio(panel->dev, p, false);
+ if (err)
+ return err;
+ }
+
+ err = readx_poll_timeout(gpiod_get_value_cansleep, p->hpd_gpio,
+hpd_asserted, hpd_asserted,
+1000, 200);
+ if (hpd_asserted < 0)
+ err = hpd_asserted;
+
+ if (err) {
+ dev_err(panel->dev,
+ "error waiting for hpd GPIO: %d\n", err);
+ return err;
+ }
+ }
+
p->prepared = true;
return 0;
@@ -462,6 +510,11 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
panel->desc = desc;
panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
+ if (!panel->no_hpd) {
+ err = panel_simple_get_hpd_gpio(dev, panel, true);
+ if (err)
+ return err;
+ }
panel->supply = devm_regulator_get(dev, "power");
if (IS_ERR(panel->supply))
--
2.26.2.526.g744177e7f7-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/6] dt-bindings: display: Add hpd-gpios to panel-common bindings
In the cases where there is no connector in a system there's no great
place to put "hpd-gpios". As per discussion [1] the best place to put
it is in the panel. Add this to the device tree bindings.
[1] https://lore.kernel.org/r/20200417180819.ge5...@pendragon.ideasonboard.com
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Reviewed-by: Linus Walleij
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- ("dt-bindings: display: Add hpd-gpios to panel-common...") new for v2
.../devicetree/bindings/display/panel/panel-common.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
index ed051ba12084..e9a04a3a4f5f 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
@@ -96,6 +96,12 @@ properties:
(hot plug detect) signal, but the signal isn't hooked up so we should
hardcode the max delay from the panel spec when powering up the panel.
+ hpd-gpios:
+maxItems: 1
+description:
+ If Hot Plug Detect (HPD) is connected to a GPIO in the system rather
+ than a dedicated HPD pin the pin can be specified here.
+
# Control I/Os
# Many display panels can be controlled through pins driven by GPIOs. The
nature
--
2.26.2.526.g744177e7f7-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect
As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86:
Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is
kinda useless, at least for embedded DisplayPort (eDP). However,
despite the fact that the actual HPD pin on the bridge is mostly
useless for eDP, the concept of HPD for eDP still makes sense. It
allows us to optimize out a hardcoded delay that many panels need if
HPD isn't hooked up. Panel timing diagrams show HPD as one of the
events to measure timing from and we have to assume the worst case if
we can't actually read HPD.
One way to use HPD for eDP without using the mostly useless HPD pin on
ti-sn65dsi86 is to route the panel's HPD somewhere else in the system,
like to a GPIO. This works great because eDP panels aren't physically
hotplugged. That means the debouncing logic that caused us problems
wasn't really needed and a raw GPIO works great.
As per the above, a smart board designer would realize the value of
HPD and choose to route it to a GPIO somewhere on the board to avoid
the silly sn65dsi86 debouncing. While said "smart designer" could
theoretically route HPD anywhere on the board, a really smart designer
would realize that there are several GPIOs on the bridge itself that
are nearly useless for anything but this purpose and route HPD to one
of those.
This series of patches is intended to allow the scenario described
above.
This patch has been tested on a board that is not yet mainline. On
the hardware I have:
- Panel spec says HPD could take up to 200 ms to come up, so without
HPD hooked up we need to delay 200 ms.
- On my board the panel is powered by the same rail as the
touchscreen. By chance of probe order the touchscreen comes up
first. This means by the time we check HPD in ti_sn_bridge_enable()
it's already up. Thus we can use the panel on 200 ms earlier.
- If I measure HPD on this pane it comes up ~56 ms after the panel is
powered. This means I can save 144 ms of delay.
Side effects (though not main goals) of this series are:
- ti-sn65dsi86 GPIOs are now exported in Linux.
- ti-sn65dsi86 bindings are converted to yaml.
- Common panel bindings now have "hpd-gpios" listed.
- The simple-panel driver in Linux can delay in prepare based on
"hpd-gpios"
- ti-sn65dsi86 bindings (and current user) now specifies "no-hpd"
if HPD isn't hooked up.
Changes in v4:
- Don't include gpio.h
- Use gpiochip_get_data() instead of container_of() to get data.
- GPIOF_DIR_XXX => GPIO_LINE_DIRECTION_XXX
- Use Linus W's favorite syntax to read a bit from a bitfield.
- Define and use SN_GPIO_MUX_MASK.
- Add a comment about why we use a bitmap for gchip_output.
- Tacked on "or is otherwise unusable." to description.
Changes in v3:
- Becaue => Because
- Add a kernel-doc to our pdata to clarify double-duty of gchip_output.
- More comments about how powering off affects us (get_dir, dir_input).
- Cleanup tail of ti_sn_setup_gpio_controller() to avoid one "return".
- Use a bitmap rather than rolling my own.
- Remind how gpio_get_optional() works in the commit message.
- useful implement => useful to implement
Changes in v2:
- ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs")
- ("dt-bindings: display: Add hpd-gpios to panel-common...") new for v2
- ("simple...hpd-gpios") is 1/2 of replacement for ("Allow...bridge GPIOs")
- specification => specifier.
- power up => power.
- Added back missing suspend-gpios.
- data-lanes and lane-polarities are are the right place now.
- endpoints don't need to be patternProperties.
- Specified more details for data-lanes and lane-polarities.
- Added old example back in, fixing bugs in it.
- Example i2c bus is just called "i2c", not "i2c1" now.
- ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2.
- ("arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza") new for v2.
Douglas Anderson (6):
drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
dt-bindings: display: Add hpd-gpios to panel-common bindings
drm/panel-simple: Support hpd-gpios for delaying prepare()
dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml
dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza
.../bindings/display/bridge/ti,sn65dsi86.txt | 87 --
.../bindings/display/bridge/ti,sn65dsi86.yaml | 287 ++
.../bindings/display/panel/panel-common.yaml | 6 +
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi| 2 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 195
drivers/gpu/drm/panel/panel-simple.c | 53
6 files changed, 543 insertions(+), 87 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
--
2.26.2.526.g744177e7f7-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[PATCH v4 4/6] dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml
This moves the bindings over, based a lot on toshiba,tc358768.yaml.
Unless there's someone known to be better, I've set the maintainer in
the yaml as the first person to submit bindings.
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- specification => specifier.
- power up => power.
- Added back missing suspend-gpios.
- data-lanes and lane-polarities are are the right place now.
- endpoints don't need to be patternProperties.
- Specified more details for data-lanes and lane-polarities.
- Added old example back in, fixing bugs in it.
- Example i2c bus is just called "i2c", not "i2c1" now.
.../bindings/display/bridge/ti,sn65dsi86.txt | 87 --
.../bindings/display/bridge/ti,sn65dsi86.yaml | 279 ++
2 files changed, 279 insertions(+), 87 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
deleted file mode 100644
index 8ec4a7f2623a..
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-SN65DSI86 DSI to eDP bridge chip
-
-
-This is the binding for Texas Instruments SN65DSI86 bridge.
-http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
-
-Required properties:
-- compatible: Must be "ti,sn65dsi86"
-- reg: i2c address of the chip, 0x2d as per datasheet
-- enable-gpios: gpio specification for bridge_en pin (active high)
-
-- vccio-supply: A 1.8V supply that powers up the digital IOs.
-- vpll-supply: A 1.8V supply that powers up the displayport PLL.
-- vcca-supply: A 1.2V supply that powers up the analog circuits.
-- vcc-supply: A 1.2V supply that powers up the digital core.
-
-Optional properties:
-- interrupts-extended: Specifier for the SN65DSI86 interrupt line.
-
-- gpio-controller: Marks the device has a GPIO controller.
-- #gpio-cells: Should be two. The first cell is the pin number and
- the second cell is used to specify flags.
- See ../../gpio/gpio.txt for more information.
-- #pwm-cells : Should be one. See ../../pwm/pwm.yaml for description of
- the cell formats.
-
-- clock-names: should be "refclk"
-- clocks: Specification for input reference clock. The reference
- clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
-
-- data-lanes: See ../../media/video-interface.txt
-- lane-polarities: See ../../media/video-interface.txt
-
-- suspend-gpios: specification for GPIO1 pin on bridge (active low)
-
-Required nodes:
-This device has two video ports. Their connections are modelled using the
-OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for DSI input
-- Video port 1 for eDP output
-
-Example
-
-edp-bridge@2d {
- compatible = "ti,sn65dsi86";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x2d>;
-
- enable-gpios = < 33 GPIO_ACTIVE_HIGH>;
- suspend-gpios = < 34 GPIO_ACTIVE_LOW>;
-
- interrupts-extended = < 4 IRQ_TYPE_EDGE_FALLING>;
-
- vccio-supply = <_l17>;
- vcca-supply = <_l6>;
- vpll-supply = <_l17>;
- vcc-supply = <_l6>;
-
- clock-names = "refclk";
- clocks = <_refclk>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- edp_bridge_in: endpoint {
- remote-endpoint = <_out>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- edp_bridge_out: endpoint {
- data-lanes = <2 1 3 0>;
- lane-polarities = <0 1 0 1>;
- remote-endpoint = <_panel_in>;
- };
- };
- };
-}
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
new file mode 100644
index ..6d7d40ad45ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -0,0 +1,279 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi86.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SN65DSI86 DSI to eDP bridge chip
+
+maintainers:
+ - Sandeep Panda
+
+description: |
+ The Texas Instruments SN65DSI86 bridge takes MIPI DSI in and outputs eDP.
+
http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
+
[PATCH v6 2/3] drm: Add support for the LogiCVC display controller
Introduces a driver for the LogiCVC display controller, a programmable logic controller optimized for use in Xilinx Zynq-7000 SoCs and other Xilinx FPGAs. The controller is mostly configured at logic synthesis time so only a subset of configuration is left for the driver to handle. The following features are implemented and tested: - LVDS 4-bit interface; - RGB565 pixel formats; - Multiple layers and hardware composition; - Layer-wide alpha mode; The following features are implemented but untested: - Other RGB pixel formats; - Layer framebuffer configuration for version 4; - Lowest-layer used as background color; - Per-pixel alpha mode. The following features are not implemented: - YUV pixel formats; - DVI, LVDS 3-bit, ITU656 and camera link interfaces; - External parallel input for layer; - Color-keying; - LUT-based alpha modes. Additional implementation-specific notes: - Panels are only enabled after the first page flip to avoid flashing a white screen. - Depth used in context of the LogiCVC driver only counts color components to match the definition of the synthesis parameters. Support is implemented for both version 3 and 4 of the controller. With version 3, framebuffers are stored in a dedicated contiguous memory area, with a base address hardcoded for each layer. This requires using a dedicated CMA pool registered at the base address and tweaking a few offset-related registers to try to use any buffer allocated from the pool. This is done on a best-effort basis to have the hardware cope with the DRM framebuffer allocation model and there is no guarantee that each buffer allocated by GEM CMA can be used for any layer. In particular, buffers allocated below the base address for a layer are guaranteed not to be configurable for that layer. See the implementation of logicvc_layer_buffer_find_setup for specifics. Version 4 allows configuring each buffer address directly, which guarantees that any buffer can be configured. Signed-off-by: Paul Kocialkowski Reviewed-by: Maxime Ripard --- MAINTAINERS | 6 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/logicvc/Kconfig | 9 + drivers/gpu/drm/logicvc/Makefile| 4 + drivers/gpu/drm/logicvc/logicvc_crtc.c | 270 + drivers/gpu/drm/logicvc/logicvc_crtc.h | 21 + drivers/gpu/drm/logicvc/logicvc_drm.c | 465 +++ drivers/gpu/drm/logicvc/logicvc_drm.h | 64 ++ drivers/gpu/drm/logicvc/logicvc_interface.c | 238 drivers/gpu/drm/logicvc/logicvc_interface.h | 30 + drivers/gpu/drm/logicvc/logicvc_layer.c | 609 drivers/gpu/drm/logicvc/logicvc_layer.h | 64 ++ drivers/gpu/drm/logicvc/logicvc_mode.c | 103 drivers/gpu/drm/logicvc/logicvc_mode.h | 15 + drivers/gpu/drm/logicvc/logicvc_of.c| 205 +++ drivers/gpu/drm/logicvc/logicvc_of.h| 28 + drivers/gpu/drm/logicvc/logicvc_regs.h | 88 +++ 18 files changed, insertions(+) create mode 100644 drivers/gpu/drm/logicvc/Kconfig create mode 100644 drivers/gpu/drm/logicvc/Makefile create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_regs.h diff --git a/MAINTAINERS b/MAINTAINERS index 938316092634..b8c0614d4c31 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5334,6 +5334,12 @@ S: Orphan / Obsolete F: drivers/gpu/drm/i810/ F: include/uapi/drm/i810_drm.h +DRM DRIVER FOR LOGICVC DISPLAY CONTROLLER +M: Paul Kocialkowski +T: git git://anongit.freedesktop.org/drm/drm-misc +S: Supported +F: drivers/gpu/drm/logicvc/ + DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS S: Orphan / Obsolete F: drivers/gpu/drm/mga/ diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 4f4e7fa001c1..d3b6ef4bd048 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -358,6 +358,8 @@ source "drivers/gpu/drm/arc/Kconfig" source "drivers/gpu/drm/hisilicon/Kconfig" +source "drivers/gpu/drm/logicvc/Kconfig" + source "drivers/gpu/drm/mediatek/Kconfig" source "drivers/gpu/drm/zte/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c0e5a7e5953..534925ff85e2 100644 ---
[PATCH v6 0/3] drm: LogiCVC display controller support
This series introduces support for the LogiCVC display controller. The controller is a bit unusual since it is usually loaded as programmable logic on Xilinx FPGAs or Zynq-7000 SoCs. More details are presented on the main commit for the driver. More information about the controller is available on the dedicated web page: https://www.logicbricks.com/Products/logiCVC-ML.aspx Changes since v5: - Subclass DRM device and use devm_drm_dev_alloc for allocation; - Removed call to drm_mode_config_cleanup (done automatically with devm); - Some related code cleanups; - Bring back not-for-merge patch adding colorkey support. Changes since v4: - Updated to internal DRM API changes (rebased on drm-misc-next); - Added Kconfig dependency on OF; - Added MAINTAINERS entry; - Used drm_err and dev_err instead of DRM_ERROR where possible; - Various cosmetic changes. Changes since v3: - Rebased on latest drm-misc; - Improved event lock wrapping; - Added collect tag; - Added color-key support patch (not for merge, for reference only). Changes since v2: - Fixed and slightly improved dt schema. Changes since v1: - Switched dt bindings documentation to dt schema; - Described more possible dt parameters; - Added support for the lvds-3bit interface; - Added support for grabbing syscon regmap from parent node; - Removed layers count property and count layers child nodes instead. Cheers! Paul Kocialkowski (3): dt-bindings: display: Document the Xylon LogiCVC display controller drm: Add support for the LogiCVC display controller NOTFORMERGE: drm/logicvc: Add plane colorkey support .../display/xylon,logicvc-display.yaml| 313 MAINTAINERS | 6 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/logicvc/Kconfig | 9 + drivers/gpu/drm/logicvc/Makefile | 4 + drivers/gpu/drm/logicvc/logicvc_crtc.c| 270 +++ drivers/gpu/drm/logicvc/logicvc_crtc.h| 21 + drivers/gpu/drm/logicvc/logicvc_drm.c | 470 +++ drivers/gpu/drm/logicvc/logicvc_drm.h | 67 ++ drivers/gpu/drm/logicvc/logicvc_interface.c | 238 ++ drivers/gpu/drm/logicvc/logicvc_interface.h | 30 + drivers/gpu/drm/logicvc/logicvc_layer.c | 744 ++ drivers/gpu/drm/logicvc/logicvc_layer.h | 71 ++ drivers/gpu/drm/logicvc/logicvc_mode.c| 103 +++ drivers/gpu/drm/logicvc/logicvc_mode.h| 15 + drivers/gpu/drm/logicvc/logicvc_of.c | 205 + drivers/gpu/drm/logicvc/logicvc_of.h | 28 + drivers/gpu/drm/logicvc/logicvc_regs.h| 88 +++ 19 files changed, 2685 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml create mode 100644 drivers/gpu/drm/logicvc/Kconfig create mode 100644 drivers/gpu/drm/logicvc/Makefile create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_regs.h -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/3] NOTFORMERGE: drm/logicvc: Add plane colorkey support
---
drivers/gpu/drm/logicvc/logicvc_drm.h | 3 +
drivers/gpu/drm/logicvc/logicvc_layer.c | 143 +++-
drivers/gpu/drm/logicvc/logicvc_layer.h | 7 ++
3 files changed, 149 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.h
b/drivers/gpu/drm/logicvc/logicvc_drm.h
index 68bbac6c4ab9..d69a686ab0f1 100644
--- a/drivers/gpu/drm/logicvc/logicvc_drm.h
+++ b/drivers/gpu/drm/logicvc/logicvc_drm.h
@@ -59,6 +59,9 @@ struct logicvc_drm {
struct list_head layers_list;
struct logicvc_crtc *crtc;
struct logicvc_interface *interface;
+
+ struct drm_property *colorkey_enabled_property;
+ struct drm_property *colorkey_value_property;
};
#endif
diff --git a/drivers/gpu/drm/logicvc/logicvc_layer.c
b/drivers/gpu/drm/logicvc/logicvc_layer.c
index 98c3c70b37b0..6a8254103145 100644
--- a/drivers/gpu/drm/logicvc/logicvc_layer.c
+++ b/drivers/gpu/drm/logicvc/logicvc_layer.c
@@ -23,6 +23,8 @@
#define logicvc_layer(p) \
container_of(p, struct logicvc_layer, drm_plane)
+#define logicvc_layer_state(p) \
+ container_of(p, struct logicvc_layer_state, drm_plane_state)
static uint32_t logicvc_layer_formats_rgb16[] = {
DRM_FORMAT_RGB565,
@@ -135,6 +137,7 @@ static void logicvc_plane_atomic_update(struct drm_plane
*drm_plane,
struct logicvc_layer *layer = logicvc_layer(drm_plane);
struct logicvc_drm *logicvc = logicvc_drm(drm_plane->dev);
struct drm_plane_state *state = drm_plane->state;
+ struct logicvc_layer_state *layer_state = logicvc_layer_state(state);
struct drm_crtc *drm_crtc = >crtc->drm_crtc;
struct drm_display_mode *mode = _crtc->state->adjusted_mode;
struct drm_framebuffer *fb = state->fb;
@@ -210,6 +213,15 @@ static void logicvc_plane_atomic_update(struct drm_plane
*drm_plane,
alpha);
}
+ /* Layer colorkey */
+
+ if (layer_state->colorkey_enabled) {
+ reg = layer_state->colorkey_value;
+
+ regmap_write(logicvc->regmap,
+LOGICVC_LAYER_COLOR_KEY_REG(index), reg);
+ }
+
/* Layer control */
reg = LOGICVC_LAYER_CTRL_ENABLE;
@@ -217,7 +229,8 @@ static void logicvc_plane_atomic_update(struct drm_plane
*drm_plane,
if (logicvc_layer_format_inverted(fb->format->format))
reg |= LOGICVC_LAYER_CTRL_PIXEL_FORMAT_INVERT;
- reg |= LOGICVC_LAYER_CTRL_COLOR_KEY_DISABLE;
+ if (!layer_state->colorkey_enabled)
+ reg |= LOGICVC_LAYER_CTRL_COLOR_KEY_DISABLE;
regmap_write(logicvc->regmap, LOGICVC_LAYER_CTRL_REG(index), reg);
}
@@ -238,13 +251,108 @@ static struct drm_plane_helper_funcs
logicvc_plane_helper_funcs = {
.atomic_disable = logicvc_plane_atomic_disable,
};
+static void logicvc_plane_reset(struct drm_plane *drm_plane)
+{
+ struct logicvc_drm *logicvc = logicvc_drm(drm_plane->dev);
+ struct device *dev = logicvc->drm_dev.dev;
+ struct logicvc_layer_state *layer_state;
+
+ if (drm_plane->state) {
+ layer_state = logicvc_layer_state(drm_plane->state);
+ __drm_atomic_helper_plane_destroy_state(drm_plane->state);
+ devm_kfree(dev, layer_state);
+ drm_plane->state = NULL;
+ }
+
+ layer_state = devm_kzalloc(dev, sizeof(*layer_state), GFP_KERNEL);
+ if (!layer_state)
+ return;
+
+ __drm_atomic_helper_plane_reset(drm_plane,
+ _state->drm_plane_state);
+}
+
+static struct drm_plane_state *logicvc_plane_atomic_duplicate_state(struct
drm_plane *drm_plane)
+{
+ struct logicvc_drm *logicvc = logicvc_drm(drm_plane->dev);
+ struct device *dev = logicvc->drm_dev.dev;
+ struct logicvc_layer_state *layer_state_current;
+ struct logicvc_layer_state *layer_state;
+
+ if (WARN_ON(!drm_plane->state))
+ return NULL;
+
+ layer_state_current = logicvc_layer_state(drm_plane->state);
+ layer_state = devm_kzalloc(dev, sizeof(*layer_state), GFP_KERNEL);
+ if (!layer_state)
+ return NULL;
+
+ layer_state->colorkey_enabled = layer_state_current->colorkey_enabled;
+ layer_state->colorkey_value = layer_state_current->colorkey_value;
+
+ __drm_atomic_helper_plane_duplicate_state(drm_plane,
+
_state->drm_plane_state);
+
+ return _state->drm_plane_state;
+}
+
+static void logicvc_plane_destroy_state(struct drm_plane *drm_plane,
+ struct drm_plane_state *state)
+{
+ struct logicvc_drm *logicvc = logicvc_drm(drm_plane->dev);
+ struct device *dev = logicvc->drm_dev.dev;
+ struct logicvc_layer_state *layer_state = logicvc_layer_state(state);
+
+ __drm_atomic_helper_plane_destroy_state(_state->drm_plane_state);
+
+
[PATCH v6 1/3] dt-bindings: display: Document the Xylon LogiCVC display controller
The Xylon LogiCVC is a display controller implemented as programmable logic in Xilinx FPGAs. Signed-off-by: Paul Kocialkowski Acked-by: Rob Herring --- .../display/xylon,logicvc-display.yaml| 313 ++ 1 file changed, 313 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml diff --git a/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml new file mode 100644 index ..817fcced764f --- /dev/null +++ b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml @@ -0,0 +1,313 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Bootlin +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/display/xylon,logicvc-display.yaml#; +$schema: "http://devicetree.org/meta-schemas/core.yaml#; + +title: Xylon LogiCVC display controller + +maintainers: + - Paul Kocialkowski + +description: | + The Xylon LogiCVC is a display controller that supports multiple layers. + It is usually implemented as programmable logic and was optimized for use + with Xilinx Zynq-7000 SoCs and Xilinx FPGAs. + + Because the controller is intended for use in a FPGA, most of the + configuration of the controller takes place at logic configuration bitstream + synthesis time. As a result, many of the device-tree bindings are meant to + reflect the synthesis configuration and must not be configured differently. + Matching synthesis parameters are provided when applicable. + + Layers are declared in the "layers" sub-node and have dedicated configuration. + In version 3 of the controller, each layer has fixed memory offset and address + starting from the video memory base address for its framebuffer. In version 4, + framebuffers are configured with a direct memory address instead. + +properties: + compatible: +enum: + - xylon,logicvc-3.02.a-display + - xylon,logicvc-4.01.a-display + + reg: +maxItems: 1 + + clocks: +minItems: 1 +maxItems: 4 + + clock-names: +minItems: 1 +maxItems: 4 +items: + # vclk is required and must be provided as first item. + - const: vclk + # Other clocks are optional and can be provided in any order. + - enum: + - vclk2 + - lvdsclk + - lvdsclkn + - enum: + - vclk2 + - lvdsclk + - lvdsclkn + - enum: + - vclk2 + - lvdsclk + - lvdsclkn + + interrupts: +maxItems: 1 + + memory-region: +maxItems: 1 + + xylon,display-interface: +enum: + # Parallel RGB interface (C_DISPLAY_INTERFACE == 0) + - parallel-rgb + # ITU-T BR656 interface (C_DISPLAY_INTERFACE == 1) + - bt656 + # 4-bit LVDS interface (C_DISPLAY_INTERFACE == 2) + - lvds-4bits + # 3-bit LVDS interface (C_DISPLAY_INTERFACE == 4) + - lvds-3bits + # DVI interface (C_DISPLAY_INTERFACE == 5) + - dvi +description: Display output interface (C_DISPLAY_INTERFACE). + + xylon,display-colorspace: +enum: + # RGB colorspace (C_DISPLAY_COLOR_SPACE == 0) + - rgb + # YUV 4:2:2 colorspace (C_DISPLAY_COLOR_SPACE == 1) + - yuv422 + # YUV 4:4:4 colorspace (C_DISPLAY_COLOR_SPACE == 2) + - yuv444 +description: Display output colorspace (C_DISPLAY_COLOR_SPACE). + + xylon,display-depth: +$ref: "/schemas/types.yaml#/definitions/uint32" +description: Display output depth (C_PIXEL_DATA_WIDTH). + + xylon,row-stride: +$ref: "/schemas/types.yaml#/definitions/uint32" +description: Fixed number of pixels in a framebuffer row (C_ROW_STRIDE). + + xylon,syscon: +$ref: /schemas/types.yaml#/definitions/phandle +description: | + Syscon phandle representing the top-level logicvc instance, useful when + the parent node is not the top-level logicvc instance. + + xylon,dithering: +$ref: "/schemas/types.yaml#/definitions/flag" +description: Dithering module is enabled (C_XCOLOR) + + xylon,background-layer: +$ref: "/schemas/types.yaml#/definitions/flag" +description: | + The last layer is used to display a black background (C_USE_BACKGROUND). + The layer must still be registered. + + xylon,layers-configurable: + $ref: "/schemas/types.yaml#/definitions/flag" + description: | + Configuration of layers' size, position and offset is enabled + (C_USE_SIZE_POSITION). + + layers: +type: object + +properties: + "#address-cells": +const: 1 + + "#size-cells": +const: 0 + +patternProperties: + "^layer@[0-9]+$": +type: object + +properties: + reg: +maxItems: 1 + + xylon,layer-depth: +$ref: "/schemas/types.yaml#/definitions/uint32" +description: Layer depth (C_LAYER_X_DATA_WIDTH). + + xylon,layer-colorspace: +enum: + # RGB
Re: [PATCH v5 2/2] drm: Add support for the LogiCVC display controller
Hi Daniel, On Fri 03 Apr 20, 13:04, Daniel Vetter wrote: > On Fri, Apr 03, 2020 at 11:36:17AM +0200, Paul Kocialkowski wrote: > > Introduces a driver for the LogiCVC display controller, a programmable > > logic controller optimized for use in Xilinx Zynq-7000 SoCs and other > > Xilinx FPGAs. The controller is mostly configured at logic synthesis > > time so only a subset of configuration is left for the driver to > > handle. > > > > The following features are implemented and tested: > > - LVDS 4-bit interface; > > - RGB565 pixel formats; > > - Multiple layers and hardware composition; > > - Layer-wide alpha mode; > > > > The following features are implemented but untested: > > - Other RGB pixel formats; > > - Layer framebuffer configuration for version 4; > > - Lowest-layer used as background color; > > - Per-pixel alpha mode. > > > > The following features are not implemented: > > - YUV pixel formats; > > - DVI, LVDS 3-bit, ITU656 and camera link interfaces; > > - External parallel input for layer; > > - Color-keying; > > - LUT-based alpha modes. > > > > Additional implementation-specific notes: > > - Panels are only enabled after the first page flip to avoid flashing a > > white screen. > > - Depth used in context of the LogiCVC driver only counts color components > > to match the definition of the synthesis parameters. > > > > Support is implemented for both version 3 and 4 of the controller. > > > > With version 3, framebuffers are stored in a dedicated contiguous > > memory area, with a base address hardcoded for each layer. This requires > > using a dedicated CMA pool registered at the base address and tweaking a > > few offset-related registers to try to use any buffer allocated from > > the pool. This is done on a best-effort basis to have the hardware cope > > with the DRM framebuffer allocation model and there is no guarantee > > that each buffer allocated by GEM CMA can be used for any layer. > > In particular, buffers allocated below the base address for a layer are > > guaranteed not to be configurable for that layer. See the implementation of > > logicvc_layer_buffer_find_setup for specifics. > > > > Version 4 allows configuring each buffer address directly, which > > guarantees that any buffer can be configured. > > > > Signed-off-by: Paul Kocialkowski > > Reviewed-by: Maxime Ripard > > Just a few comments on stuff I've spotted since I'm working in this area. Thanks for the review (and the devm_drm_dev_alloc series)! I'm preparing a new version taking in account your comments. However, I didn't find a suitable panel connector wrapper: all I see is a wrapper for the bridge + panel use case. Cheers, Paul > > --- > > MAINTAINERS | 6 + > > drivers/gpu/drm/Kconfig | 2 + > > drivers/gpu/drm/Makefile| 1 + > > drivers/gpu/drm/logicvc/Kconfig | 9 + > > drivers/gpu/drm/logicvc/Makefile| 4 + > > drivers/gpu/drm/logicvc/logicvc_crtc.c | 272 + > > drivers/gpu/drm/logicvc/logicvc_crtc.h | 23 + > > drivers/gpu/drm/logicvc/logicvc_drm.c | 471 +++ > > drivers/gpu/drm/logicvc/logicvc_drm.h | 60 ++ > > drivers/gpu/drm/logicvc/logicvc_interface.c | 240 > > drivers/gpu/drm/logicvc/logicvc_interface.h | 32 ++ > > drivers/gpu/drm/logicvc/logicvc_layer.c | 603 > > drivers/gpu/drm/logicvc/logicvc_layer.h | 65 +++ > > drivers/gpu/drm/logicvc/logicvc_mode.c | 104 > > drivers/gpu/drm/logicvc/logicvc_mode.h | 15 + > > drivers/gpu/drm/logicvc/logicvc_of.c| 205 +++ > > drivers/gpu/drm/logicvc/logicvc_of.h| 28 + > > drivers/gpu/drm/logicvc/logicvc_regs.h | 88 +++ > > 18 files changed, 2228 insertions(+) > > create mode 100644 drivers/gpu/drm/logicvc/Kconfig > > create mode 100644 drivers/gpu/drm/logicvc/Makefile > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.c > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.h > > create mode 100644 drivers/gpu/drm/logicvc/logicvc_regs.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index aff76a779cfe..531128065d46 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5307,6 +5307,12 @@ S: Orphan / Obsolete > > F: drivers/gpu/drm/i810/ > > F:
RE: [RFC PATCH 1/2] dt-bindings: display: xlnx: Add Xilinx DSI TX subsystem bindings
Hi Sam, thanks for your comments.
>-Original Message-
>From: Sam Ravnborg
>Sent: Sunday, April 26, 2020 1:59 AM
>To: Venkateshwar Rao Gannavarapu
>Cc: Hyun Kwon ; laurent.pinch...@ideasonboard.com; dri-
>de...@lists.freedesktop.org; Sandip Kothari ;
>airl...@linux.ie; linux-ker...@vger.kernel.org; Venkateshwar Rao Gannavarapu
>
>Subject: Re: [RFC PATCH 1/2] dt-bindings: display: xlnx: Add Xilinx DSI TX
>subsystem bindings
>
>Hi Venkateshwar
>
>On Tue, Apr 21, 2020 at 02:50:55AM +0530, Venkateshwar Rao Gannavarapu
>wrote:
>> This add a dt binding for Xilinx DSI TX subsystem.
>>
>> The Xilinx MIPI DSI (Display serial interface) Transmitter Subsystem
>> implements the Mobile Industry Processor Interface (MIPI) based
>> display interface. It supports the interface with the programmable logic
>(FPGA).
>>
>> Signed-off-by: Venkateshwar Rao Gannavarapu
>>
>> ---
>> .../devicetree/bindings/display/xlnx/xlnx,dsi.txt | 68
>> ++
>
>Sorry, but new bindings in DT Schema format (.yaml) please.
>We are working on migrating all bindings to DT Schema and do not want to add
>new bindings in the old format.
>
I will address bindings in YAML format in V2 patch.
>
>> 1 file changed, 68 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/xlnx/xlnx,dsi.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/xlnx/xlnx,dsi.txt
>> b/Documentation/devicetree/bindings/display/xlnx/xlnx,dsi.txt
>> new file mode 100644
>> index 000..ef69729
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,dsi.txt
>> @@ -0,0 +1,68 @@
>> +Device-Tree bindings for Xilinx MIPI DSI Tx IP core
>> +
>> +The IP core supports transmission of video data in MIPI DSI protocol.
>> +
>> +Required properties:
>> + - compatible: Should be "xlnx-dsi".
>> + - reg: physical base address and length of the registers set for the
>> device.
>> + - xlnx,dsi-num-lanes: Possible number of DSI lanes for the Tx controller.
>> + The values should be 1, 2, 3 or 4. Based on xlnx,dsi-num-lanes and
>> + line rate for the MIPI D-PHY core in Mbps, the AXI4-stream received by
>> + Xilinx MIPI DSI Tx IP core adds markers as per DSI protocol and the
>> packet
>> + thus framed is convered to serial data by MIPI D-PHY core. Please refer
>> + Xilinx pg238 for more details. This value should be equal to the number
>> + of lanes supported by the connected DSI panel. Panel has to support this
>> + value or has to be programmed to the same value that DSI Tx controller is
>> + configured to.
>> + - xlnx,dsi-datatype: Color format. The value should be one of
>> +"MIPI_DSI_FMT_RGB888",
>> + "MIPI_DSI_FMT_RGB666", "MIPI_DSI_FMT_RGB666_PACKED" or
>"MIPI_DSI_FMT_RGB565".
>> + - #address-cells, #size-cells: should be set respectively to <1> and <0>
>> + according to DSI host bindings (see MIPI DSI bindings [1])
>> + - clock-names: Must contain "s_axis_aclk" and "dphy_clk_200M" in same
>order as
>> + clocks listed in clocks property.
>> + - clocks: List of phandles to Video and 200Mhz DPHY clocks.
>> + - port: Logical block can be used / connected independently with
>> + external device. In the display controller port nodes, topology
>> + for entire pipeline should be described using the DT bindings defined in
>> + Documentation/devicetree/bindings/graph.txt.
>
>> + - simple_panel: The subnode for connected panel. This represents the
>> + DSI peripheral connected to the DSI host node. Please refer to
>> + Documentation/devicetree/bindings/display/mipi-dsi-bus.txt. The
>> + simple-panel driver has auo,b101uan01 panel timing parameters added
>along
>> + with other existing panels. DSI driver derive the required Tx IP
>> controller
>> + timing values from the panel timing parameters.A
>Please always use either a port or a ports node.
>
OK.
> Sam
>
>> +
>> +Required simple_panel properties:
>> + - compatible: Value should be one of the panel names in
>> + Documentation/devicetree/bindings/display/panel/. e.g. "auo,b101uan01".
>> + For available panel compatible strings, please refer to bindings in
>> + Documentation/devicetree/bindings/display/panel/
>> +
>> +Optional properties:
>> + - xlnx,dsi-cmd-mode: denotes command mode enable.
>> +
>> +[1]: Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
>> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +Example:
>> +
>> + mipi_dsi_tx_subsystem@8000 {
>> + compatible = "xlnx,dsi";
>> + reg = <0x0 0x8000 0x0 0x1>;
>> + xlnx,dsi-num-lanes = <4>;
>> + xlnx,dsi-data-type = ;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + clock-names = "dphy_clk_200M", "s_axis_aclk";
>> + clocks = <_clk_0>, <_clk_1>;
>> + encoder_dsi_port: port@0 {
>> + reg = <0>;
>> + dsi_encoder: endpoint {
>> +
Re: [PATCH] drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers
On Thu, Apr 30, 2020 at 5:38 PM Sean Paul wrote:
>
> On Wed, Apr 29, 2020 at 4:57 AM Jani Nikula
> wrote:
> >
> > On Tue, 28 Apr 2020, Michal Orzel wrote:
> > > As suggested by the TODO list for the kernel DRM subsystem, replace
> > > the deprecated functions that take/drop modeset locks with new helpers.
> > >
> > > Signed-off-by: Michal Orzel
> > > ---
> > > drivers/gpu/drm/drm_mode_object.c | 10 ++
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > > b/drivers/gpu/drm/drm_mode_object.c
> > > index 35c2719..901b078 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -402,12 +402,13 @@ int drm_mode_obj_get_properties_ioctl(struct
> > > drm_device *dev, void *data,
> > > {
> > > struct drm_mode_obj_get_properties *arg = data;
> > > struct drm_mode_object *obj;
> > > + struct drm_modeset_acquire_ctx ctx;
> > > int ret = 0;
> > >
> > > if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > > return -EOPNOTSUPP;
> > >
> > > - drm_modeset_lock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
> >
> > I cry a little every time I look at the DRM_MODESET_LOCK_ALL_BEGIN and
> > DRM_MODESET_LOCK_ALL_END macros. :(
> >
> > Currently only six users... but there are ~60 calls to
> > drm_modeset_lock_all{,_ctx} that I presume are to be replaced. I wonder
> > if this will come back and haunt us.
> >
>
> What's the alternative? Seems like the options without the macros is
> to use incorrect scope or have a bunch of retry/backoff cargo-cult
> everywhere (and hope the copy source is done correctly).
Yeah Sean & me had a bunch of bikesheds and this is the least worst
option we could come up with. You can't make it a function because of
the control flow. You don't want to open code this because it's tricky
to get right, if all you want is to just grab all locks. But it is
magic hidden behind a macro, which occasionally ends up hurting.
-Daniel
> Sean
>
> > BR,
> > Jani.
> >
> >
> > >
> > > obj = drm_mode_object_find(dev, file_priv, arg->obj_id,
> > > arg->obj_type);
> > > if (!obj) {
> > > @@ -427,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(struct
> > > drm_device *dev, void *data,
> > > out_unref:
> > > drm_mode_object_put(obj);
> > > out:
> > > - drm_modeset_unlock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_END(ctx, ret);
> > > return ret;
> > > }
> > >
> > > @@ -449,12 +450,13 @@ static int set_property_legacy(struct
> > > drm_mode_object *obj,
> > > {
> > > struct drm_device *dev = prop->dev;
> > > struct drm_mode_object *ref;
> > > + struct drm_modeset_acquire_ctx ctx;
> > > int ret = -EINVAL;
> > >
> > > if (!drm_property_change_valid_get(prop, prop_value, ))
> > > return -EINVAL;
> > >
> > > - drm_modeset_lock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
> > > switch (obj->type) {
> > > case DRM_MODE_OBJECT_CONNECTOR:
> > > ret = drm_connector_set_obj_prop(obj, prop, prop_value);
> > > @@ -468,7 +470,7 @@ static int set_property_legacy(struct drm_mode_object
> > > *obj,
> > > break;
> > > }
> > > drm_property_change_valid_put(prop, ref);
> > > - drm_modeset_unlock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_END(ctx, ret);
> > >
> > > return ret;
> > > }
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dt-bindings: arm-smmu: Add sc7180 compatible string and mem_iface clock
Hi, On Thu, Apr 30, 2020 at 11:12 AM Jordan Crouse wrote: > > On Thu, Apr 30, 2020 at 09:29:47AM +0530, Sharat Masetty wrote: > > This patch adds a new compatible string for sc7180 and also an > > additional clock listing needed to power the TBUs and the TCU. > > > > Signed-off-by: Sharat Masetty > > --- > > v2: Addressed review comments from Doug > > > > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > index 6515dbe..ba5dba4 100644 > > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > @@ -28,6 +28,7 @@ properties: > >- enum: > >- qcom,msm8996-smmu-v2 > >- qcom,msm8998-smmu-v2 > > + - qcom,sc7180-smmu-v2 > >- qcom,sdm845-smmu-v2 > >- const: qcom,smmu-v2 > > > > @@ -113,16 +114,23 @@ properties: > >present in such cases. > > > >clock-names: > > +minItems: 2 > > +maxItems: 3 > > items: > >- const: bus > >- const: iface > > + - const: mem_iface > > Hi Sharat - > > I think there was a bit of confusion due to renaming between downstream and > upstream. Currently for the sdm845 and friends we have: > > clocks = < GCC_GPU_MEMNOC_GFX_CLK>, > < GCC_GPU_CFG_AHB_CLK>; > clock-names = "bus", "iface"; > > Confusingly these same clocks downstream are "mem_iface_clk" and "iface_clk" > respectively. > > It looks like you are trying to add GCC_DDRSS_GPU_AXI_CLK as "mem_iface" which > was formerly "mem_clk" downstream. I'm not sure if the naming change is > intentional or you were trying to make upstream and downstream match and > didn't > realize that they were renamed. > > I'm not sure if we need DDRSS_GPU_AXI_CLK or not. Empirically it works without > it for sdm845 (I don't have a sc7180 to test) but we should probably loop back > with either the clock team or the hardware designers to be sure there isn't a > corner case that is missing. I agree with Doug that its always best if we > don't > need to add a clock. I can confirm that on sc7180 the GPU seems to come up just fine without the clock being specified in the iommu node. Definitely would be good to know what's broken and if nothing is broken maybe we can change this patch to just add the sc7180 compatible string and drop the clock. I do note that the GMU already has a reference to the same "GCC_DDRSS_GPU_AXI_CLK" clock. -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dt-bindings: arm-smmu: Add sc7180 compatible string and mem_iface clock
On Thu, Apr 30, 2020 at 09:29:47AM +0530, Sharat Masetty wrote: > This patch adds a new compatible string for sc7180 and also an > additional clock listing needed to power the TBUs and the TCU. > > Signed-off-by: Sharat Masetty > --- > v2: Addressed review comments from Doug > > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > index 6515dbe..ba5dba4 100644 > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > @@ -28,6 +28,7 @@ properties: >- enum: >- qcom,msm8996-smmu-v2 >- qcom,msm8998-smmu-v2 > + - qcom,sc7180-smmu-v2 >- qcom,sdm845-smmu-v2 >- const: qcom,smmu-v2 > > @@ -113,16 +114,23 @@ properties: >present in such cases. > >clock-names: > +minItems: 2 > +maxItems: 3 > items: >- const: bus >- const: iface > + - const: mem_iface Hi Sharat - I think there was a bit of confusion due to renaming between downstream and upstream. Currently for the sdm845 and friends we have: clocks = < GCC_GPU_MEMNOC_GFX_CLK>, < GCC_GPU_CFG_AHB_CLK>; clock-names = "bus", "iface"; Confusingly these same clocks downstream are "mem_iface_clk" and "iface_clk" respectively. It looks like you are trying to add GCC_DDRSS_GPU_AXI_CLK as "mem_iface" which was formerly "mem_clk" downstream. I'm not sure if the naming change is intentional or you were trying to make upstream and downstream match and didn't realize that they were renamed. I'm not sure if we need DDRSS_GPU_AXI_CLK or not. Empirically it works without it for sdm845 (I don't have a sc7180 to test) but we should probably loop back with either the clock team or the hardware designers to be sure there isn't a corner case that is missing. I agree with Doug that its always best if we don't need to add a clock. Jordan > >clocks: > +minItems: 2 > +maxItems: 3 > items: >- description: bus clock required for downstream bus access and for the >smmu ptw >- description: interface clock required to access smmu's registers >through the TCU's programming interface. > + - description: clock required for the inner working of SMMU TBUs and > the > + TCU like the pagetable walks and the TLB flushes. > >power-domains: > maxItems: 1 > -- > 1.9.1 > -- 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 -next] drm/amd/display: Fix unsigned comparison to zero
Applied. Thanks!
Alex
On Thu, Apr 30, 2020 at 3:33 AM Zou Wei wrote:
>
> Fixes coccicheck warning:
>
> drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c:1398:60-61:
> WARNING: Unsigned expression compared with zero: j >= 0
>
> Fixes: 238387774232 ("drm/amd/display: fix rn soc bb update")
> Reported-by: Hulk Robot
> Signed-off-by: Zou Wei
> ---
> drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> index ceaf70a..419cdde 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> @@ -1384,7 +1384,8 @@ static void update_bw_bounding_box(struct dc *dc,
> struct clk_bw_params *bw_param
> struct dcn21_resource_pool *pool = TO_DCN21_RES_POOL(dc->res_pool);
> struct clk_limit_table *clk_table = _params->clk_table;
> struct _vcs_dpi_voltage_scaling_st clock_limits[DC__VOLTAGE_STATES];
> - unsigned int i, j, closest_clk_lvl;
> + unsigned int i, closest_clk_lvl;
> + int j;
>
> // Default clock levels are used for diags, which may lead to
> overclocking.
> if (!IS_DIAG_DC(dc->ctx->dce_environment)) {
> --
> 2.6.2
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amdgpu: Fix warning Comparison to bool
On Thu, Apr 30, 2020 at 3:32 AM Zou Wei wrote:
>
> fix below warnings reported by coccicheck
>
> drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c:630:5-11: WARNING: Comparison to bool
This seems incorrect. enable is a bool.
Alex
>
> Reported-by: Hulk Robot
> Signed-off-by: Zou Wei
> ---
> drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
> index b544baf..10080e4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
> @@ -627,7 +627,7 @@ static void sdma_v5_0_enable(struct amdgpu_device *adev,
> bool enable)
> u32 f32_cntl;
> int i;
>
> - if (enable == false) {
> + if (!enable) {
> sdma_v5_0_gfx_stop(adev);
> sdma_v5_0_rlc_stop(adev);
> }
> --
> 2.6.2
>
> ___
> 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 0/4] drm/amd/display: remove set but not used variables
Applied. Thanks! Alex On Thu, Apr 30, 2020 at 3:32 AM Zheng Bin wrote: > > Zheng Bin (4): > drm/amd/display: remove set but not used variable 'dc' > drm/amd/display: remove set but not used variable 'pixel_width' > drm/amd/display: remove set but not used variable 'speakers' in > dce_stream_encoder.c > drm/amd/display: remove set but not used variable 'speakers' in > dcn10_stream_encoder.c > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 -- > drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c| 2 -- > drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c | 7 --- > .../gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.c| 2 -- > 4 files changed, 13 deletions(-) > > -- > 2.26.0.106.g9fadedd > > ___ > 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 0/3] drm/amdgpu: remove set but not used variables
Applied. Thanks! Alex On Thu, Apr 30, 2020 at 9:07 AM Christian König wrote: > > Reviewed-by: Christian König for the series. > > Am 30.04.20 um 04:26 schrieb Zheng Bin: > > Zheng Bin (3): > >drm/amdgpu: remove set but not used variable 'priority' > >drm/amdgpu: remove set but not used variable 'direct_poll' in > > vcn_v2_0.c > >drm/amdgpu: remove set but not used variable 'direct_poll' in > > vcn_v2_5.c > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 -- > > drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 3 --- > > drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 -- > > 3 files changed, 7 deletions(-) > > > > -- > > 2.26.0.106.g9fadedd > > > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > ___ > 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: [RFC PATCH 1/4] drm/etnaviv: Prevent IRQ triggering at probe time on i.MX8MM
On Thu, Apr 30, 2020 at 10:31 AM Schrempf Frieder
wrote:
>
> Hi Lucas,
>
> On 30.04.20 16:32, Lucas Stach wrote:
> > Hi Frieder,
> >
> > Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder:
> >> From: Frieder Schrempf
> >>
> >> On i.MX8MM there is an interrupt getting triggered immediately after
> >> requesting the IRQ, which leads to a stall as the handler accesses
> >> the GPU registers whithout the clock being enabled.
> >>
> >> Enabling the clocks briefly seems to clear the IRQ state, so we do
> >> this before requesting the IRQ.
> >
> > This is most likely caused by improper power-up sequencing. Normally
> > the GPC will trigger a hardware reset of the modules inside a power
> > domain when the domain is powered on. This requires the clocks to be
> > running at this point, as those resets are synchronous, so need clock
> > pulses to propagate through the hardware.
>
> Ok, I was suspecting something like that and your explanation makes
> total sense to me.
>
> >
> > From what I see the i.MX8MM is still missing the power domain
> > controller integration, but I'm pretty confident that this problem
> > should be solved in the power domain code, instead of the GPU driver.
>
> Ok. I was hoping that GPU support could be added without power domain
> control, but I now see that this is probably not reasonable at all.
> So I will keep on hoping that NXP comes up with an upstreamable solution
> for the power domain handling.
There was a patch for upstream power-domain control from NXP a few days ago:
https://patchwork.kernel.org/cover/10904511/
Can these be somehow tested to see if it helps the issue with the GPU?
adam
>
> Thanks,
> Frieder
>
> >
> > Regards,
> > Lucas
> >
> >> Signed-off-by: Frieder Schrempf
> >> ---
> >> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 29 -
> >> --
> >> 1 file changed, 22 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> >> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> >> index a31eeff2b297..23877c1f150a 100644
> >> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> >> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> >> @@ -1775,13 +1775,6 @@ static int etnaviv_gpu_platform_probe(struct
> >> platform_device *pdev)
> >> return gpu->irq;
> >> }
> >>
> >> -err = devm_request_irq(>dev, gpu->irq, irq_handler, 0,
> >> - dev_name(gpu->dev), gpu);
> >> -if (err) {
> >> -dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq,
> >> err);
> >> -return err;
> >> -}
> >> -
> >> /* Get Clocks: */
> >> gpu->clk_reg = devm_clk_get(>dev, "reg");
> >> DBG("clk_reg: %p", gpu->clk_reg);
> >> @@ -1805,6 +1798,28 @@ static int etnaviv_gpu_platform_probe(struct
> >> platform_device *pdev)
> >> gpu->clk_shader = NULL;
> >> gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
> >>
> >> +/*
> >> + * On i.MX8MM there is an interrupt getting triggered
> >> immediately
> >> + * after requesting the IRQ, which leads to a stall as the
> >> handler
> >> + * accesses the GPU registers whithout the clock being enabled.
> >> + * Enabling the clocks briefly seems to clear the IRQ state, so
> >> we do
> >> + * this here before requesting the IRQ.
> >> + */
> >> +err = etnaviv_gpu_clk_enable(gpu);
> >> +if (err)
> >> +return err;
> >> +
> >> +err = etnaviv_gpu_clk_disable(gpu);
> >> +if (err)
> >> +return err;
> >> +
> >> +err = devm_request_irq(>dev, gpu->irq, irq_handler, 0,
> >> + dev_name(gpu->dev), gpu);
> >> +if (err) {
> >> +dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq,
> >> err);
> >> +return err;
> >> +}
> >> +
> >> /* TODO: figure out max mapped size */
> >> dev_set_drvdata(dev, gpu);
> >>
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: [PATCH] drm/mediatek: cleanup coding style in mediatek a bit
Hi, Bernard:
Bernard 於 2020年4月30日 週四 下午2:32寫道：
>
>
>
> 发件人：Chun-Kuang Hu
> 发送日期：2020-04-29 22:22:50
> 收件人：Bernard Zhao
> 抄送人：Chun-Kuang Hu ,Philipp Zabel
> ,David Airlie ,Daniel Vetter
> ,Matthias Brugger ,DRI Development
> ,Linux ARM
> ,"moderated list:ARM/Mediatek SoC
> support" ,linux-kernel
> ,opensource.ker...@vivo.com
> 主题：Re: [PATCH] drm/mediatek: cleanup coding style in mediatek a bit>Hi,
> Bernard:
> >
> >Bernard Zhao 於 2020年4月27日 週一 下午3:53寫道：
> >>
> >> This code change is to make code bit more readable.
> >> Optimise array size align to HDMI macro define.
> >> Add check if len is overange.
> >
> >One patch should just do one thing, but this do three things.
> >So break this into three patches.
> >
> >Regards,
> >Chun-Kuang.
>
> Hi
> This optimization is mainly to make the code a bit readable.
> These modifications are related, main in several related function calls in
> the same file.
> I was a bit confused that if it is really necessary to change to three
> separate patch submissions?
>
> Regards
> Bernard
>
> >>
> >> Signed-off-by: Bernard Zhao
> >> ---
> >> drivers/gpu/drm/mediatek/mtk_hdmi.c | 22 +++---
> >> 1 file changed, 11 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> >> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> >> index ff43a3d80410..40fb5154ed5d 100644
> >> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> >> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> >> @@ -311,15 +311,15 @@ static void mtk_hdmi_hw_send_info_frame(struct
> >> mtk_hdmi *hdmi, u8 *buffer,
> >> u8 checksum;
> >> int ctrl_frame_en = 0;
> >>
> >> - frame_type = *buffer;
> >> - buffer += 1;
> >> - frame_ver = *buffer;
> >> - buffer += 1;
> >> - frame_len = *buffer;
> >> - buffer += 1;
> >> - checksum = *buffer;
> >> - buffer += 1;
> >> + frame_type = *buffer++;
> >> + frame_ver = *buffer++;
> >> + frame_len = *buffer++;
> >> + checksum = *buffer++;
This part looks like cleanup, so keep in this patch.
> >> frame_data = buffer;
> >> + if ((frame_len + HDMI_INFOFRAME_HEADER_SIZE) > len) {
> >> + dev_err(hdmi->dev, "Wrong frame len: %d\n", frame_len;
> >> + return;
This is error checking, not cleanup the coding style, so move this to
another patch.
> >> + }
> >>
> >> dev_dbg(hdmi->dev,
> >>
> >> "frame_type:0x%x,frame_ver:0x%x,frame_len:0x%x,checksum:0x%x\n",
> >> @@ -982,7 +982,7 @@ static int mtk_hdmi_setup_avi_infoframe(struct
> >> mtk_hdmi *hdmi,
> >> struct drm_display_mode *mode)
> >> {
> >> struct hdmi_avi_infoframe frame;
> >> - u8 buffer[17];
> >> + u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AVI_INFOFRAME_SIZE];
This is to symbolize the number, symbolization is more than cleanup.
Regards,
Chun-Kuang.
> >> ssize_t err;
> >>
> >> err = drm_hdmi_avi_infoframe_from_display_mode(,
> >> @@ -1008,7 +1008,7 @@ static int mtk_hdmi_setup_spd_infoframe(struct
> >> mtk_hdmi *hdmi,
> >> const char *product)
> >> {
> >> struct hdmi_spd_infoframe frame;
> >> - u8 buffer[29];
> >> + u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_SPD_INFOFRAME_SIZE];
> >> ssize_t err;
> >>
> >> err = hdmi_spd_infoframe_init(, vendor, product);
> >> @@ -1031,7 +1031,7 @@ static int mtk_hdmi_setup_spd_infoframe(struct
> >> mtk_hdmi *hdmi,
> >> static int mtk_hdmi_setup_audio_infoframe(struct mtk_hdmi *hdmi)
> >> {
> >> struct hdmi_audio_infoframe frame;
> >> - u8 buffer[14];
> >> + u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AUDIO_INFOFRAME_SIZE];
> >> ssize_t err;
> >>
> >> err = hdmi_audio_infoframe_init();
> >> --
> >> 2.26.2
> >>
> >>
> >> ___
> >> Linux-mediatek mailing list
> >> linux-media...@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/bridge: adv7511: Fix cec clock EPROBE_DEFER handling
Hi Vincent,
Thank you for the patch.
On Thu, Apr 30, 2020 at 01:54:39PM +0200, Vincent Whitchurch wrote:
> If adv7511's devm_clk_get() for the cec clock returns -EPROBE_DEFER, we
> end up in an infinite probe loop. This happens:
>
> (1) adv7511's probe is called.
>
> (2) adv7511's probe adds some secondary i2c devices which bind to the
> dummy driver and thus call driver_deferred_probe_trigger() and
> increment deferred_trigger_count (see driver_bound()).
>
> (3) adv7511's probe returns -EPROBE_DEFER, and since the
> deferred_trigger_count has changed during the probe call,
> driver_deferred_probe_trigger() is called immediately (see
> really_probe()) and adv7511's probe is scheduled.
>
> (4) Goto step 1.
>
> [ 61.972915] really_probe: bus: 'i2c': really_probe: probing driver adv7511
> with device 0-0039
> [ 61.992734] really_probe: bus: 'i2c': really_probe: probing driver dummy
> with device 0-003f
> [ 61.993343] driver_bound: driver: 'dummy': driver_bound: bound to device
> '0-003f'
> [ 61.993626] really_probe: bus: 'i2c': really_probe: bound device 0-003f to
> driver dummy
> [ 61.995604] really_probe: bus: 'i2c': really_probe: probing driver dummy
> with device 0-0038
> [ 61.996381] driver_bound: driver: 'dummy': driver_bound: bound to device
> '0-0038'
> [ 61.996663] really_probe: bus: 'i2c': really_probe: bound device 0-0038 to
> driver dummy
> [ 61.998651] really_probe: bus: 'i2c': really_probe: probing driver dummy
> with device 0-003c
> [ 61.999222] driver_bound: driver: 'dummy': driver_bound: bound to device
> '0-003c'
> [ 61.999496] really_probe: bus: 'i2c': really_probe: bound device 0-003c to
> driver dummy
> [ 62.010050] really_probe: i2c 0-0039: Driver adv7511 requests probe
> deferral
> [ 62.011380] really_probe: bus: 'platform': really_probe: probing driver
> pwm-clock with device clock-cec
> [ 62.012812] really_probe: platform clock-cec: Driver pwm-clock requests
> probe deferral
> [ 62.024679] really_probe: bus: 'i2c': really_probe: probing driver adv7511
> with device 0-0039
>
> Fix this by calling devm_clk_get() before registering the secondary
> devices.
>
> Signed-off-by: Vincent Whitchurch
> ---
> v2: Add devm_clk_put() in error path.
>
> drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 31
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 11 +--
> 2 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> index a20a45c0b353..f5e9d0b238d2 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> @@ -286,28 +286,17 @@ static const struct cec_adap_ops adv7511_cec_adap_ops =
> {
> .adap_transmit = adv7511_cec_adap_transmit,
> };
>
> -static int adv7511_cec_parse_dt(struct device *dev, struct adv7511 *adv7511)
> -{
> - adv7511->cec_clk = devm_clk_get(dev, "cec");
> - if (IS_ERR(adv7511->cec_clk)) {
> - int ret = PTR_ERR(adv7511->cec_clk);
> -
> - adv7511->cec_clk = NULL;
> - return ret;
> - }
> - clk_prepare_enable(adv7511->cec_clk);
> - adv7511->cec_clk_freq = clk_get_rate(adv7511->cec_clk);
> - return 0;
> -}
> -
> int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
> {
> unsigned int offset = adv7511->type == ADV7533 ?
> ADV7533_REG_CEC_OFFSET : 0;
> - int ret = adv7511_cec_parse_dt(dev, adv7511);
> + int ret;
>
> - if (ret)
> - goto err_cec_parse_dt;
> + if (!adv7511->cec_clk)
> + goto err_cec_no_clock;
> +
> + clk_prepare_enable(adv7511->cec_clk);
> + adv7511->cec_clk_freq = clk_get_rate(adv7511->cec_clk);
>
> adv7511->cec_adap = cec_allocate_adapter(_cec_adap_ops,
> adv7511, dev_name(dev), CEC_CAP_DEFAULTS, ADV7511_MAX_ADDRS);
> @@ -342,8 +331,12 @@ int adv7511_cec_init(struct device *dev, struct adv7511
> *adv7511)
> err_cec_alloc:
> dev_info(dev, "Initializing CEC failed with error %d, disabling CEC\n",
>ret);
> -err_cec_parse_dt:
> + clk_disable_unprepare(adv7511->cec_clk);
> + devm_clk_put(dev, adv7511->cec_clk);
> + /* Ensure that adv7511_remove() doesn't attempt to disable it again. */
> + adv7511->cec_clk = NULL;
> +err_cec_no_clock:
> regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
>ADV7511_CEC_CTRL_POWER_DOWN);
> - return ret == -EPROBE_DEFER ? ret : 0;
> + return 0;
If this function can't fail anymore, I would make it void. With that,
Reviewed-by: Laurent Pinchart
> }
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 9e13e466e72c..ebc548e23ece 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@
Re: [RESEND 2/2] drm/format_helper: Dual licence the header in GPL-2 and MIT
On Thu, 30 Apr 2020 17:06:34 +0200 Maxime Ripard wrote: > On Thu, Apr 30, 2020 at 04:55:37PM +0200, Emmanuel Vadot wrote: > > Source file was dual licenced but the header was omitted, fix that. > > Contributors for this file are: > > Noralf Trønnes > > Gerd Hoffmann > > Thomas Gleixner > > > > Acked-by: Gerd Hoffmann > > Acked-by: Noralf Trønnes > > Signed-off-by: Emmanuel Vadot > > --- > > include/drm/drm_format_helper.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/include/drm/drm_format_helper.h > > b/include/drm/drm_format_helper.h > > index ac220aa1a245..7c5d4ffb2af2 100644 > > --- a/include/drm/drm_format_helper.h > > +++ b/include/drm/drm_format_helper.h > > @@ -1,4 +1,4 @@ > > -/* SPDX-License-Identifier: GPL-2.0-or-later */ > > +/* SPDX-License-Identifier: GPL-2.0 or MIT */ > > You changed the GPL license there, was that intentional? > > Maxime No sorry, fixed in v2. Thanks for noticing that. -- Emmanuel Vadot ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers
On Wed, Apr 29, 2020 at 4:57 AM Jani Nikula wrote:
>
> On Tue, 28 Apr 2020, Michal Orzel wrote:
> > As suggested by the TODO list for the kernel DRM subsystem, replace
> > the deprecated functions that take/drop modeset locks with new helpers.
> >
> > Signed-off-by: Michal Orzel
> > ---
> > drivers/gpu/drm/drm_mode_object.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > b/drivers/gpu/drm/drm_mode_object.c
> > index 35c2719..901b078 100644
> > --- a/drivers/gpu/drm/drm_mode_object.c
> > +++ b/drivers/gpu/drm/drm_mode_object.c
> > @@ -402,12 +402,13 @@ int drm_mode_obj_get_properties_ioctl(struct
> > drm_device *dev, void *data,
> > {
> > struct drm_mode_obj_get_properties *arg = data;
> > struct drm_mode_object *obj;
> > + struct drm_modeset_acquire_ctx ctx;
> > int ret = 0;
> >
> > if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > return -EOPNOTSUPP;
> >
> > - drm_modeset_lock_all(dev);
> > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>
> I cry a little every time I look at the DRM_MODESET_LOCK_ALL_BEGIN and
> DRM_MODESET_LOCK_ALL_END macros. :(
>
> Currently only six users... but there are ~60 calls to
> drm_modeset_lock_all{,_ctx} that I presume are to be replaced. I wonder
> if this will come back and haunt us.
>
What's the alternative? Seems like the options without the macros is
to use incorrect scope or have a bunch of retry/backoff cargo-cult
everywhere (and hope the copy source is done correctly).
Sean
> BR,
> Jani.
>
>
> >
> > obj = drm_mode_object_find(dev, file_priv, arg->obj_id,
> > arg->obj_type);
> > if (!obj) {
> > @@ -427,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(struct drm_device
> > *dev, void *data,
> > out_unref:
> > drm_mode_object_put(obj);
> > out:
> > - drm_modeset_unlock_all(dev);
> > + DRM_MODESET_LOCK_ALL_END(ctx, ret);
> > return ret;
> > }
> >
> > @@ -449,12 +450,13 @@ static int set_property_legacy(struct drm_mode_object
> > *obj,
> > {
> > struct drm_device *dev = prop->dev;
> > struct drm_mode_object *ref;
> > + struct drm_modeset_acquire_ctx ctx;
> > int ret = -EINVAL;
> >
> > if (!drm_property_change_valid_get(prop, prop_value, ))
> > return -EINVAL;
> >
> > - drm_modeset_lock_all(dev);
> > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
> > switch (obj->type) {
> > case DRM_MODE_OBJECT_CONNECTOR:
> > ret = drm_connector_set_obj_prop(obj, prop, prop_value);
> > @@ -468,7 +470,7 @@ static int set_property_legacy(struct drm_mode_object
> > *obj,
> > break;
> > }
> > drm_property_change_valid_put(prop, ref);
> > - drm_modeset_unlock_all(dev);
> > + DRM_MODESET_LOCK_ALL_END(ctx, ret);
> >
> > return ret;
> > }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/10] drm: Add backlight helper
Hi, On 4/29/20 8:40 PM, Noralf Trønnes wrote: Den 29.04.2020 16.13, skrev Hans de Goede: Hi Noralf, On 4/29/20 2:48 PM, Noralf Trønnes wrote: This adds a function that creates a backlight device for a connector. It does not deal with the KMS backlight ABI proposition[1] to add a connector property. It only takes the current best practise to standardise the creation of a backlight device for DRM drivers while we wait for the property. The brightness value is set using a connector state variable and an atomic commit. I have looked through some of the backlight users and this is what I've found: GNOME [2] - Brightness range: 0-100 Scale: Assumes perceptual I'm afraid that this is an incaccurate view of how GNOME handles the brightness. gnome-settings-daemon (g-s-d) exports a DBUS property which has a range of 0 - 100%. But it also offers step-up and step-down DBUS methods which are used for handling brightness hotkey presses. This is important because g-s-d internally also keeps a step_size variable which depends on the brightness_max value of the sysfs backlight interface, like this: BRIGHTNESS_STEP_AMOUNT(max) ((max) < 20 ? 1 : (max) / 20) This is important because some older laptops where we depend on the vendor specific ACPI method (from e.g. dell-laptop or thinkpad_acpi) there are only 8 levels. So if g-s-d where to simply fake a 1-100 range and would leave the stepping up to the DBus API user and that user would want 20 steps, so 5 % per step, then the user would get Start -> 100% -> level 8 Press down -> 95% -> level 7 Press down -> 90% -> level 7 *no change* etc. Somewhat related on some embedded ARM devices there are tricks where when the entire scene being rendered does not use 100% white as color, the entire scene has all its rgb values upscaled (too a curve) so that the brightest colors do hit 100% of one of r/g/b, combined with dimming the backlight a bit to save power. As you can imagine for tricks like these you want as much backlight control precision as possible. So any backlight infra we add must expose the true range of the backlight control and not normalize it to a 0-100 range. So sorry, but nack for the current version because of the hardcoding of the range. No problem, I just had to start from somewhere, and I started with: Give the driver developer as few options as possible, no more than necessary, but I didn't really know what was necessary :-) The reason I chose a 0-100 range is because the backlight property ABI proposal had this range and it maps so nicely to percent. And can the ordinary human see brightness changes in more than 100 steps? This helper is only to be used by drm drivers and I assumed that all the current drivers registering a backlight device could at least do that range. Looking through the drivers and their max_brightness values that assumption isn't quite right: amd: 255 gma500: 100 i915: nouveau/nv40: 31 nouveau/nv50: 100 radeon: 255 shmobile: panel-dsi-cm.c: 255 panel-jdi-lt070me05000.c: 255 panel-orisetech-otm8009a.c: 255 panel-raydium-rm67191.c: 255 panel-samsung-s6e63m0.c: 10 panel-sony-acx424akp.c: 1023 panel-samsung-s6e3ha2.c: 100 panel-samsung-s6e63j0x03.c: 100 panel-sony-acx565akm.c: 255 bridge/parade-ps8622.c: 255 I'll add max_brightness as an argument together with scale which you commented on below. Ok, sounds good. Also the scale really should be specified by the driver, or be hardcoded to BACKLIGHT_SCALE_UNKNOWN for now. In many cases we do not really know. But for e.g. the acpi_video firmware backlight interface a good guess is that it actually represents a perceptual scale rather then controlling the wattage. Where as the native i915 backlight interface really is controlling the wattage without any perceptual correction. Another problem with your proposal is that it seems to assume that the backlight is controlled by the drm/kms driver. On x86 we have Yes, this backlight device is just for drm drivers. I was hoping you might have some clever ideas how to deal with / prepare for the backlight driver outside of drm-driver case too. But I completely understand that you want to limit your scope. The reason I spend time on this is because I want to pass backlight brightness changes through the atomic machinery like any other state change. I understand. Regards, Hans atleast 3 different drivers for the backlight: 1) The i915 (or amd/nouveau) native driver which more or less directly pokes the PWM controller of the GPU. 2) The ACPI video standard backlight interface 3) Vendor specific ACPI interfaces from older laptops ATM we always register 1. which could remain unchanged with your code and then also register 2/3 if we (the kernel) think that will work better (*) and then rely on userspace prefering these (they have a different backlight_type) over 1. Ideally any infra we add will also offer the option to tie 2. or 3. to the connector... Regards, Hans *) e.g. it will
Re: [RESEND 1/2] drm/client: Dual licence the header in GPL-2 and MIT
Am 30.04.20 um 16:54 schrieb Emmanuel Vadot: > Source file was dual licenced but the header was omitted, fix that. > Contributors for this file are: > Daniel Vetter > Matt Roper > Maxime Ripard > Noralf Trønnes > Thomas Zimmermann > > Acked-by: Noralf Trønnes > Acked-by: Matt Roper > Acked-by: Daniel Vetter > Signed-off-by: Emmanuel Vadot Acked-by: Thomas Zimmermann > --- > include/drm/drm_client.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h > index 7402f852d3c4..eb259c2547af 100644 > --- a/include/drm/drm_client.h > +++ b/include/drm/drm_client.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +/* SPDX-License-Identifier: GPL-2.0 or MIT */ > > #ifndef _DRM_CLIENT_H_ > #define _DRM_CLIENT_H_ > -- 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 signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 1/2] drm/client: Dual licence the header in GPL-2 and MIT
On Thu, Apr 30, 2020 at 4:54 PM Emmanuel Vadot wrote: > > Source file was dual licenced but the header was omitted, fix that. > Contributors for this file are: > Daniel Vetter > Matt Roper > Maxime Ripard > Noralf Trønnes > Thomas Zimmermann > > Acked-by: Noralf Trønnes > Acked-by: Matt Roper > Acked-by: Daniel Vetter > Signed-off-by: Emmanuel Vadot Acked-by: Daniel Vetter > --- > include/drm/drm_client.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h > index 7402f852d3c4..eb259c2547af 100644 > --- a/include/drm/drm_client.h > +++ b/include/drm/drm_client.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +/* SPDX-License-Identifier: GPL-2.0 or MIT */ > > #ifndef _DRM_CLIENT_H_ > #define _DRM_CLIENT_H_ > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH resend] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument
Hi, On 4/30/20 4:52 PM, Ville Syrjälä wrote: On Thu, Apr 30, 2020 at 02:47:00PM +0100, Emil Velikov wrote: Hi Hans, On Fri, 21 Feb 2020 at 17:33, Hans de Goede wrote: drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching a video= argument over calculating our own timings for the user specified mode using CVT or GTF. But userspace code which is auto-configuring the mode may want to know that the user has specified that mode on the kernel commandline so that it can pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED. This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just as we would do on the user-specified mode when no matching probed mode is found. Signed-off-by: Hans de Goede I was skimming around wrt Ville's compact drm_display_mode series and noticed that this never landed. The commit brings extra consistency when dealing with user defined modes, and is: Reviewed-by: Emil Velikov Ville this may trivially conflict with your work. I suspect you can do the honours, and apply on top of your series? That is if you agree with the patch. Quick glance at the original thread says maybe there were still some userspace issues unresolved? Not sure. IIRC the thread ended with Daniel agreeing on the userspace interface, but asking for some docs and me pointing out that the patch already updated/clarified the existing docs. After that things got quiet. So I believe that this is (still) ready to go upstream. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: cleanup coding style a bit
Applied. Thanks!
Alex
On Sun, Apr 26, 2020 at 9:18 AM Christian König
wrote:
>
> Am 26.04.20 um 15:12 schrieb Bernard Zhao:
> > Maybe no need to check ws before kmalloc, kmalloc will check
> > itself, kmalloc`s logic is if ptr is NULL, kmalloc will just
> > return
> >
> > Signed-off-by: Bernard Zhao
>
> Reviewed-by: Christian König
>
> I'm wondering why the automated scripts haven't found that one before.
>
> > ---
> > drivers/gpu/drm/radeon/atom.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> > index 2c27627b6659..f15b20da5315 100644
> > --- a/drivers/gpu/drm/radeon/atom.c
> > +++ b/drivers/gpu/drm/radeon/atom.c
> > @@ -1211,8 +1211,7 @@ static int atom_execute_table_locked(struct
> > atom_context *ctx, int index, uint32
> > SDEBUG("<<\n");
> >
> > free:
> > - if (ws)
> > - kfree(ectx.ws);
> > + kfree(ectx.ws);
> > return ret;
> > }
> >
>
> ___
> 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 resend] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument
On Thu, Apr 30, 2020 at 02:47:00PM +0100, Emil Velikov wrote: > Hi Hans, > > On Fri, 21 Feb 2020 at 17:33, Hans de Goede wrote: > > > > drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching > > a video= argument over calculating our own timings for the user specified > > mode using CVT or GTF. > > > > But userspace code which is auto-configuring the mode may want to know that > > the user has specified that mode on the kernel commandline so that it can > > pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED. > > > > This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just > > as we would do on the user-specified mode when no matching probed mode is > > found. > > > > Signed-off-by: Hans de Goede > > I was skimming around wrt Ville's compact drm_display_mode series and > noticed that this never landed. > > The commit brings extra consistency when dealing with user defined > modes, and is: > Reviewed-by: Emil Velikov > > Ville this may trivially conflict with your work. I suspect you can do > the honours, and apply on top of your series? > That is if you agree with the patch. Quick glance at the original thread says maybe there were still some userspace issues unresolved? Not sure. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/4] drm/etnaviv: Change order of enabling clocks to fix boot on i.MX8MM
Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder:
> From: Frieder Schrempf
>
> On some i.MX8MM devices the boot hangs when enabling the GPU clocks.
> Changing the order of clock initalization to
>
> core -> shader -> bus -> reg
>
> fixes the issue. This is the same order used in the imx platform code
> of the downstream GPU driver in the NXP kernel [1]. For the sake of
> consistency we also adjust the order of disabling the clocks to the
> reverse.
>
> [1]
> https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/mxc/gpu-viv/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx.c?h=imx_5.4.3_2.0.0#n1538
I don't see why the order of the clocks is important. Is this really a
GPU issue? As in: does a GPU access hang when enabling the clocks in
the wrong order? Or is this a clock driver issue with a clock access
hanging due to an upstream clock still being disabled?
Regards,
Lucas
> Signed-off-by: Frieder Schrempf
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 42 +--
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 7b138d4dd068..424b2e5951f0 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1487,55 +1487,55 @@ static int etnaviv_gpu_clk_enable(struct etnaviv_gpu
> *gpu)
> {
> int ret;
>
> - if (gpu->clk_reg) {
> - ret = clk_prepare_enable(gpu->clk_reg);
> + if (gpu->clk_core) {
> + ret = clk_prepare_enable(gpu->clk_core);
> if (ret)
> return ret;
> }
>
> - if (gpu->clk_bus) {
> - ret = clk_prepare_enable(gpu->clk_bus);
> + if (gpu->clk_shader) {
> + ret = clk_prepare_enable(gpu->clk_shader);
> if (ret)
> - goto disable_clk_reg;
> + goto disable_clk_core;
> }
>
> - if (gpu->clk_core) {
> - ret = clk_prepare_enable(gpu->clk_core);
> + if (gpu->clk_bus) {
> + ret = clk_prepare_enable(gpu->clk_bus);
> if (ret)
> - goto disable_clk_bus;
> + goto disable_clk_shader;
> }
>
> - if (gpu->clk_shader) {
> - ret = clk_prepare_enable(gpu->clk_shader);
> + if (gpu->clk_reg) {
> + ret = clk_prepare_enable(gpu->clk_reg);
> if (ret)
> - goto disable_clk_core;
> + goto disable_clk_bus;
> }
>
> return 0;
>
> -disable_clk_core:
> - if (gpu->clk_core)
> - clk_disable_unprepare(gpu->clk_core);
> disable_clk_bus:
> if (gpu->clk_bus)
> clk_disable_unprepare(gpu->clk_bus);
> -disable_clk_reg:
> - if (gpu->clk_reg)
> - clk_disable_unprepare(gpu->clk_reg);
> +disable_clk_shader:
> + if (gpu->clk_shader)
> + clk_disable_unprepare(gpu->clk_shader);
> +disable_clk_core:
> + if (gpu->clk_core)
> + clk_disable_unprepare(gpu->clk_core);
>
> return ret;
> }
>
> static int etnaviv_gpu_clk_disable(struct etnaviv_gpu *gpu)
> {
> + if (gpu->clk_reg)
> + clk_disable_unprepare(gpu->clk_reg);
> + if (gpu->clk_bus)
> + clk_disable_unprepare(gpu->clk_bus);
> if (gpu->clk_shader)
> clk_disable_unprepare(gpu->clk_shader);
> if (gpu->clk_core)
> clk_disable_unprepare(gpu->clk_core);
> - if (gpu->clk_bus)
> - clk_disable_unprepare(gpu->clk_bus);
> - if (gpu->clk_reg)
> - clk_disable_unprepare(gpu->clk_reg);
>
> return 0;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/4] drm/etnaviv: Prevent IRQ triggering at probe time on i.MX8MM
Hi Frieder,
Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder:
> From: Frieder Schrempf
>
> On i.MX8MM there is an interrupt getting triggered immediately after
> requesting the IRQ, which leads to a stall as the handler accesses
> the GPU registers whithout the clock being enabled.
>
> Enabling the clocks briefly seems to clear the IRQ state, so we do
> this before requesting the IRQ.
This is most likely caused by improper power-up sequencing. Normally
the GPC will trigger a hardware reset of the modules inside a power
domain when the domain is powered on. This requires the clocks to be
running at this point, as those resets are synchronous, so need clock
pulses to propagate through the hardware.
>From what I see the i.MX8MM is still missing the power domain
controller integration, but I'm pretty confident that this problem
should be solved in the power domain code, instead of the GPU driver.
Regards,
Lucas
> Signed-off-by: Frieder Schrempf
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 29 -
> --
> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index a31eeff2b297..23877c1f150a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1775,13 +1775,6 @@ static int etnaviv_gpu_platform_probe(struct
> platform_device *pdev)
> return gpu->irq;
> }
>
> - err = devm_request_irq(>dev, gpu->irq, irq_handler, 0,
> -dev_name(gpu->dev), gpu);
> - if (err) {
> - dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq,
> err);
> - return err;
> - }
> -
> /* Get Clocks: */
> gpu->clk_reg = devm_clk_get(>dev, "reg");
> DBG("clk_reg: %p", gpu->clk_reg);
> @@ -1805,6 +1798,28 @@ static int etnaviv_gpu_platform_probe(struct
> platform_device *pdev)
> gpu->clk_shader = NULL;
> gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
>
> + /*
> + * On i.MX8MM there is an interrupt getting triggered
> immediately
> + * after requesting the IRQ, which leads to a stall as the
> handler
> + * accesses the GPU registers whithout the clock being enabled.
> + * Enabling the clocks briefly seems to clear the IRQ state, so
> we do
> + * this here before requesting the IRQ.
> + */
> + err = etnaviv_gpu_clk_enable(gpu);
> + if (err)
> + return err;
> +
> + err = etnaviv_gpu_clk_disable(gpu);
> + if (err)
> + return err;
> +
> + err = devm_request_irq(>dev, gpu->irq, irq_handler, 0,
> +dev_name(gpu->dev), gpu);
> + if (err) {
> + dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq,
> err);
> + return err;
> + }
> +
> /* TODO: figure out max mapped size */
> dev_set_drvdata(dev, gpu);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Documentation: fix: `make htmldocs` warnings
Hello Everyone, On Thu, 30 Apr 2020 at 10:07, Sam Ravnborg wrote: > > On Wed, Apr 29, 2020 at 11:27:22PM -0300, Vitor Massaru Iha wrote: > > On Wed, 2020-04-29 at 19:06 -0700, Randy Dunlap wrote: > > > On 4/29/20 6:59 PM, Vitor Massaru Iha wrote: > > > > Add missed ":" on kernel-doc function parameter. > > > > > > > > This patch fixes this warnings from `make htmldocs`: > > > > ./drivers/dma-buf/dma-buf.c:678: warning: Function parameter or > > > > member 'importer_ops' not described in 'dma_buf_dynamic_attach' > > > > ./drivers/dma-buf/dma-buf.c:678: warning: Function parameter or > > > > member 'importer_priv' not described in 'dma_buf_dynamic_attach' > > > > > > > > Signed-off-by: Vitor Massaru Iha > > > > --- > > > > drivers/dma-buf/dma-buf.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > > > index ccc9eda1bc28..0756d2155745 100644 > > > > --- a/drivers/dma-buf/dma-buf.c > > > > +++ b/drivers/dma-buf/dma-buf.c > > > > @@ -655,8 +655,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put); > > > > * calls attach() of dma_buf_ops to allow device-specific attach > > > > functionality > > > > * @dmabuf: [in]buffer to attach device to. > > > > * @dev: [in]device to be attached. > > > > - * @importer_ops [in]importer operations for the > > > > attachment > > > > - * @importer_priv[in]importer private pointer for the > > > > attachment > > > > + * @importer_ops:[in]importer operations for the > > > > attachment > > > > + * @importer_priv: [in]importer private pointer for the > > > > attachment > > > > * > > > > * Returns struct dma_buf_attachment pointer for this attachment. > > > > Attachments > > > > * must be cleaned up by calling dma_buf_detach(). > > > > > > > > > > Sumit said that he would be applying my patch from April 7: > > > https://lore.kernel.org/linux-media/7bcbe6fe-0b4b-87da-d003-b68a26eb4...@infradead.org/ > > > > > > thanks. > > > > Sorry. I didn't check if the patch has already been sent. > > Sumit - patch from Randy is neither applied to drm-misc-next nor > drm-misc-fixes. > A reminder in case it was lost somewhere. My bad: I have now applied it to drm-misc-fixes, so should be seen in -next soon. > > Sam Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC 06/17] drm: i915: fix sg_table nents vs. orig_nents misuse
Hi
On 28.04.2020 16:27, Tvrtko Ursulin wrote:
>
> On 28/04/2020 14:19, Marek Szyprowski wrote:
>> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
>> numer of the created entries in the DMA address space. However the
>> subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg
>> must be
>> called with the original number of entries passed to dma_map_sg. The
>> sg_table->nents in turn holds the result of the dma_map_sg call as
>> stated
>> in include/linux/scatterlist.h. Adapt the code to obey those rules.
>>
>> Signed-off-by: Marek Szyprowski
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 13 +++--
>> drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4 ++--
>> drivers/gpu/drm/i915/gem/i915_gem_region.c | 4 ++--
>> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 5 +++--
>> drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 10 +-
>> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 5 +++--
>> drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
>> drivers/gpu/drm/i915/i915_gem_gtt.c | 12 +++-
>> drivers/gpu/drm/i915/i915_scatterlist.c | 4 ++--
>> drivers/gpu/drm/i915/selftests/scatterlist.c | 8
>> 10 files changed, 41 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> index 7db5a79..d829852 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> @@ -36,21 +36,22 @@ static struct sg_table
>> *i915_gem_map_dma_buf(struct dma_buf_attachment *attachme
>> goto err_unpin_pages;
>> }
>> - ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
>> + ret = sg_alloc_table(st, obj->mm.pages->orig_nents, GFP_KERNEL);
>> if (ret)
>> goto err_free;
>> src = obj->mm.pages->sgl;
>> dst = st->sgl;
>> - for (i = 0; i < obj->mm.pages->nents; i++) {
>> + for (i = 0; i < obj->mm.pages->orig_nents; i++) {
>> sg_set_page(dst, sg_page(src), src->length, 0);
>> dst = sg_next(dst);
>> src = sg_next(src);
>> }
>> - if (!dma_map_sg_attrs(attachment->dev,
>> - st->sgl, st->nents, dir,
>> - DMA_ATTR_SKIP_CPU_SYNC)) {
>> + st->nents = dma_map_sg_attrs(attachment->dev,
>> + st->sgl, st->orig_nents, dir,
>> + DMA_ATTR_SKIP_CPU_SYNC);
>> + if (!st->nents) {
>> ret = -ENOMEM;
>> goto err_free_sg;
>> }
>> @@ -74,7 +75,7 @@ static void i915_gem_unmap_dma_buf(struct
>> dma_buf_attachment *attachment,
>> struct drm_i915_gem_object *obj =
>> dma_buf_to_obj(attachment->dmabuf);
>> dma_unmap_sg_attrs(attachment->dev,
>> - sg->sgl, sg->nents, dir,
>> + sg->sgl, sg->orig_nents, dir,
>> DMA_ATTR_SKIP_CPU_SYNC);
>> sg_free_table(sg);
>> kfree(sg);
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
>> index cbbff81..a8ebfdd 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
>> @@ -73,7 +73,7 @@ static int
>> i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj)
>> }
>> sg = st->sgl;
>> - st->nents = 0;
>> + st->nents = st->orig_nents = 0;
>> sg_page_sizes = 0;
>> do {
>> @@ -94,7 +94,7 @@ static int
>> i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj)
>> sg_set_page(sg, page, PAGE_SIZE << order, 0);
>> sg_page_sizes |= PAGE_SIZE << order;
>> - st->nents++;
>> + st->nents = st->orig_nents = st->nents + 1;
>> npages -= 1 << order;
>> if (!npages) {
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_region.c
>> index 1515384..58ca560 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
>> @@ -53,7 +53,7 @@
>> GEM_BUG_ON(list_empty(blocks));
>> sg = st->sgl;
>> - st->nents = 0;
>> + st->nents = st->orig_nents = 0;
>> sg_page_sizes = 0;
>> prev_end = (resource_size_t)-1;
>> @@ -78,7 +78,7 @@
>> sg->length = block_size;
>> - st->nents++;
>> + st->nents = st->orig_nents = st->nents + 1;
>> } else {
>> sg->length += block_size;
>> sg_dma_len(sg) += block_size;
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> index 5d5d7ee..851a732 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> @@ -80,7 +80,7 @@ static int shmem_get_pages(struct
>> drm_i915_gem_object *obj)
>> noreclaim |= __GFP_NORETRY
Re: [PATCH v5 1/6] of_graph: add of_graph_get_local_port()
On Sat, 18 Apr 2020 20:06:58 +0300, Dmitry Osipenko wrote: > In some case, like a DRM display code for example, it's useful to silently > check whether port node exists at all in a device-tree before proceeding > with parsing the graph. > > This patch adds of_graph_get_local_port() which returns pointer to a local > port node, or NULL if graph isn't specified in a device-tree for a given > device node. > > Signed-off-by: Dmitry Osipenko > --- > drivers/of/property.c| 32 +++- > include/linux/of_graph.h | 7 +++ > 2 files changed, 30 insertions(+), 9 deletions(-) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: make drm_file use keyed wakeups
On Wed, Apr 29, 2020 at 11:19:07AM +, k...@kl.wtf wrote: > April 28, 2020 5:14 PM, "Daniel Vetter" wrote: > > > On Fri, Apr 24, 2020 at 06:26:15PM +0200, Kenny Levinsen wrote: > > > >> Some processes, such as systemd, are only polling for EPOLLERR|EPOLLHUP. > >> As drm_file uses unkeyed wakeups, such a poll can receive many spurious > >> wakeups from uninteresting events if, for example, the file description > >> is subscribed to vblank events. This is the case with systemd, as it > >> polls a file description from logind that is shared with the users' > >> compositor. > >> > >> Use keyed wakeups to allow the wakeup target to more efficiently discard > >> these uninteresting events. > >> > >> Signed-off-by: Kenny Levinsen > > > > Hm I applied v1 and I'm not spotting what's different here, and there's no > > changelog explaining what changed ... > > > > Please send a fixup if there's anything important missing. > > -Daniel > > > > It's only the summary that differed as you and sravn requested in #dri-devel, > so it's probably fine. > > I should have explained the change. I'm still trying to get the hang of the > email-based workflow. :) Oops sorry, I generally run as a stateless maintainer so forgot :-/ And yes email based workflow is full of warts, it's a pain. -Daniel > > Best regards, > Kenny Levinsen > > >> --- > >> drivers/gpu/drm/drm_file.c | 6 -- > >> 1 file changed, 4 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > >> index c4c704e01961..ec25b3d979d9 100644 > >> --- a/drivers/gpu/drm/drm_file.c > >> +++ b/drivers/gpu/drm/drm_file.c > >> @@ -608,7 +608,8 @@ ssize_t drm_read(struct file *filp, char __user > >> *buffer, > >> file_priv->event_space -= length; > >> list_add(>link, _priv->event_list); > >> spin_unlock_irq(>event_lock); > >> - wake_up_interruptible(_priv->event_wait); > >> + wake_up_interruptible_poll(_priv->event_wait, > >> + EPOLLIN | EPOLLRDNORM); > >> break; > >> } > >> > >> @@ -804,7 +805,8 @@ void drm_send_event_locked(struct drm_device *dev, > >> struct drm_pending_event *e) > >> list_del(>pending_link); > >> list_add_tail(>link, > >> >file_priv->event_list); > >> - wake_up_interruptible(>file_priv->event_wait); > >> + wake_up_interruptible_poll(>file_priv->event_wait, > >> + EPOLLIN | EPOLLRDNORM); > >> } > >> EXPORT_SYMBOL(drm_send_event_locked); > >> > >> -- > >> 2.26.1 > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- 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 01/10] backlight: Add backlight_device_get_by_name()
On Thu, Apr 30, 2020 at 11:15:29AM +0100, Lee Jones wrote: > On Thu, 30 Apr 2020, Noralf Trønnes wrote: > > > > > > > Den 30.04.2020 10.32, skrev Lee Jones: > > > On Wed, 29 Apr 2020, Noralf Trønnes wrote: > > > > > >> Add a way to lookup a backlight device based on its name. > > >> Will be used by a USB display gadget getting the name from configfs. > > >> > > >> Cc: Lee Jones > > >> Cc: Daniel Thompson > > >> Cc: Jingoo Han > > >> Signed-off-by: Noralf Trønnes > > >> --- > > >> drivers/video/backlight/backlight.c | 21 + > > >> include/linux/backlight.h | 1 + > > >> 2 files changed, 22 insertions(+) > > > > > > Once reviewed, can this patch be applied on its own? > > > > > > > If you can apply it for 5.8, then we're good. DRM has cutoff at -rc5 and > > the driver won't be ready for that. This patch has this dependency > > chain: usb -> drm -> backlight. So if you can apply it for 5.8, things > > gets easier. > > > > > My guess is that it can't, as the other patches in this set depend on > > > it, right? If this assumption is true, you need to send me the rest > > > of the set. > > > > > > FYI: It's normally better to send the whole set to everyone, as it > > > provides visibility on current review (or lack there of) status of the > > > other patches and allows each of the maintainers to discuss possible > > > merge strategies. Unfortunately this doesn't hold universally, since once you cc too many people smtp servers start throwing your mails away. Generally only happens for bigger refactorings, so pretty much anyone working cross-tree doesn't do this because it doesn't work. > > dri-devel is the ML for backlight so I assumed you got the full set. > > dri-devel isn't the ML for Backlight. It's an interested party. > > I certainly have no intention of subscribing to it. dri-devel is on lore so that you can grab missing patches. No need to subscribe. I've only manged to get this sorted recently (last autumn or so), but it's finally done. -Daniel > > I have had trouble in the past with my email provider dropping parts of > > a series when I had to many recipients. > > Without visibility into the other patches in the set, things become > more difficult. Maybe use a different/better email provider. > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2020-04-30: - Fix selftest refcnt leak (Xiyu) - Fix gem vma lock (Chris) - Fix gt's i915_request.timeline acquire by checking if cacheline is valid (Chris) - Fix IRQ postinistall fault masks (Matt) Thanks, Rodrigo. The following changes since commit d082119f4277ff4a63e44d293864aa9f2112b217: drm/i915/dpcd_bl: Unbreak enable_dpcd_backlight modparam (2020-04-20 10:12:58 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-04-30 for you to fetch changes up to 8598eb781cf68fd6cb67c479f1479ae58bd54fb9: drm/i915: Use proper fault mask in interrupt postinstall too (2020-04-28 16:38:03 -0700) - Fix selftest refcnt leak (Xiyu) - Fix gem vma lock (Chris) - Fix gt's i915_request.timeline acquire by checking if cacheline is valid (Chris) - Fix IRQ postinistall fault masks (Matt) Chris Wilson (2): drm/i915/gem: Hold obj->vma.lock over for_each_ggtt_vma() drm/i915/gt: Check cacheline is valid before acquiring Matt Roper (1): drm/i915: Use proper fault mask in interrupt postinstall too Xiyu Yang (1): drm/i915/selftests: Fix i915_address_space refcnt leak drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 20 ++-- drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 drivers/gpu/drm/i915/gt/intel_timeline.c| 2 ++ drivers/gpu/drm/i915/i915_irq.c | 6 ++ drivers/gpu/drm/i915/i915_vma.c | 10 ++ 5 files changed, 36 insertions(+), 14 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 4/8] drm: imx: Add i.MX 6 MIPI DSI host platform driver
On Tue, Apr 28, 2020 at 10:08:04PM +0300, Adrian Ratiu wrote: > Hi Daniel, > > On Tue, 28 Apr 2020, Daniel Vetter wrote: > > On Wed, Apr 22, 2020 at 04:07:27AM +0300, Laurent Pinchart wrote: > > > Hi Adrian, On Tue, Apr 21, 2020 at 07:16:06PM +0300, Adrian Ratiu > > > wrote: > This adds support for the Synopsis DesignWare MIPI DSI > > > v1.01 > host controller which is embedded in i.MX 6 SoCs. Based on > > > > following patches, but updated/extended to work with existing > > > > support found in the kernel: - drm: imx: Support Synopsys > > > > DesignWare MIPI DSI host controller > Signed-off-by: Liu Ying > > > > Cc: Fabio Estevam > > > Cc: Enric Balletbo > Serra Reviewed-by: Emil > > > Velikov > Tested-by: Adrian Pop > > > > Tested-by: Arnaud Ferraris > > > > Signed-off-by: Sjoerd Simons > > > > Signed-off-by: Martyn Welch > > > > Signed-off-by: Adrian Ratiu > > > > --- Changes since v6: > - Replaced > > > custom noop encoder with the simple drm encoder > (Enric) - Added > > > CONFIG_DRM_IMX6_MIPI_DSI depends on > CONFIG_OF (Enric) - Dropped > > > imx_mipi_dsi_register() because > now it only creates the dummy > > > encoder which can easily be > done directly in imx_dsi_bind() > > > > Changes since v5: > - Reword to remove unrelated device tree patch > > > mention > (Fabio) - Move pllref_clk enable/disable to bind/unbind > > > > (Ezequiel) - Fix freescale.com -> nxp.com email addresses > > > > (Fabio) - Also added myself as module author (Fabio) - Use > > > > DRM_DEV_* macros for consistency, print more error msg > Changes > > > since v4: > - Split off driver-specific configuration of phy > > > timings > due to new upstream API. - Move regmap infrastructure > > > > logic to separate commit (Ezequiel) - Move dsi v1.01 layout > > > > addition to a separate commit (Ezequiel) - Minor warnings > and > > > driver name fixes > Changes since v3: > - Renamed platform driver > > > to reflect it's i.MX6 > only. (Fabio) > Changes since v2: > - > > > Fixed commit tags. (Emil) > Changes since v1: > - Moved register > > > definitions & regmap initialization into > bridge module. Platform > > > drivers get the regmap via > plat_data after calling the bridge > > > probe. (Emil) > --- > drivers/gpu/drm/imx/Kconfig| 8 > > > + > drivers/gpu/drm/imx/Makefile | 1 + > > > > drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 391 > > > > + 3 files changed, 400 insertions(+) > > > > create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c > diff > > > --git a/drivers/gpu/drm/imx/Kconfig > b/drivers/gpu/drm/imx/Kconfig > > > index > 207bf7409dfba..0dffc72df7922 100644 --- > > > > a/drivers/gpu/drm/imx/Kconfig +++ > b/drivers/gpu/drm/imx/Kconfig @@ > > > -39,3 +39,11 @@ config > DRM_IMX_HDMI > depends on DRM_IMX help > > > Choose this if you want to use > HDMI on i.MX6. > + +config > > > DRM_IMX6_MIPI_DSI + tristate "Freescale i.MX6 > DRM MIPI DSI" > > > + select DRM_DW_MIPI_DSI +depends on > DRM_IMX + depends on OF > > > + help +Choose this if you want > to use MIPI DSI on i.MX6. diff > > > --git > a/drivers/gpu/drm/imx/Makefile > > > b/drivers/gpu/drm/imx/Makefile > index 21cdcc2faabc8..9a7843c593478 > > > 100644 --- > a/drivers/gpu/drm/imx/Makefile +++ > > > > b/drivers/gpu/drm/imx/Makefile @@ -9,3 +9,4 @@ > > > > obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o > obj-$(CONFIG_DRM_IMX_LDB) > > > += imx-ldb.o > obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o > > > > +obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o diff > --git > > > a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c > > > > b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c new file mode 100644 > > > > index 0..f8a0a4fe16e21 --- /dev/null +++ > > > > b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c @@ -0,0 +1,391 @@ > +// > > > SPDX-License-Identifier: GPL-2.0+ +/* + * i.MX6 drm > driver - MIPI > > > DSI Host Controller + * + * Copyright (C) > 2011-2015 Freescale > > > Semiconductor, Inc. + * Copyright (C) > 2019-2020 Collabora, Ltd. > > > + */ + +#include > +#include > > > +#include > +#include > > > +#include > > > > +#include +#include > +#include > > > +#include > +#include > > > > +#include +#include > > > > +#include + +#include "imx-drm.h" > > > + > +#define DSI_PWR_UP 0x04 +#define > RESET > > > 0 +#define > > > POWERUP > BIT(0) + +#define DSI_PHY_IF_CTRL 0x5c > > > > +#define > > > PHY_IF_CTRL_RESET 0x0 + +#define > DSI_PHY_TST_CTRL0 > > > 0x64 +#define > > > PHY_TESTCLK > BIT(1) +#define PHY_UNTESTCLK 0 > > > +#define > > > > PHY_TESTCLR BIT(0) +#define > PHY_UNTESTCLR > > > 0 + +#define > > > > DSI_PHY_TST_CTRL1 0x68 +#define PHY_TESTEN > BIT(16) +#define > > > PHY_UNTESTEN 0 +#define > PHY_TESTDOUT(n) > > > (((n) & 0xff) << 8) > > > >
Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
On Thu, Apr 30, 2020 at 09:47:46PM +0800, Xin Ji wrote:
> Hi Daniel,
>
> On Thu, Apr 30, 2020 at 03:38:39PM +0200, Daniel Vetter wrote:
> > On Thu, Apr 30, 2020 at 03:37:31PM +0200, Daniel Vetter wrote:
> > > On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> > > > On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > > > > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > > > > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Just commenting on the mode_fixup function that was added in v7.
> > > > > > > >
> > > > > > > [snip]
> > > > > > > > > + /*
> > > > > > > > > +* once illegal timing detected, use default HFP,
> > > > > > > > > HSYNC, HBP
> > > > > > > > > +*/
> > > > > > > > > + if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp
> > > > > > > > > < HP_MIN)) {
> > > > > > > >
> > > > > > > > should this be adj_hblanking/adj_hfp/adj_hbp?
> > > > > > > NO, need check original HFP and HBP, if they are not legal,
> > > > > > > driver need
> > > > > > > set default value to adj_hsync, adj_hfp, adj_hbp.
> > > > > > > >
> > > > > > > > > + adj_hsync = SYNC_LEN_DEF;
> > > > > > > > > + adj_hfp = HFP_HBP_DEF;
> > > > > > > > > + adj_hbp = HFP_HBP_DEF;
> > > > > > > > > + vref = adj->clock * 1000 / (adj->htotal *
> > > > > > > > > adj->vtotal);
> > > > > > > > > + if (hblanking < HBLANKING_MIN) {
> > > > > > > > > + delta_adj = HBLANKING_MIN - hblanking;
> > > > > > > > > + adj_clock = vref * delta_adj *
> > > > > > > > > adj->vtotal;
> > > > > > > > > + adj->clock += DIV_ROUND_UP(adj_clock,
> > > > > > > > > 1000);
> > > > > > > > > + } else {
> > > > > > > > > + delta_adj = hblanking - HBLANKING_MIN;
> > > > > > > > > + adj_clock = vref * delta_adj *
> > > > > > > > > adj->vtotal;
> > > > > > > > > + adj->clock -= DIV_ROUND_UP(adj_clock,
> > > > > > > > > 1000);
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + DRM_WARN("illegal hblanking timing, use
> > > > > > > > > default.\n");
> > > > > > > > > + DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp,
> > > > > > > > > hbp, hsync);
> > > > > > > >
> > > > > > > > How likely is it that this mode is going to work? Can you just
> > > > > > > > return
> > > > > > > > false here to reject the mode?
> > > > > > > We want to set the default minimal Hblancking value, then it may
> > > > > > > display,
> > > > > > > otherwise. If we just return false, there is no display for sure.
> > > > > >
> > > > > > Right, understand your argument. I'm pondering if it's not just
> > > > > > better
> > > > > > to reject the mode rather than trying a timing that is definitely
> > > > > > quite different from what the monitor was asking for. No super
> > > > > > strong
> > > > > > opinion, I'll let other people on the list weigh in.
> > > > >
> > > > > Yeah mode_fixup is supposed to be used to adjust the mode in
> > > > > intermediate
> > > > > stages (e.g. if you go from progressive to interlaced only at the end
> > > > > of
> > > > > your pipeline or something like that). It's not meant for adjusting
> > > > > the
> > > > > mode yout actually put out through a hdmi or dp connector. For fixed
> > > > > panels adjusting modes to fit the panel is also fairly common, but
> > > > > not for
> > > > > external outputs.
> > > > >
> > > > > Since this is a DP bridge I'd say no adjusting, just reject what
> > > > > doesn't
> > > > > fit.
> > > > We have found some panel which HBP less than 8, if we reject to adjust
> > > > video timing, then there is no display. The customer does not accept it,
> > > > they push us to fix it, the only resolve way is to adjust timing.
> > >
> > > Are we talking about external DP screen here, or some built-in panel? For
> > > the later case we do a lot of mode adjusting in many drivers ...
> > >
> > > I haven't checked, by if our connector type is eDP then this should be all
> > > fine.
> >
> > Ok I read the patch now, you seem to support both. Would it work if we
> > make this adjustement conditional on it being an internal panel only? I
> > think that would be perfect.
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> Based on comments of V8, only keeped eDP built-in panel in V9 version,
> removed external DP screen support.
Ah even better. Then the above adjusting has my:
Acked-by: Daniel Vetter
Maybe add a comment to the code summarizing the discussion. Definitely
needs to be covered in the commit message.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH AUTOSEL 4.19 14/30] drm/amdgpu: Correctly initialize thermal controller for GPUs with Powerplay table v0 (e.g Hawaii)
From: Sandeep Raghuraman
[ Upstream commit bbc25dadc7ed19f9d6b2e30980f0eb4c741bb8bf ]
Initialize thermal controller fields in the PowerPlay table for Hawaii
GPUs, so that fan speeds are reported.
Signed-off-by: Sandeep Raghuraman
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/powerplay/hwmgr/processpptables.c | 26 +++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
index 925e17104f909..b9e08b06ed5db 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
@@ -983,6 +983,32 @@ static int init_thermal_controller(
struct pp_hwmgr *hwmgr,
const ATOM_PPLIB_POWERPLAYTABLE *powerplay_table)
{
+ hwmgr->thermal_controller.ucType =
+ powerplay_table->sThermalController.ucType;
+ hwmgr->thermal_controller.ucI2cLine =
+ powerplay_table->sThermalController.ucI2cLine;
+ hwmgr->thermal_controller.ucI2cAddress =
+ powerplay_table->sThermalController.ucI2cAddress;
+
+ hwmgr->thermal_controller.fanInfo.bNoFan =
+ (0 != (powerplay_table->sThermalController.ucFanParameters &
+ ATOM_PP_FANPARAMETERS_NOFAN));
+
+ hwmgr->thermal_controller.fanInfo.ucTachometerPulsesPerRevolution =
+ powerplay_table->sThermalController.ucFanParameters &
+ ATOM_PP_FANPARAMETERS_TACHOMETER_PULSES_PER_REVOLUTION_MASK;
+
+ hwmgr->thermal_controller.fanInfo.ulMinRPM
+ = powerplay_table->sThermalController.ucFanMinRPM * 100UL;
+ hwmgr->thermal_controller.fanInfo.ulMaxRPM
+ = powerplay_table->sThermalController.ucFanMaxRPM * 100UL;
+
+ set_hw_cap(hwmgr,
+ ATOM_PP_THERMALCONTROLLER_NONE !=
hwmgr->thermal_controller.ucType,
+ PHM_PlatformCaps_ThermalController);
+
+ hwmgr->thermal_controller.use_hw_fan_control = 1;
+
return 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support)
On Wed, Apr 29, 2020 at 01:07:54PM +0300, Pekka Paalanen wrote: > On Tue, 28 Apr 2020 16:51:57 +0200 > Daniel Vetter wrote: > > > On Fri, Apr 24, 2020 at 11:32:16AM +0300, Pekka Paalanen wrote: > > > On Thu, 23 Apr 2020 17:01:49 +0200 > > > Daniel Vetter wrote: > > > > > > > On Tue, Apr 21, 2020 at 4:33 PM Pekka Paalanen > > > > wrote: > > > > > > > > > > On Tue, 21 Apr 2020 14:15:52 +0200 > > > > > Daniel Vetter wrote: > > > > > > > > > > > ... > > Hi, > > please skip to the TL;DR at the bottom, the rest is just how I ended up > there. > > > > > > > > > > Note that the kernel isn't entire consistent on this. I've looked a > > > > > > bit > > > > > > more closely at stuff. Ignoring content protection I've found > > > > > > following > > > > > > approaches things: > > > > > > > > > > > > - self refresh helpers, which are entirely transparent. Therefore > > > > > > we do a > > > > > > hack to set allow_modeset when the self-refresh helpers need to > > > > > > do a > > > > > > modeset, to avoid total surprise for userspace. I think this is > > > > > > only ok > > > > > > for these kind of behind-the-scenes helpers like self-refresh. > > > > > > > > > > > > - link-status is always reset to "good" when you include any > > > > > > connector, > > > > > > which might force a modeset. Even when allow_modeset isn't set by > > > > > > userspace. Maybe we should fix that, but we've discussed forever > > > > > > how to > > > > > > make sure a bad link isn't ever stuck at "bad" for old userspace, > > > > > > so > > > > > > we've gone with this. But maybe limiting to only allow_modeset > > > > > > cases > > > > > > would also work. > > > > > > > > > > Wait, what do you mean "include any connector"? > > > > > > > > > > What exactly could cause a modeset instead of failure when > > > > > ALLOW_MODESET is not set? > > > > > > > > If you do an atomic commit with the connector included that has the > > > > bad link status, then it'll reset it to Good to try to get a full > > > > modeset to restore stuff. If you don't also have ALLOW_MODESET set, > > > > it'll fail and userspace might be sad and not understand what's going > > > > on. We can easily fix this by only forcing the link training to be > > > > fixed if userspace has set ALLOW_MODESET. > > > > > > Hi, > > > > > > oh, that's ok, the fail case is there like it should. > > > > > > It sounded like even if userspace does not set ALLOW_MODESET, the > > > kernel would still do a modeset in come cases. I'm happy to have > > > misunderstood. > > > > Well currently that can go wrong, if you include a connector and a > > link-status is bad. But could be fixed fairly easily. > > What do you mean by "include a connector"? Which property on which > object? > > Weston always submits more or less full KMS state (known properties on > intended-active outputs) on all updates, on simple pageflips too, so I > am worried that the connector is "included", leading to automatic > papering over link-status failures, and Weston doesn't handle > link-status yet. Include a connector = you have a property for a connector included in your atomic update. Sounds like you do that, so if you have a real world link-status failure, then things go a bit boom already. I guess we need a kernel patch to make sure link-status only gets fixed when userspace is ok with a modeset. > Weston does this, because it is the easy thing to do and debug. You > don't have to track back thousands of frames to figure out what the > mode or the connectors are, when something doesn't work like it should. > Or to figure out why some state wasn't emitted when it was supposed to. > > > > > > > I'd probably not go there, a blind save does not guarantee a good > > > > > state. The fix to "Content Protection" is not necessary (as long as > > > > > userspace does not do a blind save/restore) if we can get the default > > > > > state from the kernel. If we get the default state from the kernel, > > > > > then userspace would be doing a blind restore but not save, meaning > > > > > that the state actually is sane and writable. > > > > > > > > > > I'd love to volunteer for writing the Weston code to make use of "get > > > > > me > > > > > sane default state" UAPI, but I'm afraid I'm not in that much control > > > > > of my time. > > > > > > > > The problem is, what is your default state? Driver defaults (generally > > > > fairly random and mostly everything is off)? After fbcon has done > > > > it's, which might never happen when you've disabling fbdev/fbcon? > > > > Boot-up state from the firmware for drivers like i915 that support > > > > fastboot (and what if that's garbage)? These can all be different too. > > > > > > I believe what I want is more or less the driver defaults, or DRM core > > > defaults for common KMS properties. It does not matter if they are > > > arbitrary, as long as they remain the same across kernel versions. They > > > need to
[PATCH AUTOSEL 5.4 25/57] drm/amdgpu: Correctly initialize thermal controller for GPUs with Powerplay table v0 (e.g Hawaii)
From: Sandeep Raghuraman
[ Upstream commit bbc25dadc7ed19f9d6b2e30980f0eb4c741bb8bf ]
Initialize thermal controller fields in the PowerPlay table for Hawaii
GPUs, so that fan speeds are reported.
Signed-off-by: Sandeep Raghuraman
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/powerplay/hwmgr/processpptables.c | 26 +++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
index 77c14671866c0..719597c5d27d9 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
@@ -984,6 +984,32 @@ static int init_thermal_controller(
struct pp_hwmgr *hwmgr,
const ATOM_PPLIB_POWERPLAYTABLE *powerplay_table)
{
+ hwmgr->thermal_controller.ucType =
+ powerplay_table->sThermalController.ucType;
+ hwmgr->thermal_controller.ucI2cLine =
+ powerplay_table->sThermalController.ucI2cLine;
+ hwmgr->thermal_controller.ucI2cAddress =
+ powerplay_table->sThermalController.ucI2cAddress;
+
+ hwmgr->thermal_controller.fanInfo.bNoFan =
+ (0 != (powerplay_table->sThermalController.ucFanParameters &
+ ATOM_PP_FANPARAMETERS_NOFAN));
+
+ hwmgr->thermal_controller.fanInfo.ucTachometerPulsesPerRevolution =
+ powerplay_table->sThermalController.ucFanParameters &
+ ATOM_PP_FANPARAMETERS_TACHOMETER_PULSES_PER_REVOLUTION_MASK;
+
+ hwmgr->thermal_controller.fanInfo.ulMinRPM
+ = powerplay_table->sThermalController.ucFanMinRPM * 100UL;
+ hwmgr->thermal_controller.fanInfo.ulMaxRPM
+ = powerplay_table->sThermalController.ucFanMaxRPM * 100UL;
+
+ set_hw_cap(hwmgr,
+ ATOM_PP_THERMALCONTROLLER_NONE !=
hwmgr->thermal_controller.ucType,
+ PHM_PlatformCaps_ThermalController);
+
+ hwmgr->thermal_controller.use_hw_fan_control = 1;
+
return 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 16/16] drm: Replace mode->export_head with a boolean
Hi Ville I don't fully grok the i915 changes to provide meaningful review. There are couple of small comments below, but regardless of those Patches 01-11 and 14-16 are: Reviewed-by: Emil Velikov On Tue, 28 Apr 2020 at 18:20, Ville Syrjala wrote: > The downside is that drm_mode_expose_to_userspace() gets to > iterate a few more modes. It already was O(n^2), now it's > a slightly worse O(n^2). > Personally I'd drop the O() sentence, or change it to It already was O(n^2), now it's slightly worse O((n+y)^2). > Another alternative would be a temp bitmask so we wouldn't have > to have anything in the mode struct itself. The main issue is > how large of a bitmask do we need? I guess we could allocate > it dynamically but that means an extra kcalloc() and an extra > loop through the modes to count them first (or grow the bitmask > with krealloc() as needed). > If the walk is even remotely close to being an issue, we could consider the bitmask. I don't think that's the case yet. Hmm the original code never discards any entries from export_head. I wonder if there's some corner case where we could end with an "old" mode showing in the list? For example: - creates a user mode via drmModeCreatePropertyBlob() - calls drmModeGetConnector() and sees their mode - optional (?) does a modeset to and away from said mode - removes their blob drmModeDestroyPropertyBlob() - calls drmModeGetConnector() and still sees their removed mode. If this is a bug (?) that we care about, we might want to add an igt test for it. Conversely, if this is a behaviour we want to keep this patch needs some work. HTH Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 01/57] drm/bridge: analogix_dp: Split bind() into probe() and real bind()
From: Marek Szyprowski
[ Upstream commit 83a196773b8bc6702f49df1eddc848180e350340 ]
Analogix_dp driver acquires all its resources in the ->bind() callback,
what is a bit against the component driver based approach, where the
driver initialization is split into a probe(), where all resources are
gathered, and a bind(), where all objects are created and a compound
driver is initialized.
Extract all the resource related operations to analogix_dp_probe() and
analogix_dp_remove(), then call them before/after registration of the
device components from the main Exynos DP and Rockchip DP drivers. Also
move the plat_data initialization to the probe() to make it available for
the analogix_dp_probe() function.
This fixes the multiple calls to the bind() of the DRM compound driver
when the DP PHY driver is not yet loaded/probed:
[drm] Exynos DRM: using 1440.fimd device for DMA mapping operations
exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops [exynosdrm])
exynos-drm exynos-drm: bound 1445.mixer (ops mixer_component_ops
[exynosdrm])
exynos-dp 145b.dp-controller: no DP phy configured
exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops exynos_dp_ops
[exynosdrm]): -517
exynos-drm exynos-drm: master bind failed: -517
...
[drm] Exynos DRM: using 1440.fimd device for DMA mapping operations
exynos-drm exynos-drm: bound 1440.fimd (ops hdmi_enable [exynosdrm])
exynos-drm exynos-drm: bound 1445.mixer (ops hdmi_enable [exynosdrm])
exynos-drm exynos-drm: bound 145b.dp-controller (ops hdmi_enable
[exynosdrm])
exynos-drm exynos-drm: bound 1453.hdmi (ops hdmi_enable [exynosdrm])
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Console: switching to colour frame buffer device 170x48
exynos-drm exynos-drm: fb0: exynosdrmfb frame buffer device
[drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1
...
Signed-off-by: Marek Szyprowski
Acked-by: Andy Yan
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20200310103427.26048-1-m.szyprow...@samsung.com
Signed-off-by: Sasha Levin
---
.../drm/bridge/analogix/analogix_dp_core.c| 33 +++--
drivers/gpu/drm/exynos/exynos_dp.c| 29 ---
.../gpu/drm/rockchip/analogix_dp-rockchip.c | 36 ++-
include/drm/bridge/analogix_dp.h | 5 +--
4 files changed, 61 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 22885dceaa177..1f26890a8da6e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1635,8 +1635,7 @@ static ssize_t analogix_dpaux_transfer(struct drm_dp_aux
*aux,
}
struct analogix_dp_device *
-analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
-struct analogix_dp_plat_data *plat_data)
+analogix_dp_probe(struct device *dev, struct analogix_dp_plat_data *plat_data)
{
struct platform_device *pdev = to_platform_device(dev);
struct analogix_dp_device *dp;
@@ -1739,22 +1738,30 @@ analogix_dp_bind(struct device *dev, struct drm_device
*drm_dev,
irq_flags, "analogix-dp", dp);
if (ret) {
dev_err(>dev, "failed to request irq\n");
- goto err_disable_pm_runtime;
+ return ERR_PTR(ret);
}
disable_irq(dp->irq);
+ return dp;
+}
+EXPORT_SYMBOL_GPL(analogix_dp_probe);
+
+int analogix_dp_bind(struct analogix_dp_device *dp, struct drm_device *drm_dev)
+{
+ int ret;
+
dp->drm_dev = drm_dev;
dp->encoder = dp->plat_data->encoder;
dp->aux.name = "DP-AUX";
dp->aux.transfer = analogix_dpaux_transfer;
- dp->aux.dev = >dev;
+ dp->aux.dev = dp->dev;
ret = drm_dp_aux_register(>aux);
if (ret)
- return ERR_PTR(ret);
+ return ret;
- pm_runtime_enable(dev);
+ pm_runtime_enable(dp->dev);
ret = analogix_dp_create_bridge(drm_dev, dp);
if (ret) {
@@ -1762,13 +1769,12 @@ analogix_dp_bind(struct device *dev, struct drm_device
*drm_dev,
goto err_disable_pm_runtime;
}
- return dp;
+ return 0;
err_disable_pm_runtime:
+ pm_runtime_disable(dp->dev);
- pm_runtime_disable(dev);
-
- return ERR_PTR(ret);
+ return ret;
}
EXPORT_SYMBOL_GPL(analogix_dp_bind);
@@ -1785,10 +1791,15 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
drm_dp_aux_unregister(>aux);
pm_runtime_disable(dp->dev);
- clk_disable_unprepare(dp->clock);
}
EXPORT_SYMBOL_GPL(analogix_dp_unbind);
+void analogix_dp_remove(struct analogix_dp_device *dp)
+{
+ clk_disable_unprepare(dp->clock);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_remove);
+
#ifdef CONFIG_PM
int
[PATCH AUTOSEL 5.6 39/79] drm/amdgpu: Correctly initialize thermal controller for GPUs with Powerplay table v0 (e.g Hawaii)
From: Sandeep Raghuraman
[ Upstream commit bbc25dadc7ed19f9d6b2e30980f0eb4c741bb8bf ]
Initialize thermal controller fields in the PowerPlay table for Hawaii
GPUs, so that fan speeds are reported.
Signed-off-by: Sandeep Raghuraman
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/powerplay/hwmgr/processpptables.c | 26 +++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
index 77c14671866c0..719597c5d27d9 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
@@ -984,6 +984,32 @@ static int init_thermal_controller(
struct pp_hwmgr *hwmgr,
const ATOM_PPLIB_POWERPLAYTABLE *powerplay_table)
{
+ hwmgr->thermal_controller.ucType =
+ powerplay_table->sThermalController.ucType;
+ hwmgr->thermal_controller.ucI2cLine =
+ powerplay_table->sThermalController.ucI2cLine;
+ hwmgr->thermal_controller.ucI2cAddress =
+ powerplay_table->sThermalController.ucI2cAddress;
+
+ hwmgr->thermal_controller.fanInfo.bNoFan =
+ (0 != (powerplay_table->sThermalController.ucFanParameters &
+ ATOM_PP_FANPARAMETERS_NOFAN));
+
+ hwmgr->thermal_controller.fanInfo.ucTachometerPulsesPerRevolution =
+ powerplay_table->sThermalController.ucFanParameters &
+ ATOM_PP_FANPARAMETERS_TACHOMETER_PULSES_PER_REVOLUTION_MASK;
+
+ hwmgr->thermal_controller.fanInfo.ulMinRPM
+ = powerplay_table->sThermalController.ucFanMinRPM * 100UL;
+ hwmgr->thermal_controller.fanInfo.ulMaxRPM
+ = powerplay_table->sThermalController.ucFanMaxRPM * 100UL;
+
+ set_hw_cap(hwmgr,
+ ATOM_PP_THERMALCONTROLLER_NONE !=
hwmgr->thermal_controller.ucType,
+ PHM_PlatformCaps_ThermalController);
+
+ hwmgr->thermal_controller.use_hw_fan_control = 1;
+
return 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.6 38/79] drm/amd/powerplay: fix resume failed as smu table initialize early exit
From: Prike Liang
[ Upstream commit 45a5e639548c459a5accebad340078e4e6e0e512 ]
When the amdgpu in the suspend/resume loop need notify the dpm disabled,
otherwise the smu table will be uninitialize and result in resume failed.
Signed-off-by: Prike Liang
Tested-by: Mengbing Wang
Reviewed-by: Alex Deucher
Reviewed-by: Huang Rui
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
index f7a1ce37227cd..4a52c310058d1 100644
--- a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
@@ -889,12 +889,17 @@ static int renoir_read_sensor(struct smu_context *smu,
static bool renoir_is_dpm_running(struct smu_context *smu)
{
+ struct amdgpu_device *adev = smu->adev;
+
/*
* Util now, the pmfw hasn't exported the interface of SMU
* feature mask to APU SKU so just force on all the feature
* at early initial stage.
*/
- return true;
+ if (adev->in_suspend)
+ return false;
+ else
+ return true;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.6 23/79] drm/scheduler: fix drm_sched_get_cleanup_job
From: Christian König [ Upstream commit 8623b5255ae7ccaf276aac3920787bf575fa6b37 ] We are racing to initialize sched->thread here, just always check the current thread. Signed-off-by: Christian König Reviewed-by: Andrey Grodzovsky Reviewed-by: Kent Russell Link: https://patchwork.freedesktop.org/patch/361303/ Signed-off-by: Sasha Levin --- drivers/gpu/drm/scheduler/sched_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index 60c4c6a1aac68..75737ec596141 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -687,7 +687,7 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched) */ if ((sched->timeout != MAX_SCHEDULE_TIMEOUT && !cancel_delayed_work(>work_tdr)) || - __kthread_should_park(sched->thread)) + kthread_should_park()) return NULL; spin_lock_irqsave(>job_list_lock, flags); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.6 20/79] drm/bridge: anx6345: set correct BPC for display_info of connector
From: Vasily Khoruzhick
[ Upstream commit 1e8a6ce9186dbf342eebc07cf14cae5e82164e03 ]
Some drivers (e.g. sun4i-drm) need this info to decide whether they
need to enable dithering. Currently driver reports what panel supports
and if panel supports 8 we don't get dithering enabled.
Hardcode BPC to 6 for now since that's the only BPC
that driver supports.
Fixes: 6aa192698089 ("drm/bridge: Add Analogix anx6345 support")
Signed-off-by: Vasily Khoruzhick
Acked-by: Jernej Skrabec
Signed-off-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/2020032953.2941405-1-anars...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 526507102c1ea..8d32fea84c75e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -485,6 +485,9 @@ static int anx6345_get_modes(struct drm_connector
*connector)
num_modes += drm_add_edid_modes(connector, anx6345->edid);
+ /* Driver currently supports only 6bpc */
+ connector->display_info.bpc = 6;
+
unlock:
if (power_off)
anx6345_poweroff(anx6345);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.6 02/79] drm/bridge: analogix_dp: Split bind() into probe() and real bind()
From: Marek Szyprowski
[ Upstream commit 83a196773b8bc6702f49df1eddc848180e350340 ]
Analogix_dp driver acquires all its resources in the ->bind() callback,
what is a bit against the component driver based approach, where the
driver initialization is split into a probe(), where all resources are
gathered, and a bind(), where all objects are created and a compound
driver is initialized.
Extract all the resource related operations to analogix_dp_probe() and
analogix_dp_remove(), then call them before/after registration of the
device components from the main Exynos DP and Rockchip DP drivers. Also
move the plat_data initialization to the probe() to make it available for
the analogix_dp_probe() function.
This fixes the multiple calls to the bind() of the DRM compound driver
when the DP PHY driver is not yet loaded/probed:
[drm] Exynos DRM: using 1440.fimd device for DMA mapping operations
exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops [exynosdrm])
exynos-drm exynos-drm: bound 1445.mixer (ops mixer_component_ops
[exynosdrm])
exynos-dp 145b.dp-controller: no DP phy configured
exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops exynos_dp_ops
[exynosdrm]): -517
exynos-drm exynos-drm: master bind failed: -517
...
[drm] Exynos DRM: using 1440.fimd device for DMA mapping operations
exynos-drm exynos-drm: bound 1440.fimd (ops hdmi_enable [exynosdrm])
exynos-drm exynos-drm: bound 1445.mixer (ops hdmi_enable [exynosdrm])
exynos-drm exynos-drm: bound 145b.dp-controller (ops hdmi_enable
[exynosdrm])
exynos-drm exynos-drm: bound 1453.hdmi (ops hdmi_enable [exynosdrm])
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Console: switching to colour frame buffer device 170x48
exynos-drm exynos-drm: fb0: exynosdrmfb frame buffer device
[drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1
...
Signed-off-by: Marek Szyprowski
Acked-by: Andy Yan
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20200310103427.26048-1-m.szyprow...@samsung.com
Signed-off-by: Sasha Levin
---
.../drm/bridge/analogix/analogix_dp_core.c| 33 +++--
drivers/gpu/drm/exynos/exynos_dp.c| 29 ---
.../gpu/drm/rockchip/analogix_dp-rockchip.c | 36 ++-
include/drm/bridge/analogix_dp.h | 5 +--
4 files changed, 61 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6effe532f8200..461eff94d2767 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1636,8 +1636,7 @@ static ssize_t analogix_dpaux_transfer(struct drm_dp_aux
*aux,
}
struct analogix_dp_device *
-analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
-struct analogix_dp_plat_data *plat_data)
+analogix_dp_probe(struct device *dev, struct analogix_dp_plat_data *plat_data)
{
struct platform_device *pdev = to_platform_device(dev);
struct analogix_dp_device *dp;
@@ -1740,22 +1739,30 @@ analogix_dp_bind(struct device *dev, struct drm_device
*drm_dev,
irq_flags, "analogix-dp", dp);
if (ret) {
dev_err(>dev, "failed to request irq\n");
- goto err_disable_pm_runtime;
+ return ERR_PTR(ret);
}
disable_irq(dp->irq);
+ return dp;
+}
+EXPORT_SYMBOL_GPL(analogix_dp_probe);
+
+int analogix_dp_bind(struct analogix_dp_device *dp, struct drm_device *drm_dev)
+{
+ int ret;
+
dp->drm_dev = drm_dev;
dp->encoder = dp->plat_data->encoder;
dp->aux.name = "DP-AUX";
dp->aux.transfer = analogix_dpaux_transfer;
- dp->aux.dev = >dev;
+ dp->aux.dev = dp->dev;
ret = drm_dp_aux_register(>aux);
if (ret)
- return ERR_PTR(ret);
+ return ret;
- pm_runtime_enable(dev);
+ pm_runtime_enable(dp->dev);
ret = analogix_dp_create_bridge(drm_dev, dp);
if (ret) {
@@ -1763,13 +1770,12 @@ analogix_dp_bind(struct device *dev, struct drm_device
*drm_dev,
goto err_disable_pm_runtime;
}
- return dp;
+ return 0;
err_disable_pm_runtime:
+ pm_runtime_disable(dp->dev);
- pm_runtime_disable(dev);
-
- return ERR_PTR(ret);
+ return ret;
}
EXPORT_SYMBOL_GPL(analogix_dp_bind);
@@ -1786,10 +1792,15 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
drm_dp_aux_unregister(>aux);
pm_runtime_disable(dp->dev);
- clk_disable_unprepare(dp->clock);
}
EXPORT_SYMBOL_GPL(analogix_dp_unbind);
+void analogix_dp_remove(struct analogix_dp_device *dp)
+{
+ clk_disable_unprepare(dp->clock);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_remove);
+
#ifdef CONFIG_PM
int
Re: [PATCH resend] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument
Hi Hans, On Fri, 21 Feb 2020 at 17:33, Hans de Goede wrote: > > drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching > a video= argument over calculating our own timings for the user specified > mode using CVT or GTF. > > But userspace code which is auto-configuring the mode may want to know that > the user has specified that mode on the kernel commandline so that it can > pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED. > > This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just > as we would do on the user-specified mode when no matching probed mode is > found. > > Signed-off-by: Hans de Goede I was skimming around wrt Ville's compact drm_display_mode series and noticed that this never landed. The commit brings extra consistency when dealing with user defined modes, and is: Reviewed-by: Emil Velikov Ville this may trivially conflict with your work. I suspect you can do the honours, and apply on top of your series? That is if you agree with the patch. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
On Thu, Apr 30, 2020 at 03:37:31PM +0200, Daniel Vetter wrote:
> On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> > On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji wrote:
> > > > >
> > > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Just commenting on the mode_fixup function that was added in v7.
> > > > > >
> > > > > [snip]
> > > > > > > + /*
> > > > > > > +* once illegal timing detected, use default HFP, HSYNC,
> > > > > > > HBP
> > > > > > > +*/
> > > > > > > + if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp <
> > > > > > > HP_MIN)) {
> > > > > >
> > > > > > should this be adj_hblanking/adj_hfp/adj_hbp?
> > > > > NO, need check original HFP and HBP, if they are not legal, driver
> > > > > need
> > > > > set default value to adj_hsync, adj_hfp, adj_hbp.
> > > > > >
> > > > > > > + adj_hsync = SYNC_LEN_DEF;
> > > > > > > + adj_hfp = HFP_HBP_DEF;
> > > > > > > + adj_hbp = HFP_HBP_DEF;
> > > > > > > + vref = adj->clock * 1000 / (adj->htotal *
> > > > > > > adj->vtotal);
> > > > > > > + if (hblanking < HBLANKING_MIN) {
> > > > > > > + delta_adj = HBLANKING_MIN - hblanking;
> > > > > > > + adj_clock = vref * delta_adj *
> > > > > > > adj->vtotal;
> > > > > > > + adj->clock += DIV_ROUND_UP(adj_clock,
> > > > > > > 1000);
> > > > > > > + } else {
> > > > > > > + delta_adj = hblanking - HBLANKING_MIN;
> > > > > > > + adj_clock = vref * delta_adj *
> > > > > > > adj->vtotal;
> > > > > > > + adj->clock -= DIV_ROUND_UP(adj_clock,
> > > > > > > 1000);
> > > > > > > + }
> > > > > > > +
> > > > > > > + DRM_WARN("illegal hblanking timing, use
> > > > > > > default.\n");
> > > > > > > + DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp,
> > > > > > > hbp, hsync);
> > > > > >
> > > > > > How likely is it that this mode is going to work? Can you just
> > > > > > return
> > > > > > false here to reject the mode?
> > > > > We want to set the default minimal Hblancking value, then it may
> > > > > display,
> > > > > otherwise. If we just return false, there is no display for sure.
> > > >
> > > > Right, understand your argument. I'm pondering if it's not just better
> > > > to reject the mode rather than trying a timing that is definitely
> > > > quite different from what the monitor was asking for. No super strong
> > > > opinion, I'll let other people on the list weigh in.
> > >
> > > Yeah mode_fixup is supposed to be used to adjust the mode in intermediate
> > > stages (e.g. if you go from progressive to interlaced only at the end of
> > > your pipeline or something like that). It's not meant for adjusting the
> > > mode yout actually put out through a hdmi or dp connector. For fixed
> > > panels adjusting modes to fit the panel is also fairly common, but not for
> > > external outputs.
> > >
> > > Since this is a DP bridge I'd say no adjusting, just reject what doesn't
> > > fit.
> > We have found some panel which HBP less than 8, if we reject to adjust
> > video timing, then there is no display. The customer does not accept it,
> > they push us to fix it, the only resolve way is to adjust timing.
>
> Are we talking about external DP screen here, or some built-in panel? For
> the later case we do a lot of mode adjusting in many drivers ...
>
> I haven't checked, by if our connector type is eDP then this should be all
> fine.
Ok I read the patch now, you seem to support both. Would it work if we
make this adjustement conditional on it being an internal panel only? I
think that would be perfect.
-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 v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji wrote:
> > > >
> > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote:
> > > > > Hi,
> > > > >
> > > > > Just commenting on the mode_fixup function that was added in v7.
> > > > >
> > > > [snip]
> > > > > > + /*
> > > > > > +* once illegal timing detected, use default HFP, HSYNC, HBP
> > > > > > +*/
> > > > > > + if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp <
> > > > > > HP_MIN)) {
> > > > >
> > > > > should this be adj_hblanking/adj_hfp/adj_hbp?
> > > > NO, need check original HFP and HBP, if they are not legal, driver need
> > > > set default value to adj_hsync, adj_hfp, adj_hbp.
> > > > >
> > > > > > + adj_hsync = SYNC_LEN_DEF;
> > > > > > + adj_hfp = HFP_HBP_DEF;
> > > > > > + adj_hbp = HFP_HBP_DEF;
> > > > > > + vref = adj->clock * 1000 / (adj->htotal *
> > > > > > adj->vtotal);
> > > > > > + if (hblanking < HBLANKING_MIN) {
> > > > > > + delta_adj = HBLANKING_MIN - hblanking;
> > > > > > + adj_clock = vref * delta_adj * adj->vtotal;
> > > > > > + adj->clock += DIV_ROUND_UP(adj_clock, 1000);
> > > > > > + } else {
> > > > > > + delta_adj = hblanking - HBLANKING_MIN;
> > > > > > + adj_clock = vref * delta_adj * adj->vtotal;
> > > > > > + adj->clock -= DIV_ROUND_UP(adj_clock, 1000);
> > > > > > + }
> > > > > > +
> > > > > > + DRM_WARN("illegal hblanking timing, use
> > > > > > default.\n");
> > > > > > + DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp,
> > > > > > hsync);
> > > > >
> > > > > How likely is it that this mode is going to work? Can you just return
> > > > > false here to reject the mode?
> > > > We want to set the default minimal Hblancking value, then it may
> > > > display,
> > > > otherwise. If we just return false, there is no display for sure.
> > >
> > > Right, understand your argument. I'm pondering if it's not just better
> > > to reject the mode rather than trying a timing that is definitely
> > > quite different from what the monitor was asking for. No super strong
> > > opinion, I'll let other people on the list weigh in.
> >
> > Yeah mode_fixup is supposed to be used to adjust the mode in intermediate
> > stages (e.g. if you go from progressive to interlaced only at the end of
> > your pipeline or something like that). It's not meant for adjusting the
> > mode yout actually put out through a hdmi or dp connector. For fixed
> > panels adjusting modes to fit the panel is also fairly common, but not for
> > external outputs.
> >
> > Since this is a DP bridge I'd say no adjusting, just reject what doesn't
> > fit.
> We have found some panel which HBP less than 8, if we reject to adjust
> video timing, then there is no display. The customer does not accept it,
> they push us to fix it, the only resolve way is to adjust timing.
Are we talking about external DP screen here, or some built-in panel? For
the later case we do a lot of mode adjusting in many drivers ...
I haven't checked, by if our connector type is eDP then this should be all
fine.
-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/radeon: cleanup coding style a bit
Am 30.04.20 um 13:00 schrieb Bernard:
发件人：Joe Perches
发送日期：2020-04-27 01:53:06
收件人："Christian König" ,Bernard Zhao ,Alex Deucher
,"David (ChunMing) Zhou" ,David Airlie
,Daniel Vetter
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
抄送人：opensource.ker...@vivo.com
主题：Re: [PATCH] drm/radeon: cleanup coding style a bit>On Sun, 2020-04-26 at
15:18 +0200, Christian König wrote:
Am 26.04.20 um 15:12 schrieb Bernard Zhao:
Maybe no need to check ws before kmalloc, kmalloc will check
itself, kmalloc`s logic is if ptr is NULL, kmalloc will just
return
Signed-off-by: Bernard Zhao
Reviewed-by: Christian König
I'm wondering why the automated scripts haven't found that one before.
because this pattern is
if (foo)
kfree(bar);
and the pattern looked for is:
if (foo)
kfree(foo);
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
[]
@@ -1211,8 +1211,7 @@ static int atom_execute_table_locked(struct atom_context
*ctx, int index, uint32
SDEBUG("<<\n");
free:
- if (ws)
- kfree(ectx.ws);
+ kfree(ectx.ws);
return ret;
}
I'm wondering if this removal is correct as the function
is named _locked and it may be recursive or called under
some external lock.
Hi
I am a little confused about this. I understand that the caller guarantees the
lock protection
that we will not release the wrong pointer. And the NULL check is the same with
the first check in kfree?
Maybe we do not need check twich.
I don't understand the comment either. When you look at the function you
see that code is freeing up the temporary allocated buffer which is to
large for the stack.
In other words we kcalloc() this buffer a few lines above and free it
here again. So I think the patch is perfectly valid.
What we could do is to update the coci pattern to catch this as well,
but this case is so rare that it is probably not worth it.
Regards,
Christian.
Regards,
Bernard
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: drm/amdgpu: Disable [1002:6611] in radeon
On Thu, Apr 30, 2020 at 9:08 AM Jian-Hong Pan wrote:
>
> The AMD/ATI Oland [1002:6611]'s HDMI output status is not synchronous
> as shown on UI after hot re-plug the HDMI cable, if it is radeon in
> used. The amdgpu module does not hit this issue.
>
> This patch disables [1002:6611] in radeon and enables it in amdgpu.
>
> Fixes: https://gitlab.freedesktop.org/drm/amd/-/issues/1117
> Signed-off-by: Jian-Hong Pan
Nack. Amdgpu does not have support for VCE or UVD yet so you are just
trading one issue for another. It would be better to figure out why
the audio is not updated properly in some cases.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
> include/drm/drm_pciids.h| 1 -
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 8ea86ffdea0d..1ad6f13a5bc0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1017,6 +1017,15 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
>
> static struct drm_driver kms_driver;
>
> +static void amdgpu_pci_fixup(struct pci_dev *pdev)
> +{
> +#ifdef CONFIG_DRM_AMDGPU_SI
> + /* [1002:6611] is disabled in radeon, so enable si_support in amdgpu.
> */
> + if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x6611)
> + amdgpu_si_support = 1;
> +#endif
> +}
> +
> static int amdgpu_pci_probe(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> {
> @@ -1036,6 +1045,8 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> return -ENODEV;
> }
>
> + amdgpu_pci_fixup(pdev);
> +
> #ifdef CONFIG_DRM_AMDGPU_SI
> if (!amdgpu_si_support) {
> switch (flags & AMD_ASIC_MASK) {
> diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
> index b7e899ce44f0..57368a0f5b82 100644
> --- a/include/drm/drm_pciids.h
> +++ b/include/drm/drm_pciids.h
> @@ -171,7 +171,6 @@
> {0x1002, 0x6607, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
> {0x1002, 0x6608, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_OLAND|RADEON_NEW_MEMMAP}, \
> {0x1002, 0x6610, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_OLAND|RADEON_NEW_MEMMAP}, \
> - {0x1002, 0x6611, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_OLAND|RADEON_NEW_MEMMAP}, \
> {0x1002, 0x6613, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_OLAND|RADEON_NEW_MEMMAP}, \
> {0x1002, 0x6617, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
> {0x1002, 0x6620, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
> --
> 2.26.2
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/amdgpu: remove set but not used variables
Reviewed-by: Christian König for the series. Am 30.04.20 um 04:26 schrieb Zheng Bin: Zheng Bin (3): drm/amdgpu: remove set but not used variable 'priority' drm/amdgpu: remove set but not used variable 'direct_poll' in vcn_v2_0.c drm/amdgpu: remove set but not used variable 'direct_poll' in vcn_v2_5.c drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 -- drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 3 --- drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 -- 3 files changed, 7 deletions(-) -- 2.26.0.106.g9fadedd ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave & Daniel, Fix for performance regression GitLab #1698: Iris Plus 655 and 4K screen. Missing workarounds for Tigerlake, and a fix for DP display audio WA. Unbreaking enable_dpcd_backlight, fixes to power code for Icelake+. Improvements to the soft-RC6 code to improve power efficiency, a fix for the timestamp corruption on Tigerlake and plenty of smaller fixes for CI found corner cases. Lots of refactoring that prep for upcoming changes, so I expect the next PR to be quite busy. Includes gvt-next-2020-04-22: Removes left non-upstream xen support bits which will be kept out of tree instead. And several guest context shadow optimizations. Regards, Joonas PS. Noticed the ack for locking rules, thanks! Will merge it. *** drm-intel-next-2020-04-30: Driver Changes: - Fix GitLab #1698: Performance regression with Linux 5.7-rc1 on Iris Plus 655 and 4K screen (Chris) - Add Wa_14011059788 for Tigerlake (Matt A) - Add per ctx batchbuffer wa for timestamp for Gen12 (Mika) - Use indirect ctx bb to load cmd buffer control value from context image to avoid corruption (Mika) - Enable DP Display Audio WA (Uma, Jani) - Update forcewake firmware ranges for Icelake (Radhakrishna) - Add missing deinitialization cases of load failure for display (Jose) - Implement TC cold sequences for Icelake and Tigerlake (Jose) - Unbreak enable_dpcd_backlight modparam (Lyude) - Move the late flush_submission in retire to the end (Chris) - Demote "Reducing compressed framebufer size" message to info (Peter) - Push MST link retraining to the hotplug work (Ville) - Hold obj->vma.lock over for_each_ggtt_vma() (Chris) - Fix timeout handling during TypeC AUX power well enabling for ICL (Imre) - Fix skl+ non-scaled pfit modes (Ville) - Prefer soft-rc6 over RPS DOWN_TIMEOUT (Chris) - Sanitize GT first before poisoning HWSP (Chris) - Fix up clock RPS frequency readout (Chris) - Avoid reusing the same logical CCID (Chris) - Avoid dereferencing a dead context (Chris) - Always enable busy-stats for execlists (Chris) - Apply the aggressive downclocking to parking (Chris) - Restore aggressive post-boost downclocking (Chris) - Scrub execlists state on resume (Chris) - Add debugfs attributes for LPSP (Ansuman) - Improvements to kernel selftests (Chris, Mika) - Add tiled blits selftest (Zbigniew) - Fix error handling in __live_lrc_indirect_ctx_bb() (Dan) - Add pre/post plane updates for SAGV (Stanislav) - Add ICL PG3 PW ID for EHL (Anshuman) - Fix Sphinx build duplicate label warning (Jani) - Error log non-zero audio power refcount after unbind (Jani) - Remove object_is_locked assertion from unpin_from_display_plane (Chris) - Use single set of AUX powerwell ops for gen11+ (Matt R) - Prefer drm_WARN_ON over WARN_ON (Pankaj) - Poison residual state [HWSP] across resume (Chris, Tvrtko) - Convert request-before-CS assertion to debug (Chris) - Carefully order virtual_submission_tasklet (Chris) - Check carefully for an idle engine in wait-for-idle (Chris) - Only close vma we open (Chris) - Trace RPS events (Chris) - Use the RPM config register to determine clk frequencies (Chris) - Drop rq->ring->vma peeking from error capture (Chris) - Check preempt-timeout target before submit_ports (Chris) - Check HWSP cacheline is valid before acquiring (Chris) - Use proper fault mask in interrupt postinstall too (Matt R) - Keep a no-frills swappable copy of the default context state (Chris) - Add atomic helpers for bandwidth (Stanislav) - Refactor setting dma info to a common helper from device info (Michael) - Refactor DDI transcoder code for clairty (Ville) - Extend PG3 power well ID to ICL (Anshuman) - Refactor PFIT code for readability and future extensibility (Ville) - Clarify code split between intel_ddi.c and intel_dp.c (Ville) - Move out code to return the digital_port of the aux ch (Jose) - Move rps.enabled/active and use of RPS interrupts to flags (Chris) - Remove superfluous inlines and dead code (Jani) - Re-disable -Wframe-address from top-level Makefile (Nick) - Static checker and spelling fixes (Colin, Nathan) - Split long lines (Ville) The following changes since commit b06ef327e26367b9286a2079b31cde8d2161c0d8: drm/i915: Update DRIVER_DATE to 20200417 (2020-04-17 09:35:00 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-04-30 for you to fetch changes up to 230982d8d8df7f9d9aa216840ea2db1df6ad5d37: drm/i915: Update DRIVER_DATE to 20200430 (2020-04-30 11:13:21 +0300) Driver Changes: - Fix GitLab #1698: Performance regression with Linux 5.7-rc1 on Iris Plus 655 and 4K screen (Chris) - Add Wa_14011059788 for Tigerlake (Matt A) - Add per ctx batchbuffer wa for timestamp for Gen12 (Mika) - Use indirect ctx bb to load cmd buffer control value from context image to avoid corruption (Mika) - Enable DP Display Audio WA (Uma, Jani) - Update forcewake firmware ranges for Icela
Re: [PATCH v2] drm: drm_fourcc: Add uncompressed AFBC modifier
On Thu, Apr 30, 2020 at 09:32:20AM +0100, Ben Davis wrote:
> AFBC has a mode that guarantees use of AFBC with an uncompressed
> payloads, we add a new modifier to support this mode.
>
> V2: updated modifier comment
>
> Signed-off-by: Ben Davis
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> include/uapi/drm/drm_fourcc.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 8bc0b31597d8..ec46c231af43 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -780,6 +780,18 @@ extern "C" {
> */
> #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
>
> +/* AFBC uncompressed storage mode
> + *
> + * Indicates that the buffer is using AFBC uncompressed storage mode.
> + * In this mode all superblock payloads in the buffer use the uncompressed
> + * storage mode, which is usually only used for data which cannot be
> compressed.
> + * The buffer layout is the same as for AFBC buffers without USM set, this
> only
> + * affects the storage mode of the individual superblocks. Note that even a
> + * buffer without USM set may use uncompressed storage mode for some or all
> + * superblocks, USM just guarantees it for all.
> + */
> +#define AFBC_FORMAT_MOD_USM (1ULL << 12)
> +
> /*
> * Arm 16x16 Block U-Interleaved modifier
> *
> --
> 2.24.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: pl111: enable render node
On Mon, 27 Apr 2020 at 16:58, Peter Collingbourne wrote: > > On Mon, Apr 27, 2020 at 7:45 AM Emil Velikov wrote: > > > > On Fri, 24 Apr 2020 at 19:54, Peter Collingbourne wrote: > > > > > > On Fri, Apr 24, 2020 at 4:11 AM Emil Velikov > > > wrote: > > > > > > > > On Thu, 23 Apr 2020 at 23:51, Peter Collingbourne > > > > wrote: > > > > > > > > > > The render node is required by Android which does not support the > > > > > legacy > > > > > drmAuth authentication process. > > > > > > > > > > Signed-off-by: Peter Collingbourne > > > > > --- > > > > > drivers/gpu/drm/pl111/pl111_drv.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > The summary talks about drmAuth, yet exposes a render node. Even > > > > through there's no rendering engine in the HW, as mentioned by Eric. > > > > > > > > AFAICT the only way drmAuth is relevant with pl111 is when you want to > > > > export/import dma bufs. > > > > Although that is handled in core and the artificial DRM_AUTH > > > > restriction has been lifted with commit [1]. > > > > > > > > -Emil > > > > > > > > [1] > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.7-rc2=30a958526d2cc6df38347336a602479d048d92e7 > > > > > > Okay, most likely drmAuth is irrelevant here (I don't know much about > > > it to be honest; I know that Android uses render nodes, so I figured > > > that drmAuth must therefore be the thing that it doesn't use). Sorry > > > for the confusion. Here is a better explanation of why I needed this > > > change. > > > > > > Android has a composer process that opens the primary node and uses > > > DRM_IOCTL_MODE_ATOMIC to switch between frame buffers, and a renderer > > > process (surfaceflinger) that opens the render node, prepares frame > > > buffers and sends them to the composer. One idea for adapting this > > > architecture to devices without render nodes is to have the renderer > > > process open the primary node instead. But this runs into a problem: > > > suppose that the renderer process starts before the composer process. > > > In this case, the kernel makes the renderer the DRM master, so the > > > composer can't change the frame buffer. Render nodes don't have this > > > problem because opening them doesn't affect the master. > > > > > > I considered fixing this by having the composer issue > > > DRM_IOCTL_SET_MASTER, but this requires root privileges. If we require > > > drivers to provide render nodes and control access to the primary node > > > while opening up the render node, we can ensure that only authorized > > > processes can become the master without requiring them to be root. > > > > > I think that the crux, is trying to open a _primary_ node for > > _rendering_ purposes. > > While that may work - as you outline above - it's usually a bad idea. > > > > To step back a bit, in practise we have three SoC combinations: > > - complete lack of render device - then you default to software rendering > > [1] > > - display and render device are one and the same - no change needed, > > things should just work > > - display and render devices are separate - surfaceflinger should > > open the correct _rendering_ device node. > > > > [1] Mesa's libEGL (don't recall exact name on Android) can open VGEM > > (Android uses SwiftShader for software rendering, not Mesa, FWIW.) > I don't know much about SwiftShader. > > render node, to work with the kms-swrast_dri.so software rasteriser > > module. > > > > While I did not try [1] with Android, it was working fine with CrOS. I > > suggest giving it a try and reporting bugs. > > I'm not sure I understand your suggestion, or at least how it would > work on Android. The composer process wouldn't be able to use > DRM_IOCTL_MODE_ATOMIC to display a frame buffer produced by the > surfaceflinger process using a vgem render node, would it? It's a > different driver so the memory region used for the frame buffer > wouldn't necessarily be compatible with the pl111 device. As far as I > know, the frame buffer would need to be produced using a pl111 render > node. > The pl111 will create a buffer, exports it. Renderer will import and draw onto it. Upon completion, the composer will DRM_IOCTL_MODE_ATOMIC the pl111 buffer. I believe this approach has been used for a few years now. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: pl111: enable render node
On Mon, 27 Apr 2020 at 17:48, Eric Anholt wrote:
>
> On Mon, Apr 27, 2020 at 7:45 AM Emil Velikov wrote:
> >
> > On Fri, 24 Apr 2020 at 19:54, Peter Collingbourne wrote:
> > >
> > > On Fri, Apr 24, 2020 at 4:11 AM Emil Velikov
> > > wrote:
> > > >
> > > > On Thu, 23 Apr 2020 at 23:51, Peter Collingbourne
> > > > wrote:
> > > > >
> > > > > The render node is required by Android which does not support the
> > > > > legacy
> > > > > drmAuth authentication process.
> > > > >
> > > > > Signed-off-by: Peter Collingbourne
> > > > > ---
> > > > > drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > The summary talks about drmAuth, yet exposes a render node. Even
> > > > through there's no rendering engine in the HW, as mentioned by Eric.
> > > >
> > > > AFAICT the only way drmAuth is relevant with pl111 is when you want to
> > > > export/import dma bufs.
> > > > Although that is handled in core and the artificial DRM_AUTH
> > > > restriction has been lifted with commit [1].
> > > >
> > > > -Emil
> > > >
> > > > [1]
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.7-rc2=30a958526d2cc6df38347336a602479d048d92e7
> > >
> > > Okay, most likely drmAuth is irrelevant here (I don't know much about
> > > it to be honest; I know that Android uses render nodes, so I figured
> > > that drmAuth must therefore be the thing that it doesn't use). Sorry
> > > for the confusion. Here is a better explanation of why I needed this
> > > change.
> > >
> > > Android has a composer process that opens the primary node and uses
> > > DRM_IOCTL_MODE_ATOMIC to switch between frame buffers, and a renderer
> > > process (surfaceflinger) that opens the render node, prepares frame
> > > buffers and sends them to the composer. One idea for adapting this
> > > architecture to devices without render nodes is to have the renderer
> > > process open the primary node instead. But this runs into a problem:
> > > suppose that the renderer process starts before the composer process.
> > > In this case, the kernel makes the renderer the DRM master, so the
> > > composer can't change the frame buffer. Render nodes don't have this
> > > problem because opening them doesn't affect the master.
> > >
> > > I considered fixing this by having the composer issue
> > > DRM_IOCTL_SET_MASTER, but this requires root privileges. If we require
> > > drivers to provide render nodes and control access to the primary node
> > > while opening up the render node, we can ensure that only authorized
> > > processes can become the master without requiring them to be root.
> > >
> > I think that the crux, is trying to open a _primary_ node for
> > _rendering_ purposes.
> > While that may work - as you outline above - it's usually a bad idea.
> >
> > To step back a bit, in practise we have three SoC combinations:
> > - complete lack of render device - then you default to software rendering
> > [1]
> > - display and render device are one and the same - no change needed,
> > things should just work
> > - display and render devices are separate - surfaceflinger should
> > open the correct _rendering_ device node.
> >
> > [1] Mesa's libEGL (don't recall exact name on Android) can open VGEM
> > render node, to work with the kms-swrast_dri.so software rasteriser
> > module.
> >
> > While I did not try [1] with Android, it was working fine with CrOS. I
> > suggest giving it a try and reporting bugs.
>
> VGEM is not a solution, because it doesn't coordinate caching behavior
> with your display node and so you get corruption if you try to to
> share dma-bufs between them. In cros it's used only for some tests as
> far as I've heard, and it's been a source of pain.
>
My understanding is that dma_buf_{begin,end}_cpu_access should be used
to handle the caching concerns.
Perhaps we're missing some calls, apart from the wc mmap Daniel mentioned?
Fwiw I've played around with CrOS for 30 minutes w/o any corruption.
Mind you it was a boot + casual web browsing.
> If we want to go the route of "kms-only nodes also provide a render
> node interface for doing swrast on", I think that would be a good
> idea, but we should do this at a core DRM level (probably "does this
> driver expose dma-buf? then also expose render nodes") rather than per
> kms driver.
This sounds doable, although I'm concerned about existing
applications, which do not expect this behaviour.
Be that mesa, compositors or otherwise.
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Tue, Apr 28, 2020 at 2:46 PM Peter Collingbourne wrote:
>
> Render nodes are not just useful for devices supporting GPU hardware
> acceleration. Even on devices that only support dumb frame buffers,
> they are useful in situations where composition (using software
> rasterization) and KMS are done in different processes with buffer
> sharing being used to send frame buffers between them. This is the
> situation on Android, where surfaceflinger is the compositor and the
> composer HAL uses KMS to display the buffers. Thus it is beneficial
> to expose render nodes on all devices that support buffer sharing.
>
> Because all drivers that currently support render nodes also support
> buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark
> devices as supporting render nodes, so remove it and just rely on
> the presence of a prime_handle_to_fd function pointer to determine
> whether buffer sharing is supported.
The idea behind render nodes is that you can freely pass these to
unpriviledged users, and nothing bad happens. That's why we have gpu
reset code in drivers, proper pagetables, and also (in at least the
solid drivers) ban code so that repeat offenders from userspace who
constantly submit endless batch buffers and funny stuff like that
can't DOS the gpu.
Ofc in practice there's hw issues and fun stuff like that sometimes,
and driver bugs, and all that. But that's the aspiration.
Now many of these display-only drivers need contiguous buffers, and
there's not endless amounts of that around. So if you allow random
clients to allocate buffers, they can easily exhaust that, and not
just upset the render side of the gpu, but essentially make it
impossible for a compositor to allocate more framebuffers. I don't
think that's a good idea.
I know there's hw like vc4 which needs contiguous buffers for
everything, but that's kinda the places where aspiration falls a bit
short.
So from that pov I'm a rather worried with handing out render rights
to everyone for these display-only buffers. It's not entirely
harmless.
-Daniel
>
> Signed-off-by: Peter Collingbourne
> ---
> Documentation/gpu/drm-uapi.rst | 9 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
> drivers/gpu/drm/drm_drv.c | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/lima/lima_drv.c | 2 +-
> drivers/gpu/drm/msm/msm_drv.c | 1 -
> drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
> drivers/gpu/drm/radeon/radeon_drv.c | 3 +--
> drivers/gpu/drm/tegra/drm.c | 2 +-
> drivers/gpu/drm/v3d/v3d_drv.c | 1 -
> drivers/gpu/drm/vc4/vc4_drv.c | 8
> drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_drv.c| 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> include/drm/drm_drv.h | 7 ---
> 19 files changed, 19 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..2769714ae75a 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -129,10 +129,11 @@ authenticate to a DRM-Master prior to getting GPU
> access. To avoid this
> step and to grant clients GPU access without authenticating, render
> nodes were introduced. Render nodes solely serve render clients, that
> is, no modesetting or privileged ioctls can be issued on render nodes.
> -Only non-global rendering commands are allowed. If a driver supports
> -render nodes, it must advertise it via the DRIVER_RENDER DRM driver
> -capability. If not supported, the primary node must be used for render
> -clients together with the legacy drmAuth authentication procedure.
> +Only non-global rendering commands are allowed. Drivers that support
> +:ref:`PRIME buffer sharing ` automatically
> +support render nodes. If a driver does not support render nodes,
> +the primary node must be used for render clients together with the
> +legacy drmAuth authentication procedure.
>
> If a driver advertises render node support, DRM core will create a
> separate render node called renderD. There will be one render node
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 8ea86ffdea0d..46460620bc37 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1426,7 +1426,7 @@ static struct drm_driver kms_driver = {
> .driver_features =
> DRIVER_ATOMIC |
> DRIVER_GEM |
> - DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ |
> + DRIVER_MODESET | DRIVER_SYNCOBJ |
> DRIVER_SYNCOBJ_TIMELINE,
> .open = amdgpu_driver_open_kms,
> .postclose =
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Thu, Apr 30, 2020 at 12:30 PM Brian Starkey wrote: > > On Wed, Apr 29, 2020 at 06:31:01PM +0100, Liviu Dudau wrote: > > On Wed, Apr 29, 2020 at 09:51:19AM -0700, Peter Collingbourne wrote: > > > On Wed, Apr 29, 2020 at 9:17 AM Brian Starkey > > > wrote: > > > > > > > > Hi Peter, > > > > > > > > On Mon, Apr 27, 2020 at 01:05:13PM -0700, Peter Collingbourne wrote: > > > > > Render nodes are not just useful for devices supporting GPU hardware > > > > > acceleration. Even on devices that only support dumb frame buffers, > > > > > they are useful in situations where composition (using software > > > > > rasterization) and KMS are done in different processes with buffer > > > > > sharing being used to send frame buffers between them. This is the > > > > > situation on Android, where surfaceflinger is the compositor and the > > > > > composer HAL uses KMS to display the buffers. Thus it is beneficial > > > > > to expose render nodes on all devices that support buffer sharing. > > > > > > > > If I understand your problem right, the issue is that you're getting > > > > your buffers in minigbm via pl111, which means you want a render node > > > > just for buffer allocation? Then HWComposer will import those on the > > > > primary node for displaying. > > > > > > Correct. > > > > > > > I'm not at all familiar with how minigbm sits in Android, but on our > > > > platforms where the Display and GPU devices are different, we allocate > > > > via ion in Gralloc, and import those into both the GPU and Display. > > > > I think that should work on pl111 too - if you can allocate contiguous > > > > memory from ion (or dma-buf heaps) in minigbm, then you don't need the > > > > render node. > > > > > > Those contiguous memory regions would not necessarily be compatible > > > with the pl111 device as far as I know -- according to [1], on some > > > devices, a designated memory region must be used for the framebuffer > > > and therefore the memory region allocated in CMA would not be > > > compatible. That being said, FVP doesn't appear to be one of those > > > devices, so in principle that might work for FVP (provided that the > > > user provides a sufficiently large cma=X kernel command line > > > argument), but not for those other devices. > > Yeah I'd be surprised if FVP cares about anything other than it being > contiguous. > > My understanding of how "most" Android devices implement this is to > have ion heaps representing whatever dedicated memory regions there > are. Gralloc can then pick the appropriate one based on the gralloc > usage flags. So allocations wouldn't go via the DRM driver. > > It looks like the checks in pl111 can't support that usage model if > use_device_memory is set (though that wouldn't matter on FVP). > > > > > We have been doing that with mali-dp drivers for years. Because most of > > our dev environments are on FPGAs, we needed to use the local RAM on > > those boards so we've had to assign a memory region to the driver that > > in turn was using CMA. We've made heavy use of 'reserved-memory' and > > 'memory-region' nodes in the DT to link the two together, but things > > worked out quite well. Because the 'reserved-memory' sub-node was marked > > as 'compatible="shared-dma-pool"', gralloc and ION could be used to > > allocate memory from it. > > This is a little imperfect because ion doesn't have a way to access > the `dev` pointer needed to allocate from device-attached CMA regions, > so some hackery is required. > > I think dma-heaps would let you expose device-specific CMA regions. The plan was that each device in sysfs which needs special dma memory would have a pointer to the corresponding dma-heap. That way userspace knows where to allocate. Just need some userspace to use these, and kernel patch to expose those links. I think it's defacto already there through the dma pointers of struct device. -Daniel > > Even if you did that and allocated from the right place, the check > in pl111 would reject any attempt to import it if it's set to > use_device_memory. > > I don't know if there's a better way to tell if the memory is > compatible, but that check seems like a bit of a sledgehammer. It > looks like it not only forces the memory to be from the right place, > it also forces it to have been allocated via pl111. > > On FVP though, I reckon any old CMA memory should be fine. > > Cheers, > -Brian > > > > > Best regards, > > Liviu > > > > > > > > Peter > > > > > > [1] > > > https://www.kernel.org/doc/Documentation/devicetree/bindings/display/arm%2Cpl11x.txt > > > > -- > > > > | I would like to | > > | fix the world, | > > | but they're not | > > | giving me the | > > \ source code! / > > --- > > ¯\_(ツ)_/¯ > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365
Re: [PATCH 01/10] backlight: Add backlight_device_get_by_name()
Den 30.04.2020 12.15, skrev Lee Jones: > On Thu, 30 Apr 2020, Noralf Trønnes wrote: > >> >> >> Den 30.04.2020 10.32, skrev Lee Jones: >>> On Wed, 29 Apr 2020, Noralf Trønnes wrote: >>> Add a way to lookup a backlight device based on its name. Will be used by a USB display gadget getting the name from configfs. Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Signed-off-by: Noralf Trønnes --- drivers/video/backlight/backlight.c | 21 + include/linux/backlight.h | 1 + 2 files changed, 22 insertions(+) >>> >>> Once reviewed, can this patch be applied on its own? >>> >> >> If you can apply it for 5.8, then we're good. DRM has cutoff at -rc5 and >> the driver won't be ready for that. This patch has this dependency >> chain: usb -> drm -> backlight. So if you can apply it for 5.8, things >> gets easier. >> >>> My guess is that it can't, as the other patches in this set depend on >>> it, right? If this assumption is true, you need to send me the rest >>> of the set. >>> >>> FYI: It's normally better to send the whole set to everyone, as it >>> provides visibility on current review (or lack there of) status of the >>> other patches and allows each of the maintainers to discuss possible >>> merge strategies. >> >> dri-devel is the ML for backlight so I assumed you got the full set. > > dri-devel isn't the ML for Backlight. It's an interested party. Oh, I thought it was strange, but kernel development has all kinds of things that seems strange to me, so I just went with it. > > I certainly have no intention of subscribing to it. > >> I have had trouble in the past with my email provider dropping parts of >> a series when I had to many recipients. > > Without visibility into the other patches in the set, things become > more difficult. Maybe use a different/better email provider. > Yeah, you need to have context, I have resent the series to you, Daniel and Jingoo. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Wed, Apr 29, 2020 at 06:31:01PM +0100, Liviu Dudau wrote: > On Wed, Apr 29, 2020 at 09:51:19AM -0700, Peter Collingbourne wrote: > > On Wed, Apr 29, 2020 at 9:17 AM Brian Starkey wrote: > > > > > > Hi Peter, > > > > > > On Mon, Apr 27, 2020 at 01:05:13PM -0700, Peter Collingbourne wrote: > > > > Render nodes are not just useful for devices supporting GPU hardware > > > > acceleration. Even on devices that only support dumb frame buffers, > > > > they are useful in situations where composition (using software > > > > rasterization) and KMS are done in different processes with buffer > > > > sharing being used to send frame buffers between them. This is the > > > > situation on Android, where surfaceflinger is the compositor and the > > > > composer HAL uses KMS to display the buffers. Thus it is beneficial > > > > to expose render nodes on all devices that support buffer sharing. > > > > > > If I understand your problem right, the issue is that you're getting > > > your buffers in minigbm via pl111, which means you want a render node > > > just for buffer allocation? Then HWComposer will import those on the > > > primary node for displaying. > > > > Correct. > > > > > I'm not at all familiar with how minigbm sits in Android, but on our > > > platforms where the Display and GPU devices are different, we allocate > > > via ion in Gralloc, and import those into both the GPU and Display. > > > I think that should work on pl111 too - if you can allocate contiguous > > > memory from ion (or dma-buf heaps) in minigbm, then you don't need the > > > render node. > > > > Those contiguous memory regions would not necessarily be compatible > > with the pl111 device as far as I know -- according to [1], on some > > devices, a designated memory region must be used for the framebuffer > > and therefore the memory region allocated in CMA would not be > > compatible. That being said, FVP doesn't appear to be one of those > > devices, so in principle that might work for FVP (provided that the > > user provides a sufficiently large cma=X kernel command line > > argument), but not for those other devices. Yeah I'd be surprised if FVP cares about anything other than it being contiguous. My understanding of how "most" Android devices implement this is to have ion heaps representing whatever dedicated memory regions there are. Gralloc can then pick the appropriate one based on the gralloc usage flags. So allocations wouldn't go via the DRM driver. It looks like the checks in pl111 can't support that usage model if use_device_memory is set (though that wouldn't matter on FVP). > > We have been doing that with mali-dp drivers for years. Because most of > our dev environments are on FPGAs, we needed to use the local RAM on > those boards so we've had to assign a memory region to the driver that > in turn was using CMA. We've made heavy use of 'reserved-memory' and > 'memory-region' nodes in the DT to link the two together, but things > worked out quite well. Because the 'reserved-memory' sub-node was marked > as 'compatible="shared-dma-pool"', gralloc and ION could be used to > allocate memory from it. This is a little imperfect because ion doesn't have a way to access the `dev` pointer needed to allocate from device-attached CMA regions, so some hackery is required. I think dma-heaps would let you expose device-specific CMA regions. Even if you did that and allocated from the right place, the check in pl111 would reject any attempt to import it if it's set to use_device_memory. I don't know if there's a better way to tell if the memory is compatible, but that check seems like a bit of a sledgehammer. It looks like it not only forces the memory to be from the right place, it also forces it to have been allocated via pl111. On FVP though, I reckon any old CMA memory should be fine. Cheers, -Brian > > Best regards, > Liviu > > > > > Peter > > > > [1] > > https://www.kernel.org/doc/Documentation/devicetree/bindings/display/arm%2Cpl11x.txt > > -- > > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --- > ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] drm/mm: optimize rb_hole_addr rbtree search
On 4/30/20 12:15 PM, Chris Wilson wrote: Quoting Nirmoy Das (2020-04-30 10:58:39) +void insert_hole_addr(struct rb_root *root, struct drm_mm_node *node) ^ static Ah I forgot! (sparse [make C=1] or make W=1 will spot this) Thanks for the tip :) Nirmoy Looks good, I'll check more carefully later. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cnirmoy.das%40amd.com%7Cfa3f0888c45546cdd9c308d7ecef60eb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637238385206441661sdata=%2Fnn7QOOukYEcawU0bZ5WWjy99TVOpWouNPxlC8%2BW2FU%3Dreserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] backlight: Add backlight_device_get_by_name()
On Thu, 30 Apr 2020, Noralf Trønnes wrote: > > > Den 30.04.2020 10.32, skrev Lee Jones: > > On Wed, 29 Apr 2020, Noralf Trønnes wrote: > > > >> Add a way to lookup a backlight device based on its name. > >> Will be used by a USB display gadget getting the name from configfs. > >> > >> Cc: Lee Jones > >> Cc: Daniel Thompson > >> Cc: Jingoo Han > >> Signed-off-by: Noralf Trønnes > >> --- > >> drivers/video/backlight/backlight.c | 21 + > >> include/linux/backlight.h | 1 + > >> 2 files changed, 22 insertions(+) > > > > Once reviewed, can this patch be applied on its own? > > > > If you can apply it for 5.8, then we're good. DRM has cutoff at -rc5 and > the driver won't be ready for that. This patch has this dependency > chain: usb -> drm -> backlight. So if you can apply it for 5.8, things > gets easier. > > > My guess is that it can't, as the other patches in this set depend on > > it, right? If this assumption is true, you need to send me the rest > > of the set. > > > > FYI: It's normally better to send the whole set to everyone, as it > > provides visibility on current review (or lack there of) status of the > > other patches and allows each of the maintainers to discuss possible > > merge strategies. > > dri-devel is the ML for backlight so I assumed you got the full set. dri-devel isn't the ML for Backlight. It's an interested party. I certainly have no intention of subscribing to it. > I have had trouble in the past with my email provider dropping parts of > a series when I had to many recipients. Without visibility into the other patches in the set, things become more difficult. Maybe use a different/better email provider. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] drm/mm: optimize rb_hole_addr rbtree search
Quoting Nirmoy Das (2020-04-30 10:58:39) > +void insert_hole_addr(struct rb_root *root, struct drm_mm_node *node) ^ static (sparse [make C=1] or make W=1 will spot this) Looks good, I'll check more carefully later. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ast: Don't check new mode if CRTC is being disabled
Hi Am 30.04.20 um 11:22 schrieb Sam Ravnborg: > Hi Thomas. > > On Thu, Apr 30, 2020 at 11:13:30AM +0200, Thomas Zimmermann wrote: >> Suspending failed because there's no mode if the CRTC is being >> disabled. Early-out in this case. This fixes runtime PM for ast. >> >> Signed-off-by: Thomas Zimmermann > > Don't you miss: > > Reported-by: > Tested-by: Waiting for the reporter's ok. > Fixes: Indeed. :( Best regards Thomas > ??? > > Sam > >> --- >> drivers/gpu/drm/ast/ast_mode.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c >> index 7a9f20a2fd303..089b7d9a0cf3f 100644 >> --- a/drivers/gpu/drm/ast/ast_mode.c >> +++ b/drivers/gpu/drm/ast/ast_mode.c >> @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc >> *crtc, >> return -EINVAL; >> } >> >> +if (!state->enable) >> +return 0; /* no checks required if CRTC is being disabled */ >> + >> ast_state = to_ast_crtc_state(state); >> >> format = ast_state->format; >> -- >> 2.26.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 signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ast: Don't check new mode if CRTC is being disabled
Hi Thomas. On Thu, Apr 30, 2020 at 11:13:30AM +0200, Thomas Zimmermann wrote: > Suspending failed because there's no mode if the CRTC is being > disabled. Early-out in this case. This fixes runtime PM for ast. > > Signed-off-by: Thomas Zimmermann Don't you miss: Reported-by: Tested-by: Fixes: ??? Sam > --- > drivers/gpu/drm/ast/ast_mode.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c > index 7a9f20a2fd303..089b7d9a0cf3f 100644 > --- a/drivers/gpu/drm/ast/ast_mode.c > +++ b/drivers/gpu/drm/ast/ast_mode.c > @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc > *crtc, > return -EINVAL; > } > > + if (!state->enable) > + return 0; /* no checks required if CRTC is being disabled */ > + > ast_state = to_ast_crtc_state(state); > > format = ast_state->format; > -- > 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] backlight: Add backlight_device_get_by_name()
Den 30.04.2020 10.32, skrev Lee Jones:
> On Wed, 29 Apr 2020, Noralf Trønnes wrote:
>
>> Add a way to lookup a backlight device based on its name.
>> Will be used by a USB display gadget getting the name from configfs.
>>
>> Cc: Lee Jones
>> Cc: Daniel Thompson
>> Cc: Jingoo Han
>> Signed-off-by: Noralf Trønnes
>> ---
>> drivers/video/backlight/backlight.c | 21 +
>> include/linux/backlight.h | 1 +
>> 2 files changed, 22 insertions(+)
>
> Once reviewed, can this patch be applied on its own?
>
If you can apply it for 5.8, then we're good. DRM has cutoff at -rc5 and
the driver won't be ready for that. This patch has this dependency
chain: usb -> drm -> backlight. So if you can apply it for 5.8, things
gets easier.
> My guess is that it can't, as the other patches in this set depend on
> it, right? If this assumption is true, you need to send me the rest
> of the set.
>
> FYI: It's normally better to send the whole set to everyone, as it
> provides visibility on current review (or lack there of) status of the
> other patches and allows each of the maintainers to discuss possible
> merge strategies.
dri-devel is the ML for backlight so I assumed you got the full set.
I have had trouble in the past with my email provider dropping parts of
a series when I had to many recipients.
Noralf.
>
>> diff --git a/drivers/video/backlight/backlight.c
>> b/drivers/video/backlight/backlight.c
>> index cac3e35d7630..92d80aa0c0ef 100644
>> --- a/drivers/video/backlight/backlight.c
>> +++ b/drivers/video/backlight/backlight.c
>> @@ -432,6 +432,27 @@ struct backlight_device
>> *backlight_device_get_by_type(enum backlight_type type)
>> }
>> EXPORT_SYMBOL(backlight_device_get_by_type);
>>
>> +/**
>> + * backlight_device_get_by_name - Get backlight device by name
>> + * @name: Device name
>> + *
>> + * This function looks up a backlight device by its name. It obtains a
>> reference
>> + * on the backlight device and it is the caller's responsibility to drop the
>> + * reference by calling backlight_put().
>> + *
>> + * Returns:
>> + * A pointer to the backlight device if found, otherwise NULL.
>> + */
>> +struct backlight_device *backlight_device_get_by_name(const char *name)
>> +{
>> +struct device *dev;
>> +
>> +dev = class_find_device_by_name(backlight_class, name);
>> +
>> +return dev ? to_backlight_device(dev) : NULL;
>> +}
>> +EXPORT_SYMBOL(backlight_device_get_by_name);
>> +
>> /**
>> * backlight_device_unregister - unregisters a backlight device object.
>> * @bd: the backlight device object to be unregistered and freed.
>> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
>> index c7d6b2e8c3b5..56e4580d4f55 100644
>> --- a/include/linux/backlight.h
>> +++ b/include/linux/backlight.h
>> @@ -190,6 +190,7 @@ extern void backlight_force_update(struct
>> backlight_device *bd,
>> extern int backlight_register_notifier(struct notifier_block *nb);
>> extern int backlight_unregister_notifier(struct notifier_block *nb);
>> extern struct backlight_device *backlight_device_get_by_type(enum
>> backlight_type type);
>> +struct backlight_device *backlight_device_get_by_name(const char *name);
>> extern int backlight_device_set_brightness(struct backlight_device *bd,
>> unsigned long brightness);
>>
>> #define to_backlight_device(obj) container_of(obj, struct backlight_device,
>> dev)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/17] drm/mgag200: Remove HW cursor
Hi Thomas.
On Thu, Apr 30, 2020 at 10:10:53AM +0200, Thomas Zimmermann wrote:
> Hi Sam
>
> Am 29.04.20 um 19:51 schrieb Sam Ravnborg:
> > On Wed, Apr 29, 2020 at 04:32:22PM +0200, Thomas Zimmermann wrote:
> >> The HW cursor of Matrox G200 cards only supports a 16-color palette
> >> format. Univeral planes require at least ARGB or a similar component-
> >> based format. Converting a cursor image from ARGB to 16 colors does not
> >> produce pleasent-looking results in general, so remove the HW cursor.
> >
> > What impact does this have in useability?
> > Does the cursor behaviour stay the same or?
> >
> > The patch looks fine, but it seems a bit gross ditching curcor support.
> > But maybe it is the right choice, I dunno.
>
> As Gerd said, compositors will render software cursors. Theoretically,
> you could measure (maybe see) a difference. In practice not so much.
>
> I'd keep HW cursor support if it was useful, but it isn't. The HW
> supports 16-color palettes. That's simply not enough to be useful for
> most desktops.
Could you re-phrase this a little and add to the changelog.
So later if one wonders, get an explanation why removing the curosr
support is OK.
I think, with the above, I would not have questioned the removal.
With the updated changelog:
Acked-by: Sam Ravnborg
Sam
>
> The cursor image is ARGB. The old code used .set_cursor callbacks and
> returned an error if the ARGB format could not be fit into the 16-color
> palette. On errors, userspace switched to software cursors. From what I
> observed, I'd guess that GNOME et al already used SW cursors most of the
> time.
>
> With the new atomic interfaces and the dirtyfb ioctl, there's no way of
> signalling an error during palette conversion. So userspace wouldn't
> know if the HW cursor is visible.
>
> Alternatively to removing the code, the driver could dither the ARGB
> cursor image to 16 colors; no matter what the result looks like. But
> that's not an option IMHO.
>
> Best regards
> Thomas
>
> >
> > Sam
> >>
> >> Signed-off-by: Thomas Zimmermann
> >> ---
> >> drivers/gpu/drm/mgag200/Makefile | 2 +-
> >> drivers/gpu/drm/mgag200/mgag200_cursor.c | 319 ---
> >> drivers/gpu/drm/mgag200/mgag200_drv.h| 13 -
> >> drivers/gpu/drm/mgag200/mgag200_main.c | 7 -
> >> drivers/gpu/drm/mgag200/mgag200_mode.c | 2 -
> >> 5 files changed, 1 insertion(+), 342 deletions(-)
> >> delete mode 100644 drivers/gpu/drm/mgag200/mgag200_cursor.c
> >>
> >> diff --git a/drivers/gpu/drm/mgag200/Makefile
> >> b/drivers/gpu/drm/mgag200/Makefile
> >> index 04b281bcf6558..63403133638a3 100644
> >> --- a/drivers/gpu/drm/mgag200/Makefile
> >> +++ b/drivers/gpu/drm/mgag200/Makefile
> >> @@ -1,5 +1,5 @@
> >> # SPDX-License-Identifier: GPL-2.0-only
> >> -mgag200-y := mgag200_main.o mgag200_mode.o mgag200_cursor.o \
> >> +mgag200-y := mgag200_main.o mgag200_mode.o \
> >>mgag200_drv.o mgag200_i2c.o mgag200_ttm.o
> >>
> >> obj-$(CONFIG_DRM_MGAG200) += mgag200.o
> >> diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
> >> b/drivers/gpu/drm/mgag200/mgag200_cursor.c
> >> deleted file mode 100644
> >> index d491edd317ff3..0
> >> --- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
> >> +++ /dev/null
> >> @@ -1,319 +0,0 @@
> >> -// SPDX-License-Identifier: GPL-2.0-only
> >> -/*
> >> - * Copyright 2013 Matrox Graphics
> >> - *
> >> - * Author: Christopher Harvey
> >> - */
> >> -
> >> -#include
> >> -
> >> -#include "mgag200_drv.h"
> >> -
> >> -static bool warn_transparent = true;
> >> -static bool warn_palette = true;
> >> -
> >> -static int mgag200_cursor_update(struct mga_device *mdev, void *dst, void
> >> *src,
> >> - unsigned int width, unsigned int height)
> >> -{
> >> - struct drm_device *dev = mdev->dev;
> >> - unsigned int i, row, col;
> >> - uint32_t colour_set[16];
> >> - uint32_t *next_space = _set[0];
> >> - uint32_t *palette_iter;
> >> - uint32_t this_colour;
> >> - bool found = false;
> >> - int colour_count = 0;
> >> - u8 reg_index;
> >> - u8 this_row[48];
> >> -
> >> - memset(_set[0], 0, sizeof(uint32_t)*16);
> >> - /* width*height*4 = 16384 */
> >> - for (i = 0; i < 16384; i += 4) {
> >> - this_colour = ioread32(src + i);
> >> - /* No transparency */
> >> - if (this_colour>>24 != 0xff &&
> >> - this_colour>>24 != 0x0) {
> >> - if (warn_transparent) {
> >> - dev_info(>pdev->dev, "Video card doesn't
> >> support cursors with partial transparency.\n");
> >> - dev_info(>pdev->dev, "Not enabling
> >> hardware cursor.\n");
> >> - warn_transparent = false; /* Only tell the user
> >> once. */
> >> - }
> >> - return -EINVAL;
> >> - }
> >> - /* Don't need to store transparent pixels as colours */
> >> - if (this_colour>>24 == 0x0)
> >> -
[PATCH] drm/ast: Don't check new mode if CRTC is being disabled
Suspending failed because there's no mode if the CRTC is being disabled. Early-out in this case. This fixes runtime PM for ast. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_mode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 7a9f20a2fd303..089b7d9a0cf3f 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, return -EINVAL; } + if (!state->enable) + return 0; /* no checks required if CRTC is being disabled */ + ast_state = to_ast_crtc_state(state); format = ast_state->format; -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Msg "PM: pci_pm_suspend(): ast_pm_suspend+0x0/0x40 [ast] returns -22" after migrating to V5.6.7 kernel from v5.5.10.
Hi Cary
Am 29.04.20 um 20:26 schrieb Cary Garrett:
> Hello Thomas,
>
> Good news! After applying the patch and regenerating the ast kernel module,
> the system will
> successfully go into suspend state.
>
> Thanks for the fast turnaround. Glad I could help.
Great. Can I add your Reported-by and Tested-by tags to the patch?
Best regards
Thomas
>
> Regards, Cary.
>
> On Wed, 2020-04-29 at 11:14 +0200, Thomas Zimmermann wrote:
>> Hi Cary,
>>
>> thanks for reporting the bug.
>>
>> Am 28.04.20 um 22:32 schrieb Cary Garrett:
>>> Hello Dave,
>>>
>>> Generating & booting v5.5.19 kernel, system will successfully enter suspend
>>> state.
>>>
>>> Generating & booting v5.6.0 kernel, system fails to enter suspend state.
>>
>> It's related to
>>
>> 4961eb60f145 ("drm/ast: Enable atomic modesetting")
>>
>> Cary, attached is a patch that fixes the problem on my system. Are you
>> in a position to build and test your own kernels? If so, could you test
>> the attached patch and report back? Thanks!
>>
>> Best regards
>> Thomas
>>
>>> v5.5.19 "lspci - -s 00:04:00" output:
>>>
>>> 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics
>>> Family (rev 30)
>>> (prog-if
>>> 00 [VGA controller])
>>> DeviceName: Onboard VGA
>>> Subsystem: Super Micro Computer Inc ASPEED Graphics Family
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>> Stepping- SERR- FastB2B-
>>> DisINTx-
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>>> SERR-
>>> >> Latency: 0
>>> Interrupt: pin A routed to IRQ 16
>>> Region 0: Memory at f600 (32-bit, non-prefetchable) [size=16M]
>>> Region 1: Memory at f700 (32-bit, non-prefetchable) [size=128K]
>>> Region 2: I/O ports at d000 [size=128]
>>> Expansion ROM at 000c [virtual] [disabled] [size=128K]
>>> Capabilities: [40] Power Management version 3
>>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
>>> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>> Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+
>>> Address: Data:
>>> Kernel driver in use: ast
>>> Kernel modules: ast
>>>
>>> v5.6.0 "lspci - -s 00:04:00" output:
>>>
>>> 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics
>>> Family (rev 30)
>>> (prog-if
>>> 00 [VGA controller])
>>> DeviceName: Onboard VGA
>>> Subsystem: Super Micro Computer Inc ASPEED Graphics Family
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>> Stepping- SERR- FastB2B-
>>> DisINTx-
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>>> SERR-
>>> >> Latency: 0
>>> Interrupt: pin A routed to IRQ 16
>>> Region 0: Memory at f600 (32-bit, non-prefetchable) [size=16M]
>>> Region 1: Memory at f700 (32-bit, non-prefetchable) [size=128K]
>>> Region 2: I/O ports at d000 [size=128]
>>> Expansion ROM at 000c [virtual] [disabled] [size=128K]
>>> Capabilities: [40] Power Management version 3
>>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
>>> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>> Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+
>>> Address: Data:
>>> Kernel driver in use: ast
>>> Kernel modules: ast
>>>
>>>
>>> v5.5.19 "modinfo ast" output:
>>>
>>> filename: /lib/modules/5.5.19/kernel/drivers/gpu/drm/ast/ast.ko.xz
>>> license:GPL and additional rights
>>> description:AST
>>> author: Dave Airlie
>>> firmware: ast_dp501_fw.bin
>>> srcversion: ABBD643B3936ECA879F0CE8
>>> alias: pci:v1A03d2010sv*sd*bc03sc*i*
>>> alias: pci:v1A03d2000sv*sd*bc03sc*i*
>>> depends:drm,drm_kms_helper,drm_vram_helper,i2c-algo-bit
>>> retpoline: Y
>>> intree: Y
>>> name: ast
>>> vermagic: 5.5.19 SMP preempt mod_unload
>>> sig_id: PKCS#7
>>> signer: Build time autogenerated kernel key
>>> sig_key:1F:7D:19:82:14:6F:30:FF:FD:11:EF:72:8D:00:41:52:AA:7E:C7:26
>>> sig_hashalgo: sha512
>>> signature: A6:B0:FE:86:CD:71:93:67:1B:13:7B:C8:F7:4F:06:19:83:DA:0A:B3:
>>> 04:3A:F9:84:AA:84:BB:A1:86:A0:E6:94:03:EA:95:70:0A:D4:08:5E:
>>> 37:C6:8A:E0:4C:A9:09:E9:F0:F1:16:A9:7B:08:BD:B5:99:F1:4E:99:
>>> 3D:BF:78:37:54:90:6A:DF:8C:E8:AD:08:75:17:38:94:02:24:2F:27:
>>> 74:D7:F6:8D:0A:14:70:98:5C:95:3D:7F:D6:9A:38:39:DC:70:CF:37:
>>> EB:E5:06:88:92:31:84:CF:AD:E8:E2:94:77:69:7B:66:01:55:C6:B7:
>>> 20:21:B5:CB:89:84:97:FB:27:FF:65:D2:DD:EF:74:DC:6A:4A:68:72:
>>> 3A:2C:C9:CD:E6:62:0D:8F:FA:74:ED:C6:5E:F3:C8:52:19:23:66:9B:
>>> B5:56:98:78:C0:4A:3E:ED:6D:FF:E5:71:58:2E:0E:E0:EC:AD:19:62:
>>>
[PATCH v2] drm: drm_fourcc: Add uncompressed AFBC modifier
AFBC has a mode that guarantees use of AFBC with an uncompressed
payloads, we add a new modifier to support this mode.
V2: updated modifier comment
Signed-off-by: Ben Davis
---
include/uapi/drm/drm_fourcc.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d8..ec46c231af43 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -780,6 +780,18 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+/* AFBC uncompressed storage mode
+ *
+ * Indicates that the buffer is using AFBC uncompressed storage mode.
+ * In this mode all superblock payloads in the buffer use the uncompressed
+ * storage mode, which is usually only used for data which cannot be
compressed.
+ * The buffer layout is the same as for AFBC buffers without USM set, this only
+ * affects the storage mode of the individual superblocks. Note that even a
+ * buffer without USM set may use uncompressed storage mode for some or all
+ * superblocks, USM just guarantees it for all.
+ */
+#define AFBC_FORMAT_MOD_USM(1ULL << 12)
+
/*
* Arm 16x16 Block U-Interleaved modifier
*
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] backlight: Add backlight_device_get_by_name()
On Wed, 29 Apr 2020, Noralf Trønnes wrote:
> Add a way to lookup a backlight device based on its name.
> Will be used by a USB display gadget getting the name from configfs.
>
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Signed-off-by: Noralf Trønnes
> ---
> drivers/video/backlight/backlight.c | 21 +
> include/linux/backlight.h | 1 +
> 2 files changed, 22 insertions(+)
Once reviewed, can this patch be applied on its own?
My guess is that it can't, as the other patches in this set depend on
it, right? If this assumption is true, you need to send me the rest
of the set.
FYI: It's normally better to send the whole set to everyone, as it
provides visibility on current review (or lack there of) status of the
other patches and allows each of the maintainers to discuss possible
merge strategies.
> diff --git a/drivers/video/backlight/backlight.c
> b/drivers/video/backlight/backlight.c
> index cac3e35d7630..92d80aa0c0ef 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -432,6 +432,27 @@ struct backlight_device
> *backlight_device_get_by_type(enum backlight_type type)
> }
> EXPORT_SYMBOL(backlight_device_get_by_type);
>
> +/**
> + * backlight_device_get_by_name - Get backlight device by name
> + * @name: Device name
> + *
> + * This function looks up a backlight device by its name. It obtains a
> reference
> + * on the backlight device and it is the caller's responsibility to drop the
> + * reference by calling backlight_put().
> + *
> + * Returns:
> + * A pointer to the backlight device if found, otherwise NULL.
> + */
> +struct backlight_device *backlight_device_get_by_name(const char *name)
> +{
> + struct device *dev;
> +
> + dev = class_find_device_by_name(backlight_class, name);
> +
> + return dev ? to_backlight_device(dev) : NULL;
> +}
> +EXPORT_SYMBOL(backlight_device_get_by_name);
> +
> /**
> * backlight_device_unregister - unregisters a backlight device object.
> * @bd: the backlight device object to be unregistered and freed.
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index c7d6b2e8c3b5..56e4580d4f55 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -190,6 +190,7 @@ extern void backlight_force_update(struct
> backlight_device *bd,
> extern int backlight_register_notifier(struct notifier_block *nb);
> extern int backlight_unregister_notifier(struct notifier_block *nb);
> extern struct backlight_device *backlight_device_get_by_type(enum
> backlight_type type);
> +struct backlight_device *backlight_device_get_by_name(const char *name);
> extern int backlight_device_set_brightness(struct backlight_device *bd,
> unsigned long brightness);
>
> #define to_backlight_device(obj) container_of(obj, struct backlight_device,
> dev)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
