> 2020年2月11日 23:43，Christian König 写道：
>
> When non-imported BOs are resurrected for delayed delete we replace
> the dma_resv object to allow for easy reclaiming of the resources.
>
> v2: move that to ttm_bo_individualize_resv
> v3: add a comment to explain what's going on
>
> Signed-off-by:
On Tue, Feb 11, 2020 at 8:05 PM Jeffrey Hugo wrote:
>
> On Tue, Feb 11, 2020 at 5:28 PM Rob Clark wrote:
> >
> > On Tue, Feb 11, 2020 at 7:59 AM Jeffrey Hugo
> > wrote:
> > >
> > > On Tue, Feb 11, 2020 at 8:44 AM Rob Clark wrote:
> > > >
> > > > On Mon, Feb 10, 2020 at 9:58 PM wrote:
> > > >
On Wed, Feb 12, 2020 at 4:09 AM Saravana Kannan wrote:
>
> On Tue, Feb 11, 2020 at 11:44 AM Rob Herring wrote:
> >
> > +Saravana
> >
> > On Thu, Feb 6, 2020 at 11:27 PM Nicolas Boichat
> > wrote:
> > >
> > > When there is a single power domain per device, the core will
> > > ensure the power
On Tue, Feb 11, 2020 at 2:09 PM Saravana Kannan wrote:
>
> On Tue, Feb 11, 2020 at 11:44 AM Rob Herring wrote:
> >
> > +Saravana
> >
> > On Thu, Feb 6, 2020 at 11:27 PM Nicolas Boichat
> > wrote:
> > >
> > > When there is a single power domain per device, the core will
> > > ensure the power
On 2020-02-11 4:27 p.m., Andrey Grodzovsky wrote:
>
> On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
>> On 2/10/20 4:50 PM, Luben Tuikov wrote:
>>> Hi Lucas,
>>>
>>> Thank you for bringing awareness of this issue, publicly.
>>>
>>> As soon as this patch showed up back in November of 2019,
>>> I
On Tue, Feb 11, 2020 at 7:59 AM Jeffrey Hugo wrote:
>
> On Tue, Feb 11, 2020 at 8:44 AM Rob Clark wrote:
> >
> > On Mon, Feb 10, 2020 at 9:58 PM wrote:
> > >
> > > On 2020-02-07 19:40, Jeffrey Hugo wrote:
> > > > On Fri, Feb 7, 2020 at 5:38 AM wrote:
> > > >>
> > > >> On 2020-02-06 20:29,
We only want create a new virglrenderer context after the first
3D ioctl.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
3 files changed, 8 insertions(+)
diff
Hi Chris,
On Fri, Feb 07, 2020 at 03:17:20PM +, Chris Wilson wrote:
> We try hard to select a suitable hole in the drm_mm first time. But if
> that is unsuccessful, we then have to look at neighbouring nodes, and
> this requires traversing the rbtree. Walking the rbtree can be slow
> (much
With virtio_gpu_notify(..), the create context command now is batched
with the first 3D hypercall.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 1 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git
We currently do it when open the DRM fd, let's delay it. First step,
remove the hyercall from initialization.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 16
drivers/gpu/drm/virtio/virtgpu_kms.c |
Let's delay enqueuing the context creation command until the first 3D
ioctl, as we add more context types. This is based on kraxel's
"drm/virtio: rework batching" patch and needs that to work correctly.
Gurchetan Singh (4):
drm/virtio: use consistent names for drm_files
drm/virtio: factor
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
On Tue, Feb 11, 2020 at 4:58 AM Gerd Hoffmann wrote:
>
> Drop the virtio_gpu_{disable,enable}_notify(). Add a new
> virtio_gpu_notify() call instead, which must be called whenever
> the driver wants make sure the host is notified needed.
>
> Drop notification from command submission. Add
On Tue, Feb 11, 2020 at 10:41:20PM +0100, H. Nikolaus Schaller wrote:
> This is needed to give the MIPS Ingenic CI20 board a stable MAC address
> which can be optionally provided by vendor U-Boot.
>
> For get_mac_addr() we use an adapted copy of from ksz884x.c which
> has very similar
On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
On 2/10/20 4:50 PM, Luben Tuikov wrote:
Hi Lucas,
Thank you for bringing awareness of this issue, publicly.
As soon as this patch showed up back in November of 2019,
I objected to it, privately.
I didn't find this objection in my mail actually
From: Daniel Stone
Add a wrapper around the getfb2 ioctl, which returns extended
framebuffer information mirroring addfb2, including multiple planes and
modifiers.
Changes since v7:
- add new symbols to core-symbol.txt (Eric Engestrom)
Changes since v5:
- style change
Changes since v4:
-
a) delta: Adds DRM_IOCTL_MODE_GETFB2
b) Generated using make headers_install
c) Taken from drm-next-misc:
commit 3ff4c24bdb1f494c217c80348f9db4896043ed81
Author: Lyude Paul
Date: Fri Jan 17 17:47:48 2020 -0500
drm/dp_mst: Fix indenting in
On Mon, Feb 10, 2020 at 4:05 AM Maxime Ripard wrote:
>
> Commit f5a98bfe7b37 ("dt-bindings: display: Convert Allwinner display
> pipeline to schemas") introduced a YAML schema for the Allwinner TCON DT
> binding, but the H6 TCON-TV compatible was mistakenly set to fallback on
> the A83t's, while
+Saravana
On Thu, Feb 6, 2020 at 11:27 PM Nicolas Boichat wrote:
>
> When there is a single power domain per device, the core will
> ensure the power domain is switched on (so it is technically
> equivalent to having not power domain specified at all).
>
> However, when there are multiple
From: Daniel Stone
Add a wrapper around the getfb2 ioctl, which returns extended
framebuffer information mirroring addfb2, including multiple planes and
modifiers.
Changes since v5:
- style change
Changes since v4:
- Set fb_id at init instead of memclear() and set (Eric Engestrom)
Changes
a) delta: Adds DRM_IOCTL_MODE_GETFB2
b) Generated using make headers_install
c) Taken from drm-next-misc:
commit 3ff4c24bdb1f494c217c80348f9db4896043ed81
Author: Lyude Paul
Date: Fri Jan 17 17:47:48 2020 -0500
drm/dp_mst: Fix indenting in
The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode,
According to Dell, trying to match their panels via OUI is not reliable
enough and we've been told that we should check against the EDID
instead. As well, Dell seems to have some panels that are actually
intended to switch between using PWM for backlight controls and DPCD for
backlight controls
The whole point of using OUIs is so that we can recognize certain
devices and potentially apply quirks for them. Normally this should work
quite well, but there appears to be quite a number of laptop panels out
there that will fill the OUI but not the device ID. As such, for devices
like this I
Unfortunately, it turned out that the DPCD is also not a reliable way of
probing for DPCD backlight support as some panels will lie and say they
have DPCD backlight controls when they don't actually.
So, revert back to the old behavior and add a bunch of EDID-based DP
quirks for the panels that
On 11/02/2020 18:27, Tony Lindgren wrote:
We are still missing DSI command mode support, and moving it to the common DRM
model.
Nope, DSI command mode support has been working just fine for
a while now :) And Sebastian has a WIP git tree of the common DRM
Indeed... It had been going on for
On 2/10/20 3:35 PM, Ben Skeggs wrote:
On Tue, 11 Feb 2020 at 09:17, James Jones wrote:
On 2/10/20 12:25 AM, Thomas Zimmermann wrote:
Hi
Am 10.02.20 um 09:20 schrieb Ben Skeggs:
On Sat, 8 Feb 2020 at 07:10, James Jones wrote:
I've sent out a v4 version of the format modifier patches
On Tue, Feb 11, 2020 at 06:05:45PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:08PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's simplify life of driver by allowing them to leave
> > encoder->possible_crtcs unset if they have no restrictions
> > in
On Tue, Feb 11, 2020 at 06:02:33PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:06PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Many drivers are populating encoder->possible_clones wrong. Let's
> > persuade them to get it right by adding some loud WARNs.
> >
> >
On Tue, Feb 11, 2020 at 06:22:08PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's simplify life of driver by allowing them to leave
> encoder->possible_crtcs unset if they have no restrictions
> in crtc<->encoder linkage. We'll just populate possible_crtcs
> with the full crtc mask
On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> WARN if the encoder possible_crtcs is effectively empty or contains
> bits for non-existing crtcs.
>
> v2: Move to drm_mode_config_validate() (Daniel)
> Make the docs say we WARN when this is wrong
On Tue, Feb 11, 2020 at 06:22:06PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Many drivers are populating encoder->possible_clones wrong. Let's
> persuade them to get it right by adding some loud WARNs.
>
> We'll cross check the bits between any two encoders. So either
> both
On Tue, Feb 11, 2020 at 06:22:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The docs say possible_clones should always include the encoder itself.
> Since most drivers don't want to deal with the complexities of cloning
> let's allow them to set possible_clones=0 and instead we'll
On Tue, 11 Feb 2020, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 04:47:53PM +0200, Jani Nikula wrote:
>> There is no real reason to require drivers to set and use
>> dev->dev_private. Indeed, the current recommendation, as documented in
>> drm_device.h, is to embed struct drm_device in the
On 11/02/2020 18:05, Tony Lindgren wrote:
* Merlijn Wajer [200211 12:54]:
Hi,
On 11/02/2020 12:08, Tomi Valkeinen wrote:
On 11/02/2020 13:07, Laurent Pinchart wrote:
Hopefully soon (in five years? =) we can say that omapdrm supports all
the boards, and we can deprecate omapfb.
I'd love
On Mon, Feb 10, 2020 at 10:38 AM YueHaibing wrote:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:
> In function dcn10_post_unlock_program_front_end:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2623:29:
> warning: variable stream_status set but
From: Ville Syrjälä
Let's simplify life of driver by allowing them to leave
encoder->possible_crtcs unset if they have no restrictions
in crtc<->encoder linkage. We'll just populate possible_crtcs
with the full crtc mask when registering the encoder so that
userspace doesn't have to deal with
From: Ville Syrjälä
WARN if the encoder possible_crtcs is effectively empty or contains
bits for non-existing crtcs.
v2: Move to drm_mode_config_validate() (Daniel)
Make the docs say we WARN when this is wrong (Daniel)
Extract full_crtc_mask()
Cc: Thomas Zimmermann
Cc: Daniel Vetter
From: Ville Syrjälä
Many drivers are populating encoder->possible_clones wrong. Let's
persuade them to get it right by adding some loud WARNs.
We'll cross check the bits between any two encoders. So either
both encoders can clone with the other, or neither can.
We'll also complain about
From: Ville Syrjälä
Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Acked-by: Thomas Zimmermann
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
1 file changed, 2
From: Ville Syrjälä
Another respin of the possible_clones/crtcs fixing.
Changes based on v2 review:
- introduce drm_mode_config_validate()
- WARN for possible_clones!=0 when the encoder
itself isn't in the mask
- update the documentation to match the code
Other changes:
- sligth refactoring
From: Ville Syrjälä
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use
From: Ville Syrjälä
It's not at all clear what cloning options this driver supports.
So let's just clear possible_clones instead of setting it to some
bogus value.
v2: Adjust the FIXME (Daniel)
Cc: Philipp Zabel
Acked-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into
Ping?
Alex
On Fri, Feb 7, 2020 at 4:17 PM Alex Deucher wrote:
>
> Split into init and register functions to avoid a segfault
> in some configs when the load/unload callbacks are removed.
>
> v2:
> - add back accidently dropped has_aux setting
> - set dev in late_register
>
> v3:
> - fix dp cec
Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
real CRC value of the last edid data block, and write it back.
Current edid CRC calculates routine adds the last CRC byte,
and check if non-zero.
This behavior is not accurate; actually, we need to return
the actual CRC value when
On 2/10/20 4:50 PM, Luben Tuikov wrote:
Hi Lucas,
Thank you for bringing awareness of this issue, publicly.
As soon as this patch showed up back in November of 2019,
I objected to it, privately.
I didn't find this objection in my mail actually
I suggested to instead use a _list_ to
The patch
drm/mediatek: exit earlier if failed to register audio driver
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.7
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the
The patch
ASoC: mediatek: mt8173-rt5650: support HDMI jack reporting
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.7
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next
The patch
drm/mediatek: support HDMI jack status reporting
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.7
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
Hi Jyri
On Tue, Feb 11, 2020 at 02:17:16PM +0200, Jyri Sarha wrote:
> Add support for Rocktech RK101II01D-CT panel to panel-simple and add
> yaml binding for it.
>
> Changes since v2:
> - No separate binding document, just add new compatible to panel-simple.yaml
>
> Changes since first fersion:
On Tue, Feb 11, 2020 at 04:43:26PM +0100, Christian König wrote:
> When non-imported BOs are resurrected for delayed delete we replace
> the dma_resv object to allow for easy reclaiming of the resources.
>
> v2: move that to ttm_bo_individualize_resv
> v3: add a comment to explain what's going on
On Mon, Feb 10, 2020 at 9:58 PM wrote:
>
> On 2020-02-07 19:40, Jeffrey Hugo wrote:
> > On Fri, Feb 7, 2020 at 5:38 AM wrote:
> >>
> >> On 2020-02-06 20:29, Jeffrey Hugo wrote:
> >> > On Thu, Feb 6, 2020 at 2:13 AM Harigovindan P
> >> > wrote:
> >> >>
> >> >> For a given byte clock, if VCO
On Tue, Feb 11, 2020 at 11:46:26AM +, Emil Velikov wrote:
> On Tue, 11 Feb 2020 at 08:06, Pekka Paalanen wrote:
> >
> > On Mon, 10 Feb 2020 19:01:06 +
> > Emil Velikov wrote:
> >
> > > Thanks for having a look Daniel.
> > >
> > > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
> > > >
When non-imported BOs are resurrected for delayed delete we replace
the dma_resv object to allow for easy reclaiming of the resources.
v2: move that to ttm_bo_individualize_resv
v3: add a comment to explain what's going on
Signed-off-by: Christian König
Reviewed-by: xinhui pan
---
On Tue, Feb 11, 2020 at 04:40:21PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 03:00:30PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 11, 2020 at 11:11:34AM +0200, Tomi Valkeinen wrote:
> > > Hi Ville,
> > >
> > > On 10/02/2020 18:03, Ville Syrjälä wrote:
> > >
> > > > The usual
On Tue, Feb 11, 2020 at 03:00:30PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 11, 2020 at 11:11:34AM +0200, Tomi Valkeinen wrote:
> > Hi Ville,
> >
> > On 10/02/2020 18:03, Ville Syrjälä wrote:
> >
> > > The usual approach we follow in i915 for things that affect more
> > > than one plane is is
On Fri, Jan 31, 2020 at 12:00 AM Akhil P Oommen wrote:
>
> On 1/24/2020 11:56 PM, Jordan Crouse wrote:
> > On Fri, Jan 24, 2020 at 05:50:11PM +0530, Akhil P Oommen wrote:
> >> Highest bank bit configuration is different for a618 gpu. Update
> >> it with the correct configuration which is the
On Tue, Feb 11, 2020 at 4:23 PM Christian König
wrote:
>
> Am 11.02.20 um 16:02 schrieb Pan, Xinhui:
> >
> >> 2020年2月11日 22:14，Daniel Vetter 写道：
> >>
> >> On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
> >>> When non-imported BOs are resurrected for delayed delete we replace
>
Am 11.02.20 um 16:02 schrieb Pan, Xinhui:
2020年2月11日 22:14，Daniel Vetter 写道：
On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
When non-imported BOs are resurrected for delayed delete we replace
the dma_resv object to allow for easy reclaiming of the resources.
v2: move that
Am 11.02.20 um 15:14 schrieb Daniel Vetter:
On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
When non-imported BOs are resurrected for delayed delete we replace
the dma_resv object to allow for easy reclaiming of the resources.
v2: move that to ttm_bo_individualize_resv
On Tue, Feb 11, 2020 at 04:47:53PM +0200, Jani Nikula wrote:
> There is no real reason to require drivers to set and use
> dev->dev_private. Indeed, the current recommendation, as documented in
> drm_device.h, is to embed struct drm_device in the per-device struct
> instead of using dev_private.
>
> 2020年2月11日 22:14，Daniel Vetter 写道：
>
> On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
>> When non-imported BOs are resurrected for delayed delete we replace
>> the dma_resv object to allow for easy reclaiming of the resources.
>>
>> v2: move that to
Hello Ramalingam C,
The patch 6498bf5800a3: "drm: revocation check at drm subsystem" from
May 7, 2019, leads to the following static checker warning:
drivers/gpu/drm/drm_hdcp.c:195 drm_hdcp_parse_hdcp2_srm()
warn: mask and shift to zero
drivers/gpu/drm/drm_hdcp.c
190
There is no real reason to require drivers to set and use
dev->dev_private. Indeed, the current recommendation, as documented in
drm_device.h, is to embed struct drm_device in the per-device struct
instead of using dev_private.
Remove the requirement for dev_private to have been set to indicate
On Tue, Feb 11, 2020 at 02:58:04PM +0100, Gerd Hoffmann wrote:
> Split virtio_gpu_deinit(), move the drm shutdown and release to
> virtio_gpu_release(). Drop vqs_ready variable, instead use
> drm_dev_{enter,exit,unplug} to avoid touching hardware after
> device removal. Tidy up here and there.
>
On Tue, Feb 11, 2020 at 02:55:22PM +0100, Gerd Hoffmann wrote:
> Move final cleanups from cirrus_pci_remove() to the new callback.
> Add drm_atomic_helper_shutdown() call to cirrus_pci_remove().
>
> Use drm_dev_{enter,exit,unplug} to avoid touching hardware after
> device removal.
>
> v4: add
On Tue, Feb 11, 2020 at 02:52:18PM +0100, Gerd Hoffmann wrote:
> Call bochs_unload via drm_driver.release to make sure we release stuff
> when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid
> touching hardware after device removal. Tidy up here and there.
>
> v4: add changelog.
>
On Mon, Feb 10, 2020 at 04:09:06PM +0100, Christian König wrote:
> When non-imported BOs are resurrected for delayed delete we replace
> the dma_resv object to allow for easy reclaiming of the resources.
>
> v2: move that to ttm_bo_individualize_resv
>
> Signed-off-by: Christian König
> ---
>
Reviewed-by: xinhui pan
> 2020年2月11日 21:43，Christian König 写道：
>
> This patch reworks the whole delayed deletion of BOs which aren't idle.
>
> Instead of having two counters for the BO structure we resurrect the BO
> when we find that a deleted BO is not idle yet.
>
> This has many
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> This patchset continues the conversion of the printk based drm logging
> macros in drm/i915 to use the struct drm_device based logging macros.
> This series was done both using coccinelle and manually.
Thank you for the patches! I pushed all the
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> Conversion of the printk based drm logging macros to the struct
> drm_device based logging macros in display/intel_dp_aux_backlight.c.
> This also involves extracting the drm_i915_private device pointer from
> various intel types to use in the macros.
>
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> Conversion of instances of the printk based drm logging macros to the
> struct drm_device based logging macros in i915/display/intel_dp_mst.c.
> This also involves extracting the drm_i915_private device pointer from
> various intel types to use in the
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> @@ -5990,11 +6040,13 @@ int intel_dp_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
> u8 *bksv)
> {
> + struct
Split virtio_gpu_deinit(), move the drm shutdown and release to
virtio_gpu_release(). Drop vqs_ready variable, instead use
drm_dev_{enter,exit,unplug} to avoid touching hardware after
device removal. Tidy up here and there.
v4: add changelog.
v3: use drm_dev_*().
Signed-off-by: Gerd Hoffmann
Move final cleanups from cirrus_pci_remove() to the new callback.
Add drm_atomic_helper_shutdown() call to cirrus_pci_remove().
Use drm_dev_{enter,exit,unplug} to avoid touching hardware after
device removal.
v4: add changelog.
v3: use drm_dev*.
v2: stop touching hardware after pci_remove().
Call bochs_unload via drm_driver.release to make sure we release stuff
when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid
touching hardware after device removal. Tidy up here and there.
v4: add changelog.
v3: use drm_dev_*().
v2: move hardware deinit to pci_remove().
Gerd Hoffmann (2):
drm/virtio: fix virtio_gpu_execbuffer_ioctl locking
drm/virtio: fix virtio_gpu_cursor_plane_update().
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++--
drivers/gpu/drm/virtio/virtgpu_plane.c | 1 +
2 files changed, 11 insertions(+), 10 deletions(-)
--
Lockdep says we can't call vmemdup() while having objects reserved
because it needs the mmap semaphore. So reorder the calls reserve
the objects later.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10
Add missing virtio_gpu_array_lock_resv() call.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index ac42c84d2d7f..d1c3f5fbfee4 100644
---
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> @@ -1364,11 +1372,15 @@ int intel_hdmi_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> static int intel_hdmi_hdcp_read_bksv(struct intel_digital_port
> *intel_dig_port,
>u8 *bksv)
> {
> +
This patch reworks the whole delayed deletion of BOs which aren't idle.
Instead of having two counters for the BO structure we resurrect the BO
when we find that a deleted BO is not idle yet.
This has many advantages, especially that we don't need to
increment/decrement the BOs reference counter
[SNIP]
+ /*
+* Make NO_EVICT bos immediately available to
+* shrinkers, now that they are queued for
+* destruction.
+*/
+ if (bo->mem.placement & TTM_PL_FLAG_NO_EVICT) {
+
On Tue, Feb 11, 2020 at 11:11:34AM +0200, Tomi Valkeinen wrote:
> Hi Ville,
>
> On 10/02/2020 18:03, Ville Syrjälä wrote:
>
> > The usual approach we follow in i915 for things that affect more
> > than one plane is is to collect that state into the crtc state.
> > That way we get to remember it
Hi,
> @@ -541,6 +539,7 @@ void virtio_gpu_cmd_unref_resource(struct
> virtio_gpu_device *vgdev,
> cmd_p->resource_id = cpu_to_le32(resource_id);
>
> virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
> + virtio_gpu_commit_ctrl(vgdev);
> }
Well, I was more thinking about adding that
Drop the virtio_gpu_{disable,enable}_notify(). Add a new
virtio_gpu_notify() call instead, which must be called whenever
the driver wants make sure the host is notified needed.
Drop notification from command submission. Add virtio_gpu_notify()
calls everywhere instead. This results in more
Add support for Rocktech RK101II01D-CT panel to panel-simple and add
yaml binding for it.
Changes since v2:
- No separate binding document, just add new compatible to panel-simple.yaml
Changes since first fersion:
- Move to yaml binding
Jyri Sarha (2):
dt-bindings: panel-simple: Add
Add support for Rocktech RK101II01D-CT, 10.1" 1280x800 TFT with LVDS
interface, LED backlight and integrated Goodix GT928 capacitive touch
panel.
Signed-off-by: Jyri Sarha
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32
Add compatible to panel-simple for Rocktech Displays Limited
RK101II01D-CT 10.1" TFT 1280x800 Pixels with LVDS interface, LED
Backlight, and capacitive touch panel ("goodix,gt928" compatible).
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
On Thursday, 2020-02-06 17:46:36 +, Li, Juston wrote:
> On Wed, 2020-02-05 at 23:27 +, Eric Engestrom wrote:
> > On Wednesday, 2020-02-05 23:10:21 +, Li, Juston wrote:
> > > On Wed, 2020-02-05 at 22:25 +, Eric Engestrom wrote:
> > > > On Friday, 2020-01-31 13:41:09 -0800, Juston Li
On Mon, 10 Feb 2020 at 08:10, Thomas Zimmermann wrote:
>
> Hi
>
> Am 07.02.20 um 17:41 schrieb Daniel Vetter:
> > On Fri, Feb 07, 2020 at 03:16:02PM +0100, Thomas Zimmermann wrote:
> >> Atomic modesetting doesn't use struct drm_connector_funcs.dpms and
> >> the set function,
On Mon, 10 Feb 2020 at 21:54, Daniel Vetter wrote:
>
> On Mon, Feb 10, 2020 at 8:01 PM Emil Velikov wrote:
> >
> > Thanks for having a look Daniel.
> >
> > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
> > >
> > > On Wed, Feb 05, 2020 at 05:48:39PM +, Emil Velikov wrote:
> > > > From:
On Tue, 11 Feb 2020 at 08:06, Pekka Paalanen wrote:
>
> On Mon, 10 Feb 2020 19:01:06 +
> Emil Velikov wrote:
>
> > Thanks for having a look Daniel.
> >
> > On Fri, 7 Feb 2020 at 13:29, Daniel Vetter wrote:
> > >
> > > On Wed, Feb 05, 2020 at 05:48:39PM +, Emil Velikov wrote:
> > > >
On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote:
> TGL timeouts when disabling MST transcoder and fifo underruns over
> MST
> transcoders are fixed when setting TRANS_DDI_MODE_SELECT to 0(HDMI
> mode) during the disable sequence.
>
> Although BSpec disable sequence don't require
On 11/02/2020 13:07, Laurent Pinchart wrote:
Hopefully soon (in five years? =) we can say that omapdrm supports all
the boards, and we can deprecate omapfb.
I'd love to send a patch to remove omapfb, but I'll let you do the
honours :-)
Not before we add DSI support to omapdrm...
Tomi
--
On Mon, Feb 10, 2020 at 10:47:36AM +0100, Thomas Zimmermann wrote:
> Hi,
>
> I smoke-tested the patchset by running X11, Weston and fbdev emulation
> on ast and udl. No apparent problems found, so
>
> Tested-by: Thomas Zimmermann
Merged patches 2-5 (first one needs to wait for amdgpu/radeon
On Tue, Feb 11, 2020 at 11:06:53AM +, Pan, Xinhui wrote:
> [AMD Official Use Only - Internal Distribution Only]
Uh might want to fix your email setup.
-Daniel
>
> For patch 1/2/3/5/6
> Reviewed-by: xinhui pan
>
> From: Christian König
> Sent: Monday,
On Tue, Feb 11, 2020 at 10:55:29AM +0100, Gerd Hoffmann wrote:
> Call bochs_unload via drm_driver.release to make sure we release stuff
> when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid
> touching hardware after device removal. Tidy up here and there.
>
> Signed-off-by: Gerd
On Tue, Feb 11, 2020 at 01:08:12PM +0200, Tomi Valkeinen wrote:
> On 11/02/2020 13:07, Laurent Pinchart wrote:
>
> >> Hopefully soon (in five years? =) we can say that omapdrm supports all
> >> the boards, and we can deprecate omapfb.
> >
> > I'd love to send a patch to remove omapfb, but I'll
Hi Tomi,
On Tue, Feb 11, 2020 at 12:01:31PM +0200, Tomi Valkeinen wrote:
> On 13/01/2020 14:01, Tomi Valkeinen wrote:
> > On 12/12/2019 22:35, Laurent Pinchart wrote:
> >> On Thu, Dec 12, 2019 at 11:37:51AM +0200, Tomi Valkeinen wrote:
> >>> On 11/12/2019 18:53, Tony Lindgren wrote:
> *
1 - 100 of 120 matches
Mail list logo
