* [PATCHv6 0/3] pwm: imx: support output polarity inversion
From: Vladimir Zapolskiy @ 2016-09-12 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909091857.7a263220@ipc1.ka-ro>
Hi Lothar,
On 09/09/2016 10:18 AM, Lothar Wa?mann wrote:
> Hi,
>
> On Thu, 08 Sep 2016 15:15:57 -0700 Stefan Agner wrote:
>> On 2014-10-10 07:22, Lothar Wa?mann wrote:
>>> This patch series adds support for polarity inversion to the pwm-imx
>>> driver. The patches have been tested on i.MX6, i.MX53 and with the
>>> ti-ehrpwm.c driver.
>>
>> Do you know what prevented this patchset from getting merged?
>>
> No idea.
>
>> We are looking for Polarity support in PWM for too, this is especially
>> useful for backlight control.
>>
> Actually the PWM driver may be the wrong place to achieve this. When
> the backlight driver sets the brightness to 0 to switch the backlight
> off, it will disable the PWM. This will make the PWM pin go LOW and
> thus turn the backlight to full brightness rather than off (unless there
> is an additional GPIO that controls a backlight enable pin on the LCD).
>
I've just realized that I had submitted practically the same change
(excluding iMX specifics) and about the same time in October 2014, but
my v1 is one and a half hours later than yours preceding v6 :)
Since I've subscribed to the linux-pwm right before sending my changes,
I don't have your changes in my mailbox. Would you mind to review my
v3 "pwm: support backward compatibility of DTB extending PWM args":
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/303833.html
then incorporate anything you find useful into your series and resend
v7? Or just resend the rebased v6 if nothing is found attracting?
In my turn I'll spend time to review the series and test it on iMX.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH V2 00/10] PM / Domains: Add support for removing PM domains
From: Rafael J. Wysocki @ 2016-09-12 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFqd6vH=eCKBSQg0Q5w9x8sd0SiZ42E7yJn6ZDWP1OMuZg@mail.gmail.com>
On Monday, September 12, 2016 03:02:13 PM Ulf Hansson wrote:
> On 12 September 2016 at 13:01, Jon Hunter <jonathanh@nvidia.com> wrote:
> > In order to safely remove PM domains there are a few changes that need to be
> > made to ensure that no one is holding an external reference to a PM domain
> > after it has been removed. One solution, implemented here, solves this by
> > eliminating external references to PM domain.
> >
> > Changes from V1:
> > - Added test when removing a PM domain to ensure the PM domain provider
> > has been removed.
> > - Re-organised patches 8-10 so that patch #8 adds the code to verify if
> > the provider is present, patch #9 adds basic support for removing PM
> > domains and patch #10 adds support for removing PM domains by provider.
> >
> > Changes from initial RFC:
> > - Renamed functions made static per Ulf's feedback.
> > - Added patch to clean-up provider/xlate APIs per Ulf's feedback
> > - Re-worked and simplified the association between PM domains and PM
> > domain providers. Dropped the 'provider_data' variable from the
> > generic_pm_domain structure in favour of using the fwnode_handle.
> > - Split patch for removing PM domains into multiple patches per Ulf's
> > feedback.
> >
> > Jon Hunter (10):
> > PM / Domains: Add new helper functions for device-tree
> > ARM: EXYNOS: Remove calls to of_genpd_get_from_provider()
> > staging: board: Remove calls to of_genpd_get_from_provider()
> > PM / Domains: Don't expose generic_pm_domain structure to clients
> > PM / Domains: Don't expose xlate and provider helper functions
> > PM / Domains: Verify the PM domain is present when adding a provider
> > PM / Domains: Prepare for adding support to remove PM domains
> > PM / Domains: Store the provider in the PM domain structure
> > PM / Domains: Add support for removing PM domains
> > PM / Domains: Add support for removing nested PM domains by provider
> >
> > drivers/base/power/domain.c | 353 +++++++++++++++++++++++++++++++++++----
> > drivers/soc/samsung/pm_domains.c | 23 +--
> > drivers/staging/board/board.c | 9 +-
> > include/linux/pm_domain.h | 74 ++++----
> > 4 files changed, 364 insertions(+), 95 deletions(-)
> >
> > --
> > 2.1.4
> >
>
> Jon, thanks for being patient and keep working on this series! I have
> now completed the review and I am happy with this version.
>
> Also, I remember Krzysztof requested an immutable branch for this
> series, I guess Rafael can arrange that if still needed!?
Yes, I can do that.
I think I'll get to these patches later today and if not, then tomorrow.
Thanks,
Rafael
^ permalink raw reply
* [UPDATE PATCH V10 1/8] ACPI: I/O Remapping Table (IORT) initial support
From: Rafael J. Wysocki @ 2016-09-12 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D6A7DD.1060305@arm.com>
On Monday, September 12, 2016 02:04:29 PM Marc Zyngier wrote:
> On 12/09/16 13:37, Tomasz Nowicki wrote:
> > Hi Rafael,
> >
> > On 09.09.2016 11:20, Lorenzo Pieralisi wrote:
> >> Hi Rafael,
> >>
> >> On Wed, Sep 07, 2016 at 01:56:52PM +0200, Tomasz Nowicki wrote:
> >>> IORT shows representation of IO topology for ARM based systems.
> >>> It describes how various components are connected together on
> >>> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
> >>> http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
> >>>
> >>> Initial support allows to detect IORT table presence and save its
> >>> root pointer obtained through acpi_get_table(). The pointer validity
> >>> depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap
> >>> is not set while using IORT nodes we would dereference unmapped pointers.
> >>>
> >>> For the aforementioned reason call iort_table_detect() from acpi_init()
> >>> which guarantees acpi_gbl_permanent_mmap to be set at that point.
> >>>
> >>> Add generic helpers which are helpful for scanning and retrieving
> >>> information from IORT table content. List of the most important helpers:
> >>> - iort_find_dev_node() finds IORT node for a given device
> >>> - iort_node_map_rid() maps device RID and returns IORT node which provides
> >>> final translation
> >>>
> >>> IORT support is placed under drivers/acpi/arm64/ new directory due to its
> >>> ARM64 specific nature. The code there is considered only for ARM64.
> >>> The long term plan is to keep all ARM64 specific tables support
> >>> in this place e.g. GTDT table.
> >>>
> >>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> >>> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>> ---
> >>
> >> Apart from the minor commit logs oversights we consider these two
> >> patches ready to go, please let us know if there is something you want
> >> changed since we are at risk of missing yet another merge window.
> >>
> >> It is ARM64 specific code, we created and moved the code to its
> >> ARM64 specific directory and we are happy to maintain it as such,
> >> we need your ACK to get this done so if there is something you
> >> want changed please let us know otherwise I would ask your ACK
> >> on these two patches to give Marc a go-ahead for -next and
> >> hopefully 4.9.
> >
> > Kindly reminder. Is there anything we need to do more about these
> > patches? Please let us know. Note this is the major thing for incoming
> > IORT more advance feature.
>
> May I convey a slight sense of urgency here? I'd like to cut the irqchip
> branch for 4.9 pretty soon (this week), in order to let it sink in -next
> for a few days at the very least.
>
> It'd be a bit disappointing if these patches missed the boat this time
> again.
Both [1-2/8] are fine by me.
Please feel free to add my ACKs to those when you apply them.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] ARM: fix the uaccess crash on PB11MPCore
From: Linus Walleij @ 2016-09-12 13:38 UTC (permalink / raw)
To: linux-arm-kernel
The following patch was sketched by Russell in response to my
crashes on the PB11MPCore after the patch for software-based
priviledged no access support for ARMv8.1. See this thread:
http://marc.info/?l=linux-arm-kernel&m=144051749807214&w=2
I am unsure what is going on, I suspect everyone involved in
the discussion is. I just want to repost this to get the
discussion restarted, as I still have to apply this patch
with every kernel iteration to get my PB11MPCore Realview
running.
Testing by Neil Armstrong on the Oxnas NAS has revealed that
this bug exist also on that widely deployed hardware, so
we are probably currently regressing all ARM11MPCore systems.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/kernel/smp_tlb.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
index 22313cb53362..9af0701f7094 100644
--- a/arch/arm/kernel/smp_tlb.c
+++ b/arch/arm/kernel/smp_tlb.c
@@ -9,6 +9,7 @@
*/
#include <linux/preempt.h>
#include <linux/smp.h>
+#include <linux/uaccess.h>
#include <asm/smp_plat.h>
#include <asm/tlbflush.h>
@@ -40,8 +41,11 @@ static inline void ipi_flush_tlb_mm(void *arg)
static inline void ipi_flush_tlb_page(void *arg)
{
struct tlb_args *ta = (struct tlb_args *)arg;
+ unsigned int __ua_flags = uaccess_save_and_enable();
local_flush_tlb_page(ta->ta_vma, ta->ta_start);
+
+ uaccess_restore(__ua_flags);
}
static inline void ipi_flush_tlb_kernel_page(void *arg)
@@ -54,8 +58,11 @@ static inline void ipi_flush_tlb_kernel_page(void *arg)
static inline void ipi_flush_tlb_range(void *arg)
{
struct tlb_args *ta = (struct tlb_args *)arg;
+ unsigned int __ua_flags = uaccess_save_and_enable();
local_flush_tlb_range(ta->ta_vma, ta->ta_start, ta->ta_end);
+
+ uaccess_restore(__ua_flags);
}
static inline void ipi_flush_tlb_kernel_range(void *arg)
--
2.7.4
^ permalink raw reply related
* [PATCH v4 6/9] pinctrl: Add IRQ support to STM32 gpios
From: Alexandre Torgue @ 2016-09-12 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYYoMqCqq=L53LFUxCM=q00q5YhcxB=+-ZhxkAUbJEB5Q@mail.gmail.com>
Hi Linus,
On 09/12/2016 02:58 PM, Linus Walleij wrote:
> On Thu, Sep 8, 2016 at 5:47 PM, Alexandre Torgue
> <alexandre.torgue@st.com> wrote:
>
>> Just one question, when you say "super-complex irqchip in use", do you mean
>> I could use another (simplest) solution to handle this EXTI controller?
>
> I don't know, GPIOLIB_IRQCHIP is to be used for some specific
> cases documented in Documentation/gpio/driver.txt.
>
> For anything complex, we either need to have this hairy code
> or invent new abstractions.
>
Ok I see
.
> For now, I assume this is needed...
Yes it is.
Regards
Alex
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* [PATCH] RFC: ARM: fix the uaccess crash on PB11MPCore
From: Linus Walleij @ 2016-09-12 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <78f8cd15-6cde-0493-e429-43d047dd58f7@baylibre.com>
On Fri, Sep 9, 2016 at 9:57 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 07/11/2016 07:08 PM, Linus Walleij wrote:
>> The following patch was sketched by Russell in response to my
>> crashes on the PB11MPCore after the patch for software-based
>> priviledged no access support for ARMv8.1. See this thread:
>> http://marc.info/?l=linux-arm-kernel&m=144051749807214&w=2
>>
>> I am unsure what is going on, I suspect everyone involved in
>> the discussion is. I just want to repost this to get the
>> discussion restarted, as I still have to apply this patch
>> with every kernel iteration to get my PB11MPCore Realview
>> running.
>>
>> I also know that Oxnas has actual, mass-deployed NAS (PogoPlug
>> Pro variants) using PB11MPCore, and that they may or may not
>> be seeing the same issue so I want their feedback on this: do
>> you or do you not see this with mainline, or have you not even
>> tested?
>>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Neil Armstrong <narmstrong@baylibre.com>
>> Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> arch/arm/kernel/smp_tlb.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>
> Hi Linus, Russell, Arnd,
>
> I made a quick port ox OX820 over v4.8-rc4 and when enabling CONFIG_CPU_SW_DOMAIN_PAN
> I get the following trace at boot time :
> [ 1.690000] Unable to handle kernel paging request at virtual address b6f23684
> [ 1.690000] Unable to handle kernel paging request at virtual address b6f95ef4
> [ 1.690000] pgd = c281c000
> [ 1.690000] [b6f95ef4] *pgd=62821831, *pte=00000000, *ppte=00000000
> [ 1.690000] Internal error: Oops: 81f [#1] SMP ARM
> [ 1.690000] Modules linked in:
> [ 1.690000] CPU: 1 PID: 65 Comm: mount Not tainted 4.8.0-rc4-00001-g0e9c45d-dirty #22
> [ 1.690000] Hardware name: Generic DT based system
> [ 1.690000] task: c2aad860 task.stack: c2814000
> [ 1.690000] PC is at ipi_flush_tlb_page+0x34/0x44
> [ 1.690000] LR is at on_each_cpu_mask+0x58/0x60
> [ 1.690000] pc : [<c010d3dc>] lr : [<c017d584>] psr: 20000193
> [ 1.690000] sp : c2815da0 ip : 00000002 fp : 00067c40
> [ 1.690000] r10: c0702744 r9 : 67c4079f r8 : 67c9e75f
> [ 1.690000] r7 : c2815dbc r6 : c010d3a8 r5 : c2816164 r4 : 20000113
> [ 1.690000] r3 : 00000000 r2 : b6f95003 r1 : 00000003 r0 : 00000003
> [ 1.690000] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
> [ 1.690000] Control: 00c5787d Table: 6281c00a DAC: 00000051
> [ 1.690000] Process mount (pid: 65, stack limit = 0xc2814190)
> [ 1.690000] Stack: (0xc2815da0 to 0xc2816000)
> [...]
> [ 1.690000] ---[ end trace 8f1207a6d611da09 ]---
>
> When applying this patch, it solved the issue.
>
> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
So this problem appears on all ARM11MPcore, not just the RealView.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] BUG: atmel_serial: Interrupts not disabled on close
From: Richard Genoud @ 2016-09-12 13:34 UTC (permalink / raw)
To: linux-arm-kernel
Since commit 18dfef9c7f87 ("serial: atmel: convert to irq handling
provided mctrl-gpio"), interrupts from GPIOs are not disabled any more
when the serial port is closed, leading to an oops when the one of the
input pin is toggled (CTS/DSR/DCD/RNG).
This is only the case if those pins are used as GPIOs, i.e. declared
like that:
usart1: serial at f8020000 {
/* CTS and DTS will be handled by GPIO */
status = "okay";
rts-gpios = <&pioB 17 GPIO_ACTIVE_LOW>;
cts-gpios = <&pioB 16 GPIO_ACTIVE_LOW>;
dtr-gpios = <&pioB 14 GPIO_ACTIVE_LOW>;
dsr-gpios = <&pioC 31 GPIO_ACTIVE_LOW>;
rng-gpios = <&pioB 12 GPIO_ACTIVE_LOW>;
dcd-gpios = <&pioB 15 GPIO_ACTIVE_LOW>;
};
That's because modem interrupts used to be freed in atmel_shutdown().
After commit 18dfef9c7f87 ("serial: atmel: convert to irq handling
provided mctrl-gpio"), this code was just removed.
Calling atmel_disable_ms() disables the interrupts and everything works
fine again.
Tested on at91sam9g35-cm
(This patch doesn't apply on -stable kernels, fixes for 4.4 and 4.7 will
be sent after this one is applied.)
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Fixes: 18dfef9c7f87 ("serial: atmel: convert to irq handling provided mctrl-gpio")
---
drivers/tty/serial/atmel_serial.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 2eaa18ddef61..8bbde52db376 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1929,6 +1929,9 @@ static void atmel_shutdown(struct uart_port *port)
{
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+ /* Disable modem control lines interrupts */
+ atmel_disable_ms(port);
+
/* Disable interrupts at device level */
atmel_uart_writel(port, ATMEL_US_IDR, -1);
@@ -1979,8 +1982,6 @@ static void atmel_shutdown(struct uart_port *port)
*/
free_irq(port->irq, port);
- atmel_port->ms_irq_enabled = false;
-
atmel_flush_buffer(port);
}
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6ul: Add DTS for liteSOM module
From: Fabio Estevam @ 2016-09-12 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b9766440-d35d-b931-2883-3dcc11425337@grinn-global.com>
On Mon, Sep 12, 2016 at 8:16 AM, Marcin Niestroj
<m.niestroj@grinn-global.com> wrote:
> We are including imx6ul.dtsi which is GPLv2 only. Do you plan to
> relicense it?
Yes, I think it is a good idea.
> What do you mean by non-Linux users? What other projects are using dts?
FreeBSD, U-Boot, Barebox.
^ permalink raw reply
* [PATCH v4 1/6] net: stmmac: dwmac-rk: add rk3366 & rk3399 specific data
From: Rob Herring @ 2016-09-12 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472752204-8924-2-git-send-email-wxt@rock-chips.com>
On Fri, Sep 02, 2016 at 01:49:59AM +0800, Caesar Wang wrote:
> From: Roger Chen <roger.chen@rock-chips.com>
>
> Add constants and callback functions for the dwmac on rk3228/rk3229 socs.
> As can be seen, the base structure is the same, only registers and the
> bits in them moved slightly.
>
> Signed-off-by: Roger Chen <roger.chen@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
>
> ---
>
> Changes in v4:
> - Fixes from the original patch on https://patchwork.kernel.org/patch/9274557/
>
> Changes in v3: None
> Changes in v2: None
>
> .../devicetree/bindings/net/rockchip-dwmac.txt | 8 +-
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 226 +++++++++++++++++++++
> 2 files changed, 232 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> index cccd945..95383c5 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> @@ -3,8 +3,12 @@ Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC)
> The device node has following properties.
>
> Required properties:
> - - compatible: Can be one of "rockchip,rk3228-gmac", "rockchip,rk3288-gmac",
> - "rockchip,rk3368-gmac"
> + - compatible: should be "rockchip,<name>-gamc"
s/gamc/gmac/
Please send a follow-up patch to fix.
> + "rockchip,rk3228-gmac": found on RK322x SoCs
> + "rockchip,rk3288-gmac": found on RK3288 SoCs
> + "rockchip,rk3366-gmac": found on RK3366 SoCs
> + "rockchip,rk3368-gmac": found on RK3368 SoCs
> + "rockchip,rk3399-gmac": found on RK3399 SoCs
> - reg: addresses and length of the register sets for the device.
> - interrupts: Should contain the GMAC interrupts.
> - interrupt-names: Should contain the interrupt names "macirq".
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Timur Tabi @ 2016-09-12 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D6AA54.6000208@laposte.net>
Sebastian Frias wrote:
> 3rd parties could choose to write a driver (as opposed to use say, a user-mode
> library) if it fits their programming model better, if they think they would
> have better performance, or other reasons.
>
> The main idea is to make DT the authoritative source of HW description.
Do you really expect the open-source community to make a serious effort
to support out-of-tree drivers written by developers who have no
intention of upstreaming?
There's a process for writing a Linux kernel driver with a DT binding.
That process is not broken.
>> >Putting smoething together that's only sufficient to support some
>> >out-of-tree driver with implicit assumptions that we are not aware of is
>> >far from fantastic.
> That does not seem very positive and it is not the case anyway, otherwise we
> would not be consulting here:-)
Mark is correct. Trying to create a device tree binding, and getting it
correct 100% the first time, without an actual drivers is just
impossible. To even attempt that is folly.
> Agreed, right now this whole thing seems like a really hypothetical question,
Yes, it is.
> but the intention is good.
I'm not sure I agree with that.
> Actually, I think it would encourage more SoC manufacturers to use DT as a way
> to document their HW, which is a good thing.
No it isn't. SOC manufacturers should just release the documentation
they have.
> But if I understood correctly your comment, you are basically saying that
> without an example is hard to say.
> Since the question seems understood, do you have an example of other SoC's
> doing something similar?
Similar to what? Every upstream driver today is written the way we're
talking about -- submit the driver with the binding, and both are
reviewed together.
> I've seen some big DT descriptions, but it is difficult to know if we are the
> first ones trying to use the DT in this way.
Hopefully, you'll be the last.
^ permalink raw reply
* [PATCH v4 0/5] arm/arm64: vgic-new: Implement API for vGICv3 live migration
From: Marc Zyngier @ 2016-09-12 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473510138-4719-1-git-send-email-vijay.kilari@gmail.com>
On 10/09/16 13:22, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> This patchset adds API for saving and restoring
> of VGICv3 registers to support live migration with new vgic feature.
> This API definition is as per version of VGICv3 specification
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>
> Compatible live migration QEMU patches will be sent later.
Could you please point to the QEMU patches as well? I need to be able to
test the this infrastructure.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Sebastian Frias @ 2016-09-12 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912123809.GB13741@leverpostej>
Hi Mark,
On 09/12/2016 02:38 PM, Mark Rutland wrote:
>>
>> 3rd party users of said SoC could then write kernel modules for such HW
>> blocks using the DT description. The DT would thus become the authoritative
>> source of information regarding register programming for the SoC.
>
> I don't follow this part entirely. Why are you expecting thrid parties
> to write a driver for those blocks rather than upstreaming a driver for
> them?
3rd parties could choose to write a driver (as opposed to use say, a user-mode
library) if it fits their programming model better, if they think they would
have better performance, or other reasons.
The main idea is to make DT the authoritative source of HW description.
>
>> Currently, HW blocks for which there is no public driver (that it is
>> accessed through user-mode libraries or firmware) require a separate
>> HW description (be it Documentation, headers, etc.)
>>
>> Since the DT describes the HW, it would make sense to expose the HW through
>> DT, that would centralise the HW description.
>
> I would generally agree that the hardware should be described in DT.
> The difficulty is that without a 'real' user it's not always possible to
> tell if we're describing the thing correctly.
>
That may be true, but so far we are not discussing changing DT's API so it
should not have big ramifications.
Besides, what "makes sense now" may "not make sense tomorrow" depending on
how the HW is modified.
We have somehow learned the hard-way that "le mieux est l'ennemi du bien"
(the better is the enemy of the good) and we are trying to take a more
practical (and flexible) approach.
> Putting smoething together that's only sufficient to support some
> out-of-tree driver with implicit assumptions that we are not aware of is
> far from fantastic.
That does not seem very positive and it is not the case anyway, otherwise we
would not be consulting here :-)
Agreed, right now this whole thing seems like a really hypothetical question,
but the intention is good.
Actually, I think it would encourage more SoC manufacturers to use DT as a way
to document their HW, which is a good thing.
>
>> However, after discussing over IRC, it looks like there was no guidance on
>> this. Some people think submitting DT properties/nodes without a corresponding
>> Linux driver is frowned upon, while others thought it was an odd limitation
>> and suggested asking here.
>
> Unfortunately, I think that the area is sufficiently vague that there
> simply is no clear and general answer.
>
> For the sake of discussion, an example of a particular block, along with
> what you expect/need to describe would be helpful.
I don't have a more concrete example now.
As I stated, right now HW description is not centralised, and thus different
bits of information are cherry-picked by hand from HW description into DT for
bootloader, DT for Linux, Documentation/headers for 3rd-parties, etc.
But if I understood correctly your comment, you are basically saying that
without an example is hard to say.
Since the question seems understood, do you have an example of other SoC's
doing something similar?
I've seen some big DT descriptions, but it is difficult to know if we are the
first ones trying to use the DT in this way.
Best regards,
Sebastian
^ permalink raw reply
* [PATCHv2 1/3] Documentation: dt: Add TI SCI clock driver
From: Rob Herring @ 2016-09-12 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472733635-22661-2-git-send-email-t-kristo@ti.com>
On Thu, Sep 01, 2016 at 03:40:33PM +0300, Tero Kristo wrote:
> Add a clock implementation, TI SCI clock, that will hook to the common
> clock framework, and allow each clock to be controlled via TI SCI
> protocol.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Tested-by: Dave Gerlach <d-gerlach@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> .../devicetree/bindings/clock/ti,sci-clk.txt | 51 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> new file mode 100644
> index 0000000..231cb80
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> @@ -0,0 +1,51 @@
> +Texas Instruments TI-SCI Clocks
> +===============================
> +
> +All clocks on Texas Instruments' SoCs that contain a System Controller,
> +are only controlled by this entity. Communication between a host processor
> +running an OS and the System Controller happens through a protocol known
> +as TI-SCI[1]. This clock implementation plugs into the common clock
> +framework and makes use of the TI-SCI protocol on clock API requests.
> +
> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +Required properties:
> +-------------------
> +- compatible: Must be "ti,sci-clk"
> +- #clock-cells: Shall be 2.
> + In clock consumers, this cell represents the device ID and clock ID
> + exposed by the PM firmware. The assignments can be found in the header
> + files <dt-bindings/genpd/<soc>.h> (which covers the device IDs) and
> + <dt-bindings/clock/<soc>.h> (which covers the clock IDs), where <soc>
> + is the SoC involved, for example 'k2g'.
> +- ti,sci: Phandle to the TI SCI device to use for managing the clocks
> +
> +Optional properties:
> +-------------------
> +- ti,ssc-clocks: Array of phandle clocks that shall enable spread spectrum
> + clocking while enabled
> +- ti,allow-freq-change-clocks: Array of phandle clocks that shall allow
> + dynamic clock frequency changes by firmware
> +- ti,input-term-clocks: Array of phandle clocks that shall enable input
> + termination
These seem like a random set of features to control. What determines the
clocks for these? If it is based on the SoC, then make your compatible
string SoC specific and don't put this into DT.
Rob
^ permalink raw reply
* [PATCH][V2] dma-mapping: add in missing white space in error message text
From: Colin King @ 2016-09-12 13:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
A dev_warn message spans two lines and the literal string is missing
a white space between words. Add the white space and reformat the
message to not span multiple lines.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/arm/common/dmabounce.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 3012816..afeb5e3 100644
--- a/arch/arm/common/dmabounce.c
+++ b/arch/arm/common/dmabounce.c
@@ -546,9 +546,7 @@ void dmabounce_unregister_dev(struct device *dev)
set_dma_ops(dev, NULL);
if (!device_info) {
- dev_warn(dev,
- "Never registered with dmabounce but attempting"
- "to unregister!\n");
+ dev_warn(dev, "Never registered with dmabounce but attempting to unregister!\n");
return;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Marc Zyngier @ 2016-09-12 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912125948.GB13899@leverpostej>
On 12/09/16 13:59, Mark Rutland wrote:
> On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote:
>> On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
>>> On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
>>>> The changes in arm64's <asm/arch_timer.h> are going to conflict with
>>>> some cleanup [1,2] that just landed in the arm64 for-next/core branch.
>>>>
>>>> Could you please rebase atop of that?
>>>
>>> Well, we should figure out what tree this is going through first. There
>>> are a mixture of arm, arm64, driver and dts changes here and not all
>>> of it is carrying the appropriate acks for me to queue it.
>>
>> Given that mix, I had assumed that this would all go through the arm64
>> tree -- I see that Rob has already acked the binding, and I'm happy to
>> give my ack for the driver once that's in shape.
>
> Now I see that I'd missed the arch/arm changes in patch 4, which lack a
> relevant ack.
>
> Given that, I don't know what to suggest.
I wouldn't mind delaying patch 4 until it gets acked by RMK, as it
doesn't impact the functionality.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] ARM: dma-mapping: add in missing white space in error message text
From: Robin Murphy @ 2016-09-12 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912125212.32739-1-colin.king@canonical.com>
On 12/09/16 13:52, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> A dev_warn message spans two lines and the literal string is missing
> a white space between words. Add the white space.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> arch/arm/common/dmabounce.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
> index 3012816..f47767b 100644
> --- a/arch/arm/common/dmabounce.c
> +++ b/arch/arm/common/dmabounce.c
> @@ -547,7 +547,7 @@ void dmabounce_unregister_dev(struct device *dev)
>
> if (!device_info) {
> dev_warn(dev,
> - "Never registered with dmabounce but attempting"
> + "Never registered with dmabounce but attempting "
> "to unregister!\n");
Per Documentation/CodingStyle, better to put the whole thing onto one
line so that, say, "git grep 'attempting to unregister'" doesn't leave
one scratching ones head in confusion.
Of course, even better would be to get rid of the whole thing and
convert ARM to use SWIOTLB, but hey, one thing at a time ;)
Robin.
> return;
> }
>
^ permalink raw reply
* [UPDATE PATCH V10 1/8] ACPI: I/O Remapping Table (IORT) initial support
From: Marc Zyngier @ 2016-09-12 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <38e36eee-cece-75db-4781-5727dd11c93d@semihalf.com>
On 12/09/16 13:37, Tomasz Nowicki wrote:
> Hi Rafael,
>
> On 09.09.2016 11:20, Lorenzo Pieralisi wrote:
>> Hi Rafael,
>>
>> On Wed, Sep 07, 2016 at 01:56:52PM +0200, Tomasz Nowicki wrote:
>>> IORT shows representation of IO topology for ARM based systems.
>>> It describes how various components are connected together on
>>> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
>>> http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
>>>
>>> Initial support allows to detect IORT table presence and save its
>>> root pointer obtained through acpi_get_table(). The pointer validity
>>> depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap
>>> is not set while using IORT nodes we would dereference unmapped pointers.
>>>
>>> For the aforementioned reason call iort_table_detect() from acpi_init()
>>> which guarantees acpi_gbl_permanent_mmap to be set at that point.
>>>
>>> Add generic helpers which are helpful for scanning and retrieving
>>> information from IORT table content. List of the most important helpers:
>>> - iort_find_dev_node() finds IORT node for a given device
>>> - iort_node_map_rid() maps device RID and returns IORT node which provides
>>> final translation
>>>
>>> IORT support is placed under drivers/acpi/arm64/ new directory due to its
>>> ARM64 specific nature. The code there is considered only for ARM64.
>>> The long term plan is to keep all ARM64 specific tables support
>>> in this place e.g. GTDT table.
>>>
>>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>>> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> ---
>>
>> Apart from the minor commit logs oversights we consider these two
>> patches ready to go, please let us know if there is something you want
>> changed since we are at risk of missing yet another merge window.
>>
>> It is ARM64 specific code, we created and moved the code to its
>> ARM64 specific directory and we are happy to maintain it as such,
>> we need your ACK to get this done so if there is something you
>> want changed please let us know otherwise I would ask your ACK
>> on these two patches to give Marc a go-ahead for -next and
>> hopefully 4.9.
>
> Kindly reminder. Is there anything we need to do more about these
> patches? Please let us know. Note this is the major thing for incoming
> IORT more advance feature.
May I convey a slight sense of urgency here? I'd like to cut the irqchip
branch for 4.9 pretty soon (this week), in order to let it sink in -next
for a few days at the very least.
It'd be a bit disappointing if these patches missed the boat this time
again.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH V2 10/10] dmaengine: qcom_hidma: add MSI support for interrupts
From: Sinan Kaya @ 2016-09-12 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
The interrupts can now be delivered as platform MSI interrupts
on newer platforms. The code looks for a new OF and ACPI strings
in order to enable the functionality.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.c | 128 ++++++++++++++++++++++++++++++++++++++++++--
drivers/dma/qcom/hidma.h | 2 +
drivers/dma/qcom/hidma_ll.c | 8 +++
3 files changed, 133 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index e244e10..cc023ae 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -56,6 +56,7 @@
#include <linux/irq.h>
#include <linux/atomic.h>
#include <linux/pm_runtime.h>
+#include <linux/msi.h>
#include "../dmaengine.h"
#include "hidma.h"
@@ -70,6 +71,7 @@
#define HIDMA_ERR_INFO_SW 0xFF
#define HIDMA_ERR_CODE_UNEXPECTED_TERMINATE 0x0
#define HIDMA_NR_DEFAULT_DESC 10
+#define HIDMA_MSI_INTS 11
static inline struct hidma_dev *to_hidma_dev(struct dma_device *dmadev)
{
@@ -553,6 +555,15 @@ static irqreturn_t hidma_chirq_handler(int chirq, void *arg)
return hidma_ll_inthandler(chirq, lldev);
}
+static irqreturn_t hidma_chirq_handler_msi(int chirq, void *arg)
+{
+ struct hidma_lldev **lldevp = arg;
+ struct hidma_dev *dmadev = to_hidma_dev_from_lldev(lldevp);
+
+ return hidma_ll_inthandler_msi(chirq, *lldevp,
+ 1 << (chirq - dmadev->msi_virqbase));
+}
+
static ssize_t hidma_show_values(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -590,6 +601,98 @@ static int hidma_create_sysfs_entry(struct hidma_dev *dev, char *name,
return device_create_file(dev->ddev.dev, attrs);
}
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+static void hidma_write_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
+{
+ struct device *dev = msi_desc_to_dev(desc);
+ struct hidma_dev *dmadev = dev_get_drvdata(dev);
+
+ if (!desc->platform.msi_index) {
+ writel(msg->address_lo, dmadev->dev_evca + 0x118);
+ writel(msg->address_hi, dmadev->dev_evca + 0x11C);
+ writel(msg->data, dmadev->dev_evca + 0x120);
+ }
+}
+
+static void hidma_free_msis(void *data)
+{
+ struct device *dev = data;
+
+ platform_msi_domain_free_irqs(dev);
+}
+#endif
+
+static int hidma_request_msi(struct hidma_dev *dmadev,
+ struct platform_device *pdev)
+{
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+ int rc;
+ struct msi_desc *desc;
+ struct msi_desc *failed_desc = NULL;
+
+ rc = platform_msi_domain_alloc_irqs(&pdev->dev, HIDMA_MSI_INTS,
+ hidma_write_msi_msg);
+ if (rc)
+ return rc;
+
+ for_each_msi_entry(desc, &pdev->dev) {
+ if (!desc->platform.msi_index)
+ dmadev->msi_virqbase = desc->irq;
+
+ rc = devm_request_irq(&pdev->dev, desc->irq,
+ hidma_chirq_handler_msi,
+ 0, "qcom-hidma-msi",
+ &dmadev->lldev);
+ if (rc) {
+ failed_desc = desc;
+ break;
+ }
+ }
+
+ if (rc) {
+ /* free allocated MSI interrupts above */
+ for_each_msi_entry(desc, &pdev->dev) {
+ if (desc == failed_desc)
+ break;
+ devm_free_irq(&pdev->dev, desc->irq,
+ &dmadev->lldev);
+ }
+ } else {
+ /* Add callback to free MSIs on teardown */
+ devm_add_action(&pdev->dev, hidma_free_msis,
+ &pdev->dev);
+ hidma_ll_setup_irq(dmadev->lldev, true);
+
+ }
+ if (rc)
+ dev_warn(&pdev->dev,
+ "failed to request MSI irq, falling back to wired IRQ\n");
+ return rc;
+#else
+ return -EINVAL;
+#endif
+}
+
+static bool hidma_msi_capable(struct device *dev)
+{
+ struct acpi_device *adev = ACPI_COMPANION(dev);
+ const char *of_compat;
+ int ret;
+
+ if (!adev || acpi_disabled) {
+ ret = device_property_read_string(dev, "compatible",
+ &of_compat);
+ if (ret)
+ return false;
+
+ ret = strcmp(of_compat, "qcom,hidma-1.1");
+ } else {
+ ret = strcmp(acpi_device_hid(adev), "QCOM8062");
+ }
+
+ return ret == 0;
+}
+
static int hidma_probe(struct platform_device *pdev)
{
struct hidma_dev *dmadev;
@@ -599,6 +702,7 @@ static int hidma_probe(struct platform_device *pdev)
void __iomem *evca;
void __iomem *trca;
int rc;
+ bool msi;
pm_runtime_set_autosuspend_delay(&pdev->dev, HIDMA_AUTOSUSPEND_TIMEOUT);
pm_runtime_use_autosuspend(&pdev->dev);
@@ -660,6 +764,12 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->ddev.device_terminate_all = hidma_terminate_all;
dmadev->ddev.copy_align = 8;
+ /*
+ * Determine the MSI capability of the platform. Old HW doesn't
+ * support MSI.
+ */
+ msi = hidma_msi_capable(&pdev->dev);
+
device_property_read_u32(&pdev->dev, "desc-count",
&dmadev->nr_descriptors);
@@ -688,10 +798,17 @@ static int hidma_probe(struct platform_device *pdev)
goto dmafree;
}
- rc = devm_request_irq(&pdev->dev, chirq, hidma_chirq_handler, 0,
- "qcom-hidma", dmadev->lldev);
- if (rc)
- goto uninit;
+ platform_set_drvdata(pdev, dmadev);
+ if (msi)
+ rc = hidma_request_msi(dmadev, pdev);
+
+ if (!msi || rc) {
+ hidma_ll_setup_irq(dmadev->lldev, false);
+ rc = devm_request_irq(&pdev->dev, chirq, hidma_chirq_handler,
+ 0, "qcom-hidma", dmadev->lldev);
+ if (rc)
+ goto uninit;
+ }
INIT_LIST_HEAD(&dmadev->ddev.channels);
rc = hidma_chan_init(dmadev, 0);
@@ -707,7 +824,6 @@ static int hidma_probe(struct platform_device *pdev)
hidma_debug_init(dmadev);
hidma_create_sysfs_entry(dmadev, "chid", S_IRUGO);
dev_info(&pdev->dev, "HI-DMA engine driver registration complete\n");
- platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
pm_runtime_put_autosuspend(dmadev->ddev.dev);
return 0;
@@ -746,12 +862,14 @@ static int hidma_remove(struct platform_device *pdev)
#if IS_ENABLED(CONFIG_ACPI)
static const struct acpi_device_id hidma_acpi_ids[] = {
{"QCOM8061"},
+ {"QCOM8062"},
{},
};
#endif
static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
+ {.compatible = "qcom,hidma-1.1",},
{},
};
MODULE_DEVICE_TABLE(of, hidma_match);
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 181f7e0..05f8ba4 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -115,6 +115,7 @@ struct hidma_dev {
int irq;
int chidx;
u32 nr_descriptors;
+ int msi_virqbase;
struct hidma_lldev *lldev;
void __iomem *dev_trca;
@@ -153,6 +154,7 @@ struct hidma_lldev *hidma_ll_init(struct device *dev, u32 max_channels,
u8 chidx);
int hidma_ll_uninit(struct hidma_lldev *llhndl);
irqreturn_t hidma_ll_inthandler(int irq, void *arg);
+irqreturn_t hidma_ll_inthandler_msi(int irq, void *arg, int cause);
void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
u8 err_code);
int hidma_debug_init(struct hidma_dev *dmadev);
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 386a64c..5518d82 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -424,6 +424,14 @@ irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
return IRQ_HANDLED;
}
+irqreturn_t hidma_ll_inthandler_msi(int chirq, void *arg, int cause)
+{
+ struct hidma_lldev *lldev = arg;
+
+ hidma_ll_int_handler_internal(lldev, cause);
+ return IRQ_HANDLED;
+}
+
int hidma_ll_enable(struct hidma_lldev *lldev)
{
u32 val;
--
1.9.1
^ permalink raw reply related
* [PATCH V2 09/10] dmaengine: qcom_hidma: protect common data structures
From: Sinan Kaya @ 2016-09-12 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
When MSI interrupts are supported, error and the transfer interrupt can
come from multiple processor contexts.
Each error interrupt is an MSI interrupt. If the channel is disabled by
the first error interrupt, the remaining error interrupts will gracefully
return in the interrupt handler.
If an error is observed while servicing the completions in success case,
the posting of the completions will be aborted as soon as channel disabled
state is observed. The error interrupt handler will take it from there and
finish the remaining completions. We don't want to create multiple success
and error messages to be delivered to the client in mixed order.
Also got rid of hidma_post_completed method and moved the locks inside
hidma_ll_int_handler_internal function. Rearranged the assignments so that
variables are updated only when a lock is held.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma_ll.c | 142 ++++++++++++++++++--------------------------
1 file changed, 58 insertions(+), 84 deletions(-)
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index f0630e0..386a64c 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -198,18 +198,50 @@ static void hidma_ll_tre_complete(unsigned long arg)
}
}
-static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
- u8 err_info, u8 err_code)
+/*
+ * Called to handle the interrupt for the channel.
+ * Return a positive number if TRE or EVRE were consumed on this run.
+ * Return a positive number if there are pending TREs or EVREs.
+ * Return 0 if there is nothing to consume or no pending TREs/EVREs found.
+ */
+static int hidma_handle_tre_completion(struct hidma_lldev *lldev, u8 err_info,
+ u8 err_code)
{
+ u32 *current_evre;
struct hidma_tre *tre;
unsigned long flags;
+ u32 evre_write_off;
+ u32 cfg;
+ u32 offset;
+
+ evre_write_off = readl_relaxed(lldev->evca + HIDMA_EVCA_WRITE_PTR_REG);
+ if ((evre_write_off > lldev->evre_ring_size) ||
+ (evre_write_off % HIDMA_EVRE_SIZE)) {
+ dev_err(lldev->dev, "HW reports invalid EVRE write offset\n");
+ return -EINVAL;
+ }
spin_lock_irqsave(&lldev->lock, flags);
- tre = lldev->pending_tre_list[tre_iterator / HIDMA_TRE_SIZE];
+ if (lldev->evre_processed_off == evre_write_off) {
+ spin_unlock_irqrestore(&lldev->lock, flags);
+ return 0;
+ }
+ current_evre = lldev->evre_ring + lldev->evre_processed_off;
+ cfg = current_evre[HIDMA_EVRE_CFG_IDX];
+ if (!err_info) {
+ err_info = cfg >> HIDMA_EVRE_ERRINFO_BIT_POS;
+ err_info &= HIDMA_EVRE_ERRINFO_MASK;
+ }
+ if (!err_code)
+ err_code = (cfg >> HIDMA_EVRE_CODE_BIT_POS) &
+ HIDMA_EVRE_CODE_MASK;
+
+ offset = lldev->tre_processed_off;
+ tre = lldev->pending_tre_list[offset / HIDMA_TRE_SIZE];
if (!tre) {
spin_unlock_irqrestore(&lldev->lock, flags);
dev_warn(lldev->dev, "tre_index [%d] and tre out of sync\n",
- tre_iterator / HIDMA_TRE_SIZE);
+ lldev->tre_processed_off / HIDMA_TRE_SIZE);
return -EINVAL;
}
lldev->pending_tre_list[tre->tre_index] = NULL;
@@ -223,6 +255,14 @@ static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
atomic_set(&lldev->pending_tre_count, 0);
}
+
+ HIDMA_INCREMENT_ITERATOR(lldev->tre_processed_off, HIDMA_TRE_SIZE,
+ lldev->tre_ring_size);
+ HIDMA_INCREMENT_ITERATOR(lldev->evre_processed_off, HIDMA_EVRE_SIZE,
+ lldev->evre_ring_size);
+
+ writel(lldev->evre_processed_off,
+ lldev->evca + HIDMA_EVCA_DOORBELL_REG);
spin_unlock_irqrestore(&lldev->lock, flags);
tre->err_info = err_info;
@@ -232,86 +272,7 @@ static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
kfifo_put(&lldev->handoff_fifo, tre);
tasklet_schedule(&lldev->task);
- return 0;
-}
-
-/*
- * Called to handle the interrupt for the channel.
- * Return a positive number if TRE or EVRE were consumed on this run.
- * Return a positive number if there are pending TREs or EVREs.
- * Return 0 if there is nothing to consume or no pending TREs/EVREs found.
- */
-static int hidma_handle_tre_completion(struct hidma_lldev *lldev, u8 err_info,
- u8 err_code)
-{
- u32 evre_ring_size = lldev->evre_ring_size;
- u32 tre_ring_size = lldev->tre_ring_size;
- u32 tre_iterator, evre_iterator;
- u32 num_completed = 0;
-
- evre_write_off = readl_relaxed(lldev->evca + HIDMA_EVCA_WRITE_PTR_REG);
- tre_iterator = lldev->tre_processed_off;
- evre_iterator = lldev->evre_processed_off;
-
- if ((evre_write_off > evre_ring_size) ||
- (evre_write_off % HIDMA_EVRE_SIZE)) {
- dev_err(lldev->dev, "HW reports invalid EVRE write offset\n");
- return 0;
- }
-
- /*
- * By the time control reaches here the number of EVREs and TREs
- * may not match. Only consume the ones that hardware told us.
- */
- while ((evre_iterator != evre_write_off)) {
- u32 *current_evre = lldev->evre_ring + evre_iterator;
- u32 cfg;
-
- cfg = current_evre[HIDMA_EVRE_CFG_IDX];
- if (!err_info) {
- err_info = cfg >> HIDMA_EVRE_ERRINFO_BIT_POS;
- err_info &= HIDMA_EVRE_ERRINFO_MASK;
- }
- if (!err_code)
- err_code = (cfg >> HIDMA_EVRE_CODE_BIT_POS) &
- HIDMA_EVRE_CODE_MASK;
-
- if (hidma_post_completed(lldev, tre_iterator, err_info,
- err_code))
- break;
-
- HIDMA_INCREMENT_ITERATOR(tre_iterator, HIDMA_TRE_SIZE,
- tre_ring_size);
- HIDMA_INCREMENT_ITERATOR(evre_iterator, HIDMA_EVRE_SIZE,
- evre_ring_size);
-
- /*
- * Read the new event descriptor written by the HW.
- * As we are processing the delivered events, other events
- * get queued to the SW for processing.
- */
- evre_write_off =
- readl_relaxed(lldev->evca + HIDMA_EVCA_WRITE_PTR_REG);
- num_completed++;
- }
-
- if (num_completed) {
- u32 evre_read_off = (lldev->evre_processed_off +
- HIDMA_EVRE_SIZE * num_completed);
- u32 tre_read_off = (lldev->tre_processed_off +
- HIDMA_TRE_SIZE * num_completed);
-
- evre_read_off = evre_read_off % evre_ring_size;
- tre_read_off = tre_read_off % tre_ring_size;
-
- writel(evre_read_off, lldev->evca + HIDMA_EVCA_DOORBELL_REG);
-
- /* record the last processed tre offset */
- lldev->tre_processed_off = tre_read_off;
- lldev->evre_processed_off = evre_read_off;
- }
-
- return num_completed;
+ return 1;
}
void hidma_cleanup_pending_tre(struct hidma_lldev *lldev, u8 err_info,
@@ -399,6 +360,16 @@ static int hidma_ll_reset(struct hidma_lldev *lldev)
*/
static void hidma_ll_int_handler_internal(struct hidma_lldev *lldev, int cause)
{
+ if ((lldev->trch_state == HIDMA_CH_DISABLED) ||
+ (lldev->evch_state == HIDMA_CH_DISABLED)) {
+ dev_err(lldev->dev, "error 0x%x, already disabled...\n",
+ cause);
+
+ /* Clear out pending interrupts */
+ writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+ return;
+ }
+
if (cause & HIDMA_ERR_INT_MASK) {
dev_err(lldev->dev, "error 0x%x, disabling...\n",
cause);
@@ -430,6 +401,9 @@ static void hidma_ll_int_handler_internal(struct hidma_lldev *lldev, int cause)
*/
if (hidma_handle_tre_completion(lldev, 0, 0))
break;
+ if ((lldev->trch_state == HIDMA_CH_DISABLED) ||
+ (lldev->evch_state == HIDMA_CH_DISABLED))
+ break;
}
/* We consumed TREs or there are pending TREs or EVREs. */
--
1.9.1
^ permalink raw reply related
* [PATCH V2 08/10] dmaengine: qcom_hidma: add a common API to setup the interrupt
From: Sinan Kaya @ 2016-09-12 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
Introducing the hidma_ll_setup_irq function to set up the interrupt
type externally from the OS interface.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.h | 2 ++
drivers/dma/qcom/hidma_ll.c | 27 +++++++++++++++++++++++----
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 3f2ddd4..181f7e0 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -46,6 +46,7 @@ struct hidma_tre {
};
struct hidma_lldev {
+ bool msi_support; /* flag indicating MSI support */
bool initialized; /* initialized flag */
u8 trch_state; /* trch_state of the device */
u8 evch_state; /* evch_state of the device */
@@ -145,6 +146,7 @@ int hidma_ll_disable(struct hidma_lldev *lldev);
int hidma_ll_enable(struct hidma_lldev *llhndl);
void hidma_ll_set_transfer_params(struct hidma_lldev *llhndl, u32 tre_ch,
dma_addr_t src, dma_addr_t dest, u32 len, u32 flags);
+void hidma_ll_setup_irq(struct hidma_lldev *lldev, bool msi);
int hidma_ll_setup(struct hidma_lldev *lldev);
struct hidma_lldev *hidma_ll_init(struct device *dev, u32 max_channels,
void __iomem *trca, void __iomem *evca,
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 088935f..f0630e0 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -672,17 +672,36 @@ int hidma_ll_setup(struct hidma_lldev *lldev)
writel(HIDMA_EVRE_SIZE * nr_tres,
lldev->evca + HIDMA_EVCA_RING_LEN_REG);
- /* support IRQ only for now */
+ /* configure interrupts */
+ hidma_ll_setup_irq(lldev, lldev->msi_support);
+
+ rc = hidma_ll_enable(lldev);
+ if (rc)
+ return rc;
+
+ return rc;
+}
+
+void hidma_ll_setup_irq(struct hidma_lldev *lldev, bool msi)
+{
+ u32 val;
+
+ lldev->msi_support = msi;
+
+ /* disable interrupts again after reset */
+ writel(0, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+ writel(0, lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
+
+ /* support IRQ by default */
val = readl(lldev->evca + HIDMA_EVCA_INTCTRL_REG);
val &= ~0xF;
- val |= 0x1;
+ if (!lldev->msi_support)
+ val = val | 0x1;
writel(val, lldev->evca + HIDMA_EVCA_INTCTRL_REG);
/* clear all pending interrupts and enable them */
writel(ENABLE_IRQS, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
writel(ENABLE_IRQS, lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
-
- return hidma_ll_enable(lldev);
}
struct hidma_lldev *hidma_ll_init(struct device *dev, u32 nr_tres,
--
1.9.1
^ permalink raw reply related
* [PATCH V2 07/10] dmaengine: qcom_hidma: bring out interrupt cause
From: Sinan Kaya @ 2016-09-12 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
Bring out the interrupt cause to the top level so that MSI interrupts
can be hooked at a later stage.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma_ll.c | 72 +++++++++++++++++++++------------------------
1 file changed, 34 insertions(+), 38 deletions(-)
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index c911ca2..088935f 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -397,12 +397,24 @@ static int hidma_ll_reset(struct hidma_lldev *lldev)
* requests traditionally to the destination, this concept does not apply
* here for this HW.
*/
-irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
+static void hidma_ll_int_handler_internal(struct hidma_lldev *lldev, int cause)
{
- struct hidma_lldev *lldev = arg;
- u32 status;
- u32 enable;
- u32 cause;
+ if (cause & HIDMA_ERR_INT_MASK) {
+ dev_err(lldev->dev, "error 0x%x, disabling...\n",
+ cause);
+
+ /* Clear out pending interrupts */
+ writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+
+ /* No further submissions. */
+ hidma_ll_disable(lldev);
+
+ /* Driver completes the txn and intimates the client.*/
+ hidma_cleanup_pending_tre(lldev, 0xFF,
+ HIDMA_EVRE_STATUS_ERROR);
+
+ return;
+ }
/*
* Fine tuned for this HW...
@@ -412,45 +424,29 @@ irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
* interrupt delivery guarantees. Do not copy this code blindly and
* expect that to work.
*/
- status = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_STAT_REG);
- enable = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
- cause = status & enable;
-
- while (cause) {
- if (cause & HIDMA_ERR_INT_MASK) {
- dev_err(lldev->dev, "error 0x%x, disabling...\n",
- cause);
-
- /* Clear out pending interrupts */
- writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
-
- /* No further submissions. */
- hidma_ll_disable(lldev);
-
- /* Driver completes the txn and intimates the client.*/
- hidma_cleanup_pending_tre(lldev, 0xFF,
- HIDMA_EVRE_STATUS_ERROR);
- goto out;
- }
-
+ while (atomic_read(&lldev->pending_tre_count)) {
/*
* Try to consume as many EVREs as possible.
*/
- hidma_handle_tre_completion(lldev);
+ if (hidma_handle_tre_completion(lldev, 0, 0))
+ break;
+ }
- /* We consumed TREs or there are pending TREs or EVREs. */
- writel_relaxed(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+ /* We consumed TREs or there are pending TREs or EVREs. */
+ writel_relaxed(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+}
- /*
- * Another interrupt might have arrived while we are
- * processing this one. Read the new cause.
- */
- status = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_STAT_REG);
- enable = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
- cause = status & enable;
- }
+irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
+{
+ struct hidma_lldev *lldev = arg;
+ u32 status;
+ u32 enable;
+ u32 cause;
-out:
+ status = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_STAT_REG);
+ enable = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
+ cause = status & enable;
+ hidma_ll_int_handler_internal(lldev, cause);
return IRQ_HANDLED;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V2 06/10] dmaengine: qcom_hidma: make error and success path common
From: Sinan Kaya @ 2016-09-12 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
Remove code duplication by feeding the error code from outside
into successful data transfer handler.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma_ll.c | 34 ++++++++++------------------------
1 file changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 29fef4f..c911ca2 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -241,11 +241,11 @@ static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
* Return a positive number if there are pending TREs or EVREs.
* Return 0 if there is nothing to consume or no pending TREs/EVREs found.
*/
-static int hidma_handle_tre_completion(struct hidma_lldev *lldev)
+static int hidma_handle_tre_completion(struct hidma_lldev *lldev, u8 err_info,
+ u8 err_code)
{
u32 evre_ring_size = lldev->evre_ring_size;
u32 tre_ring_size = lldev->tre_ring_size;
- u32 err_info, err_code, evre_write_off;
u32 tre_iterator, evre_iterator;
u32 num_completed = 0;
@@ -268,10 +268,13 @@ static int hidma_handle_tre_completion(struct hidma_lldev *lldev)
u32 cfg;
cfg = current_evre[HIDMA_EVRE_CFG_IDX];
- err_info = cfg >> HIDMA_EVRE_ERRINFO_BIT_POS;
- err_info &= HIDMA_EVRE_ERRINFO_MASK;
- err_code =
- (cfg >> HIDMA_EVRE_CODE_BIT_POS) & HIDMA_EVRE_CODE_MASK;
+ if (!err_info) {
+ err_info = cfg >> HIDMA_EVRE_ERRINFO_BIT_POS;
+ err_info &= HIDMA_EVRE_ERRINFO_MASK;
+ }
+ if (!err_code)
+ err_code = (cfg >> HIDMA_EVRE_CODE_BIT_POS) &
+ HIDMA_EVRE_CODE_MASK;
if (hidma_post_completed(lldev, tre_iterator, err_info,
err_code))
@@ -314,27 +317,10 @@ static int hidma_handle_tre_completion(struct hidma_lldev *lldev)
void hidma_cleanup_pending_tre(struct hidma_lldev *lldev, u8 err_info,
u8 err_code)
{
- u32 tre_iterator;
- u32 tre_ring_size = lldev->tre_ring_size;
- int num_completed = 0;
- u32 tre_read_off;
-
- tre_iterator = lldev->tre_processed_off;
while (atomic_read(&lldev->pending_tre_count)) {
- if (hidma_post_completed(lldev, tre_iterator, err_info,
- err_code))
+ if (hidma_handle_tre_completion(lldev, err_info, err_code))
break;
- HIDMA_INCREMENT_ITERATOR(tre_iterator, HIDMA_TRE_SIZE,
- tre_ring_size);
- num_completed++;
}
- tre_read_off = (lldev->tre_processed_off +
- HIDMA_TRE_SIZE * num_completed);
-
- tre_read_off = tre_read_off % tre_ring_size;
-
- /* record the last processed tre offset */
- lldev->tre_processed_off = tre_read_off;
}
static int hidma_ll_reset(struct hidma_lldev *lldev)
--
1.9.1
^ permalink raw reply related
* [PATCH V2 05/10] dmaengine: qcom_hidma: make pending_tre_count atomic
From: Sinan Kaya @ 2016-09-12 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
Getting ready for the MSI interrupts. The pending_tre_count is used
in the interrupt handler to make sure all outstanding requests are
serviced.
Making it atomic so that it can be updated from multiple contexts.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.h | 2 +-
drivers/dma/qcom/hidma_dbg.c | 3 ++-
drivers/dma/qcom/hidma_ll.c | 13 ++++++-------
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index e52e207..3f2ddd4 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -58,7 +58,7 @@ struct hidma_lldev {
void __iomem *evca; /* Event Channel address */
struct hidma_tre
**pending_tre_list; /* Pointers to pending TREs */
- s32 pending_tre_count; /* Number of TREs pending */
+ atomic_t pending_tre_count; /* Number of TREs pending */
void *tre_ring; /* TRE ring */
dma_addr_t tre_dma; /* TRE ring to be shared with HW */
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
index fa827e5..87db285 100644
--- a/drivers/dma/qcom/hidma_dbg.c
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -74,7 +74,8 @@ static void hidma_ll_devstats(struct seq_file *s, void *llhndl)
seq_printf(s, "tre_ring_handle=%pap\n", &lldev->tre_dma);
seq_printf(s, "tre_ring_size = 0x%x\n", lldev->tre_ring_size);
seq_printf(s, "tre_processed_off = 0x%x\n", lldev->tre_processed_off);
- seq_printf(s, "pending_tre_count=%d\n", lldev->pending_tre_count);
+ seq_printf(s, "pending_tre_count=%d\n",
+ atomic_read(&lldev->pending_tre_count));
seq_printf(s, "evca=%p\n", lldev->evca);
seq_printf(s, "evre_ring=%p\n", lldev->evre_ring);
seq_printf(s, "evre_ring_handle=%pap\n", &lldev->evre_dma);
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 3224f24..29fef4f 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -218,10 +218,9 @@ static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
* Keep track of pending TREs that SW is expecting to receive
* from HW. We got one now. Decrement our counter.
*/
- lldev->pending_tre_count--;
- if (lldev->pending_tre_count < 0) {
+ if (atomic_dec_return(&lldev->pending_tre_count) < 0) {
dev_warn(lldev->dev, "tre count mismatch on completion");
- lldev->pending_tre_count = 0;
+ atomic_set(&lldev->pending_tre_count, 0);
}
spin_unlock_irqrestore(&lldev->lock, flags);
@@ -321,7 +320,7 @@ void hidma_cleanup_pending_tre(struct hidma_lldev *lldev, u8 err_info,
u32 tre_read_off;
tre_iterator = lldev->tre_processed_off;
- while (lldev->pending_tre_count) {
+ while (atomic_read(&lldev->pending_tre_count)) {
if (hidma_post_completed(lldev, tre_iterator, err_info,
err_code))
break;
@@ -548,7 +547,7 @@ void hidma_ll_queue_request(struct hidma_lldev *lldev, u32 tre_ch)
tre->err_code = 0;
tre->err_info = 0;
tre->queued = 1;
- lldev->pending_tre_count++;
+ atomic_inc(&lldev->pending_tre_count);
lldev->tre_write_offset = (lldev->tre_write_offset + HIDMA_TRE_SIZE)
% lldev->tre_ring_size;
spin_unlock_irqrestore(&lldev->lock, flags);
@@ -654,7 +653,7 @@ int hidma_ll_setup(struct hidma_lldev *lldev)
u32 val;
u32 nr_tres = lldev->nr_tres;
- lldev->pending_tre_count = 0;
+ atomic_set(&lldev->pending_tre_count, 0);
lldev->tre_processed_off = 0;
lldev->evre_processed_off = 0;
lldev->tre_write_offset = 0;
@@ -816,7 +815,7 @@ int hidma_ll_uninit(struct hidma_lldev *lldev)
tasklet_kill(&lldev->task);
memset(lldev->trepool, 0, required_bytes);
lldev->trepool = NULL;
- lldev->pending_tre_count = 0;
+ atomic_set(&lldev->pending_tre_count, 0);
lldev->tre_write_offset = 0;
rc = hidma_ll_reset(lldev);
--
1.9.1
^ permalink raw reply related
* [PATCH V2 04/10] dmaengine: qcom_hidma: configure DMA and MSI for OF
From: Sinan Kaya @ 2016-09-12 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
Configure the DMA bindings for the device tree based firmware.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma_mgmt.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 82f36e4..e8f6b84 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -375,8 +375,11 @@ static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
ret = PTR_ERR(new_pdev);
goto out;
}
+ of_node_get(child);
+ new_pdev->dev.of_node = child;
of_dma_configure(&new_pdev->dev, child);
-
+ of_msi_configure(&new_pdev->dev, child);
+ of_node_put(child);
kfree(res);
res = NULL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V2 03/10] of: irq: make of_msi_configure accessible from modules
From: Sinan Kaya @ 2016-09-12 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
The of_msi_configure routine is only accessible by the built-in
kernel drivers. Export this function so that modules can use it
too.
This function is useful for configuring MSI on child device tree
nodes on hierarchical objects.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/of/irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a2e68f7..20c09e0 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -767,3 +767,4 @@ void of_msi_configure(struct device *dev, struct device_node *np)
dev_set_msi_domain(dev,
of_msi_get_domain(dev, np, DOMAIN_BUS_PLATFORM_MSI));
}
+EXPORT_SYMBOL_GPL(of_msi_configure);
--
1.9.1
^ permalink raw reply related
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