With the old binding and driver architecture we had many issues:
No way to assign eDMA channels to event queues, thus not able to tune the
system by moving specific DMA channels to low/high priority servicing. We
moved the cyclic channels to high priority within the code, but that was
just a workaround to this issue.
Memcopy was fundamentally broken: even if the driver scanned the DT/devices
in the booted system for direct DMA users (which is not effective when the
events are going through a crossbar) and created a map of 'used' channels,
this information was not really usable. Since via dmaengien API the eDMA
driver will be called with _some_ channel number, we would try to request
this channel when any channel is requested for memcpy. By luck we got
channel which is not used by any device most of the time so things worked,
but if a device would have been using the given channel, but not requested
it, the memcpy channel would have been waiting for HW event.
The old code had the am33xx/am43xx DMA event router handling embedded. This
should have been done in a separate driver since it is not part of the
actual eDMA IP.
There were no way to 'lock' PaRAM slots to be used by the DSP for example
when booting with DT.
In DT boot the edma node used more than one hwmod which is not a good
practice and the kernel prints warning because of this.
With the new bindings and the changes in the driver we can:
- No regression with Legacy binding and non DT boot
- DMA channels can be assigned to any TC (to set priority)
- PaRAM slots can be reserved for other cores to use
- Dynamic power management for CC and TCs, if only TC0 is used all other TC
can be powered down for example
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
The point in providing an inline version of intel_svm_bind_mm() which
just returns -ENOSYS is that people are supposed to be able to *use* it
and just see that it fails. So we need to let them have a definition of
struct svm_dev_ops (and the flags) too.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Add clk_hw_is_enabled() to the provider APIs so clk providers can
use a struct clk_hw instead of a struct clk to check if a clk is
enabled or not.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Compiling the versatile clock driver with COMPILE_TEST=y and CONFIG_OF=n
leads to the following error:
drivers/clk/versatile/clk-sp810.c: In function 'clk_sp810_of_setup':
drivers/clk/versatile/clk-sp810.c:103:6: error: implicit declaration of
function 'of_clk_parent_fill' [-Werror=implicit-function-declaration]
Silence it by providing stubs APIs for of_clk_parent_fill().
Throw in a stub for of_clk_get_parent_count() too because we're
in the area.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
DesignWare MMC Controller can supports two types of DMA
mode: external dma and internal dma. We get a RK312x platform
integrated dw_mmc and ARM pl330 dma controller. This patch add
edmac ops to support these platforms. I've tested it on RK31xx
platform with edmac mode and RK3288 platform with idmac mode.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This adds logic to the MMC core to set VQMMC. This is expected to be
called by MMC drivers like dw_mmc as part of (or instead of) their
start_signal_voltage_switch() callback.
A few notes:
* When setting the signal voltage to 3.3V we do our best to make VQMMC
and VMMC match. It's been reported that this makes some old cards
happy since they were tested back in the day before UHS when VQMMC
and VMMC were provided by the same regulator. A nice side effect of
this is that we don't end up on the hairy edge of VQMMC (2.7V),
which some EEs claim is a little too close to the minimum for
comfort.
This is done in two steps. At first we try to find a VQMMC within
a 0.3V tolerance of VMMC and if this is not supported by the
supplying regulator we try to find a suitable voltage within the
whole 2.7V-3.6V area of the spec.
* The two step approach is currently necessary, as the used
regulator_set_voltage_triplet(min, target, max) uses a simple
implementation that just tries two basic steps:
regulator_set_voltage(target, max);
regulator_set_voltage(min, target);
So with only one step with 2.7-3.6V borders, if a suitable voltage
is a bit below VMMC, we would directly get the lowest 2.7V
which some boards (like Rockchips) don't like at all.
* When setting the signal voltage to 1.8V or 1.2V we aim for that
specific voltage instead of picking the lowest one in the range.
* We very purposely don't print errors in mmc_regulator_set_vqmmc().
There are cases where the MMC core will try several different
voltages and we don't want to pollute the logs.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
MMC_CLKGATE was once invented to save power by gating the bus clock at
request inactivity. At that time it served its purpose. The modern way to
deal with power saving for these scenarios, is by using runtime PM.
Nowadays, several host drivers have deployed runtime PM, but for those
that haven't and which still cares power saving at request inactivity,
it's certainly time to deploy runtime PM as it has been around for several
years now.
To simplify code to mmc core and thus decrease maintenance efforts, this
patch removes all code related to MMC_CLKGATE.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Certain eMMC devices allow vendor specific device information to be read
via a sequence of vendor commands. These vendor commands must be issued
in sequence and an atomic fashion. One way to support this would be to
add an ioctl function for sending a sequence of commands to the device
atomically as proposed here. These multi commands are simple array of
the existing mmc_ioc_cmd structure.
The structure passed via the ioctl uses a __u64 type to specify the number
of commands (so that the structure is aligned on a 64-bit boundary) and a
zero length array as a header for list of commands to be issued. The
maximum number of commands that can be sent is determined by
MMC_IOC_MAX_CMDS (which defaults to 255 and should be more than
sufficient).
This based upon work by Seshagiri Holi <sholi@nvidia.com>.
Signed-off-by: Seshagiri Holi <sholi@nvidia.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
As there are no users of the __mmc_switch() API, except for the mmc core
itself, let's convert it from an exported function into an internal.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some Arizona devices have a hardware ANC block present. This patch adds
the registers necessary to configure this hardware block.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
On Odroid XU3 board (with S2MPS11 PMIC) the PWRHOLD bit in CTRL1
register must be manually set to 0 before initiating power off sequence.
One of usual power down methods for Exynos based devices looks like:
1. PWRHOLD pin of PMIC is connected to PSHOLD of Exynos SoC.
2. Exynos holds up this pin during system operation.
3. ACOKB pin of PMIC is pulled up to VBATT and optionally to pin in
other device.
4. When PWRHOLD/PSHOLD goes low, the PMIC will turn off the power if
ACOKB goes high.
On Odroid XU3 family the difference is in (3) - the ACOKB is grounded.
This means that PMIC must manually set PWRHOLD field to low and then
wait for signal from Application Processor (the usual change in
PWRHOLD/PSHOLD pin will actually cut off the power).
The patch adds respective binding allowing Odroid XU3 device to be
powered off.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Reported-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses
_ADR to distinguish the devices under one actual device. Due to this we have to
improve the quirk in the MFD core to handle that board.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
ASoC: Updates for v4.4
Not much core work here, a few small tweaks to interfaces but mainly the
changes here are driver ones. Highlights include:
- Updates to the topology userspace interface
- Big updates to the Renesas support from Morimoto-san
- Most of the support for Intel Sky Lake systems.
- New drivers for Asahi Kasei Microdevices AK4613, Allwinnner A10,
Cirrus Logic WM8998, Dialog DA7219, Nuvoton NAU8825 and Rockchip
S/PDIF.
- A new driver for the Atmel Class D speaker drivers
The EAE PLX-PCI card has special leds on the the main io pci resource
bar. This patch adds support to trigger the conflict and data leds with
the packages.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
The SKB context buffer for HCI request is really not just for requests,
information in their are preserved for the whole HCI layer. So it makes
more sense to actually rename it into bt_cb()->hci and also call it then
struct hci_ctrl.
In addition that allows moving the decoded opcode for outgoing packets
into that struct. So far it was just consuming valuable space from the
main shared items. And opcode are not valid for L2CAP packets.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
NCI_HCI_IDENTITY_MGMT_GATE might be useful to get information
about hardware or firmware version.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
nci_hci_clear_all_pipes might be use full in some cases
for example after a firmware update.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Bringing in the sunxi clock branch since it introduces header file contents
that is needed by the DT branch. This is a stable tag shared with the clk tree.
Allwinner clock additions for 4.4
- Support for the Audio PLL and child clocks
- Support for the A33 AHB gates
- New clk-multiplier generic driver
* tag 'sunxi-clocks-for-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
clk: sunxi: mod1 clock support
clk: sunxi: codec clock support
clk: sunxi: pll2: Add A13 support
clk: sunxi: Add a driver for the PLL2
clk: Add a basic multiplier clock
clk: sunxi: Add A33 gates support
Signed-off-by: Olof Johansson <olof@lixom.net>
This pull request contains the DT changes for BCM2835 in 4.4. It
pulls in clk/clk-bcm2835 (which Stephen Boyd has said would be stable)
because the DT changes to enable the clock driver need the driver
itself to be present. These changes include the following:
- Eric Anholt, moves the bcm2835 clock driver under bcm/ where it belongs with
other Broadcom clock providers drivers, defines the binding for new clock
driver, adds support for programming the BCM2835 audio domain, adds the DDC I2C
controller to Device Tree, and finally migrates the Device Tree to use the new
clock driver binding
- Lubomir Rintel adds support for the Raspberry Pi Model A+ and B revision 2, and
remove the I2S controller which is non-existent on Raspberry Pi Model B
- Stefan Wahren adds an uart0 label for referencing the UART adapter
* tag 'arm/soc/for-4.4/rpi-dt-v2' of https://github.com/Broadcom/stblinux:
ARM: bcm2835: Add the DDC I2C controller to the device tree.
ARM: bcm2835: Switch to using the new clock driver support.
ARM: bcm2835: dt: Add Raspberry Pi Model A+
ARM: bcm2835: dt: Add Raspberry Pi Model B rev2
ARM: bcm2835: dt: Raspberry Pi Model B had no I2S
ARM: bcm2835: add label for uart0
clk: bcm2835: Add support for programming the audio domain clocks
clk: bcm2835: Add binding docs for the new platform clock driver.
clk: bcm2835: Move under bcm/ with other Broadcom SoC clk drivers.
Signed-off-by: Olof Johansson <olof@lixom.net>
Currently when the system is trying to uninstall the ACPI interrupt
handler, it uses acpi_gbl_FADT.sci_interrupt as the IRQ number.
However, the IRQ number that the ACPI interrupt handled is installed
for comes from acpi_gsi_to_irq() and that is the number that should
be used for the handler removal.
Fix this problem by using the mapped IRQ returned from acpi_gsi_to_irq()
as appropriate.
Cc: All applicable <stable@vger.kernel.org>
Acked-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ASoC: Updates for v4.4
A first batch of updates targetted at v4.4. There are no substantial
core fixes here, the biggest block of changes is updates to the rcar
drivers and the addition of a CODEC driver for the AK4613.
# gpg: Signature made Fri 25 Sep 2015 05:37:06 KST using RSA key ID 5D5487D0
# gpg: key CD7BEEBC: no public key for trusted key - skipped
# gpg: key CD7BEEBC marked as ultimately trusted
# gpg: key AF88CD16: no public key for trusted key - skipped
# gpg: key AF88CD16 marked as ultimately trusted
# gpg: key 16005C11: no public key for trusted key - skipped
# gpg: key 16005C11 marked as ultimately trusted
# gpg: key 5621E907: no public key for trusted key - skipped
# gpg: key 5621E907 marked as ultimately trusted
# gpg: key 5C6153AD: no public key for trusted key - skipped
# gpg: key 5C6153AD marked as ultimately trusted
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg: aka "Mark Brown <broonie@debian.org>"
# gpg: aka "Mark Brown <broonie@kernel.org>"
# gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg: aka "Mark Brown <broonie@linaro.org>"
# gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
This pull request contains the Raspberry Pi firmware driver, for communicating
with the VPU which has exclusive control of some of the peripherals.
Eric adds the actual firmware driver and Alexander fixes the header file which
was missing include guards.
* tag 'arm/soc/for-4.4/rpi-drivers' of https://github.com/Broadcom/stblinux:
ARM: bcm2835: add mutual inclusion protection
ARM: bcm2835: Add the Raspberry Pi firmware driver
Signed-off-by: Olof Johansson <olof@lixom.net>
Add the necessary hooks to use the pids loaded in set_event_pid to filter
all the events enabled in the tracing instance that match the pids listed.
Two probes are added to both sched_switch and sched_wakeup tracepoints to be
called before other probes are called and after the other probes are called.
The first is used to set the necessary flags to let the probes know to test
if they should be traced or not.
The sched_switch pre probe will set the "ignore_pid" flag if neither the
previous or next task has a matching pid.
The sched_switch probe will set the "ignore_pid" flag if the next task
does not match the matching pid.
The pre probe allows for probes tracing sched_switch to be traced if
necessary.
The sched_wakeup pre probe will set the "ignore_pid" flag if neither the
current task nor the wakee task has a matching pid.
The sched_wakeup post probe will set the "ignore_pid" flag if the current
task does not have a matching pid.
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
In order to guarantee that a probe will be called before other probes that
are attached to a tracepoint, there needs to be a mechanism to provide
priority of one probe over the others.
Adding a prio field to the struct tracepoint_func, which lets the probes be
sorted by the priority set in the structure. If no priority is specified,
then a priority of 10 is given (this is a macro, and perhaps may be changed
in the future).
Now probes may be added to affect other probes that are attached to a
tracepoint with a guaranteed order.
One use case would be to allow tracing of tracepoints be able to filter by
pid. A special (higher priority probe) may be added to the sched_switch
tracepoint and set the necessary flags of the other tracepoints to notify
them if they should be traced or not. In case a tracepoint is enabled at the
sched_switch tracepoint too, the order of the two are not random.
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Samsung 2nd DT updates for v4.4
- use exynos5420-dw-mshc instead of exynos5250 for exynos3250
- add DISP1 clocks and the DISP1 power domain of two closk
on exynos5250 (clock commit got Stephen's ack)
- add vbus regulators on exynos3250, exynos4210 and exynos4412 boards
- fix typo in regulator enable GPIO property on s5pv20-aquila and goni
- document: correct the example of exynos power domain clocks
- document: consolidate exynos SoC dt-bindings and non-Samsung
boards related compatibles (FriendlyARM, Google, Hardkernel
and Insignal)
- update MAINTAINER entries accordingly (documentation)
* tag 'samsung-dt-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
MAINTAINERS: Add documentation and dt-bindings for exynos stuff
dt-bindings: EXYNOS: Document compatibles from other vendors
dt-bindings: Consolidate Exynos SoC bindings
ARM: dts: Add clocks to DISP1 domain in exynos5250
dt-bindings: Correct the example for Exynos power domain clocks
ARM: dts: Fix typo in regulator enable GPIO property in s5pv210-goni
ARM: dts: Fix typo in regulator enable GPIO property in s5pv210-aquila
ARM: dts: Add vbus regulator to USB2 phy nodes on exynos3250, exynos4210 and exynos4412 boards
clk: samsung: exynos5250: Add DISP1 clocks
ARM: dts: use exynos5420-dw-mshc compatible for exynos3250
Signed-off-by: Olof Johansson <olof@lixom.net>
Reduced Serial Bus (RSB) is an Allwinner proprietery interface
used to communicate with PMICs and other peripheral ICs.
RSB is a two-wire push-pull serial bus that supports 1 master
device and up to 15 active slave devices.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
* acpi-pci:
ia64/PCI/ACPI: Use common interface to support PCI host bridge
x86/PCI/ACPI: Use common interface to support PCI host bridge
ACPI/PCI: Reset acpi_root_dev->domain to 0 when pci_ignore_seg is set
PCI/ACPI: Add interface acpi_pci_root_create()
ia64/PCI: Use common struct resource_entry to replace struct iospace_resource
ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge
ACPI/PCI: Enhance ACPI core to support sparse IO space
This functin takes as a parameter a pointer to the nci_dev
struct and the first byte from the values of the first domain
specific parameter that was used for the connection creation.
Signed-off-by: Robert Dolca <robert.dolca@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Initially it was used to create hooks in the driver for
proprietary operations. Currently it is being used for hooks
for both proprietary and generic operations.
Signed-off-by: Robert Dolca <robert.dolca@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The driver may be required to act when some responses or
notifications arrive. For example the NCI core does not have a
handler for NCI_OP_CORE_GET_CONFIG_RSP. The NFCC can send a
config response that has to be read by the driver and the packet
may contain vendor specific data.
The Fields Peak driver needs to take certain actions when a reset
notification arrives (packet also not handled by the nfc core).
The driver handlers do not interfere with the core and they are
called after the core processes the packet.
Signed-off-by: Robert Dolca <robert.dolca@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This allows sending core commands from the driver. The driver
should be able to send NCI core commands like CORE_GET_CONFIG_CMD.
Signed-off-by: Robert Dolca <robert.dolca@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Add NCI_OP_CORE_GET_CONFIG_CMD, NCI_OP_CORE_GET_CONFIG_RSP
and NCI_OP_CORE_RESET_NTF.
Signed-off-by: Robert Dolca <robert.dolca@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
FDP driver needs to send the firmware as regular packets
(not fragmented). The driver should have a way to
get the max packet size for a given connection.
Signed-off-by: Robert Dolca <robert.dolca@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
