On 2022/3/23 10:29, Jiaxun Yang wrote:
If you want to blame somebody for the problem then please don't
blame us. We tried very hard to fit all those stuff into kernel's model
of devices. You should blame those who did the initial design of
Loongson's boot interface that failed to introduce a pr
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM boards doesn't allow unaligned access to MMIO space
is a well known bug of those ARM boar
Add a simple check to reject any size not aligned to the
min_page_size.
handle instances when size is not aligned with the min_page_size.
Unigine Heaven has allocation requests for example required pages
are 257 and alignment request is 256. To allocate the left over 1
page, continues the iteratio
Am 23.03.22 um 07:25 schrieb Arunpravin Paneer Selvam:
[SNIP]
@@ -415,48 +409,86 @@ static int amdgpu_vram_mgr_new(struct
ttm_resource_manager *man,
goto error_fini;
}
- mode = DRM_MM_INSERT_BEST;
+ INIT_LIST_HEAD(&node->blocks);
+
if (place->flags & TTM
Hi Paul,
Am 23.03.22 um 07:42 schrieb Paul Menzel:
Dear Arunprivin,
Thank you for your patch.
Am 23.03.22 um 07:25 schrieb Arunpravin Paneer Selvam:
- Remove drm_mm references and replace with drm buddy functionalities
The commit message summary to me suggested, you can somehow use both
a
Am 23.03.22 um 08:34 schrieb Arunpravin Paneer Selvam:
Add a simple check to reject any size not aligned to the
min_page_size.
handle instances when size is not aligned with the min_page_size.
Unigine Heaven has allocation requests for example required pages
are 257 and alignment request is 256.
Dear Christian,
Am 23.03.22 um 08:42 schrieb Christian König:
Am 23.03.22 um 07:42 schrieb Paul Menzel:
Am 23.03.22 um 07:25 schrieb Arunpravin Paneer Selvam:
- Remove drm_mm references and replace with drm buddy functionalities
The commit message summary to me suggested, you can somehow
Hi Paul,
Am 23.03.22 um 09:10 schrieb Paul Menzel:
Dear Christian,
Am 23.03.22 um 08:42 schrieb Christian König:
Am 23.03.22 um 07:42 schrieb Paul Menzel:
Am 23.03.22 um 07:25 schrieb Arunpravin Paneer Selvam:
- Remove drm_mm references and replace with drm buddy functionalities
The co
From: Chris Wilson
We already wrap i915_vma.node.start for use with the GGTT, as there we
can perform additional sanity checks that the node belongs to the GGTT
and fits within the 32b registers. In the next couple of patches, we
will introduce guard pages around the objects _inside_ the drm_mm_n
When DMAR / VT-d is enabled, the display engine uses overfetching, presumably
to deal with the increased latency. To avoid display engine errors and DMAR
faults, as a workaround the GGTT is populated with scatch PTEs when VT-d
is enabled. However starting with gen10, Write-combined writing of scrat
From: Chris Wilson
Introduce the concept of padding the i915_vma with guard pages before
and aft. The major consequence is that all ordinary uses of i915_vma
must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
directly, as the drm_mm_node will include the guard pages that surr
From: Chris Wilson
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Curr
On 2022/3/23 04:49, Rob Herring wrote:
+/*
+ * ls7a_gpio_i2c_set - set the state of a gpio pin indicated by mask
+ * @mask: gpio pin mask
+ */
+static void ls7a_gpio_i2c_set(struct lsdc_i2c * const li2c, int mask, int
state)
+{
+ unsigned long flags;
+ u8 val;
+
+ spin_lock_i
Hi,
On Tue, Mar 22, 2022 at 10:05:56PM +0300, Dmitry Osipenko wrote:
> On 2/25/22 17:35, Maxime Ripard wrote:
> > When we change a clock minimum or maximum using clk_set_rate_range(),
> > clk_set_min_rate() or clk_set_max_rate(), the current code will only
> > trigger a new rate change if the rate
These patches coninue work started by AngeloGioacchino Del Regno in the
previous cycle by further decoupling and dissecting MDSS and MDP drivers
probe/binding paths.
This removes code duplication between MDP5 and DPU1 MDSS drivers, by
merging them and moving to the top level.
This patchset depend
MDP5 and DPU1 both provide the driver handling the MDSS region, which
handles the irq domain and (incase of DPU1) adds some init for the UBWC
controller. Unify those two pieces of code into a common driver.
Reviewed-by: Abhinav Kumar
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
Since now there is just one mdss subdriver, drop all the indirection,
make msm_mdss struct completely opaque (and defined inside msm_mdss.c)
and call mdss functions directly.
Reviewed-by: Abhinav Kumar
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c
MSM DRM driver already allows one to compile out the DP or DSI support.
Add support for disabling other features like MDP4/MDP5/DPU drivers or
direct HDMI output support.
Suggested-by: Stephen Boyd
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig
Let's make the match's data pointer a (sub-)driver's private data. The
only user currently is the msm_drm_init() function, using this data to
select kms_init callback. Pass this callback through the driver's
private data instead.
Reviewed-by: Stephen Boyd
Reviewed-by: Abhinav Kumar
Signed-off-by
Currently the msm platform driver is a multiplex handling several cases:
- headless GPU-only driver,
- MDP4 with flat device nodes,
- MDP5/DPU MDSS with all the nodes being children of MDSS node.
This results in not-so-perfect code, checking the hardware version
(MDP4/MDP5/DPU) in several places,
The msm_mdss serves several roles at this moment. It provides IRQ domain
used by MDP5 and DPU drivers but it also serves as a component master
for both those usecases. MDP4 (which does not have separate MDSS device)
is the component master on it's own.
Remove this assymmetry and make both MDP5 and
On 2022/3/23 04:49, Rob Herring wrote:
+
+ if (state) {
+ val = readb(li2c->dir_reg);
+ val |= mask;
+ writeb(val, li2c->dir_reg);
+ } else {
+ val = readb(li2c->dir_reg);
+ val &= ~mask;
+ writeb(va
Hi Cong,
well than Dave must decide what to do here.
When QXL emulates a device it should also not use memory accesses which
won't work on a physical device.
BTW: Your patch is really buggy, it misses the cases in ttm_module.c
Regards,
Christian.
Am 23.03.22 um 09:48 schrieb liuco...@kylino
On Wed, 23 Mar 2022, Lee Shawn C wrote:
> From: Cooper Chiou
>
> Tag code stored in bit7:5 for CTA block byte[3] is not the same as
> CEA extension block definition. Only check CEA block has
> basic audio support.
>
> Cc: Jani Nikula
> Cc: Shawn C Lee
> Cc: intel-gfx
> Signed-off-by: Cooper Ch
On 2022-03-23 07:15, Christian König wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM boards doesn't allow unaligned access to MMIO
Am 23.03.22 um 10:45 schrieb Robin Murphy:
On 2022-03-23 07:15, Christian König wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM b
Only an EDID CEA extension has byte #3, while the CTA DisplayID Data
Block does not. Don't interpret bogus data for color formats.
For most displays it's probably an unlikely scenario you'd have a CTA
DisplayID Data Block without a CEA extension, but they do exist.
Fixes: e28ad544f462 ("drm/edid:
On 18/02/2022 13:03, Ville Syrjala wrote:
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
ex
On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote:
> On 2022-03-23 07:15, Christian König wrote:
> > Am 22.03.22 um 10:34 schrieb Cong Liu:
> > > qxl use ioremap to map ram_header and rom, in the arm64 implementation,
> > > the device is mapped as DEVICE_nGnRE, it can not support unalign
On Thu, 17 Mar 2022, Lee Shawn C wrote:
> According to HDMI 2.1 spec.
>
> "The HDMI Forum EDID Extension Override Data Block (HF-EEODB)
> is utilized by Sink Devices to provide an alternate method to
> indicate an EDID Extension Block count larger than 1, while
> avoiding the need to present a VES
On 18/02/2022 13:03, Ville Syrjala wrote:
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the des
Hi Cong,
yes I've seen that, but that is still not sufficient.
You need to update the check in ttm_module.c as well or otherwise your
userspace mapping might not work correctly either.
Regards,
Christian.
Am 23.03.22 um 11:00 schrieb liuco...@kylinos.cn:
Hi Christian,
another commit fix
On 18/02/2022 13:03, Ville Syrjala wrote:
From: Ville Syrjälä
This on stack middle man mode looks entirely pointless.
Just duplicate the original mode directly.
Cc: Rob Clark
Cc: Sean Paul
Cc: Abhinav Kumar
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by:
On Tue, Mar 22, 2022 at 05:37:40PM -0400, Lyude Paul wrote:
> OK so - this has become a bit of a larger rabbit hole. I've been putting quite
> a bit of work into this and I think I'm starting to make some progress -
> although on a different aspect of this issue. After talking with danvet they
> re
On 2022-03-23 10:11, Gerd Hoffmann wrote:
On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote:
On 2022-03-23 07:15, Christian K�nig wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nG
On Mon, Mar 21, 2022 at 02:25:56PM +0100, Christian König wrote:
> This way we finally fix the problem that new resource are
> not immediately evict-able after allocation.
>
> That has caused numerous problems including OOM on GDS handling
> and not being able to use TTM as general resource manage
Since the last commit, the max_pclk_khz became constant, it's set to
DP_MAX_PIXEL_CLK_KHZ and never changed afterwards. Remove it completely
and use DP_MAX_PIXEL_CLK_KHZ directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_debug.c | 2 --
drivers/gpu/drm/msm/dp/dp_display.c
Since the commit ab205927592b ("drm/msm/dp: remove mode hard-coding in
case of DP CTS") the function dp_panel_get_modes() doesn't use (or fill)
the dp_mode argument. Drop it completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
drivers/gpu/drm/msm/dp/dp_pane
As noted by Ville Syrjälä [1] the dp_connector_get_modes() has weird
on-stack interim copy of the mode. When reviewing the mentioned patch I
noticed that the rest of the code in dp_connector_get_modes() is weird,
unused since September of 2020 and can be removed. This series removes
dead weird code
Since dp_panel_get_modes() handling for dp_mode was removed,
dp_display_get_modes also doesn't change the passed dp_mode, drop the
unused dp_mode variable being allocated unused and then freed.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 8 ++--
drivers/gpu/drm
On Mon, Mar 21, 2022 at 02:25:59PM +0100, Christian König wrote:
> Those functions are going to become more complex, don't inline them any
> more.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 31 +++
> include/drm/ttm/ttm_bo_api.h | 30 ++-
On 22/03/2022 01:37, Ville Syrjälä wrote:
On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote:
On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
wrote:
On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote:
drm: Add drm_mode_init()
drm/bridge: Use drm_mode_copy()
drm/im
On Wed, Mar 23, 2022 at 11:35:02AM +0100, Daniel Vetter wrote:
> On Mon, Mar 21, 2022 at 02:25:56PM +0100, Christian König wrote:
> > This way we finally fix the problem that new resource are
> > not immediately evict-able after allocation.
> >
> > That has caused numerous problems including OOM o
On Mon, Mar 21, 2022 at 02:26:00PM +0100, Christian König wrote:
> Instead of providing the bulk move structure for each LRU update set
> this as property of the BO. This should avoid costly bulk move rebuilds
> with some games under RADV.
>
> v2: some name polishing, add a few more kerneldoc word
On 22-03-22, 19:59, Marijn Suijten wrote:
> On 2022-03-22 22:46:50, Vinod Koul wrote:
> > On 17-02-22, 16:11, Marijn Suijten wrote:
> > > Hi Vinod,
> > >
> > > Thanks for taking time to go through this review, please find some
> > > clarifications below.
> > >
> > > On 2022-02-17 16:44:04, Vinod
Arm64 also need the function in commit b849bec29a99 ("drm/ttm:
ioremap buffer according to TTM mem caching setting"), so enable
it. The following Call Trace captured in arm64 with qxl card.
[5.609923] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[5.610592] pstate: 004
Hello.
The Linux kernel provides kernel-global WQs (namely, system_wq,
system_highpri_wq,
system_long_wq, system_unbound_wq, system_freezable_wq,
system_power_efficient_wq
and system_freezable_power_efficient_wq). But since attempt to flush
kernel-global
WQs has possibility of deadlock, Tejun H
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
6.620515] pc : setup_hw_slot+0x24/0x60 [qxl]
[6.620961] lr : setup_slot+0x34/0xf0 [qxl]
[6.621376] sp : 800012b73760
[6.621701] x29:
This fixes the following sparse warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1910:16: warning:
Using
plain integer as NULL pointer
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Am Freitag, den 18.03.2022, 17:53 + schrieb Dave Stevenson:
> On Fri, 18 Mar 2022 at 17:16, Maxime Ripard wrote:
> > On Fri, Mar 18, 2022 at 05:05:11PM +, Dave Stevenson wrote:
> > > Hi Maxime
> > >
> > > On Fri, 18 Mar 2022 at 16:35, Maxime Ripard wrote:
> > > > On Mon, Mar 07, 2022 at
Hi Christian,according to 'Arm Architecture Reference Manual Armv8,for Armv8-Aarchitecture profile' pdf E2.6.5E2.6.5 Generation of Alignment faults by load/store multiple accesses to Device memory When FEAT_LSMAOC is implemented and the value of the applicable nTLSMD field is 0, any memory access b
On maandag 21 maart 2022 19:49:56 CET Dominique Dumont wrote:
> On Monday, 21 March 2022 09:57:59 CET Thorsten Leemhuis wrote:
> > Dominique/Salvatore/Eric, what's the status of this regression?
> > According to the debian bug tracker the problem is solved with 5.16 and
> > 5.17, but was 5.15 ever
Hi
On Monday, 21 March 2022 09:57:59 CET Thorsten Leemhuis wrote:
> Dominique/Salvatore/Eric, what's the status of this regression?
> According to the debian bug tracker the problem is solved with 5.16 and
> 5.17, but was 5.15 ever fixed?
I don't think so.
On kernel side, the commit fixing this
My problem has never been fixed. The proposed patch has been applied to 5.15. I
do not remerber which version 28 maybe.
I still have à RIP in pm_suspend. Did not test the Last two 15 versions.
I can leave with 5.10 est using own compiled kernels.
Thanks for asking.
21 mars 2022 09:58:01 Thorst
This fixes the following sparse warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/rc_calc_fpu.c:71:40: warning:
Using
plain integer as NULL pointer
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi Christian,another commit fix the case in ttm. I send two patches at the same time, but seems I miss '--cover-letter' when run format-patch or some other bad operation.Regards,Cong.
主 题：Re: 回复: Re: [PATCH v1 1/2] drm/qxl: replace ioremap by ioremap_cache on arm64
日 期：2
Clean up the following includecheck warning:
drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is
included more than once.
No functional change.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_
On Sat, Mar 19, 2022 at 11:27:51AM +0100, Christophe Leroy wrote:
> While working at fixing powerpc headers, I ended up with the
> following error.
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c:48:1: error:
> conflicting types for 'prom_init'; have 'void *(struct nvkm_bios *, con
This fixes the following sparse warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:865:16:
warning: Using
plain integer as NULL pointer
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
On 6/11/21 04:09, Jason Ekstrand wrote:
This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf. Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a syn
Hi Arunpravin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on a678f97326454b60ffbbde6abf52d23997d71a27]
url:
https://github.com/0day-ci/linux/commits/Arunpravin-Paneer-Selvam/drm-amdgpu-add-drm-buddy-support-to-amdgpu/20220323-142749
base
On 17-02-22, 22:44, Marijn Suijten wrote:
> On 2022-02-10 16:04:20, Vinod Koul wrote:
> > For DSC to work we typically need a 2,2,1 configuration. This should
> > suffice for resolutions up to 4k. For more resolutions like 8k this won't
> > work.
> >
> > Also, it is better to use 2 LMs and DSC ins
On 17-02-22, 23:37, Marijn Suijten wrote:
> On 2022-02-10 16:04:20, Vinod Koul wrote:
> > For DSC to work we typically need a 2,2,1 configuration. This should
> > suffice for resolutions up to 4k. For more resolutions like 8k this won't
> > work.
> >
> > Also, it is better to use 2 LMs and DSC ins
On Mon, Mar 21, 2022 at 02:25:56PM +0100, Christian König wrote:
> This way we finally fix the problem that new resource are
> not immediately evict-able after allocation.
>
> That has caused numerous problems including OOM on GDS handling
> and not being able to use TTM as general resource manage
On Wed, 23 Mar 2022, Jani Nikula wrote:
> On Thu, 17 Mar 2022, Lee Shawn C wrote:
>> According to HDMI 2.1 spec.
>>
>> "The HDMI Forum EDID Extension Override Data Block (HF-EEODB)
>> is utilized by Sink Devices to provide an alternate method to
>> indicate an EDID Extension Block count larger th
On Wednesday, March 23rd, 2022 at 13:02, Jani Nikula
wrote:
> Simon and Daniel also tell me on IRC we can't just modify the base block
> extension count to match HF-EEODB to dodge the problem, because the EDID
> gets exposed to userspace.
I'm not familiar how the EDID blob gets exposed to user-
On Wed, 23 Mar 2022, Simon Ser wrote:
> On Wednesday, March 23rd, 2022 at 13:02, Jani Nikula
> wrote:
>
>> Simon and Daniel also tell me on IRC we can't just modify the base block
>> extension count to match HF-EEODB to dodge the problem, because the EDID
>> gets exposed to userspace.
>
> I'm no
Am 23.03.22 um 12:59 schrieb Daniel Vetter:
On Mon, Mar 21, 2022 at 02:25:56PM +0100, Christian König wrote:
This way we finally fix the problem that new resource are
not immediately evict-able after allocation.
That has caused numerous problems including OOM on GDS handling
and not being able
在2022年3月23日三月 上午7:07，Sui Jingfeng写道：
> On 2022/3/23 10:29, Jiaxun Yang wrote:
>> If you want to blame somebody for the problem then please don't
>> blame us. We tried very hard to fit all those stuff into kernel's model
>> of devices. You should blame those who did the initial design of
>> Loong
On Thu, 17 Mar 2022, Lee Jones wrote:
> On Thu, 17 Mar 2022, philip yang wrote:
>
> >On 2022-03-17 11:13 a.m., Lee Jones wrote:
> >
> > On Thu, 17 Mar 2022, Felix Kuehling wrote:
> >
> >
> > Am 2022-03-17 um 11:00 schrieb Lee Jones:
> >
> > Good afternoon Felix,
> >
> > Thanks for your r
On Wed, Mar 23, 2022 at 09:53:14AM +0800, Sui Jingfeng wrote:
>
> On 2022/3/23 00:06, Jiaxun Yang wrote:
> >
> >
> > 在 2022/3/22 13:38, Sui Jingfeng 写道:
> > >
> > > On 2022/3/22 21:05, Jiaxun Yang wrote:
> > > >
> > > >
> > > > 在 2022/3/21 16:29, Sui Jingfeng 写道:
> > > > > From: suijingfeng
On Wed, Mar 23, 2022 at 11:38:55AM +0800, Sui Jingfeng wrote:
>
> On 2022/3/23 04:55, Rob Herring wrote:
> > On Tue, Mar 22, 2022 at 10:33:45AM +0800, Sui Jingfeng wrote:
> > > On 2022/3/22 07:20, Rob Herring wrote:
> > > > On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
> > > > > Fr
On Mon, Mar 21, 2022 at 02:58:34PM +0100, Christian König wrote:
> This function allows to replace fences from the shared fence list when
> we can gurantee that the operation represented by the original fence has
> finished or no accesses to the resources protected by the dma_resv
> object any more
On Wed, Mar 23, 2022 at 12:12:43PM +0800, Sui Jingfeng wrote:
>
> On 2022/3/23 04:49, Rob Herring wrote:
> > > +/*
> > > + * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
> > > + *
> > > + * @index : output channel index, 0 for DVO0, 1 for DVO1
> > > + */
> > > +struct lsdc_i2c *l
Hi,
On 21/03/2022 16:45, Alan Previn wrote:
This series:
1. Enables support of GuC to report error-state-capture
using a list of MMIO registers the driver registers
and GuC will dump, log and notify right before a GuC
triggered engine-reset event.
2. Updates the ADS blo
On Mon, Mar 21, 2022 at 02:58:37PM +0100, Christian König wrote:
> Use dma_resv_wait() instead of extracting the exclusive fence and
> waiting on it manually.
>
> Signed-off-by: Christian König
> Reviewed-by: Daniel Vetter
> Cc: Jason Gunthorpe
Jason, can you ack this for merging through drm t
On Wed, 23 Mar 2022 at 13:20, Christian König
wrote:
>
> Am 23.03.22 um 12:59 schrieb Daniel Vetter:
> > On Mon, Mar 21, 2022 at 02:25:56PM +0100, Christian König wrote:
> >> This way we finally fix the problem that new resource are
> >> not immediately evict-able after allocation.
> >>
> >> That
On Mon, Mar 21, 2022 at 02:58:43PM +0100, Christian König wrote:
> Drivers should never touch this directly.
>
> v2: fix rebase clash
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
I guess as soon as we have the rdma ack you can land up to this patch?
-Daniel
> ---
> drivers/
Hi Dmitry,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[cannot apply to v5.17 next-20220323]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
h
On Mon, Mar 21, 2022 at 02:58:44PM +0100, Christian König wrote:
> So far we had the approach of using a directed acyclic
> graph with the dma_resv obj.
>
> This turned out to have many downsides, especially it means
> that every single driver and user of this interface needs
> to be aware of this
Am 23.03.22 um 14:36 schrieb Daniel Vetter:
On Wed, 23 Mar 2022 at 13:20, Christian König
wrote:
Am 23.03.22 um 12:59 schrieb Daniel Vetter:
On Mon, Mar 21, 2022 at 02:25:56PM +0100, Christian König wrote:
This way we finally fix the problem that new resource are
not immediately evict-able af
On Wed, 23 Mar 2022 at 08:19, Christian König wrote:
> Am 23.03.22 um 09:10 schrieb Paul Menzel:
> > Sorry, I disagree. The motivation needs to be part of the commit
> > message. For example see recent discussion on the LWN article
> > *Donenfeld: Random number generator enhancements for Linux 5.1
On Tue, Mar 8, 2022 at 1:36 PM Rob Herring wrote:
>
> On Tue, Mar 1, 2022 at 6:14 PM Dmitry Baryshkov
> wrote:
> >
> > Add missing brace in dpu-qcm2290.yaml. While we are at it, also fix
> > indentation for another brace, so it matches the corresponding line.
> >
> > Reported-by: Rob Herring
> >
Hi,
On Mon, 21 Mar 2022 at 16:02, Rob Clark wrote:
> On Mon, Mar 21, 2022 at 2:30 AM Christian König
> wrote:
> > Well you can, it just means that their contexts are lost as well.
>
> Which is rather inconvenient when deqp-egl reset tests, for example,
> take down your compositor ;-)
Yeah. Or a
On Wed, Mar 23, 2022 at 12:11:50PM +0200, Jani Nikula wrote:
> On Thu, 17 Mar 2022, Lee Shawn C wrote:
> > According to HDMI 2.1 spec.
> >
> > "The HDMI Forum EDID Extension Override Data Block (HF-EEODB)
> > is utilized by Sink Devices to provide an alternate method to
> > indicate an EDID Extens
On 17-02-22, 23:32, Marijn Suijten wrote:
> On 2022-02-10 16:04:17, Vinod Koul wrote:
> > We need to configure the encoder for DSC configuration and calculate DSC
> > parameters for the given timing so this patch adds that support by
> > adding dpu_encoder_prep_dsc() which is invoked when DSC is en
On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone wrote:
>
> On Wed, 23 Mar 2022 at 08:19, Christian König
> wrote:
> > Am 23.03.22 um 09:10 schrieb Paul Menzel:
> > > Sorry, I disagree. The motivation needs to be part of the commit
> > > message. For example see recent discussion on the LWN article
Hi Alex,
On Wed, 23 Mar 2022 at 14:42, Alex Deucher wrote:
> On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone wrote:
> > On Wed, 23 Mar 2022 at 08:19, Christian König
> > wrote:
> > > Well the key point is it's not about you to judge that.
> > >
> > > If you want to complain about the commit mess
On Wed, Mar 23, 2022 at 12:04:38PM +0200, Jani Nikula wrote:
> Only an EDID CEA extension has byte #3, while the CTA DisplayID Data
> Block does not. Don't interpret bogus data for color formats.
I think what we might want eventually is a cleaner split between
the CTA data blocks vs. the rest of t
On Wed, Mar 23, 2022 at 01:39:44PM +0300, Dmitry Baryshkov wrote:
> On 22/03/2022 01:37, Ville Syrjälä wrote:
> > On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote:
> >> On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
> >> wrote:
> >>>
> >>> On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville
On Wed, 23 Mar 2022 at 15:07, Daniel Stone wrote:
>
> Hi,
>
> On Mon, 21 Mar 2022 at 16:02, Rob Clark wrote:
> > On Mon, Mar 21, 2022 at 2:30 AM Christian König
> > wrote:
> > > Well you can, it just means that their contexts are lost as well.
> >
> > Which is rather inconvenient when deqp-egl r
On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone wrote:
>
> Hi Alex,
>
> On Wed, 23 Mar 2022 at 14:42, Alex Deucher wrote:
> > On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone wrote:
> > > On Wed, 23 Mar 2022 at 08:19, Christian König
> > > wrote:
> > > > Well the key point is it's not about you to
Am 23.03.22 um 15:00 schrieb Daniel Stone:
On Wed, 23 Mar 2022 at 08:19, Christian König wrote:
Am 23.03.22 um 09:10 schrieb Paul Menzel:
Sorry, I disagree. The motivation needs to be part of the commit
message. For example see recent discussion on the LWN article
*Donenfeld: Random number gen
On Wed, 23 Mar 2022, Ville Syrjälä wrote:
> On Wed, Mar 23, 2022 at 12:04:38PM +0200, Jani Nikula wrote:
>> Only an EDID CEA extension has byte #3, while the CTA DisplayID Data
>> Block does not. Don't interpret bogus data for color formats.
>
> I think what we might want eventually is a cleaner s
On Tue, Mar 22, 2022 at 11:40:30PM +0200, Jani Nikula wrote:
> Add abstractions for getting the number of EDID extension blocks and the
> total EDID size in bytes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 18 ++
> include/drm/drm_edid.h | 2 ++
> 2
On Wed, Mar 23, 2022 at 02:44:17PM +0100, Christian König wrote:
> Am 23.03.22 um 14:36 schrieb Daniel Vetter:
> > On Wed, 23 Mar 2022 at 13:20, Christian König
> > wrote:
> > > Am 23.03.22 um 12:59 schrieb Daniel Vetter:
> > > > On Mon, Mar 21, 2022 at 02:25:56PM +0100, Christian König wrote:
> >
On Wed, 23 Mar 2022 at 15:14, Alex Deucher wrote:
> On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone wrote:
> > That's not what anyone's saying here ...
> >
> > No-one's demanding AMD publish RTL, or internal design docs, or
> > hardware specs, or URLs to JIRA tickets no-one can access.
> >
> > This
On Tue, Mar 22, 2022 at 11:40:31PM +0200, Jani Nikula wrote:
> Use the block count and size helpers in all drm core code.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_connector.c | 2 +-
> drivers/gpu/drm/drm_debugfs.c | 3 +--
> drivers/gpu/drm/drm_edid.c | 14 +++
[Adding Marek and Andrey as well]
Am 23.03.22 um 16:14 schrieb Daniel Vetter:
On Wed, 23 Mar 2022 at 15:07, Daniel Stone wrote:
Hi,
On Mon, 21 Mar 2022 at 16:02, Rob Clark wrote:
On Mon, Mar 21, 2022 at 2:30 AM Christian König
wrote:
Well you can, it just means that their contexts are los
Am 23.03.22 um 16:24 schrieb Daniel Stone:
On Wed, 23 Mar 2022 at 15:14, Alex Deucher wrote:
On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone wrote:
That's not what anyone's saying here ...
No-one's demanding AMD publish RTL, or internal design docs, or
hardware specs, or URLs to JIRA tickets n
1 - 100 of 160 matches
Mail list logo
