* [PATCH 02/22] mfd: axp20x: add ADC data regs to volatile regs for AXP22X
From: Quentin Schulz @ 2017-01-02 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-1-quentin.schulz@free-electrons.com>
The AXP22X PMICs have multiple ADCs, each one exposing data from the
different power supplies connected to the PMIC.
This adds the different ADC data registers to the volatile registers of
the AXP22X PMIC.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/mfd/axp20x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 619a83e..a33db5e 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -100,6 +100,7 @@ static const struct regmap_range axp22x_writeable_ranges[] = {
static const struct regmap_range axp22x_volatile_ranges[] = {
regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
+ regmap_reg_range(AXP22X_TEMP_ADC_H, AXP20X_BATT_DISCHRG_I_L),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
regmap_reg_range(AXP22X_PMIC_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
--
2.9.3
^ permalink raw reply related
* [PATCH 01/22] dt-bindings: iio: adc: add AXP20X/AXP22X ADC DT binding
From: Quentin Schulz @ 2017-01-02 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-1-quentin.schulz@free-electrons.com>
The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
battery voltage, battery charge and discharge currents, AC-in and VBUS
voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
This adds the device tree binding documentation for the X-Powers AXP20X
and AXP22X PMICs ADCs.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
.../devicetree/bindings/iio/adc/axp20x_adc.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
new file mode 100644
index 0000000..1b60065
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
@@ -0,0 +1,24 @@
+X-Powers AXP20X and AXP22X PMIC Analog to Digital Converter (ADC)
+
+The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
+battery voltage, battery charge and discharge currents, AC-in and VBUS
+voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
+
+The AXP22X PMICs do not have all ADCs of the AXP20X though.
+
+Required properties:
+ - compatible, one of:
+ "x-powers,axp209-adc"
+ "x-powers,axp221-adc"
+ - #io-channel-cells = <1>;
+
+This is a subnode of the AXP20X PMIC.
+
+Example:
+
+&axp209 {
+ axp209_adc: axp209_adc {
+ compatible = "x-powers,axp209-adc";
+ #io-channel-cells = <1>;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 00/22] add support for AXP20X and AXP22X power supply drivers
From: Quentin Schulz @ 2017-01-02 16:37 UTC (permalink / raw)
To: linux-arm-kernel
The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose
information and data of the various power supplies they support such as
ACIN, battery and VBUS. For example, they expose the current battery
voltage, charge or discharge, as well as ACIN and VBUS current voltages
and currents, internal PMIC temperature and ADC on 2 different GPIOs
when in the right mode (for the AXP209 only).
The ACIN power supply driver is added by this patch. The AXP20X and
AXP22X can both read the status and the "usability" of the power supply
but only the AXP209 will be able to tell the current current and voltage
of the power supply by reading ADC channels. It is simply not supported
by the AXP22X PMICs.
The battery power supply driver is also added by this patch. The AXP20X
and AXP22X share most of their behaviour but have slight variations. The
allowed target voltages for battery charging are not the same, the
AXP22X PMIC are able to tell if the battery percentage computed by the
PMIC is trustworthy and they have different formulas for computing max
current for battery power supply. The driver is able to give the current
voltage and current of the battery (be it charging or discharging), the
maximal and minimal voltage and maximal current allowed for the battery,
whether the battery is present and usable and its capacity. It will get
the battery current current and voltage by reading the ADC channels. The
PMIC allows maximal voltages (4.36V for AXP20X and 4.22V and 4.24V for
AXP22X) that should not be used with Lithium-based batteries and since
this PMIC is supposed to be used with Lithium-based batteries, they have
been disabled. The values returned by the ADC driver are multipled by
1000 to scale from the mV returned by the ADC to the uV expected by the
power supply framework.
This series of patch adds DT bindings for ACIN power supply, ADC and
battery power supply drivers for AXP20X and AXP22X PMICs and their
documentation. It also enables the supported power supplies for the
Nextthing Co. CHIP and Sinlinx SinA33 boards.
The different drivers are also added to the MFD cells of the AXP20X and
AXP22X cells and the writeable and volatile regs updated to work with
the newly added drivers.
VBUS driver has intentionally not been modified to use the ADC channels
because a DT binding already exists for this driver. Migrating the
driver would mean to add an iio_map to map the ADC channels to the VBUS
driver (so we can use iio_channel_get and iio_read_channel_processed
functions). This slightly complexifies the VBUS driver only for
"cosmetic" changes. Feel free to give your two cents on the matter.
This series of patch is based on a previous upstreaming attempt done by
Bruno Pr?mont few months ago. It differs in three points: the ADC
driver does not tell the battery temperature (TS_IN) as I do not have a
board to test it with, it does not tell the instantaneous battery power
as it returns crazy values for me and finally no support for OCV curves
for the battery.
[RFC]
I want to take this series of patch as an opportunity to ask what we should
do with the OCV curves.
A battery voltage does not decrease linearly but decreases slowly near
maximum and minimal voltage and quickly most of the time.
By taking raw values without an OCV curve, the battery percentage (or
often wrongly named "capacity") is computed by approximating by a linear
function. This results in battery percentage not lasting the same
depending if the battery is full, almost empty or within those two
states. For example, a decrease of 40 points could take as much time as
a decrease of 5 points when in low battery. Without an OCV curve, the
battery percentage returned by the battery driver (as it is done today)
is absolute non-sense.
When an OCV curve is provided, the percentage is approximated by this
OCV curve and battery percentage are very more likely to last the same
time and thus, being trustworthy.
While I understand the kernel has absolutely nothing to do with OCV
computation, the AXP20X/AXP22X PMICs raise a question due to their
ability to compute the approximated battery percentage if we give them
the OCV curve of the battery in some of their registers. No computing
has to be done in the kernel, we just have to give them the OCV curve of
the battery and the PMIC will return the approximated percentage.
The question is how to do it? IMHO, two different approaches are possible:
- give the OCV curve points in the Device Tree,
This allows the OCV curve to be fixed for boards with a non-removable
battery. However, it also avoids changing batteries without
recompiling the DT, which is definitely not end-user friendly.
The DT is here for hardware definition and battery is hardware
definition I guess, so it makes sense in a way, but it does not work
for removable batteries.
- give the OCV curve points via the POWER_SUPPLY_PROP_VOLTAGE_OCV sysfs
entry in the Power Supply framework,
This allows the OCV curve to be changed when a user switches the
batteries, but it also means that the OCV curve will always have to
be submitted by a small boot script which means it is
rootfs-dependent. Not really cool for a hardware component which in
embedded systems is more than likely not to change (IMHO).
Maybe, the best would be the two approaches at the same time: the
OCV curve of the default battery in the DT and the possibility to modify
the OCV curve via the POWER_SUPPLY_PROP_VOLTAGE_OCV sysfs entry?
Thanks,
Quentin
Quentin Schulz (22):
dt-bindings: iio: adc: add AXP20X/AXP22X ADC DT binding
mfd: axp20x: add ADC data regs to volatile regs for AXP22X
iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
mfd: axp20x: add ADC cells for AXP20X and AXP22X PMICs
ARM: dtsi: axp209: add AXP209 ADC subnode
ARM: dtsi: axp22x: add AXP22X ADC subnode
dt-bindings: power: supply: add AXP20X/AXP22X AC power supply
power: supply: add AC power supply driver for AXP20X and AXP22X PMICs
mfd: axp20x: add AC power supply cells for AXP22X PMICs
ARM: dtsi: axp209: add AC power supply subnode
ARM: dtsi: axp22x: add AC power supply subnode
ARM: dts: sun8i: sina33: enable ACIN power supply subnode
ARM: sun5i: chip: enable ACIN power supply subnode
dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
mfd: axp20x: add CHRG_CTRL1 to writeable regs for AXP20X/AXP22X
mfd: axp20x: add V_OFF to writeable regs for AXP20X and AXP22X
power: supply: add battery driver for AXP20X and AXP22X PMICs
mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver
ARM: dtsi: axp209: add battery power supply subnode
ARM: dtsi: axp22x: add battery power supply subnode
ARM: dts: sun8i: sina33: enable battery power supply subnode
ARM: sun5i: chip: enable battery power supply subnode
.../devicetree/bindings/iio/adc/axp20x_adc.txt | 24 +
.../bindings/power/supply/axp20x_ac_power.txt | 27 ++
.../bindings/power/supply/axp20x_battery.txt | 24 +
arch/arm/boot/dts/axp209.dtsi | 19 +
arch/arm/boot/dts/axp22x.dtsi | 17 +
arch/arm/boot/dts/sun5i-r8-chip.dts | 8 +
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 8 +
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/axp20x_adc.c | 490 +++++++++++++++++++++
drivers/mfd/axp20x.c | 35 +-
drivers/power/supply/Kconfig | 24 +
drivers/power/supply/Makefile | 2 +
drivers/power/supply/axp20x_ac_power.c | 251 +++++++++++
drivers/power/supply/axp20x_battery.c | 458 +++++++++++++++++++
include/linux/mfd/axp20x.h | 4 +
16 files changed, 1400 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_ac_power.txt
create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
create mode 100644 drivers/iio/adc/axp20x_adc.c
create mode 100644 drivers/power/supply/axp20x_ac_power.c
create mode 100644 drivers/power/supply/axp20x_battery.c
--
2.9.3
^ permalink raw reply
* [PATCH] crypto: picoxcell - Fix module autoload for non-OF registration
From: Javier Martinez Canillas @ 2017-01-02 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2972455.z8LBYOSBAA@wuerfel>
On 01/02/2017 01:24 PM, Arnd Bergmann wrote:
> On Monday, January 2, 2017 1:13:24 PM CET Javier Martinez Canillas wrote:
>> Hello Arnd,
>>
>> On 01/02/2017 01:05 PM, Arnd Bergmann wrote:
>>> On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote:
>>>> If the driver is built as a module, autoload won't work because the module
>>>> alias information is not filled. So user-space can't match the registered
>>>> device with the corresponding module if the device isn't registered via OF.
>>>>
>>>> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>>>
>>> I think we can just remove the table, as the platform only supports
>>> booting through DT anyway.
>>>
>>
>> Agreed. I should had checked if mach-picoxcell was DT-only indeed.
>>
>> Should I also make the driver to depend on OF and remove the #ifdefery then?
>
> I don't think we need a dependency, the #ifdef checks in there were needed
> only to make the driver smaller if OF is disabled and it should still build
> fine if someone tries to compile it for CONFIG_COMPILE_TEST without
> CONFIG_OF.
>
OK, the driver doesn't depend on COMPILE_TEST though but I agree with you
since it seems the driver only has runtime but no build time dependencies
with ARCH_PICOXCELL.
> If we remove the platform ID, we can however also remove the
> spacc_is_compatible() function and just call of_device_is_compatible()
> in its place.
>
Yes.
> Arnd
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH] crypto: picoxcell - Fix module autoload for non-OF registration
From: Arnd Bergmann @ 2017-01-02 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ab87e239-6623-764b-998d-3d8148a6adf1@osg.samsung.com>
On Monday, January 2, 2017 1:13:24 PM CET Javier Martinez Canillas wrote:
> Hello Arnd,
>
> On 01/02/2017 01:05 PM, Arnd Bergmann wrote:
> > On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote:
> >> If the driver is built as a module, autoload won't work because the module
> >> alias information is not filled. So user-space can't match the registered
> >> device with the corresponding module if the device isn't registered via OF.
> >>
> >> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
> >
> > I think we can just remove the table, as the platform only supports
> > booting through DT anyway.
> >
>
> Agreed. I should had checked if mach-picoxcell was DT-only indeed.
>
> Should I also make the driver to depend on OF and remove the #ifdefery then?
I don't think we need a dependency, the #ifdef checks in there were needed
only to make the driver smaller if OF is disabled and it should still build
fine if someone tries to compile it for CONFIG_COMPILE_TEST without
CONFIG_OF.
If we remove the platform ID, we can however also remove the
spacc_is_compatible() function and just call of_device_is_compatible()
in its place.
Arnd
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2017-01-02 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0717c63b-2e29-9ad1-7f01-39817980933f@atmel.com>
On Mon, Jan 02, 2017 at 03:47:07PM +0100, Nicolas Ferre wrote:
> Le 02/01/2017 ? 12:31, Richard Cochran a ?crit :
> > This Cadence IP core is a complete disaster.
>
> Well, it evolved and propose several options to different SoC
> integrators. This is not something unusual...
> I suspect as well that some other network adapters have the same
> weakness concerning PTP timestamp in single register as the early
> revisions of this IP.
It appears that this core can neither latch the time on read or write,
or even latch time stamps. I have worked with many different PTP HW
implementations, even early ones like on the ixp4xx, and it is no
exaggeration to say that this one is uniquely broken.
> I suspect that Rafal tend to jump too quickly to the latest IP revisions
> and add more options to this series: let's not try to pour too much
> things into this code right now.
Why can't you check the IP version in the driver?
And is it really true that the registers don't latch the time stamps,
as Rafal said? If so, then we cannot accept the non-descriptor driver
version, since it cannot possibly work correctly.
Thanks,
Richard
^ permalink raw reply
* [PATCH] crypto: picoxcell - Fix module autoload for non-OF registration
From: Javier Martinez Canillas @ 2017-01-02 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2761495.aqgObxUbGB@wuerfel>
Hello Arnd,
On 01/02/2017 01:05 PM, Arnd Bergmann wrote:
> On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote:
>> If the driver is built as a module, autoload won't work because the module
>> alias information is not filled. So user-space can't match the registered
>> device with the corresponding module if the device isn't registered via OF.
>>
>> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> I think we can just remove the table, as the platform only supports
> booting through DT anyway.
>
Agreed. I should had checked if mach-picoxcell was DT-only indeed.
Should I also make the driver to depend on OF and remove the #ifdefery then?
> Arnd
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH] crypto: picoxcell - Fix module autoload for non-OF registration
From: Arnd Bergmann @ 2017-01-02 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483371482-4956-1-git-send-email-javier@osg.samsung.com>
On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module if the device isn't registered via OF.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
I think we can just remove the table, as the platform only supports
booting through DT anyway.
Arnd
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2017-01-02 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFcVECLg-hXvfgwRW-fxi+N0k=7pTaEMhS5EMXV9_OO+xGRUqA@mail.gmail.com>
On Mon, Jan 02, 2017 at 05:13:34PM +0530, Harini Katakam wrote:
> From the revision history of Cadence spec, all versions starting
> r1p02 have ability to include timestamp in descriptors.
So why not add code to read the version, hm?
> For previous versions the event register is the only option.
And is it true that the regsiters do not latch the time stamp?
If so, then the IP core is more than useless.
Thanks,
Richard
^ permalink raw reply
* [PATCH v2 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Appana Durga Kedareswara Rao @ 2017-01-02 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <45807619-bf6a-0174-c102-12c03aeb575c@synopsys.com>
Hi Jose Miguel Abreu,
Thanks for the review...
[snip]...
>
> I just noticed there is a write to XILINX_DMA_REG_FRMSTORE which, by the
> description in the VDMA databook, allows to modify the total number of
> framebuffers.
>
> Does it correct this situation: Lets assume VDMA has 10 framebuffers in HW and
> user only submits 5 descriptors. Then vsize will be programmed and VDMA will
> start. The VDMA will start in fb 1, then 2, ... until 5 its all ok. But then after the fb
> 5 the VDMA will jump to fb 6, this fb will have no address because the user only
> submitted 5 addresses so VDMA will try to write to location 0x0 of system mem
> (if using S2MM channel). ?
>
> If so then there is no race condition, but the HW image that I have does not
> have this register enabled so I was getting this result (memory corruption
> because not all framebuffers had addresses set).
Thanks for the explanation.
Agree the issue that you mentioned won't come when XILINX_DMA_REG_FRMSTORE
(C_ENABLE_DEBUG_INFO_5 and C_ENABLE_DEBUG_INFO_13) Register is enabled in the IP.
But this register won't get enabled with the default IP configuration (C_ENABLE_DEBUG_INFO_5 and C_ENABLE_DEBUG_INFO_13).
When user is not enabled XILINX_DMA_REG_FRMSTORE in the h/w and submits frames less than h/w capable.
The solution that I am thinking is to throw an error in the driver saying that either enable the
num frame store feature in the IP or submit the frames up to h/w capable what do you think???
Regards,
Kedar.
>
> Best regards,
> Jose Miguel Abreu
>
> >
> > Regards,
> > Kedar.
> >
> >> Best regards,
> >> Jose Miguel Abreu
> >>
^ permalink raw reply
* [GIT PULL] ARM: exynos: Late mach/soc for v4.10
From: Krzysztof Kozlowski @ 2017-01-02 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5b0e55c8-01db-3f02-3526-2f71f4a73d88@samsung.com>
On Mon, Jan 02, 2017 at 10:20:21AM +0100, Sylwester Nawrocki wrote:
> On 12/30/2016 04:53 PM, Krzysztof Kozlowski wrote:
> >
> > Any comments on this? I guess it won't come as late-late-4.10, so can
> > you pull it for v4.11?
>
> >> Sylwester Nawrocki (1):
> >> ARM: S3C24XX: Add DMA slave maps for remaining s3c24xx SoCs
>
> We need this patch in v4.10 to avoid possible I2S and MMC regressions
> on selected s3c24xx SoC, since the DMA clients are already modified.
> If the patch goes in only for v4.11 it would be good to mark it for
> inclusion in v4.10 stable kernels.
You didn't mention any strict dependencies when sending this patch...
What do you mean by "needing patch in v4.10"? Is the code already
not bisectable? Already broken?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] crypto: picoxcell - Fix module autoload for non-OF registration
From: Javier Martinez Canillas @ 2017-01-02 15:38 UTC (permalink / raw)
To: linux-arm-kernel
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module if the device isn't registered via OF.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/crypto/picoxcell_crypto.ko | grep alias
alias: of:N*T*Cpicochip,spacc-l2C*
alias: of:N*T*Cpicochip,spacc-l2
alias: of:N*T*Cpicochip,spacc-ipsecC*
alias: of:N*T*Cpicochip,spacc-ipsec
After this patch:
$ modinfo drivers/crypto/picoxcell_crypto.ko | grep alias
alias: of:N*T*Cpicochip,spacc-l2C*
alias: of:N*T*Cpicochip,spacc-l2
alias: of:N*T*Cpicochip,spacc-ipsecC*
alias: of:N*T*Cpicochip,spacc-ipsec
alias: platform:picochip,spacc-l2
alias: platform:picochip,spacc-ipsec
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/crypto/picoxcell_crypto.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c
index 47576098831f..64449b7c00af 100644
--- a/drivers/crypto/picoxcell_crypto.c
+++ b/drivers/crypto/picoxcell_crypto.c
@@ -1808,6 +1808,7 @@ static const struct platform_device_id spacc_id_table[] = {
{ "picochip,spacc-l2", },
{ }
};
+MODULE_DEVICE_TABLE(platform, spacc_id_table);
static struct platform_driver spacc_driver = {
.probe = spacc_probe,
--
2.7.4
^ permalink raw reply related
* [PATCH 5/5] ARM: dts: armada388-clearfog: move uart nodes
From: Russell King @ 2017-01-02 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO4UH-0008SR-GW@rmk-PC.armlinux.org.uk>
Move the uart nodes over to use the label form to reference the serial
devices, rather than replicating the device node path.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/armada-388-clearfog.dtsi | 14 +++++++-------
arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 12 ++++++------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index 6149699eefc2..0f5938bede53 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -93,13 +93,6 @@
wp-inverted;
};
- serial at 12100 {
- /* mikrobus uart */
- pinctrl-0 = <&mikro_uart_pins>;
- pinctrl-names = "default";
- status = "okay";
- };
-
usb at 58000 {
/* CON3, nearest power. */
status = "okay";
@@ -305,3 +298,10 @@
pinctrl-names = "default";
status = "okay";
};
+
+&uart1 {
+ /* mikrobus uart */
+ pinctrl-0 = <&mikro_uart_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
index 681962a6395b..458884ff4c8c 100644
--- a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
@@ -69,12 +69,6 @@
*/
status = "okay";
};
-
- serial at 12000 {
- pinctrl-0 = <&uart0_pins>;
- pinctrl-names = "default";
- status = "okay";
- };
};
};
};
@@ -144,3 +138,9 @@
status = "disabled";
};
};
+
+&uart0 {
+ pinctrl-0 = <&uart0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: armada388-clearfog: move ethernet related nodes
From: Russell King @ 2017-01-02 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO4UH-0008SR-GW@rmk-PC.armlinux.org.uk>
Move the ethernet, buffer manager, and mdio nodes over to use label form
to reference the devices rather than replicating the device path.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/armada-388-clearfog.dtsi | 44 +++++++------
.../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 76 +++++++++++-----------
2 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index eeb845bbe3f3..6149699eefc2 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -71,27 +71,6 @@
soc {
internal-regs {
- ethernet at 30000 {
- phy-mode = "sgmii";
- buffer-manager = <&bm>;
- bm,pool-long = <2>;
- bm,pool-short = <1>;
- status = "okay";
- };
-
- ethernet at 34000 {
- phy-mode = "sgmii";
- buffer-manager = <&bm>;
- bm,pool-long = <3>;
- bm,pool-short = <1>;
- status = "okay";
-
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
-
sata at a8000 {
/* pinctrl? */
status = "okay";
@@ -147,6 +126,29 @@
};
};
+ð1 {
+ /* ethernet at 30000 */
+ bm,pool-long = <2>;
+ bm,pool-short = <1>;
+ buffer-manager = <&bm>;
+ phy-mode = "sgmii";
+ status = "okay";
+};
+
+ð2 {
+ /* ethernet at 34000 */
+ bm,pool-long = <3>;
+ bm,pool-short = <1>;
+ buffer-manager = <&bm>;
+ phy-mode = "sgmii";
+ status = "okay";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
&i2c0 {
/* Is there anything on this? */
clock-frequency = <100000>;
diff --git a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
index e397421d1531..681962a6395b 100644
--- a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
@@ -62,38 +62,6 @@
MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
internal-regs {
- ethernet at 70000 {
- pinctrl-0 = <&ge0_rgmii_pins>;
- pinctrl-names = "default";
- phy = <&phy_dedicated>;
- phy-mode = "rgmii-id";
- buffer-manager = <&bm>;
- bm,pool-long = <0>;
- bm,pool-short = <1>;
- status = "okay";
- };
-
- mdio at 72004 {
- /*
- * Add the phy clock here, so the phy can be
- * accessed to read its IDs prior to binding
- * with the driver.
- */
- pinctrl-0 = <&mdio_pins µsom_phy_clk_pins>;
- pinctrl-names = "default";
-
- phy_dedicated: ethernet-phy at 0 {
- /*
- * Annoyingly, the marvell phy driver
- * configures the LED register, rather
- * than preserving reset-loaded setting.
- * We undo that rubbish here.
- */
- marvell,reg-init = <3 16 0 0x101e>;
- reg = <0>;
- };
- };
-
rtc at a3800 {
/*
* If the rtc doesn't work, run "date reset"
@@ -107,16 +75,46 @@
pinctrl-names = "default";
status = "okay";
};
-
- bm at c8000 {
- status = "okay";
- };
};
+ };
+};
- bm-bppi {
- status = "okay";
- };
+&bm {
+ status = "okay";
+};
+
+&bm_bppi {
+ status = "okay";
+};
+
+ð0 {
+ /* ethernet at 70000 */
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ pinctrl-names = "default";
+ phy = <&phy_dedicated>;
+ phy-mode = "rgmii-id";
+ buffer-manager = <&bm>;
+ bm,pool-long = <0>;
+ bm,pool-short = <1>;
+ status = "okay";
+};
+
+&mdio {
+ /*
+ * Add the phy clock here, so the phy can be accessed to read its
+ * IDs prior to binding with the driver.
+ */
+ pinctrl-0 = <&mdio_pins µsom_phy_clk_pins>;
+ pinctrl-names = "default";
+ phy_dedicated: ethernet-phy at 0 {
+ /*
+ * Annoyingly, the marvell phy driver configures the LED
+ * register, rather than preserving reset-loaded setting.
+ * We undo that rubbish here.
+ */
+ marvell,reg-init = <3 16 0 0x101e>;
+ reg = <0>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: armada388-clearfog: move I2C nodes
From: Russell King @ 2017-01-02 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO4UH-0008SR-GW@rmk-PC.armlinux.org.uk>
Move the I2C nodes over to use the label form to reference the I2C
controllers, rather than replicating the device node path.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/armada-388-clearfog.dtsi | 245 ++++++++++++++---------------
1 file changed, 120 insertions(+), 125 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index 7946400b4bf2..eeb845bbe3f3 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -92,131 +92,6 @@
};
};
- i2c at 11000 {
- /* Is there anything on this? */
- clock-frequency = <100000>;
- pinctrl-0 = <&i2c0_pins>;
- pinctrl-names = "default";
- status = "okay";
-
- /*
- * PCA9655 GPIO expander, up to 1MHz clock.
- * 0-CON3 CLKREQ#
- * 1-CON3 PERST#
- * 2-
- * 3-CON3 W_DISABLE
- * 4-
- * 5-USB3 overcurrent
- * 6-USB3 power
- * 7-
- * 8-JP4 P1
- * 9-JP4 P4
- * 10-JP4 P5
- * 11-m.2 DEVSLP
- * 12-SFP_LOS
- * 13-SFP_TX_FAULT
- * 14-SFP_TX_DISABLE
- * 15-SFP_MOD_DEF0
- */
- expander0: gpio-expander at 20 {
- /*
- * This is how it should be:
- * compatible = "onnn,pca9655",
- * "nxp,pca9555";
- * but you can't do this because of
- * the way I2C works.
- */
- compatible = "nxp,pca9555";
- gpio-controller;
- #gpio-cells = <2>;
- reg = <0x20>;
-
- pcie1_0_clkreq {
- gpio-hog;
- gpios = <0 GPIO_ACTIVE_LOW>;
- input;
- line-name = "pcie1.0-clkreq";
- };
- pcie1_0_w_disable {
- gpio-hog;
- gpios = <3 GPIO_ACTIVE_LOW>;
- output-low;
- line-name = "pcie1.0-w-disable";
- };
- usb3_ilimit {
- gpio-hog;
- gpios = <5 GPIO_ACTIVE_LOW>;
- input;
- line-name = "usb3-current-limit";
- };
- usb3_power {
- gpio-hog;
- gpios = <6 GPIO_ACTIVE_HIGH>;
- output-high;
- line-name = "usb3-power";
- };
- m2_devslp {
- gpio-hog;
- gpios = <11 GPIO_ACTIVE_HIGH>;
- output-low;
- line-name = "m.2 devslp";
- };
- sfp_los {
- /* SFP loss of signal */
- gpio-hog;
- gpios = <12 GPIO_ACTIVE_HIGH>;
- input;
- line-name = "sfp-los";
- };
- sfp_tx_fault {
- /* SFP laser fault */
- gpio-hog;
- gpios = <13 GPIO_ACTIVE_HIGH>;
- input;
- line-name = "sfp-tx-fault";
- };
- sfp_tx_disable {
- /* SFP transmit disable */
- gpio-hog;
- gpios = <14 GPIO_ACTIVE_HIGH>;
- output-low;
- line-name = "sfp-tx-disable";
- };
- sfp_mod_def0 {
- /* SFP module present */
- gpio-hog;
- gpios = <15 GPIO_ACTIVE_LOW>;
- input;
- line-name = "sfp-mod-def0";
- };
- };
-
- /* The MCP3021 is 100kHz clock only */
- mikrobus_adc: mcp3021 at 4c {
- compatible = "microchip,mcp3021";
- reg = <0x4c>;
- };
-
- /* Also something at 0x64 */
- };
-
- i2c at 11100 {
- /*
- * Routed to SFP, mikrobus, and PCIe.
- * SFP limits this to 100kHz, and requires
- * an AT24C01A/02/04 with address pins tied
- * low, which takes addresses 0x50 and 0x51.
- * Mikrobus doesn't specify beyond an I2C
- * bus being present.
- * PCIe uses ARP to assign addresses, or
- * 0x63-0x64.
- */
- clock-frequency = <100000>;
- pinctrl-0 = <&clearfog_i2c1_pins>;
- pinctrl-names = "default";
- status = "okay";
- };
-
sata at a8000 {
/* pinctrl? */
status = "okay";
@@ -272,6 +147,126 @@
};
};
+&i2c0 {
+ /* Is there anything on this? */
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /*
+ * PCA9655 GPIO expander, up to 1MHz clock.
+ * 0-CON3 CLKREQ#
+ * 1-CON3 PERST#
+ * 2-
+ * 3-CON3 W_DISABLE
+ * 4-
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ * 7-
+ * 8-JP4 P1
+ * 9-JP4 P4
+ * 10-JP4 P5
+ * 11-m.2 DEVSLP
+ * 12-SFP_LOS
+ * 13-SFP_TX_FAULT
+ * 14-SFP_TX_DISABLE
+ * 15-SFP_MOD_DEF0
+ */
+ expander0: gpio-expander at 20 {
+ /*
+ * This is how it should be:
+ * compatible = "onnn,pca9655", "nxp,pca9555";
+ * but you can't do this because of the way I2C works.
+ */
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+
+ pcie1_0_clkreq {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "pcie1.0-clkreq";
+ };
+ pcie1_0_w_disable {
+ gpio-hog;
+ gpios = <3 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "pcie1.0-w-disable";
+ };
+ usb3_ilimit {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "usb3-current-limit";
+ };
+ usb3_power {
+ gpio-hog;
+ gpios = <6 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "usb3-power";
+ };
+ m2_devslp {
+ gpio-hog;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "m.2 devslp";
+ };
+ sfp_los {
+ /* SFP loss of signal */
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "sfp-los";
+ };
+ sfp_tx_fault {
+ /* SFP laser fault */
+ gpio-hog;
+ gpios = <13 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "sfp-tx-fault";
+ };
+ sfp_tx_disable {
+ /* SFP transmit disable */
+ gpio-hog;
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "sfp-tx-disable";
+ };
+ sfp_mod_def0 {
+ /* SFP module present */
+ gpio-hog;
+ gpios = <15 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "sfp-mod-def0";
+ };
+ };
+
+ /* The MCP3021 is 100kHz clock only */
+ mikrobus_adc: mcp3021 at 4c {
+ compatible = "microchip,mcp3021";
+ reg = <0x4c>;
+ };
+
+ /* Also something at 0x64 */
+};
+
+&i2c1 {
+ /*
+ * Routed to SFP, mikrobus, and PCIe.
+ * SFP limits this to 100kHz, and requires an AT24C01A/02/04 with
+ * address pins tied low, which takes addresses 0x50 and 0x51.
+ * Mikrobus doesn't specify beyond an I2C bus being present.
+ * PCIe uses ARP to assign addresses, or 0x63-0x64.
+ */
+ clock-frequency = <100000>;
+ pinctrl-0 = <&clearfog_i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&pinctrl {
clearfog_i2c1_pins: i2c1-pins {
/* SFP, PCIe, mSATA, mikrobus */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: armada388-clearfog: move device specific pinctrl nodes
From: Russell King @ 2017-01-02 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO4UH-0008SR-GW@rmk-PC.armlinux.org.uk>
Move the device specific pinctrl nodes over to use the label form to
reference the pin mux controller, rather than replicating the device
node path.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/armada-388-clearfog.dtsi | 50 +++++++++++-----------
.../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 27 ++++++------
2 files changed, 38 insertions(+), 39 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index 770d4bff6884..7946400b4bf2 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -217,31 +217,6 @@
status = "okay";
};
- pinctrl at 18000 {
- clearfog_i2c1_pins: i2c1-pins {
- /* SFP, PCIe, mSATA, mikrobus */
- marvell,pins = "mpp26", "mpp27";
- marvell,function = "i2c1";
- };
- clearfog_sdhci_cd_pins: clearfog-sdhci-cd-pins {
- marvell,pins = "mpp20";
- marvell,function = "gpio";
- };
- mikro_pins: mikro-pins {
- /* int: mpp22 rst: mpp29 */
- marvell,pins = "mpp22", "mpp29";
- marvell,function = "gpio";
- };
- mikro_spi_pins: mikro-spi-pins {
- marvell,pins = "mpp43";
- marvell,function = "spi1";
- };
- mikro_uart_pins: mikro-uart-pins {
- marvell,pins = "mpp24", "mpp25";
- marvell,function = "ua1";
- };
- };
-
sata at a8000 {
/* pinctrl? */
status = "okay";
@@ -297,6 +272,31 @@
};
};
+&pinctrl {
+ clearfog_i2c1_pins: i2c1-pins {
+ /* SFP, PCIe, mSATA, mikrobus */
+ marvell,pins = "mpp26", "mpp27";
+ marvell,function = "i2c1";
+ };
+ clearfog_sdhci_cd_pins: clearfog-sdhci-cd-pins {
+ marvell,pins = "mpp20";
+ marvell,function = "gpio";
+ };
+ mikro_pins: mikro-pins {
+ /* int: mpp22 rst: mpp29 */
+ marvell,pins = "mpp22", "mpp29";
+ marvell,function = "gpio";
+ };
+ mikro_spi_pins: mikro-spi-pins {
+ marvell,pins = "mpp43";
+ marvell,function = "spi1";
+ };
+ mikro_uart_pins: mikro-uart-pins {
+ marvell,pins = "mpp24", "mpp25";
+ marvell,function = "ua1";
+ };
+};
+
&spi1 {
/*
* Add SPI CS pins for clearfog:
diff --git a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
index 6608657b9994..e397421d1531 100644
--- a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
@@ -94,20 +94,6 @@
};
};
- pinctrl at 18000 {
- microsom_phy_clk_pins: microsom-phy-clk-pins {
- marvell,pins = "mpp45";
- marvell,function = "ref";
- };
- /* Optional eMMC */
- microsom_sdhci_pins: microsom-sdhci-pins {
- marvell,pins = "mpp21", "mpp28",
- "mpp37", "mpp38",
- "mpp39", "mpp40";
- marvell,function = "sd0";
- };
- };
-
rtc at a3800 {
/*
* If the rtc doesn't work, run "date reset"
@@ -134,6 +120,19 @@
};
};
+&pinctrl {
+ microsom_phy_clk_pins: microsom-phy-clk-pins {
+ marvell,pins = "mpp45";
+ marvell,function = "ref";
+ };
+ /* Optional eMMC */
+ microsom_sdhci_pins: microsom-sdhci-pins {
+ marvell,pins = "mpp21", "mpp28", "mpp37",
+ "mpp38", "mpp39", "mpp40";
+ marvell,function = "sd0";
+ };
+};
+
&spi1 {
/* The microsom has an optional W25Q32 on board, connected to CS0 */
pinctrl-0 = <&spi1_pins>;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] ARM: dts: armada388-clearfog: add phy reset gpio-hog
From: Russell King @ 2017-01-02 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO4UH-0008SR-GW@rmk-PC.armlinux.org.uk>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/armada-388-clearfog-base.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/armada-388-clearfog-base.dts b/arch/arm/boot/dts/armada-388-clearfog-base.dts
index f86e1876fb38..da788ea40717 100644
--- a/arch/arm/boot/dts/armada-388-clearfog-base.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog-base.dts
@@ -74,7 +74,17 @@
phy = <&phy1>;
};
+&gpio0 {
+ phy1_reset {
+ gpio-hog;
+ gpios = <19 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "phy1-reset";
+ };
+};
+
&mdio {
+ pinctrl-0 = <&mdio_pins µsom_phy_clk_pins &clearfog_phy_pins>;
phy1: ethernet-phy at 1 {
/*
* Annoyingly, the marvell phy driver configures the LED
@@ -87,6 +97,11 @@
};
&pinctrl {
+ /* phy1 reset */
+ clearfog_phy_pins: clearfog-phy-pins {
+ marvell,pins = "mpp19";
+ marvell,function = "gpio";
+ };
rear_button_pins: rear-button-pins {
marvell,pins = "mpp44";
marvell,function = "gpio";
--
2.7.4
^ permalink raw reply related
* [RFC v2 PATCH 1/3] ARM: NOMMU: introduce dma operations for noMMU
From: Benjamin Gaignard @ 2017-01-02 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636704-18948-2-git-send-email-vladimir.murzin@arm.com>
Hello Vladimir,
I have tested your patch on my setup (stm32f4: no MMU, no MPU) where
I'm writing display driver.
This driver use dma_alloc_wc() and dma_mmap_wc() for frame buffer
allocation and mmapping.
In dma-mapping-nommu.c you haven't implement dma_map_ops.mmap so
obviously my driver
doesn't work with your code.
In current implementation it is buggy too but I submit a patch to fix
that problem:
http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
Could it be possible for you to include mmap support in dma-mapping-nommu.c ?
Regards,
Benjamin
2016-12-13 14:45 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
> R/M classes of cpus can have momory covered by MPU which in turn might
> configure RAM as Normal i.e. bufferable and cacheable. It breaks
> dma_alloc_coherent() and friends, since data can stuck in caches now
> or be buffered.
>
> This patch introduces the way to specify region of memory (via
> "memdma=size at start" command line option) suitable for consistent DMA
> operations. It is supposed that such region is marked by MPU as
> non-cacheable.
>
> For configuration without cache support (like Cortex-M3/M4) dma
> operations are forced to be coherent and wired with dma-noop. Such
> decision is made based on cacheid global variable. In case cpu
> supports caches and no coherent memory region is given - dma is
> disallowed.
>
> Reported-by: Alexandre Torgue <alexandre.torgue@st.com>
> Reported-by: Andras Szemzo <sza@esh.hu>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> arch/arm/include/asm/dma-mapping.h | 3 +-
> arch/arm/mm/Makefile | 5 +-
> arch/arm/mm/dma-mapping-nommu.c | 262 ++++++++++++++++++++++++++++++++++++
> arch/arm/mm/mm.h | 3 +
> arch/arm/mm/nommu.c | 6 +
> 5 files changed, 275 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index bf02dbd..559faad 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -20,7 +20,8 @@ static inline struct dma_map_ops *__generic_dma_ops(struct device *dev)
> {
> if (dev && dev->archdata.dma_ops)
> return dev->archdata.dma_ops;
> - return &arm_dma_ops;
> +
> + return IS_ENABLED(CONFIG_MMU) ? &arm_dma_ops : &dma_noop_ops;
> }
>
> static inline struct dma_map_ops *get_dma_ops(struct device *dev)
> diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
> index 2ac7988..5796357 100644
> --- a/arch/arm/mm/Makefile
> +++ b/arch/arm/mm/Makefile
> @@ -2,9 +2,8 @@
> # Makefile for the linux arm-specific parts of the memory manager.
> #
>
> -obj-y := dma-mapping.o extable.o fault.o init.o \
> - iomap.o
> -
> +obj-y := extable.o fault.o init.o iomap.o
> +obj-y += dma-mapping$(MMUEXT).o
> obj-$(CONFIG_MMU) += fault-armv.o flush.o idmap.o ioremap.o \
> mmap.o pgd.o mmu.o pageattr.o
>
> diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
> new file mode 100644
> index 0000000..f92d98a
> --- /dev/null
> +++ b/arch/arm/mm/dma-mapping-nommu.c
> @@ -0,0 +1,262 @@
> +/*
> + * Based on linux/arch/arm/mm/dma-mapping.c
> + *
> + * Copyright (C) 2000-2004 Russell King
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * DMA uncached mapping support.
> + */
> +
> +#include <linux/export.h>
> +#include <linux/mm.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/scatterlist.h>
> +#include <linux/genalloc.h>
> +
> +#include <asm/cachetype.h>
> +#include <asm/cacheflush.h>
> +#include <asm/outercache.h>
> +
> +#include "dma.h"
> +
> +unsigned long dma_start __initdata;
> +unsigned long dma_size __initdata;
> +
> +static struct gen_pool *dma_pool;
> +
> +static void *arm_nommu_dma_alloc(struct device *dev, size_t size,
> + dma_addr_t *dma_handle, gfp_t gfp,
> + unsigned long attrs)
> +{
> + void *ptr;
> +
> + if (!dma_pool)
> + return NULL;
> +
> + ptr = (void *)gen_pool_alloc(dma_pool, size);
> + if (ptr) {
> + *dma_handle = __pa(ptr);
> + dmac_flush_range(ptr, ptr + size);
> + outer_flush_range(__pa(ptr), __pa(ptr) + size);
> + }
> +
> + return ptr;
> +}
> +
> +static void arm_nommu_dma_free(struct device *dev, size_t size,
> + void *cpu_addr, dma_addr_t dma_addr,
> + unsigned long attrs)
> +{
> + gen_pool_free(dma_pool, (unsigned long)cpu_addr, size);
> +}
> +
> +static void __dma_page_cpu_to_dev(dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + dmac_map_area(__va(handle), size, dir);
> +
> + if (dir == DMA_FROM_DEVICE)
> + outer_inv_range(handle, handle + size);
> + else
> + outer_clean_range(handle, handle + size);
> +}
> +
> +static void __dma_page_dev_to_cpu(dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + if (dir != DMA_TO_DEVICE) {
> + outer_inv_range(handle, handle + size);
> + dmac_unmap_area(__va(handle), size, dir);
> + }
> +}
> +
> +static dma_addr_t arm_nommu_dma_map_page(struct device *dev, struct page *page,
> + unsigned long offset, size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + dma_addr_t handle = page_to_phys(page) + offset;
> +
> + __dma_page_cpu_to_dev(handle, size, dir);
> +
> + return handle;
> +}
> +
> +static void arm_nommu_dma_unmap_page(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir, unsigned long attrs)
> +{
> + __dma_page_dev_to_cpu(handle, size, dir);
> +}
> +
> +
> +static int arm_nommu_dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int i;
> + struct scatterlist *sg;
> +
> + for_each_sg(sgl, sg, nents, i) {
> + sg_dma_address(sg) = sg_phys(sg);
> + sg_dma_len(sg) = sg->length;
> + __dma_page_cpu_to_dev(sg_dma_address(sg), sg_dma_len(sg), dir);
> + }
> +
> + return nents;
> +}
> +
> +static void arm_nommu_dma_unmap_sg(struct device *dev, struct scatterlist *sgl, int nents,
> + enum dma_data_direction dir, unsigned long attrs)
> +{
> + struct scatterlist *sg;
> + int i;
> +
> + for_each_sg(sgl, sg, nents, i)
> + __dma_page_dev_to_cpu(sg_dma_address(sg), sg_dma_len(sg), dir);
> +}
> +
> +static void arm_nommu_dma_sync_single_for_device(struct device *dev,
> + dma_addr_t handle, size_t size, enum dma_data_direction dir)
> +{
> + __dma_page_cpu_to_dev(handle, size, dir);
> +}
> +
> +static void arm_nommu_dma_sync_single_for_cpu(struct device *dev,
> + dma_addr_t handle, size_t size, enum dma_data_direction dir)
> +{
> + __dma_page_cpu_to_dev(handle, size, dir);
> +}
> +
> +static void arm_nommu_dma_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
> + int nents, enum dma_data_direction dir)
> +{
> + struct scatterlist *sg;
> + int i;
> +
> + for_each_sg(sgl, sg, nents, i)
> + __dma_page_cpu_to_dev(sg_dma_address(sg), sg_dma_len(sg), dir);
> +}
> +
> +static void arm_nommu_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sgl,
> + int nents, enum dma_data_direction dir)
> +{
> + struct scatterlist *sg;
> + int i;
> +
> + for_each_sg(sgl, sg, nents, i)
> + __dma_page_dev_to_cpu(sg_dma_address(sg), sg_dma_len(sg), dir);
> +}
> +
> +struct dma_map_ops arm_nommu_dma_ops = {
> + .alloc = arm_nommu_dma_alloc,
> + .free = arm_nommu_dma_free,
> + .map_page = arm_nommu_dma_map_page,
> + .unmap_page = arm_nommu_dma_unmap_page,
> + .map_sg = arm_nommu_dma_map_sg,
> + .unmap_sg = arm_nommu_dma_unmap_sg,
> + .sync_single_for_device = arm_nommu_dma_sync_single_for_device,
> + .sync_single_for_cpu = arm_nommu_dma_sync_single_for_cpu,
> + .sync_sg_for_device = arm_nommu_dma_sync_sg_for_device,
> + .sync_sg_for_cpu = arm_nommu_dma_sync_sg_for_cpu,
> +};
> +EXPORT_SYMBOL(arm_nommu_dma_ops);
> +
> +static struct dma_map_ops *arm_nommu_get_dma_map_ops(bool coherent)
> +{
> + return coherent ? &dma_noop_ops : &arm_nommu_dma_ops;
> +}
> +
> +void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> + const struct iommu_ops *iommu, bool coherent)
> +{
> + struct dma_map_ops *dma_ops;
> +
> + /*
> + * Cahe support for v7m is optional, so can be treated as
> + * coherent if no cache has been detected.
> + */
> + dev->archdata.dma_coherent = (cacheid) ? coherent : true;
> +
> + dma_ops = arm_nommu_get_dma_map_ops(dev->archdata.dma_coherent);
> +
> + set_dma_ops(dev, dma_ops);
> +}
> +
> +void arch_teardown_dma_ops(struct device *dev)
> +{
> +}
> +
> +int dma_supported(struct device *dev, u64 mask)
> +{
> + if (cacheid && !dma_pool)
> + return 0;
> +
> + return 1;
> +}
> +
> +EXPORT_SYMBOL(dma_supported);
> +
> +#define PREALLOC_DMA_DEBUG_ENTRIES 4096
> +
> +static int __init dma_debug_do_init(void)
> +{
> + dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
> + return 0;
> +}
> +core_initcall(dma_debug_do_init);
> +
> +/*
> + * Initialise the coherent pool for DMA allocations.
> + */
> +static int __init dma_pool_init(void)
> +{
> + int ret;
> +
> + if (cacheid && !dma_size) {
> + pr_warn("DMA: coherent memory region has not been given.\n");
> + return 0;
> + }
> +
> + dma_pool = gen_pool_create(PAGE_SHIFT, -1);
> +
> + if (!dma_pool)
> + goto out;
> +
> + ret = gen_pool_add_virt(dma_pool, (unsigned long)dma_start, (unsigned long)dma_start,
> + dma_size, -1);
> + if (ret)
> + goto destroy_genpool;
> +
> + gen_pool_set_algo(dma_pool, gen_pool_first_fit_order_align, NULL);
> +
> + pr_info("DMA: coherent memory region 0x%lx - 0x%lx (%lu KiB)\n",
> + dma_start, dma_start + dma_size, dma_size >> 10);
> +
> + return 0;
> +
> +destroy_genpool:
> + gen_pool_destroy(dma_pool);
> + dma_pool = NULL;
> +out:
> + pr_err("DMA: failed to allocate coherent memory region\n");
> + return -ENOMEM;
> +}
> +
> +postcore_initcall(dma_pool_init);
> +
> +/* "memdma=<size>@<address>" parsing. */
> +static int __init early_memdma(char *p)
> +{
> + if (!p)
> + return -EINVAL;
> +
> + dma_size = memparse(p, &p);
> + if (*p == '@')
> + dma_start = memparse(p + 1, &p);
> +
> + return 0;
> +}
> +early_param("memdma", early_memdma);
> diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
> index ce727d4..18eb869 100644
> --- a/arch/arm/mm/mm.h
> +++ b/arch/arm/mm/mm.h
> @@ -97,3 +97,6 @@ struct static_vm {
> void dma_contiguous_remap(void);
>
> unsigned long __clear_cr(unsigned long mask);
> +
> +extern unsigned long dma_start __initdata;
> +extern unsigned long dma_size __initdata;
> diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
> index 681cec8..5827e54 100644
> --- a/arch/arm/mm/nommu.c
> +++ b/arch/arm/mm/nommu.c
> @@ -303,6 +303,12 @@ void __init sanity_check_meminfo(void)
> end = memblock_end_of_DRAM();
> high_memory = __va(end - 1) + 1;
> memblock_set_current_limit(end);
> +
> + if (dma_size &&
> + memblock_overlaps_region(&memblock.memory, dma_start, dma_size)) {
> + pr_crit("DMA: coherent memory region overlaps with main memory.\n");
> + dma_size = 0;
> + }
> }
>
> /*
> --
> 1.7.9.5
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 0/5] ARM: dts: armada388: rework clearfog's .dtsi references
From: Russell King @ 2017-01-02 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO454-00083C-Tj@rmk-PC.armlinux.org.uk>
This patch series, based upon the previous series adding Clearfog Base
support, reworks the clearfog .dtsi file to reference nodes by label
rather than by path.
Not everything is moved - just those which had labels at the time the
patches were created.
arch/arm/boot/dts/armada-388-clearfog-base.dts | 15 +
arch/arm/boot/dts/armada-388-clearfog.dtsi | 353 ++++++++++-----------
.../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 113 ++++---
3 files changed, 245 insertions(+), 236 deletions(-)
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Russell King - ARM Linux @ 2017-01-02 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda2gdjM--LSoJTL0dvqyw796w1hMSAhUQwv9X0EPzJHig@mail.gmail.com>
On Mon, Jan 02, 2017 at 03:34:32PM +0100, Linus Walleij wrote:
> in the first line of arch_hw_breakpoint_init() in
> arch/arm/kernel/hw_breakpoint.c
>
> I suspect that is not an accepable solution ...
>
> It hangs at PC is at write_wb_reg+0x20c/0x330
> Which is c03101dc, and looks like this in objdump -d:
>
> c031020c: ee001eba mcr 14, 0, r1, cr0, cr10, {5}
> c0310210: eaffffb3 b c03100e4 <write_wb_reg+0x114>
... and this is several instructions after the address you mention above.
Presumably c03101dc is accessing a higher numbered register?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 9/9] ARM: dts: armada388-clearfog: add pro model DTS file
From: Russell King @ 2017-01-02 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO43Q-0007yJ-ON@rmk-PC.armlinux.org.uk>
Add the DTS file to describe the clearfog pro model - we update the
platform name and compatible string compared to the original version.
The original version remains for compatibility for the time being as
the name of the file has become established, and the machine name
and/or compatible may be used by userspace.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-clearfog-pro.dts | 55 +++++++++++++++++++++++++++
2 files changed, 56 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-clearfog-pro.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 22d2ca2b52ec..8cf288f8b84f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -922,6 +922,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-linksys-cobra.dtb \
armada-388-clearfog.dtb \
armada-388-clearfog-base.dtb \
+ armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
armada-388-rd.dtb
diff --git a/arch/arm/boot/dts/armada-388-clearfog-pro.dts b/arch/arm/boot/dts/armada-388-clearfog-pro.dts
new file mode 100644
index 000000000000..e0c630a4d92c
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-clearfog-pro.dts
@@ -0,0 +1,55 @@
+/*
+ * Device Tree file for SolidRun Clearfog Pro revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2015 Russell King
+ *
+ * This board is in development; the contents of this file work with
+ * the A1 rev 2.0 of the board, which does not represent final
+ * production board. Things will change, don't expect this file to
+ * remain compatible info the future.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include "armada-388-clearfog.dts"
+
+/ {
+ model = "SolidRun Clearfog Pro A1";
+ compatible = "solidrun,clearfog-pro-a1",
+ "solidrun,clearfog-a1", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 8/9] ARM: dts: armada388-clearfog: add base model DTS file
From: Russell King @ 2017-01-02 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO43Q-0007yJ-ON@rmk-PC.armlinux.org.uk>
Add the DTS file to describe the clearfog base model.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-clearfog-base.dts | 94 ++++++++++++++++++++++++++
2 files changed, 95 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-clearfog-base.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba75cbcc..22d2ca2b52ec 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -921,6 +921,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
armada-388-clearfog.dtb \
+ armada-388-clearfog-base.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
armada-388-rd.dtb
diff --git a/arch/arm/boot/dts/armada-388-clearfog-base.dts b/arch/arm/boot/dts/armada-388-clearfog-base.dts
new file mode 100644
index 000000000000..f86e1876fb38
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-clearfog-base.dts
@@ -0,0 +1,94 @@
+/*
+ * Device Tree file for SolidRun Clearfog Base revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2015 Russell King
+ *
+ * This board is in development; the contents of this file work with
+ * the A1 rev 2.0 of the board, which does not represent final
+ * production board. Things will change, don't expect this file to
+ * remain compatible info the future.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "armada-388-clearfog.dtsi"
+
+/ {
+ model = "SolidRun Clearfog Base A1";
+ compatible = "solidrun,clearfog-base-a1",
+ "solidrun,clearfog-a1", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&rear_button_pins>;
+ pinctrl-names = "default";
+
+ button_0 {
+ /* The rear SW3 button */
+ label = "Rear Button";
+ gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
+ linux,can-disable;
+ linux,code = <BTN_0>;
+ };
+ };
+};
+
+ð1 {
+ phy = <&phy1>;
+};
+
+&mdio {
+ phy1: ethernet-phy at 1 {
+ /*
+ * Annoyingly, the marvell phy driver configures the LED
+ * register, rather than preserving reset-loaded setting.
+ * We undo that rubbish here.
+ */
+ marvell,reg-init = <3 16 0 0x101e>;
+ reg = <1>;
+ };
+};
+
+&pinctrl {
+ rear_button_pins: rear-button-pins {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 7/9] ARM: dts: armada388-clearfog: move rear button
From: Russell King @ 2017-01-02 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO43Q-0007yJ-ON@rmk-PC.armlinux.org.uk>
Move the rear button support into the clearfog pro support file.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/armada-388-clearfog.dts | 18 ++++++++++++++++++
arch/arm/boot/dts/armada-388-clearfog.dtsi | 18 ------------------
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index b56ce4a32519..51887b85dba4 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -126,6 +126,20 @@
};
};
};
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&rear_button_pins>;
+ pinctrl-names = "default";
+
+ button_0 {
+ /* The rear SW3 button */
+ label = "Rear Button";
+ gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
+ linux,can-disable;
+ linux,code = <BTN_0>;
+ };
+ };
};
ð1 {
@@ -183,6 +197,10 @@
marvell,pins = "mpp55";
marvell,function = "spi1";
};
+ rear_button_pins: rear-button-pins {
+ marvell,pins = "mpp34";
+ marvell,function = "gpio";
+ };
};
&spi1 {
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index 30b75379377a..770d4bff6884 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -240,10 +240,6 @@
marvell,pins = "mpp24", "mpp25";
marvell,function = "ua1";
};
- rear_button_pins: rear-button-pins {
- marvell,pins = "mpp34";
- marvell,function = "gpio";
- };
};
sata at a8000 {
@@ -299,20 +295,6 @@
};
};
};
-
- gpio-keys {
- compatible = "gpio-keys";
- pinctrl-0 = <&rear_button_pins>;
- pinctrl-names = "default";
-
- button_0 {
- /* The rear SW3 button */
- label = "Rear Button";
- gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
- linux,can-disable;
- linux,code = <BTN_0>;
- };
- };
};
&spi1 {
--
2.7.4
^ permalink raw reply related
* [PATCH 6/9] ARM: dts: armada388-clearfog: move SPI CS1
From: Russell King @ 2017-01-02 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO43Q-0007yJ-ON@rmk-PC.armlinux.org.uk>
Move the SPI CS1 configuration to the clearfog .dts file as this is only
present on pro models.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/armada-388-clearfog.dts | 14 ++++++++++++++
arch/arm/boot/dts/armada-388-clearfog.dtsi | 10 ++--------
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index 1ee953112d23..b56ce4a32519 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -179,4 +179,18 @@
marvell,pins = "mpp23", "mpp41";
marvell,function = "gpio";
};
+ clearfog_spi1_cs_pins: spi1-cs-pins {
+ marvell,pins = "mpp55";
+ marvell,function = "spi1";
+ };
+};
+
+&spi1 {
+ /*
+ * Add SPI CS pins for clearfog:
+ * CS0: W25Q32 (not populated on uSOM)
+ * CS1:
+ * CS2: mikrobus
+ */
+ pinctrl-0 = <&spi1_pins &clearfog_spi1_cs_pins &mikro_spi_pins>;
};
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index ef4fbc6db7cf..30b75379377a 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -227,10 +227,6 @@
marvell,pins = "mpp20";
marvell,function = "gpio";
};
- clearfog_spi1_cs_pins: spi1-cs-pins {
- marvell,pins = "mpp55";
- marvell,function = "spi1";
- };
mikro_pins: mikro-pins {
/* int: mpp22 rst: mpp29 */
marvell,pins = "mpp22", "mpp29";
@@ -323,12 +319,10 @@
/*
* Add SPI CS pins for clearfog:
* CS0: W25Q32 (not populated on uSOM)
- * CS1:
+ * CS1: PIC microcontroller (Pro models)
* CS2: mikrobus
*/
- pinctrl-0 = <&spi1_pins
- &clearfog_spi1_cs_pins
- &mikro_spi_pins>;
+ pinctrl-0 = <&spi1_pins &mikro_spi_pins>;
pinctrl-names = "default";
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 5/9] ARM: dts: armada388-clearfog: move second PCIe port
From: Russell King @ 2017-01-02 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO43Q-0007yJ-ON@rmk-PC.armlinux.org.uk>
Move the second PCIe port to the clearfog .dts file as this is only
present on the pro models.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/armada-388-clearfog.dts | 51 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/armada-388-clearfog.dtsi | 28 ++--------------
2 files changed, 54 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index a1176d23a444..1ee953112d23 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -54,6 +54,23 @@
compatible = "solidrun,clearfog-a1", "marvell,armada388",
"marvell,armada385", "marvell,armada380";
+ soc {
+ internal-regs {
+ usb3 at f0000 {
+ /* CON2, nearest CPU, USB2 only. */
+ status = "okay";
+ };
+ };
+
+ pcie-controller {
+ pcie at 3,0 {
+ /* Port 2, Lane 0. CON2, nearest CPU. */
+ reset-gpios = <&expander0 2 GPIO_ACTIVE_LOW>;
+ status = "okay";
+ };
+ };
+ };
+
dsa at 0 {
compatible = "marvell,dsa";
dsa,ethernet = <ð1>;
@@ -119,6 +136,40 @@
};
};
+&expander0 {
+ /*
+ * PCA9655 GPIO expander:
+ * 0-CON3 CLKREQ#
+ * 1-CON3 PERST#
+ * 2-CON2 PERST#
+ * 3-CON3 W_DISABLE
+ * 4-CON2 CLKREQ#
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ * 7-CON2 W_DISABLE
+ * 8-JP4 P1
+ * 9-JP4 P4
+ * 10-JP4 P5
+ * 11-m.2 DEVSLP
+ * 12-SFP_LOS
+ * 13-SFP_TX_FAULT
+ * 14-SFP_TX_DISABLE
+ * 15-SFP_MOD_DEF0
+ */
+ pcie2_0_clkreq {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "pcie2.0-clkreq";
+ };
+ pcie2_0_w_disable {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "pcie2.0-w-disable";
+ };
+};
+
&pinctrl {
clearfog_dsa0_clk_pins: clearfog-dsa0-clk-pins {
marvell,pins = "mpp46";
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index fb02997a52a1..ef4fbc6db7cf 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -103,12 +103,12 @@
* PCA9655 GPIO expander, up to 1MHz clock.
* 0-CON3 CLKREQ#
* 1-CON3 PERST#
- * 2-CON2 PERST#
+ * 2-
* 3-CON3 W_DISABLE
- * 4-CON2 CLKREQ#
+ * 4-
* 5-USB3 overcurrent
* 6-USB3 power
- * 7-CON2 W_DISABLE
+ * 7-
* 8-JP4 P1
* 9-JP4 P4
* 10-JP4 P5
@@ -143,18 +143,6 @@
output-low;
line-name = "pcie1.0-w-disable";
};
- pcie2_0_clkreq {
- gpio-hog;
- gpios = <4 GPIO_ACTIVE_LOW>;
- input;
- line-name = "pcie2.0-clkreq";
- };
- pcie2_0_w_disable {
- gpio-hog;
- gpios = <7 GPIO_ACTIVE_LOW>;
- output-low;
- line-name = "pcie2.0-w-disable";
- };
usb3_ilimit {
gpio-hog;
gpios = <5 GPIO_ACTIVE_LOW>;
@@ -296,11 +284,6 @@
status = "okay";
};
- usb3 at f0000 {
- /* CON2, nearest CPU, USB2 only. */
- status = "okay";
- };
-
usb3 at f8000 {
/* CON7 */
status = "okay";
@@ -318,11 +301,6 @@
reset-gpios = <&expander0 1 GPIO_ACTIVE_LOW>;
status = "okay";
};
- pcie at 3,0 {
- /* Port 2, Lane 0. CON2, nearest CPU. */
- reset-gpios = <&expander0 2 GPIO_ACTIVE_LOW>;
- status = "okay";
- };
};
};
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox