* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Hanjun Guo @ 2016-12-30 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9aa650ad-a32d-e942-1c6b-b069c8a2b87a@codeaurora.org>
On 2016/12/29 22:44, Sinan Kaya wrote:
> On 12/25/2016 8:31 PM, Hanjun Guo wrote:
>>> A type->setup() would be somewhat cleaner I think, but then it's more
>>> code. Whichever works better I guess. :-)
>> Agree, I will demo the type->setup() way and send out the patch for review,
>> also I find one minor issue for the IORT code, will update that also for next
>> version.
> Can you provide details on what the minor issue is with the IORT code?
It's about the mapping of NC (named component) -> SMMU -> ITS, we can
describe it as two ID mappings:
- NC->SMMU
- NC->ITS
And the code for now can work perfect for such id mappings, but if we
want to support chained mapping NC -> SMMU -> ITS, we need to add
extra code which in my [PATCH v5 10/14] ACPI: ARM64: IORT: rework
iort_node_get_id() for NC->SMMU->ITS case, but I just scanned the first
id mapping for now, I think I need to scan all the id mappings (but seems
single id mappings don't need to do that, I will investigate it more).
Thanks
Hanjun
^ permalink raw reply
* [PATCH v2] bus: imx-weim: Fix the "fsl, weim-cs-gpr" lookup method
From: Fabio Estevam @ 2016-12-30 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230064650.GN6177@dragon>
On Fri, Dec 30, 2016 at 4:46 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> "fsl,weim-cs-gpr" is *not* a compatible string, while
> what syscon_regmap_lookup_by_compatible() does is to find a syscon node
> by its compatible string.
Ops, sorry about that. I sent a v3, which hopefully looks better.
^ permalink raw reply
* [PATCH v3] ARM: dts: imx6: Disable "weim" node in the dtsi files
From: Fabio Estevam @ 2016-12-30 10:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Commit 1be81ea5860744520 ("ARM: dts: imx6: Add imx-weim parameters to
dtsi's") causes the following probe error when the weim node is not
present on the board dts (such as imx6q-sabresd):
imx-weim 21b8000.weim: Invalid 'ranges' configuration
imx-weim: probe of 21b8000.weim failed with error -22
There is no need to always enable the "weim" node on mx6. Do the same
as in the other i.MX dtsi files where "weim" is disabled and only gets
enabled on a per dts basis.
All the imx6 weim dts users explicitily provide 'status = "okay"', so
this change has no impact on current imx6 weim users.
If a board does not use the weim driver it will not describe its 'ranges'
property, so simply disable the 'weim' node in the imx6 dtsi files to
avoid such probe error message.
Fixes: 1be81ea5860744520 ("ARM: dts: imx6: Add imx-weim parameters to dtsi's")
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v2:
- Fix the error message by disabling weim at dtsi level.
arch/arm/boot/dts/imx6qdl.dtsi | 1 +
arch/arm/boot/dts/imx6sl.dtsi | 1 +
arch/arm/boot/dts/imx6sx.dtsi | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63..89b834f 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1100,6 +1100,7 @@
interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_EIM_SLOW>;
fsl,weim-cs-gpr = <&gpr>;
+ status = "disabled";
};
ocotp: ocotp at 021bc000 {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 4fd6de2..19cbd87 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -900,6 +900,7 @@
reg = <0x021b8000 0x4000>;
interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
fsl,weim-cs-gpr = <&gpr>;
+ status = "disabled";
};
ocotp: ocotp at 021bc000 {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 076a30f..10f3330 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -977,6 +977,7 @@
interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_EIM_SLOW>;
fsl,weim-cs-gpr = <&gpr>;
+ status = "disabled";
};
ocotp: ocotp at 021bc000 {
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Sergei Shtylyov @ 2016-12-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b83c353c-c054-4378-9308-e625c460bdd9@cogentembedded.com>
On 12/30/2016 12:46 PM, Sergei Shtylyov wrote:
>> It is possible that PCI device supports 64-bit DMA addressing, and thus
>> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host
>
> Its.
>
>> bridge has limitations on inbound transactions addressing. Example of
>> such setup is NVME
>
> Isn't it called NVMe?
>
>> SSD device connected to RCAR PCIe controller.
>
> R=Car.
Sorry, R-Car. :-)
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Sergei Shtylyov @ 2016-12-30 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com>
Hello!
On 12/29/2016 11:45 PM, Nikita Yushchenko wrote:
> It is possible that PCI device supports 64-bit DMA addressing, and thus
> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host
Its.
> bridge has limitations on inbound transactions addressing. Example of
> such setup is NVME
Isn't it called NVMe?
> SSD device connected to RCAR PCIe controller.
R=Car.
> Previously there was attempt to handle this via bus notifier: after
> driver is attached to PCI device, bridge driver gets notifier callback,
> and resets dma_mask from there. However, this is racy: PCI device driver
> could already allocate buffers and/or start i/o in probe routine.
> In NVME case, i/o is started in workqueue context, and this race gives
> "sometimes works, sometimes not" effect.
>
> Proper solution should make driver's dma_set_mask() call to fail if host
> bridge can't support mask being set.
>
> This patch makes __swiotlb_dma_supported() to check mask being set for
"To" not needed here.
> PCI device against dma_mask of struct device corresponding to PCI host
> bridge (one with name "pciXXXX:YY"), if that dma_mask is set.
>
> This is the least destructive approach: currently dma_mask of that device
> object is not used anyhow, thus all existing setups will work as before,
> and modification is required only in actually affected components -
> driver of particular PCI host bridge, and dma_map_ops of particular
> platform.
>
> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> ---
> arch/arm64/mm/dma-mapping.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 290a84f..49645277 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
[...]
> @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
>
> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
> {
> +#ifdef CONFIG_PCI
> + if (dev_is_pci(hwdev)) {
> + struct pci_dev *pdev = to_pci_dev(hwdev);
> + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus);
> +
> + if (br->dev.dma_mask && (*br->dev.dma_mask) &&
> + (mask & (*br->dev.dma_mask)) != mask)
Hum, inner parens not necessary?
[...]
MBR, Sergei
^ permalink raw reply
* [BUG] ARM64: amlogic: gxbb: unhandled level 2 translation fault (11)
From: Neil Armstrong @ 2016-12-30 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c9e66a1f-a53f-9993-dd15-5e566c5f46f0@baylibre.com>
On 12/30/2016 09:51 AM, Neil Armstrong wrote:
> On 12/29/2016 10:18 PM, Heinrich Schuchardt wrote:
>> On 12/29/2016 10:07 AM, Neil Armstrong wrote:
>>> On 12/24/2016 03:00 PM, Heinrich Schuchardt wrote:
>>>> When trying to run sddm on an Hardkernel Odroid C2 I invariably run into the
>>>> translation fault below.
>>>>
>>>> The following mail thread relates this kind of problem to TLB (translation
>>>> lookaside buffer) broadcasting.
>>>>
>>>> https://lkml.org/lkml/2014/4/15/207
>>>>
>>>> [ 3163.014263] sddm[1851]: unhandled level 2 translation fault (11) at 0x00000160, esr 0x82000006
>>>> [ 3163.017287] pgd = ffff80007bf86000
>>>> [ 3163.020589] [00000160] *pgd=000000007a8a3003
>>>> [ 3163.024733] , *pud=000000007be9c003
>>>> [ 3163.028095] , *pmd=0000000000000000
>>>>
>>>>
>>>> [ 3163.033026] CPU: 1 PID: 1851 Comm: sddm Not tainted 4.9.0-next-20161212-r022-arm64 #1
>>>> [ 3163.040831] Hardware name: Hardkernel ODROID-C2 (DT)
>>>> [ 3163.045698] task: ffff80007bc6d780 task.stack: ffff80007c524000
>>>> [ 3163.051563] PC is at 0x160
>>>> [ 3163.054231] LR is at 0xffff9a9fbc98
>>>> [ 3163.057686] pc : [<0000000000000160>] lr : [<0000ffff9a9fbc98>] pstate: 40000000
>>>> [ 3163.065022] sp : 0000ffffd7180130
>>>> [ 3163.068281] x29: 0000ffffd7180130 x28: 0000ffffd7180288
>>>> [ 3163.073538] x27: 0000ffff9aa94000 x26: 0000000000000001
>>>> [ 3163.078798] x25: 0000000000000000 x24: 0000ffffd7180410
>>>> [ 3163.084060] x23: 000000000e0c2190 x22: 000000000e0ca5c0
>>>> [ 3163.089322] x21: 0000ffff9ac35000 x20: 0000000000454fa9
>>>> [ 3163.094583] x19: 0000000000454fa8 x18: 000000000e0b5938
>>>> [ 3163.099843] x17: 0000ffff9a3f2988 x16: 0000ffff9ac36aa0
>>>> [ 3163.105105] x15: 0000000000000000 x14: 0000000000000000
>>>> [ 3163.110367] x13: 6d00640064007300 x12: 0800000005000000
>>>> [ 3163.115627] x11: 0000040000000000 x10: 0000a00000000000
>>>> [ 3163.120889] x9 : 00003fffffffffff x8 : 0000000000000000
>>>> [ 3163.126150] x7 : 000000000e0cb520 x6 : 0000000000454fc0
>>>> [ 3163.131412] x5 : 0000ffffd717ffd8 x4 : 000000000e0cb510
>>>> [ 3163.136680] x3 : 0000000000000004 x2 : f2f9022b551b3900
>>>> [ 3163.141935] x1 : 0000000000000160 x0 : 000000000e0ca5c0
>>>>
>>>> Best regards
>>>>
>>>> Heinrich Schuchardt
>>>
>>> Hi Heinrich,
>>>
>>> I personally never had this issue even while loading huge applications loke LibreOffice and Gnome environment.
>>>
>>> I will have a look and try to reproduce this issue, can you provide us your configuration and user-space complete use case ?
>>>
>>> Neil
>>>
>>
>> Hello Neil,
>>
>> the kernel is build with
>> https://github.com/xypron/kernel-odroid-c2/tree/f8d565ff755e92fd585f5ae10123ce20abe03968
>>
>> Especially look at the patch directory and config/config-next-20161212.
>>
>> The userland is Debian Stretch with this package:
>> https://packages.debian.org/stretch/sddm
>>
>> The link
>> https://www.spinics.net/lists/arm-kernel/msg550204.html
>> that you mention in a separate mail just links to this very thread due
>> to linux-arm-kernel at lists.infradead.org being in copy.
>>
>> Best regards
>>
>> Heinrich Schuchardt
>>
>
> Hi,
>
> Thanks for the details, but why do you use the next-20161212 tag ? does it work with 4.10-rc1 or previous next tags ?
>
> Neil
>
Hi Heinrich,
I'm able to reproduce the bug using SDMM from Ubuntu running a 4.10-rc1 patched with memory zones :
[ 17.988446] sddm-greeter[2366]: unhandled level 2 translation fault (11) at 0x00000000, esr 0x92000006
[ 17.988451] pgd = ffff80003c3ee000
[ 17.988472] [00000000] *pgd=00000000398bd003
[ 17.988474] , *pud=00000000398bf003
[ 17.990477] , *pmd=0000000000000000
[ 17.990485] CPU: 3 PID: 2366 Comm: sddm-greeter Not tainted 4.10.0-rc1-00004-gd3f812382-dirty #488
[ 17.990487] Hardware name: Amlogic Meson GXBB P200 Development Board (DT)
[ 17.990489] task: ffff80003c160000 task.stack: ffff80003c314000
[ 17.990493] PC is at 0xffffb2999994
[ 17.990495] LR is at 0xffffb299f774
[ 17.990497] pc : [<0000ffffb2999994>] lr : [<0000ffffb299f774>] pstate: 20000000
[ 17.990503] sp : 0000ffffd2d1d5b0
[ 17.990504] x29: 0000ffffd2d1d5b0 x28: 0000ffffad10e010
[ 17.990508] x27: 0000000009c376d0 x26: 0000000000000001
[ 17.990511] x25: 0000ffffb2b67000 x24: 0000ffffad10e010
[ 17.990514] x23: 0000000000000000 x22: 0000000000000000
[ 17.990517] x21: 0000000009c376d0 x20: 0000ffffb2fcdcb8
[ 17.990520] x19: 0000ffffb2b2b000 x18: 0000000009c78450
[ 17.990523] x17: 0000ffffb2b68068 x16: 0000ffffb2022158
[ 17.990526] x15: 0000ffffb2fcd000 x14: 0000000000000000
[ 17.990529] x13: aaaaaaaaaaaaaaab x12: 0000000000010000
[ 17.990532] x11: 0000000000000008 x10: 0000000009c3b980
[ 17.990535] x9 : 0000000009c38c40 x8 : 0000ffffd2d1d4e0
[ 17.990538] x7 : 0000000000000000 x6 : 0000000009c3b998
[ 17.990541] x5 : 0000000009c3b980 x4 : 0000800000000000
[ 17.990544] x3 : 00000000fffffff0 x2 : 0000ffffad10e010
[ 17.990547] x1 : 0000000009c379d8 x0 : 0000000000000000
Looking about other occurrence of such error, it seems it may be a issue from sdmm instead.
I'll continue searching,
Neil
^ permalink raw reply
* [PATCH 4/4] video: ARM CLCD: add support of an optional GPIO to enable panel
From: Vladimir Zapolskiy @ 2016-12-30 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb5Ojs+meXZKwJP3oDcYAnnrXgqBaXmCcgmgxJM=GkBGA@mail.gmail.com>
On 12/30/2016 10:20 AM, Linus Walleij wrote:
> On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy <vz@mleia.com> wrote:
>
>> The change adds handling of "enable-gpios" property of panel-dpi device
>> node used with an ARM CLCD controller, note that the property already has
>> a description in display/panel/panel-dpi.txt documentation and it founds
>> practical usage while describing some panel devices connected to other
>> types of display controllers.
>>
>> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
>
> So as you may have seen I already handle a RESET GPIO in the
> Nomadik TPG110 panel subddriver in
> drivers/video/fbdev/amba-clcd-nomadik.c
>
> So is this all your panel needs?
I need "enable-gpios" property to define a GPIO, which literally enables
(powers up) a panel as a separate attached PCB.
To some extend "enable-gpios" property can be replaced by "power" property
with a phandle to a GPIO voltage regulator.
You may look at drivers/gpu/drm/panel/panel-simple.c, both "enable-gpios"
and "power" properties are defined for simple panels.
>
> I guess it is OK for simple panels.
>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH 7/9] pinctrl: samsung: Add property to mark pad state as suitable for power down
From: Linus Walleij @ 2016-12-30 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227153331.jbh7ei6oh3obmnri@kozik-lap>
On Tue, Dec 27, 2016 at 4:33 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Tue, Dec 27, 2016 at 11:30:57AM +0100, Marek Szyprowski wrote:
>> Separate sleep state is needed because of the pin control bindings and
>> design.
>>
>> A separate sleep state is required to let pin control client driver (in this
>> case
>> Exynos I2S driver) let to choose when it is okay to switch pads into sleep
>> state and I see no other way to achieve this.
>
> Maybe the pinctrl API should be extended for this? Doing this in DTS
> just for purpose of passing information between drivers (consumer and
> provider) looks odd.
I don't understand what is going on but you are all smart people so I
guess you're right :)
Tell me if I can help clarifying something...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 5/9] pinctrl: samsung: Move retention control from mach-exynos to the pinctrl driver
From: Linus Walleij @ 2016-12-30 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482495889-6201-6-git-send-email-m.szyprowski@samsung.com>
On Fri, Dec 23, 2016 at 1:24 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Pad retention control after suspend/resume cycle should be done from pin
> controller driver instead of PMU (power management unit) driver to avoid
> possible ordering and logical dependencies. Till now it worked fine only
> because PMU driver registered its sys_ops after pin controller.
>
> This patch moves pad retention control from PMU driver to Exynos pin
> controller driver. This is a preparation for adding new features to Exynos
> pin controller driver, like runtime power management and suspending
> individual pin controllers, which might be a part of some power domain.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Clear and elegant.
I will need an ACK from some ARM SoC person on this so they are
aware that we rip code out of mach-* to pinctrl.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
From: Linus Walleij @ 2016-12-30 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn1zHMFNiGc-wVbbkC1-JFzG3sjnnUJogtCp9EeAkWsV5A@mail.gmail.com>
On Fri, Dec 23, 2016 at 2:09 PM, M'boumba Cedric Madianga
<cedric.madianga@gmail.com> wrote:
> 2016-12-22 20:11 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
>>> @@ -337,6 +350,16 @@
>>> slew-rate = <2>;
>>> };
>>> };
>>> +
>>> + i2c1_pins_b: i2c1 at 0 {
>>> + pins1 {
>>> + pinmux = <STM32F429_PB9_FUNC_I2C1_SDA>;
>>> + drive-open-drain;
>>> + };
>>> + pins2 {
>>> + pinmux = <STM32F429_PB6_FUNC_I2C1_SCL>;
>>> + };
>>
>> the second doesn't need the open-drain property? Why?
>
> I thought that open-drain was only needed for SDA line.
> But after double-checking I2C specification, it seems that SDA and SCL
> lines need open-drain or open-collector to perform the wired-AND
> function.
I think I2C SDA/SCL must be open drain by definition.
It also requires pull-up resistors, I guess you have these mounted on the board
so you do not need pull-up from the pin controller?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Linus Walleij @ 2016-12-30 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222041328.3303-4-chris.packham@alliedtelesis.co.nz>
On Thu, Dec 22, 2016 at 5:13 AM, Chris Packham
<chris.packham@alliedtelesis.co.nz> wrote:
> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>
> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
> from Marvell.
>
> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Looks good to me, Sebastian and/or Thomas P can you ACK this patch?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 08/14] ACPI: ARM64: IORT: rework iort_node_get_id()
From: Xinwei Kong @ 2016-12-30 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-9-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> iort_node_get_id() has two output, one is the mapped ids,
> the other is the referenced parent node which is returned
> from the function.
>
> For now we need a API just return its parent node for
> single mapping, so just update this function slightly then
> reuse it later.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> drivers/acpi/arm64/iort.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ab7bae7..bc68d93 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -347,7 +347,8 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
> if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> - *id_out = map[index].output_base;
> + if (id_out)
> + *id_out = map[index].output_base;
> return parent;
> }
> }
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH 6/6] ARM64: dts: marvell: armada37xx: add pinctrl definition
From: Linus Walleij @ 2016-12-30 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222172501.16121-7-gregory.clement@free-electrons.com>
On Thu, Dec 22, 2016 at 6:25 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Start to populate the device tree of the Armada 37xx with the pincontrol
> configuration used on the board providing a dts.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +++++++
Maybe you want to take this opportunity to add gpio-line-names = ...;
to the armada 3720 pinctrl/gpiochip nodes?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 14/14] irqchip: mbigen: Add ACPI support
From: Xinwei Kong @ 2016-12-30 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-15-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> 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,
> };
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 13/14] irqchip: mbigen: introduce mbigen_of_create_domain()
From: Xinwei Kong @ 2016-12-30 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-14-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> 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;
> }
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 12/14] irqchip: mbigen: drop module owner
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-13-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Kefeng Wang <wangkefeng.wang@huawei.com>
>
> Module owner will be set by driver core, so drop it.
>
> 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 | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 03b79b0..c01ab41 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -293,7 +293,6 @@ static int mbigen_device_probe(struct platform_device *pdev)
> static struct platform_driver mbigen_platform_driver = {
> .driver = {
> .name = "Hisilicon MBIGEN-V2",
> - .owner = THIS_MODULE,
> .of_match_table = mbigen_of_match,
> },
> .probe = mbigen_device_probe,
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 11/14] msi: platform: make platform_msi_create_device_domain() ACPI aware
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-12-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the platform msi domain created for ITS, irqchip such as
> mbi-gen connecting ITS, which needs ctreate its own irqdomain.
>
> Fortunately with the platform msi support upstreamed by Marc,
> we just need to add minor code to make it run properly.
>
> platform_msi_create_device_domain() is almost ready for ACPI use
> except of_node_to_fwnode() is for dt only, make it ACPI aware then
> things will work in both DTS and ACPI.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> ---
> drivers/base/platform-msi.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
> index be6a599..035ca3b 100644
> --- a/drivers/base/platform-msi.c
> +++ b/drivers/base/platform-msi.c
> @@ -345,8 +345,7 @@ struct irq_domain *
>
> data->host_data = host_data;
> domain = irq_domain_create_hierarchy(dev->msi_domain, 0, nvec,
> - of_node_to_fwnode(dev->of_node),
> - ops, data);
> + dev->fwnode, ops, data);
> if (!domain)
> goto free_priv;
>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 10/14] ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-11-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> iort_node_get_id() for now only support NC(named componant)->SMMU
> or NC->ITS cases, we also have other device topology such NC->
> SMMU->ITS, so rework iort_node_get_id() for those cases.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> drivers/acpi/arm64/iort.c | 59 ++++++++++++++++++++++++++---------------------
> 1 file changed, 33 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 6b72fcb..9b3f268 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -292,22 +292,28 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
> return status;
> }
>
> -static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
> - u32 *rid_out)
> +static int iort_id_single_map(struct acpi_iort_id_mapping *map, u8 type,
> + u32 *rid_out)
> {
> /* Single mapping does not care for input id */
> if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> - *rid_out = map->output_base;
> + if (rid_out)
> + *rid_out = map->output_base;
> return 0;
> }
>
> pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",
> map, type);
> - return -ENXIO;
> }
>
> + return -ENXIO;
> +}
> +
> +static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
> + u32 *rid_out)
> +{
> if (rid_in < map->input_base ||
> (rid_in >= map->input_base + map->id_count))
> return -ENXIO;
> @@ -324,33 +330,34 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
> struct acpi_iort_node *parent;
> struct acpi_iort_id_mapping *map;
>
> - if (!node->mapping_offset || !node->mapping_count ||
> - index >= node->mapping_count)
> - return NULL;
> -
> - map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> - node->mapping_offset);
> + while (node) {
> + if (!node->mapping_offset || !node->mapping_count ||
> + index >= node->mapping_count)
> + return NULL;
>
> - /* Firmware bug! */
> - if (!map->output_reference) {
> - pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
> - node, node->type);
> - return NULL;
> - }
> + map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> + node->mapping_offset);
>
> - parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
> - map->output_reference);
> + /* Firmware bug! */
> + if (!map->output_reference) {
> + pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
> + node, node->type);
> + return NULL;
> + }
>
> - if (!(IORT_TYPE_MASK(parent->type) & type_mask))
> - return NULL;
> + parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
> + map->output_reference);
>
> - if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> - if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> - node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> - if (id_out)
> - *id_out = map[index].output_base;
> - return parent;
> + /* go upstream to find its parent */
> + if (!(IORT_TYPE_MASK(parent->type) & type_mask)) {
> + node = parent;
> + continue;
> }
> +
> + if (iort_id_single_map(&map[index], node->type, id_out))
> + break;
> +
> + return parent;
> }
>
> return NULL;
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-10-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the platform msi domain created, we can set up the msi domain
> for a platform device when it's probed.
>
> In order to do that, we need to get the domain that the platform
> device connecting to, so the iort_get_platform_device_domain() is
> introduced to retrieve the domain from iort.
>
> After the domain is retrieved, we need a proper way to set the
> domain to paltform device, as some platform devices such as an
> irqchip needs the msi irqdomain to be the interrupt parent domain,
> we need to get irqdomain before platform device is probed but after
> the platform device is allocated, so introduce a callback (pre_add_cb)
> in pdevinfo to prepare firmware related information which is needed
> for device probe, then set the msi domain in that callback.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/acpi/acpi_platform.c | 11 +++++++++++
> drivers/acpi/arm64/iort.c | 43 +++++++++++++++++++++++++++++++++++++++++
> drivers/base/platform.c | 3 +++
> include/linux/acpi_iort.h | 3 +++
> include/linux/platform_device.h | 3 +++
> 5 files changed, 63 insertions(+)
>
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index b4c1a6a..5d8d61b4 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -12,6 +12,7 @@
> */
>
> #include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
> #include <linux/device.h>
> #include <linux/err.h>
> #include <linux/kernel.h>
> @@ -48,6 +49,15 @@ static void acpi_platform_fill_resource(struct acpi_device *adev,
> }
>
> /**
> + * acpi_platform_pre_add_cb - callback before platform device is added, to
> + * prepare firmware related information which is needed for device probe
> + */
> +static void acpi_platform_pre_add_cb(struct device *dev)
> +{
> + acpi_configure_pmsi_domain(dev);
> +}
> +
> +/**
> * acpi_create_platform_device - Create platform device for ACPI device node
> * @adev: ACPI device node to create a platform device for.
> * @properties: Optional collection of build-in properties.
> @@ -109,6 +119,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
> pdevinfo.num_res = count;
> pdevinfo.fwnode = acpi_fwnode_handle(adev);
> pdevinfo.properties = properties;
> + pdevinfo.pre_add_cb = acpi_platform_pre_add_cb;
>
> if (acpi_dma_supported(adev))
> pdevinfo.dma_mask = DMA_BIT_MASK(32);
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index bc68d93..6b72fcb 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -527,6 +527,49 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
> return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
> }
>
> +/**
> + * iort_get_platform_device_domain() - Find MSI domain related to a
> + * platform device
> + * @dev: the dev pointer associated with the platform device
> + *
> + * Returns: the MSI domain for this device, NULL otherwise
> + */
> +static struct irq_domain *iort_get_platform_device_domain(struct device *dev)
> +{
> + struct acpi_iort_node *node, *msi_parent;
> + struct fwnode_handle *iort_fwnode;
> + struct acpi_iort_its_group *its;
> +
> + /* find its associated iort node */
> + node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
> + iort_match_node_callback, dev);
> + if (!node)
> + return NULL;
> +
> + /* then find its msi parent node */
> + msi_parent = iort_node_get_id(node, NULL, IORT_MSI_TYPE, 0);
> + if (!msi_parent)
> + return NULL;
> +
> + /* Move to ITS specific data */
> + its = (struct acpi_iort_its_group *)msi_parent->node_data;
> +
> + iort_fwnode = iort_find_domain_token(its->identifiers[0]);
> + if (!iort_fwnode)
> + return NULL;
> +
> + return irq_find_matching_fwnode(iort_fwnode, DOMAIN_BUS_PLATFORM_MSI);
> +}
> +
> +void acpi_configure_pmsi_domain(struct device *dev)
> +{
> + struct irq_domain *msi_domain;
> +
> + msi_domain = iort_get_platform_device_domain(dev);
> + if (msi_domain)
> + dev_set_msi_domain(dev, msi_domain);
> +}
> +
> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> {
> u32 *rid = data;
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index c4af003..3e68f31 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -537,6 +537,9 @@ struct platform_device *platform_device_register_full(
> goto err;
> }
>
> + if (pdevinfo->pre_add_cb)
> + pdevinfo->pre_add_cb(&pdev->dev);
> +
> ret = platform_device_add(pdev);
> if (ret) {
> err:
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index ef99fd52..33f5ac3 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -38,6 +38,7 @@
> /* IOMMU interface */
> void iort_set_dma_mask(struct device *dev);
> const struct iommu_ops *iort_iommu_configure(struct device *dev);
> +void acpi_configure_pmsi_domain(struct device *dev);
> #else
> static inline void acpi_iort_init(void) { }
> static inline bool iort_node_match(u8 type) { return false; }
> @@ -58,6 +59,8 @@ static inline void iort_set_dma_mask(struct device *dev) { }
> static inline
> const struct iommu_ops *iort_iommu_configure(struct device *dev)
> { return NULL; }
> +
> +static inline void acpi_configure_pmsi_domain(struct device *dev) { }
> #endif
>
> #define IORT_ACPI_DECLARE(name, table_id, fn) \
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 98c2a7c..280d366fb 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -74,6 +74,9 @@ struct platform_device_info {
> u64 dma_mask;
>
> struct property_entry *properties;
> +
> + /* preparation callback before the platform device is added */
> + void (*pre_add_cb)(struct device *);
> };
> extern struct platform_device *platform_device_register_full(
> const struct platform_device_info *pdevinfo);
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH 4/6] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222172501.16121-5-gregory.clement@free-electrons.com>
On Thu, Dec 22, 2016 at 6:24 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Armada 37xx SoCs can handle interrupt through GPIO. However it can
> only manage the edge ones.
>
> The way the interrupt are managed are classical so we can use the generic
> interrupt chip model.
>
> The only unusual "feature" is that many interrupts are connected to the
> parent interrupt controller. But we do not take advantage of this and use
> the chained irq with all of them.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
So this is very simple and should use GPIOLIB_IRQCHIP.
Begin with select GPIOLIB_IRQCHIP in your Kconfig and then look
at conversions such as commit 85ae9e512f437cd09bf61564bdba29ab88bab3e3
("pinctrl: bcm2835: switch to GPIOLIB_IRQCHIP")
for inspiration.
> @@ -64,6 +71,8 @@ struct armada_37xx_pinctrl {
> struct armada_37xx_pin_data *data;
> struct device *dev;
> struct gpio_chip gpio_chip;
> + struct irq_chip irq_chip;
> + struct irq_domain *domain;
You don't need a domain when using GPIOLIB_IRQCHIP
> +static int armada_37xx_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
> +
> + return irq_create_mapping(info->domain, offset);
> +}
Nor this.
The irqchip code should be pretty much the same but you need to
dereference gpio_chip from chip data and pick the irqchip from
there.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 07/14] irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain
From: Xinwei Kong @ 2016-12-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-8-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the introduction of its_pmsi_init_one(), we can add some code
> on top for ACPI support of platform MSI.
>
> We are scanning the MADT table to get the ITS entry(ies), then use
> the information to create the platform msi domain for devices connect
> to it, just like the PCI MSI for ITS did.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 36 +++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index ff72704..0be0437 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -105,6 +105,41 @@ static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,
> return 0;
> }
>
> +#ifdef CONFIG_ACPI
> +static int __init
> +its_pmsi_parse_madt(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_translator *its_entry;
> + struct fwnode_handle *domain_handle;
> + const char *node_name;
> + int err = -ENXIO;
> +
> + its_entry = (struct acpi_madt_generic_translator *)header;
> + node_name = kasprintf(GFP_KERNEL, "ITS at 0x%lx",
> + (long)its_entry->base_address);
> + domain_handle = iort_find_domain_token(its_entry->translation_id);
> + if (!domain_handle) {
> + pr_err("%s: Unable to locate ITS domain handle\n", node_name);
> + goto out;
> + }
> +
> + err = its_pmsi_init_one(domain_handle, node_name);
> +
> +out:
> + kfree(node_name);
> + return err;
> +}
> +
> +static void __init its_acpi_pmsi_init(void)
> +{
> + acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> + its_pmsi_parse_madt, 0);
> +}
> +#else
> +static inline void its_acpi_pmsi_init(void) { }
> +#endif
> +
> static void __init its_pmsi_of_init(void)
> {
> struct device_node *np;
> @@ -121,6 +156,7 @@ static void __init its_pmsi_of_init(void)
> static int __init its_pmsi_init(void)
> {
> its_pmsi_of_init();
> + its_acpi_pmsi_init();
> return 0;
> }
> early_initcall(its_pmsi_init);
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 06/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
From: Xinwei Kong @ 2016-12-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-7-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Introduce its_pmsi_init_one() to refactor the code to isolate
> ACPI&DT common code to prepare for ACPI later.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 45 ++++++++++++++++-----------
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index 16587a9..ff72704 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -84,34 +84,43 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> {},
> };
>
> -static int __init its_pmsi_init(void)
> +static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,
> + const char *name)
> {
> - struct device_node *np;
> struct irq_domain *parent;
>
> + parent = irq_find_matching_fwnode(fwnode, DOMAIN_BUS_NEXUS);
> + if (!parent || !msi_get_domain_info(parent)) {
> + pr_err("%s: unable to locate ITS domain\n", name);
> + return -ENXIO;
> + }
> +
> + if (!platform_msi_create_irq_domain(fwnode, &its_pmsi_domain_info,
> + parent)) {
> + pr_err("%s: unable to create platform domain\n", name);
> + return -ENXIO;
> + }
> +
> + pr_info("Platform MSI: %s domain created\n", name);
> + return 0;
> +}
> +
> +static void __init its_pmsi_of_init(void)
> +{
> + struct device_node *np;
> +
> for (np = of_find_matching_node(NULL, its_device_id); np;
> np = of_find_matching_node(np, its_device_id)) {
> if (!of_property_read_bool(np, "msi-controller"))
> continue;
>
> - parent = irq_find_matching_host(np, DOMAIN_BUS_NEXUS);
> - if (!parent || !msi_get_domain_info(parent)) {
> - pr_err("%s: unable to locate ITS domain\n",
> - np->full_name);
> - continue;
> - }
> -
> - if (!platform_msi_create_irq_domain(of_node_to_fwnode(np),
> - &its_pmsi_domain_info,
> - parent)) {
> - pr_err("%s: unable to create platform domain\n",
> - np->full_name);
> - continue;
> - }
> -
> - pr_info("Platform MSI: %s domain created\n", np->full_name);
> + its_pmsi_init_one(of_node_to_fwnode(np), np->full_name);
> }
> +}
>
> +static int __init its_pmsi_init(void)
> +{
> + its_pmsi_of_init();
> return 0;
> }
> early_initcall(its_pmsi_init);
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 05/14] ACPI: platform-msi: retrieve dev id from IORT
From: Xinwei Kong @ 2016-12-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-6-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> For devices connecting to ITS, it needs dev id to identify
> itself, and this dev id is represented in the IORT table in
> named componant node [1] for platform devices, so in this
> patch we will scan the IORT to retrieve device's dev id.
>
> Introduce iort_pmsi_get_dev_id() with pointer dev passed
> in for that purpose.
>
> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/acpi/arm64/iort.c | 26 ++++++++++++++++++++++++++
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 4 +++-
> include/linux/acpi_iort.h | 8 ++++++++
> 3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 174e983..ab7bae7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -444,6 +444,32 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> }
>
> /**
> + * iort_pmsi_get_dev_id() - Get the device id for a device
> + * @dev: The device for which the mapping is to be done.
> + * @dev_id: The device ID found.
> + *
> + * Returns: 0 for successful find a dev id, errors otherwise
> + */
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> + struct acpi_iort_node *node;
> +
> + if (!iort_table)
> + return -ENODEV;
> +
> + node = iort_find_dev_node(dev);
> + if (!node) {
> + dev_err(dev, "can't find related IORT node\n");
> + return -ENODEV;
> + }
> +
> + if(!iort_node_get_id(node, dev_id, IORT_MSI_TYPE, 0))
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> +/**
> * iort_dev_find_its_id() - Find the ITS identifier for a device
> * @dev: The device.
> * @req_id: Device's Requster ID
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index 3c94278..16587a9 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -15,6 +15,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/acpi_iort.h>
> #include <linux/device.h>
> #include <linux/msi.h>
> #include <linux/of.h>
> @@ -56,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
>
> msi_info = msi_get_domain_info(domain->parent);
>
> - ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
> + ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :
> + iort_pmsi_get_dev_id(dev, &dev_id);
> if (ret)
> return ret;
>
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 77e0809..ef99fd52 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -33,6 +33,7 @@
> void acpi_iort_init(void);
> bool iort_node_match(u8 type);
> u32 iort_msi_map_rid(struct device *dev, u32 req_id);
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
> struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
> /* IOMMU interface */
> void iort_set_dma_mask(struct device *dev);
> @@ -42,9 +43,16 @@ static inline void acpi_iort_init(void) { }
> static inline bool iort_node_match(u8 type) { return false; }
> static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> { return req_id; }
> +
> static inline struct irq_domain *iort_get_device_domain(struct device *dev,
> u32 req_id)
> { return NULL; }
> +
> +static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> + return -ENODEV;
> +}
> +
> /* IOMMU interface */
> static inline void iort_set_dma_mask(struct device *dev) { }
> static inline
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 04/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
From: Xinwei Kong @ 2016-12-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-5-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Adding ACPI support for platform MSI, we need to retrieve the
> dev id in ACPI way instead of device tree, we already have
> a well formed function its_pmsi_prepare() to get the dev id
> but it's OF dependent, so collect OF related code and put them
> into a single function to make its_pmsi_prepare() more friendly
> to ACPI later.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 23 ++++++++++++++++-------
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index 470b4aa..3c94278 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -24,15 +24,11 @@
> .name = "ITS-pMSI",
> };
>
> -static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> - int nvec, msi_alloc_info_t *info)
> +static int of_pmsi_get_dev_id(struct irq_domain *domain, struct device *dev,
> + u32 *dev_id)
> {
> - struct msi_domain_info *msi_info;
> - u32 dev_id;
> int ret, index = 0;
>
> - msi_info = msi_get_domain_info(domain->parent);
> -
> /* Suck the DeviceID out of the msi-parent property */
> do {
> struct of_phandle_args args;
> @@ -43,11 +39,24 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> if (args.np == irq_domain_get_of_node(domain)) {
> if (WARN_ON(args.args_count != 1))
> return -EINVAL;
> - dev_id = args.args[0];
> + *dev_id = args.args[0];
> break;
> }
> } while (!ret);
>
> + return ret;
> +}
> +
> +static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> + int nvec, msi_alloc_info_t *info)
> +{
> + struct msi_domain_info *msi_info;
> + u32 dev_id;
> + int ret;
> +
> + msi_info = msi_get_domain_info(domain->parent);
> +
> + ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
> if (ret)
> return ret;
>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 03/14] ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()
From: Xinwei Kong @ 2016-12-30 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-4-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> We are missing req_id's comment for iort_dev_find_its_id(),
> add it back.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/acpi/arm64/iort.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 46e2d82..174e983 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -446,6 +446,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> /**
> * iort_dev_find_its_id() - Find the ITS identifier for a device
> * @dev: The device.
> + * @req_id: Device's Requster ID
> * @idx: Index of the ITS identifier list.
> * @its_id: ITS identifier.
> *
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ 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