On Wed, 19 Feb 2020, Pavel Machek wrote:
> Hi!
>
> > > > > > > It would be good to get LED backlight to work in clean way for 5.6
> > > > > > > kernel.
> > > > > ...
> > > > > > > [If you have an idea what else is needed, it would be welcome; it
> > > > > > > works for me in development tree but
On 2/18/20 10:01 PM, Daniel Vetter wrote:
On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
wrote:
On 2/17/20 6:55 PM, Daniel Vetter wrote:
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
Implement the importer side of unpinned DMA-buf handling.
v2: update page
Am 18.02.20 um 18:28 schrieb Wambui Karuga:
> As drm_debugfs_create_files() should return 0, remove its use as the
> return value of drm_vram_mm_debugfs_init(), and have the function return
> 0 directly.
>
> Signed-off-by: Wambui Karuga
Acked-by: Thomas Zimmermann
> ---
>
On Wed, 19 Feb 2020 at 03:28, Wambui Karuga wrote:
>
> As there is no need to check for the return value of debugfs_create_file
> and drm_debugfs_create_files, remove unnecessary checks and error
> handling in nouveau_drm_debugfs_init.
Thanks!
>
> Signed-off-by: Wambui Karuga
> ---
>
This reverts commit ff57c6513820efe945b61863cf4a51b79f18b592.
With the commit ff57c6513820 ("drm: kirin: Fix for hikey620
display offset problem") we added support for handling LDI
overflows by resetting the hardware.
However, its been observed that when we do hit the LDI overflow
condition, the
On Tue, Feb 18, 2020 at 11:16:38PM +0100, Sam Ravnborg wrote:
> On Tue, Feb 18, 2020 at 02:13:45PM -0600, Rob Herring wrote:
> > On Sun, Feb 16, 2020 at 12:15 PM Sam Ravnborg wrote:
> > >
> > > Add data-mapping property that can be used to specify
> > > the media format used for the connection
Use a boolean variable to track whether a context has been
initiated.
v3: Fix possible race via spinlock (@olv)
v4: Fix commit message
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8
For old userspace, initialization will still be implicit.
For backwards compatibility, enqueue virtio_gpu_cmd_context_create after
the first 3D ioctl.
v3: staticify virtio_gpu_create_context
remove notify to batch vm-exit
Signed-off-by: Gurchetan Singh
---
We currently create an OpenGL context when opening the DRM fd
if 3D is available.
We may need other context types (VK,..) in the future, and the plan
is to have explicit initialization for that.
For explicit initialization to work, we need to factor out
virtio_gpu_create_context from driver
Use an atomic variable to track whether a context has been
initiated.
v3: Fix possible race via spinlock (@olv)
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
We'll have to do something like this eventually, and this
conveys we want a Virgl context by default.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git
Minor cleanup, change:
- file_priv--> file,
- drm_file --> file.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each
Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615
Summary of Vulnerability
Insufficient control flow in certain data structures for some Intel(R)
Processors with Intel Processor Graphics may allow an unauthenticated
user to potentially enable information disclosure via
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require
Hi!
> > > > > > It would be good to get LED backlight to work in clean way for 5.6
> > > > > > kernel.
> > > > ...
> > > > > > [If you have an idea what else is needed, it would be welcome; it
> > > > > > works for me in development tree but not in tree I'd like to
> > > > > > upstream.]
> > > >
On Tue, Feb 18, 2020 at 01:20:12PM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Also log buffers with the DUMP flag set, to ensure we capture all useful
> cmdstream in crashdump state with modern mesa.
>
> Otherwise we miss out on the contents of "state object" cmdstream
> buffers.
>
> v2:
On Tue, Feb 18, 2020 at 01:00:21PM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Also log buffers with the DUMP flag set, to ensure we capture all useful
> cmdstream in crashdump state with modern mesa.
>
> Otherwise we miss out on the contents of "state object" cmdstream
> buffers.
One nit,
On Tue, Feb 18, 2020 at 05:28:51PM +0100, Paolo Bonzini wrote:
> On 14/02/20 23:03, Sean Christopherson wrote:
> >> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu wrote:
> >>> AFAICT, it is currently allowed on ARM (verified) and AMD (not
> >>> verified, but svm_get_mt_mask returns 0 which supposedly
On Tue, Feb 18, 2020 at 02:13:45PM -0600, Rob Herring wrote:
> On Sun, Feb 16, 2020 at 12:15 PM Sam Ravnborg wrote:
> >
> > Add data-mapping property that can be used to specify
> > the media format used for the connection betwwen the
> > display controller (connector) and the panel.
> >
https://bugzilla.kernel.org/show_bug.cgi?id=205915
--- Comment #15 from Manuel Ullmann (la...@posteo.de) ---
That fixed it. Thanks.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
On Sun, Feb 2, 2020 at 2:03 PM Ramalingam C wrote:
>
> On 2020-01-17 at 14:30:59 -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch is required for HDCP over MST. If a port is being used for
> > multiple HDCP streams, we don't want to fully disable HDCP on a port if
> > one of them
https://bugzilla.kernel.org/show_bug.cgi?id=205915
--- Comment #14 from Alex Deucher (alexdeuc...@gmail.com) ---
See also:
https://bugzilla.kernel.org/show_bug.cgi?id=205915
https://bugzilla.kernel.org/show_bug.cgi?id=206393
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=206393
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
See also:
https://bugzilla.kernel.org/show_bug.cgi?id=205915
https://bugzilla.kernel.org/show_bug.cgi?id=206393
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--- Comment #9 from Noel Maersk (veox+ker...@veox.pw) ---
Some of the commits that got skipped in that `git bisect log` of mine actually
come before the one above when viewing `git log`. :/
Guess I'll try the bisect again in coming days.
--
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Cc: Lyude Paul
Signed-off-by: Sean Paul
Changes in v4:
-Added to the set
---
drivers/gpu/drm/drm_dp_mst_topology.c | 117 ++
include/drm/drm_dp_helper.h | 3 +
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
From: Sean Paul
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run
#v2
Link:
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean
From: Sean Paul
Hey all,
Back with a v4. Rebased on latest drm-tip.
Biggest change was adding the QUERY_STREAM_ENCRYPTION_STATUS check which
ensures not only the link to the first branch is encrypted, but also
that the channel iteself is also protected.
Sean
Sean Paul (14):
drm/i915: Fix
On Fri, Feb 14, 2020 at 10:36 AM Jordan Crouse wrote:
>
> If the opp table specifies opp-supported-hw as a property but the driver
> has not set a supported hardware value the OPP subsystem will reject
> all the table entries.
>
> Set a "default" value that will match the default table entries
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--- Comment #8 from Noel Maersk (veox+ker...@veox.pw) ---
The
*ERROR* Couldn't read SADs: -2
in my and Thomas' logs are unrelated to the issue, I believe, and pertain to
sound (HDMI sound?..).
The error comes from
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--- Comment #7 from Noel Maersk (veox+ker...@veox.pw) ---
`git bisect log` output at:
https://gist.github.com/veox/36aeb77acfbcaea9c4ba1cc70052329a
Had to `skip` a few because of system instability on v5.5.4 (cause unknown,
likely
unrelated to
Den 18.02.2020 21.57, skrev Andy Shevchenko:
> On Sun, Feb 16, 2020 at 7:30 PM Noralf Trønnes wrote:
>>
>> Hi,
>>
>> A while back I had the idea to turn a Raspberry Pi Zero into a $5
>> USB to HDMI/SDTV/DSI/DPI display adapter.
>>
>> Thinking about how to represent the display to the driver I
From: Rob Clark
Also log buffers with the DUMP flag set, to ensure we capture all useful
cmdstream in crashdump state with modern mesa.
Otherwise we miss out on the contents of "state object" cmdstream
buffers.
v2: add missing 'inline'
Signed-off-by: Rob Clark
---
From: Rob Clark
Also log buffers with the DUMP flag set, to ensure we capture all useful
cmdstream in crashdump state with modern mesa.
Otherwise we miss out on the contents of "state object" cmdstream
buffers.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h | 10 ++
On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
wrote:
>
> On 2/17/20 6:55 PM, Daniel Vetter wrote:
> > On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> >> Implement the importer side of unpinned DMA-buf handling.
> >>
> >> v2: update page tables immediately
> >>
> >>
On Sun, Feb 16, 2020 at 7:30 PM Noralf Trønnes wrote:
>
> Hi,
>
> A while back I had the idea to turn a Raspberry Pi Zero into a $5
> USB to HDMI/SDTV/DSI/DPI display adapter.
>
> Thinking about how to represent the display to the driver I realised
> that hardware use registers as API. And Linux
On Thu, Feb 13, 2020 at 09:19:42PM +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> The MediaTek DRM has a block called mmsys, which sets
> the routing and enables the different blocks.
> This patch adds one line for the mmsys bindings description and changes
> the mmsys
On 2/17/20 6:55 PM, Daniel Vetter wrote:
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
Implement the importer side of unpinned DMA-buf handling.
v2: update page tables immediately
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66
On Sun, Feb 16, 2020 at 12:15 PM Sam Ravnborg wrote:
>
> Add data-mapping property that can be used to specify
> the media format used for the connection betwwen the
> display controller (connector) and the panel.
> Signed-off-by: Sam Ravnborg
Missing blank line.
> ---
>
On Sun, Feb 16, 2020 at 12:15 PM Sam Ravnborg wrote:
>
> With panel-timing converted, now convert the single
> remaining .txt user in panel/ of panel-timing to DT schema.
>
> v2:
> - Drop Thierry as maintainer, as this is not a general panel binding
> and I have no acks.
> - Drop
On Tue, Feb 18, 2020 at 08:00:30PM +0100, Daniel Vetter wrote:
> On Tue, Feb 18, 2020 at 6:28 PM Wambui Karuga
> wrote:
> >
> > As drm_debugfs_create_files should return void, remove its use as the
> > return value of arcpgu_debugfs_init and have the latter function
> > return 0 directly.
> >
>
On Tue, Feb 18, 2020 at 04:57:44PM +0100, Torsten Duwe wrote:
> drm_dp_link_rate_to_bw_code and ...bw_code_to_link_rate simply divide by
> and multiply with 27000, respectively. Avoid an overflow in the u8 dpcd[0]
> and the multiply+divide alltogether.
>
> fixes: ff1e8fb68ea06027
On Tue, Feb 18, 2020 at 08:28:14PM +0300, Wambui Karuga wrote:
> As there is no need to check the return value of
> drm_debugfs_create_files, remove unnecessary checks and error handling
> statement blocks.
>
> Signed-off-by: Wambui Karuga
I'd split this up a bit differently, with a patch per
On Tue, Feb 18, 2020 at 07:37:44PM +0100, Christian König wrote:
> Am 18.02.20 um 19:28 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 18.02.20 um 19:23 schrieb Christian König:
> > > Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
> > > > Hi
> > > >
> > > > Am 18.02.20 um 18:13 schrieb Nirmoy:
>
On Tue, Feb 18, 2020 at 6:28 PM Wambui Karuga wrote:
>
> As drm_debugfs_create_files should return void, remove its use as the
> return value of arcpgu_debugfs_init and have the latter function
> return 0 directly.
>
> Signed-off-by: Wambui Karuga
> ---
> drivers/gpu/drm/arc/arcpgu_drv.c | 6
Am 18.02.20 um 19:28 schrieb Thomas Zimmermann:
Hi
Am 18.02.20 um 19:23 schrieb Christian König:
Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
Hi
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am
Hi
Am 18.02.20 um 19:23 schrieb Christian König:
> Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
>> Hi
>>
>> Am 18.02.20 um 18:13 schrieb Nirmoy:
>>> On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
> Hi
>
> Am 17.02.20 um 16:04 schrieb
On 2/18/20 7:16 PM, Thomas Zimmermann wrote:
Hi
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
https://bugzilla.kernel.org/show_bug.cgi?id=206519
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 287487
--> https://bugzilla.kernel.org/attachment.cgi?id=287487=edit
possible fix
I think this patch should fix it.
--
You are receiving this mail because:
You
Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
Hi
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
On Tue, Feb 18, 2020 at 08:28:12PM +0300, Wambui Karuga wrote:
> As drm_debugfs_create_files should return void, remove its use as the
> return value of arcpgu_debugfs_init and have the latter function
> return 0 directly.
>
> Signed-off-by: Wambui Karuga
> ---
>
Hi
Am 18.02.20 um 18:13 schrieb Nirmoy:
>
> On 2/18/20 1:44 PM, Christian König wrote:
>> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
>>> Hi
>>>
>>> Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
device
driver.
https://bugzilla.kernel.org/show_bug.cgi?id=206575
Thomas Frank (thfr...@e.mail.de) changed:
What|Removed |Added
CC||thfr...@e.mail.de
---
On Di, 2020-02-18 at 20:28 +0300, Wambui Karuga wrote:
> As there is no need to check the return value if
> drm_debugfs_create_files,
And here is where the commit message skips a very important
information: Since 987d65d01356 (drm: debugfs: make
drm_debugfs_create_files() never fail) this
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
device
driver.
Signed-off-by: Nirmoy Das
---
https://bugzilla.kernel.org/show_bug.cgi?id=206519
--- Comment #4 from Shlomo (shl...@fastmail.com) ---
I bisected the bug.
The first bad commit is 96a3b32e67236f547cc8acd69d5a3cef125b2295
(drm/amd/display: only enable HDCP for DCN+) with
ea268870d6f548d0661e896e9746673210c1fa79
https://bugzilla.kernel.org/show_bug.cgi?id=206519
Shlomo (shl...@fastmail.com) changed:
What|Removed |Added
Summary|[amdgpu] kernel NULL|[amdgpu] kernel NULL
On Tue, Feb 18, 2020 at 10:52:06AM -0500, Sean Paul wrote:
> On Mon, Feb 17, 2020 at 07:08:37AM +, Lin, Wayne wrote:
> > [AMD Public Use]
> >
> >
> >
> > > -Original Message-
> > > From: Sean Paul
> > > Sent: Saturday, February 15, 2020 12:09 AM
> > > To: Lin, Wayne
> > > Cc:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
device
driver.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/ttm/ttm_bo.c | 7
On 14/02/20 23:03, Sean Christopherson wrote:
>> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu wrote:
>>> AFAICT, it is currently allowed on ARM (verified) and AMD (not
>>> verified, but svm_get_mt_mask returns 0 which supposedly means the NPT
>>> does not restrict what the guest PAT can do). This
On Fri, Feb 14, 2020 at 06:33:17PM -0500, Lyude Paul wrote:
> On Thu, 2020-02-13 at 16:15 -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > Hey all,
> > Earlier this week on my 5.5 kernel (I can't seem to get a 5.6 kernel to
> > behave on any of my devices), I ran into the multi-reply problem
drm_dp_link_rate_to_bw_code and ...bw_code_to_link_rate simply divide by
and multiply with 27000, respectively. Avoid an overflow in the u8 dpcd[0]
and the multiply+divide alltogether.
fixes: ff1e8fb68ea06027 ("analogix-anx78xx: Avoid drm_dp_link helpers")
Signed-off-by: Torsten Duwe
On 2/18/20 1:42 PM, Thomas Zimmermann wrote:
Hi,
the email's subject line should contain the version of the patchset
(e.g, v2, v3, etc). git send-mail adds this with the -v switch
Thanks Thomas. I over looked that, will add version tag from my next
emails.
Nirmoy
Best regards
Thomas
of_get_regulator() will unconditionally add "-supply" to form the
property name. This is documented in commit 69511a452e6dc ("map consumer
regulator based on device tree"). Remove the suffix from the requests.
Signed-off-by: Torsten Duwe
Reviewed-by: Mark Brown
---
Mark has actually reviewed
On Mon, Feb 17, 2020 at 07:08:37AM +, Lin, Wayne wrote:
> [AMD Public Use]
>
>
>
> > -Original Message-
> > From: Sean Paul
> > Sent: Saturday, February 15, 2020 12:09 AM
> > To: Lin, Wayne
> > Cc: dri-devel@lists.freedesktop.org; ly...@redhat.com; Sean Paul
> > ; Maarten
On 18/02/2020 16:15, Boris Brezillon wrote:
> Commit 751465913f04 ("drm/bridge: Add a drm_bridge_state object")
> introduced new helpers and hooks but the kernel was slightly broken.
> Fix that now.
>
> v2:
> * Fix the drm_atomic_add_encoder_bridges() doc
>
> Fixes: 751465913f04 ("drm/bridge:
drm_dp_link_rate_to_bw_code and ...bw_code_to_link_rate simply divide by
and multiply with 27000, respectively. Avoid an overflow in the u8 dpcd[0]
and the multiply+divide alltogether.
fixes: e1cff82c1097bda2478 ("fix anx6345 compilation for v5.5")
Signed-off-by: Torsten Duwe
---
of_get_regulator() will unconditionally add "-supply" to form the
property name. This is documented in commit 69511a452e6dc ("map consumer
regulator based on device tree"). Remove the suffix from the requests.
Signed-off-by: Torsten Duwe
---
https://patchwork.freedesktop.org/patch/343005/
drm_dp_link_rate_to_bw_code and ...bw_code_to_link_rate simply divide by
and multiply with 27000, respectively. Avoid an overflow in the u8 dpcd[0]
and the multiply+divide alltogether.
fixes: ff1e8fb68ea06027 ("analogix-anx78xx: Avoid drm_dp_link helpers")
Signed-off-by: Torsten Duwe
---
On Wed, Feb 12, 2020 at 03:59:38PM +0530, Ramalingam C wrote:
> As we are not using the sysfs infrastructure anymore, link to it is
> removed. And global srm data and mutex to protect it are removed,
> with required handling at revocation check function.
>
> v2:
> srm_data is dropped and few
On Wed, Feb 12, 2020 at 03:59:41PM +0530, Ramalingam C wrote:
> When roll over detected for seq_num_m, we shouldn't continue with stream
> management with rolled over value.
>
> So we are terminating the stream management retry, on roll over of the
> seq_num_m.
>
> v2:
> using drm_dbg_kms
On Wed, Feb 12, 2020 at 03:59:40PM +0530, Ramalingam C wrote:
> As per the HDCP2.2 compliance test 1B-10 expectation, when stream
> management for a repeater fails, we retry thrice and when it fails
> in all retries, HDCP2.2 reauthentication aborted at kernel.
>
> v2:
> seq_num_m++ is extended
On 18/02/2020 16:15, Boris Brezillon wrote:
> Commit 751465913f04 ("drm/bridge: Add a drm_bridge_state object")
> introduced new helpers and hooks but the kernel was slightly broken.
> Fix that now.
>
> v2:
> * Fix the drm_atomic_add_encoder_bridges() doc
>
> Fixes: 751465913f04 ("drm/bridge:
Commit 751465913f04 ("drm/bridge: Add a drm_bridge_state object")
introduced new helpers and hooks but the kernel was slightly broken.
Fix that now.
v2:
* Fix the drm_atomic_add_encoder_bridges() doc
Fixes: 751465913f04 ("drm/bridge: Add a drm_bridge_state object")
Signed-off-by: Boris Brezillon
Commit 751465913f04 ("drm/bridge: Add a drm_bridge_state object")
introduced new helpers and hooks but the kernel was slightly broken.
Fix that now.
Fixes: 751465913f04 ("drm/bridge: Add a drm_bridge_state object")
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_atomic.c | 5 +++--
On Tue, Feb 18, 2020 at 2:20 PM Christian König
wrote:
>
> Am 05.11.19 um 11:20 schrieb Daniel Vetter:
> > On Tue, Oct 29, 2019 at 11:40:45AM +0100, Christian König wrote:
> > [SNIP]
> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >> index d377b4ca66bf..ce293cee76ed
On Wed, 12 Feb 2020, Pavel Machek wrote:
> Hi!
>
> > > > It would be good to get LED backlight to work in clean way for 5.6
> > > > kernel.
> > ...
> > > > [If you have an idea what else is needed, it would be welcome; it
> > > > works for me in development tree but not in tree I'd like to
> > >
Am 05.11.19 um 11:20 schrieb Daniel Vetter:
On Tue, Oct 29, 2019 at 11:40:45AM +0100, Christian König wrote:
[SNIP]
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..ce293cee76ed 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
Hi,
the email's subject line should contain the version of the patchset
(e.g, v2, v3, etc). git send-mail adds this with the -v switch
Best regards
Thomas
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
> With this patch series I am trying to remove GPU address dependency in
> TTM and moving GPU
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
> GPU address handling is device specific and should be handle by its device
> driver.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
> include/drm/ttm/ttm_bo_api.h| 2 --
> include/drm/ttm/ttm_bo_driver.h | 1
On 2020.02.17 17:38:58 +0100, Julian Stecklina wrote:
> Instead of defining KVMGT per-device state in struct intel_vgpu
> directly, add an indirection. This makes the GVT code oblivious of
> what state KVMGT needs to keep.
>
> The intention here is to eventually make it possible to build
>
The qxl driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
v2:
* rebase onto new simple-encoder interface
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_display.c | 18 +++---
1 file changed, 3 insertions(+),
The mgag200 driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
v2:
* rebase onto new simple-encoder interface
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 7 ---
drivers/gpu/drm/mgag200/mgag200_mode.c
This patch makes the internal encoder implementation of the simple
KMS helpers available to drivers.
These simple-encoder helpers initialize an encoder with an empty
implementation. This covers the requirements of most of the existing
DRM drivers. A call to drm_simple_encoder_create() allocates
Many DRM drivers implement an encoder with an empty implementation. This
patchset adds drm_simple_encoder_init() and drm_simple_encoder_create(),
which can be used by drivers instead. Except for the destroy callback, the
simple encoder's implementation is empty.
The patchset also converts 4
The ast driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
v2:
* rebase onto new simple-encoder interface
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 6 +-
drivers/gpu/drm/ast/ast_mode.c | 25
Hi, Bibby:
On Fri, 2020-02-14 at 14:48 +0800, CK Hu wrote:
> Hi, Bibby:
>
> On Fri, 2020-02-14 at 12:49 +0800, Bibby Hsieh wrote:
> > Mediatek CMDQ driver removed atomic parameter and implementation
> > related to atomic. DRM driver need to make sure previous message
> > done or be aborted
1 - 100 of 102 matches
Mail list logo
