On 24/11/2022 01:16, Adam Skladowski wrote:
> Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm
> SM6115 platform.
> Configuration for DSI/PHY is shared with QCM2290 so compatibles are reused.
> Lack of dsi phy supply in example is intended
> due to fact on qcm2290, sm6115 an
On Fri, 25 Nov 2022, Xia Fukun wrote:
> When (size != 0 || ptrs->lvds_ entries != 3), the program tries to
> free() the ptrs. However, the ptrs is not created by calling kzmalloc(),
> but is obtained by pointer offset operation.
> This may lead to memory leaks or undefined behavior.
Yeah probably
When (size != 0 || ptrs->lvds_ entries != 3), the program tries to
free() the ptrs. However, the ptrs is not created by calling kzmalloc(),
but is obtained by pointer offset operation.
This may lead to memory leaks or undefined behavior.
Fix this by replacing the arguments of kfree() with ptrs_blo
On 11/23/22 16:25, Maxime Ripard wrote:
> The name doesn't really fit the conventions for the other helpers in
> DRM/KMS, so let's rename it to make it obvious that we allocate a new
> DRM device.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
J
On 11/23/22 16:25, Maxime Ripard wrote:
> The device name isn't really useful, we can just define it instead of
> exposing it in the API.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/tests/drm_client_modeset_test.c | 2 +-
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 6 --
On 11/23/22 16:25, Maxime Ripard wrote:
> We'll need in some tests to control when the device needs to be added
> and removed, so let's split the device creation from the DRM device
> creation function.
>
> Signed-off-by: Maxime Ripard
> ---
[...]
> -static int dev_init(struct kunit_resource *r
On 25/11/2022 07:45, Abhinav Kumar wrote:
On 11/24/2022 4:02 PM, Dmitry Baryshkov wrote:
Since the commit commit c6122688f265 ("drm/msm/mdp5: stop overriding
drvdata") reading the MDP5 hw revision on db410c will crash the board
as the MDSS_GDSC is not enabled. Revert a part of the offending comm
On 11/23/22 16:25, Maxime Ripard wrote:
> The device managed resources are ran if the device has bus, which is not
> the case of a root_device.
>
> Let's use a platform_device instead.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 19 +--
>
bw_calcs() presently blows the stack-frame limit by calling functions
inside a argument list which return quite a bit of data to be passed
onto sub-functions. Simply breaking out this hunk reduces the
stack-frame use by 500 Bytes, preventing the following compiler
warning:
drivers/gpu/drm/amd
Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST") WERROR
now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
builds. This leads to some interesting failures, each resolved in this set.
With this set applied, I am able to obtain a successful allmodconfig A
When enabled, KASAN enlarges function's stack-frames. Pushing quite a
few over the current threshold. This can mainly be seen on 32-bit
architectures where the present limit (when !GCC) is a lowly
1024-Bytes.
Signed-off-by: Lee Jones
---
lib/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64)
architectures built with Clang (all released versions), whereby the stack
frame gets blown up to well over 5k. This would cause an immediate kernel
panic on most architectures. We'll revert this when the following bug
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote:
> When enabled, KASAN enlarges function's stack-frames. Pushing quite a
> few over the current threshold. This can mainly be seen on 32-bit
> architectures where the present limit (when !GCC) is a lowly
> 1024-Bytes.
>
> Signed-off-by: Lee Jones
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote:
> calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64)
> architectures built with Clang (all released versions), whereby the stack
> frame gets blown up to well over 5k. This would cause an immediate kernel
> panic on most
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote:
> bw_calcs() presently blows the stack-frame limit by calling functions
> inside a argument list which return quite a bit of data to be passed
> onto sub-functions. Simply breaking out this hunk reduces the
> stack-frame use by 500 Bytes, preventing
On 11/23/22 16:25, Maxime Ripard wrote:
> The device managed resources are freed when the device is detached, so
> it has to be bound in the first place.
>
> Let's create a fake driver that we will bind to our fake device to
> benefit from the device managed cleanups in our tests.
>
> Signed-off-
Those functions never worked correctly since it is still perfectly
possible that a buffer object is released and the background worker
restarted even after calling them.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_
We already fallback to a dummy BO with no backing store when we
allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
Drop all those workarounds and generalize this for GTT as well. This
fixes ENOMEM issues with runaway applications which try to allocate/free
GTT in a loop and are ot
Instead of a single worker going over the list of delete BOs in regular
intervals use a per BO worker which blocks for the resv object and
locking of the BO.
This not only simplifies the handling massively, but also results in
much better response time when cleaning up buffers.
Signed-off-by: Chr
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers
Merge and cleanup the two headers into a single description of the
object API. Also move all the documentation to the implementation and
drop unecessary includes from the header.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +-
...
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 11 ---
2 files changed, 13 insertions(+), 4 deletions(-)
diff --gi
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_cmd.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl
Make sure that we use the correct settings from the context.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f9d9fd2d865d..cd266a067773 100644
Not used anymore by other drivers or TTM itself.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 44 +++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 19 -
drivers/gpu/drm/vmwgfx/ttm_object.h | 11
include/drm/ttm/ttm_bo.h
Since the dma_alloc_coherent() may return NULL,
the pointer returned needs to be checked to avoid
null-poineter dereference.
Fixes: 46f226c93d35 ("drm/tegra: Add NVDEC driver")
Signed-off-by: Zeng Heng
---
drivers/gpu/drm/tegra/nvdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/driver
On 11/23/22 16:25, Maxime Ripard wrote:
> The current helper to allocate a DRM device doesn't allow for any
> subclassing by drivers, which is going to be troublesome as we work on
> getting some kunit testing on atomic modesetting code.
>
> Let's use a similar pattern to the other allocation help
On 11/23/22 16:25, Maxime Ripard wrote:
> Some tests will need to provide their own drm_driver instead of relying
> on the dumb one in the helpers, so let's create a helper that allows to
> do so.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Ja
On 11/23/22 16:25, Maxime Ripard wrote:
> DRM-managed actions are supposed to be ran whenever the device is
> released. Let's introduce a basic unit test to make sure it happens.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/tests/Makefile | 1 +
> drivers/gpu/drm/tests/drm
On 11/23/22 16:25, Maxime Ripard wrote:
> The drm_atomic_get_(old|new)_*_state don't modify the passed
> drm_atomic_state, so we can make it const.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 11/23/22 16:25, Maxime Ripard wrote:
> On the vc4 devices (and later), the blending is done by a single device
> called the HVS. The HVS has three FIFO that can operate in parallel, and
> route their output to 6 CRTCs and 7 encoders on the BCM2711.
>
> Each of these CRTCs and encoders have some
On 11/23/22 16:25, Maxime Ripard wrote:
> None of our wrappers around container_of to access our objects from the
> DRM object pointer actually modify the latter.
>
> Let's make them const.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier
On 11/23/22 16:25, Maxime Ripard wrote:
> In order to introduce unit tests for the HVS state computation, we'll
> need access to the vc4_hvs_state struct definition and its associated
> helpers.
>
> Let's move them in our driver header.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier
On 11/23/22 16:25, Maxime Ripard wrote:
> The vc4_hvs_get_(old|new)_global_state functions don't modify the
> drm_atomic_state passed as an argument, so let's make it const.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
On 11/23/22 16:25, Maxime Ripard wrote:
> The current order of variable assignments is unneccessarily complex,
> let's make it simpler.
>
> Signed-off-by: Maxime Ripard
> ---
Much easier to follow indeed.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Pl
On 11/23/22 16:25, Maxime Ripard wrote:
> The TXP is integrated as a separate CRTC/Encoder/Connector combo, but
> for some reason doesn't rely on the vc4_encoder type and it's associated
> type.
>
> Let's create a type to make it consistent with the other encoders.
>
> Signed-off-by: Maxime Ripar
On 11/23/22 16:25, Maxime Ripard wrote:
> It makes more sense to register the CRTC before the encoder and
> connectors, so let's move our call around.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 11/23/22 16:25, Maxime Ripard wrote:
> Both users of vc4_crtc_init need the same extra initialization to set
> the pointer to the platform_device and the CRTC data. Since it's
> mandatory, let's make them both arguments of vc4_crtc_init().
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: J
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
Hi,
This series adds support for the Verisilicon VIPNano-QI NPU in the A311D
as in the VIM3 board.
The IP is very closeley based on previous Vivante GPUs, so the etnaviv
driver works basically unchanged.
Regards,
Tomeu
Tomeu Vizoso (6):
dt-bindings: reset: meson-g12a: Add missing NNA reset
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas downstream kernel driver
6.4.4.3.310723AAA.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
On 11/25/2022 1:21 AM, Dmitry Baryshkov wrote:
On 25/11/2022 07:45, Abhinav Kumar wrote:
On 11/24/2022 4:02 PM, Dmitry Baryshkov wrote:
Since the commit commit c6122688f265 ("drm/msm/mdp5: stop overriding
drvdata") reading the MDP5 hw revision on db410c will crash the board
as the MDSS_GDSC
The IPUv3 and DCSS driver are two totally separate DRM drivers. Having
one of them live in the drivers/gpu/drm/imx toplevel directory and the
other one in the dcss/ subdirectory is confusing. Move the IPUv3 driver
into its own subdirectory to make the separation more clear.
Signed-off-by: Lucas St
On 11/23/22 16:26, Maxime Ripard wrote:
> The current vc4_crtc_init() helper assumes that we will be using
> hardware planes and calls vc4_plane_init().
>
> While it's a reasonable assumption, we'll want to mock the plane and
> thus provide our own. Let's create a helper that will take the plane a
On 11/23/22 16:26, Maxime Ripard wrote:
> We'll need a function that looks up an encoder by its vc4_encoder_type.
> Such a function is already present in the CRTC code, so let's make it
> public so that we can reuse it in the unit tests.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier
On 11/23/22 16:26, Maxime Ripard wrote:
> It's fairly hard to figure out the instance of the CRTC affected by an
> atomic change using the default name.
>
> Since we can provide our own to the CRTC initialization functions, let's
> do so to make the debugging sessions easier.
>
> Signed-off-by: M
On 11/23/22 16:26, Maxime Ripard wrote:
> We'll need to initialize the HVS structure without a backing device to
> create a mock we'll use for testing.
>
> Split the structure initialization part into a separate function.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canil
Em Wed, 23 Nov 2022 13:25:20 +0100
Greg Kroah-Hartman escreveu:
> The devnode() in struct class should not be modifying the device that is
> passed into it, so mark it as a const * and propagate the function
> signature changes out into all relevant subsystems that use this
> callback.
Acked-by:
Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST") WERROR
now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
builds. This leads to some interesting failures, each resolved in this set.
calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64)
architectures built with Clang (all released versions), whereby the stack
frame gets blown up to well over 5k. This would cause an immediate kernel
panic on most architectures. We'll revert this when the following bug
When enabled, KASAN enlarges function's stack-frames. Pushing quite a
few over the current threshold. This can mainly be seen on 32-bit
architectures where the present limit (when !GCC) is a lowly
1024-Bytes.
Signed-off-by: Lee Jones
---
lib/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
On Fri, Nov 25, 2022, at 13:07, Lee Jones wrote:
> calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64)
> architectures built with Clang (all released versions), whereby the stack
> frame gets blown up to well over 5k. This would cause an immediate kernel
> panic on most
On Fri, Nov 25, 2022 at 05:44:11PM +0800, Jiaxin Yu wrote:
> + /*
> + * PCM trigger callback.
> + * Mandatory
> + */
> + int (*trigger)(struct device *dev, int cmd);
> +
Making this mandatory would break all existing users, though...
> + switch (event) {
> + case S
On Wed, 05 Oct 2022, Jani Nikula wrote:
> Currently i915 assumes all drm_connectors it encounters are embedded in
> intel_connectors that i915 allocated. The drm_writeback_connector forces
> a design where this is not the case; we can't provide our own connector,
> and writeback embeds the drm_con
V4:
- Moves the update of the example from patch #5 to patch #4
V3:
- Moves declaration of mdss-dsi-ctrl into compat string declaration
patch - Krzysztof, Dmitry
- Renames qcm-2290 compat string to agreed compat "qcom,socname-dsi-ctrl"
Dmirty, Krzysztof
- Adds empty line after if clause in yam
Add silicon specific compatible qcom,sdm660-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm660 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 d
We will add in a number of compat strings to dsi-controller-main.yaml in
the format "qcom,socname-dsi-ctrl" convert the currently unused
qcom,dsi-ctrl-6g-qcm2290 to qcom,qcm2290-dsi-ctrl.
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 +-
Append silicon specific compatible qcom,apq8064-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for apq8064 against the yaml documentation.
Reviewed-by: David Heidelberg
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 3 ++-
1
The existing msm8916.dtsi does not depend on nor require operating points.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/display/msm/dsi-co
Add silicon specific compatible qcom,msm8996-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8996 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 --
1 file changed, 4 insertions(+
power-domain is required for the sc7180 dispcc GDSC but not every qcom SoC
has a similar dependency for example the aqp8064.
Most Qcom SoC's using mdss-dsi-ctrl seem to have the ability to
power-collapse the MDP without collapsing DSI.
For example the qcom vendor kernel commit for apq8084, msm822
Currently we do not differentiate between the various users of the
qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
compatible string but, the hardware does have some significant differences
in the number of clocks.
To facilitate documenting the clocks add the following compat
When converting from .txt to .yaml dt-binding descriptions we appear to
have missed some of the previous detail on the number and names of
permissible clocks.
Fix this by listing the clock descriptions against the clock names at a
high level.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml
There's a typo in describing the core clock as an 'escape' clock. The
accurate description is 'core'.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/
Add silicon specific compatible qcom,sc7280-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7280 against the yaml documentation.
Reviewed-by: Douglas Anderson
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 ++-
1 fil
Add silicon specific compatible qcom,sdm630-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm630 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 d
Each compatible has a different set of clocks which are associated with it.
Add in the list of clocks for each compatible.
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 152 --
1 file changed, 142 insertions(+), 10 deletions(-)
diff --git
a
When converting from .txt to .yaml we didn't include descriptions for the
existing regulator supplies.
- vdd
- vdda
- vddio
Add those descriptions into the yaml now as they were prior to the
conversion. In the .txt description we marked these regulators as required,
however, that requirement appe
Add silicon specific compatible qcom,sc7180-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7180 against the yaml documentation.
Reviewed-by: Douglas Anderson
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 ++-
1 fil
Add silicon specific compatible qcom,msm8916-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8916 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 ++-
1 file changed, 2 insertions(+),
Add silicon specific compatible qcom,msm8974-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8974 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1
Add silicon specific compatible qcom,sm8250-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sm8250 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 --
1 file changed, 4 insertions(+),
Add silicon specific compatible qcom,sdm845-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm845 against the yaml documentation.
Reviewed-by: Douglas Anderson
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 --
1
Hello Greg,
On Fri, 25 Nov 2022 at 17:25, Mauro Carvalho Chehab wrote:
>
> Em Wed, 23 Nov 2022 13:25:20 +0100
> Greg Kroah-Hartman escreveu:
>
> > The devnode() in struct class should not be modifying the device that is
> > passed into it, so mark it as a const * and propagate the function
> > s
Am 25.11.22 um 12:14 schrieb Tvrtko Ursulin:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file ch
On Fri, 25 Nov 2022, Lee Jones wrote:
> When enabled, KASAN enlarges function's stack-frames. Pushing quite a
> few over the current threshold. This can mainly be seen on 32-bit
> architectures where the present limit (when !GCC) is a lowly
> 1024-Bytes.
>
> Signed-off-by: Lee Jones
> ---
> l
On Thu, Nov 10, 2022 at 04:56:51PM -0800, Daniele Ceraolo Spurio wrote:
> The fence is always initialized in huc_init_early, but the cleanup in
> huc_fini is only being run if HuC is enabled. This causes a leaking of
> the debug object when HuC is disabled/not supported, which can in turn
> trigger
On Fri, Nov 25, 2022, at 14:40, Lee Jones wrote:
> On Fri, 25 Nov 2022, Lee Jones wrote:
>
>> When enabled, KASAN enlarges function's stack-frames. Pushing quite a
>> few over the current threshold. This can mainly be seen on 32-bit
>> architectures where the present limit (when !GCC) is a lowly
On 11/23/22 12:25, Maxime Ripard wrote:
The name doesn't really fit the conventions for the other helpers in
DRM/KMS, so let's rename it to make it obvious that we allocate a new
DRM device.
Signed-off-by: Maxime Ripard
Although I believe using "drm_device" on the function name is a bit
redu
On Thu, Nov 24, 2022 at 09:02:19AM +0800, Gaosheng Cui wrote:
> The dma_free_coherent() should be called when memory fails to
> be allocated for list, or drm_map_handle() fails, otherwise there
> will be a memory leak, so add dma_free_coherent to fix it.
>
> In addition, if drm_map_handle() fails
Hi,
On Fri, Nov 25, 2022 at 11:10:02AM -0300, Maíra Canal wrote:
> On 11/23/22 12:25, Maxime Ripard wrote:
> > The name doesn't really fit the conventions for the other helpers in
> > DRM/KMS, so let's rename it to make it obvious that we allocate a new
> > DRM device.
> >
> > Signed-off-by: Maxi
On 10/5/22 06:51, Jani Nikula wrote:
> Currently i915 assumes all drm_connectors it encounters are embedded in
> intel_connectors that i915 allocated. The drm_writeback_connector forces
> a design where this is not the case; we can't provide our own connector,
> and writeback embeds the drm_connect
Hi Dave, Daniel,
The following changes since commit c2418f911a31a266af4fbaca998dc73d3676475a:
gpu: host1x: Avoid trying to use GART on Tegra20 (2022-11-18 09:33:20 +0100)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/tegra.git tags/drm/tegra/for-6.2-rc1
for you
On Wed, Nov 23, 2022 at 10:15:25AM +0100, AngeloGioacchino Del Regno wrote:
> Il 22/11/22 15:39, Nícolas F. R. A. Prado ha scritto:
> > mtk_drm_bind() can fail, in which case drm_dev_put() is called,
> > destroying the drm_device object. However a pointer to it was still
> > being held in the priva
Le mercredi 23 novembre 2022 à 17:33 +0100, Daniel Vetter a écrit :
> On Wed, Nov 23, 2022 at 10:33:38AM +0200, Pekka Paalanen wrote:
> > On Tue, 22 Nov 2022 18:33:59 +0100
> > Christian König wrote:
> >
> > > We should have come up with dma-heaps earlier and make it clear that
> > > exporting a
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 9e46a79967326efb03c481ddfd58902475bd920d Add linux-next specific
files for 20221125
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com
https
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> The helper drm_gem_simple_display_pipe_prepare_fb() is simple-KMS'
> default implementation for prepare_fb. Remove the call from drivers
> that set it explicitly. Then inline the helper into the only caller
> within simple-kms helpers and remove .
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> MIPI DBI drivers validate each mode against their native resolution.
> Add this test to ili9225.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> MIPI DBI drivers validate each mode against their native resolution.
> Add this test to st7586.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Introduce DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS to initialize MIPI-DBI
> helpers to default values and convert drivers. The prepare_fb function
> set by some drivers is called implicitly by simple-kms helpers, so leave
> it out.
>
> Signed-off-b
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Move the vmap/vunmap blocks from the inner fb_dirty helpers into the
> MIPI DBI update helpers. The function calls can result in waiting and/or
> processing overhead. Reduce the penalties by executing the functions once
> in the outer-most functio
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Introduce struct drm_mipi_dbi_plane_state that contains state related to
> MIPI DBI. It currently only inherits from struct drm_shadow_plane_state,
> so that MIPI DBI drivers can use the vmap'ed GEM-buffer memory. Implement
> state helpers, the {b
This patchset adds a udev event for DRM device's resets.
Userspace apps can trigger GPU resets by misuse of graphical APIs or driver
bugs. Either way, the GPU reset might lead the system to a broken state[1], that
might be recovered if user has access to a tty or a remote shell. Arguably, this
rec
From: Shashank Sharma
Add a sysfs event to notify userspace about GPU resets providing:
- PID that triggered the GPU reset, if any. Resets can happen from
kernel threads as well, in that case no PID is provided
- Information about the reset (e.g. was VRAM lost?)
Co-developed-by: André Almeida
Add a work function to send a GPU reset uevent and scheduled it during
a GPU reset.
Co-developed-by: Shashank Sharma
Signed-off-by: Shashank Sharma
Signed-off-by: André Almeida
---
V3:
- Merge two last commits
V2: Addressed review comments from Christian
- Changed the name of the work to
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Call drm_dev_enter() and drm_dev_exit() in the outer-most callbacks
> of the modesetting pipeline. If drm_dev_enter() fails, the driver can
> thus avoid unnecessary work.
>
> Signed-off-by: Thomas Zimmermann
> ---
Makes sense in order to make t
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
> drivers vmap/vunmap GEM buffer memory during the atomic commit.
> Shadow-plane helpers automate this process.
>
> Patches 1 to 4 prepare the MIPI code for the change and simplify
>
Hi Dave, Daniel,
More stuff for 6.2. Mostly bug fixes at this point.
The following changes since commit 3d335a523b938a445a674be24d1dd5c7a4c86fb6:
Merge tag 'drm-intel-next-2022-11-18' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-11-23 09:15:44
+1000)
are available in
On Fri, Nov 25, 2022 at 5:21 AM Christian König
wrote:
>
> We already fallback to a dummy BO with no backing store when we
> allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
>
> Drop all those workarounds and generalize this for GTT as well. This
> fixes ENOMEM issues with runaw
The pull request you sent on Fri, 25 Nov 2022 13:47:02 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-11-25
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6fe0e074e76985c7be3eaa7a8fd51401a8999cae
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
1 - 100 of 123 matches
Mail list logo
