* mbox-name vs. mbox-names (was: Re: [PATCH v4 1/5] mailbox: dt: Supply bindings for ST's Mailbox IP)
From: Lee Jones @ 2017-01-04 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024084107.GD14477@dell>
On Mon, 24 Oct 2016, Lee Jones wrote:
> On Fri, 21 Oct 2016, Geert Uytterhoeven wrote:
>
> > On Fri, Oct 16, 2015 at 9:21 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > > .../devicetree/bindings/mailbox/sti-mailbox.txt | 51 ++++++++++++++++++++++
> > > 1 file changed, 51 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > > new file mode 100644
> > > index 0000000..b61eec9
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > > @@ -0,0 +1,51 @@
> > > +ST Microelectronics Mailbox Driver
> > > +
> > > +Each ST Mailbox IP currently consists of 4 instances of 32 channels. Messages
> > > +are passed between Application and Remote processors using shared memory.
> > > +
> > > +Controller
> > > +----------
> > > +
> > > +Required properties:
> > > +- compatible : Should be "st,stih407-mailbox"
> > > +- reg : Offset and length of the device's register set
> > > +- mbox-name : Name of the mailbox
> >
> > All other mailbox drivers use "mbox-names". Oops, it's in v4.9-rc1...
> >
> > Can we still fix that?
>
> So long as all the fixes; changes to the driver and DT are merged in a
> single kernel release, we can change it.
Scrap that, change of plan. Actually current code is correct.
mbox-name does not have the same functionality as mbox-names.
mbox-names is a client-side property used to request channels, where
as mbox-name is used to provide a better user-readable name other than
mailbox{0..x}.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] mailbox: sti: Fix mbox-names copy and paste error
From: Lee Jones @ 2017-01-04 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104145732.7yiqbi7rf7m6lem4@rob-hp-laptop>
On Wed, 04 Jan 2017, Rob Herring wrote:
> On Wed, Jan 04, 2017 at 12:05:27PM +0000, Lee Jones wrote:
> > Due to an over-sight, mbox-names has become mbox-name in some instances.
> >
> > Let's put it right.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > Documentation/devicetree/bindings/mailbox/sti-mailbox.txt | 4 ++--
> > arch/arm/boot/dts/stih407-family.dtsi | 8 ++++----
> > drivers/mailbox/mailbox-sti.c | 2 +-
> > 3 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > index 351f612..648d176 100644
> > --- a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > +++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> > @@ -9,7 +9,7 @@ Controller
> > Required properties:
> > - compatible : Should be "st,stih407-mailbox"
> > - reg : Offset and length of the device's register set
> > -- mbox-name : Name of the mailbox
> > +- mbox-names : Name of the mailbox
>
> It's worse than this. mbox-names is for the mailbox client side.
Ah yes, of course. False alarm.
Let's just leave it as it is. ;)
I'll reply to the reporter directly.
> This should just be dropped. Plus, *-names is pointless when there
> is only 1 element.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* imx: RS-485 problems during TX, maybe DMA related
From: Clemens Gruber @ 2017-01-04 16:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I observed odd behavior of the current tty/serial/imx.c driver in RS-485
mode.
RX works fine, but TX does not: When sending data, it arrives multiple
times and with data from previous transmissions at the end, after a
delay.
# My setup
Hardware:
i.MX6Q board with UARTn_RX_DATA, _TX_DATA and _CTS_B connected to a
RS-485 half-duplex transceiver (Exar SP3082E), pins RXD, TXD and DE
respectively. (DE is active-high, _CTS_B is inverted on the board)
I am using an external USB-to-RS-485 converter connected to my PC to
conduct the tests.
Firmware:
I tried both the original ROM SDMA scripts and also the RAM scripts from
Freescale (placed in firmware/imx), but there was no difference, except
for a DMA transaction error message going away (appeared when writing too
much data too fast into a device configured with too low baud rate).
So I switched back to the pure mainline 4.9 kernel with SDMA using the
scripts from ROM.
Software:
Mainline Linux 4.9 with serial_rs485 flags: rs485 (SER_RS485_ENABLED),
-rs485rtsonsend (~SER_RS485_RTS_ON_SEND), rs485rtsaftersend and
rs485rxduringtx. I only enabled rs485rxduringtx, because otherwise it
would not work at all. But I am still unsure why it is needed for
half-duplex RS-485.
# The tests
1) On the board: echo A > /dev/ttymxc4
2) On my PC: A \n A \n appears immediately
(about 4s delay)
A \n
(about 4s delay)
A \n
Kernel log on the board:
[ 29.059983] imx-uart 21f4000.serial: TX: prepare to send 2 bytes by DMA.
[ 29.067166] imx-uart 21f4000.serial: we finish the TX DMA.
[ 29.073057] imx-uart 21f4000.serial: TX: prepare to send 4094 bytes by DMA.
[ 33.359405] imx-uart 21f4000.serial: we finish the TX DMA.
[ 33.365173] imx-uart 21f4000.serial: TX: prepare to send 4072 bytes by DMA.
[ 37.603551] imx-uart 21f4000.serial: we finish the TX DMA.
3) On the board: echo B > /dev/ttymxc4
4) On my PC: B \n B \n appears immediately
(about 4s delay)
A \n B \n
(about 4s delay)
A \n B \n
Kernel log:
[ 66.000296] imx-uart 21f4000.serial: TX: prepare to send 2 bytes by DMA.
[ 66.007110] imx-uart 21f4000.serial: we finish the TX DMA.
[ 66.012841] imx-uart 21f4000.serial: TX: prepare to send 4094 bytes by DMA.
[ 70.297051] imx-uart 21f4000.serial: we finish the TX DMA.
[ 70.302798] imx-uart 21f4000.serial: TX: prepare to send 4072 bytes by DMA.
[ 74.539094] imx-uart 21f4000.serial: we finish the TX DMA.
And so on..
( If I continue with a echo C > /dev/ttymxc4, the last characters are
A \n B \n C )
--
To illustrate the behavior, I recorded the signals on the transceiver
pins with a logic analyzer:
https://pqgruber.com/rs485_results.png
I triggered only on the raising and on the falling edge of DE, so I only
captured the first and the last characters for the first two tests and
not all three events per test.
I also enabled the DMA debug options in the kernel if that is helpful,
here is the full log during the two tests:
https://gist.github.com/clemensg/1ac5ee8a8ea32acc9145c5aa8407aea5
--
Do you have an idea, what's wrong here?
Also: If you are using RS-485 with the imx driver on a recent kernel,
please let me know if it is working for you and if you can reproduce the
behavior.
Thanks,
Clemens
--
PS:
Because I assumed that the error has something to do with DMA, I
commented out the call to imx_uart_dma_init.
Then, transmitting and receiving data over RS-485 works! Verified with
the logic analyzer and the RS-485-to-USB adapter.
However, if trying to send large amounts of data in a short time,
sometimes I get an "Unhandled fault: imprecise external abort (0x1406)".
But the back trace is not very helpful and probably not related
(it is different every time), the last time I tried, the PC was at
_raw_spin_unlock_irqrestore, called from hrtimer_start_range_ns.
^ permalink raw reply
* [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap
From: Auger Eric @ 2017-01-04 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c9c4c159-60ea-8501-5dc2-17bbb24ddfab@arm.com>
Hi Marc,
On 04/01/2017 16:27, Marc Zyngier wrote:
> On 04/01/17 14:11, Auger Eric wrote:
>> Hi Marc,
>>
>> On 04/01/2017 14:46, Marc Zyngier wrote:
>>> Hi Eric,
>>>
>>> On 04/01/17 13:32, Eric Auger wrote:
>>>> This new function checks whether all platform and PCI
>>>> MSI domains implement IRQ remapping. This is useful to
>>>> understand whether VFIO passthrough is safe with respect
>>>> to interrupts.
>>>>
>>>> On ARM typically an MSI controller can sit downstream
>>>> to the IOMMU without preventing VFIO passthrough.
>>>> As such any assigned device can write into the MSI doorbell.
>>>> In case the MSI controller implements IRQ remapping, assigned
>>>> devices will not be able to trigger interrupts towards the
>>>> host. On the contrary, the assignment must be emphasized as
>>>> unsafe with respect to interrupts.
>>>>
>>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>>>
>>>> ---
>>>>
>>>> v4 -> v5:
>>>> - Handle DOMAIN_BUS_FSL_MC_MSI domains
>>>> - Check parents
>>>> ---
>>>> include/linux/irqdomain.h | 1 +
>>>> kernel/irq/irqdomain.c | 41 +++++++++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 42 insertions(+)
>>>>
>>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>>> index ab017b2..281a40f 100644
>>>> --- a/include/linux/irqdomain.h
>>>> +++ b/include/linux/irqdomain.h
>>>> @@ -219,6 +219,7 @@ struct irq_domain *irq_domain_add_legacy(struct device_node *of_node,
>>>> void *host_data);
>>>> extern struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
>>>> enum irq_domain_bus_token bus_token);
>>>> +extern bool irq_domain_check_msi_remap(void);
>>>> extern void irq_set_default_host(struct irq_domain *host);
>>>> extern int irq_domain_alloc_descs(int virq, unsigned int nr_irqs,
>>>> irq_hw_number_t hwirq, int node,
>>>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>>>> index 8c0a0ae..700caea 100644
>>>> --- a/kernel/irq/irqdomain.c
>>>> +++ b/kernel/irq/irqdomain.c
>>>> @@ -278,6 +278,47 @@ struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
>>>> EXPORT_SYMBOL_GPL(irq_find_matching_fwspec);
>>>>
>>>> /**
>>>> + * irq_domain_is_msi_remap - Check if @domain or any parent
>>>> + * has MSI remapping support
>>>> + * @domain: domain pointer
>>>> + */
>>>> +static bool irq_domain_is_msi_remap(struct irq_domain *domain)
>>>> +{
>>>> + struct irq_domain *h = domain;
>>>> +
>>>> + for (; h; h = h->parent) {
>>>> + if (h->flags & IRQ_DOMAIN_FLAG_MSI_REMAP)
>>>> + return true;
>>>> + }
>>>> + return false;
>>>> +}
>>>> +
>>>> +/**
>>>> + * irq_domain_check_msi_remap() - Checks whether all MSI
>>>> + * irq domains implement IRQ remapping
>>>> + */
>>>> +bool irq_domain_check_msi_remap(void)
>>>> +{
>>>> + struct irq_domain *h;
>>>> + bool ret = true;
>>>> +
>>>> + mutex_lock(&irq_domain_mutex);
>>>> + list_for_each_entry(h, &irq_domain_list, link) {
>>>> + if (((h->bus_token & DOMAIN_BUS_PCI_MSI) ||
>>>> + (h->bus_token & DOMAIN_BUS_PLATFORM_MSI) ||
>>>> + (h->bus_token & DOMAIN_BUS_FSL_MC_MSI)) &&
>>>> + !irq_domain_is_msi_remap(h)) {
>>>
>>> (h->bus_token & DOMAIN_BUS_PCI_MSI) and co looks quite wrong. bus_token
>>> is not a bitmap, and DOMAIN_BUS_* not a single bit value (see enum
>>> irq_domain_bus_token). Surely this should read
>>> (h->bus_token == DOMAIN_BUS_PCI_MSI).
>> Oh I did not notice that. Thanks.
>>
>> Any other comments on the irqdomain side? Do you think the current
>> approach consisting in looking at those bus tokens and their parents
>> looks good?
>
> To be completely honest, I don't like it much, as having to enumerate
> all the bus types can come up with could become quite a burden in the
> long run. I'd rather be able to identify MSI capable domains by
> construction. I came up with the following approach (fully untested):
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index 281a40f..7779796 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -183,8 +183,11 @@ enum {
> /* Irq domain is an IPI domain with single virq */
> IRQ_DOMAIN_FLAG_IPI_SINGLE = (1 << 3),
>
> + /* Irq domain implements MSIs */
> + IRQ_DOMAIN_FLAG_MSI = (1 << 4),
> +
> /* Irq domain is MSI remapping capable */
> - IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 4),
> + IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 5),
>
> /*
> * Flags starting from IRQ_DOMAIN_FLAG_NONCORE are reserved
> @@ -450,6 +453,11 @@ static inline bool irq_domain_is_ipi_single(struct irq_domain *domain)
> {
> return domain->flags & IRQ_DOMAIN_FLAG_IPI_SINGLE;
> }
> +
> +static inline bool irq_domain_is_msi(struct irq_domain *domain)
> +{
> + return domain->flags & IRQ_DOMAIN_FLAG_MSI;
> +}
> #else /* CONFIG_IRQ_DOMAIN_HIERARCHY */
> static inline void irq_domain_activate_irq(struct irq_data *data) { }
> static inline void irq_domain_deactivate_irq(struct irq_data *data) { }
> @@ -481,6 +489,11 @@ static inline bool irq_domain_is_ipi_single(struct irq_domain *domain)
> {
> return false;
> }
> +
> +static inline bool irq_domain_is_msi(struct irq_domain *domain)
> +{
> + return false;
> +}
> #endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */
>
> #else /* CONFIG_IRQ_DOMAIN */
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 700caea..33b6921 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -304,10 +304,7 @@ bool irq_domain_check_msi_remap(void)
>
> mutex_lock(&irq_domain_mutex);
> list_for_each_entry(h, &irq_domain_list, link) {
> - if (((h->bus_token & DOMAIN_BUS_PCI_MSI) ||
> - (h->bus_token & DOMAIN_BUS_PLATFORM_MSI) ||
> - (h->bus_token & DOMAIN_BUS_FSL_MC_MSI)) &&
> - !irq_domain_is_msi_remap(h)) {
> + if (irq_domain_is_msi(h) && !irq_domain_is_msi_remap(h)) {
> ret = false;
> goto out;
> }
> diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
> index ee23006..b637263 100644
> --- a/kernel/irq/msi.c
> +++ b/kernel/irq/msi.c
> @@ -270,7 +270,7 @@ struct irq_domain *msi_create_irq_domain(struct fwnode_handle *fwnode,
> if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS)
> msi_domain_update_chip_ops(info);
>
> - return irq_domain_create_hierarchy(parent, 0, 0, fwnode,
> + return irq_domain_create_hierarchy(parent, IRQ_DOMAIN_FLAG_MSI, 0, fwnode,
> &msi_domain_ops, info);
> }
>
>
>
> Thoughts?
No objection from my side. I will respin and test.
Thanks
Eric
>
> M.
>
^ permalink raw reply
* [GIT PULL] omap fixes for v4.10-rc cycle
From: Tony Lindgren @ 2017-01-04 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3791843.yGbamM6pzm@wuerfel>
* Arnd Bergmann <arnd@arndb.de> [170104 07:18]:
> On Friday, December 30, 2016 1:10:43 PM CET Tony Lindgren wrote:
> > Fist set of fixes for omaps for v4.10-rc cycle, mostly
> > to deal with various regressions noticed during the merge
> > window and to fix various device tree configurations for
> > boards. Also included is removal of mach-omap2/gpio.c that
> > is now dead code with device tree based booting that should
> > be OK for the early -rc cycle:
> >
> > - A series of fixes to add empty chosen node to fix regressions
> > caused for bootloaders that don't create chosen node as the
> > decompressor needs the chosen node to merge command line and
> > ATAGs into it
> >
> > - Fix missing logicpd-som-lv-37xx-devkit.dtb entry in Makefile
> >
> > - Fix regression for am437x timers
> >
> > - Fix wrong strcat for non-NULL terminated string
> >
> > - A series of changes to fix tps65217 interrupts to not use
> > defines as we don't do that for interrupts
> >
> > - Two patches to fix USB VBUS detection on am57xx-idk and force it
> > to peripheral mode until dwc3 role detection is working
> >
> > - Add missing dra72-evm-tps65917 missing voltage supplies
> > accidentally left out of an earlier patch
> >
> > - Fix n900 eMMC detection when booted on qemu
> >
> > - Remove unwanted pr_err on failed memory allocation for
> > prm_common.c
> >
> > - Remove legacy mach-omap2/gpio.c that now is dead code
> > since we boot mach-omap2 in device tree only mode
> >
> > - Fix am572x-idk pcie1 by adding the missing gpio reset pin
>
> I think I would have preferred to see the gpio.c removal as
> a fixes-non-critical patch for 4.11 instead, but I don't feel
> like making you respin the pull request for that, since I
> really want to get the other fixes merged for -rc3.
Sorry yeah I had that queued for v4.11 but I forgot it and then
the holidays came.. Anyways it's been sitting in Linux next since
late November so should be safe to merge.
> Pulled everything into fixes now.
Thanks,
Tony
^ permalink raw reply
* [PATCH v5 2/4] ARM: Define KERNEL_START and KERNEL_END
From: Hartley Sweeten @ 2017-01-04 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104011417.1496-3-f.fainelli@gmail.com>
On Tuesday, January 03, 2017 6:14 PM, Florian Fainelli wrote:
>
> In preparation for adding CONFIG_DEBUG_VIRTUAL support, define a set of
> common constants: KERNEL_START and KERNEL_END which abstract
> CONFIG_XIP_KERNEL vs. !CONFIG_XIP_KERNEL. Update the code where
> relevant.
>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/include/asm/memory.h | 7 +++++++
> arch/arm/mm/init.c | 7 ++-----
> arch/arm/mm/mmu.c | 6 +-----
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 76cbd9c674df..bee7511c5098 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -111,6 +111,13 @@
>
> #endif /* !CONFIG_MMU */
>
> +#ifdef CONFIG_XIP_KERNEL
> +#define KERNEL_START _sdata
> +#else
> +#define KERNEL_START _stext
> +#endif
> +#define KERNEL_END _end
> +
> /*
> * We fix the TCM memories max 32 KiB ITCM resp DTCM at these
> * locations
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 370581aeb871..c87d0d5b65f2 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -230,11 +230,8 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t align)
> void __init arm_memblock_init(const struct machine_desc *mdesc)
> {
> /* Register the kernel text, kernel data and initrd with memblock. */
> -#ifdef CONFIG_XIP_KERNEL
> - memblock_reserve(__pa(_sdata), _end - _sdata);
> -#else
> - memblock_reserve(__pa(_stext), _end - _stext);
> -#endif
> + memblock_reserve(__pa(KERNEL_START), _end - KERNEL_START);
Shouldn't the '_end' above be 'KERNEL_END'?
Hartley
^ permalink raw reply
* [PATCH 0/9] ARM: dts: armada388: Introduce Clearfog Base DT
From: Gregory CLEMENT @ 2017-01-04 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO43Q-0007yJ-ON@rmk-PC.armlinux.org.uk>
Hi Russell,
On lun., janv. 02 2017, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> This patch series, based upon the previously submitted fix for the SPI
> flash, reworks the Clearfog DT files to add support for the SolidRun
> Clearfog Base platform.
>
> The conventional model is now known as the "Clearfog Pro" module, which
> has the DSA switch and two PCIe sockets. The base model is a smaller
> board without the DSA switch, replacing it with a second copper gigabit
> port, and only one PCIe socket.
>
> We retain the original DT file (named armada-388-clearfog.dtb) for
> compatibility with existing installations - not only the filename,
> but also the board name exposed in userspace.
All the series applied on mvebu/dt.
I amended the last two patches because the license text was mangled as
spotted by Alexandre Belloni, so I fixed it while applying the patches.
Thanks,
Gregory
>
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/armada-388-clearfog-base.dts | 94 ++++++
> arch/arm/boot/dts/armada-388-clearfog-pro.dts | 55 ++++
> arch/arm/boot/dts/armada-388-clearfog.dts | 364 ++++-----------------
> arch/arm/boot/dts/armada-388-clearfog.dtsi | 310 ++++++++++++++++++
> .../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 21 ++
> 6 files changed, 548 insertions(+), 298 deletions(-)
> create mode 100644 arch/arm/boot/dts/armada-388-clearfog-base.dts
> create mode 100644 arch/arm/boot/dts/armada-388-clearfog-pro.dts
> create mode 100644 arch/arm/boot/dts/armada-388-clearfog.dtsi
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] DaVinci fixes for v4.10
From: Arnd Bergmann @ 2017-01-04 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104121354.8467-1-nsekhar@ti.com>
On Wednesday, January 4, 2017 5:43:54 PM CET Sekhar Nori wrote:
> This pull request contains fixes for the following issues
>
> 1) Fix two instances of infinite loop occurring in
> clock list for DA850. This fixes kernel hangs in some
> instances and so have been marked for stable kernel.
>
> 2) Fix for sleeping function called from atomic context
> with USB 2.0 clock management code introduced in v4.10
> merge window.
>
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Amlogic fixes for v4.10-rc
From: Arnd Bergmann @ 2017-01-04 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hk2abgzgb.fsf@baylibre.com>
On Tuesday, January 3, 2017 9:35:00 PM CET Kevin Hilman wrote:
> This pull has one real fix, as a couple non-critical ones. The DRM
> DT/defconfig patches are coming now because I didn't expect the new
> driver to make it for the v4.10 merge window, but since it did[1], the
> DT and defconfig should go into the same release.
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] drivers: firmware: PSCI fixes for v4.10
From: Arnd Bergmann @ 2017-01-04 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103185052.GA23238@e107981-lin.cambridge.arm.com>
On Tuesday, January 3, 2017 6:50:52 PM CET Lorenzo Pieralisi wrote:
> PSCI fixes for v4.10
>
> Two minor fixes following the merge of the PSCI checker:
>
> - Annotate the PSCI checker timer on the stack used to wake-up from
> suspend to prevent warnings when the DEBUG_OBJECTS config option
> is enabled
> - Extend the PSCI entry in the maintainers list to also include the
> PSCI checker code
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] arm64: dts: vexpress: fixes for v4.10
From: Arnd Bergmann @ 2017-01-04 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <252d452b-49a3-6c62-b299-ed7a2abbf538@arm.com>
On Tuesday, January 3, 2017 10:31:52 AM CET Sudeep Holla wrote:
> ARMv8 Juno/VExpress fixes for v4.10
>
> A simple fix to extend GICv2 CPU interface registers from 4K to 8K
> on AEMv8 FVP/RTSM models in order to support split priority drop and
> interrupt deactivation.
>
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: dts: vexpress: fixes for v4.10
From: Arnd Bergmann @ 2017-01-04 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4df20b4c-3f07-5f1a-2f62-df090aa0cbd6@arm.com>
On Tuesday, January 3, 2017 10:30:47 AM CET Sudeep Holla wrote:
> ARMv7 VExpress fixes for v4.10
>
> A simple fix to extend GICv2 CPU interface registers from 4K to 8K
> on VExpress TC1 and TC2 platforms in order to support split priority
> drop and interrupt deactivation.
>
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Qualcomm ARM DT Fixes for 4.10-rc2
From: Arnd Bergmann @ 2017-01-04 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483387434-4655-1-git-send-email-andy.gross@linaro.org>
On Monday, January 2, 2017 2:03:54 PM CET Andy Gross wrote:
> Qualcomm ARM DTS Fixes for v4.10-rc2
>
> * Add SCM clock for APQ8064 to fix boot failures
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] firmware: SCPI: fixes for v4.10
From: Arnd Bergmann @ 2017-01-04 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11909baf-8ab3-7e53-ef22-2988571392f5@arm.com>
On Tuesday, January 3, 2017 10:28:00 AM CET Sudeep Holla wrote:
> SCPI fix for v4.10
>
> A simple fix for reading only lower 32-bit sensor values on pre-1.0 SCPI
> firmwares so that upper 32-bit (garbage) value is discarded properly.
>
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [PATCH v3] i2c: designware: add reset interface
From: Andy Shevchenko @ 2017-01-04 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2921529.fKUMSWjgsl@wuerfel>
On Wed, 2017-01-04 at 15:55 +0100, Arnd Bergmann wrote:
> On Friday, December 23, 2016 9:40:51 PM CET Zhangfei Gao wrote:
> > @@ -176,6 +177,14 @@ static int dw_i2c_plat_probe(struct
> > platform_device *pdev)
> > ????????dev->irq = irq;
> > ????????platform_set_drvdata(pdev, dev);
> > ?
> > +???????dev->rst = devm_reset_control_get_optional_exclusive(&pdev-
> > >dev, NULL);
> > +???????if (IS_ERR(dev->rst)) {
> > +???????????????if (PTR_ERR(dev->rst) == -EPROBE_DEFER)
> > +???????????????????????return -EPROBE_DEFER;
> > +???????} else {
> > +???????????????reset_control_deassert(dev->rst);
> > +???????}
> > +
>
> Sorry for the late reply, I only now stumbled over this. I think it's
> generally wrong to ignore any error aside from -EPROBE_DEFER. It's
> better to single-out the error conditions you want to ignore (e.g.
> no reset specified) and ignore those but return an error for
> all other problems.
Which means that reset framework whenever work _optional is used should
return error iff (mind two f:s) there is a problem with existing
control.
>
> > @@ -270,10 +280,18 @@ static int dw_i2c_plat_probe(struct
> > platform_device *pdev)
> > ????????}
> > ?
> > ????????r = i2c_dw_probe(dev);
> > -???????if (r && !dev->pm_runtime_disabled)
> > -???????????????pm_runtime_disable(&pdev->dev);
> > +???????if (r)
> > +???????????????goto exit_probe;
> > ?
> > ????????return r;
> > +
> > +exit_probe:
> > +???????if (!dev->pm_runtime_disabled)
> > +???????????????pm_runtime_disable(&pdev->dev);
> > +exit_reset:
> > +???????if (!IS_ERR_OR_NULL(dev->rst))
> > +???????????????reset_control_assert(dev->rst);
> > +???????return r;
> >
>
> try to avoid the IS_ERR_OR_NULL() check, it usually indicates either
> a bad interface, or that the interface is used wrong.
Please, fix reset framework first than.
For my understanding:
It should return NULL for optional reset control.
It should not fail on NULL argument.
> In this case, I think we can't get here with a NULL dev->rst
> pointer, so it's better to only check IS_ERR, or to explicitly
> set the pointer to NULL in case there is no reset line.
>
> Arnd
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Nikita Yushchenko @ 2017-01-04 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3158203.Yc9Qgx82xo@wuerfel>
>>>> For OF platforms, this is called via of_dma_configure(), that checks
>>>> dma-ranges of node that is *parent* for host bridge. Host bridge
>>>> currently does not control this at all.
>>>
>>> We need to think about this a bit. Is it actually the PCI host
>>> bridge that limits the ranges here, or the bus that it is connected
>>> to. In the latter case, the caller needs to be adapted to handle
>>> both.
>>
>> In r-car case, I'm not sure what is the source of limitation at physical
>> level.
>>
>> pcie-rcar driver configures ranges for PCIe inbound transactions based
>> on dma-ranges property in it's device tree node. In the current device
>> tree for this platform, that only contains one range and it is in lower
>> memory.
>>
>> NVMe driver tries i/o to kmalloc()ed area. That returns 0x5xxxxxxxx
>> addresses here. As a quick experiment, I tried to add second range to
>> pcie-rcar's dma-ranges to cover 0x5xxxxxxxx area - but that did not make
>> DMA to high addresses working.
>>
>> My current understanding is that host bridge hardware module can't
>> handle inbound transactions to PCI addresses above 4G - and this
>> limitations comes from host bridge itself.
>>
>> I've read somewhere in the lists that pcie-rcar hardware is "32-bit" -
>> but I don't remember where, and don't know lowlevel details. Maybe
>> somebody from linux-renesas can elaborate?
>
> Just a guess, but if the inbound translation windows in the host
> bridge are wider than 32-bit, the reason for setting up a single
> 32-bit window is probably because that is what the parent bus supports.
Well anyway applying patch similar to your's will fix pcie-rcar + nvme
case - thus I don't object :) But it can break other cases ...
But why do you hook at set_dma_mask() and overwrite mask inside, instead
of hooking at dma_supported() and rejecting unsupported mask?
I think later is better, because it lets drivers to handle unsupported
high-dma case, like documented in DMA-API_HOWTO.
^ permalink raw reply
* [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap
From: Marc Zyngier @ 2017-01-04 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <df8e7fdb-4048-3169-c758-c2a64119a321@redhat.com>
On 04/01/17 14:11, Auger Eric wrote:
> Hi Marc,
>
> On 04/01/2017 14:46, Marc Zyngier wrote:
>> Hi Eric,
>>
>> On 04/01/17 13:32, Eric Auger wrote:
>>> This new function checks whether all platform and PCI
>>> MSI domains implement IRQ remapping. This is useful to
>>> understand whether VFIO passthrough is safe with respect
>>> to interrupts.
>>>
>>> On ARM typically an MSI controller can sit downstream
>>> to the IOMMU without preventing VFIO passthrough.
>>> As such any assigned device can write into the MSI doorbell.
>>> In case the MSI controller implements IRQ remapping, assigned
>>> devices will not be able to trigger interrupts towards the
>>> host. On the contrary, the assignment must be emphasized as
>>> unsafe with respect to interrupts.
>>>
>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>>
>>> ---
>>>
>>> v4 -> v5:
>>> - Handle DOMAIN_BUS_FSL_MC_MSI domains
>>> - Check parents
>>> ---
>>> include/linux/irqdomain.h | 1 +
>>> kernel/irq/irqdomain.c | 41 +++++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 42 insertions(+)
>>>
>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>> index ab017b2..281a40f 100644
>>> --- a/include/linux/irqdomain.h
>>> +++ b/include/linux/irqdomain.h
>>> @@ -219,6 +219,7 @@ struct irq_domain *irq_domain_add_legacy(struct device_node *of_node,
>>> void *host_data);
>>> extern struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
>>> enum irq_domain_bus_token bus_token);
>>> +extern bool irq_domain_check_msi_remap(void);
>>> extern void irq_set_default_host(struct irq_domain *host);
>>> extern int irq_domain_alloc_descs(int virq, unsigned int nr_irqs,
>>> irq_hw_number_t hwirq, int node,
>>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>>> index 8c0a0ae..700caea 100644
>>> --- a/kernel/irq/irqdomain.c
>>> +++ b/kernel/irq/irqdomain.c
>>> @@ -278,6 +278,47 @@ struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
>>> EXPORT_SYMBOL_GPL(irq_find_matching_fwspec);
>>>
>>> /**
>>> + * irq_domain_is_msi_remap - Check if @domain or any parent
>>> + * has MSI remapping support
>>> + * @domain: domain pointer
>>> + */
>>> +static bool irq_domain_is_msi_remap(struct irq_domain *domain)
>>> +{
>>> + struct irq_domain *h = domain;
>>> +
>>> + for (; h; h = h->parent) {
>>> + if (h->flags & IRQ_DOMAIN_FLAG_MSI_REMAP)
>>> + return true;
>>> + }
>>> + return false;
>>> +}
>>> +
>>> +/**
>>> + * irq_domain_check_msi_remap() - Checks whether all MSI
>>> + * irq domains implement IRQ remapping
>>> + */
>>> +bool irq_domain_check_msi_remap(void)
>>> +{
>>> + struct irq_domain *h;
>>> + bool ret = true;
>>> +
>>> + mutex_lock(&irq_domain_mutex);
>>> + list_for_each_entry(h, &irq_domain_list, link) {
>>> + if (((h->bus_token & DOMAIN_BUS_PCI_MSI) ||
>>> + (h->bus_token & DOMAIN_BUS_PLATFORM_MSI) ||
>>> + (h->bus_token & DOMAIN_BUS_FSL_MC_MSI)) &&
>>> + !irq_domain_is_msi_remap(h)) {
>>
>> (h->bus_token & DOMAIN_BUS_PCI_MSI) and co looks quite wrong. bus_token
>> is not a bitmap, and DOMAIN_BUS_* not a single bit value (see enum
>> irq_domain_bus_token). Surely this should read
>> (h->bus_token == DOMAIN_BUS_PCI_MSI).
> Oh I did not notice that. Thanks.
>
> Any other comments on the irqdomain side? Do you think the current
> approach consisting in looking at those bus tokens and their parents
> looks good?
To be completely honest, I don't like it much, as having to enumerate
all the bus types can come up with could become quite a burden in the
long run. I'd rather be able to identify MSI capable domains by
construction. I came up with the following approach (fully untested):
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 281a40f..7779796 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -183,8 +183,11 @@ enum {
/* Irq domain is an IPI domain with single virq */
IRQ_DOMAIN_FLAG_IPI_SINGLE = (1 << 3),
+ /* Irq domain implements MSIs */
+ IRQ_DOMAIN_FLAG_MSI = (1 << 4),
+
/* Irq domain is MSI remapping capable */
- IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 4),
+ IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 5),
/*
* Flags starting from IRQ_DOMAIN_FLAG_NONCORE are reserved
@@ -450,6 +453,11 @@ static inline bool irq_domain_is_ipi_single(struct irq_domain *domain)
{
return domain->flags & IRQ_DOMAIN_FLAG_IPI_SINGLE;
}
+
+static inline bool irq_domain_is_msi(struct irq_domain *domain)
+{
+ return domain->flags & IRQ_DOMAIN_FLAG_MSI;
+}
#else /* CONFIG_IRQ_DOMAIN_HIERARCHY */
static inline void irq_domain_activate_irq(struct irq_data *data) { }
static inline void irq_domain_deactivate_irq(struct irq_data *data) { }
@@ -481,6 +489,11 @@ static inline bool irq_domain_is_ipi_single(struct irq_domain *domain)
{
return false;
}
+
+static inline bool irq_domain_is_msi(struct irq_domain *domain)
+{
+ return false;
+}
#endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */
#else /* CONFIG_IRQ_DOMAIN */
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 700caea..33b6921 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -304,10 +304,7 @@ bool irq_domain_check_msi_remap(void)
mutex_lock(&irq_domain_mutex);
list_for_each_entry(h, &irq_domain_list, link) {
- if (((h->bus_token & DOMAIN_BUS_PCI_MSI) ||
- (h->bus_token & DOMAIN_BUS_PLATFORM_MSI) ||
- (h->bus_token & DOMAIN_BUS_FSL_MC_MSI)) &&
- !irq_domain_is_msi_remap(h)) {
+ if (irq_domain_is_msi(h) && !irq_domain_is_msi_remap(h)) {
ret = false;
goto out;
}
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index ee23006..b637263 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -270,7 +270,7 @@ struct irq_domain *msi_create_irq_domain(struct fwnode_handle *fwnode,
if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS)
msi_domain_update_chip_ops(info);
- return irq_domain_create_hierarchy(parent, 0, 0, fwnode,
+ return irq_domain_create_hierarchy(parent, IRQ_DOMAIN_FLAG_MSI, 0, fwnode,
&msi_domain_ops, info);
}
Thoughts?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
From: Fabio Estevam @ 2017-01-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483477049-19056-6-git-send-email-steve_longerbeam@mentor.com>
On Tue, Jan 3, 2017 at 6:57 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> + camera: ov5642 at 3c {
> + compatible = "ovti,ov5642";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5642>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + clock-names = "xclk";
> + reg = <0x3c>;
> + xclk = <24000000>;
> + DOVDD-supply = <&vgen4_reg>; /* 1.8v */
> + AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
> + rev B board is VGEN5 */
Please use vgen3 so that by default we have the valid AVDD-supply for
revC boards which is more recent and more the users have access to.
> + mipi_camera: ov5640 at 3c {
> + compatible = "ovti,ov5640_mipi";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5640>;
> + reg = <0x3c>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + clock-names = "xclk";
> + xclk = <24000000>;
> + DOVDD-supply = <&vgen4_reg>; /* 1.8v */
> + AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
> + rev B board is VGEN5 */
Same here.
> + pinctrl_ov5640: ov5640grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x80000000
> + MX6QDL_PAD_SD1_CLK__GPIO1_IO20 0x80000000
Please avoid all the 0x80000000 IOMUX settings and replace them by
their real values.
^ permalink raw reply
* [PATCH v4 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Rob Herring @ 2017-01-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483536954-27203-3-git-send-email-appanad@xilinx.com>
On Wed, Jan 04, 2017 at 07:05:53PM +0530, Kedareswara rao Appana wrote:
> When VDMA is configured for more than one frame in the h/w
> for example h/w is configured for n number of frames and user
> Submits n number of frames and triggered the DMA using issue_pending API.
> In the current driver flow we are submitting one frame at a time
> but we should submit all the n number of frames at one time as the h/w
> Is configured for n number of frames.
Please fix run-on sentences, capitalization, and word wrapping.
>
> This patch fixes this issue.
>
> Reviewed-by: Jose Abreu <joabreu@synopsys.com>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> Changes for v4:
> ---> Add Check for framestore configuration on Transmit case as well
> as suggested by Jose Abreu.
> ---> Modified the dev_dbg checks to dev_warn checks as suggested
> by Jose Abreu.
> Changes for v3:
> ---> Added Checks for frame store configuration. If frame store
> Configuration is not present at the h/w level and user
> Submits less frames added debug prints in the driver as relevant.
> Changes for v2:
> ---> Fixed race conditions in the driver as suggested by Jose Abreu
> ---> Fixed unnecessray if else checks in the vdma_start_transfer
> as suggested by Laurent Pinchart.
>
> .../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 2 +
> drivers/dma/xilinx/xilinx_dma.c | 79 +++++++++++++++-------
> 2 files changed, 58 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> index a2b8bfa..1f65e09 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> @@ -66,6 +66,8 @@ Optional child node properties:
> Optional child node properties for VDMA:
> - xlnx,genlock-mode: Tells Genlock synchronization is
> enabled/disabled in hardware.
> +- xlnx,fstore-config: Tells Whether Frame Store Configuration is
> + enabled/disabled in hardware.
What's the default (when not present)? That should be the most
common case. Looks like the code treats this as bool, but that's
not clear here. The name is not clear what it is doing. Enabling or
disabling the feature?
> Optional child node properties for AXI DMA:
> -dma-channels: Number of dma channels in child node.
>
^ permalink raw reply
* [PATCH] arm64: restore get_current() optimisation
From: Will Deacon @ 2017-01-04 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483468021-8237-1-git-send-email-mark.rutland@arm.com>
On Tue, Jan 03, 2017 at 06:27:01PM +0000, Mark Rutland wrote:
> Hi Catalin,
>
> My THREAD_INFO_IN_TASK series had an unintended performance regression in
> get_current() / current_thread_info(). Could you please take the below as a
> fix for the next rc?
>
> Thanks,
> Mark.
>
> ---->8----
> Commit c02433dd6de32f04 ("arm64: split thread_info from task stack")
> inverted the relationship between get_current() and
> current_thread_info(), with sp_el0 now holding the current task_struct
> rather than the current thead_info. The new implementation of
> get_current() prevents the compiler from being able to optimize repeated
> calls to either, resulting in a noticeable penalty in some
> microbenchmarks.
>
> This patch restores the previous optimisation by implementing
> get_current() in the same way as our old current_thread_info(), using a
> non-volatile asm statement.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reported-by: Davidlohr Bueso <dbueso@suse.de>
> ---
> arch/arm64/include/asm/current.h | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
Acked-by: Will Deacon <will.deacon@arm.com>
Thanks for putting this back like it was!
Will
^ permalink raw reply
* [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface
From: Will Deacon @ 2017-01-04 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103173456.18154-1-lorenzo.pieralisi@arm.com>
On Tue, Jan 03, 2017 at 05:34:56PM +0000, Lorenzo Pieralisi wrote:
> With the introduction of the new iommu_{register/get}_instance()
> interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT
> agnostic") (based on struct fwnode_handle as look-up token, so firmware
> agnostic) to register IOMMU instances with the core IOMMU layer there is
> no reason to keep the old OF based interface around any longer.
>
> Convert all the IOMMU drivers (and OF IOMMU core code) that rely on the
> of_iommu_{set/get}_ops() to the new kernel interface to register/retrieve
> IOMMU instances and remove the of_iommu_{set/get}_ops() remaining glue
> code in order to complete the interface rework.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> Exynos, msm and mtk code compile tested only owing to lack of
> test platforms, I would appreciate some help in testing this
> patch on those platforms before merging it even if it is just
> a simple interface conversion.
>
> Thanks,
> Lorenzo
>
> drivers/iommu/exynos-iommu.c | 2 +-
> drivers/iommu/msm_iommu.c | 2 +-
> drivers/iommu/mtk_iommu.c | 2 +-
> drivers/iommu/of_iommu.c | 4 ++--
> include/linux/of_iommu.h | 11 -----------
> 5 files changed, 5 insertions(+), 16 deletions(-)
Thanks for following up with this cleanup, Lorenzo. I'll queue it locally,
and send it to Joerg for 4.11 if he doesn't apply it manually before then.
Will
^ permalink raw reply
* [PATCH] arm64: mm: fix show_pte KERN_CONT fallout
From: Will Deacon @ 2017-01-04 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483453646-13617-1-git-send-email-mark.rutland@arm.com>
On Tue, Jan 03, 2017 at 02:27:26PM +0000, Mark Rutland wrote:
> Recent changes made KERN_CONT mandatory for continued lines. In the
> absence of KERN_CONT, a newline may be implicit inserted by the core
> printk code.
>
> In show_pte, we (erroneously) use printk without KERN_CONT for continued
> prints, resulting in output being split across a number of lines, and
> not matching the intended output, e.g.
>
> [ff000000000000] *pgd=00000009f511b003
> , *pud=00000009f4a80003
> , *pmd=0000000000000000
>
> Fix this by using pr_cont() for all the continuations.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/mm/fault.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Acked-by: Will Deacon <will.deacon@arm.com>
Catalin can pick this one up for 4.10.
Will
^ permalink raw reply
* [GIT PULL] ARM: exynos: Late mach/soc for v4.10
From: Arnd Bergmann @ 2017-01-04 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482003132-8844-1-git-send-email-krzk@kernel.org>
On Saturday, December 17, 2016 9:32:12 PM CET Krzysztof Kozlowski wrote:
> After our discussions about not-breaking out-of-tree DTB with SCU
> change in DeviceTree, I prepared an updated pull request without
> the questioned changes.
>
> Ten days ago I prepared a tag, pushed it... and apparently forgot to send pull
> request. At least, I don't have such email in my outbox. Dunno.
>
> So let's send it now, better late then never. With just few commits (without
> the DT SCU changes). These were sitting in the next for very long.
Sorry for the delay. The patches in here are all straightforward, so
I'm applying them for fixes now.
Arnd
^ permalink raw reply
* [PATCH] arm64: Don't trace __switch_to if function graph tracer is enabled
From: Will Deacon @ 2017-01-04 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482360288-124624-1-git-send-email-joelaf@google.com>
On Wed, Dec 21, 2016 at 02:44:46PM -0800, Joel Fernandes wrote:
> Function graph tracer shows negative time (wrap around) when tracing
> __switch_to if the nosleep-time trace option is enabled.
>
> Time compensation for nosleep-time is done by an ftrace probe on
> sched_switch. This doesn't work well for the following events (with
> letters representing timestamps):
> A - sched switch probe called for task T switch out
> B - __switch_to calltime is recorded
> C - sched_switch probe called for task T switch in
> D - __switch_to rettime is recorded
>
> If C - A > D - B, then we end up over compensating for the time spent in
> __switch_to giving rise to negative times in the trace output.
>
> On x86, __switch_to is not traced if function graph tracer is enabled.
> Do the same for arm64 as well.
>
> Cc: Todd Kjos <tkjos@google.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Joel Fernandes <joelaf@google.com>
> ---
> arch/arm64/kernel/process.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks, queued for 4.11.
Will
^ permalink raw reply
* [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface
From: Robin Murphy @ 2017-01-04 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103173456.18154-1-lorenzo.pieralisi@arm.com>
[+Yong Wu for mtk_iommu]
On 03/01/17 17:34, Lorenzo Pieralisi wrote:
> With the introduction of the new iommu_{register/get}_instance()
> interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT
> agnostic") (based on struct fwnode_handle as look-up token, so firmware
> agnostic) to register IOMMU instances with the core IOMMU layer there is
> no reason to keep the old OF based interface around any longer.
>
> Convert all the IOMMU drivers (and OF IOMMU core code) that rely on the
> of_iommu_{set/get}_ops() to the new kernel interface to register/retrieve
> IOMMU instances and remove the of_iommu_{set/get}_ops() remaining glue
> code in order to complete the interface rework.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Looking at before-and-after disassemblies, of_iommu.o is binary
identical, and exynos-iommu.o differs only in the use of dev->fwnode
rather than &dev->of_node->fwnode (and is binary identical if I hack it
back to the latter). I'm not sure why the (GCC 6.2) codegen for
mtk_iommu.o changes quite so much when merely replacing a callsite with
the contents of its static inline callee, but it does :/
Robin.
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> Exynos, msm and mtk code compile tested only owing to lack of
> test platforms, I would appreciate some help in testing this
> patch on those platforms before merging it even if it is just
> a simple interface conversion.
>
> Thanks,
> Lorenzo
>
> drivers/iommu/exynos-iommu.c | 2 +-
> drivers/iommu/msm_iommu.c | 2 +-
> drivers/iommu/mtk_iommu.c | 2 +-
> drivers/iommu/of_iommu.c | 4 ++--
> include/linux/of_iommu.h | 11 -----------
> 5 files changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 57ba0d3..b79e4c4 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -628,7 +628,7 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
>
> pm_runtime_enable(dev);
>
> - of_iommu_set_ops(dev->of_node, &exynos_iommu_ops);
> + iommu_register_instance(dev->fwnode, &exynos_iommu_ops);
>
> return 0;
> }
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index b09692b..9cd3cee 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -737,7 +737,7 @@ static int msm_iommu_probe(struct platform_device *pdev)
> }
>
> list_add(&iommu->dev_node, &qcom_iommu_devices);
> - of_iommu_set_ops(pdev->dev.of_node, &msm_iommu_ops);
> + iommu_register_instance(pdev->dev.fwnode, &msm_iommu_ops);
>
> pr_info("device mapped at %p, irq %d with %d ctx banks\n",
> iommu->base, iommu->irq, iommu->ncb);
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 1479c76..0596ab2 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -655,7 +655,7 @@ static int mtk_iommu_init_fn(struct device_node *np)
> return ret;
> }
>
> - of_iommu_set_ops(np, &mtk_iommu_ops);
> + iommu_register_instance(&np->fwnode, &mtk_iommu_ops);
> return 0;
> }
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 0f57ddc..d7f480a 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -127,7 +127,7 @@ static const struct iommu_ops
> "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
> return NULL;
>
> - ops = of_iommu_get_ops(iommu_spec.np);
> + ops = iommu_get_instance(&iommu_spec.np->fwnode);
> if (!ops || !ops->of_xlate ||
> iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
> ops->of_xlate(&pdev->dev, &iommu_spec))
> @@ -157,7 +157,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
> "#iommu-cells", idx,
> &iommu_spec)) {
> np = iommu_spec.np;
> - ops = of_iommu_get_ops(np);
> + ops = iommu_get_instance(&np->fwnode);
>
> if (!ops || !ops->of_xlate ||
> iommu_fwspec_init(dev, &np->fwnode, ops) ||
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 6a7fc50..13394ac 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -31,17 +31,6 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>
> #endif /* CONFIG_OF_IOMMU */
>
> -static inline void of_iommu_set_ops(struct device_node *np,
> - const struct iommu_ops *ops)
> -{
> - iommu_register_instance(&np->fwnode, ops);
> -}
> -
> -static inline const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> -{
> - return iommu_get_instance(&np->fwnode);
> -}
> -
> extern struct of_device_id __iommu_of_table;
>
> typedef int (*of_iommu_init_fn)(struct device_node *);
>
^ 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