All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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: link
Be 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.