[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390

https://bugzilla.kernel.org/show_bug.cgi?id=216119 Mario Limonciello (AMD) (mario.limoncie...@amd.com) changed: What|Removed |Added CC|

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

On Mon, Aug 8, 2022 at 5:13 AM Adam Ford wrote: > > On Mon, Aug 8, 2022 at 3:54 AM Marco Felsch wrote: > > > > On 22-08-07, Adam Ford wrote: > > > On Fri, Aug 5, 2022 at 4:05 PM Adam Ford wrote: > > > > > > > > On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote: > > > > > > > > > > On Fri, Aug 5,

Re: [PATCH v2] drm/gem: Fix GEM handle release errors

Hi Christian, On 8/9 星期二 2:03, Christian König wrote: Hi Jeffy, Am 08.08.22 um 05:51 schrieb Chen Jeffy: Hi Christian, Thanks for your reply, and sorry i didn't make it clear. On 8/8 星期一 0:52, Christian König wrote: Am 03.08.22 um 10:32 schrieb Jeffy Chen: Currently we are assuming a one

Re: [PATCH v3 2/4] dt-bindings: display: add new bus-format property for panel-dpi

On 8/8/22 15:56, Max Krummenacher wrote: Hi Marek Hello Max, [...] +properties: + bus-format: +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 0x1001 +maximum: 0x1fff +description: | + Describes how the

Re: [PATCH] drm/gem: Fix GEM handle release errors

Hi Christian, Sorry, i've sent a v2 before, please check that. On 8/9 星期二 2:05, Christian König wrote: Am 02.08.22 um 13:33 schrieb Jeffy Chen: Currently we are assuming a one to one mapping between dmabuf and handle when releasing GEM handles. But that is not always true, since we would

[RFC] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge

adv7533 bridge tries to dynamically switch lanes based on the mode by detaching and attaching the mipi dsi device. This approach is incorrect because as per the DSI spec the number of lanes is fixed at the time of system design or initial configuration and may not change dynamically. In addition

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()

On Tue, 2022-08-09 at 01:09 +0200, Andi Shyti wrote: > Hi Rodrigo, > > On Mon, Aug 08, 2022 at 03:04:13PM -0400, Rodrigo Vivi wrote: > > On Mon, Aug 08, 2022 at 06:37:58PM +0200, Andi Shyti wrote: > > > Hi Mauro, > > > > > > On Thu, Aug 04, 2022 at 09:37:22AM +0200, Mauro Carvalho Chehab > > >

[RFC v2 18/18] drm/display/dp_mst: Move all payload info into the atomic state

Now that we've finally gotten rid of the non-atomic MST users leftover in the kernel, we can finally get rid of all of the legacy payload code we have and move as much as possible into the MST atomic state structs. The main purpose of this is to make the MST code a lot less confusing to work on,

[RFC v2 16/18] drm/display/dp_mst: Maintain time slot allocations when deleting payloads

Currently, we set drm_dp_atomic_payload->time_slots to 0 in order to indicate that we're about to delete a payload in the current atomic state. Since we're going to be dropping all of the legacy code for handling the payload table however, we need to be able to ensure that we still keep track of

[RFC v2 17/18] drm/radeon: Drop legacy MST support

Right now, radeon is technically the only non-atomic driver still making use of the MST helpers - and thus the final user of all of the legacy MST helpers. Originally I was going to look into seeing if we could move legacy MST into the radeon driver itself, however: * SI and CIK both can use

[RFC v2 13/18] drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions

There's another kind of situation where we could potentially race with nonblocking modesets and MST, especially if we were to only use the locking provided by atomic modesetting: * Display 1 begins as enabled on DP-1 in SST mode * Display 1 switches to MST mode, exposes one sink in MST mode *

[RFC v2 14/18] drm/display/dp_mst: Drop all ports from topology on CSNs before queueing link address work

We want to start cutting down on all of the places that we use port validation, so that ports may be removed from the topology as quickly as possible to minimize the number of errors we run into as a result of being out of sync with the current topology status. This isn't a very typical scenario

[RFC v2 15/18] drm/display/dp_mst: Skip releasing payloads if last connected port isn't connected

In the past, we've ran into strange issues regarding errors in response to trying to destroy payloads after a port has been unplugged. We fixed this back in: This is intended to replace the workaround that was added here: commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports

[RFC v2 12/18] drm/nouveau/kms: Pull mst state in for all modesets

Since we're going to be relying on atomic locking for payloads now (and the MST mgr needs to track CRTCs), pull in the topology state for all modesets in nv50_msto_atomic_check(). Signed-off-by: Lyude Paul Acked-by: Jani Nikula --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- 1 file

[RFC v2 11/18] drm/nouveau/kms: Cache DP encoders in nouveau_connector

Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia GPUs are SORs (serial output resources). Because SORs have fixed associations with their connectors, we can correctly assume that any DP connector on a nvidia GPU will have exactly one SOR encoder routed to it for

[RFC v2 10/18] drm/display/dp_mst: Fix modeset tracking in drm_dp_atomic_release_vcpi_slots()

Currently with the MST helpers we avoid releasing payloads _and_ avoid pulling in the MST state if there aren't any actual payload changes. While we want to keep the first step, we need to now make sure that we're always pulling in the MST state on all modesets that can modify payloads - even if

[RFC v2 09/18] drm/display/dp_mst: Don't open code modeset checks for releasing time slots

I'm not sure why, but at the time I originally wrote the find/release time slot helpers I thought we should avoid keeping modeset tracking out of the MST helpers. In retrospect though there's no actual good reason to do this, and the logic has ended up being identical across all the drivers using

[RFC v2 08/18] drm/display/dp_mst: Add nonblocking helpers for DP MST

As Daniel Vetter pointed out, if we only use the atomic modesetting locks with MST it's technically possible for a driver with non-blocking modesets to race when it comes to MST displays - as we make the mistake of not doing our own CRTC commit tracking in the topology_state object. This could

[RFC v2 07/18] drm/display/dp_mst: Add helper for finding payloads in atomic MST state

We already open-code this quite often, and will be iterating through payloads even more once we've moved all of the payload tracking into the atomic state. So, let's add a helper for doing this. Signed-off-by: Lyude Paul Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc:

[RFC v2 05/18] drm/display/dp_mst: Fix confusing docs for drm_dp_atomic_release_time_slots()

For some reason we mention returning 0 if "slots have been added back to drm_dp_mst_topology_state->avail_slots". This is totally misleading, avail_slots is simply for figuring out the total number of slots available in total on the topology and has no relation to the current payload allocations.

[RFC v2 04/18] drm/display/dp_mst: Call them time slots, not VCPI slots

VCPI is only sort of the correct term here, originally the majority of this code simply referred to timeslots vaguely as "slots" - and since I started working on it and adding atomic functionality, the name "VCPI slots" has been used to represent time slots. Now that we actually have consistent

[RFC v2 06/18] drm/display/dp_mst: Add some missing kdocs for atomic MST structs

Since we're about to start adding some stuff here, we may as well fill in any missing documentation that we forgot to write. Signed-off-by: Lyude Paul Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc: Imre Deak Cc: Daniel Vetter Cc: Sean Paul Acked-by: Jani Nikula ---

[RFC v2 03/18] drm/display/dp_mst: Rename drm_dp_mst_vcpi_allocation

In retrospect, the name I chose for this originally is confusing, as there's a lot more info in here then just the VCPI. This really should be called a payload. Let's make it more obvious that this is meant to be related to the atomic state and is about payloads by renaming it to

[RFC v2 02/18] drm/amdgpu/dm/mst: Rename get_payload_table()

This function isn't too confusing if you see the comment around the call-site for it, but if you don't then it's not at all obvious this is meant to copy DRM's payload table over to DC's internal state structs. Seeing this function before finding that comment definitely threw me into a loop a few

[RFC v2 01/18] drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)

