[PATCH] drm/ttm: remove TTM_MEMTYPE_FLAG_CMA
The original intention was to avoid CPU page table unmaps
when BOs move between the GTT and SYSTEM domain.
The problem is that this never correctly handled changes
in the caching attributes or backing pages.
Just drop this for now and simply unmap the CPU page
tables in all cases.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +--
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 34 --
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
include/drm/ttm/ttm_bo_driver.h| 1 -
6 files changed, 11 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 9c0f12f74af9..44fa8bc49d18 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -93,7 +93,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
man->func = &amdgpu_gtt_mgr_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
+ man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
@@ -108,7 +108,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
+ man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
break;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index a1037478fa3f..7883341f8c83 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -695,8 +695,7 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
} else {
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE |
-TTM_MEMTYPE_FLAG_CMA;
+ man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 73085523fad7..54af06df865b 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
man->func = &ttm_bo_manager_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
+ man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
#if IS_ENABLED(CONFIG_AGP)
if (rdev->flags & RADEON_IS_AGP) {
if (!rdev->ddev->agp) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8b9e7f62bea7..0768a054a916 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -272,20 +272,15 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
struct ttm_operation_ctx *ctx)
{
struct ttm_bo_device *bdev = bo->bdev;
- bool old_is_pci = ttm_mem_reg_is_pci(bdev, &bo->mem);
- bool new_is_pci = ttm_mem_reg_is_pci(bdev, mem);
struct ttm_mem_type_manager *old_man = &bdev->man[bo->mem.mem_type];
struct ttm_mem_type_manager *new_man = &bdev->man[mem->mem_type];
- int ret = 0;
+ int ret;
- if (old_is_pci || new_is_pci ||
- ((mem->placement & bo->mem.placement & TTM_PL_MASK_CACHING) == 0)) {
- ret = ttm_mem_io_lock(old_man, true);
- if (unlikely(ret != 0))
- goto out_err;
- ttm_bo_unmap_virtual_locked(bo);
- ttm_mem_io_unlock(old_man);
- }
+ ret = ttm_mem_io_lock(old_man, true);
+ if (unlikely(ret != 0))
+ goto out_err;
+ ttm_bo_unmap_virtual_locked(bo);
+ ttm_mem_io_unlock(old_man);
/*
* Create and bind a ttm if required.
@@ -1698,23 +1693,6 @@ EXPORT_SYMBOL(ttm_bo_device_init);
* buffer object vm functions.
*/
-bool ttm_mem_reg_is_pci(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
-{
- struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
-
- if (!(man
Re: [PATCH 1/5] dt-bindings: display: panel-dpi: Add bits-per-color property
On Thu, Jul 16, 2020 at 4:00 PM Maxime Ripard wrote: > > On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote: > > From: Chen-Yu Tsai > > > > Some LCD panels do not support 24-bit true color, or 8bits per channel > > RGB. Many low end ones only support up to 6 bits per channel natively. > > > > Add a device tree property to describe the native bit depth of the > > panel. This is separate from the bus width or format of the connection > > to the display output. > > > > Signed-off-by: Chen-Yu Tsai > > --- > > .../devicetree/bindings/display/panel/panel-dpi.yaml | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > index 0cd74c8dab42..8eb013fb1969 100644 > > --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > @@ -26,6 +26,9 @@ properties: > >height-mm: true > >label: true > >panel-timing: true > > + bits-per-color: > > +description: > > + Shall contain an integer describing the number of bits per color. > > You should specify its type (u32), range (1-8 I guess?) and default > value (which seems to be 8). Ok. > Also, it's not unusual to have a different number of bits per color, > like for 16 bits panels where we usually use RGB565. I guess we could > make that an array? So for different number of bits per color, I'm not sure whether that's a function of the panel itself, or the bus format. I don't really have any 16-bit panels on hand. As it stands DRM only handles a common color depth. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] ARM: dts: sun7i: Add MSI Primo73 tablet
On Thu, Jul 16, 2020 at 4:04 PM Maxime Ripard wrote:
>
> Hi,
>
> On Tue, Jul 14, 2020 at 03:13:05PM +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai
> >
> > The Primo73 is an MSI branded Allwinner A20-based 7-inch tablet. It has
> > a metal back case with a plastic insert around where the WiFi antenna is.
> > The tablet is (as of July of 2020) no longer available from retailers.
> > Kernel sources (as required by GPL) are no longer available from the
> > vendor, MSI. The device support page still lists the link, but it is
> > dead.
> >
> > The tablet features a non-identifiable 1024x600 7" MIPI DPI TFT panel,
> > Goodix GT911-based capacitive touchscreen, 1GB DRAM, 8GB MLC NAND,
> > RTL8188ETV-based WiFi, an NXP MMA8452 accelerometer for orientation,
> > a GC2035 2 megapixel rear camera, a GC0308 0.3 megapixel front camera,
> > a mini-HDMI output, a micro-USB port, a headphone jack and single speaker.
> >
> > The board design is believe to follow Allwinner's reference design. This
> > judgement is based on the fact that the I/O pins and GPIO lines used
> > match up with the reference design. Assumptions about the regulator tree
> > are based on this.
> >
> > The LCD panel only has some serial number markings, and what appears to
> > be a part number: "OS1N71J003", which is also a prefix for one of the
> > serial number markings. Searching for this part number yielded no
> > results. As such, the color depth display timings are directly listed
> > in the device tree. The timing are from the FEX file recovered from the
> > device. The color depth was derived from the dithering setting from the
> > FEX file, as well as independent testing with a color gradient image.
> > The internal board, as well as the ribbon cable for the panel, route the
> > full 24 bits of color. So the 2 extra bits are dropped either by the
> > panel itself or somewhere within the LCD panel module casing.
> >
> > Add a device tree for this tablet. Almost the whole device is supported.
> > The only things missing are the two cameras, which don't have device
> > tree bindings or driver support. The vendor for the LCD panel is left
> > out, since there is nothing to go with.
> >
> > Signed-off-by: Chen-Yu Tsai
> > ---
> >
> > The panel-dpi binding requires a more-specific compatible string.
> > However given the vendor of the panel is unknown, I'm not sure what
> > the best course of action is here. I opted to put the part number in
> > without a vendor prefix.
>
> I guess we could just make up a comptible from the tablet name here?
> Something like msi,primo73-panel ?
That might work. On the other hand, someone might take apart theirs
and find a different panel than mine, and not realize the timings
are off. Keeping the part number would still be useful, even if we
don't have any information on it.
> > ---
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/sun7i-a20-primo73.dts | 279
> > 2 files changed, 280 insertions(+)
> > create mode 100644 arch/arm/boot/dts/sun7i-a20-primo73.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index e6a1cac0bfc7..c09cda958db5 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -1133,6 +1133,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> > sun7i-a20-orangepi-mini.dtb \
> > sun7i-a20-pcduino3.dtb \
> > sun7i-a20-pcduino3-nano.dtb \
> > + sun7i-a20-primo73.dtb \
> > sun7i-a20-wexler-tab7200.dtb \
> > sun7i-a20-wits-pro-a20-dkt.dtb
> > dtb-$(CONFIG_MACH_SUN8I) += \
> > diff --git a/arch/arm/boot/dts/sun7i-a20-primo73.dts
> > b/arch/arm/boot/dts/sun7i-a20-primo73.dts
> > new file mode 100644
> > index ..f3b1002ceb50
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun7i-a20-primo73.dts
> > @@ -0,0 +1,279 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright (C) 2020 Chen-Yu Tsai
> > + */
> > +
> > +/dts-v1/;
> > +#include "sun7i-a20.dtsi"
> > +#include "sunxi-common-regulators.dtsi"
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/{
> > + model = "MSI Primo73 Tablet";
> > + compatible = "msi,primo73", "allwinner,sun7i-a20";
> > +
> > + aliases {
> > + serial0 = &uart0;
> > + };
> > +
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
> > + enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + hdmi-connector {
> > + compatible = "hdmi-connector";
> > + type = "b";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint = <&hdmi_out_con>;
> > + };
> > + };
> > + };
> > +
> > + panel: panel {
> > +
Re: [PATCH 0/8] drm/mgag200: Support desktop chips
Dave Airlie writes: > On Thu, 16 Jul 2020 at 00:59, Thomas Zimmermann wrote: > > > > This patchset puts device initialization in the correct order and > > adds support for G200 Desktop chips (PCI ids 0x520 and 0x521). > > why? :-) > > I'm pretty sure I NAKed the previous version because the userspace > experience for these old cards was probably better with > xorg-x11-drv-mga, but hey maybe it isn't anymore and we should go > ahead. I know SuSE use these for testing, but apart from that do we > really think we have any users for this? > The reason I had added this was to enable me to test the basic functionality of this driver with a test box at my desk rather than having to rely on some remote screen setup to some server half way around the world ;) And I'm actually not sure if the user experience with this card with the xorg-x11-drv-mga is as good as it used to be in its prime time days. Cheers, Egbert. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #67 from Anthony Ruhier (anthony.ruh...@gmail.com) --- No freeze for me too, and I compiled firefox yesterday, which usually triggers a freeze on 5.7, and nothing yet. That's some really good news if it stays true, thanks a lot Duncan! FYI, I applied the revert on 5.7.8, I didn't want to run on 5.8. -- 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] drm/nouveau: add the missed kfree() for nouveau_bo_alloc()
> … to fix it.
I suggest to replace this wording by the tag “Fixes”.
…
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -276,8 +276,10 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size,
> int *align, u32 flags,
> break;
> }
>
> - if (WARN_ON(pi < 0))
> + if (WARN_ON(pi < 0)) {
> + kfree(nvbo);
> return ERR_PTR(-EINVAL);
> + }
I propose to move such common exception handling to the end of
this function implementation so that a bit of duplicate code will be avoided.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=e9919e11e219eaa5e8041b7b1a196839143e9125#n481
Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/adreno: fix gpu probe if no interconnect-names
On 7/15/20 2:29 PM, Rob Clark wrote:
From: Rob Clark
If there is no interconnect-names, but there is an interconnects
property, then of_icc_get(dev, "gfx-mem"); would return an error
rather than NULL.
Also, if there is no interconnect-names property, there will never
be a ocmem path. But of_icc_get(dev, "ocmem") would return -EINVAL
instead of -ENODATA. Just don't bother trying in this case.
Fixes: 8e29fb37b301 ("drm/msm: handle for EPROBE_DEFER for of_icc_get")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 0527e85184e1..c4ac998b90c8 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -979,6 +979,7 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
struct adreno_platform_config *config = dev->platform_data;
struct msm_gpu_config adreno_gpu_config = { 0 };
struct msm_gpu *gpu = &adreno_gpu->base;
+ bool has_interconnect_names = true;
int ret;
adreno_gpu->funcs = funcs;
@@ -1005,12 +1006,13 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
/* Check for an interconnect path for the bus */
gpu->icc_path = of_icc_get(dev, "gfx-mem");
- if (!gpu->icc_path) {
+ if (IS_ERR_OR_NULL(gpu->icc_path)) {
/*
* Keep compatbility with device trees that don't have an
* interconnect-names property.
*/
gpu->icc_path = of_icc_get(dev, NULL);
This is misleading because if it gets a EPROBE_DEFER error (or any other
error), it will hit this path. Maybe there's a specific error you can
check for instead to identify the "no-interconnect-names" case?
Also don't think its a good idea to be calling of_icc_get(dev, NULL)
again when there's a EPROBE_DEFER, the interconnect driver could come up
between the two calls
+ has_interconnect_names = false;
}
if (IS_ERR(gpu->icc_path)) {
ret = PTR_ERR(gpu->icc_path);
@@ -1018,7 +1020,9 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
return ret;
}
- gpu->ocmem_icc_path = of_icc_get(dev, "ocmem");
+ if (has_interconnect_names)
+ gpu->ocmem_icc_path = of_icc_get(dev, "ocmem");
+
if (IS_ERR(gpu->ocmem_icc_path)) {
ret = PTR_ERR(gpu->ocmem_icc_path);
gpu->ocmem_icc_path = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
On 2020/07/15 20:17, Tetsuo Handa wrote:
> On 2020/07/15 18:48, Dan Carpenter wrote:
>>> @@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc,
>>> struct fb_info *info,
>>> region.color = color;
>>> region.rop = ROP_COPY;
>>>
>>> - if (rw && !bottom_only) {
>>> + if ((int) rw > 0 && !bottom_only) {
>>> region.dx = info->var.xoffset + rs;
>> ^^
>>
>> If you choose a very high positive "rw" then this addition can overflow.
>> info->var.xoffset comes from the user and I don't think it's checked...
>
> Well, I think it would be checked by "struct fb_ops"->check_var hook.
> For example, vmw_fb_check_var() has
>
> if ((var->xoffset + var->xres) > par->max_width ||
> (var->yoffset + var->yres) > par->max_height) {
> DRM_ERROR("Requested geom can not fit in framebuffer\n");
> return -EINVAL;
> }
>
> check. Of course, there might be integer overflow in that check...
> Having sanity check at caller of "struct fb_ops"->check_var might be nice.
>
Well, while
const int fd = open("/dev/fb0", O_ACCMODE);
struct fb_var_screeninfo var = { };
ioctl(fd, FBIOGET_VSCREENINFO, &var);
var.xres = var.yres = 4;
var.xoffset = 4294967292U;
ioctl(fd, FBIOPUT_VSCREENINFO, &var);
bypassed
(var->xoffset + var->xres) > par->max_width
check in vmw_fb_check_var(),
--
--- a/drivers/video/fbdev/core/bitblit.c
+++ b/drivers/video/fbdev/core/bitblit.c
@@ -216,6 +216,7 @@ static void bit_clear_margins(struct vc_data *vc, struct
fb_info *info,
region.color = color;
region.rop = ROP_COPY;
+ printk(KERN_INFO "%s info->var.xoffset=%u rs=%u info->var.yoffset=%u
bs=%u\n", __func__, info->var.xoffset, rs, info->var.yoffset, bs);
if ((int) rw > 0 && !bottom_only) {
region.dx = info->var.xoffset + rs;
region.dy = 0;
--
says that info->var.xoffset does not come from the user.
--
bit_clear_margins info->var.xoffset=0 rs=1024 info->var.yoffset=0 bs=800
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
On 2020/07/15 18:48, Dan Carpenter wrote:
>> @@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc, struct
>> fb_info *info,
>> region.color = color;
>> region.rop = ROP_COPY;
>>
>> -if (rw && !bottom_only) {
>> +if ((int) rw > 0 && !bottom_only) {
>> region.dx = info->var.xoffset + rs;
> ^^
>
> If you choose a very high positive "rw" then this addition can overflow.
> info->var.xoffset comes from the user and I don't think it's checked...
Well, I think it would be checked by "struct fb_ops"->check_var hook.
For example, vmw_fb_check_var() has
if ((var->xoffset + var->xres) > par->max_width ||
(var->yoffset + var->yres) > par->max_height) {
DRM_ERROR("Requested geom can not fit in framebuffer\n");
return -EINVAL;
}
check. Of course, there might be integer overflow in that check...
Having sanity check at caller of "struct fb_ops"->check_var might be nice.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state
Clang warns:
drivers/gpu/drm/i915/display/intel_combo_phy.c:268:3: warning: variable
'ret' is uninitialized when used here [-Wuninitialized]
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
^~~
drivers/gpu/drm/i915/display/intel_combo_phy.c:261:10: note: initialize
the variable 'ret' to silence this warning
bool ret;
^
= 0
1 warning generated.
In practice, the bug this warning appears to be concerned with would not
actually matter because ret gets initialized to the return value of
cnl_verify_procmon_ref_values. However, that does appear to be a bug
since it means the first hunk of the patch this fixes won't actually do
anything (since the values of check_phy_reg won't factor into the final
ret value). Initialize ret to true then make all of the assignments a
bitwise AND with itself so that the function always does what it should
do.
Fixes: 239bef676d8e ("drm/i915/display: Implement new combo phy initialization
step")
Link: https://github.com/ClangBuiltLinux/linux/issues/1094
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index eccaa79cb4a9..a4b8aa6d0a9e 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -258,7 +258,7 @@ static bool phy_is_master(struct drm_i915_private
*dev_priv, enum phy phy)
static bool icl_combo_phy_verify_state(struct drm_i915_private *dev_priv,
enum phy phy)
{
- bool ret;
+ bool ret = true;
u32 expected_val = 0;
if (!icl_combo_phy_enabled(dev_priv, phy))
@@ -276,7 +276,7 @@ static bool icl_combo_phy_verify_state(struct
drm_i915_private *dev_priv,
DCC_MODE_SELECT_CONTINUOSLY);
}
- ret = cnl_verify_procmon_ref_values(dev_priv, phy);
+ ret &= cnl_verify_procmon_ref_values(dev_priv, phy);
if (phy_is_master(dev_priv, phy)) {
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
base-commit: ca0e494af5edb59002665bf12871e94b4163a257
--
2.28.0.rc0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: remove redundant assignment to variable 'ret'
The variable ret has been assigned the value '-EINVAL'. The assignment
in the if() is redundant. We can remove it.
Signed-off-by: Jing Xiangfeng
---
drivers/gpu/drm/drm_auth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 800ac39f3213..6e1b502f2797 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -299,7 +299,6 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
if (file_priv->master->lessor != NULL) {
DRM_DEBUG_LEASE("Attempt to drop lessee %d as master\n",
file_priv->master->lessee_id);
- ret = -EINVAL;
goto out_unlock;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/6] Generic USB Display driver
On Tue, Jul 14, 2020 at 09:03:14PM +0200, Noralf Trønnes wrote: > > > Den 14.07.2020 19.40, skrev Peter Stuge: > > Hi Noralf, > > > > Noralf Trønnes wrote: > >> I would like to keep the SET_BUFFER request since it will serve as a > >> syncing point between the host and the device. I'm no USB expert but I > >> assume that a bulk transfer can fail halfway through and result in the > >> next update starting where the previous one failed and thus writing > >> beyond the end of the display buffer. > > > > Transfers either succeed completely (possibly after many retries), > > time out (after zero or more transfered bytes) or fail catastrophically > > (e.g. from device disconnect). > > > > In all cases, the driver on the host knows/has available how many bytes > > were successfully transfered. > > > > I was thinking about the device, that it could get out of sync. Let's > say the host sends a 1k framebuffer and half of it gets transferred and > the rest fails for some reason. Lubomir's MCU implementation has an > endpoint max size of 64 bytes and a callback is called for each packet. Note that 64 bytes was chosen totally arbitrarily, without any thought. Perhaps the full frame of 1024 bytes would work just fine. I'm not familiar with USB at all. > If the 1k transfer fails at some point, will the device be able to > detect this and know that the next time the rx callback is called that > this is the start of a new framebuffer update? > > Noralf. Lubo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: remove redundant assignment to variable 'ret'
On 2020/7/15 20:05, Daniel Vetter wrote:
On Wed, Jul 15, 2020 at 03:05:59PM +0800, Jing Xiangfeng wrote:
The variable ret has been assigned the value '-EINVAL'. The assignment
in the if() is redundant. We can remove it.
Nope, that's not correct. Before this assignement ret is guaranteed to be
0.
Before this assignment ret is '-EINVAL'(see commit 45bc3d26c95a: "drm:
rework SET_MASTER and DROP_MASTER perm handling"). It is set to 0 above
around the drm_drop_master() calls.
Thanks
-Daniel
Signed-off-by: Jing Xiangfeng
---
drivers/gpu/drm/drm_auth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 800ac39f3213..6e1b502f2797 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -299,7 +299,6 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
if (file_priv->master->lessor != NULL) {
DRM_DEBUG_LEASE("Attempt to drop lessee %d as master\n",
file_priv->master->lessee_id);
- ret = -EINVAL;
goto out_unlock;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: add the missed kfree() for nouveau_bo_alloc()
nouveau_bo_alloc() misses to call kfree() in an error path. Add the
missed function call to fix it.
Signed-off-by: Jing Xiangfeng
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index c40f127de3d0..abd80b1a6de3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -276,8 +276,10 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 flags,
break;
}
- if (WARN_ON(pi < 0))
+ if (WARN_ON(pi < 0)) {
+ kfree(nvbo);
return ERR_PTR(-EINVAL);
+ }
/* Disable compression if suitable settings couldn't be found. */
if (nvbo->comp && !vmm->page[pi].comp) {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
On 2020/07/16 0:12, Dan Carpenter wrote: > I've complained about integer overflows in fbdev for a long time... > > What I'd like to see is something like the following maybe. I don't > know how to get the vc_data in fbmem.c so it doesn't include your checks > for negative. Yes. Like I said "Thus, I consider that we need more sanity/constraints checks." at https://lore.kernel.org/lkml/b1e7dd6a-fc22-bba8-0abb-d3e779329...@i-love.sakura.ne.jp/ , we want basic checks. That's a task for fbdev people who should be familiar with necessary constraints. Anyway, my two patches are small and low cost; can we apply these patches regardless of basic checks? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote: > On 2020/07/16 0:12, Dan Carpenter wrote: > > I've complained about integer overflows in fbdev for a long time... > > > > What I'd like to see is something like the following maybe. I don't > > know how to get the vc_data in fbmem.c so it doesn't include your checks > > for negative. > > Yes. Like I said "Thus, I consider that we need more sanity/constraints > checks." at > https://lore.kernel.org/lkml/b1e7dd6a-fc22-bba8-0abb-d3e779329...@i-love.sakura.ne.jp/ > , > we want basic checks. That's a task for fbdev people who should be familiar > with > necessary constraints. I think the worldwide supply of people who understand fbdev and willing to work on it is roughly 0. So if someone wants to fix this mess properly (which likely means adding tons of over/underflow checks at entry points, since you're never going to catch the driver bugs, there's too many and not enough people who care) they need to fix this themselves. Just to avoid confusion here. > Anyway, my two patches are small and low cost; can we apply these patches > regardless > of basic checks? Which two patches where? Cheers, Daniel -- 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
Re: [PATCH] drm: remove redundant assignment to variable 'ret'
On Thu, Jul 16, 2020 at 09:59:38AM +0800, Jing Xiangfeng wrote:
>
>
> On 2020/7/15 20:05, Daniel Vetter wrote:
> > On Wed, Jul 15, 2020 at 03:05:59PM +0800, Jing Xiangfeng wrote:
> > > The variable ret has been assigned the value '-EINVAL'. The assignment
> > > in the if() is redundant. We can remove it.
> >
> > Nope, that's not correct. Before this assignement ret is guaranteed to be
> > 0.
>
> Before this assignment ret is '-EINVAL'(see commit 45bc3d26c95a: "drm:
> rework SET_MASTER and DROP_MASTER perm handling"). It is set to 0 above
> around the drm_drop_master() calls.
Ah indeed, but it got fixed already in
commit 264ddd077c72092178153fc32d510dcecff32eeb
Author: Emil Velikov
Date: Sat May 30 13:46:40 2020 +0100
drm/auth: make drm_{set,drop}master_ioctl symmetrical
That's why your patch didn't make any sense to me.
-Daniel
>
> Thanks
> > -Daniel
> >
> > >
> > > Signed-off-by: Jing Xiangfeng
> > > ---
> > > drivers/gpu/drm/drm_auth.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> > > index 800ac39f3213..6e1b502f2797 100644
> > > --- a/drivers/gpu/drm/drm_auth.c
> > > +++ b/drivers/gpu/drm/drm_auth.c
> > > @@ -299,7 +299,6 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void
> > > *data,
> > >
> > > if (file_priv->master->lessor != NULL) {
> > > DRM_DEBUG_LEASE("Attempt to drop lessee %d as
> > > master\n", file_priv->master->lessee_id);
> > > - ret = -EINVAL;
> > > goto out_unlock;
> > > }
> > >
> > > --
> > > 2.17.1
> > >
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #68 from Stratos Zolotas (str...@gmail.com) --- (In reply to Stratos Zolotas from comment #60) > > To make things looks more strange... I have a non-explicable development > with this issue. When it appeared to me I was in the middle of upgrading > some components on my system. I replaced my AMD FX-8350 with one AMD Ryzen 5 > 3600X and my Gigabyte GA-970a-ds3p motherboard with one Gigabyte X570 UD > (along with new RAM dimms from 16GB to 32GB). RX580 stayed the same and also > OS is the same (disks moved to the new motherboard, no re-install). Guess > what... running with 5.7.7 for 48 hours now without issues problem has > disappeared. I suspect a very rare combination of things maybe even not in > the amdgpu driver itself... With 5.7.7 on my "old" configuration, I had the > crash almost immediately after login like in the above comment. Just to report that got the issue after some days with my new hardware setup, so it is still there, hope you guys pinpoint it soon! -- 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 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #69 from Anthony Ruhier (anthony.ruh...@gmail.com) --- (In reply to Stratos Zolotas from comment #68) > (In reply to Stratos Zolotas from comment #60) > > > > To make things looks more strange... I have a non-explicable development > > with this issue. When it appeared to me I was in the middle of upgrading > > some components on my system. I replaced my AMD FX-8350 with one AMD Ryzen > 5 > > 3600X and my Gigabyte GA-970a-ds3p motherboard with one Gigabyte X570 UD > > (along with new RAM dimms from 16GB to 32GB). RX580 stayed the same and > also > > OS is the same (disks moved to the new motherboard, no re-install). Guess > > what... running with 5.7.7 for 48 hours now without issues problem has > > disappeared. I suspect a very rare combination of things maybe even not in > > the amdgpu driver itself... With 5.7.7 on my "old" configuration, I had the > > crash almost immediately after login like in the above comment. > > Just to report that got the issue after some days with my new hardware > setup, so it is still there, hope you guys pinpoint it soon! You're talking about having the bug with 5.7.7 vanilla, right? Not with the revert of the commits quoted above? -- 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 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #70 from Stratos Zolotas (str...@gmail.com) --- (In reply to Anthony Ruhier from comment #69) > > You're talking about having the bug with 5.7.7 vanilla, right? Not with the > revert of the commits quoted above? Yes! It seemed to had "disappeared" with the change on hardware but probably it took a little to appear. I'm on vanilla kernel correct. -- 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 1/6] drm/vram-helper: Managed vram helpers
Hi Sam
Am 08.07.20 um 19:19 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Wed, Jul 08, 2020 at 09:49:07AM +0200, Thomas Zimmermann wrote:
>> Calling drmm_vram_helper_alloc_mm() sets up a managed instance of
>> VRAM MM. Releasing the DRM device also frees the memory manager.
>>
>> The patch also updates the DRM documentation for VRAM helpers. The
>> tutorial now only describes the new managed interface. The older
>> interfaces are deprecated and should not be used in new code.
>>
>> Signed-off-by: Thomas Zimmermann
>
> A couple of comments...
These are all good points. I'll fix them in the next revision.
Best regards
Thomas
>
>
>
>> ---
>> drivers/gpu/drm/drm_gem_vram_helper.c | 68 ---
>> include/drm/drm_gem_vram_helper.h | 4 ++
>> 2 files changed, 55 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>> b/drivers/gpu/drm/drm_gem_vram_helper.c
>> index ad096600d89f..af116999b193 100644
>> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
>> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>> @@ -10,6 +10,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -41,7 +42,7 @@ static const struct drm_gem_object_funcs
>> drm_gem_vram_object_funcs;
>> * left in VRAM, inactive GEM objects can be moved to system memory.
>> *
>> * The easiest way to use the VRAM helper library is to call
>> - * drm_vram_helper_alloc_mm(). The function allocates and initializes an
>> + * drmm_vram_helper_alloc_mm(). The function allocates and initializes an
>> * instance of &struct drm_vram_mm in &struct drm_device.vram_mm . Use
>> * &DRM_GEM_VRAM_DRIVER to initialize &struct drm_driver and
>> * &DRM_VRAM_MM_FILE_OPERATIONS to initialize &struct file_operations;
>> @@ -69,7 +70,7 @@ static const struct drm_gem_object_funcs
>> drm_gem_vram_object_funcs;
>> * // setup device, vram base and size
>> * // ...
>> *
>> - * ret = drm_vram_helper_alloc_mm(dev, vram_base, vram_size);
>> + * ret = drmm_vram_helper_alloc_mm(dev, vram_base, vram_size);
>> * if (ret)
>> * return ret;
> This example is how this should be done - but we are not there yet..
> See below.
>
>> * return 0;
>> @@ -81,20 +82,12 @@ static const struct drm_gem_object_funcs
>> drm_gem_vram_object_funcs;
>> * manages an area of video RAM with VRAM MM and provides GEM VRAM objects
>> * to userspace.
>> *
>> - * To clean up the VRAM memory management, call drm_vram_helper_release_mm()
>> - * in the driver's clean-up code.
>> + * You don't have to clean up the instance of VRAM MM.
>> + * drmm_vram_helper_alloc_mm() is a managed interface that installs a
>> + * clean-up handler to run during the DRM device's release.
>> *
>> - * .. code-block:: c
>> - *
>> - * void fini_drm_driver()
>> - * {
>> - * struct drm_device *dev = ...;
>> - *
>> - * drm_vram_helper_release_mm(dev);
>> - * }
>> - *
>> - * For drawing or scanout operations, buffer object have to be pinned in
>> video
>> - * RAM. Call drm_gem_vram_pin() with &DRM_GEM_VRAM_PL_FLAG_VRAM or
>> + * For drawing or scanout operations, rsp. buffer objects have to be pinned
>> + * in video RAM. Call drm_gem_vram_pin() with &DRM_GEM_VRAM_PL_FLAG_VRAM or
>> * &DRM_GEM_VRAM_PL_FLAG_SYSTEM to pin a buffer object in video RAM or
>> system
>> * memory. Call drm_gem_vram_unpin() to release the pinned object
>> afterwards.
>> *
>> @@ -1177,12 +1170,16 @@ static void drm_vram_mm_cleanup(struct drm_vram_mm
>> *vmm)
>> */
>>
>> /**
>> - * drm_vram_helper_alloc_mm - Allocates a device's instance of \
>> -&struct drm_vram_mm
>> + * drm_vram_helper_alloc_mm - Allocates a device's instance of
>> + *&struct drm_vram_mm
>> * @dev:the DRM device
>> * @vram_base: the base address of the video memory
>> * @vram_size: the size of the video memory in bytes
>> *
>> + * The driver is responsible to clean-up the VRAM manager during
>> + * device cleanup by calling drm_vram_helper_release_mm(). Use
>> + * drmm_vram_helper_alloc_mm() if possible.
>> + *
>> * Returns:
>> * The new instance of &struct drm_vram_mm on success, or
>> * an ERR_PTR()-encoded errno code otherwise.
> drm_vram_helper_alloc_mm is deprecated so just delete the kernel-doc.
> We do not want kernel-doc of deprecated functions.
>
>
>> @@ -1228,6 +1225,43 @@ void drm_vram_helper_release_mm(struct drm_device
>> *dev)
>> }
>> EXPORT_SYMBOL(drm_vram_helper_release_mm);
>>
>> +static void drm_vram_mm_release(struct drm_device *dev, void *ptr)
>> +{
>> +drm_vram_helper_release_mm(dev);
>> +}
>> +
>> +/**
>> + * drmm_vram_helper_alloc_mm - Allocates a device's managed instance of
>> + * &struct drm_vram_mm
>> + * @dev:the DRM device
>> + * @vram_base: the base address of the video memory
>> + * @vram_size: the size of the video me
[PULL] drm-misc-next
drm-misc-next-2020-07-16:
drm-misc-next for v5.9:
UAPI Changes:
Cross-subsystem Changes:
- Add ckoenig as dma-buf maintainer.
- Revert invalid fix for dma-fence-chain, and fix selftest.
- Add fixmes to amifb about APUS support.
- Use array3_size in fbcon_prepare_logo, and struct_size() in alloc_apertures.
- Fix leaks in neofb, fb/savage and omapfb.
- Other small fixes to fb code.
- Convert some dt bindings to schema for some panels, and fix
simple-framebuffer dt example.
Core Changes:
- Add DRM_FORMAT_MOD_GENERIC_16_16_TILE as alias to
DRM_FORMAT_MOD_SAMSUNG_16_16_TILE,
as it can be used more generic.
- Add support for multiple DispID extension blocks in edid.
- Use https instead of http for some of the urls.
- Use drm_* macros for logging in mipi-dsi and fb-helper.
- Further cleanup ttm_mem_reg handling.
- Remove duplicated words in comments.
Driver Changes:
- Use __drm_atomic_helper_crtc_reset in all atomic drivers.
- Add Amlogic Video FBC support to meson and fourcc to core.
- Refactor hisilicon's hibmc_drv_vdac.
- Create a TXP CRTC for vc4.
- Rework cursor support in ast.
- Fix runtime PM in STM.
- Allow bigger cursors in vkms.
- Cleanup sg handling in radeon and amdgpu, and stop creating dummy
gtt nodes with ttm fixed.
- Rework crtc handling in mgag200.
- Miscellaneous small fixes to meson, vgem, bridge/dw-hdmi,
panel/auo,b116xw03, panel/LG LB070WV8, lima, bridge/sil_sii8620,
virtio, tilcdc.
The following changes since commit 41752663b410c6265e24ff0570350b0b05ecdafe:
drm/debug: Expose connector VRR monitor range via debugfs (2020-06-25
15:47:14 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-07-16
for you to fetch changes up to 947fcfeac3295ff0961bb50803e0c4ae63cff65b:
drm: drm_rect.h: delete duplicated word in comment (2020-07-15 14:03:02 +0200)
Adam Ford (1):
omapfb: dss: Fix max fclk divider for omap36xx
Aditya Pakki (1):
omapfb: fix multiple reference count leaks due to pm_runtime_get_sync
Alexander A. Klimov (2):
drm/panel: Replace HTTP links with HTTPS ones
drm/bridge: Replace HTTP links with HTTPS ones
Andrey Lebedev (1):
drm/lima: Expose job_hang_limit module parameter
Antonio Borneo (1):
drm/connector: fix minor typos in comments
Bartlomiej Zolnierkiewicz (2):
video: fbdev: amifb: add FIXME about dead APUS support
video: fbdev: amifb: add FIXMEs about {put,get}_user() failures
Brian Starkey (1):
drm: drm_fourcc: Add generic alias for 16_16_TILE modifier
Chris Wilson (1):
drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset()
Christian König (5):
drm/ttm: cleanup ttm_mem_type_manager_func.get_node interface v3
drm/ttm: make TT creation purely optional v3
MAINTAINERS: Add myself as DMA-buf maintainer
drm/ttm: further cleanup ttm_mem_reg handling
drm/amdgpu: stop allocating dummy GTT nodes
Daniel Vetter (8):
drm/atomic-helper: reset vblank on crtc reset
drm/amdgpu: Use __drm_atomic_helper_crtc_reset
drm/imx: Use __drm_atomic_helper_crtc_reset
drm/mtk: Use __drm_atomic_helper_crtc_reset
drm/vc4: Use __drm_atomic_helper_crtc_reset
drm/vmwgfx: Use __drm_atomic_helper_crtc_reset
drm/tilcdc: Use standard drm_atomic_helper_commit
drm/virtio: Remove open-coded commit-tail function
Dmitry Osipenko (4):
drm/panel-simple: Correct EDT ET057090DHU connector type
drm/panel-simple: Add missing BUS descriptions for some panels
of_graph: add of_graph_is_present()
drm/of: Make drm_of_find_panel_or_bridge() to check graph's presence
Emil Velikov (3):
drm/dsi: use stack buffer in mipi_dsi_dcs_write()
drm/panel: use mipi_dsi_dcs_write_buffer where possible
drm/mipi: use dcs write for mipi_dsi_dcs_set_tear_scanline
Evgeny Novikov (4):
video: fbdev: savage: fix memory leak on error handling path in probe
video: fbdev: neofb: fix memory leak in neo_scan_monitor()
fbdev: da8xx-fb: go to proper label on error handling paths in probe
fbdev: sm712fb: set error code in probe
Gustavo A. R. Silva (2):
fbcon: Use array3_size() helper in scr_memcpyw()
fbdev/fb.h: Use struct_size() helper in kzalloc()
Harigovindan P (1):
drm/bridge: ti-sn65dsi86: ensure bridge suspend happens during PM sleep
Icenowy Zheng (1):
dt-bindings: vendor-prefixes: Add Xingbangda
Imre Deak (1):
drm/i915: Fix the old vs. new epoch counter check during hotplug detect
Jason Yan (1):
drm/zte: remove unneeded semicolon
Jitao Shi (1):
drm/panel: auo,b116xw03: fix flash backlight when power on
Laurent Pinchart (6):
dt-bindings: display: bridge: renesas,lvds: Convert binding to YAML
drm: panel: simple: Correct connector type for Starry KR070PE2T
drm: panel: simple: Correct bus format for Satoz SAT050AT40H12R2
drm
[PATCH 7/8] drm/vram-helper: stop using TTM_MEMTYPE_FLAG_MAPPABLE
The helper doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index e62a2b68fe3a..b6e4e49027aa 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1017,14 +1017,13 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
{
switch (type) {
case TTM_PL_SYSTEM:
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED |
-TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
@@ -1067,12 +1066,8 @@ static void bo_driver_move_notify(struct
ttm_buffer_object *bo,
static int bo_driver_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
{
- struct ttm_mem_type_manager *man = bdev->man + mem->mem_type;
struct drm_vram_mm *vmm = drm_vram_mm_of_bdev(bdev);
- if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
- return -EINVAL;
-
mem->bus.addr = NULL;
mem->bus.size = mem->num_pages << PAGE_SHIFT;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/vmwgfx: stop using TTM_MEMTYPE_FLAG_MAPPABLE
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 6bea7548aee0..1d78187eaba6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -742,15 +742,13 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
-
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &vmw_thp_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
@@ -762,7 +760,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
* slots as well as the bo size.
*/
man->func = &vmw_gmrid_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
@@ -789,7 +786,6 @@ static int vmw_verify_access(struct ttm_buffer_object *bo,
struct file *filp)
static int vmw_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct
ttm_mem_reg *mem)
{
- struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
struct vmw_private *dev_priv = container_of(bdev, struct vmw_private,
bdev);
mem->bus.addr = NULL;
@@ -797,8 +793,7 @@ static int vmw_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_mem_reg
mem->bus.offset = 0;
mem->bus.size = mem->num_pages << PAGE_SHIFT;
mem->bus.base = 0;
- if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
- return -EINVAL;
+
switch (mem->mem_type) {
case TTM_PL_SYSTEM:
case VMW_PL_GMR:
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/amdgpu: stop using TTM_MEMTYPE_FLAG_MAPPABLE
The driver does support some not-mapable resources, but
those are already handled correctly in the switch/case
statement in the code.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 44fa8bc49d18..0dd5e802091d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -84,7 +84,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
@@ -93,13 +93,12 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
man->func = &amdgpu_gtt_mgr_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = 0;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &amdgpu_vram_mgr_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED |
-TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
break;
@@ -796,7 +795,6 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo,
bool evict,
*/
static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct
ttm_mem_reg *mem)
{
- struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
struct amdgpu_device *adev = amdgpu_ttm_adev(bdev);
struct drm_mm_node *mm_node = mem->mm_node;
@@ -805,8 +803,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_mem_
mem->bus.size = mem->num_pages << PAGE_SHIFT;
mem->bus.base = 0;
mem->bus.is_iomem = false;
- if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
- return -EINVAL;
+
switch (mem->mem_type) {
case TTM_PL_SYSTEM:
/* system memory */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] drm/ttm: remove TTM_MEMTYPE_FLAG_CMA
The original intention was to avoid CPU page table unmaps
when BOs move between the GTT and SYSTEM domain.
The problem is that this never correctly handled changes
in the caching attributes or backing pages.
Just drop this for now and simply unmap the CPU page
tables in all cases.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +--
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 34 --
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
include/drm/ttm/ttm_bo_driver.h| 1 -
6 files changed, 11 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 9c0f12f74af9..44fa8bc49d18 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -93,7 +93,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
man->func = &amdgpu_gtt_mgr_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
+ man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
@@ -108,7 +108,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
+ man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
break;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index a1037478fa3f..7883341f8c83 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -695,8 +695,7 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
} else {
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE |
-TTM_MEMTYPE_FLAG_CMA;
+ man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 73085523fad7..54af06df865b 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
man->func = &ttm_bo_manager_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
+ man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
#if IS_ENABLED(CONFIG_AGP)
if (rdev->flags & RADEON_IS_AGP) {
if (!rdev->ddev->agp) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8b9e7f62bea7..0768a054a916 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -272,20 +272,15 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
struct ttm_operation_ctx *ctx)
{
struct ttm_bo_device *bdev = bo->bdev;
- bool old_is_pci = ttm_mem_reg_is_pci(bdev, &bo->mem);
- bool new_is_pci = ttm_mem_reg_is_pci(bdev, mem);
struct ttm_mem_type_manager *old_man = &bdev->man[bo->mem.mem_type];
struct ttm_mem_type_manager *new_man = &bdev->man[mem->mem_type];
- int ret = 0;
+ int ret;
- if (old_is_pci || new_is_pci ||
- ((mem->placement & bo->mem.placement & TTM_PL_MASK_CACHING) == 0)) {
- ret = ttm_mem_io_lock(old_man, true);
- if (unlikely(ret != 0))
- goto out_err;
- ttm_bo_unmap_virtual_locked(bo);
- ttm_mem_io_unlock(old_man);
- }
+ ret = ttm_mem_io_lock(old_man, true);
+ if (unlikely(ret != 0))
+ goto out_err;
+ ttm_bo_unmap_virtual_locked(bo);
+ ttm_mem_io_unlock(old_man);
/*
* Create and bind a ttm if required.
@@ -1698,23 +1693,6 @@ EXPORT_SYMBOL(ttm_bo_device_init);
* buffer object vm functions.
*/
-bool ttm_mem_reg_is_pci(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
-{
- struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
-
- if (!(man
[PATCH 6/8] drm/qxl: stop using TTM_MEMTYPE_FLAG_MAPPABLE
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_ttm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index a6e67149ef4a..820eb190d292 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -54,7 +54,7 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
@@ -62,8 +62,7 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_PRIV:
/* "On-card" video ram */
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED |
-TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
@@ -107,8 +106,7 @@ int qxl_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
mem->bus.size = mem->num_pages << PAGE_SHIFT;
mem->bus.base = 0;
mem->bus.is_iomem = false;
- if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
- return -EINVAL;
+
switch (mem->mem_type) {
case TTM_PL_SYSTEM:
/* system memory */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/ttm: remove TTM_MEMTYPE_FLAG_MAPPABLE
Not used any more. And it is bad design to use a TTM flag to do a check inside a driver. Signed-off-by: Christian König --- include/drm/ttm/ttm_bo_driver.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index 71b195e78c7c..9b251853afe2 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -46,7 +46,6 @@ #define TTM_MAX_BO_PRIORITY4U #define TTM_MEMTYPE_FLAG_FIXED (1 << 0)/* Fixed (on-card) PCI memory */ -#define TTM_MEMTYPE_FLAG_MAPPABLE (1 << 1)/* Memory mappable */ struct ttm_mem_type_manager; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] drm/radeon: stop using TTM_MEMTYPE_FLAG_MAPPABLE
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 54af06df865b..b474781a0920 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -76,7 +76,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
@@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
man->func = &ttm_bo_manager_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = 0;
#if IS_ENABLED(CONFIG_AGP)
if (rdev->flags & RADEON_IS_AGP) {
if (!rdev->ddev->agp) {
@@ -92,8 +92,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
(unsigned)type);
return -EINVAL;
}
- if (!rdev->ddev->agp->cant_use_aperture)
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
@@ -103,8 +101,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED |
-TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
break;
@@ -394,7 +391,6 @@ static int radeon_bo_move(struct ttm_buffer_object *bo,
bool evict,
static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct
ttm_mem_reg *mem)
{
- struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
struct radeon_device *rdev = radeon_get_rdev(bdev);
mem->bus.addr = NULL;
@@ -402,8 +398,7 @@ static int radeon_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_mem_
mem->bus.size = mem->num_pages << PAGE_SHIFT;
mem->bus.base = 0;
mem->bus.is_iomem = false;
- if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
- return -EINVAL;
+
switch (mem->mem_type) {
case TTM_PL_SYSTEM:
/* system memory */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/nouveau: stop using TTM_MEMTYPE_FLAG_MAPPABLE
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7883341f8c83..4ccf937df0d0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -655,13 +655,12 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
- man->flags = TTM_MEMTYPE_FLAG_FIXED |
-TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
@@ -690,12 +689,12 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
man->func = &ttm_bo_manager_func;
if (drm->agp.bridge) {
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = 0;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
} else {
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+ man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
}
@@ -1437,7 +1436,6 @@ nouveau_bo_verify_access(struct ttm_buffer_object *bo,
struct file *filp)
static int
nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *reg)
{
- struct ttm_mem_type_manager *man = &bdev->man[reg->mem_type];
struct nouveau_drm *drm = nouveau_bdev(bdev);
struct nvkm_device *device = nvxx_device(&drm->client.device);
struct nouveau_mem *mem = nouveau_mem(reg);
@@ -1447,8 +1445,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *reg)
reg->bus.size = reg->num_pages << PAGE_SHIFT;
reg->bus.base = 0;
reg->bus.is_iomem = false;
- if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
- return -EINVAL;
+
switch (reg->mem_type) {
case TTM_PL_SYSTEM:
/* System memory */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/6] drm/ast: Managed MM
This is the second patchset for converting ast to managed DRM interfaces.
This one addresses memory management. There will be another, final round
of patches for converting DRM device structures as well.
Patch #1 introduces managed initialization for VRAM MM. Other drivers
using the VRAM helpers should be converted to this at some point.
Patches #2 to #4 do some preparation that make ast look slightly nicer.
Patch #5 fixes a long-standing bug that I found as part of the rework.
Posting the GPU requires information about the installed DRAM. So the DRAM
detection has to run before the GPU-posting code. This got reversed by a
fix in v4.11. The patch restores the original correct order of these
operations. As the GPU is usually posted by the VGA BIOS, the problem might
not have shown up in practice.
With all the cleanups in place, patch #6 switches memory management to
mnaged interfaces.
Tested on AST2100 HW.
v2:
* reworked managed VRAM MM; new interface name, returns errno
code, improved documentation (Sam)
Thomas Zimmermann (6):
drm/vram-helper: Managed vram helpers
drm/ast: Rename ast_ttm.c to ast_mm.c
drm/ast: Use managed VRAM-helper initialization
drm/ast: Move VRAM size detection to ast_mm.c
drm/ast: Initialize DRAM type before posting GPU
drm/ast: Use managed MM initialization
drivers/gpu/drm/ast/Makefile| 2 +-
drivers/gpu/drm/ast/ast_drv.h | 2 -
drivers/gpu/drm/ast/ast_main.c | 45 ++-
drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} | 77 ++-
drivers/gpu/drm/drm_gem_vram_helper.c | 84 -
include/drm/drm_gem_vram_helper.h | 3 +
6 files changed, 115 insertions(+), 98 deletions(-)
rename drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} (63%)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] drm/ast: Move VRAM size detection to ast_mm.c
VRAM size detection is only relevant to the memory management. Move
the code into ast_mm.c.
While at it, rename the function to ast_get_vram_size(). The function
argument's type is now struct ast_private. The result is stored in a
local variable and not in struct ast_private any longer.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/drm/ast/ast_main.c | 38 ++--
drivers/gpu/drm/ast/ast_mm.c | 45 +-
3 files changed, 46 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index c8c442e9efdc..9a770e5b36d1 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -110,7 +110,6 @@ struct ast_private {
uint32_t dram_bus_width;
uint32_t dram_type;
uint32_t mclk;
- uint32_t vram_size;
int fb_mtrr;
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 860a43a64b31..b162cc82204d 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -378,38 +378,6 @@ static int ast_get_dram_info(struct drm_device *dev)
return 0;
}
-static u32 ast_get_vram_info(struct drm_device *dev)
-{
- struct ast_private *ast = to_ast_private(dev);
- u8 jreg;
- u32 vram_size;
- ast_open_key(ast);
-
- vram_size = AST_VIDMEM_DEFAULT_SIZE;
- jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xaa, 0xff);
- switch (jreg & 3) {
- case 0: vram_size = AST_VIDMEM_SIZE_8M; break;
- case 1: vram_size = AST_VIDMEM_SIZE_16M; break;
- case 2: vram_size = AST_VIDMEM_SIZE_32M; break;
- case 3: vram_size = AST_VIDMEM_SIZE_64M; break;
- }
-
- jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x99, 0xff);
- switch (jreg & 0x03) {
- case 1:
- vram_size -= 0x10;
- break;
- case 2:
- vram_size -= 0x20;
- break;
- case 3:
- vram_size -= 0x40;
- break;
- }
-
- return vram_size;
-}
-
int ast_driver_load(struct drm_device *dev, unsigned long flags)
{
struct ast_private *ast;
@@ -456,10 +424,8 @@ int ast_driver_load(struct drm_device *dev, unsigned long
flags)
ret = ast_get_dram_info(dev);
if (ret)
goto out_free;
- ast->vram_size = ast_get_vram_info(dev);
- drm_info(dev, "dram MCLK=%u Mhz type=%d bus_width=%d size=%08x\n",
-ast->mclk, ast->dram_type,
-ast->dram_bus_width, ast->vram_size);
+ drm_info(dev, "dram MCLK=%u Mhz type=%d bus_width=%d\n",
+ast->mclk, ast->dram_type, ast->dram_bus_width);
ret = ast_mm_init(ast);
if (ret)
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index f0a96cae68c9..aaeb19d01052 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -33,13 +33,56 @@
#include "ast_drv.h"
+static u32 ast_get_vram_size(struct ast_private *ast)
+{
+ u8 jreg;
+ u32 vram_size;
+
+ ast_open_key(ast);
+
+ vram_size = AST_VIDMEM_DEFAULT_SIZE;
+ jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xaa, 0xff);
+ switch (jreg & 3) {
+ case 0:
+ vram_size = AST_VIDMEM_SIZE_8M;
+ break;
+ case 1:
+ vram_size = AST_VIDMEM_SIZE_16M;
+ break;
+ case 2:
+ vram_size = AST_VIDMEM_SIZE_32M;
+ break;
+ case 3:
+ vram_size = AST_VIDMEM_SIZE_64M;
+ break;
+ }
+
+ jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x99, 0xff);
+ switch (jreg & 0x03) {
+ case 1:
+ vram_size -= 0x10;
+ break;
+ case 2:
+ vram_size -= 0x20;
+ break;
+ case 3:
+ vram_size -= 0x40;
+ break;
+ }
+
+ return vram_size;
+}
+
int ast_mm_init(struct ast_private *ast)
{
+ u32 vram_size;
int ret;
struct drm_device *dev = ast->dev;
+ vram_size = ast_get_vram_size(ast);
+
ret = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
- ast->vram_size);
+ vram_size);
if (ret) {
drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
return ret;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] drm/ast: Rename ast_ttm.c to ast_mm.c
Although built upon TTM, the ast driver's VRAM MM helper does not
expose TTM to its users. Rename the related ast file to ast_mm.c.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/Makefile| 2 +-
drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} (100%)
diff --git a/drivers/gpu/drm/ast/Makefile b/drivers/gpu/drm/ast/Makefile
index 6a5b3b247316..2265a8a624dd 100644
--- a/drivers/gpu/drm/ast/Makefile
+++ b/drivers/gpu/drm/ast/Makefile
@@ -3,7 +3,7 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-ast-y := ast_cursor.o ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o \
+ast-y := ast_cursor.o ast_drv.o ast_main.o ast_mm.o ast_mode.o ast_post.o \
ast_dp501.o
obj-$(CONFIG_DRM_AST) := ast.o
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_mm.c
similarity index 100%
rename from drivers/gpu/drm/ast/ast_ttm.c
rename to drivers/gpu/drm/ast/ast_mm.c
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] drm/ast: Use managed MM initialization
Cleaning up ast's MM code with ast_mm_fini() resets the write-combine
flags on the VRAM I/O memory. Drop ast_mm_fini() in favor of an auto-
release callback. Releasing the device also executes the callback.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/drm/ast/ast_main.c | 1 -
drivers/gpu/drm/ast/ast_mm.c | 23 ---
3 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 9a770e5b36d1..e3a264ac7ee2 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -291,7 +291,6 @@ int ast_mode_config_init(struct ast_private *ast);
#define AST_MM_ALIGN_MASK ((1 << AST_MM_ALIGN_SHIFT) - 1)
int ast_mm_init(struct ast_private *ast);
-void ast_mm_fini(struct ast_private *ast);
/* ast post */
void ast_enable_vga(struct drm_device *dev);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 87e5baded2a7..dd12b55d57a2 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -452,6 +452,5 @@ void ast_driver_unload(struct drm_device *dev)
ast_release_firmware(dev);
kfree(ast->dp501_fw_addr);
- ast_mm_fini(ast);
kfree(ast);
}
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index aaeb19d01052..9186ec3ebbe0 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -28,8 +28,9 @@
#include
-#include
#include
+#include
+#include
#include "ast_drv.h"
@@ -73,6 +74,15 @@ static u32 ast_get_vram_size(struct ast_private *ast)
return vram_size;
}
+static void ast_mm_release(struct drm_device *dev, void *ptr)
+{
+ struct ast_private *ast = to_ast_private(dev);
+
+ arch_phys_wc_del(ast->fb_mtrr);
+ arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
+ pci_resource_len(dev->pdev, 0));
+}
+
int ast_mm_init(struct ast_private *ast)
{
u32 vram_size;
@@ -93,14 +103,5 @@ int ast_mm_init(struct ast_private *ast)
ast->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
pci_resource_len(dev->pdev, 0));
- return 0;
-}
-
-void ast_mm_fini(struct ast_private *ast)
-{
- struct drm_device *dev = ast->dev;
-
- arch_phys_wc_del(ast->fb_mtrr);
- arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
- pci_resource_len(dev->pdev, 0));
+ return drmm_add_action_or_reset(dev, ast_mm_release, NULL);
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] drm/vram-helper: Managed vram helpers
Calling drmm_vram_helper_init() sets up a managed instance of
VRAM MM. Releasing the DRM device also frees the memory manager.
The patch also updates the DRM documentation for VRAM helpers. The
tutorial now describes the new managed interface. The old interfaces
are deprecated and should not be used in new code.
v2:
* rename init function to drmm_vram_helper_init()
* return errno code from init function; caller does not
need vram_mm anyway
* update documentation and remove docs for deprecated
un-managed functions
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 84 +++
include/drm/drm_gem_vram_helper.h | 3 +
2 files changed, 51 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index ad096600d89f..c96d54f7c180 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -40,12 +41,11 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs;
* the frame's scanout buffer or the cursor image. If there's no more space
* left in VRAM, inactive GEM objects can be moved to system memory.
*
- * The easiest way to use the VRAM helper library is to call
- * drm_vram_helper_alloc_mm(). The function allocates and initializes an
- * instance of &struct drm_vram_mm in &struct drm_device.vram_mm . Use
- * &DRM_GEM_VRAM_DRIVER to initialize &struct drm_driver and
- * &DRM_VRAM_MM_FILE_OPERATIONS to initialize &struct file_operations;
- * as illustrated below.
+ * To initialize the VRAM helper library call drmm_vram_helper_alloc_mm().
+ * The function allocates and initializes an instance of &struct drm_vram_mm
+ * in &struct drm_device.vram_mm . Use &DRM_GEM_VRAM_DRIVER to initialize
+ * &struct drm_driver and &DRM_VRAM_MM_FILE_OPERATIONS to initialize
+ * &struct file_operations; as illustrated below.
*
* .. code-block:: c
*
@@ -69,7 +69,7 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs;
* // setup device, vram base and size
* // ...
*
- * ret = drm_vram_helper_alloc_mm(dev, vram_base, vram_size);
+ * ret = drmm_vram_helper_alloc_mm(dev, vram_base, vram_size);
* if (ret)
* return ret;
* return 0;
@@ -81,20 +81,12 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs;
* manages an area of video RAM with VRAM MM and provides GEM VRAM objects
* to userspace.
*
- * To clean up the VRAM memory management, call drm_vram_helper_release_mm()
- * in the driver's clean-up code.
+ * You don't have to clean up the instance of VRAM MM.
+ * drmm_vram_helper_alloc_mm() is a managed interface that installs a
+ * clean-up handler to run during the DRM device's release.
*
- * .. code-block:: c
- *
- * void fini_drm_driver()
- * {
- * struct drm_device *dev = ...;
- *
- * drm_vram_helper_release_mm(dev);
- * }
- *
- * For drawing or scanout operations, buffer object have to be pinned in video
- * RAM. Call drm_gem_vram_pin() with &DRM_GEM_VRAM_PL_FLAG_VRAM or
+ * For drawing or scanout operations, rsp. buffer objects have to be pinned
+ * in video RAM. Call drm_gem_vram_pin() with &DRM_GEM_VRAM_PL_FLAG_VRAM or
* &DRM_GEM_VRAM_PL_FLAG_SYSTEM to pin a buffer object in video RAM or system
* memory. Call drm_gem_vram_unpin() to release the pinned object afterwards.
*
@@ -1176,17 +1168,7 @@ static void drm_vram_mm_cleanup(struct drm_vram_mm *vmm)
* Helpers for integration with struct drm_device
*/
-/**
- * drm_vram_helper_alloc_mm - Allocates a device's instance of \
- &struct drm_vram_mm
- * @dev: the DRM device
- * @vram_base: the base address of the video memory
- * @vram_size: the size of the video memory in bytes
- *
- * Returns:
- * The new instance of &struct drm_vram_mm on success, or
- * an ERR_PTR()-encoded errno code otherwise.
- */
+/* deprecated; use drmm_vram_mm_init() */
struct drm_vram_mm *drm_vram_helper_alloc_mm(
struct drm_device *dev, uint64_t vram_base, size_t vram_size)
{
@@ -1212,11 +1194,6 @@ struct drm_vram_mm *drm_vram_helper_alloc_mm(
}
EXPORT_SYMBOL(drm_vram_helper_alloc_mm);
-/**
- * drm_vram_helper_release_mm - Releases a device's instance of \
- &struct drm_vram_mm
- * @dev: the DRM device
- */
void drm_vram_helper_release_mm(struct drm_device *dev)
{
if (!dev->vram_mm)
@@ -1228,6 +1205,41 @@ void drm_vram_helper_release_mm(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_vram_helper_release_mm);
+static void drm_vram_mm_release(struct drm_device *dev, void *ptr)
+{
+ drm_vram_helper_release_mm(dev);
+}
+
+/**
+ * drmm_vram_helper_init - Initializes a device's instance of
+ * &struct drm_vram_mm
+ * @dev:
[PATCH v2 3/6] drm/ast: Use managed VRAM-helper initialization
As a first step to managed MM code in ast, switch over VRAM MM helpers.
v2:
* updated to use drmm_vram_helper_init()
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mm.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index 9c3788a4c1c5..f0a96cae68c9 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -35,15 +35,12 @@
int ast_mm_init(struct ast_private *ast)
{
- struct drm_vram_mm *vmm;
int ret;
struct drm_device *dev = ast->dev;
- vmm = drm_vram_helper_alloc_mm(
- dev, pci_resource_start(dev->pdev, 0),
- ast->vram_size);
- if (IS_ERR(vmm)) {
- ret = PTR_ERR(vmm);
+ ret = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
+ ast->vram_size);
+ if (ret) {
drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
return ret;
}
@@ -60,8 +57,6 @@ void ast_mm_fini(struct ast_private *ast)
{
struct drm_device *dev = ast->dev;
- drm_vram_helper_release_mm(dev);
-
arch_phys_wc_del(ast->fb_mtrr);
arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
pci_resource_len(dev->pdev, 0));
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] drm/ast: Initialize DRAM type before posting GPU
Posting the GPU requires the correct DRAM type to be stored in
struct ast_private. Therefore first initialize the DRAM info and
then post the GPU. This restores the original order of instructions
in this function.
Signed-off-by: Thomas Zimmermann
Acked-by: Benjamin Herrenschmidt
Fixes: bad09da6deab ("drm/ast: Fixed vram size incorrect issue on POWER")
Cc: Joel Stanley
Cc: Y.C. Chen
Cc: Benjamin Herrenschmidt
Cc: Dave Airlie
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Emil Velikov
Cc: "Y.C. Chen"
Cc: # v4.11+
---
drivers/gpu/drm/ast/ast_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index b162cc82204d..87e5baded2a7 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -418,15 +418,15 @@ int ast_driver_load(struct drm_device *dev, unsigned long
flags)
ast_detect_chip(dev, &need_post);
- if (need_post)
- ast_post_gpu(dev);
-
ret = ast_get_dram_info(dev);
if (ret)
goto out_free;
drm_info(dev, "dram MCLK=%u Mhz type=%d bus_width=%d\n",
ast->mclk, ast->dram_type, ast->dram_bus_width);
+ if (need_post)
+ ast_post_gpu(dev);
+
ret = ast_mm_init(ast);
if (ret)
goto out_free;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] drm/vram-helper: stop using TTM_MEMTYPE_FLAG_MAPPABLE
Am 16.07.20 um 14:50 schrieb Christian König:
> The helper doesn't expose any not-mapable memory resources.
>
> Signed-off-by: Christian König
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index e62a2b68fe3a..b6e4e49027aa 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -1017,14 +1017,13 @@ static int bo_driver_init_mem_type(struct
> ttm_bo_device *bdev, uint32_t type,
> {
> switch (type) {
> case TTM_PL_SYSTEM:
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED |
> - TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED |
>TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> @@ -1067,12 +1066,8 @@ static void bo_driver_move_notify(struct
> ttm_buffer_object *bo,
> static int bo_driver_io_mem_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *mem)
> {
> - struct ttm_mem_type_manager *man = bdev->man + mem->mem_type;
> struct drm_vram_mm *vmm = drm_vram_mm_of_bdev(bdev);
>
> - if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
> - return -EINVAL;
> -
> mem->bus.addr = NULL;
> mem->bus.size = mem->num_pages << PAGE_SHIFT;
>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/ttm: remove TTM_MEMTYPE_FLAG_CMA
Hi,
this patchset could have benefited from a cover letter.
Am 16.07.20 um 14:50 schrieb Christian König:
> The original intention was to avoid CPU page table unmaps
> when BOs move between the GTT and SYSTEM domain.
>
> The problem is that this never correctly handled changes
> in the caching attributes or backing pages.
>
> Just drop this for now and simply unmap the CPU page
> tables in all cases.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +--
> drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +-
> drivers/gpu/drm/radeon/radeon_ttm.c| 2 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 34 --
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
> include/drm/ttm/ttm_bo_driver.h| 1 -
> 6 files changed, 11 insertions(+), 35 deletions(-)
Why's CMA cleaned up in one patch and MAPPABLE in the other 7?
Wouldn't it have been better to kill both the flags from ttm in 2
patches, then have one patch per driver and finally remove both flags
from the ttm header?
Best regards
Thomas
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 9c0f12f74af9..44fa8bc49d18 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -93,7 +93,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> man->func = &amdgpu_gtt_mgr_func;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
> + man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> break;
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> @@ -108,7 +108,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> case AMDGPU_PL_OA:
> /* On-chip GDS memory*/
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
> + man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED;
> man->default_caching = TTM_PL_FLAG_UNCACHED;
> break;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index a1037478fa3f..7883341f8c83 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -695,8 +695,7 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> } else {
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE |
> - TTM_MEMTYPE_FLAG_CMA;
> + man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> }
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 73085523fad7..54af06df865b 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> man->func = &ttm_bo_manager_func;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
> + man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> #if IS_ENABLED(CONFIG_AGP)
> if (rdev->flags & RADEON_IS_AGP) {
> if (!rdev->ddev->agp) {
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8b9e7f62bea7..0768a054a916 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -272,20 +272,15 @@ static int ttm_bo_handle_move_mem(struct
> ttm_buffer_object *bo,
> struct ttm_operation_ctx *ctx)
> {
> struct ttm_bo_device *bdev = bo->bdev;
> - bool old_is_pci = ttm_mem_reg_is_pci(bdev, &bo->mem);
> - bool new_is_pci = ttm_mem_reg_is_pci(bdev, mem);
> struct ttm_mem_type_manager *old_man = &bdev->man[bo->mem.mem_type];
> struct ttm_mem_type_manager *new_man = &bdev->man[mem->mem_type];
> - int ret = 0;
> + int ret;
>
> - if (old_is_pci || new_is_pci ||
> - ((mem->placement & bo->mem.placement & TTM_PL_MASK_CACHING) == 0)) {
> - ret = ttm_mem_io_lock(old_man, true);
> - if (unlikely(ret != 0))
> - goto out_err;
> - ttm_bo_unmap_virtual_locked(bo);
> - ttm_mem_io_unlock(old_man);
> - }
> + ret = ttm_mem_io_lock(old_man, true);
> + if
Re: [PATCH v2 0/6] drm/ast: Managed MM
Hi Thomas.
On Thu, Jul 16, 2020 at 02:53:47PM +0200, Thomas Zimmermann wrote:
> This is the second patchset for converting ast to managed DRM interfaces.
> This one addresses memory management. There will be another, final round
> of patches for converting DRM device structures as well.
>
> Patch #1 introduces managed initialization for VRAM MM. Other drivers
> using the VRAM helpers should be converted to this at some point.
>
> Patches #2 to #4 do some preparation that make ast look slightly nicer.
>
> Patch #5 fixes a long-standing bug that I found as part of the rework.
> Posting the GPU requires information about the installed DRAM. So the DRAM
> detection has to run before the GPU-posting code. This got reversed by a
> fix in v4.11. The patch restores the original correct order of these
> operations. As the GPU is usually posted by the VGA BIOS, the problem might
> not have shown up in practice.
>
> With all the cleanups in place, patch #6 switches memory management to
> mnaged interfaces.
>
> Tested on AST2100 HW.
>
> v2:
> * reworked managed VRAM MM; new interface name, returns errno
> code, improved documentation (Sam)
>
> Thomas Zimmermann (6):
> drm/vram-helper: Managed vram helpers
> drm/ast: Rename ast_ttm.c to ast_mm.c
> drm/ast: Use managed VRAM-helper initialization
> drm/ast: Move VRAM size detection to ast_mm.c
> drm/ast: Initialize DRAM type before posting GPU
> drm/ast: Use managed MM initialization
Series looks good now. All patches are:
Reviewed-by: Sam Ravnborg
Sam
>
> drivers/gpu/drm/ast/Makefile| 2 +-
> drivers/gpu/drm/ast/ast_drv.h | 2 -
> drivers/gpu/drm/ast/ast_main.c | 45 ++-
> drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} | 77 ++-
> drivers/gpu/drm/drm_gem_vram_helper.c | 84 -
> include/drm/drm_gem_vram_helper.h | 3 +
> 6 files changed, 115 insertions(+), 98 deletions(-)
> rename drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} (63%)
>
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] gpu: host1x: Convert to DEFINE_SHOW_ATTRIBUTE
On Thu, Jul 16, 2020 at 05:03:23PM +0800, Qinglang Miao wrote: > From: Yongqiang Liu > > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. > > Signed-off-by: Yongqiang Liu > --- > drivers/gpu/host1x/debug.c | 28 > 1 file changed, 4 insertions(+), 24 deletions(-) This doesn't apply. Can you please resend, based on something like linux-next? Thanks, Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 00/12] PCI: brcmstb: enable PCIe for STB chips
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
v8:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- To satisfy a specific m68 compile configuration, I moved the 'struct
bus_dma_region; definition out of #ifdef CONFIG_HAS_DMA and also defined
three inline functions for !CONFIG_HAS_DMA (kernel test robot).
-- The sunXi drivers -- suc4i_csi, sun6i_csi, cedrus_hw -- set
a pfn_offset outside of_dma_configure() but the code offers no
insight on the size of the translation window. V7 had me using
SIZE_MAX as the size. I have since contacted the sunXi maintainer and
he said that using a size of SZ_4G would cover sunXi configurations.
v7:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- remove second kcalloc/copy in device.c (AndyS)
-- use PTR_ERR_OR_ZERO() and PHYS_PFN() (AndyS)
-- indentation, sizeof(struct ...) => sizeof(*r) (AndyS)
-- add pfn.h definitions: PFN_DMA_ADDR(), DMA_ADDR_PFN() (AndyS)
-- Fixed compile error in "sun6i_csi.c" (kernel test robot)
Commit "ata: ahci_brcm: Fix use of BCM7216 reset controller"
-- correct name of function in the commit msg (SergeiS)
v6:
Commit "device core: Introduce DMA range map":
-- of_dma_get_range() now takes a single argument and returns either
NULL, a valid map, or an ERR_PTR. (Robin)
-- offsets are no longer a PFN value but an actual address. (Robin)
-- the bus_dma_region struct stores the range size instead of
the cpu_end and pci_end values. (Robin)
-- devices that were setting a single offset with no boundaries
have been modified to have boundaries; in a few places
where this informatino was unavilable a /* FIXME: ... */
comment was added. (Robin)
-- dma_attach_offset_range() can be called when an offset
map already exists; if it's range is already present
nothing is done and success is returned. (Robin)
All commits:
-- Man name/style/corrections/etc changed (Bjorn)
-- rebase to Torvalds master
v5:
Commit "device core: Introduce multiple dma pfn offsets"
-- in of/address.c: "map_size = 0" => "*map_size = 0"
-- use kcalloc instead of kzalloc (AndyS)
-- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0"
Commit "PCI: brcmstb: Set internal memory viewport sizes"
-- now gives error on missing dma-ranges property.
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- removed "Allof:" from brcm,scb-sizes definition (RobH)
All Commits:
-- indentation style, use max chars 100 (AndyS)
-- rebased to torvalds master
v4:
Commit "device core: Introduce multiple dma pfn offsets"
-- of_dma_get_range() does not take a dev param but instead
takes two "out" params: map and map_size. We do this so
that the code that parses dma-ranges is separate from
the code that modifies 'dev'. (Nicolas)
-- the separate case of having a single pfn offset has
been removed and is now processed by going through the
map array. (Nicolas)
-- move attach_uniform_dma_pfn_offset() from of/address.c to
dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas)
-- devm_kcalloc => devm_kzalloc (DanC)
-- add/fix assignment to dev->dma_pfn_offset_map for func
attach_uniform_dma_pfn_offset() (DanC, Nicolas)
-- s/struct dma_pfn_offset_region/struct bus_dma_region/ (Nicolas)
-- s/attach_uniform_dma_pfn_offset/dma_attach_uniform_pfn_offset/
-- s/attach_dma_pfn_offset_map/dma_attach_pfn_offset_map/
-- More use of PFN_{PHYS,DOWN,UP}. (AndyS)
Commit "of: Include a dev param in of_dma_get_range()"
-- this commit was sqaushed with "device core: Introduce ..."
v3:
Commit "device core: Introduce multiple dma pfn offsets"
Commit "arm: dma-mapping: Invoke dma offset func if needed"
-- The above two commits have been squashed. More importantly,
the code has been modified so that the functionality for
multiple pfn offsets subsumes the use of dev->dma_pfn_offset.
In fact, dma_pfn_offset is removed and supplanted by
dma_pfn_offset_map, which is a pointer to an array. The
more common case of a uniform offset is now handled as
a map with a single entry, while cases requiring multiple
pfn offsets use a map with multiple entries. Code paths
that used to do this:
dev->dma_pfn_offset = mydrivers_pfn_offset;
have been changed to do this:
attach_uniform_dma_pfn_offset(dev, pfn_offset);
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- Add if/then clause for required props: resets, reset-names (RobH)
-- Change compatible list from const to enum (RobH)
-- Change list of u32-tuples to u64 (RobH)
Commit "of: Include a dev param in of_dma_get_range()"
-- modify of/unittests.c to add NULL param in of_dma_get_range()
[PATCH v8 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
The function of_dma_get_range() has been modified so that it takes a single
argument -- the device node -- and returns a map, NULL, or an error code.
The map is an array that holds the information regarding the DMA regions.
Each range entry contains the address offset, the cpu_start address, the
dma_start address, and the size of the region.
of_dma_configure() is the typical manner to set range offsets but there are
a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
driver code. These cases now invoke the function
dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 9 +-
arch/arm/mach-keystone/keystone.c | 17 ++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +-
arch/sh/kernel/dma-coherent.c | 16 ++--
arch/x86/pci/sta2x11-fixup.c | 7 +-
drivers/acpi/arm64/iort.c | 5 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 5 +-
drivers/iommu/io-pgtable-arm.c| 2 +-
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +-
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 4 +-
drivers/of/address.c | 95 ++-
drivers/of/device.c | 47 +
drivers/of/of_private.h | 9 +-
drivers/of/unittest.c | 35 +--
drivers/remoteproc/remoteproc_core.c | 2 +-
.../staging/media/sunxi/cedrus/cedrus_hw.c| 7 +-
drivers/usb/core/message.c| 4 +-
drivers/usb/core/usb.c| 2 +-
include/linux/device.h| 4 +-
include/linux/dma-direct.h| 10 +-
include/linux/dma-mapping.h | 43 +
include/linux/pfn.h | 2 +
kernel/dma/coherent.c | 10 +-
kernel/dma/mapping.c | 53 +++
24 files changed, 278 insertions(+), 124 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca34..b7cdde9fb83d 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -35,8 +35,9 @@ static inline const struct dma_map_ops
*get_arch_dma_ops(struct bus_type *bus)
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- if (dev)
- pfn -= dev->dma_pfn_offset;
+ if (dev && dev->dma_range_map)
+ pfn -= DMA_ADDR_PFN(dma_offset_from_phys_addr(dev,
PFN_PHYS(pfn)));
+
return (dma_addr_t)__pfn_to_bus(pfn);
}
@@ -44,8 +45,8 @@ static inline unsigned long dma_to_pfn(struct device *dev,
dma_addr_t addr)
{
unsigned long pfn = __bus_to_pfn(addr);
- if (dev)
- pfn += dev->dma_pfn_offset;
+ if (dev && dev->dma_range_map)
+ pfn += DMA_ADDR_PFN(dma_offset_from_dma_addr(dev, addr));
return pfn;
}
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index 638808c4e122..a1a19781983b 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,6 +8,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -24,8 +25,6 @@
#include "keystone.h"
-static unsigned long keystone_dma_pfn_offset __read_mostly;
-
static int keystone_platform_notifier(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -38,9 +37,12 @@ static int keystone_platform_notifier(struct notifier_block
*nb,
return NOTIFY_BAD;
if (!dev->of_node) {
- dev->dma_pfn_offset = keystone_dma_pfn_offset;
- dev_err(dev, "set dma_pfn_offset%08lx\n",
- dev->dma_pfn_offset);
+ int ret = dma_attach_offset_range(dev, KEYSTONE_HIGH_PHYS_START,
+ KEYSTONE_LOW_PHYS_START,
+ KEYSTONE_HIGH_PHYS_SIZE);
+ dev_err(dev, "set dma_offset%08llx%s\n",
+ KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START,
+ ret ? " failed" : "");
}
return NOTIFY_OK;
}
@@ -51,11 +53,8 @@ static struct notifier_block platform_nb = {
static void __init keystone_init(void)
{
- if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
- keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
- KEYSTONE_LOW_PHYS_START);
+ if (PHYS_OFFS
Re: [PATCH 0/2] Fix st7703 panel initialization failures
Hi Ondrej, On Thu, Jul 16, 2020 at 02:37:51PM +0200, Ondrej Jirman wrote: > When extending the driver for xbd599 panel support I tried to do minimal > changes and keep the existing initialization timing. > > It turned out that it's not good enough and the existing init sequence > is too aggressive and doesn't follow the specification. On PinePhone > panel is being powered down/up during suspend/resume and with current > timings this frequently leads to corrupted display. Given the amount of ST7703 look alikes i don't think you can go by the datasheet and hope not to break other panels. The current sleeps cater for the rocktech panel (which suffered from similar issues you describe when we took other parameters) so you need to make those panel specific. Cheers, -- Guido > > This patch series fixes the problems. > > The issue was reported by Samuel Holland. > > Relevant screenshots from the datasheet: > > Power on timing: https://megous.com/dl/tmp/35b72e674ce0ca27.png > Power off timing: https://megous.com/dl/tmp/dea195517106ff17.png > More optimal reset on poweron: > https://megous.com/dl/tmp/a9e5caf14e1b0dc6.png > Less optimal reset on poweron: > https://megous.com/dl/tmp/246761039283c4cf.png > Datasheet: https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf > > Please take a look. > > thank you and regards, > Ondrej Jirman > > Ondrej Jirman (2): > drm/panel: st7703: Make the sleep exit timing match the spec > drm/panel: st7703: Fix the power up sequence of the panel > > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 29 ++- > 1 file changed, 15 insertions(+), 14 deletions(-) > > -- > 2.27.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/20] backlight: improve backlight_device documentation
On Fri, 03 Jul 2020, Sam Ravnborg wrote: > Improve the documentation for backlight_device and > adapt it to kernel-doc style. > > The updated documentation is more strict on how locking is used. > With the update neither update_lock nor ops_lock may be used > outside the backlight core. > This restriction was introduced to keep the locking simple > by keeping it in the core. > It was verified that this documents the current state by renaming > update_lock => bl_update_lock and ops_lock => bl_ops_lock. > The rename did not reveal any uses outside the backlight core. > The rename is NOT part of this patch. > > v3: > - Update changelog to explain locking details (Daniel) > > v2: > - Add short intro to all fields (Daniel) > - Updated description of update_lock (Daniel) > > Signed-off-by: Sam Ravnborg > Reviewed-by: Emil Velikov > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > --- > include/linux/backlight.h | 72 ++- > 1 file changed, 49 insertions(+), 23 deletions(-) Some of these do not apply cleanly. Please collect the *-bys already received, rebase and resubmit. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/20] backlight: improve backlight_device documentation
Hi Lee. On Thu, Jul 16, 2020 at 03:39:41PM +0100, Lee Jones wrote: > On Fri, 03 Jul 2020, Sam Ravnborg wrote: > > > Improve the documentation for backlight_device and > > adapt it to kernel-doc style. > > > > The updated documentation is more strict on how locking is used. > > With the update neither update_lock nor ops_lock may be used > > outside the backlight core. > > This restriction was introduced to keep the locking simple > > by keeping it in the core. > > It was verified that this documents the current state by renaming > > update_lock => bl_update_lock and ops_lock => bl_ops_lock. > > The rename did not reveal any uses outside the backlight core. > > The rename is NOT part of this patch. > > > > v3: > > - Update changelog to explain locking details (Daniel) > > > > v2: > > - Add short intro to all fields (Daniel) > > - Updated description of update_lock (Daniel) > > > > Signed-off-by: Sam Ravnborg > > Reviewed-by: Emil Velikov > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > --- > > include/linux/backlight.h | 72 ++- > > 1 file changed, 49 insertions(+), 23 deletions(-) > > Some of these do not apply cleanly. > > Please collect the *-bys already received, rebase and resubmit. Will do. The patch-set is based on drm-misc-next. Are there another tree that I should use? Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/20] backlight: improve backlight_device documentation
On Thu, 16 Jul 2020, Sam Ravnborg wrote: > Hi Lee. > > On Thu, Jul 16, 2020 at 03:39:41PM +0100, Lee Jones wrote: > > On Fri, 03 Jul 2020, Sam Ravnborg wrote: > > > > > Improve the documentation for backlight_device and > > > adapt it to kernel-doc style. > > > > > > The updated documentation is more strict on how locking is used. > > > With the update neither update_lock nor ops_lock may be used > > > outside the backlight core. > > > This restriction was introduced to keep the locking simple > > > by keeping it in the core. > > > It was verified that this documents the current state by renaming > > > update_lock => bl_update_lock and ops_lock => bl_ops_lock. > > > The rename did not reveal any uses outside the backlight core. > > > The rename is NOT part of this patch. > > > > > > v3: > > > - Update changelog to explain locking details (Daniel) > > > > > > v2: > > > - Add short intro to all fields (Daniel) > > > - Updated description of update_lock (Daniel) > > > > > > Signed-off-by: Sam Ravnborg > > > Reviewed-by: Emil Velikov > > > Cc: Lee Jones > > > Cc: Daniel Thompson > > > Cc: Jingoo Han > > > --- > > > include/linux/backlight.h | 72 ++- > > > 1 file changed, 49 insertions(+), 23 deletions(-) > > > > Some of these do not apply cleanly. > > > > Please collect the *-bys already received, rebase and resubmit. > > Will do. > The patch-set is based on drm-misc-next. Are there another > tree that I should use? I don't have anything to do with that tree. Either Backlight [0] or Next would be fine. [0] https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git/ -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: panel: Add tianma nt36672a panel driver
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
Cc: Benni Steini
Signed-off-by: Sumit Semwal
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++
4 files changed, 878 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b4a43a9e7fbc..2d384e51353b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5544,6 +5544,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 39055c1f0e2f..da9d74c1ec91 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1
Say Y here if you want to enable support for TPO TD043MTEA1 800x480
4.3" panel (found on the OMAP3 Pandora board).
+config DRM_PANEL_TIANMA_FHD_NT36672A
+ tristate "TIANMA NT36672A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Tianma NT36672A
+ panel. It is seen mostly in Xiaomi Poco F1 mobile phone.
+ The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel.
+ It provides a MIPI DSI interface to the host.
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index de74f282c433..303e44eb50fa 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
new file mode 100644
index ..166773612ad2
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
@@ -0,0 +1,859 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const char * const regulator_names[] = {
+ "vddio",
+ "vddpos",
+ "vddneg",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100
+};
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ const char *panel_name;
+
+ unsigned int width_mm;
+ unsigned int height_mm;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+
+ const struct panel_cmd *on_cmds_1;
+ const struct panel_cmd *on_cmds_2;
+
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *active;
+ struct pinctrl_state *suspend;
+
+
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct panel_info *to_panel_info(struct drm_panel *panel)
+{
+ return container_of(p
[PATCH 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Tianma nt36672a panel drm: panel: Add tianma nt36672a panel driver .../display/panel/tianma,nt36672a.yaml| 110 +++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++ 5 files changed, 988 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
and 6.18 inches size. It is found in some of the Poco F1 phones.
Signed-off-by: Sumit Semwal
---
.../display/panel/tianma,nt36672a.yaml| 110 ++
1 file changed, 110 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
new file mode 100644
index ..3c583ca926ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tianma model NT36672A DSI Panel display driver
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a panel from Tianma is a FHD+ LCD display panel with a resolution
+ of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: tianma,nt36672a
+
+ reg:
+description: DSI virtual channel of the peripheral
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ pinctrl-names:
+description: Pinctrl for panel active and suspend
+
+ pinctrl-0:
+description: Active pinctrls
+
+ pinctrl-1:
+description: Suspend pinctrls
+
+ ports:
+type: object
+properties:
+ port@0:
+type: object
+description: DSI input port driven by master DSI
+properties:
+ reg:
+const: 0
+
+required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - pinctrl-names
+ - pinctrl-0
+ - pinctrl-1
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,nt36672a";
+reg = <0>;
+vddi0-supply = <&vreg_l14a_1p88>;
+vddpos-supply = <&lab>;
+vddneg-supply = <&ibb>;
+
+reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
+
+pinctrl-names = "panel_active", "panel_suspend";
+pinctrl-0 = <&sde_dsi_active>;
+pinctrl-1 = <&sde_dsi_suspend>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+};
+ };
+};
+ };
+};
+
+...
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208573] Black screen on boot if two displays plugged in with NAVI 10
https://bugzilla.kernel.org/show_bug.cgi?id=208573 --- Comment #4 from Thomas Langkamp (thomas.langk...@medicalschool-hamburg.de) --- Maybe it has something to do with my X470 Board not being PCI-E 4.0? I switched to a better PSU today, but that did not help either. Both screens completely black until I pull one cable and reboot. -- 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 v3 10/12] drm/ingenic: Add support for the IPU
On Thu, Jul 16, 2020 at 06:38:44PM +0200, Paul Cercueil wrote:
> Add support for the Image Processing Unit (IPU) found in all Ingenic
> SoCs.
>
> The IPU can upscale and downscale a source frame of arbitrary size
> ranging from 4x4 to 4096x4096 on newer SoCs, with bicubic filtering
> on newer SoCs, bilinear filtering on older SoCs. Nearest-neighbour can
> also be obtained with proper coefficients.
>
> Starting from the JZ4725B, the IPU supports a mode where its output is
> sent directly to the LCDC, without having to be written to RAM first.
> This makes it possible to use the IPU as a DRM plane on the compatible
> SoCs, and have it convert and scale anything the userspace asks for to
> what's available for the display.
>
> Regarding pixel formats, older SoCs support packed YUV 4:2:2 and various
> planar YUV formats. Newer SoCs introduced support for RGB.
>
> Since the IPU is a separate hardware block, to make it work properly the
> Ingenic DRM driver will now register itself as a component master in
> case the IPU driver has been enabled in the config.
>
> When enabled in the config, the CRTC will see the IPU as a second primary
> plane. It cannot be enabled at the same time as the regular primary
> plane. It has the same priority, which means that it will also display
> below the overlay plane.
>
> v2: - ingenic-ipu is no longer its own module. It will be built
> into the ingenic-drm module.
> - If enabled in the config, both the core driver and the IPU
> driver will register as components; otherwise the core
> driver will bypass that and call the ingenic_drm_bind()
> function directly.
> - Since both files now build into the same module, the
> symbols previously exported as GPL are not exported anymore,
> since they are only used internally.
> - Fix SPDX license header in ingenic-ipu.h
> - Avoid using 'for(;;);' loops without trailing statement(s)
>
> v3: - Pass priv structure to IRQ handler; that way we don't hardcode
> the expectation that the IPU plane is at index #0.
> - Rework osd_changed() to account for src_* changes
> - Add multiplanar YUV 4:4:4 support
> - Commit fb addresses to HW at vblank, since addr registers are
> not shadow registers
> - Probe IPU component later so that IPU plane is last
> - Fix driver not working on IPU-less hardware
> - Use IPU driver's name as the IRQ name to avoid having two
> 'ingenic-drm' in /proc/interrupts
> - Fix IPU only working for still images on JZ4725B
> - Add a bit more code comments
>
> Signed-off-by: Paul Cercueil
Checkpatch warns about a few "CamelCase".
With these fixed:
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/ingenic/Kconfig | 11 +
> drivers/gpu/drm/ingenic/Makefile | 3 +-
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 171 -
> drivers/gpu/drm/ingenic/ingenic-drm.h | 12 +
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 852 ++
> drivers/gpu/drm/ingenic/ingenic-ipu.h | 109 +++
> 6 files changed, 1142 insertions(+), 16 deletions(-)
> create mode 100644 drivers/gpu/drm/ingenic/ingenic-ipu.c
> create mode 100644 drivers/gpu/drm/ingenic/ingenic-ipu.h
>
> diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
> index d82c3d37ec9c..477d5387e43e 100644
> --- a/drivers/gpu/drm/ingenic/Kconfig
> +++ b/drivers/gpu/drm/ingenic/Kconfig
> @@ -14,3 +14,14 @@ config DRM_INGENIC
> Choose this option for DRM support for the Ingenic SoCs.
>
> If M is selected the module will be called ingenic-drm.
> +
> +if DRM_INGENIC
> +
> +config DRM_INGENIC_IPU
> + bool "IPU support for Ingenic SoCs"
> + help
> + Choose this option to enable support for the IPU found in Ingenic
> SoCs.
> +
> + The Image Processing Unit (IPU) will appear as a second primary plane.
> +
> +endif
> diff --git a/drivers/gpu/drm/ingenic/Makefile
> b/drivers/gpu/drm/ingenic/Makefile
> index 9875628dd8bc..d313326bdddb 100644
> --- a/drivers/gpu/drm/ingenic/Makefile
> +++ b/drivers/gpu/drm/ingenic/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
> -ingenic-drm-y += ingenic-drm-drv.o
> +ingenic-drm-y = ingenic-drm-drv.o
> +ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index e922b910ad39..296d21d203b8 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -6,6 +6,7 @@
>
> #include "ingenic-drm.h"
>
> +#include
> #include
> #include
> #include
> @@ -54,7 +55,7 @@ struct ingenic_drm {
>* f0 (aka. foreground0) can be overlayed. Z-order is fixed in
>* hardware and cannot be changed.
>*/
> - struct drm_plane f0, f1;
> + struct drm_plane f0, f1, *ipu_plane;
> struct drm_crtc crtc;
> struct drm_encoder encoder;
>
> @@ -190,1
Re: [PATCH v3 09/12] drm/ingenic: Add support for OSD mode
On Thu, Jul 16, 2020 at 06:38:43PM +0200, Paul Cercueil wrote:
> All Ingenic SoCs starting from the JZ4725B support OSD mode.
>
> In this mode, two separate planes can be used. They can have different
> positions and sizes, and one can be overlayed on top of the other.
>
> v2: Use fallthrough; instead of /* fall-through */
>
> v3: - Add custom atomic_tail function to handle case where HW gives no
> VBLANK
> - Use regmap_set_bits() / regmap_clear_bits() when possible
> - Use dma_hwdesc_f{0,1} fields in priv structure instead of array
> - Use dmam_alloc_coherent() instead of dma_alloc_coherent()
> - Use more meaningful 0xf0 / 0xf1 values as DMA descriptors IDs
> - Add a bit more code comments
>
> Signed-off-by: Paul Cercueil
Indent is wrong for ingenic_drm_plane_enable().
One space too much on second line.
With this fixed:
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 303 ++
> drivers/gpu/drm/ingenic/ingenic-drm.h | 35 +++
> 2 files changed, 288 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index 9cc785776594..e922b910ad39 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -43,12 +43,18 @@ struct ingenic_dma_hwdesc {
>
> struct jz_soc_info {
> bool needs_dev_clk;
> + bool has_osd;
> unsigned int max_width, max_height;
> };
>
> struct ingenic_drm {
> struct drm_device drm;
> - struct drm_plane primary;
> + /*
> + * f1 (aka. foreground1) is our primary plane, on top of which
> + * f0 (aka. foreground0) can be overlayed. Z-order is fixed in
> + * hardware and cannot be changed.
> + */
> + struct drm_plane f0, f1;
> struct drm_crtc crtc;
> struct drm_encoder encoder;
>
> @@ -57,10 +63,11 @@ struct ingenic_drm {
> struct clk *lcd_clk, *pix_clk;
> const struct jz_soc_info *soc_info;
>
> - struct ingenic_dma_hwdesc *dma_hwdesc;
> - dma_addr_t dma_hwdesc_phys;
> + struct ingenic_dma_hwdesc *dma_hwdesc_f0, *dma_hwdesc_f1;
> + dma_addr_t dma_hwdesc_phys_f0, dma_hwdesc_phys_f1;
>
> bool panel_is_sharp;
> + bool no_vblank;
> };
>
> static const u32 ingenic_drm_primary_formats[] = {
> @@ -90,7 +97,7 @@ static const struct regmap_config ingenic_drm_regmap_config
> = {
> .val_bits = 32,
> .reg_stride = 4,
>
> - .max_register = JZ_REG_LCD_CMD1,
> + .max_register = JZ_REG_LCD_SIZE1,
> .writeable_reg = ingenic_drm_writeable_reg,
> };
>
> @@ -110,11 +117,6 @@ drm_encoder_get_priv(struct drm_encoder *encoder)
> return container_of(encoder, struct ingenic_drm, encoder);
> }
>
> -static inline struct ingenic_drm *drm_plane_get_priv(struct drm_plane *plane)
> -{
> - return container_of(plane, struct ingenic_drm, primary);
> -}
> -
> static void ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *state)
> {
> @@ -185,34 +187,16 @@ static void ingenic_drm_crtc_update_timings(struct
> ingenic_drm *priv,
> regmap_write(priv->map, JZ_REG_LCD_SPL, hpe << 16 | (hpe + 1));
> regmap_write(priv->map, JZ_REG_LCD_REV, mode->htotal << 16);
> }
> -}
> -
> -static void ingenic_drm_crtc_update_ctrl(struct ingenic_drm *priv,
> - const struct drm_format_info *finfo)
> -{
> - unsigned int ctrl = JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16;
> -
> - switch (finfo->format) {
> - case DRM_FORMAT_XRGB1555:
> - ctrl |= JZ_LCD_CTRL_RGB555;
> - /* fall-through */
> - case DRM_FORMAT_RGB565:
> - ctrl |= JZ_LCD_CTRL_BPP_15_16;
> - break;
> - case DRM_FORMAT_XRGB:
> - ctrl |= JZ_LCD_CTRL_BPP_18_24;
> - break;
> - }
>
> - regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
> -JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16 |
> -JZ_LCD_CTRL_BPP_MASK, ctrl);
> + regmap_set_bits(priv->map, JZ_REG_LCD_CTRL,
> + JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16);
> }
>
> static int ingenic_drm_crtc_atomic_check(struct drm_crtc *crtc,
>struct drm_crtc_state *state)
> {
> struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
> + struct drm_plane_state *f1_state, *f0_state;
> long rate;
>
> if (!drm_atomic_crtc_needs_modeset(state))
> @@ -227,6 +211,14 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc
> *crtc,
> if (rate < 0)
> return rate;
>
> + if (priv->soc_info->has_osd) {
> + f1_state = drm_atomic_get_plane_state(state->state, &priv->f1);
> + f0_state = drm_atomic_get_plane_state(state->state, &priv->f0);
> +
> + /* If all the plane
[PATCH] drm/mxsfb: drop unused function parameter
flags is unused since the driver was introduced in commit 45d59d704080
("drm: Add new driver for MXSFB controller").
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 497cf443a9af..fb972dd4f642 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -191,7 +191,7 @@ static struct drm_simple_display_pipe_funcs mxsfb_funcs = {
.disable_vblank = mxsfb_pipe_disable_vblank,
};
-static int mxsfb_load(struct drm_device *drm, unsigned long flags)
+static int mxsfb_load(struct drm_device *drm)
{
struct platform_device *pdev = to_platform_device(drm->dev);
struct mxsfb_drm_private *mxsfb;
@@ -407,7 +407,7 @@ static int mxsfb_probe(struct platform_device *pdev)
if (IS_ERR(drm))
return PTR_ERR(drm);
- ret = mxsfb_load(drm, 0);
+ ret = mxsfb_load(drm);
if (ret)
goto err_free;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm/ingenic: Fix incorrect assumption about plane->index
Hi Paul.
On Thu, Jul 16, 2020 at 06:38:35PM +0200, Paul Cercueil wrote:
> plane->index is NOT the index of the color plane in a YUV frame.
> Actually, a YUV frame is represented by a single drm_plane, even though
> it contains three Y, U, V planes.
>
> v2-v3: No change
>
> Cc: sta...@vger.kernel.org # v5.3
> Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")
> Signed-off-by: Paul Cercueil
> Acked-by: Sam Ravnborg
A cover letter would have been useful. Please consider that in the
future.
All patches in this set are:
Reviewed-by: Sam Ravnborg
A few requires some trivial issues fixed. They can be fixed while
applying.
I consider the patch-set ready to go in and I expect you to commit them.
Sam
> ---
> drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
> b/drivers/gpu/drm/ingenic/ingenic-drm.c
> index deb37b4a8e91..606d8acb0954 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
> @@ -386,7 +386,7 @@ static void ingenic_drm_plane_atomic_update(struct
> drm_plane *plane,
> addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
> width = state->src_w >> 16;
> height = state->src_h >> 16;
> - cpp = state->fb->format->cpp[plane->index];
> + cpp = state->fb->format->cpp[0];
>
> priv->dma_hwdesc->addr = addr;
> priv->dma_hwdesc->cmd = width * height * cpp / 4;
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/6] Generic USB Display driver
Den 14.07.2020 21.38, skrev Peter Stuge: > Noralf Trønnes wrote: >>> In all cases, the driver on the host knows/has available how many bytes >>> were successfully transfered. >> >> I was thinking about the device, that it could get out of sync. Let's >> say the host sends a 1k framebuffer and half of it gets transferred and >> the rest fails for some reason. Lubomir's MCU implementation has an >> endpoint max size of 64 bytes and a callback is called for each packet. >> If the 1k transfer fails at some point, will the device be able to >> detect this and know that the next time the rx callback is called that >> this is the start of a new framebuffer update? > > Ah! No, a device can not detect that the host intended to send more (bulk) > packets but e.g. timed out. > > I can't immediately think of other reasons for a larger transfer to fail, > which still allow communication to continue. > > When the host recognizes a timeout with partial data transfer it could > simply send the remaining data in a new transfer. > > > While the device can not detect host intent, the protocol could allow > devices to specify requirements, e.g. that the host always sends full frames. > > In any case, please avoid making a control request mandatory for frame > transfer. > > Because control requests are scheduled differently onto the wire and > because they consist of more packets than bulk data, a control request > will interrupt a bulk data stream and likely introduce unneccessary latency. > > If synchronization is always required then I'd suggest to place it inline > with frame data, e.g. in the first packet byte. > > If synchronization is only required in rare cases then a control transfer > is probably the better choice, to not waste any inline bytes. > > But the optimum would be that the device can describe its needs to the host > and the host driver ensures that the device always receives the data it needs. > > Do you think this is possible? > Looking at the host driver I see that I need to fix it so that it requeues the update if it fails (on SET_BUFFER or bulk out). Currently it just goes back to sleep waiting for userspace to announce a new change. I would like to avoid having a special case for retrying the failing part of a bulk transfer for devices that only want full updates, I would prefer to use the common error path of retrying the whole update. This is my suggestion for the new flag: /* * Always send the entire framebuffer when flushing changes. * The GUD_DRM_USB_REQ_SET_BUFFER request will not be sent before each bulk transfer, * it will only be sent if the previous bulk transfer had failed. This is done to * inform the device that the previous update failed and that a new one is started. * * This flag can not be used in combination with compression. */ #define GUD_DRM_DISPLAY_FLAG_FULL_UPDATEBIT(1) Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/panel-simple: Fix inverted V/H SYNC for Frida FRD350H54004 panel
On Thu, Jul 16, 2020 at 02:56:46PM +0200, Paul Cercueil wrote:
> The FRD350H54004 panel was marked as having active-high VSYNC and HSYNC
> signals, which sorts-of worked, but resulted in the picture fading out
> under certain circumstances.
>
> Fix this issue by marking VSYNC and HSYNC signals active-low.
>
> v2: Rebase on drm-misc-next
>
> Fixes: 7b6bd8433609 ("drm/panel: simple: Add support for the Frida
> FRD350H54004 panel")
> Cc: sta...@vger.kernel.org # v5.5
> Signed-off-by: Paul Cercueil
Thanks for the re-submit. Applied both patches to drm-misc-next.
Sam
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index f42249b72548..8b0bab9dd075 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1763,7 +1763,7 @@ static const struct drm_display_mode
> frida_frd350h54004_mode = {
> .vsync_start = 240 + 2,
> .vsync_end = 240 + 2 + 6,
> .vtotal = 240 + 2 + 6 + 2,
> - .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> };
>
> static const struct panel_desc frida_frd350h54004 = {
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 1/4] dt-bindings: display: panel-dsi-cm: convert to YAML
On Thu, Jul 16, 2020 at 02:57:30PM +0200, Sebastian Reichel wrote:
> Convert panel-dsi-cm bindings to YAML and add
> missing properties while at it.
>
> Reviewed-by: Laurent Pinchart
> Reviewed-by: Rob Herring
> Signed-off-by: Sebastian Reichel
Hi Sebastian.
Look good now. Applied this patch to drm-misc-next.
$ ls Documentation/devicetree/bindings/display/panel/*.txt
Documentation/devicetree/bindings/display/panel/display-timing.txt
Nice :-)
The DTS file changes needs to go in via another route.
Sam
> ---
> .../bindings/display/panel/panel-dsi-cm.txt | 29 ---
> .../bindings/display/panel/panel-dsi-cm.yaml | 86 +++
> 2 files changed, 86 insertions(+), 29 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> create mode 100644
> Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> deleted file mode 100644
> index dce48eb9db57..
> --- a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -Generic MIPI DSI Command Mode Panel
> -===
> -
> -Required properties:
> -- compatible: "panel-dsi-cm"
> -
> -Optional properties:
> -- label: a symbolic name for the panel
> -- reset-gpios: panel reset gpio
> -- te-gpios: panel TE gpio
> -
> -Required nodes:
> -- Video port for DSI input
> -
> -Example
>
> -
> -lcd0: display {
> - compatible = "tpo,taal", "panel-dsi-cm";
> - label = "lcd0";
> -
> - reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
> -
> - port {
> - lcd0_in: endpoint {
> - remote-endpoint = <&dsi1_out_ep>;
> - };
> - };
> -};
> diff --git
> a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> new file mode 100644
> index ..d766c949c622
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> @@ -0,0 +1,86 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-dsi-cm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: DSI command mode panels
> +
> +maintainers:
> + - Tomi Valkeinen
> + - Sebastian Reichel
> +
> +description: |
> + This binding file is a collection of the DSI panels that
> + are usually driven in command mode. If no backlight is
> + referenced via the optional backlight property, the DSI
> + panel is assumed to have native backlight support.
> + The panel may use an OF graph binding for the association
> + to the display, or it may be a direct child node of the
> + display.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> +
> + compatible:
> +items:
> + - enum:
> +- motorola,droid4-panel# Panel from Motorola Droid4 phone
> +- nokia,himalaya # Panel from Nokia N950 phone
> +- tpo,taal # Panel from OMAP4 SDP board
> + - const: panel-dsi-cm# Generic DSI command mode panel
> compatible fallback
> +
> + reg:
> +maxItems: 1
> +description: DSI virtual channel
> +
> + vddi-supply:
> +description:
> + Display panels require power to be supplied. While several panels need
> + more than one power supply with panel-specific constraints governing
> the
> + order and timings of the power supplies, in many cases a single power
> + supply is sufficient, either because the panel has a single power
> rail, or
> + because all its power rails can be driven by the same supply. In that
> case
> + the vddi-supply property specifies the supply powering the panel as a
> + phandle to a regulator.
> +
> + vpnl-supply:
> +description:
> + When the display panel needs a second power supply, this property can
> be
> + used in addition to vddi-supply. Both supplies will be enabled at the
> + same time before the panel is being accessed.
> +
> + width-mm: true
> + height-mm: true
> + label: true
> + rotation: true
> + panel-timing: true
> + port: true
> + reset-gpios: true
> + te-gpios: true
> + backlight: true
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> +#include
> +
> +dsi-controller {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "tpo,taal", "panel-dsi-cm";
> +reg = <0>;
> +reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
> +};
> +};
> +
> +...
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.
Re: [PATCHv2 1/4] dt-bindings: display: panel-dsi-cm: convert to YAML
Hi,
On Thu, Jul 16, 2020 at 07:52:58PM +0200, Sam Ravnborg wrote:
> On Thu, Jul 16, 2020 at 02:57:30PM +0200, Sebastian Reichel wrote:
> > Convert panel-dsi-cm bindings to YAML and add
> > missing properties while at it.
> >
> > Reviewed-by: Laurent Pinchart
> > Reviewed-by: Rob Herring
> > Signed-off-by: Sebastian Reichel
>
> Hi Sebastian.
>
> Look good now. Applied this patch to drm-misc-next.
Thanks!
> $ ls Documentation/devicetree/bindings/display/panel/*.txt
> Documentation/devicetree/bindings/display/panel/display-timing.txt
>
> Nice :-)
Indeed.
> The DTS file changes needs to go in via another route.
No worries. I guess Tony will queue them up when he finds some time.
-- Sebastian
>
> Sam
>
> > ---
> > .../bindings/display/panel/panel-dsi-cm.txt | 29 ---
> > .../bindings/display/panel/panel-dsi-cm.yaml | 86 +++
> > 2 files changed, 86 insertions(+), 29 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> > b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> > deleted file mode 100644
> > index dce48eb9db57..
> > --- a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
> > +++ /dev/null
> > @@ -1,29 +0,0 @@
> > -Generic MIPI DSI Command Mode Panel
> > -===
> > -
> > -Required properties:
> > -- compatible: "panel-dsi-cm"
> > -
> > -Optional properties:
> > -- label: a symbolic name for the panel
> > -- reset-gpios: panel reset gpio
> > -- te-gpios: panel TE gpio
> > -
> > -Required nodes:
> > -- Video port for DSI input
> > -
> > -Example
> >
> > -
> > -lcd0: display {
> > - compatible = "tpo,taal", "panel-dsi-cm";
> > - label = "lcd0";
> > -
> > - reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
> > -
> > - port {
> > - lcd0_in: endpoint {
> > - remote-endpoint = <&dsi1_out_ep>;
> > - };
> > - };
> > -};
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> > b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> > new file mode 100644
> > index ..d766c949c622
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
> > @@ -0,0 +1,86 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/panel-dsi-cm.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: DSI command mode panels
> > +
> > +maintainers:
> > + - Tomi Valkeinen
> > + - Sebastian Reichel
> > +
> > +description: |
> > + This binding file is a collection of the DSI panels that
> > + are usually driven in command mode. If no backlight is
> > + referenced via the optional backlight property, the DSI
> > + panel is assumed to have native backlight support.
> > + The panel may use an OF graph binding for the association
> > + to the display, or it may be a direct child node of the
> > + display.
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > +
> > + compatible:
> > +items:
> > + - enum:
> > +- motorola,droid4-panel# Panel from Motorola Droid4 phone
> > +- nokia,himalaya # Panel from Nokia N950 phone
> > +- tpo,taal # Panel from OMAP4 SDP board
> > + - const: panel-dsi-cm# Generic DSI command mode panel
> > compatible fallback
> > +
> > + reg:
> > +maxItems: 1
> > +description: DSI virtual channel
> > +
> > + vddi-supply:
> > +description:
> > + Display panels require power to be supplied. While several panels
> > need
> > + more than one power supply with panel-specific constraints governing
> > the
> > + order and timings of the power supplies, in many cases a single power
> > + supply is sufficient, either because the panel has a single power
> > rail, or
> > + because all its power rails can be driven by the same supply. In
> > that case
> > + the vddi-supply property specifies the supply powering the panel as a
> > + phandle to a regulator.
> > +
> > + vpnl-supply:
> > +description:
> > + When the display panel needs a second power supply, this property
> > can be
> > + used in addition to vddi-supply. Both supplies will be enabled at the
> > + same time before the panel is being accessed.
> > +
> > + width-mm: true
> > + height-mm: true
> > + label: true
> > + rotation: true
> > + panel-timing: true
> > + port: true
> > + reset-gpios: true
> > + te-gpios: true
> > + backlight: true
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +examples:
> >
[Bug 208587] New: amdgpu hang and gnome shell crash if playing video on 5600M with DRI_PRIME
https://bugzilla.kernel.org/show_bug.cgi?id=208587 Bug ID: 208587 Summary: amdgpu hang and gnome shell crash if playing video on 5600M with DRI_PRIME Product: Drivers Version: 2.5 Kernel Version: 5.8.0-rc5 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: d...@rodler-keller.de Regression: No Created attachment 290321 --> https://bugzilla.kernel.org/attachment.cgi?id=290321&action=edit dmesg On my Dell Inc. G5 5505 the Gnome Shell Wayland session crashes when I try to watch a video with "DRI_PRIME=1 firefox" on the AMD 5600M I get the following kernel error messages [Do Jul 16 20:16:03 2020] [drm:mod_hdcp_add_display_to_topology [amdgpu]] *ERROR* Failed to add display topology, DTM TA is not initialized. [Do Jul 16 20:16:03 2020] [drm] [Link 0] WARNING MOD_HDCP_STATUS_FAILURE IN STATE HDCP_UNINITIALIZED STAY COUNT 0 [Do Jul 16 20:16:03 2020] [ cut here ] [Do Jul 16 20:16:03 2020] WARNING: CPU: 7 PID: 181 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:3194 dcn20_validate_bandwidth_fp+0x7a/0xb0 [amdgpu] CPU Brand: AMD Ryzen 7 4800H with Radeon Graphics Operating System Version: "Arch Linux" (64 bit) Kernel Name: Linux Kernel Version: 5.8.0-rc5-1-mainline Window Manager: GNOME Shell (Wayland) Firefox 78 DRI_PRIME=1 glxinfo Device: AMD Radeon RX 5600M (NAVI10, DRM 3.38.0, 5.8.0-rc5-1-mainline, LLVM 10.0.0) (0x731f) Version: 20.1.3 DRI_PRIME=0 glxinfo Device: AMD RENOIR (DRM 3.38.0, 5.8.0-rc5-1-mainline, LLVM 10.0.0) (0x1636) Version: 20.1.3 -- 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 208589] New: amdgpu screen corruption with DRI_PRIME on external monitor at resolution 2560x1440 and more then 60hz
https://bugzilla.kernel.org/show_bug.cgi?id=208589 Bug ID: 208589 Summary: amdgpu screen corruption with DRI_PRIME on external monitor at resolution 2560x1440 and more then 60hz Product: Drivers Version: 2.5 Kernel Version: 5.8.0-rc5 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: d...@rodler-keller.de Regression: No Created attachment 290323 --> https://bugzilla.kernel.org/attachment.cgi?id=290323&action=edit dmesg On my Dell Inc. G5 5505 I get screen corruption if I use a resolution of 2560x1440 and more than 60HZ while using the dedicated AMD Radeon RX 5600M and an external monitor. On the built in Laptop screen everything runs at 1920x1080 and 144 Hz without screen corruption. Monitor: Iiyama XUB2792QSU connected with Displayport CPU Brand: AMD Ryzen 7 4800H with Radeon Graphics Operating System Version: "Arch Linux" (64 bit) Kernel Name: Linux Kernel Version: 5.8.0-rc5-1-mainline Window Manager: GNOME Shell (Wayland) DRI_PRIME=1 glxinfo Device: AMD Radeon RX 5600M (NAVI10, DRM 3.38.0, 5.8.0-rc5-1-mainline, LLVM 10.0.0) (0x731f) Version: 20.1.3 DRI_PRIME=0 glxinfo Device: AMD RENOIR (DRM 3.38.0, 5.8.0-rc5-1-mainline, LLVM 10.0.0) (0x1636) Version: 20.1.3 -- 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 2/3] drm/vram-helper: Integrate drm_gem_vram_init() into drm_gem_vram_create()
Hi Thomas.
On Tue, Jul 14, 2020 at 10:32:37AM +0200, Thomas Zimmermann wrote:
> The drm_gem_vram_create() function is the only caller of the internal
> helepr drm_gem_vram_init(). Streamline the code by putting all code into
helper
> the create function.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 75 ++-
> 1 file changed, 28 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 8dfb7458a34b..af767d3da5da 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -175,51 +175,6 @@ static void drm_gem_vram_placement(struct
> drm_gem_vram_object *gbo,
> }
> }
>
> -/*
> - * Note that on error, drm_gem_vram_init will free the buffer object.
> - */
> -
> -static int drm_gem_vram_init(struct drm_device *dev,
> - struct drm_gem_vram_object *gbo,
> - size_t size, unsigned long pg_align)
> -{
> - struct drm_vram_mm *vmm = dev->vram_mm;
> - struct ttm_bo_device *bdev;
> - int ret;
> - size_t acc_size;
> -
> - if (WARN_ONCE(!vmm, "VRAM MM not initialized")) {
> - kfree(gbo);
> - return -EINVAL;
> - }
> - bdev = &vmm->bdev;
> -
> - gbo->bo.base.funcs = &drm_gem_vram_object_funcs;
> -
> - ret = drm_gem_object_init(dev, &gbo->bo.base, size);
> - if (ret) {
> - kfree(gbo);
> - return ret;
> - }
> -
> - acc_size = ttm_bo_dma_acc_size(bdev, size, sizeof(*gbo));
> -
> - gbo->bo.bdev = bdev;
> - drm_gem_vram_placement(gbo, TTM_PL_FLAG_VRAM | TTM_PL_FLAG_SYSTEM);
> -
> - ret = ttm_bo_init(bdev, &gbo->bo, size, ttm_bo_type_device,
> - &gbo->placement, pg_align, false, acc_size,
> - NULL, NULL, ttm_buffer_object_destroy);
> - if (ret)
> - /*
> - * A failing ttm_bo_init will call ttm_buffer_object_destroy
> - * to release gbo->bo.base and kfree gbo.
> - */
> - return ret;
> -
> - return 0;
> -}
> -
> /**
> * drm_gem_vram_create() - Creates a VRAM-backed GEM object
> * @dev: the DRM device
> @@ -235,7 +190,13 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
> drm_device *dev,
> unsigned long pg_align)
> {
> struct drm_gem_vram_object *gbo;
> + struct drm_vram_mm *vmm = dev->vram_mm;
> + struct ttm_bo_device *bdev;
> int ret;
> + size_t acc_size;
> +
> + if (WARN_ONCE(!vmm, "VRAM MM not initialized"))
> + return ERR_PTR(-EINVAL);
>
> if (dev->driver->gem_create_object) {
> struct drm_gem_object *gem =
> @@ -249,8 +210,28 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
> drm_device *dev,
> return ERR_PTR(-ENOMEM);
> }
>
> - ret = drm_gem_vram_init(dev, gbo, size, pg_align);
> - if (ret < 0)
> + gbo->bo.base.funcs = &drm_gem_vram_object_funcs;
> +
> + ret = drm_gem_object_init(dev, &gbo->bo.base, size);
> + if (ret) {
> + kfree(gbo);
> + return ERR_PTR(ret);
> + }
> +
> + bdev = &vmm->bdev;
> + acc_size = ttm_bo_dma_acc_size(bdev, size, sizeof(*gbo));
> +
> + gbo->bo.bdev = bdev;
> + drm_gem_vram_placement(gbo, TTM_PL_FLAG_VRAM | TTM_PL_FLAG_SYSTEM);
> +
> + /*
> + * A failing ttm_bo_init will call ttm_buffer_object_destroy
> + * to release gbo->bo.base and kfree gbo.
> + */
> + ret = ttm_bo_init(bdev, &gbo->bo, size, ttm_bo_type_device,
> + &gbo->placement, pg_align, false, acc_size,
> + NULL, NULL, ttm_buffer_object_destroy);
> + if (ret)
> return ERR_PTR(ret);
>
> return gbo;
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vram-helper: Set object function iff they are not provided by driver
On Tue, Jul 14, 2020 at 10:32:38AM +0200, Thomas Zimmermann wrote:
> Don't override the GEM object functions unconditionally. If the driver
> sets the GEM functions, VRAM helpers will now them. The idea has been
s/now/own
> taken from SHMEM helpers. If drivers need special versions of some of
> the GEM functions, they can now override them.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index af767d3da5da..7194144610cb 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -190,6 +190,7 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
> drm_device *dev,
> unsigned long pg_align)
The documentation of drm_gem_vram_create() could really use some love
here. It should document the behavior around gem_create_object(), and
the default allocation of drm_gem_vram_object with no drm_gem_object
assigned etc.
Sam
> {
> struct drm_gem_vram_object *gbo;
> + struct drm_gem_object *gem;
> struct drm_vram_mm *vmm = dev->vram_mm;
> struct ttm_bo_device *bdev;
> int ret;
> @@ -199,8 +200,7 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
> drm_device *dev,
> return ERR_PTR(-EINVAL);
>
> if (dev->driver->gem_create_object) {
> - struct drm_gem_object *gem =
> - dev->driver->gem_create_object(dev, size);
> + gem = dev->driver->gem_create_object(dev, size);
> if (!gem)
> return ERR_PTR(-ENOMEM);
> gbo = drm_gem_vram_of_gem(gem);
> @@ -208,11 +208,13 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
> drm_device *dev,
> gbo = kzalloc(sizeof(*gbo), GFP_KERNEL);
> if (!gbo)
> return ERR_PTR(-ENOMEM);
> + gem = &gbo->bo.base;
> }
>
> - gbo->bo.base.funcs = &drm_gem_vram_object_funcs;
> + if (!gem->funcs)
> + gem->funcs = &drm_gem_vram_object_funcs;
>
> - ret = drm_gem_object_init(dev, &gbo->bo.base, size);
> + ret = drm_gem_object_init(dev, gem, size);
> if (ret) {
> kfree(gbo);
> return ERR_PTR(ret);
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Replace HTTP links with HTTPS ones
On Mon, Jul 13, 2020 at 02:49:23PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov
Applied to drm-misc-next.
Sam
> ---
> Continuing my work started at 93431e0607e5.
> See also: git log --oneline '--author=Alexander A. Klimov
> ' v5.7..master
> (Actually letting a shell for loop submit all this stuff for me.)
>
> If there are any URLs to be removed completely or at least not just
> HTTPSified:
> Just clearly say so and I'll *undo my change*.
> See also: https://lkml.org/lkml/2020/6/27/64
>
> If there are any valid, but yet not changed URLs:
> See: https://lkml.org/lkml/2020/6/26/837
>
> If you apply the patch, please let me know.
>
> Sorry again to all maintainers who complained about subject lines.
> Now I realized that you want an actually perfect prefixes,
> not just subsystem ones.
> I tried my best...
> And yes, *I could* (at least half-)automate it.
> Impossible is nothing! :)
>
>
> drivers/gpu/drm/vboxvideo/hgsmi_defs.h | 2 +-
> drivers/gpu/drm/vboxvideo/vbox_hgsmi.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/hgsmi_defs.h
> b/drivers/gpu/drm/vboxvideo/hgsmi_defs.h
> index 6c8df1cdb087..3cb52f2b2274 100644
> --- a/drivers/gpu/drm/vboxvideo/hgsmi_defs.h
> +++ b/drivers/gpu/drm/vboxvideo/hgsmi_defs.h
> @@ -58,7 +58,7 @@ struct hgsmi_buffer_tail {
> /* Reserved, must be initialized to 0. */
> u32 reserved;
> /*
> - * One-at-a-Time Hash: http://www.burtleburtle.net/bob/hash/doobs.html
> + * One-at-a-Time Hash: https://www.burtleburtle.net/bob/hash/doobs.html
>* Over the header, offset and for first 4 bytes of the tail.
>*/
> u32 checksum;
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_hgsmi.c
> b/drivers/gpu/drm/vboxvideo/vbox_hgsmi.c
> index 94b60654a012..a9ca4d0c3eca 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_hgsmi.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_hgsmi.c
> @@ -8,7 +8,7 @@
> #include "vboxvideo_vbe.h"
> #include "hgsmi_defs.h"
>
> -/* One-at-a-Time Hash from http://www.burtleburtle.net/bob/hash/doobs.html */
> +/* One-at-a-Time Hash from https://www.burtleburtle.net/bob/hash/doobs.html
> */
> static u32 hgsmi_hash_process(u32 hash, const u8 *data, int size)
> {
> while (size--) {
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tidss: Replace HTTP links with HTTPS ones
On Mon, Jul 13, 2020 at 02:39:13PM +0200, Alexander A. Klimov wrote: > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > > Deterministic algorithm: > For each file: > If not .svg: > For each line: > If doesn't contain `\bxmlns\b`: > For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: > If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: > If both the HTTP and HTTPS versions > return 200 OK and serve the same content: > Replace HTTP with HTTPS. > > Signed-off-by: Alexander A. Klimov Applied to drm-misc-next. Sam > --- > Continuing my work started at 93431e0607e5. > See also: git log --oneline '--author=Alexander A. Klimov > ' v5.7..master > (Actually letting a shell for loop submit all this stuff for me.) > > If there are any URLs to be removed completely or at least not just > HTTPSified: > Just clearly say so and I'll *undo my change*. > See also: https://lkml.org/lkml/2020/6/27/64 > > If there are any valid, but yet not changed URLs: > See: https://lkml.org/lkml/2020/6/26/837 > > If you apply the patch, please let me know. > > Sorry again to all maintainers who complained about subject lines. > Now I realized that you want an actually perfect prefixes, > not just subsystem ones. > I tried my best... > And yes, *I could* (at least half-)automate it. > Impossible is nothing! :) > > > drivers/gpu/drm/tidss/tidss_crtc.c| 2 +- > drivers/gpu/drm/tidss/tidss_crtc.h| 2 +- > drivers/gpu/drm/tidss/tidss_dispc.c | 2 +- > drivers/gpu/drm/tidss/tidss_dispc.h | 2 +- > drivers/gpu/drm/tidss/tidss_dispc_regs.h | 2 +- > drivers/gpu/drm/tidss/tidss_drv.c | 2 +- > drivers/gpu/drm/tidss/tidss_drv.h | 2 +- > drivers/gpu/drm/tidss/tidss_encoder.c | 2 +- > drivers/gpu/drm/tidss/tidss_encoder.h | 2 +- > drivers/gpu/drm/tidss/tidss_irq.c | 2 +- > drivers/gpu/drm/tidss/tidss_irq.h | 2 +- > drivers/gpu/drm/tidss/tidss_kms.c | 2 +- > drivers/gpu/drm/tidss/tidss_kms.h | 2 +- > drivers/gpu/drm/tidss/tidss_plane.c | 2 +- > drivers/gpu/drm/tidss/tidss_plane.h | 2 +- > drivers/gpu/drm/tidss/tidss_scale_coefs.c | 2 +- > drivers/gpu/drm/tidss/tidss_scale_coefs.h | 2 +- > 17 files changed, 17 insertions(+), 17 deletions(-) > > diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c > b/drivers/gpu/drm/tidss/tidss_crtc.c > index 89a226912de8..a591c70b8386 100644 > --- a/drivers/gpu/drm/tidss/tidss_crtc.c > +++ b/drivers/gpu/drm/tidss/tidss_crtc.c > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ > + * Copyright (C) 2018 Texas Instruments Incorporated - https://www.ti.com/ > * Author: Tomi Valkeinen > */ > > diff --git a/drivers/gpu/drm/tidss/tidss_crtc.h > b/drivers/gpu/drm/tidss/tidss_crtc.h > index 09e773666228..040d1205496b 100644 > --- a/drivers/gpu/drm/tidss/tidss_crtc.h > +++ b/drivers/gpu/drm/tidss/tidss_crtc.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > /* > - * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ > + * Copyright (C) 2018 Texas Instruments Incorporated - https://www.ti.com/ > * Author: Tomi Valkeinen > */ > > diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c > b/drivers/gpu/drm/tidss/tidss_dispc.c > index 629dd06393f6..e7d28ec8f7f3 100644 > --- a/drivers/gpu/drm/tidss/tidss_dispc.c > +++ b/drivers/gpu/drm/tidss/tidss_dispc.c > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Copyright (C) 2016-2018 Texas Instruments Incorporated - > http://www.ti.com/ > + * Copyright (C) 2016-2018 Texas Instruments Incorporated - > https://www.ti.com/ > * Author: Jyri Sarha > */ > > diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h > b/drivers/gpu/drm/tidss/tidss_dispc.h > index 902e612ff7ac..5984e0de2cd9 100644 > --- a/drivers/gpu/drm/tidss/tidss_dispc.h > +++ b/drivers/gpu/drm/tidss/tidss_dispc.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > /* > - * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ > + * Copyright (C) 2018 Texas Instruments Incorporated - https://www.ti.com/ > * Author: Tomi Valkeinen > */ > > diff --git a/drivers/gpu/drm/tidss/tidss_dispc_regs.h > b/drivers/gpu/drm/tidss/tidss_dispc_regs.h > index 88a83a41b6e3..13feedfe5d6d 100644 > --- a/drivers/gpu/drm/tidss/tidss_dispc_regs.h > +++ b/drivers/gpu/drm/tidss/tidss_dispc_regs.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > /* > - * Copyright (C) 2016-2018 Texas Instruments Incorporated - > http://www.ti.com/ > + * Copyright (C) 2016-2018 Texas Instruments Incorporated - > https://www.ti.com/ > * Author: Jyri Sarha > */ > > diff --git a/drivers/gpu/drm/tidss/tidss_drv.c > b/drivers/gpu/drm/tidss/tidss_drv.c > index 99edc66ebdef..f00fadb
Re: [PATCH 0/4] drm: core: Convert logging to drm_* functions.
Hi Suraj. On Sat, Jul 11, 2020 at 08:41:26PM +0530, Suraj Upadhyay wrote: > On Fri, Jul 10, 2020 at 07:56:43PM +0200, Sam Ravnborg wrote: > > Hi Suraj. > > > > On Tue, Jul 07, 2020 at 10:04:14PM +0530, Suraj Upadhyay wrote: > > > > > > This patchset converts logging to drm_* functions in drm core. > > > > > > The following functions have been converted to their respective > > > DRM alternatives : > > > dev_info() --> drm_info() > > > dev_err() --> drm_err() > > > dev_warn() --> drm_warn() > > > dev_err_once() --> drm_err_once(). > > > > I would prefer that DRM_* logging in the same files are converted in the > > same patch. So we have one logging conversion patch for each file you > > touches and that we do not need to re-vist the files later to change > > another set of logging functions. > > Agreed. > > > If possible WARN_* should also be converted to drm_WARN_* > > If patch is too large, then split them up but again lets have all > > logging updated when we touch a file. > > > > Care to take a look at this approach? > > > > Hii, > The problem with WARN_* macros is that they are used without any > drm device context. For example [this use > here](https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_edid.c#n1667) > in drm_edid.c, > doesn't have a drm device context and only has one argument (namely > !raw_edid). > There are many more such use cases. > > And also there were cases where dev_* logging functions didn't have any > drm_device context. > > I would be very glad, if we came up with a possible solution to this > problem. I think we should develop drm_* logging APIs which could print > contextless logs (which would possibly be midlyering) or give every situation > a context. This was discussed in the past. For now the focus is migrating existing logging to the new drm_ based logging. Preferably using coccinelle. when we are more or less covered there we can discuss if we will add more logging functions. > > > Also please consider if coccinelle can make this job easier. > > There is a lot of files... > > I totally agree with you. I will remember this next time. > > But here, in this patchset I have tried to convert all possible > cases of conversion, i.e. I have changed logging wherever there was a > drm_device context. Please note this in the changelog when you resend. I delete your original patches so they are gone now from my mail-box. Yeah, could dig them up somewhere, but it is easier to let you resend them and then we can have an updated changelog too. Sam > > Thanks. > > > Sam > > > > > > > > Suraj Upadhyay (4): > > > drm: mipi-dsi: Convert logging to drm_* functions. > > > drm: mipi-dbi: Convert logging to drm_* functions. > > > drm: edid: Convert logging to drm_* functions. > > > drm: fb-helper: Convert logging to drm_* functions. > > > > > > drivers/gpu/drm/drm_edid.c | 7 +++ > > > drivers/gpu/drm/drm_fb_helper.c | 2 +- > > > drivers/gpu/drm/drm_mipi_dbi.c | 4 ++-- > > > drivers/gpu/drm/drm_mipi_dsi.c | 15 +++ > > > 4 files changed, 13 insertions(+), 15 deletions(-) > > > > > > -- > > > 2.17.1 > > > > > > > > > > > > > > > ___ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: panel: simple: Delay HPD checking on boe_nv133fhm_n61 for 15 ms
On boe_nv133fhm_n62 (and presumably on boe_nv133fhm_n61) a scope shows
a small spike on the HPD line right when you power the panel on. The
picture looks something like this:
+--
|
|
|
Power ---+
+---
|
++ |
++| |
HPD -+ +---+
So right when power is applied there's a little bump in HPD and then
there's small spike right before it goes low. The total time of the
little bump plus the spike was measured on one panel as being 8 ms
long. The total time for the HPD to go high on the same panel was
51.2 ms, though the datasheet only promises it is < 200 ms.
When asked about this glitch, BOE indicated that it was expected and
persisted until the TCON has been initialized.
If this was a real hotpluggable DP panel then this wouldn't matter a
whole lot. We'd debounce the HPD signal for a really long time and so
the little blip wouldn't hurt. However, this is not a hotpluggable DP
panel and the the debouncing logic isn't needed and just shows down
the time needed to get the display working. This is why the code in
panel_simple_prepare() doesn't do debouncing and just waits for HPD to
go high once. Unfortunately if we get unlucky and happen to poll the
HPD line right at the spike we can try talking to the panel before
it's ready.
Let's handle this situation by putting in a 15 ms prepare delay and
decreasing the "hpd absent delay" by 15 ms. That means:
* If you don't have HPD hooked up at all you've still got the
hardcoded 200 ms delay.
* If you've got HPD hooked up you will always wait at least 15 ms
before checking HPD. The only case where this could be bad is if
the panel is sharing a voltage rail with something else in the
system and was already turned on long before the panel came up. In
such a case we'll be delaying 15 ms for no reason, but it's not a
huge delay and I don't see any other good solution to handle that
case.
Even though the delay was measured as 8 ms, 15 ms was chosen to give a
bit of margin.
Signed-off-by: Douglas Anderson
---
I don't actually have a device in front of me that is exhibiting these
problems. I believe that it is only some devices and some of the
time. Still, this patch seems safe and seems likely to fix the issue
given the scope shots.
drivers/gpu/drm/panel/panel-simple.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 88493538a147..046a06b55800 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1260,7 +1260,21 @@ static const struct panel_desc boe_nv133fhm_n61 = {
.height = 165,
},
.delay = {
- .hpd_absent_delay = 200,
+ /*
+* When power is first given to the panel there's a short
+* spike on the HPD line. It was explained that this spike
+* was until the TCON data download was complete. On
+* one system this was measured at 8 ms. We'll put 15 ms
+* in the prepare delay just to be safe and take it away
+* from the hpd_absent_delay (which would otherwise be 200 ms)
+* to handle this. That means:
+* - If HPD isn't hooked up you still have 200 ms delay.
+* - If HPD is hooked up we won't try to look at it for the
+* first 15 ms.
+*/
+ .prepare = 15,
+ .hpd_absent_delay = 185,
+
.unprepare = 500,
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
--
2.28.0.rc0.105.gf9edc3c819-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: hold gem reference until object is no longer accessed
Hi Steve and others.
On Fri, Jul 10, 2020 at 06:40:26PM -0400, Steve Cohen wrote:
> BUG: KASAN: use-after-free in drm_gem_open_ioctl
>
> There is potential for use-after-free here if the GEM object
> handle is closed between the idr lookup and retrieving the size
> from the object since a local reference is not being held at that
> point. Hold the local reference while the object can still be
> accessed to resolve this.
>
> Signed-off-by: Steve Cohen
> ---
> drivers/gpu/drm/drm_gem.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 7bf628e..4b2891c 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -898,14 +898,15 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
>
> /* drm_gem_handle_create_tail unlocks dev->object_name_lock. */
> ret = drm_gem_handle_create_tail(file_priv, obj, &handle);
> - drm_gem_object_put_unlocked(obj);
> if (ret)
> - return ret;
> + goto out;
>
> args->handle = handle;
> args->size = obj->size;
>
> - return 0;
> +out:
> + drm_gem_object_put_unlocked(obj);
> + return ret;
Lookign at drm_gem_flink_ioctl() that is implmented just above this
functions there are two things that I noted.
1) In drm_gem_flink_ioctl() the label is named "err:" - and my OCD likes
that similar labels have the same name.
2) The function takes the object_name_lock but fails to release it in
the error situation.
Danile Vetter updated the locking in
20228c447846da9399ead53fdbbc8ab69b47788a ("drm/gem: completely close gem_open
vs. gem_close races")
but I failed to follow it all.
Sam
> }
>
> /**
> --
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote: > > Hi everybody, > > with the mentioned commit Nouveau isn't able to load firmware onto the > GPU on one of my systems here. Even though the issue doesn't always > happen I am quite confident this is the commit breaking it. > > I am still digging into the issue and trying to figure out what > exactly breaks, but it shows up in different ways. Either we are not > able to boot the engines on the GPU or the GPU becomes unresponsive. > Btw, this is also a system where our runtime power management issue > shows up, so maybe there is indeed something funky with the bridge > controller. > > Just pinging you in case you have an idea on how this could break Nouveau > > most of the times it shows up like this: > nouveau :01:00.0: acr: AHESASC binary failed > > Sometimes it works at boot and fails at runtime resuming with random > faults. So I will be investigating a bit more, but yeah... I am super > sure the commit triggered this issue, no idea if it actually causes > it. > so yeah.. I reverted that locally and never ran into issues again. Still valid on latest 5.7. So can we get this reverted or properly fixed? This breaks runtime pm for us on at least some hardware. > git bisect log (had to do a second bisect, that's why the first bad > and good commits appear a bit random): > > git bisect start > # bad: [a92b984a110863b42a3abf32e3f049b02b19e350] clk: samsung: > exynos5433: Add IGNORE_UNUSED flag to sclk_i2s1 > git bisect bad a92b984a110863b42a3abf32e3f049b02b19e350 > # good: [4da858c086433cd012c0bb16b5921f6fafe3f803] Merge branch > 'linux-5.7' of git://github.com/skeggsb/linux into drm-fixes > git bisect good 4da858c086433cd012c0bb16b5921f6fafe3f803 > # good: [d5dfe4f1b44ed532653c2335267ad9599c8a698e] Merge tag > 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma > git bisect good d5dfe4f1b44ed532653c2335267ad9599c8a698e > # good: [b24e451cfb8c33ef5b8b4a80e232706b089914fb] ipv6: fix > IPV6_ADDRFORM operation logic > git bisect good b24e451cfb8c33ef5b8b4a80e232706b089914fb > # good: [d843ffbce812742986293f974d55ba404e91872f] nvmet: fix memory > leak when removing namespaces and controllers concurrently > git bisect good d843ffbce812742986293f974d55ba404e91872f > # good: [be66f10a60e3ec0b589898f78a428bcb34095730] staging: wfx: fix > output of rx_stats on big endian hosts > git bisect good be66f10a60e3ec0b589898f78a428bcb34095730 > # good: [a4482984c41f5cc1d217aa189fe51bbbc0500f98] s390/qdio: > consistently restore the IRQ handler > git bisect good a4482984c41f5cc1d217aa189fe51bbbc0500f98 > # good: [bec32a54a4de62b46466f4da1beb9ddd42db81b8] f2fs: fix potential > use-after-free issue > git bisect good bec32a54a4de62b46466f4da1beb9ddd42db81b8 > # bad: [0448b1b15adb397ce423a6d97920a46b3893] habanalabs: increase > timeout during reset > git bisect bad 0448b1b15adb397ce423a6d97920a46b3893 > # good: [6fe8ed270763a6a2e350bf37eee0f3857482ed48] arm64: dts: qcom: > db820c: Fix invalid pm8994 supplies > git bisect good 6fe8ed270763a6a2e350bf37eee0f3857482ed48 > # good: [363e8bfc96b4e9d9e0a885408cecaf23df468523] tty: n_gsm: Fix > waking up upper tty layer when room available > git bisect good 363e8bfc96b4e9d9e0a885408cecaf23df468523 > # bad: [afaff825e3a436f9d1e3986530133b1c91b54cd1] PCI/PM: Assume ports > without DLL Link Active train links in 100 ms > git bisect bad afaff825e3a436f9d1e3986530133b1c91b54cd1 > # good: [be0ed15d88c65de0e28ff37a3b242e65a782fd98] HID: Add quirks for > Trust Panora Graphic Tablet > git bisect good be0ed15d88c65de0e28ff37a3b242e65a782fd98 > # first bad commit: [afaff825e3a436f9d1e3986530133b1c91b54cd1] PCI/PM: > Assume ports without DLL Link Active train links in 100 ms ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm/mgag200: Add support for G200 desktop cards
On Wed, 2020-07-15 at 16:59 +0200, Thomas Zimmermann wrote:
> This patch adds support for G200 desktop cards. We can reuse the whole
> memory and modesetting code. A few PCI and DAC register values have to
> be updated accordingly.
>
> The most significant change is in the PLL setup. The get the clock limits
> and reference clocks, parses the device's BIOS. With no BIOS found, safe
> defaults are being used.
>
> Signed-off-by: Thomas Zimmermann
> Co-developed-by: Egbert Eich
> Signed-off-by: Egbert Eich
> Co-developed-by: Takashi Iwai
> Signed-off-by: Takashi Iwai
> ---
> MAINTAINERS| 2 +-
> drivers/gpu/drm/mgag200/Kconfig| 12 +--
> drivers/gpu/drm/mgag200/mgag200_drv.c | 125 -
> drivers/gpu/drm/mgag200/mgag200_drv.h | 10 ++
> drivers/gpu/drm/mgag200/mgag200_mode.c | 80
> 5 files changed, 220 insertions(+), 9 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 415954a98934..4c6f96e2b79b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5406,7 +5406,7 @@ S: Orphan / Obsolete
> F: drivers/gpu/drm/mga/
> F: include/uapi/drm/mga_drm.h
>
> -DRM DRIVER FOR MGA G200 SERVER GRAPHICS CHIPS
> +DRM DRIVER FOR MGA G200 GRAPHICS CHIPS
> M: Dave Airlie
> S: Odd Fixes
> F: drivers/gpu/drm/mgag200/
> diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig
> index 93be766715c9..eec59658a938 100644
> --- a/drivers/gpu/drm/mgag200/Kconfig
> +++ b/drivers/gpu/drm/mgag200/Kconfig
> @@ -1,13 +1,11 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config DRM_MGAG200
> - tristate "Kernel modesetting driver for MGA G200 server engines"
> + tristate "Matrox G200"
> depends on DRM && PCI && MMU
> select DRM_GEM_SHMEM_HELPER
> select DRM_KMS_HELPER
> help
> - This is a KMS driver for the MGA G200 server chips, it
> - does not support the original MGA G200 or any of the desktop
> - chips. It requires 0.3.0 of the modesetting userspace driver,
> - and a version of mga driver that will fail on KMS enabled
> - devices.
> -
> + This is a KMS driver for Matrox G200 chips. It supports the original
> + MGA G200 desktop chips and the server variants. It requires 0.3.0
> + of the modesetting userspace driver, and a version of mga driver
> + that will fail on KMS enabled devices.
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
> b/drivers/gpu/drm/mgag200/mgag200_drv.c
> index f7652e16365c..419817d6e2cd 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> @@ -64,6 +64,14 @@ static int mgag200_regs_init(struct mga_device *mdev)
> u8 crtcext3;
>
> switch (mdev->type) {
> + case G200_PCI:
> + case G200_AGP:
> + if (mgag200_has_sgram(mdev))
> + option = 0x4049cd21;
> + else
> + option = 0x40499121;
> + option2 = 0x8000;
> + break;
> case G200_SE_A:
> case G200_SE_B:
> if (mgag200_has_sgram(mdev))
> @@ -115,6 +123,117 @@ static int mgag200_regs_init(struct mga_device *mdev)
> return 0;
> }
>
> +static void mgag200_g200_interpret_bios(struct mga_device *mdev,
> + unsigned char __iomem *bios,
> + size_t size)
> +{
> + static const unsigned int expected_length[6] = {
> + 0, 64, 64, 64, 128, 128
> + };
> +
> + struct drm_device *dev = &mdev->base;
> + unsigned char __iomem *pins;
huh, never realized you could write directly to unsigned char __iomem pointers!
> + unsigned int pins_len, version;
> + int offset;
> + int tmp;
> +
> + if (size < MGA_BIOS_OFFSET + 1)
> + return;
> +
> + if (bios[45] != 'M' || bios[46] != 'A' || bios[47] != 'T' ||
> + bios[48] != 'R' || bios[49] != 'O' || bios[50] != 'X')
> + return;
> +
> + offset = (bios[MGA_BIOS_OFFSET + 1] << 8) | bios[MGA_BIOS_OFFSET];
> +
> + if (offset + 5 > size)
> + return;
> +
> + pins = bios + offset;
> + if (pins[0] == 0x2e && pins[1] == 0x41) {
> + version = pins[5];
> + pins_len = pins[2];
> + } else {
> + version = 1;
> + pins_len = pins[0] + (pins[1] << 8);
> + }
> +
> + if (version < 1 || version > 5) {
> + drm_warn(dev, "Unknown BIOS PInS version: %d\n", version);
Did you maybe mean pins or PINS here? or is PInS some weird abbreviation matrox
uses?
> + return;
> + }
> + if (pins_len != expected_length[version]) {
> + drm_warn(dev, "Unexpected BIOS PInS size: %d expeced: %d\n",
> + pins_len, expected_length[version]);
> + return;
> + }
> +
> + if (offset + pins_len > size)
> + return;
> +
> + drm_dbg_kms(dev, "MATROX BIOS PInS
[GIT PULL] mediatek drm next for 5.9
Hi, Dave & Daniel: This include converting mtk_dsi to drm_bridge API. Regards, Chun-Kuang. The following changes since commit 5ab546f5e6309373aef01a8d398e163ab7a78431: drm/mediatek: mtk_hdmi: Remove debug messages for function calls (2020-07-05 06:39:21 +0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git tags/mediatek-drm-next-5.9 for you to fetch changes up to a9d9fea74be285a2885d8f3395042cc4dde27e6a: drm/mediatek: mtk_dsi: Create connector for bridges (2020-07-05 08:06:28 +0800) Mediatek DRM Next for Linux 5.9 Enric Balletbo i Serra (5): drm/mediatek: mtk_dsi: Rename bridge to next_bridge drm/mediatek: mtk_dsi: Convert to bridge driver drm/mediatek: mtk_dsi: Use simple encoder drm/mediatek: mtk_dsi: Use the drm_panel_bridge API drm/mediatek: mtk_dsi: Create connector for bridges drivers/gpu/drm/mediatek/mtk_dsi.c | 269 - 1 file changed, 84 insertions(+), 185 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
[+cc Sasha -- stable kernel regression]
[+cc Patrick, Kai-Heng, LKML]
On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> >
> > Hi everybody,
> >
> > with the mentioned commit Nouveau isn't able to load firmware onto the
> > GPU on one of my systems here. Even though the issue doesn't always
> > happen I am quite confident this is the commit breaking it.
> >
> > I am still digging into the issue and trying to figure out what
> > exactly breaks, but it shows up in different ways. Either we are not
> > able to boot the engines on the GPU or the GPU becomes unresponsive.
> > Btw, this is also a system where our runtime power management issue
> > shows up, so maybe there is indeed something funky with the bridge
> > controller.
> >
> > Just pinging you in case you have an idea on how this could break Nouveau
> >
> > most of the times it shows up like this:
> > nouveau :01:00.0: acr: AHESASC binary failed
> >
> > Sometimes it works at boot and fails at runtime resuming with random
> > faults. So I will be investigating a bit more, but yeah... I am super
> > sure the commit triggered this issue, no idea if it actually causes
> > it.
>
> so yeah.. I reverted that locally and never ran into issues again.
> Still valid on latest 5.7. So can we get this reverted or properly
> fixed? This breaks runtime pm for us on at least some hardware.
Yeah, that stinks. We had another similar report from Patrick:
https://lore.kernel.org/r/caerspo5stek_my1dehwp7ahd0xop87+ohywktjbl7algdbx...@mail.gmail.com
Apparently the problem is ec411e02b7a2 ("PCI/PM: Assume ports without
DLL Link Active train links in 100 ms"), which Patrick found was
backported to v5.4.49 as 828b192c57e8, and you found was backported to
v5.7.6 as afaff825e3a4.
Oddly, Patrick reported that v5.7.7 worked correctly, even though it
still contains afaff825e3a4.
I guess in the absence of any other clues we'll have to revert it.
I hate to do that because that means we'll have slow resume of
Thunderbolt-connected devices again, but that's better than having
GPUs completely broken.
Could you and Patrick open bugzilla.kernel.org reports, attach dmesg
logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's
original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837
and to this thread?
There must be a way to fix the slow resume problem without breaking
the GPUs.
Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] sw_sync deadlock avoidance, take 3
Hi all, On Wed, 15 Jul 2020 at 12:57, Daniel Vetter wrote: > On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote: > > On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen > > wrote: > > > Yes, this is used as part of the Android stack on Chrome OS (need to > > > see if ChromeOS specific, but > > > https://source.android.com/devices/graphics/sync#sync_timeline > > > suggests not) > > > > Android used to mandate it for their earlier iteration of release > > fences, which was an empty/future fence having no guarantee of > > eventual forward progress until someone committed work later on. For > > example, when you committed a buffer to SF, it would give you an empty > > 'release fence' for that buffer which would only be tied to work to > > signal it when you committed your _next_ buffer, which might never > > happen. They removed that because a) future fences were a bad idea, > > and b) it was only ever useful if you assumed strictly > > FIFO/round-robin return order which wasn't always true. > > > > So now it's been watered down to 'use this if you don't have a > > hardware timeline', but why don't we work with Android people to get > > that removed entirely? > > I think there's some testcases still using these, but most real fence > testcases use vgem nowadays. So from an upstream pov there's indeed > not much if anything holding us back from just deleting this all. And > would probably be a good idea. It looks like this is just a docs hangover which can be fixed; sw_sync is no longer part of the unified Android kernel image, so it can no longer be relied on post-Treble. So let's just continue on the assumption that sw_sync is not anything anyone can rely on. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
>
> [+cc Sasha -- stable kernel regression]
> [+cc Patrick, Kai-Heng, LKML]
>
> On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> > On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> > >
> > > Hi everybody,
> > >
> > > with the mentioned commit Nouveau isn't able to load firmware onto the
> > > GPU on one of my systems here. Even though the issue doesn't always
> > > happen I am quite confident this is the commit breaking it.
> > >
> > > I am still digging into the issue and trying to figure out what
> > > exactly breaks, but it shows up in different ways. Either we are not
> > > able to boot the engines on the GPU or the GPU becomes unresponsive.
> > > Btw, this is also a system where our runtime power management issue
> > > shows up, so maybe there is indeed something funky with the bridge
> > > controller.
> > >
> > > Just pinging you in case you have an idea on how this could break Nouveau
> > >
> > > most of the times it shows up like this:
> > > nouveau :01:00.0: acr: AHESASC binary failed
> > >
> > > Sometimes it works at boot and fails at runtime resuming with random
> > > faults. So I will be investigating a bit more, but yeah... I am super
> > > sure the commit triggered this issue, no idea if it actually causes
> > > it.
> >
> > so yeah.. I reverted that locally and never ran into issues again.
> > Still valid on latest 5.7. So can we get this reverted or properly
> > fixed? This breaks runtime pm for us on at least some hardware.
>
> Yeah, that stinks. We had another similar report from Patrick:
>
>
> https://lore.kernel.org/r/caerspo5stek_my1dehwp7ahd0xop87+ohywktjbl7algdbx...@mail.gmail.com
>
> Apparently the problem is ec411e02b7a2 ("PCI/PM: Assume ports without
> DLL Link Active train links in 100 ms"), which Patrick found was
> backported to v5.4.49 as 828b192c57e8, and you found was backported to
> v5.7.6 as afaff825e3a4.
>
> Oddly, Patrick reported that v5.7.7 worked correctly, even though it
> still contains afaff825e3a4.
>
> I guess in the absence of any other clues we'll have to revert it.
> I hate to do that because that means we'll have slow resume of
> Thunderbolt-connected devices again, but that's better than having
> GPUs completely broken.
>
> Could you and Patrick open bugzilla.kernel.org reports, attach dmesg
> logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's
> original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837
> and to this thread?
>
> There must be a way to fix the slow resume problem without breaking
> the GPUs.
>
I wouldn't be surprised if this is related to the Intel bridge we
check against for Nouveau.. I still have to check on another laptop
with the same bridge our workaround was required as well but wouldn't
be surprised if it shows the same problem. Will get you the
information from both systems tomorrow then.
> Bjorn
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 1066/1110] drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:1233:3: warning: variable 'direct_poll' set but not used
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: cefd5db37208da458fa10f83f866f2f37eef70e9
commit: 4a33206e976be79b832d5a826565b5cb430de877 [1066/1110] drm/amd/sriov
porting sriov cap to vcn3.0
config: parisc-randconfig-r015-20200717 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4a33206e976be79b832d5a826565b5cb430de877
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=parisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/mm.h:94,
from include/drm/drm_vma_manager.h:27,
from include/drm/drm_gem.h:40,
from include/drm/ttm/ttm_bo_api.h:34,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:53,
from drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:25:
include/asm-generic/pgtable.h: In function 'pte_clear_not_present_full':
arch/parisc/include/asm/pgtable.h:96:9: warning: variable 'old_pte' set but
not used [-Wunused-but-set-variable]
96 | pte_t old_pte; \
| ^~~
arch/parisc/include/asm/pgtable.h:322:34: note: in expansion of macro
'set_pte_at'
322 | #define pte_clear(mm, addr, xp) set_pte_at(mm, addr, xp, __pte(0))
| ^~
include/asm-generic/pgtable.h:201:2: note: in expansion of macro 'pte_clear'
201 | pte_clear(mm, address, ptep);
| ^
include/asm-generic/pgtable.h: In function '__ptep_modify_prot_commit':
arch/parisc/include/asm/pgtable.h:96:9: warning: variable 'old_pte' set but
not used [-Wunused-but-set-variable]
96 | pte_t old_pte; \
| ^~~
include/asm-generic/pgtable.h:640:2: note: in expansion of macro 'set_pte_at'
640 | set_pte_at(vma->vm_mm, addr, ptep, pte);
| ^~
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c: In function 'vcn_v3_0_start_sriov':
>> drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:1233:3: warning: variable
>> 'direct_poll' set but not used [-Wunused-but-set-variable]
1233 | direct_poll = { {0} };
| ^~~
In file included from drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:25:
At top level:
drivers/gpu/drm/amd/amdgpu/amdgpu.h:192:19: warning: 'debug_evictions'
defined but not used [-Wunused-const-variable=]
192 | static const bool debug_evictions; /* = false */
| ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:191:18: warning: 'sched_policy' defined
but not used [-Wunused-const-variable=]
191 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
| ^~~~
In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:65,
from drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:25:
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:76:32: warning:
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:75:32: warning:
'dc_fixpt_ln2' defined but not used [-Wunused-const-variable=]
75 | static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
|^~~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:74:32: warning:
'dc_fixpt_e' defined but not used [-Wunused-const-variable=]
74 | static const struct fixed31_32 dc_fixpt_e = { 11674931555LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:73:32: warning:
'dc_fixpt_two_pi' defined but not used [-Wunused-const-variable=]
73 | static const struct fixed31_32 dc_fixpt_two_pi = { 26986075409LL };
|^~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:72:32: warning:
'dc_fixpt_pi' defined but not used [-Wunused-const-variable=]
72 | static const struct fixed31_32 dc_fixpt_pi = { 13493037705LL };
|^~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:67:32: warning:
'dc_fixpt_zero' defined but not used [-Wunused-const-variable=]
67 | static const struct fixed31_32 dc_fixpt_zero = {
Re: [PATCH v2 11/22] drm: mxsfb: Stop using DRM simple display pipeline helper
Hi Stefan,
On Thu, Jul 09, 2020 at 12:25:42PM +0200, Stefan Agner wrote:
> On 2020-06-16 03:50, Laurent Pinchart wrote:
> > On Thu, Jun 11, 2020 at 09:33:11PM +0200, Stefan Agner wrote:
> >> On 2020-05-30 05:10, Laurent Pinchart wrote:
> >> > The DRM simple display pipeline helper only supports a single plane. In
> >> > order to prepare for support of the alpha plane on i.MX6SX and i.MX7,
> >> > move away from the helper. No new feature is added.
> >> >
> >> > Signed-off-by: Laurent Pinchart
> >> > ---
> >> > Changes since v1:
> >> >
> >> > - Move after mxsfb_crtc.c rename to mxsfb_kms.c
> >> > ---
> >> > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 108 +++---
> >> > drivers/gpu/drm/mxsfb/mxsfb_drv.h | 23 ++--
> >> > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 184 +++---
> >> > 3 files changed, 197 insertions(+), 118 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > index 204c1e52e9aa..a8da92976d13 100644
> >> > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > @@ -10,22 +10,23 @@
> >> >
> >> > #include
> >> > #include
> >> > +#include
> >> > #include
> >> > #include
> >> > +#include
> >> > #include
> >> > -#include
> >> >
> >> > -#include
> >> > #include
> >> > -#include
> >> > +#include
> >> > +#include
> >> > #include
> >> > #include
> >> > #include
> >> > #include
> >> > #include
> >> > +#include
> >> > #include
> >> > #include
> >> > -#include
> >> > #include
> >> >
> >> > #include "mxsfb_drv.h"
> >> > @@ -57,17 +58,6 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
> >> > },
> >> > };
> >> >
> >> > -static const uint32_t mxsfb_formats[] = {
> >> > -DRM_FORMAT_XRGB,
> >> > -DRM_FORMAT_RGB565
> >> > -};
> >> > -
> >> > -static struct mxsfb_drm_private *
> >> > -drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe *pipe)
> >> > -{
> >> > -return container_of(pipe, struct mxsfb_drm_private, pipe);
> >> > -}
> >> > -
> >> > void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
> >> > {
> >> > if (mxsfb->clk_axi)
> >> > @@ -90,77 +80,6 @@ static const struct drm_mode_config_helper_funcs
> >> > mxsfb_mode_config_helpers = {
> >> > .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> >> > };
> >> >
> >> > -static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
> >> > - struct drm_crtc_state *crtc_state,
> >> > - struct drm_plane_state *plane_state)
> >> > -{
> >> > -struct mxsfb_drm_private *mxsfb =
> >> > drm_pipe_to_mxsfb_drm_private(pipe);
> >> > -struct drm_device *drm = pipe->plane.dev;
> >> > -
> >> > -pm_runtime_get_sync(drm->dev);
> >> > -mxsfb_crtc_enable(mxsfb);
> >> > -}
> >> > -
> >> > -static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
> >> > -{
> >> > -struct mxsfb_drm_private *mxsfb =
> >> > drm_pipe_to_mxsfb_drm_private(pipe);
> >> > -struct drm_device *drm = pipe->plane.dev;
> >> > -struct drm_crtc *crtc = &pipe->crtc;
> >> > -struct drm_pending_vblank_event *event;
> >> > -
> >> > -mxsfb_crtc_disable(mxsfb);
> >> > -pm_runtime_put_sync(drm->dev);
> >> > -
> >> > -spin_lock_irq(&drm->event_lock);
> >> > -event = crtc->state->event;
> >> > -if (event) {
> >> > -crtc->state->event = NULL;
> >> > -drm_crtc_send_vblank_event(crtc, event);
> >> > -}
> >> > -spin_unlock_irq(&drm->event_lock);
> >> > -}
> >> > -
> >> > -static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
> >> > - struct drm_plane_state *plane_state)
> >> > -{
> >> > -struct mxsfb_drm_private *mxsfb =
> >> > drm_pipe_to_mxsfb_drm_private(pipe);
> >> > -
> >> > -mxsfb_plane_atomic_update(mxsfb, plane_state);
> >> > -}
> >> > -
> >> > -static int mxsfb_pipe_enable_vblank(struct drm_simple_display_pipe
> >> > *pipe)
> >> > -{
> >> > -struct mxsfb_drm_private *mxsfb =
> >> > drm_pipe_to_mxsfb_drm_private(pipe);
> >> > -
> >> > -/* Clear and enable VBLANK IRQ */
> >> > -mxsfb_enable_axi_clk(mxsfb);
> >> > -writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 +
> >> > REG_CLR);
> >> > -writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 +
> >> > REG_SET);
> >> > -mxsfb_disable_axi_clk(mxsfb);
> >> > -
> >> > -return 0;
> >> > -}
> >> > -
> >> > -static void mxsfb_pipe_disable_vblank(struct drm_simple_display_pipe
> >> > *pipe)
> >> > -{
> >> > -struct mxsfb_drm_private *mxsfb =
> >> > drm_pipe_to_mxsfb_drm_private(pipe);
> >> > -
> >> > -/* Disable and clear VBLANK IRQ */
> >> > -mxsfb_enable_axi_clk(mxsfb);
> >> > -writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_
Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers
Hi Christian, On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote: > On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote: > > Am 21.06.20 um 04:07 schrieb Laurent Pinchart: > > > Most of the DRM drivers uAPI headers are licensed under the MIT license, > > > and carry copies of the license with slight variations. Replace them > > > with SPDX headers. > > > > My personal opinion is that this is a really good idea, but my professional > > is that we need the acknowledgment from our legal department for this. > > I think official ack from amd on first patch, especially the .rst snippet, > would be really good indeed. Any update on this one ? > > Please separate that change into one for each driver/company/maintainer. > > Amdgpu, radeon, r128 can be one for example. I'll do so. > You can leave all the other legacy drivers in one patch (mga, savage, sis, > via), since there's likely no one around anymore and will just boil down > to drm maintainer ack from Dave&me. > > > > Signed-off-by: Laurent Pinchart > > > > > > --- > > > include/uapi/drm/amdgpu_drm.h | 19 +-- > > > include/uapi/drm/i915_drm.h| 22 +- > > > include/uapi/drm/mga_drm.h | 20 +--- > > > include/uapi/drm/msm_drm.h | 20 +--- > > > include/uapi/drm/nouveau_drm.h | 20 +--- > > > include/uapi/drm/qxl_drm.h | 20 +--- > > > include/uapi/drm/r128_drm.h| 20 +--- > > > include/uapi/drm/radeon_drm.h | 20 +--- > > > include/uapi/drm/savage_drm.h | 20 +--- > > > include/uapi/drm/sis_drm.h | 21 + > > > include/uapi/drm/tegra_drm.h | 19 +-- > > > include/uapi/drm/v3d_drm.h | 20 +--- > > > include/uapi/drm/vc4_drm.h | 20 +--- > > > include/uapi/drm/vgem_drm.h| 22 +- > > > include/uapi/drm/via_drm.h | 20 +--- > > > include/uapi/drm/virtgpu_drm.h | 20 +--- > > > include/uapi/drm/vmwgfx_drm.h | 21 + > > > 17 files changed, 17 insertions(+), 327 deletions(-) > > > > > > diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h > > > index 4e873dcbe68f..c6adda72bec7 100644 > > > --- a/include/uapi/drm/amdgpu_drm.h > > > +++ b/include/uapi/drm/amdgpu_drm.h > > > @@ -1,3 +1,4 @@ > > > +/* SPDX-License-Identifier: MIT */ > > > /* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c -*- > > >* > > >* Copyright 2000 Precision Insight, Inc., Cedar Park, Texas. > > > @@ -5,24 +6,6 @@ > > >* Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas. > > >* Copyright 2014 Advanced Micro Devices, Inc. > > >* > > > - * Permission is hereby granted, free of charge, to any person obtaining > > > a > > > - * copy of this software and associated documentation files (the > > > "Software"), > > > - * to deal in the Software without restriction, including without > > > limitation > > > - * the rights to use, copy, modify, merge, publish, distribute, > > > sublicense, > > > - * and/or sell copies of the Software, and to permit persons to whom the > > > - * Software is furnished to do so, subject to the following conditions: > > > - * > > > - * The above copyright notice and this permission notice shall be > > > included in > > > - * all copies or substantial portions of the Software. > > > - * > > > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > > EXPRESS OR > > > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > > MERCHANTABILITY, > > > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > > > SHALL > > > - * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES > > > OR > > > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > > > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > > > - * OTHER DEALINGS IN THE SOFTWARE. > > > - * > > >* Authors: > > >*Kevin E. Martin > > >*Gareth Hughes > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > > index 14b67cd6b54b..c29e3acb3026 100644 > > > --- a/include/uapi/drm/i915_drm.h > > > +++ b/include/uapi/drm/i915_drm.h > > > @@ -1,27 +1,7 @@ > > > +/* SPDX-License-Identifier: MIT */ > > > /* > > >* Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas. > > >* All Rights Reserved. > > > - * > > > - * Permission is hereby granted, free of charge, to any person obtaining > > > a > > > - * copy of this software and associated documentation files (the > > > - * "Software"), to deal in the Software without restriction, including > > > - * without limitation the rights to use, copy, modify, merge, publish, > > > - * distribute, sub license, and/or sell copies of the Software, and to > > > - * permit persons to whom
[git pull] drm fixes for 5.8-rc6
Hi Linus, Weekly fixes pull, big bigger than I'd normally like, but they are fairly scattered and small individually. The vmwgfx one is a black screen regression, otherwise the largest is an MST encoder fix for amdgpu which results in a WARN in some cases, and a scattering of i915 fixes. I'm tracking two regressions at the moment that hopefully we get nailed down this week for rc7. Dave. drm-fixes-2020-07-17-1: drm fixes for 5.8-rc6 dma-buf: - sleeping atomic fix amdgpu: - Fix a race condition with KIQ - Preemption fix - Fix handling of fake MST encoders - OLED panel fix - Handle allocation failure in stream construction - Renoir SMC fix - SDMA 5.x fix i915: - FBC w/a stride fix - Fix use-after-free fix on module reload - Ignore irq enabling on the virtual engines to fix device sleep - Use GTT when saving/restoring engine GPR - Fix selftest sort function vmwgfx: - black screen fix aspeed: - fbcon init warn fix The following changes since commit 11ba468877bb23f28956a35e896356252d63c983: Linux 5.8-rc5 (2020-07-12 16:34:50 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-17-1 for you to fetch changes up to adbe8a3cae94a63e9f416795c750237a9b789124: Merge tag 'amd-drm-fixes-5.8-2020-07-15' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-07-17 13:29:00 +1000) drm fixes for 5.8-rc6 dma-buf: - sleeping atomic fix amdgpu: - Fix a race condition with KIQ - Preemption fix - Fix handling of fake MST encoders - OLED panel fix - Handle allocation failure in stream construction - Renoir SMC fix - SDMA 5.x fix i915: - FBC w/a stride fix - Fix use-after-free fix on module reload - Ignore irq enabling on the virtual engines to fix device sleep - Use GTT when saving/restoring engine GPR - Fix selftest sort function vmwgfx: - black screen fix aspeed: - fbcon init warn fix Alex Deucher (1): drm/amdgpu/display: create fake mst encoders ahead of time (v4) Charan Teja Kalla (1): dmabuf: use spinlock to access dmabuf->name Chris Wilson (2): drm/i915/gt: Ignore irq enabling on the virtual engines drm/i915/gt: Only swap to a random sibling once upon creation Dave Airlie (4): Merge branch 'vmwgfx-fixes-5.8' of git://people.freedesktop.org/~sroland/linux into drm-fixes Merge tag 'drm-misc-fixes-2020-07-15' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2020-07-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'amd-drm-fixes-5.8-2020-07-15' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Guenter Roeck (1): drm/aspeed: Call drm_fbdev_generic_setup after drm_dev_register Jack Xiao (2): drm/amdgpu/gfx10: fix race condition for kiq drm/amdgpu: fix preemption unit test Josip Pavic (1): drm/amd/display: handle failed allocation during stream construction Maarten Lankhorst (1): drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2. Roland Scheidegger (1): drm/vmwgfx: fix update of display surface when resolution changes Sudeep Holla (1): drm/i915/selftests: Fix compare functions provided for sorting Umesh Nerlige Ramappa (1): drm/i915/perf: Use GTT when saving/restoring engine GPR Ville Syrjälä (1): drm/i915: Recalculate FBC w/a stride when needed Xiaojie Yuan (1): drm/amdgpu/sdma5: fix wptr overwritten in ->get_wptr() chen gong (1): drm/amdgpu/powerplay: Modify SMC message name for setting power profile mode hersen wu (1): drm/amd/display: OLED panel backlight adjust not work with external display connected drivers/dma-buf/dma-buf.c | 11 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 20 ++-- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 9 +++- drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 26 --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 ++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 11 - .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 53 +++--- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h| 3 ++ drivers/gpu/drm/amd/display/dc/core/dc_stream.c| 19 ++-- drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 2 +- drivers/gpu/drm/aspeed/aspeed_gfx_drv.c| 3 +- drivers/gpu/drm/i915/display/intel_fbc.c | 33 +++--- drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +--- drivers/gpu/drm/i915/gt/intel_lrc.c| 19 ++-- drivers/gpu/drm/i915/gt/selftest_rps.c | 8 ++-- drivers/gpu/drm/i915/i915_drv.h| 1 + drivers/gpu/drm/i915/i915_perf.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 ++-- include/linux/dma-buf.h
[Bug 208587] amdgpu hang and gnome shell crash if playing video on 5600M with DRI_PRIME
https://bugzilla.kernel.org/show_bug.cgi?id=208587 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Does appending amdgpu.runpm=0 to the kernel command line in grub fix the issue? -- 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 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #31 from Alex Deucher (alexdeuc...@gmail.com) --- Duplicate of bug 207979. -- 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 208589] amdgpu screen corruption with DRI_PRIME on external monitor at resolution 2560x1440 and more then 60hz
https://bugzilla.kernel.org/show_bug.cgi?id=208589 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Does appending amdgpu.runpm=0 to the kernel command line in grub fix the issue? -- 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: [git pull] drm fixes for 5.8-rc6
The pull request you sent on Fri, 17 Jul 2020 13:42:02 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-17-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8882572675c1bb1cc544f4e229a11661f1fc52e4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm/mgag200: Add support for G200 desktop cards
Hi Lyude.
On Thu, Jul 16, 2020 at 06:43:40PM -0400, Lyude Paul wrote:
> On Wed, 2020-07-15 at 16:59 +0200, Thomas Zimmermann wrote:
> > This patch adds support for G200 desktop cards. We can reuse the whole
> > memory and modesetting code. A few PCI and DAC register values have to
> > be updated accordingly.
> >
> > The most significant change is in the PLL setup. The get the clock limits
> > and reference clocks, parses the device's BIOS. With no BIOS found, safe
> > defaults are being used.
> >
> > Signed-off-by: Thomas Zimmermann
> > Co-developed-by: Egbert Eich
> > Signed-off-by: Egbert Eich
> > Co-developed-by: Takashi Iwai
> > Signed-off-by: Takashi Iwai
> > ---
> > MAINTAINERS| 2 +-
> > drivers/gpu/drm/mgag200/Kconfig| 12 +--
> > drivers/gpu/drm/mgag200/mgag200_drv.c | 125 -
> > drivers/gpu/drm/mgag200/mgag200_drv.h | 10 ++
> > drivers/gpu/drm/mgag200/mgag200_mode.c | 80
> > 5 files changed, 220 insertions(+), 9 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 415954a98934..4c6f96e2b79b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -5406,7 +5406,7 @@ S:Orphan / Obsolete
> > F: drivers/gpu/drm/mga/
> > F: include/uapi/drm/mga_drm.h
> >
> > -DRM DRIVER FOR MGA G200 SERVER GRAPHICS CHIPS
> > +DRM DRIVER FOR MGA G200 GRAPHICS CHIPS
> > M: Dave Airlie
> > S: Odd Fixes
> > F: drivers/gpu/drm/mgag200/
> > diff --git a/drivers/gpu/drm/mgag200/Kconfig
> > b/drivers/gpu/drm/mgag200/Kconfig
> > index 93be766715c9..eec59658a938 100644
> > --- a/drivers/gpu/drm/mgag200/Kconfig
> > +++ b/drivers/gpu/drm/mgag200/Kconfig
> > @@ -1,13 +1,11 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > config DRM_MGAG200
> > - tristate "Kernel modesetting driver for MGA G200 server engines"
> > + tristate "Matrox G200"
> > depends on DRM && PCI && MMU
> > select DRM_GEM_SHMEM_HELPER
> > select DRM_KMS_HELPER
> > help
> > -This is a KMS driver for the MGA G200 server chips, it
> > -does not support the original MGA G200 or any of the desktop
> > -chips. It requires 0.3.0 of the modesetting userspace driver,
> > -and a version of mga driver that will fail on KMS enabled
> > -devices.
> > -
> > +This is a KMS driver for Matrox G200 chips. It supports the original
> > +MGA G200 desktop chips and the server variants. It requires 0.3.0
> > +of the modesetting userspace driver, and a version of mga driver
> > +that will fail on KMS enabled devices.
> > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
> > b/drivers/gpu/drm/mgag200/mgag200_drv.c
> > index f7652e16365c..419817d6e2cd 100644
> > --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> > @@ -64,6 +64,14 @@ static int mgag200_regs_init(struct mga_device *mdev)
> > u8 crtcext3;
> >
> > switch (mdev->type) {
> > + case G200_PCI:
> > + case G200_AGP:
> > + if (mgag200_has_sgram(mdev))
> > + option = 0x4049cd21;
> > + else
> > + option = 0x40499121;
> > + option2 = 0x8000;
> > + break;
> > case G200_SE_A:
> > case G200_SE_B:
> > if (mgag200_has_sgram(mdev))
> > @@ -115,6 +123,117 @@ static int mgag200_regs_init(struct mga_device *mdev)
> > return 0;
> > }
> >
> > +static void mgag200_g200_interpret_bios(struct mga_device *mdev,
> > + unsigned char __iomem *bios,
> > + size_t size)
> > +{
> > + static const unsigned int expected_length[6] = {
> > + 0, 64, 64, 64, 128, 128
> > + };
> > +
> > + struct drm_device *dev = &mdev->base;
> > + unsigned char __iomem *pins;
>
> huh, never realized you could write directly to unsigned char __iomem
> pointers!
You cannot :-)
It works for some architectures but not for all.
On sparc64, for instance, this will fail.
The right thing is to use the accessors in io.h
sparse will help you finding such illegal uses of __iomem *.
The good thing is that the pointers are annotated __iomem here.
Thomas:
Please run sparse and fix the warnings using the right accessors
for this patch.
Sam
>
> > + unsigned int pins_len, version;
> > + int offset;
> > + int tmp;
> > +
> > + if (size < MGA_BIOS_OFFSET + 1)
> > + return;
> > +
> > + if (bios[45] != 'M' || bios[46] != 'A' || bios[47] != 'T' ||
> > + bios[48] != 'R' || bios[49] != 'O' || bios[50] != 'X')
> > + return;
> > +
> > + offset = (bios[MGA_BIOS_OFFSET + 1] << 8) | bios[MGA_BIOS_OFFSET];
> > +
> > + if (offset + 5 > size)
> > + return;
> > +
> > + pins = bios + offset;
> > + if (pins[0] == 0x2e && pins[1] == 0x41) {
> > + version = pins[5];
> > + pins_len = pins[2];
> > + } else {
> > + version = 1;
> > + pins_len = pins[0] + (pins[1] << 8);
> > + }
>
Re: [PATCH 3/3] drm/vram-helper: Set object function iff they are not provided by driver
Hi Sam
Am 16.07.20 um 22:11 schrieb Sam Ravnborg:
> On Tue, Jul 14, 2020 at 10:32:38AM +0200, Thomas Zimmermann wrote:
>> Don't override the GEM object functions unconditionally. If the driver
>> sets the GEM functions, VRAM helpers will now them. The idea has been
> s/now/own
Ooops, I forgot a word. This should have been 'will now use them'.
>> taken from SHMEM helpers. If drivers need special versions of some of
>> the GEM functions, they can now override them.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/drm_gem_vram_helper.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>> b/drivers/gpu/drm/drm_gem_vram_helper.c
>> index af767d3da5da..7194144610cb 100644
>> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
>> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>> @@ -190,6 +190,7 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
>> drm_device *dev,
>> unsigned long pg_align)
>
> The documentation of drm_gem_vram_create() could really use some love
> here. It should document the behavior around gem_create_object(), and
> the default allocation of drm_gem_vram_object with no drm_gem_object
> assigned etc.
Sure
Best regards
Thomas
>
> Sam
>
>
>> {
>> struct drm_gem_vram_object *gbo;
>> +struct drm_gem_object *gem;
>> struct drm_vram_mm *vmm = dev->vram_mm;
>> struct ttm_bo_device *bdev;
>> int ret;
>> @@ -199,8 +200,7 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
>> drm_device *dev,
>> return ERR_PTR(-EINVAL);
>>
>> if (dev->driver->gem_create_object) {
>> -struct drm_gem_object *gem =
>> -dev->driver->gem_create_object(dev, size);
>> +gem = dev->driver->gem_create_object(dev, size);
>> if (!gem)
>> return ERR_PTR(-ENOMEM);
>> gbo = drm_gem_vram_of_gem(gem);
>> @@ -208,11 +208,13 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
>> drm_device *dev,
>> gbo = kzalloc(sizeof(*gbo), GFP_KERNEL);
>> if (!gbo)
>> return ERR_PTR(-ENOMEM);
>> +gem = &gbo->bo.base;
>> }
>>
>> -gbo->bo.base.funcs = &drm_gem_vram_object_funcs;
>> +if (!gem->funcs)
>> +gem->funcs = &drm_gem_vram_object_funcs;
>>
>> -ret = drm_gem_object_init(dev, &gbo->bo.base, size);
>> +ret = drm_gem_object_init(dev, gem, size);
>> if (ret) {
>> kfree(gbo);
>> return ERR_PTR(ret);
>> --
>> 2.27.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/komeda: Convert to DEFINE_SHOW_ATTRIBUTE
On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qinglang Miao wrote:
> From: Liu Shixin
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Liu Shixin
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 0246b2e94..4a10e6b9e 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -41,18 +41,7 @@ static int komeda_register_show(struct seq_file *sf, void
> *x)
> return 0;
> }
>
> -static int komeda_register_open(struct inode *inode, struct file *filp)
> -{
> - return single_open(filp, komeda_register_show, inode->i_private);
> -}
> -
> -static const struct file_operations komeda_register_fops = {
> - .owner = THIS_MODULE,
> - .open = komeda_register_open,
> - .read_iter = seq_read_iter,
> - .llseek = seq_lseek,
> - .release= single_release,
> -};
> +DEFINE_SHOW_ATTRIBUTE(komeda_register);
>
Hi Shixin & Qinglang
Thanks for your patch.
Reviewed-by: James Qian Wang
Since your patch is not for drm-misc-next, so seems better
to leave it to you to merge it. :)
Thanks
James
> #ifdef CONFIG_DEBUG_FS
> static void komeda_debugfs_init(struct komeda_dev *mdev)
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
