* [PATCH] ARM: dts: imx51-zii-rdu1: fix touchscreen bindings
From: Fabio Estevam @ 2018-05-07 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507135309.32580-1-nikita.yoush@cogentembedded.com>
Hi Nikita,
On Mon, May 7, 2018 at 10:53 AM, Nikita Yushchenko
<nikita.yoush@cogentembedded.com> wrote:
> This fixes errors in RDU1 device tree that cause touch screens not
> working.
Fixes: ceef0396f367 ("ARM: dts: imx: add ZII RDU1 board")
Cc: stable at vger.kernel.org #4.15+
> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 2/4] phy: rockchip-typec: support variable phy config value
From: Enric Balletbo Serra @ 2018-05-07 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525421338-1021-2-git-send-email-hl@rock-chips.com>
Hi Lin,
Thanks for the patch, apart from the new build warnings introduced
some more comments below.
2018-05-04 10:08 GMT+02:00 Lin Huang <hl@rock-chips.com>:
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> drivers/phy/rockchip/phy-rockchip-typec.c | 286 +++++++++++++++++++-----------
> include/soc/rockchip/rockchip_phy_typec.h | 72 ++++++++
> 2 files changed, 259 insertions(+), 99 deletions(-)
> create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c
> index 76a4b58..831a93b 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
> @@ -63,6 +63,7 @@
>
> #include <linux/mfd/syscon.h>
> #include <linux/phy/phy.h>
> +#include <soc/rockchip/rockchip_phy_typec.h>
>
> #define CMN_SSM_BANDGAP (0x21 << 2)
> #define CMN_SSM_BIAS (0x22 << 2)
> @@ -323,23 +324,31 @@
> * clock 0: PLL 0 div 1
> * clock 1: PLL 1 div 2
> */
> -#define CLK_PLL_CONFIG 0X30
> +#define CLK_PLL1_DIV1 0x20
> +#define CLK_PLL1_DIV2 0x30
> #define CLK_PLL_MASK 0x33
>
> #define CMN_READY BIT(0)
>
> +#define DP_PLL_CLOCK_ENABLE_ACK BIT(3)
> #define DP_PLL_CLOCK_ENABLE BIT(2)
> +#define DP_PLL_ENABLE_ACK BIT(1)
> #define DP_PLL_ENABLE BIT(0)
> #define DP_PLL_DATA_RATE_RBR ((2 << 12) | (4 << 8))
> #define DP_PLL_DATA_RATE_HBR ((2 << 12) | (4 << 8))
> #define DP_PLL_DATA_RATE_HBR2 ((1 << 12) | (2 << 8))
> +#define DP_PLL_DATA_RATE_MASK 0xff00
>
> -#define DP_MODE_A0 BIT(4)
> -#define DP_MODE_A2 BIT(6)
> -#define DP_MODE_ENTER_A0 0xc101
> -#define DP_MODE_ENTER_A2 0xc104
> +#define DP_MODE_MASK 0xf
> +#define DP_MODE_ENTER_A0 BIT(0)
> +#define DP_MODE_ENTER_A2 BIT(2)
> +#define DP_MODE_ENTER_A3 BIT(3)
> +#define DP_MODE_A0_ACK BIT(4)
> +#define DP_MODE_A2_ACK BIT(6)
> +#define DP_MODE_A3_ACK BIT(7)
> +#define DP_LINK_RESET_DEASSERTED BIT(8)
>
> -#define PHY_MODE_SET_TIMEOUT 100000
> +#define PHY_MODE_SET_TIMEOUT 1000000
>
Why do you need to increase this timeout? Is because the software link
training timed out using the old value?
> #define PIN_ASSIGN_C_E 0x51d9
> #define PIN_ASSIGN_D_F 0x5100
> @@ -349,51 +358,7 @@
> #define MODE_DFP_USB BIT(1)
> #define MODE_DFP_DP BIT(2)
>
> -struct usb3phy_reg {
> - u32 offset;
> - u32 enable_bit;
> - u32 write_enable;
> -};
> -
> -/**
> - * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
> - * @reg: the base address for usb3-phy config.
> - * @typec_conn_dir: the register of type-c connector direction.
> - * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
> - * @external_psm: the register of type-c phy external psm clock.
> - * @pipe_status: the register of type-c phy pipe status.
> - * @usb3_host_disable: the register of type-c usb3 host disable.
> - * @usb3_host_port: the register of type-c usb3 host port.
> - * @uphy_dp_sel: the register of type-c phy DP select control.
> - */
> -struct rockchip_usb3phy_port_cfg {
> - unsigned int reg;
> - struct usb3phy_reg typec_conn_dir;
> - struct usb3phy_reg usb3tousb2_en;
> - struct usb3phy_reg external_psm;
> - struct usb3phy_reg pipe_status;
> - struct usb3phy_reg usb3_host_disable;
> - struct usb3phy_reg usb3_host_port;
> - struct usb3phy_reg uphy_dp_sel;
> -};
> -
> -struct rockchip_typec_phy {
> - struct device *dev;
> - void __iomem *base;
> - struct extcon_dev *extcon;
> - struct regmap *grf_regs;
> - struct clk *clk_core;
> - struct clk *clk_ref;
> - struct reset_control *uphy_rst;
> - struct reset_control *pipe_rst;
> - struct reset_control *tcphy_rst;
> - const struct rockchip_usb3phy_port_cfg *port_cfgs;
> - /* mutex to protect access to individual PHYs */
> - struct mutex lock;
> -
> - bool flip;
> - u8 mode;
> -};
> +#define DEFAULT_RATE 162000
>
DEFAULT_RATE seems a very common name for me, maybe add a prefix?
> struct phy_reg {
> u16 value;
> @@ -417,15 +382,15 @@ struct phy_reg usb3_pll_cfg[] = {
> { 0x8, CMN_DIAG_PLL0_LF_PROG },
> };
>
> -struct phy_reg dp_pll_cfg[] = {
> +struct phy_reg dp_pll_rbr_cfg[] = {
> { 0xf0, CMN_PLL1_VCOCAL_INIT },
> { 0x18, CMN_PLL1_VCOCAL_ITER },
> { 0x30b9, CMN_PLL1_VCOCAL_START },
> - { 0x21c, CMN_PLL1_INTDIV },
> + { 0x87, CMN_PLL1_INTDIV },
> { 0, CMN_PLL1_FRACDIV },
> - { 0x5, CMN_PLL1_HIGH_THR },
> - { 0x35, CMN_PLL1_SS_CTRL1 },
> - { 0x7f1e, CMN_PLL1_SS_CTRL2 },
> + { 0x22, CMN_PLL1_HIGH_THR },
> + { 0x8000, CMN_PLL1_SS_CTRL1 },
> + { 0, CMN_PLL1_SS_CTRL2 },
> { 0x20, CMN_PLL1_DSM_DIAG },
> { 0, CMN_PLLSM1_USER_DEF_CTRL },
> { 0, CMN_DIAG_PLL1_OVRD },
> @@ -436,9 +401,52 @@ struct phy_reg dp_pll_cfg[] = {
> { 0x8, CMN_DIAG_PLL1_LF_PROG },
> { 0x100, CMN_DIAG_PLL1_PTATIS_TUNE1 },
> { 0x7, CMN_DIAG_PLL1_PTATIS_TUNE2 },
> - { 0x4, CMN_DIAG_PLL1_INCLK_CTRL },
> + { 0x1, CMN_DIAG_PLL1_INCLK_CTRL },
> +};
> +
> +struct phy_reg dp_pll_hbr_cfg[] = {
> + { 0xf0, CMN_PLL1_VCOCAL_INIT },
> + { 0x18, CMN_PLL1_VCOCAL_ITER },
> + { 0x30b4, CMN_PLL1_VCOCAL_START },
> + { 0xe1, CMN_PLL1_INTDIV },
> + { 0, CMN_PLL1_FRACDIV },
> + { 0x5, CMN_PLL1_HIGH_THR },
> + { 0x8000, CMN_PLL1_SS_CTRL1 },
> + { 0, CMN_PLL1_SS_CTRL2 },
> + { 0x20, CMN_PLL1_DSM_DIAG },
> + { 0x1000, CMN_PLLSM1_USER_DEF_CTRL },
> + { 0, CMN_DIAG_PLL1_OVRD },
> + { 0, CMN_DIAG_PLL1_FBH_OVRD },
> + { 0, CMN_DIAG_PLL1_FBL_OVRD },
> + { 0x7, CMN_DIAG_PLL1_V2I_TUNE },
> + { 0x45, CMN_DIAG_PLL1_CP_TUNE },
> + { 0x8, CMN_DIAG_PLL1_LF_PROG },
> + { 0x1, CMN_DIAG_PLL1_PTATIS_TUNE1 },
> + { 0x1, CMN_DIAG_PLL1_PTATIS_TUNE2 },
> + { 0x1, CMN_DIAG_PLL1_INCLK_CTRL },
> };
>
> +struct phy_reg dp_pll_hbr2_cfg[] = {
> + { 0xf0, CMN_PLL1_VCOCAL_INIT },
> + { 0x18, CMN_PLL1_VCOCAL_ITER },
> + { 0x30b4, CMN_PLL1_VCOCAL_START },
> + { 0xe1, CMN_PLL1_INTDIV },
> + { 0, CMN_PLL1_FRACDIV },
> + { 0x5, CMN_PLL1_HIGH_THR },
> + { 0x8000, CMN_PLL1_SS_CTRL1 },
> + { 0, CMN_PLL1_SS_CTRL2 },
> + { 0x20, CMN_PLL1_DSM_DIAG },
> + { 0x1000, CMN_PLLSM1_USER_DEF_CTRL },
> + { 0, CMN_DIAG_PLL1_OVRD },
> + { 0, CMN_DIAG_PLL1_FBH_OVRD },
> + { 0, CMN_DIAG_PLL1_FBL_OVRD },
> + { 0x7, CMN_DIAG_PLL1_V2I_TUNE },
> + { 0x45, CMN_DIAG_PLL1_CP_TUNE },
> + { 0x8, CMN_DIAG_PLL1_LF_PROG },
> + { 0x1, CMN_DIAG_PLL1_PTATIS_TUNE1 },
> + { 0x1, CMN_DIAG_PLL1_PTATIS_TUNE2 },
> + { 0x1, CMN_DIAG_PLL1_INCLK_CTRL },
> +};
> static const struct rockchip_usb3phy_port_cfg rk3399_usb3phy_port_cfgs[] = {
> {
> .reg = 0xff7c0000,
> @@ -484,7 +492,7 @@ static void tcphy_cfg_24m(struct rockchip_typec_phy *tcphy)
>
> rdata = readl(tcphy->base + CMN_DIAG_HSCLK_SEL);
> rdata &= ~CLK_PLL_MASK;
> - rdata |= CLK_PLL_CONFIG;
> + rdata |= CLK_PLL1_DIV2;
> writel(rdata, tcphy->base + CMN_DIAG_HSCLK_SEL);
> }
>
> @@ -498,17 +506,44 @@ static void tcphy_cfg_usb3_pll(struct rockchip_typec_phy *tcphy)
> tcphy->base + usb3_pll_cfg[i].addr);
> }
>
> -static void tcphy_cfg_dp_pll(struct rockchip_typec_phy *tcphy)
> +static void tcphy_cfg_dp_pll(struct rockchip_typec_phy *tcphy, int link_rate)
> {
> - u32 i;
> + struct phy_reg *phy_cfg;
> + u32 clk_ctrl;
> + u32 i, cfg_size, hsclk_sel;
> +
> + hsclk_sel = readl(tcphy->base + CMN_DIAG_HSCLK_SEL);
> + hsclk_sel &= ~CLK_PLL_MASK;
> +
> + switch (link_rate) {
> + case 162000:
> + clk_ctrl = DP_PLL_DATA_RATE_RBR;
> + hsclk_sel |= CLK_PLL1_DIV2;
> + phy_cfg = dp_pll_rbr_cfg;
> + cfg_size = ARRAY_SIZE(dp_pll_rbr_cfg);
> + break;
> + case 270000:
> + clk_ctrl = DP_PLL_DATA_RATE_HBR;
> + hsclk_sel |= CLK_PLL1_DIV2;
> + phy_cfg = dp_pll_hbr_cfg;
> + cfg_size = ARRAY_SIZE(dp_pll_hbr_cfg);
> + break;
> + case 540000:
> + clk_ctrl = DP_PLL_DATA_RATE_HBR2;
> + hsclk_sel |= CLK_PLL1_DIV1;
> + phy_cfg = dp_pll_hbr2_cfg;
> + cfg_size = ARRAY_SIZE(dp_pll_hbr2_cfg);
> + break;
> + }
> +
> + clk_ctrl |= DP_PLL_CLOCK_ENABLE | DP_PLL_ENABLE;
> + writel(clk_ctrl, tcphy->base + DP_CLK_CTL);
>
> - /* set the default mode to RBR */
> - writel(DP_PLL_CLOCK_ENABLE | DP_PLL_ENABLE | DP_PLL_DATA_RATE_RBR,
> - tcphy->base + DP_CLK_CTL);
> + writel(hsclk_sel, tcphy->base + CMN_DIAG_HSCLK_SEL);
>
> /* load the configuration of PLL1 */
> - for (i = 0; i < ARRAY_SIZE(dp_pll_cfg); i++)
> - writel(dp_pll_cfg[i].value, tcphy->base + dp_pll_cfg[i].addr);
> + for (i = 0; i < cfg_size; i++)
> + writel(phy_cfg[i].value, tcphy->base + phy_cfg[i].addr);
> }
>
> static void tcphy_tx_usb3_cfg_lane(struct rockchip_typec_phy *tcphy, u32 lane)
> @@ -535,9 +570,10 @@ static void tcphy_rx_usb3_cfg_lane(struct rockchip_typec_phy *tcphy, u32 lane)
> writel(0xfb, tcphy->base + XCVR_DIAG_BIDI_CTRL(lane));
> }
>
> -static void tcphy_dp_cfg_lane(struct rockchip_typec_phy *tcphy, u32 lane)
> +static void tcphy_dp_cfg_lane(struct rockchip_typec_phy *tcphy, int link_rate,
> + u8 swing, u8 pre_emp, u32 lane)
> {
> - u16 rdata;
> + u16 val;
>From what I see you are only renaming rdata to val, there is any reason?
>
> writel(0xbefc, tcphy->base + XCVR_PSM_RCTRL(lane));
> writel(0x6799, tcphy->base + TX_PSC_A0(lane));
> @@ -545,25 +581,31 @@ static void tcphy_dp_cfg_lane(struct rockchip_typec_phy *tcphy, u32 lane)
> writel(0x98, tcphy->base + TX_PSC_A2(lane));
> writel(0x98, tcphy->base + TX_PSC_A3(lane));
>
> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_000(lane));
> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_001(lane));
> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_010(lane));
> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_011(lane));
> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_100(lane));
> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_101(lane));
> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_110(lane));
> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_111(lane));
> - writel(0, tcphy->base + TX_TXCC_CPOST_MULT_10(lane));
> - writel(0, tcphy->base + TX_TXCC_CPOST_MULT_01(lane));
> - writel(0, tcphy->base + TX_TXCC_CPOST_MULT_00(lane));
> - writel(0, tcphy->base + TX_TXCC_CPOST_MULT_11(lane));
> -
> - writel(0x128, tcphy->base + TX_TXCC_CAL_SCLR_MULT(lane));
> - writel(0x400, tcphy->base + TX_DIAG_TX_DRV(lane));
> -
> - rdata = readl(tcphy->base + XCVR_DIAG_PLLDRC_CTRL(lane));
> - rdata = (rdata & 0x8fff) | 0x6000;
> - writel(rdata, tcphy->base + XCVR_DIAG_PLLDRC_CTRL(lane));
> + writel(tcphy->config[swing][pre_emp].swing,
> + tcphy->base + TX_TXCC_MGNFS_MULT_000(lane));
> + writel(tcphy->config[swing][pre_emp].pe,
> + tcphy->base + TX_TXCC_CPOST_MULT_00(lane));
> +
> + if (swing == 2 && pre_emp == 0 && link_rate != 540000) {
> + writel(0x700, tcphy->base + TX_DIAG_TX_DRV(lane));
> + writel(0x13c, tcphy->base + TX_TXCC_CAL_SCLR_MULT(lane));
> + } else {
> + writel(0x128, tcphy->base + TX_TXCC_CAL_SCLR_MULT(lane));
> + writel(0x0400, tcphy->base + TX_DIAG_TX_DRV(lane));
> + }
> +
> + val = readl(tcphy->base + XCVR_DIAG_PLLDRC_CTRL(lane));
> + val = val & 0x8fff;
> + switch (link_rate) {
> + case 162000:
> + case 270000:
> + val |= (6 << 12);
> + break;
> + case 540000:
> + val |= (4 << 12);
> + break;
> + }
> + writel(val, tcphy->base + XCVR_DIAG_PLLDRC_CTRL(lane));
> }
>
> static inline int property_enable(struct rockchip_typec_phy *tcphy,
> @@ -754,30 +796,33 @@ static int tcphy_phy_init(struct rockchip_typec_phy *tcphy, u8 mode)
> tcphy_cfg_24m(tcphy);
>
> if (mode == MODE_DFP_DP) {
> - tcphy_cfg_dp_pll(tcphy);
> + tcphy_cfg_dp_pll(tcphy, DEFAULT_RATE);
> for (i = 0; i < 4; i++)
> - tcphy_dp_cfg_lane(tcphy, i);
> + tcphy_dp_cfg_lane(tcphy, DEFAULT_RATE, 0, 0, i);
>
> writel(PIN_ASSIGN_C_E, tcphy->base + PMA_LANE_CFG);
> } else {
> tcphy_cfg_usb3_pll(tcphy);
> - tcphy_cfg_dp_pll(tcphy);
> + tcphy_cfg_dp_pll(tcphy, DEFAULT_RATE);
> if (tcphy->flip) {
> tcphy_tx_usb3_cfg_lane(tcphy, 3);
> tcphy_rx_usb3_cfg_lane(tcphy, 2);
> - tcphy_dp_cfg_lane(tcphy, 0);
> - tcphy_dp_cfg_lane(tcphy, 1);
> + tcphy_dp_cfg_lane(tcphy, DEFAULT_RATE, 0, 0, 0);
> + tcphy_dp_cfg_lane(tcphy, DEFAULT_RATE, 0, 0, 1);
> } else {
> tcphy_tx_usb3_cfg_lane(tcphy, 0);
> tcphy_rx_usb3_cfg_lane(tcphy, 1);
> - tcphy_dp_cfg_lane(tcphy, 2);
> - tcphy_dp_cfg_lane(tcphy, 3);
> + tcphy_dp_cfg_lane(tcphy, DEFAULT_RATE, 0, 0, 2);
> + tcphy_dp_cfg_lane(tcphy, DEFAULT_RATE, 0, 0, 3);
> }
>
> writel(PIN_ASSIGN_D_F, tcphy->base + PMA_LANE_CFG);
> }
>
> - writel(DP_MODE_ENTER_A2, tcphy->base + DP_MODE_CTL);
> + val = readl(tcphy->base + DP_MODE_CTL);
> + val &= ~DP_MODE_MASK;
> + val |= DP_MODE_ENTER_A2 | DP_LINK_RESET_DEASSERTED;
> + writel(val, tcphy->base + DP_MODE_CTL);
>
> reset_control_deassert(tcphy->uphy_rst);
>
> @@ -990,7 +1035,7 @@ static int rockchip_dp_phy_power_on(struct phy *phy)
> property_enable(tcphy, &cfg->uphy_dp_sel, 1);
>
> ret = readx_poll_timeout(readl, tcphy->base + DP_MODE_CTL,
> - val, val & DP_MODE_A2, 1000,
> + val, val & DP_MODE_A2_ACK, 1000,
> PHY_MODE_SET_TIMEOUT);
> if (ret < 0) {
> dev_err(tcphy->dev, "failed to wait TCPHY enter A2\n");
> @@ -999,13 +1044,19 @@ static int rockchip_dp_phy_power_on(struct phy *phy)
>
> tcphy_dp_aux_calibration(tcphy);
>
> - writel(DP_MODE_ENTER_A0, tcphy->base + DP_MODE_CTL);
> + /* enter A0 mode */
> + val = readl(tcphy->base + DP_MODE_CTL);
> + val &= ~DP_MODE_MASK;
> + val |= DP_MODE_ENTER_A0;
> + writel(val, tcphy->base + DP_MODE_CTL);
>
> ret = readx_poll_timeout(readl, tcphy->base + DP_MODE_CTL,
> - val, val & DP_MODE_A0, 1000,
> + val, val & DP_MODE_A0_ACK, 1000,
> PHY_MODE_SET_TIMEOUT);
> if (ret < 0) {
> - writel(DP_MODE_ENTER_A2, tcphy->base + DP_MODE_CTL);
> + val &= ~DP_MODE_MASK;
> + val |= DP_MODE_ENTER_A2;
> + writel(val, tcphy->base + DP_MODE_CTL);
> dev_err(tcphy->dev, "failed to wait TCPHY enter A0\n");
> goto power_on_finish;
> }
> @@ -1023,6 +1074,7 @@ static int rockchip_dp_phy_power_on(struct phy *phy)
> static int rockchip_dp_phy_power_off(struct phy *phy)
> {
> struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
> + u32 val;
>
> mutex_lock(&tcphy->lock);
>
> @@ -1031,7 +1083,10 @@ static int rockchip_dp_phy_power_off(struct phy *phy)
>
> tcphy->mode &= ~MODE_DFP_DP;
>
> - writel(DP_MODE_ENTER_A2, tcphy->base + DP_MODE_CTL);
> + val = readl(tcphy->base + DP_MODE_CTL);
> + val &= ~DP_MODE_MASK;
> + val |= DP_MODE_ENTER_A2;
> + writel(val, tcphy->base + DP_MODE_CTL);
>
> if (tcphy->mode == MODE_DISCONNECT)
> tcphy_phy_deinit(tcphy);
> @@ -1047,6 +1102,30 @@ static const struct phy_ops rockchip_dp_phy_ops = {
> .owner = THIS_MODULE,
> };
>
> +static int type_c_dp_phy_config(struct phy *phy, int link_rate,
s/type_c/typec/ to be coherent with the rest of the code.
> + int lanes, u8 swing, u8 pre_emp)
> +{
> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
> + u8 i;
> +
> + tcphy_cfg_dp_pll(tcphy, link_rate);
> +
> + if (tcphy->mode == MODE_DFP_DP) {
> + for (i = 0; i < 4; i++)
> + tcphy_dp_cfg_lane(tcphy, link_rate, swing, pre_emp, i);
> + } else {
> + if (tcphy->flip) {
> + tcphy_dp_cfg_lane(tcphy, link_rate, swing, pre_emp, 0);
> + tcphy_dp_cfg_lane(tcphy, link_rate, swing, pre_emp, 1);
> + } else {
> + tcphy_dp_cfg_lane(tcphy, link_rate, swing, pre_emp, 2);
> + tcphy_dp_cfg_lane(tcphy, link_rate, swing, pre_emp, 3);
> + }
> + }
> +
> + return 0;
> +}
> +
> static int tcphy_parse_dt(struct rockchip_typec_phy *tcphy,
> struct device *dev)
> {
> @@ -1087,6 +1166,14 @@ static int tcphy_parse_dt(struct rockchip_typec_phy *tcphy,
> return PTR_ERR(tcphy->tcphy_rst);
> }
>
> + /*
> + * check if phy_config pass from dts, if yes,
> + * need to use this phy config to do software training later
> + */
> + if (!of_property_read_u32_array(dev->of_node, "rockchip,phy_config",
> + (u32 *)tcphy->config, sizeof(tcphy->config) / sizeof(u32)))
> + tcphy->need_software_training = 1;
> +
> return 0;
> }
>
> @@ -1171,6 +1258,7 @@ static int rockchip_typec_phy_probe(struct platform_device *pdev)
> }
> }
>
> + tcphy->typec_phy_config = type_c_dp_phy_config;
type_c_dp_phy_config -> typec_dp_phy_config
> pm_runtime_enable(dev);
>
> for_each_available_child_of_node(np, child_np) {
> diff --git a/include/soc/rockchip/rockchip_phy_typec.h b/include/soc/rockchip/rockchip_phy_typec.h
> new file mode 100644
> index 0000000..e25840e
> --- /dev/null
> +++ b/include/soc/rockchip/rockchip_phy_typec.h
> @@ -0,0 +1,72 @@
> +/*
Add the SPDX License identifier ...
> + * Copyright (c) 2018, Fuzhou Rockchip Electronics Co., Ltd
> + * Author: Lin Huang <hl@rock-chips.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
... and remove the above notice.
> + */
> +#ifndef __SOC_ROCKCHIP_PHY_TYPEC_H
> +#define __SOC_ROCKCHIP_PHY_TYPEC_H
> +
> +
Remove the extra new line.
> +struct usb3phy_reg {
> + u32 offset;
> + u32 enable_bit;
> + u32 write_enable;
> +};
> +
> +/**
> + * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
> + * @reg: the base address for usb3-phy config.
> + * @typec_conn_dir: the register of type-c connector direction.
> + * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
> + * @external_psm: the register of type-c phy external psm clock.
> + * @pipe_status: the register of type-c phy pipe status.
> + * @usb3_host_disable: the register of type-c usb3 host disable.
> + * @usb3_host_port: the register of type-c usb3 host port.
> + * @uphy_dp_sel: the register of type-c phy DP select control.
> + */
> +struct rockchip_usb3phy_port_cfg {
> + unsigned int reg;
> + struct usb3phy_reg typec_conn_dir;
> + struct usb3phy_reg usb3tousb2_en;
> + struct usb3phy_reg external_psm;
> + struct usb3phy_reg pipe_status;
> + struct usb3phy_reg usb3_host_disable;
> + struct usb3phy_reg usb3_host_port;
> + struct usb3phy_reg uphy_dp_sel;
> +};
> +
> +struct phy_config {
> + int swing;
> + int pe;
> +};
> +
> +struct rockchip_typec_phy {
> + struct device *dev;
> + void __iomem *base;
> + struct extcon_dev *extcon;
> + struct regmap *grf_regs;
> + struct clk *clk_core;
> + struct clk *clk_ref;
> + struct reset_control *uphy_rst;
> + struct reset_control *pipe_rst;
> + struct reset_control *tcphy_rst;
> + struct rockchip_usb3phy_port_cfg *port_cfgs;
> + /* mutex to protect access to individual PHYs */
> + struct mutex lock;
> + struct phy_config config[3][4];
> + u8 need_software_training;
> + bool flip;
> + u8 mode;
> + int (*typec_phy_config)(struct phy *phy, int link_rate,
> + int lanes, u8 swing, u8 pre_emp);
> +};
> +
> +#endif
Best regards,
Enric
> --
> 2.7.4
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
From: Peter Rosin @ 2018-05-07 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507133929.GG12521@phenom.ffwll.local>
On 2018-05-07 15:39, Daniel Vetter wrote:
> On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
>> On 2018-05-03 11:06, Daniel Vetter wrote:
>>> On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
>>>> The more natural approach would perhaps be to add an drm_bridge_add,
>>>> but there are several other bridges that never call drm_bridge_add.
>>>> Just removing the drm_bridge_remove is the easier fix.
>>>>
>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>>
>>> This mess is much bigger. There's 2 pairs of bridge functions:
>>>
>>> - drm_bridge_attach/detach. Those are meant to be called by the overall
>>> drm driver to connect/disconnect a drm_bridge.
>>>
>>> - drm_bridge_add/remove. These are supposed to be called by the bridge
>>> driver itself to register/unregister itself. Maybe we should rename
>>> them, since the same issue happens with drm_panel, with the same
>>> confusion.
>>>
>>> I thought someone was working on a cleanup series to fix this mess, but I
>>> didn't find anything.
>>
>> Ok, I just spotted the imbalance and didn't really dig into what
>> actually happens in these error paths. Now that I have done so I
>> believe that the removed drm_bridge_remove calls causes NULL
>> dereferences if/when the error paths are triggered.
>>
>> So, I don't think this can wait for some bigger cleanup.
>>
>> drm_bridge_remove calls list_del_init calls __list_del_entry calls
>> __list_del with NULL in both prev and next since the list member
>> is never initialized. prev and next are dereferenced by __list_del
>> and you have *boom*
>>
>> I recommend adding the tag
>>
>> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
>>
>> so that stable picks this one up.
>
> I just wanted to correct your commit message text - the correct solution
> is definitely _not_ for sti here to call drm_bridge_add.
Ah, I see what you mean. Do you want me to respin?
> It should call
> drm_bridge_attach/detach only, as a pair.
Alas, the attach/detach functions are generally not called from the same
level. After the bridge has been attached to an encoder, it is detached
in the generic code shutting down the encoder, i.e. the bridge consumer
is not explicitly involved with bridge detaching.
> I didn't check whether you instead have a _detach call missing or what's
> going on here.
So, even though there is no _detach call, it is still not "missing" as
it is not supposed to be there...
Cheers,
Peter
> -Daniel
>>
>> Cheers,
>> Peter
>>
>>> -Daniel
>>>
>>>> ---
>>>> drivers/gpu/drm/sti/sti_hda.c | 1 -
>>>> drivers/gpu/drm/sti/sti_hdmi.c | 1 -
>>>> 2 files changed, 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
>>>> index 67bbdb49fffc..199db13f565c 100644
>>>> --- a/drivers/gpu/drm/sti/sti_hda.c
>>>> +++ b/drivers/gpu/drm/sti/sti_hda.c
>>>> @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device *master, void *data)
>>>> return 0;
>>>>
>>>> err_sysfs:
>>>> - drm_bridge_remove(bridge);
>>>> return -EINVAL;
>>>> }
>>>>
>>>> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
>>>> index 58f431102512..932724784942 100644
>>>> --- a/drivers/gpu/drm/sti/sti_hdmi.c
>>>> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
>>>> @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data)
>>>> return 0;
>>>>
>>>> err_sysfs:
>>>> - drm_bridge_remove(bridge);
>>>> hdmi->drm_connector = NULL;
>>>> return -EINVAL;
>>>> }
>>>> --
>>>> 2.11.0
>>>>
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* [PATCH 8/8] ARM: dts: r8a7745: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A7
CPU cores on RZ/G1E by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7745.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 3de69cb66c44a7f8..1cb7a7ab0418f29d 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -105,6 +105,13 @@
clock-frequency = <0>;
};
+ pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts-extended = <&gic GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 7/8] ARM: dts: r8a7743: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A15
CPU cores on RZ/G1M by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7743.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 69d8f7e0f0536fc0..142949d7066f3a65 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -125,6 +125,13 @@
clock-frequency = <0>;
};
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 6/8] ARM: dts: r8a7794: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A7
CPU cores on R-Car E2 by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7794.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 76aadcdf9d37b39c..736196903d22f0e0 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -103,6 +103,13 @@
clock-frequency = <0>;
};
+ pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts-extended = <&gic GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 5/8] ARM: dts: r8a7793: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A15
CPU cores on R-Car M2-N by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7793.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 2fa052200495caef..4abecfc0ca98c483 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -110,6 +110,13 @@
clock-frequency = <0>;
};
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 4/8] ARM: dts: r8a7792: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A15
CPU cores on R-Car V2H by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7792.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index d2cf8dd2d9b03624..f44257dd86f66289 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -85,6 +85,13 @@
clock-frequency = <0>;
};
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 3/8] ARM: dts: r8a7791: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A15
CPU cores on R-Car M2-W by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7791.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 58f694eb411b0e3d..6e1dd7ad7bd647e7 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -126,6 +126,13 @@
clock-frequency = <0>;
};
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 2/8] ARM: dts: r8a7790: Add PMU device nodes
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A15
and Cortex-A7 CPU cores on R-Car H2 by adding device nodes for the two
PMUs.
New Linux output:
hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
hw perfevents: /pmu-1: failed to probe PMU!
hw perfevents: /pmu-1: failed to register PMU devices!
The last two lines are due to the Cortex-A7 CPU cores being described in
DT, but not enabled by the firmware.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7790.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 47a51cd71434e7d2..4d06b154bd7ebd9e 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -202,6 +202,24 @@
clock-frequency = <0>;
};
+ pmu-0 {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+ };
+
+ pmu-1 {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts-extended = <&gic GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
+ };
+
/* External SCIF clock */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 1/8] ARM: dts: r7s72100: Add PMU device node
From: Geert Uytterhoeven @ 2018-05-07 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525701427-12914-1-git-send-email-geert+renesas@glider.be>
Enable support for the ARM Performance Monitor Units in the Cortex-A9
CPU core on RZ/A1H by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r7s72100.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index eb2e6f95a2e85862..a54822e97bac42ed 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -77,6 +77,11 @@
clock-div = <6>;
};
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts-extended = <&gic GIC_PPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
rtc_x1_clk: rtc_x1 {
#clock-cells = <0>;
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH 0/8] ARM: dts: renesas: Add PMU device nodes
From: Geert Uytterhoeven @ 2018-05-07 13:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
This patch series enables support for the ARM Performance Monitor Units
in Cortex-A7, Cortex-A9, and Cortex-A15 CPU cores on Renesas RZ/A1,
R-Car Gen2, and RZ/G1 SoCs. This allows for better performance analysis
using the "perf" tool.
Sample output of "perf stat echo" on r8a7791/koelsch:
- Before:
Performance counter stats for 'echo':
2,636300 task-clock (msec) # 0,265 CPUs utilized
8 context-switches # 0,003 M/sec
0 cpu-migrations # 0,000 K/sec
43 page-faults # 0,016 M/sec
<not supported> cycles
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
<not supported> instructions
<not supported> branches
<not supported> branch-misses
0,009960300 seconds time elapsed
- After:
Performance counter stats for 'echo':
2,455400 task-clock (msec) # 0,273 CPUs utilized
3 context-switches # 0,001 M/sec
0 cpu-migrations # 0,000 K/sec
45 page-faults # 0,018 M/sec
3.556.784 cycles # 1,449 GHz
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
1.350.480 instructions # 0,38 insns per cycle
335.542 branches # 136,655 M/sec
18.075 branch-misses # 5,39% of all branches
0,008987900 seconds time elapsed
Still missing:
- R-Mobile APE6 (no PMU interrupt documented),
- R-Car M1A and H1 (the PMU interrupt seems to be routed to the legacy
SH INTC only?),
- RZ/G1C (SMP support not yet upstream).
This has been tested on r8a7791/koelsch, and boot-tested on
r7s72100/genmai, r8a7790/lager, r8a7792/blanche, and r8a7794/silk.
Thanks!
Geert Uytterhoeven (8):
ARM: dts: r7s72100: Add PMU device node
ARM: dts: r8a7790: Add PMU device nodes
ARM: dts: r8a7791: Add PMU device node
ARM: dts: r8a7792: Add PMU device node
ARM: dts: r8a7793: Add PMU device node
ARM: dts: r8a7794: Add PMU device node
ARM: dts: r8a7743: Add PMU device node
ARM: dts: r8a7745: Add PMU device node
arch/arm/boot/dts/r7s72100.dtsi | 5 +++++
arch/arm/boot/dts/r8a7743.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7745.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7790.dtsi | 18 ++++++++++++++++++
arch/arm/boot/dts/r8a7791.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7792.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7793.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7794.dtsi | 7 +++++++
8 files changed, 65 insertions(+)
--
2.7.4
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 v2 00/26] device link, bridge supplier <-> drm device
From: Daniel Vetter @ 2018-05-07 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135212.26977-1-peda@axentia.se>
On Fri, May 04, 2018 at 03:51:46PM +0200, Peter Rosin wrote:
> Hi!
>
> It was noted by Russel King [1] that bridges (not using components)
> might disappear unexpectedly if the owner of the bridge was unbound.
> Jyri Sarha had previously noted the same thing with panels [2]. Jyri
> came up with using device links to resolve the panel issue, which
> was also my (independent) reaction to the note from Russel.
>
> This series builds up to the addition of that link in the last
> patch, but in my opinion the other 25 patches do have merit on their
> own.
>
> The last patch needs testing, while the others look trivial. Jyri, are
> you able to test? That said, I might have missed some subtlety.
>
> Oh and the reason I'm pushing this is of course so that the issue
> noted by Russel in [1] is addressed which in turn means that the
> tda998x bridge driver can be patched according to that series without
> objection (hopefully) and then used from the atmel-hlcdc driver (and
> other drivers that are not componentized).
>
> Changes since v1 https://lkml.org/lkml/2018/4/26/1018
>
> - rename .owner to .odev to not get mixed up with the module owner.
> - added patches for new recent drivers thc63lvd1024 and cdns-dsi
> - fix for problem in the rockchip_lvds driver reported by 0day
> - added a WARN in drm_bridge_add if there is no .odev owner device
>
> I did *not*:
> - add any ack from Daniel since he suggested "pdev", and I ended up
> with "odev" in the rename since I disliked "pdev" about as much
> as "owner".
As long as it's not owner, I'm fine :-) Ack on the idea still holds.
> - add any port id. The current .of_node (that this series removes)
> does not identify the port, so that problem seems orthogonal
> to me.
Hm, from my cursory DT/of code reading last week I thought the port is
used to lookup the right node, but there's no port thing on the target for
a phandle? At least that's how current drm_of_find_panel_or_bridge seems
to work ...
-Daniel
>
> Cheers,
> Peter
>
> [1] https://lkml.org/lkml/2018/4/23/769
> [2] https://www.spinics.net/lists/dri-devel/msg174275.html
>
> Peter Rosin (26):
> drm/bridge: allow optionally specifying an owner .odev device
> drm/bridge: adv7511: provide an owner .odev device
> drm/bridge/analogix: core: specify the owner .odev of the bridge
> drm/bridge: analogix-anx78xx: provide an owner .odev device
> drm/bridge: cdns-dsi: provide an owner .odev device
> drm/bridge: vga-dac: provide an owner .odev device
> drm/bridge: lvds-encoder: provide an owner .odev device
> drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: provide an owner .odev
> device
> drm/bridge: nxp-ptn3460: provide an owner .odev device
> drm/bridge: panel: provide an owner .odev device
> drm/bridge: ps8622: provide an owner .odev device
> drm/bridge: sii902x: provide an owner .odev device
> drm/bridge: sii9234: provide an owner .odev device
> drm/bridge: sii8620: provide an owner .odev device
> drm/bridge: synopsys: provide an owner .odev device for the bridges
> drm/bridge: tc358767: provide an owner .odev device
> drm/bridge: thc63lvd1024: provide an owner .odev device
> drm/bridge: ti-tfp410: provide an owner .odev device
> drm/exynos: mic: provide an owner .odev device for the bridge
> drm/mediatek: hdmi: provide an owner .odev device for the bridge
> drm/msm: specify the owner .odev of the bridges
> drm/rcar-du: lvds: provide an owner .odev device for the bridge
> drm/sti: provide an owner .odev device for the bridges
> drm/bridge: remove the .of_node member
> drm/bridge: require the owner .odev to be filled in on
> drm_bridge_add/attach
> drm/bridge: establish a link between the bridge supplier and consumer
>
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 +----
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
> drivers/gpu/drm/bridge/cdns-dsi.c | 2 +-
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +-
> drivers/gpu/drm/bridge/lvds-encoder.c | 2 +-
> .../drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c | 2 +-
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
> drivers/gpu/drm/bridge/panel.c | 4 +---
> drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/sii9234.c | 2 +-
> drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
> drivers/gpu/drm/bridge/tc358767.c | 2 +-
> drivers/gpu/drm/bridge/thc63lvd1024.c | 2 +-
> drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
> drivers/gpu/drm/drm_bridge.c | 26 +++++++++++++++++++++-
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> drivers/gpu/drm/msm/dsi/dsi_manager.c | 1 +
> drivers/gpu/drm/msm/edp/edp_bridge.c | 1 +
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +-
> drivers/gpu/drm/sti/sti_dvo.c | 2 +-
> drivers/gpu/drm/sti/sti_hda.c | 1 +
> drivers/gpu/drm/sti/sti_hdmi.c | 1 +
> include/drm/drm_bridge.h | 8 +++----
> 30 files changed, 57 insertions(+), 36 deletions(-)
>
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Daniel Vetter @ 2018-05-07 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4cdcd215-8caf-e045-a478-f438f128c9f2@samsung.com>
On Mon, May 07, 2018 at 02:59:45PM +0200, Andrzej Hajda wrote:
> On 04.05.2018 15:52, Peter Rosin wrote:
> > If the bridge supplier is unbound, this will bring the bridge consumer
> > down along with the bridge. Thus, there will no longer linger any
> > dangling pointers from the bridge consumer (the drm_device) to some
> > non-existent bridge supplier.
>
> I understand rationales behind this patch, but it is another step into
> making drm_dev one big driver with subcomponents, where drm will work
> only if every subcomponent is working/loaded. Do we need to go this way?
> In case of many platforms such approach results in display turned on
> very late on boot for example due to late initialization of some
> regulator exposed by some i2c device, which is used by hdmi bridge. And
> this hdmi bridge is just to provide alternative(rarely used) display
> path, the main display path would work anyway.
>
> So the main question to drm maintainers is about evolution of bridges,
> if drm_bridges should become mandatory components of drm device or they
> could be added/removed dynamically?
This is already the case. You currently cannot hotplug a drm_bridge,
everything must be present. I don't think it makes sense to change that
until we have physically hotpluggable drm_bridges in real hardware. I
definitely don't want to refcount stuff to work around driver load
bonghits on DT platforms, because refcounting is way too hard to get right
:-)
Afaik there's out-of-tree patches to solve 99% of the driver load fun on
DT platforms, but because it's not a 100% solution it's blocked since
forever.
-Daniel
>
> Regards
> Andrzej
>
>
> >
> > Signed-off-by: Peter Rosin <peda@axentia.se>
> > ---
> > drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
> > include/drm/drm_bridge.h | 2 ++
> > 2 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 78d186b6831b..0259f0a3ff27 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -26,6 +26,7 @@
> > #include <linux/mutex.h>
> >
> > #include <drm/drm_bridge.h>
> > +#include <drm/drm_device.h>
> > #include <drm/drm_encoder.h>
> >
> > #include "drm_crtc_internal.h"
> > @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> > if (bridge->dev)
> > return -EBUSY;
> >
> > + if (encoder->dev->dev != bridge->odev) {
> > + bridge->link = device_link_add(encoder->dev->dev,
> > + bridge->odev, 0);
> > + if (!bridge->link) {
> > + dev_err(bridge->odev, "failed to link bridge to %s\n",
> > + dev_name(encoder->dev->dev));
> > + return -EINVAL;
> > + }
> > + }
> > +
> > bridge->dev = encoder->dev;
> > bridge->encoder = encoder;
> >
> > if (bridge->funcs->attach) {
> > ret = bridge->funcs->attach(bridge);
> > if (ret < 0) {
> > + if (bridge->link)
> > + device_link_del(bridge->link);
> > + bridge->link = NULL;
> > bridge->dev = NULL;
> > bridge->encoder = NULL;
> > return ret;
> > @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> > if (bridge->funcs->detach)
> > bridge->funcs->detach(bridge);
> >
> > + if (bridge->link)
> > + device_link_del(bridge->link);
> > + bridge->link = NULL;
> > +
> > bridge->dev = NULL;
> > }
> >
> > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > index b656e505d11e..804189c63a4c 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> > * @list: to keep track of all added bridges
> > * @timings: the timing specification for the bridge, if any (may
> > * be NULL)
> > + * @link: drm consumer <-> bridge supplier
> > * @funcs: control functions
> > * @driver_private: pointer to the bridge driver's internal context
> > */
> > @@ -271,6 +272,7 @@ struct drm_bridge {
> > struct drm_bridge *next;
> > struct list_head list;
> > const struct drm_bridge_timings *timings;
> > + struct device_link *link;
> >
> > const struct drm_bridge_funcs *funcs;
> > void *driver_private;
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH] ARM: dts: imx51-zii-rdu1: fix touchscreen bindings
From: Nikita Yushchenko @ 2018-05-07 13:53 UTC (permalink / raw)
To: linux-arm-kernel
This fixes errors in RDU1 device tree that cause touch screens not
working.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index 0c99ac04ad08..6464f2560e06 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -523,7 +523,7 @@
};
touchscreen at 20 {
- compatible = "syna,rmi4_i2c";
+ compatible = "syna,rmi4-i2c";
reg = <0x20>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ts>;
@@ -541,8 +541,8 @@
rmi4-f11 at 11 {
reg = <0x11>;
- touch-inverted-y;
- touch-swapped-x-y;
+ touchscreen-inverted-y;
+ touchscreen-swapped-x-y;
syna,sensor-type = <1>;
};
};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 08/14] media: v4l: Add definitions for MPEG2 frame format and header metadata
From: Paul Kocialkowski @ 2018-05-07 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1bd7af5a-c8d5-220c-8471-545eb1835882@xs4all.nl>
Hi Hans,
On Mon, 2018-05-07 at 15:49 +0200, Hans Verkuil wrote:
> On 07/05/18 14:44, Paul Kocialkowski wrote:
> > From: Florent Revest <florent.revest@free-electrons.com>
> >
> > Stateless video decoding engines require both the MPEG slices and
> > associated metadata from the video stream in order to decode frames.
> >
> > This introduces definitions for a new pixel format, describing
> > buffers
> > with MPEG2 slice data, as well as a control structure for passing
> > the
> > frame header (metadata) to drivers.
Thanks for the review!
I should have made it clear that this patch has not seen any improvement
between v2 and v3. Cleaning up and documenting the MPEG2 headers is
still in the tasks list (presented in the cover letter), as well as the
MB32 NV12 format.
> > Signed-off-by: Florent Revest <florent.revest@free-electrons.com>
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > ---
> > drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++++++++++
> > drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> > include/uapi/linux/v4l2-controls.h | 26
> > ++++++++++++++++++++++++++
> > include/uapi/linux/videodev2.h | 3 +++
> > 4 files changed, 40 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index df58a23eb731..cdf860c8e3d8 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -826,6 +826,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
> > return "Vertical MV Search Range";
> > case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER:
> > return "Repeat Sequence Header";
> > case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME: re
> > turn "Force Key Frame";
> > + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR: re
> > turn "MPEG2 Frame Header";
>
> This compound control needs to be documented in the V4l2 spec.
>
> >
> > /* VPX controls */
> > case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:
> > return "VPX Number of Partitions";
> > @@ -1271,6 +1272,9 @@ void v4l2_ctrl_fill(u32 id, const char **name,
> > enum v4l2_ctrl_type *type,
> > case V4L2_CID_RDS_TX_ALT_FREQS:
> > *type = V4L2_CTRL_TYPE_U32;
> > break;
> > + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> > + *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> > + break;
> > default:
> > *type = V4L2_CTRL_TYPE_INTEGER;
> > break;
> > @@ -1591,6 +1595,9 @@ static int std_validate(const struct v4l2_ctrl
> > *ctrl, u32 idx,
> > return -ERANGE;
> > return 0;
> >
> > + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> > + return 0;
> > +
> > default:
> > return -EINVAL;
> > }
> > @@ -2165,6 +2172,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> > v4l2_ctrl_handler *hdl,
> > case V4L2_CTRL_TYPE_U32:
> > elem_size = sizeof(u32);
> > break;
> > + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> > + elem_size = sizeof(struct
> > v4l2_ctrl_mpeg2_frame_hdr);
> > + break;
> > default:
> > if (type < V4L2_CTRL_COMPOUND_TYPES)
> > elem_size = sizeof(s32);
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 561a1fe3160b..38d318c47c55 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1274,6 +1274,7 @@ static void v4l_fill_fmtdesc(struct
> > v4l2_fmtdesc *fmt)
> > case V4L2_PIX_FMT_VP8: descr =
> > "VP8"; break;
> > case V4L2_PIX_FMT_VP9: descr =
> > "VP9"; break;
> > case V4L2_PIX_FMT_HEVC: descr =
> > "HEVC"; break; /* aka H.265 */
> > + case V4L2_PIX_FMT_MPEG2_FRAME: descr =
> > "MPEG2 Frame"; break;
>
> Needs to be documented in the spec.
>
> > case V4L2_PIX_FMT_CPIA1: descr = "GSPCA CPiA
> > YUV"; break;
> > case V4L2_PIX_FMT_WNVA: descr =
> > "WNVA"; break;
> > case V4L2_PIX_FMT_SN9C10X: descr = "GSPCA
> > SN9C10X"; break;
> > diff --git a/include/uapi/linux/v4l2-controls.h
> > b/include/uapi/linux/v4l2-controls.h
> > index 8d473c979b61..23da8bfa7e6f 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -557,6 +557,8 @@ enum v4l2_mpeg_video_mpeg4_profile {
> > };
> > #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL (V4L2_CID_MPE
> > G_BASE+407)
> >
> > +#define
> > V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR (V4L2_CID_MPEG_BASE+450)
> > +
> > /* Control IDs for VP8 streams
> > * Although VP8 is not part of MPEG we add these controls to the
> > MPEG class
> > * as that class is already handling other video compression
> > standards
> > @@ -1076,4 +1078,28 @@ enum v4l2_detect_md_mode {
> > #define V4L2_CID_DETECT_MD_THRESHOLD_GRID (V4L2_CID_DETECT_C
> > LASS_BASE + 3)
> > #define V4L2_CID_DETECT_MD_REGION_GRID (V4L2_CID_DET
> > ECT_CLASS_BASE + 4)
> >
> > +struct v4l2_ctrl_mpeg2_frame_hdr {
> > + __u32 slice_len;
> > + __u32 slice_pos;
> > + enum { MPEG1, MPEG2 } type;
>
> Still an enum?
>
> > +
> > + __u16 width;
> > + __u16 height;
> > +
> > + enum { PCT_I = 1, PCT_P, PCT_B, PCT_D }
> > picture_coding_type;
> > + __u8 f_code[2][2];
> > +
> > + __u8 intra_dc_precision;
> > + __u8 picture_structure;
> > + __u8 top_field_first;
> > + __u8 frame_pred_frame_dct;
> > + __u8 concealment_motion_vectors;
> > + __u8 q_scale_type;
> > + __u8 intra_vlc_format;
> > + __u8 alternate_scan;
> > +
> > + __u8 backward_ref_index;
> > + __u8 forward_ref_index;
> > +};
> > +
> > #endif
> > diff --git a/include/uapi/linux/videodev2.h
> > b/include/uapi/linux/videodev2.h
> > index 1f6c4b52baae..d8f9b59d90d7 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -636,6 +636,7 @@ struct v4l2_pix_format {
> > #define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /*
> > VP8 */
> > #define V4L2_PIX_FMT_VP9 v4l2_fourcc('V', 'P', '9', '0') /*
> > VP9 */
> > #define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /*
> > HEVC aka H.265 */
> > +#define V4L2_PIX_FMT_MPEG2_FRAME v4l2_fourcc('M', 'G', '2', 'F') /*
> > MPEG2 frame */
> >
> > /* Vendor-specific formats */
> > #define V4L2_PIX_FMT_CPIA1 v4l2_fourcc('C', 'P', 'I', 'A') /*
> > cpia1 YUV */
> > @@ -1587,6 +1588,7 @@ struct v4l2_ext_control {
> > __u8 __user *p_u8;
> > __u16 __user *p_u16;
> > __u32 __user *p_u32;
> > + struct v4l2_ctrl_mpeg2_frame_hdr __user
> > *p_mpeg2_frame_hdr;
> > void __user *ptr;
> > };
> > } __attribute__ ((packed));
> > @@ -1632,6 +1634,7 @@ enum v4l2_ctrl_type {
> > V4L2_CTRL_TYPE_U8 = 0x0100,
> > V4L2_CTRL_TYPE_U16 = 0x0101,
> > V4L2_CTRL_TYPE_U32 = 0x0102,
> > + V4L2_CTRL_TYPE_MPEG2_FRAME_HDR = 0x0109,
> > };
> >
> > /* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
> >
>
> Regards,
>
> Hans
--
Paul Kocialkowski, 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: 484 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180507/c9681c49/attachment.sig>
^ permalink raw reply
* [PATCH v3 09/14] media: v4l: Add definition for Allwinner's MB32-tiled NV12 format
From: Hans Verkuil @ 2018-05-07 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507124500.20434-10-paul.kocialkowski@bootlin.com>
On 07/05/18 14:44, Paul Kocialkowski wrote:
> This introduces support for Allwinner's MB32-tiled NV12 format, where
> each plane is divided into macroblocks of 32x32 pixels. Hence, the size
> of each plane has to be aligned to 32 bytes. The pixels inside each
> macroblock are coded as they would be if the macroblock was a single
> plane, line after line.
>
> The MB32-tiled NV12 format is used by the video engine on Allwinner
> platforms: it is the default format for decoded frames (and the only one
> available in the oldest supported platforms).
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
> include/uapi/linux/videodev2.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index d8f9b59d90d7..242a6bfa1440 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -670,6 +670,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_Z16 v4l2_fourcc('Z', '1', '6', ' ') /* Depth data 16-bit */
> #define V4L2_PIX_FMT_MT21C v4l2_fourcc('M', 'T', '2', '1') /* Mediatek compressed block mode */
> #define V4L2_PIX_FMT_INZI v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel Planar Greyscale 10-bit and Depth 16-bit */
> +#define V4L2_PIX_FMT_MB32_NV12 v4l2_fourcc('M', 'N', '1', '2') /* Allwinner NV12 in 32x32 macroblocks */
Must be documented in the spec as well.
Regards,
Hans
>
> /* 10bit raw bayer packed, 32 bytes for every 25 pixels, last LSB 6 bits unused */
> #define V4L2_PIX_FMT_IPU3_SBGGR10 v4l2_fourcc('i', 'p', '3', 'b') /* IPU3 packed 10-bit BGGR bayer */
>
^ permalink raw reply
* [PATCH v3 08/14] media: v4l: Add definitions for MPEG2 frame format and header metadata
From: Hans Verkuil @ 2018-05-07 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507124500.20434-9-paul.kocialkowski@bootlin.com>
On 07/05/18 14:44, Paul Kocialkowski wrote:
> From: Florent Revest <florent.revest@free-electrons.com>
>
> Stateless video decoding engines require both the MPEG slices and
> associated metadata from the video stream in order to decode frames.
>
> This introduces definitions for a new pixel format, describing buffers
> with MPEG2 slice data, as well as a control structure for passing the
> frame header (metadata) to drivers.
>
> Signed-off-by: Florent Revest <florent.revest@free-electrons.com>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++++++++++
> drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> include/uapi/linux/v4l2-controls.h | 26 ++++++++++++++++++++++++++
> include/uapi/linux/videodev2.h | 3 +++
> 4 files changed, 40 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index df58a23eb731..cdf860c8e3d8 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -826,6 +826,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return "Vertical MV Search Range";
> case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat Sequence Header";
> case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME: return "Force Key Frame";
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR: return "MPEG2 Frame Header";
This compound control needs to be documented in the V4l2 spec.
>
> /* VPX controls */
> case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS: return "VPX Number of Partitions";
> @@ -1271,6 +1272,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> case V4L2_CID_RDS_TX_ALT_FREQS:
> *type = V4L2_CTRL_TYPE_U32;
> break;
> + case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
> + *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
> + break;
> default:
> *type = V4L2_CTRL_TYPE_INTEGER;
> break;
> @@ -1591,6 +1595,9 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32 idx,
> return -ERANGE;
> return 0;
>
> + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> + return 0;
> +
> default:
> return -EINVAL;
> }
> @@ -2165,6 +2172,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
> case V4L2_CTRL_TYPE_U32:
> elem_size = sizeof(u32);
> break;
> + case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
> + elem_size = sizeof(struct v4l2_ctrl_mpeg2_frame_hdr);
> + break;
> default:
> if (type < V4L2_CTRL_COMPOUND_TYPES)
> elem_size = sizeof(s32);
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 561a1fe3160b..38d318c47c55 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1274,6 +1274,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_PIX_FMT_VP8: descr = "VP8"; break;
> case V4L2_PIX_FMT_VP9: descr = "VP9"; break;
> case V4L2_PIX_FMT_HEVC: descr = "HEVC"; break; /* aka H.265 */
> + case V4L2_PIX_FMT_MPEG2_FRAME: descr = "MPEG2 Frame"; break;
Needs to be documented in the spec.
> case V4L2_PIX_FMT_CPIA1: descr = "GSPCA CPiA YUV"; break;
> case V4L2_PIX_FMT_WNVA: descr = "WNVA"; break;
> case V4L2_PIX_FMT_SN9C10X: descr = "GSPCA SN9C10X"; break;
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 8d473c979b61..23da8bfa7e6f 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -557,6 +557,8 @@ enum v4l2_mpeg_video_mpeg4_profile {
> };
> #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL (V4L2_CID_MPEG_BASE+407)
>
> +#define V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR (V4L2_CID_MPEG_BASE+450)
> +
> /* Control IDs for VP8 streams
> * Although VP8 is not part of MPEG we add these controls to the MPEG class
> * as that class is already handling other video compression standards
> @@ -1076,4 +1078,28 @@ enum v4l2_detect_md_mode {
> #define V4L2_CID_DETECT_MD_THRESHOLD_GRID (V4L2_CID_DETECT_CLASS_BASE + 3)
> #define V4L2_CID_DETECT_MD_REGION_GRID (V4L2_CID_DETECT_CLASS_BASE + 4)
>
> +struct v4l2_ctrl_mpeg2_frame_hdr {
> + __u32 slice_len;
> + __u32 slice_pos;
> + enum { MPEG1, MPEG2 } type;
Still an enum?
> +
> + __u16 width;
> + __u16 height;
> +
> + enum { PCT_I = 1, PCT_P, PCT_B, PCT_D } picture_coding_type;
> + __u8 f_code[2][2];
> +
> + __u8 intra_dc_precision;
> + __u8 picture_structure;
> + __u8 top_field_first;
> + __u8 frame_pred_frame_dct;
> + __u8 concealment_motion_vectors;
> + __u8 q_scale_type;
> + __u8 intra_vlc_format;
> + __u8 alternate_scan;
> +
> + __u8 backward_ref_index;
> + __u8 forward_ref_index;
> +};
> +
> #endif
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 1f6c4b52baae..d8f9b59d90d7 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -636,6 +636,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
> #define V4L2_PIX_FMT_VP9 v4l2_fourcc('V', 'P', '9', '0') /* VP9 */
> #define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /* HEVC aka H.265 */
> +#define V4L2_PIX_FMT_MPEG2_FRAME v4l2_fourcc('M', 'G', '2', 'F') /* MPEG2 frame */
>
> /* Vendor-specific formats */
> #define V4L2_PIX_FMT_CPIA1 v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
> @@ -1587,6 +1588,7 @@ struct v4l2_ext_control {
> __u8 __user *p_u8;
> __u16 __user *p_u16;
> __u32 __user *p_u32;
> + struct v4l2_ctrl_mpeg2_frame_hdr __user *p_mpeg2_frame_hdr;
> void __user *ptr;
> };
> } __attribute__ ((packed));
> @@ -1632,6 +1634,7 @@ enum v4l2_ctrl_type {
> V4L2_CTRL_TYPE_U8 = 0x0100,
> V4L2_CTRL_TYPE_U16 = 0x0101,
> V4L2_CTRL_TYPE_U32 = 0x0102,
> + V4L2_CTRL_TYPE_MPEG2_FRAME_HDR = 0x0109,
> };
>
> /* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
>
Regards,
Hans
^ permalink raw reply
* [PATCH 00/13] drm/kms/mode: using helper func drm_display_mode_to/from_videomode for calculating timing parameters
From: Daniel Vetter @ 2018-05-07 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1525087679.git.satendra.t@samsung.com>
On Thu, May 03, 2018 at 01:53:55PM +0530, Satendra Singh Thakur wrote:
> 1.There is a function in drm-core to calculate display timing parameters:
> horizontal front porch, back porch, sync length,
> vertical front porch, back porch, sync length and
> clock in Hz.
> However, some drivers are still calculating these parameters themselves.
> Therefore, there is a duplication of the code.
> This patch series replaces this redundant code with the function
> drm_display_mode_to_videomode.
> This removes nearly 100 redundant lines from the related drivers.
> 2.For some drivers (sun4i) the reverse helper
> drm_display_mode_from_videomode is used.
> 3.For some drivers it replaces arithmatic operators (*, /) with shifting
> operators (>>, <<).
> 4.For some drivers DRM_MODE_FLAG_* are replaced with DISPLAY_FLAGS_* flags.
> 5.These changes apply to following crtc and encoder drivers:
> atmel-hlcdc
> bridge-tc358767
> exynos-dsi
> fsl-dcu
> gma500-mdfld_dsi_dpi
> hisilicon-kirin_dsi, ade
> meson-encoder
> pl111-display
> sun4i-tv
> ti lcdc
> tegra dc
> mediatek dpi dsi
> bridge-adv7533
The drm_mode_to_videomode helper is meant for interop between drm and v4l,
which have different internal structures to represent modes.
For drivers that only use drm I think the better option would be to add
these fields to struct drm_display_mode as another set of crtc_* values
(the computed values are stored in crtc_ prefixed members). And compute
front/back porch in drm_mode_set_crtcinfo.
Then we can use these new drm_display_mode->crtc_h|vfront|back_porch
fields in all the drivers you're changing. This way you avoid having to
change all the drm drivers to use v4l #defines.
Thanks,
Daniel
>
> Satendra Singh Thakur (13):
> drm/kms/mode/atmel-hlcdc: using helper func
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/bridge-tc358767: using helper func
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/exynos-dsi: using helper func
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/fsl-dcu: using helper func drm_display_mode_to_videomode
> for calculating timing parameters
> drm/kms/mode/gma500-mdfld_dsi_dpi: using helper function
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/hisilicon-kirin-dsi-ade: using helper function
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/meson-encoder: using helper function
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/pl111-display: using helper function
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/sun4i-tv: using helper func
> drm_display_mode_from_videomode for calculating timing
> parameters
> drm/kms/mode/ti-lcdc: using helper func drm_display_mode_to_videomode
> for calculating timing parameters
> drm/kms/mode/tegra: using helper func drm_display_mode_to_videomode
> for calculating timing parameters
> drm/kms/mode/mtk_dpi_dsi: using helper func
> drm_display_mode_to_videomode for calculating timing parameters
> drm/kms/mode/bridge-adv7533: using helper func
> drm_display_mode_to_videomode for calculating timing parameters
>
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 28 +++--
> drivers/gpu/drm/bridge/adv7511/adv7533.c | 35 +++---
> drivers/gpu/drm/bridge/tc358767.c | 42 +++----
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 29 ++---
> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 28 ++---
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 42 ++++---
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 52 +++------
> drivers/gpu/drm/mediatek/mtk_dpi.c | 60 +++++-----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +--
> drivers/gpu/drm/meson/meson_venc.c | 149 +++++++++++-------------
> drivers/gpu/drm/pl111/pl111_display.c | 40 +++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 67 ++++-------
> drivers/gpu/drm/tegra/dc.c | 15 ++-
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 60 +++++-----
> 15 files changed, 280 insertions(+), 390 deletions(-)
>
> --
> 2.7.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Peter Rosin @ 2018-05-07 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4cdcd215-8caf-e045-a478-f438f128c9f2@samsung.com>
On 2018-05-07 14:59, Andrzej Hajda wrote:
> On 04.05.2018 15:52, Peter Rosin wrote:
>> If the bridge supplier is unbound, this will bring the bridge consumer
>> down along with the bridge. Thus, there will no longer linger any
>> dangling pointers from the bridge consumer (the drm_device) to some
>> non-existent bridge supplier.
>
> I understand rationales behind this patch, but it is another step into
> making drm_dev one big driver with subcomponents, where drm will work
> only if every subcomponent is working/loaded.
The step is very small IMHO. Just a device-link, which is very easy to
remove once whatever other solution is ready.
> Do we need to go this way?
If the drivers expect the parts to be there, and there is no other safety
net in place if they are not, what is the (short-term) alternative?
> In case of many platforms such approach results in display turned on
> very late on boot for example due to late initialization of some
> regulator exposed by some i2c device, which is used by hdmi bridge. And
> this hdmi bridge is just to provide alternative(rarely used) display
> path, the main display path would work anyway.
This patch does not contribute to any late init and any such delay is not
affected by this. At all.
> So the main question to drm maintainers is about evolution of bridges,
> if drm_bridges should become mandatory components of drm device or they
> could be added/removed dynamically?
That is a much bigger question than this patch/series. Conflating the
two is not fair IMHO. You could run this very same argument for every
driver that gets added, since any additional driver will just make it
harder to make everything dynamic. Should we stop development right
away?
Besides, as long as the drm devices are in fact acting as big static
drivers (built from smaller parts), this should be considered a bug-fix
that will prevent dereference of stale pointers.
Or will some other solution appear and magically make all bridges and
drm drivers capable of dynamic reconfiguration in the next few weeks?
Yeah, right...
Cheers,
Peter
> Regards
> Andrzej
>
>
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
>> include/drm/drm_bridge.h | 2 ++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 78d186b6831b..0259f0a3ff27 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -26,6 +26,7 @@
>> #include <linux/mutex.h>
>>
>> #include <drm/drm_bridge.h>
>> +#include <drm/drm_device.h>
>> #include <drm/drm_encoder.h>
>>
>> #include "drm_crtc_internal.h"
>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
>> if (bridge->dev)
>> return -EBUSY;
>>
>> + if (encoder->dev->dev != bridge->odev) {
>> + bridge->link = device_link_add(encoder->dev->dev,
>> + bridge->odev, 0);
>> + if (!bridge->link) {
>> + dev_err(bridge->odev, "failed to link bridge to %s\n",
>> + dev_name(encoder->dev->dev));
>> + return -EINVAL;
>> + }
>> + }
>> +
>> bridge->dev = encoder->dev;
>> bridge->encoder = encoder;
>>
>> if (bridge->funcs->attach) {
>> ret = bridge->funcs->attach(bridge);
>> if (ret < 0) {
>> + if (bridge->link)
>> + device_link_del(bridge->link);
>> + bridge->link = NULL;
>> bridge->dev = NULL;
>> bridge->encoder = NULL;
>> return ret;
>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>> if (bridge->funcs->detach)
>> bridge->funcs->detach(bridge);
>>
>> + if (bridge->link)
>> + device_link_del(bridge->link);
>> + bridge->link = NULL;
>> +
>> bridge->dev = NULL;
>> }
>>
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index b656e505d11e..804189c63a4c 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>> * @list: to keep track of all added bridges
>> * @timings: the timing specification for the bridge, if any (may
>> * be NULL)
>> + * @link: drm consumer <-> bridge supplier
>> * @funcs: control functions
>> * @driver_private: pointer to the bridge driver's internal context
>> */
>> @@ -271,6 +272,7 @@ struct drm_bridge {
>> struct drm_bridge *next;
>> struct list_head list;
>> const struct drm_bridge_timings *timings;
>> + struct device_link *link;
>>
>> const struct drm_bridge_funcs *funcs;
>> void *driver_private;
>
>
^ permalink raw reply
* [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
From: Daniel Vetter @ 2018-05-07 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd8d12f7-0c71-c96b-80fa-54de7de39511@axentia.se>
On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> On 2018-05-03 11:06, Daniel Vetter wrote:
> > On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> >> The more natural approach would perhaps be to add an drm_bridge_add,
> >> but there are several other bridges that never call drm_bridge_add.
> >> Just removing the drm_bridge_remove is the easier fix.
> >>
> >> Signed-off-by: Peter Rosin <peda@axentia.se>
> >
> > This mess is much bigger. There's 2 pairs of bridge functions:
> >
> > - drm_bridge_attach/detach. Those are meant to be called by the overall
> > drm driver to connect/disconnect a drm_bridge.
> >
> > - drm_bridge_add/remove. These are supposed to be called by the bridge
> > driver itself to register/unregister itself. Maybe we should rename
> > them, since the same issue happens with drm_panel, with the same
> > confusion.
> >
> > I thought someone was working on a cleanup series to fix this mess, but I
> > didn't find anything.
>
> Ok, I just spotted the imbalance and didn't really dig into what
> actually happens in these error paths. Now that I have done so I
> believe that the removed drm_bridge_remove calls causes NULL
> dereferences if/when the error paths are triggered.
>
> So, I don't think this can wait for some bigger cleanup.
>
> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> __list_del with NULL in both prev and next since the list member
> is never initialized. prev and next are dereferenced by __list_del
> and you have *boom*
>
> I recommend adding the tag
>
> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
>
> so that stable picks this one up.
I just wanted to correct your commit message text - the correct solution
is definitely _not_ for sti here to call drm_bridge_add. It should call
drm_bridge_attach/detach only, as a pair.
I didn't check whether you instead have a _detach call missing or what's
going on here.
-Daniel
>
> Cheers,
> Peter
>
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/sti/sti_hda.c | 1 -
> >> drivers/gpu/drm/sti/sti_hdmi.c | 1 -
> >> 2 files changed, 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> >> index 67bbdb49fffc..199db13f565c 100644
> >> --- a/drivers/gpu/drm/sti/sti_hda.c
> >> +++ b/drivers/gpu/drm/sti/sti_hda.c
> >> @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device *master, void *data)
> >> return 0;
> >>
> >> err_sysfs:
> >> - drm_bridge_remove(bridge);
> >> return -EINVAL;
> >> }
> >>
> >> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> >> index 58f431102512..932724784942 100644
> >> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> >> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> >> @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data)
> >> return 0;
> >>
> >> err_sysfs:
> >> - drm_bridge_remove(bridge);
> >> hdmi->drm_connector = NULL;
> >> return -EINVAL;
> >> }
> >> --
> >> 2.11.0
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [RFC PATCH] driver core: make deferring probe forever optional
From: Rob Herring @ 2018-05-07 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505012513.GJ13402@sirena.org.uk>
On Fri, May 4, 2018 at 8:25 PM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 02, 2018 at 07:49:57PM +0100, Robin Murphy wrote:
>
>> I guess there's also the possibility that a single driver may want multiple
>> behaviours, if e.g. if SoC variants A and B have some identical peripherals
>> but slightly different pinctrl/IOMMU/etc. hardware such that A has workable
>> default behaviour and can be treated as optional, whereas B absolutely must
>> be controlled by the kernel for the consumers to function properly, and they
>> *should* defer forever otherwise. I think that would pretty much demand some
>> sort of explicitly-curated white/blacklist setup at the subsystem or driver
>> level.
>
> Different board variants, and possibly even different bootloaders might
> also be an issue here - a vendor bootloader might do pinmuxing that an
> upstream bootloader doesn't for example. In some cases the pinmuxing
> even depends on the boot method with things only getting configured if
> the bootloader wanted to use them.
I think this is going to be too big of a hammer for pinctrl at least.
My current thought is to define a pinctrl DT property to indicate pins
are configured already which the OS can use to decide if pinctrl is
optional or not. I'd prefer to keep it simple and be a per pin
controller flag even though this is quite possibly a per client or pin
group state (as you say, the bootloader may only configure what it
uses). Making this per pin group could be a lot of nodes and difficult
to really get right without testing. Making it per pin controller
could make drivers fail in less predictable ways if their pins are not
configured.
Rob
^ permalink raw reply
* [PATCH v2] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs
From: Boqun Feng @ 2018-05-07 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <tip-0476a632cb3aa88c03cefc294050a9a86760e88d@git.kernel.org>
Move PowerPC's __op_{acqurie,release}() from atomic.h to
cmpxchg.h (in arch/powerpc/include/asm), plus use them to
define these two methods:
#define cmpxchg_release __op_release(cmpxchg, __VA_ARGS__);
#define cmpxchg64_release __op_release(cmpxchg64, __VA_ARGS__);
... the idea is to generate all these methods in cmpxchg.h and to define the full
array of atomic primitives, including the cmpxchg_release() methods which were
defined by the generic code before.
Also define the atomic[64]_() variants explicitly.
This ensures that all these low level cmpxchg APIs are defined in
PowerPC headers, with no generic header fallbacks.
Also remove the duplicate definitions of atomic_xchg() and
atomic64_xchg() in asm/atomic.h: they could be generated via the generic
atomic.h header using _relaxed() primitives. This helps ppc adopt the
upcoming change of generic atomic.h header.
No change in functionality or code generation.
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: aryabinin at virtuozzo.com
Cc: catalin.marinas at arm.com
Cc: dvyukov at google.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: will.deacon at arm.com
---
v1 --> v2:
remove duplicate definitions for atomic*_xchg() for future
change
Ingo,
I also remove the link and your SoB because I think your bot
could add them automatically.
arch/powerpc/include/asm/atomic.h | 24 ++++--------------------
arch/powerpc/include/asm/cmpxchg.h | 24 ++++++++++++++++++++++++
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/asm/atomic.h
index 682b3e6a1e21..583837a41bcc 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -13,24 +13,6 @@
#define ATOMIC_INIT(i) { (i) }
-/*
- * Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
- * a "bne-" instruction at the end, so an isync is enough as a acquire barrier
- * on the platform without lwsync.
- */
-#define __atomic_op_acquire(op, args...) \
-({ \
- typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
- __asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory"); \
- __ret; \
-})
-
-#define __atomic_op_release(op, args...) \
-({ \
- __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
- op##_relaxed(args); \
-})
-
static __inline__ int atomic_read(const atomic_t *v)
{
int t;
@@ -213,8 +195,9 @@ static __inline__ int atomic_dec_return_relaxed(atomic_t *v)
cmpxchg_relaxed(&((v)->counter), (o), (n))
#define atomic_cmpxchg_acquire(v, o, n) \
cmpxchg_acquire(&((v)->counter), (o), (n))
+#define atomic_cmpxchg_release(v, o, n) \
+ cmpxchg_release(&((v)->counter), (o), (n))
-#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
#define atomic_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
/**
@@ -519,8 +502,9 @@ static __inline__ long atomic64_dec_if_positive(atomic64_t *v)
cmpxchg_relaxed(&((v)->counter), (o), (n))
#define atomic64_cmpxchg_acquire(v, o, n) \
cmpxchg_acquire(&((v)->counter), (o), (n))
+#define atomic64_cmpxchg_release(v, o, n) \
+ cmpxchg_release(&((v)->counter), (o), (n))
-#define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
#define atomic64_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
/**
diff --git a/arch/powerpc/include/asm/cmpxchg.h b/arch/powerpc/include/asm/cmpxchg.h
index 9b001f1f6b32..e27a612b957f 100644
--- a/arch/powerpc/include/asm/cmpxchg.h
+++ b/arch/powerpc/include/asm/cmpxchg.h
@@ -8,6 +8,24 @@
#include <asm/asm-compat.h>
#include <linux/bug.h>
+/*
+ * Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
+ * a "bne-" instruction at the end, so an isync is enough as a acquire barrier
+ * on the platform without lwsync.
+ */
+#define __atomic_op_acquire(op, args...) \
+({ \
+ typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
+ __asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory"); \
+ __ret; \
+})
+
+#define __atomic_op_release(op, args...) \
+({ \
+ __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
+ op##_relaxed(args); \
+})
+
#ifdef __BIG_ENDIAN
#define BITOFF_CAL(size, off) ((sizeof(u32) - size - off) * BITS_PER_BYTE)
#else
@@ -512,6 +530,9 @@ __cmpxchg_acquire(void *ptr, unsigned long old, unsigned long new,
(unsigned long)_o_, (unsigned long)_n_, \
sizeof(*(ptr))); \
})
+
+#define cmpxchg_release(...) __atomic_op_release(cmpxchg, __VA_ARGS__)
+
#ifdef CONFIG_PPC64
#define cmpxchg64(ptr, o, n) \
({ \
@@ -533,6 +554,9 @@ __cmpxchg_acquire(void *ptr, unsigned long old, unsigned long new,
BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
cmpxchg_acquire((ptr), (o), (n)); \
})
+
+#define cmpxchg64_release(...) __atomic_op_release(cmpxchg64, __VA_ARGS__)
+
#else
#include <asm-generic/cmpxchg-local.h>
#define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
--
2.16.2
^ permalink raw reply related
* [PATCH v3 2/2] ARM: dts: r8a73a4: Correct mask for GIC PPI interrupts
From: Geert Uytterhoeven @ 2018-05-07 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525699193-5589-1-git-send-email-geert+renesas@glider.be>
R-Mobile APE6 (r8a73a4) contains four Cortex-A15 and four Cortex-A7
cores, hence the second interrupt specifier cell for Private Peripheral
Interrupts should use "GIC_CPU_MASK_SIMPLE(8)", so GIC interrupts are
delivered to all 8 processor cores.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v3:
- Change one-line summary prefix to match current arm-soc practices,
- Rebased,
v2:
- Drop RFC status after receiving confirmation from Liviu Dudau.
---
arch/arm/boot/dts/r8a73a4.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 8e48090e4fdc1412..080d037f5733a8c3 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -57,10 +57,10 @@
timer {
compatible = "arm,armv7-timer";
- interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
};
dbsc1: memory-controller at e6790000 {
@@ -464,7 +464,7 @@
<0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>,
<0 0xf1006000 0 0x2000>;
- interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
clocks = <&mstp4_clks R8A73A4_CLK_INTC_SYS>;
clock-names = "clk";
power-domains = <&pd_c4>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] ARM: dts: r8a7790: Correct mask for GIC PPI interrupts
From: Geert Uytterhoeven @ 2018-05-07 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525699193-5589-1-git-send-email-geert+renesas@glider.be>
R-Car H2 (r8a7790) contains four Cortex-A15 and four Cortex-A7 cores,
hence the second interrupt specifier cell for Private Peripheral
Interrupts should use "GIC_CPU_MASK_SIMPLE(8)", to make sure interrupts
can be delivered to all 8 processor cores.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v3:
- Change one-line summary prefix to match current arm-soc practices,
- Rebase,
v2:
- Drop RFC status after receiving confirmation from Liviu Dudau.
---
arch/arm/boot/dts/r8a7790.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b66a18af28f1659a..47a51cd71434e7d2 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1554,7 +1554,7 @@
interrupt-controller;
reg = <0 0xf1001000 0 0x1000>, <0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>, <0 0xf1006000 0 0x2000>;
- interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
clocks = <&cpg CPG_MOD 408>;
clock-names = "clk";
power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
@@ -1810,10 +1810,10 @@
timer {
compatible = "arm,armv7-timer";
- interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
};
/* External USB clock - can be overridden by the board */
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox