* [PATCH -next] net: ethernet: mediatek: use dev_kfree_skb_any instead of dev_kfree_skb
From: Wei Yongjun @ 2016-10-20 17:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Replace dev_kfree_skb with dev_kfree_skb_any in mtk_start_xmit()
which can be called from hard irq context (netpoll) and from
other contexts. mtk_start_xmit() only frees skbs that it has
dropped.
This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8f80e61..d716274 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -843,7 +843,7 @@ static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
drop:
spin_unlock(ð->page_lock);
stats->tx_dropped++;
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
^ permalink raw reply related
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Gottfried Haider @ 2016-10-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb++5Xb6a=0Zz5eZURNmrkfVyvsBR-pLK9iRiyTu1g8Rw@mail.gmail.com>
> The old sysfs interface is not changing. However it is deprecated so once
> you have a v4.8+ kernel, consider migrating whatever userspace you have
> to use the chardev ABI instead.
>
> See:
> commit fe95046e960b4b76e73dc1486955d93f47276134
> "gpio: ABI: mark the sysfs ABI as obsolete"
> commit 521a2ad6f862a28e2e43cb3e254a26bf0f9452e9
> "gpio: add userspace ABI for GPIO line information"
> commit d7c51b47ac11e66f547b55640405c1c474642d72
> "gpio: userspace ABI for reading/writing GPIO lines"
> commit 61f922db72216b00386581c851db9c9095961522
> "gpio: userspace ABI for reading GPIO line events"
Thanks for those pointers. Somewhat off topic: is it planned to add
support for setting GENERIC_PINCONF style pull-up/pull-down resistors
throigh the new ABI? (The bcm28xx drivers would still need to
converted to this as well.)
>> Regarding the proposed format using the header pin numbers: From what I've
>> seen in terms of existing educational materials, it seems the overwhelming
>> majority ends up using GPIO numbers instead of physical pin header
>> numbering. (e.g. [1] [2])
>
> What does that number mean? If you are referring to the global
> GPIO numberspace it is obsolete and just reflecting the fact that
> people up until now was referring to Linux-internal GPIO numbers.
I am referring to the name of the various GPIO lines as per datasheet
("GPIO0", "GPIO1", ...). So far, I believe those matched the global
GPIO numberspace.
>> Would it be too confusing to try to pick GPIO 5 from an alphabetically
>> sorted list like this "P11_GPIO17", "P12_GPIO18"? (I know, alphabetical
>> sorting is an issue here already for a different reason. But applications
>> might do it, I guess?)
>
> Any attempt to preserve the global GPIO numberspace is futile.
> If it is the local offset number on the chip it is another thing, that
> is kind of OK if the arch maintainer likes it.
I understand that Linux can't guarantee a certain global GPIO number -
but I fear that the board manufacturers also might not think of the
pin headers as something set in stone (that the can't rearrange in a
future revision/product).
Would there be a reason against _naming_ the pin "GPIO0"? (even if it
ends up with a different global, internal number)
Thanks & best
Gottfried
^ permalink raw reply
* [PATCH v14 5/9] clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
From: Mark Rutland @ 2016-10-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475086637-1914-6-git-send-email-fu.wei@linaro.org>
On Thu, Sep 29, 2016 at 02:17:13AM +0800, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> The patch update arm_arch_timer driver to use the function
> provided by the new GTDT driver of ACPI.
> By this way, arm_arch_timer.c can be simplified, and separate
> all the ACPI GTDT knowledge from this timer driver.
>
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
This generally looks fine, but:
> + arch_timer_ppi[PHYS_SECURE_PPI] = acpi_gtdt_map_ppi(PHYS_SECURE_PPI);
As mentioned on the prior patch, I think we shouldn't bother parsing the
secure interrupt, given the problem with the GSIV, and the fact that we
shouldn't need it in Linux.
> + arch_timer_ppi[PHYS_NONSECURE_PPI] = acpi_gtdt_map_ppi(PHYS_NONSECURE_PPI);
> + arch_timer_ppi[VIRT_PPI] = acpi_gtdt_map_ppi(VIRT_PPI);
> + arch_timer_ppi[HYP_PPI] = acpi_gtdt_map_ppi(HYP_PPI);
> + /* Always-on capability */
> + arch_timer_c3stop = acpi_gtdt_c3stop();
... I think we should check the flag on the relevant interrupt, though
that's worth clarifying.
>
> - /* Always-on capability */
> - arch_timer_c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
> + if (timer_count < 0)
> + pr_err("Failed to get platform timer info.\n");
Why don't we log this in the code that would try to initialise the MMIO
timer? We can still fail after this.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Kevin Hilman @ 2016-10-20 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2278105.geKhb8xoNC@avalon>
+Arnd, Olof
Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:
> Hi Bartosz,
>
> On Wednesday 19 Oct 2016 10:26:57 Bartosz Golaszewski wrote:
>> 2016-10-18 22:49 GMT+02:00 Laurent Pinchart:
>> > On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote:
>> >> Create the driver for the da8xx System Configuration and implement
>> >> support for writing to the three Master Priority registers.
>> >>
>> >> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> [snip]
>>
>> >> +
>> >> +Documentation:
>> >> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> >> +
>> >> +Required properties:
>> >> +
>> >> +- compatible: "ti,da850-syscfg"
>> >
>> > Don't you need a reg property ?
>>
>> Yes, Kevin already pointed that out. I'll add it in v2. Same for [1/3].
>>
>> >> +Optional properties:
>> >> +
>> >> +The below properties are used to specify the priority of master
>> >> peripherals.
>> >> +They must be between 0-7 where 0 is the highest priority and 7 is the
>> >> lowest.
>> >> +
>> >> +- ti,pri-arm-i: ARM_I port priority.
>> >> +
>> >> +- ti,pri-arm-d: ARM_D port priority.
>> >> +
>> >> +- ti,pri-upp: uPP port priority.
>> >> +
>> >> +- ti,pri-sata: SATA port priority.
>> >> +
>> >> +- ti,pri-pru0: PRU0 port priority.
>> >> +
>> >> +- ti,pri-pru1: PRU1 port priority.
>> >> +
>> >> +- ti,pri-edma30tc0: EDMA3_0_TC0 port priority.
>> >> +
>> >> +- ti,pri-edma30tc1: EDMA3_0_TC1 port priority.
>> >> +
>> >> +- ti,pri-edma31tc0: EDMA3_1_TC0 port priority.
>> >> +
>> >> +- ti,pri-vpif-dma-0: VPIF DMA0 port priority.
>> >> +
>> >> +- ti,pri-vpif-dma-1: VPIF DMA1 port priority.
>> >> +
>> >> +- ti,pri-emac: EMAC port priority.
>> >> +
>> >> +- ti,pri-usb0cfg: USB0 CFG port priority.
>> >> +
>> >> +- ti,pri-usb0cdma: USB0 CDMA port priority.
>> >> +
>> >> +- ti,pri-uhpi: HPI port priority.
>> >> +
>> >> +- ti,pri-usb1: USB1 port priority.
>> >> +
>> >> +- ti,pri-lcdc: LCDC port priority.
>> >
>> > I'm afraid this looks more like system configuration than hardware
>> > description to me.
>>
>> While you're certainly right, this approach is already implemented in
>> several other memory and bus drivers and it was also suggested by
>> Sekhar in one of the tilcdc rev1 threads. There's also no real
>> alternative that I know of.
>
> The fact that other drivers get it wrong is no excuse for copying them :-)
What exactly is "wrong" with the way other drivers are doing it?
I'm sure there may be other ideas, and possibly some better ones, but
that doesn't make it wrong, and doesn't change he fact that the kernel
has existing drivers SoC-bus-specific system performance knobs like
this.
>> > There was a BoF session about how to support this kind of performance
>> > knobs at ELCE last week:
>> > https://openiotelceurope2016.sched.org/event/7rss/bof-linux-device-perfor
>> > mance-framework-michael-turquette-baylibre :-)
>>
>> Unfortunately it was just a discussion about potential approaches -
>> there's no code yet.
>
> Patches are welcome ;-)
Any generic perf framework will have to build on the HW-specifics of
individual busses, so IMO, the lack of a generic performance
framework/knobs should not be a reason to block the inclusion of any
bus-specific knobs.
I guess this ultimately would go though arm-soc, so I've added Arnd &
Olof to the thread.
Kevin
^ permalink raw reply
* [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Lorenzo Pieralisi @ 2016-10-20 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476812509-2760-2-git-send-email-agustinv@codeaurora.org>
Hi Agustin,
On Tue, Oct 18, 2016 at 01:41:48PM -0400, Agustin Vega-Frias wrote:
> This allows irqchip drivers to associate an ACPI DSDT device to
> an IRQ domain and provides support for using the ResourceSource
> in Extended IRQ Resources to find the domain and map the IRQs
> specified on that domain.
>
> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> ---
> drivers/acpi/Makefile | 1 +
> drivers/acpi/irqdomain.c | 141 ++++++++++++++++++++++++++++++++++++++
> drivers/acpi/resource.c | 21 +++---
> include/asm-generic/vmlinux.lds.h | 1 +
> include/linux/acpi.h | 71 +++++++++++++++++++
> include/linux/irqchip.h | 17 ++++-
> 6 files changed, 240 insertions(+), 12 deletions(-)
> create mode 100644 drivers/acpi/irqdomain.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 9ed0878..880401b 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
> acpi-y += acpi_lpat.o
> acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
> acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
> +acpi-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
>
> # These are (potentially) separate modules
>
> diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
> new file mode 100644
> index 0000000..c53b9f4
> --- /dev/null
> +++ b/drivers/acpi/irqdomain.c
> @@ -0,0 +1,141 @@
> +/*
> + * ACPI ResourceSource/IRQ domain mapping support
> + *
> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include <linux/acpi.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +
> +/**
> + * acpi_irq_domain_ensure_probed() - Check if the device has registered
> + * an IRQ domain and probe as necessary
> + *
> + * @device: Device to check and probe
> + *
> + * Returns: 0 on success, -ENODEV otherwise
This is not correct (ie it depends on what
struct acpi_dsdt_probe_entry.probe
returns) and I would like to take this nit as an opportunity
to take a step back and ask you a question below.
> + */
> +static int acpi_irq_domain_ensure_probed(struct acpi_device *device)
> +{
> + struct acpi_dsdt_probe_entry *entry;
> +
> + if (irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY) != 0)
> + return 0;
> +
> + for (entry = &__dsdt_acpi_probe_table;
> + entry < &__dsdt_acpi_probe_table_end; entry++)
> + if (strcmp(entry->_hid, acpi_device_hid(device)) == 0)
> + return entry->probe(device);
Through this approch we are forcing an irqchip (that by the way it
has a physical node ACPI companion by being a DSDT device object so it
could be managed by a platform driver) to be probed. The question is: is
there a reason (apart from the current ACPI resource parsing API) why
this can't be implemented through deferred probing and the device
dependencies framework Rafael is working on:
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1246897.html
The DT layer, through the of_irq_get() API, supports probe deferral
and what I am asking you is if there is any blocking point (again,
apart from the current ACPI API) to implement the same mechanism.
I have not reviewed the previous versions so I am certainly missing
some of the bits and pieces already discussed, apologies for that.
Thanks,
Lorenzo
> +
> + return -ENODEV;
> +}
> +
> +/**
> + * acpi_irq_domain_register_irq() - Register the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + * @trigger: trigger type of the IRQ number to be mapped
> + * @polarity: polarity of the IRQ to be mapped
> + *
> + * Returns: a valid linux IRQ number on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EPROBE_DEFER if the IRQ domain has not been registered
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_register_irq(const struct acpi_resource_source *source,
> + u32 hwirq, int trigger, int polarity)
> +{
> + struct irq_fwspec fwspec;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret;
> +
> + /* An empty acpi_resource_source means it is a GSI */
> + if (!source->string_length)
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + ret = acpi_irq_domain_ensure_probed(device);
> + if (ret)
> + goto out_put_device;
> +
> + fwspec.fwnode = &device->fwnode;
> + fwspec.param[0] = hwirq;
> + fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
> + fwspec.param_count = 2;
> +
> + ret = irq_create_fwspec_mapping(&fwspec);
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
> +
> +/**
> + * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + *
> + * Returns: 0 on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source *source,
> + u32 hwirq)
> +{
> + struct irq_domain *domain;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret = 0;
> +
> + if (!source->string_length) {
> + acpi_unregister_gsi(hwirq);
> + return 0;
> + }
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + domain = irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY);
> + if (!domain) {
> + ret = -EINVAL;
> + goto out_put_device;
> + }
> +
> + irq_dispose_mapping(irq_find_mapping(domain, hwirq));
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_unregister_irq);
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..3fb7abf 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -381,14 +381,15 @@ static void acpi_dev_irqresource_disabled(struct resource *res, u32 gsi)
> res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> }
>
> -static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> +static void acpi_dev_get_irqresource(struct resource *res, u32 hwirq,
> + const struct acpi_resource_source *source,
> u8 triggering, u8 polarity, u8 shareable,
> bool legacy)
> {
> int irq, p, t;
>
> - if (!valid_IRQ(gsi)) {
> - acpi_dev_irqresource_disabled(res, gsi);
> + if ((source->string_length == 0) && !valid_IRQ(hwirq)) {
> + acpi_dev_irqresource_disabled(res, hwirq);
> return;
> }
>
> @@ -402,25 +403,25 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> * using extended IRQ descriptors we take the IRQ configuration
> * from _CRS directly.
> */
> - if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
> + if (legacy && !acpi_get_override_irq(hwirq, &t, &p)) {
> u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
> u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>
> if (triggering != trig || polarity != pol) {
> - pr_warning("ACPI: IRQ %d override to %s, %s\n", gsi,
> - t ? "level" : "edge", p ? "low" : "high");
> + pr_warn("ACPI: IRQ %d override to %s, %s\n", hwirq,
> + t ? "level" : "edge", p ? "low" : "high");
> triggering = trig;
> polarity = pol;
> }
> }
>
> res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> - irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
> + irq = acpi_irq_domain_register_irq(source, hwirq, triggering, polarity);
> if (irq >= 0) {
> res->start = irq;
> res->end = irq;
> } else {
> - acpi_dev_irqresource_disabled(res, gsi);
> + acpi_dev_irqresource_disabled(res, hwirq);
> }
> }
>
> @@ -446,6 +447,7 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> struct resource *res)
> {
> + const struct acpi_resource_source dummy = { 0, 0, NULL };
> struct acpi_resource_irq *irq;
> struct acpi_resource_extended_irq *ext_irq;
>
> @@ -460,7 +462,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> acpi_dev_irqresource_disabled(res, 0);
> return false;
> }
> - acpi_dev_get_irqresource(res, irq->interrupts[index],
> + acpi_dev_get_irqresource(res, irq->interrupts[index], &dummy,
> irq->triggering, irq->polarity,
> irq->sharable, true);
> break;
> @@ -471,6 +473,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> return false;
> }
> acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
> + &ext_irq->resource_source,
> ext_irq->triggering, ext_irq->polarity,
> ext_irq->sharable, false);
> break;
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 3074796..f808afdc 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -563,6 +563,7 @@
> IRQCHIP_OF_MATCH_TABLE() \
> ACPI_PROBE_TABLE(irqchip) \
> ACPI_PROBE_TABLE(clksrc) \
> + ACPI_PROBE_TABLE(dsdt) \
> EARLYCON_TABLE()
>
> #define INIT_TEXT \
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index ddbeda6..bb1a838 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -26,6 +26,7 @@
> #include <linux/resource_ext.h>
> #include <linux/device.h>
> #include <linux/property.h>
> +#include <linux/irqdomain.h>
>
> #ifndef _LINUX
> #define _LINUX
> @@ -321,6 +322,31 @@ void acpi_set_irq_model(enum acpi_irq_model_id model,
> */
> void acpi_unregister_gsi (u32 gsi);
>
> +#ifdef CONFIG_IRQ_DOMAIN
> +
> +int acpi_irq_domain_register_irq(const struct acpi_resource_source *source,
> + u32 hwirq, int trigger, int polarity);
> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source *source,
> + u32 hwirq);
> +
> +#else
> +
> +static inline int acpi_irq_domain_register_irq(
> + const struct acpi_resource_source *source, u32 hwirq, int trigger,
> + int polarity)
> +{
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +}
> +
> +static inline int acpi_irq_domain_unregister_irq(
> + const struct acpi_resource_source *source, u32 hwirq)
> +{
> + acpi_unregister_gsi(hwirq);
> + return 0;
> +}
> +
> +#endif /* CONFIG_IRQ_DOMAIN */
> +
> struct pci_dev;
>
> int acpi_pci_irq_enable (struct pci_dev *dev);
> @@ -1024,6 +1050,34 @@ struct acpi_probe_entry {
> (&ACPI_PROBE_TABLE_END(t) - \
> &ACPI_PROBE_TABLE(t))); \
> })
> +
> +/* Length of Hardware ID field in DSDT entries as per ACPI spec */
> +#define ACPI_HID_LEN 9
> +
> +typedef int (*acpi_dsdt_handler)(struct acpi_device *);
> +
> +/**
> + * struct acpi_probe_dsdt_entry - boot-time probing entry for DSDT devices
> + * @hid: _HID of the device
> + * @fn: Callback to the driver being probed
> + * @driver_data: Sideband data provided back to the driver
> + */
> +struct acpi_dsdt_probe_entry {
> + __u8 _hid[ACPI_HID_LEN];
> + acpi_dsdt_handler probe;
> +};
> +
> +#define ACPI_DECLARE_DSDT_PROBE_ENTRY(name, hid, fn) \
> + static const struct acpi_dsdt_probe_entry __acpi_probe_##name \
> + __used __section(__dsdt_acpi_probe_table) = \
> + { \
> + ._hid = hid, \
> + .probe = fn, \
> + }
> +
> +extern struct acpi_dsdt_probe_entry __dsdt_acpi_probe_table;
> +extern struct acpi_dsdt_probe_entry __dsdt_acpi_probe_table_end;
> +
> #else
> static inline int acpi_dev_get_property(struct acpi_device *adev,
> const char *name, acpi_object_type type,
> @@ -1101,8 +1155,25 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
> (void *) data }
>
> #define acpi_probe_device_table(t) ({ int __r = 0; __r;})
> +
> +#define ACPI_DECLARE_DSDT_PROBE_ENTRY(name, hid, fn) \
> + static const void *__acpi_probe_##name[] \
> + __attribute__((unused)) \
> + = { (void *) hid, \
> + (void *) fn }
> +
> #endif
>
> +#define MADT_IRQCHIP_ACPI_DECLARE(name, subtable, validate, data, fn) \
> + ACPI_DECLARE_PROBE_ENTRY(irqchip, name, ACPI_SIG_MADT, \
> + subtable, validate, data, fn)
> +
> +#define DSDT_IRQCHIP_ACPI_DECLARE(name, hid, fn) \
> + ACPI_DECLARE_DSDT_PROBE_ENTRY(name, hid, fn)
> +
> +#define __IRQCHIP_ACPI_DECLARE(_a1, _a2, _a3, _a4, _a5, type, ...) \
> + type##_IRQCHIP_ACPI_DECLARE
> +
> #ifdef CONFIG_ACPI_TABLE_UPGRADE
> void acpi_table_upgrade(void);
> #else
> diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
> index 89c34b2..c2d0c12 100644
> --- a/include/linux/irqchip.h
> +++ b/include/linux/irqchip.h
> @@ -29,6 +29,10 @@
> /*
> * This macro must be used by the different irqchip drivers to declare
> * the association between their version and their initialization function.
> + * Two syntaxes are supported depending on the table where the irqchip device
> + * is declared:
> + *
> + * - MADT irqchip syntax, which requires the following five arguments:
> *
> * @name: name that must be unique accross all IRQCHIP_ACPI_DECLARE of the
> * same file.
> @@ -37,10 +41,17 @@
> * Can be NULL.
> * @data: data to be checked by the validate function.
> * @fn: initialization function
> + *
> + * - DSDT irqchip syntax, which requires the following three arguments:
> + *
> + * @name: name that must be unique across all IRQCHIP_ACPI_DECLARE of the
> + * same file.
> + * @hid: _HID of the DSDT device
> + * @fn: initialization function
> */
> -#define IRQCHIP_ACPI_DECLARE(name, subtable, validate, data, fn) \
> - ACPI_DECLARE_PROBE_ENTRY(irqchip, name, ACPI_SIG_MADT, \
> - subtable, validate, data, fn)
> +
> +#define IRQCHIP_ACPI_DECLARE(...) \
> + __IRQCHIP_ACPI_DECLARE(__VA_ARGS__, MADT, _unused, DSDT)(__VA_ARGS__)
>
> #ifdef CONFIG_IRQCHIP
> void irqchip_init(void);
> --
> Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
>
> --
> 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 V6 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Vinod Koul @ 2016-10-20 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e3cbd6a2-7fac-98ec-74ea-0be88075663c@codeaurora.org>
On Thu, Oct 20, 2016 at 07:06:08AM -0700, Sinan Kaya wrote:
> Hi Vinod,
>
> On 10/20/2016 2:48 AM, Vinod Koul wrote:
> >> 6:
> >> > * rebase 4.9 kernel
> > Why???
> >
>
> This is more for me. There is nothing special about 4.9 that impacts hidma.
> It just means that I retested the code against 4.9-rc1 kernel.
>
> >
> > I already told you that I have applied 6 in the last version, please dont
> > send me stuff which is already applied :(
>
> I couldn't find your applied branch on git yesterday. That's why, I sent you
> the whole thing so that you can pick the last 4 ones. You don't need to reapply
> the first 6. Better to have everything than missing code.
>
> slave-dma git://git.infradead.org/users/vkoul/slave-dma.git (fetch)
> slave-dma git://git.infradead.org/users/vkoul/slave-dma.git (push)
You seem to have missed topic/qcom which I pushed last night. next would have worked too!!
> If you prefer a reduced list, please make your current changelist available on
> one of the branches on git, I can reapply, test and send only the remaining ones.
>
> Sinan
>
> --
> Sinan Kaya
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
--
~Vinod
^ permalink raw reply
* [PATCH v14 4/9] acpi/arm64: Add GTDT table parse driver
From: Mark Rutland @ 2016-10-20 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475086637-1914-5-git-send-email-fu.wei@linaro.org>
Hi,
As a heads-up, on v4.9-rc1 I see conflicts at least against
arch/arm64/Kconfig. Luckily git am -3 seems to be able to fix that up
automatically, but this will need to be rebased before the next posting
and/or merging.
On Thu, Sep 29, 2016 at 02:17:12AM +0800, fu.wei at linaro.org wrote:
> +static int __init map_gt_gsi(u32 interrupt, u32 flags)
> +{
> + int trigger, polarity;
> +
> + if (!interrupt)
> + return 0;
Urgh.
Only the secure interrupt (which we do not need) is optional in this
manner, and (hilariously), zero appears to also be a valid GSIV, per
figure 5-24 in the ACPI 6.1 spec.
So, I think that:
(a) we should not bother parsing the secure interrupt
(b) we should drop the check above
(c) we should report the spec issue to the ASWG
> +/*
> + * acpi_gtdt_c3stop - got c3stop info from GTDT
> + *
> + * Returns 1 if the timer is powered in deep idle state, 0 otherwise.
> + */
> +bool __init acpi_gtdt_c3stop(void)
> +{
> + struct acpi_table_gtdt *gtdt = acpi_gtdt_desc.gtdt;
> +
> + return !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
> +}
It looks like this can differ per interrupt. Shouldn't we check the
appropriate one?
> +int __init acpi_gtdt_init(struct acpi_table_header *table)
> +{
> + void *start;
> + struct acpi_table_gtdt *gtdt;
> +
> + gtdt = container_of(table, struct acpi_table_gtdt, header);
> +
> + acpi_gtdt_desc.gtdt = gtdt;
> + acpi_gtdt_desc.gtdt_end = (void *)table + table->length;
> +
> + if (table->revision < 2) {
> + pr_debug("Revision:%d doesn't support Platform Timers.\n",
> + table->revision);
> + return 0;
> + }
> +
> + if (!gtdt->platform_timer_count) {
> + pr_debug("No Platform Timer.\n");
> + return 0;
> + }
> +
> + start = (void *)gtdt + gtdt->platform_timer_offset;
> + if (start < (void *)table + sizeof(struct acpi_table_gtdt)) {
> + pr_err(FW_BUG "Failed to retrieve timer info from firmware: invalid data.\n");
> + return -EINVAL;
> + }
> + acpi_gtdt_desc.platform_timer_start = start;
> +
> + return gtdt->platform_timer_count;
> +}
This is never used as anything other than a status code.
Just return zero; we haven't parsed the platform timers themselves at
this point anyway.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] arm64: Add support for additional relocations in the kexec purgatory code
From: Geoff Levand @ 2016-10-20 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476960211-25594-1-git-send-email-catalin.marinas@arm.com>
On 10/20/2016 03:43 AM, Catalin Marinas wrote:
> When compiling the kexec-tools with gcc6, the following additional
> reolcations are generated in the purgatory.ro file:
>
> R_AARCH64_ADR_PREL_PG_HI21
> R_AARCH64_ADD_ABS_LO12_NC
> R_AARCH64_LDST64_ABS_LO12_NC
Looks good. Simon, please apply.
Reviewed-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* [PATCH v2 6/9] ARM64: meson: enable MESON_IRQ_GPIO in Kconfig
From: Marc Zyngier @ 2016-10-20 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476890480-8884-7-git-send-email-jbrunet@baylibre.com>
On 19/10/16 16:21, Jerome Brunet wrote:
> Add select MESON_IRQ_GPIO in Kconfig for Amlogic's meson SoC family
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> arch/arm64/Kconfig.platforms | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index cfbdf02ef566..846479d4492d 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -95,6 +95,7 @@ config ARCH_MESON
> select PINCTRL_MESON
> select COMMON_CLK_AMLOGIC
> select COMMON_CLK_GXBB
> + select MESON_GPIO_IRQ
MESON_IRQ_GPIO?
> help
> This enables support for the Amlogic S905 SoCs.
>
>
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 1/9] irqchip: meson: add support for gpio interrupt controller
From: Marc Zyngier @ 2016-10-20 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476890480-8884-2-git-send-email-jbrunet@baylibre.com>
Jerome,
On 19/10/16 16:21, Jerome Brunet wrote:
> Add support for the interrupt gpio controller found on Amlogic's meson
> SoC family.
>
> Unlike what the IP name suggest, it is not directly linked to the gpio
> subsystem. It is actually an independent IP that is able to spy on the
> SoC pad. For that purpose, it can mux and filter (edge or level and
> polarity) any single SoC pad to one of the 8 GIC's interrupts it owns.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/irqchip/Kconfig | 9 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-meson-gpio.c | 423 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 433 insertions(+)
> create mode 100644 drivers/irqchip/irq-meson-gpio.c
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 82b0b5daf3f5..168837263e80 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -279,3 +279,12 @@ config EZNPS_GIC
> config STM32_EXTI
> bool
> select IRQ_DOMAIN
> +
> +config MESON_GPIO_IRQ
> + bool "Meson GPIO Interrupt Multiplexer"
> + depends on ARCH_MESON || COMPILE_TEST
> + select IRQ_DOMAIN
> + select IRQ_DOMAIN_HIERARCHY
> + help
> + Support Meson SoC Family GPIO Interrupt Multiplexer
> +
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index e4dbfc85abdb..33f913d037d0 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -74,3 +74,4 @@ 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
> +obj-$(CONFIG_MESON_GPIO_IRQ) += irq-meson-gpio.o
> diff --git a/drivers/irqchip/irq-meson-gpio.c b/drivers/irqchip/irq-meson-gpio.c
> new file mode 100644
> index 000000000000..869b4df8c483
> --- /dev/null
> +++ b/drivers/irqchip/irq-meson-gpio.c
> @@ -0,0 +1,423 @@
> +/*
> + * Copyright (c) 2015 Endless Mobile, Inc.
> + * Author: Carlo Caione <carlo@endlessm.com>
> + * Copyright (c) 2016 BayLibre, SAS.
> + * Author: Jerome Brunet <jbrunet@baylibre.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see <http://www.gnu.org/licenses/>.
> + * The full GNU General Public License is included in this distribution
> + * in the file called COPYING.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/irqchip.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +
> +#define IRQ_FREE (-1)
> +
> +#define REG_EDGE_POL 0x00
> +#define REG_PIN_03_SEL 0x04
> +#define REG_PIN_47_SEL 0x08
> +#define REG_FILTER_SEL 0x0c
> +
> +#define REG_EDGE_POL_MASK(x) (BIT(x) | BIT(16 + (x)))
> +#define REG_EDGE_POL_EDGE(x) BIT(x)
> +#define REG_EDGE_POL_LOW(x) BIT(16 + (x))
> +#define REG_PIN_SEL_SHIFT(x) (((x) % 4) * 8)
> +#define REG_FILTER_SEL_SHIFT(x) ((x) * 4)
> +
> +struct meson_gpio_irq_params {
> + unsigned int nhwirq;
> + irq_hw_number_t *source;
> + int nsource;
> +};
> +
> +struct meson_gpio_irq_domain {
The name of that structure is utterly confusing, as it doesn't contain
anything related to an IRQ domain. Can you please clarify its usage?
> + void __iomem *base;
> + int *map;
> + const struct meson_gpio_irq_params *params;
> +};
> +
> +struct meson_gpio_irq_chip_data {
> + void __iomem *base;
> + int index;
> +};
> +
> +static irq_hw_number_t meson_parent_hwirqs[] = {
> + 64, 65, 66, 67, 68, 69, 70, 71,
> +};
If that a guarantee that these numbers will always represent the parent
interrupt? It feels a bit odd not to get that information directly from
the device tree, in the form of a device specific property. Something like:
upstream-interrupts = <64 65 66 ... >;
or even as a base/range:
upstream-interrupts = <64 8>;
Also, how does it work if you have more than a single device like this?
This driver seems a do a great deal of dynamic allocation, and yet its
core resource is completely static... Please pick a side! ;-)
> +
> +static const struct meson_gpio_irq_params meson8_params = {
> + .nhwirq = 134,
> + .source = meson_parent_hwirqs,
> + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
I find it utterly confusing that you are calling source something that
is an output for this controller. It makes my brain melt, and I don't
like the feeling.
> +};
> +
> +static const struct meson_gpio_irq_params meson8b_params = {
> + .nhwirq = 119,
> + .source = meson_parent_hwirqs,
> + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
> +};
> +
> +static const struct meson_gpio_irq_params meson_gxbb_params = {
> + .nhwirq = 133,
> + .source = meson_parent_hwirqs,
> + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
> +};
Same thing. How big is the variability of these structures? Are we going
to see more of those? or is that now set into stone?
+Mark: what's the policy to describe this kind of things?
> +
> +static const struct of_device_id meson_irq_gpio_matches[] = {
> + {
> + .compatible = "amlogic,meson8-gpio-intc",
If it's an independent IP (as described in the commit message),
shouldn't in be rescribed in a more SoC-independent way?
> + .data = &meson8_params
> + },
> + {
> + .compatible = "amlogic,meson8b-gpio-intc",
> + .data = &meson8b_params
> + },
> + {
> + .compatible = "amlogic,meson-gxbb-gpio-intc",
> + .data = &meson_gxbb_params
> + },
> + {}
> +};
> +
> +static void meson_gpio_irq_update_bits(void __iomem *base, unsigned int reg,
> + u32 mask, u32 val)
> +{
> + u32 tmp;
> +
> + tmp = readl(base + reg);
> + tmp &= ~mask;
> + tmp |= val;
> +
> + writel(tmp, base + reg);
Can't you use the relaxed accessors?
> +}
> +
> +static int meson_gpio_irq_get_index(struct meson_gpio_irq_domain *domain_data,
> + int hwirq)
> +{
> + int i;
> +
> + for (i = 0; i < domain_data->params->nsource; i++) {
> + if (domain_data->map[i] == hwirq)
> + return i;
> + }
> +
> + return -1;
I'm a bit worried by this function. If you need an allocator, then
having a simple bitmap is much better than iterating over an array.
If you're using this to go from a hwirq to the structure describing your
interrupt, this is wrong. You should never have to look-up something
based on a hwirq, because that's what irq domains are for.
> +}
> +
> +static int mesion_gpio_irq_map_source(struct meson_gpio_irq_domain *domain_data,
> + irq_hw_number_t hwirq,
> + irq_hw_number_t *source)
> +{
> + int index;
> + unsigned int reg;
> +
> + index = meson_gpio_irq_get_index(domain_data, IRQ_FREE);
So assuming you turn this into a proper bitmap driven allocator...
> + if (index < 0) {
> + pr_err("No irq available\n");
> + return -ENOSPC;
> + }
> +
> + domain_data->map[index] = hwirq;
this can go away, as there is hardly any point in tracking the hwirq on
its own. Actually, the whole map[] array looks totally useless.
> +
> + reg = (index < 4) ? REG_PIN_03_SEL : REG_PIN_47_SEL;
> + meson_gpio_irq_update_bits(domain_data->base, reg,
> + 0xff << REG_PIN_SEL_SHIFT(index),
> + hwirq << REG_PIN_SEL_SHIFT(index));
> +
> + *source = domain_data->params->source[index];
> +
> + pr_debug("hwirq %lu assigned to channel %d - source %lu\n",
> + hwirq, index, *source);
> +
> + return index;
> +}
> +
> +static int meson_gpio_irq_type_setup(unsigned int type, void __iomem *base,
> + int index)
> +{
> + u32 val = 0;
> +
> + type &= IRQ_TYPE_SENSE_MASK;
> +
> + if (type == IRQ_TYPE_EDGE_BOTH)
> + return -EINVAL;
> +
> + if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
> + val |= REG_EDGE_POL_EDGE(index);
> +
> + if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_FALLING))
> + val |= REG_EDGE_POL_LOW(index);
> +
> + meson_gpio_irq_update_bits(base, REG_EDGE_POL,
> + REG_EDGE_POL_MASK(index), val);
> +
> + return 0;
> +}
> +
> +static unsigned int meson_gpio_irq_type_output(unsigned int type)
> +{
> + unsigned int sense = type & IRQ_TYPE_SENSE_MASK;
> +
> + type &= ~IRQ_TYPE_SENSE_MASK;
> +
> + /*
> + * If the polarity of interrupt is low, the controller will
> + * invert the signal for gic
> + */
> + if (sense & (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW))
> + type |= IRQ_TYPE_LEVEL_HIGH;
> + else if (sense & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
> + type |= IRQ_TYPE_EDGE_RISING;
> +
> + return type;
> +}
> +
> +static int meson_gpio_irq_set_type(struct irq_data *data, unsigned int type)
> +{
> + struct meson_gpio_irq_chip_data *cd = irq_data_get_irq_chip_data(data);
> + int ret;
> +
> + pr_debug("set type of hwirq %lu to %u\n", data->hwirq, type);
> +
> + ret = meson_gpio_irq_type_setup(type, cd->base, cd->index);
> + if (ret)
> + return ret;
> +
> + return irq_chip_set_type_parent(data,
> + meson_gpio_irq_type_output(type));
> +}
> +
> +static struct irq_chip meson_gpio_irq_chip = {
> + .name = "meson-gpio-irqchip",
> + .irq_mask = irq_chip_mask_parent,
> + .irq_unmask = irq_chip_unmask_parent,
> + .irq_eoi = irq_chip_eoi_parent,
> + .irq_set_type = meson_gpio_irq_set_type,
> + .irq_retrigger = irq_chip_retrigger_hierarchy,
> +#ifdef CONFIG_SMP
> + .irq_set_affinity = irq_chip_set_affinity_parent,
> +#endif
> +};
> +
> +static int meson_gpio_irq_domain_translate(struct irq_domain *domain,
> + struct irq_fwspec *fwspec,
> + unsigned long *hwirq,
> + unsigned int *type)
> +{
> + if (is_of_node(fwspec->fwnode)) {
> + if (fwspec->param_count != 2)
> + return -EINVAL;
You can write this as:
if (is_of_node() && fwspec->... == 2) {
> +
> + *hwirq = fwspec->param[0];
> + *type = fwspec->param[1];
> +
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int meson_gpio_irq_allocate_gic_irq(struct irq_domain *domain,
> + unsigned int virq,
> + irq_hw_number_t source,
> + unsigned int type)
> +{
> + struct irq_fwspec fwspec;
> +
> + if (!irq_domain_get_of_node(domain->parent))
> + return -EINVAL;
How can you end-up here if the translate operation has failed?
> +
> + fwspec.fwnode = domain->parent->fwnode;
> + fwspec.param_count = 3;
> + fwspec.param[0] = 0; /* SPI */
> + fwspec.param[1] = source;
> + fwspec.param[2] = meson_gpio_irq_type_output(type);
> +
> + return irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
> +}
> +
> +static int meson_gpio_irq_domain_alloc(struct irq_domain *domain,
> + unsigned int virq,
> + unsigned int nr_irqs,
> + void *data)
> +{
> + struct irq_fwspec *fwspec = data;
> + struct meson_gpio_irq_domain *domain_data = domain->host_data;
> + struct meson_gpio_irq_chip_data *cd;
> + unsigned long hwirq, source;
> + unsigned int type;
> + int i, index, ret;
> +
> + ret = meson_gpio_irq_domain_translate(domain, fwspec, &hwirq, &type);
> + if (ret)
> + return ret;
> +
> + pr_debug("irq %d, nr_irqs %d, hwirqs %lu\n", virq, nr_irqs, hwirq);
> +
> + for (i = 0; i < nr_irqs; i++) {
This is a pattern that gets repeated over and over, for no good reason.
The only reason we have this nr_irqs thing is to handle things like
multi-MSI, where we have to *guarantee* that the hwirqs are allocated in
a contiguous manner.
Here, you don't enforce that guarantee, so you'd rather have a big fat:
if (WARN_ON(nr_irqs != 1))
return -EINVAL;
and get rid of that loop, because I cannot imagine a case where you'd
allocate more than a single interrupt@a time.
> + index = mesion_gpio_irq_map_source(domain_data, hwirq + i,
> + &source);
> + if (index < 0)
> + return index;
> +
> + ret = meson_gpio_irq_type_setup(type, domain_data->base,
> + index);
> + if (ret)
> + return ret;
Why do you have to to this here? This should be handled by the core code
already.
> +
> + cd = kzalloc(sizeof(*cd), GFP_KERNEL);
> + if (!cd)
> + return -ENOMEM;
> +
> + cd->base = domain_data->base;
> + cd->index = index;
So what is the exact purpose of this structure? The base address is
essentially a global, or could be directly derived from the domain. The
index is only used in set_type, and is the index of the pin connected to
the GIC. It looks to me like you could have:
irq_hw_number_t *out_line = &meson_parent_hwirqs[index];
> +
> + irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> + &meson_gpio_irq_chip, cd);
and this written as
irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
out_line);
In your set_type function, you just compute the index back:
irq_hw_number_t *out_line = irq_data_get_irq_chip_data(data);
irq_hw_number_t index = out_line - meson_parent_hwirqs;
and you're done.
> +
> + ret = meson_gpio_irq_allocate_gic_irq(domain, virq + i,
> + source, type);
Resource leak on error.
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void meson_gpio_irq_domain_free(struct irq_domain *domain,
> + unsigned int virq,
> + unsigned int nr_irqs)
> +{
> + struct meson_gpio_irq_domain *domain_data = domain->host_data;
> + struct meson_gpio_irq_chip_data *cd;
> + struct irq_data *irq_data;
> + int i;
> +
> + for (i = 0; i < nr_irqs; i++) {
Same comment as above.
> + irq_data = irq_domain_get_irq_data(domain, virq + i);
> + cd = irq_data_get_irq_chip_data(irq_data);
> +
> + domain_data->map[cd->index] = IRQ_FREE;
> + kfree(cd);
> + }
> +
> + irq_domain_free_irqs_parent(domain, virq, nr_irqs);
> +
> +}
> +
> +static const struct irq_domain_ops meson_gpio_irq_domain_ops = {
> + .alloc = meson_gpio_irq_domain_alloc,
> + .free = meson_gpio_irq_domain_free,
> + .translate = meson_gpio_irq_domain_translate,
> +};
> +
> +static int __init
> +meson_gpio_irq_init_domain(struct device_node *node,
> + struct meson_gpio_irq_domain *domain_data,
> + const struct meson_gpio_irq_params *params)
> +{
> + int i;
> + int nsource = params->nsource;
> + int *map;
> +
> + map = kcalloc(nsource, sizeof(*map), GFP_KERNEL);
> + if (!map)
> + return -ENOMEM;
> +
> + for (i = 0; i < nsource; i++)
> + map[i] = IRQ_FREE;
> +
> + domain_data->map = map;
You should now be able to kill most or all of this.
> + domain_data->params = params;
> +
> + return 0;
> +}
> +
> +static int __init meson_gpio_irq_of_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + struct irq_domain *domain, *parent_domain;
> + const struct of_device_id *match;
> + const struct meson_gpio_irq_params *params;
> + struct meson_gpio_irq_domain *domain_data;
> + int ret;
> +
> + match = of_match_node(meson_irq_gpio_matches, node);
> + if (!match)
> + return -ENODEV;
> + params = match->data;
> +
> + if (!parent) {
> + pr_err("missing parent interrupt node\n");
> + return -ENODEV;
> + }
> +
> + parent_domain = irq_find_host(parent);
> + if (!parent_domain) {
> + pr_err("unable to obtain parent domain\n");
> + return -ENXIO;
> + }
> +
> + domain_data = kzalloc(sizeof(*domain_data), GFP_KERNEL);
> + if (!domain_data)
> + return -ENOMEM;
> +
> + domain_data->base = of_iomap(node, 0);
> + if (!domain_data->base) {
> + ret = -ENOMEM;
> + goto out_free_dev;
> + }
> +
> + ret = meson_gpio_irq_init_domain(node, domain_data, params);
> + if (ret < 0)
> + goto out_free_dev_content;
> +
> + domain = irq_domain_add_hierarchy(parent_domain, 0, params->nhwirq,
> + node, &meson_gpio_irq_domain_ops,
> + domain_data);
Please be consistent in using the fwnode API instead of the of_node one.
> +
> + if (!domain) {
> + pr_err("failed to allocated domain\n");
> + ret = -ENOMEM;
> + goto out_free_dev_content;
> + }
> +
> + pr_info("%d to %d gpio interrupt mux initialized\n",
> + params->nhwirq, params->nsource);
> +
> + return 0;
> +
> +out_free_dev_content:
> + kfree(domain_data->map);
> + iounmap(domain_data->base);
> +
> +out_free_dev:
> + kfree(domain_data);
> +
> + return ret;
> +}
> +
> +IRQCHIP_DECLARE(meson8_gpio_intc, "amlogic,meson8-gpio-intc",
> + meson_gpio_irq_of_init);
> +IRQCHIP_DECLARE(meson8b_gpio_intc, "amlogic,meson8b-gpio-intc",
> + meson_gpio_irq_of_init);
> +IRQCHIP_DECLARE(gxbb_gpio_intc, "amlogic,meson-gxbb-gpio-intc",
> + meson_gpio_irq_of_init);
>
Overall, this driver is a bit of a mess. Tons of structures that don't
make much sense, and a false sense of being able to support multiple
instances of the device.
I'll let Mark comment on the DT side of things.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Linus Walleij @ 2016-10-20 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPoCmYJC1TebBrspD_=mTETULSjg9or5a0Yda8p945y6ZWL99Q@mail.gmail.com>
On Tue, Oct 18, 2016 at 10:44 PM, Gottfried Haider
<gottfried.haider@gmail.com wrote:
> I'll hopefully find time to look at the more recent changes to the gpio
> subsystem (lsgpio?!), but since this patch is up for discussion now - what I
> was wondering: how does this change relate to /sys/class/gpio/gpio%d? Is
> this completely orthogonal - or would this change the sysfs interface as
> well?
The old sysfs interface is not changing. However it is deprecated so once
you have a v4.8+ kernel, consider migrating whatever userspace you have
to use the chardev ABI instead.
See:
commit fe95046e960b4b76e73dc1486955d93f47276134
"gpio: ABI: mark the sysfs ABI as obsolete"
commit 521a2ad6f862a28e2e43cb3e254a26bf0f9452e9
"gpio: add userspace ABI for GPIO line information"
commit d7c51b47ac11e66f547b55640405c1c474642d72
"gpio: userspace ABI for reading/writing GPIO lines"
commit 61f922db72216b00386581c851db9c9095961522
"gpio: userspace ABI for reading GPIO line events"
> Regarding the proposed format using the header pin numbers: From what I've
> seen in terms of existing educational materials, it seems the overwhelming
> majority ends up using GPIO numbers instead of physical pin header
> numbering. (e.g. [1] [2])
What does that number mean? If you are referring to the global
GPIO numberspace it is obsolete and just reflecting the fact that
people up until now was referring to Linux-internal GPIO numbers.
> Would it be too confusing to try to pick GPIO 5 from an alphabetically
> sorted list like this "P11_GPIO17", "P12_GPIO18"? (I know, alphabetical
> sorting is an issue here already for a different reason. But applications
> might do it, I guess?)
Any attempt to preserve the global GPIO numberspace is futile.
If it is the local offset number on the chip it is another thing, that
is kind of OK if the arch maintainer likes it.
Global GPIO numbers are inherently inconsistent since the introduction
of deferred probe, as GPIO drivers often pick a dynamic number base
and thus end up with the same number even though that can depend on
things like cosmic radiation or the temperature of their board when
they boot. So global GPIO numbers are considered harmful and have
therefore been obsoleted as userspace ABI.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM64: defconfig: Enable MMC related configs
From: Kevin Hilman @ 2016-10-20 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476964194-2194-1-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Enable MMC related defaults configs for MMC, PWM and PWM clock.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Applied to v4.10/defconfig
Kevin
^ permalink raw reply
* [RFC PATCH] net: stmmac: Add OXNAS Glue Driver
From: Joachim Eastwood @ 2016-10-20 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020155406.27172-1-narmstrong@baylibre.com>
Hi Neil,
On 20 October 2016 at 17:54, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 ++++++
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 173 +++++++++++++++++++++
> 4 files changed, 229 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
<snip>
> +
> +static int oxnas_dwmac_probe(struct platform_device *pdev)
> +{
> + struct plat_stmmacenet_data *plat_dat;
> + struct stmmac_resources stmmac_res;
> + struct device_node *sysctrl;
> + struct oxnas_dwmac *dwmac;
> + int ret;
> +
> + sysctrl = of_parse_phandle(pdev->dev.of_node, "oxsemi,sys-ctrl", 0);
> + if (!sysctrl) {
> + dev_err(&pdev->dev, "failed to get sys-ctrl node\n");
> + return -EINVAL;
> + }
> +
> + ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> + if (ret)
> + return ret;
> +
> + plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
> + if (IS_ERR(plat_dat))
> + return PTR_ERR(plat_dat);
> +
> + dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
> + if (!dwmac)
> + return -ENOMEM;
> +
> + dwmac->regmap = syscon_node_to_regmap(sysctrl);
> + if (IS_ERR(dwmac->regmap)) {
> + dev_err(&pdev->dev, "failed to have sysctrl regmap\n");
> + return PTR_ERR(dwmac->regmap);
> + }
> +
> + dwmac->clk = devm_clk_get(&pdev->dev, "gmac");
> + if (IS_ERR(dwmac->clk))
> + return PTR_ERR(dwmac->clk);
> +
> + plat_dat->bsp_priv = dwmac;
> + plat_dat->init = oxnas_dwmac_init;
> + plat_dat->exit = oxnas_dwmac_exit;
Please do not use the init/exit callbacks. Implement proper driver
callbacks instead. I.e: PM resume/suspend and driver remove.
Shouldn't you call oxnas_dwmac_init() from probe as well?
As it is now it will only be called during PM resume and that can't be right.
> +
> + return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
If stmmac_dvr_probe() fails you should disable your clocks.
regards,
Joachim Eastwood
^ permalink raw reply
* [PATCH] hwrng: meson: Remove unneeded platform MODULE_ALIAS
From: Kevin Hilman @ 2016-10-20 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476906618-14455-1-git-send-email-javier@osg.samsung.com>
Javier Martinez Canillas <javier@osg.samsung.com> writes:
> The Amlogic Meson is a DT-only platform, which means the devices are
> registered via OF and not using the legacy platform devices support.
>
> So there's no need to have a MODULE_ALIAS("platform:meson-rng") since
> the reported uevent MODALIAS to user-space will always be the OF one.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
> ---
>
> drivers/char/hw_random/meson-rng.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
> index 51864a509be7..119d698439ae 100644
> --- a/drivers/char/hw_random/meson-rng.c
> +++ b/drivers/char/hw_random/meson-rng.c
> @@ -122,7 +122,6 @@ static struct platform_driver meson_rng_driver = {
>
> module_platform_driver(meson_rng_driver);
>
> -MODULE_ALIAS("platform:meson-rng");
> MODULE_DESCRIPTION("Meson H/W Random Number Generator driver");
> MODULE_AUTHOR("Lawrence Mok <lawrence.mok@amlogic.com>");
> MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
^ permalink raw reply
* [PATCH] pwm: meson: Remove unneeded platform MODULE_ALIAS
From: Kevin Hilman @ 2016-10-20 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476906599-14350-1-git-send-email-javier@osg.samsung.com>
Javier Martinez Canillas <javier@osg.samsung.com> writes:
> The Amlogic Meson is a DT-only platform, which means the devices are
> registered via OF and not using the legacy platform devices support.
>
> So there's no need to have a MODULE_ALIAS("platform:meson-pwm") since
> the reported uevent MODALIAS to user-space will always be the OF one.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
> ---
>
> drivers/pwm/pwm-meson.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
> index 381871b2bb46..5678092cad4b 100644
> --- a/drivers/pwm/pwm-meson.c
> +++ b/drivers/pwm/pwm-meson.c
> @@ -523,7 +523,6 @@ static struct platform_driver meson_pwm_driver = {
> };
> module_platform_driver(meson_pwm_driver);
>
> -MODULE_ALIAS("platform:meson-pwm");
> MODULE_DESCRIPTION("Amlogic Meson PWM Generator driver");
> MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
> MODULE_LICENSE("Dual BSD/GPL");
^ permalink raw reply
* [PATCH] watchdog: meson: Remove unneeded platform MODULE_ALIAS
From: Kevin Hilman @ 2016-10-20 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476906582-14241-1-git-send-email-javier@osg.samsung.com>
Javier Martinez Canillas <javier@osg.samsung.com> writes:
> The Amlogic Meson is a DT-only platform, which means the devices are
> registered via OF and not using the legacy platform devices support.
>
> So there's no need to have a MODULE_ALIAS("platform:meson-gxbb-wdt")
> since the reported uevent MODALIAS to user-space will be the OF one.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
> ---
>
> drivers/watchdog/meson_gxbb_wdt.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/watchdog/meson_gxbb_wdt.c b/drivers/watchdog/meson_gxbb_wdt.c
> index 44d180a2c5e5..45d47664a00a 100644
> --- a/drivers/watchdog/meson_gxbb_wdt.c
> +++ b/drivers/watchdog/meson_gxbb_wdt.c
> @@ -264,7 +264,6 @@ static struct platform_driver meson_gxbb_wdt_driver = {
>
> module_platform_driver(meson_gxbb_wdt_driver);
>
> -MODULE_ALIAS("platform:meson-gxbb-wdt");
> MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
> MODULE_DESCRIPTION("Amlogic Meson GXBB Watchdog timer driver");
> MODULE_LICENSE("Dual BSD/GPL");
^ permalink raw reply
* [PATCH v2 1/6] clk: stm32f4: Add LSI & LSE clocks
From: Gabriel Fernandez @ 2016-10-20 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019202433.GA8871@codeaurora.org>
Hi Stephen,
On 10/19/2016 10:24 PM, Stephen Boyd wrote:
> On 10/14, gabriel.fernandez at st.com wrote:
>> @@ -292,8 +298,110 @@ static int stm32f4_rcc_lookup_clk_idx(u8 primary, u8 secondary)
>> return clks[i];
>> }
>>
>> +static struct regmap *pdrm;
> This can't be part of the stm32_rgate structure?
Finally i prefer not, because i need also to disable power domain write
protection in the patch 4 (clk: stm32f4: Add RTC clock).
its will complicate the code.
BR
Gabriel
^ permalink raw reply
* [PATCH 2/3] ARM: dts: sun8i: Use the common file in NanoPi NEO SBC
From: Maxime Ripard @ 2016-10-20 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020080701.15993-3-woogyom.kim@gmail.com>
Hi Milo,
On Thu, Oct 20, 2016 at 05:07:00PM +0900, Milo Kim wrote:
> Cc: James Pettigrew <james@innovum.com.au>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
Please add a commit log.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/eb5b7b81/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: sun8i: Add common dtsi file for NanoPi SBCs
From: Maxime Ripard @ 2016-10-20 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020080701.15993-2-woogyom.kim@gmail.com>
Hi,
On Thu, Oct 20, 2016 at 05:06:59PM +0900, Milo Kim wrote:
> This patch provides a common file for NanoPi M1 and Neo SBC.
>
> Those have common features below.
> * UART0
> * 2 LEDs
> * USB host (EHCI3, OHCI3) and PHY
> * MicroSD
> * GPIO key switch
>
> Cc: James Pettigrew <james@innovum.com.au>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> ---
> arch/arm/boot/dts/sun8i-h3-nanopi.dtsi | 143 +++++++++++++++++++++++++++++++++
> 1 file changed, 143 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi.dtsi
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi b/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi
> new file mode 100644
> index 0000000..e89ca6f
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi
> @@ -0,0 +1,143 @@
> +/*
> + * Copyright (C) 2016 Milo Kim <woogyom.kim@gmail.com>
This looks like a copy of James' DT. Keeping him as the copyright
holder seems like the right thing to do.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-h3.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&leds_npi>, <&leds_r_npi>;
> +
> + status {
> + label = "nanopi:blue:status";
> + gpios = <&pio 0 10 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + };
> +
> + pwr {
> + label = "nanopi:green:pwr";
> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> + };
> +
> + r_gpio_keys {
> + compatible = "gpio-keys";
> + input-name = "k1";
> + pinctrl-names = "default";
> + pinctrl-0 = <&sw_r_npi>;
> +
> + k1 at 0 {
> + label = "k1";
> + linux,code = <KEY_POWER>;
> + gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +&ehci3 {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + bus-width = <4>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
> + status = "okay";
> + vmmc-supply = <®_vcc3v3>;
> +};
> +
> +&ohci3 {
> + status = "okay";
> +};
> +
> +&pio {
> + leds_npi: led_pins at 0 {
> + allwinner,pins = "PA10";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +};
> +
> +&r_pio {
> + leds_r_npi: led_pins at 0 {
> + allwinner,pins = "PL10";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + sw_r_npi: key_pins at 0 {
> + allwinner,pins = "PL3";
> + allwinner,function = "gpio_in";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins_a>;
> + status = "okay";
> +};
> +
> +&usbphy {
> + status = "okay";
> +};
> --
> 2.9.3
>
Looks good otherwise.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/d8ce2171/attachment.sig>
^ permalink raw reply
* [PATCH v2 8/8] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge
From: Maxime Ripard @ 2016-10-20 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-9-wens@csie.org>
1;4402;0c
On Thu, Oct 20, 2016 at 11:43:44AM +0800, Chen-Yu Tsai wrote:
> The Hummingbird A31 board has a RGB-to-VGA bridge which converts RGB
> output from the LCD interface to VGA signals.
>
> Enable this part of the display pipeline.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
This one looks nice, but I'm going to wait for Archit answers before
merging it.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/ea5a402d/attachment.sig>
^ permalink raw reply
* [PATCH v2 6/8] ARM: dts: sun6i: Add device nodes for first display pipeline
From: Maxime Ripard @ 2016-10-20 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-7-wens@csie.org>
On Thu, Oct 20, 2016 at 11:43:42AM +0800, Chen-Yu Tsai wrote:
> The A31 has 2 parallel display pipelines, which can be intermixed.
> However the driver currently only supports one of them.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/e8175358/attachment.sig>
^ permalink raw reply
* [PATCH v2 7/8] ARM: dts: sun6i: Add A31 LCD0 RGB888 pins
From: Maxime Ripard @ 2016-10-20 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-8-wens@csie.org>
On Thu, Oct 20, 2016 at 11:43:43AM +0800, Chen-Yu Tsai wrote:
> The LCD0 controller on the A31 can do RGB output up to 8 bits per
> channel. Add the pins for RGB888 output.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/f9b10d38/attachment.sig>
^ permalink raw reply
* [PATCH v2 5/8] drm/sun4i: Add compatible strings for A31/A31s display pipelines
From: Maxime Ripard @ 2016-10-20 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-6-wens@csie.org>
On Thu, Oct 20, 2016 at 11:43:41AM +0800, Chen-Yu Tsai wrote:
> The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It
> also has new display enhancement blocks, such as the DRC (Dynamic Range
> Controller), the DEU (Display Enhancement Unit), and the CMU (Color
> Management Unit). It supports HDMI, MIPI DSI, and 2 LCD/LVDS channels.
>
> The A31s display pipeline is almost the same, just without MIPI DSI.
> Only the TCON seems to be different, due to the missing mux for MIPI
> DSI.
>
> Add compatible strings for both of them.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Rob Herring <robh@kernel.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/704f2edd/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 4/8] drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)
From: Maxime Ripard @ 2016-10-20 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-5-wens@csie.org>
On Thu, Oct 20, 2016 at 11:43:40AM +0800, Chen-Yu Tsai wrote:
> The A31 TCON has mux controls for how TCON outputs are routed to the
> HDMI and MIPI DSI blocks.
>
> Since the A31s does not have MIPI DSI, it only has a mux for the HDMI
> controller input.
>
> This patch only adds support for the compatible strings. Actual support
> for the mux controls should be added with HDMI and MIPI DSI support.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/ed0e53ae/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/8] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure
From: Maxime Ripard @ 2016-10-20 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-4-wens@csie.org>
On Thu, Oct 20, 2016 at 11:43:39AM +0800, Chen-Yu Tsai wrote:
> We already have some differences between the 2 supported SoCs.
> More will be added as we support other SoCs. To avoid bloating
> the probe function with even more conditionals, move the quirks
> to a separate data structure that's tied to the compatible string.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/b7c51e84/attachment.sig>
^ 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