* [PATCH 4/5] ARM: dts: keystone-k2l: Add PSC reset controller node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: devicetree, Russell King, linux-kernel, Rob Herring,
Philipp Zabel, Andrew Davis, linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2L SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index b58015737a35..4fa368f9ba52 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2l", "ti,keystone";
model = "Texas Instruments Keystone 2 Lamarr SoC";
@@ -216,6 +218,20 @@
};
};
+ psc: power-sleep-controller@02350000 {
+ pscrst: psc-reset-controller {
+ compatible = "ti,k2l-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 8 0xa40 8 0x840 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 1: dsp1 */
+ 0xa44 8 0xa44 8 0x844 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 2: dsp2 */
+ 0xa48 8 0xa48 8 0x848 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 3: dsp3 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio@02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: keystone-k2hk: Add PSC reset controller node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Philipp Zabel, Rob Herring, Russell King, linux-arm-kernel,
devicetree, linux-kernel, Andrew Davis, Suman Anna
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2H SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2hk.dtsi b/arch/arm/boot/dts/keystone-k2hk.dtsi
index e0780f111537..a833db72fc61 100644
--- a/arch/arm/boot/dts/keystone-k2hk.dtsi
+++ b/arch/arm/boot/dts/keystone-k2hk.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2hk", "ti,keystone";
model = "Texas Instruments Keystone 2 Kepler/Hawking SoC";
@@ -58,6 +60,24 @@
};
};
+ psc: power-sleep-controller@02350000 {
+ pscrst: psc-reset-controller {
+ compatible = "ti,k2hk-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 8 0xa40 8 0x840 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 1: dsp1 */
+ 0xa44 8 0xa44 8 0x844 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 2: dsp2 */
+ 0xa48 8 0xa48 8 0x848 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 3: dsp3 */
+ 0xa4c 8 0xa4c 8 0x84c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 4: dsp4 */
+ 0xa50 8 0xa50 8 0x850 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 5: dsp5 */
+ 0xa54 8 0xa54 8 0x854 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 6: dsp6 */
+ 0xa58 8 0xa58 8 0x858 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 7: dsp7 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio@02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: keystone: Add PSC node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: devicetree, Dave Gerlach, Russell King, linux-kernel, Rob Herring,
Philipp Zabel, Andrew Davis, linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module is responsible
for the power and clock management for each of the peripherals
present on the SoC. Represent this as a syscon node so that
multiple users can leverage it for various functionalities.
Signed-off-by: Suman Anna <s-anna@ti.com>
[afd@ti.com: add simple-mfd compatible]
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/keystone.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba2d4f4..ec203d0a673d 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -83,6 +83,11 @@
reg = <0x02310000 0x200>;
};
+ psc: power-sleep-controller@02350000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x02350000 0x1000>;
+ };
+
devctrl: device-state-control@02620000 {
compatible = "ti,keystone-devctrl", "syscon";
reg = <0x02620000 0x1000>;
--
2.10.2
^ permalink raw reply related
* [PATCH 1/5] ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Nishanth Menon, devicetree, Russell King, linux-kernel,
Rob Herring, Philipp Zabel, Andrew Davis, linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Keystone 2 family of SoCs will use various Reset Controller
drivers for managing the resets of remote processor devices like
DSPs on the SoC, so select the ARCH_HAS_RESET_CONTROLLER option
by default to enable the Reset framework.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-keystone/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 24bd64dabdfc..554357035f30 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -4,6 +4,7 @@ config ARCH_KEYSTONE
select ARM_GIC
select HAVE_ARM_ARCH_TIMER
select KEYSTONE_TIMER
+ select ARCH_HAS_RESET_CONTROLLER
select ARM_ERRATA_798181 if SMP
select COMMON_CLK_KEYSTONE
select ARCH_SUPPORTS_BIG_ENDIAN
--
2.10.2
^ permalink raw reply related
* [PATCH 0/5] Reset Controller Nodes for TI Keystone platforms
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Philipp Zabel, Rob Herring, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Davis, Suman Anna
Hi Santosh,
This patch adds the reset controller nodes and the corresponding
reset data for TI Keystone 66AK2H, 66AK2L and 66AK2E SoCs. These
resets are for the DSPs on these SoCs, and are the last dependencies
before the keystone remoteproc driver can be added.
All these SoCs will use the ti-syscon-reset driver which is already
part of mainline kernel. The bindings for the same can be found in
Documentation/devicetree/bindings/reset/ti-syscon-reset.txt file.
Note that the other Keystone 66AK2G SoC will use a different TI-SCI
based reset driver, so will be submitted separately once the TI-SCI
dependencies make it into mainline.
Patches are based on top of 4.10-rc1 plus the MSM-RAM DT node series
that you have already picked up. Patch 1 enable the Reset Framework
for Keystone platforms, and remaining patches add the required DT
nodes.
regards
Suman
Suman Anna (5):
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
ARM: dts: keystone: Add PSC node
ARM: dts: keystone-k2hk: Add PSC reset controller node
ARM: dts: keystone-k2l: Add PSC reset controller node
ARM: dts: keystone-k2e: Add PSC reset controller node
arch/arm/boot/dts/keystone-k2e.dtsi | 13 +++++++++++++
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
arch/arm/boot/dts/keystone.dtsi | 5 +++++
arch/arm/mach-keystone/Kconfig | 1 +
5 files changed, 55 insertions(+)
--
2.10.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 2/6] arm64: dts: apq8016-sbc: add support to hdmi audio via adv7533
From: Stephen Boyd @ 2017-01-09 19:39 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland, linux-arm-msm,
linux-soc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1483536902-21450-3-git-send-email-srinivas.kandagatla@linaro.org>
On 01/04, Srinivas Kandagatla wrote:
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 08bd5eb..5ab277f 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -85,6 +85,7 @@
> pinctrl-names = "default","sleep";
> pinctrl-0 = <&adv7533_int_active &adv7533_switch_active>;
> pinctrl-1 = <&adv7533_int_suspend &adv7533_switch_suspend>;
> + #sound-dai-cells = <1>;
>
> ports {
> #address-cells = <1>;
> @@ -285,6 +286,15 @@
> qcom,audio-routing =
> "AMIC2", "MIC BIAS Internal2",
> "AMIC3", "MIC BIAS External1";
> + external-dai-link@0 {
> + link-name = "ADV7533";
> + cpu { /* QUAT */
> + sound-dai = <&lpass MI2S_QUATERNARY>;
> + };
> + codec {
> + sound-dai = <&adv_bridge 0>;
> + };
> + };
>
> internal-codec-playback-dai-link@0 { /* I2S - Internal codec */
> link-name = "WCD";
The spacing is weird here. Did the internal-codec get added
without tabs before?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: 回复：Myir AM437x Rico board support (DTS) for Linux mainline 4.9 and 4.4 Ti Processor SDK 03.02.00.05
From: Tony Lindgren @ 2017-01-09 19:37 UTC (permalink / raw)
To: Sunny
Cc: Pavel Pisa, Tomi Valkeinen, devicetree, linux-arm-kernel,
Dan Murphy, linux-omap-u79uwXL29TY76Z2rM5mHXA,
support-0A6ZgDe55FJWk0Htik3J/w
In-Reply-To: <cb3b5798-e82e-4bb4-932b-1c02ece5d3e4.sunny.guo-0A6ZgDe55FJWk0Htik3J/w@public.gmane.org>
Hi,
* Sunny <sunny.guo-0A6ZgDe55FJWk0Htik3J/w@public.gmane.org> [170109 02:36]:
> Hello Pavel and Tony,
>
> This is Sunny from MYIR , and working as the software manager on RICO board. Very glad to see the great work that Pavel has done ,and sincerely appriciated to all the contributions and share.
>
> Our Linux release is not in the mailline release currently, and updates is following TI official release , may with some latency due need some time to make the update on RICO . We are planning and working on next update on RICO linux which will happen on April to Linux 4.4 or above.
>
> I will look into detail and make some testings. We will talk to you later on how we can share and help the engineers to benefit from your contribution.
Please let's coordinate the work on linux-arm-kernel and linux-omap
mailing lists to avoid duplicate work.
It seems the basic dts file is pretty much ready to go, then
it's easy to make incremental patches to that.
So maybe try to get get your engineers involved on the lists
too?
And if you want the community people to help then making
few devices available to play with might get you some extra
help.
Regards,
Tony
--
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/3] dt-bindings: gpio: Add binding documentation for gpio-thunderx
From: Linus Walleij @ 2017-01-09 19:36 UTC (permalink / raw)
To: David Daney
Cc: Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, David Daney
In-Reply-To: <1483744980-25898-2-git-send-email-ddaney.cavm@gmail.com>
On Sat, Jan 7, 2017 at 12:22 AM, David Daney <ddaney.cavm@gmail.com> wrote:
> From: David Daney <david.daney@cavium.com>
>
> Signed-off-by: David Daney <david.daney@cavium.com>
(...)
> +Optional Properties:
> +- compatible: "cavium,thunder-8890-gpio", unused as PCI driver binding is used.
> +- interrupt-controller: Marks the device node as an interrupt controller.
> +- #interrupt-cells: Must be present and have value of 2 if
> + "interrupt-controller" is present.
> + - First cell is the GPIO pin number relative to the controller.
> + - Second cell is triggering flags as defined in interrupts.txt.
AFAICT this device has an optional list of interrupts as well?
One per pin even?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/3] gpio: Add gpio driver support for ThunderX and OCTEON-TX
From: Linus Walleij @ 2017-01-09 19:35 UTC (permalink / raw)
To: David Daney
Cc: Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Daney,
Marc Zyngier
In-Reply-To: <1483744980-25898-3-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, Jan 7, 2017 at 12:22 AM, David Daney <ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>
> Cavium ThunderX and OCTEON-TX are arm64 based SoCs. Add driver for
> the on-chip GPIO pins.
>
> Signed-off-by: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
(...)
> +config GPIO_THUNDERX
> + tristate "Cavium ThunderX/OCTEON-TX GPIO"
Do you really load this as module? OK then...
> +#include <linux/gpio.h>
No.
#include <linux/gpio/driver.h>
Nothing else.
> +#define GLITCH_FILTER_400NS ((4ull << GPIO_BIT_CFG_FIL_SEL_SHIFT) | \
> + (9ull << GPIO_BIT_CFG_FIL_CNT_SHIFT))
> +
> +static unsigned int bit_cfg_reg(unsigned int line)
> +{
> + return 8 * line + GPIO_BIT_CFG;
> +}
> +
> +static unsigned int intr_reg(unsigned int line)
> +{
> + return 8 * line + GPIO_INTR;
> +}
This looks a bit overzealous, but OK.
> +struct thunderx_gpio;
> +
> +struct thunderx_irqdev {
> + struct thunderx_gpio *gpio;
> + char *name;
> + unsigned int line;
> +};
> +
> +struct thunderx_gpio {
> + struct gpio_chip chip;
> + u8 __iomem *register_base;
> + struct msix_entry *msix_entries;
> + struct thunderx_irqdev *irqdev_entries;
> + raw_spinlock_t lock;
> + unsigned long invert_mask[2];
> + unsigned long od_mask[2];
> + int base_msi;
> +};
Why can't you just move the thunderx_irqdev fields
into thunderx_gpio? It will save very little memory for
non-irq systems, I do not think footprint warrants it.
> +
> +static bool thunderx_gpio_is_gpio(struct thunderx_gpio *gpio,
> + unsigned int line)
> +{
> + u64 bit_cfg = readq(gpio->register_base + bit_cfg_reg(line));
> + bool rv = (bit_cfg & GPIO_BIT_CFG_PIN_SEL_MASK) == 0;
> +
> + WARN_RATELIMIT(!rv, "Pin %d not available for GPIO\n", line);
> +
> + return rv;
> +}
Nifty. So this actually has a pin controller back-end?
I haven't seen the code for that yet, I think.
This seems like a cheap version of
/* External interface to pin control */
extern int pinctrl_request_gpio(unsigned gpio);
extern void pinctrl_free_gpio(unsigned gpio);
extern int pinctrl_gpio_direction_input(unsigned gpio);
extern int pinctrl_gpio_direction_output(unsigned gpio);
>From <linux/pinctrl/consumer.h>
So are you planning pin control support separately in drivers/pinctrl/*
in the future? Maybe some comment to replace this with proper pin control
in the future is warranted?
> +static int thunderx_gpio_dir_in(struct gpio_chip *chip, unsigned int line)
> +{
> + struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
1. Please use gpiochip_get_data() instead of the container_of() construction,
utilized devm_gpiochip_add_data() in your probe() call.
2. Do not call this local variable "gpio" that is superconfusing, at least call
it txgpio or something.
1 & 2 applies EVERYWHERE in thid driver.
> +static void thunderx_gpio_set(struct gpio_chip *chip, unsigned int line,
> + int value)
> +{
> + struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
> + int bank = line / 64;
> + int bank_bit = line % 64;
> +
> + void __iomem *reg = gpio->register_base +
> + (bank * GPIO_2ND_BANK) + (value ? GPIO_TX_SET : GPIO_TX_CLR);
> +
> + writeq(1ull << bank_bit, reg);
Use this:
#include <linus/bitops.h>
writeq(BIT(bank_bit), reg);
Applies EVERYWHERE you use (1ULL << n)
> +static int thunderx_gpio_set_single_ended(struct gpio_chip *chip,
> + unsigned int line,
> + enum single_ended_mode mode)
Thanks for implementing this properly.
> + read_bits >>= bank_bit;
> +
> + if (test_bit(line, gpio->invert_mask))
> + return !(read_bits & 1);
> + else
> + return read_bits & 1;
This looks superconvoluted.
Can't you just:
if (test_bit(line, gpio->invert_mask))
return !(read_bits & BIT(bank_bit));
else
return !!(read_bits & BIT(bank_bit));
OK maybe not much clearer but seems clearer to me.
> +static int thunderx_gpio_irq_request_resources(struct irq_data *data)
> +{
> + struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
> + struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
> + unsigned int line = data->hwirq;
> + struct thunderx_irqdev *irqdev;
> + int err;
> +
> + if (!thunderx_gpio_is_gpio(gpio, line))
> + return -EIO;
> +
> + irqdev = gpio->irqdev_entries + line;
> +
> + irqdev->gpio = gpio;
> + irqdev->line = line;
> + irqdev->name = devm_kasprintf(chip->parent, GFP_KERNEL,
> + "gpio-%d", line + chip->base);
> +
> + writeq(GPIO_INTR_ENA_W1C, gpio->register_base + intr_reg(line));
> +
> + err = devm_request_irq(chip->parent, gpio->msix_entries[line].vector,
> + thunderx_gpio_chain_handler, IRQF_NO_THREAD, irqdev->name, irqdev);
> + return err;
> +}
> +
> +static void thunderx_gpio_irq_release_resources(struct irq_data *data)
> +{
> + struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
> + struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
> + unsigned int line = data->hwirq;
> + struct thunderx_irqdev *irqdev;
> +
> + irqdev = gpio->irqdev_entries + line;
> +
> + /*
> + * The request_resources/release_resources functions may be
> + * called multiple times in the lifitime of the driver, so we
> + * need to clean up the devm_* things to avoid a resource
> + * leak.
> + */
> + devm_free_irq(chip->parent, gpio->msix_entries[line].vector, irqdev);
> +
> + writeq(GPIO_INTR_ENA_W1C, gpio->register_base + intr_reg(line));
> +
> + devm_kfree(chip->parent, irqdev->name);
> +}
Then just do not use the devm* variants. Explicitly allocate and free instead.
These callbacks should be called on all resources anyways.
> +static void thunderx_gpio_irq_unmask(struct irq_data *data)
> +{
> + struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
> + struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
> + unsigned int line = data->hwirq;
> +
> + writeq(GPIO_INTR_ENA_W1S, gpio->register_base + intr_reg(line));
> +}
> +
> +static int thunderx_gpio_irq_set_type(struct irq_data *data,
> + unsigned int flow_type)
> +{
> + struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
> + struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
> + unsigned int line = data->hwirq;
> + u64 bit_cfg;
> +
> + irqd_set_trigger_type(data, flow_type);
> +
> + bit_cfg = GLITCH_FILTER_400NS | GPIO_BIT_CFG_INT_EN;
> +
> + if (flow_type & IRQ_TYPE_EDGE_BOTH) {
> + irq_set_handler_locked(data, handle_edge_irq);
> + bit_cfg |= GPIO_BIT_CFG_INT_TYPE;
> + } else {
> + irq_set_handler_locked(data, handle_level_irq);
> + }
> +
> + raw_spin_lock(&gpio->lock);
> + if (flow_type & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_LEVEL_LOW)) {
> + bit_cfg |= GPIO_BIT_CFG_PIN_XOR;
> + set_bit(line, gpio->invert_mask);
> + } else {
> + clear_bit(line, gpio->invert_mask);
> + }
> + clear_bit(line, gpio->od_mask);
> + writeq(bit_cfg, gpio->register_base + bit_cfg_reg(line));
> + raw_spin_unlock(&gpio->lock);
> +
> + return IRQ_SET_MASK_OK;
> +}
> +
> +/*
> + * Interrupts are chained from underlying MSI-X vectors. We have
> + * these irq_chip functions to be able to handle level triggering
> + * semantics and other acknowledgment tasks associated with the GPIO
> + * mechanism.
> + */
> +static struct irq_chip thunderx_gpio_irq_chip = {
> + .name = "GPIO",
> + .irq_enable = thunderx_gpio_irq_unmask,
> + .irq_disable = thunderx_gpio_irq_mask,
> + .irq_ack = thunderx_gpio_irq_ack,
> + .irq_mask = thunderx_gpio_irq_mask,
> + .irq_mask_ack = thunderx_gpio_irq_mask_ack,
> + .irq_unmask = thunderx_gpio_irq_unmask,
> + .irq_set_type = thunderx_gpio_irq_set_type,
> + .irq_request_resources = thunderx_gpio_irq_request_resources,
> + .irq_release_resources = thunderx_gpio_irq_release_resources,
> + .flags = IRQCHIP_SET_TYPE_MASKED
> +};
This looks wrong.
If you're calling devm_request_irq() on *every* *single* *irq* like you
do here, you are dealing with a hieararchical irqdomain, not a linear one,
and GPIOLIB_IRQCHIP may not be used.
Look at drivers/gpio/gpio-xgene-sb.c for inspiration. That is the only
hierarchical GPIO irqdomain I have right now.
Consult Marc Zyngier's IRQ domain lecture if you have time:
https://www.youtube.com/watch?v=YE8cRHVIM4E
If you have ideas how to combine hierarchical irqdomain and GPIOLIB_IRQCHIP
pls help out.
> + gpio->irqdev_entries = devm_kzalloc(dev,
> + sizeof(struct thunderx_irqdev) * ngpio,
> + GFP_KERNEL);
> + if (!gpio->irqdev_entries) {
> + err = -ENOMEM;
> + goto out;
> + }
I think this is overkill. Use hierarchical irqdomain.
Yours,
Linus Walleij
--
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 1/9] clk: stm32f4: Update DT bindings documentation
From: Stephen Boyd @ 2017-01-09 19:33 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Gabriel FERNANDEZ, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson@linaro.org, andrea.merello@gmail.com,
radoslaw.pietrzyk@gmail.com, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
kernel@stlinux.com
In-Reply-To: <ccd14adb-9d10-ae9e-de6d-565418421968@st.com>
On 01/09, Alexandre Torgue wrote:
> Hi Stephen,
>
> On 12/22/2016 01:10 AM, Stephen Boyd wrote:
> >On 12/13, gabriel.fernandez@st.com wrote:
> >>From: Gabriel Fernandez <gabriel.fernandez@st.com>
> >>
> >>Creation of dt include file for specific stm32f4 clocks.
> >>These specific clocks are not derived from system clock (SYSCLOCK)
> >>We should use index 1 to use these clocks in DT.
> >>e.g. <&rcc 1 CLK_LSI>
> >>
> >>Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> >>Acked-by: Rob Herring <robh@kernel.org>
> >>---
> >
> >Applied to clk-stm32f4 and merged into clk-next.
> >
>
> I'm preparing pull request branch for STM32 DT part. This patch is
> also requested to build correctly DT patches. Do you know how could
> we synchronize our pull request ?
>
clk-stm32f4 is stable and not going to be rebased, so you're good
to base patches on it and send it off to arm-soc if the arm-soc
maintainers agree to it. You can also base off an earlier part of
the branch if you only need this first patch for example.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] serial: fsl-imx-uart.txt: Remove generic property
From: Fabio Estevam @ 2017-01-09 19:30 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, Fabio Estevam
From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
'uart-has-rtscts' is a generic serial property and it is described
at Documentation/devicetree/bindings/serial/serial.txt, so remove it
from the specific fsl-imx-uart binding documentation.
While at it, add a note pointing to the serial.txt file, which
contains the complete list of generic serial bindings.
Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
---
Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
index 1e82802..574c3a2 100644
--- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
@@ -6,11 +6,13 @@ Required properties:
- interrupts : Should contain uart interrupt
Optional properties:
-- uart-has-rtscts : Indicate the uart has rts and cts
- fsl,irda-mode : Indicate the uart supports irda mode
- fsl,dte-mode : Indicate the uart works in DTE mode. The uart works
in DCE mode by default.
+Please check Documentation/devicetree/bindings/serial/serial.txt
+for the complete list of generic properties.
+
Note: Each uart controller should have an alias correctly numbered
in "aliases" node.
--
2.7.4
--
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
* [PATCH] Documentation: dt: reset: Revise typos in TI syscon reset example
From: Suman Anna @ 2017-01-09 19:28 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, linux-kernel, Andrew Davis, Rob Herring,
Santosh Shilimkar, linux-arm-kernel
Fix couple of typos in the example given in the TI syscon reset
binding. The ti,reset-bits used for DSP0 are corrected to match
the values that will be used in the actual DT node.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
Hi Philipp,
This is the Documentation part fix that goes along with
the ti-syscon-reset fix that you have on your next branch.
I will be submitting the DT nodes very soon
regards
Suman
Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
index 164c7f34c451..21ba739b162e 100644
--- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
+++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
@@ -63,7 +63,7 @@ Example:
--------
The following example demonstrates a syscon node, the reset controller node
using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
-Edison SoC.
+66AK2E SoC.
/ {
soc {
@@ -71,13 +71,13 @@ Edison SoC.
compatible = "syscon", "simple-mfd";
reg = <0x02350000 0x1000>;
- pscrst: psc-reset {
+ pscrst: psc-reset-controller {
compatible = "ti,k2e-pscrst", "ti,syscon-reset";
#reset-cells = <1>;
ti,reset-bits = <
- 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_SET|DEASSERT_CLEAR|STATUS_SET) /* 0: pcrst-dsp0 */
- 0xa40 5 0xa44 3 0 0 (ASSERT_SET|DEASSERT_CLEAR|STATUS_NONE) /* 1: pcrst-example */
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 5 0xa44 3 0 0 (ASSERT_SET | DEASSERT_CLEAR | STATUS_NONE) /* 1: example */
>;
};
};
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 1/4] usb: musb: da8xx: Use the right dma controller
From: Tony Lindgren @ 2017-01-09 19:06 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Alexandre Bailon, b-liu-l0cyMroinI0,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
david-nq/r/kbU++upp/zk7JDF2g
In-Reply-To: <5a002693-1ebf-550f-02df-b40e44f59751-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
* Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> [170109 10:55]:
> On 01/09/2017 09:43 PM, Tony Lindgren wrote:
>
> > > > da8xx driver is registering and using the cppi dma controller but actually,
> > > > the da8xx has a cppi41 dma controller.
> > > > Update the driver to register and use the cppi41 dma controller.
> > > >
> > > > Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > > > ---
> > > > drivers/usb/musb/da8xx.c | 8 ++++----
> > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
> > > > index e89708d..74dcc07 100644
> > > > --- a/drivers/usb/musb/da8xx.c
> > > > +++ b/drivers/usb/musb/da8xx.c
> > > > @@ -458,14 +458,14 @@ static inline u8 get_vbus_power(struct device *dev)
> > > > }
> > > >
> > > > static const struct musb_platform_ops da8xx_ops = {
> > > > - .quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
> > >
> > > Grr, MUSB_DMA_CPPI is certainly wrong! There's no CPPI 3.0 support for
> > > DA8xx. Where have this come from?
> > >
> > > > + .quirks = MUSB_DMA_CPPI41 | MUSB_INDEXED_EP,
> > > > .init = da8xx_musb_init,
> > > > .exit = da8xx_musb_exit,
> > > >
> > > > .fifo_mode = 2,
> > > > -#ifdef CONFIG_USB_TI_CPPI_DMA
> > > > - .dma_init = cppi_dma_controller_create,
> > > > - .dma_exit = cppi_dma_controller_destroy,
> > >
> > > Likewise, WTF?
> > > I suggest that you fix this crap in a separate commit, to be backported
> > > to -stable if needed.
> >
> > Probably came from my DMA patch 7f6283ed6fe8 ("usb: musb: Set up function
>
> Too bad I missed it back then. Then certainly this should be fixed in a
> separate patch. The first hunk was not a part of that commit, tho...
>
> > pointers for DMA"). At that point I thought da8xxx.c and davinci.c are just
> > separate attempts of the same driver.. Sorry the number of musb glue layers
> > is just too confusing.
Maybe from f8e9f34f80a2 ("usb: musb: Fix up DMA related macros")?
Sorry obviously I have no idea how the da8xx.c should be configured for DMA.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio
From: Linus Walleij @ 2017-01-09 18:55 UTC (permalink / raw)
To: Peter Rosin
Cc: Sebastian Reichel, Alexandre Courbot,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-gpio@vger.kernel.org
In-Reply-To: <c3d66181-3076-0d0f-d74e-ec0205b3f547@axentia.se>
On Mon, Jan 2, 2017 at 9:31 AM, Peter Rosin <peda@axentia.se> wrote:
> On 2016-12-30 08:49, Linus Walleij wrote:
>> On Wed, Dec 14, 2016 at 6:41 PM, Peter Rosin <peda@axentia.se> wrote:
>>> On 2016-12-14 18:01, Sebastian Reichel wrote:
>>>> [of course I forgot to actually add gpio people, let's try again]
>>>>
>>>> On Wed, Dec 14, 2016 at 05:59:21PM +0100, Sebastian Reichel wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Dec 14, 2016 at 12:56:45AM +0100, Peter Rosin wrote:
>>>>>> If several parallel bq24735 chargers have their ac-detect gpios wired
>>>>>> together (or if only one of the parallel bq24735 chargers have its
>>>>>> ac-detect pin wired to a gpio, and the others are assumed to react the
>>>>>> same), then all driver instances need to check the same gpio. But the
>>>>>> gpio subsystem does not allow sharing gpios, so handle that locally.
>>>>>
>>>>> Adding GPIO subsystem people to see if they can come up with
>>>>> something in the gpiod API for this usecase.
>>>
>>> Right, I don't like how my new code steps away from gpio descriptors.
>>
>> The issue of shared gpiods have come up over and over again.
>> For example the messy regulator code needs this too.
>>
>> It is better if we implement something like gpiod_get_shared()
>> in the gpiolib of these cases.
>>
>> Just put a refcount in struct gpio_desc in drivers/gpio/gpiolib.h
>> for this case I guess?
>
> I actually tried that, but ran into atomicy issues with the
> FLAG_REQUESTED bit and gave up. Didn't really try all that hard
> though, but I simply didn't feel comfortable with going near such
> fundamental designs...
Oh I see. Well if it is of any help that would make me nervous too.
I would just remove the use of FLAG_REQUESTED altogether,
redefine the flags in gpiolib.h from 0 and add a struct kref into the struct
to deal with the refcounting.
That should do it. I think.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/4] usb: musb: da8xx: Use the right dma controller
From: Sergei Shtylyov @ 2017-01-09 18:54 UTC (permalink / raw)
To: Tony Lindgren
Cc: Alexandre Bailon, b-liu-l0cyMroinI0,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
david-nq/r/kbU++upp/zk7JDF2g
In-Reply-To: <20170109184352.GL2630-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On 01/09/2017 09:43 PM, Tony Lindgren wrote:
>>> da8xx driver is registering and using the cppi dma controller but actually,
>>> the da8xx has a cppi41 dma controller.
>>> Update the driver to register and use the cppi41 dma controller.
>>>
>>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>> ---
>>> drivers/usb/musb/da8xx.c | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
>>> index e89708d..74dcc07 100644
>>> --- a/drivers/usb/musb/da8xx.c
>>> +++ b/drivers/usb/musb/da8xx.c
>>> @@ -458,14 +458,14 @@ static inline u8 get_vbus_power(struct device *dev)
>>> }
>>>
>>> static const struct musb_platform_ops da8xx_ops = {
>>> - .quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
>>
>> Grr, MUSB_DMA_CPPI is certainly wrong! There's no CPPI 3.0 support for
>> DA8xx. Where have this come from?
>>
>>> + .quirks = MUSB_DMA_CPPI41 | MUSB_INDEXED_EP,
>>> .init = da8xx_musb_init,
>>> .exit = da8xx_musb_exit,
>>>
>>> .fifo_mode = 2,
>>> -#ifdef CONFIG_USB_TI_CPPI_DMA
>>> - .dma_init = cppi_dma_controller_create,
>>> - .dma_exit = cppi_dma_controller_destroy,
>>
>> Likewise, WTF?
>> I suggest that you fix this crap in a separate commit, to be backported
>> to -stable if needed.
>
> Probably came from my DMA patch 7f6283ed6fe8 ("usb: musb: Set up function
Too bad I missed it back then. Then certainly this should be fixed in a
separate patch. The first hunk was not a part of that commit, tho...
> pointers for DMA"). At that point I thought da8xxx.c and davinci.c are just
> separate attempts of the same driver.. Sorry the number of musb glue layers
> is just too confusing.
:-)
> Tony
MBR, Sergei
--
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] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Doug Anderson @ 2017-01-09 18:52 UTC (permalink / raw)
To: Xing Zheng
Cc: Mark Rutland, devicetree@vger.kernel.org, Elaine Zhang,
Heiko Stübner, Catalin Marinas, Shawn Lin, Brian Norris,
Will Deacon, linux-kernel@vger.kernel.org,
open list:ARM/Rockchip SoC..., Rob Herring, David Wu, William wu,
Jianqun Xu, linux-arm-kernel@lists.infradead.org, Caesar Wang
In-Reply-To: <1483945344-3125-1-git-send-email-zhengxing@rock-chips.com>
Hi,
On Sun, Jan 8, 2017 at 11:02 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> The structure rockchip_clk_provider needs to refer the GRF regmap
> in somewhere, if the CRU node has not "rockchip,grf" property,
> calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> regmap, and the MUXGRF type clock will be not supported.
>
> Therefore, we need to add them.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v2:
> - referring pmugrf for PMUGRU
> - fix the typo "invaild" in COMMIT message
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
This looks sane to me, but before you land it you need to first send
up a (separate) patch that adjusts:
Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
...it would also be sorta nice if you included an a patch in your
series that actually uses this new functionality.
-Doug
^ permalink raw reply
* Re: [PATCH] of: remove redundant memset in overlay
From: Frank Rowand @ 2017-01-09 18:50 UTC (permalink / raw)
To: YiPing Xu, pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483787067-108430-1-git-send-email-xuyiping-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Hi Rob,
On 01/07/17 03:04, YiPing Xu wrote:
> From: XuYing <xuyiping-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
>
> memset in of_build_overlay_info is redundant, the ovinfo has been
> zeroed in of_fill_overlay_info when error.
>
> Signed-off-by: YiPing Xu <xuyiping-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
> ---
> drivers/of/overlay.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index 0d4cda7..4b1b6b3 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -314,7 +314,6 @@ static int of_build_overlay_info(struct of_overlay *ov,
>
> cnt = 0;
> for_each_child_of_node(tree, node) {
> - memset(&ovinfo[cnt], 0, sizeof(*ovinfo));
> err = of_fill_overlay_info(ov, node, &ovinfo[cnt]);
> if (err == 0)
> cnt++;
>
Reviewed-by: Frank Rowand <frank.rowand-mEdOJwZ7QcZBDgjK7y7TUQ@public.gmane.org>
I am in the midst of a cleanup of overlay.c. I can add this patch to
my series if you would prefer. And of course if I get delayed with
the series I would expect you to apply this one without my series if
you desire.
-Frank
--
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 v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-09 18:47 UTC (permalink / raw)
To: Hans Verkuil, Rick Chang
Cc: Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Rob Herring, linux-kernel, linux-media, srv_heupstream,
linux-mediatek, linux-arm-kernel, devicetree, Minghsiu Tsai,
James Liao
In-Reply-To: <c35bd06d-f012-1289-e765-02dc26b87e27@gmail.com>
On 09/01/17 19:45, Matthias Brugger wrote:
>
>
> On 09/01/17 12:29, Hans Verkuil wrote:
>> Hi Rick,
>>
>> On 01/06/2017 03:34 AM, Rick Chang wrote:
>>> Hi Hans,
>>>
>>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you
>>> have
>>> any idea about this patch series? Should we wait for [2] or we could
>>> merge
>>> the source code and dt-binding first?
>>
>> Looking at [2] I noticed that the last comment was July 4th. What is
>> the reason
>> it hasn't been merged yet?
>>
>> If I know [2] will be merged for 4.11, then I am fine with merging
>> this media
>> patch series. The dependency of this patch on [2] is something Mauro
>> can handle.
>>
>> If [2] is not merged for 4.11, then I think it is better to wait until
>> it is
>> merged.
>>
>
> I can't take [2] because there is no scpsys in the dts present. It seems
> that it got never posted.
>
> Rick can you please follow-up with James and provide a patch which adds
> a scpsys node to the mt2701.dtsi?
>
Ah I forgot, dts patches should go through my tree, so Hans please don't
merge this patch. Bindings should go through your branch though.
Thanks,
Matthias
^ permalink raw reply
* Re: [PATCH] ARM: dts: Add dra7 iodelay configuration and use it for MMC
From: Linus Walleij @ 2017-01-09 18:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Gary Bisson, Grygorii Strashko, Mark Rutland, Nishanth Menon,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP,
Lokesh Vutla
In-Reply-To: <20161230184914.GC3940-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Fri, Dec 30, 2016 at 7:49 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> Add dra7 iodelay configuration and use it for MMC.
>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Pls take this through the OMAP tree to ARM SoC.
Yours,
Linus Walleij
--
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 11/11] dmaengine: cppi41: Fix teardown warnings
From: Sergei Shtylyov @ 2017-01-09 18:46 UTC (permalink / raw)
To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-12-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
> During the teardown of a RX channel, because there is only one
> completion queue available for RX channel, descriptor of another
> channel may be popped which will cause 2 warnings:
> - the first one because we popped a wrong descriptor
> (neither the channel's descriptor, neither the teardown descriptor).
Neither ... nor.
> - the second one happen during the teardown of another channel,
> because we can't find the channel descriptor
> (that is, the one that caused the first warning).
> Use the teardown queue as completion queue during the teardown.
Hm, what's a teardown queue? I don't remember this documented...
memory fade is always possible tho... :-)
> Note that fix doesn't fix all the teardown warnings:
> I still get some when I run some corner case.
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
[...]
MBR, Sergei
--
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 2/2] pinctrl: Introduce TI IOdelay configuration driver
From: Linus Walleij @ 2017-01-09 18:46 UTC (permalink / raw)
To: Tony Lindgren
Cc: Gary Bisson, Grygorii Strashko, Mark Rutland, Nishanth Menon,
Rob Herring, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, Linux-OMAP, Lokesh Vutla
In-Reply-To: <20170105185414.27247-3-tony@atomide.com>
On Thu, Jan 5, 2017 at 7:54 PM, Tony Lindgren <tony@atomide.com> wrote:
> From: Nishanth Menon <nm@ti.com>
>
> SoC family such as DRA7 family of processors have, in addition
> to the regular muxing of pins (as done by pinctrl-single), a separate
> hardware module called IODelay which is also expected to be configured.
> The "IODelay" module has it's own register space that is independent
> of the control module and the padconf register area.
>
> With recent changes to the pinctrl framework, we can now support
> this hardware with a reasonably minimal driver by using #pinctrl-cells,
> GENERIC_PINCTRL_GROUPS and GENERIC_PINMUX_FUNCTIONS.
>
> It is advocated strongly in TI's official documentation considering
> the existing design of the DRA7 family of processors during mux or
> IODelay reconfiguration, there is a potential for a significant glitch
> which may cause functional impairment to certain hardware. It is
> hence recommended to do as little of muxing as absolutely necessary
> without I/O isolation (which can only be done in initial stages of
> bootloader).
>
> NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
> family, it is not reasonable to do stop all I/O operations for every
> such pad configuration scheme. So, we will let it glitch when used in
> this mode.
>
> Even with the above limitation, certain functionality such as MMC has
> mandatory need for IODelay reconfiguration requirements, depending on
> speed of transfer. In these cases, with careful examination of usecase
> involved, the expected glitch can be controlled such that it does not
> impact functionality.
>
> In short, IODelay module support as a padconf driver being introduced
> here is not expected to do SoC wide I/O Isolation and is meant for
> a limited subset of IODelay configuration requirements that need to
> be dynamic and whose glitchy behavior will not cause functionality
> failure for that interface.
>
> IMPORTANT NOTE: we take the approach of keeping LOCK_BITs cleared
> to 0x0 at all times, even when configuring Manual IO Timing Modes.
> This is done by eliminating the LOCK_BIT=1 setting from Step
> of the Manual IO timing Mode configuration procedure. This option
> leaves the CFG_* registers unprotected from unintended writes to the
> CTRL_CORE_PAD_* registers while Manual IO Timing Modes are configured.
>
> This approach is taken to allow for a generic driver to exist in kernel
> world that has to be used carefully in required usecases.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> [tony@atomide.com: updated to use generic pinctrl functions, added
> binding documentation, updated comments]
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Oh what a hardware mess. But very nicely isolated now.
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-09 18:45 UTC (permalink / raw)
To: Hans Verkuil, Rick Chang
Cc: Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Minghsiu Tsai, James Liao
In-Reply-To: <974d20f3-5133-0869-2a35-c1617bec5d6e-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
On 09/01/17 12:29, Hans Verkuil wrote:
> Hi Rick,
>
> On 01/06/2017 03:34 AM, Rick Chang wrote:
>> Hi Hans,
>>
>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
>> any idea about this patch series? Should we wait for [2] or we could merge
>> the source code and dt-binding first?
>
> Looking at [2] I noticed that the last comment was July 4th. What is the reason
> it hasn't been merged yet?
>
> If I know [2] will be merged for 4.11, then I am fine with merging this media
> patch series. The dependency of this patch on [2] is something Mauro can handle.
>
> If [2] is not merged for 4.11, then I think it is better to wait until it is
> merged.
>
I can't take [2] because there is no scpsys in the dts present. It seems
that it got never posted.
Rick can you please follow-up with James and provide a patch which adds
a scpsys node to the mt2701.dtsi?
Thanks,
Matthias
--
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 2/3] doc: binding: add new compatible for SDRAM/DDR Controller
From: Rob Herring @ 2017-01-09 18:45 UTC (permalink / raw)
To: Wenyou Yang
Cc: Alexandre Belloni, Russell King, Nicolas Ferre, Mark Rutland,
linux-kernel, Wenyou Yang, devicetree, linux-arm-kernel
In-Reply-To: <20170106065947.30631-3-wenyou.yang@atmel.com>
On Fri, Jan 06, 2017 at 02:59:46PM +0800, Wenyou Yang wrote:
> Add the new compatible "atmel,sama5d4-ddramc" for the SDRAM/DDR
> Controller.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> Documentation/devicetree/bindings/arm/atmel-at91.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCHv3 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Rob Herring @ 2017-01-09 18:44 UTC (permalink / raw)
To: Chris Packham
Cc: linux-arm-kernel, Mark Rutland, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Russell King, devicetree,
linux-kernel, netdev
In-Reply-To: <20170106041517.9589-5-chris.packham@alliedtelesis.co.nz>
On Fri, Jan 06, 2017 at 05:15:01PM +1300, Chris Packham wrote:
> The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
> with integrated CPUs. They are similar to the Armada XP SoCs but have
> different I/O interfaces.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> Changes in v2:
> - Update devicetree binding documentation to reflect that 98DX3336 and
> 984251 are supersets of 98DX3236.
> - disable crypto block
> - disable sdio for 98DX3236, enable for 98DX4251
> Changes in v3:
> - fix typo 4521 -> 4251
> - document prestera bindings
> - rework corediv-clock binding
> - add label to packet processor node
> - add new compativle string for DFX server
>
> .../devicetree/bindings/arm/marvell/98dx3236.txt | 23 ++
> .../devicetree/bindings/net/marvell,prestera.txt | 50 ++++
> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 254 +++++++++++++++++++++
> arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 76 ++++++
> arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 90 ++++++++
> 5 files changed, 493 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> create mode 100644 Documentation/devicetree/bindings/net/marvell,prestera.txt
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/4] usb: musb: da8xx: Use the right dma controller
From: Tony Lindgren @ 2017-01-09 18:43 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Alexandre Bailon, b-liu-l0cyMroinI0,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
david-nq/r/kbU++upp/zk7JDF2g
In-Reply-To: <7dcfe848-a421-d409-0e9a-659c095e4e31-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
* Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> [170109 10:30]:
> Hello!
>
> On 01/09/2017 07:38 PM, Alexandre Bailon wrote:
>
> > da8xx driver is registering and using the cppi dma controller but actually,
> > the da8xx has a cppi41 dma controller.
> > Update the driver to register and use the cppi41 dma controller.
> >
> > Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/usb/musb/da8xx.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
> > index e89708d..74dcc07 100644
> > --- a/drivers/usb/musb/da8xx.c
> > +++ b/drivers/usb/musb/da8xx.c
> > @@ -458,14 +458,14 @@ static inline u8 get_vbus_power(struct device *dev)
> > }
> >
> > static const struct musb_platform_ops da8xx_ops = {
> > - .quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
>
> Grr, MUSB_DMA_CPPI is certainly wrong! There's no CPPI 3.0 support for
> DA8xx. Where have this come from?
>
> > + .quirks = MUSB_DMA_CPPI41 | MUSB_INDEXED_EP,
> > .init = da8xx_musb_init,
> > .exit = da8xx_musb_exit,
> >
> > .fifo_mode = 2,
> > -#ifdef CONFIG_USB_TI_CPPI_DMA
> > - .dma_init = cppi_dma_controller_create,
> > - .dma_exit = cppi_dma_controller_destroy,
>
> Likewise, WTF?
> I suggest that you fix this crap in a separate commit, to be backported
> to -stable if needed.
Probably came from my DMA patch 7f6283ed6fe8 ("usb: musb: Set up function
pointers for DMA"). At that point I thought da8xxx.c and davinci.c are just
separate attempts of the same driver.. Sorry the number of musb glue layers
is just too confusing.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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