On 3/28/22 21:07, Ramalingam C wrote:
Extend the live migrate selftest, to verify the ccs surface clearing
during the Flat-CCS capable lmem obj clear.
v2:
Look at right places for ccs data [Thomas]
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/
On 3/28/22 21:07, Ramalingam C wrote:
Consider the possible round up happened at obj size alignment to
min_page_size during the obj allocation.
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 3 +++
1 file changed, 3 insertio
On 3/28/22 21:07, Ramalingam C wrote:
Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.
XY_CTRL_SURF_COPY_BLT is a BLT cmd us
On 28-03-22, 13:21, Rob Herring wrote:
> On Mon, Mar 28, 2022 at 12:18 PM Krzysztof Kozlowski
> wrote:
> >
> > On 28/03/2022 19:16, Vinod Koul wrote:
> > > On 28-03-22, 19:43, Dmitry Baryshkov wrote:
> > >> On Mon, 28 Mar 2022 at 18:30, Krzysztof Kozlowski
> > >> wrote:
> > >>>
> > >>> The DSI no
On Tue, 2022-03-29 at 00:37 +0530, Ramalingam C wrote:
> To make it uniform across copy and clear, use the engine offset
> directly
> to calculate the offset in the cmd forming for emit_clear.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/gt/intel_migrate.c | 11 ---
> 1 f
On Tue, 2022-03-29 at 00:37 +0530, Ramalingam C wrote:
> Use faster XY_FAST_COLOR_BLT cmd on graphics version of 12 and more,
> for clearing (Zero out) the pages of the newly allocated object.
>
> XY_FAST_COLOR_BLT is faster than the older XY_COLOR_BLT.
>
> v2:
> Typo fix at title [Thomas]
> v3
Dear 李真,
[Your mailer formatted the message oddly. Maybe configure it to use only
plain text email with no HTML parts – common in Linux kernel community
–, or, if not possible, switch to something else (Mozilla Thunderbird, …).]
Am 29.03.22 um 04:54 schrieb 李真能:
[…]
*日 期：*2022-03-28 15:3
This is a workaround for s3 resume hang for r7 340(amdgpu).
When we test s3 with r7 340 on arm64 platform, graphics card will hang up,
the error message are as follows:
Mar 4 01:14:11 greatwall-GW-XX-XXX kernel: [1.599374][ 7] [ T291]
amdgpu :02:00.0: fb0: amdgpudrmfb frame buffer de
主 题：Re: [PATCH] drm/amdgpu: resolve s3 hang for r7340
日 期：2022-03-28 15:38
发件人：Paul Menzel
收件人：Zhenneng Li
[Cc: -Jack Zhang (invalid address)Am 28.03.22 um 09:36 schrieb Paul Menzel:> Dear Zhenneng,> > > Thank
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next v5.17 next-20220328]
[cannot apply to airlied/drm-next]
[If your
On 2022/3/28 22:04, Rob Herring wrote:
On Sat, Mar 26, 2022 at 06:04:46PM +0800, Sui Jingfeng wrote:
On 2022/3/24 21:26, Rob Herring wrote:
On Thu, Mar 24, 2022 at 09:48:19AM +0800, Sui Jingfeng wrote:
On 2022/3/23 21:03, Rob Herring wrote:
On Wed, Mar 23, 2022 at 11:38:55AM +0800, Sui Jing
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next v5.17 next-20220328]
[cannot apply to airlied/drm-next]
[If your
I didn't notice this until now, probably because everything still
_works_, but I get a new big warning splat at bootup on my main
workstation these days as of the merge window changes.
The full warning is attached, but it's basically the ASSERT(0) at line 938 in
drivers/gpu/drm/amd/display/dc/c
Hi Paul,
> -Original Message-
> From: dri-devel On Behalf Of Paul
> Menzel
> Sent: Monday, March 28, 2022 2:15 PM
> To: Liu, Chuansheng
> Cc: tzimmerm...@suse.de; linux-fb...@vger.kernel.org; del...@gmx.de; dri-
> de...@lists.freedesktop.org; jay...@intworks.biz
> Subject: Re: [PATCH] fb
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Add support for the
DSI-to-DPI mode.
This requires skipping most of the (e)DP initialization code, which is
currently a large part of this driver, hence it is better to have far
sim
The bridge ops are specific to the bridge configuration, move them
into tc_probe_edp_bridge_endpoint() to permit cleaner addition of
DSI-to-DPI mode. No functional change.
Reviewed-by: Lucas Stach
Tested-by: Lucas Stach # In both DPI to eDP and DSI to
DPI mode.
Signed-off-by: Marek Vasut
Cc: J
This bit of code is (e)DP and aux I2C link specific, move it into
tc_aux_link_setup() to permit cleaner addition of DSI-to-DPI mode.
No functional change.
Reviewed-by: Lucas Stach
Tested-by: Lucas Stach # In both DPI to eDP and DSI to
DPI mode.
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc:
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
currently supported. In order to support the rest of the modes without
making the tc_probe() overly long, split the bridge endpoint parsing
into dedicated func
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
currently supported. It is possible to find out the mode in which the
bridge should be operated by testing connected endpoints in DT.
Port allocation:
port@0
Implement .atomic_check callback which prevents user space from setting
unsupported mode. The tc_edp_common_atomic_check() variant is already
prepared for DSI-to-DPI mode addition, which has different frequency
limits.
Reviewed-by: Lucas Stach
Tested-by: Lucas Stach # In both DPI to eDP and DSI
These functions are specific to (e)DP output initialization and
operation, add specific tc_edp_ prefix to those functions to
discern them from DPI output functions that will be added later
in this series. No functional change.
Reviewed-by: Lucas Stach
Tested-by: Lucas Stach # In both DPI to eDP
Use the atomic version of the enable/disable operations to continue the
transition to the atomic API. This will be needed to access the mode
from the atomic state.
Reviewed-by: Lucas Stach
Tested-by: Lucas Stach # In both DPI to eDP and DSI to
DPI mode.
Signed-off-by: Marek Vasut
Cc: Jonas Kar
The tc_set_video_mode() sets up both common and (e)DP video mode settings of
the bridge chip. Split the function into tc_set_common_video_mode() to set
the common settings and tc_set_edp_video_mode() to set the (e)DP specific
settings. No functional change.
Reviewed-by: Lucas Stach
Tested-by: Luc
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Clean up the driver,
switch to atomic ops, and add support for the DSI-to-DPI mode in
addition to already supported DPI-to-(e)DP mode.
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: M
It is necessary to specify the number of connected/used DSI data lanes when
using the DSI input port of this bridge. Document the 'data-lanes' property
of the DSI input port.
Reviewed-by: Rob Herring
Acked-by: Lucas Stach
Tested-by: Lucas Stach # In both DPI to eDP and DSI to
DPI mode.
Signed-
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Document support for the
DPI output port, which can now be connected both as input and output.
Acked-by: Rob Herring
Reviewed-by: Lucas Stach
Tested-by: Lucas Stach # In both DPI
Reviewed-by: Lyude Paul
Will push this to the appropriate repository shortly.
On Sun, 2022-03-27 at 15:39 +0800, Xiaomeng Tong wrote:
> The bug is here:
> return encoder;
>
> The list iterator value 'encoder' will *always* be set and non-NULL
> by drm_for_each_encoder_mask(), so it is i
To all X.Org Foundation Members:
The election for the X.Org Foundation Board of Directors will begin on 04 April
2022. We have 6 candidates who are running for 4 seats. They are:
Emma Anholt
Shashank Sharma
Ricardo Garcia
Mark Filion
Lucas Stach
Alyssa Rosenzweig
To be fo
On Sat, Mar 26, 2022 at 10:09 PM Xiaomeng Tong wrote:
>
> 'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset()
> and it will lead to a NULL dereference by a lately use of it
> (i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check.
>
> Fixes: 62fb7a5e10962 ("virtio-gpu: add 3d/v
On Mon, Mar 28, 2022 at 01:46:15PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Continuation of the effort to declutter i915_drv.h.
Also, component specific helpers which consult the iommu/virtualization
helpers moved to respective component source/header files as appropriate.
Signed-off
On Mon, Mar 28, 2022 at 11:30 PM Paul Cercueil wrote:
> Le lun., mars 28 2022 at 18:54:25 +0100, Jonathan Cameron
> a écrit :
> > On Mon, 7 Feb 2022 12:59:28 +
> > Paul Cercueil wrote:
> >
> >> Enhance the current fileio code by using DMABUF objects instead of
> >> custom buffers.
> >>
>
On Fri, Mar 25, 2022 at 02:09:33PM +0200, Jani Nikula wrote:
On Fri, 25 Mar 2022, Tvrtko Ursulin wrote:
On 24/03/2022 18:57, Jani Nikula wrote:
On Thu, 24 Mar 2022, Tvrtko Ursulin wrote:
On 24/03/2022 11:57, Jani Nikula wrote:
On Thu, 24 Mar 2022, Tvrtko Ursulin wrote:
On 24/03/2022 09:31
On Tue, Feb 8, 2022 at 5:26 PM Paul Cercueil wrote:
>
> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
>
> The advantage of this new DMABUF based interface vs. the read()
> interface, is that it avoids an extra copy of the data between the
> ke
On Wed, Feb 9, 2022 at 9:10 AM Paul Cercueil wrote:
>
> Adding write support to the buffer-dma code is easy - the write()
> function basically needs to do the exact same thing as the read()
> function: dequeue a block, read or write the data, enqueue the block
> when entirely processed.
>
> Theref
Am Donnerstag, dem 24.02.2022 um 20:58 +0100 schrieb Marek Vasut:
> The TC358767/TC358867/TC9595 are all capable of operating in multiple
> modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Clean up the driver,
> switch to atomic ops, and add support for the DSI-to-DPI mode in
> addition to already su
Am Donnerstag, dem 24.02.2022 um 20:58 +0100 schrieb Marek Vasut:
> The TC358767/TC358867/TC9595 are all capable of operating in multiple
> modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Add support for the
> DSI-to-DPI mode.
>
> This requires skipping most of the (e)DP initialization code, which
Am Donnerstag, dem 24.02.2022 um 20:58 +0100 schrieb Marek Vasut:
> The bridge ops are specific to the bridge configuration, move them
> into tc_probe_edp_bridge_endpoint() to permit cleaner addition of
> DSI-to-DPI mode. No functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
>
Am Donnerstag, dem 24.02.2022 um 20:58 +0100 schrieb Marek Vasut:
> The TC358767/TC358867/TC9595 are all capable of operating either from
> attached Xtal or from DSI clock lane clock. In case the later is used,
> all I2C accesses will fail until the DSI clock lane is running and
> supplying clock t
Am Donnerstag, dem 24.02.2022 um 20:58 +0100 schrieb Marek Vasut:
> Implement .atomic_check callback which prevents user space from setting
> unsupported mode. The tc_edp_common_atomic_check() variant is already
> prepared for DSI-to-DPI mode addition, which has different frequency
> limits.
>
> S
Am Donnerstag, dem 24.02.2022 um 20:58 +0100 schrieb Marek Vasut:
> It is necessary to specify the number of connected/used DSI data lanes when
> using the DSI input port of this bridge. Document the 'data-lanes' property
> of the DSI input port.
>
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
Am Donnerstag, dem 24.02.2022 um 20:58 +0100 schrieb Marek Vasut:
> The TC358767/TC358867/TC9595 are all capable of operating in multiple
> modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Document support for the
> DPI output port, which can now be connected both as input and output.
>
> Signed-off
Hi Jonathan,
Le lun., mars 28 2022 at 18:54:25 +0100, Jonathan Cameron
a écrit :
On Mon, 7 Feb 2022 12:59:28 +
Paul Cercueil wrote:
Enhance the current fileio code by using DMABUF objects instead of
custom buffers.
This adds more code than it removes, but:
- a lot of the complexit
On Mon, Mar 14, 2022 at 3:30 PM Jason Baron wrote:
>
>
>
> On 3/11/22 20:06, jim.cro...@gmail.com wrote:
> > On Fri, Mar 11, 2022 at 12:06 PM Jason Baron wrote:
> >>
> >>
> >>
> >> On 3/10/22 23:47, Jim Cromie wrote:
> >>>
> >>> With the patch, one can enable current/unclassed callsites by:
> >>>
Move the static calculations out of the loops for copy and clear.
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 44 -
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_m
When we are swapping out the local memory obj on flat-ccs capable platform,
we need to capture the ccs data too along with main meory and we need to
restore it when we are swapping in the content.
When lmem object is swapped into a smem obj, smem obj will
have the extra pages required to hold the
Add a parameter called "extra_pages" for ttm_tt_init, to indicate that
driver needs extra pages in ttm_tt.
v2:
Used imperative wording [Thomas and Christian]
Signed-off-by: Ramalingam C
cc: Christian Koenig
cc: Hellstrom Thomas
Reviewed-by: Thomas Hellstrom
Reviewed-by: Christian Konig
Rev
On Xe-HP and later devices, dedicated compression control state (CCS)
stored in local memory is used for each surface, to support the
3D and media compression formats.
The memory required for the CCS of the entire local memory is 1/256 of
the local memory size. So before the kernel boot, the requi
Extend the live migrate selftest, to verify the ccs surface clearing
during the Flat-CCS capable lmem obj clear.
v2:
Look at right places for ccs data [Thomas]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 250 ++---
1 file changed, 222 insertion
Consider the possible round up happened at obj size alignment to
min_page_size during the obj allocation.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c
b/drivers/gpu/dr
Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.
XY_CTRL_SURF_COPY_BLT is a BLT cmd used for reading and writing the
ccs surface
To make it uniform across copy and clear, use the engine offset directly
to calculate the offset in the cmd forming for emit_clear.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/
Use faster XY_FAST_COLOR_BLT cmd on graphics version of 12 and more,
for clearing (Zero out) the pages of the newly allocated object.
XY_FAST_COLOR_BLT is faster than the older XY_COLOR_BLT.
v2:
Typo fix at title [Thomas]
v3:
XY_FAST_COLOR_BLT is used only for FLAT_CCS capable gen12+
Signed-
On Xe-HP and later devices, we use dedicated compression control
state (CCS) stored in local memory for each surface, to support
the 3D and media compression formats.
The memory required for the CCS of the entire local memory is
1/256 of the local memory size. So before the kernel
boot, the requir
On 2022-03-24 at 17:14:53 +0100, Thomas Hellström (Intel) wrote:
> Hi, Ram
>
> On 3/21/22 23:44, Ramalingam C wrote:
> > Xe-HP and latest devices support Flat CCS which reserved a portion of
> > the device memory to store compression metadata, during the clearing of
> > device memory buffer object
On 2022-03-24 at 17:28:08 +0100, Thomas Hellström wrote:
>
> On 3/21/22 23:44, Ramalingam C wrote:
> > On Xe-HP and later devices, dedicated compression control state (CCS)
> > stored in local memory is used for each surface, to support the
> > 3D and media compression formats.
> >
> > The memory
On 2022-03-24 at 17:20:28 +0100, Thomas Hellström (Intel) wrote:
>
> On 3/21/22 23:44, Ramalingam C wrote:
> > Handle the src and dst chunk offsets for different instances of the copy
> > engines.
> >
> > Signed-off-by: Ramalingam C
> > ---
> > drivers/gpu/drm/i915/gt/intel_migrate.c | 3 +++
>
Hi Jonathan,
Le lun., mars 28 2022 at 18:37:01 +0100, Jonathan Cameron
a écrit :
On Mon, 7 Feb 2022 12:59:26 +
Paul Cercueil wrote:
Add the necessary infrastructure to the IIO core to support a new
optional DMABUF based interface.
The advantage of this new DMABUF based interface vs
Hi Jonathan,
Le lun., mars 28 2022 at 18:24:09 +0100, Jonathan Cameron
a écrit :
On Mon, 7 Feb 2022 12:59:23 +
Paul Cercueil wrote:
Adding write support to the buffer-dma code is easy - the write()
function basically needs to do the exact same thing as the read()
function: dequeue a
On Mon, 28 Mar 2022, Emil Velikov wrote:
> On Mon, 28 Mar 2022 at 15:34, Jani Nikula wrote:
>>
>> v3 of https://patchwork.freedesktop.org/series/101787/ and
>> https://patchwork.freedesktop.org/series/101862/
>>
>> I screwed up with the struct renamings in v2, so there's some falling
>> back to v
On Mon, 28 Mar 2022, Ville Syrjälä wrote:
> On Mon, Mar 28, 2022 at 05:34:33PM +0300, Jani Nikula wrote:
>> Reduce the size of the function that actually modifies the EDID.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_edid.c | 42 ++
>> 1 fi
On 2022-03-28 12:54, Melissa Wen wrote:
> On 03/28, Simon Ser wrote:
>> Thanks a lot for you patch! I've noticed as well that amdgpu ignores
>> the plane alpha property [1]. I'll try to find time to test it.
> Hi Simon,
>
> So you've faced this kind of issue many times :/
> Let me know the resu
On Mon, Mar 28, 2022 at 12:18 PM Krzysztof Kozlowski
wrote:
>
> On 28/03/2022 19:16, Vinod Koul wrote:
> > On 28-03-22, 19:43, Dmitry Baryshkov wrote:
> >> On Mon, 28 Mar 2022 at 18:30, Krzysztof Kozlowski
> >> wrote:
> >>>
> >>> The DSI node is not a bus and the children do not have unit address
On Mon, 28 Mar 2022 at 15:34, Jani Nikula wrote:
>
> v3 of https://patchwork.freedesktop.org/series/101787/ and
> https://patchwork.freedesktop.org/series/101862/
>
> I screwed up with the struct renamings in v2, so there's some falling
> back to v1 and general confusion here. Sorry.
>
The mutati
>> +u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
>> -static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
>
> I think all helpers which emit to ring take cs as the first argument so it
> would be good to make this consistent.
Updated the patch, please review
Am 28.03.22 um 19:54 schrieb Jonathan Cameron:
On Mon, 7 Feb 2022 12:59:28 +
Paul Cercueil wrote:
Enhance the current fileio code by using DMABUF objects instead of
custom buffers.
This adds more code than it removes, but:
- a lot of the complexity can be dropped, e.g. custom kref and
On Mon, Mar 28, 2022 at 05:34:33PM +0300, Jani Nikula wrote:
> Reduce the size of the function that actually modifies the EDID.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 42 ++
> 1 file changed, 24 insertions(+), 18 deletions(-)
>
>
On Mon, 7 Feb 2022 12:59:28 +
Paul Cercueil wrote:
> Enhance the current fileio code by using DMABUF objects instead of
> custom buffers.
>
> This adds more code than it removes, but:
> - a lot of the complexity can be dropped, e.g. custom kref and
> iio_buffer_block_put_atomic() are not
Am 28.03.22 um 19:17 schrieb Melissa Wen:
On 03/28, Christian König wrote:
Am 26.03.22 um 21:24 schrieb Melissa Wen:
dcn10_validate_bandwidth is only used on dcn10 files, but is declared in
dcn_calcs files. Rename dcn10_* to dcn_* in calcs, remove DC_FP_* wrapper
inside DML folder and create an
On Mon, Mar 28, 2022 at 05:34:32PM +0300, Jani Nikula wrote:
> With this, the remaining non-const parts are the ones that actually
> modify the EDID, for example to fix corrupt EDID.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edi
On Mon, Mar 28, 2022 at 05:34:31PM +0300, Jani Nikula wrote:
> Finalize detailed timing parsing constness by making struct edid also
> const in callbacks and closure.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 48 +++
On Mon, Mar 28, 2022 at 05:34:30PM +0300, Jani Nikula wrote:
> Constify the first level of struct edid in detailed timing parsing. Also
> switch to struct edid instead of u8.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 48
On Mon, Mar 28, 2022 at 05:34:29PM +0300, Jani Nikula wrote:
> Moving one level higher, constify struct detailed_timing pointers in
> callbacks.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 40 -
On Mon, Mar 28, 2022 at 05:34:28PM +0300, Jani Nikula wrote:
> Start constifying the struct detailed_timing pointers being passed
> around from bottom up.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 40 +++
On Mon, Mar 28, 2022 at 05:34:27PM +0300, Jani Nikula wrote:
> Use struct detailed_timing member access instead of direct offsets to
> avoid casting.
>
> Use BUILD_BUG_ON() for sanity check.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/dr
On Mon, Mar 28, 2022 at 05:34:26PM +0300, Jani Nikula wrote:
> Use struct detailed_timing member access instead of direct offsets to
> avoid casting.
>
> Use BUILD_BUG_ON() for sanity check.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/dr
On Mon, 7 Feb 2022 12:59:26 +
Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
>
> The advantage of this new DMABUF based interface vs. the read()
> interface, is that it avoids an extra copy of the data between the
On Mon, Mar 28, 2022 at 05:34:25PM +0300, Jani Nikula wrote:
> Use struct member access instead of direct offsets to avoid a cast.
>
> Use BUILD_BUG_ON() for sanity check.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 8 ++
On Mon, Mar 28, 2022 at 05:34:24PM +0300, Jani Nikula wrote:
> Use struct member access instead of direct offsets to avoid lots of
> casts all over the place.
>
> Use BUILD_BUG_ON() for sanity check.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drive
On Mon, Mar 28, 2022 at 05:34:23PM +0300, Jani Nikula wrote:
> The reduced blanking bit is valid only for CVT, indicated by display
> range limits flags 0x04.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Let's repeat here in so it doesn't get lost.
Reviewed-by: Ville Syrjälä
> ---
> dr
From: Fei Yang
GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the
On 28/03/2022 18:43, Dmitry Baryshkov wrote:
> On Mon, 28 Mar 2022 at 18:30, Krzysztof Kozlowski
> wrote:
>>
>> The DSI node is not a bus and the children do not have unit addresses.
>>
>> Reported-by: Vinod Koul
>> Signed-off-by: Krzysztof Kozlowski
>
> NAK.
> DSI panels are children of the DS
On 28/03/2022 17:29, Krzysztof Kozlowski wrote:
> The DSI node is not a bus and the children do not have unit addresses.
Eh, actually MIPI DSI is a serial bus, so address/size cells seem right
and my patch is not correct.
>
> Reported-by: Vinod Koul
> Signed-off-by: Krzysztof Kozlowski
> ---
>
The DSI node is not a bus and the children do not have unit addresses.
Reported-by: Vinod Koul
Signed-off-by: Krzysztof Kozlowski
---
.../bindings/display/msm/dsi-controller-main.yaml | 7 ---
1 file changed, 7 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/m
On 28/03/2022 19:16, Vinod Koul wrote:
> On 28-03-22, 19:43, Dmitry Baryshkov wrote:
>> On Mon, 28 Mar 2022 at 18:30, Krzysztof Kozlowski
>> wrote:
>>>
>>> The DSI node is not a bus and the children do not have unit addresses.
>>>
>>> Reported-by: Vinod Koul
>>> Signed-off-by: Krzysztof Kozlowski
On Mon, 7 Feb 2022 12:59:25 +
Paul Cercueil wrote:
> Use the iio_dma_buffer_write() and iio_dma_buffer_space_available()
> functions provided by the buffer-dma core, to enable write support in
> the buffer-dmaengine code.
>
> Signed-off-by: Paul Cercueil
> Reviewed-by: Alexandru Ardelean
On 03/28, Christian König wrote:
> Am 26.03.22 um 21:24 schrieb Melissa Wen:
> > dcn10_validate_bandwidth is only used on dcn10 files, but is declared in
> > dcn_calcs files. Rename dcn10_* to dcn_* in calcs, remove DC_FP_* wrapper
> > inside DML folder and create an specific dcn10_validate_bandwid
On Mon, 7 Feb 2022 12:59:23 +
Paul Cercueil wrote:
> Adding write support to the buffer-dma code is easy - the write()
> function basically needs to do the exact same thing as the read()
> function: dequeue a block, read or write the data, enqueue the block
> when entirely processed.
>
> Th
On 28-03-22, 19:43, Dmitry Baryshkov wrote:
> On Mon, 28 Mar 2022 at 18:30, Krzysztof Kozlowski
> wrote:
> >
> > The DSI node is not a bus and the children do not have unit addresses.
> >
> > Reported-by: Vinod Koul
> > Signed-off-by: Krzysztof Kozlowski
>
> NAK.
> DSI panels are children of th
On Mon, Mar 21, 2022 at 02:58:45PM +0100, Christian König wrote:
> Audit all the users of dma_resv_add_excl_fence() and make sure they
> reserve a shared slot also when only trying to add an exclusive fence.
>
> This is the next step towards handling the exclusive fence like a
> shared one.
>
> v
On Mon, 7 Feb 2022 12:59:22 +
Paul Cercueil wrote:
> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
>
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much
On 03/28, Simon Ser wrote:
> Thanks a lot for you patch! I've noticed as well that amdgpu ignores
> the plane alpha property [1]. I'll try to find time to test it.
Hi Simon,
So you've faced this kind of issue many times :/
Let me know the results from your side, so we can use it to find the
correc
On Tue, Mar 8, 2022 at 1:57 PM Jagan Teki wrote:
>
> This reverts commit c206c7faeb3263a7cc7b4de443a3877cd7a5e74b.
>
> In order to avoid any probe ordering issues, the I2C based downstream
> bridge drivers now register and attach the DSI devices at the probe
> instead of doing it on drm_bridge_fun
On Mon, 28 Mar 2022 at 18:30, Krzysztof Kozlowski
wrote:
>
> The DSI node is not a bus and the children do not have unit addresses.
>
> Reported-by: Vinod Koul
> Signed-off-by: Krzysztof Kozlowski
NAK.
DSI panels are children of the DSI device tree node with the reg = <0>; address.
This is the
On 03/28, Kazlauskas, Nicholas wrote:
> [AMD Official Use Only]
>
> > -Original Message-
> > From: Melissa Wen
> > Sent: Friday, March 25, 2022 4:45 PM
> > To: amd-...@lists.freedesktop.org; Wentland, Harry
> > ; Deucher, Alexander
> > ; Siqueira, Rodrigo
> > ; Kazlauskas, Nicholas
> > ;
Hi Zack!
>
> I'd just break apart the condition above rather than have two if ret !=
> 0. What apps do you see glitches in as a result of this? Can you
> reproduce it?
>
There are many apps I can use to trigger this drm error. It occurs more
often on a Wayland-based desktop than on X11. While loo
On Mon, Mar 28, 2022 at 12:39:07AM +0200, Guillaume Ranquet wrote:
> From: Markus Schneider-Pargmann
>
> This controller is present on several mediatek hardware. Currently
> mt8195 and mt8395 have this controller without a functional difference,
> so only one compatible field is added.
>
> The c
On Mon, Mar 28, 2022 at 12:17:16PM +0300, Jani Nikula wrote:
> The reduced blanking bit is valid only for CVT, indicated by display
> range limits flags 0x04.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+),
On Mon, Mar 28, 2022 at 03:24:05PM +0200, Robert Foss wrote:
> On Fri, 18 Mar 2022 at 10:25, Liu Ying wrote:
> >
> > On Thu, 2022-03-17 at 18:58 +0100, José Expósito wrote:
> > > The function "drm_of_find_panel_or_bridge" has been deprecated in
> > > favor of "devm_drm_of_get_bridge".
> > >
> > >
On Mon, Mar 28, 2022 at 09:44:36AM +0100, Tvrtko Ursulin wrote:
>
> + Joonas
>
> On 25/03/2022 23:03, Francisco Jerez wrote:
> > Matt Atwood writes:
> >
> > > Newer platforms have DSS that aren't necessarily available for both
> > > geometry and compute, two queries will need to exist. This int
If we use a format that has padding instead of the alpha component (such
as XRGB), it appears that the Transposer will fill the padding to 0,
disregarding what was stored in the input buffer padding.
This leads to issues with IGT, since it will set the padding to 0xff,
but will then compare th
1 - 100 of 214 matches
Mail list logo
