* [PATCH 1/3] ls1043ardb: add qe node to ls1043ardb
From: Zhao Qiang @ 2016-09-28 3:40 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++++++
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 66 +++++++++++++++++++++++
2 files changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index 4084631..4fc60e7 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -124,6 +124,22 @@
};
};
+&uqe {
+ ucc_hdlc: ucc at 2000 {
+ compatible = "fsl,ls1043-ucc-hdlc", "fsl,ucc-hdlc";
+ rx-clock-name = "clk8";
+ tx-clock-name = "clk9";
+ fsl,rx-sync-clock = "rsync_pin";
+ fsl,tx-sync-clock = "tsync_pin";
+ fsl,tx-timeslot-mask = <0xfffffffe>;
+ fsl,rx-timeslot-mask = <0xfffffffe>;
+ fsl,tdm-framer-type = "e1";
+ fsl,tdm-id = <0>;
+ fsl,siram-entry-id = <0>;
+ fsl,tdm-interface;
+ };
+};
+
&duart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..f6b6775 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -388,6 +388,72 @@
#interrupt-cells = <2>;
};
+ uqe: uqe at 2400000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "qe";
+ compatible = "fsl,qe", "simple-bus";
+ ranges = <0x0 0x0 0x2400000 0x40000>;
+ reg = <0x0 0x2400000 0x0 0x480>;
+ brg-frequency = <100000000>;
+ bus-frequency = <200000000>;
+
+ fsl,qe-num-riscs = <1>;
+ fsl,qe-num-snums = <28>;
+
+ qeic: qeic at 80 {
+ compatible = "fsl,qe-ic";
+ reg = <0x80 0x80>;
+ #address-cells = <0>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = <0 77 0x04 0 77 0x04>;
+ };
+
+ si1: si at 700 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,ls1043-qe-si",
+ "fsl,t1040-qe-si";
+ reg = <0x700 0x80>;
+ };
+
+ siram1: siram at 1000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ls1043-qe-siram",
+ "fsl,t1040-qe-siram";
+ reg = <0x1000 0x800>;
+ };
+
+ ucc at 2000 {
+ cell-index = <1>;
+ reg = <0x2000 0x200>;
+ interrupts = <32>;
+ interrupt-parent = <&qeic>;
+ };
+
+ ucc at 2200 {
+ cell-index = <3>;
+ reg = <0x2200 0x200>;
+ interrupts = <34>;
+ interrupt-parent = <&qeic>;
+ };
+
+ muram at 10000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,qe-muram", "fsl,cpm-muram";
+ ranges = <0x0 0x10000 0x6000>;
+
+ data-only at 0 {
+ compatible = "fsl,qe-muram-data",
+ "fsl,cpm-muram-data";
+ reg = <0x0 0x6000>;
+ };
+ };
+ };
+
lpuart0: serial at 2950000 {
compatible = "fsl,ls1021a-lpuart";
reg = <0x0 0x2950000 0x0 0x1000>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* ARM juno R2 board USB Issue (EHCI probe failed)
From: Sajjan, Vikas C @ 2016-09-28 3:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9b231601-2c6a-a5d7-471f-4fc0d8190d83@arm.com>
Hi All,
-----Original Message-----
From: Robin Murphy [mailto:robin.murphy at arm.com]
Sent: Tuesday, September 27, 2016 9:53 PM
To: Hanjun Guo <hanjun.guo@linaro.org>; Sudeep Holla <sudeep.holla@arm.com>; Sajjan, Vikas C <vikas.cha.sajjan@hpe.com>; Vikas Sajjan <sajjan.linux@gmail.com>; linux-usb at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org
Cc: mark.rutland at arm.com; lorenzo.pieralisi at arm.com
Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)
On 27/09/16 17:13, Hanjun Guo wrote:
> On 09/27/2016 05:07 PM, Sudeep Holla wrote:
>>
>>
>> On 27/09/16 09:55, Sajjan, Vikas C wrote:
>>> Hi Sudeep,
>>>
>>> -----Original Message-----
>>> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
>>> Sent: Tuesday, September 27, 2016 2:21 PM
>>> To: Vikas Sajjan <sajjan.linux@gmail.com>;
>>> linux-usb at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>>> linux-acpi at vger.kernel.org
>>> Cc: Sudeep Holla <sudeep.holla@arm.com>; mark.rutland at arm.com;
>>> lorenzo.pieralisi at arm.com; Sajjan, Vikas C
>>> <vikas.cha.sajjan@hpe.com>
>>> Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)
>>>
>>> Hi Vikas,
>>>
>>> On 27/09/16 09:14, Vikas Sajjan wrote:
>>>> Adding USB mailing list.
>>>>
>>>>
>>>> On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C
>>>> <vikas.cha.sajjan@hpe.com> wrote:
>>>>> Hi All,
>>>>>
>>>>> I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I
>>>>> get below USB EHCI probe error while booting with acpi=force.
>>>>>
>>>
>>> Are you using the latest UEFI EDK2 ?
>>> No, I am still using the UEFI binary which came as part of the Juno
>>> board.
>>>
>>>
>>>>> [ 1.223662] VFIO - User Level meta-driver version: 0.3
>>>>> [ 1.229335] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
>>>>> Driver
>>>>> [ 1.235882] ehci-pci: EHCI PCI platform driver
>>>>> [ 1.240359] ehci-platform: EHCI generic platform driver
>>>>> [ 1.245619] ehci-platform ARMH0D20:00: Error: DMA mask
>>>>> configuration failed
>>>>> [ 1.272491] ehci-platform: probe of ARMH0D20:00 failed with
>>>>> error -5
>>>>> [ 1.278876] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>>>>> [ 1.285071] ohci-pci: OHCI PCI platform driver
>>>>> [ 1.289548] ohci-platform: OHCI generic platform driver
>>>>> [ 1.294884] usbcore: registered new interface driver usb-storage
>>>>> [ 1.301231] mousedev: PS/2 mouse device common for all mice
>>>>> [ 1.307197] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>>>>>
>>>>> But this error goes off, if I don't force ACPI booting, i.e., if I
>>>>> remove acpi=force from kernel command line , USB is detected and
>>>>> my RFS which is in the usb drive, gets mounted successfully.
>>>>>
>>>
>>> As I mentioned in private, I do get the same error if I drop _CCA in
>>> USB object of ACPI DSDT. Can you give it a spin with latest UEFI ?
>>>
>>> Sure, will try with latest UEFI.
>>>
>>
>> I bet that's 8-12 months old. It puts the banner during boot with the
>> build date. You can try to follow [1] or access it from [2]
>
> Agree.
>
> D03 is using the same IP (EHCI) and the USB works fine with _CCA in
> the device node.
_CCA is mandatory on arm64 (see CONFIG_ACPI_CCA_REQUIRED). Any devices without it are going to end up with the dummy DMA ops which intentionally fail if a driver tries to use them - i.e. the error seen above is by design.
Thank you for the clarification.
Thanks and Regards
Vikas Sajjan
Robin.
>
> Thanks
> Hanjun
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
From: Vinod Koul @ 2016-09-28 3:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote:
> Hi,
>
> Changes since v2:
> - Instead of converting to use enum for the of_device_id data parameter the two
> patch for edma and ti-dma-crossbar is using pointers to u32 variables to make
> sure that the code compile (and in theory work) on all architectures.
> - fixed issue in the ti-dma-crossbar driver I have made with the enum change to
> not handle the DMA offset parameters correctly.
>
> Changes since v1:
> - added the compiler warning message to ti-dma-crossbar enum type patch
> - moved the Kconfig patches at the end of the seris
>
> The following series will enable unconditional COMPILE_TEST coverage for the
> following drivers: omap-dma, edma and ti-dma-crossbar
>
> The series includes fixes noticed when compiling the drivers for x86_64 and
> aarch64.
I have applied the series after fixing code style nit-picks.
Also applied the edma patch and reordered the series to have that come
before compile test enable patch
Please verify.
Thanks
--
~Vinod
^ permalink raw reply
* [PATCH v3 6/9] dmaengine: ti-dma-crossbar: Fix of_device_id data parameter usage
From: Vinod Koul @ 2016-09-28 3:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-7-peter.ujfalusi@ti.com>
On Wed, Sep 21, 2016 at 03:41:32PM +0300, Peter Ujfalusi wrote:
> @@ -395,7 +403,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
>
> xbar->dmarouter.dev = &pdev->dev;
> xbar->dmarouter.route_free = ti_dra7_xbar_free;
> - xbar->dma_offset = (u32)match->data;
> + xbar->dma_offset = *(u32*)match->data;
^^^^
we need space between u32 and *
> mutex_init(&xbar->mutex);
> platform_set_drvdata(pdev, xbar);
> @@ -428,7 +436,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
> if (unlikely(!match))
> return -EINVAL;
>
> - switch ((u32)match->data) {
> + switch (*(u32*)match->data) {
here too please
--
~Vinod
^ permalink raw reply
* [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Brian Norris @ 2016-09-28 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E0E97B.5000106@arm.com>
Hi Marc,
Thanks again for the help. I was checking with Rockchip on the details.
On Tue, Sep 20, 2016 at 08:47:07AM +0100, Marc Zyngier wrote:
> The counter is allowed to be clocked at a different rate, as long as it
> is incremented by the frequency ratio on each tick of the new frequency.
> In your case, the counter should increment by 750 on each tick of the
> 32kHz clock. If the rk3399 implementation doesn't do this, then this is
> a bug, and we need a quirk to work around it.
I had hope that we could find a switch that would do the above for
rk3399, since other parts of the system (e.g., the PMU itself) support
switching from the 24MHz to 32KHz clock, but Rockchip confirmed that it
is indeed a HW quirk that the arch timer's counter does not support
clocking out ticks based on the 32KHz clock. So I'm planning to send a
v2 that adds a "arm,no-tick-in-suspend" property.
<Begin side note>
rk3288 (ARMv7 system widely used for our Chromebooks) has the same
issue, except the kernel we're using for production (based on v3.14)
doesn't have the following commit, which stopped utilizing the RTC:
commit 0fa88cb4b82b5cf7429bc1cef9db006ca035754e
Author: Xunlei Pang <pang.xunlei@linaro.org>
Date: Wed Apr 1 20:34:38 2015 -0700
time, drivers/rtc: Don't bother with rtc_resume() for the nonstop clocksource
And any mainline testing on rk3288 doesn't see the problem, because
mainline doesn't support its lowest-power sleep modes well enough (see
ROCKCHIP_ARM_OFF_LOGIC_DEEP in arch/arm/mach-rockchip/pm.c).
<End side note>
> Note that such a quirk will have some other impacts, such as the
> gettimeofday implementation in the VDSO (which relies on the counter
> making forward progress). There could be other issues in the timer
> subsystem as well... This doesn't look like a pleasant thing to fix.
How sure are you of these problems? I'm a bit new to the kernel
timekeeping subsystem, but doesn't this kind of code already have to
handle time adjustments like this when reprogramming the system time
(settimeofday())? And might we be covered for the suspend/resume case
when we allow the kernel to fall back to the RTC instead, which adjusts
the sleep delta with timekeeping_inject_sleeptime64()? And (weaker
evidence here) we haven't seen problems on rk3288 so far, at least
without the above referenced rtc commit 0fa88cb4b82. But admittedly
there are some differences between arch/{arm,arm64}/.
Regards,
Brian
^ permalink raw reply
* [PATCH v7 0/8] power: add power sequence library
From: Peter Chen @ 2016-09-27 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57EB0109.4070000@maciej.szmigiero.name>
On Wed, Sep 28, 2016 at 01:30:17AM +0200, Maciej S. Szmigiero wrote:
> On 20.09.2016 05:36, Peter Chen wrote:
> > Hi all,
> >
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
> >
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> >
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> >
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> >
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
>
> Just tested this patch set on UDOO board again to make sure that it still
> works after all changes done since it was last tested there and can confirm
> that it does work correctly.
>
Thanks, Maciej.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v24 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Mark Rutland @ 2016-09-27 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160819132641.GA12709@rob-hp-laptop>
Hi Rob,
Reviving an old thread -- "rock" and "hard place" come to mind.
On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote:
> On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote:
> > From: James Morse <james.morse@arm.com>
> > +linux,usable-memory-range
> > +-------------------------
> > +
> > +This property (currently used only on arm64) holds the memory range,
> > +the base address and the size, which can be used as system ram on
> > +the *current* kernel. Note that, if this property is present, any memory
> > +regions under "memory" nodes in DT blob or ones marked as "conventional
> > +memory" in EFI memory map should be ignored.
> > +e.g.
> > +
> > +/ {
> > + chosen {
> > + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>;
> > + };
> > +};
>
> I've read the discussion on this. I think you should use the existing
> linux,usable-memory property in the memory nodes. If UEFI systems don't
> have memory nodes, then you can find an UEFI way to describe this. DT is
> not the dumping ground for what doesn't fit in UEFI. How do x86 systems
> work?
Having looked at the proposals, I'm personally much keener on the approach
above (modulo naming and wording) than trying to bolt memory nodes onto a UEFI
system, or using reserved-memory to describe the inverse of the allowable
range.
I completely agree that we want one solution for DT-only and DT+UEFI.
While those approaches reuse existing infrastructure, they end up creating more
work, and I believe that they create more scope for painful problems. As kdump
is already a constrained case, I think that it's reasonable to have a
linux-specific property as above.
I also think we need to figure out how we expect this to work for the
kexec_file_load case, as that has a criticial impact on the above (e.g. what's
preferable out of cmdline options vs dt properties).
Can we try to sync at connect to discuss this?
Thanks,
Mark.
^ permalink raw reply
* [PATCH v7 0/8] power: add power sequence library
From: Maciej S. Szmigiero @ 2016-09-27 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474342607-27512-1-git-send-email-peter.chen@nxp.com>
On 20.09.2016 05:36, Peter Chen wrote:
> Hi all,
>
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria is compatible string first, if the compatible string is not
> matched between dts and library, it will try to use generic power sequence.
>
> The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence instance is needed, for more power sequences
> are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
>
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
>
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
>
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
>
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html
Just tested this patch set on UDOO board again to make sure that it still
works after all changes done since it was last tested there and can confirm
that it does work correctly.
Maciej
^ permalink raw reply
* [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs
From: Stephen Boyd @ 2016-09-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20776501.pZ2NDOzLK3@phil>
On 09/26, Heiko Stuebner wrote:
> Am Montag, 26. September 2016, 09:25:11 CEST schrieb Viresh Kumar:
> > On 12-09-16, 14:55, Stephen Boyd wrote:
> > > On 08/29, Viresh Kumar wrote:
> > > > On 18-08-16, 16:52, Finlye Xiao wrote:
> > > > > +static int rockchip_adjust_opp_table(struct device *cpu_dev,
> > > > > + struct cpufreq_frequency_table *table,
> > > > > + int volt)
> > > > > +{
> > > > > + struct opp_table *opp_table;
> > > > > + struct cpufreq_frequency_table *pos;
> > > > > + struct dev_pm_opp *opp;
> > > > > +
> > > > > + if (!volt)
> > > > > + return 0;
> > > > > +
> > > > > + rcu_read_lock();
> > > > > +
> > > > > + opp_table = _find_opp_table(cpu_dev);
> > > > > + if (IS_ERR(opp_table)) {
> > > > > + rcu_read_unlock();
> > > > > + return PTR_ERR(opp_table);
> > > > > + }
> > > > > +
> > > > > + cpufreq_for_each_valid_entry(pos, table) {
> > > > > + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000,
> > > > > + true);
> > > > > + if (IS_ERR(opp))
> > > > > + continue;
> > > > > +
> > > > > + opp->u_volt += volt;
> > > > > + opp->u_volt_min += volt;
> > > > > + opp->u_volt_max += volt;
> > > > > + }
> > > > > +
> > > > > + rcu_read_unlock();
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > >
> > > > I wouldn't prefer altering the opp tables from individual drivers at
> > > > all. At the least, it should be done via some helpers exposed by the
> > > > core.
> > > >
> > > > But before that I would like to hear from Stephen a bit as I recall he
> > > > was also working on something similar.
> > >
> > > I had a patch to modify the voltage at runtime for the "current"
> > > OPP. Now that we have regulator and clk control inside OPP that
> > > became a little easier to do without having to do some notifier
> > > from the OPP layer to the consumers. I haven't had time to revive
> > > those patches though. Should we do that?
> >
> > Perhaps yes, we should have a common place for doing all that.
> >
> > > Does this need to modify
> > > anything besides the OPP the device is currently running at?
> >
> > Finlye, can you please answer this ?
>
> If I understand it correctly, depending on the leakage value stored in an
> efuse, all opp voltages are reduced by a certain value. Right now the driver
> does it in one go for the full opp table, but of course could also do it for
> each new opp individually before it gets set.
Ok. Well either way that sounds fine. We could expose an API to
change each voltage and an API to change the current voltage and
update the table.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Stephen Boyd @ 2016-09-27 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160927045357.GB27697@b29397-desktop>
Quoting Peter Chen (2016-09-26 21:53:58)
> On Mon, Sep 26, 2016 at 11:44:50AM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-09-25 20:29:27)
> > > On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> > > > Quoting Peter Chen (2016-09-16 18:16:05)
> > > > > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > > > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > > >
> > > > > > soc {
> > > > > > usb at 78d9000 {
> > > > > > extcon = <&usb_id>, <&usb_id>;
> > > > >
> > > > > Why you have two same extcon phandler? From my mind, one should id,
> > > > > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > > > > vbus support, how you support vbus detection for
> > > > > connection/disconnection with PC for your chipidea msm patch set?
> > > >
> > > > This was already in the dts files for db410c. In the chipidea binding
> > > > one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> > > > understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> > > > and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> > > > that great on this board because we only have on gpio for this.
> > >
> > > I think extcon-usb-gpio.c needs to extend for supporting vbus event,
> > > otherwise, the micro-b cable's connect/disconnect will introduce
> > > EXTCON_USB_HOST event, if you use two <&usb_idx> for both id and
> > > vbus event.
> > >
> >
> > Sorry, I'm lost now. extcon-usb-gpio.c already supports EXTCON_USB as an
> > event. Is the problem that we're using two of the same phandles in the
> > binding?
>
> No, ID and VBUS are different events.
>
> http://www.spinics.net/lists/linux-usb/msg147004.html
>
Agreed. But we only register for EXTCON_USB or EXTCON_USB_HOST for each
phandle in the list respectively based on the index of the phandle. So
with or without the patch you mention I don't see how it matters.
We do it this way to trigger the role switch when the cable is
disconnected. I think the problem with just having the id phandle is
that we'll never see the vbus event, and so the role switch doesn't
work.
^ permalink raw reply
* [PATCH v11 4/4] serial: pl011: add console matching function
From: Aleksey Makarov @ 2016-09-27 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160927205418.31529-1-aleksey.makarov@linaro.org>
This patch adds function pl011_console_match() that implements
method match of struct console. It allows to match consoles against
data specified in a string, for example taken from command line or
compiled by ACPI SPCR table handler.
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Christopher Covington <cov@codeaurora.org>
---
drivers/tty/serial/amba-pl011.c | 55 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 8a9e213..2f9af8a 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2288,12 +2288,67 @@ static int __init pl011_console_setup(struct console *co, char *options)
return uart_set_options(&uap->port, co, baud, parity, bits, flow);
}
+/**
+ * pl011_console_match - non-standard console matching
+ * @co: registering console
+ * @name: name from console command line
+ * @idx: index from console command line
+ * @options: ptr to option string from console command line
+ *
+ * Only attempts to match console command lines of the form:
+ * console=pl011,mmio|mmio32,<addr>[,<options>]
+ * console=pl011,0x<addr>[,<options>]
+ * This form is used to register an initial earlycon boot console and
+ * replace it with the amba_console at pl011 driver init.
+ *
+ * Performs console setup for a match (as required by interface)
+ * If no <options> are specified, then assume the h/w is already setup.
+ *
+ * Returns 0 if console matches; otherwise non-zero to use default matching
+ */
+static int __init pl011_console_match(struct console *co, char *name, int idx,
+ char *options)
+{
+ unsigned char iotype;
+ unsigned long addr;
+ int i;
+
+ if (strcmp(name, "pl011") != 0)
+ return -ENODEV;
+
+ if (uart_parse_earlycon(options, &iotype, &addr, &options))
+ return -ENODEV;
+
+ if (iotype != UPIO_MEM && iotype != UPIO_MEM32)
+ return -ENODEV;
+
+ /* try to match the port specified on the command line */
+ for (i = 0; i < ARRAY_SIZE(amba_ports); i++) {
+ struct uart_port *port;
+
+ if (!amba_ports[i])
+ continue;
+
+ port = &amba_ports[i]->port;
+
+ if (port->mapbase != addr)
+ continue;
+
+ co->index = i;
+ port->cons = co;
+ return pl011_console_setup(co, options);
+ }
+
+ return -ENODEV;
+}
+
static struct uart_driver amba_reg;
static struct console amba_console = {
.name = "ttyAMA",
.write = pl011_console_write,
.device = uart_console_device,
.setup = pl011_console_setup,
+ .match = pl011_console_match,
.flags = CON_PRINTBUFFER,
.index = -1,
.data = &amba_reg,
--
2.10.0
^ permalink raw reply related
* [PATCH v11 3/4] ARM64: ACPI: enable ACPI_SPCR_TABLE
From: Aleksey Makarov @ 2016-09-27 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160927205418.31529-1-aleksey.makarov@linaro.org>
SBBR mentions SPCR as a mandatory ACPI table. So enable it for ARM64
Earlycon should be set up as early as possible. ACPI boot tables are
mapped in arch/arm64/kernel/acpi.c:acpi_boot_table_init() that
is called from setup_arch() and that's where we parse SPCR.
So it has to be opted-in per-arch.
When ACPI_SPCR_TABLE is defined initialization of DT earlycon is
deferred until the DT/ACPI decision is done. Initialize DT earlycon
if ACPI is disabled.
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Tested-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/acpi.c | 11 ++++++++++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f..11a2d36 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -4,6 +4,7 @@ config ARM64
select ACPI_GENERIC_GSI if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
+ select ACPI_SPCR_TABLE if ACPI
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 3e4f1a4..252a6d9 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -24,6 +24,7 @@
#include <linux/memblock.h>
#include <linux/of_fdt.h>
#include <linux/smp.h>
+#include <linux/serial_core.h>
#include <asm/cputype.h>
#include <asm/cpu_ops.h>
@@ -206,7 +207,7 @@ void __init acpi_boot_table_init(void)
if (param_acpi_off ||
(!param_acpi_on && !param_acpi_force &&
of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
- return;
+ goto done;
/*
* ACPI is disabled at this point. Enable it in order to parse
@@ -226,6 +227,14 @@ void __init acpi_boot_table_init(void)
if (!param_acpi_force)
disable_acpi();
}
+
+done:
+ if (acpi_disabled) {
+ if (earlycon_init_is_deferred)
+ early_init_dt_scan_chosen_stdout();
+ } else {
+ parse_spcr(earlycon_init_is_deferred);
+ }
}
#ifdef CONFIG_ACPI_APEI
--
2.10.0
^ permalink raw reply related
* [PATCH v11 2/4] ACPI: parse SPCR and enable matching console
From: Aleksey Makarov @ 2016-09-27 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160927205418.31529-1-aleksey.makarov@linaro.org>
'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
Console Redirection Table) [2] as a mandatory ACPI table that
specifies the configuration of serial console.
Defer initialization of DT earlycon until ACPI/DT decision is made.
Parse the ACPI SPCR table, setup earlycon if required,
enable specified console.
Thanks to Peter Hurley for explaining how this should work.
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Tested-by: Christopher Covington <cov@codeaurora.org>
---
drivers/acpi/Kconfig | 3 ++
drivers/acpi/Makefile | 1 +
drivers/acpi/spcr.c | 111 ++++++++++++++++++++++++++++++++++++++++++
drivers/tty/serial/earlycon.c | 19 +++++++-
include/linux/acpi.h | 6 +++
include/linux/serial_core.h | 9 +++-
6 files changed, 146 insertions(+), 3 deletions(-)
create mode 100644 drivers/acpi/spcr.c
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 6cef2d1..4a269f9 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -77,6 +77,9 @@ config ACPI_DEBUGGER_USER
endif
+config ACPI_SPCR_TABLE
+ bool
+
config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index e5ada78..d799593 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
obj-$(CONFIG_ACPI_BGRT) += bgrt.o
obj-$(CONFIG_ACPI_CPPC_LIB) += cppc_acpi.o
+obj-$(CONFIG_ACPI_SPCR_TABLE) += spcr.o
obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
# processor has its own "processor." module_param namespace
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
new file mode 100644
index 0000000..e8d7bc7
--- /dev/null
+++ b/drivers/acpi/spcr.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2012, Intel Corporation
+ * Copyright (c) 2015, Red Hat, Inc.
+ * Copyright (c) 2015, 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#define pr_fmt(fmt) "ACPI: SPCR: " fmt
+
+#include <linux/acpi.h>
+#include <linux/console.h>
+#include <linux/kernel.h>
+#include <linux/serial_core.h>
+
+/**
+ * parse_spcr() - parse ACPI SPCR table and add preferred console
+ *
+ * @earlycon: set up earlycon for the console specified by the table
+ *
+ * For the architectures with support for ACPI, CONFIG_ACPI_SPCR_TABLE may be
+ * defined to parse ACPI SPCR table. As a result of the parsing preferred
+ * console is registered and if @earlycon is true, earlycon is set up.
+ *
+ * When CONFIG_ACPI_SPCR_TABLE is defined, this function should be called
+ * from arch inintialization code as soon as the DT/ACPI decision is made.
+ *
+ */
+int __init parse_spcr(bool earlycon)
+{
+ static char opts[64];
+ struct acpi_table_spcr *table;
+ acpi_size table_size;
+ acpi_status status;
+ char *uart;
+ char *iotype;
+ int baud_rate;
+ int err;
+
+ if (acpi_disabled)
+ return -ENODEV;
+
+ status = acpi_get_table_with_size(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&table,
+ &table_size);
+
+ if (ACPI_FAILURE(status))
+ return -ENOENT;
+
+ if (table->header.revision < 2) {
+ err = -ENOENT;
+ pr_err("wrong table version\n");
+ goto done;
+ }
+
+ iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ?
+ "mmio" : "io";
+
+ switch (table->interface_type) {
+ case ACPI_DBG2_ARM_SBSA_32BIT:
+ iotype = "mmio32";
+ /* fall through */
+ case ACPI_DBG2_ARM_PL011:
+ case ACPI_DBG2_ARM_SBSA_GENERIC:
+ case ACPI_DBG2_BCM2835:
+ uart = "pl011";
+ break;
+ case ACPI_DBG2_16550_COMPATIBLE:
+ case ACPI_DBG2_16550_SUBSET:
+ uart = "uart";
+ break;
+ default:
+ err = -ENOENT;
+ goto done;
+ }
+
+ switch (table->baud_rate) {
+ case 3:
+ baud_rate = 9600;
+ break;
+ case 4:
+ baud_rate = 19200;
+ break;
+ case 6:
+ baud_rate = 57600;
+ break;
+ case 7:
+ baud_rate = 115200;
+ break;
+ default:
+ err = -ENOENT;
+ goto done;
+ }
+
+ snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
+ table->serial_port.address, baud_rate);
+
+ pr_info("console: %s\n", opts);
+
+ if (earlycon)
+ setup_earlycon(opts);
+
+ err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
+
+done:
+ early_acpi_os_unmap_memory((void __iomem *)table, table_size);
+ return err;
+}
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 7aae655..ea00b9f 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -21,6 +21,7 @@
#include <linux/sizes.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
+#include <linux/acpi.h>
#ifdef CONFIG_FIX_EARLYCON_MEM
#include <asm/fixmap.h>
@@ -199,6 +200,14 @@ int __init setup_earlycon(char *buf)
return -ENOENT;
}
+/*
+ * When CONFIG_ACPI_SPCR_TABLE is defined, "earlycon" without parameters in
+ * command line does not start DT earlycon immediately, instead it defers
+ * starting it until DT/ACPI decision is made. At that time if ACPI is enabled
+ * call parse_spcr(), else call early_init_dt_scan_chosen_stdout()
+ */
+bool earlycon_init_is_deferred __initdata;
+
/* early_param wrapper for setup_earlycon() */
static int __init param_setup_earlycon(char *buf)
{
@@ -208,8 +217,14 @@ static int __init param_setup_earlycon(char *buf)
* Just 'earlycon' is a valid param for devicetree earlycons;
* don't generate a warning from parse_early_params() in that case
*/
- if (!buf || !buf[0])
- return early_init_dt_scan_chosen_stdout();
+ if (!buf || !buf[0]) {
+ if (IS_ENABLED(CONFIG_ACPI_SPCR_TABLE)) {
+ earlycon_init_is_deferred = true;
+ return 0;
+ } else {
+ return early_init_dt_scan_chosen_stdout();
+ }
+ }
err = setup_earlycon(buf);
if (err == -ENOENT || err == -EALREADY)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index c5eaf2f..2353827 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1074,4 +1074,10 @@ void acpi_table_upgrade(void);
static inline void acpi_table_upgrade(void) { }
#endif
+#ifdef CONFIG_ACPI_SPCR_TABLE
+int parse_spcr(bool earlycon);
+#else
+static inline int parse_spcr(bool earlycon) { return 0; }
+#endif
+
#endif /*_LINUX_ACPI_H*/
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 2f44e20..9e84cff 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -367,11 +367,18 @@ extern const struct earlycon_id __earlycon_table_end[];
#define EARLYCON_DECLARE(_name, fn) OF_EARLYCON_DECLARE(_name, "", fn)
-extern int setup_earlycon(char *buf);
extern int of_setup_earlycon(const struct earlycon_id *match,
unsigned long node,
const char *options);
+#ifdef CONFIG_SERIAL_EARLYCON
+extern bool earlycon_init_is_deferred __initdata;
+int setup_earlycon(char *buf);
+#else
+static const bool earlycon_init_is_deferred;
+static inline int setup_earlycon(char *buf) { return 0; }
+#endif
+
struct uart_port *uart_get_console(struct uart_port *ports, int nr,
struct console *c);
int uart_parse_earlycon(char *p, unsigned char *iotype, unsigned long *addr,
--
2.10.0
^ permalink raw reply related
* [PATCH v11 1/4] of/serial: move earlycon early_param handling to serial
From: Aleksey Makarov @ 2016-09-27 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160927151953.GB4371@kroah.com>
From: Leif Lindholm <leif.lindholm@linaro.org>
We have multiple "earlycon" early_param handlers - merge the DT one into
the main earlycon one. It's a cleanup that also will be useful
to defer setting up DT console until ACPI/DT decision is made.
Rename the exported function to avoid clashing with the function from
arch/microblaze/kernel/prom.c
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Tested-by: Christopher Covington <cov@codeaurora.org>
---
drivers/of/fdt.c | 11 +----------
drivers/tty/serial/earlycon.c | 2 +-
include/linux/of_fdt.h | 3 +++
3 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 085c638..c89d5d2 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -924,7 +924,7 @@ static inline void early_init_dt_check_for_initrd(unsigned long node)
#ifdef CONFIG_SERIAL_EARLYCON
-static int __init early_init_dt_scan_chosen_serial(void)
+int __init early_init_dt_scan_chosen_stdout(void)
{
int offset;
const char *p, *q, *options = NULL;
@@ -968,15 +968,6 @@ static int __init early_init_dt_scan_chosen_serial(void)
}
return -ENODEV;
}
-
-static int __init setup_of_earlycon(char *buf)
-{
- if (buf)
- return 0;
-
- return early_init_dt_scan_chosen_serial();
-}
-early_param("earlycon", setup_of_earlycon);
#endif
/**
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 067783f..7aae655 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -209,7 +209,7 @@ static int __init param_setup_earlycon(char *buf)
* don't generate a warning from parse_early_params() in that case
*/
if (!buf || !buf[0])
- return 0;
+ return early_init_dt_scan_chosen_stdout();
err = setup_earlycon(buf);
if (err == -ENOENT || err == -EALREADY)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 26c3302..4341f32 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -14,6 +14,7 @@
#include <linux/types.h>
#include <linux/init.h>
+#include <linux/errno.h>
/* Definitions used by the flattened device tree */
#define OF_DT_HEADER 0xd00dfeed /* marker */
@@ -66,6 +67,7 @@ extern int early_init_dt_scan_chosen(unsigned long node, const char *uname,
int depth, void *data);
extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
int depth, void *data);
+extern int early_init_dt_scan_chosen_stdout(void);
extern void early_init_fdt_scan_reserved_mem(void);
extern void early_init_fdt_reserve_self(void);
extern void early_init_dt_add_memory_arch(u64 base, u64 size);
@@ -94,6 +96,7 @@ extern void early_get_first_memblock_info(void *, phys_addr_t *);
extern u64 of_flat_dt_translate_address(unsigned long node);
extern void of_fdt_limit_memory(int limit);
#else /* CONFIG_OF_FLATTREE */
+static inline int early_init_dt_scan_chosen_stdout(void) { return -ENODEV; }
static inline void early_init_fdt_scan_reserved_mem(void) {}
static inline void early_init_fdt_reserve_self(void) {}
static inline const char *of_flat_dt_get_machine_name(void) { return NULL; }
--
2.10.0
^ permalink raw reply related
* [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288-veyron-speedy.
From: Vagrant Cascadian @ 2016-09-27 20:53 UTC (permalink / raw)
To: linux-arm-kernel
This essentially mimics what was done with rk3288-veyron-minnie in
commit 984926781122f034d5bc9962815d135b6c4a8e1d.
The eMMC of the speedy Chromebook also appears to need the same tuning
workaround, as it frequently fails to recognize the eMMC without it.
Signed-off-by: Vagrant Cascadian <vagrantc@aikidev.net>
---
Changes in v2:
- Added Signed-off-by.
arch/arm/boot/dts/rk3288-veyron-speedy.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
index a0d033f..500fd18 100644
--- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
@@ -124,6 +124,11 @@
&sdmmc_bus4>;
};
+
+&emmc {
+ /delete-property/mmc-hs200-1_8v;
+};
+
&vcc_5v {
enable-active-high;
gpio = <&gpio7 21 GPIO_ACTIVE_HIGH>;
--
2.9.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160927/2c08807f/attachment.sig>
^ permalink raw reply related
* [RFC 00/11] KVM PCIe/MSI passthrough on ARM/ARM64: re-design with transparent MSI mapping
From: Eric Auger @ 2016-09-27 20:48 UTC (permalink / raw)
To: linux-arm-kernel
Following Robin's series [1] addressing MSI IOMMU mapping for devices
attached to a DMA ops domain, my previous 3 part series (v12) lost most
of its consistency. msi-iommu API role now is handled at dma-iommu level
while MSI doorbell registration API only is used for security assessment.
Also MSI layer part is not needed anymore since mapping directly is
done in the compose callback.
Here I propose an alternative approach, based on [1]. This approach
was discussed at the KVM forum with Christoffer Dall and Marc Zyngier,
and was suggested by Christoffer. The idea is we could let the iommu
layer transparently allocate MSI frame IOVAs in the holes left between
UNMANAGED iova slots, set by the iommu-api user.
This series introduces a new IOMMU domain type that allows mixing of
unmanaged and managed IOVA slots. We define an IOVA domain whose
aperture covers the GPA address range. Each time the IOMMU-API
user maps iova/pa, we reserve the IOVA range to prevent the iova
allocator from using it for MSI mapping.
This simplifies the user part which does not need anymore to provide an
IOVA aperture anymore.
The current series does not address the interrupt safety assessment,
which may be considered as a separate issue. Currently the assignemnt
is considered as unsafe, on ARM (even with a GICv3 ITS).
Please let me know what is your feeling wrt this alternative approach.
dependency:
[1] [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
http://www.spinics.net/lists/arm-kernel/msg531110.html
Best Regards
Eric
Testing:
- functional on ARM64 AMD Overdrive HW (single GICv2m frame). Lack of contexts
prevents me from testing multiple assignment.
Git: complete series available at
https://github.com/eauger/linux/tree/generic-v7-pcie-passthru-redesign-rfc
previous: https://github.com/eauger/linux/tree/v4.7-rc7-passthrough-v12
the above branch includes a temporary patch to work around a ThunderX pci
bus reset crash (which I think unrelated to this series):
"vfio: pci: HACK! workaround thunderx pci_try_reset_bus crash"
Do not take this one for other platforms.
Eric Auger (10):
iommu: Add iommu_domain_msi_geometry and DOMAIN_ATTR_MSI_GEOMETRY
iommu: Introduce IOMMU_CAP_TRANSLATE_MSI capability
iommu: Introduce IOMMU_DOMAIN_MIXED
iommu/dma: iommu_dma_(un)map_mixed
iommu/arm-smmu: Allow IOMMU_DOMAIN_MIXED domain allocation
iommu: Use IOMMU_DOMAIN_MIXED typed domain when IOMMU translates MSI
vfio/type1: Sets the IOVA window in case MSI IOVA need to be allocated
vfio/type1: Reserve IOVAs for IOMMU_DOMAIN_MIXED domains
iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP
iommu/arm-smmu: Advertise IOMMU_CAP_TRANSLATE_MSI
Robin Murphy (1):
iommu/dma: Allow MSI-only cookies
drivers/iommu/arm-smmu-v3.c | 8 +++-
drivers/iommu/arm-smmu.c | 8 +++-
drivers/iommu/dma-iommu.c | 91 +++++++++++++++++++++++++++++++++++++++++
drivers/iommu/iommu.c | 10 ++++-
drivers/vfio/vfio_iommu_type1.c | 48 ++++++++++++++++++----
include/linux/dma-iommu.h | 27 ++++++++++++
include/linux/iommu.h | 23 +++++++++++
7 files changed, 203 insertions(+), 12 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Maxime Ripard @ 2016-09-27 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474879585.6096.33.camel@schinagl.nl>
Hi,
On Mon, Sep 26, 2016 at 10:46:25AM +0200, Olliver Schinagl wrote:
> > For the spin_lock part, I was just comparing it to a
> > spin_lock_irqsave, which is pretty expensive since it masks all the
> > interrupts in the system, introducing latencies.
>
> so spin_lock is very expensive and we should avoid if we can?
spin_lock_irqsave, if possible, yes.
> > > but I think we need the ndelay for the else where we do not
> > > have the ready flag (A10 or A13 iirc?)
> >
> > Hmmmm, good point. But that would also apply to your second patch
> > then, wouldn't it?
> yeah, you would have an if/else for the case of !hasready.
>
> this is what i've been dabbling in the train last week, but haven't
> thought it through yet, let alone tested it:
>
>
> +???????if (!(sun4i_pwm->data->has_rdy))
> +???????????????ndelay(pwm_get_period(pwm));
> +???????else
> +???????????????do {
> +???????????????????????spin_lock(&sun4i_pwm->ctrl_lock);
> +???????????????????????val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> +???????????????????????spin_unlock(&sun4i_pwm->ctrl_lock);
> +???????????????} while (!(val & PWM_RDY(pwm->hwpwm)))
>
> Here I assumed the spin_lock is cheap to make, expensive to hold for
> long, e.g. reducing the length the spin-lock is active for. the
> alternative was to remove the spin_lock here, and remove unlock-lock
> before-after this block where you basically get a very long lasting
> spin_lock, the alternative.
If you're only reading, why do you need to take the lock?
You probbaly want to have a timeout too.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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/20160927/72cc3f3f/attachment.sig>
^ permalink raw reply
* [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen
From: Jonathan Cameron @ 2016-09-27 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db3ab94a-9dbb-3bd6-fe43-e530b42c9246@free-electrons.com>
On 25/09/16 20:44, Quentin Schulz wrote:
> On 24/07/2016 13:24, Jonathan Cameron wrote:
>> On 20/07/16 09:29, Quentin Schulz wrote:
>>> This adds support for Allwinner SoCs' (A10, A13 and A31) resistive
>>> touchscreen. This driver is probed by the MFD sunxi-gpadc-mfd.
>>>
>>> This driver uses ADC channels exposed through the IIO framework by
>>> sunxi-gpadc-iio to get its data. When opening this input device, it will
>>> start buffering in the ADC driver and enable a TP_UP_PENDING irq. The ADC
>>> driver will fill in a buffer with all data and call the callback the input
>>> device associated with this buffer. The input device will then read the
>>> buffer two by two and send X and Y coordinates to the input framework based
>>> on what it received from the ADC's buffer. When closing this input device,
>>> the buffering is stopped.
>>>
>>> Note that locations in the first received buffer after an TP_UP_PENDING irq
>>> occurred are unreliable, thus dropped.
>>>
>> I think I now understand what you are doing.
>>
>> The channel grab is grabbing 4 channels, when there are only two real
>> ones (x and y) then you are abusing the callback interface from IIO.
>
> Actually, I need an IIO channel only for registering the callback from
> the consumer but I never use the IIO channel in an other way from
> consumer side (everything's done in the provider by reading the FIFO
> register and sending data to the callback via iio_buffer).
Whilst it 'would work' to just hook in and deal with the data if it
came through a single channel with enough space, that would be an
abuse of the interface which is very much designed to ship 'scans'
(e.g. sets of data taken at the same time ish).
There is a demux unit in the path which is designed to pull out
only the channels wanted by the consumer. If the combination
of available_scan_masks in the provider and the channels requested
by the consumer (via the map) are right then you'll only 'get'
the data you want and the rest will disappear into thin air ;)
>
>> That transmits only one scan (e.g. here (x,y)) per call. Because you
>> have added a sideband route for the buffer size what you have wil work.
>>
>> However, it is not how the interface should be used. Please fix that.
>> Using it correctly is not a big issue.
>>
>> On the channels front, I'd be tempted to do this as follows:
>>
>> 6 Channels, not 4.
>>
>> First 4 are standard ADC channels
>> Next 2 are the touch screen channels with appropriate descriptions
>> (guessing these are actually differential channels across the various
>> wires of the first two?)
>>
>
> Yes they are differential channels.
>
> However, I think there is actually no sense in using several channels
> for the touchscreen as everything is handled by the hardware. You only
> select the touchscreen mode by setting a register and then X and Y
> coordinates will be added to the FIFO register when touching the
> touchscreen. I would not mind not having IIO channel at all since we do
> not read from the consumer. But I need a way to register a callback to
> get data from the provider. I don't know if I make myself clear enough?
If you want to do it another way (I'd rather you didn't!) then you'll
need to create an mfd style base driver and register the touch screen
on that with custom callback registration etc.
>
>> Then you set the map up to apply to the last two channels only.
>> By setting available_scan_masks to the relevant options in the IIO driver
>> you'll be able to automatically lock the device when ever the
>> touch screeen driver is loaded.
>>
>> That map will be something like (in binary
>> 000000
>> 000011
>> 000100
>> 001000
>> 010000
>> 100000
>> 001100
>> 010100
>> 011000
>> 100100
>> 101000
>> 110000
>> 011100
>> 101100
>> 110100
>> 111000
>> 111100
>>
>> thus any combination of the ADC channels, but always all or none of the
>> touchscreen (none when ever the ADC channels are on) the order above
>> ensures we always turn on the minimum possible for a given requirement.
>>
>> Hence whenever the touch screen is there it'll lock out the ADC usage.
>> Your postenable can look at what is there and put it in the right mode.
>>
>
> I'll dive more into that.
>
>> After that, break your fifo read up into individual pairs of readings
>> and push those out.
>>
>> That way we end up using the interface in the standard fashion.
>>
>> You'll also need fix the usage of the fifo for ADC mode which suffers
>> from the same problem. There all sorts of nasty crashes might occur
>> or you might just loose data
>>
> [...]
>>> +/*
>>> + * This function will be called by iio_push_to_buffers from another driver
>>> + * (namely sunxi-gpadc-iio). It will be passed the buffer filled with input
>>> + * values (X value then Y value) and the sunxi_gpadc_ts structure representing
>>> + * the device.
>>> + */
>>> +static int sunxi_gpadc_ts_callback(const void *data, void *private)
>>> +{
>>> + const struct sunxi_gpadc_buffer *buffer = data;
>>> + struct sunxi_gpadc_ts *info = private;
>>> + int i = 0;
>>> +
>>> + /* Locations in the first buffer after an up event are unreliable */
>>> + if (info->ignore_fifo_data) {
>>> + info->ignore_fifo_data = false;
>>> + return 0;
>>> + }
>>> +
>> It doesn't work like this at all. You'll get one scan only on each call of
>> this function. As I said in the previous driver, if there is a true reason
>> to do this (and I'm unconvinced as yet) then we need to add support in the
>> iio core etc for this (and emulating it when multiple scan passing isn't
>> happening).
>>
>> I guess this will work, as you are passing the buffer size as a side
>> band, but it is definitely not how that ABI is meant to be used.
>>
>> Also, you grab 4 channels, and only two are used here. Please explain...
>>
>
> Hum. Actually, that's a mistake. I'm quiet confused about how I should
> do it while I never read channels from the consumer. I still "need" one
> for "linking" the consumer and the provider but in the meantime, I'm
> never using that channel.
You are, because the demux is only sending you the channels you
are registered for. Thus the provider should push whatever it
gets to the buffers and by the time it hits the consumer it should
get only what it needs.
It's not so interesting with this hardware because you can't do
general purpose reads at the same time as the touchscreen stuff is
running (annoyingly). With hardware that can do any combination of
channels you end up with for example:
Provider - pushing out a superset of all the channels anyone cares
about.
Consumer 1 (touch screen) gets just the x and y coordinates when pen
is down.
Consumer 2 (temperature - thermal) gets just the temperature.
Consumer 3 (e.g. battery monitory) gets just the charger voltages etc.
Consumer 4 (stretching here - analog accelerometer) gets just
accelerations for the input bridge I never get round to finally
submitting.
Jonathan
^ permalink raw reply
* [PATCH 1/4] mfd: ti_am335x_tscadc: store physical address
From: Lee Jones @ 2016-09-27 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921161134.6951-2-mugunthanvnm@ti.com>
On Wed, 21 Sep 2016, Mugunthan V N wrote:
> store the physical address of the device in its priv to use it
> for DMA addressing in the client drivers.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> drivers/mfd/ti_am335x_tscadc.c | 1 +
> include/linux/mfd/ti_am335x_tscadc.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> index c8f027b..0f3fab4 100644
> --- a/drivers/mfd/ti_am335x_tscadc.c
> +++ b/drivers/mfd/ti_am335x_tscadc.c
> @@ -183,6 +183,7 @@ static int ti_tscadc_probe(struct platform_device *pdev)
> tscadc->irq = err;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + tscadc->tscadc_phys_base = res->start;
This is unusual. Can't you use a virt_to_phys() variant instead?
> tscadc->tscadc_base = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(tscadc->tscadc_base))
> return PTR_ERR(tscadc->tscadc_base);
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
> index 7f55b8b..e45a208 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -155,6 +155,7 @@ struct ti_tscadc_dev {
> struct device *dev;
> struct regmap *regmap;
> void __iomem *tscadc_base;
> + phys_addr_t tscadc_phys_base;
> int irq;
> int used_cells; /* 1-2 */
> int tsc_wires;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 3/5] iio: adc: sunxi-gpadc-iio: enable iio_buffers
From: Jonathan Cameron @ 2016-09-27 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <433c4869-88ed-5821-2db2-67dbaa6541f7@free-electrons.com>
On 25/09/16 20:57, Quentin Schulz wrote:
> On 25/09/2016 11:10, Jonathan Cameron wrote:
>> On 24/09/16 18:40, Quentin Schulz wrote:
>>> Hi Jonathan,
>>>
>>> Sorry for the (long) delay, I did not have time to work on it. I'll
>>> mainly work in my free time now.
>>>
>>> Keep in mind this patch was proposed based on the v2 of the ADC patches.
>>> Since then, substantial changes have been made and I'm working on
>>> rebasing this series of patches on the v6, so comments here might
>>> include references to code parts added later in the ADC patch series.
>>>
>>> On 24/07/2016 13:03, Jonathan Cameron wrote:
>>>> On 20/07/16 09:29, Quentin Schulz wrote:
>>>>> This enables the use of buffers on ADC channels of sunxi-gpadc-iio driver.
>>>>> It also prepares the code which will be used by the touchscreen driver
>>>>> named sunxi-gpadc-ts.
>>>>>
>>>>> The GPADC on Allwinner SoCs (A10, A13 and A31) has a 12 bits register for
>>>>> conversion's data. The GPADC uses the same ADC channels for the ADC and the
>>>>> touchscreen therefore exposes these channels to the sunxi-gpadc-ts iio
>>>>> consumer which will be in charge of reading data from these channels for
>>>>> the input framework.
>>>>>
>>>>> The temperature can only be read when in touchscreen mode. This means if
>>>>> the buffers are being used for the ADC, the temperature sensor cannot be
>>>>> read.
>>>> That may be the bizarest hardware restriction I've heard of in a while! :)
>>>>>
>>>>> When a FIFO_DATA_PENDING irq occurs, its handler will read the entire FIFO
>>>>> and fill a buffer before sending it to the consumers which registered in
>>>>> IIO for the ADC channels.
>>>>>
>>>>> When a consumer starts buffering ADC channels,
>>>>> sunxi_gpadc_buffer_postenable is called and will enable FIFO_DATA_PENDING
>>>>> irq and select the mode in which the GPADC should run (ADC or touchscreen)
>>>>> depending on a property of the DT ("allwinner,ts-attached").
>>>>> When the consumer stops buffering, it disables the same irq.
>>>> Hmm. Might be possible to distinguish which consumer caused the start.
>>>> Thus, if the touchscreen is there we would know purely based on the
>>>> driver being the requester that we need to be in touchscreen mode.
>>>>
>>>
>>> As of yet, can't see in which way I can retrieve the consumer in
>>> provider code. Maybe I'm missing something, I don't know?
>> I don't think we have a current way of doing this... Might be possible
>> to add one, but it would be a rather odd bit of reverse looking up.
> [...]
>>>>> @@ -101,19 +104,43 @@ struct sunxi_gpadc_dev {
>>>>> unsigned int fifo_data_irq;
>>>>> unsigned int temp_data_irq;
>>>>> unsigned int flags;
>>>>> + struct iio_dev *indio_dev;
>>>> I was suprised to see this as normally it is cleaner to structure
>>>> the whole code to go in one direction through the structures (which is
>>>> why we don't provide a generic iio_device_from_priv bit of pointer magic).
>>>>
>>>> Anyhow, don't htink you are actually using it ;)
>>>>
>>>
>>> I'm using to push to buffers from the irq handler since I pass the local
>>> structure (sunxi_gpadc_dev) to the irq handler when registering it. But
>>> I guess I can pass the iio_dev instead and remove this from the local
>>> structure.
>> I'd prefer passing the iio_dev and keep all lookups in one direction.
>
> ACK.
>
>>>
>>> [...]
>>>>> static int sunxi_gpadc_adc_read(struct iio_dev *indio_dev, int channel,
>>>>> int *val)
>>>>> {
>>>>> struct sunxi_gpadc_dev *info = iio_priv(indio_dev);
>>>>> + bool buffered = info->buffered;
>>>> Not worth the local version...
>>>>> int ret = 0;
>>>>> + unsigned int reg;
>>>>>
>>>>> mutex_lock(&indio_dev->mlock);
>>>>>
>>>>> reinit_completion(&info->completion);
>>>>> +
>>>>> + reg = SUNXI_GPADC_TP_FIFO_TRIG_LEVEL(1) | SUNXI_GPADC_TP_FIFO_FLUSH;
>>>>> + regmap_update_bits(info->regmap, SUNXI_GPADC_TP_INT_FIFOC, reg, reg);
>>>> I'd put it in directly rahter than having a reg local variable. To mind
>>>> mind that would be slightly easier to understand.
>>>>> +
>>>>> if (info->flags & SUNXI_GPADC_ARCH_SUN6I)
>>>>> regmap_write(info->regmap, SUNXI_GPADC_TP_CTRL1,
>>>>> SUNXI_GPADC_SUN6I_TP_MODE_EN |
>>>>> @@ -153,9 +185,9 @@ static int sunxi_gpadc_adc_read(struct iio_dev *indio_dev, int channel,
>>>>> SUNXI_GPADC_TP_MODE_EN |
>>>>> SUNXI_GPADC_TP_ADC_SELECT |
>>>>> SUNXI_GPADC_ADC_CHAN_SELECT(channel));
>>>>> - regmap_write(info->regmap, SUNXI_GPADC_TP_INT_FIFOC,
>>>>> - SUNXI_GPADC_TP_FIFO_TRIG_LEVEL(1) |
>>>>> - SUNXI_GPADC_TP_FIFO_FLUSH);
>>>> Whole load of infrastructure in place to lock buffered mode out and
>>>> revent transitions when we can't have them.
>>>>
>>>> iio_claim_direct_mode etc. I think you can just use that here?
>>>> If you need to do extra checks on it being enabled that should be
>>>> fine too.
>>>>
>>>
>>> Yes, way better with iio_device_claim_direct_mode and iio_buffer_enabled!
>>>
>>>> As a general rule, it makes sense to simply disable polled reads
>>>> if in buffered mode. Leads to much simpler code and generally
>>>> the data is already known to userspace anyway.
>>>>
>>>
>>> That's what I try to do.
>>> However, I think the temperature of the SoC is an interesting feature to
>>> have. Since it ("hardwarely") works while the ADC is read in touchscreen
>>> mode (even in buffer mode), I guess it could be a good idea to allow it
>>> in the driver. If we don't do that, boards with a touchscreen connected
>>> to the ADC of the SoC will not get SoC temperatures and can't have
>>> proper thermal management. We already have one board in that case: the
>>> PocketCHIP.
>>>
>>> Therefore, I also need to know if when the buffer is enabled, if it's
>>> for buffering ADC data or touchscreen data. If it's for ADC data, then I
>>> should disable temperature readings since it will return senseless
>>> values (from memory, always 0 which means something like -144?C).
>> Nice so no thermal management if we don't have a touch screen :)
>
> I think that's a big constraint. I think we should be able to read the
> temperature when the ADC is in either touchscreen or ADC mode but ONLY
> in DIRECT_MODE. While in BUFFER_MODE, we should enable temperature
> reading only when the touchscreen is present.
It would certainly be preferable to do so.
>
> That might induce a problem with the thermal framework I think. I've had
> some problem with temperature reading's timeout so I'm reading a
> manually "cached" temperature which is updated when the temperature
> reading is done. However, it will never be updated when the ADC is in
> buffered ADC mode. I don't know if in that case it is better to
> unregister the thermal device, to give outdated values or to notify the
> thermal framework the temperature readings timed out (which is verbose).
> [...]
Definitely need some input from the thermal guys on this. Perhaps
they need to have a way of saying -EBUSY.
>>>>> @@ -261,7 +302,29 @@ static irqreturn_t sunxi_gpadc_temp_data_irq_handler(int irq, void *dev_id)
>>>>> static irqreturn_t sunxi_gpadc_fifo_data_irq_handler(int irq, void *dev_id)
>>>>> {
>>>>> struct sunxi_gpadc_dev *info = dev_id;
>>>>> - int ret;
>>>>> + int ret, reg, i, fifo_count;
>>>>> +
>>>>> + if (info->buffered) {
>>>>> + if (regmap_read(info->regmap, SUNXI_GPADC_TP_INT_FIFOS, ®))
>>>>> + return IRQ_HANDLED;
>>>>> +
>>>>> + fifo_count = (reg & SUNXI_GPADC_RXA_CNT) >> 8;
>>>>> + /* Sometimes, the interrupt occurs when the FIFO is empty. */
>>>>> + if (!fifo_count)
>>>>> + return IRQ_HANDLED;
>>>>> +
>>>>> + for (i = 0; i < fifo_count; i++) {
>>>>> + if (regmap_read(info->regmap, SUNXI_GPADC_TP_DATA,
>>>>> + &info->buffer.buffer[i]))
>>>>> + return IRQ_HANDLED;
>>>>> + }
>>>>> +
>>>>> + info->buffer.buff_size = i;
>>>>> +
>>>>> + iio_push_to_buffers(info->indio_dev, &info->buffer);
>>>> This is expecting a single 'scan' - e.g. set of channels read at one
>>>> time. Here I think we could have repeated sets of channels?
>>>> (at least that would be what is normally meant by a fifo in such
>>>> a device).
>>>>
>>>> If so you need to read 'whole' scans and push them one at a time.
>>>> We don't yet have a bulk iio_push_to_buffers, though we can add
>>>> one if it makes sense. Care will be needed though as we'd need
>>>> handle the case of different consumers either supporting or
>>>> not supporting this new functionality. Not particularly hard though
>>>> if it is worth doing.
>>>
>>> I didn't know it was meant for only one scan. Then I need a bulk
>>> iio_push_to_buffers.
>> We've had a few cases where that would be handy recently.
>> The bit that makes it complex is if we are doing any demux of the channels
>> to multiple consumers. Could be done by falling back to separating
>> the scan's out and pushing them one by one through the demux though.
>> Not sure there is a better way to do it though...
>>>
>>> I have a rather big problem. The whole first FIFO at each touch is
>>> unusable so I have to drop it. I can detect the beginning of a touch
>>> when the TP_UP irq occurs, then I know the next full FIFO the consumer
>>> receives by callback is to be dropped. If I use push_to_buffers to send
>>> coordinates by coordinates, the consumer has no mean to know when the
>>> second FIFO (the first to be valid) starts and can be used. Either we
>>> can find a way to notify the consumer of the start of a new FIFO or I
>>> have to use a bulk iio_push_to_buffers.
>> Nasty indeed.
>>>
>>> The workaround would be to register the TP_UP irq in the provider (the
>>> ADC driver) and do not send the first FIFO to the consumer. But then, we
>>> need a way to know which consumer requests buffering to know when to
>>> enable this irq and do all touchscreen-only logic (dropping first
>>> frame). And I guess we don't have something like that yet. Or I could
>>> only code a buffering in touchscreen mode and add the ADC buffering
>>> later? But it doesn't feel right to do what I think should be handled
>>> (TP_UP irq handler and first FIFO dropping) in the consumer, in the
>>> provider.
>> Would indeed by the nicer way of doing it, but we are ultimately working
>> around a hardware issue (to my mind it should never return rubbish!)
>> so I'd not worry too much about where the fix is.
>>>
>>> So it's quiet a dead-end yet if I can't use iio_push_to_buffers with a
>>> whole FIFO (which you told is not how it is meant to be used).
>> It only worked here because you had control of both ends of the link.
>>
>> First thought is that we should add a bulk push to buffers, but
>> that a little bit of fiddly code would be needed to unwind the
>> data in the demux if needed. Probably not too hard to do. It would then
>> need to repackage the data up as a bulk buffer data block to send onwards.
>>
>> To do this I think you'd need to:
>> 1) Add core support to have a bulk push with the right magic around to call
>> the demux code in a loop over all the elements before pushing on.
>> 2) Bulk handling in the callback buffer.
>> 3) Kfifo bulk handling (mostly to allow us to test the demux code).
>>
>> Actually, short of stuff I haven't thought of, doesn't look too tricky
>> and useful feature to have in general.
>>
>
> Then I guess we'll have to do it :) I might need a lot of guiding though
> but maybe that's more of an IRC chat or non-lkml conversation?
Sure, funnily enough I'm updating the sca3000 driver to finally
lift it out of staging and a bulk write would help there as well.
(tends to be copying 32 scans + at a time due to a hardware fifo).
Looking at the new kionix parts which have 8K hardware fifos this gets
even more interesting (though perhaps we should handle as pure
hardware fifos without the front end kfifo.)
>
> Thanks,
> Quentin
>
^ permalink raw reply
* next-20160927 build: 2 failures 4 warnings (next-20160927)
From: Lee Jones @ 2016-09-27 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160927160036.y3ti3gzt4ebg2vyz@sirena.org.uk>
On Tue, 27 Sep 2016, Mark Brown wrote:
> On Tue, Sep 27, 2016 at 10:49:27AM +0100, Build bot for Mark Brown wrote:
>
> -next is still failing to build an arm and arm64 allmodconfig due to:
>
> > arm64-allmodconfig
> > ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
>
> > arm-allmodconfig
> > ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
>
> due to 262d5cc6ceb293 (mfd: tps65217: Add support for IRQs) since
> irq_set_parent() isn't exported. There was a fix posted adding the
> export to the IRQ subsystem but it's still not been applied, the
> function is being used in order to enable lazy IRQ disabling for
> threaded interrupts:
>
> https://www.spinics.net/lists/arm-kernel/msg532864.html
Right H-hour is fast approaching. How are we going to resolve this?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 3/8] i2c: bcm2835: Use ratelimited logging on transfer errors
From: Noralf Trønnes @ 2016-09-27 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74D9ED33-1B99-4ED6-88B5-879950D160C8@martin.sperl.org>
Den 27.09.2016 15:01, skrev Martin Sperl:
>> On 27 Sep 2016, at 13:57, Noralf Tr?nnes <noralf@tronnes.org> wrote:
>>
>> Writing to an AT24C32 generates on average 2x i2c transfer errors per
>> 32-byte page write. Which amounts to a lot for a 4k write. This is due
>> to the fact that the chip doesn't respond during it's internal write
>> cycle when the at24 driver tries and retries the next write.
>> Reduce this flooding of the log by using dev_err_ratelimited().
>>
>> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
>> Reviewed-by: Eric Anholt <eric@anholt.net>
>> ---
>> drivers/i2c/busses/i2c-bcm2835.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
>> index df036ed..370a322 100644
>> --- a/drivers/i2c/busses/i2c-bcm2835.c
>> +++ b/drivers/i2c/busses/i2c-bcm2835.c
>> @@ -207,7 +207,8 @@ static int bcm2835_i2c_xfer_msg(struct bcm2835_i2c_dev *i2c_dev,
>> (msg->flags & I2C_M_IGNORE_NAK))
>> return 0;
>>
>> - dev_err(i2c_dev->dev, "i2c transfer failed: %x\n", i2c_dev->msg_err);
>> + dev_err_ratelimited(i2c_dev->dev, "i2c transfer failed: %x\n",
>> + i2c_dev->msg_err);
> Do we really need this error message at all?
>
> Maybe just remove it instead, because error messages during
> "normal"/successfull operations of at24 seems strange.
>
> Or make it a debug message instead.
I have looked through 64 i2c bus drivers, 8 use dev_err and 2 use dev_warn
on transfer errors (not timeouts). Several use dev_dbg.
I'll change it to dev_dbg instead. Thanks.
Noralf.
^ permalink raw reply
* [PATCH v2 8/8] ARM: bcm2835: Disable i2c2 in the Device Tree
From: Noralf Trønnes @ 2016-09-27 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <256118042.194076.147d5d83-f402-4ba4-b7de-4ab57a0e29ad.open-xchange@email.1und1.de>
Den 27.09.2016 19:25, skrev Stefan Wahren:
>> Noralf Tr?nnes <noralf@tronnes.org> hat am 27. September 2016 um 13:57
>> geschrieben:
>>
>>
>> i2c2 is connected to the HDMI connector and is controlled by the
>> firmware. Disable it to stay out of harms way.
> Until this point the commit message is okay, the rest is more confusing.
>
> Btw this should avoid a warning about missing clock frequency.
>
>> From the downstream commit:
>> i2c-bcm2708/BCM270X_DT: Add support for I2C2
>>
>> The third I2C bus (I2C2) is normally reserved for HDMI use. Careless
>> use of this bus can break an attached display - use with caution.
>>
>> It is recommended to disable accesses by VideoCore by setting
>> hdmi_ignore_edid=1 or hdmi_edid_file=1 in config.txt.
>>
>> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
>> ---
>> arch/arm/boot/dts/bcm2835-rpi.dtsi | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
>> b/arch/arm/boot/dts/bcm2835-rpi.dtsi
>> index e9b47b2..8bffbee 100644
>> --- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
>> +++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
>> @@ -59,10 +59,6 @@
>> clock-frequency = <100000>;
>> };
>>
>> -&i2c2 {
>> - status = "okay";
>> -};
>> -
> I'm not sure if this the right fix. According to bcm283x.dtsi the 3 i2c busses
> have the same compatible string "brcm,bcm2835-i2c", but the changelog suggests
> that this bus is "special".
I just rounded up all the differences from downstream that I knew about
into this patchset. But looking closer I see that the vc4 driver uses
i2c2. So I'll drop this patch.
Noralf.
> Shouldn't we use a different compatible string? Our intention isn't to disable
> i2c2 but avoid any claims of the usual i2c driver.
>
>> &sdhci {
>> status = "okay";
>> bus-width = <4>;
>> --
>> 2.8.2
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* linux-next: manual merge of the gpio tree with the arm-soc tree
From: Tony Lindgren @ 2016-09-27 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160927150542.7e81e7ee@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> [160926 22:06]:
> Hi Linus,
>
> Today's linux-next merge of the gpio tree got a conflict in:
>
> arch/arm/mach-omap2/board-rx51-peripherals.c
>
> between commit:
>
> 9b7141d01a76 ("ARM: OMAP2+: Drop legacy board file for n900")
>
> from the arm-soc tree and commit:
>
> 9132ce450bd1 ("ARM: omap2: fix missing include")
>
> from the gpio tree.
>
> I fixed it up (the former removed the file, so I did that) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Yes thanks removing it the way to go.
Regards,
Tony
^ permalink raw reply
* [PATCH 3/3] KVM: arm/arm64: Support arch timers with a userspace gic
From: Christoffer Dall @ 2016-09-27 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160927190806.22988-1-christoffer.dall@linaro.org>
From: Alexander Graf <agraf@suse.de>
If you're running with a userspace gic or other interrupt constroller
(that is no vgic in the kernel), then you have so far not been able to
use the architected timers, because the output of the architected
timers, which are driven inside the kernel, was a kernel-only construct
between the arch timer code and the vgic.
This patch implements the new KVM_CAP_ARM_TIMER feature, where we use a
side channel on the kvm_run structure, run->s.regs.timer_irq_level, to
always notify userspace of the timer output level when using a userspace
irqchip.
This works by ensureing that before we enter the guest, if the timer
output level has changed compared to what we last told userspace, we
don't enter the guest, but instead return to userspace to notify it of
the new level. If we are exiting, because of an MMIO for example, and
the level changed at the same time, the value is also updated and
userspace can sample the line as it needs. This is nicely achieved
simply always updating the timer_irq_level field after the main run
loop.
Note that the kvm_timer_update_irq trace event is changed to show the
host IRQ number for the timer instead of the guest IRQ number, because
the kernel no longer know which IRQ userspace wires up the timer signal
to.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/arm/kvm/arm.c | 19 ++++----
include/kvm/arm_arch_timer.h | 2 +
virt/kvm/arm/arch_timer.c | 105 +++++++++++++++++++++++++++++++++++--------
3 files changed, 98 insertions(+), 28 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 85a3f90..712695d 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -187,6 +187,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PSCI_0_2:
case KVM_CAP_READONLY_MEM:
case KVM_CAP_MP_STATE:
+ case KVM_CAP_ARM_TIMER:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
@@ -474,13 +475,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
return ret;
}
- /*
- * Enable the arch timers only if we have an in-kernel VGIC
- * and it has been properly initialized, since we cannot handle
- * interrupts from the virtual timer with a userspace gic.
- */
- if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
- ret = kvm_timer_enable(vcpu);
+ ret = kvm_timer_enable(vcpu);
return ret;
}
@@ -594,9 +589,12 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
local_irq_disable();
/*
- * Re-check atomic conditions
+ * If we have a singal pending, or need to notify a userspace
+ * irqchip about timer level changes, then we exit (and update
+ * the timer level state in kvm_timer_update_run below).
*/
- if (signal_pending(current)) {
+ if (signal_pending(current) ||
+ kvm_timer_should_notify_user(vcpu)) {
ret = -EINTR;
run->exit_reason = KVM_EXIT_INTR;
}
@@ -668,6 +666,9 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
ret = handle_exit(vcpu, run, ret);
}
+ /* Tell userspace about the arch timer output level */
+ kvm_timer_update_run(vcpu);
+
if (vcpu->sigset_active)
sigprocmask(SIG_SETMASK, &sigsaved, NULL);
return ret;
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index dda39d8..7157e73 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -65,6 +65,8 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
+bool kvm_timer_should_notify_user(struct kvm_vcpu *vcpu);
+void kvm_timer_update_run(struct kvm_vcpu *vcpu);
void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu);
u64 kvm_arm_timer_get_reg(struct kvm_vcpu *, u64 regid);
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 824ed26..c645b7d 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -166,6 +166,22 @@ bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
return cval <= now;
}
+/*
+ * Reflect the timer output level into the kvm_run structure
+ */
+void kvm_timer_update_run(struct kvm_vcpu *vcpu)
+{
+ struct kvm_sync_regs *regs = &vcpu->run->s.regs;
+
+ if (likely(irqchip_in_kernel(vcpu->kvm)))
+ return;
+
+ /* Populate the timer bitmap for user space */
+ regs->timer_irq_level &= ~KVM_ARM_TIMER_VTIMER;
+ if (vcpu->arch.timer_cpu.irq.level)
+ regs->timer_irq_level |= KVM_ARM_TIMER_VTIMER;
+}
+
static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
{
int ret;
@@ -173,12 +189,17 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
timer->active_cleared_last = false;
timer->irq.level = new_level;
- trace_kvm_timer_update_irq(vcpu->vcpu_id, timer->irq.irq,
+ trace_kvm_timer_update_irq(vcpu->vcpu_id, host_vtimer_irq,
timer->irq.level);
- ret = kvm_vgic_inject_mapped_irq(vcpu->kvm, vcpu->vcpu_id,
- timer->irq.irq,
- timer->irq.level);
- WARN_ON(ret);
+
+ if (likely(irqchip_in_kernel(vcpu->kvm))) {
+ /* Fire the timer in the VGIC */
+ ret = kvm_vgic_inject_mapped_irq(vcpu->kvm, vcpu->vcpu_id,
+ timer->irq.irq,
+ timer->irq.level);
+
+ WARN_ON(ret);
+ }
}
/*
@@ -195,7 +216,7 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
* because the guest would never see the interrupt. Instead wait
* until we call this function from kvm_timer_flush_hwstate.
*/
- if (!timer->enabled)
+ if (unlikely(!timer->enabled))
return;
if (kvm_timer_should_fire(vcpu) != timer->irq.level)
@@ -238,24 +259,12 @@ void kvm_timer_unschedule(struct kvm_vcpu *vcpu)
timer_disarm(timer);
}
-/**
- * kvm_timer_flush_hwstate - prepare to move the virt timer to the cpu
- * @vcpu: The vcpu pointer
- *
- * Check if the virtual timer has expired while we were running in the host,
- * and inject an interrupt if that was the case.
- */
-void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
+static void kvm_timer_flush_hwstate_vgic(struct kvm_vcpu *vcpu)
{
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
bool phys_active;
int ret;
- if (unlikely(!timer->enabled))
- return;
-
- kvm_timer_update_state(vcpu);
-
/*
* If we enter the guest with the virtual input level to the VGIC
* asserted, then we have already told the VGIC what we need to, and
@@ -307,6 +316,56 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
timer->active_cleared_last = !phys_active;
}
+bool kvm_timer_should_notify_user(struct kvm_vcpu *vcpu)
+{
+ struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+ bool run_level = vcpu->run->s.regs.timer_irq_level & KVM_ARM_TIMER_VTIMER;
+
+ if (likely(irqchip_in_kernel(vcpu->kvm)))
+ return false;
+
+ return timer->irq.level != run_level;
+}
+
+static void kvm_timer_flush_hwstate_user(struct kvm_vcpu *vcpu)
+{
+ struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+
+ /*
+ * To prevent continuously exiting from the guest, we mask the
+ * physical interrupt such that the guest can make forward progress.
+ * Once we detect the output level being deasserted, we unmask the
+ * interrupt again so that we exit from the guest when the timer
+ * fires.
+ */
+ if (timer->irq.level)
+ disable_percpu_irq(host_vtimer_irq);
+ else
+ enable_percpu_irq(host_vtimer_irq, 0);
+}
+
+/**
+ * kvm_timer_flush_hwstate - prepare to move the virt timer to the cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Check if the virtual timer has expired while we were running in the host,
+ * and inject an interrupt if that was the case.
+ */
+void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
+{
+ struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+
+ if (unlikely(!timer->enabled))
+ return;
+
+ kvm_timer_update_state(vcpu);
+
+ if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
+ kvm_timer_flush_hwstate_user(vcpu);
+ else
+ kvm_timer_flush_hwstate_vgic(vcpu);
+}
+
/**
* kvm_timer_sync_hwstate - sync timer state from cpu
* @vcpu: The vcpu pointer
@@ -473,6 +532,13 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
if (timer->enabled)
return 0;
+ /* Without a VGIC we do not map virtual IRQs to physical IRQs */
+ if (!irqchip_in_kernel(vcpu->kvm))
+ goto no_vgic;
+
+ if (!vgic_initialized(vcpu->kvm))
+ return -ENODEV;
+
/*
* Find the physical IRQ number corresponding to the host_vtimer_irq
*/
@@ -496,6 +562,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
if (ret)
return ret;
+no_vgic:
/*
* There is a potential race here between VCPUs starting for the first
--
2.9.0
^ 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