Re: [linux-sunxi] OV5640 camera module with A64

2020-12-07 Thread Chen-Yu Tsai 
On Tue, Dec 8, 2020 at 3:04 AM Faruk KILAVUZ  wrote:
>
> On 7.12.2020 18:43, Chen-Yu Tsai wrote:
>
> On Mon, Dec 7, 2020 at 11:34 PM Faruk KILAVUZ  
> wrote:
>
> Hello
> I am working on OV5640 with Allwinner A64  chip. I followed the steps at 
> https://linux-sunxi.org/CSI. I used kernel 5.10-rc6 and I compiled buildroot. 
> I tried to explain what I do step by step.
>
> 1- I activated this packages on kernel configuration;
> VIDEO_DEV = y
> MEDIA_CONTROLLER = y
> VIDEO_V4L2_SUBDEV_API = y
> V4L_PLATFORM_DRIVERS = y
> VIDEO_SUN6I_CSI = m
> VIDEO_OV5640 = m
>
> Also I enabled media-ctl and v4l2-ctl package on busybox.
>
>
> 2- I added i2c-csi and  node. Nodes are same as those used in pinetab.
>
> i2c-csi {
> compatible = "i2c-gpio";
> sda-gpios = < 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
> scl-gpios = < 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
> i2c-gpio,delay-us = <5>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> /* Rear camera */
> ov5640: camera@3c {
> compatible = "ovti,ov5640";
> reg = <0x3c>;
> pinctrl-names = "default";
> pinctrl-0 = <_mclk_pin>;
> clocks = < CLK_CSI_MCLK>;
> clock-names = "xclk";
>
> AVDD-supply = <_dldo3>;
> DOVDD-supply = <_aldo1>;
> DVDD-supply = <_eldo3>;
> reset-gpios = < 4 14 GPIO_ACTIVE_LOW>; /* PE14 */
> powerdown-gpios = < 4 15 GPIO_ACTIVE_HIGH>; /* 
> PE15 */
>
> port {
> ov5640_ep: endpoint {
> remote-endpoint = <_ep>;
> bus-width = <8>;
> hsync-active = <1>; /* Active high */
> vsync-active = <0>; /* Active low */
> data-active = <1>;  /* Active high */
> pclk-sample = <1>;  /* Rising */
> };
> };
> };
> };
>
> and
>
>  {
>
> status = "okay";
>
> port {
> csi_ep: endpoint {
> remote-endpoint = <_ep>;
> bus-width = <8>;
> hsync-active = <1>; /* Active high */
> vsync-active = <0>; /* Active low */
> data-active = <1>;  /* Active high */
> pclk-sample = <1>;  /* Rising */
> };
> };
> };
>
> 3- lsmod results:
>
> Module  Size  Used byNot tainted
> sr9700 20480  0
> dm9601 20480  0
> usbnet 40960  2 sr9700,dm9601
> snd_soc_simple_card24576  0
> sun50i_codec_analog32768  0
> snd_soc_simple_card_utils24576  1 snd_soc_simple_card
> sun8i_codec32768  0
> sun8i_adda_pr_regmap16384  1 sun50i_codec_analog
> sun4i_i2s  24576  0
> snd_soc_core  159744  5 
> snd_soc_simple_card,sun50i_codec_analog,snd_soc_simple_card_utils,sun8i_codec,sun4i_i2s
> axp20x_adc 20480  0
> snd_pcm_dmaengine  20480  1 snd_soc_core
> axp20x_usb_power   16384  0
> axp20x_ac_power16384  0
> axp20x_battery 16384  0
> pinctrl_axp209 16384  2
> industrialio   65536  4 
> axp20x_adc,axp20x_usb_power,axp20x_ac_power,axp20x_battery
> snd_pcm   106496  4 
> sun8i_codec,sun4i_i2s,snd_soc_core,snd_pcm_dmaengine
> i2c_mv64xxx24576  0
> sun6i_csi  36864  0
> snd_timer  40960  1 snd_pcm
> lima   57344  0
> snd65536  3 snd_soc_core,snd_pcm,snd_timer
> gpu_sched  28672  1 lima
> soundcore  16384  1 snd
> pwm_sun4i  20480  1
> sun8i_ce   28672  0
> crypto_engine  20480  1 sun8i_ce
> sun4i_drm  20480  1
> sun8i_mixer40960  0
> ov5640 28672  0
> v4l2_fwnode24576  2 sun6i_csi,ov5640
> panel_lvds 16384  0
> sun4i_frontend 16384  1 sun4i_drm
> pwm_bl 20480  0
> sun4i_tcon 36864  1 sun4i_drm
> sun8i_tcon_top 20480  2 sun4i_drm,sun4i_tcon
> cpufreq_dt 20480  0
>
> 4- media-ctl --print-topology result:
>
> Media controller API version 5.10.0
>
> Media device information
> 
> driver  cedrus
> model   cedrus
> serial
> bus infoplatform:cedrus
> hw revision 0x0
> driver version  5.10.0
>
> Device topology
> - entity 1: cedrus-source (1 pad, 1 link)
> type Node subtype V4L flags 0
> device node

