* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Laurent Pinchart @ 2016-10-20 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7h8ttj6jqo.fsf@baylibre.com>
Hi Kevin,
On Thursday 20 Oct 2016 09:57:51 Kevin Hilman wrote:
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:
> > On Wednesday 19 Oct 2016 10:26:57 Bartosz Golaszewski wrote:
> >> 2016-10-18 22:49 GMT+02:00 Laurent Pinchart:
> >>> On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote:
> >>>> Create the driver for the da8xx System Configuration and implement
> >>>> support for writing to the three Master Priority registers.
> >>>>
> >>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >>
> >> [snip]
> >>
> >>>> +
> >>>> +Documentation:
> >>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> >>>> +
> >>>> +Required properties:
> >>>> +
> >>>> +- compatible: "ti,da850-syscfg"
> >>>
> >>> Don't you need a reg property ?
> >>
> >> Yes, Kevin already pointed that out. I'll add it in v2. Same for [1/3].
> >>
> >>>> +Optional properties:
> >>>> +
> >>>> +The below properties are used to specify the priority of master
> >>>> peripherals.
> >>>> +They must be between 0-7 where 0 is the highest priority and 7 is the
> >>>> lowest.
> >>>> +
> >>>> +- ti,pri-arm-i: ARM_I port priority.
> >>>> +
> >>>> +- ti,pri-arm-d: ARM_D port priority.
> >>>> +
> >>>> +- ti,pri-upp: uPP port priority.
> >>>> +
> >>>> +- ti,pri-sata: SATA port priority.
> >>>> +
> >>>> +- ti,pri-pru0: PRU0 port priority.
> >>>> +
> >>>> +- ti,pri-pru1: PRU1 port priority.
> >>>> +
> >>>> +- ti,pri-edma30tc0: EDMA3_0_TC0 port priority.
> >>>> +
> >>>> +- ti,pri-edma30tc1: EDMA3_0_TC1 port priority.
> >>>> +
> >>>> +- ti,pri-edma31tc0: EDMA3_1_TC0 port priority.
> >>>> +
> >>>> +- ti,pri-vpif-dma-0: VPIF DMA0 port priority.
> >>>> +
> >>>> +- ti,pri-vpif-dma-1: VPIF DMA1 port priority.
> >>>> +
> >>>> +- ti,pri-emac: EMAC port priority.
> >>>> +
> >>>> +- ti,pri-usb0cfg: USB0 CFG port priority.
> >>>> +
> >>>> +- ti,pri-usb0cdma: USB0 CDMA port priority.
> >>>> +
> >>>> +- ti,pri-uhpi: HPI port priority.
> >>>> +
> >>>> +- ti,pri-usb1: USB1 port priority.
> >>>> +
> >>>> +- ti,pri-lcdc: LCDC port priority.
> >>>
> >>> I'm afraid this looks more like system configuration than hardware
> >>> description to me.
> >>
> >> While you're certainly right, this approach is already implemented in
> >> several other memory and bus drivers and it was also suggested by
> >> Sekhar in one of the tilcdc rev1 threads. There's also no real
> >> alternative that I know of.
> >
> > The fact that other drivers get it wrong is no excuse for copying them :-)
>
> What exactly is "wrong" with the way other drivers are doing it?
>
> I'm sure there may be other ideas, and possibly some better ones, but
> that doesn't make it wrong, and doesn't change he fact that the kernel
> has existing drivers SoC-bus-specific system performance knobs like
> this.
It's not the drivers I'm concerned about, but the DT bindings. The proposed DT
binding contains a large number of properties that don't describe the hardware
but contain configuration data. If they're accepted you'll have to carry them
forward forever, while they should be controlled in a more flexible way.
> >>> There was a BoF session about how to support this kind of performance
> >>> knobs at ELCE last week:
> >>> https://openiotelceurope2016.sched.org/event/7rss/bof-linux-device-perf
> >>> ormance-framework-michael-turquette-baylibre :-)
> >>
> >> Unfortunately it was just a discussion about potential approaches -
> >> there's no code yet.
> >
> > Patches are welcome ;-)
>
> Any generic perf framework will have to build on the HW-specifics of
> individual busses, so IMO, the lack of a generic performance
> framework/knobs should not be a reason to block the inclusion of any
> bus-specific knobs.
>
> I guess this ultimately would go though arm-soc, so I've added Arnd &
> Olof to the thread.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 0/3] efi: add support for seeding the kernel RNG from UEFI
From: Kees Cook @ 2016-10-20 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476962486-18368-1-git-send-email-ard.biesheuvel@linaro.org>
On Thu, Oct 20, 2016 at 4:21 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> This implements generic EFI core kernel code to seed the kernel entropy
> pool from a Linux specific UEFI configuration table containing a random seed
> supplied by the firmware. (#1)
>
> In addition, it wires it up for ARM and arm64, by invoking the EFI_RNG_PROTOCOL
> UEFI protocol from the stub, and populating such a UEFI config table using its
> output.
Looks good to me! Now that I understand it. ;)
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* [PATCH 0/4] STM32F429: Add Ethernet fixes
From: David Miller @ 2016-10-20 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476976886-23781-1-git-send-email-alexandre.torgue@st.com>
From: Alexandre TORGUE <alexandre.torgue@st.com>
Date: Thu, 20 Oct 2016 17:21:22 +0200
> This series adds several fixes for Ethernet for stm32f429 MCU.
> First 2 patches have already been reviewed some months ago when
> stm32 Ethernet glue has been pushed (I added in this series to keep
> history). Fixes are:
> -Change DT to be compliant to stm32 ethernet glue binding
> -Add phy-handle to correctly use mdio subnode
> -Remove WoL support
I'm assuming this will be merged via the ARM tree.
^ permalink raw reply
* [PATCH v2] ARM: shmobile: Consolidate R8A7743 and R8A779[234] machine definitions
From: Sergei Shtylyov @ 2016-10-20 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020085804.GK4612@verge.net.au>
Hello.
On 10/20/2016 11:58 AM, Simon Horman wrote:
>> The four SoCs use identical machine operations, consolidate them into
>> two machine definitions in a single file.
>>
>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>> Tested-by: Simon Horman <horms+renesas@verge.net.au>
>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> Changes since v1:
>>
>> - Rebased on top of Simon's latest devel branch, thus including R8A7743
>> consolidation
>>
>> arch/arm/mach-shmobile/Makefile | 4 ----
>> arch/arm/mach-shmobile/setup-r8a7743.c | 34 -------------------------------
>> arch/arm/mach-shmobile/setup-r8a7792.c | 35 --------------------------------
>> arch/arm/mach-shmobile/setup-r8a7793.c | 33 ------------------------------
>> arch/arm/mach-shmobile/setup-r8a7794.c | 33 ------------------------------
>> arch/arm/mach-shmobile/setup-rcar-gen2.c | 33 ++++++++++++++++++++++++++++++
>> 6 files changed, 33 insertions(+), 139 deletions(-)
>> delete mode 100644 arch/arm/mach-shmobile/setup-r8a7743.c
>> delete mode 100644 arch/arm/mach-shmobile/setup-r8a7792.c
>> delete mode 100644 arch/arm/mach-shmobile/setup-r8a7793.c
>> delete mode 100644 arch/arm/mach-shmobile/setup-r8a7794.c
>
> Thanks for this Laurent, its a very nice diffstat.
> I have queued it up for v4.10.
I'm not seeing a new devel tag when fetching... :-(
MBR, Sergei
^ permalink raw reply
* [PATCH v4 6/9] clk: sunxi-ng: Add A64 clocks
From: Stephen Boyd @ 2016-10-20 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cd4dd81821b8910d40626baab2dbfdabd94b1b98.1476196031.git-series.maxime.ripard@free-electrons.com>
On 10/11, Maxime Ripard wrote:
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> new file mode 100644
> index 000000000000..c0e96bf6d104
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> +
> +static int sun50i_a64_ccu_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + void __iomem *reg;
> + u32 val;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + reg = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(reg)) {
> + dev_err(&pdev->dev, "Could not map the clock registers\n");
devm_ioremap_resource() should already spit out an error.
> + return PTR_ERR(reg);
> + }
> +
> + /* Force the PLL-Audio-1x divider to 4 */
> + val = readl(reg + SUN50I_A64_PLL_AUDIO_REG);
> + val &= ~GENMASK(19, 16);
> + writel(val | (3 << 16), reg + SUN50I_A64_PLL_AUDIO_REG);
> +
> + writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
> +
> + return sunxi_ccu_probe(pdev->dev.of_node, reg, &sun50i_a64_ccu_desc);
> +}
> +
> +static const struct of_device_id sun50i_a64_ccu_ids[] = {
> + { .compatible = "allwinner,sun50i-a64-ccu" },
> + { },
Nitpick: drop the comma
> +};
> +
> +static struct platform_driver sun50i_a64_ccu_driver = {
> + .probe = sun50i_a64_ccu_probe,
> + .driver = {
> + .name = "sun50i-a64-ccu",
> + .of_match_table = sun50i_a64_ccu_ids,
> + },
> +};
> +builtin_platform_driver(sun50i_a64_ccu_driver);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH -next] net: ethernet: mediatek: use dev_kfree_skb_any instead of dev_kfree_skb
From: David Miller @ 2016-10-20 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476982832-27932-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Thu, 20 Oct 2016 17:00:32 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Replace dev_kfree_skb with dev_kfree_skb_any in mtk_start_xmit()
> which can be called from hard irq context (netpoll) and from
> other contexts. mtk_start_xmit() only frees skbs that it has
> dropped.
>
> This is detected by Coccinelle semantic patch.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* [PATCH 1/4] arm64: dts: msm8996: Add SMEM reserve-memory node
From: Sarangdhar Joshi @ 2016-10-20 18:56 UTC (permalink / raw)
To: linux-arm-kernel
Add DT node to carveout memory for shared memory region.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index d6da223..36216ae 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -31,6 +31,17 @@
reg = <0 0 0 0>;
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ smem_mem: smem-mem at 86000000 {
+ reg = <0x0 0x86000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <2>;
#size-cells = <0>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: msm8996: Add reserve-memory nodes
From: Sarangdhar Joshi @ 2016-10-20 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476989765-7524-1-git-send-email-spjoshi@codeaurora.org>
Add reserve-memory nodes required for Qualcomm
Peripheral Image Loaders
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 36216ae..949b096 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -36,6 +36,31 @@
#size-cells = <2>;
ranges;
+ mba_region: mba at 91500000 {
+ reg = <0x0 0x91500000 0x0 0x200000>;
+ no-map;
+ };
+
+ slpi_region: slpi at 90b00000 {
+ reg = <0x0 0x90b00000 0xa00000>;
+ no-map;
+ };
+
+ venus_region: venus at 90400000 {
+ reg = <0x0 0x90400000 0x0 0x700000>;
+ no-map;
+ };
+
+ adsp_region: adsp at 8ea00000 {
+ reg = <0x0 0x8ea00000 0x0 0x1a00000>;
+ no-map;
+ };
+
+ mpss_region: mpss at 88800000 {
+ reg = <0x0 0x88800000 0x0 0x6200000>;
+ no-map;
+ };
+
smem_mem: smem-mem at 86000000 {
reg = <0x0 0x86000000 0x0 0x200000>;
no-map;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: msm8996: Add SMEM DT nodes
From: Sarangdhar Joshi @ 2016-10-20 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476989765-7524-1-git-send-email-spjoshi@codeaurora.org>
From: Bjorn Andersson <bjorn.andersson@linaro.org>
Add SMEM and TCSR DT nodes on MSM8996.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 949b096..0a810f5 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -169,12 +169,31 @@
method = "smc";
};
+ smem {
+ compatible = "qcom,smem";
+
+ memory-region = <&smem_mem>;
+
+ hwlocks = <&tcsr_mutex 3>;
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0 0xffffffff>;
compatible = "simple-bus";
+ tcsr_mutex_regs: syscon at 740000 {
+ compatible = "syscon";
+ reg = <0x740000 0x20000>;
+ };
+
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_regs 0 0x1000>;
+ #hwlock-cells = <1>;
+ };
+
intc: interrupt-controller at 9bc0000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: msm8996: Add SMP2P and APCS nodes
From: Sarangdhar Joshi @ 2016-10-20 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476989765-7524-1-git-send-email-spjoshi@codeaurora.org>
Add SMP2P and APCS DT nodes required for Qualcomm ADSP
Peripheral Image Loader.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 0a810f5..3edb56b 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -169,6 +169,31 @@
method = "smc";
};
+ smp2p-adsp {
+ compatible = "qcom,smp2p";
+ qcom,smem = <443>, <429>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <0 158 IRQ_TYPE_EDGE_RISING>;
+
+ qcom,ipc = <&apcs 16 10>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <2>;
+
+ adsp_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,state-cells = <1>;
+ };
+
+ adsp_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
smem {
compatible = "qcom,smem";
@@ -205,6 +230,11 @@
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
+ apcs: syscon at 9820000 {
+ compatible = "syscon";
+ reg = <0x9820000 0x1000>;
+ };
+
gcc: clock-controller at 300000 {
compatible = "qcom,gcc-msm8996";
#clock-cells = <1>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH V7 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Stefan Wahren @ 2016-10-20 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87twczg27x.fsf@eliezer.anholt.net>
> Eric Anholt <eric@anholt.net> hat am 28. September 2016 um 23:10 geschrieben:
>
>
> kernel at martin.sperl.org writes:
>
> > From: Martin Sperl <kernel@martin.sperl.org>
> >
> > Add basic thermal driver for bcm2835 SOC.
> >
> > This driver currently relies on the firmware setting up the
> > tsense HW block and does not set it up itself.
> >
> > Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
> > Acked-by: Eric Anholt <eric@anholt.net>
> > Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>
> What's the status of merging this one? I'd like to merge the other
> patches.
gently ping ...
^ permalink raw reply
* [PATCH] ARM: dts: armada-370-rn102: drop specification of compatible for i2c0
From: Uwe Kleine-König @ 2016-10-20 19:15 UTC (permalink / raw)
To: linux-arm-kernel
The compatible string is already provided by armada-370.dtsi.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,
this is the same as commit 43940ce3b089962f97de544d72b783bd146ef362 that
currently is in next, just for rn102 instead of rn104.
Best regards
Uwe
arch/arm/boot/dts/armada-370-netgear-rn102.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
index 39181b3fa90d..3ca6330a1752 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
@@ -120,7 +120,6 @@
};
i2c at 11000 {
- compatible = "marvell,mv64xxx-i2c";
clock-frequency = <100000>;
status = "okay";
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: dts: armada-370-rn102: add pinmuxing for i2c0
From: Uwe Kleine-König @ 2016-10-20 19:19 UTC (permalink / raw)
To: linux-arm-kernel
Up to now a working i2c bus depended on the bootloader to configure the
pinmuxing. Make it explicit.
As a side effect this change makes i2c work in barebox.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/armada-370-netgear-rn102.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
index 3ca6330a1752..a9e3810aea65 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
@@ -121,6 +121,10 @@
i2c at 11000 {
clock-frequency = <100000>;
+
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+
status = "okay";
isl12057: isl12057 at 68 {
--
2.9.3
^ permalink raw reply related
* [PATCH 4/9] pinctrl: meson: allow gpio to request irq
From: Linus Walleij @ 2016-10-20 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476871709-8359-5-git-send-email-jbrunet@baylibre.com>
On Wed, Oct 19, 2016 at 12:08 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> Add the ability for gpio to request irq from the gpio interrupt controller
> if present. We have to specificaly that the parent interrupt controller is
> the gpio interrupt controller because gpio on meson SoCs can't generate
> interrupt directly on the GIC.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
(...)
> + select IRQ_DOMAIN
> select OF_GPIO
> + select OF_IRQ
(...)
> +static int meson_gpio_to_hwirq(struct meson_bank *bank, unsigned int offset)
> +{
> + unsigned int hwirq;
> +
> + if (bank->irq_first < 0)
> + /* this bank cannot generate irqs */
> + return -1;
> +
> + hwirq = offset - bank->first + bank->irq_first;
> +
> + if (hwirq > bank->irq_last)
> + /* this pin cannot generate irqs */
> + return -1;
> +
> + return hwirq;
> +}
This is reimplementing irqdomain.
> +static int meson_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
> +{
(...)
> + hwirq = meson_gpio_to_hwirq(bank, offset);
> + if (hwirq < 0) {
> + dev_dbg(pc->dev, "no interrupt for pin %u\n", offset);
> + return 0;
> + }
Isn't this usecase (also as described in the cover letter) a textbook
example of when you should be using hierarchical irqdomain?
Please check with Marc et al on hierarchical irqdomains.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Michal Hocko @ 2016-10-20 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5807AC2B.4090208@linux.intel.com>
On Wed 19-10-16 10:23:55, Dave Hansen wrote:
> On 10/19/2016 10:01 AM, Michal Hocko wrote:
> > The question I had earlier was whether this has to be an explicit FOLL
> > flag used by g-u-p users or we can just use it internally when mm !=
> > current->mm
>
> The reason I chose not to do that was that deferred work gets run under
> a basically random 'current'. If we just use 'mm != current->mm', then
> the deferred work will sometimes have pkeys enforced and sometimes not,
> basically randomly.
OK, I see (async_pf_execute and ksm ). It makes more sense to me. Thanks
for the clarification.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Kevin Hilman @ 2016-10-20 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1867292.F3aGJTmS2t@avalon>
Hi Laurent,
Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:
> On Thursday 20 Oct 2016 09:57:51 Kevin Hilman wrote:
>> Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:
>> > On Wednesday 19 Oct 2016 10:26:57 Bartosz Golaszewski wrote:
>> >> 2016-10-18 22:49 GMT+02:00 Laurent Pinchart:
>> >>> On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote:
>> >>>> Create the driver for the da8xx System Configuration and implement
>> >>>> support for writing to the three Master Priority registers.
>> >>>>
>> >>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> >>
>> >> [snip]
>> >>
>> >>>> +
>> >>>> +Documentation:
>> >>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> >>>> +
>> >>>> +Required properties:
>> >>>> +
>> >>>> +- compatible: "ti,da850-syscfg"
>> >>>
>> >>> Don't you need a reg property ?
>> >>
>> >> Yes, Kevin already pointed that out. I'll add it in v2. Same for [1/3].
>> >>
>> >>>> +Optional properties:
>> >>>> +
>> >>>> +The below properties are used to specify the priority of master
>> >>>> peripherals.
>> >>>> +They must be between 0-7 where 0 is the highest priority and 7 is the
>> >>>> lowest.
>> >>>> +
>> >>>> +- ti,pri-arm-i: ARM_I port priority.
>> >>>> +
>> >>>> +- ti,pri-arm-d: ARM_D port priority.
>> >>>> +
>> >>>> +- ti,pri-upp: uPP port priority.
>> >>>> +
>> >>>> +- ti,pri-sata: SATA port priority.
>> >>>> +
>> >>>> +- ti,pri-pru0: PRU0 port priority.
>> >>>> +
>> >>>> +- ti,pri-pru1: PRU1 port priority.
>> >>>> +
>> >>>> +- ti,pri-edma30tc0: EDMA3_0_TC0 port priority.
>> >>>> +
>> >>>> +- ti,pri-edma30tc1: EDMA3_0_TC1 port priority.
>> >>>> +
>> >>>> +- ti,pri-edma31tc0: EDMA3_1_TC0 port priority.
>> >>>> +
>> >>>> +- ti,pri-vpif-dma-0: VPIF DMA0 port priority.
>> >>>> +
>> >>>> +- ti,pri-vpif-dma-1: VPIF DMA1 port priority.
>> >>>> +
>> >>>> +- ti,pri-emac: EMAC port priority.
>> >>>> +
>> >>>> +- ti,pri-usb0cfg: USB0 CFG port priority.
>> >>>> +
>> >>>> +- ti,pri-usb0cdma: USB0 CDMA port priority.
>> >>>> +
>> >>>> +- ti,pri-uhpi: HPI port priority.
>> >>>> +
>> >>>> +- ti,pri-usb1: USB1 port priority.
>> >>>> +
>> >>>> +- ti,pri-lcdc: LCDC port priority.
>> >>>
>> >>> I'm afraid this looks more like system configuration than hardware
>> >>> description to me.
>> >>
>> >> While you're certainly right, this approach is already implemented in
>> >> several other memory and bus drivers and it was also suggested by
>> >> Sekhar in one of the tilcdc rev1 threads. There's also no real
>> >> alternative that I know of.
>> >
>> > The fact that other drivers get it wrong is no excuse for copying them :-)
>>
>> What exactly is "wrong" with the way other drivers are doing it?
>>
>> I'm sure there may be other ideas, and possibly some better ones, but
>> that doesn't make it wrong, and doesn't change he fact that the kernel
>> has existing drivers SoC-bus-specific system performance knobs like
>> this.
>
> It's not the drivers I'm concerned about, but the DT bindings.
I see, thanks for the clarification.
> The proposed DT binding contains a large number of properties that
> don't describe the hardware but contain configuration data.
I agree that there ought to be some more generic way for devices to
request performance constraints from their busses at runtime based on
their current operating critera, but unfortunately that doesn't exist
yet.
However, after our discussion on IRC, we'll respin this without the DT
bindings at all. Next version will just use static configuration data
in the drivers/bus driver based on SoC compatible string, since for the
use-cases I'm aware of, the settings are boot-time only.
Thanks again for the review,
Kevin
^ permalink raw reply
* [PATCH 3/4] arm64: dts: msm8996: Add SMEM DT nodes
From: Bjorn Andersson @ 2016-10-20 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476989765-7524-3-git-send-email-spjoshi@codeaurora.org>
On Thu 20 Oct 11:56 PDT 2016, Sarangdhar Joshi wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> Add SMEM and TCSR DT nodes on MSM8996.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 949b096..0a810f5 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -169,12 +169,31 @@
> method = "smc";
> };
>
> + smem {
> + compatible = "qcom,smem";
> +
> + memory-region = <&smem_mem>;
> +
> + hwlocks = <&tcsr_mutex 3>;
> + };
> +
> soc: soc {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0 0 0xffffffff>;
> compatible = "simple-bus";
>
> + tcsr_mutex_regs: syscon at 740000 {
> + compatible = "syscon";
> + reg = <0x740000 0x20000>;
> + };
> +
> + tcsr_mutex: hwlock {
> + compatible = "qcom,tcsr-mutex";
> + syscon = <&tcsr_mutex_regs 0 0x1000>;
> + #hwlock-cells = <1>;
> + };
Sorry, I got this in the wrong place, the hwlock node should sit outside
of soc {} - looks like we got this wrong in msm8916 as well.
Regards,
Bjorn
> +
> intc: interrupt-controller at 9bc0000 {
> compatible = "arm,gic-v3";
> #interrupt-cells = <3>;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* [PATCH 2/4] arm64: dts: msm8996: Add reserve-memory nodes
From: Bjorn Andersson @ 2016-10-20 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476989765-7524-2-git-send-email-spjoshi@codeaurora.org>
On Thu 20 Oct 11:56 PDT 2016, Sarangdhar Joshi wrote:
> Add reserve-memory nodes required for Qualcomm
> Peripheral Image Loaders
>
Awesome stuff,
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 36216ae..949b096 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -36,6 +36,31 @@
> #size-cells = <2>;
> ranges;
>
> + mba_region: mba at 91500000 {
> + reg = <0x0 0x91500000 0x0 0x200000>;
> + no-map;
> + };
> +
> + slpi_region: slpi at 90b00000 {
> + reg = <0x0 0x90b00000 0xa00000>;
> + no-map;
> + };
> +
> + venus_region: venus at 90400000 {
> + reg = <0x0 0x90400000 0x0 0x700000>;
> + no-map;
> + };
> +
> + adsp_region: adsp at 8ea00000 {
> + reg = <0x0 0x8ea00000 0x0 0x1a00000>;
> + no-map;
> + };
> +
> + mpss_region: mpss at 88800000 {
> + reg = <0x0 0x88800000 0x0 0x6200000>;
> + no-map;
> + };
> +
> smem_mem: smem-mem at 86000000 {
> reg = <0x0 0x86000000 0x0 0x200000>;
> no-map;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* [PATCH 1/4] arm64: dts: msm8996: Add SMEM reserve-memory node
From: Bjorn Andersson @ 2016-10-20 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476989765-7524-1-git-send-email-spjoshi@codeaurora.org>
On Thu 20 Oct 11:56 PDT 2016, Sarangdhar Joshi wrote:
> Add DT node to carveout memory for shared memory region.
>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index d6da223..36216ae 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -31,6 +31,17 @@
> reg = <0 0 0 0>;
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + smem_mem: smem-mem at 86000000 {
> + reg = <0x0 0x86000000 0x0 0x200000>;
> + no-map;
> + };
> + };
> +
> cpus {
> #address-cells = <2>;
> #size-cells = <0>;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Sinan Kaya @ 2016-10-20 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019224405.GA14915@localhost>
On 10/19/2016 3:44 PM, Bjorn Helgaas wrote:
[cut]
>>
>> Same problem here. This line will be broken after the sci_penalty change.
>>
>> acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
>> (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
>
> I think the fragility of this code is an indication that we have a
> design problem, so I want to step back from the nitty gritty details
> for a bit and look at the overall design.
This is all because we started with a very simple design where we replaced
the array with a get_penalty function. Set penalty function would dynamically
reallocate the link list so that we have a design that works no matter
what the number of IRQs are.
As we hit the first problem on existing platform, we realized that we can't
actually dynamically reallocate an interrupt because get_penalty function
gets called from early boot stages where heap is not initialized yet.
Then, we started restructuring the code so that we can discover the IRQs
by iterating the link list rather than using an array. While transitioning
into this new design, we forgot the fact that irq_get_penalty function
became a fixed array penalty + dynamically calculated penalty.
This line was trying to increment the static array but ended up gathering
the dynamic pieces together.
This obviously is a bug and was forgotten in the code.
>
> Let me restate the overall problem: We have a PCI device connected to
> an interrupt link. The interrupt link can be connected to one of
> several IRQs, and we want to choose one of those IRQs to minimize IRQ
> sharing.
>
> That means we need information about which IRQs are used.
> Historically we've started with a compiled-in table of common ISA IRQ
> usage, and we also collect information about which IRQs are used and
> which *might* be used. So we have the following inputs:
>
> - Compiled-in ISA IRQ usage: the static acpi_isa_irq_penalty[]
> values. ACPI is *supposed* to tell us about all these usages, so
> I don't know why we have the table. But it's been there as long
> as I can remember. The table is probably x86-specific, but we
> keep it in the supposedly generic pci_link.c.
>
I think it is because the ISA IRQ functions get called in early boot stages
and there is no heap allocator at that point of execution.
> - The "acpi_irq_isa=" and "acpi_irq_pci=" command-line overrides via
> acpi_irq_pci(). I suppose these are for cases where we can't
> figure things out automatically. I would resist adding parameters
> like this today (I would treat the need for them as a bug and look
> for a fix or a quirk), but we might be stuck with these.
>
> - SCI information from the ACPI FADT (acpi_penalize_sci_irq()).
>
> - PNPBIOS and PNPACPI device IRQ usage from _CRS and _PRS via
> acpi_penalize_isa_irq(). This is only for IRQs 0-15, and it does
> NOT include interrupt link (PNP0C0F) devices because we don't
> handle them as PNPACPI devices. I think this is related to the
> fact that PNP0C0F doesn't appear in acpi_pnp_device_ids[].
The original code supports the entire IRQ range (0..255). We limited it
to 16 during redesign.
>
> - For non-PNP0C0F, non-PNPACPI devices, we completely ignore IRQ
> information from _CRS and _PRS. This seems sub-optimal and
> possibly buggy.
>
> - Interrupt link (PNP0C0F) IRQ usage from _CRS and _PRS via
> acpi_irq_penalty_init(). This is only for IRQs 0-15, and we only
> call this on x86. If _PRS exists, we penalize each possible IRQ.
> If there's no _PRS but _CRS contains an active IRQ, we penalize
> it.
Correct.
>
> - Interrupt link (PNP0C0F) IRQ usage from _CRS and _PRS when
> enabling a new link. In acpi_irq_pci_sharing_penalty(), we
> penalize an IRQ if it appears in _CRS or _PRS of any link device
> in the system.
>
> For IRQs 0-15, this overlaps with the penalization done at
> boot-time by acpi_irq_penalty_init(): if a device has _PRS, we'll
> add the "possible" penalty twice (once in acpi_irq_penalty_init()
> and again in acpi_irq_pci_sharing_penalty()), and the "using"
> penalty once (in acpi_irq_pci_sharing_penalty()).
>
> If a device has no _PRS but has _CRS, the "using" penalty is
> applied twice (once in once in acpi_irq_penalty_init() and again
> in acpi_irq_pci_sharing_penalty())
>
> I think this whole thing is baroque and grotesque.
Regardless of these, we hit four different bugs because we didn't understand
the usage model.
1. You can't use kmalloc in IRQ get penalty
2. SCI IRQ type cannot be gathered from IRQ API
3. acpi_irq_penalty cannot be called from early stages since it is iterating
the link list. If there is a penalty assignment requirement from early stages,
this needs to be done on a statically allocated array.
4. acpi_irq_penalty_init is redundant.
>
> Here's a strawman idea:
>
> - Maintain a mapping of (IRQ, penalty). Initially all penalties are
> zero. This is for *all* IRQs, not just ISA ones. This could be a
> linked list, but the structure is not important as long as we can
> add things dynamically.
Dynamic allocation doesn't work due to early calls from x86 architecture.
This is the reason why we iterate the link objects.
>
> - Add a "acpi_penalize_irq()" function similar to
> acpi_penalize_isa_irq(), but not restricted to ISA, so we can
> increase the penalty for any IRQ, and maybe we can specify how
> much penalty to add.
This was my first patch. It didn't work due to heap requirements.
>
> - Make acpi_irq_get_penalty() a simple lookup in the mapping. No
> iterating through all link devices.
>
> - If we think the compiled-in penalties are really necessary, move
> the table to x86 code and add a boot-time loop to use
> acpi_penalize_irq() to penalize these IRQs. Same for the
> command-line options.
I agree, we can move all of the ISA interrupt stuff out of this file
if we want to.
I really don't like the fact that we have a acpi_penalize_isa_irq function.
The penalty information should have been contained in this file.
acpi_penalize_isa_irq gets called from arbitrary contexts.
I'm not sure adding a acpi_penalize_irq function is a good idea. All penalty
users should have been in this file.
>
> - Change acpi_penalize_sci_irq() to use acpi_penalize_irq().
> Probably the mapping needs to pay attention to trigger/polarity
> somehow, too.
>
> - Figure out how to make the ACPI core use acpi_penalize_irq() to
> based on the _CRS and _PRS of every ACPI device, including
> PNPACPI, PNP0C0F, etc. Then we can remove acpi_irq_penalty_init().
>
I think this is a new feature.
> - Change acpi_pci_link_set() to use acpi_penalize_irq() for the IRQ
> it is enabling. Conceptually maybe this should be done in the
> acpi_set_current_resources() path so it happens whenever we use
> _CRS to enable an IRQ on *any* ACPI device.
>
> I think the biggest issue is figuring out how to get the ACPI core to
> look at the _CRS for *all* devices. If we could do that, I think it
> could substantially simplify this code.
I think my V4 patch satisfies all of these requirements and also fixes
the existing regression. (I have test vectors captured from the machines
with issues.)
1. You can't use kmalloc in IRQ get penalty
2. SCI IRQ type cannot be gathered from IRQ API
3. acpi_irq_penalty cannot be called from early stages since it is iterating
the link list. If there is a penalty assignment requirement from early stages,
this needs to be done on a statically allocated array.
4. acpi_irq_penalty_init is redundant.
and your goal to have some common code that can be used with any IRQ we want.
If we want to move the ISA pieces out of this file, that can be done too.
We can also add support for PNPACPI. I'm not a very big fan of scratch
everything and start from beginning approach. This refactoring effort already
failed 3 times. I'd like to close the issue and move on.
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 4/4] arm64: dts: msm8996: Add SMP2P and APCS nodes
From: Bjorn Andersson @ 2016-10-20 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476989765-7524-4-git-send-email-spjoshi@codeaurora.org>
On Thu 20 Oct 11:56 PDT 2016, Sarangdhar Joshi wrote:
> Add SMP2P and APCS DT nodes required for Qualcomm ADSP
> Peripheral Image Loader.
>
Nice, two (very) small nits below. But other than that
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 0a810f5..3edb56b 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -169,6 +169,31 @@
> method = "smc";
> };
>
> + smp2p-adsp {
Sorry for bikeshedding, but on msm8916 I named these {subsystem}-smp2p,
so I would prefer this was naemd adsp-smp2p...
> + compatible = "qcom,smp2p";
> + qcom,smem = <443>, <429>;
> +
> + interrupt-parent = <&intc>;
I believe this node inherit intc as interrupt-parent from the root
already, is there are reason why you need to specify it.
> + interrupts = <0 158 IRQ_TYPE_EDGE_RISING>;
> +
> + qcom,ipc = <&apcs 16 10>;
> +
> + qcom,local-pid = <0>;
> + qcom,remote-pid = <2>;
> +
> + adsp_smp2p_out: master-kernel {
> + qcom,entry-name = "master-kernel";
> + #qcom,state-cells = <1>;
> + };
> +
> + adsp_smp2p_in: slave-kernel {
> + qcom,entry-name = "slave-kernel";
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> + };
> +
> smem {
> compatible = "qcom,smem";
>
> @@ -205,6 +230,11 @@
> interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> + apcs: syscon at 9820000 {
> + compatible = "syscon";
> + reg = <0x9820000 0x1000>;
> + };
> +
> gcc: clock-controller at 300000 {
> compatible = "qcom,gcc-msm8996";
> #clock-cells = <1>;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* [PATCH] Revert "clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init"
From: Thomas Gleixner @ 2016-10-20 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018054918.26855-1-wens@csie.org>
On Tue, 18 Oct 2016, Chen-Yu Tsai wrote:
> Revert the commit for now. clocksource_mmio_init can be made to pass back
> a pointer, but the code churn and usage of an inner struct might not be
> worth it.
You can avoid the churn by making clocksurce_mmio_init() a wrapper around a
new function, which takes a pointer to a struct clocksource_mmio as
argument so you can hand in the structure you need: Something like the
patch below should do the trick.
Thanks,
tglx
8<--------------------------------
--- a/drivers/clocksource/mmio.c
+++ b/drivers/clocksource/mmio.c
@@ -10,11 +10,6 @@
#include <linux/init.h>
#include <linux/slab.h>
-struct clocksource_mmio {
- void __iomem *reg;
- struct clocksource clksrc;
-};
-
static inline struct clocksource_mmio *to_mmio_clksrc(struct clocksource *c)
{
return container_of(c, struct clocksource_mmio, clksrc);
@@ -41,6 +36,27 @@ cycle_t clocksource_mmio_readw_down(stru
}
/**
+ * FIXME: Add doc
+ */
+int __init clocksource_mmio_setup(struct clocksource_mmio *cs,
+ void __iomem *base , const char *name,
+ unsigned long hz , int rating, unsigned bits,
+ cycle_t (*read)(struct clocksource *))
+{
+ if (bits > 64 || bits < 16)
+ return -EINVAL;
+
+ cs->reg = base;
+ cs->clksrc.name = name;
+ cs->clksrc.rating = rating;
+ cs->clksrc.read = read;
+ cs->clksrc.mask = CLOCKSOURCE_MASK(bits);
+ cs->clksrc.flags = CLOCK_SOURCE_IS_CONTINUOUS;
+
+ return clocksource_register_hz(&cs->clksrc, hz);
+}
+
+/**
* clocksource_mmio_init - Initialize a simple mmio based clocksource
* @base: Virtual address of the clock readout register
* @name: Name of the clocksource
@@ -62,12 +78,5 @@ int __init clocksource_mmio_init(void __
if (!cs)
return -ENOMEM;
- cs->reg = base;
- cs->clksrc.name = name;
- cs->clksrc.rating = rating;
- cs->clksrc.read = read;
- cs->clksrc.mask = CLOCKSOURCE_MASK(bits);
- cs->clksrc.flags = CLOCK_SOURCE_IS_CONTINUOUS;
-
- return clocksource_register_hz(&cs->clksrc, hz);
+ return clocksource_mmio_setup(cs, base, name, hz, rating, bits, read);
}
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -119,6 +119,14 @@ struct clocksource {
/* simplify initialization of mask field */
#define CLOCKSOURCE_MASK(bits) (cycle_t)((bits) < 64 ? ((1ULL<<(bits))-1) : -1)
+/**
+ * FIXME: Add doc
+ */
+struct clocksource_mmio {
+ void __iomem *reg;
+ struct clocksource clksrc;
+};
+
static inline u32 clocksource_freq2mult(u32 freq, u32 shift_constant, u64 from)
{
/* freq = cyc/from
@@ -241,6 +249,11 @@ extern cycle_t clocksource_mmio_readw_do
extern int clocksource_mmio_init(void __iomem *, const char *,
unsigned long, int, unsigned, cycle_t (*)(struct clocksource *));
+extern int clocksource_mmio_setup(struct clocksource_mmio *,
+ void __iomem *, const char *,
+ unsigned long, int, unsigned,
+ cycle_t (*)(struct clocksource *));
+
extern int clocksource_i8253_init(void);
#define CLOCKSOURCE_OF_DECLARE(name, compat, fn) \
^ permalink raw reply
* [PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path
From: Stephen Boyd @ 2016-10-20 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020101017.GA32001@b29397-desktop>
Quoting Peter Chen (2016-10-20 03:10:18)
> On Wed, Oct 19, 2016 at 11:55:29PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-10-19 01:02:11)
> > > On Tue, Oct 18, 2016 at 06:53:07PM -0700, Stephen Boyd wrote:
> > > > If you're asking if I've made modifications to extcon-usb-gpio, then the
> > > > answer is no. The branch on linaro.org git server from the cover-letter
> > > > is the branch I've used to test this with. This patch is specifically to
> > > > fix issues with that design on the db410c board that has only one pin
> > > > for ID and vbus detection. It's the schematic that we've discussed in
> > > > another thread.
> > > >
> > > > extcon-usb-gpio sends two extcon events, EXTCON_USB_HOST (for the id
> > > > pin) and EXTCON_USB (for the vbus). So afaik it does support vbus
> > > > events.
> > > >
> > >
> > > Hmm, in fact, your ID event is the same with vbus event, you take
> > > external vbus event as ID event for extcon-usb-gpio handling. Yes,
> > > it can work due to it sends EXTCON_USB_HOST event first.
> > >
> > > Where you change the USB_SW_SEL_PM pin?
> >
> > Currently that is done with the mux driver I sent based on the extcon
> > event. We don't know if that's before or after the controller handles
> > the extcon event though, so the pin should probably be changed from the
> > chipidea driver instead to be more explicit. Why do you ask though?
>
> I was just curious how you handle it, now I am clear. From my point,
> the suitable way may be: mux driver + user app (echo role through
> debugfs). The extcon-usb-gpio is not necessary, since you have already
> known role at mux driver.
>
> The current kernel has no framework to handle dual-role switch at kernel
> space.
Ok. I'm planning that as future work after this set of patches is
merged.
> > > @@ -1963,6 +1963,8 @@ static int udc_id_switch_for_device(struct ci_hdrc *ci)
> > > /* Clear and enable BSV irq */
> > > hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
> > > OTGSC_BSVIS | OTGSC_BSVIE);
> > > + /* vbus change may has already been occurred */
> >
> > "vbus change may have already occurred"?
>
> Yes, will change.
>
Great. Should I wait to incorporate your change into my series, or will
you apply the usb patches and Kishon can apply the phy patches? This
patch #11 should be dropped, but otherwise I don't think there's
anything left to do for this series.
^ permalink raw reply
* [PATCH] ARM: dt: sun8i-h3: Add sunxi-sid to dts for sun8i-h3
From: Maxime Ripard @ 2016-10-20 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019074016.GA31440@Red>
On Wed, Oct 19, 2016 at 09:40:16AM +0200, LABBE Corentin wrote:
> On Wed, Oct 05, 2016 at 12:21:30PM +0200, Jean-Francois Moine wrote:
> > On Wed, 5 Oct 2016 11:48:24 +0200
> > Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> >
> > > This patch add support for the sunxi-sid driver to the device tree for sun8i-h3.
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > ---
> > > arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > index 9f58bb4..abfd29c 100644
> > > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > @@ -211,6 +211,11 @@
> > > #size-cells = <0>;
> > > };
> > >
> > > + sid: eeprom at 01c14200 {
> > > + compatible = "allwinner,sun7i-a20-sid";
> > > + reg = <0x01c14200 0x200>;
> >
> > The datasheet says 1Kb starting at 0x01c14000.
> > Is there any reason to reduce the area and to shift the offset?
> >
>
> According to http://linux-sunxi.org/SID_Register_Guide "For
> Allwinner A83T and H3 the SID address space starts at 0x01c14000,
> and the e-fuses are at offset 0x200".
>
> So I use this offset, since the sunxi_sid driver need the base
> address of e-fuses.
>
> The easiest solution is to use 0x01c14200 since the other part of
> sid is not used and not known (A83T/H3 user manual doesnt give any
> information on all sid space, worse for A64 which reference SID only
> in memory map).
>
> So probably for H3/A64/A83T, there will never any usage of the rest
> of the SID address space.
And since we can't know that, and we have to maintain the DT ABI,
using the whole address map and an offset, with a new compatible, is
definetely the safest thing to do.
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/dec6def5/attachment.sig>
^ permalink raw reply
* [PATCH] drm: convert DT component matching to component_match_add_release()
From: Sean Paul @ 2016-10-20 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1bwo6l-0005Io-Q1@rmk-PC.armlinux.org.uk>
On Wed, Oct 19, 2016 at 6:28 AM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Convert DT component matching to use component_match_add_release().
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> Can we please get this patch from May merged into the drm-misc or
> whatever trees so that we don't end up with conflicts? I've no idea
> who looks after drm-misc, as they have _still_ failed to add
> themselves to MAINTAINERS.
I think Daniel explained pretty clearly why this wasn't happening in
the previous thread.
Next time you send a v2, can you please mark it as such and include a
"Changes in v2" section?
>
> drivers/gpu/drm/arm/hdlcd_drv.c | 3 ++-
> drivers/gpu/drm/arm/malidp_drv.c | 4 +++-
> drivers/gpu/drm/armada/armada_drv.c | 2 +-
> drivers/gpu/drm/drm_of.c | 28 +++++++++++++++++++++++--
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 5 +++--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 7 ++++---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +++-
> drivers/gpu/drm/msm/msm_drv.c | 12 ++++++-----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++++--
> drivers/gpu/drm/sti/sti_drv.c | 5 +++--
> drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
> drivers/gpu/drm/tilcdc/tilcdc_external.c | 4 +++-
> include/drm/drm_of.h | 12 +++++++++++
> 13 files changed, 73 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index fb6a418ce6be..6477d1a65266 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
> return -EAGAIN;
> }
>
> - component_match_add(&pdev->dev, &match, compare_dev, port);
> + drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
> + of_node_put(port);
There's no mention in your commit message about fixing these node leaks.
>
> return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
> match);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index 9280358b8f15..9f4739452a25 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
> return -EAGAIN;
> }
>
> - component_match_add(&pdev->dev, &match, malidp_compare_dev, port);
> + drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
> + port);
> + of_node_put(port);
> return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
> match);
> }
> diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
> index 1e0e68f608e4..94e46da9a758 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
> continue;
> }
>
> - component_match_add(dev, match, compare_of, remote);
> + drm_of_component_match_add(dev, match, compare_of, remote);
> of_node_put(remote);
> }
> }
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index bc98bb94264d..47848ed8ca48 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -6,6 +6,11 @@
> #include <drm/drm_crtc.h>
> #include <drm/drm_of.h>
>
> +static void drm_release_of(struct device *dev, void *data)
> +{
> + of_node_put(data);
> +}
> +
> /**
> * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
> * @dev: DRM device
> @@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> EXPORT_SYMBOL(drm_of_find_possible_crtcs);
>
> /**
> + * drm_of_component_match_add - Add a component helper OF node match rule
> + * @master: master device
> + * @matchptr: component match pointer
> + * @compare: compare function used for matching component
> + * @node: of_node
> + */
> +void drm_of_component_match_add(struct device *master,
> + struct component_match **matchptr,
> + int (*compare)(struct device *, void *),
> + struct device_node *node)
> +{
> + of_node_get(node);
> + component_match_add_release(master, matchptr, drm_release_of,
> + compare, node);
> +}
> +EXPORT_SYMBOL_GPL(drm_of_component_match_add);
> +
> +/**
> * drm_of_component_probe - Generic probe function for a component based master
> * @dev: master device containing the OF node
> * @compare_of: compare function used for matching components
> @@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
> continue;
> }
>
> - component_match_add(dev, &match, compare_of, port);
> + drm_of_component_match_add(dev, &match, compare_of, port);
> of_node_put(port);
> }
>
> @@ -140,7 +163,8 @@ int drm_of_component_probe(struct device *dev,
> continue;
> }
>
> - component_match_add(dev, &match, compare_of, remote);
> + drm_of_component_match_add(dev, &match, compare_of,
> + remote);
> of_node_put(remote);
> }
> of_node_put(port);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index aa687669e22b..0dee6acbd880 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -16,6 +16,7 @@
>
> #include <linux/component.h>
> #include <linux/of_platform.h>
> +#include <drm/drm_of.h>
>
> #include "etnaviv_drv.h"
> #include "etnaviv_gpu.h"
> @@ -629,8 +630,8 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
> if (!core_node)
> break;
>
> - component_match_add(&pdev->dev, &match, compare_of,
> - core_node);
> + drm_of_component_match_add(&pdev->dev, &match,
> + compare_of, core_node);
> of_node_put(core_node);
> }
> } else if (dev->platform_data) {
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 90377a609c98..e88fde18c946 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -24,6 +24,7 @@
> #include <drm/drm_fb_cma_helper.h>
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_crtc_helper.h>
> +#include <drm/drm_of.h>
>
> #include "kirin_drm_drv.h"
>
> @@ -260,14 +261,13 @@ static struct device_node *kirin_get_remote_node(struct device_node *np)
> DRM_ERROR("no valid endpoint node\n");
> return ERR_PTR(-ENODEV);
> }
> - of_node_put(endpoint);
>
> remote = of_graph_get_remote_port_parent(endpoint);
> + of_node_put(endpoint);
Another bug that's being fixed without mention in the commit.
> if (!remote) {
> DRM_ERROR("no valid remote node\n");
> return ERR_PTR(-ENODEV);
> }
> - of_node_put(remote);
>
> if (!of_device_is_available(remote)) {
> DRM_ERROR("not available for remote node\n");
> @@ -294,7 +294,8 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
> if (IS_ERR(remote))
> return PTR_ERR(remote);
>
> - component_match_add(dev, &match, compare_of, remote);
> + drm_of_component_match_add(dev, &match, compare_of, remote);
> + of_node_put(remote);
>
> return component_master_add_with_match(dev, &kirin_drm_ops, match);
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index cf83f6507ec8..9c5430fb82a2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -18,6 +18,7 @@
> #include <drm/drm_crtc_helper.h>
> #include <drm/drm_gem.h>
> #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_of.h>
> #include <linux/component.h>
> #include <linux/iommu.h>
> #include <linux/of_address.h>
> @@ -415,7 +416,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
> comp_type == MTK_DPI) {
> dev_info(dev, "Adding component match for %s\n",
> node->full_name);
> - component_match_add(dev, &match, compare_of, node);
> + drm_of_component_match_add(dev, &match, compare_of,
> + node);
> } else {
> struct mtk_ddp_comp *comp;
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index fb5c0b0a7594..84d38eaea585 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -15,6 +15,8 @@
> * this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <drm/drm_of.h>
> +
> #include "msm_drv.h"
> #include "msm_debugfs.h"
> #include "msm_fence.h"
> @@ -919,8 +921,8 @@ static int add_components_mdp(struct device *mdp_dev,
> continue;
> }
>
> - component_match_add(master_dev, matchptr, compare_of, intf);
> -
> + drm_of_component_match_add(master_dev, matchptr, compare_of,
> + intf);
> of_node_put(intf);
> of_node_put(ep_node);
> }
> @@ -962,8 +964,8 @@ static int add_display_components(struct device *dev,
> put_device(mdp_dev);
>
> /* add the MDP component itself */
> - component_match_add(dev, matchptr, compare_of,
> - mdp_dev->of_node);
> + drm_of_component_match_add(dev, matchptr, compare_of,
> + mdp_dev->of_node);
> } else {
> /* MDP4 */
> mdp_dev = dev;
> @@ -996,7 +998,7 @@ static int add_gpu_components(struct device *dev,
> if (!np)
> return 0;
>
> - component_match_add(dev, matchptr, compare_of, np);
> + drm_of_component_match_add(dev, matchptr, compare_of, np);
>
> of_node_put(np);
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 8c8cbe837e61..6fe161192bb4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -20,6 +20,7 @@
> #include <drm/drm_crtc_helper.h>
> #include <drm/drm_fb_helper.h>
> #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_of.h>
> #include <linux/dma-mapping.h>
> #include <linux/pm_runtime.h>
> #include <linux/module.h>
> @@ -388,7 +389,7 @@ static void rockchip_add_endpoints(struct device *dev,
> continue;
> }
>
> - component_match_add(dev, match, compare_of, remote);
> + drm_of_component_match_add(dev, match, compare_of, remote);
> of_node_put(remote);
> }
> }
> @@ -437,7 +438,8 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
> }
>
> of_node_put(iommu);
> - component_match_add(dev, &match, compare_of, port->parent);
> + drm_of_component_match_add(dev, &match, compare_of,
> + port->parent);
> of_node_put(port);
> }
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 2784919a7366..5e819876e642 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -17,6 +17,7 @@
> #include <drm/drm_crtc_helper.h>
> #include <drm/drm_gem_cma_helper.h>
> #include <drm/drm_fb_cma_helper.h>
> +#include <drm/drm_of.h>
>
> #include "sti_crtc.h"
> #include "sti_drv.h"
> @@ -423,8 +424,8 @@ static int sti_platform_probe(struct platform_device *pdev)
> child_np = of_get_next_available_child(node, NULL);
>
> while (child_np) {
> - component_match_add(dev, &match, compare_of, child_np);
> - of_node_put(child_np);
> + drm_of_component_match_add(dev, &match, compare_of,
> + child_np);
> child_np = of_get_next_available_child(node, child_np);
> }
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 0da9862ad8ed..b3c4ad605e81 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -18,6 +18,7 @@
> #include <drm/drm_fb_cma_helper.h>
> #include <drm/drm_gem_cma_helper.h>
> #include <drm/drm_fb_helper.h>
> +#include <drm/drm_of.h>
>
> #include "sun4i_crtc.h"
> #include "sun4i_drv.h"
> @@ -239,7 +240,7 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> /* Add current component */
> DRM_DEBUG_DRIVER("Adding component %s\n",
> of_node_full_name(node));
> - component_match_add(dev, match, compare_of, node);
> + drm_of_component_match_add(dev, match, compare_of, node);
> count++;
> }
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> index 68e895021005..06a4c584f3cb 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> @@ -10,6 +10,7 @@
>
> #include <linux/component.h>
> #include <linux/of_graph.h>
> +#include <drm/drm_of.h>
>
> #include "tilcdc_drv.h"
> #include "tilcdc_external.h"
> @@ -160,7 +161,8 @@ int tilcdc_get_external_components(struct device *dev,
>
> dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
> if (match)
> - component_match_add(dev, match, dev_match_of, node);
> + drm_of_component_match_add(dev, match, dev_match_of,
> + node);
> of_node_put(node);
> count++;
> }
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 3fd87b386ed7..d6b4c5587bbe 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -4,6 +4,7 @@
> #include <linux/of_graph.h>
>
> struct component_master_ops;
> +struct component_match;
> struct device;
> struct drm_device;
> struct drm_encoder;
> @@ -12,6 +13,10 @@ struct device_node;
> #ifdef CONFIG_OF
> extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> struct device_node *port);
> +extern void drm_of_component_match_add(struct device *master,
> + struct component_match **matchptr,
> + int (*compare)(struct device *, void *),
> + struct device_node *node);
> extern int drm_of_component_probe(struct device *dev,
> int (*compare_of)(struct device *, void *),
> const struct component_master_ops *m_ops);
> @@ -25,6 +30,13 @@ static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> return 0;
> }
>
> +static void drm_of_component_match_add(struct device *master,
> + struct component_match **matchptr,
> + int (*compare)(struct device *, void *),
> + struct device_node *node)
> +{
> +}
> +
> static inline int
> drm_of_component_probe(struct device *dev,
> int (*compare_of)(struct device *, void *),
> --
> 2.1.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox