On Tue, Feb 21, 2023 at 11:37 PM AngeloGioacchino Del Regno
wrote:
>
> In preparation for adding new bindings for new MediaTek SoCs, split out
> the power-domain-names and power-domainsvariation from the `else` in
^ missing space
Otherwise,
On Tue, Feb 21, 2023 at 04:37:30PM +0100, AngeloGioacchino Del Regno wrote:
> 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
On 22/02/2023 07:06, Laurent Pinchart wrote:
When the input to a DU channel comes from a VSP, the DU doesn't perform
any blending operation. Select XRGB instead of ARGB to ensure
that the corresponding registers don't get written with invalid values.
Signed-off-by: Laurent Pinchart
---
On Tue, Feb 21, 2023 at 11:37 PM AngeloGioacchino Del Regno
wrote:
>
> 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
From: Swati Sharma
DSC_Output_Format_Sink_Support entry is added to i915_dsc_fec_support_show
to depict if sink supports DSC output formats (RGB/YCbCr420/YCbCr444).
Also, new debugfs entry is created to enforce output format. This is
required because of our driver policy. For ex. if a mode is
Now that we have laid the groundwork for YUV420 Enablement
we fill up native_420 field in vdsc_cfg and add appropriate
checks wherever required.
---v2
-adding native_422 field as 0 [Vandita]
-filling in second_line_bpg_offset, second_line_offset_adj
and nsl_bpg_offset in vds_cfg when native_420
Add function to check if slice design requirements are being
met as defined in Bspec: 49259 in the section
Slice Design Requirement
--v7
-remove full bspec link [Jani]
-rename intel_dsc_check_slice_design_req to
intel_dsc_slice_dimensions_valid [Jani]
--v8
-fix condition to check if slice width
Implementation of VDSC for YCbCr420.
Add QP tables for 8,10,12 BPC from rc_tables.h in intel_qp_tables.c
(Derived from C-Model, which is given along with DSC1.2a Spec from Vesa)
intel_lookup_range_min/max_qp functons need to take into account the
output format. Based on that appropriate qp table
Adding new DSC register which are introducted MTL onwards
Signed-off-by: Suraj Kandpal
Reviewed-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_reg.h | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
From: Ankit Nautiyal
Go with DSC only if the given output_format is supported.
v2: Use drm helper to get DSC format support for sink.
v3: remove drm_dp_dsc_compute_bpp.
Cc: Uma Shankar
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 28 +
From: Ankit Nautiyal
Add helper to check if the DP sink supports DSC with the given
o/p format.
v2: Add documentation for the helper. (Uma Shankar)
Signed-off-by: Ankit Nautiyal
---
include/drm/display/drm_dp_helper.h | 13 +
1 file changed, 13 insertions(+)
diff --git
This patch series aims to enable the YCbCr420 format
for DSC. Changes are mostly compute params related for
hdmi,dp and dsi along with the addition of new rc_tables
for native_420 and corresponding changes to macros used to
fetch them.
There have been discussions prior to this series in which some
When the input to a DU channel comes from a VSP, the DU doesn't perform
any blending operation. Select XRGB instead of ARGB to ensure
that the corresponding registers don't get written with invalid values.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +-
The ESCR and OTAR registers are not present in all DU channels on Gen3
SoCs. ESCR only exists in channels that can be routed to an LVDS or
DPAD, and OTAR in channels that can be routed to a DPAD. Skip writing
those registers for other channels. This replaces the DU gen check, as
Gen4 doesn't have
Hello,
This patch series addresses writes to reserved register fields or
reserved registers.
Depending on the DU variant, some registers or register fields are
marked as reserved, but the rcar-du driver writes them unconditionally.
There is a high chance that those registers and fields are
Hi Andy,
Thanks for the review.
On Tue, Feb 21, 2023 at 7:36 PM Andy Shevchenko
wrote:
>
> 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
On Tue, Feb 21, 2023 at 5:51 PM Pin-yen Lin wrote:
>
> These two drivers embed a i2c_client in there private driver data, but
This should be "their private driver data". I'll fix this in the next version.
Pin-yen
> only strict device is actually needed. Replace the i2c_client reference
> with
On Tue, Feb 21, 2023 at 11:37 PM AngeloGioacchino Del Regno
wrote:
>
> 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"
On Tue, Feb 21, 2023 at 11:37 PM AngeloGioacchino Del Regno
wrote:
>
> 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:
On Tue, Feb 21, 2023 at 11:37 PM AngeloGioacchino Del Regno
wrote:
>
> 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
Am 2023-02-21 um 22:05 schrieb qu.hu...@linux.dev:
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() function, it
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 3fb1f62f80a1d249260db5ea9e22c51e52fab9ae
commit: 3fb1f62f80a1d249260db5ea9e22c51e52fab9ae [1/1] drm/fb-helper: Remove
drm_fb_helper_unprepare() from drm_fb_helper_fini()
config: arm-buildonly-randconfig-r004-20230219
On Tue, Feb 21, 2023 at 3:20 PM Rob Clark wrote:
>
> 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
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
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 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
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 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
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...___/__ __\__...
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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 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:
>
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
> >
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 ++
* 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
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
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.
>>
>>
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
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 |
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: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: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
> ---
>
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
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()
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
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()
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
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
> > > >
> > > >
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
---
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
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
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 +-
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
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
> ---
>
>
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 +++
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
---
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
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
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
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
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
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
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
---
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
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
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
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
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
>>> +++
https://bugzilla.kernel.org/show_bug.cgi?id=217065
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
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
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
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
> > > >
> >
this is a test email, Sorry to be a bother
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
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.
>>>
>>>
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()
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
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
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"
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
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 @@
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
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 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.
>
>
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
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
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
1 - 100 of 123 matches
Mail list logo
