[linux-sunxi] Re: [PATCH v2] sunxi: clock: H6/H616: Fix PLL clock factor encodings
On Wed, 5 May 2021 13:53:05 +0100
Andre Przywara wrote:
Hi,
> Most clock factors and dividers in the H6 PLLs use a "+1 encoding",
> which we were missing on two occasions.
can someone please confirm that I didn't mess this up?
Cheers,
Andre
>
> This fixes the MMC clock setup on the H6, which could be slightly off due
> to the wrong parent frequency:
> mmc 2 set mod-clk req 5200 parent 117600 n 2 m 12 rate 4900
>
> Also the CPU frequency was a tad too high before.
>
> Signed-off-by: Andre Przywara
> ---
> Changelog v1 .. v2:
> - Also fix PLL5 factor calculation (video, currently unused)
> - Also fix PLL1 factor calculation (CPU clock)
>
> arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h | 4 ++--
> arch/arm/mach-sunxi/clock_sun50i_h6.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> index 62abfc4ef6b..2e076cf594d 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> @@ -233,14 +233,14 @@ struct sunxi_ccm_reg {
> #define CCM_PLL1_OUT_EN BIT(27)
> #define CCM_PLL1_CLOCK_TIME_2(2 << 24)
> #define CCM_PLL1_CTRL_P(p) ((p) << 16)
> -#define CCM_PLL1_CTRL_N(n) ((n) << 8)
> +#define CCM_PLL1_CTRL_N(n) (((n) - 1) << 8)
>
> /* pll5 bit field */
> #define CCM_PLL5_CTRL_EN BIT(31)
> #define CCM_PLL5_LOCK_EN BIT(29)
> #define CCM_PLL5_LOCKBIT(28)
> #define CCM_PLL5_OUT_EN BIT(27)
> -#define CCM_PLL5_CTRL_N(n) ((n) << 8)
> +#define CCM_PLL5_CTRL_N(n) (((n) - 1) << 8)
> #define CCM_PLL5_CTRL_DIV1(div1) ((div1) << 0)
> #define CCM_PLL5_CTRL_DIV2(div0) ((div0) << 1)
>
> diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> index 492fc4a3fca..a947463e0a5 100644
> --- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> @@ -94,7 +94,7 @@ unsigned int clock_get_pll6(void)
> int m = IS_ENABLED(CONFIG_MACH_SUN50I_H6) ? 4 : 2;
>
> uint32_t rval = readl(>pll6_cfg);
> - int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT);
> + int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT) + 1;
> int div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
> CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
> int div2 = ((rval & CCM_PLL6_CTRL_DIV2_MASK) >>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20210527004948.0c2ef6b6%40slackpad.fritz.box.
[linux-sunxi] Re: [PATCH v2 4/6] net: sun8i-emac: add v3s variant
On Sun, 23 May 2021 01:22:38 +0200
Andreas Rehn wrote:
Hi,
> Add variant V3S_EMAC.
> Handle pinmux compile time error by skipping goio setup, because
> V3s uses internal phy and don't expose pins.
>
> Signed-off-by: Andreas Rehn
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> Changes in v2:
> - skip pinmux and add proper description
> - Add V3S variant add it to compatible list
> - Skip (R)GMII flags and handle sun8i_handle_internal_phy
>
> drivers/net/sun8i_emac.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> index 5a1b38bf80..ab9f61994c 100644
> --- a/drivers/net/sun8i_emac.c
> +++ b/drivers/net/sun8i_emac.c
> @@ -145,6 +145,7 @@ enum emac_variant {
> A64_EMAC,
> R40_GMAC,
> H6_EMAC,
> + V3S_EMAC,
> };
>
> struct emac_dma_desc {
> @@ -303,7 +304,7 @@ static void sun8i_adjust_link(struct emac_eth_dev *priv,
> static u32 sun8i_emac_set_syscon_ephy(struct emac_eth_dev *priv, u32 reg)
> {
> if (priv->use_internal_phy) {
> - /* H3 based SoC's that has an Internal 100MBit PHY
> + /* H3 and V3s based SoC's that has an Internal 100MBit PHY
>* needs to be configured and powered up before use
> */
> reg &= ~H3_EPHY_DEFAULT_MASK;
> @@ -354,7 +355,8 @@ static int sun8i_emac_set_syscon(struct sun8i_eth_pdata
> *pdata,
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> - reg |= SC_EPIT | SC_ETCS_INT_GMII;
> + if (priv->variant != V3S_EMAC)
> + reg |= SC_EPIT | SC_ETCS_INT_GMII;
> break;
> case PHY_INTERFACE_MODE_RMII:
> if (priv->variant == H3_EMAC ||
> @@ -566,6 +568,10 @@ static int parse_phy_pins(struct udevice *dev)
> iomux = SUN8I_IOMUX;
> else if (IS_ENABLED(CONFIG_MACH_SUN50I))
> iomux = SUN8I_IOMUX;
> + else if (IS_ENABLED(CONFIG_MACH_SUN8I_V3S))
> + // V3s does not expose any MAC pins,
> + // but case is required to handle BUILD_BUG_ON_MSG.
> + return 0;
> else
> BUILD_BUG_ON_MSG(1, "missing pinmux value for Ethernet pins");
>
> @@ -956,7 +962,8 @@ static int sun8i_emac_eth_of_to_plat(struct udevice *dev)
> return -EINVAL;
> }
>
> - if (priv->variant == H3_EMAC) {
> + if (priv->variant == H3_EMAC ||
> + priv->variant == V3S_EMAC) {
> ret = sun8i_handle_internal_phy(dev, priv);
> if (ret)
> return ret;
> @@ -1009,6 +1016,8 @@ static const struct udevice_id sun8i_emac_eth_ids[] = {
> .data = (uintptr_t)R40_GMAC },
> {.compatible = "allwinner,sun50i-h6-emac",
> .data = (uintptr_t)H6_EMAC },
> + {.compatible = "allwinner,sun8i-v3s-emac",
> + .data = (uintptr_t)V3S_EMAC },
> { }
> };
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20210527002419.39cd8542%40slackpad.fritz.box.
[linux-sunxi] Re: [PATCH v2 3/6] clk: sunxi: v3s: fix tabs / spaces
On Sun, 23 May 2021 01:17:29 +0200
Andreas Rehn wrote:
> align CLK_USB_PHY0 with tabs
>
> Signed-off-by: Andreas Rehn
Reviewed-by: Andre Przywara
Cheers,
Andre
P.S. Please send a whole v2 series next time, to make this easier to
sort out which patch still applies and which not.
> ---
> Changes in v2:
> - revert CLK_SPI0 extra tab
>
> drivers/clk/sunxi/clk_v3s.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi/clk_v3s.c b/drivers/clk/sunxi/clk_v3s.c
> index 55fc597043..bc6b7b4870 100644
> --- a/drivers/clk/sunxi/clk_v3s.c
> +++ b/drivers/clk/sunxi/clk_v3s.c
> @@ -29,7 +29,7 @@ static struct ccu_clk_gate v3s_gates[] = {
>
> [CLK_SPI0] = GATE(0x0a0, BIT(31)),
>
> - [CLK_USB_PHY0] = GATE(0x0cc, BIT(8)),
> + [CLK_USB_PHY0] = GATE(0x0cc, BIT(8)),
> };
>
> static struct ccu_reset v3s_resets[] = {
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20210527001624.66ffeb28%40slackpad.fritz.box.
[linux-sunxi] Re: [PATCH v5 02/16] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes
Hi everyone,
On Fri 15 Jan 21, 21:01, Paul Kocialkowski wrote:
> As some D-PHY controllers support both Rx and Tx mode, we need a way for
> users to explicitly request one or the other. For instance, Rx mode can
> be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.
>
> Introduce new MIPI D-PHY PHY submodes to use with PHY_MODE_MIPI_DPHY.
> The default (zero value) is kept to Tx so only the rkisp1 driver, which
> uses D-PHY in Rx mode, needs to be adapted.
I think it was Laurent who brought up on IRC that using a submode is probably
not a correct way to distinguish between Rx and Tx modes.
Thinking about it again, it feels like selecting the direction at run-time
would only be relevant if there's D-PHY hardware than can do both Tx and Rx
*and* that can be muxed to either a MIPI DSI and a CSI-2 controller at
run-time.
For the Allwinner case, the D-PHY is the same hardware for both but there will
be one instance attached to each controller, not a single shared instance.
It feels rather unlikely that a device with both MIPI DSI and CSI-2 would only
have one PHY for the two as this wouldn't allow concurrent use of the two
controllers. Even in a case where there'd be n controllers and m < n
bi-directional PHYs, it feels safe to assume that a static attribution would
be sufficient.
As a result it feels more relevant to have this distinction in device-tree
rather than via the PHY API.
What do you think?
Any suggestion on how this should be represented in device-tree?
Cheers,
Paul
> Signed-off-by: Paul Kocialkowski
> Acked-by: Helen Koike
> ---
> drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 3 ++-
> include/linux/phy/phy-mipi-dphy.h | 13 +
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> index 2e5b57e3aedc..cab261644102 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> @@ -948,7 +948,8 @@ static int rkisp1_mipi_csi2_start(struct rkisp1_isp *isp,
>
> phy_mipi_dphy_get_default_config(pixel_clock, isp->sink_fmt->bus_width,
>sensor->lanes, cfg);
> - phy_set_mode(sensor->dphy, PHY_MODE_MIPI_DPHY);
> + phy_set_mode_ext(cdev->dphy, PHY_MODE_MIPI_DPHY,
> + PHY_MIPI_DPHY_SUBMODE_RX);
> phy_configure(sensor->dphy, );
> phy_power_on(sensor->dphy);
>
> diff --git a/include/linux/phy/phy-mipi-dphy.h
> b/include/linux/phy/phy-mipi-dphy.h
> index a877ffee845d..0f57ef46a8b5 100644
> --- a/include/linux/phy/phy-mipi-dphy.h
> +++ b/include/linux/phy/phy-mipi-dphy.h
> @@ -6,6 +6,19 @@
> #ifndef __PHY_MIPI_DPHY_H_
> #define __PHY_MIPI_DPHY_H_
>
> +/**
> + * enum phy_mipi_dphy_submode - MIPI D-PHY sub-mode
> + *
> + * A MIPI D-PHY can be used to transmit or receive data.
> + * Since some controllers can support both, the direction to enable is
> specified
> + * with the PHY sub-mode. Transmit is assumed by default with phy_set_mode.
> + */
> +
> +enum phy_mipi_dphy_submode {
> + PHY_MIPI_DPHY_SUBMODE_TX = 0,
> + PHY_MIPI_DPHY_SUBMODE_RX,
> +};
> +
> /**
> * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
> *
> --
> 2.30.0
>
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/YK5aAL6ciI92ruHs%40aptenodytes.
signature.asc
Description: PGP signature
[linux-sunxi] Re: [PATCH v5 00/16] Allwinner MIPI CSI-2 support for A31/V3s/A83T
Hi, On Wed 26 May 21, 14:00, Hans Verkuil wrote: > Hi Paul, > > On 15/01/2021 21:01, Paul Kocialkowski wrote: > > This series introduces support for MIPI CSI-2, with the A31 controller that > > is > > found on most SoCs (A31, V3s and probably V5) as well as the A83T-specific > > controller. While the former uses the same MIPI D-PHY that is already > > supported > > for DSI, the latter embeds its own D-PHY. > > > > In order to distinguish the use of the D-PHY between Rx mode (for MIPI > > CSI-2) > > and Tx mode (for MIPI DSI), a submode is introduced for D-PHY in the PHY > > API. > > This allows adding Rx support in the A31 D-PHY driver. > > > > A few changes and fixes are applied to the A31 CSI controller driver, in > > order > > to support the MIPI CSI-2 use-case. > > Besides the compile error for patch 2/16, I also get several other compile > errors: > > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c: In function > ‘sun6i_csi_v4l2_fwnode_init’: > ./include/media/v4l2-async.h:207:10: error: expected expression before ‘)’ > token > 207 | ((type *) \ > | ^ > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c:790:8: note: in expansion > of macro ‘v4l2_async_notifier_add_fwnode_remote_subdev’ > 790 | ret = v4l2_async_notifier_add_fwnode_remote_subdev(>notifier, > |^~~~ > ./include/media/v4l2-async.h:207:10: error: expected expression before ‘)’ > token > 207 | ((type *) \ > | ^ > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c:811:8: note: in expansion > of macro ‘v4l2_async_notifier_add_fwnode_remote_subdev’ > 811 | ret = v4l2_async_notifier_add_fwnode_remote_subdev(>notifier, > |^~~~ > make[5]: *** [scripts/Makefile.build:272: > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.o] Error 1 > make[5]: *** Waiting for unfinished jobs > make[4]: *** [scripts/Makefile.build:272: > drivers/media/platform/rockchip/rkisp1/rkisp1-isp.o] Error 1 > make[3]: *** [scripts/Makefile.build:515: > drivers/media/platform/rockchip/rkisp1] Error 2 > make[3]: *** Waiting for unfinished jobs > In file included from ./include/media/v4l2-subdev.h:14, > from ./include/media/v4l2-device.h:13, > from > drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c:19: > drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c: In > function ‘sun8i_a83t_mipi_csi2_v4l2_setup’: > ./include/media/v4l2-async.h:207:10: error: expected expression before ‘)’ > token > 207 | ((type *) \ > | ^ > drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c:495:8: > note: in expansion of macro > ‘v4l2_async_notifier_add_fwnode_remote_subdev’ > 495 | ret = v4l2_async_notifier_add_fwnode_remote_subdev(notifier, handle, > |^~~~ > In file included from ./include/media/v4l2-subdev.h:14, > from ./include/media/v4l2-device.h:13, > from > drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c:18: > drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c: In function > ‘sun6i_mipi_csi2_v4l2_setup’: > ./include/media/v4l2-async.h:207:10: error: expected expression before ‘)’ > token > 207 | ((type *) \ > | ^ > drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c:437:8: note: > in expansion of macro ‘v4l2_async_notifier_add_fwnode_remote_subdev’ > 437 | ret = v4l2_async_notifier_add_fwnode_remote_subdev(notifier, handle, > |^~~~ > > Can you rebase this series? Thanks for letting me know, I'll look into this for the next iteration. > I also need Acked-by's for patches 1-3 from one of the PHY maintainers, but as > you mentioned this might need to change as well. > > Was there a reason why I haven't looked at this before? It's quite an old > series, > usually I don't wait for so long. If it was because I was really slow, then I > apologize and please kick me sooner if you see a review like this take so > long. I'm not sure, but Sakari definitely went over previous interations and made various comments,so the series definitely hasn't gone unreviewed! To be honest I also lost momentum on this but I'll be trying to finalize the series soon, once the discussion on rx/tx handling has concluded. Cheers, Paul > > Regards, > > Hans > > > > > Changes since v4: > > - Added patch to stop using v4l2_async_notifier_parse_fwnode_endpoints; > > - Fixed checkpatch strict issues (parenthesis alignment); > > - Fixed runtime PM call order and disable; > > - Fixed fwnode_handle_put order; > > - Brought back phy-names for A31 since it's mandatory according to the > > generic > > PHY binding and needed by the code; > > - Added collected tags. > > > > Changes since v3:
[linux-sunxi] Re: [PATCH v5 00/16] Allwinner MIPI CSI-2 support for A31/V3s/A83T
Hi Paul, On 15/01/2021 21:01, Paul Kocialkowski wrote: > This series introduces support for MIPI CSI-2, with the A31 controller that is > found on most SoCs (A31, V3s and probably V5) as well as the A83T-specific > controller. While the former uses the same MIPI D-PHY that is already > supported > for DSI, the latter embeds its own D-PHY. > > In order to distinguish the use of the D-PHY between Rx mode (for MIPI CSI-2) > and Tx mode (for MIPI DSI), a submode is introduced for D-PHY in the PHY API. > This allows adding Rx support in the A31 D-PHY driver. > > A few changes and fixes are applied to the A31 CSI controller driver, in order > to support the MIPI CSI-2 use-case. Besides the compile error for patch 2/16, I also get several other compile errors: drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c: In function ‘sun6i_csi_v4l2_fwnode_init’: ./include/media/v4l2-async.h:207:10: error: expected expression before ‘)’ token 207 | ((type *) \ | ^ drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c:790:8: note: in expansion of macro ‘v4l2_async_notifier_add_fwnode_remote_subdev’ 790 | ret = v4l2_async_notifier_add_fwnode_remote_subdev(>notifier, |^~~~ ./include/media/v4l2-async.h:207:10: error: expected expression before ‘)’ token 207 | ((type *) \ | ^ drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c:811:8: note: in expansion of macro ‘v4l2_async_notifier_add_fwnode_remote_subdev’ 811 | ret = v4l2_async_notifier_add_fwnode_remote_subdev(>notifier, |^~~~ make[5]: *** [scripts/Makefile.build:272: drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.o] Error 1 make[5]: *** Waiting for unfinished jobs make[4]: *** [scripts/Makefile.build:272: drivers/media/platform/rockchip/rkisp1/rkisp1-isp.o] Error 1 make[3]: *** [scripts/Makefile.build:515: drivers/media/platform/rockchip/rkisp1] Error 2 make[3]: *** Waiting for unfinished jobs In file included from ./include/media/v4l2-subdev.h:14, from ./include/media/v4l2-device.h:13, from drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c:19: drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c: In function ‘sun8i_a83t_mipi_csi2_v4l2_setup’: ./include/media/v4l2-async.h:207:10: error: expected expression before ‘)’ token 207 | ((type *) \ | ^ drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c:495:8: note: in expansion of macro ‘v4l2_async_notifier_add_fwnode_remote_subdev’ 495 | ret = v4l2_async_notifier_add_fwnode_remote_subdev(notifier, handle, |^~~~ In file included from ./include/media/v4l2-subdev.h:14, from ./include/media/v4l2-device.h:13, from drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c:18: drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c: In function ‘sun6i_mipi_csi2_v4l2_setup’: ./include/media/v4l2-async.h:207:10: error: expected expression before ‘)’ token 207 | ((type *) \ | ^ drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c:437:8: note: in expansion of macro ‘v4l2_async_notifier_add_fwnode_remote_subdev’ 437 | ret = v4l2_async_notifier_add_fwnode_remote_subdev(notifier, handle, |^~~~ Can you rebase this series? I also need Acked-by's for patches 1-3 from one of the PHY maintainers, but as you mentioned this might need to change as well. Was there a reason why I haven't looked at this before? It's quite an old series, usually I don't wait for so long. If it was because I was really slow, then I apologize and please kick me sooner if you see a review like this take so long. Regards, Hans > > Changes since v4: > - Added patch to stop using v4l2_async_notifier_parse_fwnode_endpoints; > - Fixed checkpatch strict issues (parenthesis alignment); > - Fixed runtime PM call order and disable; > - Fixed fwnode_handle_put order; > - Brought back phy-names for A31 since it's mandatory according to the generic > PHY binding and needed by the code; > - Added collected tags. > > Changes since v3: > - Fixed single-item phys description in sun6i mipi csi-2 binding; > - Fixed variables names in macros using container_of; > - Fixed style issue with operators at the end of lines; > - Reworked source endpoint/subdev assignment in sun6i-csi to handle > link_validate error case; > - Removed unrelated dt change in sun8i-a83t mipi csi-2 driver; > - Added collected tags. > > Changes since v2: > - added Kconfig depend on PM since it's not optional; > - removed phy-names for A31 MIPI CSI-2 controller; > - removed v3s compatible in the A31 MIPI CSI-2 controller driver; > - removed A31 CSI controller single-port binding deprecation; > - removed
[linux-sunxi] Re: [PATCH v5 02/16] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes
Hi,
On Wed 26 May 21, 13:50, Hans Verkuil wrote:
> On 15/01/2021 21:01, Paul Kocialkowski wrote:
> > As some D-PHY controllers support both Rx and Tx mode, we need a way for
> > users to explicitly request one or the other. For instance, Rx mode can
> > be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.
> >
> > Introduce new MIPI D-PHY PHY submodes to use with PHY_MODE_MIPI_DPHY.
> > The default (zero value) is kept to Tx so only the rkisp1 driver, which
> > uses D-PHY in Rx mode, needs to be adapted.
> >
> > Signed-off-by: Paul Kocialkowski
> > Acked-by: Helen Koike
> > ---
> > drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 3 ++-
> > include/linux/phy/phy-mipi-dphy.h | 13 +
> > 2 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> > b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> > index 2e5b57e3aedc..cab261644102 100644
> > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> > @@ -948,7 +948,8 @@ static int rkisp1_mipi_csi2_start(struct rkisp1_isp
> > *isp,
> >
> > phy_mipi_dphy_get_default_config(pixel_clock, isp->sink_fmt->bus_width,
> > sensor->lanes, cfg);
> > - phy_set_mode(sensor->dphy, PHY_MODE_MIPI_DPHY);
> > + phy_set_mode_ext(cdev->dphy, PHY_MODE_MIPI_DPHY,
> > +PHY_MIPI_DPHY_SUBMODE_RX);
>
> drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c: In function
> ‘rkisp1_mipi_csi2_start’:
> drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c:951:19: error: ‘cdev’
> undeclared (first use in this function)
> 951 | phy_set_mode_ext(cdev->dphy, PHY_MODE_MIPI_DPHY,
> | ^~~~
>
> Huh?
Oh wow that's quite shameful. Apologies here.
Note that I'll rebase/respin this series. I also remember that it wasn't very
consensual (on IRC) to use a submode to indicate rx vs tx mode and that
specifying that in the deivce-tree would be a better fit.
Cheers,
Paul
> Regards,
>
> Hans
>
> > phy_configure(sensor->dphy, );
> > phy_power_on(sensor->dphy);
> >
> > diff --git a/include/linux/phy/phy-mipi-dphy.h
> > b/include/linux/phy/phy-mipi-dphy.h
> > index a877ffee845d..0f57ef46a8b5 100644
> > --- a/include/linux/phy/phy-mipi-dphy.h
> > +++ b/include/linux/phy/phy-mipi-dphy.h
> > @@ -6,6 +6,19 @@
> > #ifndef __PHY_MIPI_DPHY_H_
> > #define __PHY_MIPI_DPHY_H_
> >
> > +/**
> > + * enum phy_mipi_dphy_submode - MIPI D-PHY sub-mode
> > + *
> > + * A MIPI D-PHY can be used to transmit or receive data.
> > + * Since some controllers can support both, the direction to enable is
> > specified
> > + * with the PHY sub-mode. Transmit is assumed by default with phy_set_mode.
> > + */
> > +
> > +enum phy_mipi_dphy_submode {
> > + PHY_MIPI_DPHY_SUBMODE_TX = 0,
> > + PHY_MIPI_DPHY_SUBMODE_RX,
> > +};
> > +
> > /**
> > * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
> > *
> >
>
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/YK43hBmFkyCChvKw%40aptenodytes.
signature.asc
Description: PGP signature
[linux-sunxi] Re: [PATCH v5 02/16] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes
On 15/01/2021 21:01, Paul Kocialkowski wrote:
> As some D-PHY controllers support both Rx and Tx mode, we need a way for
> users to explicitly request one or the other. For instance, Rx mode can
> be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.
>
> Introduce new MIPI D-PHY PHY submodes to use with PHY_MODE_MIPI_DPHY.
> The default (zero value) is kept to Tx so only the rkisp1 driver, which
> uses D-PHY in Rx mode, needs to be adapted.
>
> Signed-off-by: Paul Kocialkowski
> Acked-by: Helen Koike
> ---
> drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 3 ++-
> include/linux/phy/phy-mipi-dphy.h | 13 +
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> index 2e5b57e3aedc..cab261644102 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> @@ -948,7 +948,8 @@ static int rkisp1_mipi_csi2_start(struct rkisp1_isp *isp,
>
> phy_mipi_dphy_get_default_config(pixel_clock, isp->sink_fmt->bus_width,
>sensor->lanes, cfg);
> - phy_set_mode(sensor->dphy, PHY_MODE_MIPI_DPHY);
> + phy_set_mode_ext(cdev->dphy, PHY_MODE_MIPI_DPHY,
> + PHY_MIPI_DPHY_SUBMODE_RX);
drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c: In function
‘rkisp1_mipi_csi2_start’:
drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c:951:19: error: ‘cdev’
undeclared (first use in this function)
951 | phy_set_mode_ext(cdev->dphy, PHY_MODE_MIPI_DPHY,
| ^~~~
Huh?
Regards,
Hans
> phy_configure(sensor->dphy, );
> phy_power_on(sensor->dphy);
>
> diff --git a/include/linux/phy/phy-mipi-dphy.h
> b/include/linux/phy/phy-mipi-dphy.h
> index a877ffee845d..0f57ef46a8b5 100644
> --- a/include/linux/phy/phy-mipi-dphy.h
> +++ b/include/linux/phy/phy-mipi-dphy.h
> @@ -6,6 +6,19 @@
> #ifndef __PHY_MIPI_DPHY_H_
> #define __PHY_MIPI_DPHY_H_
>
> +/**
> + * enum phy_mipi_dphy_submode - MIPI D-PHY sub-mode
> + *
> + * A MIPI D-PHY can be used to transmit or receive data.
> + * Since some controllers can support both, the direction to enable is
> specified
> + * with the PHY sub-mode. Transmit is assumed by default with phy_set_mode.
> + */
> +
> +enum phy_mipi_dphy_submode {
> + PHY_MIPI_DPHY_SUBMODE_TX = 0,
> + PHY_MIPI_DPHY_SUBMODE_RX,
> +};
> +
> /**
> * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
> *
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/58d6651d-09c3-2b93-bd5b-1807744b2354%40xs4all.nl.
Re: [linux-sunxi] alternate irc network -> OFTC
On Sat, May 22, 2021 at 09:43:37PM +0200, Luc Verhaegen wrote: > On Fri, May 21, 2021 at 10:01:12PM +0200, Luc Verhaegen wrote: > > All existing and active founders/operators (mnemoc, turl, plaes, rellla, > libv) were moved. And two new ones (wens, apritzel) were added. > > Whitelogger has now also joined: > https://oftc.irclog.whitequark.org/linux-sunxi > > Luc Verhaegen. Things seem to have escalated last night: https://mastodon.sdf.org/@kline/106299403921451814 "andrew lee just seized over 700 channels on freenode because they mentioned libera.chat in their topic." This was in my server log this morning: "06:15 -rasengan(~rasengan@freenode/staff/rasengan)- [Global Notice] In the recent policy enforcement, some channels were erroneously included. We greatly apologize for the inconvenience. Please contact us in #freenode-services or contact...@freenode.net. Thanks for your patience and choosing freenode!" It's time to move, sadly. Many of the regulars are already on OFTC, and the above has left me little option but to +m the channel on freenode. What a waste. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210526064210.GC22252%40skynet.be.
