Am 12.01.24 um 13:51 schrieb Christian König:
From: Somalapuram Amaranath
Instead of a list of separate busy placement add flags which indicate
that a placement should only be used when there is room or if we need to
evict.
v2: add missing TTM_PL_FLAG_IDLE for i915
v3: fix auto build test ER
Am 16.01.24 um 19:50 schrieb Yangyu Chen:
Some platforms may not have any memory in ZONE_DMA32 and use IOMMU to allow
32-bit-DMA-only device to work. Forcing GFP_DMA32 on dummy_read_page will
fail on such platforms. Retry after fail will get this works on such
platforms.
Signed-off-by: Yangyu Ch
On Tue, 2024-01-16 at 12:44 -0600, Bjorn Helgaas wrote:
> On Mon, Jan 15, 2024 at 03:46:12PM +0100, Philipp Stanner wrote:
> > PCI's devres API is not extensible to ranged mappings and has
> > bug-provoking features. Improve that by providing better
> > alternatives.
>
> I guess "ranged mappings"
On Tue, 16 Jan 2024 17:10:18 +0100
Xaver Hugl wrote:
> My plan is to require support for IN_FENCE_FD at least. If the driver
> doesn't
> allow tearing with that, then tearing just doesn't happen.
That's an excellent point. I think this is important enough in its own
right, that it should be call
On Tue, 2024-01-16 at 23:34 +0200, andy.shevche...@gmail.com wrote:
> Mon, Jan 15, 2024 at 03:46:17PM +0100, Philipp Stanner kirjoitti:
> > 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,
>
>
On Tue, 2024-01-16 at 23:15 +0200, andy.shevche...@gmail.com wrote:
> Mon, Jan 15, 2024 at 03:46:12PM +0100, Philipp Stanner kirjoitti:
> > PCI's devres API is not extensible to ranged mappings and has
> > bug-provoking features. Improve that by providing better
> > alternatives.
> >
> > When the
On Tue, 16 Jan 2024 14:11:43 +
Andri Yngvason wrote:
> þri., 16. jan. 2024 kl. 13:29 skrifaði Sebastian Wick
> :
> >
> > On Tue, Jan 16, 2024 at 01:13:13PM +, Andri Yngvason wrote:
> [...]
> > > şri., 16. jan. 2024 kl. 11:42 skrifaği Sebastian Wick
> > > :
> > > >
> > > > On Mon, Jan
Hi,
On Tue, Jan 16, 2024 at 02:22:03PM -0800, Jessica Zhang wrote:
> This series introduces a simulated MIPI DSI panel.
>
> Currently, the only way to validate DSI connectors is with a physical
> panel. Since obtaining physical panels for all possible DSI configurations
> is logistically infeasib
On Tue, 16 Jan 2024 18:46:02 +0100, Michał Winiarski wrote:
> The original intent behind the test was to sanity check whether calling
> the debug iterator (drm_mm_print) doesn't cause any problems.
> Unfortunately - this call got accidentally removed during KUnit
> transition. Restore it.
>
>
Ap
Hi,
On Sun, Jan 14, 2024 at 04:23:38PM +0530, Dipam Turkar wrote:
> Introduce unit tests for the drm_mode_create_dvi_i_properties() function to
> ensure
> the proper creation of DVI-I specific connector properties and success if
> called
> multiple times.
>
> Signed-off-by: Dipam Turkar
> ---
On Tue, 2024-01-16 at 23:27 +0200, andy.shevche...@gmail.com wrote:
> Mon, Jan 15, 2024 at 03:46:13PM +0100, Philipp Stanner kirjoitti:
> > The old plural devres functions tie PCI's devres implementation to
> > the
> > iomap-table mechanism which unfortunately is not extensible.
> >
> > As the pur
On Tue, 09 Jan 2024 21:30:34 +0900,
Linus Walleij wrote:
>
> Hi Yoshinori,
>
> thanks for your patch!
>
> On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
> wrote:
>
> > + renesas,icr-irlm:
> > +$ref: /schemas/types.yaml#/definitions/flag
> > +description: If true four independent interr
Hi Sandor,
thanks for the update.
Am Mittwoch, 10. Januar 2024, 02:08:45 CET schrieb Sandor Yu:
> Add a new DRM DisplayPort and HDMI bridge driver for Candence MHDP8501
> used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
> standards according embedded Firmware running in the uCPU.
>
Hi Sandor,
thanks for the update.
Am Mittwoch, 10. Januar 2024, 02:08:48 CET schrieb Sandor Yu:
> Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ.
>
> Cadence HDP-TX PHY could be put in either DP mode or
> HDMI mode base on the configuration chosen.
> HDMI PHY mode is configurated in the driver.
On Mon, 15 Jan 2024 18:13:49 +0100, Michał Winiarski wrote:
> Add comments explaining the intention behind the test and certain
> implementation details related to device lifetime.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 15 Jan 2024 18:13:51 +0100, Michał Winiarski wrote:
> Add a simple test that checks whether the action is called when
> drmm_managed_release is called.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 15 Jan 2024 10:24:35 +0100, Alex Bee wrote:
> Commit d3e040f450ec ("drm/rockchip: inno_hdmi: Get rid of mode_set")
> started using drm_atomic_get_new_connector_state and
> drm_atomic_get_new_crtc_state which are defined in drm_atomic.h
> Building does currently only work if CONFIG_OF and CO
On Mon, 15 Jan 2024 18:13:47 +0100, Michał Winiarski wrote:
> Similar to devres equivalent, it allows to call the "release" action
> directly and remove the resource from the managed resources list.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 15 Jan 2024 18:13:48 +0100, Michał Winiarski wrote:
> DRM tests use "_" rather than "-" as word separator. Rename the test
> suite to match other tests.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 15 Jan 2024 18:13:50 +0100, Michał Winiarski wrote:
> It simplifies the process of extending the test suite with additional
> test cases without unnecessary duplication.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
Hi Maxime,
Am Mittwoch, 17. Januar 2024, 10:46:57 CET schrieb Maxime Ripard:
> On Mon, 15 Jan 2024 10:24:35 +0100, Alex Bee wrote:
> > Commit d3e040f450ec ("drm/rockchip: inno_hdmi: Get rid of mode_set")
> > started using drm_atomic_get_new_connector_state and
> > drm_atomic_get_new_crtc_state whi
On Tue, 2024-01-16 at 23:17 +0200, andy.shevche...@gmail.com wrote:
> Mon, Jan 15, 2024 at 03:46:11PM +0100, Philipp Stanner kirjoitti:
> > ¡Hola!
>
> i? Vim user? :-)
The Dark Side of the Force is the path to many abilities, that some
consider to be... unnatural
https://www.neo-layout.org/
>
>
Hi Sato-san,
On Wed, Jan 17, 2024 at 10:46 AM Yoshinori Sato
wrote:
> On Tue, 09 Jan 2024 21:30:34 +0900,
> Linus Walleij wrote:
> > On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
> > wrote:
> >
> > > + renesas,icr-irlm:
> > > +$ref: /schemas/types.yaml#/definitions/flag
> > > +descripti
On Wed, 17 Jan 2024, Maxime Ripard wrote:
> Hi,
>
> On Tue, Jan 16, 2024 at 02:22:03PM -0800, Jessica Zhang wrote:
>> This series introduces a simulated MIPI DSI panel.
>>
>> Currently, the only way to validate DSI connectors is with a physical
>> panel. Since obtaining physical panels for all po
Hi,
On 1/12/24 13:51, Christian König wrote:
Only convert it to ENOMEM in ttm_bo_validate.
This allows ttm_bo_validate to distinct between an out of memory
NIT: s/distinct/distinguish/
situation and just out of space in a placement domain.
In fact it would be nice if this could be propagate
From: Arnd Bergmann
With linux-6.8, the kernel warns about functions that have no
extern declaration, so mark both of these static.
Fixes: 2d782b0d007d ("gpu: drm: apple: Add sound mode parsing")
Signed-off-by: Arnd Bergmann
---
This is for the bits/200-dcp branch in https://github.com/AsahiLin
Hi, Christian
Xe changes look good. Will send the series to xe ci to check for
regressions.
/Thomas
On 1/12/24 13:51, Christian König wrote:
From: Somalapuram Amaranath
Instead of a list of separate busy placement add flags which indicate
that a placement should only be used when there is
Hi Daniel,
On 11/01/24 23:41, Daniel Stone wrote:
Hi Vignesh,
On Wed, 10 Jan 2024 at 10:47, Vignesh Raman wrote:
On 09/01/24 19:08, Daniel Stone wrote:
A better sequencing would be something like:
1. add ANX7625 config
2. refactor _existing_ MTK display jobs to use YAML includes, cha
Hi Vegard,
Le mardi 09 janvier 2024 à 14:08 +0100, Vegard Nossum a écrit :
> On 08/01/2024 13:00, Paul Cercueil wrote:
> > Add documentation for the three ioctls used to attach or detach
> > externally-created DMABUFs, and to request transfers from/to
> > previously
> > attached DMABUFs.
> >
> >
Reviewed-by: Qiang Yu
On Wed, Jan 17, 2024 at 3:14 PM Zhipeng Lu wrote:
>
> When lima_vm_map_bo fails, the resources need to be deallocated, or
> there will be memleaks.
>
> Fixes: 6aebc51d7aef ("drm/lima: support heap buffer creation")
> Signed-off-by: Zhipeng Lu
> ---
> Changelog:
>
> v2: rea
Hi Philipp,
On Thu, Jan 11, 2024 at 11:13:46AM +0100, Philipp Stanner wrote:
> The driver's memory regions are currently just ioremap()ed, but not
> reserved through a request. That's not a bug, but having the request is
> a little more robust.
>
> Implement the region-request through the corresp
art of the cake, we can merge them all
at once.
This is obviously for 5.9, and based on next-20240117.
Changelog:
- [3/4]:
- Protect the dmabufs list with a mutex
- Use incremental sequence number for the dma_fences
- Unref attachments and DMABUFs in workers
- Remove dead code in ffs_dma
Add a new 'sg_was_mapped' field to the struct usb_request. This field
can be used to indicate that the scatterlist associated to the USB
transfer has already been mapped into the DMA space, and it does not
have to be done internally.
Signed-off-by: Paul Cercueil
---
drivers/usb/gadget/udc/core.c
This exact same code was duplicated in two different places.
Signed-off-by: Paul Cercueil
---
drivers/usb/gadget/function/f_fs.c | 48 +-
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/
This patch introduces three new ioctls. They all should be called on a
data endpoint (ie. not ep0). They are:
- FUNCTIONFS_DMABUF_ATTACH, which takes the file descriptor of a DMABUF
object to attach to the endpoint.
- FUNCTIONFS_DMABUF_DETACH, which takes the file descriptor of the
DMABUF to
Add documentation for the three ioctls used to attach or detach
externally-created DMABUFs, and to request transfers from/to previously
attached DMABUFs.
Signed-off-by: Paul Cercueil
---
v3: New patch
---
Documentation/usb/functionfs.rst | 36
1 file changed, 36
Hi Philipp,
Several minor comments below.
On Thu, Jan 11, 2024 at 11:13:47AM +0100, Philipp Stanner wrote:
> dcss currently allocates and ioremaps quite a few resources in its probe
> function's call graph. Devres now provides convenient functions which
> perform the same task but do the cleanup
On 1/17/24 11:47, Thomas Hellström wrote:
Hi, Christian
Xe changes look good. Will send the series to xe ci to check for
regressions.
Hmm, there are some checkpatch warnings about author / SOB email mismatch,
But worserthere are some regressions in the dma-buf ktest (it tests
evicting of
Set the firmware framebuffer's parent device, which usually is the
graphics hardware's physical device. Integrates the framebuffer in
the Linux device hierarchy and lets Linux handle dependencies among
devices. For example, the graphics hardware won't be suspended while
the firmware device is still
Detect the firmware framebuffer's parent device from the global
screen_info state and set up the framebuffer's device accordingly.
Remove the equivalent functionality from efifb. Other drivers for
firmware framebuffers, such as simpledrm or vesafb, now add these
new features.
Patches 1 and 2 provi
The plain values as stored in struct screen_info need to be decoded
before being used. Add helpers that decode the type of video output
and the framebuffer I/O aperture.
Old or non-x86 systems may not set the type of video directly, but
only indicate the presence by storing 0x01 in orig_video_isVG
The EFI device has the correct parent device set. This allows Linux
to handle the power management internally. Hence, remove the manual
PM management for the parent device from efifb.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/efifb.c | 16 +++-
1 file changed, 3 insert
On ARM PCI systems, the PCI hierarchy might be reconfigured during
boot and the firmware framebuffer might move as a result of that.
The values in screen_info will then be invalid.
Work around this problem by tracking the framebuffer's initial
location before it get relocated; then fix the screen_
Add screen_info_get_pci_dev() to find the PCI device of an instance
of screen_info. Does nothing on systems without PCI bus.
Signed-off-by: Thomas Zimmermann
---
drivers/video/Makefile | 1 +
drivers/video/screen_info_pci.c | 54 +
include/linux/screen_i
There will be no EFI framebuffer device for disabled parent devices
and thus we never probe efifb in that case. Hence remove the tracking
code from efifb.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/efifb.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/driv
Test if the firmware framebuffer's parent PCI device, if any, has
been enabled. If not, the firmware framebuffer is most likely not
working. Hence, do not create a device for the firmware framebuffer
on disabled PCI devices.
So far, efifb tracked the status of the PCI parent device internally
and
If the firmware framebuffer has been reloacted, the sysfb code
fixes the screen_info state before it creates the framebuffer's
platform device. Efifb will automatically receive a screen_info
with updated values. Hence remove the tracking from efifb.
Signed-off-by: Thomas Zimmermann
---
drivers/v
Am Mi., 17. Jan. 2024 um 09:55 Uhr schrieb Pekka Paalanen :
> Is it important enough to be special-cased, e.g. to be always allowed
> with async commits?
I thought so, and sent a patch to dri-devel to make it happen, but
there are some
concerns about untested driver paths.
https://lists.freedeskto
mið., 17. jan. 2024 kl. 09:21 skrifaði Pekka Paalanen :
>
> On Tue, 16 Jan 2024 14:11:43 +
> Andri Yngvason wrote:
>
> > þri., 16. jan. 2024 kl. 13:29 skrifaði Sebastian Wick
> > :
> > >
> > > On Tue, Jan 16, 2024 at 01:13:13PM +, Andri Yngvason wrote:
> > [...]
> > > > şri., 16. jan. 2024
Am 17.01.24 um 13:26 schrieb Paul Cercueil:
This patch introduces three new ioctls. They all should be called on a
data endpoint (ie. not ep0). They are:
- FUNCTIONFS_DMABUF_ATTACH, which takes the file descriptor of a DMABUF
object to attach to the endpoint.
- FUNCTIONFS_DMABUF_DETACH, whic
On Wed, Jan 17, 2024 at 10:52:04AM +0100, Heiko Stübner wrote:
> Hi Maxime,
>
> Am Mittwoch, 17. Januar 2024, 10:46:57 CET schrieb Maxime Ripard:
> > On Mon, 15 Jan 2024 10:24:35 +0100, Alex Bee wrote:
> > > Commit d3e040f450ec ("drm/rockchip: inno_hdmi: Get rid of mode_set")
> > > started using d
On Tue, 2024-01-16 at 23:40 +0200, andy.shevche...@gmail.com wrote:
> Mon, Jan 15, 2024 at 03:46:20PM +0100, Philipp Stanner kirjoitti:
> > Thanks to preceding cleanup steps, pcim_release() is now not needed
> > anymore and can be replaced by pcim_disable_device(), which is the
> > exact
> > counte
On 13/01/2024 01:42, Anatoliy Klymenko wrote:
Assign device of node to bridge prior registering it. This will
make said bridge discoverable by separate crtc driver.
I think a few words on why this is needed (and why it wasn't needed
before) would be nice.
Other than that:
Reviewed-by: Tomi
On 13/01/2024 01:42, Anatoliy Klymenko wrote:
Expect external video timing in live video input mode, program
DPSUB accordingly.
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zyn
On 2024-01-17 13:57, Xaver Hugl wrote:
> Am Mi., 17. Jan. 2024 um 09:55 Uhr schrieb Pekka Paalanen
> :
>> Is it important enough to be special-cased, e.g. to be always allowed
>> with async commits?
>
> I thought so, and sent a patch to dri-devel to make it happen, but
> there are some
> concerns
On 13/01/2024 01:42, Anatoliy Klymenko wrote:
Filter out status register against interrupts' mask.
Some events are being reported via DP status register, even if
corresponding interrupts have been disabled. Avoid processing
of such events in interrupt handler context.
The subject talks about vb
Am Mittwoch, 17. Januar 2024, 14:47:48 CET schrieb Maxime Ripard:
> On Wed, Jan 17, 2024 at 10:52:04AM +0100, Heiko Stübner wrote:
> > Hi Maxime,
> >
> > Am Mittwoch, 17. Januar 2024, 10:46:57 CET schrieb Maxime Ripard:
> > > On Mon, 15 Jan 2024 10:24:35 +0100, Alex Bee wrote:
> > > > Commit d3e04
On Mon, Jan 15, 2024 at 09:28:39AM +0100, Maxime Ripard wrote:
> On Fri, Jan 12, 2024 at 03:42:18PM -0800, Anatoliy Klymenko wrote:
> > Patches 1/4,2/4,3/4 are minor fixes.
> >
> > DPSUB requires input live video format to be configured.
> > Patch 4/4: The DP Subsystem requires the input live vide
On Wed, Jan 17, 2024 at 04:06:31PM +0200, Tomi Valkeinen wrote:
> On 13/01/2024 01:42, Anatoliy Klymenko wrote:
> > Assign device of node to bridge prior registering it. This will
> > make said bridge discoverable by separate crtc driver.
>
> I think a few words on why this is needed (and why it w
On 12/01/2024 14:41, Daniel Vetter wrote:
On Thu, Jan 04, 2024 at 05:00:49PM +0100, Jocelyn Falempe wrote:
This was initialy done for imx6, but should work on most drivers
using drm_fb_dma_helper.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_fb_dma_helper.c | 55
Inside the if block with (running == 0), the checks for 'running'
possibly being non-zero are redundant. Remove them altogether.
This change is similar to the one authored by Heinrich Schuchardt
in commit
ddbbd3be9679 ("drm/radeon: remove dead code, si_mc_load_microcode (v2)")
Found by Linux Ver
'leakage_table' will always be successfully initialized as a pointer
to '&rdev->pm.dpm.dyn_state.cac_leakage_table'.
Remove unnecessary check if only to silence static checkers.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool Svace.
Fixes: 69e0b57a91ad ("drm/radeo
Hi
Am 04.01.24 um 17:00 schrieb Jocelyn Falempe:
This is needed for drm_panic, to draw the font, and fill
the background color, in multiple color format.
TBH, I don't like this patch at all. It looks like you're reimplementing
existing functionality for a single use case; specifically drm_fb_
Hi
Am 04.01.24 um 17:00 schrieb Jocelyn Falempe:
Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.
v5:
* Also check that the plane is visible and primary. (Thomas Zimmermann)
v7:
* use drm_for_each_primary_visible_plane()
Signed-off-b
Hi
Am 04.01.24 um 17:00 schrieb Jocelyn Falempe:
Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.
v7
* Use drm_for_each_primary_visible_plane()
Signed-off-by: Jocelyn Falempe
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/as
Am 04.01.24 um 17:00 schrieb Jocelyn Falempe:
Add support for the drm_panic module, which displays a user-friendly
message to the screen when a kernel panic occurs.
Signed-off-by: Jocelyn Falempe
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 15 +++
Hi
Am 12.01.24 um 14:58 schrieb Maxime Ripard:
On Fri, Jan 12, 2024 at 02:44:57PM +0100, Daniel Vetter wrote:
On Thu, Jan 04, 2024 at 05:00:50PM +0100, Jocelyn Falempe wrote:
Add support for the drm_panic module, which displays a user-friendly
message to the screen when a kernel panic occurs.
On Thu, 04 Jan 2024, Jocelyn Falempe wrote:
> This is needed for drm_panic, to draw the font, and fill
> the background color, in multiple color format.
>
> v5:
> * Change the drawing API, use drm_fb_blit_from_r1() to draw the font.
> * Also add drm_fb_fill() to fill area with background color.
Hi Werner,
Once again, sorry for the very slow response here.
On 11/27/23 11:59, Werner Sembach wrote:
> Hi Hans,
>
> Am 22.11.23 um 19:34 schrieb Hans de Goede:
>> Hi Werner,
> [snip]
> Another idea I want to throw in the mix:
>
> Maybe the kernel is not the right place to implement
Hi Anatoliy,
On 13/01/2024 01:42, Anatoliy Klymenko wrote:
Live video input format is expected to be set as
"bus-format" property in connected remote endpoint.
Program live video input format DPSUB registers.
Set display layer mode in layer creation context.
Some comments inline below. But one
On Wed, Jan 17, 2024 at 02:43:00AM +, dharm...@microchip.com wrote:
> On 17/01/24 1:40 am, Alexandre Belloni wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On 16/01/2024 18:03:19+, Conor Dooley wrote:
> >> On Tue, Jan 16,
Hi
Am 04.01.24 um 17:00 schrieb Jocelyn Falempe:
[...]
+ /**
+* @get_scanout_buffer:
+*
+* Get the current scanout buffer, to display a panic message with
drm_panic.
+* The driver should do the minimum changes to provide a linear buffer,
that
+* can b
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 @@ target-module@5600 {
;
ti,sysc-sidle = ,
On 17/01/2024 16:06, Thomas Zimmermann wrote:
Hi
Am 04.01.24 um 17:00 schrieb Jocelyn Falempe:
This is needed for drm_panic, to draw the font, and fill
the background color, in multiple color format.
TBH, I don't like this patch at all. It looks like you're reimplementing
existing functio
On 17/01/2024 16:26, Jani Nikula wrote:
On Thu, 04 Jan 2024, Jocelyn Falempe wrote:
This is needed for drm_panic, to draw the font, and fill
the background color, in multiple color format.
v5:
* Change the drawing API, use drm_fb_blit_from_r1() to draw the font.
* Also add drm_fb_fill()
Hi All,
On 11/27/23 11:59, Werner Sembach wrote:
> I also stumbled across a new Problem:
>
> We have an upcoming device that has a per-key keyboard backlight, but does
> the control completely via a wmi/acpi interface. So no usable hidraw here for
> a potential userspace driver implementatio
Hi,
On Tue, Jan 9, 2024 at 8:52 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Jan 9, 2024 at 4:05 AM Pin-yen Lin wrote:
> >
> > The ps8640 bridge seems to expect everything to be power cycled at the
> > disable process, but sometimes ps8640_aux_transfer() holds the runtime
> > PM reference and pre
Hi Jani and Maxime
On 1/17/2024 2:16 AM, Jani Nikula wrote:
On Wed, 17 Jan 2024, Maxime Ripard wrote:
Hi,
On Tue, Jan 16, 2024 at 02:22:03PM -0800, Jessica Zhang wrote:
This series introduces a simulated MIPI DSI panel.
Currently, the only way to validate DSI connectors is with a physical
p
MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At
current implementation, at DP_TEST_DYNAMIC_RANGE_CEA case the
Colorimetry Indicator Field is mistakenly left shifted one extra
bit. This patch return correct value of colorimetry at
dp_link_get_colorimetry_config() to fix this problem.
DMA buffers allocated from the CMA dma-buf heap get counted under
RssFile for processes that map them and trigger page faults. In
addition to the incorrect accounting reported to userspace, reclaim
behavior was influenced by the MM_FILEPAGES counter until linux 6.8, but
this memory is not reclaimab
On Wed, 17 Jan 2024 at 19:54, Kuogee Hsieh wrote:
>
> MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At
> current implementation, at DP_TEST_DYNAMIC_RANGE_CEA case the
In the current implementation, in the ... case
> Colorimetry Indicator Field is mistakenly left shifted one extra
>
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> In case a task manages to complete but it took just long enough to also
> trigger the timeout handler, the current code results in a refcount
> imbalance on lima_pm_idle.
>
> While this can be a rare occurrence, when it happens it may fill use
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> Lima pp jobs use an async reset to avoid having to wait for the soft
> reset right after a job. The soft reset is done at the end of a job and
> a reset_complete flag is expected to be set at the next job.
> However, in case the user runs into
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> This is required for reliable hard resets. Otherwise, doing a hard reset
> while a task is still running (such as a task which is being stopped by
> the drm_sched timeout handler) may result in random mmu write timeouts
> or lockups which caus
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> There are several unexplained and unreproduced cases of rendering
> timeouts with lima, for which one theory is high IRQ latency coming from
> somewhere else in the system.
> This kind of occurrence may cause applications to trigger unnecessar
On 1/17/2024 10:12 AM, Dmitry Baryshkov wrote:
On Wed, 17 Jan 2024 at 19:54, Kuogee Hsieh wrote:
MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At
current implementation, at DP_TEST_DYNAMIC_RANGE_CEA case the
In the current implementation, in the ... case
Colorimetry Indicator
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> Marking the context as guilty currently only makes the application which
> hits a single timeout problem to stop its rendering context entirely.
> All jobs submitted later are dropped from the guilty context.
>
> Lima runs on fairly underpower
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> Make the messages more consistent by showing the pp name.
>
> Signed-off-by: Erico Nunes
Reviewed-by: Vasily Khoruzhick
> ---
> drivers/gpu/drm/lima/lima_pp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/d
After commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
is suspended in .post_disable()"), if we hit the error case in
ps8640_aux_transfer() then we return without dropping the mutex. Fix
this oversight.
Fixes: 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge is suspended in
.
Hi,
On Wed, Jan 17, 2024 at 9:34 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Jan 9, 2024 at 8:52 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Jan 9, 2024 at 4:05 AM Pin-yen Lin wrote:
> > >
> > > The ps8640 bridge seems to expect everything to be power cycled at the
> > > disable process
On Wed, 17 Jan 2024 at 20:29, Kuogee Hsieh wrote:
>
>
> On 1/17/2024 10:12 AM, Dmitry Baryshkov wrote:
> > On Wed, 17 Jan 2024 at 19:54, Kuogee Hsieh wrote:
> >> MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At
> >> current implementation, at DP_TEST_DYNAMIC_RANGE_CEA case the
> > In
This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.
I plan to use it in amdgpu.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence.c | 1 +
include/trace/events/dma_fence.h | 34
2 f
This makes it possible to understand the dependencies between jobs.
Possible usage of this trace:
* stuttering issues like Mesa !9189
* incorrect synchronization: I don't have a link for this one, but having
these events was very useful to debug a virtio-gpu / native-context /
radeonsi sync iss
On 1/17/2024 10:40 AM, Dmitry Baryshkov wrote:
On Wed, 17 Jan 2024 at 20:29, Kuogee Hsieh wrote:
On 1/17/2024 10:12 AM, Dmitry Baryshkov wrote:
On Wed, 17 Jan 2024 at 19:54, Kuogee Hsieh wrote:
MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At
current implementation, at DP_TES
> kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure. Ensure the allocation was successful
> by checking the pointer validity.
…
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -144,6 +144,10 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu,
>
On Wed, Jan 17, 2024 at 10:35 AM Douglas Anderson wrote:
>
> After commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
> is suspended in .post_disable()"), if we hit the error case in
> ps8640_aux_transfer() then we return without dropping the mutex. Fix
> this oversight.
>
> Fixes: 26d
The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback
in case of YUV output") introduced a smatch warning about another
conditional block in dpu_encoder_helper_phys_cleanup() which had assumed
hw_pp will always be valid which may not necessarily be true.
Lets fix the other condit
Hi,
Le mercredi 06 décembre 2023 à 16:15 +0800, Yunfei Dong a écrit :
> From: Jeffrey Kardatzke
>
> Adds documentation for V4L2_MEMORY_FLAG_SECURE.
As I noticed from DMA Heap discussions, shall this also be renamed SECURE ->
RESTRICTED ?
regards,
Nicolas
>
> Signed-off-by: Jeffrey Kardatzke
Hi,
On Wed, Jan 17, 2024 at 11:39 AM Hsin-Yi Wang wrote:
>
> On Wed, Jan 17, 2024 at 10:35 AM Douglas Anderson
> wrote:
> >
> > After commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
> > is suspended in .post_disable()"), if we hit the error case in
> > ps8640_aux_transfer() then
On Tue, Jan 16, 2024 at 07:11:40PM +0530, Devarsh Thakkar wrote:
> Add support for using TI Keystone DSS hardware present in display
> sharing mode.
>
> TI Keystone DSS hardware supports partitioning of resources between
> multiple hosts as it provides separate register space and unique
> interrup
1 - 100 of 171 matches
Mail list logo