Just to make this more clear to outside contributors that these are DC-specific structs, as this also threw me into a loop a number of times before I figured out the purpose of this. Signed-off-by: Lyude Paul Cc: Wayne Lin Cc: Fangzhi Zuo Acked-by: Jani Nikula ---

[RFC v2 00/18] drm/display/dp_mst: Drop Radeon MST support, make MST atomic-only

For quite a while we've been carrying around a lot of legacy modesetting code in the MST helpers that has been rather annoying to keep around, and very often gets in the way of trying to implement additional functionality in MST such as fallback link rate retraining, dynamic BPC management and DSC

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()

Hi Rodrigo, On Mon, Aug 08, 2022 at 03:04:13PM -0400, Rodrigo Vivi wrote: > On Mon, Aug 08, 2022 at 06:37:58PM +0200, Andi Shyti wrote: > > Hi Mauro, > > > > On Thu, Aug 04, 2022 at 09:37:22AM +0200, Mauro Carvalho Chehab wrote: > > > WRITE_ONCE() should happen at the original var, not on a

Re: [RESEND RFC 06/18] drm/display/dp_mst: Add some missing kdocs for atomic MST structs

Also JFYI - I did see this comment but didn't address it in my respin, but only because I figured this might be better for a followup patch considering how much work is already in here On Wed, 2022-06-15 at 04:43 +, Lin, Wayne wrote: > I would prefer not using the term "available" which is a

