summaryrefslogtreecommitdiffstats
path: root/Documentation/Makefile.sphinx (unfollow)
Commit message (Collapse)AuthorFilesLines
2016-07-16drm/msm/mdp4: Clean up some MDP4 clocksArchit Taneja2-20/+13
Fix some issues with MDP4 clocks: - mdp4_dtv_encoder tries to get "src_clk", which is a RCG(TV_SRC) in MSM8960 and APQ8064. This isn't something the driver should access or configure. Instead of this, configure the "mdp_clk" (MDP_TV_CLK), a branch clock in MMCC that has the TV_SRC as its parent. Setting rate/enabling the "mdp_clk" will eventually configure "src_clk", which is what we want. - Rename "mdp_clk" to "tv_clk" because that's slightly less confusing. - Rename "mdp_axi_clk" to "bus_clk" because that's what we do elsewhere too. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-07-16drm/msm/mdp5: Don't get source of MDP core clockArchit Taneja2-6/+2
The driver expects DT to provide the parent to MDP core clock. The only operation done to the parent clock is to set a rate. This can be achieved by setting the rate on the core clock itsef. Don't try to get the parent clock anymore. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-07-16drm/msm: Print the correct virtual addresses in map/unmap funcsArchit Taneja1-2/+2
The msm_iommu_map/unmap funcs have debug prints to show the list of VA:PA mappings. Use the correct variable to print the VAs. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-07-16drm/msm: Use correct type for physical addressesArchit Taneja1-2/+2
The u32 type used to pass the physical addresses to iommu_map can't accommodate 64 bit addresses. Move to dma_addr_t to ensure wrong addresses aren't provided to the IOMMU driver. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-07-16drm/vc4: Fix a "the the" typo in a comment.Eric Anholt1-1/+1
Signed-off-by: Eric Anholt <eric@anholt.net>
2016-07-16drm/vc4: Fix definition of QPU_R_MS_REV_FLAGSEric Anholt1-1/+1
We don't use it in shader validation currently, so it had no effect, but best to fix it anyway in case we do some day. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-07-16drm/vc4: Add a getparam to signal support for branches.Eric Anholt2-0/+4
Userspace needs to know if it can create shaders that do branching. Otherwise, for backwards compatibility with old kernels it needs to lower if statements to conditional assignments. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-07-16drm/vc4: Add support for branching in shader validation.Eric Anholt4-17/+283
We're already checking that branch instructions are between the start of the shader and the proper PROG_END sequence. The other thing we need to make branching safe is to verify that the shader doesn't read past the end of the uniforms stream. To do that, we require that at any basic block reading uniforms have the following instructions: load_imm temp, <next offset within uniform stream> add unif_addr, temp, unif The instructions are generated by userspace, and the kernel verifies that the load_imm is of the expected offset, and that the add adds it to a uniform. We track which uniform in the stream that is, and at draw call time fix up the uniform stream to have the address of the start of the shader's uniforms at that location. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-07-16drm/vc4: Add a bitmap of branch targets during shader validation.Eric Anholt2-2/+124
This isn't used yet, it's just a first step toward loop validation. During the main parsing of instructions, we need to know when we hit a new basic block so that we can reset validated state. v2: Fix a stray semicolon after an if block. (caught by kbuild test). Signed-off-by: Eric Anholt <eric@anholt.net>
2016-07-14drm/vc4: Move validation's current/max ip into the validation struct.Eric Anholt1-24/+30
Reduces the argument count for some of the functions, and will be used more with the upcoming looping support. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-07-14drm/vc4: Add a getparam ioctl for getting the V3D identity regs.Eric Anholt2-0/+54
As I extend the driver to support different V3D revisions, userspace needs to know what version it's targeting. This is most easily detected using the V3D identity registers. v2: Make sure V3D is runtime PM on when reading the registers. v3: Switch to a 64-bit param value (suggested by Rob Clark in review) Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2) Reviewed-by: Rob Clark <robdclark@gmail.com> (v3, over irc)
2016-07-14drm/tegra: sor: Reject HDMI 2.0 modesThierry Reding1-0/+4
Enabling HDMI 2.0 modes requires extra programming and will not work with the current driver, so reject all those modes. Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-07-14drm/tegra: sor: Prepare for generic PM domain supportJon Hunter1-22/+35
The SOR driver for Tegra requires the SOR power partition to be enabled. Now that Tegra supports the generic PM domain framework we manage the SOR power partition via this framework. However, the sequence for gating/ungating the SOR power partition requires that the SOR reset is asserted/de-asserted at the time the SOR power partition is gated/ungated, respectively. Now that the reset control core assumes that resets are exclusive, the Tegra generic PM domain code and the SOR driver cannot request the same reset unless we mark the reset as shared. Sharing resets will not work in this case because we cannot guarantee that the reset will be asserted/de-asserted at the appropriate time. Therefore, given that the Tegra generic PM domain code will handle the resets, do not request the reset in the SOR driver if the SOR device has a PM domain associated. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-07-14drm/tegra: dsi: Prepare for generic PM domain supportJon Hunter1-11/+17
The DSI driver for Tegra requires the SOR power partition to be enabled. Now that Tegra supports the generic PM domain framework we manage the SOR power partition via this framework. However, the sequence for gating/ungating the SOR power partition requires that the DSI reset is asserted/de-asserted at the time the SOR power partition is gated/ungated, respectively. Now that the reset control core assumes that resets are exclusive, the Tegra generic PM domain code and the DSI driver cannot request the same reset unless we mark the reset as shared. Sharing resets will not work in this case because we cannot guarantee that the reset will be asserted/de-asserted at the appropriate time. Therefore, given that the Tegra generic PM domain code will handle the resets, do not request the reset in the DSI driver if the DSI device has a PM domain associated. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-07-14drm/tegra: sor: Make XBAR configurable per SoCThierry Reding1-13/+28
Provide a per-SoC mapping of lanes which can be used to configure the XBAR. Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-07-14drm/tegra: sor: Use sor1_src clock to set parent for HDMIThierry Reding1-1/+16
When running in HDMI mode, the sor1 IP block needs to use the sor1_src as parent clock, and in turn configure the sor1_src to use pll_d2_out0 as its parent. Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-07-14dt-bindings: display: tegra: Add source clock for SORThierry Reding1-0/+1
The SOR clock can have various sources, with the most commonly used being the sor_safe, pll_d2_out0, pll_dp and sor_brick clocks. These are configured using a three level mux, of which the first 2 levels can be treated as one. The direct parents of the SOR clock are the sor_safe, sor_brick and sor_src clocks, whereas the pll_d2_out0 and pll_dp clocks can be selected as parents of the sor_src clock via a second mux. Previous generations of Tegra have only supported eDP and LVDS with the SOR, where LVDS was never used on publicly available hardware. Clocking for this only ever required the first level mux (to select between sor_safe and sor_brick). Tegra210 has a new revision of the SOR that supports HDMI and hence needs to support the second level mux to allow selecting pll_d2_out0 as the SOR clock's parent. This second mux is knows as sor_src, and operating system software needs a reference to it in order to select the proper parent. Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-07-14drm/tegra: sor: Implement sor1_brick clockThierry Reding1-0/+107
sor1_brick is a clock that can be used as a source for the sor1 clock. The registers to control the clock output are part of the sor1 IP block and hence the sor driver is the best place to implement it. Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-07-14drm/imx: parallel-display: add bridge supportPhilipp Zabel1-9/+41
Add support for bridge chips connected externally to the i.MX DISP0/DISP1 DPI interfaces. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-07-14drm: Don't overwrite user ioctl arg unless requestedChris Wilson1-28/+22
Currently, we completely ignore the user when it comes to the in/out direction of the ioctl argument, as we simply cannot trust userspace. (For example, they might request a copy of the modified ioctl argument when the driver is not expecting such and so leak kernel stack.) However, blindly copying over the target address may also lead to a spurious EFAULT, and a failure after the ioctl was completed successfully. This is important in order to avoid an ABI break when extending an ioctl from IOR to IORW. Similar to how we only copy the intersection of the kernel arg size and the user arg size, we only want to copy back the kernel arg data iff both the kernel and userspace request the copy. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1468335590-21023-1-git-send-email-chris@chris-wilson.co.uk
2016-07-14drm/nouveau/bus: remove cpu_coherent flagAlexandre Courbot4-5/+1
This flag's only remaining function is to ignore the uncached flag for BOs on coherent architectures. However the reason for allocating an object uncache on a non-coherent architecture (namely because the cost of doing explicit flushes/ invalidations is higher than the benefit of caching the data because accesses are few and far between) should also apply on architectures for which coherency is maintained implicitly. Thus allocate coherent objects as uncached on all architectures. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ttm: remove special handling of coherent objectsAlexandre Courbot1-56/+5
TTM-allocated coherent objects were populated using the DMA API and accessed using the mapping it returned to workaround coherency issues. These issues seem to have been solved, thus remove this extra case to handle and use the regular kernel mapping functions. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau: check for supported chipset before booting fbdev off the hwBen Skeggs1-1/+10
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2016-07-14drm/nouveau/ce/gp104: initial supportBen Skeggs7-0/+54
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fifo/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/disp/gp104: initial supportBen Skeggs25-5/+394
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/dma/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ltc/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ibus/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/i2c/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/gpio/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fuse/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bus/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bar/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/mmu/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fb/gp104: initial supportBen Skeggs6-1/+49
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/imem/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/devinit/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bios/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/tmr/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/pci/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/mc/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/top/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/core: recognise GP104 chipsetBen Skeggs1-0/+6
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/sw/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/gr/gp100: initial supportBen Skeggs9-1/+362
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ce/gp100: initial supportBen Skeggs6-0/+113
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fifo/gp100: initial supportBen Skeggs9-1/+110
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/disp/gp100: initial supportBen Skeggs11-0/+162
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/dma/gp100: initial implementationBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>