Backmerge the main pull request to sync up with all the newly landed
drivers. Otherwise we'll have chaos even before 4.12 started in
earnest.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Extend the DSI PHY/PLL drivers to support the DSI 14nm PHY/PLL
found on 8x96.
These are picked up from the downstream driver. The PHY part is similar
to the other DSI PHYs. The PLL driver requires some trickery so that
one DSI PLL can drive both the DSIs (i.e, dual DSI mode).
In the case of dual DSI mode. One DSI instance becomes the clock master,
and other the clock slave. The master PLL's output (Byte and Pixel clock)
is fed to both the DSI hosts/PHYs.
When the DSIs are configured in dual DSI mode, the PHY driver communicates
to the PLL driver using msm_dsi_pll_set_usecase() which instance is the
master and which one is the slave. When setting rate, the master PLL also
configures some of the slave PLL/PHY registers which need to be identical
to the master's for correct dual DSI behaviour.
There are 2 PLL post dividers that should have ideally been modelled as
generic clk_divider clocks, but require some customization for dual DSI.
In particular, when the master PLL's post-diviers are set, the slave PLL's
post-dividers need to be set too. The clk_ops for these use clk_divider's
helper ops and flags internally to prevent redundant code.
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The 14nm DSI PHY on 8x96 (called PHY v2 downstream) requires a different
set of calculations for computing D-PHY timing params. Create a
timing_calc_v2 func for the newer v2 PHYs.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since DSI PHY has been a separate platform device, it should not
depend on the resources in host to be functional. This change is
to trigger PHY operations in manager, instead of host, so that
host and PHY can be completely separated.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
In case of dual DSI, some registers in PHY1 have been programmed
during PLL0 clock's set_rate. The PHY1 reset called by host1 later
will silently reset those PHY1 registers. This change is to reset
and enable both PHYs before any PLL clock operation.
[Originally worked on by Hai Li <hali@codeaurora.org>. Fixed up
by Archit Taneja <architt@codeaurora.org>]
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
For some new types of DSI PHY, more settings depend on
use cases controlled by DSI manager. This change allows
DSI manager to setup PHY with a use case.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The DSI host is required to configure more timings calculated
in PHY. By introducing a shared structure, this change allows
more timing information passed from PHY to host.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Create an init() op for dsi_phy which sets up things specific to
a given DSI PHY.
The dsi_phy driver probe expects every DSI version to get a
"dsi_phy_regulator" mmio base. This isn't the case for 8x96.
Creating an init() op will allow us to accommodate such
differences.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add 8x96 DSI data in dsi_cfg. The downstream kernel's dsi_host driver
enables core_mmss_clk. We're seeing some branch clock warnings on
8x96 when enabling this. There doesn't seem to be any negative effect
with not enabling this clock, so use it once we figure out why we
get the warnings.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The driver returns an error if a DSI DT node is populated, but no device
is connected to it or if the data-lane map isn't present. Ideally, such
a DSI node shouldn't be probed at all (i.e, its status should be set to
"disabled in DT"), but there isn't any harm in registering the DSI device
even if it doesn't have a bridge/panel connected to it.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The mdp5 kms driver currently sets up multiple encoders per interface
(INTF), one for each kind of mode of operation it supports.
We create 2 drm_encoders for DSI, one for Video Mode and the other
for Command Mode operation. The reason behind this approach could have
been that we aren't aware of the DSI device's mode of operation when
we create the encoders.
This makes things a bit complicated, since these encoders have to
be further attached to the same DSI bridge. The easier way out is
to create a single encoder, and make the DSI driver set its mode
of operation when we know what the DSI device's mode flags are.
Start with providing a way to set the mdp5_intf_mode using a kms
func that sets the encoder's mode of operation. When constructing
a DSI encoder, we set the mode of operation to Video Mode as
default. When the DSI device is attached to the host, we probe the
DSI mode flags and set the corresponding mode of operation.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We currently create 2 encoders for DSI interfaces, one for command
mode and other for video mode operation. This isn't needed as we
can't really use both the encoders at the same time. It also makes
connecting bridges harder.
Switch to creating a single encoder. For now, we assume that the
encoder is configured only in video mode. Later, the same encoder
would be usable in both modes.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The commit "drm: bridge: Link encoder and bridge in core code" updated
the drm_bridge_attach() API to also include the drm_encoder pointer
the bridge attaches to.
The func msm_dsi_manager_bridge_init() now relies on the drm_encoder
pointer stored in msm_dsi->encoders to pass the encoder to the bridge
API.
msm_dsi->encoders is unfortunately set after this function is called,
resulting in us passing a NULL pointer to drm_brigde_attach. This
results in an error and the DSI driver probe fails.
Move the initialization of msm_dsi->encoders[] a bit up. Also, don't
try to set the encoder's bridge. That's now managed by the bridge
API.
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Instead of linking encoders and bridges in every driver (and getting it
wrong half of the time, as many drivers forget to set the drm_bridge
encoder pointer), do so in core code. The drm_bridge_attach() function
needs the encoder and optional previous bridge to perform that task,
update all the callers.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Stefan Agner <stefan@agner.ch> # For DCU
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> # For atmel-hlcdc
Acked-by: Vincent Abriou <vincent.abriou@st.com> # For STI
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> # For sun4i
Acked-by: Xinliang Liu <z.liuxinliang@hisilicon.com> # For hisilicon
Acked-by: Jyri Sarha <jsarha@ti.com> # For tilcdc
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-4-git-send-email-laurent.pinchart+renesas@ideasonboard.com
On the userspace side, all the basics are working, and most of glmark2
is working. I've been working through deqp, and I've got a couple more
things to fix (but we've gone from 70% to 80+% pass in last day, and
current deqp run that is going should pick up another 5-10%). I expect
to push the mesa patches today or tomorrow.
There are a couple more a5xx related patches to take the gpu out of
secure mode (for the devices that come up in secure mode, like the hw
I have), but those depend on an scm patch that would come in through
another tree. If that can land in the next day or two, there might
be a second late pull request for drm/msm.
In addition to the new-shiny, there have also been a lot of overlay/
plane related fixes for issues found using drm-hwc2 (in the process of
testing/debugging the atomic/kms fence patches), resulting in rework
to assign hwpipes to kms planes dynamically (as part of global atomic
state) and also handling SMP (fifo) block allocation atomically as
part of the ->atomic_check() step. All those patches should also help
out atomic weston (when those patches eventually land).
* 'msm-next' of git://people.freedesktop.org/~robclark/linux: (36 commits)
drm/msm: gpu: Add support for the GPMU
drm/msm: gpu: Add A5XX target support
drm/msm: Disable interrupts during init
drm/msm: Remove 'src_clk' from adreno configuration
drm/msm: gpu: Add OUT_TYPE4 and OUT_TYPE7
drm/msm: Add adreno_gpu_write64()
drm/msm: gpu Add new gpu register read/write functions
drm/msm: gpu: Return error on hw_init failure
drm/msm: gpu: Cut down the list of "generic" registers to the ones we use
drm/msm: update generated headers
drm/msm/adreno: move scratch register dumping to per-gen code
drm/msm/rd: support for 64b iova
drm/msm: convert iova to 64b
drm/msm: set dma_mask properly
drm/msm: Remove bad calls to of_node_put()
drm/msm/mdp5: move LM bounds check into plane->atomic_check()
drm/msm/mdp5: dump smp state on errors too
drm/msm/mdp5: add debugfs to show smp block status
drm/msm/mdp5: handle SMP block allocations "atomically"
drm/msm/mdp5: dynamically assign hw pipes to planes
...
For a5xx the gpu is 64b so we need to change iova to 64b everywhere. On
the display side, iova is still 32b so it can ignore the upper bits.
(Although all the armv8 devices have an iommu that can map 64b pa to 32b
iova.)
Signed-off-by: Rob Clark <robdclark@gmail.com>
The DSI/HDMI PLLs in MSM require resources like interface clocks, power
domains to be enabled before we can access their registers.
The clock framework doesn't have a mechanism at the moment where we can
tie such resources to a clock, so we make sure that the KMS driver enables
these resources whenever a PLL is expected to be in use.
One place where we can't ensure the resource dependencies are met is when
the clock framework tries to disable unused clocks. The KMS driver doesn't
know when the clock framework calls the is_enabled clk_op, and hence can't
enable interface clocks/power domains beforehand.
We set the CLK_IGNORE_UNUSED flag for PLL clocks for now. This needs to be
revisited, since bootloaders can enable display, and we would want to
disable the PLL clocks if there isn't a display driver using them.
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The msm/dsi host drivers calls drm_helper_hpd_irq_event in the
mipi_dsi_host attach/detatch callbacks.
mipi_dsi_attach()/mipi_dsi_detach() from a panel/bridge
driver could be called from a context where the drm_device's
mode_config.mutex is already held, resulting in a deadlock.
Queue it as work instead.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob 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: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob 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: Rob 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: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob 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: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob 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: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob 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: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Move the drm_connector registration from the encoder(HDMI/DSI etc) drivers
to the msm platform driver. This will simplify the task of ensuring that
the connectors are registered only after the drm_device itself is
registered.
The connectors' destroy ops are made to use kzalloc instead of
devm_kzalloc to ensure that that the connectors can be successfully
unregistered when the msm driver module is removed. The memory for the
connectors is unallocated when drm_mode_config_cleanup() is called
during either during an error or during driver remove.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The voltage changing code in this driver is broken and should be
removed. The driver sets a single, exact voltage on probe. Unless
there is a very good reason for this (which should be documented in
comments) constraints like this need to be set via the machine
constraints, voltage setting in a driver is expected to be used in cases
where the voltage varies at runtime.
In addition client drivers should almost never be calling
regulator_can_set_voltage(), if the device needs to set a voltage it
needs to set the voltage and the regulator core will handle the case
where the regulator is fixed voltage. If the driver simply skips
setting the voltage if it doesn't have permission then it should just
not bother in the first place.
Originally authored by Mark Brown <broonie@kernel.org>
Remove the min/max voltage data entries per SoC managed by the driver.
These aren't needed as we don't try to set voltages any more. Mention in
comments the voltages that each regulator expects.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This fixes the following build failure:
drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o: In function `msm_dsi_pll_28nm_8960_init':
dsi_pll_28nm.c:(.text+0x1198): multiple definition of `msm_dsi_pll_28nm_8960_init'
drivers/gpu/drm/msm/dsi/pll/dsi_pll.o:dsi_pll.c:(.text+0x0): first defined here
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The DSI driver is currently unaware of how the DSI physical data lanes
are mapped to the logical lanes provided by the DSI controller.
Create a DT binding "qcom,data-lane-map" that provides this information
on a given platform.
The MSM DSI controller is restricted in terms of what all mappings
it can support. The lane polarity is fixed for all the lanes, the clock
lanes are fixed, and the data lanes can be swapped among each other only
for a few combinations. Apply these restrictions when we parse the DT
data.
Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh@kernel.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
VDD regulator input was specified for MSM8916. It turns our that this
regulator is used for the display panels used on MSM8916 platforms, but
not the DSI controller itself. Drop this regulator from the list.
Reported-by: Vinay Simha <vinaysimha@inforcecomputing.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
With the implementation of of_graph parsing, it isn't any longer
necessary for msm_host->device node to be same as dsi->dev.of_node. This
only holds true when the connected device is also a child of the dsi_host.
In the case of external bridge chips belonging to a different control
bus, these are guaranteed to be different.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
in case of failed to get iova, function was returning without releasing
the mutex. Added it.
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
For DSIv2 to work, we need to enable MMSS_AHB_ARB_MASTER_PORT in
MMSS_SFPB. We enable the required bitfield by retrieving MMSS_SFPB
regmap pointer via syscon.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We currently use iommu allocated DMA buffers for sending DSI commands.
DSIv2 doesn't have a port connected to the MDP iommu. Therefore, it
can't use iommu allocated buffers to fetch DSI commands.
Use a regular contiguous DMA buffer if we are DSIv2.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a dsi_cfg entry for APQ8064. Since this is the first DSIv2 chip to
be supported, add a list of bus clocks that are required by the DSIv2
block.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
DSIv2 (DSI on older A family chips) has slightly different link clock
requirements.
First, we have an extra clock called src_clk (with a dedicated RCG).
This is required by the DSI controller to process the pixel data
coming from MDP. It needs to be set at the rate "pclk * bytes_per_pixel".
We also need to explicitly configure esc_clk. On DSI6G chips, we don't
need to set a rate to esc_clk because its RCG is always sourced from
crystal clock (19.2 Mhz in all cases), which is within the escape clock
frequency range in the mipi DSI spec. For chips with DSIv2, the crystal
clock rate may not be within the required range (27Mhz on APQ8064).
Therefore, we derive it from the DSI byte clock. We calculate an esc_clck
rate that is within the mipi spec and also divisible by the byte clock
rate.
When setting rate and enabling the link clocks, we make sure that byte_clk
is configured before esc_clk, and src_clk before pixel_clk. We create two
different link_enable funcs for DSI6G and DSIv2 since the sequences are
different.
We also obtain two extra source clocks (dsi_src_clk and esc_src_clk) and
set their parent to the clocks provided by DSI PLL.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
DSI bus clocks seem to vary between different DSI host versions, and the
SOC to which they belong. Even the enable/disable sequence varies.
Provide a list of bus clock names in dsi_cfg. The driver will use this to
retrieve the clocks, and enable/disable them.
Add bus clock lists for DSI6G, and DSI for MSM8916(this is DSI6G too, but
there is no MMSS_CC specific clock since there is no MMSS clock controller
on 8916).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Initialize clocks only after we get the DSI host version. This will allow
us to get clocks using a pre-defined list based on the DSI major/minor
version of the host. This is required since clock requirements of
different major DSI revisions(v2 vs 6g) aren't the same.
Modify dsi_get_version to get the interface clock, and then put it after
it is used.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The current version checking mechanism works fine for DSI6G blocks. It
doesn't work so well for older generation DSIv2 blocks.
The initial read of REG_DSI_6G_HW_VERSION(offset 0x0) would result in a
read of REG_DSI_CTRL for DSIv2. This register won't necessarily be 0 on
DSIv2. It can be non zero if DSI was previously initialized by the
bootloader.
Instead of reading offset 0x0, we now read offset 0x1f0. For DSIv2, this
register is DSI_VERSION, and is bound to be non-zero. On DSI6G, this
register(offset 0x1f0) is SCRATCH_REGISTER_0, which no one ever seems to
touch, and from all register dumps I'vc seen, holds 0 all the time.
Modify dsi_get_version to read REG_DSI_VERSION to determine whether we
are DSI6G or DSIv2.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add DSI PLL common clock framework clocks for 8960 PHY.
The PLL here is different from the ones found in B family msm chips. As
before, the DSI provides two clocks to the outside world. dsixpll and
dsixpllbyte (x = 1, 2). dsixpll is a regular clock divider, but
dsixpllbyte is modelled as a custom clock divider.
dsixpllbyte is the starting point of the PLL configuration. It is the
one that sets up the VCO clock rate. We need the VCO clock rate in the
form: F * byteclk, where F is a multiplication factor that varies on
the byte clock the DSI driver is trying to set. We use the custom
clk_ops for dsixpllbyte to ensure that the parent (VCO) is set at this
rate.
An additional divider (POSTDIV1) generates the bitclk. Since bit clock
can be derived from byteclock, we calculate it internally, and don't
expose it as a clock.
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
DSI PHY on MSM8960 and APQ8064 is a 28nm PHY that's different from the
supported 28nm LP PHY found in newer chips.
Add support for the new PHY.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We retrieve the byte and pixel source clocks (RCG clocks) in the dsi
driver via DT. These are needed so that we can re-parent these source
clocks if we want to drive it using a different DSI PLL.
We shouldn't get these via DT because they aren't clocks that directly
serve as inputs to the dsi host.
Fortunately, there is a static parent-child link between the
byte_clk_src/pixel_clk_src and byte_clk/pixel_clk clocks. So, we can
retrieve the source clocks via clk_get_parent.
Do this instead of retrieving via DT.
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The current settings for 28nm PHY data lane CFG4 registers do
not work with certain panels. This change is to modify them to
hw recommended values.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
In some configurations the supplies are voltage switches and not LDOs,
making the set voltage call to fail. Check with the regulator framework
if the supply can change voltage before attempting.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Pull drm updates from Dave Airlie:
"This is the main pull request for the drm for 4.3. Nouveau is
probably the biggest amount of changes in here, since it missed 4.2.
Highlights below, along with the usual bunch of fixes.
All stuff outside drm should have applicable acks.
Highlights:
- new drivers:
freescale dcu kms driver
- core:
more atomic fixes
disable some dri1 interfaces on kms drivers
drop fb panic handling, this was just getting more broken, as more locking was required.
new core fbdev Kconfig support - instead of each driver enable/disabling it
struct_mutex cleanups
- panel:
more new panels
cleanup Kconfig
- i915:
Skylake support enabled by default
legacy modesetting using atomic infrastructure
Skylake fixes
GEN9 workarounds
- amdgpu:
Fiji support
CGS support for amdgpu
Initial GPU scheduler - off by default
Lots of bug fixes and optimisations.
- radeon:
DP fixes
misc fixes
- amdkfd:
Add Carrizo support for amdkfd using amdgpu.
- nouveau:
long pending cleanup to complete driver,
fully bisectable which makes it larger,
perfmon work
more reclocking improvements
maxwell displayport fixes
- vmwgfx:
new DX device support, supports OpenGL 3.3
screen targets support
- mgag200:
G200eW support
G200e new revision support
- msm:
dragonboard 410c support, msm8x94 support, msm8x74v1 support
yuv format support
dma plane support
mdp5 rotation
initial hdcp
- sti:
atomic support
- exynos:
lots of cleanups
atomic modesetting/pageflipping support
render node support
- tegra:
tegra210 support (dc, dsi, dp/hdmi)
dpms with atomic modesetting support
- atmel:
support for 3 more atmel SoCs
new input formats, PRIME support.
- dwhdmi:
preparing to add audio support
- rockchip:
yuv plane support"
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (1369 commits)
drm/amdgpu: rename gmc_v8_0_init_compute_vmid
drm/amdgpu: fix vce3 instance handling
drm/amdgpu: remove ib test for the second VCE Ring
drm/amdgpu: properly enable VM fault interrupts
drm/amdgpu: fix warning in scheduler
drm/amdgpu: fix buffer placement under memory pressure
drm/amdgpu/cz: fix cz_dpm_update_low_memory_pstate logic
drm/amdgpu: fix typo in dce11 watermark setup
drm/amdgpu: fix typo in dce10 watermark setup
drm/amdgpu: use top down allocation for non-CPU accessible vram
drm/amdgpu: be explicit about cpu vram access for driver BOs (v2)
drm/amdgpu: set MEC doorbell range for Fiji
drm/amdgpu: implement burst NOP for SDMA
drm/amdgpu: add insert_nop ring func and default implementation
drm/amdgpu: add amdgpu_get_sdma_instance helper function
drm/amdgpu: add AMDGPU_MAX_SDMA_INSTANCES
drm/amdgpu: add burst_nop flag for sdma
drm/amdgpu: add count field for the SDMA NOP packet v2
drm/amdgpu: use PT for VM sync on unmap
drm/amdgpu: make wait_event uninterruptible in push_job
...
We're removing struct clk from the clk provider API, so switch
this code to using the clk_hw based provider APIs.
Cc: Wentao Xu <wentaox@codeaurora.org>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
