[PATCH] drm: omapdrm: dss: replace ternary operator with max()

Fix the following coccicheck warning: drivers/gpu/drm/omapdrm/dss/dispc.c:2454:21-22: WARNING opportunity for max() Signed-off-by: Guo Zhengkui --- drivers/gpu/drm/omapdrm/dss/dispc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c

[PATCH v2 5/6] drm/i915/sseu: Disassociate internal subslice mask representation from uapi

As with EU masks, it's easier to store subslice/DSS masks internally in a format that's more natural for the driver to work with, and then only covert into the u8[] uapi form when the query ioctl is invoked. Since the hardware design changed significantly with Xe_HP, we'll use a union to choose

[PATCH v2 4/6] drm/i915/sseu: Don't try to store EU mask internally in UAPI format

Storing the EU mask internally in the same format the I915_QUERY topology queries use makes the final copy_to_user() a bit simpler, but makes the rest of the driver's SSEU more complicated and harder to follow. Let's switch to an internal representation that's more natural: Xe_HP platforms will

[PATCH v2 3/6] drm/i915/sseu: Simplify gen11+ SSEU handling

Although gen11 and gen12 architectures supported the concept of multiple slices, in practice all the platforms that were actually designed only had a single slice (i.e., note the parameters to 'intel_sseu_set_info' that we pass for each platform). We can simplify the code slightly by dropping the

[PATCH v2 6/6] drm/i915/pvc: Add SSEU changes

PVC splits the mask of enabled DSS over two registers. It also changes the meaning of the EU fuse register such that each bit represents a single EU rather than a pair of EUs. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_sseu.c

[PATCH v2 1/6] drm/i915/xehp: Use separate sseu init function

Xe_HP has enough fundamental differences from previous platforms that it makes sense to use a separate SSEU init function to keep things straightforward and easy to understand. We'll also add a has_xehp_dss flag to the SSEU structure that will be used by other upcoming changes. v2: - Add

[PATCH v2 2/6] drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK

Slice/subslice/EU information should be obtained via the topology queries provided by the I915_QUERY interface; let's turn off support for the old GETPARAM lookups on Xe_HP and beyond where we can't return meaningful values. The slice mask lookup is meaningless since Xe_HP doesn't support

[PATCH v2 0/6] i915: SSEU handling updates

This series reworks i915's internal handling of slice/subslice/EU (SSEU) data to represent platforms like Xe_HP in a more natural manner and to prepare for future platforms where the masks will need to grow in size. One key idea of this series is that although we have a fixed ABI to convey SSEU

linux-next: manual merge of the drm tree with the drm-intel-fixes tree

Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/i915_reg.h between commit: 54395a33718a ("drm/i915/dmc: Add MMIO range restrictions") from the drm-intel-fixes tree and commit: 9c67d9e84c7d ("drm/i915/dmc: split out dmc registers to a separate

[linux-next:master] BUILD REGRESSION 3f7bdc402fb06f897ff1f492a2d42e1f7c2efedb

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 3f7bdc402fb06f897ff1f492a2d42e1f7c2efedb Add linux-next specific files for 20220516 Error/Warning reports: https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com https

Re: [PATCH 1/2] dt-bindings: leds: qcom-wled: fix number of addresses

On Thu, 05 May 2022 17:47:01 +0200, Krzysztof Kozlowski wrote: > On PM660L, PMI8994 and PMI8998, the WLED has two address spaces. This > also fixes dtbs_check warnings like: > > arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dtb: leds@d800: reg: > [[55296], [2]] is too long > >

[PATCH v2 09/13] tools: update hmm-test to support device coherent type

Test cases such as migrate_fault and migrate_multiple, were modified to explicit migrate from device to sys memory without the need of page faults, when using device coherent type. Snapshot test case updated to read memory device type first and based on that, get the proper returned results

[PATCH v2 05/13] drm/amdkfd: add SPM support for SVM

When CPU is connected throug XGMI, it has coherent access to VRAM resource. In this case that resource is taken from a table in the device gmc aperture base. This resource is used along with the device type, which could be DEVICE_PRIVATE or DEVICE_COHERENT to create the device page map region.

[PATCH v2 07/13] lib: test_hmm add module param for zone device type

In order to configure device coherent in test_hmm, two module parameters should be passed, which correspond to the SP start address of each device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed, private device type is configured. Signed-off-by: Alex Sierra Acked-by: Felix

[PATCH v2 10/13] tools: update test_hmm script to support SP config

Add two more parameters to set spm_addr_dev0 & spm_addr_dev1 addresses. These two parameters configure the start SP addresses for each device in test_hmm driver. Consequently, this configures zone device type as coherent. Signed-off-by: Alex Sierra Acked-by: Felix Kuehling Reviewed-by: Alistair

[PATCH v2 13/13] tools: add selftests to hmm for COW in device memory

The objective is to test device migration mechanism in pages marked as COW, for private and coherent device type. In case of writing to COW private page(s), a page fault will migrate pages back to system memory first. Then, these pages will be duplicated. In case of COW device coherent type, pages

[PATCH v2 06/13] lib: test_hmm add ioctl to get zone device type

new ioctl cmd added to query zone device type. This will be used once the test_hmm adds zone device coherent type. Signed-off-by: Alex Sierra Acked-by: Felix Kuehling Reviewed-by: Alistair Poppple Signed-off-by: Christoph Hellwig --- lib/test_hmm.c | 23 +--

[PATCH v2 08/13] lib: add support for device coherent type in test_hmm

Device Coherent type uses device memory that is coherently accesible by the CPU. This could be shown as SP (special purpose) memory range at the BIOS-e820 memory enumeration. If no SP memory is supported in system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP. Currently, test_hmm only

[PATCH v2 11/13] mm: handling Non-LRU pages returned by vm_normal_pages

With DEVICE_COHERENT, we'll soon have vm_normal_pages() return device-managed anonymous pages that are not LRU pages. Although they behave like normal pages for purposes of mapping in CPU page, and for COW. They do not support LRU lists, NUMA migration or THP. We also introduced a FOLL_LRU flag

[PATCH v2 02/13] mm: add device coherent vma selection for memory migration

This case is used to migrate pages from device memory, back to system memory. Device coherent type memory is cache coherent from device and CPU point of view. Signed-off-by: Alex Sierra Acked-by: Felix Kuehling Reviewed-by: Alistair Poppple Signed-off-by: Christoph Hellwig ---

[PATCH v2 12/13] tools: add hmm gup tests for device coherent type

The intention is to test hmm device coherent type under different get user pages paths. Also, test gup with FOLL_LONGTERM flag set in device coherent pages. These pages should get migrated back to system memory. Signed-off-by: Alex Sierra Reviewed-by: Alistair Popple ---

[PATCH v2 03/13] mm: remove the vma check in migrate_vma_setup()

From: Alistair Popple migrate_vma_setup() checks that a valid vma is passed so that the page tables can be walked to find the pfns associated with a given address range. However in some cases the pfns are already known, such as when migrating device coherent pages during pin_user_pages() meaning

[PATCH v2 04/13] mm/gup: migrate device coherent pages when pinning instead of failing

From: Alistair Popple Currently any attempts to pin a device coherent page will fail. This is because device coherent pages need to be managed by a device driver, and pinning them would prevent a driver from migrating them off the device. However this is no reason to fail pinning of these

[PATCH v2 01/13] mm: add zone device coherent type memory support

Device memory that is cache coherent from device and CPU point of view. This is used on platforms that have an advanced system bus (like CAPI or CXL). Any page of a process can be migrated to such memory. However, no one should be allowed to pin such memory so that it can always be evicted.

[PATCH v2 00/13] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping

This is our MEMORY_DEVICE_COHERENT patch series rebased and updated for current 5.18-rc7. Changes since the last version: - Fixed problems with migration during long-term pinning in get_user_pages - Open coded vm_normal_lru_pages as suggested in previous code review - Update hmm_gup_test with

[PATCH v2 26/27] dyndbg: 4 new trace-events: pr_debug, dev_dbg, drm_{, dev}debug

ddebug_trace() currently issues a single printk:console event. Replace that, adding include/trace/events/dyndbg.h, which defines 2 new events: - dyndbg:prdbg - from trace_prdbg() - if !dev - dyndbg:devdbg - from trace_devdbg() - if !!dev This links the legacy pr_debug API to tracefs, via

[PATCH v2 27/27] dyndbg/drm: POC add tracebits sysfs-knob

clone DRM.debug interface to DRM.tracebits: ie map bits to drm-debug-categories, except this interface enables messages to tracefs, not to syslog. This reuses dyndbg's register-classes API to add the new sysfs-knob: drm_drv.h: [A] 2nd use of DYNAMIC_DEBUG_CLASSES(drm_trace_classes), which

[PATCH v2 21/27] drm_print: prefer bare printk KERN_DEBUG on generic fn

drm_print.c calls pr_debug() just once, from __drm_printfn_debug(), which is a generic/service fn. The callsite is compile-time enabled by DEBUG in both DYNAMIC_DEBUG=y/n builds. For dyndbg builds, reverting this callsite back to bare printk is correcting a few anti-features: 1- callsite is

[PATCH v2 22/27] drm_print: add _ddebug desc to drm_*dbg prototypes

Add a struct _ddebug ptr to drm_dbg() and drm_dev_dbg() protos, and upgrade their callers - the interposed macros added recently, to use _dynamic_func_call_no_desc(); ie drop the '_no_desc', since the factory macro's callees (these 2 functions) are now expecting the arg. This makes those

[PATCH v2 23/27] dyndbg: add _DPRINTK_FLAGS_ENABLED

Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit: _DPRINTK_FLAGS_PRINT (and define former as latter), in preparation to add another bit next: _DPRINTK_FLAGS_TRACE And change JUMP_LABEL code block to use the more general _DPRINTK_FLAGS_ENABLED symbol. Also add a 'K' to get new

[PATCH v2 25/27] dyndbg: add write-events-to-tracefs code

adds: ddebug_trace() uses trace_console() temporarily to issue printk:console event uses internal-ish __ftrace_trace_stack code: 4-context buffer stack, barriers per Steve Rostedt call it from new funcs: ddebug_printk() - print to both syslog/tracefs ddebug_dev_printk() - dev-print to

[PATCH v2 24/27] dyndbg: add _DPRINTK_FLAGS_TRACE

add new flag, and OR it into _DPRINTK_FLAGS_ENABLED definition CC: vincent.whitchu...@axis.com Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index

[PATCH v2 19/27] drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro

For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg() in one of dyndbg's Factory macros: _dynamic_func_call_no_desc(). Next, those functions are adapted to accept a descriptor arg, and we drop the _no_desc suffix, then the (~4000) drm.debug callsites will be controllable by their

[PATCH v2 18/27] drm_print: interpose drm_*dbg with forwarding macros

change drm_dev_dbg & drm_dbg to macros, which forward to the renamed functions (with __ prefix added). Those functions sit below the categorized layer of macros implementing the DRM debug.category API, and implement most of it. These are good places to insert dynamic-debug jump-label mechanics,

[PATCH v2 20/27] drm_print: refine drm_debug_enabled for jump-label

In order to use dynamic-debug's jump-label optimization in drm-debug, its clarifying to refine drm_debug_enabled into 3 uses: 1. drm_debug_enabled - legacy, public 2. __drm_debug_enabled - optimized for dyndbg jump-label enablement. 3. _drm_debug_enabled - pr_debug instrumented, observable 1.

[PATCH v2 15/27] drm: POC drm on dyndbg - map class-names to drm_debug_category's

Invoke DYNAMIC_DEBUG_CLASSES from drm_drv.h. This declares a maybe-unused struct ddebug_known_classes_map var, initialized with: . var: passed to dynamic_debug_register_classes() . class-names: "DRM_UT_CORE", "DRM_UT_DRIVER", "DRM_UT_KMS", etc. These names map to .class_id's by their index,

[PATCH v2 14/27] dyndbg: add test_dynamic_debug module

Demonstrate dyndbg's "class FOO" and bitmap-to-classes support. This support is meant to plug into drm.debug system, and largely replace the use of drm_debug_enabled(category) with JUMP_LABELs. Recap: #> echo class DRM_UT_CORE +p > /proc/dynamic_debug/control This is made "safe" because

[PATCH v2 17/27] drm_print: condense enum drm_debug_category

enum drm_debug_category has 10 categories, but is initialized with bitmasks which require 10 bits of underlying storage. By using natural enumeration, and moving the BIT(cat) into drm_debug_enabled(), the enum fits in 4 bits, allowing the category to be represented directly in pr_debug callsites,

[PATCH v2 16/27] drm/print: POC drm on dyndbg - use bitmap

POC: adapt drm_print to use/test the bitmap callback support. with dynamic_debug.verbose=1: bash-5.1# echo 1 > /sys/module/drm/parameters/debug [ 33.697039] dyndbg: set_dyndbg_classes: new 0x1 current 0x0 [ 33.697571] dyndbg: query 0: "class DRM_UT_CORE +p" mod:* [ 33.698072] dyndbg: no

[PATCH v2 09/27] Doc/dyndbg: document new class class_name query support

The added paragraph is slightly process oriented, rather than in language of guarantees; I thought the implications were clear enough. It does perhaps undersell the selectivity gained with string class_names; only drm/* would sanely register DRM_UT_CORE etc, so doing multiple "module

[PATCH v2 13/27] dyndbg: add __pr_debug_cls(class, fmt, ...)

For selftest purposes, add __pr_debug_cls(class, fmt, ...) I didn't think we'd need to define this, since DRM effectively has it already. But test_dynamic_debug needs it in order to demonstrate all the moving parts. Note the __ prefix; its not intended for general use, and doesn't include any

[PATCH v2 11/27] dyndbg: support symbolic class-names in bitmap

Extend the sysfs-node bitmap support to accept class-names registered by the module, allowing: #> echo DRM_UT_CORE,-DRM_UT_ATOMIC,+DRM_UT_KMS \ > /sys/module/drm/parameters/debug Do this in param_set_dyndbg_class_strings(), which is called from param_set_dyndbg_classes() when the

[PATCH v2 12/27] dyndbg: change zero-or-one classes-map to maps list

Upgrade single classes-map to list of them: This allows multiple DYNAMIC_DEBUG_CLASSES(class-map)s per module, using _base to segment the 0..30 classid space. alter struct ddebug table: replace .classes (a ) with maps (list-head) dynamic_debug_register_classes(map) - adds new map to maps list.

[PATCH v2 10/27] dyndbg: let query-modname override defaulting modname

dyndbg's control-parser: ddebug_parse_query(), requires that search terms: module, func, file, lineno, are not used 2x in a query; a thing cannot be named both foo and bar (not even wildcards, no OR is contemplated). Amend the treatment of module; while still enforcing the 2x rule on it, set the

[PATCH v2 08/27] dyndbg: add drm.debug style bitmap support

Add kernel_param_ops and callbacks to implement a bitmap in a sysfs-node. IE, add these: - int param_set_dyndbg_classes() - int param_get_dyndbg_classes() - struct kernel_param_ops param_ops_dyndbg_classes Following the model of kernel/params.c STANDARD_PARAM_DEFS, these are non-static and

[PATCH v2 07/27] dyndbg: validate class FOO on module

Add module-to-class validation, in #> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control If a query has "class FOO", ddebug_validate_classname (called from ddebug_change) requires that FOO is known to module X, otherwize X is skipped entirely. The choice of FOO is highly selective, giving

[PATCH v2 05/27] dyndbg: add exclusive class_id to pr_debug callsites

DRM issues ~10 exclusive categories of debug messages; to represent this directly in dyndbg, add a new field: struct _ddebug.class_id:5. We only need 4 bits for drm, and with that reserved, we have 2 to spare on 32 bit builds; lets take one extra (5 bits total), and keep a spare bit. 32

[PATCH v2 06/27] dyndbg: add dynamic_debug_(un)register_classes

Add dynamic_debug_register_classes() to API, allowing user modules (builtin and loadable) to register class_names for the .class_id's they are using. Knowing classes is 1st step to validating with them. Add dynamic_debug_unregister_classes() also. Add struct ddebug_known_classes_map: maps known

[PATCH v2 04/27] dyndbg: drop EXPORTed dynamic_debug_exec_queries

This exported fn is unused, and is effectively obsoleted by a forthcoming commit, so remove it. The export was added to let drm control pr_debugs, as part of using them to avoid drm_debug_enabled overheads. But following patches implement the drm.debug interface, and adapt drm to just use it, so

[PATCH v2 03/27] dyndbg: fix module.dyndbg handling

For CONFIG_DYNAMIC_DEBUG=N, the ddebug_dyndbg_module_param_cb() stub-fn is too permissive: bash-5.1# modprobe drm JUNKdyndbg bash-5.1# modprobe drm dyndbgJUNK [ 42.933220] dyndbg param is supported only in CONFIG_DYNAMIC_DEBUG builds [ 42.937484] ACPI: bus type drm_connector registered This

[PATCH v2 02/27] dyndbg: show both old and new in change-info

print "old -> new" flag values in the info("change") message. no functional change. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index a56c1286ffa4..ca2a28f1d51c

[PATCH v2 01/27] dyndbg: fix static_branch manipulation

In https://lore.kernel.org/lkml/20211209150910.ga23...@axis.com/ Vincent's patch commented on, and worked around, a bug toggling static_branch's, when a 2nd PRINTK-ish flag was added. The bug results in a premature static_branch_disable when the 1st of 2 flags was disabled. The cited commit

[RFC PATCH v2 00/27] DRM.debug on DYNAMIC_DEBUG, add trace events

DRM.debug API is 23 macros, issuing 10 exclusive categories of debug messages. By rough count, they are used 5140 times in the kernel. These all call drm_dbg or drm_devdbg, which call drm_debug_enabled(), which checks bits in global __drm_debug. Some of these are page-flips and vblanks, and get

Re: [PATCH v2 11/12] dt-bindings: display: exynos: dsim: Add NXP i.MX8MM support

On Wed, 04 May 2022 17:10:20 +0530, Jagan Teki wrote: > Samsung MIPI DSIM bridge can also be found in i.MX8MM SoC. > > Add dt-bingings for it. > > v2: > * updated comments > > v1: > * new patch > > Cc: devicet...@vger.kernel.org, > Cc: Rob Herring > Signed-off-by: Jagan Teki > --- > Note: >

Re: (subset) [PATCH v2 0/3] RK356x VOP2: Change register space names

On Wed, 11 May 2022 10:21:06 +0200, Sascha Hauer wrote: > The VOP2 driver sitting in next uses named register spaces, but the > binding lacks documentation for that. Add the missing documentation > and while at it take the opportunity to rename the register spaces > from too generic "regs" to

Re: [PATCH 1/1] drm/i915/guc: Remove unnecessary GuC err capture noise

On 5/6/2022 21:58, Alan Previn wrote: GuC error capture blurts some debug messages about empty register lists for certain register types on engines during firmware initialization. These are not errors or warnings, so get rid of them. Signed-off-by: Alan Previn Reviewed-by: John Harrison

Re: linux-next: Tree for May 16 (drm/i915/gt/intel_gt_sysfs_pm.c)

On 5/16/22 03:57, Stephen Rothwell wrote: > Hi all, > > Changes since 20220513: > on i386: CC drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.o ../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function ‘act_freq_mhz_show’: ../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:276:20: error:

Re: [PATCH v2] dma-buf: Move sysfs work out of DMA-BUF export path

Am 16.05.22 um 20:08 schrieb T.J. Mercier: On Mon, May 16, 2022 at 10:20 AM Christian König wrote: Am 16.05.22 um 19:13 schrieb T.J. Mercier: Recently, we noticed an issue where a process went into direct reclaim while holding the kernfs rw semaphore for sysfs in write (exclusive) mode. This

Re: [linux-next:master] BUILD REGRESSION 1e1b28b936aed946122b4e0991e7144fdbbfd77e

On Sun, 15 May 2022 21:00:21 +0800 kernel test robot wrote: > tree/branch: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > branch HEAD: 1e1b28b936aed946122b4e0991e7144fdbbfd77e Add linux-next > specific files for 20220513 > > Error/Warning reports: > >

Re: [PATCH 1/3] usb: gadget: add Aspeed ast2600 udc driver

in https://git-scm.com/docs/git-format-patch] url: https://github.com/intel-lab-lkp/linux/commits/Neal-Liu/add-Aspeed-udc-driver-for-ast2600/20220513-150314 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing config: mips-randconfig-s032-20220516 (https

[PATCH v3] drm/doc: add rfc section for small BAR uapi

Add an entry for the new uapi needed for small BAR on DG2+. v2: - Some spelling fixes and other small tweaks. (Akeem & Thomas) - Rework error capture interactions, including no longer needing NEEDS_CPU_ACCESS for objects marked for capture. (Thomas) - Add probed_cpu_visible_size.

Re: [PATCH v2] dma-buf: Move sysfs work out of DMA-BUF export path

Am 16.05.22 um 19:13 schrieb T.J. Mercier: Recently, we noticed an issue where a process went into direct reclaim while holding the kernfs rw semaphore for sysfs in write (exclusive) mode. This caused processes who were doing DMA-BUF exports and releases to go into uninterruptible sleep since

Re: [PATCH v2 1/3] dt-bindings: display: rockchip: make reg-names mandatory for VOP2

Heiko, On Mon, May 16, 2022 at 10:12:26AM -0500, Rob Herring wrote: > On Wed, 11 May 2022 10:21:07 +0200, Sascha Hauer wrote: > > The VOP2 driver relies on reg-names properties, but these are not > > documented. Add the missing documentation, make reg-names mandatory > > and increase minItems to

Re: [PATCH v1 01/13] dt-bindings: Add bindings for Tegra234 Host1x and VIC

On Mon, May 16, 2022 at 01:02:01PM +0300, cyn...@kapsi.fi wrote: > From: Mikko Perttunen > > Update VIC and Host1x bindings for changes in Tegra234. > > Namely, > - New compatible strings > - Sharded syncpoint interrupts > - Optional reset. > > Signed-off-by: Mikko Perttunen > --- >

[PATCH v1 2/2] drm/panel: simple: add bus-format support for panel-dpi

From: Max Krummenacher Evaluate the device tree bus-format property to set bus_format for a 'panel-dpi' panel. Additionally infer the bpc value from the given bus-format. Valid values for bus-format are found in: This completes the addition of panel-dpi to completely specify a panel-simple

[PATCH v1 1/2] dt-bindings: display: add new bus-format property for panel-dpi

From: Max Krummenacher The property is used to set the enum bus_format and infer the bpc for a panel defined by 'panel-dpi'. This specifies how the panel is connected to the display interface. Signed-off-by: Max Krummenacher --- .../bindings/display/panel/panel-dpi.yaml | 11 +

[PATCH v1 0/2] drm/panel: simple: add bus-format support for panel-dpi

From: Max Krummenacher Commit 4a1d0dbc8332 ("drm/panel: simple: add panel-dpi support") added support for defining a panel from device tree provided data. However support for setting the bus format is missing, so that with the current implementation a 'panel-dpi' panel can only be used if the

Re: [PATCH v5 1/9] dt-bindings: host1x: Add iommu-map property

On Mon, 16 May 2022 11:52:50 +0300, cyn...@kapsi.fi wrote: > From: Mikko Perttunen > > Add schema information for specifying context stream IDs. This uses > the standard iommu-map property. > > Signed-off-by: Mikko Perttunen > Reviewed-by: Robin Murphy > --- > v3: > * New patch > v4: > *

Re: [PATCH v2 1/3] dt-bindings: display: rockchip: make reg-names mandatory for VOP2

On Wed, 11 May 2022 10:21:07 +0200, Sascha Hauer wrote: > The VOP2 driver relies on reg-names properties, but these are not > documented. Add the missing documentation, make reg-names mandatory > and increase minItems to 2 as always both register spaces are needed. > > Signed-off-by: Sascha Hauer

Re: linux-next: Tree for May 16 (drm/msm: kconfig warning)

On 5/16/22 03:57, Stephen Rothwell wrote: > Hi all, > > Changes since 20220513: > on i386 or x86_64: WARNING: unmet direct dependencies detected for DRM_DP_AUX_BUS Depends on [n]: HAS_IOMEM [=y] && DRM [=y] && OF [=n] Selected by [y]: - DRM_MSM [=y] && HAS_IOMEM [=y] && DRM [=y] &&

Re: [PATCH] drm: Add a debug message when getting a prop is missing

friendly ping :)) On Tue, May 10, 2022 at 2:28 PM Mark Yacoub wrote: > > [Why] > If a connector property is attached but > drm_atomic_connector_get_property doesn't handle a case for it, > modeteset will crash with a segfault without. > > [How] > Add a debug message indicating that a connector

Re: [PATCH] drm: Create support for Write-Only property blob

friendly ping :)) On Tue, May 10, 2022 at 3:08 PM Mark Yacoub wrote: > > [Why] > User space might need to inject data into the kernel without allowing it > to be read again by any user space. > An example of where this is particularly useful is secret keys fetched > by user space and injected

Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

On Mon, May 16, 2022 at 8:40 AM Mike Lothian wrote: > > Hi > > The merge window for 5.19 will probably be opening next week, has > there been any progress with this bug? It took a while to find a combination of GPUs that would repro the issue, but now that we can, it is still being investigated.

Re: [PATCH] drm: bridge: icn6211: Register macro clean up

On Sat, 30 Apr 2022 at 04:50, Marek Vasut wrote: > > Drop two unused register macros, ICN6211_MAX_REGISTER and MIPI_ATE_STATUS_1, > neither of which is used and where the later should be specified using macro > MIPI_ATE_STATUS(1) instead. Drop the _(n) underscore and keep only the (n) > part of

Re: [greybus-dev] Re: [PATCH] [v2] Kbuild: move to -std=gnu11

On 5/16/22 06:31, Greg KH wrote: On Mon, May 16, 2022 at 06:10:23AM -0700, Guenter Roeck wrote: On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: From: Arnd Bergmann During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99,

Re: [PATCH v5 5/9] iommu/arm-smmu: Attach to host1x context device bus

On Mon, May 16, 2022 at 02:20:18PM +0300, Mikko Perttunen wrote: > On 5/16/22 13:44, Robin Murphy wrote: > > On 2022-05-16 11:13, Mikko Perttunen wrote: > > > On 5/16/22 13:07, Will Deacon wrote: > > > > On Mon, May 16, 2022 at 11:52:54AM +0300, cyn...@kapsi.fi wrote: > > > > > From: Mikko

[PATCH v3 6/7] drm/mgag200: Test memory requirements in drm_mode_config_funcs.mode_valid

Test for a mode's memory requirements in the device-wide mode_valid helper. For simplicify, always assume a 32-bit color format. While some rejected modes would work with less colors, implementing this is probably not worth the effort. Also remove the memory-related test from the connector's

[PATCH v3 7/7] drm/mgag200: Split up connector's mode_valid helper

Split up the connector's mode_valid helper into a simple-pipe and a mode-config helper. The simple-pipe helper tests for display-size limits while the mode-config helper tests for memory-bandwidth limits. Also add the mgag200_ prefix to mga_vga_calculate_mode_bandwidth() and comment on the

[PATCH v3 3/7] drm/mgag200: Implement connector's get_modes with helper

Provide drm_connector_helper_get_modes_from_ddc() to implement the connector's get_modes callback. The new helper updates the connector from DDC-provided EDID data. v2: * clear property if EDID is NULL in helper Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by:

[PATCH v3 5/7] drm/mgag200: Remove struct mga_connector

struct mga_connector has outlived its purpose. Inline the rsp init helper into the mode-config code and remove the data structure. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by: Jocelyn Falempe --- drivers/gpu/drm/mgag200/mgag200_drv.h | 8

[PATCH v3 1/7] drm/mgag200: Acquire I/O lock while reading EDID

DDC operation conflicts with concurrent mode setting. Acquire the driver's I/O lock in get_modes to prevent this. This change should have been part of commit 931e3f3a0e99 ("drm/mgag200: Protect concurrent access to I/O registers with lock"), but apparently got lost somewhere. v3: * fix

[PATCH v3 2/7] drm/mgag200: Fail on I2C initialization errors

Initialization of the I2C adapter was allowed to fail. The mgag200 driver would have continued without DDC support. Had this happened in practice, it would have led to segmentation faults in the connector code. Resolve this problem by failing driver initialization on I2C- related errors. v2:

[PATCH v3 4/7] drm/mgag200: Switch I2C code to managed cleanup

Store the I2C state within struct mga_device and switch I2C to managed release. Simplifies the related code and lets us remove mga_connector_destroy(). Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by: Jocelyn Falempe --- drivers/gpu/drm/mgag200/mgag200_drv.h | 5 ++--

[PATCH v3 0/7] drm/mgag200: Various cleanups

Various small fixes and clean-up patches for mgag200. Tested on Matrix G200EH hardware. v3: * fix commit message in 1/7 to say 'drm/mgag200' (Jocelyn) v2: * comment on memory constraints on early G200SE-A * fix connector DDC helper Thomas Zimmermann (7): drm/mgag200:

[PATCH v2 2/7] drm/mgag200: Fail on I2C initialization errors

Initialization of the I2C adapter was allowed to fail. The mgag200 driver would have continued without DDC support. Had this happened in practice, it would have led to segmentation faults in the connector code. Resolve this problem by failing driver initialization on I2C- related errors. v2:

[PATCH v2 7/7] drm/mgag200: Split up connector's mode_valid helper

Split up the connector's mode_valid helper into a simple-pipe and a mode-config helper. The simple-pipe helper tests for display-size limits while the mode-config helper tests for memory-bandwidth limits. Also add the mgag200_ prefix to mga_vga_calculate_mode_bandwidth() and comment on the

[PATCH v2 5/7] drm/mgag200: Remove struct mga_connector

struct mga_connector has outlived its purpose. Inline the rsp init helper into the mode-config code and remove the data structure. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by: Jocelyn Falempe --- drivers/gpu/drm/mgag200/mgag200_drv.h | 8

[PATCH v2 3/7] drm/mgag200: Implement connector's get_modes with helper

Provide drm_connector_helper_get_modes_from_ddc() to implement the connector's get_modes callback. The new helper updates the connector from DDC-provided EDID data. v2: * clear property if EDID is NULL in helper Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by:

[PATCH v2 0/7] drm/mgag200: Various cleanups

Various small fixes and clean-up patches for mgag200. Tested on Matrix G200EH hardware. v2: * comment on memory constraints on early G200SE-A * fix connector DDC helper Thomas Zimmermann (7): drm:/mgag200: Acquire I/O lock while reading EDID drm/mgag200: Fail on I2C

[PATCH v2 4/7] drm/mgag200: Switch I2C code to managed cleanup

Store the I2C state within struct mga_device and switch I2C to managed release. Simplifies the related code and lets us remove mga_connector_destroy(). Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Tested-by: Jocelyn Falempe --- drivers/gpu/drm/mgag200/mgag200_drv.h | 5 ++--

[PATCH v2 6/7] drm/mgag200: Test memory requirements in drm_mode_config_funcs.mode_valid

Test for a mode's memory requirements in the device-wide mode_valid helper. For simplicify, always assume a 32-bit color format. While some rejected modes would work with less colors, implementing this is probably not worth the effort. Also remove the memory-related test from the connector's

[PATCH v2 1/7] drm:/mgag200: Acquire I/O lock while reading EDID

DDC operation conflicts with concurrent mode setting. Acquire the driver's I/O lock in get_modes to prevent this. This change should have been part of commit 931e3f3a0e99 ("drm/mgag200: Protect concurrent access to I/O registers with lock"), but apparently got lost somewhere. Signed-off-by:

Re: [PATCH 4/4] drm/gem: Warn on trying to use a non-existing framebuffer plane

On 5/9/22 10:16, Thomas Zimmermann wrote: > Warn if callers of drm_gem_fb_get_obj() try to use a GEM buffer for > a non-existing or unset plane. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Linux Engineering Red

Re: [PATCH 7/7] drm/mgag200: Split up connector's mode_valid helper

Hi Am 12.05.22 um 12:38 schrieb Jocelyn Falempe: ... One suggestion to avoid too much repetition: static int mgag200_get_bandwidth_kbps(mdev) { if (IS_G200_SE(mdev)) {     u32 unique_rev_id = mdev->model.g200se.unique_rev_id;     if (unique_rev_id == 0x01) {    

Re: [PATCH 3/4] drm/gem-vram: Ignore planes that are unused by framebuffer format

On 5/9/22 10:16, Thomas Zimmermann wrote: > Only handle color planes that exist in a framebuffer's color format. > Ignore non-existing planes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas > @@ -673,7 +679,10 @@ drm_gem_vram_plane_helper_prepare_fb(struct

[PATCH v2] drm/nouveau: reorder nouveau_drm_device_fini

Resources needed for output poll workers are destroyed in nouveau_fbcon_fini() before output poll workers are cleared in nouveau_display_fini(). This means there is a time between fbcon_fini() and display_fini(), where if output poll happens, it crashes. This makes output poll workers cleared

Re: [greybus-dev] Re: [PATCH] [v2] Kbuild: move to -std=gnu11

On Mon, May 16, 2022 at 06:10:23AM -0700, Guenter Roeck wrote: > On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > During a patch discussion, Linus brought up the option of changing > > the C standard version from gnu89 to gnu99, which allows using

Re: [PATCH 0/4] drm: Ignore non-existing color planes in helpers

Den 09.05.2022 10.15, skrev Thomas Zimmermann: > Some DRM helpers assume that all potential color planes of a framebuffer > are available; even if the color format didn't specify them. Non-existing > planes are silently ignored. This behavior is inconsistent with other > helpers and apparently

Re: [PATCH 2/4] drm/gem: Ignore color planes that are unused by framebuffer format

On 5/9/22 10:16, Thomas Zimmermann wrote: > Only handle color planes that exist in a framebuffer's color format. > Ignore non-existing planes. > > So far, several helpers assumed that all 4 planes are available and > silently ignored non-existing planes. This lead to subtil bugs with >

Re: [PATCH v2 0/3] mgag200: Improve damage handling

On 04/05/2022 16:59, Thomas Zimmermann wrote: Hi Jocelyn, with my comment on 3/3 considered, you can add Reviewed-by: Thomas Zimemrmann to this patchset. You should get commit access for drm-misc, so that you can land the patchset on your own. Please see  

  1   2   >