[PATCH] drm/radeon: avoid a possible array overflow
From: Young Xiao
When looking up the connector type make sure the index
is valid. Avoids a later crash if we read past the end
of the array.
See commit e1718d97aa88 ("drm/amdgpu: avoid a possible
array overflow") for detail.
Signed-off-by: Young Xiao
---
drivers/gpu/drm/radeon/radeon_atombios.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index f422a8d..9121961 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -583,6 +583,12 @@ bool
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
ATOM_DEVICE_CV_SUPPORT)
continue;
+ if (con_obj_id >= ARRAY_SIZE(object_connector_convert))
{
+ DRM_ERROR("invalid con_obj_id %d for device tag
0x%04x\n",
+ con_obj_id,
le16_to_cpu(path->usDeviceTag));
+ continue;
+ }
+
/* IGP chips */
if ((rdev->flags & RADEON_IS_IGP) &&
(con_obj_id ==
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/9] Use vm_insert_range
Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating a new function and use it across the drivers. vm_insert_range is the new API which will be used to map a range of kernel memory/pages to user vma. All the applicable places are converted to use new vm_insert_range in this patch series. v1 -> v2: Address review comment on mm/memory.c. Add EXPORT_SYMBOL for vm_insert_range and corrected the documentation part for this API. In drivers/gpu/drm/xen/xen_drm_front_gem.c, replace err with ret as suggested. In drivers/iommu/dma-iommu.c, handle the scenario of partial mmap() of large buffer by passing *pages + vma->vm_pgoff* to vm_insert_range(). v2 -> v3: Declaration of vm_insert_range() moved to include/linux/mm.h v3 -> v4: Address review comments. In mm/memory.c. Added error check. In arch/arm/mm/dma-mapping.c, remove part of error check as the similar is checked inside vm_insert_range. In rockchip/rockchip_drm_gem.c, vma->vm_pgoff is respected as this might be passed as non zero value considering partial mapping of large buffer. In iommu/dma-iommu.c, count is modifed as (count - vma->vm_pgoff) to handle partial mapping scenario in v2. Souptick Joarder (9): mm: Introduce new vm_insert_range API arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range drivers/firewire/core-iso.c: Convert to use vm_insert_range drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range iommu/dma-iommu.c: Convert to use vm_insert_range videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range xen/gntdev.c: Convert to use vm_insert_range xen/privcmd-buf.c: Convert to use vm_insert_range arch/arm/mm/dma-mapping.c | 21 drivers/firewire/core-iso.c | 15 ++--- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19 ++- drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 --- drivers/iommu/dma-iommu.c | 13 ++- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23 - drivers/xen/gntdev.c | 11 +++--- drivers/xen/privcmd-buf.c | 8 ++--- include/linux/mm.h| 2 ++ mm/memory.c | 41 +++ mm/nommu.c| 7 11 files changed, 83 insertions(+), 97 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/shmob: Fix return value check in shmob_drm_probe
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Fixes: 8f1597c8f1a5 ("drm: shmobile: Perform initialization/cleanup at
probe/remove time")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index 8554102..f2cfd16 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -229,8 +229,8 @@ static int shmob_drm_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sdev->mmio = devm_ioremap_resource(>dev, res);
- if (sdev->mmio == NULL)
- return -ENOMEM;
+ if (IS_ERR(sdev->mmio))
+ return PTR_ERR(sdev->mmio);
ret = shmob_drm_setup_clocks(sdev, pdata->clk_source);
if (ret < 0)
--
2.7.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/shmob: Fix return value check in shmob_drm_probe
On Mon, Dec 17, 2018 at 05:18:30PM +0800, YueHaibing wrote:
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
>
> Fixes: 8f1597c8f1a5 ("drm: shmobile: Perform initialization/cleanup at
> probe/remove time")
> Signed-off-by: YueHaibing
Reviewed-by: Simon Horman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Disable -Wuninitialized for intel_breadcrumbs.o
On Thu, Oct 25, 2018 at 12:36:01PM -0700, Nathan Chancellor wrote:
> This warning is disabled by default in scripts/Makefile.extrawarn when
> W= is not provided but this Makefile adds -Wall after this warning is
> disabled so it shows up in the build when it shouldn't:
>
> In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
> drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
> variable 'wq' is uninitialized when used within its own initialization
> [-Werror,-Wuninitialized]
> DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> ^~
> ./include/linux/wait.h:74:63: note: expanded from macro
> 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> ^~~~
> ./include/linux/wait.h:72:33: note: expanded from macro
> '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> ({ init_waitqueue_head(); name; })
>^~~~
> 1 error generated.
>
> This warning looks to be a false positive given that init_waitqueue_head
> initializes name before it is used. Rather than disable the warning for
> the full folder like commit 46e2068081e9 ("drm/i915: Disable some extra
> clang warnings"), just disable it for the one problematic file because
> it could be a useful warning for other cases.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/220
> Signed-off-by: Nathan Chancellor
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 1c2857f13ad4..f36c420afb99 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -26,6 +26,7 @@ subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
>
> # Fine grained warnings disable
> CFLAGS_i915_pci.o = $(call cc-disable-warning, override-init)
> +CFLAGS_intel_breadcrumbs.o = $(call cc-disable-warning, uninitialized)
> CFLAGS_intel_fbdev.o = $(call cc-disable-warning, override-init)
>
> subdir-ccflags-y += \
> --
> 2.19.1
>
Gentle ping for review.
Nathan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: renesas: du: Document r8a774c0 bindings
On Thu, Dec 13, 2018 at 08:20:45PM +, Fabrizio Castro wrote: > Document the RZ/G2E (a.k.a. r8a774c0) SoC in the R-Car DU bindings. > > Signed-off-by: Fabrizio Castro Reviewed-by: Simon Horman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dts: rockchip: rk3066: add qos_hdmi and HCLK_HDMI to pmu node
Hi all, Thanks Tomasz for adding all the mailing lists. I prefer to ask first if a qos_hdmi exists before sending it in for public review. All the clocks in the pmu node seem to have a "quality-of-service" (QoS) block. So I added one for hdmi too with the question if it exists and which address it might have. SoC documentation still isn't fully public, not that I'm aware off. From Heiko's response I learned that the rk3066 manual does not list any hdmi-related QoS blocks. We now only add the HCLK_HDMI clock to pmu node in our patch. After a small step forward people immediately ask to do a real patch serie. The rk3066_hdmi.c file also handles audio, but this is not tested yet. The rk3066a-rayeager.dts file gives a idea how it's done, but I haven't had the time to get it working with .config and dts. Let me know if you can. That's it for now. On 12/17/18 6:46 AM, Tomasz Figa wrote: > Thanks for the patch. Unfortunately, it looks like you didn't add the > necessary mailing lists to the recipient list. For reference, the > ./scripts/get_maintainer.pl script in the kernel source tree should be > able to give you a reasonable recipient list. For now, I added the > mailing lists on CC and replied without snipping, so people should be > still able to review the patch. > > Other than that, It looks reasonable to me, but we need someone with > access to SoC documentation to check it. Heiko, Sandy, is that > something you would be able to help with? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][resend] drm: dw-hdmi-i2s: convert to SPDX identifiers
From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto --- few weeks passed, nothing happen. I re-post this patch again. I added Andrew on Cc drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index 8f9c8a6..2228689 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c @@ -1,12 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0 /* * dw-hdmi-i2s-audio.c * * Copyright (c) 2017 Renesas Solutions Corp. * Kuninori Morimoto - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. */ #include -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: VC4 DRM
Eric, thanks for answer, I am in doubt the type of my panel. It is Himax HX8379A-based panel. Is there a deterministic way to find out which type of panel I have, video or command ? Sergey On 12/17/18 9:12 PM, Eric Anholt wrote: Sergey Suloev writes: Eric, Noralf, could either of you answer a question about Vc4 DRM, please ? I am trying to connect MIPI DSI display to VC4 but it isn't showing anything. I have noticed that the DSI host transfer() method vc4_dsi_host_transfer gets called for the commands that I am sending from my panel driver, but not for pixel data. My question: are pixel data normally transferred the same method within vc4_dsi driver or any "behind the scene" way ? The transfer function isn't used for pixel data in video mode. The vc4 panel has never been used for command mode panels, so if you have one of those it will probably be extra work. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: renesas: lvds: Document r8a774c0 bindings
On Thu, Dec 13, 2018 at 08:20:54PM +, Fabrizio Castro wrote: > The RZ/G2E (r8a774c0) supports two LVDS channels. Extend the binding to > support them. > > Signed-off-by: Fabrizio Castro Reviewed-by: Simon Horman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/i915: Move to new PM core fields
On Mon, 17 Dec 2018 at 15:22, Vincent Guittot
wrote:
>
> On Fri, 14 Dec 2018 at 15:36, Ulf Hansson wrote:
> >
> > On Fri, 14 Dec 2018 at 15:22, Vincent Guittot
> > wrote:
> > >
> > > With jiffies been replaced by raw ns in PM core accounting, 915 driver is
> > > updated to use this new time infrastructure.
> > >
> > > Signed-off-by: Vincent Guittot
> > > ---
> > > drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
> > > drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
> > > 2 files changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > index d6c8f8f..cf6437d 100644
> > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > @@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private *i915)
> > > */
> > > if (kdev->power.runtime_status == RPM_SUSPENDED) {
> > > if
> > > (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> > > - i915->pmu.suspended_jiffies_last =
> > > -
> > > kdev->power.suspended_jiffies;
> > > + i915->pmu.suspended_time_last =
> > > + kdev->power.suspended_time;
> > >
> >
> > Huh, so patch 2 introduces a complier error because of removing the
> > old fields. We can't have that.
>
> I agree
> The patch was mainly to raise discussion
> >
> > Ideally the driver shouldn't touch these fields in the first place,
> > but because the fields are defined in a public header, there is always
> > a risk that they becomes abused. I would appreciate if we can change
> > the driver move away from using these fields and make that a patch
> > preceding patch 2.
>
> In fact, the driver doesn't only use some internal fields but also
> takes the power.lock
> IIUC, the driver wants the current pm runtime suspended time to
> estimate a metric when perf events are not accessible
Huh, so it's even worse. :-(
I had a brief look at the runtime PM deployment for these drivers and
it's really messy. Unfortunate, I have limited knowledge about the
gpu/drm drivers, so I can't tell without a investing in a deeper
analyze, of how to convert to something more generic.
> I'm going to send a new version with a runtime pm interface proposal to fix
> this
Yeah, please go ahead and try something, I am willing to help review.
> >
> > > - val = kdev->power.suspended_jiffies -
> > > - i915->pmu.suspended_jiffies_last;
> > > - val += jiffies - kdev->power.accounting_timestamp;
> > > + val = kdev->power.suspended_time -
> > > + i915->pmu.suspended_time_last;
> > > + val += ktime_to_ns(ktime_get()) -
> > > + kdev->power.accounting_timestamp;
> > >
> > > - val = jiffies_to_nsecs(val);
> > > val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
> > >
> > > i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur
> > > = val;
> > > diff --git a/drivers/gpu/drm/i915/i915_pmu.h
> > > b/drivers/gpu/drm/i915/i915_pmu.h
> > > index 7f164ca..3dc2a30 100644
> > > --- a/drivers/gpu/drm/i915/i915_pmu.h
> > > +++ b/drivers/gpu/drm/i915/i915_pmu.h
> > > @@ -95,9 +95,9 @@ struct i915_pmu {
> > > */
> > > struct i915_pmu_sample sample[__I915_NUM_PMU_SAMPLERS];
> > > /**
> > > -* @suspended_jiffies_last: Cached suspend time from PM core.
> > > +* @suspended_time_last: Cached suspend time from PM core.
> > > */
> > > - unsigned long suspended_jiffies_last;
> > > + u64 suspended_time_last;
> > > /**
> > > * @i915_attr: Memory block holding device attributes.
> > > */
> > > --
> > > 2.7.4
> > >
Kind regards
Uffe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation
On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote: > Hello, Juergen, Boris! > > As this DRM part of the series is the only one which needs ack/nack > > (and it might take quite some time to complete) could we please > > merge the patches 1 and 3 now that already have ack/r-b? > TBH I am not sure it makes sense to do this without the second patch. Refactoring (and IIUIC this series is purely refactoring --- is it not?) is done to reduce amount of code, and with only first and third patch we end up with quite a significant increase in the number of LoC. (I am going purely by diffstat) Of course, the other reason for refactoring is to eliminate code duplication, but without second patch that will not happen. -boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/9] drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 47ff019..c21e5d1 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -225,8 +225,7 @@ struct drm_gem_object *
static int gem_mmap_obj(struct xen_gem_object *xen_obj,
struct vm_area_struct *vma)
{
- unsigned long addr = vma->vm_start;
- int i;
+ int ret;
/*
* clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
@@ -247,18 +246,11 @@ static int gem_mmap_obj(struct xen_gem_object *xen_obj,
* FIXME: as we insert all the pages now then no .fault handler must
* be called, so don't provide one
*/
- for (i = 0; i < xen_obj->num_pages; i++) {
- int ret;
-
- ret = vm_insert_page(vma, addr, xen_obj->pages[i]);
- if (ret < 0) {
- DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
- return ret;
- }
-
- addr += PAGE_SIZE;
- }
- return 0;
+ ret = vm_insert_range(vma, vma->vm_start, xen_obj->pages,
+ xen_obj->num_pages);
+ if (ret < 0)
+ DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
+ return ret;
}
int xen_drm_front_gem_mmap(struct file *filp, struct vm_area_struct *vma)
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: lvds: add R8A774C0 support
On Thu, Dec 13, 2018 at 08:23:36PM +, Fabrizio Castro wrote: > The LVDS implementation on the RZ/G2E (a.k.a. R8A774C0) is very similar > to the one found on R-Car E3 (a.k.a. R8A77990), therefore add RZ/G2E > LVDS support to the LVDS encoder driver in a similar fashion to what > done for R-Car E3. > > Signed-off-by: Fabrizio Castro Reviewed-by: Simon Horman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation
On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote: > On 12/17/18 4:52 PM, Boris Ostrovsky wrote: >> On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote: >>> Hello, Juergen, Boris! >>> >>> As this DRM part of the series is the only one which needs ack/nack >>> >>> (and it might take quite some time to complete) could we please >>> >>> merge the patches 1 and 3 now that already have ack/r-b? >>> >> >> >> TBH I am not sure it makes sense to do this without the second patch. >> Refactoring (and IIUIC this series is purely refactoring --- is it not?) >> is done to reduce amount of code, and with only first and third patch we >> end up with quite a significant increase in the number of LoC. (I am >> going purely by diffstat) >> >> Of course, the other reason for refactoring is to eliminate code >> duplication, but without second patch that will not happen. > > Agree, but this is the basis for the new pv camera frontend > > I am working on now [1], so even if we do not remove the code from DRM > > then we at least do not add it to the camera driver Since 1 and 3 are already ACKed you should be able to start the camera series with these two patches as pre-requisites even if patch 2 is still stalled by the time your camera code is posted (which I assume will be 4.22 or later). -boris > >> -boris > > Thank you, > > Oleksandr > > [1] > https://github.com/andr2000/linux/blob/camera_front_v1/drivers/media/xen/Kconfig#L6 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/9] mm: Introduce new vm_insert_range API
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
vm_insert_range is the new API which will be used to map a
range of kernel memory/pages to user vma.
This API is tested by Heiko for Rockchip drm driver, on rk3188,
rk3288, rk3328 and rk3399 with graphics.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Reviewed-by: Mike Rapoport
Reviewed-by: Mauro Carvalho Chehab
Tested-by: Heiko Stuebner
---
include/linux/mm.h | 2 ++
mm/memory.c| 41 +
mm/nommu.c | 7 +++
3 files changed, 50 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index fcf9cc9..2bc399f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2506,6 +2506,8 @@ unsigned long change_prot_numa(struct vm_area_struct *vma,
int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t);
int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long page_count);
vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn);
vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index 15c417e..d44d4a8 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1478,6 +1478,47 @@ static int insert_page(struct vm_area_struct *vma,
unsigned long addr,
}
/**
+ * vm_insert_range - insert range of kernel pages into user vma
+ * @vma: user vma to map to
+ * @addr: target user address of this page
+ * @pages: pointer to array of source kernel pages
+ * @page_count: number of pages need to insert into user vma
+ *
+ * This allows drivers to insert range of kernel pages they've allocated
+ * into a user vma. This is a generic function which drivers can use
+ * rather than using their own way of mapping range of kernel pages into
+ * user vma.
+ *
+ * If we fail to insert any page into the vma, the function will return
+ * immediately leaving any previously-inserted pages present. Callers
+ * from the mmap handler may immediately return the error as their caller
+ * will destroy the vma, removing any successfully-inserted pages. Other
+ * callers should make their own arrangements for calling unmap_region().
+ *
+ * Context: Process context. Called by mmap handlers.
+ * Return: 0 on success and error code otherwise
+ */
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long page_count)
+{
+ unsigned long uaddr = addr;
+ int ret = 0, i;
+
+ if (page_count > vma_pages(vma))
+ return -ENXIO;
+
+ for (i = 0; i < page_count; i++) {
+ ret = vm_insert_page(vma, uaddr, pages[i]);
+ if (ret < 0)
+ return ret;
+ uaddr += PAGE_SIZE;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(vm_insert_range);
+
+/**
* vm_insert_page - insert single page into user vma
* @vma: user vma to map to
* @addr: target user address of this page
diff --git a/mm/nommu.c b/mm/nommu.c
index 749276b..d6ef5c7 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned
long addr,
}
EXPORT_SYMBOL(vm_insert_page);
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long page_count)
+{
+ return -EINVAL;
+}
+EXPORT_SYMBOL(vm_insert_range);
+
/*
* sys_brk() for the most part doesn't need the global kernel
* lock, except when an application is doing something nasty
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Tested-by: Heiko Stuebner
Acked-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index a8db758..8279084 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -221,26 +221,11 @@ static int rockchip_drm_gem_object_mmap_iommu(struct
drm_gem_object *obj,
struct vm_area_struct *vma)
{
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
- unsigned int i, count = obj->size >> PAGE_SHIFT;
unsigned long user_count = vma_pages(vma);
- unsigned long uaddr = vma->vm_start;
unsigned long offset = vma->vm_pgoff;
- unsigned long end = user_count + offset;
- int ret;
-
- if (user_count == 0)
- return -ENXIO;
- if (end > count)
- return -ENXIO;
- for (i = offset; i < end; i++) {
- ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
- if (ret)
- return ret;
- uaddr += PAGE_SIZE;
- }
-
- return 0;
+ return vm_insert_range(vma, vma->vm_start, rk_obj->pages + offset,
+ user_count - offset);
}
static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: avoid division by zero on skl_calc_wrpll_link
From: Young Xiao
If for some unexpected reason the registers all read zero it's better
to WARN and return instead of dividing by zero and completely freezing
the machine.
See commit 0e005888b833 ("drm/i915: avoid division by zero on
cnl_calc_wrpll_link") for detail.
Signed-off-by: Young Xiao
---
drivers/gpu/drm/i915/intel_ddi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 5186cd7..cfa7d6f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1360,6 +1360,9 @@ static int skl_calc_wrpll_link(struct drm_i915_private
*dev_priv,
dco_freq += (((cfgcr1_val & DPLL_CFGCR1_DCO_FRACTION_MASK) >> 9) * 24 *
1000) / 0x8000;
+ if (WARN_ON(p0 == 0 || p1 == 0 || p2 == 0))
+ return 0;
+
return dco_freq / (p0 * p1 * p2 * 5);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation
On 12/17/18 5:26 PM, Boris Ostrovsky wrote: On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote: On 12/17/18 4:52 PM, Boris Ostrovsky wrote: On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote: Hello, Juergen, Boris! As this DRM part of the series is the only one which needs ack/nack (and it might take quite some time to complete) could we please merge the patches 1 and 3 now that already have ack/r-b? TBH I am not sure it makes sense to do this without the second patch. Refactoring (and IIUIC this series is purely refactoring --- is it not?) is done to reduce amount of code, and with only first and third patch we end up with quite a significant increase in the number of LoC. (I am going purely by diffstat) Of course, the other reason for refactoring is to eliminate code duplication, but without second patch that will not happen. Agree, but this is the basis for the new pv camera frontend I am working on now [1], so even if we do not remove the code from DRM then we at least do not add it to the camera driver Since 1 and 3 are already ACKed you should be able to start the camera series with these two patches as pre-requisites even if patch 2 is still stalled by the time your camera code is posted (which I assume will be 4.22 or later). Agreed, maybe by that time DRM part will also get its r-b/ack -boris -boris Thank you, Oleksandr [1] https://github.com/andr2000/linux/blob/camera_front_v1/drivers/media/xen/Kconfig#L6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][resend] drm: dw-hdmi-i2s: convert to SPDX identifiers
On Tue, Dec 18, 2018 at 7:47 AM Laurent Pinchart wrote: > > Hi Morimoto-san, > > Thank you for the patch. > > On Tuesday, 18 December 2018 08:00:24 EET Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > > > This patch updates license to use SPDX-License-Identifier > > instead of verbose license text. > > > > Signed-off-by: Kuninori Morimoto > > Reviewed-by: Laurent Pinchart > > > --- > > few weeks passed, nothing happen. I re-post this patch again. > > I added Andrew on Cc > > The driver seems to be lacking a maintainer :-S bridge drivers all have a fallback maintainer, but none of them are cc'ed. It's maintained in drm-misc, so you could just push the patch too :-) Especially since you're listed: DRM DRIVERS FOR BRIDGE CHIPS M:Archit Taneja M:Andrzej Hajda R:Laurent Pinchart S:Maintained T:git git://anongit.freedesktop.org/drm/drm-misc F:drivers/gpu/drm/bridge/ Cheers, Daniel > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 5 + > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index > > 8f9c8a6..2228689 100644 > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > > @@ -1,12 +1,9 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > /* > > * dw-hdmi-i2s-audio.c > > * > > * Copyright (c) 2017 Renesas Solutions Corp. > > * Kuninori Morimoto > > - * > > - * This program is free software; you can redistribute it and/or modify > > - * it under the terms of the GNU General Public License version 2 as > > - * published by the Free Software Foundation. > > */ > > #include > > > -- > Regards, > > Laurent Pinchart > > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: drm: Remove myself as drm-bridge maintainer
Hi Daniel, On Tuesday, 18 December 2018 11:39:22 EET Daniel Vetter wrote: > On Mon, Sep 17, 2018 at 5:49 PM Sean Paul wrote: > > On Thu, Sep 13, 2018 at 01:23:00PM +0530, Archit Taneja wrote: > >> I have moved on to other stuff for now. Haven't been able to make time > >> to review bridge related work. Andrzej has been doing it by himself > >> for a while now. > >> > >> Cc: Andrzej Hajda > >> Cc: Laurent Pinchart > >> Cc: Gustavo Padovan > >> Cc: Maarten Lankhorst > >> Cc: Sean Paul > >> Cc: Daniel Vetter > >> Signed-off-by: Archit Taneja > > > > Sorry to see you taking a less active role, Archit. Hopefully you'll stick > > around on IRC and find some cycles for us in the future! > > > > Acked-by: Sean Paul > > No one seems to have pushed this ... Where did the magic go wrong ? :-) > Also might be good to find another bridge maintainer? Totally agreed. > >> --- > >> > >> MAINTAINERS | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index 9d9068ed4ee5..7ed01e227684 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -4793,7 +4793,6 @@ F: > >> Documentation/devicetree/bindings/display/atmel/> > > >> T: git git://anongit.freedesktop.org/drm/drm-misc > >> > >> DRM DRIVERS FOR BRIDGE CHIPS > >> -M: Archit Taneja > >> M: Andrzej Hajda > >> R: Laurent Pinchart > >> S: Maintained -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
On Tue, Dec 18, 2018 at 01:53:34AM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
> Tested-by: Heiko Stuebner
> Acked-by: Heiko Stuebner
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19 ++-
> 1 file changed, 2 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index a8db758..8279084 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -221,26 +221,11 @@ static int rockchip_drm_gem_object_mmap_iommu(struct
> drm_gem_object *obj,
> struct vm_area_struct *vma)
> {
> struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
> - unsigned int i, count = obj->size >> PAGE_SHIFT;
> unsigned long user_count = vma_pages(vma);
> - unsigned long uaddr = vma->vm_start;
> unsigned long offset = vma->vm_pgoff;
> - unsigned long end = user_count + offset;
> - int ret;
> -
> - if (user_count == 0)
> - return -ENXIO;
> - if (end > count)
> - return -ENXIO;
>
> - for (i = offset; i < end; i++) {
> - ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
> - if (ret)
> - return ret;
> - uaddr += PAGE_SIZE;
> - }
> -
> - return 0;
> + return vm_insert_range(vma, vma->vm_start, rk_obj->pages + offset,
> + user_count - offset);
This looks like a change in behaviour.
If user_count is zero, and offset is zero, then we pass into
vm_insert_range() a page_count of zero, and vm_insert_range() does
nothing and returns zero.
However, as we can see from the above code, the original behaviour
was to return -ENXIO in that case.
The other thing that I'm wondering is that if (eg) count is 8 (the
object is 8 pages), offset is 2, and the user requests mapping 6
pages (user_count = 6), then we call vm_insert_range() with a
pages of rk_obj->pages + 2, and a pages_count of 6 - 2 = 4. So we
end up inserting four pages.
The original code would calculate end = 6 + 2 = 8. i would iterate
from 2 through 8, inserting six pages.
(I hadn't spotted that second issue until I'd gone through the
calculations manually - which is worrying.)
I don't have patches 5 through 9 to look at, but I'm concerned that
similar issues also exist in those patches.
I'm concerned that this series seems to be introducing subtle bugs,
it seems to be unnecessarily difficult to use this function correctly.
I think your existing proposal for vm_insert_range() provides an
interface that is way too easy to get wrong, and, therefore, is the
wrong interface.
I think it would be way better to have vm_insert_range() take the
object page array without any offset adjustment, and the object
page_count again without any adjustment, and have vm_insert_range()
itself handle the offsetting and VMA size validation. That would
then give a simple interface and probably give a further reduction
in code at each call site.
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/i915: Move to new PM core fields
On Mon, Dec 17, 2018 at 3:22 PM Vincent Guittot
wrote:
>
> On Fri, 14 Dec 2018 at 15:36, Ulf Hansson wrote:
> >
> > On Fri, 14 Dec 2018 at 15:22, Vincent Guittot
> > wrote:
> > >
> > > With jiffies been replaced by raw ns in PM core accounting, 915 driver is
> > > updated to use this new time infrastructure.
> > >
> > > Signed-off-by: Vincent Guittot
> > > ---
> > > drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
> > > drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
> > > 2 files changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > index d6c8f8f..cf6437d 100644
> > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > @@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private *i915)
> > > */
> > > if (kdev->power.runtime_status == RPM_SUSPENDED) {
> > > if
> > > (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> > > - i915->pmu.suspended_jiffies_last =
> > > -
> > > kdev->power.suspended_jiffies;
> > > + i915->pmu.suspended_time_last =
> > > + kdev->power.suspended_time;
> > >
> >
> > Huh, so patch 2 introduces a complier error because of removing the
> > old fields. We can't have that.
>
> I agree
> The patch was mainly to raise discussion
OK, so patch [1/3] from this series should be applicable regardless, right?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/i915: Move to new PM core fields
On Tue, 18 Dec 2018 at 10:57, Rafael J. Wysocki wrote:
>
> On Mon, Dec 17, 2018 at 3:22 PM Vincent Guittot
> wrote:
> >
> > On Fri, 14 Dec 2018 at 15:36, Ulf Hansson wrote:
> > >
> > > On Fri, 14 Dec 2018 at 15:22, Vincent Guittot
> > > wrote:
> > > >
> > > > With jiffies been replaced by raw ns in PM core accounting, 915 driver
> > > > is
> > > > updated to use this new time infrastructure.
> > > >
> > > > Signed-off-by: Vincent Guittot
> > > > ---
> > > > drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
> > > > drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
> > > > 2 files changed, 8 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > > index d6c8f8f..cf6437d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > > @@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private *i915)
> > > > */
> > > > if (kdev->power.runtime_status == RPM_SUSPENDED) {
> > > > if
> > > > (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> > > > - i915->pmu.suspended_jiffies_last =
> > > > -
> > > > kdev->power.suspended_jiffies;
> > > > + i915->pmu.suspended_time_last =
> > > > + kdev->power.suspended_time;
> > > >
> > >
> > > Huh, so patch 2 introduces a complier error because of removing the
> > > old fields. We can't have that.
> >
> > I agree
> > The patch was mainly to raise discussion
>
> OK, so patch [1/3] from this series should be applicable regardless, right?
Yes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/i915: Move to new PM core fields
On Tue, 18 Dec 2018 at 11:03, Rafael J. Wysocki wrote:
>
> On Tue, Dec 18, 2018 at 10:58 AM Vincent Guittot
> wrote:
> >
> > On Tue, 18 Dec 2018 at 10:57, Rafael J. Wysocki wrote:
> > >
> > > On Mon, Dec 17, 2018 at 3:22 PM Vincent Guittot
> > > wrote:
> > > >
> > > > On Fri, 14 Dec 2018 at 15:36, Ulf Hansson
> > > > wrote:
> > > > >
> > > > > On Fri, 14 Dec 2018 at 15:22, Vincent Guittot
> > > > > wrote:
> > > > > >
> > > > > > With jiffies been replaced by raw ns in PM core accounting, 915
> > > > > > driver is
> > > > > > updated to use this new time infrastructure.
> > > > > >
> > > > > > Signed-off-by: Vincent Guittot
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
> > > > > > drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
> > > > > > 2 files changed, 8 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > > > > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > > > > index d6c8f8f..cf6437d 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > > > > @@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private
> > > > > > *i915)
> > > > > > */
> > > > > > if (kdev->power.runtime_status == RPM_SUSPENDED) {
> > > > > > if
> > > > > > (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> > > > > > - i915->pmu.suspended_jiffies_last =
> > > > > > -
> > > > > > kdev->power.suspended_jiffies;
> > > > > > + i915->pmu.suspended_time_last =
> > > > > > + kdev->power.suspended_time;
> > > > > >
> > > > >
> > > > > Huh, so patch 2 introduces a complier error because of removing the
> > > > > old fields. We can't have that.
> > > >
> > > > I agree
> > > > The patch was mainly to raise discussion
> > >
> > > OK, so patch [1/3] from this series should be applicable regardless,
> > > right?
> >
> > Yes
>
> OK, I'll queue it up, then.
Thanks
>
> Next time you do something like that please mark patches for
> discussion in a series as [RFC] so it is all clear.
ok. will do for the next version of the last 2 patches
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109085] Radeon driver crashes with a message "ring 0 stalled for more than 10344msec" when using Citra and others
https://bugs.freedesktop.org/show_bug.cgi?id=109085 Bug ID: 109085 Summary: Radeon driver crashes with a message "ring 0 stalled for more than 10344msec" when using Citra and others Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: kaszak...@gmail.com Created attachment 142845 --> https://bugs.freedesktop.org/attachment.cgi?id=142845=edit dmesg output Overview: Radeon driver crashes and completely corrupts the screen during an attempt to use Citra emulator (always right after loading a game), and sometimes randomly during other GPU-demanding tasks, like using hardware video decoding through VDPAU. Strangely, the X server itself doesn't crash, and i can still see and move the mouse cursor, although heavily corrupted. Attached dmesg from the time of the crash. Steps to Reproduce: Open Citra, try to load any game. Actual Results: The driver crashes, resulting in screen corruption. Expected Results: Citra running the game or failing safely without crashing the driver. Software versions: Linux 4.19.9 Mesa 18.3.1 Xorg 1.20.3 xf86-video-ati 18.1.0 lspci output for the GPU: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v] (prog-if 00 [VGA controller]) Subsystem: Dell Mobility Radeon HD 4570 / 545v Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: radeon Kernel modules: radeon 00: 02 10 53 95 07 05 10 00 00 00 00 03 10 00 80 00 10: 08 00 00 d0 01 20 00 00 00 00 00 fc 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 be 02 30: 00 00 00 00 50 00 00 00 00 00 00 00 05 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 be 02 50: 01 58 03 06 00 00 00 00 10 a0 12 00 a0 8f 2c 01 60: 10 09 0a 00 01 0d 04 00 43 00 01 11 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 05 00 81 00 04 20 e0 fe 00 00 00 00 23 40 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Additional Information: possibly related bugs: https://bugs.freedesktop.org/show_bug.cgi?id=102909 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
On Tue, Dec 18, 2018 at 05:36:04PM +0530, Souptick Joarder wrote: > On Tue, Dec 18, 2018 at 3:27 PM Russell King - ARM Linux > wrote: > > This looks like a change in behaviour. > > > > If user_count is zero, and offset is zero, then we pass into > > vm_insert_range() a page_count of zero, and vm_insert_range() does > > nothing and returns zero. > > > > However, as we can see from the above code, the original behaviour > > was to return -ENXIO in that case. > > I think these checks are not necessary. I am not sure if we get into mmap > handlers of driver with user_count = 0. I'm not sure either, I'm just pointing out the change of behaviour. > > The other thing that I'm wondering is that if (eg) count is 8 (the > > object is 8 pages), offset is 2, and the user requests mapping 6 > > pages (user_count = 6), then we call vm_insert_range() with a > > pages of rk_obj->pages + 2, and a pages_count of 6 - 2 = 4. So we > > end up inserting four pages. > > Considering the scenario, user_count will remain 8 (user_count = > vma_pages(vma) ). ? No ? > Then we call vm_insert_range() with a pages of rk_obj->pages + 2, and > a pages_count > of 8 - 2 = 6. So we end up inserting 6 pages. > > Please correct me if I am wrong. vma_pages(vma) is the number of pages that the user requested, it is the difference between vma->vm_end and vma->vm_start in pages. As I said above, "the user requests mapping 6 pages", so vma_pages() will be 6, and so user_count will also be 6. You are passing user_count - offset into vm_insert_range(), which will be 6 - 2 = 4 in my example. This is two pages short of what the user requested. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [maintainer-tools PATCH v2 0/4] dim: fix git directory evaluation
On Tue, Dec 18, 2018 at 11:30:12AM +0100, Andrzej Hajda wrote: > Hi all, > > This small patchset fixes issues with dim and git worktree's. > In v2 I have: > - removed incorrect rr_cache_dir fix patch, > - added patch fixing update_rerere_cache, > - added patch converting git_dir function to use git rev_parse, > - added R-Bs (thanks Daniel). Entire series applied, thanks for your patches. -Daniel > > Regards > Andrzej > > > Andrzej Hajda (4): > dim: allow git_dir to specify arbitrary work directory > dim: fix git directory handling > dim: fix update_rerere_cache > dim: use git rev-parse to get git directory > > dim | 44 +--- > 1 file changed, 17 insertions(+), 27 deletions(-) > > -- > 2.17.1 > > ___ > dim-tools mailing list > dim-to...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dim-tools -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] amdgpu/dc: remove various variables that are defined but never used
From: Colin Ian King
There are several variables that are defined and never used and hence can
be removed. Remove them. Cleans up clang -Wunused-const-variable warnings:
warning: ‘dvi_hdmi_dongle_signature_str’ defined but not used
warning: ‘dce11_one_lpt_channel_max_resolution’ defined but not used
warning: ‘ddc_hw_status_addr’ defined but not used
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 1 -
.../gpu/drm/amd/display/dc/dce110/dce110_compressor.c | 2 --
.../amd/display/dc/i2caux/dce80/i2c_sw_engine_dce80.c | 10 --
3 files changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index 506a97e16956..99a314b79850 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -42,7 +42,6 @@
#define CV_SMART_DONGLE_ADDRESS 0x20
/* DVI-HDMI dongle slave address for retrieving dongle signature*/
#define DVI_HDMI_DONGLE_ADDRESS 0x68
-static const int8_t dvi_hdmi_dongle_signature_str[] = "6140063500G";
struct dvi_hdmi_dongle_signature_data {
int8_t vendor[3];/* "AMD" */
uint8_t version[2];
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_compressor.c
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_compressor.c
index 52d50e24a995..7b23239d33fe 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_compressor.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_compressor.c
@@ -62,8 +62,6 @@ static const struct dce110_compressor_reg_offsets
reg_offsets[] = {
}
};
-static const uint32_t dce11_one_lpt_channel_max_resolution = 2560 * 1600;
-
static uint32_t align_to_chunks_number_per_line(uint32_t pixels)
{
return 256 * ((pixels + 255) / 256);
diff --git a/drivers/gpu/drm/amd/display/dc/i2caux/dce80/i2c_sw_engine_dce80.c
b/drivers/gpu/drm/amd/display/dc/i2caux/dce80/i2c_sw_engine_dce80.c
index 4853ee26096a..c9d6cf08e8ab 100644
--- a/drivers/gpu/drm/amd/display/dc/i2caux/dce80/i2c_sw_engine_dce80.c
+++ b/drivers/gpu/drm/amd/display/dc/i2caux/dce80/i2c_sw_engine_dce80.c
@@ -50,16 +50,6 @@
* This unit
*/
-static const uint32_t ddc_hw_status_addr[] = {
- mmDC_I2C_DDC1_HW_STATUS,
- mmDC_I2C_DDC2_HW_STATUS,
- mmDC_I2C_DDC3_HW_STATUS,
- mmDC_I2C_DDC4_HW_STATUS,
- mmDC_I2C_DDC5_HW_STATUS,
- mmDC_I2C_DDC6_HW_STATUS,
- mmDC_I2C_DDCVGA_HW_STATUS
-};
-
/*
* @brief
* Cast 'struct i2c_sw_engine *'
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v1] drm/msm/dpu: Cleanup dpu plane interface
Remove unused functions from dpu plane interface
and unused variables from dpu plane state structure.
Signed-off-by: Jayant Shekhar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 27 ---
1 file changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
index 7fed0b6..0e6063a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -28,23 +28,18 @@
/**
* struct dpu_plane_state: Define dpu extension of drm plane state object
* @base: base drm plane state object
- * @property_state: Local storage for msm_prop properties
- * @property_values: cached plane property values
* @aspace:pointer to address space for input/output buffers
- * @input_fence: dereferenced input fence pointer
* @stage: assigned by crtc blender
* @multirect_index: index of the rectangle of SSPP
* @multirect_mode: parallel or time multiplex multirect mode
* @pending: whether the current update is still pending
* @scaler3_cfg: configuration data for scaler3
* @pixel_ext: configuration data for pixel extensions
- * @scaler_check_state: indicates status of user provided pixel extension data
* @cdp_cfg: CDP configuration
*/
struct dpu_plane_state {
struct drm_plane_state base;
struct msm_gem_address_space *aspace;
- void *input_fence;
enum dpu_stage stage;
uint32_t multirect_index;
uint32_t multirect_mode;
@@ -107,12 +102,6 @@ void dpu_plane_get_ctl_flush(struct drm_plane *plane,
struct dpu_hw_ctl *ctl,
void dpu_plane_flush(struct drm_plane *plane);
/**
- * dpu_plane_kickoff - final plane operations before commit kickoff
- * @plane: Pointer to drm plane structure
- */
-void dpu_plane_kickoff(struct drm_plane *plane);
-
-/**
* dpu_plane_set_error: enable/disable error condition
* @plane: pointer to drm_plane structure
*/
@@ -147,14 +136,6 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
void dpu_plane_clear_multirect(const struct drm_plane_state *drm_state);
/**
- * dpu_plane_wait_input_fence - wait for input fence object
- * @plane: Pointer to DRM plane object
- * @wait_ms: Wait timeout value
- * Returns: Zero on success
- */
-int dpu_plane_wait_input_fence(struct drm_plane *plane, uint32_t wait_ms);
-
-/**
* dpu_plane_color_fill - enables color fill on plane
* @plane: Pointer to DRM plane object
* @color: RGB fill color value, [23..16] Blue, [15..8] Green, [7..0] Red
@@ -164,12 +145,4 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
int dpu_plane_color_fill(struct drm_plane *plane,
uint32_t color, uint32_t alpha);
-/**
- * dpu_plane_set_revalidate - sets revalidate flag which forces a full
- * validation of the plane properties in the next atomic check
- * @plane: Pointer to DRM plane object
- * @enable: Boolean to set/unset the flag
- */
-void dpu_plane_set_revalidate(struct drm_plane *plane, bool enable);
-
#endif /* _DPU_PLANE_H_ */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202019] New: amdgpu: fan speed reported incorrectly when the fan is off
https://bugzilla.kernel.org/show_bug.cgi?id=202019 Bug ID: 202019 Summary: amdgpu: fan speed reported incorrectly when the fan is off Product: Drivers Version: 2.5 Kernel Version: 4.20-rc7 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: mezin.alexan...@gmail.com Regression: No I have a card with semi-passive cooling (Sapphire RX Vega 64 Nitro+) When the fan turns off, non-zero speed is still reported through hwmon fan1_input. If I'm not mistaken, the same problem was present with my previous card - Sapphire RX 580 Pulse (so I guess it's the same for all cards). On Windows zero rpm was correctly reported for both cards, of course. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109085] Radeon driver crashes with a message "ring 0 stalled for more than 10344msec" when using Citra and others
https://bugs.freedesktop.org/show_bug.cgi?id=109085 --- Comment #1 from Łukasz Skocz --- Created attachment 142846 --> https://bugs.freedesktop.org/attachment.cgi?id=142846=edit another dmesg output -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202019] amdgpu: fan speed reported incorrectly when the fan is off
https://bugzilla.kernel.org/show_bug.cgi?id=202019 Felix Schwarz (felix.schw...@oss.schwarz.eu) changed: What|Removed |Added CC||felix.schwarz@oss.schwarz.e ||u --- Comment #1 from Felix Schwarz (felix.schw...@oss.schwarz.eu) --- Probably a silly question but still: Did you confirm (visually) that the fans are actually turned off? AFAIK on Windows there is extra software running which turns of the fans when the GPU temperature is below a certain threshold. IIRC you need third-party scripts to achieve the same. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
Hi Neil,
On 30.11.2018 14:42, Neil Armstrong wrote:
> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
> Scrambling when supported or mandatory.
>
> This patch also adds an helper to setup the control bit to support
> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with
> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
>
> These changes were based on work done by Huicong Xu
> and Nickey Yang to support HDMI2.0 modes
> on the Rockchip 4.4 BSP kernel at [1]
>
> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4
>
> Cc: Nickey Yang
> Cc: Huicong Xu
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 88 ++-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 +
> include/drm/bridge/dw_hdmi.h | 1 +
> 3 files changed, 87 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 64c3cf027518..fcd941d52753 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -43,6 +44,11 @@
>
> #define HDMI_EDID_LEN512
>
> +/* DW-HDMI Controller >= 0x200a are at least compliant with SCDC version 1 */
> +#define SCDC_MIN_SOURCE_VERSION 0x1
> +
> +#define HDMI14_MAX_TMDSCLK 34000
> +
> enum hdmi_datamap {
> RGB444_8B = 0x01,
> RGB444_10B = 0x03,
> @@ -1015,6 +1021,33 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
> unsigned short data,
> }
> EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>
> +/*
> + * HDMI2.0 Specifies the following procedure for High TMDS Bit Rates:
> + * - The Source shall suspend transmission of the TMDS clock and data
> + * - The Source shall write to the TMDS_Bit_Clock_Ratio bit to change it
> + * from a 0 to a 1 or from a 1 to a 0
> + * - The Source shall allow a minimum of 1 ms and a maximum of 100 ms from
> + * the time the TMDS_Bit_Clock_Ratio bit is written until resuming
> + * transmission of TMDS clock and data
> + *
> + * To respect the 100ms maximum delay, the
> dw_hdmi_set_high_tmds_clock_ratio()
> + * helper should called right before enabling the TMDS Clock and Data in
> + * the PHY configuration callback.
> + */
> +void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi)
> +{
> + unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mpixelclock;
> +
> + /* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
> + if (hdmi->connector.display_info.hdmi.scdc.supported) {
> + if (mtmdsclock > HDMI14_MAX_TMDSCLK)
> + drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
> + else
> + drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0);
> + }
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
> +
> static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
> {
> hdmi_mask_writeb(hdmi, !enable, HDMI_PHY_CONF0,
> @@ -1216,6 +1249,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>
> dw_hdmi_phy_power_off(hdmi);
>
> + dw_hdmi_set_high_tmds_clock_ratio(hdmi);
> +
> /* Leave low power consumption mode by asserting SVSRET. */
> if (phy->has_svsret)
> dw_hdmi_phy_enable_svsret(hdmi, 1);
> @@ -1237,6 +1272,10 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
> return ret;
> }
>
> + /* Wait for resuming transmission of TMDS clock and data */
> + if (mpixelclock > HDMI14_MAX_TMDSCLK)
> + msleep(100);
> +
> return dw_hdmi_phy_power_on(hdmi);
> }
>
> @@ -1340,11 +1379,12 @@ static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
>
> static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode
> *mode)
> {
> + bool is_hdmi2_sink = hdmi->connector.display_info.hdmi.scdc.supported;
> struct hdmi_avi_infoframe frame;
> u8 val;
>
> /* Initialise info frame from DRM mode */
> - drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> + drm_hdmi_avi_infoframe_from_display_mode(, mode, is_hdmi2_sink);
>
> if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
> frame.colorspace = HDMI_COLORSPACE_YUV444;
> @@ -1503,7 +1543,8 @@ static void
> hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
> static void hdmi_av_composer(struct dw_hdmi *hdmi,
>const struct drm_display_mode *mode)
> {
> - u8 inv_val;
> + u8 inv_val, bytes;
> + struct drm_hdmi_info *hdmi_info = >connector.display_info.hdmi;
> struct hdmi_vmode *vmode = >hdmi_data.video_mode;
> int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
> unsigned int vdisplay;
> @@ -1513,7 +1554,9 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
> dev_dbg(hdmi->dev, "final pixclk = %d\n",
Re: [PATCH] MAINTAINERS: drm: Remove myself as drm-bridge maintainer
On 18.12.2018 10:53, Laurent Pinchart wrote: > Hi Daniel, > > On Tuesday, 18 December 2018 11:39:22 EET Daniel Vetter wrote: >> On Mon, Sep 17, 2018 at 5:49 PM Sean Paul wrote: >>> On Thu, Sep 13, 2018 at 01:23:00PM +0530, Archit Taneja wrote: I have moved on to other stuff for now. Haven't been able to make time to review bridge related work. Andrzej has been doing it by himself for a while now. Cc: Andrzej Hajda Cc: Laurent Pinchart Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: Daniel Vetter Signed-off-by: Archit Taneja >>> Sorry to see you taking a less active role, Archit. Hopefully you'll stick >>> around on IRC and find some cycles for us in the future! >>> >>> Acked-by: Sean Paul >> No one seems to have pushed this ... > Where did the magic go wrong ? :-) Fixed, ie queued to drm-misc-next. > >> Also might be good to find another bridge maintainer? > Totally agreed. Also agreed. Regards Andrzej > --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9d9068ed4ee5..7ed01e227684 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4793,7 +4793,6 @@ F: Documentation/devicetree/bindings/display/atmel/> > T: git git://anongit.freedesktop.org/drm/drm-misc DRM DRIVERS FOR BRIDGE CHIPS -M: Archit Taneja M: Andrzej Hajda R: Laurent Pinchart S: Maintained ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102909] radeon 0000:03:00.0: ring 0 stalled for more than 10000msec
https://bugs.freedesktop.org/show_bug.cgi?id=102909 Łukasz Skocz changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=109085 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109085] Radeon driver crashes with a message "ring 0 stalled for more than 10344msec" when using Citra and others
https://bugs.freedesktop.org/show_bug.cgi?id=109085 Łukasz Skocz changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=102909 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 2/8] drm/meson: add HDMI div40 TMDS mode
On 30.11.2018 14:42, Neil Armstrong wrote:
> Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 24
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 807111ebfdd9..b8775102b100 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -365,7 +365,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
> *data,
> unsigned int wr_clk =
> readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
>
> - DRM_DEBUG_DRIVER("%d:\"%s\"\n", mode->base.id, mode->name);
> + DRM_DEBUG_DRIVER("%d:\"%s\" div%d\n", mode->base.id, mode->name,
> + mode->clock > 34 ? 40 : 10);
>
> /* Enable clocks */
> regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
> @@ -385,9 +386,17 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
> *data,
> /* Enable normal output to PHY */
> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
>
> - /* TMDS pattern setup (TOFIX pattern for 4k2k scrambling) */
> - dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0x001f001f);
> - dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23, 0x001f001f);
> + /* TMDS pattern setup (TOFIX Handle the YUV420 case) */
> + if (mode->clock > 34) {
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0);
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
> + 0x03ff03ff);
> + } else {
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01,
> + 0x001f001f);
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
> + 0x001f001f);
> + }
>
> /* Load TMDS pattern */
> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_CNTL, 0x1);
> @@ -413,6 +422,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
> *data,
> /* Disable clock, fifo, fifo_wr */
> regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1, 0xf, 0);
>
> + dw_hdmi_set_high_tmds_clock_ratio(hdmi);
> +
> msleep(100);
>
> /* Reset PHY 3 times in a row */
> @@ -562,6 +573,11 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
> mode->vdisplay, mode->vsync_start,
> mode->vsync_end, mode->vtotal, mode->type, mode->flags);
>
> + /* If sink max TMDS clock < 340MHz, we reject the HDMI2.0 modes */
> + if (mode->clock > 34 &&
> + connector->display_info.max_tmds_clock < 34)
> + return MODE_BAD;
> +
Why not just:
if (mode->clock > connector->display_info.max_tmds_clock)
return MODE_BAD;
Regards
Andrzej
> /* Check against non-VIC supported modes */
> if (!vic) {
> status = meson_venc_hdmi_supported_mode(mode);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 3/8] drm/meson: add support for HDMI2.0 2160p modes
On 30.11.2018 14:42, Neil Armstrong wrote:
> Now we support the TMDS Clock > 3.4GHz and support the SCDC Control
> operation in the DW-HDMI Controller, we can enable support for the
> HDMI2.0 3840x2160@60/50 RGB444 display modes.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_venc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_venc.c
> b/drivers/gpu/drm/meson/meson_venc.c
> index 0ba04f6813e6..66d73a932d19 100644
> --- a/drivers/gpu/drm/meson/meson_venc.c
> +++ b/drivers/gpu/drm/meson/meson_venc.c
> @@ -848,6 +848,8 @@ struct meson_hdmi_venc_vic_mode {
> { 93, _hdmi_encp_mode_2160p24 },
> { 94, _hdmi_encp_mode_2160p25 },
> { 95, _hdmi_encp_mode_2160p30 },
> + { 96, _hdmi_encp_mode_2160p25 },
> + { 97, _hdmi_encp_mode_2160p30 },
> { 0, NULL}, /* sentinel */
> };
>
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
On Tue, Dec 18, 2018 at 06:24:29PM +0530, Souptick Joarder wrote: > On Tue, Dec 18, 2018 at 6:03 PM Russell King - ARM Linux > wrote: > > > > On Tue, Dec 18, 2018 at 05:36:04PM +0530, Souptick Joarder wrote: > > > On Tue, Dec 18, 2018 at 3:27 PM Russell King - ARM Linux > > > wrote: > > > > This looks like a change in behaviour. > > > > > > > > If user_count is zero, and offset is zero, then we pass into > > > > vm_insert_range() a page_count of zero, and vm_insert_range() does > > > > nothing and returns zero. > > > > > > > > However, as we can see from the above code, the original behaviour > > > > was to return -ENXIO in that case. > > > > > > I think these checks are not necessary. I am not sure if we get into mmap > > > handlers of driver with user_count = 0. > > > > I'm not sure either, I'm just pointing out the change of behaviour. > > Ok. I think feedback from Heiko might be helpful here :) > > > > > > > The other thing that I'm wondering is that if (eg) count is 8 (the > > > > object is 8 pages), offset is 2, and the user requests mapping 6 > > > > pages (user_count = 6), then we call vm_insert_range() with a > > > > pages of rk_obj->pages + 2, and a pages_count of 6 - 2 = 4. So we > > > > end up inserting four pages. > > > > > > Considering the scenario, user_count will remain 8 (user_count = > > > vma_pages(vma) ). ? No ? > > > Then we call vm_insert_range() with a pages of rk_obj->pages + 2, and > > > a pages_count > > > of 8 - 2 = 6. So we end up inserting 6 pages. > > > > > > Please correct me if I am wrong. > > > > vma_pages(vma) is the number of pages that the user requested, it is > > the difference between vma->vm_end and vma->vm_start in pages. As I > > said above, "the user requests mapping 6 pages", so vma_pages() will > > be 6, and so user_count will also be 6. You are passing > > user_count - offset into vm_insert_range(), which will be 6 - 2 = 4 > > in my example. This is two pages short of what the user requested. > > > > So, this should be the correct behavior. > > return vm_insert_range(vma, vma->vm_start, > rk_obj->pages + offset, > user_count); ... and by doing so, you're introducing another instance of the same bug I pointed out in patch 2. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
On 18/12/2018 13:25, Andrzej Hajda wrote:
> Hi Neil,
>
>
> On 30.11.2018 14:42, Neil Armstrong wrote:
>> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
>> Scrambling when supported or mandatory.
>>
>> This patch also adds an helper to setup the control bit to support
>> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with
>> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
>>
>> These changes were based on work done by Huicong Xu
>> and Nickey Yang to support HDMI2.0 modes
>> on the Rockchip 4.4 BSP kernel at [1]
>>
>> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4
>>
>> Cc: Nickey Yang
>> Cc: Huicong Xu
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 88 ++-
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 +
>> include/drm/bridge/dw_hdmi.h | 1 +
>> 3 files changed, 87 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 64c3cf027518..fcd941d52753 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -28,6 +28,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #include
>> @@ -43,6 +44,11 @@
>>
>> #define HDMI_EDID_LEN 512
>>
>> +/* DW-HDMI Controller >= 0x200a are at least compliant with SCDC version 1
>> */
>> +#define SCDC_MIN_SOURCE_VERSION 0x1
>> +
>> +#define HDMI14_MAX_TMDSCLK 34000
>> +
>> enum hdmi_datamap {
>> RGB444_8B = 0x01,
>> RGB444_10B = 0x03,
>> @@ -1015,6 +1021,33 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
>> unsigned short data,
>> }
>> EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>>
>> +/*
>> + * HDMI2.0 Specifies the following procedure for High TMDS Bit Rates:
>> + * - The Source shall suspend transmission of the TMDS clock and data
>> + * - The Source shall write to the TMDS_Bit_Clock_Ratio bit to change it
>> + * from a 0 to a 1 or from a 1 to a 0
>> + * - The Source shall allow a minimum of 1 ms and a maximum of 100 ms from
>> + * the time the TMDS_Bit_Clock_Ratio bit is written until resuming
>> + * transmission of TMDS clock and data
>> + *
>> + * To respect the 100ms maximum delay, the
>> dw_hdmi_set_high_tmds_clock_ratio()
>> + * helper should called right before enabling the TMDS Clock and Data in
>> + * the PHY configuration callback.
>> + */
>> +void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi)
>> +{
>> +unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mpixelclock;
>> +
>> +/* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
>> +if (hdmi->connector.display_info.hdmi.scdc.supported) {
>> +if (mtmdsclock > HDMI14_MAX_TMDSCLK)
>> +drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
>> +else
>> +drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0);
>> +}
>> +}
>> +EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
>> +
>> static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
>> {
>> hdmi_mask_writeb(hdmi, !enable, HDMI_PHY_CONF0,
>> @@ -1216,6 +1249,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>>
>> dw_hdmi_phy_power_off(hdmi);
>>
>> +dw_hdmi_set_high_tmds_clock_ratio(hdmi);
>> +
>> /* Leave low power consumption mode by asserting SVSRET. */
>> if (phy->has_svsret)
>> dw_hdmi_phy_enable_svsret(hdmi, 1);
>> @@ -1237,6 +1272,10 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>> return ret;
>> }
>>
>> +/* Wait for resuming transmission of TMDS clock and data */
>> +if (mpixelclock > HDMI14_MAX_TMDSCLK)
>> +msleep(100);
>> +
>> return dw_hdmi_phy_power_on(hdmi);
>> }
>>
>> @@ -1340,11 +1379,12 @@ static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
>>
>> static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode
>> *mode)
>> {
>> +bool is_hdmi2_sink = hdmi->connector.display_info.hdmi.scdc.supported;
>> struct hdmi_avi_infoframe frame;
>> u8 val;
>>
>> /* Initialise info frame from DRM mode */
>> -drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
>> +drm_hdmi_avi_infoframe_from_display_mode(, mode, is_hdmi2_sink);
>>
>> if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
>> frame.colorspace = HDMI_COLORSPACE_YUV444;
>> @@ -1503,7 +1543,8 @@ static void
>> hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
>> static void hdmi_av_composer(struct dw_hdmi *hdmi,
>> const struct drm_display_mode *mode)
>> {
>> -u8 inv_val;
>> +u8 inv_val, bytes;
>> +struct drm_hdmi_info *hdmi_info = >connector.display_info.hdmi;
>> struct hdmi_vmode *vmode = >hdmi_data.video_mode;
>> int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
>> unsigned
Re: [PATCH] MAINTAINERS: drm: Remove myself as drm-bridge maintainer
On Mon, Sep 17, 2018 at 5:49 PM Sean Paul wrote: > > On Thu, Sep 13, 2018 at 01:23:00PM +0530, Archit Taneja wrote: > > I have moved on to other stuff for now. Haven't been able to make time > > to review bridge related work. Andrzej has been doing it by himself > > for a while now. > > > > Cc: Andrzej Hajda > > Cc: Laurent Pinchart > > Cc: Gustavo Padovan > > Cc: Maarten Lankhorst > > Cc: Sean Paul > > Cc: Daniel Vetter > > Signed-off-by: Archit Taneja > > Sorry to see you taking a less active role, Archit. Hopefully you'll stick > around on IRC and find some cycles for us in the future! > > Acked-by: Sean Paul No one seems to have pushed this ... Also might be good to find another bridge maintainer? -Daniel > > > > > --- > > MAINTAINERS | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 9d9068ed4ee5..7ed01e227684 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4793,7 +4793,6 @@ F: > > Documentation/devicetree/bindings/display/atmel/ > > T: git git://anongit.freedesktop.org/drm/drm-misc > > > > DRM DRIVERS FOR BRIDGE CHIPS > > -M: Archit Taneja > > M: Andrzej Hajda > > R: Laurent Pinchart > > S: Maintained > > -- > > 2.18.0 > > > > -- > Sean Paul, Software Engineer, Google / Chromium OS -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][resend] drm: dw-hdmi-i2s: convert to SPDX identifiers
Hi Daniel, On Tuesday, 18 December 2018 11:37:14 EET Daniel Vetter wrote: > On Tue, Dec 18, 2018 at 7:47 AM Laurent Pinchart wrote: > > On Tuesday, 18 December 2018 08:00:24 EET Kuninori Morimoto wrote: > >> From: Kuninori Morimoto > >> > >> This patch updates license to use SPDX-License-Identifier > >> instead of verbose license text. > >> > >> Signed-off-by: Kuninori Morimoto > > > > Reviewed-by: Laurent Pinchart > > > >> --- > >> few weeks passed, nothing happen. I re-post this patch again. > >> I added Andrew on Cc > > > > The driver seems to be lacking a maintainer :-S > > bridge drivers all have a fallback maintainer, but none of them are > cc'ed. It's maintained in drm-misc, so you could just push the patch > too :-) Especially since you're listed: > > DRM DRIVERS FOR BRIDGE CHIPS > M:Archit Taneja > M:Andrzej Hajda > R:Laurent Pinchart Note the R, not the M :-) > S:Maintained > T:git git://anongit.freedesktop.org/drm/drm-misc > F:drivers/gpu/drm/bridge/ > > > Cheers, Daniel > > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 5 + > >> 1 file changed, 1 insertion(+), 4 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index > >> 8f9c8a6..2228689 100644 > >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > >> @@ -1,12 +1,9 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> /* > >> * dw-hdmi-i2s-audio.c > >> * > >> * Copyright (c) 2017 Renesas Solutions Corp. > >> * Kuninori Morimoto > >> - * > >> - * This program is free software; you can redistribute it and/or modify > >> - * it under the terms of the GNU General Public License version 2 as > >> - * published by the Free Software Foundation. > >> */ > >> > >> #include -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/i915: Move to new PM core fields
On Tue, Dec 18, 2018 at 10:58 AM Vincent Guittot
wrote:
>
> On Tue, 18 Dec 2018 at 10:57, Rafael J. Wysocki wrote:
> >
> > On Mon, Dec 17, 2018 at 3:22 PM Vincent Guittot
> > wrote:
> > >
> > > On Fri, 14 Dec 2018 at 15:36, Ulf Hansson wrote:
> > > >
> > > > On Fri, 14 Dec 2018 at 15:22, Vincent Guittot
> > > > wrote:
> > > > >
> > > > > With jiffies been replaced by raw ns in PM core accounting, 915
> > > > > driver is
> > > > > updated to use this new time infrastructure.
> > > > >
> > > > > Signed-off-by: Vincent Guittot
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
> > > > > drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
> > > > > 2 files changed, 8 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > > > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > > > index d6c8f8f..cf6437d 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > > > @@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private
> > > > > *i915)
> > > > > */
> > > > > if (kdev->power.runtime_status == RPM_SUSPENDED) {
> > > > > if
> > > > > (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> > > > > - i915->pmu.suspended_jiffies_last =
> > > > > -
> > > > > kdev->power.suspended_jiffies;
> > > > > + i915->pmu.suspended_time_last =
> > > > > + kdev->power.suspended_time;
> > > > >
> > > >
> > > > Huh, so patch 2 introduces a complier error because of removing the
> > > > old fields. We can't have that.
> > >
> > > I agree
> > > The patch was mainly to raise discussion
> >
> > OK, so patch [1/3] from this series should be applicable regardless, right?
>
> Yes
OK, I'll queue it up, then.
Next time you do something like that please mark patches for
discussion in a series as [RFC] so it is all clear.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[maintainer-tools PATCH v2 1/4] dim: allow git_dir to specify arbitrary work directory
git_dir function returns git directory for current working directory.
Allowing specifying any directory allows to reuse it more widely.
Signed-off-by: Andrzej Hajda
Reviewed-by: Daniel Vetter
---
dim | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/dim b/dim
index 70939ff..df66c58 100755
--- a/dim
+++ b/dim
@@ -565,10 +565,12 @@ function rr_cache_dir
function git_dir
{
- if [ -d $PWD/.git ] ; then
- echo $PWD/.git
+ local dir=${1:-$PWD}
+
+ if [ -d $dir/.git ] ; then
+ echo $dir/.git
else
- cut -d ' ' -f 2 < $PWD/.git
+ cut -d ' ' -f 2 < $dir/.git
fi
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[maintainer-tools PATCH v2 4/4] dim: use git rev-parse to get git directory
Using rev-parse git option is safer than manually parsing git files.
Signed-off-by: Andrzej Hajda
---
dim | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/dim b/dim
index e4a4afe..e999409 100755
--- a/dim
+++ b/dim
@@ -556,13 +556,7 @@ function check_conflicts # tree
function git_dir
{
- local dir=${1:-$PWD}
-
- if [ -d $dir/.git ] ; then
- echo $dir/.git
- else
- cut -d ' ' -f 2 < $dir/.git
- fi
+ git -C ${1:-$PWD} rev-parse --absolute-git-dir
}
function pull_rerere_cache
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[maintainer-tools PATCH v2 3/4] dim: fix update_rerere_cache
update_rerere_cache does not work correctly if drm-tip and $DIM_REPO are
workdirs - it cannot locate properly rr-cache. Let's use git rev-parse
to resolve rr-cache location.
Signed-off-by: Andrzej Hajda
---
dim | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/dim b/dim
index 3afa8b6..e4a4afe 100755
--- a/dim
+++ b/dim
@@ -554,15 +554,6 @@ function check_conflicts # tree
true
}
-function rr_cache_dir
-{
- if [ -d $DIM_PREFIX/drm-tip/.git/ ] ; then
- echo $DIM_PREFIX/drm-tip/.git/rr-cache
- else
- echo $DIM_PREFIX/$DIM_REPO/.git/rr-cache
- fi
-}
-
function git_dir
{
local dir=${1:-$PWD}
@@ -606,17 +597,25 @@ function pull_rerere_cache
function update_rerere_cache
{
+ local rr_cache_dir
+
echo -n "Updating rerere cache... "
pull_rerere_cache
- if [ ! -L $(rr_cache_dir) ] ; then
- if [ -d $(rr_cache_dir) ] ; then
- rm -Rf $(rr_cache_dir)
+ cd $DIM_PREFIX/drm-tip/
+
+ rr_cache_dir=$(git rev-parse --git-common-dir)/rr-cache
+
+ if [ ! -L $rr_cache_dir ] ; then
+ if [ -d $rr_cache_dir ] ; then
+ rm -Rf $rr_cache_dir
fi
- ln -s "$DIM_PREFIX/drm-rerere/rr-cache" $(dirname
$(rr_cache_dir))
+ ln -s "$DIM_PREFIX/drm-rerere/rr-cache" $rr_cache_dir
fi
+ cd ~-
+
echo "Done."
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Update crtc scaler settings when update_pipe is set
Op 17-12-2018 om 15:19 schreef Hans de Goede:
> When the pipe_config's update_pipe flag is set we may need to update the
> panel fitting settings. On GEN9+ this means we need to update the crtc's
> scaler settings.
>
> This fixes the following WARN_ON, during i915 loading on an Asrock
> B150M Pro4S/D3 board with an i5-6500 CPU / graphics:
>
> [drm:pipe_config_err [i915]] *ERROR* mismatch in pch_pfit.enabled
> (expected no, found yes)
> pipe state doesn't match!
> WARNING: CPU: 3 PID: 305 at drivers/gpu/drm/i915/intel_display.c:12084
>
> With line 12084 being the I915_STATE_WARN call inside the
> "if (!intel_pipe_config_compare())" block in verify_crtc_state().
>
> On this board with 2 1920x1080 monitors connected over HDMI the GOP
> initializes both monitors at 1920x1080 and despite no scaling being
> necessary configures a scaler for one of them.
>
> When booting with fastboot=1 on the initial modeset needs_modeset will
> be false while update_pipe is true. Since we were not calling
> skl_update_scaler_crtc() in this case we would leave the scaler enabled
> causing this error.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 62df34d30b1f..df32626e0810 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10919,7 +10919,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
> }
>
> if (INTEL_GEN(dev_priv) >= 9) {
> - if (mode_changed)
> + if (mode_changed || pipe_config->update_pipe)
> ret = skl_update_scaler_crtc(pipe_config);
>
> if (!ret)
Hey,
Pushed.
You might also be interested in this patch / series, would be nice to have a
review on it.
https://patchwork.freedesktop.org/patch/268410/
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202019] amdgpu: fan speed reported incorrectly when the fan is off
https://bugzilla.kernel.org/show_bug.cgi?id=202019 Aleksandr Mezin (mezin.alexan...@gmail.com) changed: What|Removed |Added Severity|normal |low --- Comment #3 from Aleksandr Mezin (mezin.alexan...@gmail.com) --- (In reply to Felix Schwarz from comment #1) > Probably a silly question but still: Did you confirm (visually) that the > fans are actually turned off? Yes > AFAIK on Windows there is extra software > running which turns of the fans when the GPU temperature is below a certain > threshold. IIRC you need third-party scripts to achieve the same. On Windows I have no additional software, only AMD driver (downloaded from amd.com, not modded by Sapphire or anything). Actually, I have my own script that controls fans on Linux (because there's no sysfs knobs to tweak the "automatic" fan curve), it just checks the temperature every second and writes desired fan speed to hwmon/pwm1. I tried to manually write '0' to pwm1 (with pwm1_enable set to '1') - exactly the same bug - fan1_input stops changing (when the fan is actually spinning, fan speed is always slightly changing, +/- few rpms), but doesn't show "0" (and, again, the fans are actually stopped) This problem occurs with both "pwm1_enable=2" and "pwm1_enable=1, pwm1=0" -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[maintainer-tools PATCH v2 2/4] dim: fix git directory handling
Assumption that git directory is always located at REPO/.git is incorrect,
especially in case of git worktrees. There is already function to deal
with it correctly - git_dir, let's then use it.
Signed-off-by: Andrzej Hajda
Reviewed-by: Daniel Vetter
---
dim | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/dim b/dim
index df66c58..3afa8b6 100755
--- a/dim
+++ b/dim
@@ -1088,12 +1088,7 @@ function dim_backmerge
git merge --rerere-autoupdate --no-commit $upstream >& /dev/null || true
- if [[ -d .git ]]; then
- patch_file=".git"
- else
- patch_file=$(cut -d ' ' -f 2 .git)
- fi
- patch_file=$patch_file/MERGE_MSG
+ patch_file=$(git_dir)/MERGE_MSG
cat > $patch_file <<-HERE
@@ -1340,7 +1335,7 @@ dim_alias_mrr=magic-rebase-resolve
function dim_magic_rebase_resolve
{
git diff HEAD | patch -p1 -R
- dim_magic_patch < .git/rebase-merge/patch
+ dim_magic_patch < $(git_dir)/rebase-merge/patch
make $DIM_MAKE_OPTIONS
git add -u
git rebase --continue
@@ -2102,7 +2097,7 @@ function setup_aux_checkout # name url directory
git clone --reference=$DIM_PREFIX/$DIM_REPO/.git $url
$dir
cd $dir
git config remote.origin.url $url
- echo "$DIM_PREFIX/$DIM_REPO/.git/objects" >
.git/objects/info/alternates
+ echo "$(git_dir $DIM_PREFIX/$DIM_REPO)/objects" >
$(git_dir)/objects/info/alternates
git repack -a -d -l
remote=origin
fi
@@ -2132,7 +2127,7 @@ function dim_setup
fi
cd $DIM_PREFIX
- if [ ! -d $DIM_PREFIX/$DIM_REPO/.git ]; then
+ if [ ! -d $(git_dir $DIM_PREFIX/$DIM_REPO) ]; then
echoerr "No git checkout found in $DIM_PREFIX/$DIM_REPO."
echoerr "Please set up your maintainer linux repository at
$DIM_PREFIX/$DIM_REPO with"
echoerr "cd $DIM_PREFIX"
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[maintainer-tools PATCH v2 0/4] dim: fix git directory evaluation
Hi all, This small patchset fixes issues with dim and git worktree's. In v2 I have: - removed incorrect rr_cache_dir fix patch, - added patch fixing update_rerere_cache, - added patch converting git_dir function to use git rev_parse, - added R-Bs (thanks Daniel). Regards Andrzej Andrzej Hajda (4): dim: allow git_dir to specify arbitrary work directory dim: fix git directory handling dim: fix update_rerere_cache dim: use git rev-parse to get git directory dim | 44 +--- 1 file changed, 17 insertions(+), 27 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v3] drm/msm/dpu: Clean up dpu hw interrupts
Remove unused functions and macros from files handling
dpu hardware interrupts.
changes in v2:
Removed clear_interrupt_status (Jordan Crouse)
changes in v3:
Changed commit text
Signed-off-by: Jayant Shekhar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 44 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 44 ---
2 files changed, 88 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index c0b7f00..8a28a03 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -170,10 +170,6 @@
/**
* AD4 interrupt status bit definitions
*/
-#define DPU_INTR_BRIGHTPR_UPDATED BIT(4)
-#define DPU_INTR_DARKENH_UPDATED BIT(3)
-#define DPU_INTR_STREN_OUTROI_UPDATED BIT(2)
-#define DPU_INTR_STREN_INROI_UPDATED BIT(1)
#define DPU_INTR_BACKLIGHT_UPDATED BIT(0)
/**
* struct dpu_intr_reg - array of DPU register sets
@@ -782,18 +778,6 @@ static int dpu_hw_intr_irqidx_lookup(enum dpu_intr_type
intr_type,
return -EINVAL;
}
-static void dpu_hw_intr_set_mask(struct dpu_hw_intr *intr, uint32_t reg_off,
- uint32_t mask)
-{
- if (!intr)
- return;
-
- DPU_REG_WRITE(>hw, reg_off, mask);
-
- /* ensure register writes go through */
- wmb();
-}
-
static void dpu_hw_intr_dispatch_irq(struct dpu_hw_intr *intr,
void (*cbfunc)(void *, int),
void *arg)
@@ -1004,18 +988,6 @@ static int dpu_hw_intr_disable_irqs(struct dpu_hw_intr
*intr)
return 0;
}
-static int dpu_hw_intr_get_valid_interrupts(struct dpu_hw_intr *intr,
- uint32_t *mask)
-{
- if (!intr || !mask)
- return -EINVAL;
-
- *mask = IRQ_SOURCE_MDP | IRQ_SOURCE_DSI0 | IRQ_SOURCE_DSI1
- | IRQ_SOURCE_HDMI | IRQ_SOURCE_EDP;
-
- return 0;
-}
-
static void dpu_hw_intr_get_interrupt_statuses(struct dpu_hw_intr *intr)
{
int i;
@@ -1065,19 +1037,6 @@ static void dpu_hw_intr_clear_intr_status_nolock(struct
dpu_hw_intr *intr,
wmb();
}
-static void dpu_hw_intr_clear_interrupt_status(struct dpu_hw_intr *intr,
- int irq_idx)
-{
- unsigned long irq_flags;
-
- if (!intr)
- return;
-
- spin_lock_irqsave(>irq_lock, irq_flags);
- dpu_hw_intr_clear_intr_status_nolock(intr, irq_idx);
- spin_unlock_irqrestore(>irq_lock, irq_flags);
-}
-
static u32 dpu_hw_intr_get_interrupt_status(struct dpu_hw_intr *intr,
int irq_idx, bool clear)
{
@@ -1113,16 +1072,13 @@ static u32 dpu_hw_intr_get_interrupt_status(struct
dpu_hw_intr *intr,
static void __setup_intr_ops(struct dpu_hw_intr_ops *ops)
{
- ops->set_mask = dpu_hw_intr_set_mask;
ops->irq_idx_lookup = dpu_hw_intr_irqidx_lookup;
ops->enable_irq = dpu_hw_intr_enable_irq;
ops->disable_irq = dpu_hw_intr_disable_irq;
ops->dispatch_irqs = dpu_hw_intr_dispatch_irq;
ops->clear_all_irqs = dpu_hw_intr_clear_irqs;
ops->disable_all_irqs = dpu_hw_intr_disable_irqs;
- ops->get_valid_interrupts = dpu_hw_intr_get_valid_interrupts;
ops->get_interrupt_statuses = dpu_hw_intr_get_interrupt_statuses;
- ops->clear_interrupt_status = dpu_hw_intr_clear_interrupt_status;
ops->clear_intr_status_nolock = dpu_hw_intr_clear_intr_status_nolock;
ops->get_interrupt_status = dpu_hw_intr_get_interrupt_status;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
index 61e4cba..4d7a1c7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
@@ -20,13 +20,6 @@
#include "dpu_hw_util.h"
#include "dpu_hw_mdss.h"
-#define IRQ_SOURCE_MDP BIT(0)
-#define IRQ_SOURCE_DSI0BIT(4)
-#define IRQ_SOURCE_DSI1BIT(5)
-#define IRQ_SOURCE_HDMIBIT(8)
-#define IRQ_SOURCE_EDP BIT(12)
-#define IRQ_SOURCE_MHL BIT(16)
-
/**
* dpu_intr_type - HW Interrupt Type
* @DPU_IRQ_TYPE_WB_ROT_COMP: WB rotator done
@@ -96,18 +89,6 @@ enum dpu_intr_type {
*/
struct dpu_hw_intr_ops {
/**
-* set_mask - Programs the given interrupt register with the
-*given interrupt mask. Register value will get overwritten.
-* @intr: HW interrupt handle
-* @reg_off:MDSS HW register offset
-* @irqmask:IRQ mask value
-*/
- void (*set_mask)(
- struct dpu_hw_intr *intr,
- uint32_t reg,
- uint32_t irqmask);
-
- /**
* irq_idx_lookup - Lookup IRQ index on the HW interrupt type
* Used for all irq related ops
* @intr_type: Interrupt type defined in dpu_intr_type
@@ -177,16 +158,6
Re: [PATCH] drm/i915: Disable -Wuninitialized for intel_breadcrumbs.o
Quoting Nick Desaulniers (2018-10-25 23:20:58)
> On Thu, Oct 25, 2018 at 12:36 PM Nathan Chancellor
> wrote:
> >
> > This warning is disabled by default in scripts/Makefile.extrawarn when
> > W= is not provided but this Makefile adds -Wall after this warning is
> > disabled so it shows up in the build when it shouldn't:
> >
> > In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
> > drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
> > variable 'wq' is uninitialized when used within its own initialization
> > [-Werror,-Wuninitialized]
> > DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> > ^~
> > ./include/linux/wait.h:74:63: note: expanded from macro
> > 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> > struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> > ^~~~
> > ./include/linux/wait.h:72:33: note: expanded from macro
> > '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> > ({ init_waitqueue_head(); name; })
> >^~~~
> > 1 error generated.
> >
> > This warning looks to be a false positive given that init_waitqueue_head
> > initializes name before it is used. Rather than disable the warning for
> > the full folder like commit 46e2068081e9 ("drm/i915: Disable some extra
>
> cc author/reviewer of 46e2068081e9.
>
> I'm fine with the patch as is, unless others prefer to disable it for
> the whole subdir? We could be playing whack-a-mole in the future
> disabling this warning for other translation units.
Yes, exactly this since the warning is generated by a core header and a
fairly common pattern its use is not restricted to any single file.
(Will not all selftests similarly explode?)
The other false-positive clang-6 gave was for local_clock_us().
Presumably that one is fixed?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202019] amdgpu: fan speed reported incorrectly when the fan is off
https://bugzilla.kernel.org/show_bug.cgi?id=202019 --- Comment #4 from Aleksandr Mezin (mezin.alexan...@gmail.com) --- (In reply to Felix Schwarz from comment #2) > Oh and probably AMD developers would like to know which kernel version you > are using. It's here, in "Kernel Version" field in bugzilla. 4.20-rc7 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 2/8] drm/meson: add HDMI div40 TMDS mode
On 18/12/2018 13:36, Andrzej Hajda wrote:
> On 30.11.2018 14:42, Neil Armstrong wrote:
>> Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_dw_hdmi.c | 24
>> 1 file changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> index 807111ebfdd9..b8775102b100 100644
>> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> @@ -365,7 +365,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
>> *data,
>> unsigned int wr_clk =
>> readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
>>
>> -DRM_DEBUG_DRIVER("%d:\"%s\"\n", mode->base.id, mode->name);
>> +DRM_DEBUG_DRIVER("%d:\"%s\" div%d\n", mode->base.id, mode->name,
>> + mode->clock > 34 ? 40 : 10);
>>
>> /* Enable clocks */
>> regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
>> @@ -385,9 +386,17 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
>> *data,
>> /* Enable normal output to PHY */
>> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
>>
>> -/* TMDS pattern setup (TOFIX pattern for 4k2k scrambling) */
>> -dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0x001f001f);
>> -dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23, 0x001f001f);
>> +/* TMDS pattern setup (TOFIX Handle the YUV420 case) */
>> +if (mode->clock > 34) {
>> +dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0);
>> +dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
>> + 0x03ff03ff);
>> +} else {
>> +dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01,
>> + 0x001f001f);
>> +dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
>> + 0x001f001f);
>> +}
>>
>> /* Load TMDS pattern */
>> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_CNTL, 0x1);
>> @@ -413,6 +422,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
>> *data,
>> /* Disable clock, fifo, fifo_wr */
>> regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1, 0xf, 0);
>>
>> +dw_hdmi_set_high_tmds_clock_ratio(hdmi);
>> +
>> msleep(100);
>>
>> /* Reset PHY 3 times in a row */
>> @@ -562,6 +573,11 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
>> mode->vdisplay, mode->vsync_start,
>> mode->vsync_end, mode->vtotal, mode->type, mode->flags);
>>
>> +/* If sink max TMDS clock < 340MHz, we reject the HDMI2.0 modes */
>> +if (mode->clock > 34 &&
>> +connector->display_info.max_tmds_clock < 34)
>> +return MODE_BAD;
>> +
>
>
> Why not just:
>
> if (mode->clock > connector->display_info.max_tmds_clock)
> return MODE_BAD;
Hmm, let me check, it may be better indeed.
Neil
>
>
> Regards
>
> Andrzej
>
>
>> /* Check against non-VIC supported modes */
>> if (!vic) {
>> status = meson_venc_hdmi_supported_mode(mode);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: make FB_BACKLIGHT a tristate
On Fri, Oct 26, 2018 at 10:09 AM Rob Clark wrote:
>
> BACKLIGHT_CLASS_DEVICE is already tristate, but a dependency
> FB_BACKLIGHT prevents it from being built as a module. There
> doesn't seem to be any particularly good reason for this, so
> switch FB_BACKLIGHT over to tristate.
>
> Signed-off-by: Rob Clark
> Tested-by: Arnd Bergmann
bump
maybe we can merge this via drm-misc?
BR,
-R
> ---
> v2: remove IS_ENABLED() from UABI headers. Userspace doesn't
> know the kernel config, so just remove the ifdef guard
>
> drivers/video/fbdev/Kconfig| 2 +-
> drivers/video/fbdev/core/fbsysfs.c | 8
> include/linux/fb.h | 2 +-
> include/uapi/linux/fb.h| 2 --
> 4 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 591a13a59787..146ab2c347f8 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -198,7 +198,7 @@ config FB_MACMODES
> default n
>
> config FB_BACKLIGHT
> - bool
> + tristate
> depends on FB
> select BACKLIGHT_LCD_SUPPORT
> select BACKLIGHT_CLASS_DEVICE
> diff --git a/drivers/video/fbdev/core/fbsysfs.c
> b/drivers/video/fbdev/core/fbsysfs.c
> index e31a182b42bf..44cca39f2b51 100644
> --- a/drivers/video/fbdev/core/fbsysfs.c
> +++ b/drivers/video/fbdev/core/fbsysfs.c
> @@ -60,7 +60,7 @@ struct fb_info *framebuffer_alloc(size_t size, struct
> device *dev)
> info->device = dev;
> info->fbcon_rotate_hint = -1;
>
> -#ifdef CONFIG_FB_BACKLIGHT
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> mutex_init(>bl_curve_mutex);
> #endif
>
> @@ -429,7 +429,7 @@ static ssize_t show_fbstate(struct device *device,
> return snprintf(buf, PAGE_SIZE, "%d\n", fb_info->state);
> }
>
> -#ifdef CONFIG_FB_BACKLIGHT
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> static ssize_t store_bl_curve(struct device *device,
> struct device_attribute *attr,
> const char *buf, size_t count)
> @@ -510,7 +510,7 @@ static struct device_attribute device_attrs[] = {
> __ATTR(stride, S_IRUGO, show_stride, NULL),
> __ATTR(rotate, S_IRUGO|S_IWUSR, show_rotate, store_rotate),
> __ATTR(state, S_IRUGO|S_IWUSR, show_fbstate, store_fbstate),
> -#ifdef CONFIG_FB_BACKLIGHT
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> __ATTR(bl_curve, S_IRUGO|S_IWUSR, show_bl_curve, store_bl_curve),
> #endif
> };
> @@ -551,7 +551,7 @@ void fb_cleanup_device(struct fb_info *fb_info)
> }
> }
>
> -#ifdef CONFIG_FB_BACKLIGHT
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> /* This function generates a linear backlight curve
> *
> * 0: off
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index a3cab6dc9b44..7cdd31a69719 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -485,7 +485,7 @@ struct fb_info {
> struct list_head modelist; /* mode list */
> struct fb_videomode *mode; /* current mode */
>
> -#ifdef CONFIG_FB_BACKLIGHT
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> /* assigned backlight device */
> /* set before framebuffer registration,
>remove after unregister */
> diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h
> index 6cd9b198b7c6..b6aac7ee1f67 100644
> --- a/include/uapi/linux/fb.h
> +++ b/include/uapi/linux/fb.h
> @@ -393,11 +393,9 @@ struct fb_cursor {
> struct fb_image image; /* Cursor image */
> };
>
> -#ifdef CONFIG_FB_BACKLIGHT
> /* Settings for the generic backlight code */
> #define FB_BACKLIGHT_LEVELS128
> #define FB_BACKLIGHT_MAX 0xFF
> -#endif
>
>
> #endif /* _UAPI_LINUX_FB_H */
> --
> 2.17.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] etnaviv-next for 4.21 revamp
Hi Daniel, Dave, updated pull request with Christian's review added below. Regards, Lucas The following changes since commit 6fce3a406108ee6c8a61e2a33e52e9198a626ea0: drm/etnaviv: fix bogus fence complete check in timeout handler (2018-11-05 18:14:48 +0100) are available in the Git repository at: https://git.pengutronix.de/git/lst/linux etnaviv/next for you to fetch changes up to 801c7a1e528623f073c4007cb04d9a817e33b3a4: drm/etnaviv: remove lastctx member from gpu struct (2018-12-18 11:55:16 +0100) Lucas Stach (5): drm/etnaviv: kill active fence tracking drm/etnaviv: consolidate hardware fence handling in etnaviv_gpu drm/etnaviv: remove unnecessary local irq disable drm/etnaviv: replace header include with forward declaration drm/etnaviv: remove lastctx member from gpu struct Thomas Zimmermann (1): drm/etnaviv: Replace drm_dev_unref with drm_dev_put drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 2 -- drivers/gpu/drm/etnaviv/etnaviv_drv.c| 16 +--- drivers/gpu/drm/etnaviv/etnaviv_drv.h| 11 --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 37 - drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 12 ++-- 5 files changed, 23 insertions(+), 55 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202019] amdgpu: fan speed reported incorrectly when the fan is off
https://bugzilla.kernel.org/show_bug.cgi?id=202019 --- Comment #2 from Felix Schwarz (felix.schw...@oss.schwarz.eu) --- Oh and probably AMD developers would like to know which kernel version you are using. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/gem: Mark pinned pages as unevictable
Quoting Kuo-Hsin Yang (2018-12-17 09:04:01) > The gem drivers use shmemfs to allocate backing storage for gem objects. > On Samsung Chromebook Plus, the drm/rockchip driver may call > rockchip_gem_get_pages -> drm_gem_get_pages -> shmem_read_mapping_page > to pin a lot of pages, breaking the page reclaim mechanism and causing > oom-killer invocation. > > E.g. when the size of a zone is 3.9 GiB, the inactive_ratio is 5. If > active_anon / inactive_anon < 5 and all pages in the inactive_anon lru > are pinned, page reclaim would keep scanning inactive_anon lru without > reclaiming memory. It breaks page reclaim when the rockchip driver only > pins about 1/6 of the anon lru pages. Right, we invalidate the "inactive anon list should be small enough that the VM never has to do too much work" assumption. > Mark these pinned pages as unevictable to avoid the premature oom-killer > invocation. See also similar patch on i915 driver [1]. > > [1]: > https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-ch...@chris-wilson.co.uk > > Signed-off-by: Kuo-Hsin Yang > Cc: Daniel Vetter > Cc: Chris Wilson Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 4/8] drm/bridge: dw-hdmi: add support for YUV420 output
On 30.11.2018 14:42, Neil Armstrong wrote: > In order to support the HDMI2.0 YUV420 display modes, this patch > adds support for the YUV420 TMDS Clock divided by 2 and the controller > passthrough mode. > > YUV420 Synopsys PHY support will need some specific configuration table > to support theses modes. > > This patch is based on work from Zheng Yang in > the Rockchip Linux 4.4 BSP at [1] > > [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 > > Cc: Zheng Yang > Signed-off-by: Neil Armstrong Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/i915: Validate userspace-provided color management LUT's (v3)
On Mon, Dec 17, 2018 at 02:44:15PM -0800, Matt Roper wrote:
> We currently program userspace-provided gamma and degamma LUT's into our
> hardware without really checking to see whether they satisfy our
> hardware's rules. We should try to catch tables that are invalid for
> our hardware early and reject the atomic transaction.
>
> All of our platforms that accept a degamma LUT expect that the entries
> in the LUT are always flat or increasing, never decreasing. Also, our
> GLK and ICL platforms only accept degamma tables with r=g=b entries; so
> we should also add the relevant checks for that in anticipation of
> degamma support landing for those platforms.
>
> v2:
> - Use new API (single check function with bitmask of tests to apply)
> - Call helper for our gamma table as well (with no additional tests
>specified) so that the table size will be validated.
>
> v3:
> - Don't call on the gamma table since the LUT size is already tested at
>property blob upload and we don't have any additional hardware
>constraints for that LUT.
>
> Cc: Uma Shankar
> Cc: Swati Sharma
> Signed-off-by: Matt Roper
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_color.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 37fd9ddf762e..bdbe474ad9b2 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -609,10 +609,26 @@ int intel_color_check(struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> size_t gamma_length, degamma_length;
> + uint32_t tests = DRM_COLOR_LUT_NON_DECREASING;
>
> degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>
> + /*
> + * All of our platforms mandate that the degamma curve be
> + * non-decreasing. Additionally, GLK and gen11 only accept a single
> + * value for red, green, and blue in the degamma table. Make sure
> + * userspace didn't try to pass us something we can't handle.
> + *
> + * We don't have any extra hardware constraints on the gamma table,
> + * so no need to explicitly check it.
> + */
> + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
> + tests |= DRM_COLOR_LUT_EQUAL_CHANNELS;
>= 10 ?
> +
> + if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
> + return -EINVAL;
> +
> /*
>* We allow both degamma & gamma luts at the right size or
>* NULL.
> --
> 2.14.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 1/3] PM/runtime: Add a new interface to get accounted time
Some drivers (like i915/drm) need to get the accounted suspended time.
pm_runtime_accounted_time_get() will return the suspended or active
accounted time until now.
Signed-off-by: Vincent Guittot
---
drivers/base/power/runtime.c | 26 ++
include/linux/pm_runtime.h | 2 ++
2 files changed, 28 insertions(+)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 7062469..6461469 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -88,6 +88,32 @@ static void __update_runtime_status(struct device *dev, enum
rpm_status status)
dev->power.runtime_status = status;
}
+u64 pm_runtime_accounted_time_get(struct device *dev, enum rpm_status status,
bool update)
+{
+ u64 now = ktime_to_ns(ktime_get());
+ u64 delta = 0, time = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(>power.lock, flags);
+
+ if (dev->power.disable_depth > 0)
+ goto unlock;
+
+ /* Add ongoing state if requested */
+ if (update && dev->power.runtime_status == status)
+ delta = now - dev->power.accounting_timestamp;
+
+ if (status == RPM_SUSPENDED)
+ time = dev->power.suspended_time + delta;
+ else
+ time = dev->power.active_time + delta;
+
+unlock:
+ spin_unlock_irqrestore(>power.lock, flags);
+
+ return time;
+}
+
/**
* pm_runtime_deactivate_timer - Deactivate given device's suspend timer.
* @dev: Device to handle.
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 54af4ee..86f21f9 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -113,6 +113,8 @@ static inline bool pm_runtime_is_irq_safe(struct device
*dev)
return dev->power.irq_safe;
}
+extern u64 pm_runtime_accounted_time_get(struct device *dev, enum rpm_status
status, bool update);
+
#else /* !CONFIG_PM */
static inline bool queue_pm_work(struct work_struct *work) { return false; }
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 2/3] drm/i915: Move on the new pm runtime interface
Use the new pm runtime interface to get the accounted suspended time:
pm_runtime_accounted_time_get()
Signed-off-by: Vincent Guittot
---
drivers/gpu/drm/i915/i915_pmu.c | 18 --
drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index d6c8f8f..ebc49ea 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include "i915_pmu.h"
#include "intel_ringbuffer.h"
#include "i915_drv.h"
@@ -478,7 +479,6 @@ static u64 get_rc6(struct drm_i915_private *i915)
* counter value.
*/
spin_lock_irqsave(>pmu.lock, flags);
- spin_lock(>power.lock);
/*
* After the above branch intel_runtime_pm_get_if_in_use failed
@@ -491,16 +491,15 @@ static u64 get_rc6(struct drm_i915_private *i915)
* suspended and if not we cannot do better than report the last
* known RC6 value.
*/
- if (kdev->power.runtime_status == RPM_SUSPENDED) {
+ val = pm_runtime_accounted_time_get(kdev, RPM_SUSPENDED, true);
+ if (pm_runtime_status_suspended(kdev)) {
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
- i915->pmu.suspended_jiffies_last =
- kdev->power.suspended_jiffies;
+ i915->pmu.suspended_time_last =
+ pm_runtime_accounted_time_get(kdev,
+
RPM_SUSPENDED,
+ false);
- val = kdev->power.suspended_jiffies -
- i915->pmu.suspended_jiffies_last;
- val += jiffies - kdev->power.accounting_timestamp;
-
- val = jiffies_to_nsecs(val);
+ val -= i915->pmu.suspended_time_last;
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
@@ -510,7 +509,6 @@ static u64 get_rc6(struct drm_i915_private *i915)
val = i915->pmu.sample[__I915_SAMPLE_RC6].cur;
}
- spin_unlock(>power.lock);
spin_unlock_irqrestore(>pmu.lock, flags);
}
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index 7f164ca..3dc2a30 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -95,9 +95,9 @@ struct i915_pmu {
*/
struct i915_pmu_sample sample[__I915_NUM_PMU_SAMPLERS];
/**
-* @suspended_jiffies_last: Cached suspend time from PM core.
+* @suspended_time_last: Cached suspend time from PM core.
*/
- unsigned long suspended_jiffies_last;
+ u64 suspended_time_last;
/**
* @i915_attr: Memory block holding device attributes.
*/
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting
From: Thara Gopinath
This patch replaces jiffies based accounting for runtime_active_time
and runtime_suspended_time with ktime base accounting. This makes the
runtime debug counters inline with genpd and other pm subsytems which
uses ktime based accounting.
Signed-off-by: Thara Gopinath
[move from ktime to raw nsec]
Signed-off-by: Vincent Guittot
---
drivers/base/power/runtime.c | 10 +-
drivers/base/power/sysfs.c | 11 ---
include/linux/pm.h | 6 +++---
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 6461469..5c18e28 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -66,8 +66,8 @@ static int rpm_suspend(struct device *dev, int rpmflags);
*/
void update_pm_runtime_accounting(struct device *dev)
{
- unsigned long now = jiffies;
- unsigned long delta;
+ u64 now = ktime_to_ns(ktime_get());
+ u64 delta;
delta = now - dev->power.accounting_timestamp;
@@ -77,9 +77,9 @@ void update_pm_runtime_accounting(struct device *dev)
return;
if (dev->power.runtime_status == RPM_SUSPENDED)
- dev->power.suspended_jiffies += delta;
+ dev->power.suspended_time += delta;
else
- dev->power.active_jiffies += delta;
+ dev->power.active_time += delta;
}
static void __update_runtime_status(struct device *dev, enum rpm_status status)
@@ -1517,7 +1517,7 @@ void pm_runtime_init(struct device *dev)
dev->power.request_pending = false;
dev->power.request = RPM_REQ_NONE;
dev->power.deferred_resume = false;
- dev->power.accounting_timestamp = jiffies;
+ dev->power.accounting_timestamp = ktime_to_ns(ktime_get());
INIT_WORK(>power.work, pm_runtime_work);
dev->power.timer_expires = 0;
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index d713738..96c8a22 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -125,9 +125,12 @@ static ssize_t runtime_active_time_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
int ret;
+ u64 tmp;
spin_lock_irq(>power.lock);
update_pm_runtime_accounting(dev);
- ret = sprintf(buf, "%i\n", jiffies_to_msecs(dev->power.active_jiffies));
+ tmp = dev->power.active_time;
+ do_div(tmp, NSEC_PER_MSEC);
+ ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(>power.lock);
return ret;
}
@@ -138,10 +141,12 @@ static ssize_t runtime_suspended_time_show(struct device
*dev,
struct device_attribute *attr, char *buf)
{
int ret;
+ u64 tmp;
spin_lock_irq(>power.lock);
update_pm_runtime_accounting(dev);
- ret = sprintf(buf, "%i\n",
- jiffies_to_msecs(dev->power.suspended_jiffies));
+ tmp = dev->power.suspended_time;
+ do_div(tmp, NSEC_PER_MSEC);
+ ret = sprintf(buf, "%llu\n", tmp);
spin_unlock_irq(>power.lock);
return ret;
}
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 0bd9de1..3d2cbf9 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -633,9 +633,9 @@ struct dev_pm_info {
int runtime_error;
int autosuspend_delay;
u64 last_busy;
- unsigned long active_jiffies;
- unsigned long suspended_jiffies;
- unsigned long accounting_timestamp;
+ u64 active_time;
+ u64 suspended_time;
+ u64 accounting_timestamp;
#endif
struct pm_subsys_data *subsys_data; /* Owned by the subsystem. */
void (*set_latency_tolerance)(struct device *, s32);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/3] Move pm_runtime accounted time to raw nsec
Move pm_runtime accounted time to raw nsec. The subject of the patchset has changed as the 1st patch has been queued by Rafael Patch 1 adds a new pm_runtime interface to get accounted suspended time Patch 2 moves drm/i915 driver on the new interface and removes access to internal fields Patch 3 moves time accounting on raw ns. This patch initially used ktime instead of raw ns but it was easier to move i915 driver on raw ns than on ktim Changes since v2: - remove patch1 that has been queued by rafael - add new interface in pm_runtime to get accounted time - reorder patchset to prevent compilation error Changes since v1: - updated commit message of patch 1 - Added patches 2 & 3 to move runtime_pm accounting on raw ns Thara Gopinath (1): PM/runtime:Replace jiffies based accounting with ktime based accounting Vincent Guittot (2): PM/runtime: Add a new interface to get accounted time drm/i915: Move on the new pm runtime interface drivers/base/power/runtime.c| 36 +++- drivers/base/power/sysfs.c | 11 --- drivers/gpu/drm/i915/i915_pmu.c | 18 -- drivers/gpu/drm/i915/i915_pmu.h | 4 ++-- include/linux/pm.h | 6 +++--- include/linux/pm_runtime.h | 2 ++ 6 files changed, 54 insertions(+), 23 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] etnaviv-next for 4.21 revamp
On Tue, Dec 18, 2018 at 12:00:45PM +0100, Lucas Stach wrote: > Hi Daniel, Dave, > > updated pull request with Christian's review added below. > > Regards, > Lucas Thanks, applied. tagged pull would be really nice, avoids me having to find v1 for the merge commit message. Cheers, Daniel > > The following changes since commit 6fce3a406108ee6c8a61e2a33e52e9198a626ea0: > > drm/etnaviv: fix bogus fence complete check in timeout handler (2018-11-05 > 18:14:48 +0100) > > are available in the Git repository at: > > https://git.pengutronix.de/git/lst/linux etnaviv/next > > for you to fetch changes up to 801c7a1e528623f073c4007cb04d9a817e33b3a4: > > drm/etnaviv: remove lastctx member from gpu struct (2018-12-18 11:55:16 > +0100) > > > Lucas Stach (5): > drm/etnaviv: kill active fence tracking > drm/etnaviv: consolidate hardware fence handling in etnaviv_gpu > drm/etnaviv: remove unnecessary local irq disable > drm/etnaviv: replace header include with forward declaration > drm/etnaviv: remove lastctx member from gpu struct > > Thomas Zimmermann (1): > drm/etnaviv: Replace drm_dev_unref with drm_dev_put > > drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 2 -- > drivers/gpu/drm/etnaviv/etnaviv_drv.c| 16 +--- > drivers/gpu/drm/etnaviv/etnaviv_drv.h| 11 --- > drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 37 > - > drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 12 ++-- > 5 files changed, 23 insertions(+), 55 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] drm: Complete remove drm_mode_object dependency
This patch finalizes the KMS cleanup task dependency from drm_display_mode
It removes the use of drm_mode_object from drm_display_mode struct
and it removes the use of base.id and base.type.
Signed-off-by: Shayenne Moura
---
include/drm/drm_modes.h | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index baded6514456..9ecc1e835565 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -136,8 +136,7 @@ enum drm_mode_status {
.hdisplay = (hd), .hsync_start = (hss), .hsync_end = (hse), \
.htotal = (ht), .hskew = (hsk), .vdisplay = (vd), \
.vsync_start = (vss), .vsync_end = (vse), .vtotal = (vt), \
- .vscan = (vs), .flags = (f), \
- .base.type = DRM_MODE_OBJECT_MODE
+ .vscan = (vs), .flags = (f)
#define CRTC_INTERLACE_HALVE_V (1 << 0) /* halve V values for interlacing */
#define CRTC_STEREO_DOUBLE (1 << 1) /* adjust timings for stereo modes */
@@ -213,20 +212,6 @@ struct drm_display_mode {
*/
struct list_head head;
- /**
-* @base:
-*
-* A display mode is a normal modeset object, possibly including public
-* userspace id.
-*
-* FIXME:
-*
-* This can probably be removed since the entire concept of userspace
-* managing modes explicitly has never landed in upstream kernel mode
-* setting support.
-*/
- struct drm_mode_object base;
-
/**
* @name:
*
@@ -429,14 +414,14 @@ struct drm_display_mode {
/**
* DRM_MODE_FMT - printf string for drm_display_mode
*/
-#define DRM_MODE_FMT"%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
+#define DRM_MODE_FMT"\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
/**
* DRM_MODE_ARG - printf arguments for drm_display_mode
* @m: display mode
*/
#define DRM_MODE_ARG(m) \
- (m)->base.id, (m)->name, (m)->vrefresh, (m)->clock, \
+ (m)->name, (m)->vrefresh, (m)->clock, \
(m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
(m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
(m)->type, (m)->flags
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm: meson: Delete base.id prints
This patch removes base.id prints from drm_display_mode
objects in meson files. It removes dependency from drm_mode_object.
Signed-off-by: Shayenne Moura
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index d8c5cc34e22e..b203560f666d 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -365,7 +365,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
unsigned int wr_clk =
readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
- DRM_DEBUG_DRIVER("%d:\"%s\"\n", mode->base.id, mode->name);
+ DRM_DEBUG_DRIVER("\"%s\"\n", mode->name);
/* Enable clocks */
regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
@@ -555,8 +555,8 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
int vic = drm_match_cea_mode(mode);
enum drm_mode_status status;
- DRM_DEBUG_DRIVER("Modeline %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x
0x%x\n",
- mode->base.id, mode->name, mode->vrefresh, mode->clock,
+ DRM_DEBUG_DRIVER("Modeline \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x
0x%x\n",
+ mode->name, mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
mode->vdisplay, mode->vsync_start,
@@ -650,8 +650,7 @@ static void meson_venc_hdmi_encoder_mode_set(struct
drm_encoder *encoder,
struct meson_drm *priv = dw_hdmi->priv;
int vic = drm_match_cea_mode(mode);
- DRM_DEBUG_DRIVER("%d:\"%s\" vic %d\n",
-mode->base.id, mode->name, vic);
+ DRM_DEBUG_DRIVER("\"%s\" vic %d\n", mode->name, vic);
/* VENC + VENC-DVI Mode setup */
meson_venc_hdmi_mode_set(priv, vic, mode);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 -next] staging: fbtft: use strcmp() instead of strncmp() for
On Tue, Dec 18, 2018 at 09:25:08PM +0800, YueHaibing wrote: > strncmp() stops comparing when either the end of one of the first two > arguments is reached or when 'n' characters have been compared, whichever > comes first.That means that strncmp(s1, s2, n) is equivalent to > strcmp(s1, s2) if n exceeds the length of s1 or the length of s2. > > This patch avoids that the following warning is reported by smatch: > > drivers/staging/fbtft/fbtft_device.c:1458 > fbtft_device_init() error: strncmp() '"list"' too small (5 vs 32) > > Signed-off-by: YueHaibing > --- > v2: fix patch title v2 is worse than v1... v1 is a little long but I wouldn't have complained about it. Please assume that the subject and the commit message are separate things. Take a look how the patch description reads on marc.info: https://marc.info/?l=linux-driver-devel=154513957719226=2 regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm: sti: Delete base.id prints
This patch removes base.id prints from drm_display_mode
objects in sti files. It removes dependency from drm_mode_object.
Signed-off-by: Shayenne Moura
---
drivers/gpu/drm/sti/sti_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index ed76e52eb213..ab7989bc8fa0 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -53,9 +53,9 @@ sti_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode)
struct clk *compo_clk, *pix_clk;
int rate = mode->clock * 1000;
- DRM_DEBUG_KMS("CRTC:%d (%s) mode:%d (%s)\n",
+ DRM_DEBUG_KMS("CRTC:%d (%s) mode: (%s)\n",
crtc->base.id, sti_mixer_to_str(mixer),
- mode->base.id, mode->name);
+ mode->name);
DRM_DEBUG_KMS("%d %d %d %d %d %d %d %d %d %d 0x%x 0x%x\n",
mode->vrefresh, mode->clock,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] drm: i915: Delete base.id prints
This patch removes base.id prints from drm_display_mode objects in i915 files. It removes dependency from drm_mode_object. Signed-off-by: Shayenne Moura --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 7f455bca528e..61dd7bb3fa85 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2948,8 +2948,8 @@ static void intel_seq_print_mode(struct seq_file *m, int tabs, for (i = 0; i < tabs; i++) seq_putc(m, '\t'); - seq_printf(m, "id %d:\"%s\" freq %d clock %d hdisp %d hss %d hse %d htot %d vdisp %d vss %d vse %d vtot %d type 0x%x flags 0x%x\n", - mode->base.id, mode->name, + seq_printf(m, "name:\"%s\" freq %d clock %d hdisp %d hss %d hse %d htot %d vdisp %d vss %d vse %d vtot %d type 0x%x flags 0x%x\n", + mode->name, mode->vrefresh, mode->clock, mode->hdisplay, mode->hsync_start, mode->hsync_end, mode->htotal, -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #5 from fin4...@hotmail.com --- Use latest AMd wip kernel, firmware files and Oibaf ppa. https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.21-wip https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amdgpu https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] drm: KMS cleanup remove drm_mode_object dependency
This patch serie removes drm_mode_object dependency from drm_display_mode struct. This is part of KMS cleanup. Shayenne Moura (7): drm: msm: Delete base.id prints drm: Remove use of drm_mode_object drm: omapdrm: Delete base.id prints drm: i915: Delete base.id prints drm: sti: Delete base.id prints drm: meson: Delete base.id prints drm: Complete remove drm_mode_object dependency drivers/gpu/drm/drm_crtc_helper.c | 5 ++--- drivers/gpu/drm/drm_modes.c | 9 - drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- drivers/gpu/drm/meson/meson_dw_hdmi.c | 9 - drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 4 ++-- drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c | 4 ++-- drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 4 ++-- drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 4 ++-- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 ++-- drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 4 ++-- drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 4 ++-- drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 ++-- drivers/gpu/drm/msm/edp/edp_bridge.c | 4 ++-- drivers/gpu/drm/omapdrm/omap_connector.c | 4 ++-- drivers/gpu/drm/omapdrm/omap_crtc.c | 4 ++-- drivers/gpu/drm/sti/sti_crtc.c| 4 ++-- include/drm/drm_modes.h | 10 -- 17 files changed, 36 insertions(+), 49 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm: msm: Delete base.id prints
This patch removes base.id prints from drm_display_mode
objects in msm files. It removes dependency from drm_mode_object.
Signed-off-by: Shayenne Moura
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 4 ++--
drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 4 ++--
drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 4 ++--
drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 ++--
drivers/gpu/drm/msm/edp/edp_bridge.c | 4 ++--
9 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
index 457c29dba4a1..4d35fe5b8c07 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
@@ -244,8 +244,8 @@ static void mdp4_crtc_mode_set_nofb(struct drm_crtc *crtc)
mode = >state->adjusted_mode;
- DBG("%s: set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
- mdp4_crtc->name, mode->base.id, mode->name,
+ DBG("%s: set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+ mdp4_crtc->name, mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
index 6a1ebdace391..a12ad73f08c7 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
@@ -58,8 +58,8 @@ static void mdp4_dsi_encoder_mode_set(struct drm_encoder
*encoder,
mode = adjusted_mode;
- DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
- mode->base.id, mode->name,
+ DBG("set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+ mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
index ba8e587f734b..3ace21e116a0 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
@@ -104,8 +104,8 @@ static void mdp4_dtv_encoder_mode_set(struct drm_encoder
*encoder,
mode = adjusted_mode;
- DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
- mode->base.id, mode->name,
+ DBG("set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+ mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
index 2bfb39082f54..21be7640d3a8 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
@@ -273,8 +273,8 @@ static void mdp4_lcdc_encoder_mode_set(struct drm_encoder
*encoder,
mode = adjusted_mode;
- DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
- mode->base.id, mode->name,
+ DBG("set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+ mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
index d6f79dc755b4..ac61a10b79cc 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
@@ -134,8 +134,8 @@ void mdp5_cmd_encoder_mode_set(struct drm_encoder *encoder,
{
mode = adjusted_mode;
- DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
- mode->base.id, mode->name,
+ DBG("set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+ mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index b1da9ce54379..ef2ee5888777 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -384,8 +384,8 @@ static void mdp5_crtc_mode_set_nofb(struct
[PATCH 2/7] drm: Remove use of drm_mode_object
This patch removes the drm_mode_object prints, evaluation and use from
drm_display_mode objects used in drm files. It removes dependency from
drm_mode_object.
Signed-off-by: Shayenne Moura
---
drivers/gpu/drm/drm_crtc_helper.c | 5 ++---
drivers/gpu/drm/drm_modes.c | 9 -
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index a3c81850e755..cc5cc8d109a2 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -386,9 +386,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
if (!encoder_funcs)
continue;
- DRM_DEBUG_KMS("[ENCODER:%d:%s] set [MODE:%d:%s]\n",
- encoder->base.id, encoder->name,
- mode->base.id, mode->name);
+ DRM_DEBUG_KMS("[ENCODER:%d:%s] set [MODE:%s]\n",
+ encoder->base.id, encoder->name, mode->name);
if (encoder_funcs->mode_set)
encoder_funcs->mode_set(encoder, mode, adjusted_mode);
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 24a750436559..adce9a26bac9 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -71,11 +71,6 @@ struct drm_display_mode *drm_mode_create(struct drm_device
*dev)
if (!nmode)
return NULL;
- if (drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_MODE)) {
- kfree(nmode);
- return NULL;
- }
-
return nmode;
}
EXPORT_SYMBOL(drm_mode_create);
@@ -92,8 +87,6 @@ void drm_mode_destroy(struct drm_device *dev, struct
drm_display_mode *mode)
if (!mode)
return;
- drm_mode_object_unregister(dev, >base);
-
kfree(mode);
}
EXPORT_SYMBOL(drm_mode_destroy);
@@ -911,11 +904,9 @@ EXPORT_SYMBOL(drm_mode_set_crtcinfo);
*/
void drm_mode_copy(struct drm_display_mode *dst, const struct drm_display_mode
*src)
{
- int id = dst->base.id;
struct list_head head = dst->head;
*dst = *src;
- dst->base.id = id;
dst->head = head;
}
EXPORT_SYMBOL(drm_mode_copy);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm: omapdrm: Delete base.id prints
This patch removes base.id prints from drm_display_mode
objects in omapdrm files. It removes dependency from drm_mode_object.
Signed-off-by: Shayenne Moura
---
drivers/gpu/drm/omapdrm/omap_connector.c | 4 ++--
drivers/gpu/drm/omapdrm/omap_crtc.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index b81302c4bf9e..e02986e0b2c6 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -306,9 +306,9 @@ static int omap_connector_mode_valid(struct drm_connector
*connector,
done:
DBG("connector: mode %s: "
- "%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+ "\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
(ret == MODE_OK) ? "valid" : "invalid",
- mode->base.id, mode->name, mode->vrefresh, mode->clock,
+ mode->name, mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start,
mode->hsync_end, mode->htotal,
mode->vdisplay, mode->vsync_start,
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index caffc547ef97..3d6febb2e9c4 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -427,8 +427,8 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
struct drm_display_mode *mode = >state->adjusted_mode;
- DBG("%s: set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
- omap_crtc->name, mode->base.id, mode->name,
+ DBG("%s: set mode: \"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+ omap_crtc->name, mode->name,
mode->vrefresh, mode->clock,
mode->hdisplay, mode->hsync_start, mode->hsync_end, mode->htotal,
mode->vdisplay, mode->vsync_start, mode->vsync_end, mode->vtotal,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #35 from Jerry Zuo --- "startup monitor sleep regression". Please give more details on that. Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Update crtc scaler settings when update_pipe is set
Hi,
On 18-12-18 12:07, Maarten Lankhorst wrote:
Op 17-12-2018 om 15:19 schreef Hans de Goede:
When the pipe_config's update_pipe flag is set we may need to update the
panel fitting settings. On GEN9+ this means we need to update the crtc's
scaler settings.
This fixes the following WARN_ON, during i915 loading on an Asrock
B150M Pro4S/D3 board with an i5-6500 CPU / graphics:
[drm:pipe_config_err [i915]] *ERROR* mismatch in pch_pfit.enabled
(expected no, found yes)
pipe state doesn't match!
WARNING: CPU: 3 PID: 305 at drivers/gpu/drm/i915/intel_display.c:12084
With line 12084 being the I915_STATE_WARN call inside the
"if (!intel_pipe_config_compare())" block in verify_crtc_state().
On this board with 2 1920x1080 monitors connected over HDMI the GOP
initializes both monitors at 1920x1080 and despite no scaling being
necessary configures a scaler for one of them.
When booting with fastboot=1 on the initial modeset needs_modeset will
be false while update_pipe is true. Since we were not calling
skl_update_scaler_crtc() in this case we would leave the scaler enabled
causing this error.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 62df34d30b1f..df32626e0810 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10919,7 +10919,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
}
if (INTEL_GEN(dev_priv) >= 9) {
- if (mode_changed)
+ if (mode_changed || pipe_config->update_pipe)
ret = skl_update_scaler_crtc(pipe_config);
if (!ret)
Hey,
Pushed.
Thank you.
You might also be interested in this patch / series, would be nice to have a
review on it.
https://patchwork.freedesktop.org/patch/268410/
I don't feel comfortable reviewing the backlight patch, and the last patch in
the
series, which unconditionally enables fastset seems a bit controversial.
IMHO it would be better to start with a patch which just enables this for GEN9+
(and valleyview and cherryview (*)).
It would be interesting to see what the CI thinks of just patches 1-4, with the
last
one dropped.
The 2 other patches look good to me, I will reply to them with my Reviewed-by.
Regards,
Hans
*) As a side / hobby project I've been doing hw-enablement for Bay and Cherry
Trail, as
such I've a ton of devices and I always run with fastboot=1 so I'm confident
that it is
fine there,\ actually I've 2 devices where the LCD panel will not lightup with
fastboot=0
(I've debugged this but failed to come up with anything useful).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #36 from Shmerl --- (In reply to Jerry Zuo from comment #35) > "startup monitor sleep regression". Please give more details on that. Thanks. This behavior used to happen in the previous kernerls but got fixed at one point. Now it's back. Basically, after GRUB, the system boots (I usually enable loglevel=4 to see system output), but right before reaching graphical login (sddm in my case), the monitor simply switched to sleep mode. To work around it, I have to: 1. Turn the monitor off and on. 2. Switch to tty1, and restart sddm from there. This enables graphical login. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [v1] drm/msm/dpu: Cleanup dpu plane interface
On Tue, Dec 18, 2018 at 06:50:38PM +0530, Jayant Shekhar wrote:
> Remove unused functions from dpu plane interface
> and unused variables from dpu plane state structure.
>
> Signed-off-by: Jayant Shekhar
Reviewed-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 27 ---
> 1 file changed, 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
> index 7fed0b6..0e6063a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
> @@ -28,23 +28,18 @@
> /**
> * struct dpu_plane_state: Define dpu extension of drm plane state object
> * @base:base drm plane state object
> - * @property_state: Local storage for msm_prop properties
> - * @property_values: cached plane property values
> * @aspace: pointer to address space for input/output buffers
> - * @input_fence: dereferenced input fence pointer
> * @stage: assigned by crtc blender
> * @multirect_index: index of the rectangle of SSPP
> * @multirect_mode: parallel or time multiplex multirect mode
> * @pending: whether the current update is still pending
> * @scaler3_cfg: configuration data for scaler3
> * @pixel_ext: configuration data for pixel extensions
> - * @scaler_check_state: indicates status of user provided pixel extension
> data
> * @cdp_cfg: CDP configuration
> */
> struct dpu_plane_state {
> struct drm_plane_state base;
> struct msm_gem_address_space *aspace;
> - void *input_fence;
> enum dpu_stage stage;
> uint32_t multirect_index;
> uint32_t multirect_mode;
> @@ -107,12 +102,6 @@ void dpu_plane_get_ctl_flush(struct drm_plane *plane,
> struct dpu_hw_ctl *ctl,
> void dpu_plane_flush(struct drm_plane *plane);
>
> /**
> - * dpu_plane_kickoff - final plane operations before commit kickoff
> - * @plane: Pointer to drm plane structure
> - */
> -void dpu_plane_kickoff(struct drm_plane *plane);
> -
> -/**
> * dpu_plane_set_error: enable/disable error condition
> * @plane: pointer to drm_plane structure
> */
> @@ -147,14 +136,6 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
> void dpu_plane_clear_multirect(const struct drm_plane_state *drm_state);
>
> /**
> - * dpu_plane_wait_input_fence - wait for input fence object
> - * @plane: Pointer to DRM plane object
> - * @wait_ms: Wait timeout value
> - * Returns: Zero on success
> - */
> -int dpu_plane_wait_input_fence(struct drm_plane *plane, uint32_t wait_ms);
> -
> -/**
> * dpu_plane_color_fill - enables color fill on plane
> * @plane: Pointer to DRM plane object
> * @color: RGB fill color value, [23..16] Blue, [15..8] Green, [7..0] Red
> @@ -164,12 +145,4 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
> int dpu_plane_color_fill(struct drm_plane *plane,
> uint32_t color, uint32_t alpha);
>
> -/**
> - * dpu_plane_set_revalidate - sets revalidate flag which forces a full
> - * validation of the plane properties in the next atomic check
> - * @plane: Pointer to DRM plane object
> - * @enable: Boolean to set/unset the flag
> - */
> -void dpu_plane_set_revalidate(struct drm_plane *plane, bool enable);
> -
> #endif /* _DPU_PLANE_H_ */
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: lcd: Remove useless BACKLIGHT_LCD_SUPPORT kernel symbol
On Sun, Dec 16, 2018 at 08:02:46AM +0300, Alexander Shiyan wrote: > Symbol BACKLIGHT_LCD_SUPPORT affecting anything, except enabling > the backlight & LCD Kconfig menu. The patch removes this symbol as > useless and converts it into a menu. Something bothered me about the patch but I think its the lack of explanation in the patch header about *why* we don't use/need/want BACKLIGHT_LCD_SUPPORT. Essentially the reason BACKLIGHT_LCD_SUPPORT is useless is that we have two _CLASS_DEVICE configs (LCD_CLASS_DEVICE and BACKLIGHT_LCD_DEVICE) that do the same job (ad that do have code attached to them). It would be good to mention that in the patch header. Daniel. > > Signed-off-by: Alexander Shiyan > --- > arch/unicore32/Kconfig| 1 - > drivers/gpu/drm/Kconfig | 2 -- > drivers/gpu/drm/bridge/Kconfig| 1 - > drivers/gpu/drm/fsl-dcu/Kconfig | 1 - > drivers/gpu/drm/i915/Kconfig | 1 - > drivers/gpu/drm/nouveau/Kconfig | 1 - > drivers/gpu/drm/shmobile/Kconfig | 1 - > drivers/gpu/drm/tilcdc/Kconfig| 1 - > drivers/staging/olpc_dcon/Kconfig | 1 - > drivers/usb/misc/Kconfig | 1 - > drivers/video/backlight/Kconfig | 10 ++ > drivers/video/fbdev/Kconfig | 5 - > 12 files changed, 2 insertions(+), 24 deletions(-) > > diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig > index a4c0515..afeea3d 100644 > --- a/arch/unicore32/Kconfig > +++ b/arch/unicore32/Kconfig > @@ -211,7 +211,6 @@ config I2C_EEPROM_AT24 > > config LCD_BACKLIGHT > tristate "LCD Backlight support" > - select BACKLIGHT_LCD_SUPPORT > select BACKLIGHT_PWM > > endmenu > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 4385f00..ef442a7 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -198,7 +198,6 @@ config DRM_RADEON > select POWER_SUPPLY > select HWMON > select BACKLIGHT_CLASS_DEVICE > - select BACKLIGHT_LCD_SUPPORT > select INTERVAL_TREE > help > Choose this option if you have an ATI Radeon graphics card. There > @@ -219,7 +218,6 @@ config DRM_AMDGPU > select POWER_SUPPLY > select HWMON > select BACKLIGHT_CLASS_DEVICE > - select BACKLIGHT_LCD_SUPPORT > select INTERVAL_TREE > select CHASH > help > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 9eeb8ef..0f724e2 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -75,7 +75,6 @@ config DRM_PARADE_PS8622 > depends on OF > select DRM_PANEL > select DRM_KMS_HELPER > - select BACKLIGHT_LCD_SUPPORT > select BACKLIGHT_CLASS_DEVICE > ---help--- > Parade eDP-LVDS bridge chip driver. > diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig b/drivers/gpu/drm/fsl-dcu/Kconfig > index 14a72c4..dc82588 100644 > --- a/drivers/gpu/drm/fsl-dcu/Kconfig > +++ b/drivers/gpu/drm/fsl-dcu/Kconfig > @@ -2,7 +2,6 @@ config DRM_FSL_DCU > tristate "DRM Support for Freescale DCU" > depends on DRM && OF && ARM && COMMON_CLK > select BACKLIGHT_CLASS_DEVICE > - select BACKLIGHT_LCD_SUPPORT > select DRM_KMS_HELPER > select DRM_KMS_CMA_HELPER > select DRM_PANEL > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index 33a458b..90d406e73 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -15,7 +15,6 @@ config DRM_I915 > select IRQ_WORK > # i915 depends on ACPI_VIDEO when ACPI is enabled > # but for select to work, need to select ACPI_VIDEO's dependencies, ick > - select BACKLIGHT_LCD_SUPPORT if ACPI > select BACKLIGHT_CLASS_DEVICE if ACPI > select INPUT if ACPI > select ACPI_VIDEO if ACPI > diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig > index 4b75ad40..a0238bf 100644 > --- a/drivers/gpu/drm/nouveau/Kconfig > +++ b/drivers/gpu/drm/nouveau/Kconfig > @@ -11,7 +11,6 @@ config DRM_NOUVEAU > select MXM_WMI if ACPI && X86 > select POWER_SUPPLY > # Similar to i915, we need to select ACPI_VIDEO and it's dependencies > - select BACKLIGHT_LCD_SUPPORT if ACPI && X86 > select BACKLIGHT_CLASS_DEVICE if ACPI && X86 > select INPUT if ACPI && X86 > select THERMAL if ACPI && X86 > diff --git a/drivers/gpu/drm/shmobile/Kconfig > b/drivers/gpu/drm/shmobile/Kconfig > index 61bbe8e..e2a6c82 100644 > --- a/drivers/gpu/drm/shmobile/Kconfig > +++ b/drivers/gpu/drm/shmobile/Kconfig > @@ -4,7 +4,6 @@ config DRM_SHMOBILE > depends on DRM && ARM > depends on ARCH_SHMOBILE || COMPILE_TEST > select BACKLIGHT_CLASS_DEVICE > - select BACKLIGHT_LCD_SUPPORT > select DRM_KMS_HELPER > select DRM_KMS_CMA_HELPER > select DRM_GEM_CMA_HELPER > diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig > index 5259804..cb7df20 100644 > ---
Re: [PATCH v2 1/2] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU
On Fri, Dec 14, 2018 at 03:16:39PM -0700, Jordan Crouse wrote: > Add documentation for the interconnect and interconnect-names bindings > for the GPU node as detailed by bindings/interconnect/interconnect.txt. > > Signed-off-by: Jordan Crouse > --- > Documentation/devicetree/bindings/display/msm/gpu.txt | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt > b/Documentation/devicetree/bindings/display/msm/gpu.txt > index 8d9415180c22..19b5ae459fdb 100644 > --- a/Documentation/devicetree/bindings/display/msm/gpu.txt > +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt > @@ -19,6 +19,9 @@ Required properties: >* "mem_iface" > - iommus: optional phandle to an adreno iommu instance > - operating-points-v2: optional phandle to the OPP operating points > +- interconnect: optional phandle to a interconnect provider. See > + ../interconnect/interconnect.txt for details. > +- interconnect-names: Name string for the interconnects. > - qcom,gmu: For a6xx and newer targets a phandle to the GMU device that will >control the power for the GPU > > @@ -68,6 +71,9 @@ Example a6xx (with GMU): > > operating-points-v2 = <_opp_table>; > > + interconnects = <_hlos MASTER_GFX3D _hlos SLAVE_EBI1>; > + interconnect-names = "gfx-mem"; There's not really any point to having *-names when there is only 1 value. > + > qcom,gmu = <>; > }; > }; > -- > 2.18.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/gem: Mark pinned pages as unevictable
On Tue, Dec 18, 2018 at 9:55 PM Chris Wilson wrote: > > Quoting Kuo-Hsin Yang (2018-12-17 09:04:01) > > > > E.g. when the size of a zone is 3.9 GiB, the inactive_ratio is 5. If > > active_anon / inactive_anon < 5 and all pages in the inactive_anon lru > > are pinned, page reclaim would keep scanning inactive_anon lru without > > reclaiming memory. It breaks page reclaim when the rockchip driver only > > pins about 1/6 of the anon lru pages. > > Right, we invalidate the "inactive anon list should be small enough that > the VM never has to do too much work" assumption. > > > Mark these pinned pages as unevictable to avoid the premature oom-killer > > invocation. See also similar patch on i915 driver [1]. > > > > [1]: > > https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-ch...@chris-wilson.co.uk > > > > Signed-off-by: Kuo-Hsin Yang > > Cc: Daniel Vetter > > Cc: Chris Wilson > Reviewed-by: Chris Wilson Thanks for your review. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/1] drm/i915: Enable fastset by default, except on initial modeset
Hi, On 17-12-18 19:43, Rodrigo Vivi wrote: On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote: Hi All, As discussed a while ago, I would like to see us enable fastboot by default, starting with Skylake / GEN9 and newer hardware, so that we can avoid an unnecessary modeset at boot and move to a truely flickerfree boot. During our previous discussion about this Maarten mentioned that a first step would be to get this patch from him upstream. So I'm hereby resubmitting it, with a small fix. Hopefully the CI will like it better this time (if not we will need to investigate) and once this passes CI I hope this can be reviewed quickly and we can get this upstream. I honestly believe the first step is to make sure FBC, PSR, DRRS features > gets enabled somehow with fastboot. That is a good point, FBC will already be enabled on a fastboot as intel_update_crtc does: if (new_plane_state) intel_fbc_enable(intel_crtc, pipe_config, new_plane_state); Independent of need_modeset() returning true. PSR indeed stays off, even if i915.enable_psr=1 is passed on the kernel commandline. I've just completed writing a patch-set (2 patches) fixing this. I will submit these upstream soon. DRRS seems to be the same as PSR (I don't have hw to test) I will also submit 2 patches building on top of the previous 2 which should fix this, we already allow runtime enabling/disabling through i915_drrs_ctl in debugfs, so these 2 patches should be fine. Maybe DSC as well?! DSC? : [hans@shalem linux]$ grep -r dsc drivers/gpu/drm/i915 [hans@shalem linux]$ Right now as I can remember FBC, PSR, and DRRS will get disabled if fastboot is used because we just enable those when enabling the pipe. You're right for PSR and DRRS, as Maarten just found out FBC has the opposite problem, we don't turn it off on a fastset when it was enabled and we decide it should no longer be enabled. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel][PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation
Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko: From: Oleksandr Andrushchenko Use page directory based shared buffer implementation now available as common code for Xen frontend drivers. Remove flushing of shared buffer on page flip as this workaround needs a proper fix. Signed-off-by: Oleksandr Andrushchenko --- Reviewed-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU
On Tue, Dec 18, 2018 at 11:22:01AM -0600, Rob Herring wrote: > On Fri, Dec 14, 2018 at 03:16:39PM -0700, Jordan Crouse wrote: > > Add documentation for the interconnect and interconnect-names bindings > > for the GPU node as detailed by bindings/interconnect/interconnect.txt. > > > > Signed-off-by: Jordan Crouse > > --- > > Documentation/devicetree/bindings/display/msm/gpu.txt | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt > > b/Documentation/devicetree/bindings/display/msm/gpu.txt > > index 8d9415180c22..19b5ae459fdb 100644 > > --- a/Documentation/devicetree/bindings/display/msm/gpu.txt > > +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt > > @@ -19,6 +19,9 @@ Required properties: > >* "mem_iface" > > - iommus: optional phandle to an adreno iommu instance > > - operating-points-v2: optional phandle to the OPP operating points > > +- interconnect: optional phandle to a interconnect provider. See > > + ../interconnect/interconnect.txt for details. > > +- interconnect-names: Name string for the interconnects. > > - qcom,gmu: For a6xx and newer targets a phandle to the GMU device that > > will > >control the power for the GPU > > > > @@ -68,6 +71,9 @@ Example a6xx (with GMU): > > > > operating-points-v2 = <_opp_table>; > > > > + interconnects = <_hlos MASTER_GFX3D _hlos SLAVE_EBI1>; > > + interconnect-names = "gfx-mem"; > > There's not really any point to having *-names when there is only 1 > value. For the moment we can only look up the path from the DT by name. I guess we could add an lookup by index but I'm not sure if that had already been considered and rejected. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 5/6] dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings
Update the GPU bindings and document the new bindings for the GMU
device found with Adreno a6xx targets.
Signed-off-by: Jordan Crouse
---
v7: Updated the GMU compatible string and clarified details about when clocks
can be optional on the GPU
.../devicetree/bindings/display/msm/gmu.txt | 59 +++
.../devicetree/bindings/display/msm/gpu.txt | 42 -
2 files changed, 98 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
b/Documentation/devicetree/bindings/display/msm/gmu.txt
new file mode 100644
index ..59e6865898f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -0,0 +1,59 @@
+Qualcomm adreno/snapdragon GMU (Graphics management unit)
+
+The GMU is a programmable power controller for the GPU. the CPU controls the
+GMU which in turn handles power controls for the GPU.
+
+Required properties:
+- compatible: "qcom,adreno-gmu-XYZ.W", "qcom,adreno-gmu"
+for example: "qcom,adreno-gmu-630.2", "qcom,adreno-gmu"
+ Note that you need to list the less specific "qcom,adreno-gmu"
+ for generic matches and the more specific identifier to identify
+ the specific device.
+- reg: Physical base address and length of the GMU registers.
+- reg-names: Matching names for the register regions
+ * "gmu"
+ * "gmu_pdc"
+ * "gmu_pdc_seg"
+- interrupts: The interrupt signals from the GMU.
+- interrupt-names: Matching names for the interrupts
+ * "hfi"
+ * "gmu"
+- clocks: phandles to the device clocks
+- clock-names: Matching names for the clocks
+ * "gmu"
+ * "cxo"
+ * "axi"
+ * "mnoc"
+- power-domains: should be <_gpucc GPU_CX_GDSC>
+- iommus: phandle to the adreno iommu
+- operating-points-v2: phandle to the OPP operating points
+
+Example:
+
+/ {
+ ...
+
+ gmu: gmu@506a000 {
+ compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
+
+ reg = <0x506a000 0x3>,
+ <0xb28 0x1>,
+ <0xb48 0x1>;
+ reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+
+ interrupts = ,
+;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = < GPU_CC_CX_GMU_CLK>,
+ < GPU_CC_CXO_CLK>,
+ < GCC_DDRSS_GPU_AXI_CLK>,
+ < GCC_GPU_MEMNOC_GFX_CLK>;
+ clock-names = "gmu", "cxo", "axi", "memnoc";
+
+ power-domains = < GPU_CX_GDSC>;
+ iommus = <_smmu 5>;
+
+ operating-points-v2 = <_opp_table>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 4ad5e70e5c3e..9c89f4fdb8ca 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -8,14 +8,23 @@ Required properties:
with the chip-id.
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt signal from the gpu.
-- clocks: device clocks
+- clocks: device clocks (if applicable)
See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required:
+- clock-names: the following clocks are required by a3xx, a4xx and a5xx
+ cores:
* "core"
* "iface"
* "mem_iface"
+ For GMU attached devices the GPU clocks are not used and are not required.
The
+ following devices should not list clocks:
+ - qcom,adreno-630.2
+- iommus: optional phandle to an adreno iommu instance
+- operating-points-v2: optional phandle to the OPP operating points
+- qcom,gmu: For GMU attached devices a phandle to the GMU device that will
+ control the power for the GPU. Applicable targets:
+- qcom,adreno-630.2
-Example:
+Example 3xx/4xx/a5xx:
/ {
...
@@ -35,3 +44,30 @@ Example:
< MMSS_IMEM_AHB_CLK>;
};
};
+
+Example a6xx (with GMU):
+
+/ {
+ ...
+
+ gpu@500 {
+ compatible = "qcom,adreno-630.2", "qcom,adreno";
+ #stream-id-cells = <16>;
+
+ reg = <0x500 0x4>, <0x509e000 0x10>;
+ reg-names = "kgsl_3d0_reg_memory", "cx_mem";
+
+ /*
+* Look ma, no clocks! The GPU clocks and power are
+* controlled entirely by the GMU
+*/
+
+ interrupts = ;
+
+ iommus = <_smmu 0>;
+
+ operating-points-v2 = <_opp_table>;
+
+ qcom,gmu = <>;
+ };
+};
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 6/6] arm64: dts: sdm845: Add gpu and gmu device nodes
Add the nodes to describe the Adreno GPU and GMU devices.
Signed-off-by: Jordan Crouse
---
v7: Updated the GMU compatible string and removed interrupt-names
arch/arm64/boot/dts/qcom/sdm845.dtsi | 122 +++
1 file changed, 122 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 233a5898ebc2..4779014e4a05 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1349,6 +1350,127 @@
};
};
+
+ gpu@500 {
+ compatible = "qcom,adreno-630.2", "qcom,adreno";
+ #stream-id-cells = <16>;
+
+ reg = <0x500 0x4>, <0x509e000 0x10>;
+ reg-names = "kgsl_3d0_reg_memory", "cx_mem";
+
+ /*
+* Look ma, no clocks! The GPU clocks and power are
+* controlled entirely by the GMU
+*/
+
+ interrupts = ;
+
+ iommus = <_smmu 0>;
+
+ operating-points-v2 = <_opp_table>;
+
+ qcom,gmu = <>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ opp-71000 {
+ opp-hz = /bits/ 64 <71000>;
+ qcom,level =
;
+ };
+
+ opp-67500 {
+ opp-hz = /bits/ 64 <67500>;
+ qcom,level =
;
+ };
+
+ opp-59600 {
+ opp-hz = /bits/ 64 <59600>;
+ qcom,level =
;
+ };
+
+ opp-52000 {
+ opp-hz = /bits/ 64 <52000>;
+ qcom,level = ;
+ };
+
+ opp-41400 {
+ opp-hz = /bits/ 64 <41400>;
+ qcom,level =
;
+ };
+
+ opp-34200 {
+ opp-hz = /bits/ 64 <34200>;
+ qcom,level = ;
+ };
+
+ opp-25700 {
+ opp-hz = /bits/ 64 <25700>;
+ qcom,level =
;
+ };
+ };
+ };
+
+ adreno_smmu: iommu@504 {
+ compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
+ reg = <0x504 0x1>;
+ #iommu-cells = <1>;
+ #global-interrupts = <2>;
+ interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ;
+ clocks = < GCC_GPU_MEMNOC_GFX_CLK>,
+ < GCC_GPU_CFG_AHB_CLK>;
+ clock-names = "bus", "iface";
+
+ power-domains = < GPU_CX_GDSC>;
+ };
+
+ gmu: gmu@506a000 {
+ compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
+
+ reg = <0x506a000 0x3>,
+ <0xb28 0x1>,
+ <0xb48 0x1>;
+ reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+
+ interrupts = ,
+;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = < GPU_CC_CX_GMU_CLK>,
+ < GPU_CC_CXO_CLK>,
+ < GCC_DDRSS_GPU_AXI_CLK>,
+ < GCC_GPU_MEMNOC_GFX_CLK>;
+ clock-names = "gmu", "cxo", "axi", "memnoc";
+
+ power-domains = < GPU_CX_GDSC>;
+ iommus = <_smmu 5>;
+
+ operating-points-v2 = <_opp_table>;
+
+ gmu_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+
[PATCH v7 0/6] arm64: dts: Add sdm845 GPU/GMU and SMMU
Now that more of the sdm845 bindings are headed upstream this a refresh of of https://patchwork.freedesktop.org/series/39308/ to add bindings and nodes for the GPU/GMU and GPU SMMU for sdm845. v7 of this patchset also removes interrupt-names from the driver and the existing DT changes per feedback from Rob Herring. This is based on : git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git for-next with: https://lore.kernel.org/patchwork/patch/1018365/ This change requires the following dependencies: include/dt-bindings/power/qcom-rpmpd.h: https://patchwork.kernel.org/patch/1079/ qcom,smmu-v2 binding: https://patchwork.kernel.org/patch/10581911/ v7: Add patches to remove interrupt-names, add version specific compatible string for gmu v6: Update GPU bindings for a6xx and make the examples match the nodes and vice versa. Clean up types and rebase on https://lore.kernel.org/patchwork/patch/1018365/ to help facilitate merging. v5: Use symbolic names for the RPMH power levels defined in OPP table, move the opp tables as children of their respective nodes and rename the iommu device. v4: Rebase v3: Split GMU PDC region into two GPU specific sections, fix indentation, really use qcom,gmu for the phandle name v2: changed qcom,arc-level to qcom,level following discussion with Viresh; change gmu phandle to qcom,gmu per Rob Jordan Crouse (6): drm/msm/gpu: Remove hardcoded interrupt name drm/msm: drop interrupt-names ARM: dts: qcom: Removed unused interrupt-names from GPU node arm64: dts: qcom: msm8916: Remove unused interrupt-names from GPU dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings arm64: dts: sdm845: Add gpu and gmu device nodes .../devicetree/bindings/display/msm/gmu.txt | 59 + .../devicetree/bindings/display/msm/gpu.txt | 43 +- arch/arm/boot/dts/qcom-apq8064.dtsi | 1 - arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 - arch/arm64/boot/dts/qcom/sdm845.dtsi | 122 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 - drivers/gpu/drm/msm/msm_gpu.c | 2 +- drivers/gpu/drm/msm/msm_gpu.h | 1 - 8 files changed, 221 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Unblock writer if reader closes file
Prevents deadlock when fifo is full and reader closes file.
Signed-off-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_rd.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index b5672061ae085..d990b5f5154cf 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -115,7 +115,9 @@ static void rd_write(struct msm_rd_state *rd, const void
*buf, int sz)
char *fptr = >buf[fifo->head];
int n;
- wait_event(rd->fifo_event, circ_space(>fifo) > 0);
+ wait_event(rd->fifo_event, circ_space(>fifo) > 0 ||
!rd->open);
+ if (!rd->open)
+ return;
/* Note that smp_load_acquire() is not strictly required
* as CIRC_SPACE_TO_END() does not access the tail more
@@ -213,7 +215,10 @@ static int rd_open(struct inode *inode, struct file *file)
static int rd_release(struct inode *inode, struct file *file)
{
struct msm_rd_state *rd = inode->i_private;
+
rd->open = false;
+ wake_up_all(>fifo_event);
+
return 0;
}
--
2.20.0.405.gbc1bbc6f85-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 3/6] ARM: dts: qcom: Removed unused interrupt-names from GPU node
'interrupt-names' shouldn't be used in cases when there is only one interrupt and it is not otherwise used in the driver. Signed-off-by: Jordan Crouse --- arch/arm/boot/dts/qcom-apq8064.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi index 48c3cf427610..0a9862729c80 100644 --- a/arch/arm/boot/dts/qcom-apq8064.dtsi +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi @@ -1186,7 +1186,6 @@ reg = <0x0430 0x2>; reg-names = "kgsl_3d0_reg_memory"; interrupts = ; - interrupt-names = "kgsl_3d0_irq"; clock-names = "core_clk", "iface_clk", -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/6] drm/msm/gpu: Remove hardcoded interrupt name
Every GPU core only has one interrupt so there isn't any
value in looking up the interrupt by name. Remove the name (which
is legacy anyway) and use platform_get_irq() instead.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 -
drivers/gpu/drm/msm/msm_gpu.c | 2 +-
drivers/gpu/drm/msm/msm_gpu.h | 1 -
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 93d70f4a2154..bfeea50fca8a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -713,7 +713,6 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
adreno_gpu->rev = config->rev;
adreno_gpu_config.ioname = "kgsl_3d0_reg_memory";
- adreno_gpu_config.irqname = "kgsl_3d0_irq";
adreno_gpu_config.va_start = SZ_16M;
adreno_gpu_config.va_end = 0x;
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 11aac8337066..f9de09d14344 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -868,7 +868,7 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
}
/* Get Interrupt: */
- gpu->irq = platform_get_irq_byname(pdev, config->irqname);
+ gpu->irq = platform_get_irq(pdev, 0);
if (gpu->irq < 0) {
ret = gpu->irq;
dev_err(drm->dev, "failed to get irq: %d\n", ret);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index f82bac08..fc4040e24a6b 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -31,7 +31,6 @@ struct msm_gpu_state;
struct msm_gpu_config {
const char *ioname;
- const char *irqname;
uint64_t va_start;
uint64_t va_end;
unsigned int nr_rings;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/6] arm64: dts: qcom: msm8916: Remove unused interrupt-names from GPU
'interrupt-names' shouldn't be used in cases when there is only one interrupt and it is not otherwise used in the driver. Signed-off-by: Jordan Crouse --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index c5348c3da5a2..846de1043e4d 100644 --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -880,7 +880,6 @@ reg = <0x01c0 0x2>; reg-names = "kgsl_3d0_reg_memory"; interrupts = ; - interrupt-names = "kgsl_3d0_irq"; clock-names = "core", "iface", -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/6] drm/msm: drop interrupt-names
Each GPU core only uses one interrupt so we don't to look up an interrupt by name and thereby we don't need interrupt-names. Signed-off-by: Jordan Crouse --- Documentation/devicetree/bindings/display/msm/gpu.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index 43fac0fe09bb..4ad5e70e5c3e 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -25,7 +25,6 @@ Example: reg = <0x0430 0x2>; reg-names = "kgsl_3d0_reg_memory"; interrupts = ; - interrupt-names = "kgsl_3d0_irq"; clock-names = "core", "iface", -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes
Quoting Doug Anderson (2018-12-17 16:34:31)
> Hi,
>
> On Sun, Dec 16, 2018 at 11:06 PM Viresh Kumar wrote:
> >
> > +Rob +Stephen,
> >
> > On 14-12-18, 09:04, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, Dec 13, 2018 at 8:41 PM Viresh Kumar
> > > wrote:
> > > >
> > > > On 12-12-18, 14:18, Jordan Crouse wrote:
> > > > > + gpu_opp_table: opp-table {
> > > > > + compatible =
> > > > > "operating-points-v2-qcom-level";
> > > >
> > > > I think you need to mention "operating-points-v2" as well here.
> > >
> > > Are you saying the above should be:
> > > compatible = "operating-points-v2-qcom-level", "operating-points-v2";
> > >
> > > If so I'm not sure I agree.
> >
> > Well I have my doubts as well on this. This is where the ordering was
> > discussed
> > earlier:
> >
> > https://lore.kernel.org/lkml/152328979897.180276.15963925877442657...@swboyd.mtv.corp.google.com/
> >
> > @Rob/Stephen: Should the opp-table node above also have
> > "operating-points-v2"
> > string in the compatible property ?
> >
> > > It's _not_ really compatible with the
> > > "operating-points-v2" binding. If you had a driver that had never
> > > heard of "operating-points-v2-qcom-level" and had only heard of
> > > "operating-points-v2" and it took a look at this node it would have no
> > > idea what to do with it.
> >
> > Well it will parse everything apart from the qcom,level thing, so it can
> > actually parse stuff here.
> >
> > > I'll also note that other instances posted to the list don't list both:
> > >
> > > https://patchwork.kernel.org/patch/10725801/ - RPM / RPMH PD bindings
> > > https://patchwork.kernel.org/patch/10725793/ - RPMH PD device tree for
> > > sdm845
> > >
> > > The bindings patch also makes no mention of needing
> > > "operating-points-v2". I think the common case when a fallback is
> > > required it is explicitly called out in the bindings:
> > >
> > > https://patchwork.kernel.org/patch/10725803/ - qcom-opp bindings
> >
> > Sure, maybe I am wrong but its better to get some clarity on it from
> > Rob/Stephen.
>
> In case it helps:
>
> https://lkml.kernel.org/r/20181217210849.GA15490@bogus
>
> ...shows Rob giving a Reviewed-by with just
>
> compatible = "operating-points-v2-qcom-level";
>
> ...and not:
>
> compatible = "operating-points-v2-qcom-level", "operating-points-v2";
>
I don't see a problem if both compatible strings are there. Does that
change anything? I suppose the platform bus populate code won't create a
device for the subnode if it has 'operating-points-v2', so maybe the
fallback compatible string should be there? And then the generic OPP
code can parse out the frequency at least without having to know that
it's a qcom specific OPP table.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v1] drm/msm/dpu: Remove unused enum and comment from dpu mdss
Remove enum dpu_iommu_domain from dpu mdss as its unused.
Remove unnecessary comment for variable which is already
removed.
Signed-off-by: Jayant Shekhar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index 68c54d2..1ab8d4a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -258,12 +258,6 @@ enum dpu_vbif {
VBIF_NRT = VBIF_1
};
-enum dpu_iommu_domain {
- DPU_IOMMU_DOMAIN_UNSECURE,
- DPU_IOMMU_DOMAIN_SECURE,
- DPU_IOMMU_DOMAIN_MAX
-};
-
/**
* DPU HW,Component order color map
*/
@@ -358,7 +352,6 @@ enum dpu_3d_blend_mode {
* @alpha_enable: whether the format has an alpha channel
* @num_planes: number of planes (including meta data planes)
* @fetch_mode: linear, tiled, or ubwc hw fetch behavior
- * @is_yuv: is format a yuv variant
* @flag: usage bit flags
* @tile_width: format tile width
* @tile_height: format tile height
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes
Hi,
On Tue, Dec 18, 2018 at 10:40 AM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2018-12-17 16:34:31)
> > Hi,
> >
> > On Sun, Dec 16, 2018 at 11:06 PM Viresh Kumar
> > wrote:
> > >
> > > +Rob +Stephen,
> > >
> > > On 14-12-18, 09:04, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Thu, Dec 13, 2018 at 8:41 PM Viresh Kumar
> > > > wrote:
> > > > >
> > > > > On 12-12-18, 14:18, Jordan Crouse wrote:
> > > > > > + gpu_opp_table: opp-table {
> > > > > > + compatible =
> > > > > > "operating-points-v2-qcom-level";
> > > > >
> > > > > I think you need to mention "operating-points-v2" as well here.
> > > >
> > > > Are you saying the above should be:
> > > > compatible = "operating-points-v2-qcom-level", "operating-points-v2";
> > > >
> > > > If so I'm not sure I agree.
> > >
> > > Well I have my doubts as well on this. This is where the ordering was
> > > discussed
> > > earlier:
> > >
> > > https://lore.kernel.org/lkml/152328979897.180276.15963925877442657...@swboyd.mtv.corp.google.com/
> > >
> > > @Rob/Stephen: Should the opp-table node above also have
> > > "operating-points-v2"
> > > string in the compatible property ?
> > >
> > > > It's _not_ really compatible with the
> > > > "operating-points-v2" binding. If you had a driver that had never
> > > > heard of "operating-points-v2-qcom-level" and had only heard of
> > > > "operating-points-v2" and it took a look at this node it would have no
> > > > idea what to do with it.
> > >
> > > Well it will parse everything apart from the qcom,level thing, so it can
> > > actually parse stuff here.
> > >
> > > > I'll also note that other instances posted to the list don't list both:
> > > >
> > > > https://patchwork.kernel.org/patch/10725801/ - RPM / RPMH PD bindings
> > > > https://patchwork.kernel.org/patch/10725793/ - RPMH PD device tree for
> > > > sdm845
> > > >
> > > > The bindings patch also makes no mention of needing
> > > > "operating-points-v2". I think the common case when a fallback is
> > > > required it is explicitly called out in the bindings:
> > > >
> > > > https://patchwork.kernel.org/patch/10725803/ - qcom-opp bindings
> > >
> > > Sure, maybe I am wrong but its better to get some clarity on it from
> > > Rob/Stephen.
> >
> > In case it helps:
> >
> > https://lkml.kernel.org/r/20181217210849.GA15490@bogus
> >
> > ...shows Rob giving a Reviewed-by with just
> >
> > compatible = "operating-points-v2-qcom-level";
> >
> > ...and not:
> >
> > compatible = "operating-points-v2-qcom-level", "operating-points-v2";
> >
>
> I don't see a problem if both compatible strings are there. Does that
> change anything? I suppose the platform bus populate code won't create a
> device for the subnode if it has 'operating-points-v2', so maybe the
> fallback compatible string should be there? And then the generic OPP
> code can parse out the frequency at least without having to know that
> it's a qcom specific OPP table.
OK, it's fine with me to have the fallback, but if we do we should be
consistent about it and make sure it's in all the bindings and device
tree files...
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Fix drmNodeIsDRM() on DragonFly
On Mon, Dec 17, 2018 at 06:09:47PM +, Emil Velikov wrote: > On Tue, 11 Dec 2018 at 22:15, François Tigeot wrote: > > > > * There is no way to check if a device name is really a drm device > > by looking it up in a virtual filesystem like on Linux > > > > * The major device number is also dynamically allocated from a pool, > > comparing it to a constant makes no sense > > > > * In the absence of better ideas, just assume the device name really > > points to a drm device and always return true > > > I guess one could use the sysfs path, although that may require a few > extra lines to the linux emulation layer. We currently have such a thing living in local patches and it's a source of pain; it regularly breaks for one reason or another. It's not using sysfs but a hw.dri sysctl mechanism originating from FreeBSD. Some of the patches are visible here: https://github.com/DragonFlyBSD/DPorts/blob/master/graphics/libdrm/files/patch-xf86drm.c > What's the reason behind the dynamic allocation of the major? FWIW > some userspace requires a fixed DRM_MAJOR - they will need patching to > run :-( Major/minor numbers were required when device files had to be created on regular filesystem like UFS but when a devfs filesystem was implemented for DragonFly almost a decade ago, nobody thought it was important anymore. There have been no fixed major numbers on DragonFly since 2009 or so. -- Francois Tigeot ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/xen-front: Make shmem backed display buffer coherent
Den 27.11.2018 11.32, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts. Make sure that the frontend's
memory is coherent and the backend always sees correct display
buffer content.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 62 +++--
1 file changed, 48 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 47ff019d3aef..c592735e49d2 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -33,8 +33,11 @@ struct xen_gem_object {
/* set for buffers allocated by the backend */
bool be_alloc;
- /* this is for imported PRIME buffer */
- struct sg_table *sgt_imported;
+ /*
+* this is for imported PRIME buffer or the one allocated via
+* drm_gem_get_pages.
+*/
+ struct sg_table *sgt;
};
static inline struct xen_gem_object *
@@ -77,10 +80,21 @@ static struct xen_gem_object *gem_create_obj(struct
drm_device *dev,
return xen_obj;
}
+struct sg_table *xen_drm_front_gem_get_sg_table(struct drm_gem_object *gem_obj)
+{
+ struct xen_gem_object *xen_obj = to_xen_gem_obj(gem_obj);
+
+ if (!xen_obj->pages)
+ return ERR_PTR(-ENOMEM);
+
+ return drm_prime_pages_to_sg(xen_obj->pages, xen_obj->num_pages);
+}
+
static struct xen_gem_object *gem_create(struct drm_device *dev, size_t size)
{
struct xen_drm_front_drm_info *drm_info = dev->dev_private;
struct xen_gem_object *xen_obj;
+ struct address_space *mapping;
int ret;
size = round_up(size, PAGE_SIZE);
@@ -113,10 +127,14 @@ static struct xen_gem_object *gem_create(struct
drm_device *dev, size_t size)
xen_obj->be_alloc = true;
return xen_obj;
}
+
/*
* need to allocate backing pages now, so we can share those
* with the backend
*/
Let's see if I understand what you're doing:
Here you say that the pages should be DMA accessible for devices that can
only see 4GB.
+ mapping = xen_obj->base.filp->f_mapping;
+ mapping_set_gfp_mask(mapping, GFP_USER | __GFP_DMA32);
+
xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
xen_obj->pages = drm_gem_get_pages(_obj->base);
if (IS_ERR_OR_NULL(xen_obj->pages)) {
@@ -125,8 +143,27 @@ static struct xen_gem_object *gem_create(struct drm_device
*dev, size_t size)
goto fail;
}
+ xen_obj->sgt = xen_drm_front_gem_get_sg_table(_obj->base);
+ if (IS_ERR_OR_NULL(xen_obj->sgt)){
+ ret = PTR_ERR(xen_obj->sgt);
+ xen_obj->sgt = NULL;
+ goto fail_put_pages;
+ }
+
+ if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
+ DMA_BIDIRECTIONAL)) {
Are you using the DMA streaming API as a way to flush the caches?
Does this mean that GFP_USER isn't making the buffer coherent?
Noralf.
+ ret = -EFAULT;
+ goto fail_free_sgt;
+ }
+
return xen_obj;
+fail_free_sgt:
+ sg_free_table(xen_obj->sgt);
+ xen_obj->sgt = NULL;
+fail_put_pages:
+ drm_gem_put_pages(_obj->base, xen_obj->pages, true, false);
+ xen_obj->pages = NULL;
fail:
DRM_ERROR("Failed to allocate buffer with size %zu\n", size);
return ERR_PTR(ret);
@@ -149,7 +186,7 @@ void xen_drm_front_gem_free_object_unlocked(struct
drm_gem_object *gem_obj)
struct xen_gem_object *xen_obj = to_xen_gem_obj(gem_obj);
if (xen_obj->base.import_attach) {
- drm_prime_gem_destroy(_obj->base, xen_obj->sgt_imported);
+ drm_prime_gem_destroy(_obj->base, xen_obj->sgt);
gem_free_pages_array(xen_obj);
} else {
if (xen_obj->pages) {
@@ -158,6 +195,13 @@ void xen_drm_front_gem_free_object_unlocked(struct
drm_gem_object *gem_obj)
xen_obj->pages);
gem_free_pages_array(xen_obj);
} else {
+ if (xen_obj->sgt) {
+ dma_unmap_sg(xen_obj->base.dev->dev,
+xen_obj->sgt->sgl,
+xen_obj->sgt->nents,
+DMA_BIDIRECTIONAL);
+ sg_free_table(xen_obj->sgt);
+ }
Re: [PATCH 0/1] drm/i915: Enable fastset by default, except on initial modeset
On Tue, Dec 18, 2018 at 05:07:34PM +0100, Hans de Goede wrote: > Hi, > > On 17-12-18 19:43, Rodrigo Vivi wrote: > > On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote: > > > Hi All, > > > > > > As discussed a while ago, I would like to see us enable fastboot by > > > default, starting with Skylake / GEN9 and newer hardware, so that we can > > > avoid an unnecessary modeset at boot and move to a truely flickerfree > > > boot. > > > > > > During our previous discussion about this Maarten mentioned that a first > > > step would be to get this patch from him upstream. So I'm hereby > > > resubmitting it, with a small fix. Hopefully the CI will like it better > > > this time (if not we will need to investigate) and once this passes CI > > > I hope this can be reviewed quickly and we can get this upstream. > > > > I honestly believe the first step is to make sure FBC, PSR, DRRS features > > > gets enabled somehow with fastboot. > > That is a good point, FBC will already be enabled on a fastboot as > intel_update_crtc does: > > if (new_plane_state) > intel_fbc_enable(intel_crtc, pipe_config, new_plane_state); oh cool! > > Independent of need_modeset() returning true. > > PSR indeed stays off, even if i915.enable_psr=1 is passed on the kernel > commandline. I've just completed writing a patch-set (2 patches) fixing > this. I will submit these upstream soon. cool, thanks! > > DRRS seems to be the same as PSR (I don't have hw to test) I will also > submit 2 patches building on top of the previous 2 which should fix this, > we already allow runtime enabling/disabling through i915_drrs_ctl in > debugfs, so these 2 patches should be fine. yeap, I think so > > > > Maybe DSC as well?! > > DSC? : VESA's Display Stream Compression > > [hans@shalem linux]$ grep -r dsc drivers/gpu/drm/i915 > [hans@shalem linux]$ *** intel_ddi.c: intel_ddi_pre_enable_dp[3211] intel_dsc_enable(encoder, crtc_state); *** intel_vdsc.c: intel_dsc_enable[1018] void intel_dsc_enable(struct intel_encoder *encoder, > > > Right now as I can remember FBC, PSR, and DRRS will get disabled if fastboot > > is used because we just enable those when enabling the pipe. > > You're right for PSR and DRRS, as Maarten just found out FBC has the > opposite problem, we don't turn it off on a fastset when it was enabled and we > decide it should no longer be enabled. > > Regards, > > Hans > Thanks a lot for this work, Rodrigo. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
