On Wed, 23 Sep 2020 at 16:27, Dave Airlie wrote:
>
> Spent today trying to straighten out some of the ideas I had for
> dropping bind/unbind paths into drivers.
>
> https://github.com/airlied/linux/commits/ttm-no-more-bind
>
> I think it mostly trends to the right place, the bind/unbind paths all
Hi,
Am Mittwoch, 23. September 2020, 08:59:00 CEST schrieb Jian-Hong Pan:
> The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
>
> kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing
> extcon or phy
> kernel: cdn-dp: probe of fec0.dp failed with error -2
Convert phy-mtk-ufs.txt to YAML schema mediatek,ufs-phy.yaml
Signed-off-by: Chunfeng Yun
---
.../bindings/phy/mediatek,ufs-phy.yaml| 64 +++
.../devicetree/bindings/phy/phy-mtk-ufs.txt | 38 ---
2 files changed, 64 insertions(+), 38 deletions(-)
create mode 100
Hi, Douglas
在 2020/9/22 17:31, Vicente Bergas 写道:
On Tue, Sep 22, 2020 at 11:24 AM crj wrote:
Hello Vicente,
在 2020/9/22 15:40, Andy Yan 写道:
Add our HDMI driver owner Algea to list.
On 9/22/20 2:18 AM, Vicente Bergas wrote:
Under certain conditions vop_crtc_mode_fixup rounds the clock
Ma
On Tue, Sep 22, 2020 at 04:39:06PM +0200, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 12:21:44PM +0100, Matthew Wilcox wrote:
> > Actually, vfree() will work today; I cc'd you on a documentation update
> > to make it clear that this is permitted.
>
> vfree calls __free_pages, the i915 and a
Add our HDMI driver owner Algea to list.
On 9/22/20 2:18 AM, Vicente Bergas wrote:
Under certain conditions vop_crtc_mode_fixup rounds the clock
14850 to 148501000 which leads to the following error:
dwhdmi-rockchip ff94.hdmi: PHY configuration failed (clock 148501000)
The issue was fou
Modify the comment typo: "definately" -> "definitely".
Signed-off-by: Wang Qing
---
drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/radeon/radeon_vm.c
index f60fae0..3d6e2cd
--- a/drivers
Change the comment typo: "programm" -> "program".
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +-
drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 4 ++--
drivers/gpu/drm/amd/
Alrighty, I'll take everyone else's silence as tacit approval of
Ville's opinions. (I didn't receive any email bounces this time, so I
think my issue was transient.) I will start on inverting the quirk and
making the most-significant-alignment matter for these registers by
default.
Who can help me
Series is:
Acked-by: Alyssa Rosenzweig
On Tue, Sep 22, 2020 at 03:16:47PM +0100, Robin Murphy wrote:
> Hi all,
>
> Here's a quick v2 with the tags so far picked up and some inline
> commentary about the shareability domains for the pagetable code.
>
> Robin.
>
>
> Robin Murphy (3):
>
Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml
Signed-off-by: Chunfeng Yun
---
.../bindings/phy/mediatek,tphy.yaml | 260 ++
.../devicetree/bindings/phy/phy-mtk-tphy.txt | 162 ---
2 files changed, 260 insertions(+), 162 deletions(-)
create mode 10
This addresses the following gcc warning with "make W=1":
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_prepare’:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1378:6: warning:
variable ‘ret’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Tian Tao
Reviewed-by: Lyude Paul
On Tuesday, September 22, 2020 5:26:17 PM CEST, Doug Anderson wrote:
Hi,
On Tue, Sep 22, 2020 at 7:52 AM Vicente Bergas wrote:
On Tue, Sep 22, 2020 at 4:28 PM Doug Anderson
wrote: ...
Here's the code:
rate = clk_round_rate(vop->dclk, adjusted_mode->clock * 1000 + 999);
adjusted_mode->c
Adding driver implementation to support i2c driver algorithms for
bit-shift adapters, so hibmc will using the interface provided by
drm to read edid.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/Makefile| 2 +-
drivers/gpu/drm/hisilicon/hib
On Fri, Sep 4, 2020 at 10:17 AM allen wrote:
>
> This adds support for the iTE IT6505.
> This device can convert DPI signal to DP output.
>
> From: Allen Chen
> Signed-off-by: Jitao Shi
> Signed-off-by: Pi-Hsun Shih
> Signed-off-by: Yilun Lin
> Signed-off-by: Hermes Wu
> Signed-off-by: Allen
The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing
extcon or phy
kernel: cdn-dp: probe of fec0.dp failed with error -22
Then, the device halts all of the DRM related device jobs. For example,
the operat
This patch fixes below warnings reported by coccicheck
./drivers/dma-buf/heaps/heap-helpers.c:202:5-8: Unneeded variable: "ret".
Return "0" on line 215
Signed-off-by: Zou Wei
---
drivers/dma-buf/heaps/heap-helpers.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/
This addresses the following gcc warning with "make W=1":
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_prepare’:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1378:6: warning:
variable ‘ret’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Tian Tao
---
drivers/gpu/drm/nou
Hello Vicente,
在 2020/9/22 15:40, Andy Yan 写道:
Add our HDMI driver owner Algea to list.
On 9/22/20 2:18 AM, Vicente Bergas wrote:
Under certain conditions vop_crtc_mode_fixup rounds the clock
May I ask under what conditions that the clock of HDMI will
be changed to 148501000? In general,
patch #1 add a new file to implements i2c adapters, #2 read the
resolution from the edid, if that fails, set the resolution to fixed.
and update the destroy callback function to release the i2c adapters
Changes since v1:
-merge patch #3 into patch #2.
-add new function to_hibmc_drm_private, modify
On Tue, Sep 22, 2020 at 08:22:49AM +0200, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote:
> > This is awkward. I'd like it if we had a vfree() variant which called
> > put_page() instead of __free_pages(). I'd like it even more if we
> > used release_pag
This addresses the following gcc warning with "make W=1":
drivers/gpu/drm/v3d/v3d_drv.c:73:32: warning:
‘v3d_v3d_pm_ops’ defined but not used [-Wunused-const-variable=]
Reported-by: Hulk Robot
Signed-off-by: Li Heng
---
drivers/gpu/drm/v3d/v3d_drv.c | 4
1 file changed, 4 deletions(-)
di
+Lyude
I notice that Lyude email was somehow dropped from the thread.
Lyude was the person who submitted the patch for Thinkpad and should
know the OUI of the panel.
On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski wrote:
>
> Alrighty, I'll take everyone else's silence as tacit approval of
> Ville'
For a video mode to work it suffices that the available bandwidth is
large enough. There is no need to have an exact match.
This greatly expands the list of supported monitors.
Signed-off-by: Vicente Bergas
Tested-by: Vicente Bergas
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
1 fil
Convert HDMI PHY binding to YAML schema mediatek,ufs-phy.yaml
Signed-off-by: Chunfeng Yun
---
.../display/mediatek/mediatek,hdmi.txt| 17 +---
.../bindings/phy/mediatek,hdmi-phy.yaml | 90 +++
2 files changed, 91 insertions(+), 16 deletions(-)
create mode 100644 Do
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_afmt.c: warning:
variable speakers set but not used
Reported-by: Hulk Robot
Signed-off-by: Li Heng
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_afmt.c | 2 --
1 file changed, 2 deletions(-)
diff --git
Hi Laurent,
Thanks for the patch.
> Subject: [PATCH v3] drm/bridge: lvds-codec: Add support for regulator
>
> From: Biju Das
>
> Add the support for enabling optional regulator that may be used as VCC
> source.
>
> Signed-off-by: Biju Das
> Reviewed-by: Laurent Pinchart
> [Replaced 'error' var
Under certain conditions vop_crtc_mode_fixup rounds the clock
14850 to 148501000 which leads to the following error:
dwhdmi-rockchip ff94.hdmi: PHY configuration failed (clock 148501000)
The issue was found on RK3399 booting with u-boot. U-boot configures the
display at 2560x1440 and then
Thanks for the review.
Sorry for that I thought the review tag should be appended by myself.
One thing to confirm with you, will you or I push this patch to drm-misc-next ?
Thanks a lot.
On Wed, Sep 23, 2020 at 2:01 AM Lyude Paul wrote:
>
> One last change I realized we should do is print the na
Use kobj_to_dev() instead of container_of()
Signed-off-by: Wang Qing
---
drivers/video/fbdev/aty/radeon_base.c | 4 ++--
drivers/video/fbdev/udlfb.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_base.c
b/drivers/video/fbdev/aty
On Tue, Sep 22, 2020 at 11:24 AM crj wrote:
>
> Hello Vicente,
>
> 在 2020/9/22 15:40, Andy Yan 写道:
> > Add our HDMI driver owner Algea to list.
> >
> > On 9/22/20 2:18 AM, Vicente Bergas wrote:
> >> Under certain conditions vop_crtc_mode_fixup rounds the clock
>
>
> May I ask under what conditions
On Tue, Sep 22, 2020 at 4:28 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Sep 22, 2020 at 3:13 AM crj wrote:
> >
> > Hi, Douglas
> >
> > 在 2020/9/22 17:31, Vicente Bergas 写道:
> > > On Tue, Sep 22, 2020 at 11:24 AM crj wrote:
> > >> Hello Vicente,
> > >>
> > >> 在 2020/9/22 15:40, Andy Yan 写道:
> >
在 2020/9/23 4:31, Vicente Bergas 写道:
Under certain conditions vop_crtc_mode_fixup rounds the clock
14850 to 148501000 which leads to the following error:
dwhdmi-rockchip ff94.hdmi: PHY configuration failed (clock 148501000)
The issue was found on RK3399 booting with u-boot. U-boot confi
Change the comment typo: "programm" -> "program".
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/radeon/uvd_v1_0.c | 4 ++--
drivers/gpu/drm/radeon/uvd_v2_2.c | 2 +-
drivers/gpu/drm/radeon/uvd_v4_2.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/
In order to support video resolutions beyond FHD more bandwidth is needed.
The new entry values have been taken from u-boot:
https://gitlab.denx.de/u-boot/u-boot/-/blob/ba2a0cbb053951ed6d36161989d38da724696b4d/drivers/video/rockchip/rk_hdmi.c#L63
Signed-off-by: Vicente Bergas
Tested-by: Vicente B
Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml
Signed-off-by: Chunfeng Yun
---
.../bindings/phy/mediatek,xsphy.yaml | 203 ++
.../devicetree/bindings/phy/phy-mtk-xsphy.txt | 109 --
2 files changed, 203 insertions(+), 109 deletions(-)
create mode 1
Use drm_get_edid to get the resolution, if that fails, set it to
a fixed resolution. Rewrite the desrtoy callback function to release
resources.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 38 +---
1 file chan
This patch series enable a QHD HDMI monitor to work at native resolution.
Tested on a Sapphire board with RK3399 connected to a Q27q-10 monitor at
2560x1440@60
Changes since v1:
Use alternative clock rounding code proposed by Doug Anderson
Vicente Bergas (3):
drm: rockchip: hdmi: fix clock rou
On 08.09.20 17:33, Joao Martins wrote:
> [Sorry for the late response]
>
> On 8/21/20 11:06 AM, David Hildenbrand wrote:
>> On 03.08.20 07:03, Dan Williams wrote:
>>> @@ -37,109 +45,94 @@ int dev_dax_kmem_probe(struct device *dev)
>>> * could be mixed in a node with faster memory, causing
>>>
On Tue, 22 Sep 2020 20:18:34 +0200
Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this happened
On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote:
> On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote:
> > On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
> >>
> >> If a task is migrated to a different CPU then the mapping address will
> >> change which will explode in colo
On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen wrote:
>
> On Tue, 22 Sep 2020 20:18:34 +0200
> Daniel Vetter wrote:
>
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
On Fri, Aug 28, 2020 at 12:40:10PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Hi,
>
> This series implements a new IOCTL to submit push buffers that can
> optionally return a sync FD or sync object to userspace. This is useful
> in cases where userspace wants to synchronize operatio
On Wed, Sep 23, 2020 at 11:16 AM Daniel Vetter wrote:
>
> On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen wrote:
> >
> > On Tue, 22 Sep 2020 20:18:34 +0200
> > Daniel Vetter wrote:
> >
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other reso
On Wed, 2020-09-23 at 13:17 +1000, Dave Airlie wrote:
> On Fri, 18 Sep 2020 at 00:49, Christian König <
> christian.koe...@amd.com> wrote:
> > Am 17.09.20 um 16:44 schrieb Michel Dänzer:
> > > On 2020-09-17 2:20 p.m., Christian König wrote:
> > > > Hi guys,
> > > >
> > > > Michel once submitted a
I'm really not awake yet ...
On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen wrote:
>
> On Tue, 22 Sep 2020 20:18:34 +0200
> Daniel Vetter wrote:
>
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > rec
On Wed, Sep 23, 2020 at 11:24 AM Hellstrom, Thomas
wrote:
>
> On Wed, 2020-09-23 at 13:17 +1000, Dave Airlie wrote:
> > On Fri, 18 Sep 2020 at 00:49, Christian König <
> > christian.koe...@amd.com> wrote:
> > > Am 17.09.20 um 16:44 schrieb Michel Dänzer:
> > > > On 2020-09-17 2:20 p.m., Christian
On 18/09/2020 17:37, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_v
On Wed, 23 Sep 2020 11:26:39 +0200
Daniel Vetter wrote:
> I'm really not awake yet ...
>
> On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen wrote:
> >
> > On Tue, 22 Sep 2020 20:18:34 +0200
> > Daniel Vetter wrote:
> >
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed
On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote:
> Alternatively this could of course be solved with per CPU page tables
> which will come around some day anyway I fear.
Previously (with PTI) we looked at making the entire kernel map per-CPU,
and that takes a 2K copy on switch_mm()
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in armada.
Signed-off-by: Thomas Zimmermann
Acked-by: Russell King
---
drivers/gpu/drm/armada/armada_drv.c | 3 ---
drivers/gpu/drm/
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v3:
* remove amdgpu_object.c from patch (Chris
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in gma500.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/gma500/framebuffer.c | 2 ++
drivers/gpu/
The GEM and PRIME related callbacks in struct drm_driver are deprecated in
favor of GEM object functions in struct drm_gem_object_funcs. This patchset
converts the remaining drivers to object functions and removes most of the
obsolete interfaces.
Version 3 of this patchset mostly fixes drm_gem_pri
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in mediatek. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Danie
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in i915.
v2:
* move object-function instance to i915_gem_object.c (Jani)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Tvrtko
The i.MX DCSS driver uses CMA helpers with default callback functions.
Initialize the driver structure with the rsp CMA helper macro. The
driver is being converted to use GEM object functions as part of
this change.
Two callbacks, .gem_prime_export and .gem_prime_import, were initialized
to their
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in omapdrm.
v2:
* make omap_gem_free_object() static (Tomi)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Re
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in tegra.
Signed-off-by: Thomas Zimmermann
Acked-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 4
drivers/gpu/drm/tegra/g
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vgem. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Melissa W
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in rockchip. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v3:
* update documentation
Signed-off-by: T
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in radeon.
v2:
* move object-function instance to radeon_gem.c (Christian)
* set callbacks in radeon_gem_object_create()
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vc4. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Eric Anhol
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in nouveau.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 -
d
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in msm. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vet
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in exynos. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in pl111. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v2:
* use drm_gem_cma_create_object_default_fun
The xlnx driver uses CMA helpers with default callback functions.
Initialize the driver structure with the rsp CMA helper macro. The
driver is being converted to use GEM object functions as part of
this change.
Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
to their default i
Several GEM and PRIME callbacks have been deprecated in favor of
per-instance GEM object functions. Remove the callbacks as they are
now unused. The only exception is .gem_prime_mmap, which is still
in use by several drivers.
What is also gone is gem_vm_ops in struct drm_driver. All drivers now
us
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in xen. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v2:
* convert xen_drm_drv_free_object_unlocked()
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vkms.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Melissa Wen
---
drivers/gpu/drm/vkms/vkms_drv.c | 8
drivers/gpu/drm
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
function with a per-object function.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.c| 1 -
driv
Hi Stephen,
On 23/09/2020 06:36, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
> 'cdns_mhdp_fw_activate':
> drivers/gpu/drm/bridge/cad
On Tue, Sep 22, 2020 at 08:18:34PM +0200, Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this hap
On Wed, Sep 23, 2020 at 12:31 PM Ville Syrjälä
wrote:
>
> On Tue, Sep 22, 2020 at 08:18:34PM +0200, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
Hopefully we'll have the drm crash recorder RSN, but meanwhile
compositors would like to know a bit better why they get an EBUSY.
Cc: Sean Paul
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c| 4 ++--
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CR
On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
>
> On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote:
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources, includin
On 2020-09-23 07:59, Jian-Hong Pan wrote:
The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing
extcon or phy
kernel: cdn-dp: probe of fec0.dp failed with error -22
Wouldn't it make more sense to simply
On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
> >
> > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote:
> > > > When doing an atomic modeset with ALLOW_MODESET
On Wed, Sep 23, 2020 at 1:14 PM Marius Vlad wrote:
>
> On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad
> > wrote:
> > >
> > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> > > > On Thu, 5 Jul 2018 at 11:21, Daniel V
Am Mittwoch, 23. September 2020, 13:05:26 CEST schrieb Robin Murphy:
> On 2020-09-23 07:59, Jian-Hong Pan wrote:
> > The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
> >
> > kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR*
> > missing extcon or phy
> > kernel: c
Hi Thomas,
On Wed, Sep 23, 2020 at 12:21:44PM +0200, Thomas Zimmermann wrote:
> The i.MX DCSS driver uses CMA helpers with default callback functions.
> Initialize the driver structure with the rsp CMA helper macro. The
> driver is being converted to use GEM object functions as part of
> this chan
On Wed, Sep 23, 2020 at 01:16:42PM +0200, Daniel Vetter wrote:
> On Wed, Sep 23, 2020 at 1:14 PM Marius Vlad wrote:
> >
> > On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad
> > > wrote:
> > > >
> > > > On Fri, Jan 31, 2020 at 07:34:
On Mon, Sep 21, 2020 at 9:10 PM Peter Collingbourne wrote:
>
> On Mon, Sep 21, 2020 at 2:32 PM Linus Walleij
> wrote:
> >
> > On Tue, Sep 15, 2020 at 3:10 AM Peter Collingbourne wrote:
> > > On Tue, Jun 9, 2020 at 1:08 PM Linus Walleij
> > > wrote:
> > > >
> > > > All the functionality in thi
All
On 9/22/20 4:36 AM, Mark Brown wrote:
On Tue, Sep 22, 2020 at 09:08:37AM +0200, Krzysztof Kozlowski wrote:
On Mon, 21 Sep 2020 at 23:06, Pavel Machek wrote:
I believe normal way would be to mark the entries "orphaned", not to
drop them altogether. Plus, I believe someone from TI is likely
On Mi, 2020-09-23 at 12:21 +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
> which is non-trivial
On x64 we get:
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: conversion
from 'long unsigned int' to 'unsigned int' changes value from
'18446744073709551613' to '4294967293' [-Woverflow]
The registers are 32 bit, so fix by casting to u32.
Fixes: fb43aa0acdfd ("drm: bridge
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
use struct dma_buf_map. The interfaces used to receive a buffer address.
This address is now given in an instance of the structure.
Users of the functions are updated accordingly. This is only an interface
change. It is currently
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The functions return an errno code on errors.
Users of the
Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
of dma-buf memory in kernel address space. The functions operate with plain
addresses and the assumption is that the memory can be accessed with load
and store operations. This is not the case on some architectures (e.g.,
sp
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA buffer memory can be accessed with regular load
an
Ping? Ben, Dave any comment on this?
Am 17.09.20 um 16:29 schrieb Christian König:
According to Ben this is most likely just a leftover.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouvea
Hi
On Wed, 23 Sep 2020 at 08:53, Li Heng wrote:
>
> This addresses the following gcc warning with "make W=1":
>
> drivers/gpu/drm/v3d/v3d_drv.c:73:32: warning:
> ‘v3d_v3d_pm_ops’ defined but not used [-Wunused-const-variable=]
>
> Reported-by: Hulk Robot
> Signed-off-by: Li Heng
> ---
> driver
On 23/09/2020 14:41, Christoph Hellwig wrote:
On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote:
On 18/09/2020 17:37, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel mem
Am 23.09.20 um 11:24 schrieb Hellstrom, Thomas:
On Wed, 2020-09-23 at 13:17 +1000, Dave Airlie wrote:
On Fri, 18 Sep 2020 at 00:49, Christian König <
christian.koe...@amd.com> wrote:
Am 17.09.20 um 16:44 schrieb Michel Dänzer:
On 2020-09-17 2:20 p.m., Christian König wrote:
Hi guys,
Michel o
On Wed, 2020-09-23 at 10:16 +0800, Koba Ko wrote:
> Thanks for the review.
> Sorry for that I thought the review tag should be appended by myself.
> One thing to confirm with you, will you or I push this patch to drm-misc-
> next ?
I already pushed it with the change, so everything is all set
> T
Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA
Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The funct
1 - 100 of 223 matches
Mail list logo
