On Mon, 20 Feb 2023 08:14:47 -0800
Rob Clark wrote:
> On Mon, Feb 20, 2023 at 12:53 AM Pekka Paalanen wrote:
> >
> > On Sat, 18 Feb 2023 13:15:49 -0800
> > Rob Clark wrote:
> >
> > > From: Rob Clark
> > >
> > > Allow userspace to use the EPOLLPRI/POLLPRI flag to indicate an urgent
> > > wait
On Mon, 20 Feb 2023 09:31:41 +0100
Christian König wrote:
> Am 18.02.23 um 22:15 schrieb Rob Clark:
> > From: Rob Clark
> >
> > Allow userspace to use the EPOLLPRI/POLLPRI flag to indicate an urgent
> > wait (as opposed to a "housekeeping" wait to know when to cleanup after
> > some work has com
On Mon, 20 Feb 2023 08:09:04 -0800
Rob Clark wrote:
> On Mon, Feb 20, 2023 at 12:27 AM Christian König
> wrote:
> >
> > Am 18.02.23 um 22:15 schrieb Rob Clark:
> > > From: Rob Clark
> > >
> > > The initial purpose is for igt tests, but this would also be useful for
> > > compositors that wait
On Mon, 20 Feb 2023 07:55:41 -0800
Rob Clark wrote:
> On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen wrote:
> >
> > On Sat, 18 Feb 2023 13:15:53 -0800
> > Rob Clark wrote:
> >
> > > From: Rob Clark
> > >
> > > Will be used in the next commit to set a deadline on fences that an
> > > atomic u
On Mon, 20 Feb 2023 12:18:56 -0800
Rob Clark wrote:
> From: Rob Clark
>
> Add a new flag to let userspace provide a deadline as a hint for syncobj
> and timeline waits. This gives a hint to the driver signaling the
> backing fences about how soon userspace needs it to compete work, so it
> can
On 20/02/2023 17:18, Andrea Righi wrote:
It seems that commit bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU
mask internally in UAPI format") exposed a potential out-of-bounds
access, reported by UBSAN as following on a laptop with a gen 11 i915
card:
UBSAN: array-index-out-of-bounds
Thomas Zimmermann writes:
> This mail never made it to dri-devel.
>
Oh, sorry about that. It seems that your response wasn't enough for
patchwork to pick the tag, so:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
This series introduces bindings for anx7625/it6505 to register Type-C
mode-switch in their output endpoints, and use data-lanes property to
describe the pin connections.
This series is not directly related to the built-in mux in anx7625,
which automatically switches between the two orientations
From: Prashant Malani
When searching the device graph for device matches, check the
remote-endpoint itself for a match.
Some drivers register devices for individual endpoints. This allows
the matcher code to evaluate those for a match too, instead
of only looking at the remote parent devices. Th
From: Prashant Malani
When using OF graph, the fw_devlink code will create links between the
individual port driver (cros-ec-typec here) and the parent device for
a Type-C switch (like mode-switch). Since the mode-switch will in turn
have the usb-c-connector (i.e the child of the port driver) as
Add helpers to register and unregister Type-C "switches" for bridges
capable of switching their output between two downstream devices.
The helper registers USB Type-C mode switches when the "mode-switch"
and the "reg" properties are available in Device Tree.
Signed-off-by: Pin-yen Lin
---
Chan
Analogix 7625 can be used in systems to switch the DP traffic between
two downstreams, which can be USB Type-C DisplayPort alternate mode
lane or regular DisplayPort output ports.
Update the binding to accommodate this usage by introducing a
data-lanes and a mode-switch property on endpoints.
Als
The output port endpoints can be connected to USB-C connectors.
Running drm_of_find_panel_or_bridge() with such endpoints leads to
a continuous return value of -EPROBE_DEFER, even though there is
no panel present.
To avoid this, check for the existence of a "mode-switch" property in
the port endpo
These two drivers embed a i2c_client in there private driver data, but
only strict device is actually needed. Replace the i2c_client reference
with a struct device one.
Signed-off-by: Pin-yen Lin
---
Changes in v12:
- New in v12
drivers/gpu/drm/bridge/analogix/anx7625.c | 96
Register USB Type-C mode switches when the "mode-switch" property and
relevant ports are available in Device Tree. Configure the crosspoint
switch based on the entered alternate mode for a specific Type-C
connector.
Crosspoint switch can also be used for switching the output signal for
different o
ITE IT6505 can be used in systems to switch the DP traffic between
two downstreams, which can be USB Type-C DisplayPort alternate mode
lane or regular DisplayPort output ports.
Update the binding to accommodate this usage by introducing a
data-lanes and a mode-switch property on endpoints.
Signed
Replace the spaces with tab characters in the Kconfig file.
Signed-off-by: Pin-yen Lin
Reviewed-by: AngeloGioacchino Del Regno
---
(no changes since v10)
Changes in v10:
- Collected Reviewed-by tag
Changes in v7:
- New in v7
drivers/gpu/drm/bridge/Kconfig | 20 ++--
1 file
Register USB Type-C mode switches when the "mode-switch" property and
relevant port are available in Device Tree. Configure the "lane_swap"
state based on the entered alternate mode for a specific Type-C
connector, which ends up updating the lane swap registers of the it6505
chip.
Signed-off-by: P
A recent commit moved enabling of runtime PM from adreno_gpu_init() to
adreno_load_gpu() (called on first open()), which means that unbind()
may now be called with runtime PM disabled in case the device was never
opened in between.
Make sure to only forcibly suspend and disable runtime PM at unbin
As reported by Bjorn, we can end up with an unbalanced runtime PM
disable count if unbind() is called before the drm device is opened
(e.g. if component bind fails due to the panel driver not having been
loaded yet).
As runtime PM must currently stay disabled until the firmware has been
loaded, fi
Since commit 4b18299b3365 ("drm/msm/adreno: Defer enabling runpm until
hw_init()") runtime PM is no longer enabled at adreno_gpu_init(), which
means that there are no longer any bind() error paths for which
adreno_gpu_cleanup() is called with runtime PM enabled.
As the runtime PM enable on first o
Clean up the component ops initialisers which were indented one level
too far.
Signed-off-by: Johan Hovold
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adre
The runtime PM status can only be updated while runtime PM is disabled.
Drop the bogus pm_runtime_set_active() call that was made after enabling
runtime PM and which (incidentally but correctly) left the runtime PM
status set to 'suspended'.
Fixes: 2c087a336676 ("drm/msm/adreno: Load the firmware
Thomas Zimmermann writes:
> Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
> calling fbdev implementation. Avoids a possible stale mutex with
> generic fbdev code.
>
> As indicated by its name, drm_fb_helper_prepare() prepares struct
> drm_fb_helper before setting up the fbdev
https://bugzilla.kernel.org/show_bug.cgi?id=217065
Bug ID: 217065
Summary: Linux 6.2.0 - AMDGPU cannot start, ends in a blank
screen.
Product: Drivers
Version: 2.5
Kernel Version: 6.2.0
Hardware: All
OS:
On Tue, Feb 21, 2023 at 05:50:45PM +0800, Pin-yen Lin wrote:
> From: Prashant Malani
>
> When searching the device graph for device matches, check the
> remote-endpoint itself for a match.
>
> Some drivers register devices for individual endpoints. This allows
> the matcher code to evaluate thos
On Tue, Feb 21, 2023 at 05:50:51PM +0800, Pin-yen Lin wrote:
> Register USB Type-C mode switches when the "mode-switch" property and
> relevant ports are available in Device Tree. Configure the crosspoint
> switch based on the entered alternate mode for a specific Type-C
> connector.
>
> Crosspoin
On Tue, Feb 21, 2023 at 05:50:50PM +0800, Pin-yen Lin wrote:
> These two drivers embed a i2c_client in there private driver data, but
> only strict device is actually needed. Replace the i2c_client reference
> with a struct device one.
LGTM,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Pin-yen
On Mon, Feb 20, 2023 at 4:24 PM Dave Stevenson
wrote:
>
> Hi Hans
>
> On Sat, 18 Feb 2023 at 11:33, Hans Verkuil wrote:
> >
> > Hi Maxime, Dave,
> >
> > On 26/01/2023 14:46, Maxime Ripard wrote:
> > > From: Dave Stevenson
> > >
> > > Copy Intel's "Broadcast RGB" property semantics to add manual
Hi Hans,
On Sat, Feb 18, 2023 at 11:45:04AM +0100, Hans Verkuil wrote:
> > diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> > index 86d629e45307..d0a00ed42cb0 100644
> > --- a/drivers/gpu/drm/vc4/vc4_bo.c
> > +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> > @@ -609,7 +609,7 @@ stat
On 2/20/23 16:23, Dave Stevenson wrote:
> Hi Hans
>
> On Sat, 18 Feb 2023 at 11:33, Hans Verkuil wrote:
>>
>> Hi Maxime, Dave,
>>
>> On 26/01/2023 14:46, Maxime Ripard wrote:
>>> From: Dave Stevenson
>>>
>>> Copy Intel's "Broadcast RGB" property semantics to add manual override
>>> of the HDMI p
On Tue, Feb 21, 2023 at 05:50:47PM +0800, Pin-yen Lin wrote:
> Add helpers to register and unregister Type-C "switches" for bridges
> capable of switching their output between two downstream devices.
>
> The helper registers USB Type-C mode switches when the "mode-switch"
> and the "reg" propertie
On Tue, Feb 21, 2023 at 05:50:49PM +0800, Pin-yen Lin wrote:
> The output port endpoints can be connected to USB-C connectors.
> Running drm_of_find_panel_or_bridge() with such endpoints leads to
> a continuous return value of -EPROBE_DEFER, even though there is
> no panel present.
>
> To avoid th
On Tue, Feb 21, 2023 at 05:50:54PM +0800, Pin-yen Lin wrote:
> Register USB Type-C mode switches when the "mode-switch" property and
> relevant port are available in Device Tree. Configure the "lane_swap"
> state based on the entered alternate mode for a specific Type-C
> connector, which ends up u
Hi
Am 21.02.23 um 11:27 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
calling fbdev implementation. Avoids a possible stale mutex with
generic fbdev code.
As indicated by its name, drm_fb_helper_prepare() prepare
Thomas Zimmermann writes:
> Hi
>
> Am 21.02.23 um 11:27 schrieb Javier Martinez Canillas:
>> Thomas Zimmermann writes:
>>
>>> Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
>>> calling fbdev implementation. Avoids a possible stale mutex with
>>> generic fbdev code.
>>>
>>> As
Hi Dave and Daniel,
here's the final PR for drm-misc-next-fixes for this release cycle.
Best regards
Thomas
drm-misc-next-fixes-2023-02-21:
Short summary of fixes pull:
Fixes GEM SHMEM locking and generic fbdev hotplugging. Constifies
dma_buf kobj type.
The following changes since commit 38b2d8
this is a test email, Sorry to be a bother
On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote:
> On Mon, 20 Feb 2023 07:55:41 -0800
> Rob Clark wrote:
>
> > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen wrote:
> > >
> > > On Sat, 18 Feb 2023 13:15:53 -0800
> > > Rob Clark wrote:
> > >
> > > > From: Rob Clark
> > > >
> >
On Tue, 21 Feb 2023 15:01:35 +0200
Ville Syrjälä wrote:
> On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote:
> > On Mon, 20 Feb 2023 07:55:41 -0800
> > Rob Clark wrote:
> >
> > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen
> > > wrote:
> > > >
> > > > On Sat, 18 Feb 2023 1
On Tue, Feb 21, 2023 at 03:11:33PM +0200, Pekka Paalanen wrote:
> On Tue, 21 Feb 2023 15:01:35 +0200
> Ville Syrjälä wrote:
>
> > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote:
> > > On Mon, 20 Feb 2023 07:55:41 -0800
> > > Rob Clark wrote:
> > >
> > > > On Mon, Feb 20, 2023
https://bugzilla.kernel.org/show_bug.cgi?id=217065
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
On 2/21/23 12:38, Maxime Ripard wrote:
> Hi Hans,
>
> On Sat, Feb 18, 2023 at 11:45:04AM +0100, Hans Verkuil wrote:
>>> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
>>> index 86d629e45307..d0a00ed42cb0 100644
>>> --- a/drivers/gpu/drm/vc4/vc4_bo.c
>>> +++ b/drivers/gpu/
On Mon, Feb 20, 2023 at 08:33:35PM +, Matthew Wilcox wrote:
> On Mon, Feb 20, 2023 at 06:06:03PM +0100, Danilo Krummrich wrote:
> > On 2/20/23 16:10, Matthew Wilcox wrote:
> > > This is why we like people to use the spinlock embedded in the tree.
> > > There's nothing for the user to care about
On 2/17/23 17:00, Christian König wrote:
Am 17.02.23 um 14:44 schrieb Danilo Krummrich:
From: Christian König
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existinc TTMs execbuf util and intended to
replace
it in the long term.
The basic funct
Changes in v2:
- Add power-domain-names commit from Chen-Yu to the series
- Kept sram-supply in base schema, overridden for non-MediaTek
- Added Reviewed-by tags from Steven Price to the driver commits
(as released in reply to v1's cover letter - thanks!)
This series adds support for new Med
In preparation for adding new bindings for new MediaTek SoCs, split out
the power-domain-names and power-domainsvariation from the `else` in
the current mediatek,mt8183-mali conditional.
The sram-supply part is left in place to be disallowed for anything
that is not compatible with "mediatek,mt818
MediaTek MT8192 (and similar) needs five power domains for the
Mali GPU and no sram-supply: change the binding to allow so.
Fixes: 5d82e74a97c2 ("dt-bindings: Add compatible for Mali Valhall (JM)")
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Rob Herring
---
.../bindings/gpu/arm,mali
From: Chen-Yu Tsai
In commit a7a596cd3115 ("dt-bindings: gpu: mali-bifrost: Add Mediatek
MT8183"), "power-domain-names" was added to the mt8183-mali sub-schema,
but was not added to the base mali-bifrost schema. Because validation
happens for the base schema and any sub-schemas separately, this c
The MediaTek MT8195 SoC has a Mali G57 MC5 (Valhall-JM) and has the
same number of power domains and requirements as MT8192 in terms of
bindings.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 5 +
1 file
The "mediatek,mt8183-mali" compatible uses platform data that calls for
getting (and managing) two regulators ("mali" and "sram") but devfreq
does not support this usecase, resulting in DVFS not working.
Since a lot of MediaTek SoCs need to set the voltages for the GPU SRAM
regulator in a specific
From: Alyssa Rosenzweig
MediaTek MT8192 has a Mali-G57 with a special GPU ID. Add its GPU ID,
but treat it as otherwise identical to a standard Mali-G57.
We do _not_ fix up the GPU ID here -- userspace needs to be aware of the
special GPU ID, in case we find functional differences between
MediaT
Get GPU support on MT8186 by adding its compatible.
Signed-off-by: AngeloGioacchino Del Regno
---
Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
b/Documentation/dev
From: Alyssa Rosenzweig
Increase the MAX_PM_DOMAINS constant from 3 to 5, to support the
extra power domains required by the Mali-G57 on the MT8192.
Signed-off-by: Alyssa Rosenzweig
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_dev
From: Alyssa Rosenzweig
Required for Mali-G57 on the Mediatek MT8192 and MT8195, which
uses even more power domains than the MT8183 before it.
Signed-off-by: Alyssa Rosenzweig
[Angelo: Removed unneeded "sram" supply, added mt8195 to commit description]
Co-developed-by: AngeloGioacchino Del Regn
Since new platform data was required in Panfrost for getting GPU DVFS
finally working on MediaTek SoCs, add a new "mediatek,mt8183b-mali"
compatible.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Rob Herring
---
.../bindings/gpu/arm,mali-bifrost.yaml| 19 +++
1
On Sat, Feb 18, 2023 at 07:17:08PM +0800, Pin-yen Lin wrote:
> Introduce a optional "ddc-i2c-bus" property for anx7688 bridge. This
> allows the bridge to register a .get_edid callback.
What's .get_edid? This is a binding and is independent of Linux.
>
> Signed-off-by: Pin-yen Lin
> ---
>
> Ch
Ast defines a number of I/O helpers for accessing hardware. Only 4 of
the many generated functions are actually used. Replace the respective
generator macros with those 4 functions. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 48 ++-
The helper to_ast_private() now upcasts to struct ast_device. Rename
it accordingly. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_dp.c| 10 +-
drivers/gpu/drm/ast/ast_dp501.c | 20 ++--
drivers/gpu/drm/ast/ast_drv.h | 2 +-
dr
Replace one call to ast_io_write16() with two calls to ast_io_write8()
in ast_set_index_reg(). The combined 16-bit-wide write of an index
register and the corresponding data register only works on little-
endian systems. Write both registers independent from each other.
Signed-off-by: Thomas Zimme
Rename struct ast_private to struct ast_device. The old name comes
from the time when struct drm_device.dev_private was still in use.
Also update the upcast helper.
The renaming touches ast's I/O-helper macros, which generate warnings
with checkpatch. So fix the I/O helpers in the first two patche
The data structure struct ast_private represents an AST device. Its
name comes from the time when it was allocated and stored separately
in struct drm_device.dev_private. The DRM device is now embedded, so
rename struct ast_private to struct ast_device.
Signed-off-by: Thomas Zimmermann
---
drive
On Tue, Feb 21, 2023 at 9:38 AM Pekka Paalanen wrote:
>
> On Mon, 20 Feb 2023 08:14:47 -0800
> Rob Clark wrote:
>
> > On Mon, Feb 20, 2023 at 12:53 AM Pekka Paalanen wrote:
> > >
> > > On Sat, 18 Feb 2023 13:15:49 -0800
> > > Rob Clark wrote:
> > >
> > > > From: Rob Clark
> > > >
> > > > Allow
On 10/02/2023 11:03, Christian König wrote:
Am 08.02.23 um 15:53 schrieb Matthew Auld:
The ttm BO now initially has NULL bo->resource, and leaves the driver
the handle that. However it looks like we forgot to handle that for
ttm_bo_move_memcpy() users, like with vram-gem, since it just silently
Am 21.02.23 um 17:13 schrieb Matthew Auld:
On 10/02/2023 11:03, Christian König wrote:
Am 08.02.23 um 15:53 schrieb Matthew Auld:
The ttm BO now initially has NULL bo->resource, and leaves the driver
the handle that. However it looks like we forgot to handle that for
ttm_bo_move_memcpy() users,
On 21/02/2023 16:17, Christian König wrote:
Am 21.02.23 um 17:13 schrieb Matthew Auld:
On 10/02/2023 11:03, Christian König wrote:
Am 08.02.23 um 15:53 schrieb Matthew Auld:
The ttm BO now initially has NULL bo->resource, and leaves the driver
the handle that. However it looks like we forgot t
On 2023-02-21 06:35, qu.hu...@linux.dev wrote:
From: Qu Huang
In the kfd_wait_on_events() function, the kfd_event_waiter structure is
allocated by alloc_event_waiters(), but the event field of the waiter
structure is not initialized; When copy_from_user() fails in the
kfd_wait_on_events() fun
Am 21.02.23 um 17:26 schrieb Matthew Auld:
On 21/02/2023 16:17, Christian König wrote:
Am 21.02.23 um 17:13 schrieb Matthew Auld:
On 10/02/2023 11:03, Christian König wrote:
Am 08.02.23 um 15:53 schrieb Matthew Auld:
The ttm BO now initially has NULL bo->resource, and leaves the driver
the ha
On 2/16/23 23:44, Jani Nikula wrote:
> Add a helper to get a pointer to struct displayid_header. To be
> pedantic, add buffer overflow checks to not touch the base if that
> itself would overflow.
>
> Cc: Iaroslav Boliukin
> Cc: Dmitry Osipenko
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/
On 2/16/23 23:44, Jani Nikula wrote:
> Avoid figuring out the header pointer multiple times.
>
> Cc: Iaroslav Boliukin
> Cc: Dmitry Osipenko
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_displayid.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff
On 2/16/23 23:45, Jani Nikula wrote:
> The DisplayID structure version and primary use case are stored in the
> DisplayID Base Section. We should be checking them in a number of places
> when parsing the DisplayID blocks. Currently, we completely ignore the
> primary use case, and just look at the
On 2/16/23 23:45, Jani Nikula wrote:
> Use the DisplayID 2.0 primary use case information to deduce whether
> this is a head-mounted display, and should not be used for desktop.
>
> Cc: Iaroslav Boliukin
> Cc: Dmitry Osipenko
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 25
On 2/17/23 13:46, Jani Nikula wrote:
> Currently we only parse the Tiled Display Topology Data Block for
> DisplayID structure version 1.2, but not 2.0. The contents seem to be
> the same for both, so expand the parsing to structure version 2.0.
>
> Note that DisplayID spec version is not the same
On 2/20/23 18:44, Dmitry Osipenko wrote:
> On 2/16/23 23:44, Jani Nikula wrote:
>> Mostly this is prep work and plumbing for easier use of displayid
>> structure version and primary use case for parsing the displayid blocks,
>> but it can be nicely used for figuring out non-desktop too.
>>
>> Compl
On 2023-02-20 11:14, Rob Clark wrote:
> On Mon, Feb 20, 2023 at 12:53 AM Pekka Paalanen wrote:
>>
>> On Sat, 18 Feb 2023 13:15:49 -0800
>> Rob Clark wrote:
>>
>>> From: Rob Clark
>>>
>>> Allow userspace to use the EPOLLPRI/POLLPRI flag to indicate an urgent
>>> wait (as opposed to a "housekeepin
* Danilo Krummrich [230220 09:38]:
> On 2/17/23 19:34, Liam R. Howlett wrote:
> > * Danilo Krummrich [230217 08:44]:
> > > Split up the MA_STATE() macro such that components using the maple tree
> > > can easily inherit from struct ma_state and build custom tree walk
> > > macros to hide their in
Convert the Parade PS8622/PS8625 DisplayPort to LVDS Converter bindings
to DT schema. Changes during conversion: add missing vdd12-supply, used
by Linux driver.
Signed-off-by: Krzysztof Kozlowski
---
.../display/bridge/parade,ps8622.yaml | 115 ++
.../bindings/display/br
On Tue, Feb 21, 2023 at 12:53 AM Pekka Paalanen wrote:
>
> On Mon, 20 Feb 2023 12:18:56 -0800
> Rob Clark wrote:
>
> > From: Rob Clark
> >
> > Add a new flag to let userspace provide a deadline as a hint for syncobj
> > and timeline waits. This gives a hint to the driver signaling the
> > backi
On Fri, 17 Feb 2023 at 12:23, Christian König
wrote:
>
> From: Somalapuram Amaranath
>
> ttm_resource can allocate size in bytes to support less than page size.
>
> Signed-off-by: Somalapuram Amaranath
> Reviewed-by: Christian König
> Signed-off-by: Christian König
> Link:
> https://patchwork
On Fri, 17 Feb 2023 at 12:23, Christian König
wrote:
>
> We don't need multiple drm_mm nodes any more. Clean that up and remove
> the extra complexity.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Auld
On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä
wrote:
>
> On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote:
> > On Mon, 20 Feb 2023 07:55:41 -0800
> > Rob Clark wrote:
> >
> > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen
> > > wrote:
> > > >
> > > > On Sat, 18 Feb 2023 13:15:53
On Tue, Feb 21, 2023 at 8:48 AM Luben Tuikov wrote:
>
> On 2023-02-20 11:14, Rob Clark wrote:
> > On Mon, Feb 20, 2023 at 12:53 AM Pekka Paalanen wrote:
> >>
> >> On Sat, 18 Feb 2023 13:15:49 -0800
> >> Rob Clark wrote:
> >>
> >>> From: Rob Clark
> >>>
> >>> Allow userspace to use the EPOLLPRI/
On Tue, Feb 21, 2023 at 8:01 AM Sebastian Wick
wrote:
>
> On Tue, Feb 21, 2023 at 9:38 AM Pekka Paalanen wrote:
> >
> > On Mon, 20 Feb 2023 08:14:47 -0800
> > Rob Clark wrote:
> >
> > > On Mon, Feb 20, 2023 at 12:53 AM Pekka Paalanen
> > > wrote:
> > > >
> > > > On Sat, 18 Feb 2023 13:15:49 -0
* Danilo Krummrich [230217 08:45]:
> Add infrastructure to keep track of GPU virtual address (VA) mappings
> with a decicated VA space manager implementation.
>
> New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
> start implementing, allow userspace applications to request m
On Tue, Feb 21, 2023 at 09:01:24AM +, Tvrtko Ursulin wrote:
>
>
> On 20/02/2023 17:18, Andrea Righi wrote:
> > It seems that commit bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU
> > mask internally in UAPI format") exposed a potential out-of-bounds
> > access, reported by UBSAN as follo
On Tue, Feb 21, 2023 at 03:37:49PM +0100, Danilo Krummrich wrote:
> On Mon, Feb 20, 2023 at 08:33:35PM +, Matthew Wilcox wrote:
> > On Mon, Feb 20, 2023 at 06:06:03PM +0100, Danilo Krummrich wrote:
> > > On 2/20/23 16:10, Matthew Wilcox wrote:
> > > > This is why we like people to use the spinl
Move TE setup to prepare_for_kickoff() and remove empty prepare_commit()
functions in both MDP4 and DPU drivers.
Changes in V2:
- Added changes to remove empty prepare_commit() functions
Changes in V3:
- Reordered "drm/msm/dpu: Move TE setup to prepare_for_kickoff()" for
clarity
- Fixed spelli
Currently, DPU will enable TE during prepare_commit(). However, this
will cause a crash and reboot to sahara when trying to read/write to
register in get_autorefresh_config(), because the core clock rates
aren't set at that time.
This used to work because phys_enc->hw_pp is only initialized in mod
Add a NULL check before calling prepare_commit() in
msm_atomic_commit_tail()
Signed-off-by: Jessica Zhang
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_atomic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/m
Now that the TE setup has been moved to prepare_for_kickoff(), we have
not prepare_commit() callbacks left. This makes dpu_encoder_prepare_commit()
do nothing. Remove prepare_commit() from DPU driver.
Changes in V3:
- Reworded commit message to be more clear
- Corrected spelling mistake in commit
Remove empty prepare_commit() function from MDP4 driver.
Signed-off-by: Jessica Zhang
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4
Le 21/02/2023 à 17:26, Felix Kuehling a écrit :
On 2023-02-21 06:35, qu.huang-fxuvxftifdnyg1zeobx...@public.gmane.org
wrote:
From: Qu Huang
In the kfd_wait_on_events() function, the kfd_event_waiter structure is
allocated by alloc_event_waiters(), but the event field of the waiter
structure
On 2023-02-18 16:15, Rob Clark wrote:
> As the finished fence is the one that is exposed to userspace, and
> therefore the one that other operations, like atomic update, would
> block on, we need to propagate the deadline from from the finished
> fence to the actual hw fence.
>
> v2: Split into dr
On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä
wrote:
>
> On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote:
> > On Mon, 20 Feb 2023 07:55:41 -0800
> > Rob Clark wrote:
> >
> > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen
> > > wrote:
> > > >
> > > > On Sat, 18 Feb 2023 13:15:53
The VS signal change is synchronized to HS signal change, start the
info graphics with that event, instead of having that event occur in
the middle of it.
Scope trace of DPI bus with HS/VS active HIGH looks as follows:
...__
VS...___/__ __\__...
HS...__
On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote:
> On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote:
> > > On Mon, 20 Feb 2023 07:55:41 -0800
> > > Rob Clark wrote:
> > >
> > > > On Mon, Feb 20, 2023 at 1:08 AM
On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote:
> > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote:
> > > > On Mon, 20 Feb 2023 07:55:41
On Tue, Feb 21, 2023 at 1:48 PM Ville Syrjälä
wrote:
>
> On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote:
> > > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Tue, Feb 21, 2023 at 10:45:51A
On Tue, Feb 21, 2023 at 02:28:10PM -0800, Rob Clark wrote:
> On Tue, Feb 21, 2023 at 1:48 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote:
> > > > On Tue, Feb 21, 2023 at 5:01 AM Ville
On Tue, Feb 21, 2023 at 2:46 PM Ville Syrjälä
wrote:
>
> On Tue, Feb 21, 2023 at 02:28:10PM -0800, Rob Clark wrote:
> > On Tue, Feb 21, 2023 at 1:48 PM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Feb 21, 2023 at 11:54:55AM -0
1 - 100 of 123 matches
Mail list logo
