* [PATCH v2 4/4] arm64: defconfig: enable Rockchip Innosilicon hdmiphy
From: Heiko Stuebner @ 2018-05-15 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515135457.6252-1-heiko@sntech.de>
The rk3228 and rk3328 socs use an MMIO-connected hdmi-phy from Innosilicon.
So enable the necessary driver as module.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 74abf140e332..dff3de45cc04 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -604,6 +604,7 @@ CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_MVEBU_CP110_COMPHY=y
CONFIG_PHY_ROCKCHIP_INNO_USB2=y
CONFIG_PHY_ROCKCHIP_EMMC=y
+CONFIG_PHY_ROCKCHIP_INNO_HDMI=m
CONFIG_PHY_ROCKCHIP_PCIE=m
CONFIG_PHY_ROCKCHIP_TYPEC=y
CONFIG_PHY_XGENE=y
--
2.17.0
^ permalink raw reply related
* [PATCH v2 3/4] arm64: dts: rockchip: enable display nodes on rk3328-rock64
From: Heiko Stuebner @ 2018-05-15 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515135457.6252-1-heiko@sntech.de>
Enable necessary nodes to get output on the hdmi port of the board.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 5c43a61d3178..ca48be13dee7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -145,6 +145,14 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmiphy {
+ status = "okay";
+};
+
&i2c1 {
status = "okay";
@@ -341,3 +349,11 @@
dr_mode = "host";
status = "okay";
};
+
+&vop {
+ status = "okay";
+};
+
+&vop_mmu {
+ status = "okay";
+};
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/4] arm64: dts: rockchip: add rk3328 display nodes
From: Heiko Stuebner @ 2018-05-15 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515135457.6252-1-heiko@sntech.de>
Add the chain of display nodes from the core display-subsystem
through the one vop to the dw-hdmi output.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Robin Murphy <robin.murphy@arm.com>
---
changes in v2:
- remove trailing 0 from vop irq
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 56 ++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 04d81ea0924e..16e7cf210875 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -185,6 +185,11 @@
interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
};
+ display_subsystem: display-subsystem {
+ compatible = "rockchip,display-subsystem";
+ ports = <&vop_out>;
+ };
+
psci {
compatible = "arm,psci-1.0", "arm,psci-0.2";
method = "smc";
@@ -634,6 +639,28 @@
status = "disabled";
};
+ vop: vop at ff370000 {
+ compatible = "rockchip,rk3328-vop";
+ reg = <0x0 0xff370000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP>, <&cru DCLK_LCDC>, <&cru HCLK_VOP>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_VOP_A>, <&cru SRST_VOP_H>, <&cru SRST_VOP_D>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vop_mmu>;
+ status = "disabled";
+
+ vop_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vop_out_hdmi: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&hdmi_in_vop>;
+ };
+ };
+ };
+
vop_mmu: iommu at ff373f00 {
compatible = "rockchip,iommu";
reg = <0x0 0xff373f00 0x0 0x100>;
@@ -645,6 +672,35 @@
status = "disabled";
};
+ hdmi: hdmi at ff3c0000 {
+ compatible = "rockchip,rk3328-dw-hdmi";
+ reg = <0x0 0xff3c0000 0x0 0x20000>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_HDMI>,
+ <&cru SCLK_HDMI_SFC>;
+ clock-names = "iahb",
+ "isfr";
+ phys = <&hdmiphy>;
+ phy-names = "hdmi";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec &hdmii2c_xfer &hdmi_hpd>;
+ rockchip,grf = <&grf>;
+ status = "disabled";
+
+ ports {
+ hdmi_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_vop: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vop_out_hdmi>;
+ };
+ };
+ };
+ };
+
hdmiphy: phy at ff430000 {
compatible = "rockchip,rk3328-hdmi-phy";
reg = <0x0 0xff430000 0x0 0x10000>;
--
2.17.0
^ permalink raw reply related
* [PATCH v2 1/4] arm64: dts: rockchip: add Innosilicon hdmi phy node to rk3328
From: Heiko Stuebner @ 2018-05-15 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515135457.6252-1-heiko@sntech.de>
The rk3328 uses a hdmiphy from Innosilicon, so add the necessary node
to the rk3328 soc devicetree.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Robin Murphy <robin.murphy@arm.com>
---
changes in v2:
- adapt to changed clock names
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 60b3ed5918e7..04d81ea0924e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -645,6 +645,20 @@
status = "disabled";
};
+ hdmiphy: phy at ff430000 {
+ compatible = "rockchip,rk3328-hdmi-phy";
+ reg = <0x0 0xff430000 0x0 0x10000>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_HDMIPHY>, <&xin24m>, <&cru DCLK_HDMIPHY>;
+ clock-names = "sysclk", "refoclk", "refpclk";
+ clock-output-names = "hdmi_phy";
+ #clock-cells = <0>;
+ nvmem-cells = <&efuse_cpu_version>;
+ nvmem-cell-names = "cpu-version";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
cru: clock-controller at ff440000 {
compatible = "rockchip,rk3328-cru", "rockchip,cru", "syscon";
reg = <0x0 0xff440000 0x0 0x1000>;
--
2.17.0
^ permalink raw reply related
* [PATCH v2 0/4] rk3328 and rock64 display support
From: Heiko Stuebner @ 2018-05-15 13:54 UTC (permalink / raw)
To: linux-arm-kernel
Companion series for the display modifications adding the necessary
devicetree stuff for display support on the rk3328-rock64.
changes in v2:
- add defconfig addition for the phy driver
- adapt to changed reference clock names
- remove trailing 0 from vop irq
Heiko Stuebner (4):
arm64: dts: rockchip: add Innosilicon hdmi phy node to rk3328
arm64: dts: rockchip: add rk3328 display nodes
arm64: dts: rockchip: enable display nodes on rk3328-rock64
arm64: defconfig: enable Rockchip Innosilicon hdmiphy
.../arm64/boot/dts/rockchip/rk3328-rock64.dts | 16 +++++
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 70 +++++++++++++++++++
arch/arm64/configs/defconfig | 1 +
3 files changed, 87 insertions(+)
--
2.17.0
^ permalink raw reply
* [PATCH 1/4] amba: Export amba_bustype
From: Russell King - ARM Linux @ 2018-05-15 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515081519.22751a39c49e63224da3acac@arm.com>
On Tue, May 15, 2018 at 08:15:19AM -0500, Kim Phillips wrote:
> On Tue, 15 May 2018 08:59:02 +0200
> Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> > On 8 May 2018 at 21:06, Kim Phillips <kim.phillips@arm.com> wrote:
> > > This patch is provided in the context of allowing the Coresight driver
> > > subsystem to be loaded as modules. Coresight uses amba_bus in its call
> > > to bus_find_device() in of_coresight_get_endpoint_device() when
> > > searching for a configurable endpoint device. This patch allows
> > > Coresight to reference amba_bustype when built as a module.
> >
> > Sounds like you are fixing a bug, don't your want this to go for
> > stable and then also add a fixes tag?
>
> How do you consider this a bug fix? What commit would the fixes tag
> reference? The introduction of the amba bus? Not only aren't busses
> required to export their bus_type, but that commit predates git.
I do not consider it a bug fix (see my reply to Ulf) and I certainly
do not think it should qualify for backporting to *stable* kernels.
While the impact on stable kernels of just this patch should be low,
that's not really the point: one of the requirements for stable kernels
is that patches should be _real_ bug fixes - stuff that affects people
using the kernel.
That is not the case in this instance - there is no problem with any
of the existing kernels with not having this symbol exported.
The only problem which we're aware of is with Coresight, and only then
when your patches to allow Coresight to be modular are merged. That's
a new feature, and this new feature now requires a symbol that was not
previously required to be exported to now be exported.
So, the need for this export comes from your new feature, not from a
bug report that is affecting people. As long as your new feature is
not backported (does it even qualify for backporting to stable kernels?)
then there is no problem with any existing stable kernel, and so there
is no requirement for it to be backported.
Hence, there's no need to Cc stable, and no need for a fixes tag. It's
not a fix, it's a feature enhancement to permit modular code to use
bus_find_device() with this bus type which wasn't previously required.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v3 6/6] drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328
From: Heiko Stuebner @ 2018-05-15 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515134736.5824-1-heiko@sntech.de>
The rk3328 uses a dw-hdmi controller with an external hdmi phy from
Innosilicon which uses the generic phy framework for access.
Add the necessary data and the compatible for the rk3328 to the
rockchip dw-hdmi driver.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Robin Murphy <robin.murphy@arm.com>
---
changes in v3:
- reword as suggested by Rob to show that it's a dw-hdmi + Inno phy
.../display/rockchip/dw_hdmi-rockchip.txt | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 106 ++++++++++++++++++
2 files changed, 107 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 937bfb472e1d..39143424a474 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -13,6 +13,7 @@ Required properties:
- compatible: should be one of the following:
"rockchip,rk3288-dw-hdmi"
+ "rockchip,rk3328-dw-hdmi"
"rockchip,rk3399-dw-hdmi"
- reg: See dw_hdmi.txt.
- reg-io-width: See dw_hdmi.txt. Shall be 4.
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 19f002fa0a09..237f31fd8403 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -25,6 +25,24 @@
#define RK3288_GRF_SOC_CON6 0x025C
#define RK3288_HDMI_LCDC_SEL BIT(4)
+#define RK3328_GRF_SOC_CON2 0x0408
+
+#define RK3328_HDMI_SDAIN_MSK BIT(11)
+#define RK3328_HDMI_SCLIN_MSK BIT(10)
+#define RK3328_HDMI_HPD_IOE BIT(2)
+#define RK3328_GRF_SOC_CON3 0x040c
+/* need to be unset if hdmi or i2c should control voltage */
+#define RK3328_HDMI_SDA5V_GRF BIT(15)
+#define RK3328_HDMI_SCL5V_GRF BIT(14)
+#define RK3328_HDMI_HPD5V_GRF BIT(13)
+#define RK3328_HDMI_CEC5V_GRF BIT(12)
+#define RK3328_GRF_SOC_CON4 0x0410
+#define RK3328_HDMI_HPD_SARADC BIT(13)
+#define RK3328_HDMI_CEC_5V BIT(11)
+#define RK3328_HDMI_SDA_5V BIT(10)
+#define RK3328_HDMI_SCL_5V BIT(9)
+#define RK3328_HDMI_HPD_5V BIT(8)
+
#define RK3399_GRF_SOC_CON20 0x6250
#define RK3399_HDMI_LCDC_SEL BIT(6)
@@ -292,6 +310,68 @@ static const struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_fun
.atomic_check = dw_hdmi_rockchip_encoder_atomic_check,
};
+static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi *dw_hdmi, void *data,
+ struct drm_display_mode *mode)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ return phy_power_on(hdmi->phy);
+}
+
+static void dw_hdmi_rockchip_genphy_disable(struct dw_hdmi *dw_hdmi, void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ phy_power_off(hdmi->phy);
+}
+
+static enum drm_connector_status
+dw_hdmi_rk3328_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+ enum drm_connector_status status;
+
+ status = dw_hdmi_phy_read_hpd(dw_hdmi, data);
+
+ if (status == connector_status_connected)
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V,
+ RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V));
+ else
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(0,
+ RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V));
+ return status;
+}
+
+static void dw_hdmi_rk3328_setup_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ dw_hdmi_phy_setup_hpd(dw_hdmi, data);
+
+ /* Enable and map pins to 3V grf-controlled io-voltage */
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(0, RK3328_HDMI_HPD_SARADC | RK3328_HDMI_CEC_5V |
+ RK3328_HDMI_SDA_5V | RK3328_HDMI_SCL_5V |
+ RK3328_HDMI_HPD_5V));
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON3,
+ HIWORD_UPDATE(0, RK3328_HDMI_SDA5V_GRF | RK3328_HDMI_SCL5V_GRF |
+ RK3328_HDMI_HPD5V_GRF | RK3328_HDMI_CEC5V_GRF));
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON2,
+ HIWORD_UPDATE(RK3328_HDMI_SDAIN_MSK | RK3328_HDMI_SCLIN_MSK,
+ RK3328_HDMI_SDAIN_MSK | RK3328_HDMI_SCLIN_MSK |
+ RK3328_HDMI_HPD_IOE));
+}
+
static struct rockchip_hdmi_chip_data rk3288_chip_data = {
.lcdsel_grf_reg = RK3288_GRF_SOC_CON6,
.lcdsel_big = HIWORD_UPDATE(0, RK3288_HDMI_LCDC_SEL),
@@ -306,6 +386,29 @@ static const struct dw_hdmi_plat_data rk3288_hdmi_drv_data = {
.phy_data = &rk3288_chip_data,
};
+static const struct dw_hdmi_phy_ops rk3328_hdmi_phy_ops = {
+ .init = dw_hdmi_rockchip_genphy_init,
+ .disable = dw_hdmi_rockchip_genphy_disable,
+ .read_hpd = dw_hdmi_rk3328_read_hpd,
+ .update_hpd = dw_hdmi_phy_update_hpd,
+ .setup_hpd = dw_hdmi_rk3328_setup_hpd,
+};
+
+static struct rockchip_hdmi_chip_data rk3328_chip_data = {
+ .lcdsel_grf_reg = -1,
+};
+
+static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
+ .mode_valid = dw_hdmi_rockchip_mode_valid,
+ .mpll_cfg = rockchip_mpll_cfg,
+ .cur_ctr = rockchip_cur_ctr,
+ .phy_config = rockchip_phy_config,
+ .phy_data = &rk3328_chip_data,
+ .phy_ops = &rk3328_hdmi_phy_ops,
+ .phy_name = "inno_dw_hdmi_phy2",
+ .phy_force_vendor = true,
+};
+
static struct rockchip_hdmi_chip_data rk3399_chip_data = {
.lcdsel_grf_reg = RK3399_GRF_SOC_CON20,
.lcdsel_big = HIWORD_UPDATE(0, RK3399_HDMI_LCDC_SEL),
@@ -324,6 +427,9 @@ static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
{ .compatible = "rockchip,rk3288-dw-hdmi",
.data = &rk3288_hdmi_drv_data
},
+ { .compatible = "rockchip,rk3328-dw-hdmi",
+ .data = &rk3328_hdmi_drv_data
+ },
{ .compatible = "rockchip,rk3399-dw-hdmi",
.data = &rk3399_hdmi_drv_data
},
--
2.17.0
^ permalink raw reply related
* [PATCH v3 5/6] drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object
From: Heiko Stuebner @ 2018-05-15 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515134736.5824-1-heiko@sntech.de>
When using special phy handling operations we'll often need access to
the rockchip_hdmi struct.
As the chip-data that occupies the phy_data pointer initially gets
assigned to the rockchip_hdmi struct, we can now re-use this phy_data
pointer to hold the reference to the rockchip_hdmi struct and use this
reference later on.
Inspiration for this comes from meson and sunxi dw-hdmi, which are using
the same method.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Robin Murphy <robin.murphy@arm.com>
---
changes in v3:
- reword commit message
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 57e76dfd5f6d..19f002fa0a09 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -335,7 +335,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
void *data)
{
struct platform_device *pdev = to_platform_device(dev);
- const struct dw_hdmi_plat_data *plat_data;
+ struct dw_hdmi_plat_data *plat_data;
const struct of_device_id *match;
struct drm_device *drm = data;
struct drm_encoder *encoder;
@@ -350,9 +350,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
return -ENOMEM;
match = of_match_node(dw_hdmi_rockchip_dt_ids, pdev->dev.of_node);
- plat_data = match->data;
+ plat_data = devm_kmemdup(&pdev->dev, match->data,
+ sizeof(*plat_data), GFP_KERNEL);
+ if (!plat_data)
+ return -ENOMEM;
+
hdmi->dev = &pdev->dev;
hdmi->chip_data = plat_data->phy_data;
+ plat_data->phy_data = hdmi;
encoder = &hdmi->encoder;
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
--
2.17.0
^ permalink raw reply related
* [PATCH v3 4/6] drm/rockchip: dw_hdmi: allow including external phys
From: Heiko Stuebner @ 2018-05-15 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515134736.5824-1-heiko@sntech.de>
Some variants of the dw-hdmi on Rockchip socs use a separate phy block
accessed via the generic phy framework, so allow them to be included
if such a phy reference is found.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index b09c3531305b..57e76dfd5f6d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -11,6 +11,7 @@
#include <linux/mfd/syscon.h>
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/phy/phy.h>
#include <linux/regmap.h>
#include <drm/drm_of.h>
@@ -49,6 +50,7 @@ struct rockchip_hdmi {
struct clk *vpll_clk;
struct clk *grf_clk;
struct dw_hdmi *hdmi;
+ struct phy *phy;
};
#define to_rockchip_hdmi(x) container_of(x, struct rockchip_hdmi, x)
@@ -376,6 +378,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
return ret;
}
+ hdmi->phy = devm_phy_optional_get(dev, "hdmi");
+ if (IS_ERR(hdmi->phy)) {
+ ret = PTR_ERR(hdmi->phy);
+ if (ret != -EPROBE_DEFER)
+ DRM_DEV_ERROR(hdmi->dev, "failed to get phy\n");
+ return ret;
+ }
+
drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
drm_encoder_init(drm, encoder, &dw_hdmi_rockchip_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
--
2.17.0
^ permalink raw reply related
* [PATCH v3 3/6] dt-bindings: allow optional phys in Rockchip dw_hdmi binding
From: Heiko Stuebner @ 2018-05-15 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515134736.5824-1-heiko@sntech.de>
Some newer Rockchip SoCs use an Innosilicon hdmiphy accessed via general
mmio, so allow these to be referenced via the regular phy interfaces
and therefore add optional phy-related properties to the binding.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index adc94fc3c9f8..937bfb472e1d 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -34,6 +34,8 @@ Optional properties
- clock-names: May contain "cec" as defined in dw_hdmi.txt.
- clock-names: May contain "grf", power for grf io.
- clock-names: May contain "vpll", external clock for some hdmi phy.
+- phys: from general PHY binding: the phandle for the PHY device.
+- phy-names: Should be "hdmi" if phys references an external phy.
Example:
--
2.17.0
^ permalink raw reply related
* [PATCH v3 2/6] drm/rockchip: dw_hdmi: Allow outputs that don't need output switching
From: Heiko Stuebner @ 2018-05-15 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515134736.5824-1-heiko@sntech.de>
So far we always encountered socs with 2 output crtcs needing the driver
to tell the hdmi block which output to connect to. But there also exist
socs with only one crtc like the rk3228, rk3328 and rk3368.
So adapt the register field to simply carry a negative value to signal
that no output-switching is necessary.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Robin Murphy <robin.murphy@arm.com>
---
changes in v3:
- fixed wording issue found by Robin Murphy
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 11309a2a4e43..b09c3531305b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -36,7 +36,7 @@
* @lcdsel_lit: reg value of selecting vop little for HDMI
*/
struct rockchip_hdmi_chip_data {
- u32 lcdsel_grf_reg;
+ int lcdsel_grf_reg;
u32 lcdsel_big;
u32 lcdsel_lit;
};
@@ -245,6 +245,9 @@ static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
u32 val;
int ret;
+ if (hdmi->chip_data->lcdsel_grf_reg < 0)
+ return;
+
ret = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
if (ret)
val = hdmi->chip_data->lcdsel_lit;
--
2.17.0
^ permalink raw reply related
* [PATCH v3 1/6] drm/bridge: dw-hdmi: allow forcing vendor phy-type
From: Heiko Stuebner @ 2018-05-15 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515134736.5824-1-heiko@sntech.de>
In some IP implementations the reading of the phy-type may be broken.
One example are the Rockchip rk3228 and rk3328 socs that use a separate
vendor-type phy from Innosilicon but still report the HDMI20_TX type.
So allow the glue driver to force the vendor-phy for these cases.
In the future it may be necessary to allow forcing other types, but
for now we'll keep it simply to the case actually seen in the wild.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Robin Murphy <robin.murphy@arm.com>
---
changes in v3:
- only allow forcing vendor type, as suggested by Laurent
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +++-
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ec8d0006ef7c..4de82ced9370 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2212,7 +2212,9 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
unsigned int i;
u8 phy_type;
- phy_type = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
+ phy_type = hdmi->plat_data->phy_force_vendor ?
+ DW_HDMI_PHY_VENDOR_PHY :
+ hdmi_readb(hdmi, HDMI_CONFIG2_ID);
if (phy_type == DW_HDMI_PHY_VENDOR_PHY) {
/* Vendor PHYs require support from the glue layer. */
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index dd2a8cf7d20b..53f0ce9aeb4a 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -133,6 +133,7 @@ struct dw_hdmi_plat_data {
const struct dw_hdmi_phy_ops *phy_ops;
const char *phy_name;
void *phy_data;
+ bool phy_force_vendor;
/* Synopsys PHY support */
const struct dw_hdmi_mpll_config *mpll_cfg;
--
2.17.0
^ permalink raw reply related
* [PATCH v3 0/6] drm/rockchip: hdmi support for rk3328
From: Heiko Stuebner @ 2018-05-15 13:47 UTC (permalink / raw)
To: linux-arm-kernel
The rk3228/rk3229 and rk3328 socs started using a new type of hdmi-phy
from Innosilicon that resides completely separate from the dw-hdmi block
and gets accessed via mmio.
Additionally the rk3328 dw-hdmi does not report the vendor-phy type
but a different one instead, so add the possibility to override the
phy type when the glue driver knows better than the ip block itself.
changes in v3:
- split off phy driver into a separate series
- only allow forcing vendor phy type
- wording fixes and other nits
changes in v2:
- phy: prevent overflow in tmdsclk calculation
as reported by Martin Cerveny
- phy: use unsigned long for all tmdsclk rate uses
- phy: simplify tmds rate calculation
- dropped patch exporting some dw-hdmi phy functions
as a similar patch entered drm-misc already
Heiko Stuebner (6):
drm/bridge: dw-hdmi: allow forcing vendor phy-type
drm/rockchip: dw_hdmi: Allow outputs that don't need output switching
dt-bindings: allow optional phys in Rockchip dw_hdmi binding
drm/rockchip: dw_hdmi: allow including external phys
drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data
object
drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328
.../display/rockchip/dw_hdmi-rockchip.txt | 3 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +-
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 130 +++++++++++++++++-
include/drm/bridge/dw_hdmi.h | 1 +
4 files changed, 134 insertions(+), 4 deletions(-)
--
2.17.0
^ permalink raw reply
* [GIT PULL] ARM: dts: socfpga: NAND fixes for v4.17
From: Dinh Nguyen @ 2018-05-15 13:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, and Olof:
Please pull in these NAND fixes for v4.17.
Thanks,
Dinh
The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:
Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_nand_fix_v4.17
for you to fetch changes up to 3877ef7a1ccecaae378c497e1dcddbc2dccb664c:
ARM: dts: socfpga: Fix NAND controller node compatible for Arria10 (2018-05-14 10:16:56 -0500)
----------------------------------------------------------------
ARM: dts: socfpga: fix NAND support
- NAND should be using nand_x_clk, not nand_clk
- fix NAND node compatible for Cyclone5 and Arria10
----------------------------------------------------------------
Dinh Nguyen (1):
ARM: dts: socfpga: Fix NAND controller node compatible for Arria10
Marek Vasut (2):
ARM: dts: socfpga: Fix NAND controller clock supply
ARM: dts: socfpga: Fix NAND controller node compatible
arch/arm/boot/dts/socfpga.dtsi | 4 ++--
arch/arm/boot/dts/socfpga_arria10.dtsi | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH v10 03/27] clk: davinci: psc: allow for dev == NULL
From: Sekhar Nori @ 2018-05-15 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509172606.29387-4-david@lechnology.com>
On Wednesday 09 May 2018 10:55 PM, David Lechner wrote:
> @@ -261,10 +263,14 @@ davinci_lpsc_clk_register(struct device *dev, const char *name,
> lpsc->pd = pd;
> lpsc->flags = flags;
>
> - ret = devm_clk_hw_register(dev, &lpsc->hw);
> + ret = clk_hw_register(dev, &lpsc->hw);
> if (ret < 0)
> return ERR_PTR(ret);
>
> + /* for now, genpd is only registered when using device-tree */
> + if (!dev || !dev->of_node)
> + return lpsc;
> +
> /* genpd attach needs a way to look up this clock */
> ret = clk_hw_register_clkdev(&lpsc->hw, name, best_dev_name(dev));
>
> @@ -378,11 +384,11 @@ __davinci_psc_register_clocks(struct device *dev,
> struct regmap *regmap;
> int i, ret;
>
> - psc = devm_kzalloc(dev, sizeof(*psc), GFP_KERNEL);
> + psc = kzalloc(sizeof(*psc), GFP_KERNEL);
> if (!psc)
> return ERR_PTR(-ENOMEM);
>
> - clks = devm_kmalloc_array(dev, num_clks, sizeof(*clks), GFP_KERNEL);
> + clks = kmalloc_array(num_clks, sizeof(*clks), GFP_KERNEL);
> if (!clks)
> return ERR_PTR(-ENOMEM);
>
> @@ -396,14 +402,14 @@ __davinci_psc_register_clocks(struct device *dev,
> for (i = 0; i < num_clks; i++)
> clks[i] = ERR_PTR(-ENOENT);
>
> - pm_domains = devm_kcalloc(dev, num_clks, sizeof(*pm_domains), GFP_KERNEL);
> + pm_domains = kcalloc(num_clks, sizeof(*pm_domains), GFP_KERNEL);
> if (!pm_domains)
> return ERR_PTR(-ENOMEM);
>
> psc->pm_data.domains = pm_domains;
> psc->pm_data.num_domains = num_clks;
>
> - regmap = devm_regmap_init_mmio(dev, base, &davinci_psc_regmap_config);
> + regmap = regmap_init_mmio(dev, base, &davinci_psc_regmap_config);
> if (IS_ERR(regmap))
> return ERR_CAST(regmap);
Here and in the PLL driver, you have dropped the devm_* variants (like
agreed upon), but not added any error path handling. For the clocks
needed for boot, its probably fine, but the same code path is used for
non-essential clocks too. Just from a code completeness perspective, it
will be nice to see the error path correctly handled.
Apart from that both 1/27 and 3/27 look good to me.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/4] amba: Export amba_bustype
From: Russell King - ARM Linux @ 2018-05-15 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFqagt5zhz-8hLSXOqofv-nBqg4i-EVjA=UV3Jfi4zktKg@mail.gmail.com>
On Tue, May 15, 2018 at 08:59:02AM +0200, Ulf Hansson wrote:
> On 8 May 2018 at 21:06, Kim Phillips <kim.phillips@arm.com> wrote:
> > This patch is provided in the context of allowing the Coresight driver
> > subsystem to be loaded as modules. Coresight uses amba_bus in its call
> > to bus_find_device() in of_coresight_get_endpoint_device() when
> > searching for a configurable endpoint device. This patch allows
> > Coresight to reference amba_bustype when built as a module.
>
> Sounds like you are fixing a bug, don't your want this to go for
> stable and then also add a fixes tag?
What bug is this fixing exactly that would qualify it for stable
backporting?
The lack of an export is never a bug unless there is some existing
user which requires it. This is not the case here.
What Kim is doing in his new patch series is making Coresight - which
is currently only available as either disabled or built-in - possible
to be loaded as a module. This is a new feature, and in the process
of creating this new feature, Kim needs a symbol that wasn't previously
needed to be exported.
I think it would be hard to argue that Coresight not being available
as a module is a bug worthy of backporting to older kernels.
Therefore, it is not a bug, and it certainly does not qualify for
backporting to stable trees:
- It must be obviously correct and tested.
Probably.
- It cannot be bigger than 100 lines, with context.
Is.
- It must fix only one thing.
Does.
- It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing).
Nope.
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, something
critical.
Nope, not in any stable tree.
- Serious issues as reported by a user of a distribution kernel may also
be considered if they fix a notable performance or interactivity issue.
As these fixes are not as obvious and have a higher risk of a subtle
regression they should only be submitted by a distribution kernel
maintainer and include an addendum linking to a bugzilla entry if it
exists and additional information on the user-visible impact.
Hasn't been.
- New device IDs and quirks are also accepted.
Is not that.
- No "theoretical race condition" issues, unless an explanation of how the
race can be exploited is also provided.
Is not that.
- It cannot contain any "trivial" fixes in it (spelling changes,
whitespace cleanups, etc).
Doesn't (so okay.)
- It must follow the
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
rules.
Does.
- It or an equivalent fix must already exist in Linus' tree (upstream).
Eventually.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90
From: Maxime Ripard @ 2018-05-15 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <abeac1ee792b8f063001c4c280ca7f0167ac59be.camel@paulk.fr>
On Mon, May 14, 2018 at 10:40:15PM +0200, Paul Kocialkowski wrote:
> Le vendredi 11 mai 2018 ? 10:59 +0200, Maxime Ripard a ?crit :
> > On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> > > On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > > > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
> > > > > as found on the Ainol AW1 tablet.
> > > > >
> > > > > The panel also supports RGB888 output. When RGB666 mode is used instead,
> > > > > the two extra lanes per component are grounded.
> > > > >
> > > > > In the future, it might become necessary to introduce a dedicated
> > > > > device-tree property to specify the bus format to use instead of the
> > > > > default one for the panel. This will allow supporting different bus
> > > > > formats for the same panel modes.
> > > > >
> > > > > Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> > > > > ---
> > > > > drivers/gpu/drm/panel/panel-simple.c | 26 ++++++++++++++++++++++++++
> > > > > 1 file changed, 26 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > > > > index cbf1ab404ee7..32e30d5a8f08 100644
> > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > @@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at043tn24 = {
> > > > > .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
> > > > > };
> > > > >
> > > > > +static const struct drm_display_mode innolux_at070tn90_mode = {
> > > > > + .clock = 40000,
> > > > > + .hdisplay = 800,
> > > > > + .hsync_start = 800 + 112,
> > > > > + .hsync_end = 800 + 112 + 1,
> > > > > + .htotal = 800 + 112 + 1 + 87,
> > > > > + .vdisplay = 480,
> > > > > + .vsync_start = 480 + 141,
> > > > > + .vsync_end = 480 + 141 + 1,
> > > > > + .vtotal = 480 + 141 + 1 + 38,
> > > > > + .vrefresh = 60,
> > > > > +};
> > > > > +
> > > > > +static const struct panel_desc innolux_at070tn90 = {
> > > > > + .modes = &innolux_at070tn90_mode,
> > > > > + .num_modes = 1,
> > > > > + .size = {
> > > > > + .width = 154,
> > > > > + .height = 86,
> > > > > + },
> > > > > + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > > > > +};
> > > > > +
> > > >
> > > > I'm not really convinced this is the right approach. You said it
> > > > yourself, the panel is using a 24-bits interface, and you just happen
> > > > to have a tablet that routed it using a 18-bits interface instead.
> > > >
> > > > That doesn't belong in the driver, especially associated to the
> > > > compatible, but where the routing is described: in the device
> > > > tree. And given that the panel interface is a 24 bits panel, if we
> > > > were to have a default, we should have this one, and not the one
> > > > fitting your use case.
> > >
> > > I fully agree, this is why I suggested introducing a dedicated dt
> > > property for selecting the bus format (in the commit message). I still
> > > proposed this patch as a temporary solution, but I'm definitely willing
> > > to craft a proper solution as well.
> > >
> > > Here is an initial proposition:
> > > 1. Making bus_format an array in struct panel_desc and listing all the
> > > relevant bus formats that the panel can support there;
> >
> > I'm not sure this is needed, the input format is always the same in
> > your case, the panel will always take a 24 bits RGB value. What you
> > want to change is the encoder output format (and I guess you want that
> > to be meaningful to enable or not the dithering).
>
> Isn't the panel format supposed to match what the encoder's output
> should be aiming for? In my case, that would be RGB666, so the idea
> would be specifying both MEDIA_BUS_FMT_RGB666_1X18 and
> MEDIA_BUS_FMT_RGB888_1X24 in a list of supported bus formats for the
> panel.
The width your panel has in input is in 24 bits. The width the encoder
outputs in is 16 bits. This is the panel driver, you should expose the
panel capabilities.
> This way, both my setup and RGB888 setups can be supported.
I don't see what prevents you to do that with my suggestion either.
> > > 2. Introducing an optional "bus-format" dt property that indicates which
> > > bus format to use, and using the first index of the bus formats array if
> > > the property is not present;
> >
> > I guess the width would be enough, and that way we can take the
> > bus-width format that is already defined (but used in the v4l2
> > framework, not in DRM yet).
>
> Well, we already have bus-format defines on the DRM side and it feels
> like mapping these directly in device-tree would be more useful as a
> description of the hardware than just having the bus width.
Having the format in the DT doesn't make much sense. A given panel can
support multiple formats, just like a given encoder can.
If you're in that situation, the DT would describe a policy over what
happens in the OS, which isn't what should be stored in the DT. The
bus width, on the other end, is a property of the hardware.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180515/4d8de971/attachment.sig>
^ permalink raw reply
* [PATCH v10 02/27] clk: davinci: da850-pll: change PLL0 to CLK_OF_DECLARE
From: Sekhar Nori @ 2018-05-15 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509172606.29387-3-david@lechnology.com>
On Wednesday 09 May 2018 10:55 PM, David Lechner wrote:
> +void of_da850_pll0_init(struct device_node *node)
> {
> - return of_davinci_pll_init(dev, dev->of_node, &da850_pll0_info,
> - &da850_pll0_obsclk_info,
> - da850_pll0_sysclk_info, 7, base, cfgchip);
> + void __iomem *base;
> + struct regmap *cfgchip;
> +
> + base = of_iomap(node, 0);
> + if (!base) {
> + pr_err("%s: ioremap failed\n", __func__);
> + return;
> + }
> +
> + cfgchip = syscon_regmap_lookup_by_compatible("ti,da830-cfgchip");
It will be nice to handle the error case here.
> +
> + of_davinci_pll_init(NULL, node, &da850_pll0_info,
> + &da850_pll0_obsclk_info,
> + da850_pll0_sysclk_info, 7, base, cfgchip);
Apart from that, it looks good to me.
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] gpio: zynq: Setup chip->base based on alias ID
From: Michal Simek @ 2018-05-15 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57e4bbdd-1e30-0352-f758-998b64a6b77f@xilinx.com>
Hi Linus,
On 2.5.2018 16:19, Michal Simek wrote:
> On 2.5.2018 15:56, Linus Walleij wrote:
>> On Wed, May 2, 2018 at 3:41 PM, Michal Simek <michal.simek@xilinx.com> wrote:
>>
>>> If you don't want this patch I understand that and it will become just
>>> another soc vendor patch out of mainline.
>>
>> I don't really know what to do, so that is why I'm discussing.
>
> me too. It is also interesting that I have met with the case with
> zynq/zynqmp gpio driver and not gpio-xilinx.c which can have a lot of
> instances.
>
>>
>> It's one of those gray areas.
>>
>> From one point of view there is the purist stance that we should
>> only support what the mainline tree does, and be strict and
>> consistent so we don't accumulate to many nasty hacks.
>
> Also this expect that the first patch does everything right which is not
> truth all the time.
>
>>
>> On the other hand, it is completely possible that all users of this
>> particular driver actually must have this patch, and then I just
>> push them to use a deviant vendor tree for no good reason.
>>
>> Would it be possible that I apply the patch, and somehow also
>> establish some understanding with all users of the Xilinx
>> platform that whatever legacy applications are out there
>> must start to migrate towards using the character device so
>> this reliance on the numberspace doesn't stick around forever?
>
> When someone contacts me for asking guidance for gpio I am telling them
> not to use legacy sysfs interface and use libgpiod. Last one was a week
> ago in connection to Ultra96 and libmraa.
>
> But even chardev is not supported there now.
> https://github.com/intel-iot-devkit/mraa/issues/713
>
>>
>> For example can we make a patch to some systems like
>> arch/arm/boot/dts/zynq-*.dts
>> adding proper GPIO line names to these device trees, such
>> as was made in e.g. commit f6b1674d570aa1
>> "arm64: dts: qcom: sbc: Name GPIO lines"
>
> If you take a look at
> arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> which is Ultra96 board gpio-line-names are filled there for the whole PS
> part. Definitely take a look and let know if you find out any issue there.
>
> zynq/zynqmp gpio controller contains PS pins (hard part) and PL pins
> coming to logic.
>
> I can't describe PL gpio pins because it can be whatever even I have
> done that for one fixed hw design.
>
> Interesting part on that sha1 you shared is how "NC" pin is described.
>
> gpio pin 35 I have on zcu100 as "" but it should be maybe TP_PAD which
> is really just a pad on real board. And the rest of "" gpio names are
> connected to PL.
>
> I am happy to take a look at existing platforms and use gpio-line-names
> there. For example arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
> I use in tca6416_u97 and u61 comments instead of this property.
>
Have you done any decision about this patch?
Thanks,
Michal
^ permalink raw reply
* [PATCH] KVM: arm/arm64: fix unaligned hva start and end in handle_hva_to_gpa
From: Jia He @ 2018-05-15 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b9e28c64-78cd-042e-0add-e06b0f57fc36@gmail.com>
On 5/15/2018 8:38 PM, Jia He Wrote:
> Hi Suzuki
>
> On 5/15/2018 4:36 PM, Suzuki K Poulose Wrote:
>>
>> Hi Jia
>>
>> On 05/15/2018 03:03 AM, Jia He wrote:
>>> Hi Suzuki
>>>
>>> I will merge the other thread into this, and add the necessary CC list
>>>
>>> That WARN_ON call trace is very easy to reproduce in my armv8a server after I
>>> start 20 guests
>>>
>>> and run memhog in the host. Of course, ksm should be enabled
>>>
>>> For you question about my inject fault debug patch:
>>
>>
>> Thanks for the patch, comments below.
>>
>>>
>>
>> ...
>>
>>> index 7f6a944..ab8545e 100644
>>> --- a/virt/kvm/arm/mmu.c
>>> +++ b/virt/kvm/arm/mmu.c
>>> @@ -290,12 +290,17 @@ static void unmap_stage2_puds(struct kvm *kvm, pgd_t *pgd,
>>> ?? * destroying the VM), otherwise another faulting VCPU may come in and mess
>>> ?? * with things behind our backs.
>>> ?? */
>>> +extern int trigger_by_ksm;
>>> ??static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
>>> ??{
>>> ???????? pgd_t *pgd;
>>> ???????? phys_addr_t addr = start, end = start + size;
>>> ???????? phys_addr_t next;
>>>
>>> +?????? if(trigger_by_ksm) {
>>> +?????????????? end -= 0x200;
>>> +?????? }
>>> +
>>> ???????? assert_spin_locked(&kvm->mmu_lock);
>>> ???????? pgd = kvm->arch.pgd + stage2_pgd_index(addr);
>>> ???????? do {
>>>
>>> I need to point out that I never reproduced it without this debugging patch.
>>
>> That could trigger the panic iff your "size" <= 0x200, leading to the
>> condition (end < start), which can make the loop go forever, as we
>> do while(addr < end) and end up accessing something which may not be PGD entry
>> and thus get a bad page with bad numbers all around. This case could be hit only
>> with your change and the bug in the KSM which gives us an address near the page
>> boundary.
> No, I injected the fault on purpose to simulate the case when size is less than
> PAGE_SIZE(eg. PAGE_SIZE-0x200=65024)
> I ever got the panic info [1] *without* the debugging patch only once
>
> [1] https://lkml.org/lkml/2018/5/9/992
>>
>> So, I think we can safely ignore the PANIC().
>> More below.
>>
>>
>>>>> Suzuki, thanks for the comments.
>>>>>
>>>>> I proposed another ksm patch https://lkml.org/lkml/2018/5/3/1042
>>>>> The root cause is ksm will add some extra flags to indicate that the page
>>>>> is in/not_in the stable tree. This makes address not be aligned with PAGE_SIZE.
>>>> Thanks for the pointer. In the future, please Cc the people relevant to the
>>>> discussion in the patches.
>>>>
>>>>> ? From arm kvm mmu point of view, do you think handle_hva_to_gpa still need
>>>>> to handle
>>>>> the unalignment case?
>>>> I don't think we should do that. Had we done this, we would never have caught
>>>> this bug
>>>> in KSM. Eventually if some other new implementation comes up with the a new
>>>> notifier
>>>> consumer which doesn't check alignment and doesn't WARN, it could simply do
>>>> the wrong
>>>> thing. So I believe what we have is a good measure to make sure that things are
>>>> in the right order.
>>>>
>>>>> IMO, the PAGE_SIZE alignment is still needed because we should not let the
>>>>> bottom function
>>>>> kvm_age_hva_handler to handle the exception. Please refer to the
>>>>> implementation in X86 and
>>>>> powerpc kvm_handle_hva_range(). They both aligned the hva with
>>>>> hva_to_gfn_memslot.
>>>>>
>>>> ? From an API perspective, you are passed on a "start" and "end" address. So,
>>>> you could potentially
>>>> do the wrong thing if you align the "start" and "end". May be those handlers
>>>> should also do the
>>>> same thing as we do.
>>
>>> But handle_hva_to_gpa has partially adjusted the alignment possibly:
>>> ??? 1750???????? kvm_for_each_memslot(memslot, slots) {
>>> ??? 1751???????????????? unsigned long hva_start, hva_end;
>>> ??? 1752???????????????? gfn_t gpa;
>>> ??? 1753
>>> ??? 1754???????????????? hva_start = max(start, memslot->userspace_addr);
>>> ??? 1755???????????????? hva_end = min(end, memslot->userspace_addr +
>>> ??? 1756???????????????????????????? (memslot->npages << PAGE_SHIFT));
>>>
>>> at line 1755, let us assume that end=0x12340200 and
>>> memslot->userspace_addr + (memslot->npages << PAGE_SHIFT)=0x12340000
>>> Then, hva_start is not page_size aligned and hva_end is aligned, and the size
>>> will be PAGE_SIZE-0x200,
>>> just as what I had done in the inject fault debugging patch.
>>
>> Thats because we want to limit the handling of the hva/gpa range by memslot. So,
>> we make sure we pass on the range within the given memslot
>> to hva_to_gfn_memslot(). But we do iterate over the next memslot if the
>> original range falls in to the next slot. So, in practice, there is no
>> alignment/trimming of the range. Its just that we pass on the appropriate range
>> for each slot.
>>
> Yes, I understand what the codes did in hva_to_gfn_memslot(). What I mean is
> hva_end may be changed and (hva_end - hva_start) will not be same as the
> parameter _size_ ?
>
>> ret |= handler(kvm, gpa, (u64)(hva_end - hva_start), data);
>
> Anyway, I have to admit that all the exceptions are originally caused by the
> STABLE_FLAG in ksm code. What I want to discuss here is how to make arm kvm
> handle the exception more gracefully.
>
Hi Suzuki
How about this patch (balance of avoiding the WARN_ON storm and debugging
convenience):
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 7f6a944..4033946 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -297,6 +297,8 @@ static void unmap_stage2_range(struct kvm *kvm, phys_addr_t
start, u64 size)
phys_addr_t next;
assert_spin_locked(&kvm->mmu_lock);
+
+ WARN_ON_ONCE(size & ~PAGE_MASK);
pgd = kvm->arch.pgd + stage2_pgd_index(addr);
do {
/*
@@ -1792,7 +1794,7 @@ static int kvm_set_spte_handler(struct kvm *kvm, gpa_t
gpa, u64 size, void *data
{
pte_t *pte = (pte_t *)data;
- WARN_ON(size != PAGE_SIZE);
+ WARN_ON_ONCE(size != PAGE_SIZE);
/*
* We can always call stage2_set_pte with KVM_S2PTE_FLAG_LOGGING_ACTIVE
* flag clear because MMU notifiers will have unmapped a huge PMD before
@@ -1823,7 +1825,7 @@ static int kvm_age_hva_handler(struct kvm *kvm, gpa_t gpa,
u64 size, void *data)
pmd_t *pmd;
pte_t *pte;
- WARN_ON(size != PAGE_SIZE && size != PMD_SIZE);
+ WARN_ON_ONCE(size != PAGE_SIZE && size != PMD_SIZE);
pmd = stage2_get_pmd(kvm, NULL, gpa);
if (!pmd || pmd_none(*pmd)) /* Nothing there */
return 0;
@@ -1843,7 +1845,7 @@ static int kvm_test_age_hva_handler(struct kvm *kvm, gpa_t
gpa, u64 size, void *
pmd_t *pmd;
pte_t *pte;
- WARN_ON(size != PAGE_SIZE && size != PMD_SIZE);
+ WARN_ON_ONCE(size != PAGE_SIZE && size != PMD_SIZE);
pmd = stage2_get_pmd(kvm, NULL, gpa);
if (!pmd || pmd_none(*pmd)) /* Nothing there */
return 0;
--
Cheers,
Jia
^ permalink raw reply related
* [PATCH 1/4] amba: Export amba_bustype
From: Kim Phillips @ 2018-05-15 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFqagt5zhz-8hLSXOqofv-nBqg4i-EVjA=UV3Jfi4zktKg@mail.gmail.com>
On Tue, 15 May 2018 08:59:02 +0200
Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 8 May 2018 at 21:06, Kim Phillips <kim.phillips@arm.com> wrote:
> > This patch is provided in the context of allowing the Coresight driver
> > subsystem to be loaded as modules. Coresight uses amba_bus in its call
> > to bus_find_device() in of_coresight_get_endpoint_device() when
> > searching for a configurable endpoint device. This patch allows
> > Coresight to reference amba_bustype when built as a module.
>
> Sounds like you are fixing a bug, don't your want this to go for
> stable and then also add a fixes tag?
How do you consider this a bug fix? What commit would the fixes tag
reference? The introduction of the amba bus? Not only aren't busses
required to export their bus_type, but that commit predates git.
Kim
^ permalink raw reply
* [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Richard Genoud @ 2018-05-15 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95a51c6c69bf1a2422f545ac1f06846ebcdb186a.camel@microchip.com>
On 15/05/2018 14:47, Radu Pirea wrote:
> On Mon, 2018-05-14 at 12:57 +0200, Richard Genoud wrote:
>> After your patch, the DMA is not selected anymore:
>> atmel_usart_serial atmel_usart_serial.0.auto: TX channel not
>> available, switch to pio
>> instead of:
>> atmel_usart fffff200.serial: using dma1chan2 for tx DMA transfers
>>
> Fixed.
>> And the kernel doesn't log anymore on the serial console, despite the
>> loglevel=8
>> (after reverting this series, the kernel logs reappears on the serial
>> console)
>>
> Which serial are you using as console?
fffff200.serial (sam9g35-cm)
( stdout-path = "serial0:115200n8"; in the DTS )
With this series applied, all the kernel log goes on the screen.
Without, it goes on the serial debug.
>> (tests done on sam9g35)
>>
> I will consider the rest of suggestions.
>> regards,
>> Richard
^ permalink raw reply
* [PATCH] arm64: dts: exynos: fix type of thermal trip points for Exynos7
From: Krzysztof Kozlowski @ 2018-05-15 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1702366.qL959G52Hi@amdc3058>
On Tue, May 15, 2018 at 2:37 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> Currently Exynos thermal driver treats as "active" all specified
> trip points before reaching maximum number of hardware supported
> trip points.
The trip point type describe the way how system should act - use
active or passive cooling. It is independent of thermal driver. I do
not understand what is exactly wrong... maybe except whether the trip
point is active/passive looks like property of board, not SoC itself,
but your patch does not address it.
> Moreover polling-delay-passive is specified as "0"
> in exynos7.dtsi (IOW passive polling is disabled).
Which is perfectly fine. TMU driver for Exynos7 supports up to eight
trip points in interrupt mode so having polling mode = 0 is good. IOW
passive polling is disabled just like active polling is disabled so
what did you want to say here?
Best regards,
Krzysztof
> Therefore fix
> type of cpu-alert-0 to cpu-alert6 trip points to be "active"
> instead of "passive" (cpu-alert-7 type is "critical" so it
> doesn't need a fixup).
>
> Cc: Alim Akhtar <alim.akhtar@samsung.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> Index: b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
> ===================================================================
> --- a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi 2018-05-15 13:57:55.822172496 +0200
> +++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi 2018-05-15 14:23:12.594016481 +0200
> @@ -10,37 +10,37 @@ trips {
> cpu-alert-0 {
> temperature = <75000>; /* millicelsius */
> hysteresis = <10000>; /* millicelsius */
> - type = "passive";
> + type = "active";
> };
> cpu-alert-1 {
> temperature = <80000>; /* millicelsius */
> hysteresis = <10000>; /* millicelsius */
> - type = "passive";
> + type = "active";
> };
> cpu-alert-2 {
> temperature = <85000>; /* millicelsius */
> hysteresis = <10000>; /* millicelsius */
> - type = "passive";
> + type = "active";
> };
> cpu-alert-3 {
> temperature = <90000>; /* millicelsius */
> hysteresis = <10000>; /* millicelsius */
> - type = "passive";
> + type = "active";
> };
> cpu-alert-4 {
> temperature = <95000>; /* millicelsius */
> hysteresis = <10000>; /* millicelsius */
> - type = "passive";
> + type = "active";
> };
> cpu-alert-5 {
> temperature = <100000>; /* millicelsius */
> hysteresis = <10000>; /* millicelsius */
> - type = "passive";
> + type = "active";
> };
> cpu-alert-6 {
> temperature = <110000>; /* millicelsius */
> hysteresis = <10000>; /* millicelsius */
> - type = "passive";
> + type = "active";
> };
> cpu-crit-0 {
> temperature = <115000>; /* millicelsius */
>
^ permalink raw reply
* [PATCH v7 08/16] KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing
From: Dave Martin @ 2018-05-15 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515105523.GC38551@C02W217FHV2R.local>
On Tue, May 15, 2018 at 12:55:23PM +0200, Christoffer Dall wrote:
> On Wed, May 09, 2018 at 05:12:57PM +0100, Dave Martin wrote:
> > This patch refactors KVM to align the host and guest FPSIMD
> > save/restore logic with each other for arm64. This reduces the
> > number of redundant save/restore operations that must occur, and
> > reduces the common-case IRQ blackout time during guest exit storms
> > by saving the host state lazily and optimising away the need to
> > restore the host state before returning to the run loop.
[...]
> > diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
[...]
> > +/*
> > + * Prepare vcpu for saving the host's FPSIMD state and loading the guest's.
> > + * The actual loading is done by the FPSIMD access trap taken to hyp.
> > + *
> > + * Here, we just set the correct metadata to indicate that the FPSIMD
> > + * state in the cpu regs (if any) belongs to current on the host.
> > + *
> > + * TIF_SVE is backed up here, since it may get clobbered with guest state.
> > + * This flag is restored by kvm_arch_vcpu_put_fp(vcpu).
> > + */
> > +void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> > +{
> > + BUG_ON(system_supports_sve());
> > + BUG_ON(!current->mm);
> > +
> > + vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_HOST_SVE_IN_USE);
> > + vcpu->arch.flags |= KVM_ARM64_FP_HOST;
> > + if (test_thread_flag(TIF_SVE))
> > + vcpu->arch.flags |= KVM_ARM64_HOST_SVE_IN_USE;
> > +}
> > +
> > +/*
> > + * If the guest FPSIMD state was loaded, update the host's context
> > + * tracking data mark the CPU FPSIMD regs as dirty for vcpu so that they
>
> nit: by marking the CPU FPSIMD regs as dirty and belonging to the
> vcpu... ?
Changed locally.
Marc, let me know if you can pick this up or want me to repost. There
are a couple of pending FWIWs now.
There is also the option to include the separate update_thread_flags()
patches that now have maintainer acks, though I will need to confirm
with the respective maintainers that they're OK with this.
> Otherwise:
>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
[...]
Thanks
---Dave
^ permalink raw reply
* [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Radu Pirea @ 2018-05-15 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a75568e-a52e-3872-f465-d707372a5c12@sorico.fr>
On Mon, 2018-05-14 at 12:57 +0200, Richard Genoud wrote:
> Hi,
>
> On 11/05/2018 12:38, Radu Pirea wrote:
> > This patch modifies the place where resources and device tree
> > properties
> > are searched.
> >
> > Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> > ---
> > drivers/tty/serial/Kconfig | 1 +
> > drivers/tty/serial/atmel_serial.c | 29 +++++++++++++++----------
> > ----
> > 2 files changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/tty/serial/Kconfig
> > b/drivers/tty/serial/Kconfig
> > index 3682fd3e960c..25e55332f8b1 100644
> > --- a/drivers/tty/serial/Kconfig
> > +++ b/drivers/tty/serial/Kconfig
> > @@ -119,6 +119,7 @@ config SERIAL_ATMEL
> > depends on ARCH_AT91 || COMPILE_TEST
> > select SERIAL_CORE
> > select SERIAL_MCTRL_GPIO if GPIOLIB
> > + select MFD_AT91_USART
> > help
> > This enables the driver for the on-chip UARTs of the
> > Atmel
> > AT91 processors.
> > diff --git a/drivers/tty/serial/atmel_serial.c
> > b/drivers/tty/serial/atmel_serial.c
> > index df46a9e88c34..6b4494352853 100644
> > --- a/drivers/tty/serial/atmel_serial.c
> > +++ b/drivers/tty/serial/atmel_serial.c
> > @@ -193,8 +193,8 @@ static struct console atmel_console;
> >
> > #if defined(CONFIG_OF)
> > static const struct of_device_id atmel_serial_dt_ids[] = {
> > - { .compatible = "atmel,at91rm9200-usart" },
> > - { .compatible = "atmel,at91sam9260-usart" },
> > + { .compatible = "atmel,at91rm9200-usart-serial" },
> > + { .compatible = "atmel,at91sam9260-usart-serial" },
> > { /* sentinel */ }
> > };
> > #endif
> > @@ -1631,7 +1631,7 @@ static void atmel_tasklet_tx_func(unsigned
> > long data)
> > static void atmel_init_property(struct atmel_uart_port
> > *atmel_port,
> > struct platform_device *pdev)
> > {
> > - struct device_node *np = pdev->dev.of_node;
> > + struct device_node *np = pdev->dev.parent->of_node;
> >
> > /* DMA/PDC usage specification */
> > if (of_property_read_bool(np, "atmel,use-dma-rx")) {
> > @@ -2223,7 +2223,8 @@ static const char *atmel_type(struct
> > uart_port *port)
> > static void atmel_release_port(struct uart_port *port)
> > {
> > struct platform_device *pdev = to_platform_device(port-
> > >dev);
> > - int size = pdev->resource[0].end - pdev->resource[0].start
> > + 1;
> > + int size = to_platform_device(pdev->dev.parent)-
> > >resource[0].end -
> > + to_platform_device(pdev->dev.parent)-
> > >resource[0].start + 1;
>
> I think it may be simpler with something like:
> + struct platform_device *mfd_pdev = to_platform_device(port-
> >dev->parent);
> + int size = mfd_pdev->resource[0].end - mfd_pdev-
> >resource[0].start + 1;
>
> >
> > release_mem_region(port->mapbase, size);
> >
> > @@ -2239,7 +2240,8 @@ static void atmel_release_port(struct
> > uart_port *port)
> > static int atmel_request_port(struct uart_port *port)
> > {
> > struct platform_device *pdev = to_platform_device(port-
> > >dev);
> > - int size = pdev->resource[0].end - pdev->resource[0].start
> > + 1;
> > + int size = to_platform_device(pdev->dev.parent)-
> > >resource[0].end -
> > + to_platform_device(pdev->dev.parent)-
> > >resource[0].start + 1;
> >
>
> ditto
>
> > if (!request_mem_region(port->mapbase, size,
> > "atmel_serial"))
> > return -EBUSY;
> > @@ -2345,23 +2347,23 @@ static int atmel_init_port(struct
> > atmel_uart_port *atmel_port,
>
> Here, we could also add:
> + struct device *mfd_dev = pdev->dev.parent;
> + struct platform_device *mfd_pdev =
> to_platform_device(mfd_dev);
>
> > atmel_init_property(atmel_port, pdev);
> > atmel_set_ops(port);
> >
> > - uart_get_rs485_mode(&pdev->dev, &port->rs485);
> > + uart_get_rs485_mode(pdev->dev.parent, &port->rs485);
>
> ...and use them here
>
> >
> > port->iotype = UPIO_MEM;
> > port->flags = UPF_BOOT_AUTOCONF |
> > UPF_IOREMAP;
> > port->ops = &atmel_pops;
> > port->fifosize = 1;
> > port->dev = &pdev->dev;
> > - port->mapbase = pdev->resource[0].start;
> > - port->irq = pdev->resource[1].start;
> > + port->mapbase = to_platform_device(pdev-
> > >dev.parent)->resource[0].start;
> > + port->irq = to_platform_device(pdev-
> > >dev.parent)->resource[1].start;
>
> and here
> I think it would be easier to read.
>
> > port->rs485_config = atmel_config_rs485;
> > - port->membase = NULL;
> > + port->membase = NULL;
> >
> > memset(&atmel_port->rx_ring, 0, sizeof(atmel_port-
> > >rx_ring));
> >
> > /* for console, the clock could already be configured */
> > if (!atmel_port->clk) {
> > - atmel_port->clk = clk_get(&pdev->dev, "usart");
> > + atmel_port->clk = clk_get(pdev->dev.parent,
> > "usart");
>
> and here
>
> > if (IS_ERR(atmel_port->clk)) {
> > ret = PTR_ERR(atmel_port->clk);
> > atmel_port->clk = NULL;
> > @@ -2656,7 +2658,7 @@ static void atmel_serial_probe_fifos(struct
> > atmel_uart_port *atmel_port,
> > atmel_port->rts_low = 0;
> > atmel_port->rts_high = 0;
> >
> > - if (of_property_read_u32(pdev->dev.of_node,
> > + if (of_property_read_u32(pdev->dev.parent->of_node,
> > "atmel,fifo-size",
> > &atmel_port->fifo_size))
> > return;
> > @@ -2694,11 +2696,10 @@ static void atmel_serial_probe_fifos(struct
> > atmel_uart_port *atmel_port,
> > static int atmel_serial_probe(struct platform_device *pdev)
> > {
> > struct atmel_uart_port *atmel_port;
> > - struct device_node *np = pdev->dev.of_node;
> > + struct device_node *np = pdev->dev.parent->of_node;
> > void *data;
> > int ret = -ENODEV;
> > bool rs485_enabled;
> > -
>
> I think this line feed wasn't so bad.
>
> > BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE &
> > (ATMEL_SERIAL_RINGSIZE - 1));
> >
> > ret = of_alias_get_id(np, "serial");
> > @@ -2845,7 +2846,7 @@ static struct platform_driver
> > atmel_serial_driver = {
> > .suspend = atmel_serial_suspend,
> > .resume = atmel_serial_resume,
> > .driver = {
> > - .name = "atmel_usart",
> > + .name =
> > "atmel_usart_serial",
> > .of_match_table =
> > of_match_ptr(atmel_serial_dt_ids),
> > },
> > };
> >
>
> After your patch, the DMA is not selected anymore:
> atmel_usart_serial atmel_usart_serial.0.auto: TX channel not
> available, switch to pio
> instead of:
> atmel_usart fffff200.serial: using dma1chan2 for tx DMA transfers
>
Fixed.
> And the kernel doesn't log anymore on the serial console, despite the
> loglevel=8
> (after reverting this series, the kernel logs reappears on the serial
> console)
>
Which serial are you using as console?
> (tests done on sam9g35)
>
I will consider the rest of suggestions.
> regards,
> Richard
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180515/f865516c/attachment.sig>
^ 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