Hi Jonathan,
Le jeudi 21 décembre 2023 à 12:06 +, Jonathan Cameron a écrit :
> On Tue, 19 Dec 2023 18:50:06 +0100
> Paul Cercueil wrote:
>
> > Add the necessary infrastructure to the IIO core to support a new
> > optional DMABUF based interface.
> >
> > With this new interface, DMABUF
This function allocates a struct pwm_chip and driver data. Compared to
the status quo the split into pwm_chip and driver data is new, otherwise
it doesn't change anything relevant (yet).
The intention is that after all drivers are switched to use this
allocation function, its possible to add a
Hello,
this is v5 of this series. The relevant changes since v4
(https://lore.kernel.org/linux-pwm/cover.1701860672.git.u.kleine-koe...@pengutronix.de):
- New first patch to reshuffle functions in core.c. This is a
preparation for the later changes which brings functions in a better
order
struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 10 +-
1 file changed, 5 insertions(+), 5
This prepares the pwm driver of the ti-sn65dsi86 to further changes of
the pwm core outlined in the commit introducing devm_pwmchip_alloc().
There is no intended semantical change and the driver should behave as
before.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c |
Am 24.01.24 um 11:58 schrieb Paul Cercueil:
[SNIP]
The problem was then that dma_buf_unmap_attachment cannot be called
before the dma_fence is signaled, and calling it after is already
too
late (because the fence would be signaled before the data is
sync'd).
Well what sync are you
On Thu, 25 Jan 2024, Neil Armstrong wrote:
> Thanks, but now some patches subjects are wrong:
> s/drm_bridge_read_edid/drm_bridge_edid_read/s
Oh, dang it, that was mentioned before, but I forgot. My bad.
> With that fixed please add:
> Reviewed-by: Neil Armstrong
Entire series? Much
Il 25/01/24 13:08, Uwe Kleine-König ha scritto:
Currently a pwm_chip stores in its struct device *dev member a pointer
to the parent device. Preparing a change that embeds a full struct
device in struct pwm_chip, this accessor macro should be used in all
drivers directly accessing chip->dev now.
Il 25/01/24 13:09, Uwe Kleine-König ha scritto:
These functions are useful to store and query driver private data a
After struct pwm_chip got its own struct device, this can make use of
dev_get_drvdata() and dev_set_drvdata() on that device. These functions
are required already now to convert
The vendor kernel sets a previously unknown clock gating bit in the
VIVS_PM_MODULE_CONTROLS register to disable SH_EU clock gating.
Import new headers from rnndb for the definition and set the bit
for the VIPNano-Si+ NPU on i.MX8MP and other affected cores.
Signed-off-by: Philipp Zabel
---
Hi Ma Jun,
Copy that. This appears to be the exact problem, and thank you for
reviewing the bug report at such a short notice.
I apologise for the wrong assertion.
The patch you sent then just triggered another bug, and it is not
manifested without the patch (but a NULL pointer dereference
On Fri, 5 Jan 2024 21:46:18 +0300
Dmitry Osipenko wrote:
> SGT isn't refcounted. Once SGT pointer has been obtained, it remains the
> same for both locked and unlocked get_pages_sgt(). Return cached SGT
> directly without taking a potentially expensive lock.
>
> Signed-off-by: Dmitry Osipenko
On 23/01/2024 20:37, Jani Nikula wrote:
Add new struct drm_edid based ->edid_read hook and
drm_bridge_edid_read() function to call the hook.
v2: Include drm/drm_edid.h
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_bridge.c | 46 +++-
Disable SH_EU clock gating for the VIPNano-Si+ NPU on i.MX8MP
and for other affected core revisions.
Taken from linux-imx lf-6.1.36-2.1.0, specifically [1].
[1]
https://github.com/nxp-imx/linux-imx/blob/lf-6.1.36-2.1.0/drivers/mxc/gpu-viv/hal/kernel/arch/gc_hal_kernel_hardware.c#L2747-L2761
Update the state HI header from the rnndb commit
8d7ee714cfe2 ("Merge pull request #24 from pH5/unknown-3950").
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/etnaviv/cmdstream.xml.h | 52 ++--
drivers/gpu/drm/etnaviv/common.xml.h| 12 ++--
Currently a pwm_chip stores in its struct device *dev member a pointer
to the parent device. Preparing a change that embeds a full struct
device in struct pwm_chip, this accessor macro should be used in all
drivers directly accessing chip->dev now. This way struct pwm_chip and
this macro can be
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared
Add clear page support in vram memory region.
v1:(Christian)
- Dont handle clear page as TTM flag since when moving the BO back
in from GTT again we don't need that.
- Make a specialized version of amdgpu_fill_buffer() which only
clears the VRAM areas which are not already cleared
-
On 1/24/24 22:08, Matthew Brost wrote:
> All entities must be drained in the DRM scheduler run job worker to
> avoid the following case. An entity found that is ready, no job found
> ready on entity, and run job worker goes idle with other entities + jobs
> ready. Draining all ready entities (i.e.
On Thu, 25 Jan 2024, wangxiaoming321 wrote:
> In the call stack xe_device_probe -> xe_display_init_nommio ->
> intel_power_domains_init
> Power_domains hasn't been cleaned up if return error,
> which has do the clean in i915_driver_late_release call from
> i915_driver_probe.
This has nothing
Am 24.01.24 um 12:04 schrieb Alistair Popple:
"Zhou, Xianrong" writes:
[AMD Official Use Only - General]
The vmf_insert_pfn_prot could cause unnecessary double faults on a
device pfn. Because currently the vmf_insert_pfn_prot does not
make the pfn writable so the pte entry is normally
On Fri, 5 Jan 2024 21:46:24 +0300
Dmitry Osipenko wrote:
> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> @@ -328,6 +328,7 @@ int panfrost_mmu_map(struct panfrost_gem_mapping *mapping)
> struct panfrost_device *pfdev =
On Fri, 5 Jan 2024 21:46:16 +0300
Dmitry Osipenko wrote:
> +static bool drm_gem_shmem_is_evictable(struct drm_gem_shmem_object *shmem)
> +{
> + return (shmem->madv >= 0) && shmem->base.funcs->evict &&
> + refcount_read(>pages_use_count) &&
> +
On Wed, Jan 24, 2024 at 11:14:40AM -0300, André Almeida wrote:
> Hi Ville,
>
> Em 19/01/2024 15:25, Ville Syrjälä escreveu:
> > On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
> >> AMD GPUs can do async flips with changes on more properties than just
> >> the FB ID, so implement a
Turn the etnaviv_is_model_rev() macro into a static inline function.
Use the raw model number as a parameter instead of the chipModel_GC
defines. This reduces synchronization requirements for the generated
headers. For newer hardware, the GC names are not the correct model
names anyway.
These functions are useful to store and query driver private data a
After struct pwm_chip got its own struct device, this can make use of
dev_get_drvdata() and dev_set_drvdata() on that device. These functions
are required already now to convert drivers to pwmchip_alloc() which
must happen before
On 23/01/2024 20:37, Jani Nikula wrote:
v3 of [1] with a couple of patches fixed.
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/128149/
Jani Nikula (39):
drm/bridge: add ->edid_read hook and drm_bridge_edid_read()
drm/bridge: switch to drm_bridge_read_edid()
drm/bridge:
[snip]
Fd0 = open(card0)
Fd1 = open(card1)
Vm0 =xe_vm_create(fd0) //driver create process xe_svm on the process's first
vm_create
Vm1 = xe_vm_create(fd1) //driver re-use xe_svm created above if called from
same process
Queue0 = xe_exec_queue_create(fd0, vm0)
Queue1 = xe_exec_queue_create(fd1,
On 1/25/24 12:49, Boris Brezillon wrote:
> On Fri, 5 Jan 2024 21:46:24 +0300
> Dmitry Osipenko wrote:
>
>> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
>> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
>> @@ -328,6 +328,7 @@ int panfrost_mmu_map(struct panfrost_gem_mapping
>> *mapping)
>>
On Sun, 14 Jan 2024 16:39:21 +0200, Andy Shevchenko wrote:
> The "im" pins are optional. Add missing check in the hx8357_probe().
>
>
Applied, thanks!
[1/1] backlight: hx8357: Fix potential NULL pointer dereference
commit: 3b75d271e161e22aff8171940a77510d2fb2ad6f
--
Lee Jones [李琼斯]
Add a function to support defragmentation.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Matthew Auld
---
drivers/gpu/drm/drm_buddy.c | 48 -
1 file changed, 37 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c
Applied to drm-misc-fixes
On 22.01.2024 13:09, Jacek Lawrynowicz wrote:
> Stability fixes for reset, recovery and unbind.
>
> Jacek Lawrynowicz (3):
> accel/ivpu: Fix dev open/close races with unbind
> accel/ivpu: Improve stability of ivpu_submit_ioctl()
> accel/ivpu: Improve recovery and
On Wed, 24 Jan 2024, Gustavo Sousa wrote:
> Quoting Yury Norov (2024-01-24 12:27:58-03:00)
>>On Wed, Jan 24, 2024 at 08:03:53AM -0600, Lucas De Marchi wrote:
>>> On Wed, Jan 24, 2024 at 09:58:26AM +0200, Jani Nikula wrote:
>>> > On Tue, 23 Jan 2024, Lucas De Marchi wrote:
>>> > > From: Yury
On 22/01/2024 18:45, Gustavo A. R. Silva wrote:
On 1/20/24 09:10, Erick Archer wrote:
As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or
On Mon, 22 Jan 2024, Duje Mihanović wrote:
> The ExpressWire protocol is shared between at least KTD2692 and KTD2801
> with slight differences such as timings and the former not having a
> defined set of pulses for enabling the protocol (possibly because it
> does not support PWM unlike KTD2801).
On 1/22/24 4:17 PM, H. Peter Anvin wrote:
On January 22, 2024 4:04:33 PM PST, Alexey Makhalov
wrote:
On 1/22/24 10:28 AM, H. Peter Anvin wrote:
On January 22, 2024 8:32:22 AM PST, Dave Hansen wrote:
On 1/9/24 00:40, Alexey Makhalov wrote:
+#ifdef CONFIG_INTEL_TDX_GUEST
+unsigned long
On Fri, Jan 19, 2024 at 08:32:06AM -0800, Erik Kurzinger wrote:
> When waiting for a syncobj timeline point whose fence has not yet been
> submitted with the WAIT_FOR_SUBMIT flag, a callback is registered using
> drm_syncobj_fence_add_wait and the thread is put to sleep until the
> timeout
The dp_power submodule is limited to handling the clocks only following
previous cleanups. Fold it into the dp_ctrl submodule, removing one
unnecessary level of indirection.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile| 1 -
drivers/gpu/drm/msm/dp/dp_ctrl.c|
There is only a single DP_STREAM_PM clock, stream_pixel. Instead of
using a separate dss_module_power instance for this single clock, handle
this clock directly. This allows us to drop several wrapping functions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 91
Split the dp_ctrl_clk_enable() beast into four functions, each of them
doing just a single item: enabling or disabling core or link clocks.
This allows us to cleanup the dss_module_power structure and makes
several dp_ctrl functions return void.
Signed-off-by: Dmitry Baryshkov
---
Inline dp_catalog_aux_update_cfg() and call phy_calibrate() from dp_aux
functions directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_aux.c | 9 +++--
drivers/gpu/drm/msm/dp/dp_aux.h | 1 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 12
There is little point in sharing phy configuration structure between
several modules. Move it to dp_ctrl, which becomes the only submodule
re-configuring the PHY.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 19 -
drivers/gpu/drm/msm/dp/dp_catalog.h
Finally drop separate "parsing" submodule. There is no need in it
anymore. All submodules handle DT properties directly rather than
passing them via the separate structure pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile| 1 -
drivers/gpu/drm/msm/dp/dp_aux.h
There is little point in going trough dp_parser->io indirection each
time the driver needs to access the PHY. Store the pointer directly in
dp_ctrl_private.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 37 +
Rather than parsing the I/O addresses from dp_parser and then passing
them via a struct pointer to dp_catalog, handle I/O region parsing in
dp_catalog and drop it from dp_parser.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 125 ++--
Remove two levels of indirection and fetch next bridge directly in
dp_display_probe_tail().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 43 -
drivers/gpu/drm/msm/dp/dp_parser.c | 14
All supported platforms use the same clocks configuration. Instead of
parsing names from DT in a pretty complex manner, use the static
configuration. If at some point newer (or older) platforms have
different clock configuration, this clock config can be moved to the
device data.
Signed-off-by:
Instead of passing link properties through the separate struct, parse
them directly in the dp_panel.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 8 -
drivers/gpu/drm/msm/dp/dp_display.h | 1 -
drivers/gpu/drm/msm/dp/dp_panel.c | 66
Just FYI I'm pulling this into drm-fixes straight as is, since if
fixes the regression and avoids the revert, however please keep
discussing until we are sure things are right, and we can deal with
any fixes in a follow-up patch.
Dave.
On Fri, 26 Jan 2024 at 03:32, Matthew Brost wrote:
>
> On
On Do, 2024-01-25 at 17:14 +0100, Christian Gmeiner wrote:
> >
> > Update the state HI header from the rnndb commit
> > 8d7ee714cfe2 ("Merge pull request #24 from pH5/unknown-3950").
> >
> > Signed-off-by: Philipp Zabel
>
> You missed my R-b from the v1 series for this patch - please include
>
Hi Chunming,
From: 周春明(日月)
Sent: Thursday, January 25, 2024 6:01 AM
To: Zeng, Oak ; Christian König ;
Danilo Krummrich ; Dave Airlie ; Daniel
Vetter ; Felix Kuehling ; Shah, Ankur
N ; Winiarski, Michal
Cc: Brost, Matthew ; thomas.hellst...@linux.intel.com;
Welty, Brian ;
On 2024-01-24 20:17, Zeng, Oak wrote:
Hi Christian,
Even though I mentioned KFD design, I didn’t mean to copy the KFD
design. I also had hard time to understand the difficulty of KFD under
virtualization environment.
The problem with virtualization is related to virtualization design
On Fri, Jan 19, 2024 at 03:13:57PM +0100, Paul Cercueil wrote:
> These functions should be used by device drivers when they start and
> stop accessing the data of DMABUF. It allows DMABUF importers to cache
> the dma_buf_attachment while ensuring that the data they want to access
> is available
On Mon, Jan 22, 2024 at 10:31:50AM +0100, Anna-Maria Behnsen wrote:
> Hi,
>
> this is a repost of the RFC queue
> https://lkml.kernel.org/r/20240116151456.48238-1-anna-ma...@linutronix.de
>
> Jonathan Corbet is fine with this change and mentioned in an answer the
> following:
>
> "The
On Mon, Dec 11, 2023 at 9:33 PM Adam Ford wrote:
>
> When using video sync pulses, the HFP, HBP, and HSA are divided between
> the available lanes if there is more than one lane. For certain
> timings and lane configurations, the HFP may not be evenly divisible.
> If the HFP is rounded down, it
On Tue, Jan 23, 2024 at 01:04:24PM +, Matt Coster wrote:
> From: Donald Robson
>
> When the kernel driver 'loses' the device, for instance if the firmware
> stops communicating, the driver calls drm_dev_unplug(). This is
> currently done inside the drm_dev_enter() critical section, which
Am 24.01.24 um 22:08 schrieb Matthew Brost:
All entities must be drained in the DRM scheduler run job worker to
avoid the following case. An entity found that is ready, no job found
ready on entity, and run job worker goes idle with other entities + jobs
ready. Draining all ready entities
On 1/5/2024 3:50 PM, Dmitry Baryshkov wrote:
We have several reports of vblank timeout messages. However after some
debugging it was found that there might be different causes to that.
Include the actual CTL_FLUSH value into the timeout message. This allows
us to identify the DPU block that
Hi,
On Thu, Jan 25, 2024 at 4:11 AM Uwe Kleine-König
wrote:
>
> struct pwm_chip::dev is about to change. To not have to touch this
> driver in the same commit as struct pwm_chip::dev, use the macro
> provided for exactly this purpose.
>
> Signed-off-by: Uwe Kleine-König
> ---
>
On Tue, Jan 23, 2024 at 06:09:05AM +, Jason-JH Lin (林睿祥) wrote:
> Hi Maxime, Daniel,
>
> We encountered similar issue with mediatek SoCs.
>
> We have found that in drm_atomic_helper_commit_rpm(), when disabling
> the cursor plane, the old_state->legacy_cursor_update in
>
The ExpressWire protocol is shared between at least KTD2692 and KTD2801
with slight differences such as timings and the former not having a
defined set of pulses for enabling the protocol (possibly because it
does not support PWM unlike KTD2801). Despite these differences the
ExpressWire handling
The KTD2692 uses the ExpressWire protocol implemented in the newly
introduced ExpressWire library. Convert the driver to use the library.
Suggested-by: Daniel Thompson
Reviewed-by: Linus Walleij
Reviewed-by: Daniel Thompson
Signed-off-by: Duje Mihanović
---
drivers/leds/flash/Kconfig
Hello,
This series adds support for the Kinetic KTD2801 LED backlight driver
IC found in samsung,coreprimevelte.
Support is already upstream for the somewhat similar KTD2692 flash
driver, and this series since v3 also moves its ExpressWire code into a
separate library and converts the KTD2692
KTD2801 is a LED backlight driver IC found in samsung,coreprimevelte.
The brightness can be set using PWM or the ExpressWire protocol. Add
support for the KTD2801.
Reviewed-by: Linus Walleij
Reviewed-by: Daniel Thompson
Signed-off-by: Duje Mihanović
---
MAINTAINERS
KTD2801 is a LED backlight driver IC found in samsung,coreprimevelte.
The brightness can be set using PWM or the ExpressWire protocol. Add
a DT binding for the KTD2801.
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Linus Walleij
Reviewed-by: Daniel Thompson
Signed-off-by: Duje Mihanović
---
On 1/24/24 5:05 PM, Kasireddy, Vivek wrote:
Hi Andrew,
Currently this driver creates a SGT table using the CPU as the
target device, then performs the dma_sync operations against
that SGT. This is backwards to how DMA-BUFs are supposed to behave.
This may have worked for the case where these
Am Donnerstag, dem 25.01.2024 um 17:27 +0100 schrieb Christian Gmeiner:
> Hi Philipp
>
> >
> > Turn the etnaviv_is_model_rev() macro into a static inline function.
> > Use the raw model number as a parameter instead of the chipModel_GC
> > defines. This reduces synchronization requirements
On Thu, Jan 25, 2024 at 10:24:24AM +0100, Vlastimil Babka wrote:
> On 1/24/24 22:08, Matthew Brost wrote:
> > All entities must be drained in the DRM scheduler run job worker to
> > avoid the following case. An entity found that is ready, no job found
> > ready on entity, and run job worker goes
On Tue, Jan 23, 2024 at 05:25:38PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> fences are signalled on nvidia hw using non-stall interrupts.
>
> non-stall interrupts are not latched from my reading.
>
> When nouveau emits a fence, it requests a NON_STALL signalling,
> but it only calls
During syncobj_eventfd_entry_func, dma_fence_chain_find_seqno may set
the fence to NULL if the given seqno is signaled and a later seqno has
already been submitted. In that case, the eventfd should be signaled
immediately which currently does not happen.
This is a similar issue to the one
Hi Philipp
>
> Turn the etnaviv_is_model_rev() macro into a static inline function.
> Use the raw model number as a parameter instead of the chipModel_GC
> defines. This reduces synchronization requirements for the generated
> headers. For newer hardware, the GC names are not the correct
On Fri, Jan 05, 2024 at 09:46:03PM +0300, Dmitry Osipenko wrote:
> Add lockless drm_gem_shmem_get_pages() helper that skips taking reservation
> lock if pages_use_count is non-zero, leveraging from atomicity of the
> refcount_t. Make drm_gem_shmem_mmap() to utilize the new helper.
>
> Acked-by:
On Thu, Jan 25, 2024 at 04:12:58PM +0100, Christian König wrote:
>
>
> Am 24.01.24 um 22:08 schrieb Matthew Brost:
> > All entities must be drained in the DRM scheduler run job worker to
> > avoid the following case. An entity found that is ready, no job found
> > ready on entity, and run job
Hi,
On Thu, Jan 25, 2024 at 4:11 AM Uwe Kleine-König
wrote:
>
> This prepares the pwm driver of the ti-sn65dsi86 to further changes of
> the pwm core outlined in the commit introducing devm_pwmchip_alloc().
> There is no intended semantical change and the driver should behave as
> before.
>
>
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
> Am 23.01.24 um 20:37 schrieb Zeng, Oak:
> > [SNIP]
> > Yes most API are per device based.
> >
> > One exception I know is actually the kfd SVM API. If you look at the
> > svm_ioctl function, it is per-process based. Each
Sorry, I realized there is a mistake in this patch after sending it out. It
results in a use-after-free of "entry". I've sent out an updated version which
should avoid the issue.
On 1/25/24 10:03, Erik Kurzinger wrote:
> During syncobj_eventfd_entry_func, dma_fence_chain_find_seqno may set
>
Hi
On 1/4/24 14:44, Raphael Gallais-Pou wrote:
In RCC driver, 'DSI_K' is a kernel clock while 'DSI' has pclk4 as parent
clock, which means that it is an APB peripheral clock. Swap the clocks
in the DSI peripheral clock reference.
Signed-off-by: Raphael Gallais-Pou
---
After updating commit
Hi Christian,
I got a few more questions inline
From: Christian König
Sent: Wednesday, January 24, 2024 3:33 AM
To: Zeng, Oak ; Danilo Krummrich ; Dave
Airlie ; Daniel Vetter ; Felix Kuehling
Cc: Welty, Brian ; dri-devel@lists.freedesktop.org;
intel...@lists.freedesktop.org; Bommu,
Hi Ma Jun,
Greetings again.
So, I just tested the recommended patch and the issue with the graphical login
screen was successfully resolved.
Thank you very much for your prompt reviews and recommended patches.
God bless.
Best regards,
Mirsad Todorovac
On 1/25/24 10:29, Mirsad Todorovac
On Thu, Jan 25, 2024 at 04:00:16PM +0100, Christian König wrote:
> Am 24.01.24 um 11:58 schrieb Paul Cercueil:
> > [SNIP]
> > > > The problem was then that dma_buf_unmap_attachment cannot be called
> > > > before the dma_fence is signaled, and calling it after is already
> > > > too
> > > > late
On 1/24/24 4:36 PM, Kasireddy, Vivek wrote:
Hi Andrew,
When a device attaches to and maps our buffer we need to keep track
of this mapping/device. This is needed for synchronization with these
devices when beginning and ending CPU access for instance. Add a list
that tracks device mappings as
>
> Update the state HI header from the rnndb commit
> 8d7ee714cfe2 ("Merge pull request #24 from pH5/unknown-3950").
>
> Signed-off-by: Philipp Zabel
You missed my R-b from the v1 series for this patch - please include
it the next time!
Reviewed-by: Christian Gmeiner
> ---
>
On 05/01/2024 18:46, Dmitry Osipenko wrote:
> From: Boris Brezillon
>
> If some the pages or sgt allocation failed, we shouldn't release the
> pages ref we got earlier, otherwise we will end up with unbalanced
> get/put_pages() calls. We should instead leave everything in place
> and let the BO
On 05/01/2024 18:46, Dmitry Osipenko wrote:
> To simplify the drm-shmem refcnt handling, we're moving away from
> the implicit get_pages() that is used by get_pages_sgt(). From now on
> drivers will have to pin pages while they use sgt. Panfrost's shrinker
> doesn't support swapping out BOs, hence
During syncobj_eventfd_entry_func, dma_fence_chain_find_seqno may set
the fence to NULL if the given seqno is signaled and a later seqno has
already been submitted. In that case, the eventfd should be signaled
immediately which currently does not happen.
This is a similar issue to the one
> -Original Message-
> From: Felix Kuehling
> Sent: Thursday, January 25, 2024 12:16 PM
> To: Zeng, Oak ; Christian König
> ; Danilo Krummrich ; Dave
> Airlie ; Daniel Vetter ; Shah, Ankur N
> ; Winiarski, Michal
> Cc: Welty, Brian ; dri-devel@lists.freedesktop.org;
> intel-
>
> >> Currently this driver creates a SGT table using the CPU as the
> >> target device, then performs the dma_sync operations against
> >> that SGT. This is backwards to how DMA-BUFs are supposed to behave.
> >> This may have worked for the case where these buffers were given
> >> only back to the
* Tony Lindgren [240118 08:57]:
> * Andrew Davis [240117 15:52]:
> > On 1/10/24 2:29 AM, Tony Lindgren wrote:
> > > * Andrew Davis [240109 17:20]:
> > > > --- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
> > > > +++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
> > > > @@ -850,12 +850,19 @@
On Fri, Jan 5, 2024 at 8:51 AM Zack Rusin wrote:
>
> Some drivers require the mapped tt pages to be decrypted. In an ideal
> world this would have been handled by the dma layer, but the TTM page
> fault handling would have to be rewritten to able to do that.
>
> A side-effect of the TTM page
[AMD Official Use Only - General]
> The vmf_insert_pfn_prot could cause unnecessary double faults
> on a device pfn. Because currently the vmf_insert_pfn_prot does
> not make the pfn writable so the pte entry is normally
> read-only or dirty catching.
> >>>
The ITE IT6505 display bridge can take one I2S input and transmit it
over the DisplayPort link.
Add #sound-dai-cells (= 0) to the binding for it.
Signed-off-by: Chen-Yu Tsai
---
The driver side changes [1] are still being worked on, but given the
hardware is very simple, it would be nice if we
INTF_CONFIG2 register cannot have widebus enabled when DP format is
YUV420. Therefore, program the INTF to send 1 ppc.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Generalize dpu_encoder_helper_phys_setup_cdm to be compatible with DP.
Signed-off-by: Paloma Arellano
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 4 +--
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 31 ++-
2 files changed, 18 insertions(+), 17 deletions(-)
diff
Modify dp_catalog_hw_revision to make the major and minor version values
known instead of outputting the entire hex value of the hardware version
register in preparation of using it for VSC SDP programming.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 12 +---
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 8 +
From: Kuogee Hsieh
Introduce a peripheral flushing mechanism to decouple peripheral
metadata flushing from timing engine related flush.
Signed-off-by: Kuogee Hsieh
Signed-off-by: Paloma Arellano
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c| 3 +++
Rename wide_bus_en to wide_bus_supported in dp_display_private to
correctly establish that the parameter is referencing if wide bus is
supported instead of enabled.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_display.c | 42 ++---
1 file changed, 21
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420, program the
configuration control to indicate YUV420, as well as modify the MVID
programming to consider YUV420.
Signed-off-by: Paloma Arellano
---
Parity calculation is necessary for VSC SDP implementation, therefore
move it to dp_catalog so it usable by both SDP programming and
dp_audio.c
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_audio.c | 100
drivers/gpu/drm/msm/dp/dp_catalog.h | 72
Wide bus is not supported when the mode is YUV420 in DP. In preparation
for changing the DPU programming to reflect this, the value and
assignment location of wide_bus_en for the DP submodules must be
changed. Move it from boot time in dp_init_sub_modules() to run time in
dp_display_mode_set.
1 - 100 of 160 matches
Mail list logo
