* [PATCH v5 02/16] dt/bindings: Update binding for PM domain idle states
From: Lina Iyer @ 2016-09-20 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874m5cx6y8.fsf@arm.com>
On Mon, Sep 19 2016 at 09:09 -0600, Brendan Jackman wrote:
>
>On Fri, Sep 16 2016 at 18:39, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> Hi Kevin,
>>
>> Thanks for looking at this and simplifying various discussions we had so
>> far. I was thinking of summarizing something very similar. I couldn't
>> due to lack of time.
>>
>> On 16/09/16 18:13, Kevin Hilman wrote:
>>
>> [...]
>>
>>> I think we're having some terminology issues...
>>>
>>> FWIW, the kernel terminolgy is actually "PM domain", not power domain.
>>> This was intentional because the goal of the PM domain was to group
>>> devices that some PM features. To be very specific to the kernel, they
>>> us the same set of PM callbacks. Today, this is most commonly used to
>>> model power domains, where a group of devices share a power rail, but it
>>> does not need to be limited to that.
>>>
>>
>> Agreed/Understood.
>>
>>> That being said, I'm having a hard time understanding the root of the
>>> disagreement.
>>>
>>
>> Yes. I tried to convey the same earlier, but have failed. The only
>> disagreement is about a small part of this DT bindings. We would like to
>> make it completely hierarchical up to CPU nodes. More comments on that
>> below.
>>
>>> It seems that you and Sudeep would like to use domain-idle-states to
>>> replace/superceed cpu-idle-states with the primary goal (and benefit)
>>> being that it simplifies the DT bindings. Is that correct?
>>>
>>
>> Correct, we want to deprecate cpu-idle-states with the introduction of
>> this hierarchical PM bindings. Yes IMO, it simplifies things and avoids
>> any ABI break we might trigger if we miss to consider some use-case now.
>>
>>> The objections have come in because that means that implies that CPUs
>>> become their own domains, which may not be the case in hardware in the
>>> sense that they share a power rail.
>>>
>>
>> Agreed.
>>
>>> However, IMO, thinking of a CPU as it's own "PM domain" may make some
>>> sense based on the terminology above.
>>>
>>
>> Thanks for that, we do understand that it may not be 100% correct when
>> we strictly considers hardware terminologies instead of above ones.
>> As along as we see no issues with the above terminologies it should be fine.
>>
>>> I think the other objection may be that using a genpd to model domain
>>> with only a single device in it may be overkill, and I agree with that.
>>
>> I too agree with that. Just because we represent that in DT in that way
>> doesn't mean we need to create a genpd to model domain. We can always
>> skip that if not required. That's pure implementation specifics and I
>> have tried to convey the same in my previous emails. I must say you have
>> summarized it very clearly in this email. Thanks again for that.
>>
>>> But, I'm not sure if making CPUs use domain-idle-states implies that
>>> they necessarily have to use genpd is what you are proposing. Maybe
>>> someone could clarify that?
>>>
>>
>> No, I have not proposing anything around implementation in the whole
>> discussion so far. I have constrained myself just to DT bindings so far.
>> That's the main reason why I was opposed to mentions of OS vs platform
>> co-ordinated modes of CPU suspend in this discussion. IMO that's
>> completely out of scope of this DT binding we are defining here.
>>
Fair. But understand the PM Domain bindings do not impose any
requirements of hierarchy. Domain idle states are defined by the
property domain-idle-states in the domain node. How the DT bindings are
organized is immaterial to the PM Domain core.
It is a different exercise all together to look at CPU PSCI modes and
have a unified way of representing them in DT. The current set of
patches does not dictate where the domain idle states be located (pardon
my example in the patch, which was not updated to reflect that). That
said, I do require that domains that are controlled by the PSCI f/w be
defined under the 'psci' node in DT, which is fair. All the domain needs
are phandles to the idle state definitions; how the nodes are arranged
in DT is not of consequence to the driver.
In my mind providing a structure to CPU PM domains that can be used for
both OSI and PC is a separate effort. It may also club what Brendan
mentions below as part of the effort. The hierarchy that is presented in
[1] is inherent in the PM domain hierarchy and idle states don't have to
duplicate that information.
>> Hope that helps/clarifies the misunderstanding/disagreement.
>
>Indeed. My intention was that the proposal would result in the exact
>same kernel behaviour as Lina's current patchset, i.e. there is one
>genpd per cluster, and CPU-level idle states are still handled by
>cpuidle.
>
>The only change from the current patchset would be in initialisation
>code: some coordination would need to be done to determine which idle
>states go into cpuidle and which go into the genpds (whereas with the
>current bindings, states from cpu-idle-states go into cpuidle and states
>from domain-idle-states go into genpd). So you could say that this would
>be a trade-off between binding simplicity and implementation simplicity.
>
I would not oppose the idea of virtual domains around CPUs (I admit I am
not comfortable with the idea though), if that is the right thing to do.
But the scope of that work is extensive and should not be clubbed as
part of this proposal. It is an extensive code rework spanning cpuidle
drivers and PSCI and there are hooks in this code to help you achieve
that.
Thanks,
Lina
[1]. https://patchwork.kernel.org/patch/9264507/
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.8 (#3)
From: Gregory CLEMENT @ 2016-09-20 16:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the third pull request for fixes for mvebu for v4.8.
Gregory
The following changes since commit c721da1d05760ad0b4e7670896dae31b6b07d8d6:
ARM: dts: kirkwood: Fix PCIe label on OpenRD (2016-08-26 11:33:16 +0200)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.8-3
for you to fetch changes up to 51227bf52008bd4c4c50da4b749bbc6e7bbbca52:
arm64: dts: marvell: fix clocksource for CP110 master SPI0 (2016-09-20 16:55:12 +0200)
----------------------------------------------------------------
mvebu fixes for 4.8 (part 3)
- Select corediv clk for all mvebu v7 SoC
- Fix clocksource for CP110 master SPI0 for Armada 7K/8K
----------------------------------------------------------------
Gregory CLEMENT (1):
ARM: mvebu: Select corediv clk for all mvebu v7 SoC
Marcin Wojtas (1):
arm64: dts: marvell: fix clocksource for CP110 master SPI0
arch/arm/mach-mvebu/Kconfig | 4 +---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH v9 08/10] arm64: pmu: Detect and enable multiple PMUs in an ACPI system
From: Punit Agrawal @ 2016-09-20 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8b27aa5-e80e-f7cc-3410-4b2ac44c69e5@arm.com>
Jeremy Linton <jeremy.linton@arm.com> writes:
> On 09/16/2016 12:07 PM, Punit Agrawal wrote:
>> Jeremy Linton <jeremy.linton@arm.com> writes:
>>
>>> Hi,
>>>
>>> On 09/16/2016 08:33 AM, Punit Agrawal wrote:
>>>> Jeremy Linton <jeremy.linton@arm.com> writes:
>>>>
>>>>> Its possible that an ACPI system has multiple CPU types in it
>>>>> with differing PMU counters. Iterate the CPU's and make a determination
>>>>> about how many of each type exist in the system. Then take and create
>>>>> a PMU platform device for each type, and assign it the interrupts parsed
>>>>> from the MADT. Creating a platform device is necessary because the PMUs
>>>>> are not described as devices in the DSDT table.
>>>>>
>>>>> This code is loosely based on earlier work by Mark Salter.
>>>
>>> (trimming)
>>>
>>>>> +
>>>>> + list_for_each_entry_safe(pmu, safe_temp, &pmus, list) {
>>>>> + if (unused_madt_entries)
>>>>> + pmu->cpu_count = num_possible_cpus();
>>>>
>>>> So if there is any unbooted cpu ...
>>>>
>>>>> +
>>>>> + res = kcalloc(pmu->cpu_count,
>>>>> + sizeof(struct resource), GFP_KERNEL);
>>>>
>>>> ... we allocate potentially large number (num_possible_cpus()) of
>>>> resources for each PMU.
>>>>
>>>> This is needlessly wasteful. Under what conditions have you found
>>>> reg_midr to be 0?
>>>
>>> Unused MADT entries, in place for potentially unbooted/hotplug
>>> CPUs.
>>
>> Is linux able to deal with booting secondaries that have unused MADT
>> entries?
>
> Uh, yah I think so, that is how i've been testing it, maybe we are
> saying different things. When i'm talking about "unused" I mean MADT
> entries that don't have started/running cpus. Obviously they stop
> being unused when a cpu is booted.
>
>>
>>> In those cases you don't know for sure which PMU the CPU belongs
>>> to until it comes online and the MIDR can be read. I'm open to
>>> suggestions on how to deal with this, outside of pushing my luck and
>>> further breaking the platform device encapsulation by trying to
>>> reallocate the resource structure while its active. Besides its only
>>> wasteful for ACPI+big.little, which at the moment only applies to a
>>> development platform.
>>
>> I don't have any ideas to solve this problem, but in the interest of
>> helping review, please move all the changes arising from hotplug/unused
>> MADT entries in this patch to the next one.
>
> Which is sort of the opposite of the last 3 months, of complaints
> about how hard it was to review this module with multiple patches
> adding features to the code...
My suggestion to move functionality that has concerns and needs rework
to later patch is aimed at helping get stuff that everybody agrees upon
merged. But it's only a suggestion...
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/3] regulator: axp20x: simplify poly-phase handling
From: Jean-Francois Moine @ 2016-09-20 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1474616699.git.moinejf@free.fr>
Building a list (bitmap) of the slaves included in poly-phase groups
at probe startup time simplifies the treatment in the regulator
creation loop.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
---
drivers/regulator/axp20x-regulator.c | 45 +++++++++++++++++-------------------
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 54382ef..4e5e7c8 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -477,30 +477,24 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
}
/*
- * This function checks whether a regulator is part of a poly-phase
- * output setup based on the registers settings. Returns true if it is.
+ * This function checks which regulators are part of poly-phase
+ * output setups based on the registers settings.
+ * Returns a bitmap of these regulators.
*/
-static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
+static u32 axp20x_polyphase_slave(struct axp20x_dev *axp20x)
{
- u32 reg = 0;
-
- /* Only AXP806 has poly-phase outputs */
- if (axp20x->variant != AXP806_ID)
- return false;
+ u32 reg = 0, bitmap = 0;
regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, ®);
- switch (id) {
- case AXP806_DCDCB:
- return (((reg & GENMASK(7, 6)) == BIT(6)) ||
- ((reg & GENMASK(7, 6)) == BIT(7)));
- case AXP806_DCDCC:
- return ((reg & GENMASK(7, 6)) == BIT(7));
- case AXP806_DCDCE:
- return !!(reg & BIT(5));
- }
+ if ((reg & GENMASK(7, 6)) == BIT(5))
+ bitmap |= 1 << AXP806_DCDCE;
+ if ((reg & GENMASK(7, 6)) == BIT(6))
+ bitmap |= 1 << AXP806_DCDCB;
+ if ((reg & GENMASK(7, 6)) == BIT(7))
+ bitmap |= (1 << AXP806_DCDCB) | (1 << AXP806_DCDCC);
- return false;
+ return bitmap;
}
static int axp20x_regulator_probe(struct platform_device *pdev)
@@ -518,6 +512,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
const char *dcdc1_name = axp22x_regulators[AXP22X_DCDC1].name;
const char *dcdc5_name = axp22x_regulators[AXP22X_DCDC5].name;
bool drivevbus = false;
+ u32 skip_bitmap = 0;
switch (axp20x->variant) {
case AXP202_ID:
@@ -535,6 +530,13 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
case AXP806_ID:
regulators = axp806_regulators;
nregulators = AXP806_REG_ID_MAX;
+
+ /*
+ * The regulators which are slave in a poly-phase setup
+ * are skipped, as their controls are bound to the master
+ * regulator and won't work.
+ */
+ skip_bitmap |= axp20x_polyphase_slave(axp20x);
break;
case AXP809_ID:
regulators = axp809_regulators;
@@ -553,12 +555,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
const struct regulator_desc *desc = ®ulators[i];
struct regulator_desc *new_desc;
- /*
- * If this regulator is a slave in a poly-phase setup,
- * skip it, as its controls are bound to the master
- * regulator and won't work.
- */
- if (axp20x_is_polyphase_slave(axp20x, i))
+ if (skip_bitmap & (1 << i))
continue;
/*
--
2.10.0
^ permalink raw reply related
* [PATCH v6 4/4] ARM: dts: Add EXTI controller node to stm32f429
From: Alexandre TORGUE @ 2016-09-20 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474387259-18926-1-git-send-email-alexandre.torgue@st.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 35df462..1a189d4 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -176,6 +176,14 @@
reg = <0x40013800 0x400>;
};
+ exti: interrupt-controller at 40013c00 {
+ compatible = "st,stm32-exti";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x40013C00 0x400>;
+ interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <42>, <62>, <76>;
+ };
+
pin-controller {
#address-cells = <1>;
#size-cells = <1>;
--
1.9.1
^ permalink raw reply related
* [PATCH v6 3/4] ARM: STM32: Select external interrupts controller
From: Alexandre TORGUE @ 2016-09-20 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474387259-18926-1-git-send-email-alexandre.torgue@st.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2d601d7..157cea9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -877,6 +877,7 @@ config ARCH_STM32
select CLKSRC_STM32
select PINCTRL
select RESET_CONTROLLER
+ select STM32_EXTI
help
Support for STMicroelectronics STM32 processors.
--
1.9.1
^ permalink raw reply related
* [PATCH v6 2/4] drivers: irqchip: Add STM32 external interrupts support
From: Alexandre TORGUE @ 2016-09-20 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474387259-18926-1-git-send-email-alexandre.torgue@st.com>
The STM32 external interrupt controller consists of edge detectors that
generate interrupts requests or wake-up events.
Each line can be independently configured as interrupt or wake-up source,
and triggers either on rising, falling or both edges. Each line can also
be masked independently.
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 7f87289..bc62d1f 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -264,3 +264,7 @@ config EZNPS_GIC
select IRQ_DOMAIN
help
Support the EZchip NPS400 global interrupt controller
+
+config STM32_EXTI
+ bool
+ select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 4c203b6..96383b2 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -71,3 +71,4 @@ obj-$(CONFIG_MVEBU_ODMI) += irq-mvebu-odmi.o
obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
obj-$(CONFIG_EZNPS_GIC) += irq-eznps.o
obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o
+obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
new file mode 100644
index 0000000..491568c
--- /dev/null
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -0,0 +1,201 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author: Maxime Coquelin <mcoquelin.stm32@gmail.com>
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/bitops.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+
+#define EXTI_IMR 0x0
+#define EXTI_EMR 0x4
+#define EXTI_RTSR 0x8
+#define EXTI_FTSR 0xc
+#define EXTI_SWIER 0x10
+#define EXTI_PR 0x14
+
+static void stm32_irq_handler(struct irq_desc *desc)
+{
+ struct irq_domain *domain = irq_desc_get_handler_data(desc);
+ struct irq_chip_generic *gc = domain->gc->gc[0];
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned long pending;
+ int n;
+
+ chained_irq_enter(chip, desc);
+
+ while ((pending = irq_reg_readl(gc, EXTI_PR))) {
+ for_each_set_bit(n, &pending, BITS_PER_LONG) {
+ generic_handle_irq(irq_find_mapping(domain, n));
+ irq_reg_writel(gc, BIT(n), EXTI_PR);
+ }
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
+static int stm32_irq_set_type(struct irq_data *data, unsigned int type)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+ int pin = data->hwirq;
+ u32 rtsr, ftsr;
+
+ irq_gc_lock(gc);
+
+ rtsr = irq_reg_readl(gc, EXTI_RTSR);
+ ftsr = irq_reg_readl(gc, EXTI_FTSR);
+
+ switch (type) {
+ case IRQ_TYPE_EDGE_RISING:
+ rtsr |= BIT(pin);
+ ftsr &= ~BIT(pin);
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ rtsr &= ~BIT(pin);
+ ftsr |= BIT(pin);
+ break;
+ case IRQ_TYPE_EDGE_BOTH:
+ rtsr |= BIT(pin);
+ ftsr |= BIT(pin);
+ break;
+ default:
+ irq_gc_unlock(gc);
+ return -EINVAL;
+ }
+
+ irq_reg_writel(gc, rtsr, EXTI_RTSR);
+ irq_reg_writel(gc, ftsr, EXTI_FTSR);
+
+ irq_gc_unlock(gc);
+
+ return 0;
+}
+
+static int stm32_irq_set_wake(struct irq_data *data, unsigned int on)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+ int pin = data->hwirq;
+ u32 emr;
+
+ irq_gc_lock(gc);
+
+ emr = irq_reg_readl(gc, EXTI_EMR);
+ if (on)
+ emr |= BIT(pin);
+ else
+ emr &= ~BIT(pin);
+ irq_reg_writel(gc, emr, EXTI_EMR);
+
+ irq_gc_unlock(gc);
+
+ return 0;
+}
+
+static int stm32_exti_alloc(struct irq_domain *d, unsigned int virq,
+ unsigned int nr_irqs, void *data)
+{
+ struct irq_chip_generic *gc = d->gc->gc[0];
+ struct irq_fwspec *fwspec = data;
+ irq_hw_number_t hwirq;
+
+ hwirq = fwspec->param[0];
+
+ irq_map_generic_chip(d, virq, hwirq);
+ irq_domain_set_info(d, virq, hwirq, &gc->chip_types->chip, gc,
+ handle_simple_irq, NULL, NULL);
+
+ return 0;
+}
+
+static void stm32_exti_free(struct irq_domain *d, unsigned int virq,
+ unsigned int nr_irqs)
+{
+ struct irq_data *data = irq_domain_get_irq_data(d, virq);
+
+ irq_domain_reset_irq_data(data);
+}
+
+struct irq_domain_ops irq_exti_domain_ops = {
+ .map = irq_map_generic_chip,
+ .xlate = irq_domain_xlate_onetwocell,
+ .alloc = stm32_exti_alloc,
+ .free = stm32_exti_free,
+};
+
+static int __init stm32_exti_init(struct device_node *node,
+ struct device_node *parent)
+{
+ unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN;
+ int nr_irqs, nr_exti, ret, i;
+ struct irq_chip_generic *gc;
+ struct irq_domain *domain;
+ void *base;
+
+ base = of_iomap(node, 0);
+ if (!base) {
+ pr_err("%s: Unable to map registers\n", node->full_name);
+ return -ENOMEM;
+ }
+
+ /* Determine number of irqs supported */
+ writel_relaxed(~0UL, base + EXTI_RTSR);
+ nr_exti = fls(readl_relaxed(base + EXTI_RTSR));
+ writel_relaxed(0, base + EXTI_RTSR);
+
+ pr_info("%s: %d External IRQs detected\n", node->full_name, nr_exti);
+
+ domain = irq_domain_add_linear(node, nr_exti,
+ &irq_exti_domain_ops, NULL);
+ if (!domain) {
+ pr_err("%s: Could not register interrupt domain.\n",
+ node->name);
+ ret = -ENOMEM;
+ goto out_unmap;
+ }
+
+ ret = irq_alloc_domain_generic_chips(domain, nr_exti, 1, "exti",
+ handle_edge_irq, clr, 0, 0);
+ if (ret) {
+ pr_err("%s: Could not allocate generic interrupt chip.\n",
+ node->full_name);
+ goto out_free_domain;
+ }
+
+ gc = domain->gc->gc[0];
+ gc->reg_base = base;
+ gc->chip_types->type = IRQ_TYPE_EDGE_BOTH;
+ gc->chip_types->chip.name = gc->chip_types[0].chip.name;
+ gc->chip_types->chip.irq_ack = irq_gc_ack_set_bit;
+ gc->chip_types->chip.irq_mask = irq_gc_mask_clr_bit;
+ gc->chip_types->chip.irq_unmask = irq_gc_mask_set_bit;
+ gc->chip_types->chip.irq_set_type = stm32_irq_set_type;
+ gc->chip_types->chip.irq_set_wake = stm32_irq_set_wake;
+ gc->chip_types->regs.ack = EXTI_PR;
+ gc->chip_types->regs.mask = EXTI_IMR;
+ gc->chip_types->handler = handle_edge_irq;
+
+ nr_irqs = of_irq_count(node);
+ for (i = 0; i < nr_irqs; i++) {
+ unsigned int irq = irq_of_parse_and_map(node, i);
+
+ irq_set_handler_data(irq, domain);
+ irq_set_chained_handler(irq, stm32_irq_handler);
+ }
+
+ return 0;
+
+out_free_domain:
+ irq_domain_remove(domain);
+out_unmap:
+ iounmap(base);
+ return ret;
+}
+
+IRQCHIP_DECLARE(stm32_exti, "st,stm32-exti", stm32_exti_init);
--
1.9.1
^ permalink raw reply related
* [PATCH v6 1/4] Documentation: dt-bindings: Document STM32 EXTI controller bindings
From: Alexandre TORGUE @ 2016-09-20 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474387259-18926-1-git-send-email-alexandre.torgue@st.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
new file mode 100644
index 0000000..6e7703d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
@@ -0,0 +1,20 @@
+STM32 External Interrupt Controller
+
+Required properties:
+
+- compatible: Should be "st,stm32-exti"
+- reg: Specifies base physical address and size of the registers
+- interrupt-controller: Indentifies the node as an interrupt controller
+- #interrupt-cells: Specifies the number of cells to encode an interrupt
+ specifier, shall be 2
+- interrupts: interrupts references to primary interrupt controller
+
+Example:
+
+exti: interrupt-controller at 40013c00 {
+ compatible = "st,stm32-exti";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x40013C00 0x400>;
+ interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <42>, <62>, <76>;
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v6 0/4] Add STM32 EXTI interrupt controller support
From: Alexandre TORGUE @ 2016-09-20 16:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This v6 fix useless mask in .free callback of stm32 exti driver (thanks
Thomas).
I resend only patches concerning STM32 EXTI driver (as pinctrl part has
already been applied by Linus W.)
The series adds support to EXTI interrupt controller and GPIO IRQ support in
STM32 pinctrl driver.
The STM32 external interrupt controller consists of edge detectors that
generate interrupts requests or wake-up events.
Each line can be independently configured as interrupt or wake-up source,
and triggers either on rising, fallin or both edges. Each line can also
be masked independently.
Regards
Alex
Changes since v5:
-----------------
- Fix .free callback according to Thomas
Changes since v4:
-----------------
- Fix bad copy/paste in stm32 exti driver
- Remove GPIOLIB_IRQCHIP config in stm32 pinctrl driver
Changes since v3:
-----------------
- Review domain dealloc/free irq in stm32 pinctrl driver
- Review domain dealloc/free irq in stm32 exti driver
- Fix remarks on coding style
Changes since v2:
-----------------
- Define irq_chip for GPIO banks
- Use hierarchical domain for GPIO banks
- Improve search loop inside stm32_exti handler
- Rebased on top of v4.8-rc1
Changes since v1:
-----------------
- Rebased on top of v4.6-rc1
- Change variable name from virq to irq (Linus W.)
Alexandre TORGUE (4):
Documentation: dt-bindings: Document STM32 EXTI controller bindings
drivers: irqchip: Add STM32 external interrupts support
ARM: STM32: Select external interrupts controller
ARM: dts: Add EXTI controller node to stm32f429
.../interrupt-controller/st,stm32-exti.txt | 20 ++
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/stm32f429.dtsi | 8 +
drivers/irqchip/Kconfig | 4 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-stm32-exti.c | 201 +++++++++++++++++++++
6 files changed, 235 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
create mode 100644 drivers/irqchip/irq-stm32-exti.c
--
1.9.1
^ permalink raw reply
* [PATCH v3 0/3] ARM: aspeed: add support for the BT IPMI interface
From: Cédric Le Goater @ 2016-09-20 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <40bb95a8-b5a6-563b-11c6-73de2f67130d@acm.org>
On 09/20/2016 04:58 PM, Corey Minyard wrote:
> On 09/20/2016 02:01 AM, C?dric Le Goater wrote:
>> Hello,
>>
>> This serie adds support for the iBT interface on Aspeed SOCs (AST2400
>> and AST2500). The BT (Block Transfer) interface is used to perform
>> in-band IPMI communication between a host and its BMC. This driver
>> implements the BMC side.
>
> This looks good. I pulled these into my tree, it's ok for 4.9 or
> whatever is next, since it's a new driver.
>
> Do patches 2 and 3 go through Joel?
Yes. He said he would.
Thanks,
C.
>
> -corey
>
>> Changes since v2:
>>
>> - limit to one opener
>> - protect write/read operations with a mutex.
>>
>> Changes since v1:
>>
>> - the driver is now called 'bt-bmc' and the device node '/dev/ipmi-bt-host'
>> - the code is now under drivers/char/ipmi/. This required a change of
>> the top Makefile in drivers/ to compile the bt-bmc driver with the
>> ipmi handlers not being selected. That might be an issue.
>> - changed the read/write operations to use a temporary buffer and get
>> rid of the {get,put}_user calls
>>
>> Thanks,
>>
>> C.
>>
>> Alistair Popple (1):
>> ipmi: add an Aspeed BT IPMI BMC driver
>>
>> C?dric Le Goater (2):
>> ARM: aspeed: Add defconfigs for CONFIG_ASPEED_BT_IPMI_BMC
>> ARM: dts: aspeed: Enable BT IPMI BMC device
>>
>> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
>> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
>> arch/arm/boot/dts/aspeed-g5.dtsi | 6 +
>> arch/arm/configs/aspeed_g4_defconfig | 1 +
>> arch/arm/configs/aspeed_g5_defconfig | 1 +
>> drivers/Makefile | 2 +-
>> drivers/char/ipmi/Kconfig | 7 +
>> drivers/char/ipmi/Makefile | 1 +
>> drivers/char/ipmi/bt-bmc.c | 510 +++++++++++++++++++++
>> include/uapi/linux/Kbuild | 1 +
>> include/uapi/linux/bt-bmc.h | 18 +
>> 11 files changed, 575 insertions(+), 1 deletion(-)
>> create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
>> create mode 100644 drivers/char/ipmi/bt-bmc.c
>> create mode 100644 include/uapi/linux/bt-bmc.h
>>
>
^ permalink raw reply
* [PATCH v5 2/9] drivers: irqchip: Add STM32 external interrupts support
From: Thomas Gleixner @ 2016-09-20 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2095bf33-2940-3294-afd6-a28a48762569@st.com>
On Tue, 20 Sep 2016, Alexandre Torgue wrote:
> so if you agree I will resend only patches concerning stm32 exti driver
> [1],[2],[3],[4]
Ok.
> Thanks for your time.
Welcome,
tglx
^ permalink raw reply
* [PATCH v5 2/9] drivers: irqchip: Add STM32 external interrupts support
From: Alexandre Torgue @ 2016-09-20 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1609201600490.6905@nanos>
Thomas,
On 09/20/2016 04:02 PM, Thomas Gleixner wrote:
> On Tue, 20 Sep 2016, Alexandre Torgue wrote:
>> On 09/20/2016 02:44 PM, Thomas Gleixner wrote:
>>> Free will be called when a interrupt in the child domain is torn down,
>>> i.e. when irq_domain_free_irqs() is called. And it will be called for both
>>> domains like the alloc callback is invoked on both domains via
>>> irq_domain_alloc_irqs().
>>
>> Thanks Thomas for this clarification (I'm sure now that we need .free
>> callbacks).
>> irq_domain_free_irqs() is called in 2 scenario:
>> 1- when issue occurs in irq_create_fwspec_mapping()
>> 2- when irq_dispose_mapping() is called
>>
>> Case 2 is the one I tested some times ago. In this case, I need to mask
>> interrupts in .free callback of EXTI (parent) domain to avoid spurious
>> interrupts.
>
> And why would irq_dispose_mapping() be called on an unmasked, i.e. active,
> interrupt? The masking is just papering over that.
Ok. So my test was wrong and irq_dispose_mapping() has to be called when
irq is masked (for example just after free_irq()). For sure in this
case the mask inside exti free callback has no sens (catch :))
I will change .free callback by:
static void stm32_exti_free(struct irq_domain *d, unsigned int virq,
unsigned int nr_irqs)
{
struct irq_data *data = irq_domain_get_irq_data(d, virq);
irq_domain_reset_irq_data(data);
}
so if you agree I will resend only patches concerning stm32 exti driver
[1],[2],[3],[4]
Thanks for your time.
alex
>
> Thanks,
>
> tglx
>
^ permalink raw reply
* [PATCH] hwrng: omap - Only fail if pm_runtime_get_sync returns < 0
From: Dave Gerlach @ 2016-09-20 15:25 UTC (permalink / raw)
To: linux-arm-kernel
Currently omap-rng checks the return value of pm_runtime_get_sync and
reports failure if anything is returned, however it should be checking
if ret < 0 as pm_runtime_get_sync return 0 on success but also can return
1 if the device was already active which is not a failure case. Only
values < 0 are actual failures.
Fixes: 61dc0a446e5d ("hwrng: omap - Fix assumption that runtime_get_sync will always succeed")
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
drivers/char/hw_random/omap-rng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 01d4be2c354b..f5c26a5f6875 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -385,7 +385,7 @@ static int omap_rng_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
ret = pm_runtime_get_sync(&pdev->dev);
- if (ret) {
+ if (ret < 0) {
dev_err(&pdev->dev, "Failed to runtime_get device: %d\n", ret);
pm_runtime_put_noidle(&pdev->dev);
goto err_ioremap;
@@ -443,7 +443,7 @@ static int __maybe_unused omap_rng_resume(struct device *dev)
int ret;
ret = pm_runtime_get_sync(dev);
- if (ret) {
+ if (ret < 0) {
dev_err(dev, "Failed to runtime_get device: %d\n", ret);
pm_runtime_put_noidle(dev);
return ret;
--
2.9.3
^ permalink raw reply related
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Ard Biesheuvel @ 2016-09-20 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920140518.GD13855@localhost>
On 20 September 2016 at 15:05, Bjorn Helgaas <helgaas@kernel.org> wrote:
> Hi Ard,
>
> On Tue, Sep 20, 2016 at 02:40:13PM +0100, Ard Biesheuvel wrote:
>> On 20 September 2016 at 14:33, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > [+cc Rafael (maybe already cc'd; I didn't recognize rafael at kernel.org, Duc]
>> >
>> > On Tue, Sep 20, 2016 at 09:23:21AM +0200, Tomasz Nowicki wrote:
>> >> On 19.09.2016 20:09, Bjorn Helgaas wrote:
>> >> >On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
>> >> >>thunder-pem driver stands for being ACPI based PCI host controller.
>> >> >>However, there is no standard way to describe its PEM-specific register
>> >> >>ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension
>> >> >>to obtain hardcoded addresses from static resource array.
>> >> >>Although it is not pretty, it prevents from creating standard mechanism to
>> >> >>handle similar cases in future.
>> >> >>
>> >> >>Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> >> >>---
>> >> >> drivers/pci/host/pci-thunder-pem.c | 61 ++++++++++++++++++++++++++++++--------
>> >> >> 1 file changed, 48 insertions(+), 13 deletions(-)
>> >> >>
>> >> >>diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
>> >> >>index 6abaf80..b048761 100644
>> >> >>--- a/drivers/pci/host/pci-thunder-pem.c
>> >> >>+++ b/drivers/pci/host/pci-thunder-pem.c
>> >> >>@@ -18,6 +18,7 @@
>> >> >> #include <linux/init.h>
>> >> >> #include <linux/of_address.h>
>> >> >> #include <linux/of_pci.h>
>> >> >>+#include <linux/pci-acpi.h>
>> >> >> #include <linux/pci-ecam.h>
>> >> >> #include <linux/platform_device.h>
>> >> >>
>> >> >>@@ -284,6 +285,40 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
>> >> >> return pci_generic_config_write(bus, devfn, where, size, val);
>> >> >> }
>> >> >>
>> >> >>+#ifdef CONFIG_ACPI
>> >> >>+static struct resource thunder_pem_reg_res[] = {
>> >> >>+ [4] = DEFINE_RES_MEM(0x87e0c0000000UL, SZ_16M),
>> >> >>+ [5] = DEFINE_RES_MEM(0x87e0c1000000UL, SZ_16M),
>> >> >>+ [6] = DEFINE_RES_MEM(0x87e0c2000000UL, SZ_16M),
>> >> >>+ [7] = DEFINE_RES_MEM(0x87e0c3000000UL, SZ_16M),
>> >> >>+ [8] = DEFINE_RES_MEM(0x87e0c4000000UL, SZ_16M),
>> >> >>+ [9] = DEFINE_RES_MEM(0x87e0c5000000UL, SZ_16M),
>> >> >>+ [14] = DEFINE_RES_MEM(0x97e0c0000000UL, SZ_16M),
>> >> >>+ [15] = DEFINE_RES_MEM(0x97e0c1000000UL, SZ_16M),
>> >> >>+ [16] = DEFINE_RES_MEM(0x97e0c2000000UL, SZ_16M),
>> >> >>+ [17] = DEFINE_RES_MEM(0x97e0c3000000UL, SZ_16M),
>> >> >>+ [18] = DEFINE_RES_MEM(0x97e0c4000000UL, SZ_16M),
>> >> >>+ [19] = DEFINE_RES_MEM(0x97e0c5000000UL, SZ_16M),
>> >> >
>> >> >1) The "correct" way to discover the resources consumed by an ACPI
>> >> > device is to use the _CRS method. I know there are some issues
>> >> > there for bridges (not the fault of ThunderX!) because there's not
>> >> > a good way to distinguish windows from resources consumed directly
>> >> > by the bridge.
>> >> >
>> >> > But we should either do this correctly, or include a comment about
>> >> > why we're doing it wrong, so we don't give the impression that this
>> >> > is the right way to do it.
>> >> >
>> >> > I seem to recall some discussion about why we're doing it this way,
>> >> > but I don't remember the details. It'd be nice to include a
>> >> > summary here.
>> >>
>> >> OK I will. The reason why we cannot use _CRS for this case is that
>> >> CONSUMER flag was not use consistently for the bridge so far.
>> >
>> > Yes, I'm aware of that problem, but hard-coding resources into drivers
>> > is just a disaster. The PCI and ACPI cores need generic ways to learn
>> > what resources are consumed by devices. For PCI devices, that's done
>> > with BARs. For ACPI devices, it's done with _CRS. Without generic
>> > resource discovery, we can't manage resources reliably at the system
>> > level [1].
>> >
>> > You have a PNP0A03/PNP0A08 device for the PCI host bridge. Because of
>> > the BIOS bugs in CONSUMER flag usage, we assume everything in its _CRS
>> > is a window and not consumed by the bridge itself. What if you added
>> > a companion ACPI device with a _CRS that contained the bridge
>> > resources? Then you'd have some driver ugliness to find that device,
>> > but at least the ACPI core could tell what resources were in use.
>> >
>> > Maybe Rafael has a better idea?
>>
>> In the discussions leading up to this, we tried very hard to make this
>> arm64/acpi quirks mechanism just as flexible as we need it to be to
>> cover the current crop of incompatible hardware, but not more so.
>> Going forward, we intend to require all arm64/acpi hardware to be spec
>> compliant, and so any parametrization beyond what is required for the
>> currently known broken hardware is only going to make it easier for
>> others to ship with tweaked ACPI descriptions so that an existing
>> quirk is triggered for hardware that it was not intended for. It also
>> implies that we have to deal with the ACPI descriptions as they were
>> shipped with the current hardware.
>>
>> That does not mean, of course, that we should use bare constants
>> rather than symbolic ones, but anything beyond that exceeds the
>> desired scope of quirks handling.
>
> Symbolic vs bare constants is the least of my worries. I'm pretty
> happy with the current quirk implementation. It's pretty simple and
> straightforward.
>
OK, good to know that we are on the right track here.
> Apparently you shipped broken firmware that doesn't accurately
> describe system resource usage. Presumably that firmware could be
> updated, but maybe it's worthwhile to work around it in the kernel,
> depending on where it got shipped.
>
None of these platforms can be fixed entirely in software, and given
that we will not be adding quirks for new broken hardware, we should
ask ourselves whether having two versions of a quirk, i.e., one for
broken hardware + currently shipping firmware, and one for the same
broken hardware with fixed firmware is really an improvement over what
has been proposed here.
> I'd like to step back and come up with some understanding of how
> non-broken firmware *should* deal with this issue. Then, if we *do*
> work around this particular broken firmware in the kernel, it would be
> nice to do it in a way that fits in with that understanding.
>
> For example, if a companion ACPI device is the preferred solution, an
> ACPI quirk could fabricate a device with the required resources. That
> would address the problem closer to the source and make it more likely
> that the rest of the system will work correctly: /proc/iomem could
> make sense, things that look at _CRS generically would work (e.g,
> /sys/, an admittedly hypothetical "lsacpi", etc.)
>
> Hard-coding stuff in drivers is a point solution that doesn't provide
> any guidance for future platforms and makes it likely that the hack
> will get copied into even more drivers.
>
OK, I see. But the guidance for future platforms should be 'do not
rely on quirks', and what I am arguing here is that the more we polish
up this code and make it clean and reusable, the more likely it is
that will end up getting abused by new broken hardware that we set out
to reject entirely in the first place.
So of course, if the quirk involves claiming resources, let's make
sure that this occurs in the cleanest and most compliant way possible.
But any factoring/reuse concerns other than for the current crop of
broken hardware should be avoided imo.
--
Ard.
^ permalink raw reply
* [PATCH 2/2] arm64: dts: marvell: fix clocksource for CP110 slave SPI0
From: Gregory CLEMENT @ 2016-09-20 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473183672-12028-3-git-send-email-mw@semihalf.com>
Hi Olof and Arnd,
On mar., sept. 06 2016, Marcin Wojtas <mw@semihalf.com> wrote:
> I2C and SPI interfaces share common clock trees within the CP110 HW block.
> It occurred that SPI0 interface has wrong clock assignment in the device
> tree, which is fixed in this commit to a proper value.
>
> Fixes: c749b8d9de32 ("arm64: dts: marvell: add description for the ...")
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Could you take this patch for 4.9? I didn't realized at first view it
was for 4.9, I though I could put it the PR for fixes for 4.8.
I can do a new PR for dt64 with this single patch if you prefer.
The last option will be to have it as a fix for v4.9-rc2.
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> index 37bff70..150675c 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> @@ -133,7 +133,7 @@
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> cell-index = <1>;
> - clocks = <&cps_syscon0 0 3>;
> + clocks = <&cps_syscon0 1 21>;
> status = "disabled";
> };
>
> --
> 1.8.3.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 0/3] ARM: aspeed: add support for the BT IPMI interface
From: Corey Minyard @ 2016-09-20 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474354900-5618-1-git-send-email-clg@kaod.org>
On 09/20/2016 02:01 AM, C?dric Le Goater wrote:
> Hello,
>
> This serie adds support for the iBT interface on Aspeed SOCs (AST2400
> and AST2500). The BT (Block Transfer) interface is used to perform
> in-band IPMI communication between a host and its BMC. This driver
> implements the BMC side.
This looks good. I pulled these into my tree, it's ok for 4.9 or
whatever is next, since it's a new driver.
Do patches 2 and 3 go through Joel?
-corey
> Changes since v2:
>
> - limit to one opener
> - protect write/read operations with a mutex.
>
> Changes since v1:
>
> - the driver is now called 'bt-bmc' and the device node '/dev/ipmi-bt-host'
>
> - the code is now under drivers/char/ipmi/. This required a change of
> the top Makefile in drivers/ to compile the bt-bmc driver with the
> ipmi handlers not being selected. That might be an issue.
>
> - changed the read/write operations to use a temporary buffer and get
> rid of the {get,put}_user calls
>
> Thanks,
>
> C.
>
> Alistair Popple (1):
> ipmi: add an Aspeed BT IPMI BMC driver
>
> C?dric Le Goater (2):
> ARM: aspeed: Add defconfigs for CONFIG_ASPEED_BT_IPMI_BMC
> ARM: dts: aspeed: Enable BT IPMI BMC device
>
> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 +
> arch/arm/boot/dts/aspeed-g5.dtsi | 6 +
> arch/arm/configs/aspeed_g4_defconfig | 1 +
> arch/arm/configs/aspeed_g5_defconfig | 1 +
> drivers/Makefile | 2 +-
> drivers/char/ipmi/Kconfig | 7 +
> drivers/char/ipmi/Makefile | 1 +
> drivers/char/ipmi/bt-bmc.c | 510 +++++++++++++++++++++
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/bt-bmc.h | 18 +
> 11 files changed, 575 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
> create mode 100644 drivers/char/ipmi/bt-bmc.c
> create mode 100644 include/uapi/linux/bt-bmc.h
>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: marvell: fix clocksource for CP110 master SPI0
From: Gregory CLEMENT @ 2016-09-20 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473183672-12028-2-git-send-email-mw@semihalf.com>
Hi Marcin,
On mar., sept. 06 2016, Marcin Wojtas <mw@semihalf.com> wrote:
> I2C and SPI interfaces share common clock trees within the CP110 HW block.
> It occurred that SPI0 interface has wrong clock assignment in the device
> tree, which is fixed in this commit to a proper value.
>
> Fixes: 728dacc7f4dd ("arm64: dts: marvell: initial DT description of ...")
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> CC: <stable@vger.kernel.org> v4.7+
Applied on mvebu/fixes
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index db1be4c..903b0f6 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -133,7 +133,7 @@
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> cell-index = <1>;
> - clocks = <&cpm_syscon0 0 3>;
> + clocks = <&cpm_syscon0 1 21>;
> status = "disabled";
> };
>
> --
> 1.8.3.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v7 05/22] Docs: dt: document ARM SMMUv3 generic binding usage
From: Rob Herring @ 2016-09-20 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2273645f1fa5c76b6b98b5fd03804ab8b55a7691.1473695704.git.robin.murphy@arm.com>
On Mon, Sep 12, 2016 at 05:13:43PM +0100, Robin Murphy wrote:
> We're about to ratify our use of the generic binding, so document it.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> ---
>
> - Reference PCI "iommu-map" binding instead, as that's our main concern
> - Fix "IDs" typo
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 00/19] ARM: imx legacy: move peripheral initializations to .init_late
From: Shawn Guo @ 2016-09-20 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474248988-10626-1-git-send-email-vz@mleia.com>
On Mon, Sep 19, 2016 at 04:36:28AM +0300, Vladimir Zapolskiy wrote:
> Vladimir Zapolskiy (19):
> ARM: imx legacy: kzm: move peripheral initialization to .init_late
> ARM: imx legacy: mx31lite: move peripheral initialization to .init_late
> ARM: imx legacy: mx31ads: move peripheral initialization to .init_late
> ARM: imx legacy: mx31lilly: move peripheral initialization to .init_late
> ARM: imx legacy: pcm037: move peripheral initialization to .init_late
> ARM: imx legacy: mx31-3ds: move peripheral initialization to .init_late
> ARM: imx legacy: qong: move peripheral initialization to .init_late
> ARM: imx legacy: armadillo5x0: move peripheral initialization to .init_late
> ARM: imx legacy: mx31moboard: move peripheral initialization to .init_late
> ARM: imx legacy: vpr200: move peripheral initialization to .init_late
> ARM: imx legacy: imx27-visstrim-m10: move peripheral initialization to .init_late
> ARM: imx legacy: mx27-3ds: move peripheral initialization to .init_late
> ARM: imx legacy: mx35-3ds: move peripheral initialization to .init_late
> ARM: imx legacy: apf9328: move peripheral initialization to .init_late
> ARM: imx legacy: scb9328: move peripheral initialization to .init_late
> ARM: imx legacy: pcm043: move peripheral initialization to .init_late
> ARM: imx legacy: mx21ads: move peripheral initialization to .init_late
> ARM: imx legacy: mx27ads: move peripheral initialization to .init_late
> ARM: imx legacy: pca100: move peripheral initialization to .init_late
Applied all, except patch #14 (apf9328) and #15 (scb9328), which are
removed during this development cycle.
Shawn
^ permalink raw reply
* [PATCH resend 2/5] input: touchscreen: Add LED trigger support to the softbutton code
From: Rob Herring @ 2016-09-20 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911184408.11657-3-hdegoede@redhat.com>
On Sun, Sep 11, 2016 at 08:44:05PM +0200, Hans de Goede wrote:
> In some hardware there are 1 or more LEDs behind the touchscreen
> softbuttons, which are intended to provide visual feedback to the
> user that the softbutton has been pressed, this commit adds support
> for this.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../bindings/input/touchscreen/softbuttons.txt | 4 ++
> drivers/input/touchscreen/softbuttons.c | 49 +++++++++++++++++++++-
> 2 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt b/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> index 3eb6f4c..b425b95 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> @@ -17,6 +17,10 @@ Required subnode-properties:
> - softbutton-min-y : Y start of the area the softbutton area covers
> - softbutton-max-y : Y end of the area the softbutton area covers
>
> +Optional subnode-properties:
> +- linux,led-trigger : String for a LED trigger for providing visual
> + feedback that the softbutton has been pressed
This should just be a phandle to the LED if you want to describe the
link. Or standardize the trigger naming (in the kernel) for buttons and
just use the existing 'linux,default-trigger' in the LED node.
Rob
^ permalink raw reply
* [PATCH resend 1/5] input: touchscreen: Add generic touchscreen softbutton handling code
From: Rob Herring @ 2016-09-20 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911184408.11657-2-hdegoede@redhat.com>
On Sun, Sep 11, 2016 at 08:44:04PM +0200, Hans de Goede wrote:
> Some touchscreens extend over the display they cover and have a number
> of capacative softbuttons outside of the display the cover.
>
> With some hardware these softbuttons simply report touches with
> coordinates outside of the normal coordinate space for touches on the
> display.
>
> This commit adds a devicetree binding for describing such buttons in
> devicetree and a bunch of helper functions to easily add support for
> these to existing touchscreen drivers.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../bindings/input/touchscreen/softbuttons.txt | 58 +++++++++
> drivers/input/touchscreen/Makefile | 2 +-
> drivers/input/touchscreen/softbuttons.c | 145 +++++++++++++++++++++
> include/linux/input/touchscreen.h | 9 ++
> 4 files changed, 213 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> create mode 100644 drivers/input/touchscreen/softbuttons.c
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt b/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> new file mode 100644
> index 0000000..3eb6f4c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/softbuttons.txt
> @@ -0,0 +1,58 @@
> +General Touchscreen Softbutton Properties:
> +
> +Some touchscreens extend over the display they cover and have a number
> +of capacative softbuttons outside of the display the cover.
> +
> +Some of these softbuttons simply report touches with coordinates outside of
> +the normal coordinate space for touches on the display. This binding is for
> +describing such buttons in devicetree.
> +
> +Each softkey is represented as a sub-node of the touchscreen node.
> +
> +Required subnode-properties:
> + - label : Descriptive name of the key.
> + - linux,code : Keycode to emit.
> + - softbutton-min-x : X start of the area the softbutton area covers
> + - softbutton-max-x : X end of the area the softbutton area covers
> + - softbutton-min-y : Y start of the area the softbutton area covers
> + - softbutton-max-y : Y end of the area the softbutton area covers
Please add the note about these values are signed.
With that,
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH v4 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Alexander Graf @ 2016-09-20 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E12D98.6080008@arm.com>
On 09/20/2016 02:37 PM, Marc Zyngier wrote:
> On 20/09/16 13:22, Alexander Graf wrote:
>> On 09/20/2016 12:28 PM, Marc Zyngier wrote:
>>> On 20/09/16 11:05, Alexander Graf wrote:
>>>> On 09/20/2016 11:39 AM, Marc Zyngier wrote:
>>>>> On 20/09/16 10:26, Alexander Graf wrote:
>>>>>> On 20.09.16 11:21, Marc Zyngier wrote:
>>>>>>> On 19/09/16 18:39, Alexander Graf wrote:
>>>>>>>> On 19.09.16 16:48, Marc Zyngier wrote:
>>>>>>>>> On 19/09/16 12:14, Alexander Graf wrote:
>>>>>>>>>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>>>>>>>>>> handle them all using hardware acceleration through the vgic or we can emulate
>>>>>>>>>> a gic in user space and only drive CPU IRQ pins from there.
>>>>>>>>>>
>>>>>>>>>> Unfortunately, when driving IRQs from user space, we never tell user space
>>>>>>>>>> about timer events that may result in interrupt line state changes, so we
>>>>>>>>>> lose out on timer events if we run with user space gic emulation.
>>>>>>>>>>
>>>>>>>>>> This patch fixes that by routing vtimer expiration events to user space.
>>>>>>>>>> With this patch I can successfully run edk2 and Linux with user space gic
>>>>>>>>>> emulation.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> v1 -> v2:
>>>>>>>>>>
>>>>>>>>>> - Add back curly brace that got lost
>>>>>>>>>>
>>>>>>>>>> v2 -> v3:
>>>>>>>>>>
>>>>>>>>>> - Split into patch set
>>>>>>>>>>
>>>>>>>>>> v3 -> v4:
>>>>>>>>>>
>>>>>>>>>> - Improve documentation
>>>>>>>>>> ---
>>>>>>>>>> Documentation/virtual/kvm/api.txt | 30 ++++++++-
>>>>>>>>>> arch/arm/include/asm/kvm_host.h | 3 +
>>>>>>>>>> arch/arm/kvm/arm.c | 22 ++++---
>>>>>>>>>> arch/arm64/include/asm/kvm_host.h | 3 +
>>>>>>>>>> include/uapi/linux/kvm.h | 14 +++++
>>>>>>>>>> virt/kvm/arm/arch_timer.c | 125 +++++++++++++++++++++++++++-----------
>>>>>>>>>> 6 files changed, 155 insertions(+), 42 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>>>>>>>>> index 23937e0..1c0bd86 100644
>>>>>>>>>> --- a/Documentation/virtual/kvm/api.txt
>>>>>>>>>> +++ b/Documentation/virtual/kvm/api.txt
>>>>>>>>>> @@ -3202,9 +3202,14 @@ struct kvm_run {
>>>>>>>>>> /* in */
>>>>>>>>>> __u8 request_interrupt_window;
>>>>>>>>>>
>>>>>>>>>> -Request that KVM_RUN return when it becomes possible to inject external
>>>>>>>>>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>>>>>>>>>> interrupts into the guest. Useful in conjunction with KVM_INTERRUPT.
>>>>>>>>>>
>>>>>>>>>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>>>>>>>>>> +trigger forever. These lines are available:
>>>>>>>>>> +
>>>>>>>>>> + KVM_IRQWINDOW_VTIMER - Masks hw virtual timer irq while in guest
>>>>>>>>>> +
>>>>>>>>>> __u8 padding1[7];
>>>>>>>>>>
>>>>>>>>>> /* out */
>>>>>>>>>> @@ -3519,6 +3524,18 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>>>>>>>>>> event/message pages and to enable/disable SynIC messages/events processing
>>>>>>>>>> in userspace.
>>>>>>>>>>
>>>>>>>>>> + /* KVM_EXIT_ARM_TIMER */
>>>>>>>>>> + struct {
>>>>>>>>>> + __u8 timesource;
>>>>>>>>>> + } arm_timer;
>>>>>>>>>> +
>>>>>>>>>> +Indicates that a timer triggered that user space needs to handle and
>>>>>>>>>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>>>>>>>>>> +guest to proceed. This only happens for timers that got enabled through
>>>>>>>>>> +KVM_CAP_ARM_TIMER. The following time sources are available:
>>>>>>>>>> +
>>>>>>>>>> + KVM_ARM_TIMER_VTIMER - virtual cpu timer
>>>>>>>>>> +
>>>>>>>>>> /* Fix the size of the union. */
>>>>>>>>>> char padding[256];
>>>>>>>>>> };
>>>>>>>>>> @@ -3739,6 +3756,17 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>>>>>>>>>> accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>>>>>>>>>> the guest.
>>>>>>>>>>
>>>>>>>>>> +6.11 KVM_CAP_ARM_TIMER
>>>>>>>>>> +
>>>>>>>>>> +Architectures: arm, arm64
>>>>>>>>>> +Target: vcpu
>>>>>>>>>> +Parameters: args[0] contains a bitmap of timers to select (see 5.)
>>>>>>>>>> +
>>>>>>>>>> +This capability allows to route per-core timers into user space. When it's
>>>>>>>>>> +enabled and no in-kernel interrupt controller is in use, the timers selected
>>>>>>>>>> +by args[0] trigger KVM_EXIT_ARM_TIMER guest exits when they are pending,
>>>>>>>>>> +unless masked by vcpu->run->request_interrupt_window (see 5.).
>>>>>>>>>> +
>>>>>>>>>> 7. Capabilities that can be enabled on VMs
>>>>>>>>>> ------------------------------------------
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>>>>>>>>> index de338d9..77d1f73 100644
>>>>>>>>>> --- a/arch/arm/include/asm/kvm_host.h
>>>>>>>>>> +++ b/arch/arm/include/asm/kvm_host.h
>>>>>>>>>> @@ -180,6 +180,9 @@ struct kvm_vcpu_arch {
>>>>>>>>>>
>>>>>>>>>> /* Detect first run of a vcpu */
>>>>>>>>>> bool has_run_once;
>>>>>>>>>> +
>>>>>>>>>> + /* User space wants timer notifications */
>>>>>>>>>> + bool user_space_arm_timers;
>>>>>>>>> Please move this to the timer structure.
>>>>>>>> Sure.
>>>>>>>>
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>> struct kvm_vm_stat {
>>>>>>>>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>>>>>>>>> index c84b6ad..57bdb71 100644
>>>>>>>>>> --- a/arch/arm/kvm/arm.c
>>>>>>>>>> +++ b/arch/arm/kvm/arm.c
>>>>>>>>>> @@ -187,6 +187,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>>>>>>>> case KVM_CAP_ARM_PSCI_0_2:
>>>>>>>>>> case KVM_CAP_READONLY_MEM:
>>>>>>>>>> case KVM_CAP_MP_STATE:
>>>>>>>>>> + case KVM_CAP_ARM_TIMER:
>>>>>>>>>> r = 1;
>>>>>>>>>> break;
>>>>>>>>>> case KVM_CAP_COALESCED_MMIO:
>>>>>>>>>> @@ -474,13 +475,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>>>>>>>>>> return ret;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> - /*
>>>>>>>>>> - * Enable the arch timers only if we have an in-kernel VGIC
>>>>>>>>>> - * and it has been properly initialized, since we cannot handle
>>>>>>>>>> - * interrupts from the virtual timer with a userspace gic.
>>>>>>>>>> - */
>>>>>>>>>> - if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
>>>>>>>>>> - ret = kvm_timer_enable(vcpu);
>>>>>>>>>> + ret = kvm_timer_enable(vcpu);
>>>>>>>>>>
>>>>>>>>>> return ret;
>>>>>>>>>> }
>>>>>>>>>> @@ -601,6 +596,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>>>>>>>> run->exit_reason = KVM_EXIT_INTR;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> + if (kvm_check_request(KVM_REQ_PENDING_TIMER, vcpu)) {
>>>>>>>>> Since this is a very unlikely event (in the grand scheme of things), how
>>>>>>>>> about making this unlikely()?
>>>>>>>>>
>>>>>>>>>> + /* Tell user space about the pending vtimer */
>>>>>>>>>> + ret = 0;
>>>>>>>>>> + run->exit_reason = KVM_EXIT_ARM_TIMER;
>>>>>>>>>> + run->arm_timer.timesource = KVM_ARM_TIMER_VTIMER;
>>>>>>>>>> + }
>>>>>>>>> More importantly: why does it have to be indirected by a
>>>>>>>>> make_request/check_request, and not be handled as part of the
>>>>>>>>> kvm_timer_sync() call? We do update the state there, and you could
>>>>>>>>> directly find out whether an exit is required.
>>>>>>>> I can try - it seemed like it could easily become quite racy because we
>>>>>>>> call kvm_timer_sync_hwstate() at multiple places.
>>>>>>> It shouldn't. We only do it at exactly two locations (depending whether
>>>>>>> we've entered the guest or not).
>>>>>>>
>>>>>>> Also, take the following scenario:
>>>>>>> (1) guest programs the timer to expire at time T
>>>>>>> (2) guest performs an MMIO access which traps
>>>>>>> (3) during the world switch, the timer expires and we mark the timer
>>>>>>> interrupt as pending
>>>>>>> (4) we exit to handle the MMIO, no sign of the timer being pending
>>>>>>>
>>>>>>> Is the timer event lost? Or simply delayed? I think this indicates that
>>>>>>> the timer state should always be signalled to userspace, no matter what
>>>>>>> the exit reason is.
>>>>>> That's basically what I'm trying to get running right now, yes. I pushed
>>>>>> the interrupt pending status field into the kvm_sync_regs struct and
>>>>>> check it on every exit in user space - to make sure we catch pending
>>>>>> state changes before mmio reads.
>>>>>>
>>>>>> On top of that we also need a force exit event when the state changes,
>>>>>> in case there's no other event pending. Furthermore we probably want to
>>>>>> indicate the user space status of the pending bit into the kernel to not
>>>>>> exit too often.
>>>>> All you need is to do is to stash the line state in the run structure.
>>>> That's what I do now, yes. The sync_regs struct is basically an arch
>>>> specific add-on to the run structure, so we don't modify padding /
>>>> alignment with the change.
>>>>
>>>>> You shouldn't need any other information. And you trigger the exit on
>>>>> "timer line high + timer line unmasked" in order to inject the
>>>>> interrupt. Which is basically what the vgic does. It would greatly help
>>>>> if you adopted a similar behaviour.
>>>> We also need to know "timer line low + timer line masked", as otherwise
>>>> we might get spurious interrupts in the guest, no?
>>> Yes. Though you can't really know about this one, and you'll have to
>>> wait until the next natural exit to find out. As long as the spurious is
>> We can provoke a special exit for it, no?
> How? The guest decides to disable its timer. That doesn't trigger any
> exit whatsoever. You'll have to wait until the next exit from the guest
> to notice it.
Before we inject a timer interrupt, we can check whether the pending
semantics of user space / kernel space match. If they don't match, we
can exit before we inject the interrupt and allow user space to disable
the pending state again.
>
>>> "spurious in the GIC sense" (hence returning 0x3ff) and not a spurious
>>> timer interrupt being presented, you're fine.
>> Imagine
>>
>> * guest configures timer to fire
>> * kvm exits to user space because lines mismatch now
> I suppose you mean timer fired + physical interrupt for the virtual enabled?
In this scheme, I would simply say "user space thinks it's pending" ==
"host vtimer irq is masked". So because user space thinks that no timer
is pending and the guest managed to trigger a vtimer irq on the host,
the guest exited on a physical vtimer irq. Kvm then checks whether the
timer expired and sets the vcpu timer pending status to 1. User space
status is still 0, so kvm exits to user space to update the status.
>
>> * user space sets gic line up, setting vcpu irq line high
>> * guest runs, handles IRQ, calls EOI with IRQs disabled on the core
> Same thing: you mean physical interrupt for the virtual timer disabled?
> or something else?
I mean the guest sets pstate.I = 0.
>
>> * user space handles EOI, but still leaves the vcpu line high
> If there is another pending interrupt, sure. Otherwise, that's a bug.
Why is that a bug? The line really is still pending at this point.
>
>> * guest runs, sets cval, enables IRQs on the core
> What is that interrupt? Please name things, because that's very confusing.
The guest sets pstate.I=1.
>
>> * kvm injects a timer interrupt into the guest
> Why? Has the timer fired?
cntv.ctl.imask = 0 here, but user space doesn't know that yet. So the
"pending" state is still active.
>
>> At this point, the pending state from user space is bogus, as the line
>> really isn't pending anymore. However, when the guest asks the GIC at
>> that point what interrupt is pending, the line down state will have
>> populated into user space before the mmio request gets processed. So you
>> will see a 0x3ff return I guess.
>>
>> Is that reasonable?
> I'm sorry, but you need to put names on things and precisely describe
> the various events. because from the above script, I can derive twenty
> different scenarios...
I'm sure one of them has to be racy? :)
(in fact, there are probably more than what I came up with that really
are...)
Alex
^ permalink raw reply
* [PATCH v2 2/6] Documentation: dt-bindings: Add documentation for the Meson USB2 PHYs
From: Rob Herring @ 2016-09-20 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911134111.31141-3-martin.blumenstingl@googlemail.com>
On Sun, Sep 11, 2016 at 03:41:07PM +0200, Martin Blumenstingl wrote:
> Add the documentation for the bindings for the Meson8b and GXBB USB2
> PHYs.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> .../devicetree/bindings/phy/meson-usb2-phy.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
> new file mode 100644
> index 0000000..9da5ea2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
> @@ -0,0 +1,27 @@
> +* Amlogic USB2 PHY
> +
> +Required properties:
> +- compatible: Depending on the platform this should be one of:
> + "amlogic,meson8b-usb2-phy"
> + "amlogic,meson-gxbb-usb2-phy"
> +- reg: The base address and length of the registers
> +- #phys-cells: should be 0 (see phy-bindings.txt in this directory)
> +- clocks: phandle and clock identifier for the phy clocks
> +- clock-names: "usb_general" and "usb"
> +
> +Optional properties:
> +- resets: reference to the reset controller
> +- phy-supply: see phy-bindings.txt in this directory
> +
> +
> +Example:
> +
> +usb0_phy: usb_phy at 0 {
usb-phy at 0
With that,
Acked-by: Rob Herring <robh@kernel.org>
> + compatible = "amlogic,meson-gxbb-usb2-phy";
> + #phy-cells = <0>;
> + reg = <0x0 0x0 0x0 0x20>;
> + resets = <&reset RESET_USB_OTG>;
> + clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB0>;
> + clock-names = "usb_general", "usb";
> + phy-supply = <&usb_vbus>;
> +};
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v2 1/6] usb: dwc2: add support for Meson8b and GXBB SoCs
From: Rob Herring @ 2016-09-20 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911134111.31141-2-martin.blumenstingl@googlemail.com>
On Sun, Sep 11, 2016 at 03:41:06PM +0200, Martin Blumenstingl wrote:
> From: Jerome Brunet <jbrunet@baylibre.com>
>
> Add compatible strings for amlogic Meson8b and GXBB SoCs with the
> corresponding configuration parameters.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/usb/dwc2/platform.c | 34 ++++++++++++++++++++++++++
> 2 files changed, 36 insertions(+)
^ permalink raw reply
* [PATCH v2 1/2] Documentation: dt: add bindings for ti-cpufreq
From: Dave Gerlach @ 2016-09-20 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919211400.GA4276@rob-hp-laptop>
Rob,
On 09/19/2016 04:14 PM, Rob Herring wrote:
> On Wed, Aug 31, 2016 at 09:53:27PM -0500, Dave Gerlach wrote:
>> Add the device tree bindings document for the TI CPUFreq/OPP driver
>> on AM33xx, AM43xx, DRA7, and AM57 SoCs. The operating-points-v2 binding
>> allows us to provide an opp-supported-hw property for each OPP to define
>> when it is available. This driver is responsible for reading and parsing
>> registers to determine which OPPs can be selectively enabled based
>> on the specific SoC in use by matching against the opp-supported-hw
>> data.
>
> Sorry, for the delay. Missed this somehow.
>
>>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> v1->v2:
>> - Dropped all driver/linux specific documentation
>> - Fixed some typos
>> - Add new compatibles for each SoC family to match against
>> - Switched to use am335x example to better demonstrate field one of
>> opp-supported-hw.
>>
>> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 130 +++++++++++++++++++++
>> 1 file changed, 130 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>> new file mode 100644
>> index 000000000000..6276ae494121
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>> @@ -0,0 +1,130 @@
>> +TI CPUFreq and OPP bindings
>> +================================
>> +
>> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
>> +families support different OPPs depending on the silicon variant in use.
>> +The ti_cpufreq driver can use revision and an efuse value from the SoC to
>> +provide the OPP framework with supported hardware information. This is
>> +used to determine which OPPs from the operating-points-v2 table get enabled
>> +when it is parsed by the OPP framework.
>> +
>> +Required properties:
>> +--------------------
>> +In 'cpus' nodes:
>> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
>> +- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
>> + mask, and efuse register shift to get the relevant bits
>> + that describe OPP availability.
>> +- ti,syscon-rev: Syscon and offset used to look up revision value on SoC.
>
> These have nothing to do with a cpu, so they don't belong here. Maybe
> the first is a property of an OPP table, but the second certainly is
> not.
Yes, I have no issue with this and will move the ti properties into the
operating points table for v3 of the series.
>
>> +
>> +In 'operating-points-v2' table:
>> +- compatible: Should be
>> + - 'operating-points-v2-ti-am3352-cpu' for am335x SoCs
>> + - 'operating-points-v2-ti-am4372-cpu' for am43xx SoCs
>> + - 'operating-points-v2-ti-dra7-cpu' for dra7xx/am57xx SoCs
>> +
>> +- opp-supported-hw: Two bitfields indicating:
>> + 1. Which revision of the SoC the OPP is supported by
>> + 2. Which eFuse bits indicate this OPP is available
>
> I tend to think you should handle this with kernel code (bootloader
> really) fixing up the OPP table as necessary rather than putting in DT.
>
The operating-points-v2 binding here [1] was designed with doing this in
mind, and others are using it and the corresponding functionality
offered by the OPP core to selectively enable OPPs. Why hide this in
u-boot when we already have kernel framework support to do it?
Thanks for your comments, will send v3 moving the appropriate properties
into the OPP table.
Regards,
Dave
[1] Documentation/devicetree/bindings/opp/opp.txt
> Rob
>
^ 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