summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
| * drm/amdgpu/soc15: Fix static checker warningsAlex Deucher2017-04-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | vega10 is the only soc15 asic at the moment so these warnings are invalid, but add a default case to silence the warnings. Fixes: 220ab9bd1ccf: "drm/amdgpu: soc15 enable (v3)" Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/amdgpu: Read vram width from integrated system info tableHarry Wentland2017-04-044-82/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On KB, KV, CZ we should read the vram width from integrated system table, if we can. The NOOFCHAN in MC_SHARED_CHMAP is not accurate. With this change we can enable two 4k displays on CZ again. This use case was broken sometime in January when we started looking at vram_width for bandwidth calculations instead of hardcoding this value. v2: Return 0 if integrated system info table is not available. Tested-by: Roman Li <roman.li@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/amdgpu: create a func to check vm sizeZhang, Jerry2017-04-041-20/+31
| | | | | | | | | | | | | | | | | | break it out from the check parameters function. Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/amdgpu: Fix a NULL deref in amdgpu_vm_add_prt_cb()Dan Carpenter2017-04-041-1/+1
| | | | | | | | | | | | | | | | | | | | We accidentally dereference "cb" if the kmalloc() fails. Fixes: 451bc8eb8fe6 ("drm/amdgpu: fix PRT teardown on VM fini v3") Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/amd/powerplay: fix a couple locking issuesDan Carpenter2017-04-041-2/+4
| | | | | | | | | | | | | | | | | | We should return unlock on the error path in pp_dpm_dispatch_tasks() and there is a double lock bug in pp_dpm_set_sclk_od(). Fixes: 2a5071056e6a ("drm/amd/powerplay: add global PowerPlay mutex.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/amd/powerplay: fix pp_dpm_get_current_power_state() (v2)Dan Carpenter2017-04-041-0/+4
| | | | | | | | | | | | | | | | | | | | This switch statement is missing breaks. v2: agd: break in default case as well Fixes: 2a5071056e6a ("drm/amd/powerplay: add global PowerPlay mutex.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/amdgpu: various cleanups for uvd/vce.Rex Zhu2017-04-047-103/+22
| | | | | | | | | | | | Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/amdgpu: when resume failed, return error to avoid system hang.Rex Zhu2017-04-041-2/+3
| | | | | | | | | | | | | | | | Continuing if the GPU fails to resume will end in pain. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/amdgpu: use a 64bit interval tree for VM management v2Christian König2017-04-047-62/+71
| | | | | | | | | | | | | | | | | | | | | | | | This only makes a difference for 32-bit systems. The idea is to have a fixed virtual address space size with 4-level page tables and to minimize differences between 32 and 64-bit systems. v2: Update commit message. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/amdgpu: fix semicolon.cocci warningskbuild test robot2017-04-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:133:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Acked-by: Huang Rui <ray.huang@amd.com> CC: Huang Rui <ray.huang@amd.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/amdgpu/powerplay: fix locking typoAlex Deucher2017-04-041-1/+1
| | | | | | | | | | | | | | | | Fixes: 2a5071056e6a601e ("drm/amd/powerplay: add global PowerPlay mutex.") Reported-by: Julia Lawall <julia.lawall@lip6.fr> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into ↵Dave Airlie2017-04-076-25/+154
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm-next Highlights: - Cooling device support from Russell, to allow GPU throttling on system thermal overload. - Explicit fencing support from Philipp, implemented in a similar way to drm/msm. * 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux: drm/etnaviv: submit support for out-fences drm/etnaviv: return GPU fence through the submit structure drm/etnaviv: submit support for in-fences drm/etnaviv: add etnaviv cooling device drm/etnaviv: switch to postclose drm/etnaviv: add lockdep assert to fence allocation
| * | drm/etnaviv: submit support for out-fencesPhilipp Zabel2017-03-292-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on commit 4cd0945901a6 ("drm/msm: submit support for out-fences"). We increment the minor driver version so userspace can detect explicit fence support. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> --- v3: Changed to work with fence returned from GPU submit.
| * | drm/etnaviv: return GPU fence through the submit structureLucas Stach2017-03-293-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The next patch will need the complete dma_fence, instead of just the seqno, to create the sync_file in etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested. The submit needs to hold a reference to the dma_fence, to avoid raceing with the GPU completing the fence. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> --- New patch in v3.
| * | drm/etnaviv: submit support for in-fencesPhilipp Zabel2017-03-295-3/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Loosely based on commit f0a42bb5423a ("drm/msm: submit support for in-fences"). Unfortunately, struct drm_etnaviv_gem_submit doesn't have a flags field yet, so we have to extend the structure and trust that drm_ioctl will clear the flags for us if an older userspace only submits part of the struct. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Reviewed-by: Sumit Semwal <sumit.semwal@linaro.org> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
| * | drm/etnaviv: add etnaviv cooling deviceRussell King2017-03-292-15/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each Vivante GPU contains a clock divider which can divide the GPU clock by 2^n, which can lower the power dissipation from the GPU. It has been suggested that the GC600 on Dove is responsible for 20-30% of the power dissipation from the SoC, so lowering the GPU clock rate provides a way to throttle the power dissiptation, and reduce the temperature when the SoC gets hot. This patch hooks the Etnaviv driver into the kernel's thermal management to allow the GPUs to be throttled when necessary, allowing a reduction in GPU clock rate from /1 to /64 in power of 2 steps. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
| * | drm/etnaviv: switch to postcloseDaniel Vetter2017-03-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I didn't spot anything that would require ordering here (well not anywhere else either), and I'm trying to unify at least modern drivers on one close hook. Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
| * | drm/etnaviv: add lockdep assert to fence allocationLucas Stach2017-03-291-0/+6
| | | | | | | | | | | | | | | | | | | | | Make sure the GPU lock is taken, so that fence completion order matches seqno order. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
* | | Merge tag 'imx-drm-next-2017-04-04' of ↵Dave Airlie2017-04-077-19/+30
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.pengutronix.de/git/pza/linux into drm-next imx-drm module/dependency changes - The PRE/PRG drivers added an unwanted DRM dependency to the ipu-v3 driver. Remove the dependency by conditionally disabling PRE/PRG support depending on CONFIG_DRM. - Merge the imx-ipuv3-crtc module into the imxdrm module. There is no reason anymore for a separation between core drm driver and crtc/plane drivers, especially since commit eb8c88808c83 ("drm/imx: add deferred plane disabling"), which added a dependency on imx-ipuv3-crtc to the imxdrm module. * tag 'imx-drm-next-2017-04-04' of git://git.pengutronix.de/git/pza/linux: drm/imx: merge imx-drm-core and ipuv3-crtc in one module gpu: ipu-v3: don't depend on DRM being enabled
| * | | drm/imx: merge imx-drm-core and ipuv3-crtc in one moduleLucas Stach2017-04-045-17/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While it is possible to hook other CRTC implementations into imx-drm in practice there are none yet and the option to disable ipuv3-crtc support has been hidden for a long time. Now that the imx-drm-core has learned to deal with some of the specifics of IPUv3 there is a cyclic dependency between both parts. To get rid of this and to decimate the Kconfig maze a bit, simply merge both parts into one module. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
| * | | gpu: ipu-v3: don't depend on DRM being enabledLucas Stach2017-04-042-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PRE/PRG drivers, which need the DRM infrastructure, are only used from the output path, so we skip building them into the ipu-v3 driver if CONFIG_DRM is not enabled. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
* | | | drm/nouveau/gpio: enable interrupts on cards with 32 gpio linesAdam Borowski2017-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code attempts to enable them, but hits an undefined behaviour by shifting by the entire register's width: int lines = 32; u32 mask = (1 << lines) - 1; // 00000000 on x86 u32 mask = (1 << lines) - 1; // ffffffff on arm (32) u32 mask = (1 << lines) - 1; // 00000000 on arm64 u32 mask = (1ULL << lines) - 1; // ffffffff everywhere Signed-off-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/gr/gp107: initial supportBen Skeggs2017-04-069-8/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Forked from GP106 implementation. Differences: - 1 PPC/GPC - Slightly different grctx magics Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/core: recognise GP10B chipsetAlexandre Courbot2017-04-061-0/+24
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/platform: support for probing GP10BAlexandre Courbot2017-04-061-0/+10
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/platform: make VDD regulator optionalAlexandre Courbot2017-04-063-9/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GP10B's power is managed by generic PM domains, so it does not require a VDD regulator. Add this option into the chip function structure. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/gr: support for GP10BAlexandre Courbot2017-04-066-2/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GR is similar to GP100, with a few unavailable registers. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/ibus: add GP10B supportAlexandre Courbot2017-04-063-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GP10B requires a specific initialization sequence due to the absence of devinit. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/mc: add GP10B supportAlexandre Courbot2017-04-065-5/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GP10B's MC is compatible with GP100's, but engines need to be explicitly put out of ELPG during init. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/fb: add GP10B supportAlexandre Courbot2017-04-063-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GP10B's FB is largely compatible with the GP100 implementation. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/fifo: add GP10B supportAlexandre Courbot2017-04-065-1/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GP10B's FIFO is similar to GP100's, but only allows 512 channels. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/msgqueue: support for GP10B PMU firmwareAlexandre Courbot2017-04-063-0/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GP10B firmware is very close to GM20B's. The only difference is that it supports booting multiple falcons. In order to avoid having too much functions and structures shared, implement its support in the same source file as GM20B firmware. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/secboot: add GP10B supportAlexandre Courbot2017-04-063-0/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GP10B's secboot is largely similar to GM20B's. Only differences are MC base address and the fact that GPCCS is also securely managed. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/secboot/gm20b: specify MC base address as argumentAlexandre Courbot2017-04-062-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow the MC base address to be specified as an argument for the WPR region reading function. GP10B uses a different address layout as GM20B, so this is necessary. Also export the function to be used by GP10B. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/secboot: start LS firmware in post-run hookAlexandre Courbot2017-04-062-49/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LS firmware post-run hook is the right place to start said LS firmware. Moving it here also allows to remove special handling in the ACR code. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/secboot: let LS post_run hooks return errorAlexandre Courbot2017-04-064-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A LS post-run hook can meet an error meaning the failure of secure boot. Make sure this can be reported. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/secboot: pass instance to LS firmware loadersAlexandre Courbot2017-04-0612-39/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having access to the secboot instance loading a LS firmware can be useful to LS firmware handlers. At least more useful than just having an out-of-context subdev pointer. GP10B's firmware will also need to know the WPR address, which can be obtained from the secboot instance. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/secboot: allow to boot multiple falconsAlexandre Courbot2017-04-068-28/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the secboot and msgqueue interfaces to take a mask of falcons to reset instead of a single falcon. The GP10B firmware interface requires FECS and GPCCS to be booted in a single firmware command. For firmwares that only support single falcon boot, it is trivial to loop over the mask and boot each falcons individually. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/imem/gk20a: Turn instmem lock into mutexThierry Reding2017-04-061-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gk20a implementation of instance memory uses vmap()/vunmap() to map memory regions into the kernel's virtual address space. These functions may sleep, so protecting them by a spin lock is not safe. This triggers a warning if the DEBUG_ATOMIC_SLEEP Kconfig option is enabled. Fix this by using a mutex instead. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau: initial support (display-only) for GP107Ben Skeggs2017-04-061-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Forked from GP106 implementation. Split out from commit enabling secboot/gr support so that it can be added to earlier kernels. Cc: stable@vger.kernel.org [4.10+] Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/kms/nv50: fix double dma_fence_put() when destroying plane stateBen Skeggs2017-04-061-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the atomic support was added to nouveau, the DRM core did not do this. However, later in the same merge window, a commit (drm/fence: add in-fences support) was merged that added it, leading to use-after-frees of the fence object. Cc: stable@vger.kernel.org [4.10+] Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/kms/nv50: fix setting of HeadSetRasterVertBlankDmi methodBen Skeggs2017-04-061-3/+5
| | | | | | | | | | | | | | | | | | | | Cc: stable@vger.kernel.org [4.10+] Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 oneIlia Mirkin2017-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP and PCI varieties, rather than a core PCIE chip with a bridge for AGP/PCI as necessary. As a result, it appears that the MMU is also non-functional. For AGP cards, the vast majority of the NV4A lineup, this worked out since we force AGP cards to use the nv04 mmu. However for PCI variants, this did not work. Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for the suggestion. This should be a no-op for NV4A AGP boards, as they were using it already. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm/nouveau/mpeg: mthd returns true on success nowIlia Mirkin2017-04-062-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Fixes: 590801c1a3 ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup") Cc: stable@vger.kernel.org # v4.3+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | drm: rcar-du: Add HDMI outputs to R8A7795 device descriptionKoji Matsuoka2017-04-042-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the device description with the two available HDMI outputs. Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* | | | drm: rcar-du: Add DPLL supportKoji Matsuoka2017-04-044-1/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The implementation hardcodes a workaround for the H3 ES1.x SoC regardless of the SoC revision, as the workaround can be safely applied on all devices in the Gen3 family without any side effect. Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* | | | drm: rcar-du: Skip disabled outputsLaurent Pinchart2017-04-041-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When a DT node connected to a DU output is disabled no bridge will ever be instantiated for it. Skip the output in that case. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* | | | drm: rcar-du: Add Gen3 HDMI encoder supportKoji Matsuoka2017-04-043-0/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The R-Car Gen3 SoCs include on-chip DesignWare HDMI encoders. Support them with a platform driver to provide platform glue data to the dw-hdmi driver. The driver is a complete rewrite of code coming from the Renesas BSP, save for the values in the PHY parameters table. Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
* | | | drm: rcar-du: Hardcode encoders types to DRM_MODE_ENCODER_NONELaurent Pinchart2017-04-045-82/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unlike the connector type, the encoder type is unused by userspace. As it is equally unused in the driver, except in a single location where the connector type can be used instead, hardcode it to DRM_MODE_ENCODER_NONE. This allow removing all code that tries to determine (unsuccessfully in case a bridge is used) the encoder type. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* | | | drm: rcar-du: Replace manual bridge implementation with DRM bridgeLaurent Pinchart2017-04-048-331/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The rcar-du driver contains a manual implementation of HDMI and VGA bridges. Use DRM bridges to replace it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-19 15:39:02 +0000