* Tearing down DMA transfer setup after DMA client has finished
From: Russell King - ARM Linux @ 2016-11-25 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1x1sxz8vxm.fsf@unicorn.mansr.com>
On Fri, Nov 25, 2016 at 02:40:21PM +0000, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>
> > On Fri, Nov 25, 2016 at 02:03:20PM +0000, M?ns Rullg?rd wrote:
> >> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> >>
> >> > On Fri, Nov 25, 2016 at 01:50:35PM +0000, M?ns Rullg?rd wrote:
> >> >> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> >> >> > It would be unfair to augment the API and add the burden on everyone
> >> >> > for the new API when 99.999% of the world doesn't require it.
> >> >>
> >> >> I don't think making this particular dma driver wait for the descriptor
> >> >> callback to return before reusing a channel quite amounts to a horrid
> >> >> hack. It certainly wouldn't burden anyone other than the poor drivers
> >> >> for devices connected to it, all of which are specific to Sigma AFAIK.
> >> >
> >> > Except when you stop to think that delaying in a tasklet is exactly
> >> > the same as randomly delaying in an interrupt handler - the tasklet
> >> > runs on the return path back to the parent context of an interrupt
> >> > handler. Even if you sleep in the tasklet, you're sleeping on behalf
> >> > of the currently executing thread - if it's a RT thread, you effectively
> >> > destroy the RT-ness of the thread. Let's hope no one cares about RT
> >> > performance on that hardware...
> >>
> >> That's why I suggested to do this only if the needed delay is known to
> >> be no more than a few bus cycles. The completion callback is currently
> >> the only post-transfer interaction we have between the dma and device
> >> drivers. To handle an arbitrarily long delay, some new interface will
> >> be required.
> >
> > And now we're back at the point I made a few emails ago about undue
> > burden which is just about quoted above...
>
> So what do you suggest? Stick our heads in the sand and pretend
> everything is perfect?
Look, if you're going to be arsey, don't be surprised if I start getting
the urge to repeat previous comments.
Let's try and keep this on a technical basis for once, rather than
decending into insults.
So, wind back to my original email where I started talking about PL08x
already doing something along these lines. Before a DMA user can make
use of a DMA channel, it has to be requested. Once a DMA user has
finished, it can free up the channel.
What this means is that there's already a solution here - but it depends
how many DMA channels and how many active DMA users there are. It's
entirely possible to set the mapping up when a DMA user requests a
DMA channel, leave it setup, and only tear it down when the channel
is eventually freed.
At that point, there's no need to spin-wait or sleep to delay the
tear-down of the channel - and I'd suggest that approach _until_
such time that there are more users than there are DMA channels. This
has minimal overhead, it doesn't screw up RT threads (which include
IRQ threads), and it doesn't spread the maintanence burden across
drivers with a new custom API just for one SoC.
If (or when) the number of active users exceeds the number of hardware
DMA channels, then there's a decision to be made:
1) either limit the number of peripherals that we support DMA on for
the SoC.
2) add the delay or API as necessary and switch to dynamic channel
allocation to incoming requests.
Until that point is reached, there's no point inventing new APIs for
something that isn't actually a problem yet.
--
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
* [PATCH 2/2] usb: ohci: s3c2410: allow probing from device tree
From: Sergio Prado @ 2016-11-25 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480085249-25014-1-git-send-email-sergio.prado@e-labworks.com>
Allows configuring Samsung's s3c2410 USB OHCI controller using a
devicetree.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
drivers/usb/host/ohci-s3c2410.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index 7a1919ca543a..d8e03a801f2e 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -457,6 +457,13 @@ static int ohci_hcd_s3c2410_drv_resume(struct device *dev)
.resume = ohci_hcd_s3c2410_drv_resume,
};
+static const struct of_device_id ohci_hcd_s3c2410_dt_ids[] = {
+ { .compatible = "samsung,s3c2410-ohci" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, ohci_hcd_s3c2410_dt_ids);
+
static struct platform_driver ohci_hcd_s3c2410_driver = {
.probe = ohci_hcd_s3c2410_drv_probe,
.remove = ohci_hcd_s3c2410_drv_remove,
@@ -464,6 +471,7 @@ static int ohci_hcd_s3c2410_drv_resume(struct device *dev)
.driver = {
.name = "s3c2410-ohci",
.pm = &ohci_hcd_s3c2410_pm_ops,
+ .of_match_table = ohci_hcd_s3c2410_dt_ids,
},
};
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: usb: add DT binding for s3c2410 USB OHCI controller
From: Sergio Prado @ 2016-11-25 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480085249-25014-1-git-send-email-sergio.prado@e-labworks.com>
Adds the device tree bindings description for Samsung S3C2410 and
compatible USB OHCI controller.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
.../devicetree/bindings/usb/s3c2410-usb.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/s3c2410-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
new file mode 100644
index 000000000000..e45b38ce2986
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
@@ -0,0 +1,22 @@
+Samsung S3C2410 and compatible SoC USB controller
+
+OHCI
+
+Required properties:
+ - compatible: should be "samsung,s3c2410-ohci" for USB host controller
+ - reg: address and lenght of the controller memory mapped region
+ - interrupts: interrupt number for the USB OHCI controller
+ - clocks: Should reference the bus and host clocks
+ - clock-names: Should contain two strings
+ "usb-bus-host" for the USB bus clock
+ "usb-host" for the USB host clock
+
+Example:
+
+usb0: ohci at 49000000 {
+ compatible = "samsung,s3c2410-ohci";
+ reg = <0x49000000 0x100>;
+ interrupts = <0 0 26 3>;
+ clocks = <&clocks UCLK>, <&clocks HCLK_USBH>;
+ clock-names = "usb-bus-host", "usb-host";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] usb: ohci: s3c2410: add device tree support
From: Sergio Prado @ 2016-11-25 14:47 UTC (permalink / raw)
To: linux-arm-kernel
This series adds support for configuring Samsung's s3c2410 and
compatible USB OHCI controller via devicetree.
Tested on FriendlyARM mini2440, based on s3c2440 SoC.
Sergio Prado (2):
dt-bindings: usb: add DT binding for s3c2410 USB OHCI controller
usb: ohci: s3c2410: allow probing from device tree
.../devicetree/bindings/usb/s3c2410-usb.txt | 22 ++++++++++++++++++++++
drivers/usb/host/ohci-s3c2410.c | 8 ++++++++
2 files changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/s3c2410-usb.txt
--
1.9.1
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da3ddae9-eca2-f67a-1933-25bc7953c201@free.fr>
Mason <slash.tmp@free.fr> writes:
> On 25/11/2016 15:12, M?ns Rullg?rd wrote:
>
>> Mason writes:
>>
>>> On 25/11/2016 12:57, M?ns Rullg?rd wrote:
>>>
>>>> The same DMA unit is also used for SATA, which is an off the shelf
>>>> Designware controller with an in-kernel driver. This interrupt timing
>>>> glitch can actually explain some intermittent errors I've observed with
>>>> it.
>>>
>>> FWIW, newer chips embed an AHCI controller, with a dedicated
>>> memory channel.
>>>
>>> FWIW2, the HW dev said memory channels are "almost free", and he
>>> would have no problem giving each device their own private channel
>>> read/write pair.
>>
>> We still need to deal with the existing hardware.
>
> Can you confirm that your MBUS driver, in its current form,
> does not support memcpy-type transfers, which generate two
> IRQs (one from send agent, one from receive agent)?
It does not.
> Do you plan to support that, or is it just too quirky?
I hadn't planned on doing that, but I'm ruling it out entirely.
--
M?ns Rullg?rd
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125141708.GM14217@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> On Fri, Nov 25, 2016 at 02:03:20PM +0000, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>>
>> > On Fri, Nov 25, 2016 at 01:50:35PM +0000, M?ns Rullg?rd wrote:
>> >> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>> >> > It would be unfair to augment the API and add the burden on everyone
>> >> > for the new API when 99.999% of the world doesn't require it.
>> >>
>> >> I don't think making this particular dma driver wait for the descriptor
>> >> callback to return before reusing a channel quite amounts to a horrid
>> >> hack. It certainly wouldn't burden anyone other than the poor drivers
>> >> for devices connected to it, all of which are specific to Sigma AFAIK.
>> >
>> > Except when you stop to think that delaying in a tasklet is exactly
>> > the same as randomly delaying in an interrupt handler - the tasklet
>> > runs on the return path back to the parent context of an interrupt
>> > handler. Even if you sleep in the tasklet, you're sleeping on behalf
>> > of the currently executing thread - if it's a RT thread, you effectively
>> > destroy the RT-ness of the thread. Let's hope no one cares about RT
>> > performance on that hardware...
>>
>> That's why I suggested to do this only if the needed delay is known to
>> be no more than a few bus cycles. The completion callback is currently
>> the only post-transfer interaction we have between the dma and device
>> drivers. To handle an arbitrarily long delay, some new interface will
>> be required.
>
> And now we're back at the point I made a few emails ago about undue
> burden which is just about quoted above...
So what do you suggest? Stick our heads in the sand and pretend
everything is perfect?
--
M?ns Rullg?rd
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28bb9925-d0d7-9261-27fb-aa79345a19f1@free.fr>
Mason <slash.tmp@free.fr> writes:
> On 25/11/2016 14:11, M?ns Rullg?rd wrote:
>
>> Mason writes:
>>
>>> It seems there is a disconnect between what Linux expects - an IRQ
>>> when the transfer is complete - and the quirks of this HW :-(
>>>
>>> On this system, there are MBUS "agents" connected via a "switch box".
>>> An agent fires an IRQ when it has dealt with its *half* of the transfer.
>>>
>>> SOURCE_AGENT <---> SBOX <---> DESTINATION_AGENT
>>>
>>> Here are the steps for a transfer, in the general case:
>>>
>>> 1) setup the sbox to connect SOURCE TO DEST
>>> 2) configure source to send N bytes
>>> 3) configure dest to receive N bytes
>>>
>>> When SOURCE_AGENT has sent N bytes, it fires an IRQ
>>> When DEST_AGENT has received N bytes, it fires an IRQ
>>> The sbox connection can be torn down only when the destination
>>> agent has received all bytes.
>>> (And the twist is that some agents do not have an IRQ line.)
>>>
>>> The system provides 3 RAM-to-sbox agents (read channels)
>>> and 3 sbox-to-RAM agents (write channels).
>>>
>>> The NAND Flash controller read and write agents do not have
>>> IRQ lines.
>>>
>>> So for a NAND-to-memory transfer (read from device)
>>> - nothing happens when the NFC has finished sending N bytes to the sbox
>>> - the write channel fires an IRQ when it has received N bytes
>>>
>>> In that case, one IRQ fires when the transfer is complete,
>>> like Linux expects.
>>>
>>> For a memory-to-NAND transfer (write to device)
>>> - the read channel fires an IRQ when it has sent N bytes
>>> - the NFC driver is supposed to poll the NFC to determine
>>> when the controller has finished writing N bytes
>>>
>>> In that case, the IRQ does not indicate that the transfer
>>> is complete, merely that the sending half has finished
>>> its part.
>>
>> When does your NAND controller signal completion? When it has received
>> the DMA data, or only when it has finished the actual write operation?
>
> The NAND controller provides a STATUS register.
> Bit 31 is the CMD_READY bit.
> This bit goes to 0 when the controller is busy, and to 1
> when the controller is ready to accept the next command.
>
> The NFC driver is doing:
>
> res = wait_for_completion_timeout(&tx_done, HZ);
> if (res > 0)
> err = readl_poll_timeout(addr, val, val & CMD_READY, 0, 1000);
>
> So basically, sleep until the memory agent IRQ falls,
> then spin until the controller is idle.
This doesn't answer my question. Waiting for the entire operation to
finish isn't necessary. The dma driver only needs to wait until all the
data has been received by the nand controller, not until the controller
is completely finished with the command. Does the nand controller
provide an indication for completion of the dma independently of the
progress of the write command? The dma glue Sigma added to the
Designware sata controller does this.
> Did you see that adding a 10 ?s delay at the start of
> tangox_dma_pchan_detach() makes the system no longer
> fail (passes an mtd_speedtest).
Yes, but maybe that's much longer than is actually necessary.
>>> I think it is possible to have a generic solution:
>>> Right now, the callback is called from tasklet context.
>>> If we can have a new flag to have the callback invoked
>>> directly from the ISR, then the driver for the client
>>> device can do what is required.
>>
>> No, that won't work. The callback shouldn't run in interrupt context.
>
> What if the callback only spun for, at most, 10 ?s ?
>
> readl_poll_timeout(addr, val, val & CMD_READY, 0, 10);
That's far too long to wait in interrupt of tasklet context.
--
M?ns Rullg?rd
^ permalink raw reply
* [RFC PATCH] ARM: dts: Add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-25 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480078151.381.4@smtp.gmail.com>
Hello,
[trimmed Cc: a bit to annoy less]
On 11/25/2016 01:49 PM, Tomas Hlavacek wrote:
> On Thu, Nov 24, 2016 at 4:07 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>> @Tomas: I think it doesn't make sense when we alternate sending patches
>>> without prior arrangement. Do you already work on a v5? If not I can do
>>> that to fix the last few comments. Not sure when a submission is too
>>> late to enter v4.10, but I think the window isn't that big any more.
>>
>> It is getting a bit late. But maybe Linus will add in another -rc
>> week.
To keep the dice rolling I sent a v5 with is somewhere in the middle
between my v3 and Tomas RFC patch. Assuming Tomas is happy with this
change, can we still get it into 4.10? This would help me to put this in
the Debian kernel for the next release.
>>> > No leds? No buttons via gpio-keys?
>>>
>>> The leds are controlled by a Cortex-M0 and without intervention blink
>>> according to a hardware function (network, power, pci). IMHO that's ok
>>> for an initial setup.
>>
>> Yes. That is fine. It is just unusual. Most boards have gpio-led and
>> gpio-keys, which are easy to add. That is why i asked. Adding an LED
>> driver which talks to this M0 can be added later.
>
> Actually the WiP driver for MCU LED interface, that we use in our kernel
> is here:
> https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb
>
>
> It definitely needs some cleanup and it adds non-standard features (main
> PWM for all LEDs, autonomous blink mode, colors) via custom /sys files,
> which I suspect that is not going to be acceptable for upstream. Let's
> keep it for the next iteration.
Ack, the leds are one of the less critical things for the machine. I'd
like to tackle the switch next.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161125/05e21cc2/attachment.sig>
^ permalink raw reply
* [PATCH v17 08/15] clocksource/drivers/arm_arch_timer: move arch_timer_needs_of_probing into DT init call
From: kbuild test robot @ 2016-11-25 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125084623.22515-9-fu.wei@linaro.org>
Hi Fu,
[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.9-rc6]
[cannot apply to tip/timers/core next-20161125]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/fu-wei-linaro-org/acpi-clocksource-add-GTDT-driver-and-GTDT-support-in-arm_arch_timer/20161125-171111
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: the linux-review/fu-wei-linaro-org/acpi-clocksource-add-GTDT-driver-and-GTDT-support-in-arm_arch_timer/20161125-171111 HEAD 498f1f2503da21841b0e7679ddbdb86a40451bdb builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_acpi_init':
>> drivers/clocksource/arm_arch_timer.c:1071:2: error: 'ret' undeclared (first use in this function)
ret = arch_timer_register();
^~~
drivers/clocksource/arm_arch_timer.c:1071:2: note: each undeclared identifier is reported only once for each function it appears in
vim +/ret +1071 drivers/clocksource/arm_arch_timer.c
1065 return -EINVAL;
1066 }
1067
1068 /* Always-on capability */
1069 arch_timer_c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
1070
> 1071 ret = arch_timer_register();
1072 if (ret)
1073 return ret;
1074
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 31917 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161125/cf2e05c2/attachment-0001.gz>
^ permalink raw reply
* [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-25 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125142658.21690-3-uwe@kleine-koenig.org>
On Fri, Nov 25, 2016 at 03:26:58PM +0100, Uwe Kleine-K?nig wrote:
> This machine is an open hardware router by cz.nic driven by a
> Marvell Armada 385.
>
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Mason @ 2016-11-25 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xd1hj8x7i.fsf@unicorn.mansr.com>
On 25/11/2016 15:12, M?ns Rullg?rd wrote:
> Mason writes:
>
>> On 25/11/2016 12:57, M?ns Rullg?rd wrote:
>>
>>> The same DMA unit is also used for SATA, which is an off the shelf
>>> Designware controller with an in-kernel driver. This interrupt timing
>>> glitch can actually explain some intermittent errors I've observed with
>>> it.
>>
>> FWIW, newer chips embed an AHCI controller, with a dedicated
>> memory channel.
>>
>> FWIW2, the HW dev said memory channels are "almost free", and he
>> would have no problem giving each device their own private channel
>> read/write pair.
>
> We still need to deal with the existing hardware.
Can you confirm that your MBUS driver, in its current form,
does not support memcpy-type transfers, which generate two
IRQs (one from send agent, one from receive agent)?
Do you plan to support that, or is it just too quirky?
Regards.
^ permalink raw reply
* [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-25 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125142658.21690-1-uwe@kleine-koenig.org>
This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.
Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 334 ++++++++++++++++++++++++++
2 files changed, 335 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..f1d3b9ff257e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
+ armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 000000000000..bcc10c285889
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,334 @@
+/*
+ * Device Tree file for the Turris Omnia
+ *
+ * Copyright (C) 2016 Uwe Kleine-K?nig <uwe@kleine-koenig.org>
+ * Copyright (C) 2016 Tomas Hlavacek <tmshlvkc@gmail.com>
+ *
+ * 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 licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * 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.
+ */
+
+/*
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+ model = "Turris Omnia";
+ compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>; /* 1024 MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
+ MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+ MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+
+ internal-regs {
+
+ /* USB part of the PCIe2/USB 2.0 port */
+ usb at 58000 {
+ status = "okay";
+ };
+
+ sata at a8000 {
+ status = "okay";
+ };
+
+ sdhci at d8000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhci_pins>;
+ status = "okay";
+
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ };
+
+ usb3 at f0000 {
+ status = "okay";
+ };
+
+ usb3 at f8000 {
+ status = "okay";
+ };
+ };
+
+ pcie-controller {
+ status = "okay";
+
+ pcie at 1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ pcie at 2,0 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+ };
+
+ pcie at 3,0 {
+ /* Port 2, Lane 0 */
+ status = "okay";
+ };
+ };
+ };
+};
+
+/* Connected to 88E6176 switch, port 6 */
+ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* Connected to 88E6176 switch, port 5 */
+ð1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge1_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* WAN port */
+ð2 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy = <&phy1>;
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ i2cmux at 70 {
+ compatible = "nxp,pca9547";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ status = "okay";
+
+ i2c at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ /* STM32F0 command interface at address 0x2a */
+ /* leds device (in STM32F0) at address 0x2b */
+
+ eeprom at 54 {
+ compatible = "at,24c64";
+ reg = <0x54>;
+
+ /* The EEPROM contains data for bootloader.
+ * Contents:
+ * struct omnia_eeprom {
+ * u32 magic; (=0x0341a034 in LE)
+ * u32 ramsize; (in GiB)
+ * char regdomain[4];
+ * u32 crc32;
+ * };
+ */
+ };
+ };
+
+ i2c at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ /* routed to PCIe0/mSATA connector (CN7A) */
+ };
+
+ i2c at 2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ /* routed to PCIe1/USB2 connector (CN61A) */
+ };
+
+ i2c at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ /* routed to PCIe2 connector (CN62A) */
+ };
+
+ i2c at 4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ /* routed to SFP+ */
+ };
+
+ i2c at 5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ /* ATSHA204A at address 0x64 */
+ };
+
+ i2c at 6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ /* exposed on pin header */
+ };
+
+ i2c at 7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ pcawan: gpio at 71 {
+ /*
+ * GPIO expander for SFP+ signals and
+ * and phy irq
+ */
+ compatible = "nxp,pca9538";
+ reg = <0x71>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcawan_pins>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
+};
+
+&mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ status = "okay";
+
+ phy1: phy at 1 {
+ status = "okay";
+ compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+
+ /* irq is connected to &pcawan pin 7 */
+ };
+
+ /* Switch MV88E7176 at address 0x10 */
+};
+
+&pinctrl {
+ pcawan_pins: pcawan-pins {
+ marvell,pins = "mpp46";
+ marvell,function = "gpio";
+ };
+
+ spi0cs0_pins: spi0cs0-pins {
+ marvell,pins = "mpp25";
+ marvell,function = "spi0";
+ };
+
+ spi0cs1_pins: spi0cs1-pins {
+ marvell,pins = "mpp26";
+ marvell,function = "spi0";
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins &spi0cs0_pins>;
+ status = "okay";
+
+ spi-nor at 0 {
+ compatible = "spansion,s25fl164k", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+
+ partition at 0 {
+ reg = <0x0 0x00100000>;
+ label = "U-Boot";
+ };
+
+ partition at 1 {
+ reg = <0x00100000 0x00700000>;
+ label = "Rescue system";
+ };
+ };
+
+ /* MISO, MOSI, SCLK and CS1 are routed to pin header CN11 */
+};
+
+&uart0 {
+ /* Pin header CN10 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart1 {
+ /* Pin header CN11 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "okay";
+};
--
2.10.2
^ permalink raw reply related
* [PATCH v5 1/2] devicetree: Add vendor prefix for CZ.NIC
From: Uwe Kleine-König @ 2016-11-25 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125142658.21690-1-uwe@kleine-koenig.org>
Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..ae9fce9fed03 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -67,6 +67,7 @@ creative Creative Technology Ltd
crystalfontz Crystalfontz America, Inc.
cubietech Cubietech, Ltd.
cypress Cypress Semiconductor Corporation
+cznic CZ.NIC, z.s.p.o.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
--
2.10.2
^ permalink raw reply related
* [PATCH v5 0/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-25 14:26 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This is basicly my v3 plus some of the changes that Tomas changed for
his RFC patch (implicitly "v4"). So compared to v3 the following
changed:
- Add more documentation (mostly from Tomas)
- Add more mbus ranges (by Tomas)
- Move link to schematic below copyright header (suggested by Andrew)
- reenable rtc as this is not that broken on production board
- fix spi chip select pinmuxing
Uwe Kleine-K?nig (2):
devicetree: Add vendor prefix for CZ.NIC
ARM: dts: add support for Turris Omnia
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 334 +++++++++++++++++++++
3 files changed, 336 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
--
2.10.2
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Mason @ 2016-11-25 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xpolj9021.fsf@unicorn.mansr.com>
On 25/11/2016 14:11, M?ns Rullg?rd wrote:
> Mason writes:
>
>> It seems there is a disconnect between what Linux expects - an IRQ
>> when the transfer is complete - and the quirks of this HW :-(
>>
>> On this system, there are MBUS "agents" connected via a "switch box".
>> An agent fires an IRQ when it has dealt with its *half* of the transfer.
>>
>> SOURCE_AGENT <---> SBOX <---> DESTINATION_AGENT
>>
>> Here are the steps for a transfer, in the general case:
>>
>> 1) setup the sbox to connect SOURCE TO DEST
>> 2) configure source to send N bytes
>> 3) configure dest to receive N bytes
>>
>> When SOURCE_AGENT has sent N bytes, it fires an IRQ
>> When DEST_AGENT has received N bytes, it fires an IRQ
>> The sbox connection can be torn down only when the destination
>> agent has received all bytes.
>> (And the twist is that some agents do not have an IRQ line.)
>>
>> The system provides 3 RAM-to-sbox agents (read channels)
>> and 3 sbox-to-RAM agents (write channels).
>>
>> The NAND Flash controller read and write agents do not have
>> IRQ lines.
>>
>> So for a NAND-to-memory transfer (read from device)
>> - nothing happens when the NFC has finished sending N bytes to the sbox
>> - the write channel fires an IRQ when it has received N bytes
>>
>> In that case, one IRQ fires when the transfer is complete,
>> like Linux expects.
>>
>> For a memory-to-NAND transfer (write to device)
>> - the read channel fires an IRQ when it has sent N bytes
>> - the NFC driver is supposed to poll the NFC to determine
>> when the controller has finished writing N bytes
>>
>> In that case, the IRQ does not indicate that the transfer
>> is complete, merely that the sending half has finished
>> its part.
>
> When does your NAND controller signal completion? When it has received
> the DMA data, or only when it has finished the actual write operation?
The NAND controller provides a STATUS register.
Bit 31 is the CMD_READY bit.
This bit goes to 0 when the controller is busy, and to 1
when the controller is ready to accept the next command.
The NFC driver is doing:
res = wait_for_completion_timeout(&tx_done, HZ);
if (res > 0)
err = readl_poll_timeout(addr, val, val & CMD_READY, 0, 1000);
So basically, sleep until the memory agent IRQ falls,
then spin until the controller is idle.
Did you see that adding a 10 ?s delay at the start of
tangox_dma_pchan_detach() makes the system no longer
fail (passes an mtd_speedtest).
>> I think it is possible to have a generic solution:
>> Right now, the callback is called from tasklet context.
>> If we can have a new flag to have the callback invoked
>> directly from the ISR, then the driver for the client
>> device can do what is required.
>
> No, that won't work. The callback shouldn't run in interrupt context.
What if the callback only spun for, at most, 10 ?s ?
readl_poll_timeout(addr, val, val & CMD_READY, 0, 10);
Regards.
^ permalink raw reply
* [PATCH] pinctrl: sx150x: use new nested IRQ infrastructure
From: Linus Walleij @ 2016-11-25 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Use the new gpiochip_irqchip_add_nested() and
gpiochip_set_nested_irqchip() calls to properly created
a nested irqchip and mark all child irqs properly with
their parent IRQ.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-sx150x.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 1a1c8b51a992..36cb0f1ed538 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -1219,9 +1219,9 @@ static int sx150x_probe(struct i2c_client *client,
* plus it will be instantly noticeable if it is ever
* called (should not happen)
*/
- ret = gpiochip_irqchip_add(&pctl->gpio,
- &pctl->irq_chip, 0,
- handle_bad_irq, IRQ_TYPE_NONE);
+ ret = gpiochip_irqchip_add_nested(&pctl->gpio,
+ &pctl->irq_chip, 0,
+ handle_bad_irq, IRQ_TYPE_NONE);
if (ret) {
dev_err(dev, "could not connect irqchip to gpiochip\n");
return ret;
@@ -1234,6 +1234,10 @@ static int sx150x_probe(struct i2c_client *client,
pctl->irq_chip.name, pctl);
if (ret < 0)
return ret;
+
+ gpiochip_set_nested_irqchip(&pctl->gpio,
+ &pctl->irq_chip,
+ client-irq);
}
/* Pinctrl_desc */
--
2.7.4
^ permalink raw reply related
* Tearing down DMA transfer setup after DMA client has finished
From: Russell King - ARM Linux @ 2016-11-25 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xh96v8xnb.fsf@unicorn.mansr.com>
On Fri, Nov 25, 2016 at 02:03:20PM +0000, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>
> > On Fri, Nov 25, 2016 at 01:50:35PM +0000, M?ns Rullg?rd wrote:
> >> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> >> > It would be unfair to augment the API and add the burden on everyone
> >> > for the new API when 99.999% of the world doesn't require it.
> >>
> >> I don't think making this particular dma driver wait for the descriptor
> >> callback to return before reusing a channel quite amounts to a horrid
> >> hack. It certainly wouldn't burden anyone other than the poor drivers
> >> for devices connected to it, all of which are specific to Sigma AFAIK.
> >
> > Except when you stop to think that delaying in a tasklet is exactly
> > the same as randomly delaying in an interrupt handler - the tasklet
> > runs on the return path back to the parent context of an interrupt
> > handler. Even if you sleep in the tasklet, you're sleeping on behalf
> > of the currently executing thread - if it's a RT thread, you effectively
> > destroy the RT-ness of the thread. Let's hope no one cares about RT
> > performance on that hardware...
>
> That's why I suggested to do this only if the needed delay is known to
> be no more than a few bus cycles. The completion callback is currently
> the only post-transfer interaction we have between the dma and device
> drivers. To handle an arbitrarily long delay, some new interface will
> be required.
And now we're back at the point I made a few emails ago about undue
burden which is just about quoted above...
--
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
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ae97a212-a91e-5e0a-c9b6-2dba3b79ddc5@free.fr>
Mason <slash.tmp@free.fr> writes:
> On 25/11/2016 12:57, M?ns Rullg?rd wrote:
>
>> The same DMA unit is also used for SATA, which is an off the shelf
>> Designware controller with an in-kernel driver. This interrupt timing
>> glitch can actually explain some intermittent errors I've observed with
>> it.
>
> FWIW, newer chips embed an AHCI controller, with a dedicated
> memory channel.
>
> FWIW2, the HW dev said memory channels are "almost free", and he
> would have no problem giving each device their own private channel
> read/write pair.
We still need to deal with the existing hardware.
--
M?ns Rullg?rd
^ permalink raw reply
* [PATCH] bus: imx-weim: Fix the "fsl,weim-cs-gpr" lookup method
From: Fabio Estevam @ 2016-11-25 14:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Commit 1be81ea5860744520 ("ARM: dts: imx6: Add imx-weim parameters to
dtsi's") causes the following probe error when the weim node is not
present on the board dts (such as imx6q-sabresd):
imx-weim 21b8000.weim: Invalid 'ranges' configuration
imx-weim: probe of 21b8000.weim failed with error
As the "fsl,weim-cs-gpr" property changed the location from the individual
board dts "&weim" node to the common dtsi node we can no longer reach it
via syscon_regmap_lookup_by_phandle(), so use
syscon_regmap_lookup_by_compatible() instead, which will successfully
find the "fsl,weim-cs-gpr" property.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
drivers/bus/imx-weim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index 4bd361d..9824c58 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -76,7 +76,7 @@ static int __init imx_weim_gpr_setup(struct platform_device *pdev)
int cs = 0;
int i = 0;
- gpr = syscon_regmap_lookup_by_phandle(np, "fsl,weim-cs-gpr");
+ gpr = syscon_regmap_lookup_by_compatible("fsl,weim-cs-gpr");
if (IS_ERR(gpr)) {
dev_dbg(&pdev->dev, "failed to find weim-cs-gpr\n");
return 0;
--
2.7.4
^ permalink raw reply related
* Tearing down DMA transfer setup after DMA client has finished
From: Mason @ 2016-11-25 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xa8cnai0p.fsf@unicorn.mansr.com>
On 25/11/2016 12:57, M?ns Rullg?rd wrote:
> The same DMA unit is also used for SATA, which is an off the shelf
> Designware controller with an in-kernel driver. This interrupt timing
> glitch can actually explain some intermittent errors I've observed with
> it.
FWIW, newer chips embed an AHCI controller, with a dedicated
memory channel.
FWIW2, the HW dev said memory channels are "almost free", and he
would have no problem giving each device their own private channel
read/write pair.
Regards.
^ permalink raw reply
* [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Adrian Hunter @ 2016-11-25 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFr9uEjVQmTNP0KK8Zj9mxCW3i564E=47vTK0RLvXCjw3Q@mail.gmail.com>
On 24/11/16 15:34, Ulf Hansson wrote:
> On 24 November 2016 at 13:41, Ziji Hu <huziji@marvell.com> wrote:
>> On 2016/11/24 18:43, Ulf Hansson wrote:
>>> On 31 October 2016 at 12:09, Gregory CLEMENT
>>> <gregory.clement@free-electrons.com> wrote:
>>>> From: Ziji Hu <huziji@marvell.com>
>>>> +static int xenon_start_signal_voltage_switch(struct mmc_host *mmc,
>>>> + struct mmc_ios *ios)
>>>> +{
>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>> +
>>>> + /*
>>>> + * Before SD/SDIO set signal voltage, SD bus clock should be
>>>> + * disabled. However, sdhci_set_clock will also disable the Internal
>>>> + * clock in mmc_set_signal_voltage().
>>>
>>> If that's the case then that is wrong in the generic sdhci code.
>>> What's the reason why it can't be fixed there instead of having this
>>> workaround?
>>>
>> In my very own opinion, SD Spec doesn't specify whether SDCLK should be
>> enabled or not during power setting.
>> Enabling SDCLK might be a special condition only required by our SDHC.
>> I try to avoid breaking other vendors' SDHC functionality
>> if their SDHCs require SDCLK disabled.
>> Thus I prefer to keep it inside our SDHC driver.
>
> I let Adrian comment on this.
>
> For sure we should avoid breaking other sdhci variant, but on the
> other hand *if* the generic code is wrong we should fix it!
Yes, this looks like something that could perhaps be fixed in sdhci. I will
look into it.
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125135830.GL14217@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> On Fri, Nov 25, 2016 at 01:50:35PM +0000, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>> > It would be unfair to augment the API and add the burden on everyone
>> > for the new API when 99.999% of the world doesn't require it.
>>
>> I don't think making this particular dma driver wait for the descriptor
>> callback to return before reusing a channel quite amounts to a horrid
>> hack. It certainly wouldn't burden anyone other than the poor drivers
>> for devices connected to it, all of which are specific to Sigma AFAIK.
>
> Except when you stop to think that delaying in a tasklet is exactly
> the same as randomly delaying in an interrupt handler - the tasklet
> runs on the return path back to the parent context of an interrupt
> handler. Even if you sleep in the tasklet, you're sleeping on behalf
> of the currently executing thread - if it's a RT thread, you effectively
> destroy the RT-ness of the thread. Let's hope no one cares about RT
> performance on that hardware...
That's why I suggested to do this only if the needed delay is known to
be no more than a few bus cycles. The completion callback is currently
the only post-transfer interaction we have between the dma and device
drivers. To handle an arbitrarily long delay, some new interface will
be required.
--
M?ns Rullg?rd
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Russell King - ARM Linux @ 2016-11-25 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xlgw78y8k.fsf@unicorn.mansr.com>
On Fri, Nov 25, 2016 at 01:50:35PM +0000, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> > It would be unfair to augment the API and add the burden on everyone
> > for the new API when 99.999% of the world doesn't require it.
>
> I don't think making this particular dma driver wait for the descriptor
> callback to return before reusing a channel quite amounts to a horrid
> hack. It certainly wouldn't burden anyone other than the poor drivers
> for devices connected to it, all of which are specific to Sigma AFAIK.
Except when you stop to think that delaying in a tasklet is exactly
the same as randomly delaying in an interrupt handler - the tasklet
runs on the return path back to the parent context of an interrupt
handler. Even if you sleep in the tasklet, you're sleeping on behalf
of the currently executing thread - if it's a RT thread, you effectively
destroy the RT-ness of the thread. Let's hope no one cares about RT
performance on that hardware...
--
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
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125133436.GK14217@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> On Fri, Nov 25, 2016 at 01:07:05PM +0000, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>>
>> > On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote:
>> >> Looking at thread and discussion now, first thinking would be to ensure
>> >> the transaction is completed properly and then isr fired. You may need
>> >> to talk to your HW designers to find a way for that. It is quite common
>> >> that DMA controllers will fire and complete whereas the transaction is
>> >> still in flight.
>> >>
>> >> If that is not doable, then since you claim this is custom part which
>> >> other vendors wont use (hope we are wrong down the line), then we can
>> >> have a custom api,
>> >>
>> >> foo_sbox_configure(bool enable, ...);
>> >>
>> >> This can be invoked from NFC driver when required for configuration and
>> >> teardown. For very specific cases where people need some specific
>> >> configuration we do allow custom APIs.
>> >>
>> >> Only problem with that would be it wont be a generic solution and you
>> >> seem to be fine with that.
>> >
>> > Isn't this just the same problem as PL08x or any other system which
>> > has multiple requests from devices, but only a limited number of
>> > hardware channels - so you have to route the request signals to the
>> > appropriate hardware channels according to the requests queued up?
>> >
>> > If so, no new "custom" APIs are required, it's already able to be
>> > solved within the DMA engine drivers...
>>
>> That isn't the problem. The multiplexing of many devices on a limited
>> number of hardware channels is working fine. The problem is that (some)
>> client devices need the routing to remain for some time after the dma
>> interrupt signals completion. I'd characterise this hardware as broken,
>> but there's nothing we can do about that.
>>
>> The fix has to provide some way for the dma driver to delay reusing a
>> hardware channel until the client device indicates completion. If only
>> a short delay (a few bus cycles) is needed, it is probably acceptable to
>> rework the driver such that the descriptor completion callback can do
>> the necessary waiting (e.g. by busy-polling a device status register).
>> If the delay can be longer, some other method needs to be devised.
>
> What I understood from the original mail is:
>
> | The problem is that the DMA driver tears down the sbox setup
> | as soon as it receives the IRQ. However, when writing to the
> | device, the interrupt only means "I have pushed all data from
> | memory to the memory channel". These data have not reached
> | the device yet, and may still be "in flight". Thus the sbox
> | setup can only be torn down after the NFC is idle.
>
> The interrupt comes in after it's read the the last data from memory,
> but the data is still sitting in the engine's buffers and has not yet
> been passed to the device.
>
> It sounds like the DMA engine buffers the data on its way to the device,
> and it's not clear from the description whether that is done in
> response to a request from the device or whether the data is prefetched.
> IOW, what the lifetime of the data in the dma engine is.
It's not clear from the information I have exactly when the interrupt
fires, only that it appears to be somewhat too early.
> It seems odd that the DMA engine provides no way to know whether the
> channel still contains data that is in-flight to the device, whether
> by interrupt (from the descriptions the IRQ is way too early) or by
> polling some status register within the DMA engine itself.
>
> If the delay is predictable, why not use a delayed workqueue or a
> hrtimer to wait a period after the IRQ before completing the DMA
> transaction? If it's not predictable and you haven't some status
> register in the DMA engine hardware that indicates whether there's
> remaining data, then the design really is screwed up, and I don't
> think there's a reasonable solution to the problem - anything
> would be a horrid hack that would be specific to this SoC.
This would hardly be the first screwed up hardware design. There is a
completion indicator, just not in the dma engine. For some idiotic
reason, the designers put this responsibility on the client devices and
their respective drivers.
> It would be unfair to augment the API and add the burden on everyone
> for the new API when 99.999% of the world doesn't require it.
I don't think making this particular dma driver wait for the descriptor
callback to return before reusing a channel quite amounts to a horrid
hack. It certainly wouldn't burden anyone other than the poor drivers
for devices connected to it, all of which are specific to Sigma AFAIK.
--
M?ns Rullg?rd
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: Ard Biesheuvel @ 2016-11-25 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <31374.1480078855@warthog.procyon.org.uk>
On 25 November 2016 at 13:00, David Howells <dhowells@redhat.com> wrote:
> Okay, how about the attached?
>
> Can these variables every be anything other than 1 or 0? E.g. should the
> check on SetupMode be that it isn't 0 rather than it is 1?
>
The firmware will ensure that these variables only ever assume the
documented values.
> David
> ---
> commit 6d4bb08e376045e27706c2740c0fdff0a6ec43f7
> Author: David Howells <dhowells@redhat.com>
> Date: Fri Nov 25 11:52:05 2016 +0000
>
> efi: Handle secure boot from UEFI-2.6
>
> UEFI-2.6 adds a new variable, DeployedMode. If it exists, this must be 1
> if we're to engage lockdown mode.
>
> Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
>
> diff --git a/drivers/firmware/efi/libstub/secureboot.c b/drivers/firmware/efi/libstub/secureboot.c
> index ca643eba5a4b..157782d1c552 100644
> --- a/drivers/firmware/efi/libstub/secureboot.c
> +++ b/drivers/firmware/efi/libstub/secureboot.c
> @@ -22,6 +22,9 @@ static const efi_char16_t const efi_SecureBoot_name[] = {
> static const efi_char16_t const efi_SetupMode_name[] = {
> 'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
> };
> +static const efi_char16_t const efi_DeployedMode_name[] = {
> + 'D', 'e', 'p', 'l', 'o', 'y', 'e', 'd', 'M', 'o', 'd', 'e', 0
> +};
>
> /* SHIM variables */
> static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
> @@ -62,6 +65,17 @@ int efi_get_secureboot(efi_system_table_t *sys_table_arg)
> if (val == 1)
> return 0;
>
> + /* UEFI-2.6 requires DeployedMode to be 1. */
> + if (sys_table_arg->hdr.revision == EFI_2_60_SYSTEM_TABLE_REVISION) {
>=
> + status = get_efi_var(efi_DeployedMode_name, &efi_variable_guid,
> + NULL, &size, &val);
> + if (status != EFI_SUCCESS)
> + goto out_efi_err;
> +
> + if (val != 1)
> + return 0;
val == 0 is better imo, since that will prevent unexpected values from
being interpreted as 'secure boot disabled'
> + }
> +
> /* See if a user has put shim into insecure mode. If so, and if the
> * variable doesn't have the runtime attribute set, we might as well
> * honor that.
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 333d31bf55bf..563abb37f03f 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -645,6 +645,10 @@ typedef struct {
>
> #define EFI_SYSTEM_TABLE_SIGNATURE ((u64)0x5453595320494249ULL)
>
> +#define EFI_2_60_SYSTEM_TABLE_REVISION ((2 << 16) | (60))
> +#define EFI_2_50_SYSTEM_TABLE_REVISION ((2 << 16) | (50))
> +#define EFI_2_40_SYSTEM_TABLE_REVISION ((2 << 16) | (40))
> +#define EFI_2_31_SYSTEM_TABLE_REVISION ((2 << 16) | (31))
> #define EFI_2_30_SYSTEM_TABLE_REVISION ((2 << 16) | (30))
> #define EFI_2_20_SYSTEM_TABLE_REVISION ((2 << 16) | (20))
> #define EFI_2_10_SYSTEM_TABLE_REVISION ((2 << 16) | (10))
^ 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