| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Allwinner SoCs have a handful of SRAM that can be either mapped to be
accessible by devices or the CPU.
That mapping is controlled by an SRAM controller, and that mapping might
not be set by the bootloader, for example if the device wasn't used at all,
or if we're using solutions like the U-Boot's Falcon Boot.
We could also imagine changing this at runtime for example to change the
mapping of these SRAMs to use them for suspend/resume or runtime memory
rate change, if that ever happens.
These use cases require some API in the kernel to control that mapping,
exported through a drivers/soc driver.
This driver also implement a debugfs file that shows the SRAM found in the
system, the current mapping and the SRAM that have been claimed by some
drivers in the kernel.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the PMIC wrapper found on MediaTek MT8135 and
MT8173 SoCs. The PMIC wrapper is found on MT6xxx SoCs aswell but these
are currently not supported.
On MediaTek MT8135, MT8173 and other SoCs the PMIC is connected via
SPI. The SPI master interface is not directly visible to the CPU, but
only through the PMIC wrapper inside the SoC. The communication between
the SoC and the PMIC can optionally be encrypted. Also a non standard
Dual IO SPI mode can be used to increase speed. The MT8135 also supports
a special feature named "IP Pairing". With IP Pairing the pins of some
SoC internal peripherals can be on the PMIC. The signals of these pins
are routed over the SPI bus using the pwrap bridge. Because of these
optional non SPI conform features the PMIC driver is not implemented as
a SPI bus master driver.
Signed-off-by: Flora Fu, MediaTek
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a SoC driver to be used by the ARM RealView
reference boards. We create the "versatile" directory to hold
the different ARM reference designs as per the pattern of the
clk directory layout. The driver utilze the syscon to get to
the register needed. After this we can use sysfs to get at
some SoC properties on RealView DT variants like this:
> cd /sysbus/soc/devices/soc0
> ls
board family machine power subsystem
build fpga manufacturer soc_id uevent
> cat family
Versatile
> cat fpga
Multi-layer AXI
> cat board
HBI-0147
> cat build
03
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Conflicts:
drivers/soc/Kconfig
drivers/soc/Makefile
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
the main hardware sub system which forms the backbone of the Keystone
Multi-core Navigator. QMSS consist of queue managers, packed-data structure
processors(PDSP), linking RAM, descriptor pools and infrastructure
Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating
management of the packet queues. Packets are queued/de-queued by writing or
reading descriptor address to a particular memory mapped location. The PDSPs
perform QMSS related functions like accumulation, QoS, or event management.
Linking RAM registers are used to link the descriptors which are stored in
descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions,
queue pool management (allocation, push, pop and notify) and descriptor
pool management. The specifics on the device tree bindings for
QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-navigator-qmss.txt
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
| |
|
|
|
|
|
|
|
|
| |
The GSBI (General Serial Bus Interface) driver controls the overarching
configuration of the shared serial bus infrastructure on APQ8064, IPQ8064, and
earlier QCOM processors. The GSBI supports UART, I2C, SPI, and UIM
functionality in various combinations.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
|
|
|
Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and
discussion at Kernel Summit'2013, it was agreed to create
'driver/soc' for drivers which are quite SOC specific.
Further discussion on the subject is in response to
the earlier version of the patch is here:
http://lwn.net/Articles/588942/
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
|
