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>
Abhimanyu Kapur [Tue, 18 Feb 2014 17:36:37 +0000 (09:36 -0800)]
arm64: smp: move the pen to a header file
Move the secondary_pen_release variable and the secondary_holding_pen
entry function to asm/smp_plat.h so that the other cpu ops implementations
can share them.
Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
Ivan T. Ivanov [Thu, 3 Sep 2015 14:59:26 +0000 (17:59 +0300)]
dmaengine: adm: Use 'soft' flush when stopping DMA
'Soft' flush will commit current buffer to memory
beffore stopping the engine. Used with peripheral
devices which did not know a priory DMA transfer
lenght, like size of input data in UART driver.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Andy Gross [Tue, 17 Mar 2015 05:46:12 +0000 (00:46 -0500)]
dmaengine: Add ADM driver
Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA
controller found in the MSM8x60 and IPQ/APQ8064 platforms.
The ADM supports both memory to memory transactions and memory
to/from peripheral device transactions. The controller also provides flow
control capabilities for transactions to/from peripheral devices.
The initial release of this driver supports slave transfers to/from peripherals
and also incorporates CRCI (client rate control interface) flow control.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Conflicts:
drivers/dma/Kconfig
drivers/dma/Makefile
Andy Gross [Tue, 17 Mar 2015 05:46:11 +0000 (00:46 -0500)]
dt/bindings: qcom_adm: Fix channel specifiers
This patch removes the crci information from the dma channel property. At least
one client device requires using more than one CRCI value for a channel. This
does not match the current binding and the crci information needs to be removed.
Instead, the client device will provide this information via other means.
Georgi Djakov [Fri, 11 Sep 2015 15:33:57 +0000 (18:33 +0300)]
iommu/msm: Fix "scheduling while atomic" bug
In the msm iommu driver currently we incorrectly use clk_prepare_enable()
and clk_disable_unprepare() functions that are sleeping and should not be
called in atomic context. Fix this by preparing clocks in advance and use
only clk_enable() in atomic context.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Laurent Pinchart [Thu, 14 May 2015 23:00:09 +0000 (02:00 +0300)]
iommu: of: Handle IOMMU lookup failure with deferred probing or error
Failures to look up an IOMMU when parsing the DT iommus property need to
be handled separately from the .of_xlate() failures to support deferred
probing.
The lack of a registered IOMMU can be caused by the lack of a driver for
the IOMMU, the IOMMU device probe not having been performed yet, having
been deferred, or having failed.
The first case occurs when the device tree describes the bus master and
IOMMU topology correctly but no device driver exists for the IOMMU yet
or the device driver has not been compiled in. Return NULL, the caller
will configure the device without an IOMMU.
The second and third cases are handled by deferring the probe of the bus
master device which will eventually get reprobed after the IOMMU.
The last case is currently handled by deferring the probe of the bus
master device as well. A mechanism to either configure the bus master
device without an IOMMU or to fail the bus master device probe depending
on whether the IOMMU is optional or mandatory would be a good
enhancement.
Laurent Pinchart [Thu, 14 May 2015 23:00:06 +0000 (02:00 +0300)]
of: dma: Split of_configure_dma() into mask and ops configuration
The of_configure_dma() function configures both the DMA masks and ops.
Moving DMA ops configuration to probe time would thus also delay
configuration of the DMA masks, which might not be safe. To avoid issues
split the configuration in two to allow keeping masks configuration at
device add time and move ops configuration to device probe time.
Laurent Pinchart [Thu, 14 May 2015 23:00:05 +0000 (02:00 +0300)]
of: dma: Make of_dma_deconfigure() public
As part of moving DMA initializing to probe time the
of_dma_deconfigure() function will need to be called from different
source files. Make it public and move it to drivers/of/device.c where
the of_dma_configure() function is.
Laurent Pinchart [Thu, 14 May 2015 23:00:04 +0000 (02:00 +0300)]
of: dma: Move range size workaround to of_dma_get_range()
Invalid dma-ranges values should be worked around when retrieving the
DMA range in of_dma_get_range(), not by all callers of the function.
This isn't much of a problem now that we have a single caller, but that
situation will change when moving DMA configuration to device probe
time.
Laurent Pinchart [Thu, 14 May 2015 23:00:02 +0000 (02:00 +0300)]
arm: dma-mapping: Don't override dma_ops in arch_setup_dma_ops()
The arch_setup_dma_ops() function is in charge of setting dma_ops with a
call to set_dma_ops(). set_dma_ops() is also called from
- highbank and mvebu bus notifiers
- dmabounce (to be replaced with swiotlb)
- arm_iommu_attach_device
(arm_iommu_attach_device is itself called from IOMMU and bus master
device drivers)
To allow the arch_setup_dma_ops() call to be moved from device add time
to device probe time we must ensure that dma_ops already setup by any of
the above callers will not be overriden.
Aftering replacing dmabounce with swiotlb, converting IOMMU drivers to
of_xlate and taking care of highbank and mvebu, the workaround should be
removed.
Sricharan R [Fri, 7 Aug 2015 12:26:48 +0000 (17:56 +0530)]
iommu/msm: Add DT adaptation
The driver currently works based on platform data. Remove this
and add support for DT. A single master can have multiple ports
connected to more than one iommu.
This association of master and iommus/contexts were previously
represented by platform data parent/child device details. The client
drivers were responsible for programming all of the iommus/contexts
for the device. Now while adapting to generic DT bindings we maintain the
list of iommus, contexts that each master domain is connected to and
program all of them on attach/detach.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Larry Bassel [Fri, 17 Jan 2014 18:33:08 +0000 (10:33 -0800)]
arm64: provide dma cache routines with same API as 32 bit
The APIs __dma_inv_range() and __dma_clean_range() were
not exported by the third party patch. Since the functions
starting with underscores are not to be directly used by drivers,
related functions without the underscores are provided
which have the same name and functionality as the 32 bit APIs.
Change-Id: Ie0e681614307d9d9a19e58cacfb9b5dff4528977 Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
arm64: add defines for dmac_*_range for compatibility with arm32
An earlier patch created defines for dma_*_range APIs to be
compatible with arm 32 bit, however it appears
these API names have not (at least yet) appeared there, so
revise the names to dmac_*_range, which is defined
for arm 32 bit so that there is one name defined
for both architectures.
Change-Id: I6456c02bad73fb54a874dc9925d3d43d9b8be2f2 Signed-off-by: Larry Bassel <lbassel@codeaurora.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Chintan Pandya [Tue, 17 Mar 2015 10:39:19 +0000 (16:09 +0530)]
iommu: msm: Invalidate properly from iommu_unmap
TLB invalidation by VA will work for the given VA and
not the range of VA. So, for a region that spreads
across multiple PTEs, that need to call TLBIVA multiple
times. This is un-optimized.
Anyways, the present implementation also support single
TLBIVA only for the first VA and rest may be kept in
TLB as is. This is a problem. Fix this by upgrading
TLBIVA with TLBIASID which will do invalidation for
all the VAs for matching ASID.
We may still skip fixing this in iommu_map as iommu_map
is still indeed mapping one VA at a time.
Changes made:
- drop usage of gen_pool_alloc_aligned
- rename clk and pclk to iface and core
- delete unused clks and regulators
- handle EPROBE_DEFER when requesting interrupts
Georgi Djakov [Tue, 24 Nov 2015 13:24:38 +0000 (15:24 +0200)]
arm64: dts: Align msm8916 cpu thermal trip point ranges
Use the same temperature ranges for both CPU thermal sensors
(tsen3 and tsen4). Start cpufreq cooling at 75 degrees and
initiate linux shutdown at 100 degrees.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Archit Taneja [Thu, 10 Dec 2015 10:58:02 +0000 (16:28 +0530)]
arm64: msm8916-mdss.dtsi: Add bus scaling properties for mdp
Add bus scaling properties in the mdp DT node so that the mdp client is
registered by the msm bus scaling driver. Pick up the bus scaling vector
properties from the downstream kernel.
Archit Taneja [Thu, 10 Dec 2015 06:09:55 +0000 (11:39 +0530)]
arm64: apq8016-sbc.dtsi: Add regulators needed by adv7533
The adv7533 requires two supplies AVDD and V3P3 fed to it. These
are provided by L6 and L17 voltage regulators. Assing these to
the adv7533 node in DT.
projects / mirror_ubuntu-zesty-kernel.git / log