[PATCH v9 3/4] drm/panel: add Innolux TV123WAM panel driver support
Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda
Reviewed-by: Sean Paul
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 234af81..8c72270 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1190,6 +1190,30 @@ static void panel_simple_shutdown(struct device *dev)
},
};
+static const struct drm_display_mode innolux_tv123wam_mode = {
+ .clock = 206016,
+ .hdisplay = 2160,
+ .hsync_start = 2160 + 48,
+ .hsync_end = 2160 + 48 + 32,
+ .htotal = 2160 + 48 + 32 + 80,
+ .vdisplay = 1440,
+ .vsync_start = 1440 + 3,
+ .vsync_end = 1440 + 3 + 10,
+ .vtotal = 1440 + 3 + 10 + 27,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc innolux_tv123wam = {
+ .modes = &innolux_tv123wam_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 259,
+ .height = 173,
+ },
+};
+
static const struct drm_display_mode innolux_zj070na_01p_mode = {
.clock = 51501,
.hdisplay = 1024,
@@ -2037,6 +2061,9 @@ static void panel_simple_shutdown(struct device *dev)
.compatible = "innolux,n156bge-l21",
.data = &innolux_n156bge_l21,
}, {
+ .compatible = "innolux,tv123wam",
+ .data = &innolux_tv123wam,
+ }, {
.compatible = "innolux,zj070na-01p",
.data = &innolux_zj070na_01p,
}, {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mxsfb: rename driver to mxsfb-drm
On 06/13/2018 03:52 PM, Fabio Estevam wrote: > On Wed, Jun 13, 2018 at 9:38 AM, Stefan Agner wrote: > >> It seems to me a rather extreme measure though, given we could fix the >> situation rather easily. > > There are dtb's using the fbdev mxsfb driver like for example: > arch/arm/boot/dts/imx28-evk.dts > > If we kill the fbdev mxsfb driver then the display will stop working > for some users and I don't think they will be happy. Maybe it's time to fix them ? Having two drivers for the same hardware in the kernel is a bad idea and the new driver was in the kernel for long enough for the user of the old deprecated bindings migrated over I think. > Last time I tried it was not possible to use the original fbdev mxsfb > bindings with the new drm driver. > > Of course we can convert to the drm mxsfb driver, but IMHO we should > avoid functional breakage all of a sudden. The driver was in the kernel for over a year now though, so it's not new and sudden anymore. > In the meantime Stefan's patch seems to be a good approach. > -- Best regards, Marek Vasut ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/9] xen/balloon: Share common memory reservation routines
On 06/13/2018 02:26 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 03:47 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
diff --git a/include/xen/mem-reservation.h
b/include/xen/mem-reservation.h
new file mode 100644
index ..e0939387278d
--- /dev/null
+++ b/include/xen/mem-reservation.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Xen memory reservation utilities.
+ *
+ * Copyright (c) 2003, B Dragovic
+ * Copyright (c) 2003-2004, M Williamson, K Fraser
+ * Copyright (c) 2005 Dan M. Smith, IBM Corporation
+ * Copyright (c) 2010 Daniel Kiper
+ * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#ifndef _XENMEM_RESERVATION_H
+#define _XENMEM_RESERVATION_H
+
+#include
+#include
+
+#include
+#include
+
+#include
+#include
I should have noticed this in the previous post but I suspect most of
these includes belong in the C file. For example, there is no reason
for hypercall.h here.
Yes, it seems that the header can only have
#include
Will move the rest into the .c file
You may need something for clear_highpage() and maybe for Xen feature
flags. But you'll find out for sure when you try to build. ;-)
-boris
-boris
+
+static inline void xenmem_reservation_scrub_page(struct page *page)
+{
+#ifdef CONFIG_XEN_SCRUB_PAGES
+ clear_highpage(page);
+#endif
+}
+
+#ifdef CONFIG_XEN_HAVE_PVMMU
+void __xenmem_reservation_va_mapping_update(unsigned long count,
+ struct page **pages,
+ xen_pfn_t *frames);
+
+void __xenmem_reservation_va_mapping_reset(unsigned long count,
+ struct page **pages);
+#endif
+
+static inline void xenmem_reservation_va_mapping_update(unsigned
long count,
+ struct page **pages,
+ xen_pfn_t *frames)
+{
+#ifdef CONFIG_XEN_HAVE_PVMMU
+ if (!xen_feature(XENFEAT_auto_translated_physmap))
+ __xenmem_reservation_va_mapping_update(count, pages, frames);
+#endif
+}
+
+static inline void xenmem_reservation_va_mapping_reset(unsigned long
count,
+ struct page **pages)
+{
+#ifdef CONFIG_XEN_HAVE_PVMMU
+ if (!xen_feature(XENFEAT_auto_translated_physmap))
+ __xenmem_reservation_va_mapping_reset(count, pages);
+#endif
+}
+
+int xenmem_reservation_increase(int count, xen_pfn_t *frames);
+
+int xenmem_reservation_decrease(int count, xen_pfn_t *frames);
+
+#endif
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
Hi, Dne sreda, 13. junij 2018 ob 09:34:56 CEST je Maxime Ripard napisal(a): > Hi, > > Thanks for working on this! > > On Tue, Jun 12, 2018 at 10:00:13PM +0200, Jernej Skrabec wrote: > > TCON TOP main purpose is to configure whole display pipeline. It > > determines relationships between mixers and TCONs, selects source TCON > > for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder > > clock source and contains additional TV TCON and DSI gates. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > .../bindings/display/sunxi/sun4i-drm.txt | 45 +++ > > include/dt-bindings/clock/sun8i-tcon-top.h| 11 + > > 2 files changed, 56 insertions(+) > > create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h > > > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > > 3346c1e2a7a0..ef64c589a4b3 100644 > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > > @@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more clock line: > > - 'lvds-alt': An alternative clock source, separate from the TCON > > channel 0 > > > > clock, that can be used to drive the LVDS clock > > > > +TCON TOP > > + > > + > > +TCON TOPs main purpose is to configure whole display pipeline. It > > determines +relationships between mixers and TCONs, selects source TCON > > for HDMI, muxes +LCD and TV encoder GPIO output, selects TV encoder clock > > source and contains +additional TV TCON and DSI gates. > > + > > +It allows display pipeline to be configured in very different ways: > > + > > + / LCD0/LVDS0 > > + / TCON-LCD0 > > + | \ MIPI DSI > > + mixer0 | > > +\/ TCON-LCD1 - LCD1/LVDS1 > > + TCON-TOP > > +/\ TCON-TV0 - TVE0/RGB > > + mixer1 | \ > > + | TCON-TOP - HDMI > > + | / > > + \ TCON-TV1 - TVE1/RGB > > + > > +Note that both TCON TOP references same physical unit. > > + > > +Required properties: > > + - compatible: value must be one of: > > +* allwinner,sun8i-r40-tcon-top > > + - reg: base address and size of the memory-mapped region. > > + - clocks: phandle to the clocks feeding the TCON TOP > > +* bus: TCON TOP interface clock > > + - clock-names: clock name mentioned above > > + - resets: phandle to the reset line driving the DRC > > s/DRC/TCON TOP/ ? Yes, copy & paste issue > > > +* rst: TCON TOP reset line > > Remaining consistent with the clock name would be great You mean "ahb"? I noticed that most other nodes with reset lines don't have a name associated. Maybe I could just drop it and use first specified reset? > > > + - reset-names: reset name mentioned above > > + - #clock-cells : must contain 1 > > An example would be nice here You mean node example? with ports? In the past, Rob was against examples unless really necessary. Node from R40 DTSI can serve as an example. > > > +- ports: A ports node with endpoint definitions as defined in > > +Documentation/devicetree/bindings/media/video-interfaces.txt. The > > first port +should be the input for mixer0 mux. The second should be > > the output for that +mux. Third port should be input for mixer1 mux. > > Fourth port should be output +for mixer1 mux. Fifth port should be > > input for HDMI mux. Sixth port should +be output for it. All output > > endpoints should have reg property with the id +of the target TCON. > > All ports should have only one enpoint connected to > ^ endpoint > > I guess it would me more readable if you were to make it a bullet > list, but this works for me otherwise. Since I have to fix this patch anyway, I can refactor this text. Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality
On 06/13/2018 06:14 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:
int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd)
{
- return -EINVAL;
+ struct gntdev_dmabuf *gntdev_dmabuf;
+ struct dma_buf_attachment *attach;
+ struct dma_buf *dma_buf;
+
+ gntdev_dmabuf = dmabuf_imp_find_unlink(priv, fd);
+ if (IS_ERR(gntdev_dmabuf))
+ return PTR_ERR(gntdev_dmabuf);
+
+ pr_debug("Releasing DMA buffer with fd %d\n", fd);
+
+ attach = gntdev_dmabuf->u.imp.attach;
+
+ if (gntdev_dmabuf->u.imp.sgt)
+ dma_buf_unmap_attachment(attach, gntdev_dmabuf->u.imp.sgt,
+ DMA_BIDIRECTIONAL);
+ dma_buf = attach->dmabuf;
+ dma_buf_detach(attach->dmabuf, attach);
+ dma_buf_put(dma_buf);
+
+ dmabuf_imp_end_foreign_access(gntdev_dmabuf->u.imp.refs,
+ gntdev_dmabuf->nr_pages);
Should you first end foreign access, before doing anything?
I am rolling back in reverse order here, so I think we first need
to finish local activities with the buffer and then end foreign
access.
-boris
+ dmabuf_imp_free_storage(gntdev_dmabuf);
+ return 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/4] drm/bridge: add support for sn65dsi86 bridge driver
On 2018-06-12 05:05, Stephen Boyd wrote:
Quoting Sandeep Panda (2018-06-04 22:40:15)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
new file mode 100644
index 000..add6e0f
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -0,0 +1,666 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
[...]
+
+static const struct regmap_config ti_sn_bridge_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .volatile_table = &ti_sn_bridge_volatile_table,
+ .cache_type = REGCACHE_NONE,
+};
+
+static void ti_sn_bridge_write_u16(struct ti_sn_bridge *pdata,
+ unsigned int reg, u16 val)
+{
+ regmap_write(pdata->regmap, reg, val & 0xFF);
+ regmap_write(pdata->regmap, reg + 1, val >> 8);
+}
+
+static int __maybe_unused ti_sn_bridge_resume(struct device *dev)
+{
+ struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
+ int ret = 0;
Please don't assign variables and then reassign them again immediately
after. It hides use before real initialization bugs.
Ok.
+
+ ret = regulator_bulk_enable(SN_REGULATOR_SUPPLY_NUM,
pdata->supplies);
[...]
+
+static int ti_sn_bridge_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct ti_sn_bridge *pdata;
+ struct device_node *ddc_node;
+ struct mipi_dsi_host *host;
+ struct mipi_dsi_device *dsi;
+ int ret = 0;
+ const struct mipi_dsi_device_info info = { .type =
"ti_sn_bridge",
+ .channel = 0,
+ .node = NULL,
+};
+
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
+ DRM_ERROR("device doesn't support I2C\n");
+ return -ENODEV;
+ }
+
+ ret = ti_sn_bridge_parse_dsi_host(pdata);
+ if (ret)
+ return ret;
+
+ host = of_find_mipi_dsi_host_by_node(pdata->host_node);
+ if (!host) {
+ DRM_ERROR("failed to find dsi host\n");
Not sure we want to print an error and then return -EPROBE_DEFER.
Usually EPROBE_DEFER is silent.
+ ret = -EPROBE_DEFER;
+ goto err_dsi_host;
+ }
+
[...]
+
+ /* TODO: setting to 4 lanes always for now */
+ dsi->lanes = 4;
+ dsi->format = MIPI_DSI_FMT_RGB888;
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_EOT_PACKET |
MIPI_DSI_MODE_VIDEO_HSE;
+
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ DRM_ERROR("failed to attach dsi to host\n");
+ goto err_dsi_attach;
+ }
+ pdata->dsi = dsi;
+
+ pdata->refclk = devm_clk_get(pdata->dev, "refclk");
We need to check for error
if (IS_ERR(pdata->refclk))
And then if it's EPROBE_DEFER I suppose we would bail out, otherwise
assume it's not present?
Yes found this issue while testing the driver on actual sn65dsi86 HW, i
will fix this in next patchset.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
On 2018-06-12 14:01, Stephen Boyd wrote: Quoting spa...@codeaurora.org (2018-06-05 21:50:16) On 2018-06-05 20:50, Rob Herring wrote: > On Tue, Jun 05, 2018 at 11:10:16AM +0530, Sandeep Panda wrote: >> Document the bindings used for the sn65dsi86 DSI to eDP bridge. [...] >> and >> + the second cell is used to specify flags. >> + See ../../gpio/gpio.txt for more information. >> +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description >> of >> + the cell formats. >> + >> +- clock-names: should be "refclk" >> +- clocks: Specification for input reference clock. The reference >> + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. >> + >> +- lane-mapping: Specification to describe the logical to physical >> lane > > As I mentioned in v7, we already have a property for this. It's called > 'data-lanes' and defined in media/video-interfaces.txt. Use that. If > you > need polarity too, then add a property for that. And add it to > video-interfaces.txt. The data-lanes property mentioned in media/video-interfaces.txt is referring to DSI/CSI lanes where assumption is clock lane is fixed at index 0. But here the we want to mention about eDP lanes which do not have dedicated clock lane. So can we still use the existing data-lanes property here? Why is that a problem? It's just a property name. There are data-lanes and clock-lanes properties in the video-interfaces.txt file by the way. It would be nice if that document could be updated for displayport and DSI (e.g. clock-noncontinuous or link-frequencies) or even just mention in there that these can apply to DSI and displayport too. For this current review, i have modified the property description to point to media/video.txt for explanation. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 4/4] dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as done by other existing panel support changes.
Changes in v2:
- Separate driver change from dt-binding documentation (Rob Herring).
- Add the properties from simple-panel binding that are applicable to
this panel (Rob Herring).
Signed-off-by: Sandeep Panda
Reviewed-by: Rob Herring
---
.../bindings/display/panel/innolux,tv123wam.txt | 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
b/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
new file mode 100644
index 000..a9b3526
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
@@ -0,0 +1,20 @@
+Innolux TV123WAM 12.3 inch eDP 2K display panel
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible: should be "innolux,tv123wam"
+- power-supply: regulator to provide the supply voltage
+
+Optional properties:
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+ panel_edp: panel-edp {
+ compatible = "innolux,tv123wam";
+ enable-gpios = <&msmgpio 31 GPIO_ACTIVE_LOW>;
+ power-supply = <&pm8916_l2>;
+ backlight = <&backlight>;
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 2018-06-13 11:06, Ard Biesheuvel wrote: On 13 June 2018 at 16:22, Sinan Kaya wrote: Hi Ard, On 5/18/2018 10:17 AM, Sinan Kaya wrote: A host bridge is allowed to remap BAR addresses using _TRA attribute in _CRS windows. pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] (bus address [0x0010-0x1fff]) pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff] When a VGA device is behind such a host bridge and the resource is translated efifb driver is trying to do ioremap against bus address rather than the resource address and is failing to probe. efifb: probing for efifb efifb: cannot reserve video memory at 0x1e00 efifb: framebuffer at 0x1e00, using 1920k, total 1875k efifb: mode is 800x600x32, linelength=3200, pages=1 efifb: scrolling: redraw efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 Use the host bridge offset information to convert bus address to resource address in the fixup. Signed-off-by: Sinan Kaya --- I didn't see any messages about these getting picked up for 4.18. Are they queued on your own branch? No, you never cc'ed me on them until now. Ouch, I hoped that you would get it via get_maintainer script. Sorry for that. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/9] xen/gntdev: Add initial support for dma-buf UAPI
On 06/13/2018 04:49 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index a09db23e9663..e82660d81d7e 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -48,6 +48,9 @@
#include
#include "gntdev-common.h"
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+#include "gntdev-dmabuf.h"
+#endif
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Derek G. Murray , "
@@ -566,6 +569,15 @@ static int gntdev_open(struct inode *inode,
struct file *flip)
INIT_LIST_HEAD(&priv->freeable_maps);
mutex_init(&priv->lock);
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ priv->dmabuf_priv = gntdev_dmabuf_init();
+ if (IS_ERR(priv->dmabuf_priv)) {
+ ret = PTR_ERR(priv->dmabuf_priv);
+ kfree(priv);
+ return ret;
+ }
+#endif
+
if (use_ptemod) {
priv->mm = get_task_mm(current);
if (!priv->mm) {
@@ -616,8 +628,13 @@ static int gntdev_release(struct inode *inode,
struct file *flip)
WARN_ON(!list_empty(&priv->freeable_maps));
mutex_unlock(&priv->lock);
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ gntdev_dmabuf_fini(priv->dmabuf_priv);
+#endif
+
if (use_ptemod)
mmu_notifier_unregister(&priv->mn, priv->mm);
+
kfree(priv);
return 0;
}
@@ -987,6 +1004,107 @@ static long gntdev_ioctl_grant_copy(struct
gntdev_priv *priv, void __user *u)
return ret;
}
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+static long
+gntdev_ioctl_dmabuf_exp_from_refs(struct gntdev_priv *priv,
+ struct ioctl_gntdev_dmabuf_exp_from_refs __user *u)
Didn't we agree that this code moves to gntdev-dmabuf.c ?
Sure, didn't think we want IOCTL's code to be moved as well,
but that does make sense - will move all
-boris
Thank you,
Oleksandr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 13 June 2018 at 17:17, wrote: > On 2018-06-13 11:06, Ard Biesheuvel wrote: >> >> On 13 June 2018 at 16:22, Sinan Kaya wrote: >>> >>> Hi Ard, >>> >>> On 5/18/2018 10:17 AM, Sinan Kaya wrote: A host bridge is allowed to remap BAR addresses using _TRA attribute in _CRS windows. pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] (bus address [0x0010-0x1fff]) pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff] When a VGA device is behind such a host bridge and the resource is translated efifb driver is trying to do ioremap against bus address rather than the resource address and is failing to probe. efifb: probing for efifb efifb: cannot reserve video memory at 0x1e00 efifb: framebuffer at 0x1e00, using 1920k, total 1875k efifb: mode is 800x600x32, linelength=3200, pages=1 efifb: scrolling: redraw efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 Use the host bridge offset information to convert bus address to resource address in the fixup. Signed-off-by: Sinan Kaya --- >>> >>> >>> I didn't see any messages about these getting picked up for 4.18. >>> >>> Are they queued on your own branch? >>> >> >> No, you never cc'ed me on them until now. > > > Ouch, I hoped that you would get it via get_maintainer script. Sorry for > that. Actually, get_maintainer is right: this should go through the fbdev tree not the EFI tree Were you going to resend them? If not, I can find them in my archive and ack them, and we will ask Bartlomiej to take them for v4.19 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 2018-06-13 11:22, Ard Biesheuvel wrote: On 13 June 2018 at 17:17, wrote: On 2018-06-13 11:06, Ard Biesheuvel wrote: On 13 June 2018 at 16:22, Sinan Kaya wrote: Hi Ard, On 5/18/2018 10:17 AM, Sinan Kaya wrote: A host bridge is allowed to remap BAR addresses using _TRA attribute in _CRS windows. pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] (bus address [0x0010-0x1fff]) pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff] When a VGA device is behind such a host bridge and the resource is translated efifb driver is trying to do ioremap against bus address rather than the resource address and is failing to probe. efifb: probing for efifb efifb: cannot reserve video memory at 0x1e00 efifb: framebuffer at 0x1e00, using 1920k, total 1875k efifb: mode is 800x600x32, linelength=3200, pages=1 efifb: scrolling: redraw efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 Use the host bridge offset information to convert bus address to resource address in the fixup. Signed-off-by: Sinan Kaya --- I didn't see any messages about these getting picked up for 4.18. Are they queued on your own branch? No, you never cc'ed me on them until now. Ouch, I hoped that you would get it via get_maintainer script. Sorry for that. Actually, get_maintainer is right: this should go through the fbdev tree not the EFI tree Were you going to resend them? If not, I can find them in my archive and ack them, and we will ask Bartlomiej to take them for v4.19 I prefer ack rather than resend to be honest. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/4] drm/bridge: add support for sn65dsi86 bridge driver
Add support for TI's sn65dsi86 dsi2edp bridge chip. The chip converts DSI transmitted signal to eDP signal, which is fed to the connected eDP panel. This chip can be controlled via either i2c interface or dsi interface. Currently in driver all the control registers are being accessed through i2c interface only. Also as of now HPD support has not been added to bridge chip driver. Changes in v1: - Split the dt-bindings and the driver support into separate patches (Andrzej Hajda). - Use of gpiod APIs to parse and configure gpios instead of obsolete ones (Andrzej Hajda). - Use macros to define the register offsets (Andrzej Hajda). Changes in v2: - Separate out edp panel specific HW resource handling from bridge driver and create a separate edp panel drivers to handle panel specific mode information and HW resources (Sean Paul). - Replace pr_* APIs to DRM_* APIs to log error or debug information (Sean Paul). - Remove some of the unnecessary structure/variable from driver (Sean Paul). - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge" (Sean Paul / Rob Herring). - Remove most of the hard-coding and modified the bridge init sequence based on current mode (Sean Paul). - Remove the existing function to retrieve the EDID data and implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul). - Remove the dummy irq handler implementation, will add back the proper irq handling later (Sean Paul). - Capture the required enable gpios in a single array based on dt entry instead of having individual descriptor for each gpio (Sean Paul). Changes in v3: - Remove usage of irq_gpio and replace it as "interrupts" property (Rob Herring). - Remove the unnecessary header file inclusions (Sean Paul). - Rearrange the header files in alphabetical order (Sean Paul). - Use regmap interface to perform i2c transactions. - Update Copyright/License field and address other review comments (Jordan Crouse). Changes in v4: - Update License/Copyright (Sean Paul). - Add Kconfig and Makefile changes (Sean Paul). - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios will be handled by i2c master. - Update required supplies names. - Remove unnecessary goto statements (Sean Paul). - Add mutex lock to power_ctrl API to avoid race conditions (Sean Paul). - Add support to parse reference clk frequency from dt(optional). - Update the bridge chip enable/disable sequence. Changes in v5: - Fixed Kbuild test service reported warnings. Changes in v6: - Use PM runtime based ref-counting instead of local ref_count mechanism (Stephen Boyd). - Clean up some debug logs and indentations (Sean Paul). - Simplify dp rate calculation (Sean Paul). - Add support to configure refclk based on input REFCLK pin or DACP/N pin (Stephen Boyd). Changes in v7: - Use static supply entries instead of dynamic allocation (Andrzej Hajda). - Defer bridge driver probe if panel is not probed (Andrzej Hajda). - Update of_graph APIs for correct node reference management. (Andrzej Hajda). - Remove local display_mode object (Andrzej Hajda). - Remove version id check function from driver. Changes in v8: - Move dsi register/attach function to bridge driver probe (Andrzej Hajda). - Introduce a new helper function to write 16bit words into consecutive registers (Andrzej Hajda). - Remove unnecessary macros (Andrzej Hajda). Changes in v9: - Remove dsi register/attach from bridge probe, since dsi dev register completion also waits for any panel or bridge to get added. This creates deadlock situation when bridge driver calls dsi dev register and attach before bridge add, in its probe function. - Fix issues faced during testing of bridge driver on actual HW. - Remove unnecessary initializations (Stephen Boyd). - Use local refclk lut size instead of global macro (Sean Paul). Signed-off-by: Sandeep Panda --- drivers/gpu/drm/bridge/Kconfig| 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 691 ++ 3 files changed, 701 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 3b99d5a..8153150 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -108,6 +108,15 @@ config DRM_TI_TFP410 ---help--- Texas Instruments TFP410 DVI/HDMI Transmitter driver +config DRM_TI_SN65DSI86 + tristate "TI SN65DSI86 DSI to eDP bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + ---help--- + Texas Instruments SN65DSI86 DSI to eDP Bridge driver + source "drivers/gpu/drm/bridge/analogix/Kconfig" source "drivers/gpu/drm/bridge/adv7511/Kconfig" diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 373eb28..a7ca000 1
Re: [linux-sunxi] Re: [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
Dne sreda, 13. junij 2018 ob 09:36:05 CEST je Maxime Ripard napisal(a): > On Tue, Jun 12, 2018 at 10:00:33PM +0200, Jernej Skrabec wrote: > > Function is useful when drm_of_find_possible_crtcs() can't be used and > > custom parsing is needed. This can happen for example when there is a > > node with multiple muxes between crtc and encoder. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > drivers/gpu/drm/drm_of.c | 4 ++-- > > include/drm/drm_of.h | 8 > > 2 files changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c > > index 1fe122461298..2e9cea3287b2 100644 > > --- a/drivers/gpu/drm/drm_of.c > > +++ b/drivers/gpu/drm/drm_of.c > > @@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void > > *data)> > > * Given a port OF node, return the possible mask of the corresponding > > * CRTC within a device's list of CRTCs. Returns zero if not found. > > */ > > > > -static uint32_t drm_crtc_port_mask(struct drm_device *dev, > > - struct device_node *port) > > +uint32_t drm_crtc_port_mask(struct drm_device *dev, > > + struct device_node *port) > > It should probably be exported too? Yes, of course. It will be in next version. Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 8/9] xen/gntdev: Implement dma-buf export functionality
On 06/13/2018 05:58 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
corresponding dma_alloc_xxx API.
Export the resulting buffer as a new dma-buf.
2. Implement waiting for the dma-buf to be released: block until the
dma-buf with the file descriptor provided is released.
If within the time-out provided the buffer is not released then
-ETIMEDOUT error is returned. If the buffer with the file descriptor
does not exist or has already been released, then -ENOENT is
returned. For valid file descriptors this must not be treated as
error.
3. Make gntdev's common code and structures available to dma-buf.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-common.h | 4 +
drivers/xen/gntdev-dmabuf.c | 470 +++-
drivers/xen/gntdev.c | 10 +
3 files changed, 482 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
index a3408fd39b07..72f80dbce861 100644
--- a/drivers/xen/gntdev-common.h
+++ b/drivers/xen/gntdev-common.h
@@ -89,4 +89,8 @@ bool gntdev_account_mapped_pages(int count);
int gntdev_map_grant_pages(struct gntdev_grant_map *map);
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+void gntdev_remove_map(struct gntdev_priv *priv, struct
gntdev_grant_map *map);
+#endif
+
#endif
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index dc57c6a25525..84cba67c6ad7 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -3,13 +3,53 @@
/*
* Xen dma-buf functionality for gntdev.
*
+ * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
+ *
* Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
*/
+#include
#include
+#include
+#include
+
+#include "gntdev-common.h"
#include "gntdev-dmabuf.h"
+struct gntdev_dmabuf {
+ struct gntdev_dmabuf_priv *priv;
+ struct dma_buf *dmabuf;
+ struct list_head next;
+ int fd;
+
+ union {
+ struct {
+ /* Exported buffers are reference counted. */
+ struct kref refcount;
+
+ struct gntdev_priv *priv;
+ struct gntdev_grant_map *map;
+ } exp;
+ } u;
+
+ /* Number of pages this buffer has. */
+ int nr_pages;
+ /* Pages of this buffer. */
+ struct page **pages;
+};
+
+struct gntdev_dmabuf_wait_obj {
+ struct list_head next;
+ struct gntdev_dmabuf *gntdev_dmabuf;
+ struct completion completion;
+};
+
+struct gntdev_dmabuf_attachment {
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
+};
+
struct gntdev_dmabuf_priv {
/* List of exported DMA buffers. */
struct list_head exp_list;
@@ -23,17 +63,439 @@ struct gntdev_dmabuf_priv {
/* Implementation of wait for exported DMA buffer to be released. */
+static void dmabuf_exp_release(struct kref *kref);
+
+static struct gntdev_dmabuf_wait_obj *
+dmabuf_exp_wait_obj_new(struct gntdev_dmabuf_priv *priv,
+ struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ struct gntdev_dmabuf_wait_obj *obj;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ init_completion(&obj->completion);
+ obj->gntdev_dmabuf = gntdev_dmabuf;
+
+ mutex_lock(&priv->lock);
+ list_add(&obj->next, &priv->exp_wait_list);
+ /* Put our reference and wait for gntdev_dmabuf's release to
fire. */
+ kref_put(&gntdev_dmabuf->u.exp.refcount, dmabuf_exp_release);
+ mutex_unlock(&priv->lock);
+ return obj;
+}
+
+static void dmabuf_exp_wait_obj_free(struct gntdev_dmabuf_priv *priv,
+ struct gntdev_dmabuf_wait_obj *obj)
+{
+ struct gntdev_dmabuf_wait_obj *cur_obj, *q;
+
+ mutex_lock(&priv->lock);
+ list_for_each_entry_safe(cur_obj, q, &priv->exp_wait_list, next)
+ if (cur_obj == obj) {
+ list_del(&obj->next);
+ kfree(obj);
+ break;
+ }
+ mutex_unlock(&priv->lock);
Do we really need to walk the list?
It can be deleted without walking the list and no reason to do that walk.
Just an example of over-engineering here, thank you for spotting this.
And if we do, do we need the safe variant of the walk? We are holding
the lock. Here and elsewhere.
You are perfectly right. I will not use safe variant of the walk, no
need for that
+}
+
+static int dmabuf_exp_wait_obj_wait(struct gntdev_dmabuf_wait_obj *obj,
+ u32 wait_to_ms)
+{
+ if (wait_for_completion_timeout(&obj->completion,
+ msecs_to_jiffies(wait_to_ms)) <= 0)
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+static void dmabuf_exp_wait_obj_signal(struct gntdev_dmabuf_pr
Re: [linux-sunxi] Re: [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
Dne sreda, 13. junij 2018 ob 10:04:20 CEST je Chen-Yu Tsai napisal(a):
> On Wed, Jun 13, 2018 at 3:46 PM, Maxime Ripard
>
> wrote:
> > On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
> >> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> >> sense to check if panel or bridge is connected to them.
> >>
> >> Check if TCON has channel 0 and only then check for connected panel or
> >> bridges.
> >>
> >> Signed-off-by: Jernej Skrabec
> >> ---
> >>
> >> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +---
> >> 1 file changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> b/drivers/gpu/drm/sun4i/sun4i_tcon.c index b1205a7bc20f..c9ffa5381185
> >> 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops
> >> = {>>
> >> static int sun4i_tcon_probe(struct platform_device *pdev)
> >> {
> >>
> >> struct device_node *node = pdev->dev.of_node;
> >>
> >> + const struct sun4i_tcon_quirks *quirks;
> >>
> >> struct drm_bridge *bridge;
> >> struct drm_panel *panel;
> >> int ret;
> >>
> >> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
> >> - if (ret == -EPROBE_DEFER)
> >> - return ret;
> >> + quirks = of_device_get_match_data(&pdev->dev);
> >
> > We should probably check ofr the pointer value before dereferencing it.
>
> I think we've discussed this before. If the driver has data structures
> for all the supported compatible strings, and it is device tree only,
> then we should just let it blow up in the user's face, since they are
> obviously doing something they shouldn't be doing to get the driver
> to probe without a compatible string match.
TCON can't work with no quirks specified, since that would mean that neither
channels are present. Additionally, sun4i_tcon_bind() also doesn't check if
quirks are NULL or not. So I concur with Chen-Yu here.
Best regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 8/9] xen/gntdev: Implement dma-buf export functionality
On 06/14/2018 01:19 AM, Boris Ostrovsky wrote:
On 06/13/2018 07:57 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 05:58 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
+
+static struct gntdev_dmabuf *
+dmabuf_exp_wait_obj_get_by_fd(struct gntdev_dmabuf_priv *priv, int fd)
The name of this routine implies (to me) that we are getting a wait
object but IIUIC we are getting a gntdev_dmabuf that we are going to
later associate with a wait object.
How about dmabuf_exp_wait_obj_get_dmabuf_by_fd?
I would like to keep function prefixes, e.g. dmabuf_exp_wait_obj_
just to show to which functionality a routine belongs.
That's too long IMO. If you really want to keep the prefix then let's
keep this the way it is. Maybe it's just me who read it that way.
I'll rename it to dmabuf_exp_wait_obj_get_dmabuf.
As it already wants fd it seems to be clear that
the lookup will be based on it.
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+void gntdev_remove_map(struct gntdev_priv *priv, struct
gntdev_grant_map *map)
+{
+ mutex_lock(&priv->lock);
+ list_del(&map->next);
+ gntdev_put_map(NULL /* already removed */, map);
Why not pass call gntdev_put_map(priv, map) and then not have this
routine at all?
Well, I wish I could, but the main difference when calling
gntdev_put_map(priv, map)
with priv != NULL and my code is that:
void gntdev_put_map(struct gntdev_priv *priv, struct gntdev_grant_map
*map)
{
[...]
if (populate_freeable_maps && priv) {
^
mutex_lock(&priv->lock);
list_del(&map->next);
mutex_unlock(&priv->lock);
}
[...]
}
and
#define populate_freeable_maps use_ptemod
^^
which means the map will never be removed from the list in my case
because use_ptemod == false for dma-buf.
This is why I do that by hand, e.g. remove the item from the list
and then pass NULL for priv.
Also, I will remove gntdev_remove_map as I can now access
priv->lock and gntdev_put_map directly form gntdev-dmabuf.c
Yes, that's a good idea.
I really dislike the fact that we are taking a lock here that
gntdev_put_map() takes as well, although not with NULL argument. (And
yes, I see that gntdev_release() does it too.)
This can be re-factored later I guess?
OK.
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 0/4] Add suppport for sn65dsi86 bridge chip and Innolux 2k edp panel
Changes in current patchset: - Remove dsi register/attach from bridge probe, since dsi dev register completion also waits for any panel or bridge to get added. This creates deadlock situation when bridge driver calls dsi dev register and attach before bridge add, in its probe function. - Fix issues faced during testing of bridge driver on actual HW. Sandeep Panda (4): drm/bridge: add support for sn65dsi86 bridge driver dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings drm/panel: add Innolux TV123WAM panel driver support dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings .../bindings/display/bridge/ti,sn65dsi86.txt | 90 +++ .../bindings/display/panel/innolux,tv123wam.txt| 20 + drivers/gpu/drm/bridge/Kconfig | 9 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 691 + drivers/gpu/drm/panel/panel-simple.c | 27 + 6 files changed, 838 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/9] xen: dma-buf support for grant device
Hi, Boris! It seems that I have resolved all the issues now which were mainly cleanup and code movement and 5 of 9 patches already have r-b's. Do you, as the primary reviewer of the series, think I can push (hopefully) the final version of the patches? Just in case you want to look at v4 it is at [1]. Thank you, Oleksandr [1] https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
On 2018-06-05 20:50, Rob Herring wrote: On Tue, Jun 05, 2018 at 11:10:16AM +0530, Sandeep Panda wrote: Document the bindings used for the sn65dsi86 DSI to eDP bridge. Changes in v1: - Rephrase the dt-binding descriptions to be more inline with existing bindings (Andrzej Hajda). - Add missing dt-binding that are parsed by corresponding driver (Andrzej Hajda). Changes in v2: - Remove edp panel specific dt-binding entries. Only keep bridge specific entries (Sean Paul). - Remove custom-modes dt entry since its usage is removed from driver also (Sean Paul). - Remove is-pluggable dt entry since this will not be needed anymore (Sean Paul). Changes in v3: - Remove irq-gpio dt entry and instead populate is an interrupt property (Rob Herring). Changes in v4: - Add link to bridge chip datasheet (Stephen Boyd) - Add vpll and vcc regulator supply bindings (Stephen Boyd) - Add ref clk optional dt binding (Stephen Boyd) - Add gpio-controller optional dt binding (Stephen Boyd) Changes in v5: - Use clock property to specify the input refclk (Stephen Boyd). - Update gpio cell and pwm cell numbers (Stephen Boyd). Changes in v6: - Add property to mention the lane mapping scheme and polarity inversion (Stephen Boyd). Changes in v7: - Detail description of lane mapping scheme dt property (Andrzej Hajda/ Rob Herring). - Removed HDP gpio binding, since the bridge uses IRQ signal to determine HPD, and IRQ property is already documented in binding. Signed-off-by: Sandeep Panda --- .../bindings/display/bridge/ti,sn65dsi86.txt | 109 + 1 file changed, 109 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt new file mode 100644 index 000..33329f9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt @@ -0,0 +1,109 @@ +SN65DSI86 DSI to eDP bridge chip + + +This is the binding for Texas Instruments SN65DSI86 bridge. +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf + +Required properties: +- compatible: Must be "ti,sn65dsi86" +- reg: i2c address of the chip, 0x2d as per datasheet +- enable-gpios: OF device-tree gpio specification for bridge_en pin (active high) + +- vccio-supply: A 1.8V supply that powers up the digital IOs. +- vpll-supply: A 1.8V supply that powers up the displayport PLL. +- vcca-supply: A 1.2V supply that powers up the analog circuits. +- vcc-supply: A 1.2V supply that powers up the digital core. + +Optional properties: +- interrupts: Specifier for the SN65DSI86 interrupt line. + +- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing + +- gpio-controller: Marks the device has a GPIO controller. +- #gpio-cells: Should be two. The first cell is the pin number and + the second cell is used to specify flags. + See ../../gpio/gpio.txt for more information. +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of + the cell formats. + +- clock-names: should be "refclk" +- clocks: Specification for input reference clock. The reference + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. + +- lane-mapping: Specification to describe the logical to physical lane As I mentioned in v7, we already have a property for this. It's called 'data-lanes' and defined in media/video-interfaces.txt. Use that. If you need polarity too, then add a property for that. And add it to video-interfaces.txt. Ok. modified in next patchset. + mapping scheme and polarity inversion of eDP lanes on PCB. + Each pair present at index n (where n lies between 0 and 3) + describes the lane mapping of logical lane to physical lane n + and the polarity(it should be either 1 or 0) of the physical lane n. + + For example: + lane-mapping = <2 1>, + <1 0>, + <3 1>, + <0 0>; + + The above mapping describes that logical lane 2 is mapped to + physical lane 0 and polarity of physical lane 0 is inverted, + logical lane 1 is mapped to physical lane 1 and polarity of + physical lane 1 is normal, logical lane 3 is mapped to physical + lane 2 and polarity of physical lane 2 is inverted, logical lane 0 + is mapped to physical lane 4 and polarity of physical lane 3 is normal. + + If this property is not mentioned then it is assumed that physical + lanes 0 through 3 are mapped to logical lanes 0 through 3 and polarity + of all physical lanes is normal. + +Required nodes: +This device has two video
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 2018-06-13 11:45, Ard Biesheuvel wrote:
On 18 May 2018 at 16:17, Sinan Kaya wrote:
A host bridge is allowed to remap BAR addresses using _TRA attribute
in
_CRS windows.
pci_bus :00: root bus resource [mem 0x8010010-0x8011fff
window] (bus address [0x0010-0x1fff])
pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
When a VGA device is behind such a host bridge and the resource is
translated efifb driver is trying to do ioremap against bus address
rather than the resource address and is failing to probe.
efifb: probing for efifb
efifb: cannot reserve video memory at 0x1e00
efifb: framebuffer at 0x1e00, using 1920k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Use the host bridge offset information to convert bus address to
resource address in the fixup.
Signed-off-by: Sinan Kaya
Reviewed-by: Ard Biesheuvel
Bartlomiej, could you please take these via the fbdev tree for v4.19?
Peter already gave his ack but Sinan dropped it (presumably because of
the split in v2)
Sinan, does this need to go to -stable? I.e., has it ever worked
before?
Yes, it needs to go to stable. It never worked before. Issue was found
during a graphics bring up with AST driver.
It needs a 32 bit graphics card and a 32 bit translating host bridge to
hit the issue.
---
drivers/video/fbdev/efifb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 6daac8d..429cc85 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -431,6 +431,7 @@ static void efifb_fixup_resources(struct pci_dev
*dev)
.end = screen_info.lfb_base + screen_info.lfb_size -
1,
.flags = IORESOURCE_MEM,
};
+ struct pci_bus_region region;
int i;
if (efifb_pci_dev || screen_info.orig_video_isVGA !=
VIDEO_TYPE_EFI)
@@ -442,6 +443,10 @@ static void efifb_fixup_resources(struct pci_dev
*dev)
if (!screen_res.start)
return;
+ region.start = screen_res.start;
+ region.end = screen_res.end;
+ pcibios_bus_to_resource(dev->bus, &screen_res, ®ion);
+
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
struct resource *res = &dev->resource[i];
--
2.7.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/9] xen/balloon: Share common memory reservation routines
On 06/13/2018 03:02 PM, Boris Ostrovsky wrote:
On 06/13/2018 02:26 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 03:47 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
diff --git a/include/xen/mem-reservation.h
b/include/xen/mem-reservation.h
new file mode 100644
index ..e0939387278d
--- /dev/null
+++ b/include/xen/mem-reservation.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Xen memory reservation utilities.
+ *
+ * Copyright (c) 2003, B Dragovic
+ * Copyright (c) 2003-2004, M Williamson, K Fraser
+ * Copyright (c) 2005 Dan M. Smith, IBM Corporation
+ * Copyright (c) 2010 Daniel Kiper
+ * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#ifndef _XENMEM_RESERVATION_H
+#define _XENMEM_RESERVATION_H
+
+#include
+#include
+
+#include
+#include
+
+#include
+#include
I should have noticed this in the previous post but I suspect most
of these includes belong in the C file. For example, there is no
reason for hypercall.h here.
Yes, it seems that the header can only have
#include
Will move the rest into the .c file
You may need something for clear_highpage() and maybe for Xen feature
flags. But you'll find out for sure when you try to build. ;-)
#include
;)
-boris
-boris
+
+static inline void xenmem_reservation_scrub_page(struct page *page)
+{
+#ifdef CONFIG_XEN_SCRUB_PAGES
+ clear_highpage(page);
+#endif
+}
+
+#ifdef CONFIG_XEN_HAVE_PVMMU
+void __xenmem_reservation_va_mapping_update(unsigned long count,
+ struct page **pages,
+ xen_pfn_t *frames);
+
+void __xenmem_reservation_va_mapping_reset(unsigned long count,
+ struct page **pages);
+#endif
+
+static inline void xenmem_reservation_va_mapping_update(unsigned
long count,
+ struct page **pages,
+ xen_pfn_t *frames)
+{
+#ifdef CONFIG_XEN_HAVE_PVMMU
+ if (!xen_feature(XENFEAT_auto_translated_physmap))
+ __xenmem_reservation_va_mapping_update(count, pages, frames);
+#endif
+}
+
+static inline void xenmem_reservation_va_mapping_reset(unsigned
long count,
+ struct page **pages)
+{
+#ifdef CONFIG_XEN_HAVE_PVMMU
+ if (!xen_feature(XENFEAT_auto_translated_physmap))
+ __xenmem_reservation_va_mapping_reset(count, pages);
+#endif
+}
+
+int xenmem_reservation_increase(int count, xen_pfn_t *frames);
+
+int xenmem_reservation_decrease(int count, xen_pfn_t *frames);
+
+#endif
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
Hi Ard, On 5/18/2018 10:17 AM, Sinan Kaya wrote: > A host bridge is allowed to remap BAR addresses using _TRA attribute in > _CRS windows. > > pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] > (bus address [0x0010-0x1fff]) > pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff] > > When a VGA device is behind such a host bridge and the resource is > translated efifb driver is trying to do ioremap against bus address > rather than the resource address and is failing to probe. > > efifb: probing for efifb > efifb: cannot reserve video memory at 0x1e00 > efifb: framebuffer at 0x1e00, using 1920k, total 1875k > efifb: mode is 800x600x32, linelength=3200, pages=1 > efifb: scrolling: redraw > efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > > Use the host bridge offset information to convert bus address to > resource address in the fixup. > > Signed-off-by: Sinan Kaya > --- I didn't see any messages about these getting picked up for 4.18. Are they queued on your own branch? Sinan -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/9] xen/balloon: Share common memory reservation routines
On 06/13/2018 03:03 PM, Oleksandr Andrushchenko wrote:
On 06/13/2018 03:02 PM, Boris Ostrovsky wrote:
On 06/13/2018 02:26 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 03:47 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
diff --git a/include/xen/mem-reservation.h
b/include/xen/mem-reservation.h
new file mode 100644
index ..e0939387278d
--- /dev/null
+++ b/include/xen/mem-reservation.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Xen memory reservation utilities.
+ *
+ * Copyright (c) 2003, B Dragovic
+ * Copyright (c) 2003-2004, M Williamson, K Fraser
+ * Copyright (c) 2005 Dan M. Smith, IBM Corporation
+ * Copyright (c) 2010 Daniel Kiper
+ * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#ifndef _XENMEM_RESERVATION_H
+#define _XENMEM_RESERVATION_H
+
+#include
+#include
+
+#include
+#include
+
+#include
+#include
I should have noticed this in the previous post but I suspect most
of these includes belong in the C file. For example, there is no
reason for hypercall.h here.
Yes, it seems that the header can only have
#include
Will move the rest into the .c file
You may need something for clear_highpage() and maybe for Xen feature
flags. But you'll find out for sure when you try to build. ;-)
#include
Or even
#include
according to [1]
;)
-boris
-boris
+
+static inline void xenmem_reservation_scrub_page(struct page *page)
+{
+#ifdef CONFIG_XEN_SCRUB_PAGES
+ clear_highpage(page);
+#endif
+}
+
+#ifdef CONFIG_XEN_HAVE_PVMMU
+void __xenmem_reservation_va_mapping_update(unsigned long count,
+ struct page **pages,
+ xen_pfn_t *frames);
+
+void __xenmem_reservation_va_mapping_reset(unsigned long count,
+ struct page **pages);
+#endif
+
+static inline void xenmem_reservation_va_mapping_update(unsigned
long count,
+ struct page **pages,
+ xen_pfn_t *frames)
+{
+#ifdef CONFIG_XEN_HAVE_PVMMU
+ if (!xen_feature(XENFEAT_auto_translated_physmap))
+ __xenmem_reservation_va_mapping_update(count, pages,
frames);
+#endif
+}
+
+static inline void xenmem_reservation_va_mapping_reset(unsigned
long count,
+ struct page **pages)
+{
+#ifdef CONFIG_XEN_HAVE_PVMMU
+ if (!xen_feature(XENFEAT_auto_translated_physmap))
+ __xenmem_reservation_va_mapping_reset(count, pages);
+#endif
+}
+
+int xenmem_reservation_increase(int count, xen_pfn_t *frames);
+
+int xenmem_reservation_decrease(int count, xen_pfn_t *frames);
+
+#endif
[1] https://elixir.bootlin.com/linux/v4.17.1/ident/clear_highpage
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
On 12/06/18 14:20, Heiko Stuebner wrote:
> From: Sandy Huang
>
> The vop irq is shared between vop and iommu and irq probing in the
> iommu driver moved to the probe function recently. This can in some
> cases lead to a stall if the irq is triggered while the vop driver
> still has it disabled, but the vop irq handler gets called.
>
> But there is no real need to disable the irq, as the vop can simply
> also track its enabled state and ignore irqs in that case.
> For this we can simply check the power-domain state of the vop,
> similar to how the iommu driver does it.
>
> So remove the enable/disable handling and add appropriate condition
> to the irq handler.
>
> changes in v2:
> - move to just check the power-domain state
> - add clock handling
> changes in v3:
> - clarify comment to speak of runtime-pm not power-domain
> changes in v4:
> - address Marc's comments (clk-enable WARN_ON and style improvement)
>
> Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sandy Huang
> Signed-off-by: Heiko Stuebner
> Tested-by: Ezequiel Garcia
Reviewed-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
Quoting Rob Herring (2018-06-13 08:03:53) > On Wed, Jun 13, 2018 at 5:08 AM, Sandeep Panda wrote: > > +Optional properties: > > +- interrupts: Specifier for the SN65DSI86 interrupt line. > > + > > +- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing > > + > > +- gpio-controller: Marks the device has a GPIO controller. > > +- #gpio-cells: Should be two. The first cell is the pin number and > > + the second cell is used to specify flags. > > + See ../../gpio/gpio.txt for more information. > > +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of > > + the cell formats. > > + > > +- clock-names: should be "refclk" > > +- clocks: Specification for input reference clock. The reference > > + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. > > + > > +- data-lanes: Specification to describe the logical to physical lane > > + mapping scheme. See ../../media/video-interface.txt for more > > + information. > > +- lane-polarities: Specification to describe the polarity of physical > > lanes. > > + See ../../media/video-interface.txt for more information. > > You are still defining the properties here. All you need is: > > data-lanes: See ../../media/video-interface.txt > > Perhaps you need to say should be 4 lanes, but OTOH everything tends > to be 4 lanes. > Maybe also indicate what logical to physical data lanes are being remapped by saying something to the effect of "logical to physical DSI lane mapping scheme". ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
Hello,
sorry for my ignorance.
I don't know the right patch workflow in the case of "revert commit".
When I fix this bug, should I have to re-submit the previous patch
entire plus bug-fix?
Or do I have to submit patch with bug-fix only?
Thanks in advance to everybody
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
Il 13/06/2018 10:16, Paul Kocialkowski ha scritto:
This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70.
The offending commit triggers a run-time fault when accessing the panel
element of the sun4i_tcon structure when no such panel is attached.
It was apparently assumed in said commit that a panel is always used with
the TCON. Although it is often the case, this is not always true.
For instance a bridge might be used instead of a panel.
This issue was discovered using an A13-OLinuXino, that uses the TCON
in RGB mode for a simple DAC-based VGA bridge.
Cc: sta...@vger.kernel.org
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c3d92d537240..8045871335b5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
@@ -350,9 +349,6 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon *tcon,
static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
const struct drm_display_mode *mode)
{
- struct drm_panel *panel = tcon->panel;
- struct drm_connector *connector = panel->connector;
- struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -410,27 +406,6 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
- /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
- if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
- clk_set_phase(tcon->dclk, 240);
-
- if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
- clk_set_phase(tcon->dclk, 0);
-
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
val);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/4] drm/bridge: add support for sn65dsi86 bridge driver
On 2018-06-06 04:29, Sean Paul wrote: On Tue, Jun 05, 2018 at 11:10:15AM +0530, Sandeep Panda wrote: Add support for TI's sn65dsi86 dsi2edp bridge chip. The chip converts DSI transmitted signal to eDP signal, which is fed to the connected eDP panel. This chip can be controlled via either i2c interface or dsi interface. Currently in driver all the control registers are being accessed through i2c interface only. Also as of now HPD support has not been added to bridge chip driver. Changes in v1: - Split the dt-bindings and the driver support into separate patches (Andrzej Hajda). - Use of gpiod APIs to parse and configure gpios instead of obsolete ones (Andrzej Hajda). - Use macros to define the register offsets (Andrzej Hajda). Changes in v2: - Separate out edp panel specific HW resource handling from bridge driver and create a separate edp panel drivers to handle panel specific mode information and HW resources (Sean Paul). - Replace pr_* APIs to DRM_* APIs to log error or debug information (Sean Paul). - Remove some of the unnecessary structure/variable from driver (Sean Paul). - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge" (Sean Paul / Rob Herring). - Remove most of the hard-coding and modified the bridge init sequence based on current mode (Sean Paul). - Remove the existing function to retrieve the EDID data and implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul). - Remove the dummy irq handler implementation, will add back the proper irq handling later (Sean Paul). - Capture the required enable gpios in a single array based on dt entry instead of having individual descriptor for each gpio (Sean Paul). Changes in v3: - Remove usage of irq_gpio and replace it as "interrupts" property (Rob Herring). - Remove the unnecessary header file inclusions (Sean Paul). - Rearrange the header files in alphabetical order (Sean Paul). - Use regmap interface to perform i2c transactions. - Update Copyright/License field and address other review comments (Jordan Crouse). Changes in v4: - Update License/Copyright (Sean Paul). - Add Kconfig and Makefile changes (Sean Paul). - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios will be handled by i2c master. - Update required supplies names. - Remove unnecessary goto statements (Sean Paul). - Add mutex lock to power_ctrl API to avoid race conditions (Sean Paul). - Add support to parse reference clk frequency from dt(optional). - Update the bridge chip enable/disable sequence. Changes in v5: - Fixed Kbuild test service reported warnings. Changes in v6: - Use PM runtime based ref-counting instead of local ref_count mechanism (Stephen Boyd). - Clean up some debug logs and indentations (Sean Paul). - Simplify dp rate calculation (Sean Paul). - Add support to configure refclk based on input REFCLK pin or DACP/N pin (Stephen Boyd). Changes in v7: - Use static supply entries instead of dynamic allocation (Andrzej Hajda). - Defer bridge driver probe if panel is not probed (Andrzej Hajda). - Update of_graph APIs for correct node reference management. (Andrzej Hajda). - Remove local display_mode object (Andrzej Hajda). - Remove version id check function from driver. Changes in v8: - Move dsi register/attach function to bridge driver probe (Andrzej Hajda). - Introduce a new helper function to write 16bit words into consecutive registers (Andrzej Hajda). - Remove unnecessary macros (Andrzej Hajda). Signed-off-by: Sandeep Panda --- drivers/gpu/drm/bridge/Kconfig| 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 666 ++ 3 files changed, 676 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 3b99d5a..8153150 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -108,6 +108,15 @@ config DRM_TI_TFP410 ---help--- Texas Instruments TFP410 DVI/HDMI Transmitter driver +config DRM_TI_SN65DSI86 + tristate "TI SN65DSI86 DSI to eDP bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + ---help--- + Texas Instruments SN65DSI86 DSI to eDP Bridge driver + source "drivers/gpu/drm/bridge/analogix/Kconfig" source "drivers/gpu/drm/bridge/adv7511/Kconfig" diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 373eb28..3711be8 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -12,4 +12,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o +obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o SN65DSI86
Re: [PATCH v2] drm/bridge/sii8620: simplify hardware reset procedure
Hi Andrzej,
On 06/08/2018 08:04 AM, Andrzej Hajda wrote:
> There is no need to flip reset pin twice. Also delays can be changed to
> values present in vendor's code.
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Maciej Purski
> ---
> Hi,
>
> This is v2 of forgotten patch, awaiting reviewers, any volunteers.
> Also "drm/bridge/sii8620: fix loops in EDID fetch logic" waits for reviewers.
>
> In this version I have completely removed reset function, and moved its body
> to sii8620_hw_on.
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/bridge/sil-sii8620.c | 23 ++-
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 7ab36042a822..d1e780fba4b6 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -971,8 +971,17 @@ static int sii8620_hw_on(struct sii8620 *ctx)
> ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> if (ret)
> return ret;
> +
> usleep_range(1, 2);
> - return clk_prepare_enable(ctx->clk_xtal);
> + ret = clk_prepare_enable(ctx->clk_xtal);
> + if (ret)
> + return ret;
> +
> + msleep(100);
> + gpiod_set_value(ctx->gpio_reset, 0);
> + msleep(100);
> +
> + return 0;
> }
>
> static int sii8620_hw_off(struct sii8620 *ctx)
> @@ -982,17 +991,6 @@ static int sii8620_hw_off(struct sii8620 *ctx)
> return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> }
>
> -static void sii8620_hw_reset(struct sii8620 *ctx)
> -{
> - usleep_range(1, 2);
> - gpiod_set_value(ctx->gpio_reset, 0);
> - usleep_range(5000, 2);
> - gpiod_set_value(ctx->gpio_reset, 1);
> - usleep_range(1, 2);
> - gpiod_set_value(ctx->gpio_reset, 0);
> - msleep(300);
> -}
> -
> static void sii8620_cbus_reset(struct sii8620 *ctx)
> {
> sii8620_write(ctx, REG_PWD_SRST, BIT_PWD_SRST_CBUS_RST
> @@ -2112,7 +2110,6 @@ static void sii8620_cable_in(struct sii8620 *ctx)
> dev_err(dev, "Error powering on, %d.\n", ret);
> return;
> }
> - sii8620_hw_reset(ctx);
>
> sii8620_read_buf(ctx, REG_VND_IDL, ver, ARRAY_SIZE(ver));
> ret = sii8620_clear_error(ctx);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 18 May 2018 at 16:17, Sinan Kaya wrote:
> A host bridge is allowed to remap BAR addresses using _TRA attribute in
> _CRS windows.
>
> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
> (bus address [0x0010-0x1fff])
> pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
>
> When a VGA device is behind such a host bridge and the resource is
> translated efifb driver is trying to do ioremap against bus address
> rather than the resource address and is failing to probe.
>
> efifb: probing for efifb
> efifb: cannot reserve video memory at 0x1e00
> efifb: framebuffer at 0x1e00, using 1920k, total 1875k
> efifb: mode is 800x600x32, linelength=3200, pages=1
> efifb: scrolling: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
>
> Use the host bridge offset information to convert bus address to
> resource address in the fixup.
>
> Signed-off-by: Sinan Kaya
Reviewed-by: Ard Biesheuvel
Bartlomiej, could you please take these via the fbdev tree for v4.19?
Peter already gave his ack but Sinan dropped it (presumably because of
the split in v2)
Sinan, does this need to go to -stable? I.e., has it ever worked before?
> ---
> drivers/video/fbdev/efifb.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 6daac8d..429cc85 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -431,6 +431,7 @@ static void efifb_fixup_resources(struct pci_dev *dev)
> .end = screen_info.lfb_base + screen_info.lfb_size - 1,
> .flags = IORESOURCE_MEM,
> };
> + struct pci_bus_region region;
> int i;
>
> if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> @@ -442,6 +443,10 @@ static void efifb_fixup_resources(struct pci_dev *dev)
> if (!screen_res.start)
> return;
>
> + region.start = screen_res.start;
> + region.end = screen_res.end;
> + pcibios_bus_to_resource(dev->bus, &screen_res, ®ion);
> +
> for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
> struct resource *res = &dev->resource[i];
>
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] ARM: dts: Modernize the Vexpress PL111 integration
Hi Linus,
I was planning to apply this and observed few things.
On 28/05/18 13:26, Linus Walleij wrote:
> The Versatile Express was submitted with the actual display
> bridges unconnected (but defined in the device tree) and
> mock "panels" encoded in the device tree node of the PL111
> controller.
>
> This doesn't even remotely describe the actual Versatile
> Express hardware. Exploit the SiI9022 bridge by connecting
> the PL111 pads to it, making it use EDID or fallback values
> to drive the monitor.
>
> The also has to use the reserved memory through the
> CMA pool rather than by open coding a memory region and
> remapping it explicitly in the driver. To achieve this,
> a reserved-memory node must exist in the root of the
> device tree, so we need to pull that out of the
> motherboard .dtsi include files, and push it into each
> top-level device tree instead.
>
> We do the same manouver for all the Versatile Express
> boards, taking into account the different location of the
> video RAM depending on which chip select is used on
> each platform.
>
> This plays nicely with the new PL111 DRM driver and
> follows the standard ways of assigning bridges and
> memory pools for graphics.
>
> Cc: Sudeep Holla
> Cc: Lorenzo Pieralisi
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Robin Murphy
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v1->v2:
> - Fix up the memory address for the -rs1 tiles to 0x1800
> - Drop a bunch of extraneous reg props from the DVI adapter
> ---
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 44 ++
> arch/arm/boot/dts/vexpress-v2m.dtsi | 45 ++-
> arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 14 ++
> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 14 ++
> arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 14 ++
> arch/arm/boot/dts/vexpress-v2p-ca9.dts| 41 +++--
> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts| 14 ++
> .../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 +++
> 8 files changed, 105 insertions(+), 118 deletions(-)
>
> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> index 7b8ff5b3b912..69f6a9436325 100644
> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> @@ -43,11 +43,6 @@
> bank-width = <4>;
> };
>
> - v2m_video_ram: vram@2, {
> - compatible = "arm,vexpress-vram";
> - reg = <2 0x 0x0080>;
> - };
> -
> ethernet@2,0200 {
> compatible = "smsc,lan9118", "smsc,lan9115";
> reg = <2 0x0200 0x1>;
> @@ -224,6 +219,14 @@
> dvi-transmitter@39 {
> compatible = "sil,sii9022-tpi",
> "sil,sii9022";
> reg = <0x39>;
> +
> + ports {
> + port@0 {
May need reg=<0> here, otherwise DTC might complain ?
[...]
> diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi
> b/arch/arm/boot/dts/vexpress-v2m.dtsi
> index 9cd5e146abd5..067d84bc61c0 100644
> --- a/arch/arm/boot/dts/vexpress-v2m.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
> @@ -43,11 +43,6 @@
> bank-width = <4>;
> };
>
> - v2m_video_ram: vram@3, {
> - compatible = "arm,vexpress-vram";
> - reg = <3 0x 0x0080>;
> - };
> -
> ethernet@3,0200 {
> compatible = "smsc,lan9118", "smsc,lan9115";
> reg = <3 0x0200 0x1>;
> @@ -224,6 +219,14 @@
> dvi-transmitter@39 {
> compatible = "sil,sii9022-tpi",
> "sil,sii9022";
> reg = <0x39>;
> +
> + ports {
> + port@0 {
Ditto
> + dvi_bridge_in:
> endpoint {
> +
> remote-endpoint = <&clcd_pads>;
> + };
> + };
> + };
> };
>
> dvi-transmitter@60 {
[...]
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> index 39714
Re: [PATCH v3 8/9] xen/gntdev: Implement dma-buf export functionality
On 06/13/2018 07:57 AM, Oleksandr Andrushchenko wrote:
> On 06/13/2018 05:58 AM, Boris Ostrovsky wrote:
>>
>>
>> On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
>>>
>>> +
>>> +static struct gntdev_dmabuf *
>>> +dmabuf_exp_wait_obj_get_by_fd(struct gntdev_dmabuf_priv *priv, int fd)
>>
>>
>> The name of this routine implies (to me) that we are getting a wait
>> object but IIUIC we are getting a gntdev_dmabuf that we are going to
>> later associate with a wait object.
>>
> How about dmabuf_exp_wait_obj_get_dmabuf_by_fd?
> I would like to keep function prefixes, e.g. dmabuf_exp_wait_obj_
> just to show to which functionality a routine belongs.
That's too long IMO. If you really want to keep the prefix then let's
keep this the way it is. Maybe it's just me who read it that way.
>>
>>>
>>> +#ifdef CONFIG_XEN_GNTDEV_DMABUF
>>> +void gntdev_remove_map(struct gntdev_priv *priv, struct
>>> gntdev_grant_map *map)
>>> +{
>>> + mutex_lock(&priv->lock);
>>> + list_del(&map->next);
>>> + gntdev_put_map(NULL /* already removed */, map);
>>
>>
>> Why not pass call gntdev_put_map(priv, map) and then not have this
>> routine at all?
>>
> Well, I wish I could, but the main difference when calling
> gntdev_put_map(priv, map)
> with priv != NULL and my code is that:
>
> void gntdev_put_map(struct gntdev_priv *priv, struct gntdev_grant_map
> *map)
> {
> [...]
> if (populate_freeable_maps && priv) {
> ^
> mutex_lock(&priv->lock);
> list_del(&map->next);
> mutex_unlock(&priv->lock);
> }
> [...]
> }
>
> and
>
> #define populate_freeable_maps use_ptemod
> ^^
> which means the map will never be removed from the list in my case
> because use_ptemod == false for dma-buf.
> This is why I do that by hand, e.g. remove the item from the list
> and then pass NULL for priv.
>
> Also, I will remove gntdev_remove_map as I can now access
> priv->lock and gntdev_put_map directly form gntdev-dmabuf.c
Yes, that's a good idea.
>
>> I really dislike the fact that we are taking a lock here that
>> gntdev_put_map() takes as well, although not with NULL argument. (And
>> yes, I see that gntdev_release() does it too.)
>>
> This can be re-factored later I guess?
OK.
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 1/2] efi/fb: Simplify fixup code to prefer struct resource
On 18 May 2018 at 16:17, Sinan Kaya wrote:
> Get rid of base and size variables in favor of a struct resource.
> The conditional for checking window can be replaced with
> resource_contains().
>
> Signed-off-by: Sinan Kaya
Reviewed-by: Ard Biesheuvel
> ---
> drivers/video/fbdev/efifb.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 46a4484..6daac8d 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -426,17 +426,20 @@ static void record_efifb_bar_resource(struct pci_dev
> *dev, int idx, u64 offset)
>
> static void efifb_fixup_resources(struct pci_dev *dev)
> {
> - u64 base = screen_info.lfb_base;
> - u64 size = screen_info.lfb_size;
> + struct resource screen_res = {
> + .start = screen_info.lfb_base,
> + .end = screen_info.lfb_base + screen_info.lfb_size - 1,
> + .flags = IORESOURCE_MEM,
> + };
> int i;
>
> if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> return;
>
> if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
> - base |= (u64)screen_info.ext_lfb_base << 32;
> + screen_res.start |= (u64)screen_info.ext_lfb_base << 32;
>
> - if (!base)
> + if (!screen_res.start)
> return;
>
> for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
> @@ -445,8 +448,10 @@ static void efifb_fixup_resources(struct pci_dev *dev)
> if (!(res->flags & IORESOURCE_MEM))
> continue;
>
> - if (res->start <= base && res->end >= base + size - 1) {
> - record_efifb_bar_resource(dev, i, base - res->start);
> + if (resource_contains(res, &screen_res)) {
> + u64 win_offset = screen_res.start - res->start;
> +
> + record_efifb_bar_resource(dev, i, win_offset);
> break;
> }
> }
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 13 June 2018 at 16:22, Sinan Kaya wrote: > Hi Ard, > > On 5/18/2018 10:17 AM, Sinan Kaya wrote: >> A host bridge is allowed to remap BAR addresses using _TRA attribute in >> _CRS windows. >> >> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] >> (bus address [0x0010-0x1fff]) >> pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff] >> >> When a VGA device is behind such a host bridge and the resource is >> translated efifb driver is trying to do ioremap against bus address >> rather than the resource address and is failing to probe. >> >> efifb: probing for efifb >> efifb: cannot reserve video memory at 0x1e00 >> efifb: framebuffer at 0x1e00, using 1920k, total 1875k >> efifb: mode is 800x600x32, linelength=3200, pages=1 >> efifb: scrolling: redraw >> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 >> >> Use the host bridge offset information to convert bus address to >> resource address in the fixup. >> >> Signed-off-by: Sinan Kaya >> --- > > I didn't see any messages about these getting picked up for 4.18. > > Are they queued on your own branch? > No, you never cc'ed me on them until now. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/bridge/sii8620: fix loops in EDID fetch logic
Hi Andrzej,
On 01/15/2018 06:33 PM, Andrzej Hajda wrote:
> Function should constantly check if cable is connected and finish
> in finite time.
>
> Signed-off-by: Andrzej Hajda
Looks fine to me.
Reviewed-by: Maciej Purski
> ---
> drivers/gpu/drm/bridge/sil-sii8620.c | 31 ---
> 1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 7c46847fef18..f65e14836c0e 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -801,6 +801,7 @@ static void sii8620_burst_rx_all(struct sii8620 *ctx)
> static void sii8620_fetch_edid(struct sii8620 *ctx)
> {
> u8 lm_ddc, ddc_cmd, int3, cbus;
> + unsigned long timeout;
> int fetched, i;
> int edid_len = EDID_LENGTH;
> u8 *edid;
> @@ -850,23 +851,31 @@ static void sii8620_fetch_edid(struct sii8620 *ctx)
> REG_DDC_CMD, ddc_cmd | VAL_DDC_CMD_ENH_DDC_READ_NO_ACK
> );
>
> - do {
> - int3 = sii8620_readb(ctx, REG_INTR3);
> + int3 = 0;
> + timeout = jiffies + msecs_to_jiffies(200);
> + for (;;) {
> cbus = sii8620_readb(ctx, REG_CBUS_STATUS);
> -
> - if (int3 & BIT_DDC_CMD_DONE)
> - break;
> -
> - if (!(cbus & BIT_CBUS_STATUS_CBUS_CONNECTED)) {
> + if (~cbus & BIT_CBUS_STATUS_CBUS_CONNECTED) {
> + kfree(edid);
> + edid = NULL;
> + goto end;
> + }
> + if (int3 & BIT_DDC_CMD_DONE) {
> + if (sii8620_readb(ctx, REG_DDC_DOUT_CNT)
> + >= FETCH_SIZE)
> + break;
> + } else {
> + int3 = sii8620_readb(ctx, REG_INTR3);
> + }
> + if (time_is_before_jiffies(timeout)) {
> + ctx->error = -ETIMEDOUT;
> + dev_err(ctx->dev, "timeout during EDID read\n");
> kfree(edid);
> edid = NULL;
> goto end;
> }
> - } while (1);
> -
> - sii8620_readb(ctx, REG_DDC_STATUS);
> - while (sii8620_readb(ctx, REG_DDC_DOUT_CNT) < FETCH_SIZE)
> usleep_range(10, 20);
> + }
>
> sii8620_read_buf(ctx, REG_DDC_DATA, edid + fetched, FETCH_SIZE);
> if (fetched + FETCH_SIZE == EDID_LENGTH) {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality
On 06/13/2018 05:04 AM, Oleksandr Andrushchenko wrote:
> On 06/13/2018 06:14 AM, Boris Ostrovsky wrote:
>>
>>
>> On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:
>>
>>> int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32
>>> fd)
>>> {
>>> - return -EINVAL;
>>> + struct gntdev_dmabuf *gntdev_dmabuf;
>>> + struct dma_buf_attachment *attach;
>>> + struct dma_buf *dma_buf;
>>> +
>>> + gntdev_dmabuf = dmabuf_imp_find_unlink(priv, fd);
>>> + if (IS_ERR(gntdev_dmabuf))
>>> + return PTR_ERR(gntdev_dmabuf);
>>> +
>>> + pr_debug("Releasing DMA buffer with fd %d\n", fd);
>>> +
>>> + attach = gntdev_dmabuf->u.imp.attach;
>>> +
>>> + if (gntdev_dmabuf->u.imp.sgt)
>>> + dma_buf_unmap_attachment(attach, gntdev_dmabuf->u.imp.sgt,
>>> + DMA_BIDIRECTIONAL);
>>> + dma_buf = attach->dmabuf;
>>> + dma_buf_detach(attach->dmabuf, attach);
>>> + dma_buf_put(dma_buf);
>>> +
>>> + dmabuf_imp_end_foreign_access(gntdev_dmabuf->u.imp.refs,
>>> + gntdev_dmabuf->nr_pages);
>>
>>
>>
>> Should you first end foreign access, before doing anything?
>>
> I am rolling back in reverse order here, so I think we first need
> to finish local activities with the buffer and then end foreign
> access.
Looking at gntdev_dmabuf_imp_to_refs(), the order is
dmabuf_imp_alloc_storage()
dma_buf_attach()
dma_buf_map_attachment()
dmabuf_imp_grant_foreign_access()
Or was I looking at wrong place?
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality
On 06/14/2018 01:03 AM, Boris Ostrovsky wrote:
On 06/13/2018 05:04 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 06:14 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:
int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32
fd)
{
- return -EINVAL;
+ struct gntdev_dmabuf *gntdev_dmabuf;
+ struct dma_buf_attachment *attach;
+ struct dma_buf *dma_buf;
+
+ gntdev_dmabuf = dmabuf_imp_find_unlink(priv, fd);
+ if (IS_ERR(gntdev_dmabuf))
+ return PTR_ERR(gntdev_dmabuf);
+
+ pr_debug("Releasing DMA buffer with fd %d\n", fd);
+
+ attach = gntdev_dmabuf->u.imp.attach;
+
+ if (gntdev_dmabuf->u.imp.sgt)
+ dma_buf_unmap_attachment(attach, gntdev_dmabuf->u.imp.sgt,
+ DMA_BIDIRECTIONAL);
+ dma_buf = attach->dmabuf;
+ dma_buf_detach(attach->dmabuf, attach);
+ dma_buf_put(dma_buf);
+
+ dmabuf_imp_end_foreign_access(gntdev_dmabuf->u.imp.refs,
+ gntdev_dmabuf->nr_pages);
Should you first end foreign access, before doing anything?
I am rolling back in reverse order here, so I think we first need
to finish local activities with the buffer and then end foreign
access.
Looking at gntdev_dmabuf_imp_to_refs(), the order is
dmabuf_imp_alloc_storage()
dma_buf_attach()
dma_buf_map_attachment()
dmabuf_imp_grant_foreign_access()
Or was I looking at wrong place?
Agree, will move as you suggest
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with existing
bindings (Andrzej Hajda).
- Add missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Remove edp panel specific dt-binding entries. Only keep bridge
specific entries (Sean Paul).
- Remove custom-modes dt entry since its usage is removed from driver also
(Sean Paul).
- Remove is-pluggable dt entry since this will not be needed anymore (Sean
Paul).
Changes in v3:
- Remove irq-gpio dt entry and instead populate is an interrupt
property (Rob Herring).
Changes in v4:
- Add link to bridge chip datasheet (Stephen Boyd)
- Add vpll and vcc regulator supply bindings (Stephen Boyd)
- Add ref clk optional dt binding (Stephen Boyd)
- Add gpio-controller optional dt binding (Stephen Boyd)
Changes in v5:
- Use clock property to specify the input refclk (Stephen Boyd).
- Update gpio cell and pwm cell numbers (Stephen Boyd).
Changes in v6:
- Add property to mention the lane mapping scheme and polarity inversion
(Stephen Boyd).
Changes in v7:
- Detail description of lane mapping scheme dt property (Andrzej
Hajda/ Rob Herring).
- Removed HDP gpio binding, since the bridge uses IRQ signal to
determine HPD, and IRQ property is already documented in binding.
Changes in v8:
- Removed unnecessary explanation of lane mapping and polarity dt
property, since these are already explained in media/video-interface
dt binidng (Rob Herring).
Signed-off-by: Sandeep Panda
---
.../bindings/display/bridge/ti,sn65dsi86.txt | 90 ++
1 file changed, 90 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
new file mode 100644
index 000..601454c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -0,0 +1,90 @@
+SN65DSI86 DSI to eDP bridge chip
+
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
+
+Required properties:
+- compatible: Must be "ti,sn65dsi86"
+- reg: i2c address of the chip, 0x2d as per datasheet
+- enable-gpios: OF device-tree gpio specification for bridge_en pin (active
high)
+
+- vccio-supply: A 1.8V supply that powers up the digital IOs.
+- vpll-supply: A 1.8V supply that powers up the displayport PLL.
+- vcca-supply: A 1.2V supply that powers up the analog circuits.
+- vcc-supply: A 1.2V supply that powers up the digital core.
+
+Optional properties:
+- interrupts: Specifier for the SN65DSI86 interrupt line.
+
+- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing
+
+- gpio-controller: Marks the device has a GPIO controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify flags.
+ See ../../gpio/gpio.txt for more information.
+- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
+ the cell formats.
+
+- clock-names: should be "refclk"
+- clocks: Specification for input reference clock. The reference
+ clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
+
+- data-lanes: Specification to describe the logical to physical lane
+ mapping scheme. See ../../media/video-interface.txt for more
+ information.
+- lane-polarities: Specification to describe the polarity of physical lanes.
+ See ../../media/video-interface.txt for more information.
+
+Required nodes:
+This device has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for DSI input
+- Video port 1 for eDP output
+
+Example
+---
+
+edp-bridge@2d {
+ compatible = "ti,sn65dsi86";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2d>;
+
+ enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+
+ vccio-supply = <&pm8916_l17>;
+ vcca-supply = <&pm8916_l6>;
+ vpll-supply = <&pm8916_l17>;
+ vcc-supply = <&pm8916_l6>;
+
+ clock-names = "refclk";
+ clocks = <&input_refclk>;
+
+ data-lanes = <2 1 3 0>;
+ lane-polarities = <0 1 0 1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ edp_bridge_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+
+ port@1 {
+
[Bug 81678] X crashes on start (integrated 7640G + discrete 7500M/7600M)
https://bugs.freedesktop.org/show_bug.cgi?id=81678 Michel Dänzer changed: What|Removed |Added Product|DRI |xorg QA Contact||xorg-t...@lists.x.org Component|DRM/Radeon |Lib/pciaccess Assignee|dri-devel@lists.freedesktop |xorg-t...@lists.x.org |.org| -- 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] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
Hi, On Wed, 2018-06-13 at 23:52 +0200, Giulio Benetti wrote: > Hello, > > sorry for my ignorance. > I don't know the right patch workflow in the case of "revert commit". > When I fix this bug, should I have to re-submit the previous patch > entire plus bug-fix? > > Or do I have to submit patch with bug-fix only? Yes, that is usually how it works! The revert patch will be picked up by the maintainer (Maxime), integrated in his tree and eventually merged into Linus' tree (along with stable trees). Fixup patches for this will need to take into account the revert patch, so it becomes equivalent to submitting the same patch with that issue resolved. > Thanks in advance to everybody Cheers ! -- Paul Kocialkowski, Bootlin (formerly Free Electrons) Embedded Linux and kernel engineering https://bootlin.com signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] locking, drm: Fix ww mutex naming / algorithm inconsistency
This is a small fallout from a work to allow batching WW mutex locks and unlocks. Our Wound-Wait mutexes actually don't use the Wound-Wait algorithm but the Wait-Die algorithm. One could perhaps rename those mutexes tree-wide to "Wait-Die mutexes" or "Deadlock Avoidance mutexes". Another approach suggested here is to implement also the "Wound-Wait" algorithm as a per-WW-class choice, as it has advantages in some cases. See for example http://www.mathcs.emory.edu/~cheung/Courses/554/Syllabus/8-recv+serial/deadlock-compare.html Now Wound-Wait is a preemptive algorithm, and the preemption is implemented using a lazy scheme: If a wounded transaction is about to go to sleep on a contended WW mutex, we return -EDEADLK. That is sufficient for deadlock prevention. Since with WW mutexes we also require the aborted transaction to sleep waiting to lock the WW mutex it was aborted on, this choice also provides a suitable WW mutex to sleep on. If we were to return -EDEADLK on the first WW mutex lock after the transaction was wounded whether the WW mutex was contended or not, the transaction might frequently be restarted without a wait, which is far from optimal. Note also that with the lazy preemption scheme, contrary to Wait-Die there will be no rollbacks on lock contention of locks held by a transaction that has completed its locking sequence. The modeset locks are then changed from Wait-Die to Wound-Wait since the typical locking pattern of those locks very well matches the criterion for a substantial reduction in the number of rollbacks. For reservation objects, the benefit is more unclear at this point and they remain using Wait-Die. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie Cc: Davidlohr Bueso Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: Thomas Gleixner Cc: Kate Stewart Cc: Philippe Ombredanne Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org v2: Updated DEFINE_WW_CLASS() API, minor code- and comment fixes as detailed in each patch. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm: Change deadlock-avoidance algorithm for the modeset locks.
For modeset locks we don't expect a high number of contending transactions so change algorithm from Wait-Die to Wound-Wait. Signed-off-by: Thomas Hellstrom --- v2: Update to API change. --- drivers/gpu/drm/drm_modeset_lock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index ff00a814f617..8a5100685875 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -70,7 +70,7 @@ * lists and lookup data structures. */ -static DEFINE_WW_CLASS_WDIE(crtc_ww_class); +static DEFINE_WW_CLASS(crtc_ww_class); /** * drm_modeset_lock_all - take all modeset locks -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
The current Wound-Wait mutex algorithm is actually not Wound-Wait but Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait is, contrary to Wait-Die a preemptive algorithm and is known to generate fewer backoffs. Testing reveals that this is true if the number of simultaneous contending transactions is small. As the number of simultaneous contending threads increases, Wait-Wound becomes inferior to Wait-Die in terms of elapsed time. Possibly due to the larger number of held locks of sleeping transactions. Update documentation and callers. Timings using git://people.freedesktop.org/~thomash/ww_mutex_test tag patch-18-06-14 Each thread runs 10 batches of lock / unlock 800 ww mutexes randomly chosen out of 10. Four core Intel x86_64: Algorithm#threads Rollbacks time Wound-Wait 4 ~100 ~17s. Wait-Die 4 ~15~19s. Wound-Wait 16 ~36~109s. Wait-Die 16 ~45~82s. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie Cc: Davidlohr Bueso Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: Thomas Gleixner Cc: Kate Stewart Cc: Philippe Ombredanne Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Thomas Hellstrom --- v2: * Update API according to review comment by Greg Kroah-Hartman. * Address review comments by Peter Zijlstra: - Avoid _Bool in composites - Fix typo - Use __mutex_owner() where applicable - Rely on built-in barriers for the main loop exit condition, struct ww_acquire_ctx::wounded. Update code comments. - Explain unlocked use of list_empty(). --- Documentation/locking/ww-mutex-design.txt | 54 drivers/dma-buf/reservation.c | 2 +- drivers/gpu/drm/drm_modeset_lock.c| 2 +- include/linux/ww_mutex.h | 19 -- kernel/locking/locktorture.c | 2 +- kernel/locking/mutex.c| 103 +++--- kernel/locking/test-ww_mutex.c| 2 +- lib/locking-selftest.c| 2 +- 8 files changed, 156 insertions(+), 30 deletions(-) diff --git a/Documentation/locking/ww-mutex-design.txt b/Documentation/locking/ww-mutex-design.txt index 34c3a1b50b9a..b9597def9581 100644 --- a/Documentation/locking/ww-mutex-design.txt +++ b/Documentation/locking/ww-mutex-design.txt @@ -1,4 +1,4 @@ -Wait/Wound Deadlock-Proof Mutex Design +Wound/Wait Deadlock-Proof Mutex Design == Please read mutex-design.txt first, as it applies to wait/wound mutexes too. @@ -32,10 +32,23 @@ the oldest task) wins, and the one with the higher reservation id (i.e. the younger task) unlocks all of the buffers that it has already locked, and then tries again. -In the RDBMS literature this deadlock handling approach is called wait/wound: -The older tasks waits until it can acquire the contended lock. The younger tasks -needs to back off and drop all the locks it is currently holding, i.e. the -younger task is wounded. +In the RDBMS literature, a reservation ticket is associated with a transaction. +and the deadlock handling approach is called Wait-Die. The name is based on +the actions of a locking thread when it encounters an already locked mutex. +If the transaction holding the lock is younger, the locking transaction waits. +If the transaction holding the lock is older, the locking transaction backs off +and dies. Hence Wait-Die. +There is also another algorithm called Wound-Wait: +If the transaction holding the lock is younger, the locking transaction +preempts the transaction holding the lock, requiring it to back off. It +Wounds the other transaction. +If the transaction holding the lock is older, it waits for the other +transaction. Hence Wound-Wait. +The two algorithms are both fair in that a transaction will eventually succeed. +However, the Wound-Wait algorithm is typically stated to generate fewer backoffs +compared to Wait-Die, but is, on the other hand, associated with more work than +Wait-Die when recovering from a backoff. Wound-Wait is also a preemptive +algorithm which requires a reliable way to preempt another transaction. Concepts @@ -47,10 +60,12 @@ Acquire context: To ensure eventual forward progress it is important the a task trying to acquire locks doesn't grab a new reservation id, but keeps the one it acquired when starting the lock acquisition. This ticket is stored in the acquire context. Furthermore the acquire context keeps track of debugging state -to catch w/w mutex interface abuse. +to catch w/w mutex interface abuse. An acquire context is representing a +transaction. W/w class: In contrast to normal mutexes the lock class needs to be explicit for -w/w mutexes, since it is required to initialize the acquire context. +w/w
[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 Christian König changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #19 from Christian König --- Ok then let's mark this as resolved for now. -- 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 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #22 from Christian König (christian.koe...@amd.com) --- Your debugging efforts are better than mine. Please provide the output of "sudo setpci -s 65:00.0 ECAP15.l ECAP15+4.l ECAP15+8.l" once before suspend and once after suspend without any changes (e.g. when the problem happens). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] ARM: dts: Modernize the Vexpress PL111 integration
On Wed, Jun 13, 2018 at 11:57:25AM +0100, Sudeep Holla wrote:
> Hi Linus,
>
> I was planning to apply this and observed few things.
>
> On 28/05/18 13:26, Linus Walleij wrote:
> > The Versatile Express was submitted with the actual display
> > bridges unconnected (but defined in the device tree) and
> > mock "panels" encoded in the device tree node of the PL111
> > controller.
> >
> > This doesn't even remotely describe the actual Versatile
> > Express hardware. Exploit the SiI9022 bridge by connecting
> > the PL111 pads to it, making it use EDID or fallback values
> > to drive the monitor.
> >
> > The also has to use the reserved memory through the
> > CMA pool rather than by open coding a memory region and
> > remapping it explicitly in the driver. To achieve this,
> > a reserved-memory node must exist in the root of the
> > device tree, so we need to pull that out of the
> > motherboard .dtsi include files, and push it into each
> > top-level device tree instead.
> >
> > We do the same manouver for all the Versatile Express
> > boards, taking into account the different location of the
> > video RAM depending on which chip select is used on
> > each platform.
> >
> > This plays nicely with the new PL111 DRM driver and
> > follows the standard ways of assigning bridges and
> > memory pools for graphics.
> >
> > Cc: Sudeep Holla
> > Cc: Lorenzo Pieralisi
> > Cc: Liviu Dudau
> > Cc: Mali DP Maintainers
> > Cc: Robin Murphy
> > Signed-off-by: Linus Walleij
> > ---
> > ChangeLog v1->v2:
> > - Fix up the memory address for the -rs1 tiles to 0x1800
> > - Drop a bunch of extraneous reg props from the DVI adapter
> > ---
> > arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 44 ++
> > arch/arm/boot/dts/vexpress-v2m.dtsi | 45 ++-
> > arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 14 ++
> > arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 14 ++
> > arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 14 ++
> > arch/arm/boot/dts/vexpress-v2p-ca9.dts| 41 +++--
> > arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts| 14 ++
> > .../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 +++
> > 8 files changed, 105 insertions(+), 118 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > index 7b8ff5b3b912..69f6a9436325 100644
> > --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > @@ -43,11 +43,6 @@
> > bank-width = <4>;
> > };
> >
> > - v2m_video_ram: vram@2, {
> > - compatible = "arm,vexpress-vram";
> > - reg = <2 0x 0x0080>;
> > - };
> > -
> > ethernet@2,0200 {
> > compatible = "smsc,lan9118", "smsc,lan9115";
> > reg = <2 0x0200 0x1>;
> > @@ -224,6 +219,14 @@
> > dvi-transmitter@39 {
> > compatible = "sil,sii9022-tpi",
> > "sil,sii9022";
> > reg = <0x39>;
> > +
> > + ports {
> > + port@0 {
>
>
> May need reg=<0> here, otherwise DTC might complain ?
> [...]
>
> > diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi
> > b/arch/arm/boot/dts/vexpress-v2m.dtsi
> > index 9cd5e146abd5..067d84bc61c0 100644
> > --- a/arch/arm/boot/dts/vexpress-v2m.dtsi
> > +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
> > @@ -43,11 +43,6 @@
> > bank-width = <4>;
> > };
> >
> > - v2m_video_ram: vram@3, {
> > - compatible = "arm,vexpress-vram";
> > - reg = <3 0x 0x0080>;
> > - };
> > -
> > ethernet@3,0200 {
> > compatible = "smsc,lan9118", "smsc,lan9115";
> > reg = <3 0x0200 0x1>;
> > @@ -224,6 +219,14 @@
> > dvi-transmitter@39 {
> > compatible = "sil,sii9022-tpi",
> > "sil,sii9022";
> > reg = <0x39>;
> > +
> > + ports {
> > + port@0 {
>
> Ditto
>
> > + dvi_bridge_in:
> > endpoint {
> > +
> > remote-endpoint = <&clcd_pads>;
> > + };
> > + };
> > + };
> >
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #23 from Alexander Mezin (mezin.alexan...@gmail.com) --- (In reply to Christian König from comment #22) > Your debugging efforts are better than mine. > > Please provide the output of "sudo setpci -s 65:00.0 ECAP15.l ECAP15+4.l > ECAP15+8.l" once before suspend and once after suspend without any changes > (e.g. when the problem happens). before suspend: 27010015 0003f000 0d20 after resume: 27010015 0003f000 0820 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #24 from Christian König (christian.koe...@amd.com) --- Created attachment 276547 --> https://bugzilla.kernel.org/attachment.cgi?id=276547&action=edit Possible fix In this case please try the attached patch and see if it helps. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199959] amdgpu, regression?: system freezes after resume
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #25 from Alexander Mezin (mezin.alexan...@gmail.com) --- Yes, it works dmesg: [ 34.330683] amdgpu :65:00.0: Test 0 from 8 to 13 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On Wed, Jun 13, 2018 at 04:05:43PM +0200, Thomas Hellstrom wrote:
> In short, with Wait-Die (before the patch) it's the process _taking_ the
> contended lock that backs off if necessary. No preemption required. With
> Wound-Wait, it's the process _holding_ the contended lock that gets wounded
> (preempted), and it needs to back off at its own discretion but no later
> than when it's going to sleep on another ww mutex. That point is where we
> intercept the preemption request. We're preempting the transaction rather
> than the process.
This:
Wait-die:
The newer transactions are killed when:
It (= the newer transaction) makes a reqeust for a lock being held
by an older transactions
Wound-wait:
The newer transactions are killed when:
An older transaction makes a request for a lock being held by the
newer transactions
Would make for an excellent comment somewhere. No talking about
preemption, although I think I know what you mean with it, that is not
how preemption is normally used.
In scheduling speak preemption is when we pick a runnable (but !running)
task to run instead of the current running task. In this case however,
our T2 is blocked on a lock acquisition (one owned by our T1) and T1 is
the only runnable task. Only when T1's progress is inhibited by T2 (T1
wants a lock held by T2) do we wound/wake T2.
In any case, I had a little look at the current ww_mutex code and ended
up with the below patch that hopefully clarifies things a little.
---
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index f44f658ae629..a20c04619b2a 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -244,6 +244,10 @@ void __sched mutex_lock(struct mutex *lock)
EXPORT_SYMBOL(mutex_lock);
#endif
+/*
+ * Associate the ww_mutex @ww with the context @ww_ctx under which we acquired
+ * it.
+ */
static __always_inline void
ww_mutex_lock_acquired(struct ww_mutex *ww, struct ww_acquire_ctx *ww_ctx)
{
@@ -282,26 +286,36 @@ ww_mutex_lock_acquired(struct ww_mutex *ww, struct
ww_acquire_ctx *ww_ctx)
DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class);
#endif
ww_ctx->acquired++;
+ lock->ctx = ctx;
}
+/*
+ * Determine if context @a is 'after' context @b. IOW, @a should be wounded in
+ * favour of @b.
+ */
static inline bool __sched
__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
{
- return a->stamp - b->stamp <= LONG_MAX &&
- (a->stamp != b->stamp || a > b);
+
+ return (signed long)(a->stamp - b->stamp) > 0;
}
/*
- * Wake up any waiters that may have to back off when the lock is held by the
- * given context.
+ * We just acquired @lock under @ww_ctx, if there are later contexts waiting
+ * behind us on the wait-list, wake them up so they can wound themselves.
*
- * Due to the invariants on the wait list, this can only affect the first
- * waiter with a context.
+ * See __ww_mutex_add_waiter() for the list-order construction; basically the
+ * list is ordered by stamp smallest (oldest) first, so if there is a later
+ * (younger) stamp on the list behind us, wake it so it can wound itself.
+ *
+ * Because __ww_mutex_add_waiter() and __ww_mutex_check_stamp() wake any
+ * but the earliest context, this can only affect the first waiter (with a
+ * context).
*
* The current task must not be on the wait list.
*/
static void __sched
-__ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx
*ww_ctx)
+__ww_mutex_wakeup_for_wound(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
{
struct mutex_waiter *cur;
@@ -322,16 +336,14 @@ __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct
ww_acquire_ctx *ww_ctx)
}
/*
- * After acquiring lock with fastpath or when we lost out in contested
- * slowpath, set ctx and wake up any waiters so they can recheck.
+ * After acquiring lock with fastpath, where we do not hold wait_lock, set ctx
+ * and wake up any waiters so they can recheck.
*/
static __always_inline void
ww_mutex_set_context_fastpath(struct ww_mutex *lock, struct ww_acquire_ctx
*ctx)
{
ww_mutex_lock_acquired(lock, ctx);
- lock->ctx = ctx;
-
/*
* The lock->ctx update should be visible on all cores before
* the atomic read is done, otherwise contended waiters might be
@@ -352,25 +364,10 @@ ww_mutex_set_context_fastpath(struct ww_mutex *lock,
struct ww_acquire_ctx *ctx)
* so they can see the new lock->ctx.
*/
spin_lock(&lock->base.wait_lock);
- __ww_mutex_wakeup_for_backoff(&lock->base, ctx);
+ __ww_mutex_wakeup_for_wound(&lock->base, ctx);
spin_unlock(&lock->base.wait_lock);
}
-/*
- * After acquiring lock in the slowpath set ctx.
- *
- * Unlike for the fast path, the caller ensures that waiters are woken up where
- * necessary.
- *
- * Callers must hold the mutex wait_lock.
- */
-static __always_inline void
-ww_mutex_set_context_slowpath(struct ww_mutex *lo
[GIT PULL] fbdev changes for v4.18
Hi Linus,
Please pull fbdev changes for v4.18. There is nothing really major
here, few small fixes, some cleanups and dead drivers removal (please
see the signed tag description for details).
Test merge revealed a small merge conflict, the resolution is trivial:
diff --cc drivers/video/fbdev/mmp/fb/mmpfb.c
index f27697e,292b3e4..ee212be
--- a/drivers/video/fbdev/mmp/fb/mmpfb.c
+++ b/drivers/video/fbdev/mmp/fb/mmpfb.c
@@@ -493,12 -493,11 +493,11 @@@ static int modes_setup(struct mmpfb_inf
return 0;
}
/* put videomode list to info structure */
- videomodes = kzalloc(sizeof(struct fb_videomode) * videomode_num,
- GFP_KERNEL);
+ videomodes = kcalloc(videomode_num, sizeof(struct fb_videomode),
+ GFP_KERNEL);
- if (!videomodes) {
- dev_err(fbi->dev, "can't malloc video modes\n");
+ if (!videomodes)
return -ENOMEM;
- }
+
for (i = 0; i < videomode_num; i++)
mmpmode_to_fbmode(&videomodes[i], &mmp_modes[i]);
fb_videomode_to_modelist(videomodes, videomode_num, &info->modelist);
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:
Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)
are available in the git repository at:
https://github.com/bzolnier/linux.git tags/fbdev-v4.18
for you to fetch changes up to 85ebd164de56c5146e0f65cebee7fcc4babe52e3:
fb_omap2: add gpiolib dependency (2018-06-08 18:08:12 +0200)
fbdev changes for v4.18:
- mark omapfb drivers as orphans in MAINTAINERS file (Tomi Valkeinen)
- add missing module license tags to omap/omapfb driver (Arnd Bergmann)
- add missing GPIOLIB dependendy to omap2/omapfb driver (Arnd Bergmann)
- convert savagefb, aty128fb & radeonfb drivers to use msleep & co.
(Jia-Ju Bai)
- allow COMPILE_TEST build for viafb driver (media part was reviewed by
media subsystem Maintainer)
- remove unused MERAM support from sh_mobile_lcdcfb and shmob-drm drivers
(drm parts were acked by shmob-drm driver Maintainer)
- remove unused auo_k190xfb drivers
- misc cleanups (Souptick Joarder, Wolfram Sang, Markus Elfring, Andy
Shevchenko, Colin Ian King)
Andy Shevchenko (1):
video: fbdev: pxafb: Convert to use match_string() helper
Arnd Bergmann (2):
video/omap: add module license tags
fb_omap2: add gpiolib dependency
Bartlomiej Zolnierkiewicz (7):
Merge tag 'v4.17-rc2' of git://git.kernel.org/.../torvalds/linux into
fbdev-for-next
video: fbdev: remove unused auo_k190xfb drivers
video: fbdev: sh_mobile_lcdcfb: remove unused MERAM support
drm: shmobile: remove unused MERAM support
video: fbdev: remove unused sh_mobile_meram driver
video: fbdev: via: allow COMPILE_TEST build
video: fbdev: pxafb: match_string() conversion fixup
Colin Ian King (2):
video: fbdev: fix spelling mistake: "frambuffer" -> "framebuffer"
video: fbdev: nvidia: fix spelling mistake: "scaleing" -> "scaling"
Geert Uytterhoeven (1):
video: fbdev: sh_mobile_meram: Drop SUPERH platform dependency
Jia-Ju Bai (3):
video: fbdev: savage: Replace mdelay with usleep_range in savage_init_hw
video: fbdev: aty: aty128fb: Replace mdelay with msleep in
aty128_set_suspend
video: fbdev: aty: radeon_pm: Replace mdelay with msleep in
radeonfb_pci_suspend
Markus Elfring (7):
video: sh_mobile_meram: Delete an error message for a failed memory
allocation in sh_mobile_meram_probe()
video: sh_mobile_lcdcfb: Delete an error message for a failed memory
allocation in two functions
video: auo_k190x: Delete an error message for a failed memory allocation
in auok190x_common_probe()
video: fbdev-MMP: Delete an error message for a failed memory allocation
in two functions
video: fbdev-MMP: Improve a size determination in path_init()
video: sm501fb: Improve a size determination in sm501fb_probe()
video: omap: Improve a size determination in omapfb_do_probe()
Souptick Joarder (1):
video: fbdev: core: Change return type to vm_fault_t
Tomi Valkeinen (1):
MAINTAINERS: make omapfb orphan
Wolfram Sang (2):
video: fbdev: simplify getting .drvdata
video: fbdev: omap2: omapfb: displays: simplify getting .drvdata
MAINTAINERS|6 +-
drivers/gpu/drm/shmobile/Kconfig |1 -
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 42 -
drivers/gpu/drm/shmobile/shmob_drm_crtc.h |1 -
drivers/gpu/drm/shmobile/shmob_drm_drv.h |2 -
drivers/gpu/drm/shmobile/shmob_drm_kms.c | 11 -
drivers/gpu/drm/shmobile/shmob_drm_kms.h |1 -
drivers/gpu/drm/shmobi
Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On 06/14/2018 12:38 PM, Andrea Parri wrote: Hi Thomas, On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote: The current Wound-Wait mutex algorithm is actually not Wound-Wait but Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait is, contrary to Wait-Die a preemptive algorithm and is known to generate fewer backoffs. Testing reveals that this is true if the number of simultaneous contending transactions is small. As the number of simultaneous contending threads increases, Wait-Wound becomes inferior to Wait-Die in terms of elapsed time. Possibly due to the larger number of held locks of sleeping transactions. Update documentation and callers. Timings using git://people.freedesktop.org/~thomash/ww_mutex_test tag patch-18-06-14 Each thread runs 10 batches of lock / unlock 800 ww mutexes randomly chosen out of 10. Four core Intel x86_64: Algorithm#threads Rollbacks time Wound-Wait 4 ~100 ~17s. Wait-Die 4 ~15~19s. Wound-Wait 16 ~36~109s. Wait-Die 16 ~45~82s. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie Cc: Davidlohr Bueso Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: Thomas Gleixner Cc: Kate Stewart Cc: Philippe Ombredanne Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Thomas Hellstrom --- v2: * Update API according to review comment by Greg Kroah-Hartman. * Address review comments by Peter Zijlstra: - Avoid _Bool in composites - Fix typo - Use __mutex_owner() where applicable - Rely on built-in barriers for the main loop exit condition, struct ww_acquire_ctx::wounded. Update code comments. - Explain unlocked use of list_empty(). --- Documentation/locking/ww-mutex-design.txt | 54 drivers/dma-buf/reservation.c | 2 +- drivers/gpu/drm/drm_modeset_lock.c| 2 +- include/linux/ww_mutex.h | 19 -- kernel/locking/locktorture.c | 2 +- kernel/locking/mutex.c| 103 +++--- kernel/locking/test-ww_mutex.c| 2 +- lib/locking-selftest.c| 2 +- 8 files changed, 156 insertions(+), 30 deletions(-) diff --git a/Documentation/locking/ww-mutex-design.txt b/Documentation/locking/ww-mutex-design.txt index 34c3a1b50b9a..b9597def9581 100644 --- a/Documentation/locking/ww-mutex-design.txt +++ b/Documentation/locking/ww-mutex-design.txt @@ -1,4 +1,4 @@ -Wait/Wound Deadlock-Proof Mutex Design +Wound/Wait Deadlock-Proof Mutex Design == Please read mutex-design.txt first, as it applies to wait/wound mutexes too. @@ -32,10 +32,23 @@ the oldest task) wins, and the one with the higher reservation id (i.e. the younger task) unlocks all of the buffers that it has already locked, and then tries again. -In the RDBMS literature this deadlock handling approach is called wait/wound: -The older tasks waits until it can acquire the contended lock. The younger tasks -needs to back off and drop all the locks it is currently holding, i.e. the -younger task is wounded. +In the RDBMS literature, a reservation ticket is associated with a transaction. +and the deadlock handling approach is called Wait-Die. The name is based on +the actions of a locking thread when it encounters an already locked mutex. +If the transaction holding the lock is younger, the locking transaction waits. +If the transaction holding the lock is older, the locking transaction backs off +and dies. Hence Wait-Die. +There is also another algorithm called Wound-Wait: +If the transaction holding the lock is younger, the locking transaction +preempts the transaction holding the lock, requiring it to back off. It +Wounds the other transaction. +If the transaction holding the lock is older, it waits for the other +transaction. Hence Wound-Wait. +The two algorithms are both fair in that a transaction will eventually succeed. +However, the Wound-Wait algorithm is typically stated to generate fewer backoffs +compared to Wait-Die, but is, on the other hand, associated with more work than +Wait-Die when recovering from a backoff. Wound-Wait is also a preemptive +algorithm which requires a reliable way to preempt another transaction. Concepts @@ -47,10 +60,12 @@ Acquire context: To ensure eventual forward progress it is important the a task trying to acquire locks doesn't grab a new reservation id, but keeps the one it acquired when starting the lock acquisition. This ticket is stored in the acquire context. Furthermore the acquire context keeps track of debugging state -to catch w/w mutex interface abuse. +to catch w/w mutex interface abuse. An acquire context is representing a +transaction.
Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
> __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx
> *ww_ctx)
> {
> struct mutex_waiter *cur;
> + unsigned int is_wait_die = ww_ctx->ww_class->is_wait_die;
>
> lockdep_assert_held(&lock->wait_lock);
>
> @@ -310,13 +348,14 @@ __ww_mutex_wakeup_for_backoff(struct mutex *lock,
> struct ww_acquire_ctx *ww_ctx)
> if (!cur->ww_ctx)
> continue;
>
> - if (cur->ww_ctx->acquired > 0 &&
> + if (is_wait_die && cur->ww_ctx->acquired > 0 &&
> __ww_ctx_stamp_after(cur->ww_ctx, ww_ctx)) {
> debug_mutex_wake_waiter(lock, cur);
> wake_up_process(cur->task);
> }
>
> - break;
> + if (is_wait_die || __ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
> + break;
> }
> }
I ended up with:
static void __sched
__ww_mutex_check_waiters(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
{
bool is_wait_die = ww_ctx->ww_class->is_wait_die;
struct mutex_waiter *cur;
lockdep_assert_held(&lock->wait_lock);
list_for_each_entry(cur, &lock->wait_list, list) {
if (!cur->ww_ctx)
continue;
if (is_wait_die) {
/*
* Because __ww_mutex_add_waiter() and
* __ww_mutex_check_stamp() wake any but the earliest
* context, this can only affect the first waiter (with
* a context).
*/
if (cur->ww_ctx->acquired > 0 &&
__ww_ctx_stamp_after(cur->ww_ctx, ww_ctx)) {
debug_mutex_wake_waiter(lock, cur);
wake_up_process(cur->task);
}
break;
}
if (__ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
break;
}
}
Currently you don't allow mixing WD and WW contexts (which is not
immediately obvious from the above code), and the above hard relies on
that. Are there sensible use cases for mixing them? IOW will your
current restriction stand without hassle?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On 06/14/2018 12:51 PM, Peter Zijlstra wrote:
On Wed, Jun 13, 2018 at 04:05:43PM +0200, Thomas Hellstrom wrote:
In short, with Wait-Die (before the patch) it's the process _taking_ the
contended lock that backs off if necessary. No preemption required. With
Wound-Wait, it's the process _holding_ the contended lock that gets wounded
(preempted), and it needs to back off at its own discretion but no later
than when it's going to sleep on another ww mutex. That point is where we
intercept the preemption request. We're preempting the transaction rather
than the process.
This:
Wait-die:
The newer transactions are killed when:
It (= the newer transaction) makes a reqeust for a lock being held
by an older transactions
Wound-wait:
The newer transactions are killed when:
An older transaction makes a request for a lock being held by the
newer transactions
Would make for an excellent comment somewhere. No talking about
preemption, although I think I know what you mean with it, that is not
how preemption is normally used.
Ok. I'll incorporate something along this line. Unfortunately that last
statement is not fully true. It should read
"The newer transactions are wounded when:", not "killed" when.
The literature makes a distinction between "killed" and "wounded". In
our context, "Killed" is when a transaction actually receives an
-EDEADLK and needs to back off. "Wounded" is when someone (typically
another transaction) requests a transaction to kill itself. A wound will
often, but not always, lead to a kill. If the wounded transaction has
finished its locking sequence, or has the opportunity to grab
uncontended ww mutexes or steal contended (non-handoff) ww mutexes to
finish its transaction it will do so and never kill itself.
In scheduling speak preemption is when we pick a runnable (but !running)
task to run instead of the current running task. In this case however,
our T2 is blocked on a lock acquisition (one owned by our T1) and T1 is
the only runnable task. Only when T1's progress is inhibited by T2 (T1
wants a lock held by T2) do we wound/wake T2.
Indeed. The preemption spoken about in the Wound-Wait litterature means
that a transaction preempts another transaction when it wounds it. In
distributed computing my understanding is that the preempted transaction
is aborted instantly and restarted after a random delay. Of course, we
have no means of mapping wounding to process preemption in the linux
kernel, so that's why I referred to it as "lazy preemption". In process
analogy "wounded" wound roughly correspond to (need_resched() == true),
and returning -EDEADLK would correspond to voluntary preemption.
In any case, I had a little look at the current ww_mutex code and ended
up with the below patch that hopefully clarifies things a little.
---
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index f44f658ae629..a20c04619b2a 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -244,6 +244,10 @@ void __sched mutex_lock(struct mutex *lock)
EXPORT_SYMBOL(mutex_lock);
#endif
+/*
+ * Associate the ww_mutex @ww with the context @ww_ctx under which we acquired
+ * it.
+ */
IMO use of "acquire_context" or "context" is a little unfortunate when
the literature uses "transaction",
but otherwise fine.
static __always_inline void
ww_mutex_lock_acquired(struct ww_mutex *ww, struct ww_acquire_ctx *ww_ctx)
{
@@ -282,26 +286,36 @@ ww_mutex_lock_acquired(struct ww_mutex *ww, struct
ww_acquire_ctx *ww_ctx)
DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class);
#endif
ww_ctx->acquired++;
+ lock->ctx = ctx;
}
+/*
+ * Determine if context @a is 'after' context @b. IOW, @a should be wounded in
+ * favour of @b.
+ */
So "wounded" should never really be used with Wait-Die
"Determine whether context @a represents a younger transaction than
context @b"?
static inline bool __sched
__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
{
- return a->stamp - b->stamp <= LONG_MAX &&
- (a->stamp != b->stamp || a > b);
+
+ return (signed long)(a->stamp - b->stamp) > 0;
}
/*
- * Wake up any waiters that may have to back off when the lock is held by the
- * given context.
+ * We just acquired @lock under @ww_ctx, if there are later contexts waiting
+ * behind us on the wait-list, wake them up so they can wound themselves.
Actually for Wait-Die, Back off or "Die" is the correct terminology.
*
- * Due to the invariants on the wait list, this can only affect the first
- * waiter with a context.
+ * See __ww_mutex_add_waiter() for the list-order construction; basically the
+ * list is ordered by stamp smallest (oldest) first, so if there is a later
+ * (younger) stamp on the list behind us, wake it so it can wound itself.
+ *
+ * Because __ww_mutex_add_waiter() and __ww_mutex_check_stamp() wake any
+ * but the earliest contex
Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On 06/14/2018 01:36 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
__ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx
*ww_ctx)
{
struct mutex_waiter *cur;
+ unsigned int is_wait_die = ww_ctx->ww_class->is_wait_die;
lockdep_assert_held(&lock->wait_lock);
@@ -310,13 +348,14 @@ __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
if (!cur->ww_ctx)
continue;
- if (cur->ww_ctx->acquired > 0 &&
+ if (is_wait_die && cur->ww_ctx->acquired > 0 &&
__ww_ctx_stamp_after(cur->ww_ctx, ww_ctx)) {
debug_mutex_wake_waiter(lock, cur);
wake_up_process(cur->task);
}
- break;
+ if (is_wait_die || __ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
+ break;
}
}
I ended up with:
static void __sched
__ww_mutex_check_waiters(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
{
bool is_wait_die = ww_ctx->ww_class->is_wait_die;
struct mutex_waiter *cur;
lockdep_assert_held(&lock->wait_lock);
list_for_each_entry(cur, &lock->wait_list, list) {
if (!cur->ww_ctx)
continue;
if (is_wait_die) {
/*
* Because __ww_mutex_add_waiter() and
* __ww_mutex_check_stamp() wake any but the earliest
* context, this can only affect the first waiter (with
* a context).
*/
if (cur->ww_ctx->acquired > 0 &&
__ww_ctx_stamp_after(cur->ww_ctx, ww_ctx)) {
debug_mutex_wake_waiter(lock, cur);
wake_up_process(cur->task);
}
break;
}
if (__ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
break;
}
}
Looks OK to me.
Currently you don't allow mixing WD and WW contexts (which is not
immediately obvious from the above code), and the above hard relies on
that. Are there sensible use cases for mixing them? IOW will your
current restriction stand without hassle?
Contexts _must_ agree on the algorithm used to resolve deadlocks. With
Wait-Die, for example, older transactions will wait if a lock is held by
a younger transaction and with Wound-Wait, younger transactions will
wait if a lock is held by an older transaction so there is no way of
mixing them.
Thanks,
/Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On 06/14/2018 01:49 PM, Andrea Parri wrote:
[...]
+ /*
+* wake_up_process() paired with set_current_state() inserts
+* sufficient barriers to make sure @owner either sees it's
+* wounded or has a wakeup pending to re-read the wounded
+* state.
IIUC, "sufficient barriers" = full memory barriers (here). (You may
want to be more specific.)
Thanks for reviewing!
OK. What about if someone relaxes that in the future?
This is actually one of my main concerns ;-) as, IIUC, those barriers are
not only sufficient but also necessary: anything "less than a full barrier"
(in either wake_up_process() or set_current_state()) would _not_ guarantee
the "condition" above unless I'm misunderstanding it.
But am I misunderstanding it? Which barriers/guarantee do you _need_ from
the above mentioned pairing? (hence my comment...)
Andrea
No you are probably not misunderstanding me at all. My comment
originated from the reading of the kerneldoc of set_current_state()
* set_current_state() includes a barrier so that the write of current->state
* is correctly serialised wrt the caller's subsequent test of whether to
* actually sleep:
*
* for (;;) {
* set_current_state(TASK_UNINTERRUPTIBLE);
* if (!need_sleep)
* break;
*
* schedule();
* }
* __set_current_state(TASK_RUNNING);
*
* If the caller does not need such serialisation (because, for instance, the
* condition test and condition change and wakeup are under the same
lock) then
* use __set_current_state().
*
* The above is typically ordered against the wakeup, which does:
*
* need_sleep = false;
* wake_up_state(p, TASK_UNINTERRUPTIBLE);
*
* Where wake_up_state() (and all other wakeup primitives) imply enough
* barriers to order the store of the variable against wakeup. And with
ctx->wounded := !need_sleep this exactly matches what's happening in my
code. So what I was trying to say in the comment was that this above
contract is sufficient to guarantee the "condition" above, whitout me
actually knowing exactly what barriers are required. Thanks, Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
Resending hopefully better formatted..
On 06/14/2018 01:49 PM, Andrea Parri wrote:
[...]
+ /*
+* wake_up_process() paired with set_current_state() inserts
+* sufficient barriers to make sure @owner either sees it's
+* wounded or has a wakeup pending to re-read the wounded
+* state.
IIUC, "sufficient barriers" = full memory barriers (here). (You may
want to be more specific.)
Thanks for reviewing!
OK. What about if someone relaxes that in the future?
This is actually one of my main concerns ;-) as, IIUC, those barriers are
not only sufficient but also necessary: anything "less than a full barrier"
(in either wake_up_process() or set_current_state()) would _not_ guarantee
the "condition" above unless I'm misunderstanding it.
But am I misunderstanding it? Which barriers/guarantee do you _need_ from
the above mentioned pairing? (hence my comment...)
Andrea
No you are probably not misunderstanding me at all. My comment
originated from the reading of the kerneldoc of set_current_state()
/*
* set_current_state() includes a barrier so that the write of current->state
* is correctly serialised wrt the caller's subsequent test of whether to
* actually sleep:
*
* for (;;) {
* set_current_state(TASK_UNINTERRUPTIBLE);
* if (!need_sleep)
* break;
*
* schedule();
* }
* __set_current_state(TASK_RUNNING);
*
* If the caller does not need such serialisation (because, for instance, the
* condition test and condition change and wakeup are under the same
lock) then
* use __set_current_state().
*
* The above is typically ordered against the wakeup, which does:
*
* need_sleep = false;
* wake_up_state(p, TASK_UNINTERRUPTIBLE);
*
* Where wake_up_state() (and all other wakeup primitives) imply enough
* barriers to order the store of the variable against wakeup.
---
*/
And with ctx->wounded := !need_sleep this exactly matches what's
happening in my code. So what I was trying to say in the comment was
that this above contract is sufficient to guarantee the "condition"
above, whitout me actually knowing exactly what barriers are required.
Thanks, Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
> +static bool __ww_mutex_wound(struct mutex *lock,
> + struct ww_acquire_ctx *ww_ctx,
> + struct ww_acquire_ctx *hold_ctx)
> +{
> + struct task_struct *owner = __mutex_owner(lock);
> +
> + lockdep_assert_held(&lock->wait_lock);
> +
> + if (owner && hold_ctx && __ww_ctx_stamp_after(hold_ctx, ww_ctx) &&
> + ww_ctx->acquired > 0) {
> + hold_ctx->wounded = 1;
> +
> + /*
> + * wake_up_process() paired with set_current_state() inserts
> + * sufficient barriers to make sure @owner either sees it's
> + * wounded or has a wakeup pending to re-read the wounded
> + * state.
> + *
> + * The value of hold_ctx->wounded in
> + * __ww_mutex_lock_check_stamp();
> + */
> + if (owner != current)
> + wake_up_process(owner);
> +
> + return true;
> + }
> +
> + return false;
> +}
> @@ -338,12 +377,18 @@ ww_mutex_set_context_fastpath(struct ww_mutex *lock,
> struct ww_acquire_ctx *ctx)
>* and keep spinning, or it will acquire wait_lock, add itself
>* to waiter list and sleep.
>*/
> - smp_mb(); /* ^^^ */
> + smp_mb(); /* See comments above and below. */
>
> /*
> - * Check if lock is contended, if not there is nobody to wake up
> + * Check if lock is contended, if not there is nobody to wake up.
> + * We can use list_empty() unlocked here since it only compares a
> + * list_head field pointer to the address of the list head
> + * itself, similarly to how list_empty() can be considered RCU-safe.
> + * The memory barrier above pairs with the memory barrier in
> + * __ww_mutex_add_waiter and makes sure lock->ctx is visible before
> + * we check for waiters.
>*/
> - if (likely(!(atomic_long_read(&lock->base.owner) & MUTEX_FLAG_WAITERS)))
> + if (likely(list_empty(&lock->base.wait_list)))
> return;
>
OK, so what happens is that if we see !empty list, we take wait_lock,
if we end up in __ww_mutex_wound() we must really have !empty wait-list.
It can however still see !owner because __mutex_unlock_slowpath() can
clear the owner field. But if owner is set, it must stay valid because
FLAG_WAITERS and we're holding wait_lock.
So the wake_up_process() is in fact safe.
Let me put that in a comment.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/bridge: sil_sii8620: do not have a dependency of RC_CORE
On 24.05.2018 11:32, Inki Dae wrote: > This patch makes RC_CORE to be selected with this driver. > > sil_sii8620 driver calls remote controller interfaces directly > so RC_CORE should be enabled mandatorily. > > And some boards not using remote controller device don't really > need to know that RC_CORE config should be enabled to use sil_sii8620 > driver only for HDMI. > > Changelog v2: > - select INPUT because compiling will fail without INPUT. > > Signed-off-by: Inki Dae Queued to drm-misc-next. Regards Andrzej > --- > drivers/gpu/drm/bridge/Kconfig | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 3aa65bd..3c558ee 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -72,8 +72,10 @@ config DRM_PARADE_PS8622 > > config DRM_SIL_SII8620 > tristate "Silicon Image SII8620 HDMI/MHL bridge" > - depends on OF && RC_CORE > + depends on OF > select DRM_KMS_HELPER > + select INPUT > + select RC_CORE > help > Silicon Image SII8620 HDMI/MHL bridge chip driver. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.
https://bugzilla.kernel.org/show_bug.cgi?id=199025 --- Comment #37 from Alex Tucker (a...@floop.org.uk) --- Thanks Samuel, updating to kernel-4.16.14-300.fc28.x86_64 and moving back to Nouveau rather than the workaround with the NVIDIA driver, suspend and resume now works again for me too. Would you be able to provide a link to the Fedora bug you mentioned? -- 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 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
Hi, Peter,
On 06/14/2018 02:41 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
+static bool __ww_mutex_wound(struct mutex *lock,
+struct ww_acquire_ctx *ww_ctx,
+struct ww_acquire_ctx *hold_ctx)
+{
+ struct task_struct *owner = __mutex_owner(lock);
+
+ lockdep_assert_held(&lock->wait_lock);
+
+ if (owner && hold_ctx && __ww_ctx_stamp_after(hold_ctx, ww_ctx) &&
+ ww_ctx->acquired > 0) {
+ hold_ctx->wounded = 1;
+
+ /*
+* wake_up_process() paired with set_current_state() inserts
+* sufficient barriers to make sure @owner either sees it's
+* wounded or has a wakeup pending to re-read the wounded
+* state.
+*
+* The value of hold_ctx->wounded in
+* __ww_mutex_lock_check_stamp();
+*/
+ if (owner != current)
+ wake_up_process(owner);
+
+ return true;
+ }
+
+ return false;
+}
@@ -338,12 +377,18 @@ ww_mutex_set_context_fastpath(struct ww_mutex *lock,
struct ww_acquire_ctx *ctx)
* and keep spinning, or it will acquire wait_lock, add itself
* to waiter list and sleep.
*/
- smp_mb(); /* ^^^ */
+ smp_mb(); /* See comments above and below. */
/*
-* Check if lock is contended, if not there is nobody to wake up
+* Check if lock is contended, if not there is nobody to wake up.
+* We can use list_empty() unlocked here since it only compares a
+* list_head field pointer to the address of the list head
+* itself, similarly to how list_empty() can be considered RCU-safe.
+* The memory barrier above pairs with the memory barrier in
+* __ww_mutex_add_waiter and makes sure lock->ctx is visible before
+* we check for waiters.
*/
- if (likely(!(atomic_long_read(&lock->base.owner) & MUTEX_FLAG_WAITERS)))
+ if (likely(list_empty(&lock->base.wait_list)))
return;
OK, so what happens is that if we see !empty list, we take wait_lock,
if we end up in __ww_mutex_wound() we must really have !empty wait-list.
It can however still see !owner because __mutex_unlock_slowpath() can
clear the owner field. But if owner is set, it must stay valid because
FLAG_WAITERS and we're holding wait_lock.
If __ww_mutex_wound() is called from ww_mutex_set_context_fastpath()
owner is the current process so we can never see !owner. However if
__ww_mutex_wound() is called from __ww_mutex_add_waiter() then the above
is true.
So the wake_up_process() is in fact safe.
Let me put that in a comment.
Thanks,
Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver
Am Mittwoch, 14. März 2018, 13:02:13 CEST schrieb Emil Velikov:
> Hi Lin,
>
> On 14 March 2018 at 09:12, Lin Huang wrote:
> > From: huang lin
> >
> > Refactor Innolux P079ZCA panel driver, let it support
> > multi panel.
> >
> > Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
> > Signed-off-by: Lin Huang
[...]
> > @@ -207,19 +248,28 @@ static const struct drm_panel_funcs
> > innolux_panel_funcs = {
>
> >
> > - innolux->supply = devm_regulator_get(dev, "power");
> > - if (IS_ERR(innolux->supply))
> > - return PTR_ERR(innolux->supply);
> > + innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
> > + if (!innolux)
> > + return -ENOMEM;
> > +
> > + innolux->desc = desc;
> > + innolux->vddi = devm_regulator_get(dev, "power");
> > + innolux->avdd = devm_regulator_get(dev, "avdd");
> > + innolux->avee = devm_regulator_get(dev, "avee");
> >
> AFAICT devm_regulator_get returns a pointer which is unsuitable to be
> passed into regulator_{enable,disable}.
> Hence, the IS_ERR check should stay. If any of the regulators are
> optional, you want to call regulator_{enable,disable} only as
> applicable.
using the regulator_bulk APIs should help to make this far easier,
as you can just define the per-panel supplies in in the panel_desc
and then get + enable the correct ones per bound panel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 0/8] Add Plane Color Properties
On Tue, Jun 12, 2018 at 04:01:31AM +, Shankar, Uma wrote: > > > >-Original Message- > >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of > >Alexandru-Cosmin Gheorghe > >Sent: Monday, June 11, 2018 3:47 PM > >To: Shankar, Uma > >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; > >emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, Ville > >; n...@arm.com; Lankhorst, Maarten > > > >Subject: Re: [RFC v3 0/8] Add Plane Color Properties > > > >Hi Uma, > > > >Any progress on userspace for this? > >I was thinking on working on using this in drm_hwcomposer. > > > > Hi Alex, > Not much work has been done till now on user space side. You can go ahead > and try to enable it in drm_hwcomposer. > Hi, I'm missing the hardware/driver that can do all three operations DEGAMMA, CSC, GAMMA for now, any chance you have a setup env with drm_hwcomposer and you would have time to help me with some testing after I would be writing the code ? Thank you, Alex Gheorghe > Regards, > Uma Shankar > > >Thank you, > >Alex Gheorghe > > > >On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote: > >> This patch series adds properties for plane color features. It adds > >> properties for degamma used to linearize data, CSC used for gamut > >> conversion, and gamma used to again non-linearize data as per panel > >> supported color space. These can be utilize by user space to convert > >> planes from one format to another, one color space to another etc. > >> > >> Usersapce can take smart blending decisions and utilize these hardware > >> supported plane color features to get accurate color profile. The same > >> can help in consistent color quality from source to panel taking > >> advantage of advanced color features in hardware. > >> > >> These patches just add the property interfaces and enable helper > >> functions. > >> > >> This series adds Intel Gen9 specific plane gamma feature. We can build > >> up and add other platform/hardware specific implementation on top of > >> this series > >> > >> Note: This is just to get a design feedback whether these interfaces > >> look ok. Based on community feedback on interfaces, we will implement > >> IGT tests to validate plane color features. This is un-tested currently. > >> Also, userspace implementation to use these properties is currently > >> not available. > >> > >> v2: Dropped legacy gamma table for plane as suggested by Maarten. > >> Added Gen9/BDW plane gamma feature and rebase on tot. > >> > >> v3: Added a new drm_color_lut_ext structure to accommodate 32 bit > >> precision entries, pointed to by Brian, Starkey for HDR usecases. > >> Addressed Sean,Paul comments and moved plane color properties to > >> drm_plane instead of mode_config. Added property documentation as > >suggested by Daniel, Vetter. > >> Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. > >> > >> Uma Shankar (8): > >> drm: Add Enhanced Gamma LUT precision structure > >> drm: Add Plane Degamma properties > >> drm: Add Plane CTM property > >> drm: Add Plane Gamma properties > >> drm: Define helper function for plane color enabling > >> drm/i915: Enable plane color features > >> drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms > >> drm/i915: Load plane color luts from atomic flip > >> > >> Documentation/gpu/drm-kms.rst | 18 > >> drivers/gpu/drm/drm_atomic.c | 30 +++ > >> drivers/gpu/drm/drm_atomic_helper.c | 12 +++ > >> drivers/gpu/drm/drm_plane.c | 131 > >++ > >> drivers/gpu/drm/i915/i915_drv.h | 5 ++ > >> drivers/gpu/drm/i915/i915_pci.c | 5 +- > >> drivers/gpu/drm/i915/i915_reg.h | 24 ++ > >> drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + > >> drivers/gpu/drm/i915/intel_color.c| 80 ++ > >> drivers/gpu/drm/i915/intel_device_info.h | 5 ++ > >> drivers/gpu/drm/i915/intel_display.c | 4 + > >> drivers/gpu/drm/i915/intel_drv.h | 10 +++ > >> drivers/gpu/drm/i915/intel_sprite.c | 4 + > >> include/drm/drm_color_mgmt.h | 5 ++ > >> include/drm/drm_plane.h | 66 +++ > >> include/uapi/drm/drm_mode.h | 15 > >> 16 files changed, 417 insertions(+), 1 deletion(-) > >> > >> -- > >> 1.9.1 > >> > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > >-- > >Cheers, > >Alex G > >___ > >dri-devel mailing list > >dri-devel@lists.freedesktop.org > >https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200045] black screen on 'radeon' module probing
https://bugzilla.kernel.org/show_bug.cgi?id=200045 --- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Wolfram Sang from comment #5) > Sure. But reading the original description above, I think the default use > case is to not use hw_i2c. It was just added to try to work around the > regression. And that led to another bug. Or am I wrong here? Correct. I was just clarifying that that option does. -- 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 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On 06/14/2018 02:48 PM, Thomas Hellstrom wrote:
Hi, Peter,
On 06/14/2018 02:41 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
+static bool __ww_mutex_wound(struct mutex *lock,
+ struct ww_acquire_ctx *ww_ctx,
+ struct ww_acquire_ctx *hold_ctx)
+{
+ struct task_struct *owner = __mutex_owner(lock);
+
+ lockdep_assert_held(&lock->wait_lock);
+
+ if (owner && hold_ctx && __ww_ctx_stamp_after(hold_ctx, ww_ctx) &&
+ ww_ctx->acquired > 0) {
+ hold_ctx->wounded = 1;
+
+ /*
+ * wake_up_process() paired with set_current_state() inserts
+ * sufficient barriers to make sure @owner either sees it's
+ * wounded or has a wakeup pending to re-read the wounded
+ * state.
+ *
+ * The value of hold_ctx->wounded in
+ * __ww_mutex_lock_check_stamp();
+ */
+ if (owner != current)
+ wake_up_process(owner);
+
+ return true;
+ }
+
+ return false;
+}
@@ -338,12 +377,18 @@ ww_mutex_set_context_fastpath(struct ww_mutex
*lock, struct ww_acquire_ctx *ctx)
* and keep spinning, or it will acquire wait_lock, add itself
* to waiter list and sleep.
*/
- smp_mb(); /* ^^^ */
+ smp_mb(); /* See comments above and below. */
/*
- * Check if lock is contended, if not there is nobody to wake up
+ * Check if lock is contended, if not there is nobody to wake up.
+ * We can use list_empty() unlocked here since it only compares a
+ * list_head field pointer to the address of the list head
+ * itself, similarly to how list_empty() can be considered
RCU-safe.
+ * The memory barrier above pairs with the memory barrier in
+ * __ww_mutex_add_waiter and makes sure lock->ctx is visible
before
+ * we check for waiters.
*/
- if (likely(!(atomic_long_read(&lock->base.owner) &
MUTEX_FLAG_WAITERS)))
+ if (likely(list_empty(&lock->base.wait_list)))
return;
OK, so what happens is that if we see !empty list, we take wait_lock,
if we end up in __ww_mutex_wound() we must really have !empty wait-list.
It can however still see !owner because __mutex_unlock_slowpath() can
clear the owner field. But if owner is set, it must stay valid because
FLAG_WAITERS and we're holding wait_lock.
If __ww_mutex_wound() is called from ww_mutex_set_context_fastpath()
owner is the current process so we can never see !owner. However if
__ww_mutex_wound() is called from __ww_mutex_add_waiter() then the
above is true.
Or actually it was intended to be true, but FLAG_WAITERS is set too
late. It needs to be moved to just after we actually add the waiter to
the list.
Then the hunk that replaces a FLAG_WAITERS read with a lockless
list_empty() can also be ditched.
/Thomas
So the wake_up_process() is in fact safe.
Let me put that in a comment.
Thanks,
Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On 06/14/2018 03:29 PM, Matthew Wilcox wrote: On Thu, Jun 14, 2018 at 01:54:15PM +0200, Thomas Hellstrom wrote: On 06/14/2018 01:36 PM, Peter Zijlstra wrote: Currently you don't allow mixing WD and WW contexts (which is not immediately obvious from the above code), and the above hard relies on that. Are there sensible use cases for mixing them? IOW will your current restriction stand without hassle? Contexts _must_ agree on the algorithm used to resolve deadlocks. With Wait-Die, for example, older transactions will wait if a lock is held by a younger transaction and with Wound-Wait, younger transactions will wait if a lock is held by an older transaction so there is no way of mixing them. Maybe the compiler should be enforcing that; ie make it a different type? It's intended to be enforced by storing the algorithm choice in the WW_MUTEX_CLASS which must be common for an acquire context and the ww_mutexes it acquires. However, I don't think there is a check that that holds. I guess we could add it as a DEBUG_MUTEX test in ww_mutex_lock(). Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200045] black screen on 'radeon' module probing
https://bugzilla.kernel.org/show_bug.cgi?id=200045 --- Comment #8 from cerg2010cerg2...@mail.ru --- Ok, I tested the patches, but they did not fix the problem. Nothing changed, and the log is empty. I tried to apply them separately and both at the same time. Note that second one seems to depend on the first, so I had to apply it manually. Thanks for trying to fix the issue! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106418] kernel BUG at drivers/dma-buf/reservation.c:234!
https://bugs.freedesktop.org/show_bug.cgi?id=106418 davep changed: What|Removed |Added CC||david.panar...@amd.com --- Comment #5 from davep --- Hi Mikhail, My name's Dave Panariti (david.and I'm going to be taking a look at this. You mention a script that grabs what's needed. If it doesn't build it, could you send instructions on how to do so? thanks, davep -- 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
[pull] amdgpu drm-next-4.18
Hi Dave, Fixes for 4.18. Highlights: - Fixes for gfxoff on Raven - Remove an ATPX quirk now that the root cause is fixed - Runtime PM fixes - Vega20 register header update - Wattman fixes - Misc bug fixes The following changes since commit 7ba01f9e12bb3f088f617cf69b589ea37bd5d6ed: drm/amdgpu: Fix NULL pointer when load kfd driver with PP block is disabled (2018-05-31 14:08:54 -0500) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.18 for you to fetch changes up to 5c16f36f6f003b4415237acca59384a074cd8030: drm/amd/powerplay: Set higher SCLK&MCLK frequency than dpm7 in OD (v2) (2018-06-14 07:42:39 -0500) Alex Deucher (1): Revert "drm/amdgpu: Add an ATPX quirk for hybrid laptop" Colin Ian King (2): drm/amdgpu/df: fix potential array out-of-bounds read drm/amd/pp: initialize result to before or'ing in data Evan Quan (3): drm/amd/powerplay: fix wrong clock adjust sequence drm/amdgpu: fix parsing indirect register list v2 drm/amd/powerplay: remove uncessary extra gfxoff control call Huang Rui (4): drm/amdgpu: fix the missed vcn fw version report drm/amdgpu: add checking for sos version drm/amdgpu: fix CG enabling hang with gfxoff enabled drm/amd/powerplay: fix missed hwmgr check warning before call gfx_off_control handler Junwei Zhang (1): drm/amdgpu: fix clear_all and replace handling in the VM (v2) Kenneth Feng (1): drm/amd/powerplay: Set higher SCLK&MCLK frequency than dpm7 in OD (v2) Lyude Paul (1): drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail() Pratik Vishwakarma (1): drm/amd/display: Fix stale buffer object (bo) use Rex Zhu (1): drm/amd/pp: Fix OD feature enable failed on Vega10 workstation cards Shaoyun Liu (1): drm/amd/include: Update df 3.6 mask and shift definition drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++-- drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 20 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 27 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++- .../drm/amd/include/asic_reg/df/df_3_6_sh_mask.h | 8 +++ drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 10 +--- drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 13 +-- drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 4 ++-- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 7 -- drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 9 ++-- .../gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c | 2 +- 15 files changed, 92 insertions(+), 54 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100687] KWin won't draw Aurorae themes under EGL
https://bugs.freedesktop.org/show_bug.cgi?id=100687 MirceaKitsune changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from MirceaKitsune --- Closing this for now. I understand it was a deliberate decision of the KDE developers as EGL support has been disabled on X11. If the driver developers believe this can and should be fixed by the drivers, feel free to reopen. -- 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 106919] Stuttering when trying to decode stream encoded with omx
https://bugs.freedesktop.org/show_bug.cgi?id=106919 Bug ID: 106919 Summary: Stuttering when trying to decode stream encoded with omx Product: Mesa Version: 18.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: ricardo.riba...@gmail.com QA Contact: dri-devel@lists.freedesktop.org We have the following configuration: With this configuration: Mesa 18.1.1 AMD Radeon R7 Graphics (CARRIZO, DRM 3.25.0, 4.17.0, LLVM 6.0.1) When we decode with OMX a video that was previously encoded with OMX, the video seems to roll back a second once in a while (Please take a look to the videos, it is hard to explain what is happening). We are accessing libmesa-omx with libomx-bellagio 0.9.3 and gstreamer 1.12.4 -- 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 report] drm/prime: replace NULL with error value in drm_prime_pages_to_sg
Hello YoungJun Cho,
The patch 7e3d88f9cce3: "drm/prime: replace NULL with error value in
drm_prime_pages_to_sg" from Jun 24, 2013, leads to the following
static checker warning:
drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
warn: 'sgt' can also be NULL
drivers/gpu/drm/drm_prime.c
307 /*
308 * two mappings with different directions for the same
attachment are
309 * not allowed
310 */
311 if (WARN_ON(prime_attach->dir != DMA_NONE))
312 return ERR_PTR(-EBUSY);
313
314 sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
The problematic functions here are drm_gem_cma_prime_get_sg_table() and
xen_drm_front_gem_get_sg_table(). My preference would be to update
those functions to return error pointers, but I'm not familiar with the
code or able to test it.
But this static checker test seems pretty good so I'm likely to publish
it soon and then this sort of bug will normally be caught quickly.
315
316 if (!IS_ERR(sgt)) {
317 if (!dma_map_sg_attrs(attach->dev, sgt->sgl,
sgt->nents, dir,
318DMA_ATTR_SKIP_CPU_SYNC)) {
319 sg_free_table(sgt);
320 kfree(sgt);
321 sgt = ERR_PTR(-ENOMEM);
322 } else {
323 prime_attach->sgt = sgt;
324 prime_attach->dir = dir;
325 }
326 }
327
328 return sgt;
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106919] Stuttering when trying to decode stream encoded with omx
https://bugs.freedesktop.org/show_bug.cgi?id=106919 --- Comment #1 from Ricardo Ribalda --- Created attachment 140154 --> https://bugs.freedesktop.org/attachment.cgi?id=140154&action=edit Original file encoded with omx (one keyframe per second) -- 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 106919] Stuttering when trying to decode stream encoded with omx
https://bugs.freedesktop.org/show_bug.cgi?id=106919 --- Comment #2 from Ricardo Ribalda --- Created attachment 140156 --> https://bugs.freedesktop.org/attachment.cgi?id=140156&action=edit Sluttering (how do I see the video with omx decode) -- 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 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On Thu, Jun 14, 2018 at 01:48:39PM +0200, Thomas Hellstrom wrote:
> The literature makes a distinction between "killed" and "wounded". In our
> context, "Killed" is when a transaction actually receives an -EDEADLK and
> needs to back off. "Wounded" is when someone (typically another transaction)
> requests a transaction to kill itself. A wound will often, but not always,
> lead to a kill. If the wounded transaction has finished its locking
> sequence, or has the opportunity to grab uncontended ww mutexes or steal
> contended (non-handoff) ww mutexes to finish its transaction it will do so
> and never kill itself.
Hopefully I got it all right this time; I folded your patch in and
mucked around with it a bit, but haven't done anything except compile
it.
I left the context/transaction thing because well, that's what we called
the thing.
diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 39fda195bf78..50ef5a10cfa0 100644
--- a/include/linux/ww_mutex.h
+++ b/include/linux/ww_mutex.h
@@ -8,6 +8,8 @@
*
* Wound/wait implementation:
* Copyright (C) 2013 Canonical Ltd.
+ * Choice of algorithm:
+ * Copyright (C) 2018 WMWare Inc.
*
* This file contains the main data structure and API definitions.
*/
@@ -23,14 +25,17 @@ struct ww_class {
struct lock_class_key mutex_key;
const char *acquire_name;
const char *mutex_name;
+ unsigned int is_wait_die;
};
struct ww_acquire_ctx {
struct task_struct *task;
unsigned long stamp;
- unsigned acquired;
+ unsigned int acquired;
+ unsigned short wounded;
+ unsigned short is_wait_die;
#ifdef CONFIG_DEBUG_MUTEXES
- unsigned done_acquire;
+ unsigned int done_acquire;
struct ww_class *ww_class;
struct ww_mutex *contending_lock;
#endif
@@ -38,8 +43,8 @@ struct ww_acquire_ctx {
struct lockdep_map dep_map;
#endif
#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
- unsigned deadlock_inject_interval;
- unsigned deadlock_inject_countdown;
+ unsigned int deadlock_inject_interval;
+ unsigned int deadlock_inject_countdown;
#endif
};
@@ -58,17 +63,21 @@ struct ww_mutex {
# define __WW_CLASS_MUTEX_INITIALIZER(lockname, class)
#endif
-#define __WW_CLASS_INITIALIZER(ww_class) \
+#define __WW_CLASS_INITIALIZER(ww_class, _is_wait_die) \
{ .stamp = ATOMIC_LONG_INIT(0) \
, .acquire_name = #ww_class "_acquire" \
- , .mutex_name = #ww_class "_mutex" }
+ , .mutex_name = #ww_class "_mutex" \
+ , .is_wait_die = _is_wait_die }
#define __WW_MUTEX_INITIALIZER(lockname, class) \
{ .base = __MUTEX_INITIALIZER(lockname.base) \
__WW_CLASS_MUTEX_INITIALIZER(lockname, class) }
+#define DEFINE_WD_CLASS(classname) \
+ struct ww_class classname = __WW_CLASS_INITIALIZER(classname, 1)
+
#define DEFINE_WW_CLASS(classname) \
- struct ww_class classname = __WW_CLASS_INITIALIZER(classname)
+ struct ww_class classname = __WW_CLASS_INITIALIZER(classname, 0)
#define DEFINE_WW_MUTEX(mutexname, ww_class) \
struct ww_mutex mutexname = __WW_MUTEX_INITIALIZER(mutexname, ww_class)
@@ -123,6 +132,8 @@ static inline void ww_acquire_init(struct ww_acquire_ctx
*ctx,
ctx->task = current;
ctx->stamp = atomic_long_inc_return_relaxed(&ww_class->stamp);
ctx->acquired = 0;
+ ctx->wounded = false;
+ ctx->is_wait_die = ww_class->is_wait_die;
#ifdef CONFIG_DEBUG_MUTEXES
ctx->ww_class = ww_class;
ctx->done_acquire = 0;
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index f44f658ae629..9e244af4647d 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -244,6 +244,22 @@ void __sched mutex_lock(struct mutex *lock)
EXPORT_SYMBOL(mutex_lock);
#endif
+/*
+ * Wait-Die:
+ * The newer transactions are killed when:
+ * It (the new transaction) makes a request for a lock being held
+ * by an older transaction.
+ *
+ * Wound-Wait:
+ * The newer transactions are wounded when:
+ * An older transaction makes a request for a lock being held by
+ * the newer transaction.
+ */
+
+/*
+ * Associate the ww_mutex @ww with the context @ww_ctx under which we acquired
+ * it.
+ */
static __always_inline void
ww_mutex_lock_acquired(struct ww_mutex *ww, struct ww_acquire_ctx *ww_ctx)
{
@@ -282,26 +298,96 @@ ww_mutex_lock_acquired(struct ww_mutex *ww, struct
ww_acquire_ctx *ww_ctx)
DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class);
#endif
ww_ctx->acquired++;
+ ww->ctx = ww_ctx;
}
+/*
+ * Determine if context @a is 'after' context @b. IOW, @a should be wounded in
+ * favour of @b.
+ */
static inline bool __sched
__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
{
- return a->stamp - b->stamp <= LONG_MAX &&
- (a->stamp != b->stamp || a > b);
+
+ return (signed long)(a->stamp - b-
Re: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On Thu, Jun 14, 2018 at 03:43:04PM +0200, Thomas Hellstrom wrote: > It's intended to be enforced by storing the algorithm choice in the > WW_MUTEX_CLASS which must be common for an acquire context and the > ww_mutexes it acquires. However, I don't think there is a check that that > holds. I guess we could add it as a DEBUG_MUTEX test in ww_mutex_lock(). There is ww_mutex_lock_acquired(): DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class) which should trigger if you try and be clever. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL][drm-misc-next] drm_writeback patches
Hello, Please pull the generic drm_writeback patches into drm-misc-next. They have been reviewed on the mailing lists for a while, and we have the userspace and individual kernel driver's implementations using it. The following changes since commit 33ce21d6a2491ef9adb8dc395e3f5bbbfcdc95b5: Merge tag 'drm-intel-next-fixes-2018-06-08-2' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-06-09 06:34:51 +1000) are available in the Git repository at: git://linux-arm.org/linux-ld.git f989333aea5729639e522830af8d74dd6a4bd3cf for you to fetch changes up to f989333aea5729639e522830af8d74dd6a4bd3cf: drm: writeback: Add client capability for exposing writeback connectors (2018-06-14 13:42:26 +0100) Brian Starkey (2): drm: Add writeback connector type drm: writeback: Add out-fences for writeback connectors Liviu Dudau (1): drm: writeback: Add client capability for exposing writeback connectors Documentation/gpu/drm-kms.rst| 9 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 223 +++- drivers/gpu/drm/drm_atomic_helper.c | 25 +++ drivers/gpu/drm/drm_connector.c | 4 +- drivers/gpu/drm/drm_ioctl.c | 7 + drivers/gpu/drm/drm_mode_config.c| 5 + drivers/gpu/drm/drm_writeback.c | 350 +++ include/drm/drm_atomic.h | 11 + include/drm/drm_connector.h | 13 ++ include/drm/drm_file.h | 7 + include/drm/drm_mode_config.h| 23 ++ include/drm/drm_modeset_helper_vtables.h | 11 + include/drm/drm_writeback.h | 130 include/uapi/drm/drm.h | 9 + include/uapi/drm/drm_mode.h | 1 + 16 files changed, 819 insertions(+), 11 deletions(-) create mode 100644 drivers/gpu/drm/drm_writeback.c create mode 100644 include/drm/drm_writeback.h -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ 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 #20 from sam.ps...@gmail.com --- Created attachment 140158 --> https://bugs.freedesktop.org/attachment.cgi?id=140158&action=edit dmesg w/mesa 18.0.2-1.fc28 I am still suffering from this issue, even with latest firmware from comment 15. Kernel: 4.16.14-300.fc28.x86_64 Mesa: tested both 18.0.2-1.fc28 (current Fedora release) and 18.2.0-0.11.git41dabdc.fc28 (from che/mesa copr repo). Bug occurred on both. Firmware: 20180525-85.git7518922b.fc28 (current Fedora release), but with vega10_vce.bin from comment 15 replacing the one installed by the package. My graphics card is a PowerColor RX Vega 64. I am attaching two dmesgs: one with each mentioned tested Mesa 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
[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 #21 from sam.ps...@gmail.com --- Created attachment 140159 --> https://bugs.freedesktop.org/attachment.cgi?id=140159&action=edit dmesg w/mesa 18.2.0-0.11.git41dabdc.fc28 -- 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: [DPU PATCH v3 0/7] clean up DPU custom properties
On Mon, Jun 11, 2018 at 02:13:17PM -0700, Jeykumar Sankaran wrote: > Submitting a series of patches to further clean up DPU driver by stripping > down a list of custom properties supporting proprietary features. It > removes the property installers/handlers and cleans up relevant files of > of some of the advanced features. This series is based on the patch[1] > available on the drm-next tip. > > [1]https://patchwork.kernel.org/patch/10202847/ Pushed the set + cherry-pick of this patch to dpu-staging/for-next Thanks, Sean > > Thanks. > > changes in v2: > - remove stale code in blend config > - move unrelated code while updating zpos property > - Makefile changes > changes in v3: > - rebase on https://gitlab.freedesktop.org/seanpaul/ > dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5 > > Thanks. > > Jeykumar Sankaran (7): > drm/msm: remove connector custom properties > drm/msm/dpu: clean up dpu plane custom properties > drm/msm: enable zpos normalization > drm/msm/dpu: switch to drm zpos property > Remove dpu crtc custom properties and its handlers. > drm/msm: remove msm_prop files > drm/msm: remove dpu specific uapi header > > drivers/gpu/drm/msm/Makefile |9 - > drivers/gpu/drm/msm/disp/dpu1/dpu_ad4.h| 99 -- > .../gpu/drm/msm/disp/dpu1/dpu_color_processing.c | 1521 > > .../gpu/drm/msm/disp/dpu1/dpu_color_processing.h | 120 -- > drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 30 - > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1328 + > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 45 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 14 - > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|2 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ad4.c | 1443 --- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 72 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 89 -- > .../msm/disp/dpu1/dpu_hw_color_proc_common_v4.h| 69 - > .../gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.c | 242 > .../gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.h | 40 - > .../drm/msm/disp/dpu1/dpu_hw_color_processing.h| 20 - > .../msm/disp/dpu1/dpu_hw_color_processing_v1_7.c | 565 > .../msm/disp/dpu1/dpu_hw_color_processing_v1_7.h | 92 -- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 44 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 15 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.c | 149 -- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.h | 111 -- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c| 209 --- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h| 220 --- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 67 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 14 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h| 58 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c| 68 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|6 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.c | 757 -- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.h | 27 - > .../msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.c | 943 > .../msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.h | 75 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c| 220 --- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h| 73 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c|1 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h| 156 ++ > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 11 - > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 1404 ++ > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 43 - > drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.c| 139 -- > drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.h| 310 > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 149 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |2 - > drivers/gpu/drm/msm/msm_drv.c |3 + > drivers/gpu/drm/msm/msm_drv.h | 86 +- > drivers/gpu/drm/msm/msm_prop.c | 688 - > drivers/gpu/drm/msm/msm_prop.h | 438 -- > include/uapi/drm/dpu_drm.h | 407 -- > include/uapi/drm/msm_drm.h |1 - > include/uapi/drm/msm_drm_pp.h | 345 - > 51 files changed, 297 insertions(+), 12742 deletions(-) > delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_ad4.h > delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_color_processing.c > delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_color_processing.h > delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ad4.c > delete mode 100644 > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_common_v4.h > delete mode 1
Re: [DPU PATCH] drm/msm: remove support for seamless modes
On Tue, Jun 12, 2018 at 05:49:03PM -0700, Abhinav Kumar wrote:
> Seamless modes are ones which do not require a display
> to be turned OFF/ON between mode switches.
>
> Remove support for seamless modes from DPU for now.
>
> This will be added later based on additional requirements.
>
> This change depends on the DPU custom property removal series:
> - https://patchwork.freedesktop.org/series/44592/
Pushed to dpu-staging/for-next, thanks
Sean
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 31
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 106
> +---
> drivers/gpu/drm/msm/msm_kms.h | 44
> include/uapi/drm/drm_mode.h | 1 -
> 4 files changed, 3 insertions(+), 179 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 4616a62..9ca8325 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -591,22 +591,6 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
> kfree(dpu_crtc);
> }
>
> -static bool dpu_crtc_mode_fixup(struct drm_crtc *crtc,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> - DPU_DEBUG("\n");
> -
> - if ((msm_is_mode_seamless(adjusted_mode) ||
> - msm_is_mode_seamless_vrr(adjusted_mode)) &&
> - (!crtc->enabled)) {
> - DPU_ERROR("crtc state prevents seamless transition\n");
> - return false;
> - }
> -
> - return true;
> -}
> -
> static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
> struct dpu_plane_state *pstate)
> {
> @@ -1728,12 +1712,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
> mode = &cstate->base.adjusted_mode;
> priv = crtc->dev->dev_private;
>
> - if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode) ||
> - msm_is_mode_seamless_dms(mode)) {
> - DPU_DEBUG("Seamless mode is being applied, skip disable\n");
> - return;
> - }
> -
> DPU_DEBUG("crtc%d\n", crtc->base.id);
>
> if (dpu_kms_is_suspend_state(crtc->dev))
> @@ -1817,12 +1795,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
> DPU_EVT32_VERBOSE(DRMID(crtc));
> dpu_crtc = to_dpu_crtc(crtc);
>
> - if (msm_is_mode_seamless(&crtc->state->adjusted_mode) ||
> - msm_is_mode_seamless_vrr(&crtc->state->adjusted_mode)) {
> - DPU_DEBUG("Skipping crtc enable, seamless mode\n");
> - return;
> - }
> -
> drm_for_each_encoder(encoder, crtc->dev) {
> if (encoder->crtc != crtc)
> continue;
> @@ -1857,8 +1829,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
> DPU_POWER_EVENT_PRE_DISABLE,
> dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
>
> - if (msm_needs_vblank_pre_modeset(&crtc->state->adjusted_mode))
> - drm_crtc_wait_one_vblank(crtc);
> }
>
> struct plane_state {
> @@ -2497,7 +2467,6 @@ static void dpu_crtc_early_unregister(struct drm_crtc
> *crtc)
> };
>
> static const struct drm_crtc_helper_funcs dpu_crtc_helper_funcs = {
> - .mode_fixup = dpu_crtc_mode_fixup,
> .disable = dpu_crtc_disable,
> .atomic_enable = dpu_crtc_enable,
> .atomic_check = dpu_crtc_atomic_check,
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 7dd609c..11a1045 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -96,15 +96,6 @@
> * IDLE is expected when IDLE_PC has run, and PRE_OFF did nothing.
> * PRE_OFF is expected when PRE_STOP was executed during the ON state.
> * Resource state should be in OFF at the end of the event.
> - * @DPU_ENC_RC_EVENT_PRE_MODESET:
> - * This event happens at NORMAL priority from a work item.
> - * Event signals that there is a seamless mode switch is in prgoress. A
> - * client needs to turn of only irq - leave clocks ON to reduce the mode
> - * switch latency.
> - * @DPU_ENC_RC_EVENT_POST_MODESET:
> - * This event happens at NORMAL priority from a work item.
> - * Event signals that seamless mode switch is complete and resources are
> - * acquired. Clients wants to turn on the irq again.
> * @DPU_ENC_RC_EVENT_ENTER_IDLE:
> * This event happens at NORMAL priority from a work item.
> * Event signals that there were no frame updates for IDLE_TIMEOUT time.
> @@ -116,8 +107,6 @@ enum dpu_enc_rc_events {
> DPU_ENC_RC_EVENT_FRAME_DONE,
> DPU_ENC_RC_EVENT_PRE_STOP,
> DPU_ENC_RC_EVENT_STOP,
> - DPU_ENC_RC_EVENT_PRE_MODESET,
> - DPU_ENC_RC_EVENT_POST_MODESET,
> DPU_ENC_RC_EVENT_ENTER_IDLE
> };
>
> @@ -133,7 +122,6 @@ enum dpu_enc_rc_states {
> D
[Bug 200045] black screen on 'radeon' module probing
https://bugzilla.kernel.org/show_bug.cgi?id=200045 --- Comment #9 from Wolfram Sang (w...@the-dreams.de) --- Created attachment 276551 --> https://bugzilla.kernel.org/attachment.cgi?id=276551&action=edit print initial states to allow further debug Thanks for testing the patches, pity it didn't help. Would you mind testing with the attached patch? It should give some output about the initial states. Let's hope that will lead to something... -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: mali-dp: Add debugfs file for reporting internal errors
On Tue, May 15, 2018 at 11:18:50AM +0100, Alexandru Gheorghe wrote:
> Status register contains a lot of bits for reporting internal errors
> inside Mali DP. Currently, we just silently ignore all of the errors,
> that doesn't help when we are investigating different bugs, especially
> on the FPGA models which have a lot of constraints, so we could easily
> end up in AXI or underrun errors.
>
> Add a new file called debug that contains an aggregate of the
> errors reported by the Mali DP hardware.
Hi Alex,
Sorry, I thought I had Acked this one already, but I cannot find the
proof, so:
Acked-by: Liviu Dudau
Best regards,
Liviu
>
> E.g:
> [root@alarm ~]# cat /sys/kernel/debug/dri/1/debug
> [DE] num_errors : 167
> [DE] last_error_status : 0x0001
> [DE] last_error_vblank : 385
> [SE] num_errors : 3
> [SE] last_error_status : 0x00e23001
> [SE] last_error_vblank : 201
>
> Changes since v2:
> - Add lock to protect the errors stats.
> - Add possibility to reset the error stats by writing anything to the
> debug file.
>
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 104
> ++
> drivers/gpu/drm/arm/malidp_drv.h | 19 +++
> drivers/gpu/drm/arm/malidp_hw.c | 46 ++---
> drivers/gpu/drm/arm/malidp_hw.h | 1 +
> drivers/gpu/drm/arm/malidp_regs.h | 6 +++
> 5 files changed, 169 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 8d20faa..8bfeb46 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -327,6 +328,106 @@ static int malidp_dumb_create(struct drm_file
> *file_priv,
> return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
> }
>
> +#ifdef CONFIG_DEBUG_FS
> +
> +static void malidp_error_stats_init(struct malidp_error_stats *error_stats)
> +{
> + error_stats->num_errors = 0;
> + error_stats->last_error_status = 0;
> + error_stats->last_error_vblank = -1;
> +}
> +
> +void malidp_error(struct malidp_drm *malidp,
> + struct malidp_error_stats *error_stats, u32 status,
> + u64 vblank)
> +{
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&malidp->errors_lock, irqflags);
> + error_stats->last_error_status = status;
> + error_stats->last_error_vblank = vblank;
> + error_stats->num_errors++;
> + spin_unlock_irqrestore(&malidp->errors_lock, irqflags);
> +}
> +
> +void malidp_error_stats_dump(const char *prefix,
> + struct malidp_error_stats error_stats,
> + struct seq_file *m)
> +{
> + seq_printf(m, "[%s] num_errors : %d\n", prefix,
> +error_stats.num_errors);
> + seq_printf(m, "[%s] last_error_status : 0x%08x\n", prefix,
> +error_stats.last_error_status);
> + seq_printf(m, "[%s] last_error_vblank : %lld\n", prefix,
> +error_stats.last_error_vblank);
> +}
> +
> +static int malidp_show_stats(struct seq_file *m, void *arg)
> +{
> + struct drm_device *drm = m->private;
> + struct malidp_drm *malidp = drm->dev_private;
> + unsigned long irqflags;
> + struct malidp_error_stats de_errors, se_errors;
> +
> + spin_lock_irqsave(&malidp->errors_lock, irqflags);
> + de_errors = malidp->de_errors;
> + se_errors = malidp->se_errors;
> + spin_unlock_irqrestore(&malidp->errors_lock, irqflags);
> + malidp_error_stats_dump("DE", de_errors, m);
> + malidp_error_stats_dump("SE", se_errors, m);
> + return 0;
> +}
> +
> +static int malidp_debugfs_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, malidp_show_stats, inode->i_private);
> +}
> +
> +static ssize_t malidp_debugfs_write(struct file *file, const char __user
> *ubuf,
> + size_t len, loff_t *offp)
> +{
> + struct seq_file *m = file->private_data;
> + struct drm_device *drm = m->private;
> + struct malidp_drm *malidp = drm->dev_private;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&malidp->errors_lock, irqflags);
> + malidp_error_stats_init(&malidp->de_errors);
> + malidp_error_stats_init(&malidp->se_errors);
> + spin_unlock_irqrestore(&malidp->errors_lock, irqflags);
> + return len;
> +}
> +
> +static const struct file_operations malidp_debugfs_fops = {
> + .owner = THIS_MODULE,
> + .open = malidp_debugfs_open,
> + .read = seq_read,
> + .write = malidp_debugfs_write,
> + .llseek = seq_lseek,
> + .release = single_release,
> +};
> +
> +static int malidp_debugfs_init(struct drm_minor *minor)
> +{
> + struct malidp_drm *malidp = minor->dev->dev_private;
> + struct dentry *dentry = NULL;
> +
> + malidp_error_stats_init(&malidp->de_errors);
> + malidp_error_stats_init(&malidp->s
Re: [DPU PATCH 4/4] drm/msm/dpu: use private obj to track hw resources
On Wed, Jun 13, 2018 at 12:01:21PM -0700, Jeykumar Sankaran wrote: > On 2018-06-13 09:44, Jordan Crouse wrote: > > On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote: > > > Switch to state based resource management. This patch > > > overhauls the resource manager and HW allocation methods by > > > maintaining the global resource pool and allocated hw > > > blocks in respective drm component states. > > > > > > Global resource manager(RM) is tracked in private object. > > > Allocation strategy is switched from single point allocation > > > of HW resources for the display pipeline to per component > > > based allocation, where each drm component allocates HW > > > blocks mapped to it's domain and tracks them in their respective > > > state objects. > > > > > > Fixes resource contention due to race conditions between > > > user space and display thread by reserving resources > > > only in atomic check. > > > > > > Signed-off-by: Jeykumar Sankaran > > > --- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 210 +++--- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 59 +- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 223 ++ > > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h| 4 - > > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 9 +- > > > .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 32 +- > > > .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 86 +-- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 19 +- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 8 +- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 805 > > ++--- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 149 ++-- > > > 11 files changed, 534 insertions(+), 1070 deletions(-) /snip > > cstate->num_mixers); > > > > Nit - this could be worded a bit better - "too many mixers" would be > > better, but > > I have to ask - under what circumstances would the number of mixers be > > larger > > than CRTC_DUAL_MIXERS and/or why don't we support a dynamic number of > > mixers? > > > Comes from downstream driver implementation where CRTC iterates through > RM free pool to identify mixers tagged with the current crtc id. If the > previous clean up was screwed up this may have more than 2 mixers. With > the new state based RM, its very unlikely we hit this condition. > In this case, add a comment with "/* This should never happen */" I'm just kidding, that would virtually guarantee that it does happen and we certainly don't need that bad juju around! Sean > We do support dynamic mixer counts. Based on the connector (panel) > resolution, > CRTC allocates 1 or 2 (panel_width > hw mixer width) mixer block(s) on the > first > atomic check. DPU limits max no. of hw mixers that can be ganged up for a > display to 2. > > > > return; > > > } > > /snip -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 0/4] Atomic resource management
On Tue, Jun 12, 2018 at 06:17:43PM -0700, Jeykumar Sankaran wrote: > This patchset introduces drm private object in KMS to manage HW > resource management. It modifies the resource manager by > introducing API's to do per DRM object resource allocation/cleanups. > > The patchset is based on: https://patchwork.kernel.org/patch/10461375/ > > Jeykumar Sankaran (4): > drm/msm/dpu: add atomic private object to dpu kms > drm/msm/dpu: remove scalar config definitions > drm/msm/dpu: remove resource pool manager > drm/msm/dpu: use private obj to track hw resources Kind of an odd arrangement of patches. Since you're respinning anyways, can you please reorder to: drm/msm/dpu: remove scalar config definitions drm/msm/dpu: remove resource pool manager drm/msm/dpu: add atomic private object to dpu kms drm/msm/dpu: use private obj to track hw resources Sean > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 704 +++--- > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 144 ++-- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 223 ++ > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h| 4 - > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 9 +- > .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 32 +- > .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 86 +-- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h| 10 - > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 85 ++- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 23 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 805 > ++--- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 149 ++-- > 12 files changed, 615 insertions(+), 1659 deletions(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > -- Sean Paul, Software Engineer, Google / Chromium OS ___ 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 #22 from Michel Dänzer --- (In reply to sam.psylo from comment #20) > I am still suffering from this issue, even with latest firmware from comment > 15. Please file your own report. This report is resolved. > Firmware: 20180525-85.git7518922b.fc28 (current Fedora release), but with > vega10_vce.bin from comment 15 replacing the one installed by the package. Did you double-check that's the only file which differs from the ones you have? -- 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 106872] vram sizes reported by the kernel totally off
https://bugs.freedesktop.org/show_bug.cgi?id=106872 Michel Dänzer changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|dri-devel@lists.freedesktop |mic...@daenzer.net |.org| --- Comment #3 from Michel Dänzer --- Created attachment 140160 --> https://bugs.freedesktop.org/attachment.cgi?id=140160&action=edit drm/amdgpu: Refactor amdgpu_vram_mgr_bo_sizes helper -- 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 200045] black screen on 'radeon' module probing
https://bugzilla.kernel.org/show_bug.cgi?id=200045 --- Comment #10 from cerg2010cerg2...@mail.ru --- Here is the output: [ 23.056329] (null): initial SCL state 1 [ 23.056330] (null): initial SDA state 1 [ 23.056532] (null): initial SCL state 1 [ 23.056534] (null): initial SDA state 1 [ 23.056578] (null): initial SCL state 0 [ 23.056580] (null): initial SDA state 0 [ 23.056617] (null): initial SCL state 0 [ 23.056618] (null): initial SDA state 0 [ 23.056656] (null): initial SCL state 0 [ 23.056657] (null): initial SDA state 0 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 4/4] drm/msm/dpu: use private obj to track hw resources
On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> Switch to state based resource management. This patch
> overhauls the resource manager and HW allocation methods by
> maintaining the global resource pool and allocated hw
> blocks in respective drm component states.
>
> Global resource manager(RM) is tracked in private object.
> Allocation strategy is switched from single point allocation
> of HW resources for the display pipeline to per component
> based allocation, where each drm component allocates HW
> blocks mapped to it's domain and tracks them in their respective
> state objects.
>
> Fixes resource contention due to race conditions between
> user space and display thread by reserving resources
> only in atomic check.
>
> Signed-off-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 210 +++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 59 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 223 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h| 4 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 9 +-
> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 32 +-
> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 86 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 19 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 8 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 805
> ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 149 ++--
> 11 files changed, 534 insertions(+), 1070 deletions(-)
Ok, there's a lot going on here. It's pretty easy to review megapatches where
the diffstat is mostly negative. However, this patch has a lot of code deleted
and moving around, along with the new private obj. It's really hard to review
changes like this.
Could you please split this up into a bunch of simple patches which do one
thing? ie: Moving topology is a patch, using cstate instead of crtc is a patch,
using private obj is a patch, etc, etc.
Basically, cut things down into small enough pieces such that each patch can
be easily explained without using "and" in the commit message :-)
/snip
> +
> dpu_crtc = to_dpu_crtc(crtc);
> cstate = to_dpu_crtc_state(crtc->state);
> mode = &cstate->base.adjusted_mode;
> priv = crtc->dev->dev_private;
> + dpu_kms = to_dpu_kms(priv->kms);
> +
> + /* accessing after swap state. piv_obj.state is the current state */
s/piv_obj/priv_obj/
> + dpu_priv_state = to_dpu_private_state(dpu_kms->priv_obj.state);
>
> DPU_DEBUG("crtc%d\n", crtc->base.id);
>
/snip
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/i915: Prevent writing into a read-only object via a GGTT mmap
If the user has created a read-only object, they should not be allowed
to circumvent the write protection by using a GGTT mmapping. Deny it.
Also most machines do not support read-only GGTT PTEs, so again we have
to reject attempted writes. Fortunately, this is known a priori, so we
can at least reject in the call to create the mmap (with a sanity check
in the fault handler).
v2: Check the vma->vm_flags during mmap() to allow readonly access.
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Cc: Joonas Lahtinen
Cc: Matthew Auld
Cc: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 5 +
drivers/gpu/drm/i915/i915_gem.c | 4
drivers/gpu/drm/i915/i915_gem_gtt.c | 12 +++-
drivers/gpu/drm/i915/i915_gem_object.h| 7 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_context.c | 5 +++--
include/drm/drm_vma_manager.h | 1 +
7 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4a16d7b26c89..230863813905 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1036,6 +1036,11 @@ int drm_gem_mmap(struct file *filp, struct
vm_area_struct *vma)
return -EACCES;
}
+ if (vma->vm_flags & VM_WRITE && node->readonly) {
+ drm_gem_object_put_unlocked(obj);
+ return -EINVAL;
+ }
+
ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT,
vma);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8dd4d35655af..2bfb16e83af2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2009,6 +2009,10 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
unsigned int flags;
int ret;
+ /* Sanity check that we allow writing into this object */
+ if (i915_gem_object_is_readonly(obj) && write)
+ return VM_FAULT_SIGBUS;
+
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ca84616fbe24..d57f0154b6cc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -198,7 +198,7 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
/* Applicable to VLV, and gen8+ */
pte_flags = 0;
- if (vma->obj->gt_ro)
+ if (i915_gem_object_is_readonly(vma->obj))
pte_flags |= PTE_READ_ONLY;
vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
@@ -2416,8 +2416,10 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
const gen8_pte_t pte_encode = gen8_pte_encode(0, level, 0);
dma_addr_t addr;
- /* The GTT does not support read-only mappings */
- GEM_BUG_ON(flags & PTE_READ_ONLY);
+ /*
+* Note that we ignore PTE_READ_ONLY here. The caller must be careful
+* not to allow the user to override access to a read only page.
+*/
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
gtt_entries += vma->node.start >> PAGE_SHIFT;
@@ -2656,7 +2658,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
/* Applicable to VLV (gen8+ do not support RO in the GGTT) */
pte_flags = 0;
- if (obj->gt_ro)
+ if (i915_gem_object_is_readonly(obj))
pte_flags |= PTE_READ_ONLY;
intel_runtime_pm_get(i915);
@@ -2694,7 +2696,7 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
/* Currently applicable only to VLV */
pte_flags = 0;
- if (vma->obj->gt_ro)
+ if (i915_gem_object_is_readonly(vma->obj))
pte_flags |= PTE_READ_ONLY;
if (flags & I915_VMA_LOCAL_BIND) {
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index 54f00b350779..66e30aa4b7da 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -141,7 +141,6 @@ struct drm_i915_gem_object {
* Is the object to be mapped as read-only to the GPU
* Only honoured if hardware has relevant pte bit
*/
- unsigned long gt_ro:1;
unsigned int cache_level:3;
unsigned int cache_coherent:2;
#define I915_BO_CACHE_COHERENT_FOR_READ BIT(0)
@@ -367,6 +366,12 @@ static inline void i915_gem_object_unlock(struct
drm_i915_gem_object *obj)
reservation_object_unlock(obj->resv);
}
+static inline bool
+i915_gem_object_is_readonly(const struct drm_i915_gem_object *obj)
+{
+ return obj->base.vma_node.readonly;
+}
+
static inline bool
i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm
Re: [PATCH 1/5] drm/msm: Remove pm_runtime operations from msm_iommu
On Thu, Jun 14, 2018 at 12:30:35PM +0530, Vivek Gautam wrote: > Hi Jordan, > > On Mon, Jun 11, 2018 at 11:56 PM, Jordan Crouse > wrote: > > Now that the IOMMU is the master of it's own power we don't need to bring > > up the GPU to do IOMMU operations. This is good because bringing up a6xx > > requires the GMU so calling pm_runtime_get_sync() too early in the process > > gets us into some nasty circular dependency situations. > > Thanks for the patch. > While you are removing these calls, we should add pm_runtime calls > to qcom_iommu_map(). That should make qcom_iommu too master of > its power control. > Then we should be good to go with this patch. Right - I told Rob about that in IRC but I should have mentioned it here as well. In order to do this we need to be sure that all of of the possible MMU combinations are covered. > > > > Signed-off-by: Jordan Crouse > > --- > > drivers/gpu/drm/msm/msm_iommu.c | 8 > > 1 file changed, 8 deletions(-) > > > > diff --git a/drivers/gpu/drm/msm/msm_iommu.c > > b/drivers/gpu/drm/msm/msm_iommu.c > > index b23d33622f37..ccd93ac6a4d8 100644 > > --- a/drivers/gpu/drm/msm/msm_iommu.c > > +++ b/drivers/gpu/drm/msm/msm_iommu.c > > @@ -40,9 +40,7 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const > > char * const *names, > > struct msm_iommu *iommu = to_msm_iommu(mmu); > > int ret; > > > > - pm_runtime_get_sync(mmu->dev); > > ret = iommu_attach_device(iommu->domain, mmu->dev); > > - pm_runtime_put_sync(mmu->dev); > > may be just do the following here. >return iommu_attach_device(iommu->domain, mmu->dev); I'll do that. Thanks. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/27] docs: fix broken references with multiple hints
The script: ./scripts/documentation-file-ref-check --fix-rst Gives multiple hints for broken references on some files. Manually use the one that applies for some files. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/obsolete/sysfs-gpio | 2 +- .../devicetree/bindings/display/bridge/tda998x.txt| 2 +- Documentation/trace/events.rst| 2 +- Documentation/trace/tracepoint-analysis.rst | 2 +- Documentation/translations/zh_CN/SubmittingDrivers| 2 +- Documentation/translations/zh_CN/gpio.txt | 4 ++-- MAINTAINERS | 2 +- drivers/hid/usbhid/Kconfig| 2 +- drivers/input/Kconfig | 4 ++-- drivers/input/joystick/Kconfig| 4 ++-- drivers/input/joystick/iforce/Kconfig | 4 ++-- drivers/input/serio/Kconfig | 4 ++-- drivers/staging/fsl-mc/bus/dpio/dpio-driver.txt | 2 +- drivers/video/fbdev/skeletonfb.c | 8 include/linux/tracepoint.h| 2 +- security/device_cgroup.c | 2 +- 16 files changed, 24 insertions(+), 24 deletions(-) diff --git a/Documentation/ABI/obsolete/sysfs-gpio b/Documentation/ABI/obsolete/sysfs-gpio index 32513dc2eec9..40d41ea1a3f5 100644 --- a/Documentation/ABI/obsolete/sysfs-gpio +++ b/Documentation/ABI/obsolete/sysfs-gpio @@ -11,7 +11,7 @@ Description: Kernel code may export it for complete or partial access. GPIOs are identified as they are inside the kernel, using integers in - the range 0..INT_MAX. See Documentation/gpio/gpio.txt for more information. + the range 0..INT_MAX. See Documentation/gpio for more information. /sys/class/gpio /export ... asks the kernel to export a GPIO to userspace diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt b/Documentation/devicetree/bindings/display/bridge/tda998x.txt index 1a4eaca40d94..f5a02f61dd36 100644 --- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt +++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt @@ -30,7 +30,7 @@ Optional properties: - nxp,calib-gpios: calibration GPIO, which must correspond with the gpio used for the TDA998x interrupt pin. -[1] Documentation/sound/alsa/soc/DAI.txt +[1] Documentation/sound/soc/dai.rst [2] include/dt-bindings/display/tda998x.h Example: diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst index 1afae55dc55c..696dc69b8158 100644 --- a/Documentation/trace/events.rst +++ b/Documentation/trace/events.rst @@ -8,7 +8,7 @@ Event Tracing 1. Introduction === -Tracepoints (see Documentation/trace/tracepoints.txt) can be used +Tracepoints (see Documentation/trace/tracepoints.rst) can be used without creating custom kernel modules to register probe functions using the event tracing infrastructure. diff --git a/Documentation/trace/tracepoint-analysis.rst b/Documentation/trace/tracepoint-analysis.rst index a4d3ff2e5efb..bef37abf4ad3 100644 --- a/Documentation/trace/tracepoint-analysis.rst +++ b/Documentation/trace/tracepoint-analysis.rst @@ -6,7 +6,7 @@ Notes on Analysing Behaviour Using Events and Tracepoints 1. Introduction === -Tracepoints (see Documentation/trace/tracepoints.txt) can be used without +Tracepoints (see Documentation/trace/tracepoints.rst) can be used without creating custom kernel modules to register probe functions using the event tracing infrastructure. diff --git a/Documentation/translations/zh_CN/SubmittingDrivers b/Documentation/translations/zh_CN/SubmittingDrivers index 929385e4b194..15e73562f710 100644 --- a/Documentation/translations/zh_CN/SubmittingDrivers +++ b/Documentation/translations/zh_CN/SubmittingDrivers @@ -107,7 +107,7 @@ Linux 2.6: 程序测试的指导，请参阅 Documentation/power/drivers-testing.txt。有关驱动程序电 源管理问题相对全面的概述，请参阅 - Documentation/power/admin-guide/devices.rst。 + Documentation/driver-api/pm/devices.rst。 管理：如果一个驱动程序的作者还在进行有效的维护，那么通常除了那 些明显正确且不需要任何检查的补丁以外，其他所有的补丁都会 diff --git a/Documentation/translations/zh_CN/gpio.txt b/Documentation/translations/zh_CN/gpio.txt index 4f8bf30a41dc..4cb1ba8b8fed 100644 --- a/Documentation/translations/zh_CN/gpio.txt +++ b/Documentation/translations/zh_CN/gpio.txt @@ -1,4 +1,4 @@ -Chinese translated version of Documentation/gpio.txt +Chinese translated version of Documentation/gpio If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -10,7 +10,7 @@ Maintainer: Grant Likely Linus Walleij Chinese maintainer: Fu Wei --
[PATCH v3 16/27] docs: Fix more broken references
As we move stuff around, some doc references are broken. Fix some of them via this script: ./scripts/documentation-file-ref-check --fix Manually checked that produced results are valid. Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/clock/st/st,clkgen.txt | 8 .../devicetree/bindings/clock/ti/gate.txt | 2 +- .../devicetree/bindings/clock/ti/interface.txt | 2 +- .../bindings/cpufreq/cpufreq-mediatek.txt | 2 +- .../devicetree/bindings/devfreq/rk3399_dmc.txt | 2 +- .../bindings/gpu/arm,mali-midgard.txt | 2 +- .../bindings/gpu/arm,mali-utgard.txt | 2 +- .../devicetree/bindings/mfd/mt6397.txt | 2 +- .../devicetree/bindings/mfd/sun6i-prcm.txt | 2 +- .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 2 +- .../devicetree/bindings/net/dsa/ksz.txt| 2 +- .../devicetree/bindings/net/dsa/mt7530.txt | 2 +- .../devicetree/bindings/power/fsl,imx-gpc.txt | 2 +- .../bindings/power/wakeup-source.txt | 2 +- .../devicetree/bindings/usb/rockchip,dwc3.txt | 2 +- Documentation/hwmon/ina2xx | 2 +- Documentation/maintainer/pull-requests.rst | 2 +- Documentation/translations/ko_KR/howto.rst | 2 +- MAINTAINERS| 18 +- drivers/net/ethernet/intel/Kconfig | 8 drivers/soundwire/stream.c | 8 fs/Kconfig.binfmt | 2 +- fs/binfmt_misc.c | 2 +- 23 files changed, 40 insertions(+), 40 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt index 7364953d0d0b..45ac19bfa0a9 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt @@ -31,10 +31,10 @@ This binding uses the common clock binding[1]. Each subnode should use the binding described in [2]..[7] [1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[3] Documentation/devicetree/bindings/clock/st,clkgen-mux.txt -[4] Documentation/devicetree/bindings/clock/st,clkgen-pll.txt -[7] Documentation/devicetree/bindings/clock/st,quadfs.txt -[8] Documentation/devicetree/bindings/clock/st,flexgen.txt +[3] Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt +[4] Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt +[7] Documentation/devicetree/bindings/clock/st/st,quadfs.txt +[8] Documentation/devicetree/bindings/clock/st/st,flexgen.txt Required properties: diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt index 03f8fdee62a7..56d603c1f716 100644 --- a/Documentation/devicetree/bindings/clock/ti/gate.txt +++ b/Documentation/devicetree/bindings/clock/ti/gate.txt @@ -10,7 +10,7 @@ will be controlled instead and the corresponding hw-ops for that is used. [1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/clock/gate-clock.txt +[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt [3] Documentation/devicetree/bindings/clock/ti/clockdomain.txt Required properties: diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt index 3111a409fea6..3f4704040140 100644 --- a/Documentation/devicetree/bindings/clock/ti/interface.txt +++ b/Documentation/devicetree/bindings/clock/ti/interface.txt @@ -9,7 +9,7 @@ companion clock finding (match corresponding functional gate clock) and hardware autoidle enable / disable. [1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/clock/gate-clock.txt +[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt Required properties: - compatible : shall be one of: diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt index d36f07e0a2bb..0551c78619de 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt @@ -8,7 +8,7 @@ Required properties: "intermediate" - A parent of "cpu" clock which is used as "intermediate" clock source (usually MAINPLL) when the original CPU PLL is under transition and not stable yet. - Please refer to Documentation/devicetree/bindings/clk/clock-bindings.txt for + Please refer to Documentation/devicetree/bindings/clock/clock-bindings.txt for generic clock consumer properties. - operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp.txt for detail. diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt index d6
[PATCH v3 05/27] docs: Fix some broken references
As we move stuff around, some doc references are broken. Fix some of them via this script: ./scripts/documentation-file-ref-check --fix Manually checked if the produced result is valid, removing a few false-positives. Acked-by: Takashi Iwai Acked-by: Masami Hiramatsu Acked-by: Stephen Boyd Acked-by: Charles Keepax Acked-by: Mathieu Poirier Signed-off-by: Mauro Carvalho Chehab --- .../admin-guide/kernel-parameters.txt | 4 ++-- .../bindings/input/rotary-encoder.txt | 2 +- Documentation/driver-api/gpio/consumer.rst| 2 +- Documentation/kprobes.txt | 4 ++-- Documentation/trace/coresight.txt | 2 +- Documentation/trace/ftrace-uses.rst | 2 +- Documentation/trace/histogram.txt | 2 +- Documentation/trace/intel_th.rst | 2 +- Documentation/trace/tracepoint-analysis.rst | 6 +++--- Documentation/translations/ja_JP/howto.rst| 4 ++-- .../translations/zh_CN/magic-number.txt | 4 ++-- .../zh_CN/video4linux/omap3isp.txt| 4 ++-- MAINTAINERS | 20 +-- arch/Kconfig | 2 +- arch/arm/include/asm/cacheflush.h | 2 +- arch/arm64/include/asm/cacheflush.h | 2 +- arch/microblaze/include/asm/cacheflush.h | 2 +- arch/um/Kconfig.um| 2 +- arch/unicore32/include/asm/cacheflush.h | 2 +- arch/x86/entry/vsyscall/vsyscall_64.c | 2 +- arch/xtensa/include/asm/cacheflush.h | 4 ++-- block/Kconfig | 2 +- certs/Kconfig | 2 +- crypto/asymmetric_keys/asymmetric_type.c | 2 +- crypto/asymmetric_keys/signature.c| 2 +- drivers/char/Kconfig | 2 +- drivers/clk/clk.c | 4 ++-- drivers/clk/ingenic/cgu.h | 2 +- drivers/gpu/vga/Kconfig | 2 +- drivers/gpu/vga/vgaarb.c | 2 +- drivers/input/joystick/Kconfig| 10 +- drivers/input/joystick/walkera0701.c | 2 +- drivers/input/misc/Kconfig| 4 ++-- drivers/input/misc/rotary_encoder.c | 2 +- drivers/input/mouse/Kconfig | 6 +++--- drivers/input/mouse/alps.c| 2 +- drivers/input/touchscreen/wm97xx-core.c | 2 +- drivers/lightnvm/pblk-rb.c| 2 +- drivers/md/bcache/Kconfig | 2 +- drivers/md/bcache/btree.c | 2 +- drivers/md/bcache/extents.c | 2 +- drivers/media/dvb-core/dvb_ringbuffer.c | 2 +- drivers/media/pci/meye/Kconfig| 2 +- drivers/media/platform/pxa_camera.c | 4 ++-- .../soc_camera/sh_mobile_ceu_camera.c | 2 +- drivers/media/radio/Kconfig | 2 +- drivers/media/radio/si470x/Kconfig| 2 +- drivers/media/usb/dvb-usb-v2/lmedm04.c| 2 +- drivers/media/usb/zr364xx/Kconfig | 2 +- drivers/parport/Kconfig | 6 +++--- drivers/staging/media/bcm2048/TODO| 2 +- include/keys/asymmetric-subtype.h | 2 +- include/keys/asymmetric-type.h| 2 +- include/linux/assoc_array.h | 2 +- include/linux/assoc_array_priv.h | 2 +- include/linux/circ_buf.h | 2 +- include/linux/ftrace.h| 2 +- include/linux/rculist_nulls.h | 2 +- include/uapi/linux/prctl.h| 2 +- include/xen/interface/io/kbdif.h | 2 +- kernel/cgroup/cpuset.c| 2 +- kernel/trace/Kconfig | 16 +++ lib/Kconfig | 2 +- security/selinux/hooks.c | 2 +- sound/core/Kconfig| 4 ++-- sound/drivers/Kconfig | 4 ++-- sound/pci/Kconfig | 10 +- tools/include/uapi/linux/prctl.h | 2 +- tools/lib/api/fs/fs.c | 2 +- tools/perf/util/bpf-prologue.c| 2 +- .../config/custom-timeline-functions.cfg | 4 ++-- 71 files changed, 113 insertions(+), 113 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 638342d0a095..6fa3f31ed2a5 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4335,7 +4335,7 @@ [FTRACE] Set and start specified trace events in order to facilitate early boot debugging. The event-list is a comma separated list of trace events to enable. See - also Documentati
RE: [RFC v3 0/8] Add Plane Color Properties
>-Original Message- >From: Alexandru-Cosmin Gheorghe [mailto:Alexandru- >cosmin.gheor...@arm.com] >Sent: Thursday, June 14, 2018 6:21 PM >To: Shankar, Uma >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; >emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, Ville >; n...@arm.com; Lankhorst, Maarten > >Subject: Re: [RFC v3 0/8] Add Plane Color Properties > >On Tue, Jun 12, 2018 at 04:01:31AM +, Shankar, Uma wrote: >> >> >> >-Original Message- >> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On >> >Behalf Of Alexandru-Cosmin Gheorghe >> >Sent: Monday, June 11, 2018 3:47 PM >> >To: Shankar, Uma >> >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; >> >emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, >> >Ville ; n...@arm.com; Lankhorst, Maarten >> > >> >Subject: Re: [RFC v3 0/8] Add Plane Color Properties >> > >> >Hi Uma, >> > >> >Any progress on userspace for this? >> >I was thinking on working on using this in drm_hwcomposer. >> > >> >> Hi Alex, >> Not much work has been done till now on user space side. You can go >> ahead and try to enable it in drm_hwcomposer. >> > >Hi, > >I'm missing the hardware/driver that can do all three operations DEGAMMA, CSC, >GAMMA for now, any chance you have a setup env with drm_hwcomposer and >you would have time to help me with some testing after I would be writing the >code ? > I can help with testing this out in some of our intel platforms. Will implement the platform hooks for the same. Let me know once you have the hwc changes ready. Regards, Uma Shankar >Thank you, >Alex Gheorghe > >> > >> >On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote: >> >> This patch series adds properties for plane color features. It adds >> >> properties for degamma used to linearize data, CSC used for gamut >> >> conversion, and gamma used to again non-linearize data as per panel >> >> supported color space. These can be utilize by user space to >> >> convert planes from one format to another, one color space to another etc. >> >> >> >> Usersapce can take smart blending decisions and utilize these >> >> hardware supported plane color features to get accurate color >> >> profile. The same can help in consistent color quality from source >> >> to panel taking advantage of advanced color features in hardware. >> >> >> >> These patches just add the property interfaces and enable helper >> >> functions. >> >> >> >> This series adds Intel Gen9 specific plane gamma feature. We can >> >> build up and add other platform/hardware specific implementation on >> >> top of this series >> >> >> >> Note: This is just to get a design feedback whether these >> >> interfaces look ok. Based on community feedback on interfaces, we >> >> will implement IGT tests to validate plane color features. This is >> >> un-tested >currently. >> >> Also, userspace implementation to use these properties is currently >> >> not available. >> >> >> >> v2: Dropped legacy gamma table for plane as suggested by Maarten. >> >> Added Gen9/BDW plane gamma feature and rebase on tot. >> >> >> >> v3: Added a new drm_color_lut_ext structure to accommodate 32 bit >> >> precision entries, pointed to by Brian, Starkey for HDR usecases. >> >> Addressed Sean,Paul comments and moved plane color properties to >> >> drm_plane instead of mode_config. Added property documentation as >> >suggested by Daniel, Vetter. >> >> Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. >> >> >> >> Uma Shankar (8): >> >> drm: Add Enhanced Gamma LUT precision structure >> >> drm: Add Plane Degamma properties >> >> drm: Add Plane CTM property >> >> drm: Add Plane Gamma properties >> >> drm: Define helper function for plane color enabling >> >> drm/i915: Enable plane color features >> >> drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms >> >> drm/i915: Load plane color luts from atomic flip >> >> >> >> Documentation/gpu/drm-kms.rst | 18 >> >> drivers/gpu/drm/drm_atomic.c | 30 +++ >> >> drivers/gpu/drm/drm_atomic_helper.c | 12 +++ >> >> drivers/gpu/drm/drm_plane.c | 131 >> >++ >> >> drivers/gpu/drm/i915/i915_drv.h | 5 ++ >> >> drivers/gpu/drm/i915/i915_pci.c | 5 +- >> >> drivers/gpu/drm/i915/i915_reg.h | 24 ++ >> >> drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + >> >> drivers/gpu/drm/i915/intel_color.c| 80 ++ >> >> drivers/gpu/drm/i915/intel_device_info.h | 5 ++ >> >> drivers/gpu/drm/i915/intel_display.c | 4 + >> >> drivers/gpu/drm/i915/intel_drv.h | 10 +++ >> >> drivers/gpu/drm/i915/intel_sprite.c | 4 + >> >> include/drm/drm_color_mgmt.h | 5 ++ >> >> include/drm/drm_plane.h | 66 +++ >> >> include/uapi/drm/drm_mode.h | 15 >> >> 16 files changed, 417 inserti
Re: [Intel-wired-lan] [PATCH v3 16/27] docs: Fix more broken references
On Thu, 2018-06-14 at 13:09 -0300, Mauro Carvalho Chehab wrote: > As we move stuff around, some doc references are broken. Fix some of > them via this script: > ./scripts/documentation-file-ref-check --fix > > Manually checked that produced results are valid. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Jeff Kirsher For the Intel networking Kconfig changes. > --- > .../devicetree/bindings/clock/st/st,clkgen.txt | 8 > .../devicetree/bindings/clock/ti/gate.txt | 2 +- > .../devicetree/bindings/clock/ti/interface.txt | 2 +- > .../bindings/cpufreq/cpufreq-mediatek.txt | 2 +- > .../devicetree/bindings/devfreq/rk3399_dmc.txt | 2 +- > .../bindings/gpu/arm,mali-midgard.txt | 2 +- > .../bindings/gpu/arm,mali-utgard.txt | 2 +- > .../devicetree/bindings/mfd/mt6397.txt | 2 +- > .../devicetree/bindings/mfd/sun6i-prcm.txt | 2 +- > .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 2 +- > .../devicetree/bindings/net/dsa/ksz.txt| 2 +- > .../devicetree/bindings/net/dsa/mt7530.txt | 2 +- > .../devicetree/bindings/power/fsl,imx-gpc.txt | 2 +- > .../bindings/power/wakeup-source.txt | 2 +- > .../devicetree/bindings/usb/rockchip,dwc3.txt | 2 +- > Documentation/hwmon/ina2xx | 2 +- > Documentation/maintainer/pull-requests.rst | 2 +- > Documentation/translations/ko_KR/howto.rst | 2 +- > MAINTAINERS| 18 +--- > -- > drivers/net/ethernet/intel/Kconfig | 8 > drivers/soundwire/stream.c | 8 > fs/Kconfig.binfmt | 2 +- > fs/binfmt_misc.c | 2 +- > 23 files changed, 40 insertions(+), 40 deletions(-) signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/27] docs: fix broken references with multiple hints
On Thu, 14 Jun 2018 13:08:49 -0300 Mauro Carvalho Chehab wrote: > +++ b/Documentation/trace/events.rst > @@ -8,7 +8,7 @@ Event Tracing > 1. Introduction > === > > -Tracepoints (see Documentation/trace/tracepoints.txt) can be used > +Tracepoints (see Documentation/trace/tracepoints.rst) can be used > without creating custom kernel modules to register probe functions > using the event tracing infrastructure. > > diff --git a/Documentation/trace/tracepoint-analysis.rst > b/Documentation/trace/tracepoint-analysis.rst > index a4d3ff2e5efb..bef37abf4ad3 100644 > --- a/Documentation/trace/tracepoint-analysis.rst > +++ b/Documentation/trace/tracepoint-analysis.rst > @@ -6,7 +6,7 @@ Notes on Analysing Behaviour Using Events and Tracepoints > 1. Introduction > === > > -Tracepoints (see Documentation/trace/tracepoints.txt) can be used without > +Tracepoints (see Documentation/trace/tracepoints.rst) can be used without > creating custom kernel modules to register probe functions using the event > tracing infrastructure. > Acked-by: Steven Rostedt (VMware) -- Steve ___ 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 #23 from sam.ps...@gmail.com --- (In reply to Michel Dänzer from comment #22) > (In reply to sam.psylo from comment #20) > > I am still suffering from this issue, even with latest firmware from comment > > 15. > > Please file your own report. This report is resolved. Will do. Sorry about that. > > Firmware: 20180525-85.git7518922b.fc28 (current Fedora release), but with > > vega10_vce.bin from comment 15 replacing the one installed by the package. > > Did you double-check that's the only file which differs from the ones you > have? Not directly, but I did take a look at the linux-firmware git history and that was the only firmware changed after May 25 (the date that the fedora package was based on). I'll make a new report for the bug, and continue there. -- 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: [alsa-devel] [PATCH v3 16/27] docs: Fix more broken references
On Thu, 14 Jun 2018 18:09:01 +0200, Mauro Carvalho Chehab wrote: > > As we move stuff around, some doc references are broken. Fix some of > them via this script: > ./scripts/documentation-file-ref-check --fix > > Manually checked that produced results are valid. > > Signed-off-by: Mauro Carvalho Chehab For the sound bits: Acked-by: Takashi Iwai thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] drm/i915: Prevent writing into a read-only object via a GGTT mmap
> -Original Message- > From: Chris Wilson > Sent: Thursday, June 14, 2018 9:07 AM > To: intel-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org; Chris Wilson ; > Bloomfield, Jon ; Joonas Lahtinen > ; Matthew Auld > ; David Herrmann > > Subject: [PATCH v2] drm/i915: Prevent writing into a read-only object via a > GGTT mmap > > If the user has created a read-only object, they should not be allowed > to circumvent the write protection by using a GGTT mmapping. Deny it. > > Also most machines do not support read-only GGTT PTEs, so again we have > to reject attempted writes. Fortunately, this is known a priori, so we > can at least reject in the call to create the mmap (with a sanity check > in the fault handler). > > v2: Check the vma->vm_flags during mmap() to allow readonly access. > > Signed-off-by: Chris Wilson > Cc: Jon Bloomfield > Cc: Joonas Lahtinen > Cc: Matthew Auld > Cc: David Herrmann Shame about the BUG_ON, but probably overkill to add code to suppress the RO flag just for mmap. Reviewed-by: Jon Bloomfield ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
