[git pull] drm fixes
Hi Linus, A bunch of change across the board, the main things are some vblank fallout in radeon and nouveau required some work, but I think this should fix it all. There is also one drm fix for an oops in vmwgfx with how we pass the drm master around. The rest is just some amdgpu, i915, imx and rockchip fixes. probably more than I'd like at this point, but hopefully things settle down now. Dave. The following changes since commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8: Linux 4.4-rc3 (2015-11-29 18:58:26 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to df4d4aa96d1db1657e14b848a341fc614c8d61eb: Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux into drm-next (2015-12-05 16:15:38 +1000) Alex Deucher (1): drm/amdgpu: Fixup hw vblank counter/ts for new drm_update_vblank_count() (v3) Chris Wilson (2): drm/i915: Mark uneven memory banks on gen4 desktop as unknown swizzling drm/i915: Check the timeout passed to i915_wait_request Christian König (6): drm/amdgpu: fix userptr flags check drm/amdgpu: fix VM page table reference counting drm/amdgpu: set snooped flags only on system addresses v2 drm/amdgpu: take a BO reference in the display code drm/amdgpu: take a BO reference for the user fence drm/amdgpu: partially revert "drm/amdgpu: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR" v2 Chunming Zhou (1): drm/amdgpu: add err check for pin userptr Daniel Stone (1): drm/rockchip: Use CRTC vblank event interface Daniel Vetter (1): drm/nouveau: Fix pre-nv50 pageflip events (v4) Dave Airlie (5): Merge tag 'drm-intel-fixes-2015-11-30' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge branch 'drm-fixes-rockchip-2015-12-02' of https://github.com/markyzq/kernel-drm-rockchip into drm-fixes Merge tag 'drm-intel-fixes-2015-12-03' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge tag 'imx-drm-fixes-2015-12-01' of git://git.pengutronix.de/git/pza/linux into drm-fixes Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux into drm-next Dominik Behr (1): drm/rockchip: vop: fix window origin calculation Heiko Stuebner (1): drm/rockchip: unset pgoff when mmap'ing gems Imre Deak (3): drm/i915/ddi: fix intel_display_port_aux_power_domain() after HDMI detect drm/i915: add MISSING_CASE to a few port/aux power domain helpers drm/i915: take a power domain reference while checking the HDMI live status Liu Ying (1): drm/imx: ipuv3-crtc: Return error if ipu_plane_init() fails for primary plane Luis de Bethencourt (2): drm: imx: imx-tve: Fix module autoload for OF platform driver drm/rockchip: Fix module autoload for OF platform driver Lyude (1): drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt Marc-André Lureau (1): virtio-gpu: use no-merge for fill-modes Mario Kleiner (1): drm/radeon: Fixup hw vblank counter/ts for new drm_update_vblank_count() (v2) Markus Elfring (1): GPU-DRM-IMX: Delete an unnecessary check before drm_fbdev_cma_restore_mode() Nicolai Hähnle (1): drm/amdgpu: fix race condition in amd_sched_entity_push_job Pavel Machek (1): add blacklist for thinkpad T40p Philipp Zabel (6): drm/imx: switch to universal planes drm/imx: parallel-display: allow to determine bus format from the connected panel gpu: ipu-v3: drop unused dmfc field from client platform data gpu: ipu-v3: Remove reg_offset field gpu: ipu-v3: Assign of_node of child platform devices to corresponding ports drm/imx: Remove of_node assignment from ipuv3-crtc driver probe Russell King (1): drm: imx: convert to drm_crtc_send_vblank_event() Sjoerd Simons (1): drm/rockchip: vop: Correct enabled clocks during setup Takashi Iwai (2): drm/i915: Don't compare has_drrs strictly in pipe config drm/i915: Don't override output type for DDI HDMI Thomas Hellstrom (1): drm: Fix an unwanted master inheritance v2 Ville Syrjälä (2): drm/i915: Clean up AUX power domain handling drm/i915: Introduce a gmbus power domain jimqu (1): drm/amdgpu: add spin lock to protect freed list in vm (v2) drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 108 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 48 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 5 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 17 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 21 - drivers/gpu/dr
[PATCH v2 05/14] ALSA: pcm: Add DRM helper to set constraint for format
On Sat, Dec 05, 2015 at 09:12:34AM +0100, Takashi Iwai wrote: > On Sat, 05 Dec 2015 12:27:03 +0100, > Subhransu S. Prusty wrote: > > > > On Fri, Dec 04, 2015 at 06:59:19AM +0100, Takashi Iwai wrote: > > > On Fri, 04 Dec 2015 12:08:26 +0100, > > > Subhransu S. Prusty wrote: > > > > > > > > On Thu, Dec 03, 2015 at 04:57:14PM +0100, Takashi Iwai wrote: > > > > > On Thu, 03 Dec 2015 22:08:53 +0100, > > > > > Subhransu S. Prusty wrote: > > > > > > > > > > > > Setting the constraint format based on ELD was missing bit in > > > > > > the sound/core pcm drm. Added with this patch. > > > > > > > > > > No, you can't define these here. The format really depends on the > > > > > hardware, while the rate and the channels are independent. > > > > > > > > Probably then I will move this definition to driver. > > > > > > > > > How do you know it's little-endian? And why it must be S24_LE for > > > > > 24bit, not S32_LE? > > > > > > > > Regarding the little-endian, In the driver I think I should set the > > > > constraint for both LE and BE. And the platform as it only supports LE > > > > alone > > > > it will set the constraint accordingly and edianness will be taken care > > > > of. > > > > > > > > Regarding the sample size, from short audio descriptor, the samples can > > > > be > > > > one of 16/20/24 bit. I could use the format bits for 16 and 24 bits but > > > > don't know which format bits macro is suitable for 20bits. So kept it as > > > > S32_LE for 20bits. Should I fix the format bits for 20bits to use S24? > > > > > > No you seem misunderstanding the concept... > > > > Sorry about that. > > > > I re-read the spec, it doesn't mention the container size for the samples. > > Assuming the container will be 32 bits, then I think we should use S24_LE > > for both 20 and 24 bits. > > You can't limit easily from the supported bits. In theory, all > formats that may fit with the given bit should be set. For example, > for a 20bit sample, S24, U24, S32, U32, S24_3, U24_3, S20_3, etc would > match, and even for both endianess. > > The format type doesn't specify only the *max* bit it can pack, but > also only the position of bits to be packed. For example, S24 packs > max 24 bits in the lower 24 bits in a 32bit container. And, S24_3 > packs max 24 bits in a 24bit container. Most of Intel chips takes the > upper bits in a container, so usually they need S32 or S16 no matter > how many bits are used. Thanks for the quick reply. I am thinking to set the format as S16 for 16bits and S32 for 20/24bits. But then we can set S32 for everything as well including 16bits. What do you recommend? > > > Takashi --
[Bug 92858] AMD Radeon GPU Acceleration Disabled Under Kernels 4.2.x and later versions
https://bugs.freedesktop.org/show_bug.cgi?id=92858 --- Comment #12 from Christian König --- (In reply to Darren D. from comment #11) > (In reply to Christian König from comment #10) > And no, I didn't actually type > all the commit tags below out, I simply copied and pasted the output from > git bisect log' into the comment section. Sorry, didn't know that git bisect log was so noisy. > > git bisect start > # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 > git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345 > # bad: [d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754] Linux 4.2-rc1 > git bisect bad d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754 > # good: [4570a37169d4b44d316f40b2ccc681dc93fedc7b] Merge tag 'sound-4.2-rc1' > of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound > git bisect good 4570a37169d4b44d316f40b2ccc681dc93fedc7b > # bad: [8d7804a2f03dbd34940fcb426450c730adf29dae] Merge tag > 'driver-core-4.2-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core > git bisect bad 8d7804a2f03dbd34940fcb426450c730adf29dae > # good: [3d9f96d850e4bbfae24dc9aee03033dd77c81596] Merge tag 'armsoc-dt' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > git bisect good 3d9f96d850e4bbfae24dc9aee03033dd77c81596 > # bad: [692a59e696afe1a4e777d0e4359325336ab0ad89] drm/amdgpu: remove > AMDGPU_CTX_OP_STATE_RUNNING > git bisect bad 692a59e696afe1a4e777d0e4359325336ab0ad89 > # good: [81663016dbfd53e29d1b5c5ddbc9b12ae1d66474] drm/amdkfd: Add module > parameter of send_sigterm > git bisect good 81663016dbfd53e29d1b5c5ddbc9b12ae1d66474 > > Once again, the next kernel I built after telling git the revision starting > with '8166301dbfd..' was good, and with about 172 commits left to bisect, > failed to boot. It got stuck at 'loading initial ramdisk,' the same problem > as I'd been running into during my previous builds. At least by doing it all > over again I've confirmed it's nothing about the source I'm using, but I'm > in the same position still. Is it actually ok to skip revisions until the > kernel I built at least boots? In this case I would suggest to just say git bisect bad until you find a kernel that boots again and then continue till you either have the commit which causes the radeon problem or the boot problem. If it's the radeon problem you find first than we can just continue analyzing it. And if it's the boot lockup problem then please note the commit hash and I will try to figure out what's going wrong here. This way you should be able to finally dig up what's the issue with radeon. Thanks for sticking with that. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/1e5da638/attachment-0001.html>
[Bug 93264] Tonga VM Faults since llvm ScheduleDAGInstrs: Rework schedule graph builder.
https://bugs.freedesktop.org/show_bug.cgi?id=93264 Bug ID: 93264 Summary: Tonga VM Faults since llvm ScheduleDAGInstrs: Rework schedule graph builder. Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: adf.lists at gmail.com R9285 using Unreal ElementalDemo to trigger this. It doesn't start till well into the demo at the same place that triggered an older resolved issue. https://bugs.freedesktop.org/show_bug.cgi?id=93015 (so maybe Nicolai knows what happens at this point in demo) bisecting llvm came up with c0a189c3792865257c1383f176e5401373ed2270 is the first bad commit commit c0a189c3792865257c1383f176e5401373ed2270 Author: Matthias Braun Date: Thu Dec 3 02:05:27 2015 + ScheduleDAGInstrs: Rework schedule graph builder. The new algorithm remembers the uses encountered while walking backwards until a matching def is found. Contrary to the previous version this: - Works without LiveIntervals being available - Allows to increase the precision to subregisters/lanemasks (not used for now) The changes in the AMDGPU tests are necessary because the R600 scheduler is not stable with respect to the order of nodes in the ready queues. Differential Revision: http://reviews.llvm.org/D9068 The demo continues to run/render OK, but I get thousands of - amdgpu :01:00.0: GPU fault detected: 147 0x07d04401 amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x092D80FA amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A044001 VM fault (0x01, vmid 5) at page 153977082, read from 'TC7' (0x54433700) (68) amdgpu :01:00.0: GPU fault detected: 147 0x07d00401 amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0022D16B amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A0C4002 VM fault (0x02, vmid 5) at page 2281835, read from 'TC4' (0x54433400) (196) amdgpu :01:00.0: GPU fault detected: 147 0x07d04001 amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0022D163 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/3a39335c/attachment.html>
[Bug 64661] udl causes blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=64661 Jason Schulz changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |CODE_FIX --- Comment #6 from Jason Schulz --- Later versions of either the nvidia drivers or kernel have fixed this problem. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 92858] AMD Radeon GPU Acceleration Disabled Under Kernels 4.2.x and later versions
https://bugs.freedesktop.org/show_bug.cgi?id=92858 --- Comment #11 from Darren D. --- (In reply to Christian König from comment #10) There's been several delays and I've mostly made no progress, but I thought I should at the least provide an update. The kernels I was building kept not booting and I thought it unwise to keep skipping revisions, so I started over, thinking perhaps something had corrupted or messed up my source. I built and booted a 4.2-rc1 kernel to see if the problem had started by then, and after comfirming acceleration didn't function under it, I re-cloned Linus's git tree and began my bisect again, using 4.1.0 as my good starting point and 4.2-rc1 as my bad starting point. And no, I didn't actually type all the commit tags below out, I simply copied and pasted the output from git bisect log' into the comment section. git bisect start # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345 # bad: [d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754] Linux 4.2-rc1 git bisect bad d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754 # good: [4570a37169d4b44d316f40b2ccc681dc93fedc7b] Merge tag 'sound-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect good 4570a37169d4b44d316f40b2ccc681dc93fedc7b # bad: [8d7804a2f03dbd34940fcb426450c730adf29dae] Merge tag 'driver-core-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core git bisect bad 8d7804a2f03dbd34940fcb426450c730adf29dae # good: [3d9f96d850e4bbfae24dc9aee03033dd77c81596] Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good 3d9f96d850e4bbfae24dc9aee03033dd77c81596 # bad: [692a59e696afe1a4e777d0e4359325336ab0ad89] drm/amdgpu: remove AMDGPU_CTX_OP_STATE_RUNNING git bisect bad 692a59e696afe1a4e777d0e4359325336ab0ad89 # good: [81663016dbfd53e29d1b5c5ddbc9b12ae1d66474] drm/amdkfd: Add module parameter of send_sigterm git bisect good 81663016dbfd53e29d1b5c5ddbc9b12ae1d66474 Once again, the next kernel I built after telling git the revision starting with '8166301dbfd..' was good, and with about 172 commits left to bisect, failed to boot. It got stuck at 'loading initial ramdisk,' the same problem as I'd been running into during my previous builds. At least by doing it all over again I've confirmed it's nothing about the source I'm using, but I'm in the same position still. Is it actually ok to skip revisions until the kernel I built at least boots? I'm not aware of another method that I can use, but What if one of these commits that causes the build process to produce an unbootable kernel is the bad one, and by skipping it I've made it impossible to identify it as the initial bad commit? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/e74ef256/attachment.html>
dumb BOs and prime
On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann wrote: > On 12/04/2015 11:23 AM, Rob Herring wrote: >> >> On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard >> wrote: >>> >>> Hi Rob, >>> >>> I got the same problem today with sti drm/kms driver and dumb Bo. >>> The issue comes become hwcomposer because is the master and authenticated >>> on >>> /dev/dri/cardX >>> Dumb allocation is done by gralloc which does a new open (so it is not >>> authenticated) on drm node the consequence is that we can't use prime >>> functions... >>> If you use render node you won't be able to call dumb functions. >>> >>> To get out of this I think I will implement additional helpers in gem_cma >>> to >>> have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP >>> and call them instead of dumb so be able to use render node. >>> Of course it is only for drivers which already use gem_cma helpers (like >>> sti) >> >> >> That's only marginally better than per driver BO calls which is the >> whole thing I'm trying to avoid. There should be some way to pass the >> auth token to gralloc? >> >> Rob > > > Frankly, you probably want to approach this by allocating dma-bufs using > something external to DRM (probably ion) and then have your hwcomposer > import them into DRM when they're passed to the display. > > Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc > is designed: like dma-buf, it's built around passing buffers between > different hardware blocks, and some of those buffers may never even touch > the display hardware. You'll also run up against other (deliberate) > limitations of dumb BOs like not being able to allocate YUV buffers. Yes, I realize dumb BO are not the long term nor production solution. ATM, I'm just looking for getting things working on new platforms without the need for lots of userspace changes. Perhaps I could just use fb emulation, but having DRM code paths tested is valuable IMO. > Unfortunately this currently means adding some shim driver code to create > the ion device. (Device-Tree bindings for ion are on my long, long backlog > of things to do.) It's not a lot of code, especially if all you need is a > CMA heap, but it's still non-zero. Laura is working on that. I'm still a bit skeptical about what should go in DT though. > Note that supporting dumb BOs in your KMS driver is still useful, since the > recovery console in AOSP has KMS support now. In that case it's a single > privileged process software-rendering everything, so it bypasses > gralloc/hwcomposer and calls directly into libdrm. I've not seen that. Where does that live? Rob
[PATCH 02/12] drm/etnaviv: add devicetree bindings
On Sat, Dec 5, 2015 at 5:42 AM, Russell King - ARM Linux wrote: > On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote: >> I see where you are going here and I appreciate that this discussion >> isn't a exercise in bikeshed, but based on technical facts. > > It would be nice (for the sake of this discussion not getting heated) > if Rob could show that he's been reading my replies to his questions. > My impression so far is that I'm being ignored. Evidence being Rob's > assertion that his points have not been addressed, where I've replied > with the technical responses - and not one of those has seen any kind > of reply. Sorry, I had missed your reply before I did reply. In any case, I'm satisfied with the reasoning and the virtual node is fine. I do want to see a note in the binding doc about why the compatible string is not specific. Rob
[PATCH v2 05/14] ALSA: pcm: Add DRM helper to set constraint for format
On Fri, Dec 04, 2015 at 06:59:19AM +0100, Takashi Iwai wrote: > On Fri, 04 Dec 2015 12:08:26 +0100, > Subhransu S. Prusty wrote: > > > > On Thu, Dec 03, 2015 at 04:57:14PM +0100, Takashi Iwai wrote: > > > On Thu, 03 Dec 2015 22:08:53 +0100, > > > Subhransu S. Prusty wrote: > > > > > > > > Setting the constraint format based on ELD was missing bit in > > > > the sound/core pcm drm. Added with this patch. > > > > > > No, you can't define these here. The format really depends on the > > > hardware, while the rate and the channels are independent. > > > > Probably then I will move this definition to driver. > > > > > How do you know it's little-endian? And why it must be S24_LE for > > > 24bit, not S32_LE? > > > > Regarding the little-endian, In the driver I think I should set the > > constraint for both LE and BE. And the platform as it only supports LE alone > > it will set the constraint accordingly and edianness will be taken care of. > > > > Regarding the sample size, from short audio descriptor, the samples can be > > one of 16/20/24 bit. I could use the format bits for 16 and 24 bits but > > don't know which format bits macro is suitable for 20bits. So kept it as > > S32_LE for 20bits. Should I fix the format bits for 20bits to use S24? > > No you seem misunderstanding the concept... Sorry about that. I re-read the spec, it doesn't mention the container size for the samples. Assuming the container will be 32 bits, then I think we should use S24_LE for both 20 and 24 bits. Can you please help to understand which concept I got wrong here. Regards, Subhransu > > > Takashi --
[PATCH 15/15] drm: omapdrm: gem: Implement dma_buf import
On Sat, Dec 05, 2015 at 12:27:19AM +0200, Laurent Pinchart wrote:
> OMAP GEM objects backed by dma_buf reuse the current OMAP GEM object
> support as much as possible. If the imported buffer is physically
> contiguous its physical address will be used directly, reusing the
> OMAP_BO_MEM_DMA_API code paths. Otherwise it will be mapped through the
> TILER using a pages list created from the scatterlist instead of the
> shmem backing storage.
>
> Disallow exporting imported buffers for now as those code paths haven't
> been verified. Use cases of such a feature are suspicious anyway.
If you export a buffer that's been imported the drm_prime.c helpers should
dig out the original dma-buf again. You should never end up with a dma-buf
-> omap gem bo -> dma-buf chain.
If that doesn't work then there's a bug somewhere ...
-Daniel
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_drv.h| 2 +
> drivers/gpu/drm/omapdrm/omap_gem.c| 138
> --
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 57 +---
> 3 files changed, 163 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
> b/drivers/gpu/drm/omapdrm/omap_drv.h
> index 97fcb892fdd7..6615b7d51ee3 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -200,6 +200,8 @@ void omap_gem_deinit(struct drm_device *dev);
>
> struct drm_gem_object *omap_gem_new(struct drm_device *dev,
> union omap_gem_size gsize, uint32_t flags);
> +struct drm_gem_object *omap_gem_new_dmabuf(struct drm_device *dev, size_t
> size,
> + struct sg_table *sgt);
> int omap_gem_new_handle(struct drm_device *dev, struct drm_file *file,
> union omap_gem_size gsize, uint32_t flags, uint32_t *handle);
> void omap_gem_free_object(struct drm_gem_object *obj);
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c
> index 11df4f78d8a7..8a54d333a47b 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -33,6 +33,7 @@
> #define OMAP_BO_MEM_DMA_API 0x0100 /* memory allocated with the
> dma_alloc_* API */
> #define OMAP_BO_MEM_SHMEM0x0200 /* memory allocated through
> shmem backing */
> #define OMAP_BO_MEM_EXT 0x0400 /* memory allocated
> externally */
> +#define OMAP_BO_MEM_DMABUF 0x0800 /* memory imported from a
> dmabuf */
> #define OMAP_BO_EXT_SYNC 0x1000 /* externally allocated sync
> object */
>
> struct omap_gem_object {
> @@ -49,17 +50,25 @@ struct omap_gem_object {
> uint32_t roll;
>
> /**
> - * If buffer is allocated physically contiguous, the OMAP_BO_MEM_DMA_API
> - * flag is set and the paddr is valid. Also if the buffer is remapped
> - * in TILER and paddr_cnt > 0, then paddr is valid. But if you are using
> - * the physical address and OMAP_BO_MEM_DMA_API is not set, then you
> - * should be going thru omap_gem_{get,put}_paddr() to ensure the mapping
> - * is not removed from under your feet.
> + * paddr contains the buffer DMA address. It is valid for
>*
> - * Note that OMAP_BO_SCANOUT is a hint from userspace that DMA capable
> - * buffer is requested, but doesn't mean that it is. Use the
> - * OMAP_BO_MEM_DMA_API flag to determine if the buffer has a DMA capable
> - * physical address.
> + * - buffers allocated through the DMA mapping API (with the
> + * OMAP_BO_MEM_DMA_API flag set)
> + *
> + * - buffers imported from dmabuf (with the OMAP_BO_MEM_DMABUF flag set)
> + * if they are physically contiguous (when sgt->orig_nents == 1)
> + *
> + * - buffers mapped through the TILER when paddr_cnt is not zero, in
> + * which case the DMA address points to the TILER aperture
> + *
> + * Physically contiguous buffers have their DMA address equal to the
> + * physical address as we don't remap those buffers through the TILER.
> + *
> + * Buffers mapped to the TILER have their DMA address pointing to the
> + * TILER aperture. As TILER mappings are refcounted (through paddr_cnt)
> + * the DMA address must be accessed through omap_get_get_paddr() to
> + * ensure that the mapping won't disappear unexpectedly. References must
> + * be released with omap_gem_put_paddr().
>*/
> dma_addr_t paddr;
>
> @@ -69,6 +78,12 @@ struct omap_gem_object {
> uint32_t paddr_cnt;
>
> /**
> + * If the buffer has been imported from a dmabuf the OMAP_DB_DMABUF flag
> + * is set and the sgt field is valid.
> + */
> + struct sg_table *sgt;
> +
> + /**
>* tiler block used when buffer is remapped in DMM/TILER.
>*/
> struct tiler_block *block;
> @@ -166,6 +181,17 @@ static uint64_t mmap_offset(struct drm_gem_object *obj)
> return drm_vma
[PATCH 02/12] drm/etnaviv: add devicetree bindings
On Sat, Dec 05, 2015 at 11:02:09AM +, Russell King - ARM Linux wrote: > On Sat, Dec 05, 2015 at 11:12:08AM +0100, Daniel Vetter wrote: > > Given that I think the current etnaviv is a sound architecture. And I'm > > not saying that because drm requires everything to be smashed into one > > driver, since that's simple not the case. > > There's other reasons as well, mostly from the performance point of view. > Having separate DRM devices for each GPU means you need to use dmabuf to > share buffers across the GPUs. This brings with it several kinds of > overhead: > > 1. having more fd usage in the client programs. > 2. having more memory usage as a result. > 3. having more locks, due to more object lists. > 4. having the overhead from the DMA API when importing buffers between >different GPU nodes. > > From my performance measurements over the last month, the top hit is > currently from the DMA API, so having to export and import buffers > between different GPU devices is just going to make that worse. Yeah dma-api for shared buffers is currently not up to the challenge, we had the same problem with the intel driver. Big one is that gpus tend to do cache management themselves, or at least all need cpu caches to be flushed. But if you have multiple drivers using the same memory nothing currently keeps track of whether caches are flushed already or not, so you end up with double or worse flushing of your buffers. Which totally kills performance. In theory dma-buf could keep track of who's flushed a buffer already, but there's no implementation of that yet. And for a generic one we'd need to violate the current dma api abstractions. So yeah, perf is going to tank until that's solved, at least for some workloads. Video wasn't a problem here since all you do is establish a set of shared buffers once, making all the overhead just one-time. But dynamic workloads like GL can't amortize setup cost that easily. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver
2015-12-04 15:00 GMT+01:00 Lucas Stach : > Signed-off-by: Lucas Stach Acked-by: Christian Gmeiner greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner
[PATCH 02/12] drm/etnaviv: add devicetree bindings
On Sat, Dec 05, 2015 at 04:35:11PM +0100, Daniel Vetter wrote: > In theory dma-buf could keep track of who's flushed a buffer already, but > there's no implementation of that yet. And for a generic one we'd need to > violate the current dma api abstractions. So yeah, perf is going to tank > until that's solved, at least for some workloads. Video wasn't a problem > here since all you do is establish a set of shared buffers once, making > all the overhead just one-time. But dynamic workloads like GL can't > amortize setup cost that easily. Indeed, and as the Vivante 3D core is not as capable as the 2D core at blitting between two pixmaps, the cost of splitting them would be high. (The early 3D cores such as found in Dove seem only able to bit from the 0,0 origin.) So, we really need to do the 3D rendering on the 3D core, and then use the 2D core as a blitter - preferably with the 3D core rendering the next frame in parallel with the blit. There's more reasons to do this when you discover that iMX6's memory bus arbiter doesn't work quite right: it appears that each bus master has a certain bandwidth reserved which is never given to any other master. That means it's best to spread the memory workload over as many of the masters as possible. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
dumb BOs and prime
On Sat, Dec 5, 2015 at 3:40 PM, Rob Herring wrote: > On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann wrote: >> On 12/04/2015 11:23 AM, Rob Herring wrote: >>> >>> On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard >>> wrote: Hi Rob, I got the same problem today with sti drm/kms driver and dumb Bo. The issue comes become hwcomposer because is the master and authenticated on /dev/dri/cardX Dumb allocation is done by gralloc which does a new open (so it is not authenticated) on drm node the consequence is that we can't use prime functions... If you use render node you won't be able to call dumb functions. To get out of this I think I will implement additional helpers in gem_cma to have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP and call them instead of dumb so be able to use render node. Of course it is only for drivers which already use gem_cma helpers (like sti) >>> >>> >>> That's only marginally better than per driver BO calls which is the >>> whole thing I'm trying to avoid. There should be some way to pass the >>> auth token to gralloc? >>> >>> Rob >> >> >> Frankly, you probably want to approach this by allocating dma-bufs using >> something external to DRM (probably ion) and then have your hwcomposer >> import them into DRM when they're passed to the display. >> >> Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc >> is designed: like dma-buf, it's built around passing buffers between >> different hardware blocks, and some of those buffers may never even touch >> the display hardware. You'll also run up against other (deliberate) >> limitations of dumb BOs like not being able to allocate YUV buffers. > > Yes, I realize dumb BO are not the long term nor production solution. > ATM, I'm just looking for getting things working on new platforms > without the need for lots of userspace changes. Perhaps I could just > use fb emulation, but having DRM code paths tested is valuable IMO. > >> Unfortunately this currently means adding some shim driver code to create >> the ion device. (Device-Tree bindings for ion are on my long, long backlog >> of things to do.) It's not a lot of code, especially if all you need is a >> CMA heap, but it's still non-zero. > > Laura is working on that. I'm still a bit skeptical about what should > go in DT though. > >> Note that supporting dumb BOs in your KMS driver is still useful, since the >> recovery console in AOSP has KMS support now. In that case it's a single >> privileged process software-rendering everything, so it bypasses >> gralloc/hwcomposer and calls directly into libdrm. > > I've not seen that. Where does that live? https://android.googlesource.com/platform/bootable/recovery/+/1a92c4458dcc983f624a60fb75f9679c213e6814 Stéphane > > Rob > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/12] drm/etnaviv: add devicetree bindings
Am Freitag, den 04.12.2015, 14:19 -0600 schrieb Rob Herring:
> On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach
> wrote:
> > Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
> > > On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach > > .de> wrote:
> > > > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> > > > > On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > > > > > Etnaviv follows the same priciple as imx-drm to have a
> > > > > > virtual
> > > > > > master device node to bind all the individual GPU cores
> > > > > > together
> > > > > > into one DRM device.
> > > > > >
> > > > > > Signed-off-by: Lucas Stach
> > > > > > ---
> > > > > >  .../bindings/display/etnaviv/etnaviv-drm.txt       | 46
> > > > > > ++
> > > > > > Â 1 file changed, 46 insertions(+)
> > > > > > Â create mode 100644
> > > > > > Documentation/devicetree/bindings/display/etnaviv/etnaviv-
> > > > > > drm.txt
> > > > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv
> > > > > > -drm.txt
> > > > > > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv
> > > > > > -drm.txt
> > > > > > new file mode 100644
> > > > > > index ..19fde29dc1d7
> > > > > > --- /dev/null
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv
> > > > > > -drm.txt
> > > > > > @@ -0,0 +1,46 @@
> > > > > > +Etnaviv DRM master device
> > > > > > +
> > > > > > +
> > > > > > +The Etnaviv DRM master device is a virtual device needed
> > > > > > to list all
> > > > > > +Vivante GPU cores that comprise the GPU subsystem.
> > > > > > +
> > > > > > +Required properties:
> > > > > > +- compatible: Should be one of
> > > > > > +Â Â Â Â "fsl,imx-gpu-subsystem"
> > > > > > +Â Â Â Â "marvell,dove-gpu-subsystem"
> > > > > > +- cores: Should contain a list of phandles pointing to
> > > > > > Vivante GPU devices
> > > > > > +
> > > > > > +example:
> > > > > > +
> > > > > > +gpu-subsystem {
> > > > > > +Â Â Â compatible = "fsl,imx-gpu-subsystem";
> > > > > > +Â Â Â cores = <&gpu_2d>, <&gpu_3d>;
> > > > > > +};
> > > > >
> > > > > Yeah, I'm not really a fan of doing this simply because DRM
> > > > > wants 1
> > > > > driver.
> > > > >
> > > > I'm aware of that, but I don't see much value in kicking this
> > > > discussion
> > > > around for every DRM driver submission. This is the binding
> > > > that has
> > > > emerged from a lengthy discussion at KS 2013 in Edinburgh and
> > > > at least
> > > > allows us to standardize on _something_. Also ALSA does a
> > > > similar thing
> > > > to bind codecs and CPU interfaces together.
> > >
> > > This case is quite different though I think. The ALSA case and
> > > other
> > > DRM cases are ones that have inter-dependencies between the
> > > blocks
> > > (e.g. some sort of h/w connection). What is the inter-dependency
> > > here?
> > >
> > > Doing this way has also been found to be completely unnecessary
> > > and
> > > removed in recent DRM driver reviews. Admittedly, those are cases
> > > where one device can be the master of the others. For 2 parallel
> > > devices, I don't have an alternative other than question why they
> > > need
> > > to be a single driver.
> > >
> > If you insist on doing things differently for this driver, we could
> > add
> > a pass at driver registration that scans through the DT, looking
> > for
> > nodes matching the GPU core compatible.
>
> I've not insisted on anything. I'm only asking a question which
> didn't
> get answered. I'll ask another way. Why can't you have 2 instances of
> the same driver given they are only rendering nodes?
>
> > I'm not sure if that makes things cleaner though and might bite us
> > later
> > on. Also I'm not sure if moving away from the binding scheme
> > already
> > established for other DRM drivers makes things better from a DT
> > perspective. Personally I would prefer DT binding consistency over
> > perfection for single drivers, segmenting the DT binding space.
>
> This is the least of our issues in terms of consistency among
> drivers,
> but that is in fact what I'm pushing for. This is probably the first
> case of a render only driver (at least for DT). So this isn't a case
> of just follow what others are doing.
>
> The h/w in this area can be quite different, so the DT bindings are
> going to reflect that to some extent. A virtual node makes sense in
> some cases, but for others it may not.
>
I see where you are going here and I appreciate that this discussion
isn't a exercise in bikeshed, but based on technical facts.
So let me try to explain things from the other way around:
We made the decision to have a single DRM device for all the Vivante
GPU nodes in a system based on technical merits, not because DRM wants
us to do this, but because it has practical upsides for the
implementation of the driver.
1. It makes buffer and management and information sharing between the
[PATCH 02/12] drm/etnaviv: add devicetree bindings
On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote: > I already sketched up the alternative of having the master driver scan > the DT for matching GPU nodes at probe time and binding them together > into a single device. But given that we end up with one master device > anyways, do you really prefer this over the virtual node, which is a > working and proven solution to this exact problem? I really don't think that would be a sane approach for several reasons: 1. We end up with a load of platform devices which are just dangling. 2. We lose the ability to runtime PM manage each GPU core separately, along with the PM domain infrastructure to manage the separate GPU power domains, as we wouldn't be able to bind to the individual struct devices. 3. We still need some kind of master struct device to trigger the registration of devices, and to act as the struct device for DRM and DMA allocations. I can't see any advantages to such an approach, only downsides. Hence, I'd say that such an approach is completely unsuitable - especially as the 3D GPUs consume much more power than their 2D counterparts, so it's very advantageous to have the individual GPU core power management that the current structure elegantly gives us. To do the above, we'd probably have to re-implement our own private per-GPU runtime PM infrastructure, and somehow couple that into the PM domains stuff - or even bring the SoC specific PM domain manipulation into the GPU driver. The only way I can see around that would be to keep the existing driver structure, but have a non-driver shim which scans the DT and is responsible for creating the platform devices - duplicating in effect what the platform device code in drivers/of is already doing but specifically for this driver. It'd also be responsible for creating the master device as well. In other words, it would be a half-way between DT and non-DT solutions: DT would be dealt with in the shim layer and the etnaviv driver itself would effectively know nothing about DT. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH 02/12] drm/etnaviv: add devicetree bindings
On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote: > I see where you are going here and I appreciate that this discussion > isn't a exercise in bikeshed, but based on technical facts. It would be nice (for the sake of this discussion not getting heated) if Rob could show that he's been reading my replies to his questions. My impression so far is that I'm being ignored. Evidence being Rob's assertion that his points have not been addressed, where I've replied with the technical responses - and not one of those has seen any kind of reply. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH 1/3] radeon/cik: Fix GFX IB test on Big-Endian
Patch #1 & #2 are Reviewed-by: Christian König For patch #3: Couldn't we just in a loop go over all the dw in the IB and swap them after writing them? That would simplify the patch massively. And line like the one below just look a bit odd to me: > for (i = ib.length_dw; i < ib_size_dw; ++i) > - ib.ptr[i] = 0x0; > + ib.ptr[i] = cpu_to_le32(0x0); Alternatively a helper function adding DW to an IB with swapping could do it as well. Regards, Christian. On 04.12.2015 22:09, Oded Gabbay wrote: > This patch makes the IB test on the GFX ring pass for CI-based cards > installed in Big-Endian machines. > > Signed-off-by: Oded Gabbay > Cc: stable at vger.kernel.org > --- > drivers/gpu/drm/radeon/cik.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c > index 248953d..05d43a0 100644 > --- a/drivers/gpu/drm/radeon/cik.c > +++ b/drivers/gpu/drm/radeon/cik.c > @@ -4173,11 +4173,7 @@ void cik_ring_ib_execute(struct radeon_device *rdev, > struct radeon_ib *ib) > control |= ib->length_dw | (vm_id << 24); > > radeon_ring_write(ring, header); > - radeon_ring_write(ring, > -#ifdef __BIG_ENDIAN > - (2 << 0) | > -#endif > - (ib->gpu_addr & 0xFFFC)); > + radeon_ring_write(ring, (ib->gpu_addr & 0xFFFC)); > radeon_ring_write(ring, upper_32_bits(ib->gpu_addr) & 0x); > radeon_ring_write(ring, control); > }
dumb BOs and prime
On Fri, Dec 04, 2015 at 03:48:26PM -0800, Greg Hackmann wrote: > On 12/04/2015 11:23 AM, Rob Herring wrote: > >On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard > > wrote: > >>Hi Rob, > >> > >>I got the same problem today with sti drm/kms driver and dumb Bo. > >>The issue comes become hwcomposer because is the master and authenticated on > >>/dev/dri/cardX > >>Dumb allocation is done by gralloc which does a new open (so it is not > >>authenticated) on drm node the consequence is that we can't use prime > >>functions... > >>If you use render node you won't be able to call dumb functions. > >> > >>To get out of this I think I will implement additional helpers in gem_cma to > >>have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP > >>and call them instead of dumb so be able to use render node. > >>Of course it is only for drivers which already use gem_cma helpers (like > >>sti) > > > >That's only marginally better than per driver BO calls which is the > >whole thing I'm trying to avoid. There should be some way to pass the > >auth token to gralloc? > > > >Rob > > Frankly, you probably want to approach this by allocating dma-bufs using > something external to DRM (probably ion) and then have your hwcomposer > import them into DRM when they're passed to the display. > > Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc > is designed: like dma-buf, it's built around passing buffers between > different hardware blocks, and some of those buffers may never even touch > the display hardware. You'll also run up against other (deliberate) > limitations of dumb BOs like not being able to allocate YUV buffers. > > Unfortunately this currently means adding some shim driver code to create > the ion device. (Device-Tree bindings for ion are on my long, long backlog > of things to do.) It's not a lot of code, especially if all you need is a > CMA heap, but it's still non-zero. Yeah at plumbers in seattle we discussed this and pretty much all agreed that for these kind of embedded cases ION makes tons of sense as the backing allocator. Trying to use dumb buffers for everything really isn't how it's meant to be, and it shows in all the hacks added and hoops you still need to jump through. As Greg says there's some polish left to do for really neat ION integration, but we captured that in drivers/staging/android/TODO. > Note that supporting dumb BOs in your KMS driver is still useful, since the > recovery console in AOSP has KMS support now. In that case it's a single > privileged process software-rendering everything, so it bypasses > gralloc/hwcomposer and calls directly into libdrm. Yeah, dumb buffers is for emergency consoles and for boot splash (where loading GL is either not yet possible or too expensive). Anything else will result in sizeable amounts of hurt. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 02/12] drm/etnaviv: add devicetree bindings
On Fri, Dec 04, 2015 at 05:43:33PM -0500, Ilia Mirkin wrote: > On Fri, Dec 4, 2015 at 5:05 PM, Russell King - ARM Linux > wrote: > > On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote: > >> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux > >> wrote: > >> > Moreover, DRI3 is not yet available for Gallium, so if we're talking > >> > about Xorg, then functional DRI2 is a requirement, and that _needs_ > >> > to have a single device for the rendering instances. Xorg has no way > >> > to pass multiple render nodes to client over DRI2. > >> > >> Just to correct... DRI3 has been available on gallium [at least in the > >> context of st/mesa] basically since DRI3 was introduced. Not sure what > >> issue you're fighting with, but it's definitely not a gallium > >> limitation... could be something related to platform devices. > > > > Well, my statement is based on the fact that there's nothing in > > src/gallium/state-tracker/dri which hints at being DRI3. Maybe it's > > implemented differently, I don't know. I never wanted to hack MESA - > > I'm supposed to be the ARM kernel maintainer - and I'm still very new > > to MESA. > > > > I think it's a DRI3 limitation. The issue with the DRI3 design is that: > > > > * The client has access to the GPU render nodes only, but not the > > corresponding KMS node. > > * Buffers in DRI3 are allocated from the GPU render nodes. > > * The Xorg Present protocol is then used to manage the vblank > > synchonisation and page flips. > > > > Now, the KMS scanout hardware typically does not support any kind of > > scatter-gather: the buffers it has must be contiguous. These can be > > allocated from the KMS DRM device. > > > > However, the DRI3 client has no access to the KMS DRM device to allocate > > linear buffers from, and GPUs typically don't have dumb buffer support. > > Hence, the client can't pass a suitable buffer to the present layer. Oh right, buffer alloc if you have special constraints won't work with DRI3 as-is. For that we probably need something like DRI2 for buffer alloc + Present (like DRI3 does) for flipping them. > > Hence, I can see no way for the resource_create() to be able to allocate > > any kind of scanout capable buffer. > > > > That's a separate issue though: you've pointed out that you can select > > which render node to use: what if we want to use multiple render nodes > > simultaneously - eg, because we want to use multiple 3D GPU cores > > together? How does that work with stuff? > > This is a bit like the SLI question -- let's say you have 2 pricey > desktop GPUs, with a fast interconnect between them, which lets them > know about each other, how do you make use of that. Solution: unsolved > :) > > In an ideal world, you'd have a single driver that knows how to > interact with multiple devices and make them do cool things. However > this a completely untrodden path. (Not to mention the problem of *how* > to break up a workload across 2 GPUs.) > > > > > I think the idea that individual GPU cores should be exposed as > > separate DRM devices is fundamentally flawed, and adds a hell of a > > lot of complexity. > > > > In any case, I've spent _way_ too much time on etnaviv during November - > > quite literally almost every day (I worked out that I was producing 4.5 > > patches a day during November for Etnaviv MESA.) I'm afraid that it's > > now time that I switch my attention elsewhere, so if this means that > > Etnaviv is rejected for merging, I'm afraid it'll be a few months before > > I can get back to it. > > > > It would have been nice if these issues had been brought up much earlier, > > during the RFC posting of the patches. These are nothing new, and I now > > feel that this whole thing has been a total waste of time. > > The whole multi-gpu thing is a bit of an open question right now. It > works in theory, but in practice nobody's done it. Maarten tried to > get nouveau/gk20a + tegra/drm on Jetson TK1 to play nice with, e.g., X > 2d accel, and it was an exercise in pain. Not sure that he ever > succeeded. > > I think it's unfair to try to make new hardware enablement the time to > attempt to heap extra work onto those authors unfortunate enough to > have slightly unorthodox hardware that maps nicely onto some > desired-but-not-quite-there-yet usage model -- they have enough > problems. > > The way everything works is one drm node can do everything. PRIME is a > barely-functional way to offload some things onto a (single) secondary > GPU. Everything beyond that is purely theoretical. One thing that doesn't yet work with PRIME is synchronization. But at list for the render->display combo Alex Goins from nvidia fixed it up, and it's pretty much trivial to do so (2 patches on i915 since we needed to support both atomic and legacy page_flip, would have been just 1 tiny patch otherwise). i915->nvidia would have been more work because of some locking fun, but the infrastructure is now all there (including patches for
[PATCH 02/12] drm/etnaviv: add devicetree bindings
On Sat, Dec 05, 2015 at 11:12:08AM +0100, Daniel Vetter wrote: > Given that I think the current etnaviv is a sound architecture. And I'm > not saying that because drm requires everything to be smashed into one > driver, since that's simple not the case. There's other reasons as well, mostly from the performance point of view. Having separate DRM devices for each GPU means you need to use dmabuf to share buffers across the GPUs. This brings with it several kinds of overhead: 1. having more fd usage in the client programs. 2. having more memory usage as a result. 3. having more locks, due to more object lists. 4. having the overhead from the DMA API when importing buffers between different GPU nodes. >From my performance measurements over the last month, the top hit is currently from the DMA API, so having to export and import buffers between different GPU devices is just going to make that worse. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH] drm: do not use device name as a format string
Hello, I sent the path below a few weeks ago and did not have any feedback. Is there any issue in it that I need to fix before submitting it again? Thanks, Nicolas Iooss On 11/18/2015 06:58 PM, Nicolas Iooss wrote: > drm_dev_set_unique() formats its parameter using kvasprintf() but many > of its callers directly pass dev_name(dev) as printf format string, > without any format parameter. This can cause some issues when the > device name contains '%' characters. > > To avoid any potential issue, always use "%s" when using > drm_dev_set_unique() with dev_name(). > > Signed-off-by: Nicolas Iooss > --- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 2 +- > drivers/gpu/drm/tegra/drm.c | 2 +- > drivers/gpu/drm/vc4/vc4_drv.c| 2 +- > include/drm/drmP.h | 1 + > 5 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > index 244df0a440b7..0d720d3a7ee0 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > @@ -733,7 +733,7 @@ static int atmel_hlcdc_dc_drm_probe(struct > platform_device *pdev) > if (!ddev) > return -ENOMEM; > > - ret = drm_dev_set_unique(ddev, dev_name(ddev->dev)); > + ret = drm_dev_set_unique(ddev, "%s", dev_name(ddev->dev)); > if (ret) > goto err_unref; > > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > index 1930234ba5f1..947d75f59881 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > @@ -363,7 +363,7 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev) > fsl_dev->np = dev->of_node; > drm->dev_private = fsl_dev; > dev_set_drvdata(dev, fsl_dev); > - drm_dev_set_unique(drm, dev_name(dev)); > + drm_dev_set_unique(drm, "%s", dev_name(dev)); > > ret = drm_dev_register(drm, 0); > if (ret < 0) > diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c > index 159ef515cab1..b278f60f4376 100644 > --- a/drivers/gpu/drm/tegra/drm.c > +++ b/drivers/gpu/drm/tegra/drm.c > @@ -991,7 +991,7 @@ static int host1x_drm_probe(struct host1x_device *dev) > if (!drm) > return -ENOMEM; > > - drm_dev_set_unique(drm, dev_name(&dev->dev)); > + drm_dev_set_unique(drm, "%s", dev_name(&dev->dev)); > dev_set_drvdata(&dev->dev, drm); > > err = drm_dev_register(drm, 0); > diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c > index 6e730605edcc..c90a451aaa79 100644 > --- a/drivers/gpu/drm/vc4/vc4_drv.c > +++ b/drivers/gpu/drm/vc4/vc4_drv.c > @@ -168,7 +168,7 @@ static int vc4_drm_bind(struct device *dev) > vc4->dev = drm; > drm->dev_private = vc4; > > - drm_dev_set_unique(drm, dev_name(dev)); > + drm_dev_set_unique(drm, "%s", dev_name(dev)); > > drm_mode_config_init(drm); > if (ret) > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > index 0b921ae06cd8..995fb96cb740 100644 > --- a/include/drm/drmP.h > +++ b/include/drm/drmP.h > @@ -1049,6 +1049,7 @@ void drm_dev_ref(struct drm_device *dev); > void drm_dev_unref(struct drm_device *dev); > int drm_dev_register(struct drm_device *dev, unsigned long flags); > void drm_dev_unregister(struct drm_device *dev); > +__printf(2, 3) > int drm_dev_set_unique(struct drm_device *dev, const char *fmt, ...); > > struct drm_minor *drm_minor_acquire(unsigned int minor_id); >
[PATCH v2 05/14] ALSA: pcm: Add DRM helper to set constraint for format
On Sat, 05 Dec 2015 15:05:49 +0100, Subhransu S. Prusty wrote: > > On Sat, Dec 05, 2015 at 09:12:34AM +0100, Takashi Iwai wrote: > > On Sat, 05 Dec 2015 12:27:03 +0100, > > Subhransu S. Prusty wrote: > > > > > > On Fri, Dec 04, 2015 at 06:59:19AM +0100, Takashi Iwai wrote: > > > > On Fri, 04 Dec 2015 12:08:26 +0100, > > > > Subhransu S. Prusty wrote: > > > > > > > > > > On Thu, Dec 03, 2015 at 04:57:14PM +0100, Takashi Iwai wrote: > > > > > > On Thu, 03 Dec 2015 22:08:53 +0100, > > > > > > Subhransu S. Prusty wrote: > > > > > > > > > > > > > > Setting the constraint format based on ELD was missing bit in > > > > > > > the sound/core pcm drm. Added with this patch. > > > > > > > > > > > > No, you can't define these here. The format really depends on the > > > > > > hardware, while the rate and the channels are independent. > > > > > > > > > > Probably then I will move this definition to driver. > > > > > > > > > > > How do you know it's little-endian? And why it must be S24_LE for > > > > > > 24bit, not S32_LE? > > > > > > > > > > Regarding the little-endian, In the driver I think I should set the > > > > > constraint for both LE and BE. And the platform as it only supports > > > > > LE alone > > > > > it will set the constraint accordingly and edianness will be taken > > > > > care of. > > > > > > > > > > Regarding the sample size, from short audio descriptor, the samples > > > > > can be > > > > > one of 16/20/24 bit. I could use the format bits for 16 and 24 bits > > > > > but > > > > > don't know which format bits macro is suitable for 20bits. So kept it > > > > > as > > > > > S32_LE for 20bits. Should I fix the format bits for 20bits to use S24? > > > > > > > > No you seem misunderstanding the concept... > > > > > > Sorry about that. > > > > > > I re-read the spec, it doesn't mention the container size for the samples. > > > Assuming the container will be 32 bits, then I think we should use S24_LE > > > for both 20 and 24 bits. > > > > You can't limit easily from the supported bits. In theory, all > > formats that may fit with the given bit should be set. For example, > > for a 20bit sample, S24, U24, S32, U32, S24_3, U24_3, S20_3, etc would > > match, and even for both endianess. > > > > The format type doesn't specify only the *max* bit it can pack, but > > also only the position of bits to be packed. For example, S24 packs > > max 24 bits in the lower 24 bits in a 32bit container. And, S24_3 > > packs max 24 bits in a 24bit container. Most of Intel chips takes the > > upper bits in a container, so usually they need S32 or S16 no matter > > how many bits are used. > > Thanks for the quick reply. > > I am thinking to set the format as S16 for 16bits and S32 for 20/24bits. > > But then we can set S32 for everything as well including 16bits. > > What do you recommend? In general it's better to use S16 for 16bits. The problem is that you tried to put in the generic code where you can't know the exact condition in the controller side. Actually the legacy HDA driver sets the formats constraint, too, but it at least knows that the HDA controller may support only S16_LE and S32_LE. That said, rather implement it locally instead of pcm_drm_eld.c. Takashi
[PATCH v2 03/10] drm/hisilicon: Add hisilicon DRM master driver
On 4 December 2015 at 00:21, Rob Herring wrote:
> On Sat, Nov 28, 2015 at 4:38 AM, Xinliang Liu
> wrote:
>> Add DRM master driver for hi6220 SoC which used in HiKey board.
>> Add dumb buffer feature.
>> Add prime dmabuf feature.
>>
>> Signed-off-by: Xinliang Liu
>> Signed-off-by: Xinwei Kong
>> Signed-off-by: Andy Green
>> ---
>
>> +static int hisi_gem_cma_dumb_create(struct drm_file *file,
>> + struct drm_device *dev,
>> + struct drm_mode_create_dumb *args)
>> +{
>> + int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>
> BTW, is args->bpp supposed to be bits or bytes? I'm using your dumb bo
> support in drm_gralloc which does bytes as that is what
> gralloc_drm_get_bpp returns. The virtio-gpu driver does bits. I'm
> guessing bits is correct.
yes, it is bits. And pitch is bytes.
>
> Rob
[PATCH v2 05/14] ALSA: pcm: Add DRM helper to set constraint for format
On Sat, 05 Dec 2015 12:27:03 +0100, Subhransu S. Prusty wrote: > > On Fri, Dec 04, 2015 at 06:59:19AM +0100, Takashi Iwai wrote: > > On Fri, 04 Dec 2015 12:08:26 +0100, > > Subhransu S. Prusty wrote: > > > > > > On Thu, Dec 03, 2015 at 04:57:14PM +0100, Takashi Iwai wrote: > > > > On Thu, 03 Dec 2015 22:08:53 +0100, > > > > Subhransu S. Prusty wrote: > > > > > > > > > > Setting the constraint format based on ELD was missing bit in > > > > > the sound/core pcm drm. Added with this patch. > > > > > > > > No, you can't define these here. The format really depends on the > > > > hardware, while the rate and the channels are independent. > > > > > > Probably then I will move this definition to driver. > > > > > > > How do you know it's little-endian? And why it must be S24_LE for > > > > 24bit, not S32_LE? > > > > > > Regarding the little-endian, In the driver I think I should set the > > > constraint for both LE and BE. And the platform as it only supports LE > > > alone > > > it will set the constraint accordingly and edianness will be taken care > > > of. > > > > > > Regarding the sample size, from short audio descriptor, the samples can be > > > one of 16/20/24 bit. I could use the format bits for 16 and 24 bits but > > > don't know which format bits macro is suitable for 20bits. So kept it as > > > S32_LE for 20bits. Should I fix the format bits for 20bits to use S24? > > > > No you seem misunderstanding the concept... > > Sorry about that. > > I re-read the spec, it doesn't mention the container size for the samples. > Assuming the container will be 32 bits, then I think we should use S24_LE > for both 20 and 24 bits. You can't limit easily from the supported bits. In theory, all formats that may fit with the given bit should be set. For example, for a 20bit sample, S24, U24, S32, U32, S24_3, U24_3, S20_3, etc would match, and even for both endianess. The format type doesn't specify only the *max* bit it can pack, but also only the position of bits to be packed. For example, S24 packs max 24 bits in the lower 24 bits in a 32bit container. And, S24_3 packs max 24 bits in a 24bit container. Most of Intel chips takes the upper bits in a container, so usually they need S32 or S16 no matter how many bits are used. Takashi
[Bug 92974] Fiji Nano long boot up and long X startup with amdgpu-powerplay enabled
https://bugs.freedesktop.org/show_bug.cgi?id=92974 --- Comment #8 from charlie --- Created attachment 120363 --> https://bugs.freedesktop.org/attachment.cgi?id=120363&action=edit Kernel config Dec. 4, 2015 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/0cb2f705/attachment.html>
[Bug 92974] Fiji Nano long boot up and long X startup with amdgpu-powerplay enabled
https://bugs.freedesktop.org/show_bug.cgi?id=92974 --- Comment #7 from charlie --- I recently compiled this kernel version: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=amdgpu-powerplay&id=ab72939ad61cc7c22b03946cac94153a1fa23e43 There was no change in the bug. I'll submit my kernel ".config" as well. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/de4bc5f4/attachment.html>
[Bug 92974] Fiji Nano long boot up and long X startup with amdgpu-powerplay enabled
https://bugs.freedesktop.org/show_bug.cgi?id=92974 --- Comment #6 from charlie --- Created attachment 120362 --> https://bugs.freedesktop.org/attachment.cgi?id=120362&action=edit dmesg Friday Dec. 4, 2015 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/7e87ff02/attachment.html>
[Bug 93217] [tonga] [powerplay] Radon M395X isn't initialised with the powerplay branch
https://bugs.freedesktop.org/show_bug.cgi?id=93217 --- Comment #4 from Mike Lothian --- I'd just like to add that booting with amdgpu.powerplay=0 allow the card to be initialized -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/971a548e/attachment-0001.html>
[Bug 93147] [regression bisected] Stuttering in games caused by commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed"
https://bugs.freedesktop.org/show_bug.cgi?id=93147 --- Comment #19 from Ernst Sjöstrand --- Tested the amdgpu v3 patch on top of agd5f/amdgpu-powerplay, seems to work fine. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151205/0caafa2d/attachment.html>
[PATCH 15/15] drm: omapdrm: gem: Implement dma_buf import
OMAP GEM objects backed by dma_buf reuse the current OMAP GEM object
support as much as possible. If the imported buffer is physically
contiguous its physical address will be used directly, reusing the
OMAP_BO_MEM_DMA_API code paths. Otherwise it will be mapped through the
TILER using a pages list created from the scatterlist instead of the
shmem backing storage.
Disallow exporting imported buffers for now as those code paths haven't
been verified. Use cases of such a feature are suspicious anyway.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h| 2 +
drivers/gpu/drm/omapdrm/omap_gem.c| 138 --
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 57 +---
3 files changed, 163 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 97fcb892fdd7..6615b7d51ee3 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -200,6 +200,8 @@ void omap_gem_deinit(struct drm_device *dev);
struct drm_gem_object *omap_gem_new(struct drm_device *dev,
union omap_gem_size gsize, uint32_t flags);
+struct drm_gem_object *omap_gem_new_dmabuf(struct drm_device *dev, size_t size,
+ struct sg_table *sgt);
int omap_gem_new_handle(struct drm_device *dev, struct drm_file *file,
union omap_gem_size gsize, uint32_t flags, uint32_t *handle);
void omap_gem_free_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 11df4f78d8a7..8a54d333a47b 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -33,6 +33,7 @@
#define OMAP_BO_MEM_DMA_API0x0100 /* memory allocated with the
dma_alloc_* API */
#define OMAP_BO_MEM_SHMEM 0x0200 /* memory allocated through
shmem backing */
#define OMAP_BO_MEM_EXT0x0400 /* memory allocated
externally */
+#define OMAP_BO_MEM_DMABUF 0x0800 /* memory imported from a
dmabuf */
#define OMAP_BO_EXT_SYNC 0x1000 /* externally allocated sync
object */
struct omap_gem_object {
@@ -49,17 +50,25 @@ struct omap_gem_object {
uint32_t roll;
/**
-* If buffer is allocated physically contiguous, the OMAP_BO_MEM_DMA_API
-* flag is set and the paddr is valid. Also if the buffer is remapped
-* in TILER and paddr_cnt > 0, then paddr is valid. But if you are using
-* the physical address and OMAP_BO_MEM_DMA_API is not set, then you
-* should be going thru omap_gem_{get,put}_paddr() to ensure the mapping
-* is not removed from under your feet.
+* paddr contains the buffer DMA address. It is valid for
*
-* Note that OMAP_BO_SCANOUT is a hint from userspace that DMA capable
-* buffer is requested, but doesn't mean that it is. Use the
-* OMAP_BO_MEM_DMA_API flag to determine if the buffer has a DMA capable
-* physical address.
+* - buffers allocated through the DMA mapping API (with the
+* OMAP_BO_MEM_DMA_API flag set)
+*
+* - buffers imported from dmabuf (with the OMAP_BO_MEM_DMABUF flag set)
+* if they are physically contiguous (when sgt->orig_nents == 1)
+*
+* - buffers mapped through the TILER when paddr_cnt is not zero, in
+* which case the DMA address points to the TILER aperture
+*
+* Physically contiguous buffers have their DMA address equal to the
+* physical address as we don't remap those buffers through the TILER.
+*
+* Buffers mapped to the TILER have their DMA address pointing to the
+* TILER aperture. As TILER mappings are refcounted (through paddr_cnt)
+* the DMA address must be accessed through omap_get_get_paddr() to
+* ensure that the mapping won't disappear unexpectedly. References must
+* be released with omap_gem_put_paddr().
*/
dma_addr_t paddr;
@@ -69,6 +78,12 @@ struct omap_gem_object {
uint32_t paddr_cnt;
/**
+* If the buffer has been imported from a dmabuf the OMAP_DB_DMABUF flag
+* is set and the sgt field is valid.
+*/
+ struct sg_table *sgt;
+
+ /**
* tiler block used when buffer is remapped in DMM/TILER.
*/
struct tiler_block *block;
@@ -166,6 +181,17 @@ static uint64_t mmap_offset(struct drm_gem_object *obj)
return drm_vma_node_offset_addr(&obj->vma_node);
}
+static bool is_contiguous(struct omap_gem_object *omap_obj)
+{
+ if (omap_obj->flags & OMAP_BO_MEM_DMA_API)
+ return true;
+
+ if ((omap_obj->flags & OMAP_BO_MEM_DMABUF) && omap_obj->sgt->nents == 1)
+ return true;
+
+ return false;
+}
+
/*
-
* Evictio
[PATCH 14/15] drm: omapdrm: gem: Refactor GEM object allocation
Split the individual steps of GEM object allocation and initialization
clearly. This improves readability and prepares for dma_buf import
support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 75 ++
1 file changed, 43 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index a95b6486fbf6..11df4f78d8a7 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1345,67 +1345,80 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
size_t size;
int ret;
+ /* Validate the flags and compute the memory and cache flags. */
if (flags & OMAP_BO_TILED) {
if (!priv->usergart) {
dev_err(dev->dev, "Tiled buffers require DMM\n");
return NULL;
}
- /* tiled buffers are always shmem paged backed.. when they are
-* scanned out, they are remapped into DMM/TILER
+ /*
+* Tiled buffers are always shmem paged backed. When they are
+* scanned out, they are remapped into DMM/TILER.
*/
flags &= ~OMAP_BO_SCANOUT;
+ flags |= OMAP_BO_MEM_SHMEM;
- /* currently don't allow cached buffers.. there is some caching
-* stuff that needs to be handled better
+ /*
+* Currently don't allow cached buffers. There is some caching
+* stuff that needs to be handled better.
*/
flags &= ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
flags |= tiler_get_cpu_cache_flags();
-
- /* align dimensions to slot boundaries... */
- tiler_align(gem2fmt(flags),
- &gsize.tiled.width, &gsize.tiled.height);
-
- /* ...and calculate size based on aligned dimensions */
- size = tiler_size(gem2fmt(flags),
- gsize.tiled.width, gsize.tiled.height);
- } else {
- size = PAGE_ALIGN(gsize.bytes);
+ } else if ((flags & OMAP_BO_SCANOUT) && !priv->usergart) {
+ /*
+* Use contiguous memory if we don't have DMM to remap
+* discontiguous buffers.
+*/
+ flags |= OMAP_BO_MEM_DMA_API;
+ } else if (!(flags & OMAP_BO_MEM_EXT)) {
+ /*
+* All other buffers not backed with external memory are
+* shmem-backed.
+*/
+ flags |= OMAP_BO_MEM_SHMEM;
}
+ /* Allocate the initialize the OMAP GEM object. */
omap_obj = kzalloc(sizeof(*omap_obj), GFP_KERNEL);
if (!omap_obj)
return NULL;
obj = &omap_obj->base;
+ omap_obj->flags = flags;
- if ((flags & OMAP_BO_SCANOUT) && !priv->usergart) {
- /* attempt to allocate contiguous memory if we don't
-* have DMM for remappign discontiguous buffers
+ if (flags & OMAP_BO_TILED) {
+ /*
+* For tiled buffers align dimensions to slot boundaries and
+* calculate size based on aligned dimensions.
*/
- omap_obj->vaddr = dma_alloc_writecombine(dev->dev, size,
- &omap_obj->paddr, GFP_KERNEL);
- if (!omap_obj->vaddr) {
- kfree(omap_obj);
+ tiler_align(gem2fmt(flags), &gsize.tiled.width,
+ &gsize.tiled.height);
- return NULL;
- }
+ size = tiler_size(gem2fmt(flags), gsize.tiled.width,
+ gsize.tiled.height);
- flags |= OMAP_BO_MEM_DMA_API;
+ omap_obj->width = gsize.tiled.width;
+ omap_obj->height = gsize.tiled.height;
+ } else {
+ size = PAGE_ALIGN(gsize.bytes);
}
spin_lock(&priv->list_lock);
list_add(&omap_obj->mm_list, &priv->obj_list);
spin_unlock(&priv->list_lock);
- omap_obj->flags = flags;
-
- if (flags & OMAP_BO_TILED) {
- omap_obj->width = gsize.tiled.width;
- omap_obj->height = gsize.tiled.height;
+ /* 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;
}
- if (flags & (OMAP_BO_MEM_DMA_API | OMAP_BO_MEM_EXT)) {
+ /* Initialize the GEM object. */
+ if (!(flags & OMAP_BO_MEM_SHMEM)) {
drm_gem_pri
[PATCH 13/15] drm: omapdrm: gem: Remove check for impossible condition
The GEM object can't be tiled without a usergart as that condition is
checked and considered as an error when creating the GEM object.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index c2b0cdfd7798..a95b6486fbf6 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -207,9 +207,6 @@ static void evict(struct drm_gem_object *obj)
enum tiler_fmt fmt = gem2fmt(omap_obj->flags);
int i;
- if (!priv->usergart)
- return;
-
for (i = 0; i < NUM_USERGART_ENTRIES; i++) {
struct omap_drm_usergart_entry *entry =
&priv->usergart[fmt].entry[i];
--
2.4.10
[PATCH 12/15] drm: omapdrm: gem: Simplify error handling when creating GEM object
The goto error statement end up just returning NULL without performing
any cleanup, replace it with a direct return.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 5ba447d717c6..c2b0cdfd7798 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1343,7 +1343,7 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
{
struct omap_drm_private *priv = dev->dev_private;
struct omap_gem_object *omap_obj;
- struct drm_gem_object *obj = NULL;
+ struct drm_gem_object *obj;
struct address_space *mapping;
size_t size;
int ret;
@@ -1351,7 +1351,7 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
if (flags & OMAP_BO_TILED) {
if (!priv->usergart) {
dev_err(dev->dev, "Tiled buffers require DMM\n");
- goto fail;
+ return NULL;
}
/* tiled buffers are always shmem paged backed.. when they are
@@ -1424,9 +1424,7 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
return obj;
fail:
- if (obj)
- omap_gem_free_object(obj);
-
+ omap_gem_free_object(obj);
return NULL;
}
--
2.4.10
[PATCH 11/15] drm: omapdrm: gem: Don't free mmap offset twice
The drm_gem_free_mmap_offset() call in omap_gem_free_object() is redundant as the same function is called from drm_gem_object_release(). Remove it. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/omapdrm/omap_gem.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c index f24bb71d9946..5ba447d717c6 100644 --- a/drivers/gpu/drm/omapdrm/omap_gem.c +++ b/drivers/gpu/drm/omapdrm/omap_gem.c @@ -1310,8 +1310,6 @@ void omap_gem_free_object(struct drm_gem_object *obj) list_del(&omap_obj->mm_list); spin_unlock(&priv->list_lock); - drm_gem_free_mmap_offset(obj); - /* this means the object is still pinned.. which really should * not happen. I think.. */ -- 2.4.10
[PATCH 10/15] drm: omapdrm: gem: Free the correct memory object
The GEM object free handler frees memory allocated by the driver using the pointer to the drm_gem_object instead of the pointer to the omap_gem_object that embeds it. This doesn't cause any issue in practice as the drm_gem_object is the first field of omap_gem_object, but would cause memory corruption if the structure layout changes. Fix it. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/omapdrm/omap_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c index 644dff8ab516..f24bb71d9946 100644 --- a/drivers/gpu/drm/omapdrm/omap_gem.c +++ b/drivers/gpu/drm/omapdrm/omap_gem.c @@ -1336,7 +1336,7 @@ void omap_gem_free_object(struct drm_gem_object *obj) drm_gem_object_release(obj); - kfree(obj); + kfree(omap_obj); } /* GEM buffer object constructor */ -- 2.4.10
[PATCH 09/15] drm: omapdrm: gem: Clean up GEM objects memory flags
The driver assumes that only objects backed by shmem need to be mapped
through DMM. While this is true with the current code, the assumption
won't hold with dma_buf import support.
Condition the mapping based on whether the buffer has been allocated
using the DMA mapping API instead and clean up the flags to avoid having
to check both flags and GEM object filp field to decide how to process
buffers. Flags are not the authoritative source of information regarding
where the buffer memory comes from, and are renamed to make that
clearer.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 57 +-
1 file changed, 25 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 8e3b415aa43b..644dff8ab516 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -30,9 +30,10 @@
*/
/* note: we use upper 8 bits of flags for driver-internal flags: */
-#define OMAP_BO_DMA0x0100 /* actually is physically
contiguous */
-#define OMAP_BO_EXT_SYNC 0x0200 /* externally allocated sync
object */
-#define OMAP_BO_EXT_MEM0x0400 /* externally allocated
memory */
+#define OMAP_BO_MEM_DMA_API0x0100 /* memory allocated with the
dma_alloc_* API */
+#define OMAP_BO_MEM_SHMEM 0x0200 /* memory allocated through
shmem backing */
+#define OMAP_BO_MEM_EXT0x0400 /* memory allocated
externally */
+#define OMAP_BO_EXT_SYNC 0x1000 /* externally allocated sync
object */
struct omap_gem_object {
struct drm_gem_object base;
@@ -48,16 +49,16 @@ struct omap_gem_object {
uint32_t roll;
/**
-* If buffer is allocated physically contiguous, the OMAP_BO_DMA flag
-* is set and the paddr is valid. Also if the buffer is remapped in
-* TILER and paddr_cnt > 0, then paddr is valid. But if you are using
-* the physical address and OMAP_BO_DMA is not set, then you should
-* be going thru omap_gem_{get,put}_paddr() to ensure the mapping is
-* not removed from under your feet.
+* If buffer is allocated physically contiguous, the OMAP_BO_MEM_DMA_API
+* flag is set and the paddr is valid. Also if the buffer is remapped
+* in TILER and paddr_cnt > 0, then paddr is valid. But if you are using
+* the physical address and OMAP_BO_MEM_DMA_API is not set, then you
+* should be going thru omap_gem_{get,put}_paddr() to ensure the mapping
+* is not removed from under your feet.
*
* Note that OMAP_BO_SCANOUT is a hint from userspace that DMA capable
-* buffer is requested, but doesn't mean that it is. Use the
-* OMAP_BO_DMA flag to determine if the buffer has a DMA capable
+* buffer is requested, but doesn't mean that it is. Use the
+* OMAP_BO_MEM_DMA_API flag to determine if the buffer has a DMA capable
* physical address.
*/
dma_addr_t paddr;
@@ -165,18 +166,6 @@ static uint64_t mmap_offset(struct drm_gem_object *obj)
return drm_vma_node_offset_addr(&obj->vma_node);
}
-/* GEM objects can either be allocated from contiguous memory (in which
- * case obj->filp==NULL), or w/ shmem backing (obj->filp!=NULL). But non
- * contiguous buffers can be remapped in TILER/DMM if they need to be
- * contiguous... but we don't do this all the time to reduce pressure
- * on TILER/DMM space when we know at allocation time that the buffer
- * will need to be scanned out.
- */
-static inline bool is_shmem(struct drm_gem_object *obj)
-{
- return obj->filp != NULL;
-}
-
/*
-
* Eviction
*/
@@ -294,7 +283,7 @@ static int get_pages(struct drm_gem_object *obj, struct
page ***pages)
struct omap_gem_object *omap_obj = to_omap_bo(obj);
int ret = 0;
- if (is_shmem(obj) && !omap_obj->pages) {
+ if ((omap_obj->flags & OMAP_BO_MEM_SHMEM) && !omap_obj->pages) {
ret = omap_gem_attach_pages(obj);
if (ret) {
dev_err(obj->dev->dev, "could not attach pages\n");
@@ -398,7 +387,7 @@ static int fault_1d(struct drm_gem_object *obj,
omap_gem_cpu_sync(obj, pgoff);
pfn = page_to_pfn(omap_obj->pages[pgoff]);
} else {
- BUG_ON(!(omap_obj->flags & OMAP_BO_DMA));
+ BUG_ON(!(omap_obj->flags & OMAP_BO_MEM_DMA_API));
pfn = (omap_obj->paddr >> PAGE_SHIFT) + pgoff;
}
@@ -728,7 +717,8 @@ fail:
static inline bool is_cached_coherent(struct drm_gem_object *obj)
{
struct omap_gem_object *omap_obj = to_omap_bo(obj);
- return is_shmem(obj) &&
+
+ return (omap_obj->flags & OMAP_BO_MEM_SHMEM) &&
((omap_obj->flags & OMAP_BO_CACHE_MAS
[PATCH 08/15] drm: omapdrm: gem: Mask out private flags passed from userspace
The 8 high order bits of the buffer flags are reserved for internal use.
Mask them out from the flags passed by userspace.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.c | 9 ++---
include/uapi/drm/omap_drm.h| 1 +
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 83d63d71062c..e405ab23d7a6 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -551,10 +551,13 @@ static int ioctl_gem_new(struct drm_device *dev, void
*data,
struct drm_file *file_priv)
{
struct drm_omap_gem_new *args = data;
+ u32 flags = args->flags & OMAP_BO_USER_MASK;
+
VERB("%p:%p: size=0x%08x, flags=%08x", dev, file_priv,
- args->size.bytes, args->flags);
- return omap_gem_new_handle(dev, file_priv, args->size,
- args->flags, &args->handle);
+args->size.bytes, flags);
+
+ return omap_gem_new_handle(dev, file_priv, args->size, flags,
+ &args->handle);
}
static int ioctl_gem_cpu_prep(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
index 1d0b1172664e..6852c26e8f78 100644
--- a/include/uapi/drm/omap_drm.h
+++ b/include/uapi/drm/omap_drm.h
@@ -36,6 +36,7 @@ struct drm_omap_param {
#define OMAP_BO_SCANOUT0x0001 /* scanout capable
(phys contiguous) */
#define OMAP_BO_CACHE_MASK 0x0006 /* cache type mask, see cache
modes */
#define OMAP_BO_TILED_MASK 0x0f00 /* tiled mapping mask, see
tiled modes */
+#define OMAP_BO_USER_MASK 0x00ff /* flags settable by userspace
*/
/* cache modes */
#define OMAP_BO_CACHED 0x /* default */
--
2.4.10
[PATCH 07/15] drm: omapdrm: gem: Remove omap_drm_private has_dmm field
The field is set to true iff the usergart field is not NULL. Test
usergart instead.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
drivers/gpu/drm/omapdrm/omap_drv.h | 1 -
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/omapdrm/omap_gem.c | 5 ++---
drivers/gpu/drm/omapdrm/omap_plane.c | 2 +-
5 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 69be482e8d47..83d63d71062c 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -303,7 +303,7 @@ static int omap_modeset_init_properties(struct drm_device
*dev)
{
struct omap_drm_private *priv = dev->dev_private;
- if (priv->has_dmm) {
+ if (priv->usergart) {
dev->mode_config.rotation_property =
drm_mode_create_rotation_property(dev,
BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 718f032aa052..97fcb892fdd7 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -100,7 +100,6 @@ struct omap_drm_private {
struct list_head obj_list;
struct omap_drm_usergart *usergart;
- bool has_dmm;
/* properties: */
struct drm_property *zorder_prop;
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index db4aa35accfc..9fb15de1207f 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -132,7 +132,7 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
mode_cmd.width * ((sizes->surface_bpp + 7) / 8),
mode_cmd.width, sizes->surface_bpp);
- fbdev->ywrap_enabled = priv->has_dmm && ywrap_enabled;
+ fbdev->ywrap_enabled = priv->usergart && ywrap_enabled;
if (fbdev->ywrap_enabled) {
/* need to align pitch to page size if using DMM scrolling */
mode_cmd.pitches[0] = PAGE_ALIGN(mode_cmd.pitches[0]);
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 391bc7378f9f..8e3b415aa43b 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -787,7 +787,7 @@ int omap_gem_get_paddr(struct drm_gem_object *obj,
mutex_lock(&obj->dev->struct_mutex);
- if (remap && is_shmem(obj) && priv->has_dmm) {
+ if (remap && is_shmem(obj) && priv->usergart) {
if (omap_obj->paddr_cnt == 0) {
struct page **pages;
uint32_t npages = obj->size >> PAGE_SHIFT;
@@ -1393,7 +1393,7 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
obj = &omap_obj->base;
- if ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm) {
+ if ((flags & OMAP_BO_SCANOUT) && !priv->usergart) {
/* attempt to allocate contiguous memory if we don't
* have DMM for remappign discontiguous buffers
*/
@@ -1521,7 +1521,6 @@ void omap_gem_init(struct drm_device *dev)
}
priv->usergart = usergart;
- priv->has_dmm = true;
}
void omap_gem_deinit(struct drm_device *dev)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 11d406b160e1..1c6ec7080f16 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -208,7 +208,7 @@ void omap_plane_install_properties(struct drm_plane *plane,
struct drm_device *dev = plane->dev;
struct omap_drm_private *priv = dev->dev_private;
- if (priv->has_dmm) {
+ if (priv->usergart) {
struct drm_property *prop = dev->mode_config.rotation_property;
drm_object_attach_property(obj, prop, 0);
--
2.4.10
[PATCH 06/15] drm: omapdrm: gem: Move global usergart variable to omap_drm_private
The structure contains data related to a device instance, it shouldn't
be a global variable.
While at it rename the usergart structures with an omap_drm_ prefix.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 3 +++
drivers/gpu/drm/omapdrm/omap_gem.c | 54 +++---
2 files changed, 36 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 289d9b0984e2..718f032aa052 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -36,6 +36,8 @@
#define MODULE_NAME "omapdrm"
+struct omap_drm_usergart;
+
/* max # of mapper-id's that can be assigned.. todo, come up with a better
* (but still inexpensive) way to store/access per-buffer mapper private
* data..
@@ -97,6 +99,7 @@ struct omap_drm_private {
/* list of GEM objects: */
struct list_head obj_list;
+ struct omap_drm_usergart *usergart;
bool has_dmm;
/* properties: */
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index b6dffdbbc0c1..391bc7378f9f 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -124,21 +124,22 @@ struct omap_gem_object {
* for later..
*/
#define NUM_USERGART_ENTRIES 2
-struct usergart_entry {
+struct omap_drm_usergart_entry {
struct tiler_block *block; /* the reserved tiler block */
dma_addr_t paddr;
struct drm_gem_object *obj; /* the current pinned obj */
pgoff_t obj_pgoff; /* page offset of obj currently
mapped in */
};
-static struct {
- struct usergart_entry entry[NUM_USERGART_ENTRIES];
+
+struct omap_drm_usergart {
+ struct omap_drm_usergart_entry entry[NUM_USERGART_ENTRIES];
int height; /* height in rows */
int height_shift; /* ilog2(height in rows) */
int slot_shift; /* ilog2(width per slot) */
int stride_pfn; /* stride in pages */
int last; /* index of last used entry */
-} *usergart;
+};
/*
-
* Helpers
@@ -181,10 +182,11 @@ static inline bool is_shmem(struct drm_gem_object *obj)
*/
static void evict_entry(struct drm_gem_object *obj,
- enum tiler_fmt fmt, struct usergart_entry *entry)
+ enum tiler_fmt fmt, struct omap_drm_usergart_entry *entry)
{
struct omap_gem_object *omap_obj = to_omap_bo(obj);
- int n = usergart[fmt].height;
+ struct omap_drm_private *priv = obj->dev->dev_private;
+ int n = priv->usergart[fmt].height;
size_t size = PAGE_SIZE * n;
loff_t off = mmap_offset(obj) +
(entry->obj_pgoff << PAGE_SHIFT);
@@ -210,16 +212,19 @@ static void evict_entry(struct drm_gem_object *obj,
static void evict(struct drm_gem_object *obj)
{
struct omap_gem_object *omap_obj = to_omap_bo(obj);
+ struct omap_drm_private *priv = obj->dev->dev_private;
if (omap_obj->flags & OMAP_BO_TILED) {
enum tiler_fmt fmt = gem2fmt(omap_obj->flags);
int i;
- if (!usergart)
+ if (!priv->usergart)
return;
for (i = 0; i < NUM_USERGART_ENTRIES; i++) {
- struct usergart_entry *entry = &usergart[fmt].entry[i];
+ struct omap_drm_usergart_entry *entry =
+ &priv->usergart[fmt].entry[i];
+
if (entry->obj == obj)
evict_entry(obj, fmt, entry);
}
@@ -408,7 +413,8 @@ static int fault_2d(struct drm_gem_object *obj,
struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct omap_gem_object *omap_obj = to_omap_bo(obj);
- struct usergart_entry *entry;
+ struct omap_drm_private *priv = obj->dev->dev_private;
+ struct omap_drm_usergart_entry *entry;
enum tiler_fmt fmt = gem2fmt(omap_obj->flags);
struct page *pages[64]; /* XXX is this too much to have on stack? */
unsigned long pfn;
@@ -421,8 +427,8 @@ static int fault_2d(struct drm_gem_object *obj,
* that need to be mapped in to fill 4kb wide CPU page. If the slot
* height is 64, then 64 pages fill a 4kb wide by 64 row region.
*/
- const int n = usergart[fmt].height;
- const int n_shift = usergart[fmt].height_shift;
+ const int n = priv->usergart[fmt].height;
+ const int n_shift = priv->usergart[fmt].height_shift;
/*
* If buffer width in bytes > PAGE_SIZE then the virtual stride is
@@ -443,11 +449,11 @@ static int fault_2d(struct drm_gem_object *obj,
base_pgoff = round_down(pgoff, m << n_shift);
[PATCH 05/15] drm: omapdrm: gem: Group functions by purpose
Divide the GEM implementation in groups of functions to improve
readability.
No code change is performed by this commit.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 140 +++--
1 file changed, 87 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index a953a967b7db..b6dffdbbc0c1 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -29,14 +29,11 @@
* GEM buffer object implementation.
*/
-#define to_omap_bo(x) container_of(x, struct omap_gem_object, base)
-
/* note: we use upper 8 bits of flags for driver-internal flags: */
-#define OMAP_BO_DMA0x0100 /* actually is
physically contiguous */
+#define OMAP_BO_DMA0x0100 /* actually is physically
contiguous */
#define OMAP_BO_EXT_SYNC 0x0200 /* externally allocated sync
object */
#define OMAP_BO_EXT_MEM0x0400 /* externally allocated
memory */
-
struct omap_gem_object {
struct drm_gem_object base;
@@ -113,6 +110,7 @@ struct omap_gem_object {
} *sync;
};
+#define to_omap_bo(x) container_of(x, struct omap_gem_object, base)
/* To deal with userspace mmap'ings of 2d tiled buffers, which (a) are
* not necessarily pinned in TILER all the time, and (b) when they are
@@ -166,6 +164,22 @@ static uint64_t mmap_offset(struct drm_gem_object *obj)
return drm_vma_node_offset_addr(&obj->vma_node);
}
+/* GEM objects can either be allocated from contiguous memory (in which
+ * case obj->filp==NULL), or w/ shmem backing (obj->filp!=NULL). But non
+ * contiguous buffers can be remapped in TILER/DMM if they need to be
+ * contiguous... but we don't do this all the time to reduce pressure
+ * on TILER/DMM space when we know at allocation time that the buffer
+ * will need to be scanned out.
+ */
+static inline bool is_shmem(struct drm_gem_object *obj)
+{
+ return obj->filp != NULL;
+}
+
+/*
-
+ * Eviction
+ */
+
static void evict_entry(struct drm_gem_object *obj,
enum tiler_fmt fmt, struct usergart_entry *entry)
{
@@ -212,30 +226,9 @@ static void evict(struct drm_gem_object *obj)
}
}
-/* GEM objects can either be allocated from contiguous memory (in which
- * case obj->filp==NULL), or w/ shmem backing (obj->filp!=NULL). But non
- * contiguous buffers can be remapped in TILER/DMM if they need to be
- * contiguous... but we don't do this all the time to reduce pressure
- * on TILER/DMM space when we know at allocation time that the buffer
- * will need to be scanned out.
- */
-static inline bool is_shmem(struct drm_gem_object *obj)
-{
- return obj->filp != NULL;
-}
-
-/**
- * shmem buffers that are mapped cached can simulate coherency via using
- * page faulting to keep track of dirty pages
+/*
-
+ * Page Management
*/
-static inline bool is_cached_coherent(struct drm_gem_object *obj)
-{
- struct omap_gem_object *omap_obj = to_omap_bo(obj);
- return is_shmem(obj) &&
- ((omap_obj->flags & OMAP_BO_CACHE_MASK) == OMAP_BO_CACHED);
-}
-
-static DEFINE_SPINLOCK(sync_lock);
/** ensure backing pages are allocated */
static int omap_gem_attach_pages(struct drm_gem_object *obj)
@@ -380,6 +373,10 @@ int omap_gem_tiled_size(struct drm_gem_object *obj,
uint16_t *w, uint16_t *h)
return -EINVAL;
}
+/*
-
+ * Fault Handling
+ */
+
/* Normal handling for the case of faulting in non-tiled buffers */
static int fault_1d(struct drm_gem_object *obj,
struct vm_area_struct *vma, struct vm_fault *vmf)
@@ -614,6 +611,9 @@ int omap_gem_mmap_obj(struct drm_gem_object *obj,
return 0;
}
+/*
-
+ * Dumb Buffers
+ */
/**
* omap_gem_dumb_create- create a dumb buffer
@@ -710,6 +710,21 @@ fail:
}
#endif
+/*
-
+ * Memory Management & DMA Sync
+ */
+
+/**
+ * shmem buffers that are mapped cached can simulate coherency via using
+ * page faulting to keep track of dirty pages
+ */
+static inline bool is_cached_coherent(struct drm_gem_object *obj)
+{
+ struct omap_gem_object *omap_obj = to_omap_bo(obj);
+ return is_shmem(obj) &&
+ ((omap_obj->flags & OMAP_BO_CACHE_MASK) == OMAP_BO_CACHED);
+}
+
/* Sync the buffer for CPU access.. note pages should already be
* attached, ie. omap_gem_get_pages()
*/
@@ -943,6 +958,10 @@ void *omap_gem_vaddr(struct drm_gem_object *obj)
}
#endif
+/*
-
+ * Power Management
+ */
+
[PATCH 04/15] drm: omapdrm: gem: Remove forward declarations
Reorder functions to get rid of forward declarations
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 90 +++---
1 file changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 29a7ac6eb040..a953a967b7db 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -113,8 +113,6 @@ struct omap_gem_object {
} *sync;
};
-static int get_pages(struct drm_gem_object *obj, struct page ***pages);
-static uint64_t mmap_offset(struct drm_gem_object *obj);
/* To deal with userspace mmap'ings of 2d tiled buffers, which (a) are
* not necessarily pinned in TILER all the time, and (b) when they are
@@ -144,6 +142,30 @@ static struct {
int last; /* index of last used entry */
} *usergart;
+/*
-
+ * Helpers
+ */
+
+/** get mmap offset */
+static uint64_t mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ int ret;
+ size_t size;
+
+ WARN_ON(!mutex_is_locked(&dev->struct_mutex));
+
+ /* Make it mmapable */
+ size = omap_gem_mmap_size(obj);
+ ret = drm_gem_create_mmap_offset_size(obj, size);
+ if (ret) {
+ dev_err(dev->dev, "could not allocate mmap offset\n");
+ return 0;
+ }
+
+ return drm_vma_node_offset_addr(&obj->vma_node);
+}
+
static void evict_entry(struct drm_gem_object *obj,
enum tiler_fmt fmt, struct usergart_entry *entry)
{
@@ -266,6 +288,28 @@ free_pages:
return ret;
}
+/* acquire pages when needed (for example, for DMA where physically
+ * contiguous buffer is not required
+ */
+static int get_pages(struct drm_gem_object *obj, struct page ***pages)
+{
+ struct omap_gem_object *omap_obj = to_omap_bo(obj);
+ int ret = 0;
+
+ if (is_shmem(obj) && !omap_obj->pages) {
+ ret = omap_gem_attach_pages(obj);
+ if (ret) {
+ dev_err(obj->dev->dev, "could not attach pages\n");
+ return ret;
+ }
+ }
+
+ /* TODO: even phys-contig.. we should have a list of pages? */
+ *pages = omap_obj->pages;
+
+ return 0;
+}
+
/** release backing pages */
static void omap_gem_detach_pages(struct drm_gem_object *obj)
{
@@ -295,26 +339,6 @@ uint32_t omap_gem_flags(struct drm_gem_object *obj)
return to_omap_bo(obj)->flags;
}
-/** get mmap offset */
-static uint64_t mmap_offset(struct drm_gem_object *obj)
-{
- struct drm_device *dev = obj->dev;
- int ret;
- size_t size;
-
- WARN_ON(!mutex_is_locked(&dev->struct_mutex));
-
- /* Make it mmapable */
- size = omap_gem_mmap_size(obj);
- ret = drm_gem_create_mmap_offset_size(obj, size);
- if (ret) {
- dev_err(dev->dev, "could not allocate mmap offset\n");
- return 0;
- }
-
- return drm_vma_node_offset_addr(&obj->vma_node);
-}
-
uint64_t omap_gem_mmap_offset(struct drm_gem_object *obj)
{
uint64_t offset;
@@ -861,28 +885,6 @@ int omap_gem_tiled_stride(struct drm_gem_object *obj,
uint32_t orient)
return ret;
}
-/* acquire pages when needed (for example, for DMA where physically
- * contiguous buffer is not required
- */
-static int get_pages(struct drm_gem_object *obj, struct page ***pages)
-{
- struct omap_gem_object *omap_obj = to_omap_bo(obj);
- int ret = 0;
-
- if (is_shmem(obj) && !omap_obj->pages) {
- ret = omap_gem_attach_pages(obj);
- if (ret) {
- dev_err(obj->dev->dev, "could not attach pages\n");
- return ret;
- }
- }
-
- /* TODO: even phys-contig.. we should have a list of pages? */
- *pages = omap_obj->pages;
-
- return 0;
-}
-
/* if !remap, and we don't have pages backing, then fail, rather than
* increasing the pin count (which we don't really do yet anyways,
* because we don't support swapping pages back out). And 'remap'
--
2.4.10
[PATCH 03/15] drm: omapdrm: gem: Remove unused function prototypes
Several DRM core function prototypes refer to functions that don't exist anymore and are thus obviously never called. Remove them. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/omapdrm/omap_gem.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c index 374ce2adc811..29a7ac6eb040 100644 --- a/drivers/gpu/drm/omapdrm/omap_gem.c +++ b/drivers/gpu/drm/omapdrm/omap_gem.c @@ -25,12 +25,6 @@ #include "omap_drv.h" #include "omap_dmm_tiler.h" -/* remove these once drm core helpers are merged */ -struct page **_drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask); -void _drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages, - bool dirty, bool accessed); -int _drm_gem_create_mmap_offset_size(struct drm_gem_object *obj, size_t size); - /* * GEM buffer object implementation. */ -- 2.4.10
[PATCH 02/15] drm: omapdrm: Make fbdev emulation optional
Don't compile the fbdev emulation code when fbdev emulation support is
disabled.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/Makefile | 3 ++-
drivers/gpu/drm/omapdrm/omap_debugfs.c | 4
drivers/gpu/drm/omapdrm/omap_drv.c | 4
drivers/gpu/drm/omapdrm/omap_drv.h | 10 ++
drivers/gpu/drm/omapdrm/omap_fbdev.c | 4
drivers/gpu/drm/omapdrm/omap_gem.c | 4
6 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/Makefile b/drivers/gpu/drm/omapdrm/Makefile
index 778372b062ad..368c1ec6805a 100644
--- a/drivers/gpu/drm/omapdrm/Makefile
+++ b/drivers/gpu/drm/omapdrm/Makefile
@@ -12,10 +12,11 @@ omapdrm-y := omap_drv.o \
omap_encoder.o \
omap_connector.o \
omap_fb.o \
- omap_fbdev.o \
omap_gem.o \
omap_gem_dmabuf.o \
omap_dmm_tiler.o \
tcm-sita.o
+omapdrm-$(CONFIG_DRM_FBDEV_EMULATION) += omap_fbdev.o
+
obj-$(CONFIG_DRM_OMAP) += omapdrm.o
diff --git a/drivers/gpu/drm/omapdrm/omap_debugfs.c
b/drivers/gpu/drm/omapdrm/omap_debugfs.c
index ee91a25127f9..6f5fc14fc015 100644
--- a/drivers/gpu/drm/omapdrm/omap_debugfs.c
+++ b/drivers/gpu/drm/omapdrm/omap_debugfs.c
@@ -51,6 +51,7 @@ static int mm_show(struct seq_file *m, void *arg)
return drm_mm_dump_table(m, &dev->vma_offset_manager->vm_addr_space_mm);
}
+#ifdef CONFIG_DRM_FBDEV_EMULATION
static int fb_show(struct seq_file *m, void *arg)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
@@ -73,12 +74,15 @@ static int fb_show(struct seq_file *m, void *arg)
return 0;
}
+#endif
/* list of debufs files that are applicable to all devices */
static struct drm_info_list omap_debugfs_list[] = {
{"gem", gem_show, 0},
{"mm", mm_show, 0},
+#ifdef CONFIG_DRM_FBDEV_EMULATION
{"fb", fb_show, 0},
+#endif
};
/* list of debugfs files that are specific to devices with dmm/tiler */
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 5c6609cbb6a2..69be482e8d47 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -692,10 +692,6 @@ static int dev_load(struct drm_device *dev, unsigned long
flags)
drm_crtc_vblank_off(priv->crtcs[i]);
priv->fbdev = omap_fbdev_init(dev);
- if (!priv->fbdev) {
- dev_warn(dev->dev, "omap_fbdev_init failed\n");
- /* well, limp along without an fbdev.. maybe X11 will work? */
- }
/* store off drm_device for use in pm ops */
dev_set_drvdata(dev->dev, dev);
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 130fca70bfd7..289d9b0984e2 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -138,8 +138,18 @@ void omap_irq_unregister(struct drm_device *dev, struct
omap_drm_irq *irq);
void omap_drm_irq_uninstall(struct drm_device *dev);
int omap_drm_irq_install(struct drm_device *dev);
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct drm_fb_helper *omap_fbdev_init(struct drm_device *dev);
void omap_fbdev_free(struct drm_device *dev);
+#else
+static inline struct drm_fb_helper *omap_fbdev_init(struct drm_device *dev)
+{
+ return NULL;
+}
+static inline void omap_fbdev_free(struct drm_device *dev)
+{
+}
+#endif
struct omap_video_timings *omap_crtc_timings(struct drm_crtc *crtc);
enum omap_channel omap_crtc_channel(struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b8e4cdec28c3..db4aa35accfc 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -298,6 +298,10 @@ fini:
drm_fb_helper_fini(helper);
fail:
kfree(fbdev);
+
+ dev_warn(dev->dev, "omap_fbdev_init failed\n");
+ /* well, limp along without an fbdev.. maybe X11 will work? */
+
return NULL;
}
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 7ed08fdc4c42..374ce2adc811 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -653,6 +653,7 @@ fail:
return ret;
}
+#ifdef CONFIG_DRM_FBDEV_EMULATION
/* Set scrolling position. This allows us to implement fast scrolling
* for console.
*
@@ -689,6 +690,7 @@ fail:
return ret;
}
+#endif
/* Sync the buffer for CPU access.. note pages should already be
* attached, ie. omap_gem_get_pages()
@@ -924,6 +926,7 @@ int omap_gem_put_pages(struct drm_gem_object *obj)
return 0;
}
+#ifdef CONFIG_DRM_FBDEV_EMULATION
/* Get kernel virtual address for CPU access.. this more or less only
* exists for omap_fbdev. This should be called with struct_mutex
* held.
@@ -942,6 +945,7 @@ void *omap_gem_vaddr(struct drm_gem_object *obj)
}
return omap_obj->vaddr;
}
+#endif
#ifdef CONFIG_PM
/* re-pin objects in DMM in resume path: */
--
2.4.1
[PATCH 01/15] drm: omapdrm: Fix plane state free in plane reset handler
The plane reset handler frees the plane state and allocates a new
default state, but when doing so attempt to free the plane state using
the base plane state pointer instead of casting it to the
driver-specific state object that has been allocated. Fix it by using
the omap_plane_atomic_destroy_state() function to destroy the plane
state instead of duplicating the code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_plane.c | 53 ++--
1 file changed, 26 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 3054bda72688..11d406b160e1 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -188,33 +188,6 @@ static const struct drm_plane_helper_funcs
omap_plane_helper_funcs = {
.atomic_disable = omap_plane_atomic_disable,
};
-static void omap_plane_reset(struct drm_plane *plane)
-{
- struct omap_plane *omap_plane = to_omap_plane(plane);
- struct omap_plane_state *omap_state;
-
- if (plane->state && plane->state->fb)
- drm_framebuffer_unreference(plane->state->fb);
-
- kfree(plane->state);
- plane->state = NULL;
-
- omap_state = kzalloc(sizeof(*omap_state), GFP_KERNEL);
- if (omap_state == NULL)
- return;
-
- /*
-* Set defaults depending on whether we are a primary or overlay
-* plane.
-*/
- omap_state->zorder = plane->type == DRM_PLANE_TYPE_PRIMARY
- ? 0 : omap_plane->id;
- omap_state->base.rotation = BIT(DRM_ROTATE_0);
-
- plane->state = &omap_state->base;
- plane->state->plane = plane;
-}
-
static void omap_plane_destroy(struct drm_plane *plane)
{
struct omap_plane *omap_plane = to_omap_plane(plane);
@@ -270,6 +243,32 @@ static void omap_plane_atomic_destroy_state(struct
drm_plane *plane,
kfree(to_omap_plane_state(state));
}
+static void omap_plane_reset(struct drm_plane *plane)
+{
+ struct omap_plane *omap_plane = to_omap_plane(plane);
+ struct omap_plane_state *omap_state;
+
+ if (plane->state) {
+ omap_plane_atomic_destroy_state(plane, plane->state);
+ plane->state = NULL;
+ }
+
+ omap_state = kzalloc(sizeof(*omap_state), GFP_KERNEL);
+ if (omap_state == NULL)
+ return;
+
+ /*
+* Set defaults depending on whether we are a primary or overlay
+* plane.
+*/
+ omap_state->zorder = plane->type == DRM_PLANE_TYPE_PRIMARY
+ ? 0 : omap_plane->id;
+ omap_state->base.rotation = BIT(DRM_ROTATE_0);
+
+ plane->state = &omap_state->base;
+ plane->state->plane = plane;
+}
+
static int omap_plane_atomic_set_property(struct drm_plane *plane,
struct drm_plane_state *state,
struct drm_property *property,
--
2.4.10
[PATCH 00/15] omapdrm: Implement dma_buf import
Hello, This patch series implements support for dma_buf import in the omapdrm driver. The patches are based on top of the latest drm-next branch and can be found in my git tree at git://linuxtv.org/pinchartl/fbdev.git omapdrm/dmabuf-import The first two patches are unrelated fixes and enhancements, but I've included them in the series to avoid merge conflicts. The next 12 patches are miscellaneous fixes, cleanups and refactoring to prepare for patch 15/15 that implements dma_buf import. The code has been successfully tested with the vivid driver as an exporter, using a hacked version that uses uncached CPU mappings in vivid when filling the buffers. vivid is a test driver that generates a test pattern using the CPU with cached mappings by default, resulting in corruption on the screen due to missing cache handling. As the problem doesn't occur when sharing buffers not touched by the CPU or touched through uncached mappings only, it will be addressed separately. Laurent Pinchart (15): drm: omapdrm: Fix plane state free in plane reset handler drm: omapdrm: Make fbdev emulation optional drm: omapdrm: gem: Remove unused function prototypes drm: omapdrm: gem: Remove forward declarations drm: omapdrm: gem: Group functions by purpose drm: omapdrm: gem: Move global usergart variable to omap_drm_private drm: omapdrm: gem: Remove omap_drm_private has_dmm field drm: omapdrm: gem: Mask out private flags passed from userspace drm: omapdrm: gem: Clean up GEM objects memory flags drm: omapdrm: gem: Free the correct memory object drm: omapdrm: gem: Don't free mmap offset twice drm: omapdrm: gem: Simplify error handling when creating GEM object drm: omapdrm: gem: Remove check for impossible condition drm: omapdrm: gem: Refactor GEM object allocation drm: omapdrm: gem: Implement dma_buf import drivers/gpu/drm/omapdrm/Makefile | 3 +- drivers/gpu/drm/omapdrm/omap_debugfs.c| 4 + drivers/gpu/drm/omapdrm/omap_drv.c| 15 +- drivers/gpu/drm/omapdrm/omap_drv.h| 16 +- drivers/gpu/drm/omapdrm/omap_fbdev.c | 6 +- drivers/gpu/drm/omapdrm/omap_gem.c| 504 +++--- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 57 +++- drivers/gpu/drm/omapdrm/omap_plane.c | 55 ++-- include/uapi/drm/omap_drm.h | 1 + 9 files changed, 426 insertions(+), 235 deletions(-) -- Regards, Laurent Pinchart
