Courtney Cavin [Mon, 5 Jan 2015 18:07:57 +0000 (10:07 -0800)]
remoteproc: Support loading firmware from lately mounted fs (HACK)
If the firmware isn't available during boot then table_ptr will be NULL
and subsequent attempts to load the firmware will fail. Move things
around and reattempt the load upon trying to boot the rproc.
Bjorn Andersson [Wed, 10 Dec 2014 19:42:18 +0000 (11:42 -0800)]
remoteproc: qcom-tz: Finish shutdown on timeout
When the remote processor have hit an fatal error, it will not perform
the stop-ack handshake. So we have to finish the shutdown process to not
leave the remote processor in a dangling state (stopping us from
bringing it up again).
Bjorn Andersson [Wed, 10 Dec 2014 19:41:12 +0000 (11:41 -0800)]
remoteproc: qcom-tz: Inform SMD about crashing remotes
When a remote processor crashes there is no indication in SMD, so we
need to inform the SMD driver that it should reset all open channels
associated with the remote processor.
Bjorn Andersson [Thu, 27 Feb 2014 23:52:47 +0000 (15:52 -0800)]
remoteproc: qcom-pil: Implementation of Qualcomm TZ backed PIL
This implements the TrustZone based Peripheral Image Loader used in
Qualcomm platforms for loading and boot audio, video and wifi/bt remote
processors.
Bjorn Andersson [Tue, 11 Nov 2014 01:25:53 +0000 (17:25 -0800)]
remoteproc: core: Make the loaded resource table optional
Remote processors like the ones found in the Qualcomm SoCs does not have
a resource table passed to them, so make it optional and only populate
it if it exists.
Andy Gross [Tue, 15 Dec 2015 05:30:45 +0000 (23:30 -0600)]
regulator: qcom-smd: Add support for PMA8084
This patch adds support and documentation for the PMA8084 regulators
found on APQ8084 platforms.
Signed-off-by: Andy Gross <agross@codeaurora.org> Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
Andy Gross [Tue, 15 Dec 2015 05:30:44 +0000 (23:30 -0600)]
regulator: qcom-smd: Add PM8916 support
This patch adds support and documentation for the PM8916 regulators
found on MSM8916 platforms.
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Andy Gross <agross@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
ARM: 8485/1: cpuidle: remove cpu parameter from the cpuidle_ops suspend hook
The suspend() hook in the cpuidle_ops struct is always called on
the cpu entering idle, which means that the cpu parameter passed
to the suspend hook always corresponds to the local cpu, making
it somewhat redundant.
This patch removes the logical cpu parameter from the ARM
cpuidle_ops.suspend hook and updates all the existing kernel
implementations to reflect this change.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lina Iyer <lina.iyer@linaro.org> Tested-by: Lina Iyer <lina.iyer@linaro.org> Tested-by: Jisheng Zhang <jszhang@marvell.com> [psci] Cc: Lina Iyer <lina.iyer@linaro.org> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Arnd Bergmann [Tue, 24 Nov 2015 22:13:09 +0000 (23:13 +0100)]
ARM: qcom: select ARM_CPU_SUSPEND for power management
The qcom spm driver uses cpu_resume_arm(), which is not included
in the kernel in all configurations:
drivers/built-in.o: In function `qcom_cpu_spc':
:(.text+0xbc022): undefined reference to `cpu_suspend'
drivers/built-in.o: In function `qcom_cpuidle_init':
:(.init.text+0x610c): undefined reference to `cpu_resume_arm'
This adds a 'select' Kconfig statement to ensure it's always
enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Andy Gross <agross@codeaurora.org>
Arnd Bergmann [Fri, 20 Nov 2015 10:32:21 +0000 (11:32 +0100)]
soc: qcom: enable smsm/smp2p modular build
The newly added smp2p and smsm drivers cannot be loadable modules
but depend on smem, which can be, and that causes a link error:
drivers/built-in.o: In function `qcom_smp2p_intr':
:(.text+0xa6e68): undefined reference to `qcom_smem_get'
drivers/built-in.o: In function `qcom_smp2p_probe':
:(.text+0xa7320): undefined reference to `qcom_smem_alloc'
:(.text+0xa736c): undefined reference to `qcom_smem_get'
drivers/built-in.o: In function `qcom_smsm_probe':
:(.text+0xa7b34): undefined reference to `qcom_smem_get'
This marks all the drivers as 'tristate' to make the Kconfig
dependency resolution work properly.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: dbb04bd7122f ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point") Fixes: d7387fc6add4 ("soc: qcom: smsm: Add driver for Qualcomm SMSM") Signed-off-by: Andy Gross <agross@codeaurora.org>
Ivan T. Ivanov [Mon, 8 Jun 2015 07:22:08 +0000 (10:22 +0300)]
mmc: sdhci: let GPIO based card detection have higher precedence
Controller could have BROKEN_CARD_DETECTION quirk set, but drivers
could use GPIO to detect card present state. Let, when defined, GPIO
take precedence, so drivers could properly detect card state and not
use polling.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Archit Taneja [Thu, 10 Dec 2015 05:19:31 +0000 (10:49 +0530)]
drm/msm/dsi: Update the "vdd" voltage range
The min and max voltage levels for the VDD input to DSI were initially set
to 2.85V (as suggested by the spec).
We have a platform (db410c) where the same regulator supply is also needed
by another consumer at a higher voltage. Bump up the max voltage level to
3.3V. No regressions are seen with this.
The drm msm driver isn't pm_runtime adapted yet. Since gdsc is now associated
with pm_runtime, we need to make sure we don't do a pm_runtime_put() when we
are using the hardware.
HACK: drm/msm/mdp5: Make sure mdp5 clocks aren't disbaled when we need them
mdp5_hw_init configures registers but may not have clocks enabled. Add
calls to enable/disable clocks in this func.
Comment out a mdp5_disable() call in mdp5_kms_init. For now, this makes
sure we have clocks all the time. This will be removed when runtime
pm is added, and we identify all paths where we risk clocks being
disabled when they shouldn't.
Currently, msm dsi_host's attach/detach ops call drm_helper_hpd_irq_event
unconditionally. Calling it makes sense if we have a drm_panel
connected (in this case, we created the connector), but not when we have
a bridge chip connected. For bridges, the driver (or someone else in the
encoder chain) should call the hpd handler.
Call it in the attach/detach ops only if we're connected to a panel.
drm/msm/dsi: Remove incorrect warning on host attach
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.
Hai Li [Thu, 3 Sep 2015 18:30:49 +0000 (14:30 -0400)]
drm/msm/dsi: Parse lane swap information from DT
Lane swap configuration is based on the board design.
This change allows the DSI host to get this information
from device tree, instead of hardcoding in driver.
This patch moves some of the dev_err messages to dev_dgb as these are
very normal messages, nothing unusual. Without this patch the messages
on console are very distracting when we run programs like i2cdetect.
Sricharan R [Mon, 18 May 2015 14:40:55 +0000 (20:10 +0530)]
i2c: qup: Add bam dma capabilities
QUP cores can be attached to a BAM module, which acts as a dma engine for the
QUP core. When DMA with BAM is enabled, the BAM consumer pipe transmitted data
is written to the output FIFO and the BAM producer pipe received data is read
from the input FIFO.
With BAM capabilities, qup-i2c core can transfer more than 256 bytes, without a
'stop' which is not possible otherwise.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Sricharan R [Mon, 18 May 2015 11:40:05 +0000 (17:10 +0530)]
i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit
The definition of i2c_msg says that
"If this is the last message in a group, it is followed by a STOP.
Otherwise it is followed by the next @i2c_msg transaction segment,
beginning with a (repeated) START"
So the expectation is that there is no 'STOP' bit inbetween individual
i2c_msg segments with repeated 'START'. The QUP i2c hardware has no way
to inform that there should not be a 'STOP' at the end of transaction.
The only way to implement this is to coalesce all the i2c_msg in i2c_msgs
in to one transaction and transfer them. Adding the support for the same.
This is required for some clients like touchscreen which keeps
incrementing counts across individual transfers and 'STOP' bit inbetween
resets the counter, which is not required.
This patch adds the support in non-dma mode.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Sricharan R [Mon, 18 May 2015 10:31:36 +0000 (16:01 +0530)]
i2c: qup: Add V2 tags support
QUP from version 2.1.1 onwards, supports a new format of
i2c command tags. Tag codes instructs the controller to
perform a operation like read/write. This new tagging version
supports bam dma and transfers of more than 256 bytes without 'stop'
in between. Adding the support for the same.
For each block a data_write/read tag and data_len tag is added to
the output fifo. For the final block of data write_stop/read_stop
tag is used.
Signed-off-by: Andy Gross <agross@codeaurora.org> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Sricharan R [Mon, 18 May 2015 09:23:08 +0000 (14:53 +0530)]
qup: i2c: factor out common code for reuse
The qup_i2c_write/read_one functions can be split to have
the common initialization code and function to loop around
the data bytes separately. This way the initialization code
can be reused while adding v2 tags functionality.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Sricharan R [Thu, 12 Mar 2015 09:15:19 +0000 (14:45 +0530)]
i2c: qup: Change qup_wait_writeready function to use for all timeouts
qup_wait_writeready waits only on a output fifo empty event.
Change the same function to accept the event and data length
to wait as parameters. This way the same function can be used for
timeouts in otherplaces as well.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Ivan T. Ivanov [Fri, 15 May 2015 08:07:00 +0000 (11:07 +0300)]
amba: Defer device peripheral ID read
To be able to read peripheral ID during device create time
bus code have turn on device interface clock, but this
clock could be unavailable at this time. Fix this by defer
device ID read until driver match time.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Rajendra Nayak [Fri, 9 Oct 2015 09:41:06 +0000 (15:11 +0530)]
thermal: qcom: tsens-8960: Add support for 8960 family of SoCs
8960 family of SoCs have the TSENS device as part of GCC, hence
the driver probes the virtual child device created by GCC and
uses the parent to extract all DT properties and reuses the GCC
regmap.
Also GCC/TSENS are part of a domain thats not always ON.
Hence add .suspend and .resume hooks to save and restore some of
the inited register context.
Also 8960 family have some of the TSENS init sequence thats
required to be done by the HLOS driver (some later versions of TSENS
do not export these registers to non-secure world, and hence need
these initializations to be done by secure bootloaders)
8660 from the same family has just one sensor and hence some register
offset/layout differences which need special handling in the driver.
Based on the original code from Siddartha Mohanadoss, Stephen Boyd and
Narendran Rajan.
Rajendra Nayak [Fri, 9 Oct 2015 09:41:04 +0000 (15:11 +0530)]
thermal: qcom: tsens-8916: Add support for 8916 family of SoCs
Add support to calibrate sensors on 8916 family and also add common
functions to read temperature from sensors (This can be reused on
other SoCs having similar TSENS device)
The calibration data is read from eeprom using the generic nvmem
framework apis.
Based on the original code by Siddartha Mohanadoss and Stephen Boyd.
Rajendra Nayak [Fri, 9 Oct 2015 09:41:03 +0000 (15:11 +0530)]
thermal: qcom: tsens: Add a skeletal TSENS drivers
TSENS is Qualcomms' thermal temperature sensor device. It
supports reading temperatures from multiple thermal sensors
present on various QCOM SoCs.
Calibration data is generally read from a non-volatile memory
(eeprom) device.
Add a skeleton driver with all the necessary abstractions so
a variety of qcom device families which support TSENS can
add driver extensions.
Also add the required device tree bindings which can be used
to describe the TSENS device in DT.
Georgi Djakov [Tue, 11 Aug 2015 13:35:59 +0000 (16:35 +0300)]
soc: qcom: Add support for SAW2 regulators
The SAW2 (Subsystem Power Manager and Adaptive Voltage Scalling Wrapper)
is part of the SPM subsystem. It is a hardware block in the Qualcomm
chipsets that regulates the power to the cores.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Georgi Djakov [Wed, 18 Mar 2015 15:23:29 +0000 (17:23 +0200)]
clk: qcom: Add support for regmap mux-div clocks
Add support for hardware that support switching both parent clocks and the
divider at the same time. This avoids generating intermediate frequencies
from either the old parent clock and new divider or new parent clock and
old divider combinations.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Georgi Djakov [Thu, 3 Dec 2015 12:14:15 +0000 (14:14 +0200)]
clk: qcom: Add support for RPM Clocks
This adds initial support for clocks controlled by the Resource
Power Manager (RPM) processor on some Qualcomm SoCs, which use
the qcom_rpm driver to communicate with RPM.
Such platforms are apq8064 and msm8960.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Georgi Djakov [Mon, 3 Aug 2015 13:30:30 +0000 (16:30 +0300)]
clk: qcom: Add support for SMD-RPM Clocks
This adds initial support for clocks controlled by the Resource
Power Manager (RPM) processor on some Qualcomm SoCs, which use
the qcom_smd_rpm driver to communicate with RPM.
Such platforms are msm8916, apq8084 and msm8974.
The RPM is a dedicated hardware engine for managing the shared
SoC resources in order to keep the lowest power profile. It
communicates with other hardware subsystems via shared memory
and accepts clock requests, aggregates the requests and turns
the clocks on/off or scales them on demand.
This driver is based on the codeaurora.org driver:
https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/clk/qcom/clock-rpm.c
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Stephen Boyd [Sat, 21 Mar 2015 06:45:30 +0000 (23:45 -0700)]
clk: qcom: Add Krait clock controller driver
The Krait CPU clocks are made up of a primary mux and secondary
mux for each CPU and the L2, controlled via cp15 accessors. For
Kraits within KPSSv1 each secondary mux accepts a different aux
source, but on KPSSv2 each secondary mux accepts the same aux
source.
Cc: <devicetree@vger.kernel.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Stephen Boyd [Sat, 21 Mar 2015 06:45:29 +0000 (23:45 -0700)]
clk: qcom: Add KPSS ACC/GCC driver
The ACC and GCC regions present in KPSSv1 contain registers to
control clocks and power to each Krait CPU and L2. For CPUfreq
purposes probe these devices and expose a mux clock that chooses
between PXO and PLL8.
Cc: <devicetree@vger.kernel.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Stephen Boyd [Sat, 21 Mar 2015 06:45:28 +0000 (23:45 -0700)]
clk: qcom: Add support for Krait clocks
The Krait clocks are made up of a series of muxes and a divider
that choose between a fixed rate clock and dedicated HFPLLs for
each CPU. Instead of using mmio accesses to remux parents, the
Krait implementation exposes the remux control via cp15
registers. Support these clocks.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Stephen Boyd [Sat, 21 Mar 2015 06:45:25 +0000 (23:45 -0700)]
clk: qcom: Add HFPLL driver
On some devices (MSM8974 for example), the HFPLLs are
instantiated within the Krait processor subsystem as separate
register regions. Add a driver for these PLLs so that we can
provide HFPLL clocks for use by the system.
Cc: <devicetree@vger.kernel.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Stephen Boyd [Sat, 21 Mar 2015 06:45:23 +0000 (23:45 -0700)]
clk: Add safe switch hook
Sometimes clocks can't accept their parent source turning off
while the source is reprogrammed to a different rate. Most
notably CPU clocks require a way to switch away from the current
PLL they're running on, reprogram that PLL to a new rate, and
then switch back to the PLL with the new rate once they're done.
Add a hook that drivers can implement allowing them to return a
'safe parent' and 'safe frequency' that they can switch their
parent to while the upstream source is reprogrammed to support
this.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Stephen Boyd [Sat, 21 Mar 2015 06:45:21 +0000 (23:45 -0700)]
clk: mux: Split out register accessors for reuse
We want to reuse the logic in clk-mux.c for other clock drivers
that don't use readl as register accessors. Fortunately, there
really isn't much to the mux code besides the table indirection
and quirk flags if you assume any bit shifting and masking has
been done already. Pull that logic out into reusable functions
that operate on an optional table and some flags so that other
drivers can use the same logic.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Stephen Boyd [Sat, 21 Mar 2015 06:45:22 +0000 (23:45 -0700)]
clk: Avoid sending high rates to downstream clocks during set_rate
If a clock is on and we call clk_set_rate() on it we may get into
a situation where the clock temporarily increases in rate
dramatically while we walk the tree and call .set_rate() ops. For
example, consider a case where a PLL feeds into a divider.
Initially the divider is set to divide by 1 and the PLL is
running fairly slow (100MHz). The downstream consumer of the
divider output can only handle rates =< 400 MHz, but the divider
can only choose between divisors of 1 and 4.
+-----+ +----------------+
| PLL |-->| div 1 or div 4 |---> consumer device
+-----+ +----------------+
To achieve a rate of 400MHz on the output of the divider, we
would have to set the rate of the PLL to 1.6 GHz and then divide
it by 4. The current code would set the PLL to 1.6GHz first while
the divider is still set to 1, thus causing the downstream
consumer of the clock to receive a few clock cycles of 1.6GHz
clock (far beyond it's maximum acceptable rate). We should be
changing the divider first before increasing the PLL rate to
avoid this problem.
Therefore, set the rate of any child clocks that are increasing
in rate from their current rate so that they can increase their
dividers if necessary. We assume that there isn't such a thing as
minimum rate requirements.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Conflicts:
drivers/clk/clk.c
Stephen Boyd [Sat, 21 Mar 2015 06:45:20 +0000 (23:45 -0700)]
ARM: Add Krait L2 register accessor functions
Krait CPUs have a handful of L2 cache controller registers that
live behind a cp15 based indirection register. First you program
the indirection register (l2cpselr) to point the L2 'window'
register (l2cpdr) at what you want to read/write. Then you
read/write the 'window' register to do what you want. The
l2cpselr register is not banked per-cpu so we must lock around
accesses to it to prevent other CPUs from re-pointing l2cpdr
underneath us.
Cc: Mark Rutland <mark.rutland@arm.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Courtney Cavin <courtney.cavin@sonymobile.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Georgi Djakov [Thu, 19 Nov 2015 13:57:56 +0000 (15:57 +0200)]
clk: qcom: msm8916: Move xo and sleep clocks into DT
Move the xo and sleep clocks to device-tree, instead of hard-coding
them in the driver. This allows us to insert the RPM clocks (if they
are enabled) in between the on-board oscillators and the actual clock.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Stephen Boyd [Tue, 27 Oct 2015 01:10:09 +0000 (18:10 -0700)]
clk: qcom: Move cxo/pxo/xo into dt files
Put these clocks into the dt files instead of registering them
from C code. This provides a few benefits. It allows us to
specify the frequency of these clocks at the board level instead
of hard-coding them in the driver. It allows us to insert an RPM
clock in between the consumers of the crystals and the actual
clock. And finally, it helps us transition the GCC driver to use
RPM clocks when that configuration is enabled.
Cc: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Stephen Boyd [Tue, 27 Oct 2015 00:11:32 +0000 (17:11 -0700)]
clk: qcom: common: Add API to register board clocks backwards compatibly
We want to put the XO board clocks into the dt files, but we also
need to be backwards compatible with an older dtb. Add an API to
the common code to do this. This also makes a place for us to
handle the case when the RPM clock driver is enabled and we don't
want to register the fixed factor clock.
Cc: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Rajendra Nayak [Thu, 6 Aug 2015 10:37:54 +0000 (16:07 +0530)]
clk: qcom: gdsc: Manage clocks with !CONFIG_PM
With CONFIG_PM disabled, turn the devices clocks on during
driver binding to the device, and turn them off when the
driver is unbound from the device. Platforms can specify
all the clocks that need to be managed in !CONFIG_PM case
using qcom_pm_add_notifier().
The use of pm_clk_add_notifier() isn't appropriate here since we need
to only manage clocks with valid power domain associations done via
DT, instead of what pm_clk_add_notifier() does, which is manage clocks
for all on SoC/off SoC devices associating all of them to a dummy power
domain instead
Rajendra Nayak [Thu, 6 Aug 2015 10:37:53 +0000 (16:07 +0530)]
clk: qcom: gdsc: Enable an RCG before turing on the gdsc
Some gdsc instances require a certain root clock (RCG) to be turned on
*before* the power domain itself can be turned on. Handle this as part
of the gdsc enable/disable callbacks.
Rajendra Nayak [Thu, 6 Aug 2015 10:37:52 +0000 (16:07 +0530)]
clk: qcom: gdsc: Use PM clocks to control gdsc clocks
The devices within a gdsc power domain, quite often have additional
clocks to be turned on/off along with the power domain itself.
Once the drivers for these devices are converted to use runtime PM,
it would be possible to remove all clock handling from the drivers if
the gdsc driver can handle it.
Use PM clocks to add support for this. A list of clock ids specified
per gdsc would be the clocks turned on/off on every device start/stop
callbacks.
drm/i2c: adv7511: setup CEC registers during power off-power-on sequence
This patch sets up the CEC register during power up sequence, the reason
to do this because during power dowm the bridge can put audio pins in to
low power state.
Orignally the issue was detected on ubuntu image, where in after first
logout the audio was totally disabled.
Reported-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
drm/i2c: adv7511: Create mipi_dsi_device for ADV7533
In order to pass DSI specific parameters to the DSI host, we need the
driver to create a mipi_dsi_device that attaches to the host.
Use of_graph helpers to get the DSI host DT node. Create a dummy dsi
device using this host. Finally, attach this device to the host.
Populate few other DT parameters (number of data lanes etc) that are
required for DSI RX to work correctly. Hardcode few other parameters
(rgb, embedded_sync) for now.
drm/i2c: adv7511: Add drm_bridge/connector for ADV7533
Create bridge and connector helper functions. These internally refer to
the ADV75xx helper functions.
The driver registers a drm_bridge object during probe. The bridge, in
turn registers a HDMI connector when a user attaches the bridge.
Therefore, when the device type is ADV7533, we create bridge and
connector entities, and when it's ADV7511, we create a slave encoder as
before.
Since the i2c driver is still wrapped around by the drm_i2c_slave_encoder
struct. We make sure the encoder_init op returns an error when the device
type is ADV7533.
ADV7511 is represented as an i2c drm slave encoder device. ADV7533, on
the other hand, is going be a normal i2c client device creating bridge
and connector entities.
Move the code in encoder slave functions to generate helpers that are
agnostic to the drm object type. These helpers will later also be used
by bridge and connecter helper functions.
ADV7533 is a DSI to HDMI encoder chip. It is a derivative of ADV7511,
with additional blocks to translate input DSI data to parallel RGB
data. Besides the ADV7511 i2c register map, it has additional registers
that require to be configured to activate the DSI blocks.
Use DT compatible strings to populate the adv7533 type enum. Add minimal
register configurations belonging to the DSI/CEC register map.
drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled
When the adv7511 i2c client doesn't have an interrupt line, we observe a
deadlock on caused by trying to lock drm device's mode_config.mutex twice
in the same context.
mipi_dsi_devices are inherently aware of their host because they
share a parent-child hierarchy in the device tree.
Non-dsi drivers that create a dummy dsi device don't have this data.
In order to get this information, they require to a phandle to the dsi
host in the device tree.
Maintain a list of all the hosts DSI that are currently registered.
This list will be used to find the mipi_dsi_host corresponding to the
device_node passed in of_find_mipi_dsi_host_by_node.
We can have devices where the data bus is MIPI DSI, but the control bus
is something else (i2c, spi etc). A typical example is i2c controlled
encoder bridge chips.
Such devices too require passing DSI specific parameters (number of data
lanes, DSI mode flags, color format etc) to their DSI host. For a device
that isn't 'mipi_dsi_device', there is no way of passing such parameters.
Provide the option of creating a dummy DSI device. The main purpose of
this would be to attach to a DSI host by calling mipi_dsi_attach, and
pass DSI params.
Create mipi_dsi_new_dummy for creating a dummy dsi device. The driver
calling this needs to be aware of the mipi_dsi_host it wants to attach
to, and also the DSI virtual channel the DSI device intends to use.
Archit Taneja [Wed, 19 Aug 2015 10:44:09 +0000 (16:14 +0530)]
drm/mipi_dsi: refactor device creation
Create a helper function mipi_dsi_device_new which takes in struct
mipi_dsi_device_info and the mipi_dsi_host. This will be called by
of_mipi_dsi_device_add.
Instead of calling device_initialize and device_add separately, merge
it into a single device_register call. This will remove the need of
having two separate funcs mipi_dsi_device_alloc and mipi_dsi_device_add.
The reason for creating mipi_dsi_device_new is that it can also be used
as a standalone way for creating a dsi device that isn't available via
DT.
arm64: dma-mapping: map sg lists into the SMMU as virtually contiguous
In arm_iommu_map_sg, currently we map each individual link in the given
scatterlist into the SMMU individually such that they may or may not be
virtually contiguous. However, in most (all?) of our use cases we
actually want the entire sg list mapped into the SMMU as a single
contiguous range. Use iommu_map_range to accomplish this.
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
[Forward Ported this from msm3.14] Signed-off-by: Sricharan R <sricharan@codeaurora.org>
[added iommu_map_range in generic dma code] Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Sricharan R [Tue, 21 Apr 2015 14:30:37 +0000 (20:00 +0530)]
arm64: mm: Fix a bug in iommu dma-mapping
iommu_alloc_attrs and arm_iommu_mmap_attrs calls
dma_pgprot with device type set to always 'coherent'
which is wrong. Should be based on the device type.
Signed-off-by: Sricharan R <sricharan@codeaurora.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
On systems with IOMMUs, it's useful to handle IOMMU mappings in the
dma-mapping layer. This is currently supported on arm but not arm64. Add
support in arm64 by gratuitously lifting most of the IOMMU-related stuff
from dma-mapping.c in arm.
The original arm work was done by Marek Szyprowski in [4ce63fcd919c32:
"ARM: dma-mapping: add support for IOMMU mapper"].
Change-Id: I1c3c8fe15049fe456751074398fd179ebd2ec64e Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
[forward ported from 3.14 tree] Signed-off-by: R Sricharan <sricharan@codeaurora.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Laura Abbott [Wed, 6 Aug 2014 02:39:38 +0000 (19:39 -0700)]
arm: Add option to skip buffer zeroing
The DMA framework currently zeros all buffers because it (righfully so)
assumes that drivers will soon need to pass the memory to a device.
Some devices/use case may not require zeroed memory and there can
be an increase in performance if we skip the zeroing. Add a DMA_ATTR
to allow skipping of DMA zeroing.
Note: only the header file was modified to add the enum to allow the code to
compile, however the arm32 implementation was not pulled, and the arm64
implementation is missing as well
Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Strongly ordered memory is occasionally needed for some DMA
allocations for specialized use cases. Add the corresponding
DMA attribute.
Change-Id: Idd9e756c242ef57d6fa6700e51cc38d0863b760d Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
[ luis: adjuste context after commit a9a62c938441 ("dma-mapping: introduce
the DMA_ATTR_NO_WARN attribute") has been applied to master ] Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
projects / mirror_ubuntu-zesty-kernel.git / log