Enable drivers for PMICs and MUICs present on Exynos-based devices:
- max14577: charger, fuel gauge (max17040), regulator,
used on: Gear 1, Gear 2,
- max77693: charger, fuel gauge (max17042),
used on: Trats2,
- s5m/s2mps: RTC, clock,
used on: Arndale, Arndale Octa, Gear 1, Gear 2
This allows full usage of charging stack on these devices along with RTC
and 32 kHz clocks.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
[kgene@kernel.org: savedefconfig]
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Current Exynos CPU idle driver supports entering AFTR (Arm Off, Top
Running) mode on Exynos3250, Exynos4210 (coupled), Exynos4x12 and
Exynos5250. Enable it in default configuration to reduce energy
consumption.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The Cypress All Points Addressable (APA) I2C Trackpad is used in the
Samsung Exynos 5250 Snow Chromebook. Build the driver as a module so
the device is supported.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The I2C GPIO arbitration driver is used on the Exynos5250 Snow Chromebook
to arbitrate the access to a I2C bus by the Application Processor or a EC.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Many Exynos devices have devices attached to their display ports.
This patch enables the needed Kconfig options to support different
configuration such as simple panel, embedded DisplayPort (eDP) to
LVDS bridges and HDMI displays.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
[kgene@kernel.org: savedefconfig]
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The rtc-s3c driver supports a range of S3C series Real-Time-Clocks found
on many Samsung SoCs. Build the driver as a module to support these RTC.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Build the Generic PWM Samsung driver as a module to support PWM
devices used in platforms with a Samsung SoC.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Enable the needed Kconfig options to have support for the ChromeOS EC
I2C transport, I2C tunnel and chardev user-space interface.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Enable the needed kconfig options to have support for Samsung USB 2.0
and USB 3.0 PHY drivers to support the USB PHYs found on Exynos SoCs.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
[kgene@kernel.org: savedefconfig]
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The Maxim max77802 Power Management IC is used on many Exynos machines.
Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
and 2-channel 32kHz clock outputs.
Enable the kernel config options to have the drivers for these devices
built as a module.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
[kgene@kernel.org: removing useless REGULATOR_MAX77802 config]
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Build the spi-s3c64xx driver as a module to have support for
the SPI controller in several Samsung SoCs.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A PCIe Port is an interface to a Link. A Root Port is a PCI-PCI bridge in
a Root Complex and has a Link on its secondary (downstream) side. For
other Ports, the Link may be on either the upstream (closer to the Root
Complex) or downstream side of the Port.
The usual topology has a Root Port connected to an Upstream Port. We
previously assumed this was the only possible topology, and that a
Downstream Port's Link was always on its downstream side, like this:
+---------------------+
+------+ | Downstream |
| Root | | Upstream Port +--Link--
| Port +--Link--+ Port |
+------+ | Downstream |
| Port +--Link--
+---------------------+
But systems do exist (see URL below) where the Root Port is connected to a
Downstream Port. In this case, a Downstream Port's Link may be on either
the upstream or downstream side:
+---------------------+
+------+ | Upstream |
| Root | | Downstream Port +--Link--
| Port +--Link--+ Port |
+------+ | Downstream |
| Port +--Link--
+---------------------+
We can't use the Port type to determine which side the Link is on, so add a
bit in struct pci_dev to keep track.
A Root Port's Link is always on the Port's secondary side. A component
(Endpoint or Port) on the other end of the Link obviously has the Link on
its upstream side. If that component is a Port, it is part of a Switch or
a Bridge. A Bridge has a PCI or PCI-X bus on its secondary side, not a
Link. The internal bus of a Switch connects the Port to another Port whose
Link is on the downstream side.
[bhelgaas: changelog, comment, cache "type", use if/else]
Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Currently dm-multipath has to clone the bios for every request sent
to the lower devices, which wastes cpu cycles and ties down memory.
This patch instead adds a new REQ_CLONE flag that instructs req_bio_endio
to not complete bios attached to a request, which we set on clone
requests similar to bios in a flush sequence. With this change I/O
errors on a path failure only get propagated to dm-multipath, which
can then either resubmit the I/O or complete the bios on the original
request.
I've done some basic testing of this on a Linux target with ALUA support,
and it survives path failures during I/O nicely.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Commit c4cf5261 ("bio: skip atomic inc/dec of ->bi_remaining for
non-chains") regressed all existing callers that followed this pattern:
1) saving a bio's original bi_end_io
2) wiring up an intermediate bi_end_io
3) restoring the original bi_end_io from intermediate bi_end_io
4) calling bio_endio() to execute the restored original bi_end_io
The regression was due to BIO_CHAIN only ever getting set if
bio_inc_remaining() is called. For the above pattern it isn't set until
step 3 above (step 2 would've needed to establish BIO_CHAIN). As such
the first bio_endio(), in step 2 above, never decremented __bi_remaining
before calling the intermediate bi_end_io -- leaving __bi_remaining with
the value 1 instead of 0. When bio_inc_remaining() occurred during step
3 it brought it to a value of 2. When the second bio_endio() was
called, in step 4 above, it should've called the original bi_end_io but
it didn't because there was an extra reference that wasn't dropped (due
to atomic operations being optimized away since BIO_CHAIN wasn't set
upfront).
Fix this issue by removing the __bi_remaining management complexity for
all callers that use the above pattern -- bio_chain() is the only
interface that _needs_ to be concerned with __bi_remaining. For the
above pattern callers just expect the bi_end_io they set to get called!
Remove bio_endio_nodec() and also remove all bio_inc_remaining() calls
that aren't associated with the bio_chain() interface.
Also, the bio_inc_remaining() interface has been moved local to bio.c.
Fixes: c4cf5261 ("bio: skip atomic inc/dec of ->bi_remaining for non-chains")
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Select ARM_SINGLE_ARMV7M in defconfigs of the converted ARMv7-M
platforms.
[arnd: moved the efm32_defconfig change to the patch that
originally introduces the symbol, to avoid intermittent regression]
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Use the new config symbol ARM_SINGLE_ARMV7M which groups config
symbols used by modern ARMv7-M platforms. This allows supporting
multiple ARMv7-M platforms in one kernel image. However, a common
kernel image requires the combined platforms to share the same
main memory layout to be bootable.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Joachim Eastwood <manabian@gmail.com>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Marvell 9120 SATA controller has the same issue as a number of others, so
use the same quirk for this one. The other quirks were added by
cc346a4714 ("PCI: Add function 1 DMA alias quirk for Marvell devices").
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
The newly added zx platform causes a build error when
CONFIG_THUMB2_KERNEL is enabled:
arch/arm/mach-zx/headsmp.S:16: Error: invalid immediate for address calculation (value = 0x00000004)
I'm assuming that the ROM code that is calling these entry
points runs in ARM mode, so there would be another problem
in the same file, and we can solve both problems at once
by adding a '.arm' statement that will make zx_resume_jump
and zx_secondary_startup both be built as ARM code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jun Nie <jun.nie@linaro.org>
Tested-by: Jun Nie <jun.nie@linaro.org>
"base_irq" needs to be signed for the error handling to work. Also we
can remove the initialization because we re-assign it later.
Fixes: aa8d6b73ea ('ARM: pxa: pxa_cplds: add lubbock and mainstone IO')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- use syscon in the ata and cf drivers to configure the SMC and drop
sam9_smc.c
- switch the at91rm9200 memory controller to syscon
- remove last useless headers
- remove now useless Makefile.boot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJVXkSpAAoJEKbNnwlvZCyzauwQAMw7hS1F13piSpN5JBlST6yx
I4ojH/wB5GzI+qvTTcBZQR0AGcDatU3cHuzIPzYypKTB76iLf5DaZPvPjN3S3EK0
2/4R2eJyz0pA/2liTQ17e0MjKSIR0Ui7kk/aWYnC92/p2KK8xpUsbxznAIkAdw8I
a1HgsM1IKPVnyyxgvrKNhNcsP7fCzfjgnRNmRiFe9iDIbLervE+jKpm7PTakWtQL
OeLqRoURVd7yOLeqhlrmgch0ut8MqdHPgD57M/xbgi11VSg1PwLWTpuUlbnbVFwD
nw8A7d24+rUYLgyhTj92RmSiPjFyztHL6S+rw4yzaDLHMIr4Vm/U4eS9xcRhXzhe
FaigePDKYQiDNZ3u3NCDwOJk3HLlTkpvlzmVd1nFn313afFOy4AtIwtyUgg51946
HkZQSU0JIcqd6y53EFjSMjdGxuDavyrYsV9KNDh3dFNHEKfe41LJBnYB9Q3mSYZC
H66sqs+5JVguwNdLJKXKvrehTF0dmsawvd0cjZgBDDj8JORjBPLIquU+IVJ1isYV
KDH4JjEWYqVk86j0Cpt0A+vCBOCAS21dn5wb6vi8dD4agoRr7HuQnSMbvzDhNLnY
93Ah82q5bQJjvWgb5FXYp2Ar9IhLBZ7sLqcnF1Fo5S7KCC6wMnd11/NeFYsnKfE/
N55fXpd/pPYDNg3XDs+q
=iSye
-----END PGP SIGNATURE-----
Merge tag 'at91-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux into next/cleanup
Merge "First batch of cleanup for 4.2" from Alexandre Belloni:
- use syscon in the ata and cf drivers to configure the SMC and drop
sam9_smc.c
- switch the at91rm9200 memory controller to syscon
- remove last useless headers
- remove now useless Makefile.boot
* tag 'at91-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
ARM: at91: remove useless Makefile.boot
ARM: at91: remove at91rm9200_sdramc.h
ARM: at91: remove mach/at91_ramc.h and mach/at91rm9200_mc.h
ARM: at91/pm: use the atmel-mc syscon defines
pcmcia: at91_cf: Use syscon to configure the MC/smc
ARM: at91: declare the at91rm9200 memory controller as a syscon
mfd: syscon: Add Atmel MC (Memory Controller) registers definition
ARM: at91: drop sam9_smc.c
ata: at91: use syscon to configure the smc
Drop more omap3 legacy board-*.c files for v4.2. This time we're
dropping the board files for beagle, overo and cm-t35.
The reason for dropping these now rather than later is that now
we can simply revert the patches in case of unexpected issues as
we are not dropping any platform data at this point.
This leaves us with only the following board-*.c files:
BOARD REASON NEEDED
board-ldp.c Still used in RMKs boot test system
board-omap3logic.c Getting a .dts file for v4.2
board-omap3pandora.c Got a .dts file for v4.1
board-rx51-*.c Needs /proc/atags support for user space
I'm hoping we can drop the remaining board-*.c for v4.3 merge
window, then keep the platform data around for one more merge
window in case of reverting needed, then drop the platform data
too for v4.4 if no issues needing reverting are found.
Also, few patches to clean-up the usage of Linux generic
macros:
- Use define for console loglevel
- Use const for struct irq_domain_ops
- Use PTR_ERR_OR_ZERO instead of PTR_RET
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVXQPLAAoJEBvUPslcq6VzbrEQAKWjRL1aaSkxmAB6NzB9o16K
/BbDTAl93l4zsnk4yvWz2CH1wRF0dtzN8aULgCK0v/dOAQx+scYDGGJZwt4EmFcP
7th7tgSAumNwNQz7BLT9IgdHUTSmGxHMS6dotMHlSfa8g5S0K97wWyfWsyBmj3gZ
nrD8ub9GfVkjt4k/Kk83EuEz8TI/ne1K6+EAR/RObLW15PzbP2YoTp14sXBWEqos
8yRvUV/j57M7VOKu7zv+QRFx476c2GxiU7FnrVdZkuJNoZNdMYsMTm77Q7p8/Kw/
AKvbQSa0Wa9VifhPIX7mpxlIBnuDM+2tJNXBkDuBjzcM1WllBiqlK7Zvzc5D3SoI
vGSYicgjU+nafyhGt2dmf6TmiO0LX4ve7n8tNkKGHux8OdXhhFnH+SnwWyt1/Bxy
aTwGiL0Jy82m817DL0GY9cbqydTtrRFR3H/UbInv/miT1SV1BX0rR2S3rFDad6BM
CWn0e5mB1fJ3BX3F9hJH8pBj4Uz8pusyIIxAceyfIqRTBH5jwZcED0TcKhuiwbmL
QMGUM1mSBhFqnnTr3DYsXwatkPzC+7pR1xHP/Qnve7jbX3PxipOASvCIb8HDq8sF
lmpWZRnC7UYi4SOf3DTnbqy9dlIQYp8oRZTmeeol4R5QML49pNkuxcr50dmLc0tA
8ReodZZlD4aPHZZ41rD7
=AVB2
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.2/clean' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup
Merge "Clean-up for omaps for v4.2 merge window" from Tony Lindgren:
Drop more omap3 legacy board-*.c files for v4.2. This time we're
dropping the board files for beagle, overo and cm-t35.
The reason for dropping these now rather than later is that now
we can simply revert the patches in case of unexpected issues as
we are not dropping any platform data at this point.
This leaves us with only the following board-*.c files:
BOARD REASON NEEDED
board-ldp.c Still used in RMKs boot test system
board-omap3logic.c Getting a .dts file for v4.2
board-omap3pandora.c Got a .dts file for v4.1
board-rx51-*.c Needs /proc/atags support for user space
I'm hoping we can drop the remaining board-*.c for v4.3 merge
window, then keep the platform data around for one more merge
window in case of reverting needed, then drop the platform data
too for v4.4 if no issues needing reverting are found.
Also, few patches to clean-up the usage of Linux generic
macros:
- Use define for console loglevel
- Use const for struct irq_domain_ops
- Use PTR_ERR_OR_ZERO instead of PTR_RET
* tag 'omap-for-v4.2/clean' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
mach-omap2: Remove use of deprecated marco, PTR_RET in devices.c
ARM: OMAP2+: Remove calls to deprecacted marco,PTR_RET in the files,fb.c and pmu.c
ARM: OMAP2+: Constify irq_domain_ops
ARM: OMAP2+: use symbolic defines for console loglevels instead of numbers
ARM: OMAP2+: Remove legacy booting support for Beagleboards
ARM: OMAP2+: Remove legacy booting support for Overo
ARM: OMAP2+: Remove legacy booting support for cm-t35
Use block layer queues with an internal cmd_type to submit internally
generated NVMe commands. This both simplifies the code a lot and allow
for a better structure. For example now the LighNVM code can construct
commands without knowing the details of the underlying I/O descriptors.
Or a future NVMe over network target could inject commands, as well as
could the SCSI translation and ioctl code be reused for such a beast.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
NVMe device always support the FUA bit, and the SCSI translations
accepts the DPO bit, which doesn't have much of a meaning for us.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Erorr handling for the scsi translation was completely broken, as there
were two different positive error number spaces overlapping. Fix this
up by removing one of them, and centralizing the generation of the other
positive values in a single place. Also fix up a few places that didn't
handle the NVMe error codes properly.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
This function handles two totally different opcodes, so split it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Most users want the generic device, so store that in struct nvme_dev
instead of the pci_dev. This also happens to be a nice step towards
making some code reusable for non-PCI transports.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Note that we keep the unused timeout argument, but allow callers to
pass 0 instead of a timeout if they want the default. This will allow
adding a timeout to the pass through path later on.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
to making omap1 support multiarch. After this series we still need to
make omap1 use the common clock framework and fix up the drivers to not
rely on includes from mach and plat directories.
Note that this branch depends on a GPIO driver fix in v4.1-rc3
d2d05c65c4 ("gpio: omap: Fix regression for MPUIO interrupts").
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVXlPnAAoJEBvUPslcq6Vzb3UP/2ObsLBggAG9uAFkTV4Jg4Sy
BKuetmnLpnthbjLXBXgvErdJwDGVjiB9DzhOe9x3kkqM8+emRW/ZS/wBdNNarGiY
qJo0y6aCgYOxYbELpgksfQfoPGEdU7aAauo7pIneDXHwxFwpcxlCRZc3QVLZRqPO
M85THI0h699Ejs+rjIyJD/juGb1O5HKk2qJa0yGn/MNnTeh6OVDFOU7oK95tB5WF
DiHJl/rQouQqERPrteM1iFqO9BV7F0K0bRrLC764YyvzG7uEb41f8TNOWFGnABDV
abHiAL6ZvYrfkFZK9Y29pCJriZjOerVbP4yjEHlORiu5Jng6i0Jmw+Jk67FakwAl
6IfwLItpmZtq0GjsvR7eeyfu8NF2Lk0HGFDuG2kSnRzsihjnJnF+ZFNejmg2b8e4
Rwuq6rU9MZQhe9uzJkArhVP5JZns8V2H7kFuep0/N1pUeGoQqJsGjaCQIcqoVvhl
Sub02jBFrvby3gS+fUSwjdbLRweD/iUrzAMBqnPNyB1z9OUxjeBU5k2YJM0yRWCi
tPTEoGXu75qCJguIH3bbQg7QY/g/eqYZVRTVGO1h2PRlLwEy5lnt9aS66BPn3rJj
tlYWuqq6vhnQrZBGadIHI5KHIB+eVU37hKmzv9NuD2J2fWXG/gTxqJPZWHuGT96f
p0VZTqHG2CkQO0LL58hf
=FVxF
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.2/omap1-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/soc
Merge fixed up omap1 sparse irq support for v4.2 from Tony Lindgren:
Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
to making omap1 support multiarch. After this series we still need to
make omap1 use the common clock framework and fix up the drivers to not
rely on includes from mach and plat directories.
Note that this branch depends on a GPIO driver fix in v4.1-rc3
d2d05c65c4 ("gpio: omap: Fix regression for MPUIO interrupts").
* tag 'omap-for-v4.2/omap1-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP1: Fix section mismatch warnings for omap_cfg_reg
ARM: OMAP1: Fix randconfig builds if ARCH_OMAP15XX not selected
ARM: OMAP1: Change interrupt numbering for sparse IRQ
ARM: omap1: Switch to use MULTI_IRQ
ARM: OMAP1: Switch to use generic irqchip in preparation for sparse IRQ
ARM: OMAP1: Move UART defines to prepare for sparse IRQ
Merge mach-bcm changes from Florian Fainelli:
This pull request contains the following changes:
- Rafal adds an additional fault code to be ignored by the kernel on BCM5301X SoC
- BCM63138 SMP support which:
* common code to control the PMB bus, to be shared with a reset
controller driver in drivers/reset
* secondary CPU initialization sequence using PMB helpers
* small changes suggested by Russell King to allow platforms to disable VFP
* tag 'arm-soc/for-4.2/soc-take2' of http://github.com/broadcom/stblinux:
ARM: BCM63xx: Add SMP support for BCM63138
ARM: vfp: Add vfp_disable for problematic platforms
ARM: vfp: Add include guards
ARM: BCM63xx: Add secondary CPU PMB initialization sequence
ARM: BCM63xx: Add Broadcom BCM63xx PMB controller helpers
ARM: BCM5301X: Ignore another (BCM4709 specific) fault code
Add an ioctl which allows users to create blob properties from supplied
data. Currently this only supports modes, creating a drm_display_mode from
the userspace drm_mode_modeinfo.
v2: Removed size/type checks.
Rebased on new patches to allow error propagation from create_blob,
as well as avoiding double-allocation.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Change drm_property_create_blob to return an ERR_PTR-encoded error on
failure, so we can pass the failure reason down.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@intel.com>
Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make the data parameter to drm_property_create_blob optional; if
omitted, the copy will be skipped and the data will be empty.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the drm_display_mode <-> drm_mode_modeinfo conversion functions
from drm_crtc.c to drm_modes.c, and make them non-static so that others
can use them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The only user of convert_umode was also performing mode validation, so
do that in the same place.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rather than open-coding our own CRTC state helpers, use the atomic helpers
added in f5e7840b0c, and make our freeing behaviour consistent as well.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Change '@param foo' to '@foo:' to fit kerneldoc style.
672cb1d6ae mistakenly added an extra parameter to the kerneldoc for
drm_property_unreference_blob which wasn't actually present.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a helper to create the IEC958 channel status from an ALSA
snd_pcm_runtime structure, taking account of the sample rate and
sample size.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviwed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a helper for the EDID like data structure, which is typically passed
from a HDMI adapter to its associated audio driver. This informs the
audio driver of the capabilities of the attached HDMI sink.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
After the renesas_usbhs driver is enabled in ARM multi_v7_defconfig,
we now get a new warning:
renesas_usbhs/mod.c: In function 'usbhs_interrupt':
renesas_usbhs/mod.c:246:7: warning: 'intenb1' may be used uninitialized in this function [-Wmaybe-uninitialized]
gcc correctly points to a problem here, for the case that the
device is in host mode, we use the intenb1 variable without
having assigned it first. The state->intsts1 has a similar
problem, but gcc cannot know that.
This avoids the problem by initializing both sides of the
comparison to zero when we don't read them from the respective
registers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 88a25e02f3 ("usb: renesas_usbhs: Add access control for INTSTS1 and INTENB1 register")
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Current rcar-dmac driver is using spin_lock_irq() / spin_unlock_irq()
in some functions. But, some other driver might call DMAEngine API
during interrupt disabled. In such case, rcar-dmac side spin_unlock_irq()
forcefully allows all interrupts. Therefore, other driver receives
unexpected interruption, and its exclusive access control will be broken.
This patch replaces spin_lock_irq() to spin_lock_irqsave(),
and spin_unlock_irq() to spin_unlock_irqrestore().
Reported-by: Cao Minh Hiep <cm-hiep@jinso.co.jp>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Keita Kobayashi <keita.kobayashi.ym@renesas.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds support for the LG LB070WV8 7" 800x480 panel to the DRM simple
panel driver.
Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
MAX8973 supports the voltage output enable/disable through its EN
pin. This EN pin can be connected through GPIO from host processor.
Add support to provide GPIO number from platform/DT and if it is
valid GPIO then enable external control default.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