Re: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info into the atomic state

On Mon, 2022-08-08 at 10:02 +, Lin, Wayne wrote: > [Public] > > > > > -Original Message- > > From: Lyude Paul > > Sent: Thursday, August 4, 2022 4:28 AM > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org; > > nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org > > Cc:

[Bug 100871] radeon fails to initialize one DisplayPort monitor

https://bugzilla.kernel.org/show_bug.cgi?id=100871 --- Comment #18 from Charles R. Anderson (c...@fea.st) --- I believe the PCI ID is 1002:68f1: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cedar GL [FirePro 2460] [1002:68f1] (prog-if 00 [VGA controller]) --

[PATCH] drm/amd/display: include soc._clock_tmp[] into DC's scratch region

Currently, we are using soc._clock_tmp[] to temporarily store and modify data from soc.clock_limits[] before copying it back into soc.clock_limits[] (because modifying data directly in soc.clock_limits[] causes unintended behavior). However, this approch has a number of downsides, such as:

[Bug 100871] radeon fails to initialize one DisplayPort monitor

https://bugzilla.kernel.org/show_bug.cgi?id=100871 --- Comment #17 from Charles R. Anderson (c...@fea.st) --- Still a problem on Fedora 36 / Linux kernel 5.18.16-200.fc36.x86_64. I'm now using two newer monitors (DELL U3219Q) connected via DP instead of the previous four monitors (2 DP, 2 DVI)

[PATCH v3 2/2] drm/panel/tianma-tl057fvxp01: add panel for Motorola Moto G6

This is a 5.7" 2160x1080 panel found on the Motorola Moto G6. There may be other smartphones using it, as well. Signed-off-by: Julian Braha --- v3: Fixed kconfig dependencies. v2: Fixed accidental whitespace deletion. --- drivers/gpu/drm/panel/Kconfig | 9 +

[PATCH v3 1/2] dt-bindings: panel-simple-dsi: add Tianma TL057FVXP01

Adds the bindings for the Tianma TL057FVXP01 DSI panel, found on the Motorola Moto G6. Signed-off-by: Julian Braha --- v3: Fixed kconfig dependencies. v2: Fixed accidental whitespace deletion. --- .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++ 1 file changed, 2

Re: FYI: misc: visconti: Toshiba Visconti DSP accelerator driver sample

On Fri, Aug 5, 2022 at 1:41 PM Yuji Ishikawa wrote: > > Hello Odded > > This is a sample (wip) driver for a DSP found on Toshiba Visconti SoC. > The DSP typically accepts some images, apply an algorithm on them and yields > resulting one. > Therefore (image-in, image-out), they say this driver

Re: [PATCH v9 1/3] i915/gvt: Separate the MMIO tracking table from GVT-g

On Thu, 7 Apr 2022 03:19:43 -0400 Zhi Wang wrote: > From: Zhi Wang > > To support the new mdev interfaces and the re-factor patches from > Christoph, which moves the GVT-g code into a dedicated module, the GVT-g > MMIO tracking table needs to be separated from GVT-g. > Since this commit I'm

Re: New subsystem for acceleration devices

On Mon, Aug 8, 2022 at 8:46 PM Jason Gunthorpe wrote: > > On Sun, Aug 07, 2022 at 09:43:40AM +0300, Oded Gabbay wrote: > > > 1. If there is a subsystem which is responsible for creating and > > exposing the device character files, then there should be some code > > that connects between each

Re: [PATCH v2 00/14] drm/format-helper: Move to struct iosys_map

Den 08.08.2022 14.53, skrev Thomas Zimmermann: > Change format-conversion helpers to use struct iosys_map for source > and destination buffers. Update all users. Also prepare interface for > multi-plane color formats. > > The format-conversion helpers mostly used to convert to I/O memory > or

Re: [PATCH RFC] dma-buf: To check DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT status on debug

Am 04.08.22 um 14:19 schrieb Arvind Yadav: If core DMA-buf framework forgets to call dma_fence_enable_signaling() before calling the dma_fence_is_signaled(). To handle this scenario on debug kernel the DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT needs to be checked before checking the actual signaling

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()

