* [PATCH v2 2/3] arm64: dts: r8a7796: Add CAN support
From: Chris Paterson @ 2016-11-24 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480004021-4037-1-git-send-email-chris.paterson2@renesas.com>
Adds CAN controller nodes for r8a7796.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 61d165b..47fa29c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -362,6 +362,36 @@
status = "disabled";
};
+ can0: can at e6c30000 {
+ compatible = "renesas,can-r8a7796",
+ "renesas,rcar-gen3-can";
+ reg = <0 0xe6c30000 0 0x1000>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 916>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ can1: can at e6c38000 {
+ compatible = "renesas,can-r8a7796",
+ "renesas,rcar-gen3-can";
+ reg = <0 0xe6c38000 0 0x1000>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 915>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
scif2: serial at e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: r8a7796: Add CAN FD support
From: Chris Paterson @ 2016-11-24 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480004021-4037-1-git-send-email-chris.paterson2@renesas.com>
Adds CAN FD controller node for r8a7796.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 47fa29c..1ed1886 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -392,6 +392,30 @@
status = "disabled";
};
+ canfd: can at e66c0000 {
+ compatible = "renesas,r8a7796-canfd",
+ "renesas,rcar-gen3-canfd";
+ reg = <0 0xe66c0000 0 0x8000>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 914>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "fck", "canfd", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+
+ channel0 {
+ status = "disabled";
+ };
+
+ channel1 {
+ status = "disabled";
+ };
+ };
+
scif2: serial at e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
1.9.1
^ permalink raw reply related
* [PATCH V7 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Lorenzo Pieralisi @ 2016-11-24 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479074375-2629-3-git-send-email-agustinv@codeaurora.org>
Hi Agustin,
On Sun, Nov 13, 2016 at 04:59:34PM -0500, Agustin Vega-Frias wrote:
> When an Extended IRQ Resource contains a valid ResourceSource
> use it to map the IRQ on the domain associated with the ACPI
> device referenced.
>
> With this in place an irqchip driver can create its domain using
> irq_domain_create_linear and pass the device fwnode to create
> the domain mapping. When dependent devices are probed these
> changes allow the ACPI core find the domain and map the IRQ.
>
> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> ---
> drivers/acpi/Makefile | 2 +-
> drivers/acpi/{gsi.c => irq.c} | 98 +++++++++++++++++++++++++++++++++++++------
> drivers/acpi/resource.c | 29 +++++++------
> include/linux/acpi.h | 19 +++++++++
> 4 files changed, 121 insertions(+), 27 deletions(-)
> rename drivers/acpi/{gsi.c => irq.c} (53%)
It looks to me the direction is the right one but I have a question
for you and others below.
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 9ed0878..a391bbc 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -55,7 +55,7 @@ acpi-$(CONFIG_DEBUG_FS) += debugfs.o
> acpi-$(CONFIG_ACPI_NUMA) += numa.o
> acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
> acpi-y += acpi_lpat.o
> -acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
> +acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
> acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
>
> # These are (potentially) separate modules
> diff --git a/drivers/acpi/gsi.c b/drivers/acpi/irq.c
> similarity index 53%
> rename from drivers/acpi/gsi.c
> rename to drivers/acpi/irq.c
> index ee9e0f2..c6ecaab 100644
> --- a/drivers/acpi/gsi.c
> +++ b/drivers/acpi/irq.c
> @@ -18,6 +18,45 @@
> static struct fwnode_handle *acpi_gsi_domain_id;
>
> /**
> + * acpi_get_irq_source_fwhandle() - Retrieve the fwhandle of the given
> + * acpi_resource_source which is used
> + * to be used as an IRQ domain id
> + * @source: acpi_resource_source to use for the lookup
> + *
> + * Returns: The appropriate IRQ fwhandle domain id
> + * NULL on failure
> + */
> +struct fwnode_handle *
> +acpi_get_irq_source_fwhandle(const struct acpi_resource_source *source)
> +{
> + struct fwnode_handle *result;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> +
> + if (!source->string_length)
> + return acpi_gsi_domain_id;
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status)) {
> + pr_warn("Could not find handle for %s\n", source->string_ptr);
> + return NULL;
> + }
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device) {
> + pr_warn("Could not get device for %s\n", source->string_ptr);
> + return NULL;
> + }
> +
> + result = &device->fwnode;
> + acpi_bus_put_acpi_device(device);
> +
> + return result;
> +}
> +EXPORT_SYMBOL_GPL(acpi_get_irq_source_fwhandle);
> +
> +/**
> * acpi_gsi_to_irq() - Retrieve the linux irq number for a given GSI
> * @gsi: GSI IRQ number to map
> * @irq: pointer where linux IRQ number is stored
> @@ -42,6 +81,50 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
>
> /**
> + * acpi_register_irq() - Map a hardware 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
> + * -EINVAL on failure
Nit: You need to update the return values list.
> + */
> +int acpi_register_irq(struct fwnode_handle *source, u32 hwirq, int trigger,
> + int polarity)
> +{
> + struct irq_fwspec fwspec;
> +
> + if (!source)
> + return -EINVAL;
> +
> + if (irq_find_matching_fwnode(source, DOMAIN_BUS_ANY) == NULL)
> + return -EPROBE_DEFER;
> +
> + fwspec.fwnode = source;
> + fwspec.param[0] = hwirq;
> + fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
> + fwspec.param_count = 2;
> +
> + return irq_create_fwspec_mapping(&fwspec);
> +}
> +EXPORT_SYMBOL_GPL(acpi_register_irq);
> +
> +/**
> + * acpi_unregister_irq() - Free a Hardware IRQ<->linux IRQ number mapping
> + * @hwirq: Hardware IRQ number
> + */
> +void acpi_unregister_irq(struct fwnode_handle *source, u32 hwirq)
> +{
> + struct irq_domain *d = irq_find_matching_fwnode(source,
> + DOMAIN_BUS_ANY);
> + int irq = irq_find_mapping(d, hwirq);
> +
> + irq_dispose_mapping(irq);
> +}
> +EXPORT_SYMBOL_GPL(acpi_unregister_irq);
> +
> +/**
> * acpi_register_gsi() - Map a GSI to a linux IRQ number
> * @dev: device for which IRQ has to be mapped
> * @gsi: GSI IRQ number
> @@ -54,19 +137,12 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
> int polarity)
> {
> - struct irq_fwspec fwspec;
> -
> if (WARN_ON(!acpi_gsi_domain_id)) {
> pr_warn("GSI: No registered irqchip, giving up\n");
> return -EINVAL;
> }
>
> - fwspec.fwnode = acpi_gsi_domain_id;
> - fwspec.param[0] = gsi;
> - fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
> - fwspec.param_count = 2;
> -
> - return irq_create_fwspec_mapping(&fwspec);
> + return acpi_register_irq(acpi_gsi_domain_id, gsi, trigger, polarity);
> }
> EXPORT_SYMBOL_GPL(acpi_register_gsi);
>
> @@ -76,11 +152,7 @@ int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
> */
> void acpi_unregister_gsi(u32 gsi)
> {
> - struct irq_domain *d = irq_find_matching_fwnode(acpi_gsi_domain_id,
> - DOMAIN_BUS_ANY);
> - int irq = irq_find_mapping(d, gsi);
> -
> - irq_dispose_mapping(irq);
> + acpi_unregister_irq(acpi_gsi_domain_id, gsi);
> }
> EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 4beda15..83cff00 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -374,21 +374,22 @@ unsigned int acpi_dev_get_irq_type(int triggering, int polarity)
> }
> EXPORT_SYMBOL_GPL(acpi_dev_get_irq_type);
>
> -static void acpi_dev_irqresource_disabled(struct resource *res, u32 gsi)
> +static void acpi_dev_irqresource_disabled(struct resource *res, u32 hwirq)
> {
> - res->start = gsi;
> - res->end = gsi;
> + res->start = hwirq;
> + res->end = hwirq;
> 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,
> + struct fwnode_handle *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 && !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_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);
> }
> }
>
> @@ -448,6 +449,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> {
> struct acpi_resource_irq *irq;
> struct acpi_resource_extended_irq *ext_irq;
> + struct fwnode_handle *src;
>
> switch (ares->type) {
> case ACPI_RESOURCE_TYPE_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], NULL,
> irq->triggering, irq->polarity,
> irq->sharable, true);
> break;
> @@ -470,7 +472,8 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> acpi_dev_irqresource_disabled(res, 0);
> return false;
> }
> - acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
> + src = acpi_get_irq_source_fwhandle(&ext_irq->resource_source);
Is there a reason why we need to do the domain look-up here ?
I would like to understand if, by reshuffling the code (and by returning
the resource_source to the calling code - somehow), it would be possible
to just mirror what the OF code does in of_irq_get(), namely:
(1) parse the irq entry -> of_irq_parse_one()
(2) look the domain up -> irq_find_host()
(3) create the mapping -> irq_create_of_mapping()
You wrote the code already, I think it is just a matter of shuffling
it around (well, minus returning the resource_source to the caller
which is phandle equivalent in DT).
You abstracted away (2) and (3) behind acpi_register_irq(), that
on anything than does not use ACPI_GENERIC_GSI is just glue code
to acpi_register_gsi().
Also, it is not a question on this patch but I ask it here because it
is related. On ACPI you are doing the reverse of what is done in
DT in platform_get_irq():
- get the resources already parsed -> platform_get_resource()
- if they are disabled -> acpi_irq_get()
and I think the ordering is tied to my question above because
you carry out the domain look up in acpi_dev_resource_interrupt()
so that if for any reason it fails the corresponding resource
is disabled so that we try to get it again through acpi_irq_get().
I suspect you did it this way to make sure:
a) keep the current ACPI IRQ parsing interface changes to a mininum
b) avoid changing the behaviour on x86/ia64; in particular, calling
acpi_register_gsi() for the _same_ mapping (an IRQ that was already
registered at device creation resource parsing) multiple times can
trigger issues on x86/ia64
I think that's a reasonable approach but I wanted to get these
clarifications, I do not think you are far from getting this
done but since it is a significant change I think it is worth
discussing the points I raised above because I think the DT code
sequence in of_irq_get() (1-2-3 above) is cleaner from an IRQ
layer perspective (instead of having the domain look-up buried
inside the ACPI IRQ resource parsing API).
Thanks !
Lorenzo
> + acpi_dev_get_irqresource(res, ext_irq->interrupts[index], src,
> ext_irq->triggering, ext_irq->polarity,
> ext_irq->sharable, false);
> break;
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 325bdb9..1099b51 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -321,6 +321,25 @@ void acpi_set_irq_model(enum acpi_irq_model_id model,
> */
> void acpi_unregister_gsi (u32 gsi);
>
> +#ifdef CONFIG_ACPI_GENERIC_GSI
> +struct fwnode_handle *
> +acpi_get_irq_source_fwhandle(const struct acpi_resource_source *source);
> +int acpi_register_irq(struct fwnode_handle *source, u32 hwirq, int trigger,
> + int polarity);
> +void acpi_unregister_irq(struct fwnode_handle *source, u32 hwirq);
> +#else
> +#define acpi_get_irq_source_fwhandle(source) (NULL)
> +static inline int acpi_register_irq(struct fwnode_handle *source, u32 hwirq,
> + int trigger, int polarity)
> +{
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +}
> +static inline void acpi_unregister_irq(struct fwnode_handle *source, u32 hwirq)
> +{
> + acpi_unregister_gsi(hwirq);
> +}
> +#endif
> +
> struct pci_dev;
>
> int acpi_pci_irq_enable (struct pci_dev *dev);
> --
> 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.
>
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Arnd Bergmann @ 2016-11-24 16:29 UTC (permalink / raw)
To: linux-arm-kernel
The camera_supply_dummy_device definition is shared between a780 and a910,
but only provided when the first is enabled and fails to build for a
configuration with only a910:
arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
This moves the definition into its own section.
Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
1 file changed, 30 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index 0b8300e6fca3..a057cf9c0e7b 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -696,32 +696,7 @@ static struct pxa27x_keypad_platform_data e2_keypad_platform_data = {
};
#endif /* CONFIG_MACH_EZX_E2 */
-#ifdef CONFIG_MACH_EZX_A780
-/* gpio_keys */
-static struct gpio_keys_button a780_buttons[] = {
- [0] = {
- .code = SW_LID,
- .gpio = GPIO12_A780_FLIP_LID,
- .active_low = 0,
- .desc = "A780 flip lid",
- .type = EV_SW,
- .wakeup = 1,
- },
-};
-
-static struct gpio_keys_platform_data a780_gpio_keys_platform_data = {
- .buttons = a780_buttons,
- .nbuttons = ARRAY_SIZE(a780_buttons),
-};
-
-static struct platform_device a780_gpio_keys = {
- .name = "gpio-keys",
- .id = -1,
- .dev = {
- .platform_data = &a780_gpio_keys_platform_data,
- },
-};
-
+#if defined(CONFIG_MACH_EZX_A780) || defined(CONFIG_MACH_EZX_A910)
/* camera */
static struct regulator_consumer_supply camera_dummy_supplies[] = {
REGULATOR_SUPPLY("vdd", "0-005d"),
@@ -750,6 +725,35 @@ static struct platform_device camera_supply_dummy_device = {
.platform_data = &camera_dummy_config,
},
};
+#endif
+
+#ifdef CONFIG_MACH_EZX_A780
+/* gpio_keys */
+static struct gpio_keys_button a780_buttons[] = {
+ [0] = {
+ .code = SW_LID,
+ .gpio = GPIO12_A780_FLIP_LID,
+ .active_low = 0,
+ .desc = "A780 flip lid",
+ .type = EV_SW,
+ .wakeup = 1,
+ },
+};
+
+static struct gpio_keys_platform_data a780_gpio_keys_platform_data = {
+ .buttons = a780_buttons,
+ .nbuttons = ARRAY_SIZE(a780_buttons),
+};
+
+static struct platform_device a780_gpio_keys = {
+ .name = "gpio-keys",
+ .id = -1,
+ .dev = {
+ .platform_data = &a780_gpio_keys_platform_data,
+ },
+};
+
+/* camera */
static int a780_camera_reset(struct device *dev)
{
gpio_set_value(GPIO19_GEN1_CAM_RST, 0);
--
2.9.0
^ permalink raw reply related
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-24 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58370530.5080605@free.fr>
Mason <slash.tmp@free.fr> writes:
> On 24/11/2016 15:17, M?ns Rullg?rd wrote:
>
>> Mason wrote:
>>
>>> [ 35.085854] SETUP DMA
>>> [ 35.088272] START NAND TRANSFER
>>> [ 35.091670] tangox_dma_pchan_start from tangox_dma_irq
>>> [ 35.096882] tango_dma_callback from vchan_complete
>>> [ 45.102513] DONE FAKE SPINNING
>>>
>>> So the IRQ rolls in, the ISR calls tangox_dma_pchan_start,
>>> which calls tangox_dma_pchan_detach to tear down the sbox
>>> setup; and only sometime later does the DMA framework call
>>> my callback function.
>>
>> Yes, I realised this soon after I said it. The dma driver could be
>> rearranged to make it work though.
>
> There is a way to make the tasklet run and invoke the callback
> before the interrupt service routine proceeds?
No, but it would be possible to defer the teardown to the tasklet.
Having said that, I'm not sure it's such a great idea since the tasklet
could be held up for an arbitrary length of time waiting for the target
to finish.
>>> So far, the work-arounds I've tested are:
>>>
>>> 1) delay sbox tear-down by 10 ?s in tangox_dma_pchan_detach.
>>> 2) statically setup sbox in probe, and never touch it henceforth.
>>>
>>> WA1 is fragile, it might break for devices other than NFC.
>>> WA2 is what I used when I wrote the NFC driver.
>>>
>>> Can tangox_dma_irq() be changed to have the framework call
>>> the client's callback *before* tangox_dma_pchan_start?
>>>
>>> (Thinking out loud) The DMA_PREP_INTERRUPT requests that the
>>> DMA framework invoke the callback from tasklet context,
>>> maybe a different flag DMA_PREP_INTERRUPT_EX can request
>>> calling the call-back directly from within the ISR?
>>>
>>> (Looking at existing flags) Could I use DMA_CTRL_ACK?
>>> Description sounds like some kind hand-shake between
>>> client and dmaengine.
>>>
>>> Grepping for DMA_PREP_INTERRUPT, I don't see where the framework
>>> checks that flag to spawn the tasklet? Or is that up to each
>>> driver individually?
>>
>> Those flags all have defined meanings and abusing them for other things
>> is a bad idea. As far as possible, device drivers should work with any
>> dma driver.
>
> I was asking about introducing a new flag, not abusing existing
> flags. (I don't understand the semantics of DMA_CTRL_ACK.)
This needs more than a new flag anyhow.
> (FWIW, both the NFC and the MBUS agent are custom designs,
> not third-party IP blocks.)
Sure, but who knows what will be in the next chip?
--
M?ns Rullg?rd
^ permalink raw reply
* [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support
From: Geert Uytterhoeven @ 2016-11-24 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HK2PR0601MB1329C747CA5C6B5222C02C3FB7B60@HK2PR0601MB1329.apcprd06.prod.outlook.com>
Hi Chris,
On Thu, Nov 24, 2016 at 3:25 PM, Chris Paterson
<Chris.Paterson2@renesas.com> wrote:
> From: Simon Horman [mailto:horms at verge.net.au]
> Sent: 24 November 2016 10:18
>> On Thu, Nov 24, 2016 at 10:05:08AM +0000, Chris Paterson wrote:
>> > From: Simon Horman [mailto:horms at verge.net.au]
>> > > Regarding the arch/arm64/boot/dts/renesas/ portion, I would like
>> > > some consideration given to what effect enabling memory above 4Gb
>> > > (64bit
>> > > addressing) would have.
>> >
>> > Can you give me some guidance here? I'm not sure what you're referring
>> > to. As far as I know the DT reg definition here is 64-bit, or are you
>> > referring to DMA usage? If the later, neither CAN driver uses DMA.
>>
>> Sorry for not being clearer.
>>
>> What I would like to know is if there are any problems in the CAN driver or
>> hardware that would prevent it from functioning with memory that requires
>> 64bit addressing present.
>>
>> If the CAN hardware cannot use DMA then DMA doesn't need to be taken
>> into account. But if it DMA could be enabled in future for CAN, for example
>> after some driver enhancements, then it would be good to know if 64bit
>> memory can be supported - if not it would imply DMA cannot be enabled.
>
> Thank you for the clarification.
>
> The CAN interface for r8a7795/6 does not support DMA.
>
> With CAN FD there is currently a H/W issue that means DMA is unusable.
Is that issue present on R-Car M3-W, or only on R-Car H3 ES1.x?
> Potentially this issue could be fixed in the future and DMA support could
> be added to the driver. If this happens I can see no reason why the CAN FD
> IP wouldn't be able to handle DMA transfers when using 64bit addressing.
Yep, AFAIK it uses SYS-DMAC, which supports 64-bit addressing.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [net-next PATCH v1 1/2] net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
From: Martin Blumenstingl @ 2016-11-24 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124154858.GB20455@lunn.ch>
Hi Andrew,
On Thu, Nov 24, 2016 at 4:48 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> The configuration values are provided as preprocessor macros to make the
>> devicetree files easier to read.
>
> Hi Martin
>
> If i'm reading the code/comments correctly, you can set the delay to
> 0, 2, 4 or 6ns? So calling this property amlogic,tx-delay-ns would be
> even easier to read.
indeed, this sounds like a very nice idea (as it moves the calculation
from the programmer's brain to dwmac-meson8b.c)!
I'll send an updated version once I received enough feedback (in case
something else is wrong with the patches)
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH 0/5] arm64: Allwinner H5 support
From: Ian Campbell @ 2016-11-24 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <560f873c-7ad9-5614-21f6-489879380ebe@arm.com>
On Thu, 2016-11-24 at 11:05 +0000, Andre Przywara wrote:
>
> > I don't have any major comments but I guess it all depends on the DT
> > maintainers view on the symbolic link to share the DTSI.
>
> I am curious too ;-)
> But I saw symlinks for the RaspberryPi 3 (check
> arch/arm64/boot/dts/broadcom) and VExpress, so I picked that low hanging
> fruit ;-)
See http://git.kernel.org/torvalds/linux/c/8ee57b8182c4?and the ML
discussion around the posting of that for some background on why the
symlinks are being used in preference to #include or /include/.
IIRC there was some further discussion on some lists when?http://git.ke
rnel.org/torvalds/linux/c/76aa75916880?was posted too.
Ian.
^ permalink raw reply
* [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Martin Blumenstingl @ 2016-11-24 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480002964.17538.131.camel@baylibre.com>
On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
>> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
>> cycle TX clock delay. This seems to work fine for many boards (for
>> example Odroid-C2 or Amlogic's reference boards) but there are some
>> others where TX traffic is simply broken.
>> There are probably multiple reasons why it's working on some boards
>> while it's broken on others:
>> - some of Amlogic's reference boards are using a Micrel PHY
>> - hardware circuit design
>> - maybe more...
>>
>> This raises a question though:
>> Which device is supposed to enable the TX delay when both MAC and PHY
>> support it? And should we implement it for each PHY / MAC separately
>> or should we think about a more generic solution (currently it's not
>> possible to disable the TX delay generated by the RTL8211F PHY via
>> devicetree when using phy-mode "rgmii")?
>
> Actually you can skip the part which activate the Tx-delay on the phy
> by setting "phy-mode = "rgmii-id" instead of "rgmii"
>
> phy->interface will no longer be PHY_INTERFACE_MODE_RGMII
> but PHY_INTERFACE_MODE_RGMII_ID.
unfortunately this is not true for RTL8211F (I did my previous tests
with the same expectation in mind)!
the code seems to suggest that TX-delay is disabled whenever mode !=
PHY_INTERFACE_MODE_RGMII.
BUT: on my device RTL8211F_TX_DELAY is set even before
"phy_write(phydev, 0x11, reg);"!
Based on what I found it seems that rgmii-id, rgmii-txid and
rgmii-rxid are supposed to be handled by the PHY.
That would mean that we have two problems here:
1) drivers/net/phy/realtek.c:rtl8211f_config_init should check for
PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID and
enable the TX-delay in that case - otherwise explicitly disable it
2) dwmac-meson8b.c should only use the configured TX-delay for
PHY_INTERFACE_MODE_RGMII
@Florian: could you please share your thoughts on this (who handles
the TX delay in which case)?
Regards,
Martin
^ permalink raw reply
* [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue
From: Martin Blumenstingl @ 2016-11-24 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480003306.17538.137.camel@baylibre.com>
On Thu, Nov 24, 2016 at 5:01 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Thu, 2016-11-24 at 15:40 +0100, Martin Blumenstingl wrote:
>> Hi Jerome,
>>
>> On Mon, Nov 21, 2016 at 4:35 PM, Jerome Brunet <jbrunet@baylibre.com>
>> wrote:
>> >
>> > This patchset fixes an issue with the OdroidC2 board (DWMAC +
>> > RTL8211F).
>> > Initially reported as a low Tx throughput issue at gigabit speed,
>> > the
>> > platform enters LPI too often. This eventually break the link (both
>> > Tx
>> > and Rx), and require to bring the interface down and up again to
>> > get the
>> > Rx path working again.
>> >
>> > The root cause of this issue is not fully understood yet but
>> > disabling EEE
>> > advertisement on the PHY prevent this feature to be negotiated.
>> > With this change, the link is stable and reliable, with the
>> > expected
>> > throughput performance.
>> I have just sent a series which allows configuring the TX delay on
>> the
>> MAC (dwmac-meson8b glue) side: [0]
>> Disabling the TX delay generated by the MAC fixes TX throughput for
>> me, even when leaving EEE enabled in the RTL8211F PHY driver!
>>
>> Unfortunately the RTL8211F PHY is a black-box for the community
>> because there is no public datasheeet available.
>> *maybe* (pure speculation!) they're enabling the TX delay based on
>> some internal magic only when EEE is enabled.
>
> Hi already tried acting on the register setting the TX_delay. I also
> tried on the PHY. I never been able to improve situation on the
> Odroic2. Only disabling EEE improved the situation.
OK, thanks for clarifying this!
> To make sure, i tried again with your patch but the result remains
> unchanged. With Tx_delay disabled (either the mac or the phy), the
> situation is even worse, it seems that nothing gets through
This is interesting, because in your case you should have a 4ns TX
delay (2ns from the MAC and presumably 2ns from the PHY).
Maybe that is also the reason why the TX delay is configurable in 2ns
steps in PRG_ETHERNET0 on Amlogic SoCs.
out of curiosity: have you tried setting a 4ns (half clock-cycle) TX
delay for the MAC and disabling it in the PHY?
Regards,
Martin
^ permalink raw reply
* [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support
From: Chris Paterson @ 2016-11-24 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXO=uFuJCXPjkdYB_CeyfPMqy6cMrOW=s1DZzcJ9Gp33A@mail.gmail.com>
Hello Geert,
From: geert.uytterhoeven@gmail.com
Sent: 24 November 2016 16:42
> Hi Chris,
>
> On Thu, Nov 24, 2016 at 3:25 PM, Chris Paterson
> <Chris.Paterson2@renesas.com> wrote:
> > From: Simon Horman [mailto:horms at verge.net.au]
> > Sent: 24 November 2016 10:18
> >> On Thu, Nov 24, 2016 at 10:05:08AM +0000, Chris Paterson wrote:
> >> > From: Simon Horman [mailto:horms at verge.net.au]
> >> > > Regarding the arch/arm64/boot/dts/renesas/ portion, I would like
> >> > > some consideration given to what effect enabling memory above 4Gb
> >> > > (64bit
> >> > > addressing) would have.
> >> >
> >> > Can you give me some guidance here? I'm not sure what you're
> >> > referring to. As far as I know the DT reg definition here is
> >> > 64-bit, or are you referring to DMA usage? If the later, neither CAN
> driver uses DMA.
> >>
> >> Sorry for not being clearer.
> >>
> >> What I would like to know is if there are any problems in the CAN
> >> driver or hardware that would prevent it from functioning with memory
> >> that requires 64bit addressing present.
> >>
> >> If the CAN hardware cannot use DMA then DMA doesn't need to be
> taken
> >> into account. But if it DMA could be enabled in future for CAN, for
> >> example after some driver enhancements, then it would be good to know
> >> if 64bit memory can be supported - if not it would imply DMA cannot be
> enabled.
> >
> > Thank you for the clarification.
> >
> > The CAN interface for r8a7795/6 does not support DMA.
> >
> > With CAN FD there is currently a H/W issue that means DMA is unusable.
>
> Is that issue present on R-Car M3-W, or only on R-Car H3 ES1.x?
Both
>
> > Potentially this issue could be fixed in the future and DMA support
> > could be added to the driver. If this happens I can see no reason why
> > the CAN FD IP wouldn't be able to handle DMA transfers when using 64bit
> addressing.
>
> Yep, AFAIK it uses SYS-DMAC, which supports 64-bit addressing.
Yep
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-
> m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* [PATCH v28 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Catalin Marinas @ 2016-11-24 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124095944.7167-1-takahiro.akashi@linaro.org>
On Thu, Nov 24, 2016 at 06:59:44PM +0900, AKASHI Takahiro wrote:
> From: James Morse <james.morse@arm.com>
>
> Add documentation for
> linux,crashkernel-base and crashkernel-size,
> linux,usable-memory-range
> linux,elfcorehdr
> used by arm64 kdump to decribe the kdump reserved area, and
> the elfcorehdr's location within it.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> [takahiro.akashi at linaro.org: added "linux,crashkernel-base" and "-size" ]
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
Rob, Mark, are you ok with this patch?
--
Catalin
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Afzal Mohammed @ 2016-11-24 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123191621.GD14217@n2100.armlinux.org.uk>
Hi,
On Wed, Nov 23, 2016 at 07:16:21PM +0000, Russell King - ARM Linux wrote:
> Well, !MMU and multiplatform _are_ exclusive in reality. One of the
> things we work around in multiplatform is the different physical
> address space layouts of the platforms, particularly with where RAM
> is located. That's not possible in !MMU configurations. A kernel
> built to support every platform in multiplatform will not boot on
> most of them.
>
> So efforts to make !MMU work with multiplatform are IMHO rather
> misguided.
>
> !MMU makes sense with classifications of systems (like the Cortex-M*
> based systems) but not everything.
Okay, seems you were referring to AUTO_ZRELADDR or if you had
something else in mind, please let me know.
The plan was to use Image instead of zImage. Here there are 2
platforms, Freescale's, oh no, NXP's, oh no no, Qualcomm's Vybrid
(vf610) and TI's Sitara siblings (am335x beagle & am437x). It was
thought that though changes might have to be made b/n them, at least
it might be easier using same defconfig, thus went by multi_v7.
Though have been able to build for !MMU, have not yet been successful
in seeing any activity on the console, probably will have to put
printascii() into service.
Regards
afzal
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Afzal Mohammed @ 2016-11-24 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5835BEBA.8050905@arm.com>
Hi,
On Wed, Nov 23, 2016 at 04:07:22PM +0000, Vladimir Murzin wrote:
> I think this one is fixed by
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 8e7496c..c3349b9 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -2019,7 +2019,7 @@ config XIP_PHYS_ADDR
> config KEXEC
> bool "Kexec system call (EXPERIMENTAL)"
> depends on (!SMP || PM_SLEEP_SMP)
> - depends on !CPU_V7M
> + depends on MMU
> These we fixed in 9001214 ("ARM: imx: no need to select SMP_ON_UP explicitly")
> Thanks for trying it. Just a gentle remainder not to forget to set DRAM_BASE
> and DRAM_SIZE ;)
Thanks for the info.
Based on your feedback, have been able to build multi_v7 w/ MMU & SMP
disabled.
Trying to get something in the console on Cortex A platform.
Regards
afzal
^ permalink raw reply
* [PATCH 4/4] crypto: arm/crct10dif - port x86 SSE implementation to ARM
From: Ard Biesheuvel @ 2016-11-24 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480002201-1427-5-git-send-email-ard.biesheuvel@linaro.org>
On 24 November 2016 at 15:43, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> This is a straight transliteration of the Intel algorithm implemented
> using SSE and PCLMULQDQ instructions that resides under in the file
> arch/x86/crypto/crct10dif-pcl-asm_64.S.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm/crypto/Kconfig | 5 +
> arch/arm/crypto/Makefile | 2 +
> arch/{arm64 => arm}/crypto/crct10dif-ce-core.S | 457 +++++++++++---------
> arch/{arm64 => arm}/crypto/crct10dif-ce-glue.c | 23 +-
> 4 files changed, 277 insertions(+), 210 deletions(-)
>
This patch needs the following hunk folded in to avoid breaking the
Thumb2 build:
"""
diff --git a/arch/arm/crypto/crct10dif-ce-core.S
b/arch/arm/crypto/crct10dif-ce-core.S
index 30168b0f8581..4fdbca94dd0c 100644
--- a/arch/arm/crypto/crct10dif-ce-core.S
+++ b/arch/arm/crypto/crct10dif-ce-core.S
@@ -152,7 +152,8 @@ CPU_LE( vrev64.8 q7, q7 )
// XOR the initial_crc value
veor.8 q0, q0, q10
- adrl ip, rk3
+ARM( adrl ip, rk3 )
+THUMB( adr ip, rk3 )
vld1.64 {q10}, [ip] // xmm10 has rk3 and rk4
// type of pmull instruction
// will determine which constant to use
"""
Updated patch(es) can be found here
https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/log/?h=arm-crct10dif
^ permalink raw reply related
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Vladimir Murzin @ 2016-11-24 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124172826.GB3524@afzalpc>
On 24/11/16 17:28, Afzal Mohammed wrote:
> Hi,
>
> On Wed, Nov 23, 2016 at 04:07:22PM +0000, Vladimir Murzin wrote:
>
>> I think this one is fixed by
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 8e7496c..c3349b9 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -2019,7 +2019,7 @@ config XIP_PHYS_ADDR
>> config KEXEC
>> bool "Kexec system call (EXPERIMENTAL)"
>> depends on (!SMP || PM_SLEEP_SMP)
>> - depends on !CPU_V7M
>> + depends on MMU
>
>> These we fixed in 9001214 ("ARM: imx: no need to select SMP_ON_UP explicitly")
>
>> Thanks for trying it. Just a gentle remainder not to forget to set DRAM_BASE
>> and DRAM_SIZE ;)
>
> Thanks for the info.
>
> Based on your feedback, have been able to build multi_v7 w/ MMU & SMP
> disabled.
>
> Trying to get something in the console on Cortex A platform.
Make sure you have ARM_MPU disabled, otherwise it will die early (I keep
proper patch for that here).
Cheers
Vladimir
>
> Regards
> afzal
>
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Russell King - ARM Linux @ 2016-11-24 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124172535.GA3524@afzalpc>
On Thu, Nov 24, 2016 at 10:55:35PM +0530, Afzal Mohammed wrote:
> Hi,
>
> On Wed, Nov 23, 2016 at 07:16:21PM +0000, Russell King - ARM Linux wrote:
>
> > Well, !MMU and multiplatform _are_ exclusive in reality. One of the
> > things we work around in multiplatform is the different physical
> > address space layouts of the platforms, particularly with where RAM
> > is located. That's not possible in !MMU configurations. A kernel
> > built to support every platform in multiplatform will not boot on
> > most of them.
> >
> > So efforts to make !MMU work with multiplatform are IMHO rather
> > misguided.
> >
> > !MMU makes sense with classifications of systems (like the Cortex-M*
> > based systems) but not everything.
>
> Okay, seems you were referring to AUTO_ZRELADDR or if you had
> something else in mind, please let me know.
No, I'm talking about the kernel proper itself.
> The plan was to use Image instead of zImage. Here there are 2
> platforms, Freescale's, oh no, NXP's, oh no no, Qualcomm's Vybrid
> (vf610) and TI's Sitara siblings (am335x beagle & am437x).
Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building
for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE
to be the appropriate size of RAM.
You'll be able to run the same "Image" kernel on the other platforms
_if_ and _only_ _if_ they have RAM covering the same region.
That's my point - the kernel image will be linked to place its
read-write data at a certain location in the address space, and if
you have the MMU disabled (or in 1:1 translation mode) you _must_
have RAM at that location.
The reason multiplatform works is because we use the MMU to abstract
away the differences in the location of RAM on the platform (amongst
other things.)
Also note that Cortex-A class CPUs don't perform well with the MMU
off, because you can't enable the data cache - and you must have the
data cache enabled for SMP to be functional, and it's also required
for exclusives to work.
There's also some cases where "Device, non-shared" must be used to
access some devices, which can only be done with the MMU enabled.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros
From: Vladimir Murzin @ 2016-11-24 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58347A61.306@arm.com>
On 22/11/16 17:03, Vladimir Murzin wrote:
> On 22/11/16 11:54, Russell King - ARM Linux wrote:
>> On Tue, Nov 22, 2016 at 11:50:57AM +0000, Vladimir Murzin wrote:
>>> On 22/11/16 10:07, Russell King - ARM Linux wrote:
>>>> On Tue, Nov 22, 2016 at 09:26:06AM +0000, Vladimir Murzin wrote:
>>>>> Pickup defines from pgtable-2level.h to make NOMMU build happy.
>>>>
>>>> This needs more detail.
>>>>
>>>
>>> It comes from
>>>
>>> CC arch/arm/kernel/setup.o
>>> arch/arm/kernel/setup.c: In function 'reserve_crashkernel':
>>> arch/arm/kernel/setup.c:1001:25: error: 'SECTION_SIZE' undeclared (first use in this function)
>>> crash_size, SECTION_SIZE);
>>> ^
>>> arch/arm/kernel/setup.c:1001:25: note: each undeclared identifier is reported only once for each function it appears in
>>> make[1]: *** [arch/arm/kernel/setup.o] Error 1
>>> make: *** [arch/arm/kernel] Error 2
>>
>> Hmm, I decided not to use CRASH_ALIGN there because I didn't want to
>> break anyone's existing setup unnecessarily, however arguably it
>> should be CRASH_ALIGN to ensure that the new kernel is properly
>> positioned.
>>
>> I wonder if we can get away with changing that, rather than
>> unnecessarily introducing these otherwise meaningless definitions
>> for R-class.
>>
>
> CRASH_ALIGN works fine but it seems not only user of SECTION_SIZE
>
> In file included from ./include/linux/cache.h:4:0,
> from ./include/linux/printk.h:8,
> from ./include/linux/kernel.h:13,
> from arch/arm/mach-omap2/omap-secure.c:15:
> arch/arm/mach-omap2/omap-secure.c: In function 'omap_secure_ram_reserve_memblock':
> arch/arm/mach-omap2/omap-secure.c:65:21: error: 'SECTION_SIZE' undeclared (first use in this function)
> size = ALIGN(size, SECTION_SIZE);
> ^
> ./include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK'
> #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
> ^
> ./include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
> #define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
> ^
> arch/arm/mach-omap2/omap-secure.c:65:9: note: in expansion of macro 'ALIGN'
> size = ALIGN(size, SECTION_SIZE);
> ^
> arch/arm/mach-omap2/omap-secure.c:65:21: note: each undeclared identifier is reported only once for each function it appears in
> size = ALIGN(size, SECTION_SIZE);
> ^
> ./include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK'
> #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
> ^
> ./include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
> #define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
> ^
> arch/arm/mach-omap2/omap-secure.c:65:9: note: in expansion of macro 'ALIGN'
> size = ALIGN(size, SECTION_SIZE);
> ^
> make[1]: *** [arch/arm/mach-omap2/omap-secure.o] Error 1
Russell, do you have further comment on this? I would try to address them in
the next version.
Thanks!
Vladimir
>
> Cheers
> Vladimir
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [RFC PATCH 06/11] ARM: tlbflush: drop dependency on CONFIG_SMP
From: Vladimir Murzin @ 2016-11-24 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <583449F9.6060804@arm.com>
On 22/11/16 13:36, Vladimir Murzin wrote:
> On 22/11/16 10:03, Russell King - ARM Linux wrote:
>> On Tue, Nov 22, 2016 at 09:26:03AM +0000, Vladimir Murzin wrote:
>>> It can be referenced in UP case as well.
>>
>> What's missing is an explanation of why you want this change.
>> Exposing the local_* stuff doesn't make sense for UP.
>
> It comes from:
>
> arch/arm/mach-mvebu/pmsu.c: In function 'armada_370_xp_pmsu_idle_enter':
> arch/arm/mach-mvebu/pmsu.c:291:2: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]
> local_flush_tlb_all();
> ^
>
> make[1]: *** [arch/arm/mach-mvebu/pmsu.o] Error 1
>
> and
>
> arch/arm/mach-imx/pm-imx5.c: In function 'mx5_suspend_enter':
> arch/arm/mach-imx/pm-imx5.c:227:3: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]
>
> local_flush_tlb_all();
> ^
> cc1: some warnings being treated as errors
> make[1]: *** [arch/arm/mach-imx/pm-imx5.o] Error 1
>
> Maybe there are other users, please, let me know if you want me to count them
> all.
Russell, is it a good argument to expose the local_* stuff or it should be
addressed differently?
Thanks
Vladimir
>
> Cheers
> Vladimir
>
>>
>>> Cc: Russell King <linux@armlinux.org.uk>
>>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>> ---
>>> arch/arm/include/asm/tlbflush.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
>>> index def9e57..d9a6e2e 100644
>>> --- a/arch/arm/include/asm/tlbflush.h
>>> +++ b/arch/arm/include/asm/tlbflush.h
>>> @@ -641,7 +641,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
>>>
>>> #endif
>>>
>>> -#elif defined(CONFIG_SMP) /* !CONFIG_MMU */
>>> +#else /* !CONFIG_MMU */
>>>
>>> #ifndef __ASSEMBLY__
>>>
>>> --
>>> 1.7.9.5
>>>
>>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Afzal Mohammed @ 2016-11-24 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124173532.GH14217@n2100.armlinux.org.uk>
Hi,
On Thu, Nov 24, 2016 at 05:35:32PM +0000, Russell King - ARM Linux wrote:
> Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building
> for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE
> to be the appropriate size of RAM.
Hmm.., i had thought that Vybrid's memory mappings starts from
0x80000000 (same TI Sitara's), just rechecked the older boot logs of
Vybrid & Data manual, it seems it is @0x80000000, probably iMX6 has a
different map.
> Also note that Cortex-A class CPUs don't perform well with the MMU
> off, because you can't enable the data cache - and you must have the
> data cache enabled for SMP to be functional, and it's also required
> for exclusives to work.
Yes, was aware of the performance degradation due to disabled dcache.
Here the platforms at my disposal are all single core - vf610, am335x
& am437x (though strictly speaking 2 of them are ARM SMP
configurations, but with number of cores as 1). Seems at least from
SMP pov, not expecting issues as they are single core (SMP disabled
kernel with MMU enabled works on those)
> There's also some cases where "Device, non-shared" must be used to
> access some devices, which can only be done with the MMU enabled.
Thanks for your valuable feedbacks.
Regards
afzal
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Afzal Mohammed @ 2016-11-24 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5837246D.5080106@arm.com>
Hi,
On Thu, Nov 24, 2016 at 05:33:33PM +0000, Vladimir Murzin wrote:
> Make sure you have ARM_MPU disabled, otherwise it will die early (I keep
> proper patch for that here).
Hmm.., thanks, that is enabled here, will disable it & proceed.
Regards
afzal
^ permalink raw reply
* [PATCH 9/9] arm64: Documentation - Expose CPU feature registers
From: Catalin Marinas @ 2016-11-24 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479994809-9081-10-git-send-email-suzuki.poulose@arm.com>
Hi Suzuki,
On Thu, Nov 24, 2016 at 01:40:09PM +0000, Suzuki K. Poulose wrote:
> --- /dev/null
> +++ b/Documentation/arm64/cpu-feature-registers.txt
> @@ -0,0 +1,198 @@
> + ARM64 CPU Feature Registers
> + ===========================
> +
> +Author: Suzuki K Poulose <suzuki.poulose@arm.com>
> +
> +
> +This file describes the API for exporting the AArch64 CPU ID/feature
> +registers to userspace. The availability of this API is advertised
> +via the HWCAP_CPUID in HWCAPs.
s/API/ABI/ maybe?
> +
> +1. Motivation
> +---------------
> +
> +The ARM architecture defines a set of feature registers, which describe
> +the capabilities of the CPU/system. Access to these system registers is
> +restricted from EL0 and there is no reliable way for an application to
> +extract this information to make better decisions at runtime. There is
> +limited information available to the application via HWCAPs, however
> +there are some issues with their usage.
> +
> + a) Any change to the HWCAPs requires an update to userspace (e.g libc)
> + to detect the new changes, which can take a long time to appear in
> + distributions. Exposing the registers allows applications to get the
> + information without requiring updates to the toolchains.
> +
> + b) Access to HWCAPs is sometimes limited (e.g prior to libc, or
> + when ld is initialised at startup time).
> +
> + c) HWCAPs cannot represent non-boolean information effectively. The
> + architecture defines a canonical format for representing features
> + in the ID registers; this is well defined and is capable of
> + representing all valid architecture variations. Exposing the ID
> + registers avoids having to come up with HWCAP representations and
> + parsing code.
For point (c) above, we don't (yet?) have an actual case on AArch64
where HWCAP needs more than a boolean value.
And just to clarify my position: I consider that we should continue to
expose HWCAP for new features (e.g. SVE) in parallel with the CPUID
access emulation. There are different use-cases for them (i.e. dynamic
loader uses HWCAP for the ifunc resolver).
> +3. Implementation
> +--------------------
> +
> +The infrastructure is built on the emulation of the 'MRS' instruction.
> +Accessing a restricted system register from an application generates an
> +exception and ends up in SIGILL being delivered to the process.
> +The infrastructure hooks into the exception handler and emulates the
> +operation if the source belongs to the supported system register space.
> +
> +The infrastructure emulates only the following system register space:
> + Op0=3, Op1=0, CRn=0
> +
> +(See Table C5-6 'System instruction encodings for non-Debug System
> +register accesses' in ARMv8 ARM DDI 0487A.h, for the list of
> +registers).
> +
> +
> +The following rules are applied to the value returned by the
> +infrastructure:
> +
> + a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0.
> + b) The value of a reserved field is populated with the reserved
> + value as defined by the architecture.
> + c) The value of a field marked as not 'visible', is set to indicate
> + the feature is missing (as defined by the architecture).
I don't understand point (c) above. If it is marked as not 'visible', it
is always reported to user as 0. The above could be misinterpreted as
reporting missing architecture features.
[...]
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 94c188f..fb331de 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -81,6 +81,10 @@ static bool __maybe_unused
> cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry, int __unused);
>
>
> +/*
> + * NOTE: Any changes to the visibility of features should be kept in
> + * sync with the documentation of the CPU feature register API.
s/API/ABI/
--
Catalin
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Russell King - ARM Linux @ 2016-11-24 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124180751.GA5258@afzalpc>
On Thu, Nov 24, 2016 at 11:37:51PM +0530, Afzal Mohammed wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 05:35:32PM +0000, Russell King - ARM Linux wrote:
>
> > Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building
> > for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE
> > to be the appropriate size of RAM.
>
> Hmm.., i had thought that Vybrid's memory mappings starts from
> 0x80000000 (same TI Sitara's), just rechecked the older boot logs of
> Vybrid & Data manual, it seems it is @0x80000000, probably iMX6 has a
> different map.
Right, so if you build a multiplatform kernel which covers TI Sitara
and iMX6, then you have a choice:
- Set DRAM_START to 0x10000000, and have a kernel which will boot on
iMX6 but fail on TI Sitara.
- Set DRAM_START to 0x80000000, and have a kernel which will boot on
TI Sitara, but fail on iMX6 with less than 2GiB of memory (0x70000000
bytes to be exact.)
This is why multiplatform doesn't make sense for noMMU - you can't
actually build a multiplatform kernel that will work across all
these platforms.
You'd have to re-link it (at the very least) to place the data section
elsewhere in physical memory to make it work.
It's this reason that I don't like removing the "depends on MMU" from
multiplatform - it gives the incorrect impression that we _can_ support
a wide range of systems, but what it will lead to is a kernel that will
work on some platforms but not others. The result will be more "bug"
reports because the kernel fails to boot...
In any case, I think kernelci and similar would first need to be updated
to avoid trying to boot noMMU kernels on hardware which it just can't
boot on - we _really_ do not want to be randomly scribbling into physical
memory, potentially hitting devices, especially with devices that contain
OTP fuses that set options as security features.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Florian Fainelli @ 2016-11-24 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCB7sXjXor++W+PW0-j_VxATRzhexjqHgXj2jD10tBpZFg@mail.gmail.com>
Le 24/11/2016 ? 09:05, Martin Blumenstingl a ?crit :
> On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
>> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
>>> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
>>> cycle TX clock delay. This seems to work fine for many boards (for
>>> example Odroid-C2 or Amlogic's reference boards) but there are some
>>> others where TX traffic is simply broken.
>>> There are probably multiple reasons why it's working on some boards
>>> while it's broken on others:
>>> - some of Amlogic's reference boards are using a Micrel PHY
>>> - hardware circuit design
>>> - maybe more...
>>>
>>> This raises a question though:
>>> Which device is supposed to enable the TX delay when both MAC and PHY
>>> support it? And should we implement it for each PHY / MAC separately
>>> or should we think about a more generic solution (currently it's not
>>> possible to disable the TX delay generated by the RTL8211F PHY via
>>> devicetree when using phy-mode "rgmii")?
>>
>> Actually you can skip the part which activate the Tx-delay on the phy
>> by setting "phy-mode = "rgmii-id" instead of "rgmii"
>>
>> phy->interface will no longer be PHY_INTERFACE_MODE_RGMII
>> but PHY_INTERFACE_MODE_RGMII_ID.
> unfortunately this is not true for RTL8211F (I did my previous tests
> with the same expectation in mind)!
> the code seems to suggest that TX-delay is disabled whenever mode !=
> PHY_INTERFACE_MODE_RGMII.
> BUT: on my device RTL8211F_TX_DELAY is set even before
> "phy_write(phydev, 0x11, reg);"!
(Adding Sebastian (and Mans, and Andrew) since he raised the same
question a while ago. I think I now understand a bit better what
Sebastian was after a couple of weeks ago)
>
> Based on what I found it seems that rgmii-id, rgmii-txid and
> rgmii-rxid are supposed to be handled by the PHY.
Correct, the meaning of PHY_INTERFACE_MODE should be from the
perspective of the PHY device:
- PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
- PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)
> That would mean that we have two problems here:
> 1) drivers/net/phy/realtek.c:rtl8211f_config_init should check for
> PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID and
> enable the TX-delay in that case - otherwise explicitly disable it
Agreed.
> 2) dwmac-meson8b.c should only use the configured TX-delay for
> PHY_INTERFACE_MODE_RGMII
> @Florian: could you please share your thoughts on this (who handles
> the TX delay in which case)?
This also seems reasonable to do, provided that the PHY is also properly
configured not to add delays in both directions, and therefore assumes
that the MAC does it.
We have a fairly large problem with how RGMII delays are done in PHYLIB
and Ethernet MAC drivers (or just in general), where we can't really
intersect properly what a PHY is supporting (in terms of internal
delays), and what the MAC supports either. One possible approach could
be to update PHY drivers a list of PHY_INTERFACE_MODE_* that they
support (ideally, even with normalized nanosecond delay values), and
then intersect that with the requested phy_interface_t during
phy_{attach,connect} time, and feed this back to the MAC with a special
error code/callback, so we could gracefully try to choose another
PHY_INTERFACE_MODE_* value that the MAC supports....
A larger problem is that a number of drivers have been deployed, and
Device Trees, possibly with the meaning of "phy-mode" and
"phy-connection-type" being from the MAC perspective, and not the PHY
perspective *sigh*, good luck auditing those.
So from there, here is possibly what we could do
- submit a series of patches that update the PHYLIB documentation (there
are other things missing here) and make it clear from which entity (PHY
or MAC) does the delay apply to, document the "intersection" problem here
- have you document the configured behavior for dwmac-meson8b that we
just discussed here in v2 of this patch series
Sorry for the long post, here is a virtual potato: 0
--
Florian
^ permalink raw reply
* [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Florian Fainelli @ 2016-11-24 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8760ncly5s.fsf@free-electrons.com>
Le 24/11/2016 ? 07:01, Gregory CLEMENT a ?crit :
> Hi Arnd,
>
> On jeu., nov. 24 2016, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Thursday, November 24, 2016 4:37:36 PM CET Jisheng Zhang wrote:
>>> solB (a SW shadow cookie) perhaps gives a better performance: in hot path,
>>> such as mvneta_rx(), the driver accesses buf_cookie and buf_phys_addr of
>>> rx_desc which is allocated by dma_alloc_coherent, it's noncacheable if the
>>> device isn't cache-coherent. I didn't measure the performance difference,
>>> because in fact we take solA as well internally. From your experience,
>>> can the performance gain deserve the complex code?
>>
>> Yes, a read from uncached memory is fairly slow, so if you have a chance
>> to avoid that it will probably help. When adding complexity to the code,
>> it probably makes sense to take a runtime profile anyway quantify how
>> much it gains.
>>
>> On machines that have cache-coherent DMA, accessing the descriptor
>> should be fine, as you already have to load the entire cache line
>> to read the status field.
>>
>> Looking at this snippet:
>>
>> rx_status = rx_desc->status;
>> rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
>> data = (unsigned char *)rx_desc->buf_cookie;
>> phys_addr = rx_desc->buf_phys_addr;
>> pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
>> bm_pool = &pp->bm_priv->bm_pools[pool_id];
>>
>> if (!mvneta_rxq_desc_is_first_last(rx_status) ||
>> (rx_status & MVNETA_RXD_ERR_SUMMARY)) {
>> err_drop_frame_ret_pool:
>> /* Return the buffer to the pool */
>> mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
>> rx_desc->buf_phys_addr);
>> err_drop_frame:
>>
>>
>> I think there is more room for optimizing if you start: you read
>> the status field twice (the second one in MVNETA_RX_GET_BM_POOL_ID)
>> and you can cache the buf_phys_addr along with the virtual address
>> once you add that.
>
> I agree we can optimize this code but it is not related to the 64 bits
> conversion. Indeed this part is running when we use the HW buffer
> management, however currently this part is not ready at all for 64
> bits. The virtual address is directly handled by the hardware but it has
> only 32 bits to store it in the cookie.So if we want to use the HWBM in
> 64 bits we need to redesign the code, (maybe by storing the virtual
> address in a array and pass the index in the cookie).
Can't you make sure that skb->data is aligned to a value big enough that
you can still cover the <N> bit physical address space of the adapter
within a 32-bit quantity if you drop the low bits that would be all zeroes?
That way, even though you only have 32-bits of storage/cookie, these
don't have to be the actual 32-bits of your original address, but could
be addr >> 8 for instance?
As you indicate using an index stored in the cookie might be a better
scheme though, since you could attach a lot more metadata to an index in
an local array (which could be in cached memory) as opposed to just an
address.
--
Florian
^ 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