[RFC PATCH v3 2/2] drm/tegra: plane: Implement generic colorkey property for older Tegra's
For the starter a minimal color keying support is implemented, which is
enough to provide userspace like Opentegra Xorg driver with ability to
support color keying by the XVideo extension.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c| 25 +
drivers/gpu/drm/tegra/dc.h| 7 +++
drivers/gpu/drm/tegra/plane.c | 102 ++
3 files changed, 134 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index c3afe7b2237e..685a0fedb01d 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -162,6 +162,7 @@ static void tegra_plane_setup_blending_legacy(struct
tegra_plane *plane)
u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
BLEND_COLOR_KEY_NONE;
u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
+ enum drm_plane_colorkey_mode mode;
struct tegra_plane_state *state;
u32 blending[2];
unsigned int i;
@@ -171,7 +172,15 @@ static void tegra_plane_setup_blending_legacy(struct
tegra_plane *plane)
tegra_plane_writel(plane, foreground, DC_WIN_BLEND_1WIN);
state = to_tegra_plane_state(plane->base.state);
+ mode = plane->base.state->colorkey.mode;
+ /* setup color keying */
+ if (mode == DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP) {
+ /* color key matched areas are transparent */
+ foreground = background[0] | BLEND_COLOR_KEY_0;
+ }
+
+ /* setup alpha blending */
if (state->opaque) {
/*
* Since custom fix-weight blending isn't utilized and weight
@@ -792,6 +801,11 @@ static struct drm_plane *tegra_primary_plane_create(struct
drm_device *drm,
dev_err(dc->dev, "failed to create rotation property: %d\n",
err);
+ if (dc->soc->has_legacy_blending)
+ drm_plane_create_colorkey_properties(&plane->base,
+ BIT(DRM_PLANE_COLORKEY_MODE_DISABLED) |
+ BIT(DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP));
+
return &plane->base;
}
@@ -1077,6 +1091,11 @@ static struct drm_plane
*tegra_dc_overlay_plane_create(struct drm_device *drm,
dev_err(dc->dev, "failed to create rotation property: %d\n",
err);
+ if (dc->soc->has_legacy_blending)
+ drm_plane_create_colorkey_properties(&plane->base,
+ BIT(DRM_PLANE_COLORKEY_MODE_DISABLED) |
+ BIT(DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP));
+
return &plane->base;
}
@@ -1187,6 +1206,7 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
copy->pclk = state->pclk;
copy->div = state->div;
copy->planes = state->planes;
+ copy->ckey = state->ckey;
return ©->base;
}
@@ -1917,6 +1937,11 @@ static void tegra_crtc_atomic_flush(struct drm_crtc
*crtc,
struct tegra_dc *dc = to_tegra_dc(crtc);
u32 value;
+ if (dc->soc->has_legacy_blending) {
+ tegra_dc_writel(dc, state->ckey.min, DC_DISP_COLOR_KEY0_LOWER);
+ tegra_dc_writel(dc, state->ckey.max, DC_DISP_COLOR_KEY0_UPPER);
+ }
+
value = state->planes << 8 | GENERAL_UPDATE;
tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
value = tegra_dc_readl(dc, DC_CMD_STATE_CONTROL);
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index e96f582ca692..14ed31f0ff37 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -18,6 +18,11 @@
struct tegra_output;
+struct tegra_dc_color_key_state {
+ u32 min;
+ u32 max;
+};
+
struct tegra_dc_state {
struct drm_crtc_state base;
@@ -26,6 +31,8 @@ struct tegra_dc_state {
unsigned int div;
u32 planes;
+
+ struct tegra_dc_color_key_state ckey;
};
static inline struct tegra_dc_state *to_dc_state(struct drm_crtc_state *state)
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index d068e8aa3553..b8f05fd6ffcc 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -465,6 +465,104 @@ static int tegra_plane_setup_transparency(struct
tegra_plane *tegra,
return 0;
}
+static u32 tegra_plane_convert_colorkey_format(u64 value)
+{
+ /* convert ARGB16161616 to ARGB */
+ u16 a = (value >> 48) & 0x;
+ u16 r = (value >> 32) & 0x;
+ u16 g = (value >> 16) & 0x;
+ u16 b = (value >> 0) & 0x;
+
+ a = min_t(u16, 0xff, a / 256);
+ r = min_t(u16, 0xff, r / 256);
+ g = min_t(u16, 0xff, g / 256);
+ b = min_t(u16, 0xff, b / 256);
+
+ return (a << 24) | (r << 16) | (g << 8) | b;
+}
+
+static bool tegra_plane_format_invalid_for_colorkey(
+ struct drm_plane_state *state)
+{
+ /*
+* Olde
Re: [PATCH v2] gpu: drm: armada: Adding new typedef vm_fault_t
On Wed, May 23, 2018 at 3:09 PM, Souptick Joarder wrote:
> On Wed, May 16, 2018 at 10:05 AM, Souptick Joarder
> wrote:
>> On Fri, May 11, 2018 at 2:52 PM, Russell King - ARM Linux
>> wrote:
>>> On Thu, May 10, 2018 at 08:34:48PM +0530, Souptick Joarder wrote:
Use new return type vm_fault_t for fault handler in
struct vm_operations_struct. For now, this is just
documenting that the function returns a VM_FAULT
value rather than an errno. Once all instances are
converted, vm_fault_t will become a distinct type.
commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_pfn() returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_pfn() will replace this inefficiency by
returning VM_FAULT_* type.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
>>>
>>> Acked-by: Russell King
>>>
>>> Thanks.
>>
>> If no further comment, we would like to get this patch in queue
>> for 4.18.
>
> We would like to get this patch in queue
> for 4.18.
We would like to get this patch in 4.18.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] gpu: drm: gma500: Change return type to vm_fault_t
On Sun, May 27, 2018 at 6:15 AM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Previously vm_insert_{pfn,mixed} returns err which driver
> mapped into VM_FAULT_* type. The new function
> vmf_insert_{pfn,mixed} will replace this inefficiency by
> returning VM_FAULT_* type.
>
> vmf_error() is the newly introduce inline function
> in 4.17-rc6.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
> ---
> v2: updated the change log
>
> v3: Fixed kbuild error
>
> drivers/gpu/drm/gma500/framebuffer.c | 14 +-
> drivers/gpu/drm/gma500/gem.c | 27 ++-
> drivers/gpu/drm/gma500/psb_drv.h | 3 ++-
> 3 files changed, 17 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> b/drivers/gpu/drm/gma500/framebuffer.c
> index cb0a2ae..632aadb 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -111,7 +111,7 @@ static int psbfb_pan(struct fb_var_screeninfo *var,
> struct fb_info *info)
> return 0;
> }
>
> -static int psbfb_vm_fault(struct vm_fault *vmf)
> +static vm_fault_t psbfb_vm_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct psb_framebuffer *psbfb = vma->vm_private_data;
> @@ -120,7 +120,7 @@ static int psbfb_vm_fault(struct vm_fault *vmf)
> int page_num;
> int i;
> unsigned long address;
> - int ret;
> + vm_fault_t ret = VM_FAULT_SIGBUS;
> unsigned long pfn;
> unsigned long phys_addr = (unsigned long)dev_priv->stolen_base +
> psbfb->gtt->offset;
> @@ -133,18 +133,14 @@ static int psbfb_vm_fault(struct vm_fault *vmf)
> for (i = 0; i < page_num; i++) {
> pfn = (phys_addr >> PAGE_SHIFT);
>
> - ret = vm_insert_mixed(vma, address,
> + ret = vmf_insert_mixed(vma, address,
> __pfn_to_pfn_t(pfn, PFN_DEV));
> - if (unlikely((ret == -EBUSY) || (ret != 0 && i > 0)))
> + if (unlikely(ret & VM_FAULT_ERROR))
> break;
> - else if (unlikely(ret != 0)) {
> - ret = (ret == -ENOMEM) ? VM_FAULT_OOM :
> VM_FAULT_SIGBUS;
> - return ret;
> - }
> address += PAGE_SIZE;
> phys_addr += PAGE_SIZE;
> }
> - return VM_FAULT_NOPAGE;
> + return ret;
> }
>
> static void psbfb_vm_open(struct vm_area_struct *vma)
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index 1312397..e7be5c9 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -134,12 +134,13 @@ int psb_gem_dumb_create(struct drm_file *file, struct
> drm_device *dev,
> * vma->vm_private_data points to the GEM object that is backing this
> * mapping.
> */
> -int psb_gem_fault(struct vm_fault *vmf)
> +vm_fault_t psb_gem_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct drm_gem_object *obj;
> struct gtt_range *r;
> - int ret;
> + int err;
> + vm_fault_t ret;
> unsigned long pfn;
> pgoff_t page_offset;
> struct drm_device *dev;
> @@ -158,9 +159,10 @@ int psb_gem_fault(struct vm_fault *vmf)
> /* For now the mmap pins the object and it stays pinned. As things
>stand that will do us no harm */
> if (r->mmapping == 0) {
> - ret = psb_gtt_pin(r);
> - if (ret < 0) {
> - dev_err(dev->dev, "gma500: pin failed: %d\n", ret);
> + err = psb_gtt_pin(r);
> + if (err < 0) {
> + dev_err(dev->dev, "gma500: pin failed: %d\n", err);
> + ret = vmf_error(err);
> goto fail;
> }
> r->mmapping = 1;
> @@ -175,18 +177,9 @@ int psb_gem_fault(struct vm_fault *vmf)
> pfn = (dev_priv->stolen_base + r->offset) >> PAGE_SHIFT;
> else
> pfn = page_to_pfn(r->pages[page_offset]);
> - ret = vm_insert_pfn(vma, vmf->address, pfn);
> -
> + ret = vmf_insert_pfn(vma, vmf->address, pfn);
> fail:
> mutex_unlock(&dev_priv->mmap_mutex);
> - switch (ret) {
> - case 0:
> - case -ERESTARTSYS:
> - case -EINTR:
> - return VM_FAULT_NOPAGE;
> - case -ENOMEM:
> - return VM_FAULT_OOM;
> - default:
> - return VM_FAULT_SIGBUS;
> - }
> +
> + return ret;
> }
> diff --git a/drivers/gpu/drm/gma500/psb_drv.h
>
[RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
From: Laurent Pinchart
Color keying is the action of replacing pixels matching a given color
(or range of colors) with transparent pixels in an overlay when
performing blitting. Depending on the hardware capabilities, the
matching pixel can either become fully transparent or gain adjustment
of the pixels component values.
Color keying is found in a large number of devices whose capabilities
often differ, but they still have enough common features in range to
standardize color key properties. This commit adds three generic DRM plane
properties related to the color keying, providing initial color keying
support.
Signed-off-by: Laurent Pinchart
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_atomic.c | 12 +
drivers/gpu/drm/drm_blend.c | 99
include/drm/drm_blend.h | 3 ++
include/drm/drm_plane.h | 53 +++
4 files changed, 167 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 895741e9cd7d..b322cbed319b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -799,6 +799,12 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+ } else if (property == plane->colorkey.mode_property) {
+ state->colorkey.mode = val;
+ } else if (property == plane->colorkey.min_property) {
+ state->colorkey.min = val;
+ } else if (property == plane->colorkey.max_property) {
+ state->colorkey.max = val;
} else if (property == plane->color_encoding_property) {
state->color_encoding = val;
} else if (property == plane->color_range_property) {
@@ -864,6 +870,12 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+ } else if (property == plane->colorkey.mode_property) {
+ *val = state->colorkey.mode;
+ } else if (property == plane->colorkey.min_property) {
+ *val = state->colorkey.min;
+ } else if (property == plane->colorkey.max_property) {
+ *val = state->colorkey.max;
} else if (property == plane->color_encoding_property) {
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index a16a74d7e15e..12fed2ff65c8 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -107,6 +107,11 @@
* planes. Without this property the primary plane is always below the
cursor
* plane, and ordering between all other planes is undefined.
*
+ * colorkey:
+ * Color keying is set up with drm_plane_create_colorkey_properties().
+ * It adds support for replacing a range of colors with a transparent
+ * color in the plane.
+ *
* Note that all the property extensions described here apply either to the
* plane or the CRTC (e.g. for the background color, which currently is not
* exposed and assumed to be black).
@@ -448,3 +453,97 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
return 0;
}
EXPORT_SYMBOL(drm_atomic_normalize_zpos);
+
+static const char * const plane_colorkey_mode_name[] = {
+ [DRM_PLANE_COLORKEY_MODE_DISABLED] = "disabled",
+ [DRM_PLANE_COLORKEY_MODE_FOREGROUND_CLIP] = "foreground-clip",
+};
+
+/**
+ * drm_plane_create_colorkey_properties - create colorkey properties
+ * @plane: drm plane
+ * @supported_modes: bitmask of supported color keying modes
+ *
+ * This function creates the generic color keying properties and attach them to
+ * the plane to enable color keying control for blending operations.
+ *
+ * Color keying is controlled by these properties:
+ *
+ * colorkey.mode:
+ * The mode is an enumerated property that controls how color keying
+ * operates.
+ *
+ * colorkey.min, colorkey.max:
+ * These two properties specify the colors that are treated as the color
+ * key. Pixel whose value is in the [min, max] range is the color key
+ * matching pixel. The minimum and maximum values are expressed as a
+ * 64-bit integer in ARGB16161616 format, where A is the alpha value and
+ * R, G and B correspond to the color components. Drivers shall convert
+ * ARGB16161616 value into appropriate format within planes atomic check.
+ *
+ * When a single color key is desired instead of a range, userspace shall
+ * set the min and max properties to the same value.
+ *
+ * Drivers return an error from their plane atomic check if range can't be
+ * handled.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_plane_create_colorkey_properties(struct drm_plane *plane,
+
[RFC PATCH v3 0/2] drm: Add generic colorkey plane properties
Hello, In this version I've reduced color keying modes and properties to a bare minimum because considering several modes and properties at once might take quite a lot of effort due to a variety of HW capabilities. This allows us to start easy with the generic colorkey properties support. For the starter let's implement probably the most common (and simple) color keying mode - the "green screen" (or "chroma key") mode. More advanced modes and features could be implemented later on by as needed basis. Following Ville's Syrjälä review comments to v2, the color key value is now given in ARGB16161616 format. Drivers have to convert this 16bpc format into internal color key value representation themselves. This works well for cases where conversion is done to a non-planar integer formats, but I'm not sure how drivers are supposed to cope with cases where conversion involves churning with fixed point math / floating point representation. Comments are welcome. v2: https://lists.freedesktop.org/archives/dri-devel/2018-May/178408.html v1: https://lists.freedesktop.org/archives/dri-devel/2017-December/160510.html Dmitry Osipenko (1): drm/tegra: plane: Implement generic colorkey property for older Tegra's Laurent Pinchart (1): drm: Add generic colorkey properties for DRM planes drivers/gpu/drm/drm_atomic.c | 12 drivers/gpu/drm/drm_blend.c | 99 + drivers/gpu/drm/tegra/dc.c| 25 + drivers/gpu/drm/tegra/dc.h| 7 +++ drivers/gpu/drm/tegra/plane.c | 102 ++ include/drm/drm_blend.h | 3 + include/drm/drm_plane.h | 53 ++ 7 files changed, 301 insertions(+) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv9 0/3] Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port. Basically the driver just wraps the information such as the pixels to be drawn by the FPGA FrameBuffer 2. The piece of hardware in discussion is the SoC FPGA where Linux runs on the ARM chip and the FGPA is driven by its NIOS soft core with its own proprietary firmware. For example the application from the ARM Linux would have to write information on the /dev/fb0 with the information stored in the SDRAM to be fetched by the FPGA framebuffer IP and displayed on the Display Port Monitor. Ong Hean Loong (2): ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite ARM:drm ivip Intel FPGA Video and Image Processing Suite Ong, Hean Loong (1): ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite .../devicetree/bindings/display/altr,vip-fb2.txt | 99 ++ arch/arm/configs/socfpga_defconfig |5 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivip/Kconfig | 14 ++ drivers/gpu/drm/ivip/Makefile |9 + drivers/gpu/drm/ivip/intel_vip_conn.c | 95 ++ drivers/gpu/drm/ivip/intel_vip_core.c | 161 drivers/gpu/drm/ivip/intel_vip_drv.h | 52 ++ drivers/gpu/drm/ivip/intel_vip_of.c| 193 10 files changed, 631 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt create mode 100644 drivers/gpu/drm/ivip/Kconfig create mode 100644 drivers/gpu/drm/ivip/Makefile create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv9 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong
Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is located at:
Documentation/devicetree/bindings/display/altr,vip-fb2.txt
Signed-off-by: Ong Hean Loong
---
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/ivip/Kconfig | 14 +++
drivers/gpu/drm/ivip/Makefile |9 ++
drivers/gpu/drm/ivip/intel_vip_conn.c | 95
drivers/gpu/drm/ivip/intel_vip_core.c | 161 +++
drivers/gpu/drm/ivip/intel_vip_drv.h | 52 +
drivers/gpu/drm/ivip/intel_vip_of.c | 193 +
8 files changed, 527 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index deeefa7..cdc8e1a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -204,6 +204,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
source "drivers/gpu/drm/i915/Kconfig"
+source "drivers/gpu/drm/ivip/Kconfig"
+
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff..c0fba1d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
obj-$(CONFIG_DRM_MGA) += mga/
obj-$(CONFIG_DRM_I810) += i810/
obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
obj-$(CONFIG_DRM_MGAG200) += mgag200/
obj-$(CONFIG_DRM_VC4) += vc4/
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..1d08b90
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,14 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM && OF
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+ Choose this option if you have an Intel FPGA Arria 10 system
+ and above with an Intel Display Port IP. This does not support
+ legacy Intel FPGA Cyclone V display port. Currently only
single
+ frame buffer is supported. Note that ACPI and X_86
architecture
+ is not supported for Arria10. If M is selected the module
will be
+ called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..cc55b04
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver. This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+ intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..46bb04c
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,95 @@
+/*
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
+ .reset = drm_atomic_helper_connector_reset,
+ .detect =
[PATCHv9 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 371fca4..21d8d2b 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -112,6 +112,11 @@ CONFIG_MFD_ALTERA_A10SR=y CONFIG_MFD_STMPE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_DRM=m +CONFIG_DRM_IVIP=m +CONFIG_DRM_IVIP_OF=m +CONFIG_FB=y +CONFIG_FB_SIMPLE=y CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv9 1/3] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong
Device tree binding for Intel FPGA Video and Image Processing Suite. The
binding involved would be generated from the Altera (Intel) Qsys system. The
bindings would set the max width, max height, buts per pixel and memory port
width. The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as altr.
V8:
*Add port to Display port decoder
V7:
*Fix OF graph for better description
*Add description for encoder
V6:
*Description have not describe DT device in general
V5:
*remove bindings for bits per symbol as it has only one value which is 8
V4:
*fix properties that does not describe the values
V3:
*OF graph not in accordance to graph.txt
V2:
*Remove Linux driver description
V1:
*Missing vendor prefix
Signed-off-by: Ong, Hean Loong
---
.../devicetree/bindings/display/altr,vip-fb2.txt | 99
1 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
new file mode 100644
index 000..4092804
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,99 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Intel FPGA SoC Arria10 and above with display port IP
+
+The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core
+that interfaces between system memory and Avalon-ST video ports. The IP core
+can be configured to support the memory reader (from memory to Avalon-ST)
+and/or memory writer (from Avalon-ST to memory) interfaces.
+
+More information the FPGA video IP component can be acquired from
+https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
+/literature/ug/ug_vip.pdf
+
+DT-Bindings:
+=
+Required properties:
+
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- altr,max-width: The maximum width of the framebuffer in pixels.
+- altr,max-height: The maximum height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port
+ on the frame reader
+
+Optional sub-nodes:
+- ports: The connection to the encoder
+
+Optional properties
+
+- compatible: "altr, display-port"
+- reg: Physical base address and length of the display port controller's
+ registers
+- clocks: required clock handles for specified pairs in clock name
+- clock-names: required clock names. Contains:
+ - aux_clk: auxiliary clock,
+ - clk: 100 MHz output clock
+ - xcvr_mgmt_clk: transceiver management clock
+
+Optional sub-nodes:
+- ports: The connection to the controller
+
+Connections between the Frame Buffer II and other video IP cores in the system
+are modelled using the OF graph DT bindings. The Frame Buffer II node has up
+to two OF graph ports. When the memory writer interface is enabled, port 0
+maps to the Avalon-ST Input (din) port. When the memory reader interface is
+enabled, port 1 maps to the Avalon-ST Output (dout) port.
+
+The encoder is built into the FPGA HW design and therefore would not
+be accessible from the DDR.
+
+ Port 0 Port1
+-
+ARRIA10 AVALON_ST (DIN)AVALON_ST (DOUT)
+
+Required Properties Example:
+
+
+framebuffer@10280 {
+ compatible = "altr,vip-frame-buffer-2.0";
+ reg = <0x0001 0x0280 0x0040>;
+ altr,max-width = <1280>;
+ altr,max-height = <720>;
+ altr,mem-port-width = <128>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ fb_output: endpoint {
+ remote-endpoint =
<&dp_encoder_input>;
+ };
+ };
+ };
+};
+
+Optional Properties Example:
+This is not required unless there are needs to customize
+Display Port controller settings.
+
+displayport@12000 {
+ compatible = "altr, display-port";
+ reg = <0x0001 0x2000 0x0800>;
+ clocks = <&dp_0_clk_16 &dp_0_clk_100 &dp_0_clk_100>;
+ clock-names = "aux_clk", "clk", "xcvr_mgmt_clk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <1>;
+ dp_input: endpoint {
+
[Bug 199917] Stack dump with amdgpu.dc=1 the instant FreeSync is enabled in the connected display.
https://bugzilla.kernel.org/show_bug.cgi?id=199917 --- Comment #1 from Nicholas Johnson (nicholas.john...@outlook.com.au) --- On the first stack dump, it says not tainted, and then on the following ones, it says tainted. Can having a stack dump taint the kernel? Either way, I had not modified the kernel or loaded any out of tree modules, and it was not tainted until the error occurred. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays
On 6/3/18 5:00 PM, Noralf Trønnes wrote: Den 25.05.2018 21.36, skrev David Lechner: This series adds a new tinydrm driver for the Ilitek ILI9341 controller and a 2.4" display panel that uses this controller. David, do you have commit rights now? No. Opened a bug a while back to request access, but I guess the right person didn't see it. https://bugs.freedesktop.org/show_bug.cgi?id=105166 Noralf. A few things to note here: * The datasheet for this display[1] doesn't have a vendor mentioned on it anywhere, so I have used "adafruit" as the vendor prefix. If someone has a better suggestion, please speak up. * The MAINTAINERS patch for ili9225 is included so we don't end up with a merge conflict later on. v2 changes: * change vendor prefix from "noname" to "adafruit" * new patch for "adafruit" vendor prefix * minor style changes * drop regulator from driver (instead of adding to DT bindings) [1]: https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf David Lechner (4): MAINTAINERS: fix path to ilitek,ili9225 device tree bindings dt-bindings: Add vendor prefix for Adafruit dt-bindings: new binding for Ilitek ILI9341 display panels drm/tinydrm: new driver for ILI9341 display panels .../bindings/display/ilitek,ili9341.txt | 27 ++ .../devicetree/bindings/vendor-prefixes.txt | 1 + MAINTAINERS | 8 +- drivers/gpu/drm/tinydrm/Kconfig | 10 + drivers/gpu/drm/tinydrm/Makefile | 1 + drivers/gpu/drm/tinydrm/ili9341.c | 233 ++ 6 files changed, 279 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199917] New: Stack dump with amdgpu.dc=1 the instant FreeSync is enabled in the connected display.
https://bugzilla.kernel.org/show_bug.cgi?id=199917 Bug ID: 199917 Summary: Stack dump with amdgpu.dc=1 the instant FreeSync is enabled in the connected display. Product: Drivers Version: 2.5 Kernel Version: 4.17.0-041700-generic 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: nicholas.john...@outlook.com.au Regression: No Created attachment 276315 --> https://bugzilla.kernel.org/attachment.cgi?id=276315&action=edit dmesg output and the error starts on the line with "Jun 4 13:26" in it My hardware: Dell XPS 9370 (i7-8650U, 16GB RAM) - although should be reproducible on any system with two Thunderbolt 3 ports. Gigabyte Aorus Thunderbolt Gaming Box external graphics with AMD Radeon R9 Nano installed - should be reproducible with any R9 Fury (Fiji) series. VBIOS is UEFI GOP, laptop BIOS up to date Monitor is Samsung U32E850R with FreeSync support - although any FreeSync monitor should be sufficient. 4.17 kernel enables amdgpu.dc=1 by default, but on previous kernels, you have to pass it explicitly. There is a separate bug with getting the GPU posted when on Thunderbolt - ATOM BIOS loop. However, trying again with the other Thunderbolt port on the computer than the one with which you first attempted, works. Once approved, I can mess around with Xorg conf (seriously, why does Xorg have to be so difficult?) and get the lightdm / Cinnamon running on the external GPU with Intel graphics ignored. This is with FreeSync disabled in the monitor settings. No issues, no errors in dmesg. However, when I enable FreeSync in the monitor menu, when the video signal returns, dmesg has spewed a barrage of errors, as attached in the file (starting from the line containing "Jun 4 13:26" - search without quotes. That line was when I first enabled FreeSync. Passing amdgpu.dc=0 eliminates this particular problem. There are a lot more problems for AMD to fix, though. It is unknown of yet if this error is specific to Thunderbolt only, or if it also happens with the same Radeon GPU installed inside of a desktop. Either way, the AMDGPU DC is not ready for prime time, and should not have been enabled by default until tested properly. -- 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
[PATCH v3] staging: vboxvideo: Update driver to use drm_dev_register.
The use of load and unload hooks is deprecated. DRM drivers should
use drm_dev_alloc|drm_dev_init and drm_dev_register for initialization
and publishing.
Signed-off-by: Fabio Rafael da Rosa
Reviewed-by: Nicholas Mc Guire
---
Changes in v2:
- Replace drm_dev_unref (also depretated) by drm_dev_put
Changes in v3:
- Add vbox_driver_unload to pci_remove hook so it can free
all driver resources
drivers/staging/vboxvideo/TODO| 1 -
drivers/staging/vboxvideo/vbox_drv.c | 34 +++
drivers/staging/vboxvideo/vbox_drv.h | 2 +-
drivers/staging/vboxvideo/vbox_main.c | 2 +-
4 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/vboxvideo/TODO b/drivers/staging/vboxvideo/TODO
index bd381d861ab3..468eea856ca6 100644
--- a/drivers/staging/vboxvideo/TODO
+++ b/drivers/staging/vboxvideo/TODO
@@ -1,6 +1,5 @@
TODO:
-Move the driver over to the atomic API
--Stop using old load / unload drm_driver hooks
-Get a full review from the drm-maintainers on dri-devel done on this driver
-Extend this TODO with the results of that review
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vboxvideo/vbox_drv.c
index e18642e5027e..d34f22e07772 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -51,14 +51,42 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
- return drm_get_pci_dev(pdev, ent, &driver);
+ struct drm_device *dev = NULL;
+ int ret = 0;
+
+ dev = drm_dev_alloc(&driver, &pdev->dev);
+ if (IS_ERR(dev)) {
+ ret = PTR_ERR(dev);
+ goto err_drv_alloc;
+ }
+ dev->pdev = pdev;
+ pci_set_drvdata(pdev, dev);
+
+ ret = vbox_driver_load(dev);
+ if (ret)
+ goto err_vbox_driver_load;
+
+ ret = drm_dev_register(dev, 0);
+ if (ret)
+ goto err_drv_dev_register;
+
+ return ret;
+
+ err_drv_dev_register:
+ vbox_driver_unload(dev);
+ err_vbox_driver_load:
+ drm_dev_put(dev);
+ err_drv_alloc:
+ return ret;
}
static void vbox_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_dev_unregister(dev);
+ vbox_driver_unload(dev);
+ drm_dev_put(dev);
}
static int vbox_drm_freeze(struct drm_device *dev)
@@ -227,8 +255,6 @@ static struct drm_driver driver = {
DRIVER_PRIME,
.dev_priv_size = 0,
- .load = vbox_driver_load,
- .unload = vbox_driver_unload,
.lastclose = vbox_driver_lastclose,
.master_set = vbox_master_set,
.master_drop = vbox_master_drop,
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index eeac4f0cb2c6..594f84272957 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -126,7 +126,7 @@ struct vbox_private {
#undef CURSOR_PIXEL_COUNT
#undef CURSOR_DATA_SIZE
-int vbox_driver_load(struct drm_device *dev, unsigned long flags);
+int vbox_driver_load(struct drm_device *dev);
void vbox_driver_unload(struct drm_device *dev);
void vbox_driver_lastclose(struct drm_device *dev);
diff --git a/drivers/staging/vboxvideo/vbox_main.c
b/drivers/staging/vboxvideo/vbox_main.c
index 9d2018cd544e..429f6a453619 100644
--- a/drivers/staging/vboxvideo/vbox_main.c
+++ b/drivers/staging/vboxvideo/vbox_main.c
@@ -350,7 +350,7 @@ static void vbox_hw_fini(struct vbox_private *vbox)
pci_iounmap(vbox->dev->pdev, vbox->guest_heap);
}
-int vbox_driver_load(struct drm_device *dev, unsigned long flags)
+int vbox_driver_load(struct drm_device *dev)
{
struct vbox_private *vbox;
int ret = 0;
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm tree with Linus' tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
between commit:
a9e8d27574f2 ("drm/amd/display: Make atomic-check validate underscan changes")
from Linus' tree and commit:
dm_update_crtcs_state ("drm/amd/display: Couple formatting fixes")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 27579443cdc5,1ce10bc2d37b..
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@@ -4577,14 -4650,11 +4650,14 @@@ static int dm_update_crtcs_state(struc
/* TODO This hack should go away */
if (aconnector && enable) {
// Make sure fake sink is created in plug-in scenario
- new_con_state = drm_atomic_get_connector_state(state,
+ drm_new_conn_state =
drm_atomic_get_new_connector_state(state,
-
&aconnector->base);
+
&aconnector->base);
+ drm_old_conn_state =
drm_atomic_get_old_connector_state(state,
+
&aconnector->base);
+
- if (IS_ERR(new_con_state)) {
- ret = PTR_ERR_OR_ZERO(new_con_state);
+ if (IS_ERR(drm_new_conn_state)) {
+ ret = PTR_ERR_OR_ZERO(drm_new_conn_state);
break;
}
pgp8AWiePUo4E.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #16 from ejr.ph...@gmail.com --- I have this issue too, disabling page flipping fixes it for me on my vega10. It started with 4.16rc1 IIRC -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/21] USB DisplayLink patches
On 4 June 2018 at 00:40, Mikulas Patocka wrote: > Hi > > Here I'm sending bug fixes and performance improvements for the USB > DisplayLink framebuffer and modesetting drivers for this merge window. > Hi, You probably want to split these up into separate series for the kms and fbdev drivers. Otherwise at least for drm you've missed this merge window, since it closes around rc6 of the previous kernel, did you use git send-email for these patches, at least some of them viewed funny on my phone, I'll try and look over the kms ones soon. Do you have any numbers for improvements to the kms ones? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays
Den 25.05.2018 21.36, skrev David Lechner: This series adds a new tinydrm driver for the Ilitek ILI9341 controller and a 2.4" display panel that uses this controller. David, do you have commit rights now? Noralf. A few things to note here: * The datasheet for this display[1] doesn't have a vendor mentioned on it anywhere, so I have used "adafruit" as the vendor prefix. If someone has a better suggestion, please speak up. * The MAINTAINERS patch for ili9225 is included so we don't end up with a merge conflict later on. v2 changes: * change vendor prefix from "noname" to "adafruit" * new patch for "adafruit" vendor prefix * minor style changes * drop regulator from driver (instead of adding to DT bindings) [1]: https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf David Lechner (4): MAINTAINERS: fix path to ilitek,ili9225 device tree bindings dt-bindings: Add vendor prefix for Adafruit dt-bindings: new binding for Ilitek ILI9341 display panels drm/tinydrm: new driver for ILI9341 display panels .../bindings/display/ilitek,ili9341.txt | 27 ++ .../devicetree/bindings/vendor-prefixes.txt | 1 + MAINTAINERS | 8 +- drivers/gpu/drm/tinydrm/Kconfig | 10 + drivers/gpu/drm/tinydrm/Makefile | 1 + drivers/gpu/drm/tinydrm/ili9341.c | 233 ++ 6 files changed, 279 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #4 from dwagner --- I was asked in https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1027705-amdgpu-on-linux-4-18-to-offer-greater-vega-power-savings-displayport-1-4-fixes?p=1027933#post1027933 to mention here that I have experienced this kind of bug only when using the "new" display code (amdgpu.dc=1). I cannot strictly rule out that it could also happen with dc=0, since I have tried dc=0 only for short periods occasionally, but during those periods I did not see this kind of crash. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #3 from dwagner --- Just for the record, others have reported similar symptoms - here is a recent example: https://bugs.freedesktop.org/show_bug.cgi?id=10 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #11 from dwagner --- The symptoms you describe sound very much the same as the ones I experience - I reported them in https://bugs.freedesktop.org/show_bug.cgi?id=102322 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon
https://bugs.freedesktop.org/show_bug.cgi?id=106533 michael.panzl...@fau.de changed: What|Removed |Added CC||michael.panzl...@fau.de --- Comment #3 from michael.panzl...@fau.de --- Created attachment 139995 --> https://bugs.freedesktop.org/attachment.cgi?id=139995&action=edit registers, stack and jit function disassembly (In reply to Roland Scheidegger from comment #2) > I suppose it crashes in the jit-compiled code (debug symbols should help > with identifying that, but not help any further if that's the case). > Can you print out the faulting instruction (gdb x/i address or so)? > Also, if that would be some SSE instruction, try to see if the memory > operand is aligned (or just not addressable). I've tried to get the game "Thimbleweed Park" to run and it seems like it's crashing for a very similar reason. This is the stack trace: #0 0x77fdc000 in ?? () #1 0x727288d8 in llvm_pipeline_generic (middle=middle@entry=0x2bc9110, fetch_info=fetch_info@entry=0x7fffdf80, in_prim_info=in_prim_info@entry=0x7fffdfa0) at draw/draw_pt_fetch_shade_pipeline_llvm.c:408 #2 0x72728f86 in llvm_middle_end_linear_run (middle=0x2bc9110, start=0, count=, prim_flags=0) at draw/draw_pt_fetch_shade_pipeline_llvm.c:588 #3 0x72635d56 in vsplit_segment_simple_linear (vsplit=0x2bc6340, vsplit=0x2bc6340, icount=4, istart=0, flags=0) at draw/draw_pt_vsplit_tmp.h:226 #4 vsplit_run_linear (frontend=0x2bc6340, start=0, count=4) at draw/draw_split_tmp.h:70 #5 0x7262d71a in draw_pt_arrays (draw=draw@entry=0x2ba3b20, prim=6, start=0, count=count@entry=4) at draw/draw_pt.c:175 #6 0x7262df50 in draw_vbo (draw=0x2ba3b20, info=0x7fffe0d0, info@entry=0x7fffe1a0) at draw/draw_pt.c:609 #7 0x7273b319 in r300_swtcl_draw_vbo (pipe=0x2b7ac80, info=0x7fffe1a0) at r300_render.c:862 #8 0x7273d9e6 in r300_stencilref_draw_vbo (pipe=0x2b7ac80, info=0x7fffe1a0) at r300_render_stencilref.c:113 #9 0x7261cce7 in cso_draw_arrays (cso=, mode=mode@entry=6, start=start@entry=0, count=count@entry=4) at cso_cache/cso_context.c:1724 #10 0x72413ee4 in st_draw_quad (st=st@entry=0x2cbddb0, x0=x0@entry=-1, y0=y0@entry=-0.89976, x1=x1@entry=1, y1=y1@entry=0.89976, z=1, s0=s0@entry=0, t0=t0@entry=0, s1=s1@entry=0, t1=0, color=color@entry=0x2c9a44c, num_instances=num_instances@entry=1) at state_tracker/st_draw.c:435 #11 0x723f8df1 in clear_with_quad (clear_buffers=, ctx=0x2c987c0) at state_tracker/st_cb_clear.c:300 #12 st_Clear (ctx=0x2c987c0, mask=2) at state_tracker/st_cb_clear.c:454 #13 0x72244dc5 in clear (no_error=false, mask=, ctx=0x2c987c0) at main/clear.c:221 #14 _mesa_Clear (mask=) at main/clear.c:244 #15 0x0049e364 in ?? () #16 0x00481fd3 in ?? () #17 0x0048359f in ?? () #18 0x76c9aa87 in __libc_start_main (main=0x40e130, argc=1, argv=0x7fffe5f8, init=, fini=, rtld_fini=, stack_end=0x7fffe5e8) at ../csu/libc-start.c:310 #19 0x0040f04a in ?? () To answer your original question I've provided information (stack, registers, assembly of jit function) in the attached text file. PS: Hope I did everything correct. First time for me posting something on the bugzilla. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 18/21] udlfb: allow reallocating the framebuffer
Hi Mikulas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.17-rc7 next-20180601]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Mikulas-Patocka/USB-DisplayLink-patches/20180603-233013
base: git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
vim +1198 drivers/video/fbdev/udlfb.c
1171
1172 /*
1173 * Assumes &info->lock held by caller
1174 * Assumes no active clients have framebuffer open
1175 */
1176 static int dlfb_realloc_framebuffer(struct dlfb_data *dlfb, struct
fb_info *info, u32 new_len)
1177 {
1178 u32 old_len = info->fix.smem_len;
> 1179 unsigned char *old_fb = info->screen_base;
1180 unsigned char *new_fb;
1181 unsigned char *new_back = NULL;
1182
1183 new_len = PAGE_ALIGN(new_len);
1184
1185 if (new_len > old_len) {
1186 /*
1187 * Alloc system memory for virtual framebuffer
1188 */
1189 new_fb = vmalloc(new_len);
1190 if (!new_fb) {
1191 dev_err(info->dev, "Virtual framebuffer alloc
failed\n");
1192 return -ENOMEM;
1193 }
1194 memset(new_fb, 0xff, new_len);
1195
1196 if (info->screen_base) {
1197 memcpy(new_fb, old_fb, old_len);
> 1198 dlfb_deferred_vfree(dlfb, info->screen_base);
1199 }
1200
1201 info->screen_base = new_fb;
1202 info->fix.smem_len = new_len;
1203 info->fix.smem_start = (unsigned long) new_fb;
1204 info->flags = udlfb_info_flags;
1205
1206 /*
1207 * Second framebuffer copy to mirror the framebuffer
state
1208 * on the physical USB device. We can function without
this.
1209 * But with imperfect damage info we may send pixels
over USB
1210 * that were, in fact, unchanged - wasting limited USB
bandwidth
1211 */
1212 if (shadow)
1213 new_back = vzalloc(new_len);
1214 if (!new_back)
1215 dev_info(info->dev,
1216 "No shadow/backing buffer
allocated\n");
1217 else {
1218 dlfb_deferred_vfree(dlfb, dlfb->backing_buffer);
1219 dlfb->backing_buffer = new_back;
1220 }
1221 }
1222 return 0;
1223 }
1224
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/scheduler: Avoid using wait_event_killable for dying process.
Am 01.06.2018 um 21:56 schrieb Andrey Grodzovsky:
On 06/01/2018 01:22 PM, Christian König wrote:
Am 01.06.2018 um 19:11 schrieb Andrey Grodzovsky:
Dying process might be blocked from receiving any more signals
so avoid using it.
Also retire enity->fini_status and just check the SW queue,
if it's not empty do the fallback cleanup.
Also handle entity->last_scheduled == NULL use case which
happens when HW ring is already hangged whem a new entity
tried to enqeue jobs.
v2:
Return the remaining timeout and use that as parameter for the next
call.
This way when we need to cleanup multiple queues we don't wait for the
entire TO period for each queue but rather in total.
Styling comments.
Rebase.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 74
---
include/drm/gpu_scheduler.h | 7 +--
2 files changed, 61 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 8c1e80c..c594d17 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -181,7 +181,6 @@ int drm_sched_entity_init(struct
drm_gpu_scheduler *sched,
entity->rq = rq;
entity->sched = sched;
entity->guilty = guilty;
- entity->fini_status = 0;
entity->last_scheduled = NULL;
spin_lock_init(&entity->rq_lock);
@@ -219,7 +218,8 @@ static bool
drm_sched_entity_is_initialized(struct drm_gpu_scheduler *sched,
static bool drm_sched_entity_is_idle(struct drm_sched_entity *entity)
{
rmb();
- if (spsc_queue_peek(&entity->job_queue) == NULL)
+
+ if (!entity->rq || spsc_queue_peek(&entity->job_queue) == NULL)
return true;
return false;
@@ -260,25 +260,48 @@ static void
drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
*
* @sched: scheduler instance
* @entity: scheduler entity
+ * @timeout: time to wait in ms for Q to become empty.
*
* Splitting drm_sched_entity_fini() into two functions, The first
one does the waiting,
* removes the entity from the runqueue and returns an error when
the process was killed.
+ *
+ * Returns amount of time spent in waiting for TO.
+ * 0 if wait wasn't with time out.
+ * MAX_WAIT_SCHED_ENTITY_Q_EMPTY_MS if wait timed out with
condition false
+ * Number of MS spent in waiting before condition became true
+ *
*/
-void drm_sched_entity_do_release(struct drm_gpu_scheduler *sched,
- struct drm_sched_entity *entity)
+unsigned drm_sched_entity_do_release(struct drm_gpu_scheduler *sched,
+ struct drm_sched_entity *entity, unsigned timeout)
Better use long for return type and timeout.
{
+ unsigned ret = 0;
Also use a long here and initialize it with timeout.
Please see bellow
+
if (!drm_sched_entity_is_initialized(sched, entity))
return;
/**
* The client will not queue more IBs during this fini,
consume existing
* queued IBs or discard them on SIGKILL
*/
- if ((current->flags & PF_SIGNALED) && current->exit_code ==
SIGKILL)
- entity->fini_status = -ERESTARTSYS;
- else
- entity->fini_status =
wait_event_killable(sched->job_scheduled,
- drm_sched_entity_is_idle(entity));
- drm_sched_entity_set_rq(entity, NULL);
+ if (current->flags & PF_EXITING) {
+ if (timeout) {
+ ret = jiffies_to_msecs(
+ wait_event_timeout(
+ sched->job_scheduled,
+ drm_sched_entity_is_idle(entity),
+ msecs_to_jiffies(timeout)));
Oh please don't use msecs as timeout, just use jiffies and let the
caller do the conversion.
+
+ if (!ret)
+ ret = MAX_WAIT_SCHED_ENTITY_Q_EMPTY_MS;
Why that? It is common coding style to return 0 when a timeout occurs.
Christian.
What should i return when i do wait_event_killable, it's return values
are opposite to wait_event_timeout...
Just the unmodified timeout. The timeout should begin only after the
process is killed.
This way returning 0 has no impact on remaining waiting time, dong it
the other way will force the caller
to do some cumbersome logic instead of just
max_wait = max_wait >= ret ? max_wait - ret : 0;
like in amdgpu_ctx_mgr_entity_fini
Hui? Why do you want to fiddle with the max_wait here all together?
The usual pattern of using timeouts with multiple wait_event_timeout
calls is the following:
timeout = MAX_TIMEOUT;
while (more_events_to_handle) {
timeout = wait_event_timeout(... timeout);
if (timeout == 0)
break;
}
if (timeout == 0)
we_timeout_out_waiting_for_all_events();
Christian.
Andrey
+ }
+ } else
+ wait_event_killable(sched->job_scheduled,
drm_sched_entity_is_idle(entity));
+
+
+ /* For killed process disable any more IBs enqueue right now */
+ if ((cu
[Bug 100616] With Radeon HD 8550M system freezes when running 3D application
https://bugs.freedesktop.org/show_bug.cgi?id=100616 Arham Amouei changed: What|Removed |Added Priority|medium |high --- Comment #2 from Arham Amouei --- I recently installed ubuntu 18.04. I also added the PPA ppa:oibaf/graphics-drivers to have the latest version of the driver. Now, when I try DRI_PRIME=1 glxgears it usually works fine, but sometimes the system freezes when I maximize the window. The other software I mentioned, i.e. "Visual Molecular Dynamics", crashes much more frequently, maybe because its 3D job is heavier. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On 29.05.2018 10:17, Ville Syrjälä wrote:
> On Sat, May 26, 2018 at 06:56:22PM +0300, Dmitry Osipenko wrote:
>> Color keying is the action of replacing pixels matching a given color
>> (or range of colors) with transparent pixels in an overlay when
>> performing blitting. Depending on the hardware capabilities, the
>> matching pixel can either become fully transparent or gain adjustment
>> of the pixels component values.
>>
>> Color keying is found in a large number of devices whose capabilities
>> often differ, but they still have enough common features in range to
>> standardize color key properties. This commit adds nine generic DRM plane
>> properties related to the color keying to cover various HW capabilities.
>>
>> This patch is based on the initial work done by Laurent Pinchart, most of
>> credits for this patch goes to him.
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/gpu/drm/drm_atomic.c | 36 ++
>> drivers/gpu/drm/drm_blend.c | 229 +++
>> include/drm/drm_blend.h | 3 +
>> include/drm/drm_plane.h | 77
>> 4 files changed, 345 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 895741e9cd7d..5b808cb68654 100644
>> @@ -124,6 +175,19 @@ struct drm_plane_state {
>> unsigned int zpos;
>> unsigned int normalized_zpos;
>>
>> +/* Plane colorkey */
>> +struct {
>> +enum drm_plane_colorkey_mode mode;
>> +u64 min;
>> +u64 max;
>> +u64 mask;
>> +u32 format;
>> +bool inverted_match;
>> +u64 replacement_mask;
>> +u64 replacement_value;
>> +u32 replacement_format;
>> +} colorkey;
>
> After a quick stab at implementing this for i915 I came to the
> conclusion that I'd like this struct to have a name so that I can pass
> it around/consult it easily without having to mess about with the entire
> plane state.
>
> One extra question that came up is how are we going to define the
> destination color key? Is it to be a) enabled on the plane that has the
> colorkey painted on it, or is it to be b) enabled on a plane that sits
> above the plane that is going to be covering up the colorkey? Modern
> Intel hardware defines it the a) way, whereas older hw used the b)
> method. Thinking about it I do think the a) method seems nicer because
> it removes the ambiguity as to which plane's pixels are going to be
> compared again the colorkey. So kinda matches the src colorkey case
> better.
>
> Oh and this also brings up the question as to which other plane(s) are
> taking part in the colorkey process. Looks like on modern Intel hw it's
> supposed to be just the plane immediately above the plane with
> dst keying enabled. On some really old hw there were some more
> complicated rules as to which pair of planes are involved. On middle
> aged hw the situation is simpler a there are only ever two
> (non-cursor) planes on the same crtc. The cursor doesn't seem to
> participate in the colorkeing ever. Not sure there's a sane way to
> fully abstract this all.
>
> I should probably poke at the hardware a bit more to figure out how
> this really works when there are more than two active planes on the
> crtc. I did poke at one particular class of hw which is
> a bit of a mix of old and middle aged hw, and there it seems I can
> also do dst colorkeying the a) way. And in this case there are three
> planes taking part in the dst colorkey match (the primary that
> has the colorkey painted on it, and two overlay planes that cover
> up the matched pixels). So for that case definitely the a) approach
> in the uapi would make more sense as trying to specify conflicting
> dst colorkey settings for each of the overlay planes wouldn't make
> any sense. I'll need to poke at the modern hw a bit more still...
>
Color keying mode must explicitly define the expected behavior. It is up to a
driver to enable HW color keying for an appropriate plane, or whatever needs to
be done to provide the behavior.
After some more considering, I've reduced the color keying properties and modes
to a bare-and-practical minimum, also taking into account your comments. I'll
send out a new version of the patch later today, let's continue discussion
there.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: ttm: Adding new return type vm_fault_t
On Fri, Jun 1, 2018 at 5:18 PM, Christian König
wrote:
> Am 31.05.2018 um 07:07 schrieb Souptick Joarder:
>>
>> On Thu, May 24, 2018 at 12:25 AM, Souptick Joarder
>> wrote:
>>>
>>> Use new return type vm_fault_t for fault handler. For
>>> now, this is just documenting that the function returns
>>> a VM_FAULT value rather than an errno. Once all instances
>>> are converted, vm_fault_t will become a distinct type.
>>>
>>> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>>>
>>> Previously vm_insert_{mixed,pfn} returns err which driver
>>> mapped into VM_FAULT_* type. The new function
>>> vmf_insert_{mixed,pfn} will replace this inefficiency by
>>> returning VM_FAULT_* type.
>>>
>>> Signed-off-by: Souptick Joarder
>>> ---
>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 45
>>> -
>>> 1 file changed, 22 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> index 8eba95b..2d13f03 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> @@ -43,10 +43,11 @@
>>>
>>> #define TTM_BO_VM_NUM_PREFAULT 16
>>>
>>> -static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
>>> +static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
>>> struct vm_fault *vmf)
>>> {
>>> - int ret = 0;
>>> + int err = 0;
>>> + vm_fault_t ret = 0;
>
>
> Please keep reverse xmas tree order for variable declarations.
>
> Except for that it looks good to me,
> Christian.
>
Sure, I will send v2. We would like to get this patch in
queue for 4.18.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: vboxvideo: Update driver to use drm_dev_register.
On Sat, Jun 02, 2018 at 08:41:44AM -0300, Fabio Rafael da Rosa wrote:
> The use of load and unload hooks is deprecated. DRM drivers should
> use drm_dev_alloc|drm_dev_init and drm_dev_register for initialization
> and publishing.
>
> Signed-off-by: Fabio Rafael da Rosa
Reviewed-by: Nicholas Mc Guire
> ---
> drivers/staging/vboxvideo/TODO| 1 -
> drivers/staging/vboxvideo/vbox_drv.c | 33 +++
> drivers/staging/vboxvideo/vbox_drv.h | 2 +-
> drivers/staging/vboxvideo/vbox_main.c | 2 +-
> 4 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/vboxvideo/TODO b/drivers/staging/vboxvideo/TODO
> index bd381d861ab3..468eea856ca6 100644
> --- a/drivers/staging/vboxvideo/TODO
> +++ b/drivers/staging/vboxvideo/TODO
> @@ -1,6 +1,5 @@
> TODO:
> -Move the driver over to the atomic API
> --Stop using old load / unload drm_driver hooks
> -Get a full review from the drm-maintainers on dri-devel done on this driver
> -Extend this TODO with the results of that review
>
> diff --git a/drivers/staging/vboxvideo/vbox_drv.c
> b/drivers/staging/vboxvideo/vbox_drv.c
> index e18642e5027e..a580d184c613 100644
> --- a/drivers/staging/vboxvideo/vbox_drv.c
> +++ b/drivers/staging/vboxvideo/vbox_drv.c
> @@ -51,14 +51,41 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
>
> static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> *ent)
> {
> - return drm_get_pci_dev(pdev, ent, &driver);
> + struct drm_device *dev = NULL;
> + int ret = 0;
> +
> + dev = drm_dev_alloc(&driver, &pdev->dev);
> + if (IS_ERR(dev)) {
> + ret = PTR_ERR(dev);
> + goto err_drv_alloc;
> + }
> + dev->pdev = pdev;
> + pci_set_drvdata(pdev, dev);
> +
> + ret = vbox_driver_load(dev);
> + if (ret)
> + goto err_vbox_driver_load;
> +
> + ret = drm_dev_register(dev, 0);
> + if (ret)
> + goto err_drv_dev_register;
> +
> + return ret;
> +
> + err_drv_dev_register:
> + vbox_driver_unload(dev);
> + err_vbox_driver_load:
> + drm_dev_unref(dev);
Documentation to drm_dev_unref() notes:
* This is a compatibility alias for drm_dev_put() and should not be used by new
* code.
so probably that should be a drm_dev_put(dev); here (as well as below)
Also does dev not need to be freed in the error paths ? atleast I did not
see how it would be in the current code (kzalloc´ed in drm_dev_alloc())
thx!
hofrat
> + err_drv_alloc:
> + return ret;
> }
>
> static void vbox_pci_remove(struct pci_dev *pdev)
> {
> struct drm_device *dev = pci_get_drvdata(pdev);
>
> - drm_put_dev(dev);
> + drm_dev_unregister(dev);
> + drm_dev_unref(dev);
> }
>
> static int vbox_drm_freeze(struct drm_device *dev)
> @@ -227,8 +254,6 @@ static struct drm_driver driver = {
> DRIVER_PRIME,
> .dev_priv_size = 0,
>
> - .load = vbox_driver_load,
> - .unload = vbox_driver_unload,
> .lastclose = vbox_driver_lastclose,
> .master_set = vbox_master_set,
> .master_drop = vbox_master_drop,
> diff --git a/drivers/staging/vboxvideo/vbox_drv.h
> b/drivers/staging/vboxvideo/vbox_drv.h
> index eeac4f0cb2c6..594f84272957 100644
> --- a/drivers/staging/vboxvideo/vbox_drv.h
> +++ b/drivers/staging/vboxvideo/vbox_drv.h
> @@ -126,7 +126,7 @@ struct vbox_private {
> #undef CURSOR_PIXEL_COUNT
> #undef CURSOR_DATA_SIZE
>
> -int vbox_driver_load(struct drm_device *dev, unsigned long flags);
> +int vbox_driver_load(struct drm_device *dev);
> void vbox_driver_unload(struct drm_device *dev);
> void vbox_driver_lastclose(struct drm_device *dev);
>
> diff --git a/drivers/staging/vboxvideo/vbox_main.c
> b/drivers/staging/vboxvideo/vbox_main.c
> index 9d2018cd544e..429f6a453619 100644
> --- a/drivers/staging/vboxvideo/vbox_main.c
> +++ b/drivers/staging/vboxvideo/vbox_main.c
> @@ -350,7 +350,7 @@ static void vbox_hw_fini(struct vbox_private *vbox)
> pci_iounmap(vbox->dev->pdev, vbox->guest_heap);
> }
>
> -int vbox_driver_load(struct drm_device *dev, unsigned long flags)
> +int vbox_driver_load(struct drm_device *dev)
> {
> struct vbox_private *vbox;
> int ret = 0;
> --
> 2.17.0
>
>
> ___
> Kernelnewbies mailing list
> kernelnewb...@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] gpu: drm: ttm: Adding new return type vm_fault_t
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_{mixed,pfn} returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_{mixed,pfn} will replace this inefficiency by
returning VM_FAULT_* type.
Signed-off-by: Souptick Joarder
---
v2: Address christian's comment. Put reverse
xmas tree order for variable declarations.
drivers/gpu/drm/ttm/ttm_bo_vm.c | 45 -
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 8eba95b..9de8b4f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -43,10 +43,11 @@
#define TTM_BO_VM_NUM_PREFAULT 16
-static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
+static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
struct vm_fault *vmf)
{
- int ret = 0;
+ vm_fault_t ret = 0;
+ int err = 0;
if (likely(!bo->moving))
goto out_unlock;
@@ -77,9 +78,9 @@ static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
/*
* Ordinary wait.
*/
- ret = dma_fence_wait(bo->moving, true);
- if (unlikely(ret != 0)) {
- ret = (ret != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
+ err = dma_fence_wait(bo->moving, true);
+ if (unlikely(err != 0)) {
+ ret = (err != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
VM_FAULT_NOPAGE;
goto out_unlock;
}
@@ -104,7 +105,7 @@ static unsigned long ttm_bo_io_mem_pfn(struct
ttm_buffer_object *bo,
+ page_offset;
}
-static int ttm_bo_vm_fault(struct vm_fault *vmf)
+static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
@@ -115,8 +116,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
unsigned long pfn;
struct ttm_tt *ttm = NULL;
struct page *page;
- int ret;
+ int err;
int i;
+ vm_fault_t ret = VM_FAULT_NOPAGE;
unsigned long address = vmf->address;
struct ttm_mem_type_manager *man =
&bdev->man[bo->mem.mem_type];
@@ -128,9 +130,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
* for reserve, and if it fails, retry the fault after waiting
* for the buffer to become unreserved.
*/
- ret = ttm_bo_reserve(bo, true, true, NULL);
- if (unlikely(ret != 0)) {
- if (ret != -EBUSY)
+ err = ttm_bo_reserve(bo, true, true, NULL);
+ if (unlikely(err != 0)) {
+ if (err != -EBUSY)
return VM_FAULT_NOPAGE;
if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
@@ -162,8 +164,8 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
}
if (bdev->driver->fault_reserve_notify) {
- ret = bdev->driver->fault_reserve_notify(bo);
- switch (ret) {
+ err = bdev->driver->fault_reserve_notify(bo);
+ switch (err) {
case 0:
break;
case -EBUSY:
@@ -191,13 +193,13 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
goto out_unlock;
}
- ret = ttm_mem_io_lock(man, true);
- if (unlikely(ret != 0)) {
+ err = ttm_mem_io_lock(man, true);
+ if (unlikely(err != 0)) {
ret = VM_FAULT_NOPAGE;
goto out_unlock;
}
- ret = ttm_mem_io_reserve_vm(bo);
- if (unlikely(ret != 0)) {
+ err = ttm_mem_io_reserve_vm(bo);
+ if (unlikely(err != 0)) {
ret = VM_FAULT_SIGBUS;
goto out_io_unlock;
}
@@ -265,23 +267,20 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
}
if (vma->vm_flags & VM_MIXEDMAP)
- ret = vm_insert_mixed(&cvma, address,
+ ret = vmf_insert_mixed(&cvma, address,
__pfn_to_pfn_t(pfn, PFN_DEV));
else
- ret = vm_insert_pfn(&cvma, address, pfn);
+ ret = vmf_insert_pfn(&cvma, address, pfn);
/*
* Somebody beat us to this PTE or prefaulting to
* an already populated PTE, or prefaulting error.
*/
- if (unlikely((ret == -EBUSY) || (ret != 0 && i > 0)))
+ if (unlikely((ret == VM_FAULT_NOPAGE && i > 0)))
break;
- else if (unlikely(ret != 0)) {
- ret
[PATCH] fb: fix lost console when the user unplugs a USB adapter
I have a USB display adapter using the udlfb driver and I use it on an ARM
board that doesn't have any graphics card. When I plug the adapter in, the
console is properly displayed, however when I unplug and re-plug the
adapter, the console is not displayed and I can't access it until I reboot
the board.
The reason is this:
When the adapter is unplugged, dlfb_usb_disconnect calls
unlink_framebuffer, then it waits until the reference count drops to zero
and then it deallocates the framebuffer. However, the console that is
attached to the framebuffer device keeps the reference count non-zero, so
the framebuffer device is never destroyed. When the USB adapter is plugged
again, it creates a new device /dev/fb1 and the console is not attached to
it.
This patch fixes the bug by unbinding the console from unlink_framebuffer.
The code to unbind the console is moved from do_unregister_framebuffer to
a function unbind_console. When the console is unbound, the reference
count drops to zero and the udlfb driver frees the framebuffer. When the
adapter is plugged back, a new framebuffer is created and the console is
attached to it.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/video/fbdev/core/fbmem.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
Index: linux-4.16.12/drivers/video/fbdev/core/fbmem.c
===
--- linux-4.16.12.orig/drivers/video/fbdev/core/fbmem.c 2018-05-26
06:13:20.0 +0200
+++ linux-4.16.12/drivers/video/fbdev/core/fbmem.c 2018-05-26
06:13:20.0 +0200
@@ -1805,12 +1805,12 @@ static int do_register_framebuffer(struc
return 0;
}
-static int do_unregister_framebuffer(struct fb_info *fb_info)
+static int unbind_console(struct fb_info *fb_info)
{
struct fb_event event;
- int i, ret = 0;
+ int ret;
+ int i = fb_info->node;
- i = fb_info->node;
if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info)
return -EINVAL;
@@ -1825,6 +1825,16 @@ static int do_unregister_framebuffer(str
unlock_fb_info(fb_info);
console_unlock();
+ return ret;
+}
+
+static int do_unregister_framebuffer(struct fb_info *fb_info)
+{
+ struct fb_event event;
+ int ret;
+
+ ret = unbind_console(fb_info);
+
if (ret)
return -EINVAL;
@@ -1835,7 +1845,7 @@ static int do_unregister_framebuffer(str
(fb_info->pixmap.flags & FB_PIXMAP_DEFAULT))
kfree(fb_info->pixmap.addr);
fb_destroy_modelist(&fb_info->modelist);
- registered_fb[i] = NULL;
+ registered_fb[fb_info->node] = NULL;
num_registered_fb--;
fb_cleanup_device(fb_info);
event.info = fb_info;
@@ -1860,6 +1870,9 @@ int unlink_framebuffer(struct fb_info *f
device_destroy(fb_class, MKDEV(FB_MAJOR, i));
fb_info->dev = NULL;
}
+
+ unbind_console(fb_info);
+
return 0;
}
EXPORT_SYMBOL(unlink_framebuffer);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106795] Laptop with Intel+Nvidia hybrid graphics won't suspend after hibernation
https://bugs.freedesktop.org/show_bug.cgi?id=106795 Bug ID: 106795 Summary: Laptop with Intel+Nvidia hybrid graphics won't suspend after hibernation Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel@lists.freedesktop.org Reporter: network...@rkmail.ru Created attachment 139988 --> https://bugs.freedesktop.org/attachment.cgi?id=139988&action=edit kernel log with drm.debug=0x0e A laptop with hybrid graphics won't suspend on the second time after it was hibernated and restored. Kernel log shows some nouveau-related error messages. For details see https://bugzilla.suse.com/show_bug.cgi?id=1094780 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/21] udlfb: dont switch if we are switching to the same videomode
The udlfb driver reprograms the hardware everytime the user switches the
console, that makes quite unusable when working on the console.
This patch makes the driver remember the videomode we are in and avoid
reprogramming the hardware if we switch to the same videomode.
We mask the "activate" field and the "FB_VMODE_SMOOTH_XPAN" flag when
comparing the videomode, because they cause spurious switches when
switching to and from the Xserver.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 18 --
include/video/udlfb.h |1 +
2 files changed, 17 insertions(+), 2 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
===
--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31
14:49:52.0 +0200
+++ linux-4.17-rc7/drivers/video/fbdev/udlfb.c 2018-05-31 14:49:52.0
+0200
@@ -1041,10 +1041,24 @@ static int dlfb_ops_set_par(struct fb_in
int result;
u16 *pix_framebuffer;
int i;
+ struct fb_var_screeninfo fvs;
+
+ /* clear the activate field because it causes spurious miscompares */
+ fvs = info->var;
+ fvs.activate = 0;
+ fvs.vmode &= ~FB_VMODE_SMOOTH_XPAN;
+
+ if (!memcmp(&dlfb->current_mode, &fvs, sizeof(struct
fb_var_screeninfo)))
+ return 0;
result = dlfb_set_video_mode(dlfb, &info->var);
- if ((result == 0) && (dlfb->fb_count == 0)) {
+ if (result)
+ return result;
+
+ dlfb->current_mode = fvs;
+
+ if (dlfb->fb_count == 0) {
/* paint greenscreen */
@@ -1056,7 +1070,7 @@ static int dlfb_ops_set_par(struct fb_in
info->screen_base);
}
- return result;
+ return 0;
}
/* To fonzi the jukebox (e.g. make blanking changes take effect) */
Index: linux-4.17-rc7/include/video/udlfb.h
===
--- linux-4.17-rc7.orig/include/video/udlfb.h 2018-05-31 14:49:52.0
+0200
+++ linux-4.17-rc7/include/video/udlfb.h2018-05-31 14:49:52.0
+0200
@@ -56,6 +56,7 @@ struct dlfb_data {
atomic_t bytes_identical; /* saved effort with backbuffer comparison */
atomic_t bytes_sent; /* to usb, after compression including overhead */
atomic_t cpu_kcycles_used; /* transpired during pixel processing */
+ struct fb_var_screeninfo current_mode;
};
#define NR_USB_REQUEST_I2C_SUB_IO 0x02
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/21] udl-kms: dont spam the syslog with debug messages
The udl kms driver writes messages to the syslog whenever some application
opens or closes /dev/fb0 and whenever the user switches between the
Xserver and the console.
This patch changes the priority of these messages to debug.
Signed-off-by: Mikulas Patocka
---
drivers/gpu/drm/udl/udl_fb.c |6 +++---
drivers/gpu/drm/udl/udl_modeset.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-4.17-rc7/drivers/gpu/drm/udl/udl_fb.c
===
--- linux-4.17-rc7.orig/drivers/gpu/drm/udl/udl_fb.c2018-06-03
13:17:58.0 +0200
+++ linux-4.17-rc7/drivers/gpu/drm/udl/udl_fb.c 2018-06-03 13:42:48.0
+0200
@@ -179,7 +179,7 @@ static int udl_fb_mmap(struct fb_info *i
pos = (unsigned long)info->fix.smem_start + offset;
- pr_notice("mmap() framebuffer addr:%lu size:%lu\n",
+ pr_debug("mmap() framebuffer addr:%lu size:%lu\n",
pos, size);
/* We don't want the framebuffer to be mapped encrypted */
@@ -237,7 +237,7 @@ static int udl_fb_open(struct fb_info *i
}
#endif
- pr_notice("open /dev/fb%d user=%d fb_info=%p count=%d\n",
+ pr_debug("open /dev/fb%d user=%d fb_info=%p count=%d\n",
info->node, user, info, ufbdev->fb_count);
return 0;
@@ -262,7 +262,7 @@ static int udl_fb_release(struct fb_info
}
#endif
- pr_warn("released /dev/fb%d user=%d count=%d\n",
+ pr_debug("released /dev/fb%d user=%d count=%d\n",
info->node, user, ufbdev->fb_count);
return 0;
Index: linux-4.17-rc7/drivers/gpu/drm/udl/udl_modeset.c
===
--- linux-4.17-rc7.orig/drivers/gpu/drm/udl/udl_modeset.c 2018-06-03
13:17:58.0 +0200
+++ linux-4.17-rc7/drivers/gpu/drm/udl/udl_modeset.c2018-06-03
13:41:56.0 +0200
@@ -243,7 +243,7 @@ static int udl_crtc_write_mode_to_hw(str
memcpy(buf, udl->mode_buf, udl->mode_buf_len);
retval = udl_submit_urb(dev, urb, udl->mode_buf_len);
- DRM_INFO("write mode info %d\n", udl->mode_buf_len);
+ DRM_DEBUG("write mode info %d\n", udl->mode_buf_len);
return retval;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/21] udlfb: fix display corruption of the last line
The displaylink hardware has such a peculiarity that it doesn't render a
command until next command is received. This produces occasional
corruption, such as when setting 22x11 font on the console, only the first
line of the cursor will be blinking if the cursor is located at some
specific columns.
When we end up with a repeating pixel, the driver has a bug that it leaves
one uninitialized byte after the command (and this byte is enough to flush
the command and render it - thus it fixes the screen corruption), however
whe we end up with a non-repeating pixel, there is no byte appended and
this results in temporary screen corruption.
This patch fixes the screen corruption by always appending a byte 0xAF at
the end of URB. It also removes the uninitialized byte.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
===
--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31
14:43:13.0 +0200
+++ linux-4.17-rc7/drivers/video/fbdev/udlfb.c 2018-05-31 14:46:03.0
+0200
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include "edid.h"
@@ -450,17 +451,17 @@ static void dlfb_compress_hline(
raw_pixels_count_byte = cmd++; /* we'll know this later */
raw_pixel_start = pixel;
- cmd_pixel_end = pixel + min(MAX_CMD_PIXELS + 1,
- min((int)(pixel_end - pixel),
- (int)(cmd_buffer_end - cmd) / BPP));
+ cmd_pixel_end = pixel + min3(MAX_CMD_PIXELS + 1UL,
+ (unsigned long)(pixel_end - pixel),
+ (unsigned long)(cmd_buffer_end - 1 -
cmd) / BPP);
- prefetch_range((void *) pixel, (cmd_pixel_end - pixel) * BPP);
+ prefetch_range((void *) pixel, (u8 *)cmd_pixel_end - (u8
*)pixel);
while (pixel < cmd_pixel_end) {
const uint16_t * const repeating_pixel = pixel;
- *cmd++ = *pixel >> 8;
- *cmd++ = *pixel;
+ put_unaligned_be16(*pixel, cmd);
+ cmd += 2;
pixel++;
if (unlikely((pixel < cmd_pixel_end) &&
@@ -486,13 +487,16 @@ static void dlfb_compress_hline(
if (pixel > raw_pixel_start) {
/* finalize last RAW span */
*raw_pixels_count_byte = (pixel-raw_pixel_start) & 0xFF;
+ } else {
+ /* undo unused byte */
+ cmd--;
}
*cmd_pixels_count_byte = (pixel - cmd_pixel_start) & 0xFF;
- dev_addr += (pixel - cmd_pixel_start) * BPP;
+ dev_addr += (u8 *)pixel - (u8 *)cmd_pixel_start;
}
- if (cmd_buffer_end <= MIN_RLX_CMD_BYTES + cmd) {
+ if (cmd_buffer_end - MIN_RLX_CMD_BYTES <= cmd) {
/* Fill leftover bytes with no-ops */
if (cmd_buffer_end > cmd)
memset(cmd, 0xAF, cmd_buffer_end - cmd);
@@ -610,8 +614,11 @@ static int dlfb_handle_damage(struct dlf
}
if (cmd > (char *) urb->transfer_buffer) {
+ int len;
+ if (cmd < (char *) urb->transfer_buffer +
urb->transfer_buffer_length)
+ *cmd++ = 0xAF;
/* Send partial buffer remaining before exiting */
- int len = cmd - (char *) urb->transfer_buffer;
+ len = cmd - (char *) urb->transfer_buffer;
ret = dlfb_submit_urb(dlfb, urb, len);
bytes_sent += len;
} else
@@ -735,8 +742,11 @@ static void dlfb_dpy_deferred_io(struct
}
if (cmd > (char *) urb->transfer_buffer) {
+ int len;
+ if (cmd < (char *) urb->transfer_buffer +
urb->transfer_buffer_length)
+ *cmd++ = 0xAF;
/* Send partial buffer remaining before exiting */
- int len = cmd - (char *) urb->transfer_buffer;
+ len = cmd - (char *) urb->transfer_buffer;
dlfb_submit_urb(dlfb, urb, len);
bytes_sent += len;
} else
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/21] udlfb: optimization - test the backing buffer
Currently, the udlfb driver only tests for identical bytes at the
beginning or at the end of a page and renders anything between the first
and last mismatching pixel. But pages are not the same as lines, so this
is quite suboptimal - if there is something modified at the beginning of a
page and at the end of a page, the whole page is rendered, even if most of
the page is not modified.
This patch makes it test for identical pixels at the beginning and end of
each rendering command. This patch improves identical byte detection by
41% when playing video in a window.
This patch also fixes a possible screen corruption if the user is writing
to the framebuffer while dlfb_render_hline is in progress - the pixel data
that is copied to the backbuffer with memcpy may be different from the
pixel data that is actually rendered to the hardware (because the content
of the framebuffer may change between memcpy and the rendering command).
We must make sure that we copy exactly the same pixel as the pixel that is
being rendered.
Signed-off-by: Mikulas Patocka
---
drivers/video/fbdev/udlfb.c | 45 +---
1 file changed, 34 insertions(+), 11 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
===
--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31
14:51:43.0 +0200
+++ linux-4.17-rc7/drivers/video/fbdev/udlfb.c 2018-05-31 14:51:43.0
+0200
@@ -431,7 +431,9 @@ static void dlfb_compress_hline(
const uint16_t *const pixel_end,
uint32_t *device_address_ptr,
uint8_t **command_buffer_ptr,
- const uint8_t *const cmd_buffer_end)
+ const uint8_t *const cmd_buffer_end,
+ unsigned long back_buffer_offset,
+ int *ident_ptr)
{
const uint16_t *pixel = *pixel_start_ptr;
uint32_t dev_addr = *device_address_ptr;
@@ -444,6 +446,14 @@ static void dlfb_compress_hline(
const uint16_t *raw_pixel_start = NULL;
const uint16_t *cmd_pixel_start, *cmd_pixel_end = NULL;
+ if (back_buffer_offset &&
+ *pixel == *(u16 *)((u8 *)pixel + back_buffer_offset)) {
+ pixel++;
+ dev_addr += BPP;
+ (*ident_ptr)++;
+ continue;
+ }
+
prefetchw((void *) cmd); /* pull in one cache line at least */
*cmd++ = 0xAF;
@@ -462,25 +472,37 @@ static void dlfb_compress_hline(
(unsigned long)(pixel_end - pixel),
(unsigned long)(cmd_buffer_end - 1 -
cmd) / BPP);
+ if (back_buffer_offset) {
+ /* note: the framebuffer may change under us, so we
must test for underflow */
+ while (cmd_pixel_end - 1 > pixel &&
+ *(cmd_pixel_end - 1) == *(u16 *)((u8
*)(cmd_pixel_end - 1) + back_buffer_offset))
+ cmd_pixel_end--;
+ }
+
prefetch_range((void *) pixel, (u8 *)cmd_pixel_end - (u8
*)pixel);
while (pixel < cmd_pixel_end) {
const uint16_t * const repeating_pixel = pixel;
+ u16 pixel_value = *pixel;
- put_unaligned_be16(*pixel, cmd);
+ put_unaligned_be16(pixel_value, cmd);
+ if (back_buffer_offset)
+ *(u16 *)((u8 *)pixel + back_buffer_offset) =
pixel_value;
cmd += 2;
pixel++;
if (unlikely((pixel < cmd_pixel_end) &&
-(*pixel == *repeating_pixel))) {
+(*pixel == pixel_value))) {
/* go back and fill in raw pixel count */
*raw_pixels_count_byte = ((repeating_pixel -
raw_pixel_start) + 1) & 0xFF;
- while ((pixel < cmd_pixel_end)
- && (*pixel == *repeating_pixel)) {
- pixel++;
- }
+ do {
+ if (back_buffer_offset)
+ *(u16 *)((u8 *)pixel +
back_buffer_offset) = pixel_value;
+ pixel++;
+ } while ((pixel < cmd_pixel_end) &&
+(*pixel == pixel_value));
/* immediately after raw data is repeat byte */
*cmd++ = ((pixel - repeating_pixel) - 1) & 0xFF;
@@ -531,6 +553,7 @@ static int dlfb_render_hline(struct dlfb
struct urb *urb = *
[PATCH 21/21] udlfb: use spin_lock_irq instead of spin_lock_irqsave
spin_lock_irqsave and spin_unlock_irqrestore is inteded to be called from
a context where it is unknown if interrupts are enabled or disabled (such
as interrupt handlers). From a process context, we should call
spin_lock_irq and spin_unlock_irq, that avoids the costly pushf and popf
instructions.
Signed-off-by: Mikulas Patocka
---
drivers/video/fbdev/udlfb.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
===
--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-06-03
13:17:46.0 +0200
+++ linux-4.17-rc7/drivers/video/fbdev/udlfb.c 2018-06-03 13:17:46.0
+0200
@@ -1855,18 +1855,17 @@ static void dlfb_free_urb_list(struct dl
struct list_head *node;
struct urb_node *unode;
struct urb *urb;
- unsigned long flags;
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
down(&dlfb->urbs.limit_sem);
- spin_lock_irqsave(&dlfb->urbs.lock, flags);
+ spin_lock_irq(&dlfb->urbs.lock);
node = dlfb->urbs.list.next; /* have reserved one with sem */
list_del_init(node);
- spin_unlock_irqrestore(&dlfb->urbs.lock, flags);
+ spin_unlock_irq(&dlfb->urbs.lock);
unode = list_entry(node, struct urb_node, entry);
urb = unode->urb;
@@ -1944,7 +1943,6 @@ static struct urb *dlfb_get_urb(struct d
int ret;
struct list_head *entry;
struct urb_node *unode;
- unsigned long flags;
/* Wait for an in-flight buffer to complete and get re-queued */
ret = down_timeout(&dlfb->urbs.limit_sem, GET_URB_TIMEOUT);
@@ -1956,14 +1954,14 @@ static struct urb *dlfb_get_urb(struct d
return NULL;
}
- spin_lock_irqsave(&dlfb->urbs.lock, flags);
+ spin_lock_irq(&dlfb->urbs.lock);
BUG_ON(list_empty(&dlfb->urbs.list)); /* reserved one with limit_sem */
entry = dlfb->urbs.list.next;
list_del_init(entry);
dlfb->urbs.available--;
- spin_unlock_irqrestore(&dlfb->urbs.lock, flags);
+ spin_unlock_irq(&dlfb->urbs.lock);
unode = list_entry(entry, struct urb_node, entry);
return unode->urb;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/21] udlfb: make a local copy of fb_ops
The defio subsystem overwrites the method fb_osp->mmap. That method is
stored in module's static data - and that means that if we have multiple
diplaylink adapters, they will over write each other's method.
In order to avoid interference between multiple adapters, we copy the
fb_ops structure to a device-local memory.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/video/fbdev/udlfb.c |3 ++-
include/video/udlfb.h |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
===
--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-06-03
13:17:33.0 +0200
+++ linux-4.17-rc7/drivers/video/fbdev/udlfb.c 2018-06-03 13:17:33.0
+0200
@@ -1665,7 +1665,8 @@ static void dlfb_init_framebuffer_work(s
dlfb->info = info;
info->par = dlfb;
info->pseudo_palette = dlfb->pseudo_palette;
- info->fbops = &dlfb_ops;
+ dlfb->ops = dlfb_ops;
+ info->fbops = &dlfb->ops;
retval = fb_alloc_cmap(&info->cmap, 256, 0);
if (retval < 0) {
Index: linux-4.17-rc7/include/video/udlfb.h
===
--- linux-4.17-rc7.orig/include/video/udlfb.h 2018-06-03 13:17:33.0
+0200
+++ linux-4.17-rc7/include/video/udlfb.h2018-06-03 13:17:33.0
+0200
@@ -51,6 +51,7 @@ struct dlfb_data {
int base8;
u32 pseudo_palette[256];
int blank_mode; /*one of FB_BLANK_ */
+ struct fb_ops ops;
/* blit-only rendering path metrics, exposed through sysfs */
atomic_t bytes_rendered; /* raw pixel-bytes driver asked to render */
atomic_t bytes_identical; /* saved effort with backbuffer comparison */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/21] udl-kms: fix a linked-list corruption when using fbdefio
The udl driver crashes when fbdefio is used. The crash can be reproduced
with this sequence:
1. echo 1 >/sys/module/udl/parameters/fb_defio
2. run some program that maps the framebuffer, such as 'links -g' or 'fbi'
3. allocate memory to the point where the machine starts swapping
The reason for the crash is that udl_gem_get_pages calls drm_gem_get_pages
and drm_gem_get_pages allocates the pages using shmem_read_mapping_page.
The shmem pages are kept on the memory management lists using the
page->lru entry.
However, fbdefio reuses the page->lru entry for the list of pages that
were modified, so the memory management lists are corrupted and the
machine crashes when vmscan starts to scan memory.
I fixed this crash by allocating pages with "alloc_page" instead. The
pages allocated with "alloc_page" have page->lru unused, and thus the
system doesn't crash when fbdefio uses it.
Unable to handle kernel paging request at virtual address dead0200
Mem abort info:
ESR = 0x9644
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0044
CM = 0, WnR = 1
[dead0200] address between user and kernel address ranges
Internal error: Oops: 9644 [#1] PREEMPT SMP
Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables x_tables
af_packet autofs4 udl drm_kms_helper cfbfillrect syscopyarea cfbimgblt
sysfillrect sysimgblt fb_sys_fops cfbcopyarea fb font drm
drm_panel_orientation_quirks mousedev hid_generic usbhid hid binfmt_misc
snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_pcm snd_timer snd
soundcore ipv6 aes_ce_blk crypto_simd cryptd aes_ce_cipher crc32_ce ghash_ce
gf128mul aes_arm64 sha2_ce sha256_arm64 sha1_ce sha1_generic xhci_plat_hcd
xhci_hcd sd_mod usbcore usb_common mvpp2 unix
CPU: 0 PID: 39 Comm: kswapd0 Not tainted 4.16.12 #3
Hardware name: Marvell 8040 MACHIATOBin (DT)
pstate: 0085 (nzcv daIf -PAN -UAO)
pc : isolate_lru_pages.isra.16+0x23c/0x2b0
lr : isolate_lru_pages.isra.16+0x104/0x2b0
sp : ffc13a897ac0
x29: ffc13a897ac0 x28: 0003
x27: 0003 x26: 0004
x25: ff80087e84a0 x24: ffc13a897b68
x23: ffbf04cefc60 x22: ffc13a897e44
x21: 0009 x20: ffc13a897c00
x19: ffc13a897b40 x18: ffbf04d39000
x17: fff8 x16: ffbf
x15: 0006 x14:
x13: 01aa x12: 4004001c
x11: 0001 x10: 0001
x9 : 000ee3ac x8 : 04a0
x7 : ff80087e84a0 x6 :
x5 : x4 : 0002
x3 : ff80087e84a0 x2 : 0200
x1 : dead0200 x0 : 4004001c
Process kswapd0 (pid: 39, stack limit = 0x97f25571)
Call trace:
isolate_lru_pages.isra.16+0x23c/0x2b0
shrink_inactive_list+0xe4/0x3b0
shrink_node_memcg.constprop.19+0x374/0x630
shrink_node+0x64/0x1c8
kswapd+0x340/0x568
kthread+0x118/0x120
ret_from_fork+0x10/0x18
Code: d2804002 f85e02e0 f85e02ec f9000461 (f923)
---[ end trace f9f3ad3856cb2ef3 ]---
note: kswapd0[39] exited with preempt_count 1
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/udl/udl_gem.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_gem.c
===
--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_gem.c2018-01-10
09:31:23.0 +0100
+++ linux-4.16.12/drivers/gpu/drm/udl/udl_gem.c 2018-05-29 17:46:10.0
+0200
@@ -130,28 +130,51 @@ int udl_gem_fault(struct vm_fault *vmf)
int udl_gem_get_pages(struct udl_gem_object *obj)
{
struct page **pages;
+ int npages, i;
if (obj->pages)
return 0;
- pages = drm_gem_get_pages(&obj->base);
- if (IS_ERR(pages))
- return PTR_ERR(pages);
+ npages = obj->base.size >> PAGE_SHIFT;
+
+ pages = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
+ if (!pages)
+ return -ENOMEM;
+
+ for (i = 0; i < npages; i++) {
+ struct page *p = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!p)
+ goto fail;
+ pages[i] = p;
+ }
obj->pages = pages;
return 0;
+
+fail:
+ while (i--)
+ put_page(pages[i]);
+ kvfree(pages);
+ return -ENOMEM;
}
void udl_gem_put_pages(struct udl_gem_object *obj)
{
+ int npages, i;
+
if (obj->base.import_attach) {
kvfree(obj->pages);
obj->pages = NULL;
return;
}
- drm_gem_put_pages(&obj->base, obj->pages, false, false);
+ npages = obj->base.size >> PAGE_SHIFT;
+
+ for (i = 0; i < npages; i++)
+ put_page(obj->pages[i]);
+
+ kvfree(obj->pages);
obj->pages = NULL;
}
_
[PATCH 16/21] udlfb: handle allocation failure
Allocations larger than PAGE_ALLOC_COSTLY_ORDER are unreliable and they
may fail anytime. This patch fixes the udlfb driver so that when a large
alloactions fails, it tries to do multiple smaller allocations.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
===
--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-06-03
13:17:38.0 +0200
+++ linux-4.17-rc7/drivers/video/fbdev/udlfb.c 2018-06-03 13:17:38.0
+0200
@@ -1843,17 +1843,22 @@ static void dlfb_free_urb_list(struct dl
static int dlfb_alloc_urb_list(struct dlfb_data *dlfb, int count, size_t size)
{
- int i = 0;
struct urb *urb;
struct urb_node *unode;
char *buf;
+ size_t wanted_size = count * size;
spin_lock_init(&dlfb->urbs.lock);
+retry:
dlfb->urbs.size = size;
INIT_LIST_HEAD(&dlfb->urbs.list);
- while (i < count) {
+ sema_init(&dlfb->urbs.limit_sem, 0);
+ dlfb->urbs.count = 0;
+ dlfb->urbs.available = 0;
+
+ while (dlfb->urbs.count * size < wanted_size) {
unode = kzalloc(sizeof(*unode), GFP_KERNEL);
if (!unode)
break;
@@ -1866,11 +1871,16 @@ static int dlfb_alloc_urb_list(struct dl
}
unode->urb = urb;
- buf = usb_alloc_coherent(dlfb->udev, MAX_TRANSFER, GFP_KERNEL,
+ buf = usb_alloc_coherent(dlfb->udev, size, GFP_KERNEL,
&urb->transfer_dma);
if (!buf) {
kfree(unode);
usb_free_urb(urb);
+ if (size > PAGE_SIZE) {
+ size /= 2;
+ dlfb_free_urb_list(dlfb);
+ goto retry;
+ }
break;
}
@@ -1881,14 +1891,12 @@ static int dlfb_alloc_urb_list(struct dl
list_add_tail(&unode->entry, &dlfb->urbs.list);
- i++;
+ up(&dlfb->urbs.limit_sem);
+ dlfb->urbs.count++;
+ dlfb->urbs.available++;
}
- sema_init(&dlfb->urbs.limit_sem, i);
- dlfb->urbs.count = i;
- dlfb->urbs.available = i;
-
- return i;
+ return dlfb->urbs.count;
}
static struct urb *dlfb_get_urb(struct dlfb_data *dlfb)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/21] udlfb: set optimal write delay
The default delay 5 jiffies is too much when the kernel is compiled with
HZ=100 - it results in jumpy cursor in Xwindow.
In order to find out the optimal delay, I benchmarked the driver on
1280x720x30fps video. I found out that with HZ=1000, 10ms is acceptable,
but with HZ=250 or HZ=300, we need 4ms, so that the video is played
without any frame skips.
This patch changes the delay to this value.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
include/video/udlfb.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-4.17-rc7/include/video/udlfb.h
===
--- linux-4.17-rc7.orig/include/video/udlfb.h 2018-06-03 13:17:37.0
+0200
+++ linux-4.17-rc7/include/video/udlfb.h2018-06-03 13:17:37.0
+0200
@@ -88,7 +88,7 @@ struct dlfb_data {
#define MIN_RAW_PIX_BYTES 2
#define MIN_RAW_CMD_BYTES (RAW_HEADER_BYTES + MIN_RAW_PIX_BYTES)
-#define DL_DEFIO_WRITE_DELAY5 /* fb_deferred_io.delay in jiffies */
+#define DL_DEFIO_WRITE_DELAYmsecs_to_jiffies(HZ <= 300 ? 4 : 10) /*
optimal value for 720p video */
#define DL_DEFIO_WRITE_DISABLE (HZ*60) /* "disable" with long delay */
/* remove these once align.h patch is taken into kernel */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/21] USB DisplayLink patches
Hi Here I'm sending bug fixes and performance improvements for the USB DisplayLink framebuffer and modesetting drivers for this merge window. Mikulas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/21] udl-kms: handle allocation failure
Allocations larger than PAGE_ALLOC_COSTLY_ORDER are unreliable and they
may fail anytime. This patch fixes the udl kms driver so that when a large
alloactions fails, it tries to do multiple smaller allocations.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/udl/udl_main.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_main.c
===
--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_main.c 2018-05-31
11:16:15.0 +0200
+++ linux-4.16.12/drivers/gpu/drm/udl/udl_main.c2018-05-31
11:16:15.0 +0200
@@ -200,17 +200,22 @@ static void udl_free_urb_list(struct drm
static int udl_alloc_urb_list(struct drm_device *dev, int count, size_t size)
{
struct udl_device *udl = dev->dev_private;
- int i = 0;
struct urb *urb;
struct urb_node *unode;
char *buf;
+ size_t wanted_size = count * size;
spin_lock_init(&udl->urbs.lock);
+retry:
udl->urbs.size = size;
INIT_LIST_HEAD(&udl->urbs.list);
- while (i < count) {
+ sema_init(&udl->urbs.limit_sem, 0);
+ udl->urbs.count = 0;
+ udl->urbs.available = 0;
+
+ while (udl->urbs.count * size < wanted_size) {
unode = kzalloc(sizeof(struct urb_node), GFP_KERNEL);
if (!unode)
break;
@@ -226,11 +231,16 @@ static int udl_alloc_urb_list(struct drm
}
unode->urb = urb;
- buf = usb_alloc_coherent(udl->udev, MAX_TRANSFER, GFP_KERNEL,
+ buf = usb_alloc_coherent(udl->udev, size, GFP_KERNEL,
&urb->transfer_dma);
if (!buf) {
kfree(unode);
usb_free_urb(urb);
+ if (size > PAGE_SIZE) {
+ size /= 2;
+ udl_free_urb_list(dev);
+ goto retry;
+ }
break;
}
@@ -241,16 +251,14 @@ static int udl_alloc_urb_list(struct drm
list_add_tail(&unode->entry, &udl->urbs.list);
- i++;
+ up(&udl->urbs.limit_sem);
+ udl->urbs.count++;
+ udl->urbs.available++;
}
- sema_init(&udl->urbs.limit_sem, i);
- udl->urbs.count = i;
- udl->urbs.available = i;
-
- DRM_DEBUG("allocated %d %d byte urbs\n", i, (int) size);
+ DRM_DEBUG("allocated %d %d byte urbs\n", udl->urbs.count, (int) size);
- return i;
+ return udl->urbs.count;
}
struct urb *udl_get_urb(struct drm_device *dev)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/21] udl-kms: change down_interruptible to down
If we leave urbs around, it causes not only leak, but also memory
corruption. This patch fixes the function udl_free_urb_list, so that it
always waits for all urbs that are in progress.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/udl/udl_main.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_main.c
===
--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_main.c 2018-05-31
10:23:42.0 +0200
+++ linux-4.16.12/drivers/gpu/drm/udl/udl_main.c2018-05-31
10:28:11.0 +0200
@@ -170,18 +170,13 @@ static void udl_free_urb_list(struct drm
struct list_head *node;
struct urb_node *unode;
struct urb *urb;
- int ret;
unsigned long flags;
DRM_DEBUG("Waiting for completes and freeing all render urbs\n");
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
-
- /* Getting interrupted means a leak, but ok at shutdown*/
- ret = down_interruptible(&udl->urbs.limit_sem);
- if (ret)
- break;
+ down(&udl->urbs.limit_sem);
spin_lock_irqsave(&udl->urbs.lock, flags);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/21] udl-kms: avoid division
Division is slow, so it shouldn't be done by the pixel generating code.
The driver supports only 2 or 4 bytes per pixel, so we can replace
division with a shift.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/udl/udl_drv.h |2 -
drivers/gpu/drm/udl/udl_fb.c | 15 --
drivers/gpu/drm/udl/udl_transfer.c | 39 ++---
3 files changed, 30 insertions(+), 26 deletions(-)
Index: linux-4.17-rc7/drivers/gpu/drm/udl/udl_drv.h
===
--- linux-4.17-rc7.orig/drivers/gpu/drm/udl/udl_drv.h 2018-06-03
13:15:01.0 +0200
+++ linux-4.17-rc7/drivers/gpu/drm/udl/udl_drv.h2018-06-03
13:15:01.0 +0200
@@ -110,7 +110,7 @@ udl_fb_user_fb_create(struct drm_device
struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd);
-int udl_render_hline(struct drm_device *dev, int bpp, struct urb **urb_ptr,
+int udl_render_hline(struct drm_device *dev, int log_bpp, struct urb **urb_ptr,
const char *front, char **urb_buf_ptr,
u32 byte_offset, u32 device_byte_offset, u32 byte_width,
int *ident_ptr, int *sent_ptr);
Index: linux-4.17-rc7/drivers/gpu/drm/udl/udl_fb.c
===
--- linux-4.17-rc7.orig/drivers/gpu/drm/udl/udl_fb.c2018-06-03
13:15:01.0 +0200
+++ linux-4.17-rc7/drivers/gpu/drm/udl/udl_fb.c 2018-06-03 13:15:01.0
+0200
@@ -91,7 +91,10 @@ int udl_handle_damage(struct udl_framebu
int bytes_identical = 0;
struct urb *urb;
int aligned_x;
- int bpp = fb->base.format->cpp[0];
+ int log_bpp;
+
+ BUG_ON(!is_power_of_2(fb->base.format->cpp[0]));
+ log_bpp = __ffs(fb->base.format->cpp[0]);
if (!fb->active_16)
return 0;
@@ -126,12 +129,12 @@ int udl_handle_damage(struct udl_framebu
for (i = y; i < y + height ; i++) {
const int line_offset = fb->base.pitches[0] * i;
- const int byte_offset = line_offset + (x * bpp);
- const int dev_byte_offset = (fb->base.width * bpp * i) + (x *
bpp);
- if (udl_render_hline(dev, bpp, &urb,
+ const int byte_offset = line_offset + (x << log_bpp);
+ const int dev_byte_offset = (fb->base.width * i + x) << log_bpp;
+ if (udl_render_hline(dev, log_bpp, &urb,
(char *) fb->obj->vmapping,
&cmd, byte_offset, dev_byte_offset,
-width * bpp,
+width << log_bpp,
&bytes_identical, &bytes_sent))
goto error;
}
@@ -150,7 +153,7 @@ int udl_handle_damage(struct udl_framebu
error:
atomic_add(bytes_sent, &udl->bytes_sent);
atomic_add(bytes_identical, &udl->bytes_identical);
- atomic_add(width*height*bpp, &udl->bytes_rendered);
+ atomic_add((width * height) << log_bpp, &udl->bytes_rendered);
end_cycles = get_cycles();
atomic_add(((unsigned int) ((end_cycles - start_cycles)
>> 10)), /* Kcycles */
Index: linux-4.17-rc7/drivers/gpu/drm/udl/udl_transfer.c
===
--- linux-4.17-rc7.orig/drivers/gpu/drm/udl/udl_transfer.c 2018-06-03
13:15:01.0 +0200
+++ linux-4.17-rc7/drivers/gpu/drm/udl/udl_transfer.c 2018-06-03
13:15:01.0 +0200
@@ -83,12 +83,12 @@ static inline u16 pixel32_to_be16(const
((pixel >> 8) & 0xf800));
}
-static inline u16 get_pixel_val16(const uint8_t *pixel, int bpp)
+static inline u16 get_pixel_val16(const uint8_t *pixel, int log_bpp)
{
- u16 pixel_val16 = 0;
- if (bpp == 2)
+ u16 pixel_val16;
+ if (log_bpp == 1)
pixel_val16 = *(const uint16_t *)pixel;
- else if (bpp == 4)
+ else
pixel_val16 = pixel32_to_be16(*(const uint32_t *)pixel);
return pixel_val16;
}
@@ -125,8 +125,9 @@ static void udl_compress_hline16(
const u8 *const pixel_end,
uint32_t *device_address_ptr,
uint8_t **command_buffer_ptr,
- const uint8_t *const cmd_buffer_end, int bpp)
+ const uint8_t *const cmd_buffer_end, int log_bpp)
{
+ const int bpp = 1 << log_bpp;
const u8 *pixel = *pixel_start_ptr;
uint32_t dev_addr = *device_address_ptr;
uint8_t *cmd = *command_buffer_ptr;
@@ -153,12 +154,12 @@ static void udl_compress_hline16(
raw_pixels_count_byte = cmd++; /* we'll know this later */
raw_pixel_start = pixel;
- cmd_pixel_end = pixel + min3(MAX_CMD_PIXELS + 1UL,
- (unsigned long)(pixel_end - pixel) /
bpp,
[PATCH 17/21] udlfb: set line_length in dlfb_ops_set_par
Set the variable "line_length" in the function dlfb_ops_set_par. Without
this, we get garbage if we select different videomode with fbset.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/video/fbdev/udlfb.c |1 +
1 file changed, 1 insertion(+)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
===
--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31
14:50:00.0 +0200
+++ linux-4.17-rc7/drivers/video/fbdev/udlfb.c 2018-05-31 14:50:00.0
+0200
@@ -1057,6 +1057,7 @@ static int dlfb_ops_set_par(struct fb_in
return result;
dlfb->current_mode = fvs;
+ info->fix.line_length = info->var.xres * (info->var.bits_per_pixel / 8);
if (dlfb->fb_count == 0) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/21] udl-kms: avoid prefetch
Modern processors can detect linear memory accesses and prefetch data
automatically, so there's no need to use prefetch.
Signed-off-by: Mikulas Patocka
---
drivers/gpu/drm/udl/udl_transfer.c |7 ---
1 file changed, 7 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c
===
--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31
14:48:12.0 +0200
+++ linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c2018-05-31
14:48:12.0 +0200
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
@@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbac
int start = width;
int end = width;
- prefetch((void *) front);
- prefetch((void *) back);
-
for (j = 0; j < width; j++) {
if (back[j] != front[j]) {
start = j;
@@ -140,8 +136,6 @@ static void udl_compress_hline16(
const u8 *cmd_pixel_start, *cmd_pixel_end = NULL;
uint16_t pixel_val16;
- prefetchw((void *) cmd); /* pull in one cache line at least */
-
*cmd++ = 0xaf;
*cmd++ = 0x6b;
*cmd++ = (uint8_t) ((dev_addr >> 16) & 0xFF);
@@ -158,7 +152,6 @@ static void udl_compress_hline16(
(unsigned long)(pixel_end - pixel) >>
log_bpp,
(unsigned long)(cmd_buffer_end - 1 -
cmd) / 2) << log_bpp);
- prefetch_range((void *) pixel, cmd_pixel_end - pixel);
pixel_val16 = get_pixel_val16(pixel, log_bpp);
while (pixel < cmd_pixel_end) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/21] udl-kms: make a local copy of fb_ops
The defio subsystem overwrites the method fb_osp->mmap. That method is
stored in module's static data - and that means that if we have multiple
diplaylink adapters, they will over write each other's method.
In order to avoid interference between multiple adapters, we copy the
fb_ops structure to a device-local memory.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/udl/udl_fb.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-4.17-rc7/drivers/gpu/drm/udl/udl_fb.c
===
--- linux-4.17-rc7.orig/drivers/gpu/drm/udl/udl_fb.c2018-06-03
13:05:20.0 +0200
+++ linux-4.17-rc7/drivers/gpu/drm/udl/udl_fb.c 2018-06-03 13:08:03.0
+0200
@@ -34,6 +34,7 @@ module_param(fb_defio, int, S_IWUSR | S_
struct udl_fbdev {
struct drm_fb_helper helper;
struct udl_framebuffer ufb;
+ struct fb_ops fb_ops;
int fb_count;
};
@@ -405,7 +406,8 @@ static int udlfb_create(struct drm_fb_he
info->fix.smem_len = size;
info->fix.smem_start = (unsigned long)ufbdev->ufb.obj->vmapping;
- info->fbops = &udlfb_ops;
+ ufbdev->fb_ops = udlfb_ops;
+ info->fbops = &ufbdev->fb_ops;
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
drm_fb_helper_fill_var(info, &ufbdev->helper, sizes->fb_width,
sizes->fb_height);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 20/21] udlfb: avoid prefetch
Modern processors can detect linear memory accesses and prefetch data
automatically, so there's no need to use prefetch.
Signed-off-by: Mikulas Patocka
---
drivers/video/fbdev/udlfb.c |8
1 file changed, 8 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
===
--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31
12:48:35.0 +0200
+++ linux-4.17-rc7/drivers/video/fbdev/udlfb.c 2018-05-31 12:48:35.0
+0200
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -375,9 +374,6 @@ static int dlfb_trim_hline(const u8 *bba
int start = width;
int end = width;
- prefetch((void *) front);
- prefetch((void *) back);
-
for (j = 0; j < width; j++) {
if (back[j] != front[j]) {
start = j;
@@ -454,8 +450,6 @@ static void dlfb_compress_hline(
continue;
}
- prefetchw((void *) cmd); /* pull in one cache line at least */
-
*cmd++ = 0xAF;
*cmd++ = 0x6B;
*cmd++ = dev_addr >> 16;
@@ -479,8 +473,6 @@ static void dlfb_compress_hline(
cmd_pixel_end--;
}
- prefetch_range((void *) pixel, (u8 *)cmd_pixel_end - (u8
*)pixel);
-
while (pixel < cmd_pixel_end) {
const uint16_t * const repeating_pixel = pixel;
u16 pixel_value = *pixel;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/21] udl-kms: use spin_lock_irq instead of spin_lock_irqsave
spin_lock_irqsave and spin_unlock_irqrestore is inteded to be called from
a context where it is unknown if interrupts are enabled or disabled (such
as interrupt handlers). From a process context, we should call
spin_lock_irq and spin_unlock_irq, that avoids the costly pushf and popf
instructions.
Signed-off-by: Mikulas Patocka
---
drivers/gpu/drm/udl/udl_main.c| 10 --
drivers/gpu/drm/udl/udl_modeset.c |5 ++---
2 files changed, 6 insertions(+), 9 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_main.c
===
--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_main.c 2018-05-31
11:17:01.0 +0200
+++ linux-4.16.12/drivers/gpu/drm/udl/udl_main.c2018-05-31
11:17:01.0 +0200
@@ -170,7 +170,6 @@ static void udl_free_urb_list(struct drm
struct list_head *node;
struct urb_node *unode;
struct urb *urb;
- unsigned long flags;
DRM_DEBUG("Waiting for completes and freeing all render urbs\n");
@@ -178,12 +177,12 @@ static void udl_free_urb_list(struct drm
while (count--) {
down(&udl->urbs.limit_sem);
- spin_lock_irqsave(&udl->urbs.lock, flags);
+ spin_lock_irq(&udl->urbs.lock);
node = udl->urbs.list.next; /* have reserved one with sem */
list_del_init(node);
- spin_unlock_irqrestore(&udl->urbs.lock, flags);
+ spin_unlock_irq(&udl->urbs.lock);
unode = list_entry(node, struct urb_node, entry);
urb = unode->urb;
@@ -268,7 +267,6 @@ struct urb *udl_get_urb(struct drm_devic
struct list_head *entry;
struct urb_node *unode;
struct urb *urb = NULL;
- unsigned long flags;
/* Wait for an in-flight buffer to complete and get re-queued */
ret = down_timeout(&udl->urbs.limit_sem, GET_URB_TIMEOUT);
@@ -279,14 +277,14 @@ struct urb *udl_get_urb(struct drm_devic
goto error;
}
- spin_lock_irqsave(&udl->urbs.lock, flags);
+ spin_lock_irq(&udl->urbs.lock);
BUG_ON(list_empty(&udl->urbs.list)); /* reserved one with limit_sem */
entry = udl->urbs.list.next;
list_del_init(entry);
udl->urbs.available--;
- spin_unlock_irqrestore(&udl->urbs.lock, flags);
+ spin_unlock_irq(&udl->urbs.lock);
unode = list_entry(entry, struct urb_node, entry);
urb = unode->urb;
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_modeset.c
===
--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_modeset.c2018-05-31
11:17:01.0 +0200
+++ linux-4.16.12/drivers/gpu/drm/udl/udl_modeset.c 2018-05-31
11:17:01.0 +0200
@@ -366,7 +366,6 @@ static int udl_crtc_page_flip(struct drm
{
struct udl_framebuffer *ufb = to_udl_fb(fb);
struct drm_device *dev = crtc->dev;
- unsigned long flags;
struct drm_framebuffer *old_fb = crtc->primary->fb;
if (old_fb) {
@@ -377,10 +376,10 @@ static int udl_crtc_page_flip(struct drm
udl_handle_damage(ufb, 0, 0, fb->width, fb->height);
- spin_lock_irqsave(&dev->event_lock, flags);
+ spin_lock_irq(&dev->event_lock);
if (event)
drm_crtc_send_vblank_event(crtc, event);
- spin_unlock_irqrestore(&dev->event_lock, flags);
+ spin_unlock_irq(&dev->event_lock);
crtc->primary->fb = fb;
return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/21] udlfb: allow reallocating the framebuffer
This patch changes udlfb so that it may reallocate the framebuffer when
setting higher-resolution mode. If we boot the system without monitor
attached, udlfb creates a framebuffer with the size 800x600. This patch
makes it possible to select higher videomode with the fbset command when
a monitor is attached.
Note that there is no reliable way to prevent the system from touching the
old framebuffer, so we must not free it. We add it to the list
dlfb->deferred_free and free it when the driver is unloaded.
Signed-off-by: Mikulas Patocka
---
drivers/video/fbdev/udlfb.c | 70 +---
include/video/udlfb.h |1
2 files changed, 48 insertions(+), 23 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
===
--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-06-03
13:17:41.0 +0200
+++ linux-4.17-rc7/drivers/video/fbdev/udlfb.c 2018-06-03 13:17:41.0
+0200
@@ -73,6 +73,13 @@ static bool fb_defio = 1; /* Detect mma
static bool shadow = 1; /* Optionally disable shadow framebuffer */
static int pixel_limit; /* Optionally force a pixel resolution limit */
+struct dlfb_deferred_free {
+ struct list_head list;
+ void *mem;
+};
+
+static int dlfb_realloc_framebuffer(struct dlfb_data *dlfb, struct fb_info
*info, u32 new_len);
+
/* dlfb keeps a list of urbs for efficient bulk transfers */
static void dlfb_urb_completion(struct urb *urb);
static struct urb *dlfb_get_urb(struct dlfb_data *dlfb);
@@ -927,6 +934,12 @@ static void dlfb_free(struct kref *kref)
{
struct dlfb_data *dlfb = container_of(kref, struct dlfb_data, kref);
+ while (!list_empty(&dlfb->deferred_free)) {
+ struct dlfb_deferred_free *d =
list_entry(dlfb->deferred_free.next, struct dlfb_deferred_free, list);
+ list_del(&d->list);
+ vfree(d->mem);
+ kfree(d);
+ }
vfree(dlfb->backing_buffer);
kfree(dlfb->edid);
kfree(dlfb);
@@ -1020,10 +1033,6 @@ static int dlfb_ops_check_var(struct fb_
struct fb_videomode mode;
struct dlfb_data *dlfb = info->par;
- /* TODO: support dynamically changing framebuffer size */
- if ((var->xres * var->yres * 2) > info->fix.smem_len)
- return -EINVAL;
-
/* set device-specific elements of var unrelated to mode */
dlfb_var_color_format(var);
@@ -1042,6 +1051,7 @@ static int dlfb_ops_set_par(struct fb_in
u16 *pix_framebuffer;
int i;
struct fb_var_screeninfo fvs;
+ u32 line_length = info->var.xres * (info->var.bits_per_pixel / 8);
/* clear the activate field because it causes spurious miscompares */
fvs = info->var;
@@ -1051,13 +1061,17 @@ static int dlfb_ops_set_par(struct fb_in
if (!memcmp(&dlfb->current_mode, &fvs, sizeof(struct
fb_var_screeninfo)))
return 0;
+ result = dlfb_realloc_framebuffer(dlfb, info, info->var.yres *
line_length);
+ if (result)
+ return result;
+
result = dlfb_set_video_mode(dlfb, &info->var);
if (result)
return result;
dlfb->current_mode = fvs;
- info->fix.line_length = info->var.xres * (info->var.bits_per_pixel / 8);
+ info->fix.line_length = line_length;
if (dlfb->fb_count == 0) {
@@ -1066,11 +1080,11 @@ static int dlfb_ops_set_par(struct fb_in
pix_framebuffer = (u16 *) info->screen_base;
for (i = 0; i < info->fix.smem_len / 2; i++)
pix_framebuffer[i] = 0x37e6;
-
- dlfb_handle_damage(dlfb, 0, 0, info->var.xres, info->var.yres,
- info->screen_base);
}
+ dlfb_handle_damage(dlfb, 0, 0, info->var.xres, info->var.yres,
+ info->screen_base);
+
return 0;
}
@@ -1146,21 +1160,29 @@ static struct fb_ops dlfb_ops = {
};
+static void dlfb_deferred_vfree(struct dlfb_data *dlfb, void *mem)
+{
+ struct dlfb_deferred_free *d = kmalloc(sizeof(struct
dlfb_deferred_free), GFP_KERNEL);
+ if (!d)
+ return;
+ d->mem = mem;
+ list_add(&d->list, &dlfb->deferred_free);
+}
+
/*
* Assumes &info->lock held by caller
* Assumes no active clients have framebuffer open
*/
-static int dlfb_realloc_framebuffer(struct dlfb_data *dlfb, struct fb_info
*info)
+static int dlfb_realloc_framebuffer(struct dlfb_data *dlfb, struct fb_info
*info, u32 new_len)
{
- int old_len = info->fix.smem_len;
- int new_len;
+ u32 old_len = info->fix.smem_len;
unsigned char *old_fb = info->screen_base;
unsigned char *new_fb;
unsigned char *new_back = NULL;
- new_len = info->fix.line_length * info->var.yres;
+ new_len = PAGE_ALIGN(new_len);
- if (PAGE_ALIGN(new_len) > old_len) {
+ if (new_len
[PATCH 04/21] udl-kms: fix crash due to uninitialized memory
We must use kzalloc when allocating the fb_deferred_io structure.
Otherwise, the field first_io is undefined and it causes a crash.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/udl/udl_fb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_fb.c
===
--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_fb.c 2018-05-29
17:55:39.0 +0200
+++ linux-4.16.12/drivers/gpu/drm/udl/udl_fb.c 2018-05-29 17:55:39.0
+0200
@@ -221,7 +221,7 @@ static int udl_fb_open(struct fb_info *i
struct fb_deferred_io *fbdefio;
- fbdefio = kmalloc(sizeof(struct fb_deferred_io), GFP_KERNEL);
+ fbdefio = kzalloc(sizeof(struct fb_deferred_io), GFP_KERNEL);
if (fbdefio) {
fbdefio->delay = DL_DEFIO_WRITE_DELAY;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/21] udlfb: fix semaphore value leak
I observed that the performance of the udl fb driver degrades over time.
On a freshly booted machine, it takes 6 seconds to do "ls -la /usr/bin";
after some time of use, the same operation takes 14 seconds.
The reason is that the value of "limit_sem" decays over time.
The udl driver uses a semaphore "limit_set" to specify how many free urbs
are there on dlfb->urbs.list. If the count is zero, the "down" operation
will sleep until some urbs are added to the freelist.
In order to avoid some hypothetical deadlock, the driver will not call
"up" immediatelly, but it will offload it to a workqueue. The problem is
that if we call "schedule_delayed_work" on the same work item multiple
times, the work item may only be executed once.
This is happening:
* some urb completes
* dlfb_urb_completion adds it to the free list
* dlfb_urb_completion calls schedule_delayed_work to schedule the function
dlfb_release_urb_work to increase the semaphore count
* as the urb is on the free list, some other task grabs it and submits it
* the submitted urb completes, dlfb_urb_completion is called again
* dlfb_urb_completion calls schedule_delayed_work, but the work is already
scheduled, so it does nothing
* finally, dlfb_release_urb_work is called, it increases the semaphore
count by 1, although it should increase it by 2
So, the semaphore count is decreasing over time, and this causes gradual
performance degradation.
Note that in the current kernel, the "up" function may be called from
interrupt and it may race with the "down" function called by another
thread, so we don't have to offload the call of "up" to a workqueue at
all. This patch removes the workqueue code. The patch also changes
"down_interruptible" to "down" in dlfb_free_urb_list, so that we will
clean up the driver properly even if a signal arrives.
With this patch, the performance of udlfb no longer degrades.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 27 ++-
include/video/udlfb.h |1 -
2 files changed, 2 insertions(+), 26 deletions(-)
Index: linux-4.17-rc7/drivers/video/fbdev/udlfb.c
===
--- linux-4.17-rc7.orig/drivers/video/fbdev/udlfb.c 2018-05-31
12:31:04.0 +0200
+++ linux-4.17-rc7/drivers/video/fbdev/udlfb.c 2018-05-31 12:31:04.0
+0200
@@ -922,14 +922,6 @@ static void dlfb_free(struct kref *kref)
kfree(dlfb);
}
-static void dlfb_release_urb_work(struct work_struct *work)
-{
- struct urb_node *unode = container_of(work, struct urb_node,
- release_urb_work.work);
-
- up(&unode->dlfb->urbs.limit_sem);
-}
-
static void dlfb_free_framebuffer(struct dlfb_data *dlfb)
{
struct fb_info *info = dlfb->info;
@@ -1789,14 +1781,7 @@ static void dlfb_urb_completion(struct u
dlfb->urbs.available++;
spin_unlock_irqrestore(&dlfb->urbs.lock, flags);
- /*
-* When using fb_defio, we deadlock if up() is called
-* while another is waiting. So queue to another process.
-*/
- if (fb_defio)
- schedule_delayed_work(&unode->release_urb_work, 0);
- else
- up(&dlfb->urbs.limit_sem);
+ up(&dlfb->urbs.limit_sem);
}
static void dlfb_free_urb_list(struct dlfb_data *dlfb)
@@ -1805,16 +1790,11 @@ static void dlfb_free_urb_list(struct dl
struct list_head *node;
struct urb_node *unode;
struct urb *urb;
- int ret;
unsigned long flags;
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
-
- /* Getting interrupted means a leak, but ok at disconnect */
- ret = down_interruptible(&dlfb->urbs.limit_sem);
- if (ret)
- break;
+ down(&dlfb->urbs.limit_sem);
spin_lock_irqsave(&dlfb->urbs.lock, flags);
@@ -1854,9 +1834,6 @@ static int dlfb_alloc_urb_list(struct dl
break;
unode->dlfb = dlfb;
- INIT_DELAYED_WORK(&unode->release_urb_work,
- dlfb_release_urb_work);
-
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb) {
kfree(unode);
Index: linux-4.17-rc7/include/video/udlfb.h
===
--- linux-4.17-rc7.orig/include/video/udlfb.h 2018-05-31 12:31:04.0
+0200
+++ linux-4.17-rc7/include/video/udlfb.h2018-05-31 12:31:04.0
+0200
@@ -20,7 +20,6 @@ struct dloarea {
struct urb_node {
struct list_head entry;
struct dlfb_data *dlfb;
- struct delayed_work release_urb_work;
struct urb *urb;
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/21] udl-kms: fix display corruption of the last line
The displaylink hardware has such a peculiarity that it doesn't render a
command until next command is received. This produces occasional
corruption, such as when setting 22x11 font on the console, only the first
line of the cursor will be blinking if the cursor is located at some
specific columns.
When we end up with a repeating pixel, the driver has a bug that it leaves
one uninitialized byte after the command (and this byte is enough to flush
the command and render it - thus it fixes the screen corruption), however
whe we end up with a non-repeating pixel, there is no byte appended and
this results in temporary screen corruption.
This patch fixes the screen corruption by always appending a byte 0xAF at
the end of URB. It also removes the uninitialized byte.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/udl/udl_fb.c |5 -
drivers/gpu/drm/udl/udl_transfer.c | 11 +++
2 files changed, 11 insertions(+), 5 deletions(-)
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c
===
--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31
14:47:07.0 +0200
+++ linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c2018-05-31
14:53:31.0 +0200
@@ -153,11 +153,11 @@ static void udl_compress_hline16(
raw_pixels_count_byte = cmd++; /* we'll know this later */
raw_pixel_start = pixel;
- cmd_pixel_end = pixel + (min(MAX_CMD_PIXELS + 1,
- min((int)(pixel_end - pixel) / bpp,
- (int)(cmd_buffer_end - cmd) / 2))) * bpp;
+ cmd_pixel_end = pixel + min3(MAX_CMD_PIXELS + 1UL,
+ (unsigned long)(pixel_end - pixel) /
bpp,
+ (unsigned long)(cmd_buffer_end - 1 -
cmd) / 2) * bpp;
- prefetch_range((void *) pixel, (cmd_pixel_end - pixel) * bpp);
+ prefetch_range((void *) pixel, cmd_pixel_end - pixel);
pixel_val16 = get_pixel_val16(pixel, bpp);
while (pixel < cmd_pixel_end) {
@@ -193,6 +193,9 @@ static void udl_compress_hline16(
if (pixel > raw_pixel_start) {
/* finalize last RAW span */
*raw_pixels_count_byte = ((pixel-raw_pixel_start) /
bpp) & 0xFF;
+ } else {
+ /* undo unused byte */
+ cmd--;
}
*cmd_pixels_count_byte = ((pixel - cmd_pixel_start) / bpp) &
0xFF;
Index: linux-4.16.12/drivers/gpu/drm/udl/udl_fb.c
===
--- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_fb.c 2018-05-31
14:47:07.0 +0200
+++ linux-4.16.12/drivers/gpu/drm/udl/udl_fb.c 2018-05-31 14:53:32.0
+0200
@@ -137,7 +137,10 @@ int udl_handle_damage(struct udl_framebu
if (cmd > (char *) urb->transfer_buffer) {
/* Send partial buffer remaining before exiting */
- int len = cmd - (char *) urb->transfer_buffer;
+ int len;
+ if (cmd < (char *) urb->transfer_buffer +
urb->transfer_buffer_length)
+ *cmd++ = 0xAF;
+ len = cmd - (char *) urb->transfer_buffer;
ret = udl_submit_urb(dev, urb, len);
bytes_sent += len;
} else
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106471] Radeon HD 3450 acceleration not working
https://bugs.freedesktop.org/show_bug.cgi?id=106471 --- Comment #4 from mirh --- Phoronix also reported 4870 not to work on 4.17. Could you try some previous kernel version? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 4.17-rc7
On Sun 2018-06-03 10:27:02, Daniel Stone wrote: > Hi Pavel, > > On 2 June 2018 at 18:55, Pavel Machek wrote: > >> On 30 May 2018 at 12:17, Pavel Machek wrote: > >> > Any chance to still get in this one? > >> > > >> > https://github.com/freedesktop/drm-misc/commit/2bc5ff0bdc00d81d719dad74589317a260d583ed > >> > > >> > ...it fixes display on Nokia N900, and display is rather important for > >> > cellphone. > >> > >> The pull request was sent to Dave just yesterday: > >> https://lists.freedesktop.org/archives/dri-devel/2018-May/178606.html > > > > Still nothing in the mainline. If there's no -rc8, time is running out > > :-(. > > https://lists.freedesktop.org/archives/dri-devel/2018-June/179000.html Yep, and patch is in now and seems to work. Thanks to everyone involved! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 4.17-rc7
Hi Pavel, On 2 June 2018 at 18:55, Pavel Machek wrote: >> On 30 May 2018 at 12:17, Pavel Machek wrote: >> > Any chance to still get in this one? >> > >> > https://github.com/freedesktop/drm-misc/commit/2bc5ff0bdc00d81d719dad74589317a260d583ed >> > >> > ...it fixes display on Nokia N900, and display is rather important for >> > cellphone. >> >> The pull request was sent to Dave just yesterday: >> https://lists.freedesktop.org/archives/dri-devel/2018-May/178606.html > > Still nothing in the mainline. If there's no -rc8, time is running out > :-(. https://lists.freedesktop.org/archives/dri-devel/2018-June/179000.html Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/psr: Fix missed entry in PSR setup time table." has been added to the 4.14-stable tree
This is a note to let you know that I've just added the patch titled
drm/psr: Fix missed entry in PSR setup time table.
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-psr-fix-missed-entry-in-psr-setup-time-table.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From bdcc02cf1bb508fc700df7662f55058f651f2621 Mon Sep 17 00:00:00 2001
From: Dhinakaran Pandiyan
Date: Fri, 11 May 2018 12:51:42 -0700
Subject: drm/psr: Fix missed entry in PSR setup time table.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dhinakaran Pandiyan
commit bdcc02cf1bb508fc700df7662f55058f651f2621 upstream.
Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this could potentially result in enabling
PSR on a panel with a higher setup time requirement than supported by the
hardware.
I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a.
Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Cc: Jose Roberto de Souza
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: José Roberto de Souza
Reviewed-by: Tarun Vyas
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-3-dhinakaran.pandi...@intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_dp_helper.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1139,6 +1139,7 @@ int drm_dp_psr_setup_time(const u8 psr_c
static const u16 psr_setup_time_us[] = {
PSR_SETUP_TIME(330),
PSR_SETUP_TIME(275),
+ PSR_SETUP_TIME(220),
PSR_SETUP_TIME(165),
PSR_SETUP_TIME(110),
PSR_SETUP_TIME(55),
Patches currently in stable-queue which might be from
dhinakaran.pandi...@intel.com are
queue-4.14/drm-psr-fix-missed-entry-in-psr-setup-time-table.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/psr: Fix missed entry in PSR setup time table." has been added to the 4.9-stable tree
This is a note to let you know that I've just added the patch titled
drm/psr: Fix missed entry in PSR setup time table.
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-psr-fix-missed-entry-in-psr-setup-time-table.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From bdcc02cf1bb508fc700df7662f55058f651f2621 Mon Sep 17 00:00:00 2001
From: Dhinakaran Pandiyan
Date: Fri, 11 May 2018 12:51:42 -0700
Subject: drm/psr: Fix missed entry in PSR setup time table.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dhinakaran Pandiyan
commit bdcc02cf1bb508fc700df7662f55058f651f2621 upstream.
Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this could potentially result in enabling
PSR on a panel with a higher setup time requirement than supported by the
hardware.
I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a.
Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Cc: Jose Roberto de Souza
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: José Roberto de Souza
Reviewed-by: Tarun Vyas
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-3-dhinakaran.pandi...@intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_dp_helper.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1065,6 +1065,7 @@ int drm_dp_psr_setup_time(const u8 psr_c
static const u16 psr_setup_time_us[] = {
PSR_SETUP_TIME(330),
PSR_SETUP_TIME(275),
+ PSR_SETUP_TIME(220),
PSR_SETUP_TIME(165),
PSR_SETUP_TIME(110),
PSR_SETUP_TIME(55),
Patches currently in stable-queue which might be from
dhinakaran.pandi...@intel.com are
queue-4.9/drm-psr-fix-missed-entry-in-psr-setup-time-table.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/psr: Fix missed entry in PSR setup time table." has been added to the 4.16-stable tree
This is a note to let you know that I've just added the patch titled
drm/psr: Fix missed entry in PSR setup time table.
to the 4.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-psr-fix-missed-entry-in-psr-setup-time-table.patch
and it can be found in the queue-4.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From bdcc02cf1bb508fc700df7662f55058f651f2621 Mon Sep 17 00:00:00 2001
From: Dhinakaran Pandiyan
Date: Fri, 11 May 2018 12:51:42 -0700
Subject: drm/psr: Fix missed entry in PSR setup time table.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dhinakaran Pandiyan
commit bdcc02cf1bb508fc700df7662f55058f651f2621 upstream.
Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this could potentially result in enabling
PSR on a panel with a higher setup time requirement than supported by the
hardware.
I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a.
Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Cc: Jose Roberto de Souza
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: José Roberto de Souza
Reviewed-by: Tarun Vyas
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-3-dhinakaran.pandi...@intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_dp_helper.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1141,6 +1141,7 @@ int drm_dp_psr_setup_time(const u8 psr_c
static const u16 psr_setup_time_us[] = {
PSR_SETUP_TIME(330),
PSR_SETUP_TIME(275),
+ PSR_SETUP_TIME(220),
PSR_SETUP_TIME(165),
PSR_SETUP_TIME(110),
PSR_SETUP_TIME(55),
Patches currently in stable-queue which might be from
dhinakaran.pandi...@intel.com are
queue-4.16/drm-psr-fix-missed-entry-in-psr-setup-time-table.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
