* Make sure that struct members are referred to using @, otherwise they
won't be formatted as such
* Make sure to refer to other struct types using & so they link back to
each struct's definition
* Make sure to precede constant values with % so they're formatted
correctly
Signed-off-by: Lyud
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/br
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 26 ++---
1 file changed, 18 insertions(+), 8 deletions(-)
As pointed out by the documentation for drm_dp_aux_register(),
drm_dp_aux_init() should be used in situations where the AUX channel for a
display driver can potentially be registered before it's respective DRM
driver. This is the case with Tegra, since the DP aux channel exists as a
platform device
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for d
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display b
Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want
to make sure that we can also add ratelimited versions of these macros in
order to retain some of the previous debugging output behavior we had.
However, as I was preparing to do this I noticed that the current
rate limited
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_help
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c
Another function we need to pass drm_device down to in order to start using
drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4 inserti
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
th
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm/drm_dp_dual_mode_helpe
So that we can start using drm_dbg_*() throughout the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +---
drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
include/drm/drm_dp_dual_mode_helper.h | 4 ++--
3 files changed, 14
Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff -
Now that we've added a back-pointer to drm_device to drm_dp_aux, made
drm_dp_aux available to any functions in drm_dp_helper.c which need to
print to the kernel log, and ensured all of our logging uses a consistent
format, let's do the final step of the conversion and actually move
everything over
Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c |
Checkpatch was complaining about this - there's no need for us to print
errors when kzalloc() fails, as kzalloc() will already WARN for us. So,
let's fix that before converting things to make checkpatch happy.
Signed-off-by: Lyude Paul
Cc: Robert Foss
---
drivers/gpu/drm/drm_dp_mst_topology.c |
And finally, convert all of the code in drm_dp_mst_topology.c over to using
drm_err() and drm_dbg*(). Note that this refactor would have been a lot
more complicated to have tried writing a coccinelle script for, so this
whole thing was done by hand.
v2:
* Fix line-wrapping in drm_dp_mst_atomic_che
Next step in the conversion, move everything in drm_dp_dual_mode_helper.c
over to using drm_err() and drm_dbg_kms(). This was done using the
following cocci script:
@@
expression list expr;
@@
(
- DRM_DEBUG_KMS(expr);
+ drm_dbg_kms(dev, expr);
|
- DRM_ERROR(expr);
+ drm_err(dev,
Hi Dmitry
On 2021-03-26 13:36, Dmitry Baryshkov wrote:
On 26/03/2021 21:05, abhin...@codeaurora.org wrote:
Hi Dmitry
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
There is no reason to set clock parents manually, use device tree to
assign DSI/display clock parents to DSI PHY clocks. Dropping t
On Tue, Feb 23, 2021 at 2:26 PM Rob Herring wrote:
>
> On Thu, 18 Feb 2021 16:28:37 +0100, Maxime Ripard wrote:
> > For some reason, unevaluatedProperties doesn't work and
> > additionalProperties is required. Fix it by switching to
> > additionalProperties.
> >
> > Signed-off-by: Maxime Ripard
>
pushed! thanks for the patch
On Thu, 2021-03-25 at 14:06 -0400, Eryk Brol wrote:
> [why]
> MST topology print was missing fec logging and pdt printed
> as an int wasn't clear. vcpi and payload info was printed as an
> arbitrary series of ints which requires user to know the ordering
> of the print
On Mon, Mar 22, 2021 at 07:50:31PM +0100, Daniel Mack wrote:
> This adds documentation for a new ILI9163 based, SPI connected display.
>
> Signed-off-by: Daniel Mack
> ---
> .../bindings/display/ilitek,ili9163.yaml | 70 +++
As this is panel chip, put it in panel/.
> 1 fil
Reviewed-by: Lyude Paul
On Wed, 2020-12-02 at 19:02 -0500, Jeremy Cline wrote:
> nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code
> back to the caller. On failures, ttm_bo_init() invokes the provided
> destructor which should de-initialize and free the memory.
>
> Thus, w
This patch series is:
Reviewed-by: Lyude Paul
Btw - in the future if you need to send a respin of multiple patches, you need
to send it as it's own separate series instead of replying to the previous one
(one-off respins can just be posted as replies though), otherwise patchwork
won't pick it up
On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
>
> On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> >
> > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
> > >
> > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding
> > > wrote:
> > > >
> > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Ro
26.03.2021 22:10, Mikko Perttunen пишет:
> On 3/26/21 8:31 PM, Dmitry Osipenko wrote:
>> 26.03.2021 17:54, Mikko Perttunen пишет:
>>>
>>> Lockdep doesn't seem to be liking dev_name() for the name, and I think
>>> allocating a string for this purpose seems a bit overkill, so I'll keep
>>> the lock n
Hi Rob,
On Fri, 26 Mar 2021 15:01:34 -0600 Rob Herring wrote:
>
> On Tue, Feb 23, 2021 at 2:26 PM Rob Herring wrote:
> >
> > On Thu, 18 Feb 2021 16:28:37 +0100, Maxime Ripard wrote:
> > > For some reason, unevaluatedProperties doesn't work and
> > > additionalProperties is required. Fix it by
This enables the adreno-specific SMMU path that sets HUPCF so
(user-managed) page faults don't wedge the GPU.
Signed-off-by: Eric Anholt
---
We've been seeing a flaky test per day or so in Mesa CI where the
kernel gets wedged after an iommu fault turns into CP errors. With
this patch, the CI is
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
Signed-off-by: Eric Anholt
---
We've b
On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote:
>
> On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
> >
> > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> > >
> > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
> > > >
> > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding
> > > >
From: Jeremy Cline
Make use of the devm_drm_dev_alloc() API to bind the lifetime of
nouveau_drm structure to the drm_device. This is important because a
reference to nouveau_drm is accessible from drm_device, which is
provided to a number of DRM layer callbacks that can run after the
deallocation
From: Jeremy Cline
In order to use the resource-managed allocation of a struct drm_device
instance, it is recommended to embed the drm_device instance within the
driver-specific structure.
As there is already a helper to convert a drm_device to a nouveau_drm
struct, this adds an inverse function
From: Jeremy Cline
Start on documentation for the Nouveau device structure and the NVIF
client structure it uses. This documentation is not complete as the
structures are non-trivial and I am not familiar with large portions of
them.
Signed-off-by: Jeremy Cline
Signed-off-by: Lyude Paul
---
d
On Fri, Mar 26, 2021 at 4:48 PM Rob Herring wrote:
>
> On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote:
> >
> > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
> > >
> > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> > > >
> > > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
> >
On Fri, Mar 26, 2021 at 5:33 PM Rob Clark wrote:
>
> On Fri, Mar 26, 2021 at 4:48 PM Rob Herring wrote:
> >
> > On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote:
> > >
> > > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
> > > >
> > > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> >
On 26/03/2021 23:48, abhin...@codeaurora.org wrote:
Hi Dmitry
On 2021-03-26 13:36, Dmitry Baryshkov wrote:
On 26/03/2021 21:05, abhin...@codeaurora.org wrote:
Hi Dmitry
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
There is no reason to set clock parents manually, use device tree to
assign DS
101 - 138 of 138 matches
Mail list logo
