[RFC v2 5/8] drm/fence: add in-fences support
On Thu, Apr 28, 2016 at 8:17 PM, Ville Syrjälä wrote: >> > - implicit fences also needs one fence per plane/fb, so it will be good to >> >match with that. >> >> We would actually need a fence per object rather than per fb. > > I guess you could overcome this by automagically creating a merged fence > for a multi-obj fb? Yeah, and the android hwc does this for you already. You get passed a surface (or whatever it's called exactly) plus a fence, and the surface contains the gralloc/native buffer thing, which would contain multiple dma-buf handles if your hw does planar stuff that way. I think everyone else who wants explicit fencing will go with the same or similar model, so it's just about implicit fencing. And there we can easily construct the fence_collection from a drm_framebuffer ourselves with a small helper in each driver (or shared one in cma, although cma doesn't yet grok reserverations/implicitly attached fences). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 95198] Shadow of Mordor beta has missing geometry with gl 4.3
https://bugs.freedesktop.org/show_bug.cgi?id=95198 Ernst Sj�strand changed: What|Removed |Added Attachment #123332|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/b7277fa2/attachment.html>
[Bug 95198] Shadow of Mordor beta has missing geometry with gl 4.3
https://bugs.freedesktop.org/show_bug.cgi?id=95198 Ernst Sj�strand changed: What|Removed |Added CC||esmith at feralinteractive.com --- Comment #1 from Ernst Sj�strand --- Card: Radeon Fury OS: Ubuntu 16.04 Mesa: 11.3~git160426193800.912ed84 Kernel: From 4.7-wip up to MAINTAINERS: Remove unneded wildcard for the Radeon/AMDGPU drivers LLVM: 3.9~svn267193-0~x~padoka0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/2ea334fc/attachment.html>
[Bug 95198] Shadow of Mordor beta has missing geometry with gl 4.3
https://bugs.freedesktop.org/show_bug.cgi?id=95198 Bug ID: 95198 Summary: Shadow of Mordor beta has missing geometry with gl 4.3 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: ernstp at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 123332 --> https://bugs.freedesktop.org/attachment.cgi?id=123332&action=edit screenshot.png The public version of Shadow of Mordor worked fine for me, so I don't think this is a dupe of #92059. However there's a beta (v1.1?) that supports compute shaders and GL 4.3. If I run it with MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=430 and set texture quality to Medium, I get missing geometry as the attached picture. I'm trying to apitrace it but unfortunately the error doesn't appear when running under apitrace. Also, glretrace refuses to work with forced gl-versions? I either get: MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=430 glretrace ShadowOfMordor.2.trace error: context mismatch: expected OpenGL 1.0, but got OpenGL 4.3 core Or: glretrace ShadowOfMordor.2.trace error: xlib: BadMatch (invalid parameter attributes) error: xlib: BadMatch (invalid parameter attributes) error: failed to create OpenGL 4.3 core context. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/1b1c5b74/attachment.html>
[Bug 95195] Tonga agd5f drm-next-4.7-wip UVD Oops/lock since drm/amdgpu: keep vm in job instead of ib
https://bugs.freedesktop.org/show_bug.cgi?id=95195 --- Comment #2 from Andy Furniss --- (In reply to Alex Deucher from comment #1) > Created attachment 123329 [details] [review] > possible fix > > Does the attached patch help? Yes, so far running OK with that. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/2121c41a/attachment.html>
[PATCH] drm/omap: check plane size
On Wed, Apr 27, 2016 at 11:02:17PM +0300, Laurent Pinchart wrote: > Hi Ville, > > On Wednesday 27 Apr 2016 20:29:24 Ville Syrjälä wrote: > > On Wed, Apr 27, 2016 at 06:30:19PM +0300, Laurent Pinchart wrote: > > > Hi Tomi, > > > > > > (CC'ing Daniel) > > > > > > Thank you for the patch. > > > > > > On Tuesday 26 Apr 2016 13:16:42 Tomi Valkeinen wrote: > > > > At the moment we don't check the plane input/output sizes, which can > > > > lead to DSS HW errors when invalid values are given from the userspace. > > > > > > > > Add a check so that the sizes are > 0. > > > > > > > > Signed-off-by: Tomi Valkeinen > > > > > > I don't think it makes sense to have an empty source or destination > > > rectangle for any driver, not just omapdrm. Shouldn't this check be added > > > to drm_atomic_plane_check() instead ? > > > > It's perfectly legal. Just means you're supposed to turn the plane off. > > Where is that documented ? Do we have uapi docs? > I thought turning the plane off was done by setting > the framebuffer to NULL (in which case the src and crtc coordinates must of > course be ignored) ? That's another way. However setting the fb to 0 is a bit different, as then you're not holding a ref on the fb (nor does it get pinned etc.). So eg. if you want to make sure that you really can pin the fb, but want to have the plane disabled for a bit, you could just the clear out the coordinates. Also from an implementation POV it's no different than the plane just getting clipped away entirely, so supporting this way of disabling a plane has no extra cost really. > > > > > --- > > > > > > > > drivers/gpu/drm/omapdrm/omap_plane.c | 6 ++ > > > > 1 file changed, 6 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c > > > > b/drivers/gpu/drm/omapdrm/omap_plane.c index 93ee538a99f5..fa9e5086eb65 > > > > 100644 > > > > --- a/drivers/gpu/drm/omapdrm/omap_plane.c > > > > +++ b/drivers/gpu/drm/omapdrm/omap_plane.c > > > > @@ -168,6 +168,12 @@ static int omap_plane_atomic_check(struct drm_plane > > > > *plane, if (IS_ERR(crtc_state)) > > > > > > > > return PTR_ERR(crtc_state); > > > > > > > > + if (state->src_w == 0 || state->src_h == 0) > > > > + return -EINVAL; > > > > + > > > > + if (state->crtc_w == 0 || state->crtc_h == 0) > > > > + return -EINVAL; > > > > + > > > > > > > > if (state->crtc_x < 0 || state->crtc_y < 0) > > > > > > > > return -EINVAL; > > -- > Regards, > > Laurent Pinchart -- Ville Syrjälä Intel OTC
[Bug 117151] amdgpu: Fails to initialize R7 260x (Bonaire)
https://bugzilla.kernel.org/show_bug.cgi?id=117151 --- Comment #1 from Parker Reed --- Created attachment 214661 --> https://bugzilla.kernel.org/attachment.cgi?id=214661&action=edit Full verbose lspci -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC v2 5/8] drm/fence: add in-fences support
On Thu, Apr 28, 2016 at 07:56:19PM +0300, Ville Syrjälä wrote: > On Thu, Apr 28, 2016 at 11:36:44AM -0300, Gustavo Padovan wrote: > > 2016-04-27 Daniel Stone : > > > > > Hi, > > > > > > On 26 April 2016 at 21:48, Greg Hackmann wrote: > > > > On 04/26/2016 01:05 PM, Daniel Vetter wrote: > > > >> On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote: > > > >>> What are they doing that can't stuff the fences into an array > > > >>> instead of props? > > > >> > > > >> The hw composer interface is one in-fence per plane. That's really the > > > >> major reason why the kernel interface is built to match. And I really > > > >> don't think we should diverge just because we have a slight different > > > >> color preference ;-) > > > > > > > > The relationship between layers and fences is only fuzzy and indirect > > > > though. The relationship is really between the buffer you're > > > > displaying on > > > > that layer, and the fence representing the work done to render into that > > > > buffer. SurfaceFlinger just happens to bundle them together inside the > > > > same > > > > struct hwc_layer_1 as an API convenience. > > > > > > Right, and when using implicit fencing, this comes as a plane > > > property, by virtue of plane -> fb -> buffer -> fence. > > > > > > > Which is kind of splitting hairs as long as you have a 1-to-1 > > > > relationship > > > > between layers and DRM planes. But that's not always the case. > > > > > > Can you please elaborate? > > > > > > > A (per-CRTC?) array of fences would be more flexible. And even in the > > > > cases > > > > where you could make a 1-to-1 mapping between planes and fences, it's > > > > not > > > > that much more work for userspace to assemble those fences into an array > > > > anyway. > > > > > > As Ville says, I don't want to go down the path of scheduling CRTC > > > updates separately, because that breaks MST pretty badly. If you don't > > > want your updates to display atomically, then don't schedule them > > > atomically ... ? That's the only reason I can see for making fencing > > > per-CRTC, rather than just a pile of unassociated fences appended to > > > the request. Per-CRTC fences also forces userspace to merge fences > > > before submission when using multiple planes per CRTC, which is pretty > > > punitive. > > > > > > I think having it semantically attached to the plane is a little bit > > > nicer for tracing (why was this request delayed? -> a fence -> which > > > buffer was that fence for?) at a glance. Also the 'pile of appended > > > fences' model is a bit awkward for more generic userspace, which > > > creates a libdrm request and builds it (add a plane, try it out, wind > > > back) incrementally. Using properties makes that really easy, but > > > without properties, we'd have to add separate codepaths - and thus > > > separate ABI, which complicates distribution - to libdrm to account > > > for a separate plane array which shares a cursor with the properties. > > > So for that reason if none other, I'd really prefer not to go down > > > that route. > > > > I also agree to have it as FENCE_FD prop on the plane. Summarizing the > > arguments on this thread, they are: > > Your "summary" forgot to include any counter arguments. > > > > > - implicit fences also needs one fence per plane/fb, so it will be good to > > > >match with that. > > > > We would actually need a fence per object rather than per fb. I guess you could overcome this by automagically creating a merged fence for a multi-obj fb? -- Ville Syrjälä Intel OTC
[Bug 95195] Tonga agd5f drm-next-4.7-wip UVD Oops/lock since drm/amdgpu: keep vm in job instead of ib
https://bugs.freedesktop.org/show_bug.cgi?id=95195 --- Comment #1 from Alex Deucher --- Created attachment 123329 --> https://bugs.freedesktop.org/attachment.cgi?id=123329&action=edit possible fix Does the attached patch help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/c690e77a/attachment.html>
[RFC v2 5/8] drm/fence: add in-fences support
On Thu, Apr 28, 2016 at 07:43:16PM +0200, Daniel Vetter wrote: > On Thu, Apr 28, 2016 at 6:56 PM, Ville Syrjälä > wrote: > >> - better for tracing, can identify the buffer/fence promptly > > > > Can fences be reused somehow while still attached to a plane, or ever? > > That might cause some oddness if you, say, leave a fence attached to one > > plane and then do a modeset on another crtc perhaps which needs to turn > > the first crtc off+on to reconfigure something. > > Fences auto-disappear of course and don't stick around when you > duplicate the drm_plane_state again. I still don't really get the real > concerns though ... Properties that magically change values shouldn't exist IMO. I guess if you could have write-only properties or something it migth be sensible? > In the end it's purely a transport question, and > both ABI ideas work out semantically exactly the same in the end. It's > just that at least in my opinion FENCE_FD prop is a lot more > convenient. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Ville Syrjälä Intel OTC
[Bug 95195] Tonga agd5f drm-next-4.7-wip UVD Oops/lock since drm/amdgpu: keep vm in job instead of ib
https://bugs.freedesktop.org/show_bug.cgi?id=95195 Bug ID: 95195 Summary: Tonga agd5f drm-next-4.7-wip UVD Oops/lock since drm/amdgpu: keep vm in job instead of ib Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: adf.lists at gmail.com Created attachment 123327 --> https://bugs.freedesktop.org/attachment.cgi?id=123327&action=edit dmesg showing Oops Tonga on agd5f drm-next-4.7-wip Getting an Oops followed by a GPU lock using UVD since - commit 5599239c331b9860c35d5e0fd7c6acbc838fc20d Author: Monk Liu Date: Tue Apr 19 20:11:32 2016 +0800 drm/amdgpu: keep vm in job instead of ib ib.vm is a legacy way to get vm, after scheduler implemented vm should be get from job, and all ibs from one job share the same vm, no need to keep ib.vm just move vm field to job. this patch as well add job as paramter to ib_schedule so it can get vm from job->vm. Easy to provoke with powerplay=1 and auto clocks. Harder to provoke, but also happens with powerplay=0. dmesg with Oops attached. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/7f85a0e1/attachment.html>
[PATCH v15 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by: Jitao Shi Reviewed-by: Daniel Kurtz --- Changes since v14: - update copyright info. - change bridge_to_ps8640 and connector_to_ps8640 to inline function. - fix some coding style. - use sizeof as array counter. - use drm_get_edid when read edid. - add mutex when firmware updating. Changes since v13: - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 *data, u16 data_len) - fix PAGE2_SW_REST tyro. - move the buf[3] init to entrance of the function. Changes since v12: - fix hw_chip_id build warning Changes since v11: - Remove depends on I2C, add DRM depends - Reuse ps8640_write_bytes() in ps8640_write_byte() - Use timer check for polling like the routines in - Fix no drm_connector_unregister/drm_connector_cleanup when ps8640_bridge_attach fail - Check the ps8640 hardware id in ps8640_validate_firmware - Remove fw_version check - Move ps8640_validate_firmware before ps8640_enter_bl - Add ddc_i2c unregister when probe fail and ps8640_remove --- drivers/gpu/drm/bridge/Kconfig | 12 + drivers/gpu/drm/bridge/Makefile|1 + drivers/gpu/drm/bridge/parade-ps8640.c | 1076 3 files changed, 1089 insertions(+) create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 27e2022..be6084e 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -40,4 +40,16 @@ config DRM_PARADE_PS8622 ---help--- Parade eDP-LVDS bridge chip driver. +config DRM_PARADE_PS8640 + tristate "Parade PS8640 MIPI DSI to eDP Converter" + depends on DRM + depends on OF + select DRM_KMS_HELPER + select DRM_MIPI_DSI + select DRM_PANEL + ---help--- + Choose this option if you have PS8640 for display + The PS8640 is a high-performance and low-power + MIPI DSI to eDP converter + endmenu diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index f13c33d..fbe38dc 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c new file mode 100644 index 000..a82ed6c --- /dev/null +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -0,0 +1,1076 @@ +/* + * Copyright (c) 2016 MediaTek Inc. + * + * 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. + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#define PAGE2_SPI_CFG3 0x82 +#define I2C_TO_SPI_RESET 0x20 +#define PAGE2_ROMADD_BYTE1 0x8e +#define PAGE2_ROMADD_BYTE2 0x8f +#define PAGE2_SWSPI_WDATA 0x90 +#define PAGE2_SWSPI_RDATA 0x91 +#define PAGE2_SWSPI_LEN0x92 +#define PAGE2_SWSPI_CTL0x93 +#define TRIGGER_NO_READBACK0x05 +#define TRIGGER_READBACK 0x01 +#define PAGE2_SPI_STATUS 0x9e +#define SPI_READY 0x0c +#define PAGE2_GPIO_L 0xa6 +#define PAGE2_GPIO_H 0xa7 +#define PS_GPIO9 BIT(1) +#define PAGE2_IROM_CTRL0xb0 +#define IROM_ENABLE0xc0 +#define IROM_DISABLE 0x80 +#define PAGE2_SW_RESET 0xbc +#define SPI_SW_RESET BIT(7) +#define MPU_SW_RESET BIT(6) +#define PAGE2_ENCTLSPI_WR 0xda +#define PAGE2_I2C_BYPASS 0xea +#define I2C_BYPASS_EN 0xd0 +#define PAGE3_SET_ADD 0xfe +#define PAGE3_SET_VAL 0xff +#define VDO_CTL_ADD0x13 +#define VDO_DIS0x18 +#define VDO_EN 0x1c +#define PAGE4_REV_L0xf0 +#define PAGE4_REV_H0xf1 +#define PAGE4_CHIP_L 0xf2 +#define PAGE4_CHIP_H 0xf3 + +/* Firmware */ +#define SPI_MAX_RETRY_CNT 8 +#define PS_FW_NAME "ps864x_fw.bin" + +#define FW_CHIP_ID_OFFSET 0 +#define FW_VERSION_OFFSET 2 +#define EDID_I2C_ADDR 0x50 + +#define WRITE_STATUS_REG_CMD 0x01 +#define READ_STATUS_REG_CMD0x05 +#define BUSY
[PATCH v15 1/2] Documentation: bridge: Add documentation for ps8640 DT properties
Add documentation for DT properties supported by
ps8640 DSI-eDP converter.
Signed-off-by: Jitao Shi
Acked-by: Rob Herring
Reviewed-by: Philipp Zabel
---
Changes since v14:
- change mode-sel-gpios as optional.
---
.../devicetree/bindings/display/bridge/ps8640.txt | 44
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt
b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 000..7b13f92
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,44 @@
+ps8640-bridge bindings
+
+Required properties:
+ - compatible: "parade,ps8640"
+ - reg: first page address of the bridge.
+ - sleep-gpios: OF device-tree gpio specification for PD pin.
+ - reset-gpios: OF device-tree gpio specification for reset pin.
+ - vdd12-supply: OF device-tree regulator specification for 1.2V power.
+ - vdd33-supply: OF device-tree regulator specification for 3.3V power.
+ - ports: The device node can contain video interface port nodes per
+the video-interfaces bind[1]. For port at 0,set the reg = <0>
as
+ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP
out.
+
+Optional properties:
+ - mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+ edp-bridge at 18 {
+ compatible = "parade,ps8640";
+ reg = <0x18>;
+ sleep-gpios = <&pio 116 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&pio 115 GPIO_ACTIVE_LOW>;
+ mode-sel-gpios = <&pio 92 GPIO_ACTIVE_HIGH>;
+ vdd12-supply = <&ps8640_fixed_1v2>;
+ vdd33-supply = <&mt6397_vgp2_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 0 {
+ reg = <0>;
+ ps8640_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ ps8640_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
--
1.7.9.5
[RFC v2 5/8] drm/fence: add in-fences support
On Thu, Apr 28, 2016 at 7:55 PM, Gustavo Padovan wrote: > 2016-04-28 Ville Syrjälä : > >> On Thu, Apr 28, 2016 at 07:43:16PM +0200, Daniel Vetter wrote: >> > On Thu, Apr 28, 2016 at 6:56 PM, Ville Syrjälä >> > wrote: >> > >> - better for tracing, can identify the buffer/fence promptly >> > > >> > > Can fences be reused somehow while still attached to a plane, or ever? >> > > That might cause some oddness if you, say, leave a fence attached to one >> > > plane and then do a modeset on another crtc perhaps which needs to turn >> > > the first crtc off+on to reconfigure something. >> > >> > Fences auto-disappear of course and don't stick around when you >> > duplicate the drm_plane_state again. I still don't really get the real >> > concerns though ... >> >> Properties that magically change values shouldn't exist IMO. I guess if >> you could have write-only properties or something it migth be sensible? > > We can just not return FENCE_FD on get_props, that would make it > write-only. We do actually return a value for get_props, but it's -1 which for fds means "no fd". That's to make sure userspace can save&restore any prop without causing harm. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFC v2 5/8] drm/fence: add in-fences support
On Thu, Apr 28, 2016 at 11:36:44AM -0300, Gustavo Padovan wrote: > 2016-04-27 Daniel Stone : > > > Hi, > > > > On 26 April 2016 at 21:48, Greg Hackmann wrote: > > > On 04/26/2016 01:05 PM, Daniel Vetter wrote: > > >> On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote: > > >>> What are they doing that can't stuff the fences into an array > > >>> instead of props? > > >> > > >> The hw composer interface is one in-fence per plane. That's really the > > >> major reason why the kernel interface is built to match. And I really > > >> don't think we should diverge just because we have a slight different > > >> color preference ;-) > > > > > > The relationship between layers and fences is only fuzzy and indirect > > > though. The relationship is really between the buffer you're displaying > > > on > > > that layer, and the fence representing the work done to render into that > > > buffer. SurfaceFlinger just happens to bundle them together inside the > > > same > > > struct hwc_layer_1 as an API convenience. > > > > Right, and when using implicit fencing, this comes as a plane > > property, by virtue of plane -> fb -> buffer -> fence. > > > > > Which is kind of splitting hairs as long as you have a 1-to-1 relationship > > > between layers and DRM planes. But that's not always the case. > > > > Can you please elaborate? > > > > > A (per-CRTC?) array of fences would be more flexible. And even in the > > > cases > > > where you could make a 1-to-1 mapping between planes and fences, it's not > > > that much more work for userspace to assemble those fences into an array > > > anyway. > > > > As Ville says, I don't want to go down the path of scheduling CRTC > > updates separately, because that breaks MST pretty badly. If you don't > > want your updates to display atomically, then don't schedule them > > atomically ... ? That's the only reason I can see for making fencing > > per-CRTC, rather than just a pile of unassociated fences appended to > > the request. Per-CRTC fences also forces userspace to merge fences > > before submission when using multiple planes per CRTC, which is pretty > > punitive. > > > > I think having it semantically attached to the plane is a little bit > > nicer for tracing (why was this request delayed? -> a fence -> which > > buffer was that fence for?) at a glance. Also the 'pile of appended > > fences' model is a bit awkward for more generic userspace, which > > creates a libdrm request and builds it (add a plane, try it out, wind > > back) incrementally. Using properties makes that really easy, but > > without properties, we'd have to add separate codepaths - and thus > > separate ABI, which complicates distribution - to libdrm to account > > for a separate plane array which shares a cursor with the properties. > > So for that reason if none other, I'd really prefer not to go down > > that route. > > I also agree to have it as FENCE_FD prop on the plane. Summarizing the > arguments on this thread, they are: Your "summary" forgot to include any counter arguments. > > - implicit fences also needs one fence per plane/fb, so it will be good to > >match with that. > We would actually need a fence per object rather than per fb. > - requires userspace to always merge fences > "doesn't?" but that's not true if it's an array. It would be true if you had just one fence for the whole thing, or one per crtc. > - can use standard plane properties, making kernel and userspace life > easier, >an array brings more work to build the atomic request plus extra checkings > >on the kernel. > I don't really get this one. The objects and props are arrays too. Why is another array so problematic? > - do not need to changes to drivers > > - better for tracing, can identify the buffer/fence promptly Can fences be reused somehow while still attached to a plane, or ever? That might cause some oddness if you, say, leave a fence attached to one plane and then do a modeset on another crtc perhaps which needs to turn the first crtc off+on to reconfigure something. -- Ville Syrjälä Intel OTC
[Bug 94231] Problems compiling libdrm since glibc 2.23
https://bugs.freedesktop.org/show_bug.cgi?id=94231 --- Comment #20 from Matt Turner --- (In reply to Emil Velikov from comment #19) > That was fast, only a few hours ago the commit landed. > > No objections about having this in, although let's use AC_CHECK_HEADERS. > > I'm wondering if we shouldn't give it a day or two before landing though. > Obviously waiting for a man-pages release would be a serious overkill > (afaict it will be within ~4 months). Do you want to commit it... or do you want me to send it to the list? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/41293bca/attachment.html>
[RFC v2 5/8] drm/fence: add in-fences support
On Thu, Apr 28, 2016 at 6:56 PM, Ville Syrjälä wrote: >> - better for tracing, can identify the buffer/fence promptly > > Can fences be reused somehow while still attached to a plane, or ever? > That might cause some oddness if you, say, leave a fence attached to one > plane and then do a modeset on another crtc perhaps which needs to turn > the first crtc off+on to reconfigure something. Fences auto-disappear of course and don't stick around when you duplicate the drm_plane_state again. I still don't really get the real concerns though ... In the end it's purely a transport question, and both ABI ideas work out semantically exactly the same in the end. It's just that at least in my opinion FENCE_FD prop is a lot more convenient. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
On Thursday 28 April 2016 07:16 PM, Alexey Brodkin wrote: >> > Note that the IOC start alignment needs to follow >> > max(4k, size). What will be maximum size of frame buffer - 16M always ! > What do you mean by that? For HS38, we intend to bypass the frame buffer traffic from IOC port. So the frame buffer start needs to be inside the IOC aperture base address. That value can't be arbitrary - it is atleast 4K aligned value and further also needs to be aligned to the size of aperture. So if the size is 16M it needs to be 16M aligned etc... -Vineet
[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #149 from bhaallord at arcor.de --- Are there any new information about this bug? I would like to use my GPU again. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/3f8c91e4/attachment.html>
[PATCH] drm/msm: Move call to PTR_ERR_OR_ZERO after reassignment
On Thursday 28 April 2016 06:23 PM, Eric Engestrom wrote:
> On Wed, Apr 27, 2016 at 04:51:37PM +0530, Vaishali Thakkar wrote:
>> Here, a location is reset to NULL before being passed to PTR_ERR.
>> So, PTR_ERR should be called before its argument is reassigned
>> to NULL. Further to simplify things use PTR_ERR_OR_ZERO instead
>> of PTR_ERR and IS_ERR.
>>
>> Problem found using Coccinelle.
>>
>> Signed-off-by: Vaishali Thakkar
>> ---
>> drivers/gpu/drm/msm/edp/edp_ctrl.c | 16 +---
>> 1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
>> b/drivers/gpu/drm/msm/edp/edp_ctrl.c
>> index 81200e9..7816541 100644
>> --- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
>> +++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
>> @@ -302,21 +302,23 @@ static void edp_clk_disable(struct edp_ctrl *ctrl, u32
>> clk_mask)
>> static int edp_regulator_init(struct edp_ctrl *ctrl)
>> {
>> struct device *dev = &ctrl->pdev->dev;
>> +int ret;
>>
>> DBG("");
>> ctrl->vdda_vreg = devm_regulator_get(dev, "vdda");
>> -if (IS_ERR(ctrl->vdda_vreg)) {
>> +ret = PTR_ERR_OR_ZERO(ctrl->vdda_vreg);
>> +if (ret) {
>> pr_err("%s: Could not get vdda reg, ret = %ld\n", __func__,
>> -PTR_ERR(ctrl->vdda_vreg));
>> +ret);
>> ctrl->vdda_vreg = NULL;
>> -return PTR_ERR(ctrl->vdda_vreg);
>> +return ret;
>> }
>> ctrl->lvl_vreg = devm_regulator_get(dev, "lvl-vdd");
>> -if (IS_ERR(ctrl->lvl_vreg)) {
>> -pr_err("Could not get lvl-vdd reg, %ld",
>> -PTR_ERR(ctrl->lvl_vreg));
>> +ret = PTR_ERR_OR_ZERO(ctrl->lvl_vreg);
>> +if (ret) {
>
> While you're rewriting them, it might be worth making these two pr_err()
> print the same format, e.g.:
>
> pr_err("%s: Could not get lvl-vdd reg, ret = %ld\n", __func__, ret);
Done, thanks.
>> +pr_err("Could not get lvl-vdd reg, %ld", ret);
>> ctrl->lvl_vreg = NULL;
>> -return PTR_ERR(ctrl->lvl_vreg);
>> +return ret;
>> }
>>
>> return 0;
>> --
>> 2.1.4
>
> Reviewed-by: Eric Engestrom
>
--
Vaishali
[PATCH v2] drm/msm: Move call to PTR_ERR_OR_ZERO after reassignment
Here, a location is reset to NULL before being passed to PTR_ERR.
So, PTR_ERR should be called before its argument is reassigned
to NULL. Further to simplify things use PTR_ERR_OR_ZERO instead
of PTR_ERR and IS_ERR.
Problem found using Coccinelle.
Signed-off-by: Vaishali Thakkar
Reviewed-by: Eric Engestrom
---
Changes since v1:
- No functional changes, just make two pr_err() to print
the same format
---
drivers/gpu/drm/msm/edp/edp_ctrl.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 81200e9..e10fa810 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -302,21 +302,24 @@ static void edp_clk_disable(struct edp_ctrl *ctrl, u32
clk_mask)
static int edp_regulator_init(struct edp_ctrl *ctrl)
{
struct device *dev = &ctrl->pdev->dev;
+ int ret;
DBG("");
ctrl->vdda_vreg = devm_regulator_get(dev, "vdda");
- if (IS_ERR(ctrl->vdda_vreg)) {
+ ret = PTR_ERR_OR_ZERO(ctrl->vdda_vreg);
+ if (ret) {
pr_err("%s: Could not get vdda reg, ret = %ld\n", __func__,
- PTR_ERR(ctrl->vdda_vreg));
+ ret);
ctrl->vdda_vreg = NULL;
- return PTR_ERR(ctrl->vdda_vreg);
+ return ret;
}
ctrl->lvl_vreg = devm_regulator_get(dev, "lvl-vdd");
- if (IS_ERR(ctrl->lvl_vreg)) {
- pr_err("Could not get lvl-vdd reg, %ld",
- PTR_ERR(ctrl->lvl_vreg));
+ ret = PTR_ERR_OR_ZERO(ctrl->lvl_vreg);
+ if (ret) {
+ pr_err("%s: Could not get lvl-vdd reg, ret = %ld\n", __func__,
+ ret);
ctrl->lvl_vreg = NULL;
- return PTR_ERR(ctrl->lvl_vreg);
+ return ret;
}
return 0;
--
2.1.4
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #130 from Marek Olšák --- Oh I see you did that. Sorry for the noise. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/79ed78ab/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #129 from Marek Olšák --- (In reply to Davin McCall from comment #127) > diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c > index f0245fd..d1f4ac6 100644 > --- a/src/mesa/vbo/vbo_exec_array.c > +++ b/src/mesa/vbo/vbo_exec_array.c > @@ -935,7 +935,9 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode, > (void) check_draw_elements_data; > #endif > > - vbo_validated_drawrangeelements(ctx, mode, index_bounds_valid, start, > end, > + //vbo_validated_drawrangeelements(ctx, mode, index_bounds_valid, start, > end, > + // count, type, indices, basevertex, 1, 0); > + vbo_validated_drawrangeelements(ctx, mode, GL_FALSE, ~0, ~0, > count, type, indices, basevertex, 1, 0); > } That's not correct, but it's close. If you want the driver to ignore the app-supplied index bounds, simply change "index_bounds_valid" to "false". -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/3c371083/attachment.html>
Results of the 2016 Election to the X.Org BoD & Vote on the By-Law Changes
The 2016 Election is now over and the results are in. Two questions were up for voting, 4 seats on the Board of Directors and approval of the amended By-Laws to join SPI. The Results of the Board of Director elections: Candidates and their respective points: Egbert Eich 205 Alex Deucher 195 Keith Packard152 Bryce Harrington 142 Lucas Stach 129 Therefore the following candidates have been elected to the board: Egbert Eich, Alex Deucher, Keith Packard, Bryce Harrington The results on the vote to change the By-Laws to join SPI: Do you agree to the changed By-Laws? Yes 54/65 (83.1%) No 4/65 (6.2%) Abstain 3/65 (4.6%) We have 65 members and 61 votes were recorded. According to Article 7 of the Oct. 29, 2006 By-Laws the following provision is made for changes to the By-Laws: "AMENDMENT These By-law may be altered, amended or repealed by an affirmative vote of at least two-thirds (2/3) of the Members of X.Org." We have reached quorum and have a 2/3 majority in favour of the change. The changes to the By-Laws are thus accepted. Cheers, The X.Org 2016 Election Committee Peter Hutterer Daniel Vetter Martin Peres Rob Clark -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/f15e42ed/attachment.sig>
[RFC v2 5/8] drm/fence: add in-fences support
On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter wrote: > On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote: >> On 04/26/2016 01:05 PM, Daniel Vetter wrote: >> >On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote: >> >>On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote: >> >>>On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote: >> >>>But really the reason for per-plane is hw composer from >> >>>Android. I don't see any point in designing an api that's needlessly >> >>>different from what the main user expects (even if it may be silly). >> >> >> >>What are they doing that can't stuff the fences into an array >> >>instead of props? >> > >> >The hw composer interface is one in-fence per plane. That's really the >> >major reason why the kernel interface is built to match. And I really >> >don't think we should diverge just because we have a slight different >> >color preference ;-) >> > >> >As long as you end up with a pile of fences somehow it'll work. >> >-Daniel >> > >> >> The relationship between layers and fences is only fuzzy and indirect >> though. The relationship is really between the buffer you're displaying on >> that layer, and the fence representing the work done to render into that >> buffer. SurfaceFlinger just happens to bundle them together inside the same >> struct hwc_layer_1 as an API convenience. >> >> Which is kind of splitting hairs as long as you have a 1-to-1 relationship >> between layers and DRM planes. But that's not always the case. >> >> A (per-CRTC?) array of fences would be more flexible. And even in the cases >> where you could make a 1-to-1 mapping between planes and fences, it's not >> that much more work for userspace to assemble those fences into an array >> anyway. > > I'm ok with an array too if that's what you folks prefer (it's meant to be > used by you after all). I just don't want just 1 fence for the entire op, > forcing userspace to first merge them all together. That seems silly. I was kinda more a fan of array too, if for no other reason that to be consistent w/ how out-fences work. (And using property just for in-fence seemed slightly weird/abusive to me) > One side-effect of that is that we'd also have to rework all the internal > bits and move fences around in atomic. Which means change a pile of > drivers. Not sure that's worth it, but I'd be ok either way really. hmm, well we could keep the array per-plane (and if one layer is using multiple planes, just list the same fd multiple times).. then it mostly comes down to changes in the ioctl fxn itself. BR, -R > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2 v2] ARC: [axs10x] Specify reserved memory for frame buffer
Allocation of a frame buffer memory in a special memory region
allows bypassing of so-called IO Coherency aperture
which is typically set as a range 0x8z-0xAz.
I.e. all data traffic to PGU bypasses IO Coherency block
and saves its bandwidth for other peripherals.
Even though for AXS101 (which sorts ARC770 CPU) IOC is not
an option for a sake of keeping one DT description for the
base-board (axs10x_mb.dtsi) we're still defining reserved
memory location in the very end of DDR.
Signed-off-by: Alexey Brodkin
Cc: Vineet Gupta
Cc: devicetree at vger.kernel.org
---
Changes v1 -> v2:
* Reserved memory size bumped from 16Mb to 32Mb.
Given the corner case 1920x1080x24bpp and tripl-buffering
we'll need ~18Mb in the future so let's reserve 32Mb today
and don't think about that any more.
* Reserved area in AXS103 boards moved to the very end of the first Gb.
Even though we use only 512Mb for kernel on AXS103 board
we have 1Gb of DDR really. So let's move reserved area in the very
end of available mamory. This way we'll be able to keep this mapping
when we'll want to use > 512Mb in the kernel.
* And while at it correct "ranges" value for AXS101 board: we do have
only 512 Mb of DDR on the board so let's not temp users to try to use more.
arch/arc/boot/dts/axc001.dtsi | 22 --
arch/arc/boot/dts/axc003.dtsi | 14 ++
arch/arc/boot/dts/axc003_idu.dtsi | 14 ++
arch/arc/boot/dts/axs10x_mb.dtsi | 2 +-
4 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
index 420dcfd..262496a 100644
--- a/arch/arc/boot/dts/axc001.dtsi
+++ b/arch/arc/boot/dts/axc001.dtsi
@@ -93,8 +93,26 @@
memory {
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x 0x8000 0x4000>;
+ ranges = <0x 0x8000 0x2000>;
device_type = "memory";
- reg = <0x8000 0x2000>; /* 512MiB */
+ reg = <0x8000 0x1b00>; /* (512 - 32) MiB */
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ /*
+* We just move frame buffer area to the very end of
+* available DDR. And even though in case of ARC770 there's
+* no strict requirement for a frame-buffer to be in any
+* particular location it allows us to use the same
+* base board's DT node for ARC PGU as for ARc HS38.
+*/
+ frame_buffer: frame_buffer at 9e00 {
+ compatible = "shared-dma-pool";
+ reg = <0x9e00 0x200>;
+ no-map;
+ };
};
};
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index f90fadf..35ece04 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -100,4 +100,18 @@
device_type = "memory";
reg = <0x8000 0x2000>; /* 512MiB */
};
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ /*
+* Move frame buffer out of IOC aperture (0x8z-0xAz).
+*/
+ frame_buffer: frame_buffer at be00 {
+ compatible = "shared-dma-pool";
+ reg = <0xbe00 0x200>;
+ no-map;
+ };
+ };
};
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi
b/arch/arc/boot/dts/axc003_idu.dtsi
index 06a9f29..df9ddb6 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -123,4 +123,18 @@
device_type = "memory";
reg = <0x8000 0x2000>; /* 512MiB */
};
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ /*
+* Move frame buffer out of IOC aperture (0x8z-0xAz).
+*/
+ frame_buffer: frame_buffer at be00 {
+ compatible = "shared-dma-pool";
+ reg = <0xbe00 0x200>;
+ no-map;
+ };
+ };
};
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 823f15c..64b063d 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -283,7 +283,7 @@
encoder-slave = <&adv7511>;
clocks = <&pguclk>;
clock-names = "pxlclk";
-
+ memory-region = <&frame_buffer>;
port {
pgu_output: endpoint {
re
[PATCH 1/2 v2] drm/arcpgu: use dedicated memory area for frame buffer
Now when ARC supports reserved memory areas and per-device coherent DMA allocations we may switch ARC PGU to use of those dedicated areas. One of the benefits we may move frame-buffer area out from IO Coherency aperture and so significantly reduce IOC utilization allowing less demanding peripherals to use all perks of IOC. Signed-off-by: Alexey Brodkin Cc: Dave Airlie Cc: Daniel Vetter --- No changes v1 -> v2. drivers/gpu/drm/arc/arcpgu_drv.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c index 5b35e5db..76e187a 100644 --- a/drivers/gpu/drm/arc/arcpgu_drv.c +++ b/drivers/gpu/drm/arc/arcpgu_drv.c @@ -19,6 +19,7 @@ #include #include #include +#include #include "arcpgu.h" #include "arcpgu_regs.h" @@ -135,6 +136,11 @@ static int arcpgu_load(struct drm_device *drm) dev_info(drm->dev, "arc_pgu ID: 0x%x\n", arc_pgu_read(arcpgu, ARCPGU_REG_ID)); + /* Get the optional framebuffer memory resource */ + ret = of_reserved_mem_device_init(drm->dev); + if (ret && ret != -ENODEV) + return ret; + if (dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32))) return -ENODEV; -- 2.5.5
[PATCH 0/2 v2] drm/arcpgu: Get use of dedicated memory area for frame buffer
This mini-series allows to allocate frame buffer memory in desired location. Allocation of a frame buffer memory in a special memory region allows bypassing of so-called IO Coherency aperture which is typically set as a range 0x8z-0xAz. I.e. all data traffic to PGU bypasses IO Coherency block and saves its bandwidth for other peripherals. Cc: Dave Airlie Cc: Daniel Vetter Cc: devicetree at vger.kernel.org Changes v1 -> v2: * Reserved memory size bumped from 16Mb to 32Mb. * Reserved area in AXS103 boards moved to the very end of available DDR. Alexey Brodkin (2): drm/arcpgu: use dedicated memory area for frame buffer ARC: [axs10x] Specify reserved memory for frame buffer arch/arc/boot/dts/axc001.dtsi | 22 -- arch/arc/boot/dts/axc003.dtsi | 14 ++ arch/arc/boot/dts/axc003_idu.dtsi | 14 ++ arch/arc/boot/dts/axs10x_mb.dtsi | 2 +- drivers/gpu/drm/arc/arcpgu_drv.c | 6 ++ 5 files changed, 55 insertions(+), 3 deletions(-) -- 2.5.5
[PATCH v4 7/7] drm/udl: Use drm_fb_helper deferred_io support
Use the fbdev deferred io support in drm_fb_helper.
The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
now schedule a worker instead of being flushed directly like it was
previously (recorded when in atomic).
This patch has only been compile tested.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
Changes since v1:
- No need to enable deferred_io by default since drm_fb_helper uses
a dedicated worker for flushing
drivers/gpu/drm/udl/udl_drv.h | 2 -
drivers/gpu/drm/udl/udl_fb.c | 140 ++
2 files changed, 6 insertions(+), 136 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 4a064ef..0b03d34 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -81,8 +81,6 @@ struct udl_framebuffer {
struct drm_framebuffer base;
struct udl_gem_object *obj;
bool active_16; /* active on the 16-bit channel */
- int x1, y1, x2, y2; /* dirty rect */
- spinlock_t dirty_lock;
};
#define to_udl_fb(x) container_of(x, struct udl_framebuffer, base)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index a52de2f..4a9b432 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -77,68 +77,6 @@ static uint16_t rgb16(uint32_t col)
}
#endif
-/*
- * NOTE: fb_defio.c is holding info->fbdefio.mutex
- * Touching ANY framebuffer memory that triggers a page fault
- * in fb_defio will cause a deadlock, when it also tries to
- * grab the same mutex.
- */
-static void udlfb_dpy_deferred_io(struct fb_info *info,
- struct list_head *pagelist)
-{
- struct page *cur;
- struct fb_deferred_io *fbdefio = info->fbdefio;
- struct udl_fbdev *ufbdev = info->par;
- struct drm_device *dev = ufbdev->ufb.base.dev;
- struct udl_device *udl = dev->dev_private;
- struct urb *urb;
- char *cmd;
- cycles_t start_cycles, end_cycles;
- int bytes_sent = 0;
- int bytes_identical = 0;
- int bytes_rendered = 0;
-
- if (!fb_defio)
- return;
-
- start_cycles = get_cycles();
-
- urb = udl_get_urb(dev);
- if (!urb)
- return;
-
- cmd = urb->transfer_buffer;
-
- /* walk the written page list and render each to device */
- list_for_each_entry(cur, &fbdefio->pagelist, lru) {
-
- if (udl_render_hline(dev, (ufbdev->ufb.base.bits_per_pixel / 8),
-&urb, (char *) info->fix.smem_start,
-&cmd, cur->index << PAGE_SHIFT,
-cur->index << PAGE_SHIFT,
-PAGE_SIZE, &bytes_identical, &bytes_sent))
- goto error;
- bytes_rendered += PAGE_SIZE;
- }
-
- if (cmd > (char *) urb->transfer_buffer) {
- /* Send partial buffer remaining before exiting */
- int len = cmd - (char *) urb->transfer_buffer;
- udl_submit_urb(dev, urb, len);
- bytes_sent += len;
- } else
- udl_urb_completion(urb);
-
-error:
- atomic_add(bytes_sent, &udl->bytes_sent);
- atomic_add(bytes_identical, &udl->bytes_identical);
- atomic_add(bytes_rendered, &udl->bytes_rendered);
- end_cycles = get_cycles();
- atomic_add(((unsigned int) ((end_cycles - start_cycles)
- >> 10)), /* Kcycles */
- &udl->cpu_kcycles_used);
-}
-
int udl_handle_damage(struct udl_framebuffer *fb, int x, int y,
int width, int height)
{
@@ -152,9 +90,6 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, int
y,
struct urb *urb;
int aligned_x;
int bpp = (fb->base.bits_per_pixel / 8);
- int x2, y2;
- bool store_for_later = false;
- unsigned long flags;
if (!fb->active_16)
return 0;
@@ -180,38 +115,6 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x,
int y,
(y + height > fb->base.height))
return -EINVAL;
- /* if we are in atomic just store the info
- can't test inside spin lock */
- if (in_atomic())
- store_for_later = true;
-
- x2 = x + width - 1;
- y2 = y + height - 1;
-
- spin_lock_irqsave(&fb->dirty_lock, flags);
-
- if (fb->y1 < y)
- y = fb->y1;
- if (fb->y2 > y2)
- y2 = fb->y2;
- if (fb->x1 < x)
- x = fb->x1;
- if (fb->x2 > x2)
- x2 = fb->x2;
-
- if (store_for_later) {
- fb->x1 = x;
- fb->x2 = x2;
- fb->y1 = y;
- fb->y2 = y2;
- spin_unlock_irqrestore(&fb->dirty_lock, flags);
- return 0;
- }
-
- fb->x1 = fb->y1 = INT_MAX;
- fb->x2 = fb->y2 = 0;
[PATCH v4 6/7] drm/qxl: Use drm_fb_helper deferred_io support
Use the fbdev deferred io support in drm_fb_helper which mirrors the
one qxl has had.
This patch has only been compile tested.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
Changes since v2:
- The drm_clip_rect_{width/height} functions are dropped, so open code it
Changes since v1:
- Add FIXME about special dirty() callback for fbdev
- Remove note in commit message about deferred worker, drm_fb_helper
is similar to qxl now.
drivers/gpu/drm/qxl/qxl_display.c | 9 +-
drivers/gpu/drm/qxl/qxl_drv.h | 7 +-
drivers/gpu/drm/qxl/qxl_fb.c | 223 ++
drivers/gpu/drm/qxl/qxl_kms.c | 4 -
4 files changed, 65 insertions(+), 178 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 030409a..9a03524 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -465,7 +465,7 @@ static const struct drm_crtc_funcs qxl_crtc_funcs = {
.page_flip = qxl_crtc_page_flip,
};
-static void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
+void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);
@@ -527,12 +527,13 @@ int
qxl_framebuffer_init(struct drm_device *dev,
struct qxl_framebuffer *qfb,
const struct drm_mode_fb_cmd2 *mode_cmd,
-struct drm_gem_object *obj)
+struct drm_gem_object *obj,
+const struct drm_framebuffer_funcs *funcs)
{
int ret;
qfb->obj = obj;
- ret = drm_framebuffer_init(dev, &qfb->base, &qxl_fb_funcs);
+ ret = drm_framebuffer_init(dev, &qfb->base, funcs);
if (ret) {
qfb->obj = NULL;
return ret;
@@ -999,7 +1000,7 @@ qxl_user_framebuffer_create(struct drm_device *dev,
if (qxl_fb == NULL)
return NULL;
- ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj);
+ ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj, &qxl_fb_funcs);
if (ret) {
kfree(qxl_fb);
drm_gem_object_unreference_unlocked(obj);
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 3f3897e..3ad6604 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -324,8 +324,6 @@ struct qxl_device {
struct workqueue_struct *gc_queue;
struct work_struct gc_work;
- struct work_struct fb_work;
-
struct drm_property *hotplug_mode_update_property;
int monitors_config_width;
int monitors_config_height;
@@ -389,11 +387,13 @@ int qxl_get_handle_for_primary_fb(struct qxl_device *qdev,
void qxl_fbdev_set_suspend(struct qxl_device *qdev, int state);
/* qxl_display.c */
+void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb);
int
qxl_framebuffer_init(struct drm_device *dev,
struct qxl_framebuffer *rfb,
const struct drm_mode_fb_cmd2 *mode_cmd,
-struct drm_gem_object *obj);
+struct drm_gem_object *obj,
+const struct drm_framebuffer_funcs *funcs);
void qxl_display_read_client_monitors_config(struct qxl_device *qdev);
void qxl_send_monitors_config(struct qxl_device *qdev);
int qxl_create_monitors_object(struct qxl_device *qdev);
@@ -553,7 +553,6 @@ int qxl_irq_init(struct qxl_device *qdev);
irqreturn_t qxl_irq_handler(int irq, void *arg);
/* qxl_fb.c */
-int qxl_fb_init(struct qxl_device *qdev);
bool qxl_fbdev_qobj_is_fb(struct qxl_device *qdev, struct qxl_bo *qobj);
int qxl_debugfs_add_files(struct qxl_device *qdev,
diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 3f7c543..739a08c 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -46,15 +46,6 @@ struct qxl_fbdev {
struct list_head delayed_ops;
void *shadow;
int size;
-
- /* dirty memory logging */
- struct {
- spinlock_t lock;
- unsigned x1;
- unsigned y1;
- unsigned x2;
- unsigned y2;
- } dirty;
};
static void qxl_fb_image_init(struct qxl_fb_image *qxl_fb_image,
@@ -82,169 +73,18 @@ static void qxl_fb_image_init(struct qxl_fb_image
*qxl_fb_image,
}
}
-static void qxl_fb_dirty_flush(struct fb_info *info)
-{
- struct qxl_fbdev *qfbdev = info->par;
- struct qxl_device *qdev = qfbdev->qdev;
- struct qxl_fb_image qxl_fb_image;
- struct fb_image *image = &qxl_fb_image.fb_image;
- unsigned long flags;
- u32 x1, x2, y1, y2;
-
- /* TODO: hard coding 32 bpp */
- int stride = qfbdev->qfb.base.pitches[0];
-
- spin_lock_irqsave(&qfbdev->dirty.lock, flags);
-
- x1 = qfbdev->dirty.x1;
- x2 = qfbdev->dirty.x2;
- y1 = qfbdev->dirty.y1;
- y2 = qfbdev->dirty.y2;
- qfbd
[PATCH v4 5/7] drm/fb-cma-helper: Add fb_deferred_io support
This adds fbdev deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
The driver has to provide a (struct drm_framebuffer_funcs *)->dirty()
callback to get notification of fbdev framebuffer changes.
If the dirty() hook is set, then fb_deferred_io is set up automatically
by the helper.
Two functions have been added so that the driver can provide a dirty()
function:
- drm_fbdev_cma_init_with_funcs()
This makes it possible for the driver to provided a custom
(struct drm_fb_helper_funcs *)->fb_probe() function.
- drm_fbdev_cma_create_with_funcs()
This is used by the .fb_probe hook to set a driver provided
(struct drm_framebuffer_funcs *)->dirty() function.
Cc: laurent.pinchart at ideasonboard.com
Signed-off-by: Noralf Trønnes
---
Changes since v2:
- FB_DEFERRED_IO is now always selected by DRM_KMS_FB_HELPER, ifdef removed
drivers/gpu/drm/drm_fb_cma_helper.c | 178 +---
include/drm/drm_fb_cma_helper.h | 14 +++
2 files changed, 180 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index bb88e3d..086f600 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -25,6 +25,8 @@
#include
#include
+#define DEFAULT_FBDEFIO_DELAY_MS 50
+
struct drm_fb_cma {
struct drm_framebuffer fb;
struct drm_gem_cma_object *obj[4];
@@ -35,6 +37,61 @@ struct drm_fbdev_cma {
struct drm_fb_cma *fb;
};
+/**
+ * DOC: framebuffer cma helper functions
+ *
+ * Provides helper functions for creating a cma (contiguous memory allocator)
+ * backed framebuffer.
+ *
+ * drm_fb_cma_create() is used in the
+ * (struct drm_mode_config_funcs *)->fb_create callback function to create the
+ * cma backed framebuffer.
+ *
+ * An fbdev framebuffer backed by cma is also available by calling
+ * drm_fbdev_cma_init(). drm_fbdev_cma_fini() tears it down.
+ * If CONFIG_FB_DEFERRED_IO is enabled and the callback
+ * (struct drm_framebuffer_funcs)->dirty is set, fb_deferred_io
+ * will be set up automatically. dirty() is called by
+ * drm_fb_helper_deferred_io() in process context (struct delayed_work).
+ *
+ * Example fbdev deferred io code:
+ *
+ * static int driver_fbdev_fb_dirty(struct drm_framebuffer *fb,
+ * struct drm_file *file_priv,
+ * unsigned flags, unsigned color,
+ * struct drm_clip_rect *clips,
+ * unsigned num_clips)
+ * {
+ * struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
+ * ... push changes ...
+ * return 0;
+ * }
+ *
+ * static struct drm_framebuffer_funcs driver_fbdev_fb_funcs = {
+ * .destroy = drm_fb_cma_destroy,
+ * .create_handle = drm_fb_cma_create_handle,
+ * .dirty = driver_fbdev_fb_dirty,
+ * };
+ *
+ * static int driver_fbdev_create(struct drm_fb_helper *helper,
+ * struct drm_fb_helper_surface_size *sizes)
+ * {
+ * return drm_fbdev_cma_create_with_funcs(helper, sizes,
+ *&driver_fbdev_fb_funcs);
+ * }
+ *
+ * static const struct drm_fb_helper_funcs driver_fb_helper_funcs = {
+ * .fb_probe = driver_fbdev_create,
+ * };
+ *
+ * Initialize:
+ * fbdev = drm_fbdev_cma_init_with_funcs(dev, 16,
+ * dev->mode_config.num_crtc,
+ * dev->mode_config.num_connector,
+ * &driver_fb_helper_funcs);
+ *
+ */
+
static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
{
return container_of(helper, struct drm_fbdev_cma, fb_helper);
@@ -45,7 +102,7 @@ static inline struct drm_fb_cma *to_fb_cma(struct
drm_framebuffer *fb)
return container_of(fb, struct drm_fb_cma, fb);
}
-static void drm_fb_cma_destroy(struct drm_framebuffer *fb)
+void drm_fb_cma_destroy(struct drm_framebuffer *fb)
{
struct drm_fb_cma *fb_cma = to_fb_cma(fb);
int i;
@@ -58,8 +115,9 @@ static void drm_fb_cma_destroy(struct drm_framebuffer *fb)
drm_framebuffer_cleanup(fb);
kfree(fb_cma);
}
+EXPORT_SYMBOL(drm_fb_cma_destroy);
-static int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
+int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
struct drm_file *file_priv, unsigned int *handle)
{
struct drm_fb_cma *fb_cma = to_fb_cma(fb);
@@ -67,6 +125,7 @@ static int drm_fb_cma_create_handle(struct drm_framebuffer
*fb,
return drm_gem_handle_create(file_priv,
&fb_cma->obj[0]->base, handle);
}
+EXPORT_SYMBOL(drm_fb_cma_create_handle);
static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
.destroy= drm_fb_cma_destroy,
@@ -76,7 +135,7 @@ static struct drm_framebuf
[PATCH v4 4/7] fbdev: fb_defio: Export fb_deferred_io_mmap
Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
When the framebuffer memory is allocated using dma_alloc_writecombine()
instead of vmalloc(), I get cache syncing problems on ARM.
This solves it:
static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
struct vm_area_struct *vma)
{
fb_deferred_io_mmap(info, vma);
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
return 0;
}
Could this have been done in the core?
Drivers that don't set (struct fb_ops *)->fb_mmap, gets a call to
fb_pgprotect() at the end of the default fb_mmap implementation
(drivers/video/fbdev/core/fbmem.c). This is an architecture specific
function that on many platforms uses pgprot_writecombine(), but not on
all. And looking at some of the fb_mmap implementations, some of them
sets vm_page_prot to nocache for instance, so I think the safest bet is
to do this in the driver and not in the fbdev core. And we can't call
fb_pgprotect() from fb_deferred_io_mmap() either because we don't have
access to the file pointer that powerpc needs.
Signed-off-by: Noralf Trønnes
---
Changes since v1:
- Expand commit message
drivers/video/fbdev/core/fb_defio.c | 3 ++-
include/linux/fb.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fb_defio.c
b/drivers/video/fbdev/core/fb_defio.c
index 57721c7..74b5bca 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -164,7 +164,7 @@ static const struct address_space_operations
fb_deferred_io_aops = {
.set_page_dirty = fb_deferred_io_set_page_dirty,
};
-static int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct
*vma)
+int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
vma->vm_ops = &fb_deferred_io_vm_ops;
vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
@@ -173,6 +173,7 @@ static int fb_deferred_io_mmap(struct fb_info *info, struct
vm_area_struct *vma)
vma->vm_private_data = info;
return 0;
}
+EXPORT_SYMBOL(fb_deferred_io_mmap);
/* workqueue callback */
static void fb_deferred_io_work(struct work_struct *work)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index dfe8835..a964d07 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -673,6 +673,7 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32
d_pitch,
}
/* drivers/video/fb_defio.c */
+int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
extern void fb_deferred_io_init(struct fb_info *info);
extern void fb_deferred_io_open(struct fb_info *info,
struct inode *inode,
--
2.2.2
[PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support
This adds deferred io support to drm_fb_helper.
The fbdev framebuffer changes are flushed using the callback
(struct drm_framebuffer *)->funcs->dirty() by a dedicated worker
ensuring that it always runs in process context.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
Changes since v3:
- Don't use forward decl, move drm_fb_helper_dirty_work()
- Use DIV_ROUND_UP in drm_fb_helper_deferred_io()
Changes since v2:
- FB_DEFERRED_IO is now always selected by DRM_KMS_FB_HELPER, ifdef removed
- The drm_clip_rect utility functions are dropped, so open code it
- docs: use & to denote structs
Changes since v1:
- Use a dedicated worker to run the framebuffer flushing like qxl does
- Add parameter descriptions to drm_fb_helper_deferred_io
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_fb_helper.c | 103 +++-
include/drm/drm_fb_helper.h | 15 ++
3 files changed, 118 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 9e4f2f1..8e6f34b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -52,6 +52,7 @@ config DRM_KMS_FB_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_DEFERRED_IO
help
FBDEV helpers for KMS drivers.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 855108e..62f849f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -84,6 +84,15 @@ static LIST_HEAD(kernel_fb_helper_list);
* and set up an initial configuration using the detected hardware, drivers
* should call drm_fb_helper_single_add_all_connectors() followed by
* drm_fb_helper_initial_config().
+ *
+ * If CONFIG_FB_DEFERRED_IO is enabled and &drm_framebuffer_funcs ->dirty is
+ * set, the drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit}
+ * functions will accumulate changes and schedule &fb_helper .dirty_work to run
+ * right away. This worker then calls the dirty() function ensuring that it
+ * will always run in process context since the fb_*() function could be
+ * running in atomic context. If drm_fb_helper_deferred_io() is used as the
+ * deferred_io callback it will also schedule dirty_work with the damage
+ * collected from the mmap page writes.
*/
/**
@@ -637,6 +646,23 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper
*helper)
kfree(helper->crtc_info);
}
+static void drm_fb_helper_dirty_work(struct work_struct *work)
+{
+ struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
+ dirty_work);
+ struct drm_clip_rect *clip = &helper->dirty_clip;
+ struct drm_clip_rect clip_copy;
+ unsigned long flags;
+
+ spin_lock_irqsave(&helper->dirty_lock, flags);
+ clip_copy = *clip;
+ clip->x1 = clip->y1 = ~0;
+ clip->x2 = clip->y2 = 0;
+ spin_unlock_irqrestore(&helper->dirty_lock, flags);
+
+ helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
+}
+
/**
* drm_fb_helper_prepare - setup a drm_fb_helper structure
* @dev: DRM device
@@ -650,6 +676,9 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
drm_fb_helper *helper,
const struct drm_fb_helper_funcs *funcs)
{
INIT_LIST_HEAD(&helper->kernel_fb_list);
+ spin_lock_init(&helper->dirty_lock);
+ INIT_WORK(&helper->dirty_work, drm_fb_helper_dirty_work);
+ helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
helper->funcs = funcs;
helper->dev = dev;
}
@@ -834,6 +863,59 @@ void drm_fb_helper_unlink_fbi(struct drm_fb_helper
*fb_helper)
}
EXPORT_SYMBOL(drm_fb_helper_unlink_fbi);
+static void drm_fb_helper_dirty(struct fb_info *info, u32 x, u32 y,
+ u32 width, u32 height)
+{
+ struct drm_fb_helper *helper = info->par;
+ struct drm_clip_rect *clip = &helper->dirty_clip;
+ unsigned long flags;
+
+ if (!helper->fb->funcs->dirty)
+ return;
+
+ spin_lock_irqsave(&helper->dirty_lock, flags);
+ clip->x1 = min_t(u32, clip->x1, x);
+ clip->y1 = min_t(u32, clip->y1, y);
+ clip->x2 = max_t(u32, clip->x2, x + width);
+ clip->y2 = max_t(u32, clip->y2, y + height);
+ spin_unlock_irqrestore(&helper->dirty_lock, flags);
+
+ schedule_work(&helper->dirty_work);
+}
+
+/**
+ * drm_fb_helper_deferred_io() - fbdev deferred_io callback function
+ * @info: fb_info struct pointer
+ * @pagelist: list of dirty mmap framebuffer pages
+ *
+ * This function is used as the &fb_deferred_io ->deferred_io
+ * callback function for flushing the fbdev mmap writes.
+ */
+void drm_fb_helper_deferred_io(struct fb_info *info,
+ struct list_head *pagelist)
+{
+ unsigned long start, end, min, max;
+ struct page *page;
+ u32 y1, y2;
+
+ min
[PATCH v4 2/7] drm/qxl: Change drm_fb_helper_sys_*() calls to sys_*()
Now that drm_fb_helper gets deferred io support, the
drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
a worker that will call the (struct drm_framebuffer *)->funcs->dirty()
function. This will break this driver so use the
sys_{fillrect,copyarea,imageblit} functions directly.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/qxl/qxl_fb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index bb7ce07..3f7c543 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -199,7 +199,7 @@ static void qxl_fb_fillrect(struct fb_info *info,
{
struct qxl_fbdev *qfbdev = info->par;
- drm_fb_helper_sys_fillrect(info, rect);
+ sys_fillrect(info, rect);
qxl_dirty_update(qfbdev, rect->dx, rect->dy, rect->width,
rect->height);
}
@@ -209,7 +209,7 @@ static void qxl_fb_copyarea(struct fb_info *info,
{
struct qxl_fbdev *qfbdev = info->par;
- drm_fb_helper_sys_copyarea(info, area);
+ sys_copyarea(info, area);
qxl_dirty_update(qfbdev, area->dx, area->dy, area->width,
area->height);
}
@@ -219,7 +219,7 @@ static void qxl_fb_imageblit(struct fb_info *info,
{
struct qxl_fbdev *qfbdev = info->par;
- drm_fb_helper_sys_imageblit(info, image);
+ sys_imageblit(info, image);
qxl_dirty_update(qfbdev, image->dx, image->dy, image->width,
image->height);
}
--
2.2.2
[PATCH v4 1/7] drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()
Now that drm_fb_helper gets deferred io support, the
drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
a worker that will call the (struct drm_framebuffer *)->funcs->dirty()
function. This will break this driver so use the
sys_{fillrect,copyarea,imageblit} functions directly.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/udl/udl_fb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index fd1eb9d..a52de2f 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -287,7 +287,7 @@ static void udl_fb_fillrect(struct fb_info *info, const
struct fb_fillrect *rect
{
struct udl_fbdev *ufbdev = info->par;
- drm_fb_helper_sys_fillrect(info, rect);
+ sys_fillrect(info, rect);
udl_handle_damage(&ufbdev->ufb, rect->dx, rect->dy, rect->width,
rect->height);
@@ -297,7 +297,7 @@ static void udl_fb_copyarea(struct fb_info *info, const
struct fb_copyarea *regi
{
struct udl_fbdev *ufbdev = info->par;
- drm_fb_helper_sys_copyarea(info, region);
+ sys_copyarea(info, region);
udl_handle_damage(&ufbdev->ufb, region->dx, region->dy, region->width,
region->height);
@@ -307,7 +307,7 @@ static void udl_fb_imageblit(struct fb_info *info, const
struct fb_image *image)
{
struct udl_fbdev *ufbdev = info->par;
- drm_fb_helper_sys_imageblit(info, image);
+ sys_imageblit(info, image);
udl_handle_damage(&ufbdev->ufb, image->dx, image->dy, image->width,
image->height);
--
2.2.2
[PATCH v4 0/7] drm: Add fbdev deferred io support to helpers
This patchset adds fbdev deferred io support to drm_fb_helper and
drm_fb_cma_helper.
It channels fbdev mmap and fb_{write,fillrect,copyarea,imageblit} damage
through the (struct drm_framebuffer_funcs)->dirty callback on the
fb_helper framebuffer which will always run in process context.
I have also added patches that converts qxl and udl to use this
deferred io support. I have only compile tested it, no functional testing.
I know that qxl is purely a software thing so I could actually test it, but
I have never used qemu so I'm not keen on spending a lot of time on that.
This was originally part of the tinydrm patchset.
Changes since v3:
- drm/fb-helper: Add fb_deferred_io support
- Don't use forward decl, move drm_fb_helper_dirty_work()
- Use DIV_ROUND_UP in drm_fb_helper_deferred_io()
Changes since v2:
- drm/rect: Add some drm_clip_rect utility functions
- This patch is dropped
- drm/fb-helper: Add fb_deferred_io support
- FB_DEFERRED_IO is now always selected by DRM_KMS_FB_HELPER, ifdef removed
- The drm_clip_rect utility functions are dropped, so open code it
- docs: use & to denote structs
- drm/qxl: Use drm_fb_helper deferred_io support
- The drm_clip_rect_{width/height} functions are dropped, so open code it
Changes since v1:
- drm/fb-helper: Add fb_deferred_io support
- Use a dedicated worker to run the framebuffer flushing like qxl does
- Add parameter descriptions to drm_fb_helper_deferred_io
- fbdev: fb_defio: Export fb_deferred_io_mmap
- Expand commit message
- drm/qxl: Use drm_fb_helper deferred_io support
- Add FIXME about special dirty() callback for fbdev
- Remove note in commit message about deferred worker, drm_fb_helper
is similar to qxl now.
- drm/udl: Use drm_fb_helper deferred_io support
- No need to enable deferred_io by default since drm_fb_helper uses
a dedicated worker for flushing
Changes since RFC:
- Fix drm_clip_rect use to be exclusive on x2/y2
- Put drm_clip_rect functions in drm_rect.{h,c}
- Take into account that (struct fb_ops *)->fb_{write,...}() can be called
from atomic context (spin_lock_irqsave)
- Export fb_deferred_io_mmap()
- Add some more documentation
- Add qxl and udl patches
Noralf Trønnes (7):
drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()
drm/qxl: Change drm_fb_helper_sys_*() calls to sys_*()
drm/fb-helper: Add fb_deferred_io support
fbdev: fb_defio: Export fb_deferred_io_mmap
drm/fb-cma-helper: Add fb_deferred_io support
drm/qxl: Use drm_fb_helper deferred_io support
drm/udl: Use drm_fb_helper deferred_io support
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_fb_cma_helper.c | 178 ++--
drivers/gpu/drm/drm_fb_helper.c | 103 -
drivers/gpu/drm/qxl/qxl_display.c | 9 +-
drivers/gpu/drm/qxl/qxl_drv.h | 7 +-
drivers/gpu/drm/qxl/qxl_fb.c| 223 +---
drivers/gpu/drm/qxl/qxl_kms.c | 4 -
drivers/gpu/drm/udl/udl_drv.h | 2 -
drivers/gpu/drm/udl/udl_fb.c| 140 +-
drivers/video/fbdev/core/fb_defio.c | 3 +-
include/drm/drm_fb_cma_helper.h | 14 +++
include/drm/drm_fb_helper.h | 15 +++
include/linux/fb.h | 1 +
13 files changed, 372 insertions(+), 328 deletions(-)
--
2.2.2
[PATCH v3 2/2] dt-bindings: imx: ldb: Add ddc-i2c-bus property
On Wed, Apr 27, 2016 at 04:23:34PM -0400, Akshay Bhat wrote: > Document the ddc-i2c-bus property used by imx-ldb driver to read EDID > information via I2C interface. > > Signed-off-by: Akshay Bhat > --- > > v3: > Newly added. > > Documentation/devicetree/bindings/display/imx/ldb.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/imx/ldb.txt > b/Documentation/devicetree/bindings/display/imx/ldb.txt > index 0a175d9..a407462 100644 > --- a/Documentation/devicetree/bindings/display/imx/ldb.txt > +++ b/Documentation/devicetree/bindings/display/imx/ldb.txt > @@ -62,6 +62,7 @@ Required properties: > display-timings are used instead. > > Optional properties (required if display-timings are used): The required part doesn't make sense if you add this, but... > + - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing Really, this should be part of a connector node since i2c goes from the i2c controller to a connector and is not part of the display controller. > - display-timings : A node that describes the display timings as defined in > Documentation/devicetree/bindings/display/display-timing.txt. > - fsl,data-mapping : should be "spwg" or "jeida" > -- > 2.8.1 >
[GIT PULL] drm/fsl-dcu: TCON support and fixes for v4.7
Hi Dave, This adds very rudimentary TCON (timing controller for raw LCD displays) support to enable the bypass mode in order to use the DCU controller on Freescale/NXP Vybrid SoC's. Additionally the register clock and pixel clock has been separated, but are currently still enabled and disabled pairwise. Other than that, fixes and cleanups accross the driver. -- Stefan The following changes since commit 027b3f8ba9277410c3191d72d1ed2c6146d8a668: drm/modes: stop handling framebuffer special (2016-04-22 10:47:16 +1000) are available in the git repository at: http://git.agner.ch/git/linux-drm-fsl-dcu.git for-next for you to fetch changes up to 0449eefe2db1038a327db45d5428c196f63c0cb9: drm/fsl-dcu: increment version and date (2016-04-25 23:27:08 -0700) Arnd Bergmann (1): drm/layerscape: reduce excessive stack usage Stefan Agner (11): drm/fsl-dcu: disable clock on initialization failure and remove drm/fsl-dcu: add extra clock for pixel clock drm/fsl-dcu: use common clock framework for pixel clock divider drm/fsl-dcu: add TCON driver drm/fsl-dcu: detach panel on destroy drm/fsl-dcu: handle missing panel gracefully drm/fsl-dcu: use variable name dev for struct drm_device drm/fsl-dcu: deallocate fbdev CMA on unload drm/fsl-dcu: disable output polling on driver unload drm/fsl-dcu: implement lastclose callback drm/fsl-dcu: increment version and date .../devicetree/bindings/display/fsl,dcu.txt| 15 ++- .../devicetree/bindings/display/fsl,tcon.txt | 18 +++ MAINTAINERS| 1 + drivers/gpu/drm/fsl-dcu/Makefile | 3 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 7 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 127 +++-- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 2 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 38 -- drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 111 ++ drivers/gpu/drm/fsl-dcu/fsl_tcon.h | 33 ++ 10 files changed, 298 insertions(+), 57 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/fsl,tcon.txt create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_tcon.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_tcon.h
[RFC v2 5/8] drm/fence: add in-fences support
On Thu, Apr 28, 2016 at 11:36:44AM -0300, Gustavo Padovan wrote: > 2016-04-27 Daniel Stone : > > > Hi, > > > > On 26 April 2016 at 21:48, Greg Hackmann wrote: > > > On 04/26/2016 01:05 PM, Daniel Vetter wrote: > > >> On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote: > > >>> What are they doing that can't stuff the fences into an array > > >>> instead of props? > > >> > > >> The hw composer interface is one in-fence per plane. That's really the > > >> major reason why the kernel interface is built to match. And I really > > >> don't think we should diverge just because we have a slight different > > >> color preference ;-) > > > > > > The relationship between layers and fences is only fuzzy and indirect > > > though. The relationship is really between the buffer you're displaying > > > on > > > that layer, and the fence representing the work done to render into that > > > buffer. SurfaceFlinger just happens to bundle them together inside the > > > same > > > struct hwc_layer_1 as an API convenience. > > > > Right, and when using implicit fencing, this comes as a plane > > property, by virtue of plane -> fb -> buffer -> fence. > > > > > Which is kind of splitting hairs as long as you have a 1-to-1 relationship > > > between layers and DRM planes. But that's not always the case. > > > > Can you please elaborate? > > > > > A (per-CRTC?) array of fences would be more flexible. And even in the > > > cases > > > where you could make a 1-to-1 mapping between planes and fences, it's not > > > that much more work for userspace to assemble those fences into an array > > > anyway. > > > > As Ville says, I don't want to go down the path of scheduling CRTC > > updates separately, because that breaks MST pretty badly. If you don't > > want your updates to display atomically, then don't schedule them > > atomically ... ? That's the only reason I can see for making fencing > > per-CRTC, rather than just a pile of unassociated fences appended to > > the request. Per-CRTC fences also forces userspace to merge fences > > before submission when using multiple planes per CRTC, which is pretty > > punitive. > > > > I think having it semantically attached to the plane is a little bit > > nicer for tracing (why was this request delayed? -> a fence -> which > > buffer was that fence for?) at a glance. Also the 'pile of appended > > fences' model is a bit awkward for more generic userspace, which > > creates a libdrm request and builds it (add a plane, try it out, wind > > back) incrementally. Using properties makes that really easy, but > > without properties, we'd have to add separate codepaths - and thus > > separate ABI, which complicates distribution - to libdrm to account > > for a separate plane array which shares a cursor with the properties. > > So for that reason if none other, I'd really prefer not to go down > > that route. > > I also agree to have it as FENCE_FD prop on the plane. Summarizing the > arguments on this thread, they are: > > - implicit fences also needs one fence per plane/fb, so it will be good to > >match with that. > > - requires userspace to always merge fences > "does not require" I presume? > - can use standard plane properties, making kernel and userspace life > easier, >an array brings more work to build the atomic request plus extra checkings > >on the kernel. > > - do not need to changes to drivers > > - better for tracing, can identify the buffer/fence promptly - Fits in well with the libdrm atomic rollback support - no need to manage fences separately when incrementally building an atomic commit. > > Gustavo > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/atomic: Add missing drm_crtc_internal.h include
On Thu, Apr 28, 2016 at 03:19:56PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Some of the functions implemented are flagged as not having a prototype > defined when building with W=1. Include the header to avoid these build > warnings. > > Signed-off-by: Thierry Reding Applied to drm-misc, thanks. -Daniel > --- > drivers/gpu/drm/drm_atomic.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 8ee1db866e80..2fabd8c4fd88 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -31,6 +31,8 @@ > #include > #include > > +#include "drm_crtc_internal.h" > + > /** > * drm_atomic_state_default_release - > * release memory initialized by drm_atomic_state_init > -- > 2.8.0 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/etnaviv: remove BUG_ON in MMU unmap path
Am Donnerstag, den 28.04.2016, 14:55 +0100 schrieb Russell King - ARM Linux: > On Wed, Apr 27, 2016 at 02:38:18PM +0200, Lucas Stach wrote: > > If the MMU map fails caused by an unaligned SG entry, the unmap path > > is called to undo all already setup SG mappings. When encountering the > > unaligned SG the unmap path hangs the kernel with a BUG(), while the > > error is recoverable by just failing the submit that references the > > faulty object. > > I'm very tempted to NAK this, because I introduced it with good reason: > we should never see anything except a page-aligned number of bytes here. > > Are you seeing this trigger? > I've only seen this once and I don't know what caused it really. Maybe some unrelated corruption. The observation was that the common code in iommu_map() rightfully rejected to map things, as mapping something unaligned to the page size is totally bogus. iommu_unmap will detect this condition in the same way. So without this BUG_ON() the kernel would have been able to recover from the bogus input data (maybe allowing to debug things further), but with the BUG_ON() in place it just dies. Regards, Lucas
[PATCH] Revert "drm/omap: no need to select OMAP2_DSS"
This reverts commit 1c278e5e3718d15475ec08ee2135f37a6b13361c. If DRM_OMAP does not select OMAP2_DSS it is possible to build a kernel with DRM_OMAP only and not selecting OMAP2_DSS. Since omapdrm depends on OMAP2_DSS this will result on broken kernel build. Signed-off-by: Peter Ujfalusi --- drivers/gpu/drm/omapdrm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig index 73241c4eb7aa..336ad4de9981 100644 --- a/drivers/gpu/drm/omapdrm/Kconfig +++ b/drivers/gpu/drm/omapdrm/Kconfig @@ -2,6 +2,7 @@ config DRM_OMAP tristate "OMAP DRM" depends on DRM depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM + select OMAP2_DSS select DRM_KMS_HELPER select DRM_KMS_FB_HELPER select FB_SYS_FILLRECT -- 2.8.1
[PATCH] drm/omap: Remove deprecated regulator_can_change_voltage() usage
regulator_can_change_voltage() is deprecated and it's use is not necessary
as commit:
6a0028b3dd67b regulator: Deprecate regulator_can_change_voltage()
describers it clearly.
As there is no practical use of it it can be removed.
At this point the regulator_set_voltage() calls can not be removed as the
DT data need to be fixed first.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 12 +---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 12 +---
3 files changed, 15 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 8730646a0cbb..316cde6a794f 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -1180,13 +1180,11 @@ static int dsi_regulator_init(struct platform_device
*dsidev)
return PTR_ERR(vdds_dsi);
}
- if (regulator_can_change_voltage(vdds_dsi)) {
- r = regulator_set_voltage(vdds_dsi, 180, 180);
- if (r) {
- devm_regulator_put(vdds_dsi);
- DSSERR("can't set the DSI regulator voltage\n");
- return r;
- }
+ r = regulator_set_voltage(vdds_dsi, 180, 180);
+ if (r) {
+ devm_regulator_put(vdds_dsi);
+ DSSERR("can't set the DSI regulator voltage\n");
+ return r;
}
dsi->vdds_dsi_reg = vdds_dsi;
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index f892ae157ff3..289f87ae9f62 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -114,13 +114,11 @@ static int hdmi_init_regulator(void)
return PTR_ERR(reg);
}
- if (regulator_can_change_voltage(reg)) {
- r = regulator_set_voltage(reg, 180, 180);
- if (r) {
- devm_regulator_put(reg);
- DSSWARN("can't set the regulator voltage\n");
- return r;
- }
+ r = regulator_set_voltage(reg, 180, 180);
+ if (r) {
+ devm_regulator_put(reg);
+ DSSWARN("can't set the regulator voltage\n");
+ return r;
}
hdmi.vdda_reg = reg;
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index a43f7b10e113..b6d101076eb4 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -131,13 +131,11 @@ static int hdmi_init_regulator(void)
return PTR_ERR(reg);
}
- if (regulator_can_change_voltage(reg)) {
- r = regulator_set_voltage(reg, 180, 180);
- if (r) {
- devm_regulator_put(reg);
- DSSWARN("can't set the regulator voltage\n");
- return r;
- }
+ r = regulator_set_voltage(reg, 180, 180);
+ if (r) {
+ devm_regulator_put(reg);
+ DSSWARN("can't set the regulator voltage\n");
+ return r;
}
hdmi.vdda_reg = reg;
--
2.8.1
[PATCH] drm/etnaviv: remove BUG_ON in MMU unmap path
On Thu, Apr 28, 2016 at 04:04:58PM +0200, Lucas Stach wrote:
> The observation was that the common code in iommu_map() rightfully
> rejected to map things, as mapping something unaligned to the page size
> is totally bogus.
Shouldn't iommu_map() detect this?
/*
* both the virtual address and the physical one, as well as
* the size of the mapping, must be aligned (at least) to the
* size of the smallest page supported by the hardware
*/
if (!IS_ALIGNED(iova | paddr | size, min_pagesz)) {
pr_err("unaligned: iova 0x%lx pa %pa size 0x%zx min_pagesz
0x%x\n",
iova, &paddr, size, min_pagesz);
return -EINVAL;
}
where min_pagesz is derived from:
.pgsize_bitmap = SZ_4K,
and will be 4096. So, iommu_map() should reject this, and
etnaviv_iommu_map() will tear down the partially created mapping, and
propagate the error code to its caller, that being etnaviv_iommu_map_gem().
etnaviv_iommu_map_gem() will remove the drm_mm node, propagating the
failure up to etnaviv_gem_mapping_get(), which will free the
etnaviv_vram_mapping structure.
I fail to see how we could get into etnaviv_iommu_unmap() with a bad
mapping, other than if there's memory corruption, and if there is
memory corruption, hanging the kernel with a BUG_ON() is totally the
right thing to do. Better that than a corrupted filesystem.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash
https://bugs.freedesktop.org/show_bug.cgi?id=92258 --- Comment #42 from Vladislav Kamenev --- (In reply to Michel D�nzer from comment #41) > (In reply to Vladislav Kamenev from comment #40) > > cannot encounter freeze while using kernel with ZEN patches. > > What patches are those? https://liquorix.net/ And i run into one or two freezes during these three days. And now it looks like nature of my freezes differs from OP's one, despite having 6650m like him. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/d349b690/attachment.html>
[Intel-gfx] [PATCH] drm/i915: Fix enc_to_dig_port() for MST encoders
On Thu, 28 Apr 2016, Ville Syrjälä wrote:
> On Thu, Apr 28, 2016 at 09:17:00AM +0300, Jani Nikula wrote:
>> On Wed, 27 Apr 2016, Lyude wrote:
>> > For MST encoders, the encoder struct is stored in the intel_dp_mst
>> > struct, not a intel_digital_port struct.
>> >
>> > This fixes issues with hotplugging MST displays that support MST audio,
>> > where hotplugging had a surprisingly good chance of accidentally
>> > overwriting other parts of the kernel leading to seemingly unrelated
>> > backtraces in sysfs, ext4, etc.
>> >
>> > Cc: stable at vger.kernel.org
>> > Signed-off-by: Lyude
>>
>> Ugh. Just ugh.
>>
>> At a glance, it's probably this one that starts calling
>> intel_audio_codec_enable() and intel_audio_codec_disable() on DP MST:
>>
>> commit 3d52ccf52f2c51f613e42e65be0f06e4e6788093
>> Author: Libin Yang
>> Date: Wed Dec 2 14:09:44 2015 +0800
>>
>> drm/i915: start adding dp mst audio
>>
>> which has been there since v4.5. Would it be feasible for you to revert
>> the commit or change it so that it stops calling the audio codec
>> enable/disable, to verify this is the culprit? So we could add a proper
>> Fixes: line too.
>
> I don't particularly like making enc_to_dig_port() work on MST encoders
> because it'll likely result in the wrong thing anyway. I already asked
> before how MST audio port handling is supposed to work, but never got
> any answer. Right now, if you just use the ->primary dig_port in the
> audio paths, there's no way audio can work correctly with MST, at least
> if you enable multiple streams on the same port.
>
> So what I would do is just revert the audio calls from the MST paths and
> go back to the drawing board.
I don't mind that approach either.
I was thinking we should probably add some dynamic type checking to
enc_to_dig_port to catch this type of bugs.
BR,
Jani.
>
>>
>> The non-MST aware enc_to_dig_port() calls on platforms that might have
>> MST were added in:
>>
>> commit 51e1d83cab9988716ae68801a721f4df0aaa374b
>> Author: David Henningsson
>> Date: Wed Aug 19 10:48:56 2015 +0200
>>
>> drm/i915: Call audio pin/ELD notify function
>>
>> and:
>>
>> commit 7e8275c2f2bbb384e18af37066b8b2f32b7d092f
>> Author: Libin Yang
>> Date: Fri Sep 25 09:36:12 2015 +0800
>>
>> drm/i915: set proper N/CTS in modeset
>>
>> but I don't think the codec enable/disable were called on MST at that
>> time.
>>
>> Some of the problem was probably seen by Takashi in
>>
>> commit 0bdf5a05647a66dcc6394986e061daeac9b1cf96
>> Author: Takashi Iwai
>> Date: Mon Nov 30 18:19:39 2015 +0100
>>
>> drm/i915: Add reverse mapping between port and intel_encoder
>>
>> which has a comment /* intel_encoder might be NULL for DP MST */. Maybe
>> that needs to be updated to DTRT too.
>>
>>
>> Lyude, thanks for your efforts in DP MST area. Much appreciated.
>>
>>
>> BR,
>> Jani.
>>
>>
>>
>> > ---
>> > drivers/gpu/drm/i915/intel_drv.h | 17 +++--
>> > 1 file changed, 11 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> > b/drivers/gpu/drm/i915/intel_drv.h
>> > index 4c027d6..81f2212 100644
>> > --- a/drivers/gpu/drm/i915/intel_drv.h
>> > +++ b/drivers/gpu/drm/i915/intel_drv.h
>> > @@ -918,18 +918,23 @@ intel_attached_encoder(struct drm_connector
>> > *connector)
>> >return to_intel_connector(connector)->encoder;
>> > }
>> >
>> > -static inline struct intel_digital_port *
>> > -enc_to_dig_port(struct drm_encoder *encoder)
>> > -{
>> > - return container_of(encoder, struct intel_digital_port, base.base);
>> > -}
>> > -
>> > static inline struct intel_dp_mst_encoder *
>> > enc_to_mst(struct drm_encoder *encoder)
>> > {
>> >return container_of(encoder, struct intel_dp_mst_encoder, base.base);
>> > }
>> >
>> > +static inline struct intel_digital_port *
>> > +enc_to_dig_port(struct drm_encoder *encoder)
>> > +{
>> > + if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST)
>> > + return enc_to_mst(encoder)->primary;
>> > + else {
>> > + return container_of(encoder, struct intel_digital_port,
>> > + base.base);
>> > + }
>> > +}
>> > +
>> > static inline struct intel_dp *enc_to_intel_dp(struct drm_encoder
>> > *encoder)
>> > {
>> >return &enc_to_dig_port(encoder)->dp;
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/atomic: Add missing drm_crtc_internal.h include
From: Thierry Reding Some of the functions implemented are flagged as not having a prototype defined when building with W=1. Include the header to avoid these build warnings. Signed-off-by: Thierry Reding --- drivers/gpu/drm/drm_atomic.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 8ee1db866e80..2fabd8c4fd88 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -31,6 +31,8 @@ #include #include +#include "drm_crtc_internal.h" + /** * drm_atomic_state_default_release - * release memory initialized by drm_atomic_state_init -- 2.8.0
[PATCH 00/24] drm: add extern C guard for the UAPI headers
On Wed, Apr 27, 2016 at 10:45:54PM +0100, Emil Velikov wrote: > On 27 April 2016 at 10:47, Russell King - ARM Linux > wrote: > > On Thu, Apr 21, 2016 at 09:17:13PM +0100, Emil Velikov wrote: > >> Dave Airlie pointed out that "polluting" the headers in a manner as seen > >> with this series might not be too wise. David H, can we hear your view > >> on the topic ? > > > > For armada and etnaviv, it seems sensible, so I'd be happy to see the > > change go in if it means less work for others. > > > > Hence, for patch 2 and 4, > > > > Acked-by: Russell King > > > Thank you Russel ! While I was away on a long weekend, I was talking to a TV programme editor who occasionally suffers from his name being spelt incorrectly in TV credits. Like me, he feels that this is very disrespectful. Please take more care when spelling names. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH 1/2] drm/etnaviv: take etnaviv_gem_obj in etnaviv_gem_mmap_obj
On Wed, Apr 27, 2016 at 02:39:20PM +0200, Lucas Stach wrote: > This function will be changed to be called indirectly and this > prototype change brings it in line with all the other indirect > object calls. Christian prefers passing around struct drm_gem_object rather than the etnaviv_gem_object. I'm much more in favour of passing the appropriate data type like the patch below. Please sort it out with Christian. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH] drm/etnaviv: remove BUG_ON in MMU unmap path
On Wed, Apr 27, 2016 at 02:38:18PM +0200, Lucas Stach wrote: > If the MMU map fails caused by an unaligned SG entry, the unmap path > is called to undo all already setup SG mappings. When encountering the > unaligned SG the unmap path hangs the kernel with a BUG(), while the > error is recoverable by just failing the submit that references the > faulty object. I'm very tempted to NAK this, because I introduced it with good reason: we should never see anything except a page-aligned number of bytes here. Are you seeing this trigger? -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[RFC v2 5/8] drm/fence: add in-fences support
2016-04-28 Ville Syrjälä : > On Thu, Apr 28, 2016 at 07:43:16PM +0200, Daniel Vetter wrote: > > On Thu, Apr 28, 2016 at 6:56 PM, Ville Syrjälä > > wrote: > > >> - better for tracing, can identify the buffer/fence promptly > > > > > > Can fences be reused somehow while still attached to a plane, or ever? > > > That might cause some oddness if you, say, leave a fence attached to one > > > plane and then do a modeset on another crtc perhaps which needs to turn > > > the first crtc off+on to reconfigure something. > > > > Fences auto-disappear of course and don't stick around when you > > duplicate the drm_plane_state again. I still don't really get the real > > concerns though ... > > Properties that magically change values shouldn't exist IMO. I guess if > you could have write-only properties or something it migth be sensible? We can just not return FENCE_FD on get_props, that would make it write-only. Gustavo
[PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
Hi Vineet, On Thu, 2016-04-28 at 19:26 +0530, Vineet Gupta wrote: > On Thursday 28 April 2016 07:16 PM, Alexey Brodkin wrote: > > > > > > > > > > > > > Note that the IOC start alignment needs to follow > > > > max(4k, size). What will be maximum size of frame buffer - 16M always ! > > What do you mean by that? > For HS38, we intend to bypass the frame buffer traffic from IOC port. So the > frame > buffer start needs to be inside the IOC aperture base address. That value > can't be > arbitrary - it is atleast 4K aligned value and further also needs to be > aligned to > the size of aperture. So if the size is 16M it needs to be 16M aligned etc... The point is we want to put frame buffer memory OUTSIDE IOC aperture. So we allocate FB memory in the very end of DDR which is far away from IOC. And in that case IOC alignment issues are out of the question here. -Alexey
[PATCH 16/35] drm/etnaviv: Use lockless gem BO free callback
On Tue, Apr 26, 2016 at 07:29:49PM +0200, Daniel Vetter wrote: > No dev->struct_mutex anywhere to be seen. > > Cc: Christian Gmeiner > Cc: Russell King Acked-by: Russell King Thanks Daniel. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH 11/35] drm/armada: Use lockless gem BO free callback
On Tue, Apr 26, 2016 at 07:29:44PM +0200, Daniel Vetter wrote: > No dev->struct_mutex anywhere to be seen. > > Cc: Russell King Acked-by: Russell King Thanks Daniel. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH v4 2/2] drm: sti: Add ASoC generic hdmi codec support.
Add linux-fbdev diffusion list in loop for patch-set review.
On 04/21/2016 05:29 PM, Arnaud POULIQUEN wrote:
> Add the interface needed by audio hdmi-codec driver.
>
> Signed-off-by: Arnaud Pouliquen
> Acked-by: Benjamin Gaignard
> Acked-by: Vincent ABRIOU
> ---
> drivers/gpu/drm/sti/Kconfig| 1 +
> drivers/gpu/drm/sti/sti_hdmi.c | 248
> ++---
> drivers/gpu/drm/sti/sti_hdmi.h | 13 +++
> 3 files changed, 245 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> index 5ad43a1..494ab25 100644
> --- a/drivers/gpu/drm/sti/Kconfig
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -7,5 +7,6 @@ config DRM_STI
> select DRM_KMS_CMA_HELPER
> select DRM_PANEL
> select FW_LOADER
> + select SND_SOC_HDMI_CODEC if SND_SOC
> help
> Choose this option to enable DRM on STM stiH41x chipset
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index 6ef0715..3a8bd47 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -18,6 +18,8 @@
> #include
> #include
>
> +#include
> +
> #include "sti_hdmi.h"
> #include "sti_hdmi_tx3g4c28phy.h"
> #include "sti_hdmi_tx3g0c55phy.h"
> @@ -35,6 +37,8 @@
> #define HDMI_DFLT_CHL0_DAT 0x0110
> #define HDMI_DFLT_CHL1_DAT 0x0114
> #define HDMI_DFLT_CHL2_DAT 0x0118
> +#define HDMI_AUDIO_CFG 0x0200
> +#define HDMI_SPDIF_FIFO_STATUS 0x0204
> #define HDMI_SW_DI_1_HEAD_WORD 0x0210
> #define HDMI_SW_DI_1_PKT_WORD0 0x0214
> #define HDMI_SW_DI_1_PKT_WORD1 0x0218
> @@ -44,6 +48,9 @@
> #define HDMI_SW_DI_1_PKT_WORD5 0x0228
> #define HDMI_SW_DI_1_PKT_WORD6 0x022C
> #define HDMI_SW_DI_CFG 0x0230
> +#define HDMI_SAMPLE_FLAT_MASK 0x0244
> +#define HDMI_AUDN 0x0400
> +#define HDMI_AUD_CTS0x0404
> #define HDMI_SW_DI_2_HEAD_WORD 0x0600
> #define HDMI_SW_DI_2_PKT_WORD0 0x0604
> #define HDMI_SW_DI_2_PKT_WORD1 0x0608
> @@ -103,6 +110,7 @@
> #define HDMI_INT_DLL_LCKBIT(5)
> #define HDMI_INT_NEW_FRAME BIT(6)
> #define HDMI_INT_GENCTRL_PKTBIT(7)
> +#define HDMI_INT_AUDIO_FIFO_XRUNBIT(8)
> #define HDMI_INT_SINK_TERM_PRESENT BIT(11)
>
> #define HDMI_DEFAULT_INT (HDMI_INT_SINK_TERM_PRESENT \
> @@ -111,6 +119,7 @@
> | HDMI_INT_GLOBAL)
>
> #define HDMI_WORKING_INT (HDMI_INT_SINK_TERM_PRESENT \
> + | HDMI_INT_AUDIO_FIFO_XRUN \
> | HDMI_INT_GENCTRL_PKT \
> | HDMI_INT_NEW_FRAME \
> | HDMI_INT_DLL_LCK \
> @@ -121,6 +130,27 @@
>
> #define HDMI_STA_SW_RST BIT(1)
>
> +#define HDMI_AUD_CFG_8CH BIT(0)
> +#define HDMI_AUD_CFG_SPDIF_DIV_2 BIT(1)
> +#define HDMI_AUD_CFG_SPDIF_DIV_3 BIT(2)
> +#define HDMI_AUD_CFG_SPDIF_CLK_DIV_4 (BIT(1) | BIT(2))
> +#define HDMI_AUD_CFG_CTS_CLK_256FS BIT(12)
> +#define HDMI_AUD_CFG_DTS_INVALID BIT(16)
> +#define HDMI_AUD_CFG_ONE_BIT_INVALID (BIT(18) | BIT(19) | BIT(20) | BIT(21))
> +#define HDMI_AUD_CFG_CH12_VALID BIT(28)
> +#define HDMI_AUD_CFG_CH34_VALID BIT(29)
> +#define HDMI_AUD_CFG_CH56_VALID BIT(30)
> +#define HDMI_AUD_CFG_CH78_VALID BIT(31)
> +
> +/* sample flat mask */
> +#define HDMI_SAMPLE_FLAT_NO 0
> +#define HDMI_SAMPLE_FLAT_SP0 BIT(0)
> +#define HDMI_SAMPLE_FLAT_SP1 BIT(1)
> +#define HDMI_SAMPLE_FLAT_SP2 BIT(2)
> +#define HDMI_SAMPLE_FLAT_SP3 BIT(3)
> +#define HDMI_SAMPLE_FLAT_ALL (HDMI_SAMPLE_FLAT_SP0 | HDMI_SAMPLE_FLAT_SP1 |\
> + HDMI_SAMPLE_FLAT_SP2 | HDMI_SAMPLE_FLAT_SP3)
> +
> #define HDMI_INFOFRAME_HEADER_TYPE(x)(((x) & 0xff) << 0)
> #define HDMI_INFOFRAME_HEADER_VERSION(x) (((x) & 0xff) << 8)
> #define HDMI_INFOFRAME_HEADER_LEN(x) (((x) & 0x0f) << 16)
> @@ -171,6 +201,10 @@ static irqreturn_t hdmi_irq_thread(int irq, void *arg)
> wake_up_interruptible(&hdmi->wait_event);
> }
>
> + /* Audio FIFO underrun IRQ */
> + if (hdmi->irq_status & HDMI_INT_AUDIO_FIFO_XRUN)
> + DRM_INFO("Warning: audio FIFO underrun occurs!");
> +
> return IRQ_HANDLED;
> }
>
> @@ -441,26 +475,29 @@ static int hdmi_avi_infoframe_config(struct sti_hdmi
> *hdmi)
> */
> static int hdmi_audio_infoframe_config(struct sti_hdmi *hdmi)
> {
> - struct hdmi_audio_infoframe infofame;
> + struct hdmi_audio_params *audio = &hdmi->audio;
> u8 buffer[HDMI_INFOFRAME_SIZE(AUDIO)];
> - int ret;
> -
> - ret = hdmi_audio_infoframe_init(&infofame);
> - if (ret < 0) {
> - DRM_ERROR("failed to setup audio infoframe: %d\n", ret);
> - return ret;
> - }
> -
> - infofame.channels = 2;
> -
> - ret = hdmi_audio_infoframe_pack(&infofam
[PATCH v4 1/2] video: hdmi: add helper functions for N and CTS
Add linux-fbdev diffusion list in loop for patch-set review.
On 04/21/2016 05:29 PM, Arnaud POULIQUEN wrote:
> Add helper functions to compute HDMI CTS and N parameters.
> Implementation is based on HDMI 1.4b specification.
>
> Signed-off-by: Arnaud Pouliquen
> Acked-by: Benjamin Gaignard
> Acked-by: Vincent ABRIOU
> ---
> drivers/video/hdmi.c | 208
> +++
> include/linux/hdmi.h | 24 ++
> 2 files changed, 232 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 1626892..5d124ef 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -1242,3 +1242,211 @@ int hdmi_infoframe_unpack(union hdmi_infoframe
> *frame, void *buffer)
> return ret;
> }
> EXPORT_SYMBOL(hdmi_infoframe_unpack);
> +
> +/*
> + * audio clock regeneration (acr) parameters
> + * N and CTS computation are based on HDMI specification 1.4b
> + */
> +enum hdmi_audio_rate {
> + HDMI_AUDIO_N_CTS_32KHZ,
> + HDMI_AUDIO_N_CTS_44_1KHZ,
> + HDMI_AUDIO_N_CTS_48KHZ,
> +};
> +
> +struct hdmi_audio_acr {
> + unsigned int tmds_clk;
> + struct hdmi_audio_n_cts n_cts;
> +};
> +
> +static const struct hdmi_audio_acr hdmi_audio_standard_acr[3][13] = {
> + [HDMI_AUDIO_N_CTS_32KHZ] = {
> + /* N and CTS values for 32 kHz rate*/
> + { 25174825, { 4576, 28125, 0 } }, /* 25.20/1.001 MHz */
> + { 2520, { 4096, 25200, 0 } }, /* 25.20MHz */
> + { 2700, { 4096, 27000, 0 } }, /* 27.00MHz */
> + { 27027000, { 4096, 27027, 0 } }, /* 27.00*1.001 MHz */
> + { 5400, { 4096, 54000, 0 } }, /* 54.00MHz */
> + { 54054000, { 4096, 54054, 0 } }, /* 54.00*1.001 MHz */
> + { 74175824, { 11648, 210937, 50 } }, /* 74.25/1.001 MHz */
> + { 7425, { 4096, 74250, 0 } }, /* 74.25MHz */
> + { 148351648, { 11648, 421875, 0 } }, /* 148.50/1.001 MHz */
> + { 14850, { 4096, 148500, 0 } }, /* 148.50 MHz */
> + { 296703296, { 5824, 421875, 0 } }, /* 297/1.001 MHz
> (truncated)*/
> + { 296703297, { 5824, 421875, 0 } }, /* 297/1.001 MHz
> (rounded)*/
> + { 29700, { 3072, 222750, 0 } }, /* 297 MHz */
> + },
> + [HDMI_AUDIO_N_CTS_44_1KHZ] = {
> + /* N and CTS values for 44.1 kHz, 88.2 kHz and 176.4 kHz rates*/
> + { 25174825, { 7007, 31250, 0 } }, /* 25.20/1.001 MHz */
> + { 2520, { 6272, 28000, 0 } }, /* 25.20MHz */
> + { 2700, { 6272, 3, 0 } }, /* 27.00MHz */
> + { 27027000, { 6272, 30030, 0 } }, /* 27.00*1.001 MHz */
> + { 5400, { 6272, 6, 0 } }, /* 54.00MHz */
> + { 54054000, { 6272, 60060, 0 } }, /* 54.00*1.001 MHz */
> + { 74175824, { 17836, 234375, 0 } }, /* 74.25/1.001 MHz */
> + { 7425, { 6272, 82500, 0 } }, /* 74.25MHz */
> + { 148351648, { 8918, 234375, 0 } }, /* 148.50/1.001 MHz */
> + { 14850, { 6272, 165000, 0 } }, /* 148.50 MHz */
> + { 296703296, { 4459, 234375, 0 } }, /* 297/1.001 MHz
> (truncated) */
> + { 296703297, { 4459, 234375, 0 } }, /* 297/1.001 MHz (rounded)
> */
> + { 29700, { 4704, 247500, 0 } }, /* 297 MHz */
> + },
> + [HDMI_AUDIO_N_CTS_48KHZ] = {
> + /* N and CTS values for 48 kHz, 96 kHz and 192 kHz rates*/
> + { 25174825, { 6864, 28125, 0 } }, /* 25.20/1.001 MHz */
> + { 2520, { 6144, 25200, 0 } }, /* 25.20MHz */
> + { 2700, { 6144, 27000, 0 } }, /* 27.00MHz */
> + { 27027000, { 6144, 27027, 0 } }, /* 27.00*1.001 MHz */
> + { 5400, { 6144, 54000, 0 } }, /* 54.00MHz */
> + { 54054000, { 6144, 54054, 0 } }, /* 54.00*1.001 MHz */
> + { 74175824, { 11648, 140625, 0 } }, /* 74.25/1.001 MHz */
> + { 7425, { 6144, 74250, 0 } }, /* 74.25MHz */
> + { 148351648, { 5824, 140625, 0 } }, /* 148.50/1.001 MHz */
> + { 14850, { 6144, 148500, 0 } }, /* 148.50 MHz */
> + { 296703296, { 5824, 281250, 0 } }, /* 297/1.001 MHz
> (truncated) */
> + { 296703297, { 5824, 281250, 0 } }, /* 297/1.001 MHz (rounded)
> */
> + { 29700, { 5120, 247500, 0 } }, /* 297 MHz */
> + }
> +};
> +
> +/**
> + * hdmi_audio_get_coherent_n_cts() - compute N and CTS parameters for
> coherent
> + * clocks. Coherent clock means that audio and TMDS clocks have the same
> + * source (no drifts between clocks).
> + *
> + * @audio_fs: audio frame clock frequency in Hz
> + * @tmds_clk: HDMI TMDS clock frequency in Hz
> + * @n_cts: N and CTS parameter returned
[PATCH v4 0/2] sti: add audio interface to the hdmi driver
Add linux-fbdev diffusion list in loop for patch-set review.
On 04/21/2016 05:29 PM, Arnaud POULIQUEN wrote:
> This patchset implements audio interface in HDMI drm driver. Implementation
> is based on
> ASoC generic hdmi codec driver( https://patchwork.kernel.org/patch/8713141/).
> It also proposes helper functions to compute N and CTS parameters
> according to HDMI 1.4b specification.
>
> V4:
> fixes for "video: hdmi: add helper functions for N and CTS"
> - typo error and additional comments
> - cts_1_ratio computation
> - warning reported by kbuild test robot
> - add rounded value for 297/1.001 MHz
>
> V3:
> - video: hdmi: add helper function for N and CTS
> Also used on Mediatek platform
> (https://patchwork.kernel.org/patch/8887341)
> delta vs V2:
> - typo fixes
> - if/else code optimisation
> - drm: sti: Add ASoC generic hdmi codec support.
> - typo fixes
> - add audio registers in debugfs information
>
> V2: RFC
> https://patchwork.kernel.org/patch/8091531/("video: hdmi: add helper function
> for N and CTS")
> https://patchwork.kernel.org/patch/8091561/("ASoC: hdmi-codec: Add hdmi-codec
> for external HDMI-encoders")
> - patch: video: hdmi: add helper function for N and CTS
> Fixes based on Russel King remarks
> - Duplicate function to have a separte treatment for coherent and
>non-coherent clocks
> - Add ratio field for alternate CTS value
> - Clock frequency in Hz for TMDS and audio clocks
> - Add information concerning clocks and CTS calculation.
>
> V1:
> This RFC is the implementation of audio HDMI on sti platform based on generic
> hdmi-codec driver:
> https://patchwork.kernel.org/patch/7215271/ ("ASoC: hdmi-codec: Add
> hdmi-codec for external HDMI-encoders")
> https://patchwork.kernel.org/patch/8062611/ ("video: hdmi: add helper
> function for N and CTS")
> Arnaud Pouliquen (2):
> video: hdmi: add helper functions for N and CTS
> drm: sti: Add ASoC generic hdmi codec support.
>
> drivers/gpu/drm/sti/Kconfig| 1 +
> drivers/gpu/drm/sti/sti_hdmi.c | 248
> ++---
> drivers/gpu/drm/sti/sti_hdmi.h | 13 +++
> drivers/video/hdmi.c | 208 ++
> include/linux/hdmi.h | 24
> 5 files changed, 477 insertions(+), 17 deletions(-)
>
[PATCH] drm: fix pixel size of NV12 / NV16 pixel formats
On Thu, Apr 28, 2016 at 10:40:39AM +0200, Fabien Dessenne wrote: > With NV12, NV21, NV16 and NV61 formats, the size of one pixel from the > UV plane (plane #1) is one byte. > > Indeed, these pixel formats use 4:2:x chroma subsampling: the chroma > pixels are sampled at half the luma: for 2 pixels, there are 1 Cb + > 1 Cr = 2 bytes. You just said it, it's 2 bytes. NAK > So for plane #1, the correct size is actually 1 byte per pixel. > > Signed-off-by: Fabien Dessenne > --- > drivers/gpu/drm/drm_crtc.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 3313f7e..572c6fa 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -5618,10 +5618,6 @@ int drm_format_plane_cpp(uint32_t format, int plane) > case DRM_FORMAT_UYVY: > case DRM_FORMAT_VYUY: > return 2; > - case DRM_FORMAT_NV12: > - case DRM_FORMAT_NV21: > - case DRM_FORMAT_NV16: > - case DRM_FORMAT_NV61: > case DRM_FORMAT_NV24: > case DRM_FORMAT_NV42: > return plane ? 2 : 1; > @@ -5635,6 +5631,10 @@ int drm_format_plane_cpp(uint32_t format, int plane) > case DRM_FORMAT_YVU422: > case DRM_FORMAT_YUV444: > case DRM_FORMAT_YVU444: > + case DRM_FORMAT_NV12: > + case DRM_FORMAT_NV21: > + case DRM_FORMAT_NV16: > + case DRM_FORMAT_NV61: > return 1; > default: > drm_fb_get_bpp_depth(format, &depth, &bpp); > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC
[PATCH] drm/msm: Move call to PTR_ERR_OR_ZERO after reassignment
On Wed, Apr 27, 2016 at 04:51:37PM +0530, Vaishali Thakkar wrote:
> Here, a location is reset to NULL before being passed to PTR_ERR.
> So, PTR_ERR should be called before its argument is reassigned
> to NULL. Further to simplify things use PTR_ERR_OR_ZERO instead
> of PTR_ERR and IS_ERR.
>
> Problem found using Coccinelle.
>
> Signed-off-by: Vaishali Thakkar
> ---
> drivers/gpu/drm/msm/edp/edp_ctrl.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
> b/drivers/gpu/drm/msm/edp/edp_ctrl.c
> index 81200e9..7816541 100644
> --- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
> +++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
> @@ -302,21 +302,23 @@ static void edp_clk_disable(struct edp_ctrl *ctrl, u32
> clk_mask)
> static int edp_regulator_init(struct edp_ctrl *ctrl)
> {
> struct device *dev = &ctrl->pdev->dev;
> + int ret;
>
> DBG("");
> ctrl->vdda_vreg = devm_regulator_get(dev, "vdda");
> - if (IS_ERR(ctrl->vdda_vreg)) {
> + ret = PTR_ERR_OR_ZERO(ctrl->vdda_vreg);
> + if (ret) {
> pr_err("%s: Could not get vdda reg, ret = %ld\n", __func__,
> - PTR_ERR(ctrl->vdda_vreg));
> + ret);
> ctrl->vdda_vreg = NULL;
> - return PTR_ERR(ctrl->vdda_vreg);
> + return ret;
> }
> ctrl->lvl_vreg = devm_regulator_get(dev, "lvl-vdd");
> - if (IS_ERR(ctrl->lvl_vreg)) {
> - pr_err("Could not get lvl-vdd reg, %ld",
> - PTR_ERR(ctrl->lvl_vreg));
> + ret = PTR_ERR_OR_ZERO(ctrl->lvl_vreg);
> + if (ret) {
While you're rewriting them, it might be worth making these two pr_err()
print the same format, e.g.:
pr_err("%s: Could not get lvl-vdd reg, ret = %ld\n", __func__, ret);
> + pr_err("Could not get lvl-vdd reg, %ld", ret);
> ctrl->lvl_vreg = NULL;
> - return PTR_ERR(ctrl->lvl_vreg);
> + return ret;
> }
>
> return 0;
> --
> 2.1.4
Reviewed-by: Eric Engestrom
[PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
Hi Vineet,
On Thu, 2016-04-28 at 09:56 +0530, Vineet Gupta wrote:
[snip]
> >
> > diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> > index 420dcfd..ae6162d 100644
> > --- a/arch/arc/boot/dts/axc001.dtsi
> > +++ b/arch/arc/boot/dts/axc001.dtsi
> > @@ -95,6 +95,24 @@
> > Â #size-cells = <1>;
> > Â ranges = <0x 0x8000 0x4000>;
> > Â device_type = "memory";
> > - reg = <0x8000 0x2000>; /* 512MiB */
> > + reg = <0x8000 0x1f00>; /* 512 - 16 MiB */
> Is 16MB fixed size or is this a function of display resolution / density etc.
Indeed this value depends on screen resolution and bpp and double-
or even tripple-buffering (once this becomes supported in the driver).
So as of now the corner case would be 1920x1080, 16 bits per pixel
which gives ~4Mb. Now if we add support of triple-buffering we'll
need ~12Mb so I booked a little bit more - 16Mb.
But now I recalled that we also support r8g8b8 mode and in this case
3 bytes are used for color encoding, which effectively gives ~6Mb for
1 FullHD frame. And for tripple-buffering we'll need > 18Mb, so probably
we'll need to go for 24 or even 32 Mb.
[snip]
> > +
> > + reserved-memory {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > + /*
> > + Â * Move frame buffer out of IOC aperture (0x8z-0xAz).
> > + Â */
> > + frame_buffer: frame_buffer at bf00 {
> > + compatible = "shared-dma-pool";
> > + reg = <0xbf00 0x100>;
> Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
> currently only uses 512M. Once we increase that, this will need fixing too.
> Better
> to make this as far possible.
Makes sense. Will move it to the very end of 1Gb.
> Note that the IOC start alignment needs to follow
> max(4k, size). What will be maximum size of frame buffer - 16M always !
What do you mean by that?
-Alexey
[Intel-gfx] [PATCH] drm/i915: Fix enc_to_dig_port() for MST encoders
On Thu, Apr 28, 2016 at 09:17:00AM +0300, Jani Nikula wrote:
> On Wed, 27 Apr 2016, Lyude wrote:
> > For MST encoders, the encoder struct is stored in the intel_dp_mst
> > struct, not a intel_digital_port struct.
> >
> > This fixes issues with hotplugging MST displays that support MST audio,
> > where hotplugging had a surprisingly good chance of accidentally
> > overwriting other parts of the kernel leading to seemingly unrelated
> > backtraces in sysfs, ext4, etc.
> >
> > Cc: stable at vger.kernel.org
> > Signed-off-by: Lyude
>
> Ugh. Just ugh.
>
> At a glance, it's probably this one that starts calling
> intel_audio_codec_enable() and intel_audio_codec_disable() on DP MST:
>
> commit 3d52ccf52f2c51f613e42e65be0f06e4e6788093
> Author: Libin Yang
> Date: Wed Dec 2 14:09:44 2015 +0800
>
> drm/i915: start adding dp mst audio
>
> which has been there since v4.5. Would it be feasible for you to revert
> the commit or change it so that it stops calling the audio codec
> enable/disable, to verify this is the culprit? So we could add a proper
> Fixes: line too.
I don't particularly like making enc_to_dig_port() work on MST encoders
because it'll likely result in the wrong thing anyway. I already asked
before how MST audio port handling is supposed to work, but never got
any answer. Right now, if you just use the ->primary dig_port in the
audio paths, there's no way audio can work correctly with MST, at least
if you enable multiple streams on the same port.
So what I would do is just revert the audio calls from the MST paths and
go back to the drawing board.
>
> The non-MST aware enc_to_dig_port() calls on platforms that might have
> MST were added in:
>
> commit 51e1d83cab9988716ae68801a721f4df0aaa374b
> Author: David Henningsson
> Date: Wed Aug 19 10:48:56 2015 +0200
>
> drm/i915: Call audio pin/ELD notify function
>
> and:
>
> commit 7e8275c2f2bbb384e18af37066b8b2f32b7d092f
> Author: Libin Yang
> Date: Fri Sep 25 09:36:12 2015 +0800
>
> drm/i915: set proper N/CTS in modeset
>
> but I don't think the codec enable/disable were called on MST at that
> time.
>
> Some of the problem was probably seen by Takashi in
>
> commit 0bdf5a05647a66dcc6394986e061daeac9b1cf96
> Author: Takashi Iwai
> Date: Mon Nov 30 18:19:39 2015 +0100
>
> drm/i915: Add reverse mapping between port and intel_encoder
>
> which has a comment /* intel_encoder might be NULL for DP MST */. Maybe
> that needs to be updated to DTRT too.
>
>
> Lyude, thanks for your efforts in DP MST area. Much appreciated.
>
>
> BR,
> Jani.
>
>
>
> > ---
> > drivers/gpu/drm/i915/intel_drv.h | 17 +++--
> > 1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 4c027d6..81f2212 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -918,18 +918,23 @@ intel_attached_encoder(struct drm_connector
> > *connector)
> > return to_intel_connector(connector)->encoder;
> > }
> >
> > -static inline struct intel_digital_port *
> > -enc_to_dig_port(struct drm_encoder *encoder)
> > -{
> > - return container_of(encoder, struct intel_digital_port, base.base);
> > -}
> > -
> > static inline struct intel_dp_mst_encoder *
> > enc_to_mst(struct drm_encoder *encoder)
> > {
> > return container_of(encoder, struct intel_dp_mst_encoder, base.base);
> > }
> >
> > +static inline struct intel_digital_port *
> > +enc_to_dig_port(struct drm_encoder *encoder)
> > +{
> > + if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST)
> > + return enc_to_mst(encoder)->primary;
> > + else {
> > + return container_of(encoder, struct intel_digital_port,
> > + base.base);
> > + }
> > +}
> > +
> > static inline struct intel_dp *enc_to_intel_dp(struct drm_encoder *encoder)
> > {
> > return &enc_to_dig_port(encoder)->dp;
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[git pull] vmwgfx-fixes
Hi Dave, The following changes since commit 928815245cbdaa611873424759d5e7a7293dd18b: Merge tag 'drm-intel-fixes-2016-04-07' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2016-04-11 13:30:05 +1000) are available in the git repository at: git://people.freedesktop.org/~syeh/repos_linux drm-vmwgfx-fixes for you to fetch changes up to 7851496a32319237456919575e5f4ba62f74cc7d: drm/vmwgfx: Fix order of operation (2016-04-28 11:07:30 -0700) Charmaine Lee (2): drm/vmwgfx: Enable SVGA_3D_CMD_DX_SET_PREDICATION drm/vmwgfx: use vmw_cmd_dx_cid_check for query commands. Sinclair Yeh (1): drm/vmwgfx: Fix order of operation drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 6 +++--- 2 files changed, 8 insertions(+), 8 deletions(-)
[RFC v2 8/8] drm/fence: add out-fences support
2016-04-26 Daniel Vetter :
> On Mon, Apr 25, 2016 at 07:33:28PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Support DRM out-fences creating a sync_file with a fence for each crtc
> > update with the DRM_MODE_ATOMIC_OUT_FENCE flag.
> >
> > We then send an struct drm_out_fences array with the out-fences fds back in
> > the drm_atomic_ioctl() as an out arg in the out_fences_ptr field.
> >
> > struct drm_out_fences {
> > __u32 crtc_id;
> > __u32 fd;
> > };
> >
> > v2: Comment by Rob Clark:
> > - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
> >
> > Comment by Daniel Vetter:
> > - Add clean up code for out_fences
> >
> > Signed-off-by: Gustavo Padovan
> > ---
> > drivers/gpu/drm/drm_atomic.c | 163
> > +--
> > include/drm/drm_crtc.h | 10 +++
> > include/uapi/drm/drm_mode.h | 11 ++-
> > 3 files changed, 179 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 5f9d434..06c6007 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1566,6 +1566,133 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
> > }
> > EXPORT_SYMBOL(drm_atomic_clean_old_fb);
> >
> > +static struct drm_out_fence_state *get_out_fence(struct drm_device *dev,
> > +struct drm_atomic_state *state,
> > +uint32_t __user
> > *out_fences_ptr,
> > +uint64_t count_out_fences,
> > +uint64_t user_data)
> > +{
> > + struct drm_crtc *crtc;
> > + struct drm_crtc_state *crtc_state;
> > + struct drm_out_fences *out_fences;
> > + struct drm_out_fence_state *fence_state;
> > + int num_fences = 0;
> > + int i, ret;
> > +
> > + if (count_out_fences > dev->mode_config.num_crtc)
> > + return ERR_PTR(-EINVAL);
> > +
> > + out_fences = kcalloc(count_out_fences, sizeof(*out_fences),
> > +GFP_KERNEL);
> > + if (!out_fences)
> > + return ERR_PTR(-ENOMEM);
>
> A bit tricky, but the above kcalloc is the only thing that catches integer
> overflows in count_out_fences. Needs a comment imo since this could be a
> security exploit if we accidentally screw it up.
The check above makes sure that count_out_fences is not bigger than
num_crtc. Don't that fix this?
>
> Also needs a testcase imo.
>
> > +
> > + fence_state = kcalloc(count_out_fences, sizeof(*fence_state),
> > +GFP_KERNEL);
> > + if (!fence_state) {
> > + kfree(out_fences);
> > + return ERR_PTR(-ENOMEM);
> > + }
> > +
> > + for (i = 0 ; i < count_out_fences ; i++)
> > + fence_state[i].fd = -1;
> > +
> > + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > + struct drm_pending_vblank_event *e;
> > + struct fence *fence;
> > + char name[32];
> > +
> > + fence = kzalloc(sizeof(*fence), GFP_KERNEL);
> > + if (!fence) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + fence_init(fence, &drm_crtc_fence_ops, &crtc->fence_lock,
> > + crtc->fence_context, crtc->fence_seqno);
> > +
> > + snprintf(name, sizeof(name), "crtc-%d_%lu",
> > +drm_crtc_index(crtc), crtc->fence_seqno++);
>
> Hm ... fence_init_with_name? I'm kinda confused why we only name fences
> that are exported though, and why not all of them. Debugging fence
> deadlocks is real hard, so giving them all names might be a good idea.
>
> Anyway, seems like more room for a bit more sync_file/struct fence
> merging.
We just removed name from sync_file_create() so snprintf() is not even
necessary here anymore.
>
> > +
> > + fence_state[i].fd = get_unused_fd_flags(O_CLOEXEC);
> > + if (fence_state[i].fd < 0) {
> > + fence_put(fence);
> > + ret = fence_state[i].fd;
> > + goto out;
> > + }
> > +
> > + fence_state[i].sync_file = sync_file_create(name, fence);
> > + if(!fence_state[i].sync_file) {
> > + fence_put(fence);
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + if (crtc_state->event) {
> > + crtc_state->event->base.fence = fence;
> > + } else {
>
> This looks a bit funny - I'd change the create event logic to create an
> event either if we have the either drm event or out-fence flag set.
Ok.
>
> > + e = create_vblank_event(dev, NULL, fence, user_data);
> > + if (!e) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + crt
[PATCH] drm/amdgpu: use ERR_PTR() to return from amdgpu_mn_get
On Thu 28-04-16 11:33:48, Arnd Bergmann wrote:
> The newly added failure path in amdgpu_mn_get() use the
> wrong return type:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c: In function 'amdgpu_mn_get':
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:237:10: error: return makes pointer
> from integer without a cast
>
> This adds the necessary ERR_PTR() conversion.
>
> Signed-off-by: Arnd Bergmann
> Fixes: ad35eee9fb17 ("drm/amdgpu: make amdgpu_mn_get wait for mmap_sem
> killable")
This is in the mmotm tree so the sha is unstable.
Acked-by: Michal Hocko
Thanks for catching this.
Andrew, could you fold this into the original patch please?
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> index cf90686a50d1..32fa7b7913f7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> @@ -234,7 +234,7 @@ static struct amdgpu_mn *amdgpu_mn_get(struct
> amdgpu_device *adev)
> mutex_lock(&adev->mn_lock);
> if (down_write_killable(&mm->mmap_sem)) {
> mutex_unlock(&adev->mn_lock);
> - return -EINTR;
> + return ERR_PTR(-EINTR);
> }
>
> hash_for_each_possible(adev->mn_hash, rmn, node, (unsigned long)mm)
> --
> 2.7.0
--
Michal Hocko
SUSE Labs
linux-next: build failure after merge of the drm tree
Hi Dave,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_prepare_ddi_buffer':
drivers/gpu/drm/i915/intel_ddi.c:447:15: error: 'struct drm_i915_private' has
no member named 'edp_low_vswing'
if (dev_priv->edp_low_vswing) {
^
Caused by commit
06411f08b3f3 ("drm/i915: move edp low vswing config to vbt data")
interacting with commit
992e7a41f9fc ("drm/i915: Fix eDP low vswing for Broadwell")
from the drm-intel-fixes tree.
I applied the following merge fixup patch (which is suggested by the "v3:
Change dev_priv->edp_low_vswing to use dev_priv->vbt.edp.low_vswing"
comment in the drm-intel-fixes tree patch, but clearly could not be
done there).
From: Stephen Rothwell
Date: Thu, 28 Apr 2016 11:53:36 +1000
Subject: [PATCH] drm/i915: fix up for edp_low_vswing change
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 6080b5481984..e304857ba405 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -444,7 +444,7 @@ void intel_prepare_ddi_buffer(struct intel_encoder *encoder)
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
- if (dev_priv->edp_low_vswing) {
+ if (dev_priv->vbt.edp.low_vswing) {
ddi_translations_edp = bdw_ddi_translations_edp;
n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
} else {
--
2.7.0
--
Cheers,
Stephen Rothwell
[PATCH] drm/dp: Allow signals to interrupt drm_aux-dev reads/writes
On Wed, 27 Apr 2016, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> Let's be nice and interrupt the dpcd aux-dev reads/writes when there's
> a signal pending. Much nicer if the user can hit ^C instead of having to
> sit around waiting for the read/write to finish.
>
> time dd if=/dev/drm_dp_aux0 bs=$((1024*1024))
> ^C
>
> before:
> real 0m34.681s
> user 0m0.003s
> sys 0m6.880s
>
> after:
> real 0m0.222s
> user 0m0.006s
> sys 0m0.057s
>
> Cc: Rafael Antognolli
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_aux_dev.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c
> b/drivers/gpu/drm/drm_dp_aux_dev.c
> index f73b38b33a8e..3334baacf43d 100644
> --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> @@ -159,6 +159,12 @@ static ssize_t auxdev_read(struct file *file, char
> __user *buf, size_t count,
> uint8_t localbuf[DP_AUX_MAX_PAYLOAD_BYTES];
> ssize_t todo = min_t(size_t, bytes_pending, sizeof(localbuf));
>
> + if (signal_pending(current)) {
> + res = num_bytes_processed ?
> + num_bytes_processed : -ERESTARTSYS;
> + goto out;
> + }
> +
> res = drm_dp_dpcd_read(aux_dev->aux, *offset, localbuf, todo);
> if (res <= 0) {
> res = num_bytes_processed ? num_bytes_processed : res;
> @@ -202,6 +208,12 @@ static ssize_t auxdev_write(struct file *file, const
> char __user *buf,
> uint8_t localbuf[DP_AUX_MAX_PAYLOAD_BYTES];
> ssize_t todo = min_t(size_t, bytes_pending, sizeof(localbuf));
>
> + if (signal_pending(current)) {
> + res = num_bytes_processed ?
> + num_bytes_processed : -ERESTARTSYS;
> + goto out;
> + }
> +
> if (__copy_from_user(localbuf,
>buf + num_bytes_processed, todo)) {
> res = num_bytes_processed ?
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/dp: Allow signals to interrupt drm_aux-dev reads/writes
On Thu, Apr 28, 2016 at 11:49:12AM +0300, Jani Nikula wrote: > On Wed, 27 Apr 2016, ville.syrjala at linux.intel.com wrote: > > From: Ville Syrjälä > > > > Let's be nice and interrupt the dpcd aux-dev reads/writes when there's > > a signal pending. Much nicer if the user can hit ^C instead of having to > > sit around waiting for the read/write to finish. > > > > time dd if=/dev/drm_dp_aux0 bs=$((1024*1024)) > > ^C > > > > before: > > real 0m34.681s > > user 0m0.003s > > sys0m6.880s > > > > after: > > real 0m0.222s > > user 0m0.006s > > sys0m0.057s > > > > Cc: Rafael Antognolli > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Jani Nikula Applied to drm-misc, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[RFC v2 1/8] dma-buf/fence: add fence_collection fences
2016-04-26 Chris Wilson :
> On Mon, Apr 25, 2016 at 07:33:21PM -0300, Gustavo Padovan wrote:
> > +static const char *fence_collection_get_timeline_name(struct fence *fence)
> > +{
> > + return "no context";
>
> "unbound" to distinguish from fence contexts within a timeline?
>
> > +static bool fence_collection_enable_signaling(struct fence *fence)
> > +{
> > + struct fence_collection *collection = to_fence_collection(fence);
> > + int i;
> > +
> > + for (i = 0 ; i < collection->num_fences ; i++) {
> > + if (fence_add_callback(collection->fences[i].fence,
> > + &collection->fences[i].cb,
> > + collection_check_cb_func)) {
> > + atomic_dec(&collection->num_pending_fences);
> > + return false;
>
> Don't stop, we need to enable all the others!
>
> > + }
> > + }
> > +
> > + return !!atomic_read(&collection->num_pending_fences);
>
> Redundant !!
>
> > +}
> > +
> > +static bool fence_collection_signaled(struct fence *fence)
> > +{
> > + struct fence_collection *collection = to_fence_collection(fence);
> > +
> > + return (atomic_read(&collection->num_pending_fences) == 0);
>
> Redundant ()
>
> > +static signed long fence_collection_wait(struct fence *fence, bool intr,
> > +signed long timeout)
> > +{
>
> What advantage does this have over fence_default_wait? You enable
> signaling on all, then wait sequentially. The code looks redundant and
> could just use fence_default_wait instead.
None actually, I'll just replace it with fence_default_wait().
Gustavo
[GIT PULL v2] drm-hisilicon-next for 4.7
Hi Dave, V2 has fixed the module compilation error and warnings in this commit: 3d76c7e5bbdd drm/hisilicon: Add designware dsi encoder driver Please help to try and let me know if there is any problem. Thanks, -xinliang The following changes since commit 152ef5fa9e14e93e7efc43adad7dbcf35d7780f5: drm: Switch blobs to the new generic modeset obj refcounting (2016-04-27 09:58:05 +1000) are available in the git repository at: git at github.com:xin3liang/linux.git tags/drm-hisilicon-next-2016-04-28 for you to fetch changes up to 4f65fd49d7184bda4e3abddc04d5965109832b4f: MAINTAINERS: Add maintainer for hisilicon DRM driver (2016-04-28 11:06:54 +0800) drm-hisilicon-next for 4.7 Add new hisilicon kirin drm driver: - Add maintainer for hisilicon DRM driver - Add support for external bridge - Add designware dsi host driver - Add designware dsi encoder driver - Add cma fbdev and hotplug - Add vblank driver for ADE - Add plane driver for ADE - Add crtc driver for ADE - Add hisilicon kirin drm master driver - Add device tree binding for hi6220 display subsystem Xinliang Liu (10): drm/hisilicon: Add device tree binding for hi6220 display subsystem drm/hisilicon: Add hisilicon kirin drm master driver drm/hisilicon: Add crtc driver for ADE drm/hisilicon: Add plane driver for ADE drm/hisilicon: Add vblank driver for ADE drm/hisilicon: Add cma fbdev and hotplug drm/hisilicon: Add designware dsi encoder driver drm/hisilicon: Add designware dsi host driver drm/hisilicon: Add support for external bridge MAINTAINERS: Add maintainer for hisilicon DRM driver .../bindings/display/hisilicon/dw-dsi.txt | 72 ++ .../bindings/display/hisilicon/hisi-ade.txt| 64 ++ MAINTAINERS| 10 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/hisilicon/Kconfig |5 + drivers/gpu/drm/hisilicon/Makefile |5 + drivers/gpu/drm/hisilicon/kirin/Kconfig| 18 + drivers/gpu/drm/hisilicon/kirin/Makefile |6 + drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 857 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h | 103 ++ drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h| 230 + drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c| 1057 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c| 367 +++ drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h| 31 + 15 files changed, 2828 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt create mode 100644 drivers/gpu/drm/hisilicon/Kconfig create mode 100644 drivers/gpu/drm/hisilicon/Makefile create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
[Bug 117181] graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake
https://bugzilla.kernel.org/show_bug.cgi?id=117181 yves.dufournaud at gmail.com changed: What|Removed |Added Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC v2 5/8] drm/fence: add in-fences support
2016-04-27 Daniel Stone : > Hi, > > On 26 April 2016 at 21:48, Greg Hackmann wrote: > > On 04/26/2016 01:05 PM, Daniel Vetter wrote: > >> On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote: > >>> What are they doing that can't stuff the fences into an array > >>> instead of props? > >> > >> The hw composer interface is one in-fence per plane. That's really the > >> major reason why the kernel interface is built to match. And I really > >> don't think we should diverge just because we have a slight different > >> color preference ;-) > > > > The relationship between layers and fences is only fuzzy and indirect > > though. The relationship is really between the buffer you're displaying on > > that layer, and the fence representing the work done to render into that > > buffer. SurfaceFlinger just happens to bundle them together inside the same > > struct hwc_layer_1 as an API convenience. > > Right, and when using implicit fencing, this comes as a plane > property, by virtue of plane -> fb -> buffer -> fence. > > > Which is kind of splitting hairs as long as you have a 1-to-1 relationship > > between layers and DRM planes. But that's not always the case. > > Can you please elaborate? > > > A (per-CRTC?) array of fences would be more flexible. And even in the cases > > where you could make a 1-to-1 mapping between planes and fences, it's not > > that much more work for userspace to assemble those fences into an array > > anyway. > > As Ville says, I don't want to go down the path of scheduling CRTC > updates separately, because that breaks MST pretty badly. If you don't > want your updates to display atomically, then don't schedule them > atomically ... ? That's the only reason I can see for making fencing > per-CRTC, rather than just a pile of unassociated fences appended to > the request. Per-CRTC fences also forces userspace to merge fences > before submission when using multiple planes per CRTC, which is pretty > punitive. > > I think having it semantically attached to the plane is a little bit > nicer for tracing (why was this request delayed? -> a fence -> which > buffer was that fence for?) at a glance. Also the 'pile of appended > fences' model is a bit awkward for more generic userspace, which > creates a libdrm request and builds it (add a plane, try it out, wind > back) incrementally. Using properties makes that really easy, but > without properties, we'd have to add separate codepaths - and thus > separate ABI, which complicates distribution - to libdrm to account > for a separate plane array which shares a cursor with the properties. > So for that reason if none other, I'd really prefer not to go down > that route. I also agree to have it as FENCE_FD prop on the plane. Summarizing the arguments on this thread, they are: - implicit fences also needs one fence per plane/fb, so it will be good to match with that. - requires userspace to always merge fences - can use standard plane properties, making kernel and userspace life easier, an array brings more work to build the atomic request plus extra checkings on the kernel. - do not need to changes to drivers - better for tracing, can identify the buffer/fence promptly Gustavo
[PATCH] drm/amdgpu: use ERR_PTR() to return from amdgpu_mn_get
The newly added failure path in amdgpu_mn_get() use the
wrong return type:
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c: In function 'amdgpu_mn_get':
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:237:10: error: return makes pointer from
integer without a cast
This adds the necessary ERR_PTR() conversion.
Signed-off-by: Arnd Bergmann
Fixes: ad35eee9fb17 ("drm/amdgpu: make amdgpu_mn_get wait for mmap_sem
killable")
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
index cf90686a50d1..32fa7b7913f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -234,7 +234,7 @@ static struct amdgpu_mn *amdgpu_mn_get(struct amdgpu_device
*adev)
mutex_lock(&adev->mn_lock);
if (down_write_killable(&mm->mmap_sem)) {
mutex_unlock(&adev->mn_lock);
- return -EINTR;
+ return ERR_PTR(-EINTR);
}
hash_for_each_possible(adev->mn_hash, rmn, node, (unsigned long)mm)
--
2.7.0
[GIT PULL] drm-hisilicon-next-2016-04-18 for 4.7
Hi Dave, Have fixed the module compilation error and warnings in this commit: 3d76c7e5bbdd drm/hisilicon: Add designware dsi encoder driver Please help to pull the new tag drm-hisilicon-next-2016-04-28 and let me know if there is any problem. Thanks, -xinliang The following changes since commit 152ef5fa9e14e93e7efc43adad7dbcf35d7780f5: drm: Switch blobs to the new generic modeset obj refcounting (2016-04-27 09:58:05 +1000) are available in the git repository at: git at github.com:xin3liang/linux.git tags/drm-hisilicon-next-2016-04-28 for you to fetch changes up to 4f65fd49d7184bda4e3abddc04d5965109832b4f: MAINTAINERS: Add maintainer for hisilicon DRM driver (2016-04-28 11:06:54 +0800) drm-hisilicon-next for 4.7 Add new hisilicon kirin drm driver: - Add maintainer for hisilicon DRM driver - Add support for external bridge - Add designware dsi host driver - Add designware dsi encoder driver - Add cma fbdev and hotplug - Add vblank driver for ADE - Add plane driver for ADE - Add crtc driver for ADE - Add hisilicon kirin drm master driver - Add device tree binding for hi6220 display subsystem Xinliang Liu (10): drm/hisilicon: Add device tree binding for hi6220 display subsystem drm/hisilicon: Add hisilicon kirin drm master driver drm/hisilicon: Add crtc driver for ADE drm/hisilicon: Add plane driver for ADE drm/hisilicon: Add vblank driver for ADE drm/hisilicon: Add cma fbdev and hotplug drm/hisilicon: Add designware dsi encoder driver drm/hisilicon: Add designware dsi host driver drm/hisilicon: Add support for external bridge MAINTAINERS: Add maintainer for hisilicon DRM driver .../bindings/display/hisilicon/dw-dsi.txt | 72 ++ .../bindings/display/hisilicon/hisi-ade.txt| 64 ++ MAINTAINERS| 10 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/hisilicon/Kconfig |5 + drivers/gpu/drm/hisilicon/Makefile |5 + drivers/gpu/drm/hisilicon/kirin/Kconfig| 18 + drivers/gpu/drm/hisilicon/kirin/Makefile |6 + drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 857 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h | 103 ++ drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h| 230 + drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c| 1057 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c| 367 +++ drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h| 31 + 15 files changed, 2828 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt create mode 100644 drivers/gpu/drm/hisilicon/Kconfig create mode 100644 drivers/gpu/drm/hisilicon/Makefile create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h On 27 April 2016 at 07:43, Dave Airlie wrote: > On 19 April 2016 at 19:03, Xinliang Liu wrote: >> Hi Dave, >> >> This is the first pull request from drm-hisilicon and for 4.7. >> >> The patches add new hisilicon drm driver. >> >> The patches were reviewed here: >> http://www.spinics.net/lists/dri-devel/msg104437.html >> >> DT binding docs were acked by Rob Herring here: >> https://lists.freedesktop.org/archives/dri-devel/2016-March/102135.html >> >> Please kindly let me know if there is any problem. > > CC [M] drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.o > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c: > In function âade_initâ: > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c:169:134: > warning: left shift count >= width of type [-Wshift-count-overflow] > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c:170:134: > warning: left shift count >= width of type [-Wshift-count-overflow] > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c:171:134: > warning: left shift count >= width of type [-Wshift-count-overflow] > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c:172:134: > warning: left shift count >= width of type [-Wshift-count-overflow] > DTC drivers/gpu/drm/tilcdc/tilcdc_s
[PATCH 12/24] drm/omap: add extern C guard for the UAPI header
On 21/04/16 23:17, Emil Velikov wrote:
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Signed-off-by: Emil Velikov
> ---
> include/uapi/drm/omap_drm.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
> index 38a3bd8..407cb55 100644
> --- a/include/uapi/drm/omap_drm.h
> +++ b/include/uapi/drm/omap_drm.h
> @@ -22,6 +22,10 @@
>
> #include "drm.h"
>
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> /* Please note that modifications to all structs defined here are
> * subject to backwards-compatibility constraints.
> */
> @@ -114,4 +118,8 @@ struct drm_omap_gem_info {
> #define DRM_IOCTL_OMAP_GEM_CPU_FINI DRM_IOW (DRM_COMMAND_BASE +
> DRM_OMAP_GEM_CPU_FINI, struct drm_omap_gem_cpu_fini)
> #define DRM_IOCTL_OMAP_GEM_INFO DRM_IOWR(DRM_COMMAND_BASE +
> DRM_OMAP_GEM_INFO, struct drm_omap_gem_info)
>
> +#if defined(__cplusplus)
> +}
> +#endif
> +
> #endif /* __OMAP_DRM_H__ */
>
Acked-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/69e53def/attachment.sig>
linux-next: build failure after merge of the drm tree
On Thu, 28 Apr 2016, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_prepare_ddi_buffer':
> drivers/gpu/drm/i915/intel_ddi.c:447:15: error: 'struct drm_i915_private' has
> no member named 'edp_low_vswing'
>if (dev_priv->edp_low_vswing) {
>^
>
> Caused by commit
>
> 06411f08b3f3 ("drm/i915: move edp low vswing config to vbt data")
>
> interacting with commit
>
> 992e7a41f9fc ("drm/i915: Fix eDP low vswing for Broadwell")
>
> from the drm-intel-fixes tree.
>
> I applied the following merge fixup patch (which is suggested by the "v3:
> Change dev_priv->edp_low_vswing to use dev_priv->vbt.edp.low_vswing"
> comment in the drm-intel-fixes tree patch, but clearly could not be
> done there).
>
> From: Stephen Rothwell
> Date: Thu, 28 Apr 2016 11:53:36 +1000
> Subject: [PATCH] drm/i915: fix up for edp_low_vswing change
>
> Signed-off-by: Stephen Rothwell
FWIW,
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6080b5481984..e304857ba405 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -444,7 +444,7 @@ void intel_prepare_ddi_buffer(struct intel_encoder
> *encoder)
> ddi_translations_fdi = bdw_ddi_translations_fdi;
> ddi_translations_dp = bdw_ddi_translations_dp;
>
> - if (dev_priv->edp_low_vswing) {
> + if (dev_priv->vbt.edp.low_vswing) {
> ddi_translations_edp = bdw_ddi_translations_edp;
> n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> } else {
> --
> 2.7.0
--
Jani Nikula, Intel Open Source Technology Center
i915: screen flicker
On Wed, 27 Apr 2016, Mihai DonÈu wrote:
> On Wed, 27 Apr 2016 20:36:13 +0300 Mihai DonÈu wrote:
>> On Wed, 27 Apr 2016 08:28:20 -0700 Rodrigo Vivi wrote:
>> > Hi Mihai,
>> >
>> > What platform do you have? HSW or BDW?
>>
>> I have an i7, Haswell CPU.
>>
>> > If you don't know please provide lspci -nn
>>
>> I have attached the output of lspci, just in case. :-)
>>
>> > What happens if you boot with i915.enable_psr=2?
>>
>> I'll try now.
>
> The behaviour is worse now. The screen flickers every couple of seconds.
Another report, please move the discussion there:
https://bugs.freedesktop.org/show_bug.cgi?id=95176
Thanks,
Jani.
>
>> > In case it helps, could you please boot with default
>> > i915.enable_psr=-1 appying this patch to your kernel to know what your
>> > VBT recommends:
>> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
>> > b/drivers/gpu/drm/i915/intel_psr.c
>> > index c3abae4..68bc405 100644
>> > --- a/drivers/gpu/drm/i915/intel_psr.c
>> > +++ b/drivers/gpu/drm/i915/intel_psr.c
>> > @@ -798,6 +798,8 @@ void intel_psr_init(struct drm_device *dev)
>> > /* For new platforms let's respect VBT back again */
>> > dev_priv->psr.link_standby =
>> > dev_priv->vbt.psr.full_link;
>> >
>> > + DRM_ERROR("PSR: VBT recommends link_standby %d, using %d\n",
>> > dev_priv->vbt.psr.full_link, dev_priv->psr.link_standby);
>> > +
>> > /* Override link_standby x link_off defaults */
>> > if (i915.enable_psr == 2 && !dev_priv->psr.link_standby) {
>> > DRM_DEBUG_KMS("PSR: Forcing link standby\n");
>> >
>>
>> I applied your patch and booted with enable_psr=-1
>>
>> [0.763651] [drm:intel_psr_init] *ERROR* PSR: VBT recommends link_standby
>> 0, using 0
--
Jani Nikula, Intel Open Source Technology Center
[Intel-gfx] [PATCH] drm: Quiet down drm_mode_getresources
On Wed, Apr 27, 2016 at 12:11:47PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> The debug logging here can be very verbose in the kernel logs
> and provides no information which userspace doesn't have the
> access to already. Turn it off so kernel logs become more
> manageable.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
> Cc: dri-devel at lists.freedesktop.org
> Acked-by: Daniel Vetter
Also merged this one to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_crtc.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index ffb01d91ae32..9626a0cc050a 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1936,8 +1936,6 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> copied = 0;
> crtc_id = (uint32_t __user *)(unsigned
> long)card_res->crtc_id_ptr;
> drm_for_each_crtc(crtc, dev) {
> - DRM_DEBUG_KMS("[CRTC:%d:%s]\n",
> - crtc->base.id, crtc->name);
> if (put_user(crtc->base.id, crtc_id + copied)) {
> ret = -EFAULT;
> goto out;
> @@ -1952,8 +1950,6 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> copied = 0;
> encoder_id = (uint32_t __user *)(unsigned
> long)card_res->encoder_id_ptr;
> drm_for_each_encoder(encoder, dev) {
> - DRM_DEBUG_KMS("[ENCODER:%d:%s]\n", encoder->base.id,
> - encoder->name);
> if (put_user(encoder->base.id, encoder_id +
>copied)) {
> ret = -EFAULT;
> @@ -1969,9 +1965,6 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> copied = 0;
> connector_id = (uint32_t __user *)(unsigned
> long)card_res->connector_id_ptr;
> drm_for_each_connector(connector, dev) {
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> - connector->base.id,
> - connector->name);
> if (put_user(connector->base.id,
>connector_id + copied)) {
> ret = -EFAULT;
> @@ -1982,9 +1975,6 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> }
> card_res->count_connectors = connector_count;
>
> - DRM_DEBUG_KMS("CRTC[%d] CONNECTORS[%d] ENCODERS[%d]\n",
> card_res->count_crtcs,
> - card_res->count_connectors, card_res->count_encoders);
> -
> out:
> mutex_unlock(&dev->mode_config.mutex);
> return ret;
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[GIT PULL] drm: Allwinner sun4i support
Hi Dave, Please consider the following pull request to introduce the support for the Allwinner SoCs display engine. This is based on my latest patch set, adressing the minor reviews made during that latest round. Thanks, Maxime The following changes since commit 152ef5fa9e14e93e7efc43adad7dbcf35d7780f5: drm: Switch blobs to the new generic modeset obj refcounting (2016-04-27 09:58:05 +1000) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sun4i-drm-for-4.7 for you to fetch changes up to bf1139dfe797c0d6037dd689219a431516490544: MAINTAINERS: Add a maintainer for the Allwinner DRM driver (2016-04-28 10:30:05 +0200) Allwinner DRM driver for 4.7 This pull request introduces the sun4i driver, meant to be used on the older Allwinner SoCs (A10, A13, A20, A23, A31 and A33). It currently supports only the A13, which has one of the simplest video pipeline. Support for other video components and SoCs will be added eventually. It supports only a RGB or composite output. It doesn't do HDMI, VGA, LVDS or power management yet, but that will come in time as well. Maxime Ripard (8): drm: fb: Add seq_file definition drm: sun4i: Add DT bindings documentation drm: Add Allwinner A10 Display Engine support drm: sun4i: Add RGB output drm: sun4i: Add composite output drm: sun4i: tv: Add PAL output standard drm: sun4i: tv: Add NTSC output standard MAINTAINERS: Add a maintainer for the Allwinner DRM driver .../bindings/display/sunxi/sun4i-drm.txt | 258 MAINTAINERS| 7 + drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/sun4i/Kconfig | 14 + drivers/gpu/drm/sun4i/Makefile | 13 + drivers/gpu/drm/sun4i/sun4i_backend.c | 364 +++ drivers/gpu/drm/sun4i/sun4i_backend.h | 165 + drivers/gpu/drm/sun4i/sun4i_crtc.c | 120 drivers/gpu/drm/sun4i/sun4i_crtc.h | 30 + drivers/gpu/drm/sun4i/sun4i_dotclock.c | 160 + drivers/gpu/drm/sun4i/sun4i_dotclock.h | 21 + drivers/gpu/drm/sun4i/sun4i_drv.c | 358 +++ drivers/gpu/drm/sun4i/sun4i_drv.h | 30 + drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 54 ++ drivers/gpu/drm/sun4i/sun4i_framebuffer.h | 19 + drivers/gpu/drm/sun4i/sun4i_layer.c| 161 + drivers/gpu/drm/sun4i/sun4i_layer.h| 30 + drivers/gpu/drm/sun4i/sun4i_rgb.c | 250 drivers/gpu/drm/sun4i/sun4i_rgb.h | 18 + drivers/gpu/drm/sun4i/sun4i_tcon.c | 561 drivers/gpu/drm/sun4i/sun4i_tcon.h | 186 ++ drivers/gpu/drm/sun4i/sun4i_tv.c | 708 + include/drm/drm_fb_cma_helper.h| 2 + 24 files changed, 3533 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt create mode 100644 drivers/gpu/drm/sun4i/Kconfig create mode 100644 drivers/gpu/drm/sun4i/Makefile create mode 100644 drivers/gpu/drm/sun4i/sun4i_backend.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_backend.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_crtc.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_crtc.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_dotclock.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_dotclock.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_drv.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_drv.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_framebuffer.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_framebuffer.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_layer.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_layer.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_rgb.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_rgb.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_tcon.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_tcon.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_tv.c -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/2d553697/attachment.sig>
[PATCH 9/9] drm: Quiet down drm_mode_getconnector
On Wed, Apr 27, 2016 at 11:07:02AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Debug logging in this function does not provide any information
> apart that the userspace is calling an ioctl on the connector.
>
> There is not any info on the connector provided at all and
> since there are other ioctls userspace typically calls which
> do log useful things about the same connectors, remove this
> one to make things a little bit more readable when KMS debugging
> is turned on.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
> Cc: dri-devel at lists.freedesktop.org
Yeah this seems over the top debug noise. If we want this, we could easily
add a generic debugfs file, with a lot more info on top.
-Daniel
> ---
> drivers/gpu/drm/drm_crtc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 4e5b015a5e3a..ffb01d91ae32 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2143,8 +2143,6 @@ int drm_mode_getconnector(struct drm_device *dev, void
> *data,
>
> memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo));
>
> - DRM_DEBUG_KMS("[CONNECTOR:%d:?]\n", out_resp->connector_id);
> -
> mutex_lock(&dev->mode_config.mutex);
>
> connector = drm_connector_find(dev, out_resp->connector_id);
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 13/13] Documentation: add Sync File doc
From: Gustavo Padovan Add sync_file documentation on dma-buf-sync_file.txt Reviewed-by: Daniel Vetter --- Documentation/sync_file.txt | 69 + 1 file changed, 69 insertions(+) create mode 100644 Documentation/sync_file.txt diff --git a/Documentation/sync_file.txt b/Documentation/sync_file.txt new file mode 100644 index 000..eaf8297 --- /dev/null +++ b/Documentation/sync_file.txt @@ -0,0 +1,69 @@ + Sync File API Guide + ~~~ + + Gustavo Padovan + + +This document serves as a guide for device drivers writers on what the +sync_file API is, and how drivers can support it. Sync file is the carrier of +the fences(struct fence) that needs to synchronized between drivers or across +process boundaries. + +The sync_file API is meant to be used to send and receive fence information +to/from userspace. It enables userspace to do explicit fencing, where instead +of attaching a fence to the buffer a producer driver (such as a GPU or V4L +driver) sends the fence related to the buffer to userspace via a sync_file. + +The sync_file then can be sent to the consumer (DRM driver for example), that +will not use the buffer for anything before the fence(s) signals, i.e., the +driver that issued the fence is not using/processing the buffer anymore, so it +signals that the buffer is ready to use. And vice-versa for the consumer -> +producer part of the cycle. + +Sync files allows userspace awareness on buffer sharing synchronization between +drivers. + +Sync file was originally added in the Android kernel but current Linux Desktop +can benefit a lot from it. + +in-fences and out-fences + + +Sync files can go either to or from userspace. When a sync_file is sent from +the driver to userspace we call the fences it contains 'out-fences'. They are +related to a buffer that the driver is processing or is going to process, so +the driver an create out-fence to be able to notify, through fence_signal(), +when it has finished using (or processing) that buffer. Out-fences are fences +that the driver creates. + +On the other hand if the driver receives fence(s) through a sync_file from +userspace we call these fence(s) 'in-fences'. Receiveing in-fences means that +we need to wait for the fence(s) to signal before using any buffer related to +the in-fences. + +Creating Sync Files +--- + +When a driver needs to send an out-fence userspace it creates a sync_file. + +Interface: + struct sync_file *sync_file_create(struct fence *fence); + +The caller pass the out-fence and gets back the sync_file. That is just the +first step, next it needs to install an fd on sync_file->file. So it gets an +fd: + + fd = get_unused_fd_flags(O_CLOEXEC); + +and installs it on sync_file->file: + + fd_install(fd, sync_file->file); + +The sync_file fd now can be sent to userspace. + +If the creation process fail, or the sync_file needs to be released by any +other reason fput(sync_file->file) should be used. + +References: +[1] struct sync_file in include/linux/sync_file.h +[2] All interfaces mentioned above defined in include/linux/sync_file.h -- 2.5.5
[PATCH v2 12/13] Documentation: include sync_file into DocBook
From: Gustavo Padovan Add entry in device-drivers.tmpl for sync_file documentation. Signed-off-by: Gustavo Padovan Reviewed-by: Daniel Vetter --- Documentation/DocBook/device-drivers.tmpl | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 184f3c7..509a187 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -136,6 +136,8 @@ X!Edrivers/base/interface.c !Iinclude/linux/seqno-fence.h !Edrivers/dma-buf/reservation.c !Iinclude/linux/reservation.h +!Edrivers/dma-buf/sync_file.c +!Iinclude/linux/sync_file.h !Edrivers/base/dma-coherent.c !Edrivers/base/dma-mapping.c -- 2.5.5
[PATCH v2 11/13] dma-buf/sync_file: de-stage sync_file
From: Gustavo Padovan
sync_file is useful to connect one or more fences to the file. The file is
used by userspace to track fences between drivers that share DMA bufs.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/Kconfig | 2 ++
drivers/dma-buf/Kconfig | 11 +++
drivers/dma-buf/Makefile | 1 +
drivers/{staging/android => dma-buf}/sync_file.c | 0
drivers/staging/android/Kconfig | 1 +
drivers/staging/android/Makefile | 2 +-
6 files changed, 16 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma-buf/Kconfig
rename drivers/{staging/android => dma-buf}/sync_file.c (100%)
diff --git a/drivers/Kconfig b/drivers/Kconfig
index d2ac339..430f761 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -114,6 +114,8 @@ source "drivers/rtc/Kconfig"
source "drivers/dma/Kconfig"
+source "drivers/dma-buf/Kconfig"
+
source "drivers/dca/Kconfig"
source "drivers/auxdisplay/Kconfig"
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
new file mode 100644
index 000..9824bc4
--- /dev/null
+++ b/drivers/dma-buf/Kconfig
@@ -0,0 +1,11 @@
+menu "DMABUF options"
+
+config SYNC_FILE
+ bool "sync_file support for fences"
+ default n
+ select ANON_INODES
+ select DMA_SHARED_BUFFER
+ ---help---
+ This option enables the fence framework synchronization to export
+ sync_files to userspace that can represent one or more fences.
+endmenu
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 57a675f..4a424ec 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1 +1,2 @@
obj-y := dma-buf.o fence.o reservation.o seqno-fence.o
+obj-$(CONFIG_SYNC_FILE)+= sync_file.o
diff --git a/drivers/staging/android/sync_file.c b/drivers/dma-buf/sync_file.c
similarity index 100%
rename from drivers/staging/android/sync_file.c
rename to drivers/dma-buf/sync_file.c
diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 4244821..7a3a77e 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -38,6 +38,7 @@ config SW_SYNC
bool "Software synchronization objects"
default n
depends on SYNC
+ depends on SYNC_FILE
---help---
A sync object driver that uses a 32bit counter to coordinate
synchronization. Useful when there is no hardware primitive backing
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index ebc2df1..980d6dc 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -4,5 +4,5 @@ obj-y += ion/
obj-$(CONFIG_ASHMEM) += ashmem.o
obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
-obj-$(CONFIG_SYNC) += sync_file.o sync.o sync_debug.o
+obj-$(CONFIG_SYNC) += sync.o sync_debug.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o
--
2.5.5
[PATCH v2 10/13] dma-buf/sync_file: de-stage sync_file headers
From: Gustavo Padovan
Move sync_file headers file to include/ dir.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/staging/android/sync.h | 4 ++--
drivers/staging/android/sync_debug.c | 2 +-
drivers/staging/android/sync_file.c | 4 ++--
{drivers/staging/android => include/linux}/sync_file.h | 0
{drivers/staging/android/uapi => include/uapi/linux}/sync_file.h | 0
5 files changed, 5 insertions(+), 5 deletions(-)
rename {drivers/staging/android => include/linux}/sync_file.h (100%)
rename {drivers/staging/android/uapi => include/uapi/linux}/sync_file.h (100%)
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index df44abb..b56885c 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -20,8 +20,8 @@
#include
#include
-#include "sync_file.h"
-#include "uapi/sync_file.h"
+#include
+#include
struct sync_timeline;
diff --git a/drivers/staging/android/sync_debug.c
b/drivers/staging/android/sync_debug.c
index 8b55218..5f57499 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -26,7 +26,7 @@
#include
#include
#include
-#include "sync_file.h"
+#include
#include "sw_sync.h"
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/staging/android/sync_file.c
b/drivers/staging/android/sync_file.c
index eabf90d..f08cf2d 100644
--- a/drivers/staging/android/sync_file.c
+++ b/drivers/staging/android/sync_file.c
@@ -23,8 +23,8 @@
#include
#include
#include
-#include "sync_file.h"
-#include "uapi/sync_file.h"
+#include
+#include
static const struct file_operations sync_file_fops;
diff --git a/drivers/staging/android/sync_file.h b/include/linux/sync_file.h
similarity index 100%
rename from drivers/staging/android/sync_file.h
rename to include/linux/sync_file.h
diff --git a/drivers/staging/android/uapi/sync_file.h
b/include/uapi/linux/sync_file.h
similarity index 100%
rename from drivers/staging/android/uapi/sync_file.h
rename to include/uapi/linux/sync_file.h
--
2.5.5
[PATCH v2 09/13] staging/android: style fix: alignment to match the open parenthesis
From: Gustavo Padovan
Fix checks reported by checkpatch.pl.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/staging/android/sync_file.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/android/sync_file.c
b/drivers/staging/android/sync_file.c
index d9da3a4..eabf90d 100644
--- a/drivers/staging/android/sync_file.c
+++ b/drivers/staging/android/sync_file.c
@@ -242,7 +242,7 @@ static unsigned int sync_file_poll(struct file *file,
poll_table *wait)
}
static long sync_file_ioctl_merge(struct sync_file *sync_file,
- unsigned long arg)
+ unsigned long arg)
{
int fd = get_unused_fd_flags(O_CLOEXEC);
int err;
@@ -297,7 +297,7 @@ err_put_fd:
}
static void sync_fill_fence_info(struct fence *fence,
- struct sync_fence_info *info)
+struct sync_fence_info *info)
{
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
@@ -311,7 +311,7 @@ static void sync_fill_fence_info(struct fence *fence,
}
static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
- unsigned long arg)
+ unsigned long arg)
{
struct sync_file_info info;
struct sync_fence_info *fence_info = NULL;
@@ -370,7 +370,7 @@ out:
}
static long sync_file_ioctl(struct file *file, unsigned int cmd,
-unsigned long arg)
+ unsigned long arg)
{
struct sync_file *sync_file = file->private_data;
--
2.5.5
[PATCH v2 08/13] staging/android: improve documentation for sync_file
From: Gustavo Padovan
num_fences was missing a colon mark and sync_file_create() now have
better description.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/staging/android/sync_file.c | 5 +++--
drivers/staging/android/sync_file.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/sync_file.c
b/drivers/staging/android/sync_file.c
index 2c724ec..d9da3a4 100644
--- a/drivers/staging/android/sync_file.c
+++ b/drivers/staging/android/sync_file.c
@@ -65,11 +65,12 @@ static void fence_check_cb_func(struct fence *f, struct
fence_cb *cb)
}
/**
- * sync_fence_create() - creates a sync fence
+ * sync_file_create() - creates a sync file
* @fence: fence to add to the sync_fence
*
* Creates a sync_file containg @fence. Once this is called, the sync_file
- * takes ownership of @fence.
+ * takes ownership of @fence. The sync_file can be released with
+ * fput(sync_file->file). Returns the sync_file or NULL in case of error.
*/
struct sync_file *sync_file_create(struct fence *fence)
{
diff --git a/drivers/staging/android/sync_file.h
b/drivers/staging/android/sync_file.h
index 8a1b546..c6ffe8b 100644
--- a/drivers/staging/android/sync_file.h
+++ b/drivers/staging/android/sync_file.h
@@ -32,7 +32,7 @@ struct sync_file_cb {
* @kref: reference count on fence.
* @name: name of sync_file. Useful for debugging
* @sync_file_list:membership in global file list
- * @num_fences number of sync_pts in the fence
+ * @num_fences:number of sync_pts in the fence
* @wq:wait queue for fence signaling
* @status:0: signaled, >0:active, <0: error
* @cbs: sync_pts callback information
--
2.5.5
[PATCH v2 07/13] staging/android: prepare sync_file for de-staging
From: Gustavo Padovan
Move its functions and structs to their own file. Also moves function's
docs to the .c file.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/staging/android/Makefile | 2 +-
drivers/staging/android/sync.c | 374 ---
drivers/staging/android/sync.h | 38 +-
drivers/staging/android/sync_debug.c | 1 +
drivers/staging/android/sync_file.c| 394 +
drivers/staging/android/sync_file.h| 57 +++
.../staging/android/uapi/{sync.h => sync_file.h} | 0
7 files changed, 455 insertions(+), 411 deletions(-)
create mode 100644 drivers/staging/android/sync_file.c
create mode 100644 drivers/staging/android/sync_file.h
rename drivers/staging/android/uapi/{sync.h => sync_file.h} (100%)
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 980d6dc..ebc2df1 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -4,5 +4,5 @@ obj-y += ion/
obj-$(CONFIG_ASHMEM) += ashmem.o
obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
-obj-$(CONFIG_SYNC) += sync.o sync_debug.o
+obj-$(CONFIG_SYNC) += sync_file.o sync.o sync_debug.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 5470ae9..1d14c83 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -16,10 +16,7 @@
#include
#include
-#include
-#include
#include
-#include
#include
#include
#include
@@ -32,7 +29,6 @@
#include "trace/sync.h"
static const struct fence_ops android_fence_ops;
-static const struct file_operations sync_file_fops;
struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops,
int size, const char *name)
@@ -136,182 +132,6 @@ struct fence *sync_pt_create(struct sync_timeline *obj,
int size)
}
EXPORT_SYMBOL(sync_pt_create);
-static struct sync_file *sync_file_alloc(int size)
-{
- struct sync_file *sync_file;
-
- sync_file = kzalloc(size, GFP_KERNEL);
- if (!sync_file)
- return NULL;
-
- sync_file->file = anon_inode_getfile("sync_file", &sync_file_fops,
-sync_file, 0);
- if (IS_ERR(sync_file->file))
- goto err;
-
- kref_init(&sync_file->kref);
-
- init_waitqueue_head(&sync_file->wq);
-
- return sync_file;
-
-err:
- kfree(sync_file);
- return NULL;
-}
-
-static void fence_check_cb_func(struct fence *f, struct fence_cb *cb)
-{
- struct sync_file_cb *check;
- struct sync_file *sync_file;
-
- check = container_of(cb, struct sync_file_cb, cb);
- sync_file = check->sync_file;
-
- if (atomic_dec_and_test(&sync_file->status))
- wake_up_all(&sync_file->wq);
-}
-
-/**
- * sync_fence_create() - creates a sync fence
- * @fence: fence to add to the sync_fence
- *
- * Creates a sync_file containg @fence. Once this is called, the sync_file
- * takes ownership of @fence.
- */
-struct sync_file *sync_file_create(struct fence *fence)
-{
- struct sync_file *sync_file;
-
- sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]));
- if (!sync_file)
- return NULL;
-
- sync_file->num_fences = 1;
- atomic_set(&sync_file->status, 1);
- snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%d-%d",
-fence->ops->get_driver_name(fence),
-fence->ops->get_timeline_name(fence), fence->context,
-fence->seqno);
-
- sync_file->cbs[0].fence = fence;
- sync_file->cbs[0].sync_file = sync_file;
- if (fence_add_callback(fence, &sync_file->cbs[0].cb,
- fence_check_cb_func))
- atomic_dec(&sync_file->status);
-
- sync_file_debug_add(sync_file);
-
- return sync_file;
-}
-EXPORT_SYMBOL(sync_file_create);
-
-/**
- * sync_file_fdget() - get a sync_file from an fd
- * @fd:fd referencing a fence
- *
- * Ensures @fd references a valid sync_file, increments the refcount of the
- * backing file. Returns the sync_file or NULL in case of error.
- */
-static struct sync_file *sync_file_fdget(int fd)
-{
- struct file *file = fget(fd);
-
- if (!file)
- return NULL;
-
- if (file->f_op != &sync_file_fops)
- goto err;
-
- return file->private_data;
-
-err:
- fput(file);
- return NULL;
-}
-
-static void sync_file_add_pt(struct sync_file *sync_file, int *i,
-struct fence *fence)
-{
- sync_file->cbs[*i].fence = fence;
- sync_file->cbs[*i].sync_file = sync_file;
-
- if (!fence_add_callb
[PATCH v2 06/13] staging/android: remove name arg from sync_file_create()
From: Gustavo Padovan
Simplifies the API to only receive the fence it needs to add to the
sync and create a name for the sync_file based on the fence context and
seqno.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/staging/android/sync.c | 16 +---
drivers/staging/android/sync.h | 2 +-
drivers/staging/android/sync_debug.c | 3 +--
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 7e0fa20..5470ae9 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -136,7 +136,7 @@ struct fence *sync_pt_create(struct sync_timeline *obj, int
size)
}
EXPORT_SYMBOL(sync_pt_create);
-static struct sync_file *sync_file_alloc(int size, const char *name)
+static struct sync_file *sync_file_alloc(int size)
{
struct sync_file *sync_file;
@@ -150,7 +150,6 @@ static struct sync_file *sync_file_alloc(int size, const
char *name)
goto err;
kref_init(&sync_file->kref);
- strlcpy(sync_file->name, name, sizeof(sync_file->name));
init_waitqueue_head(&sync_file->wq);
@@ -175,23 +174,25 @@ static void fence_check_cb_func(struct fence *f, struct
fence_cb *cb)
/**
* sync_fence_create() - creates a sync fence
- * @name: name of fence to create
* @fence: fence to add to the sync_fence
*
* Creates a sync_file containg @fence. Once this is called, the sync_file
* takes ownership of @fence.
*/
-struct sync_file *sync_file_create(const char *name, struct fence *fence)
+struct sync_file *sync_file_create(struct fence *fence)
{
struct sync_file *sync_file;
- sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]),
- name);
+ sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]));
if (!sync_file)
return NULL;
sync_file->num_fences = 1;
atomic_set(&sync_file->status, 1);
+ snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%d-%d",
+fence->ops->get_driver_name(fence),
+fence->ops->get_timeline_name(fence), fence->context,
+fence->seqno);
sync_file->cbs[0].fence = fence;
sync_file->cbs[0].sync_file = sync_file;
@@ -260,7 +261,7 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
int i, i_a, i_b;
unsigned long size = offsetof(struct sync_file, cbs[num_fences]);
- sync_file = sync_file_alloc(size, name);
+ sync_file = sync_file_alloc(size);
if (!sync_file)
return NULL;
@@ -306,6 +307,7 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
atomic_sub(num_fences - i, &sync_file->status);
sync_file->num_fences = i;
+ strlcpy(sync_file->name, name, sizeof(sync_file->name));
sync_file_debug_add(sync_file);
return sync_file;
}
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 1f164df..7dee444 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -167,7 +167,7 @@ void sync_timeline_signal(struct sync_timeline *obj);
*/
struct fence *sync_pt_create(struct sync_timeline *parent, int size);
-struct sync_file *sync_file_create(const char *name, struct fence *fence);
+struct sync_file *sync_file_create(struct fence *fence);
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/staging/android/sync_debug.c
b/drivers/staging/android/sync_debug.c
index e4b0e41..2cab40d 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -262,8 +262,7 @@ static long sw_sync_ioctl_create_fence(struct
sw_sync_timeline *obj,
goto err;
}
- data.name[sizeof(data.name) - 1] = '\0';
- sync_file = sync_file_create(data.name, fence);
+ sync_file = sync_file_create(fence);
if (!sync_file) {
fence_put(fence);
err = -ENOMEM;
--
2.5.5
[PATCH v2 05/13] staging/android: make sync_file_fdget() static
From: Gustavo Padovan
There is no plan in the near future to use this function outside of this
file so keep it as static.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/staging/android/sync.c | 3 +--
drivers/staging/android/sync.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index e9bf251..7e0fa20 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -212,7 +212,7 @@ EXPORT_SYMBOL(sync_file_create);
* Ensures @fd references a valid sync_file, increments the refcount of the
* backing file. Returns the sync_file or NULL in case of error.
*/
-struct sync_file *sync_file_fdget(int fd)
+static struct sync_file *sync_file_fdget(int fd)
{
struct file *file = fget(fd);
@@ -228,7 +228,6 @@ err:
fput(file);
return NULL;
}
-EXPORT_SYMBOL(sync_file_fdget);
static void sync_file_add_pt(struct sync_file *sync_file, int *i,
struct fence *fence)
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index ffc6df6..1f164df 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -168,7 +168,6 @@ void sync_timeline_signal(struct sync_timeline *obj);
struct fence *sync_pt_create(struct sync_timeline *parent, int size);
struct sync_file *sync_file_create(const char *name, struct fence *fence);
-struct sync_file *sync_file_fdget(int fd);
#ifdef CONFIG_DEBUG_FS
--
2.5.5
[PATCH v2 04/13] staging/android: make sync_file_merge() static
From: Gustavo Padovan
There is no plan in the near future to use this function outside of this
file so keep it as static.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/staging/android/sync.c | 5 ++---
drivers/staging/android/sync.h | 2 --
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index a89ded0..e9bf251 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -253,8 +253,8 @@ static void sync_file_add_pt(struct sync_file *sync_file,
int *i,
* @a and @b. @a and @b remain valid, independent sync_file. Returns the
* new merged sync_file or NULL in case of error.
*/
-struct sync_file *sync_file_merge(const char *name,
- struct sync_file *a, struct sync_file *b)
+static struct sync_file *sync_file_merge(const char *name, struct sync_file *a,
+struct sync_file *b)
{
int num_fences = a->num_fences + b->num_fences;
struct sync_file *sync_file;
@@ -310,7 +310,6 @@ struct sync_file *sync_file_merge(const char *name,
sync_file_debug_add(sync_file);
return sync_file;
}
-EXPORT_SYMBOL(sync_file_merge);
static const char *android_fence_get_driver_name(struct fence *fence)
{
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 925fba5..ffc6df6 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -168,8 +168,6 @@ void sync_timeline_signal(struct sync_timeline *obj);
struct fence *sync_pt_create(struct sync_timeline *parent, int size);
struct sync_file *sync_file_create(const char *name, struct fence *fence);
-struct sync_file *sync_file_merge(const char *name,
- struct sync_file *a, struct sync_file *b);
struct sync_file *sync_file_fdget(int fd);
#ifdef CONFIG_DEBUG_FS
--
2.5.5
[PATCH v2 03/13] staging/android: move sync_file functions comments to sync.c
From: Gustavo Padovan
To keep comments in line with drivers/dma-buf/ move all sync_file comments
to sync.c.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/staging/android/sync.c | 26 +-
drivers/staging/android/sync.h | 31 ---
2 files changed, 25 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index b965e2a..a89ded0 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -173,7 +173,14 @@ static void fence_check_cb_func(struct fence *f, struct
fence_cb *cb)
wake_up_all(&sync_file->wq);
}
-/* TODO: implement a create which takes more that one fence */
+/**
+ * sync_fence_create() - creates a sync fence
+ * @name: name of fence to create
+ * @fence: fence to add to the sync_fence
+ *
+ * Creates a sync_file containg @fence. Once this is called, the sync_file
+ * takes ownership of @fence.
+ */
struct sync_file *sync_file_create(const char *name, struct fence *fence)
{
struct sync_file *sync_file;
@@ -198,6 +205,13 @@ struct sync_file *sync_file_create(const char *name,
struct fence *fence)
}
EXPORT_SYMBOL(sync_file_create);
+/**
+ * sync_file_fdget() - get a sync_file from an fd
+ * @fd:fd referencing a fence
+ *
+ * Ensures @fd references a valid sync_file, increments the refcount of the
+ * backing file. Returns the sync_file or NULL in case of error.
+ */
struct sync_file *sync_file_fdget(int fd)
{
struct file *file = fget(fd);
@@ -229,6 +243,16 @@ static void sync_file_add_pt(struct sync_file *sync_file,
int *i,
}
}
+/**
+ * sync_file_merge() - merge two sync_files
+ * @name: name of new fence
+ * @a: sync_file a
+ * @b: sync_file b
+ *
+ * Creates a new sync_file which contains copies of all the fences in both
+ * @a and @b. @a and @b remain valid, independent sync_file. Returns the
+ * new merged sync_file or NULL in case of error.
+ */
struct sync_file *sync_file_merge(const char *name,
struct sync_file *a, struct sync_file *b)
{
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index c45cc7b..925fba5 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -167,40 +167,9 @@ void sync_timeline_signal(struct sync_timeline *obj);
*/
struct fence *sync_pt_create(struct sync_timeline *parent, int size);
-/**
- * sync_fence_create() - creates a sync fence
- * @name: name of fence to create
- * @fence: fence to add to the sync_fence
- *
- * Creates a sync_file containg @fence. Once this is called, the sync_file
- * takes ownership of @fence.
- */
struct sync_file *sync_file_create(const char *name, struct fence *fence);
-
-/*
- * API for sync_file consumers
- */
-
-/**
- * sync_file_merge() - merge two sync_files
- * @name: name of new fence
- * @a: sync_file a
- * @b: sync_file b
- *
- * Creates a new sync_file which contains copies of all the fences in both
- * @a and @b. @a and @b remain valid, independent sync_file. Returns the
- * new merged sync_file or NULL in case of error.
- */
struct sync_file *sync_file_merge(const char *name,
struct sync_file *a, struct sync_file *b);
-
-/**
- * sync_file_fdget() - get a sync_file from an fd
- * @fd:fd referencing a fence
- *
- * Ensures @fd references a valid sync_file, increments the refcount of the
- * backing file. Returns the sync_file or NULL in case of error.
- */
struct sync_file *sync_file_fdget(int fd);
#ifdef CONFIG_DEBUG_FS
--
2.5.5
[PATCH v2 02/13] staging/android: drop sync_file_install() and sync_file_put()
From: Gustavo Padovan
These two functions are just wrappers for one line functions, they
call fd_install() and fput() respectively, so just get rid of them
and use fd_install() and fput() directly for more simplicity.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/staging/android/sync.c | 20
drivers/staging/android/sync.h | 19 ---
drivers/staging/android/sync_debug.c | 4 ++--
3 files changed, 6 insertions(+), 37 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index f9c6094..b965e2a 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -216,18 +216,6 @@ err:
}
EXPORT_SYMBOL(sync_file_fdget);
-void sync_file_put(struct sync_file *sync_file)
-{
- fput(sync_file->file);
-}
-EXPORT_SYMBOL(sync_file_put);
-
-void sync_file_install(struct sync_file *sync_file, int fd)
-{
- fd_install(fd, sync_file->file);
-}
-EXPORT_SYMBOL(sync_file_install);
-
static void sync_file_add_pt(struct sync_file *sync_file, int *i,
struct fence *fence)
{
@@ -469,15 +457,15 @@ static long sync_file_ioctl_merge(struct sync_file
*sync_file,
goto err_put_fence3;
}
- sync_file_install(fence3, fd);
- sync_file_put(fence2);
+ fd_install(fd, fence3->file);
+ fput(fence2->file);
return 0;
err_put_fence3:
- sync_file_put(fence3);
+ fput(fence3->file);
err_put_fence2:
- sync_file_put(fence2);
+ fput(fence2->file);
err_put_fd:
put_unused_fd(fd);
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index d2a1734..c45cc7b 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -203,25 +203,6 @@ struct sync_file *sync_file_merge(const char *name,
*/
struct sync_file *sync_file_fdget(int fd);
-/**
- * sync_file_put() - puts a reference of a sync_file
- * @sync_file: sync_file to put
- *
- * Puts a reference on @sync_fence. If this is the last reference, the
- * sync_fil and all it's sync_pts will be freed
- */
-void sync_file_put(struct sync_file *sync_file);
-
-/**
- * sync_file_install() - installs a sync_file into a file descriptor
- * @sync_file: sync_file to install
- * @fd:file descriptor in which to install the fence
- *
- * Installs @sync_file into @fd. @fd's should be acquired through
- * get_unused_fd_flags(O_CLOEXEC).
- */
-void sync_file_install(struct sync_file *sync_file, int fd);
-
#ifdef CONFIG_DEBUG_FS
void sync_timeline_debug_add(struct sync_timeline *obj);
diff --git a/drivers/staging/android/sync_debug.c
b/drivers/staging/android/sync_debug.c
index 5a7ec58..e4b0e41 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -272,12 +272,12 @@ static long sw_sync_ioctl_create_fence(struct
sw_sync_timeline *obj,
data.fence = fd;
if (copy_to_user((void __user *)arg, &data, sizeof(data))) {
- sync_file_put(sync_file);
+ fput(sync_file->file);
err = -EFAULT;
goto err;
}
- sync_file_install(sync_file, fd);
+ fd_install(fd, sync_file->file);
return 0;
--
2.5.5
[PATCH v2 01/13] staging/android: remove redundant comments on sync_merge_data
From: Gustavo Padovan
struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/staging/android/uapi/sync.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/android/uapi/sync.h
b/drivers/staging/android/uapi/sync.h
index 7de5d6a..413303d 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -23,9 +23,9 @@
* @pad: padding for 64-bit alignment, should always be zero
*/
struct sync_merge_data {
- charname[32]; /* name of new fence */
- __s32 fd2; /* fd of second fence */
- __s32 fence; /* fd on newly created fence */
+ charname[32];
+ __s32 fd2;
+ __s32 fence;
__u32 flags;
__u32 pad;
};
@@ -33,8 +33,8 @@ struct sync_merge_data {
/**
* struct sync_fence_info - detailed fence information
* @obj_name: name of parent sync_timeline
- * @driver_name: name of driver implementing the parent
- * @status:status of the fence 0:active 1:signaled <0:error
+* @driver_name:name of driver implementing the parent
+* @status: status of the fence 0:active 1:signaled <0:error
* @flags: fence_info flags
* @timestamp_ns: timestamp of status change in nanoseconds
*/
--
2.5.5
[PATCH v2 00/13] De-stage Sync File Framework
From: Gustavo Padovan Hi, This patchset sits on top of Sync ABI Rework v13: https://www.spinics.net/lists/dri-devel/msg105667.html The first eight clean up and prepare sync_file for de-staging. The last four patches do the de-staging, moving files to drivers/dma-buf/ and include/linux/ plus adding Documentation. As the de-stage depends upon many changes on the staging tree it would be good to get all the patches merged through the staging tree if Sumit agrees with that. The next step on the Sync de-stage is clean up the remaining bits of the Sync Framework, mainly SW_SYNC, which is only used for testing. v2: - Add Reviewed-by: tag from Daniel Vetter to all patches. - Take in sugestions for the Sync File Documentation (Daniel) - Remove name arg from sync_file_crate() (Daniel) - Revome leftover EXPORT_SYMBOL(sync_file_merge) (Daniel) Thanks, Gustavo Gustavo Padovan (13): staging/android: remove redundant comments on sync_merge_data staging/android: drop sync_file_install() and sync_file_put() staging/android: move sync_file functions comments to sync.c staging/android: make sync_file_merge() static staging/android: make sync_file_fdget() static staging/android: remove name arg from sync_file_create() staging/android: prepare sync_file for de-staging staging/android: improve documentation for sync_file staging/android: style fix: alignment to match the open parenthesis dma-buf/sync_file: de-stage sync_file headers dma-buf/sync_file: de-stage sync_file Documentation: include sync_file into DocBook Documentation: add Sync File doc Documentation/DocBook/device-drivers.tmpl | 2 + Documentation/sync_file.txt | 69 ++ drivers/Kconfig | 2 + drivers/dma-buf/Kconfig | 11 + drivers/dma-buf/Makefile | 1 + drivers/dma-buf/sync_file.c | 395 ++ drivers/staging/android/Kconfig | 1 + drivers/staging/android/sync.c| 362 --- drivers/staging/android/sync.h| 91 +-- drivers/staging/android/sync_debug.c | 8 +- drivers/staging/android/uapi/sync.h | 100 include/linux/sync_file.h | 57 + include/uapi/linux/sync_file.h| 100 13 files changed, 644 insertions(+), 555 deletions(-) create mode 100644 Documentation/sync_file.txt create mode 100644 drivers/dma-buf/Kconfig create mode 100644 drivers/dma-buf/sync_file.c delete mode 100644 drivers/staging/android/uapi/sync.h create mode 100644 include/linux/sync_file.h create mode 100644 include/uapi/linux/sync_file.h -- 2.5.5
[PATCH] drm: fix pixel size of NV12 / NV16 pixel formats
With NV12, NV21, NV16 and NV61 formats, the size of one pixel from the UV plane (plane #1) is one byte. Indeed, these pixel formats use 4:2:x chroma subsampling: the chroma pixels are sampled at half the luma: for 2 pixels, there are 1 Cb + 1 Cr = 2 bytes. So for plane #1, the correct size is actually 1 byte per pixel. Signed-off-by: Fabien Dessenne --- drivers/gpu/drm/drm_crtc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 3313f7e..572c6fa 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -5618,10 +5618,6 @@ int drm_format_plane_cpp(uint32_t format, int plane) case DRM_FORMAT_UYVY: case DRM_FORMAT_VYUY: return 2; - case DRM_FORMAT_NV12: - case DRM_FORMAT_NV21: - case DRM_FORMAT_NV16: - case DRM_FORMAT_NV61: case DRM_FORMAT_NV24: case DRM_FORMAT_NV42: return plane ? 2 : 1; @@ -5635,6 +5631,10 @@ int drm_format_plane_cpp(uint32_t format, int plane) case DRM_FORMAT_YVU422: case DRM_FORMAT_YUV444: case DRM_FORMAT_YVU444: + case DRM_FORMAT_NV12: + case DRM_FORMAT_NV21: + case DRM_FORMAT_NV16: + case DRM_FORMAT_NV61: return 1; default: drm_fb_get_bpp_depth(format, &depth, &bpp); -- 1.9.1
drm/vmwgfx: Initial DX support
Hello Thomas Hellstrom,
The patch d80efd5cb3de: "drm/vmwgfx: Initial DX support" from Aug 10,
2015, leads to the following static checker warning:
drivers/gpu/drm/vmwgfx/vmwgfx_so.c:335 vmw_view_add()
error: buffer overflow 'vmw_view_define_sizes' 3 <= 3
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
2656 static int vmw_cmd_dx_view_define(struct vmw_private *dev_priv,
2657struct vmw_sw_context *sw_context,
2658SVGA3dCmdHeader *header)
2659 {
2660 struct vmw_resource_val_node *ctx_node =
sw_context->dx_ctx_node;
2661 struct vmw_resource_val_node *srf_node;
2662 struct vmw_resource *res;
2663 enum vmw_view_type view_type;
2664 int ret;
2665 /*
2666 * This is based on the fact that all affected define commands
have
2667 * the same initial command body layout.
2668 */
2669 struct {
2670 SVGA3dCmdHeader header;
2671 uint32 defined_id;
2672 uint32 sid;
2673 } *cmd;
2674
2675 if (unlikely(ctx_node == NULL)) {
2676 DRM_ERROR("DX Context not set.\n");
2677 return -EINVAL;
2678 }
2679
2680 view_type = vmw_view_cmd_to_type(header->id);
vmw_view_cmd_to_type() returns 0-3.
2681 cmd = container_of(header, typeof(*cmd), header);
2682 ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
2683 user_surface_converter,
2684 &cmd->sid, &srf_node);
2685 if (unlikely(ret != 0))
2686 return ret;
2687
2688 res = vmw_context_cotable(ctx_node->res,
vmw_view_cotables[view_type]);
So we're one space beyond the end of the array, here and other places.
2689 ret = vmw_cotable_notify(res, cmd->defined_id);
2690 vmw_resource_unreference(&res);
2691 if (unlikely(ret != 0))
2692 return ret;
regards,
dan carpenter
[Intel-gfx] RFC: libdrm: Support Iris Graphics 540 & 550 (Skylake GT3e)
Kenneth Graunke wrote on 28.04.2016 03:05: > On Wednesday, April 27, 2016 9:37:07 AM PDT Thorsten Leemhuis wrote: >> Thorsten Leemhuis wrote on 26.04.2016 13:41: >> > Lo! Below patch adds the PCI-ID for the Intel(R) Iris Graphics 550 > (Skylake >>> GT3e mobile) to libdrm. It afaics is the last piece that is missing to >>> make those GPUs work properly, as Linux 4.6-rc(¹) and Mesa 11.2 already >>> support it â > [â¦] >> Forget that patch -- a way better one was submitted weeks ago my Michal >> already: >> https://lists.freedesktop.org/archives/intel-gfx/2016-February/087819.html > It looks like it fell through the cracks. Roland just mentioned this on > IRC...I've reviewed and pushed the patch to master. I'm also making a > release. Many thx. Side note, while at it: I think this linux-drm patch from MichaÅ fell through the cracks, too: https://lists.freedesktop.org/archives/intel-gfx/2016-February/087855.html Whole story: That libdrm patch you applied contained this line: +#define PCI_CHIP_SKYLAKE_SRV_GT3 0x192D This id for the Iris Graphics P555 is also present in Mesa master i965(¹), but missing in Linux master afaics: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/drm/i915_pciids.h#n279 And it's not in drm-intel-next either afaics: https://cgit.freedesktop.org/drm-intel/tree/include/drm/i915_pciids.h?h=drm-intel-next#n279 CU, knurd (¹) https://cgit.freedesktop.org/mesa/mesa/tree/include/pci_ids/i965_pci_ids.h#n132
[PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
On Wednesday 27 April 2016 08:05 PM, Alexey Brodkin wrote:
> Allocation of a frame buffer memory in a special memory region
> allows bypassing of so-called IO Coherency aperture
> which is typically set as a range 0x8z-0xAz.
>
> I.e. all data traffic to PGU bypasses IO Coherency block
> and saves its bandwidth for other peripherals.
>
> Even though for AXS101 (which sorts ARC770 CPU) IOC is not
> an option for a sake of keeping one DT description for the
> base-board (axs10x_mb.dtsi) we're still defining reserved
> memory location in the very end of DDR.
>
> Signed-off-by: Alexey Brodkin
> Cc: devicetree at vger.kernel.org
> ---
> arch/arc/boot/dts/axc001.dtsi | 20 +++-
> arch/arc/boot/dts/axc003.dtsi | 14 ++
> arch/arc/boot/dts/axc003_idu.dtsi | 14 ++
> arch/arc/boot/dts/axs10x_mb.dtsi | 2 +-
> 4 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> index 420dcfd..ae6162d 100644
> --- a/arch/arc/boot/dts/axc001.dtsi
> +++ b/arch/arc/boot/dts/axc001.dtsi
> @@ -95,6 +95,24 @@
> #size-cells = <1>;
> ranges = <0x 0x8000 0x4000>;
> device_type = "memory";
> - reg = <0x8000 0x2000>; /* 512MiB */
> + reg = <0x8000 0x1f00>; /* 512 - 16 MiB */
Is 16MB fixed size or is this a function of display resolution / density etc.
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + /*
> + * We just move frame buffer area to the very end of
> + * available DDR. And even though in case of ARC770 there's
> + * no strict requirement for a frame-buffer to be in any
> + * particular location it allows us to use the same
> + * base board's DT node for ARC PGU as for ARc HS38.
> + */
> + frame_buffer: frame_buffer at 9f00 {
> + compatible = "shared-dma-pool";
> + reg = <0x9f00 0x100>;
> + no-map;
> + };
> };
> };
> diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
> index f90fadf..c7a95c2 100644
> --- a/arch/arc/boot/dts/axc003.dtsi
> +++ b/arch/arc/boot/dts/axc003.dtsi
> @@ -100,4 +100,18 @@
> device_type = "memory";
> reg = <0x8000 0x2000>; /* 512MiB */
> };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + /*
> + * Move frame buffer out of IOC aperture (0x8z-0xAz).
> + */
> + frame_buffer: frame_buffer at a000 {
> + compatible = "shared-dma-pool";
> + reg = <0xa000 0x100>;
Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
currently only uses 512M. Once we increase that, this will need fixing too.
Better
to make this as far possible. Note that the IOC start alignment needs to follow
max(4k, size). What will be maximum size of frame buffer - 16M always !
Same for the idu DT below !
> + no-map;
> + };
> + };
> };
> diff --git a/arch/arc/boot/dts/axc003_idu.dtsi
> b/arch/arc/boot/dts/axc003_idu.dtsi
> index 06a9f29..929ec8c 100644
> --- a/arch/arc/boot/dts/axc003_idu.dtsi
> +++ b/arch/arc/boot/dts/axc003_idu.dtsi
> @@ -123,4 +123,18 @@
> device_type = "memory";
> reg = <0x8000 0x2000>; /* 512MiB */
> };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + /*
> + * Move frame buffer out of IOC aperture (0x8z-0xAz).
> + */
> + frame_buffer: frame_buffer at a000 {
> + compatible = "shared-dma-pool";
> + reg = <0xa000 0x100>;
> + no-map;
> + };
> + };
> };
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi
> b/arch/arc/boot/dts/axs10x_mb.dtsi
> index 823f15c..64b063d 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -283,7 +283,7 @@
> encoder-slave = <&adv7511>;
> clocks = <&pguclk>;
> clock-names = "pxlclk";
> -
> + memory-region = <&frame_buffer>;
> port {
> pgu_output: endpoint {
> remote-endpoint = <&adv7511_input>;
>
[Bug 87856] Driver load fails with no error on ppc64 host
https://bugs.freedesktop.org/show_bug.cgi?id=87856 --- Comment #13 from Mathieu Malaterre --- I believe that all r600 issues have now been solved (thx Oded!). The remaining of the comments relates to r300 (and thus is a dup of #71789). I believe this bug can be closed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/06853cff/attachment.html>
[PATCH v4 05/11] drm: Add Allwinner A10 Display Engine support
Hi Boris,
On Tue, Apr 26, 2016 at 11:14:19AM +0200, Boris Brezillon wrote:
> Hi Maxime,
>
> On Mon, 25 Apr 2016 15:22:46 +0200
> Maxime Ripard wrote:
>
> > The Allwinner A10 and subsequent SoCs share the same display pipeline, with
> > variations in the number of controllers (1 or 2), or the presence or not of
> > some output (HDMI, TV, VGA) or not.
> >
> > Add a driver with a limited set of features for now, and we will hopefully
> > support all of them eventually
> >
> > Signed-off-by: Maxime Ripard
>
> Just 2 comments below. Once addressed you can add my
>
> Reviewed-by: Boris Brezillon
>
> > ---
>
> [...]
>
> > +
> > +static int sun4i_drv_connector_plug_all(struct drm_device *drm)
> > +{
> > + struct drm_connector *connector, *failed;
> > + int ret;
> > +
> > + mutex_lock(&drm->mode_config.mutex);
> > + list_for_each_entry(connector, &drm->mode_config.connector_list, head) {
> > + ret = drm_connector_register(connector);
> > + if (ret) {
> > + failed = connector;
> > + goto err;
> > + }
> > + }
> > + mutex_unlock(&drm->mode_config.mutex);
> > + return 0;
> > +
> > +err:
> > + list_for_each_entry(connector, &drm->mode_config.connector_list, head) {
> > + if (failed == connector)
> > + break;
> > +
> > + drm_connector_unregister(connector);
> > + }
> > + mutex_unlock(&drm->mode_config.mutex);
> > +
> > + return ret;
> > +}
>
> You can use the generic drm_connector_register_all() to do that.
>
> [...]
>
> > +
> > +static void sun4i_drv_unbind(struct device *dev)
> > +{
> > + struct drm_device *drm = dev_get_drvdata(dev);
> > +
>
> And you probably miss a call to drm_connector_unregister_all() here.
Thanks, I'll fix that.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160428/0d08c8d6/attachment.sig>
[PATCH v14 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
On Thu, 2016-04-14 at 16:28 +0200, Thierry Reding wrote:
> On Sun, Apr 03, 2016 at 12:20:45PM +0800, Jitao Shi wrote:
> [...]
> > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > new file mode 100644
> > index 000..87f8bc7
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> > @@ -0,0 +1,1066 @@
> > +/*
> > + * Copyright (c) 2014 MediaTek Inc.
>
> Presumably the copyright here should be updated?
Thanks for your review. I'll update it next version.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define PAGE2_SPI_CFG3 0x82
> > +#define I2C_TO_SPI_RESET 0x20
> > +#define PAGE2_ROMADD_BYTE1 0x8e
> > +#define PAGE2_ROMADD_BYTE2 0x8f
> > +#define PAGE2_SWSPI_WDATA 0x90
> > +#define PAGE2_SWSPI_RDATA 0x91
> > +#define PAGE2_SWSPI_LEN0x92
> > +#define PAGE2_SWSPI_CTL0x93
> > +#define TRIGGER_NO_READBACK0x05
> > +#define TRIGGER_READBACK 0x01
> > +#define PAGE2_SPI_STATUS 0x9e
> > +#define PAGE2_GPIO_L 0xa6
> > +#define PAGE2_GPIO_H 0xa7
> > +#define PS_GPIO9 BIT(1)
> > +#define PAGE2_IROM_CTRL0xb0
> > +#define IROM_ENABLE0xc0
> > +#define IROM_DISABLE 0x80
> > +#define PAGE2_SW_RESET 0xbc
> > +#define SPI_SW_RESET BIT(7)
> > +#define MPU_SW_RESET BIT(6)
> > +#define PAGE2_ENCTLSPI_WR 0xda
> > +#define PAGE2_I2C_BYPASS 0xea
> > +#define I2C_BYPASS_EN 0xd0
> > +#define PAGE3_SET_ADD 0xfe
> > +#define PAGE3_SET_VAL 0xff
> > +#define VDO_CTL_ADD0x13
> > +#define VDO_DIS0x18
> > +#define VDO_EN 0x1c
> > +#define PAGE4_REV_L0xf0
> > +#define PAGE4_REV_H0xf1
> > +#define PAGE4_CHIP_L 0xf2
> > +#define PAGE4_CHIP_H 0xf3
> > +
> > +/* Firmware */
> > +#define SPI_MAX_RETRY_CNT 8
> > +#define PS_FW_NAME "ps864x_fw.bin"
> > +
> > +#define FW_CHIP_ID_OFFSET 0
> > +#define FW_VERSION_OFFSET 2
> > +#define EDID_I2C_ADDR 0x50
> > +
> > +#define WRITE_STATUS_REG_CMD 0x01
> > +#define READ_STATUS_REG_CMD0x05
> > +#define BUSY BIT(0)
> > +#define CLEAR_ALL_PROTECT 0x00
> > +#define BLK_PROTECT_BITS 0x0c
> > +#define STATUS_REG_PROTECT BIT(7)
> > +#define WRITE_ENABLE_CMD 0x06
> > +#define CHIP_ERASE_CMD 0xc7
> > +
> > +#define bridge_to_ps8640(e)container_of(e, struct ps8640, bridge)
> > +#define connector_to_ps8640(e) container_of(e, struct ps8640,
> > connector)
>
> I'd prefer these to be static inline functions.
I'll update it next version.
Thanks
>
> > +
> > +struct ps8640_info {
> > + u8 family_id;
> > + u8 variant_id;
> > + u16 version;
> > +};
> > +
> > +struct ps8640 {
> > + struct drm_connector connector;
> > + struct drm_bridge bridge;
> > + struct edid *edid;
> > + struct mipi_dsi_device dsi;
> > + struct i2c_client *page[8];
> > + struct i2c_client *ddc_i2c;
> > + struct regulator_bulk_data supplies[2];
> > + struct drm_panel *panel;
> > + struct gpio_desc *gpio_rst_n;
> > + struct gpio_desc *gpio_slp_n;
> > + struct gpio_desc *gpio_mode_sel_n;
> > + bool enabled;
> > +
> > + /* firmware file info */
> > + bool in_fw_update;
> > + struct ps8640_info info;
> > +};
> > +
> > +static const u8 enc_ctrl_code[6] = {0xaa, 0x55, 0x50, 0x41, 0x52, 0x44};
> > +static const u8 hw_chip_id[4] = {0x00, 0x0a, 0x00, 0x30};
>
> Spaces after { and before }, please.
I'll fix them next version, thanks.
> > +
> > +static int ps8640_read(struct i2c_client *client, u8 reg, u8 *data,
> > + u16 data_len)
> > +{
> > + int ret;
> > + struct i2c_msg msgs[] = {
> > + {
> > +.addr = client->addr,
> > +.flags = 0,
> > +.len = 1,
> > +.buf = ®,
> > +},
> > + {
> > +.addr = client->addr,
> > +.flags = I2C_M_RD,
> > +.len = data_len,
> > +.buf = data,
> > +}
>
> Please indent properly here. This uses a weird mix of tabs and spaces,
> where it should be tabs only.
I'll fix it next version.
Thanks
>
> > + };
> > +
> > + ret = i2c_transfer(client->adapter, msgs, 2);
> > +
> > + if (ret == 2)
> > + return 0;
> > + if (ret < 0)
> > + return ret;
> > + else
> > + return -EIO;
> > +}
> > +
> > +static int ps8640_write_bytes(struct i2c_client *client, const u8 *data,
> > + u16 data_len)
> > +{
> > + int ret;
> > + struct i2c_msg msg;
> > +
> > + msg.ad