On Mon, Aug 08, 2022 at 06:37:58PM +0200, Andi Shyti wrote: > Hi Mauro, > > On Thu, Aug 04, 2022 at 09:37:22AM +0200, Mauro Carvalho Chehab wrote: > > WRITE_ONCE() should happen at the original var, not on a local > > copy of it. > > > > Fixes: 5d36acb7198b ("drm/i915/gt: Batch TLB

Re: [PATCH v2 14/14] drm/format-helper: Rename parameter vmap to src

Hi Thomas, On Mon, Aug 08, 2022 at 02:54:06PM +0200, Thomas Zimmermann wrote: > The name the parameter vmap to src in all functions. The parameter > contains the locations of the source data and the new name says that. > > Signed-off-by: Thomas Zimmermann Thanks, this helped in readability!

Re: [PATCH v2 00/14] drm/format-helper: Move to struct iosys_map

Hi Thomas, On Mon, Aug 08, 2022 at 02:53:52PM +0200, Thomas Zimmermann wrote: > Change format-conversion helpers to use struct iosys_map for source > and destination buffers. Update all users. Also prepare interface for > multi-plane color formats. > > The format-conversion helpers mostly used

Re: [PATCH v1 0/7] New DRM driver for Intel VPU

Hi Stanislaw, > I'm not sure what we can add to TODO file, from driver perspective > I think it's pretty much ready for merging (except renaming), just > other components: F/W and user-space are not yet released. > > > I think I'd like Christian/Maarten to maybe review the fencing/uapi, > > to

Re: [PATCH v2 13/14] drm/format-helper: Move destination-buffer handling into internal helper

Hi Thomas, On Mon, Aug 08, 2022 at 02:54:05PM +0200, Thomas Zimmermann wrote: > The format-convertion helpers handle several cases for different > values of destination buffer and pitch. Move that code into the > internal helper drm_fb_xfrm() and avoid quite a bit of duplication. > > v2: >

Re: [Intel-gfx] [PATCH 3/7] drm/i915/guc: Add GuC <-> kernel time stamp translation information

On 8/4/2022 17:40, Teres Alexis, Alan Previn wrote: I have a question on below code. Everything else looked good. Will r-b as soon as we can close on below question ...alan On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote: From: John Harrison It is useful to be able to

Re: [PATCH v2 04/14] drm/format-helper: Convert drm_fb_swab() to struct iosys_map

Hi Thomas, On Mon, Aug 08, 2022 at 02:53:56PM +0200, Thomas Zimmermann wrote: > Convert drm_fb_swab() to use struct iosys_map() and convert users. The > new interface supports multi-plane color formats, but implementation > only supports a single plane for now. > > v2: > * use

Re: [PATCH v2 03/14] drm/format-helper: Merge drm_fb_memcpy() and drm_fb_memcpy_toio()

Hi Thomas, On Mon, Aug 08, 2022 at 02:53:55PM +0200, Thomas Zimmermann wrote: > Merge drm_fb_memcpy() and drm_fb_memcpy_toio() into a drm_fb_memcpy() > that uses struct iosys_map for buffers. The new function also supports > multi-plane color formats. Convert all users of the original helpers. >

Re: [PATCH v2 01/14] iosys-map: Add IOSYS_MAP_INIT_VADDR_IOMEM()

On Mon, Aug 08, 2022 at 02:53:53PM +0200, Thomas Zimmermann wrote: > Add IOSYS_MAP_INIT_VADDR_IOMEM() for static init of variables of type > struct iosys_map. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg > --- > include/linux/iosys-map.h | 15 ++- > 1 file

[Bug 216092] rn_vbios_smu_send_msg_with_param+0xf9/0x100 - amdgpu

https://bugzilla.kernel.org/show_bug.cgi?id=216092 Mario Limonciello (AMD) (mario.limoncie...@amd.com) changed: What|Removed |Added Status|NEW

Re: [PATCH 12/12] drm/format-helper: Move destination-buffer handling into internal helper

Hi Thomas, > > > - static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = { > > > - 0, 0, 0, 0 > > > - }; > > > const struct drm_format_info *format = fb->format; > > > - u8 cpp = format->cpp[0]; > > > void (*swab_line)(void *dbuf, const void *sbuf,

Re: [PATCH] drm/gem: Fix GEM handle release errors

Am 02.08.22 um 13:33 schrieb Jeffy Chen: Currently we are assuming a one to one mapping between dmabuf and handle when releasing GEM handles. But that is not always true, since we would create extra handles for the GEM obj in cases like gem_open() and getfb{,2}(). A similar issue was

Re: [PATCH v2] drm/gem: Fix GEM handle release errors

Hi Jeffy, Am 08.08.22 um 05:51 schrieb Chen Jeffy: Hi Christian, Thanks for your reply, and sorry i didn't make it clear. On 8/8 星期一 0:52, Christian König wrote: Am 03.08.22 um 10:32 schrieb Jeffy Chen: Currently we are assuming a one to one mapping between dmabuf and handle when releasing

Re: New subsystem for acceleration devices

On Mon, Aug 08, 2022 at 08:10:22AM +0200, Greg Kroah-Hartman wrote: > On Sun, Aug 07, 2022 at 02:25:33PM +0300, Oded Gabbay wrote: > > 2. Common code to handle drivers that want to allow a single user at a > > time to run open the device char file. > > Note, that's an impossible request, and one

Re: [PATCH v1 0/7] New DRM driver for Intel VPU

On Mon, Aug 08, 2022 at 12:34:59PM +1000, Dave Airlie wrote: > On Thu, 28 Jul 2022 at 23:17, Jacek Lawrynowicz > wrote: > > > > Hi, > > > > This patchset contains a new Linux* Kernel Driver for Intel® VPUs. > > > > VPU stands for Versatile Processing Unit and it is an AI inference > >

Re: [PATCH] dma-buf: Use dma_fence_unwrap_for_each when importing fences

On Sun, 2022-08-07 at 18:35 +0200, Christian König wrote: > Am 02.08.22 um 23:01 schrieb Jason Ekstrand: > > Ever since 68129f431faa ("dma-buf: warn about containers in > > dma_resv object"), > > dma_resv_add_shared_fence will warn if you attempt to add a > > container fence. > > While most

Re: [PATCH] i2c: qcom-geni: Fix GPI DMA buffer sync-back

On Mon, 8 Aug 2022, Wolfram Sang wrote: On Sun, Aug 07, 2022 at 11:04:54PM +0900, Robin Reckmann wrote: Fix i2c transfers using GPI DMA mode for all message types that do not set the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte"). In this case a bounce buffer is returned by

Re: New subsystem for acceleration devices

On Sun, Aug 07, 2022 at 09:43:40AM +0300, Oded Gabbay wrote: > 1. If there is a subsystem which is responsible for creating and > exposing the device character files, then there should be some code > that connects between each device driver to that subsystem. > i.e. There should be functions that

Re: [PATCH] drm: Fix EDID firmware load on resume

On Mon, 08 Aug 2022, Matthieu CHARETTE wrote: > Sorry, What do you mean? You cache with one name at connector init time, but the name specified using drm.edid_firmware may be changed whenever, to cause the next EDID read to use a different EDID firmware. BR, Jani. > > Matthieu > > On Tue, Aug

Re: [PATCH v3 3/3] drm/i915/gt: document TLB cache invalidation functions

Hi Mauro, On Thu, Aug 04, 2022 at 09:37:24AM +0200, Mauro Carvalho Chehab wrote: > Add a description for the TLB cache invalidation algorithm and for > the related kAPI functions. > > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Andi Shyti Andi

[Bug 216092] rn_vbios_smu_send_msg_with_param+0xf9/0x100 - amdgpu

https://bugzilla.kernel.org/show_bug.cgi?id=216092 --- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) --- See also: https://gitlab.freedesktop.org/drm/amd/-/issues/2110 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of

Re: [PATCH v3 1/3] drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()

Hi Mauro, On Thu, Aug 04, 2022 at 09:37:22AM +0200, Mauro Carvalho Chehab wrote: > WRITE_ONCE() should happen at the original var, not on a local > copy of it. > > Fixes: 5d36acb7198b ("drm/i915/gt: Batch TLB invalidations") > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Andi Shyti Are

Re: [Linaro-mm-sig] [PATCH 1/3] dma-buf: Add ioctl to query mmap info

On Mon, Aug 8, 2022 at 7:56 AM Christian König wrote: > > Am 08.08.22 um 15:26 schrieb Rob Clark: > > On Mon, Aug 8, 2022 at 4:22 AM Christian König > > wrote: > > > > [SNIP] > If the virtio/virtgpu UAPI was build around the idea that this is > possible then it is most likely

[PATCH 1/2] drm/fourcc: Add Synaptics VideoSmart tiled modifiers

From: "Hsia-Jun(Randy) Li" Memory Traffic Reduction(MTR) is a module in Synaptics VideoSmart platform could process lossless compression image and cache the tile memory line. Those modifiers only record the parameters would effort pixel layout or memory layout. Whether physical memory page

[PATCH 2/2] [WIP]: media: Add Synaptics compressed tiled format

From: "Hsia-Jun(Randy) Li" The most of detail has been written in the drm. Please notice that the tiled formats here request one more plane for storing the motion vector metadata. This buffer won't be compressed, so you can't append it to luma or chroma plane. Signed-off-by: Hsia-Jun(Randy) Li

[PATCH 0/2] Add pixel formats used in Synatpics SoC

From: "Hsia-Jun(Randy) Li" Those pixel formats are used in Synaptics's VideoSmart series SoCs, likes VS640, VS680. I just disclose the pixel formats used in the video codecs and display pipeline this time. Actually any device with a MTR module could support those tiled and compressed pixel

Re: [PATCH v2 1/3] drivers: serial: earlycon: Correct argument name

On Sat, Aug 6, 2022 at 10:34 AM Markuss Broks wrote: > > The "node" argument is actually an offset, It's an offset to a node in the FDT. The fact that it is an offset is an internal implementation detail of the FDT format. So really, it's a handle to a node. 'node' is more descriptive to its

Re: [PATCH v5] drm/i915: stop using swiotlb

Hi, [back from vacation] On Tue, 2022-07-26 at 16:39 +0100, Robert Beckett wrote: > Calling swiotlb functions directly is nowadays considered harmful. > See > https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/ > > Replace swiotlb_max_segment() calls with dma_max_mapping_size(). >

Re: [PATCH] drm: Fix EDID firmware load on resume

Sorry, What do you mean? Matthieu On Tue, Aug 2 2022 at 05:29:12 PM +0300, Jani Nikula wrote: On Wed, 27 Jul 2022, Matthieu CHARETTE wrote: Loading an EDID using drm.edid_firmware parameter makes resume to fail after firmware cache is being cleaned. This is because edid_load() use a

Re: [PATCH] drm: Fix EDID firmware load on resume

Sorry, What do you mean? Matthieu On Tue, Aug 2 2022 at 05:29:12 PM +0300, Jani Nikula wrote: On Wed, 27 Jul 2022, Matthieu CHARETTE > wrote: Loading an EDID using drm.edid_firmware parameter makes resume to fail after firmware cache is being cleaned.

Re: [PATCH 5/5] drm/vkms: Support registering configfs devices

On Fri, Jul 22, 2022 at 05:32:13PM -0400, Jim Shargo wrote: > VKMS now supports creating virtual cards and registering them to create > real drm devices. > > In addition to the registration logic, this commit also prevents users > from adding new objects once a card is registered. > >

[PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support

add Linaro secure heap compatible reserved mem: linaro,secure-heap use genalloc to allocate/free buffer from buffer pool. buffer pool info is defined from a dts reserved memory. Signed-off-by: Olivier Masse --- drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile |

Re: [Linaro-mm-sig] [PATCH 1/3] dma-buf: Add ioctl to query mmap info

Am 08.08.22 um 15:26 schrieb Rob Clark: On Mon, Aug 8, 2022 at 4:22 AM Christian König wrote: [SNIP] If the virtio/virtgpu UAPI was build around the idea that this is possible then it is most likely fundamental broken. How else can you envision mmap'ing to guest userspace working? Well long

[Bug 216338] New: Null Pointer Dereference in rockchip_drm_vop2.c

https://bugzilla.kernel.org/show_bug.cgi?id=216338 Bug ID: 216338 Summary: Null Pointer Dereference in rockchip_drm_vop2.c Product: Drivers Version: 2.5 Kernel Version: 5.19.0 Hardware: ARM OS: Linux Tree:

Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support

Hi Brian, On ven., 2022-08-05 at 16:41 +0100, Brian Starkey wrote: > Caution: EXT Email > > Hi Olivier, > > Thanks, I think this is looking much better. > > I'd like to know how others feel about landing this heap; there's > been > push-back in the past about heaps in device-tree and

Re: [v1] drm/msm/disp/dpu1: add support for hierarchical flush for dspp in sc7280

Hi, On Mon, Aug 8, 2022 at 3:44 AM Kalyan Thota wrote: > > >I'd like to land at least patches 6-8 from [1] next cycle. They clean up the > >CTL > >interface. Could you please rebase your patch on top of them? > > > > Sure I'll wait for the series to rebase. @Doug can you comment if this is >

Re: [PATCH v2 01/14] iosys-map: Add IOSYS_MAP_INIT_VADDR_IOMEM()

On Mon, Aug 08, 2022 at 02:53:53PM +0200, Thomas Zimmermann wrote: Add IOSYS_MAP_INIT_VADDR_IOMEM() for static init of variables of type struct iosys_map. Signed-off-by: Thomas Zimmermann Reviewed-by: Lucas De Marchi Lucas De Marchi --- include/linux/iosys-map.h | 15 ++- 1

Re: [PATCH v3 4/4] drm/panel: simple: add bus-format support for panel-dpi

Hi Aradhya Thanks for the review. Rob's comment requires changes to panel-common.yaml in order for this to get in. I think I know what needs to be done. However, as there is no agreement on bus-format in the first place there is no point in sorting that out now. Regards Max On Wed, Aug 3,

Re: [PATCH v3 2/4] dt-bindings: display: add new bus-format property for panel-dpi

Hi Marek On Wed, Aug 3, 2022 at 10:21 AM Marek Vasut wrote: > > On 6/28/22 20:18, Max Krummenacher wrote: > > Hello Max, > > [...] > > > diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > index

Re: [Linaro-mm-sig] [PATCH 1/3] dma-buf: Add ioctl to query mmap info

On Mon, Aug 8, 2022 at 4:22 AM Christian König wrote: > > Am 07.08.22 um 21:10 schrieb Rob Clark: > > On Sun, Aug 7, 2022 at 11:05 AM Christian König > > wrote: > >> Am 07.08.22 um 19:56 schrieb Rob Clark: > >>> On Sun, Aug 7, 2022 at 10:38 AM Christian König > >>> wrote: > [SNIP] >

Nested AVIC design (was:Re: [RFC PATCH v3 04/19] KVM: x86: mmu: allow to enable write tracking externally)

On Mon, 2022-08-01 at 17:20 +, Sean Christopherson wrote: > On Thu, Jul 28, 2022, Maxim Levitsky wrote: > > On Mon, 2022-07-25 at 16:08 +, Sean Christopherson wrote: > > > On Wed, Jul 20, 2022, Maxim Levitsky wrote: > > > And on that topic, do you have performance numbers to justify using

Re: [Freedreno] [PATCH 1/3] dma-buf: Add ioctl to query mmap info

On Sun, Aug 7, 2022 at 1:25 PM Akhil P Oommen wrote: > > On 7/29/2022 10:37 PM, Rob Clark wrote: > > From: Rob Clark > > > > This is a fairly narrowly focused interface, providing a way for a VMM > > in userspace to tell the guest kernel what pgprot settings to use when > > mapping a buffer to

Re: [PATCH v1 00/35] drm: Analog TV Improvements

Den 29.07.2022 18.34, skrev Maxime Ripard: > Hi, > > Here's a series aiming at improving the command line named modes support, > and more importantly how we deal with all the analog TV variants. > > The named modes support were initially introduced to allow to specify the > analog TV mode to

[PATCH v2 13/14] drm/format-helper: Move destination-buffer handling into internal helper

The format-convertion helpers handle several cases for different values of destination buffer and pitch. Move that code into the internal helper drm_fb_xfrm() and avoid quite a bit of duplication. v2: * remove a duplicated blank line (Jose) * use drm_format_info_bpp() (Sam)

[PATCH v2 00/14] drm/format-helper: Move to struct iosys_map

Change format-conversion helpers to use struct iosys_map for source and destination buffers. Update all users. Also prepare interface for multi-plane color formats. The format-conversion helpers mostly used to convert to I/O memory or system memory. To actual memory type depended on the usecase.

[PATCH v2 04/14] drm/format-helper: Convert drm_fb_swab() to struct iosys_map

Convert drm_fb_swab() to use struct iosys_map() and convert users. The new interface supports multi-plane color formats, but implementation only supports a single plane for now. v2: * use drm_format_info_bpp() (Sam) * update documentation (Sam) * add TODO on vaddr location

[PATCH v2 14/14] drm/format-helper: Rename parameter vmap to src

The name the parameter vmap to src in all functions. The parameter contains the locations of the source data and the new name says that. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_format_helper.c | 106 ++-- include/drm/drm_format_helper.h | 18 ++---

[PATCH v2 10/14] drm/format-helper: Rework XRGB8888-to-XRGB2101010 conversion

Update XRGB-to-XRGB2101010 conversion to support struct iosys_map and convert all users. Although these are single-plane color formats, the new interface supports multi-plane formats for consistency with drm_fb_blit(). v2: * update documentation (Sam) * add TODO on vaddr

[PATCH v2 11/14] drm/format-helper: Rework XRGB8888-to-GRAY8 conversion

Update XRGB-to-GRAY8 conversion to support struct iosys_map and convert all users. Although these are single-plane color formats, the new interface supports multi-plane formats for consistency with drm_fb_blit(). v2: * update documentation (Sam) * add TODO on vaddr location

[PATCH v2 05/14] drm/format-helper: Rework XRGB8888-to-RGBG332 conversion

Update XRGB-to-RGB332 conversion to support struct iosys_map and convert all users. Although these are single-plane color formats, the new interface supports multi-plane formats for consistency with drm_fb_blit(). v2: * rebase onto refactored Kunit tests * update documentation

[PATCH v2 02/14] drm/format-helper: Provide drm_fb_blit()

Provide drm_fb_blit() that works with struct iosys_map. Update all users of drm_fb_blit_toio(), which required a destination buffer in I/O memory. This patch only updates the function's interface. The implementation still relies on the destination buffer to be located in I/O memory. See the

[PATCH v2 12/14] drm/format-helper: Rework XRGB8888-to-MONO conversion

Update XRGB-to-MONO conversion to support struct iosys_map and convert all users. Although these are single-plane color formats, the new interface supports multi-plane formats for consistency with drm_fb_blit(). v2: * rebase after renaming CMA helpers to DMA helpers * update

[PATCH v2 08/14] drm/format-helper: Rework RGB565-to-XRGB8888 conversion

Update RGB565-to-XRGB conversion to support struct iosys_map and convert all users. Although these are single-plane color formats, the new interface supports multi-plane formats for consistency with drm_fb_blit(). v2: * add TODO on vaddr location (Sam) Signed-off-by: Thomas

[PATCH v2 06/14] drm/format-helper: Rework XRGB8888-to-RGBG565 conversion

Update XRGB-to-RGB565 conversion to support struct iosys_map and convert all users. Although these are single-plane color formats, the new interface supports multi-plane formats for consistency with drm_fb_blit(). v2: * update new Kunit tests * update documentation (Sam)

[PATCH v2 09/14] drm/format-helper: Rework RGB888-to-XRGB8888 conversion

Update RGB888-to-XRGB conversion to support struct iosys_map and convert all users. Although these are single-plane color formats, the new interface supports multi-plane formats for consistency with drm_fb_blit(). v2: * add TODO on vaddr location (Sam) Signed-off-by: Thomas

[PATCH v2 07/14] drm/format-helper: Rework XRGB8888-to-RGB888 conversion

Update XRGB-to-RGB888 conversion to support struct iosys_map and convert all users. Although these are single-plane color formats, the new interface supports multi-plane formats for consistency with drm_fb_blit(). v2: * update documentation (Sam) * add TODO on vaddr location

[PATCH v2 03/14] drm/format-helper: Merge drm_fb_memcpy() and drm_fb_memcpy_toio()

Merge drm_fb_memcpy() and drm_fb_memcpy_toio() into a drm_fb_memcpy() that uses struct iosys_map for buffers. The new function also supports multi-plane color formats. Convert all users of the original helpers. v2: * rebase onto refactored mgag200 * use drm_formap_info_bpp() (Sam)

[PATCH v2 01/14] iosys-map: Add IOSYS_MAP_INIT_VADDR_IOMEM()

Add IOSYS_MAP_INIT_VADDR_IOMEM() for static init of variables of type struct iosys_map. Signed-off-by: Thomas Zimmermann --- include/linux/iosys-map.h | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h index

Re: [PATCH v1 06/35] drm/connector: Only register TV mode property if present

Den 29.07.2022 18.34, skrev Maxime Ripard: > The drm_create_tv_properties() will create the TV mode property > unconditionally. > > However, since we'll gradually phase it out, let's register it only if we > have a list passed as an argument. This will make the transition easier. > >

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

Den 29.07.2022 18.34, skrev Maxime Ripard: > The TV mode property has been around for a while now to select and get the > current TV mode output on an analog TV connector. > > Despite that property name being generic, its content isn't and has been > driver-specific which makes it hard to

RE: [v1] drm/msm/disp/dpu1: add support for hierarchical flush for dspp in sc7280

>-Original Message- >From: Dmitry Baryshkov >Sent: Thursday, August 4, 2022 9:29 PM >To: Kalyan Thota (QUIC) >Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org; >freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux- >ker...@vger.kernel.org;

  1   2   >