Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v5.19-rc1]
[also build test ERROR on next-20220610]
[cannot apply to drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
https://bugzilla.kernel.org/show_bug.cgi?id=210301
--- Comment #4 from ramast (m...@ramast.me) ---
After more log review it seems I had two problems:
One related to have two graphics card and that's the one resulting in the
"amdgpu_ib_ring_tests" error
https://pastebin.com/Eu7PF3en
Then after
https://bugzilla.kernel.org/show_bug.cgi?id=210301
--- Comment #3 from ramast (m...@ramast.me) ---
I think mine could be a different problem but I'll paste the output here anyway
in case it help anyone. Mine consistently happen the second time my PC goes
into sleep mode (S3).
Let's replace the assortment of intel_gt_* and intel_uncore_* functions
that operate on MCR registers with a cleaner set of interfaces:
* intel_gt_mcr_read -- unicast read from specific instance
* intel_gt_mcr_read_any[_fw] -- unicast read from any non-terminated
instance
*
Handling of multicast/replicated registers is spread across intel_gt.c
and intel_uncore.c today. As multicast handling and the related
steering logic gets more complicated with the addition of new platforms
and new rules it makes sense to centralize it all in one place.
For now the existing
Multicast/replicated (MCR) registers on Intel hardware are a purely
GT-specific concept. Rather than leaving MCR register handling spread
across several places throughout the driver (intel_uncore.c, intel_gt.c,
etc.) with confusing combinations of handler functions living in
different namespaces,
This test will validate we can achieve actual frequency of RP0. Pcode
grants frequencies based on what GuC is requesting. However, thermal
throttling can limit what is being granted. Add a test to request for
max, but don't fail the test if RP0 is not granted due to throttle
reasons.
Also
On 6/10/2022 3:02 PM, Luca Weiss wrote:
From: Vladimir Lypak
There is currently two function for performing reset: dsi_sw_reset and
dsi_sw_reset_restore. Only difference betwean those is that latter one
betwean --> between
assumes that DSI controller is enabled. In contrary former one
On 11/06/2022 01:53, Luca Weiss wrote:
From: Vladimir Lypak
Add the perf data for the mdp found in msm8953.
Signed-off-by: Vladimir Lypak
Signed-off-by: Luca Weiss
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 5 +
1 file changed, 5 insertions(+)
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high penalty.
Employ a similar trick as __seqprop() by
It's one argument, vaddr_iomem, not 2 (vaddr and _iomem).
Signed-off-by: Lucas De Marchi
---
include/linux/iosys-map.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
index 793e5cd50dbf..d092d30f5812 100644
---
Like was done for read, provide the equivalent for write. Even if
current users are not in the hot path, this should future-proof it.
Signed-off-by: Lucas De Marchi
---
include/linux/iosys-map.h | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git
On 6/7/2022 4:08 AM, Miaoqian Lin wrote:
of_graph_get_remote_node() returns remote device node pointer with
refcount incremented, we should use of_node_put() on it
when not need anymore.
Add missing of_node_put() to avoid refcount leak.
Fixes: 86418f90a4c1 ("drm: convert drivers to use
From: Vladimir Lypak
Add the perf data for the mdp found in msm8953.
Signed-off-by: Vladimir Lypak
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
On 6/8/2022 11:08 PM, Dmitry Baryshkov wrote:
On Thu, 9 Jun 2022 at 02:37, Abhinav Kumar wrote:
On 6/8/2022 3:46 PM, Dmitry Baryshkov wrote:
On 09/06/2022 01:42, Abhinav Kumar wrote:
On 6/8/2022 3:38 PM, Dmitry Baryshkov wrote:
On 09/06/2022 01:35, Abhinav Kumar wrote:
On
From: Vladimir Lypak
There is currently two function for performing reset: dsi_sw_reset and
dsi_sw_reset_restore. Only difference betwean those is that latter one
assumes that DSI controller is enabled. In contrary former one assumes
that controller is disabled and executed during power-on.
On Thu, Jun 9, 2022 at 10:33 PM Stefan Wahren wrote:
>
> Hi Peter,
>
> Am 09.06.22 um 13:52 schrieb Peter Robinson:
> > As of Linux 5.18.0, module vc4 apparently isn't working on Raspberry Pi
> > 3B any more.
> >
> > If a monitor is attached to the device, the boot messages show
On Fri, Jun 10, 2022 at 2:55 PM Sam Ravnborg wrote:
>
> Hi Rob,
>
> On Fri, Jun 10, 2022 at 02:38:18PM -0600, Rob Herring wrote:
> > 'arm,rtsm-display' is a panel for Arm, Ltd. virtual platforms (e.g. FVP).
> > The binding has been in use for a long time, but was never documented.
> >
> > Some
This test will validate we can achieve actual frequency of RP0. Pcode
grants frequencies based on what GuC is requesting. However, thermal
throttling can limit what is being granted. Add a test to request for
max, but don't fail the test if RP0 is not granted due to throttle
reasons.
Also
Quoting Kuogee Hsieh (2022-06-06 10:55:39)
> During msm initialize phase, dp_display_unbind() will be called to undo
> initializations had been done by dp_display_bind() previously if there is
> error happen at msm_drm_bind. In this case, core_initialized flag had to
> be check to make sure clocks
Quoting Kuogee Hsieh (2022-05-27 14:32:13)
> During display resolution changes display have to be disabled first
> followed by display enabling with new resolution. Display disable
> will turn off both pixel clock and main link clock so that main link
> have to be re trained during display enable
Hi Rob,
On Fri, Jun 10, 2022 at 02:38:18PM -0600, Rob Herring wrote:
> 'arm,rtsm-display' is a panel for Arm, Ltd. virtual platforms (e.g. FVP).
> The binding has been in use for a long time, but was never documented.
>
> Some users and an example have a 'panel-dpi' compatible, but that's not
>
On Fri, Jun 10, 2022 at 10:43:06PM +0200, Stephen Kitt wrote:
> Hi Sam,
>
> On Fri, 10 Jun 2022 22:22:59 +0200, Sam Ravnborg wrote:
> > On Tue, Jun 07, 2022 at 08:55:16PM +0200, Stephen Kitt wrote:
> > > backlight_properties.fb_blank is deprecated. The states it represents
> > > are handled by
On 10/06/2022 23:46, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-06-09 05:23:42)
The HDMI driver has code to configure extra GPIOs, which predates
pinctrl support. Nowadays all platforms should use pinctrl instead.
Neither of upstreamed Qualcomm platforms uses these properties, so it's
Quoting Dmitry Baryshkov (2022-06-09 05:23:42)
> The HDMI driver has code to configure extra GPIOs, which predates
> pinctrl support. Nowadays all platforms should use pinctrl instead.
> Neither of upstreamed Qualcomm platforms uses these properties, so it's
> safe to drop them.
>
> Reported-by:
Hi Sam,
On Fri, 10 Jun 2022 22:22:59 +0200, Sam Ravnborg wrote:
> On Tue, Jun 07, 2022 at 08:55:16PM +0200, Stephen Kitt wrote:
> > backlight_properties.fb_blank is deprecated. The states it represents
> > are handled by other properties; but instead of accessing those
> > properties directly,
Quoting Dmitry Baryshkov (2022-06-09 04:31:48)
> Conversion to use bulk regulator API omitted filling the pwr_regs with
> proper regulator IDs. This was left unnoticed, since none of my testing
> platforms has used the pwr_regs. Fix this by propagating regulator ids
> properly.
>
> Fixes:
'arm,rtsm-display' is a panel for Arm, Ltd. virtual platforms (e.g. FVP).
The binding has been in use for a long time, but was never documented.
Some users and an example have a 'panel-dpi' compatible, but that's not
needed without a 'panel-timing' node which none of the users have since
commit
On Fri, 10 Jun 2022 21:52:36 +0200, Stephen Kitt wrote:
> On Fri, 10 Jun 2022 21:28:32 +0200, Sam Ravnborg wrote:
> > Hi Stephen.
> > On Fri, Jun 10, 2022 at 07:47:20PM +0200, Stephen Kitt wrote:
> > > Hi Sebastian,
> > >
> > > On Thu, 9 Jun 2022 23:52:36 +0200, Sebastian Reichel
> > >
(I'm sending this as an email as lowest common denominator but feel an issue on
the color-and-hdr repo would be a better interface for productive discussion.
Please pop over to https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/10
if you agree. Hopefully we can drive the discussion there
Hi Stepehen,
On Tue, Jun 07, 2022 at 09:23:29PM +0200, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates
On Fri, 10 Jun 2022 21:28:32 +0200, Sam Ravnborg wrote:
> Hi Stephen.
> On Fri, Jun 10, 2022 at 07:47:20PM +0200, Stephen Kitt wrote:
> > Hi Sebastian,
> >
> > On Thu, 9 Jun 2022 23:52:36 +0200, Sebastian Reichel
> > wrote:
> > > On Tue, Jun 07, 2022 at 08:20:25PM +0200, Stephen Kitt wrote:
Hi Stephen,
On Tue, Jun 07, 2022 at 08:55:16PM +0200, Stephen Kitt wrote:
> backlight_properties.fb_blank is deprecated. The states it represents
> are handled by other properties; but instead of accessing those
> properties directly, drivers should use the helpers provided by
> backlight.h.
>
>
Quoting Hsin-Yi Wang (2022-06-09 00:27:23)
> Panel orientation property should be set before drm_dev_register().
> Some drm driver calls drm_dev_register() in .bind(). However, most
> panels sets orientation property relatively late, mostly in .get_modes()
> callback, since this is when they are
Hi Stephen,
> > > >
> > > > Thanks, I’ll wait a little more to see if there are any other reviews of
> > > > the patches and then push a v2 with that fix.
> > > It would be very nice if you could kill all uses of FB_BLANK in the
> > > drivers/gpu/drm/panel/* drivers, and post them as one
Hi,
Am 09.06.22 um 23:33 schrieb Stefan Wahren:
Hi Peter,
Am 09.06.22 um 13:52 schrieb Peter Robinson:
As of Linux 5.18.0, module vc4 apparently isn't working on
Raspberry Pi
3B any more.
If a monitor is attached to the device, the boot messages show up as
usual, but right when KMS starts,
Hi,
On Thu, Jun 9, 2022 at 12:28 AM Hsin-Yi Wang wrote:
>
> Panel orientation property should be set before drm_dev_register().
> Some drm driver calls drm_dev_register() in .bind(). However, most
> panels sets orientation property relatively late, mostly in .get_modes()
> callback, since this
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device". Unfortunately
On Wed, Jun 08, 2022 at 10:50:38AM +0300, Jani Nikula wrote:
> Add a helper function to be used as the "default" .get_modes()
> hook. This also works as an example of what the driver .get_modes()
> hooks are supposed to do regarding the new drm_edid_read*() and
> drm_edid_connector_update() calls.
On Wed, Jun 08, 2022 at 10:50:35AM +0300, Jani Nikula wrote:
> Add new functions drm_edid_read(), drm_edid_read_ddc(), and
> drm_edid_read_custom() to replace drm_get_edid() and drm_do_get_edid()
> for reading the EDID. The transition is expected to happen over a fairly
> long time.
>
> Note that
On Wed, Jun 08, 2022 at 10:50:37AM +0300, Jani Nikula wrote:
> Abstract the .get_modes() connector helper call, including the
> override/firmware EDID fallback, for clarity.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_probe_helper.c | 29
On Wed, Jun 08, 2022 at 10:50:35AM +0300, Jani Nikula wrote:
> Add new functions drm_edid_read(), drm_edid_read_ddc(), and
> drm_edid_read_custom() to replace drm_get_edid() and drm_do_get_edid()
> for reading the EDID. The transition is expected to happen over a fairly
> long time.
>
> Note that
On Wed, Jun 08, 2022 at 10:50:34AM +0300, Jani Nikula wrote:
> We'll want to return the allocated buffer size in the future. Keep track
> of it.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 27 +++
> 1 file changed, 19
On Wed, Jun 08, 2022 at 10:50:44AM +0300, Jani Nikula wrote:
> Take the HF-EEODB extension count override into account.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c
On Wed, Jun 08, 2022 at 10:50:43AM +0300, Jani Nikula wrote:
> HDMI 2.1 section 10.3.6 defines an HDMI Forum EDID Extension Override
> Data Block, which may contain a different extension count than the base
> block claims. Add support for reading more EDID data if available. The
> extra blocks
On Wed, Jun 08, 2022 at 10:50:42AM +0300, Jani Nikula wrote:
> Rewrite edid_filter_invalid_blocks() to filter invalid blocks
> in-place. The main motivation is to not rely on passed in information on
> invalid block count or the allocation size, which will be helpful in
> follow-up work on
On Wed, Jun 08, 2022 at 10:50:41AM +0300, Jani Nikula wrote:
> Try to use struct drm_edid where possible, even if having to fall back
> to looking into struct edid down low via drm_edid_raw().
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
>
On Wed, Jun 08, 2022 at 10:50:39AM +0300, Jani Nikula wrote:
> Unfortunately, there are still plenty of interfaces around that require
> a struct edid pointer, and it's impossible to change them all at
> once. Add an accessor to the raw EDID data to help the transition.
>
> While there are no
Hi Stephen.
On Fri, Jun 10, 2022 at 07:47:20PM +0200, Stephen Kitt wrote:
> Hi Sebastian,
>
> On Thu, 9 Jun 2022 23:52:36 +0200, Sebastian Reichel
> wrote:
> > On Tue, Jun 07, 2022 at 08:20:25PM +0200, Stephen Kitt wrote:
> > > diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c
> > >
On Wed, Jun 08, 2022 at 10:50:40AM +0300, Jani Nikula wrote:
> Convert all the connectors that use cached connector edid and
> detect_edid to drm_edid.
>
> Signed-off-by: Jani Nikula
> ---
> .../gpu/drm/i915/display/intel_connector.c| 4 +-
> .../drm/i915/display/intel_display_types.h|
On Wed, Jun 08, 2022 at 10:50:36AM +0300, Jani Nikula wrote:
> Add a new function drm_edid_connector_update() to replace the
> combination of calls drm_connector_update_edid_property() and
> drm_add_edid_modes(). Usually they are called in the drivers in this
> order, however the former needs
Hi Sebastian,
On Thu, 9 Jun 2022 23:52:36 +0200, Sebastian Reichel
wrote:
> On Tue, Jun 07, 2022 at 08:20:25PM +0200, Stephen Kitt wrote:
> > diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c
> > b/drivers/gpu/drm/panel/panel-dsi-cm.c index b58cb064975f..aa36dc6cedd3
> > 100644 ---
Quoting Marijn Suijten (2022-06-10 00:46:32)
> On 2022-06-09 15:12:09, Stephen Boyd wrote:
> > Quoting Dmitry Baryshkov (2022-06-02 03:20:19)
> > > On Thu, 2 Jun 2022 at 01:07, Marijn Suijten
> > > wrote:
> > > > diff --git a/drivers/clk/clk-fixed-factor.c
> > > >
On Wed, Jun 08, 2022 at 10:50:32AM +0300, Jani Nikula wrote:
> Add a function to get the cea data block collection size.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 24 +---
> 1 file changed, 21
On Wed, Jun 08, 2022 at 10:50:31AM +0300, Jani Nikula wrote:
> The CTA Data Block Collection is valid only for CTA extension version
> 3. In versions 1 and 2, it is a reserved block, which we ignore.
>
> The DTD start offset (byte 2, or d in CTA-861 spec), which determines
> the CTA Data Block
It doesn't always work, as there is just a single adjusted mode, so if
parts of the display pipeline disagree on the required sync polarity
it's possible to end up with a invalid config. However it also isn't
necessary for this bridge chip, as the DPI interface has a configurable
sync polarity, so
On Fri, Jun 10, 2022 at 06:00:24PM +0200, Andrzej Hajda wrote:
> Handling HPD during driver removal is pointless, and can cause different
> use-after-free/concurrency issues:
> 1. Setup of deferred fbdev after fbdev unregistration.
> 2. Access to DP-AUX after DP-AUX removal.
>
> Below stacktraces
On Thu, 09 Jun 2022 17:27:29 +0100, Andre Przywara wrote:
> As Liviu pointed out, the arm,malidp-arqos-high-level property
> mentioned in the original .txt binding was a mistake, and
> arm,malidp-arqos-value needs to take its place.
>
> The binding commit ce6eb0253cba ("dt/bindings: display: Add
The pull request you sent on Fri, 10 Jun 2022 16:00:24 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-06-10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8dd77d44795d708f5f4f783b81c5197c5b994d74
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, 10 Jun 2022 10:49:55 +0100, Daniel Thompson
wrote:
> On Thu, Jun 09, 2022 at 07:45:11PM +0200, Stephen Kitt wrote:
> > Hi Sam, Daniel,
> >
> > On Thu, 9 Jun 2022 19:30:57 +0200, Sam Ravnborg wrote:
> >
> > > thanks for taking care of all these backlight simplifications - this
> > >
On Fri, Jun 10, 2022 at 11:18:14AM +0300, Lionel Landwerlin wrote:
On 10/06/2022 10:54, Niranjana Vishwanathapura wrote:
On Fri, Jun 10, 2022 at 09:53:24AM +0300, Lionel Landwerlin wrote:
On 09/06/2022 22:31, Niranjana Vishwanathapura wrote:
On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel
On Fri, Jun 10, 2022 at 09:20:18AM +0200, Christian König wrote:
Am 10.06.22 um 01:20 schrieb Lucas De Marchi:
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually.
From: Rob Clark
Keep the warn, but drop the early return. If we do manage to hit this
sort of issue, skipping the cleanup just makes things worse (dangling
drm_mm_nodes when the msm_gem_vma is freed, etc). Whereas the worst
that happens if we tear down a mapping the GPU is accessing is that we
On Fri, Jun 10, 2022 at 12:01:24PM +0100, Matthew Auld wrote:
On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:
Add some missing i915 upai documentation which the new
i915 VM_BIND feature documentation will be refer to.
Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Matthew Auld
On Fri, Jun 10, 2022 at 01:56:58AM -0700, Matthew Brost wrote:
On Fri, Jun 10, 2022 at 01:53:40AM -0700, Matthew Brost wrote:
On Fri, Jun 10, 2022 at 12:07:11AM -0700, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
>
> Signed-off-by: Niranjana Vishwanathapura
> ---
>
On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote:
On 10/06/2022 13:37, Tvrtko Ursulin wrote:
On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h |
https://bugzilla.kernel.org/show_bug.cgi?id=210301
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
Applied. Thanks!
Alex
On Fri, Jun 10, 2022 at 10:01 AM Michel Dänzer wrote:
>
> From: Michel Dänzer
>
> The commit below changed the TTM manager size unit from pages to
> bytes, but failed to adjust the corresponding calculations in
> amdgpu_ioctl.
>
> Fixes: dfa714b88eb0 ("drm/amdgpu: remove
Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.
Below stacktraces of both cases observed on CI:
[272.634530] general protection fault,
On Thu, Jun 9, 2022 at 5:10 PM Douglas Anderson wrote:
>
> From testing on sc7180-trogdor devices, reading the GMU registers
> needs the GMU clocks to be enabled. Those clocks get turned on in
> a6xx_gmu_resume(). Confusingly enough, that function is called as a
> result of the runtime_pm of the
Hello.
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
a macro") explains, we are removing flush_scheduled_work() calls. And now
drivers/gpu/drm/i915/display/intel_display.c
drivers/gpu/drm/i915/gt/selftest_execlists.c
are the last flush_scheduled_work() callers which
On 10/06/2022 13:37, Tvrtko Ursulin wrote:
On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 490 +++
1 file changed, 490 insertions(+)
On 5/27/22 02:50, Dmitry Osipenko wrote:
> Hello,
>
> This patchset introduces memory shrinker for the VirtIO-GPU DRM driver
> and adds memory purging and eviction support to VirtIO-GPU driver.
>
> The new dma-buf locking convention is introduced here as well.
>
> During OOM, the shrinker will
Use local wq in order to avoid flush_scheduled_work() usage.
Signed-off-by: Tetsuo Handa
---
Changes in v2:
Replace flush_scheduled_work() with flush_workqueue().
Please see commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue()
using a macro") for background.
This is a blind
On Fri, 10 Jun 2022 09:03:15 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 09.06.22 um 23:44 schrieb Alex Williamson:
> > On Thu, 9 Jun 2022 15:41:02 -0600
> > Alex Williamson wrote:
> >
> >> On Thu, 9 Jun 2022 11:13:22 +0200
> >> Thomas Zimmermann wrote:
> >>>
> >>> Please have a look at
Use local wq in order to avoid flush_scheduled_work() usage.
Signed-off-by: Tetsuo Handa
---
Please see commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue()
using a macro") for background.
This is a blind conversion, and is only compile tested.
On Fri, 2022-06-10 at 10:59 +0200, Daniel Vetter wrote:
> ⚠ External Email
>
> On Fri, Jun 10, 2022 at 10:41:05AM +0200, Daniel Vetter wrote:
> > Hi all,
> >
> > Kinda top post because the thread is sprawling and I think we need a
> > summary/restart. I think there's at least 3 issues here:
> >
Hi Lucas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on linus/master v5.19-rc1 next-20220610]
[cannot apply to tegra-drm/drm/tegra/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
From: Michel Dänzer
The commit below changed the TTM manager size unit from pages to
bytes, but failed to adjust the corresponding calculations in
amdgpu_ioctl.
Fixes: dfa714b88eb0 ("drm/amdgpu: remove GTT accounting v2")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1930
Bug:
On Fri, 10 Jun 2022 18:55:13 +0800, Bo-Chen Chen 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 controller
At some point the DRM printers started adding a newline after each
print. This caused SDVO command debug printing to look weird. Fix this
by using snprintf to print into a buffer which can be printed as a whole
by DRM_DEBUG_KMS(). Code is heavily inspired by i915.
Signed-off-by: Patrik Jakobsson
On Friday, June 10th, 2022 at 14:36, Gerd Hoffmann wrote:
> Hi,
>
> > > As Pekka mentionned, I'd also like to have a conversation of how far we
> > > want to
> > > push virtualized driver features. I think KMS support is a good feature
> > > to have
> > > to spin up a VM and have all of the
Hi Liu,
On Fri, Jun 10, 2022 at 10:09:19AM +0800, Liu Ying wrote:
> On Thu, 2022-06-09 at 12:30 +0300, Laurent Pinchart wrote:
> > On Thu, Jun 09, 2022 at 02:49:23PM +0800, Liu Ying wrote:
> > > This patch adds a drm bridge driver for i.MX8qm/qxp display pixel
> > > link.
> > > The pixel link
https://bugzilla.kernel.org/show_bug.cgi?id=210301
ramast (m...@ramast.me) changed:
What|Removed |Added
CC||m...@ramast.me
--- Comment #1
Hi,
> > As Pekka mentionned, I'd also like to have a conversation of how far we
> > want to
> > push virtualized driver features. I think KMS support is a good feature to
> > have
> > to spin up a VM and have all of the basics working. However I don't think
> > it's
> > a good idea to try to
Hi,
> > 4. make sure the hotspot property is only set on VIRTUAL_CURSOR planes
> > and nothing else in the rebased patch series
>
> Simon also mentioned on irc that these special planes must not expose the
> CRTC_X/Y property, since that doesn't really do much at all. Or is our
>
Hello Melissa,
On 6/10/22 13:05, Melissa Wen wrote:
> On 06/08, Javier Martinez Canillas wrote:
[snip]
>
> Hi Javier,
>
> Thanks for waiting a little.
>
> Stefan guided me to the missing part and I'm okay on this serie.
>
No worries and thanks for the testing.
> If there's any r-b missing
On Thu, Jun 09, 2022 at 05:27:29PM +0100, Andre Przywara wrote:
> As Liviu pointed out, the arm,malidp-arqos-high-level property
> mentioned in the original .txt binding was a mistake, and
> arm,malidp-arqos-value needs to take its place.
>
> The binding commit ce6eb0253cba ("dt/bindings:
We'll soon introduce another completion callback source that won't need
to use the BO reference counting, so let's move it around to create a
function we will be able to share between both callbacks.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 34
The BCM2711 has a separate driver for the v3d, and thus we can't call
into any of the driver entrypoints that rely on the v3d being there.
Let's add a bunch of checks and complain loudly if that ever happen.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
---
The function vc4_async_page_flip() handles asynchronous page-flips in
the vc4 driver.
However, it mixes some generic code with code that should only be run on
older generations that have the GPU handled by the vc4 driver.
Let's split the generic part out of vc4_async_page_flip() and into a
Prior to the BCM2711/RaspberryPi4, the GPU was a part of the display
components of the SoC. It was thus a part of the vc4 driver.
However, with the BCM2711, it got split out and thus the v3d driver was
created. The vc4 driver now only handles the display part.
We didn't properly split out the
When doing an asynchronous page flip (PAGE_FLIP ioctl with the
DRM_MODE_PAGE_FLIP_ASYNC flag set), the current code waits for the
possible GPU buffer being rendered through a call to
vc4_queue_seqno_cb().
On the BCM2835-37, the GPU driver is part of the vc4 driver and that
function is defined in
The BCM2711 doesn't have a v3d GPU so we don't want to call into its BO
management code. Let's create an asynchronous page-flip handler for the
BCM2711 that just calls into the common code.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 21
On the BCM2711, our current definition of drm_mode_config_funcs uses the
custom vc4_fb_create().
However, that function relies on the buffer allocation path that was
relying on the GPU, and is no longer relevant.
Let's create another drm_mode_config_funcs structure that we will
register on the
We'll need to extend the vc4_async_flip_state structure to rely on
another callback implementation, so let's move the current one into a
union.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 20 ++--
1 file changed, 14 insertions(+),
On the BCM2711, we currently call the vc4_bo_cache_init() and
vc4_gem_init() functions. These functions initialize the BO and GEM
backends.
However, this code was initially created to accomodate the requirements
of the GPU on the older SoCs, while the BCM2711 has a separate driver
for it. So
On the BCM2711, our current definition of drm_plane_helper_funcs uses
the custom vc4_prepare_fb() and vc4_cleanup_fb().
Those functions rely on the buffer allocation path that was relying on
the GPU, and is no longer relevant.
Let's create another drm_plane_helper_funcs structure that we will
We're going to add a new variant of the dumb BO allocation function, so
let's rename vc4_dumb_create() to something a bit more specific.
Reviewed-by: Melissa Wen
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_bo.c | 6 +++---
drivers/gpu/drm/vc4/vc4_drv.c | 2 +-
A new generation of controller has been introduced with the
BCM2711/RaspberryPi4. This generation needs a bunch of quirks, and over
time we've piled on a number of checks in most parts of the drivers.
All these checks are performed several times, and are not always
consistent. Let's create a
1 - 100 of 211 matches
Mail list logo
