Dave Airlie [Tue, 8 Mar 2016 00:51:51 +0000 (10:51 +1000)]
Merge branch 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-next
Some more radeon and amdgpu stuff for drm-next. Mostly just bug fixes
for new features and cleanups.
* 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: fix rb bitmap & cu bitmap calculation
drm/amdgpu: trace the pd_addr in vm_grab_id as well
drm/amdgpu: fix VM faults caused by vm_grab_id() v4
drm/amdgpu: update radeon acpi header
drm/radeon: update radeon acpi header
drm/amd: cleanup get_mfd_cell_dev()
drm/amdgpu: fix error handling in amdgpu_bo_list_set
drm/amd/powerplay: fix code style warning.
drm/amd: Do not make DRM_AMD_ACP default to y
drm/amdgpu/gfx: fix off by one in rb rework (v2)
Dave Airlie [Tue, 8 Mar 2016 00:51:14 +0000 (10:51 +1000)]
Merge branch 'drm-etnaviv-next' of git://git.pengutronix.de/git/lst/linux into drm-next
Notable changes:
- correctness fixes to the GPU cache flushing when switching execution
state and when powering down the GPU
- reduction of time spent in hardirq-off context
- placement improvements to the GPU DMA linear window, allowing the
driver to properly work on i.MX6 systems with more than 2GB of RAM
* 'drm-etnaviv-next' of git://git.pengutronix.de/git/lst/linux:
drm: etnaviv: clean up submit_bo()
drm: etnaviv: clean up vram_mapping submission/retire path
drm: etnaviv: improve readability of command insertion to ring buffer
drm: etnaviv: clean up GPU command submission
drm: etnaviv: use previous GPU pipe state when pipe switching
drm: etnaviv: flush all GPU caches when stopping GPU
drm: etnaviv: track current execution state
drm: etnaviv: extract arming of semaphore
drm: etnaviv: extract replacement of WAIT command
drm: etnaviv: extract command ring reservation
drm/etnaviv: move GPU linear window to end of DMA window
drm/etnaviv: move runtime PM balance into retire worker
Dave Airlie [Tue, 8 Mar 2016 00:50:37 +0000 (10:50 +1000)]
Merge tag 'drm-intel-next-2016-02-29' of git://anongit.freedesktop.org/drm-intel into drm-next
- fbc by default on hsw&bdw, thanks to great work by Paulo!
- psr by default hsw,bdw,vlv&chv, thanks to great work by Rodrigo!
- fixes to hw state readout vs. rpm issues (Imre)
- dc3 fixes&improvements (Mika), this and above already cherr-pick to -fixes
- first part of locking fixes from Tvrtko
- proper atomic code for load detect (Maarten)
- more rpm fixes from Ville
- more atomic work from Maarten
* tag 'drm-intel-next-2016-02-29' of git://anongit.freedesktop.org/drm-intel: (63 commits)
drm/i915: Update DRIVER_DATE to 20160229
drm/i915: Execlists cannot pin a context without the object
drm/i915: Reduce the pointer dance of i915_is_ggtt()
drm/i915: Rename vma->*_list to *_link for consistency
drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)
drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS
drm/i915/gen9: Set value of Indirect Context Offset based on gen version
drm/i915: Remove update_sprite_watermarks.
drm/i915: Kill off intel_crtc->atomic.wait_vblank, v6.
drm/i915: Unify power domain handling.
drm/i915: Pass crtc state to modeset_get_crtc_power_domains.
drm/i915: Add for_each_pipe_masked()
drm/i915: Make sure pipe interrupts are processed before turning off power well on BDW+
drm/i915: synchronize_irq() before turning off disp2d power well on VLV/CHV
drm/i915: Skip PIPESTAT reads from irq handler on VLV/CHV when power well is down
drm/i915/gen9: Write dc state debugmask bits only once
drm/i915/gen9: Extend dmc debug mask to include cores
drm/i915/gen9: Verify and enforce dc6 state writes
drm/i915/gen9: Check for DC state mismatch
drm/i915/fbc: enable FBC by default on HSW and BDW
...
Dave Airlie [Tue, 8 Mar 2016 00:49:58 +0000 (10:49 +1000)]
Merge tag 'tilcdc-4.6' of https://github.com/jsarha/linux into drm-next
tilcdc changes for v4.6
Accumulated fixes and improvements from ti-linux-4.1.
* Almost complete rewrite of pagefliping code
* dma-buf support
* pinctrl support
* lot of fixes and cleanups
* tag 'tilcdc-4.6' of https://github.com/jsarha/linux: (22 commits)
drm/tilcdc: Use devm_kzalloc() and devm_kcalloc() for private data
drm/tilcdc: Initialize crtc->port
drm/tilcdc: Disable sync lost interrupt if it fires on every frame
drm/tilcdc: Add prints on sync lost and FIFO underrun interrupts
drm/tilcdc: Remove the duplicate LCDC_INT_ENABLE_SET_REG in registers[]
drm/tilcdc: Fix interrupt enable/disable code for version 2 tilcdc
drm/tilcdc: Do not update the next frame buffer close to vertical blank
drm/tilcdc: Get rid of complex ping-pong mechanism
drm/tilcdc: cleanup irq handling
drm/tilcdc: remove broken error handling
drm/tilcdc: split reset to a separate function
drm/tilcdc: disable crtc on unload
drm/tilcdc: cleanup runtime PM handling
drm/tilcdc: Allocate register storage based on the actual number registers
drm/tilcdc: fix build error when !CONFIG_CPU_FREQ
drm/tilcdc: Implement dma-buf support for tilcdc
drm/tilcdc: disable the lcd controller/dma engine when suspend invoked
drm/tilcdc: make frame_done interrupt active at all times
drm/tilcdc: fix kernel panic on suspend when no hdmi monitor connected
drm/tilcdc: adopt pinctrl support
...
Brian Norris [Sat, 5 Mar 2016 01:19:23 +0000 (17:19 -0800)]
mtd: nand: check status before reporting timeout
In commit b70af9bef49b ("mtd: nand: increase ready wait timeout and
report timeouts"), we increased the likelihood of scheduling during
nand_wait(). This makes us more likely to hit the time_before(...)
condition, since a lot of time may pass before we get scheduled again.
Now, the loop was already buggy, since we don't check if the NAND is
ready after exiting the loop; we simply print out a timeout warning. Fix
this by doing a final status check before printing a timeout message.
This isn't actually a critical bug, since the only effect is a false
warning print. But too many prints never hurt anyone, did they? :)
Side note: perhaps I'm not smart enough, but I'm not sure what the best
policy is for this kind of loop; do we busy loop (i.e., no
cond_resched()) to keep the lowest I/O latency (it's not great if the
resched is delaying Richard's system ~400ms)? Or do we allow
rescheduling, to play nice with the rest of the system (since some
operations can take quite a while)?
Reported-by: Richard Weinberger <richard@nod.at> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Richard Weinberger <richard@nod.at> Reviewed-by: Harvey Hunt <harvey.hunt@imgtec.com>
projects / karo-tx-linux.git / log