* [PATCH v7 07/11] ARM: dts: alt: Enable UHS-I SDR-50 and SDR-104
From: Wolfram Sang @ 2016-09-16 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-8-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:04PM +0200, Simon Horman wrote:
> Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1}.
> And the sd-uhs-sdr104 property to SDHI0.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
If you drop sdr104 here for now as well:
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/2907a398/attachment-0001.sig>
^ permalink raw reply
* [PATCH v7 06/11] ARM: dts: r8a7794: set maximum frequency for SDHI clocks
From: Wolfram Sang @ 2016-09-16 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-7-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:03PM +0200, Simon Horman wrote:
> Define the upper limit otherwise the driver cannot utilize max speeds.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/54d0476b/attachment.sig>
^ permalink raw reply
* [PATCH v7 05/11] ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104
From: Wolfram Sang @ 2016-09-16 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916100031.GH14562@verge.net.au>
On Fri, Sep 16, 2016 at 12:00:32PM +0200, Simon Horman wrote:
> On Tue, Sep 13, 2016 at 12:57:02PM +0200, Simon Horman wrote:
> > Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
> > And the sd-uhs-sdr104 property to SDHI0.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> As SDR50 support is present in the driver in mainline (correct me if I am
> wrong!) I have queued this up after dropping the sdr104 portion and
> updating the changelog accordingly.
Looks good!
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/685f0fe7/attachment.sig>
^ permalink raw reply
* [PATCH v7 02/11] arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3
From: Wolfram Sang @ 2016-09-16 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916095500.GG14562@verge.net.au>
On Fri, Sep 16, 2016 at 11:55:00AM +0200, Simon Horman wrote:
> On Tue, Sep 13, 2016 at 12:56:59PM +0200, Simon Horman wrote:
> > From: Wolfram Sang <wsa+renesas@sang-engineering.com>
> >
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> As SDR50 support is present in the driver in mainline (correct me if I am
> wrong!) I am queuing this up.
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/dbe6ea4b/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: Kconfig: select GENERIC_CLOCKEVENTS_BROADCAST also on UP
From: Russell King - ARM Linux @ 2016-09-16 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474018340.2243.103.camel@pengutronix.de>
On Fri, Sep 16, 2016 at 11:32:20AM +0200, Lucas Stach wrote:
> Hi Russell,
>
> can you please take a look at this and tell if there is something wrong
> about it, or if you think it can go in?
>
> Without this patch the kernel is unable to use the deeper CPU idle
> states on i.MX6S if it isn't built with SMP support enabled.
Without spending a lot of time digging into this code, working out what
these configuration symbols do, I frankly don't know if it's a sensible
thing to do or not. I guess tglx knows this code like the back of his
hand, and would be in a better position to comment.
There's two factors there:
1. the amount of undocumented code in the kernel needing the code to be
read and understood to understand various aspects of it from the
architecture point of view.
2. your architecture maintainer has done very little actual platform
development (not through his own choice) for the last 10 or so years,
which means he's not had to dig into these areas.
So, I'm afraid I feel less than qualified on this at the moment. I'll
try to look into this and talk to tglx to work out whether it's a
sensible change. As I never had a reply to my last email to tglx about
threaded interrupts vs tasklets (for a reported performance regression
in my crypto patches already queued for the next merge window) I'm not
hoping for much help.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Marc Zyngier @ 2016-09-16 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474007187-18673-1-git-send-email-agraf@suse.de>
Hi Alex,
On 16/09/16 07:26, Alexander Graf wrote:
> Some systems out there (well, one type in particular - the Raspberry Pi series)
> do have virtualization capabilities in the core, but no ARM GIC interrupt
> controller.
>
> To run on these systems, the cleanest route is to just handle all
> interrupt delivery in user space and only deal with IRQ pins in the core
> side in KVM.
>
> This works pretty well already, but breaks when the guest starts to use
> architected timers, as these are handled straight inside kernel space today.
>
> This patch set allows user space to receive vtimer events as well as mask
> them, so that we can handle all vtimer related interrupt injection from user
> space, enabling us to use architected timer with user space gic emulation.
I have already voiced my concerns in the past, including face to face,
and I'm going to repeat it: I not keen at all on adding a new userspace
interface that is going to bitrot extremely quickly.
Let's face it, this new ABI will have a single user, with a limited
shelf life. I understand that the RPi is a popular product, but it looks
fairly obvious that this kind of sub-standard HW will eventually
disappear. We'll then be left with a userspace ABI that will break at
every single release, given that nobody in the RPi community actually
uses a mainline kernel.
And breaking this ABI will introduce userspace exploitable bugs, like
the one you've already shown. If anything, I would have loved to
completely kill the whole userspace GIC, because nobody cares. Yes, I
understand it is fun to have KVM running on the RPi. But the maintenance
costs far outweigh the fun aspect already.
You could still run KVM with an external emulated timer (not the arch
timer). No need for a new ABI for that.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] ARM: dts: wheat: add DU support
From: Simon Horman @ 2016-09-16 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ba5b2f8e-13f8-6c7d-17c1-44988d30a947@cogentembedded.com>
On Mon, Sep 12, 2016 at 08:52:40PM +0300, Sergei Shtylyov wrote:
> On 09/02/2016 12:29 AM, Sergei Shtylyov wrote:
>
> >Define the Wheat board dependent part of the DU device node.
> >Add the device nodes for the Analog Devices ADV7513 HDMI transmitters
> >connected to DU0/1. Add the necessary subnodes to interconnect DU with
> >HDMI transmitters/connectors.
> >
> >Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >
> >---
> >This patch is against the 'renesas-devel-20160901-v4.8-rc4' of Simon Horman's
> >'renesas.git' repo plus the Wheat CAN and SDHI patches posted earlier...
> >The path depends on the 2 DRM patches just posted in order to work correctly!
>
> In principle, both these patches have been queued by the maintainers...
> Simon, are you going to wait till they hit media_tree.git? Linus' tree?
I don't think that is necessary. I was waiting for some review.
But in any case it looks like this patch no longer applies cleanly.
Could you rebase?
^ permalink raw reply
* [PATCH] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Pavel Labath @ 2016-09-16 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916085825.GL3380@arm.com>
Hello Will,
thank you for the review. I will be a bit busy in the next few weeks,
so I don't think I'll be able to submit a revised version of the patch
that quickly. Until then, here I my responses.
On 16 September 2016 at 09:58, Will Deacon <will.deacon@arm.com> wrote:
> Hi Pavel,
>
> On Mon, Sep 12, 2016 at 03:07:24PM +0100, Pavel Labath wrote:
>> Arm64 hardware does not always report a watchpoint hit address that
>> matches one of the watchpoints set. It can also report an address
>> "near" the watchpoint if a single instruction access both watched and
>> unwatched addresses. There is no straight-forward way, short of
>> disassembling the offending instruction, to map that address back to
>> the watchpoint.
>>
>> Previously, when the hardware reported a watchpoint hit on an address
>> that did not match our watchpoint (this happens in case of instructions
>> which access large chunks of memory such as "stp") the process would
>> enter a loop where we would be continually resuming it (because we did
>> not recognise that watchpoint hit) and it would keep hitting the
>> watchpoint again and again. The tracing process would never get
>> notified of the watchpoint hit.
>>
>> This commit fixes the problem by looking at the watchpoints near the
>> address reported by the hardware. If the address does not exactly match
>> one of the watchpoints we have set, it attributes the hit to the
>> nearest watchpoint we have. This heuristic is a bit dodgy, but I don't
>> think we can do much more, given the hardware limitations.
>> I include a kernel selftest which triggers this code.
>
> Thanks for the patch. Comments inline.
>
>> Signed-off-by: Pavel Labath <labath@google.com>
>> ---
>> arch/arm64/kernel/hw_breakpoint.c | 104 +++++++---
>> tools/testing/selftests/breakpoints/Makefile | 5 +-
>> .../selftests/breakpoints/breakpoint_test-arm.c | 217 +++++++++++++++++++++
>> 3 files changed, 298 insertions(+), 28 deletions(-)
>> create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test-arm.c
>
> Could you split the test out into a separate patch please?
Sure thing.
>
>> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
>> index 26a6bf7..d0ebfe6 100644
>> --- a/arch/arm64/kernel/hw_breakpoint.c
>> +++ b/arch/arm64/kernel/hw_breakpoint.c
>> @@ -661,50 +661,80 @@ unlock:
>> }
>> NOKPROBE_SYMBOL(breakpoint_handler);
>>
>> +/*
>> + * Arm64 hardware does not always report a watchpoint hit address that matches
>> + * one of the watchpoints set. It can also report an address "near" the
>> + * watchpoint if a single instruction access both watched and unwatched
>> + * addresses. There is no straight-forward way, short of disassembling the
>> + * offending instruction, to map that address back to the watchpoint. This
>> + * function computes the distance of the memory access from the watchpoint as a
>> + * heuristic for the likelyhood that a given access triggered the watchpoint.
>> + *
>> + * See Section D2.10.5 "Determining the memory location that caused a Watchpoint
>> + * exception" of ARMv8 Architecture Reference Manual for details.
>> + *
>> + * The function returns the distance of the address from the bytes watched by
>> + * the watchpoint. In case of an exact match, it returns 0.
>> + */
>> +static u64 get_distance_from_watchpoint(unsigned long addr, int i,
>> + struct arch_hw_breakpoint *info)
>> +{
>> + u64 val, alignment_mask, wp_low, wp_high;
>> + u32 ctrl_reg;
>> + int first_bit;
>> + struct arch_hw_breakpoint_ctrl ctrl;
>> +
>> + /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
>> + if (is_compat_task()) {
>> + if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
>> + alignment_mask = 0x7;
>> + else
>> + alignment_mask = 0x3;
>> + } else {
>> + alignment_mask = 0x7;
>> + }
>
> We have identical logic elsewhere in this file, so please stick this into
> a get_watchpoint_alignment_mask function.
I presume you mean the code in arch_validate_hwbkpt_settings. I'll put
that up as a separate patch as well, as it does not seem to be a
completely trivial cut'n'paste job.
>
>> +
>> + val = read_wb_reg(AARCH64_DBG_REG_WVR, i) & ~alignment_mask;
>> +
>> + ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
>> + decode_ctrl_reg(ctrl_reg, &ctrl);
>> + first_bit = ffs(ctrl.len);
>> + if (first_bit == 0)
>> + return -1;
>> + wp_low = val + first_bit - 1;
>> + wp_high = val + fls(ctrl.len) - 1;
>> + if (addr < wp_low)
>> + return wp_low - addr;
>> + else if (addr > wp_high)
>> + return addr - wp_high;
>
> Why do you need to read the control register? We already have the length
> in the arch_hw_breakpoint, and that should be sufficient for the check, no?
I did this because the original code (see below) relied on reading the
register instead of struct arch_hw_breakpoint. However, if you believe
that is ok, I can do it that way. It will certainly make this code
less complicated.
>
>> static int watchpoint_handler(unsigned long addr, unsigned int esr,
>> struct pt_regs *regs)
>> {
>> - int i, step = 0, *kernel_step, access;
>> - u32 ctrl_reg;
>> - u64 val, alignment_mask;
>> + int i, step = 0, *kernel_step, access, closest_match;
>> + u64 min_dist = -1, dist;
>> struct perf_event *wp, **slots;
>> struct debug_info *debug_info;
>> struct arch_hw_breakpoint *info;
>> - struct arch_hw_breakpoint_ctrl ctrl;
>>
>> slots = this_cpu_ptr(wp_on_reg);
>> debug_info = ¤t->thread.debug;
>>
>> + /*
>> + * Find all watchpoints that match the reported address. If no exact
>> + * match is found. Attribute the hit to the closest watchpoint.
>> + */
>> for (i = 0; i < core_num_wrps; ++i) {
>> rcu_read_lock();
>>
>> wp = slots[i];
>> -
>> if (wp == NULL)
>> goto unlock;
>>
>> - info = counter_arch_bp(wp);
>> - /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
>> - if (is_compat_task()) {
>> - if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
>> - alignment_mask = 0x7;
>> - else
>> - alignment_mask = 0x3;
>> - } else {
>> - alignment_mask = 0x7;
>> - }
>> -
>> - /* Check if the watchpoint value matches. */
>> - val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
>> - if (val != (addr & ~alignment_mask))
>> - goto unlock;
>> -
>> - /* Possible match, check the byte address select to confirm. */
>> - ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
>> - decode_ctrl_reg(ctrl_reg, &ctrl);
>> - if (!((1 << (addr & alignment_mask)) & ctrl.len))
>> - goto unlock;
Original code reading the control register.
>> -
>> /*
>> * Check that the access type matches.
>> * 0 => load, otherwise => store
>> @@ -714,6 +744,17 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
>> if (!(access & hw_breakpoint_type(wp)))
>> goto unlock;
>>
>> + info = counter_arch_bp(wp);
>> +
>> + dist = get_distance_from_watchpoint(addr, i, info);
>> + if (dist < min_dist) {
>> + min_dist = dist;
>> + closest_match = i;
>> + }
>> + /* Is this an exact match? */
>> + if (dist != 0)
>> + goto unlock;
>> +
>> info->trigger = addr;
>> perf_bp_event(wp, regs);
>>
>> @@ -724,6 +765,15 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
>> unlock:
>> rcu_read_unlock();
>> }
>> + if (min_dist > 0 && min_dist != -1) {
>> + /* No exact match found. */
>> + rcu_read_lock();
>> + wp = slots[closest_match];
>> + info = counter_arch_bp(wp);
>> + info->trigger = addr;
>> + perf_bp_event(wp, regs);
>> + rcu_read_unlock();
>
> Hmm, are you sure it's safe to drop and retake the RCU lock here? If the
> event is destroyed before we retake the RCU lock, won't htis go horribly
> wrong? It's probably best to hold the lock outside the loop :(
I am definitely not sure of that. :) It's not even clear to me what
data does this lock protect. Doing the locking outside the loop would
certainly be safer though.
regards,
pavel
^ permalink raw reply
* [PATCH] ARM: dts: gose: use generic pinctrl properties in SDHI nodes
From: Simon Horman @ 2016-09-16 10:04 UTC (permalink / raw)
To: linux-arm-kernel
Since 16ccaf5bb5a5 ("pinctrl: sh-pfc: Accept standard function, pins and
groups properties") renesas pfc drivers accept generic "function", "pins"
and "groups" properties.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7793-gose.dts | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 90af18600124..dc311eba4444 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -346,18 +346,18 @@
};
sdhi0_pins: sd0 {
- renesas,groups = "sdhi0_data4", "sdhi0_ctrl";
- renesas,function = "sdhi0";
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
};
sdhi1_pins: sd1 {
- renesas,groups = "sdhi1_data4", "sdhi1_ctrl";
- renesas,function = "sdhi1";
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
};
sdhi2_pins: sd2 {
- renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
- renesas,function = "sdhi2";
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
};
qspi_pins: qspi {
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v7 05/11] ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104
From: Simon Horman @ 2016-09-16 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-6-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:02PM +0200, Simon Horman wrote:
> Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
> And the sd-uhs-sdr104 property to SDHI0.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
As SDR50 support is present in the driver in mainline (correct me if I am
wrong!) I have queued this up after dropping the sdr104 portion and
updating the changelog accordingly.
The result is as follows:
From: Simon Horman <horms+renesas@verge.net.au>
Date: Tue, 13 Sep 2016 12:57:02 +0200
Subject: [PATCH] ARM: dts: koelsch: arm64: dts: r8a7795: salvator-x: enable
UHS for SDHI 0, 1 & 3
Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 33 ++++++++++++++++++++++++++++++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index f8a7d090fd01..f17bfa000f73 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -360,16 +360,37 @@
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
};
sdhi1_pins: sd1 {
groups = "sdhi1_data4", "sdhi1_ctrl";
function = "sdhi1";
+ power-source = <3300>;
+ };
+
+ sdhi1_pins_uhs: sd1_uhs {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <1800>;
};
sdhi2_pins: sd2 {
groups = "sdhi2_data4", "sdhi2_ctrl";
function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2_uhs {
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
};
qspi_pins: qspi {
@@ -454,33 +475,39 @@
&sdhi0 {
pinctrl-0 = <&sdhi0_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi0>;
vqmmc-supply = <&vccq_sdhi0>;
cd-gpios = <&gpio6 6 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
+ sd-uhs-sdr50;
status = "okay";
};
&sdhi1 {
pinctrl-0 = <&sdhi1_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi1_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi1>;
vqmmc-supply = <&vccq_sdhi1>;
cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio6 15 GPIO_ACTIVE_HIGH>;
+ sd-uhs-sdr50;
status = "okay";
};
&sdhi2 {
pinctrl-0 = <&sdhi2_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi2_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi2>;
vqmmc-supply = <&vccq_sdhi2>;
cd-gpios = <&gpio6 22 GPIO_ACTIVE_LOW>;
+ sd-uhs-sdr50;
status = "okay";
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v7 02/11] arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3
From: Simon Horman @ 2016-09-16 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-3-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:56:59PM +0200, Simon Horman wrote:
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
As SDR50 support is present in the driver in mainline (correct me if I am
wrong!) I am queuing this up.
^ permalink raw reply
* [PATCH v7 04/11] ARM: dts: r8a7791: set maximum frequency for SDHI clocks
From: Simon Horman @ 2016-09-16 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-5-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:01PM +0200, Simon Horman wrote:
> Define the upper limit otherwise the driver cannot utilize max speeds.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
I have queued this up.
^ permalink raw reply
* [GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.9
From: Simon Horman @ 2016-09-16 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14474684.Hhngk1emgJ@wuerfel>
On Tue, Sep 13, 2016 at 05:35:25PM +0200, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 9:49:30 AM CEST Simon Horman wrote:
> > Second Round of Renesas ARM Based SoC DT Updates for v4.9
> >
> > Fixes (for v4.9):
> > * Correct PWM clock parent on r8a7794 SoC
> >
> > Clean-up:
> > * Remove obsolete vsp1 properties from r8a779[01] SoCs
> >
> > New boards:
> > * Add r8a7792/wheat and r7s72100/rskrza1 boards
> >
> > Enablement:
> > * Enable LEDs, DU, SDHI on r8a7792/blanche board
> > * Enable MMCIF and SDHI on r8a7794/alt board
> > * Add SPI and VSP1 to r8a7792 SoC
> > * Add ethernet to r7s72100 SoC
> >
>
> Pulled into next/dt, thanks!
Great, thanks for handling this and the other pull requests I sent last week.
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Laurent Pinchart @ 2016-09-16 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3152956.IVRykDnfF6@wuerfel>
Hi Arnd,
On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> > On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> >> On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S?derlund wrote:
> >>> Hi,
> >>>
> >>> This series tries to solve the problem with DMA with device registers
> >>> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> >>> recent patch '9575632 (dmaengine: make slave address physical)'
> >>> clarifies that DMA slave address provided by clients is the physical
> >>> address. This puts the task of mapping the DMA slave address from a
> >>> phys_addr_t to a dma_addr_t on the DMA engine.
> >>>
> >>> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> >>> the same and no special care is needed. However if you have a IOMMU
> >>> you need to map the DMA slave phys_addr_t to a dma_addr_t using
> >>> something like this.
> >>>
> >>> This series is based on top of v4.8-rc1. And I'm hoping to be able to
> >>> collect a Ack from Russell King on patch 4/6 that adds the ARM
> >>> specific part and then be able to take the whole series through the
> >>> dmaengine tree. If this is not the best route I'm more then happy to
> >>> do it another way.
> >>>
> >>> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> >>> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting
> >>> with /dev/mmcblk1, i2c and the serial console which are devices behind
> >>> the iommu.
> >>
> >> As I said in last one, the dmaengine parts look fine to me. But to go
> >> thru dmaengine tree I would need ACK on non dmaengine patches.
> >
> > I havent heard back from this one and I am inclined to merge this one now.
> > If anyone has any objects, please speak up now...
> >
> > Also ACKs welcome...
>
> I had not looked at the series earlier, but this version looks entirely
> reasonable to me, so
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
>
> One concern I have is that we might get an awkward situation if we ever
> encounter one DMA engine hardware that is used in different systems that all
> have an IOMMU, but on some of them the connection between the DMA master and
> the slave FIFO bypasses the IOMMU while on others the IOMMU is required.
Do you mean systems where some of the channels of a specific DMA engine go
through the IOMMU while others do not ? We indeed have no solution today for
such a situation.
The problem is a bit broader than that, we'll also have an issue with DMA
engines that have different channels served by different IOMMUs. I recall
discussing this in the past with you, and the solution you proposed was to add
a channel index to struct dma_attrs seems good to me. To support the case
where some channels don't go through an IOMMU we would only need support for
null entries in the IOMMUs list associated with a device (for instance in the
DT case null entries in the iommus property).
Now I see that struct dma_attrs has been replaced by unsigned long in
commit 00085f1efa387a8ce100e3734920f7639c80caa3
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Wed Aug 3 13:46:00 2016 -0700
dma-mapping: use unsigned long for dma_attrs
We still have enough bits to reserve some of them for a channel number, but
I'm not very happy with that patch as I can see how a future proposal to
handle the channel number through the DMA attributes will get rejected on the
grounds of bits starvation then :-(
> I don't have any idea for how this could be handled in a generic way, so my
> best answer here is to hope we never get there, and if we do, handle it
> using some local hack in the driver.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2] KVM: arm/arm64: Route vtimer events to user space
From: Christoffer Dall @ 2016-09-16 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474002553-30079-1-git-send-email-agraf@suse.de>
Alex,
On Fri, Sep 16, 2016 at 07:09:13AM +0200, Alexander Graf wrote:
> We have 2 modes for dealing with interrupts in the ARM world. We can either
> handle them all using hardware acceleration through the vgic or we can emulate
> a gic in user space and only drive CPU IRQ pins from there.
>
> Unfortunately, when driving IRQs from user space, we never tell user space
> about timer events that may result in interrupt line state changes, so we
> lose out on timer events if we run with user space gic emulation.
>
> This patch set fixes that by routing vtimer expiration events to user space.
> With this patch I can successfully run edk2 and Linux with user space gic
> emulation.
I have two versions of v2. Are there any differences or did it just go
out twice or got duplicated somehow on my end?
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH] dmaengine: mv_xor: Add support for scatter-gather DMA mode
From: Stefan Roese @ 2016-09-16 9:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds memory to memory scatter-gather support to the Marvell
mv_or DMA driver.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
---
drivers/dma/mv_xor.c | 183 +++++++++++++++++++++++++++++++++++++++++++++++++--
drivers/dma/mv_xor.h | 1 +
2 files changed, 180 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index ff4a094..d453aa6 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -68,6 +68,36 @@ static void mv_desc_init(struct mv_xor_desc_slot *desc,
hw_desc->byte_count = byte_count;
}
+/* Populate the descriptor */
+static void mv_xor_config_sg_ll_desc(struct mv_xor_desc_slot *desc,
+ dma_addr_t dma_src, dma_addr_t dma_dst,
+ u32 len, struct mv_xor_desc_slot *prev)
+{
+ struct mv_xor_desc *hw_desc = desc->hw_desc;
+
+ hw_desc->status = XOR_DESC_DMA_OWNED;
+ hw_desc->phy_next_desc = 0;
+ /* Configure for XOR with only one src address -> MEMCPY */
+ hw_desc->desc_command = XOR_DESC_OPERATION_XOR | (0x1 << 0);
+ hw_desc->phy_dest_addr = dma_dst;
+ hw_desc->phy_src_addr[0] = dma_src;
+ hw_desc->byte_count = len;
+
+ if (prev) {
+ struct mv_xor_desc *hw_prev = prev->hw_desc;
+
+ hw_prev->phy_next_desc = desc->async_tx.phys;
+ }
+}
+
+static void mv_xor_desc_config_eod(struct mv_xor_desc_slot *desc)
+{
+ struct mv_xor_desc *hw_desc = desc->hw_desc;
+
+ /* Enable end-of-descriptor interrupt */
+ hw_desc->desc_command |= XOR_DESC_EOD_INT_EN;
+}
+
static void mv_desc_set_mode(struct mv_xor_desc_slot *desc)
{
struct mv_xor_desc *hw_desc = desc->hw_desc;
@@ -231,8 +261,13 @@ mv_chan_clean_completed_slots(struct mv_xor_chan *mv_chan)
list_for_each_entry_safe(iter, _iter, &mv_chan->completed_slots,
node) {
- if (async_tx_test_ack(&iter->async_tx))
+ if (async_tx_test_ack(&iter->async_tx)) {
list_move_tail(&iter->node, &mv_chan->free_slots);
+ if (!list_empty(&iter->sg_tx_list)) {
+ list_splice_tail_init(&iter->sg_tx_list,
+ &mv_chan->free_slots);
+ }
+ }
}
return 0;
}
@@ -247,11 +282,20 @@ mv_desc_clean_slot(struct mv_xor_desc_slot *desc,
/* the client is allowed to attach dependent operations
* until 'ack' is set
*/
- if (!async_tx_test_ack(&desc->async_tx))
+ if (!async_tx_test_ack(&desc->async_tx)) {
/* move this slot to the completed_slots */
list_move_tail(&desc->node, &mv_chan->completed_slots);
- else
+ if (!list_empty(&desc->sg_tx_list)) {
+ list_splice_tail_init(&desc->sg_tx_list,
+ &mv_chan->completed_slots);
+ }
+ } else {
list_move_tail(&desc->node, &mv_chan->free_slots);
+ if (!list_empty(&desc->sg_tx_list)) {
+ list_splice_tail_init(&desc->sg_tx_list,
+ &mv_chan->free_slots);
+ }
+ }
return 0;
}
@@ -453,6 +497,7 @@ static int mv_xor_alloc_chan_resources(struct dma_chan *chan)
dma_async_tx_descriptor_init(&slot->async_tx, chan);
slot->async_tx.tx_submit = mv_xor_tx_submit;
INIT_LIST_HEAD(&slot->node);
+ INIT_LIST_HEAD(&slot->sg_tx_list);
dma_desc = mv_chan->dma_desc_pool;
slot->async_tx.phys = dma_desc + idx * MV_XOR_SLOT_SIZE;
slot->idx = idx++;
@@ -620,6 +665,132 @@ mv_xor_prep_dma_interrupt(struct dma_chan *chan, unsigned long flags)
return mv_xor_prep_dma_xor(chan, dest, &src, 1, len, flags);
}
+/**
+ * mv_xor_prep_dma_sg - prepare descriptors for a memory sg transaction
+ * @chan: DMA channel
+ * @dst_sg: Destination scatter list
+ * @dst_sg_len: Number of entries in destination scatter list
+ * @src_sg: Source scatter list
+ * @src_sg_len: Number of entries in source scatter list
+ * @flags: transfer ack flags
+ *
+ * Return: Async transaction descriptor on success and NULL on failure
+ */
+static struct dma_async_tx_descriptor *
+mv_xor_prep_dma_sg(struct dma_chan *chan, struct scatterlist *dst_sg,
+ unsigned int dst_sg_len, struct scatterlist *src_sg,
+ unsigned int src_sg_len, unsigned long flags)
+{
+ struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
+ struct mv_xor_desc_slot *new;
+ struct mv_xor_desc_slot *first = NULL;
+ struct mv_xor_desc_slot *prev = NULL;
+ size_t len, dst_avail, src_avail;
+ dma_addr_t dma_dst, dma_src;
+ int desc_cnt = 0;
+ int ret;
+
+ dev_dbg(mv_chan_to_devp(mv_chan),
+ "%s dst_sg_len: %d src_sg_len: %d flags: %ld\n",
+ __func__, dst_sg_len, src_sg_len, flags);
+
+ dst_avail = sg_dma_len(dst_sg);
+ src_avail = sg_dma_len(src_sg);
+
+ /* Run until we are out of scatterlist entries */
+ while (true) {
+ /* Allocate and populate the descriptor */
+ desc_cnt++;
+ new = mv_chan_alloc_slot(mv_chan);
+ if (!new) {
+ dev_err(mv_chan_to_devp(mv_chan),
+ "Out of descriptors (desc_cnt=%d)!\n",
+ desc_cnt);
+ goto err;
+ }
+
+ len = min_t(size_t, src_avail, dst_avail);
+ len = min_t(size_t, len, MV_XOR_MAX_BYTE_COUNT);
+ if (len == 0)
+ goto fetch;
+
+ if (len < MV_XOR_MIN_BYTE_COUNT) {
+ dev_err(mv_chan_to_devp(mv_chan),
+ "Transfer size of %d too small!\n", len);
+ goto err;
+ }
+
+ dma_dst = sg_dma_address(dst_sg) + sg_dma_len(dst_sg) -
+ dst_avail;
+ dma_src = sg_dma_address(src_sg) + sg_dma_len(src_sg) -
+ src_avail;
+
+ /* Check if a new window needs to get added for 'dst' */
+ ret = mv_xor_add_io_win(mv_chan, dma_dst);
+ if (ret)
+ goto err;
+
+ /* Check if a new window needs to get added for 'src' */
+ ret = mv_xor_add_io_win(mv_chan, dma_src);
+ if (ret)
+ goto err;
+
+ /* Populate the descriptor */
+ mv_xor_config_sg_ll_desc(new, dma_src, dma_dst, len, prev);
+ prev = new;
+ dst_avail -= len;
+ src_avail -= len;
+
+ if (!first)
+ first = new;
+ else
+ list_move_tail(&new->node, &first->sg_tx_list);
+
+fetch:
+ /* Fetch the next dst scatterlist entry */
+ if (dst_avail == 0) {
+ if (dst_sg_len == 0)
+ break;
+
+ /* Fetch the next entry: if there are no more: done */
+ dst_sg = sg_next(dst_sg);
+ if (dst_sg == NULL)
+ break;
+
+ dst_sg_len--;
+ dst_avail = sg_dma_len(dst_sg);
+ }
+
+ /* Fetch the next src scatterlist entry */
+ if (src_avail == 0) {
+ if (src_sg_len == 0)
+ break;
+
+ /* Fetch the next entry: if there are no more: done */
+ src_sg = sg_next(src_sg);
+ if (src_sg == NULL)
+ break;
+
+ src_sg_len--;
+ src_avail = sg_dma_len(src_sg);
+ }
+ }
+
+ /* Set the EOD flag in the last descriptor */
+ mv_xor_desc_config_eod(new);
+ first->async_tx.flags = flags;
+
+ return &first->async_tx;
+
+err:
+ /* Cleanup: Move all descriptors back into the free list */
+ spin_lock_bh(&mv_chan->lock);
+ mv_desc_clean_slot(first, mv_chan);
+ spin_unlock_bh(&mv_chan->lock);
+
+ return NULL;
+}
+
static void mv_xor_free_chan_resources(struct dma_chan *chan)
{
struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
@@ -1086,6 +1257,8 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
dma_dev->device_prep_dma_interrupt = mv_xor_prep_dma_interrupt;
if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask))
dma_dev->device_prep_dma_memcpy = mv_xor_prep_dma_memcpy;
+ if (dma_has_cap(DMA_SG, dma_dev->cap_mask))
+ dma_dev->device_prep_dma_sg = mv_xor_prep_dma_sg;
if (dma_has_cap(DMA_XOR, dma_dev->cap_mask)) {
dma_dev->max_xor = 8;
dma_dev->device_prep_dma_xor = mv_xor_prep_dma_xor;
@@ -1135,10 +1308,11 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
goto err_free_irq;
}
- dev_info(&pdev->dev, "Marvell XOR (%s): ( %s%s%s)\n",
+ dev_info(&pdev->dev, "Marvell XOR (%s): ( %s%s%s%s)\n",
mv_chan->op_in_desc ? "Descriptor Mode" : "Registers Mode",
dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
+ dma_has_cap(DMA_SG, dma_dev->cap_mask) ? "sg " : "",
dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");
dma_async_device_register(dma_dev);
@@ -1381,6 +1555,7 @@ static int mv_xor_probe(struct platform_device *pdev)
dma_cap_zero(cap_mask);
dma_cap_set(DMA_MEMCPY, cap_mask);
+ dma_cap_set(DMA_SG, cap_mask);
dma_cap_set(DMA_XOR, cap_mask);
dma_cap_set(DMA_INTERRUPT, cap_mask);
diff --git a/drivers/dma/mv_xor.h b/drivers/dma/mv_xor.h
index 88eeab2..cf921dd 100644
--- a/drivers/dma/mv_xor.h
+++ b/drivers/dma/mv_xor.h
@@ -148,6 +148,7 @@ struct mv_xor_chan {
*/
struct mv_xor_desc_slot {
struct list_head node;
+ struct list_head sg_tx_list;
enum dma_transaction_type type;
void *hw_desc;
u16 idx;
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: Kconfig: select GENERIC_CLOCKEVENTS_BROADCAST also on UP
From: Lucas Stach @ 2016-09-16 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1467993522-9176-1-git-send-email-l.stach@pengutronix.de>
Hi Russell,
can you please take a look at this and tell if there is something wrong
about it, or if you think it can go in?
Without this patch the kernel is unable to use the deeper CPU idle
states on i.MX6S if it isn't built with SMP support enabled.
Regards,
Lucas
Am Freitag, den 08.07.2016, 17:58 +0200 schrieb Lucas Stach:
> Quite a few systems have deeper idle states where the local timer tick
> stops to fire, that rely on the GENERIC_CLOCKEVENTS_BROADCAST
> infrastructure to switch to a global (non-stopping) clockevent device.
> This is also true on UP systems, so select GENERIC_CLOCKEVENTS_BROADCAST
> unconditionally.
>
> Instead only select ARCH_HAS_TICK_BROADCAST if SMP is present, as this
> is only implemented for SMP systems.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> arch/arm/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 90542db1220d..745843ea769c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -4,7 +4,7 @@ config ARM
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> - select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> + select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST && SMP
> select ARCH_HAVE_CUSTOM_GPIO_H
> select ARCH_HAS_GCOV_PROFILE_ALL
> select ARCH_MIGHT_HAVE_PC_PARPORT
> @@ -20,7 +20,7 @@ config ARM
> select EDAC_ATOMIC_SCRUB
> select GENERIC_ALLOCATOR
> select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
> - select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> + select GENERIC_CLOCKEVENTS_BROADCAST
> select GENERIC_EARLY_IOREMAP
> select GENERIC_IDLE_POLL_SETUP
> select GENERIC_IRQ_PROBE
^ permalink raw reply
* [PATCH v3 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Alexander Graf @ 2016-09-16 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA_SGmQVg0COoVArhVtC3TFEEMB3bdT-UTPYvnuwLKANYg@mail.gmail.com>
> On 16 Sep 2016, at 11:11, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On 16 September 2016 at 07:26, Alexander Graf <agraf@suse.de> wrote:
>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>> handle them all using hardware acceleration through the vgic or we can emulate
>> a gic in user space and only drive CPU IRQ pins from there.
>>
>> Unfortunately, when driving IRQs from user space, we never tell user space
>> about timer events that may result in interrupt line state changes, so we
>> lose out on timer events if we run with user space gic emulation.
>>
>> This patch fixes that by routing vtimer expiration events to user space.
>> With this patch I can successfully run edk2 and Linux with user space gic
>> emulation.
>
> Hi Alex. I have some comments just on the userspace API docs.
> These are mostly requests for clarification or expansion, and they
> boil down to "if you gave me this API document change I wouldn't be
> able to deduce from it the necessary changes to QEMU or kvmtool to
> use this functionality?.
Yeah, most of the documentation wouldn?t be enough to deduce the changes you need in user space applications, but I agree that that doesn?t mean we can?t improve going forward :).
>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>> index 23937e0..dec1a78 100644
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -3202,8 +3202,10 @@ struct kvm_run {
>> /* in */
>> __u8 request_interrupt_window;
>>
>> -Request that KVM_RUN return when it becomes possible to inject external
>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>> interrupts into the guest. Useful in conjunction with KVM_INTERRUPT.
>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>> +trigger forever. Useful with KVM_CAP_ARM_TIMER.
>
> It's only a _u8 and there's more than 8 IRQ lines -- which ones
> can you mask this way?
There are defines for the individual event lines you can mask. I?ll clarify.
>
>> __u8 padding1[7];
>>
>> @@ -3519,6 +3521,16 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>> event/message pages and to enable/disable SynIC messages/events processing
>> in userspace.
>>
>> + /* KVM_EXIT_ARM_TIMER */
>> + struct {
>> + __u8 timesource;
>> + } arm_timer;
>> +
>> +Indicates that a timer triggered that user space needs to handle and
>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>> +guest to proceed. This only happens for timers that got enabled through
>> +KVM_CAP_ARM_TIMER.
>
> What values can the timesource field contain?
There are defines for that again, I?ll clarify :).
>
>> +
>> /* Fix the size of the union. */
>> char padding[256];
>> };
>> @@ -3739,6 +3751,16 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>> accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>> the guest.
>>
>> +6.11 KVM_CAP_ARM_TIMER
>> +
>> +Architectures: arm, arm64
>> +Target: vcpu
>> +Parameters: args[0] contains a bitmap of timers to enable
>> +
>> +This capability allows to route per-core timers into user space. When it's
>> +enabled, the enabled timers trigger KVM_EXIT_ARM_TIMER guest exits when they
>> +are pending, unless masked by vcpu->run->request_interrupt_window.
>
> How are the timers enumerated within the bitmap? Which timers can
> be enabled like this?
See above ;).
> Shouldn't this be talking about "timers to route to userspace"
> rather than "timers to enable", since AIUI the timers are always
> enabled regardless of what you set here ?
The counter is enabled, but the timer isn?t, as you can never receive an event. But yes, I agree that the wording isn?t explicit enough. I?ll see if I can come up with something better.
> The KVM_CAP constant name seems rather generic given this is an
> obscure corner of the API.
It basically enables the KVM_EXIT_ARM_TIMER capability - and I didn?t want to make the name too long. Any suggestions?
> What is the mechanism for the kernel to tell userspace when the
> timer *stops* being pending, so it can update the interrupt
It can?t, because it doesn?t know :(. We can?t trap that event.
> level for it in userspace? (What you really want I think is
> for the kernel to notify "timer level goes high" and "timer
> level goes low" and handle the masking internally.)
That?s what I want, but it?s not what hardware gives me. All I can do is poll whether it?s still up - and that?s basically what this interface does.
Alex
^ permalink raw reply
* [PATCH] drm/rockchip: Respect page offset for PRIME mmap calls
From: Tomasz Figa @ 2016-09-16 9:17 UTC (permalink / raw)
To: linux-arm-kernel
From: ?rjan Eide <orjan.eide@arm.com>
When mapping external DMA-bufs through the PRIME mmap call, we might be
given an offset which has to be respected. However for the internal DRM
GEM mmap path, we have to ignore the fake mmap offset used to identify
the buffer only. Currently the code always zeroes out vma->vm_pgoff,
which breaks the former.
This patch fixes the problem by moving the vm_pgoff assignment to a
function that is used only for GEM mmap path, so that the PRIME path
retains the original offset.
Fixes: a8594f2 ("drm/rockchip: unset pgoff when mmap'ing gems")
Signed-off-by: ?rjan Eide <orjan.eide@arm.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index b70f942..cab4d60 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -64,7 +64,6 @@ static int rockchip_drm_gem_object_mmap(struct drm_gem_object *obj,
* VM_PFNMAP flag that was set by drm_gem_mmap_obj()/drm_gem_mmap().
*/
vma->vm_flags &= ~VM_PFNMAP;
- vma->vm_pgoff = 0;
ret = dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
obj->size, rk_obj->dma_attrs);
@@ -96,6 +95,12 @@ int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma)
if (ret)
return ret;
+ /*
+ * Set vm_pgoff (used as a fake buffer offset by DRM) to 0 and map the
+ * whole buffer from the start.
+ */
+ vma->vm_pgoff = 0;
+
obj = vma->vm_private_data;
return rockchip_drm_gem_object_mmap(obj, vma);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 2/2] clk: imx6: initialize GPU clocks
From: Lucas Stach @ 2016-09-16 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474017371-28966-1-git-send-email-l.stach@pengutronix.de>
Initialize the GPU clock muxes to sane inputs. Until now they have
not been changed from their default values, which means that both
GPU3D shader and GPU2D core were fed by clock inputs whose rates
exceed the maximium allowed frequency of the cores by as much as
200MHz.
This fixes a severe GPU stability issue on i.MX6DL.
Cc: stable at vger.kernel.org
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/clk/imx/clk-imx6q.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index 64c243173395..751c3e7d5843 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -633,6 +633,24 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
if (IS_ENABLED(CONFIG_PCI_IMX6))
clk_set_parent(clk[IMX6QDL_CLK_LVDS1_SEL], clk[IMX6QDL_CLK_SATA_REF_100M]);
+ /*
+ * Initialize the GPU clock muxes, so that the maximum specified clock
+ * rates for the respective SoC are not exceeded.
+ */
+ if (clk_on_imx6dl()) {
+ clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
+ clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
+ clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
+ clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
+ } else if (clk_on_imx6q()) {
+ clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
+ clk[IMX6QDL_CLK_MMDC_CH0_AXI]);
+ clk_set_parent(clk[IMX6QDL_CLK_GPU3D_SHADER_SEL],
+ clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
+ clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
+ clk[IMX6QDL_CLK_PLL3_USB_OTG]);
+ }
+
imx_register_uart_clocks(uart_clks);
}
CLK_OF_DECLARE(imx6q, "fsl,imx6q-ccm", imx6q_clocks_init);
--
2.8.1
^ permalink raw reply related
* [PATCH 1/2] clk: imx6: fix i.MX6DL clock tree to reflect reality
From: Lucas Stach @ 2016-09-16 9:16 UTC (permalink / raw)
To: linux-arm-kernel
The current clock tree only implements the minimal set of differences
between the i.MX6Q and the i.MX6DL, but that doesn't really reflect
reality.
Apply the following fixes to match the RM:
- DL has no GPU3D_SHADER_SEL/PODF, the shader domain is clocked by
GPU3D_CORE
- GPU3D_SHADER_SEL/PODF has been repurposed as GPU2D_CORE_SEL/PODF
- GPU2D_CORE_SEL/PODF has been repurposed as MLB_SEL/PODF
Cc: stable at vger.kernel.org
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/clk/imx/clk-imx6q.c | 28 ++++++++++++++++------------
include/dt-bindings/clock/imx6qdl-clock.h | 4 +++-
2 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index ba1c1ae72ac2..64c243173395 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -318,11 +318,16 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk[IMX6QDL_CLK_IPG_PER_SEL] = imx_clk_mux("ipg_per_sel", base + 0x1c, 6, 1, ipg_per_sels, ARRAY_SIZE(ipg_per_sels));
clk[IMX6QDL_CLK_UART_SEL] = imx_clk_mux("uart_sel", base + 0x24, 6, 1, uart_sels, ARRAY_SIZE(uart_sels));
clk[IMX6QDL_CLK_GPU2D_CORE_SEL] = imx_clk_mux("gpu2d_core_sel", base + 0x18, 16, 2, gpu2d_core_sels_2, ARRAY_SIZE(gpu2d_core_sels_2));
+ } else if (clk_on_imx6dl()) {
+ clk[IMX6QDL_CLK_MLB_SEL] = imx_clk_mux("mlb_sel", base + 0x18, 16, 2, gpu2d_core_sels, ARRAY_SIZE(gpu2d_core_sels));
} else {
clk[IMX6QDL_CLK_GPU2D_CORE_SEL] = imx_clk_mux("gpu2d_core_sel", base + 0x18, 16, 2, gpu2d_core_sels, ARRAY_SIZE(gpu2d_core_sels));
}
clk[IMX6QDL_CLK_GPU3D_CORE_SEL] = imx_clk_mux("gpu3d_core_sel", base + 0x18, 4, 2, gpu3d_core_sels, ARRAY_SIZE(gpu3d_core_sels));
- clk[IMX6QDL_CLK_GPU3D_SHADER_SEL] = imx_clk_mux("gpu3d_shader_sel", base + 0x18, 8, 2, gpu3d_shader_sels, ARRAY_SIZE(gpu3d_shader_sels));
+ if (clk_on_imx6dl())
+ clk[IMX6QDL_CLK_GPU2D_CORE_SEL] = imx_clk_mux("gpu2d_core_sel", base + 0x18, 8, 2, gpu3d_shader_sels, ARRAY_SIZE(gpu3d_shader_sels));
+ else
+ clk[IMX6QDL_CLK_GPU3D_SHADER_SEL] = imx_clk_mux("gpu3d_shader_sel", base + 0x18, 8, 2, gpu3d_shader_sels, ARRAY_SIZE(gpu3d_shader_sels));
clk[IMX6QDL_CLK_IPU1_SEL] = imx_clk_mux("ipu1_sel", base + 0x3c, 9, 2, ipu_sels, ARRAY_SIZE(ipu_sels));
clk[IMX6QDL_CLK_IPU2_SEL] = imx_clk_mux("ipu2_sel", base + 0x3c, 14, 2, ipu_sels, ARRAY_SIZE(ipu_sels));
clk[IMX6QDL_CLK_LDB_DI0_SEL] = imx_clk_mux_flags("ldb_di0_sel", base + 0x2c, 9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
@@ -400,9 +405,15 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk[IMX6QDL_CLK_LDB_DI0_DIV_3_5] = imx_clk_fixed_factor("ldb_di0_div_3_5", "ldb_di0_sel", 2, 7);
clk[IMX6QDL_CLK_LDB_DI1_DIV_3_5] = imx_clk_fixed_factor("ldb_di1_div_3_5", "ldb_di1_sel", 2, 7);
}
- clk[IMX6QDL_CLK_GPU2D_CORE_PODF] = imx_clk_divider("gpu2d_core_podf", "gpu2d_core_sel", base + 0x18, 23, 3);
+ if (clk_on_imx6dl())
+ clk[IMX6QDL_CLK_MLB_PODF] = imx_clk_divider("mlb_podf", "mlb_sel", base + 0x18, 23, 3);
+ else
+ clk[IMX6QDL_CLK_GPU2D_CORE_PODF] = imx_clk_divider("gpu2d_core_podf", "gpu2d_core_sel", base + 0x18, 23, 3);
clk[IMX6QDL_CLK_GPU3D_CORE_PODF] = imx_clk_divider("gpu3d_core_podf", "gpu3d_core_sel", base + 0x18, 26, 3);
- clk[IMX6QDL_CLK_GPU3D_SHADER] = imx_clk_divider("gpu3d_shader", "gpu3d_shader_sel", base + 0x18, 29, 3);
+ if (clk_on_imx6dl())
+ clk[IMX6QDL_CLK_GPU2D_CORE_PODF] = imx_clk_divider("gpu2d_core_podf", "gpu2d_core_sel", base + 0x18, 29, 3);
+ else
+ clk[IMX6QDL_CLK_GPU3D_SHADER] = imx_clk_divider("gpu3d_shader", "gpu3d_shader_sel", base + 0x18, 29, 3);
clk[IMX6QDL_CLK_IPU1_PODF] = imx_clk_divider("ipu1_podf", "ipu1_sel", base + 0x3c, 11, 3);
clk[IMX6QDL_CLK_IPU2_PODF] = imx_clk_divider("ipu2_podf", "ipu2_sel", base + 0x3c, 16, 3);
clk[IMX6QDL_CLK_LDB_DI0_PODF] = imx_clk_divider_flags("ldb_di0_podf", "ldb_di0_div_3_5", base + 0x20, 10, 1, 0);
@@ -473,14 +484,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk[IMX6QDL_CLK_ESAI_MEM] = imx_clk_gate2_shared("esai_mem", "ahb", base + 0x6c, 16, &share_count_esai);
clk[IMX6QDL_CLK_GPT_IPG] = imx_clk_gate2("gpt_ipg", "ipg", base + 0x6c, 20);
clk[IMX6QDL_CLK_GPT_IPG_PER] = imx_clk_gate2("gpt_ipg_per", "ipg_per", base + 0x6c, 22);
- if (clk_on_imx6dl())
- /*
- * The multiplexer and divider of imx6q clock gpu3d_shader get
- * redefined/reused as gpu2d_core_sel and gpu2d_core_podf on imx6dl.
- */
- clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core", "gpu3d_shader", base + 0x6c, 24);
- else
- clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core", "gpu2d_core_podf", base + 0x6c, 24);
+ clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core", "gpu2d_core_podf", base + 0x6c, 24);
clk[IMX6QDL_CLK_GPU3D_CORE] = imx_clk_gate2("gpu3d_core", "gpu3d_core_podf", base + 0x6c, 26);
clk[IMX6QDL_CLK_HDMI_IAHB] = imx_clk_gate2("hdmi_iahb", "ahb", base + 0x70, 0);
clk[IMX6QDL_CLK_HDMI_ISFR] = imx_clk_gate2("hdmi_isfr", "video_27m", base + 0x70, 4);
@@ -511,7 +515,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
* The multiplexer and divider of the imx6q clock gpu2d get
* redefined/reused as mlb_sys_sel and mlb_sys_clk_podf on imx6dl.
*/
- clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb", "gpu2d_core_podf", base + 0x74, 18);
+ clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb", "mlb_podf", base + 0x74, 18);
else
clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb", "axi", base + 0x74, 18);
clk[IMX6QDL_CLK_MMDC_CH0_AXI] = imx_clk_gate2("mmdc_ch0_axi", "mmdc_ch0_axi_podf", base + 0x74, 20);
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h b/include/dt-bindings/clock/imx6qdl-clock.h
index 29050337d9d5..da59fd9cdb5e 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -269,6 +269,8 @@
#define IMX6QDL_CLK_PRG0_APB 256
#define IMX6QDL_CLK_PRG1_APB 257
#define IMX6QDL_CLK_PRE_AXI 258
-#define IMX6QDL_CLK_END 259
+#define IMX6QDL_CLK_MLB_SEL 259
+#define IMX6QDL_CLK_MLB_PODF 260
+#define IMX6QDL_CLK_END 261
#endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
--
2.8.1
^ permalink raw reply related
* [PATCH v3 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Peter Maydell @ 2016-09-16 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474007187-18673-3-git-send-email-agraf@suse.de>
On 16 September 2016 at 07:26, Alexander Graf <agraf@suse.de> wrote:
> We have 2 modes for dealing with interrupts in the ARM world. We can either
> handle them all using hardware acceleration through the vgic or we can emulate
> a gic in user space and only drive CPU IRQ pins from there.
>
> Unfortunately, when driving IRQs from user space, we never tell user space
> about timer events that may result in interrupt line state changes, so we
> lose out on timer events if we run with user space gic emulation.
>
> This patch fixes that by routing vtimer expiration events to user space.
> With this patch I can successfully run edk2 and Linux with user space gic
> emulation.
Hi Alex. I have some comments just on the userspace API docs.
These are mostly requests for clarification or expansion, and they
boil down to "if you gave me this API document change I wouldn't be
able to deduce from it the necessary changes to QEMU or kvmtool to
use this functionality".
> Signed-off-by: Alexander Graf <agraf@suse.de>
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 23937e0..dec1a78 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -3202,8 +3202,10 @@ struct kvm_run {
> /* in */
> __u8 request_interrupt_window;
>
> -Request that KVM_RUN return when it becomes possible to inject external
> +[x86] Request that KVM_RUN return when it becomes possible to inject external
> interrupts into the guest. Useful in conjunction with KVM_INTERRUPT.
> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
> +trigger forever. Useful with KVM_CAP_ARM_TIMER.
It's only a _u8 and there's more than 8 IRQ lines -- which ones
can you mask this way?
> __u8 padding1[7];
>
> @@ -3519,6 +3521,16 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
> event/message pages and to enable/disable SynIC messages/events processing
> in userspace.
>
> + /* KVM_EXIT_ARM_TIMER */
> + struct {
> + __u8 timesource;
> + } arm_timer;
> +
> +Indicates that a timer triggered that user space needs to handle and
> +potentially mask with vcpu->run->request_interrupt_window to allow the
> +guest to proceed. This only happens for timers that got enabled through
> +KVM_CAP_ARM_TIMER.
What values can the timesource field contain?
> +
> /* Fix the size of the union. */
> char padding[256];
> };
> @@ -3739,6 +3751,16 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
> accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
> the guest.
>
> +6.11 KVM_CAP_ARM_TIMER
> +
> +Architectures: arm, arm64
> +Target: vcpu
> +Parameters: args[0] contains a bitmap of timers to enable
> +
> +This capability allows to route per-core timers into user space. When it's
> +enabled, the enabled timers trigger KVM_EXIT_ARM_TIMER guest exits when they
> +are pending, unless masked by vcpu->run->request_interrupt_window.
How are the timers enumerated within the bitmap? Which timers can
be enabled like this?
Shouldn't this be talking about "timers to route to userspace"
rather than "timers to enable", since AIUI the timers are always
enabled regardless of what you set here ?
The KVM_CAP constant name seems rather generic given this is an
obscure corner of the API.
What is the mechanism for the kernel to tell userspace when the
timer *stops* being pending, so it can update the interrupt
level for it in userspace? (What you really want I think is
for the kernel to notify "timer level goes high" and "timer
level goes low" and handle the masking internally.)
> +
> 7. Capabilities that can be enabled on VMs
> ------------------------------------------
thanks
-- PMM
^ permalink raw reply
* v4.8-rc: GSM audio causes trouble
From: Pavel Machek @ 2016-09-16 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916055249.h7zw6hguvwwe2zwu@earth>
On Fri 2016-09-16 07:52:50, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Sep 15, 2016 at 10:51:42PM +0200, Pavel Machek wrote:
> > > I was trying to improve GSM call quality, and hit problems in
> > > v4.8-rc. Sound only worked for a while, then I tried to kill
> > > cmtspeech_ofono_test, and could not, not even with -9 and could not
> > > even reboot.
> > >
> > > I went back to v4.1 (ok, quite far, I see), and problems are gone.
> > >
> > > Does it work for you? Any ideas what to try... besides bisect?
> >
> > v4.7 is okay.
> >
> > v4.8 with
> >
> > git diff ..mini-v4.7 drivers/hsi/ | git apply
> >
> > Seems to work ok.
Hmm. I guess I made some error with the testing, because reverting
just drivers/hsi to v4.7 state results in non-compiling kernel
> hsi changes from 4.7 to 4.8 are basically runtime PM enablement.
> Does 4.8 work for you with just 9c99e5e51988 reverted?
No, according to the notes. But see above... and let me retry with
drivers/hsi _and_ include/linux/hsi reverted. No GSM audio and same
problem with shutdown. Oops. Sorry about the confusion.
Does it work for you? Any ideas what could be wrong?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Arnd Bergmann @ 2016-09-16 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915162650.GZ13920@localhost>
On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> > On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S?derlund wrote:
> > > Hi,
> > >
> > > This series tries to solve the problem with DMA with device registers
> > > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> > > recent patch '9575632 (dmaengine: make slave address physical)'
> > > clarifies that DMA slave address provided by clients is the physical
> > > address. This puts the task of mapping the DMA slave address from a
> > > phys_addr_t to a dma_addr_t on the DMA engine.
> > >
> > > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> > > the same and no special care is needed. However if you have a IOMMU you
> > > need to map the DMA slave phys_addr_t to a dma_addr_t using something
> > > like this.
> > >
> > > This series is based on top of v4.8-rc1. And I'm hoping to be able to collect a
> > > Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> > > able to take the whole series through the dmaengine tree. If this is not the
> > > best route I'm more then happy to do it another way.
> > >
> > > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> > > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> > > /dev/mmcblk1, i2c and the serial console which are devices behind the
> > > iommu.
> >
> > As I said in last one, the dmaengine parts look fine to me. But to go thru
> > dmaengine tree I would need ACK on non dmaengine patches.
>
> I havent heard back from this one and I am inclined to merge this one now.
> If anyone has any objects, please speak up now...
>
> Also ACKs welcome...
>
I had not looked at the series earlier, but this version looks entirely
reasonable to me, so
Acked-by: Arnd Bergmann <arnd@arndb.de>
One concern I have is that we might get an awkward situation if we
ever encounter one DMA engine hardware that is used in different
systems that all have an IOMMU, but on some of them the connection
between the DMA master and the slave FIFO bypasses the IOMMU
while on others the IOMMU is required. I don't have any idea for
how this could be handled in a generic way, so my best answer
here is to hope we never get there, and if we do, handle it
using some local hack in the driver.
Arnd
^ permalink raw reply
* [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks
From: Gabriele Paoloni @ 2016-09-16 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915105849.GA10345@red-moon>
Hi Lorenzo and Tomasz
Many Thanks for looking at this
> -----Original Message-----
> From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi at arm.com]
> Sent: 15 September 2016 11:59
> To: liudongdong (C)
> Cc: Tomasz Nowicki; helgaas at kernel.org; will.deacon at arm.com;
> catalin.marinas at arm.com; rafael at kernel.org; arnd at arndb.de;
> hanjun.guo at linaro.org; okaya at codeaurora.org; jchandra at broadcom.com;
> cov at codeaurora.org; dhdang at apm.com; ard.biesheuvel at linaro.org;
> robert.richter at caviumnetworks.com; mw at semihalf.com;
> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing;
> msalter at redhat.com; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linaro-acpi at lists.linaro.org;
> jcm at redhat.com; andrea.gallo at linaro.org; jeremy.linton at arm.com;
> Gabriele Paoloni; jhugo at codeaurora.org; linux-acpi at vger.kernel.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM
> quirks
>
> On Tue, Sep 13, 2016 at 07:38:39PM +0800, Dongdong Liu wrote:
>
> [...]
>
> > Our host bridge is non ECAM only for the RC bus config space;
> > for any other bus underneath the root bus we support ECAM access.
> >
> > RC config resource with hardcode as DEFINE_RES_MEM(0xb0070000,
> SZ_4K),
> > EP config resource we get it from MCFG table.
> > So we need to override ops, but config resource we only need to
> hardcode with RC config resource.
> >
> > Our host controller ACPI support patch can be found:
> > https://lkml.org/lkml/2016/8/31/340
>
> Sorry I misread your code. IIUC you create an array of resources that
> represent non-ECAM config space (and incidentally contain debug
> registers to check the link status - that you need to check for every
> given config access (?)), but you still need to have an MCFG entry that
The link status check is inherited from the designware framework (see
http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L678)
However I think that in this case we can just check the link status
in our init function and return an error if the link is down
> covers the bus number subject to quirk to make sure this mechanism
> works. Correct ?
Well we need the quirks for the root bus numbers but if read this v6
quirk mechanism correctly even if we do not specify an mcfg entry for
bus 0 oci_mcfg_match_quirks() is called anyway and we can set our
special configuration space addresses for the root buses (i.e. I think
we can have a clean MCFG table with entries only for those bus ranges
that are really ECAM)
>
> This also means that, with the MCFG tables you have and current
> mainline kernel you are able to probe a root bridge (because the MCFG
> table covers the bus number that is not ECAM), with enumeration
> going haywire because it is trying to carry out ECAM accesses on
> non-ECAM space.
Yes correct, we cannot access the host controller configuration space
with our current MCFG table and current Linux mainline
>
> Is my reading correct ?
>
> Anyway, that's not stricly related to this discussion, it is time we
> converge on this patchset, we can add a domain range if that
> simplifies things.
IMO it would be better to have the domain range to avoid
a very large and repetitive static quirk array
Thanks
Gab
>
> Thanks,
> Lorenzo
>
> > This patch is based on RFC V5 quirk mechanism.
> >
> > Based on V6 quirk mechanism, we have to change it as below:
> >
> > #ifdef CONFIG_PCI_HISI_ACPI
> > { "HISI ", "HIP05 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP05 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP05 ", 0, 2, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP05 ", 0, 3, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 2, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 3, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP07 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP07 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > MCFG_RES_EMPTY},
> > ....
> >
> > { "HISI ", "HIP07 ", 0, 15, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > MCFG_RES_EMPTY},
> >
> > #endif
> >
> > struct pci_ecam_ops hisi_pci_hip05_ops = {
> > .bus_shift = 20,
> > .init = hisi_pci_hip05_init,
> > .pci_ops = {
> > .map_bus = pci_ecam_map_bus,
> > .read = hisi_pcie_acpi_rd_conf,
> > .write = hisi_pcie_acpi_wr_conf,
> > }
> > };
> >
> > struct pci_ecam_ops hisi_pci_hip06_ops = {
> > .bus_shift = 20,
> > .init = hisi_pci_hip06_init,
> > .pci_ops = {
> > .map_bus = pci_ecam_map_bus,
> > .read = hisi_pcie_acpi_rd_conf,
> > .write = hisi_pcie_acpi_wr_conf,
> > }
> > };
> >
> > hisi_pci_hipxx_init function is used to get RC config resource with
> hardcode.
> > .....
> >
> > So I hope we can use MCFG_DOM_RANGE, Then I can change it as below.
> >
> > #ifdef CONFIG_PCI_HISI_ACPI
> > { "HISI ", "HIP05 ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
> > &hisi_pcie_hip05_ops, MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
> > &hisi_pcie_hip06_ops, MCFG_RES_EMPTY},
> > { "HISI ", "HIP07 ", 0, MCFG_DOM_RANGE(0, 15), MCFG_BUS_ANY,
> > &hisi_pcie_hip07_ops, MCFG_RES_EMPTY},
> > #endif
> >
> > Thanks
> > Dongdong
> > >
> > >Thanks,
> > >Tomasz
> > >
> > >.
> > >
> >
^ 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