Hi,
> > + if (!shmem->map_cached)
> > + prot = pgprot_writecombine(prot);
> > shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
> > - VM_MAP, pgprot_writecombine(PAGE_KERNEL));
> > +
On Wed, Feb 26, 2020 at 04:25:53PM -0800, Gurchetan Singh wrote:
> The main motivation behind this is to have eventually have something like
> this:
>
> struct virtio_gpu_shmem {
> struct drm_gem_shmem_object base;
> uint32_t hw_res_handle;
> struct sg_table *pages;
> (...)
> };
On 2/27/20 1:02 AM, Chia-I Wu wrote:
On Wed, Feb 26, 2020 at 10:25 AM Thomas Hellström (VMware)
wrote:
Hi, Gerd,
#define to_drm_gem_shmem_obj(obj) \
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index a421a2eed48a..aad9324dcf4f 100644
---
Properly propagate error value from devm_regulator_bulk_get() and don't
confuse user with meaningless warning about failure in getting regulators
in case of deferred probe.
Signed-off-by: Marek Szyprowski
---
v2: rephrased commit message
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 +++--
1
Hi Chris,
> -Original Message-
> From: Chris Wilson
> Sent: 25 February 2020 19:32
> To: David Airlie ; Joonas Lahtinen
> ; Laxminarayan Bharadiya, Pankaj
> ; Vivi, Rodrigo
> ; dan...@ffwll.ch; dri-devel@lists.freedesktop.org;
> intel-...@lists.freedesktop.org;
Hi, Enric:
On Wed, 2020-02-26 at 12:27 +0100, Enric Balletbo i Serra wrote:
> Equivalent information can be nowadays obtained using function tracer.
>
Reviewed-by: CK Hu
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 -
>
Hi Dave & Daniel -
Switching gen7 back to aliasing-ppgtt seems to be the main highlight
here.
BR,
Jani.
drm-intel-fixes-2020-02-27:
drm/i915 fixes for v5.6-rc4:
- downgrade gen7 back to aliasing-ppgtt to avoid GPU hangs
- shrinker fix
- pmu leak and double free fixes
- gvt user after free and
Hi Dave, Daniel,
New stuff for 5.7.
The following changes since commit 58fe03d6dec908a1bec07eea7e94907af5c07eec:
drm/amd/dm/mst: Ignore payload update failures (2020-02-04 23:30:39 -0500)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux
On Wed, 26 Feb 2020 10:36:26 +0100 Daniel Vetter wrote:
> On Wed, Feb 26, 2020 at 5:29 AM Sumit Semwal wrote:
> >
> > Hello Andrew,
> >
> >
> > On Wed, 26 Feb 2020 at 07:25, Andrew Morton
> > wrote:
> > >
> > >
> > > The patch titled
> > > Subject: dma-buf: free dmabuf->name in
Hi Dave, Daniel,
Fixes for 5.6.
The following changes since commit 97d9a4e9619a822c5baf6a63e6f5b80fee4d4213:
Merge tag 'drm-intel-fixes-2020-02-20' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2020-02-21 12:46:54
+1000)
are available in the Git repository at:
Hi, Enric:
I would like you to modify mmsys binding document. In current document,
mmsys is a clock controller, but I think it's a system controller
including clock control, routing control, and miscellaneous control in
mmsys partition.
Regards,
CK
On Wed, 2020-02-26 at 11:54 +0100, Enric
Hi, Enric:
On Wed, 2020-02-26 at 11:54 +0100, Enric Balletbo i Serra wrote:
> In the actual implementation the same compatible string
> "mediatek,-mmsys" is used to bind the clock drivers
> (drivers/soc/mediatek) as well as to the gpu driver
> (drivers/gpu/drm/mediatek/mtk_drm_drv.c). This ends
Hi, Enric:
On Wed, 2020-02-26 at 11:54 +0100, Enric Balletbo i Serra wrote:
> From: Matthias Brugger
>
> There is no strong reason for this to use CLK_OF_DECLARE instead of
> being a platform driver. Plus, this driver provides clocks but also
> a shared register space for the mediatek-drm and
Hi, Enric:
On Wed, 2020-02-26 at 11:54 +0100, Enric Balletbo i Serra wrote:
> From: Matthias Brugger
>
> The mmsys memory space is shared between the drm and the
> clk driver. Use regmap to access it.
Once there is a mmsys driver and clock control is moved into mmsys
driver, I think we should
Hi,
On Tue, Feb 25, 2020 at 12:21:13AM +0100, Sebastian Reichel wrote:
> This fixes the omapdrm driver to call component_bind_all()
> with drm_device as data argument as recommended in the
> DRM component helper usage text.
>
> After this patch DRM functionality can be implemented directly
> in
Hi,
On Wed, Feb 26, 2020 at 02:28:23PM +0200, Tomi Valkeinen wrote:
> On 25/02/2020 01:20, Sebastian Reichel wrote:
> > This updates the existing omapdrm DSI code, so that it uses
> > common drm_mipi_dsi API and drm_panel.
> >
> > The patchset has been tested with Droid 4 using Linux console,
tree: git://anongit.freedesktop.org/drm-intel for-linux-next
head: 7a0a6ee731508b770f3ee198af7b0c87a20ebb80
commit: d54c1a513c487ac6d6b3c4595e93e3625b461cc3 [3/6] drm/i915: Fix broken
transcoder err state
config: x86_64-randconfig-b003-20200226 (attached as .config)
compiler: gcc-7 (Debian
These hypercalls are reusable by both shmem and (planned) vram
based virtio_gpu objects.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
This renames struct virtio_gpu_object to struct virtio_gpu_shmem.
This will go in line with the planned struct virtio_gpu_vram.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 22 ++---
drivers/gpu/drm/virtio/virtgpu_gem.c| 12 +--
The plan is to use this array with VRAM objects too.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 36
drivers/gpu/drm/virtio/virtgpu_gem.c| 116
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 32 +++
The plan is use have both shmem and virtual "vram" running
side-by-side in virtio-gpu. It looks like we'll eventually use
struct drm_gem_object as a base class, and we'll need to convert
to shmem and vram objects on the fly. As a first step, add a
virtio_gpu_is_shmem helper. Thanks to kraxel for
Currently, struct virtio_gpu_object refers to the SHMEM based object,
which is fair. We want to expand that a bit, so let's expand the
creation params too.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 10 +-
drivers/gpu/drm/virtio/virtgpu_gem.c| 4
Whether the resource is a shmem based resource or a (planned)
vram based resource, it will have a resource handle associated
with it. Since the hypercall interface works on resource handles,
add a function that returns the handle given a GEM object.
Signed-off-by: Gurchetan Singh
---
This hypercall is reusable for both shmem and (planned) vram
based virtgpu objects.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 2 +-
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_vq.c | 17 +++--
3 files
This is a very, very minor cleanup.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 3d2a6d489bfc..07de3260118a
The main motivation behind this is to have eventually have something like this:
struct virtio_gpu_shmem {
?? ?? struct drm_gem_shmem_object base;
?? ?? uint32_t hw_res_handle;
?? ?? struct sg_table *pages;
?? ?? (...)
};
struct virtio_gpu_vram {
?? ?? struct drm_gem_object base; ??// or
On Wed, Feb 26, 2020 at 10:25 AM Thomas Hellström (VMware)
wrote:
>
> Hi, Gerd,
>
> While looking at this patchset I came across some stuff that seems
> strange but that was merged in a previous patchset.
>
> (please refer to
>
Hi Hans
Just commenting in the "[3.309061] [drm:intel_dump_pipe_config
[i915]] MST master transcoder: " message, it is the expected
behaviour for anything older than Tigerlake, from TGL+ this will be set
in MST mode.
On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
> Hi,
>
> On
Hi Laurent,
On Tue, Feb 25, 2020 at 06:30:01PM +0200, Laurent Pinchart wrote:
> On Tue, Feb 25, 2020 at 12:20:43AM +0100, Sebastian Reichel wrote:
> > Simplify the DSI encoder by using mipi_dsi_msg for
> > dsi_vc_send_long and dsi_vc_send_short. Further improvements
> > require cleaning up the
Hi Sebastian,
On Wed, Feb 26, 2020 at 11:46:43PM +0100, Sebastian Reichel wrote:
> On Tue, Feb 25, 2020 at 05:31:05PM +0200, Laurent Pinchart wrote:
> > > + if (mipi_dsi_packet_format_is_short(msg->type)) {
> > > + u16 data = packet.header[1] | (packet.header[2] << 8);
> > > + r =
Hi Laurent,
On Tue, Feb 25, 2020 at 05:31:05PM +0200, Laurent Pinchart wrote:
> > + if (mipi_dsi_packet_format_is_short(msg->type)) {
> > + u16 data = packet.header[1] | (packet.header[2] << 8);
> > + r = dsi_vc_send_short(dsi, msg->channel, msg->type, data, 0);
>
> You use
Hi Laurent,
On Wed, Feb 26, 2020 at 11:36:30PM +0200, Laurent Pinchart wrote:
> > > I think you can drop the definition of the omap_dsi_pin_config structure
> > > earlier in this file too, as well as the OMAP_DSS_MAX_DSI_PINS macro.
> > > With this fixed,
> >
> > No, the struct is still used by
Hi,
On Tue, Feb 25, 2020 at 04:52:21PM +0200, Laurent Pinchart wrote:
> Hi Sebastian,
>
> Thank you for the patch.
>
> On Tue, Feb 25, 2020 at 12:20:38AM +0100, Sebastian Reichel wrote:
> > This converts the panel-dsi-cm driver to use the transfer
> > API instead of specific functions, so that
Removes codestyle issues on detect_dp function as suggested by
checkpatch.pl.
CHECK: Lines should not end with a '('
WARNING: Missing a blank line after declarations
WARNING: line over 80 characters
CHECK: Alignment should match open parenthesis
Signed-off-by: Melissa Wen
---
Coding style clean up on enable_link_dp function as suggested by
checkpatch.pl:
CHECK: Lines should not end with a '('
WARNING: line over 80 characters
WARNING: suspect code indent for conditional statements (8, 24)
CHECK: braces {} should be used on all arms of this statement
ERROR: else should
This patchset solves some coding style issues on dc_link for readability
and cleaning up warnings. Change suggested by checkpatch.pl.
Melissa Wen (2):
drm/amd/display: dc_link: code clean up on enable_link_dp function
drm/amd/display: dc_link: code clean up on detect_dp function
Hi Sebastian,
On Wed, Feb 26, 2020 at 10:28:19PM +0100, Sebastian Reichel wrote:
> On Tue, Feb 25, 2020 at 01:42:49AM +0200, Laurent Pinchart wrote:
> > On Tue, Feb 25, 2020 at 12:20:34AM +0100, Sebastian Reichel wrote:
> > > The panel-dsi-cm's ddata->pin_config is always NULL, so this
> > >
Hi Laurent,
On Tue, Feb 25, 2020 at 01:42:49AM +0200, Laurent Pinchart wrote:
> Hi Sebastian,
>
> Thank you for the patch.
>
> On Tue, Feb 25, 2020 at 12:20:34AM +0100, Sebastian Reichel wrote:
> > The panel-dsi-cm's ddata->pin_config is always NULL, so this
> > callback is never called.
Hi,
On Tue, Feb 25, 2020 at 03:58:23PM +0200, Laurent Pinchart wrote:
> Hi Sebastian,
>
> Thank you for the patch.
>
> On Tue, Feb 25, 2020 at 12:20:35AM +0100, Sebastian Reichel wrote:
> > This replaces OMAP specific enum for pixel format with
> > common implementation.
> >
> > Signed-off-by:
From: Colin Ian King
In the unlikely event that num_entry is zero, the while loop
pre-decrements num_entry to cause negative array indexing into the
array sources. Fix this by iterating only if num_entry >= 0.
Addresses-Coverity: ("Out-of-bounds read")
Fixes: f705806c9f35 ("backlight: Add
From: Colin Ian King
In the unlikely event that num_entry is zero, the while loop
pre-decrements num_entry to cause negative array indexing into the
array sources. Fix this by iterating only if num_entry >= 0.
Addresses-Coverity: ("Out-of-bounds read")
Fixes: f705806c9f35 ("backlight: Add
On Wed, Feb 26, 2020 at 12:10 AM Vasily Khoruzhick wrote:
>
> From: Samuel Holland
This patch can be dropped since equivalent was merged:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=6726ca1a2d531f5a6efc1f785b15606ce837c4dc
> We don't need to pass '-supply' suffix to
Before this commit, drmcg limits are updated but enforcement is delayed
until the next time the driver check against the new limit. While this
is sufficient for certain resources, a more proactive enforcement may be
needed for other resources.
Introducing an optional drmcg_limit_updated callback
The drm resource being limited here is the GEM buffer objects. User
applications allocate and free these buffers. In addition, a process
can allocate a buffer and share it with another process. The consumer
of a shared buffer can also outlive the allocator of the buffer.
For the purpose of
gpu.buffer.peak.default
A read-only flat-keyed file which exists on the root cgroup.
Each entry is keyed by the drm device's major:minor.
Default limits on the largest GEM buffer allocation in bytes.
gpu.buffer.peak.max
A read-write flat-keyed file which exists on
gpu.compute.weight
A read-write flat-keyed file which exists on all cgroups. The
default weight is 100. Each entry is keyed by the DRM device's
major:minor (the primary minor). The weights are in the range [1,
1] and specifies the relative amount of physical
The number of compute unit (CU) for a device is used for the gpu cgroup
compute capacity. The gpu cgroup compute allocation limit only applies
to compute workload for the moment (enforced via kfd queue creation.)
Any cu_mask update is validated against the availability of the compute
unit as
With the increased importance of machine learning, data science and
other cloud-based applications, GPUs are already in production use in
data centers today. Existing GPU resource management is very coarse
grain, however, as sysadmins are only able to distribute workload on a
per-GPU basis. An
gpu.buffer.count.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Total number of GEM buffer allocated.
Change-Id: Iad29bdf44390dbcee07b1e72ea0ff811aa3b9dcd
Signed-off-by: Kenny Ho
---
gpu.buffer.peak.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Largest (high water mark) GEM buffer allocated in bytes.
Change-Id: I40fe4c13c1cea8613b3e04b802f3e1f19eaab4fc
Signed-off-by: Kenny Ho
---
drmcg initialization involves allocating a per cgroup, per device data
structure and setting the defaults. There are two entry points for
drmcg init:
1) When struct drmcg is created via css_alloc, initialization is done
for each device
2) When DRM devices are created after drmcgs are created
The drm resource being measured here is the GEM buffer objects. User
applications allocate and free these buffers. In addition, a process
can allocate a buffer and share it with another process. The consumer
of a shared buffer can also outlive the allocator of the buffer.
For the purpose of
Since the drm subsystem can be compiled as a module and drm devices can
be added and removed during run time, add several functions to bind the
drm subsystem as well as drm devices with drmcg.
Two pairs of functions:
drmcg_bind/drmcg_unbind - used to bind/unbind the drm subsystem to the
cgroup
This is a submission for the introduction of a new cgroup controller for the
drm subsystem follow a series of RFCs [v1, v2, v3, v4]
Changes from PR v1
* changed cgroup controller name from drm to gpu
* removed lgpu
* added compute.weight resources, clarified resources being distributed as
Hi, Gerd,
While looking at this patchset I came across some stuff that seems
strange but that was merged in a previous patchset.
(please refer to
https://lists.freedesktop.org/archives/dri-devel/2018-September/190001.html.
Forgive me if I've missed any discussion leading up to this).
On
Explicit synchronization is the future. At least, that seems to be what
most userspace APIs are agreeing on at this point. However, most of our
Linux APIs (both userspace and kernel UAPI) are currently built around
implicit synchronization with dma-buf. While work is ongoing to change
many of
Hi,
On 2/26/20 5:05 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede wrote:
Hi,
On 2/26/20 4:29 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede wrote:
Hi Lyude and everyone else,
Lyude I'm mailing you about this because you have done a lot
On Wed, Feb 26, 2020 at 7:48 AM Gerd Hoffmann wrote:
>
> v5: rebase, add tags, add cc stable for 1+2, no code changes.
> v4: back to v2-ish design, but simplified a bit.
> v3: switch to drm_gem_object_funcs callback.
> v2: make shmem helper caching configurable.
>
> Gerd Hoffmann (3):
>
> -Original Message-
> From: Gerd Hoffmann
> Sent: 26 February 2020 16:48
> To: dri-devel@lists.freedesktop.org
> Cc: tzimmerm...@suse.de; gurchetansi...@chromium.org; olva...@gmail.com;
> Guillaume Gardet ; Gerd Hoffmann
> ; sta...@vger.kernel.org; David Airlie ;
> Daniel Vetter ;
> -Original Message-
> From: Gerd Hoffmann
> Sent: 26 February 2020 16:48
> To: dri-devel@lists.freedesktop.org
> Cc: tzimmerm...@suse.de; gurchetansi...@chromium.org; olva...@gmail.com;
> Guillaume Gardet ; Gerd Hoffmann
> ; sta...@vger.kernel.org; Maarten Lankhorst
> ; Maxime Ripard
On Wed, Feb 26, 2020 at 4:29 PM Jason Ekstrand wrote:
>
> On Wed, Feb 26, 2020 at 4:05 AM Daniel Vetter wrote:
> >
> > On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote:
> > > Hi Jason,
> > >
> > > Am 26.02.20 um 00:58 schrieb Jason Ekstrand:
> > > > Explicit synchronization is the
On Tue, Feb 25, 2020 at 6:16 PM Daniel Vetter wrote:
>
> On Mon, Feb 24, 2020 at 07:46:59PM +0100, Christian König wrote:
> > Am 23.02.20 um 17:54 schrieb Thomas Hellström (VMware):
> > > On 2/23/20 4:45 PM, Christian König wrote:
> > > > Am 21.02.20 um 18:12 schrieb Daniel Vetter:
> > > > >
On Thu, Feb 20, 2020 at 11:26:53AM -0700, Jordan Crouse wrote:
> Convert display/msm/gmu.txt to display/msm/gmu.yaml and remove the old
> text bindings.
>
> Signed-off-by: Jordan Crouse
> ---
>
> .../devicetree/bindings/display/msm/gmu.txt| 116 --
>
On Wed, Feb 26, 2020 at 12:56:58PM +0900, David Stevens wrote:
> On Tue, Feb 25, 2020 at 3:10 PM Gerd Hoffmann wrote:
> >
> > How about dma_buf_{get,set}_uuid, simliar to dma_buf_set_name?
>
> While I'm not opposed to such an API, I'm also hesitant to make
> changes to the dma-buf API for a
On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede wrote:
>
> Hi,
>
> On 2/26/20 4:29 PM, Alex Deucher wrote:
> > On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede wrote:
> >>
> >> Hi Lyude and everyone else,
> >>
> >> Lyude I'm mailing you about this because you have done a lot of
> >> work on DP MST,
On Wed, Feb 26, 2020 at 04:54:35PM +0100, Lucas Stach wrote:
> On Mi, 2020-02-26 at 15:31 +, Schrempf Frieder wrote:
> > On 25.02.20 09:13, Frieder Schrempf wrote:
> > > Hi Lucas,
> > >
> > > On 24.02.20 12:08, Lucas Stach wrote:
> > > > On Mo, 2020-02-24 at 10:53 +, Schrempf Frieder
On Mi, 2020-02-26 at 15:31 +, Schrempf Frieder wrote:
> On 25.02.20 09:13, Frieder Schrempf wrote:
> > Hi Lucas,
> >
> > On 24.02.20 12:08, Lucas Stach wrote:
> > > On Mo, 2020-02-24 at 10:53 +, Schrempf Frieder wrote:
> > > > Hi Lucas,
> > > >
> > > > On 24.02.20 11:37, Lucas Stach
Hi,
> > ... into 5.6-rc3 fixes the corruption for me.
>
> I tried those 2 patches on top of kernel 5.6-rc3 and they indeed fix the
> problem.
>
> I applied them on top of 5.5.6 and they also fix the problem!
> Could we get those 2 patches applied to stable 5.5, please?
Series just
virtio-gpu uses cached mappings, set
drm_gem_shmem_object.map_cached accordingly.
Cc: sta...@vger.kernel.org
Fixes: c66df701e783 ("drm/virtio: switch from ttm to gem shmem helpers")
Reported-by: Gurchetan Singh
Reported-by: Guillaume Gardet
Signed-off-by: Gerd Hoffmann
---
With shmem helpers allowing to update pgprot caching flags via
drm_gem_shmem_object.map_cached we can just use that and ditch
our own implementations of mmap() and vmap().
We also don't need a special case for imported objects, any map
requests are handled by the exporter not udl.
Signed-off-by:
Add map_cached bool to drm_gem_shmem_object, to request cached mappings
on a per-object base. Check the flag before adding writecombine to
pgprot bits.
Cc: sta...@vger.kernel.org
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_shmem_helper.h | 5 +
v5: rebase, add tags, add cc stable for 1+2, no code changes.
v4: back to v2-ish design, but simplified a bit.
v3: switch to drm_gem_object_funcs callback.
v2: make shmem helper caching configurable.
Gerd Hoffmann (3):
drm/shmem: add support for per object caching flags.
drm/virtio: fix mmap
Hi,
On 2/26/20 4:29 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede wrote:
Hi Lyude and everyone else,
Lyude I'm mailing you about this because you have done a lot of
work on DP MST, but if this rings a bell to anyone else feel
free to weigh in on this.
Might be a
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Jerry (Fangzhi) Zuo
-Original Message-
From: Alex Deucher
Sent: February 26, 2020 10:40 AM
To: Zuo, Jerry
Cc: Liu, Zhan ; Wentland, Harry ;
amd-gfx list ; Maling list - DRI developers
; Deucher, Alexander
;
On Wed, Feb 26, 2020 at 10:36 AM Zuo, Jerry wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Alex:
>
> The patch set works. Please let me know when you push the change to
> drm-next.
Can someone give me and R-b or A-b on the patches?
Thanks,
Alex
>
> Thanks a
[AMD Official Use Only - Internal Distribution Only]
Hi Alex:
The patch set works. Please let me know when you push the change to
drm-next.
Thanks a lot.
Regards,
Jerry
-Original Message-
From: Alex Deucher
Sent: February 25, 2020 1:42 PM
To: Zuo, Jerry
Cc: Liu, Zhan ;
On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede wrote:
>
> Hi Lyude and everyone else,
>
> Lyude I'm mailing you about this because you have done a lot of
> work on DP MST, but if this rings a bell to anyone else feel
> free to weigh in on this.
Might be a duplicate of:
On Wed, Feb 26, 2020 at 4:05 AM Daniel Vetter wrote:
>
> On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote:
> > Hi Jason,
> >
> > Am 26.02.20 um 00:58 schrieb Jason Ekstrand:
> > > Explicit synchronization is the future. At least, that seems to be what
> > > most userspace APIs are
As seen in the Vivante kernel driver, most GPUs with the BLT engine have
a broken TS cache flush. The workaround is to temporarily set the BLT
command to CLEAR_IMAGE, without actually executing the clear. Apparently
this state change is enough to trigger the required TS cache flush. As
the BLT
Hi Christian,
series applied to etnaviv/next.
Regards,
Lucas
On Mo, 2020-01-06 at 16:16 +0100, Christian Gmeiner wrote:
> Update the state HI header from rnndb commit
> 7f1ce75 ("rnndb: document some GPU identity register")
>
> Signed-off-by: Christian Gmeiner
> ---
>
Hi Christian,
sorry for taking so long to get around to this.
On Mo, 2020-01-06 at 11:43 +0100, Christian Gmeiner wrote:
> Report the correct perfmon domains and signals depending
> on the supported feature flags.
>
> Reported-by: Dan Carpenter
> Fixes: 9e2c2e273012 ("drm/etnaviv: add
On Mon, 2020-02-24 at 15:07 +0100, Sebastian Andrzej Siewior wrote:
> vmw_fifo_ping_host() disables preemption around a test and a register
> write via vmw_write(). The write function acquires a spinlock_t typed
> lock which is not allowed in a preempt_disable()ed section on
> PREEMPT_RT. This has
Hi Lyude and everyone else,
Lyude I'm mailing you about this because you have done a lot of
work on DP MST, but if this rings a bell to anyone else feel
free to weigh in on this.
I'm currently using a Lenovo X1 7th gen + a Lenovo TB3 gen 2 dock
as my daily rider for testing purposes. When
On 2/23/20 9:40 PM, Maya Rashish wrote:
Signed-off-by: Maya Rashish
Signed-off-by: Thomas Klausner
Co-authored-by: Thomas Klausner
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä
> wrote:
> > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> > > wrote:
> > > > On Tue, Feb 25, 2020 at 10:52:25PM
On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä
wrote:
> On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> > wrote:
> > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> >
> > > > I have long suspected that a whole
On Wed, Feb 26, 2020 at 12:10:08AM -0800, Vasily Khoruzhick wrote:
> Add vendor prefix for Guangdong Neweast Optoelectronics CO. LTD
>
> Signed-off-by: Vasily Khoruzhick
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob
On 26.02.2020 11:21, Daniel Vetter wrote:
> On Wed, Feb 26, 2020 at 10:21:17AM +0100, Andrzej Hajda wrote:
>> On 25.02.2020 16:03, Daniel Vetter wrote:
>>> On Tue, Feb 25, 2020 at 11:27 AM Andrzej Hajda wrote:
Hi Daniel,
The patchset looks interesting.
On
On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> wrote:
> > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
>
> > > I have long suspected that a whole bunch of the "simple" displays
> > > are not simple but contains
On Wed, Feb 26, 2020 at 5:17 AM Sharat Masetty wrote:
>
>
> On 2/21/2020 2:05 AM, Rob Herring wrote:
> > On Thu, 20 Feb 2020 13:42:22 +0530, Sharat Masetty wrote:
> >> This patch adds a clock definition needed for powering on the GPU TBUs
> >> and the GPU TCU.
> >>
> >> Signed-off-by: Sharat
Hi,
> -Original Message-
> From: Gerd Hoffmann
> Sent: 26 February 2020 07:46
> To: Guillaume Gardet
> Cc: Gurchetan Singh ; dri-
> de...@lists.freedesktop.org; Daniel Vetter ; Catalin
> Marinas ; nd ; Chia-I Wu
>
> Subject: Re: [Bug] virtio-gpu broken with qemu/kvm on arm64 on kernel
On Wed, Feb 26, 2020 at 8:30 AM Christian König
wrote:
>
> Am 25.02.20 um 20:12 schrieb Christian König:
> > Am 25.02.20 um 20:11 schrieb Alex Deucher:
> >> On Tue, Feb 25, 2020 at 2:09 PM Christian König
> >> wrote:
> >>> Am 25.02.20 um 19:56 schrieb Alex Deucher:
> From: Ahzo
>
>
On Wed, Feb 26, 2020 at 2:30 PM Christian König
wrote:
>
> Am 25.02.20 um 20:12 schrieb Christian König:
> > Am 25.02.20 um 20:11 schrieb Alex Deucher:
> >> On Tue, Feb 25, 2020 at 2:09 PM Christian König
> >> wrote:
> >>> Am 25.02.20 um 19:56 schrieb Alex Deucher:
> From: Ahzo
>
>
On 26/02/2020 10:06 am, Lukasz Luba wrote:
[...]
@@ -118,6 +120,7 @@ void panfrost_devfreq_fini(struct panfrost_device
*pfdev)
{
if (pfdev->devfreq.cooling)
devfreq_cooling_unregister(pfdev->devfreq.cooling);
+ dev_pm_opp_of_unregister_em(>pdev->dev);
[ /me fires off MAINTAINERS patch... ]
On 20/02/2020 9:02 pm, Matthias Kaehlcke wrote:
On Thu, Feb 20, 2020 at 01:42:22PM +0530, Sharat Masetty wrote:
This patch adds a clock definition needed for powering on the GPU TBUs
and the GPU TCU.
Signed-off-by: Sharat Masetty
---
Am 25.02.20 um 20:12 schrieb Christian König:
Am 25.02.20 um 20:11 schrieb Alex Deucher:
On Tue, Feb 25, 2020 at 2:09 PM Christian König
wrote:
Am 25.02.20 um 19:56 schrieb Alex Deucher:
From: Ahzo
Set the drm_device to NULL, so that the newly created buffer object
doesn't appear to use
Hi Laurentiu,
again a day later than promised, but here we go with some more
in-depth comments. Apologies if I missed something, my metal bandwidth
was pretty exhausted by the time I made my was to the scaler code. :)
On Fr, 2019-12-06 at 11:52 +0200, Laurentiu Palcu wrote:
> This adds initial
On 25/02/2020 01:20, Sebastian Reichel wrote:
> This updates the existing omapdrm DSI code, so that it uses
> common drm_mipi_dsi API and drm_panel.
>
> The patchset has been tested with Droid 4 using Linux console, X.org and
> Weston. The patchset is based on Laurent Pinchartl's patch series [0]
On 26/02/2020 01:52, Sebastian Reichel wrote:
Well for now let's get Laurent's and my series forward. I think
the next step would be to get rid of omap_encoder by moving the
encoder init into the DSS output code. Technically we are already
merging omapdrm and omapdss, e.g. omap_connector is
On 26/02/2020 13:24, Laurent Pinchart wrote:
Hello,
This version of the series is there just to make "dim apply" happy, as
it needs to get patches from the list. Sorry for the spam :-)
Thank you! I have pushed to drm-misc-next.
It's been a long journey here, now when we just get Sebastian's
1 - 100 of 227 matches
Mail list logo
