Re: [RFC 2/3] ARM: sunxi: do not select COMMON_CLK to fix builds
On 11/15/20 11:09 AM, Krzysztof Kozlowski wrote:
> COMMON_CLK is a user-selectable option with its own dependencies. The
> most important dependency is !HAVE_LEGACY_CLK. User-selectable drivers
> should not select COMMON_CLK because they will create a dependency cycle
> and build failures. For example on MIPS a configuration with COMMON_CLK
> (selected by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (selected by
> SOC_RT305X) is possible:
Ah, that makes sense.
>
> WARNING: unmet direct dependencies detected for COMMON_CLK
> Depends on [n]: !HAVE_LEGACY_CLK [=y]
> Selected by [y]:
> - SND_SUN8I_CODEC [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y]
> &&
> (ARCH_SUNXI || COMPILE_TEST [=y]) && OF [=y] && (MACH_SUN8I || ARM64 &&
> ARCH_SUNXI || COMPILE_TEST [=y])
>
> /usr/bin/mips-linux-gnu-ld: drivers/clk/clk.o: in function `clk_set_rate':
> (.text+0xaeb4): multiple definition of `clk_set_rate';
> arch/mips/ralink/clk.o:(.text+0x88): first defined here
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> arch/arm/mach-sunxi/Kconfig | 1 +
> sound/soc/sunxi/Kconfig | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index eeadb1a4dcfe..4d9f9b6d329d 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -4,6 +4,7 @@ menuconfig ARCH_SUNXI
> depends on ARCH_MULTI_V5 || ARCH_MULTI_V7
> select ARCH_HAS_RESET_CONTROLLER
> select CLKSRC_MMIO
> + select COMMON_CLK
This is not necessary, since ARCH_SUNXI depends (through ARCH_MULTI_V{5,7}) on
ARCH_MULTIPLATFORM, which selects COMMON_CLK already.
> select GENERIC_IRQ_CHIP
> select GPIOLIB
> select PINCTRL
> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
> index 69b9d8515335..ddcaaa98d3cb 100644
> --- a/sound/soc/sunxi/Kconfig
> +++ b/sound/soc/sunxi/Kconfig
> @@ -14,7 +14,7 @@ config SND_SUN8I_CODEC
> tristate "Allwinner SUN8I audio codec"
> depends on OF
> depends on MACH_SUN8I || (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> - select COMMON_CLK
> + depends on COMMON_CLK
> select REGMAP_MMIO
> help
> This option enables the digital part of the internal audio codec for
>
For this file:
Reviewed-by: Samuel Holland
Thanks,
Samuel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 3/6] ARM: dts: sun8i: v3s: Add node for system control
On 12/3/20 10:44 AM, Chen-Yu Tsai wrote:
> On Fri, Dec 4, 2020 at 12:25 AM Martin Cerveny wrote:
>>
>> Hello.
>>
>> On Thu, 3 Dec 2020, Chen-Yu Tsai wrote:
>>
>>> Hi,
>>>
>>> On Mon, Nov 16, 2020 at 8:57 PM Martin Cerveny
>>> wrote:
Allwinner V3s has system control and SRAM C1 region similar to H3.
Signed-off-by: Martin Cerveny
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 0c7341676921..70193512c222 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -161,6 +161,20 @@ syscon: system-control@1c0 {
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+ sram_c: sram@1d0 {
+ compatible = "mmio-sram";
+ reg = <0x01d0 0x8>;
>>>
>>> How was this address derived? Did you check that there is actually SRAM
>>> here?
>>
>> Yes, I did some checking (mmap). But I repeated measurement and found
>> mirrored regions:
>>
>> - SRAM_C is mirrored from 0x_4000 (primary location) to 0x01d0_4000
>> (size 0xb000)
>>(probably exact size is 0xb0c0)
>> - rest of 0x01d0_ are discontinuously filled with R/W register sets
>>(probably some internals registers from VE) that I thought to be SRAM too
>> - register SRAM_CTRL_REG0==0x01c00_ (value 0x7fff_) switch whole
>>region 0x01d0_-0x01df_ __AND__ 0x_4000-0x_
>> - VE/cedrus code use this regions indirectly
>>(VE_AVC_SRAM_PORT_OFFSET/VE_AVC_SRAM_PORT_DATA...)
>>and it is not influenced by "true" SRAM mapping or size
>
> Could you add this to your commit log? That would make the information
> available to others, and you could mention that you only added the
> location that is contiguous SRAM without the interspersed registers.
>
> So based on this, and what we've seen with the H616, I'm guessing
> 0x01d0_ - 0x01df_ exposes all the internal guts of the VE,
> while SRAM C @ 0x4000 just maps a small portion out.
>
>> -> so I suppose to better use only SRAM_C lower definition:
>
> Yes that would be more appropriate, as it matches the manual, and as you
> mentioned, is *real* SRAM.
My reading of the manual and comments in the BSP U-Boot is that the high
address near the VE registers is the "real" address. The alternate SRAM
mapping just past the end of SRAM A1 exists specifically so the boot ROM
can load boot0/TOC0 images larger than would fit in SRAM A1.
I don't have a copy of the V3s BROM, but here's the logic from the
beginning of the H6 SBROM, which first enables the VE bus clock and
reset before mapping the SRAM:
; VE_BGR_REG |= BIT(16)
2dc: e59f113c ldr r1, [pc, #316] ; 420
2e0: e5912000 ldr r2, [r1]
2e4: e3a03801 mov r3, #65536 ; 0x1
2e8: e1822003 orr r2, r2, r3
2ec: e5812000 str r2, [r1]
; VE_BGR_REG |= BIT(0)
2f0: e59f1128 ldr r1, [pc, #296] ; 420
2f4: e5912000 ldr r2, [r1]
2f8: e3a03001 mov r3, #1
2fc: e1822003 orr r2, r2, r3
300: e5812000 str r2, [r1]
; SRAM_CTRL_REG0 &= BIT(31)
304: e3a01403 mov r1, #50331648 ; 0x300
308: e5912000 ldr r2, [r1]
30c: e3c220ff bic r2, r2, #255 ; 0xff
310: e3c22cff bic r2, r2, #65280 ; 0xff00
314: e3c228ff bic r2, r2, #16711680 ; 0xff
318: e3c2247f bic r2, r2, #2130706432 ; 0x7f00
31c: e5812000 str r2, [r1]
; SRAM_CTRL_REG1 = BIT(24) | BIT(0)
320: e59f10fc ldr r1, [pc, #252] ; 424
324: e3a02401 mov r2, #16777216 ; 0x100
328: e1822003 orr r2, r2, r3
32c: e5812000 str r2, [r1]
...
420: .word 0300169c
424: .word 0304
Then U-Boot SPL[1] sets the SRAM back to "normal mode" before turning
off the VE gating and reset:
//VE SRAM:set sram to normal mode, default boot mode
reg_val = readl(SUNXI_SYSCRL_BASE+0X0004);
reg_val &= ~(0x1<<24);
writel(reg_val, SUNXI_SYSCRL_BASE+0X0004);
//VE gating&VE Bus Reset :brom set them, but not require now
reg_val = readl(CCMU_VE_BGR_REG);
reg_val &= ~(0x1<<0);
reg_val &= ~(0x1<<16);
writel(reg_val, CCMU_VE_BGR_REG);
Other SoCs have a similar code to unmap SRAM C[2]. The AHB1 bus clock
frequency limitation makes sense given that it has to go through the VE
hardware block to get to the SRAM.
In fact, the AHB1 clock limitation when using the low mapping should be
reason enough to prefer the high mapping.
Cheers,
Samuel
[1]:
https://github.com/Allwinner-Homlet/H6-BSP4.9-brandy/blob/master/u-boot-2014.07/board/sunxi/sun50iw6p1/sun50iw6p1.c#L60
[2]:
https://github.com/Allwinner-Homlet/H6-BSP4.9-brandy/blob/master/u-boot-2014.07/board/sunxi/sun8iw10p1/sun8iw10p1.c#L7
Re: [PATCH v4 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller
On 12/31/20 8:29 AM, Paul Kocialkowski wrote:
> The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
> found on Allwinner SoCs such as the A31 and V3/V3s.
>
> It is a standalone block, connected to the CSI controller on one side
> and to the MIPI D-PHY block on the other. It has a dedicated address
> space, interrupt line and clock.
>
> It is represented as a V4L2 subdev to the CSI controller and takes a
> MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
> media controller API.
>
> Only 8-bit and 10-bit Bayer formats are currently supported.
> While up to 4 internal channels to the CSI controller exist, only one
> is currently supported by this implementation.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/media/platform/sunxi/Kconfig | 1 +
> drivers/media/platform/sunxi/Makefile | 1 +
> .../platform/sunxi/sun6i-mipi-csi2/Kconfig| 12 +
> .../platform/sunxi/sun6i-mipi-csi2/Makefile | 4 +
> .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c | 590 ++
> .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h | 117
> 6 files changed, 725 insertions(+)
> create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> create mode 100644
> drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> create mode 100644
> drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h
>
> diff --git a/drivers/media/platform/sunxi/Kconfig
> b/drivers/media/platform/sunxi/Kconfig
> index 7151cc249afa..9684e07454ad 100644
> --- a/drivers/media/platform/sunxi/Kconfig
> +++ b/drivers/media/platform/sunxi/Kconfig
> @@ -2,3 +2,4 @@
>
> source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
> source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
> +source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
> diff --git a/drivers/media/platform/sunxi/Makefile
> b/drivers/media/platform/sunxi/Makefile
> index fc537c9f5ca9..887a7cae8fca 100644
> --- a/drivers/media/platform/sunxi/Makefile
> +++ b/drivers/media/platform/sunxi/Makefile
> @@ -2,5 +2,6 @@
>
> obj-y+= sun4i-csi/
> obj-y+= sun6i-csi/
> +obj-y+= sun6i-mipi-csi2/
> obj-y+= sun8i-di/
> obj-y+= sun8i-rotate/
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> new file mode 100644
> index ..47f1bb0779a8
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> @@ -0,0 +1,12 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config VIDEO_SUN6I_MIPI_CSI2
> + tristate "Allwinner A31 MIPI CSI-2 Controller Driver"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + depends on PM && COMMON_CLK && VIDEO_V4L2
> + select REGMAP_MMIO
> + select PHY_SUN6I_MIPI_DPHY
> + select MEDIA_CONTROLLER
> + select VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
> + help
> +Support for the Allwinner A31 MIPI CSI-2 Controller.
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> new file mode 100644
> index ..14e4e03818b5
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +sun6i-mipi-csi2-y += sun6i_mipi_csi2.o
> +
> +obj-$(CONFIG_VIDEO_SUN6I_MIPI_CSI2) += sun6i-mipi-csi2.o
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> new file mode 100644
> index ..87307beda4cf
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> @@ -0,0 +1,590 @@
[...]
> +/* Base Driver */
> +
> +static int sun6i_mipi_csi2_suspend(struct device *dev)
> +{
> + struct sun6i_mipi_csi2_dev *cdev = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(cdev->clk_mod);
> + clk_disable_unprepare(cdev->clk_bus);
> + reset_control_assert(cdev->reset);
> +
> + return 0;
> +}
> +
> +static int sun6i_mipi_csi2_resume(struct device *dev)
> +{
> + struct sun6i_mipi_csi2_dev *cdev = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = reset_control_deassert(cdev->reset);
> + if (ret) {
> + dev_err(cdev->dev, "failed to deassert reset\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(cdev->clk_bus);
> + if (ret) {
> + dev_err(cdev->dev, "failed to enable bus clock\n");
> + goto error_reset;
> + }
> +
> + ret = clk_prepare_enable(cdev->clk_mod);
> + if (ret) {
> + dev_err(cdev->dev, "failed to enable module clock\n");
> + goto error_clk_bus;
> + }
> +
> + return 0;
> +
> +error_clk_bus:
> + clk_disable_unprepare(cdev->clk_bus);
> +
> +error_reset:
> + reset_cont
