Hi Linus,
Some fixes for rc1 that came in the past weeks, mainly a bunch of
amdgpu fixes, some i915 and the rest are misc around the place. I'm
sending this a bit early so some more stuff may show up, but I'll
probably take tomorrow off.
Dave.
drm-next-2021-07-08-1:
drm fixes for 5.14-rc1
On Wed, 07 Jul 2021, 4:14 p.m, Jani Nikula wrote:
>On Wed, 07 Jul 2021, Lee Shawn C wrote:
>> Refer to DP link CTS 1.2/1.4 spec, the following test case request
>> source read DPCD 200h - 205h to get latest link status from sink.
>>
>> (4.3.2.4) Handling of IRQ HPD Pulse with No Error Status
Hi all,
On Thu, 3 Jun 2021 19:32:42 +1000 Stephen Rothwell
wrote:
>
> After merging the drm tree, today's linux-next build (htmldocs) produced
> these warnings:
>
> Documentation/gpu/driver-uapi.rst:2412: WARNING: Duplicate C declaration,
> also defined at gpu/rfc/i915_gem_lmem:1393.
>
Auto-generated diff between internal/internal..internal
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 190 +-
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 6 -
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 73 ++---
Based on upstream feedback the set_parallel extension isn't suitable as
it looks a bit too much like the bonding extension. Introduce a
set_parallel2 extension which configures parallel submission in a single
extension and in a single slot. This compares to old set_parallel
extension which
Based on upstream feedback [1] the current set_parallel extension isn't
suitable. Add a single patch to DII implementing the new interface
agreed two upstream [2]. Intended to enable the UMDs with the upstream
interface while maintaining the old interface on DII.
Quick IGT to prove this is
This adds a driver for panels based on the WideChips WS2401 display
controller. This display controller is used in the Samsung LMS380KF01
display found in the Samsung GT-I8160 (Codina) mobile phone and
possibly others.
As is common with Samsung displays manufacturer commands are necessary
to
This adds device tree bindings for the Samsung Mobile Displays
LMS380KF01 RGB DPI display panel.
Cc: devicet...@vger.kernel.org
Cc: phone-de...@vger.kernel.org
Cc: Douglas Anderson
Cc: Noralf Trønnes
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- No changes just resending with the
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.
If a panel's EDID is broken, there may be an override EDID set
Panel is 800x1280, but mounted on a laptop form factor, sideways.
Reviewed-by: Hans de Goede
Signed-off-by: Anisse Astier
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
This patch series is for making the GPD Win Max display usable with
Linux.
The GPD Win Max is a small laptop, and its eDP panel does not send an
EDID over DPCD; the EDID is instead available in the intel opregion, in
mailbox #5 [1]
The first patch is based on Jani's patch series [2] adding
On Wed, Jul 07, 2021 at 12:39:28PM -0700, Matt Roper wrote:
On Wed, Jul 07, 2021 at 11:13:24AM -0700, Lucas De Marchi wrote:
Commit 161058fb899e ("drm/i915: Add remaining conversions to GRAPHICS_VER")
did the last conversions to the new macros for version checks, but some
some changes sneaked
Le Wed, Jul 07, 2021 at 02:57:47PM -0500, Daniel Dadap a écrit :
> On 6/1/21 5:43 PM, Anisse Astier wrote:
> >
> > Le Tue, Jun 01, 2021 at 06:50:24PM +0300, Ville Syrj?l? a ?crit :
> > > On Mon, May 31, 2021 at 10:46:41PM +0200, Anisse Astier wrote:
> > > > The ACPI OpRegion Mailbox #5 ASLE
Hi,
On 07.07.2021 21:09, Matthew Brost wrote:
> CTB writes are now in the path of command submission and should be
> optimized for performance. Rather than reading CTB descriptor values
> (e.g. head, tail) which could result in accesses across the PCIe bus,
> store shadow local copies and only
On Wed, Jul 07, 2021 at 01:21:35PM -0700, John Harrison wrote:
> On 7/7/2021 11:56, Matthew Brost wrote:
>
> > Ok, I sent it but I looks like patchworks didn't like it. Anyways we
> > should be able to review that patch.
> >
> > Matt
> Maybe because it came out as 6/56 instead of 6/7? Also, not
On 7/7/2021 11:56, Matthew Brost wrote:
Ok, I sent it but I looks like patchworks didn't like it. Anyways we
should be able to review that patch.
Matt
Maybe because it came out as 6/56 instead of 6/7? Also, not sure if it
needs to be in reply to 0/7 or 6/7?
John.
On Wed, Jul 7, 2021 at 12:15 AM Christoph Hellwig wrote:
>
> On Wed, Jul 07, 2021 at 09:10:26AM +0200, Christian K??nig wrote:
> > Well, the original code all this is based on already had the comment that
> > this really belong into the page allocator.
> >
> > The key point is traditionally only
On Wed, Jul 07, 2021 at 11:13:25AM -0700, Lucas De Marchi wrote:
> Now that all the codebase is converted to the new *VER macros, remove
> the old GEN ones.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
We're still going to need another patch or two to kill off
IS_GEN9_{BC,LP},
On Wed, Jul 07, 2021 at 11:13:24AM -0700, Lucas De Marchi wrote:
> Commit 161058fb899e ("drm/i915: Add remaining conversions to GRAPHICS_VER")
> did the last conversions to the new macros for version checks, but some
> some changes sneaked in to use INTEL_GEN. Remove the last users so
> we can
On Wed, Jul 07, 2021 at 11:13:23AM -0700, Lucas De Marchi wrote:
> Commit c816723b6b8a ("drm/i915/gt: replace IS_GEN and friends with
> GRAPHICS_VER") converted INTEL_GEN and friends to the new version check
> macros. Meanwhile, some changes sneaked in to use INTEL_GEN. Remove the
> last users so
On Tue, Jul 6, 2021 at 11:38 PM Christoph Hellwig wrote:
> On Wed, Jun 30, 2021 at 01:34:17AM +, John Stultz wrote:
> > This adds a shrinker controlled page pool, extracted
> > out of the ttm_pool logic, and abstracted out a bit
> > so it can be used by other non-ttm drivers.
>
> Can you
On Wed, Jul 07, 2021 at 11:19:01AM -0700, John Harrison wrote:
> On 7/7/2021 10:50, Matthew Brost wrote:
> > On Tue, Jul 06, 2021 at 03:51:00PM -0700, John Harrison wrote:
> > > On 7/6/2021 15:20, Matthew Brost wrote:
> > > > CTB writes are now in the path of command submission and should be
> > >
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely
[+cc linux-pci]
On Mon, Jul 5, 2021 at 5:04 AM Huacai Chen wrote:
>
> Currently, vga_arb_device_init() selects the first probed VGA device
> with VGA legacy resources enabled as the default device. However, some
> BMC-based VGA cards (e.g., AST2500 and HiSilicon D05) don't enable VGA
> legacy
On Wed, 07 Jul 2021, Lucas De Marchi wrote:
> Finish the conversion to the new VER macros and nuke the old macros so
> we don't have more changes sneaking in.
>
> Initially I thought about waiting for a backmerge from drm-next in
> drm-intel-next so I could use a topic branch to finish the
On 7/7/2021 10:50, Matthew Brost wrote:
On Tue, Jul 06, 2021 at 03:51:00PM -0700, John Harrison wrote:
On 7/6/2021 15:20, Matthew Brost wrote:
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head,
Finish the conversion to the new VER macros and nuke the old macros so
we don't have more changes sneaking in.
Initially I thought about waiting for a backmerge from drm-next in
drm-intel-next so I could use a topic branch to finish the conversion
and nuke the macro, merging the topic branch in
Commit 161058fb899e ("drm/i915: Add remaining conversions to GRAPHICS_VER")
did the last conversions to the new macros for version checks, but some
some changes sneaked in to use INTEL_GEN. Remove the last users so
we can remove the macros.
Signed-off-by: Lucas De Marchi
---
Now that all the codebase is converted to the new *VER macros, remove
the old GEN ones.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index
Commit c816723b6b8a ("drm/i915/gt: replace IS_GEN and friends with
GRAPHICS_VER") converted INTEL_GEN and friends to the new version check
macros. Meanwhile, some changes sneaked in to use INTEL_GEN. Remove the
last users so we can remove the macros.
Signed-off-by: Lucas De Marchi
---
Hi Maxime,
Am 07.07.21 um 15:11 schrieb Maxime Ripard:
> On Tue, Jul 06, 2021 at 05:45:27PM +0200, Stefan Wahren wrote:
>> Hi Maxime,
>>
>> Am 06.07.21 um 15:21 schrieb Maxime Ripard:
>>> Hi Stefan,
>>>
>>> On Tue, Jul 06, 2021 at 12:48:05PM +0200, Stefan Wahren wrote:
Am 06.07.21 um 11:58
From: Rob Clark
It turns out that when the display is enabled by the bootloader, we can
get some transient iommu faults from the display. Which doesn't go over
too well when we install a fault handler that is gpu specific. To avoid
this, defer installing the fault handler until we get around
On Tue, Jul 06, 2021 at 03:51:00PM -0700, John Harrison wrote:
> On 7/6/2021 15:20, Matthew Brost wrote:
> > CTB writes are now in the path of command submission and should be
> > optimized for performance. Rather than reading CTB descriptor values
> > (e.g. head, tail) which could result in
On 2021-07-06 9:08 p.m., Felix Kuehling
wrote:
Am 2021-07-06 um 11:36 a.m. schrieb Colin Ian King:
Hi,
Static analysis with Coverity on linux-next has found a potential null
pointer dereference in function svm_range_restore_pages in
On 2021-07-06 11:36 a.m., Colin Ian
King wrote:
Hi,
Static analysis with Coverity on linux-next has found a potential null
pointer dereference in function svm_range_restore_pages in
drivers/gpu/drm/amd/amdkfd/kfd_svm.c from the following commit:
commit
On 07/07, Beatriz Martins de Carvalho wrote:
> Development vkms_config_debufs in vkms_drv.c for the long term plan of
> making vkms configurable and have multiple different instances it's
> useful to be able to get at the config of each instance in debugfs
Hi Beatriz,
Thanks for your patch.
Hi,
> Gesendet: Mittwoch, 07. Juli 2021 um 17:03 Uhr
> Von: "Chun-Kuang Hu"
> I think you have done many experiment [1] and you bisect between
> 2e4773915223 (good) and be18cd1fcae2 (bad), and you are confused by
> merge commit.
> You may refer to [2] and it may help you to understand git
On Wed, Jul 7, 2021 at 2:58 PM Christian König wrote:
> Am 07.07.21 um 14:13 schrieb Daniel Vetter:
> > On Wed, Jul 7, 2021 at 1:57 PM Christian König
> > wrote:
> >> Am 07.07.21 um 13:14 schrieb Daniel Vetter:
> >>> On Wed, Jul 7, 2021 at 11:30 AM Christian König
> >>> wrote:
> Am
Hi Jagan,
Sorry for the delay. Thanks for the patch.
Tested-by: Yannick Fertre
On 7/4/21 4:03 PM, Jagan Teki wrote:
Finding panel_or_bridge might vary based on associated
DSI devices like DSI panel, bridge, and I2C based DSI
bridge.
1. DSI panels and bridges will invoke the host attach
Hi Jagan,
thanks for the patch.
Tested-by: Yannick Fertre
On 7/4/21 3:59 PM, Jagan Teki wrote:
As dw-mipi-dsi supported all possible ways to find the DSI
devices. It can take multiple iterations for ltdc to find
all components attached to the DSI bridge.
The current ltdc driver failed to
On Wed, 07 Jul 2021, Lee Shawn C wrote:
> Refer to DP link CTS 1.2/1.4 spec, the following test case request
> source read DPCD 200h - 205h to get latest link status from sink.
>
> (4.3.2.4) Handling of IRQ HPD Pulse with No Error Status Bits Set
> (400.3.2.1) Successful Link Re-training After
On Wed, Jul 07, 2021 at 09:39:03AM +0200, Daniel Vetter wrote:
On Wed, Jul 7, 2021 at 12:48 AM Lucas De Marchi
wrote:
On Fri, Jul 02, 2021 at 11:21:10AM +0200, Daniel Vetter wrote:
>On Thu, Jul 1, 2021 at 10:26 PM Matt Roper wrote:
>>
>> From: Paulo Zanoni
>>
>> The current interrupt handler
On Wed, Jul 07, 2021 at 11:34:36AM +0300, Jani Nikula wrote:
On Tue, 06 Jul 2021, Lucas De Marchi wrote:
On Mon, Jul 05, 2021 at 02:52:31PM +0300, Jani Nikula wrote:
On Fri, 02 Jul 2021, Tvrtko Ursulin wrote:
On 01/07/2021 21:23, Matt Roper wrote:
From: Lucas De Marchi
Besides the arch
Am 07.07.21 um 16:19 schrieb Maxime Ripard:
The drm_encoder crtc pointer isn't really fit for an atomic driver,
let's rely on the connector state instead.
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 39
Refer to DP link CTS 1.2/1.4 spec, the following test case request
source read DPCD 200h - 205h to get latest link status from sink.
(4.3.2.4) Handling of IRQ HPD Pulse with No Error Status Bits Set
(400.3.2.1) Successful Link Re-training After IRQ HPD Pulse
Due to Loss of Symbol
On Wed, July 7, 2021, 3:05 p.m., Simon Ser wrote:
>> + DP_LINK_STATUS_SIZE + 2);
>
>Suggestion: use sizeof(full_link_stat) here instead to avoid this getting
>out-of-sync with the real array size?
>
I will update v2 patch later. Thanks for comment!
Best
Hi Dave and Daniel,
Here goes drm-intel-next-fixes-2021-07-07:
One fix targeting stable for display DP VSC, plus DG1 display fix and
a bug fix of IRQs usages and cleanup references to the DRM IRQ midlayer.
Thanks,
Rodrigo.
The following changes since commit
> +DP_LINK_STATUS_SIZE + 2);
Suggestion: use sizeof(full_link_stat) here instead to avoid this
getting out-of-sync with the real array size?
Hi, Frank:
Frank Wunderlich 於 2021年7月6日 週二 下午7:54寫道：
>
> Hi Daniel
>
> > Gesendet: Dienstag, 06. Juli 2021 um 13:20 Uhr
> > Von: "Daniel Vetter"
> > An: "Frank Wunderlich"
> > Cc: "Maarten Lankhorst" , "Maxime
> > Ripard" , "Thomas Zimmermann" ,
> > "David Airlie" , "Daniel Vetter" ,
> >
Hi, Frank:
Frank Wunderlich 於 2021年7月6日 週二 下午7:54寫道：
>
> Hi Daniel
>
> > Gesendet: Dienstag, 06. Juli 2021 um 13:20 Uhr
> > Von: "Daniel Vetter"
> > An: "Frank Wunderlich"
> > Cc: "Maarten Lankhorst" , "Maxime
> > Ripard" , "Thomas Zimmermann" ,
> > "David Airlie" , "Daniel Vetter" ,
> >
Refer to DP link CTS 1.2/1.4 spec, the following test case request
source read DPCD 200h - 205h to get latest link status from sink.
(4.3.2.4) Handling of IRQ HPD Pulse with No Error Status Bits Set
(400.3.2.1) Successful Link Re-training After IRQ HPD Pulse
Due to Loss of Symbol
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on drm-intel/for-linux-next next-20210707]
[cannot apply to anholt/for-next v5.13]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
The drm_encoder crtc pointer isn't really fit for an atomic driver,
let's rely on the connector state instead.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 39 ++
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git
On Tue, Jul 06, 2021 at 05:45:27PM +0200, Stefan Wahren wrote:
> Hi Maxime,
>
> Am 06.07.21 um 15:21 schrieb Maxime Ripard:
> > Hi Stefan,
> >
> > On Tue, Jul 06, 2021 at 12:48:05PM +0200, Stefan Wahren wrote:
> >> Am 06.07.21 um 11:58 schrieb Maxime Ripard:
> >>> Hi,
> >>>
> >>> On Mon, Jul 05,
On Wed, Jul 7, 2021 at 2:31 PM Lucas Stach wrote:
>
> Am Mittwoch, dem 07.07.2021 um 13:37 +0200 schrieb Daniel Vetter:
> > On Wed, Jul 7, 2021 at 10:54 AM Lucas Stach wrote:
> > >
> > > Hi Daniel,
> > >
> > > I'm feeling like I miss a ton of context here, so some maybe dumb
> > >
Am 07.07.21 um 14:13 schrieb Daniel Vetter:
On Wed, Jul 7, 2021 at 1:57 PM Christian König wrote:
Am 07.07.21 um 13:14 schrieb Daniel Vetter:
On Wed, Jul 7, 2021 at 11:30 AM Christian König
wrote:
Am 02.07.21 um 23:38 schrieb Daniel Vetter:
This is a very confusingly named function,
On Wed, Jul 7, 2021 at 2:17 PM Christian König
wrote:
> Am 06.07.21 um 14:23 schrieb Daniel Vetter:
> > On Tue, Jul 06, 2021 at 02:21:10PM +0200, Christoph Hellwig wrote:
> >> On Tue, Jul 06, 2021 at 10:40:37AM +0200, Daniel Vetter wrote:
> Greg, I hope this will be good enough for you to
Am Mittwoch, dem 07.07.2021 um 13:32 +0200 schrieb Daniel Vetter:
> On Wed, Jul 7, 2021 at 1:26 PM Daniel Vetter wrote:
> > On Wed, Jul 7, 2021 at 11:08 AM Lucas Stach wrote:
> > > Am Freitag, dem 02.07.2021 um 23:38 +0200 schrieb Daniel Vetter:
> > > > We need to pull the drm_sched_job_init
Am Mittwoch, dem 07.07.2021 um 13:37 +0200 schrieb Daniel Vetter:
> On Wed, Jul 7, 2021 at 10:54 AM Lucas Stach wrote:
> >
> > Hi Daniel,
> >
> > I'm feeling like I miss a ton of context here, so some maybe dumb
> > questions/remarks below.
> >
> > Am Dienstag, dem 06.07.2021 um 12:12 +0200
Am 06.07.21 um 14:23 schrieb Daniel Vetter:
On Tue, Jul 06, 2021 at 02:21:10PM +0200, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 10:40:37AM +0200, Daniel Vetter wrote:
Greg, I hope this will be good enough for you to merge this code.
So we're officially going to use dri-devel for
On Wed, Jul 7, 2021 at 1:57 PM Christian König wrote:
> Am 07.07.21 um 13:14 schrieb Daniel Vetter:
> > On Wed, Jul 7, 2021 at 11:30 AM Christian König
> > wrote:
> >> Am 02.07.21 um 23:38 schrieb Daniel Vetter:
> >>> This is a very confusingly named function, because not just does it
> >>> init
Am 07.07.21 um 13:14 schrieb Daniel Vetter:
On Wed, Jul 7, 2021 at 11:30 AM Christian König
wrote:
Am 02.07.21 um 23:38 schrieb Daniel Vetter:
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job
Am 07.07.21 um 12:52 schrieb Lucas Stach:
Am Dienstag, dem 06.07.2021 um 07:11 -0400 schrieb Sasha Levin:
From: Tian Tao
[ Upstream commit 7d614ab2f20503ed8766363d41f8607337571adf ]
fixed the below warning:
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check
before
On Mon, Jul 05, 2021 at 02:53:06PM +0100, Matthew Auld wrote:
> For discrete, users of pin_map() needs to obey the same rules at the TTM
> backend, where we map system only objects as WB, and everything else as
> WC. The simplest for now is to just force the correct mapping type as
> per the new
On Tue, Jul 06, 2021 at 05:21:42PM +0800, Huacai Chen wrote:
> Hi, Daniel,
>
> On Tue, Jul 6, 2021 at 4:21 PM Daniel Vetter wrote:
> >
> > On Mon, Jul 05, 2021 at 06:05:03PM +0800, Huacai Chen wrote:
> > > Currently, vga_arb_device_init() selects the first probed VGA device
> > > with VGA legacy
On Wed, Jul 07, 2021 at 09:03:03AM +, Simon Ser wrote:
> Hi,
>
> Thanks for working on this. Do you have plans for user-space
> implementations and IGT?
Note that these parts are mandatory, and there's a patch floating around
further clarifying what's all expected for new properties:
On Wed, Jul 7, 2021 at 10:54 AM Lucas Stach wrote:
>
> Hi Daniel,
>
> I'm feeling like I miss a ton of context here, so some maybe dumb
> questions/remarks below.
>
> Am Dienstag, dem 06.07.2021 um 12:12 +0200 schrieb Daniel Vetter:
> > There's only one exclusive slot, and we must not break the
On Wed, Jul 7, 2021 at 1:26 PM Daniel Vetter wrote:
> On Wed, Jul 7, 2021 at 11:08 AM Lucas Stach wrote:
> > Am Freitag, dem 02.07.2021 um 23:38 +0200 schrieb Daniel Vetter:
> > > We need to pull the drm_sched_job_init much earlier, but that's very
> > > minor surgery.
> > >
> > > Signed-off-by:
On Wed, Jul 7, 2021 at 11:08 AM Lucas Stach wrote:
> Am Freitag, dem 02.07.2021 um 23:38 +0200 schrieb Daniel Vetter:
> > We need to pull the drm_sched_job_init much earlier, but that's very
> > minor surgery.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Lucas Stach
> > Cc: Russell King
> >
On Wed, Jul 7, 2021 at 11:26 AM Christian König
wrote:
>
> Am 02.07.21 um 23:38 schrieb Daniel Vetter:
> > Instead of just a callback we can just glue in the gem helpers that
> > panfrost, v3d and lima currently use. There's really not that many
> > ways to skin this cat.
> >
> > On the naming
On Wed, Jul 7, 2021 at 11:30 AM Christian König
wrote:
>
> Am 02.07.21 um 23:38 schrieb Daniel Vetter:
> > This is a very confusingly named function, because not just does it
> > init an object, it arms it and provides a point of no return for
> > pushing a job into the scheduler. It would be
Am Dienstag, dem 06.07.2021 um 07:11 -0400 schrieb Sasha Levin:
> From: Tian Tao
>
> [ Upstream commit 7d614ab2f20503ed8766363d41f8607337571adf ]
>
> fixed the below warning:
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check
> before some freeing functions is not needed.
On Tue, Jul 06, 2021 at 07:09:37PM -0400, Felix Kuehling wrote:
Am 2021-07-06 um 5:44 p.m. schrieb Alex Deucher:
On Tue, Jul 6, 2021 at 7:16 AM Sasha Levin wrote:
From: Yifan Zhang
[ Upstream commit 631003101c516ea29a74aee59666708857b9a805 ]
If GC has entered CGPG, ringing doorbell > first
On 07.07.2021 02:57, John Harrison wrote:
> On 7/3/2021 01:21, Martin Peres wrote:
>> On 02/07/2021 18:07, Michal Wajdeczko wrote:
>>> On 02.07.2021 10:09, Martin Peres wrote:
On 02/07/2021 10:29, Pekka Paalanen wrote:
> On Thu, 1 Jul 2021 21:28:06 +0200
> Daniel Vetter wrote:
Hi Maxime
On Wed, 7 Jul 2021 at 10:51, Maxime Ripard wrote:
>
> Hi,
>
> Those are three fixes for race conditions we currently have in the vc4 HDMI
> driver with regard to the interrupts handling.
>
> The first two are fixing an issue where the handler will be removed by devm
> after the
Hi John,
On 26.06.2021 02:45, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> There is a new HuC version available for TGL and compatible platforms,
> so switch to using it. Also, there is now a GuC and HuC for ADL-P, so
> use those too.
I recall discussion about splitting UC_FW
Our hotplug handler will currently call the drm_kms_helper_hotplug_event
every time a hotplug interrupt is called.
However, since the device is registered after all the drivers have
finished their bind callback, we have a window between when we install
our interrupt handler and when
The hotplugs interrupt handlers are registered through the
devm_request_threaded_irq function. However, while free_irq is indeed
called properly when the device is unbound or bind fails, it's called
after unbind or bind is done.
In our particular case, it means that on failure it creates a window
The CEC interrupt handlers are registered through the
devm_request_threaded_irq function. However, while free_irq is indeed
called properly when the device is unbound or bind fails, it's called
after unbind or bind is done.
In our particular case, it means that on failure it creates a window
Hi,
Those are three fixes for race conditions we currently have in the vc4 HDMI
driver with regard to the interrupts handling.
The first two are fixing an issue where the handler will be removed by devm
after the resources it uses have been free'd already.
The last one is there to deal with an
Commit 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") removed the
references to the vc4_hdmi_audio_component_drv structure, but not the
structure itself resulting in a warning. Remove it.
Fixes: 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec")
Reported-by: kernel test robot
The vc4_hdmi_audio_prepare function and the functions it's calling have
in several occurences multiple dereferences of either the sample rate or
the number of channels.
It turns out that these variables are also passed through the hdmi codec
parameters structure. Convert all the users to use this
Am 07.07.21 um 09:14 schrieb Christoph Hellwig:
On Wed, Jul 07, 2021 at 09:10:26AM +0200, Christian K??nig wrote:
Well, the original code all this is based on already had the comment that
this really belong into the page allocator.
The key point is traditionally only GPUs used uncached and
Am 02.07.21 um 23:38 schrieb Daniel Vetter:
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job into the scheduler. It would be nice if that's a bit
clearer in the interface.
But the real reason is
Development vkms_config_debufs in vkms_drv.c for the long term plan of
making vkms configurable and have multiple different instances it's
useful to be able to get at the config of each instance in debugfs
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/gpu/drm/vkms/vkms_drv.c | 28
Am 02.07.21 um 23:38 schrieb Daniel Vetter:
Instead of just a callback we can just glue in the gem helpers that
panfrost, v3d and lima currently use. There's really not that many
ways to skin this cat.
On the naming bikeshed: The idea for using _await_ to denote adding
dependencies to a job
We've had many silent hangs where the kernel would look like it just
stalled due to the access to one of the HDMI registers while the
controller was disabled.
Add a warning if we're about to do that so that it's at least not silent
anymore.
Signed-off-by: Maxime Ripard
---
Similarly to what we encountered with the detect hook with DRM, nothing
actually prevents any of the CEC callback from being run while the HDMI
output is disabled.
However, this is an issue since any register access to the controller
when it's powered down will result in a silent hang.
Let's
In order to ease further additions to the CEC enable and disable, let's
split the function into two functions, one to enable and the other to
disable.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 73 --
1 file changed, 44 insertions(+), 29
Since our pre_crtc_configure hook returned void, we didn't implement a
goto-based error path handling, leading to errors like failing to put
back the device in pm_runtime in all the error paths, but also failing
to disable the pixel clock if clk_set_min_rate on the HSM clock fails.
Move to a
In the bind hook, we actually need the device to have the HSM clock
running during the final part of the display initialisation where we
reset the controller and initialise the CEC component.
Failing to do so will result in a complete, silent, hang of the CPU.
Fixes: 411efa18e4b0 ("drm/vc4:
Hi,
This series aims at fixing a complete and silent hang when one tries to use CEC
while the display output is off.
This can be tested with:
echo off > /sys/class/drm/card0-HDMI-A-1/status
cec-ctl --tuner -p 1.0.0.0
cec-compliance
This series addresses it by making sure the HDMI controller is
On Wed, Jul 7, 2021 at 10:06 AM Christian König
wrote:
>
> Am 06.07.21 um 12:12 schrieb Daniel Vetter:
> > Specifically document the new/clarified rules around how the shared
> > fences do not have any ordering requirements against the exclusive
> > fence.
> >
> > But also document all the things
On 06/07/2021 13:48, Alyssa Rosenzweig wrote:
>> My concern is if we ever find a security bug which requires new
>> information/behaviour in the submit ABI to properly fix. In this case it
>> would be appropriate to backport a 'feature' (bug fix) which provides a
>> new ABI but it would need to be
Am Freitag, dem 02.07.2021 um 23:38 +0200 schrieb Daniel Vetter:
> We need to pull the drm_sched_job_init much earlier, but that's very
> minor surgery.
>
> Signed-off-by: Daniel Vetter
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christian Gmeiner
> Cc: Sumit Semwal
> Cc: "Christian König"
>
Hi,
Thanks for working on this. Do you have plans for user-space
implementations and IGT?
Thanks,
Simon
Hi Daniel,
I'm feeling like I miss a ton of context here, so some maybe dumb
questions/remarks below.
Am Dienstag, dem 06.07.2021 um 12:12 +0200 schrieb Daniel Vetter:
> There's only one exclusive slot, and we must not break the ordering.
>
> A better fix would be to us a dma_fence_chain or
This patch comes from the need to display small resolution pictures with
very few DDR usage. In practice, using a background color, produced by the
drm CRTC, around this picture allows to fetch less data in memory than
setting a full frame picture. And therefore the picture in DDR is smaller
than
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background
1 - 100 of 126 matches
Mail list logo