Re: [linux-sunxi] Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

2020-12-07 Thread André Przywara 
On 03/12/2020 16:20, Chen-Yu Tsai wrote:

Hi,

> On Thu, Dec 3, 2020 at 11:45 PM André Przywara  wrote:
>>
>> On 03/12/2020 15:02, Chen-Yu Tsai wrote:
>>> On Thu, Dec 3, 2020 at 6:54 PM André Przywara  
>>> wrote:

 On 03/12/2020 03:16, Samuel Holland wrote:

 Hi,

> On 12/2/20 7:54 AM, Andre Przywara wrote:
> ...
>> +soc {
>> +compatible = "simple-bus";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges = <0x0 0x0 0x0 0x4000>;
>> +
>> +syscon: syscon@300 {
>> +compatible = "allwinner,sun50i-h616-system-control",
>> + "allwinner,sun50i-a64-system-control";
>> +reg = <0x0300 0x1000>;
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +
>> +sram_c: sram@28000 {
>> +compatible = "mmio-sram";
>> +reg = <0x00028000 0x3>;
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges = <0 0x00028000 0x3>;
>> +};
>> +
>> +sram_c1: sram@1a0 {
>> +compatible = "mmio-sram";
>> +reg = <0x01a0 0x20>;
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges = <0 0x01a0 0x20>;
>> +
>> +ve_sram: sram-section@0 {
>> +compatible = 
>> "allwinner,sun50i-h616-sram-c1",
>> + 
>> "allwinner,sun4i-a10-sram-c1";
>> +reg = <0x00 0x20>;
>> +};
>> +};
>> +};
>
> You mentioned that you could not find a SRAM A2. How were these SRAM 
> ranges
> verified? If you can load eGON.BT0 larger than 32 KiB, then presumably 
> NBROM
> uses SRAM C, and it is in the manual, but I see no mention of SRAM C1.

 The manual says that SRAM C *can* be used by "the system", at boot time,
 as long as it's configured correctly. I couldn't find any details on how
 to switch clock sources for SRAM C, and the manual stanza on this is
 quite gibberish. I presume it's configured either by BROM or by reset
 default this way. I think the idea is that the later users (VE, DE) take
 ownership at some point (which means we can't run any firmware in there).
 The BSP boot0 is 48KB already, so reaching into SRAM C, and the code
 itself heavily uses SRAM C (found by hacking boot0 to drop to FEL and
 inspecting the memory afterwards).

 For C1: I copied this name from the H6 .dtsi, the manual calls this
 "VE-SRAM", in both manuals, and the description looks identical there
 for both SoCs. I think this will be later used by the video engine, so I
 kept it in. The large size made me suspicious, and from former
 experiments it looks like being aliased to (parts of) SRAM C.
>>>
>>> I would just call it sram_ve or ve_sram. SRAM C1 would make more sense if
>>> it were part of SRAM C, not the other way around.
>>
>> But isn't that what we do? "sram_c1" is just the node name alias used
>> for the parent node. That is actually never referenced anywhere (in any
>> of the the H6 .dts), so we can actually remove it, I guess.
>> The actual SRAM section is called ve_sram already.
> 
> This is what I had in mind:
> 
> syscon: {
> sram_c: sram@28000 {
> compatible = "mmio-sram";
> reg = <0x00028000 0x3>;
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0x00028000 0x3>;
> 
> /* starting address might not be correct */
> sram_c_ve: sram-section@0 {
> compatible = "allwinner,sun50i-h616-ve-sram-c",
>  "allwinner,sun4i-a10-sram-c1";
>/* 64 kiB borrowed from ve_sram */
> reg = <0x0 0x1>;
> };
> };
> 
> ve_sram: sram@1a0 {
> compatible = "mmio-sram";
> reg = <0x01a0 0x20>;
> #address-cells = <1>;
> #size-cells = <1>;
> };
> };

OK, I am taking this version, but am dropping the sram_c_ve subnode,
until we know where it is, what we actually need and until we can test it.

> Another variant, trying to describe the aliasing, though it seems
> quite confusing:

I don't know

Re: [linux-sunxi] OV5640 camera module with A64

2020-12-07 Thread Faruk KILAVUZ 
On 7.12.2020 18:43, Chen-Yu Tsai wrote:

On Mon, Dec 7, 2020 at 11:34 PM Faruk KILAVUZ 
 wrote:



Hello
I am working on OV5640 with Allwinner A64  chip. I followed the steps at 
https://linux-sunxi.org/CSI. I used kernel 5.10-rc6 and I compiled buildroot. I 
tried to explain what I do step by step.

1- I activated this packages on kernel configuration;
VIDEO_DEV = y
MEDIA_CONTROLLER = y
VIDEO_V4L2_SUBDEV_API = y
V4L_PLATFORM_DRIVERS = y
VIDEO_SUN6I_CSI = m
VIDEO_OV5640 = m

Also I enabled media-ctl and v4l2-ctl package on busybox.


2- I added i2c-csi and  node. Nodes are same as those used in pinetab.

i2c-csi {
compatible = "i2c-gpio";
sda-gpios = < 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
scl-gpios = < 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
i2c-gpio,delay-us = <5>;
#address-cells = <1>;
#size-cells = <0>;

/* Rear camera */
ov5640: camera@3c {
compatible = "ovti,ov5640";
reg = <0x3c>;
pinctrl-names = "default";
pinctrl-0 = <_mclk_pin>;
clocks = < CLK_CSI_MCLK>;
clock-names = "xclk";

AVDD-supply = <_dldo3>;
DOVDD-supply = <_aldo1>;
DVDD-supply = <_eldo3>;
reset-gpios = < 4 14 GPIO_ACTIVE_LOW>; /* PE14 */
powerdown-gpios = < 4 15 GPIO_ACTIVE_HIGH>; /* PE15 
*/

port {
ov5640_ep: endpoint {
remote-endpoint = <_ep>;
bus-width = <8>;
hsync-active = <1>; /* Active high */
vsync-active = <0>; /* Active low */
data-active = <1>;  /* Active high */
pclk-sample = <1>;  /* Rising */
};
};
};
};

and

 {

status = "okay";

port {
csi_ep: endpoint {
remote-endpoint = <_ep>;
bus-width = <8>;
hsync-active = <1>; /* Active high */
vsync-active = <0>; /* Active low */
data-active = <1>;  /* Active high */
pclk-sample = <1>;  /* Rising */
};
};
};

3- lsmod results:

Module  Size  Used byNot tainted
sr9700 20480  0
dm9601 20480  0
usbnet 40960  2 sr9700,dm9601
snd_soc_simple_card24576  0
sun50i_codec_analog32768  0
snd_soc_simple_card_utils24576  1 snd_soc_simple_card
sun8i_codec32768  0
sun8i_adda_pr_regmap16384  1 sun50i_codec_analog
sun4i_i2s  24576  0
snd_soc_core  159744  5 
snd_soc_simple_card,sun50i_codec_analog,snd_soc_simple_card_utils,sun8i_codec,sun4i_i2s
axp20x_adc 20480  0
snd_pcm_dmaengine  20480  1 snd_soc_core
axp20x_usb_power   16384  0
axp20x_ac_power16384  0
axp20x_battery 16384  0
pinctrl_axp209 16384  2
industrialio   65536  4 
axp20x_adc,axp20x_usb_power,axp20x_ac_power,axp20x_battery
snd_pcm   106496  4 
sun8i_codec,sun4i_i2s,snd_soc_core,snd_pcm_dmaengine
i2c_mv64xxx24576  0
sun6i_csi  36864  0
snd_timer  40960  1 snd_pcm
lima   57344  0
snd65536  3 snd_soc_core,snd_pcm,snd_timer
gpu_sched  28672  1 lima
soundcore  16384  1 snd
pwm_sun4i  20480  1
sun8i_ce   28672  0
crypto_engine  20480  1 sun8i_ce
sun4i_drm  20480  1
sun8i_mixer40960  0
ov5640 28672  0
v4l2_fwnode24576  2 sun6i_csi,ov5640
panel_lvds 16384  0
sun4i_frontend 16384  1 sun4i_drm
pwm_bl 20480  0
sun4i_tcon 36864  1 sun4i_drm
sun8i_tcon_top 20480  2 sun4i_drm,sun4i_tcon
cpufreq_dt 20480  0

4- media-ctl --print-topology result:

Media controller API version 5.10.0

Media device information

driver  cedrus
model   cedrus
serial
bus infoplatform:cedrus
hw revision 0x0
driver version  5.10.0

Device topology
- entity 1: cedrus-source (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Source
-> "cedrus-proc":0 [ENABLED,IMMUTABLE]

- entity 3: cedrus-proc (2 pads, 2 links)
type Node subtype Unknown flags 0
pad0: Sink
<- "cedrus-source":0 [ENABLED,IMMUTABLE]
pad1: Source
-> "cedrus-sink":0

[linux-sunxi] Re: [PATCH] sunxi: Add arm64 FEL support

2020-12-07 Thread Jagan Teki 
On Thu, Nov 19, 2020 at 4:24 PM Andre Przywara  wrote:
>
> 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 
> ---

Acked-by: Jagan Teki 

-- 
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/CAMty3ZCntuSMZkBRkY4QAAvFUbftHYGhF9mTLPoqemwpeKWXSA%40mail.gmail.com.

Re: [linux-sunxi] OV5640 camera module with A64

2020-12-07 Thread Chen-Yu Tsai 
On Mon, Dec 7, 2020 at 11:34 PM Faruk KILAVUZ  wrote:
>
> Hello
> I am working on OV5640 with Allwinner A64  chip. I followed the steps at 
> https://linux-sunxi.org/CSI. I used kernel 5.10-rc6 and I compiled buildroot. 
> I tried to explain what I do step by step.
>
> 1- I activated this packages on kernel configuration;
> VIDEO_DEV = y
> MEDIA_CONTROLLER = y
> VIDEO_V4L2_SUBDEV_API = y
> V4L_PLATFORM_DRIVERS = y
> VIDEO_SUN6I_CSI = m
> VIDEO_OV5640 = m
>
> Also I enabled media-ctl and v4l2-ctl package on busybox.
>
>
> 2- I added i2c-csi and  node. Nodes are same as those used in pinetab.
>
> i2c-csi {
> compatible = "i2c-gpio";
> sda-gpios = < 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
> scl-gpios = < 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
> i2c-gpio,delay-us = <5>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> /* Rear camera */
> ov5640: camera@3c {
> compatible = "ovti,ov5640";
> reg = <0x3c>;
> pinctrl-names = "default";
> pinctrl-0 = <_mclk_pin>;
> clocks = < CLK_CSI_MCLK>;
> clock-names = "xclk";
>
> AVDD-supply = <_dldo3>;
> DOVDD-supply = <_aldo1>;
> DVDD-supply = <_eldo3>;
> reset-gpios = < 4 14 GPIO_ACTIVE_LOW>; /* PE14 */
> powerdown-gpios = < 4 15 GPIO_ACTIVE_HIGH>; /* 
> PE15 */
>
> port {
> ov5640_ep: endpoint {
> remote-endpoint = <_ep>;
> bus-width = <8>;
> hsync-active = <1>; /* Active high */
> vsync-active = <0>; /* Active low */
> data-active = <1>;  /* Active high */
> pclk-sample = <1>;  /* Rising */
> };
> };
> };
> };
>
> and
>
>  {
>
> status = "okay";
>
> port {
> csi_ep: endpoint {
> remote-endpoint = <_ep>;
> bus-width = <8>;
> hsync-active = <1>; /* Active high */
> vsync-active = <0>; /* Active low */
> data-active = <1>;  /* Active high */
> pclk-sample = <1>;  /* Rising */
> };
> };
> };
>
> 3- lsmod results:
>
> Module  Size  Used byNot tainted
> sr9700 20480  0
> dm9601 20480  0
> usbnet 40960  2 sr9700,dm9601
> snd_soc_simple_card24576  0
> sun50i_codec_analog32768  0
> snd_soc_simple_card_utils24576  1 snd_soc_simple_card
> sun8i_codec32768  0
> sun8i_adda_pr_regmap16384  1 sun50i_codec_analog
> sun4i_i2s  24576  0
> snd_soc_core  159744  5 
> snd_soc_simple_card,sun50i_codec_analog,snd_soc_simple_card_utils,sun8i_codec,sun4i_i2s
> axp20x_adc 20480  0
> snd_pcm_dmaengine  20480  1 snd_soc_core
> axp20x_usb_power   16384  0
> axp20x_ac_power16384  0
> axp20x_battery 16384  0
> pinctrl_axp209 16384  2
> industrialio   65536  4 
> axp20x_adc,axp20x_usb_power,axp20x_ac_power,axp20x_battery
> snd_pcm   106496  4 
> sun8i_codec,sun4i_i2s,snd_soc_core,snd_pcm_dmaengine
> i2c_mv64xxx24576  0
> sun6i_csi  36864  0
> snd_timer  40960  1 snd_pcm
> lima   57344  0
> snd65536  3 snd_soc_core,snd_pcm,snd_timer
> gpu_sched  28672  1 lima
> soundcore  16384  1 snd
> pwm_sun4i  20480  1
> sun8i_ce   28672  0
> crypto_engine  20480  1 sun8i_ce
> sun4i_drm  20480  1
> sun8i_mixer40960  0
> ov5640 28672  0
> v4l2_fwnode24576  2 sun6i_csi,ov5640
> panel_lvds 16384  0
> sun4i_frontend 16384  1 sun4i_drm
> pwm_bl 20480  0
> sun4i_tcon 36864  1 sun4i_drm
> sun8i_tcon_top 20480  2 sun4i_drm,sun4i_tcon
> cpufreq_dt 20480  0
>
> 4- media-ctl --print-topology result:
>
> Media controller API version 5.10.0
>
> Media device information
> 
> driver  cedrus
> model   cedrus
> serial
> bus infoplatform:cedrus
> hw revision 0x0
> driver version  5.10.0
>
> Device topology
> - entity 1: cedrus-source (1 pad, 1 link)
> type Node subtype V4L flags 0
> device node name /dev/video0
> pad0: Source
> -> "cedrus-proc":0 [ENABLED,IMMUTABLE]
>
> - entity 3:

[linux-sunxi] OV5640 camera module with A64

2020-12-07 Thread Faruk KILAVUZ 
Hello
I am working on OV5640 with Allwinner A64  chip. I followed the steps at 
https://linux-sunxi.org/CSI. I used kernel 5.10-rc6 and I compiled buildroot. I 
tried to explain what I do step by step.

1- I activated this packages on kernel configuration;
VIDEO_DEV = y
MEDIA_CONTROLLER = y
VIDEO_V4L2_SUBDEV_API = y
V4L_PLATFORM_DRIVERS = y
VIDEO_SUN6I_CSI = m
VIDEO_OV5640 = m

Also I enabled media-ctl and v4l2-ctl package on busybox.

2- I added i2c-csi and  node. Nodes are same as those used in pinetab.

i2c-csi {
compatible = "i2c-gpio";
sda-gpios = < 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
scl-gpios = < 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
i2c-gpio,delay-us = <5>;
#address-cells = <1>;
#size-cells = <0>;

/* Rear camera */
ov5640: camera@3c {
compatible = "ovti,ov5640";
reg = <0x3c>;
pinctrl-names = "default";
pinctrl-0 = <_mclk_pin>;
clocks = < CLK_CSI_MCLK>;
clock-names = "xclk";

AVDD-supply = <_dldo3>;
DOVDD-supply = <_aldo1>;
DVDD-supply = <_eldo3>;
reset-gpios = < 4 14 GPIO_ACTIVE_LOW>; /* PE14 */
powerdown-gpios = < 4 15 GPIO_ACTIVE_HIGH>; /* PE15 
*/

port {
ov5640_ep: endpoint {
remote-endpoint = <_ep>;
bus-width = <8>;
hsync-active = <1>; /* Active high */
vsync-active = <0>; /* Active low */
data-active = <1>;  /* Active high */
pclk-sample = <1>;  /* Rising */
};
};
};
};

and

 {

status = "okay";

port {
csi_ep: endpoint {
remote-endpoint = <_ep>;
bus-width = <8>;
hsync-active = <1>; /* Active high */
vsync-active = <0>; /* Active low */
data-active = <1>;  /* Active high */
pclk-sample = <1>;  /* Rising */
};
};
};


3- lsmod results:

Module  Size  Used byNot tainted
sr9700 20480  0
dm9601 20480  0
usbnet 40960  2 sr9700,dm9601
snd_soc_simple_card24576  0
sun50i_codec_analog32768  0
snd_soc_simple_card_utils24576  1 snd_soc_simple_card
sun8i_codec32768  0
sun8i_adda_pr_regmap16384  1 sun50i_codec_analog
sun4i_i2s  24576  0
snd_soc_core  159744  5 
snd_soc_simple_card,sun50i_codec_analog,snd_soc_simple_card_utils,sun8i_codec,sun4i_i2s
axp20x_adc 20480  0
snd_pcm_dmaengine  20480  1 snd_soc_core
axp20x_usb_power   16384  0
axp20x_ac_power16384  0
axp20x_battery 16384  0
pinctrl_axp209 16384  2
industrialio   65536  4 
axp20x_adc,axp20x_usb_power,axp20x_ac_power,axp20x_battery
snd_pcm   106496  4 
sun8i_codec,sun4i_i2s,snd_soc_core,snd_pcm_dmaengine
i2c_mv64xxx24576  0
sun6i_csi  36864  0
snd_timer  40960  1 snd_pcm
lima   57344  0
snd65536  3 snd_soc_core,snd_pcm,snd_timer
gpu_sched  28672  1 lima
soundcore  16384  1 snd
pwm_sun4i  20480  1
sun8i_ce   28672  0
crypto_engine  20480  1 sun8i_ce
sun4i_drm  20480  1
sun8i_mixer40960  0
ov5640 28672  0
v4l2_fwnode24576  2 sun6i_csi,ov5640
panel_lvds 16384  0
sun4i_frontend 16384  1 sun4i_drm
pwm_bl 20480  0
sun4i_tcon 36864  1 sun4i_drm
sun8i_tcon_top 20480  2 sun4i_drm,sun4i_tcon
cpufreq_dt 20480  0


4- media-ctl --print-topology result:

Media controller API version 5.10.0

Media device information

driver  cedrus
model   cedrus
serial
bus infoplatform:cedrus
hw revision 0x0
driver version  5.10.0

Device topology
- entity 1: cedrus-source (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Source
-> "cedrus-proc":0 [ENABLED,IMMUTABLE]

- entity 3: cedrus-proc (2 pads, 2 links)
type Node subtype Unknown flags 0
pad0: Sink
<- "cedrus-source":0 [ENABLED,IMMUTABLE]
pad1: Source
-> "cedrus-sink":0 [ENABLED,IMMUTABLE]

- entity 6: cedrus-sink (1 pad, 1 link)
type Node subtype V4L flags 0
device node name

[linux-sunxi] OV5640 Camera Module on Allwinner A64

2020-12-07 Thread Faruk KILAVUZ 
Hello
I am working on OV5640 with Allwinner A64  chip. I followed the steps at 
https://linux-sunxi.org/CSI. I used kernel 5.10-rc6 and I compiled buildroot. I 
tried to explain what I do step by step.

1- I activated this packages on kernel configuration;
VIDEO_DEV = y
MEDIA_CONTROLLER = y
VIDEO_V4L2_SUBDEV_API = y
V4L_PLATFORM_DRIVERS = y
VIDEO_SUN6I_CSI = m
VIDEO_OV5640 = m

Also I enabled media-ctl and v4l2-ctl package on busybox.

2- I added i2c-csi and  node. Nodes are same as those used in pinetab.

i2c-csi {
compatible = "i2c-gpio";
sda-gpios = < 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
scl-gpios = < 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
i2c-gpio,delay-us = <5>;
#address-cells = <1>;
#size-cells = <0>;

/* Rear camera */
ov5640: camera@3c {
compatible = "ovti,ov5640";
reg = <0x3c>;
pinctrl-names = "default";
pinctrl-0 = <_mclk_pin>;
clocks = < CLK_CSI_MCLK>;
clock-names = "xclk";

AVDD-supply = <_dldo3>;
DOVDD-supply = <_aldo1>;
DVDD-supply = <_eldo3>;
reset-gpios = < 4 14 GPIO_ACTIVE_LOW>; /* PE14 */
powerdown-gpios = < 4 15 GPIO_ACTIVE_HIGH>; /* PE15 
*/

port {
ov5640_ep: endpoint {
remote-endpoint = <_ep>;
bus-width = <8>;
hsync-active = <1>; /* Active high */
vsync-active = <0>; /* Active low */
data-active = <1>;  /* Active high */
pclk-sample = <1>;  /* Rising */
};
};
};
};

and

 {

status = "okay";

port {
csi_ep: endpoint {
remote-endpoint = <_ep>;
bus-width = <8>;
hsync-active = <1>; /* Active high */
vsync-active = <0>; /* Active low */
data-active = <1>;  /* Active high */
pclk-sample = <1>;  /* Rising */
};
};
};


3- lsmod results:

Module  Size  Used byNot tainted
sr9700 20480  0
dm9601 20480  0
usbnet 40960  2 sr9700,dm9601
snd_soc_simple_card24576  0
sun50i_codec_analog32768  0
snd_soc_simple_card_utils24576  1 snd_soc_simple_card
sun8i_codec32768  0
sun8i_adda_pr_regmap16384  1 sun50i_codec_analog
sun4i_i2s  24576  0
snd_soc_core  159744  5 
snd_soc_simple_card,sun50i_codec_analog,snd_soc_simple_card_utils,sun8i_codec,sun4i_i2s
axp20x_adc 20480  0
snd_pcm_dmaengine  20480  1 snd_soc_core
axp20x_usb_power   16384  0
axp20x_ac_power16384  0
axp20x_battery 16384  0
pinctrl_axp209 16384  2
industrialio   65536  4 
axp20x_adc,axp20x_usb_power,axp20x_ac_power,axp20x_battery
snd_pcm   106496  4 
sun8i_codec,sun4i_i2s,snd_soc_core,snd_pcm_dmaengine
i2c_mv64xxx24576  0
sun6i_csi  36864  0
snd_timer  40960  1 snd_pcm
lima   57344  0
snd65536  3 snd_soc_core,snd_pcm,snd_timer
gpu_sched  28672  1 lima
soundcore  16384  1 snd
pwm_sun4i  20480  1
sun8i_ce   28672  0
crypto_engine  20480  1 sun8i_ce
sun4i_drm  20480  1
sun8i_mixer40960  0
ov5640 28672  0
v4l2_fwnode24576  2 sun6i_csi,ov5640
panel_lvds 16384  0
sun4i_frontend 16384  1 sun4i_drm
pwm_bl 20480  0
sun4i_tcon 36864  1 sun4i_drm
sun8i_tcon_top 20480  2 sun4i_drm,sun4i_tcon
cpufreq_dt 20480  0


4- media-ctl --print-topology result:

Media controller API version 5.10.0

Media device information

driver  cedrus
model   cedrus
serial
bus infoplatform:cedrus
hw revision 0x0
driver version  5.10.0

Device topology
- entity 1: cedrus-source (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Source
-> "cedrus-proc":0 [ENABLED,IMMUTABLE]

- entity 3: cedrus-proc (2 pads, 2 links)
type Node subtype Unknown flags 0
pad0: Sink
<- "cedrus-source":0 [ENABLED,IMMUTABLE]
pad1: Source
-> "cedrus-sink":0 [ENABLED,IMMUTABLE]

- entity 6: cedrus-sink (1 pad, 1 link)
type Node subtype V4L flags 0
device node name

Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample

2020-12-07 Thread Maxime Ripard 
On Sun, Dec 06, 2020 at 10:03:16PM +0100, Clément Péron wrote:
> Hi Maxime
> 
> On Tue, 1 Dec 2020 at 11:35, Maxime Ripard  wrote:
> >
> > On Sat, Nov 28, 2020 at 10:07:27PM +0100, Clément Péron wrote:
> > > 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.
> >
> > Like you said, it can happen pretty much any time, for any reason, so
> > the intent doesn't really matter here.
> 
> Agree, that was more to support Pin64 guys here.
> 
> As pinetab compatible can't be reused maybe somethings like this :
> sun50i-a64-pinetab.dtsi
> sun50i-a64-pinetab-1.0-early-adopter.dtb
> sun50i-a64-pinetab-1.0.dtb or sun50i-a64-pinetab-retail.dtb. But
> retail is like prod it's not explicit.
> 
> What do you think ?

I already said what I think multiple times in this thread: the DT that
has been merged for the early adopter, devs, whatever, won't be renamed.
As far as I'm concerned, I don't care about the name that is picked for
the new version as long as everyone is clear on the fact that that name
won't change ever either.

Maxime

-- 
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/20201207100703.tfavhmexbtrzucry%40gilmour.


signature.asc
Description: PGP signature