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 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
>
>
> 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 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
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ć
---
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
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
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
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
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
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
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
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
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
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
-
- 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
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
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
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
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
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 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 [李琼斯]
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
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:
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
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
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 |
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
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
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)
>>
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
---
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 ++--
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
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.
[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 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 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 +++-
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
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, 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 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 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
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 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.
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 Fri, 5 Jan 2024 21:46:17 +0300
Dmitry Osipenko wrote:
> Export drm_gem_shmem_get_pages_sgt_locked() that will be used by virtio-gpu
> shrinker during GEM swap-in operation done under the held reservation lock.
>
Nit: I'd move that patch before "drm/shmem-helper: Add common memory
On Fri, 5 Jan 2024 21:46:16 +0300
Dmitry Osipenko wrote:
> *
> * This function Increases the use count and allocates the backing pages if
> * use-count equals to zero.
> + *
> + * Note that this function doesn't pin pages in memory. If your driver
> + * uses drm-shmem shrinker, then it's
Ah, I see that Mario already posted a patch for a "frozen desktop" problem here:
https://lore.kernel.org/lkml/caovelgsczkyhj61t8szc2ck1cjy2izv6urva2422kcfy8on...@mail.gmail.com/T/#t
and I can confirm that patch fixes my problem as well. Sorry for the noise.
Thanks,
Paul
On Wed, Jan 24, 2024 at
I forgot to say what graphics driver I'm using. It is amdgpu.
p.s. Sorry for the bad formatting in my previous email, it has been a while
since I posted to LKML.
Thanks,
Paul
On Wed, Jan 24, 2024 at 12:47 PM Paul Zimmerman wrote:
>
> When I attempt to connect via VNC or RDP to my Ubuntu
When I attempt to connect via VNC or RDP to my Ubuntu desktop, the Wayland
server seems to hang. The desktop GUI no longer works either locally or
remotely. I can still log in via ssh, so the system is still alive,
but the GUI is
frozen. If I boot into Xorg instead, everything works fine. Kernel
The comments explaining the function "drm_dp_mst_atom_check_mgr()" had
uneven indentation which made "make htmldocs" complain:
Documentation/gpu/drm-kms-helpers:296:
./drivers/gpu/drm/display/drm_dp_mst_topology.c:5496:
ERROR: Unexpected indentation.
Hi, Dave, Sima
The Xe fixes PR for 6.8-rc2.
Thanks, Thomas.
The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d:
Linux 6.8-rc1 (2024-01-21 14:11:32 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/xe/kernel.git
> > If the lvds pll is an input to the hlcdc, you need to add it here.
> > From your description earlier it does sound like it is an input to
> > the hlcdc, but now you are claiming that it is not.
>
> The LVDS PLL serves as an input to both the LCDC and LVDSC
Then it should be an input to
On Fri, 5 Jan 2024 21:46:12 +0300
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
On Fri, 5 Jan 2024 21:46:08 +0300
Dmitry Osipenko wrote:
> We're going to move away from having implicit get_pages() done by
> get_pages_sgt() to ease simplify refcnt handling. Drivers will manage
> get/put_pages() by themselves. Add drm_gem_shmem_put_pages().
>
> Signed-off-by: Dmitry
On Fri, 5 Jan 2024 21:46:09 +0300
Dmitry Osipenko wrote:
> All drivers will be moved to get/put pages explicitly and then the last
> put_pages() will be invoked during gem_free() time by some drivers.
> We can't touch reservation lock when GEM is freed because that will cause
> a spurious
On Fri, 5 Jan 2024 21:46:07 +0300
Dmitry Osipenko wrote:
> We're going to move away from having implicit get_pages() done by
> get_pages_sgt() to simplify refcnt handling. Drivers will manage
> get/put_pages() by themselves. Expose the drm_gem_shmem_get_pages()
> in a public drm-shmem API.
>
>
On Fri, 5 Jan 2024 21:46:06 +0300
Dmitry Osipenko wrote:
> Prepare drm_gem_shmem_free() to addition of memory shrinker support
> to drm-shmem by adding and using variant of put_pages() that doesn't
> touch reservation lock. Reservation shouldn't be touched because lockdep
> will trigger a bogus
101 - 160 of 160 matches
Mail list logo
