Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
Hi Maxime, Icenowy, On Sat, 28 Nov 2020 at 12:59, Icenowy Zheng wrote: > > > > 于 2020年11月28日 GMT+08:00 下午7:54:04, "Clément Péron" 写到: > >Hi Icenowy, > > > >On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng wrote: > >> > >> 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道： > >> > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote: > >> > > > > > > > Okay. But I'm not satisfied with a non-public sample > >> > > > > > > > occupies > >> > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a > >> > > > > > > > pinetab-retail okay? > >> > > > > > > > >> > > > > > > To me, naming the production version anything but > >"pinetab" > >> > > > > > > isn't > >> > > > > > > satisfying either. > >> > > > > > > >> > > > > > I understand where you're coming from, but the point I was > >> > > > > > making my > >> > > > > > previous mail is precisely that it's not really possible. > >> > > > > > > >> > > > > > You want to name the early adopter version _the_ production > >> > > > > > version. Let's assume the hardware changes again between > >the > >> > > > > > early > >> > > > > > adopter and mass-production version. Which one will be > >_the_ > >> > > > > > production version? The early-adopter or the mass-produced > >> > > > > > one? > >> > > > > > > >> > > > > > There's really no good answer here, and both would suck in > >> > > > > > their > >> > > > > > own way. The only way to deal with this is to simply avoid > >> > > > > > defining one version as the one true board, and just > >loading > >> > > > > > the > >> > > > > > proper DT in u-boot based on whatever clue we have of the > >> > > > > > hardware > >> > > > > > revision. > >> > > > > Then will it be okay to rename current pinetab DT to > >> > > > > pinetab-sample and then introduce new DTs all with suffixes? > >> > > > > >> > > > No. From my previous mail: > >> > > > >> > > It can be seen as dropping the PineTab DT and introduce new DTs > >> > > with > >> > > suffix. > >> > > > >> > > Do we have rule that we cannot drop boards? > >> > > >> > Are you really arguing that removing a DT and then adding an > >> > identical > >> > one under a different name is not renaming it? > >> > >> Then we can just keep confusing name? > > > >Sorry maybe I missed some information > >But why don't you do like pinephone? > > They're the same board revision with different LCD panels. I just ask Pine64 about this and here is the reply : "The PineTab LCD panel change was a last minutes before production starts that vendor advise us switch over to new LCD controller due to EoL concern". "Pine64 communication" is not so bad we just need to ask and they reply :) So the issue is not that the Product was not finalized but that one component arrives in EoL. This could also happens during a running production. Regards, Clement > > And the major problem is that the DT for samples is already submitted > under the name "PineTab". > > >sun50i-a64-pinetab-1.0.dts > >sun50i-a64-pinetab-1.1.dts > > > >-dev is also a confusing name I think, as the board has been already > >shipped. > > > >Regards, > >Clement > > > > > >> > >> If we do so, how can we mark the new DT as "the user should use this > >> one"? > >> > >> -- > >> 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/1666a61f6ea3e7d573795f9000a0b096c7b7dee0.camel%40aosc.io. -- 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/CAJiuCcc%3Ds6xG7Wzfx6PBU0e3BHz%2BYRpU%3Dt0Ef3EcTp9k11Dkzg%40mail.gmail.com.
[linux-sunxi] [PATCH v2 19/19] MAINTAINERS: Add entry for the Allwinner A83T MIPI CSI-2 bridge
Add myself as maintainer of the A83T MIPI CSI-2 bridge media driver. Signed-off-by: Paul Kocialkowski --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a1352171778b..3b48612657b6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -717,6 +717,14 @@ T: git git://linuxtv.org/media_tree.git F: Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml F: drivers/media/platform/sunxi/sun6i-mipi-csi2/ +ALLWINNER A83T MIPI CSI-2 BRIDGE +M: Paul Kocialkowski +L: linux-me...@vger.kernel.org +S: Maintained +T: git git://linuxtv.org/media_tree.git +F: Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml +F: drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/ + ALLWINNER CPUFREQ DRIVER M: Yangtao Li L: linux...@vger.kernel.org -- 2.29.2 -- 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/20201128142839.517949-20-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 18/19] ARM: dts: sun8i: a83t: Add MIPI CSI-2 controller node
MIPI CSI-2 is supported on the A83T with a dedicated controller that
covers both the protocol and D-PHY. It can be connected to the CSI
interface as a V4L2 subdev through the fwnode graph.
This is not done by default since connecting the bridge without a
subdev attached to it will cause a failure on the CSI driver.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 3ce030f7e05d..ee19cbb565a6 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -1076,6 +1076,32 @@ csi_in_mipi_csi2_bridge: port@1 {
};
};
+ mipi_csi2: csi@1cb1000 {
+ compatible = "allwinner,sun8i-a83t-mipi-csi2";
+ reg = <0x01cb1000 0x1000>;
+ interrupts = ;
+ clocks = < CLK_BUS_CSI>,
+< CLK_CSI_SCLK>,
+< CLK_MIPI_CSI>,
+< CLK_CSI_MISC>;
+ clock-names = "bus", "mod", "mipi", "misc";
+ resets = < RST_BUS_CSI>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_csi2_in: port@0 {
+ reg = <0>;
+ };
+
+ mipi_csi2_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
hdmi: hdmi@1ee {
compatible = "allwinner,sun8i-a83t-dw-hdmi";
reg = <0x01ee 0x1>;
--
2.29.2
--
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/20201128142839.517949-19-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 17/19] media: sunxi: Add support for the A83T MIPI CSI-2 controller
The A83T supports MIPI CSI-2 with a composite controller, covering both the protocol logic and the D-PHY implementation. This controller seems to be found on the A83T only and probably was abandoned since. This implementation splits the protocol and D-PHY registers and uses the PHY framework internally. The D-PHY is not registered as a standalone PHY driver since it cannot be used with any other controller. There are a few notable points about the controller: - The initialisation sequence involes writing specific magic init values that do not seem to make any particular sense given the concerned register fields. - Interrupts appear to be hitting regardless of the interrupt mask registers, which can cause a serious flood when transmission errors occur. 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. This work is based on the first version of the driver submitted by Kévin L'hôpital, which was adapted to mainline from the Allwinner BSP. This version integrates MIPI CSI-2 support as a standalone V4L2 subdev instead of merging it in the sun6i-csi driver. It was tested on a Banana Pi M3 board with an OV8865 sensor in a 4-lane configuration. Signed-off-by: Paul Kocialkowski --- drivers/media/platform/sunxi/Kconfig | 1 + drivers/media/platform/sunxi/Makefile | 1 + .../sunxi/sun8i-a83t-mipi-csi2/Kconfig| 11 + .../sunxi/sun8i-a83t-mipi-csi2/Makefile | 4 + .../sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c| 92 +++ .../sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.h| 39 ++ .../sun8i_a83t_mipi_csi2.c| 657 ++ .../sun8i_a83t_mipi_csi2.h| 197 ++ 8 files changed, 1002 insertions(+) create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.h create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.h diff --git a/drivers/media/platform/sunxi/Kconfig b/drivers/media/platform/sunxi/Kconfig index 9684e07454ad..db4c07be7e4c 100644 --- a/drivers/media/platform/sunxi/Kconfig +++ b/drivers/media/platform/sunxi/Kconfig @@ -3,3 +3,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" +source "drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig" diff --git a/drivers/media/platform/sunxi/Makefile b/drivers/media/platform/sunxi/Makefile index 887a7cae8fca..9aa01cb01883 100644 --- a/drivers/media/platform/sunxi/Makefile +++ b/drivers/media/platform/sunxi/Makefile @@ -3,5 +3,6 @@ obj-y += sun4i-csi/ obj-y += sun6i-csi/ obj-y += sun6i-mipi-csi2/ +obj-y += sun8i-a83t-mipi-csi2/ obj-y += sun8i-di/ obj-y += sun8i-rotate/ diff --git a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig new file mode 100644 index ..162f5d1dc25f --- /dev/null +++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig @@ -0,0 +1,11 @@ +# SPDX-License-Identifier: GPL-2.0-only +config VIDEO_SUN8I_A83T_MIPI_CSI2 + tristate "Allwinner A83T MIPI CSI-2 Controller and D-PHY Driver" + depends on VIDEO_V4L2 && COMMON_CLK + depends on ARCH_SUNXI || COMPILE_TEST + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API + select REGMAP_MMIO + select V4L2_FWNODE + help + Support for the Allwinner A83T MIPI CSI-2 Controller and D-PHY. diff --git a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile new file mode 100644 index ..1427d15a879a --- /dev/null +++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile @@ -0,0 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0-only +sun8i-a83t-mipi-csi2-y += sun8i_a83t_mipi_csi2.o sun8i_a83t_dphy.o + +obj-$(CONFIG_VIDEO_SUN8I_A83T_MIPI_CSI2) += sun8i-a83t-mipi-csi2.o diff --git a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c new file mode 100644 index ..ebb504247956 --- /dev/null +++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c @@ -0,0 +1,92 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2020 Bootlin + * Author: Paul Kocialkowski + */ + +#include +#include + +#include "sun8i_a83t_dphy.h" +#include "sun8i_a83t_mipi_csi2.h" + +static int
[linux-sunxi] [PATCH v2 16/19] dt-bindings: media: Add A83T MIPI CSI-2 bindings documentation
This introduces YAML bindings documentation for the A83T MIPI CSI-2
controller.
Signed-off-by: Paul Kocialkowski
---
.../media/allwinner,sun8i-a83t-mipi-csi2.yaml | 147 ++
1 file changed, 147 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
diff --git
a/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
new file mode 100644
index ..78309084f904
--- /dev/null
+++
b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun8i-a83t-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A83T MIPI CSI-2 Device Tree Bindings
+
+maintainers:
+ - Paul Kocialkowski
+
+properties:
+ compatible:
+const: allwinner,sun8i-a83t-mipi-csi2
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Bus Clock
+ - description: Module Clock
+ - description: MIPI-specific Clock
+ - description: Misc CSI Clock
+
+ clock-names:
+items:
+ - const: bus
+ - const: mod
+ - const: mipi
+ - const: misc
+
+ resets:
+maxItems: 1
+
+ # See ./video-interfaces.txt for details
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: Input port, connect to a MIPI CSI-2 sensor
+
+properties:
+ reg:
+const: 0
+
+ endpoint:
+type: object
+
+properties:
+ remote-endpoint: true
+
+ clock-lanes:
+maxItems: 1
+
+ data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+ - data-lanes
+ - remote-endpoint
+
+required:
+ - endpoint
+
+additionalProperties: false
+
+ port@1:
+type: object
+description: Output port, connect to a CSI controller
+
+properties:
+ reg:
+const: 1
+
+ endpoint:
+type: object
+
+properties:
+ remote-endpoint: true
+
+ bus-type:
+const: 4
+
+required:
+ - endpoint
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+mipi_csi2: csi@1cb1000 {
+compatible = "allwinner,sun8i-a83t-mipi-csi2";
+reg = <0x01cb1000 0x1000>;
+interrupts = ;
+clocks = < CLK_BUS_CSI>,
+ < CLK_CSI_SCLK>,
+ < CLK_MIPI_CSI>,
+ < CLK_CSI_MISC>;
+clock-names = "bus", "mod", "mipi", "misc";
+resets = < RST_BUS_CSI>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi_csi2_in: port@0 {
+reg = <0>;
+
+mipi_csi2_in_ov8865: endpoint {
+data-lanes = <1 2 3 4>;
+
+remote-endpoint = <_out_mipi_csi2>;
+};
+};
+
+mipi_csi2_out: port@1 {
+reg = <1>;
+
+mipi_csi2_out_csi: endpoint {
+remote-endpoint = <_in_mipi_csi2>;
+};
+};
+};
+};
+
+...
--
2.29.2
--
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/20201128142839.517949-17-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 15/19] MAINTAINERS: Add entry for the Allwinner A31 MIPI CSI-2 bridge
Add myself as maintainer of the A31 MIPI CSI-2 bridge media driver. Signed-off-by: Paul Kocialkowski --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0644128640fb..a1352171778b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -709,6 +709,14 @@ T: git git://linuxtv.org/media_tree.git F: Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml F: drivers/media/platform/sunxi/sun4i-csi/ +ALLWINNER A31 MIPI CSI-2 BRIDGE +M: Paul Kocialkowski +L: linux-me...@vger.kernel.org +S: Maintained +T: git git://linuxtv.org/media_tree.git +F: Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml +F: drivers/media/platform/sunxi/sun6i-mipi-csi2/ + ALLWINNER CPUFREQ DRIVER M: Yangtao Li L: linux...@vger.kernel.org -- 2.29.2 -- 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/20201128142839.517949-16-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 14/19] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
MIPI CSI-2 is supported on the V3s with an A31-based MIPI CSI-2 bridge
controller. The controller uses a separate D-PHY, which is the same
that is otherwise used for MIPI DSI, but used in Rx mode.
On the V3s, the CSI0 controller is dedicated to MIPI CSI-2 as it does
not have access to any parallel interface pins.
Add all the necessary nodes (CSI0, MIPI CSI-2 bridge and D-PHY) to
support the MIPI CSI-2 interface.
Note that a fwnode graph link is created between CSI0 and MIPI CSI-2
even when no sensor is connected. This will result in a probe failure
for the controller as long as no sensor is connected but this is fine
since no other interface is available.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 68
1 file changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 7926c8b2ac5e..641da6c7bca0 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -530,6 +530,31 @@ spi0: spi@1c68000 {
#size-cells = <0>;
};
+ csi0: camera@1cb {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb 0x1000>;
+ interrupts = ;
+ clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>,
+< CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = < RST_BUS_CSI>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ csi0_in_mipi_csi2: endpoint {
+ remote-endpoint =
<_csi2_out_csi0>;
+ };
+ };
+ };
+ };
+
csi1: camera@1cb4000 {
compatible = "allwinner,sun8i-v3s-csi";
reg = <0x01cb4000 0x3000>;
@@ -561,5 +586,48 @@ gic: interrupt-controller@1c81000 {
#interrupt-cells = <3>;
interrupts = ;
};
+
+ mipi_csi2: csi@1cb1000 {
+ compatible = "allwinner,sun8i-v3s-mipi-csi2",
+"allwinner,sun6i-a31-mipi-csi2";
+ reg = <0x01cb1000 0x1000>;
+ interrupts = ;
+ clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>;
+ clock-names = "bus", "mod";
+ resets = < RST_BUS_CSI>;
+ status = "disabled";
+
+ phys = <>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_csi2_in: port@0 {
+ reg = <0>;
+ };
+
+ mipi_csi2_out: port@1 {
+ reg = <1>;
+
+ mipi_csi2_out_csi0: endpoint {
+ remote-endpoint =
<_in_mipi_csi2>;
+ };
+ };
+ };
+ };
+
+ dphy: d-phy@1cb2000 {
+ compatible = "allwinner,sun6i-a31-mipi-dphy";
+ reg = <0x01cb2000 0x1000>;
+ clocks = < CLK_BUS_CSI>,
+< CLK_MIPI_CSI>;
+ clock-names = "bus", "mod";
+ resets = < RST_BUS_CSI>;
+ status = "disabled";
+ #phy-cells = <0>;
+ };
};
};
--
2.29.2
--
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/20201128142839.517949-15-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 13/19] media: sunxi: Add support for the A31 MIPI CSI-2 controller
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 | 591 ++
.../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h | 117
6 files changed, 726 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 ..3260591ed5c0
--- /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 VIDEO_V4L2 && COMMON_CLK
+ depends on ARCH_SUNXI || COMPILE_TEST
+ select PHY_SUN6I_MIPI_DPHY
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
+ select REGMAP_MMIO
+ 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 ..a6567ef82fb4
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
@@ -0,0 +1,591 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Bootlin
+ * Author: Paul Kocialkowski
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sun6i_mipi_csi2.h"
+
+#define MODULE_NAME"sun6i-mipi-csi2"
+
+static const u32 sun6i_mipi_csi2_mbus_codes[] = {
+ MEDIA_BUS_FMT_SBGGR8_1X8,
+ MEDIA_BUS_FMT_SGBRG8_1X8,
+ MEDIA_BUS_FMT_SGRBG8_1X8,
+ MEDIA_BUS_FMT_SRGGB8_1X8,
+ MEDIA_BUS_FMT_SBGGR10_1X10,
+ MEDIA_BUS_FMT_SGBRG10_1X10,
+ MEDIA_BUS_FMT_SGRBG10_1X10,
+ MEDIA_BUS_FMT_SRGGB10_1X10,
+};
+
+/* Video */
+
+static int sun6i_mipi_csi2_s_stream(struct v4l2_subdev *subdev, int on)
+{
+ struct sun6i_mipi_csi2_video *video =
+ sun6i_mipi_csi2_subdev_video(subdev);
+ struct sun6i_mipi_csi2_dev *cdev = sun6i_mipi_csi2_video_dev(video);
+ struct v4l2_subdev *remote_subdev = video->remote_subdev;
+ struct v4l2_fwnode_bus_mipi_csi2 *bus_mipi_csi2 =
+ >endpoint.bus.mipi_csi2;
+ union phy_configure_opts dphy_opts = { 0 };
+ struct phy_configure_opts_mipi_dphy *dphy_cfg = _opts.mipi_dphy;
+ struct regmap *regmap = cdev->regmap;
+ struct v4l2_ctrl *ctrl;
+ unsigned int lanes_count;
+ unsigned int bpp;
+ unsigned long
[linux-sunxi] [PATCH v2 12/19] dt-bindings: media: Add A31 MIPI CSI-2 bindings documentation
This introduces YAML bindings documentation for the A31 MIPI CSI-2
controller.
Signed-off-by: Paul Kocialkowski
---
.../media/allwinner,sun6i-a31-mipi-csi2.yaml | 151 ++
1 file changed, 151 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
diff --git
a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
new file mode 100644
index ..917cd09d6fda
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A31 MIPI CSI-2 Device Tree Bindings
+
+maintainers:
+ - Paul Kocialkowski
+
+properties:
+ compatible:
+oneOf:
+ - const: allwinner,sun6i-a31-mipi-csi2
+ - items:
+ - const: allwinner,sun8i-v3s-mipi-csi2
+ - const: allwinner,sun6i-a31-mipi-csi2
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Bus Clock
+ - description: Module Clock
+
+ clock-names:
+items:
+ - const: bus
+ - const: mod
+
+ phys:
+items:
+ - description: MIPI D-PHY
+
+ phy-names:
+items:
+ - const: dphy
+
+ resets:
+maxItems: 1
+
+ # See ./video-interfaces.txt for details
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: Input port, connect to a MIPI CSI-2 sensor
+
+properties:
+ reg:
+const: 0
+
+ endpoint:
+type: object
+
+properties:
+ remote-endpoint: true
+
+ data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+ - data-lanes
+ - remote-endpoint
+
+required:
+ - endpoint
+
+additionalProperties: false
+
+ port@1:
+type: object
+description: Output port, connect to a CSI controller
+
+properties:
+ reg:
+const: 1
+
+ endpoint:
+type: object
+
+properties:
+ remote-endpoint: true
+
+required:
+ - endpoint
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+mipi_csi2: csi@1cb1000 {
+compatible = "allwinner,sun8i-v3s-mipi-csi2",
+ "allwinner,sun6i-a31-mipi-csi2";
+reg = <0x01cb1000 0x1000>;
+interrupts = ;
+clocks = < CLK_BUS_CSI>,
+ < CLK_CSI1_SCLK>;
+clock-names = "bus", "mod";
+resets = < RST_BUS_CSI>;
+
+phys = <>;
+phy-names = "dphy";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi_csi2_in: port@0 {
+reg = <0>;
+
+mipi_csi2_in_ov5648: endpoint {
+data-lanes = <1 2 3 4>;
+
+remote-endpoint = <_out_mipi_csi2>;
+};
+};
+
+mipi_csi2_out: port@1 {
+reg = <1>;
+
+mipi_csi2_out_csi0: endpoint {
+remote-endpoint = <_in_mipi_csi2>;
+};
+};
+};
+};
+
+...
--
2.29.2
--
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/20201128142839.517949-13-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 11/19] arm64: dts: allwinner: a64: Add CSI controller port for parallel input
Since the CSI controller binding is getting a bit more complex due
to the addition of MIPI CSI-2 bridge support, make the ports node
explicit with the parallel port.
This way, it's clear that the controller only supports parallel
interface input and there's no confusion about the port number.
Signed-off-by: Paul Kocialkowski
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 51cc30e84e26..1e1f0d2097d5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -1109,6 +1109,15 @@ csi: csi@1cb {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi_in_parallel: port@0 {
+ reg = <0>;
+ };
+ };
};
dsi: dsi@1ca {
--
2.29.2
--
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/20201128142839.517949-12-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 10/19] ARM: dts: sun8i: v3s: Add CSI1 controller port for parallel input
Since the CSI controller binding is getting a bit more complex due
to the addition of MIPI CSI-2 bridge support, make the ports node
explicit with the parallel port.
This way, it's clear that the controller only supports parallel
interface input and there's no confusion about the port number.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 7b2d684aeb97..7926c8b2ac5e 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -540,6 +540,15 @@ csi1: camera@1cb4000 {
clock-names = "bus", "mod", "ram";
resets = < RST_BUS_CSI>;
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_in_parallel: port@0 {
+ reg = <0>;
+ };
+ };
};
gic: interrupt-controller@1c81000 {
--
2.29.2
--
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/20201128142839.517949-11-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 09/19] ARM: dts: sunxi: h3/h5: Add CSI controller port for parallel input
Since the CSI controller binding is getting a bit more complex due
to the addition of MIPI CSI-2 bridge support, make the ports node
explicit with the parallel port.
This way, it's clear that the controller only supports parallel
interface input and there's no confusion about the port number.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 9be13378d4df..02b698cace6a 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -803,6 +803,15 @@ csi: camera@1cb {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi_in_parallel: port@0 {
+ reg = <0>;
+ };
+ };
};
hdmi: hdmi@1ee {
--
2.29.2
--
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/20201128142839.517949-10-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 08/19] ARM: dts: sun8i: a83t: Add CSI controller ports
Since the CSI controller binding is getting a bit more complex due
to the addition of MIPI CSI-2 bridge support, make the ports node
explicit with the parallel and MIPI CSI-2 bridge ports.
This way, it's clear that the controller supports both parallel and
MIPI CSI-2 interface inputs and there's no confusion about their port
number.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c010b27fdb6a..3ce030f7e05d 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -1062,7 +1062,17 @@ csi: camera@1cb {
resets = < RST_BUS_CSI>;
status = "disabled";
- csi_in: port {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi_in_parallel: port@0 {
+ reg = <0>;
+ };
+
+ csi_in_mipi_csi2_bridge: port@1 {
+ reg = <1>;
+ };
};
};
--
2.29.2
--
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/20201128142839.517949-9-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 07/19] media: sun6i-csi: Add support for MIPI CSI-2 bridge input
The A31 CSI controller supports a MIPI CSI-2 bridge input, which has
its own dedicated port in the fwnode graph.
Support for this input is added with this change:
- two pads are defined for the media entity instead of one
and only one needs to be connected at a time;
- the pads currently match the fwnode graph representation;
- links are created between our pads and the subdevs for each
interface and are no longer immutable so that userspace can select
which interface to use in case both are bound to a subdev;
- fwnode endpoints are parsed and stored for each interface;
- the active subdev (and fwnode endpoint) is retrieved when validating
the media link at stream on time and cleared at stream off;
- an error is raised if both links are active at the same time;
- the MIPI interface bit is set if the MIPI CSI-2 bridge endpoint is
active.
In the future, the media entity representation might evolve to:
- distinguish the internal parallel bridge and data formatter;
- represent each of the 4 internal channels that can exist between
the parallel bridge (for BT656 time-multiplex) and MIPI CSI-2
(internal channels can be mapped to virtual channels);
- connect the controller's output to the ISP instead of its
DMA engine.
Finally note that the MIPI CSI-2 bridges should not be linked in
the fwnode graph unless they have a sensor subdev attached.
Signed-off-by: Paul Kocialkowski
---
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 123 ++
.../platform/sunxi/sun6i-csi/sun6i_csi.h | 3 -
.../platform/sunxi/sun6i-csi/sun6i_video.c| 53
.../platform/sunxi/sun6i-csi/sun6i_video.h| 7 +-
4 files changed, 135 insertions(+), 51 deletions(-)
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index f1150de94e98..481181038e1e 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -52,15 +52,16 @@ bool sun6i_csi_is_format_supported(struct sun6i_csi *csi,
u32 pixformat, u32 mbus_code)
{
struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
+ struct v4l2_fwnode_endpoint *endpoint = sdev->csi.video.source_endpoint;
/*
* Some video receivers have the ability to be compatible with
* 8bit and 16bit bus width.
* Identify the media bus format from device tree.
*/
- if ((sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_PARALLEL
-|| sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_BT656)
-&& sdev->csi.v4l2_ep.bus.parallel.bus_width == 16) {
+ if ((endpoint->bus_type == V4L2_MBUS_PARALLEL
+|| endpoint->bus_type == V4L2_MBUS_BT656)
+&& endpoint->bus.parallel.bus_width == 16) {
switch (pixformat) {
case V4L2_PIX_FMT_HM12:
case V4L2_PIX_FMT_NV12:
@@ -373,7 +374,7 @@ static enum csi_input_seq get_csi_input_seq(struct
sun6i_csi_dev *sdev,
static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
{
- struct v4l2_fwnode_endpoint *endpoint = >csi.v4l2_ep;
+ struct v4l2_fwnode_endpoint *endpoint = sdev->csi.video.source_endpoint;
struct sun6i_csi *csi = >csi;
unsigned char bus_width;
u32 flags;
@@ -459,6 +460,9 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
cfg |= CSI_IF_CFG_CLK_POL_FALLING_EDGE;
break;
+ case V4L2_MBUS_CSI2_DPHY:
+ cfg |= CSI_IF_CFG_MIPI_IF_MIPI;
+ break;
default:
dev_warn(sdev->dev, "Unsupported bus type: %d\n",
endpoint->bus_type);
@@ -636,11 +640,11 @@ void sun6i_csi_set_stream(struct sun6i_csi *csi, bool
enable)
* Media Controller and V4L2
*/
static int sun6i_csi_link_entity(struct sun6i_csi *csi,
+struct media_pad *sink_pad,
struct media_entity *entity,
-struct fwnode_handle *fwnode)
+struct fwnode_handle *fwnode, bool enabled)
{
struct media_entity *sink;
- struct media_pad *sink_pad;
int src_pad_index;
int ret;
@@ -654,14 +658,12 @@ static int sun6i_csi_link_entity(struct sun6i_csi *csi,
src_pad_index = ret;
sink = >video.vdev.entity;
- sink_pad = >video.pad;
dev_dbg(csi->dev, "creating %s:%u -> %s:%u link\n",
entity->name, src_pad_index, sink->name, sink_pad->index);
ret = media_create_pad_link(entity, src_pad_index, sink,
sink_pad->index,
- MEDIA_LNK_FL_ENABLED |
- MEDIA_LNK_FL_IMMUTABLE);
+ enabled ? MEDIA_LNK_FL_ENABLED : 0);
if (ret < 0) {
[linux-sunxi] [PATCH v2 06/19] dt-bindings: media: sun6i-a31-csi: Add MIPI CSI-2 input port
The A31 CSI controller supports two distinct input interfaces:
parallel and an external MIPI CSI-2 bridge. The parallel interface
is often connected to a set of hardware pins while the MIPI CSI-2
bridge is an internal FIFO-ish link. As a result, these two inputs
are distinguished as two different ports.
Note that only one of the two may be present on a controller instance.
For example, the V3s has one controller dedicated to MIPI-CSI2 and one
dedicated to parallel.
Update the binding with an explicit ports node that holds two distinct
port nodes: one for parallel input and one for MIPI CSI-2.
This is backward-compatible with the single-port approach that was
previously taken for representing the parallel interface port, which
stays enumerated as fwnode port 0. However, it is now marked as
deprecated and the multi-port approach should be preferred.
Note that additional ports may be added in the future, especially to
support feeding the CSI controller's output to the ISP.
Signed-off-by: Paul Kocialkowski
---
.../media/allwinner,sun6i-a31-csi.yaml| 86 ---
1 file changed, 73 insertions(+), 13 deletions(-)
diff --git
a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
index 1fd9b5532a21..3bcee2d44f3c 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
@@ -43,6 +43,7 @@ properties:
# See ./video-interfaces.txt for details
port:
type: object
+deprecated: true
properties:
endpoint:
@@ -67,6 +68,59 @@ properties:
additionalProperties: false
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: Parallel input port, connect to a parallel sensor
+
+properties:
+ reg:
+const: 0
+
+ endpoint:
+type: object
+
+properties:
+ remote-endpoint: true
+
+ bus-width:
+enum: [ 8, 10, 12, 16 ]
+
+ pclk-sample: true
+ hsync-active: true
+ vsync-active: true
+
+required:
+ - bus-width
+ - remote-endpoint
+
+required:
+ - endpoint
+
+additionalProperties: false
+
+ port@1:
+type: object
+description: MIPI CSI-2 bridge input port
+
+properties:
+ reg:
+const: 1
+
+ endpoint:
+type: object
+
+properties:
+ remote-endpoint: true
+
+required:
+ - remote-endpoint
+
+additionalProperties: false
+
required:
- compatible
- reg
@@ -95,19 +149,25 @@ examples:
"ram";
resets = < RST_BUS_CSI>;
-port {
-/* Parallel bus endpoint */
-csi1_ep: endpoint {
-remote-endpoint = <_ep>;
-bus-width = <16>;
-
-/*
- * If hsync-active/vsync-active are missing,
- * embedded BT.656 sync is used.
- */
- hsync-active = <0>; /* Active low */
- vsync-active = <0>; /* Active low */
- pclk-sample = <1>; /* Rising */
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+/* Parallel bus endpoint */
+csi1_ep: endpoint {
+remote-endpoint = <_ep>;
+bus-width = <16>;
+
+/*
+ * If hsync-active/vsync-active are missing,
+ * embedded BT.656 sync is used.
+ */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ pclk-sample = <1>; /* Rising */
+};
};
};
};
--
2.29.2
--
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/20201128142839.517949-7-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 05/19] media: sun6i-csi: Only configure the interface data width for parallel
Bits related to the interface data width are only applicable to the
parallel interface and are irrelevant when the CSI controller is taking
input from the MIPI CSI-2 controller.
In prevision of adding support for this case, set these bits
conditionally so there is no ambiguity. The conditional block is
moved around before the interlaced conditional block for nicer code
symmetry (conditional blocks first) while at it.
Co-developed-by: Kévin L'hôpital
Signed-off-by: Kévin L'hôpital
Signed-off-by: Paul Kocialkowski
---
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 42 +++
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index 531a4cccd14a..f1150de94e98 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -378,8 +378,13 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
unsigned char bus_width;
u32 flags;
u32 cfg;
+ bool input_parallel = false;
bool input_interlaced = false;
+ if (endpoint->bus_type == V4L2_MBUS_PARALLEL ||
+ endpoint->bus_type == V4L2_MBUS_BT656)
+ input_parallel = true;
+
if (csi->config.field == V4L2_FIELD_INTERLACED
|| csi->config.field == V4L2_FIELD_INTERLACED_TB
|| csi->config.field == V4L2_FIELD_INTERLACED_BT)
@@ -395,6 +400,26 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
CSI_IF_CFG_HREF_POL_MASK | CSI_IF_CFG_FIELD_MASK |
CSI_IF_CFG_SRC_TYPE_MASK);
+ if (input_parallel) {
+ switch (bus_width) {
+ case 8:
+ cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
+ break;
+ case 10:
+ cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
+ break;
+ case 12:
+ cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
+ break;
+ case 16: /* No need to configure DATA_WIDTH for 16bit */
+ break;
+ default:
+ dev_warn(sdev->dev, "Unsupported bus width: %u\n",
+bus_width);
+ break;
+ }
+ }
+
if (input_interlaced)
cfg |= CSI_IF_CFG_SRC_TYPE_INTERLACED;
else
@@ -440,23 +465,6 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
break;
}
- switch (bus_width) {
- case 8:
- cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
- break;
- case 10:
- cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
- break;
- case 12:
- cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
- break;
- case 16: /* No need to configure DATA_WIDTH for 16bit */
- break;
- default:
- dev_warn(sdev->dev, "Unsupported bus width: %u\n", bus_width);
- break;
- }
-
regmap_write(sdev->regmap, CSI_IF_CFG_REG, cfg);
}
--
2.29.2
--
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/20201128142839.517949-6-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 04/19] media: sun6i-csi: Use common V4L2 format info for storage bpp
V4L2 has a common helper which can be used for calculating the number
of stored bits per pixels of a given (stored) image format.
Use the helper-returned structure instead of our own switch/case list.
Note that a few formats are not in that list so we keep them as
special cases.
The custom switch/case was also wrong concerning 10/12-bit Bayer
formats, which are aligned to 16 bits in memory. Using the common
helper fixes it.
Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
Signed-off-by: Paul Kocialkowski
---
.../platform/sunxi/sun6i-csi/sun6i_csi.h | 55 +++
1 file changed, 20 insertions(+), 35 deletions(-)
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
index c626821aaedb..092445f04c60 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
@@ -86,53 +86,38 @@ void sun6i_csi_update_buf_addr(struct sun6i_csi *csi,
dma_addr_t addr);
*/
void sun6i_csi_set_stream(struct sun6i_csi *csi, bool enable);
-/* get bpp form v4l2 pixformat */
+/* get memory storage bpp from v4l2 pixformat */
static inline int sun6i_csi_get_bpp(unsigned int pixformat)
{
+ const struct v4l2_format_info *info;
+ unsigned int i;
+ int bpp = 0;
+
+ /* Handle special cases unknown to V4L2 format info first. */
switch (pixformat) {
- case V4L2_PIX_FMT_SBGGR8:
- case V4L2_PIX_FMT_SGBRG8:
- case V4L2_PIX_FMT_SGRBG8:
- case V4L2_PIX_FMT_SRGGB8:
case V4L2_PIX_FMT_JPEG:
return 8;
- case V4L2_PIX_FMT_SBGGR10:
- case V4L2_PIX_FMT_SGBRG10:
- case V4L2_PIX_FMT_SGRBG10:
- case V4L2_PIX_FMT_SRGGB10:
- return 10;
- case V4L2_PIX_FMT_SBGGR12:
- case V4L2_PIX_FMT_SGBRG12:
- case V4L2_PIX_FMT_SGRBG12:
- case V4L2_PIX_FMT_SRGGB12:
case V4L2_PIX_FMT_HM12:
- case V4L2_PIX_FMT_NV12:
- case V4L2_PIX_FMT_NV21:
- case V4L2_PIX_FMT_YUV420:
- case V4L2_PIX_FMT_YVU420:
return 12;
- case V4L2_PIX_FMT_YUYV:
- case V4L2_PIX_FMT_YVYU:
- case V4L2_PIX_FMT_UYVY:
- case V4L2_PIX_FMT_VYUY:
- case V4L2_PIX_FMT_NV16:
- case V4L2_PIX_FMT_NV61:
- case V4L2_PIX_FMT_YUV422P:
- case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB565X:
return 16;
- case V4L2_PIX_FMT_RGB24:
- case V4L2_PIX_FMT_BGR24:
- return 24;
- case V4L2_PIX_FMT_RGB32:
- case V4L2_PIX_FMT_BGR32:
- return 32;
- default:
+ }
+
+ info = v4l2_format_info(pixformat);
+ if (!info) {
WARN(1, "Unsupported pixformat: 0x%x\n", pixformat);
- break;
+ return 0;
+ }
+
+ for (i = 0; i < info->comp_planes; i++) {
+ unsigned int hdiv = (i == 0) ? 1 : info->hdiv;
+ unsigned int vdiv = (i == 0) ? 1 : info->vdiv;
+
+ /* We return bits per pixel while V4L2 format info is bytes. */
+ bpp += 8 * info->bpp[i] / hdiv / vdiv;
}
- return 0;
+ return bpp;
}
#endif /* __SUN6I_CSI_H__ */
--
2.29.2
--
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/20201128142839.517949-5-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 02/19] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes
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/staging/media/rkisp1/rkisp1-isp.c | 3 ++-
include/linux/phy/phy-mipi-dphy.h | 13 +
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/rkisp1/rkisp1-isp.c
b/drivers/staging/media/rkisp1/rkisp1-isp.c
index a9715b0b7264..f1167995688a 100644
--- a/drivers/staging/media/rkisp1/rkisp1-isp.c
+++ b/drivers/staging/media/rkisp1/rkisp1-isp.c
@@ -914,7 +914,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.29.2
--
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/20201128142839.517949-3-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 03/19] phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI CSI-2
The Allwinner A31 D-PHY supports both Rx and Tx modes. While the latter
is already supported and used for MIPI DSI this adds support for the
former, to be used with MIPI CSI-2.
This implementation is inspired by Allwinner's V3s Linux SDK
implementation, which was used as a documentation base.
Signed-off-by: Paul Kocialkowski
---
drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 164 +++-
1 file changed, 160 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
index 1fa761ba6cbb..0389b6b670d6 100644
--- a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
+++ b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
@@ -24,6 +24,14 @@
#define SUN6I_DPHY_TX_CTL_REG 0x04
#define SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT BIT(28)
+#define SUN6I_DPHY_RX_CTL_REG 0x08
+#define SUN6I_DPHY_RX_CTL_EN_DBC BIT(31)
+#define SUN6I_DPHY_RX_CTL_RX_CLK_FORCE BIT(24)
+#define SUN6I_DPHY_RX_CTL_RX_D3_FORCE BIT(23)
+#define SUN6I_DPHY_RX_CTL_RX_D2_FORCE BIT(22)
+#define SUN6I_DPHY_RX_CTL_RX_D1_FORCE BIT(21)
+#define SUN6I_DPHY_RX_CTL_RX_D0_FORCE BIT(20)
+
#define SUN6I_DPHY_TX_TIME0_REG0x10
#define SUN6I_DPHY_TX_TIME0_HS_TRAIL(n)(((n) & 0xff) << 24)
#define SUN6I_DPHY_TX_TIME0_HS_PREPARE(n) (((n) & 0xff) << 16)
@@ -44,12 +52,29 @@
#define SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(n) (((n) & 0xff) << 8)
#define SUN6I_DPHY_TX_TIME4_HS_TX_ANA0(n) ((n) & 0xff)
+#define SUN6I_DPHY_RX_TIME0_REG0x30
+#define SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(n) (((n) & 0xff) << 24)
+#define SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(n) (((n) & 0xff) << 16)
+#define SUN6I_DPHY_RX_TIME0_LP_RX(n) (((n) & 0xff) << 8)
+
+#define SUN6I_DPHY_RX_TIME1_REG0x34
+#define SUN6I_DPHY_RX_TIME1_RX_DLY(n) (((n) & 0xfff) << 20)
+#define SUN6I_DPHY_RX_TIME1_LP_RX_ULPS_WP(n) ((n) & 0xf)
+
+#define SUN6I_DPHY_RX_TIME2_REG0x38
+#define SUN6I_DPHY_RX_TIME2_HS_RX_ANA1(n) (((n) & 0xff) << 8)
+#define SUN6I_DPHY_RX_TIME2_HS_RX_ANA0(n) ((n) & 0xff)
+
+#define SUN6I_DPHY_RX_TIME3_REG0x40
+#define SUN6I_DPHY_RX_TIME3_LPRST_DLY(n) (((n) & 0x) << 16)
+
#define SUN6I_DPHY_ANA0_REG0x4c
#define SUN6I_DPHY_ANA0_REG_PWSBIT(31)
#define SUN6I_DPHY_ANA0_REG_DMPC BIT(28)
#define SUN6I_DPHY_ANA0_REG_DMPD(n)(((n) & 0xf) << 24)
#define SUN6I_DPHY_ANA0_REG_SLV(n) (((n) & 7) << 12)
#define SUN6I_DPHY_ANA0_REG_DEN(n) (((n) & 0xf) << 8)
+#define SUN6I_DPHY_ANA0_REG_SFB(n) (((n) & 3) << 2)
#define SUN6I_DPHY_ANA1_REG0x50
#define SUN6I_DPHY_ANA1_REG_VTTMODEBIT(31)
@@ -92,6 +117,8 @@ struct sun6i_dphy {
struct phy *phy;
struct phy_configure_opts_mipi_dphy config;
+
+ int submode;
};
static int sun6i_dphy_init(struct phy *phy)
@@ -105,6 +132,18 @@ static int sun6i_dphy_init(struct phy *phy)
return 0;
}
+static int sun6i_dphy_set_mode(struct phy *phy, enum phy_mode mode, int
submode)
+{
+ struct sun6i_dphy *dphy = phy_get_drvdata(phy);
+
+ if (mode != PHY_MODE_MIPI_DPHY)
+ return -EINVAL;
+
+ dphy->submode = submode;
+
+ return 0;
+}
+
static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts
*opts)
{
struct sun6i_dphy *dphy = phy_get_drvdata(phy);
@@ -119,9 +158,8 @@ static int sun6i_dphy_configure(struct phy *phy, union
phy_configure_opts *opts)
return 0;
}
-static int sun6i_dphy_power_on(struct phy *phy)
+static int sun6i_dphy_tx_power_on(struct sun6i_dphy *dphy)
{
- struct sun6i_dphy *dphy = phy_get_drvdata(phy);
u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
regmap_write(dphy->regs, SUN6I_DPHY_TX_CTL_REG,
@@ -211,12 +249,129 @@ static int sun6i_dphy_power_on(struct phy *phy)
return 0;
}
+static int sun6i_dphy_rx_power_on(struct sun6i_dphy *dphy)
+{
+ /* Physical clock rate is actually half of symbol rate with DDR. */
+ unsigned long mipi_symbol_rate = dphy->config.hs_clk_rate;
+ unsigned long dphy_clk_rate;
+ unsigned int rx_dly;
+ unsigned int lprst_dly;
+ u32 value;
+
+ dphy_clk_rate = clk_get_rate(dphy->mod_clk);
+ if (!dphy_clk_rate)
+ return -EINVAL;
+
+ /* Hardcoded timing parameters from the Allwinner BSP. */
+ regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME0_REG,
+SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(255) |
+SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(255) |
+SUN6I_DPHY_RX_TIME0_LP_RX(255));
+
+ /*
+* Formula from the Allwinner BSP, with hardcoded coefficients
+* (probably internal divider/multiplier).
+*/
+ rx_dly = 8 * (unsigned
[linux-sunxi] [PATCH v2 01/19] docs: phy: Add a part about PHY mode and submode
Besides giving pointers to the relevant functions for PHY mode and submode configuration, this clarifies the need to set them before powering on the PHY. Signed-off-by: Paul Kocialkowski --- Documentation/driver-api/phy/phy.rst | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/driver-api/phy/phy.rst b/Documentation/driver-api/phy/phy.rst index 8fc1ce0bb905..6cbc72707a49 100644 --- a/Documentation/driver-api/phy/phy.rst +++ b/Documentation/driver-api/phy/phy.rst @@ -195,3 +195,21 @@ DeviceTree Binding The documentation for PHY dt binding can be found @ Documentation/devicetree/bindings/phy/phy-bindings.txt + +PHY Mode and Submode + + +Once a reference to a PHY is obtained by a controller, the PHY can be configured +to a PHY mode and submode. PHY modes are described in the `phy_mode` enum while +submodes are specific to the selected PHY mode. + +Mode and submode configuration is done by calling:: + + int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, int submode); + +If no submode is to be configured, users can call:: + + int phy_set_mode(struct phy *phy, enum phy_mode mode); + +The PHY mode and submode must not be configured after the PHY has already been +powered on. -- 2.29.2 -- 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/20201128142839.517949-2-paul.kocialkowski%40bootlin.com.
[linux-sunxi] [PATCH v2 00/19] Allwinner MIPI CSI-2 support for A31/V3s/A83T
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. Changes since v1: - reworked fwnode and media graph on the CSI controller end to have one port per interface, which solves the bus type representation issue; - removed unused IRQ handlers in the MIPI CSI-2 bridges; - avoided the use of devm_regmap_init_mmio_clk; - deasserted reset before enabling clocks; - fixed reported return code issues (ret |=, missing checks); - applied requested cosmetic changes (backward goto, etc); - switched over to runtime PM for the mipi csi-2 bridge drivers; - selected PHY_SUN6I_MIPI_DPHY in Kconfig for sun6i-mipi-csi2; - registered nodes with mipi csi-2 bridge subdevs; - used V4L2 format info instead of switch/case for sun6i-csi bpp; - fixed device-tree bindings as requested (useless properties, license); - fixed mipi bridge dt instances names; - added PHY API documentation about mode/power on order requirement; - fixed clock error return code in d-phy code; - fixed D-PHY mode check in d-phy code; - added MAINTAINERS entries for the new drivers; - added V4L2 compliance results; - added various comments and rework commit mesages as requested. V4L2 compliance runs are available below: # sun6i-csi + sun6i-mipi-csi2 + ov5648 v4l2-compliance SHA: not available, 32 bits Compliance test for sun6i-video device /dev/video0: Driver Info: Driver name : sun6i-video Card type: sun6i-csi Bus info : platform:camera Driver version : 5.10.0 Capabilities : 0x8421 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x0421 Video Capture Streaming Extended Pix Format Media Driver Info: Driver name : sun6i-csi Model: Allwinner Video Capture Device Serial : Bus info : platform:1cb.camera Media version: 5.10.0 Hardware revision: 0x (0) Driver version : 5.10.0 Interface Info: ID : 0x0304 Type : V4L Video Entity Info: ID : 0x0001 (1) Name : sun6i-csi Function : V4L2 I/O Pad 0x0102 : 0: Sink Pad 0x0103 : 1: Sink Link 0x020d: from remote pad 0x108 of entity 'sun6i-mipi-csi2': Data, Enabled Required ioctls: test MC information (see 'Media Driver Info' above): OK warn: v4l2-compliance.cpp(633): media bus_info 'platform:1cb.camera' differs from V4L2 bus_info 'platform:camera' test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video0 open: OK warn: v4l2-compliance.cpp(633): media bus_info 'platform:1cb.camera' differs from V4L2 bus_info 'platform:camera' test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls (Input 0): warn: v4l2-test-controls.cpp(92): Exposure: (max - min) % step != 0 warn: v4l2-test-controls.cpp(92): Gain: (max - min) % step != 0 warn: v4l2-test-controls.cpp(92): Exposure: (max - min) % step != 0 warn: v4l2-test-controls.cpp(92): Gain:
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月28日 GMT+08:00 下午7:54:04, "Clément Péron" 写到: >Hi Icenowy, > >On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng wrote: >> >> 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道： >> > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote: >> > > > > > > > Okay. But I'm not satisfied with a non-public sample >> > > > > > > > occupies >> > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a >> > > > > > > > pinetab-retail okay? >> > > > > > > >> > > > > > > To me, naming the production version anything but >"pinetab" >> > > > > > > isn't >> > > > > > > satisfying either. >> > > > > > >> > > > > > I understand where you're coming from, but the point I was >> > > > > > making my >> > > > > > previous mail is precisely that it's not really possible. >> > > > > > >> > > > > > You want to name the early adopter version _the_ production >> > > > > > version. Let's assume the hardware changes again between >the >> > > > > > early >> > > > > > adopter and mass-production version. Which one will be >_the_ >> > > > > > production version? The early-adopter or the mass-produced >> > > > > > one? >> > > > > > >> > > > > > There's really no good answer here, and both would suck in >> > > > > > their >> > > > > > own way. The only way to deal with this is to simply avoid >> > > > > > defining one version as the one true board, and just >loading >> > > > > > the >> > > > > > proper DT in u-boot based on whatever clue we have of the >> > > > > > hardware >> > > > > > revision. >> > > > > Then will it be okay to rename current pinetab DT to >> > > > > pinetab-sample and then introduce new DTs all with suffixes? >> > > > >> > > > No. From my previous mail: >> > > >> > > It can be seen as dropping the PineTab DT and introduce new DTs >> > > with >> > > suffix. >> > > >> > > Do we have rule that we cannot drop boards? >> > >> > Are you really arguing that removing a DT and then adding an >> > identical >> > one under a different name is not renaming it? >> >> Then we can just keep confusing name? > >Sorry maybe I missed some information >But why don't you do like pinephone? They're the same board revision with different LCD panels. And the major problem is that the DT for samples is already submitted under the name "PineTab". >sun50i-a64-pinetab-1.0.dts >sun50i-a64-pinetab-1.1.dts > >-dev is also a confusing name I think, as the board has been already >shipped. > >Regards, >Clement > > >> >> If we do so, how can we mark the new DT as "the user should use this >> one"? >> >> -- >> 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/1666a61f6ea3e7d573795f9000a0b096c7b7dee0.camel%40aosc.io. -- 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/C8F86F90-14BF-4857-9DB8-7968A34E4656%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
Hi Icenowy, On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng wrote: > > 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道： > > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote: > > > > > > > > Okay. But I'm not satisfied with a non-public sample > > > > > > > > occupies > > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a > > > > > > > > pinetab-retail okay? > > > > > > > > > > > > > > To me, naming the production version anything but "pinetab" > > > > > > > isn't > > > > > > > satisfying either. > > > > > > > > > > > > I understand where you're coming from, but the point I was > > > > > > making my > > > > > > previous mail is precisely that it's not really possible. > > > > > > > > > > > > You want to name the early adopter version _the_ production > > > > > > version. Let's assume the hardware changes again between the > > > > > > early > > > > > > adopter and mass-production version. Which one will be _the_ > > > > > > production version? The early-adopter or the mass-produced > > > > > > one? > > > > > > > > > > > > There's really no good answer here, and both would suck in > > > > > > their > > > > > > own way. The only way to deal with this is to simply avoid > > > > > > defining one version as the one true board, and just loading > > > > > > the > > > > > > proper DT in u-boot based on whatever clue we have of the > > > > > > hardware > > > > > > revision. > > > > > Then will it be okay to rename current pinetab DT to > > > > > pinetab-sample and then introduce new DTs all with suffixes? > > > > > > > > No. From my previous mail: > > > > > > It can be seen as dropping the PineTab DT and introduce new DTs > > > with > > > suffix. > > > > > > Do we have rule that we cannot drop boards? > > > > Are you really arguing that removing a DT and then adding an > > identical > > one under a different name is not renaming it? > > Then we can just keep confusing name? Sorry maybe I missed some information But why don't you do like pinephone? sun50i-a64-pinetab-1.0.dts sun50i-a64-pinetab-1.1.dts -dev is also a confusing name I think, as the board has been already shipped. Regards, Clement > > If we do so, how can we mark the new DT as "the user should use this > one"? > > -- > 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/1666a61f6ea3e7d573795f9000a0b096c7b7dee0.camel%40aosc.io. -- 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/CAJiuCcfEcM%2BDksm4uoRPCiRepDSnEmp7pr8Qk5EsFSH_zEOTYA%40mail.gmail.com.
Re: [linux-sunxi] [PATCH] sunxi: Add arm64 FEL support
在 2020-11-19星期四的 10:54 +，Andre Przywara写道：
> So far we did not support the BootROM based FEL USB debug mode on the
> 64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but
> the
> SPL runs in AArch64.
> Returning back to AArch32 was not working as expected, since the RMR
> reset into 32-bit mode always starts execution in the BootROM, but
> not
> in the FEL routine.
>
> After some debug and research and with help via IRC, the CPU hotplug
> mechanism emerged as a solution: If a certain R_CPUCFG register
> contains
> some magic, the BootROM will immediately branch to an address stored
> in
> some other register. This works well for our purposes.
>
> Enable the FEL feature by providing early AArch32 code to first save
> the
> FEL state, *before* initially entering AArch64.
> If we eventually determine that we should return to FEL, we reset
> back
> into AArch32, and use the CPU hotplug mechanism to run some small
> AArch32 code snippet that restores the initially saved FEL state.
>
> That allows the normal AArch64 SPL build to be loaded via the sunxi-
> fel
> tool, with it returning into FEL mode, so that other payloads can be
> transferred via FEL as well.
>
> Tested on A64, H5 and H6.
>
> Signed-off-by: Andre Przywara
Tested-by: Icenowy Zheng
> ---
> arch/arm/cpu/armv8/Makefile | 2 +
> arch/arm/cpu/armv8/fel_utils.S | 78
> +
> arch/arm/include/asm/arch-sunxi/boot0.h | 14 +
> include/configs/sunxi-common.h | 2 -
> 4 files changed, 94 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/cpu/armv8/fel_utils.S
>
> diff --git a/arch/arm/cpu/armv8/Makefile
> b/arch/arm/cpu/armv8/Makefile
> index 93d26f98568..f7b4a5ee46c 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -27,6 +27,8 @@ obj-$(CONFIG_ARM_SMCCC) += smccc-call.o
>
> ifndef CONFIG_SPL_BUILD
> obj-$(CONFIG_ARMV8_SPIN_TABLE) += spin_table.o spin_table_v8.o
> +else
> +obj-$(CONFIG_ARCH_SUNXI) += fel_utils.o
> endif
> obj-$(CONFIG_$(SPL_)ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o
> sec_firmware_asm.o
>
> diff --git a/arch/arm/cpu/armv8/fel_utils.S
> b/arch/arm/cpu/armv8/fel_utils.S
> new file mode 100644
> index 000..334fdef7fa0
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/fel_utils.S
> @@ -0,0 +1,78 @@
> +/*
> + * Utility functions for FEL mode, when running SPL in AArch64.
> + *
> + * Copyright (c) 2017 Arm Ltd.
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * We don't overwrite save_boot_params() here, to save the FEL state
> upon
> + * entry, since this would run *after* the RMR reset, which clobbers
> that
> + * state.
> + * Instead we store the state _very_ early in the boot0 hook,
> *before*
> + * resetting to AArch64.
> + */
> +
> +/*
> + * The FEL routines in BROM run in AArch32.
> + * Reset back into 32-bit mode here and restore the saved FEL state
> + * afterwards.
> + * Resetting back into AArch32/EL3 using the RMR always enters the
> BROM,
> + * but we can use the CPU hotplug mechanism to branch back to our
> code
> + * immediately.
> + */
> +ENTRY(return_to_fel)
> + /*
> + * the RMR reset will clear all registers, so save the
> arguments
> + * (LR and SP) in the fel_stash structure, which we read
> anyways later
> + */
> + adr x2, fel_stash
> + str w0, [x2]
> + str w1, [x2, #4]
> +
> + adr x1, fel_stash_addr // to find the fel_stash
> address in AA32
> + str w2, [x1]
> +
> + ldr x0, =0xfa50392f // CPU hotplug magic
> +#ifndef CONFIG_MACH_SUN50I_H6
> + ldr x2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU
> hotplug base
> + str w0, [x2, #0x8]
> +#else
> + ldr x2, =(SUNXI_RTC_BASE + 0x1b8) //
> BOOT_CPU_HP_FLAG_REG
> + str w0, [x2], #0x4
> +#endif
> + adr x0, back_in_32
> + str w0, [x2]
> +
> + dsb sy
> + isb sy
> + mov x0, #2 // RMR reset into AArch32
> + dsb sy
> + msr RMR_EL3, x0
> + isb sy
> +1: wfi
> + b 1b
> +
> +/* AArch32 code to restore the state from fel_stash and return back
> to FEL. */
> +back_in_32:
> + .word 0xe59f0028 // ldr r0, [pc, #40] ; load
> fel_stash address
> + .word 0xe5901008 // ldr r1, [r0, #8]
> + .word 0xe129f001 // msr CPSR_fc, r1
> + .word 0xf57ff06f // isb
> + .word 0xe590d000 // ldr sp, [r0]
> + .word 0xe590e004 // ldr lr, [r0, #4]
> + .word 0xe5901010 // ldr r1, [r0, #16]
> + .word 0xee0c1f10 // mcr 15, 0, r1, cr12, cr0, {0} ;
> VBAR
> + .word 0xe590100c // ldr r1, [r0, #12]
> + .word 0xee011f10 // mcr 15, 0, r1, cr1, cr0, {0} ;
> SCTLR
> + .word 0xf57ff06f // isb
> + .word 0xe12fff1e // bx lr ; return to
> FEL
>
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道： > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote: > > > > > > > Okay. But I'm not satisfied with a non-public sample > > > > > > > occupies > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a > > > > > > > pinetab-retail okay? > > > > > > > > > > > > To me, naming the production version anything but "pinetab" > > > > > > isn't > > > > > > satisfying either. > > > > > > > > > > I understand where you're coming from, but the point I was > > > > > making my > > > > > previous mail is precisely that it's not really possible. > > > > > > > > > > You want to name the early adopter version _the_ production > > > > > version. Let's assume the hardware changes again between the > > > > > early > > > > > adopter and mass-production version. Which one will be _the_ > > > > > production version? The early-adopter or the mass-produced > > > > > one? > > > > > > > > > > There's really no good answer here, and both would suck in > > > > > their > > > > > own way. The only way to deal with this is to simply avoid > > > > > defining one version as the one true board, and just loading > > > > > the > > > > > proper DT in u-boot based on whatever clue we have of the > > > > > hardware > > > > > revision. > > > > Then will it be okay to rename current pinetab DT to > > > > pinetab-sample and then introduce new DTs all with suffixes? > > > > > > No. From my previous mail: > > > > It can be seen as dropping the PineTab DT and introduce new DTs > > with > > suffix. > > > > Do we have rule that we cannot drop boards? > > Are you really arguing that removing a DT and then adding an > identical > one under a different name is not renaming it? Then we can just keep confusing name? If we do so, how can we mark the new DT as "the user should use this one"? -- 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/1666a61f6ea3e7d573795f9000a0b096c7b7dee0.camel%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote: > >> >> > Okay. But I'm not satisfied with a non-public sample occupies > >> >> > the pinetab name. Is rename it to pinetab-dev and add a > >> >> > pinetab-retail okay? > >> >> > >> >> To me, naming the production version anything but "pinetab" isn't > >> >> satisfying either. > >> > > >> >I understand where you're coming from, but the point I was making my > >> >previous mail is precisely that it's not really possible. > >> > > >> >You want to name the early adopter version _the_ production > >> >version. Let's assume the hardware changes again between the early > >> >adopter and mass-production version. Which one will be _the_ > >> >production version? The early-adopter or the mass-produced one? > >> > > >> >There's really no good answer here, and both would suck in their > >> >own way. The only way to deal with this is to simply avoid > >> >defining one version as the one true board, and just loading the > >> >proper DT in u-boot based on whatever clue we have of the hardware > >> >revision. > > > > > Then will it be okay to rename current pinetab DT to > > > pinetab-sample and then introduce new DTs all with suffixes? > > > > No. From my previous mail: > > It can be seen as dropping the PineTab DT and introduce new DTs with > suffix. > > Do we have rule that we cannot drop boards? Are you really arguing that removing a DT and then adding an identical one under a different name is not renaming it? -- 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/20201128103827.d6sfc2eumli2betx%40gilmour. signature.asc Description: PGP signature
