The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In case of error, the function drm_mode_duplicate() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

This patch adds support to generic audio codec via
ASoC hdmi-codec infrastucture which is merged recently.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
[rebased on efc9194b]
Signed-off-by: NRob Clark <robdclark@gmail.com>

By default, if using $debugfs/.../rd to log cmdstream, only the
cmdstream buffers themselves are logged.  But in some cases we want
to capture other buffers in the submit (to see VBO's or shaders).
So add a mod-param knob to control this.
Signed-off-by: NRob Clark <robdclark@gmail.com>

(reduce the noise in next patch)
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>

For some optimizations coming on the userspace side, splitting larger
draw or gmem cmds into multiple cmdstream buffers, we need to support
much more than the previous small/arbitrary limit.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>

Before we can add vmap shrinking, we really need to know which vmap'ings
are currently being used.  So switch to get/put interface.  Stubbed put
fxns for now.
Signed-off-by: NRob Clark <robdclark@gmail.com>

For a first step, only purge obj->madv==DONTNEED objects.  We could be
more agressive and next try unpinning inactive objects..  but that is
only useful if you have swap.
Signed-off-by: NRob Clark <robdclark@gmail.com>

We'll need this too for shrinker/purging.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Doesn't do anything too interesting until we wire up shrinker.  Pretty
much lifted from i915.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Be kinder to things that do lots of signal handling (ie. Xorg)
Signed-off-by: NRob Clark <robdclark@gmail.com>

The DSI host and PHY driver currently expects the DT bindings to provide
custom properties "qcom,dsi-host-index" and "qcom,dsi-phy-index" so that
the driver can identify which DSI instance it is.

The binding isn't acceptable, but the driver still needs to figure out
what its instance id. This is now done by storing the mmio starting
addresses for each DSI instance in every SoC version in the driver. The
driver then identifies the index number by trying to match the stored
address with comparing the resource start address we get from DT.

We don't have compatible strings for DSI PHY on each SoC, but only the
DSI PHY type. We only support one SoC version for each PHY type, so we
get away doing the same thing above for the PHY driver. We can revisit
this when we support two SoCs with the same DSI PHY.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Introduce new compatible strings for the top level MDSS wrapper device,
and the MDP5 device.

Previously, the "qcom,mdp5" and "qcom,mdss_mdp" compatible strings
were used to match the top level platform_device (which was also tied
to the top level drm_device struct). Now, these strings are used
to match the MDP5 platform device.

Use "qcom,mdss" as the compatible string for top level MDSS device.
This is now used to match the top level platform_device (which is
tied to the drm_device struct).
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The driver currently identifies the GPU components it needs by parsing
a phandle list from the 'gpus' DT property.

This isn't the right binding to go with. So, for now, just search all
device nodes and find the gpu node we need by parsing a list of
compatible strings.

Once we know how to link the kms and gpu drivers, we'll drop this method
and use the correct binding.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

For MDP5 based platforms, the master device isn't the MDP5 platform
device, but the top level MDSS device, which is a parent to MDP5 and
interface (DSI, HDMI, eDP etc) devices.

In order to add components on MDP5 platforms, we first need to populate
the MDSS children, locate the MDP5 child, and then parse its ports to
get the display interfaces.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The kms driver currently identifies all the mdss components it needs by
parsing a phandle list from the 'connectors' DT property.

Instead of this, describe a list of ports that the MDP hardware provides
to the external world. These ports are linked to external encoder
interfaces such as DSI, HDMI. These are also the subcomponent devices
that we need add. This description of ports complies with the generic
graph bindings.

The LVDS port is a special case since it is a part of MDP4 itself, and
its output connects directly to the LVDS panel. In this case, we don't
try to add it as a component.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Simplifies some of the code that we'll add later.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Since runtime PM isn't implemented yet, we need to call
mdp5_enable/disable in a few more places. These would later be
replaced by runtime PM get/put calls.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

With the new device hierarchy for MDP5, we need to enable runtime PM
for both the toplevel MDSS device and the MDP5 device itself. Enable
runtime PM for the new devices.

Since MDP4 and MDP5 now have different places where runtime PM is
enabled, remove the previous pm_runtime_enable/disable calls, and
squash them in the respective kms drivers.

The new device hierarchy (as expressed in the DT bindings) has the GDSC
tied only to the MDSS wrapper device. This GDSC needs to be enabled for
accessing any register in the MDSS sub-blocks. Once every driver is
runtime adapted, the GDSC will be enabled when any sub-block device
calls runtime_get because of the parent-child relationship with MDSS.

Until then, we call pm_runtime_get_sync() once for the MDSS device to
ensure the GDSC is never disabled. This will be removed once all the
drivers are runtime PM adapted.

The error handling paths become a bit tricky when we call these runtime
PM funcs. There doesn't seem to be any helper that checks if runtime PM
is enabled already. Add bool variables in mdp4_kms/mdp5_kms structs to
check if the driver had managed to call pm_runtime_enable before bailing
out.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The MDP5 sub-block register offsets are relative to the top level
MDSS register address.

Now that we have the start of MDP5 register address space, provide
the offsets relative to that. This involves subtracting the offsets
with 0x1000 or 0x100 depending on the MDP5 version.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Since MDSS registers were stuffed within the the MDP5 register
space, we had an __offset_MDP() macro to identify the offset
between the start of MDSS and MDP5 address spaces. This offset
macro expected a MDP index argument, which didn't make much
sense since we don't have multiple MDPs.

The offset is no longer needed now that we have devices for the 2
different register address spaces. Also, remove the "REG_MDP5_MDP_"
prefix to "REG_MDP5_".

Update the generated headers in mdp5.xml.h

We generally update headers as a separate patch, but we need to
do these together to prevent breaking build.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

With the new kms_init/destroy funcs in place for MDP5, we can get rid of
the old kms funcs. Some members of the mdp5_kms struct also become
redundant, so we remove those too.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Call msm_mdss_init in msm_drv to set up top level registers/irq line.
Start using the new kms_init2/destroy2 funcs to inititalize MDP5 KMS.

With the MDSS interrupt and irqdomain set up, the old MDP5 irq code
can be dropped.

The mdp5_hw_init kms func now uses the platform device tied to MDP5
instead of the one tied to the drm_device/MDSS.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

With MDP5 as a new device, we need to do less for MDP when initializing
modeset after all the components are bound.

Create mdp5_kms_init2/destroy2 funcs that inits modeset. These will
eventually replace the older kms_init/destroy funcs.

In the new kms_init2, the platform_device used is the one corresponding
to the new MDP5 platform_device. The new change here is that the irq is
now retrieved using irq_of_parse_and_map(), since MDP5 is a child interrupt
of the MDSS interrupt controller.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In order to have a tree-like device hierarchy between MDSS and its
sub-blocks (MDP5, DSI, HDMI, eDP etc), we need to create a separate
device/driver for MDP5. Currently, MDP5 and MDSS are squashed
together are are tied to the top level platform_device, which is
also the one used to create drm_device.

The mdp5_kms_init code is split into two parts. The part where device
resources are allocated are associated with the MDP5 driver's probe,
the rest is executed later when we initialize modeset.

With this change, unlike MDP4, the MDP5 platform_device isn't tied to
the top level drm_device anymore. The top level drm_device is now
associated with a platform device that corresponds to MDSS wrapper
hardware.

Create mdp5_init/destroy funcs that will be used by the MDP5 driver
probe/remove. Use the HW_VERSION register in the MDP5 register address
space. Both the MDSS and MDP VERSION registers give out identical
version info.

The older mdp5_kms_init code is left as is for now, this would be removed
later when we have all the pieces to support the new device hierarchy.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

SoCs that contain MDP5 have a top level wrapper called MDSS that manages
clocks, power and irq for the sub-blocks within it.

Currently, the MDSS portions are stuffed into the MDP5 driver. This makes
it hard to represent the DT bindings in the correct way. We create a top
level MDSS helper that handles these parts. This is essentially moving out
some of the mdp5_kms irq code and MDSS register space and keeping it as a
separate entity. We haven't given any clocks to the top level MDSS yet,
but a AHB clock would be added in the future to access registers.

One thing to note is that the resources allocated by this helper are
tied to the top level platform_device (the one that allocates the
drm_device struct too). This device would be the parent to MDSS
sub-blocks like MDP5, DSI, eDP etc.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The driver gets the irq number using platform_get_irq on the main kms
platform device. This works fine since both MDP4 and MDP5 currently
have a flat device hierarchy. The platform device tied with the
drm_device points to the MDP DT node in both cases.

This won't work when MDP5 supports a tree-like hierarchy. In this
case, the platform device tied to the top level drm_device is the
MDSS DT node, and the irq we need for KMS is the one generated by
MDP5, not MDSS.

Get the irq number from the MDP4/5 kms driver itself. Each driver
can later provide the irq number based on what device hierarchy it
uses.

While we're at it, call drm_irq_install only when we have a valid KMS
driver.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

These aren't used. Probably left overs when driver was refactored to
support both MDP4 and MDP5.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

This isn't needed as we only support OF.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

A more standard DT binding describing data lanes already exists here:
Documentation/devicetree/bindings/media/video-interfaces.txt

Use this binding instead of "qcom,data-lane-map". One difference
in the standard binding w.r.t to the existing binding is that it
provides a logical to physical mapping instead of the other way
round. Tweak the code to translate the data the way we want it.

The MSM DSI DT bindings aren't used anywhere at the moment, so
it's okay to update this property.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The DSI host links to the DSI PHY device using a custom binding. Switch to
the generic PHY bindings. The DSI PHY driver itself doesn't use the common
PHY framework for now.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The DSI interface is going to have two ports defined in its device node.
The first port is always going to be the link between the MDP output
and the input to DSI, the second port is going to be the link between
the DSI output and the connected panel/bridge:

 -----           -----           -------
| MDP | ------> | DSI | ------> | Panel |
 -----           -----           -------
        (Port 0)       (Port 1)

Until now, there was only one Port representing the output. Update the
DSI host driver such that it parses Port #1 for a connected device.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

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: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

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: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

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: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

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: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We already have a fallback in place to fill out the unique from
dev->unique, which is set to something reasonable in drm_dev_alloc.

Which means we only need to have a special set_busid for pci devices,
to be able to care the backwards compat code for drm 1.1 around, which
libdrm still needs.

While developing and testing this patch things blew up in really
interesting ways, and the code is rather confusing in naming things
between the kernel code, ioctl #defines and libdrm. For the next brave
dragon slayer, document all this madness properly in the userspace
interface section of gpu.tmpl.

v2: Make drm_dev_set_unique static and update kerneldoc.

v3: Entire rewrite, plus document what's going on for posterity in the
gpu docbook uapi section.

v4: Drop accidental amdgpu hunk (Emil).

v5: Drop accidental omapdrm vblank counter change (Emil).

v6: Rebase on top of the sphinx conversion.

Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> (virt_gpu)
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility issues with drivers not following the
more rigorous init ordering.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rob Clark <robdclark@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Tested-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466151923-1572-7-git-send-email-chris@chris-wilson.co.uk