* [PATCH 5/5] iommu/mediatek: Fix M4Uv1 group refcounting
From: Robin Murphy @ 2016-11-09 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu_v1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index b8aeb0768483..1b736990373f 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -502,6 +502,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ __iommu_group_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus
From: Lars-Peter Clausen @ 2016-11-09 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87eg2ly8k6.fsf@belgarion.home>
On 11/08/2016 10:18 PM, Robert Jarzmik wrote:
[...]
>>> +/**
>>> + * struct ac97_controller - The AC97 controller of the AC-Link
>>> + * @ops: the AC97 operations.
>>> + * @controllers: linked list of all existing controllers.
>>> + * @dev: the device providing the AC97 controller.
>>> + * @slots_available: the mask of accessible/scanable codecs.
>>> + * @codecs: the 4 possible AC97 codecs (NULL if none found).
>>> + * @codecs_pdata: platform_data for each codec (NULL if no pdata).
>>> + *
>>> + * This structure is internal to AC97 bus, and should not be used by the
>>> + * controllers themselves, excepting for using @dev.
>>> + */
>>> +struct ac97_controller {
>>> + const struct ac97_controller_ops *ops;
>>> + struct list_head controllers;
>>> + struct device *dev;
>>
>> I'd make the controller itself a struct dev, rather than just having the
>> pointer to the parent. This is more idiomatic and matches what other
>> subsystems do. It has several advantages, you get proper refcounting of your
>> controller structure, the controller gets its own sysfs directory where the
>> CODECs appear as children, you don't need the manual sysfs attribute
>> creation and removal in ac97_controler_{un,}register().
>
> If you mean having "struct device dev" instead of "struct device *dev", it has
> also a drawback : all the legacy platforms have already a probing method, be
> that platform data, device-tree or something else.
>
> I'm a bit converned about the conversion toll. Maybe I've not understood your
> point fully, so please feel free to explain, with an actual example even better.
This would be a struct device that is not bound to a driver, but just acts
as a shell for the controller and places it inside the device hierarchy. You
get reference counting and other management functions as well as a
consistent naming scheme. E.g. you can call the devices ac97c%d (or
something similar) and then call the CODEC ac97c%d.%d.
This is how most frameworks implementing some kind of control bus are
structured in the Linux kernel. E.g. take a look at I2C or SPI.
Your controller driver itself is unaffected by this, you still call
snd_ac97_controller_register() from the probe function and so on.
>
>>> + void (*wait)(struct ac97_controller *adrv, int slot);
>>> + void (*init)(struct ac97_controller *adrv, int slot);
>>
>> Neither wait nor init are ever used.
> This is because I've not begun to porting sound/pci/ac97_codec.c into
> sound/ac97.
Ok, makes sense. But maybe just leave them out for now and add them when
they are used.
[...]
>>> + ret = sysfs_create_link(&codec->dev.kobj, &ac97_ctrl->dev->kobj,
>>> + "ac97_controller");
>>
>> Since the CODEC is a child of the controller this should not be necessary as
>> this just points one directory up. It's like `ln -s .. parent`
> This creates :
> /sys/bus/ac97/devices/pxa2xx-ac97\:0/ac97_controller
>
> Of course as you pointed out, it's a 'ln -s .. parent' like link, but it seems
> to me very unfriendly to have :
> - /sys/bus/ac97/devices/pxa2xx-ac97\:0/../ac97_operations
> - while /sys/bus/ac97/devices/ac97_operations doesn't exist (obviously)
>
> Mmm, I don't know for this one, my mind is not set, it's a bit hard to tell if
> it's only an unecessary link bringing "comfort", or something usefull.
It is additional ABI and we do not have this for any other bus either (e.g.
you don't see a backlink for a I2C or SPI device to the parent). In my
opinion for the sake of keeping things consistent and simple we should not
add this.
>>
>>> + if (ret)
>>> + goto err_unregister_device;
>>> +
>>> + return 0;
>>> +err_unregister_device:
>>> + put_device(&codec->dev);
>>> +err_free_codec:
>>> + kfree(codec);
>>
>> Since the struct is reference counted, the freeing is done in the release
>> callback and this leads to a double free.
> A yes in the "goto err_unregister_device" case right, while it's necessary in
> the "goto err_free_codec" case ... I need to rework that a bit.
It should use put_device() in both cases, check the the device_register()
documentation. It says that put_device() must be used, even if
device_register() fails.
>
>>> +int snd_ac97_codec_driver_register(struct ac97_codec_driver *drv)
>>> +{
>>> + int ret;
>>> +
>>> + drv->driver.bus = &ac97_bus_type;
>>> +
>>> + ret = driver_register(&drv->driver);
>>> + if (!ret)
>>> + ac97_rescan_all_controllers();
>>
>> Rescanning the bus when a new codec driver is registered should not be
>> neccessary. The bus is scanned once when the controller is registered, this
>> creates the device. The device driver core will take care of binding the
>> device to the driver, if the driver is registered after thed evice.
> That's because you suppose the initial scanning found all the ac97 codecs.
> But that's an incomplete vision as a codec might be powered off at that time and
> not seen by the first scanning, while the new scanning will discover it.
But why would the device become suddenly visible when the driver is
registered. This seems to be an as arbitrary point in time as any other.
Also consider that when you build a driver as a module, the module will
typically only be auto-loaded after the device has been detected, based on
the device ID. On the other hand, if the driver is built-in driver
registration will happen either before or shortly after the controller
registration.
If there is the expectation that the AC97 CODEC might randomly appear on the
bus, the core should periodically scan the bus.
[...]
>>> + ac97_ctrl->ops->warm_reset(ac97_ctrl);
>>> + return len;
>>> +}
>>> +static DEVICE_ATTR_WO(warm_reset);
>>> +
>>> +static struct attribute *ac97_controller_device_attrs[] = {
>>> + &dev_attr_cold_reset.attr,
>>> + &dev_attr_warm_reset.attr,
>>> + NULL
>>> +};
>>
>> This adds new userspace ABI that is not documented at the moment.
> Very true. And as all userspace interface, it needs to be discussed. If nobody
> complains, I'll add the documentation for next patch round.
>>
>>> +int snd_ac97_controller_register(const struct ac97_controller_ops *ops,
>>> + struct device *dev,
>>> + unsigned short slots_available,
>>> + void **codecs_pdata)
>>
>> In my opinion this should return a handle to a ac97 controller which can
>> then be passed to snd_ac97_controller_unregister(). This is in my opinion
>> the better approach rather than looking up the controller by parent device.
> This is another "legacy drivers" issue.
>
> The legacy driver (the one probed by platform_data or devicetree) doesn't
> necessarily have a private structure to store this ac97_controller pointer.
I might be missing something, but I'm not convinced by this. Can you point
me to such a legacy driver where you think this would not work?
^ permalink raw reply
* [PATCH v2 0/9] rockchip: add more power domain and devices dts for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Please allow me to integrate these patches.
They are missing or losing for upstream, then there are some patches
are always depending on them.
The following patches are releated to PD.
git log --oneline
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip: support dwc3 USB for rk3399
3ced49c arm64: dts: rockchip: add pd_edp node for rk3399
e19db3f arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
eb92079 arm64: dts: rockchip: add backlight support for rk3399 evb board
20b8135 arm64: dts: rockchip: add eDP device node for rk3399
480a1bb arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
4964c0a arm64: dts: rockchip: add pd_sd power node for rk3399
c407a4c arm64: dts: rockchip: add eMMC's power domain support for rk3399
----
Hi Heiko & guys,
This series patches support the below PDs.
1) sd & emmc pd
4964c0a arm64: dts: rockchip: add pd_sd power node for rk3399
c407a4c arm64: dts: rockchip: add eMMC's power domain support for rk3399
2) edp pd
3ced49c arm64: dts: rockchip: add pd_edp node for rk3399
e19db3f arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
eb92079 arm64: dts: rockchip: add backlight support for rk3399 evb board
20b8135 arm64: dts: rockchip: add eDP device node for rk3399
480a1bb arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
3) usb3 pd
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip: support dwc3 USB for rk3399
Thanks,
Caesar
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review.googlesource.com/386483
- Verified on ChromeOS kernel4.4
- Yakir posted the original patch on
- https://patchwork.kernel.org/patch/9191777
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
- Reviewed-on: https://chromium-review.googlesource.com/384280
Brian Norris (1):
arm64: dts: rockchip: support dwc3 USB for rk3399
Caesar Wang (1):
arm64: dts: rockchip: add the usb3 pd for rk3399
Mark Yao (1):
arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
Yakir Yang (3):
arm64: dts: rockchip: add eDP device node for rk3399
arm64: dts: rockchip: add backlight support for rk3399 evb board
arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
Ziyuan Xu (1):
arm64: dts: rockchip: add eMMC's power domain support for rk3399
zhangqing (2):
arm64: dts: rockchip: add pd_sd power node for rk3399
arm64: dts: rockchip: add pd_edp node for rk3399
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40 ++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 210 ++++++++++++++++++++++++++++
2 files changed, 250 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Ziyuan Xu <xzy.xu@rock-chips.com>
Control power domain for eMMC via genpd to reduce power consumption.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index cbb7f8b..b401176 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -269,6 +269,7 @@
#clock-cells = <0>;
phys = <&emmc_phy>;
phy-names = "phy_arasan";
+ power-domains = <&power RK3399_PD_EMMC>;
status = "disabled";
};
@@ -690,6 +691,11 @@
status = "disabled";
};
+ qos_emmc: qos at ffa58000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa58000 0x0 0x20>;
+ };
+
qos_gmac: qos at ffa5c000 {
compatible = "syscon";
reg = <0x0 0xffa5c000 0x0 0x20>;
@@ -823,6 +829,11 @@
};
/* These power domains are grouped by VD_LOGIC */
+ pd_emmc at RK3399_PD_EMMC {
+ reg = <RK3399_PD_EMMC>;
+ clocks = <&cru ACLK_EMMC>;
+ pm_qos = <&qos_emmc>;
+ };
pd_gmac at RK3399_PD_GMAC {
reg = <RK3399_PD_GMAC>;
clocks = <&cru ACLK_GMAC>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: zhangqing <zhangqing@rock-chips.com>
1.add pd node for RK3399 Soc
2.create power domain tree
3.add qos node for domain
4.add the pd_sd consumers node
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review.googlesource.com/386483
- Verified on ChromeOS kernel4.4
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b401176..e5b5b3d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -253,6 +253,7 @@
<&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
+ power-domains = <&power RK3399_PD_SD>;
status = "disabled";
};
@@ -691,6 +692,11 @@
status = "disabled";
};
+ qos_sd: qos at ffa74000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa74000 0x0 0x20>;
+ };
+
qos_emmc: qos at ffa58000 {
compatible = "syscon";
reg = <0x0 0xffa58000 0x0 0x20>;
@@ -839,6 +845,12 @@
clocks = <&cru ACLK_GMAC>;
pm_qos = <&qos_gmac>;
};
+ pd_sd at RK3399_PD_SD {
+ reg = <RK3399_PD_SD>;
+ clocks = <&cru HCLK_SDMMC>,
+ <&cru SCLK_SDMMC>;
+ pm_qos = <&qos_sd>;
+ };
pd_vio at RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Mark Yao <mark.yao@rock-chips.com>
Add the core display-subsystem node and the two display controllers
available on the rk3399.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58 ++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e5b5b3d..f1d289a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1290,6 +1290,64 @@
status = "disabled";
};
+ vopl: vop at ff8f0000 {
+ compatible = "rockchip,rk3399-vop-lit";
+ reg = <0x0 0xff8f0000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopl_mmu>;
+ status = "disabled";
+
+ vopl_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vopl_mmu: iommu at ff8f3f00 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff8f3f00 0x0 0x100>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vopl_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ vopb: vop at ff900000 {
+ compatible = "rockchip,rk3399-vop-big";
+ reg = <0x0 0xff900000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopb_mmu>;
+ status = "disabled";
+
+ vopb_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vopb_mmu: iommu at ff903f00 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff903f00 0x0 0x100>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vopb_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ display_subsystem: display-subsystem {
+ compatible = "rockchip,display-subsystem";
+ ports = <&vopl_out>, <&vopb_out>;
+ status = "disabled";
+ };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <&grf>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/9] arm64: dts: rockchip: add eDP device node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Yakir Yang <ykk@rock-chips.com>
Add rk3399 eDP device node, and connect to VOP device node with
remote endpoint.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(Caesar rebase the lastest and solve the conflict)
---
Changes in v2:
- Yakir posted the original patch on
- https://patchwork.kernel.org/patch/9191777
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 52 ++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index f1d289a..6544910 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1304,6 +1304,11 @@
vopl_out: port {
#address-cells = <1>;
#size-cells = <0>;
+
+ vopl_out_edp: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&edp_in_vopl>;
+ };
};
};
@@ -1330,6 +1335,11 @@
vopb_out: port {
#address-cells = <1>;
#size-cells = <0>;
+
+ vopb_out_edp: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&edp_in_vopb>;
+ };
};
};
@@ -1342,6 +1352,41 @@
status = "disabled";
};
+ edp: edp at ff970000 {
+ compatible = "rockchip,rk3399-edp";
+ reg = <0x0 0xff970000 0x0 0x8000>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ resets = <&cru SRST_P_EDP_CTRL>;
+ reset-names = "dp";
+ rockchip,grf = <&grf>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_hpd>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in: port at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in_vopb: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+
+ edp_in_vopl: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+ };
+ };
+
display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
ports = <&vopl_out>, <&vopb_out>;
@@ -1469,6 +1514,13 @@
};
};
+ edp {
+ edp_hpd: edp-hpd {
+ rockchip,pins =
+ <4 23 RK_FUNC_2 &pcfg_pull_none>;
+ };
+ };
+
gmac {
rgmii_pins: rgmii-pins {
rockchip,pins =
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/9] arm64: dts: rockchip: add backlight support for rk3399 evb board
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Yakir Yang <ykk@rock-chips.com>
Add backlight node for evb board, perpare for panel device node.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40 +++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index 8e82497..c585e93 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -49,6 +49,46 @@
compatible = "rockchip,rk3399-evb", "rockchip,rk3399",
"google,rk3399evb-rev2";
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm0 0 25000 0>;
+ brightness-levels = <
+ 0 1 2 3 4 5 6 7
+ 8 9 10 11 12 13 14 15
+ 16 17 18 19 20 21 22 23
+ 24 25 26 27 28 29 30 31
+ 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47
+ 48 49 50 51 52 53 54 55
+ 56 57 58 59 60 61 62 63
+ 64 65 66 67 68 69 70 71
+ 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87
+ 88 89 90 91 92 93 94 95
+ 96 97 98 99 100 101 102 103
+ 104 105 106 107 108 109 110 111
+ 112 113 114 115 116 117 118 119
+ 120 121 122 123 124 125 126 127
+ 128 129 130 131 132 133 134 135
+ 136 137 138 139 140 141 142 143
+ 144 145 146 147 148 149 150 151
+ 152 153 154 155 156 157 158 159
+ 160 161 162 163 164 165 166 167
+ 168 169 170 171 172 173 174 175
+ 176 177 178 179 180 181 182 183
+ 184 185 186 187 188 189 190 191
+ 192 193 194 195 196 197 198 199
+ 200 201 202 203 204 205 206 207
+ 208 209 210 211 212 213 214 215
+ 216 217 218 219 220 221 222 223
+ 224 225 226 227 228 229 230 231
+ 232 233 234 235 236 237 238 239
+ 240 241 242 243 244 245 246 247
+ 248 249 250 251 252 253 254 255>;
+ default-brightness-level = <200>;
+ enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ };
+
clkin_gmac: external-gmac-clock {
compatible = "fixed-clock";
clock-frequency = <125000000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 6/9] arm64: dts: rockchip: introduce pclk_vio_grf in eDP device node
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Yakir Yang <ykk@rock-chips.com>
The pclk_vio_grf supply power for VIO GRF IOs, if it is disabled, driver
would failed to operate the VIO GRF registers.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 6544910..74deb44 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1356,8 +1356,8 @@
compatible = "rockchip,rk3399-edp";
reg = <0x0 0xff970000 0x0 0x8000>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>;
- clock-names = "dp", "pclk";
+ clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>, <&cru PCLK_VIO_GRF>;
+ clock-names = "dp", "pclk", "grf";
resets = <&cru SRST_P_EDP_CTRL>;
reset-names = "dp";
rockchip,grf = <&grf>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 7/9] arm64: dts: rockchip: add pd_edp node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: zhangqing <zhangqing@rock-chips.com>
1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain
4. add the pd support for edp
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 74deb44..09ebf4e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -835,6 +835,10 @@
};
/* These power domains are grouped by VD_LOGIC */
+ pd_edp at RK3399_PD_EDP {
+ reg = <RK3399_PD_EDP>;
+ clocks = <&cru PCLK_EDP_CTRL>;
+ };
pd_emmc at RK3399_PD_EMMC {
reg = <RK3399_PD_EMMC>;
clocks = <&cru ACLK_EMMC>;
@@ -1364,6 +1368,7 @@
status = "disabled";
pinctrl-names = "default";
pinctrl-0 = <&edp_hpd>;
+ power-domains = <&power RK3399_PD_EDP>;
ports {
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 8/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Caesar Wang @ 2016-11-09 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Brian Norris <briannorris@chromium.org>
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 54 ++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 09ebf4e..3659c56 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -353,6 +353,60 @@
status = "disabled";
};
+ usbdrd3_0: usb at fe800000 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+ <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_0: dwc3 at fe800000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe800000 0x0 0x100000>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
+ dr_mode = "otg";
+ phys = <&tcphy0_usb3>;
+ phy-names = "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,xhci-slow-suspend-quirk;
+ status = "disabled";
+ };
+ };
+
+ usbdrd3_1: usb at fe900000 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
+ <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_1: dwc3 at fe900000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe900000 0x0 0x100000>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
+ dr_mode = "host";
+ phys = <&tcphy1_usb3>;
+ phy-names = "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,xhci-slow-suspend-quirk;
+ status = "disabled";
+ };
+ };
+
gic: interrupt-controller at fee00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <4>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 9/9] arm64: dts: rockchip: add the usb3 pd for rk3399
From: Caesar Wang @ 2016-11-09 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain
4. add the pd support for usb3
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/384280
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 3659c56..7480fa7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -376,6 +376,7 @@
snps,dis_u2_susphy_quirk;
snps,dis-del-phy-power-chg-quirk;
snps,xhci-slow-suspend-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
status = "disabled";
};
};
@@ -403,6 +404,7 @@
snps,dis_u2_susphy_quirk;
snps,dis-del-phy-power-chg-quirk;
snps,xhci-slow-suspend-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
status = "disabled";
};
};
@@ -746,6 +748,16 @@
status = "disabled";
};
+ qos_usb_otg0: qos at ffa70000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa70000 0x0 0x20>;
+ };
+
+ qos_usb_otg1: qos at ffa70080 {
+ compatible = "syscon";
+ reg = <0x0 0xffa70080 0x0 0x20>;
+ };
+
qos_sd: qos at ffa74000 {
compatible = "syscon";
reg = <0x0 0xffa74000 0x0 0x20>;
@@ -909,6 +921,12 @@
<&cru SCLK_SDMMC>;
pm_qos = <&qos_sd>;
};
+ pd_usb3 at RK3399_PD_USB3 {
+ reg = <RK3399_PD_USB3>;
+ clocks = <&cru ACLK_USB3>;
+ pm_qos = <&qos_usb_otg0>,
+ <&qos_usb_otg1>;
+ };
pd_vio at RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration
From: Tomasz Nowicki @ 2016-11-09 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018160414.1228-14-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On 18.10.2016 18:04, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to configure platform devices for
> ARM SMMU components.
>
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU components, so that the ARM SMMU driver can
> initialize its respective platform device by relying on the IORT
> kernel infrastructure and by adding a corresponding ACPI device
> early probe section entry.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/arm-smmu.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/acpi_iort.h | 3 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ea90bc8..04cc5f7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -548,6 +548,78 @@ static bool __init arm_smmu_v3_is_coherent(struct acpi_iort_node *node)
> return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
> }
>
[...]
> +
> +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + struct device *dev = smmu->dev;
> + struct acpi_iort_node *node =
> + *(struct acpi_iort_node **)dev_get_platdata(dev);
> + struct acpi_iort_smmu *iort_smmu;
> + u64 *glb_irq;
> + int ret;
> +
> + /* Retrieve SMMU1/2 specific data */
> + iort_smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> + ret = acpi_smmu_get_data(iort_smmu->model, &smmu->version,
> + &smmu->model);
> + if (ret < 0)
> + return ret;
> +
> + glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
> + iort_smmu->global_interrupt_offset);
One bug that I found:
- glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
- iort_smmu->global_interrupt_offset);
+ glb_irq = ACPI_ADD_PTR(u64, node,
+ iort_smmu->global_interrupt_offset);
With this fix, I run VM with several PCI devices (NIC, SATA) in
passthrough mode successfully on ACPI host using ThunderX 1-socket board.
Also, for my tests I used Eric's patches:
https://github.com/eauger/linux/commits/v4.9-rc3-reserved-rfc-v2
Including bug fix above:
Tested-by: Tomasz Nowicki <tn@semihalf.com> for all series.
> +
> + if (!IORT_IRQ_MASK(glb_irq[1])) /* 0 means not implemented */
> + smmu->num_global_irqs = 1;
> + else
> + smmu->num_global_irqs = 2;
> +
> + if (iort_smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK)
> + smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
> +
> + return 0;
> +}
> +#else
> +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
Thanks,
Tomasz
^ permalink raw reply
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-09 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdV4HG0aOr4Qp_OZXU=3jLeOJ2QaMKp09a3v4489ABbRcA@mail.gmail.com>
Hi Arnd,
On Mon, Nov 7, 2016 at 10:35 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>> Some Renesas SoCs may exist in different revisions, providing slightly
>> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
>> (errate and quirks). This needs to be catered for by drivers and/or
>> platform code. The recently proposed soc_device_match() API seems like
>> a good fit to handle this.
>>
>> This patch series implements the core infrastructure to provide SoC and
>> revision information through the SoC bus for Renesas ARM SoCs. It
>> consists of 7 patches:
>> - Patches 1-4 provide soc_device_match(), with some related fixes,
>> - Patches 5-7 implement identification of Renesas SoCs and
>> registration with the SoC bus,
>>
>> Changes compared to v1:
>> - Add Acked-by,
>> - New patches:
>> - "[4/7] base: soc: Provide a dummy implementation of
>> soc_device_match()",
>> - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
>> - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
>> (more similar patches available, I'm not yet spamming you all
>> with them),
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>> - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
>> devices with other SoCs,
>> - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
>> M1A: not accessible from the ARM core?),
>> - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
>> for SoCs that provide a chip ID register,
>> - Build renesas-soc only if SOC_BUS is enabled,
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>> - Remove verification of product IDs; just print the ID instead,
>> - Don't register the SoC bus if the chip ID register is missing,
>> - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
>> both).
>>
>> Merge strategy:
>> - In theory, patches 1-4 should go through Greg's driver core tree.
>> But it's a hard dependency for all users.
>> If people agree, I can provide an immutable branch in my
>> renesas-drivers repository, to be merged by all interested parties.
>> So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
> Shall I create the immutable branch now?
Arnd: are you happy with the new patches and changes?
Thanks again!
>> - Patches 5-7 obviously have to go through Simon's Renesas tree (after
>> merging the soc_device_match() core), and arm-soc.
>>
>> Tested on (machine, soc_id, optional revision):
>> EMEV2 KZM9D Board, emev2
>> Genmai, r7s72100
>> APE6EVM, r8a73a4, ES1.0
>> armadillo 800 eva, r8a7740, ES2.0
>> bockw, r8a7778
>> marzen, r8a7779, ES1.0
>> Lager, r8a7790, ES1.0
>> Koelsch, r8a7791, ES1.0
>> Porter, r8a7791, ES3.0
>> Blanche, r8a7792, ES1.1
>> Gose, r8a7793, ES1.0
>> Alt, r8a7794, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
>> Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
>> KZM-A9-GT, sh73a0, ES2.0
>>
>> For your convenience, this series (incl. more DT updates to add device
>> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
>> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
>> repository at
>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
>> Its first user is support for R-Car H3 ES2.0 in branch
>> topic/r8a7795-es2-v1-rebased2.
>>
>> Thanks for your comments!
>>
>> Arnd Bergmann (1):
>> base: soc: Introduce soc_device_match() interface
>>
>> Geert Uytterhoeven (6):
>> base: soc: Early register bus when needed
>> base: soc: Check for NULL SoC device attributes
>> base: soc: Provide a dummy implementation of soc_device_match()
>> ARM: shmobile: Document DT bindings for CCCR and PRR
>> arm64: dts: r8a7795: Add device node for PRR
>> soc: renesas: Identify SoC and register with the SoC bus
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: One Thousand Gnomes @ 2016-11-09 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2368890.jTbyGqYR0M@wuerfel>
> I think it is a relatively safe assumption that there is only one
> ISA bridge. A lot of old drivers hardcode PIO or memory addresses
It's not a safe assumption for x86 at least. There are a few systems with
multiple ISA busses particularly older laptops with a docking station.
> when talking to an ISA device, so having multiple instances is
> already problematic.
PCMCIA devices handle it themselves so are ok. I'm not clear how the dual
PIIX4 configuration used in the older IBM laptop docks actually worked so
I assume the transaction went out of both bridges and providing one of
them responded the other kept silent as you simply stuffed the card into
the dock and it worked.
Alan
^ permalink raw reply
* [PATCH 11/13] ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-09 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103062135.10697-12-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:33 CET schrieb Jaehoon Chung:
> In drivers/mmc/core/host.c, there is "max-frequency" property.
> It should be same behavior. So use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
looks good, my veyron-pinky and rk3036-kylin still seem to work and hopefully
I haven't missed any spelling errors in the properties :-), so applied to my
dts32 branch for 4.10
Thanks
Heiko
^ permalink raw reply
* [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP
From: ayaka @ 2016-11-09 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16dfbe16-eae7-8da9-4108-07e623210d35@rock-chips.com>
On 10/28/2016 05:29 PM, Randy Li wrote:
>
>
> On 10/28/2016 05:11 PM, Shawn Lin wrote:
>> On 2016/10/23 3:18, Randy Li wrote:
>>> I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
>>> RK3288, once trying to enable the pclk clock, the kernel would dead.
>>> This patch would try to enable them first. The eDP_AVDD_1V8 more
>>> likely to be applied to eDP phy, but I have no time to confirmed
>>> it yet.
>>
>> Comfirm it or at least someone should be able to answer your
>> question, Mark?
> I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a
short time.
>>
>> Have you considered to add some details about vcc-supply and vccio-
>> supply for your analogix_dp-rockchip.txt ?
>>
>> From your commit msg, these two properties are more likely to be
>> required but the code itself tell me them should be optional(from the
>> point of backward compatibility, it should also be optinoal).
> Yes, I keep it optional for the same reason. Most of boards won't turn
> off those power supply and may use some fixed regulators.
>>
>>>
>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>> ---
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
>>> +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index 8548e82..6bf0441 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -17,6 +17,7 @@
>>> #include <linux/of_device.h>
>>> #include <linux/of_graph.h>
>>> #include <linux/regmap.h>
>>> +#include <linux/regulator/consumer.h>
>>> #include <linux/reset.h>
>>> #include <linux/clk.h>
>>>
>>> @@ -70,6 +71,7 @@ struct rockchip_dp_device {
>>> struct clk *grfclk;
>>> struct regmap *grf;
>>> struct reset_control *rst;
>>> + struct regulator_bulk_data supplies[2];
>>>
>>> struct work_struct psr_work;
>>> spinlock_t psr_lock;
>>> @@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> cancel_work_sync(&dp->psr_work);
>>>
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret) {
>>> + dev_err(dp->dev, "failed to enable vdd supply %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>> @@ -168,6 +177,9 @@ static int rockchip_dp_powerdown(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> clk_disable_unprepare(dp->pclk);
>>>
>>> + regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
>>> rockchip_dp_device *dp)
>>> return PTR_ERR(dp->rst);
>>> }
>>>
>>> + dp->supplies[0].supply = "vcc";
>>> + dp->supplies[1].supply = "vccio";
>>> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to get regulators: %d\n", ret);
>>> + }
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable regulators: %d\n", ret);
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>>
>>
>>
>
^ permalink raw reply
* [PATCH 1/5] iommu: Allow taking a reference on a group directly
From: Sricharan @ 2016-11-09 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
Hi,
>-----Original Message-----
>From: Robin Murphy [mailto:robin.murphy at arm.com]
>Sent: Wednesday, November 09, 2016 6:17 PM
>To: joro at 8bytes.org
>Cc: will.deacon at arm.com; sricharan at codeaurora.org; iommu at lists.linux-foundation.org; linux-arm-kernel at lists.infradead.org
>Subject: [PATCH 1/5] iommu: Allow taking a reference on a group directly
>
>iommu_group_get_for_dev() expects that the IOMMU driver's device_group
>callback return a group with a reference held for the given device.
>Whilst allocating a new group is fine, and pci_device_group() correctly
>handles reusing an existing group, there is no general means for IOMMU
>drivers doing their own group lookup to take additional references on an
>existing group pointer without having to also store device pointers or
>resort to elaborate trickery.
>
>Add an IOMMU-driver-specific function to fill the hole.
>
>Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>---
> drivers/iommu/iommu.c | 14 ++++++++++++++
> include/linux/iommu.h | 1 +
> 2 files changed, 15 insertions(+)
>
>diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>index 9a2f1960873b..b0b052bc6bb5 100644
>--- a/drivers/iommu/iommu.c
>+++ b/drivers/iommu/iommu.c
>@@ -552,6 +552,20 @@ struct iommu_group *iommu_group_get(struct device *dev)
> EXPORT_SYMBOL_GPL(iommu_group_get);
>
> /**
>+ * __iommu_group_get - Increment reference on a group
>+ * @group: the group to use, must not be NULL
>+ *
>+ * This function may be called by internal iommu driver group management
>+ * when the context of a struct device pointer is not available. It is
>+ * not for general use. Returns the given group for convenience.
>+ */
>+struct iommu_group *__iommu_group_get(struct iommu_group *group)
>+{
>+ kobject_get(group->devices_kobj);
>+ return group;
>+}
>+
>+/**
Acked-by: sricharan at codeaurora.org
Regards,
Sricharan
^ permalink raw reply
* [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP
From: ayaka @ 2016-11-09 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16dfbe16-eae7-8da9-4108-07e623210d35@rock-chips.com>
On 10/28/2016 05:29 PM, Randy Li wrote:
>
>
> On 10/28/2016 05:11 PM, Shawn Lin wrote:
>> On 2016/10/23 3:18, Randy Li wrote:
>>> I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
>>> RK3288, once trying to enable the pclk clock, the kernel would dead.
>>> This patch would try to enable them first. The eDP_AVDD_1V8 more
>>> likely to be applied to eDP phy, but I have no time to confirmed
>>> it yet.
>>
>> Comfirm it or at least someone should be able to answer your
>> question, Mark?
> I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a
short time.
>>
>> Have you considered to add some details about vcc-supply and vccio-
>> supply for your analogix_dp-rockchip.txt ?
>>
>> From your commit msg, these two properties are more likely to be
>> required but the code itself tell me them should be optional(from the
>> point of backward compatibility, it should also be optinoal).
> Yes, I keep it optional for the same reason. Most of boards won't turn
> off those power supply and may use some fixed regulators.
>>
>>>
>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>> ---
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
>>> +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index 8548e82..6bf0441 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -17,6 +17,7 @@
>>> #include <linux/of_device.h>
>>> #include <linux/of_graph.h>
>>> #include <linux/regmap.h>
>>> +#include <linux/regulator/consumer.h>
>>> #include <linux/reset.h>
>>> #include <linux/clk.h>
>>>
>>> @@ -70,6 +71,7 @@ struct rockchip_dp_device {
>>> struct clk *grfclk;
>>> struct regmap *grf;
>>> struct reset_control *rst;
>>> + struct regulator_bulk_data supplies[2];
>>>
>>> struct work_struct psr_work;
>>> spinlock_t psr_lock;
>>> @@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> cancel_work_sync(&dp->psr_work);
>>>
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret) {
>>> + dev_err(dp->dev, "failed to enable vdd supply %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>> @@ -168,6 +177,9 @@ static int rockchip_dp_powerdown(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> clk_disable_unprepare(dp->pclk);
>>>
>>> + regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
>>> rockchip_dp_device *dp)
>>> return PTR_ERR(dp->rst);
>>> }
>>>
>>> + dp->supplies[0].supply = "vcc";
>>> + dp->supplies[1].supply = "vccio";
>>> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to get regulators: %d\n", ret);
>>> + }
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable regulators: %d\n", ret);
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>>
>>
>>
>
^ permalink raw reply
* [PATCHv2] ARM: socfpga_defconfig: enable FS configs to support Angstrom filesystem
From: Dinh Nguyen @ 2016-11-09 14:15 UTC (permalink / raw)
To: linux-arm-kernel
systemd on the Angstrom root file system expects AUTOFS to be configured
as a module and NFSD to be statically linked into the kernel. This patch
adds the necessary configuration to get rid two "FAILED" error messages
during systemd startup.
Signed-off-by: Matthew Gerlach <mgerlach@opensource.altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
v2: provide a more descriptive changelog
---
arch/arm/configs/socfpga_defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
index 18d3ec1..2e1d254 100644
--- a/arch/arm/configs/socfpga_defconfig
+++ b/arch/arm/configs/socfpga_defconfig
@@ -116,13 +116,18 @@ CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT3_FS=y
+CONFIG_AUTOFS4_FS=y
CONFIG_VFAT_FS=y
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y
CONFIG_TMPFS=y
CONFIG_CONFIGFS_FS=y
CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
CONFIG_ROOT_NFS=y
+CONFIG_NFSD=y
+CONFIG_NFSD_V3_ACL=y
+CONFIG_NFSD_V4=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
--
2.8.3
^ permalink raw reply related
* [PATCH] pinctrl: single: check for any error when getting rows
From: Axel Haslam @ 2016-11-09 14:17 UTC (permalink / raw)
To: linux-arm-kernel
pinctrl_count_index_with_args returns -ENOENT not
-EINVAL. The return check would pass, and we would
try to kzalloc with a negative error size throwing
a warning.
Instead of checking for -EINVAL specifically, lets
check for any error and avoid negative size allocations.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
drivers/pinctrl/pinctrl-single.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 539f31c..56e22be 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1228,7 +1228,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
struct pcs_function *function;
rows = pinctrl_count_index_with_args(np, name);
- if (rows == -EINVAL)
+ if (rows < 0)
return rows;
npins_in_row = pcs->width / pcs->bits_per_pin;
--
2.10.1
^ permalink raw reply related
* [PATCH v7 00/16] ACPI IORT ARM SMMU support
From: Lorenzo Pieralisi @ 2016-11-09 14:19 UTC (permalink / raw)
To: linux-arm-kernel
This patch series is v7 of a previous posting:
https://lkml.org/lkml/2016/10/18/506
v6 -> v7
- Rebased against v4.9-rc4
- Fixed IORT probing on ACPI systems with missing IORT table
- Fixed SMMUv1/v2 global interrupt detection
- Updated iommu_ops firmware look-up
v5 -> v6
- Rebased against v4.9-rc1
- Changed FWNODE_IOMMU to FWNODE_ACPI_STATIC
- Moved platform devices creation into IORT code
- Updated fwnode handling
- Added default dma masks initialization
v4 -> v5
- Added SMMUv1/v2 support
- Rebased against v4.8-rc5 and dependencies series
- Consolidated IORT platform devices creation
v3 -> v4
- Added single mapping API (for IORT named components)
- Fixed arm_smmu_iort_xlate() return value
- Reworked fwnode registration and platform device creation
ordering to fix probe ordering dependencies
- Added code to keep device_node ref count with new iommu
fwspec API
- Added patch to make iommu_fwspec arch agnostic
- Dropped RFC status
- Rebased against v4.8-rc2
v2 -> v3
- Rebased on top of dependencies series [1][2][3](v4.7-rc3)
- Added back reliance on ACPI early probing infrastructure
- Patch[1-3] merged through other dependent series
- Added back IOMMU fwnode generalization
- Move SMMU v3 static functions configuration to IORT code
- Implemented generic IOMMU fwspec API
- Added code to implement fwnode platform device look-up
v1 -> v2:
- Rebased on top of dependencies series [1][2][3](v4.7-rc1)
- Removed IOMMU fwnode generalization
- Implemented ARM SMMU v3 ACPI probing instead of ARM SMMU v2
owing to patch series dependencies [1]
- Moved platform device creation logic to IORT code to
generalize its usage for ARM SMMU v1-v2-v3 components
- Removed reliance on ACPI early device probing
- Created IORT specific iommu_xlate() translation hook leaving
OF code unchanged according to v1 reviews
The ACPI IORT table provides information that allows instantiating
ARM SMMU devices and carrying out id mappings between components on
ARM based systems (devices, IOMMUs, interrupt controllers).
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
Building on basic IORT support, this patchset enables ARM SMMUs support
on ACPI systems.
Most of the code is aimed at building the required generic ACPI
infrastructure to create and enable IOMMU components and to bring
the IOMMU infrastructure for ACPI on par with DT, which is going to
make future ARM SMMU components easier to integrate.
PATCH (1) adds a FWNODE_ACPI_STATIC type to the struct fwnode_handle type.
It is required to attach a fwnode identifier to platform
devices allocated/detected through static ACPI table entries
(ie IORT tables entries).
IOMMU devices have to have an identifier to look them up
eg IOMMU core layer carrying out id translation. This can be
done through a fwnode_handle (ie IOMMU platform devices created
out of IORT tables are not ACPI devices hence they can't be
allocated as such, otherwise they would have a fwnode_handle of
type FWNODE_ACPI).
PATCH (2) makes use of the ACPI early probing API to add a linker script
section for probing devices via IORT ACPI kernel code.
PATCH (3) provides IORT support for registering IOMMU IORT node through
their fwnode handle.
PATCH (4) make of_iommu_{set/get}_ops() functions DT agnostic.
PATCH (5) convert ARM SMMU driver to use fwnode instead of of_node as
look-up and iommu_ops retrieval token.
PATCH (6) convert ARM SMMU v3 driver to use fwnode instead of of_node as
look-up and iommu_ops retrieval token.
PATCH (7) implements the of_dma_configure() API in ACPI world -
acpi_dma_configure() - and patches PCI and ACPI core code to
start making use of it.
PATCH (8) provides an IORT function to detect existence of specific type
of IORT components.
PATCH (9) creates the kernel infrastructure required to create ARM SMMU
platform devices for IORT nodes.
PATCH (10) refactors the ARM SMMU v3 driver so that the init functions are
split in a way that groups together code that probes through DT
and code that carries out HW registers FW agnostic probing, in
preparation for adding the ACPI probing path.
PATCH (11) adds ARM SMMU v3 IORT IOMMU operations to create and probe
ARM SMMU v3 components.
PATCH (12) refactors the ARM SMMU v1/v2 driver so that the init functions
are split in a way that groups together code that probes
through DT and code that carries out HW registers FW agnostic
probing, in preparation for adding the ACPI probing path.
PATCH (13) adds ARM SMMU v1/v2 IORT IOMMU operations to create and
probe ARM SMMU v1/v2 components.
PATCH (14) Extend the IORT iort_node_map_rid() to work on a type mask
instead of a single type so that the translation API can
be used on a range of components.
PATCH (15) Add IORT API to carry out id mappings for components that do
do not have an input identifier/RIDs (ie named components).
PATCH (16) provides IORT infrastructure to carry out IOMMU configuration
for devices and hook it up to the previously introduced ACPI
DMA configure API.
This patchset is provided for review/testing purposes here:
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/iort-smmu-v7
Tested on Juno and FVP models for ARM SMMU v1 and v3 probing path.
Lorenzo Pieralisi (16):
drivers: acpi: add FWNODE_ACPI_STATIC fwnode type
drivers: acpi: iort: introduce linker section for IORT entries probing
drivers: acpi: iort: add support for IOMMU fwnode registration
drivers: iommu: make of_iommu_set/get_ops() DT agnostic
drivers: iommu: arm-smmu: convert struct device of_node to fwnode
usage
drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode
usage
drivers: acpi: implement acpi_dma_configure
drivers: acpi: iort: add node match function
drivers: acpi: iort: add support for ARM SMMU platform devices
creation
drivers: iommu: arm-smmu-v3: split probe functions into DT/generic
portions
drivers: iommu: arm-smmu-v3: add IORT configuration
drivers: iommu: arm-smmu: split probe functions into DT/generic
portions
drivers: iommu: arm-smmu: add IORT configuration
drivers: acpi: iort: replace rid map type with type mask
drivers: acpi: iort: add single mapping function
drivers: acpi: iort: introduce iort_iommu_configure
drivers/acpi/arm64/iort.c | 596 +++++++++++++++++++++++++++++++++++++-
drivers/acpi/glue.c | 4 +-
drivers/acpi/scan.c | 45 +++
drivers/iommu/arm-smmu-v3.c | 105 +++++--
drivers/iommu/arm-smmu.c | 154 ++++++++--
drivers/iommu/iommu.c | 42 +++
drivers/iommu/of_iommu.c | 39 ---
drivers/pci/probe.c | 3 +-
include/acpi/acpi_bus.h | 2 +
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/acpi.h | 26 ++
include/linux/acpi_iort.h | 14 +
include/linux/fwnode.h | 3 +-
include/linux/iommu.h | 14 +
include/linux/of_iommu.h | 12 +-
15 files changed, 956 insertions(+), 104 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v7 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type
From: Lorenzo Pieralisi @ 2016-11-09 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-1-lorenzo.pieralisi@arm.com>
On systems booting with a device tree, every struct device is associated
with a struct device_node, that provides its DT firmware representation.
The device node can be used in generic kernel contexts (eg IRQ
translation, IOMMU streamid mapping), to retrieve the properties
associated with the device and carry out kernel operations accordingly.
Owing to the 1:1 relationship between the device and its device_node,
the device_node can also be used as a look-up token for the device (eg
looking up a device through its device_node), to retrieve the device in
kernel paths where the device_node is available.
On systems booting with ACPI, the same abstraction provided by
the device_node is required to provide look-up functionality.
The struct acpi_device, that represents firmware objects in the
ACPI namespace already includes a struct fwnode_handle of
type FWNODE_ACPI as their member; the same abstraction is missing
though for devices that are instantiated out of static ACPI tables
entries (eg ARM SMMU devices).
Add a new fwnode_handle type to associate devices created out
of static ACPI table entries to the respective firmware components
and create a simple ACPI core layer interface to dynamically allocate
and free the corresponding firmware nodes so that kernel subsystems
can use it to instantiate the nodes and associate them with the
respective devices.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
include/linux/acpi.h | 21 +++++++++++++++++++++
include/linux/fwnode.h | 3 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 689a8b9..6efb13c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -56,6 +56,27 @@ static inline acpi_handle acpi_device_handle(struct acpi_device *adev)
acpi_fwnode_handle(adev) : NULL)
#define ACPI_HANDLE(dev) acpi_device_handle(ACPI_COMPANION(dev))
+static inline struct fwnode_handle *acpi_alloc_fwnode_static(void)
+{
+ struct fwnode_handle *fwnode;
+
+ fwnode = kzalloc(sizeof(struct fwnode_handle), GFP_KERNEL);
+ if (!fwnode)
+ return NULL;
+
+ fwnode->type = FWNODE_ACPI_STATIC;
+
+ return fwnode;
+}
+
+static inline void acpi_free_fwnode_static(struct fwnode_handle *fwnode)
+{
+ if (WARN_ON(!fwnode || fwnode->type != FWNODE_ACPI_STATIC))
+ return;
+
+ kfree(fwnode);
+}
+
/**
* ACPI_DEVICE_CLASS - macro used to describe an ACPI device with
* the PCI-defined class-code information
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 8516717..8bd28ce 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -17,8 +17,9 @@ enum fwnode_type {
FWNODE_OF,
FWNODE_ACPI,
FWNODE_ACPI_DATA,
+ FWNODE_ACPI_STATIC,
FWNODE_PDATA,
- FWNODE_IRQCHIP,
+ FWNODE_IRQCHIP
};
struct fwnode_handle {
--
2.10.0
^ permalink raw reply related
* [PATCH v7 02/16] drivers: acpi: iort: introduce linker section for IORT entries probing
From: Lorenzo Pieralisi @ 2016-11-09 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-1-lorenzo.pieralisi@arm.com>
Since commit e647b532275b ("ACPI: Add early device probing
infrastructure") the kernel has gained the infrastructure that allows
adding linker script section entries to execute ACPI driver callbacks
(ie probe routines) for all subsystems that register a table entry
in the respective kernel section (eg clocksource, irqchip).
Since ARM IOMMU devices data is described through IORT tables when
booting with ACPI, the ARM IOMMU drivers must be made able to hook ACPI
callback routines that are called to probe IORT entries and initialize
the respective IOMMU devices.
To avoid adding driver specific hooks into IORT table initialization
code (breaking therefore code modularity - ie ACPI IORT code must be made
aware of ARM SMMU drivers ACPI init callbacks), this patch adds code
that allows ARM SMMU drivers to take advantage of the ACPI early probing
infrastructure, so that they can add linker script section entries
containing drivers callback to be executed on IORT tables detection.
Since IORT nodes are differentiated by a type, the callback routines
can easily parse the IORT table entries, check the IORT nodes and
carry out some actions whenever the IORT node type associated with
the driver specific callback is matched.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/acpi/arm64/iort.c | 13 ++++++++++---
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/acpi_iort.h | 3 +++
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 6b81746..2c46ebc 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -361,8 +361,15 @@ void __init acpi_iort_init(void)
acpi_status status;
status = acpi_get_table(ACPI_SIG_IORT, 0, &iort_table);
- if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
- const char *msg = acpi_format_exception(status);
- pr_err("Failed to get table, %s\n", msg);
+ if (ACPI_FAILURE(status)) {
+ if (status != AE_NOT_FOUND) {
+ const char *msg = acpi_format_exception(status);
+
+ pr_err("Failed to get table, %s\n", msg);
+ }
+
+ return;
}
+
+ acpi_probe_device_table(iort);
}
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 3074796..f9c9f3c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -563,6 +563,7 @@
IRQCHIP_OF_MATCH_TABLE() \
ACPI_PROBE_TABLE(irqchip) \
ACPI_PROBE_TABLE(clksrc) \
+ ACPI_PROBE_TABLE(iort) \
EARLYCON_TABLE()
#define INIT_TEXT \
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 0e32dac..d16fdda 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -39,4 +39,7 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev,
{ return NULL; }
#endif
+#define IORT_ACPI_DECLARE(name, table_id, fn) \
+ ACPI_DECLARE_PROBE_ENTRY(iort, name, table_id, 0, NULL, 0, fn)
+
#endif /* __ACPI_IORT_H__ */
--
2.10.0
^ permalink raw reply related
* [PATCH v7 03/16] drivers: acpi: iort: add support for IOMMU fwnode registration
From: Lorenzo Pieralisi @ 2016-11-09 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-1-lorenzo.pieralisi@arm.com>
The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world)
components that allow creating the kernel data structures required to
probe and initialize the IOMMU devices.
This patch provides support in the IORT kernel code to register IOMMU
components and their respective fwnode.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
drivers/acpi/arm64/iort.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 2c46ebc..1ac2720 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -20,7 +20,9 @@
#include <linux/acpi_iort.h>
#include <linux/kernel.h>
+#include <linux/list.h>
#include <linux/pci.h>
+#include <linux/slab.h>
struct iort_its_msi_chip {
struct list_head list;
@@ -28,6 +30,90 @@ struct iort_its_msi_chip {
u32 translation_id;
};
+struct iort_fwnode {
+ struct list_head list;
+ struct acpi_iort_node *iort_node;
+ struct fwnode_handle *fwnode;
+};
+static LIST_HEAD(iort_fwnode_list);
+static DEFINE_SPINLOCK(iort_fwnode_lock);
+
+/**
+ * iort_set_fwnode() - Create iort_fwnode and use it to register
+ * iommu data in the iort_fwnode_list
+ *
+ * @node: IORT table node associated with the IOMMU
+ * @fwnode: fwnode associated with the IORT node
+ *
+ * Returns: 0 on success
+ * <0 on failure
+ */
+static inline int iort_set_fwnode(struct acpi_iort_node *iort_node,
+ struct fwnode_handle *fwnode)
+{
+ struct iort_fwnode *np;
+
+ np = kzalloc(sizeof(struct iort_fwnode), GFP_ATOMIC);
+
+ if (WARN_ON(!np))
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&np->list);
+ np->iort_node = iort_node;
+ np->fwnode = fwnode;
+
+ spin_lock(&iort_fwnode_lock);
+ list_add_tail(&np->list, &iort_fwnode_list);
+ spin_unlock(&iort_fwnode_lock);
+
+ return 0;
+}
+
+/**
+ * iort_get_fwnode() - Retrieve fwnode associated with an IORT node
+ *
+ * @node: IORT table node to be looked-up
+ *
+ * Returns: fwnode_handle pointer on success, NULL on failure
+ */
+static inline
+struct fwnode_handle *iort_get_fwnode(struct acpi_iort_node *node)
+{
+ struct iort_fwnode *curr;
+ struct fwnode_handle *fwnode = NULL;
+
+ spin_lock(&iort_fwnode_lock);
+ list_for_each_entry(curr, &iort_fwnode_list, list) {
+ if (curr->iort_node == node) {
+ fwnode = curr->fwnode;
+ break;
+ }
+ }
+ spin_unlock(&iort_fwnode_lock);
+
+ return fwnode;
+}
+
+/**
+ * iort_delete_fwnode() - Delete fwnode associated with an IORT node
+ *
+ * @node: IORT table node associated with fwnode to delete
+ */
+static inline void iort_delete_fwnode(struct acpi_iort_node *node)
+{
+ struct iort_fwnode *curr, *tmp;
+
+ spin_lock(&iort_fwnode_lock);
+ list_for_each_entry_safe(curr, tmp, &iort_fwnode_list, list) {
+ if (curr->iort_node == node) {
+ list_del(&curr->list);
+ kfree(curr);
+ break;
+ }
+ }
+ spin_unlock(&iort_fwnode_lock);
+}
+
typedef acpi_status (*iort_find_node_callback)
(struct acpi_iort_node *node, void *context);
--
2.10.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox