* [PATCH v4 0/2] gpio: Generalise state persistence
From: Andrew Jeffery @ 2017-11-30 3:55 UTC (permalink / raw)
To: linux-gpio-u79uwXL29TY76Z2rM5mHXA
Cc: Andrew Jeffery, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w, joel-U3u1mxZcP9KHXe+LvDLADg,
ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
ldewangan-DDmLM1+adcrQT0dZR+AlfA,
ryan_chen-SAlXDmAnmOAqDJ6do+/SaQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-aspeed-uLR06cmDAlY/bJ5BZ2RsiQ
Hello,
This series provides an API to configure general GPIO state persistence in
gpiolib. Previously, only sleep persistence was considered, but controllers
like one found in Aspeed BMCs also support persistence of state across
controller resets. There is some prior discussion on v1[1] and the initial
RFC[2], and minor comments on v2[3]. v3 addresses minor issues with comments
and debug statements[4], removing remaining references to reset tolerance.
v4 is just a rebase of v3 onto v4.15-rc1, fixing a conflict with the new
PIN_CONFIG_SKEW_DELAY pinconf parameter.
Please review!
Andrew
[1] https://www.spinics.net/lists/devicetree/msg200027.html
[2] https://www.spinics.net/lists/devicetree/msg199559.html
[3] https://www.spinics.net/lists/kernel/msg2635769.html
[4] https://www.spinics.net/lists/devicetree/msg200040.html
Andrew Jeffery (2):
gpio: gpiolib: Generalise state persistence beyond sleep
gpio: aspeed: Add support for reset tolerance
drivers/gpio/gpio-aspeed.c | 39 +++++++++++++++++++--
drivers/gpio/gpiolib-of.c | 6 ++--
drivers/gpio/gpiolib-sysfs.c | 14 +++++---
drivers/gpio/gpiolib.c | 61 ++++++++++++++++++++++++++++++---
drivers/gpio/gpiolib.h | 2 +-
include/dt-bindings/gpio/gpio.h | 6 ++--
include/linux/gpio/consumer.h | 8 +++++
include/linux/gpio/machine.h | 4 +--
include/linux/of_gpio.h | 2 +-
include/linux/pinctrl/pinconf-generic.h | 2 ++
10 files changed, 124 insertions(+), 20 deletions(-)
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 1/2] gpio: gpiolib: Generalise state persistence beyond sleep
From: Andrew Jeffery @ 2017-11-30 3:55 UTC (permalink / raw)
To: linux-gpio
Cc: Andrew Jeffery, linus.walleij, robh+dt, mark.rutland,
frowand.list, joel, ckeepax, ldewangan, ryan_chen, linux-kernel,
devicetree, openbmc, linux-aspeed
In-Reply-To: <20171130035525.29653-1-andrew@aj.id.au>
General support for state persistence is added to gpiolib with the
introduction of a new pinconf parameter to propagate the request to
hardware. The existing persistence support for sleep is adapted to
include hardware support if the GPIO driver provides it. Persistence
continues to be enabled by default; in-kernel consumers can opt out, but
userspace (currently) does not have a choice.
The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are
renamed, dropping the SLEEP prefix to reflect that the concept is no
longer sleep-specific. I feel that renaming to just *_MAY_LOSE_VALUE
could initially be misinterpreted, so I've further changed the symbols
to *_TRANSITORY and *_PERSISTENT to address this.
The sysfs interface is modified only to keep consistency with the
chardev interface in enforcing persistence for userspace exports.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Rob Herring <robh@kernel.org>
---
drivers/gpio/gpiolib-of.c | 6 ++--
drivers/gpio/gpiolib-sysfs.c | 14 +++++---
drivers/gpio/gpiolib.c | 61 ++++++++++++++++++++++++++++++---
drivers/gpio/gpiolib.h | 2 +-
include/dt-bindings/gpio/gpio.h | 6 ++--
include/linux/gpio/consumer.h | 8 +++++
include/linux/gpio/machine.h | 4 +--
include/linux/of_gpio.h | 2 +-
include/linux/pinctrl/pinconf-generic.h | 2 ++
9 files changed, 87 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index e0d59e61b52f..4a2b8d3397c7 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -153,8 +153,8 @@ struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
*flags |= GPIO_OPEN_SOURCE;
}
- if (of_flags & OF_GPIO_SLEEP_MAY_LOSE_VALUE)
- *flags |= GPIO_SLEEP_MAY_LOSE_VALUE;
+ if (of_flags & OF_GPIO_TRANSITORY)
+ *flags |= GPIO_TRANSITORY;
return desc;
}
@@ -214,6 +214,8 @@ static struct gpio_desc *of_parse_own_gpio(struct device_node *np,
if (xlate_flags & OF_GPIO_ACTIVE_LOW)
*lflags |= GPIO_ACTIVE_LOW;
+ if (xlate_flags & OF_GPIO_TRANSITORY)
+ *lflags |= GPIO_TRANSITORY;
if (of_property_read_bool(np, "input"))
*dflags |= GPIOD_IN;
diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
index 3f454eaf2101..0bd472ffb072 100644
--- a/drivers/gpio/gpiolib-sysfs.c
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -474,11 +474,15 @@ static ssize_t export_store(struct class *class,
status = -ENODEV;
goto done;
}
- status = gpiod_export(desc, true);
- if (status < 0)
- gpiod_free(desc);
- else
- set_bit(FLAG_SYSFS, &desc->flags);
+
+ status = gpiod_set_transitory(desc, false);
+ if (!status) {
+ status = gpiod_export(desc, true);
+ if (status < 0)
+ gpiod_free(desc);
+ else
+ set_bit(FLAG_SYSFS, &desc->flags);
+ }
done:
if (status)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index aad84a6306c4..e91c2d28b7bd 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -505,6 +505,10 @@ static int linehandle_create(struct gpio_device *gdev, void __user *ip)
if (lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE)
set_bit(FLAG_OPEN_SOURCE, &desc->flags);
+ ret = gpiod_set_transitory(desc, false);
+ if (ret < 0)
+ goto out_free_descs;
+
/*
* Lines have to be requested explicitly for input
* or output, else the line will be treated "as is".
@@ -2520,6 +2524,49 @@ int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce)
}
EXPORT_SYMBOL_GPL(gpiod_set_debounce);
+/**
+ * gpiod_set_transitory - Lose or retain GPIO state on suspend or reset
+ * @desc: descriptor of the GPIO for which to configure persistence
+ * @transitory: True to lose state on suspend or reset, false for persistence
+ *
+ * Returns:
+ * 0 on success, otherwise a negative error code.
+ */
+int gpiod_set_transitory(struct gpio_desc *desc, bool transitory)
+{
+ struct gpio_chip *chip;
+ unsigned long packed;
+ int gpio;
+ int rc;
+
+ /*
+ * Handle FLAG_TRANSITORY first, enabling queries to gpiolib for
+ * persistence state.
+ */
+ if (transitory)
+ set_bit(FLAG_TRANSITORY, &desc->flags);
+ else
+ clear_bit(FLAG_TRANSITORY, &desc->flags);
+
+ /* If the driver supports it, set the persistence state now */
+ chip = desc->gdev->chip;
+ if (!chip->set_config)
+ return 0;
+
+ packed = pinconf_to_config_packed(PIN_CONFIG_PERSIST_STATE,
+ !transitory);
+ gpio = gpio_chip_hwgpio(desc);
+ rc = chip->set_config(chip, gpio, packed);
+ if (rc == -ENOTSUPP) {
+ dev_dbg(&desc->gdev->dev, "Persistence not supported for GPIO %d\n",
+ gpio);
+ return 0;
+ }
+
+ return rc;
+}
+EXPORT_SYMBOL_GPL(gpiod_set_transitory);
+
/**
* gpiod_is_active_low - test whether a GPIO is active-low or not
* @desc: the gpio descriptor to test
@@ -3107,8 +3154,7 @@ bool gpiochip_line_is_persistent(struct gpio_chip *chip, unsigned int offset)
if (offset >= chip->ngpio)
return false;
- return !test_bit(FLAG_SLEEP_MAY_LOSE_VALUE,
- &chip->gpiodev->descs[offset].flags);
+ return !test_bit(FLAG_TRANSITORY, &chip->gpiodev->descs[offset].flags);
}
EXPORT_SYMBOL_GPL(gpiochip_line_is_persistent);
@@ -3545,8 +3591,10 @@ int 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_SLEEP_MAY_LOSE_VALUE)
- set_bit(FLAG_SLEEP_MAY_LOSE_VALUE, &desc->flags);
+
+ status = gpiod_set_transitory(desc, (lflags & GPIO_TRANSITORY));
+ if (status < 0)
+ return status;
/* No particular flag request, return here... */
if (!(dflags & GPIOD_FLAGS_BIT_DIR_SET)) {
@@ -3660,6 +3708,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
bool active_low = false;
bool single_ended = false;
bool open_drain = false;
+ bool transitory = false;
int ret;
if (!fwnode)
@@ -3674,6 +3723,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
active_low = flags & OF_GPIO_ACTIVE_LOW;
single_ended = flags & OF_GPIO_SINGLE_ENDED;
open_drain = flags & OF_GPIO_OPEN_DRAIN;
+ transitory = flags & OF_GPIO_TRANSITORY;
}
} else if (is_acpi_node(fwnode)) {
struct acpi_gpio_info info;
@@ -3704,6 +3754,9 @@ struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
lflags |= GPIO_OPEN_SOURCE;
}
+ if (transitory)
+ lflags |= GPIO_TRANSITORY;
+
ret = gpiod_configure_flags(desc, propname, lflags, dflags);
if (ret < 0) {
gpiod_put(desc);
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index af48322839c3..736b189d1bb5 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -205,7 +205,7 @@ struct gpio_desc {
#define FLAG_OPEN_SOURCE 8 /* Gpio is open source type */
#define FLAG_USED_AS_IRQ 9 /* GPIO is connected to an IRQ */
#define FLAG_IS_HOGGED 11 /* GPIO is hogged */
-#define FLAG_SLEEP_MAY_LOSE_VALUE 12 /* GPIO may lose value in sleep */
+#define FLAG_TRANSITORY 12 /* GPIO may lose value in sleep or reset */
/* Connection label */
const char *label;
diff --git a/include/dt-bindings/gpio/gpio.h b/include/dt-bindings/gpio/gpio.h
index dd549ff04295..2cc10ae4bbb7 100644
--- a/include/dt-bindings/gpio/gpio.h
+++ b/include/dt-bindings/gpio/gpio.h
@@ -29,8 +29,8 @@
#define GPIO_OPEN_DRAIN (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN)
#define GPIO_OPEN_SOURCE (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_SOURCE)
-/* Bit 3 express GPIO suspend/resume persistence */
-#define GPIO_SLEEP_MAINTAIN_VALUE 0
-#define GPIO_SLEEP_MAY_LOSE_VALUE 8
+/* Bit 3 express GPIO suspend/resume and reset persistence */
+#define GPIO_PERSISTENT 0
+#define GPIO_TRANSITORY 8
#endif
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 7447d85dbe2f..540b2c142493 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -139,6 +139,7 @@ void gpiod_set_raw_array_value_cansleep(unsigned int array_size,
int *value_array);
int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce);
+int gpiod_set_transitory(struct gpio_desc *desc, bool transitory);
int gpiod_is_active_low(const struct gpio_desc *desc);
int gpiod_cansleep(const struct gpio_desc *desc);
@@ -431,6 +432,13 @@ static inline int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce)
return -ENOSYS;
}
+static inline int gpiod_set_transitory(struct gpio_desc *desc, bool transitory)
+{
+ /* GPIO can never have been requested */
+ WARN_ON(1);
+ return -ENOSYS;
+}
+
static inline int gpiod_is_active_low(const struct gpio_desc *desc)
{
/* GPIO can never have been requested */
diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
index 846be7c69a52..b2f2dc638463 100644
--- a/include/linux/gpio/machine.h
+++ b/include/linux/gpio/machine.h
@@ -10,8 +10,8 @@ enum gpio_lookup_flags {
GPIO_ACTIVE_LOW = (1 << 0),
GPIO_OPEN_DRAIN = (1 << 1),
GPIO_OPEN_SOURCE = (1 << 2),
- GPIO_SLEEP_MAINTAIN_VALUE = (0 << 3),
- GPIO_SLEEP_MAY_LOSE_VALUE = (1 << 3),
+ GPIO_PERSISTENT = (0 << 3),
+ GPIO_TRANSITORY = (1 << 3),
};
/**
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index 1fe205582111..18a7f03e1182 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -31,7 +31,7 @@ enum of_gpio_flags {
OF_GPIO_ACTIVE_LOW = 0x1,
OF_GPIO_SINGLE_ENDED = 0x2,
OF_GPIO_OPEN_DRAIN = 0x4,
- OF_GPIO_SLEEP_MAY_LOSE_VALUE = 0x8,
+ OF_GPIO_TRANSITORY = 0x8,
};
#ifdef CONFIG_OF_GPIO
diff --git a/include/linux/pinctrl/pinconf-generic.h b/include/linux/pinctrl/pinconf-generic.h
index ec6dadcc1fde..6c0680641108 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -94,6 +94,7 @@
* or latch delay (on outputs) this parameter (in a custom format)
* specifies the clock skew or latch delay. It typically controls how
* many double inverters are put in front of the line.
+ * @PIN_CONFIG_PERSIST_STATE: retain pin state across sleep or controller reset
* @PIN_CONFIG_END: this is the last enumerator for pin configurations, if
* you need to pass in custom configurations to the pin controller, use
* PIN_CONFIG_END+1 as the base offset.
@@ -122,6 +123,7 @@ enum pin_config_param {
PIN_CONFIG_SLEEP_HARDWARE_STATE,
PIN_CONFIG_SLEW_RATE,
PIN_CONFIG_SKEW_DELAY,
+ PIN_CONFIG_PERSIST_STATE,
PIN_CONFIG_END = 0x7F,
PIN_CONFIG_MAX = 0xFF,
};
--
2.14.1
^ permalink raw reply related
* [PATCH v4 2/2] gpio: aspeed: Add support for reset tolerance
From: Andrew Jeffery @ 2017-11-30 3:55 UTC (permalink / raw)
To: linux-gpio
Cc: Andrew Jeffery, linus.walleij, robh+dt, mark.rutland,
frowand.list, joel, ckeepax, ldewangan, ryan_chen, linux-kernel,
devicetree, openbmc, linux-aspeed
In-Reply-To: <20171130035525.29653-1-andrew@aj.id.au>
Use the new pinconf parameter for state persistence to expose the
associated capability of the Aspeed GPIO controller.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
---
drivers/gpio/gpio-aspeed.c | 39 +++++++++++++++++++++++++++++++++++++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 6b3ca6601af2..30bc97b81bec 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -60,6 +60,7 @@ struct aspeed_gpio_bank {
uint16_t val_regs;
uint16_t irq_regs;
uint16_t debounce_regs;
+ uint16_t tolerance_regs;
const char names[4][3];
};
@@ -70,48 +71,56 @@ static const struct aspeed_gpio_bank aspeed_gpio_banks[] = {
.val_regs = 0x0000,
.irq_regs = 0x0008,
.debounce_regs = 0x0040,
+ .tolerance_regs = 0x001c,
.names = { "A", "B", "C", "D" },
},
{
.val_regs = 0x0020,
.irq_regs = 0x0028,
.debounce_regs = 0x0048,
+ .tolerance_regs = 0x003c,
.names = { "E", "F", "G", "H" },
},
{
.val_regs = 0x0070,
.irq_regs = 0x0098,
.debounce_regs = 0x00b0,
+ .tolerance_regs = 0x00ac,
.names = { "I", "J", "K", "L" },
},
{
.val_regs = 0x0078,
.irq_regs = 0x00e8,
.debounce_regs = 0x0100,
+ .tolerance_regs = 0x00fc,
.names = { "M", "N", "O", "P" },
},
{
.val_regs = 0x0080,
.irq_regs = 0x0118,
.debounce_regs = 0x0130,
+ .tolerance_regs = 0x012c,
.names = { "Q", "R", "S", "T" },
},
{
.val_regs = 0x0088,
.irq_regs = 0x0148,
.debounce_regs = 0x0160,
+ .tolerance_regs = 0x015c,
.names = { "U", "V", "W", "X" },
},
{
.val_regs = 0x01E0,
.irq_regs = 0x0178,
.debounce_regs = 0x0190,
+ .tolerance_regs = 0x018c,
.names = { "Y", "Z", "AA", "AB" },
},
{
- .val_regs = 0x01E8,
- .irq_regs = 0x01A8,
+ .val_regs = 0x01e8,
+ .irq_regs = 0x01a8,
.debounce_regs = 0x01c0,
+ .tolerance_regs = 0x01bc,
.names = { "AC", "", "", "" },
},
};
@@ -534,6 +543,30 @@ static int aspeed_gpio_setup_irqs(struct aspeed_gpio *gpio,
return 0;
}
+static int aspeed_gpio_reset_tolerance(struct gpio_chip *chip,
+ unsigned int offset, bool enable)
+{
+ struct aspeed_gpio *gpio = gpiochip_get_data(chip);
+ const struct aspeed_gpio_bank *bank;
+ unsigned long flags;
+ u32 val;
+
+ bank = to_bank(offset);
+
+ spin_lock_irqsave(&gpio->lock, flags);
+ val = readl(gpio->base + bank->tolerance_regs);
+
+ if (enable)
+ val |= GPIO_BIT(offset);
+ else
+ val &= ~GPIO_BIT(offset);
+
+ writel(val, gpio->base + bank->tolerance_regs);
+ spin_unlock_irqrestore(&gpio->lock, flags);
+
+ return 0;
+}
+
static int aspeed_gpio_request(struct gpio_chip *chip, unsigned int offset)
{
if (!have_gpio(gpiochip_get_data(chip), offset))
@@ -771,6 +804,8 @@ static int aspeed_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
param == PIN_CONFIG_DRIVE_OPEN_SOURCE)
/* Return -ENOTSUPP to trigger emulation, as per datasheet */
return -ENOTSUPP;
+ else if (param == PIN_CONFIG_PERSIST_STATE)
+ return aspeed_gpio_reset_tolerance(chip, offset, arg);
return -ENOTSUPP;
}
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] ARM: dts: DRA76-EVM: Set powerhold property for tps65917
From: Keerthy @ 2017-11-30 4:14 UTC (permalink / raw)
To: Tony Lindgren
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, t-kristo-l0cyMroinI0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20171026141707.GE21504-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Thursday 26 October 2017 07:47 PM, Tony Lindgren wrote:
> * Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [171025 23:31]:
>>
>>
>> On Wednesday 25 October 2017 10:22 PM, Tony Lindgren wrote:
>>> * Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [171024 01:46]:
>>>> Set powerhold property for tps65917
>>>>
>>>> Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
>>>
>>> Is this safe to merge separately before the driver changes?
>>
>> This needs to wait till [1] is merged. I should have mentioned this.
>>
>> I will ping on this as soon as the dependent patch is merged.
>
> OK thanks will untag this patch from my inbox for now then.
Tony,
The dependent driver patch [1] is pulled by Lee Jones.
So this patch is okay to be applied.
[1] https://patchwork.kernel.org/patch/10023635/
- Keerthy
>
> Regards,
>
> Tony
>
>> [1] https://marc.info/?l=linux-omap&m=150883331614239&w=2
>>
>> Thanks,
>> Keerthy
>>
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>>> ---
>>>> 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 b024a65..f64aab4 100644
>>>> --- a/arch/arm/boot/dts/dra76-evm.dts
>>>> +++ b/arch/arm/boot/dts/dra76-evm.dts
>>>> @@ -148,6 +148,7 @@
>>>> compatible = "ti,tps65917";
>>>> reg = <0x58>;
>>>> ti,system-power-controller;
>>>> + ti,palmas-override-powerhold;
>>>> interrupt-controller;
>>>> #interrupt-cells = <2>;
>>>>
>>>> --
>>>> 1.9.1
>>>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH][v2] dt-bindings: ifc: Update endianness usage
From: Florian Fainelli @ 2017-11-30 4:37 UTC (permalink / raw)
To: Prabhakar Kushwaha, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1512013344-4042-1-git-send-email-prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
On 11/29/2017 07:42 PM, Prabhakar Kushwaha wrote:
> IFC controller version < 2.0 support IFC register access as
> big endian. These controller version also require IFC NOR signals to
> be connected in reverse order with NOR flash.
>
> IFC >= 2.0 is other way around.
>
> So updating IFC binding to take care of both using endianness field.
>
> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> ---
> Changes for v2: updated subject
>
> Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> index 89427b0..824a2ca 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> @@ -18,8 +18,10 @@ Properties:
> interrupt (NAND_EVTER_STAT). If there is only one,
> that interrupt reports both types of event.
>
> -- little-endian : If this property is absent, the big-endian mode will
> - be in use as default for registers.
> +- little-endian or big-endin : It represents how IFC registers to be accessed.
^==== big-endian (there is a typo)
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC V7 1/2] OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-11-30 4:48 UTC (permalink / raw)
To: Rob Herring
Cc: Ulf Hansson, Kevin Hilman, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rafael J. Wysocki, linux-pm@vger.kernel.org,
Vincent Guittot, Rajendra Nayak, Sudeep Holla,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqJr9pTkwODqxc1CKRv-zNr3B_kfy4U0g6imaV67oaca4A@mail.gmail.com>
On 29-11-17, 10:46, Rob Herring wrote:
> On Tue, Oct 31, 2017 at 7:47 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > +- power-domain-opp: This contains phandle to one of the OPP nodes of the master
> > + power domain. This specifies the minimum required OPP of the master domain for
> > + the functioning of the device in this OPP (where this property is present).
> > + This property can only be set for a device if the device node contains the
> > + "power-domains" property. Also, either all or none of the OPP nodes in an OPP
> > + table should have it set.
>
> This is a "this device requires OPP n" property. Couldn't we want this
> for cases other than a powerdomain OPP? What if a device has
> requirements 2 different OPPs?
Hmm, I agree. We can/should make it more generic.
> On the flipside, I don't think we want devices picking things like CPU
> OPPs and putting policy here. But I'd rather things be extendable than
> reviewing yet another OPP property next month.
Sure, I would rename this property and make necessary changes to it.
--
viresh
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Greentime Hu @ 2017-11-30 5:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Greentime, Linux Kernel Mailing List,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, Networking, Vincent Chen, DTML, Al Viro,
David Howells, Will Deacon, Daniel Lezcano,
linux-serial@vger.kernel.org, Vincent Chen
In-Reply-To: <CAK8P3a3-CexhRkJB7_8TGShuDQP8w=myhkoB8-7ax3my96PrMw@mail.gmail.com>
2017-11-30 4:27 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Wed, Nov 29, 2017 at 3:10 PM, Greentime Hu <green.hu@gmail.com> wrote:
>> 2017-11-29 19:57 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>> On Wed, Nov 29, 2017 at 12:39 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>
>>>> How about this?
>>>>
>>>> choice
>>>> prompt "CPU type"
>>>> default CPU_N13
>>>> config CPU_N15
>>>> bool "AndesCore N15"
>>>> select CPU_CACHE_NONALIASING
>>>> config CPU_N13
>>>> bool "AndesCore N13"
>>>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>>>> config CPU_N10
>>>> bool "AndesCore N10"
>>>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>>>> config CPU_D15
>>>> bool "AndesCore D15"
>>>> select CPU_CACHE_NONALIASING
>>>> select HWZOL
>>>> config CPU_D10
>>>> bool "AndesCore D10"
>>>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>>>> endchoice
>>>
>>> With a 'choice' statement this works, but I would consider that
>>> suboptimal for another reason: now you cannot build a kernel that
>>> works on e.g. both N13 and N15.
>>>
>>> This is what we had on ARM a long time ago and on MIPS not so long
>>> ago, but it's really a burden for testing and distribution once you get
>>> support for more than a handful of machines supported in the mainline
>>> kernel: If each CPU core is mutually incompatible with the other ones,
>>> this means you likely end up having one defconfig per CPU core,
>>> or even one defconfig per SoC or board.
>>>
>>> I would always try to get the largest amount of hardware to work
>>> in the same kernel concurrently.
>>>
>>> One way of of this would be to define the "CPU type" as the minimum
>>> supported CPU, e.g. selecting D15 would result in a kernel that
>>> only works on D15, while selecting N15 would work on both N15 and
>>> D15, and selecting D10 would work on both D10 and D15.
>>>
>>
>> Hi, Arnd:
>>
>> Maybe we should keep the original implementation for this reason.
>> The default value of CPU_CACHE_NONALIASING and ANDES_PAGE_SIZE_8KB is
>> available for all CPU types for now.
>> User can use these configs built kernel to boot on almost all nds32 CPUs.
>>
>> It might be a little bit weird if we config CPU_N10 but run on a N13 CPU.
>> This might confuse our users.
>
> I think it really depends on how much flexibility you want to give to users.
> The way I suggested first was to allow selecting an arbitrary combination
> of CPUs, and then let Kconfig derive the correct set of optimization flags
> and other options that work with those. That is probably the easiest for
> the users, but can be tricky to get right for all combinations.
>
> When you put them in a sorted list like I mentioned for simplicity, you
> could reduce the confusion by naming them differently, e.g.
> CONFIG_CPU_N10_OR_NEWER.
>
> Having only the CPU_CACHE_NONALIASING option is fine if you
> never need to make any other decisions based on the CPU core
> type, but then the help text should describe specifically which cases
> are affected (N10/N13/D13 with 4K page size), and you can decide to
> hide the option and make it always-on when using 8K page size.
>
> Arnd
Hi, Arnd:
I think I can use this name "CPU_V3" for all nds32 v3 compatible cpu.
It will be implemented like this.
config HWZOL
bool "hardware zero overhead loop support"
depends on CPU_D10 || CPU_D15
default n
help
A set of Zero-Overhead Loop mechanism is provided to reduce the
instruction fetch and execution overhead of loop-control instructions.
It will save 3 registers($LB, $LC, $LE) for context saving if say Y.
You don't need to save these registers if you can make sure your user
program doesn't use these registers.
If unsure, say N.
config CPU_CACHE_NONALIASING
bool "Non-aliasing cache"
depends on !CPU_N10 && !CPU_D10
default n
help
If this CPU is using VIPT data cache and its cache way size is larger
than page size, say N. If it is using PIPT data cache, say Y.
If unsure, say N.
choice
prompt "CPU type"
default CPU_V3
config CPU_N15
bool "AndesCore N15"
select CPU_CACHE_NONALIASING
config CPU_N13
bool "AndesCore N13"
select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
config CPU_N10
bool "AndesCore N10"
config CPU_D15
bool "AndesCore D15"
select CPU_CACHE_NONALIASING
config CPU_D10
bool "AndesCore D10"
config CPU_V3
bool "AndesCore v3 compatible"
select ANDES_PAGE_SIZE_4KB
endchoice
^ permalink raw reply
* Re: [PATCH v3 2/3] clk: meson-axg: add clock controller drivers
From: Yixun Lan @ 2017-11-30 6:01 UTC (permalink / raw)
To: Stephen Boyd
Cc: yixun.lan, Neil Armstrong, Jerome Brunet, Kevin Hilman,
Rob Herring, Mark Rutland, Michael Turquette, Carlo Caione,
Qiufang Dai, linux-amlogic, devicetree, linux-clk,
linux-arm-kernel, linux-kernel
In-Reply-To: <20171129193433.GA19419@codeaurora.org>
Hi Stephen
On 11/30/17 03:34, Stephen Boyd wrote:
> On 11/28, Yixun Lan wrote:
>> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
>> new file mode 100644
>> index 000000000000..51c5b4062715
>> --- /dev/null
>> +++ b/drivers/clk/meson/axg.c
>> @@ -0,0 +1,948 @@
>> +/*
>> + * AmLogic Meson-AXG Clock Controller Driver
>> + *
>> + * Copyright (c) 2016 Baylibre SAS.
>> + * Author: Michael Turquette <mturquette@baylibre.com>
>> + *
>> + * Copyright (c) 2017 Amlogic, inc.
>> + * Author: Qiufang Dai <qiufang.dai@amlogic.com>
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/clk-provider.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/init.h>
>> +
>> +#include "clkc.h"
>> +#include "axg.h"
>> +
>> +static DEFINE_SPINLOCK(clk_lock);
>
> meson_axg_clk_lock?
>
em... I'd leave it unchanged
because the spinlock will be used at macro MESON_GATE() [1] which
defined at drivers/clk/meson/clkc.h, and it assume using the generic
name 'clk_lock', change name will break the code..
and besides it's already defined as static, so I see no problem here
[1]
#define MESON_GATE(_name, _reg, _bit) \
struct clk_gate _name = { \
.reg = (void __iomem *) _reg, \
.bit_idx = (_bit), \
.lock = &clk_lock,
[2]
drivers/clk/meson/gxbb.c
drivers/clk/meson/meson8b.c
>> +
>> +static const struct pll_rate_table sys_pll_rate_table[] = {
>> + PLL_RATE(24000000, 56, 1, 2),
>> + PLL_RATE(48000000, 64, 1, 2),
>> + PLL_RATE(72000000, 72, 1, 2),
>> + PLL_RATE(96000000, 64, 1, 2),
>> + PLL_RATE(120000000, 80, 1, 2),
>> + PLL_RATE(144000000, 96, 1, 2),
>> + PLL_RATE(168000000, 56, 1, 1),
>> + PLL_RATE(192000000, 64, 1, 1),
>> + PLL_RATE(216000000, 72, 1, 1),
>> + PLL_RATE(240000000, 80, 1, 1),
> [...]
>> +
>> +static const struct clkc_data axg_clkc_data = {
>> + .clk_gates = axg_clk_gates,
>> + .clk_gates_count = ARRAY_SIZE(axg_clk_gates),
>> + .clk_mplls = axg_clk_mplls,
>> + .clk_mplls_count = ARRAY_SIZE(axg_clk_mplls),
>> + .clk_plls = axg_clk_plls,
>> + .clk_plls_count = ARRAY_SIZE(axg_clk_plls),
>> + .clk_muxes = axg_clk_muxes,
>> + .clk_muxes_count = ARRAY_SIZE(axg_clk_muxes),
>> + .clk_dividers = axg_clk_dividers,
>> + .clk_dividers_count = ARRAY_SIZE(axg_clk_dividers),
>> + .hw_onecell_data = &axg_hw_onecell_data,
>> +};
>> +
>> +static const struct of_device_id clkc_match_table[] = {
>> + { .compatible = "amlogic,axg-clkc", .data = &axg_clkc_data },
>> + {},
>
> Nitpick: Drop the comma. Nothing comes after this.
>
sure, can do
>> +};
>> +
>> +static int axg_clkc_probe(struct platform_device *pdev)
>> +{
>> + const struct clkc_data *clkc_data;
>> + void __iomem *clk_base;
>> + int ret, clkid, i;
>> + struct device *dev = &pdev->dev;
>> +
>> + clkc_data = of_device_get_match_data(&pdev->dev);
>> + if (!clkc_data)
>> + return -EINVAL;
>> +
>> + /* Generic clocks and PLLs */
>> + clk_base = of_iomap(dev->of_node, 0);
>
> Use platform device APIs for ioremapping?
>
I assume you are referring to 'platform_get_resource +
devm_ioremap_resource' ?
the idea sounds good to me.
>> + if (!clk_base) {
>> + pr_err("%s: Unable to map clk base\n", __func__);
>> + return -ENXIO;
>> + }
>> +
>> + /* Populate base address for PLLs */
>> + for (i = 0; i < clkc_data->clk_plls_count; i++)
>> + clkc_data->clk_plls[i]->base = clk_base;
>> +
>> + /* Populate base address for MPLLs */
>> + for (i = 0; i < clkc_data->clk_mplls_count; i++)
>> + clkc_data->clk_mplls[i]->base = clk_base;
>> +
>> + /* Populate base address for gates */
>> + for (i = 0; i < clkc_data->clk_gates_count; i++)
>> + clkc_data->clk_gates[i]->reg = clk_base +
>> + (u64)clkc_data->clk_gates[i]->reg;
>> +
>> + /* Populate base address for muxes */
>> + for (i = 0; i < clkc_data->clk_muxes_count; i++)
>> + clkc_data->clk_muxes[i]->reg = clk_base +
>> + (u64)clkc_data->clk_muxes[i]->reg;
>> +
>> + /* Populate base address for dividers */
>> + for (i = 0; i < clkc_data->clk_dividers_count; i++)
>> + clkc_data->clk_dividers[i]->reg = clk_base +
>> + (u64)clkc_data->clk_dividers[i]->reg;
>> +
>> + /*
>> + * register all clks
>> + */
>
> Yes, that's obvious..
>
will drop at next version
>> + for (clkid = 0; clkid < clkc_data->hw_onecell_data->num; clkid++) {
>> + /* array might be sparse */
>> + if (!clkc_data->hw_onecell_data->hws[clkid])
>> + continue;
>> +
>> + ret = devm_clk_hw_register(dev,
>> + clkc_data->hw_onecell_data->hws[clkid]);
>> + if (ret)
>> + goto iounmap;
>> + }
>> +
>> + return of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
>> + clkc_data->hw_onecell_data);
>> +
>> +iounmap:
>> + iounmap(clk_base);
can also drop this once convert to devm_ API
>> + return ret;
>> +}
>> +
>> +static struct platform_driver axg_driver = {
>> + .probe = axg_clkc_probe,
>> + .driver = {
>> + .name = "axg-clkc",
>> + .of_match_table = clkc_match_table,
>> + },
>> +};
>> +
>> +builtin_platform_driver(axg_driver);
>> diff --git a/include/dt-bindings/clock/axg-clkc.h b/include/dt-bindings/clock/axg-clkc.h
>> new file mode 100644
>> index 000000000000..d2c0f49ba0df
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/axg-clkc.h
>> @@ -0,0 +1,72 @@
>> +/*
>> + * Meson-AXG clock tree IDs
>> + *
>> + * Copyright (c) 2017 Amlogic, Inc. All rights reserved.
>> + *
>> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
> There's a standard way to add these it seems. They should be the
> first line in the file and look like
>
> /* SPDX-License-Identifier: */
>
> for header files and
>
> // SPDX-License-Identifier:
>
> for C files.
>
thanks for the suggestion, will update at next version
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: meson-axg: add clock DT info for Meson AXG SoC
From: Yixun Lan @ 2017-11-30 6:01 UTC (permalink / raw)
To: Stephen Boyd
Cc: yixun.lan, Neil Armstrong, Jerome Brunet, Kevin Hilman,
Rob Herring, Mark Rutland, Michael Turquette, Carlo Caione,
Qiufang Dai, linux-amlogic, devicetree, linux-clk,
linux-arm-kernel, linux-kernel
In-Reply-To: <20171129193536.GB19419@codeaurora.org>
Hi Stephen
On 11/30/17 03:35, Stephen Boyd wrote:
> On 11/28, Yixun Lan wrote:
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index b932a784b02a..36a2e98338a8 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -7,6 +7,7 @@
>> #include <dt-bindings/gpio/gpio.h>
>> #include <dt-bindings/interrupt-controller/irq.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/clock/axg-clkc.h>
>>
>> / {
>> compatible = "amlogic,meson-axg";
>> @@ -148,6 +149,20 @@
>> #address-cells = <0>;
>> };
>>
>> + hiubus: hiubus@ff63c000 {
>
> Maybe just call the node "bus@ff63c000"?
>
isn't this just a name? what's the benefits to change?
personally, I tend to keep it this way, because it's better map to the
data sheet
we also has 'aobus', 'cbus' scattered there..
>> + compatible = "simple-bus";
>> + reg = <0x0 0xff63c000 0x0 0x1c00>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x0 0x0 0x0 0xff63c000 0x0 0x1c00>;
>> +
>> + clkc: clock-controller@0 {
>> + compatible = "amlogic,axg-clkc";
>> + #clock-cells = <1>;
>> + reg = <0x0 0x0 0x0 0x320>;
>> + };
>> + };
>> +
>> mailbox: mailbox@ff63dc00 {
>> compatible = "amlogic,meson-gx-mhu", "amlogic,meson-gxbb-mhu";
>> reg = <0 0xff63dc00 0 0x400>;
>> --
>> 2.15.0
>>
>
^ permalink raw reply
* Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values
From: Viresh Kumar @ 2017-11-30 6:59 UTC (permalink / raw)
To: Stephen Boyd
Cc: Ulf Hansson, Rob Herring, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Rafael Wysocki,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Vincent Guittot,
Rajendra Nayak, Sudeep Holla,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20171130005029.GC19419-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 29-11-17, 16:50, Stephen Boyd wrote:
> Sorry it still makes zero sense to me. It seems that we're trying
> to make the OPP table parsing generic just for the sake of code
> brevity.
Not just the code but bindings as well to make sure we don't add a new
property (similar to earlier ones) for every platform that wants to
use performance states.
> Is this the goal? From a DT writer perspective it seems
> confusing to say that opp-microvolt is sometimes a microvolt and
> sometimes not a microvolt.
Well it would still represent the voltage but not in microvolt units
as the platform guys decided to hide those values from kernel and
handle them directly in firmware.
> Why can't the SoC specific genpd
> driver parse something like "qcom,corner" instead out of the
> node?
Sure we can, but that means that a new property will be required for
the next platform.
I did it this way as Kevin (and Rob) suggested NOT to add another
property but use the earlier ones as we aren't passing anything new
here, just that the units of the property are different. For another
SoC, we may want to hide both freq and voltage values from kernel and
pass firmware dependent values. Should we add two new properties for
that SoC then ?
> BTW, I don't believe I have a use-case where I want to express
> power domain OPP tables.
I do remember that you once said [1] that you may want to pass the
real voltage values as well via DT. And so I thought that you can pass
performance-state (corner) in opp-hz and real voltage values in
opp-microvolt.
> I have many devices that all have
> different frequencies that are all tied into the same power
> domain. This binding makes it look like we can only have one
> frequency per domain which won't work.
No, that isn't the case. Looks like we have some confusion here. Let
me try with a simple example:
foo: foo-power-domain@09000000 {
compatible = "foo,genpd";
#power-domain-cells = <0>;
operating-points-v2 = <&domain_opp_table>;
};
cpu0: cpu@0 {
compatible = "arm,cortex-a53", "arm,armv8";
...
operating-points-v2 = <&cpu_opp_table>;
power-domains = <&foo>;
};
domain_opp_table: domain_opp_table {
compatible = "operating-points-v2";
domain_opp_1: opp00 {
opp-hz = /bits/ 64 <1>; /* These are corners AKA perf states */
};
domain_opp_2: opp01 {
opp-hz = /bits/ 64 <2>;
};
domain_opp_3: opp02 {
opp-hz = /bits/ 64 <3>;
};
};
cpu_opp_table: cpu_opp_table {
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp-hz = /bits/ 64 <208000000>;
clock-latency-ns = <500000>;
power-domain-opp = <&domain_opp_1>;
};
opp01 {
opp-hz = /bits/ 64 <432000000>;
clock-latency-ns = <500000>;
power-domain-opp = <&domain_opp_2>;
};
opp02 {
opp-hz = /bits/ 64 <729000000>;
clock-latency-ns = <500000>;
power-domain-opp = <&domain_opp_2>;
};
opp03 {
opp-hz = /bits/ 64 <960000000>;
clock-latency-ns = <500000>;
power-domain-opp = <&domain_opp_3>;
};
};
The device frequencies are still managed by device's OPP table,
just that device's OPP has OPP requirement from another device which
is power domain in this case.
> I want to express that a device with a range of frequencies (or
> really multiple ranges of frequencies) is inside certain physical
> power domains and the frequency of the clks dictates the minimum
> voltage requirement of those power domains.
>
> For the most complicated case, imagine something like our eMMC
> controller that has two clks (clk1,clk2) that it changes the rate
> of independently and those two clks rely on two different
> regulators (vreg1, vreg2) that supply voltage domains in the SoC
> which the eMMC controller happens to be part of (pd1, pd2). And
> the device is also part of another power domain that we use to
> turn everything off (pd3).
>
> +-------+ +-------+
> | vreg1 | | vreg2 |
> +---+---+ +----+--+
> | |
> | +------------+-------------+ |
> | | +-------+ | +--------+ | |
> +-----> | clk1 | | | clk2 | <---------+
> | +---+---+ | +----+---+ |
> | | | | |
> +----------v--------------v-----------+
> | | | | |
> | | | | |
> | | pd1 | pd2 | |
> | | | | |
> | +------------+-------------+ |
> | |
> | pd3 eMMC |
> +-------------------------------------+
>
>
> >From a DT perspective, I see this as one emmc node:
>
> pd: power-domain-controller {
> #power-domain-cells = <1>;
> };
>
> cc: clock-controller {
> #clock-cells = <1>;
> };
>
> emmc {
> power-domains = <&pd 1> <&pd 2>, <&pd 3>;
> clocks = <&cc 1> <&cc 2>;
> }
>
> And then we really don't want to have to express every single
> possible frequency that clk1 and clk2 can be just to express the
> voltage/corner constraints. It could be that we have some table
> like so:
>
> clk1 Hz | pd1 Corner
> ------------+-----------
> 40000 | 0
> 960000 | 0
> 19200000 | 1
> 25000000 | 1
> 50000000 | 2
> 74000000 | 3
>
> clk2 Hz | pd2 Corner
> ------------+-----------
> 19200000 | 0
> 150000000 | 1
> 340000000 | 2
>
>
> BUT we also have another device that uses pd1 and has it's own
> clk3 with different frequency constraints:
>
> clk3 Hz | pd1 Corner
> -------------+-----------
> 250000000 | 0
> 360000000 | 1
> 730000000 | 2
>
> So when clk3 is at 730000000, we don't care what frequency clk1
> is running at, pd1 needs to be at least at corner 2. If it's at
> corner 3 because clk1 is at 74000000 then that's fine.
>
> I imagine DT would look like our "fmax tables" that are currently
> out of tree. Something like:
>
> clk1_fmax_table {
> fmax0 {
> reg = /bits/ 64 <960000>;
> qcom,corner = <0>;
> };
> fmax1 {
> reg = /bits/ 64 <25000000>;
> qcom,corner = <1>;
> };
> fmax2 {
> reg = /bits/ 64 <50000000>;
> qcom,corner = <2>;
> };
> fmax3 {
> reg = /bits/ 64 <740000000>;
> qcom,corner = <3>;
> };
> };
>
> Which is similar to OPP table, but we only list the maximum
> frequency that requires a particular corner. We're back to the
> same problem we have with OPPs of figuring out how to relate a
> table to a certain clk and power domain though. At least for
> qcom, we could do that with some sort of complicated list
> property:
>
> emmc {
> performance-states = <&fmax_table &cc 1 &pd 1>
> };
>
> or something like that which would parse a table, a clock, and a
> number of power domains.
Here is how this can be represented with the current proposal.
pd: power-domain-controller {
#power-domain-cells = <1>;
operating-points-v2 = <&pd1_opp_table>, <&pd2_opp_table>, <&pd3_opp_table>;
};
/*
* The below OPP nodes can contain other properties like
* microvolt and microamps, etc.
*
* Also if the below 3 tables are exactly same, then the same
* table can be used for all the three power domains provided
* by the above controller.
*/
pd1_opp_table: pd1_opp_table {
compatible = "operating-points-v2";
pd1_opp_1: opp00 {
opp-hz = /bits/ 64 <1>; /* These are corners AKA perf states */
};
pd1_opp_2: opp01 {
opp-hz = /bits/ 64 <2>;
};
pd1_opp_3: opp02 {
opp-hz = /bits/ 64 <3>;
};
};
pd2_opp_table: pd2_opp_table {
compatible = "operating-points-v2";
pd2_opp_1: opp00 {
opp-hz = /bits/ 64 <1>; /* These are corners AKA perf states */
};
pd2_opp_2: opp01 {
opp-hz = /bits/ 64 <2>;
};
pd2_opp_3: opp02 {
opp-hz = /bits/ 64 <3>;
};
};
pd3_opp_table: pd3_opp_table {
compatible = "operating-points-v2";
pd3_opp_1: opp00 {
opp-hz = /bits/ 64 <1>; /* These are corners AKA perf states */
};
pd3_opp_2: opp01 {
opp-hz = /bits/ 64 <2>;
};
pd3_opp_3: opp02 {
opp-hz = /bits/ 64 <3>;
};
};
cc: clock-controller {
#clock-cells = <1>;
};
emmc {
power-domains = <&pd 1> <&pd 2>, <&pd 3>;
clocks = <&cc 1> <&cc 2>;
/*
* We don't allow multiple OPP tables for devices
* currently, but I think we need to use it for multiple
* clk case, like emmc in your example.
*/
operating-points-v2 = <&cc1_opp_table>, <&cc2_opp_table>;
}
cc1_opp_table: cc1_opp_table {
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp-hz = /bits/ 64 <40000>;
power-domain-opp = <&pd1_opp_1>;
};
opp01 {
opp-hz = /bits/ 64 <960000>;
power-domain-opp = <&pd1_opp_1>;
};
opp02 {
opp-hz = /bits/ 64 <19200000>;
power-domain-opp = <&pd1_opp_2>;
};
opp03 {
opp-hz = /bits/ 64 <25000000>;
power-domain-opp = <&pd1_opp_2>;
};
opp04 {
opp-hz = /bits/ 64 <50000000>;
power-domain-opp = <&pd1_opp_3>;
};
opp05 {
opp-hz = /bits/ 64 <74000000>;
power-domain-opp = <&pd1_opp_3>;
};
};
cc2_opp_table: cc2_opp_table {
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp-hz = /bits/ 64 <19200000>;
power-domain-opp = <&pd2_opp_1>;
};
opp01 {
opp-hz = /bits/ 64 <150000000>;
power-domain-opp = <&pd2_opp_2>;
};
opp02 {
opp-hz = /bits/ 64 <340000000>;
power-domain-opp = <&pd2_opp_3>;
};
};
Other devices can too have their OPP tables containing phandles to the
pd1/2/3 OPPs.
Wouldn't this work well ?
> Reminds me, we can have one clk frequency map to multiple power
> domains too. We have this case for our CPUs and PLLs where we
> have individual power control on two domains for one frequency.
> So when the PLL frequency changes, we need to turn on and set the
> voltage or corner of two regulators.
Sure, in that case the above "power-domain-opp" can contain a list.
This is the multiple-power-domain case we have discussed multiple
times earlier.
> So I don't really know how this is all going to work.
I am still hopeful :)
> I'd really
> appreciate to see the full picture though. Reviewing this a bit
> at a time makes me lose sight of the bigger picture.
I was about to publish code based on these bindings today, but then I
received last minute comments from you and Rob and that work is going
to wait a bit more :)
--
viresh
[1] https://marc.info/?l=linux-kernel&m=147995301320486&w=2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 7/8] netdev: octeon-ethernet: Add Cavium Octeon III support.
From: Souptick Joarder @ 2017-11-30 7:12 UTC (permalink / raw)
To: David Daney
Cc: David Daney, linux-mips, ralf, James Hogan, netdev,
David S. Miller, Rob Herring, Mark Rutland, devel,
Greg Kroah-Hartman, linux-kernel, Steven J. Hill, devicetree,
Andrew Lunn, Florian Fainelli, Carlos Munoz
In-Reply-To: <cef2bbe0-cb06-6938-f665-9840eb67172d@caviumnetworks.com>
Hi David, Dan,
On Thu, Nov 30, 2017 at 12:50 AM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 11/29/2017 08:07 AM, Souptick Joarder wrote:
>>
>> On Wed, Nov 29, 2017 at 4:00 PM, Souptick Joarder <jrdr.linux@gmail.com>
>> wrote:
>>>
>>> On Wed, Nov 29, 2017 at 6:25 AM, David Daney <david.daney@cavium.com>
>>> wrote:
>>>>
>>>> From: Carlos Munoz <cmunoz@cavium.com>
>>>>
>>>> The Cavium OCTEON cn78xx and cn73xx SoCs have network packet I/O
>>>> hardware that is significantly different from previous generations of
>>>> the family.
>>
>>
>>>> diff --git a/drivers/net/ethernet/cavium/octeon/octeon3-bgx-port.c
>>>> b/drivers/net/ethernet/cavium/octeon/octeon3-bgx-port.c
>>>> new file mode 100644
>>>> index 000000000000..4dad35fa4270
>>>> --- /dev/null
>>>> +++ b/drivers/net/ethernet/cavium/octeon/octeon3-bgx-port.c
>>>> @@ -0,0 +1,2033 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/* Copyright (c) 2017 Cavium, Inc.
>>>> + *
>>>> + * This file is subject to the terms and conditions of the GNU General
>>>> Public
>>>> + * License. See the file "COPYING" in the main directory of this
>>>> archive
>>>> + * for more details.
>>>> + */
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/netdevice.h>
>>>> +#include <linux/etherdevice.h>
>>>> +#include <linux/of_platform.h>
>>>> +#include <linux/of_address.h>
>>>> +#include <linux/of_mdio.h>
>>>> +#include <linux/of_net.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/slab.h>
>>>> +#include <linux/list.h>
>>>> +
>>
>>
>>>> +static void bgx_port_sgmii_set_link_down(struct bgx_port_priv *priv)
>>>> +{
>>>> + u64 data;
>>
>>
>>>> + data = oct_csr_read(BGX_GMP_PCS_MISC_CTL(priv->node, priv->bgx,
>>>> priv->index));
>>>> + data |= BIT(11);
>>>> + oct_csr_write(data, BGX_GMP_PCS_MISC_CTL(priv->node, priv->bgx,
>>>> priv->index));
>>>> + data = oct_csr_read(BGX_GMP_PCS_MISC_CTL(priv->node, priv->bgx,
>>>> priv->index));
>>>
>>>
>>> Any particular reason to read immediately after write ?
>>
>>
>
> Yes, to ensure the write is committed to hardware before the next step.
>
>>
>>
>>>> +static int bgx_port_sgmii_set_link_speed(struct bgx_port_priv *priv,
>>>> struct port_status status)
>>>> +{
>>>> + u64 data;
>>>> + u64 prtx;
>>>> + u64 miscx;
>>>> + int timeout;
>>>> +
>>
>>
>>>> +
>>>> + switch (status.speed) {
>>>> + case 10:
>>>
>>>
>>> In my opinion, instead of hard coding the value, is it fine to use ENUM ?
>>
>> Similar comments applicable in other places where hard coded values
>> are used.
>>
>
> There is nothing to be gained by interposing an extra layer of abstraction
> in this case. The code is more clear with the raw numbers in this
> particular case.
As mentioned by Andrew, macros defined in uapi/linux/ethtool.h may
be useful here.
Otherwise it's fine to me :)
>
>
>>
>>
>>>> +static int bgx_port_gser_27882(struct bgx_port_priv *priv)
>>>> +{
>>>> + u64 data;
>>>> + u64 addr;
>>>
>>>
>>>> + int timeout = 200;
>>>> +
>>>> + // timeout = 200;
>>
>> Better to initialize the timeout value
>
>
> What are you talking about? It is properly initialized using valid C code.
I mean, instead of writing
int timeout;
timeout = 200;
write,
int timeout = 200;
Anyway both are correct and there is nothing wrong in your code.
Please ignore my comment here.
>
>
>>
>>
>>>> +static int bgx_port_qlm_rx_equalization(struct bgx_port_priv *priv, int
>>>> qlm, int lane)
>>>> +{
>>>> + lmode = oct_csr_read(GSER_LANE_MODE(priv->node, qlm));
>>>> + lmode &= 0xf;
>>>> + addr = GSER_LANE_P_MODE_1(priv->node, qlm, lmode);
>>>> + data = oct_csr_read(addr);
>>>> + /* Don't complete rx equalization if in VMA manual mode */
>>>> + if (data & BIT(14))
>>>> + return 0;
>>>> +
>>>> + /* Apply rx equalization for speed > 6250 */
>>>> + if (bgx_port_get_qlm_speed(priv, qlm) < 6250)
>>>> + return 0;
>>>> +
>>>> + /* Wait until rx data is valid (CDRLOCK) */
>>>> + timeout = 500;
>>>
>>>
>>> 500 us is the min required value or it can be further reduced ?
>>
>>
>
>
> 500 uS works well and is shorter than the 2000 uS from the hardware manual.
>
> If you would like to verify shorter timeout values, we could consider
> merging such a patch. But really, this doesn't matter as it is a very short
> one-off action when the link is brought up.
Ok.
>
>>
>>>> +static int bgx_port_init_xaui_link(struct bgx_port_priv *priv)
>>>> +{
>>
>>
>>>> +
>>>> + if (use_ber) {
>>>> + timeout = 10000;
>>>> + do {
>>>> + data =
>>>> +
>>>> oct_csr_read(BGX_SPU_BR_STATUS1(priv->node, priv->bgx, priv->index));
>>>> + if (data & BIT(0))
>>>> + break;
>>>> + timeout--;
>>>> + udelay(1);
>>>> + } while (timeout);
>>>
>>>
>>> In my opinion, it's better to implement similar kind of loops inside
>>> macros.
>
>
> Ok, duly noted. I think we are in disagreement with respect to this point.
As similar type loops are implemented in many places, so I suggested
to implement those in macros
in header file and include it here.
Anyway if you don't agree with me, I am fine with it :)
>
>
>>>
>>>> + if (!timeout) {
>>>> + pr_debug("BGX%d:%d:%d: BLK_LOCK
>>>> timeout\n",
>>>> + priv->bgx, priv->index,
>>>> priv->node);
>>>> + return -1;
>>>> + }
>>>> + } else {
>>>> + timeout = 10000;
>>>> + do {
>>>> + data =
>>>> +
>>>> oct_csr_read(BGX_SPU_BX_STATUS(priv->node, priv->bgx, priv->index));
>>>> + if (data & BIT(12))
>>>> + break;
>>>> + timeout--;
>>>> + udelay(1);
>>>> + } while (timeout);
>>>
>>> same here
>
>
^ permalink raw reply
* Re: [PATCH 0/5] PCI: Add support to the Cadence PCIe controller
From: Kishon Vijay Abraham I @ 2017-11-30 7:13 UTC (permalink / raw)
To: Lorenzo Pieralisi, Cyrille Pitchen
Cc: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
adouglas-vna1KIf7WgpBDgjK7y7TUQ, stelford-vna1KIf7WgpBDgjK7y7TUQ,
dgary-vna1KIf7WgpBDgjK7y7TUQ, kgopi-vna1KIf7WgpBDgjK7y7TUQ,
eandrews-vna1KIf7WgpBDgjK7y7TUQ,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
sureshp-vna1KIf7WgpBDgjK7y7TUQ, nsekhar-l0cyMroinI0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171128155039.GA17154@red-moon>
Hi,
On Tuesday 28 November 2017 09:20 PM, Lorenzo Pieralisi wrote:
> On Thu, Nov 23, 2017 at 04:01:45PM +0100, Cyrille Pitchen wrote:
>> Hi all,
>>
>> this series of patches adds support to the Cadence PCIe controller.
>> It was tested on a ARM64 platform emulated by a Palladium running both
>> linux-next (next-20171123) and pci-next kernels.
>>
>> The host mode was tested with some PCIe devices connected to the Palladium
>> through a speed-bridge. Some of those devices were a USB host controller
>> and a SATA controller. The PCIe host controller was also tested with a
>> second controller configured in endpoint mode and connected back to back
>> to the first controller.
>>
>> The EndPoint Controller (EPC) driver of this series was tested with the
>> pci-epf-test.c EndPoint Function (EPF) driver and the pcitest userspace
>> program.
>>
>> For linux-next, I applied this series on top of Kishon's patch
>> ("PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent")
>> otherwise dma_alloc_coherent() fails when called by pci_epf_alloc_space().
>>
>> Also, I patched drivers/Makefile rather than drivers/pci/Makefile to make
>> the drivers/pci/cadence/pcie-cadence-ep.o linked after
The reason to patch drivers/Makefile should be because pcie-cadence-ep has to
be compiled even when CONFIG_PCI is not enabled. CONFIG_PCI enables host
specific features and ENDPOINT shouldn't depend on CONFIG_PCI.
>> drivers/pci/endpoint/*.o objects, otherwise the built-in pci-cadence-ep
>> driver would be probed before the PCI endpoint framework would have been
>> initialized, which results in a kernel crash.
>
> Nice :( - isn't there a way to improve this (ie probe deferral or
> registering the EPF bus earlier) ?
>
>> I guess this is the reason why the "pci/dwc" line was also put in
>> drivers/Makefile, right after the "pci/endpoint" line.
>
> Or probably the other way around - see commit 5e8cb4033807
>
> @Kishon, thoughts ?
Lorenzo, ordering Makefile is one way to initialize EP core before other
drivers. the other way is to have PCI EP core have a different initcall level..
subsys_initcall??
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [v2,01/12] hwrng: bcm2835 - Obtain base register via resource
From: Herbert Xu @ 2017-11-30 7:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Matt Mackall, Rob Herring, Mark Rutland, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Eric Anholt, Stefan Wahren, PrasannaKumar Muralidharan,
Russell King, Krzysztof Kozlowski, Harald Freudenberger,
Sean Wang, Martin Kaiser, Steffen Trumtrar,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE
In-Reply-To: <ac49deb2-6f81-1daf-596d-16fd6bd6af32@gmail.com>
On Wed, Nov 29, 2017 at 09:38:52AM -0800, Florian Fainelli wrote:
>
> Hu, okay, I actually had a v3 prepared that I was going to post
> addressing some of the comments. Should I send an incremental set of
> changes now?
Please send it as an incremental set.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/2] dt-binding: can: mcp2517fd: document device tree bindings
From: kernel @ 2017-11-30 7:24 UTC (permalink / raw)
To: Patrick Menschel; +Cc: linux-can, devicetree
In-Reply-To: <0a7e4416-332a-5c23-bda3-8c7561410314@posteo.de>
Hi Patrick!
> On 29.11.2017, at 21:35, Patrick Menschel <menschel.p@posteo.de> wrote:
>
> Hello Martin,
>
>
> I didn't catch the whole discussion but you may want to check
>
> include/dt-bindings/gpio/gpio.h
>
>> #define GPIO_OPEN_DRAIN (GPIO_SINGLE_ENDED | GPIO_ACTIVE_LOW)
>
> This corresponds to
>
> Documentation/devicetree/bindings/gpio/gpio.txt
I understand, but the question still is: how to
present the information in a valid way.
To use gpio propperly it would require that the driver
implements a “sub-driver” pinctrl with all the extra
(boilerplate) code overhead.
Also this would mean mixing different types of
logical drivers into a single source - I doubt that
would be easy to get accepted...
Here again a summary of all the GPIOs that the mcp2517fd has:
* TXCAN: dedicated GPIO with single function,
individually conigurable as push/pull or open drain
* INT: main interrupt line - configurable as push/pull or
individually conigurable as push/pull or open drain
* GPIO0: general GPIO with in/out option, but 2 special “cases”:
tx-irq and TX-disable
group configurable as push/pull or open drain
* GPIO1: general GPIO with in/out potion, but 1 special “cases”:
rx-irq
group configurable as push/pull or open drain
* CLKO/SOF: clock output at (1/10th, 1/5th, 1/2, 1 of the
core frequency) or start of frame output
possibly group configurable as push/pull or open drain
(not explicitly specified in datasheet)
How would you try to present that HW-configuration in the
device tree instead?
How would it impact the driver design?
Thanks,
Martin
^ permalink raw reply
* Re: [PATCH v2 1/2] ARM: dts: exynos: Switch to dedicated Odroid-XU3 sound card binding
From: Marek Szyprowski @ 2017-11-30 7:30 UTC (permalink / raw)
To: Krzysztof Kozlowski, Sylwester Nawrocki
Cc: kgene-DgEjT+Ai2ygdnm+yROfE0A, mihailescu2m-Re5JQEeQqe8AvxtiuMwx3w,
Bartłomiej Żołnierkiewicz,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAJKOXPegJsQPrbDH8mXBhypOBnT9+Nn1T6NF=Cav=PV+9b-2MA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Krzysztof,
On 2017-11-29 18:55, Krzysztof Kozlowski wrote:
> On Mon, Nov 27, 2017 at 7:12 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Fri, Nov 03, 2017 at 05:54:45PM +0100, Sylwester Nawrocki wrote:
>>> The new sound card DT binding is used for Odroid XU3 in order
>>> to properly support the HDMI audio path.
>>> Clocks configuration is changed so the I2S controller is now the bit
>>> and the frame clock master with EPLL as the root clock source.
>>>
>>> Signed-off-by: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>> ---
>>> arch/arm/boot/dts/exynos4.dtsi | 1 +
>>> arch/arm/boot/dts/exynos5420.dtsi | 1 +
>>> arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi | 60 ++++++++++++++---------
>>> 3 files changed, 40 insertions(+), 22 deletions(-)
>>>
>
> Unfortunately this patch causes the audio card to disappear on Odroid
> XU3. "aplay -L" shows nothing and obviously speaker-test fails.
>
> Applied on v4.15-rc1... any dependencies are missing?
>
> Full boot-logs are here:
> http://www.krzk.eu/#/builders/1/builds/976
> (test exits on aplay -L).
>
> Should this be dropped?
Please add CONFIG_SND_SOC_ODROID=y to you .config. Probably exynos_defconfig
and multi_v7_defconfig should be updated too.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/2] ARM: dts: exynos: Switch to dedicated Odroid-XU3 sound card binding
From: Krzysztof Kozlowski @ 2017-11-30 7:51 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Sylwester Nawrocki, kgene-DgEjT+Ai2ygdnm+yROfE0A,
mihailescu2m-Re5JQEeQqe8AvxtiuMwx3w,
Bartłomiej Żołnierkiewicz,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <46152007-e599-23eb-6a07-cc5f3ff32c70-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Thu, Nov 30, 2017 at 8:30 AM, Marek Szyprowski
<m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi Krzysztof,
>
> On 2017-11-29 18:55, Krzysztof Kozlowski wrote:
>>
>> On Mon, Nov 27, 2017 at 7:12 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> wrote:
>>>
>>> On Fri, Nov 03, 2017 at 05:54:45PM +0100, Sylwester Nawrocki wrote:
>>>>
>>>> The new sound card DT binding is used for Odroid XU3 in order
>>>> to properly support the HDMI audio path.
>>>> Clocks configuration is changed so the I2S controller is now the bit
>>>> and the frame clock master with EPLL as the root clock source.
>>>>
>>>> Signed-off-by: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>> ---
>>>> arch/arm/boot/dts/exynos4.dtsi | 1 +
>>>> arch/arm/boot/dts/exynos5420.dtsi | 1 +
>>>> arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi | 60
>>>> ++++++++++++++---------
>>>> 3 files changed, 40 insertions(+), 22 deletions(-)
>>>>
>>
>> Unfortunately this patch causes the audio card to disappear on Odroid
>> XU3. "aplay -L" shows nothing and obviously speaker-test fails.
>>
>> Applied on v4.15-rc1... any dependencies are missing?
>>
>> Full boot-logs are here:
>> http://www.krzk.eu/#/builders/1/builds/976
>> (test exits on aplay -L).
>>
>> Should this be dropped?
>
>
> Please add CONFIG_SND_SOC_ODROID=y to you .config. Probably exynos_defconfig
> and multi_v7_defconfig should be updated too.
That would explain it. Can you send a patch for both of configs?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] dt-bindings: Remove leading 0x from bindings notation
From: Mathieu Malaterre @ 2017-11-30 7:52 UTC (permalink / raw)
To: David Daney
Cc: Rob Herring, linux-kernel, devicetree, Marco Franchi, linux-mips
In-Reply-To: <c7200904-f016-8789-ee5e-fe5a281be215@caviumnetworks.com>
[-- Attachment #1: Type: text/plain, Size: 7242 bytes --]
Hi David,
On Thu, Nov 30, 2017 at 12:21 AM, David Daney <ddaney@caviumnetworks.com>
wrote:
>
> On 11/29/2017 12:55 PM, Mathieu Malaterre wrote:
>>
>> Improve the binding example by removing all the leading 0x to fix the
>> following dtc warnings:
>>
>> Warning (unit_address_format): Node /XXX unit name should not have
leading "0x"
>
>
> How does it fix the warnings? You are not changing the .dts files that
are compiled.
I originally only wanted to fix [...]watchdog/ingenic,jz4740-wdt.txt, but
when I lookup git log, I eventually found out about the commit I refer to
in my commit message: https://github.com/torvalds/linux/commit/48c926cd3414
and I simply followed suggestion from Rob:
https://lkml.org/lkml/2017/11/1/965
> This may also cause the binding documentation to differ from the reality
of what the actual device trees contain.
Chicken or the egg dilemma, but you understand that linux master tree still
has the original warning:
$ perl -p -i -e 's/\@0+([0-9a-f])/\@$1/g' `find ./ -type f \( -iname
\*.dtsi -o -iname \*.dts \)`
$ git diff | diffstat
[...]
40 files changed, 160 insertions(+), 160 deletions(-)
And those are real W=1 actual warnings. Do you want me to re-submit it as
patch series instead which fix both the documentation side and the dts*
files ?
>>
>> Converted using the following command:
>>
>> find Documentation/devicetree/bindings -name "*.txt" -exec sed -i -e
's/([^ ])\@0x([0-9a-f])/$1\@$2/g' {} +
>>
>> This is a follow up to commit 48c926cd3414
>>
>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>> ---
>> I've also checked using the original perl command that I did not
introduce:
>>
>> Warning (unit_address_format): Node /XXX unit name should not have
leading 0s
>>
>> Documentation/devicetree/bindings/arm/ccn.txt | 2 +-
>> Documentation/devicetree/bindings/arm/omap/crossbar.txt | 2 +-
>> .../devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt | 2 +-
>> Documentation/devicetree/bindings/clock/axi-clkgen.txt | 2 +-
>> .../devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt | 2 +-
>> Documentation/devicetree/bindings/clock/exynos4-clock.txt | 2 +-
>> Documentation/devicetree/bindings/clock/exynos5250-clock.txt | 2 +-
>> Documentation/devicetree/bindings/clock/exynos5410-clock.txt | 2 +-
>> Documentation/devicetree/bindings/clock/exynos5420-clock.txt | 2 +-
>> Documentation/devicetree/bindings/clock/exynos5440-clock.txt | 2 +-
>> .../devicetree/bindings/clock/ti-keystone-pllctrl.txt | 2 +-
>> Documentation/devicetree/bindings/clock/zx296702-clk.txt | 4 ++--
>> Documentation/devicetree/bindings/crypto/fsl-sec4.txt | 4 ++--
>> .../devicetree/bindings/devfreq/event/rockchip-dfi.txt | 2 +-
>> Documentation/devicetree/bindings/display/atmel,lcdc.txt | 4 ++--
>> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
>> Documentation/devicetree/bindings/dma/zxdma.txt | 2 +-
>> Documentation/devicetree/bindings/gpio/gpio-altera.txt | 2 +-
>> Documentation/devicetree/bindings/i2c/i2c-jz4780.txt | 2 +-
>> Documentation/devicetree/bindings/iio/pressure/hp03.txt | 2 +-
>> .../devicetree/bindings/input/touchscreen/bu21013.txt | 2 +-
>> .../devicetree/bindings/interrupt-controller/arm,gic.txt | 4 ++--
>> .../bindings/interrupt-controller/img,meta-intc.txt | 2 +-
>> .../bindings/interrupt-controller/img,pdc-intc.txt | 2 +-
>> .../bindings/interrupt-controller/st,spear3xx-shirq.txt | 2 +-
>> Documentation/devicetree/bindings/mailbox/altera-mailbox.txt | 6
+++---
>> .../devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.txt | 2 +-
>> Documentation/devicetree/bindings/media/exynos5-gsc.txt | 2 +-
>> Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 2 +-
>> Documentation/devicetree/bindings/media/rcar_vin.txt | 2 +-
>> Documentation/devicetree/bindings/media/samsung-fimc.txt | 2 +-
>> Documentation/devicetree/bindings/media/sh_mobile_ceu.txt | 2 +-
>> Documentation/devicetree/bindings/media/video-interfaces.txt | 10
+++++-----
>> .../devicetree/bindings/memory-controllers/ti/emif.txt | 2 +-
>> .../devicetree/bindings/mfd/ti-keystone-devctrl.txt | 2 +-
>> Documentation/devicetree/bindings/misc/brcm,kona-smc.txt | 2 +-
>> Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt | 2 +-
>> Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 2 +-
>> Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt | 4 ++--
>> Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 6
+++---
>> Documentation/devicetree/bindings/mtd/mtk-nand.txt | 2 +-
>> Documentation/devicetree/bindings/net/altera_tse.txt | 4 ++--
>> Documentation/devicetree/bindings/net/mdio.txt | 2 +-
>> Documentation/devicetree/bindings/net/socfpga-dwmac.txt | 2 +-
>> Documentation/devicetree/bindings/nios2/nios2.txt | 2 +-
>> Documentation/devicetree/bindings/pci/altera-pcie.txt | 2 +-
>> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 2 +-
>> Documentation/devicetree/bindings/pci/hisilicon-pcie.txt | 2 +-
>> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 2 +-
>> .../devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt | 2 +-
>> Documentation/devicetree/bindings/pinctrl/pinctrl-atlas7.txt | 4 ++--
>> Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt | 2 +-
>> .../devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 4 ++--
>> Documentation/devicetree/bindings/regulator/regulator.txt | 2 +-
>> Documentation/devicetree/bindings/serial/efm32-uart.txt | 2 +-
>> .../devicetree/bindings/serio/allwinner,sun4i-ps2.txt | 2 +-
>> .../devicetree/bindings/soc/ti/keystone-navigator-qmss.txt | 2 +-
>> Documentation/devicetree/bindings/sound/adi,axi-i2s.txt | 2 +-
>> Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt | 2 +-
>> Documentation/devicetree/bindings/sound/ak4613.txt | 2 +-
>> Documentation/devicetree/bindings/sound/ak4642.txt | 2 +-
>> Documentation/devicetree/bindings/sound/max98371.txt | 2 +-
>> Documentation/devicetree/bindings/sound/max9867.txt | 2 +-
>> Documentation/devicetree/bindings/sound/renesas,fsi.txt | 2 +-
>> Documentation/devicetree/bindings/sound/rockchip-spdif.txt | 2 +-
>> Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt | 8
++++----
>> Documentation/devicetree/bindings/spi/efm32-spi.txt | 2 +-
>> Documentation/devicetree/bindings/thermal/thermal.txt | 12
++++++------
>> Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 4 ++--
>> Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 2 +-
>> Documentation/devicetree/bindings/usb/ehci-st.txt | 2 +-
>> Documentation/devicetree/bindings/usb/ohci-st.txt | 2 +-
>> .../devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt | 2 +-
>> 73 files changed, 99 insertions(+), 99 deletions(-)
>>
[-- Attachment #2: Type: text/html, Size: 8916 bytes --]
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Geert Uytterhoeven @ 2017-11-30 7:52 UTC (permalink / raw)
To: Greentime Hu
Cc: Arnd Bergmann, Greentime, Linux Kernel Mailing List, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Networking, Vincent Chen, DTML, Al Viro, David Howells,
Will Deacon, Daniel Lezcano, linux-serial@vger.kernel.org,
Vincent Chen
In-Reply-To: <CAEbi=3cTkbt9i7XPXMnY1D6qtbebDW1x8sFVsgqhq-nApAx5mA@mail.gmail.com>
On Thu, Nov 30, 2017 at 6:48 AM, Greentime Hu <green.hu@gmail.com> wrote:
> 2017-11-30 4:27 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wed, Nov 29, 2017 at 3:10 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>> 2017-11-29 19:57 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Wed, Nov 29, 2017 at 12:39 PM, Greentime Hu <green.hu@gmail.com> wrote:
> I think I can use this name "CPU_V3" for all nds32 v3 compatible cpu.
> It will be implemented like this.
>
> config HWZOL
> bool "hardware zero overhead loop support"
> depends on CPU_D10 || CPU_D15
> default n
> help
> A set of Zero-Overhead Loop mechanism is provided to reduce the
> instruction fetch and execution overhead of loop-control instructions.
> It will save 3 registers($LB, $LC, $LE) for context saving if say Y.
> You don't need to save these registers if you can make sure your user
> program doesn't use these registers.
>
> If unsure, say N.
>
> config CPU_CACHE_NONALIASING
> bool "Non-aliasing cache"
> depends on !CPU_N10 && !CPU_D10
> default n
> help
> If this CPU is using VIPT data cache and its cache way size is larger
> than page size, say N. If it is using PIPT data cache, say Y.
>
> If unsure, say N.
I still think it will be easier to revert the logic, and have
CPU_CACHE_ALIASING.
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH] dt-bindings: Remove leading 0x from bindings notation
From: Mathieu Malaterre @ 2017-11-30 7:57 UTC (permalink / raw)
To: David Daney
Cc: Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marco Franchi,
linux-mips-6z/3iImG2C8G8FEW9MqTrA
In-Reply-To: <c7200904-f016-8789-ee5e-fe5a281be215-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Hi David,
On Thu, Nov 30, 2017 at 12:21 AM, David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> wrote:
> On 11/29/2017 12:55 PM, Mathieu Malaterre wrote:
>>
>> Improve the binding example by removing all the leading 0x to fix the
>> following dtc warnings:
>>
>> Warning (unit_address_format): Node /XXX unit name should not have leading
>> "0x"
>
>
> How does it fix the warnings? You are not changing the .dts files that are
> compiled.
I originally only wanted to fix [...]watchdog/ingenic,jz4740-wdt.txt,
but when I lookup git log, I eventually found out about the commit I
refer to in my commit message:
https://github.com/torvalds/linux/commit/48c926cd3414
and I simply followed suggestion from Rob:
https://lkml.org/lkml/2017/11/1/965
> This may also cause the binding documentation to differ from the reality of
> what the actual device trees contain.
Chicken or the egg dilemma, but you understand that linux master tree
still has the original warning:
$ perl -p -i -e 's/\@0+([0-9a-f])/\@$1/g' `find ./ -type f \( -iname
\*.dtsi -o -iname \*.dts \)`
$ git diff | diffstat
[...]
40 files changed, 160 insertions(+), 160 deletions(-)
And those are real W=1 actual warnings. Do you want me to re-submit it
as patch series instead which fix both the documentation side and the
dts* files ?
>
>>
>> Converted using the following command:
>>
>> find Documentation/devicetree/bindings -name "*.txt" -exec sed -i -e
>> 's/([^ ])\@0x([0-9a-f])/$1\@$2/g' {} +
>>
>> This is a follow up to commit 48c926cd3414
>>
>> Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
>> ---
>> I've also checked using the original perl command that I did not
>> introduce:
>>
>> Warning (unit_address_format): Node /XXX unit name should not have leading
>> 0s
>>
>> Documentation/devicetree/bindings/arm/ccn.txt | 2 +-
>> Documentation/devicetree/bindings/arm/omap/crossbar.txt | 2 +-
>> .../devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt | 2 +-
>> Documentation/devicetree/bindings/clock/axi-clkgen.txt | 2 +-
>> .../devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt | 2 +-
>> Documentation/devicetree/bindings/clock/exynos4-clock.txt | 2 +-
>> Documentation/devicetree/bindings/clock/exynos5250-clock.txt | 2 +-
>> Documentation/devicetree/bindings/clock/exynos5410-clock.txt | 2 +-
>> Documentation/devicetree/bindings/clock/exynos5420-clock.txt | 2 +-
>> Documentation/devicetree/bindings/clock/exynos5440-clock.txt | 2 +-
>> .../devicetree/bindings/clock/ti-keystone-pllctrl.txt | 2 +-
>> Documentation/devicetree/bindings/clock/zx296702-clk.txt | 4 ++--
>> Documentation/devicetree/bindings/crypto/fsl-sec4.txt | 4 ++--
>> .../devicetree/bindings/devfreq/event/rockchip-dfi.txt | 2 +-
>> Documentation/devicetree/bindings/display/atmel,lcdc.txt | 4 ++--
>> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
>> Documentation/devicetree/bindings/dma/zxdma.txt | 2 +-
>> Documentation/devicetree/bindings/gpio/gpio-altera.txt | 2 +-
>> Documentation/devicetree/bindings/i2c/i2c-jz4780.txt | 2 +-
>> Documentation/devicetree/bindings/iio/pressure/hp03.txt | 2 +-
>> .../devicetree/bindings/input/touchscreen/bu21013.txt | 2 +-
>> .../devicetree/bindings/interrupt-controller/arm,gic.txt | 4 ++--
>> .../bindings/interrupt-controller/img,meta-intc.txt | 2 +-
>> .../bindings/interrupt-controller/img,pdc-intc.txt | 2 +-
>> .../bindings/interrupt-controller/st,spear3xx-shirq.txt | 2 +-
>> Documentation/devicetree/bindings/mailbox/altera-mailbox.txt | 6 +++---
>> .../devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.txt | 2 +-
>> Documentation/devicetree/bindings/media/exynos5-gsc.txt | 2 +-
>> Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 2 +-
>> Documentation/devicetree/bindings/media/rcar_vin.txt | 2 +-
>> Documentation/devicetree/bindings/media/samsung-fimc.txt | 2 +-
>> Documentation/devicetree/bindings/media/sh_mobile_ceu.txt | 2 +-
>> Documentation/devicetree/bindings/media/video-interfaces.txt | 10
>> +++++-----
>> .../devicetree/bindings/memory-controllers/ti/emif.txt | 2 +-
>> .../devicetree/bindings/mfd/ti-keystone-devctrl.txt | 2 +-
>> Documentation/devicetree/bindings/misc/brcm,kona-smc.txt | 2 +-
>> Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt | 2 +-
>> Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 2 +-
>> Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt | 4 ++--
>> Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 6 +++---
>> Documentation/devicetree/bindings/mtd/mtk-nand.txt | 2 +-
>> Documentation/devicetree/bindings/net/altera_tse.txt | 4 ++--
>> Documentation/devicetree/bindings/net/mdio.txt | 2 +-
>> Documentation/devicetree/bindings/net/socfpga-dwmac.txt | 2 +-
>> Documentation/devicetree/bindings/nios2/nios2.txt | 2 +-
>> Documentation/devicetree/bindings/pci/altera-pcie.txt | 2 +-
>> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 2 +-
>> Documentation/devicetree/bindings/pci/hisilicon-pcie.txt | 2 +-
>> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 2 +-
>> .../devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt | 2 +-
>> Documentation/devicetree/bindings/pinctrl/pinctrl-atlas7.txt | 4 ++--
>> Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt | 2 +-
>> .../devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 4 ++--
>> Documentation/devicetree/bindings/regulator/regulator.txt | 2 +-
>> Documentation/devicetree/bindings/serial/efm32-uart.txt | 2 +-
>> .../devicetree/bindings/serio/allwinner,sun4i-ps2.txt | 2 +-
>> .../devicetree/bindings/soc/ti/keystone-navigator-qmss.txt | 2 +-
>> Documentation/devicetree/bindings/sound/adi,axi-i2s.txt | 2 +-
>> Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt | 2 +-
>> Documentation/devicetree/bindings/sound/ak4613.txt | 2 +-
>> Documentation/devicetree/bindings/sound/ak4642.txt | 2 +-
>> Documentation/devicetree/bindings/sound/max98371.txt | 2 +-
>> Documentation/devicetree/bindings/sound/max9867.txt | 2 +-
>> Documentation/devicetree/bindings/sound/renesas,fsi.txt | 2 +-
>> Documentation/devicetree/bindings/sound/rockchip-spdif.txt | 2 +-
>> Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt | 8
>> ++++----
>> Documentation/devicetree/bindings/spi/efm32-spi.txt | 2 +-
>> Documentation/devicetree/bindings/thermal/thermal.txt | 12
>> ++++++------
>> Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 4 ++--
>> Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 2 +-
>> Documentation/devicetree/bindings/usb/ehci-st.txt | 2 +-
>> Documentation/devicetree/bindings/usb/ohci-st.txt | 2 +-
>> .../devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt | 2 +-
>> 73 files changed, 99 insertions(+), 99 deletions(-)
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH][v3] dt-bindings: ifc: Update endianness usage
From: Prabhakar Kushwaha @ 2017-11-30 8:06 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Prabhakar Kushwaha
IFC controller version < 2.0 support IFC register access as
big endian. These controller version also require IFC NOR signals to
be connected in reverse order with NOR flash.
IFC >= 2.0 is other way around.
So updating IFC binding to take care of both using endianness field.
Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
---
Changes for v2: updated subject
Changes for v3: fixed typo for "big-endian"
Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
index 89427b0..824a2ca 100644
--- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
@@ -18,8 +18,10 @@ Properties:
interrupt (NAND_EVTER_STAT). If there is only one,
that interrupt reports both types of event.
-- little-endian : If this property is absent, the big-endian mode will
- be in use as default for registers.
+- little-endian or big-endian : It represents how IFC registers to be accessed.
+ It also represents connection between controller and
+ NOR flash. If this property is absent, the big-endian
+ mode will be in use as default.
- ranges : Each range corresponds to a single chipselect, and covers
the entire access window as configured.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC 1/2] mailbox: ZynqMP IPI mailbox controller
From: Philippe Ombredanne @ 2017-11-30 8:15 UTC (permalink / raw)
To: Wendy Liang
Cc: jassisinghbrar, michal.simek, robh+dt, mark.rutland, LKML,
linux-arm-kernel, devicetree, Wendy Liang
In-Reply-To: <1511999947-8274-2-git-send-email-jliang@xilinx.com>
On Thu, Nov 30, 2017 at 12:59 AM, Wendy Liang <wendy.liang@xilinx.com> wrote:
> diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
> new file mode 100644
> index 0000000..229f26c
> --- /dev/null
> +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
> @@ -0,0 +1,633 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
FYI, the style Linus wants us to use is this for .c:, as a top line:
// SPDX-License-Identifier: GPL-2.0
See the threads for details on this.
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* Re: [PATCH] rtc: add mxc driver for i.MX53
From: Philippe Ombredanne @ 2017-11-30 8:18 UTC (permalink / raw)
To: Alexandre Belloni
Cc: linux-kernel-dev, Alessandro Zummo, Patrick Bruenn, Rob Herring,
Mark Rutland, open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Fabio Estevam, Juergen Borleis, Noel Vellemans,
Shawn Guo, Sascha Hauer, Russell King,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20171129221114.GV21126@piout.net>
On Wed, Nov 29, 2017 at 11:11 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> On 28/11/2017 at 08:39:27 +0100, linux-kernel-dev@beckhoff.com wrote:
>> From: Patrick Bruenn <p.bruenn@beckhoff.com>
[]
>> diff --git a/drivers/rtc/rtc-mxc_v2.c b/drivers/rtc/rtc-mxc_v2.c
>> new file mode 100644
>> index 000000000000..5049b521b38e
>> --- /dev/null
>> +++ b/drivers/rtc/rtc-mxc_v2.c
>> @@ -0,0 +1,531 @@
>
> I think SPDX identifier will soon be required on new files, please add
> one.
>
>> +/*
>> + * Copyright (C) 2004-2011 Freescale Semiconductor, Inc. All Rights Reserved.
>> + */
>> +
>> +/*
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
Exactly!
And while you are it , you could replace the boilerplate license text
with the SPDX id.
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* Re: [patch v12 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver
From: Philippe Ombredanne @ 2017-11-30 8:21 UTC (permalink / raw)
To: Kun Yi
Cc: Oleksandr Shamray, Greg Kroah-Hartman, arnd-r2nGTMty4D4,
system-sw-low-level-VPRAkNaXOzVWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA, jiri-rHqAuBHg3fBzbRFIqnYvSA,
vadimp-VPRAkNaXOzVWk0Htik3J/w, linux-api-u79uwXL29TY76Z2rM5mHXA,
OpenBMC Maillist, LKML,
openocd-devel-owner-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
mec-WqBc5aa1uDFeoWH0uzbU5w, Jiri Pirko,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
tklauser-93Khv+1bN0NyDzI6CaY1VQ, Mauro Carvalho Chehab,
David S. Miller,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAGMNF6XRwU5QEJhkg-mVwE5zpPigtcGJtRUupZHtcWRdedcsxg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Nov 29, 2017 at 11:51 PM, Kun Yi <kunyi-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, Nov 14, 2017 at 8:11 AM, Oleksandr Shamray
> <oleksandrs-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
[]
>> diff --git a/drivers/jtag/jtag-aspeed.c b/drivers/jtag/jtag-aspeed.c
>> new file mode 100644
>> index 0000000..a6e2417
>> --- /dev/null
>> +++ b/drivers/jtag/jtag-aspeed.c
>> @@ -0,0 +1,782 @@
>> +/*
>> + * drivers/jtag/aspeed-jtag.c
>> + *
>> + * Copyright (c) 2017 Mellanox Technologies. All rights reserved.
>> + * Copyright (c) 2017 Oleksandr Shamray <oleksandrs-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>> + *
>> + * Released under the GPLv2 only.
>> + * SPDX-License-Identifier: GPL-2.0
>> + */
I think the SPDX id should be on the first line as requested by Linus
and documented by Thomas (tglx) and Greg (greg-kh). And it should use
// comments, e.g:
// SPDX-License-Identifier: GPL-2.0
See the threads discussing all these.
--
Cordially
Philippe Ombredanne
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4] mfd: syscon: Add hardware spinlock support
From: Lee Jones @ 2017-11-30 8:35 UTC (permalink / raw)
To: Baolin Wang
Cc: arnd, robh+dt, mark.rutland, broonie, linux-kernel, devicetree
In-Reply-To: <2344ec4123c8b0985e54e03a0fa1bfe8d5e68235.1512009343.git.baolin.wang@linaro.org>
On Thu, 30 Nov 2017, Baolin Wang wrote:
> Some system control registers need hardware spinlock to synchronize
> between the multiple subsystems, so we should add hardware spinlock
> support for syscon.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Changes since v3:
> - Add error handling for of_hwspin_lock_get_id()
>
> Changes since v2:
> - Add acked tag from Rob.
>
> Changes since v1:
> - Remove timeout configuration.
> - Modify the binding file to add hwlocks.
> ---
> Documentation/devicetree/bindings/mfd/syscon.txt | 1 +
> drivers/mfd/syscon.c | 21 +++++++++++++++++++++
> 2 files changed, 22 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt b/Documentation/devicetree/bindings/mfd/syscon.txt
> index 8b92d45..f464cc8 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> @@ -16,6 +16,7 @@ Required properties:
> Optional property:
> - reg-io-width: the size (in bytes) of the IO accesses that should be
> performed on the device.
> +- hwlocks: reference to a phandle of a hardware spinlock provider node.
Example?
Perhaps even include the hwlock node (I'm not sure what that would
look like).
> Examples:
> gpr: iomuxc-gpr@20e0000 {
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index b93fe4c..caf6a25 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -13,6 +13,7 @@
> */
>
> #include <linux/err.h>
> +#include <linux/hwspinlock.h>
> #include <linux/io.h>
> #include <linux/module.h>
> #include <linux/list.h>
> @@ -87,6 +88,26 @@ static struct syscon *of_syscon_register(struct device_node *np)
> if (ret)
> reg_io_width = 4;
>
> + ret = of_hwspin_lock_get_id(np, 0);
> + if (ret > 0) {
> + syscon_config.hwlock_id = ret;
> + syscon_config.hwlock_mode = HWLOCK_IRQSTATE;
> + } else {
> + switch (ret) {
> + case -ENOENT:
> + /* ignore missing hwlock, it's optional */
Is your shift key broken? ;)
Please use proper grammar. Sentences start with capital letters.
> + break;
> + case 0:
> + ret = -EINVAL;
> + /* fall-through */
> + default:
> + pr_err("Failed to retrieve valid hwlock: %d\n", ret);
> + /* fall-through */
> + case -EPROBE_DEFER:
> + goto err_regmap;
> + }
> + }
> +
> syscon_config.reg_stride = reg_io_width;
> syscon_config.val_bits = reg_io_width * 8;
> syscon_config.max_register = resource_size(&res) - reg_io_width;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4] mfd: syscon: Add hardware spinlock support
From: Baolin Wang @ 2017-11-30 8:50 UTC (permalink / raw)
To: Lee Jones
Cc: Arnd Bergmann, Rob Herring, Mark Rutland, Mark Brown, LKML, DTML
In-Reply-To: <20171130083552.ynti3n3njzvps555@dell>
On 30 November 2017 at 16:35, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Thu, 30 Nov 2017, Baolin Wang wrote:
>
>> Some system control registers need hardware spinlock to synchronize
>> between the multiple subsystems, so we should add hardware spinlock
>> support for syscon.
>>
>> Signed-off-by: Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>> Changes since v3:
>> - Add error handling for of_hwspin_lock_get_id()
>>
>> Changes since v2:
>> - Add acked tag from Rob.
>>
>> Changes since v1:
>> - Remove timeout configuration.
>> - Modify the binding file to add hwlocks.
>> ---
>> Documentation/devicetree/bindings/mfd/syscon.txt | 1 +
>> drivers/mfd/syscon.c | 21 +++++++++++++++++++++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt b/Documentation/devicetree/bindings/mfd/syscon.txt
>> index 8b92d45..f464cc8 100644
>> --- a/Documentation/devicetree/bindings/mfd/syscon.txt
>> +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
>> @@ -16,6 +16,7 @@ Required properties:
>> Optional property:
>> - reg-io-width: the size (in bytes) of the IO accesses that should be
>> performed on the device.
>> +- hwlocks: reference to a phandle of a hardware spinlock provider node.
>
> Example?
>
> Perhaps even include the hwlock node (I'm not sure what that would
> look like).
Sure, I will add one example node here.
>
>> Examples:
>> gpr: iomuxc-gpr@20e0000 {
>> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
>> index b93fe4c..caf6a25 100644
>> --- a/drivers/mfd/syscon.c
>> +++ b/drivers/mfd/syscon.c
>> @@ -13,6 +13,7 @@
>> */
>>
>> #include <linux/err.h>
>> +#include <linux/hwspinlock.h>
>> #include <linux/io.h>
>> #include <linux/module.h>
>> #include <linux/list.h>
>> @@ -87,6 +88,26 @@ static struct syscon *of_syscon_register(struct device_node *np)
>> if (ret)
>> reg_io_width = 4;
>>
>> + ret = of_hwspin_lock_get_id(np, 0);
>> + if (ret > 0) {
>> + syscon_config.hwlock_id = ret;
>> + syscon_config.hwlock_mode = HWLOCK_IRQSTATE;
>> + } else {
>> + switch (ret) {
>> + case -ENOENT:
>> + /* ignore missing hwlock, it's optional */
>
> Is your shift key broken? ;)
>
> Please use proper grammar. Sentences start with capital letters.
OK. Thanks for your comments.
--
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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