[drm:radeon_dp_link_train] *ERROR* clock recovery failed -bisected
On Thu, Mar 03, 2016 at 02:38:11AM +, Ken Moffat wrote: > One of my machines is an A10 Kaveri desktop, with a good old VGA > connection to the monitor. I've only just started trying to boot > any 4.5 kernel on it, but with 4.5.0-rc6 and now linus's tree from a > few hours ago (4.5.0-rc6-00018-gf983cd3) I get a blank screen, with > no video signal, as soon as it tries to switch to a framebuffer. > > Comparing the logs, the first bad attempt had a couple of new error > messages, everything else in the logs looked normal - > > Mar 1 19:31:10 deluxe kernel: [2.543163] fbcon: radeondrmfb (fb0) is > primary device > Mar 1 19:31:10 deluxe kernel: [2.654179] [drm:radeon_dp_link_train] > *ERROR* clock recovery reached max voltage > Mar 1 19:31:10 deluxe kernel: [2.654181] [drm:radeon_dp_link_train] > *ERROR* clock recovery failed > Mar 1 19:31:10 deluxe kernel: [2.677142] Console: switching to colour > frame buffer device 200x56 > Mar 1 19:31:10 deluxe kernel: [2.680435] radeon :00:01.0: fb0: > radeondrmfb frame buffer device > Bisection pointed to 092c96a8ab9d1bd60ada2ed385cc364ce084180e is the first bad commit commit 092c96a8ab9d1bd60ada2ed385cc364ce084180e Author: Alex Deucher Date: Thu Dec 17 10:23:34 2015 -0500 drm/radeon: fix dp link rate selection (v2) Need to properly handle the max link rate in the dpcd. This prevents some cases where 5.4 Ghz is selected when it shouldn't be. v2: simplify logic, add array bounds check Reviewed-by: Tom St Denis Signed-off-by: Alex Deucher I have now reverted that commit from that version of linus's tree and the machine everything is back to normal. This mobo does not have a DP connector. lspci reports the graphics part is 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Kaveri [Radeon R7 Graphics] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0 ExtTag+ RBE+ DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: fee0f00c Data: 4172 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [270 v1] #19 Capabilities: [2b0 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable-, Smallest Translation Unit: 00 Capabilities: [2c0 v1] Page Request Interface (PRI) PRICtl: Enable- Reset- PRISta: RF- UPRGI- Stopped+ Page Request Capacity: 0020, Page Request Allocation: Capabilities: [2d0 v1] Process Address Space ID (PASID) PASIDCap: Exec- Priv-, Max PASID Width: 10 PASIDCtl: Enable- Exec- Priv- Kernel driver in use: radeon I've attached my config. Please let me know if there is anything I can do to help fix this. ĸen -- This email was written using 100% recycled letters. -- next part -- # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.5.0-rc6 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=28 CONFIG_ARCH_MMAP_RND_BITS_MAX=32 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHU
[PATCH] staging/android: add flags member to sync ioctl structs
On Thu, Mar 03, 2016 at 08:17:14AM -0800, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Play safe and add flags member to all structs. So we don't need to > > break API or create new IOCTL in the future if new features that requires > > flags arises. > > > > v2: check if flags are valid (zero, in this case) > > > > v3: return -EINVAL if flags are not zero'ed > > > > v4: add padding for 64-bit alignment > > > > v5: rebase to use only stacked sync_file_info > > Why are these vX things here in the changelog? That's how we usually roll in gpu land. -- Ville Syrjälä Intel OTC
[Bug 94387] Approx 35W more power usage in multi-screen
https://bugs.freedesktop.org/show_bug.cgi?id=94387 --- Comment #3 from Steve --- Created attachment 122106 --> https://bugs.freedesktop.org/attachment.cgi?id=122106&action=edit Xorg.0.log as requested -- 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/20160303/9072d3d0/attachment.html>
[Bug 94387] Approx 35W more power usage in multi-screen
https://bugs.freedesktop.org/show_bug.cgi?id=94387 --- Comment #2 from Steve --- Created attachment 122105 --> https://bugs.freedesktop.org/attachment.cgi?id=122105&action=edit dmesg output You are right - I notice: [3.055513] [drm] Loading BARTS Microcode [3.055579] [drm] Internal thermal controller with fan control [3.061488] [drm] radeon: dpm initialized This is interesting - as the fan sure works harder under the radeon driver than the fglrx - and you can feel the extra heat coming out the back of the card. Is there any further information I can supply re power levels on the card to try and see what causes the extra power / heat usage? -- 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/20160303/7a8e7080/attachment.html>
[PATCH] drm/amdgpu: delete set-but-not-read member has_uvd from amdgpu_device
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/cik.c| 2 --
drivers/gpu/drm/amd/amdgpu/vi.c | 4
3 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 0c42a85..cfd35b0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -2053,7 +2053,6 @@ struct amdgpu_device {
struct amdgpu_sdma sdma;
/* uvd */
- boolhas_uvd;
struct amdgpu_uvd uvd;
/* vce */
diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c
index 6b1f053..5da14a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik.c
@@ -2025,8 +2025,6 @@ static int cik_common_early_init(void *handle)
adev->asic_funcs = &cik_asic_funcs;
- adev->has_uvd = true;
-
adev->rev_id = cik_get_rev_id(adev);
adev->external_rev_id = 0xFF;
switch (adev->asic_type) {
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 1250035..9163f59 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1071,26 +1071,22 @@ static int vi_common_early_init(void *handle)
adev->external_rev_id = 0xFF;
switch (adev->asic_type) {
case CHIP_TOPAZ:
- adev->has_uvd = false;
adev->cg_flags = 0;
adev->pg_flags = 0;
adev->external_rev_id = 0x1;
break;
case CHIP_FIJI:
- adev->has_uvd = true;
adev->cg_flags = 0;
adev->pg_flags = 0;
adev->external_rev_id = adev->rev_id + 0x3c;
break;
case CHIP_TONGA:
- adev->has_uvd = true;
adev->cg_flags = 0;
adev->pg_flags = 0;
adev->external_rev_id = adev->rev_id + 0x14;
break;
case CHIP_CARRIZO:
case CHIP_STONEY:
- adev->has_uvd = true;
adev->cg_flags = 0;
/* Disable UVD pg */
adev->pg_flags = /* AMDGPU_PG_SUPPORT_UVD |
*/AMDGPU_PG_SUPPORT_VCE;
--
2.7.0
[PATCH] drm/amdgpu: cleanup or bug?
Hi! First time sending a patch to the list. This patch deletes a set-but-not-read member from the amdgpu_device struct but I'm not sure the correct thing is to delete it. Maybe it should be checked some where? BR Nils Nils Wallménius (1): drm/amdgpu: delete set-but-not-read member has_uvd from amdgpu_device drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - drivers/gpu/drm/amd/amdgpu/cik.c| 2 -- drivers/gpu/drm/amd/amdgpu/vi.c | 4 3 files changed, 7 deletions(-) -- 2.7.0
[PATCH 1/3] drm/omap: remove -Werror from Makefile
On 03/03/16 20:44, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Thursday 03 March 2016 16:01:16 Tomi Valkeinen wrote: >> Having -Werror in the omapdrm Makefile makes development and debugging a >> PITA. Let's remove it. > > Well, shouldn't we target having no warning ? :-) Yes, but we don't need to make errors of warnings to do that. I'm just too tired of trying to avoid warnings when doing new development or debugging or testing something. Too often I have wanted to comment out a line to test something, only to find out I need to comment out lots of other things too, just to get rid of "unused variable" warning. Or developing a new feature, knowing it's not ready but want to test it anyway, but even a single warning stops compilation. 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/20160303/56c7e3c6/attachment.sig>
[PATCH 1/3] drm/omap: remove -Werror from Makefile
Hi Tomi, Thank you for the patch. On Thursday 03 March 2016 16:01:16 Tomi Valkeinen wrote: > Having -Werror in the omapdrm Makefile makes development and debugging a > PITA. Let's remove it. Well, shouldn't we target having no warning ? :-) > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/omapdrm/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/omapdrm/Makefile > b/drivers/gpu/drm/omapdrm/Makefile index fe4c2228bc18..48b7b750c05c 100644 > --- a/drivers/gpu/drm/omapdrm/Makefile > +++ b/drivers/gpu/drm/omapdrm/Makefile > @@ -6,7 +6,7 @@ > obj-y += dss/ > obj-y += displays/ > > -ccflags-y := -Iinclude/drm -Werror > +ccflags-y := -Iinclude/drm > omapdrm-y := omap_drv.o \ > omap_irq.o \ > omap_debugfs.o \ -- Regards, Laurent Pinchart
[GIT PULL] drm-vc4-fixes-2016-03-03
This is pretty late, and since it's not regressions, I won't be at all surprised if you want to pull this into -next instead. I could rebase it back to -rc3 if you want it for -next. The following changes since commit 81f70ba233d5f660e1ea5fe23260ee323af5d53a: Linux 4.5-rc5 (2016-02-20 13:39:35 -0800) are available in the git repository at: git at github.com:anholt/linux.git tags/drm-vc4-fixes-2016-03-03 for you to fetch changes up to 6a609209865247cc748e90158c99f374f79b494c: drm/vc4: Initialize scaler DISPBKGND on modeset. (2016-02-26 17:42:48 -0800) This pull request fixes the major VC4 HDMI modesetting bugs found when the first wave of users showed up in Raspbian. Eric Anholt (6): drm/vc4: Fix a framebuffer reference leak on async flip interrupt. drm/vc4: Bring HDMI up from power off if necessary. drm/vc4: Add another reg to HDMI debug dumping. drm/vc4: Fix the name of the VSYNCD_EVEN register. drm/vc4: Fix setting of vertical timings in the CRTC. drm/vc4: Initialize scaler DISPBKGND on modeset. drivers/gpu/drm/vc4/vc4_crtc.c | 19 ++- drivers/gpu/drm/vc4/vc4_hdmi.c | 30 +- drivers/gpu/drm/vc4/vc4_regs.h | 18 +- 3 files changed, 64 insertions(+), 3 deletions(-)
[PATCH] staging/android: change IOCTLs opcode after ABI change
From: Gustavo Padovan
Burn the old opcode to avoid any potential old userspace running the old
API to get weird errors. Changing the opcodes will make them fail right
away.
This is just a precaution, there no upstream users of these interfaces
yet and the only user is Android, but we don't expect anyone trying to
run android userspace and all it dependencies on top of upstream kernels.
Moreover Android should be converted to use upstream sync_files.
Suggested-by: Rob Clark
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/uapi/sync.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/uapi/sync.h
b/drivers/staging/android/uapi/sync.h
index 859977c..fbadb8a 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -69,13 +69,20 @@ struct sync_file_info {
#define SYNC_IOC_MAGIC '>'
/**
+ * Opcodes 0, 1 and 2 were burned during a API change to avoid users of the
+ * old API to get weird errors when trying to handling sync_files. The API
+ * change happened during the de-stage of the Sync Framework when there was
+ * no upstream users available.
+ */
+
+/**
* DOC: SYNC_IOC_MERGE - merge two fences
*
* Takes a struct sync_merge_data. Creates a new fence containing copies of
* the sync_pts in both the calling fd and sync_merge_data.fd2. Returns the
* new fence's fd in sync_merge_data.fence
*/
-#define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 1, struct sync_merge_data)
+#define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
/**
* DOC: SYNC_IOC_FENCE_INFO - get detailed information on a fence
@@ -88,6 +95,6 @@ struct sync_file_info {
* pt_info is a buffer containing sync_pt_infos for every sync_pt in the fence.
* To iterate over the sync_pt_infos, use the sync_pt_info.len field.
*/
-#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)
+#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info)
#endif /* _UAPI_LINUX_SYNC_H */
--
2.5.0
[PATCH] MAINTAINERS: update radeon entry to include amdgpu as well
Am 03.03.2016 um 17:53 schrieb Thierry Reding: > On Thu, Mar 03, 2016 at 11:50:54AM -0500, Alex Deucher wrote: >> Both are maintained by same team. >> >> Signed-off-by: Alex Deucher >> --- >> MAINTAINERS | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) > Thanks for doing this. scripts/get_maintainer.pl output will be much > more useful with this. > > Acked-by: Thierry Reding Yeah, that was also still on my todo list, thanks for getting that done. Reviewed-by: Christian König Regards, Christian. > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/3b333417/attachment.html>
Two kangaroo
First Kangaroo: What does a frog say when it washes car windows? Second Kangaroo: Rub it, rub it, rub it. https://lists.freedesktop.org/archives/dri-devel/2016-January/097945.html https://patchwork.freedesktop.org/patch/65722 https://bugzilla.redhat.com/show_bug.cgi?id=1295646 It's been more than 100 sunsets, Mister Crocodile Dundee, care to throw a boomerang, finally?
[PATCH] dma-buf/fence: fix fence_is_later v2
Hi Alex, On 29 February 2016 at 21:23, Alex Deucher wrote: > From: Christian König > > A fence is never later than itself. This caused a bunch of overhead for > AMDGPU. > Thanks; added to for-next. > v2: simplify check as suggested by Michel. > Best regards, ~Sumit.
[PATCH] MAINTAINERS: update radeon entry to include amdgpu as well
On Thu, Mar 03, 2016 at 11:50:54AM -0500, Alex Deucher wrote: > Both are maintained by same team. > > Signed-off-by: Alex Deucher > --- > MAINTAINERS | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Thanks for doing this. scripts/get_maintainer.pl output will be much more useful with this. Acked-by: Thierry Reding -- 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/20160303/adb76513/attachment.sig>
[Intel-gfx] [PATCH v3 6/7] drm/atomic: Clean up steal_encoder, v2.
Hi Maarten,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20160303]
[cannot apply to v4.5-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Maarten-Lankhorst/drm-atomic-Fix-encoder-stealing-v3/20160303-172123
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x014-201609 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/drm_atomic_helper.c: In function 'update_connector_routing':
>> drivers/gpu/drm/drm_atomic_helper.c:268:11: warning: unused variable 'ret'
>> [-Wunused-variable]
int idx, ret;
^
vim +/ret +268 drivers/gpu/drm/drm_atomic_helper.c
c6c869e2 Maarten Lankhorst 2016-03-03 252
c6c869e2 Maarten Lankhorst 2016-03-03 253 crtc_state =
drm_atomic_get_existing_crtc_state(state, encoder_crtc);
c6c869e2 Maarten Lankhorst 2016-03-03 254
crtc_state->connectors_changed = true;
c6c869e2 Maarten Lankhorst 2016-03-03 255
49bf38f8 Maarten Lankhorst 2016-03-03 256 return;
623369e5 Daniel Vetter 2014-09-16 257 }
623369e5 Daniel Vetter 2014-09-16 258 }
623369e5 Daniel Vetter 2014-09-16 259
623369e5 Daniel Vetter 2014-09-16 260 static int
184a4cc1 Maarten Lankhorst 2016-03-03 261 update_connector_routing(struct
drm_atomic_state *state,
184a4cc1 Maarten Lankhorst 2016-03-03 262 struct
drm_connector *connector,
184a4cc1 Maarten Lankhorst 2016-03-03 263 struct
drm_connector_state *connector_state)
623369e5 Daniel Vetter 2014-09-16 264 {
b5ceff20 Ville Syrjälä 2015-03-10 265const struct
drm_connector_helper_funcs *funcs;
623369e5 Daniel Vetter 2014-09-16 266 struct drm_encoder *new_encoder;
623369e5 Daniel Vetter 2014-09-16 267 struct drm_crtc_state
*crtc_state;
623369e5 Daniel Vetter 2014-09-16 @268 int idx, ret;
623369e5 Daniel Vetter 2014-09-16 269
17a38d9c Daniel Vetter 2015-02-22 270 DRM_DEBUG_ATOMIC("Updating
routing for [CONNECTOR:%d:%s]\n",
623369e5 Daniel Vetter 2014-09-16 271
connector->base.id,
623369e5 Daniel Vetter 2014-09-16 272
connector->name);
623369e5 Daniel Vetter 2014-09-16 273
623369e5 Daniel Vetter 2014-09-16 274 if (connector->state->crtc !=
connector_state->crtc) {
623369e5 Daniel Vetter 2014-09-16 275 if
(connector->state->crtc) {
623369e5 Daniel Vetter 2014-09-16 276 idx =
drm_crtc_index(connector->state->crtc);
:: The code at line 268 was first introduced by commit
:: 623369e533e8a5f85999d605723efa4523554bae drm: Atomic crtc/connector
updates using crtc/plane helper interfaces
:: TO: Daniel Vetter
:: CC: Daniel Vetter
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 21254 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160303/1e4c75c9/attachment-0001.obj>
[PATCH 1/4 v2] drm: Add support of ARC PGU display controller
ARC PGU could be found on some development boards from Synopsys.
This is a simple byte streamer that reads data from a framebuffer
and sends data to the single encoder.
Signed-off-by: Alexey Brodkin
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-snps-arc at lists.infradead.org
---
No changes since v1.
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/arc/Kconfig | 10 ++
drivers/gpu/drm/arc/Makefile | 2 +
drivers/gpu/drm/arc/arcpgu.h | 47 +++
drivers/gpu/drm/arc/arcpgu_crtc.c | 274 ++
drivers/gpu/drm/arc/arcpgu_drv.c | 239 +
drivers/gpu/drm/arc/arcpgu_hdmi.c | 204
drivers/gpu/drm/arc/arcpgu_regs.h | 36 +
9 files changed, 815 insertions(+)
create mode 100644 drivers/gpu/drm/arc/Kconfig
create mode 100644 drivers/gpu/drm/arc/Makefile
create mode 100644 drivers/gpu/drm/arc/arcpgu.h
create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c
create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c
create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c
create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 08706f0..654a9cb 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -279,3 +279,5 @@ source "drivers/gpu/drm/imx/Kconfig"
source "drivers/gpu/drm/vc4/Kconfig"
source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/arc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6eb94fc..c338d04 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -78,3 +78,4 @@ obj-y += panel/
obj-y += bridge/
obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-$(CONFIG_DRM_ARCPGU)+= arc/
diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
new file mode 100644
index 000..f9a13b6
--- /dev/null
+++ b/drivers/gpu/drm/arc/Kconfig
@@ -0,0 +1,10 @@
+config DRM_ARCPGU
+ tristate "ARC PGU"
+ depends on DRM && OF
+ select DRM_KMS_CMA_HELPER
+ select DRM_KMS_FB_HELPER
+ select DRM_KMS_HELPER
+ help
+ Choose this option if you have an ARC PGU controller.
+
+ If M is selected the module will be called arcpgu.
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
new file mode 100644
index 000..d48fda7
--- /dev/null
+++ b/drivers/gpu/drm/arc/Makefile
@@ -0,0 +1,2 @@
+arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_drv.o
+obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
new file mode 100644
index 000..d6a5cf5
--- /dev/null
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -0,0 +1,47 @@
+/*
+ * ARC PGU DRM driver.
+ *
+ * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * 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.
+ *
+ */
+
+#ifndef _ARCPGU_H_
+#define _ARCPGU_H_
+
+struct arcpgu_drm_private {
+ void __iomem*regs;
+ struct clk *clk;
+ struct drm_fbdev_cma*fbdev;
+ struct drm_framebuffer *fb;
+ struct list_headevent_list;
+ struct drm_crtc crtc;
+ struct drm_plane*plane;
+};
+
+#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, crtc)
+
+static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
+unsigned int reg, u32 value)
+{
+ iowrite32(value, arcpgu->regs + reg);
+}
+
+static inline u32 arc_pgu_read(struct arcpgu_drm_private *arcpgu,
+ unsigned int reg)
+{
+ return ioread32(arcpgu->regs + reg);
+}
+
+int arc_pgu_setup_crtc(struct drm_device *dev);
+int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np);
+
+#endif
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
new file mode 100644
index 000..0fe5c8a
--- /dev/null
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -0,0 +1,274 @@
+/*
+ * ARC PGU DRM driver.
+ *
+ * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * 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 PURPO
[PATCH 0/4 v2] drm: Add support of ARC PGU display controller
This series add support of ARC PGU display controller. ARC PGU is a quite simple byte streamer that gets data from the framebuffer and pushes it to hte connected encoder (DP or HDMI). It was tested on ARC SDP boards (axs101 in particular). Changes v1 -> v2: * Clean-up of DT bindings documentation * Added missing "pxlclk" clock in axs10x_mb.dtsi Cc: David Airlie Cc: devicetree at vger.kernel.org Cc: dri-devel at lists.freedesktop.org Cc: Ian Campbell Cc: Kumar Gala Cc: linux-snps-arc at lists.infradead.org Cc: Mark Rutland Cc: Pawel Moll Cc: Rob Herring Cc: Vineet Gupta Alexey Brodkin (4): drm: Add support of ARC PGU display controller drm: Add DT bindings documentation for ARC PGU display controller arc: axs10x - add support of ARC PGU MAINTAINERS: Add maintainer for ARC PGU display controller .../devicetree/bindings/display/snps,arcpgu.txt| 33 +++ MAINTAINERS| 6 + arch/arc/boot/dts/axs10x_mb.dtsi | 61 + drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/arc/Kconfig| 10 + drivers/gpu/drm/arc/Makefile | 2 + drivers/gpu/drm/arc/arcpgu.h | 47 drivers/gpu/drm/arc/arcpgu_crtc.c | 274 + drivers/gpu/drm/arc/arcpgu_drv.c | 239 ++ drivers/gpu/drm/arc/arcpgu_hdmi.c | 204 +++ drivers/gpu/drm/arc/arcpgu_regs.h | 36 +++ 12 files changed, 915 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt create mode 100644 drivers/gpu/drm/arc/Kconfig create mode 100644 drivers/gpu/drm/arc/Makefile create mode 100644 drivers/gpu/drm/arc/arcpgu.h create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h -- 2.5.0
[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field
On Thu, Mar 03, 2016 at 03:40:56PM +0100, Fabien DESSENNE wrote: > > On 03/03/2016 02:33 PM, Ville Syrjälä wrote: > > On Thu, Mar 03, 2016 at 02:28:38PM +0100, Fabien DESSENNE wrote: > >> > >> On 03/03/2016 12:28 PM, Ville Syrjälä wrote: > >>> On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote: > Hi Ville, > > Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes > that the userland controls the field presentation on the display output. > This assumes that the userland is aware of the field actually on display > and I think that this information is not provided by the DRM framework. > Moreover the field management is something very close to the HW and I do > not think that this shall be managed at userland level. > >>> Userland is the only one that knows how the data is to be presented, so > >>> I don't understand your comment. Userland is the one that would set your > >>> fb flag too. > >> Sure, the flag is under userland control. > >> In the two options I am comparing, this flag is set. But in different ways: > >> A/ either the userland sets DRM_MODE_PRESENT_TOP_FIELD to display the > >> top field, then sets DRM_MODE_PRESENT_BOTTOM_FIELD to display the bottom > >> field. (2 PageFlip calls) > > No, in case of actual interlaced scanout the these flags would in fact > > mean TFF or BFF. > > My natural and initial understanding of PRESENT_TOP_FIELD is "present > top field *only*". > Since these flags are not verbosely documented (and not used in any > driver?), I did not catch that it may also mean "present top field *first*" > > So considering this statement, I have a better understanding of what you > mean and it looks like there are no real difference between the two > compared options. At least for the interlaced scanout case. > > > You would only use two pageflips for bob deinterlacing. > For the bob deinterlacing case (progressive scanout) it is a bit > different. But well, no so different. > > > So focusing back to the initial difference which is about what the flag > marks (SetPlane vs fb): > DRM_MODE_FB_BFF is a fb flag. The fb can be used in SetPlane, PageFlip > or SetCrtc calls. > Since DRM_MODE_PRESENT_TOP_FIELD is a drm_mode_set_plane flag I do not > see how we can specify the top/bottom field order in a PageFlip call. It's all a bit moot since these are legacy APIs and we shouldn't probably worry about them too much. All that really matters IMO is atomic. For atomic we need either a few fb flags which could work for interlaced scanout allowing you to specify tff/bff/any, but as stated this would then force you to create a second fb if you missed your deadline for the first field and want to present the second field instead. But maybe people don't care about deadlines that much? For the bob deinterlacing we would definitely need some new plane property. I'm not sure how we'd handle cases where the hardware has some more fancy adaptive deinterlacing mechanism that can use weave/bob/something else as needed. I guess it could work with the same kind of property where the flip to the second field could essentially become a nop in case the hardware chose to use weave/etc. when the first field got presented. The other option is providing both fields with the same flip, but then we'd need to add some kind of target framecount/deadline for presenting the second field. > > >> B/ either, the userland sets DRM_MODE_FB_BFF for a single frame, and > >> lets the driver display the two fields (1 PageFlip call) > > Well, this would rather be N fields, because the scanout being > > interlaced it will keep alternating between the two fields until another > > flip is performed. > As an alternative approach, the field management can be transparent to > the userland, letting the driver doing the job. This is how the STI > driver works: when handling an interlaced buffer it displays top and > bottom fields at the right time, synchronized with the VSYNC signal > (vsync for top field / vsync for btm field). The usage of the atomic > mode is transparent for this processing. > >>> We can do that on most hardware without specific hardware assist. Well, > >>> to be precise we can present the first field correctly, but the > >>> second/third field will only be presented correctly if the output > >>> refresh rate matches the intended refresh rate for the input data. > >>> But any hardware assist would have the same problem as well. > >>> > Clearly, the two methods are very different. > >>> Not from where I'm sitting. > >>> > The proposed patch fits with the second one. > > BR > Fabien > > On 02/29/2016 09:41 PM, Ville Syrjälä wrote: > > On Fri, Feb 12, 2016 at 10:26:03AM +0100, Vincent Abriou wrote: > >> Interlaced video can have different scan order: > >> Top Field First or Bottom Field First > >> > >> In case of video with interlaced content,
[PATCH] staging/android: add flags member to sync ioctl structs
On Thu, Mar 3, 2016 at 3:54 PM, Rob Clark wrote: > On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman > wrote: >> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: >>> From: Gustavo Padovan >>> >>> Play safe and add flags member to all structs. So we don't need to >>> break API or create new IOCTL in the future if new features that requires >>> flags arises. >>> >>> v2: check if flags are valid (zero, in this case) >>> >>> v3: return -EINVAL if flags are not zero'ed >>> >>> v4: add padding for 64-bit alignment >>> >>> v5: rebase to use only stacked sync_file_info >> >> Why are these vX things here in the changelog? >> >> And you just broke all existing userspace users of this code, why are >> you allowed to do that? >> >> not ok... > > There are not really any users of this on an upstream kernel yet, so > it makes sense to fix the ABI to something we can live with now, > before that changes. If we are stuck not breaking ABI with android > stuff pulled into staging as we destage it, then maybe we should be a > *lot* slower at pulling android stuff into staging. (Ie. if that is > the case, please kick it all out now and we'll re-add things > properly.) That all said, I suppose one sensible concession to practicality would be to burn the old ioctl numbers and pick new ioctl numbers. At least this way if someone did manage to take an old android userspace (with it's various dependencies on other non-upstream SoC specific platform drivers, etc) and run it on upstream kernel, at least things would fail in an obvious way. I could live with this as the mode-of-operations for fixing up and destaging staging/android stuff. BR, -R
[PATCH] staging/android: add flags member to sync ioctl structs
2016-03-03 Gustavo Padovan : > Hi Greg, > > 2016-03-03 Greg Kroah-Hartman : > > > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan > > > > > > Play safe and add flags member to all structs. So we don't need to > > > break API or create new IOCTL in the future if new features that requires > > > flags arises. > > > > > > v2: check if flags are valid (zero, in this case) > > > > > > v3: return -EINVAL if flags are not zero'ed > > > > > > v4: add padding for 64-bit alignment > > > > > > v5: rebase to use only stacked sync_file_info > > > > Why are these vX things here in the changelog? > > There are few people who does this in drm, so I just followed that. Anyway, I've sent v7 without the vX things in the changelog. Gustavo
[PATCH v7 5/5] staging/android: add flags member to sync ioctl structs
From: Gustavo Padovan
Play safe and add flags member to all structs. So we don't need to
break API or create new IOCTL in the future if new features that requires
flags arises.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
v2: check if flags are valid (zero, in this case)
v3: return -EINVAL if flags are not zero'ed
v4: add padding for 64-bit alignment
v5: rebase to use only stacked sync_file_info
---
drivers/staging/android/sync.c | 8
drivers/staging/android/uapi/sync.h | 14 --
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 48ee175..ae81c95 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file
*sync_file,
goto err_put_fd;
}
+ if (data.flags || data.pad) {
+ err = -EINVAL;
+ goto err_put_fd;
+ }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -504,6 +509,9 @@ static long sync_file_ioctl_fence_info(struct sync_file
*sync_file,
if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
return -EFAULT;
+ if (info.flags || info.pad)
+ return -EINVAL;
+
/*
* Passing num_fences = 0 means that userspace doesn't want to
* retrieve any sync_fence_info. If num_fences = 0 we skip filling
diff --git a/drivers/staging/android/uapi/sync.h
b/drivers/staging/android/uapi/sync.h
index a122bb5..859977c 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -16,14 +16,18 @@
/**
* struct sync_merge_data - data passed to merge ioctl
- * @fd2: file descriptor of second fence
* @name: name of new fence
+ * @fd2: file descriptor of second fence
* @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
+ * @pad: padding for 64-bit alignment, should always be zero
*/
struct sync_merge_data {
- __s32 fd2;
charname[32];
+ __s32 fd2;
__s32 fence;
+ __u32 flags;
+ __u32 pad;
};
/**
@@ -31,12 +35,14 @@ struct sync_merge_data {
* @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
+ * @flags: fence_info flags
* @timestamp_ns: timestamp of status change in nanoseconds
*/
struct sync_fence_info {
charobj_name[32];
chardriver_name[32];
__s32 status;
+ __u32 flags;
__u64 timestamp_ns;
};
@@ -44,14 +50,18 @@ struct sync_fence_info {
* struct sync_file_info - data returned from fence info ioctl
* @name: name of fence
* @status:status of fence. 1: signaled 0:active <0:error
+ * @flags: sync_file_info flags
* @num_fences number of fences in the sync_file
+ * @pad: padding for 64-bit alignment, should always be zero
* @sync_fence_info: pointer to array of structs sync_fence_info with all
* fences in the sync_file
*/
struct sync_file_info {
charname[32];
__s32 status;
+ __u32 flags;
__u32 num_fences;
+ __u32 pad;
__u64 sync_fence_info;
};
--
2.5.0
[PATCH v7 4/5] staging/android: refactor SYNC_IOC_FILE_INFO
From: Gustavo Padovan
Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.
However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.
Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.
Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.
Also, info->sync_fence_info was converted to __u64 pointer to prevent
32bit compatibility issues.
An example userspace code for the later would be:
struct sync_file_info *info;
int err, size, num_fences;
info = malloc(sizeof(*info));
info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;
if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
sizeof(struct
sync_fence_info));
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
v2: fix fence_info memory leak
v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()
Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size
Comments from Dan Carpenter
- fix info->sync_fence_info documentation
v4: remove allocated struct sync_file_info (comment from Maarten)
---
drivers/staging/android/sync.c | 70 +
drivers/staging/android/uapi/sync.h | 9 ++---
2 files changed, 36 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index dc5f382..48ee175 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -479,13 +479,9 @@ err_put_fd:
return err;
}
-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+ struct sync_fence_info *info)
{
- struct sync_fence_info *info = data;
-
- if (size < sizeof(*info))
- return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,60 +491,60 @@ static int sync_fill_fence_info(struct fence *fence, void
*data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
- return sizeof(*info);
}
static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
{
- struct sync_file_info *info;
+ struct sync_file_info info;
+ struct sync_fence_info *fence_info = NULL;
__u32 size;
- __u32 len = 0;
int ret, i;
- if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+ if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
return -EFAULT;
- if (size < sizeof(struct sync_file_info))
- return -EINVAL;
+ /*
+* Passing num_fences = 0 means that userspace doesn't want to
+* retrieve any sync_fence_info. If num_fences = 0 we skip filling
+* sync_fence_info and return the actual number of fences on
+* info->num_fences.
+*/
+ if (!info.num_fences)
+ goto no_fences;
- if (size > 4096)
- size = 4096;
+ if (info.num_fences < sync_file->num_fences)
+ return -EINVAL;
- info = kzalloc(size, GFP_KERNEL);
- if (!info)
+ size = sync_file->num_fences * sizeof(*fence_info);
+ fence_info = kzalloc(size, GFP_KERNEL);
+ if (!fence_info)
return -ENOMEM;
- strlcpy(info->name, sync_file->name, sizeof(info->name));
- info->status = atomic_read(&sync_file->status);
- if (info->status >= 0)
- info->status = !info->status;
+ for (i = 0; i < sync_file->num_fences; ++i)
+ sync_fill_fence_info(sync_file->cbs[i].fence, &fence_info[i]);
- info->num_fences = sync_file->nu
[PATCH v7 3/5] 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
---
drivers/staging/android/uapi/sync.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/uapi/sync.h
b/drivers/staging/android/uapi/sync.h
index dd0dd84..f0b41ce 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -21,9 +21,9 @@
* @fence: returns the fd of the new fence to userspace
*/
struct sync_merge_data {
- __s32 fd2; /* fd of second fence */
- charname[32]; /* name of new fence */
- __s32 fence; /* fd on newly created fence */
+ __s32 fd2;
+ charname[32];
+ __s32 fence;
};
/**
--
2.5.0
[PATCH v7 2/5] staging/android: rename SYNC_IOC_FENCE_INFO
From: Gustavo Padovan
We don't use the 'fence' name to refer to sync_file anymore. So rename it
to SYNC_IOC_FILE_INFO.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
drivers/staging/android/sync.c | 2 +-
drivers/staging/android/uapi/sync.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 31aa462..dc5f382 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -562,7 +562,7 @@ static long sync_file_ioctl(struct file *file, unsigned int
cmd,
case SYNC_IOC_MERGE:
return sync_file_ioctl_merge(sync_file, arg);
- case SYNC_IOC_FENCE_INFO:
+ case SYNC_IOC_FILE_INFO:
return sync_file_ioctl_fence_info(sync_file, arg);
default:
diff --git a/drivers/staging/android/uapi/sync.h
b/drivers/staging/android/uapi/sync.h
index 4ffb7cc..dd0dd84 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -81,6 +81,6 @@ struct sync_file_info {
* pt_info is a buffer containing sync_pt_infos for every sync_pt in the fence.
* To iterate over the sync_pt_infos, use the sync_pt_info.len field.
*/
-#define SYNC_IOC_FENCE_INFO_IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)
+#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)
#endif /* _UAPI_LINUX_SYNC_H */
--
2.5.0
[PATCH v7 1/5] staging/android: add num_fences field to struct sync_file_info
From: Gustavo Padovan
Inform userspace how many fences are in the sync_fence_info field.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
drivers/staging/android/sync.c | 2 ++
drivers/staging/android/uapi/sync.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..31aa462 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -525,6 +525,8 @@ static long sync_file_ioctl_fence_info(struct sync_file
*sync_file,
if (info->status >= 0)
info->status = !info->status;
+ info->num_fences = sync_file->num_fences;
+
len = sizeof(struct sync_file_info);
for (i = 0; i < sync_file->num_fences; ++i) {
diff --git a/drivers/staging/android/uapi/sync.h
b/drivers/staging/android/uapi/sync.h
index a0cf357..4ffb7cc 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -47,12 +47,14 @@ struct sync_fence_info {
* userspace including pt_info.
* @name: name of fence
* @status:status of fence. 1: signaled 0:active <0:error
+ * @num_fences number of fences in the sync_file
* @sync_fence_info: array of sync_fence_info for every fence in the sync_file
*/
struct sync_file_info {
__u32 len;
charname[32];
__s32 status;
+ __u32 num_fences;
__u8sync_fence_info[0];
};
--
2.5.0
[pull] drm/msm: msm-next for 4.6
Hi Dave, Big ticket items are hdmi support for 8996 (aka snapdragon 820), and adreno 430 support. Also one more small uapi addition to support timestamp queries. The following changes since commit d2eaa59000c7717e68a75cf2c106f056d2bc30b4: Merge branch 'drm-rockchip-next-2016-02-18' of https://github.com/markyzq/kernel-drm-rockchip into drm-next (2016-02-19 13:10:18 +1000) are available in the git repository at: git://people.freedesktop.org/~robclark/linux msm-next for you to fetch changes up to fcda50c8f484cf1140232c870449f0619db9: drm/msm: rename hdmi symbols (2016-03-03 11:55:33 -0500) Archit Taneja (15): drm/msm/hdmi: Clean up connector gpio usage drm/msm/hdmi: Fix connector detect when there is no HPD gpio drm/msm/hdmi: Create a separate HDMI PHY driver drm/msm/hdmi: Manage HDMI PLL through PHY driver drm/msm/hdmi: Make HDMI core get its PHY drm/msm/hdmi: Convert PHY files according to new design drm/msm/hdmi: Update generated headers to split PHY/PLL offsets drm/msm/hdmi: Update generated headers for HDMI 8996 PHY drm/msm/hdmi: HDMI 8996 PHY/PLL support dt-bindings: msm/hdmi: Add HDMI PHY bindings drm/msm/mdp: Use atomic helper to set crtc property drm/msm: Free fb helper resources in msm_unload drm/msm/dsi: Remove incorrect warning on host attach drm/msm/dsi: Drop VDD regulator for MSM8916 drm/msm/dsi: Parse DSI lanes via DT Arnd Bergmann (1): drm/msm: rename hdmi symbols Craig Stout (4): drm/msm/adreno: support for adreno 430. drm/msm/adreno: add adreno430 power control drm/msm/adreno: get CP_RPTR from register instead of shadow memory drm/msm/adreno: print details in case of a protect fault interrupt Luis Henriques (1): drm/msm/dsi: fix definition of msm_dsi_pll_28nm_8960_init() Rob Clark (7): drm/msm: make iommu port names const'ier drm/msm: update generated headers drm/msm: reject submit ioctl if no gpu drm/msm: grab struct_mutex after allocating submit drm/msm: fix small typo drm/msm: add timestamp param drm/msm/adreno: remove duplicate adreno_hw_init() call Sricharan R (1): drm/msm/mdp: Detach iommu in mdp4_destroy .../devicetree/bindings/display/msm/dsi.txt| 32 +- .../devicetree/bindings/display/msm/hdmi.txt | 46 +- drivers/gpu/drm/msm/Makefile |3 + drivers/gpu/drm/msm/adreno/a2xx.xml.h | 11 +- drivers/gpu/drm/msm/adreno/a3xx.xml.h | 493 +++- drivers/gpu/drm/msm/adreno/a4xx.xml.h | 1267 +++- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 108 +- drivers/gpu/drm/msm/adreno/adreno_common.xml.h | 30 +- drivers/gpu/drm/msm/adreno/adreno_device.c |8 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 41 +- drivers/gpu/drm/msm/adreno/adreno_gpu.h|6 + drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h| 48 +- drivers/gpu/drm/msm/dsi/dsi.xml.h |5 +- drivers/gpu/drm/msm/dsi/dsi_cfg.c |3 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 118 +- drivers/gpu/drm/msm/dsi/mmss_cc.xml.h |5 +- drivers/gpu/drm/msm/dsi/pll/dsi_pll.h |4 +- drivers/gpu/drm/msm/dsi/sfpb.xml.h |5 +- drivers/gpu/drm/msm/edp/edp.xml.h |5 +- drivers/gpu/drm/msm/hdmi/hdmi.c| 174 +-- drivers/gpu/drm/msm/hdmi/hdmi.h| 110 +- drivers/gpu/drm/msm/hdmi/hdmi.xml.h| 647 -- drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 10 +- drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 56 +- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 172 +-- drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c | 166 +-- drivers/gpu/drm/msm/hdmi/hdmi_i2c.c| 20 +- drivers/gpu/drm/msm/hdmi/hdmi_phy.c| 230 drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c | 503 +--- drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 766 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 196 ++- drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c | 94 +- drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c | 461 +++ drivers/gpu/drm/msm/hdmi/qfprom.xml.h |5 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h|5 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c |9 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 19 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h|1 + drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h|5 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c |9 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c|2 +- drivers/gpu/drm/msm/mdp/mdp_common.xml.h |5 +- drivers/gpu/
[PATCH] staging/android: add flags member to sync ioctl structs
Hi Greg, 2016-03-03 Greg Kroah-Hartman : > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Play safe and add flags member to all structs. So we don't need to > > break API or create new IOCTL in the future if new features that requires > > flags arises. > > > > v2: check if flags are valid (zero, in this case) > > > > v3: return -EINVAL if flags are not zero'ed > > > > v4: add padding for 64-bit alignment > > > > v5: rebase to use only stacked sync_file_info > > Why are these vX things here in the changelog? There are few people who does this in drm, so I just followed that. > > And you just broke all existing userspace users of this code, why are > you allowed to do that? Because we've discussed this extensively in the last versions of this patches. Most of the people from CC agreed with it. We are cleaning up the Android sync and coming up with a better ABI for it before we de-stage it. Android people agreed with this and we will patch it. Gustavo
[Intel-gfx] [PATCH] drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW
On Mon, 29 Feb 2016 15:39:53 +0100,
Jani Nikula wrote:
>
> On Mon, 29 Feb 2016, Martin Kepplinger wrote:
> > Am 2016-02-26 um 20:59 schrieb Takashi Iwai:
> >> Sorry, Cc to Jani was missing mistakenly.
> >>
> >> Please check this. It's a regression in 4.5-rc.
> >>
> >>
> >> thanks,
> >>
> >> Takashi
> >>
> >
> > I can confirm that with -rc6 nothing changed and this fixes audio over
> > HDMI for me. I added David Airlie and dri-devel to CC aswell and hope
> > that this can go in for 4.5 in the last minute.
>
> I'll pick this up when we get the CI results. (This had fallen between
> the cracks...)
As far as looking at linux-next, this one still seems remaining in the
crevasse...
thanks,
Takashi
>
> BR,
> Jani.
>
>
>
> >
> > thanks
> > martin
> >
> >
> >> On Wed, 24 Feb 2016 15:35:22 +0100,
> >> Takashi Iwai wrote:
> >>>
> >>> The recent commit [0bdf5a05647a: drm/i915: Add reverse mapping between
> >>> port and intel_encoder] introduced a reverse mapping to retrieve
> >>> intel_dig_port object from the port number. The code assumed that the
> >>> port vs intel_dig_port are 1:1 mapping. But in reality, this was a
> >>> too naive assumption.
> >>>
> >>> As Martin reported about the missing HDMI audio on his SNB machine,
> >>> pre-HSW chips may have multiple intel_dig_port objects corresponding
> >>> to the same port. Since we assign the mapping statically at the init
> >>> time and the multiple objects override the map, it may not match with
> >>> the actually enabled output.
> >>>
> >>> This patch tries to address the regression above. The reverse mapping
> >>> is provided basically only for the audio callbacks, so now we set /
> >>> clear the mapping dynamically at enabling and disabling HDMI/DP audio,
> >>> so that we can always track the latest and correct object
> >>> corresponding to the given port.
> >>>
> >>> Fixes: 0bdf5a05647a ('drm/i915: Add reverse mapping between port and
> >>> intel_encoder')
> >>> Reported-and-tested-by: Martin Kepplinger
> >>> Signed-off-by: Takashi Iwai
> >>> ---
> >>> drivers/gpu/drm/i915/intel_audio.c | 3 +++
> >>> drivers/gpu/drm/i915/intel_ddi.c | 1 -
> >>> drivers/gpu/drm/i915/intel_dp.c| 1 -
> >>> drivers/gpu/drm/i915/intel_hdmi.c | 2 --
> >>> 4 files changed, 3 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> >>> b/drivers/gpu/drm/i915/intel_audio.c
> >>> index 31f6d212fb1b..30f921421b0c 100644
> >>> --- a/drivers/gpu/drm/i915/intel_audio.c
> >>> +++ b/drivers/gpu/drm/i915/intel_audio.c
> >>> @@ -527,6 +527,8 @@ void intel_audio_codec_enable(struct intel_encoder
> >>> *intel_encoder)
> >>>
> >>> mutex_lock(&dev_priv->av_mutex);
> >>> intel_dig_port->audio_connector = connector;
> >>> + /* referred in audio callbacks */
> >>> + dev_priv->dig_port_map[port] = intel_encoder;
> >>> mutex_unlock(&dev_priv->av_mutex);
> >>>
> >>> if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> >>> @@ -554,6 +556,7 @@ void intel_audio_codec_disable(struct intel_encoder
> >>> *intel_encoder)
> >>>
> >>> mutex_lock(&dev_priv->av_mutex);
> >>> intel_dig_port->audio_connector = NULL;
> >>> + dev_priv->dig_port_map[port] = NULL;
> >>> mutex_unlock(&dev_priv->av_mutex);
> >>>
> >>> if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> >>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> >>> b/drivers/gpu/drm/i915/intel_ddi.c
> >>> index 54a165b9c92d..a50fc452d5f1 100644
> >>> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >>> @@ -3312,7 +3312,6 @@ void intel_ddi_init(struct drm_device *dev, enum
> >>> port port)
> >>> intel_encoder->get_config = intel_ddi_get_config;
> >>>
> >>> intel_dig_port->port = port;
> >>> - dev_priv->dig_port_map[port] = intel_encoder;
> >>> intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
> >>> (DDI_BUF_PORT_REVERSAL |
> >>> DDI_A_4_LANES);
> >>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >>> b/drivers/gpu/drm/i915/intel_dp.c
> >>> index 1bbd67b046da..acf918728492 100644
> >>> --- a/drivers/gpu/drm/i915/intel_dp.c
> >>> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >>> @@ -6035,7 +6035,6 @@ intel_dp_init(struct drm_device *dev,
> >>> }
> >>>
> >>> intel_dig_port->port = port;
> >>> - dev_priv->dig_port_map[port] = intel_encoder;
> >>> intel_dig_port->dp.output_reg = output_reg;
> >>>
> >>> intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
> >>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> >>> b/drivers/gpu/drm/i915/intel_hdmi.c
> >>> index 4a77639a489d..23ee48dc765f 100644
> >>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> >>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> >>> @@ -2146,7 +2146,6 @@ void intel_hdmi_init_connector(struct
> >>> intel_digital_port *intel_dig_port,
> >>> void intel_hdmi_init(struct drm_device *dev,
> >>>i915_reg_t hdmi_re
[PATCH 3/3] drm/omap: no need to select OMAP2_DSS
omapdss driver now depends on omapdrm, so we no longer should select OMAP2_DSS from omapdrm's Kconfig. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig index 336ad4de9981..73241c4eb7aa 100644 --- a/drivers/gpu/drm/omapdrm/Kconfig +++ b/drivers/gpu/drm/omapdrm/Kconfig @@ -2,7 +2,6 @@ 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.5.0
[PATCH 2/3] drm/omap: gem: Fix omap_gem_new() error path
From: Laurent Pinchart
When an error occurs in omap_gem_new() the function calls
omap_gem_free_object() to clean up. However, that function expects to be
called on a fully initialized GEM object and thus crashes.
Replace it by manual cleanup.
Signed-off-by: Laurent Pinchart
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 9ac30560e9b1..cc36a8dc9bd4 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1398,35 +1398,37 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
size = PAGE_ALIGN(gsize.bytes);
}
- spin_lock(&priv->list_lock);
- list_add(&omap_obj->mm_list, &priv->obj_list);
- spin_unlock(&priv->list_lock);
-
- /* Allocate memory if needed. */
- if (flags & OMAP_BO_MEM_DMA_API) {
- omap_obj->vaddr = dma_alloc_writecombine(dev->dev, size,
-&omap_obj->paddr,
-GFP_KERNEL);
- if (!omap_obj->vaddr)
- goto fail;
- }
-
/* Initialize the GEM object. */
if (!(flags & OMAP_BO_MEM_SHMEM)) {
drm_gem_private_object_init(dev, obj, size);
} else {
ret = drm_gem_object_init(dev, obj, size);
if (ret)
- goto fail;
+ goto err_free;
mapping = file_inode(obj->filp)->i_mapping;
mapping_set_gfp_mask(mapping, GFP_USER | __GFP_DMA32);
}
+ /* Allocate memory if needed. */
+ if (flags & OMAP_BO_MEM_DMA_API) {
+ omap_obj->vaddr = dma_alloc_writecombine(dev->dev, size,
+&omap_obj->paddr,
+GFP_KERNEL);
+ if (!omap_obj->vaddr)
+ goto err_release;
+ }
+
+ spin_lock(&priv->list_lock);
+ list_add(&omap_obj->mm_list, &priv->obj_list);
+ spin_unlock(&priv->list_lock);
+
return obj;
-fail:
- omap_gem_free_object(obj);
+err_release:
+ drm_gem_object_release(obj);
+err_free:
+ kfree(omap_obj);
return NULL;
}
--
2.5.0
[PATCH 1/3] drm/omap: remove -Werror from Makefile
Having -Werror in the omapdrm Makefile makes development and debugging a PITA. Let's remove it. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/Makefile b/drivers/gpu/drm/omapdrm/Makefile index fe4c2228bc18..48b7b750c05c 100644 --- a/drivers/gpu/drm/omapdrm/Makefile +++ b/drivers/gpu/drm/omapdrm/Makefile @@ -6,7 +6,7 @@ obj-y += dss/ obj-y += displays/ -ccflags-y := -Iinclude/drm -Werror +ccflags-y := -Iinclude/drm omapdrm-y := omap_drv.o \ omap_irq.o \ omap_debugfs.o \ -- 2.5.0
[PATCH 0/3] drm/omap: patches for v4.6 part 3
Hi, A few more patches for omapdrm for 4.6. These are based on the "drm/omap: patches for v4.6 part 2" series sent earlier. Tomi Laurent Pinchart (1): drm/omap: gem: Fix omap_gem_new() error path Tomi Valkeinen (2): drm/omap: remove -Werror from Makefile drm/omap: no need to select OMAP2_DSS drivers/gpu/drm/omapdrm/Kconfig| 1 - drivers/gpu/drm/omapdrm/Makefile | 2 +- drivers/gpu/drm/omapdrm/omap_gem.c | 34 ++ 3 files changed, 19 insertions(+), 18 deletions(-) -- 2.5.0
[PATCH] staging/android: refactor SYNC_IOC_FILE_INFO
Op 03-03-16 om 15:34 schreef Gustavo Padovan: > From: Gustavo Padovan > > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and > optimize buffer > > Now num_fences can be filled by the caller to inform how many fences it > wants to retrieve from the kernel. If the num_fences passed is greater > than zero info->sync_fence_info should point to a buffer with enough space > to fit all fences. > > However if num_fences passed to the kernel is 0, the kernel will reply > with number of fences of the sync_file. > > Sending first an ioctl with num_fences = 0 can optimize buffer allocation, > in a first call with num_fences = 0 userspace will receive the actual > number of fences in the num_fences filed. > > Then it can allocate a buffer with the correct size on sync_fence_info and > call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences > in the sync_file. > > Also, info->sync_fence_info was converted to __u64 pointer to prevent > 32bit compatibility issues. For this patch and 6/6: Reviewed-by: Maarten Lankhorst
[PATCH] staging/android: add flags member to sync ioctl structs
On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: >> From: Gustavo Padovan >> >> Play safe and add flags member to all structs. So we don't need to >> break API or create new IOCTL in the future if new features that requires >> flags arises. >> >> v2: check if flags are valid (zero, in this case) >> >> v3: return -EINVAL if flags are not zero'ed >> >> v4: add padding for 64-bit alignment >> >> v5: rebase to use only stacked sync_file_info > > Why are these vX things here in the changelog? > > And you just broke all existing userspace users of this code, why are > you allowed to do that? > > not ok... There are not really any users of this on an upstream kernel yet, so it makes sense to fix the ABI to something we can live with now, before that changes. If we are stuck not breaking ABI with android stuff pulled into staging as we destage it, then maybe we should be a *lot* slower at pulling android stuff into staging. (Ie. if that is the case, please kick it all out now and we'll re-add things properly.) BR, -R
[PATCH v6 05/11] drm/hisilicon: Add vblank driver for ADE
On 1 March 2016 at 20:40, Archit Taneja wrote:
>
>
> On 3/1/2016 3:44 PM, Xinliang Liu wrote:
>>
>> Hi,
>>
>> On 1 March 2016 at 02:48, Archit Taneja wrote:
>>>
>>>
>>>
>>> On 2/26/2016 2:10 PM, Xinliang Liu wrote:
Add vblank irq handle.
v6: None.
v5: None.
v4: None.
v3:
- Remove hisi_get_crtc_from_index func.
- A few cleanup.
v2:
- Remove abtraction layer.
Signed-off-by: Xinliang Liu
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 62
+
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 14 +-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index aa2cf75cab39..749382952ab7 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -292,6 +292,59 @@ static void ade_set_medianoc_qos(struct ade_crtc
*acrtc)
SOCKET_QOS_EN, SOCKET_QOS_EN);
}
+static int ade_enable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+ struct kirin_drm_private *priv = dev->dev_private;
+ struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+ struct ade_hw_ctx *ctx = acrtc->ctx;
+ void __iomem *base = ctx->base;
+
+ if (!ctx->power_on)
+ (void)ade_power_up(ctx);
+
+ ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+ MASK(1), 1);
+
+ return 0;
+}
+
+static void ade_disable_vblank(struct drm_device *dev, unsigned int
pipe)
+{
+ struct kirin_drm_private *priv = dev->dev_private;
+ struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+ struct ade_hw_ctx *ctx = acrtc->ctx;
+ void __iomem *base = ctx->base;
+
+ if (!ctx->power_on) {
+ DRM_ERROR("power is down! vblank disable fail\n");
+ return;
+ }
+
+ ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+ MASK(1), 0);
+}
+
+static irqreturn_t ade_irq_handler(int irq, void *data)
+{
+ struct ade_crtc *acrtc = data;
+ struct ade_hw_ctx *ctx = acrtc->ctx;
+ struct drm_crtc *crtc = &acrtc->base;
+ void __iomem *base = ctx->base;
+ u32 status;
+
+ status = readl(base + LDI_MSK_INT);
+ DRM_DEBUG_VBL("LDI IRQ: status=0x%X\n", status);
+
+ /* vblank irq */
+ if (status & BIT(FRAME_END_INT_EN_OFST)) {
+ ade_update_bits(base + LDI_INT_CLR,
FRAME_END_INT_EN_OFST,
+ MASK(1), 1);
+ drm_crtc_handle_vblank(crtc);
+ }
+
+ return IRQ_HANDLED;
+}
+
static void ade_display_enable(struct ade_crtc *acrtc)
{
struct ade_hw_ctx *ctx = acrtc->ctx;
@@ -967,6 +1020,15 @@ int ade_drm_init(struct drm_device *dev)
if (ret)
return ret;
+ /* vblank irq init */
+ ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler,
+ DRIVER_IRQ_SHARED, dev->driver->name,
acrtc);
>>>
>>>
>>>
>>> This isn't the way we set up interrupts for kms drivers. We need to
>>> provide the handler in drm_driver and call drm_irq_install.
>>
>>
>> I prefer to set up interrupts here for two reasons.
>> One is that it is easy to pass any interrupt private "void * data" to
>> the interrupt handler here.
>> As I discussed with Daniel Vetter before:
>> https://lkml.org/lkml/2015/9/10/204.
>>
>> Second is setting up interrupt here in the specific SoC display
>> controller driver, make other SoC reuse the kirin_drm_drv.c code
>> easily.
>> Different Hisilicon SoC may has different display controller interrupts.
>
>
> Sure, as long as this has been discussed before.
>
>
>>
>>>
>>>
+ if (ret)
+ return ret;
+ dev->driver->get_vblank_counter = drm_vblank_no_hw_counter;
+ dev->driver->enable_vblank = ade_enable_vblank;
+ dev->driver->disable_vblank = ade_disable_vblank;
+
return 0;
}
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 055729c1889c..723888feb760 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -32,6 +32,7 @@ static int kirin_drm_kms_cleanup(struct drm_device
*dev)
{
struct kirin_drm_private *priv = dev->dev_private;
+ drm_vblank_cleanup(dev)
[PATCH v2 2/2] drm/i915/gen9: Add support for pipe background color (v2)
Hi Matt,
On 11/02/16 02:32, Matt Roper wrote:
> Gen9 platforms allow CRTC's to be programmed with a background/canvas
> color below the programmable planes. Let's expose this as a property to
> allow userspace to program a desired value.
>
> This patch is based on earlier work by Chandra Konduru; unfortunately
> the driver has evolved so much since his patches were written (in the
> pre-atomic era) that the functionality had to be pretty much completely
> rewritten for the new i915 atomic internals.
>
> v2:
> - Set initial background color (black) via proper helper function (Bob)
> - Fix debugfs output
> - General rebasing
>
> Cc: Chandra Konduru
> Cc: Bob Paauwe
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Matt Roper
> ---
> Documentation/DocBook/gpu.tmpl | 10 +++-
> drivers/gpu/drm/i915/i915_debugfs.c | 8 +++
> drivers/gpu/drm/i915/i915_reg.h | 9 +++
> drivers/gpu/drm/i915/intel_display.c | 46
>
> 4 files changed, 72 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index fe6b36a..9e003cd 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -2092,7 +2092,7 @@ void intel_crt_init(struct drm_device *dev)
> TBD
>
>
> - i915
> + i915
> Generic
> "Broadcast RGB"
> ENUM
> @@ -2108,6 +2108,14 @@ void intel_crt_init(struct drm_device *dev)
> TBD
>
>
> + CRTC
> + âbackground_colorâ
> + RGBA
> +
> + CRTC
> + Background color of regions not covered by a
> plane
> +
> +
> SDVO-TV
> âmodeâ
> ENUM
Why make this property i915 specific?
Have you considered make this a generic optional property?
Just asking because your first patch seems to imply this could be generic.
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index ec0c2a05e..e7352fc 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3104,6 +3104,14 @@ static int i915_display_info(struct seq_file *m, void
> *unused)
> intel_scaler_info(m, crtc);
> intel_plane_info(m, crtc);
> }
> + if (INTEL_INFO(dev)->gen >= 9 && pipe_config->base.active) {
> + struct drm_rgba background =
> pipe_config->base.background_color;
> +
> + seq_printf(m, "\tbackground color (10bpc): r=%x g=%x
> b=%x\n",
> +DRM_RGBA_REDBITS(background, 10),
> +DRM_RGBA_GREENBITS(background, 10),
> +DRM_RGBA_BLUEBITS(background, 10));
> + }
>
> seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
> yesno(!crtc->cpu_fifo_underrun_disabled),
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 144586e..b0b014d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7649,6 +7649,15 @@ enum skl_disp_power_wells {
> #define PIPE_CSC_POSTOFF_ME(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
> #define PIPE_CSC_POSTOFF_LO(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
>
> +/* Skylake pipe bottom color */
> +#define _PIPE_BOTTOM_COLOR_A0x70034
> +#define _PIPE_BOTTOM_COLOR_B0x71034
> +#define _PIPE_BOTTOM_COLOR_C0x72034
> +#define PIPE_BOTTOM_GAMMA_ENABLE (1 << 31)
> +#define PIPE_BOTTOM_CSC_ENABLE (1 << 30)
> +#define PIPE_BOTTOM_COLOR_MASK 0x3FFF
> +#define PIPE_BOTTOM_COLOR(pipe) _MMIO_PIPE(pipe, _PIPE_BOTTOM_COLOR_A,
> _PIPE_BOTTOM_COLOR_B)
> +
> /* MIPI DSI registers */
>
> #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c) /* ports A and
> C only */
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 836bbdc..a616ac42 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3299,6 +3299,8 @@ static void intel_update_pipe_config(struct intel_crtc
> *crtc,
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_crtc_state *pipe_config =
> to_intel_crtc_state(crtc->base.state);
> + struct drm_rgba background = pipe_config->base.background_color;
> + uint32_t val;
>
> /* drm_atomic_helper_update_legacy_modeset_state might not be called. */
> crtc->base.mode = crtc->base.state->mode;
> @@ -3335,6 +3337,26 @@ static void intel_update_pipe_config(struct intel_crtc
> *crtc,
> else if (old_crtc_state->pch_pfit.enabled)
> ironlake_pfit_disable(crtc, true);
> }
> +
> + if (INTEL_INFO(dev)->gen >= 9) {
> + /* BGR 16bpc ==> RGB 10bpc */
[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field
On 03/03/2016 02:33 PM, Ville Syrjälä wrote: > On Thu, Mar 03, 2016 at 02:28:38PM +0100, Fabien DESSENNE wrote: >> >> On 03/03/2016 12:28 PM, Ville Syrjälä wrote: >>> On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote: Hi Ville, Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes that the userland controls the field presentation on the display output. This assumes that the userland is aware of the field actually on display and I think that this information is not provided by the DRM framework. Moreover the field management is something very close to the HW and I do not think that this shall be managed at userland level. >>> Userland is the only one that knows how the data is to be presented, so >>> I don't understand your comment. Userland is the one that would set your >>> fb flag too. >> Sure, the flag is under userland control. >> In the two options I am comparing, this flag is set. But in different ways: >> A/ either the userland sets DRM_MODE_PRESENT_TOP_FIELD to display the >> top field, then sets DRM_MODE_PRESENT_BOTTOM_FIELD to display the bottom >> field. (2 PageFlip calls) > No, in case of actual interlaced scanout the these flags would in fact > mean TFF or BFF. My natural and initial understanding of PRESENT_TOP_FIELD is "present top field *only*". Since these flags are not verbosely documented (and not used in any driver?), I did not catch that it may also mean "present top field *first*" So considering this statement, I have a better understanding of what you mean and it looks like there are no real difference between the two compared options. At least for the interlaced scanout case. > You would only use two pageflips for bob deinterlacing. For the bob deinterlacing case (progressive scanout) it is a bit different. But well, no so different. So focusing back to the initial difference which is about what the flag marks (SetPlane vs fb): DRM_MODE_FB_BFF is a fb flag. The fb can be used in SetPlane, PageFlip or SetCrtc calls. Since DRM_MODE_PRESENT_TOP_FIELD is a drm_mode_set_plane flag I do not see how we can specify the top/bottom field order in a PageFlip call. >> B/ either, the userland sets DRM_MODE_FB_BFF for a single frame, and >> lets the driver display the two fields (1 PageFlip call) > Well, this would rather be N fields, because the scanout being > interlaced it will keep alternating between the two fields until another > flip is performed. As an alternative approach, the field management can be transparent to the userland, letting the driver doing the job. This is how the STI driver works: when handling an interlaced buffer it displays top and bottom fields at the right time, synchronized with the VSYNC signal (vsync for top field / vsync for btm field). The usage of the atomic mode is transparent for this processing. >>> We can do that on most hardware without specific hardware assist. Well, >>> to be precise we can present the first field correctly, but the >>> second/third field will only be presented correctly if the output >>> refresh rate matches the intended refresh rate for the input data. >>> But any hardware assist would have the same problem as well. >>> Clearly, the two methods are very different. >>> Not from where I'm sitting. >>> The proposed patch fits with the second one. BR Fabien On 02/29/2016 09:41 PM, Ville Syrjälä wrote: > On Fri, Feb 12, 2016 at 10:26:03AM +0100, Vincent Abriou wrote: >> Interlaced video can have different scan order: >> Top Field First or Bottom Field First >> >> In case of video with interlaced content, this information should be >> propagated from the userland to the DRM kernel driver that will process >> the >> deinterlacing starting with the top or the bottom field first. >> That's why we introduce this new flag definition DRM_MODE_FB_BFF (Bottom >> Field >> First) that should be used jointly with the already existing >> DRM_MODE_FB_INTERLACED flag incase of interlaced video with Bottom Field >> First >> scan order should be processed. > The way I envisioned this long ago is that we would specify the > bff/tff at flip time. In fact we already have the > DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD flags for > setplane. When doing bob deinterlacing these would choose the field > we're going to present, and when doing interlaced scanout these would > choose tff vs. bff. But that approach does fall short with atomic when > you want to flip multiple planes at once. > > One problem I see with making this part of the FB is that if you already > missed your original deadline for the first field, and you want to > actually present the second field instead, you're forced to create > another fb. So a plane property might be a bit more flexible. And the > same way as th
[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field
On Thu, Mar 03, 2016 at 02:28:38PM +0100, Fabien DESSENNE wrote: > > > On 03/03/2016 12:28 PM, Ville Syrjälä wrote: > > On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote: > >> Hi Ville, > >> > >> Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes > >> that the userland controls the field presentation on the display output. > >> This assumes that the userland is aware of the field actually on display > >> and I think that this information is not provided by the DRM framework. > >> Moreover the field management is something very close to the HW and I do > >> not think that this shall be managed at userland level. > > Userland is the only one that knows how the data is to be presented, so > > I don't understand your comment. Userland is the one that would set your > > fb flag too. > Sure, the flag is under userland control. > In the two options I am comparing, this flag is set. But in different ways: > A/ either the userland sets DRM_MODE_PRESENT_TOP_FIELD to display the > top field, then sets DRM_MODE_PRESENT_BOTTOM_FIELD to display the bottom > field. (2 PageFlip calls) No, in case of actual interlaced scanout the these flags would in fact mean TFF or BFF. You would only use two pageflips for bob deinterlacing. > B/ either, the userland sets DRM_MODE_FB_BFF for a single frame, and > lets the driver display the two fields (1 PageFlip call) Well, this would rather be N fields, because the scanout being interlaced it will keep alternating between the two fields until another flip is performed. > >> As an alternative approach, the field management can be transparent to > >> the userland, letting the driver doing the job. This is how the STI > >> driver works: when handling an interlaced buffer it displays top and > >> bottom fields at the right time, synchronized with the VSYNC signal > >> (vsync for top field / vsync for btm field). The usage of the atomic > >> mode is transparent for this processing. > > We can do that on most hardware without specific hardware assist. Well, > > to be precise we can present the first field correctly, but the > > second/third field will only be presented correctly if the output > > refresh rate matches the intended refresh rate for the input data. > > But any hardware assist would have the same problem as well. > > > >> Clearly, the two methods are very different. > > Not from where I'm sitting. > > > >> The proposed patch fits with the second one. > >> > >> BR > >> Fabien > >> > >> On 02/29/2016 09:41 PM, Ville Syrjälä wrote: > >>> On Fri, Feb 12, 2016 at 10:26:03AM +0100, Vincent Abriou wrote: > Interlaced video can have different scan order: > Top Field First or Bottom Field First > > In case of video with interlaced content, this information should be > propagated from the userland to the DRM kernel driver that will process > the > deinterlacing starting with the top or the bottom field first. > That's why we introduce this new flag definition DRM_MODE_FB_BFF (Bottom > Field > First) that should be used jointly with the already existing > DRM_MODE_FB_INTERLACED flag incase of interlaced video with Bottom Field > First > scan order should be processed. > >>> The way I envisioned this long ago is that we would specify the > >>> bff/tff at flip time. In fact we already have the > >>> DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD flags for > >>> setplane. When doing bob deinterlacing these would choose the field > >>> we're going to present, and when doing interlaced scanout these would > >>> choose tff vs. bff. But that approach does fall short with atomic when > >>> you want to flip multiple planes at once. > >>> > >>> One problem I see with making this part of the FB is that if you already > >>> missed your original deadline for the first field, and you want to > >>> actually present the second field instead, you're forced to create > >>> another fb. So a plane property might be a bit more flexible. And the > >>> same way as the setplane flags we could then share the properties for > >>> bob deinterlacing field selection as well. There's no way to do bob > >>> deinterlacing with fb flags, unless you create a separate fb for each > >>> field. > >>> -- Ville Syrjälä Intel OTC
[Bug 107381] radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics
https://bugzilla.kernel.org/show_bug.cgi?id=107381 --- Comment #5 from Robin KERDILES --- Created attachment 206701 --> https://bugzilla.kernel.org/attachment.cgi?id=206701&action=edit dmesg under kernel 4.4 - archlinux x64 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 107381] radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics
https://bugzilla.kernel.org/show_bug.cgi?id=107381 Robin KERDILES changed: What|Removed |Added CC||xxdrshadowxx at gmail.com --- Comment #4 from Robin KERDILES --- This issue still affects kernels 4.4, 4.5-rc6 Archlinux x64 Hardware : radeon HD 8750M -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 2/2] drm/i915/gen9: Add support for pipe background color (v2)
On Thu, Mar 03, 2016 at 03:50:23PM +, Lionel Landwerlin wrote:
> Hi Matt,
>
> On 11/02/16 02:32, Matt Roper wrote:
> >Gen9 platforms allow CRTC's to be programmed with a background/canvas
> >color below the programmable planes. Let's expose this as a property to
> >allow userspace to program a desired value.
> >
> >This patch is based on earlier work by Chandra Konduru; unfortunately
> >the driver has evolved so much since his patches were written (in the
> >pre-atomic era) that the functionality had to be pretty much completely
> >rewritten for the new i915 atomic internals.
> >
> >v2:
> > - Set initial background color (black) via proper helper function (Bob)
> > - Fix debugfs output
> > - General rebasing
> >
> >Cc: Chandra Konduru
> >Cc: Bob Paauwe
> >Cc: dri-devel at lists.freedesktop.org
> >Signed-off-by: Matt Roper
> >---
> > Documentation/DocBook/gpu.tmpl | 10 +++-
> > drivers/gpu/drm/i915/i915_debugfs.c | 8 +++
> > drivers/gpu/drm/i915/i915_reg.h | 9 +++
> > drivers/gpu/drm/i915/intel_display.c | 46
> >
> > 4 files changed, 72 insertions(+), 1 deletion(-)
> >
> >diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> >index fe6b36a..9e003cd 100644
> >--- a/Documentation/DocBook/gpu.tmpl
> >+++ b/Documentation/DocBook/gpu.tmpl
> >@@ -2092,7 +2092,7 @@ void intel_crt_init(struct drm_device *dev)
> > TBD
> >
> >
> >-i915
> >+i915
> > Generic
> > "Broadcast RGB"
> > ENUM
> >@@ -2108,6 +2108,14 @@ void intel_crt_init(struct drm_device *dev)
> > TBD
> >
> >
> >+CRTC
> >+âbackground_colorâ
> >+RGBA
> >+
> >+CRTC
> >+Background color of regions not covered by a
> >plane
> >+
> >+
> > SDVO-TV
> > âmodeâ
> > ENUM
>
> Why make this property i915 specific?
> Have you considered make this a generic optional property?
>
> Just asking because your first patch seems to imply this could be generic.
Yeah, the intention is for it to be generic. I guess I should have
stuck this under the 'DRM/Optional' section of DocBook rather than the
i915-specific section. Thanks for pointing that out.
Matt
>
> >diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> >b/drivers/gpu/drm/i915/i915_debugfs.c
> >index ec0c2a05e..e7352fc 100644
> >--- a/drivers/gpu/drm/i915/i915_debugfs.c
> >+++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >@@ -3104,6 +3104,14 @@ static int i915_display_info(struct seq_file *m, void
> >*unused)
> > intel_scaler_info(m, crtc);
> > intel_plane_info(m, crtc);
> > }
> >+if (INTEL_INFO(dev)->gen >= 9 && pipe_config->base.active) {
> >+struct drm_rgba background =
> >pipe_config->base.background_color;
> >+
> >+seq_printf(m, "\tbackground color (10bpc): r=%x g=%x
> >b=%x\n",
> >+ DRM_RGBA_REDBITS(background, 10),
> >+ DRM_RGBA_GREENBITS(background, 10),
> >+ DRM_RGBA_BLUEBITS(background, 10));
> >+}
> > seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
> >yesno(!crtc->cpu_fifo_underrun_disabled),
> >diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >b/drivers/gpu/drm/i915/i915_reg.h
> >index 144586e..b0b014d 100644
> >--- a/drivers/gpu/drm/i915/i915_reg.h
> >+++ b/drivers/gpu/drm/i915/i915_reg.h
> >@@ -7649,6 +7649,15 @@ enum skl_disp_power_wells {
> > #define PIPE_CSC_POSTOFF_ME(pipe) _MMIO_PIPE(pipe,
> > _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
> > #define PIPE_CSC_POSTOFF_LO(pipe) _MMIO_PIPE(pipe,
> > _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
> >+/* Skylake pipe bottom color */
> >+#define _PIPE_BOTTOM_COLOR_A0x70034
> >+#define _PIPE_BOTTOM_COLOR_B0x71034
> >+#define _PIPE_BOTTOM_COLOR_C0x72034
> >+#define PIPE_BOTTOM_GAMMA_ENABLE (1 << 31)
> >+#define PIPE_BOTTOM_CSC_ENABLE (1 << 30)
> >+#define PIPE_BOTTOM_COLOR_MASK 0x3FFF
> >+#define PIPE_BOTTOM_COLOR(pipe) _MMIO_PIPE(pipe, _PIPE_BOTTOM_COLOR_A,
> >_PIPE_BOTTOM_COLOR_B)
> >+
> > /* MIPI DSI registers */
> > #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c) /* ports A and
> > C only */
> >diff --git a/drivers/gpu/drm/i915/intel_display.c
> >b/drivers/gpu/drm/i915/intel_display.c
> >index 836bbdc..a616ac42 100644
> >--- a/drivers/gpu/drm/i915/intel_display.c
> >+++ b/drivers/gpu/drm/i915/intel_display.c
> >@@ -3299,6 +3299,8 @@ static void intel_update_pipe_config(struct intel_crtc
> >*crtc,
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > struct intel_crtc_state *pipe_config =
> > to_intel_crtc_state(crtc->base.state);
> >+struct drm_rgba background = pipe_config->base.background_color;
> >+uint32_t val;
> > /* drm_atomic_helper_update_legacy_modeset_state might not be called. */
> > cr
[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field
On 03/03/2016 12:28 PM, Ville Syrjälä wrote: > On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote: >> Hi Ville, >> >> Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes >> that the userland controls the field presentation on the display output. >> This assumes that the userland is aware of the field actually on display >> and I think that this information is not provided by the DRM framework. >> Moreover the field management is something very close to the HW and I do >> not think that this shall be managed at userland level. > Userland is the only one that knows how the data is to be presented, so > I don't understand your comment. Userland is the one that would set your > fb flag too. Sure, the flag is under userland control. In the two options I am comparing, this flag is set. But in different ways: A/ either the userland sets DRM_MODE_PRESENT_TOP_FIELD to display the top field, then sets DRM_MODE_PRESENT_BOTTOM_FIELD to display the bottom field. (2 PageFlip calls) B/ either, the userland sets DRM_MODE_FB_BFF for a single frame, and lets the driver display the two fields (1 PageFlip call) >> As an alternative approach, the field management can be transparent to >> the userland, letting the driver doing the job. This is how the STI >> driver works: when handling an interlaced buffer it displays top and >> bottom fields at the right time, synchronized with the VSYNC signal >> (vsync for top field / vsync for btm field). The usage of the atomic >> mode is transparent for this processing. > We can do that on most hardware without specific hardware assist. Well, > to be precise we can present the first field correctly, but the > second/third field will only be presented correctly if the output > refresh rate matches the intended refresh rate for the input data. > But any hardware assist would have the same problem as well. > >> Clearly, the two methods are very different. > Not from where I'm sitting. > >> The proposed patch fits with the second one. >> >> BR >> Fabien >> >> On 02/29/2016 09:41 PM, Ville Syrjälä wrote: >>> On Fri, Feb 12, 2016 at 10:26:03AM +0100, Vincent Abriou wrote: Interlaced video can have different scan order: Top Field First or Bottom Field First In case of video with interlaced content, this information should be propagated from the userland to the DRM kernel driver that will process the deinterlacing starting with the top or the bottom field first. That's why we introduce this new flag definition DRM_MODE_FB_BFF (Bottom Field First) that should be used jointly with the already existing DRM_MODE_FB_INTERLACED flag incase of interlaced video with Bottom Field First scan order should be processed. >>> The way I envisioned this long ago is that we would specify the >>> bff/tff at flip time. In fact we already have the >>> DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD flags for >>> setplane. When doing bob deinterlacing these would choose the field >>> we're going to present, and when doing interlaced scanout these would >>> choose tff vs. bff. But that approach does fall short with atomic when >>> you want to flip multiple planes at once. >>> >>> One problem I see with making this part of the FB is that if you already >>> missed your original deadline for the first field, and you want to >>> actually present the second field instead, you're forced to create >>> another fb. So a plane property might be a bit more flexible. And the >>> same way as the setplane flags we could then share the properties for >>> bob deinterlacing field selection as well. There's no way to do bob >>> deinterlacing with fb flags, unless you create a separate fb for each >>> field. >>>
[PULL] drm-intel-fixes
Hi Dave, a couple of Intel fixes for v4.5. BR, Jani. The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af: Linux 4.5-rc6 (2016-02-28 08:41:20 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-03-03 for you to fetch changes up to eda908967feecf7575a8ab74f1695b0445cf324e: drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM) (2016-03-02 14:40:46 +0200) Chris Wilson (1): drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM) Imre Deak (1): drm/i915/skl: Fix power domain suspend sequence drivers/gpu/drm/i915/intel_runtime_pm.c | 32 +++- 1 file changed, 15 insertions(+), 17 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[Bug 94387] Approx 35W more power usage in multi-screen
https://bugs.freedesktop.org/show_bug.cgi?id=94387 Alex Deucher changed: What|Removed |Added Product|xorg|DRI Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Component|Driver/Radeon |DRM/Radeon Version|7.6 (2010.12) |unspecified QA Contact|xorg-team at lists.x.org | -- 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/20160303/a17cb4ad/attachment.html>
[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field
On Thu, Mar 03, 2016 at 11:03:51AM +0100, Fabien DESSENNE wrote: > Hi Ville, > > Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes > that the userland controls the field presentation on the display output. > This assumes that the userland is aware of the field actually on display > and I think that this information is not provided by the DRM framework. > Moreover the field management is something very close to the HW and I do > not think that this shall be managed at userland level. Userland is the only one that knows how the data is to be presented, so I don't understand your comment. Userland is the one that would set your fb flag too. > > As an alternative approach, the field management can be transparent to > the userland, letting the driver doing the job. This is how the STI > driver works: when handling an interlaced buffer it displays top and > bottom fields at the right time, synchronized with the VSYNC signal > (vsync for top field / vsync for btm field). The usage of the atomic > mode is transparent for this processing. We can do that on most hardware without specific hardware assist. Well, to be precise we can present the first field correctly, but the second/third field will only be presented correctly if the output refresh rate matches the intended refresh rate for the input data. But any hardware assist would have the same problem as well. > > Clearly, the two methods are very different. Not from where I'm sitting. > The proposed patch fits with the second one. > > BR > Fabien > > On 02/29/2016 09:41 PM, Ville Syrjälä wrote: > > On Fri, Feb 12, 2016 at 10:26:03AM +0100, Vincent Abriou wrote: > >> Interlaced video can have different scan order: > >> Top Field First or Bottom Field First > >> > >> In case of video with interlaced content, this information should be > >> propagated from the userland to the DRM kernel driver that will process the > >> deinterlacing starting with the top or the bottom field first. > >> That's why we introduce this new flag definition DRM_MODE_FB_BFF (Bottom > >> Field > >> First) that should be used jointly with the already existing > >> DRM_MODE_FB_INTERLACED flag incase of interlaced video with Bottom Field > >> First > >> scan order should be processed. > > The way I envisioned this long ago is that we would specify the > > bff/tff at flip time. In fact we already have the > > DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD flags for > > setplane. When doing bob deinterlacing these would choose the field > > we're going to present, and when doing interlaced scanout these would > > choose tff vs. bff. But that approach does fall short with atomic when > > you want to flip multiple planes at once. > > > > One problem I see with making this part of the FB is that if you already > > missed your original deadline for the first field, and you want to > > actually present the second field instead, you're forced to create > > another fb. So a plane property might be a bit more flexible. And the > > same way as the setplane flags we could then share the properties for > > bob deinterlacing field selection as well. There's no way to do bob > > deinterlacing with fb flags, unless you create a separate fb for each > > field. > > -- Ville Syrjälä Intel OTC
[Bug 94388] r600_blit.c:281: r600_decompress_depth_textures: Assertion `tex->is_depth && !tex->is_flushing_texture' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=94388 Bug ID: 94388 Summary: r600_blit.c:281: r600_decompress_depth_textures: Assertion `tex->is_depth && !tex->is_flushing_texture' failed. Product: Mesa Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: iive at yahoo.com QA Contact: dri-devel at lists.freedesktop.org am\steamapps\common\Crysis\bin32\crysis.exe: r600_blit.c:281: r600_decompress_depth_textures: Assertion `tex->is_depth && !tex->is_flushing_texture' failed. fixme:faultrep:ReportFault 0x738120 0x0 stub This is a regression and bisect narrowed it down to: --- commit 757071ca7cdda12d2974614f9a9d02d5a834f38c Author: Fredrik H�glund Date: Fri Jan 8 16:31:14 2016 -0500 st/mesa: Accelerate PBO uploads --- Unfortunately I was not able to get backtrace or apitrace (d3d9 or opengl). For me the bug is triggered when using the wine native d3d9 to opengl wrapper, running the steam version of Crysis 1. The game starts, shows intros and menus, loading screen, but crashes when level is started. -- 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/20160303/6f374dcd/attachment.html>
[PATCH] drm: Taint mm->mmap_sem with dev->struct_mutex for lockdep
The DRM core depends on mm->mmap_sem being the outer lock in order to
setup/teardown and utilize fault handlers. If we taint the mm->mmap_sem
as soon as we open the device for a process, we can define this proper
ordering for lockdep and so it will report any violations early.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_fops.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index aeef58ed359b..a95d588c24c8 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -246,6 +246,19 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
DRM_DEBUG("pid = %d, minor = %d\n", task_pid_nr(current), minor->index);
+ if (IS_ENABLED(CONFIG_LOCKDEP)) {
+ /* We depend upon the strict order of mmap_sem outside of
+* struct_mutex in order for the fault handlers and their
+* setup/teardown. Taint mmap_sem as early as possible in
+* order to define the proper order and flag ABBA errors
+* should the order ever be inverted.
+*/
+ down_write(¤t->mm->mmap_sem);
+ mutex_lock(&dev->struct_mutex);
+ mutex_unlock(&dev->struct_mutex);
+ up_write(¤t->mm->mmap_sem);
+ }
+
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
--
2.7.0
[PATCH] MAINTAINERS: update radeon entry to include amdgpu as well
Both are maintained by same team. Signed-off-by: Alex Deucher --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index c647c40..20166fb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3712,7 +3712,7 @@ F:drivers/gpu/vga/ F: include/drm/ F: include/uapi/drm/ -RADEON DRM DRIVERS +RADEON and AMDGPU DRM DRIVERS M: Alex Deucher M: Christian König L: dri-devel at lists.freedesktop.org @@ -3720,6 +3720,8 @@ T:git git://people.freedesktop.org/~agd5f/linux S: Supported F: drivers/gpu/drm/radeon/ F: include/uapi/drm/radeon* +F: drivers/gpu/drm/amd/ +F: include/uapi/drm/amdgpu* DRM PANEL DRIVERS M: Thierry Reding -- 2.5.0
[PATCH] staging/android: add flags member to sync ioctl structs
From: Gustavo Padovan
Play safe and add flags member to all structs. So we don't need to
break API or create new IOCTL in the future if new features that requires
flags arises.
v2: check if flags are valid (zero, in this case)
v3: return -EINVAL if flags are not zero'ed
v4: add padding for 64-bit alignment
v5: rebase to use only stacked sync_file_info
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync.c | 8
drivers/staging/android/uapi/sync.h | 14 --
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 48ee175..ae81c95 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file
*sync_file,
goto err_put_fd;
}
+ if (data.flags || data.pad) {
+ err = -EINVAL;
+ goto err_put_fd;
+ }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -504,6 +509,9 @@ static long sync_file_ioctl_fence_info(struct sync_file
*sync_file,
if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
return -EFAULT;
+ if (info.flags || info.pad)
+ return -EINVAL;
+
/*
* Passing num_fences = 0 means that userspace doesn't want to
* retrieve any sync_fence_info. If num_fences = 0 we skip filling
diff --git a/drivers/staging/android/uapi/sync.h
b/drivers/staging/android/uapi/sync.h
index a122bb5..859977c 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -16,14 +16,18 @@
/**
* struct sync_merge_data - data passed to merge ioctl
- * @fd2: file descriptor of second fence
* @name: name of new fence
+ * @fd2: file descriptor of second fence
* @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
+ * @pad: padding for 64-bit alignment, should always be zero
*/
struct sync_merge_data {
- __s32 fd2;
charname[32];
+ __s32 fd2;
__s32 fence;
+ __u32 flags;
+ __u32 pad;
};
/**
@@ -31,12 +35,14 @@ struct sync_merge_data {
* @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
+ * @flags: fence_info flags
* @timestamp_ns: timestamp of status change in nanoseconds
*/
struct sync_fence_info {
charobj_name[32];
chardriver_name[32];
__s32 status;
+ __u32 flags;
__u64 timestamp_ns;
};
@@ -44,14 +50,18 @@ struct sync_fence_info {
* struct sync_file_info - data returned from fence info ioctl
* @name: name of fence
* @status:status of fence. 1: signaled 0:active <0:error
+ * @flags: sync_file_info flags
* @num_fences number of fences in the sync_file
+ * @pad: padding for 64-bit alignment, should always be zero
* @sync_fence_info: pointer to array of structs sync_fence_info with all
* fences in the sync_file
*/
struct sync_file_info {
charname[32];
__s32 status;
+ __u32 flags;
__u32 num_fences;
+ __u32 pad;
__u64 sync_fence_info;
};
--
2.5.0
[PATCH] staging/android: refactor SYNC_IOC_FILE_INFO
From: Gustavo Padovan
Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.
However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.
Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.
Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.
Also, info->sync_fence_info was converted to __u64 pointer to prevent
32bit compatibility issues.
An example userspace code for the later would be:
struct sync_file_info *info;
int err, size, num_fences;
info = malloc(sizeof(*info));
info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;
if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
sizeof(struct
sync_fence_info));
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}
v2: fix fence_info memory leak
v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()
Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size
Comments from Dan Carpenter
- fix info->sync_fence_info documentation
v4: remove allocated struct sync_file_info (comment from Maarten)
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync.c | 70 +
drivers/staging/android/uapi/sync.h | 9 ++---
2 files changed, 36 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index dc5f382..48ee175 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -479,13 +479,9 @@ err_put_fd:
return err;
}
-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+ struct sync_fence_info *info)
{
- struct sync_fence_info *info = data;
-
- if (size < sizeof(*info))
- return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,60 +491,60 @@ static int sync_fill_fence_info(struct fence *fence, void
*data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
- return sizeof(*info);
}
static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
{
- struct sync_file_info *info;
+ struct sync_file_info info;
+ struct sync_fence_info *fence_info = NULL;
__u32 size;
- __u32 len = 0;
int ret, i;
- if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+ if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
return -EFAULT;
- if (size < sizeof(struct sync_file_info))
- return -EINVAL;
+ /*
+* Passing num_fences = 0 means that userspace doesn't want to
+* retrieve any sync_fence_info. If num_fences = 0 we skip filling
+* sync_fence_info and return the actual number of fences on
+* info->num_fences.
+*/
+ if (!info.num_fences)
+ goto no_fences;
- if (size > 4096)
- size = 4096;
+ if (info.num_fences < sync_file->num_fences)
+ return -EINVAL;
- info = kzalloc(size, GFP_KERNEL);
- if (!info)
+ size = sync_file->num_fences * sizeof(*fence_info);
+ fence_info = kzalloc(size, GFP_KERNEL);
+ if (!fence_info)
return -ENOMEM;
- strlcpy(info->name, sync_file->name, sizeof(info->name));
- info->status = atomic_read(&sync_file->status);
- if (info->status >= 0)
- info->status = !info->status;
+ for (i = 0; i < sync_file->num_fences; ++i)
+ sync_fill_fence_info(sync_file->cbs[i].fence, &fence_info[i]);
- info->num_fences = sync_file->num_fences;
-
- len = sizeof(st
[PATCH] drm/vmwgfx: use *_32_bits() macros
Use the upper_32_bits() macro instead of the four line equivalent that triggers a GCC warning on 32 bits x86: drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function 'vmw_cmdbuf_header_submit': drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:297:25: warning: right shift count >= width of type [-Wshift-count-overflow] val = (header->handle >> 32); ^ And use the lower_32_bits() macro instead of and-ing with a 32 bits mask. Signed-off-by: Paul Bolle --- Note: compile tested only (I don't use any of vmware's products). drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c index 67cebb23c940..aa04fb0159a7 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c @@ -293,13 +293,10 @@ static int vmw_cmdbuf_header_submit(struct vmw_cmdbuf_header *header) struct vmw_cmdbuf_man *man = header->man; u32 val; - if (sizeof(header->handle) > 4) - val = (header->handle >> 32); - else - val = 0; + val = upper_32_bits(header->handle); vmw_write(man->dev_priv, SVGA_REG_COMMAND_HIGH, val); - val = (header->handle & 0xULL); + val = lower_32_bits(header->handle); val |= header->cb_context & SVGA_CB_CONTEXT_MASK; vmw_write(man->dev_priv, SVGA_REG_COMMAND_LOW, val); -- 2.4.3
[PATCH 0/2] drm/sti: support of interlaced content with Bottom Field
Hi Ville, Using DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD assumes that the userland controls the field presentation on the display output. This assumes that the userland is aware of the field actually on display and I think that this information is not provided by the DRM framework. Moreover the field management is something very close to the HW and I do not think that this shall be managed at userland level. As an alternative approach, the field management can be transparent to the userland, letting the driver doing the job. This is how the STI driver works: when handling an interlaced buffer it displays top and bottom fields at the right time, synchronized with the VSYNC signal (vsync for top field / vsync for btm field). The usage of the atomic mode is transparent for this processing. Clearly, the two methods are very different. The proposed patch fits with the second one. BR Fabien On 02/29/2016 09:41 PM, Ville Syrjälä wrote: > On Fri, Feb 12, 2016 at 10:26:03AM +0100, Vincent Abriou wrote: >> Interlaced video can have different scan order: >> Top Field First or Bottom Field First >> >> In case of video with interlaced content, this information should be >> propagated from the userland to the DRM kernel driver that will process the >> deinterlacing starting with the top or the bottom field first. >> That's why we introduce this new flag definition DRM_MODE_FB_BFF (Bottom >> Field >> First) that should be used jointly with the already existing >> DRM_MODE_FB_INTERLACED flag incase of interlaced video with Bottom Field >> First >> scan order should be processed. > The way I envisioned this long ago is that we would specify the > bff/tff at flip time. In fact we already have the > DRM_MODE_PRESENT_TOP_FIELD/DRM_MODE_PRESENT_BOTTOM_FIELD flags for > setplane. When doing bob deinterlacing these would choose the field > we're going to present, and when doing interlaced scanout these would > choose tff vs. bff. But that approach does fall short with atomic when > you want to flip multiple planes at once. > > One problem I see with making this part of the FB is that if you already > missed your original deadline for the first field, and you want to > actually present the second field instead, you're forced to create > another fb. So a plane property might be a bit more flexible. And the > same way as the setplane flags we could then share the properties for > bob deinterlacing field selection as well. There's no way to do bob > deinterlacing with fb flags, unless you create a separate fb for each > field. >
[PATCH v1 12/12] PCI: Simplify sysfs ROM cleanup
The value of pdev->rom_attr is the definitive indicator of the fact that
we're created a sysfs attribute. Check that rather than rom_size, which is
only used incidentally when deciding whether to create a sysfs attribute.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-sysfs.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 95d9e7b..a4cfa52 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1409,7 +1409,7 @@ int __must_check pci_create_sysfs_dev_files(struct
pci_dev *pdev)
return 0;
err_rom_file:
- if (rom_size) {
+ if (pdev->rom_attr) {
sysfs_remove_bin_file(&pdev->dev.kobj, pdev->rom_attr);
kfree(pdev->rom_attr);
pdev->rom_attr = NULL;
@@ -1447,8 +1447,6 @@ static void pci_remove_capabilities_sysfs(struct pci_dev
*dev)
*/
void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
{
- int rom_size = 0;
-
if (!sysfs_initialized)
return;
@@ -1461,18 +1459,13 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
pci_remove_resource_files(pdev);
- if (pci_resource_len(pdev, PCI_ROM_RESOURCE))
- rom_size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
- else if (pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW)
- rom_size = 0x2;
-
- if (rom_size && pdev->rom_attr) {
+ if (pdev->rom_attr) {
sysfs_remove_bin_file(&pdev->dev.kobj, pdev->rom_attr);
kfree(pdev->rom_attr);
+ pdev->rom_attr = NULL;
}
pci_remove_firmware_label_files(pdev);
-
}
static int __init pci_sysfs_init(void)
[PATCH v1 11/12] PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY
The IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY bits are unused.
Remove them and code that depends on them.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/remove.c |1 -
drivers/pci/rom.c | 31 +--
include/linux/ioport.h |2 --
3 files changed, 1 insertion(+), 33 deletions(-)
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 8a280e9..6b66329 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -7,7 +7,6 @@ static void pci_free_resources(struct pci_dev *dev)
{
int i;
- pci_cleanup_rom(dev);
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
struct resource *res = dev->resource + i;
if (res->parent)
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index 2a07f34..06663d3 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -128,12 +128,6 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t
*size)
loff_t start;
void __iomem *rom;
- if (res->flags & (IORESOURCE_ROM_COPY | IORESOURCE_ROM_BIOS_COPY)) {
- *size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
- return (void __iomem *)(unsigned long)
- pci_resource_start(pdev, PCI_ROM_RESOURCE);
- }
-
/* assign the ROM an address if it doesn't have one */
if (res->parent == NULL && pci_assign_resource(pdev, PCI_ROM_RESOURCE))
return NULL;
@@ -150,8 +144,7 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t
*size)
rom = ioremap(start, *size);
if (!rom) {
/* restore enable if ioremap fails */
- if (!(res->flags & (IORESOURCE_ROM_ENABLE |
- IORESOURCE_ROM_COPY)))
+ if (!(res->flags & IORESOURCE_ROM_ENABLE))
pci_disable_rom(pdev);
return NULL;
}
@@ -177,9 +170,6 @@ void pci_unmap_rom(struct pci_dev *pdev, void __iomem *rom)
{
struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
- if (res->flags & (IORESOURCE_ROM_COPY | IORESOURCE_ROM_BIOS_COPY))
- return;
-
iounmap(rom);
/* Disable again before continuing */
@@ -189,25 +179,6 @@ void pci_unmap_rom(struct pci_dev *pdev, void __iomem *rom)
EXPORT_SYMBOL(pci_unmap_rom);
/**
- * pci_cleanup_rom - free the ROM copy created by pci_map_rom_copy
- * @pdev: pointer to pci device struct
- *
- * Free the copied ROM if we allocated one.
- */
-void pci_cleanup_rom(struct pci_dev *pdev)
-{
- struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
-
- if (res->flags & IORESOURCE_ROM_COPY) {
- kfree((void *)(unsigned long)res->start);
- res->flags |= IORESOURCE_UNSET;
- res->flags &= ~IORESOURCE_ROM_COPY;
- res->start = 0;
- res->end = 0;
- }
-}
-
-/**
* pci_platform_rom - provides a pointer to any ROM image provided by the
* platform
* @pdev: pointer to pci device struct
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 2cf1667..29a6deb 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -99,8 +99,6 @@ struct resource {
/* PCI ROM control bits (IORESOURCE_BITS) */
#define IORESOURCE_ROM_ENABLE (1<<0) /* ROM is enabled, same as
PCI_ROM_ADDRESS_ENABLE */
#define IORESOURCE_ROM_SHADOW (1<<1) /* Use RAM image, not ROM BAR */
-#define IORESOURCE_ROM_COPY(1<<2) /* ROM is alloc'd copy,
resource field overlaid */
-#define IORESOURCE_ROM_BIOS_COPY (1<<3) /* ROM is BIOS copy, resource
field overlaid */
/* PCI control bits. Shares IORESOURCE_BITS with above PCI ROM. */
#define IORESOURCE_PCI_FIXED (1<<4) /* Do not move resource */
[PATCH v1 10/12] MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in shadow ROM resource
Loongson 3 used the IORESOURCE_ROM_COPY flag for its ROM resource. There are two problems with this: - When IORESOURCE_ROM_COPY is set, pci_map_rom() assumes the resource contains virtual addresses, so it doesn't ioremap the resource. This implies loongson_sysconf.vgabios_addr is a virtual address. That's a problem because resources should contain CPU *physical* addresses not virtual addresses. - When IORESOURCE_ROM_COPY is set, pci_cleanup_rom() calls kfree() on the resource. We did not kmalloc() the loongson_sysconf.vgabios_addr area, so it is incorrect to kfree() it. If we're using a shadow copy in RAM for the Loongson 3 VGA BIOS area, disable the ROM BAR and release the address space it was consuming. Use IORESOURCE_ROM_SHADOW instead of IORESOURCE_ROM_COPY. This means the struct resource contains CPU physical addresses, and pci_map_rom() will ioremap() it as needed. Signed-off-by: Bjorn Helgaas --- arch/mips/pci/fixup-loongson3.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/mips/pci/fixup-loongson3.c b/arch/mips/pci/fixup-loongson3.c index b66b1eb..c015ca1 100644 --- a/arch/mips/pci/fixup-loongson3.c +++ b/arch/mips/pci/fixup-loongson3.c @@ -48,9 +48,14 @@ static void pci_fixup_radeon(struct pci_dev *pdev) if (!loongson_sysconf.vgabios_addr) return; - res->start = loongson_sysconf.vgabios_addr; + pci_disable_rom(pdev); + if (res->parent) + release_resource(res); + + res->start = virt_to_phys(loongson_sysconf.vgabios_addr); res->end = res->start + 256*1024 - 1; - res->flags |= IORESOURCE_ROM_COPY; + res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW | +IORESOURCE_PCI_FIXED; dev_info(&pdev->dev, "BAR %d: assigned %pR for Radeon ROM\n", PCI_ROM_RESOURCE, res);
[PATCH v1 09/12] MIPS: Loongson 3: Use temporary struct resource * to avoid repetition
Use a temporary struct resource pointer to avoid needless repetition of
"pdev->resource[PCI_ROM_RESOURCE]". No functional change intended.
Signed-off-by: Bjorn Helgaas
---
arch/mips/pci/fixup-loongson3.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/mips/pci/fixup-loongson3.c b/arch/mips/pci/fixup-loongson3.c
index d708ae4..b66b1eb 100644
--- a/arch/mips/pci/fixup-loongson3.c
+++ b/arch/mips/pci/fixup-loongson3.c
@@ -40,20 +40,20 @@ int __init pcibios_map_irq(const struct pci_dev *dev, u8
slot, u8 pin)
static void pci_fixup_radeon(struct pci_dev *pdev)
{
- if (pdev->resource[PCI_ROM_RESOURCE].start)
+ struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
+
+ if (res->start)
return;
if (!loongson_sysconf.vgabios_addr)
return;
- pdev->resource[PCI_ROM_RESOURCE].start =
- loongson_sysconf.vgabios_addr;
- pdev->resource[PCI_ROM_RESOURCE].end =
- loongson_sysconf.vgabios_addr + 256*1024 - 1;
- pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_COPY;
+ res->start = loongson_sysconf.vgabios_addr;
+ res->end = res->start + 256*1024 - 1;
+ res->flags |= IORESOURCE_ROM_COPY;
dev_info(&pdev->dev, "BAR %d: assigned %pR for Radeon ROM\n",
- PCI_ROM_RESOURCE, &pdev->resource[PCI_ROM_RESOURCE]);
+PCI_ROM_RESOURCE, res);
}
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
[PATCH v1 08/12] ia64/PCI: Keep CPU physical (not virtual) addresses in shadow ROM resource
A struct resource contains CPU physical addresses, not virtual addresses.
But sn_acpi_slot_fixup() and sn_io_slot_fixup() stored the virtual address
of a shadow ROM copy in the resource. To compensate, pci_map_rom() had a
special case that returned the resource address directly rather than
calling ioremap() on it.
When we're using a shadow copy in RAM or PROM, disable the ROM BAR and
release the address space it was consuming.
Store the CPU physical (not virtual) address in the shadow ROM resource,
and mark the resource as IORESOURCE_ROM_SHADOW so we use the normal
pci_map_rom() path that ioremaps the copy.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/sn/kernel/io_acpi_init.c | 18 +++---
arch/ia64/sn/kernel/io_init.c | 17 +
2 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/arch/ia64/sn/kernel/io_acpi_init.c
b/arch/ia64/sn/kernel/io_acpi_init.c
index 815c291..231234c 100644
--- a/arch/ia64/sn/kernel/io_acpi_init.c
+++ b/arch/ia64/sn/kernel/io_acpi_init.c
@@ -430,7 +430,7 @@ sn_acpi_slot_fixup(struct pci_dev *dev)
struct pcidev_info *pcidev_info = NULL;
struct sn_irq_info *sn_irq_info = NULL;
struct resource *res;
- size_t image_size, size;
+ size_t size;
if (sn_acpi_get_pcidev_info(dev, &pcidev_info, &sn_irq_info)) {
panic("%s: Failure obtaining pcidev_info for %s\n",
@@ -444,13 +444,17 @@ sn_acpi_slot_fixup(struct pci_dev *dev)
* of the shadowed copy, and the actual length of the ROM image.
*/
size = pci_resource_len(dev, PCI_ROM_RESOURCE);
- addr =
ioremap(pcidev_info->pdi_pio_mapped_addr[PCI_ROM_RESOURCE],
- size);
- image_size = pci_get_rom_size(dev, addr, size);
+
res = &dev->resource[PCI_ROM_RESOURCE];
- res->start = (unsigned long) addr;
- res->end = (unsigned long) addr + image_size - 1;
- res->flags |= IORESOURCE_ROM_BIOS_COPY;
+
+ pci_disable_rom(dev);
+ if (res->parent)
+ release_resource(res);
+
+ res->start = pcidev_info->pdi_pio_mapped_addr[PCI_ROM_RESOURCE];
+ res->end = res->start + size - 1;
+ res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
+IORESOURCE_PCI_FIXED;
}
sn_pci_fixup_slot(dev, pcidev_info, sn_irq_info);
}
diff --git a/arch/ia64/sn/kernel/io_init.c b/arch/ia64/sn/kernel/io_init.c
index 0227e20..c15a41e 100644
--- a/arch/ia64/sn/kernel/io_init.c
+++ b/arch/ia64/sn/kernel/io_init.c
@@ -185,8 +185,7 @@ sn_io_slot_fixup(struct pci_dev *dev)
if (size == 0)
continue;
- res->start = ioremap(pcidev_info->pdi_pio_mapped_addr[idx],
-size + 1);
+ res->start = pcidev_info->pdi_pio_mapped_addr[idx];
res->end = addr + size;
/*
@@ -201,18 +200,12 @@ sn_io_slot_fixup(struct pci_dev *dev)
else
insert_resource(&iomem_resource, res);
/*
-* If ROM, set the actual ROM image size, and mark as
-* shadowed in PROM.
+* If ROM, mark as shadowed in PROM.
*/
if (idx == PCI_ROM_RESOURCE) {
- size_t image_size;
- void __iomem *rom;
-
- rom = ioremap(pci_resource_start(dev, PCI_ROM_RESOURCE),
- size + 1);
- image_size = pci_get_rom_size(dev, rom, size + 1);
- res->end = res->start + image_size - 1;
- res->flags |= IORESOURCE_ROM_BIOS_COPY;
+ pci_disable_rom(dev);
+ res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
+IORESOURCE_PCI_FIXED;
}
}
[PATCH v1 07/12] ia64/PCI: Use ioremap() instead of open-coded equivalent
Depositing __IA64_UNCACHED_OFFSET in the upper address bits is essentially equivalent to ioremap(): it converts a CPU physical address to a virtual address using the ia64 uncacheable identity map. Call ioremap() instead of doing the phys-to-virt conversion manually with __IA64_UNCACHED_OFFSET. Note that this makes it obvious that (a) we're putting a virtual address in a struct resource, and (b) we're passing a virtual address to ioremap() below in the PCI_ROM_RESOURCE case. These are both pre-existing problems that I'll resolve next. Signed-off-by: Bjorn Helgaas --- arch/ia64/sn/kernel/io_init.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/ia64/sn/kernel/io_init.c b/arch/ia64/sn/kernel/io_init.c index 40c0263..0227e20 100644 --- a/arch/ia64/sn/kernel/io_init.c +++ b/arch/ia64/sn/kernel/io_init.c @@ -185,9 +185,8 @@ sn_io_slot_fixup(struct pci_dev *dev) if (size == 0) continue; - addr = pcidev_info->pdi_pio_mapped_addr[idx]; - addr = ((addr << 4) >> 4) | __IA64_UNCACHED_OFFSET; - res->start = addr; + res->start = ioremap(pcidev_info->pdi_pio_mapped_addr[idx], +size + 1); res->end = addr + size; /*
[PATCH v1 06/12] ia64/PCI: Use temporary struct resource * to avoid repetition
Use a temporary struct resource pointer to avoid needless repetition of
"dev->resource[idx]". No functional change intended.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/sn/kernel/io_acpi_init.c | 10 +
arch/ia64/sn/kernel/io_init.c | 39
2 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/arch/ia64/sn/kernel/io_acpi_init.c
b/arch/ia64/sn/kernel/io_acpi_init.c
index 0640739..815c291 100644
--- a/arch/ia64/sn/kernel/io_acpi_init.c
+++ b/arch/ia64/sn/kernel/io_acpi_init.c
@@ -429,6 +429,7 @@ sn_acpi_slot_fixup(struct pci_dev *dev)
void __iomem *addr;
struct pcidev_info *pcidev_info = NULL;
struct sn_irq_info *sn_irq_info = NULL;
+ struct resource *res;
size_t image_size, size;
if (sn_acpi_get_pcidev_info(dev, &pcidev_info, &sn_irq_info)) {
@@ -446,14 +447,13 @@ sn_acpi_slot_fixup(struct pci_dev *dev)
addr =
ioremap(pcidev_info->pdi_pio_mapped_addr[PCI_ROM_RESOURCE],
size);
image_size = pci_get_rom_size(dev, addr, size);
- dev->resource[PCI_ROM_RESOURCE].start = (unsigned long) addr;
- dev->resource[PCI_ROM_RESOURCE].end =
- (unsigned long) addr + image_size - 1;
- dev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_BIOS_COPY;
+ res = &dev->resource[PCI_ROM_RESOURCE];
+ res->start = (unsigned long) addr;
+ res->end = (unsigned long) addr + image_size - 1;
+ res->flags |= IORESOURCE_ROM_BIOS_COPY;
}
sn_pci_fixup_slot(dev, pcidev_info, sn_irq_info);
}
-
EXPORT_SYMBOL(sn_acpi_slot_fixup);
diff --git a/arch/ia64/sn/kernel/io_init.c b/arch/ia64/sn/kernel/io_init.c
index 1be65eb..40c0263 100644
--- a/arch/ia64/sn/kernel/io_init.c
+++ b/arch/ia64/sn/kernel/io_init.c
@@ -150,7 +150,8 @@ void
sn_io_slot_fixup(struct pci_dev *dev)
{
int idx;
- unsigned long addr, end, size, start;
+ struct resource *res;
+ unsigned long addr, size;
struct pcidev_info *pcidev_info;
struct sn_irq_info *sn_irq_info;
int status;
@@ -175,33 +176,31 @@ sn_io_slot_fixup(struct pci_dev *dev)
/* Copy over PIO Mapped Addresses */
for (idx = 0; idx <= PCI_ROM_RESOURCE; idx++) {
-
- if (!pcidev_info->pdi_pio_mapped_addr[idx]) {
+ if (!pcidev_info->pdi_pio_mapped_addr[idx])
continue;
- }
- start = dev->resource[idx].start;
- end = dev->resource[idx].end;
- size = end - start;
- if (size == 0) {
+ res = &dev->resource[idx];
+
+ size = res->end - res->start;
+ if (size == 0)
continue;
- }
+
addr = pcidev_info->pdi_pio_mapped_addr[idx];
addr = ((addr << 4) >> 4) | __IA64_UNCACHED_OFFSET;
- dev->resource[idx].start = addr;
- dev->resource[idx].end = addr + size;
+ res->start = addr;
+ res->end = addr + size;
/*
* if it's already in the device structure, remove it before
* inserting
*/
- if (dev->resource[idx].parent &&
dev->resource[idx].parent->child)
- release_resource(&dev->resource[idx]);
+ if (res->parent && res->parent->child)
+ release_resource(res);
- if (dev->resource[idx].flags & IORESOURCE_IO)
- insert_resource(&ioport_resource, &dev->resource[idx]);
+ if (res->flags & IORESOURCE_IO)
+ insert_resource(&ioport_resource, res);
else
- insert_resource(&iomem_resource, &dev->resource[idx]);
+ insert_resource(&iomem_resource, res);
/*
* If ROM, set the actual ROM image size, and mark as
* shadowed in PROM.
@@ -213,17 +212,13 @@ sn_io_slot_fixup(struct pci_dev *dev)
rom = ioremap(pci_resource_start(dev, PCI_ROM_RESOURCE),
size + 1);
image_size = pci_get_rom_size(dev, rom, size + 1);
- dev->resource[PCI_ROM_RESOURCE].end =
- dev->resource[PCI_ROM_RESOURCE].start +
- image_size - 1;
- dev->resource[PCI_ROM_RESOURCE].flags |=
-IORESOURCE_ROM_BIOS_COPY;
+ res->end = res->start + image_size - 1;
+ res->flags |= IORESOURCE_ROM_BIOS_COPY;
}
}
sn_pci_fixup_slot(dev, pcidev_info, sn_irq_info);
}
-
EXPORT_SYMBOL(sn_io_slot_fixup);
/*
[PATCH v1 05/12] PCI: Clean up pci_map_rom() whitespace
Remove unnecessary indentation in pci_map_rom(). This is logically part of
the previous patch; I split it out to make the critical changes in that
patch more obvious. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/rom.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index 80e82b1..2a07f34 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -128,25 +128,24 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t
*size)
loff_t start;
void __iomem *rom;
- if (res->flags &
- (IORESOURCE_ROM_COPY | IORESOURCE_ROM_BIOS_COPY)) {
- *size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
- return (void __iomem *)(unsigned long)
- pci_resource_start(pdev, PCI_ROM_RESOURCE);
- } else {
- /* assign the ROM an address if it doesn't have one */
- if (res->parent == NULL &&
- pci_assign_resource(pdev, PCI_ROM_RESOURCE))
- return NULL;
- start = pci_resource_start(pdev, PCI_ROM_RESOURCE);
- *size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
- if (*size == 0)
- return NULL;
-
- /* Enable ROM space decodes */
- if (pci_enable_rom(pdev))
- return NULL;
- }
+ if (res->flags & (IORESOURCE_ROM_COPY | IORESOURCE_ROM_BIOS_COPY)) {
+ *size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
+ return (void __iomem *)(unsigned long)
+ pci_resource_start(pdev, PCI_ROM_RESOURCE);
+ }
+
+ /* assign the ROM an address if it doesn't have one */
+ if (res->parent == NULL && pci_assign_resource(pdev, PCI_ROM_RESOURCE))
+ return NULL;
+
+ start = pci_resource_start(pdev, PCI_ROM_RESOURCE);
+ *size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
+ if (*size == 0)
+ return NULL;
+
+ /* Enable ROM space decodes */
+ if (pci_enable_rom(pdev))
+ return NULL;
rom = ioremap(start, *size);
if (!rom) {
[PATCH v1 04/12] PCI: Set ROM shadow location in arch code, not in PCI core
IORESOURCE_ROM_SHADOW means there is a copy of a device's option ROM in
RAM. The existence of such a copy and its location are arch-specific.
Previously the IORESOURCE_ROM_SHADOW flag was set in arch code, but the
0xC-0xD location was hard-coded into the PCI core.
If we're using a shadow copy in RAM, disable the ROM BAR and release the
address space it was consuming. Move the location information from the PCI
core to the arch code that sets IORESOURCE_ROM_SHADOW. Save the location
of the RAM copy in the struct resource for PCI_ROM_RESOURCE.
After this change, pci_map_rom() will call pci_assign_resource() and
pci_enable_rom() for these IORESOURCE_ROM_SHADOW resources, which we did
not do before. This is safe because:
- pci_assign_resource() will do nothing because the resource is marked
IORESOURCE_PCI_FIXED, which means we can't move it, and
- pci_enable_rom() will not turn on the ROM BAR's enable bit because the
resource is marked IORESOURCE_ROM_SHADOW, which means it is in RAM
rather than in PCI memory space.
Storing the location in the struct resource means "lspci" will show the
shadow location, not the value from the ROM BAR.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/pci/fixup.c | 22 --
arch/x86/pci/fixup.c | 22 --
drivers/pci/rom.c | 11 ---
include/linux/ioport.h |2 +-
4 files changed, 33 insertions(+), 24 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index fd9ceff..41caa99 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -17,14 +17,14 @@
*
* The standard boot ROM sequence for an x86 machine uses the BIOS
* to select an initial video card for boot display. This boot video
- * card will have it's BIOS copied to C in system RAM.
+ * card will have its BIOS copied to 0xC in system RAM.
* IORESOURCE_ROM_SHADOW is used to associate the boot video
* card with this copy. On laptops this copy has to be used since
* the main ROM may be compressed or combined with another image.
* See pci_map_rom() for use of this flag. Before marking the device
* with IORESOURCE_ROM_SHADOW check if a vga_default_device is already set
- * by either arch cde or vga-arbitration, if so only apply the fixup to this
- * already determined primary video card.
+ * by either arch code or vga-arbitration; if so only apply the fixup to this
+ * already-determined primary video card.
*/
static void pci_fixup_video(struct pci_dev *pdev)
@@ -32,6 +32,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
struct pci_dev *bridge;
struct pci_bus *bus;
u16 config;
+ struct resource *res;
if ((strcmp(ia64_platform_name, "dig") != 0)
&& (strcmp(ia64_platform_name, "hpzx1") != 0))
@@ -61,9 +62,18 @@ static void pci_fixup_video(struct pci_dev *pdev)
if (!vga_default_device() || pdev == vga_default_device()) {
pci_read_config_word(pdev, PCI_COMMAND, &config);
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
- pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW |
- IORESOURCE_PCI_FIXED;
- dev_printk(KERN_DEBUG, &pdev->dev, "Video device with
shadowed ROM\n");
+ res = &pdev->resource[PCI_ROM_RESOURCE];
+
+ pci_disable_rom(pdev);
+ if (res->parent)
+ release_resource(res);
+
+ res->start = 0xC;
+ res->end = res->start + 0x2 - 1;
+ res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
+IORESOURCE_PCI_FIXED;
+ dev_info(&pdev->dev, "Video device with shadowed ROM at
%pR\n",
+res);
}
}
}
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index dac027c..b7de192 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -297,14 +297,14 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_MCH_PC1,pcie_r
*
* The standard boot ROM sequence for an x86 machine uses the BIOS
* to select an initial video card for boot display. This boot video
- * card will have it's BIOS copied to C in system RAM.
+ * card will have its BIOS copied to 0xC in system RAM.
* IORESOURCE_ROM_SHADOW is used to associate the boot video
* card with this copy. On laptops this copy has to be used since
* the main ROM may be compressed or combined with another image.
* See pci_map_rom() for use of this flag. Before marking the device
* with IORESOURCE_ROM_SHADOW check if a vga_default_device is already set
- * by either arch cde or vga-arbitration, if so only apply the fixup to this
- * already determined primary video card.
+ * by either arch code or vga-arbitration; if so only apply the fixup to
[PATCH v1 03/12] PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy
If we're using a RAM shadow copy instead of the ROM BAR, we don't need to
touch the ROM BAR enable bit.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/rom.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index 9eaca39..5da8d06 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -24,13 +24,17 @@
*/
int pci_enable_rom(struct pci_dev *pdev)
{
- struct resource *res = pdev->resource + PCI_ROM_RESOURCE;
+ struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
struct pci_bus_region region;
u32 rom_addr;
if (!res->flags)
return -1;
+ /* Nothing to enable if we're using a shadow copy in RAM */
+ if (res->flags & IORESOURCE_ROM_SHADOW)
+ return 0;
+
pcibios_resource_to_bus(pdev->bus, ®ion, res);
pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_addr);
rom_addr &= ~PCI_ROM_ADDRESS_MASK;
@@ -49,7 +53,12 @@ EXPORT_SYMBOL_GPL(pci_enable_rom);
*/
void pci_disable_rom(struct pci_dev *pdev)
{
+ struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
u32 rom_addr;
+
+ if (res->flags & IORESOURCE_ROM_SHADOW)
+ return;
+
pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_addr);
rom_addr &= ~PCI_ROM_ADDRESS_ENABLE;
pci_write_config_dword(pdev, pdev->rom_base_reg, rom_addr);
@@ -154,7 +163,6 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t
*size)
if (!rom) {
/* restore enable if ioremap fails */
if (!(res->flags & (IORESOURCE_ROM_ENABLE |
- IORESOURCE_ROM_SHADOW |
IORESOURCE_ROM_COPY)))
pci_disable_rom(pdev);
return NULL;
@@ -186,8 +194,8 @@ void pci_unmap_rom(struct pci_dev *pdev, void __iomem *rom)
iounmap(rom);
- /* Disable again before continuing, leave enabled if pci=rom */
- if (!(res->flags & (IORESOURCE_ROM_ENABLE | IORESOURCE_ROM_SHADOW)))
+ /* Disable again before continuing */
+ if (!(res->flags & IORESOURCE_ROM_ENABLE))
pci_disable_rom(pdev);
}
EXPORT_SYMBOL(pci_unmap_rom);
[PATCH v1 02/12] PCI: Don't assign or reassign immutable resources
IORESOURCE_PCI_FIXED means the resource can't be moved, so if it's set,
don't bother trying to assign or reassign the resource.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/setup-res.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 604011e..66c4d8f 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -276,6 +276,9 @@ int pci_assign_resource(struct pci_dev *dev, int resno)
resource_size_t align, size;
int ret;
+ if (res->flags & IORESOURCE_PCI_FIXED)
+ return 0;
+
res->flags |= IORESOURCE_UNSET;
align = pci_resource_alignment(dev, res);
if (!align) {
@@ -321,6 +324,9 @@ int pci_reassign_resource(struct pci_dev *dev, int resno,
resource_size_t addsiz
resource_size_t new_size;
int ret;
+ if (res->flags & IORESOURCE_PCI_FIXED)
+ return 0;
+
flags = res->flags;
res->flags |= IORESOURCE_UNSET;
if (!res->parent) {
[PATCH v1 01/12] PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED
A shadow copy of an option ROM is placed by the BIOS as a fixed address.
Set IORESOURCE_PCI_FIXED to indicate that we can't move the shadow copy.
This prevents warnings like the following when we assign resources:
BAR 6: [??? 0x flags 0x2] has bogus alignment
This warning is emitted by pdev_sort_resources(), which already ignores
IORESOURCE_PCI_FIXED resources.
Link:
http://lkml.kernel.org/r/CA+55aFyVMfTBB0oz_yx8+eQOEJnzGtCsYSj9QuhEpdZ9BHdq5A at
mail.gmail.com
Signed-off-by: Bjorn Helgaas
---
arch/ia64/pci/fixup.c |3 ++-
arch/x86/pci/fixup.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index fc505d5..fd9ceff 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -61,7 +61,8 @@ static void pci_fixup_video(struct pci_dev *pdev)
if (!vga_default_device() || pdev == vga_default_device()) {
pci_read_config_word(pdev, PCI_COMMAND, &config);
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
- pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW;
+ pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW |
+ IORESOURCE_PCI_FIXED;
dev_printk(KERN_DEBUG, &pdev->dev, "Video device with
shadowed ROM\n");
}
}
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 0ae7e9f..dac027c 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -336,7 +336,8 @@ static void pci_fixup_video(struct pci_dev *pdev)
if (!vga_default_device() || pdev == vga_default_device()) {
pci_read_config_word(pdev, PCI_COMMAND, &config);
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
- pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW;
+ pdev->resource[PCI_ROM_RESOURCE].flags |=
IORESOURCE_ROM_SHADOW |
+ IORESOURCE_PCI_FIXED;
dev_printk(KERN_DEBUG, &pdev->dev, "Video device with
shadowed ROM\n");
}
}
[PATCH v1 00/12] PCI: Rework shadow ROM handling
The purpose of this series is to: - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment" messages reported by Linus [1], Andy [2], and others. - Move arch-specific shadow ROM location knowledge, e.g., 0xC-0xD, from PCI core to arch code. - Fix the ia64 and MIPS Loongson 3 oddity of keeping virtual addresses in shadow ROM struct resource (resources should always contain *physical* addresses). - Remove now-unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY flags. This series is based on v4.5-rc1, and it's available on my pci/resource git branch (along with a couple tiny unrelated patches) at [3]. Bjorn [1] http://lkml.kernel.org/r/CA+55aFyVMfTBB0oz_yx8+eQOEJnzGtCsYSj9QuhEpdZ9BHdq5A at mail.gmail.com [2] http://lkml.kernel.org/r/CALCETrV+RwNPzxyL8UVNsrAGu-6cCzD_Cc9PFJT2NCTJPLZZiw at mail.gmail.com [3] https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/resource --- Bjorn Helgaas (12): PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED PCI: Don't assign or reassign immutable resources PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy PCI: Set ROM shadow location in arch code, not in PCI core PCI: Clean up pci_map_rom() whitespace ia64/PCI: Use temporary struct resource * to avoid repetition ia64/PCI: Use ioremap() instead of open-coded equivalent ia64/PCI: Keep CPU physical (not virtual) addresses in shadow ROM resource MIPS: Loongson 3: Use temporary struct resource * to avoid repetition MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in shadow ROM resource PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY PCI: Simplify sysfs ROM cleanup arch/ia64/pci/fixup.c | 21 +++-- arch/ia64/sn/kernel/io_acpi_init.c | 22 ++ arch/ia64/sn/kernel/io_init.c | 51 -- arch/mips/pci/fixup-loongson3.c| 19 +--- arch/x86/pci/fixup.c | 21 +++-- drivers/pci/pci-sysfs.c| 13 +- drivers/pci/remove.c |1 drivers/pci/rom.c | 83 +++- drivers/pci/setup-res.c|6 +++ include/linux/ioport.h |4 -- 10 files changed, 111 insertions(+), 130 deletions(-)
[git pull] drm/sti: drm-next 2016-02-26
Hello Dave, Here are sti patches for drm-next. It brings: - The support of the atomic_check for the planes and minor fixes for planes - The support of the vendor specific infoframe for HDMI and the support of 2 HDMI properties related to the connector - The support of the DVO solving panel detection issue and timing issue. - The support of debugfs for connectors, encoders, crtcs and planes. The following changes since commit 44ab4042178bd596275927ea050980aa4257581b: Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next (2016-02-26 13:02:57 +1000) are available in the git repository at: http://git.linaro.org/people/benjamin.gaignard/kernel.git 2016-02-26-st-drm-next for you to fetch changes up to 52807ae90e76b69fd01688d6031190271536d29f: drm/sti: use u32 to store DMA addresses (2016-03-03 09:17:17 +0100) Regards, Vincent Arnd Bergmann (1): drm/sti: use u32 to store DMA addresses Benjamin Gaignard (1): drm: sti: remove sti_gem_prime_export hack Bich Hemon (6): drm/sti: awg_utils code cleanup drm/sti: GDP planes only support RGB formats drm/sti: fallback for GDP scaling drm/sti: adapt YUV colorspace in display pipeline drm/sti: adjust delay for DVO drm/sti: fix dvo data_enable signal Fabien Dessenne (2): drm/sti: clarify the skip frame/field message drm/sti: force cursor CLUT fetch Vincent Abriou (22): drm/sti: update VTG timing programming drm/sti: GDP cropping fails when we remove 2 pixels horizontally drm/sti: implement atomic_check for the planes drm/sti: do not clip RGB/YUV component value at connector side drm/sti: fix panel detection for DVO connector drm/sti: add missing encoder cleanup for DVO connector drm/sti: reset HD DACS when HDA connector is created drm/sti: HDMI infoframe transmission mode not take into account drm/sti: reset infoframe transmission when HDMI is stopped drm/sti: add HDMI vendor specific infoframe drm/sti: add colorspace property to the HDMI connector drm/sti: add hdmi_mode property for HDMI connector drm/sti: add debugfs entries for HDMI connector drm/sti: add debugfs entries for DVO connector drm/sti: add debugfs entries for HDA connector drm/sti: add debugfs entries for CURSOR plane drm/sti: add debugfs entries for GDP planes drm/sti: add debugfs entries for HQVDP plane drm/sti: add debugfs entries for VID plane drm/sti: add debugfs entries for MIXER crtc drm/sti: add debugfs entries for TVOUT encoders drm/sti: add debugfs fps_show/fps_get mechanism for planes benjamin.gaignard at linaro.org (4): drm/sti: fix potential crash in gdp drm/sti: set CRTC modesetting parameters drm/sti: fix cursor coordinates drm/sti: set DRIVER_ATOMIC for sti drivers/gpu/drm/sti/sti_awg_utils.c | 78 +++--- drivers/gpu/drm/sti/sti_compositor.c | 4 +- drivers/gpu/drm/sti/sti_crtc.c | 1 + drivers/gpu/drm/sti/sti_cursor.c | 184 +++--- drivers/gpu/drm/sti/sti_drv.c| 141 ++- drivers/gpu/drm/sti/sti_dvo.c| 78 +- drivers/gpu/drm/sti/sti_gdp.c| 476 --- drivers/gpu/drm/sti/sti_hda.c| 108 +++- drivers/gpu/drm/sti/sti_hdmi.c | 400 +++-- drivers/gpu/drm/sti/sti_hdmi.h | 31 ++- drivers/gpu/drm/sti/sti_hqvdp.c | 447 ++-- drivers/gpu/drm/sti/sti_mixer.c | 146 ++- drivers/gpu/drm/sti/sti_mixer.h | 4 +- drivers/gpu/drm/sti/sti_plane.c | 63 + drivers/gpu/drm/sti/sti_plane.h | 17 ++ drivers/gpu/drm/sti/sti_tvout.c | 295 +- drivers/gpu/drm/sti/sti_vid.c| 125 - drivers/gpu/drm/sti/sti_vid.h| 4 +- drivers/gpu/drm/sti/sti_vtg.c| 200 ++- drivers/gpu/drm/sti/sti_vtg.h| 5 + 20 files changed, 2391 insertions(+), 416 deletions(-)
[PATCH v6 5/6] staging/android: refactor SYNC_IOC_FILE_INFO
Op 02-03-16 om 20:52 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer
>
> Now num_fences can be filled by the caller to inform how many fences it
> wants to retrieve from the kernel. If the num_fences passed is greater
> than zero info->sync_fence_info should point to a buffer with enough space
> to fit all fences.
>
> However if num_fences passed to the kernel is 0, the kernel will reply
> with number of fences of the sync_file.
>
> Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
> in a first call with num_fences = 0 userspace will receive the actual
> number of fences in the num_fences filed.
>
> Then it can allocate a buffer with the correct size on sync_fence_info and
> call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
> in the sync_file.
>
> Also, info->sync_fence_info was converted to __u64 pointer to prevent
> 32bit compatibility issues.
>
> An example userspace code for the later would be:
>
> struct sync_file_info *info;
> int err, size, num_fences;
>
> info = malloc(sizeof(*info));
>
> info.flags = 0;
> err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> num_fences = info->num_fences;
>
> if (num_fences) {
> info.flags = 0;
> size = sizeof(struct sync_fence_info) * num_fences;
> info->num_fences = num_fences;
> info->sync_fence_info = (uint64_t) calloc(num_fences,
> sizeof(struct
> sync_fence_info));
>
> err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> }
>
> v2: fix fence_info memory leak
>
> v3: Comments from Emil Velikov
> - improve commit message
> - remove __u64 cast
> - remove check for output fields in file_info
> - clean up sync_fill_fence_info()
>
> Comments from Maarten Lankhorst
> - remove in.num_fences && !in.sync_fence_info check
> - remove info->len and use only num_fences to calculate size
>
> Comments from Dan Carpenter
> - fix info->sync_fence_info documentation
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/staging/android/sync.c | 64
> -
> drivers/staging/android/uapi/sync.h | 9 ++
> 2 files changed, 38 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index dc5f382..3604e453 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -479,13 +479,9 @@ err_put_fd:
> return err;
> }
>
> -static int sync_fill_fence_info(struct fence *fence, void *data, int size)
> +static void sync_fill_fence_info(struct fence *fence,
> + struct sync_fence_info *info)
> {
> - struct sync_fence_info *info = data;
> -
> - if (size < sizeof(*info))
> - return -ENOMEM;
> -
> strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
> sizeof(info->obj_name));
> strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
> @@ -495,28 +491,20 @@ static int sync_fill_fence_info(struct fence *fence,
> void *data, int size)
> else
> info->status = 0;
> info->timestamp_ns = ktime_to_ns(fence->timestamp);
> -
> - return sizeof(*info);
> }
>
> static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> unsigned long arg)
> {
> - struct sync_file_info *info;
> + struct sync_file_info in, *info;
Why put one copy on the stack, and allocate a second?
With sync_file_info now being a fixed size just put 1 copy on the stack from
userspace,
run some sanity checks first, put in the new values and copy it back to
userspace without additional memory allocation.
The rest looks good now. :)
~Maarten
[PATCH 0/8] drm/bochs: convert bochs to atomic mode-setting
Hi, > > Did testing a while back & reported back to John (not sure this was in > > public on the list as we had some ping-ping emails beforehand due to > > some problems of applying the patches). No new version of the series > > since. > > > The only comment that I can see is this one [1] which was addressed a > couple of days later [2]. > If you have any other comments please bring them up publicly. Digged the mails up in the archive. First, v2 posting was apparently incomplete, only one of the 8 patches landed in my inbox. John pointed me to https://github.com/zhjwpku/gsoc/commits/20150720_no_gpu_addr which I've used to test things. Second, page flipping failed in testing. cheers, Gerd
[PATCH v3 7/7] drm/atomic: Clean up update_connector_routing.
connector_state->crtc can no longer be unset by accident,
so that check can be removed. The other code open-codes
drm_atomic_get_existing_crtc_state, so use that.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2395201eb7ab..9f0d16eb04b2 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -265,7 +265,7 @@ update_connector_routing(struct drm_atomic_state *state,
const struct drm_connector_helper_funcs *funcs;
struct drm_encoder *new_encoder;
struct drm_crtc_state *crtc_state;
- int idx, ret;
+ int ret;
DRM_DEBUG_ATOMIC("Updating routing for [CONNECTOR:%d:%s]\n",
connector->base.id,
@@ -273,16 +273,12 @@ update_connector_routing(struct drm_atomic_state *state,
if (connector->state->crtc != connector_state->crtc) {
if (connector->state->crtc) {
- idx = drm_crtc_index(connector->state->crtc);
-
- crtc_state = state->crtc_states[idx];
+ crtc_state = drm_atomic_get_existing_crtc_state(state,
connector->state->crtc);
crtc_state->connectors_changed = true;
}
if (connector_state->crtc) {
- idx = drm_crtc_index(connector_state->crtc);
-
- crtc_state = state->crtc_states[idx];
+ crtc_state = drm_atomic_get_existing_crtc_state(state,
connector_state->crtc);
crtc_state->connectors_changed = true;
}
}
@@ -336,14 +332,9 @@ update_connector_routing(struct drm_atomic_state *state,
steal_encoder(state, new_encoder);
- if (WARN_ON(!connector_state->crtc))
- return -EINVAL;
-
set_best_encoder(state, connector_state, new_encoder);
- idx = drm_crtc_index(connector_state->crtc);
-
- crtc_state = state->crtc_states[idx];
+ crtc_state = drm_atomic_get_existing_crtc_state(state,
connector_state->crtc);
crtc_state->connectors_changed = true;
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
[CRTC:%d:%s]\n",
--
2.1.0
[PATCH v3 6/7] drm/atomic: Clean up steal_encoder, v2.
Now that only encoders can be stolen that are part of the state
steal_encoder no longer needs to inspect all connectors,
just those that are part of the atomic state.
Changes since v1:
- Change return value to void, can no longer fail.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index bb60148c5c8d..2395201eb7ab 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -227,25 +227,18 @@ set_best_encoder(struct drm_atomic_state *state,
conn_state->best_encoder = encoder;
}
-static int
+static void
steal_encoder(struct drm_atomic_state *state,
struct drm_encoder *encoder)
{
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
struct drm_connector_state *connector_state;
+ int i;
- drm_for_each_connector(connector, state->dev) {
+ for_each_connector_in_state(state, connector, connector_state, i) {
struct drm_crtc *encoder_crtc;
- if (connector->state->best_encoder != encoder)
- continue;
-
- connector_state = drm_atomic_get_connector_state(state,
-connector);
- if (IS_ERR(connector_state))
- return PTR_ERR(connector_state);
-
if (connector_state->best_encoder != encoder)
continue;
@@ -260,10 +253,8 @@ steal_encoder(struct drm_atomic_state *state,
crtc_state = drm_atomic_get_existing_crtc_state(state,
encoder_crtc);
crtc_state->connectors_changed = true;
- return 0;
+ return;
}
-
- return 0;
}
static int
@@ -343,13 +334,7 @@ update_connector_routing(struct drm_atomic_state *state,
return 0;
}
- ret = steal_encoder(state, new_encoder);
- if (ret) {
- DRM_DEBUG_ATOMIC("Encoder stealing failed for
[CONNECTOR:%d:%s]\n",
-connector->base.id,
-connector->name);
- return ret;
- }
+ steal_encoder(state, new_encoder);
if (WARN_ON(!connector_state->crtc))
return -EINVAL;
--
2.1.0
[PATCH v3 5/7] drm/atomic: Handle encoder assignment conflicts in a separate check, v3.
The current check doesn't handle the case where we don't steal an
encoder, but keep it on the current connector. If we repurpose
disable_conflicting_encoders to do the checking, we just have
to reject the ones that conflict.
Changes since v1:
- Return early with empty encoder_mask, drm_for_each_connector
requires connection_mutex held.
Changes since v2:
- Add comments for the loops.
Signed-off-by: Maarten Lankhorst
Testcase: kms_setmode.invalid-clone-single-crtc-stealing
---
drivers/gpu/drm/drm_atomic_helper.c | 77 +
1 file changed, 43 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index db11c2f9b098..bb60148c5c8d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -86,7 +86,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
*state,
}
}
-static int disable_conflicting_connectors(struct drm_atomic_state *state)
+static int handle_conflicting_encoders(struct drm_atomic_state *state,
+ bool disable_conflicting_encoders)
{
struct drm_connector_state *conn_state;
struct drm_connector *connector;
@@ -94,6 +95,11 @@ static int disable_conflicting_connectors(struct
drm_atomic_state *state)
unsigned encoder_mask = 0;
int i, ret;
+ /*
+* First loop, find all newly assigned encoders from the connectors
+* part of the state. If the same encoder is assigned to multiple
+* connectors bail out.
+*/
for_each_connector_in_state(state, connector, conn_state, i) {
const struct drm_connector_helper_funcs *funcs =
connector->helper_private;
struct drm_encoder *new_encoder;
@@ -106,10 +112,33 @@ static int disable_conflicting_connectors(struct
drm_atomic_state *state)
else
new_encoder = funcs->best_encoder(connector);
- if (new_encoder)
+ if (new_encoder) {
+ if (encoder_mask & (1 <<
drm_encoder_index(new_encoder))) {
+ DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] on
[CONNECTOR:%d:%s] already assigned\n",
+ new_encoder->base.id, new_encoder->name,
+ connector->base.id, connector->name);
+
+ return -EINVAL;
+ }
+
encoder_mask |= 1 << drm_encoder_index(new_encoder);
+ }
}
+ if (!encoder_mask)
+ return 0;
+
+ /*
+* Second loop, iterate over all connectors not part of the state.
+*
+* If a conflicting encoder is found and disable_conflicting_encoders
+* is not set, an error is returned. Userspace can provide a solution
+* through the atomic ioctl.
+*
+* If the flag is set conflicting connectors are removed from the crtc
+* and the crtc is disabled if no encoder is left. This preserves
+* compatibility with the legacy set_config behavior.
+*/
drm_for_each_connector(connector, state->dev) {
struct drm_crtc_state *crtc_state;
@@ -120,6 +149,15 @@ static int disable_conflicting_connectors(struct
drm_atomic_state *state)
if (!encoder || !(encoder_mask & (1 <<
drm_encoder_index(encoder
continue;
+ if (!disable_conflicting_encoders) {
+ DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on
[CRTC:%d:%s] by [CONNECTOR:%d:%s]\n",
+encoder->base.id, encoder->name,
+connector->state->crtc->base.id,
+connector->state->crtc->name,
+connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
conn_state = drm_atomic_get_connector_state(state, connector);
if (IS_ERR(conn_state))
return PTR_ERR(conn_state);
@@ -148,26 +186,6 @@ static int disable_conflicting_connectors(struct
drm_atomic_state *state)
return 0;
}
-static bool
-check_pending_encoder_assignment(struct drm_atomic_state *state,
-struct drm_encoder *new_encoder)
-{
- struct drm_connector *connector;
- struct drm_connector_state *conn_state;
- int i;
-
- for_each_connector_in_state(state, connector, conn_state, i) {
- if (conn_state->best_encoder != new_encoder)
- continue;
-
- /* encoder already assigned and we're trying to re-steal it! */
- if (connector->state->best_encoder != conn_state->best_encoder)
- return false;
- }
-
- return true;
-}
-
static void
set_best_en
[PATCH v3 4/7] drm/atomic: Handle encoder stealing from set_config better.
Instead of failing with -EINVAL when conflicting encoders are found,
the legacy set_config will disable other connectors when encoders
conflict.
With the previous commit this becomes a lot easier to implement.
set_config only adds connectors to the state that are modified,
and because of the previous commit that calls add_affected_connectors
only on set->crtc it means any connector not part of the modeset can
be stolen from. We disable the connector in that case, and possibly
the crtc if required.
Atomic modeset itself still doesn't allow encoder stealing, the results
would be too unpredictable.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 69 +
include/drm/drm_crtc.h | 2 ++
2 files changed, 71 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 72ca85b32260..db11c2f9b098 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -86,6 +86,68 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
*state,
}
}
+static int disable_conflicting_connectors(struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ struct drm_encoder *encoder;
+ unsigned encoder_mask = 0;
+ int i, ret;
+
+ for_each_connector_in_state(state, connector, conn_state, i) {
+ const struct drm_connector_helper_funcs *funcs =
connector->helper_private;
+ struct drm_encoder *new_encoder;
+
+ if (!conn_state->crtc)
+ continue;
+
+ if (funcs->atomic_best_encoder)
+ new_encoder = funcs->atomic_best_encoder(connector,
conn_state);
+ else
+ new_encoder = funcs->best_encoder(connector);
+
+ if (new_encoder)
+ encoder_mask |= 1 << drm_encoder_index(new_encoder);
+ }
+
+ drm_for_each_connector(connector, state->dev) {
+ struct drm_crtc_state *crtc_state;
+
+ if (drm_atomic_get_existing_connector_state(state, connector))
+ continue;
+
+ encoder = connector->state->best_encoder;
+ if (!encoder || !(encoder_mask & (1 <<
drm_encoder_index(encoder
+ continue;
+
+ conn_state = drm_atomic_get_connector_state(state, connector);
+ if (IS_ERR(conn_state))
+ return PTR_ERR(conn_state);
+
+ DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s],
disabling [CONNECTOR:%d:%s]\n",
+encoder->base.id, encoder->name,
+conn_state->crtc->base.id,
conn_state->crtc->name,
+connector->base.id, connector->name);
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state,
conn_state->crtc);
+
+ ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+ if (ret)
+ return ret;
+
+ if (!crtc_state->connector_mask) {
+ ret = drm_atomic_set_mode_prop_for_crtc(crtc_state,
+ NULL);
+ if (ret < 0)
+ return ret;
+
+ crtc_state->active = false;
+ }
+ }
+
+ return 0;
+}
+
static bool
check_pending_encoder_assignment(struct drm_atomic_state *state,
struct drm_encoder *new_encoder)
@@ -448,6 +510,12 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
}
}
+ if (state->legacy_set_config) {
+ ret = disable_conflicting_connectors(state);
+ if (ret)
+ return ret;
+ }
+
for_each_connector_in_state(state, connector, connector_state, i) {
/*
* This only sets crtc->mode_changed for routing changes,
@@ -1796,6 +1864,7 @@ int drm_atomic_helper_set_config(struct drm_mode_set *set)
if (!state)
return -ENOMEM;
+ state->legacy_set_config = true;
state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
retry:
ret = __drm_atomic_helper_set_config(set, state);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7fad193dc645..9a946df27f07 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1677,6 +1677,7 @@ struct drm_bridge {
* @dev: parent DRM device
* @allow_modeset: allow full modeset
* @legacy_cursor_update: hint to enforce legacy cursor IOCTL semantics
+ * @legacy_set_config: Disable conflicting encoders instead of failing with
-EINVAL.
* @planes: pointer to array of plane pointers
* @plane_states: pointer to array of plane states pointers
* @crtcs: poin
[PATCH v3 3/7] drm/atomic: Always call steal_encoder, v2.
There's no need to have a separate function to get the crtc
which is stolen, this can already be found when actually
stealing the encoder.
drm_for_each_connector already checks for connection_mutex, so
use that macro now.
Changes since v1:
- Do not check for NULL crtc in connector_state,
this may happen when a crtc is disabled and its encoder stolen.
- Because of this, use connector->state->crtc instead of conn_state->crtc.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 74 ++---
1 file changed, 20 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 3d1f97a832fc..72ca85b32260 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -106,25 +106,6 @@ check_pending_encoder_assignment(struct drm_atomic_state
*state,
return true;
}
-static struct drm_crtc *
-get_current_crtc_for_encoder(struct drm_device *dev,
-struct drm_encoder *encoder)
-{
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_connector *connector;
-
- WARN_ON(!drm_modeset_is_locked(&config->connection_mutex));
-
- drm_for_each_connector(connector, dev) {
- if (connector->state->best_encoder != encoder)
- continue;
-
- return connector->state->crtc;
- }
-
- return NULL;
-}
-
static void
set_best_encoder(struct drm_atomic_state *state,
struct drm_connector_state *conn_state,
@@ -168,38 +149,18 @@ set_best_encoder(struct drm_atomic_state *state,
static int
steal_encoder(struct drm_atomic_state *state,
- struct drm_encoder *encoder,
- struct drm_crtc *encoder_crtc)
+ struct drm_encoder *encoder)
{
- struct drm_mode_config *config = &state->dev->mode_config;
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
struct drm_connector_state *connector_state;
- /*
-* We can only steal an encoder coming from a connector, which means we
-* must already hold the connection_mutex.
-*/
- WARN_ON(!drm_modeset_is_locked(&config->connection_mutex));
-
- DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], stealing
it\n",
-encoder->base.id, encoder->name,
-encoder_crtc->base.id, encoder_crtc->name);
+ drm_for_each_connector(connector, state->dev) {
+ struct drm_crtc *encoder_crtc;
- crtc_state = drm_atomic_get_crtc_state(state, encoder_crtc);
- if (IS_ERR(crtc_state))
- return PTR_ERR(crtc_state);
-
- crtc_state->connectors_changed = true;
-
- list_for_each_entry(connector, &config->connector_list, head) {
if (connector->state->best_encoder != encoder)
continue;
- DRM_DEBUG_ATOMIC("Stealing encoder from [CONNECTOR:%d:%s]\n",
-connector->base.id,
-connector->name);
-
connector_state = drm_atomic_get_connector_state(state,
connector);
if (IS_ERR(connector_state))
@@ -208,7 +169,18 @@ steal_encoder(struct drm_atomic_state *state,
if (connector_state->best_encoder != encoder)
continue;
+ encoder_crtc = connector->state->crtc;
+
+ DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s],
stealing it\n",
+encoder->base.id, encoder->name,
+encoder_crtc->base.id, encoder_crtc->name);
+
set_best_encoder(state, connector_state, NULL);
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state,
encoder_crtc);
+ crtc_state->connectors_changed = true;
+
+ return 0;
}
return 0;
@@ -221,7 +193,6 @@ update_connector_routing(struct drm_atomic_state *state,
{
const struct drm_connector_helper_funcs *funcs;
struct drm_encoder *new_encoder;
- struct drm_crtc *encoder_crtc;
struct drm_crtc_state *crtc_state;
int idx, ret;
@@ -299,17 +270,12 @@ update_connector_routing(struct drm_atomic_state *state,
return -EINVAL;
}
- encoder_crtc = get_current_crtc_for_encoder(state->dev,
- new_encoder);
-
- if (encoder_crtc) {
- ret = steal_encoder(state, new_encoder, encoder_crtc);
- if (ret) {
- DRM_DEBUG_ATOMIC("Encoder stealing failed for
[CONNECTOR:%d:%s]\n",
-connector->base.id,
-connector->name);
- return ret;
- }
+
[PATCH v3 2/7] drm/atomic: Pass connector and state to update_connector_routing.
Minor cleanup, connector and connector_state are always non-NULL here.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a0226d4b949a..3d1f97a832fc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -215,22 +215,16 @@ steal_encoder(struct drm_atomic_state *state,
}
static int
-update_connector_routing(struct drm_atomic_state *state, int conn_idx)
+update_connector_routing(struct drm_atomic_state *state,
+struct drm_connector *connector,
+struct drm_connector_state *connector_state)
{
const struct drm_connector_helper_funcs *funcs;
struct drm_encoder *new_encoder;
struct drm_crtc *encoder_crtc;
- struct drm_connector *connector;
- struct drm_connector_state *connector_state;
struct drm_crtc_state *crtc_state;
int idx, ret;
- connector = state->connectors[conn_idx];
- connector_state = state->connector_states[conn_idx];
-
- if (!connector)
- return 0;
-
DRM_DEBUG_ATOMIC("Updating routing for [CONNECTOR:%d:%s]\n",
connector->base.id,
connector->name);
@@ -494,7 +488,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
* drivers must set crtc->mode_changed themselves when connector
* properties need to be updated.
*/
- ret = update_connector_routing(state, i);
+ ret = update_connector_routing(state, connector,
+ connector_state);
if (ret)
return ret;
}
--
2.1.0
[PATCH v3 1/7] drm/atomic: Clean up update_output_state.
With the addition of crtc_state->connector_mask other connectors from
different crtc's aren't needed any more, so only call
add_affected_connectors on the target crtc. This allows a cleanup
to first remove all current connectors, then add all set->connectors
to the target crtc.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 41 +++--
1 file changed, 17 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 4da4f2a49078..a0226d4b949a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1761,28 +1761,18 @@ static int update_output_state(struct drm_atomic_state
*state,
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
struct drm_connector_state *conn_state;
- int ret, i, j;
+ int ret, i;
ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
state->acquire_ctx);
if (ret)
return ret;
- /* First grab all affected connector/crtc states. */
- for (i = 0; i < set->num_connectors; i++) {
- conn_state = drm_atomic_get_connector_state(state,
- set->connectors[i]);
- if (IS_ERR(conn_state))
- return PTR_ERR(conn_state);
- }
-
- for_each_crtc_in_state(state, crtc, crtc_state, i) {
- ret = drm_atomic_add_affected_connectors(state, crtc);
- if (ret)
- return ret;
- }
+ /* First disable all connectors on the target crtc. */
+ ret = drm_atomic_add_affected_connectors(state, set->crtc);
+ if (ret)
+ return ret;
- /* Then recompute connector->crtc links and crtc enabling state. */
for_each_connector_in_state(state, connector, conn_state, i) {
if (conn_state->crtc == set->crtc) {
ret = drm_atomic_set_crtc_for_connector(conn_state,
@@ -1790,16 +1780,19 @@ static int update_output_state(struct drm_atomic_state
*state,
if (ret)
return ret;
}
+ }
- for (j = 0; j < set->num_connectors; j++) {
- if (set->connectors[j] == connector) {
- ret =
drm_atomic_set_crtc_for_connector(conn_state,
-
set->crtc);
- if (ret)
- return ret;
- break;
- }
- }
+ /* Then set all connectors from set->connectors on the target crtc */
+ for (i = 0; i < set->num_connectors; i++) {
+ conn_state = drm_atomic_get_connector_state(state,
+ set->connectors[i]);
+ if (IS_ERR(conn_state))
+ return PTR_ERR(conn_state);
+
+ ret = drm_atomic_set_crtc_for_connector(conn_state,
+ set->crtc);
+ if (ret)
+ return ret;
}
for_each_crtc_in_state(state, crtc, crtc_state, i) {
--
2.1.0
[PATCH v3 0/7] drm/atomic: Fix encoder stealing, v3.
This is a resend of "drm/atomic: Fix encoder stealing" with updated patches. Maarten Lankhorst (7): drm/atomic: Clean up update_output_state. drm/atomic: Pass connector and state to update_connector_routing. drm/atomic: Always call steal_encoder, v2. drm/atomic: Handle encoder stealing from set_config better. drm/atomic: Handle encoder assignment conflicts in a separate check, v3. drm/atomic: Clean up steal_encoder, v2. drm/atomic: Clean up update_connector_routing. drivers/gpu/drm/drm_atomic_helper.c | 252 +++- include/drm/drm_crtc.h | 2 + 2 files changed, 132 insertions(+), 122 deletions(-) -- 2.1.0
[PATCH v1 00/12] PCI: Rework shadow ROM handling
On Thu, Mar 3, 2016 at 8:53 AM, Bjorn Helgaas wrote: > The purpose of this series is to: > [ .. ] The patches look ok to me and seem to make sense. Of course, let's see what they break. Hopefully nothing, but any time the PCI resource code changes I get a bit worried. PTSD, I guess. Linus
[PATCH v6 01/11] drm/hisilicon: Add device tree binding for hi6220 display subsystem
Hi, On 3 March 2016 at 02:29, Rob Herring wrote: > On Fri, Feb 26, 2016 at 04:40:18PM +0800, Xinliang Liu wrote: >> Add ADE display controller binding doc. >> Add DesignWare DSI Host Controller v1.20a binding doc. >> >> v6: >> - Cleanup values part of reg and clocks properties. >> - Change "pclk_dsi" clock name to "pclk". >> v5: >> - Remove endpoint unit address of dsi output port. >> - Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon. >> - Add "resets" property for ADE reset. >> v4: >> - Describe more specific of clocks and ports. >> - Fix indentation. >> v3: >> - Make ade as the drm master node. >> - Use assigned-clocks to set clock rate. >> - Use ports to connect display relavant nodes. >> v2: >> - Move dt binding docs to bindings/display/hisilicon directory. >> >> Signed-off-by: Xinliang Liu >> --- >> .../bindings/display/hisilicon/dw-dsi.txt | 72 >> ++ >> .../bindings/display/hisilicon/hisi-ade.txt| 64 +++ >> 2 files changed, 136 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt >> create mode 100644 >> Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt > > Acked-by: Rob Herring Thanks :-) -xinliang
[PATCH] staging/android: add flags member to sync ioctl structs
On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Play safe and add flags member to all structs. So we don't need to > break API or create new IOCTL in the future if new features that requires > flags arises. > > v2: check if flags are valid (zero, in this case) > > v3: return -EINVAL if flags are not zero'ed > > v4: add padding for 64-bit alignment > > v5: rebase to use only stacked sync_file_info Why are these vX things here in the changelog? And you just broke all existing userspace users of this code, why are you allowed to do that? not ok...
[pull] radeon and amdgpu drm-next-4.6
Hi Dave, Some more radeon and amdgpu stuff for drm-next. Mostly just bug fixes for new features and cleanups. The following changes since commit d2eaa59000c7717e68a75cf2c106f056d2bc30b4: Merge branch 'drm-rockchip-next-2016-02-18' of https://github.com/markyzq/kernel-drm-rockchip into drm-next (2016-02-19 13:10:18 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.6 for you to fetch changes up to 6157bd7a1009c2a6944fb3eee8ed2b3dea091fd8: drm/amdgpu: fix rb bitmap & cu bitmap calculation (2016-03-03 01:00:20 -0500) Alex Deucher (3): drm/amdgpu/gfx: fix off by one in rb rework (v2) drm/radeon: update radeon acpi header drm/amdgpu: update radeon acpi header Christian König (3): drm/amdgpu: fix error handling in amdgpu_bo_list_set drm/amdgpu: fix VM faults caused by vm_grab_id() v4 drm/amdgpu: trace the pd_addr in vm_grab_id as well Dan Carpenter (1): drm/amd: cleanup get_mfd_cell_dev() Flora Cui (1): drm/amdgpu: fix rb bitmap & cu bitmap calculation Geert Uytterhoeven (1): drm/amd: Do not make DRM_AMD_ACP default to y Rex Zhu (1): drm/amd/powerplay: fix code style warning. drivers/gpu/drm/amd/acp/Kconfig | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu.h | 16 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 7 +- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 15 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 19 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 116 ++ drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 2 +- drivers/gpu/drm/amd/amdgpu/cikd.h | 3 - drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 28 +++ drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 22 +++-- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c| 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c| 2 +- drivers/gpu/drm/amd/amdgpu/vid.h | 2 - drivers/gpu/drm/amd/include/amd_acpi.h| 2 + drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 4 +- drivers/gpu/drm/radeon/radeon_acpi.h | 2 + 18 files changed, 131 insertions(+), 121 deletions(-)
