Quoting Yong Wu (2022-01-14 23:39:52)
> On Fri, 2022-01-14 at 15:30 -0600, Stephen Boyd wrote:
> >
> > This sounds more correct to me. I'm not an expert on runtime PM
> > though
> > as I always have to read the code to remember how it works. if the
> > device isn't ready for runtime PM until the
On Fri, 2022-01-14 at 15:30 -0600, Stephen Boyd wrote:
> Quoting Yong Wu (2022-01-14 01:06:31)
> > On Wed, 2022-01-12 at 20:25 -0800, Stephen Boyd wrote:
> > > >
> > > > [2.654526] [ cut here ]
> > > > [2.68] refcount_t: addition on 0; use-after-free.
> > > >
From: Changcheng Deng
'drm/drm_drv.h' included in 'amdgpu_ttm.c' is duplicated. It is also
included on 53 line.
Reported-by: Zeal Robot
Signed-off-by: Changcheng Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git
On Fri, Jan 14, 2022 at 4:04 AM Guangming.Cao
wrote:
>
> On Fri, 2022-01-14 at 08:16 +0100, Christian König wrote:
> > Am 14.01.22 um 00:26 schrieb John Stultz:
> > > On Thu, Jan 13, 2022 at 5:05 AM Christian König
> > > wrote:
> > > > Am 13.01.22 um 14:00 schrieb Ruhl, Michael J:
> > > > > >
Quoting Kuogee Hsieh (2022-01-14 16:58:32)
> @@ -1363,14 +1368,14 @@ static int dp_pm_suspend(struct device *dev)
> if (dp_power_clk_status(dp->power, DP_CTRL_PM))
> dp_ctrl_off_link_stream(dp->ctrl);
>
> + dp_display_host_phy_exit(dp);
> +
> +
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
--
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume
Group below 4 dp driver related patches into one series.
Kuogee Hsieh (4):
drm/msm/dp: do not initialize phy until plugin interrupt received
drm/msm/dp: populate connector of struct dp_panel
drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
drm/msm/dp: stop link training
Each DP link training contains link training 1 followed by link
training 2. There is maximum of 5 retries of DP link training
before declared link training failed. It is required to stop link
training at end of link training 2 if it is failed so that next
link training 1 can start freshly. This
Quoting Kuogee Hsieh (2022-01-14 14:28:52)
>
> On 1/14/2022 1:41 PM, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2022-01-14 13:11:47)
> >> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> >> b/drivers/gpu/drm/msm/dp/dp_display.c
> >> index 7cc4d21..7cd6222 100644
> >> ---
Now that the cdn-dp driver supports plug-change callbacks, let's wire it
up.
Signed-off-by: Brian Norris
---
(no changes since v1)
sound/soc/rockchip/rk3399_gru_sound.c | 20
1 file changed, 20 insertions(+)
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c
Some audio servers like to monitor a jack device (perhaps combined with
EDID, for audio-presence info) to determine DP/HDMI audio presence.
Signed-off-by: Brian Norris
---
(no changes since v1)
drivers/gpu/drm/rockchip/cdn-dp-core.c | 28 ++
Commit b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound output use spdif")
switched the platform to SPDIF, but we didn't fix up the device tree.
Drop the pinctrl settings, because the 'spdif_bus' pins are either:
* unused (on kevin, bob), so the settings is ~harmless
* used by a different function
This series fixes DP/HDMI audio for RK3399 Gru systems.
First, there was a regression with the switch to SPDIF. Patch 1 can be
taken separately as a regression fix if desired. But it's not quite so
useful (at least on Chrome OS systems) without the second part.
Second, jack detection was never
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume
Each DP link training contains link training 1 followed by link
training 2. There is maximum of 5 retries of DP link training
before declared link training failed. It is required to stop link
training at end of link training 2 if it is failed so that next
link training 1 can start freshly. This
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
Group below 4 dp driver related patches into one series.
Kuogee Hsieh (4):
drm/msm/dp: do not initialize phy until plugin interrupt received
drm/msm/dp: populate connector of struct dp_panel
drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
drm/msm/dp: stop link training
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
--
Quoting Maxime Ripard (2022-01-14 08:15:56)
> On Thu, Jan 13, 2022 at 01:44:25PM -0800, Stephen Boyd wrote:
> >
> > I don't see a problem with re-evaluating the rate every time we call
> > clk_set_rate_range(). That's probably the bug that I can't recall. Can
> > you fix the API so it works that
Quoting Maxime Ripard (2022-01-14 08:15:56)
> On Thu, Jan 13, 2022 at 01:44:25PM -0800, Stephen Boyd wrote:
> > >
> > I don't see a problem with re-evaluating the rate every time we call
> > clk_set_rate_range(). That's probably the bug that I can't recall. Can
> > you fix the API so it works
On 1/14/2022 1:41 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-01-14 13:11:47)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 7cc4d21..7cd6222 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@
Applied. Thanks!
On Fri, Jan 14, 2022 at 5:44 AM Jiapeng Chong
wrote:
>
> dpg_width is being initialized to width but this is never read
> as dpg_width is overwritten later on. Remove the redundant
> initialization.
>
> Cleans up the following clang-analyzer warning:
>
>
Applied. Thanks!
On Fri, Jan 14, 2022 at 4:20 AM wrote:
>
> From: Changcheng Deng
>
> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use "flexible array members" for these
Am 2022-01-10 um 8:39 p.m. schrieb Daniel Phillips:
> Add an ioctl to inquire memory available for allocation by libhsakmt
> per node, allowing for space consumed by page translation tables.
>
> This ioctl is the underlying mechanism for the new memory availability
> library call posted for review
Quoting Kuogee Hsieh (2022-01-14 13:11:47)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 7cc4d21..7cd6222 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -696,12 +699,9 @@ static int
Quoting Yong Wu (2022-01-14 01:06:31)
> On Wed, 2022-01-12 at 20:25 -0800, Stephen Boyd wrote:
> > >
> > > [2.654526] [ cut here ]
> > > [2.68] refcount_t: addition on 0; use-after-free.
> > >
> > > After this patch, the aggregate_driver flow looks ok. But our
>
Each DP link training contains link training 1 followed by link
training 2. There is maximum of 5 retries of DP link training
before declared link training failed. It is required to stop link
training at end of link training 2 if it is failed so that next
link training 1 can start freshly. This
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
--
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume
Group below 4 dp driver related patches into one series.
Kuogee Hsieh (4):
drm/msm/dp: do not initialize phy until plugin interrupt received
drm/msm/dp: populate connector of struct dp_panel
drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
drm/msm/dp: stop link training
Sorry to send a self-reply so quickly, but I noticed an error and want
to make sure this doesn't get merged _too_ quickly before I get to
send a revision! See below:
On Fri, Jan 14, 2022 at 12:17 PM Brian Norris wrote:
>
> Commit b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound output use spdif")
>
https://bugzilla.kernel.org/show_bug.cgi?id=215494
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Quoting Kuogee Hsieh (2022-01-14 09:54:31)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 7cc4d21..2616f7b 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -372,21 +373,38 @@ static int
https://bugzilla.kernel.org/show_bug.cgi?id=215494
--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
This is more likely a mesa bug. I'd suggest filing a bug there:
https://gitlab.freedesktop.org/groups/mesa/-/issues
and closing this one.
--
You may reply to this email to add a
Some audio servers like to monitor a jack device (perhaps combined with
EDID, for audio-presence info) to determine DP/HDMI audio presence.
Signed-off-by: Brian Norris
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 28 ++
drivers/gpu/drm/rockchip/cdn-dp-core.h | 4
Now that the cdn-dp driver supports plug-change callbacks, let's wire it
up.
Signed-off-by: Brian Norris
---
sound/soc/rockchip/rk3399_gru_sound.c | 20
1 file changed, 20 insertions(+)
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c
Commit b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound output use spdif")
switched the platform to SPDIF, but we didn't fix up the device tree.
Fixes: b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound output use spdif")
Signed-off-by: Brian Norris
---
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 10
This series fixes DP/HDMI audio for RK3399 Gru systems.
First, there was a regression with the switch to SPDIF. Patch 1 can be
taken separately as a regression fix if desired. But it's not quite so
useful (at least on Chrome OS systems) without the second part.
Second, jack detection was never
https://bugzilla.kernel.org/show_bug.cgi?id=215494
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300270
--> https://bugzilla.kernel.org/attachment.cgi?id=300270=edit
piglit results & summary up to glsl-vs-raytrace-bug26691
--
You may reply to this email to add a
Starting from DG2, some of the programming previously done by i915 and
the GuC has been moved to the GSC and the relevant registers are no
longer writable by either CPU or GuC. This is also referred to as GuC
deprivilege.
On the i915 side, this affects the WOPCM registers: these are no longer
https://bugzilla.kernel.org/show_bug.cgi?id=215494
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300269
--> https://bugzilla.kernel.org/attachment.cgi?id=300269=edit
kernel .config (kernel 5.16.0, Ryzen 9 5950X)
--
You may reply to this email to add a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=215494
Bug ID: 215494
Summary: [radeon, rv370] Running piglit
shaders@glsl-vs-raytrace-bug26691 test causes hard
lockup & reboot
Product: Drivers
Version: 2.5
On Mon, Jan 10, 2022 at 01:44:19AM +0100, Andrea Parri wrote:
> (Extending Cc: list,)
>
> On Sun, Jan 09, 2022 at 05:55:16PM +0800, Yanming Liu wrote:
> > Commit adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V
> > out of the ring buffer") introduced a notion of maximum packet size
From: Rob Clark
For newer devices which deprecate gpu-id and do matching based on
chip-id, we need this information in cmdstream dumps so that the
decoding tools know how to decode them.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_rd.c | 4
1 file changed, 4 insertions(+)
diff
Hi Helge,
On Fri, Jan 14, 2022 at 7:12 PM Helge Deller wrote:
> The fbdev layer is orphaned, but seems to need some care.
> So I'd like to step up as new maintainer.
>
> Signed-off-by: Helge Deller
Thanks a lot!
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
Hi Matt,
> > The GT has its own properties and in sysfs they should be grouped
> > in the 'gt/' directory.
> >
> > Create a 'gt/' directory in sysfs which will contain gt0...gtN
> > directories related to each tile configured in the GPU. Move the
> > power management files inside those
The fbdev layer is orphaned, but seems to need some care.
So I'd like to step up as new maintainer.
Signed-off-by: Helge Deller
diff --git a/MAINTAINERS b/MAINTAINERS
index 5d0cd537803a..ce47dbc467cc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7583,11 +7583,12 @@ W:
Hi all,
On Wed, Jan 12, 2022 at 11:55:14AM -0800, Iouri Tarassov wrote:
> Implement the LX_DXCREATESYNCFILE IOCTL (D3DKMTCreateSyncFile).
>
> dxgsyncfile is built on top of the Linux sync_file object and
> provides a way for the user mode to synchronize with the execution
> of the device DMA
Hi Matt,
[...]
> > -int intel_uncore_setup_mmio(struct intel_uncore *uncore)
> > +int intel_uncore_setup_mmio(struct intel_uncore *uncore, phys_addr_t
> > phys_addr)
> > {
> > struct drm_i915_private *i915 = uncore->i915;
> > - struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > -
Each DP link training contains link training 1 followed by link
training 2. There is maximum of 5 retries of DP link training
before declared link training failed. It is required to stop link
training at end of link training 2 if it is failed so that next
link training 1 can start freshly. This
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
--
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume
Group below 4 dp driver related patches into one series.
Kuogee Hsieh (4):
drm/msm/dp: do not initialize phy until plugin interrupt received
drm/msm/dp: populate connector of struct dp_panel
drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
drm/msm/dp: stop link training
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
Am 2022-01-14 um 12:26 p.m. schrieb Christian König:
> Am 14.01.22 um 17:44 schrieb Daniel Vetter:
>> Top post because I tried to catch up on the entire discussion here.
>>
>> So fundamentally I'm not opposed to just close this fork() hole once and
>> for all. The thing that worries me from a
On Fri, 2022-01-14 at 20:28 +0800, Liu Yi L wrote:
> Hi Eric,
>
> Hope you are back from new year holiday.:-) Have you got chane to
> consider
> this patch?
Hi Yi Liu,
It's coming up the list, but it's not there yet. Haven't forgotten. :)
Eric
>
> Regards,
> Yi Liu
>
> On 2021/11/30 19:32,
Am 14.01.22 um 17:44 schrieb Daniel Vetter:
Top post because I tried to catch up on the entire discussion here.
So fundamentally I'm not opposed to just close this fork() hole once and
for all. The thing that worries me from a upstream/platform pov is really
only if we don't do it consistently
Hi Linus,
drm-next-2022-01-14:
drm fixes for 5.17-rc1:
drivers fixes:
- i915 fixes for ttm backend + one pm wakelock fix
- amdgpu fixes, fairly big pile of small things all over. Note this
doesn't yet containe the fixed version of the otg sync patch that
blew up
- small driver fixes: meson,
On Thu, Jan 13, 2022 at 12:20:31AM +0200, Andi Shyti wrote:
> The GT has its own properties and in sysfs they should be grouped
> in the 'gt/' directory.
>
> Create a 'gt/' directory in sysfs which will contain gt0...gtN
> directories related to each tile configured in the GPU. Move the
> power
On 1/13/2022 6:42 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-01-13 15:53:36)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 7cc4d21..b3c5404 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@
On Thu, Dec 30, 2021 at 04:06:26PM +, Colin Ian King wrote:
> Pointer bufs is being initialized with a value that is never read, it
> is being re-assigned with a different value later on. The assignment
> is redundant and can be removed. Cleans up clang-scan warning:
>
>
On Wed, Jan 12, 2022 at 09:08:46PM +0300, Pavel Skripkin wrote:
> On 12/30/21 17:26, Pavel Skripkin wrote:
> > Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The
> > problem was in ubuf->pages == ZERO_PTR.
> >
> > ubuf->pagecount is calculated from arguments passed from
On Thu, Jan 13, 2022 at 12:20:30AM +0200, Andi Shyti wrote:
> From: Tvrtko Ursulin
>
> On a multi-tile platform, each tile has its own registers + GGTT
> space, and BAR 0 is extended to cover all of them.
>
> Up to four gts are supported in i915->gt[], with slot zero
> shadowing the existing
On Wed, Dec 22, 2021 at 02:27:25PM +0900, Tomohito Esaki wrote:
> The LINEAR modifier is advertised as default if a driver doesn't specify
> modifiers. However, there are legacy drivers such as radeon that do not
> support modifiers but infer the actual layout of the underlying buffer.
>
Top post because I tried to catch up on the entire discussion here.
So fundamentally I'm not opposed to just close this fork() hole once and
for all. The thing that worries me from a upstream/platform pov is really
only if we don't do it consistently across all drivers.
So maybe as an idea:
- Do
On Thu, Dec 23, 2021 at 10:11:20AM +0100, Christian König wrote:
> Am 22.12.21 um 23:17 schrieb Daniel Vetter:
> > On Fri, Dec 17, 2021 at 03:39:52PM +0100, Christian König wrote:
> > > Hi Daniel,
> > >
> > > looks like this is going nowhere and you don't seem to have time to
> > > review.
> > >
On Tue, Jan 04, 2022 at 04:08:20PM +0100, Christian König wrote:
> Am 22.12.21 um 22:43 schrieb Daniel Vetter:
> > On Tue, Dec 07, 2021 at 01:34:00PM +0100, Christian König wrote:
> > > So far we had the approach of using a directed acyclic
> > > graph with the dma_resv obj.
> > >
> > > This
On Mon, Jan 03, 2022 at 12:13:41PM +0100, Christian König wrote:
> Am 22.12.21 um 22:21 schrieb Daniel Vetter:
> > On Tue, Dec 07, 2021 at 01:33:51PM +0100, Christian König wrote:
> > > Add a function to simplify getting a single fence for all the fences in
> > > the dma_resv object.
> > >
> > >
On Mon, Jan 03, 2022 at 11:48:25AM +0100, Christian König wrote:
> Am 22.12.21 um 22:05 schrieb Daniel Vetter:
> > On Tue, Dec 07, 2021 at 01:33:48PM +0100, Christian König wrote:
> > > This function allows to replace fences from the shared fence list when
> > > we can gurantee that the operation
On Thu, Jan 13, 2022 at 01:44:25PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-01-12 03:46:52)
> > On Tue, Jan 11, 2022 at 07:37:15PM -0800, Stephen Boyd wrote:
> > > Sorry for being super delayed on response here. I'm buried in other
> > > work. +Jerome for exclusive clk API.
> > >
On Fri, Jan 14, 2022 at 03:42:54PM +, Simon Ser wrote:
> On Friday, January 14th, 2022 at 16:17, Andy Shevchenko
> wrote:
>
> > On Fri, Jan 14, 2022 at 03:07:21PM +, Simon Ser wrote:
> > > On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
> > > wrote:
> > >
> > > > Why not enum?
On 03/01/2022 06:47, Miles Chen wrote:
In current implementation, mtk_cec_mask() writes val into target register
and ignores the mask. After talking to our hdmi experts, mtk_cec_mask()
should read a register, clean only mask bits, and update (val | mask) bits
to the register.
Fixes:
On Friday, January 14th, 2022 at 16:17, Andy Shevchenko
wrote:
> On Fri, Jan 14, 2022 at 03:07:21PM +, Simon Ser wrote:
> > On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
> > wrote:
> >
> > > Why not enum?
> >
> > There is no enum for DRM format modifiers.
>
> I'm not sure how
On 13/01/2022 09:21, Jani Nikula wrote:
On Wed, 12 Jan 2022, Colin Ian King wrote:
Don't populate the read-only array flex_regs on the stack but
instead it static const. Also makes the object code a little smaller.
Signed-off-by: Colin Ian King
---
RESEND: Use correct e-mail address for
On Fri, Jan 14, 2022 at 03:24:59PM +0100, Thomas Zimmermann wrote:
> Hi Dave and Daniel,
>
> here are two more fixes for this week. I cherry-picked both from
> drm-misc-next.
>
> Best regards
> Thomas
>
> drm-misc-next-fixes-2022-01-14:
> * atomic helpers: Fix error messages
> * mipi-dbi:
On Fri, Jan 14, 2022 at 03:07:21PM +, Simon Ser wrote:
> On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
> wrote:
>
> > Why not enum?
>
> There is no enum for DRM format modifiers.
I'm not sure how this prevents to use enum in the code instead of const u64.
Any specific reason for
On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
wrote:
> Why not enum?
There is no enum for DRM format modifiers.
https://bugzilla.kernel.org/show_bug.cgi?id=215492
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On 2022-01-14 05:17, Tomohito Esaki wrote:
> If only linear modifier is advertised, since there are many drivers that
> only linear supported, the DRM core should handle this rather than
> open-coding in every driver. However, there are legacy drivers such as
> radeon that do not support modifiers
;> drm_bridge *bridge,
>>>> last_bridge_state =
>>>> drm_atomic_get_new_bridge_state(crtc_state-
>>>>> state,
>>>>
>>>> last_bridge);
>>>>
>>>> - if (last_bridge-&
On 1/14/22 09:16, Jagan Teki wrote:
Hi
[...]
Fill in the actual register names and bits from [1] and [2] and add the
entire register layout, since the documentation for this chip is hard to
come by.
[1]
Hi Dave and Daniel,
here are two more fixes for this week. I cherry-picked both from
drm-misc-next.
Best regards
Thomas
drm-misc-next-fixes-2022-01-14:
* atomic helpers: Fix error messages
* mipi-dbi: Fix buffer mapping
The following changes since commit
drm_atomic_get_new_bridge_state(crtc_state-
> >>> state,
> >>
> >> last_bridge);
> >>
> >> - if (last_bridge->funcs->atomic_get_output_bus_fmts) {
> >> + /*
> >> +* Only negociate with real values if both
On Fri, Jan 14, 2022 at 07:17:52PM +0900, Tomohito Esaki wrote:
> The LINEAR modifier is advertised as default if a driver doesn't specify
> modifiers.
...
> + const uint64_t default_modifiers[] = {
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
+ Comma?
> +
When the host1x syncpts status is dumped via the debugfs, syncpts that
have been allocated but not yet used are not shown and so currently it
is not possible to see all the allocated syncpts. Update the path for
dumping the syncpt status via the debugfs to show all allocated syncpts
even if they
On 1/14/22 14:23, Maarten Lankhorst wrote:
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some
put format.
>> +*/
>> + if (bridge->funcs->atomic_get_input_bus_fmts &&
>> + last_bridge->funcs->atomic_get_output_bus_fmts) {
>> const struct drm_bridge_funcs *funcs = last_bridge->funcs;
>>
>>
On Fri, Jan 14, 2022 at 02:13:30PM +0100, Daniel Vetter wrote:
> On Wed, Jan 12, 2022 at 10:05:37PM -0500, Alex Deucher wrote:
> > Hi Dave, Daniel,
> >
> > Fixes for 5.17.
> >
> > The following changes since commit cb6846fbb83b574c85c2a80211b402a6347b60b1:
> >
> > Merge tag
On Thu, Jan 13, 2022 at 09:29:51AM +0100, Thomas Zimmermann wrote:
> Hi Dave and Daniel,
>
> here's this week's PR for drm-misc-next-fixes.
>
> Best regards
> Thomas
>
> drm-misc-next-fixes-2022-01-13:
> * Fix use of CRTC state's active vs enable in atomic helper
> The following changes since
Now that we require the object lock for all ops, some code handling
race conditions can be removed.
This is required to not take short-term pins inside execbuf.
Signed-off-by: Maarten Lankhorst
Acked-by: Niranjana Vishwanathapura
Reviewed-by: Thomas Hellström
---
We want to remove more members of i915_vma, which requires the locking to
be held more often.
Start requiring gem object lock for i915_vma_unbind, as it's one of the
callers that may unpin pages.
Some special care is needed when evicting, because the last reference to
the object may be held by
Because we will start to require the obj->resv lock for unbinding,
ensure these vma eviction utility functions also take the lock.
This requires some function signature changes, to ensure that the
ww context is passed around, but is mostly straightforward.
Previously this was split up into
Add a flag PIN_VALIDATE, to indicate we don't need to pin and only
protected by the object lock.
This removes the need to unpin, which is done by just releasing the
lock.
eb_reserve is slightly reworked for readability, but the same steps
are still done:
- First pass pins with NONBLOCK.
- Second
Previously, short term pinning in execbuf was required because i915_vma was
effectively independent from objects, and has its own refcount, locking,
lifetime rules and pinning.
This series removes the separate locking, by requiring vma->obj->resv to be
held when pinning and unbinding. This will
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some objects' locks.
Previously, this was spread over
Now that we cannot unbind kill the currently locked object directly
because we're removing short term pinning, we may have to unbind the
object from gtt manually, using a i915_gem_evict_vm() call.
Changes since v1:
- Remove -ENOSPC warning, can still happen with concurrent mmaps
where we can't
On Thu, Jan 13, 2022 at 09:33:03AM +, Tvrtko Ursulin wrote:
>
> Hi Dave and Daniel,
>
> A few fixes for the merge window.
>
> One dealing with runtime PM handling on the PXP unbind path and a few
> regarding the newly added TTM backend support.
>
> Regards,
>
> Tvrtko
>
> ---
>
>
1 - 100 of 159 matches
Mail list logo
