+ Tvrtko and Chris for comments
Code seems to be added in:
commit 0cd4684d6ea9a4ffec33fc19de4dd667bb90d0a5
Author: Tvrtko Ursulin
Date: Tue Nov 21 18:18:50 2017 +
drm/i915/pmu: Add interrupt count metric
I think later in the thread there was a suggestion to replace this with
simple c
Hi,
On Tue, Dec 08, 2020 at 06:03:05PM +0800, Liu Ying wrote:
> On Tue, 2020-12-08 at 10:24 +0100, Guido Günther wrote:
> > Hi Liu,
> > some minor comments inline:
> >
> > On Fri, Dec 04, 2020 at 03:33:44PM +0800, Liu Ying wrote:
> > > i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which s
Enable HDCP 2.2 over DP MST.
Authenticate and enable port encryption only once for
an active HDCP 2.2 session, once port is authenticated
and encrypted enable encryption for each stream that
requires encryption on this port.
Similarly disable the stream encryption for each encrypted
stream, once a
Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.
v2:
- Added a WARN_ON() instead of drm_err. [Uma]
- Cosmetic changes. [Uma]
v3:
- 's/port_data/hdcp_port_data' [Ram]
- skip redund
Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.
B.Spec: 21780
B.Spec: 14410
B.Spec: 50573
v2
- Modified naming convention of HDCP2_STREAM_STATUS
for pre-gen12 platforms inline with B.Spec.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramal
This requires for HDCP 2.2 MST check link.
As for DP/HDMI shims check_2_2_link retrieves the connector
from dig_port, this is not sufficient or DP MST connector,
there can be multiple DP MST topology connector associated
with same dig_port.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by:
Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.
Security f/w doesn't have any provision to mark the
stream_type for each stream separately, it just take
single input of stream_type while authentic
Let's define Maximum MST content streams up to four
generically which can be supported by modern display
controllers.
Cc: Sean Paul
Cc: Ramalingam C
Acked-by: Maarten Lankhorst
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
inclu
Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
It is based upon the actual number of MST streams and size
of wired_cmd_repeater_auth_stream_req_in.
Excluding the size of hdcp_cmd_header.
v2:
- hdcp_cmd_header size annotation nitpick. [Tomas]
Cc: Tomas Winkler
Cc: Ramalingam C
A
hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.
v2:
- 's/port_data/hdcp_port_data'. [Ram]
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
T
Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_h
Enable HDCP 1.4 over DP MST for Gen12.
v2:
- Enable HDCP for <= Gen12 platforms. [Ram]
Cc: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/dr
Enable HDCP 1.4 DP MST stream encryption.
Enable stream encryption once encryption is enabled on
the DP transport driving the link for each stream which
has requested encryption.
Disable stream encryption for each stream that no longer
requires encryption before disabling HDCP encryption on
the l
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving th
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and
There can be situation when DP MST connector is created without
mst modeset being done, in those cases connector->encoder will be
NULL. MST connector->encoder initializes after modeset.
Don't enable HDCP in such cases to prevent any crash.
Cc: Ramalingam C
Cc: Juston Li
Tested-by: Karthik B S
S
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.
Cc: "Ville Syrjälä"
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gu
This is v7 version has added some fixes to below pacthes related to
gen11 platform.
[PATCH v7 17/18] drm/i915/hdcp: Support for HDCP 2.2 MST shim
[PATCH v7 16/18] drm/i915/hdcp: Add HDCP 2.2 stream register
It has been tested manually with below IGT series on TGL and ICL.
https://patchwork.freede
Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.
Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing
connectors")
Cc: Sean Paul
Cc: Ramalingam C
Reviewed-by: Uma Shankar
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
fastset instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actual hdcp->value was ENABLED.
This i
Hi Dave, Daniel,
Fixes for 5.11.
The following changes since commit beaff108e1bf1e38c9def60dd09f7a4ed7910481:
drm/amd/powerplay: fix spelling mistake "smu_state_memroy_block" ->
"smu_state_memory_block" (2020-11-24 12:09:54 -0500)
are available in the Git repository at:
git://people.freed
On Mon, 07 Dec 2020 22:50:25 +0800, Kevin Tang wrote:
> From: Kevin Tang
>
> Adds MIPI DSI Controller
> support for Unisoc's display subsystem.
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
> ---
> .../display/sprd/sprd,sharkl3-dsi-host.yaml| 107
> +
On Mon, Dec 07, 2020 at 10:50:23PM +0800, Kevin Tang wrote:
> From: Kevin Tang
>
> DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
> which transfers the image data from a video memory buffer to an internal
> LCD interface.
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Sig
Hi Dave, Daniel,
Fixes for 5.10.
The following changes since commit 0477e92881850d44910a7e94fc2c46f96faa131f:
Linux 5.10-rc7 (2020-12-06 14:25:12 -0800)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.10-2020-12-09
for you to fetch ch
On Mon, 07 Dec 2020 22:50:21 +0800, Kevin Tang wrote:
> From: Kevin Tang
>
> The Unisoc DRM master device is a virtual device needed to list all
> DPU devices or other display interface nodes that comprise the
> graphics subsystem
>
> Unisoc's display pipeline have several components as below
>
On Mon, 07 Dec 2020 15:09:34 +0100, Oleksij Rempel wrote:
> So far, this panel seems to be compatible with "lg,lb070wv8", on other
> hand it is better to set this compatible in the devicetree. So, let's
> add it for now only to the dt-binding documentation to fix the
> checkpatch warnings.
>
> Sig
On Mon, 07 Dec 2020 15:09:33 +0100, Oleksij Rempel wrote:
> Some EDT compatibles are already supported by the driver but will fail
> on checkpatch script. Fix it by syncing dt-bindings documentation with the
> driver.
>
> Signed-off-by: Oleksij Rempel
> ---
> .../devicetree/bindings/display/pane
On Mon, 07 Dec 2020 15:09:32 +0100, Oleksij Rempel wrote:
> Reorder it alphabetically and remove one double entry.
>
> Signed-off-by: Oleksij Rempel
> ---
> .../bindings/display/panel/panel-simple.yaml | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
Reviewed-by:
On Sun, 06 Dec 2020 14:33:51 +0100, Johan Jonker wrote:
> '#sound-dai-cells' is required to properly interpret
> the list of DAI specified in the 'sound-dai' property.
> Add it to rockchip,rk3066-hdmi.yaml to document that the
> rk3066 HDMI TX also can be used to transmit some audio.
>
> Signed-of
This patch does not change current behaviour.
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.
Default behaviour as of this patch, is preserved,
except
The driver's timeout handler now returns a value back up to DRM.
This patch doesn't change current behaviour. I request it'd be applied
so that Andrey G. can take advantage of the value sent back up to DRM
from the GPU driver.
I'm still working on the last patch which takes advantage of this
patc
On Mon, Dec 07, 2020 at 10:40:22PM -0600, Bjorn Andersson wrote:
> The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
> with the primary purpose of controlling the backlight of the attached
> panel. Add an implementation that exposes this using the standard PWM
> framework, to all
This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of),
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control bit
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
thi
eDP doesn't do hotplugging, so there's no reason for us to reprobe it (unless a
connection status change is being forced, of course).
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++
1 file changed,
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
This series:
* Cleans up i915's DPCD backlight code a little bit
* Extracts i915's DPCD backlight code into a set of shared DRM helpers
* Starts using those helpers in nouveau to add support to nouveau for
DPCD backlight control
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
Lyude
On Wed, Dec 09, 2020 at 04:16:36PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> No need to spam syslog/console when we can ignore/fix the flag.
besides that we are calling from multiple places anyway..
>
> Signed-off-by: Sean Paul
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915
Hi Dave and Daniel,
The commit 7c5c15dffe1e ("drm/i915/gt: Declare gen9 has 64 mocs entries!")
should actually be sent last week along with the commit
777a7717d60c ("drm/i915/gt: Program mocs:63 for cache eviction on gen9"),
but I had missed that and dim didn't cope with fixes for fixes.
Here goe
Add a missing structure comment for the recently
added @list member.
Cc: Stephen Rothwell
Cc: Daniel Vetter
Cc: Christian König
Fixes: 8935ff00e3b1 ("drm/scheduler: "node" --> "list"")
Reported-by: Stephen Rothwell
Signed-off-by: Luben Tuikov
---
include/drm/gpu_scheduler.h | 2 +-
1 file c
On 2020-12-09 5:24 p.m., Stephen Rothwell wrote:
> Hi Luben,
>
> On Wed, 9 Dec 2020 16:58:07 -0500 Luben Tuikov wrote:
>>
>> Add a missing structure comment for the recently
>> added @list member.
>>
>> Signed-off-by: Luben Tuikov
>>
>> Cc: Stephen Rothwell
>> Cc: Daniel Vetter
>> Cc: Christi
Hi Luben,
On Wed, 9 Dec 2020 16:58:07 -0500 Luben Tuikov wrote:
>
> Add a missing structure comment for the recently
> added @list member.
>
> Signed-off-by: Luben Tuikov
>
> Cc: Stephen Rothwell
> Cc: Daniel Vetter
> Cc: Christian König
The commit message tags should all be together at t
On Thu, Dec 10, 2020 at 12:34:53AM +0530, Sumera Priyadarsini wrote:
> Update the vkms documentation to contain steps to:
>
> - setup the vkms driver
> - run tests using igt
>
> Signed-off-by: Sumera Priyadarsini
> ___
> Changes in v2:
> - Change heading to title case (Daniel)
> - Add exampl
Add a missing structure comment for the recently
added @list member.
Signed-off-by: Luben Tuikov
Cc: Stephen Rothwell
Cc: Daniel Vetter
Cc: Christian König
---
include/drm/gpu_scheduler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/gpu_scheduler.h b/includ
From: Sean Paul
No need to spam syslog/console when we can ignore/fix the flag.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_tc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel
On Wed, Dec 09, 2020 at 10:10:47PM +0100, Daniel Vetter wrote:
> On Tue, Dec 08, 2020 at 04:59:16PM +0100, Philipp Zabel wrote:
> > On Tue, 2020-12-08 at 16:54 +0100, Philipp Zabel wrote:
> > > Hi,
> > >
> > > this is an update of the drmm_(simple_)encoder_alloc(),
> > > drmm_universal_plane_alloc
On Tue, Dec 08, 2020 at 04:59:16PM +0100, Philipp Zabel wrote:
> On Tue, 2020-12-08 at 16:54 +0100, Philipp Zabel wrote:
> > Hi,
> >
> > this is an update of the drmm_(simple_)encoder_alloc(),
> > drmm_universal_plane_alloc(), and drmm_crtc_alloc_with_plane()
> > functions in v3 [1] together with
On Tue, Dec 08, 2020 at 04:54:37PM +0100, Philipp Zabel wrote:
> Add an alternative to drm_crtc_init_with_planes() that allocates
> and initializes a crtc and registers drm_crtc_cleanup() with
> drmm_add_action_or_reset().
>
> Signed-off-by: Philipp Zabel
> Reviewed-by: Laurent Pinchart
Same bi
On Thu, 03 Dec 2020 22:24:30 +0300, Dmitry Osipenko wrote:
> Document opp-supported-hw property, which is not strictly necessary to
> have on Tegra20, but it's very convenient to have because all other SoC
> core devices will use hardware versioning, and thus, it's good to maintain
> the consistenc
On Tue, Dec 08, 2020 at 04:54:36PM +0100, Philipp Zabel wrote:
> Add an alternative to drm_universal_plane_init() that allocates
> and initializes a plane and registers drm_plane_cleanup() with
> drmm_add_action_or_reset().
>
> Signed-off-by: Philipp Zabel
> Reviewed-by: Laurent Pinchart
> ---
>
On Tue, Dec 08, 2020 at 04:54:35PM +0100, Philipp Zabel wrote:
> Add an alternative to drm_simple_encoder_init() that allocates and
> initializes a simple encoder and registers drm_encoder_cleanup() with
> drmm_add_action_or_reset().
>
> Signed-off-by: Philipp Zabel
> Reviewed-by: Laurent Pinchar
On Wed, Dec 09, 2020 at 11:34:44AM +0200, Jani Nikula wrote:
> On Tue, 08 Dec 2020, Jani Nikula wrote:
> > For whatever reason this old series was never merged. Please let's get
> > this done.
>
> Daniel, Maarten, may I have an ack to merge patches 1 and 4 via
> drm-intel?
Ack.
-Daniel
>
> BR,
On Wed, Dec 09, 2020 at 04:35:31PM +, Simon Ser wrote:
> On Wednesday, December 9th, 2020 at 5:02 PM, Daniel Vetter
> wrote:
>
> > On Wed, 9 Dec 2020 01:42:23 +0100
> > Daniel Vetter wrote:
> >
> > > On Sun, Dec 06, 2020 at 04:34:15PM +, Simon Ser wrote:
> > > > The previous wording cou
Update the vkms documentation to contain steps to:
- setup the vkms driver
- run tests using igt
Signed-off-by: Sumera Priyadarsini
___
Changes in v2:
- Change heading to title case (Daniel)
- Add examples to run tests directly (Daniel)
- Add examples to run subtests (Melissa)
Changes in v
> -Original Message-
> From: Leon Romanovsky
> Sent: Tuesday, December 08, 2020 10:45 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Jason Gunthorpe ;
> Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
> Subject: Re: [PATCH
> -Original Message-
> From: Yishai Hadas
> Sent: Tuesday, December 08, 2020 11:13 PM
> To: Xiong, Jianxin
> Cc: Doug Ledford ; Jason Gunthorpe ; Leon
> Romanovsky ; Sumit Semwal
> ; Christian Koenig ;
> Vetter, Daniel ; linux-
> r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Yi
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20201209]
[cannot apply to drm-exynos/exynos-drm-next drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.10-rc7]
[If
> -Original Message-
> From: Leon Romanovsky
> Sent: Tuesday, December 08, 2020 10:31 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Jason Gunthorpe ;
> Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
> Subject: Re: [PATCH
Hi,
On Tue, Dec 01, 2020 at 11:35:35AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert nouveau to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/dispnv04/arb.c | 12
Hi Ankit,
url:
https://github.com/0day-ci/linux/commits/Ankit-Nautiyal/Add-support-for-DP-HDMI2-1-PCON/20201208-160027
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-m021-20201209 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20201209]
[cannot apply to drm-exynos/exynos-drm-next drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.10-rc7]
[If
On Wed, 2020-12-09 at 14:11 +0200, Ville Syrjälä wrote:
> On Thu, Dec 03, 2020 at 05:47:05AM -0800, Rodrigo Vivi wrote:
> > Hi Dave and Daniel,
> >
> > Please ignore the pull request I had sent yesterday and use only
> > this one.
> >
> > I had missed one patch: 14d1eaf08845 ("drm/i915/gt: Protec
On 12/9/20 5:37 PM, Jason Gunthorpe wrote:
On Wed, Dec 09, 2020 at 05:36:16PM +0100, Thomas Hellström (Intel) wrote:
Jason, Christian
In most implementations of the callback mentioned in the subject there's a
fence wait.
What exactly is it needed for?
Invalidate must stop DMA before returning
Jason, Christian
In most implementations of the callback mentioned in the subject there's
a fence wait.
What exactly is it needed for?
Thanks,
Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailma
On 09/12/2020 14:08, Daniel Vetter wrote:
> On Wed, Dec 9, 2020 at 1:06 PM Tomi Valkeinen wrote:
>>
>> On 09/12/2020 13:56, Daniel Vetter wrote:
>>> On Wed, Dec 9, 2020 at 12:29 PM Tomi Valkeinen
>>> wrote:
On 09/12/2020 02:48, Daniel Vetter wrote:
> On Tue, Dec 08, 2020 at 03:50:5
On Wednesday, December 9th, 2020 at 5:02 PM, Daniel Vetter
wrote:
> On Wed, 9 Dec 2020 01:42:23 +0100
> Daniel Vetter wrote:
>
> > On Sun, Dec 06, 2020 at 04:34:15PM +, Simon Ser wrote:
> > > The previous wording could be understood by user-space evelopers as "a
> > > primary/cursor plane i
On Wednesday, December 9th, 2020 at 5:02 PM, Daniel Vetter
wrote:
> On Wed, Dec 09, 2020 at 03:58:17PM +, Simon Ser wrote:
> > Thanks for the review!
> >
> > On Wednesday, December 9th, 2020 at 1:42 AM, Daniel Vetter
> > wrote:
> >
> > > I think maybe a follow up patch should document how
On 2020-12-09 05:02, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced this warning:
>
> include/drm/gpu_scheduler.h:201: warning: Function parameter or member 'list'
> not described in 'drm_sched_job'
>
> Introduced by commit
On 09/12/2020 13:56, Daniel Vetter wrote:
> On Wed, Dec 9, 2020 at 12:29 PM Tomi Valkeinen wrote:
>>
>> On 09/12/2020 02:48, Daniel Vetter wrote:
>>> On Tue, Dec 08, 2020 at 03:50:59PM +0800, Tian Tao wrote:
Use devm_drm_irq_install to register interrupts so that
drm_irq_uninstall is not
On Tue, Dec 08, 2020 at 04:54:34PM +0100, Philipp Zabel wrote:
> Add an alternative to drm_encoder_init() that allocates and initializes
> an encoder and registers drm_encoder_cleanup() with
> drmm_add_action_or_reset().
>
> Signed-off-by: Philipp Zabel
> Reviewed-by: Laurent Pinchart
> ---
> Ch
On Wed, Dec 09, 2020 at 03:58:17PM +, Simon Ser wrote:
> Thanks for the review!
>
> On Wednesday, December 9th, 2020 at 1:42 AM, Daniel Vetter
> wrote:
>
> > I think maybe a follow up patch should document how userspace should
> > figure out how to line up the primary planes with the right
On Wed, Dec 09, 2020 at 04:58:05PM +0100, Daniel Vetter wrote:
> On Wed, Dec 09, 2020 at 11:58:44AM +0100, Philipp Zabel wrote:
> > Hi Sam,
> >
> > On Tue, 2020-12-08 at 19:48 +0100, Sam Ravnborg wrote:
> > > Hi Philipp,
> > > On Tue, Dec 08, 2020 at 04:54:33PM +0100, Philipp Zabel wrote:
> > > >
Thanks for the review!
On Wednesday, December 9th, 2020 at 1:42 AM, Daniel Vetter
wrote:
> I think maybe a follow up patch should document how userspace should
> figure out how to line up the primary planes with the right crtcs (if it
> wishes to know that information, it's not super useful asi
On Wed, Dec 09, 2020 at 11:58:44AM +0100, Philipp Zabel wrote:
> Hi Sam,
>
> On Tue, 2020-12-08 at 19:48 +0100, Sam Ravnborg wrote:
> > Hi Philipp,
> > On Tue, Dec 08, 2020 at 04:54:33PM +0100, Philipp Zabel wrote:
> > > Simple managed encoders do not require the .destroy callback,
> > > make the
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> The pixel rate is for now quite simple to compute, but with more features
> (30 and 36 bits output, YUV output, etc.) will depend on a bunch of
> connectors properties.
>
> Let's store the rate we have to run the pixel clock at in ou
On 09/12/2020 02:48, Daniel Vetter wrote:
> On Tue, Dec 08, 2020 at 03:50:59PM +0800, Tian Tao wrote:
>> Use devm_drm_irq_install to register interrupts so that
>> drm_irq_uninstall is not needed to be called.
>>
>> Signed-off-by: Tian Tao
>
> There's another drm_irq_install in the error path. Bu
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> Reported-by: Thomas Zimmermann
> Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within
> limits")
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++
> 1
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> The BCM2711 supports higher bpc count than just 8, so let's support it in
> our driver.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 71 -
> drivers/gpu/drm/vc4/vc4_hdmi
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> Unlike the previous generations, the HSM clock limitation is way above
> what we can reach without scrambling, so let's move the maximum
> frequency we support to the maximum clock frequency without scrambling.
>
> Signed-off-by: Max
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> The PHY initialisation parameters are not based on the pixel clock but
> the TMDS clock rate which can be the pixel clock in the standard case,
> but could be adjusted based on some parameters like the bits per color.
>
> Since the T
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> When run with a higher bpc than 8, the clock of the HDMI controller needs
> to be adjusted. Let's create a connector state that will be used at
> atomic_check and atomic_enable to compute and store the clock rate
> associated to the
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> drm_atomic_helper_connector_reset uses kmalloc which, from an API
> standpoint, can fail, and thus setting connector->state to NULL.
> However, our reset hook then calls drm_atomic_helper_connector_tv_reset
> that will access connect
Hi Daniel,
On 09/12/2020 02:51, Daniel Vetter wrote:
>>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>>> index ba839e5e357d..4d9e217e5040 100644
>>> --- a/include/drm/drm_crtc.h
>>> +++ b/include/drm/drm_crtc.h
>>> @@ -1084,6 +1084,9 @@ struct drm_crtc {
>>> */
>>> uint1
Am Di., 1. Dez. 2020 um 21:38 Uhr schrieb Lubomir Rintel :
>
> Instead of always dumping the rendered picture, check whether it matches
> the expectations. This makes more sense for automated testing.
>
> Retain the ability to dump the picture instead of checking it when a
> file name is given as a
Am Di., 1. Dez. 2020 um 21:38 Uhr schrieb Lubomir Rintel :
>
> Run the test on a core capable of 2D rendering instead of hardcoding to
> core zero.
>
Thanks - I should have done this before landing this test :)
> Signed-off-by: Lubomir Rintel
Reviewed-by: Christian Gmeiner
> ---
> tests/etna
Am Di., 1. Dez. 2020 um 21:38 Uhr schrieb Lubomir Rintel :
>
> Just so that it's obvious what failed and why.
>
> Signed-off-by: Lubomir Rintel
Reviewed-by: Christian Gmeiner
> ---
> tests/etnaviv/etnaviv_2d_test.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> d
Hi
Am 09.12.20 um 15:25 schrieb Thomas Zimmermann:
The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
allowed to pin the buffer or acquire the buffer's reservation object
lock.
This is a problem for callers that only require a short-term mapping
of the buffer without the pinning
Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
Callers that only require a mapping of the contained memory can thus
interfere with other tasks that require exact pinning, such as scanout.
This is less of an is
Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
It's somewhat inconvenient to callers that simply require a mapping of
the contained memory; and also ipmplies a certain overhead.
Therefore provide drm_gem_vram
Fbdev emulation has to lock the BO into place while flushing the shadow
buffer into the BO's memory. Remove any interference with pinning by
using vmap_local functionality (instead of full vmap). This requires
BO reservation locking in fbdev's damage worker.
The new DRM client functions for lockin
The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
allowed to pin the buffer or acquire the buffer's reservation object
lock.
This is a problem for callers that only require a short-term mapping
of the buffer without the pinning, or callers that have special locking
requirements. T
Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
Callers that only require a mapping of the contained memory can thus
interfere with other tasks that require exact pinning, such as scanout.
This is less of an is
The HW cursor's BO used to be mapped permanently into the kernel's
address space. GEM's vmap operation will be protected by locks, and
we don't want to lock the BO's for an indefinate period of time.
Change the cursor code to map the HW BOs only during updates. The
vmap operation in VRAM helpers i
Vmapping the cursor source BO contains an implicit pin operation,
so there's no need to do this manually.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers
This patch adds vmap_local and vunmap_local to struct drm_gem_object_funcs;
including the PRIME helpers to connect with dma-buf's related interfaces.
Besides the generic DRM core, this will become relevant for fbdev emulation
with virtio, so we update it as well.
Signed-off-by: Thomas Zimmermann
(was: drm/vram-helper: Lock GEM BOs while they are mapped)
GEM VRAM helpers used to pin the BO in their implementation of vmap, so
that they could not be relocated. In recent discussions, [1][2] it became
clear that this is incorrect for in-kernel use cases, such as fbdev
emulation; which should r
On Wed, Dec 9, 2020 at 3:10 PM Christian König
wrote:
>
> Based on an idea from Dave, but cleaned up a bit.
>
> We had multiple fields for essentially the same thing.
>
> Now bo->base.size is the original size of the BO in
> arbitrary units, usually bytes.
>
> bo->mem.num_pages is the size in numb
Based on an idea from Dave, but cleaned up a bit.
We had multiple fields for essentially the same thing.
Now bo->base.size is the original size of the BO in
arbitrary units, usually bytes.
bo->mem.num_pages is the size in number of pages in the
resource domain of bo->mem.mem_type.
v2: use the G
1 - 100 of 154 matches
Mail list logo
