summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-08-08drm/rockchip: Use drm_plane_helper_check_state()Ville Syrjälä
Replace the use of drm_plane_helper_check_update() with drm_plane_helper_check_state() since we have a plane state. Rockchip looks to handling plane clipping rather well already (unlikje most arm drm drivers) so there are no function changes here. Cc: Yao <mark.yao@rock-chips.com> Cc: linux-rockchip@lists.infradead.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Mark Yao <mark.yao@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-8-git-send-email-ville.syrjala@linux.intel.com
2016-08-08drm/rockchip: Use drm_plane_state.{src, dst}Ville Syrjälä
Replace the private drm_rects in vop_plane_state with the ones now living in drm_plane_state. Cc: Yao <mark.yao@rock-chips.com> Cc: linux-rockchip@lists.infradead.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Mark Yao <mark.yao@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-7-git-send-email-ville.syrjala@linux.intel.com
2016-08-08drm/i915: Use drm_plane_helper_check_state()Ville Syrjälä
Replace the use of drm_plane_helper_check_update() with drm_plane_helper_check_state() since we have a plane state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-6-git-send-email-ville.syrjala@linux.intel.com
2016-08-08drm/i915: Use drm_plane_state.{src,dst,visible}Ville Syrjälä
Replace the private drm_rects/flags in intel_plane_state with the ones now living in drm_plane_state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-5-git-send-email-ville.syrjala@linux.intel.com
2016-08-08drm/plane-helper: Add drm_plane_helper_check_state()Ville Syrjälä
Add a version of drm_plane_helper_check_update() which takes a plane state instead of having the caller pass in everything. And to reduce code duplication, let's reimplement drm_plane_helper_check_update() in terms of the new function, by having a tempororary plane state on the stack. v2: Add a note that the functions modifies the state (Chris) v3: Fix drm_plane_helper_check_update() y coordinates (Daniel Kurtz) Cc: Daniel Kurtz <djkurtz@chromium.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> (v2) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1470642910-14073-1-git-send-email-ville.syrjala@linux.intel.com
2016-08-08drm: Store clipped src/dst coordinatee in drm_plane_stateVille Syrjälä
Pretty much all driver will have need for the clipped plane coordinates, so let's stuff then into drm_plane_state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-3-git-send-email-ville.syrjala@linux.intel.com
2016-08-08drm: Warn about negative sizes when calculating scale factorVille Syrjälä
Passing negative width/hight to scale factor calculations is not legal. Let's WARN if that happens. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-2-git-send-email-ville.syrjala@linux.intel.com
2016-08-08drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?Joonas Lahtinen
Only property creation uses the rotation as an index, so convert the to figure the index when needed. v2: Use the new defines to build the _MASK defines (Sean) Cc: intel-gfx@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: malidp@foss.arm.com Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Sean Paul <seanpaul@chromium.org> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1469771405-17653-1-git-send-email-joonas.lahtinen@linux.intel.com
2016-08-08dell-wmi: Ignore WMI event 0xe00ePali Rohár
WMI event 0xe00e is received when battery was removed or inserted. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-08-08x86/hweight: Don't clobber %rdiVille Syrjälä
The caller expects %rdi to remain intact, push+pop it make that happen. Fixes the following kind of explosions on my core2duo machine when trying to reboot or shut down: general protection fault: 0000 [#1] PREEMPT SMP Modules linked in: i915 i2c_algo_bit drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea drm netconsole configfs binfmt_misc iTCO_wdt psmouse pcspkr snd_hda_codec_idt e100 coretemp hwmon snd_hda_codec_generic i2c_i801 mii i2c_smbus lpc_ich mfd_core snd_hda_intel uhci_hcd snd_hda_codec snd_hwdep snd_hda_core ehci_pci 8250 ehci_hcd snd_pcm 8250_base usbcore evdev serial_core usb_common parport_pc parport snd_timer snd soundcore CPU: 0 PID: 3070 Comm: reboot Not tainted 4.8.0-rc1-perf-dirty #69 Hardware name: /D946GZIS, BIOS TS94610J.86A.0087.2007.1107.1049 11/07/2007 task: ffff88012a0b4080 task.stack: ffff880123850000 RIP: 0010:[<ffffffff81003c92>] [<ffffffff81003c92>] x86_perf_event_update+0x52/0xc0 RSP: 0018:ffff880123853b60 EFLAGS: 00010087 RAX: 0000000000000001 RBX: ffff88012fc0a3c0 RCX: 000000000000001e RDX: 0000000000000000 RSI: 0000000040000000 RDI: ffff88012b014800 RBP: ffff880123853b88 R08: ffffffffffffffff R09: 0000000000000000 R10: ffffea0004a012c0 R11: ffffea0004acedc0 R12: ffffffff80000001 R13: ffff88012b0149c0 R14: ffff88012b014800 R15: 0000000000000018 FS: 00007f8b155cd700(0000) GS:ffff88012fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8b155f5000 CR3: 000000012a2d7000 CR4: 00000000000006f0 Stack: ffff88012fc0a3c0 ffff88012b014800 0000000000000004 0000000000000001 ffff88012fc1b750 ffff880123853bb0 ffffffff81003d59 ffff88012b014800 ffff88012fc0a3c0 ffff88012b014800 ffff880123853bd8 ffffffff81003e13 Call Trace: [<ffffffff81003d59>] x86_pmu_stop+0x59/0xd0 [<ffffffff81003e13>] x86_pmu_del+0x43/0x140 [<ffffffff8111705d>] event_sched_out.isra.105+0xbd/0x260 [<ffffffff8111738d>] __perf_remove_from_context+0x2d/0xb0 [<ffffffff8111745d>] __perf_event_exit_context+0x4d/0x70 [<ffffffff810c8826>] generic_exec_single+0xb6/0x140 [<ffffffff81117410>] ? __perf_remove_from_context+0xb0/0xb0 [<ffffffff81117410>] ? __perf_remove_from_context+0xb0/0xb0 [<ffffffff810c898f>] smp_call_function_single+0xdf/0x140 [<ffffffff81113d27>] perf_event_exit_cpu_context+0x87/0xc0 [<ffffffff81113d73>] perf_reboot+0x13/0x40 [<ffffffff8107578a>] notifier_call_chain+0x4a/0x70 [<ffffffff81075ad7>] __blocking_notifier_call_chain+0x47/0x60 [<ffffffff81075b06>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff81076a1d>] kernel_restart_prepare+0x1d/0x40 [<ffffffff81076ae2>] kernel_restart+0x12/0x60 [<ffffffff81076d56>] SYSC_reboot+0xf6/0x1b0 [<ffffffff811a823c>] ? mntput_no_expire+0x2c/0x1b0 [<ffffffff811a83e4>] ? mntput+0x24/0x40 [<ffffffff811894fc>] ? __fput+0x16c/0x1e0 [<ffffffff811895ae>] ? ____fput+0xe/0x10 [<ffffffff81072fc3>] ? task_work_run+0x83/0xa0 [<ffffffff81001623>] ? exit_to_usermode_loop+0x53/0xc0 [<ffffffff8100105a>] ? trace_hardirqs_on_thunk+0x1a/0x1c [<ffffffff81076e6e>] SyS_reboot+0xe/0x10 [<ffffffff814c4ba5>] entry_SYSCALL_64_fastpath+0x18/0xa3 Code: 7c 4c 8d af c0 01 00 00 49 89 fe eb 10 48 09 c2 4c 89 e0 49 0f b1 55 00 4c 39 e0 74 35 4d 8b a6 c0 01 00 00 41 8b 8e 60 01 00 00 <0f> 33 8b 35 6e 02 8c 00 48 c1 e2 20 85 f6 7e d2 48 89 d3 89 cf RIP [<ffffffff81003c92>] x86_perf_event_update+0x52/0xc0 RSP <ffff880123853b60> ---[ end trace 7ec95181faf211be ]--- note: reboot[3070] exited with preempt_count 2 Cc: Borislav Petkov <bp@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Fixes: f5967101e9de ("x86/hweight: Get rid of the special calling convention") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-08nvdimm, btt: add a size attribute for BTTsVishal Verma
To be consistent with other namespaces, expose a 'size' attribute for BTT devices also. Cc: Dan Williams <dan.j.williams@intel.com> Reported-by: Linda Knippers <linda.knippers@hpe.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2016-08-08libnvdimm, nd_blk: mask off reserved status bitsRoss Zwisler
The "NVDIMM Block Window Driver Writer's Guide": http://pmem.io/documents/NVDIMM_DriverWritersGuide-July-2016.pdf ...defines the layout of the block window status register. For the July 2016 version of the spec linked to above, this happens in Figure 4 on page 26. The only bits defined in this spec are bits 31, 5, 4, 2, 1 and 0. The rest of the bits in the status register are reserved, and there is a warning following the diagram that says: Note: The driver cannot assume the value of the RESERVED bits in the status register are zero. These reserved bits need to be masked off, and the driver must avoid checking the state of those bits. This change ensures that for hardware implementations that set these reserved bits in the status register, the driver won't incorrectly fail the block I/Os. Cc: <stable@vger.kernel.org> #v4.2+ Reviewed-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2016-08-08Merge branch 'nvmf-4.8-rc' of git://git.infradead.org/nvme-fabrics into ↵Jens Axboe
for-linus Sagi writes: Mostly stability fixes for nvmet, rdma: - fix uninitialized rdma_cm private data from Roland. - rdma device removal handling (host and target). - fix controller disconnect during active mounts. - fix namespaces lost after fabric reconnects. - remove redundant calls to namespace removal (rdma, loop). - actually send controller shutdown when disconnecting. - reconnect fixes (ns rescan and aen requeue) - nvmet controller serial number inconsistency fix.
2016-08-08drm/imx: imx-ldb: use encoder atomic_mode_set callbackPhilipp Zabel
Using atomic_mode_set instead of mode_set allows to access crtc and connector states in addition to the modes. This allows to remove the connector list walk. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08drm/atomic-helper: Add atomic_mode_set helper callbackPhilipp Zabel
Some encoders need more information from crtc and connector state or connector display info than just the mode during mode setting. This patch adds an atomic encoder mode setting variant that passes the crtc state (which contains the modes) and the connector state. atomic_enable/disable variants that additionally pass crtc and connector state don't seem to be necessary for any current driver. mode_fixup already has an atomic equivalent in atomic_check. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-08drm/imx: Remove imx_drm_handle_vblank()Liu Ying
imx_drm_handle_vblank() is just a simple wrapper of drm_crtc_handle_vblank() without doing any thing fancy - drm_crtc_handle_vblank() can be called directly. So, let's remove the wrapper. Signed-off-by: Liu Ying <gnuiyl@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08gpu: ipu-v3: Add missing IDMAC channel namesPhilipp Zabel
This patch adds the remaining missing IDMAC channel names: VDIC channels for combining, the separate alpha channels for the MEM->IC and MEM->DC ASYNC channels, and the DC read, command, and output mask channels. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08gpu: ipu-v3: rename CSI client deviceSteve Longerbeam
Rename the CSI client device in the client_reg[] table to "imx-ipuv3-csi". Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08gpu: ipu-v3: Fix IRT usageSteve Longerbeam
There can be multiple IC tasks using the IRT, so the IRT needs a separate use counter. Create a private ipu_irt_enable() to enable the IRT module when any IC task requires rotation, and ipu_irt_disable() when a task no longer needs the IRT. Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08gpu: ipu-v3: Fix CSI data format for 16-bit media bus formatsSteve Longerbeam
The CSI data format was being programmed incorrectly for the 1x16 media bus formats. The CSI data format for 16-bit must be bayer/generic (CSI_SENS_CONF_DATA_FMT_BAYER). Suggested-by: Carsten Resch <Carsten.Resch@de.bosch.com> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08gpu: ipu-v3: set correct full sensor frame for PAL/NTSCSteve Longerbeam
Set the sensor full frame based on whether the passed in mbus_fmt is 720x480 (NTSC) or 720x576 (PAL). Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08gpu: ipu-v3: Add VDI input IDMAC channelsSteve Longerbeam
Adds the VDIC field input IDMAC channels. These channels transfer fields F(n-1), F(n), and F(N+1) from memory to the VDIC (channels 8, 9, 10 respectively). Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08gpu: ipu-v3: Add ipu_get_num()Steve Longerbeam
Adds of-alias id to ipu_soc and retrieve with ipu_get_num(). Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize()Steve Longerbeam
Adds ipu_cpmem_get_burstsize(). Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset()Steve Longerbeam
Adds ipu_cpmem_set_uv_offset(), to set planar U/V offsets. Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08drm/imx: Remove imx_drm_crtc_id()Liu Ying
There is no one calling imx_drm_crtc_id() and it is just a simple wrapper of drm_crtc_index() without doing any thing fancy - the drivers may call drm_crtc_index() directly. So, let's remove the wrapper. Signed-off-by: Liu Ying <gnuiyl@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08drm/imx: Remove imx_drm_crtc_vblank_get/_put()Liu Ying
There is no one calling imx_drm_crtc_vblank_get/_put() and they are just two simple wrappers of drm_crtc_vblank_get/_put() without doing any thing fancy - the drivers may call drm_crtc_vblank_get/_put() directly. So, let's remove the two wrappers. Signed-off-by: Liu Ying <gnuiyl@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08drm/imx: convey the pixelclk-active and de-active flags from DT to the ↵Lothar Waßmann
ipu-di driver The 'de-active' and 'pixelclk-active' DT properties are evaluated by of_parse_display_timing() called from of_get_drm_display_mode(), but later lost in the conversion from videomode.flags to drm_display_mode.flags. Enhance of_get_drm_display_mode() to also return the bus flags in a separate variable, so that they can be passed on to the ipu-di driver. Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08drm: add a helper function to extract 'de-active' and 'pixelclk-active' from DTLothar Waßmann
add a helper function to extract information about pixel clock and DE polarity from DT for use by of_get_drm_display_mode(). While at it, convert spaces to tabs in indentation in drm_modes.h. Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08drm: Don't prepare or cleanup unchanging frame buffers [v3]Keith Packard
When reconfiguring a plane position (as in moving the cursor), the frame buffer for the cursor isn't changing, so don't call the prepare or cleanup driver functions. This avoids making cursor position updates block on all pending rendering. v3: use drm_atomic_helper_framebuffer_changed in both prepare and cleanup phases instead of keeping state in the plane. cc: dri-devel@lists.freedesktop.org cc: David Airlie <airlied@linux.ie> cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com> [danvet: Rebase onto 4.8] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-08drm: Used DRM_LEGACY for all legacy functionsDaniel Vetter
Except for nouveau, only legacy drivers need this really. And nouveau is already marked up with DRIVER_KMS_LEGACY_CONTEXT as the special case. I've tried to be careful to leave everything related to modeset still using the DRIVER_MODESET flag. Otherwise it's a direct replacement of !DRIVER_MODESET with DRIVER_LEGACY checks. Also helps readability since fewer negative checks overall. Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-2-git-send-email-daniel.vetter@ffwll.ch
2016-08-08drm: Mark up legacy/dri1 drivers with DRM_LEGACYDaniel Vetter
It's super confusing that new drivers need to be marked with DRIVER_MODESET when really it means DRIVER_MODERN. Much better to invert the meaning and rename it to something that's suitably off-putting. Since there's over 100 places using DRIVER_MODESET we need to roll out this change without a flag day. v2: Update docs. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-1-git-send-email-daniel.vetter@ffwll.ch
2016-08-08drm: Declare that create drm_mm nodes with size 0 is illegalChris Wilson
At a higher level, all objects are created with definite size i.e. 0 is illegal. In forthcoming patches, this assumption is dependent upon in the drm_mm range manager, i.e. trying to create a drm_mm node with size 0 will have undefined behaviour. Add a couple of WARNs upon creating the drm_mm node to prevent later bugs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470248788-30873-1-git-send-email-chris@chris-wilson.co.uk
2016-08-08drm: rename DRM_MINOR_LEGACY to DRM_MINOR_PRIMARYDavid Herrmann
The minor referred to by "DRM_MINOR_LEGACY" is called 'dev->primary' and gets 'cardX' as name assigned. Lets reduce this magnificent number of names for the same concept by one and rename DRM_MINOR_LEGACY to DRM_MINOR_PRIMARY (to match the actual struct-member name). Furthermore, this is in no way a legacy node, so lets not call it that. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160803180432.1341-2-dh.herrmann@gmail.com
2016-08-08drm: Skip initialising the drm_mm_node->hole_stackChris Wilson
As we always add this to the drm_mm->hole_stack as our first operation, we do not need to initialise the list node. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470236651-678-3-git-send-email-chris@chris-wilson.co.uk
2016-08-08drm: Convert drm_vma_manager to embedded interval-tree in drm_mmChris Wilson
Having added an interval-tree to struct drm_mm, we can replace the auxiliary rb-tree inside the drm_vma_manager with it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470236651-678-2-git-send-email-chris@chris-wilson.co.uk
2016-08-08drm: Track drm_mm nodes with an interval treeChris Wilson
In addition to the last-in/first-out stack for accessing drm_mm nodes, we occasionally and in the future often want to find a drm_mm_node by an address. To do so efficiently we need to track the nodes in an interval tree - lookups for a particular address will then be O(lg(N)), where N is the number of nodes in the range manager as opposed to O(N). Insertion however gains an extra O(lg(N)) step for all nodes irrespective of whether the interval tree is in use. For future i915 patches, eliminating the linear walk is a significant improvement. v2: Use generic interval-tree template for u64 and faster insertion. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470236651-678-1-git-send-email-chris@chris-wilson.co.uk
2016-08-08drm: Avoid printing negative values for unsigned variables.Rodrigo Vivi
It was really strange to see negative vblank seqs on debug messages. It is rare to have that big number, but when it happens it is confusing and misleading. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470243226-2750-1-git-send-email-rodrigo.vivi@intel.com
2016-08-08drm/i915: Update DRIVER_DATE to 20160808Daniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-08Merge branch 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-next A few fixes for amdgpu and ttm for 4.8 - fix a ttm regression caused by the new pipelining code - fixes for mullins on amdgpu - updated golden settings for amdgpu * 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux: drm/ttm: Wait for a BO to become idle before unbinding it from GTT drm/amdgpu: update golden setting of polaris10 drm/amdgpu: update golden setting of stoney drm/amdgpu: update golden setting of polaris11 drm/amdgpu: update golden setting of carrizo drm/amdgpu: update golden setting of iceland drm/amd/amdgpu: change pptable output format from ASCII to binary drm/amdgpu/ci: add mullins to default case for smc ucode drm/amdgpu/gmc7: add missing mullins case
2016-08-08powerpc/pasemi: Fix coherent_dma_mask for dma engineDarren Stevens
Commit 817820b0226a ("powerpc/iommu: Support "hybrid" iommu/direct DMA ops for coherent_mask < dma_mask) adds a check of coherent_dma_mask for dma allocations. Unfortunately current PASemi code does not set this value for the DMA engine, which ends up with the default value of 0xffffffff, the result is on a PASemi system with >2Gb ram and iommu enabled the the onboard ethernet stops working due to an inability to allocate memory. Add an initialisation to pci_dma_dev_setup_pasemi(). Signed-off-by: Darren Stevens <darren@stevens-zone.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-08-08Merge tag 'drm-intel-next-fixes-2016-08-05' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next 3 intel fixes. * tag 'drm-intel-next-fixes-2016-08-05' of git://anongit.freedesktop.org/drm-intel: drm/i915/fbdev: Check for the framebuffer before use drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
2016-08-08drm: Paper over locking inversion after registration reworkDaniel Vetter
drm_connector_register_all requires a few too many locks because our connector_list locking is busted. Add another FIXME+hack to work around this. This should address the below lockdep splat: ====================================================== [ INFO: possible circular locking dependency detected ] 4.7.0-rc5+ #524 Tainted: G O ------------------------------------------------------- kworker/u8:0/6 is trying to acquire lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120 but task is already holding lock: ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 ((fb_notifier_list).rwsem){++++.+}: [<ffffffff810df611>] lock_acquire+0xb1/0x200 [<ffffffff819a55b4>] down_write+0x44/0x80 [<ffffffff810abf91>] blocking_notifier_chain_register+0x21/0xb0 [<ffffffff814c7448>] fb_register_client+0x18/0x20 [<ffffffff814c6c86>] backlight_device_register+0x136/0x260 [<ffffffffa0127eb2>] intel_backlight_device_register+0xa2/0x160 [i915] [<ffffffffa00f46be>] intel_connector_register+0xe/0x10 [i915] [<ffffffffa0112bfb>] intel_dp_connector_register+0x1b/0x80 [i915] [<ffffffff8159dfea>] drm_connector_register+0x4a/0x80 [<ffffffff8159fe44>] drm_connector_register_all+0x64/0xf0 [<ffffffff815a2a64>] drm_modeset_register_all+0x174/0x1c0 [<ffffffff81599b72>] drm_dev_register+0xc2/0xd0 [<ffffffffa00621d7>] i915_driver_load+0x1547/0x2200 [i915] [<ffffffffa006d80f>] i915_pci_probe+0x4f/0x70 [i915] [<ffffffff814a2135>] local_pci_probe+0x45/0xa0 [<ffffffff814a349b>] pci_device_probe+0xdb/0x130 [<ffffffff815c07e3>] driver_probe_device+0x223/0x440 [<ffffffff815c0ad5>] __driver_attach+0xd5/0x100 [<ffffffff815be386>] bus_for_each_dev+0x66/0xa0 [<ffffffff815c002e>] driver_attach+0x1e/0x20 [<ffffffff815bf9be>] bus_add_driver+0x1ee/0x280 [<ffffffff815c1810>] driver_register+0x60/0xe0 [<ffffffff814a1a10>] __pci_register_driver+0x60/0x70 [<ffffffffa01a905b>] i915_init+0x5b/0x62 [i915] [<ffffffff8100042d>] do_one_initcall+0x3d/0x150 [<ffffffff811a935b>] do_init_module+0x5f/0x1d9 [<ffffffff81124416>] load_module+0x20e6/0x27e0 [<ffffffff81124d63>] SYSC_finit_module+0xc3/0xf0 [<ffffffff81124dae>] SyS_finit_module+0xe/0x10 [<ffffffff819a83a9>] entry_SYSCALL_64_fastpath+0x1c/0xac -> #0 (&dev->mode_config.mutex){+.+.+.}: [<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260 [<ffffffff810df611>] lock_acquire+0xb1/0x200 [<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0 [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120 [<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50 [<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915] [<ffffffff814c13c6>] fbcon_init+0x586/0x610 [<ffffffff8154d16a>] visual_init+0xca/0x130 [<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0 [<ffffffff8154eaf6>] do_take_over_console+0x116/0x180 [<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0 [<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750 [<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0 [<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70 [<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20 [<ffffffff814c86b1>] register_framebuffer+0x251/0x330 [<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0 [<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915] [<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150 [<ffffffff810a3947>] process_one_work+0x1e7/0x750 [<ffffffff810a3efb>] worker_thread+0x4b/0x4f0 [<ffffffff810aad4f>] kthread+0xef/0x110 [<ffffffff819a85ef>] ret_from_fork+0x1f/0x40 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((fb_notifier_list).rwsem); lock(&dev->mode_config.mutex); lock((fb_notifier_list).rwsem); lock(&dev->mode_config.mutex); *** DEADLOCK *** 6 locks held by kworker/u8:0/6: #0: ("events_unbound"){.+.+.+}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750 #1: ((&entry->work)){+.+.+.}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750 #2: (registration_lock){+.+.+.}, at: [<ffffffff814c8487>] register_framebuffer+0x27/0x330 #3: (console_lock){+.+.+.}, at: [<ffffffff814c86ce>] register_framebuffer+0x26e/0x330 #4: (&fb_info->lock){+.+.+.}, at: [<ffffffff814c78dd>] lock_fb_info+0x1d/0x40 #5: ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70 stack backtrace: CPU: 2 PID: 6 Comm: kworker/u8:0 Tainted: G O 4.7.0-rc5+ #524 Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLKRVPA.X64.0138.B33.1606250842 06/25/2016 Workqueue: events_unbound async_run_entry_fn 0000000000000000 ffff8800758577f0 ffffffff814507a5 ffffffff828b9900 ffffffff828b9900 ffff880075857830 ffffffff810dc6fa ffff880075857880 ffff88007584d688 0000000000000005 0000000000000006 ffff88007584d6b0 Call Trace: [<ffffffff814507a5>] dump_stack+0x67/0x92 [<ffffffff810dc6fa>] print_circular_bug+0x1aa/0x200 [<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260 [<ffffffff810df611>] lock_acquire+0xb1/0x200 [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120 [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120 [<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0 [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120 [<ffffffff810fa85f>] ? rcu_read_lock_sched_held+0x7f/0x90 [<ffffffff81208218>] ? kmem_cache_alloc_trace+0x248/0x2b0 [<ffffffff815afdc5>] ? drm_modeset_lock_all+0x25/0x120 [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120 [<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50 [<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915] [<ffffffff814c13c6>] fbcon_init+0x586/0x610 [<ffffffff8154d16a>] visual_init+0xca/0x130 [<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0 [<ffffffff8154eaf6>] do_take_over_console+0x116/0x180 [<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0 [<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750 [<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0 [<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70 [<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20 [<ffffffff814c86b1>] register_framebuffer+0x251/0x330 [<ffffffff815b7e8d>] ? vga_switcheroo_client_fb_set+0x5d/0x70 [<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0 [<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915] [<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150 [<ffffffff810a3947>] process_one_work+0x1e7/0x750 [<ffffffff810a38c9>] ? process_one_work+0x169/0x750 [<ffffffff810a3efb>] worker_thread+0x4b/0x4f0 [<ffffffff810a3eb0>] ? process_one_work+0x750/0x750 [<ffffffff810aad4f>] kthread+0xef/0x110 [<ffffffff819a85ef>] ret_from_fork+0x1f/0x40 [<ffffffff810aac60>] ? kthread_stop+0x2e0/0x2e0 v2: Rebase onto the right branch (hand-editing patches ftw) and add more reporters. Reported-by: Imre Deak <imre.deak@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Jiri Kosina <jikos@kernel.org> Cc: Jiri Kosina <jikos@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-08-08drm: rcar-du: Link HDMI encoder with bridgeLaurent Pinchart
The conversion of the rcar-du driver from the I2C slave encoder to the DRM bridge API left the HDMI encoder's bridge pointer NULL, preventing the bridge from being handled automatically by the DRM core. Fix it. Fixes: 1d926114d8f4 ("drm: rcar-du: Remove i2c slave encoder interface for hdmi encoder") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-08-08Merge branches 'thermal-intel' and 'thermal-core' into nextZhang Rui
2016-08-08thermal: clock_cooling: Fix missing mutex_init()Wei Yongjun
The driver allocates the mutex but not initialize it. Use mutex_init() on it to initialize it correctly. This is detected by Coccinelle semantic patch. Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-08-08thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfsKuninori Morimoto
thermal_add_hwmon_sysfs()/thermal_remove_hwmon_sysfs() need EXPORT_SYMBOL_GPL(). Otherwise we will have ERROR >> ERROR: "thermal_remove_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] undefined! >> ERROR: "thermal_add_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] undefined! Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-08-08thermal: fix race condition when updating cooling deviceMichele Di Giorgio
When multiple thermal zones are bound to the same cooling device, multiple kernel threads may want to update the cooling device state by calling thermal_cdev_update(). Having cdev not protected by a mutex can lead to a race condition. Consider the following situation with two kernel threads k1 and k2: Thread k1 Thread k2 || || call thermal_cdev_update() || ... || set_cur_state(cdev, target); call power_actor_set_power() || ... || instance->target = state; || cdev->updated = false; || || cdev->updated = true; || // completes execution call thermal_cdev_update() || // cdev->updated == true || return; || \/ time k2 has already looped through the thermal instances looking for the deepest cooling device state and is preempted right before setting cdev->updated to true. Now, k1 runs, modifies the thermal instance state and sets cdev->updated to false. Then, k1 is preempted and k2 continues the execution by setting cdev->updated to true, therefore preventing k1 from performing the update. Notice that this is not an issue if k2 looks at the instance->target modified by k1 "after" it is assigned by k1. In fact, in this case the update will happen anyway and k1 can safely return immediately from thermal_cdev_update(). This may lead to a situation where a thermal governor never updates the cooling device. For example, this is the case for the step_wise governor: when calling the function thermal_zone_trip_update(), the governor may always get a new state equal to the old one (which, however, wasn't notified to the cooling device) and will therefore skip the update. CC: Zhang Rui <rui.zhang@intel.com> CC: Eduardo Valentin <edubezval@gmail.com> CC: Peter Feuerer <peter@piie.net> Reported-by: Toby Huang <toby.huang@arm.com> Signed-off-by: Michele Di Giorgio <michele.digiorgio@arm.com> Reviewed-by: Javi Merino <javi.merino@arm.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-08-08thermal/powerclamp: Prevent division by zero when counting intervalPetr Mladek
I have got a zero division error when disabling the forced idle injection from the intel powerclamp. I did echo 0 >/sys/class/thermal/cooling_device48/cur_state and got [ 986.072632] divide error: 0000 [#1] PREEMPT SMP [ 986.078989] Modules linked in: [ 986.083618] CPU: 17 PID: 24967 Comm: kidle_inject/17 Not tainted 4.7.0-1-default+ #3055 [ 986.093781] Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.R3.27.D685.1305151734 05/15/2013 [ 986.106227] task: ffff880430e1c080 task.stack: ffff880427ef0000 [ 986.114122] RIP: 0010:[<ffffffff81794859>] [<ffffffff81794859>] clamp_thread+0x1d9/0x600 [ 986.124609] RSP: 0018:ffff880427ef3e20 EFLAGS: 00010246 [ 986.131860] RAX: 0000000000000258 RBX: 0000000000000006 RCX: 0000000000000001 [ 986.141179] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000018 [ 986.150478] RBP: ffff880427ef3ec8 R08: ffff880427ef0000 R09: 0000000000000002 [ 986.159779] R10: 0000000000003df2 R11: 0000000000000018 R12: 0000000000000002 [ 986.169089] R13: 0000000000000000 R14: ffff880427ef0000 R15: ffff880427ef0000 [ 986.178388] FS: 0000000000000000(0000) GS:ffff880435940000(0000) knlGS:0000000000000000 [ 986.188785] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 986.196559] CR2: 00007f1d0caf0000 CR3: 0000000002006000 CR4: 00000000001406e0 [ 986.205909] Stack: [ 986.209524] ffff8802be897b00 ffff880430e1c080 0000000000000011 0000006a35959780 [ 986.219236] 0000000000000011 ffff880427ef0008 0000000000000000 ffff8804359503d0 [ 986.228966] 0000000100029d93 ffffffff81794140 0000000000000000 ffffffff05000011 [ 986.238686] Call Trace: [ 986.242825] [<ffffffff81794140>] ? pkg_state_counter+0x80/0x80 [ 986.250866] [<ffffffff81794680>] ? powerclamp_set_cur_state+0x180/0x180 [ 986.259797] [<ffffffff8111d1a9>] kthread+0xc9/0xe0 [ 986.266682] [<ffffffff8193d69f>] ret_from_fork+0x1f/0x40 [ 986.274142] [<ffffffff8111d0e0>] ? kthread_create_on_node+0x180/0x180 [ 986.282869] Code: d1 ea 48 89 d6 80 3d 6a d0 d4 00 00 ba 64 00 00 00 89 d8 41 0f 45 f5 0f af c2 42 8d 14 2e be 31 00 00 00 83 fa 31 0f 42 f2 31 d2 <f7> f6 48 8b 15 9e 07 87 00 48 8b 3d 97 07 87 00 48 63 f0 83 e8 [ 986.307806] RIP [<ffffffff81794859>] clamp_thread+0x1d9/0x600 [ 986.315871] RSP <ffff880427ef3e20> RIP points to the following lines: compensation = get_compensation(target_ratio); interval = duration_jiffies*100/(target_ratio+compensation); A solution would be to switch the following two commands in powerclamp_set_cur_state(): set_target_ratio = 0; end_power_clamp(); But I think that the zero division might happen also when target_ratio is non-zero because the compensation might be negative. Therefore we also check the sum of target_ratio and compensation explicitly. Also the compensated_ratio variable is always set. Therefore there is no need to initialize it. Signed-off-by: Petr Mladek <pmladek@suse.com> Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-08-08thermal: intel_pch_thermal: Add suspend/resume callbackSrinivas Pandruvada
Added suspend/resume callback to disable/enable PCH thermal sensor respectively. If the sensor is enabled by the BIOS, then the sensor status will not be changed during suspend/resume. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>