[PATCH v7 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
From: Boris Brezillon Document the bindings used for the Cadence DSI bridge. Signed-off-by: Boris Brezillon Reviewed-by: Rob Herring --- Changes in v7: - Add Rob's R-b Changes in v6: - Document the DPHY bindings - Drop Rob's ack because of the addition DPHY bindings doc Changes in v5: - Add optional reset line for the peripheral/APB logic Changes in v4: - Rename DSI clks (suggested by Tomi) - Drop the IP version in the compatible since it can be extracted from a register (suggested by Andrzej) Changes in v3: - Fix clock names in the example - Document how to represent DSI devices that are controller through an external bus like I2C or SPI Changes in v2: - None --- .../bindings/display/bridge/cdns,dsi.txt | 133 + 1 file changed, 133 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt new file mode 100644 index ..f5725bb6c61c --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt @@ -0,0 +1,133 @@ +Cadence DSI bridge +== + +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes. + +Required properties: +- compatible: should be set to "cdns,dsi". +- reg: physical base address and length of the controller's registers. +- interrupts: interrupt line connected to the DSI bridge. +- clocks: DSI bridge clocks. +- clock-names: must contain "dsi_p_clk" and "dsi_sys_clk". +- phys: phandle link to the MIPI D-PHY controller. +- phy-names: must contain "dphy". +- #address-cells: must be set to 1. +- #size-cells: must be set to 0. + +Optional properties: +- resets: DSI reset lines. +- reset-names: can contain "dsi_p_rst". + +Required subnodes: +- ports: Ports as described in Documentation/devicetree/bindings/graph.txt. + 2 ports are available: + * port 0: this port is only needed if some of your DSI devices are + controlled through an external bus like I2C or SPI. Can have at + most 4 endpoints. The endpoint number is directly encoding the + DSI virtual channel used by this device. + * port 1: represents the DPI input. + Other ports will be added later to support the new kind of inputs. + +- one subnode per DSI device connected on the DSI bus. Each DSI device should + contain a reg property encoding its virtual channel. + +Cadence DPHY + + +Cadence DPHY block. + +Required properties: +- compatible: should be set to "cdns,dphy". +- reg: physical base address and length of the DPHY registers. +- clocks: DPHY reference clocks. +- clock-names: must contain "psm" and "pll_ref". +- #phy-cells: must be set to 0. + + +Example: + dphy0: dphy@fd0e{ + compatible = "cdns,dphy"; + reg = <0x0 0xfd0e 0x0 0x1000>; + clocks = <&psm_clk>, <&pll_ref_clk>; + clock-names = "psm", "pll_ref"; + #phy-cells = <0>; + }; + + dsi0: dsi@fd0c { + compatible = "cdns,dsi"; + reg = <0x0 0xfd0c 0x0 0x1000>; + clocks = <&pclk>, <&sysclk>; + clock-names = "dsi_p_clk", "dsi_sys_clk"; + interrupts = <1>; + phys = <&dphy0>; + phy-names = "dphy"; + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + dsi0_dpi_input: endpoint { + remote-endpoint = <&xxx_dpi_output>; + }; + }; + }; + + panel: dsi-dev@0 { + compatible = ""; + reg = <0>; + }; + }; + +or + + dsi0: dsi@fd0c { + compatible = "cdns,dsi"; + reg = <0x0 0xfd0c 0x0 0x1000>; + clocks = <&pclk>, <&sysclk>; + clock-names = "dsi_p_clk", "dsi_sys_clk"; + interrupts = <1>; + phys = <&dphy1>; + phy-names = "dphy"; + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + dsi0_output: endpoint@0 { + reg = <0>; + remote-endpoint = <&dsi_panel_input>; + }; + }; + +
[PATCH v7 1/2] drm/bridge: Add Cadence DSI driver
From: Boris Brezillon Add a driver for Cadence DPI -> DSI bridge. This driver only support a subset of Cadence DSI bridge capabilities. This driver has been tested/debugged in a simulated environment which explains why some of the features are missing. Here is a non-exhaustive list of missing features: * burst mode * DPHY init/configuration steps * support for additional input interfaces (SDI input) DSI commands and non-burst video mode have been tested. Signed-off-by: Boris Brezillon Reviewed-by: Andrzej Hajda Acked-by: Eric Anholt Reviewed-by: Archit Taneja --- Changes in v7: - Use DIV_ROUND_UP_ULL() to fix a build error on arm 32-bit - Add Archit's R-b Changes in v6: - Use SPDX header - Do not enable the sys_clk in the probe function - Remove unneeded udelay() - Add a function to make sure the PLL and pixel clock are close enough to be recoverable if they don't match exactly - Add the DPHY init sequence used in simulation (likely to be different based on each SoC integration) Changes in v5: - Add runtime PM support Changes in v4: - Fix typos - Rename clks as suggested by Tomi - Fix DSI setup done in cdns_dsi_bridge_enable() - Add a precision about where this bridge is supposed to used to the Kconfig entry - Let DRM_CDNS_DSI select DRM_PANEL_BRIDGE - Remove the IP version from the DT compatible name - Adapt register the layout to match the one used in the last revision of the IP (hopefully the final version) Changes in v3: - replace magic values by real timing calculation. The DPHY PLL clock is still hardcoded since we don't have a working DPHY block yet, and this is the piece of HW we need to dynamically configure the PLL rate based on the display refresh rate and the resolution. - parse DSI devices represented with the OF-graph. This is needed to support DSI devices controlled through an external bus like I2C or SPI. - use the DRM panel-bridge infrastructure to simplify the DRM panel logic Changes in v2: - rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes - return the correct error when devm_clk_get(sysclk) fails - add missing depends on OF and select DRM_PANEL in the Kconfig entry DSI runtime PM --- drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/cdns-dsi.c | 1623 + 3 files changed, 1634 insertions(+) create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 42c9c2d13752..1d75d3a1f951 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -25,6 +25,16 @@ config DRM_ANALOGIX_ANX78XX the HDMI output of an application processor to MyDP or DisplayPort. +config DRM_CDNS_DSI + tristate "Cadence DPI/DSI bridge" + select DRM_KMS_HELPER + select DRM_MIPI_DSI + select DRM_PANEL_BRIDGE + depends on OF + help + Support Cadence DPI to DSI bridge. This is an internal + bridge and is meant to be directly embedded in a SoC. + config DRM_DUMB_VGA_DAC tristate "Dumb VGA DAC Bridge support" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index fd90b16a65c0..35f88d48ec20 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o +obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += megachips-stdp-ge-b850v3-fw.o diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c b/drivers/gpu/drm/bridge/cdns-dsi.c new file mode 100644 index ..9d75e6707e05 --- /dev/null +++ b/drivers/gpu/drm/bridge/cdns-dsi.c @@ -0,0 +1,1623 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright: 2017 Cadence Design Systems, Inc. + * + * Author: Boris Brezillon + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#define IP_CONF0x0 +#define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26) +#define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21) +#define VRS_FIFO_DEPTH(x) (((x) & GENMASK(20, 16)) >> 16) +#define DIRCMD_FIFO_DEPTH(x) (((x) & GENMASK(15, 13)) >> 13) +#define SDI_IFACE_32 BIT(12) +#define INTERNAL_DATAPATH_32 (0 << 10) +#define INTERNAL_DATAPATH_16 (1 << 10) +#define INTERNAL_DATAPATH_8(3 << 10) +#define INTERNAL_DATAPATH_SIZE ((x) & GENMASK(11, 10)) +#define NUM_IFACE(x) x) & GENMASK(9, 8)) >> 8) + 1) +#define MAX_LANE_NB(x) (((x) & GENMASK(7, 6)) >> 6) +#define RX_FIF
Re: [PATCH v6 1/2] drm/bridge: Add Cadence DSI driver
Hi Archit, On Sun, 15 Apr 2018 13:39:44 +0530 Archit Taneja wrote: > > +static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy, > > +struct cdns_dphy_cfg *cfg, > > +unsigned int dpi_htotal, > > +unsigned int dpi_bpp, > > +unsigned int dpi_hz, > > +unsigned int dsi_htotal, > > +unsigned int dsi_nlanes, > > +unsigned int *dsi_hfp_ext) > > +{ > > + u64 dlane_bps, dlane_bps_max, fbdiv, fbdiv_max, adj_dsi_htotal; > > + unsigned long pll_ref_hz = clk_get_rate(dphy->pll_ref_clk); > > + > > + memset(cfg, 0, sizeof(*cfg)); > > + > > + cfg->nlanes = dsi_nlanes; > > + > > + if (pll_ref_hz < 960 || pll_ref_hz >= 15000) > > + return -EINVAL; > > + else if (pll_ref_hz < 1920) > > + cfg->pll_ipdiv = 1; > > + else if (pll_ref_hz < 3840) > > + cfg->pll_ipdiv = 2; > > + else if (pll_ref_hz < 7680) > > + cfg->pll_ipdiv = 4; > > + else > > + cfg->pll_ipdiv = 8; > > + > > + /* > > +* Make sure DSI htotal is aligned on a lane boundary when calculating > > +* the expected data rate. This is done by extending HFP in case of > > +* misalignment. > > +*/ > > + adj_dsi_htotal = dsi_htotal; > > + if (dsi_htotal % dsi_nlanes) > > + adj_dsi_htotal += dsi_nlanes - (dsi_htotal % dsi_nlanes); > > + > > + dlane_bps = (u64)dpi_hz * adj_dsi_htotal; > > + > > + /* data rate in bytes/sec is not an integer, refuse the mode. */ > > + if (do_div(dlane_bps, dsi_nlanes * dpi_htotal)) > > + return -EINVAL; > > + > > + /* data rate was in bytes/sec, convert to bits/sec. */ > > + dlane_bps *= 8; > > + > > + if (dlane_bps > 25UL || dlane_bps < 16000UL) > > + return -EINVAL; > > + else if (dlane_bps >= 125000) > > + cfg->pll_opdiv = 1; > > + else if (dlane_bps >= 63000) > > + cfg->pll_opdiv = 2; > > + else if (dlane_bps >= 32000) > > + cfg->pll_opdiv = 4; > > + else if (dlane_bps >= 16000) > > + cfg->pll_opdiv = 8; > > + > > + /* > > +* Allow a deviation of 0.2% on the per-lane data rate to try to > > +* recover a potential mismatch between DPI and PPI clks. > > +*/ > > + dlane_bps_max = dlane_bps + (dlane_bps / 500); > > kbuild reported an error for 32 bit archs. I'm guessing it's because of > this divide above? Yep, DIV_ROUND_UP_ULL() should fix the problem. > > > > + > > + fbdiv_max = DIV_ROUND_DOWN_ULL((dlane_bps + (dlane_bps / 500)) * 2 * > > You could use dlane_bps_max here instead. Sure. > > Otherwise, > > Reviewed-by: Archit Taneja Thanks for the review. Does that mean I'm allowed to apply the patch to drm-misc-next myself after fixing the div64 issue? Regards, Boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91808] trine1 misrender r600g
https://bugs.freedesktop.org/show_bug.cgi?id=91808 --- Comment #10 from Hamish Wilson --- Created attachment 138966 --> https://bugs.freedesktop.org/attachment.cgi?id=138966&action=edit April 2018 Graphical Artifact Screenshots I am seeing graphical artifacts across several levels of Trine Enchanted Edition. These are most apparent with the gears in the Academy Hallways level, but I also encountered a curious lighting artifact in the Dragon Graveyard level as well as a problem with the rain later on in the same level. I am using a Sapphire Radeon HD 6870 graphics card on Arch Linux using the 4.16.3-1-ARCH Kernel package, the 1:18.0.1-1 xf86-video-ati pacakge, and the 18.0.1-1 Mesa package. -- 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 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=101739 --- Comment #15 from Marek Olšák --- We can add "glsl_correct_derivatives_after_discard=true" to Mesa's drirc and call it a day. -- 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 106164] dal_gpio_open_ex+0x34/0x180 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=106164 Bug ID: 106164 Summary: dal_gpio_open_ex+0x34/0x180 [amdgpu] Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: higu...@gmx.net Created attachment 138965 --> https://bugs.freedesktop.org/attachment.cgi?id=138965&action=edit full dmesg log With kernel 4.16.2 and mesa 18.0 i get the attach oops when booting on a Asus RX480. With kernel 4.15.x i also had the same (or similar) oops. Other than the kernel dmesg, i do not see any problem, even fan and cpu temperature are reported by the sensors command -- 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: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake
Hi all: We tested GLK DMC 1.04 FW in last week of September 2017, using the latest drm-tip version for that time (4.14.0-rc2) and according to our results we could declare this FW as acceptable and healthy to be used with kernel version 4.14 . However, we cannot guarantee quality and healthy of this FW if it is used in top of current drm-tip kernel (4.17-rc0). Best Regards Luis Botello -Original Message- From: Srivatsa, Anusha Sent: Friday, April 20, 2018 1:30 PM To: Vivi, Rodrigo ; Jani Nikula ; Botello Ortega, Luis ; Martinez Monroy, Elio Cc: Ian W MORRISON ; airl...@linux.ie; Greg KH ; intel-...@lists.freedesktop.org; linux-ker...@vger.kernel.org; sta...@vger.kernel.org; dri-devel@lists.freedesktop.org; Wajdeczko, Michal Subject: RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake >-Original Message- >From: Vivi, Rodrigo >Sent: Friday, April 20, 2018 11:04 AM >To: Jani Nikula >Cc: Srivatsa, Anusha ; Ian W MORRISON >; airl...@linux.ie; Greg KH >; intel-...@lists.freedesktop.org; linux- >ker...@vger.kernel.org; sta...@vger.kernel.org; dri- >de...@lists.freedesktop.org; Wajdeczko, Michal > >Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for >Geminilake > >On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote: >> On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: >> >>-Original Message- >> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >> >>Sent: Wednesday, April 11, 2018 5:27 AM >> >>To: Ian W MORRISON >> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha >> >>; Wajdeczko, Michal >> >>; Greg KH ; >> >>airl...@linux.ie; joonas.lahti...@linux.intel.com; >> >>linux-ker...@vger.kernel.org; sta...@vger.kernel.org; >> >>intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org >> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE >> >>for Geminilake >> >> >> >>On Wed, 11 Apr 2018, Ian W MORRISON wrote: >> >>> >> >>> >> >> NAK on indiscriminate Cc: stable. There are zero guarantees that >> older kernels will work with whatever firmware you throw at them. >> >> >>> >> >>> I included 'Cc: stable' so the patch would get added to the v4.16 >> >>> and >> >>> v4.15 kernels which I have tested with the patch. I found that >> >>> earlier kernels didn't support the 'linux-firmware' package >> >>> required to get wifi working on Intel's new Gemini Lake NUC. >> >> >> >>You realize that this patch should have nothing to do with wifi? >> >> >> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please >> >>indicate the specific versions of stable it is appropriate for. >> > >> > Hi Jani, >> > >> > The stable kernel version is 4.12 and beyond. >> > It is appropriate to add the CC: stable in my opinion >> >> Who tested the firmware with v4.12 and later? We only have the CI >> results against *current* drm-tip. We don't even know about v4.16. >> > >I understand your concerns, but the problem was that our old process >was a bit >(lot?) messed and there was the unreliable time until the firmware >really lands on linux-firmware.git. So MODULE_FIRMWARE call was only >added after firmware was really there on firmware repository but it wasn't >about the testing. > >In other words, the bump version patch was merged after tested, but >MODULE_FIRMWARE was left behind because firmware blob took a while to >get pulled into linux-firmware.git and we end up forgetting to add it there. > >In my opinion it should be safe to add the MODULE_FIRMWARE there based >on the tests from when the version was bumped. Luis, Elio, can you guys confirm that this firmware is tested and healthy? And also, give a tested-by to this patch please? Thanks, Anusha >> I'm not going to ack and take responsibility for the stable backports >> unless someone actually comes forward with credible Tested-bys. >> >> BR, >> Jani. >> >> >> > >> > Anusha >> >>BR, >> >>Jani. >> >> >> >>> >> >> PS. How is this a "RESEND"? I haven't seen this before. >> >> >>> >> >>> It is a 'RESEND' for that very reason. I initially sent the patch >> >>> to the same people as a similar patch >> >>> (https://patchwork.kernel.org/patch/10143637/) however after >> >>> realising this omitted required addresses I added them and resent >> >>> the >patch. >> >>> >> >>> Best regards, >> >>> Ian >> >> >> >>-- >> >>Jani Nikula, Intel Open Source Technology Center >> >> -- >> Jani Nikula, Intel Open Source Technology Center >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)
https://bugs.freedesktop.org/show_bug.cgi?id=104001 --- Comment #30 from Marek Olšák --- This might fix it: https://cgit.freedesktop.org/mesa/mesa/commit/?id=d15fb766aa3c98ffbe16d050b2af4804e4b12c57 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/vc4: Add support for plane alpha
The HVS supports mixing fixed alpha with per-pixel alpha or setting a fixed plane alpha in case there is no per-pixel information. This allows us to support the generic DRM plane alpha property. Signed-off-by: Stefan Schake --- v2: Non-opaque plane alpha can trigger the background blending issue and we need to hint the CRTC that background fill might be required. drivers/gpu/drm/vc4/vc4_plane.c | 21 + drivers/gpu/drm/vc4/vc4_regs.h | 1 + 2 files changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index c3a37a99e601..3483c05cc3d6 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -201,6 +201,7 @@ static void vc4_plane_reset(struct drm_plane *plane) return; plane->state = &vc4_state->base; + plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE; vc4_state->base.plane = plane; } @@ -467,6 +468,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane, u32 ctl0_offset = vc4_state->dlist_count; const struct hvs_format *format = vc4_get_hvs_format(fb->format->format); int num_planes = drm_format_num_planes(format->drm); + bool mix_plane_alpha; bool covers_screen; u32 scl0, scl1, pitch0; u32 lbm_size, tiling; @@ -552,7 +554,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane, /* Position Word 0: Image Positions and Alpha Value */ vc4_state->pos0_offset = vc4_state->dlist_count; vc4_dlist_write(vc4_state, - VC4_SET_FIELD(0xff, SCALER_POS0_FIXED_ALPHA) | + VC4_SET_FIELD(state->alpha >> 8, SCALER_POS0_FIXED_ALPHA) | VC4_SET_FIELD(vc4_state->crtc_x, SCALER_POS0_START_X) | VC4_SET_FIELD(vc4_state->crtc_y, SCALER_POS0_START_Y)); @@ -565,6 +567,13 @@ static int vc4_plane_mode_set(struct drm_plane *plane, SCALER_POS1_SCL_HEIGHT)); } + /* Don't waste cycles mixing with plane alpha if the set alpha +* is opaque or there is no per-pixel alpha information. +* In any case we use the alpha property value as the fixed alpha. +*/ + mix_plane_alpha = state->alpha != DRM_BLEND_ALPHA_OPAQUE && + fb->format->has_alpha; + /* Position Word 2: Source Image Size, Alpha */ vc4_state->pos2_offset = vc4_state->dlist_count; vc4_dlist_write(vc4_state, @@ -572,6 +581,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane, SCALER_POS2_ALPHA_MODE_PIPELINE : SCALER_POS2_ALPHA_MODE_FIXED, SCALER_POS2_ALPHA_MODE) | + (mix_plane_alpha ? SCALER_POS2_ALPHA_MIX : 0) | (fb->format->has_alpha ? SCALER_POS2_ALPHA_PREMULT : 0) | VC4_SET_FIELD(vc4_state->src_w[0], SCALER_POS2_WIDTH) | VC4_SET_FIELD(vc4_state->src_h[0], SCALER_POS2_HEIGHT)); @@ -653,10 +663,11 @@ static int vc4_plane_mode_set(struct drm_plane *plane, vc4_state->crtc_w == state->crtc->mode.hdisplay && vc4_state->crtc_h == state->crtc->mode.vdisplay; /* Background fill might be necessary when the plane has per-pixel -* alpha content and blends from the background or does not cover -* the entire screen. +* alpha content or a non-opaque plane alpha and could blend from the +* background or does not cover the entire screen. */ - vc4_state->needs_bg_fill = fb->format->has_alpha || !covers_screen; + vc4_state->needs_bg_fill = fb->format->has_alpha || !covers_screen || + state->alpha != DRM_BLEND_ALPHA_OPAQUE; return 0; } @@ -916,5 +927,7 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev, drm_plane_helper_add(plane, &vc4_plane_helper_funcs); + drm_plane_create_alpha_property(plane); + return plane; } diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h index 4af3e29d076a..d1fb6fec46eb 100644 --- a/drivers/gpu/drm/vc4/vc4_regs.h +++ b/drivers/gpu/drm/vc4/vc4_regs.h @@ -945,6 +945,7 @@ enum hvs_pixel_format { #define SCALER_POS2_ALPHA_MODE_FIXED_NONZERO 2 #define SCALER_POS2_ALPHA_MODE_FIXED_OVER_0x07 3 #define SCALER_POS2_ALPHA_PREMULT BIT(29) +#define SCALER_POS2_ALPHA_MIX BIT(28) #define SCALER_POS2_HEIGHT_MASKVC4_MASK(27, 16) #define SCALER_POS2_HEIGHT_SHIFT 16 -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Add support for plane alpha
On Sat, Apr 21, 2018 at 1:45 AM, Eric Anholt wrote: > Stefan Schake writes: > >> The HVS supports mixing fixed alpha with per-pixel alpha or >> setting a fixed plane alpha in case there is no per-pixel information. >> This allows us to support the generic DRM plane alpha property. > > Don't we need to set needs_bg_fill based on alpha != OPAQUE, as well? > > Other than that, looks good to me. I did forget about the whole background situation, and a quick test shows you are right: anything less than opaque has the funky repeating pattern artifact. Thanks, I'll send a new version. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Add support for plane alpha
Stefan Schake writes: > The HVS supports mixing fixed alpha with per-pixel alpha or > setting a fixed plane alpha in case there is no per-pixel information. > This allows us to support the generic DRM plane alpha property. Don't we need to set needs_bg_fill based on alpha != OPAQUE, as well? Other than that, looks good to me. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+
Daniel Vetter writes: > On Thu, Apr 19, 2018 at 12:20:35PM -0700, Eric Anholt wrote: >> This driver will be used to support Mesa on the Broadcom 7268 and 7278 >> platforms. >> >> V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's >> complicated CL/shader validation scheme. This massively changes the >> GEM behavior, so I've forked off to a new driver. >> >> Signed-off-by: Eric Anholt > > Read through the entire thing, ignored the hw details, but dropped a few > comments all over. With those addressed one way or another this has my > > Acked-by: Daniel Vetter > > Can I call in a return favour for > https://patchwork.freedesktop.org/series/41219/ ? Done. >> diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst >> index d3ab6abae838..f982558fc25d 100644 >> --- a/Documentation/gpu/drivers.rst >> +++ b/Documentation/gpu/drivers.rst >> @@ -10,6 +10,7 @@ GPU Driver Documentation >> tegra >> tinydrm >> tve200 >> + v3d >> vc4 >> bridge/dw-hdmi >> xen-front >> diff --git a/MAINTAINERS b/MAINTAINERS >> index bca3c32fb141..7314d66833fd 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -4795,6 +4795,15 @@ S:Maintained >> F: drivers/gpu/drm/omapdrm/ >> F: Documentation/devicetree/bindings/display/ti/ >> >> +DRM DRIVERS FOR V3D >> +M: Eric Anholt >> +T: git git://github.com/anholt/linux > > This one also official? If it's just for now I'd drop it ... Sure. >> +/* Pins the shmem pages, fills in the .pages and .sgt fields of the BO, and >> maps >> + * it for DMA. >> + */ >> +static int >> +v3d_bo_get_pages(struct v3d_bo *bo) >> +{ >> +struct drm_gem_object *obj = &bo->base; >> +struct drm_device *dev = obj->dev; >> +int npages = obj->size >> PAGE_SHIFT; >> +int ret = 0; >> + >> +mutex_lock(&bo->lock); >> +if (bo->pages_refcount++ != 0) >> +goto unlock; >> + >> +if (!obj->import_attach) { >> +bo->pages = drm_gem_get_pages(obj); >> +if (IS_ERR(bo->pages)) { >> +ret = PTR_ERR(bo->pages); >> +goto unlock; >> +} >> + >> +bo->sgt = drm_prime_pages_to_sg(bo->pages, npages); >> +if (IS_ERR(bo->sgt)) { >> +ret = PTR_ERR(bo->sgt); >> +goto put_pages; >> +} >> +} else { >> +bo->pages = kcalloc(npages, sizeof(*bo->pages), GFP_KERNEL); >> +if (!bo->pages) >> +goto put_pages; >> + >> +drm_prime_sg_to_page_addr_arrays(bo->sgt, bo->pages, >> + NULL, npages); >> +} >> + >> +/* Map the pages for use by the GPU. */ >> +dma_map_sg(dev->dev, bo->sgt->sgl, >> + bo->sgt->nents, DMA_BIDIRECTIONAL); > > For dma-buf you already get a mapped sgt, and the idea at least is to not > noodle around in internals like drm_prime_sg_to_page_addr_arrays does ... > That was just a hack Dave did to avoid rewriting all of ttm, which imo > shouldn't be copied all over the place (but it happens). > > Since you immediately convert the page list back into a mapped sg table > it's a bit silly. > > I guess longer-term we could switch the gem helpers to just use sg tables > directly, instead of going through pages arrays. But core mm folks just > got nasty on us doing that, so I'm not sure which direction we should go > here longer-term. I moved the map/unmap to the !import case. We still need the pages array for v3d_gem_fault(). If we have an alternative for that that isn't a linear walk of the sg at fault time, I'd be up for that. >> +int v3d_gem_fault(struct vm_fault *vmf) >> +{ >> +struct vm_area_struct *vma = vmf->vma; >> +struct drm_gem_object *obj = vma->vm_private_data; >> +struct v3d_bo *bo = to_v3d_bo(obj); >> +unsigned long pfn; >> +pgoff_t pgoff; >> +int ret; >> + >> +/* We don't use vmf->pgoff since that has the fake offset: */ >> +pgoff = (vmf->address - vma->vm_start) >> PAGE_SHIFT; >> +pfn = page_to_pfn(bo->pages[pgoff]); > > Freaked out for a bit, then noticed you're pinning everything. That makes > the bo->pages_refcount a bit confusing since totally not needed. > > I guess if you do have longer-term plans to roll out a shrinker I'd put at > least a FIXME here. Yep, long-term shrinker plans. Added a note to the kerneldoc about why we don't shrink yet. >> +int v3d_mmap(struct file *filp, struct vm_area_struct *vma) >> +{ >> +int ret; >> + >> +ret = drm_gem_mmap(filp, vma); >> +if (ret) >> +return ret; >> + >> +v3d_set_mmap_vma_flags(vma); > > If it'd actually understand what these vma flag frobberies in most drivers > do I might come up with an idea how we can avoid the copypaste. Oh well. > Maybe a drm_gem_mmap_wc? drm_gem_mmap seems to already be wc, just with different vma flags. If you ever figure out the flag frobbing, please let me know. :( >> + >> +return ret
[PATCH] drm/vc4: Add support for plane alpha
The HVS supports mixing fixed alpha with per-pixel alpha or setting a fixed plane alpha in case there is no per-pixel information. This allows us to support the generic DRM plane alpha property. Signed-off-by: Stefan Schake --- drivers/gpu/drm/vc4/vc4_plane.c | 14 +- drivers/gpu/drm/vc4/vc4_regs.h | 1 + 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index c3a37a99e601..b06e0ec013c5 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -201,6 +201,7 @@ static void vc4_plane_reset(struct drm_plane *plane) return; plane->state = &vc4_state->base; + plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE; vc4_state->base.plane = plane; } @@ -467,6 +468,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane, u32 ctl0_offset = vc4_state->dlist_count; const struct hvs_format *format = vc4_get_hvs_format(fb->format->format); int num_planes = drm_format_num_planes(format->drm); + bool mix_plane_alpha; bool covers_screen; u32 scl0, scl1, pitch0; u32 lbm_size, tiling; @@ -552,7 +554,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane, /* Position Word 0: Image Positions and Alpha Value */ vc4_state->pos0_offset = vc4_state->dlist_count; vc4_dlist_write(vc4_state, - VC4_SET_FIELD(0xff, SCALER_POS0_FIXED_ALPHA) | + VC4_SET_FIELD(state->alpha >> 8, SCALER_POS0_FIXED_ALPHA) | VC4_SET_FIELD(vc4_state->crtc_x, SCALER_POS0_START_X) | VC4_SET_FIELD(vc4_state->crtc_y, SCALER_POS0_START_Y)); @@ -565,6 +567,13 @@ static int vc4_plane_mode_set(struct drm_plane *plane, SCALER_POS1_SCL_HEIGHT)); } + /* Don't waste cycles mixing with plane alpha if the set alpha +* is opaque or there is no per-pixel alpha information. +* In any case we use the alpha property value as the fixed alpha. +*/ + mix_plane_alpha = state->alpha != DRM_BLEND_ALPHA_OPAQUE && + fb->format->has_alpha; + /* Position Word 2: Source Image Size, Alpha */ vc4_state->pos2_offset = vc4_state->dlist_count; vc4_dlist_write(vc4_state, @@ -572,6 +581,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane, SCALER_POS2_ALPHA_MODE_PIPELINE : SCALER_POS2_ALPHA_MODE_FIXED, SCALER_POS2_ALPHA_MODE) | + (mix_plane_alpha ? SCALER_POS2_ALPHA_MIX : 0) | (fb->format->has_alpha ? SCALER_POS2_ALPHA_PREMULT : 0) | VC4_SET_FIELD(vc4_state->src_w[0], SCALER_POS2_WIDTH) | VC4_SET_FIELD(vc4_state->src_h[0], SCALER_POS2_HEIGHT)); @@ -916,5 +926,7 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev, drm_plane_helper_add(plane, &vc4_plane_helper_funcs); + drm_plane_create_alpha_property(plane); + return plane; } diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h index 4af3e29d076a..d1fb6fec46eb 100644 --- a/drivers/gpu/drm/vc4/vc4_regs.h +++ b/drivers/gpu/drm/vc4/vc4_regs.h @@ -945,6 +945,7 @@ enum hvs_pixel_format { #define SCALER_POS2_ALPHA_MODE_FIXED_NONZERO 2 #define SCALER_POS2_ALPHA_MODE_FIXED_OVER_0x07 3 #define SCALER_POS2_ALPHA_PREMULT BIT(29) +#define SCALER_POS2_ALPHA_MIX BIT(28) #define SCALER_POS2_HEIGHT_MASKVC4_MASK(27, 16) #define SCALER_POS2_HEIGHT_SHIFT 16 -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] gpu: drm: i915: Change return type to vm_fault_t
On Wed, Apr 18, 2018 at 08:46:44AM +0300, Jani Nikula wrote: > On Tue, 17 Apr 2018, Souptick Joarder wrote: > > On 17-Apr-2018 9:45 PM, "Matthew Wilcox" wrote: > >> > >> On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote: > >> > Not exactly. The plan for these patches is to introduce new vm_fault_t > > type > >> > in vm_operations_struct fault handlers. It's now available in 4.17-rc1. > > We will > >> > push all the required drivers/filesystem changes through different > > maintainers > >> > to linus tree. Once everything is converted into vm_fault_t type then > > Changing > >> > it from a signed to an unsigned int causes GCC to warn about an > > assignment > >> > from an incompatible type -- int foo(void) is incompatible with > >> > unsigned int foo(void). > >> > > >> > Please refer 1c8f422059ae ("mm: change return type to vm_fault_t") in > > 4.17-rc1. > >> > >> I think this patch would be clearer if you did > >> > >> - int ret; > >> + int err; > >> + vm_fault_t ret; > >> > >> Then it would be clearer to the maintainer that you're splitting apart the > >> VM_FAULT and errno codes. > >> > >> Sorry for not catching this during initial review. > > > > Ok, I will make required changes and send v2. Sorry, even I missed this :) > > I'm afraid Daniel is closer to the truth. +1. > My bad, sorry for the noise. I opened this thread to add exactly question/noise ;). So my recommendation for some next time is to make the intention clear on the commit message itself from the begin. > > BR, > Jani. > > > > >> > >> > On Tue, Apr 17, 2018 at 8:59 PM, Jani Nikula > >> > wrote: > >> > > On Tue, 17 Apr 2018, Souptick Joarder wrote: > >> > >> Use new return type vm_fault_t for fault handler. For > >> > >> now, this is just documenting that the function returns > >> > >> a VM_FAULT value rather than an errno. Once all instances > >> > >> are converted, vm_fault_t will become a distinct type. > >> > >> > >> > >> Reference id -> 1c8f422059ae ("mm: change return type to > >> > >> vm_fault_t") > >> > >> > >> > >> Signed-off-by: Souptick Joarder > >> > >> --- > >> > >> drivers/gpu/drm/i915/i915_drv.h | 3 ++- > >> > >> drivers/gpu/drm/i915/i915_gem.c | 15 --- > >> > >> 2 files changed, 10 insertions(+), 8 deletions(-) > >> > >> > >> > >> diff --git a/drivers/gpu/drm/i915/i915_drv.h > > b/drivers/gpu/drm/i915/i915_drv.h > >> > >> index a42deeb..95b0d50 100644 > >> > >> --- a/drivers/gpu/drm/i915/i915_drv.h > >> > >> +++ b/drivers/gpu/drm/i915/i915_drv.h > >> > >> @@ -51,6 +51,7 @@ > >> > >> #include > >> > >> #include > >> > >> #include > >> > >> +#include > >> > >> > >> > >> #include "i915_params.h" > >> > >> #include "i915_reg.h" > >> > >> @@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct > > drm_i915_private *dev_priv, > >> > >> unsigned int flags); > >> > >> int __must_check i915_gem_suspend(struct drm_i915_private > > *dev_priv); > >> > >> void i915_gem_resume(struct drm_i915_private *dev_priv); > >> > >> -int i915_gem_fault(struct vm_fault *vmf); > >> > >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf); > >> > >> int i915_gem_object_wait(struct drm_i915_gem_object *obj, > >> > >>unsigned int flags, > >> > >>long timeout, > >> > >> diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > >> > >> index dd89abd..bdac690 100644 > >> > >> --- a/drivers/gpu/drm/i915/i915_gem.c > >> > >> +++ b/drivers/gpu/drm/i915/i915_gem.c > >> > >> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void) > >> > >> * The current feature set supported by i915_gem_fault() and thus > > GTT mmaps > >> > >> * is exposed via I915_PARAM_MMAP_GTT_VERSION (see > > i915_gem_mmap_gtt_version). > >> > >> */ > >> > >> -int i915_gem_fault(struct vm_fault *vmf) > >> > >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf) > >> > >> { > >> > >> #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */ > >> > >> struct vm_area_struct *area = vmf->vma; > >> > >> @@ -1895,6 +1895,7 @@ int i915_gem_fault(struct vm_fault *vmf) > >> > >> pgoff_t page_offset; > >> > >> unsigned int flags; > >> > >> int ret; > >> > >> + vm_fault_t retval; > >> > > > >> > > What's the point of changing the name? An unnecessary change. > >> > > > >> > > BR, > >> > > Jani. > >> > > > >> > >> > >> > >> /* We don't use vmf->pgoff since that has the fake offset */ > >> > >> page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT; > >> > >> @@ -2000,7 +2001,7 @@ int i915_gem_fault(struct vm_fault *vmf) > >> > >>* and so needs to be reported. > >> > >>*/ > >> > >> if (!i915_terminally_wedged(&dev_priv->gpu_error)) { > >> > >> - ret = VM_FAULT_SIGBUS; > >> > >> + retval = VM_FAULT_SIGBUS; > >> > >> break; > >> > >> } > >> > >> case -EAGAI
Re: [PATCH 8/9] drm/vc4: Always obey implicit sync
Daniel Vetter writes: > Same justification as for drm_gem_fb_prepare_fb. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/9] drm/gem-fb-helper: Always do implicit sync
Daniel Vetter writes: > I've done a lot of history digging. The first signs of this > optimization was introduced in i915: I can't come up with any reason this would matter. I almost came up with "You're doing tearing X11 front buffer rendering, and you do a modeset using the same fb, and so you block that modeset behind your rendering." Except that: 1) who cares 2) this helper is only for dma-bufs, not normal X11 rendering 3) your X11 driver should be doing pageflipping to be tear-free anyway, let's just fix that[1]. Reviewed-by: Eric Anholt [1] This is not actually me volunteering myself or anyone else to go fix that. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/9] drm/atomic: better doc for implicit vs explicit fencing
Daniel Vetter writes: > Note that a pile of drivers don't seem to take implicit fencing into > account, or at least don't call drm_atoimc_set_fence_for_plane(). ^atomic > Cc'ing relevant people, or at least some. Some drivers also look like > they don't disable implicit fencing (e.g. amdgpu) because the explicit > fences and implicit fences are handled by entirely independent code > paths. > > I also wonder whether we shouldn't just make the recommended helpers > the default ones, since a lot of drivers don't bother to handle the > implicit fences at all it seems. The helpers won't blow up even for > non-GEM drivers or GEM drivers which don't fill out the gem bo > pointers in struct drm_framebuffer. > > Cc: Gerd Hoffmann > Cc: Alex Deucher > Cc: Harry Wentland > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: Gustavo Padovan > Cc: Maarten Lankhorst > Cc: Sean Paul > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_atomic.c | 8 > include/drm/drm_modeset_helper_vtables.h | 5 - > include/drm/drm_plane.h | 7 ++- > 3 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 7d25c42f22db..ec77afbda0c3 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -1492,6 +1492,14 @@ EXPORT_SYMBOL(drm_atomic_set_fb_for_plane); > * Otherwise, if &drm_plane_state.fence is not set this function we just set > it > * with the received implicit fence. In both cases this function consumes a > * reference for @fence. > + * > + * This way explicit fencing can be used to overrule implicit fencing, which > is > + * important to make explicit fencing use-cases work: One example is using > one > + * buffer for 2 screens with different refresh rates. Implicit fencing will > + * clamp rendering to the refresh rate of the slower screen, whereas explicit > + * fence allows 2 independent render and display loops on a single buffer. > If a > + * driver allows obeys both implicit and explicit fences for plane updates, > then > + * it will break all the benefits of explicit fencing. > */ Thanks for explaining why we should care about explicit fencing for display! I'd been trying and failing to generate a usecase. > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h > index d6da26d66a4b..1e2622e33208 100644 > --- a/include/drm/drm_plane.h > +++ b/include/drm/drm_plane.h > @@ -80,7 +80,12 @@ struct drm_plane_state { >* @fence: >* >* Optional fence to wait for before scanning out @fb. Do not write this > - * directly, use drm_atomic_set_fence_for_plane() > + * directly, use drm_atomic_set_fence_for_plane(). The core atomic code > + * will set this when userspace is using explicit fencing. Optional suggestion: * Optional fence to wait for before scanning out @fb. The core * atomic code will set this when userspace is using explicit * fencing. Do not write this directly for a driver's implicit * fence, use drm_atomic_set_fence_for_plane() to ensure that * an explicit fence is preserved. > + * > + * Drivers should store any implicit fences in this from their Maybe s/fences/fence/ to make it more obvious that you can only attach one? > + * &drm_plane_helper.prepare_fb callback. See drm_gem_fb_prepare_fb() > + * and drm_gem_fb_simple_display_pipe_prepare_fb() for suitable helpers. >*/ > struct dma_fence *fence; Regardless, Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] drm/mxsfb: Use simple_display_pipe prepare_fb helper
Daniel Vetter writes: > Signed-off-by: Daniel Vetter > Cc: Marek Vasut 4,5 are: Reviewed-by: Eric Anholt It would be great to land this series up to here soon, as I was surprised to see another new simple_display_pipe prepare implementation in a driver I reviewed this week. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105680] [CI] igt@kms_frontbuffer_tracking@* - fail - FBC disabled: mode too large for compression
https://bugs.freedesktop.org/show_bug.cgi?id=105680 Jose Roberto de Souza changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |jose.so...@intel.com |.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: [v2] drm/sun4i: add lvds mode_valid function
On Fri, Apr 20, 2018 at 03:10:26PM +0200, Ondřej Jirman wrote: > Hello, > > On Thu, Apr 19, 2018 at 04:02:08PM +0200, Giulio Benetti wrote: > > Hi everybody, > > > > Il 19/04/2018 15:36, Chen-Yu Tsai ha scritto: > > > On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman > > > wrote: > > > > Hello Giulio, > > > > > > > > this patch breaks LVDS output on A83T. Without it, modesetting works, > > > > with it there's no output. > > > > > > > > Some more info below... > > > > > > > > On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote: > > > > > mode_valid function is missing for lvds. > > > > > > > > > > Add it making it pointed by encoder helper functions. > > > > > > > > > > Signed-off-by: Giulio Benetti > > > > > --- > > > > > drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 > > > > > ++ > > > > > 1 file changed, 55 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c > > > > > b/drivers/gpu/drm/sun4i/sun4i_lvds.c > > > > > index be3f14d..b4c 100644 > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_lvds.c > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c > > > > > @@ -94,9 +94,64 @@ static void sun4i_lvds_encoder_disable(struct > > > > > drm_encoder *encoder) > > > > >} > > > > > } > > > > > > > > > > +static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct > > > > > drm_encoder *crtc, > > > > > + const struct > > > > > drm_display_mode *mode) > > > > > +{ > > > > > + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc); > > > > > + struct sun4i_tcon *tcon = lvds->tcon; > > > > > + u32 hsync = mode->hsync_end - mode->hsync_start; > > > > > + u32 vsync = mode->vsync_end - mode->vsync_start; > > > > > + unsigned long rate = mode->clock * 1000; > > > > > + long rounded_rate; > > > > > + > > > > > + DRM_DEBUG_DRIVER("Validating modes...\n"); > > > > > + > > > > > + if (hsync < 1) > > > > > + return MODE_HSYNC_NARROW; > > > > > + > > > > > + if (hsync > 0x3ff) > > > > > + return MODE_HSYNC_WIDE; > > > > > + > > > > > + if ((mode->hdisplay < 1) || (mode->htotal < 1)) > > > > > + return MODE_H_ILLEGAL; > > > > > + > > > > > + if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff)) > > > > > + return MODE_BAD_HVALUE; > > > > > + > > > > > + DRM_DEBUG_DRIVER("Horizontal parameters OK\n"); > > > > > + > > > > > + if (vsync < 1) > > > > > + return MODE_VSYNC_NARROW; > > > > > + > > > > > + if (vsync > 0x3ff) > > > > > + return MODE_VSYNC_WIDE; > > > > > + > > > > > + if ((mode->vdisplay < 1) || (mode->vtotal < 1)) > > > > > + return MODE_V_ILLEGAL; > > > > > + > > > > > + if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff)) > > > > > + return MODE_BAD_VVALUE; > > > > > + > > > > > + DRM_DEBUG_DRIVER("Vertical parameters OK\n"); > > > > > + > > > > > + tcon->dclk_min_div = 7; > > > > > + tcon->dclk_max_div = 7; > > > > > > > > Why would validation function change any state anywhere? > > > > > > > > > + rounded_rate = clk_round_rate(tcon->dclk, rate); > > > > > > > > The issue is here, on A83T TBS A711 tablet, I get... > > > > > > > > sun4i-tcon 1c0c000.lcd-controller: XXX: hsync=20 hdisplay=1024 > > > > htotal=1384 > > > >vsync=5 vdisplay=600 vtotal=640 rate=5200 rounded_rate=51857142 > > > > > > > > > + if (rounded_rate < rate) > > > > > + return MODE_CLOCK_LOW; > > > > > + > > > > > + if (rounded_rate > rate) > > > > > + return MODE_CLOCK_HIGH; > > > > > > > > ... while the previous conditions require an exact match for some > > > > reason. > > > > > > > > But HW works fine without an exact rate match. Why is exact match > > > > required here? > > > > > > This thread might provide some more info, though we could never get an > > > agreement. > > > > > > https://patchwork.kernel.org/patch/9446385/ > > > > Thanks for pointing that Thread ChenYu. > > So the only chance is to trim frequency according to encoder capabilities. > > I agree to block when encoder can't provide frequency specified, > > otherwise you could drive you panel at the near the lowest(highest) > > frequency and get out of limits for a few without knowing it. > > When I set the range of pixel clock frequencies on simple-panel connected > to this encoder, the check still fails, so there's something not working > there as expected. This check is only called once with a typical frequency. > > I guess drm doesn't implement clock-frequency range on panels. But I haven't > looked. It does, but only omapdss is able to use it iirc. We could do it too, but that would be way out of scope for a fix. > I can set the exact frequency that the SoC can provide on the simple-panel, > but that's a bit of a hack. Yes. And if the only device using this thus far is broken, that's not re
Re: RFC for a render API to support adaptive sync and VRR
On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote: > On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote: > > Michel Dänzer writes: > >> Time-based presentation seems to be the right approach for preventing > >> micro-stutter in games as well, Croteam developers have been researching > >> this. > > > > Both the Vulkan GOOGLE_display_timing extension and X11 Present > > extension offer the ability to specify the desired display time in > > seconds. > > > > Similarly, I'd suggest that the min/max display refresh rate values be > > advertised as time between frames rather than frames per second. So there is a global min and max refresh rate as advertised by the monitor range descriptor. That I guess can be exposed as a global range in terms of min and max time between frames as a global property of the connector. We dont need the per mode min and max refresh rate to be exposed right? > > > > I'd also encourage using a single unit for all of these values, > > preferably nanoseconds. Absolute times should all be referenced to > > CLOCK_MONOTONIC. > > +1 on everything Keith said. I got somehow dragged in khr vk > discussions around preventing micro-stuttering, and consensus seems to > be that timestamps for scheduling frames is the way to go, most likely > absolute ones (not everything is running Linux unfortunately, so can't > go outright and claim it's guaranteed to be CLOCK_MONOTONIC). > -Daniel And yes I also got consensus from Mesa and media folks about using the absolute timestamp for scheduling the frames and then the driver will modify the vblank logic to "present no earlier than the timestamp" Manasi > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [[RFC]DPU PATCH 3/4] drm/panel: add Innolux TV123WAM eDP panel driver
On Thu, Apr 19, 2018 at 11:26:07PM +0530, Sandeep Panda wrote: > Add support for Innolux TV123WAM 12.3" panel which > is an eDP panel. It seems like you could just use the panel-simple driver, no? Given that this driver doesn't have any power timing, that will probably work better since the warranty won't be voided :) Sean > > Signed-off-by: Sandeep Panda > --- > drivers/gpu/drm/panel/panel-innolux-tv123wam.c | 293 > + > 1 file changed, 293 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-innolux-tv123wam.c > > diff --git a/drivers/gpu/drm/panel/panel-innolux-tv123wam.c > b/drivers/gpu/drm/panel/panel-innolux-tv123wam.c > new file mode 100644 > index 000..5632b02 > --- /dev/null > +++ b/drivers/gpu/drm/panel/panel-innolux-tv123wam.c > @@ -0,0 +1,293 @@ > +/* > + * Copyright (c) 2018, The Linux Foundation. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +struct innolux_edp_2k_panel_desc { > + const struct drm_display_mode *modes; > + unsigned int num_modes; > + u32 bpc; > + u32 bus_flags; > +}; > + > +struct innolux_edp_2k_panel { > + struct drm_panel base; > + bool enabled; > + bool prepared; > + const struct innolux_edp_2k_panel_desc *desc; > + struct regulator *supply; > + struct gpio_desc *enable_gpio; > + struct backlight_device *backlight; > +}; > + > +static const struct drm_display_mode innolux_edp_2k_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 innolux_edp_2k_panel_desc innolux_edp_2k = { > + .modes = &innolux_edp_2k_mode, > + .num_modes = 1, > + .bpc = 8, > + .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE, > +}; > + > +static const struct of_device_id platform_of_match[] = { > + { > + .compatible = "innolux, edp_2k_panel", > + .data = &innolux_edp_2k, > + }, > +}; > + > +static inline struct innolux_edp_2k_panel * > +to_innolux_edp_2k_panel(struct drm_panel *panel) > +{ > + return container_of(panel, struct innolux_edp_2k_panel, base); > +} > + > +static int innolux_edp_2k_panel_disable(struct drm_panel *panel) > +{ > + struct innolux_edp_2k_panel *pdata = to_innolux_edp_2k_panel(panel); > + > + if (!pdata->enabled) > + return 0; > + > + if (pdata->backlight) { > + pdata->backlight->props.power = FB_BLANK_POWERDOWN; > + pdata->backlight->props.state |= BL_CORE_FBBLANK; > + backlight_update_status(pdata->backlight); > + } > + > + pdata->enabled = false; > + > + return 0; > +} > + > +static int innolux_edp_2k_panel_unprepare(struct drm_panel *panel) > +{ > + struct innolux_edp_2k_panel *pdata = to_innolux_edp_2k_panel(panel); > + > + if (!pdata->prepared) > + return 0; > + > + if (pdata->enable_gpio) > + gpiod_set_value_cansleep(pdata->enable_gpio, 0); > + > + regulator_disable(pdata->supply); > + > + pdata->prepared = false; > + > + return 0; > +} > + > +static int innolux_edp_2k_panel_prepare(struct drm_panel *panel) > +{ > + struct innolux_edp_2k_panel *pdata = to_innolux_edp_2k_panel(panel); > + int ret; > + > + if (pdata->prepared) > + return 0; > + > + ret = regulator_enable(pdata->supply); > + if (ret < 0) { > + dev_err(panel->dev, "failed to enable supply: %d\n", ret); > + return ret; > + } > + > + if (pdata->enable_gpio) > + gpiod_set_value_cansleep(pdata->enable_gpio, 1); > + > + pdata->prepared = true; > + > + return 0; > +} > + > +static int innolux_edp_2k_panel_enable(struct drm_panel *panel) > +{ > + struct innolux_edp_2k_panel *pdata = to_innolux_edp_2k_panel(panel); > + > + if (pdata->enabled) > + return 0; > + > + if (pdata->backlight) { > + pdata->backlight->props.state &= ~BL_CORE_FBBLANK; > + pdata->backlight->props.power = FB_BLANK_UNBLANK; > + backlight_update_status(pdata->backlight); > + } > + > + pdata->enabled = true; > + > + return 0; > +} > + > +static int inno
Re: AMD graphics performance regression in 4.15 and later
[+Philip] On 2018-04-20 10:47 AM, Michel Dänzer wrote: > On 2018-04-11 11:37 AM, Christian König wrote: >> Am 11.04.2018 um 06:00 schrieb Gabriel C: >>> 2018-04-09 11:42 GMT+02:00 Christian König >>> : Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: > Hi Christian, > > Thanks for the info. FYI, I've also opened a Firefox bug for that at: > https://bugzilla.mozilla.org/show_bug.cgi?id=1448778 > Feel free to comment since you have a better understanding of what's > going on. > > One last question: right now I'm running 4.15.0 with the "offending" > patch reverted. Is that safe to run or are there possible bad > interactions with other changes. That should work without problems. But I just had another idea as well, if you want you could still test the new code path which will be using in 4.17. >>> While Firefox may do some strange things is not about only Firefox. >>> >>> With your patches my EPYC box is unusable with 4.15++ kernels. >>> The whole Desktop is acting weird. This one is using >>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU. >>> >>> Box is 2 * EPYC 7281 with 128 GB ECC RAM >>> >>> Also a 14C Xeon box with a HD7700 is broken same way. >> The hardware is irrelevant for this. We need to know what software stack >> you use on top of it. >> >> E.g. desktop environment/Mesa and DDX version etc... >> >>> Everything breaks in X .. scrolling , moving windows , flickering etc. >>> >>> >>> reverting f4c809914a7c3e4a59cf543da6c2a15d0f75ee38 and >>> 648bc3574716400acc06f99915815f80d9563783 >>> from an 4.15 kernel makes things work again. >>> >>> Backporting all the detection logic is to invasive, but you could just go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the other code path. Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those. >>> Well you really can't be serious about these suggestions ? Are you ? >>> >>> Telling peoples to #if 0 random code is not a solution. >> That is for testing and not a permanent solution. >> >>> You broke existsing working userland with your patches and at least >>> please fix that for 4.16. >>> >>> I can help testing code for 4.17/++ if you wish but that is >>> *different* storry. >> Please test Alex's amd-staging-drm-next branch from >> git://people.freedesktop.org/~agd5f/linux. > I think we're still missing something here. > > I'm currently running 4.16.2 + the DRM subsystem changes which are going > into 4.17 (so I have the changes Christian is referring to) with a > Kaveri APU, and I'm seeing similar symptoms as described by Jean-Marc. > Some observations: > > Firefox, Thunderbird, or worst, gnome-shell, can freeze for up to on the > order of a minute, during which the kernel is spending most of one > core's cycles inside alloc_pages (__alloc_pages_nodemask to be more > precise), called from ttm_alloc_new_pages. Philip debugged a similar problem with a KFD memory stress test about two weeks ago, where the kernel was seemingly stuck in an infinite loop trying to allocate huge pages. I'm pasting his analysis for the record: > [...] it uses huge_flags GFP_TRANSHUGE to call alloc_pages(), this > seems a corner case inside __alloc_pages_slowpath(), it never exits > but goes to retry path every time. It can reclaim pages and > did_some_progress (as a result, no_progress_loops is reset to 0 every > loop, never reach MAX_RECLAIM_RETRIES) but cannot finish huge page > allocations under this specific memory pressure. As a workaround to unblock our release branch testing we removed transparent huge page allocation from ttm_get_pages. We're seeing this as far back as 4.13 on our release branch. If we're really talking about the same problem, I don't think it's caused by recent page allocator changes, but rather exposed by recent TTM changes. Regards, Felix > > At least in the case of Firefox, this happens due to Mesa internal BO > allocations for glTex(Sub)Image, so it's not obvious that Firefox is > doing something wrong. > > I never noticed this before this week. Before, I was running 4.15.y + > DRM subsystem changes from 4.16. Maybe something has changed in core > code, trying harder to allocate huge pages. > > > Maybe TTM should only try to use any huge pages that happen to be > available, not spend any (/ "too much"?) additional effort trying to > free up huge pages? > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [[RFC]DPU PATCH 1/4] drm/bridge: add support for sn65dsi86 bridge driver
On Thu, Apr 19, 2018 at 11:26:05PM +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). > > Signed-off-by: Sandeep Panda > --- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 690 > ++ What about Kconfig/Makefile? > 1 file changed, 690 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > new file mode 100644 > index 000..a2a95f5 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -0,0 +1,690 @@ > +/* > + * Copyright (c) 2018, The Linux Foundation. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ Use SPDX license > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define SN_BRIDGE_REVISION_ID 0x2 > + > +/* Link Training specific registers */ > +#define SN_DEVICE_REV_REG0x08 > +#define SN_REFCLK_FREQ_REG 0x0A > +#define SN_DSI_LANES_REG 0x10 > +#define SN_DSIA_CLK_FREQ_REG 0x12 > +#define SN_ENH_FRAME_REG 0x5A > +#define SN_SSC_CONFIG_REG0x93 > +#define SN_DATARATE_CONFIG_REG 0x94 > +#define SN_PLL_ENABLE_REG0x0D > +#define SN_SCRAMBLE_CONFIG_REG 0x95 > +#define SN_AUX_WDATA0_REG0x64 > +#define SN_AUX_ADDR_19_16_REG0x74 > +#define SN_AUX_ADDR_15_8_REG 0x75 > +#define SN_AUX_ADDR_7_0_REG 0x76 > +#define SN_AUX_LENGTH_REG0x77 > +#define SN_AUX_CMD_REG 0x78 > +#define SN_ML_TX_MODE_REG0x96 > +/* video config specific registers */ > +#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG0x20 > +#define SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG 0x21 > +#define SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG 0x24 > +#define SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG0x25 > +#define SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG 0x2C > +#define SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG0x2D > +#define SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG 0x30 > +#define SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG0x31 > +#define SN_CHA_HORIZONTAL_BACK_PORCH_REG 0x34 > +#define SN_CHA_VERTICAL_BACK_PORCH_REG 0x36 > +#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG0x38 > +#define SN_CHA_VE
Re: [PATCH] drm/amdgpu: cleanup firmware requests v2
Ping. On 2018-04-17 06:12 PM, Andres Rodriguez wrote: Add a new function amdgpu_ucode_request_firmware() that encapsulates a lot of the common behaviour we have around firmware requests. This is the first step in my quest to get rid of the following annoying messages when my polaris10 boots up: [0.558537] amdgpu :01:00.0: Direct firmware load for amdgpu/polaris10_pfp_2.bin failed with error -2 [0.558551] amdgpu :01:00.0: Direct firmware load for amdgpu/polaris10_me_2.bin failed with error -2 [0.558562] amdgpu :01:00.0: Direct firmware load for amdgpu/polaris10_ce_2.bin failed with error -2 [0.558580] amdgpu :01:00.0: Direct firmware load for amdgpu/polaris10_mec_2.bin failed with error -2 [0.558619] amdgpu :01:00.0: Direct firmware load for amdgpu/polaris10_mec2_2.bin failed with error -2 v2: make amdgpu_ucode_validate file scope only add kernel-doc for amdgpu_ucode_request_firmware() Signed-off-by: Andres Rodriguez --- Sorry for the quick V2, noticed some docs might help and that _validate() could be reduced in scope. Pasting my old message again just in case. Hey Christian, Wanted to go through a cleanup of the ucode loading in amdgpu to facilitate some of our heated discussions :) For now, functionality should remain the same. Once _nowarn() lands we can change amdgpu_ucode_request_firmware() with either: Alternative A: - err = request_firmware(&loaded_fw, name, adev->dev); + err = request_firmware_nowarn(&loaded_fw, name, adev->dev); Alternative B: - err = request_firmware(&loaded_fw, name, adev->dev); + if (optional) + err = request_firmware_nowarn(&loaded_fw, name, adev->dev); + else + err = request_firmware(&loaded_fw, name, adev->dev); I prefer A, but I'm not opposed to B. I'll leave it up to you. Regards, Andres drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 14 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 + drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 74 --- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 16 + drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 16 + drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 16 + drivers/gpu/drm/amd/amdgpu/ci_dpm.c| 15 +--- drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 5 +- drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 19 ++--- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 30 ++-- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 112 + drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 39 +++--- drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 17 + drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 14 +--- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 14 +--- drivers/gpu/drm/amd/amdgpu/psp_v10_0.c | 18 + drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 15 +--- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 6 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 6 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 7 +- drivers/gpu/drm/amd/amdgpu/si_dpm.c| 16 + 22 files changed, 164 insertions(+), 325 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c index a8a942c60ea2..347ab1710523 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c @@ -402,19 +402,9 @@ static int amdgpu_cgs_get_firmware_info(struct cgs_device *cgs_device, return -EINVAL; } - err = request_firmware(&adev->pm.fw, fw_name, adev->dev); - if (err) { - DRM_ERROR("Failed to request firmware\n"); + err = amdgpu_ucode_request_firmware(adev, &adev->pm.fw, fw_name, false); + if (err) return err; - } - - err = amdgpu_ucode_validate(adev->pm.fw); - if (err) { - DRM_ERROR("Failed to load firmware \"%s\"", fw_name); - release_firmware(adev->pm.fw); - adev->pm.fw = NULL; - return err; - } if (adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) { ucode = &adev->firmware.ucode[AMDGPU_UCODE_ID_SMC]; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index abc33464959e..967e14f14abc 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -1355,20 +1355,10 @@ static int amdgpu_device_parse_gpu_info_fw(struct amdgpu_device *adev) } snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_gpu_info.bin", chip_name); - err = request_firmware(&adev->firmware.gpu_info_fw, fw_nam
[PATCH] drm/bridge: vga-dac: Fix edid memory leak
edid should be freed once it's finished being used. Fixes: 56fe8b6f4991 ("drm/bridge: Add RGB to VGA bridge support") Cc: Rob Herring Cc: Sean Paul Cc: Maxime Ripard Cc: Archit Taneja Cc: Andrzej Hajda Cc: Laurent Pinchart Cc: # v4.9+ Signed-off-by: Sean Paul --- drivers/gpu/drm/bridge/dumb-vga-dac.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c index 498d5948d1a8..9837c8d69e69 100644 --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c @@ -56,7 +56,9 @@ static int dumb_vga_get_modes(struct drm_connector *connector) } drm_mode_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + ret = drm_add_edid_modes(connector, edid); + kfree(edid); + return ret; fallback: /* -- 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 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output
https://bugs.freedesktop.org/show_bug.cgi?id=106159 --- Comment #3 from Joel Sass --- Created attachment 138959 --> https://bugs.freedesktop.org/attachment.cgi?id=138959&action=edit lshw output -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output
https://bugs.freedesktop.org/show_bug.cgi?id=106159 --- Comment #2 from Joel Sass --- Created attachment 138958 --> https://bugs.freedesktop.org/attachment.cgi?id=138958&action=edit dmesg output -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output
https://bugs.freedesktop.org/show_bug.cgi?id=106159 --- Comment #1 from Joel Sass --- Created attachment 138957 --> https://bugs.freedesktop.org/attachment.cgi?id=138957&action=edit Xorg.0.log -- 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 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output
https://bugs.freedesktop.org/show_bug.cgi?id=106159 Bug ID: 106159 Summary: When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: sass.j...@gmail.com Created attachment 138956 --> https://bugs.freedesktop.org/attachment.cgi?id=138956&action=edit dpkg -l |grep mesa When connecting a displayport monitor to an active DP hub with working outputs, my workstation experiences a hard freeze requiring a cold reboot. Network services stop responding, including ping and SSH. root@nope:~# uname -a Linux nope 4.16.2+ #1 SMP Fri Apr 13 17:51:14 CEST 2018 x86_64 x86_64 x86_64 GNU/Linux root@nope:~# lsmod |grep -i amdgpu amdgpu 2695168 2 chash 16384 1 amdgpu i2c_algo_bit 16384 1 amdgpu gpu_sched 20480 1 amdgpu ttm94208 1 amdgpu drm_kms_helper143360 1 amdgpu drm 348160 6 amdgpu,gpu_sched,ttm,drm_kms_helper Mesa drivers from padoka PPA -- 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: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake
>-Original Message- >From: Vivi, Rodrigo >Sent: Friday, April 20, 2018 11:04 AM >To: Jani Nikula >Cc: Srivatsa, Anusha ; Ian W MORRISON >; airl...@linux.ie; Greg KH >; intel-...@lists.freedesktop.org; linux- >ker...@vger.kernel.org; sta...@vger.kernel.org; dri- >de...@lists.freedesktop.org; Wajdeczko, Michal >Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for >Geminilake > >On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote: >> On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: >> >>-Original Message- >> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >> >>Sent: Wednesday, April 11, 2018 5:27 AM >> >>To: Ian W MORRISON >> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha >> >>; Wajdeczko, Michal >> >>; Greg KH ; >> >>airl...@linux.ie; joonas.lahti...@linux.intel.com; >> >>linux-ker...@vger.kernel.org; sta...@vger.kernel.org; >> >>intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org >> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE >> >>for Geminilake >> >> >> >>On Wed, 11 Apr 2018, Ian W MORRISON wrote: >> >>> >> >>> >> >> NAK on indiscriminate Cc: stable. There are zero guarantees that >> older kernels will work with whatever firmware you throw at them. >> >> >>> >> >>> I included 'Cc: stable' so the patch would get added to the v4.16 >> >>> and >> >>> v4.15 kernels which I have tested with the patch. I found that >> >>> earlier kernels didn't support the 'linux-firmware' package >> >>> required to get wifi working on Intel's new Gemini Lake NUC. >> >> >> >>You realize that this patch should have nothing to do with wifi? >> >> >> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please >> >>indicate the specific versions of stable it is appropriate for. >> > >> > Hi Jani, >> > >> > The stable kernel version is 4.12 and beyond. >> > It is appropriate to add the CC: stable in my opinion >> >> Who tested the firmware with v4.12 and later? We only have the CI >> results against *current* drm-tip. We don't even know about v4.16. >> > >I understand your concerns, but the problem was that our old process was a bit >(lot?) messed and there was the unreliable time until the firmware really >lands on >linux-firmware.git. So MODULE_FIRMWARE call was only added after firmware >was really there on firmware repository but it wasn't about the testing. > >In other words, the bump version patch was merged after tested, but >MODULE_FIRMWARE was left behind because firmware blob took a while to get >pulled into linux-firmware.git and we end up forgetting to add it there. > >In my opinion it should be safe to add the MODULE_FIRMWARE there based on >the tests from when the version was bumped. Luis, Elio, can you guys confirm that this firmware is tested and healthy? And also, give a tested-by to this patch please? Thanks, Anusha >> I'm not going to ack and take responsibility for the stable backports >> unless someone actually comes forward with credible Tested-bys. >> >> BR, >> Jani. >> >> >> > >> > Anusha >> >>BR, >> >>Jani. >> >> >> >>> >> >> PS. How is this a "RESEND"? I haven't seen this before. >> >> >>> >> >>> It is a 'RESEND' for that very reason. I initially sent the patch >> >>> to the same people as a similar patch >> >>> (https://patchwork.kernel.org/patch/10143637/) however after >> >>> realising this omitted required addresses I added them and resent the >patch. >> >>> >> >>> Best regards, >> >>> Ian >> >> >> >>-- >> >>Jani Nikula, Intel Open Source Technology Center >> >> -- >> Jani Nikula, Intel Open Source Technology Center >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103234] KWin crashed when Alt+Tab-ing through open windows
https://bugs.freedesktop.org/show_bug.cgi?id=103234 --- Comment #20 from bernhardu --- Got already commited in master branch: https://cgit.freedesktop.org/mesa/mesa/commit/src/mesa/state_tracker/st_draw.c?id=f7542175178e724510c7918edfe09ba33c7a But not yet in 17.3 or 18.0 branch. -- 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 103234] KWin crashed when Alt+Tab-ing through open windows
https://bugs.freedesktop.org/show_bug.cgi?id=103234 bernhardu changed: What|Removed |Added CC||bernha...@mailbox.org --- Comment #19 from bernhardu --- *** Bug 106153 has been marked as a duplicate of this bug. *** -- 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 106153] KWin crashed when Alt+Tab-ing through open windows
https://bugs.freedesktop.org/show_bug.cgi?id=106153 bernhardu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from bernhardu --- *** This bug has been marked as a duplicate of bug 103234 *** -- 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 106153] KWin crashed when Alt+Tab-ing through open windows
https://bugs.freedesktop.org/show_bug.cgi?id=106153 --- Comment #2 from bernhardu --- Being able to reproduce it I built a set of mesa packages with the patch from #103234. By adding a fprintf before the return I can confirm that this patch avoids the crash. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake
On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote: > On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: > >>-Original Message- > >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >>Sent: Wednesday, April 11, 2018 5:27 AM > >>To: Ian W MORRISON > >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha > >>; Wajdeczko, Michal > >>; Greg KH ; > >>airl...@linux.ie; joonas.lahti...@linux.intel.com; > >>linux-ker...@vger.kernel.org; > >>sta...@vger.kernel.org; intel-...@lists.freedesktop.org; dri- > >>de...@lists.freedesktop.org > >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for > >>Geminilake > >> > >>On Wed, 11 Apr 2018, Ian W MORRISON wrote: > >>> > >>> > > NAK on indiscriminate Cc: stable. There are zero guarantees that > older kernels will work with whatever firmware you throw at them. > > >>> > >>> I included 'Cc: stable' so the patch would get added to the v4.16 and > >>> v4.15 kernels which I have tested with the patch. I found that earlier > >>> kernels didn't support the 'linux-firmware' package required to get > >>> wifi working on Intel's new Gemini Lake NUC. > >> > >>You realize that this patch should have nothing to do with wifi? > >> > >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please indicate > >>the specific > >>versions of stable it is appropriate for. > > > > Hi Jani, > > > > The stable kernel version is 4.12 and beyond. > > It is appropriate to add the CC: stable in my opinion > > Who tested the firmware with v4.12 and later? We only have the CI > results against *current* drm-tip. We don't even know about v4.16. > I understand your concerns, but the problem was that our old process was a bit (lot?) messed and there was the unreliable time until the firmware really lands on linux-firmware.git. So MODULE_FIRMWARE call was only added after firmware was really there on firmware repository but it wasn't about the testing. In other words, the bump version patch was merged after tested, but MODULE_FIRMWARE was left behind because firmware blob took a while to get pulled into linux-firmware.git and we end up forgetting to add it there. In my opinion it should be safe to add the MODULE_FIRMWARE there based on the tests from when the version was bumped. > I'm not going to ack and take responsibility for the stable backports > unless someone actually comes forward with credible Tested-bys. > > BR, > Jani. > > > > > > Anusha > >>BR, > >>Jani. > >> > >>> > > PS. How is this a "RESEND"? I haven't seen this before. > > >>> > >>> It is a 'RESEND' for that very reason. I initially sent the patch to > >>> the same people as a similar patch > >>> (https://patchwork.kernel.org/patch/10143637/) however after realising > >>> this omitted required addresses I added them and resent the patch. > >>> > >>> Best regards, > >>> Ian > >> > >>-- > >>Jani Nikula, Intel Open Source Technology Center > > -- > Jani Nikula, Intel Open Source Technology Center > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/vmwgfx: Drop DRM_CONTROL_ALLOW
On 04/20/2018 08:51 AM, Daniel Vetter wrote: Control nodes are no more! Signed-off-by: Daniel Vetter Cc: VMware Graphics Cc: Sinclair Yeh Cc: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 70e1a8820a7c..97f37c3c16f2 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -159,14 +159,14 @@ static const struct drm_ioctl_desc vmw_ioctls[] = { DRM_RENDER_ALLOW), VMW_IOCTL_DEF(VMW_CURSOR_BYPASS, vmw_kms_cursor_bypass_ioctl, - DRM_MASTER | DRM_CONTROL_ALLOW), + DRM_MASTER), VMW_IOCTL_DEF(VMW_CONTROL_STREAM, vmw_overlay_ioctl, - DRM_MASTER | DRM_CONTROL_ALLOW), + DRM_MASTER), VMW_IOCTL_DEF(VMW_CLAIM_STREAM, vmw_stream_claim_ioctl, - DRM_MASTER | DRM_CONTROL_ALLOW), + DRM_MASTER), VMW_IOCTL_DEF(VMW_UNREF_STREAM, vmw_stream_unref_ioctl, - DRM_MASTER | DRM_CONTROL_ALLOW), + DRM_MASTER), VMW_IOCTL_DEF(VMW_CREATE_CONTEXT, vmw_context_define_ioctl, DRM_AUTH | DRM_RENDER_ALLOW), Reviewed-by: Thomas Hellstrom I can queue this on the next -fixes pull. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106153] KWin crashed when Alt+Tab-ing through open windows
https://bugs.freedesktop.org/show_bug.cgi?id=106153 --- Comment #1 from bernhardu --- A little addition: Looks like I can reliably reproduce by just pressing alt+tab and holding it for some seconds, while on the left the window previews are iterating through. And it looks like the 3.5 core file is not coming from kind of a memory limit, because in htop a such crashed process shows: VIRT: 4452M RES: 216M SHR: 118M And gcore produces a 3.8 GB file of it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: remove register logging
I'm not aware of any case where tracing GPU register manipulation at the kernel level would have been useful. It only adds more indirections and adds to the code size. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/Kconfig | 8 -- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 51 --- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 5 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 ++- drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 4 +-- 5 files changed, 5 insertions(+), 67 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig index e5bfeca361bd..041a77e400d4 100644 --- a/drivers/gpu/drm/etnaviv/Kconfig +++ b/drivers/gpu/drm/etnaviv/Kconfig @@ -22,11 +22,3 @@ config DRM_ETNAVIV_THERMAL help Compile in support for thermal throttling. Say Y unless you want to risk burning your SoC. - -config DRM_ETNAVIV_REGISTER_LOGGING - bool "enable ETNAVIV register logging" - depends on DRM_ETNAVIV - help - Compile in support for logging register reads/writes in a format - that can be parsed by envytools demsm tool. If enabled, register - logging can be switched on via etnaviv.reglog=y module param. diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c index ab50090d066c..0aa543d75953 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c @@ -25,57 +25,6 @@ #include "etnaviv_mmu.h" #include "etnaviv_perfmon.h" -#ifdef CONFIG_DRM_ETNAVIV_REGISTER_LOGGING -static bool reglog; -MODULE_PARM_DESC(reglog, "Enable register read/write logging"); -module_param(reglog, bool, 0600); -#else -#define reglog 0 -#endif - -void __iomem *etnaviv_ioremap(struct platform_device *pdev, const char *name, - const char *dbgname) -{ - struct resource *res; - void __iomem *ptr; - - if (name) - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name); - else - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - - ptr = devm_ioremap_resource(&pdev->dev, res); - if (IS_ERR(ptr)) { - dev_err(&pdev->dev, "failed to ioremap %s: %ld\n", name, - PTR_ERR(ptr)); - return ptr; - } - - if (reglog) - dev_printk(KERN_DEBUG, &pdev->dev, "IO:region %s 0x%p %08zx\n", - dbgname, ptr, (size_t)resource_size(res)); - - return ptr; -} - -void etnaviv_writel(u32 data, void __iomem *addr) -{ - if (reglog) - printk(KERN_DEBUG "IO:W %p %08x\n", addr, data); - - writel(data, addr); -} - -u32 etnaviv_readl(const void __iomem *addr) -{ - u32 val = readl(addr); - - if (reglog) - printk(KERN_DEBUG "IO:R %p %08x\n", addr, val); - - return val; -} - /* * DRM operations: */ diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h b/drivers/gpu/drm/etnaviv/etnaviv_drv.h index ddb17ee565e9..56be51c13c49 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h @@ -101,11 +101,6 @@ void etnaviv_gem_describe_objects(struct etnaviv_drm_private *priv, struct seq_file *m); #endif -void __iomem *etnaviv_ioremap(struct platform_device *pdev, const char *name, - const char *dbgname); -void etnaviv_writel(u32 data, void __iomem *addr); -u32 etnaviv_readl(const void __iomem *addr); - #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__) #define VERB(fmt, ...) if (0) DRM_DEBUG(fmt"\n", ##__VA_ARGS__) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index 8a88799bf79b..08c587547f19 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -1735,6 +1735,7 @@ static int etnaviv_gpu_platform_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct etnaviv_gpu *gpu; + struct resource *res; int err; gpu = devm_kzalloc(dev, sizeof(*gpu), GFP_KERNEL); @@ -1746,7 +1747,8 @@ static int etnaviv_gpu_platform_probe(struct platform_device *pdev) mutex_init(&gpu->fence_idr_lock); /* Map registers: */ - gpu->mmio = etnaviv_ioremap(pdev, NULL, dev_name(gpu->dev)); + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + gpu->mmio = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(gpu->mmio)) return PTR_ERR(gpu->mmio); diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h index 3c3005501846..6052093d00b2 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h @@ -161,12 +161,12 @@ struct etnaviv_gpu { static inline void gpu_write(struct etnaviv_gpu *gpu, u32 reg, u32 data) { - etnaviv_writel(data, gpu->mmio + reg); + writel(data, gpu->mmio + reg); } static inline u32
[PATCH 1/2] drm/etnaviv: switch MMU page tables to writecombine memory
We are likely to write multiple page entries at once and already ensure proper write buffer flushing before GPU submit, so this improves CPU time usage in the submit path without any downsides. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_iommu.c| 27 +-- drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 74 +++--- 2 files changed, 51 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c index 4b9b11ca6f03..65121b93c78f 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c @@ -47,7 +47,7 @@ static int __etnaviv_iommu_init(struct etnaviv_iommuv1_domain *etnaviv_domain) u32 *p; int i; - etnaviv_domain->base.bad_page_cpu = dma_alloc_coherent( + etnaviv_domain->base.bad_page_cpu = dma_alloc_writecombine( etnaviv_domain->base.dev, SZ_4K, &etnaviv_domain->base.bad_page_dma, @@ -60,13 +60,14 @@ static int __etnaviv_iommu_init(struct etnaviv_iommuv1_domain *etnaviv_domain) *p++ = 0xdead55aa; etnaviv_domain->pgtable_cpu = - dma_alloc_coherent(etnaviv_domain->base.dev, PT_SIZE, - &etnaviv_domain->pgtable_dma, - GFP_KERNEL); + dma_alloc_writecombine(etnaviv_domain->base.dev, + PT_SIZE, + &etnaviv_domain->pgtable_dma, + GFP_KERNEL); if (!etnaviv_domain->pgtable_cpu) { - dma_free_coherent(etnaviv_domain->base.dev, SZ_4K, - etnaviv_domain->base.bad_page_cpu, - etnaviv_domain->base.bad_page_dma); + dma_free_writecombine(etnaviv_domain->base.dev, SZ_4K, + etnaviv_domain->base.bad_page_cpu, + etnaviv_domain->base.bad_page_dma); return -ENOMEM; } @@ -81,13 +82,13 @@ static void etnaviv_iommuv1_domain_free(struct etnaviv_iommu_domain *domain) struct etnaviv_iommuv1_domain *etnaviv_domain = to_etnaviv_domain(domain); - dma_free_coherent(etnaviv_domain->base.dev, PT_SIZE, - etnaviv_domain->pgtable_cpu, - etnaviv_domain->pgtable_dma); + dma_free_writecombine(etnaviv_domain->base.dev, PT_SIZE, + etnaviv_domain->pgtable_cpu, + etnaviv_domain->pgtable_dma); - dma_free_coherent(etnaviv_domain->base.dev, SZ_4K, - etnaviv_domain->base.bad_page_cpu, - etnaviv_domain->base.bad_page_dma); + dma_free_writecombine(etnaviv_domain->base.dev, SZ_4K, + etnaviv_domain->base.bad_page_cpu, + etnaviv_domain->base.bad_page_dma); kfree(etnaviv_domain); } diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c index 9752dbd5d28b..540962f24d0f 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c @@ -104,7 +104,7 @@ static int etnaviv_iommuv2_init(struct etnaviv_iommuv2_domain *etnaviv_domain) int ret, i, j; /* allocate scratch page */ - etnaviv_domain->base.bad_page_cpu = dma_alloc_coherent( + etnaviv_domain->base.bad_page_cpu = dma_alloc_writecombine( etnaviv_domain->base.dev, SZ_4K, &etnaviv_domain->base.bad_page_dma, @@ -117,19 +117,19 @@ static int etnaviv_iommuv2_init(struct etnaviv_iommuv2_domain *etnaviv_domain) for (i = 0; i < SZ_4K / 4; i++) *p++ = 0xdead55aa; - etnaviv_domain->pta_cpu = dma_alloc_coherent(etnaviv_domain->base.dev, -SZ_4K, -&etnaviv_domain->pta_dma, -GFP_KERNEL); + etnaviv_domain->pta_cpu = + dma_alloc_writecombine(etnaviv_domain->base.dev, + SZ_4K, &etnaviv_domain->pta_dma, + GFP_KERNEL); if (!etnaviv_domain->pta_cpu) { ret = -ENOMEM; goto fail_mem; } - etnaviv_domain->mtlb_cpu = dma_alloc_coherent(etnaviv_domain->base.dev, - SZ_4K, -
[PATCH 2/2] drm/etnaviv: mmuv2: allocate 2nd level page tables on demand
With etnaviv not being tied into the IOMMU framework anymore, the MMU functions will only be called under sleeping locks. Thus we are able to allocate the memory for the 2nd level page tables on demand without having to deal with memory allocation in atomic context. This speeds up driver intitialization on MMUv2 GPU cores, as we don't need to preallocate all the page table memory and also reduces memory consumption for most workloads, as most of them won't use the full GPU virtual address space. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 59 +++--- 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c index 540962f24d0f..c0d7e5244102 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c @@ -49,6 +49,7 @@ struct etnaviv_iommuv2_domain { /* S(lave) TLB aka second level pagetable */ u32 *stlb_cpu[1024]; dma_addr_t stlb_dma[1024]; + DECLARE_BITMAP(stlb_allocated, 1024); }; static struct etnaviv_iommuv2_domain * @@ -57,13 +58,35 @@ to_etnaviv_domain(struct etnaviv_iommu_domain *domain) return container_of(domain, struct etnaviv_iommuv2_domain, base); } +static int +etnaviv_iommuv2_ensure_stlb(struct etnaviv_iommuv2_domain *etnaviv_domain, + int stlb) +{ + if (test_bit(stlb, etnaviv_domain->stlb_allocated)) + return 0; + + etnaviv_domain->stlb_cpu[stlb] = + dma_alloc_writecombine(etnaviv_domain->base.dev, + SZ_4K, + &etnaviv_domain->stlb_dma[stlb], + GFP_KERNEL); + + if (!etnaviv_domain->stlb_cpu[stlb]) + return -ENOMEM; + + __set_bit(stlb, etnaviv_domain->stlb_allocated); + etnaviv_domain->mtlb_cpu[stlb] = etnaviv_domain->stlb_dma[stlb] | + MMUv2_PTE_PRESENT; + return 0; +} + static int etnaviv_iommuv2_map(struct etnaviv_iommu_domain *domain, unsigned long iova, phys_addr_t paddr, size_t size, int prot) { struct etnaviv_iommuv2_domain *etnaviv_domain = to_etnaviv_domain(domain); - int mtlb_entry, stlb_entry; + int mtlb_entry, stlb_entry, ret; u32 entry = (u32)paddr | MMUv2_PTE_PRESENT; if (size != SZ_4K) @@ -75,6 +98,10 @@ static int etnaviv_iommuv2_map(struct etnaviv_iommu_domain *domain, mtlb_entry = (iova & MMUv2_MTLB_MASK) >> MMUv2_MTLB_SHIFT; stlb_entry = (iova & MMUv2_STLB_MASK) >> MMUv2_STLB_SHIFT; + ret = etnaviv_iommuv2_ensure_stlb(etnaviv_domain, mtlb_entry); + if (ret) + return ret; + etnaviv_domain->stlb_cpu[mtlb_entry][stlb_entry] = entry; return 0; @@ -101,7 +128,7 @@ static size_t etnaviv_iommuv2_unmap(struct etnaviv_iommu_domain *domain, static int etnaviv_iommuv2_init(struct etnaviv_iommuv2_domain *etnaviv_domain) { u32 *p; - int ret, i, j; + int ret, i; /* allocate scratch page */ etnaviv_domain->base.bad_page_cpu = dma_alloc_writecombine( @@ -135,25 +162,6 @@ static int etnaviv_iommuv2_init(struct etnaviv_iommuv2_domain *etnaviv_domain) goto fail_mem; } - /* pre-populate STLB pages (may want to switch to on-demand later) */ - for (i = 0; i < MMUv2_MAX_STLB_ENTRIES; i++) { - etnaviv_domain->stlb_cpu[i] = - dma_alloc_writecombine(etnaviv_domain->base.dev, - SZ_4K, - &etnaviv_domain->stlb_dma[i], - GFP_KERNEL); - if (!etnaviv_domain->stlb_cpu[i]) { - ret = -ENOMEM; - goto fail_mem; - } - p = etnaviv_domain->stlb_cpu[i]; - for (j = 0; j < SZ_4K / 4; j++) - *p++ = MMUv2_PTE_EXCEPTION; - - etnaviv_domain->mtlb_cpu[i] = etnaviv_domain->stlb_dma[i] | - MMUv2_PTE_PRESENT; - } - return 0; fail_mem: @@ -172,13 +180,6 @@ static int etnaviv_iommuv2_init(struct etnaviv_iommuv2_domain *etnaviv_domain) etnaviv_domain->mtlb_cpu, etnaviv_domain->mtlb_dma); - for (i = 0; i < MMUv2_MAX_STLB_ENTRIES; i++) { - if (etnaviv_domain->stlb_cpu[i]) - dma_free_writecombine(etnaviv_domain->base.dev, SZ_4K, - etnaviv_domain->stlb_cpu[i], -
[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5
https://bugzilla.kernel.org/show_bug.cgi?id=199101 --- Comment #20 from Alex Deucher (alexdeuc...@gmail.com) --- The revert is cc'ed to stable so it will show up in the 4.16 stable tree as well. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/7] drm/i2c: tda9950: add CEC driver
On 04/20/2018 05:31 PM, Russell King - ARM Linux wrote: > Hi Hans, > > Any comments? I have been traveling and haven't had time to look at this. Next week will be busy as well, but I expect to be able to look at it the week after that. I remember from the previous series that I couldn't test it with my BeagleBone Black board (the calibration gpio had to switch from in to out but it wasn't allowed since it had an associated irq). That's still a problem? I didn't see any changes in that area when I did a quick scan. Regards, Hans > > Thanks. > > On Mon, Apr 09, 2018 at 01:16:32PM +0100, Russell King wrote: >> Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device, >> but is also integrated into HDMI transceivers such as the TDA9989 and >> TDA19989. >> >> The TDA9950 contains a command processor which handles retransmissions >> and the low level bus protocol. The driver just has to read and write >> the messages, and handle error conditions. >> >> Signed-off-by: Russell King >> --- >> drivers/gpu/drm/i2c/Kconfig | 5 + >> drivers/gpu/drm/i2c/Makefile | 1 + >> drivers/gpu/drm/i2c/tda9950.c | 509 >> ++ >> include/linux/platform_data/tda9950.h | 16 ++ >> 4 files changed, 531 insertions(+) >> create mode 100644 drivers/gpu/drm/i2c/tda9950.c >> create mode 100644 include/linux/platform_data/tda9950.h >> >> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig >> index a6c92beb410a..3a232f5ff0a1 100644 >> --- a/drivers/gpu/drm/i2c/Kconfig >> +++ b/drivers/gpu/drm/i2c/Kconfig >> @@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X >> help >>Support for NXP Semiconductors TDA998X HDMI encoders. >> >> +config DRM_I2C_NXP_TDA9950 >> +tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC" >> +select CEC_NOTIFIER >> +select CEC_CORE >> + >> endmenu >> diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile >> index b20100c18ffb..a962f6f08568 100644 >> --- a/drivers/gpu/drm/i2c/Makefile >> +++ b/drivers/gpu/drm/i2c/Makefile >> @@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o >> >> tda998x-y := tda998x_drv.o >> obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o >> +obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o >> diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c >> new file mode 100644 >> index ..3f7396caad48 >> --- /dev/null >> +++ b/drivers/gpu/drm/i2c/tda9950.c >> @@ -0,0 +1,509 @@ >> +/* >> + * TDA9950 Consumer Electronics Control driver >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + * >> + * The NXP TDA9950 implements the HDMI Consumer Electronics Control >> + * interface. The host interface is similar to a mailbox: the data >> + * registers starting at REG_CDR0 are written to send a command to the >> + * internal CPU, and replies are read from these registers. >> + * >> + * As the data registers represent a mailbox, they must be accessed >> + * as a single I2C transaction. See the TDA9950 data sheet for details. >> + */ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +enum { >> +REG_CSR = 0x00, >> +CSR_BUSY = BIT(7), >> +CSR_INT = BIT(6), >> +CSR_ERR = BIT(5), >> + >> +REG_CER = 0x01, >> + >> +REG_CVR = 0x02, >> + >> +REG_CCR = 0x03, >> +CCR_RESET = BIT(7), >> +CCR_ON= BIT(6), >> + >> +REG_ACKH = 0x04, >> +REG_ACKL = 0x05, >> + >> +REG_CCONR = 0x06, >> +CCONR_ENABLE_ERROR = BIT(4), >> +CCONR_RETRY_MASK = 7, >> + >> +REG_CDR0 = 0x07, >> + >> +CDR1_REQ = 0x00, >> +CDR1_CNF = 0x01, >> +CDR1_IND = 0x81, >> +CDR1_ERR = 0x82, >> +CDR1_IER = 0x83, >> + >> +CDR2_CNF_SUCCESS= 0x00, >> +CDR2_CNF_OFF_STATE = 0x80, >> +CDR2_CNF_BAD_REQ= 0x81, >> +CDR2_CNF_CEC_ACCESS = 0x82, >> +CDR2_CNF_ARB_ERROR = 0x83, >> +CDR2_CNF_BAD_TIMING = 0x84, >> +CDR2_CNF_NACK_ADDR = 0x85, >> +CDR2_CNF_NACK_DATA = 0x86, >> +}; >> + >> +struct tda9950_priv { >> +struct i2c_client *client; >> +struct device *hdmi; >> +struct cec_adapter *adap; >> +struct tda9950_glue *glue; >> +u16 addresses; >> +struct cec_msg rx_msg; >> +struct cec_notifier *notify; >> +bool open; >> +}; >> + >> +static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, >> int cnt) >> +{ >> +struct i2c_msg msg; >> +u8 buf[cnt + 1]; >> +int ret; >> + >> +buf[0] = addr; >> +memcpy(buf + 1, p, cnt); >> + >> +msg.addr = client->addr; >> +msg.flags = 0; >> +msg.len = cnt + 1; >> +msg.buf = buf; >> + >> +dev_dbg(&client->dev, "wr 0x%02x: %*ph\n", addr, cnt, p); >> + >> +ret = i2c_transfer(client->adapter, &msg, 1); >> +
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #39 from MirceaKitsune --- Created attachment 138951 --> https://bugs.freedesktop.org/attachment.cgi?id=138951&action=edit journalctl --since yesterday -- 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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #37 from MirceaKitsune --- I have just finished preforming the first new test. First of all I must say I'm utterly amazed at the variability of this issue: Last week when I played Xonotic with "r_shadows 2", the freeze occurred in just a few seconds or minutes at most... today after a few openSUSE Tumbleweed snapshots, I was able to play for over 60 minutes even with this option enabled! It's clear that package updates are causing the lockup to vary unpredictably. In any case, I can confirm the SysRq keys also stop functioning after the freeze: I tried REISUB for a few minutes, but there was no form of response. I also kept both NumLock and CapsLock enabled during the game to better see how they behave in a crash. 5 seconds after the freeze, they both turned off... that is the very last noticeable activity of the system. None the less I will attach the logs you suggested below, just in case they still captured something. Please let me know exactly what you believe I should try next, in as much detail as possible since I'm unfamiliar with the other tests you hinted to in our last conversation (eg: apitrace). -- 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: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag
On Fri, Apr 20, 2018 at 05:46:25AM -0700, Christoph Hellwig wrote: > On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote: > > > > What we need is an sg_alloc_table_from_resources(dev, resources, > > > > num_resources) which does the handling common to all drivers. > > > A structure that contains > > > > > > {page,offset,len} + {dma_addr+dma_len} > > > > > > is not a good container for storing > > > > > > {virt addr, dma_addr, len} > > > > > > no matter what interface you build arond it. > > > > Why not? I mean at least for my use case we actually don't need the virtual > > address. > > If you don't need the virtual address you need scatterlist even list. > > > What we need is {dma_addr+dma_len} in a consistent interface which can come > > from both {page,offset,len} as well as {resource, len}. > > Ok. > > > What I actually don't need is separate handling for system memory and > > resources, but that would we get exactly when we don't use sg_table. > > At the very lowest level they will need to be handled differently for > many architectures, the questions is at what point we'll do the > branching out. Having at least struct page also in that list with (dma_addr_t, lenght) pairs has a bunch of benefits for drivers in unifying buffer handling code. You just pass that one single list around, use the dma_addr_t side for gpu access (generally bashing it into gpu ptes). And the struct page (if present) for cpu access, using kmap or vm_insert_*. We generally ignore virt, if we do need a full mapping then we construct a vmap for that buffer of our own. If (and that would be serious amounts of work all over the tree, with lots of drivers) we come up with a new struct for gpu buffers, then I'd also add "force page alignement for everything" to the requirements list. That's another mismatch we have, since gpu buffer objects (and dma-buf) are always full pages. That mismatch motived the addition of the page-oriented sg iterators. So maybe a list of (struct page *, dma_addr_t, num_pages) would suit best, with struct page * being optional (if it's a resource, or something else that the kernel core mm isn't aware of). But that only has benefits if we really roll it out everywhere, in all the subsystems and drivers, since if we don't we've made the struct pages ** <-> sgt conversion fun only worse by adding a 3 representation of gpu buffer object backing storage. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST
On Thursday, April 05, 2018 04:29:42 PM Mauro Carvalho Chehab wrote: > This driver builds cleanly with COMPILE_TEST, and it is > needed in order to allow building drivers/media omap2 > driver. > > So, change the logic there to allow building it. > > Signed-off-by: Mauro Carvalho Chehab This change has broken build on OF=n && COMPILE_TEST=y configs: https://patchwork.kernel.org/patch/10352465/ [ This is not a problem when compiling for OMAP2 because it depends on ARM Multiplatform support which (indirectly) selects OF. ] Also I would really prefer that people won't merge fbdev related patches without my ACK and I see this patch in -next coming from one of your trees.. > --- > drivers/video/fbdev/omap2/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/fbdev/omap2/Kconfig > b/drivers/video/fbdev/omap2/Kconfig > index 0921c4de8407..82008699d253 100644 > --- a/drivers/video/fbdev/omap2/Kconfig > +++ b/drivers/video/fbdev/omap2/Kconfig > @@ -1,4 +1,4 @@ > -if ARCH_OMAP2PLUS > +if ARCH_OMAP2PLUS || COMPILE_TEST > > source "drivers/video/fbdev/omap2/omapfb/Kconfig" Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v5 1/2] drm: content-type property for HDMI connector
On Fri, Apr 20, 2018 at 08:31:56AM +, Lisovskiy, Stanislav wrote: > > > From: Daniel Vetter [daniel.vet...@ffwll.ch] on behalf of Daniel Vetter > [dan...@ffwll.ch] > > > The property documentation to tie all the bits together (property, helper, > > internals) is missing. It should be in > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties > > > Probably want to start with an intro-paragraph for HDMI properties > > (someone should document the broadcast prop too eventually). > > > Pls also make sure the resulting docs look pretty and that it's all > > nicely hyperlink: > > >$ make htmldocs > > Thank you for your feedback. The thing is that I actually looked into docs, > but I think there should have been already some HDMI specific property > documentation, > because this one is actually not a standard connector property, so I've added > it only to > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#existing-kms-properties > table This table is seriously deprecated, because it's unreadable and unmaintainable. Quoting from the docs: "Because this table is very unwieldy, do not add any new properties here. Instead document them in a section above." We haven't yet moved all the existing properties over to the new layout (patches very much welcome, especially if you spot that an entire area you're touching like HDMI properties isn't moved yet). But the old table is very much not cool to add stuff to. Sorry that I didn't notice this earlier, missed it in the diffstat. > as optional. > I think it might be a bit misleading, if I add that one to standard connector > properties, > there are probably should be created some HDMI specific property chapter > then, as there > are already plenty of HDMI specific ones(force audio, broadcast rgb, aspect > ratio). > > Shouldn't it then go in a separate patch may be? Because this work is surely > needed, however > goes a bit out of scope of this patch. Don't make it worse by adding more unmaintainable and unreadable entries to this table. That's the minimum. Moving all the standard hdmi properties first would obviously be even better. That also makes reviewing easier, since it's clearer what's there already, and how your new thing fits in. -Daniel > > Best Regards, > > Lisovskiy Stanislav > > > --- > > Documentation/gpu/kms-properties.csv | 1 + > > drivers/gpu/drm/drm_atomic.c | 17 ++ > > drivers/gpu/drm/drm_connector.c | 51 > > drivers/gpu/drm/drm_edid.c | 2 ++ > > include/drm/drm_connector.h | 18 ++ > > include/drm/drm_mode_config.h| 5 +++ > > include/uapi/drm/drm_mode.h | 7 > > 7 files changed, 101 insertions(+) > > > > diff --git a/Documentation/gpu/kms-properties.csv > > b/Documentation/gpu/kms-properties.csv > > index 6b28b014cb7d..a91c9211b8d6 100644 > > --- a/Documentation/gpu/kms-properties.csv > > +++ b/Documentation/gpu/kms-properties.csv > > @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property > > Values,Object attached,De > > ,Virtual GPU,“suggested X”,RANGE,"Min=0, > > Max=0x",Connector,property to suggest an X offset for a connector > > ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to > > suggest an Y offset for a connector > > ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" > > }",Connector,TDB > > +,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"", > > ""Cinema"", ""Game"" }",Connector,TBD > > i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", > > ""Limited 16:235"" }",Connector,"When this property is set to Limited > > 16:235 and CTM is set, the hardware will be programmed with the result of > > the multiplication of CTM by the limited range matrix to ensure the pixels > > normaly in the range 0..1.0 are remapped to the range 16/255..235/255." > > ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD > > ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } > > etc.",Connector,TBD > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > > index 7d25c42f22db..479499f5848e 100644 > > --- a/drivers/gpu/drm/drm_atomic.c > > +++ b/drivers/gpu/drm/drm_atomic.c > > @@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct > > drm_connector *connector, > > state->link_status = val; > > } else if (property == config->aspect_ratio_property) { > > state->picture_aspect_ratio = val; > > + } else if (property == config->content_type_property) { > > + /* > > + * Lowest two bits of content_type property control > > + * content_type, bit 2 controls itc bit. > > + * It was decided to have a single property called > > + * content_type, instead of co
[Bug 106153] KWin crashed when Alt+Tab-ing through open windows
https://bugs.freedesktop.org/show_bug.cgi?id=106153 Bug ID: 106153 Summary: KWin crashed when Alt+Tab-ing through open windows Product: Mesa Version: 17.3 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: bernha...@mailbox.org QA Contact: dri-devel@lists.freedesktop.org Created attachment 138954 --> https://bugs.freedesktop.org/attachment.cgi?id=138954&action=edit More infos of KCrash/gdb and glxinfo. This might be a duplicate of #102423 or #103234. (But did not want to pollute these if they were unrelated.) ... #4 0x7f78f8a4c793 in KCrash::defaultCrashHandler (sig=11) at ./src/kcra... #5 ... #6 si_emit_draw_packets (sctx=sctx@entry=0x5600dec29f30, info=info@entry=0x... #7 0x7f78c278d2b0 in si_draw_vbo (ctx=0x5600dec29f30, info=0x5600dec6b1... #8 0x7f78c24efd03 in tc_call_draw_vbo (pipe=, payload=0x... #9 0x7f78c24eddff in tc_batch_execute (thread_index=0, job=0x5600dec6a8... ... (gdb) up #6 si_emit_draw_packets (sctx=sctx@entry=0x5600dec29f30, info=info@entry=0x... 713 index_max_size = (indexbuf->width0 - index_offset) / At this point it looks like variable indexbuf is NULL. "bt full" would suggest this too: #7 0x7f78c278d2b0 in si_draw_vbo (ctx=0x5600dec29f30, info=0x5600dec6b1... ... indexbuf = 0x0 So I cannot reproduce this and was hit just once. But it could be related to the not so long Qt 5.10 update in Debian testing. I took a core dump if there are more questions. All debug symbols are available as far as I see. Related could also be that the core file is of a size of 3.5 GB so that might have led to the NULL pointer. Attached is a file containing the more infos of KCrash/gdb and glxinfo. -- 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: [PATCHv3 3/8] drm/omap: add support for manually updated displays
Hi Tony! On 20 April 2018 at 15:25, Tony Lindgren wrote: > * Daniel Stone [180420 10:21]: >> On 20 April 2018 at 08:09, Tomi Valkeinen wrote: >> > It's actually not quite clear to me how manual update displays work with >> > DRM... >> > >> > As far as I see, we have essentially two cases: 1) single buffering, >> > where the userspace must set an area in the fb dirty, which then >> > triggers the update, 2) multi buffering, which doesn't need fb dirty, >> > but just a page flip which triggers the update. >> > >> > In the 2) case (which I think is the optimal case which all the modern >> > apps should use), there's no need for delayed work or any work, and the >> > code flow should be very similar to the auto-update model. >> >> Correct. There's been talk (and I think patches?) of adding a >> per-plane dirty property, so userspace can as an optimisation inform >> the kernel of the area changed between frames. But short of that, a >> pageflip needs to trigger a full-plane update, with no dirtyfb >> required. > > For per-plane dirty property patches, which ones do you refer to? Here's the latest iteration of that series: https://lists.freedesktop.org/archives/dri-devel/2018-April/171900.html <1522885748-67122-1-git-send-email-dra...@vmware.com> > Then for xorg, there's my second attempt on fixing the command mode > rotation at [0]. Not sure if that's enough for a fix? > > It seems not very efficient to me and I don't really know where > the the per crtc dirty flag should be stored.. I try to deny all knowledge of X11 these days, I'm afraid. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 09/11] drm: Expose modes with aspect ratio, only if requested
On Fri, Apr 20, 2018 at 07:01:49PM +0530, Nautiyal, Ankit K wrote: > From: Ankit Nautiyal > > We parse the EDID and add all the modes in the connector's modelist. > This adds CEA modes with aspect ratio information too, regardless of > whether user space requested this information or not. > > This patch prunes the modes with aspect-ratio information, from a > connector's modelist, if the user-space has not set the aspect ratio > DRM client cap. However if such a mode is unique in the list, it is > kept in the list, with aspect-ratio flags reset. > > Cc: Ville Syrjala > Cc: Shashank Sharma > Cc: Jose Abreu > > Signed-off-by: Ankit Nautiyal > > V3: As suggested by Ville, modified the mechanism of pruning of modes > with aspect-ratio, if the aspect-ratio is not supported. Instead > of straight away pruning such a mode, the mode is retained with > aspect ratio bits set to zero, provided it is unique. > V4: rebase > V5: Addressed review comments from Ville: > -used a pointer to store last valid mode. > -avoided, modifying of picture_aspect_ratio in kernel mode, > instead only flags bits of user mode are reset (if aspect-ratio > is not supported). > V6: As suggested by Ville, corrected the mode pruning logic and > elaborated the mode pruning logic and the assumptions taken. > V7: rebase > V8: rebase > V9: rebase > V10: rebase > V11: Fixed the issue caused in kms_3d test, and enhanced the pruning > logic to correctly identify and prune modes with aspect-ratio, > if aspect-ratio cap is not set. > --- > drivers/gpu/drm/drm_connector.c | 56 > +++-- > 1 file changed, 48 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index b3cde89..865ee354 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1531,15 +1531,35 @@ static struct drm_encoder > *drm_connector_get_encoder(struct drm_connector *conne > return connector->encoder; > } > > -static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode, > - const struct drm_file *file_priv) > +static bool > +drm_mode_expose_to_userspace(const struct drm_display_mode *mode, > + const struct drm_display_mode *modelist, > + const struct drm_file *file_priv) > { > /* >* If user-space hasn't configured the driver to expose the stereo 3D >* modes, don't expose them. >*/ > + struct drm_display_mode *mode_itr; > + > if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode)) > return false; > + /* > + * If user-space hasn't configured the driver to expose the modes > + * with aspect-ratio, don't expose them. However if such a mode > + * is unique, let it be exposed, but reset the aspect-ratio flags > + * while preparing the list of user-modes. > + */ > + if (!file_priv->aspect_ratio_allowed && > + mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) { > + list_for_each_entry(mode_itr, &modelist->head, head) > + if (drm_mode_match(mode_itr, mode, > +DRM_MODE_MATCH_TIMINGS | > +DRM_MODE_MATCH_CLOCK | > +DRM_MODE_MATCH_FLAGS | > +DRM_MODE_MATCH_3D_FLAGS)) > + return false; > + } > > return true; > } > @@ -1550,7 +1570,7 @@ int drm_mode_getconnector(struct drm_device *dev, void > *data, > struct drm_mode_get_connector *out_resp = data; > struct drm_connector *connector; > struct drm_encoder *encoder; > - struct drm_display_mode *mode; > + struct drm_display_mode *mode, *tmp, modelist; > int mode_count = 0; > int encoders_count = 0; > int ret = 0; > @@ -1605,23 +1625,37 @@ int drm_mode_getconnector(struct drm_device *dev, > void *data, > out_resp->subpixel = connector->display_info.subpixel_order; > out_resp->connection = connector->status; > > + INIT_LIST_HEAD(&modelist.head); Why are we using a struct drm_display_mode to get a simple list_head? > + > /* delayed so we get modes regardless of pre-fill_modes state */ > list_for_each_entry(mode, &connector->modes, head) > - if (drm_mode_expose_to_userspace(mode, file_priv)) > + if (drm_mode_expose_to_userspace(mode, &modelist, > + file_priv)) { > + struct drm_display_mode *tmp_mode; > + > + tmp_mode = drm_mode_duplicate(dev, mode); Duplicating every mode seems rather wasteful. I suppose we could just add another list_head to struct drm_display_mode for this purpose. An alternative could be to somehow mark each exposed mode an
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #38 from MirceaKitsune --- Created attachment 138950 --> https://bugs.freedesktop.org/attachment.cgi?id=138950&action=edit cat /var/log/messages -- 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 v11 06/11] drm: Add DRM client cap for aspect-ratio
On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote: > From: Ankit Nautiyal > > To enable aspect-ratio support in DRM, blindly exposing the aspect > ratio information along with mode, can break things in existing > user-spaces which have no intention or support to use this aspect > ratio information. > > To avoid this, a new drm client cap is required to enable a > user-space to advertise if it supports modes with aspect-ratio. Based > on this cap value, the kernel will take a call on exposing the aspect > ratio info in modes or not. > > This patch adds the client cap for aspect-ratio. > > Cc: Ville Syrjala > Cc: Shashank Sharma > Signed-off-by: Ankit Nautiyal > > V3: rebase > V4: As suggested by Marteen Lankhorst modified the commit message > explaining the need to use the DRM cap for aspect-ratio. Also, > tweaked the comment lines in the code for better understanding and > clarity, as recommended by Shashank Sharma. > V5: rebase > V6: rebase > V7: rebase > V8: rebase > V9: rebase > V10: added comment explaining that no userspace breaks on aspect-ratio > mode bits. > > Reviewed-by: Shashank Sharma > --- > drivers/gpu/drm/drm_ioctl.c | 9 + > include/drm/drm_file.h | 8 > include/uapi/drm/drm.h | 7 +++ > 3 files changed, 24 insertions(+) > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c > index af78291..39c8eab 100644 > --- a/drivers/gpu/drm/drm_ioctl.c > +++ b/drivers/gpu/drm/drm_ioctl.c > @@ -325,6 +325,15 @@ drm_setclientcap(struct drm_device *dev, void *data, > struct drm_file *file_priv) > file_priv->atomic = req->value; > file_priv->universal_planes = req->value; > break; > + case DRM_CLIENT_CAP_ASPECT_RATIO: > + if (req->value > 1) > + return -EINVAL; > + /* > + * No Atomic userspace blows up on aspect ratio mode bits. Checked in > + * wayland/weston, xserver, and hardware-composer modeset paths. > + */ Bogus indentation. Also where's the aspect_ratio_allowed handling for the atomic cap? Or did we decide against it after all? > + file_priv->aspect_ratio_allowed = req->value; > + break; > default: > return -EINVAL; > } > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h > index 5176c37..02b7dde 100644 > --- a/include/drm/drm_file.h > +++ b/include/drm/drm_file.h > @@ -182,6 +182,14 @@ struct drm_file { > unsigned atomic:1; > > /** > + * @aspect_ratio_allowed: > + * > + * True, if client can handle picture aspect ratios, and has requested > + * to pass this information along with the mode. > + */ > + unsigned aspect_ratio_allowed:1; > + > + /** >* @is_master: >* >* This client is the creator of @master. Protected by struct > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > index 6fdff59..9c660e1 100644 > --- a/include/uapi/drm/drm.h > +++ b/include/uapi/drm/drm.h > @@ -680,6 +680,13 @@ struct drm_get_cap { > */ > #define DRM_CLIENT_CAP_ATOMIC3 > > +/** > + * DRM_CLIENT_CAP_ASPECT_RATIO > + * > + * If set to 1, the DRM core will provide aspect ratio information in modes. > + */ > +#define DRM_CLIENT_CAP_ASPECT_RATIO4 > + > /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */ > struct drm_set_client_cap { > __u64 capability; > -- > 2.7.4 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits
On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote: > From: Ankit Nautiyal > > This patch adds helper functions for determining if aspect-ratio is > expected in user-mode and for allowing/disallowing the aspect-ratio, > if its not expected. > > Signed-off-by: Ankit Nautiyal > --- > drivers/gpu/drm/drm_modes.c | 47 > + > include/drm/drm_modes.h | 4 > 2 files changed, 51 insertions(+) > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index c395a24..d6133e8 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -1759,3 +1759,50 @@ bool drm_mode_is_420(const struct drm_display_info > *display, > drm_mode_is_420_also(display, mode); > } > EXPORT_SYMBOL(drm_mode_is_420); > + > +/** > + * drm_mode_aspect_ratio_allowed - checks if the aspect-ratio information > + * is expected from the user-mode. > + * > + * If the user has set aspect-ratio cap, then the flag of the user-mode is > + * allowed to contain aspect-ratio value. > + * If the user does not set aspect-ratio cap, then the only value allowed in > the > + * flags bits is aspect-ratio NONE. > + * > + * @file_priv: file private structure to get the user capabilities > + * @umode: drm_mode_modeinfo struct, whose flag carry the aspect ratio > + * information. > + * > + * Returns: > + * true if the aspect-ratio info is allowed in the user-mode flags. > + * false, otherwise. > + */ > +bool > +drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv, > + struct drm_mode_modeinfo *umode) > +{ > + return file_priv->aspect_ratio_allowed || (umode->flags & > + DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE; Odd line split here. Makes this a bit hard to read. I would split after the || > +} > +EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed); Do we actually need to export these? I don't think so. But I might be wrong. It's a bit hard to see with the way you split this patch with the actual users in a different patch. > + > +/** > + * drm_mode_filter_aspect_ratio_flags - filters the aspect-ratio bits in the > + * user-mode flags. > + * > + * Checks if the aspect-ratio information is allowed. Resets the aspect-ratio > + * bits in the user-mode flags, if aspect-ratio info is not allowed. > + * > + * @file_priv: file private structure to get the user capabilities. > + * @umode: drm_mode_modeinfo struct, whose flags' aspect-ratio bits needs to > + * be filtered. > + * > + */ > +void > +drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv, > +struct drm_mode_modeinfo *umode) > +{ > + if (!drm_mode_aspect_ratio_allowed(file_priv, umode)) > + umode->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK; > +} > +EXPORT_SYMBOL(drm_mode_filter_aspect_ratio_flags); > diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h > index 2f78b7e..e0b060d 100644 > --- a/include/drm/drm_modes.h > +++ b/include/drm/drm_modes.h > @@ -461,6 +461,10 @@ bool drm_mode_is_420_also(const struct drm_display_info > *display, > const struct drm_display_mode *mode); > bool drm_mode_is_420(const struct drm_display_info *display, >const struct drm_display_mode *mode); > +bool drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv, > +struct drm_mode_modeinfo *umode); > +void drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv, > + struct drm_mode_modeinfo *umode); > > struct drm_display_mode *drm_cvt_mode(struct drm_device *dev, > int hdisplay, int vdisplay, int vrefresh, > -- > 2.7.4 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMD graphics performance regression in 4.15 and later
On 2018-04-11 11:37 AM, Christian König wrote: > Am 11.04.2018 um 06:00 schrieb Gabriel C: >> 2018-04-09 11:42 GMT+02:00 Christian König >> : >>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: Hi Christian, Thanks for the info. FYI, I've also opened a Firefox bug for that at: https://bugzilla.mozilla.org/show_bug.cgi?id=1448778 Feel free to comment since you have a better understanding of what's going on. One last question: right now I'm running 4.15.0 with the "offending" patch reverted. Is that safe to run or are there possible bad interactions with other changes. >>> >>> That should work without problems. >>> >>> But I just had another idea as well, if you want you could still test >>> the >>> new code path which will be using in 4.17. >>> >> While Firefox may do some strange things is not about only Firefox. >> >> With your patches my EPYC box is unusable with 4.15++ kernels. >> The whole Desktop is acting weird. This one is using >> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU. >> >> Box is 2 * EPYC 7281 with 128 GB ECC RAM >> >> Also a 14C Xeon box with a HD7700 is broken same way. > > The hardware is irrelevant for this. We need to know what software stack > you use on top of it. > > E.g. desktop environment/Mesa and DDX version etc... > >> >> Everything breaks in X .. scrolling , moving windows , flickering etc. >> >> >> reverting f4c809914a7c3e4a59cf543da6c2a15d0f75ee38 and >> 648bc3574716400acc06f99915815f80d9563783 >> from an 4.15 kernel makes things work again. >> >> >>> Backporting all the detection logic is to invasive, but you could >>> just go >>> into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the other >>> code path. >>> >>> Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those. >>> >> Well you really can't be serious about these suggestions ? Are you ? >> >> Telling peoples to #if 0 random code is not a solution. > > That is for testing and not a permanent solution. > >> You broke existsing working userland with your patches and at least >> please fix that for 4.16. >> >> I can help testing code for 4.17/++ if you wish but that is >> *different* storry. > > Please test Alex's amd-staging-drm-next branch from > git://people.freedesktop.org/~agd5f/linux. I think we're still missing something here. I'm currently running 4.16.2 + the DRM subsystem changes which are going into 4.17 (so I have the changes Christian is referring to) with a Kaveri APU, and I'm seeing similar symptoms as described by Jean-Marc. Some observations: Firefox, Thunderbird, or worst, gnome-shell, can freeze for up to on the order of a minute, during which the kernel is spending most of one core's cycles inside alloc_pages (__alloc_pages_nodemask to be more precise), called from ttm_alloc_new_pages. At least in the case of Firefox, this happens due to Mesa internal BO allocations for glTex(Sub)Image, so it's not obvious that Firefox is doing something wrong. I never noticed this before this week. Before, I was running 4.15.y + DRM subsystem changes from 4.16. Maybe something has changed in core code, trying harder to allocate huge pages. Maybe TTM should only try to use any huge pages that happen to be available, not spend any (/ "too much"?) additional effort trying to free up huge pages? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events
Hi Enric, On 05.04.2018 11:49, Enric Balletbo i Serra wrote: > From: "Kristian H. Kristensen" > > To improve PSR exit latency, we speculatively start exiting when we > receive input events. Occasionally, this may lead to false positives, > but most of the time we get a head start on coming out of PSR. Depending > on how userspace takes to produce a new frame in response to the event, > this can completely hide the exit latency. In case of Chrome OS, we > typically get the input notifier 50ms or more before the dirty_fb > triggered exit. This patch is quite controversial and require more attention/discussion and probably changes. The rest of the patches is OK, and all have r-b/t-b tags. If you prefer I can merge all other patches, if you rebase patches 25-30 on top of patch 23, or I can only merge patches 01-23. What do you prefer? Regards Andrzej > > Signed-off-by: Kristian H. Kristensen > Signed-off-by: Thierry Escande > Signed-off-by: Enric Balletbo i Serra > Tested-by: Marek Szyprowski > --- > > drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 134 > > 1 file changed, 134 insertions(+) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c > b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c > index 9376f4396b6b..a107845ba97c 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c > @@ -12,6 +12,8 @@ > * GNU General Public License for more details. > */ > > +#include > + > #include > #include > > @@ -35,6 +37,9 @@ struct psr_drv { > enum psr_state state; > > struct delayed_work flush_work; > + struct work_struct disable_work; > + > + struct input_handlerinput_handler; > > int (*set)(struct drm_encoder *encoder, bool enable); > }; > @@ -133,6 +138,18 @@ static void psr_flush_handler(struct work_struct *work) > mutex_unlock(&psr->lock); > } > > +static void psr_disable_handler(struct work_struct *work) > +{ > + struct psr_drv *psr = container_of(work, struct psr_drv, disable_work); > + > + /* If the state has changed since we initiated the flush, do nothing */ > + mutex_lock(&psr->lock); > + if (psr->state == PSR_ENABLE) > + psr_set_state_locked(psr, PSR_FLUSH); > + mutex_unlock(&psr->lock); > + mod_delayed_work(system_wq, &psr->flush_work, PSR_FLUSH_TIMEOUT_MS); > +} > + > /** > * rockchip_drm_psr_activate - activate PSR on the given pipe > * @encoder: encoder to obtain the PSR encoder > @@ -173,6 +190,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder > *encoder) > psr->active = false; > mutex_unlock(&psr->lock); > cancel_delayed_work_sync(&psr->flush_work); > + cancel_work_sync(&psr->disable_work); > > return 0; > } > @@ -226,6 +244,95 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev) > } > EXPORT_SYMBOL(rockchip_drm_psr_flush_all); > > +static void psr_input_event(struct input_handle *handle, > + unsigned int type, unsigned int code, > + int value) > +{ > + struct psr_drv *psr = handle->handler->private; > + > + schedule_work(&psr->disable_work); > +} > + > +static int psr_input_connect(struct input_handler *handler, > + struct input_dev *dev, > + const struct input_device_id *id) > +{ > + struct input_handle *handle; > + int error; > + > + handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL); > + if (!handle) > + return -ENOMEM; > + > + handle->dev = dev; > + handle->handler = handler; > + handle->name = "rockchip-psr"; > + > + error = input_register_handle(handle); > + if (error) > + goto err2; > + > + error = input_open_device(handle); > + if (error) > + goto err1; > + > + return 0; > + > +err1: > + input_unregister_handle(handle); > +err2: > + kfree(handle); > + return error; > +} > + > +static void psr_input_disconnect(struct input_handle *handle) > +{ > + input_close_device(handle); > + input_unregister_handle(handle); > + kfree(handle); > +} > + > +/* Same device ids as cpu-boost */ > +static const struct input_device_id psr_ids[] = { > + { > + .flags = INPUT_DEVICE_ID_MATCH_EVBIT | > + INPUT_DEVICE_ID_MATCH_ABSBIT, > + .evbit = { BIT_MASK(EV_ABS) }, > + .absbit = { [BIT_WORD(ABS_MT_POSITION_X)] = > + BIT_MASK(ABS_MT_POSITION_X) | > + BIT_MASK(ABS_MT_POSITION_Y) }, > + }, /* multi-touch touchscreen */ > + { > + .flags = INPUT_DEVICE_ID_MATCH_EVBIT, > + .evbit = { BIT_MASK(EV_ABS) }, > + .absbit = { [BIT_WORD(ABS_X)] = BIT_MASK(ABS_X) } > + > + }, /* stylus or joystick device */ > + { > + .flags = INPUT_DEVICE_ID_MATCH_EVBIT, > + .evbit = { BI
[PATCH v11 02/11] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
From: Ville Syrjälä Use drm_mode_equal_no_clocks_no_stereo() in drm_match_hdmi_mode_clock_tolerance() for consistency as we also use it in drm_match_hdmi_mode() and the cea mode matching functions. This doesn't actually change anything since the input mode comes from detailed timings and we match it against edid_4k_modes[] which. So none of those modes can have stereo flags set. Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma --- drivers/gpu/drm/drm_edid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 134069f..c35d3bc 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3047,7 +3047,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_ abs(to_match->clock - clock2) > clock_tolerance) continue; - if (drm_mode_equal_no_clocks(to_match, hdmi_mode)) + if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode)) return vic; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 09/11] drm: Expose modes with aspect ratio, only if requested
From: Ankit Nautiyal We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch prunes the modes with aspect-ratio information, from a connector's modelist, if the user-space has not set the aspect ratio DRM client cap. However if such a mode is unique in the list, it is kept in the list, with aspect-ratio flags reset. Cc: Ville Syrjala Cc: Shashank Sharma Cc: Jose Abreu Signed-off-by: Ankit Nautiyal V3: As suggested by Ville, modified the mechanism of pruning of modes with aspect-ratio, if the aspect-ratio is not supported. Instead of straight away pruning such a mode, the mode is retained with aspect ratio bits set to zero, provided it is unique. V4: rebase V5: Addressed review comments from Ville: -used a pointer to store last valid mode. -avoided, modifying of picture_aspect_ratio in kernel mode, instead only flags bits of user mode are reset (if aspect-ratio is not supported). V6: As suggested by Ville, corrected the mode pruning logic and elaborated the mode pruning logic and the assumptions taken. V7: rebase V8: rebase V9: rebase V10: rebase V11: Fixed the issue caused in kms_3d test, and enhanced the pruning logic to correctly identify and prune modes with aspect-ratio, if aspect-ratio cap is not set. --- drivers/gpu/drm/drm_connector.c | 56 +++-- 1 file changed, 48 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index b3cde89..865ee354 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1531,15 +1531,35 @@ static struct drm_encoder *drm_connector_get_encoder(struct drm_connector *conne return connector->encoder; } -static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode, -const struct drm_file *file_priv) +static bool +drm_mode_expose_to_userspace(const struct drm_display_mode *mode, +const struct drm_display_mode *modelist, +const struct drm_file *file_priv) { /* * If user-space hasn't configured the driver to expose the stereo 3D * modes, don't expose them. */ + struct drm_display_mode *mode_itr; + if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode)) return false; + /* +* If user-space hasn't configured the driver to expose the modes +* with aspect-ratio, don't expose them. However if such a mode +* is unique, let it be exposed, but reset the aspect-ratio flags +* while preparing the list of user-modes. +*/ + if (!file_priv->aspect_ratio_allowed && + mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) { + list_for_each_entry(mode_itr, &modelist->head, head) + if (drm_mode_match(mode_itr, mode, + DRM_MODE_MATCH_TIMINGS | + DRM_MODE_MATCH_CLOCK | + DRM_MODE_MATCH_FLAGS | + DRM_MODE_MATCH_3D_FLAGS)) + return false; + } return true; } @@ -1550,7 +1570,7 @@ int drm_mode_getconnector(struct drm_device *dev, void *data, struct drm_mode_get_connector *out_resp = data; struct drm_connector *connector; struct drm_encoder *encoder; - struct drm_display_mode *mode; + struct drm_display_mode *mode, *tmp, modelist; int mode_count = 0; int encoders_count = 0; int ret = 0; @@ -1605,23 +1625,37 @@ int drm_mode_getconnector(struct drm_device *dev, void *data, out_resp->subpixel = connector->display_info.subpixel_order; out_resp->connection = connector->status; + INIT_LIST_HEAD(&modelist.head); + /* delayed so we get modes regardless of pre-fill_modes state */ list_for_each_entry(mode, &connector->modes, head) - if (drm_mode_expose_to_userspace(mode, file_priv)) + if (drm_mode_expose_to_userspace(mode, &modelist, +file_priv)) { + struct drm_display_mode *tmp_mode; + + tmp_mode = drm_mode_duplicate(dev, mode); + list_add_tail(&tmp_mode->head, &modelist.head); mode_count++; + } /* * This ioctl is called twice, once to determine how much space is * needed, and the 2nd time to fill it. +* The modes that need to be exposed to the user are maintained in the +* 'modelist'. When the ioctl is called first time to determine the, +* space, the modelist gets filled,
[PATCH v11 04/11] drm/edid: Don't send bogus aspect ratios in AVI infoframes
From: Ville Syrjälä If the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be careful that we don't try to send illegal picture aspect in the infoframe as it's only capable of signalling none, 4:3, and 16:9. Currently we're sending these bogus infoframes whenever the cea mode specifies some other aspect ratio. Cc: Shashank Sharma Cc: Sean Paul Cc: Jose Abreu Cc: Daniel Vetter Cc: Emil Velikov Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma --- drivers/gpu/drm/drm_edid.c | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 29c88eb..d5757aa 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4840,6 +4840,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, const struct drm_display_mode *mode, bool is_hdmi2_sink) { + enum hdmi_picture_aspect picture_aspect; int err; if (!frame || !mode) @@ -4882,13 +4883,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, * Populate picture aspect ratio from either * user input (if specified) or from the CEA mode list. */ - if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 || - mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9) - frame->picture_aspect = mode->picture_aspect_ratio; - else if (frame->video_code > 0) - frame->picture_aspect = drm_get_cea_aspect_ratio( - frame->video_code); + picture_aspect = mode->picture_aspect_ratio; + if (picture_aspect == HDMI_PICTURE_ASPECT_NONE) + picture_aspect = drm_get_cea_aspect_ratio(frame->video_code); + /* +* The infoframe can't convey anything but none, 4:3 +* and 16:9, so if the user has asked for anything else +* we can only satisfy it by specifying the right VIC. +*/ + if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) { + if (picture_aspect != + drm_get_cea_aspect_ratio(frame->video_code)) + return -EINVAL; + picture_aspect = HDMI_PICTURE_ASPECT_NONE; + } + + frame->picture_aspect = picture_aspect; frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE; frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 05/11] video/hdmi: Reject illegal picture aspect ratios
From: Ville Syrjälä AVI infoframe can only carry none, 4:3, or 16:9 picture aspect ratios. Return an error if the user asked for something different. Cc: Shashank Sharma Cc: "Lin, Jia" Cc: Akashdeep Sharma Cc: Jim Bride Cc: Jose Abreu Cc: Daniel Vetter Cc: Emil Velikov Cc: Thierry Reding Cc: Hans Verkuil Cc: linux-me...@vger.kernel.org Signed-off-by: Ville Syrjälä Reviewed-by: Jose Abreu --- drivers/video/hdmi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index 111a0ab..38716eb5 100644 --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -93,6 +93,9 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void *buffer, if (size < length) return -ENOSPC; + if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9) + return -EINVAL; + memset(buffer, 0, size); ptr[0] = frame->type; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: udl: Destroy framebuffer only if it was initialized
On Fri, Apr 20, 2018 at 01:50:01PM +0200, Emil Lundmark wrote: > This fixes a NULL pointer dereference that can happen if the UDL > driver is unloaded before the framebuffer is initialized. This can > happen e.g. if the USB device is unplugged right after it was plugged > in. > JFYI, in future, if someone makes a suggestion on how to fix a bug, it's good practice to add a Suggested-by tag to give credit. Reviewed-by: Sean Paul > Signed-off-by: Emil Lundmark > --- > drivers/gpu/drm/udl/udl_fb.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c > index 2ebdc6d5a76e..5754e37f741b 100644 > --- a/drivers/gpu/drm/udl/udl_fb.c > +++ b/drivers/gpu/drm/udl/udl_fb.c > @@ -426,9 +426,11 @@ static void udl_fbdev_destroy(struct drm_device *dev, > { > drm_fb_helper_unregister_fbi(&ufbdev->helper); > drm_fb_helper_fini(&ufbdev->helper); > - drm_framebuffer_unregister_private(&ufbdev->ufb.base); > - drm_framebuffer_cleanup(&ufbdev->ufb.base); > - drm_gem_object_put_unlocked(&ufbdev->ufb.obj->base); > + if (ufbdev->ufb.obj) { > + drm_framebuffer_unregister_private(&ufbdev->ufb.base); > + drm_framebuffer_cleanup(&ufbdev->ufb.base); > + drm_gem_object_put_unlocked(&ufbdev->ufb.obj->base); > + } > } > > int udl_fbdev_init(struct drm_device *dev) > -- > 2.17.0.484.g0c8726318c-goog > -- 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 v11 06/11] drm: Add DRM client cap for aspect-ratio
From: Ankit Nautiyal To enable aspect-ratio support in DRM, blindly exposing the aspect ratio information along with mode, can break things in existing user-spaces which have no intention or support to use this aspect ratio information. To avoid this, a new drm client cap is required to enable a user-space to advertise if it supports modes with aspect-ratio. Based on this cap value, the kernel will take a call on exposing the aspect ratio info in modes or not. This patch adds the client cap for aspect-ratio. Cc: Ville Syrjala Cc: Shashank Sharma Signed-off-by: Ankit Nautiyal V3: rebase V4: As suggested by Marteen Lankhorst modified the commit message explaining the need to use the DRM cap for aspect-ratio. Also, tweaked the comment lines in the code for better understanding and clarity, as recommended by Shashank Sharma. V5: rebase V6: rebase V7: rebase V8: rebase V9: rebase V10: added comment explaining that no userspace breaks on aspect-ratio mode bits. Reviewed-by: Shashank Sharma --- drivers/gpu/drm/drm_ioctl.c | 9 + include/drm/drm_file.h | 8 include/uapi/drm/drm.h | 7 +++ 3 files changed, 24 insertions(+) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index af78291..39c8eab 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -325,6 +325,15 @@ drm_setclientcap(struct drm_device *dev, void *data, struct drm_file *file_priv) file_priv->atomic = req->value; file_priv->universal_planes = req->value; break; + case DRM_CLIENT_CAP_ASPECT_RATIO: + if (req->value > 1) + return -EINVAL; + /* +* No Atomic userspace blows up on aspect ratio mode bits. Checked in +* wayland/weston, xserver, and hardware-composer modeset paths. +*/ + file_priv->aspect_ratio_allowed = req->value; + break; default: return -EINVAL; } diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h index 5176c37..02b7dde 100644 --- a/include/drm/drm_file.h +++ b/include/drm/drm_file.h @@ -182,6 +182,14 @@ struct drm_file { unsigned atomic:1; /** +* @aspect_ratio_allowed: +* +* True, if client can handle picture aspect ratios, and has requested +* to pass this information along with the mode. +*/ + unsigned aspect_ratio_allowed:1; + + /** * @is_master: * * This client is the creator of @master. Protected by struct diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 6fdff59..9c660e1 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -680,6 +680,13 @@ struct drm_get_cap { */ #define DRM_CLIENT_CAP_ATOMIC 3 +/** + * DRM_CLIENT_CAP_ASPECT_RATIO + * + * If set to 1, the DRM core will provide aspect ratio information in modes. + */ +#define DRM_CLIENT_CAP_ASPECT_RATIO4 + /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */ struct drm_set_client_cap { __u64 capability; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)
https://bugs.freedesktop.org/show_bug.cgi?id=104082 --- Comment #40 from Jean Delvare --- I believe there are 2 incarnations of this bug, with the same symptoms but different root causes. The first bug is affecting kernels v4.14 and v4.15, it is caused by 2 MB allocations failing too verbosely when in fact 4 kB allocations worked just fine as a fallback. That one is fixed in v4.16 by: commit d0bc0c2a31c95002d37c3cc511ffdcab851b3256 Author: Christian König Date: Thu Jan 4 14:24:19 2018 +0100 swiotlb: suppress warning when __GFP_NOWARN is set However kernel v4.16 also includes the following commit: commit 0176adb004065d6815a8e67946752df4cd947c5b Author: Christoph Hellwig Date: Tue Jan 9 22:15:30 2018 +0100 swiotlb: refactor coherent buffer allocation which contains a bug producing exactly the same backtraces. That bug is caused by an improper check of the result of dma_coherent_ok(), which was fixed 10 days ago with: commit 9e7f06c8beee304ee21b791653fefcd713f48b9a Author: Takashi Iwai Date: Tue Apr 10 19:05:13 2018 +0200 swiotlb: fix unexpected swiotlb_alloc_coherent failures I backported this fix on top of v4.16.3 and the backtraces are gone. The commit was tagged for stable inclusion so I expect it to be included in v4.16. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 11/11] drm: Add and handle new aspect ratios in DRM layer
From: "Sharma, Shashank" HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise versa. This patch was once reviewed and merged, and later reverted due to lack of DRM client protection, while adding aspect ratio bits in user modes. This is a re-spin of the series, with DRM client cap protection. The previous series can be found here: https://pw-emeril.freedesktop.org/series/10850/ Signed-off-by: Shashank Sharma Reviewed-by: Sean Paul (V2) Reviewed-by: Jose Abreu (V2) Cc: Ville Syrjala Cc: Sean Paul Cc: Jose Abreu Cc: Ankit Nautiyal V3: rebase V4: rebase V5: corrected the macro name for an aspect ratio, in a switch case. V6: rebase V7: rebase V8: rebase V9: rebase V10: rebase --- drivers/gpu/drm/drm_modes.c | 12 include/uapi/drm/drm_mode.h | 6 ++ 2 files changed, 18 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 454f2ff..21cc84b 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1656,6 +1656,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out, case HDMI_PICTURE_ASPECT_16_9: out->flags |= DRM_MODE_FLAG_PIC_AR_16_9; break; + case HDMI_PICTURE_ASPECT_64_27: + out->flags |= DRM_MODE_FLAG_PIC_AR_64_27; + break; + case HDMI_PICTURE_ASPECT_256_135: + out->flags |= DRM_MODE_FLAG_PIC_AR_256_135; + break; case HDMI_PICTURE_ASPECT_RESERVED: default: out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; @@ -1721,6 +1727,12 @@ int drm_mode_convert_umode(struct drm_device *dev, case DRM_MODE_FLAG_PIC_AR_16_9: out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9; break; + case DRM_MODE_FLAG_PIC_AR_64_27: + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27; + break; + case DRM_MODE_FLAG_PIC_AR_256_135: + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135; + break; default: out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; break; diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 50bcf42..4b3a1bb 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -93,6 +93,8 @@ extern "C" { #define DRM_MODE_PICTURE_ASPECT_NONE 0 #define DRM_MODE_PICTURE_ASPECT_4_31 #define DRM_MODE_PICTURE_ASPECT_16_9 2 +#define DRM_MODE_PICTURE_ASPECT_64_27 3 +#define DRM_MODE_PICTURE_ASPECT_256_1354 /* Aspect ratio flag bitmask (4 bits 22:19) */ #define DRM_MODE_FLAG_PIC_AR_MASK (0x0F<<19) @@ -102,6 +104,10 @@ extern "C" { (DRM_MODE_PICTURE_ASPECT_4_3<<19) #define DRM_MODE_FLAG_PIC_AR_16_9 \ (DRM_MODE_PICTURE_ASPECT_16_9<<19) +#define DRM_MODE_FLAG_PIC_AR_64_27 \ + (DRM_MODE_PICTURE_ASPECT_64_27<<19) +#define DRM_MODE_FLAG_PIC_AR_256_135 \ + (DRM_MODE_PICTURE_ASPECT_256_135<<19) #define DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \ DRM_MODE_FLAG_NHSYNC | \ -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 01/11] drm/modes: Introduce drm_mode_match()
From: Ville Syrjälä Make mode matching less confusing by allowing the caller to specify which parts of the modes should match via some flags. Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma --- drivers/gpu/drm/drm_modes.c | 134 ++-- include/drm/drm_modes.h | 9 +++ 2 files changed, 112 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index e82b61e..c395a24 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -939,17 +939,68 @@ struct drm_display_mode *drm_mode_duplicate(struct drm_device *dev, } EXPORT_SYMBOL(drm_mode_duplicate); +static bool drm_mode_match_timings(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2) +{ + return mode1->hdisplay == mode2->hdisplay && + mode1->hsync_start == mode2->hsync_start && + mode1->hsync_end == mode2->hsync_end && + mode1->htotal == mode2->htotal && + mode1->hskew == mode2->hskew && + mode1->vdisplay == mode2->vdisplay && + mode1->vsync_start == mode2->vsync_start && + mode1->vsync_end == mode2->vsync_end && + mode1->vtotal == mode2->vtotal && + mode1->vscan == mode2->vscan; +} + +static bool drm_mode_match_clock(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2) +{ + /* +* do clock check convert to PICOS +* so fb modes get matched the same +*/ + if (mode1->clock && mode2->clock) + return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock); + else + return mode1->clock == mode2->clock; +} + +static bool drm_mode_match_flags(const struct drm_display_mode *mode1, +const struct drm_display_mode *mode2) +{ + return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) == + (mode2->flags & ~DRM_MODE_FLAG_3D_MASK); +} + +static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2) +{ + return (mode1->flags & DRM_MODE_FLAG_3D_MASK) == + (mode2->flags & DRM_MODE_FLAG_3D_MASK); +} + +static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2) +{ + return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio; +} + /** - * drm_mode_equal - test modes for equality + * drm_mode_match - test modes for (partial) equality * @mode1: first mode * @mode2: second mode + * @match_flags: which parts need to match (DRM_MODE_MATCH_*) * * Check to see if @mode1 and @mode2 are equivalent. * * Returns: - * True if the modes are equal, false otherwise. + * True if the modes are (partially) equal, false otherwise. */ -bool drm_mode_equal(const struct drm_display_mode *mode1, const struct drm_display_mode *mode2) +bool drm_mode_match(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2, + unsigned int match_flags) { if (!mode1 && !mode2) return true; @@ -957,15 +1008,48 @@ bool drm_mode_equal(const struct drm_display_mode *mode1, const struct drm_displ if (!mode1 || !mode2) return false; - /* do clock check convert to PICOS so fb modes get matched -* the same */ - if (mode1->clock && mode2->clock) { - if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock)) - return false; - } else if (mode1->clock != mode2->clock) + if (match_flags & DRM_MODE_MATCH_TIMINGS && + !drm_mode_match_timings(mode1, mode2)) return false; - return drm_mode_equal_no_clocks(mode1, mode2); + if (match_flags & DRM_MODE_MATCH_CLOCK && + !drm_mode_match_clock(mode1, mode2)) + return false; + + if (match_flags & DRM_MODE_MATCH_FLAGS && + !drm_mode_match_flags(mode1, mode2)) + return false; + + if (match_flags & DRM_MODE_MATCH_3D_FLAGS && + !drm_mode_match_3d_flags(mode1, mode2)) + return false; + + if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO && + !drm_mode_match_aspect_ratio(mode1, mode2)) + return false; + + return true; +} +EXPORT_SYMBOL(drm_mode_match); + +/** + * drm_mode_equal - test modes for equality + * @mode1: first mode + * @mode2: second mode + * + * Check to see if @mode1 and @mode2 are equivalent. + * + * Returns: + * True if the modes are equal, false otherwise. + */ +bool drm_mode_equal(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2) +{ + return drm_mode_match(mode1, mode2, + DRM_
[PATCH v11 08/11] drm: Handle aspect ratio info in legacy and atomic modeset paths
From: Ankit Nautiyal If the user-space does not support aspect-ratio, and requests for a modeset with mode having aspect ratio bits set, then the given user-mode must be rejected. Secondly, while preparing a user-mode from kernel mode, the aspect-ratio info must not be given, if aspect-ratio is not supported by the user. Note: In case, a user-space asks for a video-mode blob, from the getblob ioctl, the aspect-ratio bits in the video-mode blob are passed to the user as it is, without any filtering. However, no such case is present in most of the atomic user-spaces. Currently atomic path of Xserver, Wayland/weston, Hardware-Composer are checked, and none of them are using getblob ioctl to get the video-mode blob. This patch: 1. passes the file_priv structure from the drm_mode_atomic_ioctl till the drm_mode_crtc_set_mode_prop, to get the user capability. 2. rejects the modes with aspect-ratio info, during modeset, if the user does not support aspect ratio. 3. does not load the aspect-ratio info in user-mode structure, if aspect ratio is not supported. Signed-off-by: Ankit Nautiyal V3: Addressed review comments from Ville: Do not corrupt the current crtc state by updating aspect-ratio on the fly. V4: rebase V5: As suggested by Ville, rejected the modeset calls for modes with aspect ratio, if the user does not set aspect-ratio cap. V6: Used the helper functions for determining if aspect-ratio is expected in the user-mode. V7: rebase V8: rebase V9: rebase v10: Modified the commit-message --- drivers/gpu/drm/drm_atomic.c| 34 +- drivers/gpu/drm/drm_atomic_helper.c | 6 +++--- drivers/gpu/drm/drm_crtc.c | 8 drivers/gpu/drm/drm_crtc_internal.h | 3 ++- drivers/gpu/drm/drm_mode_object.c | 9 ++--- include/drm/drm_atomic.h| 5 +++-- 6 files changed, 47 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 3d9ae05..5acf49d 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -368,6 +368,7 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc); * drm_atomic_set_mode_prop_for_crtc - set mode for CRTC * @state: the CRTC whose incoming state to update * @blob: pointer to blob property to use for mode + * @file_priv: file priv structure, to get the userspace capabilities * * Set a mode (originating from a blob property) on the desired CRTC state. * This function will take a reference on the blob property for the CRTC state, @@ -378,7 +379,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc); * Zero on success, error code on failure. Cannot return -EDEADLK. */ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state, - struct drm_property_blob *blob) + struct drm_property_blob *blob, + struct drm_file *file_priv) { if (blob == state->mode_blob) return 0; @@ -389,9 +391,21 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state, memset(&state->mode, 0, sizeof(state->mode)); if (blob) { - if (blob->length != sizeof(struct drm_mode_modeinfo) || - drm_mode_convert_umode(state->crtc->dev, &state->mode, - blob->data)) + struct drm_mode_modeinfo *u_mode; + + if (blob->length != sizeof(struct drm_mode_modeinfo)) + return -EINVAL; + + u_mode = (struct drm_mode_modeinfo *) blob->data; + if (!drm_mode_aspect_ratio_allowed(file_priv, + u_mode)) { + DRM_DEBUG_ATOMIC("Unexpected aspect-ratio flag bits\n"); + return -EINVAL; + } + + if (drm_mode_convert_umode(state->crtc->dev, &state->mode, + (const struct drm_mode_modeinfo *) + u_mode)) return -EINVAL; state->mode_blob = drm_property_blob_get(blob); @@ -471,6 +485,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device *dev, * @state: the state object to update with the new property value * @property: the property to set * @val: the new property value + * @file_priv: the file private structure, to get the user capabilities * * This function handles generic/core properties and calls out to driver's * &drm_crtc_funcs.atomic_set_property for driver properties. To ensure @@ -482,7 +497,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device *dev, */ int drm_atomic_crtc_set_property(struct drm_crtc *crtc, struct drm_crtc_state *state, struct drm_property *property, - uint64_t val) + uint64_t val, struct drm_file *file_priv) { struct drm_device *
[PATCH v11 10/11] drm: Add aspect ratio parsing in DRM layer
From: "Sharma, Shashank" Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information in DRM's mode conversion and mode comparision functions, to make sure kernel picks mode with right aspect ratio (as per the VIC). Background: This patch was once reviewed and merged, and later reverted due to lack of DRM cap protection. This is a re-spin of this patch, this time with DRM cap protection, to avoid aspect ratio information, when the client doesn't request for it. Review link: https://pw-emeril.freedesktop.org/patch/104068/ Background discussion: https://patchwork.kernel.org/patch/9379057/ Signed-off-by: Shashank Sharma Signed-off-by: Lin, Jia Signed-off-by: Akashdeep Sharma Reviewed-by: Jim Bride (V2) Reviewed-by: Jose Abreu (V4) Cc: Ville Syrjala Cc: Jim Bride Cc: Jose Abreu Cc: Ankit Nautiyal V3: modified the aspect-ratio check in drm_mode_equal as per new flags provided by Ville. https://patchwork.freedesktop.org/patch/188043/ V4: rebase V5: rebase V6: As recommended by Ville, avoided matching of aspect-ratio in drm_fb_helper, while trying to find a common mode among connectors for the target clone mode. V7: rebase V8: rebase V9: rebase V10: rebase --- drivers/gpu/drm/drm_fb_helper.c | 12 ++-- drivers/gpu/drm/drm_modes.c | 35 ++- 2 files changed, 44 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 0646b10..2ee1eaa 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct drm_fb_helper *fb_helper, for (j = 0; j < i; j++) { if (!enabled[j]) continue; - if (!drm_mode_equal(modes[j], modes[i])) + if (!drm_mode_match(modes[j], modes[i], + DRM_MODE_MATCH_TIMINGS | + DRM_MODE_MATCH_CLOCK | + DRM_MODE_MATCH_FLAGS | + DRM_MODE_MATCH_3D_FLAGS)) can_clone = false; } } @@ -2203,7 +2207,11 @@ static bool drm_target_cloned(struct drm_fb_helper *fb_helper, fb_helper_conn = fb_helper->connector_info[i]; list_for_each_entry(mode, &fb_helper_conn->connector->modes, head) { - if (drm_mode_equal(mode, dmt_mode)) + if (drm_mode_match(mode, dmt_mode, + DRM_MODE_MATCH_TIMINGS | + DRM_MODE_MATCH_CLOCK | + DRM_MODE_MATCH_FLAGS | + DRM_MODE_MATCH_3D_FLAGS)) modes[i] = mode; } if (!modes[i]) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index d6133e8..454f2ff 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1049,7 +1049,8 @@ bool drm_mode_equal(const struct drm_display_mode *mode1, DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_CLOCK | DRM_MODE_MATCH_FLAGS | - DRM_MODE_MATCH_3D_FLAGS); + DRM_MODE_MATCH_3D_FLAGS| + DRM_MODE_MATCH_ASPECT_RATIO); } EXPORT_SYMBOL(drm_mode_equal); @@ -1647,6 +1648,20 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out, out->vrefresh = in->vrefresh; out->flags = in->flags; out->type = in->type; + + switch (in->picture_aspect_ratio) { + case HDMI_PICTURE_ASPECT_4_3: + out->flags |= DRM_MODE_FLAG_PIC_AR_4_3; + break; + case HDMI_PICTURE_ASPECT_16_9: + out->flags |= DRM_MODE_FLAG_PIC_AR_16_9; + break; + case HDMI_PICTURE_ASPECT_RESERVED: + default: + out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; + break; + } + strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN); out->name[DRM_DISPLAY_MODE_LEN-1] = 0; } @@ -1693,6 +1708,24 @@ int drm_mode_convert_umode(struct drm_device *dev, strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN); out->name[DRM_DISPLAY_MODE_LEN-1] = 0; + /* Clearing picture aspect ratio bits from out flags, +* as the aspect-ratio information is not stored in +* flags for kernel-mode, but in picture_aspect_ratio. +*/ + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK; + +
[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5
https://bugzilla.kernel.org/show_bug.cgi?id=199101 --- Comment #19 from Kevin McCormack (wittyma...@yahoo.com) --- Thanks for testing, Martin. This doesn't appear to be included in 4.16.3 looking at https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.16.3 and Arch just bumped the kernel from 4.15 to 4.16.3 so I'm holding back updating. Are we likely to see this included in 4.16.4? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 00/11] Aspect ratio support in DRM layer
From: Ankit Nautiyal This patch series is a re-attempt to enable aspect ratio support in DRM layer. Currently the aspect ratio information gets lost in translation during a user->kernel mode or vice versa. The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had 4 patches, out of which 2 patches were reverted due to lack of drm client protection while loading the aspect information. This patch series also includes 5 patches from Ville Syrjälä's series for 'Info-frame cleanup and fixes': https://patchwork.freedesktop.org/series/33730/ which fixes the mode matching mechanism via flags, and also ensures that no bogus aspect-ratios are sent in the AVI infoframes. This patch series, adds a DRM client option for aspect ratio, and loads aspect ratio flags, only when the client sets this cap. To test this patch, the testdiplay IGT test is modified to have an option to do a modeset with only aspect ratio modes. Also, there is a userspace implementation in Wayland/weston layer: https://patchwork.freedesktop.org/patch/188125/ (Which is already ACK'ed by wayland community.) This, helps us in passing HDMI compliance test cases like 7-27, where the test equipment applies a CEA mode, and expects the exact VIC in the AVI infoframes. Ankit Nautiyal (4): drm: Add DRM client cap for aspect-ratio drm: Add helper functions to handle aspect-ratio flag bits drm: Handle aspect ratio info in legacy and atomic modeset paths drm: Expose modes with aspect ratio, only if requested Sharma, Shashank (2): drm: Add aspect ratio parsing in DRM layer drm: Add and handle new aspect ratios in DRM layer Ville Syrjälä (5): drm/modes: Introduce drm_mode_match() drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy drm/edid: Fix cea mode aspect ratio handling drm/edid: Don't send bogus aspect ratios in AVI infoframes video/hdmi: Reject illegal picture aspect ratios drivers/gpu/drm/drm_atomic.c| 34 -- drivers/gpu/drm/drm_atomic_helper.c | 6 +- drivers/gpu/drm/drm_connector.c | 56 +++-- drivers/gpu/drm/drm_crtc.c | 8 ++ drivers/gpu/drm/drm_crtc_internal.h | 3 +- drivers/gpu/drm/drm_edid.c | 41 +-- drivers/gpu/drm/drm_fb_helper.c | 12 +- drivers/gpu/drm/drm_ioctl.c | 9 ++ drivers/gpu/drm/drm_mode_object.c | 9 +- drivers/gpu/drm/drm_modes.c | 226 +++- drivers/video/hdmi.c| 3 + include/drm/drm_atomic.h| 5 +- include/drm/drm_file.h | 8 ++ include/drm/drm_modes.h | 13 +++ include/uapi/drm/drm.h | 7 ++ include/uapi/drm/drm_mode.h | 6 + 16 files changed, 377 insertions(+), 69 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 03/11] drm/edid: Fix cea mode aspect ratio handling
From: Ville Syrjälä commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add aspect ratio handing back we need to be more careful. Let's handle this by considering the aspect ratio as a requirement for cea mode matching only if the passed in mode actually has a non-zero aspect ratio field. This will keep userspace that doesn't provide an aspect ratio working as before by matching it to the first otherwise equal cea mode. And once userspace starts to provide the aspect ratio it will be considerd a hard requirement for the match. Also change the hdmi mode matching to use drm_mode_match() for consistency, but we don't match on aspect ratio there since the spec doesn't list a specific aspect ratio for those modes. Cc: Shashank Sharma Cc: "Lin, Jia" Cc: Akashdeep Sharma Cc: Jim Bride Cc: Jose Abreu Cc: Daniel Vetter Cc: Emil Velikov Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma --- drivers/gpu/drm/drm_edid.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index c35d3bc..29c88eb 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2930,11 +2930,15 @@ cea_mode_alternate_timings(u8 vic, struct drm_display_mode *mode) static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode *to_match, unsigned int clock_tolerance) { + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; u8 vic; if (!to_match->clock) return 0; + if (to_match->picture_aspect_ratio) + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO; + for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) { struct drm_display_mode cea_mode = edid_cea_modes[vic]; unsigned int clock1, clock2; @@ -2948,7 +2952,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode *to_m continue; do { - if (drm_mode_equal_no_clocks_no_stereo(to_match, &cea_mode)) + if (drm_mode_match(to_match, &cea_mode, match_flags)) return vic; } while (cea_mode_alternate_timings(vic, &cea_mode)); } @@ -2965,11 +2969,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode *to_m */ u8 drm_match_cea_mode(const struct drm_display_mode *to_match) { + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; u8 vic; if (!to_match->clock) return 0; + if (to_match->picture_aspect_ratio) + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO; + for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) { struct drm_display_mode cea_mode = edid_cea_modes[vic]; unsigned int clock1, clock2; @@ -2983,7 +2991,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode *to_match) continue; do { - if (drm_mode_equal_no_clocks_no_stereo(to_match, &cea_mode)) + if (drm_mode_match(to_match, &cea_mode, match_flags)) return vic; } while (cea_mode_alternate_timings(vic, &cea_mode)); } @@ -3030,6 +3038,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode) static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_match, unsigned int clock_tolerance) { + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; u8 vic; if (!to_match->clock) @@ -3047,7 +3056,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_ abs(to_match->clock - clock2) > clock_tolerance) continue; - if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode)) + if (drm_mode_match(to_match, hdmi_mode, match_flags)) return vic; } @@ -3064,6 +3073,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_ */ static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match) { + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; u8 vic; if (!to_match->clock) @@ -3079,7 +3089,7 @@ static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match) if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) || KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) && - drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode)) + drm_mode_match(to_match, hdmi_mode, m
Re: [PATCH 0/2] drm/exynos/mixer: fixes for interlaced mode
On 12.03.2018 08:12, Andrzej Hajda wrote: > On 20.02.2018 07:45, Andrzej Hajda wrote: >> Hi Inki, >> >> On 02.02.2018 16:11, Andrzej Hajda wrote: >>> Hi Inki, Tobias, >>> >>> This is reviewed/updated/tested Tobias's patch addressing page-faults >>> in Video Processor in interlaced mode. Plus preliminary patch fixing Mixer >>> interlaced mode. >>> >>> Regards >>> Andrzej >> Gentle ping. > Ping. Ping, almost three months passed. Regards Andrzej > > -- > Regards > Andrzej > >> Regards >> Andrzej >> >>> Andrzej Hajda (1): >>> drm/exynos/mixer: fix synchronization check in interlaced mode >>> >>> Tobias Jakobi (1): >>> drm/exynos: mixer: avoid Oops in vp_video_buffer() >>> >>> drivers/gpu/drm/exynos/exynos_mixer.c | 22 +- >>> drivers/gpu/drm/exynos/regs-mixer.h | 1 + >>> 2 files changed, 18 insertions(+), 5 deletions(-) >>> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits
From: Ankit Nautiyal This patch adds helper functions for determining if aspect-ratio is expected in user-mode and for allowing/disallowing the aspect-ratio, if its not expected. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/drm_modes.c | 47 + include/drm/drm_modes.h | 4 2 files changed, 51 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index c395a24..d6133e8 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1759,3 +1759,50 @@ bool drm_mode_is_420(const struct drm_display_info *display, drm_mode_is_420_also(display, mode); } EXPORT_SYMBOL(drm_mode_is_420); + +/** + * drm_mode_aspect_ratio_allowed - checks if the aspect-ratio information + * is expected from the user-mode. + * + * If the user has set aspect-ratio cap, then the flag of the user-mode is + * allowed to contain aspect-ratio value. + * If the user does not set aspect-ratio cap, then the only value allowed in the + * flags bits is aspect-ratio NONE. + * + * @file_priv: file private structure to get the user capabilities + * @umode: drm_mode_modeinfo struct, whose flag carry the aspect ratio + * information. + * + * Returns: + * true if the aspect-ratio info is allowed in the user-mode flags. + * false, otherwise. + */ +bool +drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv, + struct drm_mode_modeinfo *umode) +{ + return file_priv->aspect_ratio_allowed || (umode->flags & + DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE; +} +EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed); + +/** + * drm_mode_filter_aspect_ratio_flags - filters the aspect-ratio bits in the + * user-mode flags. + * + * Checks if the aspect-ratio information is allowed. Resets the aspect-ratio + * bits in the user-mode flags, if aspect-ratio info is not allowed. + * + * @file_priv: file private structure to get the user capabilities. + * @umode: drm_mode_modeinfo struct, whose flags' aspect-ratio bits needs to + * be filtered. + * + */ +void +drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv, + struct drm_mode_modeinfo *umode) +{ + if (!drm_mode_aspect_ratio_allowed(file_priv, umode)) + umode->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK; +} +EXPORT_SYMBOL(drm_mode_filter_aspect_ratio_flags); diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h index 2f78b7e..e0b060d 100644 --- a/include/drm/drm_modes.h +++ b/include/drm/drm_modes.h @@ -461,6 +461,10 @@ bool drm_mode_is_420_also(const struct drm_display_info *display, const struct drm_display_mode *mode); bool drm_mode_is_420(const struct drm_display_info *display, const struct drm_display_mode *mode); +bool drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv, + struct drm_mode_modeinfo *umode); +void drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv, + struct drm_mode_modeinfo *umode); struct drm_display_mode *drm_cvt_mode(struct drm_device *dev, int hdisplay, int vdisplay, int vrefresh, -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106073] RX480 gfx_v8_0_ring_test_ib [amdgpu]] *ERROR* amdgpu: IB test timed out.
https://bugs.freedesktop.org/show_bug.cgi?id=106073 Gabriel Rauter changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Gabriel Rauter --- Not sure what changed it, but I haven't seen the error anymore so I think this can be closed 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 104439] intel_do_flush_locked failed: Invalid argument
https://bugs.freedesktop.org/show_bug.cgi?id=104439 --- Comment #11 from magiblot --- It has been working fine for me for quite a time with the 4.15 kernel as well. -- 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 4/8] dma-buf: add peer2peer flag
On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote: > > > What we need is an sg_alloc_table_from_resources(dev, resources, > > > num_resources) which does the handling common to all drivers. > > A structure that contains > > > > {page,offset,len} + {dma_addr+dma_len} > > > > is not a good container for storing > > > > {virt addr, dma_addr, len} > > > > no matter what interface you build arond it. > > Why not? I mean at least for my use case we actually don't need the virtual > address. If you don't need the virtual address you need scatterlist even list. > What we need is {dma_addr+dma_len} in a consistent interface which can come > from both {page,offset,len} as well as {resource, len}. Ok. > What I actually don't need is separate handling for system memory and > resources, but that would we get exactly when we don't use sg_table. At the very lowest level they will need to be handled differently for many architectures, the questions is at what point we'll do the branching out. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Pass connector state to the bridge enable and disable handlers
To allow bridge drivers to access state data such as the active mode in their enable and disable handlers, pass a pointer to the connector state to those handlers. From there the CRTC state can be accessed through conn_state->crtc->state. Signed-off-by: Laurent Pinchart Reviewed-by: Sean Paul --- Changes since v1: - Update the new thc63lvd1024 driver I haven't CC'ed all the individual drivers maintainers, as doing so on v1 seems to have exceeded the maximum number of recipients allowed by the mailing list and prevented the mail from reaching the list. --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 ++-- drivers/gpu/drm/bridge/analogix-anx78xx.c | 6 ++-- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16 +++ drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 ++-- drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 +++ drivers/gpu/drm/bridge/panel.c | 12 +--- drivers/gpu/drm/bridge/parade-ps8622.c | 12 +--- drivers/gpu/drm/bridge/sii902x.c | 6 ++-- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 ++-- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 8 -- drivers/gpu/drm/bridge/tc358767.c | 12 +--- drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++-- drivers/gpu/drm/drm_atomic_helper.c| 8 +++--- drivers/gpu/drm/drm_bridge.c | 32 ++ drivers/gpu/drm/drm_crtc_helper.c | 20 +++--- drivers/gpu/drm/exynos/exynos_drm_mic.c| 16 --- drivers/gpu/drm/mediatek/mtk_hdmi.c| 12 +--- drivers/gpu/drm/msm/dsi/dsi_manager.c | 12 +--- drivers/gpu/drm/msm/edp/edp_bridge.c | 12 +--- drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 12 +--- drivers/gpu/drm/rcar-du/rcar_lvds.c| 6 ++-- drivers/gpu/drm/sti/sti_dvo.c | 9 -- drivers/gpu/drm/sti/sti_hda.c | 9 -- drivers/gpu/drm/sti/sti_hdmi.c | 9 -- include/drm/drm_bridge.h | 25 +++-- 25 files changed, 190 insertions(+), 104 deletions(-) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index efa29db5fc2b..7e8d4f10ad53 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -812,14 +812,16 @@ static struct adv7511 *bridge_to_adv7511(struct drm_bridge *bridge) return container_of(bridge, struct adv7511, bridge); } -static void adv7511_bridge_enable(struct drm_bridge *bridge) +static void adv7511_bridge_enable(struct drm_bridge *bridge, + const struct drm_connector_state *conn_state) { struct adv7511 *adv = bridge_to_adv7511(bridge); adv7511_power_on(adv); } -static void adv7511_bridge_disable(struct drm_bridge *bridge) +static void adv7511_bridge_disable(struct drm_bridge *bridge, + const struct drm_connector_state *conn_state) { struct adv7511 *adv = bridge_to_adv7511(bridge); diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix-anx78xx.c index b49043866be6..73f1ed6c6d1f 100644 --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c @@ -1072,7 +1072,8 @@ anx78xx_bridge_mode_valid(struct drm_bridge *bridge, return MODE_OK; } -static void anx78xx_bridge_disable(struct drm_bridge *bridge) +static void anx78xx_bridge_disable(struct drm_bridge *bridge, + const struct drm_connector_state *conn_state) { struct anx78xx *anx78xx = bridge_to_anx78xx(bridge); @@ -1109,7 +1110,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge *bridge, mutex_unlock(&anx78xx->lock); } -static void anx78xx_bridge_enable(struct drm_bridge *bridge) +static void anx78xx_bridge_enable(struct drm_bridge *bridge, + const struct drm_connector_state *conn_state) { struct anx78xx *anx78xx = bridge_to_anx78xx(bridge); int err; diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 5c52307146c7..217428b7e589 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -1140,7 +1140,8 @@ static int analogix_dp_bridge_attach(struct drm_bridge *bridge) return 0; } -static void analogix_dp_bridge_pre_enable(struct drm_bridge *bridge) +static void analogix_dp_bridge_pre_enable(struct drm_bridge *bridge, + const struct drm_connector_state *conn_state) { struct analogix_dp_device *dp = bridge->driver_private; int ret; @@ -1150,7 +1151,8 @@ stati
[PATCH v4 2/2] drm/vc4: Add CTM registers to debugfs
Now that we set the OLED* registers to do CTM, it's helpful to have them in the register dump. Signed-off-by: Stefan Schake --- v4: new in the series. drivers/gpu/drm/vc4/vc4_hvs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c index 2b62fc5b8d85..5d8c749c9749 100644 --- a/drivers/gpu/drm/vc4/vc4_hvs.c +++ b/drivers/gpu/drm/vc4/vc4_hvs.c @@ -58,6 +58,10 @@ static const struct { HVS_REG(SCALER_DISPSTAT2), HVS_REG(SCALER_DISPBASE2), HVS_REG(SCALER_DISPALPHA2), + HVS_REG(SCALER_OLEDOFFS), + HVS_REG(SCALER_OLEDCOEF0), + HVS_REG(SCALER_OLEDCOEF1), + HVS_REG(SCALER_OLEDCOEF2), }; void vc4_hvs_dump_state(struct drm_device *dev) -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] drm/vc4: Add CTM support
The hardware has a single block for applying a CTM prior to gamma lut. It can be fed with pixels from one of our CRTC at a time and uses a matrix with S0.9 scalars. Use private atomic state to reject attempts from userland to apply CTM for more than one CRTC at a time and reject matrices with scalars that we can't approximate without integer bits. Signed-off-by: Stefan Schake Signed-off-by: Eric Anholt --- Eric, I removed your r-b since there were a bunch more changes. v4: Handle CTM disabling in check Don't use drm_atomic_get_private_obj_state in commit Fix S31.32 -> S0.9 conversion Squashed in Erics fixup series: Don't take the CTM lock unless a CTM change is happening (Eric) Lock across changes to the CTM (Eric) Handle allocation failure in out CTM priv state (Eric) Move CTM object init before FBDEV setup (Eric) Clean up the CTM private object manager on unload (Eric) v3: New in the series. drivers/gpu/drm/vc4/vc4_crtc.c | 5 + drivers/gpu/drm/vc4/vc4_drv.c | 3 + drivers/gpu/drm/vc4/vc4_drv.h | 4 + drivers/gpu/drm/vc4/vc4_kms.c | 204 - 4 files changed, 215 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c index 08fe8dd7d8df..83d3b7912fc2 100644 --- a/drivers/gpu/drm/vc4/vc4_crtc.c +++ b/drivers/gpu/drm/vc4/vc4_crtc.c @@ -1018,6 +1018,11 @@ static int vc4_crtc_bind(struct device *dev, struct device *master, void *data) drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r)); drm_crtc_enable_color_mgmt(crtc, 0, false, crtc->gamma_size); + /* We support CTM, but only for one CRTC at a time. It's therefore +* implemented as private driver state in vc4_kms, not here. +*/ + drm_crtc_enable_color_mgmt(crtc, 0, true, crtc->gamma_size); + /* Set up some arbitrary number of planes. We're not limited * by a set number of physical registers, just the space in * the HVS (16k) and how small an plane can be (28 bytes). diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 94b99c90425a..52bfe0e9ddda 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -320,6 +320,7 @@ static void vc4_drm_unbind(struct device *dev) { struct platform_device *pdev = to_platform_device(dev); struct drm_device *drm = platform_get_drvdata(pdev); + struct vc4_dev *vc4 = to_vc4_dev(drm); drm_dev_unregister(drm); @@ -327,6 +328,8 @@ static void vc4_drm_unbind(struct device *dev) drm_mode_config_cleanup(drm); + drm_atomic_private_obj_fini(&vc4->ctm_manager); + drm_dev_unref(drm); } diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h index 4288615b66a2..22589d39083c 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.h +++ b/drivers/gpu/drm/vc4/vc4_drv.h @@ -10,6 +10,7 @@ #include #include #include +#include #include "uapi/drm/vc4_drm.h" @@ -193,6 +194,9 @@ struct vc4_dev { } hangcheck; struct semaphore async_modeset; + + struct drm_modeset_lock ctm_state_lock; + struct drm_private_obj ctm_manager; }; static inline struct vc4_dev * diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index e791e498a3dd..8a411e5f8776 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -23,6 +23,117 @@ #include #include #include "vc4_drv.h" +#include "vc4_regs.h" + +struct vc4_ctm_state { + struct drm_private_state base; + struct drm_color_ctm *ctm; + int fifo; +}; + +static struct vc4_ctm_state *to_vc4_ctm_state(struct drm_private_state *priv) +{ + return container_of(priv, struct vc4_ctm_state, base); +} + +static struct vc4_ctm_state *vc4_get_ctm_state(struct drm_atomic_state *state, + struct drm_private_obj *manager) +{ + struct drm_device *dev = state->dev; + struct vc4_dev *vc4 = dev->dev_private; + struct drm_private_state *priv_state; + int ret; + + ret = drm_modeset_lock(&vc4->ctm_state_lock, state->acquire_ctx); + if (ret) + return ERR_PTR(ret); + + priv_state = drm_atomic_get_private_obj_state(state, manager); + if (IS_ERR(priv_state)) + return ERR_CAST(priv_state); + + return to_vc4_ctm_state(priv_state); +} + +static struct drm_private_state * +vc4_ctm_duplicate_state(struct drm_private_obj *obj) +{ + struct vc4_ctm_state *state; + + state = kmemdup(obj->state, sizeof(*state), GFP_KERNEL); + if (!state) + return NULL; + + __drm_atomic_helper_private_obj_duplicate_state(obj, &state->base); + + return &state->base; +} + +static void vc4_ctm_destroy_state(struct drm_private_obj *obj, + struct drm_private_state *state) +{ + struct vc4_ctm_s
[Bug 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #88 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- Great, thanks.(In reply to Ricardo Ribalda from comment #87) > Hi Andrey > > I have been running some manual tests (~30 boots) and it has been always ok. > I did not have time to setup an automatic test machine. > > You are more than welcome to close the ticket and I will update it with the > results later. > > Thanks for your help! Great, thanks. Andrey -- 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 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #87 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- Hi Andrey I have been running some manual tests (~30 boots) and it has been always ok. I did not have time to setup an automatic test machine. You are more than welcome to close the ticket and I will update it with the results later. Thanks for your help! -- 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 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #86 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- Hi, any updates (In reply to Andrey Grodzovsky from comment #85) > (In reply to Ricardo Ribalda from comment #84) > > Hi Andrey > > > > I have removed the GALLIUM_DDEBUG=flush hack and performed around 10 > boots. > > I have not been able to replicate the bug. > > > > I am porting the patch to my current distro and will run the test there for > > a couple of hours (hopefully tomorrow). But It looks pretty good! > > > > Kudos! > > Ping me once it's done. > > Thanks. Any updates ? Andrey -- 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 104439] intel_do_flush_locked failed: Invalid argument
https://bugs.freedesktop.org/show_bug.cgi?id=104439 --- Comment #10 from Francesco Turco --- I can't reproduce this bug anymore with the Falkon 3.0.0 web browser and the Linux 4.16.2 kernel. -- 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 v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc
Hi Peter, On Fri, Apr 20, 2018 at 01:05:21PM +0200, Peter Rosin wrote: > On 2018-04-20 12:18, Laurent Pinchart wrote: > > Hello, > > > > On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote: > >> Hi Peter, > >> I've been a bit a pain in the arse for you recently, but please > >> bear with me a bit more, and sorry for jumping late on the band wagon. > >> > >> On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote: > >>> Hi! > >>> > >>> I naively thought that since there was support for both nxp,tda19988 (in > >>> the tda998x driver) and the atmel-hlcdc, things would be a smooth ride. > >>> But it wasn't, so I started looking around and realized I had to fix > >>> things. > >>> > >>> In v1 and v2 I fixed things by making the atmel-hlcdc driver a master > >>> component, but now in v3 I fix things by making the tda998x driver > >>> a bridge instead. This was after a suggestion from Boris Brezillion > > That should be Brezillon, sorry for being sloppy with the spelling. > > >>> (the atmel-hlcdc maintainer), so there was some risk of bias ... but > >>> after comparing what was needed, I too find the bridge approach better. > >>> > >>> In addition to the above, our PCB interface between the SAMA5D3 and the > >>> HDMI encoder is only using 16 bits, and this has to be described > >>> somewhere, or the atmel-hlcdc driver have no chance of selecting the > >>> correct output mode. Since I have similar problems with a ds90c185 lvds > >>> encoder I added patches to override the atmel-hlcdc output format via > >>> DT properties compatible with the media video-interface binding and > >>> things start to play together. > >>> > >>> Since this series superseeds the bridge series [1], I have included the > >>> leftover bindings patch for the ti,ds90c185 here. > >> > >> I feel like this series would look better if it would make use of the > >> proposed bridge media bus format support I have recently sent out [1] > >> (and which was not there when you first sent v1). > >> > >> I understand your fundamental problem here is that the bus format > >> that should be reported by your bridge is different from the ones > >> actually supported by the TDA19988 chip, as the wirings ground some > >> of the input pins. > >> > >> Although this is defintely something that could be described in the > >> bridge's own OF node with the 'bus_width' property, and what I would do, > >> now that you have made a bridge out from the tda19988 driver, is: > >> > >> 1) Set the bridge accepted input bus_format parsing its pin > >> configuration, or default it if that's not implemented yet. > >> This will likely be rgb888. You can do that using the trivial > >> support for bridge input image formats implemented by my series. > >> 2) Specify in the bridge endpoint a 'bus_width' of <16> > >> 3) In your atmel-hlcd get both the image format of the bridge (rgb888) > >> and parse the remote endpoint property 'bus_width' and get the <16> > >> value back. > > > > Parsing properties of remote nodes should be avoided as much as possible, as > > they need to be interpreted in the context of the DT bindings related to the > > compatible string applicable to that node. I'd rather have the bus_width > > property in the local endpoint node. > > In addition to that, my view of this binding > > endpoint { > bus-type = <0>; bus-type is used by v4l2_fwnode helpers to decide which type of bus they're dealing with iirc. Here it seems to me it has no added value, also because in your bindings description "it shall be 0" and it is not parsed anywhere in you code, but no big deal > bus-widht = <16>; > }; > > is that it always means rgb565. See further below. > > >> 4) Set the correct format in the atmel hlcd driver to accommodate a > >> bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565, > >> or are there other possible combinations I am missing?) > >> > >> I would consider this better mostly because in this series you are > >> creating a semantic for the whole DRM subsystem on the 'bus_width' > >> property, where numerical values as '12', '16' etc are arbitrary tied > >> to the selection of a media bus format. At least you should use a > >> common set of defines [1] between the device tree and the driver, > >> but this looks anyway fragile imho. > > > > This I agree with though. Combining the remote bus format with the local bus > > width should fix the problem without having to parse remote properties. > > My thinking was that the binding with bus-type = <0> and bus-width = > would mean a parallel bus (type 0 means auto-detect and with a bus-width that > auto-detect means a parallel bus) and the most natural/common interpretation > of that bus-width. For bus widths of 12, 16, 18, 24, 30 etc I think that > would be rgb444, rgb565, rgb666, rgb888, rgb101010 (or, I'm first so I get > to define the default). If you have some other interpretation of a bus with > that width, you'd need to extend the video-i
[Bug 104723] [CI] igt@[kms_3d|igt@kms_panel_fitting] - fail - Could not open data file "1080p-left.png": No such file or directoryReceived signal SIGSEGV.
https://bugs.freedesktop.org/show_bug.cgi?id=104723 Marta Löfstedt changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 103924] [CI] igt@perf_pmu@other-* - fail - Test assertion failure function read_other - Failed assertion: fd >= 0
https://bugs.freedesktop.org/show_bug.cgi?id=103924 Marta Löfstedt changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On 04/20/2018 10:19 AM, Daniel Vetter wrote: On Wed, Apr 18, 2018 at 11:10:58AM +0100, Roger Pau Monné wrote: On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote: On 04/18/2018 10:35 AM, Roger Pau Monné wrote: On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: On 04/17/2018 11:57 PM, Dongwon Kim wrote: On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: 3.2 Backend exports dma-buf to xen-front In this case Dom0 pages are shared with DomU. As before, DomU can only write to these pages, not any other page from Dom0, so it can be still considered safe. But, the following must be considered (highlighted in xen-front's Kernel documentation): - If guest domain dies then pages/grants received from the backend cannot be claimed back - think of it as memory lost to Dom0 (won't be used for any other guest) - Misbehaving guest may send too many requests to the backend exhausting its grant references and memory (consider this from security POV). As the backend runs in the trusted domain we also assume that it is trusted as well, e.g. must take measures to prevent DDoS attacks. I cannot parse the above sentence: "As the backend runs in the trusted domain we also assume that it is trusted as well, e.g. must take measures to prevent DDoS attacks." What's the relation between being trusted and protecting from DoS attacks? I mean that we trust the backend that it can prevent Dom0 from crashing in case DomU's frontend misbehaves, e.g. if the frontend sends too many memory requests etc. In any case, all? PV protocols are implemented with the frontend sharing pages to the backend, and I think there's a reason why this model is used, and it should continue to be used. This is the first use-case above. But there are real-world use-cases (embedded in my case) when physically contiguous memory needs to be shared, one of the possible ways to achieve this is to share contiguous memory from Dom0 to DomU (the second use-case above) Having to add logic in the backend to prevent such attacks means that: - We need more code in the backend, which increases complexity and chances of bugs. - Such code/logic could be wrong, thus allowing DoS. You can live without this code at all, but this is then up to backend which may make Dom0 down because of DomU's frontend doing evil things IMO we should design protocols that do not allow such attacks instead of having to defend against them. 4. xen-front/backend/xen-zcopy synchronization 4.1. As I already said in 2) all the inter VM communication happens between xen-front and the backend, xen-zcopy is NOT involved in that. When xen-front wants to destroy a display buffer (dumb/dma-buf) it issues a XENDISPL_OP_DBUF_DESTROY command (opposite to XENDISPL_OP_DBUF_CREATE). This call is synchronous, so xen-front expects that backend does free the buffer pages on return. 4.2. Backend, on XENDISPL_OP_DBUF_DESTROY: - closes all dumb handles/fd's of the buffer according to [3] - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen-zcopy to make sure the buffer is freed (think of it as it waits for dma-buf->release callback) So this zcopy thing keeps some kind of track of the memory usage? Why can't the user-space backend keep track of the buffer usage? Because there is no dma-buf UAPI which allows to track the buffer life cycle (e.g. wait until dma-buf's .release callback is called) - replies to xen-front that the buffer can be destroyed. This way deletion of the buffer happens synchronously on both Dom0 and DomU sides. In case if DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE returns with time-out error (BTW, wait time is a parameter of this IOCTL), Xen will defer grant reference removal and will retry later until those are free. Hope this helps understand how buffers are synchronously deleted in case of xen-zcopy with a single protocol command. I think the above logic can also be re-used by the hyper-dmabuf driver with some additional work: 1. xen-zcopy can be split into 2 parts and extend: 1.1. Xen gntdev driver [4], [5] to allow creating dma-buf from grefs and vise versa, I don't know much about the dma-buf implementation in Linux, but gntdev is a user-space device, and AFAICT user-space applications don't have any notion of dma buffers. How are such buffers useful for user-space? Why can't this just be called memory? A dma-buf is seen by user-space as a file descriptor and you can pass it to different drivers then. For example, you can share a buffer used by a display driver for scanout with a GPU, to compose a picture into it: 1. User-space (US) allocates a display buffer from display driver 2. US asks display driver to export the dma-buf which backs up that buffer, US gets buffer's fd: dma_buf_fd 3. US asks GPU driver to import a buffer and provides it with dma_buf_fd 4. GPU renders contents into display buffer
Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc
Hi Laurent, On Fri, Apr 20, 2018 at 01:18:13PM +0300, Laurent Pinchart wrote: > Hello, > > On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote: > > Hi Peter, > > I've been a bit a pain in the arse for you recently, but please > > bear with me a bit more, and sorry for jumping late on the band wagon. > > > > On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote: > > > Hi! > > > > > > I naively thought that since there was support for both nxp,tda19988 (in > > > the tda998x driver) and the atmel-hlcdc, things would be a smooth ride. > > > But it wasn't, so I started looking around and realized I had to fix > > > things. > > > > > > In v1 and v2 I fixed things by making the atmel-hlcdc driver a master > > > component, but now in v3 I fix things by making the tda998x driver > > > a bridge instead. This was after a suggestion from Boris Brezillion > > > (the atmel-hlcdc maintainer), so there was some risk of bias ... but > > > after comparing what was needed, I too find the bridge approach better. > > > > > > In addition to the above, our PCB interface between the SAMA5D3 and the > > > HDMI encoder is only using 16 bits, and this has to be described > > > somewhere, or the atmel-hlcdc driver have no chance of selecting the > > > correct output mode. Since I have similar problems with a ds90c185 lvds > > > encoder I added patches to override the atmel-hlcdc output format via > > > DT properties compatible with the media video-interface binding and > > > things start to play together. > > > > > > Since this series superseeds the bridge series [1], I have included the > > > leftover bindings patch for the ti,ds90c185 here. > > > > I feel like this series would look better if it would make use of the > > proposed bridge media bus format support I have recently sent out [1] > > (and which was not there when you first sent v1). > > > > I understand your fundamental problem here is that the bus format > > that should be reported by your bridge is different from the ones > > actually supported by the TDA19988 chip, as the wirings ground some > > of the input pins. > > > > Although this is defintely something that could be described in the > > bridge's own OF node with the 'bus_width' property, and what I would do, > > now that you have made a bridge out from the tda19988 driver, is: > > > > 1) Set the bridge accepted input bus_format parsing its pin > > configuration, or default it if that's not implemented yet. > > This will likely be rgb888. You can do that using the trivial > > support for bridge input image formats implemented by my series. > > 2) Specify in the bridge endpoint a 'bus_width' of <16> > > 3) In your atmel-hlcd get both the image format of the bridge (rgb888) > > and parse the remote endpoint property 'bus_width' and get the <16> > > value back. > > Parsing properties of remote nodes should be avoided as much as possible, as > they need to be interpreted in the context of the DT bindings related to the > compatible string applicable to that node. I'd rather have the bus_width > property in the local endpoint node. Right, I see... Well, in Peter's case, the bus width, being a consequence of wirings, can be described safely in both endpoints, right? > > > 4) Set the correct format in the atmel hlcd driver to accommodate a > > bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565, > > or are there other possible combinations I am missing?) > > > > I would consider this better mostly because in this series you are > > creating a semantic for the whole DRM subsystem on the 'bus_width' > > property, where numerical values as '12', '16' etc are arbitrary tied > > to the selection of a media bus format. At least you should use a > > common set of defines [1] between the device tree and the driver, > > but this looks anyway fragile imho. > > This I agree with though. Combining the remote bus format with the local bus > width should fix the problem without having to parse remote properties. > > > Have I maybe missed some parts of the problem you are trying to solve > > here? > > > > Thank you > >j > > > > [1] drm: bridge: Add support for static image formats > > https://lwn.net/Articles/752296/ > > [2] include/uapi/linux/media-bus-format.h > > > > > Anyway, this series solves some real issues for my HW. > > > > > > Cheers, > > > Peter > > > > > > Changes since v2 https://lkml.org/lkml/2018/4/17/385 > > > - patch 2/7 fixed spelling and added an example > > > - patch 4/7 parse the DT up front and store the result indexed by encoder > > > - old patch 5/6 and 6/6 dropped > > > - patch 5-7/7 are new and makes the tda998x driver a drm_bridge > > > > > > Changes since v1 https://lkml.org/lkml/2018/4/9/294 > > > - added reviewed-by from Rob to patch 1/6 > > > - patch 2/6 changed so that the bus format override is in the endpoint > > > DT node, and follows the binding of media video-interfaces. > > > - patch 3/6 is new, it adds drm_of_media_bus_fmt which parses above > > >
Re: [PATCH 4/8] dma-buf: add peer2peer flag
Am 20.04.2018 um 12:17 schrieb Christoph Hellwig: On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote: Yes there's a bit a layering violation insofar that drivers really shouldn't each have their own copy of "how do I convert a piece of dma memory into dma-buf", but that doesn't render the interface a bad idea. Completely agree on that. What we need is an sg_alloc_table_from_resources(dev, resources, num_resources) which does the handling common to all drivers. A structure that contains {page,offset,len} + {dma_addr+dma_len} is not a good container for storing {virt addr, dma_addr, len} no matter what interface you build arond it. Why not? I mean at least for my use case we actually don't need the virtual address. What we need is {dma_addr+dma_len} in a consistent interface which can come from both {page,offset,len} as well as {resource, len}. What I actually don't need is separate handling for system memory and resources, but that would we get exactly when we don't use sg_table. Christian. And that is discounting all the problems around mapping coherent allocations for other devices, or the iommu merging problem we are having another thread on. So let's come up with a better high level interface first, and then worrty about how to implement it in the low-level dma-mapping interface second. Especially given that my consolidation of the dma_map_ops implementation is in full stream and there shoudn't be all that many to bother with. So first question: Do you actually care about having multiple pairs of the above, or instead of all chunks just deal with a single of the above? In that case we really should not need that many new interfaces as dma_map_resource will be all you need anyway. Christian. -Daniel ---end quoted text--- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge
Hi Peter, I love your patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on v4.17-rc1 next-20180420] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Peter-Rosin/Add-tda998x-HDMI-support-to-atmel-hlcdc/20180420-160131 base: git://people.freedesktop.org/~airlied/linux.git drm-next config: i386-randconfig-a0-201815 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/gpu/drm/i2c/tda998x_drv.c: In function 'tda998x_probe': >> drivers/gpu/drm/i2c/tda998x_drv.c:1859:16: error: 'struct drm_bridge' has no >> member named 'of_node' bridge->bridge.of_node = dev->of_node; ^ vim +1859 drivers/gpu/drm/i2c/tda998x_drv.c 1838 1839 static int 1840 tda998x_probe(struct i2c_client *client, const struct i2c_device_id *id) 1841 { 1842 struct device *dev = &client->dev; 1843 struct tda998x_bridge *bridge; 1844 int ret; 1845 1846 if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) { 1847 dev_warn(&client->dev, "adapter does not support I2C\n"); 1848 return -EIO; 1849 } 1850 1851 bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL); 1852 if (!bridge) 1853 return -ENOMEM; 1854 1855 bridge->dev = dev; 1856 dev_set_drvdata(dev, bridge); 1857 1858 bridge->bridge.funcs = &tda998x_bridge_funcs; > 1859 bridge->bridge.of_node = dev->of_node; 1860 drm_bridge_add(&bridge->bridge); 1861 1862 ret = component_add(dev, &tda998x_ops); 1863 1864 if (ret) 1865 drm_bridge_remove(&bridge->bridge); 1866 1867 return ret; 1868 } 1869 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays
Hi Tomi, On 20 April 2018 at 08:09, Tomi Valkeinen wrote: > It's actually not quite clear to me how manual update displays work with > DRM... > > As far as I see, we have essentially two cases: 1) single buffering, > where the userspace must set an area in the fb dirty, which then > triggers the update, 2) multi buffering, which doesn't need fb dirty, > but just a page flip which triggers the update. > > In the 2) case (which I think is the optimal case which all the modern > apps should use), there's no need for delayed work or any work, and the > code flow should be very similar to the auto-update model. Correct. There's been talk (and I think patches?) of adding a per-plane dirty property, so userspace can as an optimisation inform the kernel of the area changed between frames. But short of that, a pageflip needs to trigger a full-plane update, with no dirtyfb required. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers
Hi, On 20-04-18 09:27, Daniel Vetter wrote: On Thu, Apr 19, 2018 at 03:43:19PM +0200, Hans de Goede wrote: Hi, On 05-04-18 15:26, Daniel Vetter wrote: On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede wrote: Hi, On 05-04-18 09:14, Daniel Vetter wrote: On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goede wrote: Before this commit the WaSkipStolenMemoryFirstPage workaround code was skipping the first 4k by passing 4096 as start of the address range passed to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and reserve the firmware framebuffer so that we can inherit it would always fail, as the firmware framebuffer starts at address 0. Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on everything >= gen8") says in its commit message: "This is confirmed to fix Skylake screen flickering issues (probably caused by the fact that we initialized a ring in the first page of stolen, but I didn't 100% confirm this theory)." Which suggests that it is safe to use the first page for a linear framebuffer as the firmware is doing. This commit always passes 0 as start to drm_mm_init() and works around WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range() by insuring the start address passed by to drm_mm_insert_node_in_range() is always 4k or more. All entry points to i915_gem_stolen.c go through i915_gem_stolen_insert_node_in_range(), so that any newly allocated objects such as ring-buffers will not be allocated in the first 4k. The one exception is i915_gem_object_create_stolen_for_preallocated() which directly calls drm_mm_reserve_node() which now will be able to use the first 4k. This fixes the i915 driver no longer being able to inherit the firmware framebuffer on gen8+, which fixes the video output changing from the vendor logo to a black screen as soon as the i915 driver is loaded (on systems without fbcon). Signed-off-by: Hans de Goede I think this is worth a shot. The only explanation I can think of why the GOP could get away with this and still follow the w/a is if it doesn't have a 1:1 mapping between GGTT and stolen. My guess is that the GOP does not care about the w/a because the w/a states that the command-streamers sometimes do a spurious flush (write) to the first page, and the command-streamers are not used until much later, so the GOP is probably ignoring the w/a all together. At least that is my theory. Atm we do not know whether the GOP actually implements the wa or not. That it doesn't care is just a conjecture, but we have no proof. On previous platforms the 1:1 mapping did hold, but there's no fundamental reason why it sitll does. Right. Atm we hardcode that assumption in intel_alloc_initial_plane_obj by passing the base_aligned as both the stolen_offset and the gtt_offset (but it's only the gtt_offset really). And since we're not re-writing the ptes it's not noticeable. I think to decide whether this is the right approach we should double-check whether that 1:1 assumption really holds true: Either read back the ggtt ptes and check their addresses (but iirc on some platforms their write-only, readback doesn't work), or we also rewrite the ptes again for preallocated stuff, like when binding a normal object into the gtt. If either of these approaches confirms that those affected gen8+ machines still use the 1:1 mapping, then I'm happy to put my r-b on this patch. If not, well then we at least know what to fix: We need to read out the real stolen_offset, instead of making assumptions. I'm happy to give this a try on one or more affected machines, I can e.g. try this on both a skylake desktop and a cherry-trail based tablet. But I'm clueless about the whole PTE stuff, so I'm going to need someone to provide me with a patch following either approach. If readback of the PTEs works on skylake / cherrytrail I guess that would be the best way. Note to test this I'm currently booting the kernel with the machine's UEFI vendor logo still being displayed when efifb kicks in. I've added: "fbcon=vc:2-62" to the kernel commandline to make fbcon not bind to VC0 / VC1, so that the framebuffer contents stays intact, combined with the patch we are discussing now, this makes the vendor logo stay on the screen all the way till GDM loads, which looks rather nice actually :) And on shutdown we fall back to the original framebuffer and the vendor logo is back again. I cannot see any corruption in the display at either boot or shutdown time. It shouldn't matter whether efifb takes over or not, it's still the GOP's framebuffer we're taking over. Different content for sure, logo is gone, but we only care about which pages we're using. Wrt the code: - (Re)binding happens by calling i915_vma_bind, if you put a call to that at the end of the stolen_preallocated functions you should get that. Ofc needs the logo still there so you can see it jump/get mangled. - GGTT PTEs for gen8+ are written through e.g. gen8_ggttt_insert_page or gen8_gg
Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc
Hello, On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote: > Hi Peter, > I've been a bit a pain in the arse for you recently, but please > bear with me a bit more, and sorry for jumping late on the band wagon. > > On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote: > > Hi! > > > > I naively thought that since there was support for both nxp,tda19988 (in > > the tda998x driver) and the atmel-hlcdc, things would be a smooth ride. > > But it wasn't, so I started looking around and realized I had to fix > > things. > > > > In v1 and v2 I fixed things by making the atmel-hlcdc driver a master > > component, but now in v3 I fix things by making the tda998x driver > > a bridge instead. This was after a suggestion from Boris Brezillion > > (the atmel-hlcdc maintainer), so there was some risk of bias ... but > > after comparing what was needed, I too find the bridge approach better. > > > > In addition to the above, our PCB interface between the SAMA5D3 and the > > HDMI encoder is only using 16 bits, and this has to be described > > somewhere, or the atmel-hlcdc driver have no chance of selecting the > > correct output mode. Since I have similar problems with a ds90c185 lvds > > encoder I added patches to override the atmel-hlcdc output format via > > DT properties compatible with the media video-interface binding and > > things start to play together. > > > > Since this series superseeds the bridge series [1], I have included the > > leftover bindings patch for the ti,ds90c185 here. > > I feel like this series would look better if it would make use of the > proposed bridge media bus format support I have recently sent out [1] > (and which was not there when you first sent v1). > > I understand your fundamental problem here is that the bus format > that should be reported by your bridge is different from the ones > actually supported by the TDA19988 chip, as the wirings ground some > of the input pins. > > Although this is defintely something that could be described in the > bridge's own OF node with the 'bus_width' property, and what I would do, > now that you have made a bridge out from the tda19988 driver, is: > > 1) Set the bridge accepted input bus_format parsing its pin > configuration, or default it if that's not implemented yet. > This will likely be rgb888. You can do that using the trivial > support for bridge input image formats implemented by my series. > 2) Specify in the bridge endpoint a 'bus_width' of <16> > 3) In your atmel-hlcd get both the image format of the bridge (rgb888) > and parse the remote endpoint property 'bus_width' and get the <16> > value back. Parsing properties of remote nodes should be avoided as much as possible, as they need to be interpreted in the context of the DT bindings related to the compatible string applicable to that node. I'd rather have the bus_width property in the local endpoint node. > 4) Set the correct format in the atmel hlcd driver to accommodate a > bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565, > or are there other possible combinations I am missing?) > > I would consider this better mostly because in this series you are > creating a semantic for the whole DRM subsystem on the 'bus_width' > property, where numerical values as '12', '16' etc are arbitrary tied > to the selection of a media bus format. At least you should use a > common set of defines [1] between the device tree and the driver, > but this looks anyway fragile imho. This I agree with though. Combining the remote bus format with the local bus width should fix the problem without having to parse remote properties. > Have I maybe missed some parts of the problem you are trying to solve > here? > > Thank you >j > > [1] drm: bridge: Add support for static image formats > https://lwn.net/Articles/752296/ > [2] include/uapi/linux/media-bus-format.h > > > Anyway, this series solves some real issues for my HW. > > > > Cheers, > > Peter > > > > Changes since v2 https://lkml.org/lkml/2018/4/17/385 > > - patch 2/7 fixed spelling and added an example > > - patch 4/7 parse the DT up front and store the result indexed by encoder > > - old patch 5/6 and 6/6 dropped > > - patch 5-7/7 are new and makes the tda998x driver a drm_bridge > > > > Changes since v1 https://lkml.org/lkml/2018/4/9/294 > > - added reviewed-by from Rob to patch 1/6 > > - patch 2/6 changed so that the bus format override is in the endpoint > > DT node, and follows the binding of media video-interfaces. > > - patch 3/6 is new, it adds drm_of_media_bus_fmt which parses above > > media video-interface binding (partially). > > - patch 4/6 now makes use of the above helper (and also fixes problems > > with the 3/5 patch from v1 when no override was specified). > > - do not mention unrelated connector display_info details in the cover > > letter and commit messages. > > > > [1] > > "Bridge" series v2 https://lkml.org/lkml/2018/3/26/610 > > "Bridge" series v1
Re: [PATCH 4/8] dma-buf: add peer2peer flag
On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote: > > Yes there's a bit a layering violation insofar that drivers really > > shouldn't each have their own copy of "how do I convert a piece of dma > > memory into dma-buf", but that doesn't render the interface a bad idea. > > Completely agree on that. > > What we need is an sg_alloc_table_from_resources(dev, resources, > num_resources) which does the handling common to all drivers. A structure that contains {page,offset,len} + {dma_addr+dma_len} is not a good container for storing {virt addr, dma_addr, len} no matter what interface you build arond it. And that is discounting all the problems around mapping coherent allocations for other devices, or the iommu merging problem we are having another thread on. So let's come up with a better high level interface first, and then worrty about how to implement it in the low-level dma-mapping interface second. Especially given that my consolidation of the dma_map_ops implementation is in full stream and there shoudn't be all that many to bother with. So first question: Do you actually care about having multiple pairs of the above, or instead of all chunks just deal with a single of the above? In that case we really should not need that many new interfaces as dma_map_resource will be all you need anyway. > > Christian. > > > -Daniel > ---end quoted text--- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: fix vq wait_event condition
Reviewed-by: Dave Airlie On Fri., 20 Apr. 2018, 17:23 Gerd Hoffmann, wrote: > On Tue, Apr 03, 2018 at 11:59:04AM +0200, Gerd Hoffmann wrote: > > Wait until we have enough space in the virt queue to actually queue up > > our request. Avoids the guest spinning in case we have a non-zero > > amount of free entries but not enough for the request. > > Ping airlied, can you please either pick it up or review so I can commit > myself? > > thanks, > Gerd > > > Cc: sta...@vger.kernel.org > > Reported-by: Alain Magloire > > Signed-off-by: Gerd Hoffmann > > --- > > drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c > b/drivers/gpu/drm/virtio/virtgpu_vq.c > > index 48e4f1df6e..020070d483 100644 > > --- a/drivers/gpu/drm/virtio/virtgpu_vq.c > > +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c > > @@ -293,7 +293,7 @@ static int > virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device *vgdev, > > ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC); > > if (ret == -ENOSPC) { > > spin_unlock(&vgdev->ctrlq.qlock); > > - wait_event(vgdev->ctrlq.ack_queue, vq->num_free); > > + wait_event(vgdev->ctrlq.ack_queue, vq->num_free >= outcnt > + incnt); > > spin_lock(&vgdev->ctrlq.qlock); > > goto retry; > > } else { > > @@ -368,7 +368,7 @@ static int virtio_gpu_queue_cursor(struct > virtio_gpu_device *vgdev, > > ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC); > > if (ret == -ENOSPC) { > > spin_unlock(&vgdev->cursorq.qlock); > > - wait_event(vgdev->cursorq.ack_queue, vq->num_free); > > + wait_event(vgdev->cursorq.ack_queue, vq->num_free >= > outcnt); > > spin_lock(&vgdev->cursorq.qlock); > > goto retry; > > } else { > > -- > > 2.9.3 > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge
Hi Peter, Thank you for the patch. On Thursday, 19 April 2018 19:27:51 EEST Peter Rosin wrote: > This makes this driver work with all(?) drivers that are not > componentized and instead expect to connect to a panel/bridge. That > said, the only one tested is atmel_hlcdc. > > This hooks the relevant work function previously called by the encoder > and the component also to the bridge, since the encoder goes away when > connecting to the bridge interface of the driver and the equivalent of > bind/unbind of the component is handled by bridge attach/detach. > > The lifetime requirements of a bridge and a component are slightly > different, which is the reason for struct tda998x_bridge. Couldn't you move the allocation and initialization (tda998x_create) of the tda998x_priv structure to probe time ? I think you wouldn't need a separate structure in that case. Unless I'm mistaken there would be an added benefit of separating component and bridge initialization, resulting in the encoder not being initialized at all if the component isn't used. You wouldn't need to add a local_encoder parameter to the tda998x_init() function. > Signed-off-by: Peter Rosin > --- > drivers/gpu/drm/i2c/tda998x_drv.c | 157 --- > 1 file changed, 137 insertions(+), 20 deletions(-) > > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c > b/drivers/gpu/drm/i2c/tda998x_drv.c index 9c78f7bde49c..012dee61d817 100644 > --- a/drivers/gpu/drm/i2c/tda998x_drv.c > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c > @@ -36,6 +36,14 @@ struct tda998x_audio_port { > u8 config; /* AP value */ > }; > > +struct tda998x_priv; > + > +struct tda998x_bridge { > + struct tda998x_priv *priv; > + struct device *dev; > + struct drm_bridge bridge; > +}; > + > struct tda998x_priv { > struct i2c_client *cec; > struct i2c_client *hdmi; > @@ -63,6 +71,8 @@ struct tda998x_priv { > wait_queue_head_t edid_delay_waitq; > bool edid_delay_active; > > + struct tda998x_bridge *bridge; > + bool local_encoder; > struct drm_encoder encoder; > struct drm_connector connector; > > @@ -75,6 +85,9 @@ struct tda998x_priv { > #define enc_to_tda998x_priv(x) \ > container_of(x, struct tda998x_priv, encoder) > > +#define bridge_to_tda998x_bridge(x) \ > + container_of(x, struct tda998x_bridge, bridge) > + > /* The TDA9988 series of devices use a paged register scheme.. to simplify > * things we encode the page # in upper bits of the register #. To read/ > * write a given register, we need to make sure CURPAGE register is set > @@ -842,7 +855,8 @@ static int tda998x_audio_hw_params(struct device *dev, > void *data, struct hdmi_codec_daifmt *daifmt, > struct hdmi_codec_params *params) > { > - struct tda998x_priv *priv = dev_get_drvdata(dev); > + struct tda998x_bridge *bridge = dev_get_drvdata(dev); > + struct tda998x_priv *priv = bridge->priv; > int i, ret; > struct tda998x_audio_params audio = { > .sample_width = params->sample_width, > @@ -899,7 +913,8 @@ static int tda998x_audio_hw_params(struct device *dev, > void *data, > > static void tda998x_audio_shutdown(struct device *dev, void *data) > { > - struct tda998x_priv *priv = dev_get_drvdata(dev); > + struct tda998x_bridge *bridge = dev_get_drvdata(dev); > + struct tda998x_priv *priv = bridge->priv; > > mutex_lock(&priv->audio_mutex); > > @@ -912,7 +927,8 @@ static void tda998x_audio_shutdown(struct device *dev, > void *data) > > int tda998x_audio_digital_mute(struct device *dev, void *data, bool enable) > { > - struct tda998x_priv *priv = dev_get_drvdata(dev); > + struct tda998x_bridge *bridge = dev_get_drvdata(dev); > + struct tda998x_priv *priv = bridge->priv; > > mutex_lock(&priv->audio_mutex); > > @@ -925,7 +941,8 @@ int tda998x_audio_digital_mute(struct device *dev, void > *data, bool enable) static int tda998x_audio_get_eld(struct device *dev, > void *data, >uint8_t *buf, size_t len) > { > - struct tda998x_priv *priv = dev_get_drvdata(dev); > + struct tda998x_bridge *bridge = dev_get_drvdata(dev); > + struct tda998x_priv *priv = bridge->priv; > > mutex_lock(&priv->audio_mutex); > memcpy(buf, priv->connector.eld, > @@ -1126,7 +1143,10 @@ tda998x_connector_best_encoder(struct drm_connector > *connector) { > struct tda998x_priv *priv = conn_to_tda998x_priv(connector); > > - return &priv->encoder; > + if (priv->local_encoder) > + return &priv->encoder; > + else > + return priv->bridge->bridge.encoder; > } > > static > @@ -1140,6 +1160,7 @@ static int tda998x_connector_init(struct tda998x_priv > *priv, struct drm_device *drm) > { > struct drm_connector *connector = &priv->connector; > + struct drm_encoder *encoder; > int ret; > > connector->interlace_allowed = 1; >
Re: [PATCH 1/8] drm/mediatek: Use regmap for register access
Hi Matthias, On Fri, 2018-04-20 at 11:41 +0200, Matthias Brugger wrote: > Hi Philipp, > > On 11/23/2017 09:54 AM, Philipp Zabel wrote: > > Hi Matthias, > > > > On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote: > > > The mmsys memory space is shared between the drm and the > > > clk driver. Use regmap to access it. > > > > > > Signed-off-by: Matthias Brugger > > > --- > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++-- > > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 30 > > > +- > > > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 4 ++-- > > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 - > > > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- > > > 5 files changed, 26 insertions(+), 27 deletions(-) > > > > [...] > > [...] > > > } > > > > > > value = mtk_ddp_sel_in(cur, next, &addr); > > > if (value) { > > > - reg = readl_relaxed(config_regs + addr) & ~value; > > > - writel_relaxed(reg, config_regs + addr); > > > + regmap_read(config_regs, addr, ®); > > > + reg &= ~value; > > > + regmap_write(config_regs, addr, reg); > > > > regmap_update_bits(config_regs, addr, value, 0); > > > > Reviewed-by: Philipp Zabel > > > > Thanks for having a look on that. > > I'll update the next version with regmap_update_bits and leave your > Reviewed-by, > hope that's ok. Yes, that's fine. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/7] drm/i2c: tda998x: split encoder and component functions from the work
Hi Peter, Thank you for the patch. On Thursday, 19 April 2018 19:27:50 EEST Peter Rosin wrote: > This enables reuse of the machinery for the case where a drm_bridge > needs to do the same work via different interfaces. > > Signed-off-by: Peter Rosin > --- > drivers/gpu/drm/i2c/tda998x_drv.c | 46 > 1 file changed, 36 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c > b/drivers/gpu/drm/i2c/tda998x_drv.c index 8f6e013f2b87..9c78f7bde49c 100644 > --- a/drivers/gpu/drm/i2c/tda998x_drv.c > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c > @@ -1163,9 +1163,8 @@ static int tda998x_connector_init(struct tda998x_priv > *priv, > > /* DRM encoder functions */ > > -static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode) > +static void tda998x_dpms(struct tda998x_priv *priv, int mode) I'd split this function into tda998x_enable() and tda998x_disable(), as the DRM bridge API doesn't need to care about DPMS. The core of the driver would then be DPMS-free. Apart from that the patch looks good to me. > { > - struct tda998x_priv *priv = enc_to_tda998x_priv(encoder); > bool on; > > /* we only care about on or off: */ > @@ -1195,12 +1194,18 @@ static void tda998x_encoder_dpms(struct drm_encoder > *encoder, int mode) } > } > > -static void > -tda998x_encoder_mode_set(struct drm_encoder *encoder, > - struct drm_display_mode *mode, > - struct drm_display_mode *adjusted_mode) > +static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode) > { > struct tda998x_priv *priv = enc_to_tda998x_priv(encoder); > + > + tda998x_dpms(priv, mode); > +} > + > +static void > +tda998x_mode_set(struct tda998x_priv *priv, > + struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > u16 ref_pix, ref_line, n_pix, n_line; > u16 hs_pix_s, hs_pix_e; > u16 vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e; > @@ -1407,6 +1412,16 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder, > mutex_unlock(&priv->audio_mutex); > } > > +static void > +tda998x_encoder_mode_set(struct drm_encoder *encoder, > + struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct tda998x_priv *priv = enc_to_tda998x_priv(encoder); > + > + tda998x_mode_set(priv, mode, adjusted_mode); > +} > + > static void tda998x_destroy(struct tda998x_priv *priv) > { > /* disable all IRQs and free the IRQ handler */ > @@ -1653,11 +1668,10 @@ static void tda998x_set_config(struct tda998x_priv > *priv, priv->audio_params = p->audio_params; > } > > -static int tda998x_bind(struct device *dev, struct device *master, void > *data) > +static int tda998x_init(struct device *dev, struct drm_device *drm) > { > struct tda998x_encoder_params *params = dev->platform_data; > struct i2c_client *client = to_i2c_client(dev); > - struct drm_device *drm = data; > struct tda998x_priv *priv; > u32 crtcs = 0; > int ret; > @@ -1705,8 +1719,7 @@ static int tda998x_bind(struct device *dev, struct > device *master, void *data) return ret; > } > > -static void tda998x_unbind(struct device *dev, struct device *master, > -void *data) > +static void tda998x_fini(struct device *dev) > { > struct tda998x_priv *priv = dev_get_drvdata(dev); > > @@ -1715,6 +1728,19 @@ static void tda998x_unbind(struct device *dev, struct > device *master, tda998x_destroy(priv); > } > > +static int tda998x_bind(struct device *dev, struct device *master, void > *data) > +{ > + struct drm_device *drm = data; > + > + return tda998x_init(dev, drm); > +} > + > +static void tda998x_unbind(struct device *dev, struct device *master, > +void *data) > +{ > + tda998x_fini(dev); > +} > + > static const struct component_ops tda998x_ops = { > .bind = tda998x_bind, > .unbind = tda998x_unbind, -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/7] drm/i2c: tda998x: find the drm_device via the drm_connector
Hi Peter, Thank you for the patch. On Thursday, 19 April 2018 19:27:49 EEST Peter Rosin wrote: > This prepares for being a drm_bridge which will not register the > encoder. That makes the connector the better choice. > > Signed-off-by: Peter Rosin Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c > b/drivers/gpu/drm/i2c/tda998x_drv.c index cd3f0873bbdd..8f6e013f2b87 100644 > --- a/drivers/gpu/drm/i2c/tda998x_drv.c > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c > @@ -630,7 +630,7 @@ static void tda998x_detect_work(struct work_struct > *work) { > struct tda998x_priv *priv = > container_of(work, struct tda998x_priv, detect_work); > - struct drm_device *dev = priv->encoder.dev; > + struct drm_device *dev = priv->connector.dev; > > if (dev) > drm_kms_helper_hotplug_event(dev); -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge
On 18.04.2018 16:40, Jacopo Mondi wrote: > As I have another series which is based on this one + Eagle board display > support, I'm re-sending this one to fix the small issue I pointed out in my > reply to v8. > > Simon: no changes to Eagle DTS series, so the last one sent is still the good > one. > > DRM: I have collected several reviewed-by tags both on driver and bindings. > Can I send out incremental patches on this series and consider this one to > be ready to be collected? Queued to drm-misc-next. Regards Andrzej > > Thanks >j > > v8 -> v9: > - Put 'remote' OF node after usage not just in error path during device > tree parsing routine > - Add Rob's Reviewed-by tag to the device tree bindings documentation > > v7 -> b8: > - Make 'vcc' supply mandatory > - Use 'oe' property name to describe "OE" pin > - Minor fixes as suggested by Laurent on bindings and driver > > v6 -> v7: > - Use semi-standard names for powerdown and output enable GPIOs as suggested > by Rob and Vladimir > - Use 'regulator_get()' not the optional version, and list only 'vcc' as > requested supply > - Addressed Laurent's review comments and removed Eagle display enablement > patch > to be sent separately > > v5 -> v6: > - Drop check for CONFIG_OF as it is a Kconfig dependency > - Add Niklas Reviewed-by tags > - List [3/3] depenencies below commit message to ease integration > > v4 -> v5: > - Fix punctuation in bindings documentation > - Add small statement to bindings document to clarify the chip has no > control bus > - Print regulator name in enable/disable routines error path > - Add Andrzej Reviewed-by tag > > v3 -> v4: > - Rename permutations of "pdwn" to just "pdwn" everywhere in the series > - Improve power enable/disable routines as suggested by Andrzej and Sergei > - Change "pdwn" gpio initialization to use the logical output level > - Change Kconfig description > > v2 -> v3: > - Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific > -- Rework bindings to describe multiple input/output ports > -- Rename driver and remove "lvds-decoder" references > -- Rework Eagle DTS to use new bindings > > v1 -> v2: > - Drop support for THC63LVD1024 > > Jacopo Mondi (2): > dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder > drm: bridge: Add thc63lvd1024 LVDS decoder driver > > .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 ++ > drivers/gpu/drm/bridge/Kconfig | 6 + > drivers/gpu/drm/bridge/Makefile| 1 + > drivers/gpu/drm/bridge/thc63lvd1024.c | 205 > + > 4 files changed, 272 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c > > -- > 2.7.4 > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] dma-buf: add peer2peer flag
Am 20.04.2018 um 09:13 schrieb Daniel Vetter: On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote: On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote: We've broken that assumption in i915 years ago. Not struct page backed gpu memory is very real. Of course we'll never feed such a strange sg table to a driver which doesn't understand it, but allowing sg_page == NULL works perfectly fine. At least for gpu drivers. For GPU drivers on x86 with no dma coherency problems, sure. But not all the world is x86. We already have problems due to dmabugs use of the awkward get_sgtable interface (see the common on arm_dma_get_sgtable that I fully agree with), and doing this for memory that doesn't have a struct page at all will make things even worse. x86 dma isn't coherent either, if you're a GPU :-) Flushing gpu caches tends to be too expensive, so there's pci-e support and chipset support to forgo it. Plus drivers flushing caches themselves. The dma_get_sgtable thing is indeed fun, right solution would probably be to push the dma-buf export down into the dma layer. The comment for arm_dma_get_sgtable is also not a realy concern, because dma-buf also abstracts away the flushing (or well is supposed to), so there really shouldn't be anyone calling the streaming apis on the returned sg table. That's why dma-buf gives you an sg table that's mapped already. If that's not acceptable then I guess we could go over the entire tree and frob all the gpu related code to switch over to a new struct sg_table_might_not_be_struct_page_backed, including all the other functions we added over the past few years to iterate over sg tables. But seems slightly silly, given that sg tables seem to do exactly what we need. It isn't silly. We will have to do some surgery like that anyway because the current APIs don't work. So relax, sit back and come up with an API that solves the existing issues and serves us well in the future. So we should just implement a copy of sg table for dma-buf, since I still think it does exactly what we need for gpus? Yes there's a bit a layering violation insofar that drivers really shouldn't each have their own copy of "how do I convert a piece of dma memory into dma-buf", but that doesn't render the interface a bad idea. Completely agree on that. What we need is an sg_alloc_table_from_resources(dev, resources, num_resources) which does the handling common to all drivers. Christian. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel