* [PATCH 0/3] DMA Engine: switch PL330 driver to non-irq-safe runtime PM
From: Marek Szyprowski @ 2016-12-22 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161222121148epcas5p11d4e49a3724e375a989aa173f731346f@epcas5p1.samsung.com>
Hello,
This patchset changes the way the runtime PM is implemented in PL330 DMA
engine driver. The main goal of such change is to add support for audio
power domain to Exynos5 SoCs (5250, 542x, 5433, probably others) and let
it to be properly turned off, when no audio is being used. Switching to
non-irq-safe runtime PM is needed to properly let power domain to be
turned off (irqsafe runtime PM keeps power domain turned on all the time)
and to integrate with clock controller's runtime PM (this cannot be
workarounded any other way, PL330 uses clocks from the controller, which
belongs to the same power domain).
For more details of the proposed change to PL330 driver see patch #3.
Audio power domain on Exynos5 SoCs contains following hardware modules:
1. clock controller
2. pin controller
3. PL330 DMA controller
4. I2S audio controller
Patches for adding/fixing runtime PM for each of the above device will be
handled separately.
Runtime PM patches for clock controllers is possible and has been proposed
in the following thread (pending review, patch for runtime PM for Exynos
Audio subsystem will be added in v4 soon):
https://www.spinics.net/lists/arm-kernel/msg538122.html
Runtime PM support for Exynos pin controller will be posted soon in
a separate thread.
Exynos I2S driver already supports runtime PM, but some fixes are needed
for it and they will be also posted soon.
Patches are based on linux-next with my PL330 runtime PM fix patch
applied (which I assume will be merged as a fix to v4.10):
https://patchwork.kernel.org/patch/9477695/
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Patch summary:
Marek Szyprowski (3):
dmaengine: pl330: remove pdata based initialization
dmaengine: Forward slave device pointer to of_xlate callback
dmaengine: pl330: Don't require irq-safe runtime PM
drivers/dma/amba-pl08x.c | 2 +-
drivers/dma/at_hdmac.c | 4 +-
drivers/dma/at_xdmac.c | 2 +-
drivers/dma/bcm2835-dma.c | 2 +-
drivers/dma/coh901318.c | 2 +-
drivers/dma/cppi41.c | 2 +-
drivers/dma/dma-jz4780.c | 2 +-
drivers/dma/dmaengine.c | 2 +-
drivers/dma/dw/platform.c | 2 +-
drivers/dma/edma.c | 4 +-
drivers/dma/fsl-edma.c | 2 +-
drivers/dma/img-mdc-dma.c | 2 +-
drivers/dma/imx-dma.c | 2 +-
drivers/dma/imx-sdma.c | 2 +-
drivers/dma/k3dma.c | 2 +-
drivers/dma/mmp_pdma.c | 2 +-
drivers/dma/mmp_tdma.c | 2 +-
drivers/dma/moxart-dma.c | 2 +-
drivers/dma/mxs-dma.c | 2 +-
drivers/dma/nbpfaxi.c | 2 +-
drivers/dma/of-dma.c | 20 +++--
drivers/dma/pl330.c | 166 +++++++++++++++++++---------------------
drivers/dma/pxa_dma.c | 2 +-
drivers/dma/qcom/bam_dma.c | 2 +-
drivers/dma/sh/rcar-dmac.c | 2 +-
drivers/dma/sh/shdma-of.c | 2 +-
drivers/dma/sh/usb-dmac.c | 2 +-
drivers/dma/sirf-dma.c | 2 +-
drivers/dma/st_fdma.c | 2 +-
drivers/dma/ste_dma40.c | 2 +-
drivers/dma/stm32-dma.c | 2 +-
drivers/dma/sun4i-dma.c | 2 +-
drivers/dma/sun6i-dma.c | 2 +-
drivers/dma/tegra20-apb-dma.c | 2 +-
drivers/dma/tegra210-adma.c | 2 +-
drivers/dma/xilinx/xilinx_dma.c | 2 +-
drivers/dma/xilinx/zynqmp_dma.c | 2 +-
drivers/dma/zx296702_dma.c | 2 +-
include/linux/amba/pl330.h | 35 ---------
include/linux/of_dma.h | 17 ++--
40 files changed, 139 insertions(+), 175 deletions(-)
delete mode 100644 include/linux/amba/pl330.h
--
1.9.1
^ permalink raw reply
* [PATCH] clk: mvebu: adjust AP806 CPU clock frequencies to production chip
From: Thomas Petazzoni @ 2016-12-22 12:08 UTC (permalink / raw)
To: linux-arm-kernel
This commit adjusts the list of possible "Sample At Reset" values that
define the CPU clock frequency of the AP806 (part of Marvell Armada
7K/8K) to the values that have been validated with the production
chip. Earlier values were preliminary.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/clk/mvebu/ap806-system-controller.c | 28 +++++++++++++++++++++++-----
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/mvebu/ap806-system-controller.c b/drivers/clk/mvebu/ap806-system-controller.c
index 02023ba..962e0c5 100644
--- a/drivers/clk/mvebu/ap806-system-controller.c
+++ b/drivers/clk/mvebu/ap806-system-controller.c
@@ -55,21 +55,39 @@ static int ap806_syscon_clk_probe(struct platform_device *pdev)
freq_mode = reg & AP806_SAR_CLKFREQ_MODE_MASK;
switch (freq_mode) {
- case 0x0 ... 0x5:
+ case 0x0:
+ case 0x1:
cpuclk_freq = 2000;
break;
- case 0x6 ... 0xB:
+ case 0x6:
+ case 0x7:
cpuclk_freq = 1800;
break;
- case 0xC ... 0x11:
+ case 0x4:
+ case 0xB:
+ case 0xD:
cpuclk_freq = 1600;
break;
- case 0x12 ... 0x16:
+ case 0x1a:
cpuclk_freq = 1400;
break;
- case 0x17 ... 0x19:
+ case 0x14:
+ case 0x17:
cpuclk_freq = 1300;
break;
+ case 0x19:
+ cpuclk_freq = 1200;
+ break;
+ case 0x13:
+ case 0x1d:
+ cpuclk_freq = 1000;
+ break;
+ case 0x1c:
+ cpuclk_freq = 800;
+ break;
+ case 0x1b:
+ cpuclk_freq = 600;
+ break;
default:
dev_err(&pdev->dev, "invalid SAR value\n");
return -EINVAL;
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: print bad_frame in handle_signal
From: bamvor.zhangjian at huawei.com @ 2016-12-22 11:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Sometims handle_signal will fail due to the bad frame and send to
segfault to process consequently. But there is no information in system
log which lead to hard to debug the root issue.
This patch add as same bad frame print as sys_rt_sigreturn.
Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org>
---
arch/arm64/kernel/signal.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index c7b6de6..cd6b81b 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -316,6 +316,10 @@ static void handle_signal(struct ksignal *ksig, struct pt_regs *regs)
if (!ret)
user_fastforward_single_step(tsk);
+ if (show_unhandled_signals)
+ pr_info_ratelimited("%s[%d]: bad frame in %s: pc=%08llx sp=%08llx\n",
+ current->comm, task_pid_nr(current),
+ __func__, regs->pc, regs->sp);
signal_setup_done(ret, ksig, 0);
}
--
2.10.2
^ permalink raw reply related
* [PATCH v4 00/12] mmc: Add support to Marvell Xenon SD Host Controller
From: Russell King - ARM Linux @ 2016-12-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.67d726f70f6bd48d38a2023513f2711080bc66c8.1481651244.git-series.gregory.clement@free-electrons.com>
On Tue, Dec 13, 2016 at 06:48:29PM +0100, Gregory CLEMENT wrote:
> This the forth version of the series adding support for the SDHCI
> Xenon controller. It can be currently found on the Armada 37xx and the
> Armada 7K/8K but will be also used in more Marvell SoC (and not only
> the mvebu ones actually).
With the problems and niggles fixed, it seems to work here on my 8040
board (along with dma-coherent):
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: SDHCI controller on f06e0000.sdhci [f06e0000.sdhci] using ADMA 64-bit
mmc0: new high speed MMC card at address 0001
mmcblk0: mmc0:0001 8GND3R 7.28 GiB
mmc1: SDHCI controller on f2780000.sdhci [f2780000.sdhci] using ADMA 64-bit
mmcblk0boot0: mmc0:0001 8GND3R partition 1 4.00 MiB
mmcblk0boot1: mmc0:0001 8GND3R partition 2 4.00 MiB
mmcblk0rpmb: mmc0:0001 8GND3R partition 3 512 KiB
mmc1: new high speed SDHC card at address 0001
mmcblk1: mmc1:0001 00000 14.6 GiB
mmcblk1: p1 p2 p3
Thanks.
--
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 v4 11/12] arm64: dts: marvell: add sdhci support for Armada 7K/8K
From: Russell King - ARM Linux @ 2016-12-22 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2564fe18eb9cc8a0a1a3311cdf7e7141f35211bd.1481651244.git-series.gregory.clement@free-electrons.com>
On Tue, Dec 13, 2016 at 06:48:40PM +0100, Gregory CLEMENT wrote:
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index 7b6136182ad0..181e8c5de3bf 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -229,6 +229,15 @@
>
> };
>
> + ap_sdhci0: sdhci at 6e0000 {
> + compatible = "marvell,armada-7000-sdhci";
> + reg = <0x6e0000 0x300>;
> + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "core";
> + clocks = <&cpm_syscon0 1 4>;
> + status = "disabled";
> + };
> +
> ap_syscon: system-controller at 6f4000 {
> compatible = "marvell,ap806-system-controller",
> "syscon";
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index e5e3ed678b6f..035b2b2fc9ca 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -164,6 +164,16 @@
> clocks = <&cpm_syscon0 1 21>;
> status = "disabled";
> };
> +
> + cpm_sdhci0: sdhci at 780000 {
> + compatible = "marvell,armada-7000-sdhci";
> + reg = <0x780000 0x300>;
> + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "core";
> + clocks = <&cpm_syscon0 1 4>;
> + status = "disabled";
> + };
> +
One other point - aren't the SDHCI interfaces dma-coherent on the AP806
and CP110?
--
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 v4 06/12] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Russell King - ARM Linux @ 2016-12-22 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8acb86f1e7977648977ed5c6b4eb86323e4b777.1481651244.git-series.gregory.clement@free-electrons.com>
On Tue, Dec 13, 2016 at 06:48:35PM +0100, Gregory CLEMENT wrote:
> +Optional Properties:
> +- mmc-card:
> + mmc-card child node must be provided when current SDHC is for eMMC.
> + Xenon SDHC often can support both SD and eMMC. This child node indicates that
> + current SDHC is for eMMC card. Thus Xenon eMMC specific configuration and
> + operations can be enabled prior to eMMC init sequence.
> + Please refer to Documentation/devicetree/bindings/mmc/mmc-card.txt.
> + This child node should not be set if current Xenon SDHC is for SD/SDIO.
This looks like a typo - shouldn't it be "mmccard" and not "mmc-card"?
Your examples below use "mmccard" as does the documentation you point
towards.
--
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 v4 11/12] arm64: dts: marvell: add sdhci support for Armada 7K/8K
From: Thomas Petazzoni @ 2016-12-22 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222104502.GV14217@n2100.armlinux.org.uk>
Hello,
On Thu, 22 Dec 2016 10:45:02 +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 13, 2016 at 06:48:40PM +0100, Gregory CLEMENT wrote:
> > diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> > index 7b6136182ad0..181e8c5de3bf 100644
> > --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> > +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> > @@ -229,6 +229,15 @@
> >
> > };
> >
> > + ap_sdhci0: sdhci at 6e0000 {
> > + compatible = "marvell,armada-7000-sdhci";
> > + reg = <0x6e0000 0x300>;
> > + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> > + clock-names = "core";
> > + clocks = <&cpm_syscon0 1 4>;
>
> This seems to be the wrong clock - how can the AP SDHCI core be connected
> to the CPM syscon (which is on a different die.)
Agreed. This cannot be the right clock.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 11/12] arm64: dts: marvell: add sdhci support for Armada 7K/8K
From: Russell King - ARM Linux @ 2016-12-22 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2564fe18eb9cc8a0a1a3311cdf7e7141f35211bd.1481651244.git-series.gregory.clement@free-electrons.com>
On Tue, Dec 13, 2016 at 06:48:40PM +0100, Gregory CLEMENT wrote:
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index e5e3ed678b6f..035b2b2fc9ca 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -164,6 +164,16 @@
> clocks = <&cpm_syscon0 1 21>;
> status = "disabled";
> };
> +
> + cpm_sdhci0: sdhci at 780000 {
> + compatible = "marvell,armada-7000-sdhci";
> + reg = <0x780000 0x300>;
> + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "core";
> + clocks = <&cpm_syscon0 1 4>;
> + status = "disabled";
> + };
> +
Oh, and a nitpick, since I've already commented on this patch - there's
a needless extra blank line here...
--
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 v4 11/12] arm64: dts: marvell: add sdhci support for Armada 7K/8K
From: Russell King - ARM Linux @ 2016-12-22 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2564fe18eb9cc8a0a1a3311cdf7e7141f35211bd.1481651244.git-series.gregory.clement@free-electrons.com>
On Tue, Dec 13, 2016 at 06:48:40PM +0100, Gregory CLEMENT wrote:
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index 7b6136182ad0..181e8c5de3bf 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -229,6 +229,15 @@
>
> };
>
> + ap_sdhci0: sdhci at 6e0000 {
> + compatible = "marvell,armada-7000-sdhci";
> + reg = <0x6e0000 0x300>;
> + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "core";
> + clocks = <&cpm_syscon0 1 4>;
This seems to be the wrong clock - how can the AP SDHCI core be connected
to the CPM syscon (which is on a different die.)
I think you first need a patch to add this clock to the AP syscon...
Thanks.
--
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
* [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID
From: Hans de Goede @ 2016-12-22 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64s08tey0ZevivFpxBk-dRjrApiyyh3mwYyVARHQV=Www@mail.gmail.com>
Hi,
On 22-12-16 11:31, Chen-Yu Tsai wrote:
> On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>>
>> On 19-12-16 17:06, Icenowy Zheng wrote:
>>>
>>>
>>>
>>> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>>>
>>>> Hi,
>>>>
>>>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>>> controller of H3 (incl. H2+).
>>>>>
>>>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>>
>>>>> Two read method of the H3 eFUSE is used in the BSP: by register
>>>>> accessing, or
>>>>> directly access 0x01c14200.
>>>>>
>>>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference
>>>>> between
>>>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2
>>>>> (in
>>>>> legacy kernel).
>>>>>
>>>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by
>>>>> the last
>>>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is
>>>>> H3,
>>>>> 0x58 is H3D (currently not known SoC) )
>>>>>
>>>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3,
>>>>> start
>>>>> with 0x02004620, which do not match this rule.
>>>>>
>>>>> The readout by devmem2 is satisfying this rule: their first word is
>>>>> 0x02c00081, matches H3.
>>>>>
>>>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>>> register operations. With this kind of code (I wrote one prototype in
>>>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e"
>>>>> on
>>>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel
>>>>> sid)
>>>>> And, after accessing to the SID by registers, the value of *0x01c14200
>>>>> become
>>>>> also "02c00081".
>>>>>
>>>>> With direct access to 0x01c14200 after boot with mainline kernel, I got
>>>>> also
>>>>> "02004620".
>>>>>
>>>>> Then I altered the program to do the register operations with
>>>>> sunxi-fel, the
>>>>> result is also "02c00081", and changed `sunxi-fel sid` result to
>>>>> "02c00081".
>>>>>
>>>>> Summary:
>>>>>
>>>>> +-----------------------------------------------+----------------+
>>>>> | Read situation | The first word |
>>>>> +-----------------------------------------------+----------------+
>>>>> | Direct read by sunxi-fel | 02004620 |
>>>>> | Direct read in mainline /dev/mem | 02004620 |
>>>>> | Direct read in legacy /dev/mem | 02c00081 |
>>>>> | Register access in FEL | 02c00081 |
>>>>> | Register access in mainline | 02c00081 |
>>>>> | Direct read after register access in FEL | 02c00081 |
>>>>> | Direct read after register access in mainline | 02c00081 |
>>>>> +-----------------------------------------------+----------------+
>>>>>
>>>>> According to some facts:
>>>>> - The register based access to SID is weird: it needs ~5 register
>>>>> operations per word of SID.
>>>>> - Reading via register access will change the value when reading by
>>>>> accessing
>>>>> 0x01c14200.
>>>>> - In the u-boot code[2] there's some functions which read out the SID
>>>>> by
>>>>> registers and then abandoned the value.
>>>>> - This mismatch do not exist on A64.
>>>>>
>>>>> I think that: Allwinner designed a "cache" to the SID to make the
>>>>> simplify the
>>>>> code to read it, and it automatically loaded the cache when booting;
>>>>> however,
>>>>> when doing first cache on H3, some byte shifts occured, and the value
>>>>> become
>>>>> wrong. A manual read on H3 can make the cache right again. This is a
>>>>> silicon
>>>>> bug, and fixed in A64.
>>>>>
>>>>> This raises a problem: currently many systems has used the misread SID
>>>>> value to
>>>>> generated lots of MAC addresses, and workaround this SID bug will
>>>>> change them.
>>>>>
>>>>> However, if this bug is not workarounded, the sun8i-ths driver won't
>>>>> work well
>>>>> (as some calibartion value lies in eFUSE). I think some early user of
>>>>> this
>>>>> driver has already experienced bad readout value.
>>>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>>
>>>>> And many wrong SID values have been generated by `sunxi-fel sid`.
>>>>> (Although I
>>>>> think sunxi-fel must have the workaround)
>>>>>
>>>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on
>>>>> H3/A64
>>>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>>
>>>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>>>
>>>>> [1]
>>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>>> [2]
>>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>>
>>>>> Experiments:
>>>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>>> A SID readout shell script via FEL with register access.
>>>>> - https://31.135.195.151:20281/d/efuse/
>>>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>>>> (with statically compiled binary)
>>>>
>>>>
>>>> Good detective work!
>>>>
>>>> I believe this would best be fixed by making u-boot use the register
>>>> access
>>>> method to get the SID on affected chips, and make sure u-boot reads the
>>>> SID at-least once.
>>>
>>>
>>> Yes.
>>>
>>> However, what I considered is that fixing this bug will change H3 devices'
>>> MAC addresses, as they are derived from SID.
>>
>>
>> I know, but I think we will just need to accept this onetime change
>> of the fixed MAC addresses to fix this bug. I don't think this is
>> a big problem since the driver for the H3 ethernet has not been
>> merged into the mainline kernel yet.
>
> Do we still need to do the CRC32 across the SID values to generate
> the MAC addresses?
Yes this does not change that a single word has not enough
randomness in it.
Regards,
Hans
^ permalink raw reply
* [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID
From: Chen-Yu Tsai @ 2016-12-22 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12fa0112-b0e2-21e0-f369-7372944153d5@redhat.com>
On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 19-12-16 17:06, Icenowy Zheng wrote:
>>
>>
>>
>> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>>
>>> Hi,
>>>
>>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>> controller of H3 (incl. H2+).
>>>>
>>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>
>>>> Two read method of the H3 eFUSE is used in the BSP: by register
>>>> accessing, or
>>>> directly access 0x01c14200.
>>>>
>>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference
>>>> between
>>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2
>>>> (in
>>>> legacy kernel).
>>>>
>>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by
>>>> the last
>>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is
>>>> H3,
>>>> 0x58 is H3D (currently not known SoC) )
>>>>
>>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3,
>>>> start
>>>> with 0x02004620, which do not match this rule.
>>>>
>>>> The readout by devmem2 is satisfying this rule: their first word is
>>>> 0x02c00081, matches H3.
>>>>
>>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>> register operations. With this kind of code (I wrote one prototype in
>>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e"
>>>> on
>>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel
>>>> sid)
>>>> And, after accessing to the SID by registers, the value of *0x01c14200
>>>> become
>>>> also "02c00081".
>>>>
>>>> With direct access to 0x01c14200 after boot with mainline kernel, I got
>>>> also
>>>> "02004620".
>>>>
>>>> Then I altered the program to do the register operations with
>>>> sunxi-fel, the
>>>> result is also "02c00081", and changed `sunxi-fel sid` result to
>>>> "02c00081".
>>>>
>>>> Summary:
>>>>
>>>> +-----------------------------------------------+----------------+
>>>> | Read situation | The first word |
>>>> +-----------------------------------------------+----------------+
>>>> | Direct read by sunxi-fel | 02004620 |
>>>> | Direct read in mainline /dev/mem | 02004620 |
>>>> | Direct read in legacy /dev/mem | 02c00081 |
>>>> | Register access in FEL | 02c00081 |
>>>> | Register access in mainline | 02c00081 |
>>>> | Direct read after register access in FEL | 02c00081 |
>>>> | Direct read after register access in mainline | 02c00081 |
>>>> +-----------------------------------------------+----------------+
>>>>
>>>> According to some facts:
>>>> - The register based access to SID is weird: it needs ~5 register
>>>> operations per word of SID.
>>>> - Reading via register access will change the value when reading by
>>>> accessing
>>>> 0x01c14200.
>>>> - In the u-boot code[2] there's some functions which read out the SID
>>>> by
>>>> registers and then abandoned the value.
>>>> - This mismatch do not exist on A64.
>>>>
>>>> I think that: Allwinner designed a "cache" to the SID to make the
>>>> simplify the
>>>> code to read it, and it automatically loaded the cache when booting;
>>>> however,
>>>> when doing first cache on H3, some byte shifts occured, and the value
>>>> become
>>>> wrong. A manual read on H3 can make the cache right again. This is a
>>>> silicon
>>>> bug, and fixed in A64.
>>>>
>>>> This raises a problem: currently many systems has used the misread SID
>>>> value to
>>>> generated lots of MAC addresses, and workaround this SID bug will
>>>> change them.
>>>>
>>>> However, if this bug is not workarounded, the sun8i-ths driver won't
>>>> work well
>>>> (as some calibartion value lies in eFUSE). I think some early user of
>>>> this
>>>> driver has already experienced bad readout value.
>>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>
>>>> And many wrong SID values have been generated by `sunxi-fel sid`.
>>>> (Although I
>>>> think sunxi-fel must have the workaround)
>>>>
>>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on
>>>> H3/A64
>>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>
>>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>>
>>>> [1]
>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>> [2]
>>>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>
>>>> Experiments:
>>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>> A SID readout shell script via FEL with register access.
>>>> - https://31.135.195.151:20281/d/efuse/
>>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>>> (with statically compiled binary)
>>>
>>>
>>> Good detective work!
>>>
>>> I believe this would best be fixed by making u-boot use the register
>>> access
>>> method to get the SID on affected chips, and make sure u-boot reads the
>>> SID at-least once.
>>
>>
>> Yes.
>>
>> However, what I considered is that fixing this bug will change H3 devices'
>> MAC addresses, as they are derived from SID.
>
>
> I know, but I think we will just need to accept this onetime change
> of the fixed MAC addresses to fix this bug. I don't think this is
> a big problem since the driver for the H3 ethernet has not been
> merged into the mainline kernel yet.
Do we still need to do the CRC32 across the SID values to generate
the MAC addresses?
ChenYu
>> Maybe we should add #ifdef's to MAC generation code after this fix.
>
>
> I would rather not see #ifdefs for this, see above, but that is no
> longer my call, see below.
>
>>
>> (This is why I will create this discussion)
>>
>> P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>> MAINTAINER file in board/sunxi indicates this.
>
>
> No I'm no longer the maintainer, I'm still the MAINTAINER file because
> I have a lot of boards and as such I'm still the point of contact for
> those boards (if there are any board specific issues / questions), but
> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
> is the maintainer now.
>
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
From: Heinrich Schuchardt @ 2016-12-22 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56869b90-6bee-f6ae-a7b1-884b4c0d72c0@baylibre.com>
On 12/14/2016 10:52 AM, Neil Armstrong wrote:
> Hi Heinrich,
>
> Thanks for testing and for the report,
> we are still struggling into finding what are these zones and how to label them correctly.
>
> We need to identify the zones on all boards, the patch I provided works on a non-odroid-c2 and gxm and gxl boards.
>
> Neil
>
Hello Neil,
the configuration below works for me on the Hardkernel Odroid C2.
ramoops is needed for CONFIG_PSTORE_RAM.
Debian Stretch has CONFIG_PSTORE_RAM=m. Same is true for Fedora.
I have chosen the address arbitrarily. To accommodate 512 MB boards we
would have to put it below 0x20000000.
The size parameters are the same as in hisilicon/hi6220-hikey.dts and
qcom-apq8064-asus-nexus7-flo.dts.
linux,cma is used for contiguous memory assignment. I have taken the
align parameter from arm-src-kernel-2016-08-18-26e194264c.tar.gz
provided by Amlogic at
http://openlinux.amlogic.com:8000/download/ARM/kernel/ .
See Documentation/DMA-API.txt for the usage of align.
They use the same value 0x400000 for all GXBB boards.
So we want to put this zone into meson-gxbb.dtsi.
secmon is used by drivers/firmware/meson/meson_sm.c.
Amlogic uses the same address range for all 64bit boards.
memory at 0 {
device_type = "memory";
linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
reserved-memory {
#address-cells = <0x2>;
#size-cells = <0x2>;
ranges;
ramoops at 0x23f00000 {
compatible = "ramoops";
reg = <0x0 0x23f00000 0x0 0x100000>;
record-size = <0x20000>;
console-size = <0x20000>;
ftrace-size = <0x20000>;
};
secmon: secmon {
compatible = "amlogic, aml_secmon_memory";
reg = <0x0 0x10000000 0x0 0x200000>;
no-map;
};
linux,cma {
compatible = "shared-dma-pool";
reusable;
size = <0x0 0xbc00000>;
alignment = <0x0 0x400000>;
linux,cma-default;
};
};
Best regards
Heinrich Schuchardt
^ permalink raw reply
* [PATCH v2] ARM: dts: turris-omnia: add support for ethernet switch
From: Uwe Kleine-König @ 2016-12-22 9:43 UTC (permalink / raw)
To: linux-arm-kernel
The Turris Omnia features a Marvell MV88E7176 ethernet switch. Add it to
the dts.
Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---
Changes since (implicit) v1:
- drop mdio bus and per port phy-handle as they match the default
setup.
One thing I was surprised is that the mv88e6xxx module isn't autoloaded
by udev. Is this expected?
Best regards
Uwe
arch/arm/boot/dts/armada-385-turris-omnia.dts | 66 ++++++++++++++++++++++++++-
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
index ab49acb2d452..f8e55fa7f0fa 100644
--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -122,7 +122,7 @@
pinctrl-names = "default";
pinctrl-0 = <&ge0_rgmii_pins>;
status = "okay";
- phy-mode = "rgmii-id";
+ phy-mode = "rgmii";
fixed-link {
speed = <1000>;
@@ -135,7 +135,7 @@
pinctrl-names = "default";
pinctrl-0 = <&ge1_rgmii_pins>;
status = "okay";
- phy-mode = "rgmii-id";
+ phy-mode = "rgmii";
fixed-link {
speed = <1000>;
@@ -274,6 +274,68 @@
};
/* Switch MV88E7176 at address 0x10 */
+ switch at 10 {
+ compatible = "marvell,mv88e6085";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dsa,member = <0 0>;
+
+ reg = <0x10>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports at 0 {
+ reg = <0>;
+ label = "lan0";
+ };
+
+ ports at 1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ ports at 2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ ports at 3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+ ports at 4 {
+ reg = <4>;
+ label = "lan4";
+ };
+
+ ports at 5 {
+ reg = <5>;
+ label = "cpu";
+ ethernet = <ð1>;
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ ports at 6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <ð0>;
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
};
&pinctrl {
--
2.11.0
^ permalink raw reply related
* [PATCH] mm: pmd dirty emulation in page fault handler
From: Kirill A. Shutemov @ 2016-12-22 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482364101-16204-1-git-send-email-minchan@kernel.org>
On Thu, Dec 22, 2016 at 08:48:21AM +0900, Minchan Kim wrote:
> Andreas reported [1] made a test in jemalloc hang in THP mode in arm64.
I guess you wanted put b8d3c4c3009d before [1], right?
> http://lkml.kernel.org/r/mvmmvfy37g1.fsf at hawking.suse.de
>
> The problem is page fault handler supports only accessed flag emulation
> for THP page of SW-dirty/accessed architecture.
>
> This patch enables dirty-bit emulation for those architectures.
> Without it, MADV_FREE makes application hang by repeated fault forever.
>
> [1] mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called
>
> Cc: Jason Evans <je@fb.com>
> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: linux-arch at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: <stable@vger.kernel.org> [4.5+]
> Fixes: b8d3c4c3009d ("mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called")
> Reported-by: Andreas Schwab <schwab@suse.de>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> ---
> mm/huge_memory.c | 6 ++++--
> mm/memory.c | 18 ++++++++++--------
> 2 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 10eedbf..29ec8a4 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -883,15 +883,17 @@ void huge_pmd_set_accessed(struct vm_fault *vmf, pmd_t orig_pmd)
> {
> pmd_t entry;
> unsigned long haddr;
> + bool write = vmf->flags & FAULT_FLAG_WRITE;
>
> vmf->ptl = pmd_lock(vmf->vma->vm_mm, vmf->pmd);
> if (unlikely(!pmd_same(*vmf->pmd, orig_pmd)))
> goto unlock;
>
> entry = pmd_mkyoung(orig_pmd);
> + if (write)
> + entry = pmd_mkdirty(entry);
> haddr = vmf->address & HPAGE_PMD_MASK;
> - if (pmdp_set_access_flags(vmf->vma, haddr, vmf->pmd, entry,
> - vmf->flags & FAULT_FLAG_WRITE))
> + if (pmdp_set_access_flags(vmf->vma, haddr, vmf->pmd, entry, write))
> update_mmu_cache_pmd(vmf->vma, vmf->address, vmf->pmd);
>
> unlock:
> diff --git a/mm/memory.c b/mm/memory.c
> index 36c774f..7408ddc 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3637,18 +3637,20 @@ static int __handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> if (pmd_protnone(orig_pmd) && vma_is_accessible(vma))
> return do_huge_pmd_numa_page(&vmf, orig_pmd);
>
> - if ((vmf.flags & FAULT_FLAG_WRITE) &&
> - !pmd_write(orig_pmd)) {
> - ret = wp_huge_pmd(&vmf, orig_pmd);
> - if (!(ret & VM_FAULT_FALLBACK))
> + if (vmf.flags & FAULT_FLAG_WRITE) {
> + if (!pmd_write(orig_pmd)) {
> + ret = wp_huge_pmd(&vmf, orig_pmd);
> + if (ret == VM_FAULT_FALLBACK)
In theory, more than one flag can be set and it would lead to
false-negative. Bit check was the right thing.
And I don't understand why do you need to change code in
__handle_mm_fault() at all.
>From what I see change to huge_pmd_set_accessed() should be enough.
> + goto pte_fault;
> return ret;
> - } else {
> - huge_pmd_set_accessed(&vmf, orig_pmd);
> - return 0;
> + }
> }
> +
> + huge_pmd_set_accessed(&vmf, orig_pmd);
> + return 0;
> }
> }
> -
> +pte_fault:
> return handle_pte_fault(&vmf);
> }
>
> --
> 2.7.4
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Ming Lei @ 2016-12-22 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478576829-112707-2-git-send-email-yuanzhichang@hisilicon.com>
Hi Guys,
On Tue, Nov 8, 2016 at 11:47 AM, zhichang.yuan
<yuanzhichang@hisilicon.com> wrote:
> For arm64, there is no I/O space as other architectural platforms, such as
> X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
> such as Hip06, when accessing some legacy ISA devices connected to LPC, those
> known port addresses are used to control the corresponding target devices, for
> example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
> normal MMIO mode in using.
>
> To drive these devices, this patch introduces a method named indirect-IO.
> In this method the in/out pair in arch/arm64/include/asm/io.h will be
> redefined. When upper layer drivers call in/out with those known legacy port
> addresses to access the peripherals, the hooking functions corrresponding to
> those target peripherals will be called. Through this way, those upper layer
> drivers which depend on in/out can run on Hip06 without any changes.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> ---
> arch/arm64/Kconfig | 6 +++
> arch/arm64/include/asm/extio.h | 94 ++++++++++++++++++++++++++++++++++++++++++
> arch/arm64/include/asm/io.h | 29 +++++++++++++
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/extio.c | 27 ++++++++++++
> 5 files changed, 157 insertions(+)
When I applied these three patches against current linus tree and
enable CONFIG_HISILICON_LPC, the following build failure[1] is
triggered when running 'make modules'.
Thanks,
Ming
[1] 'make modules' failure log
Building modules, stage 2.
MODPOST 2260 modules
ERROR: "inb" [drivers/watchdog/wdt_pci.ko] undefined!
ERROR: "outb" [drivers/watchdog/wdt_pci.ko] undefined!
ERROR: "outb" [drivers/watchdog/pcwd_pci.ko] undefined!
ERROR: "inb" [drivers/watchdog/pcwd_pci.ko] undefined!
ERROR: "outw" [drivers/video/vgastate.ko] undefined!
ERROR: "outb" [drivers/video/vgastate.ko] undefined!
ERROR: "inb" [drivers/video/vgastate.ko] undefined!
ERROR: "outw" [drivers/video/fbdev/vt8623fb.ko] undefined!
ERROR: "inb" [drivers/video/fbdev/vt8623fb.ko] undefined!
ERROR: "outb" [drivers/video/fbdev/vt8623fb.ko] undefined!
ERROR: "outw" [drivers/video/fbdev/tridentfb.ko] undefined!
ERROR: "inb" [drivers/video/fbdev/tridentfb.ko] undefined!
ERROR: "outb" [drivers/video/fbdev/tridentfb.ko] undefined!
ERROR: "inb" [drivers/video/fbdev/tdfxfb.ko] undefined!
.....
ERROR: "inb" [drivers/ata/pata_cmd64x.ko] undefined!
ERROR: "inb" [drivers/ata/pata_artop.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1196: recipe for target 'modules' failed
make: *** [modules] Error 2
> create mode 100644 arch/arm64/include/asm/extio.h
> create mode 100644 arch/arm64/kernel/extio.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 969ef88..b44070b 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -163,6 +163,12 @@ config ARCH_MMAP_RND_COMPAT_BITS_MIN
> config ARCH_MMAP_RND_COMPAT_BITS_MAX
> default 16
>
> +config ARM64_INDIRECT_PIO
> + bool "access peripherals with legacy I/O port"
> + help
> + Support special accessors for ISA I/O devices. This is needed for
> + SoCs that do not support standard read/write for the ISA range.
> +
> config NO_IOPORT_MAP
> def_bool y if !PCI
>
> diff --git a/arch/arm64/include/asm/extio.h b/arch/arm64/include/asm/extio.h
> new file mode 100644
> index 0000000..6ae0787
> --- /dev/null
> +++ b/arch/arm64/include/asm/extio.h
> @@ -0,0 +1,94 @@
> +/*
> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __LINUX_EXTIO_H
> +#define __LINUX_EXTIO_H
> +
> +struct extio_ops {
> + unsigned long start;/* inclusive, sys io addr */
> + unsigned long end;/* inclusive, sys io addr */
> +
> + u64 (*pfin)(void *devobj, unsigned long ptaddr, size_t dlen);
> + void (*pfout)(void *devobj, unsigned long ptaddr, u32 outval,
> + size_t dlen);
> + u64 (*pfins)(void *devobj, unsigned long ptaddr, void *inbuf,
> + size_t dlen, unsigned int count);
> + void (*pfouts)(void *devobj, unsigned long ptaddr,
> + const void *outbuf, size_t dlen,
> + unsigned int count);
> + void *devpara;
> +};
> +
> +extern struct extio_ops *arm64_extio_ops;
> +
> +#define DECLARE_EXTIO(bw, type) \
> +extern type in##bw(unsigned long addr); \
> +extern void out##bw(type value, unsigned long addr); \
> +extern void ins##bw(unsigned long addr, void *buffer, unsigned int count);\
> +extern void outs##bw(unsigned long addr, const void *buffer, unsigned int count);
> +
> +#define BUILD_EXTIO(bw, type) \
> +type in##bw(unsigned long addr) \
> +{ \
> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> + arm64_extio_ops->end < addr) \
> + return read##bw(PCI_IOBASE + addr); \
> + return arm64_extio_ops->pfin ? \
> + arm64_extio_ops->pfin(arm64_extio_ops->devpara, \
> + addr, sizeof(type)) : -1; \
> +} \
> + \
> +void out##bw(type value, unsigned long addr) \
> +{ \
> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> + arm64_extio_ops->end < addr) \
> + write##bw(value, PCI_IOBASE + addr); \
> + else \
> + if (arm64_extio_ops->pfout) \
> + arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> + addr, value, sizeof(type)); \
> +} \
> + \
> +void ins##bw(unsigned long addr, void *buffer, unsigned int count) \
> +{ \
> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> + arm64_extio_ops->end < addr) \
> + reads##bw(PCI_IOBASE + addr, buffer, count); \
> + else \
> + if (arm64_extio_ops->pfins) \
> + arm64_extio_ops->pfins(arm64_extio_ops->devpara,\
> + addr, buffer, sizeof(type), count); \
> +} \
> + \
> +void outs##bw(unsigned long addr, const void *buffer, unsigned int count) \
> +{ \
> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> + arm64_extio_ops->end < addr) \
> + writes##bw(PCI_IOBASE + addr, buffer, count); \
> + else \
> + if (arm64_extio_ops->pfouts) \
> + arm64_extio_ops->pfouts(arm64_extio_ops->devpara,\
> + addr, buffer, sizeof(type), count); \
> +}
> +
> +static inline void arm64_set_extops(struct extio_ops *ops)
> +{
> + if (ops)
> + WRITE_ONCE(arm64_extio_ops, ops);
> +}
> +
> +#endif /* __LINUX_EXTIO_H*/
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 0bba427..136735d 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -31,6 +31,7 @@
> #include <asm/early_ioremap.h>
> #include <asm/alternative.h>
> #include <asm/cpufeature.h>
> +#include <asm/extio.h>
>
> #include <xen/xen.h>
>
> @@ -149,6 +150,34 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> #define IO_SPACE_LIMIT (PCI_IO_SIZE - 1)
> #define PCI_IOBASE ((void __iomem *)PCI_IO_START)
>
> +
> +/*
> + * redefine the in(s)b/out(s)b for indirect-IO.
> + */
> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> +#define inb inb
> +#define outb outb
> +#define insb insb
> +#define outsb outsb
> +/* external declaration */
> +DECLARE_EXTIO(b, u8)
> +
> +#define inw inw
> +#define outw outw
> +#define insw insw
> +#define outsw outsw
> +
> +DECLARE_EXTIO(w, u16)
> +
> +#define inl inl
> +#define outl outl
> +#define insl insl
> +#define outsl outsl
> +
> +DECLARE_EXTIO(l, u32)
> +#endif
> +
> +
> /*
> * String version of I/O memory access operations.
> */
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 7d66bba..60e0482 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -31,6 +31,7 @@ arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
> sys_compat.o entry32.o
> arm64-obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o entry-ftrace.o
> arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
> +arm64-obj-$(CONFIG_ARM64_INDIRECT_PIO) += extio.o
> arm64-obj-$(CONFIG_ARM64_MODULE_PLTS) += module-plts.o
> arm64-obj-$(CONFIG_PERF_EVENTS) += perf_regs.o perf_callchain.o
> arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
> new file mode 100644
> index 0000000..647b3fa
> --- /dev/null
> +++ b/arch/arm64/kernel/extio.c
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/io.h>
> +
> +struct extio_ops *arm64_extio_ops;
> +
> +
> +BUILD_EXTIO(b, u8)
> +
> +BUILD_EXTIO(w, u16)
> +
> +BUILD_EXTIO(l, u32)
> --
> 1.9.1
>
--
Ming Lei
^ permalink raw reply
* How to remove warn msg "cache: parent cpui should not be sleeping" i=1, 2, 3...
From: Jisheng Zhang @ 2016-12-22 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a793d088-2faf-3ea8-41b6-f0b614a71e19@arm.com>
On Wed, 21 Dec 2016 16:54:22 +0000 Sudeep Holla wrote:
> On 21/12/16 11:37, Jisheng Zhang wrote:
> > Hi all,
> >
> > I'm not sure this is a bug, when wake up from s2ram, I could get something
> > like:
> >
> > [ 313.271464] Enabling non-boot CPUs ...
> > [ 313.271551] CPU1: Booted secondary processor
> > [ 313.271556] Detected VIPT I-cache on CPU1
> > [ 313.301378] cache: parent cpu1 should not be sleeping
> > [ 313.301504] CPU1 is up
> > [ 313.301582] CPU2: Booted secondary processor
> > [ 313.301585] Detected VIPT I-cache on CPU2
> > [ 313.331485] cache: parent cpu2 should not be sleeping
> > [ 313.331605] CPU2 is up
> > [ 313.331683] CPU3: Booted secondary processor
> > [ 313.331686] Detected VIPT I-cache on CPU3
> > [ 313.361599] cache: parent cpu3 should not be sleeping
> > [ 313.361719] CPU3 is up
> >
> > This is because we call cpu_device_create() when secondary cpu is brought
> > online, the cpu_cache device's parent device: cpu device isn't already
> > resumed, all device resume will resume after secondary cores are brought
> > up.
> >
> > What's the elegant solution to remove this warning msg?
> >
>
> It is not a serious warning as you can see a comment in the code:
> "/*
> * This is a fib. But we'll allow new children to be added below
> * a resumed device, even if the device hasn't been completed yet.
> */"
>
Great, make sense, I agree with "this is not a serious warn msg".
Thanks for the help,
Jisheng
> But if we think it needs to be removed, I have something like below in
> my mind. I am not sure if this is hacky or not(completely untested, not
> even compiled).
>
> Regards,
> Sudeep
>
> -->8
>
> diff --git i/drivers/base/cpu.c w/drivers/base/cpu.c
> index 4c28e1a09786..2a5c04377adf 100644
> --- i/drivers/base/cpu.c
> +++ w/drivers/base/cpu.c
> @@ -344,6 +344,14 @@ static int cpu_uevent(struct device *dev, struct
> kobj_uevent_env *env)
> }
> #endif
>
> +static int cpu_dev_pm_unset_is_prepared(unsigned int cpu)
> +{
> + struct device *cpu_dev = get_cpu_device(cpu);
> +
> + if(cpu_dev)
> + cpu_dev->power.is_prepared = false;
> + return 0;
> +}
> /*
> * register_cpu - Setup a sysfs device for a CPU.
> * @cpu - cpu->hotpluggable field set to 1 will generate a control file in
> @@ -377,7 +385,9 @@ int register_cpu(struct cpu *cpu, int num)
> per_cpu(cpu_sys_devices, num) = &cpu->dev;
> register_cpu_under_node(num, cpu_to_node(num));
>
> - return 0;
> + return cpuhp_setup_state_nocalls(CPUHP_CPUDEV_PM_PREPARE,
> + "base/cpu/dev_pm:prepare",
> + cpu_dev_pm_unset_is_prepared, NULL);
> }
>
> struct device *get_cpu_device(unsigned cpu)
> diff --git i/include/linux/cpuhotplug.h w/include/linux/cpuhotplug.h
> index 2ab7bf53d529..5bfe3c1aa148 100644
> --- i/include/linux/cpuhotplug.h
> +++ w/include/linux/cpuhotplug.h
> @@ -51,6 +51,7 @@ enum cpuhp_state {
> CPUHP_SLAB_PREPARE,
> CPUHP_MD_RAID5_PREPARE,
> CPUHP_RCUTREE_PREP,
> + CPUHP_CPUDEV_PM_PREPARE,
> CPUHP_CPUIDLE_COUPLED_PREPARE,
> CPUHP_POWERPC_PMAC_PREPARE,
> CPUHP_POWERPC_MMU_CTX_PREPARE,
^ permalink raw reply
* [PATCH] ARM64: zynqmp: Fix i2c node's compatible string
From: Michal Simek @ 2016-12-22 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482385788-7187-1-git-send-email-moritz.fischer@ettus.com>
On 22.12.2016 06:49, Moritz Fischer wrote:
> From: Moritz Fischer <mdf@kernel.org>
>
> The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core
> which fixes some silicon bugs that needed software workarounds
> in Version 1.0 that was used on Zynq systems.
>
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: U-Boot List <u-boot@lists.denx.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> ---
>
> Hi Michal,
>
> I think this is a slip up and should be r1p14 for
> Ultrascale ZynqMP. drivers/i2c/i2c-cadence.c already uses this.
> I Cc'd the u-boot list, because the same change would be required there.
>
> Cheers,
>
> Moritz
>
> ---
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> index 68a90833..a5a5f91 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> @@ -175,7 +175,7 @@
> };
>
> i2c0: i2c at ff020000 {
> - compatible = "cdns,i2c-r1p10";
> + compatible = "cdns,i2c-r1p14";
I was checking this internally and p10 is doing something what p14
doesn't need to do. That's why this should be
compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
The same of course for u-boot where also p14 should be added to the driver.
Thanks,
Michal
^ permalink raw reply
* hi
From: Ellis Andrew @ 2016-12-22 7:20 UTC (permalink / raw)
To: linux-arm-kernel
Good afternoon
http://oknaprozivot.cz/wp-content/uploads/eop/thank-you.php?well=q21v8dtggf8r3b
Ellis Andrew
^ permalink raw reply
* [PATCH 3/3] dma: zx: fix residue calculation
From: Jun Nie @ 2016-12-22 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481810617-7650-3-git-send-email-shawnguo@kernel.org>
2016-12-15 22:03 GMT+08:00 Shawn Guo <shawnguo@kernel.org>:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> The dma residue is defined as the free space to end of transfer buffer,
> which could be multiple segments chained together. So the residue
> calculation in zx_dma_tx_status() works for both slave_sg and cyclic
> case. But unfortunately, the 'index' is wrong. It should plus one,
> because the current segment is already occupied and shouldn't be counted
> into free space.
>
> This fixes the HDMI audio noise issue we see on ZX296718 with SPDIF
> interface.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> drivers/dma/zx_dma.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
^ permalink raw reply
* [PATCH 1/2] arm64: setup: introduce kaslr_offset()
From: Yury Norov @ 2016-12-22 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481417456-28826-2-git-send-email-alex.popov@linux.com>
On Sun, Dec 11, 2016 at 03:50:55AM +0300, Alexander Popov wrote:
> Introduce kaslr_offset() similarly to x86_64 for fixing kcov.
>
> Signed-off-by: Alexander Popov <alex.popov@linux.com>
> ---
> arch/arm64/include/asm/setup.h | 19 +++++++++++++++++++
> arch/arm64/include/uapi/asm/setup.h | 4 ++--
> arch/arm64/kernel/setup.c | 8 ++++----
> 3 files changed, 25 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm64/include/asm/setup.h
>
> diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
> new file mode 100644
> index 0000000..e7b59b9
> --- /dev/null
> +++ b/arch/arm64/include/asm/setup.h
> @@ -0,0 +1,19 @@
> +/*
> + * arch/arm64/include/asm/setup.h
> + *
> + * 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.
> + */
> +
> +#ifndef __ASM_SETUP_H
> +#define __ASM_SETUP_H
> +
> +#include <uapi/asm/setup.h>
> +
> +static inline unsigned long kaslr_offset(void)
> +{
> + return kimage_vaddr - KIMAGE_VADDR;
> +}
> +
> +#endif
Hi Alexander,
I found today's linux-next master broken:
In file included from init/main.c:88:0:
./arch/arm64/include/asm/setup.h:14:100: error: redefinition of ?kaslr_offset?
In file included from ./arch/arm64/include/asm/page.h:54:0,
from ./include/linux/mm_types.h:16,
from ./include/linux/sched.h:27,
from ./arch/arm64/include/asm/compat.h:25,
from ./arch/arm64/include/asm/stat.h:23,
from ./include/linux/stat.h:5,
from ./include/linux/module.h:10,
from init/main.c:15:
/arch/arm64/include/asm/memory.h:168:100: note: previous definition of ?kaslr_offset? was here scripts/Makefile.build:293: recipe for target 'init/main.o' failed
make[1]: *** [init/main.o] Error 1
It looks like you declare kaslr_offset() twice - in this patch, and in 7ede8665f
(arm64: setup: introduce kaslr_offset()).
Yury
^ permalink raw reply
* [PATCH 2/3] dma: zx: set DMA_CYCLIC cap_mask bit
From: Jun Nie @ 2016-12-22 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481810617-7650-2-git-send-email-shawnguo@kernel.org>
2016-12-15 22:03 GMT+08:00 Shawn Guo <shawnguo@kernel.org>:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> The zx_dma driver supports cyclic transfer mode. Let's set DMA_CYCLIC
> cap_mask bit to make that clear, and avoid unnecessary failure when
> clients request channel via dma_request_chan_by_mask() with DMA_CYCLIC
> bit set in mask.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> drivers/dma/zx_dma.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
^ permalink raw reply
* [PATCH 1/3] dma: zx: rename zx296702_dma.c to zx_dma.c
From: Jun Nie @ 2016-12-22 6:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481810617-7650-1-git-send-email-shawnguo@kernel.org>
2016-12-15 22:03 GMT+08:00 Shawn Guo <shawnguo@kernel.org>:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> ZTE ZX dma driver is not ZX296702 specific. It works for not only
> ZX296702 but also other ZTE ZX family platforms like ZX296718. Let's
> rename the file to reflect that.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> drivers/dma/Kconfig | 4 ++--
> drivers/dma/Makefile | 2 +-
> drivers/dma/{zx296702_dma.c => zx_dma.c} | 0
> 3 files changed, 3 insertions(+), 3 deletions(-)
> rename drivers/dma/{zx296702_dma.c => zx_dma.c} (100%)
>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
^ permalink raw reply
* [PATCH] ARM64: zynqmp: Fix i2c node's compatible string
From: Moritz Fischer @ 2016-12-22 5:49 UTC (permalink / raw)
To: linux-arm-kernel
From: Moritz Fischer <mdf@kernel.org>
The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core
which fixes some silicon bugs that needed software workarounds
in Version 1.0 that was used on Zynq systems.
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
Cc: U-Boot List <u-boot@lists.denx.de>
Cc: Rob Herring <robh+dt@kernel.org>
---
Hi Michal,
I think this is a slip up and should be r1p14 for
Ultrascale ZynqMP. drivers/i2c/i2c-cadence.c already uses this.
I Cc'd the u-boot list, because the same change would be required there.
Cheers,
Moritz
---
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 68a90833..a5a5f91 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -175,7 +175,7 @@
};
i2c0: i2c at ff020000 {
- compatible = "cdns,i2c-r1p10";
+ compatible = "cdns,i2c-r1p14";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 17 4>;
@@ -185,7 +185,7 @@
};
i2c1: i2c at ff030000 {
- compatible = "cdns,i2c-r1p10";
+ compatible = "cdns,i2c-r1p14";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 18 4>;
--
2.4.11
^ permalink raw reply related
* [PATCH v5 14/14] irqchip: mbigen: Add ACPI support
From: Hanjun Guo @ 2016-12-22 5:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-1-git-send-email-guohanjun@huawei.com>
From: Hanjun Guo <hanjun.guo@linaro.org>
With the preparation of platform msi support and interrupt producer
in DSDT, we can add mbigen ACPI support now.
We are using _PRS methd to indicate number of irq pins instead
of num_pins in DT to avoid _DSD usage in this case.
For mbi-gen,
Device(MBI0) {
Name(_HID, "HISI0152")
Name(_UID, Zero)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
})
Name (_PRS, ResourceTemplate() {
Interrupt(ResourceProducer,...) {12,14,....}
})
}
For devices,
Device(COM0) {
Name(_HID, "ACPIIDxx")
Name(_UID, Zero)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
})
}
With the helpe of platform msi and interrupt producer, then devices
will get the virq from mbi-gen's irqdomain.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ma Jun <majun258@huawei.com>
---
drivers/irqchip/irq-mbigen.c | 70 ++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 67 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4e11da5..17d35fa 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -16,6 +16,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/interrupt.h>
#include <linux/irqchip.h>
#include <linux/module.h>
@@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
unsigned long *hwirq,
unsigned int *type)
{
- if (is_of_node(fwspec->fwnode)) {
+ if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
if (fwspec->param_count != 2)
return -EINVAL;
@@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,
return 0;
}
+#ifdef CONFIG_ACPI
+static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
+ void *context)
+{
+ struct acpi_resource_extended_irq *ext_irq;
+ u32 *num_irqs = context;
+
+ switch (ares->type) {
+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ ext_irq = &ares->data.extended_irq;
+ *num_irqs += ext_irq->interrupt_count;
+ break;
+ default:
+ break;
+ }
+
+ return AE_OK;
+}
+
+static int mbigen_acpi_create_domain(struct platform_device *pdev,
+ struct mbigen_device *mgn_chip)
+{
+ struct irq_domain *domain;
+ u32 num_msis = 0;
+ acpi_status status;
+
+ status = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), METHOD_NAME__PRS,
+ mbigen_acpi_process_resource, &num_msis);
+ if (ACPI_FAILURE(status) || num_msis == 0)
+ return -EINVAL;
+
+ domain = platform_msi_create_device_domain(&pdev->dev, num_msis,
+ mbigen_write_msg,
+ &mbigen_domain_ops,
+ mgn_chip);
+ if (!domain)
+ return -ENOMEM;
+
+ return 0;
+}
+#else
+static int mbigen_acpi_create_domain(struct platform_device *pdev,
+ struct mbigen_device *mgn_chip)
+{
+ return -ENODEV;
+}
+#endif
+
static int mbigen_device_probe(struct platform_device *pdev)
{
struct mbigen_device *mgn_chip;
@@ -288,9 +337,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
- err = mbigen_of_create_domain(pdev, mgn_chip);
- if (err)
+ if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
+ err = mbigen_of_create_domain(pdev, mgn_chip);
+ else if (ACPI_COMPANION(&pdev->dev))
+ err = mbigen_acpi_create_domain(pdev, mgn_chip);
+ else
+ err = -EINVAL;
+
+ if (err) {
+ dev_err(&pdev->dev, "Failed to create mbi-gen@%p irqdomain", mgn_chip->base);
return err;
+ }
platform_set_drvdata(pdev, mgn_chip);
return 0;
@@ -302,10 +359,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
};
MODULE_DEVICE_TABLE(of, mbigen_of_match);
+static const struct acpi_device_id mbigen_acpi_match[] = {
+ { "HISI0152", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
+
static struct platform_driver mbigen_platform_driver = {
.driver = {
.name = "Hisilicon MBIGEN-V2",
.of_match_table = mbigen_of_match,
+ .acpi_match_table = ACPI_PTR(mbigen_acpi_match),
},
.probe = mbigen_device_probe,
};
--
1.7.12.4
^ permalink raw reply related
* [PATCH v5 13/14] irqchip: mbigen: introduce mbigen_of_create_domain()
From: Hanjun Guo @ 2016-12-22 5:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-1-git-send-email-guohanjun@huawei.com>
From: Kefeng Wang <wangkefeng.wang@huawei.com>
Introduce mbigen_of_create_domain() to consolidate OF related
code and prepare for ACPI later, no funtional change.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ma Jun <majun258@huawei.com>
---
drivers/irqchip/irq-mbigen.c | 42 +++++++++++++++++++++++++++---------------
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index c01ab41..4e11da5 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -236,27 +236,15 @@ static int mbigen_irq_domain_alloc(struct irq_domain *domain,
.free = irq_domain_free_irqs_common,
};
-static int mbigen_device_probe(struct platform_device *pdev)
+static int mbigen_of_create_domain(struct platform_device *pdev,
+ struct mbigen_device *mgn_chip)
{
- struct mbigen_device *mgn_chip;
+ struct device *parent;
struct platform_device *child;
struct irq_domain *domain;
struct device_node *np;
- struct device *parent;
- struct resource *res;
u32 num_pins;
- mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
- if (!mgn_chip)
- return -ENOMEM;
-
- mgn_chip->pdev = pdev;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mgn_chip->base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(mgn_chip->base))
- return PTR_ERR(mgn_chip->base);
-
for_each_child_of_node(pdev->dev.of_node, np) {
if (!of_property_read_bool(np, "interrupt-controller"))
continue;
@@ -280,6 +268,30 @@ static int mbigen_device_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ return 0;
+}
+
+static int mbigen_device_probe(struct platform_device *pdev)
+{
+ struct mbigen_device *mgn_chip;
+ struct resource *res;
+ int err;
+
+ mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
+ if (!mgn_chip)
+ return -ENOMEM;
+
+ mgn_chip->pdev = pdev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (IS_ERR(mgn_chip->base))
+ return PTR_ERR(mgn_chip->base);
+
+ err = mbigen_of_create_domain(pdev, mgn_chip);
+ if (err)
+ return err;
+
platform_set_drvdata(pdev, mgn_chip);
return 0;
}
--
1.7.12.4
^ 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