Re: [PATCH v6 3/8] drm/bridge: mhdp8546: Add minimal format negotiation
Hi Tomi,
Thank you for taking a look at this.
On 26/05/23 14:59, Tomi Valkeinen wrote:
> On 16/05/2023 17:25, Aradhya Bhatia wrote:
>> Hi Neil,
>>
>> Thank you for reviewing the patch.
>>
>> On 16-May-23 12:51, Neil Armstrong wrote:
>>> On 15/05/2023 17:59, Aradhya Bhatia wrote:
Hi Tomi,
On 12-May-23 14:45, Tomi Valkeinen wrote:
> On 09/05/2023 12:30, Aradhya Bhatia wrote:
>> From: Nikhil Devshatwar
>>
>> With new connector model, mhdp bridge will not create the
>> connector and
>> SoC driver will rely on format negotiation to setup the encoder
>> format.
>>
>> Support minimal format negotiations hooks in the drm_bridge_funcs.
>> Complete format negotiation can be added based on EDID data.
>> This patch adds the minimal required support to avoid failure
>> after moving to new connector model.
>>
>> Signed-off-by: Nikhil Devshatwar
>> Reviewed-by: Tomi Valkeinen
>
> You need to add your SoB to this and the other patches.
Okay!
>
>> ---
>>
>> Notes:
>>
>> changes from v1:
>> * cosmetic fixes, commit message update.
>>
>> changes from v5:
>> * dropped the default_bus_format variable and directly
>> assigned
>> MEDIA_BUS_FMT_RGB121212_1X36 to input_fmts.
>>
>> .../drm/bridge/cadence/cdns-mhdp8546-core.c | 25
>> +++
>> 1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> index f6822dfa3805..623e4235c94f 100644
>> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>> @@ -2146,6 +2146,30 @@ cdns_mhdp_bridge_atomic_reset(struct
>> drm_bridge
>> *bridge)
>> return &cdns_mhdp_state->base;
>> }
>> +static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge
>> *bridge,
>> + struct drm_bridge_state *bridge_state,
>> + struct drm_crtc_state *crtc_state,
>> + struct drm_connector_state *conn_state,
>> + u32 output_fmt,
>> + unsigned int *num_input_fmts)
>> +{
>> + u32 *input_fmts;
>> +
>> + *num_input_fmts = 0;
>> +
>> + if (output_fmt != MEDIA_BUS_FMT_FIXED)
>> + return NULL;
>
> The tfp410 and sii902x drivers don't have the above check. Why does
> mhdp
> need it? Or the other way, why don't tfp410 and sii902x need it?
I had removed this condition in order to follow status quo, from the
ITE-66121 HDMI bridge driver.
The idea would have been to drop this for MHDP as well, but I guess I
overlooked this one.
However...
> I guess at the moment we always do get MEDIA_BUS_FMT_FIXED as the out
> fmt (in all three bridge drivers), don't we?
... I tested again to ensure that the above is indeed the case. And
ended up catching some odd behavior.
It turns out that for all the HDMI bridges (TFP410, SII902X,
ITE-66121),
the format negotiation doesn't stop at output_fmt =
MEDIA_BUS_FMT_FIXED.
The {bridge}_get_input_format API gets called again with the output_fmt
= MEDIA_BUS_FMT_RGB24_1X24.
This doesn't happen with the MHDP driver. Format negotiation with MHDP
bridge stops after one round, at output_fmt = MEDIA_BUS_FMT_FIXED.
>>>
>>> This is because the bridge negociation logic will test with all possible
>>> output formats from the chain, and won't stop at first working test.
>>>
>> Okay..
>>
>>> If your bridge only supports a single input format, it should return the
>>> same format whatever output_fmt is tried.
>>>
>>> So indeed remove this test on mhdp aswell, or filter out invalid output
>>> formats.
>> Agreed.
>>
>> I have been looking into the code deeper and trying to understand the
>> logic flow around the format negotiation in the framework. Here are the
>> 2 points that I want to mention. Please let me know if I have missed
>> something with my understanding.
>>
>>
>> Firstly, the mhdp-8546 output connects to the display-connector (with
>> the compatible, "dp-connector") in the devicetree.
>>
>> When the negotiation begins at 'drm_atomic_bridge_chain_select_bus_fmts'
>> the display-connector bridge *should* act as the 'last_bridge', and the
>> atomic_get_output_bus_fmts hook of the display-connector should get
>> called. However, for some reason I am not yet sure of, the condition
>>
>> :: if (last_bridge->funcs->atomic_get_output_bus_fmts)
>>
>> fails and the 'select_bus_fmt_recursive' function gets called instead,
>> (with MEDIA_BUS_FMT_FIXED as output_fmt), which in turn calls the
>> atomic_get_input_bus_fmts hook of the mhdp-8546. This entirely skips the
>> d
RE: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, May 26, 2023 7:18 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign
> handling
>
> On Thu, May 25, 2023 at 08:55:08PM +, Shankar, Uma wrote:
> >
> >
> > > -Original Message-
> > > From: dri-devel On Behalf
> > > Of Ville Syrjala
> > > Sent: Thursday, April 13, 2023 10:19 PM
> > > To: intel-...@lists.freedesktop.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Subject: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign
> > > handling
> > >
> > > From: Ville Syrjälä
> > >
> > > The CHV CGM CSC coefficients are in s4.12 two's complement format.
> > > Fix the CTM-
> > > >CGM conversion to handle that correctly instead of pretending that
> > > >the hw
> > > coefficients are also in some sign-magnitude format.
> >
> > Spec is slightly confusing when it says:
> > "CGM CSC : Input pixels to the CGM CSC are 14 bits. (u.14 format).
> > Coefficients are
> 16 bits (s3.12)."
> > Also here:
> > "Programmable parameters :
> > c0[15 :0], c1[15 :0], c2[15 :0], c3[15 :0], c4[15 :0], c5[15 :0], c6[15
> > :0], c7[15 :0],
> c8[15 :0] ; // signed matrix coefficients (s3.12)"
>
> Yeah, the spec just uses a weird notation where it doesn't count the msb in
> the bits.
>
> >
> > But the coefficients are 16bits, can you help understand how were you
> > able to crack this 😊
>
> The 16bit coefficient already made me suspect they screwed up the notation.
> Testing specific values on real hardware confirmed that.
Got it, thanks Ville for the clarification.
> >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_color.c | 46
> > > ++
> > > 1 file changed, 29 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > > b/drivers/gpu/drm/i915/display/intel_color.c
> > > index 4fc16cac052d..63141f4ed372 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > > @@ -568,29 +568,41 @@ static void icl_load_csc_matrix(const struct
> > > intel_crtc_state *crtc_state)
> > > icl_update_output_csc(crtc, &crtc_state->output_csc); }
> > >
> > > +static u16 ctm_to_twos_complement(u64 coeff, int int_bits, int
> > > +frac_bits) {
> > > + s64 c = CTM_COEFF_ABS(coeff);
> > > +
> > > + /* leave an extra bit for rounding */
> > > + c >>= 32 - frac_bits - 1;
> > > +
> > > + /* round and drop the extra bit */
> > > + c = (c + 1) >> 1;
> > > +
> > > + if (CTM_COEFF_NEGATIVE(coeff))
> > > + c = -c;
> > > +
> > > + c = clamp(c, -(s64)BIT(int_bits + frac_bits - 1),
> > > + (s64)(BIT(int_bits + frac_bits - 1) - 1));
> > > +
> > > + return c & (BIT(int_bits + frac_bits) - 1); }
> > > +
> > > +/*
> > > + * CHV Color Gamut Mapping (CGM) CSC
> > > + * |r| | c0 c1 c2 | |r|
> > > + * |g| = | c3 c4 c5 | x |g|
> > > + * |b| | c6 c7 c8 | |b|
> > > + *
> > > + * Coefficients are two's complement s4.12.
> > > + */
> > > static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state
> > > *crtc_state,
> > > struct intel_csc_matrix *csc) {
> > > const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
> > > int i;
> > >
> > > - for (i = 0; i < 9; i++) {
> > > - u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
> > > -
> > > - /* Round coefficient. */
> > > - abs_coeff += 1 << (32 - 13);
> > > - /* Clamp to hardware limits. */
> > > - abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
> > > -
> > > - csc->coeff[i] = 0;
> > > -
> > > - /* Write coefficients in S3.12 format. */
> > > - if (ctm->matrix[i] & (1ULL << 63))
> > > - csc->coeff[i] |= 1 << 15;
> > > -
> > > - csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
> > > - csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
> > > - }
> > > + for (i = 0; i < 9; i++)
> > > + csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
> > > }
> > >
> > > static void chv_load_cgm_csc(struct intel_crtc *crtc,
> > > --
> > > 2.39.2
> >
>
> --
> Ville Syrjälä
> Intel
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
On Mon, May 29, 2023 at 12:14 PM Icenowy Zheng wrote:
>
> 在 2023-05-26星期五的 07:24 -0700，Doug Anderson写道：
> > Hi,
> >
> > On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng wrote:
> > >
> > > Currently a specific panel number is used in the Elm DTSI, which is
> > > corresponded to a 12" panel. However, according to the official
> > > Chrome
> > > OS devices document, Elm refers to Acer Chromebook R13, which, as
> > > the
> > > name specifies, uses a 13.3" panel, which comes with EDID
> > > information.
> > >
> > > As the kernel currently prioritizes the hardcoded timing parameters
> > > matched with the panel number compatible, a wrong timing will be
> > > applied
> > > to the 13.3" panel on Acer Chromebook R13, which leads to blank
> > > display.
> > >
> > > Because the Elm DTSI is shared with Hana board, and Hana
> > > corresponds to
> > > multiple devices from 11" to 14", a certain panel model number
> > > shouldn't
> > > be present, and driving the panel according to its EDID information
> > > is
> > > necessary.
> > >
> > > Signed-off-by: Icenowy Zheng
> > > ---
> > > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > We went through a bunch of back-and-forth here but in the end in the
> > ChromeOS tree we have "edp-panel" as the "compatible" here in the
> > ChromeOS 5.15 tree and this makes sense.
>
> I only have Elm, so I am curious that do all Hana's only rely on panel
> EDID to use different displays?
>
> BTW The Chrome OS document say that Elm and Hana are both board based
> on Oak baseboard, should the DTSI be renamed mt8173-oak.dtsi, and still
> let mt8173-elm.dts include it and then set model information?
>
Oak is a reference design board which is not in the public. Since only
elm and hana board are in the public and the difference between elm
and hana are not much, instead of creating oak.dtsi, elm.dtsi (inherit
from oak.dtsi), hana.dtsi (inherit from oak.dtsi), we decided to make
elm.dtsi as the main dtsi and let hana inherit it and make its own
changes.
> >
> > Reviewed-by: Douglas Anderson
> >
> > ...in theory one would wish for a "Fixes" tag, but I think in
> > previous
> > discussions it was decided that it was too complicated. Hardcoding
> > the
> > other compatible string has always been technically wrong, but I
> > guess
> > it worked at some point in time. The more correct way (as you're
> > doing
> > here) needs the DP AUX bus support and the generic eDP panels, both
> > of
> > which are significantly newer than the elm dts. So I guess leaving no
> > "Fixes" tag is OK, or perhaps you could do the somewhat weak:
>
> Well I remembered when I was developing the support for Pine64
> Pinebook, which is also an ARM64 laptop with an eDP panel (via a DPI-
> eDP bridge, ANX6345). At first I didn't use any panel node in the DT,
> and the kernel maintainers argued to the bridge that seems to be
> connected to nothing (because DP is a discoverable port), and
> fortunately 2 Pinebook SKUs (11.6" and 14") is finally reduced to one,
> and it's then possible to hardcode a panel model in the Pinebook DT.
> According to my memory, the need to specify the panel is to properly
> handle eDP panel power up timing, because it's not a very standard
> thing. (Well, in my memory, when I was testing that code, on a
> (engineering sample) 14" Pinebook, the EDID timing overrided the
> hardcoded 11.6" timing and it properly works, the 14" panel is 1366x768
> but the 11.6" panel is 1920x1080.)
>
> (BTW when I checked the DT of Olimex TERES-I, which uses the same DPI-
> eDP bridge, it is still in the status of a dangling bridge, and of
> course it works ;-) )
>
> >
> > Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move display
> > to ps8640 auxiliary bus")
>
> Well this sound quite reasonable, as the kernel should have proper AUX
> support at this commit.
>
>
Re: [PATCH 0/5] MDSS reg bus interconnect
On Mon, 17 Apr 2023 at 18:30, Konrad Dybcio wrote: > > Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's > another path that needs to be handled to ensure MDSS functions properly, > namely the "reg bus", a.k.a the CPU-MDSS interconnect. > > Gating that path may have a variety of effects.. from none to otherwise > inexplicable DSI timeouts.. > > This series tries to address the lack of that. > > Example path: > > interconnects = <&bimc MASTER_AMPSS_M0 0 &config_noc SLAVE_DISPLAY_CFG 0>; If we are going to touch the MDSS interconnects, could you please also add the rotator interconnect to the bindings? We do not need to touch it at this time, but let's not have to change bindings later again. > > Signed-off-by: Konrad Dybcio > --- > Konrad Dybcio (5): > dt-bindings: display/msm: Add reg bus interconnect > drm/msm/dpu1: Rename path references to mdp_path > drm/msm/mdss: Rename path references to mdp_path > drm/msm/mdss: Handle the reg bus ICC path > drm/msm/dpu1: Handle the reg bus ICC path > > .../bindings/display/msm/mdss-common.yaml | 1 + > drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 10 +++ > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 34 - > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 5 ++-- > drivers/gpu/drm/msm/msm_mdss.c | 35 > ++ > 5 files changed, 57 insertions(+), 28 deletions(-) > --- > base-commit: d3f2cd24819158bb70701c3549e586f9df9cee67 > change-id: 20230417-topic-dpu_regbus-abc94a770952 > > Best regards, > -- > Konrad Dybcio > -- With best wishes Dmitry
Re: [PATCH V2] dt-bindings: bridge: samsung-dsim: Make some flags optional
On Sun, May 28, 2023 at 10:27 AM Adam Ford wrote: > > In the event a device is connected to the samsung-dsim > controller that doesn't support the burst-clock, the > driver is able to get the requested pixel clock from the > attached device or bridge. In these instances, the > samsung,burst-clock-frequency isn't needed, so remove > it from the required list. > > The pll-clock frequency can be set by the device tree entry > for samsung,pll-clock-frequency, but in some cases, the > pll-clock may have the same clock rate as sclk_mipi clock. > If they are equal, this flag is not needed since the driver > will use the sclk_mipi rate as a fallback. > > Signed-off-by: Adam Ford > Reviewed-by: Conor Dooley > --- > V2: Split from driver series. Re-word updates for burst > and pll-clock frequency. Reviewed-by: Fabio Estevam
Re: [PATCH RFC 01/10] drm/panel: Clean up SOFEF00 config dependencies
On 21/05/2023 22:23, Marijn Suijten wrote:
> As per the config name this Display IC features a DSI command-mode
> interface (or the command to switch to video mode is not
> known/documented) and does not use any of the video-mode helper
> utilities, hence should not select VIDEOMODE_HELPERS. In addition it
> uses devm_gpiod_get() and related functions from GPIOLIB.
>
> Fixes: 5933baa36e26 ("drm/panel/samsung-sofef00: Add panel for OnePlus 6/T
> devices")
> Signed-off-by: Marijn Suijten
Reviewed-by: Caleb Connolly
> ---
> drivers/gpu/drm/panel/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 2b9d6db7860ba..67ef898d133f2 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -608,10 +608,10 @@ config DRM_PANEL_SAMSUNG_S6E8AA0
>
> config DRM_PANEL_SAMSUNG_SOFEF00
> tristate "Samsung sofef00/s6e3fc2x01 OnePlus 6/6T DSI cmd mode panels"
> + depends on GPIOLIB
> depends on OF
> depends on DRM_MIPI_DSI
> depends on BACKLIGHT_CLASS_DEVICE
> - select VIDEOMODE_HELPERS
> help
> Say Y or M here if you want to enable support for the Samsung AMOLED
> command mode panels found in the OnePlus 6/6T smartphones.
>
> --
> 2.40.1
>
--
Kind Regards,
Caleb
[PATCH][next] drm/amdgpu/discovery: Replace fake flex-arrays with flexible-array members
Zero-length and one-element arrays are deprecated, and we are moving
towards adopting C99 flexible-array members, instead.
Use the DECLARE_FLEX_ARRAY() helper macro to transform zero-length
arrays in a union into flexible-array members. And replace a one-element
array with a C99 flexible-array member.
Address the following warnings found with GCC-13 and
-fstrict-flex-arrays=3 enabled:
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1009:89: warning: array subscript
kk is outside array bounds of ‘uint32_t[0]’ {aka ‘unsigned int[]’}
[-Warray-bounds=]
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1007:94: warning: array subscript
kk is outside array bounds of ‘uint64_t[0]’ {aka ‘long long unsigned int[]’}
[-Warray-bounds=]
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1310:94: warning: array subscript
k is outside array bounds of ‘uint64_t[0]’ {aka ‘long long unsigned int[]’}
[-Warray-bounds=]
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1309:57: warning: array subscript
k is outside array bounds of ‘uint32_t[0]’ {aka ‘unsigned int[]’}
[-Warray-bounds=]
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].
This results in no differences in binary output.
Link: https://github.com/KSPP/linux/issues/21
Link: https://github.com/KSPP/linux/issues/193
Link: https://github.com/KSPP/linux/issues/300
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/include/discovery.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/include/discovery.h
b/drivers/gpu/drm/amd/include/discovery.h
index 9181e57887db..f43e29722ef7 100644
--- a/drivers/gpu/drm/amd/include/discovery.h
+++ b/drivers/gpu/drm/amd/include/discovery.h
@@ -122,7 +122,7 @@ typedef struct ip_v3
uint8_t sub_revision : 4; /* HCID Sub-Revision */
uint8_t variant : 4;/* HW variant */
#endif
- uint32_t base_address[1]; /* Base Address list.
Corresponds to the num_base_address field*/
+ uint32_t base_address[];/* Base Address list.
Corresponds to the num_base_address field*/
} ip_v3;
typedef struct ip_v4 {
@@ -140,8 +140,8 @@ typedef struct ip_v4 {
uint8_t sub_revision : 4; /* HCID Sub-Revision */
#endif
union {
- uint32_t base_address[0]; /* 32-bit Base Address
list. Corresponds to the num_base_address field*/
- uint64_t base_address_64[0];/* 64-bit Base Address
list. Corresponds to the num_base_address field*/
+ DECLARE_FLEX_ARRAY(uint32_t, base_address); /* 32-bit Base
Address list. Corresponds to the num_base_address field*/
+ DECLARE_FLEX_ARRAY(uint64_t, base_address_64); /* 64-bit Base
Address list. Corresponds to the num_base_address field*/
} __packed;
} ip_v4;
--
2.34.1
[PATCH 6.1 065/119] drm: fix drmm_mutex_init()
From: Matthew Auld
commit c21f11d182c2180d8b90eaff84f574cfa845b250 upstream.
In mutex_init() lockdep identifies a lock by defining a special static
key for each lock class. However if we wrap the macro in a function,
like in drmm_mutex_init(), we end up generating:
int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
{
static struct lock_class_key __key;
__mutex_init((lock), "lock", &__key);
}
The static __key here is what lockdep uses to identify the lock class,
however since this is just a normal function the key here will be
created once, where all callers then use the same key. In effect the
mutex->depmap.key will be the same pointer for different
drmm_mutex_init() callers. This then results in impossible lockdep
splats since lockdep thinks completely unrelated locks are the same lock
class.
To fix this turn drmm_mutex_init() into a macro such that it generates a
different "static struct lock_class_key __key" for each invocation,
which looks to be inline with what mutex_init() wants.
v2:
- Revamp the commit message with clearer explanation of the issue.
- Rather export __drmm_mutex_release() than static inline.
Reported-by: Thomas Hellström
Reported-by: Sarah Walker
Fixes: e13f13e039dc ("drm: Add DRM-managed mutex_init()")
Cc: Stanislaw Gruszka
Cc: Boris Brezillon
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Matthew Auld
Reviewed-by: Boris Brezillon
Reviewed-by: Stanislaw Gruszka
Reviewed-by: Lucas De Marchi
Acked-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20230519090733.489019-1-matthew.a...@intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_managed.c | 22 ++
include/drm/drm_managed.h | 18 +-
2 files changed, 19 insertions(+), 21 deletions(-)
--- a/drivers/gpu/drm/drm_managed.c
+++ b/drivers/gpu/drm/drm_managed.c
@@ -264,28 +264,10 @@ void drmm_kfree(struct drm_device *dev,
}
EXPORT_SYMBOL(drmm_kfree);
-static void drmm_mutex_release(struct drm_device *dev, void *res)
+void __drmm_mutex_release(struct drm_device *dev, void *res)
{
struct mutex *lock = res;
mutex_destroy(lock);
}
-
-/**
- * drmm_mutex_init - &drm_device-managed mutex_init()
- * @dev: DRM device
- * @lock: lock to be initialized
- *
- * Returns:
- * 0 on success, or a negative errno code otherwise.
- *
- * This is a &drm_device-managed version of mutex_init(). The initialized
- * lock is automatically destroyed on the final drm_dev_put().
- */
-int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
-{
- mutex_init(lock);
-
- return drmm_add_action_or_reset(dev, drmm_mutex_release, lock);
-}
-EXPORT_SYMBOL(drmm_mutex_init);
+EXPORT_SYMBOL(__drmm_mutex_release);
--- a/include/drm/drm_managed.h
+++ b/include/drm/drm_managed.h
@@ -105,6 +105,22 @@ char *drmm_kstrdup(struct drm_device *de
void drmm_kfree(struct drm_device *dev, void *data);
-int drmm_mutex_init(struct drm_device *dev, struct mutex *lock);
+void __drmm_mutex_release(struct drm_device *dev, void *res);
+
+/**
+ * drmm_mutex_init - &drm_device-managed mutex_init()
+ * @dev: DRM device
+ * @lock: lock to be initialized
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ *
+ * This is a &drm_device-managed version of mutex_init(). The initialized
+ * lock is automatically destroyed on the final drm_dev_put().
+ */
+#define drmm_mutex_init(dev, lock) ({ \
+ mutex_init(lock);\
+ drmm_add_action_or_reset(dev, __drmm_mutex_release, lock); \
+}) \
#endif
[PATCH 6.3 069/127] drm: fix drmm_mutex_init()
From: Matthew Auld
commit c21f11d182c2180d8b90eaff84f574cfa845b250 upstream.
In mutex_init() lockdep identifies a lock by defining a special static
key for each lock class. However if we wrap the macro in a function,
like in drmm_mutex_init(), we end up generating:
int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
{
static struct lock_class_key __key;
__mutex_init((lock), "lock", &__key);
}
The static __key here is what lockdep uses to identify the lock class,
however since this is just a normal function the key here will be
created once, where all callers then use the same key. In effect the
mutex->depmap.key will be the same pointer for different
drmm_mutex_init() callers. This then results in impossible lockdep
splats since lockdep thinks completely unrelated locks are the same lock
class.
To fix this turn drmm_mutex_init() into a macro such that it generates a
different "static struct lock_class_key __key" for each invocation,
which looks to be inline with what mutex_init() wants.
v2:
- Revamp the commit message with clearer explanation of the issue.
- Rather export __drmm_mutex_release() than static inline.
Reported-by: Thomas Hellström
Reported-by: Sarah Walker
Fixes: e13f13e039dc ("drm: Add DRM-managed mutex_init()")
Cc: Stanislaw Gruszka
Cc: Boris Brezillon
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Matthew Auld
Reviewed-by: Boris Brezillon
Reviewed-by: Stanislaw Gruszka
Reviewed-by: Lucas De Marchi
Acked-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20230519090733.489019-1-matthew.a...@intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_managed.c | 22 ++
include/drm/drm_managed.h | 18 +-
2 files changed, 19 insertions(+), 21 deletions(-)
--- a/drivers/gpu/drm/drm_managed.c
+++ b/drivers/gpu/drm/drm_managed.c
@@ -264,28 +264,10 @@ void drmm_kfree(struct drm_device *dev,
}
EXPORT_SYMBOL(drmm_kfree);
-static void drmm_mutex_release(struct drm_device *dev, void *res)
+void __drmm_mutex_release(struct drm_device *dev, void *res)
{
struct mutex *lock = res;
mutex_destroy(lock);
}
-
-/**
- * drmm_mutex_init - &drm_device-managed mutex_init()
- * @dev: DRM device
- * @lock: lock to be initialized
- *
- * Returns:
- * 0 on success, or a negative errno code otherwise.
- *
- * This is a &drm_device-managed version of mutex_init(). The initialized
- * lock is automatically destroyed on the final drm_dev_put().
- */
-int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
-{
- mutex_init(lock);
-
- return drmm_add_action_or_reset(dev, drmm_mutex_release, lock);
-}
-EXPORT_SYMBOL(drmm_mutex_init);
+EXPORT_SYMBOL(__drmm_mutex_release);
--- a/include/drm/drm_managed.h
+++ b/include/drm/drm_managed.h
@@ -105,6 +105,22 @@ char *drmm_kstrdup(struct drm_device *de
void drmm_kfree(struct drm_device *dev, void *data);
-int drmm_mutex_init(struct drm_device *dev, struct mutex *lock);
+void __drmm_mutex_release(struct drm_device *dev, void *res);
+
+/**
+ * drmm_mutex_init - &drm_device-managed mutex_init()
+ * @dev: DRM device
+ * @lock: lock to be initialized
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ *
+ * This is a &drm_device-managed version of mutex_init(). The initialized
+ * lock is automatically destroyed on the final drm_dev_put().
+ */
+#define drmm_mutex_init(dev, lock) ({ \
+ mutex_init(lock);\
+ drmm_add_action_or_reset(dev, __drmm_mutex_release, lock); \
+}) \
#endif
Re: [PATCH V2] dt-bindings: bridge: samsung-dsim: Make some flags optional
On Sun, May 28, 2023 at 8:34 AM Jagan Teki wrote: > > On Sun, May 28, 2023 at 6:57 PM Adam Ford wrote: > > > > In the event a device is connected to the samsung-dsim > > controller that doesn't support the burst-clock, the > > driver is able to get the requested pixel clock from the > > attached device or bridge. In these instances, the > > samsung,burst-clock-frequency isn't needed, so remove > > it from the required list. > > > > The pll-clock frequency can be set by the device tree entry > > for samsung,pll-clock-frequency, but in some cases, the > > pll-clock may have the same clock rate as sclk_mipi clock. > > If they are equal, this flag is not needed since the driver > > will use the sclk_mipi rate as a fallback. > > > > Signed-off-by: Adam Ford > > Reviewed-by: Conor Dooley > > --- > > V2: Split from driver series. Re-word updates for burst > > and pll-clock frequency. > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > index 9f61ebdfefa8..06b6c44d4641 100644 > > --- > > a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > +++ > > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > @@ -70,7 +70,9 @@ properties: > >samsung,burst-clock-frequency: > > $ref: /schemas/types.yaml#/definitions/uint32 > > description: > > - DSIM high speed burst mode frequency. > > + DSIM high speed burst mode frequency. If absent, > > + the pixel clock from the attached device or bridge > > + will be used instead. > > > >samsung,esc-clock-frequency: > > $ref: /schemas/types.yaml#/definitions/uint32 > > @@ -80,7 +82,8 @@ properties: > >samsung,pll-clock-frequency: > > $ref: /schemas/types.yaml#/definitions/uint32 > > description: > > - DSIM oscillator clock frequency. > > + DSIM oscillator clock frequency. If absent, the clock frequency > > + of sclk_mipi will be used instead. > > Maybe this explicit comment won't require as it is not listed in "required" I mostly listed it here to explain why it's being removed from the required list and what happens if it's missing. > > Reviewed-by: Jagan Teki
Re: [PATCH v2 2/3] arm64: dts: qcom: sc8280xp: Add GPU related nodes
On Tue, May 23, 2023 at 09:59:53AM +0200, Konrad Dybcio wrote:
>
>
> On 23.05.2023 03:15, Bjorn Andersson wrote:
> > From: Bjorn Andersson
> >
> > Add Adreno SMMU, GPU clock controller, GMU and GPU nodes for the
> > SC8280XP.
> >
> > Signed-off-by: Bjorn Andersson
> > Signed-off-by: Bjorn Andersson
> > ---
> It does not look like you tested the DTS against bindings. Please run
> `make dtbs_check` (see
> Documentation/devicetree/bindings/writing-schema.rst for instructions).
>
> >
> > Changes since v1:
> > - Dropped gmu_pdc_seq region from &gmu, as it shouldn't have been used.
> > - Added missing compatible to &adreno_smmu.
> > - Dropped aoss_qmp clock in &gmu and &adreno_smmu.
> >
> > arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 169 +
> > 1 file changed, 169 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > index d2a2224d138a..329ec2119ecf 100644
> > --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > @@ -6,6 +6,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -2331,6 +2332,174 @@ tcsr: syscon@1fc {
> > reg = <0x0 0x01fc 0x0 0x3>;
> > };
> >
> > + gpu: gpu@3d0 {
> > + compatible = "qcom,adreno-690.0", "qcom,adreno";
> > +
> > + reg = <0 0x03d0 0 0x4>,
> > + <0 0x03d9e000 0 0x1000>,
> > + <0 0x03d61000 0 0x800>;
> > + reg-names = "kgsl_3d0_reg_memory",
> > + "cx_mem",
> > + "cx_dbgc";
> > + interrupts = ;
> > + iommus = <&adreno_smmu 0 0xc00>, <&adreno_smmu 1 0xc00>;
> > + operating-points-v2 = <&gpu_opp_table>;
> > +
> > + qcom,gmu = <&gmu>;
> > + interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt
> > SLAVE_EBI1 0>;
> > + interconnect-names = "gfx-mem";
> > + #cooling-cells = <2>;
> > +
> > + status = "disabled";
> > +
> > + gpu_opp_table: opp-table {
> > + compatible = "operating-points-v2";
> > +
> > + opp-27000 {
> > + opp-hz = /bits/ 64 <27000>;
> > + opp-level =
> > ;
> > + opp-peak-kBps = <451000>;
> > + };
> > +
> > + opp-41000 {
> > + opp-hz = /bits/ 64 <41000>;
> > + opp-level = ;
> > + opp-peak-kBps = <1555000>;
> > + };
> > +
> > + opp-5 {
> > + opp-hz = /bits/ 64 <5>;
> > + opp-level =
> > ;
> > + opp-peak-kBps = <1555000>;
> > + };
> > +
> > + opp-54700 {
> > + opp-hz = /bits/ 64 <54700>;
> > + opp-level =
> > ;
> > + opp-peak-kBps = <1555000>;
> > + };
> > +
> > + opp-60600 {
> > + opp-hz = /bits/ 64 <60600>;
> > + opp-level = ;
> > + opp-peak-kBps = <2736000>;
> > + };
> > +
> > + opp-64000 {
> > + opp-hz = /bits/ 64 <64000>;
> > + opp-level =
> > ;
> > + opp-peak-kBps = <2736000>;
> > + };
> > +
> > + opp-69000 {
> > + opp-hz = /bits/ 64 <69000>;
> > + opp-level =
> > ;
> > + opp-peak-kBps = <2736000>;
> > + };
> > + };
> > + };
> > +
> > + gmu: gmu@3d6a000 {
> > + compatible = "qcom,adreno-gmu-690.0", "qcom,adreno-gmu";
> > + reg = <0 0x03d6a000 0 0x34000>,
> > + <0 0x03de 0 0x1>,
> > + <0 0x0b29 0 0x1>;
> > + reg-names = "gmu", "rscc", "gmu_pdc";
> > + interrupts = ,
> > +;
> > + interrupt-names = "hfi", "gmu";
> > + clocks = <&gpucc GPU_CC_CX_GMU_CLK>,
> > +<&gpucc GPU_CC_CXO_CLK
Patch "drm: fix drmm_mutex_init()" has been added to the 6.3-stable tree
This is a note to let you know that I've just added the patch titled
drm: fix drmm_mutex_init()
to the 6.3-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fix-drmm_mutex_init.patch
and it can be found in the queue-6.3 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From c21f11d182c2180d8b90eaff84f574cfa845b250 Mon Sep 17 00:00:00 2001
From: Matthew Auld
Date: Fri, 19 May 2023 10:07:33 +0100
Subject: drm: fix drmm_mutex_init()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Matthew Auld
commit c21f11d182c2180d8b90eaff84f574cfa845b250 upstream.
In mutex_init() lockdep identifies a lock by defining a special static
key for each lock class. However if we wrap the macro in a function,
like in drmm_mutex_init(), we end up generating:
int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
{
static struct lock_class_key __key;
__mutex_init((lock), "lock", &__key);
}
The static __key here is what lockdep uses to identify the lock class,
however since this is just a normal function the key here will be
created once, where all callers then use the same key. In effect the
mutex->depmap.key will be the same pointer for different
drmm_mutex_init() callers. This then results in impossible lockdep
splats since lockdep thinks completely unrelated locks are the same lock
class.
To fix this turn drmm_mutex_init() into a macro such that it generates a
different "static struct lock_class_key __key" for each invocation,
which looks to be inline with what mutex_init() wants.
v2:
- Revamp the commit message with clearer explanation of the issue.
- Rather export __drmm_mutex_release() than static inline.
Reported-by: Thomas Hellström
Reported-by: Sarah Walker
Fixes: e13f13e039dc ("drm: Add DRM-managed mutex_init()")
Cc: Stanislaw Gruszka
Cc: Boris Brezillon
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Matthew Auld
Reviewed-by: Boris Brezillon
Reviewed-by: Stanislaw Gruszka
Reviewed-by: Lucas De Marchi
Acked-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20230519090733.489019-1-matthew.a...@intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_managed.c | 22 ++
include/drm/drm_managed.h | 18 +-
2 files changed, 19 insertions(+), 21 deletions(-)
--- a/drivers/gpu/drm/drm_managed.c
+++ b/drivers/gpu/drm/drm_managed.c
@@ -264,28 +264,10 @@ void drmm_kfree(struct drm_device *dev,
}
EXPORT_SYMBOL(drmm_kfree);
-static void drmm_mutex_release(struct drm_device *dev, void *res)
+void __drmm_mutex_release(struct drm_device *dev, void *res)
{
struct mutex *lock = res;
mutex_destroy(lock);
}
-
-/**
- * drmm_mutex_init - &drm_device-managed mutex_init()
- * @dev: DRM device
- * @lock: lock to be initialized
- *
- * Returns:
- * 0 on success, or a negative errno code otherwise.
- *
- * This is a &drm_device-managed version of mutex_init(). The initialized
- * lock is automatically destroyed on the final drm_dev_put().
- */
-int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
-{
- mutex_init(lock);
-
- return drmm_add_action_or_reset(dev, drmm_mutex_release, lock);
-}
-EXPORT_SYMBOL(drmm_mutex_init);
+EXPORT_SYMBOL(__drmm_mutex_release);
--- a/include/drm/drm_managed.h
+++ b/include/drm/drm_managed.h
@@ -105,6 +105,22 @@ char *drmm_kstrdup(struct drm_device *de
void drmm_kfree(struct drm_device *dev, void *data);
-int drmm_mutex_init(struct drm_device *dev, struct mutex *lock);
+void __drmm_mutex_release(struct drm_device *dev, void *res);
+
+/**
+ * drmm_mutex_init - &drm_device-managed mutex_init()
+ * @dev: DRM device
+ * @lock: lock to be initialized
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ *
+ * This is a &drm_device-managed version of mutex_init(). The initialized
+ * lock is automatically destroyed on the final drm_dev_put().
+ */
+#define drmm_mutex_init(dev, lock) ({ \
+ mutex_init(lock);\
+ drmm_add_action_or_reset(dev, __drmm_mutex_release, lock); \
+}) \
#endif
Patches currently in stable-queue which might be from matthew.a...@intel.com are
queue-6.3/drm-fix-drmm_mutex_init.patch
Patch "drm: fix drmm_mutex_init()" has been added to the 6.1-stable tree
This is a note to let you know that I've just added the patch titled
drm: fix drmm_mutex_init()
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fix-drmm_mutex_init.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From c21f11d182c2180d8b90eaff84f574cfa845b250 Mon Sep 17 00:00:00 2001
From: Matthew Auld
Date: Fri, 19 May 2023 10:07:33 +0100
Subject: drm: fix drmm_mutex_init()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Matthew Auld
commit c21f11d182c2180d8b90eaff84f574cfa845b250 upstream.
In mutex_init() lockdep identifies a lock by defining a special static
key for each lock class. However if we wrap the macro in a function,
like in drmm_mutex_init(), we end up generating:
int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
{
static struct lock_class_key __key;
__mutex_init((lock), "lock", &__key);
}
The static __key here is what lockdep uses to identify the lock class,
however since this is just a normal function the key here will be
created once, where all callers then use the same key. In effect the
mutex->depmap.key will be the same pointer for different
drmm_mutex_init() callers. This then results in impossible lockdep
splats since lockdep thinks completely unrelated locks are the same lock
class.
To fix this turn drmm_mutex_init() into a macro such that it generates a
different "static struct lock_class_key __key" for each invocation,
which looks to be inline with what mutex_init() wants.
v2:
- Revamp the commit message with clearer explanation of the issue.
- Rather export __drmm_mutex_release() than static inline.
Reported-by: Thomas Hellström
Reported-by: Sarah Walker
Fixes: e13f13e039dc ("drm: Add DRM-managed mutex_init()")
Cc: Stanislaw Gruszka
Cc: Boris Brezillon
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Matthew Auld
Reviewed-by: Boris Brezillon
Reviewed-by: Stanislaw Gruszka
Reviewed-by: Lucas De Marchi
Acked-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20230519090733.489019-1-matthew.a...@intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_managed.c | 22 ++
include/drm/drm_managed.h | 18 +-
2 files changed, 19 insertions(+), 21 deletions(-)
--- a/drivers/gpu/drm/drm_managed.c
+++ b/drivers/gpu/drm/drm_managed.c
@@ -264,28 +264,10 @@ void drmm_kfree(struct drm_device *dev,
}
EXPORT_SYMBOL(drmm_kfree);
-static void drmm_mutex_release(struct drm_device *dev, void *res)
+void __drmm_mutex_release(struct drm_device *dev, void *res)
{
struct mutex *lock = res;
mutex_destroy(lock);
}
-
-/**
- * drmm_mutex_init - &drm_device-managed mutex_init()
- * @dev: DRM device
- * @lock: lock to be initialized
- *
- * Returns:
- * 0 on success, or a negative errno code otherwise.
- *
- * This is a &drm_device-managed version of mutex_init(). The initialized
- * lock is automatically destroyed on the final drm_dev_put().
- */
-int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
-{
- mutex_init(lock);
-
- return drmm_add_action_or_reset(dev, drmm_mutex_release, lock);
-}
-EXPORT_SYMBOL(drmm_mutex_init);
+EXPORT_SYMBOL(__drmm_mutex_release);
--- a/include/drm/drm_managed.h
+++ b/include/drm/drm_managed.h
@@ -105,6 +105,22 @@ char *drmm_kstrdup(struct drm_device *de
void drmm_kfree(struct drm_device *dev, void *data);
-int drmm_mutex_init(struct drm_device *dev, struct mutex *lock);
+void __drmm_mutex_release(struct drm_device *dev, void *res);
+
+/**
+ * drmm_mutex_init - &drm_device-managed mutex_init()
+ * @dev: DRM device
+ * @lock: lock to be initialized
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ *
+ * This is a &drm_device-managed version of mutex_init(). The initialized
+ * lock is automatically destroyed on the final drm_dev_put().
+ */
+#define drmm_mutex_init(dev, lock) ({ \
+ mutex_init(lock);\
+ drmm_add_action_or_reset(dev, __drmm_mutex_release, lock); \
+}) \
#endif
Patches currently in stable-queue which might be from matthew.a...@intel.com are
queue-6.1/drm-fix-drmm_mutex_init.patch
[Bug 217499] NVIDIA drivers fail to install on 6.4.0-rc3-1-mainline kernel
https://bugzilla.kernel.org/show_bug.cgi?id=217499 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #1 from Artem S. Tashkinov (a...@gmx.com) --- Please report here https://github.com/NVIDIA/open-gpu-kernel-modules -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] drm: Remove unnecessary (void*) conversions
On 2023/5/26 15:27, Christian König wrote:
Am 26.05.23 um 05:32 schrieb Su Hui:
Pointer variables of (void*) type do not require type cast.
Please split that up by subsystem/driver. Taking it through the misc
tree might just cause merge conflicts.
Sorry for that, I will split it and send again.
Thanks for your reply!
Su Hui
Christian.
Signed-off-by: Su Hui
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +-
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
drivers/gpu/drm/omapdrm/omap_debugfs.c | 6 +++---
drivers/gpu/drm/pl111/pl111_debugfs.c | 2 +-
drivers/gpu/drm/qxl/qxl_debugfs.c | 4 ++--
drivers/gpu/drm/tiny/arcpgu.c | 2 +-
drivers/gpu/drm/ttm/ttm_resource.c | 3 +--
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 6 +++---
drivers/gpu/drm/vmwgfx/ttm_object.c | 5 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 2 +-
12 files changed, 19 insertions(+), 21 deletions(-)
diff --git
a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 827fcb4fb3b3..8a2c39927167 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -3312,7 +3312,7 @@ static ssize_t dtn_log_write(
static int mst_topo_show(struct seq_file *m, void *unused)
{
- struct amdgpu_device *adev = (struct amdgpu_device *)m->private;
+ struct amdgpu_device *adev = m->private;
struct drm_device *dev = adev_to_drm(adev);
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 58c2246918fd..e6c870bd307b 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -3671,7 +3671,7 @@ static void amdgpu_parse_cg_state(struct
seq_file *m, u64 flags)
static int amdgpu_debugfs_pm_info_show(struct seq_file *m, void
*unused)
{
- struct amdgpu_device *adev = (struct amdgpu_device *)m->private;
+ struct amdgpu_device *adev = m->private;
struct drm_device *dev = adev_to_drm(adev);
u64 flags = 0;
int r;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 31a7f59ccb49..dd57f7164e9a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -198,7 +198,7 @@ static int etnaviv_ring_show(struct etnaviv_gpu
*gpu, struct seq_file *m)
static int show_unlocked(struct seq_file *m, void *arg)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
int (*show)(struct drm_device *dev, struct seq_file *m) =
node->info_ent->data;
@@ -208,7 +208,7 @@ static int show_unlocked(struct seq_file *m, void
*arg)
static int show_each_gpu(struct seq_file *m, void *arg)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct etnaviv_drm_private *priv = dev->dev_private;
struct etnaviv_gpu *gpu;
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 2a36d1ca8fda..96b59d5d68ed 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -37,7 +37,7 @@
static int
nouveau_debugfs_vbios_image(struct seq_file *m, void *data)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
struct nouveau_drm *drm = nouveau_drm(node->minor->dev);
int i;
diff --git a/drivers/gpu/drm/omapdrm/omap_debugfs.c
b/drivers/gpu/drm/omapdrm/omap_debugfs.c
index a3d470468e5b..a94ce502e152 100644
--- a/drivers/gpu/drm/omapdrm/omap_debugfs.c
+++ b/drivers/gpu/drm/omapdrm/omap_debugfs.c
@@ -19,7 +19,7 @@
static int gem_show(struct seq_file *m, void *arg)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct omap_drm_private *priv = dev->dev_private;
@@ -33,7 +33,7 @@ static int gem_show(struct seq_file *m, void *arg)
static int mm_show(struct seq_file *m, void *arg)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct drm_printer p = drm_seq_file_printer(m);
@@ -45,7 +45,7 @@ static int mm_show(struc
Re: [Nouveau] [PATCH v2] drm/nouveau: bring back blit subchannel for pre nv50 GPUs
On Fri, May 26, 2023 at 5:11 AM Karol Herbst wrote:
>
> 1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128
> was important as otherwise the GPU spams us with `CACHE_ERROR` messages.
>
> We use the blit subchannel inside our vblank handling, so we should keep
> at least this part.
>
> v2: Only do it for NV11+ GPUs
>
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201
> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/nouveau_chan.c | 1 +
> drivers/gpu/drm/nouveau/nouveau_chan.h | 1 +
> drivers/gpu/drm/nouveau/nouveau_drm.c | 20 +---
> 3 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
> b/drivers/gpu/drm/nouveau/nouveau_chan.c
> index e648ecd0c1a0..3dfbc374478e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_chan.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
> @@ -90,6 +90,7 @@ nouveau_channel_del(struct nouveau_channel **pchan)
> if (cli)
> nouveau_svmm_part(chan->vmm->svmm, chan->inst);
>
> + nvif_object_dtor(&chan->blit);
> nvif_object_dtor(&chan->nvsw);
> nvif_object_dtor(&chan->gart);
> nvif_object_dtor(&chan->vram);
> diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h
> b/drivers/gpu/drm/nouveau/nouveau_chan.h
> index e06a8ffed31a..bad7466bd0d5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_chan.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
> @@ -53,6 +53,7 @@ struct nouveau_channel {
> u32 user_put;
>
> struct nvif_object user;
> + struct nvif_object blit;
>
> struct nvif_event kill;
> atomic_t killed;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index cc7c5b4a05fd..9512f1c2f871 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -369,15 +369,29 @@ nouveau_accel_gr_init(struct nouveau_drm *drm)
> ret = nvif_object_ctor(&drm->channel->user, "drmNvsw",
>NVDRM_NVSW, nouveau_abi16_swclass(drm),
>NULL, 0, &drm->channel->nvsw);
> +
> + if (ret == 0 && device->info.chipset >= 0x11) {
Can you double-check that this is needed on NV15? IIRC there's some
non-linearity of chipsets here which is why we had (some long time
ago, not sure if it's still there), a chip class which would simplify
such checks.
Cheers,
-ilia
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
在 2023-05-26星期五的 07:24 -0700，Doug Anderson写道：
> Hi,
>
> On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng wrote:
> >
> > Currently a specific panel number is used in the Elm DTSI, which is
> > corresponded to a 12" panel. However, according to the official
> > Chrome
> > OS devices document, Elm refers to Acer Chromebook R13, which, as
> > the
> > name specifies, uses a 13.3" panel, which comes with EDID
> > information.
> >
> > As the kernel currently prioritizes the hardcoded timing parameters
> > matched with the panel number compatible, a wrong timing will be
> > applied
> > to the 13.3" panel on Acer Chromebook R13, which leads to blank
> > display.
> >
> > Because the Elm DTSI is shared with Hana board, and Hana
> > corresponds to
> > multiple devices from 11" to 14", a certain panel model number
> > shouldn't
> > be present, and driving the panel according to its EDID information
> > is
> > necessary.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> We went through a bunch of back-and-forth here but in the end in the
> ChromeOS tree we have "edp-panel" as the "compatible" here in the
> ChromeOS 5.15 tree and this makes sense.
I only have Elm, so I am curious that do all Hana's only rely on panel
EDID to use different displays?
BTW The Chrome OS document say that Elm and Hana are both board based
on Oak baseboard, should the DTSI be renamed mt8173-oak.dtsi, and still
let mt8173-elm.dts include it and then set model information?
>
> Reviewed-by: Douglas Anderson
>
> ...in theory one would wish for a "Fixes" tag, but I think in
> previous
> discussions it was decided that it was too complicated. Hardcoding
> the
> other compatible string has always been technically wrong, but I
> guess
> it worked at some point in time. The more correct way (as you're
> doing
> here) needs the DP AUX bus support and the generic eDP panels, both
> of
> which are significantly newer than the elm dts. So I guess leaving no
> "Fixes" tag is OK, or perhaps you could do the somewhat weak:
Well I remembered when I was developing the support for Pine64
Pinebook, which is also an ARM64 laptop with an eDP panel (via a DPI-
eDP bridge, ANX6345). At first I didn't use any panel node in the DT,
and the kernel maintainers argued to the bridge that seems to be
connected to nothing (because DP is a discoverable port), and
fortunately 2 Pinebook SKUs (11.6" and 14") is finally reduced to one,
and it's then possible to hardcode a panel model in the Pinebook DT.
According to my memory, the need to specify the panel is to properly
handle eDP panel power up timing, because it's not a very standard
thing. (Well, in my memory, when I was testing that code, on a
(engineering sample) 14" Pinebook, the EDID timing overrided the
hardcoded 11.6" timing and it properly works, the 14" panel is 1366x768
but the 11.6" panel is 1920x1080.)
(BTW when I checked the DT of Olimex TERES-I, which uses the same DPI-
eDP bridge, it is still in the status of a dangling bridge, and of
course it works ;-) )
>
> Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move display
> to ps8640 auxiliary bus")
Well this sound quite reasonable, as the kernel should have proper AUX
support at this commit.
[PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
Currently a specific panel number is used in the Elm DTSI, which is
corresponded to a 12" panel. However, according to the official Chrome
OS devices document, Elm refers to Acer Chromebook R13, which, as the
name specifies, uses a 13.3" panel, which comes with EDID information.
As the kernel currently prioritizes the hardcoded timing parameters
matched with the panel number compatible, a wrong timing will be applied
to the 13.3" panel on Acer Chromebook R13, which leads to blank display.
Because the Elm DTSI is shared with Hana board, and Hana corresponds to
multiple devices from 11" to 14", a certain panel model number shouldn't
be present, and driving the panel according to its EDID information is
necessary.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index d452cab28c67..737737528eed 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -285,7 +285,7 @@ ps8640_out: endpoint {
aux-bus {
panel: panel {
- compatible = "lg,lp120up1";
+ compatible = "edp-panel";
power-supply = <&panel_fixed_3v3>;
backlight = <&backlight>;
--
2.39.1
[PATCH] drm/radeon: fix race condition UAF in radeon_gem_set_domain_ioctl
Userspace can race to free the gobj(robj converted from), robj should not be accessed again after drm_gem_object_put, otherwith it will result in use-after-free. Signed-off-by: Min Li --- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index bdc5af23f005..450c7cbdd28a 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -478,7 +478,7 @@ int radeon_gem_set_domain_ioctl(struct drm_device *dev, void *data, drm_gem_object_put(gobj); up_read(&rdev->exclusive_lock); - r = radeon_gem_handle_lockup(robj->rdev, r); + r = radeon_gem_handle_lockup(rdev, r); return r; } -- 2.34.1
[PATCH] drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl
If it is async, runqueue_node is freed in g2d_runqueue_worker on another worker thread. So in extreme cases, if g2d_runqueue_worker runs first, and then executes the following if statement, there will be use-after-free. Signed-off-by: Min Li --- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c index ec784e58da5c..414e585ec7dd 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c @@ -1335,7 +1335,7 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev, void *data, /* Let the runqueue know that there is work to do. */ queue_work(g2d->g2d_workq, &g2d->runqueue_work); - if (runqueue_node->async) + if (req->async) goto out; wait_for_completion(&runqueue_node->complete); -- 2.34.1
[Bug 217499] NVIDIA drivers fail to install on 6.4.0-rc3-1-mainline kernel
https://bugzilla.kernel.org/show_bug.cgi?id=217499 Wessel (wessel.working+ker...@gmail.com) changed: What|Removed |Added Kernel Version||6.4.0-rc3-1-mainline -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 217499] NVIDIA drivers fail to install on 6.4.0-rc3-1-mainline kernel
https://bugzilla.kernel.org/show_bug.cgi?id=217499 Wessel (wessel.working+ker...@gmail.com) changed: What|Removed |Added URL||https://forum.garudalinux.o ||rg/t/nvidia-drivers-fail-to ||-install-on-6-4-0-rc3-1-mai ||nline-kernel/28769 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 217499] New: NVIDIA drivers fail to install on 6.4.0-rc3-1-mainline kernel
https://bugzilla.kernel.org/show_bug.cgi?id=217499 Bug ID: 217499 Summary: NVIDIA drivers fail to install on 6.4.0-rc3-1-mainline kernel Product: Drivers Version: 2.5 Hardware: Intel OS: Linux Status: NEW Severity: normal Priority: P3 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: wessel.working+ker...@gmail.com Regression: No Created attachment 304341 --> https://bugzilla.kernel.org/attachment.cgi?id=304341&action=edit /var/lib/dkms/nvidia/530.41.03/build/make.log Unsure if this is the right place to post or If I have to post somewhere NVIDIA. If so please direct me to the appropriate place to raise this. I am unsure if this is a priority in this point of the mainline release but I had issues with installing the `nvidia/530.41.03` drivers on `6.4.0-rc3-1-mainline` release. Driver installs correctly on LTS and Stable as well as cachyos BORE. I posted on my distribution's help [forums](https://forum.garudalinux.org/t/nvidia-drivers-fail-to-install-on-6-4-0-rc3-1-mainline-kernel/28769) and they directed me to the kernel maintainers. This is what happens if I try to install the drivers on mainline. ``` > sudo dkms install nvidia/530.41.03 -k 6.4.0-rc3-1-mainline > Sign command: /usr/lib/modules/6.4.0-rc3-1-mainline/build/scripts/sign-file > Signing key: /var/lib/dkms/mok.key > Public certificate (MOK): /var/lib/dkms/mok.pub > > Building module: > Cleaning build area... > 'make' -j4 IGNORE_PREEMPT_RT_PRESENCE=1 > NV_EXCLUDE_BUILD_MODULES='__EXCLUDE_MODULES' > KERNEL_UNAME=6.4.0-rc3-1-mainline modules...(bad exit > status: 2) > Error! Bad return status for module build on kernel: 6.4.0-rc3-1-mainline > (x86_64) > Consult /var/lib/dkms/nvidia/530.41.03/build/make.log for more information. ``` Please find attached the `make.log` -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/3] dw-hdmi: truly enforce 420-only formats when drm mode demands it
The current output bus format selection logic is enforcing YUV420 even
when the drm mode allows for other bus formats as well.
Fix it by adding check for 420-only drm modes.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index d59a547f9cb2..1afb8f2603a0 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2710,9 +2710,10 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
/* Default 8bit fallback */
output_fmts[i++] = MEDIA_BUS_FMT_UYYVYY8_0_5X24;
- *num_output_fmts = i;
-
- return output_fmts;
+ if (drm_mode_is_420_only(info, mode)) {
+ *num_output_fmts = i;
+ return output_fmts;
+ }
}
/*
--
2.40.0
[PATCH 3/3] dw-hdmi: remove dead code and fix indentation
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 1afb8f2603a0..0accfb51509c 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -49,20 +49,6 @@
#define HDMI14_MAX_TMDSCLK 34000
-enum hdmi_datamap {
- RGB444_8B = 0x01,
- RGB444_10B = 0x03,
- RGB444_12B = 0x05,
- RGB444_16B = 0x07,
- YCbCr444_8B = 0x09,
- YCbCr444_10B = 0x0B,
- YCbCr444_12B = 0x0D,
- YCbCr444_16B = 0x0F,
- YCbCr422_8B = 0x16,
- YCbCr422_10B = 0x14,
- YCbCr422_12B = 0x12,
-};
-
static const u16 csc_coeff_default[3][4] = {
{ 0x2000, 0x, 0x, 0x },
{ 0x, 0x2000, 0x, 0x },
@@ -856,10 +842,10 @@ static void dw_hdmi_gp_audio_enable(struct dw_hdmi *hdmi)
if (pdata->enable_audio)
pdata->enable_audio(hdmi,
- hdmi->channels,
- hdmi->sample_width,
- hdmi->sample_rate,
- hdmi->sample_non_pcm);
+ hdmi->channels,
+ hdmi->sample_width,
+ hdmi->sample_rate,
+ hdmi->sample_non_pcm);
}
static void dw_hdmi_gp_audio_disable(struct dw_hdmi *hdmi)
--
2.40.0
[PATCH 1/3] drm/meson: dw-hdmi: change YUV420 selection logic at clock setup
Right now clocking value selection code is prioritising RGB, YUV444 modes
over YUV420 for HDMI2 sinks. However, because of the bus format selection
procedure in dw-hdmi, for HDMI2 sinks YUV420 is the format that will always
be picked during the drm bridge chain check stage.
Later on dw_hdmi_setup will configure a colour space based on the bus
format that doesn't match the pixel value we had calculated as described
above.
Fix it by bringing back dw-hdmi bus format check when picking the right
pixel clock.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 ++
drivers/gpu/drm/meson/meson_dw_hdmi.c | 4 ++--
include/drm/bridge/dw_hdmi.h | 2 ++
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 603bb3c51027..d59a547f9cb2 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3346,6 +3346,12 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
return 0;
}
+bool dw_hdmi_bus_fmt_is_420(struct dw_hdmi *hdmi)
+{
+ return hdmi_bus_fmt_is_yuv420(hdmi->hdmi_data.enc_out_bus_format);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_bus_fmt_is_420);
+
struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
{
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 3d046878ce6c..b49bb0d86efe 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -379,8 +379,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
mode->clock > 34 ? 40 : 10);
if (drm_mode_is_420_only(display, mode) ||
- (!is_hdmi2_sink &&
-drm_mode_is_420_also(display, mode)))
+ (!is_hdmi2_sink && drm_mode_is_420_also(display, mode)) ||
+ dw_hdmi_bus_fmt_is_420(hdmi))
mode_is_420 = true;
/* Enable clocks */
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index f668e75fbabe..6a46baa0737c 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -206,4 +206,6 @@ void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void
*data,
bool force, bool disabled, bool rxsense);
void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+bool dw_hdmi_bus_fmt_is_420(struct dw_hdmi *hdmi);
+
#endif /* __IMX_HDMI_H__ */
--
2.40.0
[PATCH 0/3] Add additional YUV420 bus format check for dw-meson's bridge enable
This is a belated follow-up on
https://lore.kernel.org/dri-devel/20220515204412.2733803-1-adrian.laru...@collabora.com/
Commit e67f6037ae1be34b2b68 ("drm/meson: split out encoder from meson_dw_hdmi")
broke 4K display modes for me, and I discovered it was because the right pixel
clock wasn't being chosen in dw_hdmi_phy_init. I misinterpreted the reason as a
problem in figuring out whether we want to enforce YUV420 mode, but it turned
out to be a mismatch between what dw-meson code is doing and the way the bus
format is being picked by the dw-hdmi bus output format drm helper.
I fixed it by bringing back dw-hdmi bus format check in dw-meson.
The second patch makes sure YUV420 bus format is the only one being returned by
dw-hdmi's output format bridge function when that's the only drm mode allowed.
Adrián Larumbe (3):
drm/meson: dw-hdmi: change YUV420 selection logic at clock setup
dw-hdmi: truly enforce 420-only formats when drm mode demands it
dw-hdmi: remove dead code and fix indentation
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 35 +--
drivers/gpu/drm/meson/meson_dw_hdmi.c | 4 +--
include/drm/bridge/dw_hdmi.h | 2 ++
3 files changed, 18 insertions(+), 23 deletions(-)
--
2.40.0
Re: [PATCH V2] dt-bindings: bridge: samsung-dsim: Make some flags optional
On Sun, May 28, 2023 at 6:57 PM Adam Ford wrote: > > In the event a device is connected to the samsung-dsim > controller that doesn't support the burst-clock, the > driver is able to get the requested pixel clock from the > attached device or bridge. In these instances, the > samsung,burst-clock-frequency isn't needed, so remove > it from the required list. > > The pll-clock frequency can be set by the device tree entry > for samsung,pll-clock-frequency, but in some cases, the > pll-clock may have the same clock rate as sclk_mipi clock. > If they are equal, this flag is not needed since the driver > will use the sclk_mipi rate as a fallback. > > Signed-off-by: Adam Ford > Reviewed-by: Conor Dooley > --- > V2: Split from driver series. Re-word updates for burst > and pll-clock frequency. > > diff --git > a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > index 9f61ebdfefa8..06b6c44d4641 100644 > --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > @@ -70,7 +70,9 @@ properties: >samsung,burst-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > - DSIM high speed burst mode frequency. > + DSIM high speed burst mode frequency. If absent, > + the pixel clock from the attached device or bridge > + will be used instead. > >samsung,esc-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > @@ -80,7 +82,8 @@ properties: >samsung,pll-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > - DSIM oscillator clock frequency. > + DSIM oscillator clock frequency. If absent, the clock frequency > + of sclk_mipi will be used instead. Maybe this explicit comment won't require as it is not listed in "required" Reviewed-by: Jagan Teki
[PATCH V2] dt-bindings: bridge: samsung-dsim: Make some flags optional
In the event a device is connected to the samsung-dsim controller that doesn't support the burst-clock, the driver is able to get the requested pixel clock from the attached device or bridge. In these instances, the samsung,burst-clock-frequency isn't needed, so remove it from the required list. The pll-clock frequency can be set by the device tree entry for samsung,pll-clock-frequency, but in some cases, the pll-clock may have the same clock rate as sclk_mipi clock. If they are equal, this flag is not needed since the driver will use the sclk_mipi rate as a fallback. Signed-off-by: Adam Ford Reviewed-by: Conor Dooley --- V2: Split from driver series. Re-word updates for burst and pll-clock frequency. diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml index 9f61ebdfefa8..06b6c44d4641 100644 --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -70,7 +70,9 @@ properties: samsung,burst-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 description: - DSIM high speed burst mode frequency. + DSIM high speed burst mode frequency. If absent, + the pixel clock from the attached device or bridge + will be used instead. samsung,esc-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 @@ -80,7 +82,8 @@ properties: samsung,pll-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 description: - DSIM oscillator clock frequency. + DSIM oscillator clock frequency. If absent, the clock frequency + of sclk_mipi will be used instead. phys: maxItems: 1 @@ -134,9 +137,7 @@ required: - compatible - interrupts - reg - - samsung,burst-clock-frequency - samsung,esc-clock-frequency - - samsung,pll-clock-frequency allOf: - $ref: ../dsi-controller.yaml# -- 2.39.2
[PATCH 2/3] accel/habanalabs: add event queue extra validation
From: Ofir Bitton
In order to increase reliability of the event queue interface,
we apply to Gaudi2 the same mechanism we have in Gaudi1.
The extra validation is basically checking that the received
event index matches the expected index.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/irq.c| 2 +-
drivers/accel/habanalabs/gaudi2/gaudi2.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/accel/habanalabs/common/irq.c
b/drivers/accel/habanalabs/common/irq.c
index c67895b1cdeb..b1010d206c2e 100644
--- a/drivers/accel/habanalabs/common/irq.c
+++ b/drivers/accel/habanalabs/common/irq.c
@@ -430,7 +430,7 @@ irqreturn_t hl_irq_handler_eq(int irq, void *arg)
cur_eqe_index = FIELD_GET(EQ_CTL_INDEX_MASK, cur_eqe);
if ((hdev->event_queue.check_eqe_index) &&
(((eq->prev_eqe_index + 1) & EQ_CTL_INDEX_MASK)
!= cur_eqe_index)) {
- dev_dbg(hdev->dev,
+ dev_err(hdev->dev,
"EQE %#x in queue is ready but index does not
match %d!=%d",
cur_eqe,
((eq->prev_eqe_index + 1) & EQ_CTL_INDEX_MASK),
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index 0d41adf4792c..20c4583f12b0 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -3619,6 +3619,12 @@ static int gaudi2_sw_init(struct hl_device *hdev)
prop->supports_compute_reset = true;
+ /* Event queue sanity check added in FW version 1.11 */
+ if (hl_is_fw_sw_ver_below(hdev, 1, 11))
+ hdev->event_queue.check_eqe_index = false;
+ else
+ hdev->event_queue.check_eqe_index = true;
+
hdev->asic_funcs->set_pci_memory_regions(hdev);
rc = gaudi2_special_blocks_iterator_config(hdev);
--
2.40.1
[PATCH 3/3] accel/habanalabs: refactor error info reset
From: Dani Liberman
Moved error info reset code to single function for future use from
other places in the driver.
Signed-off-by: Dani Liberman
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 8
drivers/accel/habanalabs/common/habanalabs.h | 1 +
drivers/accel/habanalabs/common/habanalabs_drv.c | 5 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index ea02f2cfdf81..b97339d1f7c6 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -2689,3 +2689,11 @@ void hl_handle_fw_err(struct hl_device *hdev, struct
hl_info_fw_err_info *info)
if (info->event_mask)
*info->event_mask |= HL_NOTIFIER_EVENT_CRITICL_FW_ERR;
}
+
+void hl_enable_err_info_capture(struct hl_error_info *captured_err_info)
+{
+ vfree(captured_err_info->page_fault_info.user_mappings);
+ memset(captured_err_info, 0, sizeof(struct hl_error_info));
+ atomic_set(&captured_err_info->cs_timeout.write_enable, 1);
+ captured_err_info->undef_opcode.write_enable = true;
+}
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index c5aa33eaa826..d92ba2e30e31 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -3944,6 +3944,7 @@ void hl_handle_page_fault(struct hl_device *hdev, u64
addr, u16 eng_id, bool is_
u64 *event_mask);
void hl_handle_critical_hw_err(struct hl_device *hdev, u16 event_id, u64
*event_mask);
void hl_handle_fw_err(struct hl_device *hdev, struct hl_info_fw_err_info
*info);
+void hl_enable_err_info_capture(struct hl_error_info *captured_err_info);
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/accel/habanalabs/common/habanalabs_drv.c
b/drivers/accel/habanalabs/common/habanalabs_drv.c
index 446f444a1c7e..7263e84c1a4d 100644
--- a/drivers/accel/habanalabs/common/habanalabs_drv.c
+++ b/drivers/accel/habanalabs/common/habanalabs_drv.c
@@ -219,10 +219,7 @@ int hl_device_open(struct inode *inode, struct file *filp)
hl_debugfs_add_file(hpriv);
- vfree(hdev->captured_err_info.page_fault_info.user_mappings);
- memset(&hdev->captured_err_info, 0, sizeof(hdev->captured_err_info));
- atomic_set(&hdev->captured_err_info.cs_timeout.write_enable, 1);
- hdev->captured_err_info.undef_opcode.write_enable = true;
+ hl_enable_err_info_capture(&hdev->captured_err_info);
hdev->open_counter++;
hdev->last_successful_open_jif = jiffies;
--
2.40.1
[PATCH 1/3] accel/habanalabs: unsecure TSB_CFG_MTRR regs
From: Ofir Bitton
In order to utilize Engine Barrier padding, user must have access to
this register set.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2_security.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2_security.c
b/drivers/accel/habanalabs/gaudi2/gaudi2_security.c
index fadb870ff4c0..2742b1f801eb 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2_security.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2_security.c
@@ -1534,6 +1534,10 @@ static const u32 gaudi2_pb_dcr0_tpc0_unsecured_regs[] = {
mmDCORE0_TPC0_CFG_QM_KERNEL_CONFIG,
mmDCORE0_TPC0_CFG_QM_KERNEL_ID,
mmDCORE0_TPC0_CFG_QM_POWER_LOOP,
+ mmDCORE0_TPC0_CFG_TSB_CFG_MTRR_2_0,
+ mmDCORE0_TPC0_CFG_TSB_CFG_MTRR_2_1,
+ mmDCORE0_TPC0_CFG_TSB_CFG_MTRR_2_2,
+ mmDCORE0_TPC0_CFG_TSB_CFG_MTRR_2_3,
mmDCORE0_TPC0_CFG_LUT_FUNC32_BASE2_ADDR_LO,
mmDCORE0_TPC0_CFG_LUT_FUNC32_BASE2_ADDR_HI,
mmDCORE0_TPC0_CFG_LUT_FUNC64_BASE2_ADDR_LO,
--
2.40.1
