From: linus.walleij@linaro.org (Linus Walleij) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 0/3] Bandwidth limitation on PL111, take 2 Date: Tue, 6 Feb 2018 13:18:51 +0100 [thread overview] Message-ID: <20180206121854.4407-1-linus.walleij@linaro.org> (raw) I had to add a hook into the simple KMS helper to be able to gate off too high bandwidths on the PL111. Let me know what you think. This solution is inspired by the OMAPDRM commit a7631c4b9846 "drm/omap: Filter displays mode based on bandwidth limit" by Peter Ujfalusi. I'm not super-happy that we don't know or negotiate the desired pixel format when the CRTC asks the driver whether the mode is valid, I need to think more about this for the future. For now patch 2/2 just hammers that down to 16 or 32 BPP depending on variant, so we get running code. But the BPP is not used to negotiate formats wrt bandwidth, we just fix that variable and work on the resolution limitation. Maybe the 16BPP systems are in such a minority that this hard-coding is reasonable. Linus Walleij (3): drm: simple_kms_helper: Add mode_valid() callback support drm/pl111: Make the default BPP a per-variant variable drm/pl111: Use max memory bandwidth for resolution drivers/gpu/drm/drm_simple_kms_helper.c | 15 +++++++++++++++ drivers/gpu/drm/pl111/pl111_display.c | 30 ++++++++++++++++++++++++++++++ drivers/gpu/drm/pl111/pl111_drm.h | 3 +++ drivers/gpu/drm/pl111/pl111_drv.c | 10 +++++++++- drivers/gpu/drm/pl111/pl111_versatile.c | 2 ++ include/drm/drm_simple_kms_helper.h | 15 +++++++++++++++ 6 files changed, 74 insertions(+), 1 deletion(-) -- 2.14.3
WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org> To: Daniel Vetter <daniel.vetter@intel.com>, Jani Nikula <jani.nikula@linux.intel.com>, Sean Paul <seanpaul@chromium.org>, Eric Anholt <eric@anholt.net>, Peter Ujfalusi <peter.ujfalusi@ti.com>, Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org Subject: [PATCH 0/3] Bandwidth limitation on PL111, take 2 Date: Tue, 6 Feb 2018 13:18:51 +0100 [thread overview] Message-ID: <20180206121854.4407-1-linus.walleij@linaro.org> (raw) I had to add a hook into the simple KMS helper to be able to gate off too high bandwidths on the PL111. Let me know what you think. This solution is inspired by the OMAPDRM commit a7631c4b9846 "drm/omap: Filter displays mode based on bandwidth limit" by Peter Ujfalusi. I'm not super-happy that we don't know or negotiate the desired pixel format when the CRTC asks the driver whether the mode is valid, I need to think more about this for the future. For now patch 2/2 just hammers that down to 16 or 32 BPP depending on variant, so we get running code. But the BPP is not used to negotiate formats wrt bandwidth, we just fix that variable and work on the resolution limitation. Maybe the 16BPP systems are in such a minority that this hard-coding is reasonable. Linus Walleij (3): drm: simple_kms_helper: Add mode_valid() callback support drm/pl111: Make the default BPP a per-variant variable drm/pl111: Use max memory bandwidth for resolution drivers/gpu/drm/drm_simple_kms_helper.c | 15 +++++++++++++++ drivers/gpu/drm/pl111/pl111_display.c | 30 ++++++++++++++++++++++++++++++ drivers/gpu/drm/pl111/pl111_drm.h | 3 +++ drivers/gpu/drm/pl111/pl111_drv.c | 10 +++++++++- drivers/gpu/drm/pl111/pl111_versatile.c | 2 ++ include/drm/drm_simple_kms_helper.h | 15 +++++++++++++++ 6 files changed, 74 insertions(+), 1 deletion(-) -- 2.14.3 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2018-02-06 12:18 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-06 12:18 Linus Walleij [this message] 2018-02-06 12:18 ` [PATCH 0/3] Bandwidth limitation on PL111, take 2 Linus Walleij 2018-02-06 12:18 ` [PATCH 1/3] drm: simple_kms_helper: Add mode_valid() callback support Linus Walleij 2018-02-06 12:18 ` Linus Walleij 2018-02-10 17:08 ` Eric Anholt 2018-02-10 17:08 ` Eric Anholt 2018-02-19 9:40 ` Daniel Vetter 2018-02-19 9:40 ` Daniel Vetter 2018-02-06 12:18 ` [PATCH 2/3] drm/pl111: Make the default BPP a per-variant variable Linus Walleij 2018-02-06 12:18 ` Linus Walleij 2018-02-10 17:10 ` Eric Anholt 2018-02-10 17:10 ` Eric Anholt 2018-02-06 12:18 ` [PATCH 3/3] drm/pl111: Use max memory bandwidth for resolution Linus Walleij 2018-02-06 12:18 ` Linus Walleij 2018-02-10 17:14 ` Eric Anholt 2018-02-10 17:14 ` Eric Anholt 2018-02-11 11:05 ` Linus Walleij 2018-02-11 11:05 ` Linus Walleij 2018-02-22 20:30 ` Eric Anholt 2018-02-22 20:30 ` Eric Anholt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180206121854.4407-1-linus.walleij@linaro.org \ --to=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.