Only importing an FD to a handle is currently supported on UDL,
but the exporting functionality is equally useful.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
By default set udl_gem_object as cacheable, but set WC flag when attaching
dmabuf. In udl_gem_mmap() update cache attributes based on the flags, similar
to exynos_drm_gem_mmap().
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Before this patch, cirrus_device_init could have failed while
cirrus_mm_init succeeded and the driver would have reported overall
success on load. This patch causes cirrus_device_init to return on
the first error encountered.
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Oversight from my kerneldoc cleanup when doing the original atomic
helper series - I've only applied this clarification to the modeset
related helpers, and not the plane update code. Remedy this asap.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I guess for hysterical raisins this was meant to be the way to read
blob properties. But that's done with the two-stage approach which
uses separate blob kms object and the special-purpose get_blob ioctl.
Shipping userspace seems to have never relied on this, and the kernel
also never put any blob thing onto that property. And nowadays it
would blow up, e.g. in drm_property_destroy. Also it makes no sense to
return values in an ioctl that only returns metadata about everything.
So let's ditch all the internal code for the blob list, rename the
list to be unambiguous and sprinkle comments all over the place to
explain this peculiar piece of api.
v2: Squash in fixup from Rob to remove now unused variables.
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- Make it clear that it's a negative errno (more in line with
everything else).
- Clean up the confusion around get_properties vs. getproperty ioctls:
One reads per-obj property values, the other reads property
metadata.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Yet another fallout from not considering DP MST hotplug. With the
previous patches we have stable indices, but it might still happen
that a connector gets added between when we allocate the array and
when we actually add a connector. Especially when we back off due to
ww mutex contention or similar issues.
So store the sizes of the arrays in struct drm_atomic_state and double
check them. We don't really care about races except that we want to
use a consistent value, so ACCESS_ONCE is all we need. And if we
indeed notice that we'd overrun the array then just give up and
restart the entire ioctl.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise the connector might have been unplugged and destroyed while
we didn't look. Yet another fallout from DP MST hotplugging that I
didn't consider.
To make sure we get this right add an appropriate WARN_ON to
drm_atomic_state_clear (obviously only when we actually have a state
to clear up). And reorder all the state_clear and backoff calls to
make it work out properly.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I've totally forgotten that with DP MST connectors can now be
hotplugged. And failed to adapt Rob's drm_atomic_state code (which
predates connector hotplugging) to the new realities.
The first step is to make sure that the connector indices used to
access the arrays of pointers are stable. The connection mutex gives
us enough guarantees for that, which means we won't unecessarily block
on concurrent modesets or background probing.
So add a locking WARN_ON and shuffle the code slightly to make sure we
always hold the right lock.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Let's make things a bit easier to debug when things go bad (potentially
under console_lock).
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Andrew Morton wrote:
> On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> > Andrew Morton wrote:
> > > Poor ttm guys - this is a bit of a trap we set for them.
> >
> > Commit a91576d791 ("drm/ttm: Pass GFP flags in order to avoid deadlock.")
> > changed to use sc->gfp_mask rather than GFP_KERNEL.
> >
> > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
> > - GFP_KERNEL);
> > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> >
> > But this bug is caused by sc->gfp_mask containing some flags which are not
> > in GFP_KERNEL, right? Then, I think
> >
> > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL);
> >
> > would hide this bug.
> >
> > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag)
>
> Well no - ttm_page_pool_free() should stop calling kmalloc altogether.
> Just do
>
> struct page *pages_to_free[16];
>
> and rework the code to free 16 pages at a time. Easy.
Well, ttm code wants to process 512 pages at a time for performance.
Memory footprint increased by 512 * sizeof(struct page *) buffer is
only 4096 bytes. What about using static buffer like below?
----------
>From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Thu, 13 Nov 2014 22:21:54 +0900
Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions.
Commit a91576d791 ("drm/ttm: Pass GFP flags in order to avoid
deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags
which are not in GFP_KERNEL.
https://bugzilla.kernel.org/show_bug.cgi?id=87891
Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would
avoid the BUG_ON(), but avoiding memory allocation from shrinker
function is better and reliable fix.
Shrinker function is already serialized by global lock, and
clean up function is called after shrinker function is unregistered.
Thus, we can use static buffer when called from shrinker function
and clean up function.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit f9b9faf6d94dd29eab8c128905c7d091f955481d "drm: flip-work: change
drm_flip_work_init prototype" changed the drm_flip_work_init prototype
to a void function, which makes 'ret' an unused variable.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Implement crtc page_flip callback for bochsdrm. The qemu stdvga has no
vblank signaling, so we have to fake it. We do so by instantly calling
drm_send_vblank_event. Tested with kmscon.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove the mapping offset from the bo backing the fbdev framebuffer.
Wire up fbdev mmap function to map the backing bo using ttm_fbdev_mmap.
With that patch in place mmap(/dev/fb0) works as expected.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Recently (qemu 2.2+) the qemu stdvga got a register to switch the vga
framebuffer endianness. This patch adds code to explicitly set the
endianness of the framebuffer. In most cases this has no effect as
the default is guest architecture endianness. It is needed though in
case a architecture supports both big and little endian, i.e. for
ppc64le.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Main pull for 3.19. I may have another pull in a few days with some
mdp5 bits (and hopefully mdp5 atomic), but I figured there was no need
to hold up what we have already. Main highlights so far:
1) a4xx gpu support (userspace gallium bits on mesa master)
2) mdp4/hdmi/core bits for atomic helpers. Still missing mdp5
conversion, main hold up there is current hard-coded mixer setup isn't
clever enough to deal with disabling primary plane while crtc active.
3) various other misc cleanup/fixes/etc..
* 'msm-next' of git://people.freedesktop.org/~robclark/linux: (21 commits)
drm/msm: a4xx support for msm-drm
drm/msm: Handle register offset differences between a3xx and a4xx
drm/msm: small mmap offset cleanups
drm/msm/mdp4: atomic
drm/msm/hdmi: atomic
drm/msm: atomic core bits
drm/msm: bit of fb error checking
drm/msm: fb prepare/cleanup
drm/msm: remove unused compile-test stub
drm/msm: small fence cleanup
drm/msm/mdp5: drop attached planes table
drm/msm/mdp4: drop attached planes table
drm/msm/mdp4: don't care about fb in crtc
drm/msm/mdp5: drop private primary ptr
drm/msm/mdp4: drop private primary ptr
drm/msm: Fix fbdev for 16- and 24-bit modes.
drm/msm: Allow exported dma-bufs to be mapped
drm/msm/hdmi: refactor bind/init
drm/msm: update generated headers
drm/msm/adreno: slight init order cleanup
...
Register offsets have changed between a3xx and a4xx GPUs.
To be able access these registers in common code, we create
a lookup table, and set of read-write APIs to access the
register through the lookup table.
Signed-off-by: Aravind Ganesan <aravindg@codeaurora.org>
[robclark: remove REG_ADRENO_UNDEFINED, just use zero, and minor
tweaks for latest generated headers]
Signed-off-by: Rob Clark <robdclark@gmail.com>
Use pre-computed iova when unmapping, to reduce the places we assume iova
and mmap offset are (at the moment) the same. And get rid of an extra
drm_gem_free_mmap_offset() call (since it is already called from
drm_gem_object_release())
Signed-off-by: Rob Clark <robdclark@gmail.com>
It's a problem that can't happen yet, since we don't support any
multi-planar formats yet. But let's avoid nasty surprises when the
time comes.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Atomic wants to split the prepare/pin from where we actually program the
scanout address (so that any part that can fail is done synchronously).
Add some fb/gem apis to make this easier to use from the kms parts.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Give ourselves a way to wait for certain fence #.. makes it easier to
wait on a set of bo's, which we'll need for atomic.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Simplify things a bit for atomic, gets rid of some bookkeeping, and
makes the code cleaner.
TODO move iterator macro somewhere common.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since we are configuring things via MDP4_PIPE regs in the plane, it seems
like setting the dimensions of the primary plane on the OVLP/DMA regs in
crtc is unnecessary. This will make life easier when we want to do a
nofb modeset.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Currently forcing the video mode from the kernel command line (for example
video=HDMI-A-1:1280x720-16@60) does not correctly set the number of bits
per pixel. This is due to a rather aggressive override in
msm_fbdev_create(). This is a particular problem for Android bring up
because the software EGL fallbacks don't support 32bpp.
Since the overrides are actually the default values anyway then this
problem can be trivially fixed by removing the overrides completely.
Change was tested by dd'ing a test image to /dev/fb0 with no video=
(still 32bpp), video=1920x1080-32@60, video=1920x1080-24@60 and
video=1920x1080-16@60 .
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Currently msm does not implement gem_prime_mmap. Without this it is not
possible to draw onto a dma-buf from userspace (making its very hard to
implement the Android rendering model).
Fixing this is just a matter of adding a little boilerplate.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Split up hdmi_init() into hdmi_init() (done at hdmi sub-device
bind/probe time) and hdmi_modeset_init() done from master driver's
modeset_init().
Anything that can fail due to dependencies on other drivers which
may be missing or not probed yet should go in hdmi_init(), so that
devm error/cleanup paths work properly.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Move anything that can fail after call to base class msm_gpu_init().
This way, if we fail, active_list has already been initialized so we
don't trip 'WARN_ON(!list_empty(&gpu->active_list))' in
msm_gpu_cleanup().
Signed-off-by: Rob Clark <robdclark@gmail.com>
Fixes a potential error, spotted by Felipe with randconfig:
-----
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ‘mdp4_kms_init’:
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \
of function ‘devm_regulator_get_exclusive’ [-Werror=implicit-function-declaration]
mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
^
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:16: error: assignment makes \
pointer from integer without a cast [-Werror]
mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
^
-----
Also add a brief comment explaining the use of _get_exclusive()
Reported-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Some drivers erroneously treat the .pitch and .size fields of struct
drm_mode_create_dumb as inputs. While the include/uapi/drm/drm_mode.h
header has a comment denoting them as outputs, that seemingly wasn't
enough to make drivers use them properly.
The result is that some userspace doesn't explicitly zero out those
fields, assuming that the kernel won't use them. That causes problems
since the data within the structure might be uninitialized, so bogus
data may end up confusing drivers (ridiculously large values for the
pitch, ...).
This series attempts to improve the situation by fixing all drivers to
not use the output fields. Furthermore to spare new drivers this bad
surprise, the DRM core now zeros out these fields prior to handing the
data structure to the driver.
Lessons learned from this are that future IOCTLs should be properly
documented (in the DRM DocBook for example) and should be rigorously
defined. To prevent misuse like this, userspace should be required to
zero out all output fields. The kernel should check for this and fail
if that's not the case.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUZKbcAAoJEN0jrNd/PrOh57QQAKdX7ASd4XVhMC6fuVGXHUXI
HVZuJ3Own+e3aAJKhZ2DZ263+PtBLfe3+eEF1WRWqZcDu647Nj3wSV64celdZdIl
WHU2RokxneHTPHlttZ+MLhVwtzSddO8712iLU/2B7Rg/MNlN9tv9tbRtGqPWwlzg
IZNAdU5etnm+YDYil8/I8f84+5vT59Z/X2NHbq+jReD3V6I2WBAK6zlRIy4o54io
fccK7M6+uGlbNmtPwoKXufeiqTxxdYYelZoQzO4NjWEhdU0LoUnTFdfqISSdt3HV
26NwTmqVTx38AD5bGwot2b1VFEkja5tkP7G+DeFkj0DRHbFfAQK/tNeqdf9xq4gQ
UEVjljyEW6dauibtT6ASk2RoTmQmMVWw44aSulcaz6eVqa21zpEwOZVMX/VW3QM+
vKh4Vy6eVbCHmdOiXgtQSexQAN6uO1o9cHEGamJQpMshm+kax9T7hBdcHMH0ORtL
uEYHXzqB/bbkhAodHTraoZ5aM8YFwS2TgGtCJoYw1GHehMhjpJG9HaDlL50lkObk
LDUShta8AwN9iu3/qmkaYaxkbBPEnRtU9d9qO6S1NsZugBmmEUj6lNKFOK13U9Ho
vjKWTpB4USgKdrTwJXEAXJTBmubwrPBnZb1vdCovCtC3JS7sXUH8AM/E6tp4Q0Go
idGCjMglaSFO8EUeScFT
=QZIW
-----END PGP SIGNATURE-----
Merge tag 'drm/gem-cma/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux into drm-next
drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input
Some drivers erroneously treat the .pitch and .size fields of struct
drm_mode_create_dumb as inputs. While the include/uapi/drm/drm_mode.h
header has a comment denoting them as outputs, that seemingly wasn't
enough to make drivers use them properly.
The result is that some userspace doesn't explicitly zero out those
fields, assuming that the kernel won't use them. That causes problems
since the data within the structure might be uninitialized, so bogus
data may end up confusing drivers (ridiculously large values for the
pitch, ...).
This series attempts to improve the situation by fixing all drivers to
not use the output fields. Furthermore to spare new drivers this bad
surprise, the DRM core now zeros out these fields prior to handing the
data structure to the driver.
Lessons learned from this are that future IOCTLs should be properly
documented (in the DRM DocBook for example) and should be rigorously
defined. To prevent misuse like this, userspace should be required to
zero out all output fields. The kernel should check for this and fail
if that's not the case.
* tag 'drm/gem-cma/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux:
drm/cma: Remove call to drm_gem_free_mmap_offset()
drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input
drm/rcar: gem: dumb: pitch is an output
drm/omap: gem: dumb: pitch is an output
drm/cma: Introduce drm_gem_cma_dumb_create_internal()
drm/doc: Add GEM/CMA helpers to kerneldoc
drm/doc: mm: Fix indentation
drm/gem: Fix a few kerneldoc typos
This passes the guest preferences for a where to place the
outputs through to userspace. Userspace would need to be updated
to take note of this information, X server and GNOME.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Virtual GPUs would like to give the guest some indication where on the screen
the outputs are layed out. So far we only provide modes, these
properties could be exposed to userspace so the desktop environment
could use them as hints to set the correct offsets.
v2: rename properties to be more consistent.
Signed-off-by: Dave Airlie <airlied@redhat.com>
While looking through drm_crtc.c to double-check make locking changes
I've noticed that there's a few other places that would now benefit
from simplified return value handling.
So let's flatten the control flow and replace and always 0 ret with 0
where possible.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The highlights in this pull request are:
* IOMMU support: The Tegra DRM driver can now deal with discontiguous
buffers if an IOMMU exists in the system. That means it can allocate
using drm_gem_get_pages() and will map them into IOVA space via the
IOMMU API. Similarly, non-contiguous PRIME buffers can be imported
from a different driver, which allows better integration with gk20a
(nouveau) and less hacks.
* Universal planes: This is precursory work for atomic modesetting and
will allow hardware cursor support to be implemented on pre-Tegra114
where RGB cursors were not supported.
* DSI ganged-mode support: The DSI controller can now gang up with a
second DSI controller to drive high resolution DSI panels.
Besides those bigger changes there is a slew of fixes, cleanups, plugged
memory leaks and so on.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUZM29AAoJEN0jrNd/PrOhd1EP/iGBGppcPiYhFI6CC2V5IyGO
j4GaNU656QQj0RNS3RH0Oby0oHdQum2rFNtHnkGYjoXFiSznId3OwVQ1+Y1s5804
BkPSR1Q3fyIfsQdGA9DEkVGuyavCEbJ9yOalIBLda456nxfkPFBJdNjq5AJDT2N1
J54MSRtV3fV5Uerd7WbmiNdLyuly4Gyyb7ApotOQEsfYvaGgobdpMRGyp38tvYbD
pNDZ69iYBSJmaVaF1a/NxFw3/25CSHakY5J95R9eXK1Y3BKDBhqHo7b1L1XMt1L5
yKEy+eqjnnB7/itszjKG3dnMHunKsch9C+nyxR4xKMf036Pesz65tMbg07Pd0cIy
oYZMDGdm380d0mu41LydN7zK/ZZf6bBfcZallnxk1CSEQB6BcMZhOmQP2aa8r9rU
VdaNGlNio7XAjVGDsd8Y652y27NH7VJTpx3nxXB0f7eyGg7AlfLKxOFehDE+beVJ
OAzRQrHJ63vOIAUg21G84W4cvpsVSG4FomgRTXC8Se6WcwP3TWD5MmOzLYNjbFnb
ayuIiIfNtyu2KJU60hCOqWQg05UcWIYRkvxmdnQQcFyItmw4qJzh9ep7ebAqTx0t
0p0y5/O7KGYKS1pB7o1XJtL84N7SPiNGB3fdwiGryl9Z7hypuhKS7/lRBDTiiTAd
Ok1HHSRDxTaiGhrN3TKH
=v4QW
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux into drm-next
drm/tegra: Changes for v3.19-rc1
The highlights in this pull request are:
* IOMMU support: The Tegra DRM driver can now deal with discontiguous
buffers if an IOMMU exists in the system. That means it can allocate
using drm_gem_get_pages() and will map them into IOVA space via the
IOMMU API. Similarly, non-contiguous PRIME buffers can be imported
from a different driver, which allows better integration with gk20a
(nouveau) and less hacks.
* Universal planes: This is precursory work for atomic modesetting and
will allow hardware cursor support to be implemented on pre-Tegra114
where RGB cursors were not supported.
* DSI ganged-mode support: The DSI controller can now gang up with a
second DSI controller to drive high resolution DSI panels.
Besides those bigger changes there is a slew of fixes, cleanups, plugged
memory leaks and so on.
* tag 'drm/tegra/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux: (44 commits)
drm/tegra: gem: Check before freeing CMA memory
drm/tegra: fb: Add error codes to error messages
drm/tegra: fb: Properly release GEM objects on failure
drm/tegra: Detach panel when a connector is removed
drm/tegra: Plug memory leak
drm/tegra: gem: Use more consistent data types
drm/tegra: fb: Do not destroy framebuffer
drm/tegra: gem: dumb: pitch and size are outputs
drm/tegra: Enable the hotplug interrupt only when necessary
drm/tegra: dc: Universal plane support
drm/tegra: dc: Registers are 32 bits wide
drm/tegra: dc: Factor out DC, window and cursor commit
drm/tegra: Add IOMMU support
drm/tegra: Fix error handling cleanup
drm/tegra: gem: Use dma_mmap_writecombine()
drm/tegra: gem: Remove redundant drm_gem_free_mmap_offset()
drm/tegra: gem: Cleanup tegra_bo_create_with_handle()
drm/tegra: gem: Extract tegra_bo_alloc_object()
drm/tegra: dsi: Set up PHY_TIMING & BTA_TIMING registers earlier
drm/tegra: dsi: Replace 1000000 by USEC_PER_SEC
...
This is a small collection of fixes that I've been carrying around for a
while now. Many of these have been posted and reviewed or acked. The few
that haven't I deemed too trivial to bother.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUZKenAAoJEN0jrNd/PrOhNwkQAJTGxhol/k0Vj+P+HVj+MROU
9EEw67mh/c2Y4zQxEmWRE/rHdIgoz4zPL5hoJLLjPmorvKil6BIfURUybxYu9n3b
MrunoA7adxvL+Uce+XMkuvWUE2fxFNaEwU+FT66Ib+Lo8A25FZXBqo125/RmhAHZ
EQKcr0MBH76jybYoyB1H1pf/O3i6qODmh3kXT4Fved3jf5mZNPl5wgCSSr/4ilOZ
wx3pzG3BvIrsyvGF6Q0oAjDEbaBTOhglfAvPFhC16cfhtPJMzVvx6v/abtipMjRv
pUY3t96BvL1pyszcEc/ykjDX/ODlY00uOe1GgRSSXS/bThF0HJP14rTpjO+6ycON
rap17o2feRuK3c2NzLMqv4bjkaNF/ut+2YnByulJWnpg1dDjIpJOzJ6Heep5D6+H
lV5QP0B9LGI4718le2tv5hkH0NnQygiyRlACRzLBpq9gnXuSoSZYxjo6SuVid1X8
Ebs+QKNoTl1NEYeEvT/CnC552MdWzntcNjE9SA1yj0RgrIS87x8bmXqh/zAwa2dI
1Lq1wZ965ruDUPCGrd6jE8JiiEEXJjJr0y6zA4LBnR+OvmR/2GN7KCwjX+jwBthq
9dyO9YEnxSXT/dFEUumx3F4ZKcPUntT61pT6ZblIljiJ5vw6SegDXdWDc+eZ4QyD
y2YyxRL+KxPftkeyfU4j
=OUaP
-----END PGP SIGNATURE-----
Merge tag 'drm/fixes/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux into drm-next
drm: Miscellaneous fixes for v3.19-rc1
This is a small collection of fixes that I've been carrying around for a
while now. Many of these have been posted and reviewed or acked. The few
that haven't I deemed too trivial to bother.
* tag 'drm/fixes/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux:
video/hdmi: Relicense header under MIT license
drm/gma500: mdfld: Reuse video/mipi_display.h
drm: Make drm_mode_create_tv_properties() signature consistent
drm: Implement drm_get_pci_dev() dummy for !PCI
drm/prime: Use unsigned type for number of pages
drm/gem: Fix typo in kerneldoc
drm: Use const data when creating blob properties
drm: Use size_t for blob property sizes
This contains support for a couple of new panels, updates for some GPIO
API changes and a bunch of updates to the MIPI DSI support that should
make it easier to write panel drivers in the future.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUZKsmAAoJEN0jrNd/PrOhvoQP/Ryl8OHSEOB6vNxn7cmz3nQf
0l+2Q3V3qpJALC3Dlm57kSF1760mHNjPuwiVLhjINn5zcDS4kB3Llgx/dmAzgTZA
Ikm8iDgcOmlBUBE1W5YuzdSCXJK8Eth9JQiA4yQVS0RWi+WEClwb+F7KBLi+9Ep3
1C3qURrBAfe9DRzU4GswrsCzBQACCKH8f+2OcYeFMW0eMa7ejHNs+n0wi6lMLvLn
JrxEuMBKWdXbM2sw4UXvpVZm3CTh8dJtXBkpwOBK75XhY9DSsrqmbdk0qKIDCY+y
JB/5UTU2sg37ZFnvhFoHN10AtXWnGbwS2iCitNSmKaBOARVbcoWk9pJtR3AHc44c
cpLVTsJgZStYZAydtVZKQDJWLNTnTMtyLPcy9eq6kLMc8sVe930U8IsGQyihyyUU
cSDP8Z6THZ2zHqfDnmogjm8XWsUa+LimNwAgm5oub8JKxdqGb49J8ry+Ny4a19cS
MgqVZE85K9aF7e/VxeGFiIpUb5ax5bLQxrcpVJg/d2TFuftNBslmL3FOkvEbwrLM
WS9KJ8e8VIRNoI5dtemfx0+LGlLwoPaUWSeWpb8OxUAuy6e5NabazkFQuCb5E+HM
JLqnMFCCVvwtGyr+DrFiF4ye8ZTZNcFcdidgB4mr9D5k7RksyeZTT4vz13y2JyAr
VcfbBQICIQzn91osEetJ
=+xMK
-----END PGP SIGNATURE-----
Merge tag 'drm/panel/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux into drm-next
drm/panel: Changes for v3.19-rc1
This contains support for a couple of new panels, updates for some GPIO
API changes and a bunch of updates to the MIPI DSI support that should
make it easier to write panel drivers in the future.
* tag 'drm/panel/for-3.19-rc1' of git://people.freedesktop.org/~tagr/linux: (31 commits)
drm/panel: Add Sharp LQ101R1SX01 support
drm/dsi: Do not require .owner field to be set
drm/dsi: Resolve MIPI DSI device from phandle
drm/dsi: Implement DCS set_{column,page}_address commands
drm/dsi: Implement DCS {get,set}_pixel_format commands
drm/dsi: Implement DCS get_power_mode command
drm/dsi: Implement DCS soft_reset command
drm/dsi: Implement DCS nop command
drm/dsi: Add to DocBook documentation
drm/dsi: Implement some standard DCS commands
drm/dsi: Implement generic read and write commands
drm/panel: s6e8aa0: Use standard MIPI DSI function
drm/dsi: Add mipi_dsi_set_maximum_return_packet_size() helper
drm/dsi: Constify mipi_dsi_msg
drm/dsi: Make mipi_dsi_dcs_{read,write}() symmetrical
drm/dsi: Add DSI transfer helper
drm/dsi: Add message to packet translator
drm/dsi: Introduce packet format helpers
drm/panel: s6e8aa0: Fix build warnings on 64-bit
drm/panel: ld9040: Fix build warnings on 64-bit
...
- skl watermarks code (Damien, Vandana, Pradeep)
- reworked audio codec /eld handling code (Jani)
- rework the mmio_flip code to use the vblank evade logic and wait for rendering
using the standard wait_seqno interface (Ander)
- skl forcewake support (Zhe Wang)
- refactor the chv interrupt code to use functions shared with vlv (Ville)
- prep work for different global gtt views (Tvrtko Ursulin)
- precompute the display PLL config before touching hw state (Ander)
- completely reworked panel power sequencer code for chv/vlv (Ville)
- pre work to split the plane update code into a prepare and commit phase
(Gustavo Padovan)
- golden context for skl (Armin Reese)
- as usual tons of fixes and improvements all over
* tag 'drm-intel-next-2014-11-07-fixups' of git://anongit.freedesktop.org/drm-intel: (135 commits)
drm/i915: Use correct pipe config to update pll dividers. V2
drm/i915: Plug memory leak in intel_shared_dpll_start_config()
drm/i915: Update DRIVER_DATE to 20141107
drm/i915: Add gen to the gpu hang ecode
drm/i915: Cache HPLL frequency on VLV/CHV
Revert "drm/i915/vlv: Remove check for Old Ack during forcewake"
drm/i915: Make mmio flip wait for seqno in the work function
drm/i915: Make __wait_seqno non-static and rename to __i915_wait_seqno
drm/i915: Move the .global_resources() hook call into modeset_update_crtc_power_domains()
drm/i915/audio: add DOC comment describing HDA over HDMI/DP
drm/i915: make pipe/port based audio valid accessors easier to use
drm/i915/audio: add audio codec enable debug log for g4x
drm/i915/audio: add audio codec disable on g4x
drm/i915: enable audio codec after port
drm/i915/audio: add vlv/chv/gen5-7 audio codec disable sequence
drm/i915/audio: rewrite vlv/chv and gen 5-7 audio codec enable sequence
drm/i915/skl: Enable Gen9 RC6
drm/i915/skl: Gen9 Forcewake
drm/i915/skl: Log the order in which we flush the pipes in the WM code
drm/i915/skl: Flush the WM configuration
...
Don't BUG out if the link reports an invalid (or plain unknown)
bandwidth value, but report the failure and fail gracefully.
Fixes a trivial compiler warning in case the BUG is ever compiled away.
Link: http://lkml.kernel.org/p/1415785566-12758-1-git-send-email-geert@linux-m68k.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For async commit, it is *intentional* that those locks are not held.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Haixia Shi