[PATCH v2 2/4] drm/vc4: hdmi: Add pixel bvb clock control
There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 95ec5eedea39..eb3192d1fd86 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -80,6 +80,7 @@
# define VC4_HD_M_ENABLE BIT(0)
#define CEC_CLOCK_FREQ 4
+#define VC4_HSM_MID_CLOCK 149985000
static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
{
@@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
drm_encoder *encoder)
HDMI_WRITE(HDMI_VID_CTL,
HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
+ clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
clk_disable_unprepare(vc4_hdmi->hsm_clock);
clk_disable_unprepare(vc4_hdmi->pixel_clock);
@@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder)
return;
}
+ ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
+ (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
+ if (ret) {
+ DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
+ clk_disable_unprepare(vc4_hdmi->hsm_clock);
+ clk_disable_unprepare(vc4_hdmi->pixel_clock);
+ return;
+ }
+
+ ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
+ if (ret) {
+ DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
+ clk_disable_unprepare(vc4_hdmi->hsm_clock);
+ clk_disable_unprepare(vc4_hdmi->pixel_clock);
+ return;
+ }
+
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
@@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
return PTR_ERR(vc4_hdmi->audio_clock);
}
+ vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
+ if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
+ DRM_ERROR("Failed to get pixel bvb clock\n");
+ return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+ }
+
vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(vc4_hdmi->reset)) {
DRM_ERROR("Failed to get HDMI reset line\n");
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0806c6d9f24e..63c6f8bddf1d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -147,6 +147,7 @@ struct vc4_hdmi {
struct clk *pixel_clock;
struct clk *hsm_clock;
struct clk *audio_clock;
+ struct clk *pixel_bvb_clock;
struct reset_control *reset;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] dt-bindings: display: vc4: hdmi: Add bvb clock-names property
When using a resolution exceeding FHD, bvb clock is required. Add bvb clock-names property. Signed-off-by: Hoegeun Kwon --- .../bindings/display/brcm,bcm2711-hdmi.yaml | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml index 6091fe3d315b..08cdcc579cf5 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml @@ -40,10 +40,14 @@ properties: - const: hd clocks: -description: The HDMI state machine clock +items: + - description: The HDMI state machine clock + - description: The bvb clock clock-names: -const: hdmi +items: + - const: hdmi + - const: bvb ddc: allOf: @@ -100,8 +104,8 @@ examples: "csc", "cec", "hd"; -clocks = <_clocks 13>; -clock-names = "hdmi"; +clocks = <_clocks 13>, <_clocks 14>; +clock-names = "hdmi", "bvb"; resets = < 0>; ddc = <>; }; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] drm/vc4: Support HDMI QHD or higher output
Hi everyone, There is a problem that the output does not work at a resolution exceeding FHD. To solve this, we need to adjust the bvb clock at a resolution exceeding FHD. Rebased on top of next-20200708 and [1]. [1] : [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline (Maxime's patchset) Changes from v1: - Added dt-bindings documents - Change patch order, first fix driver and then device tree Hoegeun Kwon (4): clk: bcm: rpi: Add register to control pixel bvb clk drm/vc4: hdmi: Add pixel bvb clock control dt-bindings: display: vc4: hdmi: Add bvb clock-names property ARM: dts: bcm2711: Add bvb clock for hdmi-pixel .../bindings/display/brcm,bcm2711-hdmi.yaml | 12 ++--- arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 +++-- drivers/clk/bcm/clk-raspberrypi.c | 1 + drivers/gpu/drm/vc4/vc4_hdmi.c| 25 +++ drivers/gpu/drm/vc4/vc4_hdmi.h| 1 + 5 files changed, 39 insertions(+), 6 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] clk: bcm: rpi: Add register to control pixel bvb clk
To use QHD or higher, we need to modify the pixel_bvb_clk value. So add register to control this clock. Signed-off-by: Hoegeun Kwon --- drivers/clk/bcm/clk-raspberrypi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c index 5cc82954e1ce..f89b9cfc4309 100644 --- a/drivers/clk/bcm/clk-raspberrypi.c +++ b/drivers/clk/bcm/clk-raspberrypi.c @@ -271,6 +271,7 @@ static int raspberrypi_discover_clocks(struct raspberrypi_clk *rpi, case RPI_FIRMWARE_CORE_CLK_ID: case RPI_FIRMWARE_M2MC_CLK_ID: case RPI_FIRMWARE_V3D_CLK_ID: + case RPI_FIRMWARE_PIXEL_BVB_CLK_ID: hw = raspberrypi_clk_register(rpi, clks->parent, clks->id); if (IS_ERR(hw)) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] ARM: dts: bcm2711: Add bvb clock for hdmi-pixel
It is necessary to control the hdmi pixel bvb clock. Add bvb clock.
Signed-off-by: Hoegeun Kwon
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index b93eb30e1ddb..90dee4cb38bc 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -172,12 +172,14 @@
};
{
- clocks = <_clocks 13>, < 0>;
+ clocks = <_clocks 13>, < 0>, <_clocks 14>;
+ clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
};
{
- clocks = <_clocks 13>, < 1>;
+ clocks = <_clocks 13>, < 1>, <_clocks 14>;
+ clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/19] drm/msm: remove dangling submitqueue references
On Mon, Aug 31, 2020 at 7:35 PM Bjorn Andersson
wrote:
>
> On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
>
> > From: Rob Clark
> >
> > Currently it doesn't matter, since we free the ctx immediately. But
> > when we start refcnt'ing the ctx, we don't want old dangling list
> > entries to hang around.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> > b/drivers/gpu/drm/msm/msm_submitqueue.c
> > index a1d94be7883a..90c9d84e6155 100644
> > --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> > +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> > @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private *ctx)
> >* No lock needed in close and there won't
> >* be any more user ioctls coming our way
> >*/
> > - list_for_each_entry_safe(entry, tmp, >submitqueues, node)
> > + list_for_each_entry_safe(entry, tmp, >submitqueues, node) {
> > + list_del(>node);
>
> If you refcount ctx, what does that do for the entries in the submit
> queue?
>
> "entry" here is kref'ed, but you're popping it off the list regardless
> of the put ends up freeing the object or not - which afaict would mean
> leaking the object.
>
What ends up happening is the submit has reference to submit-queue,
which has reference to the ctx.. the submitqueue could be alive still
pending in-flight submits (in a later patch), but dead from the PoV of
userspace interface.
We aren't relying (or at least aren't in the end, and I *think* I
didn't miss anything in the middle) relying on ctx->submitqueues list
to clean anything up in the end, just track what is still a valid
submitqueue from userspace PoV
BR,
-R
>
> On the other hand, with the current implementation an object with higher
> refcount with adjacent objects of single refcount would end up with
> dangling pointers after the put. So in itself this change seems like a
> net gain, but I'm wondering about the plan described in the commit
> message.
>
> Regards,
> Bjorn
>
> > msm_submitqueue_put(entry);
> > + }
> > }
> >
> > int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private
> > *ctx,
> > --
> > 2.26.2
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Thank you reviews by Dave, Maxime and Stefan.
On 8/29/20 12:37 AM, Dave Stevenson wrote:
> Hi Maxime, Stefan, and Hoegeun
>
> On Fri, 28 Aug 2020 at 16:25, Maxime Ripard wrote:
>> Hi,
>>
>> On Fri, Aug 28, 2020 at 02:45:49PM +0200, Stefan Wahren wrote:
>>> Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
On 8/27/20 6:49 PM, Stefan Wahren wrote:
> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
>> Hi Stefan,
>>
>> Thank you for your review.
>>
>>
>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>>> Hi Hoeguen,
>>>
>>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.
>>> this patch introduces a mandatory clock, please update
>>> brcm,bcm2835-hdmi.yaml first.
>>>
>>> Is this clock physically available on BCM283x or only on BCM2711?
>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>>
>> don't supported on pi 3 and pi 3+.
>>
>> Since 4k is not supported in versions prior to Raspberry Pi 4,
>>
>> I don't think we need to modify the bvb clock.
>>
>>
>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>>
>> instead of 'brcm,bcm2835-hdmi.yaml'.
> You are correct please update only brcm,bcm2711-hdmi.yaml.
>
> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
> DTB. So making the BVB clock optional might be better?
You are right, if use old dtb, we have a problem with the hdmi driver.
So how about modifying it like this?
@@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
- DRM_ERROR("Failed to get pixel bvb clock\n");
- return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+ DRM_WARN("Failed to get pixel bvb clock\n");
+ vc4_hdmi->pixel_bvb_clock = NULL;
}
>>> i think the better solution would be devm_clk_get_optional(), which
>>> return NULL in case the clock doesn't exist.
>> It's not really optional though. BCM2711 will require it in order to run
>> properly (as Hoegeun experienced), and the previous SoCs won't.
>>
>> If we use clk_get_optional and that the DT is missing the clock on the
>> BCM2711, we will silently ignore it which doesn't sound great.
> Am I missing something here? (I know I missed this earlier)
> We're in vc5_hdmi_init_resources, which is inherently bcm2711 only.
> bcm283x will go through vc4_hdmi_init_resources.
>
> As long as vc4_hdmi_init_resources has left vc4_hdmi->pixel_bvb_clock
> at NULL, then the clock framework will be happy to do a nop.
>
> For BCM2711 an old DT would have issues, but, as Maxime has stated, no
> binding or upstream DTB has been merged yet, so it can be made
> mandatory.
If so, it seems good to set bvb_clock to mandatory without taking into
account the BCM2711 an old DTB as it hasn't been merged yet.
I will send version 2 patches.
> Making it optional drops you back on whatever the firmware might have
> set it to, which may be sufficient for some resolutions but not
> others.
As a result of checking by adding bvb_clock when I operated it with
the firmware, it was confirmed that the firmware increased the bvb_clock
from 7500 to 15000 when the FHD was exceeded.
Best regards
Hoegeun
>
>Dave
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208893] Navi (RX 5700 XT) system appears to hang with more than one display connected
https://bugzilla.kernel.org/show_bug.cgi?id=208893 --- Comment #15 from Alex Deucher (alexdeuc...@gmail.com) --- Does setting amdgpu.dpm=0 on the kernel command line in grub fix the issue? If so, remove that and try setting amdgpu.ppfeaturemask=0xbffd on the kernel command line in grub. Does that help? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] topic/nouveau-i915-dp-helpers-and-cleanup
topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1: UAPI Changes: None Cross-subsystem Changes: * Moves a bunch of miscellaneous DP code from the i915 driver into a set of shared DRM DP helpers Core Changes: * New DRM DP helpers (see above) Driver Changes: * Implements usage of the aforementioned DP helpers in the nouveau driver, along with some other various HPD related cleanup for nouveau The following changes since commit bfacb84993eb173c0ab53ca4dd6180f76f4dc176: drm: virtio: fix kconfig dependency warning (2020-08-31 08:55:02 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1 for you to fetch changes up to 79416e97dda0118b137302575a70a14259a27d7d: drm/nouveau/kms: Start using drm_dp_read_dpcd_caps() (2020-08-31 19:10:09 -0400) UAPI Changes: None Cross-subsystem Changes: * Moves a bunch of miscellaneous DP code from the i915 driver into a set of shared DRM DP helpers Core Changes: * New DRM DP helpers (see above) Driver Changes: * Implements usage of the aforementioned DP helpers in the nouveau driver, along with some other various HPD related cleanup for nouveau Lyude Paul (20): drm/nouveau/kms: Fix some indenting in nouveau_dp_detect() drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc() drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new() drm/nouveau/kms: Search for encoders' connectors properly drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in nv50_sor_disable() drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling drm/i915/dp: Extract drm_dp_read_mst_cap() drm/nouveau/kms: Use new drm_dp_read_mst_cap() helper for checking MST caps drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect() drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths drm/i915/dp: Extract drm_dp_read_downstream_info() drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation drm/i915/dp: Extract drm_dp_read_sink_count_cap() drm/i915/dp: Extract drm_dp_read_sink_count() drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT drm/nouveau/kms: Don't change EDID when it hasn't actually changed drm/i915/dp: Extract drm_dp_read_dpcd_caps() drm/nouveau/kms: Start using drm_dp_read_dpcd_caps() drivers/gpu/drm/drm_dp_helper.c | 187 - drivers/gpu/drm/drm_dp_mst_topology.c | 22 ++ drivers/gpu/drm/i915/display/intel_dp.c | 124 +++ drivers/gpu/drm/i915/display/intel_dp.h | 1 - drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/dfp.c | 7 +- drivers/gpu/drm/nouveau/dispnv04/disp.c | 24 ++- drivers/gpu/drm/nouveau/dispnv04/disp.h | 4 + drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 305 drivers/gpu/drm/nouveau/nouveau_connector.c | 132 +--- drivers/gpu/drm/nouveau/nouveau_connector.h | 1 + drivers/gpu/drm/nouveau/nouveau_display.c | 72 ++- drivers/gpu/drm/nouveau/nouveau_display.h | 3 +- drivers/gpu/drm/nouveau/nouveau_dp.c| 210 +++ drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +- drivers/gpu/drm/nouveau/nouveau_drv.h | 2 + drivers/gpu/drm/nouveau/nouveau_encoder.h | 48 - include/drm/drm_dp_helper.h | 15 +- include/drm/drm_dp_mst_helper.h | 3 +- 22 files changed, 779 insertions(+), 393 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/sun4i: tcon: Support the LVDS Dual-Link on the A20
Hi Maxime,
Thank you for the patch.
On Thu, Jul 30, 2020 at 11:35:03AM +0200, Maxime Ripard wrote:
> The A20 can use its second TCON as the secondary LVDS link in a dual-link
> setup, with the TCON0 being the main link. Extend a bit the parsing code to
> leverage the DRM dual-link code, register only the LVDS output on the
> primary TCON, and add the needed bits to setup the TCON properly.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 36 +++-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 +++-
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index d03ad75f9900..ed2abf6eb18b 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -487,6 +487,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
> *tcon,
> else
> reg |= SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL;
>
> + if (tcon->lvds_dual_link)
> + reg |= SUN4I_TCON0_LVDS_IF_DUAL_LINK;
> +
> if (sun4i_tcon_get_pixel_depth(encoder) == 24)
> reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS;
> else
> @@ -896,6 +899,16 @@ static int sun4i_tcon_register_panel(struct drm_device
> *drm,
> return sun4i_rgb_init(drm, tcon);
>
> /*
> + * Only the TCON0 will be relevant for the LVDS output, so if
> + * our ID is something else, let's prevent our TCON from
> + * registering its own LVDS output
> + */
> + if (tcon->id) {
> + dev_info(dev, "Secondary TCON, disabling panel output");
This may worry the user unnecessarily. I'd make it a debug message, or
drop it completely, and like reword it a bit as pointed out by Chen-Yu.
> + return 0;
> + }
> +
> + /*
>* This can only be made optional since we've had DT
>* nodes without the LVDS reset properties.
>*
> @@ -941,6 +954,28 @@ static int sun4i_tcon_register_panel(struct drm_device
> *drm,
> return -ENODEV;
> }
>
> + /*
> + * If we don't have a second TCON, we will never be able to do
> + * dual-link LVDS, so we don't have much more to do.
> + */
> + companion = of_parse_phandle(dev->of_node, "allwinner,lvds-companion",
> 0);
Should there be a patch to add this property to the DT bindings ?
> + if (!companion)
> + return 0;
> +
> + /*
> + * Let's do a sanity check on the dual-link setup to make sure
> + * everything is properly described.
> + */
> + ret = drm_of_lvds_get_dual_link_pixel_order(dev->of_node, 1, 0,
> + companion, 1, 0);
> + if (ret < 0) {
> + dev_err(dev, "Invalid Dual-Link Configuration.\n");
> + return ret;
> + }
> +
> + dev_info(dev, "Primary TCON, enabling LVDS Dual-Link");
> + tcon->lvds_dual_link = true;
> +
> return sun4i_lvds_init(drm, tcon);
> }
>
> @@ -1500,6 +1535,7 @@ static const struct sun4i_tcon_quirks
> sun7i_a20_tcon0_quirks = {
> };
>
> static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
> + .supports_lvds = true,
Should this be split to a separate patch, or at least mentioned in the
commit message ?
> .has_channel_0 = true,
> .has_channel_1 = true,
> .dclk_min_div = 4,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index cfbf4e6c1679..51c4e09cdd13 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -98,6 +98,7 @@
>
> #define SUN4I_TCON0_LVDS_IF_REG 0x84
> #define SUN4I_TCON0_LVDS_IF_EN BIT(31)
> +#define SUN4I_TCON0_LVDS_IF_DUAL_LINKBIT(30)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_MASKBIT(26)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_18BITS (1 << 26)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS (0 << 26)
> @@ -274,6 +275,9 @@ struct sun4i_tcon {
> /* Associated crtc */
> struct sun4i_crtc *crtc;
>
> + /* Is the LVDS link a dual-channel link? */
> + boollvds_dual_link;
> +
> int id;
>
> /* TCON list management */
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon: Add vddc hwmon sensor
On Sun, Aug 30, 2020 at 3:26 AM Sandeep Raghuraman wrote:
>
Please add a commit message. Also, split this into 2-3 patches:
1. add the new dpm callback
2. add the sumo implementation of the new callback (could be combined with 1)
3. expose the voltage via hwmon
For the last patch, you probably also want to adjust
hwmon_attributes_visible() to hide the voltage on asics which don't
have the callback.
Thanks!
Alex
> Signed-off-by: Sandeep Raghuraman
> ---
> drivers/gpu/drm/radeon/radeon.h | 1 +
> drivers/gpu/drm/radeon/radeon_asic.c | 1 +
> drivers/gpu/drm/radeon/radeon_asic.h | 1 +
> drivers/gpu/drm/radeon/radeon_pm.c | 21 +
> drivers/gpu/drm/radeon/sumo_dpm.c| 20
> 5 files changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 30e32adc1fc6..ec82f22e503a 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1992,6 +1992,7 @@ struct radeon_asic {
> int (*get_fan_speed_percent)(struct radeon_device *rdev, u32
> *speed);
> u32 (*get_current_sclk)(struct radeon_device *rdev);
> u32 (*get_current_mclk)(struct radeon_device *rdev);
> + u16 (*get_current_vddc)(struct radeon_device *rdev);
> } dpm;
> /* pageflipping */
> struct {
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 495700d16fc9..8becbe09af2f 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -1513,6 +1513,7 @@ static struct radeon_asic sumo_asic = {
> .force_performance_level = _dpm_force_performance_level,
> .get_current_sclk = _dpm_get_current_sclk,
> .get_current_mclk = _dpm_get_current_mclk,
> + .get_current_vddc = _dpm_get_current_vddc,
> },
> .pflip = {
> .page_flip = _page_flip,
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index a74fa18cd27b..24644daead53 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> @@ -596,6 +596,7 @@ int sumo_dpm_force_performance_level(struct radeon_device
> *rdev,
> enum radeon_dpm_forced_level level);
> u32 sumo_dpm_get_current_sclk(struct radeon_device *rdev);
> u32 sumo_dpm_get_current_mclk(struct radeon_device *rdev);
> +u16 sumo_dpm_get_current_vddc(struct radeon_device *rdev);
>
> /*
> * cayman
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 05c4196a8212..f02386a0d988 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -737,6 +737,26 @@ static ssize_t radeon_hwmon_show_sclk(struct device *dev,
> static SENSOR_DEVICE_ATTR(freq1_input, S_IRUGO, radeon_hwmon_show_sclk, NULL,
> 0);
>
> +static ssize_t radeon_hwmon_show_vddc(struct device *dev,
> + struct device_attribute *attr, char
> *buf)
> +{
> + struct radeon_device *rdev = dev_get_drvdata(dev);
> + struct drm_device *ddev = rdev->ddev;
> + u16 vddc = 0;
> +
> + /* Can't get vddc when the card is off */
> + if ((rdev->flags & RADEON_IS_PX) &&
> + (ddev->switch_power_state != DRM_SWITCH_POWER_ON))
> + return -EINVAL;
> +
> + if (rdev->asic->dpm.get_current_vddc)
> + vddc = rdev->asic->dpm.get_current_vddc(rdev);
> +
> + return snprintf(buf, PAGE_SIZE, "%u\n", vddc);
> +}
> +
> +static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, radeon_hwmon_show_vddc, NULL,
> + 0);
>
> static struct attribute *hwmon_attributes[] = {
> _dev_attr_temp1_input.dev_attr.attr,
> @@ -747,6 +767,7 @@ static struct attribute *hwmon_attributes[] = {
> _dev_attr_pwm1_min.dev_attr.attr,
> _dev_attr_pwm1_max.dev_attr.attr,
> _dev_attr_freq1_input.dev_attr.attr,
> + _dev_attr_in0_input.dev_attr.attr,
> NULL
> };
>
> diff --git a/drivers/gpu/drm/radeon/sumo_dpm.c
> b/drivers/gpu/drm/radeon/sumo_dpm.c
> index b95d5d390caf..f74f381af05f 100644
> --- a/drivers/gpu/drm/radeon/sumo_dpm.c
> +++ b/drivers/gpu/drm/radeon/sumo_dpm.c
> @@ -1865,6 +1865,26 @@ u32 sumo_dpm_get_current_mclk(struct radeon_device
> *rdev)
> return pi->sys_info.bootup_uma_clk;
> }
>
> +u16 sumo_dpm_get_current_vddc(struct radeon_device *rdev)
> +{
> + struct sumo_power_info *pi = sumo_get_pi(rdev);
> + struct radeon_ps *rps = >current_rps;
> + struct sumo_ps *ps = sumo_get_ps(rps);
> + struct sumo_pl *pl;
> + u32 current_index =
> + (RREG32(TARGET_AND_CURRENT_PROFILE_INDEX) & CURR_INDEX_MASK)
> >>
> + CURR_INDEX_SHIFT;
> +
> + if (current_index ==
Re: [PATCH v2 2/4] drm/sun4i: tcon: Refactor the LVDS and panel probing
Hi Maxime,
Thank you for the patch.
On Thu, Jul 30, 2020 at 11:35:02AM +0200, Maxime Ripard wrote:
> The current code to parse the DT, deal with the older device trees, and
> register either the RGB or LVDS output has so far grown organically into
> the bind function and has become quite hard to extend properly.
>
> Let's move it into a single function that grabs all the resources it needs
> and registers the proper panel output.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 139 +++---
> 1 file changed, 70 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 2a5a9903c4c6..d03ad75f9900 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -875,6 +875,75 @@ static int sun4i_tcon_init_regmap(struct device *dev,
> return 0;
> }
>
> +static int sun4i_tcon_register_panel(struct drm_device *drm,
> + struct sun4i_tcon *tcon)
> +{
> + struct device_node *companion;
> + struct device_node *remote;
> + struct device *dev = tcon->dev;
> + bool has_lvds_alt;
> + bool has_lvds_rst;
> + int ret;
> +
> + /*
> + * If we have an LVDS panel connected to the TCON, we should
> + * just probe the LVDS connector. Otherwise, let's just register
> + * an RGB panel.
> + */
> + remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> + if (!tcon->quirks->supports_lvds ||
> + !of_device_is_compatible(remote, "panel-lvds"))
This isn't very nice :-S Not a candidate for a fix in this patch, but
something that should be addressed in the future. As Chen-Yu mentioned,
there are LVDS panels supported by the panel-simple driver.
> + return sun4i_rgb_init(drm, tcon);
> +
> + /*
> + * This can only be made optional since we've had DT
> + * nodes without the LVDS reset properties.
> + *
> + * If the property is missing, just disable LVDS, and
> + * print a warning.
> + */
> + tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
> + if (IS_ERR(tcon->lvds_rst)) {
> + dev_err(dev, "Couldn't get our reset line\n");
> + return PTR_ERR(tcon->lvds_rst);
> + } else if (tcon->lvds_rst) {
> + has_lvds_rst = true;
> + reset_control_reset(tcon->lvds_rst);
> + } else {
> + has_lvds_rst = false;
> + }
> +
> + /*
> + * This can only be made optional since we've had DT
> + * nodes without the LVDS reset properties.
Shouldn't this mention clock, not reset ?
> + *
> + * If the property is missing, just disable LVDS, and
> + * print a warning.
> + */
> + if (tcon->quirks->has_lvds_alt) {
> + tcon->lvds_pll = devm_clk_get(dev, "lvds-alt");
> + if (IS_ERR(tcon->lvds_pll)) {
> + if (PTR_ERR(tcon->lvds_pll) == -ENOENT) {
> + has_lvds_alt = false;
> + } else {
> + dev_err(dev, "Couldn't get the LVDS PLL\n");
> + return PTR_ERR(tcon->lvds_pll);
> + }
> + } else {
> + has_lvds_alt = true;
> + }
> + }
> +
> + if (!has_lvds_rst ||
> + (tcon->quirks->has_lvds_alt && !has_lvds_alt)) {
> + dev_warn(dev, "Missing LVDS properties, Please upgrade your
> DT\n");
> + dev_warn(dev, "LVDS output disabled\n");
Would it make sense to move this to the has_lvds_rst = false and
has_lvds_alt = false code sections about ? You could then print which
property is missing.
Reviewed-by: Laurent Pinchart
> + return -ENODEV;
> + }
> +
> + return sun4i_lvds_init(drm, tcon);
> +}
> +
> /*
> * On SoCs with the old display pipeline design (Display Engine 1.0),
> * the TCON is always tied to just one backend. Hence we can traverse
> @@ -1122,10 +1191,8 @@ static int sun4i_tcon_bind(struct device *dev, struct
> device *master,
> struct drm_device *drm = data;
> struct sun4i_drv *drv = drm->dev_private;
> struct sunxi_engine *engine;
> - struct device_node *remote;
> struct sun4i_tcon *tcon;
> struct reset_control *edp_rstc;
> - bool has_lvds_rst, has_lvds_alt, can_lvds;
> int ret;
>
> engine = sun4i_tcon_find_engine(drv, dev->of_node);
> @@ -1170,58 +1237,6 @@ static int sun4i_tcon_bind(struct device *dev, struct
> device *master,
> return ret;
> }
>
> - if (tcon->quirks->supports_lvds) {
> - /*
> - * This can only be made optional since we've had DT
> - * nodes without the LVDS reset properties.
> - *
> - * If the property is missing, just disable LVDS, and
> - * print a warning.
> - */
> -
[PATCH] [RFC] drm/i915: make object creation avoid regions layering.
From: Dave Airlie
This looked like indirect ptr for not much reason in the create
object path, I just wonder why it couldn't be simpler like this,
The tests aren't cleaned up but this was more of is this a good idea
test patch.
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 16 ---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 33 +-
drivers/gpu/drm/i915/gem/i915_gem_region.h | 6 ++--
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 22 ++-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 24 ++--
drivers/gpu/drm/i915/i915_gem.c| 29 ---
drivers/gpu/drm/i915/intel_memory_region.h | 5
drivers/gpu/drm/i915/intel_region_lmem.c | 1 -
8 files changed, 50 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 932ee21e6609..710fb1158904 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -27,18 +27,14 @@ i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
unsigned int flags)
{
- return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
-size, flags);
-}
-
-struct drm_i915_gem_object *
-__i915_gem_lmem_object_create(struct intel_memory_region *mem,
- resource_size_t size,
- unsigned int flags)
-{
+ struct intel_memory_region *mem = i915->mm.regions[INTEL_REGION_LMEM];
static struct lock_class_key lock_class;
- struct drm_i915_private *i915 = mem->i915;
struct drm_i915_gem_object *obj;
+ int ret;
+
+ ret = i915_gem_object_pre_check(mem, , flags);
+ if (ret)
+ return ERR_PTR(ret);
obj = i915_gem_object_alloc();
if (!obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 1515384d7e0e..0902b3790e70 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -133,13 +133,12 @@ void i915_gem_object_release_memory_region(struct
drm_i915_gem_object *obj)
intel_memory_region_put(mem);
}
-struct drm_i915_gem_object *
-i915_gem_object_create_region(struct intel_memory_region *mem,
- resource_size_t size,
+int i915_gem_object_pre_check(struct intel_memory_region *mem,
+ resource_size_t *size,
unsigned int flags)
{
- struct drm_i915_gem_object *obj;
+ GEM_BUG_ON(!is_power_of_2(mem->min_page_size));
/*
* NB: Our use of resource_size_t for the size stems from using struct
* resource for the mem->region. We might need to revisit this in the
@@ -148,13 +147,13 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
GEM_BUG_ON(flags & ~I915_BO_ALLOC_FLAGS);
- if (!mem)
- return ERR_PTR(-ENODEV);
+ *size = round_up(*size, mem->min_page_size);
+ if (*size == 0)
+ return -EINVAL;
- size = round_up(size, mem->min_page_size);
-
- GEM_BUG_ON(!size);
- GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_MIN_ALIGNMENT));
+ /* For most of the ABI (e.g. mmap) we think in system pages */
+ GEM_BUG_ON(!IS_ALIGNED(*size, PAGE_SIZE));
+ GEM_BUG_ON(!IS_ALIGNED(*size, I915_GTT_MIN_ALIGNMENT));
/*
* XXX: There is a prevalence of the assumption that we fit the
@@ -163,15 +162,11 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
* spot such a local variable, please consider fixing!
*/
- if (size >> PAGE_SHIFT > INT_MAX)
- return ERR_PTR(-E2BIG);
-
- if (overflows_type(size, obj->base.size))
- return ERR_PTR(-E2BIG);
+ if (*size >> PAGE_SHIFT > INT_MAX)
+ return -E2BIG;
- obj = mem->ops->create_object(mem, size, flags);
- if (!IS_ERR(obj))
- trace_i915_gem_object_create(obj);
+ if (overflows_type(*size, size_t))
+ return -E2BIG;
- return obj;
+ return 0;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h
b/drivers/gpu/drm/i915/gem/i915_gem_region.h
index f2ff6f8bff74..584f3e91060c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
@@ -21,9 +21,7 @@ void i915_gem_object_init_memory_region(struct
drm_i915_gem_object *obj,
unsigned long flags);
void i915_gem_object_release_memory_region(struct drm_i915_gem_object *obj);
-struct drm_i915_gem_object *
-i915_gem_object_create_region(struct intel_memory_region *mem,
- resource_size_t size,
+int i915_gem_object_pre_check(struct intel_memory_region *mem,
+
Re: [PATCH 1/2] drm/radeon: Add sclk frequency as hwmon sensor
On Sun, Aug 30, 2020 at 3:25 AM Sandeep Raghuraman wrote:
>
> This patch series adds support for reporting sclk and vddc values for Radeon
> GPUs, where supported.
This commit message should be specific to this particular patch rather
than the series. You could probably expose mclk as well.
Alex
>
> Signed-off-by: Sandeep Raghuraman
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 8c5d6fda0d75..05c4196a8212 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -712,6 +712,31 @@ static SENSOR_DEVICE_ATTR(pwm1_enable, S_IRUGO |
> S_IWUSR, radeon_hwmon_get_pwm1_
> static SENSOR_DEVICE_ATTR(pwm1_min, S_IRUGO, radeon_hwmon_get_pwm1_min,
> NULL, 0);
> static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO, radeon_hwmon_get_pwm1_max,
> NULL, 0);
>
> +static ssize_t radeon_hwmon_show_sclk(struct device *dev,
> + struct device_attribute *attr, char
> *buf)
> +{
> + struct radeon_device *rdev = dev_get_drvdata(dev);
> + struct drm_device *ddev = rdev->ddev;
> + u32 sclk = 0;
> +
> + /* Can't get clock frequency when the card is off */
> + if ((rdev->flags & RADEON_IS_PX) &&
> + (ddev->switch_power_state != DRM_SWITCH_POWER_ON))
> + return -EINVAL;
> +
> + if (rdev->asic->dpm.get_current_sclk)
> + sclk = radeon_dpm_get_current_sclk(rdev);
> +
> + /* Value returned by dpm is in 10 KHz units, need to convert it into
> Hz
> + for hwmon */
> + sclk *= 1;
> +
> + return snprintf(buf, PAGE_SIZE, "%u\n", sclk);
> +}
> +
> +static SENSOR_DEVICE_ATTR(freq1_input, S_IRUGO, radeon_hwmon_show_sclk, NULL,
> + 0);
> +
>
> static struct attribute *hwmon_attributes[] = {
> _dev_attr_temp1_input.dev_attr.attr,
> @@ -721,6 +746,7 @@ static struct attribute *hwmon_attributes[] = {
> _dev_attr_pwm1_enable.dev_attr.attr,
> _dev_attr_pwm1_min.dev_attr.attr,
> _dev_attr_pwm1_max.dev_attr.attr,
> + _dev_attr_freq1_input.dev_attr.attr,
> NULL
> };
>
> @@ -738,7 +764,8 @@ static umode_t hwmon_attributes_visible(struct kobject
> *kobj,
> attr == _dev_attr_pwm1.dev_attr.attr ||
> attr == _dev_attr_pwm1_enable.dev_attr.attr ||
> attr == _dev_attr_pwm1_max.dev_attr.attr ||
> -attr == _dev_attr_pwm1_min.dev_attr.attr))
> +attr == _dev_attr_pwm1_min.dev_attr.attr ||
> +attr == _dev_attr_freq1_input.dev_attr.attr))
> return 0;
>
> /* Skip fan attributes if fan is not present */
> --
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order
Hi Maxime,
Thank you for the patch.
On Thu, Jul 30, 2020 at 11:35:01AM +0200, Maxime Ripard wrote:
> The drm_of_lvds_get_dual_link_pixel_order() function took so far the
> device_node of the two ports used together to make up a dual-link LVDS
> output.
>
> This assumes that a binding would use an entire port for the LVDS output.
> However, some bindings have used endpoints instead and thus we need to
> operate at the endpoint level. Change slightly the arguments to allow that.
Is this still needed ? Unless I'm mistaken, the Allwinner platform now
uses two TCON instances for the two links, so there are two ports.
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_of.c| 98 +++---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 8 +--
> include/drm/drm_of.h| 16 +++--
> 3 files changed, 63 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index b50b44e76279..2dcb49b0401b 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -291,50 +291,34 @@ static int drm_of_lvds_get_port_pixels_type(struct
> device_node *port_node)
> (odd_pixels ? DRM_OF_LVDS_ODD : 0);
> }
>
> -static int drm_of_lvds_get_remote_pixels_type(
> - const struct device_node *port_node)
> +static int drm_of_lvds_get_remote_pixels_type(const struct device_node
> *endpoint)
> {
> - struct device_node *endpoint = NULL;
> - int pixels_type = -EPIPE;
> + struct device_node *remote_port;
> + int pixels_type;
>
> - for_each_child_of_node(port_node, endpoint) {
> - struct device_node *remote_port;
> - int current_pt;
> -
> - if (!of_node_name_eq(endpoint, "endpoint"))
> - continue;
> -
> - remote_port = of_graph_get_remote_port(endpoint);
> - if (!remote_port) {
> - of_node_put(remote_port);
> - return -EPIPE;
> - }
> -
> - current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
> + remote_port = of_graph_get_remote_port(endpoint);
> + if (!remote_port) {
> of_node_put(remote_port);
> - if (pixels_type < 0)
> - pixels_type = current_pt;
> -
> - /*
> - * Sanity check, ensure that all remote endpoints have the same
> - * pixel type. We may lift this restriction later if we need to
> - * support multiple sinks with different dual-link
> - * configurations by passing the endpoints explicitly to
> - * drm_of_lvds_get_dual_link_pixel_order().
> - */
> - if (!current_pt || pixels_type != current_pt) {
> - of_node_put(remote_port);
> - return -EINVAL;
> - }
> + return -EPIPE;
> }
>
> + pixels_type = drm_of_lvds_get_port_pixels_type(remote_port);
> + of_node_put(remote_port);
> +
> + if (pixels_type < 0)
> + pixels_type = -EPIPE;
> +
> return pixels_type;
> }
>
> /**
> * drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link pixel order
> - * @port1: First DT port node of the Dual-link LVDS source
> - * @port2: Second DT port node of the Dual-link LVDS source
> + * @dev1: First DT device node of the Dual-Link LVDS source
> + * @port1_id: ID of the first DT port node of the Dual-Link LVDS source
> + * @endpoint1_id: ID of the first DT port node of the Dual-Link LVDS source
> + * @dev2: First DT device node of the Dual-Link LVDS source
> + * @port2_id: ID of the first DT port node of the Dual-Link LVDS source
> + * @endpoint2_id: ID of the first DT port node of the Dual-Link LVDS source
> *
> * An LVDS dual-link connection is made of two links, with even pixels
> * transitting on one link, and odd pixels on the other link. This function
> @@ -348,32 +332,48 @@ static int drm_of_lvds_get_remote_pixels_type(
> *
> * If either port is not connected, this function returns -EPIPE.
> *
> - * @port1 and @port2 are typically DT sibling nodes, but may have different
> - * parents when, for instance, two separate LVDS encoders carry the even and
> odd
> - * pixels.
> + * @port1_id and @port2_id are typically DT sibling nodes, but may have
> + * different parents when, for instance, two separate LVDS encoders carry the
> + * even and odd pixels.
> + *
> + * If @port1_id, @port2_id, @endpoint1_id or @endpoint2_id are set to -1,
> their
> + * value is going to be ignored.
> *
> * Return:
> - * * DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS - @port1 carries even pixels and
> @port2
> - * carries odd pixels
> - * * DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS - @port1 carries odd pixels and
> @port2
> - * carries even pixels
> - * * -EINVAL - @port1 and @port2 are not connected to a dual-link LVDS sink,
> or
> - * the sink configuration is invalid
> - * * -EPIPE -
Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
Hi Swapnil,
Thank you for the patch.
On Mon, Aug 31, 2020 at 10:23:34AM +0200, Swapnil Jakhade wrote:
> Add a new DRM bridge driver for Cadence MHDP8546 DPTX IP used in TI J721E
> SoC. MHDP DPTX IP is the component that complies with VESA DisplayPort (DP)
> and embedded Display Port (eDP) standards. It integrates uCPU running the
> embedded Firmware (FW) interfaced over APB interface.
>
> Basically, it takes a DPI stream as input and outputs it encoded in DP
> format. Currently, it supports only SST mode.
>
> Co-developed-by: Tomi Valkeinen
> Signed-off-by: Tomi Valkeinen
> Co-developed-by: Jyri Sarha
> Signed-off-by: Jyri Sarha
> Signed-off-by: Quentin Schulz
> Signed-off-by: Yuti Amonkar
> Signed-off-by: Swapnil Jakhade
> ---
> drivers/gpu/drm/bridge/Kconfig|2 +
> drivers/gpu/drm/bridge/Makefile |1 +
> drivers/gpu/drm/bridge/cadence/Kconfig| 11 +
> drivers/gpu/drm/bridge/cadence/Makefile |3 +
> .../drm/bridge/cadence/cdns-mhdp8546-core.c | 2548 +
> .../drm/bridge/cadence/cdns-mhdp8546-core.h | 402 +++
> 6 files changed, 2967 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/cadence/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/cadence/Makefile
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3e11af4e9f63..ef91646441b1 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -241,6 +241,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
>
> +source "drivers/gpu/drm/bridge/cadence/Kconfig"
> +
> source "drivers/gpu/drm/bridge/synopsys/Kconfig"
>
> endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index c589a6a7cbe1..2b3aff104e46 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -25,4 +25,5 @@ obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
> obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
>
> obj-y += analogix/
> +obj-y += cadence/
> obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
> b/drivers/gpu/drm/bridge/cadence/Kconfig
> new file mode 100644
> index ..f49d77eb7814
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config DRM_CDNS_MHDP8546
> + tristate "Cadence DPI/DP bridge"
> + select DRM_KMS_HELPER
> + select DRM_PANEL_BRIDGE
> + depends on OF
> + help
> + Support Cadence DPI to DP bridge. This is an internal
> + bridge and is meant to be directly embedded in a SoC.
> + It takes a DPI stream as input and outputs it encoded
> + in DP format.
> diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
> b/drivers/gpu/drm/bridge/cadence/Makefile
> new file mode 100644
> index ..676739cdf5e6
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
> +cdns-mhdp8546-y := cdns-mhdp8546-core.o
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> new file mode 100644
> index ..14be6f370d6e
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -0,0 +1,2548 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Cadence MHDP8546 DP bridge driver.
> + *
> + * Copyright (C) 2020 Cadence Design Systems, Inc.
> + *
> + * Authors: Quentin Schulz
> + * Swapnil Jakhade
> + * Yuti Amonkar
> + * Tomi Valkeinen
> + * Jyri Sarha
> + *
> + * TODO:
> + * - Implement optimized mailbox communication using mailbox interrupts
> + * - Add support for power management
> + * - Add support for features like audio, MST and fast link training
> + * - Implement request_fw_cancel to handle HW_STATE
> + * - Fix asynchronous loading of firmware implementation
> + * - Add DRM helper function for cdns_mhdp_lower_link_rate
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "cdns-mhdp8546-core.h"
> +
> +static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
> +{
> + int ret, empty;
> +
> + WARN_ON(!mutex_is_locked(>mbox_mutex));
> +
> + ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_EMPTY,
> + empty, !empty, MAILBOX_RETRY_US,
> +
RE: [PATCH v6] drm/kmb: Add support for KeemBay Display
Hi Sam,
Thanks a lot for the review. I will address your comments in v7.
For those that are not addressed, please see my reply inline.
Regards,
Anitha
> -Original Message-
> From: Sam Ravnborg
> Sent: Thursday, August 20, 2020 1:10 PM
> To: Chrisanthus, Anitha
> Cc: dri-devel@lists.freedesktop.org; Paauwe, Bob J
> ; Dea, Edmund J ;
> Vetter, Daniel ; intel-...@lists.freedesktop.org
> Subject: Re: [PATCH v6] drm/kmb: Add support for KeemBay Display
>
> Hi Anitha.
>
> Feedback on kmb_dsi.
>
> The main feedback can be found after the kmb_dsi_init function.
> The highligt of the feedback is that, in my opinion, the
> best would be to use the drm_bridge abstraction for the kmb_dsi.
> Maybe because I am biased - and this is just overhead.
> But it just looks simpler to me.
Mipi dsi is very time sensitive and any delay can cause problems.
As soon as it's initialized it expects LCD controller to be up and running
especially the LCD_TIMING_GEN_TRIG, a slight delay and lots of issues.
It is tightly coupled in the hardware with LCD and let's keep it that
way in the software too.
> There are several chunks of code surrounded by #ifdef.
> It would be good if they could all be handled so no more #ifdef are
> required.
>
> There is also a lot of debug prints. Maybe this can be trimmed now that
> the driver works?
>
> There is a lot of variables that should all be included in a struct
> kmb_dsi that should be allocated in the probe function (if this becomes
> a bridge driver).
>
> I hope this does not scare you away! If I am right about the ocnversion
> to a drm_bridge, then I hope it is semi trivial to do.
> All the hard HW init stuff is done.
>
> Sam
>
> > diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c
> b/drivers/gpu/drm/kmb/kmb_dsi.c
> > new file mode 100644
> > index 000..21745ae
> > --- /dev/null
> > +++ b/drivers/gpu/drm/kmb/kmb_dsi.c
> > @@ -0,0 +1,1828 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (c) 2019-2020 Intel Corporation
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "kmb_drv.h"
> > +#include "kmb_dsi.h"
> > +#include "kmb_regs.h"
> > +
> > +static int hw_initialized;
> > +/* #define MIPI_TX_TEST_PATTERN_GENERATION */
> > +/* #define DPHY_GET_FSM */
> > +/* #define DPHY_READ_TESTCODE */
> > +
> > +static struct mipi_dsi_host *dsi_host;
> > +static struct mipi_dsi_device *dsi_device;
> > +
> > +/* Default setting is 1080p, 4 lanes */
> > +#define IMG_HEIGHT_LINES 1080
> > +#define IMG_WIDTH_PX 1920
> > +#define MIPI_TX_ACTIVE_LANES 4
> > +
> > +struct mipi_tx_frame_section_cfg mipi_tx_frame0_sect_cfg = {
> > + .width_pixels = IMG_WIDTH_PX,
> > + .height_lines = IMG_HEIGHT_LINES,
> > + .data_type = DSI_LP_DT_PPS_RGB888_24B,
> > + .data_mode = MIPI_DATA_MODE1,
> > + .dma_packed = 0
> > +};
> > +
> > +struct mipi_tx_frame_cfg mipitx_frame0_cfg = {
> > + .sections[0] = _tx_frame0_sect_cfg,
> > + .sections[1] = NULL,
> > + .sections[2] = NULL,
> > + .sections[3] = NULL,
> > + .vsync_width = 5,
> > + .v_backporch = 36,
> > + .v_frontporch = 4,
> > + .hsync_width = 44,
> > + .h_backporch = 148,
> > + .h_frontporch = 88
> > +};
> > +
> > +struct mipi_tx_dsi_cfg mipitx_dsi_cfg = {
> > + .hfp_blank_en = 0,
> > + .eotp_en = 0,
> > + .lpm_last_vfp_line = 0,
> > + .lpm_first_vsa_line = 0,
> > + .sync_pulse_eventn = DSI_VIDEO_MODE_NO_BURST_EVENT,
> > + .hfp_blanking = SEND_BLANK_PACKET,
> > + .hbp_blanking = SEND_BLANK_PACKET,
> > + .hsa_blanking = SEND_BLANK_PACKET,
> > + .v_blanking = SEND_BLANK_PACKET,
> > +};
> > +
> > +struct mipi_ctrl_cfg mipi_tx_init_cfg = {
> > + .index = MIPI_CTRL6,
> > + .type = MIPI_DSI,
> > + .dir = MIPI_TX,
> > + .active_lanes = MIPI_TX_ACTIVE_LANES,
> > + .lane_rate_mbps = MIPI_TX_LANE_DATA_RATE_MBPS,
> > + .ref_clk_khz = MIPI_TX_REF_CLK_KHZ,
> > + .cfg_clk_khz = MIPI_TX_CFG_CLK_KHZ,
> > + .data_if = MIPI_IF_PARALLEL,
> > + .tx_ctrl_cfg = {
> > + .frames[0] = _frame0_cfg,
> > + .frames[1] = NULL,
> > + .frames[2] = NULL,
> > + .frames[3] = NULL,
> > + .tx_dsi_cfg = _dsi_cfg,
> > + .line_sync_pkt_en = 0,
> > + .line_counter_active = 0,
> > + .frame_counter_active = 0,
> > + .tx_always_use_hact = 1,
> > + .tx_hact_wait_stop = 1,
> > + }
> > +};
> > +
> > +struct mipi_hs_freq_range_cfg {
> > + u16 default_bit_rate_mbps;
> > + u8 hsfreqrange_code;
> > +};
> > +
> > +struct vco_params {
> > + u32 freq;
> > + u32 range;
> > + u32 divider;
> > +};
> > +
> > +static struct vco_params vco_table[] = {
> > + {52, 0x3f, 8},
> > + {80, 0x39, 8},
> > + {105, 0x2f, 4},
> > +
[PATCH v7 2/4] drm/kmb: Add support for KeemBay Display
This is a basic KMS atomic modesetting display driver for KeemBay family of
SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge
driver at the connector level.
Single CRTC with LCD controller->mipi DSI-> ADV bridge
Only 1080p resolution and single plane is supported at this time.
v2: moved extern to .h, removed license text
use drm_dev_init, upclassed dev_private, removed HAVE_IRQ.(Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
moved clocks under kmb_clock, consolidated clk initializations
use drmm functions
use DRM_GEM_CMA_DRIVER_OPS_VMAP
v5: corrected spellings
v6: corrected checkpatch warnings
v7: review changes Sam Ravnborg and Thomas Zimmerman
removed kmb_crtc.h kmb_crtc_cleanup (Thomas)
renamed mode_set, kmb_load, inlined unload (Thomas)
moved remaining logging to drm_*(Thomas)
re-orged driver initialization (Thomas)
moved plane_status to drm_private (Sam)
removed unnecessary logs and defines and ifdef codes (Sam)
call helper_check in plane_atomic_check (Sam)
renamed set to get for bpp and format functions(Sam)
use drm helper functions for reset, duplicate/destroy state instead
of kmb functions (Sam)
removed kmb_priv from kmb_plane and removed kmb_plane_state (Sam)
Cc: Sam Ravnborg
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/kmb/kmb_crtc.c | 224 +
drivers/gpu/drm/kmb/kmb_drv.c | 676
drivers/gpu/drm/kmb/kmb_drv.h | 170 ++
drivers/gpu/drm/kmb/kmb_plane.c | 480
drivers/gpu/drm/kmb/kmb_plane.h | 110 +++
5 files changed, 1660 insertions(+)
create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c
create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c
create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h
create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c
create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h
diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c b/drivers/gpu/drm/kmb/kmb_crtc.c
new file mode 100644
index 000..a684331
--- /dev/null
+++ b/drivers/gpu/drm/kmb/kmb_crtc.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2018-2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "kmb_drv.h"
+#include "kmb_dsi.h"
+#include "kmb_plane.h"
+#include "kmb_regs.h"
+
+struct kmb_crtc_timing {
+ u32 vfront_porch;
+ u32 vback_porch;
+ u32 vsync_len;
+ u32 hfront_porch;
+ u32 hback_porch;
+ u32 hsync_len;
+};
+
+static int kmb_crtc_enable_vblank(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct kmb_drm_private *kmb = to_kmb(dev);
+
+ /* Clear interrupt */
+ kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
+ /* Set which interval to generate vertical interrupt */
+ kmb_write_lcd(kmb, LCD_VSTATUS_COMPARE,
+ LCD_VSTATUS_COMPARE_VSYNC);
+ /* Enable vertical interrupt */
+ kmb_set_bitmask_lcd(kmb, LCD_INT_ENABLE,
+ LCD_INT_VERT_COMP);
+ return 0;
+}
+
+static void kmb_crtc_disable_vblank(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct kmb_drm_private *kmb = to_kmb(dev);
+
+ /* Clear interrupt */
+ kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
+ /* Disable vertical interrupt */
+ kmb_clr_bitmask_lcd(kmb, LCD_INT_ENABLE,
+ LCD_INT_VERT_COMP);
+}
+
+static const struct drm_crtc_funcs kmb_crtc_funcs = {
+ .destroy = drm_crtc_cleanup,
+ .set_config = drm_atomic_helper_set_config,
+ .page_flip = drm_atomic_helper_page_flip,
+ .reset = drm_atomic_helper_crtc_reset,
+ .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+ .enable_vblank = kmb_crtc_enable_vblank,
+ .disable_vblank = kmb_crtc_disable_vblank,
+};
+
+static void kmb_crtc_set_mode(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_display_mode *m = >state->adjusted_mode;
+ struct kmb_crtc_timing vm;
+ int vsync_start_offset;
+ int vsync_end_offset;
+ struct kmb_drm_private *kmb = to_kmb(dev);
+ unsigned int val = 0;
+
+ /* Initialize mipi */
+ kmb_dsi_hw_init(dev, m);
+ drm_info(dev,
+"vfp= %d vbp= %d vsyc_len=%d hfp=%d hbp=%d hsync_len=%d\n",
+m->crtc_vsync_start - m->crtc_vdisplay,
+m->crtc_vtotal - m->crtc_vsync_end,
+m->crtc_vsync_end - m->crtc_vsync_start,
+m->crtc_hsync_start - m->crtc_hdisplay,
[PATCH v7 1/4] drm/kmb: Keem Bay driver register definition
Register definitions for Keem Bay display driver v2: removed license text (Sam) v3: Squashed all 59 commits to one v4: review changes from Sam Ravnborg renamed dev_p to kmb v5: corrected spellings v6: corrected checkpatch warnings Cc: Sam Ravnborg Signed-off-by: Anitha Chrisanthus Reviewed-by: Bob Paauwe --- drivers/gpu/drm/kmb/kmb_regs.h | 748 + 1 file changed, 748 insertions(+) create mode 100644 drivers/gpu/drm/kmb/kmb_regs.h diff --git a/drivers/gpu/drm/kmb/kmb_regs.h b/drivers/gpu/drm/kmb/kmb_regs.h new file mode 100644 index 000..f794ac3 --- /dev/null +++ b/drivers/gpu/drm/kmb/kmb_regs.h @@ -0,0 +1,748 @@ +/* SPDX-License-Identifier: GPL-2.0-only + * + * Copyright © 2018-2020 Intel Corporation + */ + +#ifndef __KMB_REGS_H__ +#define __KMB_REGS_H__ + +#define ENABLE 1 +#define DISABLE 0 +/*from Data Book section 12.5.8.1 page 4322 */ +#define CPR_BASE_ADDR (0x2081) +#define MIPI_BASE_ADDR (0x2090) +/*from Data Book section 12.11.6.1 page 4972 */ +#define LCD_BASE_ADDR (0x2093) +#define MSS_CAM_BASE_ADDR (MIPI_BASE_ADDR + 0x1) +#define LCD_MMIO_SIZE (0x3000) +#define MIPI_MMIO_SIZE (0x4000) +#define MSS_CAM_MMIO_SIZE (0x30) + +/*** + *LCD controller control register defines + ***/ +#define LCD_CONTROL(0x4 * 0x000) +#define LCD_CTRL_PROGRESSIVE (0 << 0) +#define LCD_CTRL_INTERLACED BIT(0) +#define LCD_CTRL_ENABLE BIT(1) +#define LCD_CTRL_VL1_ENABLE BIT(2) +#define LCD_CTRL_VL2_ENABLE BIT(3) +#define LCD_CTRL_GL1_ENABLE BIT(4) +#define LCD_CTRL_GL2_ENABLE BIT(5) +#define LCD_CTRL_ALPHA_BLEND_VL1 (0 << 6) +#define LCD_CTRL_ALPHA_BLEND_VL2 BIT(6) +#define LCD_CTRL_ALPHA_BLEND_GL1 (2 << 6) +#define LCD_CTRL_ALPHA_BLEND_GL2 (3 << 6) +#define LCD_CTRL_ALPHA_TOP_VL1 (0 << 8) +#define LCD_CTRL_ALPHA_TOP_VL2 BIT(8) +#define LCD_CTRL_ALPHA_TOP_GL1 (2 << 8) +#define LCD_CTRL_ALPHA_TOP_GL2 (3 << 8) +#define LCD_CTRL_ALPHA_MIDDLE_VL1(0 << 10) +#define LCD_CTRL_ALPHA_MIDDLE_VL2BIT(10) +#define LCD_CTRL_ALPHA_MIDDLE_GL1(2 << 10) +#define LCD_CTRL_ALPHA_MIDDLE_GL2(3 << 10) +#define LCD_CTRL_ALPHA_BOTTOM_VL1(0 << 12) +#define LCD_CTRL_ALPHA_BOTTOM_VL2BIT(12) +#define LCD_CTRL_ALPHA_BOTTOM_GL1(2 << 12) +#define LCD_CTRL_ALPHA_BOTTOM_GL2(3 << 12) +#define LCD_CTRL_TIM_GEN_ENABLE BIT(14) +#define LCD_CTRL_CONTINUOUS (0 << 15) +#define LCD_CTRL_ONE_SHOTBIT(15) +#define LCD_CTRL_PWM0_EN BIT(16) +#define LCD_CTRL_PWM1_EN BIT(17) +#define LCD_CTRL_PWM2_EN BIT(18) +#define LCD_CTRL_OUTPUT_DISABLED (0 << 19) +#define LCD_CTRL_OUTPUT_ENABLED BIT(19) +#define LCD_CTRL_BPORCH_ENABLE BIT(21) +#define LCD_CTRL_FPORCH_ENABLE BIT(22) +#define LCD_CTRL_PIPELINE_DMABIT(28) +#define LCD_CTRL_VHSYNC_IDLE_LVL BIT(31) + +/*interrupts */ +#define LCD_INT_STATUS (0x4 * 0x001) +#define LCD_INT_EOF BIT(0) +#define LCD_INT_LINE_CMP BIT(1) +#define LCD_INT_VERT_COMPBIT(2) +#define LAYER0_DMA_DONE BIT(3) +#define LAYER0_DMA_IDLE BIT(4) +#define LAYER0_DMA_FIFO_OVERFLOW BIT(5) +#define LAYER0_DMA_FIFO_UNDERFLOWBIT(6) +#define LAYER0_DMA_CB_FIFO_OVERFLOW BIT(7) +#define LAYER0_DMA_CB_FIFO_UNDERFLOW BIT(8) +#define LAYER0_DMA_CR_FIFO_OVERFLOW BIT(9) +#define LAYER0_DMA_CR_FIFO_UNDERFLOW BIT(10) +#define LAYER1_DMA_DONE BIT(11) +#define LAYER1_DMA_IDLE BIT(12) +#define LAYER1_DMA_FIFO_OVERFLOW BIT(13) +#define LAYER1_DMA_FIFO_UNDERFLOWBIT(14) +#define LAYER1_DMA_CB_FIFO_OVERFLOW BIT(15) +#define LAYER1_DMA_CB_FIFO_UNDERFLOW BIT(16) +#define LAYER1_DMA_CR_FIFO_OVERFLOW BIT(17) +#define LAYER1_DMA_CR_FIFO_UNDERFLOW
[PATCH v7 3/4] drm/kmb: Mipi DSI part of the display driver
Initializes Mipi DSI and sets up connects to ADV bridge
v2: removed license text
upclassed dev_private, removed HAVE_IRQ. (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7: review changes Sam Ravnborg and Thomas Zimmerman
removed unnecessary logs and defines and ifdef codes (Sam)
split dphy_init_sequence smaller (Sam)
removed redundant checks in kmb_dsi (Sam)
changed kmb_dsi_init to drm_bridge_connector_init and
drm_connector_attach_encoder to bridge's connector (Sam)
Cc: Sam Ravnborg
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/kmb/kmb_dsi.c | 1523 +
drivers/gpu/drm/kmb/kmb_dsi.h | 350 ++
2 files changed, 1873 insertions(+)
create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c
create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.h
diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c b/drivers/gpu/drm/kmb/kmb_dsi.c
new file mode 100644
index 000..a0dbfa7
--- /dev/null
+++ b/drivers/gpu/drm/kmb/kmb_dsi.c
@@ -0,0 +1,1523 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2019-2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "kmb_drv.h"
+#include "kmb_dsi.h"
+#include "kmb_regs.h"
+
+static struct mipi_dsi_host *dsi_host;
+static struct mipi_dsi_device *dsi_device;
+
+/* Default setting is 1080p, 4 lanes */
+#define IMG_HEIGHT_LINES 1080
+#define IMG_WIDTH_PX 1920
+#define MIPI_TX_ACTIVE_LANES 4
+
+struct mipi_tx_frame_section_cfg mipi_tx_frame0_sect_cfg = {
+ .width_pixels = IMG_WIDTH_PX,
+ .height_lines = IMG_HEIGHT_LINES,
+ .data_type = DSI_LP_DT_PPS_RGB888_24B,
+ .data_mode = MIPI_DATA_MODE1,
+ .dma_packed = 0
+};
+
+struct mipi_tx_frame_cfg mipitx_frame0_cfg = {
+ .sections[0] = _tx_frame0_sect_cfg,
+ .sections[1] = NULL,
+ .sections[2] = NULL,
+ .sections[3] = NULL,
+ .vsync_width = 5,
+ .v_backporch = 36,
+ .v_frontporch = 4,
+ .hsync_width = 44,
+ .h_backporch = 148,
+ .h_frontporch = 88
+};
+
+struct mipi_tx_dsi_cfg mipitx_dsi_cfg = {
+ .hfp_blank_en = 0,
+ .eotp_en = 0,
+ .lpm_last_vfp_line = 0,
+ .lpm_first_vsa_line = 0,
+ .sync_pulse_eventn = DSI_VIDEO_MODE_NO_BURST_EVENT,
+ .hfp_blanking = SEND_BLANK_PACKET,
+ .hbp_blanking = SEND_BLANK_PACKET,
+ .hsa_blanking = SEND_BLANK_PACKET,
+ .v_blanking = SEND_BLANK_PACKET,
+};
+
+struct mipi_ctrl_cfg mipi_tx_init_cfg = {
+ .active_lanes = MIPI_TX_ACTIVE_LANES,
+ .lane_rate_mbps = MIPI_TX_LANE_DATA_RATE_MBPS,
+ .ref_clk_khz = MIPI_TX_REF_CLK_KHZ,
+ .cfg_clk_khz = MIPI_TX_CFG_CLK_KHZ,
+ .tx_ctrl_cfg = {
+ .frames[0] = _frame0_cfg,
+ .frames[1] = NULL,
+ .frames[2] = NULL,
+ .frames[3] = NULL,
+ .tx_dsi_cfg = _dsi_cfg,
+ .line_sync_pkt_en = 0,
+ .line_counter_active = 0,
+ .frame_counter_active = 0,
+ .tx_always_use_hact = 1,
+ .tx_hact_wait_stop = 1,
+ }
+};
+
+struct mipi_hs_freq_range_cfg {
+ u16 default_bit_rate_mbps;
+ u8 hsfreqrange_code;
+};
+
+struct vco_params {
+ u32 freq;
+ u32 range;
+ u32 divider;
+};
+
+static struct vco_params vco_table[] = {
+ {52, 0x3f, 8},
+ {80, 0x39, 8},
+ {105, 0x2f, 4},
+ {160, 0x29, 4},
+ {210, 0x1f, 2},
+ {320, 0x19, 2},
+ {420, 0x0f, 1},
+ {630, 0x09, 1},
+ {1100, 0x03, 1},
+ {0x, 0x01, 1},
+};
+
+static struct mipi_hs_freq_range_cfg
+mipi_hs_freq_range[MIPI_DPHY_DEFAULT_BIT_RATES] = {
+ {.default_bit_rate_mbps = 80, .hsfreqrange_code = 0x00},
+ {.default_bit_rate_mbps = 90, .hsfreqrange_code = 0x10},
+ {.default_bit_rate_mbps = 100, .hsfreqrange_code = 0x20},
+ {.default_bit_rate_mbps = 110, .hsfreqrange_code = 0x30},
+ {.default_bit_rate_mbps = 120, .hsfreqrange_code = 0x01},
+ {.default_bit_rate_mbps = 130, .hsfreqrange_code = 0x11},
+ {.default_bit_rate_mbps = 140, .hsfreqrange_code = 0x21},
+ {.default_bit_rate_mbps = 150, .hsfreqrange_code = 0x31},
+ {.default_bit_rate_mbps = 160, .hsfreqrange_code = 0x02},
+ {.default_bit_rate_mbps = 170, .hsfreqrange_code = 0x12},
+ {.default_bit_rate_mbps = 180, .hsfreqrange_code = 0x22},
+ {.default_bit_rate_mbps = 190, .hsfreqrange_code = 0x32},
+ {.default_bit_rate_mbps = 205, .hsfreqrange_code = 0x03},
+ {.default_bit_rate_mbps = 220, .hsfreqrange_code = 0x13},
+
[PATCH v7 0/4] Add support for KeemBay DRM driver
This is a new DRM driver for Intel's KeemBay SOC. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This driver is tested with the KMB EVM board which is the refernce baord for Keem Bay SOC. The SOC's display pipeline is as follows +--++-++---+ |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | +--++-++---+ LCD controller and Mipi DSI transmitter are part of the SOC and mipi to HDMI converter is ADV7535 for KMB EVM board. The DRM driver is a basic KMS atomic modesetting display driver and has no 2D or 3D graphics.It calls into the ADV bridge driver at the connector level. Only 1080p resolution and single plane is supported at this time. The usecase is for debugging video and camera outputs. Device tree patches are under review here https://lore.kernel.org/linux-arm-kernel/20200708175020.194436-1-daniele.alessandre...@linux.intel.com/T/ Changes since v1: - Removed redundant license text, updated license - Rearranged include blocks - renamed global vars and removed extern in c - Used upclassing for dev_private - Used drm_dev_init in drm device create - minor cleanups Changes since v2: - squashed all commits to a single commit - logging changed to drm_info, drm_dbg etc. - used devm_drm_dev_alloc() - removed commented out sections and general cleanup Changes since v3: - renamed dev_p to kmb - moved clocks under kmb_clock, consolidated clk initializations - use drmm functions - use DRM_GEM_CMA_DRIVER_OPS_VMAP - more cleanups Changes since v4: - corrected spellings Changes since v5: - corrected checkpatch warnings/checks -Please ignore checkpatch checks on Camelcase - this is how it is named in the databook - Please ignore checkpatch warnings on misspelled for hsa, dout, widthn etc. - they are spelled as in the databook - Please ignore checkpatch checks on macro arguments reuse - its confirmed ok Changes since v6: - review changes Sam Ravnborg and Thomas Zimmerman split patch into 4 parts, part1 register definitions, part2 display driver files, part3 mipi dsi, part4 build files (Sam) removed kmb_crtc.h kmb_crtc_cleanup (Thomas) renamed mode_set, kmb_load, inlined unload (Thomas) moved remaining logging to drm_*(Thomas) re-orged driver initialization (Thomas) moved plane_status to drm_private (Sam) removed unnecessary logs and defines and ifdef codes (Sam) split dphy_init_sequence smaller (Sam) removed redundant checks in kmb_dsi (Sam) changed kmb_dsi_init to drm_bridge_connector_init and drm_connector_attach_encoder to bridge's connector (Sam) call helper_check in plane_atomic_check (Sam) renamed set to get for bpp and format functions(Sam) use drm helper functions for reset, duplicate/destroy state instead of kmb functions (Sam) removed kmb_priv from kmb_plane and removed kmb_plane_state (Sam) Anitha Chrisanthus (4): drm/kmb: Keem Bay driver register definition drm/kmb: Add support for KeemBay Display drm/kmb: Mipi DSI part of the display driver drm/kmb: Build files for KeemBay Display driver drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile|1 + drivers/gpu/drm/kmb/Kconfig | 13 + drivers/gpu/drm/kmb/Makefile|2 + drivers/gpu/drm/kmb/kmb_crtc.c | 224 ++ drivers/gpu/drm/kmb/kmb_drv.c | 676 + drivers/gpu/drm/kmb/kmb_drv.h | 170 + drivers/gpu/drm/kmb/kmb_dsi.c | 1523 +++ drivers/gpu/drm/kmb/kmb_dsi.h | 350 + drivers/gpu/drm/kmb/kmb_plane.c | 480 drivers/gpu/drm/kmb/kmb_plane.h | 110 +++ drivers/gpu/drm/kmb/kmb_regs.h | 748 +++ 12 files changed, 4299 insertions(+) create mode 100644 drivers/gpu/drm/kmb/Kconfig create mode 100644 drivers/gpu/drm/kmb/Makefile create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.h create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h create mode 100644 drivers/gpu/drm/kmb/kmb_regs.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/4] drm/kmb: Build files for KeemBay Display driver
Cc: Sam Ravnborg Signed-off-by: Anitha Chrisanthus Reviewed-by: Bob Paauwe --- drivers/gpu/drm/Kconfig | 2 ++ drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/kmb/Kconfig | 13 + drivers/gpu/drm/kmb/Makefile | 2 ++ 4 files changed, 18 insertions(+) create mode 100644 drivers/gpu/drm/kmb/Kconfig create mode 100644 drivers/gpu/drm/kmb/Makefile diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 147d61b..97a1631b 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -275,6 +275,8 @@ source "drivers/gpu/drm/nouveau/Kconfig" source "drivers/gpu/drm/i915/Kconfig" +source "drivers/gpu/drm/kmb/Kconfig" + config DRM_VGEM tristate "Virtual GEM provider" depends on DRM diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2f31579..2146ff8 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/ obj-$(CONFIG_DRM_MGA) += mga/ obj-$(CONFIG_DRM_I810) += i810/ obj-$(CONFIG_DRM_I915) += i915/ +obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ diff --git a/drivers/gpu/drm/kmb/Kconfig b/drivers/gpu/drm/kmb/Kconfig new file mode 100644 index 000..e18b74c --- /dev/null +++ b/drivers/gpu/drm/kmb/Kconfig @@ -0,0 +1,13 @@ +config DRM_KMB_DISPLAY + tristate "INTEL KEEMBAY DISPLAY" + depends on DRM && OF && (ARM || ARM64) + depends on COMMON_CLK + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + select VIDEOMODE_HELPERS + help + Choose this option if you have Intel's KeemBay SOC which integrates + an ARM Cortex A53 CPU with an Intel Movidius VPU. + + If M is selected the module will be called kmb-drm. diff --git a/drivers/gpu/drm/kmb/Makefile b/drivers/gpu/drm/kmb/Makefile new file mode 100644 index 000..527d737 --- /dev/null +++ b/drivers/gpu/drm/kmb/Makefile @@ -0,0 +1,2 @@ +kmb-drm-y := kmb_crtc.o kmb_drv.o kmb_plane.o kmb_dsi.o +obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb-drm.o -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Parse Colorimetry data block from EDID
On Fri, Aug 28, 2020 at 09:07:13AM +0800, crj wrote:
> Hi Ville Syrjälä,
>
> 在 2020/8/27 18:57, Ville Syrjälä 写道:
> > On Wed, Aug 26, 2020 at 10:23:28PM +0800, Algea Cao wrote:
> >> CEA 861.3 spec adds colorimetry data block for HDMI.
> >> Parsing the block to get the colorimetry data from
> >> panel.
> > And what exactly do you want to do with that data?
>
>
> We can get colorimetry data block from edid then support
>
> HDMI colorimetry such as BT2020.
But what do you want to do with it? The patch does nothing
functional.
>
> >> Signed-off-by: Algea Cao
> >> ---
> >>
> >> drivers/gpu/drm/drm_edid.c | 45 +
> >> include/drm/drm_connector.h | 3 +++
> >> include/drm/drm_edid.h | 14
> >> 3 files changed, 62 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 31496b6cfc56..67e607c04492 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector *connector,
> >> struct edid *edid,
> >> #define VIDEO_BLOCK 0x02
> >> #define VENDOR_BLOCK0x03
> >> #define SPEAKER_BLOCK0x04
> >> +#define COLORIMETRY_DATA_BLOCK0x5
> >> #define HDR_STATIC_METADATA_BLOCK0x6
> >> #define USE_EXTENDED_TAG 0x07
> >> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> >> @@ -4309,6 +4310,48 @@ static void fixup_detailed_cea_mode_clock(struct
> >> drm_display_mode *mode)
> >>mode->clock = clock;
> >> }
> >>
> >> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
> >> +{
> >> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> >> + return false;
> >> +
> >> + if (db[1] != COLORIMETRY_DATA_BLOCK)
> >> + return false;
> >> +
> >> + if (cea_db_payload_len(db) < 2)
> >> + return false;
> >> +
> >> + return true;
> >> +}
> >> +
> >> +static void
> >> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const
> >> u8 *db)
> >> +{
> >> + struct drm_hdmi_info *info = >display_info.hdmi;
> >> +
> >> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
> >> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
> >> + if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
> >> + if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
> >> + if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
> >> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
> >> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
> >> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
> >> + /* Byte 4 Bit 7: DCI-P3 */
> >> + if (db[3] & BIT(7))
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
> >> +
> >> + DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
> >> +}
> >> +
> >> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> >> {
> >>if (cea_db_tag(db) != USE_EXTENDED_TAG)
> >> @@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct drm_connector
> >> *connector,
> >>drm_parse_vcdb(connector, db);
> >>if (cea_db_is_hdmi_hdr_metadata_block(db))
> >>drm_parse_hdr_metadata_block(connector, db);
> >> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> >> + drm_parse_colorimetry_data_block(connector, db);
> >>}
> >> }
> >>
> >> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> >> index af145608b5ed..d599c3b9e881 100644
> >> --- a/include/drm/drm_connector.h
> >> +++ b/include/drm/drm_connector.h
> >> @@ -207,6 +207,9 @@ struct drm_hdmi_info {
> >>
> >>/** @y420_dc_modes: bitmap of deep color support index */
> >>u8 y420_dc_modes;
> >> +
> >> + /* @colorimetry: bitmap of supported colorimetry modes */
> >> + u16 colorimetry;
> >> };
> >>
> >> /**
> >> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> >> index cfa4f5af49af..98fa78c2f82d 100644
> >> --- a/include/drm/drm_edid.h
> >> +++ b/include/drm/drm_edid.h
> >> @@ -229,6 +229,20 @@ struct detailed_timing {
> >>DRM_EDID_YCBCR420_DC_36 | \
> >>DRM_EDID_YCBCR420_DC_30)
> >>
> >> +/*
> >> + * Supported Colorimetry from colorimetry data block
> >> + * as per CEA 861-G spec
> >> + */
> >> +#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
> >> +#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
> >> +#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
> >> +#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
> >> +#define
Re: [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
On Thu, Aug 27, 2020 at 01:04:54PM +0800, Kai Heng Feng wrote:
> Hi Ville,
>
> > On Aug 27, 2020, at 12:24 AM, Ville Syrjälä
> > wrote:
> >
> > On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
> >> LSPCON only supports 8 bpc for RGB/YCbCr444.
> >>
> >> Set the correct bpp otherwise it renders blank screen.
> >
> > Hmm. Does
> > git://github.com/vsyrjala/linux.git dp_downstream_ports_5
> > work?
> >
> > Actually better make that dp_downstream_ports_5^^^ aka.
> > 54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
> > converters") to avoid the experiments and hacks I have sitting on top.
>
> Can you please rebase it to mainline master or drm-tip?
git://github.com/vsyrjala/linux.git dp_downstream_ports_6
I threw out the hacks/experimental stuff.
>
> I am getting errors on the branch:
>
> DESCEND objtool
> CALLscripts/atomic/check-atomics.sh
> CALLscripts/checksyscalls.sh
> CHK include/generated/compile.h
> Building modules, stage 2.
> MODPOST 166 modules
> LD arch/x86/boot/compressed/vmlinux
> ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of
> `__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first
> defined here
> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only
> section `.head.text'
> ld: warning: creating DT_TEXTREL in a PIE
> make[2]: *** [arch/x86/boot/compressed/Makefile:119:
> arch/x86/boot/compressed/vmlinux] Error 1
> make[1]: *** [arch/x86/boot/Makefile:113: arch/x86/boot/compressed/vmlinux]
> Error 2
> make: *** [arch/x86/Makefile:284: bzImage] Error 2
> make: *** Waiting for unfinished jobs
>
> Kai-Heng
>
> >
> >>
> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
> >> Signed-off-by: Kai-Heng Feng
> >> ---
> >> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> index b781bf469644..c7a44fcaade8 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector
> >> *connector,
> >>crtc_state->port_clock /= 2;
> >>crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
> >>crtc_state->lspcon_downsampling = true;
> >> - }
> >> + } else
> >> + crtc_state->pipe_bpp = 24;
> >> }
> >>
> >> static bool lspcon_probe(struct intel_lspcon *lspcon)
> >> --
> >> 2.17.1
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] drm/msm/dp: add hook_plugged_cb hdmi-codec op for MSM DP driver
Add the hook_plugged_cb op for the MSM DP driver to signal connect
and disconnect events to the hdmi-codec driver which in-turn shall
notify the audio subsystem to start a new or teardown an existing
session.
Changes in v2: none
Changes in v3: none
Changes in v4: rebase on top of latest patchset of dependency
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_audio.c | 25 -
drivers/gpu/drm/msm/dp/dp_display.c | 23 +++
drivers/gpu/drm/msm/dp/dp_display.h | 7 +++
3 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
index 75556eea1059..11fa5ad7a801 100644
--- a/drivers/gpu/drm/msm/dp/dp_audio.c
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -10,7 +10,6 @@
#include
#include
-#include
#include "dp_catalog.h"
#include "dp_audio.h"
@@ -442,6 +441,29 @@ static struct dp_audio_private *dp_audio_get_data(struct
platform_device *pdev)
return container_of(dp_audio, struct dp_audio_private, dp_audio);
}
+static int dp_audio_hook_plugged_cb(struct device *dev, void *data,
+ hdmi_codec_plugged_cb fn,
+ struct device *codec_dev)
+{
+
+ struct platform_device *pdev;
+ struct msm_dp *dp_display;
+
+ pdev = to_platform_device(dev);
+ if (!pdev) {
+ pr_err("invalid input\n");
+ return -ENODEV;
+ }
+
+ dp_display = platform_get_drvdata(pdev);
+ if (!dp_display) {
+ pr_err("invalid input\n");
+ return -ENODEV;
+ }
+
+ return dp_display_set_plugged_cb(dp_display, fn, codec_dev);
+}
+
static int dp_audio_get_eld(struct device *dev,
void *data, uint8_t *buf, size_t len)
{
@@ -513,6 +535,7 @@ static const struct hdmi_codec_ops dp_audio_codec_ops = {
.hw_params = dp_audio_hw_params,
.audio_shutdown = dp_audio_shutdown,
.get_eld = dp_audio_get_eld,
+ .hook_plugged_cb = dp_audio_hook_plugged_cb,
};
static struct hdmi_codec_pdata codec_data = {
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 7cf25e151ded..76eb6d765075 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -768,6 +768,13 @@ static int dp_display_prepare(struct msm_dp *dp)
return 0;
}
+static void dp_display_handle_plugged_change(struct msm_dp *dp_display,
+ bool plugged)
+{
+ if (dp_display->plugged_cb && dp_display->codec_dev)
+ dp_display->plugged_cb(dp_display->codec_dev, plugged);
+}
+
static int dp_display_enable(struct dp_display_private *dp, u32 data)
{
int rc = 0;
@@ -798,6 +805,8 @@ static int dp_display_post_enable(struct msm_dp *dp_display)
dp->audio->lane_count = dp->link->link_params.num_lanes;
}
+ /* signal the connect event late to synchronize video and display */
+ dp_display_handle_plugged_change(dp_display, true);
return 0;
}
@@ -820,6 +829,19 @@ static int dp_display_unprepare(struct msm_dp *dp)
return 0;
}
+int dp_display_set_plugged_cb(struct msm_dp *dp_display,
+ hdmi_codec_plugged_cb fn, struct device *codec_dev)
+{
+ bool plugged;
+
+ dp_display->plugged_cb = fn;
+ dp_display->codec_dev = codec_dev;
+ plugged = dp_display->is_connected;
+ dp_display_handle_plugged_change(dp_display, plugged);
+
+ return 0;
+}
+
int dp_display_validate_mode(struct msm_dp *dp, u32 mode_pclk_khz)
{
const u32 num_components = 3, default_bpp = 24;
@@ -1304,6 +1326,7 @@ int msm_dp_display_pre_disable(struct msm_dp *dp, struct
drm_encoder *encoder)
dp_ctrl_push_idle(dp_display->ctrl);
+ dp_display_handle_plugged_change(dp, false);
return 0;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.h
b/drivers/gpu/drm/msm/dp/dp_display.h
index 1e0d2b9d9a2a..5020faf360db 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.h
+++ b/drivers/gpu/drm/msm/dp/dp_display.h
@@ -7,18 +7,25 @@
#define _DP_DISPLAY_H_
#include "dp_panel.h"
+#include
struct msm_dp {
struct drm_device *drm_dev;
+ struct device *codec_dev;
struct drm_connector *connector;
struct drm_encoder *encoder;
bool is_connected;
+
+ hdmi_codec_plugged_cb plugged_cb;
+
u32 max_pclk_khz;
u32 max_dp_lanes;
struct dp_audio *dp_audio;
};
+int dp_display_set_plugged_cb(struct msm_dp *dp_display,
+ hdmi_codec_plugged_cb fn, struct device *codec_dev);
int dp_display_validate_mode(struct msm_dp *dp_display, u32 mode_pclk_khz);
int dp_display_get_modes(struct msm_dp *dp_display,
struct dp_display_mode *dp_mode);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing
[PATCH v4 2/5] drm/msm/dp: add audio support for Display Port on MSM
Introduce audio support for Display Port on MSM chipsets.
This change integrates DP audio sub-module with the main
Display Port platform driver.
In addition, this change leverages hdmi_codec_ops to expose
the operations to the audio driver.
Changes in v2: fix up a compilation issue on drm-next branch
Changes in v3: none
Changes in v4: none
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile| 3 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 +
drivers/gpu/drm/msm/dp/dp_audio.c | 583
drivers/gpu/drm/msm/dp/dp_audio.h | 72 +++
drivers/gpu/drm/msm/dp/dp_catalog.c | 192 +++
drivers/gpu/drm/msm/dp/dp_catalog.h | 29 +
drivers/gpu/drm/msm/dp/dp_display.c | 48 ++
drivers/gpu/drm/msm/dp/dp_display.h | 2 +
8 files changed, 935 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/msm/dp/dp_audio.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_audio.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 6d31188cc776..db1bdd35bbf5 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -111,7 +111,8 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_parser.o \
dp/dp_power.o \
dp/dp_pll.o \
- dp/dp_pll_10nm.o
+ dp/dp_pll_10nm.o \
+ dp/dp_audio.o
msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
msm-$(CONFIG_COMMON_CLK) += disp/mdp4/mdp4_lvds_pll.o
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 292eea6e139e..316da9a8c791 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1139,6 +1139,13 @@ static void _dpu_encoder_virt_enable_helper(struct
drm_encoder *drm_enc)
return;
}
+
+ if (dpu_enc->disp_info.intf_type == DRM_MODE_CONNECTOR_DisplayPort &&
+ dpu_enc->cur_master->hw_mdptop &&
+ dpu_enc->cur_master->hw_mdptop->ops.intf_audio_select)
+ dpu_enc->cur_master->hw_mdptop->ops.intf_audio_select(
+ dpu_enc->cur_master->hw_mdptop);
+
_dpu_encoder_update_vsync_source(dpu_enc, _enc->disp_info);
if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI &&
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
new file mode 100644
index ..75556eea1059
--- /dev/null
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -0,0 +1,583 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2016-2020, The Linux Foundation. All rights reserved.
+ */
+
+
+#define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
+
+#include
+
+#include
+#include
+#include
+
+#include "dp_catalog.h"
+#include "dp_audio.h"
+#include "dp_panel.h"
+#include "dp_display.h"
+
+#define HEADER_BYTE_2_BIT 0
+#define PARITY_BYTE_2_BIT 8
+#define HEADER_BYTE_1_BIT 16
+#define PARITY_BYTE_1_BIT 24
+#define HEADER_BYTE_3_BIT 16
+#define PARITY_BYTE_3_BIT 24
+
+struct dp_audio_private {
+ struct platform_device *audio_pdev;
+ struct platform_device *pdev;
+ struct dp_catalog *catalog;
+ struct dp_panel *panel;
+
+ bool engine_on;
+ u32 channels;
+
+ struct dp_audio dp_audio;
+};
+
+static u8 dp_audio_get_g0_value(u8 data)
+{
+ u8 c[4];
+ u8 g[4];
+ u8 ret_data = 0;
+ u8 i;
+
+ for (i = 0; i < 4; i++)
+ c[i] = (data >> i) & 0x01;
+
+ g[0] = c[3];
+ g[1] = c[0] ^ c[3];
+ g[2] = c[1];
+ g[3] = c[2];
+
+ for (i = 0; i < 4; i++)
+ ret_data = ((g[i] & 0x01) << i) | ret_data;
+
+ return ret_data;
+}
+
+static u8 dp_audio_get_g1_value(u8 data)
+{
+ u8 c[4];
+ u8 g[4];
+ u8 ret_data = 0;
+ u8 i;
+
+ for (i = 0; i < 4; i++)
+ c[i] = (data >> i) & 0x01;
+
+ g[0] = c[0] ^ c[3];
+ g[1] = c[0] ^ c[1] ^ c[3];
+ g[2] = c[1] ^ c[2];
+ g[3] = c[2] ^ c[3];
+
+ for (i = 0; i < 4; i++)
+ ret_data = ((g[i] & 0x01) << i) | ret_data;
+
+ return ret_data;
+}
+
+static u8 dp_audio_calculate_parity(u32 data)
+{
+ u8 x0 = 0;
+ u8 x1 = 0;
+ u8 ci = 0;
+ u8 iData = 0;
+ u8 i = 0;
+ u8 parity_byte;
+ u8 num_byte = (data & 0xFF00) > 0 ? 8 : 2;
+
+ for (i = 0; i < num_byte; i++) {
+ iData = (data >> i*4) & 0xF;
+
+ ci = iData ^ x1;
+ x1 = x0 ^ dp_audio_get_g1_value(ci);
+ x0 = dp_audio_get_g0_value(ci);
+ }
+
+ parity_byte = x1 | (x0 << 4);
+
+ return parity_byte;
+}
+
+static u32 dp_audio_get_header(struct dp_catalog *catalog,
+ enum dp_catalog_audio_sdp_type sdp,
+ enum dp_catalog_audio_header_type header)
+{
+ catalog->sdp_type = sdp;
+ catalog->sdp_header = header;
+
[PATCH v4 4/5] drm/msm/dp: signal the hotplug disconnect in the event handler
Signal the hotplug disconnect event to the audio side in the
event handler so that they are notified earlier and have more
time to process the disconnect event.
Changes in v2: none
Changes in v3: none
Changes in v4: rebase on top of latest patchset of dependency
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_display.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 76eb6d765075..606f44321b0f 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -533,6 +533,13 @@ static int dp_connect_pending_timeout(struct
dp_display_private *dp, u32 data)
return 0;
}
+static void dp_display_handle_plugged_change(struct msm_dp *dp_display,
+ bool plugged)
+{
+ if (dp_display->plugged_cb && dp_display->codec_dev)
+ dp_display->plugged_cb(dp_display->codec_dev, plugged);
+}
+
static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data)
{
struct dp_usbpd *hpd = dp->usbpd;
@@ -578,6 +585,9 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
/* start sanity checking */
dp_add_event(dp, EV_DISCONNECT_PENDING_TIMEOUT, 0, 50);
+ /* signal the disconnect event early to ensure proper teardown */
+ dp_display_handle_plugged_change(g_dp_display, false);
+
dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK |
DP_DP_IRQ_HPD_INT_MASK, true);
@@ -768,13 +778,6 @@ static int dp_display_prepare(struct msm_dp *dp)
return 0;
}
-static void dp_display_handle_plugged_change(struct msm_dp *dp_display,
- bool plugged)
-{
- if (dp_display->plugged_cb && dp_display->codec_dev)
- dp_display->plugged_cb(dp_display->codec_dev, plugged);
-}
-
static int dp_display_enable(struct dp_display_private *dp, u32 data)
{
int rc = 0;
@@ -1326,8 +1329,6 @@ int msm_dp_display_pre_disable(struct msm_dp *dp, struct
drm_encoder *encoder)
dp_ctrl_push_idle(dp_display->ctrl);
- dp_display_handle_plugged_change(dp, false);
-
return 0;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] drm/msm/dp: store dp_display in the driver data
Store the dp_display in the platform driver data instead of the
dp_display_private.
This is required to allow other sub-modules to reuse the platform
driver data.
Changes in v3: none
Changes in v4: none
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_display.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index d584d415ad6e..5e779e29c3da 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -173,11 +173,11 @@ static int dp_display_bind(struct device *dev, struct
device *master,
struct dp_display_private *dp;
struct drm_device *drm;
struct msm_drm_private *priv;
- struct platform_device *pdev = to_platform_device(dev);
drm = dev_get_drvdata(master);
- dp = platform_get_drvdata(pdev);
+ dp = container_of(g_dp_display,
+ struct dp_display_private, dp_display);
if (!dp) {
DRM_ERROR("DP driver bind failed. Invalid driver data\n");
return -EINVAL;
@@ -212,11 +212,11 @@ static void dp_display_unbind(struct device *dev, struct
device *master,
void *data)
{
struct dp_display_private *dp;
- struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = dev_get_drvdata(master);
struct msm_drm_private *priv = drm->dev_private;
- dp = platform_get_drvdata(pdev);
+ dp = container_of(g_dp_display,
+ struct dp_display_private, dp_display);
if (!dp) {
DRM_ERROR("Invalid DP driver data\n");
return;
@@ -351,7 +351,8 @@ static int dp_display_usbpd_configure_cb(struct device *dev)
goto end;
}
- dp = dev_get_drvdata(dev);
+ dp = container_of(g_dp_display,
+ struct dp_display_private, dp_display);
if (!dp) {
DRM_ERROR("no driver data found\n");
rc = -ENODEV;
@@ -375,7 +376,8 @@ static int dp_display_usbpd_disconnect_cb(struct device
*dev)
int rc = 0;
struct dp_display_private *dp;
- dp = dev_get_drvdata(dev);
+ dp = container_of(g_dp_display,
+ struct dp_display_private, dp_display);
dp_add_event(dp, EV_USER_NOTIFICATION, false, 0);
@@ -427,7 +429,8 @@ static int dp_display_usbpd_attention_cb(struct device *dev)
return -EINVAL;
}
- dp = dev_get_drvdata(dev);
+ dp = container_of(g_dp_display,
+ struct dp_display_private, dp_display);
if (!dp) {
DRM_ERROR("no driver data found\n");
return -ENODEV;
@@ -1053,11 +1056,12 @@ static int dp_display_probe(struct platform_device
*pdev)
return -EPROBE_DEFER;
}
- platform_set_drvdata(pdev, dp);
-
mutex_init(>event_mutex);
+
g_dp_display = >dp_display;
+ platform_set_drvdata(pdev, g_dp_display);
+
rc = component_add(>dev, _display_comp_ops);
if (rc) {
DRM_ERROR("component add failed, rc=%d\n", rc);
@@ -1071,7 +1075,8 @@ static int dp_display_remove(struct platform_device *pdev)
{
struct dp_display_private *dp;
- dp = platform_get_drvdata(pdev);
+ dp = container_of(g_dp_display,
+ struct dp_display_private, dp_display);
dp_display_deinit_sub_modules(dp);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/5] drm/msm/dp: wait for audio notification before disabling clocks
In the current implementation, there is a very small window for
the audio side to safely signal the hdmi_code_shutdown() before
the clocks are disabled.
Add some synchronization between the DP display and DP audio module
to safely disable the clocks to avoid unclocked access from audio
side.
In addition, audio side can open the sound card even if DP monitor
is not connected. Avoid programming hardware registers in this case
and bail out early.
Changes in v4: removed some leftover prints
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_audio.c | 32 +
drivers/gpu/drm/msm/dp/dp_display.c | 28 +
drivers/gpu/drm/msm/dp/dp_display.h | 2 ++
3 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
index 11fa5ad7a801..8e0240047821 100644
--- a/drivers/gpu/drm/msm/dp/dp_audio.c
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -497,8 +497,23 @@ int dp_audio_hw_params(struct device *dev,
int rc = 0;
struct dp_audio_private *audio;
struct platform_device *pdev;
+ struct msm_dp *dp_display;
pdev = to_platform_device(dev);
+ dp_display = platform_get_drvdata(pdev);
+
+ /*
+* there could be cases where sound card can be opened even
+* before OR even when DP is not connected . This can cause
+* unclocked access as the audio subsystem relies on the DP
+* driver to maintain the correct state of clocks. To protect
+* such cases check for connection status and bail out if not
+* connected.
+*/
+ if (!dp_display->is_connected) {
+ rc = -EINVAL;
+ goto end;
+ }
audio = dp_audio_get_data(pdev);
if (IS_ERR(audio)) {
@@ -512,6 +527,8 @@ int dp_audio_hw_params(struct device *dev,
dp_audio_setup_acr(audio);
dp_audio_safe_to_exit_level(audio);
dp_audio_enable(audio, true);
+ dp_display->audio_enabled = true;
+
end:
return rc;
}
@@ -520,15 +537,30 @@ static void dp_audio_shutdown(struct device *dev, void
*data)
{
struct dp_audio_private *audio;
struct platform_device *pdev;
+ struct msm_dp *dp_display;
pdev = to_platform_device(dev);
+ dp_display = platform_get_drvdata(pdev);
audio = dp_audio_get_data(pdev);
if (IS_ERR(audio)) {
DRM_ERROR("failed to get audio data\n");
return;
}
+ /*
+* if audio was not enabled there is no need
+* to execute the shutdown and we can bail out early.
+* This also makes sure that we dont cause an unclocked
+* access when audio subsystem calls this without DP being
+* connected. is_connected cannot be used here as its set
+* to false earlier than this call
+*/
+ if (!dp_display->audio_enabled)
+ return;
+
dp_audio_enable(audio, false);
+ /* signal the dp display to safely shutdown clocks */
+ dp_display_signal_audio_complete(dp_display);
}
static const struct hdmi_codec_ops dp_audio_codec_ops = {
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 606f44321b0f..f0e7abc223f4 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -98,6 +98,9 @@ struct dp_display_private {
struct dp_display_mode dp_mode;
struct msm_dp dp_display;
+ /* wait for audio signaling */
+ struct completion audio_comp;
+
/* event related only access by event thread */
struct mutex event_mutex;
wait_queue_head_t event_q;
@@ -169,6 +172,15 @@ static int dp_del_event(struct dp_display_private
*dp_priv, u32 event)
return 0;
}
+void dp_display_signal_audio_complete(struct msm_dp *dp_display)
+{
+ struct dp_display_private *dp;
+
+ dp = container_of(dp_display, struct dp_display_private, dp_display);
+
+ complete_all(>audio_comp);
+}
+
static int dp_display_bind(struct device *dev, struct device *master,
void *data)
{
@@ -587,6 +599,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
/* signal the disconnect event early to ensure proper teardown */
dp_display_handle_plugged_change(g_dp_display, false);
+ reinit_completion(>audio_comp);
dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK |
DP_DP_IRQ_HPD_INT_MASK, true);
@@ -815,9 +828,22 @@ static int dp_display_post_enable(struct msm_dp
*dp_display)
static int dp_display_disable(struct dp_display_private *dp, u32 data)
{
+ struct msm_dp *dp_display;
+
if (!dp->power_on)
return -EINVAL;
+ dp_display = g_dp_display;
+
+ /* wait only if audio was enabled */
+ if (dp_display->audio_enabled) {
+
[PATCH v4 0/5] add audio support for Display Port on MSM
This series adds audio support for DP on MSM chipsets. It leverages the hdmi-codec interface [1] to communicate between the Display Port driver and the audio subsystem. These changes depend on the series [2] which adds Display Port support to MSM chipsets. [1] https://patchwork.kernel.org/patch/11047883/ [2] https://patchwork.kernel.org/patch/11708677/ changes in v2: - fix up a compilation issue on drm-next branch changes in v3: - add support to synchronize DP driver and audio during shutdown changes in v4: - rebase on top of latest patchset of dependency Abhinav Kumar (5): drm/msm/dp: store dp_display in the driver data drm/msm/dp: add audio support for Display Port on MSM drm/msm/dp: add hook_plugged_cb hdmi-codec op for MSM DP driver drm/msm/dp: signal the hotplug disconnect in the event handler drm/msm/dp: wait for audio notification before disabling clocks drivers/gpu/drm/msm/Makefile| 3 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 + drivers/gpu/drm/msm/dp/dp_audio.c | 638 drivers/gpu/drm/msm/dp/dp_audio.h | 72 +++ drivers/gpu/drm/msm/dp/dp_catalog.c | 192 ++ drivers/gpu/drm/msm/dp/dp_catalog.h | 29 + drivers/gpu/drm/msm/dp/dp_display.c | 127 +++- drivers/gpu/drm/msm/dp/dp_display.h | 11 + 8 files changed, 1067 insertions(+), 12 deletions(-) create mode 100644 drivers/gpu/drm/msm/dp/dp_audio.c create mode 100644 drivers/gpu/drm/msm/dp/dp_audio.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on resume
Hi,
On 8/31/20 3:15 PM, Thierry Reding wrote:
On Mon, Aug 31, 2020 at 01:46:28PM +0200, Hans de Goede wrote:
Hi,
On 8/31/20 1:10 PM, Thierry Reding wrote:
On Sun, Aug 30, 2020 at 02:57:42PM +0200, Hans de Goede wrote:
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consumer
(the i915 driver) was always making duty-cycle changes on resume.
With the conversion of the i915 driver to the atomic PWM API the
driver now only disables/enables the PWM on suspend/resume leaving
the output-freq and duty as is, triggering this problem.
Doesn't this imply that there's another bug at play here? At the PWM API
level you're applying a state and it's up to the driver to ensure that
the hardware state after ->apply() is what the software has requested.
If you only switch the enable state and that doesn't cause period and
duty cycle to be updated it means that your driver isn't writing those
registers when it should be.
Right, the driver was not committing those as it should *on resume*,
that and it skips setting the update bit on the subsequent enable,
which is an optimization which gets removed in 7/17.
Before switching the i915 driver over to atomic, when the LPSS-PWM
was used for the backlight we got the following order on suspend/resume
1. Set duty-cycle to 0%
2. Set enabled to 0
3. Save ctrl reg
4. Power-off PWM controller, it now looses all its state
5. Power-on PWM ctrl
6. Restore ctrl reg (as a single reg write)
7. Set enabled to 1, at this point one would expect the
duty/freq from the restored ctrl-reg to apply, but:
a) The resume code never sets the update bit (which this commit fixes); and
b) On applying the pwm_state with enabled=1 the code applying the
state does this (before setting the enabled bit in the ctrl reg):
if (orig_ctrl != ctrl) {
pwm_lpss_write(pwm, ctrl);
pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
}
and since the restore of the ctrl reg set the old duty/freq the
writes are skipped, so the update bit never gets set.
8. Set duty-cycle to the pre-suspend value (which is not 0)
this does cause a change in the ctrl-reg, so now the update flag
does get set.
Note that 1-2 and 7-8 are both done by the non atomic i915 code,
when moving the i915 code to atomic I decided that having these
2 separate steps here is non-sense, so the new i915 code just
toggles the enable bit. So in essence the new atomic PWM
i915 code drops step 1 and 8.
Dropping steps 8 means that the update bit never gets set and we
end up with the PWM running at its power-on-reset duty cycle.
You are correct in your remark to patch 7/17 that since that removes
the if (orig_ctrl != ctrl) for the writes that now step 7 will be
sufficient to get the PWM to work again. But that only takes the i915
usage into account.
What if the PWM is used through the sysfs userspace API?
Then only steps 3-6 will happen on suspend-resume and without
fixing step 6 to properly restore the PWM controller in its
pre-resume state (this patch) it will once again be running at
its power-on-reset defaults instead of the values from the
restored control register.
Actually PWM's sysfs code has suspend/resume callbacks that basically
make sysfs just a regular consumer of PWMs. So they do end up doing a
pwm_apply_state() on the PWM as well on suspend and restore the state
from before suspend on resume.
This was done very specifically because the suspend/resume order can be
unexpected under some circumstances, so for PWM we really want for the
consumer to always have ultimate control over when precisely the PWM is
restored on resume.
The reason why we did this was because people observed weird glitches on
suspend/resume with different severity. In some cases a backlight would
be resumed before the display controller had had a chance to start
sending frames, causing on-screen corruption in some cases (such as
smart displays) and in other cases a PWM-controller regulator would be
resumed too late or too early, which I think was causing some issue with
the CPUs not working properly on resume.
So I'd prefer not to have any PWM driver save and restore its own
context on suspend/resume, because that's inevitably going to cause
unexpected behaviour at some point. If it's absolutely necessary we can
of course still do that, but I think in that case we need to at least
add a comment in the code about why context save/restore is needed in
this particular case and make it clear that this is not something that
other drivers should copy because they most likely won't be needing it.
Given the above it also doesn't sound to me like there's a real problem,
or at least that the bug is somewhere else. A consumer should always be
responsible for applying the pre-suspend state upon
Re: [PATCH v5 4/4] MAINTAINERS: add files for Mediatek DRM drivers
Hi, Chunfeng: Chunfeng Yun 於 2020年8月31日 週一 上午9:50寫道： > > On Sun, 2020-08-23 at 09:48 +0800, Chun-Kuang Hu wrote: > > Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to > > drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers' > > information. > > > > Signed-off-by: Chun-Kuang Hu > > Reviewed-by: Matthias Brugger > > --- > > MAINTAINERS | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index deaafb617361..191bacf02209 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5793,6 +5793,7 @@ L: dri-devel@lists.freedesktop.org > > S: Supported > > F: Documentation/devicetree/bindings/display/mediatek/ > > F: drivers/gpu/drm/mediatek/ > > +F: drivers/phy/mediatek/phy-mtk-hdmi* > > > > DRM DRIVERS FOR NVIDIA TEGRA > > M: Thierry Reding > > Reviewed-by: Chunfeng Yun > Could you give an 'Acked-by' tag on this patch? So I could apply the whole series into my tree. Regards, Chun-Kuang. > Thanks > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/4] phy: mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek folder
Hi, Chunfeng:
Chunfeng Yun 於 2020年8月31日 週一 上午9:48寫道：
>
> On Mon, 2020-08-31 at 07:03 +0800, Chun-Kuang Hu wrote:
> > Hi, Chunfeng & Kishon:
> >
> > How do you feel about this patch?
> It's fine to me,
>
> Reviewed-by: Chunfeng Yun
>
Could you give an 'Acked-by' tag on this patch? So I could apply the
whole series into my tree.
Regards,
Chun-Kuang.
> Thanks a lot
>
> >
> > Regards,
> > Chun-Kuang.
> >
> > Chun-Kuang Hu 於 2020年8月23日 週日 上午9:48寫道：
> > >
> > > From: CK Hu
> > >
> > > mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> > > more suitable to place a phy driver into phy driver folder, so move
> > > mtk_hdmi_phy driver into phy driver folder.
> > >
> > > Signed-off-by: CK Hu
> > > Signed-off-by: Chun-Kuang Hu
> > > ---
> > > drivers/gpu/drm/mediatek/Kconfig | 7 ---
> > > drivers/gpu/drm/mediatek/Makefile | 6 --
> > > drivers/phy/mediatek/Kconfig | 7 +++
> > > drivers/phy/mediatek/Makefile | 5 +
> > > .../mediatek/phy-mtk-hdmi-mt2701.c}| 2 +-
> > > .../mediatek/phy-mtk-hdmi-mt8173.c}| 2 +-
> > > .../mtk_hdmi_phy.c => phy/mediatek/phy-mtk-hdmi.c} | 2 +-
> > > .../mtk_hdmi_phy.h => phy/mediatek/phy-mtk-hdmi.h} | 0
> > > 8 files changed, 15 insertions(+), 16 deletions(-)
> > > rename drivers/{gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c =>
> > > phy/mediatek/phy-mtk-hdmi-mt2701.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c =>
> > > phy/mediatek/phy-mtk-hdmi-mt8173.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.c =>
> > > phy/mediatek/phy-mtk-hdmi.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.h =>
> > > phy/mediatek/phy-mtk-hdmi.h} (100%)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/Kconfig
> > > b/drivers/gpu/drm/mediatek/Kconfig
> > > index 6363f2c1cdbc..65cd03a4be29 100644
> > > --- a/drivers/gpu/drm/mediatek/Kconfig
> > > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > > @@ -27,10 +27,3 @@ config DRM_MEDIATEK_HDMI
> > > select PHY_MTK_HDMI
> > > help
> > > DRM/KMS HDMI driver for Mediatek SoCs
> > > -
> > > -config PHY_MTK_HDMI
> > > - tristate "MediaTek HDMI-PHY Driver"
> > > - depends on ARCH_MEDIATEK && OF
> > > - select GENERIC_PHY
> > > - help
> > > - Support HDMI PHY for Mediatek SoCs.
> > > diff --git a/drivers/gpu/drm/mediatek/Makefile
> > > b/drivers/gpu/drm/mediatek/Makefile
> > > index fcbef23aa6ce..77b0fd86063d 100644
> > > --- a/drivers/gpu/drm/mediatek/Makefile
> > > +++ b/drivers/gpu/drm/mediatek/Makefile
> > > @@ -22,9 +22,3 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
> > > mtk_hdmi_ddc.o
> > >
> > > obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> > > -
> > > -phy-mtk-hdmi-drv-objs := mtk_hdmi_phy.o \
> > > -mtk_mt2701_hdmi_phy.o \
> > > -mtk_mt8173_hdmi_phy.o
> > > -
> > > -obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> > > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> > > index dee757c957f2..50c5e9306e19 100644
> > > --- a/drivers/phy/mediatek/Kconfig
> > > +++ b/drivers/phy/mediatek/Kconfig
> > > @@ -35,3 +35,10 @@ config PHY_MTK_XSPHY
> > > Enable this to support the SuperSpeedPlus XS-PHY transceiver for
> > > USB3.1 GEN2 controllers on MediaTek chips. The driver supports
> > > multiple USB2.0, USB3.1 GEN2 ports.
> > > +
> > > +config PHY_MTK_HDMI
> > > + tristate "MediaTek HDMI-PHY Driver"
> > > + depends on ARCH_MEDIATEK && OF
> > > + select GENERIC_PHY
> > > + help
> > > + Support HDMI PHY for Mediatek SoCs.
> > > diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> > > index 08a8e6a97b1e..6325e38709ed 100644
> > > --- a/drivers/phy/mediatek/Makefile
> > > +++ b/drivers/phy/mediatek/Makefile
> > > @@ -6,3 +6,8 @@
> > > obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> > > obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o
> > > obj-$(CONFIG_PHY_MTK_XSPHY)+= phy-mtk-xsphy.o
> > > +
> > > +phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> > > +phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> > > +phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8173.o
> > > +obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> > > similarity index 99%
> > > rename from drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > rename to drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> > > index 99fe05cd3598..a6cb1dea3d0c 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> > > @@ -4,7 +4,7 @@
> > > * Author:
[PATCH AUTOSEL 4.14 3/9] drm/msm: add shutdown support for display platform_driver
From: Krishna Manikandan
[ Upstream commit 9d5cbf5fe46e350715389d89d0c350d83289a102 ]
Define shutdown callback for display drm driver,
so as to disable all the CRTCS when shutdown
notification is received by the driver.
This change will turn off the timing engine so
that no display transactions are requested
while mmu translations are getting disabled
during reboot sequence.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Remove NULL check from msm_pdev_shutdown (Stephen Boyd)
- Change commit text to reflect when this issue
was uncovered (Sai Prakash Ranjan)
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d9c0687435a05..c59240b566d83 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1134,6 +1134,13 @@ static int msm_pdev_remove(struct platform_device *pdev)
return 0;
}
+static void msm_pdev_shutdown(struct platform_device *pdev)
+{
+ struct drm_device *drm = platform_get_drvdata(pdev);
+
+ drm_atomic_helper_shutdown(drm);
+}
+
static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdp4", .data = (void *)4 }, /* MDP4 */
{ .compatible = "qcom,mdss", .data = (void *)5 }, /* MDP5 MDSS */
@@ -1144,6 +1151,7 @@ MODULE_DEVICE_TABLE(of, dt_match);
static struct platform_driver msm_platform_driver = {
.probe = msm_pdev_probe,
.remove = msm_pdev_remove,
+ .shutdown = msm_pdev_shutdown,
.driver = {
.name = "msm",
.of_match_table = dt_match,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 09/23] drm/msm: enable vblank during atomic commits
From: Rob Clark
[ Upstream commit 43906812eaab06423f56af5cca9a9fcdbb4ac454 ]
This has roughly the same effect as drm_atomic_helper_wait_for_vblanks(),
basically just ensuring that vblank accounting is enabled so that we get
valid timestamp/seqn on pageflip events.
Signed-off-by: Rob Clark
Tested-by: Stephen Boyd
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_atomic.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 5ccfad794c6a5..561bfa48841c3 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -27,6 +27,34 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
return msm_framebuffer_prepare(new_state->fb, kms->aspace);
}
+/*
+ * Helpers to control vblanks while we flush.. basically just to ensure
+ * that vblank accounting is switched on, so we get valid seqn/timestamp
+ * on pageflip events (if requested)
+ */
+
+static void vblank_get(struct msm_kms *kms, unsigned crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ if (!crtc->state->active)
+ continue;
+ drm_crtc_vblank_get(crtc);
+ }
+}
+
+static void vblank_put(struct msm_kms *kms, unsigned crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ if (!crtc->state->active)
+ continue;
+ drm_crtc_vblank_put(crtc);
+ }
+}
+
static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
{
unsigned crtc_mask = BIT(crtc_idx);
@@ -44,6 +72,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
kms->funcs->enable_commit(kms);
+ vblank_get(kms, crtc_mask);
+
/*
* Flush hardware updates:
*/
@@ -58,6 +88,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
+ vblank_put(kms, crtc_mask);
+
mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
mutex_unlock(>commit_lock);
@@ -221,6 +253,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
*/
kms->pending_crtc_mask &= ~crtc_mask;
+ vblank_get(kms, crtc_mask);
+
/*
* Flush hardware updates:
*/
@@ -235,6 +269,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
+ vblank_put(kms, crtc_mask);
+
mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
mutex_unlock(>commit_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 07/11] drm/msm/a6xx: fix gmu start on newer firmware
From: Dmitry Baryshkov
[ Upstream commit f5749d6181fa7df5ae741788e5d96f593d3a60b6 ]
New Qualcomm firmware has changed a way it reports back the 'started'
event. Support new register values.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 9cde79a7335c8..739ca9c2081a6 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -117,12 +117,22 @@ static int a6xx_gmu_start(struct a6xx_gmu *gmu)
{
int ret;
u32 val;
+ u32 mask, reset_val;
+
+ val = gmu_read(gmu, REG_A6XX_GMU_CM3_DTCM_START + 0xff8);
+ if (val <= 0x20010004) {
+ mask = 0x;
+ reset_val = 0xbabeface;
+ } else {
+ mask = 0x1ff;
+ reset_val = 0x100;
+ }
gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 1);
gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 0);
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_CM3_FW_INIT_RESULT, val,
- val == 0xbabeface, 100, 1);
+ (val & mask) == reset_val, 100, 1);
if (ret)
dev_err(gmu->dev, "GMU firmware initialization timed out\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 20/23] drm/amd/display: Retry AUX write when fail occurs
From: Wayne Lin [ Upstream commit ef67d792a2fc578319399f605fbec2f99ecc06ea ] [Why] In dm_dp_aux_transfer() now, we forget to handle AUX_WR fail cases. We suppose every write wil get done successfully and hence some AUX commands might not sent out indeed. [How] Check if AUX_WR success. If not, retry it. Signed-off-by: Wayne Lin Reviewed-by: Hersen Wu Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index 28a6c7b2ef4bb..2f858507ca702 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -101,7 +101,7 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux, result = dc_link_aux_transfer_raw(TO_DM_AUX(aux)->ddc_service, , _result); - if (payload.write) + if (payload.write && result >= 0) result = msg->size; if (result < 0) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 39/42] drm/amd/display: Retry AUX write when fail occurs
From: Wayne Lin [ Upstream commit ef67d792a2fc578319399f605fbec2f99ecc06ea ] [Why] In dm_dp_aux_transfer() now, we forget to handle AUX_WR fail cases. We suppose every write wil get done successfully and hence some AUX commands might not sent out indeed. [How] Check if AUX_WR success. If not, retry it. Signed-off-by: Wayne Lin Reviewed-by: Hersen Wu Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index e5ecc5affa1eb..5098fc98cc255 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -67,7 +67,7 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux, result = dc_link_aux_transfer_raw(TO_DM_AUX(aux)->ddc_service, , _result); - if (payload.write) + if (payload.write && result >= 0) result = msg->size; if (result < 0) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 03/23] drm/msm/dpu: Fix scale params in plane validation
From: Kalyan Thota
[ Upstream commit 4c978caf08aa155bdeadd9e2d4b026d4ce97ebd0 ]
Plane validation uses an API drm_calc_scale which will
return src/dst value as a scale ratio.
when viewing the range on a scale the values should fall in as
Upscale ratio < Unity scale < Downscale ratio for src/dst formula
Fix the min and max scale ratios to suit the API accordingly.
Signed-off-by: Kalyan Thota
Tested-by: Kristian H. Kristensen
Reviewed-by: Kristian H. Kristensen
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 58d5acbcfc5c2..b984bafd27e25 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -853,9 +853,9 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
crtc_state = drm_atomic_get_new_crtc_state(state->state,
state->crtc);
- min_scale = FRAC_16_16(1, pdpu->pipe_sblk->maxdwnscale);
+ min_scale = FRAC_16_16(1, pdpu->pipe_sblk->maxupscale);
ret = drm_atomic_helper_check_plane_state(state, crtc_state, min_scale,
- pdpu->pipe_sblk->maxupscale << 16,
+ pdpu->pipe_sblk->maxdwnscale << 16,
true, true);
if (ret) {
DPU_ERROR_PLANE(pdpu, "Check plane state failed (%d)\n", ret);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 04/11] drm/msm: add shutdown support for display platform_driver
From: Krishna Manikandan
[ Upstream commit 9d5cbf5fe46e350715389d89d0c350d83289a102 ]
Define shutdown callback for display drm driver,
so as to disable all the CRTCS when shutdown
notification is received by the driver.
This change will turn off the timing engine so
that no display transactions are requested
while mmu translations are getting disabled
during reboot sequence.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Remove NULL check from msm_pdev_shutdown (Stephen Boyd)
- Change commit text to reflect when this issue
was uncovered (Sai Prakash Ranjan)
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 6f81de85fb860..7f45486b6650b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1358,6 +1358,13 @@ static int msm_pdev_remove(struct platform_device *pdev)
return 0;
}
+static void msm_pdev_shutdown(struct platform_device *pdev)
+{
+ struct drm_device *drm = platform_get_drvdata(pdev);
+
+ drm_atomic_helper_shutdown(drm);
+}
+
static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
@@ -1369,6 +1376,7 @@ MODULE_DEVICE_TABLE(of, dt_match);
static struct platform_driver msm_platform_driver = {
.probe = msm_pdev_probe,
.remove = msm_pdev_remove,
+ .shutdown = msm_pdev_shutdown,
.driver = {
.name = "msm",
.of_match_table = dt_match,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 14/23] drm/omap: fix incorrect lock state
From: Tomi Valkeinen
[ Upstream commit 7fd5b25499bcec157dd4de9a713425efcf4571cd ]
After commit 92cc68e35863c1c61c449efa2b2daef6e9926048 ("drm/vblank: Use
spin_(un)lock_irq() in drm_crtc_vblank_on()") omapdrm locking is broken:
WARNING: inconsistent lock state
5.8.0-rc2-00483-g92cc68e35863 #13 Tainted: GW
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
ea98222c (>event_lock#2){?.+.}-{2:2}, at: drm_handle_vblank+0x4c/0x520
[drm]
{HARDIRQ-ON-W} state was registered at:
trace_hardirqs_on+0x9c/0x1ec
_raw_spin_unlock_irq+0x20/0x58
omap_crtc_atomic_enable+0x54/0xa0 [omapdrm]
drm_atomic_helper_commit_modeset_enables+0x218/0x270 [drm_kms_helper]
omap_atomic_commit_tail+0x48/0xc4 [omapdrm]
commit_tail+0x9c/0x190 [drm_kms_helper]
drm_atomic_helper_commit+0x154/0x188 [drm_kms_helper]
drm_client_modeset_commit_atomic+0x228/0x268 [drm]
drm_client_modeset_commit_locked+0x60/0x1d0 [drm]
drm_client_modeset_commit+0x24/0x40 [drm]
drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa8 [drm_kms_helper]
drm_fb_helper_set_par+0x2c/0x5c [drm_kms_helper]
drm_fb_helper_hotplug_event.part.0+0xa0/0xbc [drm_kms_helper]
drm_kms_helper_hotplug_event+0x24/0x30 [drm_kms_helper]
output_poll_execute+0x1a8/0x1c0 [drm_kms_helper]
process_one_work+0x268/0x800
worker_thread+0x30/0x4e0
kthread+0x164/0x190
ret_from_fork+0x14/0x20
The reason for this is that omapdrm calls drm_crtc_vblank_on() while
holding event_lock taken with spin_lock_irq().
It is not clear why drm_crtc_vblank_on() and drm_crtc_vblank_get() are
called while holding event_lock. I don't see any problem with moving
those calls outside the lock, which is what this patch does.
Signed-off-by: Tomi Valkeinen
Link:
https://patchwork.freedesktop.org/patch/msgid/20200819103021.440288-1-tomi.valkei...@ti.com
Reviewed-by: Laurent Pinchart
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 3c5ddbf30e974..f5e18802e7bc6 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -451,11 +451,12 @@ static void omap_crtc_atomic_enable(struct drm_crtc *crtc,
if (omap_state->manually_updated)
return;
- spin_lock_irq(>dev->event_lock);
drm_crtc_vblank_on(crtc);
+
ret = drm_crtc_vblank_get(crtc);
WARN_ON(ret != 0);
+ spin_lock_irq(>dev->event_lock);
omap_crtc_arm_event(crtc);
spin_unlock_irq(>dev->event_lock);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 12/23] drm/msm/a6xx: fix gmu start on newer firmware
From: Dmitry Baryshkov
[ Upstream commit f5749d6181fa7df5ae741788e5d96f593d3a60b6 ]
New Qualcomm firmware has changed a way it reports back the 'started'
event. Support new register values.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 9ea748667fab0..40431a09dc97c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -199,12 +199,22 @@ static int a6xx_gmu_start(struct a6xx_gmu *gmu)
{
int ret;
u32 val;
+ u32 mask, reset_val;
+
+ val = gmu_read(gmu, REG_A6XX_GMU_CM3_DTCM_START + 0xff8);
+ if (val <= 0x20010004) {
+ mask = 0x;
+ reset_val = 0xbabeface;
+ } else {
+ mask = 0x1ff;
+ reset_val = 0x100;
+ }
gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 1);
gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 0);
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_CM3_FW_INIT_RESULT, val,
- val == 0xbabeface, 100, 1);
+ (val & mask) == reset_val, 100, 1);
if (ret)
DRM_DEV_ERROR(gmu->dev, "GMU firmware initialization timed
out\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 40/42] drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init
From: Dinghao Liu
[ Upstream commit b67a468a4ccef593cd8df6a02ba3d167b77f0c81 ]
When amdgpu_display_modeset_create_props() fails, state and
state->context should be freed to prevent memleak. It's the
same when amdgpu_dm_audio_init() fails.
Signed-off-by: Dinghao Liu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0682fd363cb50..580c17c95a1d8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2822,12 +2822,18 @@ static int amdgpu_dm_mode_config_init(struct
amdgpu_device *adev)
_atomic_state_funcs);
r = amdgpu_display_modeset_create_props(adev);
- if (r)
+ if (r) {
+ dc_release_state(state->context);
+ kfree(state);
return r;
+ }
r = amdgpu_dm_audio_init(adev);
- if (r)
+ if (r) {
+ dc_release_state(state->context);
+ kfree(state);
return r;
+ }
return 0;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 18/23] drm/amd/display: Reject overlay plane configurations in multi-display scenarios
From: Nicholas Kazlauskas
[ Upstream commit 168f09cdadbd547c2b202246ef9a8183da725f13 ]
[Why]
These aren't stable on some platform configurations when driving
multiple displays, especially on higher resolution.
In particular the delay in asserting p-state and validating from
x86 outweights any power or performance benefit from the hardware
composition.
Under some configurations this will manifest itself as extreme stutter
or unresponsiveness especially when combined with cursor movement.
[How]
Disable these for now. Exposing overlays to userspace doesn't guarantee
that they'll be able to use them in any and all configurations and it's
part of the DRM contract to have userspace gracefully handle validation
failures when they occur.
Valdiation occurs as part of DC and this in particular affects RV, so
disable this in dcn10_global_validation.
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Hersen Wu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
index 1599bb971..e860ae05feda1 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
@@ -1151,6 +1151,7 @@ static enum dc_status dcn10_validate_global(struct dc
*dc, struct dc_state *cont
bool video_large = false;
bool desktop_large = false;
bool dcc_disabled = false;
+ bool mpo_enabled = false;
for (i = 0; i < context->stream_count; i++) {
if (context->stream_status[i].plane_count == 0)
@@ -1159,6 +1160,9 @@ static enum dc_status dcn10_validate_global(struct dc
*dc, struct dc_state *cont
if (context->stream_status[i].plane_count > 2)
return DC_FAIL_UNSUPPORTED_1;
+ if (context->stream_status[i].plane_count > 1)
+ mpo_enabled = true;
+
for (j = 0; j < context->stream_status[i].plane_count; j++) {
struct dc_plane_state *plane =
context->stream_status[i].plane_states[j];
@@ -1182,6 +1186,10 @@ static enum dc_status dcn10_validate_global(struct dc
*dc, struct dc_state *cont
}
}
+ /* Disable MPO in multi-display configurations. */
+ if (context->stream_count > 1 && mpo_enabled)
+ return DC_FAIL_UNSUPPORTED_1;
+
/*
* Workaround: On DCN10 there is UMC issue that causes underflow when
* playing 4k video on 4k desktop with video downscaled and single
channel
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 21/23] drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init
From: Dinghao Liu
[ Upstream commit b67a468a4ccef593cd8df6a02ba3d167b77f0c81 ]
When amdgpu_display_modeset_create_props() fails, state and
state->context should be freed to prevent memleak. It's the
same when amdgpu_dm_audio_init() fails.
Signed-off-by: Dinghao Liu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 526e4161df454..2da040c1876dd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2043,12 +2043,18 @@ static int amdgpu_dm_mode_config_init(struct
amdgpu_device *adev)
_atomic_state_funcs);
r = amdgpu_display_modeset_create_props(adev);
- if (r)
+ if (r) {
+ dc_release_state(state->context);
+ kfree(state);
return r;
+ }
r = amdgpu_dm_audio_init(adev);
- if (r)
+ if (r) {
+ dc_release_state(state->context);
+ kfree(state);
return r;
+ }
return 0;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 06/23] drm/msm: add shutdown support for display platform_driver
From: Krishna Manikandan
[ Upstream commit 9d5cbf5fe46e350715389d89d0c350d83289a102 ]
Define shutdown callback for display drm driver,
so as to disable all the CRTCS when shutdown
notification is received by the driver.
This change will turn off the timing engine so
that no display transactions are requested
while mmu translations are getting disabled
during reboot sequence.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Remove NULL check from msm_pdev_shutdown (Stephen Boyd)
- Change commit text to reflect when this issue
was uncovered (Sai Prakash Ranjan)
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index b73fbb65e14b2..4558d66761b3c 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1321,6 +1321,13 @@ static int msm_pdev_remove(struct platform_device *pdev)
return 0;
}
+static void msm_pdev_shutdown(struct platform_device *pdev)
+{
+ struct drm_device *drm = platform_get_drvdata(pdev);
+
+ drm_atomic_helper_shutdown(drm);
+}
+
static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
@@ -1332,6 +1339,7 @@ MODULE_DEVICE_TABLE(of, dt_match);
static struct platform_driver msm_platform_driver = {
.probe = msm_pdev_probe,
.remove = msm_pdev_remove,
+ .shutdown = msm_pdev_shutdown,
.driver = {
.name = "msm",
.of_match_table = dt_match,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 37/42] drm/amd/display: Fix passive dongle mistaken as active dongle in EDID emulation
From: Samson Tam [ Upstream commit efbde23a3b0164cef27fd394e7d548f46af5b51d ] [Why] dongle_type is set during dongle connection but for passive dongles, dongle_type is not set. If user starts with an active dongle and then switches to a passive dongle, it will still report as an active dongle. Trying to emulate the wrong connecter type results in display not lighting up. [How] Set dpcd_caps.dongle_type for passive dongles in detect_dp(). Signed-off-by: Samson Tam Reviewed-by: Joshua Aberback Acked-by: Eryk Brol Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index bdddb46727b1f..885beb0bcc199 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -767,6 +767,7 @@ static bool detect_dp(struct dc_link *link, sink_caps->signal = dp_passive_dongle_detection(link->ddc, sink_caps, audio_support); + link->dpcd_caps.dongle_type = sink_caps->dongle_type; } return true; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 19/23] drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in amdgpu_dm_update_backlight_caps
From: Furquan Shaikh [ Upstream commit 5896585512e5156482335e902f7c7393b940da51 ] In `amdgpu_dm_update_backlight_caps()`, there is a local `amdgpu_dm_backlight_caps` object that is filled in by `amdgpu_acpi_get_backlight_caps()`. However, this object is uninitialized before the call and hence the subsequent check for aux_support can fail since it is not initialized by `amdgpu_acpi_get_backlight_caps()` as well. This change initializes this local `amdgpu_dm_backlight_caps` object to 0. Reviewed-by: Christian König Signed-off-by: Furquan Shaikh Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 2c0eb7140ca0e..526e4161df454 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2064,6 +2064,8 @@ static void amdgpu_dm_update_backlight_caps(struct amdgpu_display_manager *dm) #if defined(CONFIG_ACPI) struct amdgpu_dm_backlight_caps caps; + memset(, 0, sizeof(caps)); + if (dm->backlight_caps.caps_valid) return; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 38/42] drm/amd/display: Keep current gain when ABM disable immediately
From: Brandon Syu
[ Upstream commit cba4b52e431e5de3d8012281cfe194f1c39a9052 ]
[Why]
When system enters s3/s0i3, backlight PWM would set user level.
[How]
ABM disable function add keep current gain to avoid it.
Signed-off-by: Brandon Syu
Reviewed-by: Josip Pavic
Acked-by: Eryk Brol
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dc_stream.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_stream.h
b/drivers/gpu/drm/amd/display/dc/dc_stream.h
index 49aad691e687e..ccac2315a903a 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_stream.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_stream.h
@@ -222,7 +222,7 @@ struct dc_stream_state {
union stream_update_flags update_flags;
};
-#define ABM_LEVEL_IMMEDIATE_DISABLE 0x
+#define ABM_LEVEL_IMMEDIATE_DISABLE 255
struct dc_stream_update {
struct dc_stream_state *stream;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 34/42] drm/amd/display: Reject overlay plane configurations in multi-display scenarios
From: Nicholas Kazlauskas
[ Upstream commit 168f09cdadbd547c2b202246ef9a8183da725f13 ]
[Why]
These aren't stable on some platform configurations when driving
multiple displays, especially on higher resolution.
In particular the delay in asserting p-state and validating from
x86 outweights any power or performance benefit from the hardware
composition.
Under some configurations this will manifest itself as extreme stutter
or unresponsiveness especially when combined with cursor movement.
[How]
Disable these for now. Exposing overlays to userspace doesn't guarantee
that they'll be able to use them in any and all configurations and it's
part of the DRM contract to have userspace gracefully handle validation
failures when they occur.
Valdiation occurs as part of DC and this in particular affects RV, so
disable this in dcn10_global_validation.
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Hersen Wu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
index 17d5cb422025e..8939541ad7afc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
@@ -1213,6 +1213,7 @@ static enum dc_status dcn10_validate_global(struct dc
*dc, struct dc_state *cont
bool video_large = false;
bool desktop_large = false;
bool dcc_disabled = false;
+ bool mpo_enabled = false;
for (i = 0; i < context->stream_count; i++) {
if (context->stream_status[i].plane_count == 0)
@@ -1221,6 +1222,9 @@ static enum dc_status dcn10_validate_global(struct dc
*dc, struct dc_state *cont
if (context->stream_status[i].plane_count > 2)
return DC_FAIL_UNSUPPORTED_1;
+ if (context->stream_status[i].plane_count > 1)
+ mpo_enabled = true;
+
for (j = 0; j < context->stream_status[i].plane_count; j++) {
struct dc_plane_state *plane =
context->stream_status[i].plane_states[j];
@@ -1244,6 +1248,10 @@ static enum dc_status dcn10_validate_global(struct dc
*dc, struct dc_state *cont
}
}
+ /* Disable MPO in multi-display configurations. */
+ if (context->stream_count > 1 && mpo_enabled)
+ return DC_FAIL_UNSUPPORTED_1;
+
/*
* Workaround: On DCN10 there is UMC issue that causes underflow when
* playing 4k video on 4k desktop with video downscaled and single
channel
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 06/42] drm/msm/dpu: fix unitialized variable error
From: Rob Clark
[ Upstream commit 35c719da95c0d28560bff7bafeaf07ebb212665e ]
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:817 dpu_crtc_enable() error:
uninitialized symbol 'request_bandwidth'.
Reported-by: kernel test robot
Signed-off-by: Rob Clark
Reviewed-by: Sean Paul
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 969d95aa873c4..1026e1e5bec10 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -827,7 +827,7 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
{
struct dpu_crtc *dpu_crtc;
struct drm_encoder *encoder;
- bool request_bandwidth;
+ bool request_bandwidth = false;
if (!crtc) {
DPU_ERROR("invalid crtc\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 09/42] drm/msm: add shutdown support for display platform_driver
From: Krishna Manikandan
[ Upstream commit 9d5cbf5fe46e350715389d89d0c350d83289a102 ]
Define shutdown callback for display drm driver,
so as to disable all the CRTCS when shutdown
notification is received by the driver.
This change will turn off the timing engine so
that no display transactions are requested
while mmu translations are getting disabled
during reboot sequence.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Remove NULL check from msm_pdev_shutdown (Stephen Boyd)
- Change commit text to reflect when this issue
was uncovered (Sai Prakash Ranjan)
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index f6ce40bf36998..b4d61af7a104e 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1328,6 +1328,13 @@ static int msm_pdev_remove(struct platform_device *pdev)
return 0;
}
+static void msm_pdev_shutdown(struct platform_device *pdev)
+{
+ struct drm_device *drm = platform_get_drvdata(pdev);
+
+ drm_atomic_helper_shutdown(drm);
+}
+
static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
@@ -1340,6 +1347,7 @@ MODULE_DEVICE_TABLE(of, dt_match);
static struct platform_driver msm_platform_driver = {
.probe = msm_pdev_probe,
.remove = msm_pdev_remove,
+ .shutdown = msm_pdev_shutdown,
.driver = {
.name = "msm",
.of_match_table = dt_match,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 28/42] drm/omap: fix incorrect lock state
From: Tomi Valkeinen
[ Upstream commit 7fd5b25499bcec157dd4de9a713425efcf4571cd ]
After commit 92cc68e35863c1c61c449efa2b2daef6e9926048 ("drm/vblank: Use
spin_(un)lock_irq() in drm_crtc_vblank_on()") omapdrm locking is broken:
WARNING: inconsistent lock state
5.8.0-rc2-00483-g92cc68e35863 #13 Tainted: GW
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
ea98222c (>event_lock#2){?.+.}-{2:2}, at: drm_handle_vblank+0x4c/0x520
[drm]
{HARDIRQ-ON-W} state was registered at:
trace_hardirqs_on+0x9c/0x1ec
_raw_spin_unlock_irq+0x20/0x58
omap_crtc_atomic_enable+0x54/0xa0 [omapdrm]
drm_atomic_helper_commit_modeset_enables+0x218/0x270 [drm_kms_helper]
omap_atomic_commit_tail+0x48/0xc4 [omapdrm]
commit_tail+0x9c/0x190 [drm_kms_helper]
drm_atomic_helper_commit+0x154/0x188 [drm_kms_helper]
drm_client_modeset_commit_atomic+0x228/0x268 [drm]
drm_client_modeset_commit_locked+0x60/0x1d0 [drm]
drm_client_modeset_commit+0x24/0x40 [drm]
drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa8 [drm_kms_helper]
drm_fb_helper_set_par+0x2c/0x5c [drm_kms_helper]
drm_fb_helper_hotplug_event.part.0+0xa0/0xbc [drm_kms_helper]
drm_kms_helper_hotplug_event+0x24/0x30 [drm_kms_helper]
output_poll_execute+0x1a8/0x1c0 [drm_kms_helper]
process_one_work+0x268/0x800
worker_thread+0x30/0x4e0
kthread+0x164/0x190
ret_from_fork+0x14/0x20
The reason for this is that omapdrm calls drm_crtc_vblank_on() while
holding event_lock taken with spin_lock_irq().
It is not clear why drm_crtc_vblank_on() and drm_crtc_vblank_get() are
called while holding event_lock. I don't see any problem with moving
those calls outside the lock, which is what this patch does.
Signed-off-by: Tomi Valkeinen
Link:
https://patchwork.freedesktop.org/patch/msgid/20200819103021.440288-1-tomi.valkei...@ti.com
Reviewed-by: Laurent Pinchart
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index fce7e944a280b..dbf91b3fd6f08 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -451,11 +451,12 @@ static void omap_crtc_atomic_enable(struct drm_crtc *crtc,
if (omap_state->manually_updated)
return;
- spin_lock_irq(>dev->event_lock);
drm_crtc_vblank_on(crtc);
+
ret = drm_crtc_vblank_get(crtc);
WARN_ON(ret != 0);
+ spin_lock_irq(>dev->event_lock);
omap_crtc_arm_event(crtc);
spin_unlock_irq(>dev->event_lock);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 13/42] drm/msm: enable vblank during atomic commits
From: Rob Clark
[ Upstream commit 43906812eaab06423f56af5cca9a9fcdbb4ac454 ]
This has roughly the same effect as drm_atomic_helper_wait_for_vblanks(),
basically just ensuring that vblank accounting is enabled so that we get
valid timestamp/seqn on pageflip events.
Signed-off-by: Rob Clark
Tested-by: Stephen Boyd
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_atomic.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 5ccfad794c6a5..561bfa48841c3 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -27,6 +27,34 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
return msm_framebuffer_prepare(new_state->fb, kms->aspace);
}
+/*
+ * Helpers to control vblanks while we flush.. basically just to ensure
+ * that vblank accounting is switched on, so we get valid seqn/timestamp
+ * on pageflip events (if requested)
+ */
+
+static void vblank_get(struct msm_kms *kms, unsigned crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ if (!crtc->state->active)
+ continue;
+ drm_crtc_vblank_get(crtc);
+ }
+}
+
+static void vblank_put(struct msm_kms *kms, unsigned crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ if (!crtc->state->active)
+ continue;
+ drm_crtc_vblank_put(crtc);
+ }
+}
+
static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
{
unsigned crtc_mask = BIT(crtc_idx);
@@ -44,6 +72,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
kms->funcs->enable_commit(kms);
+ vblank_get(kms, crtc_mask);
+
/*
* Flush hardware updates:
*/
@@ -58,6 +88,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
+ vblank_put(kms, crtc_mask);
+
mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
mutex_unlock(>commit_lock);
@@ -221,6 +253,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
*/
kms->pending_crtc_mask &= ~crtc_mask;
+ vblank_get(kms, crtc_mask);
+
/*
* Flush hardware updates:
*/
@@ -235,6 +269,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
+ vblank_put(kms, crtc_mask);
+
mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
mutex_unlock(>commit_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 35/42] drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in amdgpu_dm_update_backlight_caps
From: Furquan Shaikh [ Upstream commit 5896585512e5156482335e902f7c7393b940da51 ] In `amdgpu_dm_update_backlight_caps()`, there is a local `amdgpu_dm_backlight_caps` object that is filled in by `amdgpu_acpi_get_backlight_caps()`. However, this object is uninitialized before the call and hence the subsequent check for aux_support can fail since it is not initialized by `amdgpu_acpi_get_backlight_caps()` as well. This change initializes this local `amdgpu_dm_backlight_caps` object to 0. Reviewed-by: Christian König Signed-off-by: Furquan Shaikh Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 0a39a8558b294..0682fd363cb50 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2844,6 +2844,8 @@ static void amdgpu_dm_update_backlight_caps(struct amdgpu_display_manager *dm) #if defined(CONFIG_ACPI) struct amdgpu_dm_backlight_caps caps; + memset(, 0, sizeof(caps)); + if (dm->backlight_caps.caps_valid) return; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 36/42] drm/amd/display: Revert HDCP disable sequence change
From: Jaehyun Chung [ Upstream commit b61f05622ace5b9498ae279cdfd1c9f0c1ce3f75 ] [Why] Revert HDCP disable sequence change that blanks stream before disabling HDCP. PSP and HW teams are currently investigating the root cause of why HDCP cannot be disabled before stream blank, which is expected to work without issues. Signed-off-by: Jaehyun Chung Reviewed-by: Wenjing Liu Acked-by: Eryk Brol Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index 31aa31c280ee6..bdddb46727b1f 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -3265,10 +3265,10 @@ void core_link_disable_stream(struct pipe_ctx *pipe_ctx) core_link_set_avmute(pipe_ctx, true); } - dc->hwss.blank_stream(pipe_ctx); #if defined(CONFIG_DRM_AMD_DC_HDCP) update_psp_stream_config(pipe_ctx, true); #endif + dc->hwss.blank_stream(pipe_ctx); if (pipe_ctx->stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST) deallocate_mst_payload(pipe_ctx); -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 21/42] drm/msm/a6xx: fix gmu start on newer firmware
From: Dmitry Baryshkov
[ Upstream commit f5749d6181fa7df5ae741788e5d96f593d3a60b6 ]
New Qualcomm firmware has changed a way it reports back the 'started'
event. Support new register values.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 1d330204c465c..2dd1cf1ffbe25 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -207,6 +207,16 @@ static int a6xx_gmu_start(struct a6xx_gmu *gmu)
{
int ret;
u32 val;
+ u32 mask, reset_val;
+
+ val = gmu_read(gmu, REG_A6XX_GMU_CM3_DTCM_START + 0xff8);
+ if (val <= 0x20010004) {
+ mask = 0x;
+ reset_val = 0xbabeface;
+ } else {
+ mask = 0x1ff;
+ reset_val = 0x100;
+ }
gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 1);
@@ -218,7 +228,7 @@ static int a6xx_gmu_start(struct a6xx_gmu *gmu)
gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 0);
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_CM3_FW_INIT_RESULT, val,
- val == 0xbabeface, 100, 1);
+ (val & mask) == reset_val, 100, 1);
if (ret)
DRM_DEV_ERROR(gmu->dev, "GMU firmware initialization timed
out\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 04/42] drm/msm/dpu: Fix reservation failures in modeset
From: Kalyan Thota
[ Upstream commit ccc862b957c6413b008fbe458034372847992d7f ]
In TEST_ONLY commit, rm global_state will duplicate the
object and request for new reservations, once they pass
then the new state will be swapped with the old and will
be available for the Atomic Commit.
This patch fixes some of missing links in the resource
reservation sequence mentioned above.
1) Creation of duplicate state in test_only commit (Rob)
2) Allocate and release the resources on every modeset.
3) Avoid allocation only when active is false.
In a modeset operation, swap state happens well before
disable. Hence clearing reservations in disable will
cause failures in modeset enable.
Allow reservations to be cleared/allocated before swap,
such that only newly committed resources are pushed to HW.
Changes in v1:
- Move the rm release to atomic_check.
- Ensure resource allocation and free happens when active
is not changed i.e only when mode is changed.(Rob)
Changes in v2:
- Handle dpu_kms_get_global_state API failure as it may
return EDEADLK (swboyd).
Signed-off-by: Kalyan Thota
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0946a86b37b28..c0cd936314e66 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -586,7 +586,10 @@ static int dpu_encoder_virt_atomic_check(
dpu_kms = to_dpu_kms(priv->kms);
mode = _state->mode;
adj_mode = _state->adjusted_mode;
- global_state = dpu_kms_get_existing_global_state(dpu_kms);
+ global_state = dpu_kms_get_global_state(crtc_state->state);
+ if (IS_ERR(global_state))
+ return PTR_ERR(global_state);
+
trace_dpu_enc_atomic_check(DRMID(drm_enc));
/*
@@ -621,12 +624,15 @@ static int dpu_encoder_virt_atomic_check(
/* Reserve dynamic resources now. */
if (!ret) {
/*
-* Avoid reserving resources when mode set is pending. Topology
-* info may not be available to complete reservation.
+* Release and Allocate resources on every modeset
+* Dont allocate when active is false.
*/
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
- ret = dpu_rm_reserve(_kms->rm, global_state,
- drm_enc, crtc_state, topology);
+ dpu_rm_release(global_state, drm_enc);
+
+ if (!crtc_state->active_changed || crtc_state->active)
+ ret = dpu_rm_reserve(_kms->rm, global_state,
+ drm_enc, crtc_state, topology);
}
}
@@ -1175,7 +1181,6 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
struct dpu_encoder_virt *dpu_enc = NULL;
struct msm_drm_private *priv;
struct dpu_kms *dpu_kms;
- struct dpu_global_state *global_state;
int i = 0;
if (!drm_enc) {
@@ -1194,7 +1199,6 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
priv = drm_enc->dev->dev_private;
dpu_kms = to_dpu_kms(priv->kms);
- global_state = dpu_kms_get_existing_global_state(dpu_kms);
trace_dpu_enc_disable(DRMID(drm_enc));
@@ -1224,8 +1228,6 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
DPU_DEBUG_ENC(dpu_enc, "encoder disabled\n");
- dpu_rm_release(global_state, drm_enc);
-
mutex_unlock(_enc->enc_lock);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 05/42] drm/msm/dpu: Fix scale params in plane validation
From: Kalyan Thota
[ Upstream commit 4c978caf08aa155bdeadd9e2d4b026d4ce97ebd0 ]
Plane validation uses an API drm_calc_scale which will
return src/dst value as a scale ratio.
when viewing the range on a scale the values should fall in as
Upscale ratio < Unity scale < Downscale ratio for src/dst formula
Fix the min and max scale ratios to suit the API accordingly.
Signed-off-by: Kalyan Thota
Tested-by: Kristian H. Kristensen
Reviewed-by: Kristian H. Kristensen
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 3b9c33e694bf4..994d23bad3870 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -866,9 +866,9 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
crtc_state = drm_atomic_get_new_crtc_state(state->state,
state->crtc);
- min_scale = FRAC_16_16(1, pdpu->pipe_sblk->maxdwnscale);
+ min_scale = FRAC_16_16(1, pdpu->pipe_sblk->maxupscale);
ret = drm_atomic_helper_check_plane_state(state, crtc_state, min_scale,
- pdpu->pipe_sblk->maxupscale << 16,
+ pdpu->pipe_sblk->maxdwnscale << 16,
true, true);
if (ret) {
DPU_DEBUG_PLANE(pdpu, "Check plane state failed (%d)\n", ret);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 33/42] drm/amd/display: should check error using DC_OK
From: Tong Zhang [ Upstream commit ed9ab229fea24cbcab17f484297dc8344afb7ea9 ] core_link_read_dpcd returns only DC_OK(1) and DC_ERROR_UNEXPECTED(-1), the caller should check error using DC_OK instead of checking against 0 Signed-off-by: Tong Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 91cd884d6f257..7728fd71d1f3a 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -4346,9 +4346,9 @@ bool dc_link_get_backlight_level_nits(struct dc_link *link, link->connector_signal != SIGNAL_TYPE_DISPLAY_PORT)) return false; - if (!core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_CURRENT_PEAK, + if (core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_CURRENT_PEAK, dpcd_backlight_get.raw, - sizeof(union dpcd_source_backlight_get))) + sizeof(union dpcd_source_backlight_get)) != DC_OK) return false; *backlight_millinits_avg = @@ -4387,9 +4387,9 @@ bool dc_link_read_default_bl_aux(struct dc_link *link, uint32_t *backlight_milli link->connector_signal != SIGNAL_TYPE_DISPLAY_PORT)) return false; - if (!core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_LEVEL, + if (core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_LEVEL, (uint8_t *) backlight_millinits, - sizeof(uint32_t))) + sizeof(uint32_t)) != DC_OK) return false; return true; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209091] New: i915: drm:fw_domains_get [i915] *ERROR* render: timed out waiting for forcewake ack request.
https://bugzilla.kernel.org/show_bug.cgi?id=209091 Bug ID: 209091 Summary: i915: drm:fw_domains_get [i915] *ERROR* render: timed out waiting for forcewake ack request. Product: Drivers Version: 2.5 Kernel Version: 5.8.5 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: madc...@atlas.cz Regression: No I have been seeing this error ever since I last updated my system packages. I see the following error message every time during boot: [ 11.504795] [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request. [ 11.509800] [ cut here ] [ 11.509801] i915 :00:02.0: Unclaimed read from register 0x235c [ 11.509850] WARNING: CPU: 4 PID: 494 at drivers/gpu/drm/i915/intel_uncore.c:1182 __unclaimed_reg_debug+0x77/0x90 [i915] [ 11.509851] Modules linked in: bnep joydev mousedev intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp kvm_intel iwldvm kvm mac80211 irqbypass snd_hda_codec_hdmi crct10dif_pclmul libarc4 crc32_pclmul snd_hda_codec_conexant ghash_clmulni_intel snd_hda_codec_generic nls_iso8859_1 mei_wdt mei_hdcp iwlwifi aesni_intel nls_cp437 iTCO_wdt btusb snd_hda_intel btrtl crypto_simd vfat btbcm cryptd fat snd_intel_dspcfg btintel glue_helper intel_pmc_bxt wmi_bmof rapl at24 iTCO_vendor_support intel_cstate snd_hda_codec bluetooth snd_hda_core thinkpad_acpi psmouse ecdh_generic snd_hwdep intel_uncore cfg80211 ecc nvram input_leds snd_pcm mei_me pcspkr ledtrig_audio e1000e lpc_ich i2c_i801 tpm_tis tpm_tis_core i2c_smbus snd_timer rfkill mei tpm snd wmi soundcore rng_core evdev battery ac mac_hid usbip_host usbip_core coretemp msr pkcs8_key_parser sg crypto_user ip_tables x_tables ext4 sdhci_pci cqhci serio_raw atkbd sdhci crc32c_generic libps2 crc16 ehci_pci mbcache i8042 jbd2 [ 11.509872] crc32c_intel mmc_core ehci_hcd serio i915 intel_gtt i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm agpgart [ 11.509878] CPU: 4 PID: 494 Comm: Xorg Tainted: GW I 5.8.5-arch1-1 #1 [ 11.509878] Hardware name: LENOVO 4236B87/4236B87, BIOS 83ET79WW (1.49 ) 09/05/2016 [ 11.509899] RIP: 0010:__unclaimed_reg_debug+0x77/0x90 [i915] [ 11.509900] Code: 48 8b 78 18 4c 8b 77 50 4d 85 f6 74 30 e8 f1 7e 58 ef 45 89 e0 4c 89 e9 4c 89 f2 48 89 c6 48 c7 c7 40 7e 49 c0 e8 8f b1 f5 ee <0f> 0b 83 2d a0 64 21 00 01 5b 5d 41 5c 41 5d 41 5e c3 c3 4c 8b 37 [ 11.509901] RSP: 0018:b6198089fd28 EFLAGS: 00010082 [ 11.509902] RAX: RBX: 965446d107e0 RCX: [ 11.509902] RDX: 0003 RSI: b056ac7f RDI: [ 11.509903] RBP: R08: 0521 R09: 0004 [ 11.509903] R10: R11: 0001 R12: 235c [ 11.509904] R13: c04c00ef R14: 96544b06df90 R15: 965446d107f8 [ 11.509905] FS: 7fc0db350540() GS:96544e30() knlGS: [ 11.509906] CS: 0010 DS: ES: CR0: 80050033 [ 11.509906] CR2: 7fc0da07d070 CR3: 0003ef1aa006 CR4: 000606e0 [ 11.509907] Call Trace: [ 11.509931] gen6_read32+0x1da/0x1f0 [i915] [ 11.509952] i915_reg_read_ioctl+0xc0/0x130 [i915] [ 11.509968] ? drm_gem_handle_delete+0x73/0x90 [drm] [ 11.509988] ? intel_uncore_fini_mmio+0xa0/0xa0 [i915] [ 11.509998] drm_ioctl_kernel+0xb2/0x100 [drm] [ 11.510008] drm_ioctl+0x208/0x360 [drm] [ 11.510029] ? intel_uncore_fini_mmio+0xa0/0xa0 [i915] [ 11.510033] ksys_ioctl+0x82/0xc0 [ 11.510035] __x64_sys_ioctl+0x16/0x20 [ 11.510038] do_syscall_64+0x44/0x70 [ 11.510040] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 11.510042] RIP: 0033:0x7fc0dbd08f6b [ 11.510043] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d5 ae 0c 00 f7 d8 64 89 01 48 [ 11.510044] RSP: 002b:7ffeffa77968 EFLAGS: 0246 ORIG_RAX: 0010 [ 11.510045] RAX: ffda RBX: 7ffeffa77a10 RCX: 7fc0dbd08f6b [ 11.510045] RDX: 7ffeffa77a10 RSI: c0106471 RDI: 000f [ 11.510046] RBP: c0106471 R08: R09: 55bf48dc6010 [ 11.510046] R10: 7ffeffb17080 R11: 0246 R12: [ 11.510047] R13: 000f R14: 55bf48e23b00 R15: 0003 [ 11.510049] ---[ end trace cc066b47ea04e946 ]--- The system still kind of works but the rendering performance seems reduced and noticeably sluggish. There are some more [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request.
Re: [RFC] Experimental DMA-BUF Device Heaps
Hi James, On Sun, Aug 23, 2020 at 03:53:50PM -0700, James Jones wrote: > On 8/23/20 1:46 PM, Laurent Pinchart wrote: > > On Sun, Aug 23, 2020 at 01:04:43PM -0700, James Jones wrote: > >> On 8/20/20 1:15 AM, Ezequiel Garcia wrote: > >>> On Mon, 2020-08-17 at 20:49 -0700, James Jones wrote: > On 8/17/20 8:18 AM, Brian Starkey wrote: > > On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote: > >> This heap is basically a wrapper around DMA-API dma_alloc_attrs, > >> which will allocate memory suitable for the given device. > >> > >> The implementation is mostly a port of the Contiguous Videobuf2 > >> memory allocator (see videobuf2/videobuf2-dma-contig.c) > >> over to the DMA-BUF Heap interface. > >> > >> The intention of this allocator is to provide applications > >> with a more system-agnostic API: the only thing the application > >> needs to know is which device to get the buffer for. > >> > >> Whether the buffer is backed by CMA, IOMMU or a DMA Pool > >> is unknown to the application. > >> > >> I'm not really expecting this patch to be correct or even > >> a good idea, but just submitting it to start a discussion on DMA-BUF > >> heap discovery and negotiation. > >> > > > > My initial reaction is that I thought dmabuf heaps are meant for use > > to allocate buffers for sharing across devices, which doesn't fit very > > well with having per-device heaps. > > > > For single-device allocations, would using the buffer allocation > > functionality of that device's native API be better in most > > cases? (Some other possibly relevant discussion at [1]) > > > > I can see that this can save some boilerplate for devices that want > > to expose private chunks of memory, but might it also lead to 100 > > aliases for the system's generic coherent memory pool? > > > > I wonder if a set of helpers to allow devices to expose whatever they > > want with minimal effort would be better. > > I'm rather interested on where this goes, as I was toying with using > some sort of heap ID as a basis for a "device-local" constraint in the > memory constraints proposals Simon and I will be discussing at XDC this > year. It would be rather elegant if there was one type of heap ID used > universally throughout the kernel that could provide a unique handle for > the shared system memory heap(s), as well as accelerator-local heaps on > fancy NICs, GPUs, NN accelerators, capture devices, etc. so apps could > negotiate a location among themselves. This patch seems to be a step > towards that in a way, but I agree it would be counterproductive if a > bunch of devices that were using the same underlying system memory ended > up each getting their own heap ID just because they used some SW > framework that worked that way. > > Would appreciate it if you could send along a pointer to your BoF if it > happens! > >>> > >>> Here is it: > >>> > >>> https://linuxplumbersconf.org/event/7/contributions/818/ > >>> > >>> It would be great to see you there and discuss this, > >>> given I was hoping we could talk about how to meet a > >>> userspace allocator library expectations as well. > >> > >> Thanks! I hadn't registered for LPC and it looks like it's sold out, > >> but I'll try to watch the live stream. > >> > >> This is very interesting, in that it looks like we're both trying to > >> solve roughly the same set of problems but approaching it from different > >> angles. From what I gather, your approach is that a "heap" encompasses > >> all the allocation constraints a device may have. > >> > >> The approach Simon Ser and I are tossing around so far is somewhat > >> different, but may potentially leverage dma-buf heaps a bit as well. > >> > >> Our approach looks more like what I described at XDC a few years ago, > >> where memory constraints for a given device's usage of an image are > >> exposed up to applications, which can then somehow perform boolean > >> intersection/union operations on them to arrive at a common set of > >> constraints that describe something compatible with all the devices & > >> usages desired (or fail to do so, and fall back to copying things around > >> presumably). I believe this is more flexible than your initial proposal > >> in that devices often support multiple usages (E.g., different formats, > >> different proprietary layouts represented by format modifiers, etc.), > >> and it avoids adding a combinatorial number of heaps to manage that. > >> > >> In my view, heaps are more like blobs of memory that can be allocated > >> from in various different ways to satisfy constraints. I realize heaps > >> mean something specific in the dma-buf heap design (specifically, > >> something closer to an association between an "allocation mechanism" and > >> "physical memory"), but I hope we don't
[Bug 208373] drm:drm_atomic_helper_wait_for_dependencies - drm_kms_helper - flip_done timed out
https://bugzilla.kernel.org/show_bug.cgi?id=208373 --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- Google for "kernel git bisect howto" -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Call traces triggered by starting X on 5.8.x kernels - Radeon RX580
On Sat, Aug 29, 2020 at 5:21 AM Adam wrote: > > > Hi All, > > I hope this is useful. Let me know if you would like me to test anything. > > Cheers, > > Adam > > > [2.] Full description of the problem/report: > > X works but, 6 warnings triggered, in; > drivers/gpu/drm/drm_modeset_lock.c:185 > drivers/gpu/drm/drm_crtc_helper.c:148 > drivers/gpu/drm/drm_crtc_helper.c:108 > > First one here, refer to dmesg-out.txt in tarball for the rest; Fixed with this patch: https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-fixes=77ef38574beb3e0b414db48e9c0f04633df68ba6 On it's way to stable as well. Alex > > [ 28.223717] [ cut here ] > [ 28.223722] WARNING: CPU: 15 PID: 844 at > drivers/gpu/drm/drm_modeset_lock.c:185 > drm_warn_on_modeset_not_all_locked.part.0+0x67/0x70 > [ 28.223723] Modules linked in: igb uvcvideo snd_usb_audio > videobuf2_vmalloc videobuf2_memops snd_usbmidi_lib videobuf2_v4l2 > snd_rawmidi videobuf2_common snd_seq_device snd_hda_codec_realtek > kvm_amd snd_hda_codec_generic kvm irqbypass snd_hda_codec_hdmi > aesni_intel glue_helper crypto_simd snd_hda_intel cryptd > snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer > pinctrl_amd sch_fq_codel efivarfs > [ 28.223734] CPU: 15 PID: 844 Comm: X Tainted: G T 5.8.4-gentoo #1 > [ 28.223735] Hardware name: Micro-Star International Co., Ltd. > MS-7C37/X570-A PRO (MS-7C37), BIOS H.70 01/09/2020 > [ 28.223736] RIP: 0010:drm_warn_on_modeset_not_all_locked.part.0+0x67/0x70 > [ 28.223737] Code: 01 00 00 e8 0b c5 9d ff 84 c0 74 1a 49 8d bc 24 98 > 01 00 00 e8 fa c4 9d ff 84 c0 74 0d 5b 5d 41 5c c3 0f 0b eb c8 0f 0b eb > e2 <0f> 0b 5b 5d 41 5c c3 66 90 8b 05 f2 c2 ad 01 85 c0 75 02 eb 84 c3 > [ 28.223738] RSP: 0018:ae22c1217a50 EFLAGS: 00010246 > [ 28.223739] RAX: RBX: 92f1f2370af8 RCX: > > [ 28.223739] RDX: RSI: 92f1f1dce8a0 RDI: > 92f1f2370998 > [ 28.223740] RBP: 92f1f2370b08 R08: 92f1f16c9d48 R09: > 92f1f1f85848 > [ 28.223740] R10: R11: R12: > 92f1f2370800 > [ 28.223741] R13: 0002 R14: 92f1f2370800 R15: > 92f1f1dce800 > [ 28.223742] FS: 77e6a3f76dc0() GS:92f1febc() > knlGS: > [ 28.223742] CS: 0010 DS: ES: CR0: 80050033 > [ 28.223743] CR2: 644699c64018 CR3: 0007dcb9e000 CR4: > 00340ee0 > [ 28.223743] Call Trace: > [ 28.223745] drm_crtc_helper_set_mode+0x73/0x4b0 > [ 28.223748] ? __blk_mq_try_issue_directly+0xfd/0x250 > [ 28.223750] ? update_load_avg+0x71/0x5a0 > [ 28.223751] ? newidle_balance.constprop.0+0x1eb/0x340 > [ 28.223752] ? psi_group_change+0x3a/0x1d0 > [ 28.223754] ? kernel_init_free_pages+0x40/0x50 > [ 28.223754] ? prep_new_page+0xa3/0xb0 > [ 28.223755] ? get_page_from_freelist+0x1125/0x1a60 > [ 28.223757] amdgpu_connector_set_property+0x2a8/0x630 > [ 28.223758] drm_connector_set_obj_prop+0x39/0x80 > [ 28.223759] drm_mode_obj_set_property_ioctl+0x291/0x320 > [ 28.223760] ? drm_connector_set_obj_prop+0x80/0x80 > [ 28.223761] drm_connector_property_set_ioctl+0x34/0x50 > [ 28.223763] drm_ioctl_kernel+0xa3/0xf0 > [ 28.223764] drm_ioctl+0x1f9/0x36f > [ 28.223764] ? drm_connector_set_obj_prop+0x80/0x80 > [ 28.223766] ? handle_mm_fault+0xd65/0x1680 > [ 28.223767] amdgpu_drm_ioctl+0x41/0x70 > [ 28.223769] ksys_ioctl+0x88/0xc0 > [ 28.223769] __x64_sys_ioctl+0x11/0x20 > [ 28.223771] do_syscall_64+0x3e/0x70 > [ 28.223772] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 28.223773] RIP: 0033:0x77e6a446d747 > [ 28.223774] Code: 1f 40 00 48 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 > b1 e8 0c ff ff ff 85 c0 78 b6 5b 4c 89 e0 5d 41 5c c3 b8 10 00 00 00 0f > 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 76 0c 00 f7 d8 64 89 01 48 > [ 28.223775] RSP: 002b:7ffe15738858 EFLAGS: 0246 ORIG_RAX: > 0010 > [ 28.223776] RAX: ffda RBX: 7ffe15738890 RCX: > 77e6a446d747 > [ 28.223776] RDX: 7ffe15738890 RSI: c01064ab RDI: > 000b > [ 28.223777] RBP: c01064ab R08: 644699c61e90 R09: > 0001 > [ 28.223777] R10: 77e6a4535a60 R11: 0246 R12: > 6446996915b0 > [ 28.223778] R13: 000b R14: 644699c63c10 R15: > 0002 > [ 28.223778] ---[ end trace b571c596e5f7bd31 ]--- > > > [3.] Keywords (i.e., modules, networking, kernel): > [4.] Kernel information > [4.1.] Kernel version (from /proc/version): > > Linux version 5.8.4-gentoo (root@zen) (gcc (Gentoo 10.2.0-r1 p2) 10.2.0, > GNU ld (Gentoo 2.34 p6) 2.34.0) #1 SMP Thu Aug 27 11:20:43 AEST 2020 > > Pretty sure it started in 5.8.0. > > > [4.2.] Kernel .config file: > > In tarball > > [5.] Most recent kernel version which did not have the bug: > > Likely 5.7.x, however, it is possible that I missed it in other versions > since X still runs. > > [6.]
Re: [RFT 10/10] arm64: dts: exynos: Enable Arizona interrupt controller in Exynos5433 TM2
On Mon, 31 Aug 2020 at 15:12, Marek Szyprowski wrote: > > > On 29.08.2020 16:25, Krzysztof Kozlowski wrote: > > The Wolfson Arizona codec is interrupt controller which is required by > > bindings. This fixes dtbs_check warnings like: > > > >arch/arm64/boot/dts/exynos/exynos5433-tm2e.dt.yaml: wm5110-codec@0: > > 'interrupt-controller' is a required property > >arch/arm64/boot/dts/exynos/exynos5433-tm2e.dt.yaml: wm5110-codec@0: > > '#interrupt-cells' is a required property > > > > Signed-off-by: Krzysztof Kozlowski > > Tested-by: Marek Szyprowski > > However I really wonder if it makes sense to expose this to DTS. Indeed, > the main MFD device of the WM5110 chip is interrupt controller, but its > interrupts are requested internally by the respective drivers. In such case maybe the schema should be updated? Feel free to send a follow up or a replacement patch for this one. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: add support for gamma_set interface
On Mon, Aug 31, 2020 at 01:38:58PM +, Sidong Yang wrote:
> On Mon, Aug 31, 2020 at 11:39:10AM +, Simon Ser wrote:
> > On Saturday, August 29, 2020 4:06 PM, Sidong Yang
> > wrote:
> >
> > > Currently vkms module doesn't support gamma function for userspace. so igt
> > > subtests in kms_plane(pixel-format-pipe-A-plan) failed for calling
> > > drmModeCrtcSetGamma().
> >
>
> Hi, Simon.
> Thanks for review.
>
> > It doesn't seem like this IGT test's goal is to exercise support for
> > gamma LUTs. Does the test just tries to reset the gamma LUT to linear?
> > If so, I think the IGT test should be fixed to ignore "I don't support
> > gamma" errors.
>
> It seems like that IGT test pixel-format is to make gamma lut like below.
>
> for (i = 0; i < lut_size; i++)
> lut[i] = (i * 0x / (lut_size - 1)) & mask;
>
> And set this table to drm driver. and test begins. It's the test about pixel
> format. I think you're right. It's not about gamma lut.
The point of the gamma LUT stuff in the pixel format test is to throw
away a bunch of the lsbs so that the test passes when the result is
"close enough" to the 8bpc RGB reference image. Without it we would
never get a crc match when testing non-8bpc or YCbCr formats.
> >
> > > This patch set gamma_set interface in vkms_crtc_funcs for
> > > support gamma function. With initializing crtc, added calls for setting
> > > gamma
> > > size. it pass the test after this patch.
> > >
> > > Cc: Daniel Vetter
> > > Cc: Rodrigo Siqueira
> > > Cc: Haneen Mohammed
> > >
> > > Signed-off-by: Sidong Yang
> > > ---
> > > drivers/gpu/drm/vkms/vkms_crtc.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > index ac85e17428f8..643435fb2ee6 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > @@ -160,6 +160,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
> > > .get_crc_sources= vkms_get_crc_sources,
> > > .set_crc_source = vkms_set_crc_source,
> > > .verify_crc_source = vkms_verify_crc_source,
> > > + .gamma_set = drm_atomic_helper_legacy_gamma_set,
> >
> > Why does VKMS need to use a legacy helper?
>
> drm_crtc_enable_color_mgmt() enables properties about gamma/degamma lut. And
> legacy helper just saves lut data from userspace to drm property blob. It
> seems
> that it's convenient way to implement .gamma_set.
>
> > It seems like this patch just advertises support for gamma LUTs, but
> > ignores any value set by user-space. If VKMS advertises support for
> > gamma LUTs, it needs to take the LUT into account when blending planes.
>
> Yes, This patch doesn't use gamma lut passed by user. lut should be used for
> calculating pixel value. For vkms, Maybe lut will be used in making crc value?
> If so, I'll try to write next patch for it.
>
> Thanks,
> -Sidong
>
> >
> > > };
> > >
> > > static int vkms_crtc_atomic_check(struct drm_crtc *crtc,
> > > @@ -275,6 +276,13 @@ int vkms_crtc_init(struct drm_device *dev, struct
> > > drm_crtc *crtc,
> > > return ret;
> > > }
> > >
> > > + ret = drm_mode_crtc_set_gamma_size(crtc, 256);
> > > + if (ret) {
> > > + DRM_ERROR("Failed to set gamma size\n");
> > > + return ret;
> > > + }
> > > + drm_crtc_enable_color_mgmt(crtc, 0, false, 256);
> > > +
> > > drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> > >
> > > spin_lock_init(_out->lock);
> > > --
> > > 2.17.1
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: add support for gamma_set interface
On Mon, Aug 31, 2020 at 11:39:10AM +, Simon Ser wrote:
> On Saturday, August 29, 2020 4:06 PM, Sidong Yang wrote:
>
> > Currently vkms module doesn't support gamma function for userspace. so igt
> > subtests in kms_plane(pixel-format-pipe-A-plan) failed for calling
> > drmModeCrtcSetGamma().
>
Hi, Simon.
Thanks for review.
> It doesn't seem like this IGT test's goal is to exercise support for
> gamma LUTs. Does the test just tries to reset the gamma LUT to linear?
> If so, I think the IGT test should be fixed to ignore "I don't support
> gamma" errors.
It seems like that IGT test pixel-format is to make gamma lut like below.
for (i = 0; i < lut_size; i++)
lut[i] = (i * 0x / (lut_size - 1)) & mask;
And set this table to drm driver. and test begins. It's the test about pixel
format. I think you're right. It's not about gamma lut.
>
> > This patch set gamma_set interface in vkms_crtc_funcs for
> > support gamma function. With initializing crtc, added calls for setting
> > gamma
> > size. it pass the test after this patch.
> >
> > Cc: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Haneen Mohammed
> >
> > Signed-off-by: Sidong Yang
> > ---
> > drivers/gpu/drm/vkms/vkms_crtc.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index ac85e17428f8..643435fb2ee6 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -160,6 +160,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
> > .get_crc_sources= vkms_get_crc_sources,
> > .set_crc_source = vkms_set_crc_source,
> > .verify_crc_source = vkms_verify_crc_source,
> > + .gamma_set = drm_atomic_helper_legacy_gamma_set,
>
> Why does VKMS need to use a legacy helper?
drm_crtc_enable_color_mgmt() enables properties about gamma/degamma lut. And
legacy helper just saves lut data from userspace to drm property blob. It seems
that it's convenient way to implement .gamma_set.
> It seems like this patch just advertises support for gamma LUTs, but
> ignores any value set by user-space. If VKMS advertises support for
> gamma LUTs, it needs to take the LUT into account when blending planes.
Yes, This patch doesn't use gamma lut passed by user. lut should be used for
calculating pixel value. For vkms, Maybe lut will be used in making crc value?
If so, I'll try to write next patch for it.
Thanks,
-Sidong
>
> > };
> >
> > static int vkms_crtc_atomic_check(struct drm_crtc *crtc,
> > @@ -275,6 +276,13 @@ int vkms_crtc_init(struct drm_device *dev, struct
> > drm_crtc *crtc,
> > return ret;
> > }
> >
> > + ret = drm_mode_crtc_set_gamma_size(crtc, 256);
> > + if (ret) {
> > + DRM_ERROR("Failed to set gamma size\n");
> > + return ret;
> > + }
> > + drm_crtc_enable_color_mgmt(crtc, 0, false, 256);
> > +
> > drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> >
> > spin_lock_init(_out->lock);
> > --
> > 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 07/17] pwm: lpss: Always update state and set update bit
On Mon, Aug 31, 2020 at 01:26:46PM +0200, Hans de Goede wrote:
> Hi,
>
> On 8/31/20 1:13 PM, Thierry Reding wrote:
> > On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
> > > This commit removes a check where we would skip writing the ctrl register
> > > and then setting the update bit in case the ctrl register already contains
> > > the correct values.
> > >
> > > In a perfect world skipping the update should be fine in these cases, but
> > > on Cherry Trail devices the AML code in the GFX0 devices' PS0 and PS3
> > > methods messes with the PWM controller.
> > >
> > > The "ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase"
> > > patch
> > > earlier in this series stops the GFX0._PS0 method from messing with the
> > > PWM
> > > controller and on the DSDT-s inspected sofar the _PS3 method only reads
> > > from the PWM controller (and turns it off before we get a change to do
> > > so):
> > >
> > > {
> > > PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> > > PSAT |= 0x03
> > > Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> > > }
> > >
> > > The PWM controller getting turning off before we do this ourselves is
> > > a bit annoying but not really an issue.
> > >
> > > The problem this patch fixes comes from a new variant of the GFX0._PS3
> > > code
> > > messing with the PWM controller found on the Acer One 10 S1003 (1):
> > >
> > > {
> > > PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> > > PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> > > PWMT &= 0xFFFF
> > > PWMT |= 0xC000
> > > PWMC = PWMT /* \_SB_.PCI0.GFX0.PWMT */
> > > PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> > > Sleep (0x64)
> > > PWMB &= 0x3FFF
> > > PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
> > > PSAT |= 0x03
> > > Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> > > }
> > >
> > > This "beautiful" piece of code clears the base-unit part of the ctrl-reg,
> > > which effectively disables the controller, and it sets the update flag
> > > to apply this change. Then after this it restores the original ctrl-reg
> > > value, so we do not see it has mucked with the controller.
> > >
> > > *But* it does not set the update flag when restoring the original value.
> > > So the check to see if we can skip writing the ctrl register succeeds
> > > but since the update flag was not set, the old base-unit value of 0 is
> > > still in use and the PWM controller is effectively disabled.
> > >
> > > IOW this PWM controller poking means that we cannot trust the base-unit /
> > > on-time-div value we read back from the PWM controller since it may not
> > > have been applied/committed. Thus we must always update the ctrl-register
> > > and set the update bit.
> >
> > Doesn't this now make patch 6/17 obsolete?
>
> No, there is no guarantee we will get any changes soon after resume,
> so we must restore the state properly on resume, before 5.17
> we were just blindly restoring the old ctrl reg state, but
> if either the freq-div or the duty-cycle changes, we should
> also set the update bit in that case to apply the new freq-div/
> duty-cycle.
Hm... I didn't realize the driver was already saving/restoring context
before this. And from a quick look through the subsystem it looks like
I've done a pretty poor job of enforcing the "no context save/restore
from PWM drivers" rule. There are some cases that have had this support
since before we realized that this is problematic, but I think at least
pwm-img is newer than that and should never have had that code either.
> This actually also helps with that case since patch 6/17 uses
> pwm_lpss_prepare and this makes pwm_lpss_prepare set the
> update but unconditionally.
>
> Also on resume we most do the set the enable bit vs set
> the update bit in the right order, depending on the
> generation of the SoC in which the PWM controller is
> embedded. 6/17 fixes all this by resume, by treating
> resume as a special case of apply() taking all the
> steps apply does.
As I mentioned earlier this works only under the assumption that the
suspend/resume order is correct. And that's possibly true for LPSS. It
won't work in the general case, though, because a backlight could end up
suspending/resuming completely out of sync with the rest of the display
pipeline and that's not something that we want.
I would expect that on i915 you also do have a controlled call sequence
that LPSS is part of, so I would expect that some consumer would
eventually call pwm_apply_state() and then any new settings would get
applied. Yes, that may perhaps be not immediately at the point where the
LPSS resumes, but it should be exactly at the point where the consumer
wants to enable it and therefore the only point where you can expect it
to make sense to enable the PWM.
Anyway, if this really turns out to be the only way to make this work I
can't object to it. But if you do rely on this, perhaps
Re: [PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on resume
On Mon, Aug 31, 2020 at 01:46:28PM +0200, Hans de Goede wrote:
> Hi,
>
> On 8/31/20 1:10 PM, Thierry Reding wrote:
> > On Sun, Aug 30, 2020 at 02:57:42PM +0200, Hans de Goede wrote:
> > > Before this commit a suspend + resume of the LPSS PWM controller
> > > would result in the controller being reset to its defaults of
> > > output-freq = clock/256, duty-cycle=100%, until someone changes
> > > to the output-freq and/or duty-cycle are made.
> > >
> > > This problem has been masked so far because the main consumer
> > > (the i915 driver) was always making duty-cycle changes on resume.
> > > With the conversion of the i915 driver to the atomic PWM API the
> > > driver now only disables/enables the PWM on suspend/resume leaving
> > > the output-freq and duty as is, triggering this problem.
> >
> > Doesn't this imply that there's another bug at play here? At the PWM API
> > level you're applying a state and it's up to the driver to ensure that
> > the hardware state after ->apply() is what the software has requested.
> >
> > If you only switch the enable state and that doesn't cause period and
> > duty cycle to be updated it means that your driver isn't writing those
> > registers when it should be.
>
> Right, the driver was not committing those as it should *on resume*,
> that and it skips setting the update bit on the subsequent enable,
> which is an optimization which gets removed in 7/17.
>
> Before switching the i915 driver over to atomic, when the LPSS-PWM
> was used for the backlight we got the following order on suspend/resume
>
> 1. Set duty-cycle to 0%
> 2. Set enabled to 0
> 3. Save ctrl reg
> 4. Power-off PWM controller, it now looses all its state
> 5. Power-on PWM ctrl
> 6. Restore ctrl reg (as a single reg write)
> 7. Set enabled to 1, at this point one would expect the
> duty/freq from the restored ctrl-reg to apply, but:
> a) The resume code never sets the update bit (which this commit fixes); and
> b) On applying the pwm_state with enabled=1 the code applying the
> state does this (before setting the enabled bit in the ctrl reg):
>
> if (orig_ctrl != ctrl) {
> pwm_lpss_write(pwm, ctrl);
> pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
> }
> and since the restore of the ctrl reg set the old duty/freq the
> writes are skipped, so the update bit never gets set.
>
> 8. Set duty-cycle to the pre-suspend value (which is not 0)
> this does cause a change in the ctrl-reg, so now the update flag
> does get set.
>
> Note that 1-2 and 7-8 are both done by the non atomic i915 code,
> when moving the i915 code to atomic I decided that having these
> 2 separate steps here is non-sense, so the new i915 code just
> toggles the enable bit. So in essence the new atomic PWM
> i915 code drops step 1 and 8.
>
> Dropping steps 8 means that the update bit never gets set and we
> end up with the PWM running at its power-on-reset duty cycle.
>
> You are correct in your remark to patch 7/17 that since that removes
> the if (orig_ctrl != ctrl) for the writes that now step 7 will be
> sufficient to get the PWM to work again. But that only takes the i915
> usage into account.
>
> What if the PWM is used through the sysfs userspace API?
> Then only steps 3-6 will happen on suspend-resume and without
> fixing step 6 to properly restore the PWM controller in its
> pre-resume state (this patch) it will once again be running at
> its power-on-reset defaults instead of the values from the
> restored control register.
Actually PWM's sysfs code has suspend/resume callbacks that basically
make sysfs just a regular consumer of PWMs. So they do end up doing a
pwm_apply_state() on the PWM as well on suspend and restore the state
from before suspend on resume.
This was done very specifically because the suspend/resume order can be
unexpected under some circumstances, so for PWM we really want for the
consumer to always have ultimate control over when precisely the PWM is
restored on resume.
The reason why we did this was because people observed weird glitches on
suspend/resume with different severity. In some cases a backlight would
be resumed before the display controller had had a chance to start
sending frames, causing on-screen corruption in some cases (such as
smart displays) and in other cases a PWM-controller regulator would be
resumed too late or too early, which I think was causing some issue with
the CPUs not working properly on resume.
So I'd prefer not to have any PWM driver save and restore its own
context on suspend/resume, because that's inevitably going to cause
unexpected behaviour at some point. If it's absolutely necessary we can
of course still do that, but I think in that case we need to at least
add a comment in the code about why context save/restore is needed in
this particular case and make it clear that this is not something that
other drivers should copy because they most likely won't be needing it.
Given the above it also doesn't sound to me like
Re: [RFT 10/10] arm64: dts: exynos: Enable Arizona interrupt controller in Exynos5433 TM2
On 29.08.2020 16:25, Krzysztof Kozlowski wrote: > The Wolfson Arizona codec is interrupt controller which is required by > bindings. This fixes dtbs_check warnings like: > >arch/arm64/boot/dts/exynos/exynos5433-tm2e.dt.yaml: wm5110-codec@0: > 'interrupt-controller' is a required property >arch/arm64/boot/dts/exynos/exynos5433-tm2e.dt.yaml: wm5110-codec@0: > '#interrupt-cells' is a required property > > Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski However I really wonder if it makes sense to expose this to DTS. Indeed, the main MFD device of the WM5110 chip is interrupt controller, but its interrupts are requested internally by the respective drivers. > --- > > Not tested on HQ. Please kindly review and test. > > Best regards, > Krzysztof > --- > arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi > b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi > index bab6c1addd5f..49cd55d6891c 100644 > --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi > +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi > @@ -1242,6 +1242,8 @@ > > gpio-controller; > #gpio-cells = <2>; > + interrupt-controller; > + #interrupt-cells = <2>; > > wlf,micd-detect-debounce = <300>; > wlf,micd-bias-start-time = <0x1>; Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
Hi Swapnil,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on linus/master v5.9-rc3 next-20200828]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Swapnil-Jakhade/drm-Add-support-for-Cadence-MHDP8546-DPI-DP-bridge-and-J721E-wrapper/20200831-162549
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=sparc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
'cdns_mhdp_fw_activate':
>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:749:10: warning:
>> conversion from 'long unsigned int' to 'u32' {aka 'unsigned int'} changes
>> value from '18446744073709551613' to '4294967293' [-Woverflow]
749 | writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
'cdns_mhdp_fill_host_caps':
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:1355:2: error: implicit
declaration of function 'phy_get_attrs' [-Werror=implicit-function-declaration]
1355 | phy_get_attrs(mhdp->phy, );
| ^
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:1361:19: error: 'struct
phy_attrs' has no member named 'max_link_rate'
1361 | link_rate = attrs.max_link_rate;
| ^
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
'cdns_mhdp_attach':
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:1680:10: warning:
conversion from 'long unsigned int' to 'u32' {aka 'unsigned int'} changes value
from '18446744073709551613' to '4294967293' [-Woverflow]
1680 | writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
'cdns_mhdp_bridge_hpd_enable':
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:2152:10: warning:
conversion from 'long unsigned int' to 'u32' {aka 'unsigned int'} changes value
from '18446744073709551613' to '4294967293' [-Woverflow]
2152 | writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
cc1: some warnings being treated as errors
#
https://github.com/0day-ci/linux/commit/f9a2fb8569e017b7eaba3a94afc9581179c2b62b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Swapnil-Jakhade/drm-Add-support-for-Cadence-MHDP8546-DPI-DP-bridge-and-J721E-wrapper/20200831-162549
git checkout f9a2fb8569e017b7eaba3a94afc9581179c2b62b
vim +749 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
692
693 static int cdns_mhdp_fw_activate(const struct firmware *fw,
694 struct cdns_mhdp_device *mhdp)
695 {
696 unsigned int reg;
697 int ret;
698
699 /* Release uCPU reset and stall it. */
700 writel(CDNS_CPU_STALL, mhdp->regs + CDNS_APB_CTRL);
701
702 memcpy_toio(mhdp->regs + CDNS_MHDP_IMEM, fw->data, fw->size);
703
704 /* Leave debug mode, release stall */
705 writel(0, mhdp->regs + CDNS_APB_CTRL);
706
707 /*
708 * Wait for the KEEP_ALIVE "message" on the first 8 bits.
709 * Updated each sched "tick" (~2ms)
710 */
711 ret = readl_poll_timeout(mhdp->regs + CDNS_KEEP_ALIVE, reg,
712 reg & CDNS_KEEP_ALIVE_MASK, 500,
713 CDNS_KEEP_ALIVE_TIMEOUT);
714 if (ret) {
715 dev_err(mhdp->dev,
716 "device didn't give any life sign: reg %d\n",
reg);
717 return ret;
718 }
719
720 ret = cdns_mhdp_check_fw_version(mhdp);
721 if (ret)
722 return ret;
723
724 /* Init events to 0 as it's not cleared by FW at boot but on
read */
725 readl(mhdp->regs + CDNS_SW_EVENT0);
726 readl(mhdp->regs + CDNS_SW_EVENT1);
727 readl(mhdp->regs + CDNS_SW_EVENT2);
728 readl(mhdp->regs + CDNS_SW_EVENT3);
729
730 /* Activate uCPU */
731 ret = cdns_mhdp_set_firmware_active(mhdp, true);
732 if (re
Re: [PATCH v5 2/2] drm: panel: Add novatek nt36672a panel driver
Hi Sam, On Sun, 30 Aug 2020 at 03:01, Sam Ravnborg wrote: > > Hi Sumit. > > On Wed, Aug 26, 2020 at 09:33:08PM +0530, Sumit Semwal wrote: > > Novatek NT36672a is a generic DSI IC that drives command and video mode > > panels. Add the driver for it. > > > > Right now adding support for some Poco F1 phones that have an LCD panel > > from Tianma connected with this IC, with a resolution of 1080x2246 that > > operates in DSI video mode. > > > > During testing, Benni Steini helped us fix > > the reset sequence timing (from 10ms to 20ms), to get the bootanimation > > to work on Android. > > > > With current AOSP, we need to increase it to 200ms - this seems to be a > > safe high value to avoid a white screen occasionally. > > > > Signed-off-by: Sumit Semwal > > Cc: Benni Steini > > > > --- > > v2: increase reset sequence timing to a safe 200ms > > v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate > > vrefresh on demand. Update for it. > > v5: Fixed review comments from Sam: > > - rebased on top of drm-misc-next > >remove return of drm_panel_add() > >remove drm_panel_detach() > > - renamed the panel driver file to reflect that this is a novatek > >nt36672a display driver and not only for tianma panels. > >Adjusted some internal names also to reflect the same. > > - corrected changelog to add info about the generic Novatek DSI IC > > - corrected compatible string accordingly > > - removed pinctrl > > - used drm_panel* API for prepare/unprepare/disable/remove > Thanks for the detailed follow-up - very nice. > > A few things slipped thought last review and we have gained support for > dv_err_probe() now. Also dev_err() and friends are now the right choice > for panel drivers. Thanks very much for your detailed review :) - I have incorporated the review comments, and will send v6 (hopefully last :) ) in a short while. > > Sam > > > --- > > MAINTAINERS | 7 + > > drivers/gpu/drm/panel/Kconfig | 10 + > > drivers/gpu/drm/panel/Makefile| 1 + > > .../gpu/drm/panel/panel-novatek-nt36672a.c| 767 ++ > > 4 files changed, 785 insertions(+) > > create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 01fb9ee6b951..aeecade2d65f 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5619,6 +5619,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > > F: Documentation/devicetree/bindings/display/ste,mcde.txt > > F: drivers/gpu/drm/mcde/ > > > > +DRM DRIVER FOR TIANMA NT36672A PANELS > > +M: Sumit Semwal > > +S: Maintained > > +T: git git://anongit.freedesktop.org/drm/drm-misc > > +F: > > Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml > > +F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c > > + > > DRM DRIVER FOR TDFX VIDEO CARDS > > S: Orphan / Obsolete > > F: drivers/gpu/drm/tdfx/ > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > > index 8d97d07c5871..02600f12a063 100644 > > --- a/drivers/gpu/drm/panel/Kconfig > > +++ b/drivers/gpu/drm/panel/Kconfig > > @@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510 > > around the Novatek NT35510 display controller, such as some > > Hydis panels. > > > > +config DRM_PANEL_NOVATEK_NT36672A > > + tristate "Novatek NT36672A DSI panel" > > + depends on OF > > + depends on DRM_MIPI_DSI > > + depends on BACKLIGHT_CLASS_DEVICE > > + help > > + Say Y here if you want to enable support for the panels built > > + around the Novatek NT36672A display controller, such as some > > + Tianma panels used in a few Xiaomi Poco F1 mobile phone. > > + > > config DRM_PANEL_NOVATEK_NT39016 > > tristate "Novatek NT39016 RGB/SPI panel" > > depends on OF && SPI > > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > > index 15a4e7752951..4a36eb45f670 100644 > > --- a/drivers/gpu/drm/panel/Makefile > > +++ b/drivers/gpu/drm/panel/Makefile > > @@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o > > obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o > > obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o > > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o > > +obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o > > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o > > obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o > > obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += > > panel-olimex-lcd-olinuxino.o > > diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > > b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > > new file mode 100644 > > index ..3f0c18e46818 > > --- /dev/null > > +++
Re: [PATCH 07/10] arm64: dts: exynos: Replace deprecated "gpios" i2c-gpio property in Exynos5433
On 29.08.2020 16:24, Krzysztof Kozlowski wrote:
> "gpios" property is deprecated. Update the Exynos5433 DTS to fix
> dtbs_checks warnings like:
>
>arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2c-gpio-0: 'sda-gpios'
> is a required property
>arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2c-gpio-0: 'scl-gpios'
> is a required property
>
> Signed-off-by: Krzysztof Kozlowski
Tested-by: Marek Szyprowski
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index 250fc01de78d..6246cce2a15e 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -87,8 +87,8 @@
>
> i2c_max98504: i2c-gpio-0 {
> compatible = "i2c-gpio";
> - gpios = < 1 GPIO_ACTIVE_HIGH /* SPK_AMP_SDA */
> - 0 GPIO_ACTIVE_HIGH /* SPK_AMP_SCL */ >;
> + sda-gpios = < 1 GPIO_ACTIVE_HIGH>;
> + scl-gpios = < 0 GPIO_ACTIVE_HIGH>;
> i2c-gpio,delay-us = <2>;
> #address-cells = <1>;
> #size-cells = <0>;
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Novatek nt36672a is a display driver IC that can drive DSI panel. It
is also present in the Tianma video mode panel, which is a FHD+ panel
with a resolution of 1080x2246 and 6.18 inches size. It is found in
some of the Poco F1 phones.
This patch adds the display driver for the IC, with support added for
this tianma fhd video mode panel.
Signed-off-by: Sumit Semwal
Reviewed-by: Rob Herring
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0 to just 'port'.
v5: renamed to novatek,nt36672a, since the binding is for the IC and not
the panel.
v6: v5 review comments incorporated.
- added enum for the compatible part, since it can be extended in
future.
- few cosmetic updates.
---
.../display/panel/novatek,nt36672a.yaml | 87 +++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
new file mode 100644
index ..d2170de6b723
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT36672A based DSI display Panels
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
+ panels.
+ Right now, support is added only for a Tianma FHD+ LCD display panel with a
+ resolution of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - tianma,fhd-video
+ - const: novatek,nt36672a
+description: This indicates the panel manufacturer of the panel that is
+ in turn using the NT36672A panel driver. This compatible string
+ determines how the NT36672A panel driver is configured for the indicated
+ panel. The novatek,nt36672a compatible shall always be provided as a
fallback.
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ reg: true
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+
+dsi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "tianma,fhd-video", "novatek,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port {
+tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/2] drm: panel: Add novatek nt36672a panel driver
Novatek NT36672a is a generic DSI IC that drives command and video mode
panels. Add the driver for it.
Right now adding support for some Poco F1 phones that have an LCD panel
from Tianma connected with this IC, with a resolution of 1080x2246 that
operates in DSI video mode.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
With current AOSP, we need to increase it to 200ms - this seems to be a
safe high value to avoid a white screen occasionally.
Signed-off-by: Sumit Semwal
Cc: Benni Steini
---
v2: increase reset sequence timing to a safe 200ms
v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate
vrefresh on demand. Update for it.
v5: Fixed review comments from Sam:
- rebased on top of drm-misc-next
remove return of drm_panel_add()
remove drm_panel_detach()
- renamed the panel driver file to reflect that this is a novatek
nt36672a display driver and not only for tianma panels.
Adjusted some internal names also to reflect the same.
- corrected changelog to add info about the generic Novatek DSI IC
- corrected compatible string accordingly
- removed pinctrl
- used drm_panel* API for prepare/unprepare/disable/remove
v6: Fixed few review comments on v5 from Sam:
- add dev_err_probe() support
- move DRM_* error printing to dev_err()
- removed a few unnecessary bits
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-novatek-nt36672a.c| 740 ++
4 files changed, 758 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 01fb9ee6b951..aeecade2d65f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5619,6 +5619,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 8d97d07c5871..02600f12a063 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510
around the Novatek NT35510 display controller, such as some
Hydis panels.
+config DRM_PANEL_NOVATEK_NT36672A
+ tristate "Novatek NT36672A DSI panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the panels built
+ around the Novatek NT36672A display controller, such as some
+ Tianma panels used in a few Xiaomi Poco F1 mobile phone.
+
config DRM_PANEL_NOVATEK_NT39016
tristate "Novatek NT39016 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 15a4e7752951..4a36eb45f670 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
+obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
new file mode 100644
index ..675e9d52f3c4
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
@@ -0,0 +1,740 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ *
+ * This driver is for the DSI interface to panels using the NT36672A display
driver IC
+ * from Novatek.
+ * Currently supported are the Tianma FHD+ panels found in some Xiaomi phones,
including
+ * some variants of the Poco F1 phone.
+ *
+ * Panels using the Novatek NT37762A IC should add appropriate configuration
per-panel and
+ * use this driver.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t
[PATCH v6 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have a FHD+ video mode panel based on the Novatek NT36672A display controller; Add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.9-rc1 based drm-misc-next on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. v3: Replaced port@0 with just port in panel@0 node. v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate vrefresh on demand. Update for it. v5: Fixed review comments from Sam: - rebased on top of drm-misc-next remove return of drm_panel_add() remove drm_panel_detach() - renamed the panel driver file to reflect that this is a novatek nt36672a display driver and not only for tianma panels. Adjusted some internal names also to reflect the same. - corrected changelog to add info about the generic Novatek DSI IC - corrected compatible string accordingly - removed pinctrl - used drm_panel* API for prepare/unprepare/disable/remove v6: Fixed few review comments on v5 from Sam: - add dev_err_probe() support - move DRM_* error printing to dev_err() - removed a few unnecessary bits Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Novatek nt36672a drm: panel: Add novatek nt36672a panel driver .../display/panel/novatek,nt36672a.yaml | 87 ++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-novatek-nt36672a.c| 740 ++ 5 files changed, 845 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/10] arm64: dts: exynos: Add compatibles to sysreg nodes
On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > System register nodes, implementing syscon binding, should use > appropriate compatible. This fixes dtbs_check warnings: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: syscon@13b8: > compatible: ['syscon'] is not valid under any of the given schemas > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/10] arm64: dts: exynos: Replace deprecated "gpios" i2c-gpio property in Exynos5433
On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > "gpios" property is deprecated. Update the Exynos5433 DTS to fix > dtbs_checks warnings like: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2c-gpio-0: 'sda-gpios' > is a required property > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2c-gpio-0: 'scl-gpios' > is a required property > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFT 09/10] arm64: dts: exynos: Correct port of USB-C connector node on Exynos5433 TM2
Hi Krzysztof,
On 29.08.2020 16:25, Krzysztof Kozlowski wrote:
> The USB-C connector bindings require port@0. Such port was already
> described in DTS but outside of the connector itself. Put it into
> proper place to fix dtbs_check warnings like:
>
>arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: musb_connector: ports:
> 'port@0' is a required property
>
> Signed-off-by: Krzysztof Kozlowski
I'm not sure if topic should be about USB-C, I will call it simply USB
connector node. TM2(e) uses Samsung's 11-pin micro USB 2.0 connector,
which has nothing in common with USB Type-C.
Anyway, this patch breaks DWC3 (tested in Device mode) driver operation,
so something has to be somehow adjusted or fixed. Added CC Andrzej
Hajda, who actually worked on this.
> ---
>
> Not tested on HQ. Please kindly review and test.
>
> Best regards,
> Krzysztof
> ---
> .../boot/dts/exynos/exynos5433-tm2-common.dtsi| 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index 6246cce2a15e..bab6c1addd5f 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -871,6 +871,13 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> + port@0 {
> + reg = <0>;
> + muic_to_usb: endpoint {
> + remote-endpoint =
> <_to_muic>;
> + };
> + };
> +
> port@3 {
> reg = <3>;
> musb_con_to_mhl: endpoint {
> @@ -879,14 +886,6 @@
> };
> };
> };
> -
> - ports {
> - port {
> - muic_to_usb: endpoint {
> - remote-endpoint =
> <_to_muic>;
> - };
> - };
> - };
> };
>
> regulators {
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/10] dt-bindings: mfd: syscon: Document Samsung Exynos compatibles
On Mon, Aug 31, 2020 at 02:30:52PM +0200, Sylwester Nawrocki wrote: > On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > > Samsung Exynos SoCs use syscon for system registers so document its > > compatibles. > > > > Signed-off-by: Krzysztof Kozlowski > > --- > > Documentation/devicetree/bindings/mfd/syscon.yaml | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml > > b/Documentation/devicetree/bindings/mfd/syscon.yaml > > index 049ec2ffc7f9..0f21943dea28 100644 > > --- a/Documentation/devicetree/bindings/mfd/syscon.yaml > > +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml > > @@ -40,6 +40,10 @@ properties: > >- allwinner,sun50i-a64-system-controller > >- microchip,sparx5-cpu-syscon > >- mstar,msc313-pmsleep > > + - samsung,exynos3-sysreg > > + - samsung,exynos4-sysreg > > + - samsung,exynos5-sysreg > > + - samsung,exynos5433-sysreg > > Reviewed-by: Sylwester Nawrocki > > Do you also have a patch updating Documentation/devicetree/ > bindings/arm/samsung/sysreg.yaml with new compatibles? Good point. This file should be probably dropped as everything is documented in syscon. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] dt-bindings: sound: samsung-i2s: Use unevaluatedProperties
On 29.08.2020 16:24, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. power-domains) so use
> unevaluatedProperties to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2s@1144:
> Additional properties are not allowed ('power-domains', '#address-cells',
> 'interrupts', '#size-cells' were unexpected)
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Sylwester Nawrocki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/10] dt-bindings: mfd: syscon: Document Samsung Exynos compatibles
On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > Samsung Exynos SoCs use syscon for system registers so document its > compatibles. > > Signed-off-by: Krzysztof Kozlowski > --- > Documentation/devicetree/bindings/mfd/syscon.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml > b/Documentation/devicetree/bindings/mfd/syscon.yaml > index 049ec2ffc7f9..0f21943dea28 100644 > --- a/Documentation/devicetree/bindings/mfd/syscon.yaml > +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml > @@ -40,6 +40,10 @@ properties: >- allwinner,sun50i-a64-system-controller >- microchip,sparx5-cpu-syscon >- mstar,msc313-pmsleep > + - samsung,exynos3-sysreg > + - samsung,exynos4-sysreg > + - samsung,exynos5-sysreg > + - samsung,exynos5433-sysreg Reviewed-by: Sylwester Nawrocki Do you also have a patch updating Documentation/devicetree/ bindings/arm/samsung/sysreg.yaml with new compatibles? -- Regards, Sylwester ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/10] dt-bindings: gpu: arm,mali-midgard: Use unevaluatedProperties
On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > Additional properties or nodes actually might appear (e.g. operating > points table) so use unevaluatedProperties to fix dtbs_check warnings > like: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: gpu@14ac: > 'opp_table' does not match any of the regexes: 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/10] dt-bindings: timer: exynos4210-mct: Use unevaluatedProperties
On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > Additional properties actually might appear (e.g. clocks) so use > unevaluatedProperties to fix dtbs_check warnings like: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: timer@101c: > 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] dt-bindings: arm: samsung: pmu: Use unevaluatedProperties
On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > Additional properties actually might appear (e.g. assigned-clocks) so > use unevaluatedProperties to fix dtbs_check warnings like: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: > system-controller@105c: > 'assigned-clock-parents', 'assigned-clocks' do not match any of the > regexes: 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/modeset-lock: Take the modeset BKL for legacy drivers" has been added to the 5.8-stable tree
This is a note to let you know that I've just added the patch titled
drm/modeset-lock: Take the modeset BKL for legacy drivers
to the 5.8-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-modeset-lock-take-the-modeset-bkl-for-legacy-drivers.patch
and it can be found in the queue-5.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 77ef38574beb3e0b414db48e9c0f04633df68ba6 Mon Sep 17 00:00:00 2001
From: Daniel Vetter
Date: Fri, 14 Aug 2020 11:38:42 +0200
Subject: drm/modeset-lock: Take the modeset BKL for legacy drivers
From: Daniel Vetter
commit 77ef38574beb3e0b414db48e9c0f04633df68ba6 upstream.
This fell off in the conversion in
commit 9bcaa3fe58ab7559e71df798bcff6e0795158695
Author: Michal Orzel
Date: Tue Apr 28 19:10:04 2020 +0200
drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers
but it's caught by the drm_warn_on_modeset_not_all_locked() that the
legacy modeset code uses. Since this is the bkl and it's unclear
what's all protected, play it safe and grab it again for legacy
drivers.
Unfortunately this means we need to sprinkle a few more #includes
around.
Also we need to add the drm_device as a parameter to the _END macro.
Finally remove the mute_lock() from setcrtc, since that's now done by
the macro.
Cc: Alex Deucher
References: https://gitlab.freedesktop.org/drm/amd/-/issues/1224
Fixes: 9bcaa3fe58ab ("drm: Replace drm_modeset_lock/unlock_all with
DRM_MODESET_LOCK_ALL_* helpers")
Cc: Michal Orzel
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.8+
Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20200814093842.3048472-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_helper.c |7 ---
drivers/gpu/drm/drm_color_mgmt.c|2 +-
drivers/gpu/drm/drm_crtc.c |4 +---
drivers/gpu/drm/drm_mode_object.c |4 ++--
drivers/gpu/drm/drm_plane.c |2 +-
include/drm/drm_modeset_lock.h |9 +++--
6 files changed, 16 insertions(+), 12 deletions(-)
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -3105,7 +3106,7 @@ void drm_atomic_helper_shutdown(struct d
if (ret)
DRM_ERROR("Disabling all crtc's during unload failed with
%i\n", ret);
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
}
EXPORT_SYMBOL(drm_atomic_helper_shutdown);
@@ -3245,7 +3246,7 @@ struct drm_atomic_state *drm_atomic_help
}
unlock:
- DRM_MODESET_LOCK_ALL_END(ctx, err);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, err);
if (err)
return ERR_PTR(err);
@@ -3326,7 +3327,7 @@ int drm_atomic_helper_resume(struct drm_
err = drm_atomic_helper_commit_duplicated_state(state, );
- DRM_MODESET_LOCK_ALL_END(ctx, err);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, err);
drm_atomic_state_put(state);
return err;
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -294,7 +294,7 @@ int drm_mode_gamma_set_ioctl(struct drm_
crtc->gamma_size, );
out:
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -561,7 +561,6 @@ int drm_mode_setcrtc(struct drm_device *
if (crtc_req->mode_valid && !drm_lease_held(file_priv, plane->base.id))
return -EACCES;
- mutex_lock(>dev->mode_config.mutex);
DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx,
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
@@ -728,8 +727,7 @@ out:
fb = NULL;
mode = NULL;
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
- mutex_unlock(>dev->mode_config.mutex);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -428,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(st
out_unref:
drm_mode_object_put(obj);
out:
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
@@ -470,7 +470,7 @@ static int set_property_legacy(struct dr
break;
}
drm_property_change_valid_put(prop, ref);
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
--- a/drivers/gpu/drm/drm_plane.c
+++
Re: [PATCH v8 07/17] pwm: lpss: Always update state and set update bit
Hi,
On 8/31/20 10:56 AM, Andy Shevchenko wrote:
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
This commit removes a check where we would skip writing the ctrl register
and then setting the update bit in case the ctrl register already contains
the correct values.
In a perfect world skipping the update should be fine in these cases, but
on Cherry Trail devices the AML code in the GFX0 devices' PS0 and PS3
methods messes with the PWM controller.
The "ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase" patch
earlier in this series stops the GFX0._PS0 method from messing with the PWM
controller and on the DSDT-s inspected sofar the _PS3 method only reads
from the PWM controller (and turns it off before we get a change to do so):
{
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
}
The PWM controller getting turning off before we do this ourselves is
a bit annoying but not really an issue.
The problem this patch fixes comes from a new variant of the GFX0._PS3 code
messing with the PWM controller found on the Acer One 10 S1003 (1):
{
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PWMT &= 0xFFFF
PWMT |= 0xC000
PWMC = PWMT /* \_SB_.PCI0.GFX0.PWMT */
PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
Sleep (0x64)
PWMB &= 0x3FFF
PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
}
This "beautiful" piece of code clears the base-unit part of the ctrl-reg,
which effectively disables the controller, and it sets the update flag
to apply this change. Then after this it restores the original ctrl-reg
value, so we do not see it has mucked with the controller.
*But* it does not set the update flag when restoring the original value.
So the check to see if we can skip writing the ctrl register succeeds
but since the update flag was not set, the old base-unit value of 0 is
still in use and the PWM controller is effectively disabled.
IOW this PWM controller poking means that we cannot trust the base-unit /
on-time-div value we read back from the PWM controller since it may not
have been applied/committed. Thus we must always update the ctrl-register
and set the update bit.
1) And once I knew what to look for also in a bunch of other devices
including the popular Lenovo Ideapad Miix 310 and 320 models and
various Medion models.
Despite the above mentioned issue I'm always in favour of not micro-optimizing
I/O.
Reviewed-by: Andy Shevchenko
Thank you.
Regards,
Hans
Signed-off-by: Hans de Goede
---
Changes in v8:
- New patch in v8 of this patch-set
---
drivers/pwm/pwm-lpss.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 9a7400c6fb6e..20f6b6d6f874 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -85,7 +85,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
struct pwm_device *pwm,
unsigned long long on_time_div;
unsigned long c = lpwm->info->clk_rate, base_unit_range;
unsigned long long base_unit, freq = NSEC_PER_SEC;
- u32 orig_ctrl, ctrl;
+ u32 ctrl;
do_div(freq, period_ns);
@@ -104,16 +104,14 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm,
do_div(on_time_div, period_ns);
on_time_div = 255ULL - on_time_div;
- orig_ctrl = ctrl = pwm_lpss_read(pwm);
+ ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
- if (orig_ctrl != ctrl) {
- pwm_lpss_write(pwm, ctrl);
- pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
- }
+ pwm_lpss_write(pwm, ctrl);
+ pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
}
static inline void pwm_lpss_cond_enable(struct pwm_device *pwm, bool cond)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on resume
Hi,
On 8/31/20 1:10 PM, Thierry Reding wrote:
On Sun, Aug 30, 2020 at 02:57:42PM +0200, Hans de Goede wrote:
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consumer
(the i915 driver) was always making duty-cycle changes on resume.
With the conversion of the i915 driver to the atomic PWM API the
driver now only disables/enables the PWM on suspend/resume leaving
the output-freq and duty as is, triggering this problem.
Doesn't this imply that there's another bug at play here? At the PWM API
level you're applying a state and it's up to the driver to ensure that
the hardware state after ->apply() is what the software has requested.
If you only switch the enable state and that doesn't cause period and
duty cycle to be updated it means that your driver isn't writing those
registers when it should be.
Right, the driver was not committing those as it should *on resume*,
that and it skips setting the update bit on the subsequent enable,
which is an optimization which gets removed in 7/17.
Before switching the i915 driver over to atomic, when the LPSS-PWM
was used for the backlight we got the following order on suspend/resume
1. Set duty-cycle to 0%
2. Set enabled to 0
3. Save ctrl reg
4. Power-off PWM controller, it now looses all its state
5. Power-on PWM ctrl
6. Restore ctrl reg (as a single reg write)
7. Set enabled to 1, at this point one would expect the
duty/freq from the restored ctrl-reg to apply, but:
a) The resume code never sets the update bit (which this commit fixes); and
b) On applying the pwm_state with enabled=1 the code applying the
state does this (before setting the enabled bit in the ctrl reg):
if (orig_ctrl != ctrl) {
pwm_lpss_write(pwm, ctrl);
pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
}
and since the restore of the ctrl reg set the old duty/freq the
writes are skipped, so the update bit never gets set.
8. Set duty-cycle to the pre-suspend value (which is not 0)
this does cause a change in the ctrl-reg, so now the update flag
does get set.
Note that 1-2 and 7-8 are both done by the non atomic i915 code,
when moving the i915 code to atomic I decided that having these
2 separate steps here is non-sense, so the new i915 code just
toggles the enable bit. So in essence the new atomic PWM
i915 code drops step 1 and 8.
Dropping steps 8 means that the update bit never gets set and we
end up with the PWM running at its power-on-reset duty cycle.
You are correct in your remark to patch 7/17 that since that removes
the if (orig_ctrl != ctrl) for the writes that now step 7 will be
sufficient to get the PWM to work again. But that only takes the i915
usage into account.
What if the PWM is used through the sysfs userspace API?
Then only steps 3-6 will happen on suspend-resume and without
fixing step 6 to properly restore the PWM controller in its
pre-resume state (this patch) it will once again be running at
its power-on-reset defaults instead of the values from the
restored control register.
So at step 6, if the PWM was enabled before, we must set the update
bit, and then wait for it to clear again so the controller is
ready for subsequent updates. The waiting for it to clear again
needs to happen before or after setting the enable bit depending
on the hw generation, which leads to this patch.
I hope that helps explain why this patch is the correct thing
to do.
The LPSS PWM controller has a mechanism where the ctrl register value
and the actual base-unit and on-time-div values used are latched. When
software sets the SW_UPDATE bit then at the end of the current PWM cycle,
the new values from the ctrl-register will be latched into the actual
registers, and the SW_UPDATE bit will be cleared.
The problem is that before this commit our suspend/resume handling
consisted of simply saving the PWM ctrl register on suspend and
restoring it on resume, without setting the PWM_SW_UPDATE bit.
When the controller has lost its state over a suspend/resume and thus
has been reset to the defaults, just restoring the register is not
enough. We must also set the SW_UPDATE bit to tell the controller to
latch the restored values into the actual registers.
Fixing this problem is not as simple as just or-ing in the value which
is being restored with SW_UPDATE. If the PWM was enabled before we must
write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
model we must do this either before or after the setting of PWM_ENABLE.
All the necessary logic for doing this is already present inside
pwm_lpss_apply(), so instead of duplicating this inside the resume
handler, this commit adds a new pwm_lpss_restore() helper which mirrors
Re: [PATCH] drm/vkms: add support for gamma_set interface
On Saturday, August 29, 2020 4:06 PM, Sidong Yang wrote:
> Currently vkms module doesn't support gamma function for userspace. so igt
> subtests in kms_plane(pixel-format-pipe-A-plan) failed for calling
> drmModeCrtcSetGamma().
It doesn't seem like this IGT test's goal is to exercise support for
gamma LUTs. Does the test just tries to reset the gamma LUT to linear?
If so, I think the IGT test should be fixed to ignore "I don't support
gamma" errors.
> This patch set gamma_set interface in vkms_crtc_funcs for
> support gamma function. With initializing crtc, added calls for setting gamma
> size. it pass the test after this patch.
>
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
>
> Signed-off-by: Sidong Yang
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index ac85e17428f8..643435fb2ee6 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -160,6 +160,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
> .get_crc_sources= vkms_get_crc_sources,
> .set_crc_source = vkms_set_crc_source,
> .verify_crc_source = vkms_verify_crc_source,
> + .gamma_set = drm_atomic_helper_legacy_gamma_set,
Why does VKMS need to use a legacy helper?
It seems like this patch just advertises support for gamma LUTs, but
ignores any value set by user-space. If VKMS advertises support for
gamma LUTs, it needs to take the LUT into account when blending planes.
> };
>
> static int vkms_crtc_atomic_check(struct drm_crtc *crtc,
> @@ -275,6 +276,13 @@ int vkms_crtc_init(struct drm_device *dev, struct
> drm_crtc *crtc,
> return ret;
> }
>
> + ret = drm_mode_crtc_set_gamma_size(crtc, 256);
> + if (ret) {
> + DRM_ERROR("Failed to set gamma size\n");
> + return ret;
> + }
> + drm_crtc_enable_color_mgmt(crtc, 0, false, 256);
> +
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
>
> spin_lock_init(_out->lock);
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/mcde: Add new driver for ST-Ericsson MCDE
Hello Linus Walleij, The patch 5fc537bfd000: "drm/mcde: Add new driver for ST-Ericsson MCDE" from May 24, 2019, leads to the following static checker warning: drivers/gpu/drm/mcde/mcde_display.c:570 mcde_configure_channel() error: uninitialized symbol 'val'. drivers/gpu/drm/mcde/mcde_display.c 552 case MCDE_VIDEO_TE_FLOW: 553 val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_HARDWARE 554 << MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT; 555 val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_TE0 556 << MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT; 557 break; 558 case MCDE_VIDEO_FORMATTER_FLOW: 559 val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_HARDWARE 560 << MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT; 561 val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_FORMATTER 562 << MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT; 563 break; 564 default: 565 dev_err(mcde->dev, "unknown flow mode %d\n", 566 mcde->flow_mode); "val" not initialized on this path. 567 break; 568 } 569 570 writel(val, mcde->regs + sync); 571 572 /* Set up pixels per line and lines per frame */ regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hello Guido Günther,
The patch 72967d5616d3: "drm/panel: Add panel driver for the Mantix
MLAF057WE51-X DSI panel" from Aug 17, 2020, leads to the following
static checker warning:
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c:205 mantix_get_modes()
error: we previously assumed 'mode' could be null (see line 204)
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
197 static int mantix_get_modes(struct drm_panel *panel,
198 struct drm_connector *connector)
199 {
200 struct mantix *ctx = panel_to_mantix(panel);
201 struct drm_display_mode *mode;
202
203 mode = drm_mode_duplicate(connector->dev, _mode);
204 if (!mode) {
205 dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
206 default_mode.hdisplay, default_mode.vdisplay,
207 drm_mode_vrefresh(mode));
This will lead to a NULL dereference.
208 return -ENOMEM;
209 }
210
211 drm_mode_set_name(mode);
212
213 mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
214 connector->display_info.width_mm = mode->width_mm;
215 connector->display_info.height_mm = mode->height_mm;
216 drm_mode_probed_add(connector, mode);
217
218 return 1;
219 }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 07/17] pwm: lpss: Always update state and set update bit
Hi,
On 8/31/20 1:13 PM, Thierry Reding wrote:
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
This commit removes a check where we would skip writing the ctrl register
and then setting the update bit in case the ctrl register already contains
the correct values.
In a perfect world skipping the update should be fine in these cases, but
on Cherry Trail devices the AML code in the GFX0 devices' PS0 and PS3
methods messes with the PWM controller.
The "ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase" patch
earlier in this series stops the GFX0._PS0 method from messing with the PWM
controller and on the DSDT-s inspected sofar the _PS3 method only reads
from the PWM controller (and turns it off before we get a change to do so):
{
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
}
The PWM controller getting turning off before we do this ourselves is
a bit annoying but not really an issue.
The problem this patch fixes comes from a new variant of the GFX0._PS3 code
messing with the PWM controller found on the Acer One 10 S1003 (1):
{
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PWMT &= 0xFFFF
PWMT |= 0xC000
PWMC = PWMT /* \_SB_.PCI0.GFX0.PWMT */
PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
Sleep (0x64)
PWMB &= 0x3FFF
PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
}
This "beautiful" piece of code clears the base-unit part of the ctrl-reg,
which effectively disables the controller, and it sets the update flag
to apply this change. Then after this it restores the original ctrl-reg
value, so we do not see it has mucked with the controller.
*But* it does not set the update flag when restoring the original value.
So the check to see if we can skip writing the ctrl register succeeds
but since the update flag was not set, the old base-unit value of 0 is
still in use and the PWM controller is effectively disabled.
IOW this PWM controller poking means that we cannot trust the base-unit /
on-time-div value we read back from the PWM controller since it may not
have been applied/committed. Thus we must always update the ctrl-register
and set the update bit.
Doesn't this now make patch 6/17 obsolete?
No, there is no guarantee we will get any changes soon after resume,
so we must restore the state properly on resume, before 5.17
we were just blindly restoring the old ctrl reg state, but
if either the freq-div or the duty-cycle changes, we should
also set the update bit in that case to apply the new freq-div/
duty-cycle.
This actually also helps with that case since patch 6/17 uses
pwm_lpss_prepare and this makes pwm_lpss_prepare set the
update but unconditionally.
Also on resume we most do the set the enable bit vs set
the update bit in the right order, depending on the
generation of the SoC in which the PWM controller is
embedded. 6/17 fixes all this by resume, by treating
resume as a special case of apply() taking all the
steps apply does.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi Lucas, Sam, On Mon, Aug 31, 2020 at 12:37:23PM +0200, Lucas Stach wrote: > Hi Laurentiu, > > On Fr, 2020-08-28 at 11:36 +0300, Laurentiu Palcu wrote: > > Hi Lucas, > > > > I was wondering about the plans to merge this series. Since not many > > people can test it properly due to lack of DCSS support in the upstream > > NWL driver (which I heard it's coming soon) and a completely nonexistent > > HDP driver, are we going to take a leap of faith and merge it as is? Or > > should we wait? > > I think even if the bridges aren't ready yet, the driver is in a good > enough shape to merge it. There's no point in letting it accumulate > bitrot while waiting for the bridges to land. Also I guess it will make > bridge driver development a lot easier when the DCSS driver is in-tree. OK, fair enough. > > > As to who is going to do the actual merge, I know we had a brief > > discussion about it some time ago and I was supposed to apply for > > drm-misc rights, however it feels a little awkward to merge my own > > code... :) Though, I might not even qualify for drm-misc rights anyway, > > considering I haven't been very active in this area... :/ > > Please consider applying for drm-misc merge rights. Even if you don't > do the initial merge I think it will come in handy in the long run. OK, I'll apply for drm-misc rights. Sam also encouraged me to do this in a previous email. Since this series will be followed by a bunch of other patches, enabling support for video planes, among other things, I guess I'll need the rights anyway. > > > On that note, I will probably need help with the merging, provided it's > > still happenning. Will you be able to help me out with this? > > Sure, I'm having some time available this week. I'll give this v9 > another spin on my boards and will do the merge after that. Thanks Lucas. As a matter of fact, after Sam's email, I was preparing a v10 after rebasing to latest drm-next. However, no conflicts were encountered and the v9 series applied cleanly. Let me know if you encounter any issues and I can resend it. Thanks, Laurentiu > > Regards, > Lucas > > > Thanks, > > laurentiu > > > > On Fri, Jul 31, 2020 at 11:18:28AM +0300, Laurentiu Palcu wrote: > > > From: Laurentiu Palcu > > > > > > Hi, > > > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > > > includes only graphics plane support (no video planes), no HDR10 > > > capabilities, > > > no graphics decompression (only linear, tiled and super-tiled buffers > > > allowed). > > > > > > Support for the rest of the features will be added incrementally, in > > > subsequent > > > patches. > > > > > > The patchset was tested with both HDP driver (in the downstream tree) and > > > the upstream > > > MIPI-DSI driver (with a couple of patches on top, to make it work > > > correctly with DCSS). > > > > > > Thanks, > > > Laurentiu > > > > > > Changes in v9: > > > * Fixed a compilation issue found by Guido in his setup: 'select > > >VIDEOMODE_HELPERS' was missing from Kconfig; > > > * Use imx8mq-clock.h in the bindings file so one can understand what > > >those clock values mean; > > > * no other changes done. Couldn't address the hang Guido reported as > > >it's not happening in my setup. However, in my tree, there are some > > >extra NWL and ADV patches applied on top of upstream ones... Also, > > >removing them and testing only with upstream, even if there's no > > >image out, does not produce a hang... :/ > > > > > > Changes in v8: > > > * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed > > >out. SRC is not used in DCSS driver; > > > * Nothing else changed; > > > > > > Changes in v7: > > > * Added a patch to initialize the connector using the > > > drm_bridge_connector > > >API as Sam suggested. Tested it using NWL_DSI and ADV7535 with > > >Guido's patch [1] applied and one fix for ADV [2]. Also, some extra > > >patches for ADV and NWL were needed, from our downstream tree, which > > >will be upstreamed soon by their author; > > > * Rest of the patches are untouched; > > > > > > [1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html > > > [2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html > > > > > > Changes in v6: > > > * Addressed Rob's comment and added "additionalProperties: false" at > > >the end of the bindings' properties. However, this change surfaced > > >an issue with the assigned-clock* properties not being documented in > > >the properties section. Added the descriptions and the bindings patch > > >will need another review; > > > * Added an entry for DCSS driver in the MAINTAINERS file; > > > * Removed the component framework patch altogether; > > > > > > Changes in v5: > > > * Rebased to latest; > > > * Took out component framework support and made it a separate patch so > > >that people can still test with HDP driver, which makes
Re: [PATCH v8 12/17] pwm: crc: Implement apply() method to support the new atomic PWM API
On Sun, Aug 30, 2020 at 02:57:48PM +0200, Hans de Goede wrote: > Replace the enable, disable and config pwm_ops with an apply op, > to support the new atomic PWM API. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v6: > - Rebase on 5.9-rc1 > - Use do_div when calculating level because pwm_state.period and .duty_cycle > are now u64 > > Changes in v3: > - Keep crc_pwm_calc_clk_div() helper to avoid needless churn > --- > drivers/pwm/pwm-crc.c | 89 ++- > 1 file changed, 54 insertions(+), 35 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 13/17] pwm: crc: Implement get_state() method
On Sun, Aug 30, 2020 at 02:57:49PM +0200, Hans de Goede wrote: > Implement the pwm_ops.get_state() method to complete the support for the > new atomic PWM API. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v6: > - Rebase on 5.9-rc1 > - Use DIV_ROUND_UP_ULL because pwm_state.period and .duty_cycle are now u64 > > Changes in v5: > - Fix an indentation issue > > Changes in v4: > - Use DIV_ROUND_UP when calculating the period and duty_cycle from the > controller's register values > > Changes in v3: > - Add Andy's Reviewed-by tag > - Remove extra whitespace to align some code after assignments (requested by > Uwe Kleine-König) > --- > drivers/pwm/pwm-crc.c | 31 +++ > 1 file changed, 31 insertions(+) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 11/17] pwm: crc: Enable/disable PWM output on enable/disable
On Sun, Aug 30, 2020 at 02:57:47PM +0200, Hans de Goede wrote: > The pwm-crc code is using 2 different enable bits: > 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE) > 2. bit 0 of the BACKLIGHT_EN register > > So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM, > this commit makes crc_pwm_disable() clear it on disable and makes > crc_pwm_enable() set it again on re-enable. > > Acked-by: Uwe Kleine-König > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v3: > - Remove paragraph about tri-stating the output from the commit message, > we don't have a datasheet so this was just an unfounded guess > --- > drivers/pwm/pwm-crc.c | 4 > 1 file changed, 4 insertions(+) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 10/17] pwm: crc: Fix period changes not having any effect
On Sun, Aug 30, 2020 at 02:57:46PM +0200, Hans de Goede wrote: > The pwm-crc code is using 2 different enable bits: > 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE) > 2. bit 0 of the BACKLIGHT_EN register > > The BACKLIGHT_EN register at address 0x51 really controls a separate > output-only GPIO which is earmarked to be used as output connected to the > backlight-enable pin for LCD panels, this GPO is part of the PMIC's > "Display Panel Control Block." . This pin should probably be moved over > to a GPIO provider driver (and consumers modified accordingly), but that > is something for an(other) patch. > > Enabling / disabling the actual PWM output is controlled by the > PWM_OUTPUT_ENABLE bit of the PWM0_CLK_DIV register. > > As the comment in the old code already indicates we must disable the PWM > before we can change the clock divider. But the crc_pwm_disable() and > crc_pwm_enable() calls the old code make for this only change the > BACKLIGHT_EN register; and the value of that register does not matter for > changing the period / the divider. What does matter is that the > PWM_OUTPUT_ENABLE bit must be cleared before a new value can be written. > > This commit modifies crc_pwm_config() to clear PWM_OUTPUT_ENABLE instead > when changing the period, so that period changes actually work. > > Note this fix will cause a significant behavior change on some devices > using the CRC PWM output to drive their backlight. Before the PWM would > always run with the output frequency configured by the BIOS at boot, now > the period time specified by the i915 driver will actually be honored. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > drivers/pwm/pwm-crc.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 09/17] pwm: crc: Fix off-by-one error in the clock-divider calculations
On Sun, Aug 30, 2020 at 02:57:45PM +0200, Hans de Goede wrote: > The CRC PWM controller has a clock-divider which divides the clock with > a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx > defines, this range maps to a register value of 0-127. > > So after calculating the clock-divider we must subtract 1 to get the > register value, unless the requested frequency was so high that the > calculation has already resulted in a (rounded) divider value of 0. > > Note that before this fix, setting a period of PWM_MAX_PERIOD_NS which > corresponds to the max. divider value of 128 could have resulted in a > bug where the code would use 128 as divider-register value which would > have resulted in an actual divider value of 0 (and the enable bit being > set). A rounding error stopped this bug from actually happen. This > same rounding error means that after the subtraction of 1 it is impossible > to set the divider to 128. Also bump PWM_MAX_PERIOD_NS by 1 ns to allow > setting a divider of 128 (register-value 127). > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v3: > - Introduce crc_pwm_calc_clk_div() here instead of later in the patch-set > to reduce the amount of churn in the patch-set a bit > --- > drivers/pwm/pwm-crc.c | 17 ++--- > 1 file changed, 14 insertions(+), 3 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 08/17] pwm: crc: Fix period / duty_cycle times being off by a factor of 256
On Sun, Aug 30, 2020 at 02:57:44PM +0200, Hans de Goede wrote: > While looking into adding atomic-pwm support to the pwm-crc driver I > noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and > there is a clock-divider which divides this with a value between 1-128, > and there are 256 duty-cycle steps. > > The pwm-crc code before this commit assumed that a clock-divider > setting of 1 means that the PWM output is running at 6 MHZ, if that > is true, where do these 256 duty-cycle steps come from? > > This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that > seems unlikely for a PMIC which is using a silicon process optimized for > power-switching transistors. It is way more likely that there is an 8 > bit counter for the duty cycle which acts as an extra fixed divider > wrt the PWM output frequency. > > The main user of the pwm-crc driver is the i915 GPU driver which uses it > for backlight control. Lets compare the PWM register values set by the > video-BIOS (the GOP), assuming the extra fixed divider is present versus > the PWM frequency specified in the Video-BIOS-Tables: > > Device: PWM Hz set by BIOS PWM Hz specified in VBT > Asus T100TA 200 200 > Asus T100HA 200 200 > Lenovo Miix 2 8 23437 2 > Toshiba WT8-A 23437 2 > > So as we can see if we assume the extra division by 256 then the register > values set by the GOP are an exact match for the VBT values, where as > otherwise the values would be of by a factor of 256. > > This commit fixes the period / duty_cycle calculations to take the > extra division by 256 into account. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v3: > - Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define > --- > drivers/pwm/pwm-crc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 07/17] pwm: lpss: Always update state and set update bit
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
> This commit removes a check where we would skip writing the ctrl register
> and then setting the update bit in case the ctrl register already contains
> the correct values.
>
> In a perfect world skipping the update should be fine in these cases, but
> on Cherry Trail devices the AML code in the GFX0 devices' PS0 and PS3
> methods messes with the PWM controller.
>
> The "ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase" patch
> earlier in this series stops the GFX0._PS0 method from messing with the PWM
> controller and on the DSDT-s inspected sofar the _PS3 method only reads
> from the PWM controller (and turns it off before we get a change to do so):
>
> {
> PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PSAT |= 0x03
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> }
>
> The PWM controller getting turning off before we do this ourselves is
> a bit annoying but not really an issue.
>
> The problem this patch fixes comes from a new variant of the GFX0._PS3 code
> messing with the PWM controller found on the Acer One 10 S1003 (1):
>
> {
> PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PWMT &= 0xFFFF
> PWMT |= 0xC000
> PWMC = PWMT /* \_SB_.PCI0.GFX0.PWMT */
> PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> Sleep (0x64)
> PWMB &= 0x3FFF
> PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
> PSAT |= 0x03
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> }
>
> This "beautiful" piece of code clears the base-unit part of the ctrl-reg,
> which effectively disables the controller, and it sets the update flag
> to apply this change. Then after this it restores the original ctrl-reg
> value, so we do not see it has mucked with the controller.
>
> *But* it does not set the update flag when restoring the original value.
> So the check to see if we can skip writing the ctrl register succeeds
> but since the update flag was not set, the old base-unit value of 0 is
> still in use and the PWM controller is effectively disabled.
>
> IOW this PWM controller poking means that we cannot trust the base-unit /
> on-time-div value we read back from the PWM controller since it may not
> have been applied/committed. Thus we must always update the ctrl-register
> and set the update bit.
Doesn't this now make patch 6/17 obsolete?
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
