of_icc_get() alloc resources for path1, we should release it when not
need anymore. Early return when IS_ERR_OR_NULL(path0) may leak path1.
Add icc_put(path1) in the error path to fix this.
Fixes: b9364eed9232 ("drm/msm/dpu: Move min BW request and full BW disable back
to mdss")
Signed-off-by:
As kzalloc may fail and return NULL pointer,
it should be better to check the return value
in order to avoid the NULL pointer dereference.
Fixes: 1cff7440a86e ("drm/msm: Convert to using
__drm_atomic_helper_crtc_reset() for reset.")
Signed-off-by: Jiasheng Jiang
---
GSC FW is loaded by submitting a dedicated command via the GSC engine.
The memory area used for loading the FW is then re-purposed as local
memory for the GSC itself, so we use a separate allocation instead of
using the one where we keep the firmware stored for reload.
The GSC is not reset as
On Mon, Dec 05, 2022 at 12:50:53PM +0200, Jani Nikula wrote:
> On Thu, 01 Dec 2022, wrote:
> > From: ye xingchen
> >
> > Replace the open-code with sysfs_emit() to simplify the code.
>
> I was going to push this, but noticed the function has a third
> scnprintf(), and the last two play together
As kzalloc may fail and return NULL pointer,
it should be better to check the return value
in order to avoid the NULL pointer dereference.
Fixes: 1cff7440a86e ("drm/msm: Convert to using
__drm_atomic_helper_crtc_reset() for reset.")
Signed-off-by: Jiasheng Jiang
---
From: Nathan Lu
modify VDOSYS0 display device tree Documentations for MT8188.
Signed-off-by: Nathan Lu
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: AngeloGioacchino Del Regno
---
.../devicetree/bindings/display/mediatek/mediatek,aal.yaml| 1 +
From: Nathan Lu
add mtk-mutex support for mt8188 vdosys0.
Signed-off-by: amy zhang
Signed-off-by: Nathan Lu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/soc/mediatek/mtk-mutex.c | 53
1 file changed, 53 insertions(+)
diff --git
From: Nathan Lu
modify VDOSYS0 mutex device tree Documentations for MT8188.
Signed-off-by: Nathan Lu
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/soc/mediatek/mediatek,mutex.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Nathan Lu
1. add mt8188 mmsys
2. add mt8188 vdosys0 routing table settings
Signed-off-by: amy zhang
Signed-off-by: Nathan Lu
---
drivers/soc/mediatek/mt8188-mmsys.h | 149
drivers/soc/mediatek/mtk-mmsys.c| 11 ++
2 files changed, 160 insertions(+)
From: Nathan Lu
add driver data of mt8188 vdosys0 to mediatek-drm and the sub driver.
Signed-off-by: amy zhang
Signed-off-by: Nathan Lu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 21 +
1 file changed, 21 insertions(+)
diff
From: Nathan Lu
modify VDOSYS0 mmsys device tree Documentations for MT8188.
Signed-off-by: Nathan Lu
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
From: Nathan Lu
This patch is to add first version mt8188 vdosys0 driver
Modify and add new files include:
1. bindings documents
2. mtk mmsys
3. mtk mutex
4. mtk drm driver
Change in V4:
- based on [1]
[1] Change mmsys compatible for mt8195 mediatek-drm
-
Now that we have the GSC FW support code as a user to the GSC CS, we
can add the relevant flag to the engine mask. Note that the engine will
still be disabled until we define the GSC FW binary file.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
GSC FW is loaded by submitting a dedicated command via the GSC engine.
The memory area used for loading the FW is then re-purposed as local
memory for the GSC itself, so we use a separate allocation instead of
using the one where we keep the firmware stored for reload.
The GSC is not reset as
The current exectation from the FW side is that the driver will query
the GSC FW version after the FW is loaded, similarly to what the mei
driver does on DG2. However, we're discussing with the FW team if there
is a way to extract the version from the bin file before loading, so we
can keep the
From: Jonathan Cavitt
The GSC CS is only used for communicating with the GSC FW, so no need to
initialize it if we're not going to use the FW. If we're not using
neither the engine nor the microcontoller, then we can also disable the
power well.
IMPORTANT: lack of GSC FW breaks media C6 due to
If the GSC was loaded, the only way to stop it during the driver unload
flow is to do a driver-FLR.
The driver-initiated FLR is not the same as PCI config space FLR in
that it doesn't reset the SGUnit and doesn't modify the PCI config
space. Thus, it doesn't require a re-enumeration of the PCI
On MTL the GSC FW needs to be loaded on the media GT by the graphics
driver. We're going to treat it like a new uc_fw, so add the initial
defs and init/fini functions for it.
Similarly to the other FWs, the GSC FW path can be overriden via
modparam. The modparam can also be used to disable the
Starting from MTL, the GSC FW is runtime loaded by the driver, instead
of being stored in flash memory. Loading the GSC FW is required to allow
the media GT to go into its C6 state and for content protection features
(PXP, HDCP).
The loading happens via a submission to the GSC engine. All
On 12/5/22 10:55, Melissa Wen wrote:
> As v3d_lookup_bos() performs the same steps as drm_gem_objects_lookup(),
> replace the explicit code in v3d to simply use the DRM function.
>
> Signed-off-by: Melissa Wen
Reviewed-by: Maíra Canal
Best Regards,
- Maíra Canal
> ---
>
On 12/5/22 10:55, Melissa Wen wrote:
> When v3d_lookup_bos fails to `allocate validated BO pointers`,
> job->bo_count was already set to args->bo_count, but job->bo points to
> NULL. In this scenario, we must verify that job->bo is not NULL before
> iterating on it to proper clean up a job. Also,
dynamic_debug_init() currently uses strcmp to find the module
boundaries in the builtin _ddebug[] table.
The table is filled by the linker; for its content, pointer inequality
works, is faster, and communicates the data properties more tightly.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c
It appears that, at least for builtin drm,i915 loadable amdgpu, data
in the class_refs section is not properly linked, this works partway
towards isolating the problem.
The "NO CLI" name test is failing.
This version of the report fails with a non-canonical address:
// v2pr_info("NO CLI name
Cited commit uses stale macro name, fix this, and explain better.
When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug. This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the
for loadable drm, helpers, and drivers, dependent-load is failing to
apply changes, needs more investigation.
---
lib/dynamic_debug.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 46684aa7284d..3ef1c0a1f0cd 100644
---
dont break the loop, to see multiple clients. the 3 client records
are differently wrong.
---
lib/dynamic_debug.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 3ef1c0a1f0cd..a26eaa348731 100644
--- a/lib/dynamic_debug.c
patch 1 in this series fixed a CLASSMAP usage error, this improves the
api so that misuse is less likely.
changes here:
0- Add William Swanson's public domain map macro:
https://github.com/swansontec/map-macro/blob/master/map.h
this makes 1 possible.
1- classnames were formerly specified
DECLARE_DYNDBG_CLASSMAPs job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf. Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap). Modules wanting a drm.debug
style knob need
Drop macro args after _var. Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward. Keep only the _var arg, which is the extern'd struct
classmap with all the class info.
Signed-off-by: Jim Cromie
---
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly
ddebug_apply_class_bitmap() currently applies the class settings to
all modules, make it more selective, by adding query_module param.
The fn now calls ddebug_exec_queries(query, NULL), where NULL is
query_modname wildcard ("*" does the same). So just expose the
parameter, and alter users to
ARRAY_SIZE works here, since array decl is complete.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index bf47bcfad8e6..81b643ab7f6e 100644
---
Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE variants, lets
differentiate them according to their separate jobs.
Dyndbg's existing __dyndbg_classes[] section does:
. catalogs the classmaps defined by the module (or builtin modules)
currently, for verbose=3, this is logged:
[ 3832.333424] dyndbg: parsed: func="" file="" module="amdgpu" format=""
lineno=0-0 class=DRM_UT_PRIME
[ 3832.333888] dyndbg: no matches for query
[ 3832.334093] dyndbg: no-match: func="" file="" module="amdgpu" format=""
lineno=0-0 class=DRM_UT_PRIME
[
The inner func has a base arg which is unused in the body, so theres
no point in having the inner fn. Its one-time purpose was subsumed
into the ddebug_info record, which is used in dynamic_debug_init() as
a cursor to load the builtin _ddebug[] table.
TODO: cited commit gives another reason for
Since sysfs knobs should generally read-back what was just written
(unless theres a good reason to do otherwise), this result (using
test_dynamic_debug.ko) is suboptimal:
echo L3 > p_level_names
cat p_level_names
4
Fix this with a -1 offset in LEVEL_NAMES readback.
NOTE:
Calling this a
Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined. Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:
[ 15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[ 15.293189] dyndbg: 32 debug prints in
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
Hi everyone,
DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
Regression is due to a chicken-egg problem loading modules; on
`modprobe i915`, drm is loaded 1st, and drm.debug is set. When
drm_debug_enabled() tested __drm_debug at runtime, that just worked.
But with DRM_USE_DYNAMIC_DEBUG=y, the
6 декабря 2022 г. 02:08:13 GMT+03:00, Kuogee Hsieh
пишет:
>Add capability to parser and retrieve max DP link supported rate from
>link-frequencies property of dp_out endpoint.
>
>Changes in v6:
>-- second patch after split parser patch into two patches
>
>Changes in v7:
>-- without checking cnt
Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.
Changes in v6:
-- first patch after split parser patch into two
Changes in v7:
-- check "data-lanes" from endpoint first
By default, HBR2 (5.4G) is the max link link be supported. This patch uses the
actual limit specified by DT and removes the artificial limitation to 5.4 Gbps.
Supporting HBR3 is a consequence of that.
Changes in v2:
-- add max link rate from dtsi
Changes in v3:
-- parser max_data_lanes and
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
Changes in v9:
--
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Signed-off-by: Kuogee Hsieh `
---
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out
Add DP both data-lanes and link-frequencies property to dp_out endpoint and
support
functions to DP driver.
Kuogee Hsieh (5):
arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
dt-bindings: msm/dp: add data-lanes and link-frequencies property
drm/msm/dp: parser
On Thu, Dec 01, 2022 at 11:38:16AM +0100, Krzysztof Kozlowski wrote:
> On 30/11/2022 21:09, Adam Skladowski wrote:
> > Add WCN node to allow using wifi module.
> >
>
> A nit: Drop full stop from commit subject.
>
Done. Thanks for pointing it out :)
Regards,
Bjorn
> Best regards,
> Krzysztof
Hi!
> .get_state() might fail in some cases. To make it possible that a driver
> signals such a failure change the prototype of .get_state() to return an
> error code.
>
> This patch was created using coccinelle and the following semantic patch:
>
> @p1@
> identifier getstatefunc;
> identifier
On Tue, Dec 06, 2022 at 12:29:13AM +0300, Dmitry Baryshkov wrote:
>
>
> On 5 December 2022 20:44:28 GMT+03:00, Bjorn Andersson
> wrote:
> >From: Bjorn Andersson
> >
> >The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
> >physical signal on a GPIO pin into the controller.
syzbot is reporting memory leak at fbcon_do_set_font() [1], for
commit a5a923038d70 ("fbdev: fbcon: Properly revert changes when
vc_resize() failed") missed that the buffer might be newly allocated
by fbcon_set_font().
Link: https://syzkaller.appspot.com/bug?extid=25bdb7b1703639abd498 [1]
Hi Thomas,
On Mon, Dec 5, 2022 at 3:11 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 05.12.22 um 10:32 schrieb m...@lab.how:
> > I have a rtx 3070 and a 3090, I am absolutely sure I am binding vfio-pci
> > to the 3090 and not the 3070.
> >
> > I have bound the driver in two different ways, first by
On 5 December 2022 22:14:27 GMT+03:00, Kuogee Hsieh
wrote:
>Add both data-lanes and link-frequencies property into endpoint
>
>Changes in v7:
>-- split yaml out of dtsi patch
>-- link-frequencies from link rate to symbol rate
>-- deprecation of old data-lanes property
>
>Changes in v8:
>--
On 5 December 2022 20:44:28 GMT+03:00, Bjorn Andersson
wrote:
>From: Bjorn Andersson
>
>The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
>physical signal on a GPIO pin into the controller. This is not always
>possible, either because there aren't dedicated GPIOs
On Mon, Dec 05, 2022 at 04:33:29PM -0300, Gustavo Sousa wrote:
> On Thu, Dec 01, 2022 at 02:22:10PM -0800, Matt Roper wrote:
> > The TGL/RKL/DG1/ADL performance tuning guide suggests programming a
> > literal value of 0x2FC0100F for this register. The register's hardware
> > default value is
On 5 December 2022 20:44:32 GMT+03:00, Bjorn Andersson
wrote:
>From: Bjorn Andersson
>
>The SC8280XP CRD has a EDP display on MDSS0 DP3, enable relevant nodes
>and link it together with the backlight control.
>
>Signed-off-by: Bjorn Andersson
>Signed-off-by: Bjorn Andersson
>---
>
>Changes
On 6 December 2022 00:07:12 GMT+03:00, Dmitry Baryshkov
wrote:
>
>
>On 5 December 2022 20:44:29 GMT+03:00, Bjorn Andersson
> wrote:
>>From: Bjorn Andersson
>>
>>Most instances where HPD interrupts are masked and unmasked are guareded
>>by the presence of an EDP panel being connected, but
On 5 December 2022 20:44:30 GMT+03:00, Bjorn Andersson
wrote:
>From: Bjorn Andersson
>
>The DisplayPort controller's internal HPD interrupt handling is used for
>cases where the HPD signal is connected to a GPIO which is pinmuxed into
>the DisplayPort controller. In other configurations the
On Mon, 05 Dec 2022 09:44:21 -0800, Bjorn Andersson wrote:
> From: Bjorn Andersson
>
> Add binding for the display subsystem and display processing unit in the
> Qualcomm SC8280XP platform.
>
> Signed-off-by: Bjorn Andersson
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v3:
> -
On Mon, 05 Dec 2022 17:37:45 +0100, Robert Foss wrote:
> Mobile Display Subsystem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema for MDSS device
> tree bindings
>
> Signed-off-by: Robert Foss
> ---
> .../display/msm/qcom,sm8350-mdss.yaml | 221
On 5 December 2022 20:44:29 GMT+03:00, Bjorn Andersson
wrote:
>From: Bjorn Andersson
>
>Most instances where HPD interrupts are masked and unmasked are guareded
>by the presence of an EDP panel being connected, but not all. Extend
>this to cover the last few places, as HPD interrupt handling
On Mon, 05 Dec 2022 11:14:27 -0800, Kuogee Hsieh wrote:
> Add both data-lanes and link-frequencies property into endpoint
>
> Changes in v7:
> -- split yaml out of dtsi patch
> -- link-frequencies from link rate to symbol rate
> -- deprecation of old data-lanes property
>
> Changes in v8:
> --
On 5 December 2022 20:44:28 GMT+03:00, Bjorn Andersson
wrote:
>From: Bjorn Andersson
>
>The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
>physical signal on a GPIO pin into the controller. This is not always
>possible, either because there aren't dedicated GPIOs
On 5 December 2022 20:44:23 GMT+03:00, Bjorn Andersson
wrote:
>From: Bjorn Andersson
>
>Add compatible for the SC8280XP Mobile Display Subsystem and
>initialization for version 8.0.0.
>
>Signed-off-by: Bjorn Andersson
>Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
>---
On 5 December 2022 22:14:30 GMT+03:00, Kuogee Hsieh
wrote:
>By default, HBR2 (5.4G) is the max link link be supported. This patch add
>the capability to support max link rate at HBR3 (8.1G).
This patch uses the actual limit specified by DT and removes the artificial
limitation to 5.4 Gbps.
On 5 December 2022 22:14:29 GMT+03:00, Kuogee Hsieh
wrote:
>Add capability to parser and retrieve max DP link supported rate from
>link-frequencies property of dp_out endpoint.
>
>Changes in v6:
>-- second patch after split parser patch into two patches
>
>Changes in v7:
>-- without checking
On Mon, 2022-12-05 at 11:53 -0800, Ceraolo Spurio, Daniele wrote:
>
Alan:[snip]
> >
> > ext_data->flags |= I915_BO_PROTECTED;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 29e9e8d5b6fe..ed74d173a092 100644
On 5 December 2022 22:14:26 GMT+03:00, Kuogee Hsieh
wrote:
>Move data-lanes property from mdss_dp node to dp_out endpoint. Also
>add link-frequencies property into dp_out endpoint as well. The last
>frequency specified at link-frequencies will be the max link rate
>supported by DP.
>
>Changes
Dne sreda, 30. november 2022 ob 16:21:38 CET je Uwe Kleine-König napisal(a):
> .get_state() might fail in some cases. To make it possible that a driver
> signals such a failure change the prototype of .get_state() to return an
> error code.
>
> This patch was created using coccinelle and the
On 5 December 2022 22:14:28 GMT+03:00, Kuogee Hsieh
wrote:
>Add capability to parser data-lanes as property of dp_out endpoint.
>Also retain the original capability to parser data-lanes as property
>of mdss_dp node to handle legacy case.
>
>Changes in v6:
>-- first patch after split parser
On 05/12/2022 21:02, Bjorn Andersson wrote:
On Mon, Dec 05, 2022 at 07:09:45PM +0100, Konrad Dybcio wrote:
On 05/12/2022 18:44, Bjorn Andersson wrote:
diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
[..]
+_dp2 {
+ status = "okay";
On Mon, Dec 05, 2022 at 07:09:45PM +0100, Konrad Dybcio wrote:
> On 05/12/2022 18:44, Bjorn Andersson wrote:
> > diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> > b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
[..]
> > +_dp2 {
> > + status = "okay";
> status should go last.
>
Thanks for
On Fri, 25 Nov 2022 12:36:28 +, Bryan O'Donoghue wrote:
> When converting from .txt to .yaml we didn't include descriptions for the
> existing regulator supplies.
>
> - vdd
> - vdda
> - vddio
>
> Add those descriptions into the yaml now as they were prior to the
> conversion. In the .txt
On Fri, 25 Nov 2022 12:36:27 +, Bryan O'Donoghue wrote:
> When converting from .txt to .yaml dt-binding descriptions we appear to
> have missed some of the previous detail on the number and names of
> permissible clocks.
>
> Fix this by listing the clock descriptions against the clock names
On Fri, 25 Nov 2022 12:36:25 +, Bryan O'Donoghue wrote:
> Each compatible has a different set of clocks which are associated with it.
> Add in the list of clocks for each compatible.
>
> Signed-off-by: Bryan O'Donoghue
> ---
> .../display/msm/dsi-controller-main.yaml | 152
Am 30.11.22 um 15:06 schrieb Daniel Vetter:
On Wed, 30 Nov 2022 at 14:03, Tvrtko Ursulin
wrote:
On 29/11/2022 18:05, Matthew Auld wrote:
On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
wrote:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality
On 12/2/2022 3:28 PM, Alan Previn wrote:
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only
On Thu, Dec 01, 2022 at 02:22:10PM -0800, Matt Roper wrote:
> The TGL/RKL/DG1/ADL performance tuning guide suggests programming a
> literal value of 0x2FC0100F for this register. The register's hardware
> default value is 0x2FC0108F, so this translates to just clearing one
> bit.
>
> Take this
Hi Robert,
On 5.12.22 18:37, Robert Foss wrote:
Use two interconnect cells in order to optionally
support a path tag.
Signed-off-by: Robert Foss
Reviewed-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 28 ++--
1 file changed, 14 insertions(+), 14
On 12/5/2022 11:04 AM, Teres Alexis, Alan Previn wrote:
On Mon, 2022-12-05 at 12:57 -0500, Vivi, Rodrigo wrote:
On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
Alan: [snip]
@@ -1168,6 +1176,8 @@ static int i915_drm_prepare(struct drm_device *dev)
{
struct
By default, HBR2 (5.4G) is the max link link be supported. This patch add
the capability to support max link rate at HBR3 (8.1G).
Changes in v2:
-- add max link rate from dtsi
Changes in v3:
-- parser max_data_lanes and max_dp_link_rate from dp_out endpoint
Changes in v4:
-- delete unnecessary
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
Signed-off-by:
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out
Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.
Changes in v6:
-- first patch after split parser patch into two
Changes in v7:
-- check "data-lanes" from endpoint first
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Signed-off-by: Kuogee Hsieh
---
Add DP both data-lanes and link-frequencies property to dp_out endpoint and
support
functions to DP driver.
Kuogee Hsieh (5):
arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
dt-bindings: msm/dp: add data-lanes and link-frequencies property
drm/msm/dp: parser
On Mon, 2022-12-05 at 12:57 -0500, Vivi, Rodrigo wrote:
> On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
> >
> >
> >
Alan: [snip]
> > @@ -1168,6 +1176,8 @@ static int i915_drm_prepare(struct drm_device *dev)
> > {
> > struct drm_i915_private *i915 = to_i915(dev);
> >
>
On 05.12.2022 14:16, Tvrtko Ursulin wrote:
>
> On 02/12/2022 20:14, John Harrison wrote:
>
and while for dbg level messages it doesn't matter, I assume we should
be consistent for err/warn/info messages (as those will eventually show
up to the end user) so let maintainers
On 05/12/2022 16:27, Matt Roper wrote:
On Mon, Dec 05, 2022 at 12:50:40PM +, Tvrtko Ursulin wrote:
On 02/12/2022 22:49, Rodrigo Vivi wrote:
On Fri, Dec 02, 2022 at 02:35:28PM -0800, Matt Roper wrote:
When determining whether the platform has a hardware-level steering
semaphore (i.e.,
On 05/12/2022 15:52, Matt Roper wrote:
On Mon, Dec 05, 2022 at 08:58:16AM +, Tvrtko Ursulin wrote:
On 28/11/2022 23:30, Matt Roper wrote:
Starting with MTL, the driver needs to not only protect the steering
control register from simultaneous software accesses, but also protect
against
On 05/12/2022 18:44, Bjorn Andersson wrote:
From: Bjorn Andersson
The SA8295P ADP has, among other interfaces, six MiniDP connectors which
are connected to MDSS0 DP2 and DP3, and MDSS1 DP0 through DP3.
Enable Display Clock controllers, MDSS instanced, MDPs, DP controllers,
DP PHYs and link
On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
> Starting with MTL, there will be two GT-tiles, a render and media
> tile. PXP as a service for supporting workloads with protected
> contexts and protected buffers can be subscribed by process
> workloads on any tile. However,
By default, HBR2 (5.4G) is the max link link be supported. This patch add
the capability to support max link rate at HBR3 (8.1G).
Changes in v2:
-- add max link rate from dtsi
Changes in v3:
-- parser max_data_lanes and max_dp_link_rate from dp_out endpoint
Changes in v4:
-- delete unnecessary
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
Signed-off-by:
Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.
Changes in v6:
-- first patch after split parser patch into two
Changes in v7:
-- check "data-lanes" from endpoint first
Add both data-lanes and link-frequencies property into endpoint
changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Signed-off-by: Kuogee Hsieh
---
.../bindings/display/msm/dp-controller.yaml| 22
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out
Add DP both data-lanes and link-frequencies property to dp_out endpoint and
support
functions to DP driver.
Kuogee Hsieh (5):
arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
dt-bindings: msm/dp: add data-lanes and link-frequencies property
drm/msm/dp: parser
From: Bjorn Andersson
The SA8295P ADP has, among other interfaces, six MiniDP connectors which
are connected to MDSS0 DP2 and DP3, and MDSS1 DP0 through DP3.
Enable Display Clock controllers, MDSS instanced, MDPs, DP controllers,
DP PHYs and link them all together.
Signed-off-by: Bjorn
From: Bjorn Andersson
Most instances where HPD interrupts are masked and unmasked are guareded
by the presence of an EDP panel being connected, but not all. Extend
this to cover the last few places, as HPD interrupt handling is not used
for the EDP case.
Signed-off-by: Bjorn Andersson
From: Bjorn Andersson
Define the display clock controllers, the MDSS instances, the DP phys
and connect these together.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
I did not add the USB-related DP controllers back into this patch. Will send
that separately once I've
1 - 100 of 182 matches
Mail list logo
