On 15/01/2024 17:51, Raphael Gallais-Pou wrote:
>
> On 1/15/24 16:46, Rob Herring wrote:
>> On Mon, Jan 15, 2024 at 02:20:04PM +0100, Raphael Gallais-Pou wrote:
>>> Add "st,stm32mp25-lvds" compatible.
>>>
A nit, subject: drop second/last, redundant "dt-bindings for". The
"dt-bindings" prefix is
Include instead of to fix
below compilation errors:
drivers/gpu/drm/panel/panel-novatek-nt36672e.c:564:14: error: implicit
declaration of function 'of_device_get_match_data'
ctx->desc = of_device_get_match_data(dev);
^
drivers/gpu/drm/panel/panel-novatek-nt36672e.c:622:34:
AMD GPUs can do async flips with overlay planes and other props rather
than just FB ID, so implement a custom check_async_props for AMD planes.
Signed-off-by: André Almeida
---
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 30 +++
1 file changed, 30 insertions(+)
diff --git
Hi,
AMD hardware can do more on the async flip path than just the primary plane, so
to lift up the current restrictions, this patchset allows drivers to write their
own check for planes for async flips.
I'm not sure if adding something new to drm_plane_funcs is the right way to do,
because if we
Some hardware are more flexible on what they can flip asynchronously, so
rework the plane check so drivers can implement their own check, lifting
up some of the restrictions.
Signed-off-by: André Almeida
---
drivers/gpu/drm/drm_atomic_uapi.c | 62 ++-
> From: Tian, Kevin
> Sent: Tuesday, January 16, 2024 8:46 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, January 16, 2024 12:31 AM
> >
> > On Tue, Jan 09, 2024 at 10:11:23AM +0800, Yan Zhao wrote:
> >
> > > > Well, for instance, when you install pages into the KVM the hypervisor
> > > > will
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4
1 file changed, 4 insertions(+)
diff --git
Thanks for the fix. As the error handling gets longer and duplicated,
could you rearrange them like the lima_gem_submit():
err_out2:
dma_unmap_sgtable(dev, , DMA_BIDIRECTIONAL, 0);
err_out1:
kfree(bo->base.sgt);
bo->base.sgt = NULL;
err_out0:
sg_free_table();
return ret.
> From: Jason Gunthorpe
> Sent: Tuesday, January 16, 2024 12:31 AM
>
> On Tue, Jan 09, 2024 at 10:11:23AM +0800, Yan Zhao wrote:
>
> > > Well, for instance, when you install pages into the KVM the hypervisor
> > > will have taken kernel memory, then zero'd it with cachable writes,
> > > however
Hi Dave, Sima,
Fixes for 6.8. Same PR as Friday, but with new clang warning fixed and
dropped KFD changes at Felix' request.
The following changes since commit e54478fbdad20f2c58d0a4f99d01299ed8e7fe9c:
Merge tag 'amd-drm-next-6.8-2024-01-05' of
https://gitlab.freedesktop.org/agd5f/linux
On 2024-01-15 17:08, Alex Deucher wrote:
Hi Dave, Sima,
Same PR as Friday, but with the new clang warning fixed.
The following changes since commit e54478fbdad20f2c58d0a4f99d01299ed8e7fe9c:
Merge tag 'amd-drm-next-6.8-2024-01-05' of
https://gitlab.freedesktop.org/agd5f/linux into
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: ea489a3d983ba788c64712a55073d2a541e30d44
commit: d3e040f450ec8e46ff42fa495a433b976ab47686 [6/21] drm/rockchip:
inno_hdmi: Get rid of mode_set
config: um-randconfig-r113-20240116
Hi Dave, Sima,
Same PR as Friday, but with the new clang warning fixed.
The following changes since commit e54478fbdad20f2c58d0a4f99d01299ed8e7fe9c:
Merge tag 'amd-drm-next-6.8-2024-01-05' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2024-01-09 09:07:50
+1000)
are available
On 1/13/24 09:58, Christophe JAILLET wrote:
It is likely that the statement related to 'dml_edp' is misplaced. So move
it in the correct "case SIGNAL_TYPE_EDP".
Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2")
Signed-off-by: Christophe JAILLET
Nice catch! Applied, thanks!
---
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Signed-off-by: Uwe Kleine-König
Hello,
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions were renamed. Further some compat defines were introduced
to map the old names to the new ones.
In this series all drivers still using the old names are changed to use
the new ones and then in patch #32
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Signed-off-by: Uwe Kleine-König
I haven't seen any replies to this proposal. Either it got lost in the
pre-holiday noise, or there is genuinely no interest in this.
If it's the latter, I would look for an AMDGPU driver-specific solution
with minimally invasive changes in DRM and DMABuf code, if needed. Maybe
it could be
On Mon, 4 Dec 2023 18:33:00 +0100
Boris Brezillon wrote:
> +static int panthor_gpuva_sm_step_remap(struct drm_gpuva_op *op,
> +void *priv)
> +{
> + struct panthor_vma *unmap_vma = container_of(op->remap.unmap->va,
> struct panthor_vma, base);
> +
-20240115
(https://download.01.org/0day-ci/archive/20240116/202401160108.j5lqkppm-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240116/202401160108.j5lqkppm-...@intel.com/reproduce)
If you fix the issue
On Mon, 4 Dec 2023 18:33:00 +0100
Boris Brezillon wrote:
> +/**
> + * panthor_vm_active() - Flag a VM as active
> + * @VM: VM to flag as active.
> + *
> + * Assigns an address space to a VM so it can be used by the GPU/MCU.
> + *
> + * Return: 0 on success, a negative error code otherwise.
> +
On Mon, 4 Dec 2023 18:33:00 +0100
Boris Brezillon wrote:
> +/**
> + * panthor_vm_idle() - Flag a VM idle
> + * @VM: VM to flag as idle.
> + *
> + * When we know the GPU is done with the VM (no more jobs to process),
> + * we can relinquish the AS slot attached to this VM, if any.
> + *
> + * We
On Mon, 4 Dec 2023 18:33:00 +0100
Boris Brezillon wrote:
> +static int panthor_vm_prepare_unmap_op_ctx(struct panthor_vm_op_ctx *op_ctx,
> +struct panthor_vm *vm,
> +u64 va, u64 size)
> +{
> + u32 pt_count = 0;
On Sun, Jan 14, 2024 at 04:39:21PM +0200, Andy Shevchenko wrote:
> The "im" pins are optional. Add missing check in the hx8357_probe().
>
> Reported-by: Dan Carpenter
> Closes:
> https://lore.kernel.org/r/642e1230-3358-4006-a17f-3f297897ae74@moroto.mountain
> Fixes: 7d84a63a39b7 ("backlight:
It simplifies the process of extending the test suite with additional
test cases without unnecessary duplication.
Signed-off-by: Michał Winiarski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_managed_test.c | 41 +++-
1 file changed, 26 insertions(+), 15
Add a simple test that checks whether the action is called when
drmm_managed_release is called.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/tests/drm_managed_test.c | 25
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_managed_test.c
DRM tests use "_" rather than "-" as word separator. Rename the test
suite to match other tests.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/tests/drm_managed_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tests/drm_managed_test.c
Add comments explaining the intention behind the test and certain
implementation details related to device lifetime.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/tests/drm_managed_test.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_managed_test.c
Similar to devres equivalent, it allows to call the "release" action
directly and remove the resource from the managed resources list.
Signed-off-by: Michał Winiarski
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_managed.c | 39 +++
Upcoming Intel Xe driver will need to have a more fine-grained control
over DRM managed actions - namely, the ability to release a given
action, triggering it manually at a different point in time than the
final drm_dev_put().
This series adds a drmm_release_action function (which is similar to
On Wed, Jan 10, 2024 at 04:56:27PM +0100, Maxime Ripard wrote:
> On Fri, Jan 05, 2024 at 11:13:24AM +0100, Michał Winiarski wrote:
> > Add a simple test that checks whether the action is indeed called right
> > away and that it is not called on the final drm_dev_put().
> >
> > Signed-off-by:
On 2023-11-22 06:30, Nava kishore Manne wrote:
> Some systems are memory constrained but they need to load very
> large Configuration files. The FPGA subsystem allows drivers to
> request this Configuration image be loaded from the filesystem,
> but this requires that the entire configuration
Applied. Thanks!
On Wed, Jan 10, 2024 at 3:56 PM Nathan Chancellor wrote:
>
> Clang warns (or errors with CONFIG_WERROR=y) when performing arithmetic
> with different enumerated types, which is usually a bug:
>
>
>
On 1/15/24 16:46, Rob Herring wrote:
> On Mon, Jan 15, 2024 at 02:20:04PM +0100, Raphael Gallais-Pou wrote:
>> Add "st,stm32mp25-lvds" compatible.
>>
>> Signed-off-by: Raphael Gallais-Pou
>> ---
>> Depends on: "dt-bindings: stm32: add clocks and reset binding for
>> stm32mp25 platform"
On 04/01/2024 05:14, Vignesh Raman wrote:
Add job that executes the IGT test suite for sc7180-trogdor-kingoftown.
This commit also updates xfails for sc7180-trogdor-lazor-limozeen.
Signed-off-by: Vignesh Raman
Applied to drm-misc-next.
Thanks
Helen
---
See pipeline:
On 22/12/2023 00:34, Vignesh Raman wrote:
build-kdl.sh was doing a `clone --depth 1` of the default branch,
then checking out a commit that might not be the latest of that
branch, resulting in container build error.
https://gitlab.freedesktop.org/mesa/mesa/-/commit/5efa4d56 fixes
kdl commit
On 15/01/2024 07:17, Vignesh Raman wrote:
msm tests are added to testlist.txt, so update the xfails
for jobs in msm stage.
Signed-off-by: Vignesh Raman
Applied to drm-misc-next.
Thanks
Helen
---
Depends on
On 08/01/2024 16:50, Rob Clark wrote:
From: Rob Clark
The msm tests should skip on non-msm hw, so I think it should be safe to
enable everywhere.
Signed-off-by: Rob Clark
Applied to drm-misc-next.
Thanks
Helen
---
drivers/gpu/drm/ci/testlist.txt | 49
On Tue, Jan 09, 2024 at 10:11:23AM +0800, Yan Zhao wrote:
> > Well, for instance, when you install pages into the KVM the hypervisor
> > will have taken kernel memory, then zero'd it with cachable writes,
> > however the VM can read it incoherently with DMA and access the
> > pre-zero'd data
On Mon, Jan 15, 2024 at 06:27:15PM +0530, Devarsh Thakkar wrote:
> TI keystone display subsystem present in AM65 and other SoCs such as AM62
Do all 3 SoCs supported by this binding (am625 am62a7 am65x) have this
common1 register? If not, you should limit it the platforms that do have
it.
Thanks,
On Mon, Jan 15, 2024 at 06:27:16PM +0530, Devarsh Thakkar wrote:
> This adds common1 register space for AM62x and AM65x SoC's which are using
> TI's Keystone display hardware and supporting it as described in
> Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml.
>
> This region is
From: Werner Sembach
This commit implements the "force color format" drm property for the
Intel GPU driver.
Signed-off-by: Werner Sembach
Co-Developed-by: Andri Yngvason
Signed-off-by: Andri Yngvason
Tested-by: Andri Yngvason
---
Changes in v2:
- Renamed to "force color format" from
From: Werner Sembach
This commit implements the "force color format" drm property for the
AMD GPU driver.
Signed-off-by: Werner Sembach
Co-Developed-by: Andri Yngvason
Signed-off-by: Andri Yngvason
Tested-by: Andri Yngvason
---
Changes in v2:
- Renamed to "force color format" from
From: Werner Sembach
Add a new general drm property "force color format" which can be used
by userspace to tell the graphics driver which color format to use.
Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (supported by neither amdgpu or
From: Werner Sembach
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB
After some discussion, we decided to drop the "active color format"
property and rename the "preferred color format" property to "force
color format".
The user can probe available color formats in combination with other
properties using TEST_ONLY commits.
v1:
On Mon, Jan 15, 2024 at 02:20:04PM +0100, Raphael Gallais-Pou wrote:
> Add "st,stm32mp25-lvds" compatible.
>
> Signed-off-by: Raphael Gallais-Pou
> ---
> Depends on: "dt-bindings: stm32: add clocks and reset binding for
> stm32mp25 platform" by Gabriel Fernandez
>
> Changes in v3:
>
On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick wrote:
> On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote:
> > On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
> > > The i915 driver has a property to force the RGB range of an HDMI output.
> > > The vc4 driver
On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote:
> On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
> > The i915 driver has a property to force the RGB range of an HDMI output.
> > The vc4 driver then implemented the same property with the same
> > semantics. KWin has
On 15/01/2024 07:22, Vignesh Raman wrote:
Hi Rob,
On 12/01/24 22:44, Rob Clark wrote:
On Fri, Jan 12, 2024 at 7:57 AM Rob Clark wrote:
On Fri, Jan 12, 2024 at 3:42 AM Vignesh Raman
wrote:
Hi Rob,
On 09/01/24 01:20, Rob Clark wrote:
From: Rob Clark
The msm tests should skip on
On 15/01/2024 07:17, Vignesh Raman wrote:
msm tests are added to testlist.txt, so update the xfails
for jobs in msm stage.
Signed-off-by: Vignesh Raman
---
Depends on
https://patchwork.kernel.org/project/linux-arm-msm/patch/20240108195016.156583-1-robdcl...@gmail.com/
---
On 04/01/2024 05:14, Vignesh Raman wrote:
Add job that executes the IGT test suite for sc7180-trogdor-kingoftown.
This commit also updates xfails for sc7180-trogdor-lazor-limozeen.
Signed-off-by: Vignesh Raman
lgtm
Acked-by: Helen Koike
Thanks
Helen
---
See pipeline:
Hi,
Thanks for picking this up.
On 02/01/2024 06:41, Vignesh Raman wrote:
From: Helen Koike
Add job that runs igt on top of vkms.
Signed-off-by: Vignesh Raman
Acked-by: Jessica Zhang
Tested-by: Jessica Zhang
Acked-by: Maxime Ripard
Signed-off-by: Helen Koike
---
v2:
- do not mv
On Wed, Jan 10, 2024 at 02:44:00PM -0300, Arthur Grillo wrote:
> This patchset aims to add support for additional buffer YUV formats.
> More specifically, it adds support to:
>
> Semi-planar formats:
>
> - NV12
> - NV16
> - NV24
> - NV21
> - NV61
> - NV42
>
> Planar formats:
>
> - YUV440
> -
On Thu, Jan 11, 2024 at 05:17:46PM +, Andri Yngvason wrote:
> mið., 10. jan. 2024 kl. 13:26 skrifaði Daniel Stone :
> > >
> > > This thing here works entirely differently, and I think we need somewhat
> > > new semantics for this:
> > >
> > > - I agree it should be read-only for userspace, so
When the managed PCI-API was introduced to this driver, it was falsly
assumed that initializing the device with pcim_enable_device() instead
of pci_enable_device() will make all PCI functions managed.
This is wrong and was caused by the quite confusing devres API for PCI:
The function
Thanks to preceding cleanup steps, pcim_release() is now not needed
anymore and can be replaced by pcim_disable_device(), which is the exact
counterpart to pcim_enable_device().
This permits removing further parts of the old devres API.
Replace pcim_release() with pcim_disable_device().
Remove
pci_intx() is one of the functions that have "hybrid mode" (i.e.,
sometimes managed, sometimes not). Providing a separate pcim_intx()
function with its own device resource and cleanup callback allows for
removing further large parts of the legacy pci-devres implementation.
As in the
The bit describing whether the PCI device is currently pinned is stored
in the PCI devres struct. To clean up and simplify the pci-devres API,
it's better if this information is stored in the pci_dev struct, because
it allows for checking that device's pinned-status directly through the
device
The bit describing whether the PCI device is currently enabled is stored
in the devres-struct. Besides this struct being subject of a cleanup
process, the device-struct is in general the right place to store this
information, since it is not devres-specific.
Move the 'enabled' boolean bit to
managing mwi with devres can easily be done with its own callback,
without the necessity to store any state about it in a device-related
struct.
Remove the mwi state from the devres-struct.
Make the devres-mwi functions set a separate devres-callback.
Signed-off-by: Philipp Stanner
---
Now that pure managed region request functions are available, the
implementation of the hybrid-functions which are only sometimes managed
can be made more consistent and readable by wrapping those
always-managed functions.
Implement a new pcim_ function for exclusively requested regions.
Have the
The old plural devres functions tie PCI's devres implementation to the
iomap-table mechanism which unfortunately is not extensible.
As the purlal functions are almost never used with more than one bit set
in their bit-mask, deprecating them and encouraging users to use the new
singular functions
The PCI region-request functions become managed functions when
pcim_enable_device() has been called previously instead of
pci_enable_device().
This has already caused bugs by confusing users, who came to believe
that all pci functions, such as pci_iomap(), suddenly are managed that
way.
This is
PCI's devres API is not extensible to ranged mappings and has
bug-provoking features. Improve that by providing better alternatives.
When the original devres API for PCI was implemented, priority was given
to the creation of a set of "pural functions" such as
pcim_request_regions(). These
¡Hola!
PCI's devres API suffers several weaknesses:
1. There are functions prefixed with pcim_. Those are always managed
counterparts to never-managed functions prefixed with pci_ – or so one
would like to think. There are some apparently unmanaged functions
(all region-request /
On Mon, Jan 15, 2024 at 09:55:00AM +0100, H. Nikolaus Schaller wrote:
> Hi,
>
> > Am 15.01.2024 um 09:25 schrieb Maxime Ripard :
> >
> > Hi,
> >
> > On Fri, Jan 12, 2024 at 06:33:58PM +0100, H. Nikolaus Schaller wrote:
> >>> Am 08.01.2024 um 19:32 schrieb Andrew Davis :
> >>>
> >>> Add SGX GPU
On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote:
> On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
> > The i915 driver has a property to force the RGB range of an HDMI output.
> > The vc4 driver then implemented the same property with the same
> > semantics. KWin has
On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
> The i915 driver has a property to force the RGB range of an HDMI output.
> The vc4 driver then implemented the same property with the same
> semantics. KWin has support for it, and a PR for mutter is also there to
> support it.
>
>
On Mon, 15 Jan 2024 14:20:04 +0100, Raphael Gallais-Pou wrote:
> Add "st,stm32mp25-lvds" compatible.
>
> Signed-off-by: Raphael Gallais-Pou
> ---
> Depends on: "dt-bindings: stm32: add clocks and reset binding for
> stm32mp25 platform" by Gabriel Fernandez
>
> Changes in v3:
>
Hi Faith,
Sorry for the late reply, I only got back to panthor very recently.
On Mon, 11 Dec 2023 12:18:04 -0600
Faith Ekstrand wrote:
> On Mon, 2023-12-11 at 09:52 +0100, Boris Brezillon wrote:
> > Hi,
> >
> > On Sun, 10 Dec 2023 13:58:51 +0900
> > Tatsuyuki Ishi wrote:
> >
> > > > On
On Tue, Jan 9, 2024 at 9:23 AM Yoshinori Sato
wrote:
> R4 is caller saved in SH ABI.
> Save it so it doesn't get corrupted until it's needed for initialization.
>
> Signed-off-by: Yoshinori Sato
My
Reviewed-by: Geert Uytterhoeven
on v3 is still valid.
Gr{oetje,eeting}s,
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
wrote:
> Add IO DATA DEVICE INC.
> https://www.iodata.com/
>
> Signed-off-by: Yoshinori Sato
My
Reviewed-by: Geert Uytterhoeven
on v3 is still valid.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:23 AM Yoshinori Sato
wrote:
> Add SH7750 TMU entry.
>
> I wanted to replace interrupts and interrupt-names in the if compatible is
> "renesas,tmu-7750", but it seems that I can't rewrite it as expected.
> This resulted in a redundant conditional statement.
>
Add common1 register space for SoC's supporting TI Keystone displays
present in AM65x and AM62x SoCs. This is required to support use-cases
where Linux may want to use common1 region instead of common region with
the latter being controlled by another processing core.
The enumeration of common1
This adds common1 register space for AM62x and AM65x SoC's which are using
TI's Keystone display hardware and supporting it as described in
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml.
This region is documented in respective Technical Reference Manuals [1].
[1]:
AM62x TRM:
Make debug logs more readable and consistent:
- don't print handle as it is not always available for all buffers
- use hashed ivpu_bo ptr as main buffer identifier
- remove unused fields from ivpu_bo_print_info()
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/ivpu_gem.c | 63
From: "Wachowski, Karol"
DRM_IVPU_PARAM_CONTEXT_PRIORITY has been deprecated because it
has been replaced with DRM_IVPU_JOB_PRIORITY levels set with
submit IOCTL and was unused anyway.
Signed-off-by: Wachowski, Karol
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/ivpu_drv.c | 11
This was not supported properly. A buffer was imported to another VPU
context as a separate buffer object with duplicated sgt.
Both exported and imported buffers could be DMA mapped causing a double
mapping on the same device.
Buffers imported from another VPU context will now just increase
Call dma_unmap() on all buffers before the VPU is unbinded to avoid
"device driver has pending DMA allocations while released from device"
warning when DMA-API debug is enabled.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
---
drivers/accel/ivpu/ivpu_gem.c | 14 --
1
drm_gem_shmem_vmap/vunmap requires dma resv lock to be held.
This was missed during conversion to shmem helper.
Fixes: 8d88e4cdce4f ("accel/ivpu: Use GEM shmem helper for all buffers")
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
---
drivers/accel/ivpu/ivpu_gem.c | 5 +
1
From: "Wachowski, Karol"
Make boot/suspend failure debugging easier by dumping FW logs and error
registers.
Signed-off-by: Wachowski, Karol
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
---
drivers/accel/ivpu/ivpu_drv.c | 5 +++--
drivers/accel/ivpu/ivpu_pm.c | 4 +++-
2 files
From: "Wachowski, Karol"
It is common need to be able to see IOVA/physical to VPU addresses
mappings. Especially when debugging different kind of memory related
issues. Lack of such logs forces user to modify and recompile KMD manually.
This commit adds those logs under MMU debug mask which can
From: "Wachowski, Karol"
Check for possible failure reasons in the buttress.
Some errors (like external abort) should have corresponding buttress errors
registers set indicating the real reason of failure.
Signed-off-by: Wachowski, Karol
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey
From: "Wachowski, Karol"
Add ivpu_mmu_evtq_dump() function that dumps existing MMU events from
MMU event queue. Call this function if VPU boot failed.
Previously MMU events were only checked in interrupt handler, but if VPU
failed to boot due to MMU faults, those faults were missed because of
Various driver fixes:
- Fixes for infinite loops, missing locks and DMA-API debug warnings
- Deprecate DRM_IVPU_PARAM_CONTEXT_PRIORITY
- Improve diagnostic messages
v2 includes changes from v1 review comments and drops IRQ infinite loop patch.
Jacek Lawrynowicz (4):
accel/ivpu: Fix for
Prefer the parsed results for is_hdmi and has_audio in display info over
calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
respectively.
Conveniently, this also removes the need to use edid_blob_ptr.
v2: Reverse a backwards if condition (Ilia)
Cc: Karol Herbst
Cc: Lyude Paul
The LCD-TFT Display Controller (LTDC) handles display composition,
scaling and rotation. It provides a parallel digital RGB flow to be used
by display interfaces.
Signed-off-by: Raphael Gallais-Pou
---
arch/arm64/boot/dts/st/stm32mp251.dtsi | 12
1 file changed, 12 insertions(+)
This patch adds LVDS support on stm32mp255. The LVDS is used on
STM32MP2 as a display interface. LVDS PLL clock is binded to the LTDC
input clock.
Signed-off-by: Raphael Gallais-Pou
---
Changes in v3:
- Change the compatible to show SoC specificity
Changes in v2:
- Move patch
This patch enables the following IPs on stm32mp257f-ev :
* LTDC
* LVDS
* WSVGA LVDS panel (1024x600)
* Panel backlight
* Ilitek touchescreen
Signed-off-by: Raphael Gallais-Pou
---
arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 79 ++
1 file changed, 79 insertions(+)
The Low-Voltage Differential Signaling (LVDS) Display Interface
Transmitter handles the LVDS protocol: it maps the pixels received from
the upstream Pixel-DMA LCD-TFT Display Controller (LTDC) onto the LVDS
PHY.
It is composed of three sub blocks:
* LVDS host: handles the LVDS protocol
Add "st,stm32mp25-lvds" compatible.
Signed-off-by: Raphael Gallais-Pou
---
Depends on: "dt-bindings: stm32: add clocks and reset binding for
stm32mp25 platform" by Gabriel Fernandez
Changes in v3:
- Clarify commit dependency
- Fix includes in the example
-
This serie introduces a new DRM bridge driver for STM32MP257 platforms
based on Arm Cortex-35. It also adds an instance in the device-tree and
handle the inclusion of the driver within the DRM framework. First patch
adds a new panel compatible in the panel-lvds driver, which is used by
default on
The STM32MP25x display subsystem presents a mux which feeds the loopback
pixel clock of the current bridge in use into the LTDC. This mux is only
accessible through sysconfig registers which is not yet available in the
STM32MP25x common clock framework.
While waiting for a complete update of the
On Wed, 20 Dec 2023 20:59:43 +0100
Ketil Johnsen wrote:
> > +/**
> > + * cs_slot_sync_queue_state_locked() - Synchronize the queue slot priority
> > + * @ptdev: Device.
> > + * @csg_id: Group slot.
> > + * @cs_id: Queue slot.
> > + *
> > + * Queue state is updated on group suspend or
TI keystone display subsystem present in AM65 and other SoCs such as AM62
support two separate register spaces namely "common" and "common1" which
can be used by two separate hosts to program the display controller as
described in respective Technical Reference Manuals [1].
The common1 register
On Tue, 19 Dec 2023 12:50:21 +0100
Ketil Johnsen wrote:
> On 04/12/2023 18:33, Boris Brezillon wrote:
>
>
>
> > +static void
> > +panthor_queue_put_syncwait_obj(struct panthor_queue *queue)
> > +{
> > + if (queue->syncwait.kmap) {
> > + struct iosys_map map =
> >
On Mon, 11 Dec 2023 16:27:36 +
Steven Price wrote:
> On 04/12/2023 17:33, Boris Brezillon wrote:
> > This is the piece of software interacting with the FW scheduler, and
> > taking care of some scheduling aspects when the FW comes short of slots
> > scheduling slots. Indeed, the FW only
On Wed, 20 Dec 2023 16:24:17 +
Liviu Dudau wrote:
> > +/**
> > + * panthor_get_uobj_array() - Copy a user object array into a kernel
> > accessible object array.
> > + * @in: The object array to copy.
> > + * @min_stride: Minimum array stride.
> > + * @obj_size: Kernel object size.
> > + *
On Wed, 20 Dec 2023 15:12:15 +
Liviu Dudau wrote:
> > +static int panthor_fw_load_section_entry(struct panthor_device *ptdev,
> > +const struct firmware *fw,
> > +struct panthor_fw_binary_iter *iter,
> > +
1 - 100 of 142 matches
Mail list logo
