- 10 9月, 2014 2 次提交
-
-
由 Rob Clark 提交于
In particular, blend_setup() should not overwrite the other crtc's mixer settings. Also, the encoder needs to be able to specify the mixer-id explicitly, since both LVDS and DTV use 'INTF_LVDC_DTV', so we cannot guess the mixer-id from the interface. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 David Herrmann 提交于
One step closer to dropping all the drm_bus_* code: Add a driver->set_busid() callback and make all drivers use the generic helpers. Nouveau is the only driver that uses two different bus-types with the same drm_driver. This is totally broken if both buses are available on the same machine (unlikely, but lets be safe). Therefore, we create two different drivers for each platform during module_init() and set the set_busid() callback respectively. Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 04 8月, 2014 2 次提交
-
-
由 Rob Clark 提交于
Somewhere along the way, the firmware loader sprouted another lock dependency, resulting in possible deadlock scenario: &dev->struct_mutex --> &sb->s_type->i_mutex_key#2 --> &mm->mmap_sem which is problematic vs things like gem mmap. So introduce a separate mutex to synchronize gpu init. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Now that we (almost) have enough dependencies in place (MMCC, RPM, etc), add necessary DT support so that we can use drm/msm on upstream kernel. v2: update for review comments v3: rebase on component helper changes Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 05 7月, 2014 1 次提交
-
-
由 Russell King 提交于
Update MSM's DRM driver to use the component match support rather than add_components. Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 22 6月, 2014 1 次提交
-
-
由 Peter Griffin 提交于
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: NPeter Griffin <peter.griffin@linaro.org> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 05 6月, 2014 1 次提交
-
-
由 Rob Clark 提交于
All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same locking. Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked(). Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 02 6月, 2014 3 次提交
-
-
由 Rob Clark 提交于
We want at least __GFP_WAIT, otherwise dma-mapping tries to use coherent pool rather than CMA pool. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
To ease debugging, add debugfs file which can be cat/tail'd to log submits, along with fence #. If GPU hangs, you can look at 'gpu' debugfs file to find last completed fence and current register state, and compare with logged rd file to narrow down the DRAW_INDX which triggered the GPU hang. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 23 4月, 2014 1 次提交
-
-
由 Daniel Vetter 提交于
Unfortunately this requires a drm-wide change, and I didn't see a sane way around that. Luckily it's fairly simple, we just need to inline the respective get_irq implementation from either drm_pci.c or drm_platform.c. With that we can now also remove drm_dev_to_irq from drm_irq.c. Reviewed-by: NThierry Reding <treding@nvidia.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 31 3月, 2014 3 次提交
-
-
由 Rob Clark 提交于
After reading a nice article on LWN[1], I went back and double checked my handling of invalid-input checking. Turns out there were a couple places I had missed. Since the driver is fairly young, and the devices it supports are really only just barely usable for basic stuff (serial console) with an upstream kernel, I think we should fix this now and revert specific parts of this patch later in the unlikely event that a regression is reported. [1] https://lwn.net/Articles/588444/Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Shut down the clks when the gpu has nothing to do. A short inactivity timer is used to provide a low pass filter for power transitions. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 14 1月, 2014 1 次提交
-
-
由 Daniel Vetter 提交于
This was hidden in a generic void * dev->mm_private. But only ever used for gem. But thanks to this fake generic pretension no one noticed that Rob's drm drivers are now all broken. So just give the offset manager a type pointer and fix up msm, omapdrm and tilcdc. v2: Fixup compile fail. v3: Fixup rebase fail that David spotted. Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 10 1月, 2014 3 次提交
-
-
由 Rob Clark 提交于
Add support for the new MDP5 display controller block. The mapping between parts of the display controller and KMS is: plane -> PIPE{RGBn,VIGn} \ crtc -> LM (layer mixer) |-> MDP "device" encoder -> INTF / connector -> HDMI/DSI/eDP/etc --> other device(s) Unlike MDP4, it appears we can get by with a single encoder, rather than needing a different implementation for DTV, DSI, etc. (Ie. the register interface is same, just different bases.) Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are routed through MDP. And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from which blocks need to be allocated to the active pipes based on fetch stride. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Add a VRAM carveout that is used for systems which do not have an IOMMU. The VRAM carveout uses CMA. The arch code must setup a CMA pool for the device (preferrably in highmem.. a 256m-512m VRAM pool in lowmem is not cool). The user can configure the VRAM pool size using msm.vram module param. Technically, the abstraction of IOMMU behind msm_mmu is not strictly needed, but it simplifies the GEM code a bit, and will be useful later when I add support for a2xx devices with GPUMMU, so I decided to keep this part. It appears to be possible to configure the GPU to restrict access to addresses within the VRAM pool, but this is not done yet. So for now the GPU will refuse to load if there is no sort of mmu. Once address based limits are supported and tested to confirm that we aren't giving the GPU access to arbitrary memory, this restriction can be lifted Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 18 12月, 2013 2 次提交
-
-
由 Daniel Vetter 提交于
I've killed them a long time ago in drm/i915, let's get rid of this remnant of shared drm core days for good. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Vetter 提交于
The drvdata pointer is already assigned to something useful. Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 02 11月, 2013 3 次提交
-
-
由 Rob Clark 提交于
Re-arrange things a bit so that we can get work requested after a bo fence passes, like pageflip, done before retiring bo's. Without any sort of bo cache in userspace, some games can trigger hundred's of transient bo's, which can cause retire to take a long time (5-10ms). Obviously we want a bo cache.. but this cleanup will make things a bit easier for atomic as well and makes things a bit cleaner. Signed-off-by: NRob Clark <robdclark@gmail.com> Acked-by: NDavid Brown <davidb@codeaurora.org>
-
由 Rob Clark 提交于
Enable support for drm render nodes for msm by flagging the ioctls that are safe and only needed for rendering. Signed-off-by: NRob Clark <robdclark@gmail.com> Acked-by: NDavid Brown <davidb@codeaurora.org>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com> Acked-by: NDavid Brown <davidb@codeaurora.org>
-
- 28 9月, 2013 3 次提交
-
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
We still need an API exported by msm iommu driver (but not visible in any public header anymore). For now, just declare the prototype ourselves, but when msm iommu driver provides a better option, use that instead. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Thomas Meyer 提交于
The variable priv->kms is not initialized yet. Found by "scripts/coccinelle/tests/odd_ptr_err.cocci". PTR_ERR should access the value just tested by IS_ERR. Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
-
- 12 9月, 2013 1 次提交
-
-
由 Rob Clark 提交于
When we CPU_PREP a bo with NOSYNC flag (for example, to implement PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE), an -EBUSY return indicates to userspace that the bo is still busy. Previously it was incorrectly returning 0 in this case. And while we're in there throw in an bit of extra sanity checking in case userspace tries to wait for a bogus fence. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 25 8月, 2013 2 次提交
-
-
由 Rob Clark 提交于
Add initial support for a3xx 3d core. So far, with hardware that I've seen to date, we can have: + zero, one, or two z180 2d cores + a3xx or a2xx 3d core, which share a common CP (the firmware for the CP seems to implement some different PM4 packet types but the basics of cmdstream submission are the same) Which means that the eventual complete "class" hierarchy, once support for all past and present hw is in place, becomes: + msm_gpu + adreno_gpu + a3xx_gpu + a2xx_gpu + z180_gpu This commit splits out the parts that will eventually be common between a2xx/a3xx into adreno_gpu, and the parts that are even common to z180 into msm_gpu. Note that there is no cmdstream validation required. All memory access from the GPU is via IOMMU/MMU. So as long as you don't map silly things to the GPU, there isn't much damage that the GPU can do. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
The snapdragon chips have multiple different display controllers, depending on which chip variant/version. (As far as I can tell, current devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And then external to the display controller are HDMI, DSI, etc. blocks which may be shared across devices which have different display controller blocks. To more easily add support for different display controller blocks, the display controller specific bits are split out into a "kms" module, which provides the kms plane/crtc/encoder objects. The external HDMI, DSI, etc. blocks are part encoder, and part connector currently. But I think I will pull in the drm_bridge patches from chromeos tree, and split them into a bridge+connector, with the registers that need to be set in modeset handled by the bridge. This would remove the 'msm_connector' base class. But some things need to be double checked to make sure I could get the correct ON/OFF sequencing.. This patch adds support for mdp4 crtc (including hw cursor), dtv encoder (part of MDP4 block), and hdmi. Signed-off-by: NRob Clark <robdclark@gmail.com>
-