* [RFC PATCH 5/7] pinctrl: at91-pio4: allow the gpiolib to set pin configuration
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
Use gpiochip_generic_config to allow the gpiolib to set pin
configuration. Since it relies on .pin_config_set(), add it too.
For this controller, one pin is on group so we can use
atmel_conf_pin_config_group_set() function.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
drivers/pinctrl/pinctrl-at91-pio4.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
index b1ca838dd80a..4b8dda770af8 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -364,6 +364,7 @@ static struct gpio_chip atmel_gpio_chip = {
.set = atmel_gpio_set,
.to_irq = atmel_gpio_to_irq,
.base = 0,
+ .set_config = gpiochip_generic_config,
};
/* --- PINCTRL --- */
@@ -817,6 +818,7 @@ static void atmel_conf_pin_config_dbg_show(struct pinctrl_dev *pctldev,
}
static const struct pinconf_ops atmel_confops = {
+ .pin_config_set = atmel_conf_pin_config_group_set, /* In our case, a pin = a group */
.pin_config_group_get = atmel_conf_pin_config_group_get,
.pin_config_group_set = atmel_conf_pin_config_group_set,
.pin_config_dbg_show = atmel_conf_pin_config_dbg_show,
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 4/7] gpio: gpiolib: add bias support
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
If we want to setup the bias of a pin used as a GPIO, we have,
at least for some pin controllers, to declare it in the pinmuxing
in order to apply the configuration wanted.
If the pinmuxing strict mode is enabled, there is a conflict when
the device driver requests the GPIO. It is due to an ownership
mismatch. The device driver has requested the pin through the
pinctrl so the owner is the device. When the GPIO is requested,
there is a conflict because the owner of the GPIO is the pin
controller not the requester.
This patch provides a way to add the bias configuration to the
flags of a GPIO.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
drivers/gpio/gpiolib-of.c | 9 +++++++++
drivers/gpio/gpiolib.c | 34 ++++++++++++++++++++++++++++------
drivers/gpio/gpiolib.h | 3 +++
include/dt-bindings/gpio/gpio.h | 9 +++++++++
include/linux/gpio/machine.h | 3 +++
include/linux/of_gpio.h | 3 +++
6 files changed, 55 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 67b1a7ff1e97..9c6da8c2e97c 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -158,6 +158,15 @@ struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
if (of_flags & OF_GPIO_TRANSITORY)
*flags |= GPIO_TRANSITORY;
+ if (of_flags & OF_GPIO_BIAS_PULL_UP)
+ *flags |= GPIO_BIAS_PULL_UP;
+
+ if (of_flags & OF_GPIO_BIAS_PULL_DOWN)
+ *flags |= GPIO_BIAS_PULL_DOWN;
+
+ if (of_flags & OF_GPIO_BIAS_DISABLE)
+ *flags |= GPIO_BIAS_DISABLE;
+
return desc;
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index c887602ca0ff..2caec626dcd5 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2133,7 +2133,7 @@ static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
{
struct gpio_chip *chip = desc->gdev->chip;
int status;
- unsigned long flags;
+ unsigned long flags, config = 0;
spin_lock_irqsave(&gpio_lock, flags);
@@ -2161,6 +2161,16 @@ static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
goto done;
}
}
+ if (chip->set_config) {
+ /* The following flags are exclusive. */
+ if (test_bit(FLAG_BIAS_PULL_UP, &desc->flags))
+ config |= pinconf_to_config_packed(PIN_CONFIG_BIAS_PULL_UP, 1);
+ else if (test_bit(FLAG_BIAS_PULL_DOWN, &desc->flags))
+ config |= pinconf_to_config_packed(PIN_CONFIG_BIAS_PULL_DOWN, 1);
+ else if (test_bit(FLAG_BIAS_DISABLE, &desc->flags))
+ config |= pinconf_to_config_packed(PIN_CONFIG_BIAS_DISABLE, 1);
+ chip->set_config(chip, gpio_chip_hwgpio(desc), config);
+ }
if (chip->get_direction) {
/* chip->get_direction may sleep */
spin_unlock_irqrestore(&gpio_lock, flags);
@@ -3587,6 +3597,16 @@ void gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
if (lflags & GPIO_OPEN_SOURCE)
set_bit(FLAG_OPEN_SOURCE, &desc->flags);
+ if (lflags & GPIO_BIAS_PULL_UP)
+ set_bit(FLAG_BIAS_PULL_UP, &desc->flags);
+
+ if (lflags & GPIO_BIAS_PULL_DOWN)
+ set_bit(FLAG_BIAS_PULL_DOWN, &desc->flags);
+
+ if (lflags & GPIO_BIAS_DISABLE)
+ set_bit(FLAG_BIAS_DISABLE, &desc->flags);
+}
+
int gpiod_process_flags(struct gpio_desc *desc, const char *con_id,
unsigned long lflags, enum gpiod_flags dflags)
{
@@ -3760,10 +3780,6 @@ struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
if (IS_ERR(desc))
return desc;
- ret = gpiod_request(desc, label);
- if (ret)
- return ERR_PTR(ret);
-
if (active_low)
lflags |= GPIO_ACTIVE_LOW;
@@ -3777,7 +3793,13 @@ struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
if (transitory)
lflags |= GPIO_TRANSITORY;
- ret = gpiod_configure_and_process_flags(desc, propname, lflags, dflags);
+ gpiod_configure_flags(desc, propname, lflags, dflags);
+
+ ret = gpiod_request(desc, label);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = gpiod_process_flags(desc, propname, lflags, dflags);
if (ret < 0) {
gpiod_put(desc);
return ERR_PTR(ret);
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index a03553d4be1c..381a7a1bf540 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -210,6 +210,9 @@ struct gpio_desc {
#define FLAG_USED_AS_IRQ 9 /* GPIO is connected to an IRQ */
#define FLAG_IS_HOGGED 11 /* GPIO is hogged */
#define FLAG_TRANSITORY 12 /* GPIO may lose value in sleep or reset */
+#define FLAG_BIAS_PULL_UP 13
+#define FLAG_BIAS_PULL_DOWN 14
+#define FLAG_BIAS_DISABLE 15
/* Connection label */
const char *label;
diff --git a/include/dt-bindings/gpio/gpio.h b/include/dt-bindings/gpio/gpio.h
index 2cc10ae4bbb7..28ccfce72c59 100644
--- a/include/dt-bindings/gpio/gpio.h
+++ b/include/dt-bindings/gpio/gpio.h
@@ -33,4 +33,13 @@
#define GPIO_PERSISTENT 0
#define GPIO_TRANSITORY 8
+/* Bit 4 express Bias Pull up */
+#define GPIO_BIAS_PULL_UP 16
+
+/* Bit 5 express Bias Pull down */
+#define GPIO_BIAS_PULL_DOWN 32
+
+/* Bit 6 express Bias Disable */
+#define GPIO_BIAS_DISABLE 64
+
#endif
diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
index b2f2dc638463..e0b6ac64871f 100644
--- a/include/linux/gpio/machine.h
+++ b/include/linux/gpio/machine.h
@@ -12,6 +12,9 @@ enum gpio_lookup_flags {
GPIO_OPEN_SOURCE = (1 << 2),
GPIO_PERSISTENT = (0 << 3),
GPIO_TRANSITORY = (1 << 3),
+ GPIO_BIAS_PULL_UP = (1 << 4),
+ GPIO_BIAS_PULL_DOWN = (1 << 5),
+ GPIO_BIAS_DISABLE = (1 << 6),
};
/**
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index f928c2df2bcd..1b025e6680ea 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -33,6 +33,9 @@ enum of_gpio_flags {
OF_GPIO_SINGLE_ENDED = BIT(1),
OF_GPIO_OPEN_DRAIN = BIT(2),
OF_GPIO_TRANSITORY = BIT(3),
+ OF_GPIO_BIAS_PULL_UP = BIT(4),
+ OF_GPIO_BIAS_PULL_DOWN = BIT(5),
+ OF_GPIO_BIAS_DISABLE = BIT(6),
};
#ifdef CONFIG_OF_GPIO
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 3/7] gpio: gpiolib: save GPIO flags in of_get_named_gpiod_flags
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
When we get a GPIO descriptor from the device device, the flags
are updated for the caller to know if the GPIO is active low or
high. After calling of_get_named_gpio_flags the next step is
usually calling gpiod_request which doesn't take flags as a
parameter.
Updating the flags of the GPIO descriptor will allow to configure
the GPIO when it will be requested.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
drivers/gpio/gpiolib-of.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 4a2b8d3397c7..67b1a7ff1e97 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -97,6 +97,8 @@ struct gpio_desc *of_get_named_gpiod_flags(struct device_node *np,
__func__, propname, np, index,
PTR_ERR_OR_ZERO(desc));
+ gpiod_configure_flags(desc, propname, *flags, 0);
+
out:
of_node_put(gpiospec.np);
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 2/7] gpio: gpiolib: split the gpiod_configure_flags function
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
The gpiod_configure_flags function doesn't only configure flags, it
also performs some processing. It implies that it should be called
after having requested the GPIO. Split configuration and processing
to allow flags configuration before requesting the GPIO. It is
needed if we want to set the pin configuration.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
drivers/gpio/gpiolib.c | 49 +++++++++++++++++++++++++++++++------------------
drivers/gpio/gpiolib.h | 7 ++++++-
2 files changed, 37 insertions(+), 19 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 0621baddfddc..c887602ca0ff 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -3564,23 +3564,9 @@ struct gpio_desc *__must_check gpiod_get_optional(struct device *dev,
EXPORT_SYMBOL_GPL(gpiod_get_optional);
-/**
- * gpiod_configure_flags - helper function to configure a given GPIO
- * @desc: gpio whose value will be assigned
- * @con_id: function within the GPIO consumer
- * @lflags: gpio_lookup_flags - returned from of_find_gpio() or
- * of_get_gpio_hog()
- * @dflags: gpiod_flags - optional GPIO initialization flags
- *
- * Return 0 on success, -ENOENT if no GPIO has been assigned to the
- * requested function and/or index, or another IS_ERR() code if an error
- * occurred while trying to acquire the GPIO.
- */
-int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
+void gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
unsigned long lflags, enum gpiod_flags dflags)
{
- int status;
-
if (lflags & GPIO_ACTIVE_LOW)
set_bit(FLAG_ACTIVE_LOW, &desc->flags);
@@ -3601,6 +3587,11 @@ int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
if (lflags & GPIO_OPEN_SOURCE)
set_bit(FLAG_OPEN_SOURCE, &desc->flags);
+int gpiod_process_flags(struct gpio_desc *desc, const char *con_id,
+ unsigned long lflags, enum gpiod_flags dflags)
+{
+ int status;
+
status = gpiod_set_transitory(desc, (lflags & GPIO_TRANSITORY));
if (status < 0)
return status;
@@ -3622,6 +3613,28 @@ int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
}
/**
+ * gpiod_configure_and_process_flags - helper function to configure a
+ * given GPIO
+ * @desc: gpio whose value will be assigned
+ * @con_id: function within the GPIO consumer
+ * @lflags: gpio_lookup_flags - returned from of_find_gpio() or
+ * of_get_gpio_hog()
+ * @dflags: gpiod_flags - optional GPIO initialization flags
+ *
+ * Return 0 on success, -ENOENT if no GPIO has been assigned to the
+ * requested function and/or index, or another IS_ERR() code if an error
+ * occurred while trying to acquire the GPIO.
+ */
+int gpiod_configure_and_process_flags(struct gpio_desc *desc,
+ const char *con_id,
+ unsigned long lflags,
+ enum gpiod_flags dflags)
+{
+ gpiod_configure_flags(desc, con_id, lflags, dflags);
+ return gpiod_process_flags(desc, con_id, lflags, dflags);
+}
+
+/**
* gpiod_get_index - obtain a GPIO from a multi-index GPIO function
* @dev: GPIO consumer, can be NULL for system-global GPIOs
* @con_id: function within the GPIO consumer
@@ -3675,7 +3688,7 @@ struct gpio_desc *__must_check gpiod_get_index(struct device *dev,
if (status < 0)
return ERR_PTR(status);
- status = gpiod_configure_flags(desc, con_id, lookupflags, flags);
+ status = gpiod_configure_and_process_flags(desc, con_id, lookupflags, flags);
if (status < 0) {
dev_dbg(dev, "setup of GPIO %s failed\n", con_id);
gpiod_put(desc);
@@ -3764,7 +3777,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
if (transitory)
lflags |= GPIO_TRANSITORY;
- ret = gpiod_configure_flags(desc, propname, lflags, dflags);
+ ret = gpiod_configure_and_process_flags(desc, propname, lflags, dflags);
if (ret < 0) {
gpiod_put(desc);
return ERR_PTR(ret);
@@ -3830,7 +3843,7 @@ int gpiod_hog(struct gpio_desc *desc, const char *name,
return status;
}
- status = gpiod_configure_flags(desc, name, lflags, dflags);
+ status = gpiod_configure_and_process_flags(desc, name, lflags, dflags);
if (status < 0) {
pr_err("setup of hog GPIO %s (chip %s, offset %d) failed, %d\n",
name, chip->label, hwnum, status);
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index 5e1f7cc6eeb6..a03553d4be1c 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -219,8 +219,13 @@ struct gpio_desc {
int gpiod_request(struct gpio_desc *desc, const char *label);
void gpiod_free(struct gpio_desc *desc);
-int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
+void gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
unsigned long lflags, enum gpiod_flags dflags);
+int gpiod_process_flags(struct gpio_desc *desc, const char *con_id,
+ unsigned long lflags, enum gpiod_flags dflags);
+int gpiod_configure_and_process_flags(struct gpio_desc *desc,
+ const char *con_id, unsigned long lflags,
+ enum gpiod_flags dflags);
int gpiod_hog(struct gpio_desc *desc, const char *name,
unsigned long lflags, enum gpiod_flags dflags);
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 1/7] gpio: of: use the BIT macro for of_gpio_flags
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-1-ludovic.desroches@microchip.com>
Use the BIT macro for the of_gpio_flags enumeration.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
include/linux/of_gpio.h | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index 18a7f03e1182..f928c2df2bcd 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -14,6 +14,7 @@
#ifndef __LINUX_OF_GPIO_H
#define __LINUX_OF_GPIO_H
+#include <linux/bitops.h>
#include <linux/compiler.h>
#include <linux/kernel.h>
#include <linux/errno.h>
@@ -28,10 +29,10 @@ struct device_node;
* Linux-specific in their .xlate callback. Though, 1:1 mapping is recommended.
*/
enum of_gpio_flags {
- OF_GPIO_ACTIVE_LOW = 0x1,
- OF_GPIO_SINGLE_ENDED = 0x2,
- OF_GPIO_OPEN_DRAIN = 0x4,
- OF_GPIO_TRANSITORY = 0x8,
+ OF_GPIO_ACTIVE_LOW = BIT(0),
+ OF_GPIO_SINGLE_ENDED = BIT(1),
+ OF_GPIO_OPEN_DRAIN = BIT(2),
+ OF_GPIO_TRANSITORY = BIT(3),
};
#ifdef CONFIG_OF_GPIO
--
2.12.2
^ permalink raw reply related
* [RFC PATCH 0/7] gpiolib: add bias support
From: Ludovic Desroches @ 2017-12-14 14:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is an attempt to add the bias configuration to the gpiolib since
I want and need to enable the pinmuxing strict mode to get an error if
I request a GPIO which is used by a peripheral.
I have not monitored the gpio mailing list for a while. Sorry I may have
missed some discussions about this topic. In this case, let me know which
threads I should read.
I have a memory of a discussion about the pinmux strict mode and the
constraints related to it. Several pin controllers can mux a pin as a GPIO
or as a peripheral. Doing both is not possible, so the strict mode may or
must be enabled. Unfortunately, to perform the pin configuration of the GPIO,
such as the bias (pull up, pull down, disabled), we have to declare this pin
in the pinmuxing. Doing this leads to a conflict when the device requests the
GPIO. The owner of the pin is the device which requested the pinmuxing whereas
the owner of the GPIO is the pin controller.
To solve this, there are two solutions:
- fix this owner mismatching. The owner of the GPIO must be the requester. It's
not difficult to solve this issue if we add the requester as a parameter when
the GPIO is requested but it impacts a lot of code.
- allow the gpiolib to set the pin configuration. I think the main issue
was code duplication. Since I have seen the introduction of
gpiochip_generic_config(), gpiod_set_debounce(), I suppose it's the way to go.
I have not introduced a gpiod_set_bias() because I think the only place to
setup this is in the device tree. It's useless to setup a bias pull up if there
is an external pull up on the board.
Ludovic Desroches (7):
gpio: of: use the BIT macro for of_gpio_flags
gpio: gpiolib: split the gpiod_configure_flags function
gpio: gpiolib: save GPIO flags in of_get_named_gpiod_flags
gpio: gpiolib: add bias support
pinctrl: at91-pio4: allow the gpiolib to set pin configuration
pinctrl: at91-pio4: use strict mode if explicitly requested
ARM: dts: remove gpio from pinmux
.../bindings/pinctrl/atmel,at91-pio4-pinctrl.txt | 4 ++
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 45 ++----------
drivers/gpio/gpiolib-of.c | 11 +++
drivers/gpio/gpiolib.c | 81 ++++++++++++++++------
drivers/gpio/gpiolib.h | 10 ++-
drivers/pinctrl/pinctrl-at91-pio4.c | 26 ++++++-
include/dt-bindings/gpio/gpio.h | 9 +++
include/linux/gpio/machine.h | 3 +
include/linux/of_gpio.h | 12 ++--
9 files changed, 134 insertions(+), 67 deletions(-)
--
2.12.2
^ permalink raw reply
* [PATCH v2 1/3] mmc: dt-bindings: add mmc support to MT7623 SoC
From: Sean Wang @ 2017-12-14 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86e53802-9bb4-35eb-66e1-f9a401e31863@gmail.com>
On Thu, 2017-12-14 at 12:16 +0100, Matthias Brugger wrote:
> Hi Ulf,
>
> On 12/07/2017 07:43 AM, sean.wang at mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > Add the devicetree binding for MT7623 SoC using MT2701 as the fallback.
> >
> > Cc: devicetree at vger.kernel.org
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> > Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > index 72d2a73..9b80176 100644
> > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > @@ -12,6 +12,8 @@ Required properties:
> > "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> > "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> > "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> > + "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
> > +
> > - reg: physical base address of the controller and length
> > - interrupts: Should contain MSDC interrupt number
> > - clocks: Should contain phandle for the clock feeding the MMC controller
> >
>
> Are you fine to take this patch through your branch, or shall I take it through
> mine?
>
> @Sean it seems you forgot to send this patch to Ulf as well. In the future
> please take care to send the patch to all relevant people and mailinglist.
>
Okay. I'll be. really sorry for the inconvenience
> Thanks,
> Matthias
>
^ permalink raw reply
* [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
From: Timur Tabi @ 2017-12-14 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214103027.GB697@e107981-ln.cambridge.arm.com>
On 12/14/17 4:30 AM, Lorenzo Pieralisi wrote:
>> I didn't want to put any ACPI code in amba-pl011.c, so putting it in spcr.c
>> made the most sense. I agree the global variable is ugly. If you have a
>> better idea, I'm all ears.
> I told you my idea. It could have been made easier by reusing the
> ACPI_DECLARE_PROBE_ENTRY() mechanism.
Sorry, I don't mean to be difficult, but when did you tell *me* this
idea of yours? I don't see any email from you to me that mentions
ACPI_DECLARE_PROBE_ENTRY(). I've never even heard of that macro before.
Please note that I'm not the original author of this code.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] arm64/sve: Report SVE to userspace via CPUID only if supported
From: Mark Rutland @ 2017-12-14 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513260094-9893-1-git-send-email-Dave.Martin@arm.com>
On Thu, Dec 14, 2017 at 02:01:34PM +0000, Dave Martin wrote:
> Currently, the SVE field in ID_AA64PFR0_EL1 is visible
> unconditionally to userspace via the CPU ID register emulation,
> irrespective of the kernel config. This means that if a kernel
> configured with CONFIG_ARM64_SVE=n is run on SVE-capable hardware,
> userspace will see SVE reported as present in the ID regs even
> though the kernel forbids execution of SVE instructions.
>
> This patch makes the exposure of the SVE field in ID_AA64PFR0_EL1
> conditional on CONFIG_ARM64_SVE=y.
>
> Since future architecture features are likely to encounter a
> similar requirement, this patch adds a suitable helper macros for
> use when declaring config-conditional ID register fields.
Makes sense to me; I can use this for pointer authentication fields.
> Fixes: 43994d824e84 ("arm64/sve: Detect SVE and activate runtime support")
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
>
> This patch is proposed as a fix for v4.15, since we don't want to create
> unintentional ABI by exposing the wrong thing to userspace in a full
> kernel release.
>
> arch/arm64/include/asm/cpufeature.h | 3 +++
> arch/arm64/kernel/cpufeature.c | 3 ++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index ac67cfc..060e3a4 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -60,6 +60,9 @@ enum ftr_type {
> #define FTR_VISIBLE true /* Feature visible to the user space */
> #define FTR_HIDDEN false /* Feature is hidden from the user */
>
> +#define FTR_VISIBLE_IF_IS_ENABLED(config) \
> + (IS_ENABLED(config) ? FTR_VISIBLE : FTR_HIDDEN)
> +
> struct arm64_ftr_bits {
> bool sign; /* Value is signed ? */
> bool visible;
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index c5ba009..a73a592 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -145,7 +145,8 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> - ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
> + FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 08/12] mmc: sdhci-omap: Add support to override f_max and iodelay from pdata
From: Philippe Ombredanne @ 2017-12-14 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214130941.26666-9-kishon@ti.com>
Kishon,
On Thu, Dec 14, 2017 at 2:09 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> DRA74x EVM Rev H EVM comes with revision 2.0 silicon. However, earlier
> versions of EVM can come with either revision 1.1 or revision 1.0 of
> silicon.
>
> The device-tree file is written to support rev 2.0 of silicon.
> pdata-quirks are used to then override the settings needed for
> PG 1.1 silicon.
>
> PG 1.1 silicon has limitations w.r.t frequencies at which MMC1/2/3
> can operate as well as different IOdelay numbers.
>
> Add support in sdhci-omap driver to get platform data if available
> (added using pdata quirks) and override the data (max-frequency and
> iodelay data) obtained from device tree.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
<snip>
> --- /dev/null
> +++ b/include/linux/platform_data/sdhci-omap.h
> @@ -0,0 +1,35 @@
> +/**
> + * SDHCI Controller Platform Data for TI's OMAP SoCs
> + *
> + * Copyright (C) 2017 Texas Instruments
> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 of
> + * the License as published by the Free Software Foundation.
> + *
> + * This program 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
Could you use the new SPDX tags instead of this fine and long boilerplate? See
Thomas doc for details [1]
[1] https://lkml.org/lkml/2017/12/4/934
Thanks!
PS: if you could spread the word out in your team too, this would be
much welcomed!
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH] arm64/sve: Report SVE to userspace via CPUID only if supported
From: Dave Martin @ 2017-12-14 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513260094-9893-1-git-send-email-Dave.Martin@arm.com>
Will, FYI -- sorry, forgot to Cc you.
Cheers
---Dave
On Thu, Dec 14, 2017 at 02:01:34PM +0000, Dave Martin wrote:
> Currently, the SVE field in ID_AA64PFR0_EL1 is visible
> unconditionally to userspace via the CPU ID register emulation,
> irrespective of the kernel config. This means that if a kernel
> configured with CONFIG_ARM64_SVE=n is run on SVE-capable hardware,
> userspace will see SVE reported as present in the ID regs even
> though the kernel forbids execution of SVE instructions.
>
> This patch makes the exposure of the SVE field in ID_AA64PFR0_EL1
> conditional on CONFIG_ARM64_SVE=y.
>
> Since future architecture features are likely to encounter a
> similar requirement, this patch adds a suitable helper macros for
> use when declaring config-conditional ID register fields.
>
> Fixes: 43994d824e84 ("arm64/sve: Detect SVE and activate runtime support")
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
> ---
>
> This patch is proposed as a fix for v4.15, since we don't want to create
> unintentional ABI by exposing the wrong thing to userspace in a full
> kernel release.
>
> arch/arm64/include/asm/cpufeature.h | 3 +++
> arch/arm64/kernel/cpufeature.c | 3 ++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index ac67cfc..060e3a4 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -60,6 +60,9 @@ enum ftr_type {
> #define FTR_VISIBLE true /* Feature visible to the user space */
> #define FTR_HIDDEN false /* Feature is hidden from the user */
>
> +#define FTR_VISIBLE_IF_IS_ENABLED(config) \
> + (IS_ENABLED(config) ? FTR_VISIBLE : FTR_HIDDEN)
> +
> struct arm64_ftr_bits {
> bool sign; /* Value is signed ? */
> bool visible;
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index c5ba009..a73a592 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -145,7 +145,8 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> - ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
> + FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
> --
> 2.1.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64/sve: Report SVE to userspace via CPUID only if supported
From: Dave Martin @ 2017-12-14 14:01 UTC (permalink / raw)
To: linux-arm-kernel
Currently, the SVE field in ID_AA64PFR0_EL1 is visible
unconditionally to userspace via the CPU ID register emulation,
irrespective of the kernel config. This means that if a kernel
configured with CONFIG_ARM64_SVE=n is run on SVE-capable hardware,
userspace will see SVE reported as present in the ID regs even
though the kernel forbids execution of SVE instructions.
This patch makes the exposure of the SVE field in ID_AA64PFR0_EL1
conditional on CONFIG_ARM64_SVE=y.
Since future architecture features are likely to encounter a
similar requirement, this patch adds a suitable helper macros for
use when declaring config-conditional ID register fields.
Fixes: 43994d824e84 ("arm64/sve: Detect SVE and activate runtime support")
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>
---
This patch is proposed as a fix for v4.15, since we don't want to create
unintentional ABI by exposing the wrong thing to userspace in a full
kernel release.
arch/arm64/include/asm/cpufeature.h | 3 +++
arch/arm64/kernel/cpufeature.c | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index ac67cfc..060e3a4 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -60,6 +60,9 @@ enum ftr_type {
#define FTR_VISIBLE true /* Feature visible to the user space */
#define FTR_HIDDEN false /* Feature is hidden from the user */
+#define FTR_VISIBLE_IF_IS_ENABLED(config) \
+ (IS_ENABLED(config) ? FTR_VISIBLE : FTR_HIDDEN)
+
struct arm64_ftr_bits {
bool sign; /* Value is signed ? */
bool visible;
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c5ba009..a73a592 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -145,7 +145,8 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
};
static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
+ FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
--
2.1.4
^ permalink raw reply related
* [PATCH v2 20/36] KVM: arm64: Don't save the host ELR_EL2 and SPSR_EL2 on VHE systems
From: Christoffer Dall @ 2017-12-14 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a5d687f6-478f-7436-58c0-932a4eaa466c@arm.com>
On Mon, Dec 11, 2017 at 10:44:59AM +0000, Marc Zyngier wrote:
> On 07/12/17 17:06, Christoffer Dall wrote:
> > On non-VHE systems we need to save the ELR_EL2 and SPSR_EL2 so that we
> > can return to the host in EL1 in the same state and location where we
> > issued a hypercall to EL2, but these registers don't contain anything
> > important on VHE, because all of the host runs in EL2. Therefore,
>
> If I may refine the rational: ELR_EL2 and SPSR_EL2 are not useful here
> because we never enter a guest as a result of an exception entry that
> would be directly handled by KVM. The kernel entry code already saves
> ELR_EL1/SPSR_EL1 on exception entry, which is enough.
>
Indeed, I was being a bit loosey-goosey here.
> > factor out these registers into separate save/restore functions, making
> > it easy to exclude them from the VHE world-switch path later on.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > arch/arm64/kvm/hyp/sysreg-sr.c | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
> > index a12112494f75..479de0f0dd07 100644
> > --- a/arch/arm64/kvm/hyp/sysreg-sr.c
> > +++ b/arch/arm64/kvm/hyp/sysreg-sr.c
> > @@ -71,6 +71,10 @@ static void __hyp_text __sysreg_save_el1_state(struct kvm_cpu_context *ctxt)
> > ctxt->gp_regs.sp_el1 = read_sysreg(sp_el1);
> > ctxt->gp_regs.elr_el1 = read_sysreg_el1(elr);
> > ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg_el1(spsr);
> > +}
> > +
> > +static void __hyp_text __sysreg_save_el2_return_state(struct kvm_cpu_context *ctxt)
> > +{
> > ctxt->gp_regs.regs.pc = read_sysreg_el2(elr);
> > ctxt->gp_regs.regs.pstate = read_sysreg_el2(spsr);
> > }
> > @@ -80,6 +84,7 @@ void __hyp_text __sysreg_save_state_nvhe(struct kvm_cpu_context *ctxt)
> > __sysreg_save_el1_state(ctxt);
> > __sysreg_save_common_state(ctxt);
> > __sysreg_save_user_state(ctxt);
> > + __sysreg_save_el2_return_state(ctxt);
> > }
> >
> > void sysreg_save_host_state_vhe(struct kvm_cpu_context *ctxt)
> > @@ -93,6 +98,7 @@ void sysreg_save_guest_state_vhe(struct kvm_cpu_context *ctxt)
> > __sysreg_save_el1_state(ctxt);
> > __sysreg_save_common_state(ctxt);
> > __sysreg_save_user_state(ctxt);
> > + __sysreg_save_el2_return_state(ctxt);
> > }
> >
> > static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctxt)
> > @@ -137,6 +143,11 @@ static void __hyp_text __sysreg_restore_el1_state(struct kvm_cpu_context *ctxt)
> > write_sysreg(ctxt->gp_regs.sp_el1, sp_el1);
> > write_sysreg_el1(ctxt->gp_regs.elr_el1, elr);
> > write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr);
> > +}
> > +
> > +static void __hyp_text
> > +__sysreg_restore_el2_return_state(struct kvm_cpu_context *ctxt)
> > +{
> > write_sysreg_el2(ctxt->gp_regs.regs.pc, elr);
> > write_sysreg_el2(ctxt->gp_regs.regs.pstate, spsr);
> > }
> > @@ -146,6 +157,7 @@ void __hyp_text __sysreg_restore_state_nvhe(struct kvm_cpu_context *ctxt)
> > __sysreg_restore_el1_state(ctxt);
> > __sysreg_restore_common_state(ctxt);
> > __sysreg_restore_user_state(ctxt);
> > + __sysreg_restore_el2_return_state(ctxt);
> > }
> >
> > void sysreg_restore_host_state_vhe(struct kvm_cpu_context *ctxt)
> > @@ -159,6 +171,7 @@ void sysreg_restore_guest_state_vhe(struct kvm_cpu_context *ctxt)
> > __sysreg_restore_el1_state(ctxt);
> > __sysreg_restore_common_state(ctxt);
> > __sysreg_restore_user_state(ctxt);
> > + __sysreg_restore_el2_return_state(ctxt);
> > }
> >
> > static void __hyp_text __fpsimd32_save_state(struct kvm_cpu_context *ctxt)
> >
>
> Otherwise:
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 14/14] ARM: dts: keystone-k2g: Use sdhci-omap programming model
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
Use sdhci-omap programming model based on the generic sdhci
library for programming the MMC/SD controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/keystone-k2g.dtsi | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 8f313ff406b9..2c6da70eac38 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -349,14 +349,10 @@
};
mmc0: mmc at 23000000 {
- compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+ compatible = "ti,k2g-sdhci";
reg = <0x23000000 0x400>;
interrupts = <GIC_SPI 96 IRQ_TYPE_EDGE_RISING>;
- dmas = <&edma1 24 0>, <&edma1 25 0>;
- dma-names = "tx", "rx";
bus-width = <4>;
- ti,needs-special-reset;
- no-1-8-v;
max-frequency = <96000000>;
power-domains = <&k2g_pds 0xb>;
clocks = <&k2g_clks 0xb 1>, <&k2g_clks 0xb 2>;
@@ -365,14 +361,11 @@
};
mmc1: mmc at 23100000 {
- compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+ compatible = "ti,k2g-sdhci";
reg = <0x23100000 0x400>;
interrupts = <GIC_SPI 97 IRQ_TYPE_EDGE_RISING>;
- dmas = <&edma1 26 0>, <&edma1 27 0>;
- dma-names = "tx", "rx";
bus-width = <8>;
- ti,needs-special-reset;
- ti,non-removable;
+ non-removable;
max-frequency = <96000000>;
power-domains = <&k2g_pds 0xc>;
clocks = <&k2g_clks 0xc 1>, <&k2g_clks 0xc 2>;
--
2.11.0
^ permalink raw reply related
* [PATCH 13/14] ARM: dts: dra7: Use sdhci-omap programming model
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
Use sdhci-omap programming model based on the generic sdhci
library for programming the first 2 instances of eMMC/SD/SDIO
controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 3 +--
arch/arm/boot/dts/am57xx-idk-common.dtsi | 2 +-
arch/arm/boot/dts/dra7-evm.dts | 1 +
arch/arm/boot/dts/dra7.dtsi | 25 ++++++++++++++++---------
arch/arm/boot/dts/dra72-evm-common.dtsi | 2 +-
arch/arm/boot/dts/dra76-evm.dts | 3 ++-
6 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 50e7c3c0d111..44e6720bc939 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -444,8 +444,7 @@
vmmc-supply = <&vdd_3v3>;
vqmmc-supply = <&vdd_3v3>;
bus-width = <8>;
- ti,non-removable;
- cap-mmc-dual-data-rate;
+ non-removable;
};
&sata {
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 43cdf523a8a0..855c130afc69 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -423,7 +423,7 @@
vmmc-supply = <&v3_3d>;
vqmmc-supply = <&v3_3d>;
bus-width = <8>;
- ti,non-removable;
+ non-removable;
max-frequency = <96000000>;
};
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index ef9c90daa74b..b5ec42f16efc 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -351,6 +351,7 @@
status = "okay";
vmmc-supply = <&evm_1v8_sw>;
bus-width = <8>;
+ non-removable;
pinctrl-names = "default", "hs", "ddr_1_8v-rev11", "ddr_1_8v", "hs200_1_8v-rev11", "hs200_1_8v";
pinctrl-0 = <&mmc2_pins_default>;
pinctrl-1 = <&mmc2_pins_hs>;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ac9216293b7c..1acd77f29d0b 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1057,17 +1057,21 @@
};
mmc1: mmc at 4809c000 {
- compatible = "ti,omap4-hsmmc";
+ compatible = "ti,dra7-sdhci";
reg = <0x4809c000 0x400>;
interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mmc1";
- ti,dual-volt;
- ti,needs-special-reset;
- dmas = <&sdma_xbar 61>, <&sdma_xbar 62>;
- dma-names = "tx", "rx";
status = "disabled";
pbias-supply = <&pbias_mmc_reg>;
max-frequency = <192000000>;
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-ddr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
+ cap-sd-highspeed;
+ mmc-ddr-1_8v;
+ cap-mmc-highspeed;
};
hdqw1w: 1w at 480b2000 {
@@ -1078,15 +1082,18 @@
};
mmc2: mmc at 480b4000 {
- compatible = "ti,omap4-hsmmc";
+ compatible = "ti,dra7-sdhci";
reg = <0x480b4000 0x400>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mmc2";
- ti,needs-special-reset;
- dmas = <&sdma_xbar 47>, <&sdma_xbar 48>;
- dma-names = "tx", "rx";
status = "disabled";
max-frequency = <192000000>;
+ cap-sd-highspeed;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
+ mmc-hs200-1_8v;
+ mmc-ddr-1_8v;
+ cap-mmc-highspeed;
};
mmc3: mmc at 480ad000 {
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index 2e485a13dfd7..4f48f97c9c47 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -421,7 +421,7 @@
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins_default>;
bus-width = <8>;
- ti,non-removable;
+ non-removable;
max-frequency = <192000000>;
};
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 4dd8a5ac8fae..02c01cecc417 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -306,7 +306,7 @@
&mmc1 {
status = "okay";
vmmc-supply = <&vio_3v3_sd>;
- vmmc_aux-supply = <&ldo4_reg>;
+ vqmmc-supply = <&ldo4_reg>;
bus-width = <4>;
/*
* SDCD signal is not being used here - using the fact that GPIO mode
@@ -323,6 +323,7 @@
vmmc-supply = <&vio_1v8>;
vqmmc-supply = <&vio_1v8>;
bus-width = <8>;
+ non-removable;
pinctrl-names = "default", "hs", "ddr_1_8v", "hs200_1_8v";
pinctrl-0 = <&mmc2_pins_default>;
pinctrl-1 = <&mmc2_pins_hs>;
--
2.11.0
^ permalink raw reply related
* [PATCH 12/14] ARM: dts: am57xx-idk: Select pull down for mmc1_clk line in default mode
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.
According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Physical Layer Specification Version 5.00 February 22, 2016", the
host should hold CLK low for at least 5ms.
In order to keep the card line low during voltage switch, the pad mux of
mmc1_clk line should be configured to pull down.
This is specific to am57xx-idk (and not all dra72/dra74 based boards)
since mmc1_clk line in am57xx-idk is not connected to an external
pullup.
While at that change the order of header files in am571x-idk.dts and
am572x-idk.dts so that the modified pinctrl values in am57xx-idk-common
could take effect.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/am571x-idk.dts | 2 +-
arch/arm/boot/dts/am572x-idk.dts | 2 +-
arch/arm/boot/dts/am57xx-idk-common.dtsi | 11 +++++++++++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am571x-idk.dts b/arch/arm/boot/dts/am571x-idk.dts
index debf9464403e..c7d77acffa28 100644
--- a/arch/arm/boot/dts/am571x-idk.dts
+++ b/arch/arm/boot/dts/am571x-idk.dts
@@ -10,8 +10,8 @@
#include "dra72x.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
-#include "am57xx-idk-common.dtsi"
#include "dra72x-mmc-iodelay.dtsi"
+#include "am57xx-idk-common.dtsi"
/ {
model = "TI AM5718 IDK";
diff --git a/arch/arm/boot/dts/am572x-idk.dts b/arch/arm/boot/dts/am572x-idk.dts
index a578fe97ba3b..144376ad5f35 100644
--- a/arch/arm/boot/dts/am572x-idk.dts
+++ b/arch/arm/boot/dts/am572x-idk.dts
@@ -11,8 +11,8 @@
#include "dra74x.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
-#include "am57xx-idk-common.dtsi"
#include "dra74x-mmc-iodelay.dtsi"
+#include "am57xx-idk-common.dtsi"
/ {
model = "TI AM5728 IDK";
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 43a6d0590f7c..43cdf523a8a0 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -115,6 +115,17 @@
DRA7XX_CORE_IOPAD(0x37d4, MUX_MODE15 | PULL_UP) /* dcan1_rx.off */
>;
};
+
+ mmc1_pins_default: mmc1_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
};
&i2c1 {
--
2.11.0
^ permalink raw reply related
* [PATCH 11/14] ARM: dts: dra71-evm: Select pull down for mmc1_clk line in default mode
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.
According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Physical Layer Specification Version 5.00 February 22, 2016", the
host should hold CLK low for at least 5ms.
In order to keep the card line low during voltage switch, the pad mux of
mmc1_clk line should be configured to pull down.
This is specific only to dra71-evm (and not all dra72 based boards) since
mmc1_clk line in dra71-evm is not connected to an external pullup.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/dra71-evm.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/dra71-evm.dts b/arch/arm/boot/dts/dra71-evm.dts
index 64363f75c01a..ebc4bbae981e 100644
--- a/arch/arm/boot/dts/dra71-evm.dts
+++ b/arch/arm/boot/dts/dra71-evm.dts
@@ -50,6 +50,19 @@
};
};
+&dra7_pmx_core {
+ mmc1_pins_default: mmc1_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+};
+
&i2c1 {
status = "okay";
clock-frequency = <400000>;
--
2.11.0
^ permalink raw reply related
* [PATCH 10/14] ARM: dts: dra71-evm: Correct evm_sd regulator max voltage
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
From: Ravikumar Kattekola <rk@ti.com>
Correct vpo_sd_1v8_3v3 regulator max voltage to 3.3V
Fixes: 9868bc585ae2 ("ARM: dts: Add support for dra718-evm")
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/dra71-evm.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra71-evm.dts b/arch/arm/boot/dts/dra71-evm.dts
index 41c9132eb550..64363f75c01a 100644
--- a/arch/arm/boot/dts/dra71-evm.dts
+++ b/arch/arm/boot/dts/dra71-evm.dts
@@ -24,13 +24,13 @@
regulator-name = "vddshv8";
regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
regulator-boot-on;
vin-supply = <&evm_5v0>;
gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
states = <1800000 0x0
- 3000000 0x1>;
+ 3300000 0x1>;
};
evm_1v8_sw: fixedregulator-evm_1v8 {
--
2.11.0
^ permalink raw reply related
* [PATCH 09/14] ARM: dts: dra76-evm: Add "vqmmc-supply" property for mmc2
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
Add "vqmmc-supply" property for mmc2 to indicate the supply connected
to the IO lines.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/dra76-evm.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index ec8af5841061..4dd8a5ac8fae 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -321,6 +321,7 @@
&mmc2 {
status = "okay";
vmmc-supply = <&vio_1v8>;
+ vqmmc-supply = <&vio_1v8>;
bus-width = <8>;
pinctrl-names = "default", "hs", "ddr_1_8v", "hs200_1_8v";
pinctrl-0 = <&mmc2_pins_default>;
--
2.11.0
^ permalink raw reply related
* [PATCH 08/14] ARM: dts: am57xx-idk: Add "vqmmc-supply" property for mmc2
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
Add "vqmmc-supply" property for mmc2 to indicate the supply connected
to the IO lines.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/am57xx-idk-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 97aa8e6a56da..43a6d0590f7c 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -410,6 +410,7 @@
&mmc2 {
status = "okay";
vmmc-supply = <&v3_3d>;
+ vqmmc-supply = <&v3_3d>;
bus-width = <8>;
ti,non-removable;
max-frequency = <96000000>;
--
2.11.0
^ permalink raw reply related
* [PATCH 07/14] ARM: dts: am57xx-beagle-x15: Add "vqmmc-supply" property for mmc2
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
Add "vqmmc-supply" property for mmc2 to indicate the supply connected
to the IO lines.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 49aeecd312b4..50e7c3c0d111 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -442,6 +442,7 @@
pinctrl-0 = <&mmc2_pins_default>;
vmmc-supply = <&vdd_3v3>;
+ vqmmc-supply = <&vdd_3v3>;
bus-width = <8>;
ti,non-removable;
cap-mmc-dual-data-rate;
--
2.11.0
^ permalink raw reply related
* [PATCH 06/14] ARM: dts: dra76-evm: Add pinctrl data for higher speed MMC/SD modes
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
From: Sekhar Nori <nsekhar@ti.com>
The SD card interface on DRA76x EVM can support
high speed SD cards. The eMMC onboard can support
upto HS200 mode.
Enable support for these higher speed modes in the
device-tree file.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/dra76-evm.dts | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 2770f6d3e1cb..ec8af5841061 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -313,16 +313,20 @@
* is always hardwired.
*/
cd-gpios = <&gpio6 27 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "hs";
pinctrl-0 = <&mmc1_pins_default>;
+ pinctrl-1 = <&mmc1_pins_hs>;
};
&mmc2 {
status = "okay";
vmmc-supply = <&vio_1v8>;
bus-width = <8>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "hs", "ddr_1_8v", "hs200_1_8v";
pinctrl-0 = <&mmc2_pins_default>;
+ pinctrl-1 = <&mmc2_pins_hs>;
+ pinctrl-2 = <&mmc2_pins_ddr>;
+ pinctrl-3 = <&mmc2_pins_hs200 &mmc2_iodelay_hs200_conf>;
};
/* No RTC on this device */
--
2.11.0
^ permalink raw reply related
* [PATCH 05/14] ARM: dts: dra76-evm: Shift to using common IOdelay data
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
From: Sekhar Nori <nsekhar@ti.com>
Now that we have a device-tree include file with common
MMC/SD IOdelay data for DRA76x SoC, shift the EVM device-tree
file to using that.
Tested-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/dra76-evm.dts | 41 +----------------------------------------
1 file changed, 1 insertion(+), 40 deletions(-)
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index b024a65c6e27..2770f6d3e1cb 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -9,6 +9,7 @@
#include "dra76x.dtsi"
#include "dra7-evm-common.dtsi"
+#include "dra76x-mmc-iodelay.dtsi"
#include <dt-bindings/net/ti-dp83867.h>
/ {
@@ -100,46 +101,6 @@
};
};
-&dra7_pmx_core {
- mmc1_pins_default: mmc1_pins_default {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x376c, PIN_INPUT | MUX_MODE14) /* mmc1sdcd.gpio219 */
- DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.clk */
- DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
- DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
- DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
- DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
- DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
- >;
- };
-
- mmc1_pins_sdr12: pinmux_mmc1_sdr12_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.clk */
- DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
- DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
- DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
- DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
- DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
- >;
- };
-
- mmc2_pins_default: mmc2_pins_default {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x349c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a23.mmc2_clk */
- DRA7XX_CORE_IOPAD(0x34b0, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_cs1.mmc2_cmd */
- DRA7XX_CORE_IOPAD(0x34a0, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a24.mmc2_dat0 */
- DRA7XX_CORE_IOPAD(0x34a4, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a25.mmc2_dat1 */
- DRA7XX_CORE_IOPAD(0x34a8, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a26.mmc2_dat2 */
- DRA7XX_CORE_IOPAD(0x34ac, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a27.mmc2_dat3 */
- DRA7XX_CORE_IOPAD(0x348c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a19.mmc2_dat4 */
- DRA7XX_CORE_IOPAD(0x3490, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a20.mmc2_dat5 */
- DRA7XX_CORE_IOPAD(0x3494, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a21.mmc2_dat6 */
- DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a22.mmc2_dat7 */
- >;
- };
-};
-
&i2c1 {
status = "okay";
clock-frequency = <400000>;
--
2.11.0
^ permalink raw reply related
* [PATCH 04/14] ARM: dts: dra76x: Create a common file with MMC/SD IOdelay data
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
From: Sekhar Nori <nsekhar@ti.com>
Add a common device-tree include file with MMC/SD IOdelay data
for DRA76x SoC.
In the most common case, IOdelay data available in datamanual
can directly be used. This file caters to that common case.
Data is based on DRA76x datamanual, SPRS993A, revised July 2017.
Tested-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi | 435 ++++++++++++++++++++++++++++++
1 file changed, 435 insertions(+)
create mode 100644 arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi
diff --git a/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi b/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi
new file mode 100644
index 000000000000..67aa3e4d671d
--- /dev/null
+++ b/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi
@@ -0,0 +1,435 @@
+/*
+ * MMC IOdelay values for TI's DRA76x and AM576x SoCs.
+ *
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Rules for modifying this file:
+ * a) Update of this file should typically correspond to a datamanual revision.
+ * Datamanual revision that was used should be updated in comment below.
+ * If there is no update to datamanual, do not update the values. If you
+ * need to use values different from that recommended by the datamanual
+ * for your design, then you should consider adding values to the device-
+ * -tree file for your board directly.
+ * b) We keep the mode names as close to the datamanual as possible. So
+ * if the manual calls a mode, DDR50, or DDR or DDR 1.8v or DDR 3.3v,
+ * we follow that in code too.
+ * c) If the values change between multiple revisions of silicon, we add
+ * a revision tag to both the new and old entry. Use 'rev11' for PG 1.1,
+ * 'rev20' for PG 2.0 and so on.
+ * d) The node name and node label should be the exact same string. This is
+ * to curb naming creativity and achieve consistency.
+ *
+ * Datamanual Revisions:
+ *
+ * DRA76x Silicon Revision 1.0: SPRS993A, Revised July 2017
+ *
+ */
+
+&dra7_pmx_core {
+ mmc1_pins_default: mmc1_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+
+ mmc1_pins_sdr12: mmc1_pins_sdr12 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+
+ mmc1_pins_hs: mmc1_pins_hs {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+
+ mmc1_pins_sdr25: mmc1_pins_sdr25 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+
+ mmc1_pins_sdr50: mmc1_pins_sdr50 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE10 | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE10 | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE10 | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE10 | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE10 | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_VIRTUAL_MODE10 | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+
+ mmc1_pins_ddr50: mmc1_pins_ddr50 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+
+ mmc1_pins_sdr104: mmc1_pins_sdr104 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+
+ mmc2_pins_default: mmc2_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x349c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a23.mmc2_clk */
+ DRA7XX_CORE_IOPAD(0x34b0, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_cs1.mmc2_cmd */
+ DRA7XX_CORE_IOPAD(0x34a0, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a24.mmc2_dat0 */
+ DRA7XX_CORE_IOPAD(0x34a4, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a25.mmc2_dat1 */
+ DRA7XX_CORE_IOPAD(0x34a8, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a26.mmc2_dat2 */
+ DRA7XX_CORE_IOPAD(0x34ac, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a27.mmc2_dat3 */
+ DRA7XX_CORE_IOPAD(0x348c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a19.mmc2_dat4 */
+ DRA7XX_CORE_IOPAD(0x3490, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a20.mmc2_dat5 */
+ DRA7XX_CORE_IOPAD(0x3494, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a21.mmc2_dat6 */
+ DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a22.mmc2_dat7 */
+ >;
+ };
+
+ mmc2_pins_hs: mmc2_pins_hs {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x349c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a23.mmc2_clk */
+ DRA7XX_CORE_IOPAD(0x34b0, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_cs1.mmc2_cmd */
+ DRA7XX_CORE_IOPAD(0x34a0, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a24.mmc2_dat0 */
+ DRA7XX_CORE_IOPAD(0x34a4, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a25.mmc2_dat1 */
+ DRA7XX_CORE_IOPAD(0x34a8, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a26.mmc2_dat2 */
+ DRA7XX_CORE_IOPAD(0x34ac, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a27.mmc2_dat3 */
+ DRA7XX_CORE_IOPAD(0x348c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a19.mmc2_dat4 */
+ DRA7XX_CORE_IOPAD(0x3490, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a20.mmc2_dat5 */
+ DRA7XX_CORE_IOPAD(0x3494, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a21.mmc2_dat6 */
+ DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a22.mmc2_dat7 */
+ >;
+ };
+
+ mmc2_pins_ddr: mmc2_pins_ddr {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x349c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a23.mmc2_clk */
+ DRA7XX_CORE_IOPAD(0x34b0, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_cs1.mmc2_cmd */
+ DRA7XX_CORE_IOPAD(0x34a0, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a24.mmc2_dat0 */
+ DRA7XX_CORE_IOPAD(0x34a4, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a25.mmc2_dat1 */
+ DRA7XX_CORE_IOPAD(0x34a8, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a26.mmc2_dat2 */
+ DRA7XX_CORE_IOPAD(0x34ac, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a27.mmc2_dat3 */
+ DRA7XX_CORE_IOPAD(0x348c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a19.mmc2_dat4 */
+ DRA7XX_CORE_IOPAD(0x3490, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a20.mmc2_dat5 */
+ DRA7XX_CORE_IOPAD(0x3494, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a21.mmc2_dat6 */
+ DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a22.mmc2_dat7 */
+ >;
+ };
+
+ mmc2_pins_hs200: mmc2_pins_hs200 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x349c, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_a23.mmc2_clk */
+ DRA7XX_CORE_IOPAD(0x34b0, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_cs1.mmc2_cmd */
+ DRA7XX_CORE_IOPAD(0x34a0, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_a24.mmc2_dat0 */
+ DRA7XX_CORE_IOPAD(0x34a4, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_a25.mmc2_dat1 */
+ DRA7XX_CORE_IOPAD(0x34a8, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_a26.mmc2_dat2 */
+ DRA7XX_CORE_IOPAD(0x34ac, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_a27.mmc2_dat3 */
+ DRA7XX_CORE_IOPAD(0x348c, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_a19.mmc2_dat4 */
+ DRA7XX_CORE_IOPAD(0x3490, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_a20.mmc2_dat5 */
+ DRA7XX_CORE_IOPAD(0x3494, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_a21.mmc2_dat6 */
+ DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE1) /* gpmc_a22.mmc2_dat7 */
+ >;
+ };
+
+ mmc3_pins_default: mmc3_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
+ DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
+ DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
+ DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
+ DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
+ DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
+ >;
+ };
+
+ mmc3_pins_hs: mmc3_pins_hs {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
+ DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
+ DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
+ DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
+ DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
+ DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
+ >;
+ };
+
+ mmc3_pins_sdr12: mmc3_pins_sdr12 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
+ DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
+ DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
+ DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
+ DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
+ DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
+ >;
+ };
+
+ mmc3_pins_sdr25: mmc3_pins_sdr25 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
+ DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
+ DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
+ DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
+ DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
+ DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
+ >;
+ };
+
+ mmc3_pins_sdr50: mmc3_pins_sdr50 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x377c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_clk.mmc3_clk */
+ DRA7XX_CORE_IOPAD(0x3780, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_cmd.mmc3_cmd */
+ DRA7XX_CORE_IOPAD(0x3784, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat0.mmc3_dat0 */
+ DRA7XX_CORE_IOPAD(0x3788, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat1.mmc3_dat1 */
+ DRA7XX_CORE_IOPAD(0x378c, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat2.mmc3_dat2 */
+ DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 */
+ >;
+ };
+
+ mmc4_pins_default: mmc4_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x37e8, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart1_ctsn.mmc4_clk */
+ DRA7XX_CORE_IOPAD(0x37ec, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart1_rtsn.mmc4_cmd */
+ DRA7XX_CORE_IOPAD(0x37f0, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_rxd.mmc4_dat0 */
+ DRA7XX_CORE_IOPAD(0x37f4, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_txd.mmc4_dat1 */
+ DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_ctsn.mmc4_dat2 */
+ DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_rtsn.mmc4_dat3 */
+ >;
+ };
+
+ mmc4_pins_sdr12: mmc4_pins_sdr12 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x37e8, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart1_ctsn.mmc4_clk */
+ DRA7XX_CORE_IOPAD(0x37ec, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart1_rtsn.mmc4_cmd */
+ DRA7XX_CORE_IOPAD(0x37f0, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_rxd.mmc4_dat0 */
+ DRA7XX_CORE_IOPAD(0x37f4, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_txd.mmc4_dat1 */
+ DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_ctsn.mmc4_dat2 */
+ DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_rtsn.mmc4_dat3 */
+ >;
+ };
+
+ mmc4_pins_hs: mmc4_pins_hs {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x37e8, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart1_ctsn.mmc4_clk */
+ DRA7XX_CORE_IOPAD(0x37ec, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart1_rtsn.mmc4_cmd */
+ DRA7XX_CORE_IOPAD(0x37f0, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_rxd.mmc4_dat0 */
+ DRA7XX_CORE_IOPAD(0x37f4, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_txd.mmc4_dat1 */
+ DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_ctsn.mmc4_dat2 */
+ DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_rtsn.mmc4_dat3 */
+ >;
+ };
+
+ mmc4_pins_sdr25: mmc4_pins_sdr25 {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x37e8, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart1_ctsn.mmc4_clk */
+ DRA7XX_CORE_IOPAD(0x37ec, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart1_rtsn.mmc4_cmd */
+ DRA7XX_CORE_IOPAD(0x37f0, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_rxd.mmc4_dat0 */
+ DRA7XX_CORE_IOPAD(0x37f4, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_txd.mmc4_dat1 */
+ DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_ctsn.mmc4_dat2 */
+ DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE3) /* uart2_rtsn.mmc4_dat3 */
+ >;
+ };
+};
+
+&dra7_iodelay_core {
+
+ /* Corresponds to MMC1_DDR_MANUAL1 in datamanual */
+ mmc1_iodelay_ddr_conf: mmc1_iodelay_ddr_conf {
+ pinctrl-pin-array = <
+ 0x618 A_DELAY_PS(489) G_DELAY_PS(0) /* CFG_MMC1_CLK_IN */
+ 0x624 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_CMD_IN */
+ 0x630 A_DELAY_PS(374) G_DELAY_PS(0) /* CFG_MMC1_DAT0_IN */
+ 0x63c A_DELAY_PS(31) G_DELAY_PS(0) /* CFG_MMC1_DAT1_IN */
+ 0x648 A_DELAY_PS(56) G_DELAY_PS(0) /* CFG_MMC1_DAT2_IN */
+ 0x654 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT3_IN */
+ 0x620 A_DELAY_PS(1355) G_DELAY_PS(0) /* CFG_MMC1_CLK_OUT */
+ 0x628 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_CMD_OEN */
+ 0x62c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_CMD_OUT */
+ 0x634 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT0_OEN */
+ 0x638 A_DELAY_PS(0) G_DELAY_PS(4) /* CFG_MMC1_DAT0_OUT */
+ 0x640 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT1_OEN */
+ 0x644 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT1_OUT */
+ 0x64c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT2_OEN */
+ 0x650 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT2_OUT */
+ 0x658 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT3_OEN */
+ 0x65c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT3_OUT */
+ >;
+ };
+
+ /* Corresponds to MMC1_SDR104_MANUAL1 in datamanual */
+ mmc1_iodelay_sdr104_conf: mmc1_iodelay_sdr104_conf {
+ pinctrl-pin-array = <
+ 0x620 A_DELAY_PS(892) G_DELAY_PS(0) /* CFG_MMC1_CLK_OUT */
+ 0x628 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_CMD_OEN */
+ 0x62c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_CMD_OUT */
+ 0x634 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT0_OEN */
+ 0x638 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT0_OUT */
+ 0x640 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT1_OEN */
+ 0x644 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT1_OUT */
+ 0x64c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT2_OEN */
+ 0x650 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT2_OUT */
+ 0x658 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT3_OEN */
+ 0x65c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC1_DAT3_OUT */
+ >;
+ };
+
+ /* Corresponds to MMC2_HS200_MANUAL1 in datamanual */
+ mmc2_iodelay_hs200_conf: mmc2_iodelay_hs200_conf {
+ pinctrl-pin-array = <
+ 0x190 A_DELAY_PS(384) G_DELAY_PS(0) /* CFG_GPMC_A19_OEN */
+ 0x194 A_DELAY_PS(0) G_DELAY_PS(174) /* CFG_GPMC_A19_OUT */
+ 0x1a8 A_DELAY_PS(410) G_DELAY_PS(0) /* CFG_GPMC_A20_OEN */
+ 0x1ac A_DELAY_PS(85) G_DELAY_PS(0) /* CFG_GPMC_A20_OUT */
+ 0x1b4 A_DELAY_PS(468) G_DELAY_PS(0) /* CFG_GPMC_A21_OEN */
+ 0x1b8 A_DELAY_PS(139) G_DELAY_PS(0) /* CFG_GPMC_A21_OUT */
+ 0x1c0 A_DELAY_PS(676) G_DELAY_PS(0) /* CFG_GPMC_A22_OEN */
+ 0x1c4 A_DELAY_PS(69) G_DELAY_PS(0) /* CFG_GPMC_A22_OUT */
+ 0x1d0 A_DELAY_PS(1062) G_DELAY_PS(154) /* CFG_GPMC_A23_OUT */
+ 0x1d8 A_DELAY_PS(640) G_DELAY_PS(0) /* CFG_GPMC_A24_OEN */
+ 0x1dc A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_GPMC_A24_OUT */
+ 0x1e4 A_DELAY_PS(356) G_DELAY_PS(0) /* CFG_GPMC_A25_OEN */
+ 0x1e8 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_GPMC_A25_OUT */
+ 0x1f0 A_DELAY_PS(579) G_DELAY_PS(0) /* CFG_GPMC_A26_OEN */
+ 0x1f4 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_GPMC_A26_OUT */
+ 0x1fc A_DELAY_PS(435) G_DELAY_PS(0) /* CFG_GPMC_A27_OEN */
+ 0x200 A_DELAY_PS(36) G_DELAY_PS(0) /* CFG_GPMC_A27_OUT */
+ 0x364 A_DELAY_PS(759) G_DELAY_PS(0) /* CFG_GPMC_CS1_OEN */
+ 0x368 A_DELAY_PS(72) G_DELAY_PS(0) /* CFG_GPMC_CS1_OUT */
+ >;
+ };
+
+ /* Corresponds to MMC3_MANUAL1 in datamanual */
+ mmc3_iodelay_manual1_conf: mmc3_iodelay_manual1_conf {
+ pinctrl-pin-array = <
+ 0x678 A_DELAY_PS(0) G_DELAY_PS(386) /* CFG_MMC3_CLK_IN */
+ 0x680 A_DELAY_PS(605) G_DELAY_PS(0) /* CFG_MMC3_CLK_OUT */
+ 0x684 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_CMD_IN */
+ 0x688 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_CMD_OEN */
+ 0x68c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_CMD_OUT */
+ 0x690 A_DELAY_PS(171) G_DELAY_PS(0) /* CFG_MMC3_DAT0_IN */
+ 0x694 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT0_OEN */
+ 0x698 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT0_OUT */
+ 0x69c A_DELAY_PS(221) G_DELAY_PS(0) /* CFG_MMC3_DAT1_IN */
+ 0x6a0 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT1_OEN */
+ 0x6a4 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT1_OUT */
+ 0x6a8 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT2_IN */
+ 0x6ac A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT2_OEN */
+ 0x6b0 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT2_OUT */
+ 0x6b4 A_DELAY_PS(474) G_DELAY_PS(0) /* CFG_MMC3_DAT3_IN */
+ 0x6b8 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT3_OEN */
+ 0x6bc A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT3_OUT */
+ >;
+ };
+
+ /* Corresponds to MMC3_MANUAL2 in datamanual */
+ mmc3_iodelay_sdr50_conf: mmc3_iodelay_sdr50_conf {
+ pinctrl-pin-array = <
+ 0x678 A_DELAY_PS(852) G_DELAY_PS(0) /* CFG_MMC3_CLK_IN */
+ 0x680 A_DELAY_PS(94) G_DELAY_PS(0) /* CFG_MMC3_CLK_OUT */
+ 0x684 A_DELAY_PS(122) G_DELAY_PS(0) /* CFG_MMC3_CMD_IN */
+ 0x688 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_CMD_OEN */
+ 0x68c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_CMD_OUT */
+ 0x690 A_DELAY_PS(91) G_DELAY_PS(0) /* CFG_MMC3_DAT0_IN */
+ 0x694 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT0_OEN */
+ 0x698 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT0_OUT */
+ 0x69c A_DELAY_PS(57) G_DELAY_PS(0) /* CFG_MMC3_DAT1_IN */
+ 0x6a0 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT1_OEN */
+ 0x6a4 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT1_OUT */
+ 0x6a8 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT2_IN */
+ 0x6ac A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT2_OEN */
+ 0x6b0 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT2_OUT */
+ 0x6b4 A_DELAY_PS(375) G_DELAY_PS(0) /* CFG_MMC3_DAT3_IN */
+ 0x6b8 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT3_OEN */
+ 0x6bc A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_MMC3_DAT3_OUT */
+ >;
+ };
+
+ /* Corresponds to MMC4_MANUAL1 in datamanual */
+ mmc4_iodelay_manual1_conf: mmc4_iodelay_manual1_conf {
+ pinctrl-pin-array = <
+ 0x840 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART1_CTSN_IN */
+ 0x848 A_DELAY_PS(1147) G_DELAY_PS(0) /* CFG_UART1_CTSN_OUT */
+ 0x84c A_DELAY_PS(1834) G_DELAY_PS(0) /* CFG_UART1_RTSN_IN */
+ 0x850 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART1_RTSN_OEN */
+ 0x854 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART1_RTSN_OUT */
+ 0x870 A_DELAY_PS(2165) G_DELAY_PS(0) /* CFG_UART2_CTSN_IN */
+ 0x874 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_CTSN_OEN */
+ 0x878 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_CTSN_OUT */
+ 0x87c A_DELAY_PS(1929) G_DELAY_PS(64) /* CFG_UART2_RTSN_IN */
+ 0x880 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_RTSN_OEN */
+ 0x884 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_RTSN_OUT */
+ 0x888 A_DELAY_PS(1935) G_DELAY_PS(128) /* CFG_UART2_RXD_IN */
+ 0x88c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_RXD_OEN */
+ 0x890 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_RXD_OUT */
+ 0x894 A_DELAY_PS(2172) G_DELAY_PS(44) /* CFG_UART2_TXD_IN */
+ 0x898 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_TXD_OEN */
+ 0x89c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_TXD_OUT */
+ >;
+ };
+
+ /* Corresponds to MMC4_DS_MANUAL1 in datamanual */
+ mmc4_iodelay_default_conf: mmc4_iodelay_default_conf {
+ pinctrl-pin-array = <
+ 0x840 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART1_CTSN_IN */
+ 0x848 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART1_CTSN_OUT */
+ 0x84c A_DELAY_PS(307) G_DELAY_PS(0) /* CFG_UART1_RTSN_IN */
+ 0x850 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART1_RTSN_OEN */
+ 0x854 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART1_RTSN_OUT */
+ 0x870 A_DELAY_PS(785) G_DELAY_PS(0) /* CFG_UART2_CTSN_IN */
+ 0x874 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_CTSN_OEN */
+ 0x878 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_CTSN_OUT */
+ 0x87c A_DELAY_PS(613) G_DELAY_PS(0) /* CFG_UART2_RTSN_IN */
+ 0x880 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_RTSN_OEN */
+ 0x884 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_RTSN_OUT */
+ 0x888 A_DELAY_PS(683) G_DELAY_PS(0) /* CFG_UART2_RXD_IN */
+ 0x88c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_RXD_OEN */
+ 0x890 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_RXD_OUT */
+ 0x894 A_DELAY_PS(835) G_DELAY_PS(0) /* CFG_UART2_TXD_IN */
+ 0x898 A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_TXD_OEN */
+ 0x89c A_DELAY_PS(0) G_DELAY_PS(0) /* CFG_UART2_TXD_OUT */
+ >;
+ };
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 03/14] ARM: configs: keystone: Enable CONFIG_MMC_SDHCI_OMAP
From: Kishon Vijay Abraham I @ 2017-12-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214134054.7749-1-kishon@ti.com>
Enable CONFIG_MMC_SDHCI_OMAP so that TI's k2g SoC
can use sdhci-omap driver for MMC/SD controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/configs/keystone_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
index f710c192b33a..264260a9b1be 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -170,7 +170,10 @@ CONFIG_USB_DWC3=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_KEYSTONE_USB_PHY=y
CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_OMAP_HS=y
+CONFIG_MMC_SDHCI_OMAP=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
--
2.11.0
^ 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