On Tue, 2021-08-17 at 23:05 -0700, Kees Cook wrote:
>
> @@ -275,12 +275,11 @@ static void carl9170_tx_release(struct kref *ref)
> if (WARN_ON_ONCE(!ar))
> return;
>
>
>
>
> - BUILD_BUG_ON(
> - offsetof(struct ieee80211_tx_info, status.ack_signal) != 20);
> -
>
Hi,
On Tue, Aug 17, 2021 at 05:50:44PM +0800, CK Hu wrote:
> Hi, Markus:
>
> On Mon, 2021-08-16 at 21:25 +0200, Markus Schneider-Pargmann wrote:
> > dpintf is the displayport interface hardware unit. This unit is similar
> > to dpi and can reuse most of the code.
> >
> > This patch adds support
Hi,
On Wed, Aug 18, 2021 at 12:45:46PM +0800, CK Hu wrote:
> Hi, Markus:
>
> On Mon, 2021-08-16 at 21:25 +0200, Markus Schneider-Pargmann wrote:
> > DP_INTF is similar to the actual dpi. They differ in some points
> > regarding registers and what needs to be set but the function blocks
> > itself
Hi,
The patches in this series are largely fixes and prepwork leading up to
the final patch which plugs races with modesetting rights. Most of the
fixes don't have bug reports, so comments would be very appreciated.
The biggest change from the previous version is that we convert
drm_device.master
The master_lookup_lock spinlock can be useful as an inner lock for
other attributes that are currently protected by
drm_device.master_mutex.
However, since the spinlock belongs to struct drm_file, its use case
is limited to serializing accesses by a single drm_file. Moving this
lock into struct dr
When drm_file.master changes value, the corresponding
drm_device.master_lookup_lock should be held.
In drm_master_release, a call to drm_master_put sets the
file_priv->master to NULL, so we protect this section with
drm_device.master_lookup_lock.
Signed-off-by: Desmond Cheong Zhi Xi
---
drivers
There are three areas where we dereference struct drm_master without
checking if the pointer is non-NULL.
1. drm_getmagic is called from the ioctl_handler. Since
DRM_IOCTL_GET_MAGIC has no ioctl flags, drm_getmagic is run without
any check that drm_file.master has been set.
2. Similarly, drm_getu
There is a window after calling drm_master_release, and before a file
is freed, where drm_file can have is_master set to true, but both the
drm_file and drm_device have no master.
This could result in wrongly approving permissions in
drm_is_current_master_locked. Add a check that fpriv->master is
Currently, drm_device.master_mutex is used to serialize writes to the
drm_master.magic_map idr and to protect drm_master.unique{_len}.
In preparation for converting drm_device.master_mutex into an outer
rwsem that might be read locked before entering some of these
functions, we can instead seriali
drm_device.master_mutex currently protects the following:
- drm_device.master
- drm_file.master
- drm_file.was_master
- drm_file.is_master
These attributes determine modesetting permissions for drm devices,
and there is a clear separation between functions that read or change
the permissions. Henc
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this produces the following lockdep splat:
==
WARNING: possible circular locking dependency detected
5.14.0-rc
The task_work_add function is needed to prevent userspace races with
DRM modesetting rights.
Some DRM ioctls can change modesetting permissions while other
concurrent users are performing modesetting. To prevent races with
userspace, such functions should flush readers of old permissions
before re
In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_rwsem while
committing, and bail if there's already a master.
However, there are other places where modesetting rights can race
On Fri, Jul 30, 2021 at 06:26:34PM +0800, Jiapeng Chong wrote:
> This symbol is not used outside of vc4_hdmi.c, so marks it static.
>
> Fix the following sparse warning:
>
> drivers/gpu/drm/vc4/vc4_hdmi.c:1479:25: warning: symbol
> 'vc4_hdmi_codec_pdata' was not declared. Should it be static?
>
Am 18.08.21 um 09:43 schrieb Gal Pressman:
Hey all,
Currently, the RDMA subsystem can only work with dynamic dmabuf
attachments, which requires the RDMA device to support on-demand-paging
(ODP) which is not common on most devices (only supported by mlx5).
While the dynamic requirement makes sen
On Wed, 2021-08-18 at 09:08 +0200, Johannes Berg wrote:
> On Tue, 2021-08-17 at 23:05 -0700, Kees Cook wrote:
> >
> > @@ -275,12 +275,11 @@ static void carl9170_tx_release(struct kref *ref)
> > if (WARN_ON_ONCE(!ar))
> > return;
> >
> >
> >
> >
> > - BUILD_BUG_ON(
> > -
On 8/18/21 12:20 AM, Rob Herring wrote:
On Wed, Aug 11, 2021 at 01:50:28PM +0300, Mikko Perttunen wrote:
Add YAML device tree bindings for NVDEC, now in a more appropriate
place compared to the old textual Host1x bindings.
Signed-off-by: Mikko Perttunen
---
v3:
* Drop host1x bindings
* Change
On Wed, 18 Aug 2021 at 08:27, Viresh Kumar wrote:
>
> On 18-08-21, 09:22, Dmitry Osipenko wrote:
> > 18.08.2021 08:58, Viresh Kumar пишет:
> > > What about calling dev_pm_opp_set_rate(dev, clk_get_rate(dev)) here
> > > instead ? That will work, right ? The advantage is it works without
> > > any s
On Tue, 17 Aug 2021 at 16:03, Thierry Reding wrote:
>
> On Tue, Aug 17, 2021 at 02:04:38PM +0200, Ulf Hansson wrote:
> > On Tue, 17 Aug 2021 at 03:30, Dmitry Osipenko wrote:
> > >
> > > Add runtime PM and OPP support to the Host1x driver. It's required for
> > > enabling system-wide DVFS and supp
On 18/08/2021 11:00, Christian König wrote:
> Am 18.08.21 um 09:43 schrieb Gal Pressman:
>> Hey all,
>>
>> Currently, the RDMA subsystem can only work with dynamic dmabuf
>> attachments, which requires the RDMA device to support on-demand-paging
>> (ODP) which is not common on most devices (only su
On Wed, Aug 18, 2021 at 10:06:51AM +0200, Johannes Berg wrote:
> On Wed, 2021-08-18 at 09:08 +0200, Johannes Berg wrote:
> > On Tue, 2021-08-17 at 23:05 -0700, Kees Cook wrote:
> > >
> > > @@ -275,12 +275,11 @@ static void carl9170_tx_release(struct kref *ref)
> > > if (WARN_ON_ONCE(!ar))
> > >
On 18-08-21, 10:29, Ulf Hansson wrote:
> Me and Dmitry discussed adding a new genpd callback for this. I agreed
> that it seems like a reasonable thing to add, if he insists.
>
> The intent was to invoke the new callback from __genpd_dev_pm_attach()
> when the device has been attached to its genpd
Among other features the mmsys driver should implement a reset
controller to be able to reset different bits from their space.
For MT8195 vdosys1, many async modules need to reset after
the display pipe stops and restart.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h | 1 +
Add vdosys1 ETHDR definition.
Signed-off-by: Nancy.Lin
---
.../display/mediatek/mediatek,ethdr.yaml | 144 ++
1 file changed, 144 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
diff --git
a/Documentation/devicetree
Add vdosys1 RDMA definition.
Signed-off-by: Nancy.Lin
---
.../display/mediatek/mediatek,mdp-rdma.yaml | 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
diff --git
a/Documentation/devicetre
Add mt8195 vdosys1 clock driver name and routing table to
the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 136 +
drivers/soc/mediatek/mtk-mmsys.c | 10 ++
include/linux/soc/mediatek/mtk-mmsys.h | 2 +
3 files ch
ETHDR is a part of ovl_adaptor.
ETHDR is designed for HDR video and graphics conversion in the external
display path. It handles multiple HDR input types and performs tone
mapping, color space/color format conversion, and then combine
different layers, output the required HDR or SDR signal to the
s
Add mtk-mutex support for mt8195 vdosys1.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements,
so change it to support multi-bit control.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mutex.c | 270 ++-
Add vdosys1 reset control bit for MT8195 platform.
Signed-off-by: Nancy.Lin
---
include/dt-bindings/reset/mt8195-resets.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/dt-bindings/reset/mt8195-resets.h
b/include/dt-bindings/reset/mt8195-resets.h
index a26bccc8b957..e
Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of
the ovl_adaptor component.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 12 ++
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 275
driver
Add cmdq support for mtk-mmsys config API.
The mmsys config register settings need to take effect with the other
HW settings(like OVL_ADAPTOR...) at the same vblanking time.
If we use CPU to write the mmsys reg, we can't guarantee all the
settings can be written in the same vblanking time.
Cmdq is
Add ovl_adaptor driver for MT8195.
Ovl_adaptor is an encapsulated module and designed for simplified
DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
an ETHDR. Two RDMAs merge into one layer, so this module support 4
layers.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek
Add mmsys config API. The config API is used for config mmsys reg.
Some mmsys regs need to be setting according to the HW engine binding
to the mmsys simultaneously.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 62 ++
drivers/soc/mediatek/mtk-mmsy
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add DRM and these modules support by the patches below:
Changes in v3:
- modify for reviewer's comment in v2.
- add vdosys1 2 pixels align limit.
- add mixer odd offset support.
Add driver data of mt8195 vdosys1 to mediatek-drm and modify drm for
multi-mmsys support. The two mmsys (vdosys0 and vdosys1) will bring
up two drm drivers, only one drm driver register as the drm device.
Each drm driver binds its own component. The first bind drm driver
will allocate the drm devic
The mmsys system controller exposes a set of memory client resets and
needs to specify the #reset-cells property in order to advertise the
number of cells needed to describe each of the resets
Signed-off-by: Nancy.Lin
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 3 +++
1
Add display node for vdosys1.
Signed-off-by: Nancy.Lin
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 217 +++
1 file changed, 217 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index aa2a7849b822..b2e377515a52
Add vdosys1 MERGE definition.
Signed-off-by: Nancy.Lin
---
.../devicetree/bindings/display/mediatek/mediatek,merge.yaml| 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
b/Documentation/devicetree/bindings/display/me
On Wed, Aug 18, 2021 at 2:28 AM John Harrison wrote:
> On 8/9/2021 23:36, Daniel Vetter wrote:
> > On Mon, Aug 09, 2021 at 04:12:52PM -0700, John Harrison wrote:
> >> On 8/6/2021 12:46, Daniel Vetter wrote:
> >>> Seen this fly by and figured I dropped a few thoughts in here. At the
> >>> likely co
On Tue, Aug 17, 2021 at 11:05:19PM -0700, Kees Cook wrote:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memset(), avoid intentionally writing across
> neighboring fields.
>
> Use memset_startat() so memset() doesn't get confused about writing
On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman wrote:
>
> Hey all,
>
> Currently, the RDMA subsystem can only work with dynamic dmabuf
> attachments, which requires the RDMA device to support on-demand-paging
> (ODP) which is not common on most devices (only supported by mlx5).
>
> While the dynamic
On Tue, Aug 17, 2021 at 11:04:56PM -0700, Kees Cook wrote:
> The core functions of string.c are those that may be implemented by
> per-architecture functions, or overloaded by FORTIFY_SOURCE. As a
> result, it needs to be built with __NO_FORTIFY. Without this, macros
> will collide with function de
On Wed, 18 Aug 2021 at 11:14, Viresh Kumar wrote:
>
> On 18-08-21, 10:29, Ulf Hansson wrote:
> > Me and Dmitry discussed adding a new genpd callback for this. I agreed
> > that it seems like a reasonable thing to add, if he insists.
> >
> > The intent was to invoke the new callback from __genpd_de
On Wed, 18 Aug 2021 at 11:41, Ulf Hansson wrote:
>
> On Wed, 18 Aug 2021 at 11:14, Viresh Kumar wrote:
> >
> > On 18-08-21, 10:29, Ulf Hansson wrote:
> > > Me and Dmitry discussed adding a new genpd callback for this. I agreed
> > > that it seems like a reasonable thing to add, if he insists.
> >
On Tue, Aug 17, 2021 at 05:08:02PM -0700, John Harrison wrote:
> On 8/9/2021 23:38, Daniel Vetter wrote:
> > On Wed, Jul 28, 2021 at 05:33:59PM -0700, Matthew Brost wrote:
> > > Should fix below failures with GuC submission for the following tests:
> > > gem_exec_balancer --r noheartbeat
> > > gem_
On 18-08-21, 11:41, Ulf Hansson wrote:
> On Wed, 18 Aug 2021 at 11:14, Viresh Kumar wrote:
> > What we need here is just configure. So something like this then:
> >
> > - genpd->get_performance_state()
> > -> dev_pm_opp_get_current_opp() //New API
> > -> dev_pm_genpd_set_performance_state(dev,
On Tue, Aug 17, 2021 at 04:26:04PM -0700, José Roberto de Souza wrote:
> Cursors don't have a framebuffer so the fb comparisson was always
> failing and atomic state was being committed without any plane state.
>
> So here checking if objects match when checking cursors.
This looks extremely back
On Tue, Aug 17, 2021 at 04:33:57PM -0700, Kees Cook wrote:
> The kernel builds with -Werror=designated-init, and __designated_init
> is used by CONFIG_GCC_PLUGIN_RANDSTRUCT for automatically selected (all
> function pointer) structures. Include the field names in the init/exit
> table. Avoids warni
On Wed, Aug 18, 2021 at 03:38:18PM +0800, Desmond Cheong Zhi Xi wrote:
> There is a window after calling drm_master_release, and before a file
> is freed, where drm_file can have is_master set to true, but both the
> drm_file and drm_device have no master.
>
> This could result in wrongly approvin
On Wed, Aug 18, 2021 at 03:38:17PM +0800, Desmond Cheong Zhi Xi wrote:
> When drm_file.master changes value, the corresponding
> drm_device.master_lookup_lock should be held.
>
> In drm_master_release, a call to drm_master_put sets the
> file_priv->master to NULL, so we protect this section with
>
On Wed, 18 Aug 2021 at 11:50, Viresh Kumar wrote:
>
> On 18-08-21, 11:41, Ulf Hansson wrote:
> > On Wed, 18 Aug 2021 at 11:14, Viresh Kumar wrote:
> > > What we need here is just configure. So something like this then:
> > >
> > > - genpd->get_performance_state()
> > > -> dev_pm_opp_get_current
On Wed, Aug 18, 2021 at 03:38:19PM +0800, Desmond Cheong Zhi Xi wrote:
> There are three areas where we dereference struct drm_master without
> checking if the pointer is non-NULL.
>
> 1. drm_getmagic is called from the ioctl_handler. Since
> DRM_IOCTL_GET_MAGIC has no ioctl flags, drm_getmagic is
From: Rajeev Nandan
Add DSI controller and PHY nodes for sc7280.
Signed-off-by: Rajeev Nandan
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 101 +++
1 file changed, 101 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7
Add mdss and mdp DT nodes for sc7280.
Signed-off-by: Krishna Manikandan
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 85
1 file changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 53a21d0..f
MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI, EDP etc. Add required DPU
device tree bindings for SC7280.
Signed-off-by: Krishna Manikandan
---
.../bindings/display/msm/dpu-sc7280.yaml | 228 +
1 file changed, 228 inser
From: Sankeerth Billakanti
Add edp controller and phy DT nodes for sc7280.
Signed-off-by: Sankeerth Billakanti
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 127 ++-
1 file changed, 126 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
On Wed, Aug 18, 2021 at 03:38:20PM +0800, Desmond Cheong Zhi Xi wrote:
> Currently, drm_device.master_mutex is used to serialize writes to the
> drm_master.magic_map idr and to protect drm_master.unique{_len}.
>
> In preparation for converting drm_device.master_mutex into an outer
> rwsem that mig
Only the DRM GPU scheduler, radeon and amdgpu where using them and they depend
on a non existing config option to actually emit some code.
v2: keep the signal path as is for now
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 10 +-
drivers/gpu/drm/radeon/
As we now knew allowing userspace control over dma_fence synchronization
is fundamentally broken and can cause deadlocks inside the kernel memory
management.
Because of this harden the wording for CONFIG_SW_SYNC and taint the kernel
as soon as it is used.
Signed-off-by: Christian König
---
driv
On Wed, Aug 18, 2021 at 03:38:22PM +0800, Desmond Cheong Zhi Xi wrote:
> In a future patch, a read lock on drm_device.master_rwsem is
> held in the ioctl handler before the check for ioctl
> permissions. However, this produces the following lockdep splat:
>
> ==
On Wed, Aug 18, 2021 at 03:38:23PM +0800, Desmond Cheong Zhi Xi wrote:
> The task_work_add function is needed to prevent userspace races with
> DRM modesetting rights.
>
> Some DRM ioctls can change modesetting permissions while other
> concurrent users are performing modesetting. To prevent races
On Sat, Aug 14, 2021 at 02:46:27PM +0200, Heiko Carstens wrote:
> Hello,
>
> I have Fedora 33 running, and with the Fedore kernel update from 5.11
> series to 5.12 my external monitor was not detected anymore. Same is
> true with the Fedora supplied 5.13 kernel version.
>
> So I tried with vanill
Just a gentle ping?
Does anybody have any objections? It's just switching back to using a
spinlock in the hot path instead of a mutex.
Thanks,
Christian.
Am 22.07.21 um 13:34 schrieb Christian König:
Switch back to using a spinlock again by moving the IOMMU unmap outside
of the locked region
On Tue, Aug 17, 2021 at 11:04:43PM -0700, Kees Cook wrote:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memcpy(), memmove(), and memset(), avoid
> intentionally writing across neighboring fields.
>
> Use struct_group() in struct ivhd_entry ar
On 8/18/2021 11:34 AM, Kees Cook wrote:
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
Use struct_group() in structs:
struct atom_smc_dpm_info_v4_
On Mon, 16 Aug 2021 at 18:14, Thomas Hellström
wrote:
>
> It's only used by the for_i915_gem_ww() macro and we can use
> the (typically) on-stack _err variable in its place.
>
> v2:
> - Don't clear the _err variable when entering the loop
> (Matthew Auld, Maarten Lankhorst).
> - Use parentheses
Commit 6104c37094e7 ("fbcon: Make fbcon a built-time depency for fbdev")
changed the FRAMEBUFFER_CONSOLE Kconfig symbol from tristate to bool.
But the drm_kms_helper_init() function still attempts to load the fbcon
module, even when this is always built-in since the mentioned change.
Signed-off-b
To be honest I think the if(WARN_ON(!dmabuf)) return -EINVAL handling
here is misleading in the first place.
Returning -EINVAL on a hard coding error is not good practice and should
probably be removed from the DMA-buf subsystem in general.
Christian.
Am 18.08.21 um 13:58 schrieb Nuno Sá:
O
Am 18.08.21 um 14:17 schrieb Sa, Nuno:
From: Christian König
Sent: Wednesday, August 18, 2021 2:10 PM
To: Sa, Nuno ; linaro-mm-...@lists.linaro.org;
dri-devel@lists.freedesktop.org; linux-me...@vger.kernel.org
Cc: Rob Clark ; Sumit Semwal
Subject: Re: [PATCH] dma-buf: return -EINVAL if dmabuf o
On Wed, Aug 18, 2021 at 01:27:13PM +0200, Christian König wrote:
> Just a gentle ping?
>
> Does anybody have any objections? It's just switching back to using a
> spinlock in the hot path instead of a mutex.
>
> Thanks,
> Christian.
>
> Am 22.07.21 um 13:34 schrieb Christian König:
> > Switch ba
On Wed, Aug 18, 2021 at 02:09:48PM +0200, Javier Martinez Canillas wrote:
> Commit 6104c37094e7 ("fbcon: Make fbcon a built-time depency for fbdev")
> changed the FRAMEBUFFER_CONSOLE Kconfig symbol from tristate to bool.
>
> But the drm_kms_helper_init() function still attempts to load the fbcon
>
Dear DRM maintainers,
The script ./scripts/checkkconfigsymbols.py warns on invalid references to
Kconfig symbols (often, minor typos, name confusions or outdated references).
This patch series addresses all issues reported by
./scripts/checkkconfigsymbols.py
in ./drivers/gpu/ for Kconfig and Mak
commit 1f0f01515172 ("drm/rockchip: Add support for Rockchip Soc RGB
output interface") accidently adds to select the non-existing config
DRM_RGB in ./drivers/gpu/drm/rockchip/Kconfig.
Luckily, ./scripts/checkkconfigsymbols.py warns on non-existing configs:
DRM_RGB
Referencing files: drivers/gpu/
Commit 04ed8459f334 ("drm/amdgpu: remove chash") removes the chash
architecture and its corresponding config CHASH.
There is still a reference to CHASH in the config DRM_AMDGPU in
./drivers/gpu/drm/Kconfig.
Remove this obsolete reference to config CHASH.
Signed-off-by: Lukas Bulwahn
---
driver
Commit 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D
V3.x+") adds the config DRM_V3D, which depends on "ARCH_BCMSTB".
Although, a bit confusing: all Broadcom architectures in
./arch/arm/mach-bcm/Kconfig have the prefix "ARCH_BCM", except for
ARCH_BRCMSTB, i.e., the config for
Commit 89d4f98ae90d ("ARM: remove zte zx platform") removes the config
ARCH_ZX. So, since then, the DRM Support for ZTE SoCs (config DRM_ZTE)
depends on this removed config ARCH_ZX and cannot be selected.
Fortunately, ./scripts/checkkconfigsymbols.py detects this and warns:
ARCH_ZX
Referencing fi
Commit 55b68fb856b5 ("drm/omap: squash omapdrm sub-modules into one")
removes the config OMAP2_DSS in ./drivers/gpu/drm/omapdrm/dss/Kconfig,
while moving the other configs into./drivers/gpu/drm/omapdrm/Kconfig, but
misses to remove an obsolete selection of OMAP2_DSS in config DRM_OMAP.
Hence, ./sc
Hi Rob, Sam,
On Wed, Jul 21, 2021 at 08:29:47PM -0600, Rob Herring wrote:
> On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
> > The binding mentions that all the drivers using that driver must use a
> > vendor-specific compatible but never enforces it, nor documents the
> > vendor-s
On Wed, Aug 18, 2021 at 02:31:34PM +0200, Christian König wrote:
> Am 18.08.21 um 14:17 schrieb Sa, Nuno:
> > > From: Christian König
> > > Sent: Wednesday, August 18, 2021 2:10 PM
> > > To: Sa, Nuno ; linaro-mm-...@lists.linaro.org;
> > > dri-devel@lists.freedesktop.org; linux-me...@vger.kernel.o
Am 18.08.21 um 14:46 schrieb Daniel Vetter:
On Wed, Aug 18, 2021 at 02:31:34PM +0200, Christian König wrote:
Am 18.08.21 um 14:17 schrieb Sa, Nuno:
From: Christian König
Sent: Wednesday, August 18, 2021 2:10 PM
To: Sa, Nuno ; linaro-mm-...@lists.linaro.org;
dri-devel@lists.freedesktop.org; lin
Am 18.08.21 um 14:32 schrieb Daniel Vetter:
On Wed, Aug 18, 2021 at 01:27:13PM +0200, Christian König wrote:
Just a gentle ping?
Does anybody have any objections? It's just switching back to using a
spinlock in the hot path instead of a mutex.
Thanks,
Christian.
Am 22.07.21 um 13:34 schrieb C
On Wed, Aug 18, 2021 at 11:24:28AM +0300, Mikko Perttunen wrote:
> On 8/18/21 12:20 AM, Rob Herring wrote:
> > On Wed, Aug 11, 2021 at 01:50:28PM +0300, Mikko Perttunen wrote:
> > > Add YAML device tree bindings for NVDEC, now in a more appropriate
> > > place compared to the old textual Host1x bin
Am 18.08.21 um 15:02 schrieb Wentao_Liang:
In line 317 (#1), drm_gem_prime_import() is called, it will call
drm_gem_prime_import_dev(). At the end of the function
drm_gem_prime_import_dev() (line 956, #2), "dma_buf_put(dma_buf);" puts
dma_buf->file and may cause it to be released. However, after
Am 18.08.21 um 15:13 schrieb Sa, Nuno:
From: Christian König
Sent: Wednesday, August 18, 2021 2:58 PM
To: Daniel Vetter
Cc: Sa, Nuno ; linaro-mm-...@lists.linaro.org;
dri-devel@lists.freedesktop.org; linux-me...@vger.kernel.org; Rob
Clark
Subject: Re: [Linaro-mm-sig] [PATCH] dma-buf: return -E
On Tue, 17 Aug 2021 23:05:20 -0700
Kees Cook wrote:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memset(), avoid intentionally writing across
> neighboring fields.
>
> Use memset_startat() to avoid confusing memset() about writing beyond
>
On Wed, Aug 18, 2021 at 7:43 AM Maxime Ripard wrote:
>
> Hi Rob, Sam,
>
> On Wed, Jul 21, 2021 at 08:29:47PM -0600, Rob Herring wrote:
> > On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
> > > The binding mentions that all the drivers using that driver must use a
> > > vendor-specif
On Wed, Aug 18, 2021 at 04:44:30AM +0300, Dmitry Osipenko wrote:
> 18.08.2021 04:15, Rob Herring пишет:
> >> + tegra-clocks:
> >> +description: child nodes are the output clocks from the CAR
> >> +type: object
> >> +
> >> +patternProperties:
> >> + "^[a-z]+[0-9]+$":
> >> +
On Tue, Aug 17, 2021 at 04:27:26AM +0300, Dmitry Osipenko wrote:
> Document tegra-clocks sub-node which describes Tegra SoC clocks that
> require a higher voltage of the core power domain in order to operate
> properly on a higher clock rates. Each node contains a phandle to OPP
> table and power
+ dri-devel
Since scheduler is a shared component, please add dri-devel on all
scheduler patches.
On Wed, Aug 18, 2021 at 7:21 AM Jingwen Chen wrote:
>
> [Why]
> for bailing job, this commit will delete it from pending list thus the
> bailing job will never have a chance to be resubmitted even i
On Tue, Aug 17, 2021 at 04:27:27AM +0300, Dmitry Osipenko wrote:
[...]
> +struct clk *tegra_clk_register(struct clk_hw *hw)
> +{
> + struct platform_device *pdev;
> + struct device *dev = NULL;
> + struct device_node *np;
> + const char *dev_name;
> +
> + np = tegra_clk_get_of_n
On Wed, Aug 18, 2021 at 03:25:59PM +0200, Christian König wrote:
> Am 18.08.21 um 15:02 schrieb Wentao_Liang:
> > In line 317 (#1), drm_gem_prime_import() is called, it will call
> > drm_gem_prime_import_dev(). At the end of the function
> > drm_gem_prime_import_dev() (line 956, #2), "dma_buf_put(d
+danvet
Hi,
On Tue, 10 Aug 2021 at 23:58, Yunfei Dong wrote:
>
> This series adds support for multi hardware decode into mtk-vcodec, by first
> adding component framework to manage each hardware information: interrupt,
> clock, register bases and power. Secondly add core thread to deal with core
On Thu, Jul 01, 2021 at 05:55:11PM +0200, Michal Wajdeczko wrote:
> Instead of plain error value (%d) print more user friendly error
> name (%pe).
>
> Signed-off-by: Michal Wajdeczko
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
On Thu, Jul 01, 2021 at 05:55:10PM +0200, Michal Wajdeczko wrote:
> In commit b839a869dfc9 ("drm/i915/guc: Add support for data
> reporting in GuC responses") we missed the hypothetical case
> that GuC might return positive non-zero value as success data.
>
> While that would be lucky treated as e
On Thu, Jul 01, 2021 at 05:55:12PM +0200, Michal Wajdeczko wrote:
> Instead of plain error value (%d) print more user friendly error
> name (%pe).
>
> Signed-off-by: Michal Wajdeczko
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
On Thu, Jul 01, 2021 at 05:55:13PM +0200, Michal Wajdeczko wrote:
> If we timeout waiting for a CT reply we print very simple error
> message. Improve that and by moving error reporting to the caller
> we can use CT_ERROR instead of DRM_ERROR and report just fence
> as error code will be reported l
On 2021-08-18 10:02 a.m., Alex Deucher wrote:
+ dri-devel
Since scheduler is a shared component, please add dri-devel on all
scheduler patches.
On Wed, Aug 18, 2021 at 7:21 AM Jingwen Chen wrote:
[Why]
for bailing job, this commit will delete it from pending list thus the
bailing job will ne
On Wed, Aug 18, 2021 at 10:02:06AM -0400, Alex Deucher wrote:
> + dri-devel
>
> Since scheduler is a shared component, please add dri-devel on all
> scheduler patches.
Do we need a MAINTAINRS entry specifically for this, or just oversight?
> On Wed, Aug 18, 2021 at 7:21 AM Jingwen Chen wrote:
>
On Wed, Aug 18, 2021 at 10:26:25AM -0400, Andrey Grodzovsky wrote:
> On 2021-08-18 10:02 a.m., Alex Deucher wrote:
>
> > + dri-devel
> >
> > Since scheduler is a shared component, please add dri-devel on all
> > scheduler patches.
> >
> > On Wed, Aug 18, 2021 at 7:21 AM Jingwen Chen wrote:
> >
On 2021-08-18 10:32 a.m., Daniel Vetter wrote:
On Wed, Aug 18, 2021 at 10:26:25AM -0400, Andrey Grodzovsky wrote:
On 2021-08-18 10:02 a.m., Alex Deucher wrote:
+ dri-devel
Since scheduler is a shared component, please add dri-devel on all
scheduler patches.
On Wed, Aug 18, 2021 at 7:21 AM
1 - 100 of 233 matches
Mail list logo
