[Intel-gfx] [PATCH v3 1/2] drm: Wrap the check for atomic_commit implementation
Hi Dhinakaran,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20161222]
[cannot apply to v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Dhinakaran-Pandiyan/drm-Wrap-the-check-for-atomic_commit-implementation/20161222-174536
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: openrisc-allmodconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/vc4/vc4_crtc.c:34:0:
include/drm/drm_atomic.h: In function 'drm_drv_uses_atomic_modeset':
>> include/drm/drm_atomic.h:437:12: error: dereferencing pointer to incomplete
>> type
vim +437 include/drm/drm_atomic.h
431 *
432 * This check is useful if drivers do not have DRIVER_ATOMIC set but
433 * have atomic modesetting internally implemented.
434 */
435 static inline bool drm_drv_uses_atomic_modeset(struct drm_device *dev)
436 {
> 437 return dev->mode_config.funcs->atomic_commit != NULL;
438 }
439
440 #endif /* DRM_ATOMIC_H_ */
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 39268 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161223/1c13aad4/attachment-0001.gz>
[git pull] drm fixes for 4.10-rc1
Hi Linus, Some fixes came in while I was out, mostly intel and amdgpu ones, with one ast fix. If you can land them before -rc1 it would be good but I don't mind if they don't. Dave. The following changes since commit 50f6584e4c626b8fa39edb66f33fec27bab3996c: Merge tag 'leds_for_4.10_email_update' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds (2016-12-22 10:31:30 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-4.10-rc1 for you to fetch changes up to 4a401ceeef7bf3bc55f5e913cbf19d6038cf83c6: Merge tag 'drm-intel-next-fixes-2016-12-22' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2016-12-23 05:28:02 +1000) drm initial fixes for 4.10 (intel, amd) Chris Wilson (2): drm/i915: Reorder phys backing storage release drm/i915: Fallback to single PAGE_SIZE segments for DMA remapping Daniel Vetter (1): drm/i915: tune down the fast link training vs boot fail Dave Airlie (3): Merge branch 'drm-next-4.10' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2016-12-22' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes Merge tag 'drm-intel-next-fixes-2016-12-22' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes Flora Cui (12): drm/amdgpu: fix cursor setting of dce6/dce8 drm/amdgpu: update golden setting/tiling table of tahiti drm/amdgpu: update golden setting for pitcairn drm/amdgpu: update rev id for pitcairn drm/amdgpu: update golden setting for hainan drm/amdgpu: update rev id for hainan drm/amdgpu: update golden setting for oland drm/amdgpu: update rev id for oland drm/amdgpu: update golden setting for verde drm/amdgpu: update rev id for verde drm/amdgpu: update tile table for verde drm/amdgpu: update tile table for oland/hainan Hans de Goede (3): drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting Imre Deak (2): drm/i915/gen9: Fix PCODE polling during CDCLK change notification drm/i915/gen9: Fix PCODE polling during SAGV disabling Matthew Auld (1): drm/i915: drop the struct_mutex when wedged or trying to reset Mika Kuoppala (1): drm/i915: Fix setting of boost freq tunable Paulo Zanoni (2): drm/i915: disable PSR by default on HSW/BDW drm/i915: skip the first 4k of stolen memory on everything >= gen8 Rex Zhu (9): drm/amdgpu: disable uvd pg on Tonga. drm/amdgpu: fix enable_cp_power_gating in gfx_v8.0. drm/amdgpu: fix init save/restore list in gfx_v8.0 drm/amdgpu: enable AMD_PG_SUPPORT_CP in Carrizo/Stoney. drm/amdgpu: always initialize gfx pg for gfx_v8.0. drm/amdgpu: fix pg can't be disabled by PG mask. drm/amdgpu: add new gfx cg flags. drm/amdgpu: initialize cg flags for tonga/polaris10/polaris11. drm/amdgpu: refine set clock gating for tonga/polaris Russell Currey (1): drivers/gpu/drm/ast: Fix infinite loop if read fails Tvrtko Ursulin (1): drm/i915: Fix use after free in logical_render_ring_init drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 - drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 935 - drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 249 +--- drivers/gpu/drm/amd/amdgpu/si.c| 442 +++--- drivers/gpu/drm/amd/amdgpu/vi.c| 211 +-- drivers/gpu/drm/amd/include/amd_shared.h | 4 + drivers/gpu/drm/ast/ast_main.c | 7 +- drivers/gpu/drm/i915/i915_drv.h| 2 + drivers/gpu/drm/i915/i915_gem.c| 79 ++- drivers/gpu/drm/i915/i915_gem_stolen.c | 5 +- drivers/gpu/drm/i915/i915_sysfs.c | 2 +- drivers/gpu/drm/i915/intel_bios.h | 12 +- drivers/gpu/drm/i915/intel_display.c | 31 +- drivers/gpu/drm/i915/intel_dp.c| 4 +- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 7 +- drivers/gpu/drm/i915/intel_lrc.c | 7 +- drivers/gpu/drm/i915/intel_pm.c| 109 +++- drivers/gpu/drm/i915/intel_psr.c | 10 +- drivers/gpu/drm/i915/intel_runtime_pm.c| 13 +- 20 files changed, 1409 insertions(+), 728 deletions(-)
[Intel-gfx] [PATCH v3 1/3] drm: Create new structure for HDMI info
Regards Shashank On 12/22/2016 5:26 PM, Ville Syrjälä wrote: > On Thu, Dec 22, 2016 at 10:02:26AM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 21-12-2016 15:29, Shashank Sharma wrote: >> >> [snip] >> >>> + >>> + /** >>> +* @edid_yuv420_dc_modes: bpc for deep color yuv420 encoding. >>> +* various sinks can support 10/12/16 bit per channel deep >>> +* color encoding. edid_yuv420_dc_modes = 0 means sink doesn't >>> +* support deep color yuv420 encoding. >>> +*/ >>> + u8 edid_yuv420_dc_modes; >>> + >>> + >>> +#define DRM_HFVSDB_SCDC_SUPPORT(1<<7) >>> +#define DRM_HFVSDB_SCDC_RR_CAP (1<<6) >>> +#define DRM_HFVSDB_SCRAMBLING (1<<3) >>> +#define DRM_HFVSDB_INDEPENDENT_VIEW(1<<2) >>> +#define DRM_HFVSDB_DUAL_VIEW (1<<1) >>> +#define DRM_HFVSDB_3D_OSD (1<<0) >>> + >>> + /** >>> +* @scdc_supported: Sink supports SCDC functionality. >>> +*/ >>> + bool scdc_supported; >>> + >>> + /** >>> +* @scdc_rr_cap: Sink has SCDC read request capability. >>> +*/ >>> + bool scdc_rr_cap; >>> + >>> + /** >>> +* @scrambling: Sync supports scrambling for <=340 Mcsc TMDS >>> +* char rates. Above 340 Mcsc rates, scrambling is always reqd. >>> +*/ >>> + bool scrambling; >>> + >>> + /** >>> +* @independent_view_3d: Sink supports 3d independent view signaling >>> +* in HF-VSIF. >>> +*/ >>> + bool independent_view_3d; >>> + >>> + /** >>> +* @dual_view_3d: Sink supports 3d dual view signaling in HF-VSIF. >>> +*/ >>> + bool dual_view_3d; >>> + >>> + /** >>> +* @osd_disparity_3d: Sink supports 3d osd disparity indication >>> +* in HF-VSIF. >>> +*/ >>> + bool osd_disparity_3d; >>> +}; >> [snip] >> >> I thought we agreed in only adding these fields >> (edid_yuv420_dc_modes, scdc_supported, scdc_rr_cap, scrambling, >> independent_view_3d, dual_view_3d, osd_disparity_3d) in patch 2. >> I think it makes sense because you are only using them after that >> patch. Though, I would like to hear more comments about this as I >> am quite new to dri-devel. > Generally you shouldn't add stuff you don't use. In this seires nothing > actually uses any of of this stuff, so I don't think we should add > any of it. > > The only piece of information actually used is the max TMDS clock, so > parsing that does make sense. But I think that might be buggy as the > patch will go ahead and parse both the old and new HDMI data blocks. > IIRC the spec did have some words about which one should be used in > which case. I don't think I spotted anything matching that in these > patches. > If I understood the spec right, H14B VSDB block should contain the max_tmds_clock value to be reflected for tmds_clock_rates <340Mhz, But if the sink supports tmds_rates above 340Mhz, it should set this field in hf-vsdb. Also, this field allows sinks to support higher color depths to lower resolutions, than it can support to higher resolutions. In this case, if this byte is hf-vsdb is set, max tmds clock should be picked from this block. Regards Shashank Regards Shashank
drm_mm crash with multi threads
An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161223/9a90c85e/attachment.html>
[PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On 12/20/2016 03:55 AM, Rob Herring wrote:
> On Wed, Dec 14, 2016 at 03:04:04PM +0900, Hoegeun Kwon wrote:
>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>> panel in the TM2 device.
>>
>> Signed-off-by: Donghwa Lee
>> Signed-off-by: Hyungwon Hwang
>> Signed-off-by: Hoegeun Kwon
>> ---
>> .../bindings/display/panel/samsung,s6e3ha2.txt | 52 ++
>> drivers/gpu/drm/panel/Kconfig | 6 +
>> drivers/gpu/drm/panel/Makefile | 1 +
>> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 756
>> +
>> 4 files changed, 815 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>> new file mode 100644
>> index 000..1f41f24
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>> @@ -0,0 +1,52 @@
>> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
>> +
>> +Required properties:
>> + - compatible: "samsung,s6e3ha2"
>> + - reg: the virtual channel number of a DSI peripheral
>> + - vdd3-supply: core voltage supply
>> + - vci-supply: voltage supply for analog circuits
>> + - reset-gpios: a GPIO spec for the reset pin
>> + - enable-gpios: a GPIO spec for the panel enable pin
>> + - te-gpios: a GPIO spec for the tearing effect synchronization signal
>> gpio pin
> Need to specify the GPIOs as active high or low.
Hi Rob Herring,
Thanks for point out. I will add "(active high or low)" after the
description of the GPIOs.
>> +
>> +Optional properties:
>> + - display-timings: timings for the connected panel as described by [1]
>> +
>> +The device node can contain one 'port' child node with one child
>> +'endpoint' node, according to the bindings defined in [2]. This
>> +node should describe panel's video bus.
>> +
>> +[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
>> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +Example:
>> +
>> +panel at 0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
> reg doesn't really work here unless this node is a child of the DSI
> controller node. But if it is a child node, then you don't need the OF
> graph.
The reg value is used in virtual child panel node so I think the reg
value is needed.
Please refer to the document below.
Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
Best Regards,
Hoegeun Kwon
>> +vdd3-supply = <&ldo27_reg>;
>> +vci-supply = <&ldo28_reg>;
>> +reset-gpios = <&gpg0 0 GPIO_ACTIVE_HIGH>;
>> +enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
>> +
>> +display-timings {
>> +timing-0 {
>> +clock-frequency = <0>;
>> +hactive = <1440>;
>> +vactive = <2560>;
>> +hfront-porch = <1>;
>> +hback-porch = <1>;
>> +hsync-len = <1>;
>> +vfront-porch = <1>;
>> +vback-porch = <15>;
>> +vsync-len = <1>;
>> +};
>> +};
>> +
>> +port {
>> +dsi_in: endpoint {
>> +remote-endpoint = <&dsi_out>;
>> +};
>> +};
>> +};
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 96488] [r600g]OpenCL driver causes segfault in ImageMagick's Histogram kernel
https://bugs.freedesktop.org/show_bug.cgi?id=96488 --- Comment #7 from nixscripter at gmail.com --- Normally, I would be asking in this comment if there is any progress on this, but I can tell there has been... change, at least. Now instead of crashing, it deadlocks the calling process waiting on a mutex. Forever, as far as I can tell. LLVM version: r289770 Mesa version: commit 47351b843a Perhaps this is more easily fixed? Or is this getting to the heart of the matter implied in comment 2? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161223/0fbbb327/attachment-0001.html>
[Intel-gfx] drm_mm crash with multi threads
On Thu, Dec 22, 2016 at 11:07 PM, Mark yao wrote: > Hi Chris Wilson > > We port drm_mm to my internal kernel, with high load test, found following > crash: > > [49451.856244] > == > [49451.856350] BUG: KASAN: wild-memory-access on address dead0108 > [49451.856379] Write of size 8 by task Binder:218_4/683 [49451.856417] CPU: > 2 PID: 683 Comm: Binder:218_4 Not tainted 4.4.36 #62 [49451.856443] Hardware > name: Rockchip RK3399 Excavator Board edp (Android) (DT) [49451.856469] Call > trace: [49451.856519] [] dump_backtrace+0x0/0x230 > [49451.856556] [] show_stack+0x14/0x1c [49451.856592] > [] dump_stack+0xa0/0xc8 [49451.856633] > [] kasan_report+0x110/0x4dc [49451.856670] > [] __asan_store8+0x24/0x7c [49451.856715] > [] drm_mm_insert_node_generic+0x2dc/0x464 [49451.856760] > [] rockchip_gem_iommu_map+0x60/0x158 [49451.856794] > [] rockchip_gem_create_object+0x278/0x488 [49451.856827] > [] rockchip_gem_create_with_handle+0x24/0x10c > [49451.856862] [] rockchip_gem_create_ioctl+0x3c/0x50 > [49451.856896] [] drm_ioctl+0x354/0x52c [49451.856939] > [] do_vfs_ioctl+0x670/0x78c [49451.856976] > [] SyS_ioctl+0x60/0x88 [49451.857009] [] > el0_svc_naked+0x24/0x28 > We only use drm_mm_insert_node_generic to alloc memory, and use > drm_mm_remove_node to release memory > > alloc/release maybe on difference threads. > > Seem the problem is threads problem, drm_mm seems is not threads safe, we > found drm_mm_insert_node_generic and drm_mm_remove_node > may access same resource with list ops, such as some mm->hole_stack. > > After use mutex lock protect drm_mm_remove_node and > drm_mm_insert_node_generic, the crash disappear. > > I'm not familiar with drm mm, Do you know how to fix it? I don't think drm_mm is intended to be thread safe, but instead the driver should provide whatever locking is needed before calling in to drm_mm. (And presumably you already need some lock to protect driver level data structures when creating/destroying gem objects.) BR, -R > Thanks. > > On 2016å¹´12æ17æ¥ 03:25, Chris Wilson wrote: > > With a lot of polish applied, Joonas has reviewed the series - all but > for [04/38] "lib: Add a simple prime number generator" > [lib/prime_numbers.c]. Anyone feel like poking around at a bit of number > theory? > > Other than it would appear to be ready for Daniel to sort out the merge > between drm-misc/i915... Please do take a look and see if you can spot > anything else that needs fixing/improving. > -Chris > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > ï¼ark Yao > > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx >
[Intel-gfx] drm_mm crash with multi threads
On 2016å¹´12æ23æ¥ 13:57, Rob Clark wrote: > On Thu, Dec 22, 2016 at 11:07 PM, Mark yao wrote: >> Hi Chris Wilson >> >> We port drm_mm to my internal kernel, with high load test, found following >> crash: >> >> [49451.856244] >> == >> [49451.856350] BUG: KASAN: wild-memory-access on address dead0108 >> [49451.856379] Write of size 8 by task Binder:218_4/683 [49451.856417] CPU: >> 2 PID: 683 Comm: Binder:218_4 Not tainted 4.4.36 #62 [49451.856443] Hardware >> name: Rockchip RK3399 Excavator Board edp (Android) (DT) [49451.856469] Call >> trace: [49451.856519] [] dump_backtrace+0x0/0x230 >> [49451.856556] [] show_stack+0x14/0x1c [49451.856592] >> [] dump_stack+0xa0/0xc8 [49451.856633] >> [] kasan_report+0x110/0x4dc [49451.856670] >> [] __asan_store8+0x24/0x7c [49451.856715] >> [] drm_mm_insert_node_generic+0x2dc/0x464 [49451.856760] >> [] rockchip_gem_iommu_map+0x60/0x158 [49451.856794] >> [] rockchip_gem_create_object+0x278/0x488 [49451.856827] >> [] rockchip_gem_create_with_handle+0x24/0x10c >> [49451.856862] [] rockchip_gem_create_ioctl+0x3c/0x50 >> [49451.856896] [] drm_ioctl+0x354/0x52c [49451.856939] >> [] do_vfs_ioctl+0x670/0x78c [49451.856976] >> [] SyS_ioctl+0x60/0x88 [49451.857009] [] >> el0_svc_naked+0x24/0x28 >> We only use drm_mm_insert_node_generic to alloc memory, and use >> drm_mm_remove_node to release memory >> >> alloc/release maybe on difference threads. >> >> Seem the problem is threads problem, drm_mm seems is not threads safe, we >> found drm_mm_insert_node_generic and drm_mm_remove_node >> may access same resource with list ops, such as some mm->hole_stack. >> >> After use mutex lock protect drm_mm_remove_node and >> drm_mm_insert_node_generic, the crash disappear. >> >> I'm not familiar with drm mm, Do you know how to fix it? > I don't think drm_mm is intended to be thread safe, but instead the > driver should provide whatever locking is needed before calling in to > drm_mm. (And presumably you already need some lock to protect driver > level data structures when creating/destroying gem objects.) > > BR, > -R Got it, I also see other's driver, all of them have a lock to protect memory creating/destorying. Thanks. > >> Thanks. >> >> On 2016å¹´12æ17æ¥ 03:25, Chris Wilson wrote: >> >> With a lot of polish applied, Joonas has reviewed the series - all but >> for [04/38] "lib: Add a simple prime number generator" >> [lib/prime_numbers.c]. Anyone feel like poking around at a bit of number >> theory? >> >> Other than it would appear to be ready for Daniel to sort out the merge >> between drm-misc/i915... Please do take a look and see if you can spot >> anything else that needs fixing/improving. >> -Chris >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> >> -- >> ï¼ark Yao >> >> >> ___ >> Intel-gfx mailing list >> Intel-gfx at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx >> > > -- ï¼ark Yao
[PATCH] drm/i915: check if execlist_port is empty before using its content
On Fri, 23 Dec 2016, changbin.du at intel.com wrote:
> From: "Du, Changbin"
>
> This patch fix a crash in function reset_common_ring. In this case,
> the port[0].request is null when reset the render ring, so a null
> dereference exception is raised. We need to check execlist_port status
> first.
>
> [ 35.748034] BUG: unable to handle kernel NULL pointer dereference at
> 0070
> [ 35.749567] IP: [] reset_common_ring+0xbe/0x150
> [ 35.749567] Call Trace:
> [ 35.749567] [] i915_gem_reset+0x150/0x270
> [ 35.749567] [] i915_reset+0x8a/0xe0
> [ 35.749567] [] i915_reset_and_wakeup+0x131/0x160
> [ 35.749567] [] ? gen5_read8+0x110/0x110
> [ 35.749567] [] i915_handle_error+0xca/0x5a0
> [ 35.749567] [] ? scnprintf+0x3d/0x70
> [ 35.749567] [] i915_hangcheck_elapsed+0x213/0x510
> [ 35.749567] [] process_one_work+0x15b/0x470
> [ 35.749567] [] worker_thread+0x43/0x4d0
> [ 35.749567] [] ? process_one_work+0x470/0x470
> [ 35.749567] [] ? process_one_work+0x470/0x470
> [ 35.749567] [] ?
> call_usermodehelper_exec_async+0x12e/0x130
> [ 35.749567] [] kthread+0xc5/0xe0
> [ 35.749567] [] ? kthread_park+0x60/0x60
> [ 35.749567] [] ? umh_complete+0x40/0x40
> [ 35.749567] [] ret_from_fork+0x22/0x30
>
Fixes: ?
i.e. which commit broke things?
BR,
Jani.
> Signed-off-by: Changbin Du
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 0a09024..81a9b0b 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1450,7 +1450,7 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
>
> /* Catch up with any missed context-switch interrupts */
> I915_WRITE(RING_CONTEXT_STATUS_PTR(engine), _MASKED_FIELD(0x, 0));
> - if (request->ctx != port[0].request->ctx) {
> + if (!execlists_elsp_idle(engine) && request->ctx !=
> port[0].request->ctx) {
> i915_gem_request_put(port[0].request);
> port[0] = port[1];
> memset(&port[1], 0, sizeof(port[1]));
--
Jani Nikula, Intel Open Source Technology Center
[Intel-gfx] [PATCH] drm/i915: check if execlist_port is empty before using its content
On Fri, Dec 23, 2016 at 01:46:36PM +0800, changbin.du at intel.com wrote: > From: "Du, Changbin" > > This patch fix a crash in function reset_common_ring. In this case, > the port[0].request is null when reset the render ring, so a null > dereference exception is raised. We need to check execlist_port status > first. No. The root cause is whatever got you into the illegal condition in the first place. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 190971] New: amdgpu (on Kabini) fails to resume, atombios stuck executing BA98
https://bugzilla.kernel.org/show_bug.cgi?id=190971 Bug ID: 190971 Summary: amdgpu (on Kabini) fails to resume, atombios stuck executing BA98 Product: Drivers Version: 2.5 Kernel Version: 4.9 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: blade at debian.org Regression: No Created attachment 248421 --> https://bugzilla.kernel.org/attachment.cgi?id=248421&action=edit Kernel messages Hardware: Lenovo Thinkpad Edge E145 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Root Complex 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kabini [Radeon HD 8240 / R3 Series] This system works fine with the Radeon driver. With amdgpu and CONFIG_DRM_AMDGPU_CIK=y , it works until the next suspend-to-ram cycle. Then the system comes up but the screen remains dark. See attachment for kernel logs. The same thing happened earlier when I tested AMDGPU with 4.8.x kernels. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 05/12] locking/ww_mutex: Remove the __ww_mutex_lock inline wrappers
On Wed, Dec 21, 2016 at 07:46:33PM +0100, Nicolai Hähnle wrote:
> diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
> index a5960e5..b2eaaab 100644
> --- a/include/linux/ww_mutex.h
> +++ b/include/linux/ww_mutex.h
> @@ -186,11 +186,6 @@ static inline void ww_acquire_fini(struct ww_acquire_ctx
> *ctx)
> #endif
> }
>
> -extern int __must_check __ww_mutex_lock(struct ww_mutex *lock,
> - struct ww_acquire_ctx *ctx);
> -extern int __must_check __ww_mutex_lock_interruptible(struct ww_mutex *lock,
> - struct ww_acquire_ctx
> *ctx);
> -
> /**
> * ww_mutex_lock - acquire the w/w mutex
> * @lock: the mutex to be acquired
> @@ -220,10 +215,8 @@ extern int __must_check
> __ww_mutex_lock_interruptible(struct ww_mutex *lock,
> *
> * A mutex acquired with this function must be released with ww_mutex_unlock.
> */
> -static inline int ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx
> *ctx)
> -{
> - return __ww_mutex_lock(lock, ctx);
> -}
> +extern int __must_check ww_mutex_lock(struct ww_mutex *lock,
> + struct ww_acquire_ctx *ctx);
>
> /**
> * ww_mutex_lock_interruptible - acquire the w/w mutex, interruptible
> @@ -255,11 +248,8 @@ static inline int ww_mutex_lock(struct ww_mutex *lock,
> struct ww_acquire_ctx *ct
> *
> * A mutex acquired with this function must be released with ww_mutex_unlock.
> */
> -static inline int __must_check ww_mutex_lock_interruptible(struct ww_mutex
> *lock,
> -struct
> ww_acquire_ctx *ctx)
> -{
> - return __ww_mutex_lock_interruptible(lock, ctx);
> -}
> +extern int __must_check ww_mutex_lock_interruptible(struct ww_mutex *lock,
> + struct ww_acquire_ctx *ctx);
>
> /**
> * ww_mutex_lock_slow - slowpath acquiring of the w/w mutex
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index a41bec2..282c6de 100644
For some reason this patch appears to make lib/locking-selftest.c really
unhappy.
I get endless streams of:
../lib/locking-selftest.c: In function âww_test_fail_acquireâ:
../lib/locking-selftest.c:1141:6: error: void value not ignored as it ought to
be
ret = WWL(&o, &t);
^
Apparently GCC gets confused about __much_check on inline functions or
something, or I got the patch wrong.
[Bug 99191] Weird blocky green stuff rendered in High Fidelity
https://bugs.freedesktop.org/show_bug.cgi?id=99191 Bug ID: 99191 Summary: Weird blocky green stuff rendered in High Fidelity Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: haagch at frickel.club QA Contact: dri-devel at lists.freedesktop.org RX 480, mesa git, llvm 4.0.0svn_r290385 They have an OpenGL 4.1 and an OpenGL 4.5 backend and it happens on both. Here is a video with the 4.3 backend: https://www.youtube.com/watch?v=VpNFhlzsLHg Here is a (50 megabyte compressed) trace with the 4.5 backend: https://haagch.frickel.club/files/interface.trace.xz Possibly an application bug, but glretrace prints no real errors. If you want to run it yourself, you will need this fix: https://github.com/highfidelity/hifi/pull/9264#issuecomment-268943917 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161223/675180dc/attachment-0001.html>
[PATCH v4 3/5] drm: bridge: Link encoder and bridge in core code
Am Freitag, den 16.12.2016, 14:05 +0530 schrieb Archit Taneja: > Hi, > > On 12/14/2016 03:29 PM, Laurent Pinchart wrote: > > Instead of linking encoders and bridges in every driver (and getting it > > wrong half of the time, as many drivers forget to set the drm_bridge > > encoder pointer), do so in core code. The drm_bridge_attach() function > > needs the encoder and optional previous bridge to perform that task, > > update all the callers. > > > > Signed-off-by: Laurent Pinchart > ideasonboard.com> > > Acked-by: Stefan Agner # For DCU > > Acked-by: Boris Brezillon # For > > atmel-hlcdc > > Acked-by: Vincent Abriou # For STI > > This one needs acks for arcgpu, tilcdc, mediatek and imx. The changes in > those drivers look good to me, though. Will push it in a day or so unless > anyone > has any comments on it. for mediatek and imx Acked-by: Philipp Zabel regards Philipp
[PATCH v3 05/12] locking/ww_mutex: Remove the __ww_mutex_lock inline wrappers
On 23.12.2016 11:48, Peter Zijlstra wrote:
> On Wed, Dec 21, 2016 at 07:46:33PM +0100, Nicolai Hähnle wrote:
>> diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
>> index a5960e5..b2eaaab 100644
>> --- a/include/linux/ww_mutex.h
>> +++ b/include/linux/ww_mutex.h
>> @@ -186,11 +186,6 @@ static inline void ww_acquire_fini(struct
>> ww_acquire_ctx *ctx)
>> #endif
>> }
>>
>> -extern int __must_check __ww_mutex_lock(struct ww_mutex *lock,
>> -struct ww_acquire_ctx *ctx);
>> -extern int __must_check __ww_mutex_lock_interruptible(struct ww_mutex *lock,
>> - struct ww_acquire_ctx
>> *ctx);
>> -
>> /**
>> * ww_mutex_lock - acquire the w/w mutex
>> * @lock: the mutex to be acquired
>> @@ -220,10 +215,8 @@ extern int __must_check
>> __ww_mutex_lock_interruptible(struct ww_mutex *lock,
>> *
>> * A mutex acquired with this function must be released with
>> ww_mutex_unlock.
>> */
>> -static inline int ww_mutex_lock(struct ww_mutex *lock, struct
>> ww_acquire_ctx *ctx)
>> -{
>> -return __ww_mutex_lock(lock, ctx);
>> -}
>> +extern int __must_check ww_mutex_lock(struct ww_mutex *lock,
>> + struct ww_acquire_ctx *ctx);
>>
>> /**
>> * ww_mutex_lock_interruptible - acquire the w/w mutex, interruptible
>> @@ -255,11 +248,8 @@ static inline int ww_mutex_lock(struct ww_mutex *lock,
>> struct ww_acquire_ctx *ct
>> *
>> * A mutex acquired with this function must be released with
>> ww_mutex_unlock.
>> */
>> -static inline int __must_check ww_mutex_lock_interruptible(struct ww_mutex
>> *lock,
>> - struct
>> ww_acquire_ctx *ctx)
>> -{
>> -return __ww_mutex_lock_interruptible(lock, ctx);
>> -}
>> +extern int __must_check ww_mutex_lock_interruptible(struct ww_mutex *lock,
>> +struct ww_acquire_ctx *ctx);
>>
>> /**
>> * ww_mutex_lock_slow - slowpath acquiring of the w/w mutex
>> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
>> index a41bec2..282c6de 100644
>
> For some reason this patch appears to make lib/locking-selftest.c really
> unhappy.
>
> I get endless streams of:
>
> ../lib/locking-selftest.c: In function âww_test_fail_acquireâ:
> ../lib/locking-selftest.c:1141:6: error: void value not ignored as it ought
> to be
> ret = WWL(&o, &t);
> ^
>
> Apparently GCC gets confused about __much_check on inline functions or
> something, or I got the patch wrong.
Weird, I'm not getting that, and it makes no sense either from a quick
glimpse of the code. Is there anything beside
CONFIG_DEBUG_LOCKING_API_SELFTESTS I would have to enable to trigger
this? FWIW:
$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>
>
[PATCH v3 05/12] locking/ww_mutex: Remove the __ww_mutex_lock inline wrappers
On Fri, Dec 23, 2016 at 12:16:03PM +0100, Nicolai Hähnle wrote: > >For some reason this patch appears to make lib/locking-selftest.c really > >unhappy. > > > >I get endless streams of: > > > >../lib/locking-selftest.c: In function âww_test_fail_acquireâ: > >../lib/locking-selftest.c:1141:6: error: void value not ignored as it ought > >to be > > ret = WWL(&o, &t); > > ^ > > > >Apparently GCC gets confused about __much_check on inline functions or > >something, or I got the patch wrong. > > Weird, I'm not getting that, and it makes no sense either from a quick > glimpse of the code. Is there anything beside > CONFIG_DEBUG_LOCKING_API_SELFTESTS I would have to enable to trigger this? Not entirely sure, I'm building an allmodconfig. > FWIW: > > $ gcc --version > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 gcc (Debian 6.2.1-5) 6.2.1 20161124
[Intel-gfx] [PATCH 1/2] drm : adds Y-coordinate and Colorimetry Format
On Thu, 22 Dec 2016, vathsala nagaraju wrote: > PSR2 vsc revision number hb2( as per table 6-11)is updated to > 4 or 5 based on Y cordinate and Colorimetry Format as below > 04h = 3D stereo + PSR/PSR2 + Y-coordinate. > 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry > Format indication. A DP Source device is allowed to indicate the pixel > encoding/colorimetry format to the DP Sink device with VSC SDP only when > the DP Sink device supports it ( > i.e.,VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the > DPRX_FEATURE_ENUMERATION_LIST register (DPCD Address 02210h, bit 3; > is set to 1). > > v2: (Jani) > - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED. > - Add DP_PSR2_SU_GRANULARITY_REQUIRED. > - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX. > - Add GTC_CAP and AV_SYNC_CAP, other bits in DPRX_FEATURE_ENUMERATION_LIST. > > Cc: Rodrigo Vivi > Cc: Jim Bride > Signed-off-by: Vathsala Nagaraju > --- > include/drm/drm_dp_helper.h | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 55bbeb0..ee2a649d 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -194,7 +194,8 @@ > # define DP_PSR_SETUP_TIME_0(6 << 1) > # define DP_PSR_SETUP_TIME_MASK (7 << 1) > # define DP_PSR_SETUP_TIME_SHIFT1 > - > +# define DP_PSR2_SU_Y_COORDINATE_REQUIRED (1 << 4) /* eDP 1.4a */ > +# define DP_PSR2_SU_GRANULARITY_REQUIRED(1 << 5) /* eDP 1.4b */ > /* > * 0x80-0x8f describe downstream port capabilities, but there are two layouts > * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not, > @@ -568,6 +569,11 @@ > #define DP_RECEIVER_ALPM_STATUS 0x200b /* eDP 1.4 */ > # define DP_ALPM_LOCK_TIMEOUT_ERROR (1 << 0) > > +#define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210 > +# define DP_GTC_CAP (1 << 0) > +# define DP_AV_SYNC_CAP (1 << 2) > +# define DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED(1 << 3) The spec continues with bits 4 to 7 in the next page... > + > /* DP 1.2 Sideband message defines */ > /* peer device type - DP 1.2a Table 2-92 */ > #define DP_PEER_DEVICE_NONE 0x0 -- Jani Nikula, Intel Open Source Technology Center
[PATCH 06/18] drm/i915/dsi: Move disable pll call outside of clear_device_ready()
On Thu, 01 Dec 2016, Hans de Goede wrote:
> On enable intel_dsi_enable() directly calls intel_enable_dsi_pll(),
> make intel_dsi_disable() also directly call intel_disable_dsi_pll(),
> rather then hiding the call in intel_dsi_clear_device_ready(),
> no functional changes.
>
> Signed-off-by: Hans de Goede
Pushed this one to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 967bae9..cb15c0a 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -642,8 +642,6 @@ static void intel_dsi_clear_device_ready(struct
> intel_encoder *encoder)
> I915_WRITE(MIPI_DEVICE_READY(port), 0x00);
> usleep_range(2000, 2500);
> }
> -
> - intel_disable_dsi_pll(encoder);
> }
>
> static void intel_dsi_post_disable(struct intel_encoder *encoder,
> @@ -674,6 +672,8 @@ static void intel_dsi_post_disable(struct intel_encoder
> *encoder,
>
> intel_dsi_clear_device_ready(encoder);
>
> + intel_disable_dsi_pll(encoder);
> +
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> u32 val;
--
Jani Nikula, Intel Open Source Technology Center
[git pull] drm fixes for 4.10-rc1
On Fri, Dec 23, 2016 at 2:59 AM, Dave Airlie wrote: > Hi Linus, > > Some fixes came in while I was out, mostly intel and amdgpu ones, > with one ast fix. If you can land them before -rc1 it would be good > but I don't mind if they don't. This should also shut up the WARN_ON(!intel_dp->lane_count) noise. -Daniel > > Dave. > > The following changes since commit 50f6584e4c626b8fa39edb66f33fec27bab3996c: > > Merge tag 'leds_for_4.10_email_update' of > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds > (2016-12-22 10:31:30 -0800) > > are available in the git repository at: > > git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-4.10-rc1 > > for you to fetch changes up to 4a401ceeef7bf3bc55f5e913cbf19d6038cf83c6: > > Merge tag 'drm-intel-next-fixes-2016-12-22' of > git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2016-12-23 > 05:28:02 +1000) > > > drm initial fixes for 4.10 (intel, amd) > > > Chris Wilson (2): > drm/i915: Reorder phys backing storage release > drm/i915: Fallback to single PAGE_SIZE segments for DMA remapping > > Daniel Vetter (1): > drm/i915: tune down the fast link training vs boot fail > > Dave Airlie (3): > Merge branch 'drm-next-4.10' of > git://people.freedesktop.org/~agd5f/linux into drm-fixes > Merge tag 'drm-misc-fixes-2016-12-22' of > git://anongit.freedesktop.org/git/drm-misc into drm-fixes > Merge tag 'drm-intel-next-fixes-2016-12-22' of > git://anongit.freedesktop.org/git/drm-intel into drm-fixes > > Flora Cui (12): > drm/amdgpu: fix cursor setting of dce6/dce8 > drm/amdgpu: update golden setting/tiling table of tahiti > drm/amdgpu: update golden setting for pitcairn > drm/amdgpu: update rev id for pitcairn > drm/amdgpu: update golden setting for hainan > drm/amdgpu: update rev id for hainan > drm/amdgpu: update golden setting for oland > drm/amdgpu: update rev id for oland > drm/amdgpu: update golden setting for verde > drm/amdgpu: update rev id for verde > drm/amdgpu: update tile table for verde > drm/amdgpu: update tile table for oland/hainan > > Hans de Goede (3): > drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from > vlv_init_display_clock_gating > drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / > MIPI_SEQ_ASSERT_RESET > drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting > > Imre Deak (2): > drm/i915/gen9: Fix PCODE polling during CDCLK change notification > drm/i915/gen9: Fix PCODE polling during SAGV disabling > > Matthew Auld (1): > drm/i915: drop the struct_mutex when wedged or trying to reset > > Mika Kuoppala (1): > drm/i915: Fix setting of boost freq tunable > > Paulo Zanoni (2): > drm/i915: disable PSR by default on HSW/BDW > drm/i915: skip the first 4k of stolen memory on everything >= gen8 > > Rex Zhu (9): > drm/amdgpu: disable uvd pg on Tonga. > drm/amdgpu: fix enable_cp_power_gating in gfx_v8.0. > drm/amdgpu: fix init save/restore list in gfx_v8.0 > drm/amdgpu: enable AMD_PG_SUPPORT_CP in Carrizo/Stoney. > drm/amdgpu: always initialize gfx pg for gfx_v8.0. > drm/amdgpu: fix pg can't be disabled by PG mask. > drm/amdgpu: add new gfx cg flags. > drm/amdgpu: initialize cg flags for tonga/polaris10/polaris11. > drm/amdgpu: refine set clock gating for tonga/polaris > > Russell Currey (1): > drivers/gpu/drm/ast: Fix infinite loop if read fails > > Tvrtko Ursulin (1): > drm/i915: Fix use after free in logical_render_ring_init > > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +- > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 - > drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 935 > - > drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 249 +--- > drivers/gpu/drm/amd/amdgpu/si.c| 442 +++--- > drivers/gpu/drm/amd/amdgpu/vi.c| 211 +-- > drivers/gpu/drm/amd/include/amd_shared.h | 4 + > drivers/gpu/drm/ast/ast_main.c | 7 +- > drivers/gpu/drm/i915/i915_drv.h| 2 + > drivers/gpu/drm/i915/i915_gem.c| 79 ++- > drivers/gpu/drm/i915/i915_gem_stolen.c | 5 +- > drivers/gpu/drm/i915/i915_sysfs.c | 2 +- > drivers/gpu/drm/i915/intel_bios.h | 12 +- > drivers/gpu/drm/i915/intel_display.c | 31 +- > drivers/gpu/drm/i915/intel_dp.c| 4 +- > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 7 +- > drivers/gpu/drm/i915/intel_lrc.c | 7 +- > drivers/gpu/drm/i915/intel_pm.c| 109 +++- > drivers/gpu/drm/i915/intel_psr.c | 10 +- > drivers/gpu/drm/i915/intel_runtime_pm.c| 13 +- > 20 files changed, 1409 insertions(+), 728 deletions(-) >
[Bug 96488] [r600g]OpenCL driver causes segfault in ImageMagick's Histogram kernel
https://bugs.freedesktop.org/show_bug.cgi?id=96488 --- Comment #8 from Jan Vesely --- (In reply to nixscripter from comment #7) > Normally, I would be asking in this comment if there is any progress on > this, but I can tell there has been... change, at least. > > Now instead of crashing, it deadlocks the calling process waiting on a > mutex. Forever, as far as I can tell. > > LLVM version: r289770 > Mesa version: commit 47351b843a > > Perhaps this is more easily fixed? Or is this getting to the heart of the > matter implied in comment 2? the hang is probably a separate bug. ImageMagick test suite results on my Turks GPU are: # TOTAL: 86 # PASS: 78 # SKIP: 0 # XFAIL: 0 # FAIL: 3 # XPASS: 0 # ERROR: 5 the errors and failures are accompanied by: Assertion `i < getNumRegs() && "Register number out of range!"' failed. The patches to add support for noret atomics (should be good enough for histogram) are at: https://reviews.llvm.org/D27989 https://reviews.llvm.org/D28067 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161223/4dd7fd40/attachment.html>
[Intel-gfx] [PATCH 1/2] drm : adds Y-coordinate and Colorimetry Format
On Fri, 23 Dec 2016, "Nagaraju, Vathsala" wrote: > In DP V1.3 spec , Table 2-149 , page number-374 , for Register 0x2210 > , bit 7:4 is reserved. See DP 1.4. BR, Jani. > > -Original Message- > From: Jani Nikula [mailto:jani.nikula at linux.intel.com] > Sent: Friday, December 23, 2016 6:57 PM > To: Nagaraju, Vathsala ; dri-devel at > lists.freedesktop.org; intel-gfx at lists.freedesktop.org > Cc: Vivi, Rodrigo > Subject: Re: [Intel-gfx] [PATCH 1/2] drm : adds Y-coordinate and Colorimetry > Format > > On Thu, 22 Dec 2016, vathsala nagaraju wrote: >> PSR2 vsc revision number hb2( as per table 6-11)is updated to >> 4 or 5 based on Y cordinate and Colorimetry Format as below 04h = 3D >> stereo + PSR/PSR2 + Y-coordinate. >> 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel >> Encoding/Colorimetry Format indication. A DP Source device is allowed >> to indicate the pixel encoding/colorimetry format to the DP Sink >> device with VSC SDP only when the DP Sink device supports it ( >> i.e.,VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the >> DPRX_FEATURE_ENUMERATION_LIST register (DPCD Address 02210h, bit 3; is >> set to 1). >> >> v2: (Jani) >> - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED. >> - Add DP_PSR2_SU_GRANULARITY_REQUIRED. >> - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX. >> - Add GTC_CAP and AV_SYNC_CAP, other bits in DPRX_FEATURE_ENUMERATION_LIST. >> >> Cc: Rodrigo Vivi >> Cc: Jim Bride >> Signed-off-by: Vathsala Nagaraju >> --- >> include/drm/drm_dp_helper.h | 8 +++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h >> index 55bbeb0..ee2a649d 100644 >> --- a/include/drm/drm_dp_helper.h >> +++ b/include/drm/drm_dp_helper.h >> @@ -194,7 +194,8 @@ >> # define DP_PSR_SETUP_TIME_0(6 << 1) >> # define DP_PSR_SETUP_TIME_MASK (7 << 1) >> # define DP_PSR_SETUP_TIME_SHIFT1 >> - >> +# define DP_PSR2_SU_Y_COORDINATE_REQUIRED (1 << 4) /* eDP 1.4a */ >> +# define DP_PSR2_SU_GRANULARITY_REQUIRED(1 << 5) /* eDP 1.4b */ >> /* >> * 0x80-0x8f describe downstream port capabilities, but there are two >> layouts >> * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it >> was not, @@ -568,6 +569,11 @@ >> #define DP_RECEIVER_ALPM_STATUS 0x200b /* eDP 1.4 */ >> # define DP_ALPM_LOCK_TIMEOUT_ERROR (1 << 0) >> >> +#define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210 >> +# define DP_GTC_CAP (1 << 0) >> +# define DP_AV_SYNC_CAP (1 << 2) >> +# define DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED (1 << 3) > > The spec continues with bits 4 to 7 in the next page... > >> + >> /* DP 1.2 Sideband message defines */ >> /* peer device type - DP 1.2a Table 2-92 */ >> #define DP_PEER_DEVICE_NONE 0x0 > > -- > Jani Nikula, Intel Open Source Technology Center -- Jani Nikula, Intel Open Source Technology Center
[PATCH libdrm 1/2] xf86drm: Fix indentation
From: Thierry Reding libdrm uses spaces for indentation. Fix the two inconsistent lines in this file. Signed-off-by: Thierry Reding --- xf86drm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index b5eeeb090ecb..ac59bf513d6c 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -2904,7 +2904,7 @@ static int drmParseSubsystemType(int maj, int min) return -EINVAL; #elif defined(__OpenBSD__) - return DRM_BUS_PCI; +return DRM_BUS_PCI; #else #warning "Missing implementation of drmParseSubsystemType" return -EINVAL; @@ -3411,7 +3411,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr *device) closedir(sysdir); free(local_devices); if (*device == NULL) - return -ENODEV; +return -ENODEV; return 0; free_devices: -- 2.11.0
[PATCH libdrm 2/2] Add .editorconfig
From: Thierry Reding
This encodes the indentation style for libdrm and can be used with
various editors. See http://editorconfig.org for instructions.
Signed-off-by: Thierry Reding
---
.editorconfig | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 .editorconfig
diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index ..893b7be082e4
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,19 @@
+# To use this config with your editor, follow the instructions at:
+# http://editorconfig.org
+
+root = true
+
+[*]
+charset = utf-8
+insert_final_newline = true
+
+[*.{c,h}]
+indent_style = space
+indent_size = 4
+
+[{Makefile.*,*.mk}]
+indent_style = tab
+
+[*.m4]
+indent_style = space
+indent_size = 2
--
2.11.0
[PATCH libdrm 0/3] xf86drm: Add USB, platform and host1x bus support
From: Thierry Reding Hi, This series enables support for USB, platform and host1x busses in the drmDevice infrastructure. The goal is to make use of these in Mesa for PRIME support (via the DRI_PRIME environment variable) for devices on one of these busses. I'll be sending out Mesa patches for this shortly. Thierry Thierry Reding (3): xf86drm: Factor out drmDeviceAlloc() xf86drm: Add USB support xf86drm: Add platform and host1x bus support xf86drm.c | 385 +- xf86drm.h | 35 +- 2 files changed, 392 insertions(+), 28 deletions(-) -- 2.11.0
[PATCH libdrm 1/3] xf86drm: Factor out drmDeviceAlloc()
From: Thierry Reding
Subsequent patches will add support for other bus types to drmDevice and
they will duplicate a lot of the code to allocate a drmDevice. Factor
out the common code so it can be reused.
Signed-off-by: Thierry Reding
---
xf86drm.c | 78 +--
1 file changed, 51 insertions(+), 27 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index ac59bf513d6c..6a271000af82 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3153,57 +3153,81 @@ void drmFreeDevices(drmDevicePtr devices[], int count)
drmFreeDevice(&devices[i]);
}
+static drmDevicePtr drmDeviceAlloc(unsigned int type, const char *node,
+ size_t bus_size, size_t device_size,
+ char **ptrp)
+{
+size_t max_node_length, extra, size;
+drmDevicePtr device;
+unsigned int i;
+char *ptr;
+
+max_node_length = ALIGN(drmGetMaxNodeName(), sizeof(void *));
+extra = DRM_NODE_MAX * (sizeof(void *) + max_node_length);
+
+size = sizeof(*device) + extra + bus_size + device_size;
+
+device = calloc(1, size);
+if (!device)
+return NULL;
+
+device->available_nodes = 1 << type;
+
+ptr = (char *)device + sizeof(*device);
+device->nodes = (char **)ptr;
+
+ptr += DRM_NODE_MAX * sizeof(void *);
+
+for (i = 0; i < DRM_NODE_MAX; i++) {
+device->nodes[i] = ptr;
+ptr += max_node_length;
+}
+
+memcpy(device->nodes[type], node, max_node_length);
+
+*ptrp = ptr;
+
+return device;
+}
+
static int drmProcessPciDevice(drmDevicePtr *device,
const char *node, int node_type,
int maj, int min, bool fetch_deviceinfo,
uint32_t flags)
{
-const int max_node_str = ALIGN(drmGetMaxNodeName(), sizeof(void *));
-int ret, i;
+drmDevicePtr dev;
char *addr;
+int ret;
-*device = calloc(1, sizeof(drmDevice) +
- (DRM_NODE_MAX * (sizeof(void *) + max_node_str)) +
- sizeof(drmPciBusInfo) +
- sizeof(drmPciDeviceInfo));
-if (!*device)
+dev = drmDeviceAlloc(node_type, node, sizeof(drmPciBusInfo),
+ sizeof(drmPciDeviceInfo), &addr);
+if (!dev)
return -ENOMEM;
-addr = (char*)*device;
+dev->bustype = DRM_BUS_PCI;
-(*device)->bustype = DRM_BUS_PCI;
-(*device)->available_nodes = 1 << node_type;
+dev->businfo.pci = (drmPciBusInfoPtr)addr;
-addr += sizeof(drmDevice);
-(*device)->nodes = (char**)addr;
-
-addr += DRM_NODE_MAX * sizeof(void *);
-for (i = 0; i < DRM_NODE_MAX; i++) {
-(*device)->nodes[i] = addr;
-addr += max_node_str;
-}
-memcpy((*device)->nodes[node_type], node, max_node_str);
-
-(*device)->businfo.pci = (drmPciBusInfoPtr)addr;
-
-ret = drmParsePciBusInfo(maj, min, (*device)->businfo.pci);
+ret = drmParsePciBusInfo(maj, min, dev->businfo.pci);
if (ret)
goto free_device;
// Fetch the device info if the user has requested it
if (fetch_deviceinfo) {
addr += sizeof(drmPciBusInfo);
-(*device)->deviceinfo.pci = (drmPciDeviceInfoPtr)addr;
+dev->deviceinfo.pci = (drmPciDeviceInfoPtr)addr;
-ret = drmParsePciDeviceInfo(maj, min, (*device)->deviceinfo.pci,
flags);
+ret = drmParsePciDeviceInfo(maj, min, dev->deviceinfo.pci, flags);
if (ret)
goto free_device;
}
+
+*device = dev;
+
return 0;
free_device:
-free(*device);
-*device = NULL;
+free(dev);
return ret;
}
--
2.11.0
[PATCH libdrm 3/3] xf86drm: Add platform and host1x bus support
From: Thierry Reding
ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
support for that to enable these devices to be used with the drmDevice
infrastructure.
NVIDIA Tegra SoCs have an additional level in the hierarchy and DRM/KMS
devices can also be on the host1x bus. This is mostly equivalent to the
platform bus.
Signed-off-by: Thierry Reding
---
Note that we could probably get away with treating host1x as platform
bus. However, they are technically two different busses in the kernel
and hence we may want to make use of that differentiation later on.
xf86drm.c | 164 ++
xf86drm.h | 24 -
2 files changed, 186 insertions(+), 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index f0171c34c958..69887accb3cb 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2905,6 +2905,12 @@ static int drmParseSubsystemType(int maj, int min)
if (strncmp(name, "/usb", 4) == 0)
return DRM_BUS_USB;
+if (strncmp(name, "/platform", 9) == 0)
+return DRM_BUS_PLATFORM;
+
+if (strncmp(name, "/host1x", 7) == 0)
+return DRM_BUS_HOST1X;
+
return -EINVAL;
#elif defined(__OpenBSD__)
return DRM_BUS_PCI;
@@ -2995,6 +3001,12 @@ static int drmCompareBusInfo(drmDevicePtr a,
drmDevicePtr b)
case DRM_BUS_USB:
return memcmp(a->businfo.usb, b->businfo.usb, sizeof(drmUsbBusInfo));
+case DRM_BUS_PLATFORM:
+return memcmp(a->businfo.platform, b->businfo.platform,
sizeof(drmPlatformBusInfo));
+
+case DRM_BUS_HOST1X:
+return memcmp(a->businfo.host1x, b->businfo.host1x,
sizeof(drmHost1xBusInfo));
+
default:
break;
}
@@ -3357,6 +3369,128 @@ free_device:
return ret;
}
+static int drmParsePlatformBusInfo(int maj, int min, drmPlatformBusInfoPtr
info)
+{
+char path[PATH_MAX + 1], *name;
+
+snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+
+name = sysfs_uevent_get(path, "OF_FULLNAME");
+strcpy(info->fullname, name);
+free(name);
+
+return 0;
+}
+
+static int drmParsePlatformDeviceInfo(int maj, int min,
+ drmPlatformDeviceInfoPtr info)
+{
+/* XXX fill in platform device info */
+
+return 0;
+}
+
+static int drmProcessPlatformDevice(drmDevicePtr *device,
+const char *node, int node_type,
+int maj, int min, bool fetch_deviceinfo,
+uint32_t flags)
+{
+drmDevicePtr dev;
+char *ptr;
+int ret;
+
+dev = drmDeviceAlloc(node_type, node, sizeof(drmPlatformBusInfo),
+ sizeof(drmPlatformDeviceInfo), &ptr);
+if (!dev)
+return -ENOMEM;
+
+dev->bustype = DRM_BUS_PLATFORM;
+
+dev->businfo.platform = (drmPlatformBusInfoPtr)ptr;
+
+ret = drmParsePlatformBusInfo(maj, min, dev->businfo.platform);
+if (ret < 0)
+goto free_device;
+
+if (fetch_deviceinfo) {
+ptr += sizeof(drmPlatformBusInfo);
+dev->deviceinfo.platform = (drmPlatformDeviceInfoPtr)ptr;
+
+ret = drmParsePlatformDeviceInfo(maj, min, dev->deviceinfo.platform);
+if (ret < 0)
+goto free_device;
+}
+
+*device = dev;
+
+return 0;
+
+free_device:
+free(dev);
+return ret;
+}
+
+static int drmParseHost1xBusInfo(int maj, int min, drmHost1xBusInfoPtr info)
+{
+char path[PATH_MAX + 1], *name;
+
+snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+
+name = sysfs_uevent_get(path, "OF_FULLNAME");
+strcpy(info->fullname, name);
+free(name);
+
+return 0;
+}
+
+static int drmParseHost1xDeviceInfo(int maj, int min,
+drmHost1xDeviceInfoPtr info)
+{
+/* XXX fill in host1x device info */
+
+return 0;
+}
+
+static int drmProcessHost1xDevice(drmDevicePtr *device,
+ const char *node, int node_type,
+ int maj, int min, bool fetch_deviceinfo,
+ uint32_t flags)
+{
+drmDevicePtr dev;
+char *ptr;
+int ret;
+
+dev = drmDeviceAlloc(node_type, node, sizeof(drmHost1xBusInfo),
+ sizeof(drmHost1xDeviceInfo), &ptr);
+if (!dev)
+return -ENOMEM;
+
+dev->bustype = DRM_BUS_HOST1X;
+
+dev->businfo.host1x = (drmHost1xBusInfoPtr)ptr;
+
+ret = drmParseHost1xBusInfo(maj, min, dev->businfo.host1x);
+if (ret < 0)
+goto free_device;
+
+if (fetch_deviceinfo) {
+ptr += sizeof(drmHost1xBusInfo);
+dev->deviceinfo.host1x = (drmHost1xDeviceInfoPtr)ptr;
+
+ret = drmParseHost1xDeviceInfo(maj, min, dev->deviceinfo.host1x);
+if (ret < 0)
+goto free_device;
+}
+
+*device = dev;
+
+return 0;
+
+free_device:
+free(dev);
+return ret;
+}
+
/* Consider devices located on the same bus as duplicate and fold the
respective
[PATCH libdrm 2/3] xf86drm: Add USB support
Allow DRM/KMS devices hosted on USB to be detected by the drmDevice
infrastructure.
Signed-off-by: Thierry Reding
---
Note that this is completely untested because I don't have a UDL device
for testing. I'm fairly confident that this will work, though, and it'd
be nice to include it before the new platform and host1x busses because
support for it existed in the kernel longer than for platform devices.
xf86drm.c | 143 ++
xf86drm.h | 13 ++
2 files changed, 156 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 6a271000af82..f0171c34c958 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2902,6 +2902,9 @@ static int drmParseSubsystemType(int maj, int min)
if (strncmp(name, "/pci", 4) == 0)
return DRM_BUS_PCI;
+if (strncmp(name, "/usb", 4) == 0)
+return DRM_BUS_USB;
+
return -EINVAL;
#elif defined(__OpenBSD__)
return DRM_BUS_PCI;
@@ -2988,6 +2991,10 @@ static int drmCompareBusInfo(drmDevicePtr a,
drmDevicePtr b)
switch (a->bustype) {
case DRM_BUS_PCI:
return memcmp(a->businfo.pci, b->businfo.pci, sizeof(drmPciBusInfo));
+
+case DRM_BUS_USB:
+return memcmp(a->businfo.usb, b->businfo.usb, sizeof(drmUsbBusInfo));
+
default:
break;
}
@@ -3231,6 +3238,125 @@ free_device:
return ret;
}
+static char *sysfs_uevent_get(const char *path, const char *key)
+{
+char filename[PATH_MAX], *line = NULL, *value = NULL;
+size_t size = 0, len = strlen(key);
+ssize_t num;
+FILE *fp;
+
+snprintf(filename, PATH_MAX, "%s/uevent", path);
+
+fp = fopen(filename, "r");
+if (!fp)
+return NULL;
+
+while ((num = getline(&line, &size, fp)) >= 0) {
+if ((strncmp(line, key, len) == 0) && (line[len] == '=')) {
+char *start = line + len + 1, *end = line + num - 1;
+
+if (*end != '\n')
+end++;
+
+value = strndup(start, end - start);
+break;
+}
+}
+
+free(line);
+fclose(fp);
+
+return value;
+}
+
+static int drmParseUsbBusInfo(int maj, int min, drmUsbBusInfoPtr info)
+{
+char path[PATH_MAX + 1], *value;
+unsigned int bus, dev;
+int ret;
+
+snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+
+value = sysfs_uevent_get(path, "BUSNUM");
+ret = sscanf(value, "%03u", &bus);
+free(value);
+
+if (ret <= 0)
+return -errno;
+
+value = sysfs_uevent_get(path, "DEVNUM");
+ret = sscanf(value, "%03u", &dev);
+free(value);
+
+if (ret <= 0)
+return -errno;
+
+info->bus = bus;
+info->dev = dev;
+
+return 0;
+}
+
+static int drmParseUsbDeviceInfo(int maj, int min, drmUsbDeviceInfoPtr info)
+{
+char path[PATH_MAX + 1], *value;
+unsigned int vendor, product;
+int ret;
+
+snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+
+value = sysfs_uevent_get(path, "PRODUCT");
+ret = sscanf(value, "%x/%x", &vendor, &product);
+free(value);
+
+if (ret <= 0)
+return -errno;
+
+info->vendor = vendor;
+info->product = product;
+
+return 0;
+}
+
+static int drmProcessUsbDevice(drmDevicePtr *device, const char *node,
+ int node_type, int maj, int min,
+ bool fetch_deviceinfo, uint32_t flags)
+{
+drmDevicePtr dev;
+char *ptr;
+int ret;
+
+dev = drmDeviceAlloc(node_type, node, sizeof(drmUsbBusInfo),
+ sizeof(drmUsbDeviceInfo), &ptr);
+if (!dev)
+return -ENOMEM;
+
+dev->bustype = DRM_BUS_USB;
+
+dev->businfo.usb = (drmUsbBusInfoPtr)ptr;
+
+ret = drmParseUsbBusInfo(maj, min, dev->businfo.usb);
+if (ret < 0)
+goto free_device;
+
+if (fetch_deviceinfo) {
+ptr += sizeof(drmUsbBusInfo);
+dev->deviceinfo.usb = (drmUsbDeviceInfoPtr)ptr;
+
+ret = drmParseUsbDeviceInfo(maj, min, dev->deviceinfo.usb);
+if (ret < 0)
+goto free_device;
+}
+
+*device = dev;
+
+return 0;
+
+free_device:
+free(dev);
+return ret;
+}
+
/* Consider devices located on the same bus as duplicate and fold the
respective
* entries into a single one.
*
@@ -3402,6 +3528,14 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr
*device)
goto free_devices;
break;
+
+case DRM_BUS_USB:
+ret = drmProcessUsbDevice(&d, node, node_type, maj, min, true,
flags);
+if (ret)
+goto free_devices;
+
+break;
+
default:
continue;
}
@@ -3533,6 +3667,15 @@ int drmGetDevices2(uint32_t flags, drmDevicePtr
devices[], int max_devices)
goto free_devices;
break;
+
+case DRM_BUS_USB:
+ret = drmProcessUsbDevice(&device, node, node_type, maj, min,
+ devices != NULL, flags);
+i
[Bug 99089] Random screen lockups
https://bugs.freedesktop.org/show_bug.cgi?id=99089 --- Comment #2 from Witold Baryluk --- The kernel update might be possibility. I am now running 4.9.0 custom built, and the system / screen is not freezing, but instead sometimes Xorg crashes, usually when clicking something. I am able to reproduce it reliably on some webpages in chrome, when clicking specifying button (dmesg shows X11 segfault, but entire Xorg exits, and I need to relogin). I was able to also reproduce it in few other programs like VLC, but less reliably. Probably a different issue. It is also possibly that my Xorg server is now confused, and uses i915 instead of radeon (ThinkPad W500 has both), but dmesg and xorg.0.log claims I am using radeon, but glxinfo shows there is no hardware opengl acceleration (llvmpipe instead). Weird. I will try to reproduce it again, maybe on 4.8 kernel again. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161223/fff054cb/attachment.html>
Implementing Miracast
Hello, about a year ago there was a discussion about Implementing Miracast on this list: https://lists.freedesktop.org/archives/dri-devel/2015-December/096035.html Since then I could not find further information about that topic there. So maybe someone can answer this question: Is that implementation expected to be available in the near future or did that development stop? Thanks Norbert Wegener
[PATCH 1/2] drm : adds Y-coordinate and Colorimetry Format
PSR2 vsc revision number hb2( as per table 6-11)is updated to 4 or 5 based on Y cordinate and Colorimetry Format as below 04h = 3D stereo + PSR/PSR2 + Y-coordinate. 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry Format indication. A DP Source device is allowed to indicate the pixel encoding/colorimetry format to the DP Sink device with VSC SDP only when the DP Sink device supports it ( i.e.,VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the DPRX_FEATURE_ENUMERATION_LIST register (DPCD Address 02210h, bit 3; is set to 1). v2: (Jani) - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED. - Add DP_PSR2_SU_GRANULARITY_REQUIRED. - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX. - Add GTC_CAP and AV_SYNC_CAP, other bits in DPRX_FEATURE_ENUMERATION_LIST. v3: (Jani) - Add support for bits 7:4 and 1 as per DP v1.4 for DPRX_FEATURE_ENUMERATION_LIST. Cc: Rodrigo Vivi Cc: Jim Bride Signed-off-by: Vathsala Nagaraju Signed-off-by: Patil Deepti --- include/drm/drm_dp_helper.h | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 55bbeb0..0468135 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -194,7 +194,8 @@ # define DP_PSR_SETUP_TIME_0(6 << 1) # define DP_PSR_SETUP_TIME_MASK (7 << 1) # define DP_PSR_SETUP_TIME_SHIFT1 - +# define DP_PSR2_SU_Y_COORDINATE_REQUIRED (1 << 4) /* eDP 1.4a */ +# define DP_PSR2_SU_GRANULARITY_REQUIRED(1 << 5) /* eDP 1.4b */ /* * 0x80-0x8f describe downstream port capabilities, but there are two layouts * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not, @@ -568,6 +569,16 @@ #define DP_RECEIVER_ALPM_STATUS0x200b /* eDP 1.4 */ # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0) +#define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210 /* DP 1.3 */ +# define DP_GTC_CAP(1 << 0) /* DP 1.3 */ +# define DP_SST_SPLIT_SDP_CAP (1 << 1) /* DP 1.4 */ +# define DP_AV_SYNC_CAP(1 << 2) /* DP 1.3 */ +# define DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED (1 << 3) /* DP 1.3 */ +# define DP_VSC_EXT_VESA_SDP_SUPPORTED (1 << 4) /* DP 1.4 */ +# define DP_VSC_EXT_VESA_SDP_CHAINING_SUPPORTED(1 << 5) /* DP 1.4 */ +# define DP_VSC_EXT_CEA_SDP_SUPPORTED (1 << 6) /* DP 1.4 */ +# define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP 1.4 */ + /* DP 1.2 Sideband message defines */ /* peer device type - DP 1.2a Table 2-92 */ #define DP_PEER_DEVICE_NONE0x0 -- 1.9.1
[Intel-gfx] [PATCH 1/2] drm : adds Y-coordinate and Colorimetry Format
In DP V1.3 spec , Table 2-149 , page number-374 , for Register 0x2210 , bit 7:4 is reserved. -Original Message- From: Jani Nikula [mailto:jani.nik...@linux.intel.com] Sent: Friday, December 23, 2016 6:57 PM To: Nagaraju, Vathsala ; dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org Cc: Vivi, Rodrigo Subject: Re: [Intel-gfx] [PATCH 1/2] drm : adds Y-coordinate and Colorimetry Format On Thu, 22 Dec 2016, vathsala nagaraju wrote: > PSR2 vsc revision number hb2( as per table 6-11)is updated to > 4 or 5 based on Y cordinate and Colorimetry Format as below 04h = 3D > stereo + PSR/PSR2 + Y-coordinate. > 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel > Encoding/Colorimetry Format indication. A DP Source device is allowed > to indicate the pixel encoding/colorimetry format to the DP Sink > device with VSC SDP only when the DP Sink device supports it ( > i.e.,VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the > DPRX_FEATURE_ENUMERATION_LIST register (DPCD Address 02210h, bit 3; is > set to 1). > > v2: (Jani) > - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED. > - Add DP_PSR2_SU_GRANULARITY_REQUIRED. > - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX. > - Add GTC_CAP and AV_SYNC_CAP, other bits in DPRX_FEATURE_ENUMERATION_LIST. > > Cc: Rodrigo Vivi > Cc: Jim Bride > Signed-off-by: Vathsala Nagaraju > --- > include/drm/drm_dp_helper.h | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 55bbeb0..ee2a649d 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -194,7 +194,8 @@ > # define DP_PSR_SETUP_TIME_0(6 << 1) > # define DP_PSR_SETUP_TIME_MASK (7 << 1) > # define DP_PSR_SETUP_TIME_SHIFT1 > - > +# define DP_PSR2_SU_Y_COORDINATE_REQUIRED (1 << 4) /* eDP 1.4a */ > +# define DP_PSR2_SU_GRANULARITY_REQUIRED(1 << 5) /* eDP 1.4b */ > /* > * 0x80-0x8f describe downstream port capabilities, but there are two layouts > * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it > was not, @@ -568,6 +569,11 @@ > #define DP_RECEIVER_ALPM_STATUS 0x200b /* eDP 1.4 */ > # define DP_ALPM_LOCK_TIMEOUT_ERROR (1 << 0) > > +#define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210 > +# define DP_GTC_CAP (1 << 0) > +# define DP_AV_SYNC_CAP (1 << 2) > +# define DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED(1 << 3) The spec continues with bits 4 to 7 in the next page... > + > /* DP 1.2 Sideband message defines */ > /* peer device type - DP 1.2a Table 2-92 */ > #define DP_PEER_DEVICE_NONE 0x0 -- Jani Nikula, Intel Open Source Technology Center
[PATCH v4 2/2] drm: Get atomic property value even if DRIVER_ATOMIC is not set
i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and atomic_commit. drm_object_property_get_value() does not read the correct value of atomic properties if DRIVER_ATOMIC is not set. Checking whether the driver uses atomic modeset is a better check instead as the property values are tracked in the state structures. v2: Included header Cc: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_mode_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c index 9f17085..14543ff 100644 --- a/drivers/gpu/drm/drm_mode_object.c +++ b/drivers/gpu/drm/drm_mode_object.c @@ -23,6 +23,7 @@ #include #include #include +#include #include "drm_crtc_internal.h" @@ -273,7 +274,7 @@ int drm_object_property_get_value(struct drm_mode_object *obj, * their value in obj->properties->values[].. mostly to avoid * having to deal w/ EDID and similar props in atomic paths: */ - if (drm_core_check_feature(property->dev, DRIVER_ATOMIC) && + if (drm_drv_uses_atomic_modeset(property->dev) && !(property->flags & DRM_MODE_PROP_IMMUTABLE)) return drm_atomic_get_property(obj, property, val); -- 2.7.4
[PATCH] drm/i915: check if execlist_port is empty before using its content
From: "Du, Changbin"
This patch fix a crash in function reset_common_ring. In this case,
the port[0].request is null when reset the render ring, so a null
dereference exception is raised. We need to check execlist_port status
first.
[ 35.748034] BUG: unable to handle kernel NULL pointer dereference at
0070
[ 35.749567] IP: [] reset_common_ring+0xbe/0x150
[ 35.749567] Call Trace:
[ 35.749567] [] i915_gem_reset+0x150/0x270
[ 35.749567] [] i915_reset+0x8a/0xe0
[ 35.749567] [] i915_reset_and_wakeup+0x131/0x160
[ 35.749567] [] ? gen5_read8+0x110/0x110
[ 35.749567] [] i915_handle_error+0xca/0x5a0
[ 35.749567] [] ? scnprintf+0x3d/0x70
[ 35.749567] [] i915_hangcheck_elapsed+0x213/0x510
[ 35.749567] [] process_one_work+0x15b/0x470
[ 35.749567] [] worker_thread+0x43/0x4d0
[ 35.749567] [] ? process_one_work+0x470/0x470
[ 35.749567] [] ? process_one_work+0x470/0x470
[ 35.749567] [] ?
call_usermodehelper_exec_async+0x12e/0x130
[ 35.749567] [] kthread+0xc5/0xe0
[ 35.749567] [] ? kthread_park+0x60/0x60
[ 35.749567] [] ? umh_complete+0x40/0x40
[ 35.749567] [] ret_from_fork+0x22/0x30
Signed-off-by: Changbin Du
---
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0a09024..81a9b0b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1450,7 +1450,7 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
/* Catch up with any missed context-switch interrupts */
I915_WRITE(RING_CONTEXT_STATUS_PTR(engine), _MASKED_FIELD(0x, 0));
- if (request->ctx != port[0].request->ctx) {
+ if (!execlists_elsp_idle(engine) && request->ctx !=
port[0].request->ctx) {
i915_gem_request_put(port[0].request);
port[0] = port[1];
memset(&port[1], 0, sizeof(port[1]));
--
2.7.4
[PATCH 2/2] drm/i915/psr: program vsc header for psr2
Function hsw_psr_setup handles vsc header setup for psr1 and
skl_psr_setup_vsc handles vsc header setup for psr2.
Setup VSC header in function skl_psr_setup_vsc for psr2 support,
as per edp 1.4 spec, table 6-11:VSC SDP HEADER Extension for psr2
operation.
v2: (Jani)
- Initialize variables to 0
- intel_dp_get_y_cord_status and intel_dp_get_y_cord_status made static
- Correct indentation for continuation lines
- Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED
- Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX_*
- Change VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED to DP_VSC_*
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 26 ++
drivers/gpu/drm/i915/intel_psr.c | 17 +++--
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1a91409..855dcba 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1232,6 +1232,8 @@ struct i915_psr {
bool psr2_support;
bool aux_frame_sync;
bool link_standby;
+ bool y_cord_support;
+ bool colorimetry_support;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fb12896..da577c9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3042,6 +3042,24 @@ static void chv_dp_post_pll_disable(struct intel_encoder
*encoder,
DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
}
+static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
+{
+ uint8_t psr_caps = 0;
+
+ drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_CAPS, &psr_caps);
+ return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
+}
+
+static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
+{
+ uint8_t dprx = 0;
+
+ drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_DPRX_FEATURE_ENUMERATION_LIST,
+ &dprx);
+ return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
+}
+
/* These are source-specific values. */
uint8_t
intel_dp_voltage_max(struct intel_dp *intel_dp)
@@ -3620,6 +3638,14 @@ void intel_dp_set_idle_link_train(struct intel_dp
*intel_dp)
dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not
supported");
+
+ if (dev_priv->psr.psr2_support) {
+ dev_priv->psr.y_cord_support =
+ intel_dp_get_y_cord_status(intel_dp);
+ dev_priv->psr.colorimetry_support =
+ intel_dp_get_colorimetry_status(intel_dp);
+ }
+
}
/* Read the eDP Display control capabilities registers */
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 6aca8ff..c3aa649 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -122,13 +122,26 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
{
struct edp_vsc_psr psr_vsc;
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
/* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
memset(&psr_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
psr_vsc.sdp_header.HB1 = 0x7;
- psr_vsc.sdp_header.HB2 = 0x3;
- psr_vsc.sdp_header.HB3 = 0xb;
+ if (dev_priv->psr.colorimetry_support &&
+ dev_priv->psr.y_cord_support) {
+ psr_vsc.sdp_header.HB2 = 0x5;
+ psr_vsc.sdp_header.HB3 = 0x13;
+ } else if (dev_priv->psr.y_cord_support) {
+ psr_vsc.sdp_header.HB2 = 0x4;
+ psr_vsc.sdp_header.HB3 = 0xe;
+ } else {
+ psr_vsc.sdp_header.HB2 = 0x3;
+ psr_vsc.sdp_header.HB3 = 0xc;
+ }
+
intel_psr_write_vsc(intel_dp, &psr_vsc);
}
--
1.9.1
[PATCH v4 1/2] drm: Wrap the check for atomic_commit implementation
This check is useful for drivers that do not have DRIVER_ATOMIC set but
have atomic modesetting internally implemented. Wrap the check into a
function since this is used in many places and as a bonus, the function
name helps to document what the check is for.
v2:
Change return type to bool (Ville)
Move the function drm_atomic.h (Daniel)
Fixed comment marker for documentation
v3:
Included drmP.h to dereference struct drm_device
Suggested-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Ben Skeggs
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_fb_helper.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_connector.c | 5 +++--
drivers/gpu/drm/nouveau/nouveau_display.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 ++-
include/drm/drm_atomic.h| 13 +
5 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 145d55f..730342c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -405,7 +405,7 @@ static int restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
drm_warn_on_modeset_not_all_locked(dev);
- if (dev->mode_config.funcs->atomic_commit)
+ if (drm_drv_uses_atomic_modeset(dev))
return restore_fbdev_mode_atomic(fb_helper);
drm_for_each_plane(plane, dev) {
@@ -1444,7 +1444,7 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
*var,
return -EBUSY;
}
- if (dev->mode_config.funcs->atomic_commit) {
+ if (drm_drv_uses_atomic_modeset(dev)) {
ret = pan_display_atomic(var, info);
goto unlock;
}
@@ -2060,7 +2060,7 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
* NULL we fallback to the default drm_atomic_helper_best_encoder()
* helper.
*/
- if (fb_helper->dev->mode_config.funcs->atomic_commit &&
+ if (drm_drv_uses_atomic_modeset(fb_helper->dev) &&
!connector_funcs->best_encoder)
encoder = drm_atomic_helper_best_encoder(connector);
else
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 947c200..966d20a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include "nouveau_reg.h"
#include "nouveau_drv.h"
@@ -769,7 +770,7 @@ nouveau_connector_set_property(struct drm_connector
*connector,
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
int ret;
- if (connector->dev->mode_config.funcs->atomic_commit)
+ if (drm_drv_uses_atomic_modeset(connector->dev))
return drm_atomic_helper_connector_set_property(connector,
property, value);
ret = connector->funcs->atomic_set_property(&nv_connector->base,
@@ -1074,7 +1075,7 @@ nouveau_connector_helper_funcs = {
static int
nouveau_connector_dpms(struct drm_connector *connector, int mode)
{
- if (connector->dev->mode_config.funcs->atomic_commit)
+ if (drm_drv_uses_atomic_modeset(connector->dev))
return drm_atomic_helper_connector_dpms(connector, mode);
return drm_helper_connector_dpms(connector, mode);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index c5cf888..add353e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -162,7 +162,7 @@ nouveau_display_vblstamp(struct drm_device *dev, unsigned
int pipe,
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
if (nouveau_crtc(crtc)->index == pipe) {
struct drm_display_mode *mode;
- if (dev->mode_config.funcs->atomic_commit)
+ if (drm_drv_uses_atomic_modeset(dev))
mode = &crtc->state->adjusted_mode;
else
mode = &crtc->hwmode;
@@ -738,7 +738,7 @@ nouveau_display_suspend(struct drm_device *dev, bool
runtime)
struct nouveau_display *disp = nouveau_display(dev);
struct drm_crtc *crtc;
- if (dev->mode_config.funcs->atomic_commit) {
+ if (drm_drv_uses_atomic_modeset(dev)) {
if (!runtime) {
disp->suspend = nouveau_atomic_suspend(dev);
if (IS_ERR(disp->suspend)) {
@@ -784,7 +784,7 @@ nouveau_display_resume(struct drm_device *dev, bool runtime)
struct drm_crtc *crtc;
int ret;
- if (dev->mode_config.funcs->atomic_commit) {
+ if (drm_drv_uses_atomic_modeset(dev)) {
nouveau_display_init(dev);
if (disp->suspend) {
drm_atomic_helper_resume(dev, disp->suspend);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/
[RFC 00/10] implement alternative and much simpler id allocator
On Sat, Dec 17 2016, Matthew Wilcox wrote:
> From: Matthew Wilcox
>> From: Rasmus Villemoes [mailto:linux at rasmusvillemoes.dk]
>> > This sounds good. I think there may still be a lot of users that never
>> > allocate more than a handful of IDAs, making a 128 byte allocation still
>> > somewhat excessive. One thing I considered was (exactly as it's done for
>> > file descriptor tables) to embed a single word in the struct ida and
>> > use that initially; I haven't looked closely at newIDA, so I don't know
>> > how easy that would be or if its worth the complexity.
>>
>> Heh, I was thinking about that too. The radix tree supports "exceptional
>> entries" which have the bottom bit set. On a 64-bit machine, we could use 62
>> of the bits in the radix tree root to store the ID bitmap. I'm a little
>> wary of the
>> potential complexity, but we should try it out.
>
> Test patch here:
> http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/idr-2016-12-16
> It passes the test suite ... which I actually had to adjust because it
> now succeeds in cases where it hadn't (allocating ID 0 without
> preallocating), and it will now fail in cases where it hadn't
> previously (assuming a single preallocation would be enough). There
> shouldn't be any examples of that in the kernel proper; it was simply
> me being lazy when I wrote the test suite.
Nice work! A few random comments/questions:
- It does add some complexity, but I think a few comments would make it
more digestable.
- Hm, maybe I'm confused, and I certainly don't understand how the whole
radix tree works. But do you use every leaf node as an exceptional
entry initially, to allocate the first 62 ids from that level? This
code
if ((bit + RADIX_TREE_EXCEPTIONAL_SHIFT) <
BITS_PER_LONG) {
bit += RADIX_TREE_EXCEPTIONAL_SHIFT;
radix_tree_iter_replace(root, &iter, slot,
(void *)((1UL << bit) |
RADIX_TREE_EXCEPTIONAL_ENTRY));
*id = new;
return 0;
}
operates on bit, which is the offset from index*IDA_BITMAP_BITS, and
it seems to create an exceptional entry somewhere down the tree
(which may of course be the root).
But we don't seem to allocate another bit from that exceptional entry
ever unless it happened to sit at index 0; the code
unsigned long tmp = (unsigned long)bitmap;
if (start < BITS_PER_LONG) {
unsigned tbit = find_next_zero_bit(&tmp,
BITS_PER_LONG, start);
if (tbit < BITS_PER_LONG) {
tmp |= 1UL << tbit;
rcu_assign_pointer(*slot, (void *)tmp);
*id = new + tbit -
RADIX_TREE_EXCEPTIONAL_SHIFT;
return 0;
}
}
is only used for small values of start (though it does seem to
account for a non-zero value of new == iter.index * IDA_BITMAP_BITS).
- In the micro-optimization department, I think we should avoid
find_next_zero_bit on a single word, and instead use __ffs. Something
like (assuming we can use bit instead of start)
if (bit + RADIX_TREE_EXCEPTIONAL_SHIFT < BITS_PER_LONG) {
tmp = (~(unsigned long)bitmap) >> (bit + RADIX_TREE_EXCEPTIONAL_SHIFT);
if (tmp) {
tbit = __ffs(tmp) + bit + RADIX_TREE_EXCEPTIONAL_SHIFT;
tmp = (unsigned long)bitmap | (1UL << tbit);
rcu_assign_pointer(*slot, (void *)tmp);
*id = new + tbit - RADIX_TREE_EXCEPTIONAL_SHIFT;
return 0;
}
}
Rasmus
[RFC 00/10] implement alternative and much simpler id allocator
From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
> Nice work! A few random comments/questions:
>
> - It does add some complexity, but I think a few comments would make it
> more digestable.
I'm open to adding some comments ... I need some time between writing the code
and writing the comments to be sure what comments are useful.
> - Hm, maybe I'm confused, and I certainly don't understand how the whole
> radix tree works. But do you use every leaf node as an exceptional
> entry initially, to allocate the first 62 ids from that level? This
> code
I do! And that question tells me one useful comment to add!
> if ((bit + RADIX_TREE_EXCEPTIONAL_SHIFT) <
> BITS_PER_LONG) {
> bit += RADIX_TREE_EXCEPTIONAL_SHIFT;
> radix_tree_iter_replace(root, &iter, slot,
> (void *)((1UL << bit) |
> RADIX_TREE_EXCEPTIONAL_ENTRY));
> *id = new;
> return 0;
> }
>
>operates on bit, which is the offset from index*IDA_BITMAP_BITS, and
>it seems to create an exceptional entry somewhere down the tree
>(which may of course be the root).
>
>But we don't seem to allocate another bit from that exceptional entry
>ever unless it happened to sit at index 0; the code
>
> unsigned long tmp = (unsigned long)bitmap;
> if (start < BITS_PER_LONG) {
> unsigned tbit = find_next_zero_bit(&tmp,
> BITS_PER_LONG, start);
> if (tbit < BITS_PER_LONG) {
> tmp |= 1UL << tbit;
> rcu_assign_pointer(*slot, (void *)tmp);
> *id = new + tbit -
> RADIX_TREE_EXCEPTIONAL_SHIFT;
> return 0;
> }
> }
>
>is only used for small values of start (though it does seem to
>account for a non-zero value of new == iter.index * IDA_BITMAP_BITS).
Ahh. You're reading the code wrong, and I wrote the code wrongly too, so it's
clearly overly complex. I was testing with 'start' set to 0, allocating N
entries, and then freeing them. If I'd set start to 1024 and allocated two
entries, I'd've seen the failure.
Please see the top commit here ("Improve IDA exceptional entry handling"):
http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/idr-2016-12-20
> - In the micro-optimization department, I think we should avoid
> find_next_zero_bit on a single word, and instead use __ffs. Something
> like (assuming we can use bit instead of start)
>
> if (bit + RADIX_TREE_EXCEPTIONAL_SHIFT < BITS_PER_LONG) {
> tmp = (~(unsigned long)bitmap) >> (bit + RADIX_TREE_EXCEPTIONAL_SHIFT);
> if (tmp) {
> tbit = __ffs(tmp) + bit + RADIX_TREE_EXCEPTIONAL_SHIFT;
> tmp = (unsigned long)bitmap | (1UL << tbit);
> rcu_assign_pointer(*slot, (void *)tmp);
> *id = new + tbit - RADIX_TREE_EXCEPTIONAL_SHIFT;
> return 0;
> }
> }
I'm certainly open to microoptimisations, but I'll have to think about this one
for a bit.
