Date   

Re: Is cadence-quadspi working on cyclone V?

Nobuhiro Iwamatsu
 

Hi Koguchi-san,

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of Takuo Koguchi
Sent: Monday, March 15, 2021 1:33 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Is cadence-quadspi working on cyclone V?

Hi Pavel,

Git bisect has told me the first bad commit is
31fb632b5d43 spi: Move cadence-quadspi driver to drivers/spi/
That's strange.

Does this change requires device tree modification?
Any suggestions or comments would be appreciated.
...because that particular change does not change any C code. But it
touches Kconfig bits; can you check that CONFIG_SPI_CADENCE_QUADSPI is
enabled in the "bad" configuration?

Do you have any local changes in
drivers/mtd/spi-nor/controllers/cadence-quadspi.c or
drivers/spi/spi-cadence-quadspi.c ?
I have no local changes to those files.
Maybe I lost CONFIG_SPI_CADENCE_QUADSPI accidentally while bisecting.
I will try bisect and post the result again.
I redo the bisect and get the following result;
# first bad commit: [a314f6367787ee1d767df9a2120f17e4511144d0] mtd: spi-nor: Convert cadence-quadspi to use spi-mem
framework

It contains significant amount of changes;

cadence-quadspi.c | 476 +++++++++++++++++++++---------------------------------
1 file changed, 191 insertions(+), 285 deletions(-)

With this change, cpspi_probe return 0 without any error messages, but it does not detect NOR flash on a custom cyclone
V board.

Any information will be appreciated.
I checked on a Sodia board with the same SoC.
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/tree/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts?h=linux-5.10.y-cip

It recognizes NOR flash in 5.10.y. How about checking DTS?
Sodia board uses n25q512a and has the following DT:
```
&qspi {
status = "okay";

flash0: n25q512a@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "n25q512a";
reg = <0>;
spi-max-frequency = <100000000>;

m25p,fast-read;
cdns,page-size = <256>;
cdns,block-size = <16>;
cdns,read-delay = <4>;
cdns,tshsl-ns = <50>;
cdns,tsd2d-ns = <50>;
cdns,tchsh-ns = <4>;
cdns,tslch-ns = <4>;
};
};
```

Thanks,

Takuo Koguchi
Best regards,
Nobuhiro


-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO
Sent: Sunday, March 14, 2021 4:37 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [!]Re: [cip-dev] Is cadence-quadspi working on cyclone V?

Hi Pavel,
Thank you for the response.

Git bisect has told me the first bad commit is
31fb632b5d43 spi: Move cadence-quadspi driver to drivers/spi
That's strange.

Does this change requires device tree modification?
Any suggestions or comments would be appreciated.
...because that particular change does not change any C code. But it
touches Kconfig bits; can you check that CONFIG_SPI_CADENCE_QUADSPI is
enabled in the "bad" configuration?

Do you have any local changes in
drivers/mtd/spi-nor/controllers/cadence-quadspi.c or
drivers/spi/spi-cadence-quadspi.c ?
I have no local changes to those files.
Maybe I lost CONFIG_SPI_CADENCE_QUADSPI accidentally while bisecting.
I will try bisect and post the result again.

Regards,

Takuo Koguchi

2021/03/13 8:07、Pavel Machek <pavel@denx.de>のメール:

Hi!

Git bisect has told me the first bad commit is
31fb632b5d43 spi: Move cadence-quadspi driver to drivers/spi/
That's strange.

Does this change requires device tree modification?
Any suggestions or comments would be appreciated.
...because that particular change does not change any C code. But it
touches Kconfig bits; can you check that CONFIG_SPI_CADENCE_QUADSPI is
enabled in the "bad" configuration?

Do you have any local changes in
drivers/mtd/spi-nor/controllers/cadence-quadspi.c or
drivers/spi/spi-cadence-quadspi.c ?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany



Re: Is cadence-quadspi working on cyclone V?

Takuo Koguchi
 

Hi Pavel,

Git bisect has told me the first bad commit is
31fb632b5d43 spi: Move cadence-quadspi driver to drivers/spi/
That's strange.

Does this change requires device tree modification?
Any suggestions or comments would be appreciated.
...because that particular change does not change any C code. But it
touches Kconfig bits; can you check that CONFIG_SPI_CADENCE_QUADSPI is
enabled in the "bad" configuration?

Do you have any local changes in
drivers/mtd/spi-nor/controllers/cadence-quadspi.c or
drivers/spi/spi-cadence-quadspi.c ?
I have no local changes to those files.
Maybe I lost CONFIG_SPI_CADENCE_QUADSPI accidentally while bisecting.
I will try bisect and post the result again.
I redo the bisect and get the following result;
# first bad commit: [a314f6367787ee1d767df9a2120f17e4511144d0] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework

It contains significant amount of changes;

cadence-quadspi.c | 476 +++++++++++++++++++++---------------------------------
1 file changed, 191 insertions(+), 285 deletions(-)

With this change, cpspi_probe return 0 without any error messages, but it does not detect NOR flash on a custom cyclone V board.

Any information will be appreciated.

Thanks,

Takuo Koguchi

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO
Sent: Sunday, March 14, 2021 4:37 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [!]Re: [cip-dev] Is cadence-quadspi working on cyclone V?

Hi Pavel,
Thank you for the response.

Git bisect has told me the first bad commit is
31fb632b5d43 spi: Move cadence-quadspi driver to drivers/spi
That's strange.

Does this change requires device tree modification?
Any suggestions or comments would be appreciated.
...because that particular change does not change any C code. But it
touches Kconfig bits; can you check that CONFIG_SPI_CADENCE_QUADSPI is
enabled in the "bad" configuration?

Do you have any local changes in
drivers/mtd/spi-nor/controllers/cadence-quadspi.c or
drivers/spi/spi-cadence-quadspi.c ?
I have no local changes to those files.
Maybe I lost CONFIG_SPI_CADENCE_QUADSPI accidentally while bisecting.
I will try bisect and post the result again.

Regards,

Takuo Koguchi

2021/03/13 8:07、Pavel Machek <pavel@denx.de>のメール:

Hi!

Git bisect has told me the first bad commit is
31fb632b5d43 spi: Move cadence-quadspi driver to drivers/spi/
That's strange.

Does this change requires device tree modification?
Any suggestions or comments would be appreciated.
...because that particular change does not change any C code. But it
touches Kconfig bits; can you check that CONFIG_SPI_CADENCE_QUADSPI is
enabled in the "bad" configuration?

Do you have any local changes in
drivers/mtd/spi-nor/controllers/cadence-quadspi.c or
drivers/spi/spi-cadence-quadspi.c ?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany



Re: master branch at git.kernel.org/...cip

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of Pavel Machek
Sent: Thursday, March 11, 2021 9:43 PM
To: Chris.Paterson2@renesas.com; cip-dev@lists.cip-project.org
Subject: [cip-dev] master branch at git.kernel.org/...cip

Hi!

Chris pointed out our master branch at git.kernel.org is rather old:

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/refs/heads

master CIP: Bump version suffix to -cip28 after Renesas patches Ben Hutchings 2 years


Master branch is really not too applicable for our workflow. Yes, 2
years old version of 4.4 looks out of place.

I see these options:

1) leave it alone. (+) It is quite obvious development is not
happening there (-) It looks strange.

2) delete it. (-) I'm not sure that is possible or what problems it
might cause.

3) update it to Linus' 5.12-rc1 and keep it updated. (-) Extra work to
keep it updated, (-) we don't really do anything with mainline commits
newer than 5.10

4) update it to Linus' 5.10, and only touch it when the linux-5.21-cip
is branched out.

Any other ideas?

My preference would be (1) and (4).
I want to choose 1 or 3.
We have multiple release branches, so setting the branch that manages a particular version to
the master branch can be a bit confusing. How about managing a branch similar to LTS tree?

Best regards,
Nobuhiro


Re: Is cadence-quadspi working on cyclone V?

Takuo Koguchi
 

Hi Pavel,
Thank you for the response.

Git bisect has told me the first bad commit is
31fb632b5d43 spi: Move cadence-quadspi driver to drivers/spi/
That's strange.

Does this change requires device tree modification?
Any suggestions or comments would be appreciated.
...because that particular change does not change any C code. But it
touches Kconfig bits; can you check that CONFIG_SPI_CADENCE_QUADSPI is
enabled in the "bad" configuration?

Do you have any local changes in
drivers/mtd/spi-nor/controllers/cadence-quadspi.c or
drivers/spi/spi-cadence-quadspi.c ?
I have no local changes to those files.
Maybe I lost CONFIG_SPI_CADENCE_QUADSPI accidentally while bisecting.
I will try bisect and post the result again.

Regards,

Takuo Koguchi

2021/03/13 8:07、Pavel Machek <pavel@denx.de>のメール:

Hi!

Git bisect has told me the first bad commit is
31fb632b5d43 spi: Move cadence-quadspi driver to drivers/spi/
That's strange.

Does this change requires device tree modification?
Any suggestions or comments would be appreciated.
...because that particular change does not change any C code. But it
touches Kconfig bits; can you check that CONFIG_SPI_CADENCE_QUADSPI is
enabled in the "bad" configuration?

Do you have any local changes in
drivers/mtd/spi-nor/controllers/cadence-quadspi.c or
drivers/spi/spi-cadence-quadspi.c ?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany



Re: Is cadence-quadspi working on cyclone V?

Pavel Machek
 

Hi!

Git bisect has told me the first bad commit is
31fb632b5d43 spi: Move cadence-quadspi driver to drivers/spi/
That's strange.

Does this change requires device tree modification?
Any suggestions or comments would be appreciated.
...because that particular change does not change any C code. But it
touches Kconfig bits; can you check that CONFIG_SPI_CADENCE_QUADSPI is
enabled in the "bad" configuration?

Do you have any local changes in
drivers/mtd/spi-nor/controllers/cadence-quadspi.c or
drivers/spi/spi-cadence-quadspi.c ?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Is cadence-quadspi working on cyclone V?

Takuo Koguchi
 

Hi CIP developers,

 

Can anyone confirm that spi-cadence-quadspi works fine with SPI-NOR on cyclone V?

I recently moved to 5.10.y-cip from 4.19.y-cip, then my custom board with cyclone V failed to detect SPI-NOR

 

Git bisect has told me the first bad commit is

31fb632b5d43 spi: Move cadence-quadspi driver to drivers/spi/

 

Does this change requires device tree modification?

Any suggestions or comments would be appreciated.

 

Takuo Koguchi

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

V


master branch at git.kernel.org/...cip

Pavel Machek
 

Hi!

Chris pointed out our master branch at git.kernel.org is rather old:

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/refs/heads

master CIP: Bump version suffix to -cip28 after Renesas patches Ben Hutchings 2 years


Master branch is really not too applicable for our workflow. Yes, 2
years old version of 4.4 looks out of place.

I see these options:

1) leave it alone. (+) It is quite obvious development is not
happening there (-) It looks strange.

2) delete it. (-) I'm not sure that is possible or what problems it
might cause.

3) update it to Linus' 5.12-rc1 and keep it updated. (-) Extra work to
keep it updated, (-) we don't really do anything with mainline commits
newer than 5.10

4) update it to Linus' 5.10, and only touch it when the linux-5.21-cip
is branched out.

Any other ideas?

My preference would be (1) and (4).

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


4.4 futex: Change locking rules

Pavel Machek
 

Hi!

There was some discussion about futexes in 4.4 on irc.

https://lore.kernel.org/stable/20210309030605.3295183-2-zhengyejian1@huawei.com/

I don't believe we need to do anything there. Peter Zijlstra is
re-doing locking for futexes, which will have benefits for future
realtime releases. But we have separate patches for 4.4-rt, so we
should be fine.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Cip-kernel-sec Updates for Week of 2021-03-11

Chen-Yu Tsai (Moxa) <wens@...>
 

Hi everyone,

Seven new CVEs this week:
- CVE-2021-20265 [af_unix: memory leak] - fixed
- CVE-2021-20268 [ebpf: signed type overflow] - fixed
- CVE-2021-27363 [iscsi: iscsi_host_get_param() allows sysfs params
larger than 4k] - fixed
- CVE-2021-27364 [iscsi: iscsi_if_recv_msg allows non-root user] - fixed
- CVE-2021-27365 [iscsi: heap buffer overflow] - fixed
- CVE-2021-28038 [xen: netback: fails to honor errors] - fixed
- CVE-2021-28039 [xen: incorrect foreign pages mapping under special
config] - fixed

All fixes have been backported to all relevant stable kernels.

Also, 4.9.y specific follow-up patch for CVE-2020-29368 was merged in 4.9.259.


Regards
ChenYu


Re: CIP IRC weekly meeting today

Nobuhiro Iwamatsu
 

Hi all,

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of
masashi.kudo@cybertrust.co.jp
Sent: Thursday, March 11, 2021 9:23 AM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] CIP IRC weekly meeting today

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
Sorry, I can not participate today's IRC meeting for personal reason.


*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according
to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=3&day=11&hour=9&min=0&sec=0&p1=224&p2=
179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
01:00 04:00 9:00 10:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2021/03/cip.2021-03-04-09.00.log.html

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
No update.

2. Do some experiment to lower burdens on CI - patersonc

* Kernel maintenance updates
I reviewed 4.4.260, 5.10.21 and 5.10.22.

* Kernel testing
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics
can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
Best regards.
Nobuhiro

--
M. Kudo
Cybertrust Japan Co., Ltd.


CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=3&day=11&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
01:00 04:00 9:00 10:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2021/03/cip.2021-03-04-09.00.log.html

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Do some experiment to lower burdens on CI - patersonc

* Kernel maintenance updates
* Kernel testing
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: [PATCH 4.19.y-cip 00/40] Renesas RZ/G2{E,H,M,N} add VIN, CSI2 support

Chris Paterson
 

Hello Pavel, Iwamatsu-san,

From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On
Behalf Of Nobuhiro Iwamatsu via lists.cip-project.org
Sent: 10 March 2021 08:08

Hi,

-----Original Message-----
From: Lad Prabhakar [mailto:prabhakar.mahadev-lad.rj@bp.renesas.com]
Sent: Wednesday, March 10, 2021 1:36 AM
To: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋
□SWC◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>
Cc: Biju Das <biju.das.jz@bp.renesas.com>
Subject: [PATCH 4.19.y-cip 00/40] Renesas RZ/G2{E,H,M,N} add VIN, CSI2
support

Hi All,

This patch series does the following:
* Drops unneeded regulator setup for OV5645 sensor
* Adds driver for IMX219 sensor
* Updates v4l2-async to accept endpoints for fwnode matching
* Various fixes for R-Car VIN driver
* Support to capture RAW format to VIN driver
* Support for RZ/G2{H,M,N,E} SoC's in VIN/CSI2 driver
* DTS changes for HiHope RZ/G2{H,M,N} and SI Linux RZ/G2E to
enable VIN, CSI2 modules and OV5645, IMX219 sensors.
I reviewed this series, I didn't see any major problems.
As Paval points out, the Renesas lab is now stopped.
If this recovers and the target hardware test is okay, I would apply this.
Sorry about the lab-cip-renesas issues. The lab will probably be offline until next week.
I'm happy for this series to be delayed until it's tested if that's what you'd prefer.

Kind regards, Chris

Cheers,
Prabhakar
Best regards,
Nobuhiro



Andrey Konovalov (1):
media: dt-bindings: media: i2c: Add IMX219 CMOS sensor binding

Biju Das (10):
media: dt-bindings: media: rcar_vin: Add r8a774a1 support
media: rcar-vin: Enable support for r8a774a1
media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
media: rcar-csi2: Enable support for r8a774a1
arm64: dts: renesas: r8a774a1: Add VIN and CSI-2 nodes
media: dt-bindings: rcar-vin: Add R8A774B1 support
media: rcar-vin: Enable support for R8A774B1
media: dt-bindings: rcar-csi2: Add R8A774B1 support
media: rcar-csi2: Enable support for R8A774B1
arm64: dts: renesas: r8a774b1: Add VIN and CSI-2 support

Dafna Hirschfeld (1):
media: i2c: imx219: Fix a bug in imx219_enum_frame_size

Dave Stevenson (1):
media: i2c: Add driver for Sony IMX219 sensor

Fabio Estevam (1):
media: ov5645: Remove unneeded regulator_set_voltage()

Hans Verkuil (2):
media: i2c: imx219: Selection compliance fixes
media: i2c: imx219: take lock in imx219_enum_mbus_code/frame_size

Jacopo Mondi (1):
media: i2c: imx219: Implement get_selection

Lad Prabhakar (16):
media: rcar-vin: Invalidate pipeline if conversion is not possible on
input formats
media: rcar-vin: Add support for MEDIA_BUS_FMT_SRGGB8_1X8 format
media: rcar-csi2: Add support for MEDIA_BUS_FMT_SRGGB8_1X8 format
media: i2c: imx219: Fix power sequence
media: i2c: imx219: Add support for RAW8 bit bayer format
media: i2c: imx219: Add support for cropped 640x480 resolution
arm64: dts: renesas: r8a774c0-cat874: Add support for AISTARVISION
MIPI Adapter V2.1
media: dt-bindings: media: renesas,vin: Add R8A774E1 support
media: rcar-vin: Enable support for R8A774E1
media: dt-bindings: media: renesas,csi2: Add R8A774E1 support
media: rcar-csi2: Enable support for R8A774E1
arm64: dts: renesas: r8a774e1: Add VIN and CSI-2 nodes
arm64: dts: renesas: aistarvision-mipi-adapter-2.1: Add parent macro
for each sensor
arm64: dts: renesas: Add support for MIPI Adapter V2.1 connected to
HiHope RZ/G2H
arm64: dts: renesas: Add support for MIPI Adapter V2.1 connected to
HiHope RZ/G2M
arm64: dts: renesas: Add support for MIPI Adapter V2.1 connected to
HiHope RZ/G2N

Laurent Pinchart (4):
media: device property: Add a function to test is a fwnode is a graph
endpoint
media: v4l2-async: Accept endpoints and devices for fwnode matching
media: v4l2-async: Pass notifier pointer to match functions
media: v4l2-async: Log message in case of heterogeneous fwnode match

Niklas Söderlund (2):
media: rcar-vin: fix wrong return value in rvin_set_channel_routing()
media: rcar-csi2: Update V3M and E3 start procedure

Sakari Ailus (1):
media: v4l: ctrl: Provide unlocked variant of v4l2_ctrl_grab

.../devicetree/bindings/media/i2c/imx219.yaml | 114 ++
.../devicetree/bindings/media/rcar_vin.txt | 3 +
.../bindings/media/renesas,rcar-csi2.txt | 3 +
MAINTAINERS | 8 +
arch/arm64/boot/dts/renesas/Makefile | 10 +-
.../aistarvision-mipi-adapter-2.1.dtsi | 96 +
...rzg2-ex-aistarvision-mipi-adapter-2.1.dtsi | 109 ++
.../r8a774a1-hihope-rzg2m-ex-mipi-2.1.dts | 29 +
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 367 ++++
.../r8a774b1-hihope-rzg2n-ex-mipi-2.1.dts | 16 +
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 366 ++++
.../dts/renesas/r8a774c0-ek874-mipi-2.1.dts | 73 +
.../r8a774e1-hihope-rzg2h-ex-mipi-2.1.dts | 16 +
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 334 ++++
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/imx219.c | 1582 +++++++++++++++++
drivers/media/i2c/ov5645.c | 28 -
drivers/media/platform/rcar-vin/rcar-core.c | 49 +
drivers/media/platform/rcar-vin/rcar-csi2.c | 23 +-
drivers/media/platform/rcar-vin/rcar-dma.c | 17 +-
drivers/media/platform/rcar-vin/rcar-v4l2.c | 4 +
drivers/media/v4l2-core/v4l2-async.c | 83 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 8 +-
include/linux/property.h | 5 +
include/media/v4l2-ctrls.h | 26 +-
26 files changed, 3330 insertions(+), 51 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/i2c/imx219.yaml
create mode 100644 arch/arm64/boot/dts/renesas/aistarvision-mipi-
adapter-2.1.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/hihope-rzg2-ex-
aistarvision-mipi-adapter-2.1.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r8a774a1-hihope-
rzg2m-ex-mipi-2.1.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a774b1-hihope-
rzg2n-ex-mipi-2.1.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-mipi-
2.1.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a774e1-hihope-
rzg2h-ex-mipi-2.1.dts
create mode 100644 drivers/media/i2c/imx219.c

--
2.17.1


Re: [PATCH 4.19.y-cip 12/40] media: dt-bindings: media: i2c: Add IMX219 CMOS sensor binding

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 10 March 2021 09:39
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: Pavel Machek <pavel@denx.de>; cip-dev@lists.cip-project.org; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@toshiba.co.jp>; Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [PATCH 4.19.y-cip 12/40] media: dt-bindings: media: i2c: Add IMX219 CMOS sensor binding

Hi!

+description: |-
+ The Sony imx219 is a 1/4.0-inch CMOS active pixel digital image sensor
I assume it is 0.25 inch sensor? 1/4 inch or 0.25 inch would be
understandable, but 1/4.0 is kind of strange.
Agree with you here, but looking at the document [1] its referred the same way "1/4.0".

[1] http://www.opensourceinstruments.com/Electronics/Data/IMX219PQ.pdf
It is refered as "Type 1/4.0" and I'm not really sure what it means.

1/4 inch is 6.35mm, but document states it is 4.6mm.

https://www.photoreview.com.au/tips/buying/unravelling-sensor-sizes/
Thanks for the pointer.

explains this system, but they use 1/4", not 1/4.0, and it translates
that to 4.5mm.

I guess easiest way is to say it is "4.8mm CMOS active pixel digital
image sensor" and forget about confusing inch values.
Totally agree with you (^^4.5mm).

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 00/40] Renesas RZ/G2{E,H,M,N} add VIN, CSI2 support

Lad Prabhakar
 

Hi Pavel, Nobuhiro,

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: 10 March 2021 08:08
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>; cip-dev@lists.cip-project.org;
pavel@denx.de
Cc: Biju Das <biju.das.jz@bp.renesas.com>
Subject: RE: [PATCH 4.19.y-cip 00/40] Renesas RZ/G2{E,H,M,N} add VIN, CSI2 support

Hi,

-----Original Message-----
From: Lad Prabhakar [mailto:prabhakar.mahadev-lad.rj@bp.renesas.com]
Sent: Wednesday, March 10, 2021 1:36 AM
To: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>
Cc: Biju Das <biju.das.jz@bp.renesas.com>
Subject: [PATCH 4.19.y-cip 00/40] Renesas RZ/G2{E,H,M,N} add VIN, CSI2 support

Hi All,

This patch series does the following:
* Drops unneeded regulator setup for OV5645 sensor
* Adds driver for IMX219 sensor
* Updates v4l2-async to accept endpoints for fwnode matching
* Various fixes for R-Car VIN driver
* Support to capture RAW format to VIN driver
* Support for RZ/G2{H,M,N,E} SoC's in VIN/CSI2 driver
* DTS changes for HiHope RZ/G2{H,M,N} and SI Linux RZ/G2E to
enable VIN, CSI2 modules and OV5645, IMX219 sensors.
I reviewed this series, I didn't see any major problems.
Thank you for the review.

As Paval points out, the Renesas lab is now stopped.
If this recovers and the target hardware test is okay, I would apply this.
I have informed Chris about this.

Cheers,
Prabhakar

Cheers,
Prabhakar
Best regards,
Nobuhiro



Andrey Konovalov (1):
media: dt-bindings: media: i2c: Add IMX219 CMOS sensor binding

Biju Das (10):
media: dt-bindings: media: rcar_vin: Add r8a774a1 support
media: rcar-vin: Enable support for r8a774a1
media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
media: rcar-csi2: Enable support for r8a774a1
arm64: dts: renesas: r8a774a1: Add VIN and CSI-2 nodes
media: dt-bindings: rcar-vin: Add R8A774B1 support
media: rcar-vin: Enable support for R8A774B1
media: dt-bindings: rcar-csi2: Add R8A774B1 support
media: rcar-csi2: Enable support for R8A774B1
arm64: dts: renesas: r8a774b1: Add VIN and CSI-2 support

Dafna Hirschfeld (1):
media: i2c: imx219: Fix a bug in imx219_enum_frame_size

Dave Stevenson (1):
media: i2c: Add driver for Sony IMX219 sensor

Fabio Estevam (1):
media: ov5645: Remove unneeded regulator_set_voltage()

Hans Verkuil (2):
media: i2c: imx219: Selection compliance fixes
media: i2c: imx219: take lock in imx219_enum_mbus_code/frame_size

Jacopo Mondi (1):
media: i2c: imx219: Implement get_selection

Lad Prabhakar (16):
media: rcar-vin: Invalidate pipeline if conversion is not possible on
input formats
media: rcar-vin: Add support for MEDIA_BUS_FMT_SRGGB8_1X8 format
media: rcar-csi2: Add support for MEDIA_BUS_FMT_SRGGB8_1X8 format
media: i2c: imx219: Fix power sequence
media: i2c: imx219: Add support for RAW8 bit bayer format
media: i2c: imx219: Add support for cropped 640x480 resolution
arm64: dts: renesas: r8a774c0-cat874: Add support for AISTARVISION
MIPI Adapter V2.1
media: dt-bindings: media: renesas,vin: Add R8A774E1 support
media: rcar-vin: Enable support for R8A774E1
media: dt-bindings: media: renesas,csi2: Add R8A774E1 support
media: rcar-csi2: Enable support for R8A774E1
arm64: dts: renesas: r8a774e1: Add VIN and CSI-2 nodes
arm64: dts: renesas: aistarvision-mipi-adapter-2.1: Add parent macro
for each sensor
arm64: dts: renesas: Add support for MIPI Adapter V2.1 connected to
HiHope RZ/G2H
arm64: dts: renesas: Add support for MIPI Adapter V2.1 connected to
HiHope RZ/G2M
arm64: dts: renesas: Add support for MIPI Adapter V2.1 connected to
HiHope RZ/G2N

Laurent Pinchart (4):
media: device property: Add a function to test is a fwnode is a graph
endpoint
media: v4l2-async: Accept endpoints and devices for fwnode matching
media: v4l2-async: Pass notifier pointer to match functions
media: v4l2-async: Log message in case of heterogeneous fwnode match

Niklas Söderlund (2):
media: rcar-vin: fix wrong return value in rvin_set_channel_routing()
media: rcar-csi2: Update V3M and E3 start procedure

Sakari Ailus (1):
media: v4l: ctrl: Provide unlocked variant of v4l2_ctrl_grab

.../devicetree/bindings/media/i2c/imx219.yaml | 114 ++
.../devicetree/bindings/media/rcar_vin.txt | 3 +
.../bindings/media/renesas,rcar-csi2.txt | 3 +
MAINTAINERS | 8 +
arch/arm64/boot/dts/renesas/Makefile | 10 +-
.../aistarvision-mipi-adapter-2.1.dtsi | 96 +
...rzg2-ex-aistarvision-mipi-adapter-2.1.dtsi | 109 ++
.../r8a774a1-hihope-rzg2m-ex-mipi-2.1.dts | 29 +
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 367 ++++
.../r8a774b1-hihope-rzg2n-ex-mipi-2.1.dts | 16 +
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 366 ++++
.../dts/renesas/r8a774c0-ek874-mipi-2.1.dts | 73 +
.../r8a774e1-hihope-rzg2h-ex-mipi-2.1.dts | 16 +
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 334 ++++
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/imx219.c | 1582 +++++++++++++++++
drivers/media/i2c/ov5645.c | 28 -
drivers/media/platform/rcar-vin/rcar-core.c | 49 +
drivers/media/platform/rcar-vin/rcar-csi2.c | 23 +-
drivers/media/platform/rcar-vin/rcar-dma.c | 17 +-
drivers/media/platform/rcar-vin/rcar-v4l2.c | 4 +
drivers/media/v4l2-core/v4l2-async.c | 83 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 8 +-
include/linux/property.h | 5 +
include/media/v4l2-ctrls.h | 26 +-
26 files changed, 3330 insertions(+), 51 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/imx219.yaml
create mode 100644 arch/arm64/boot/dts/renesas/aistarvision-mipi-adapter-2.1.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/hihope-rzg2-ex-aistarvision-mipi-adapter-2.1.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-mipi-2.1.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a774b1-hihope-rzg2n-ex-mipi-2.1.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-mipi-2.1.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a774e1-hihope-rzg2h-ex-mipi-2.1.dts
create mode 100644 drivers/media/i2c/imx219.c

--
2.17.1


Re: [PATCH 4.19.y-cip 12/40] media: dt-bindings: media: i2c: Add IMX219 CMOS sensor binding

Pavel Machek
 

Hi!

+description: |-
+ The Sony imx219 is a 1/4.0-inch CMOS active pixel digital image sensor
I assume it is 0.25 inch sensor? 1/4 inch or 0.25 inch would be
understandable, but 1/4.0 is kind of strange.
Agree with you here, but looking at the document [1] its referred the same way "1/4.0".

[1] http://www.opensourceinstruments.com/Electronics/Data/IMX219PQ.pdf
It is refered as "Type 1/4.0" and I'm not really sure what it means.

1/4 inch is 6.35mm, but document states it is 4.6mm.

https://www.photoreview.com.au/tips/buying/unravelling-sensor-sizes/
explains this system, but they use 1/4", not 1/4.0, and it translates
that to 4.5mm.

I guess easiest way is to say it is "4.8mm CMOS active pixel digital
image sensor" and forget about confusing inch values.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 21/40] arm64: dts: renesas: r8a774c0-cat874: Add support for AISTARVISION MIPI Adapter V2.1

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 09 March 2021 20:39
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek
<pavel@denx.de>; Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [PATCH 4.19.y-cip 21/40] arm64: dts: renesas: r8a774c0-cat874: Add support for
AISTARVISION MIPI Adapter V2.1

Hi!

+ imx219_ep: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <456000000>;
+ /* uncomment remote-endpoint property to tie imx219 to
+ * CSI2 also make sure remote-endpoint for ov5645 camera
+ * is commented and remote endpoint phandle in csi40_in
+ * is imx219_ep
+ */
This needs to be normal comment style, and it needs to contain
sentences. And it may be better to provide #ifdef for the alternate
configuration.
Agreed will fix that upstream.

Cheers,
Prabhakar

+ /* remote-endpoint = <&csi40_in>; */
Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 13/40] media: i2c: Add driver for Sony IMX219 sensor

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 09 March 2021 20:37
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek
<pavel@denx.de>; Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [PATCH 4.19.y-cip 13/40] media: i2c: Add driver for Sony IMX219 sensor

Hi!

+/* External clock frequency is 24.0M */
+#define IMX219_XCLK_FREQ 24000000
MHz?

+/*Frame Length Line*/
Make this usual comment style.

+/*
+ * Initialisation delay between XCLR low->high and the moment when the sensor
+ * can start capture (i.e. can leave software stanby) must be not less than:
+ * t4 + max(t5, t6 + <time to initialize the sensor register over I2C>)
+ * where
+ * t4 is fixed, and is max 200uS,
+ * t5 is fixed, and is 6000uS,
...
+ * 1185 to 5333 uS, and is always less than t5.
...
+ * For this reason this is always safe to wait (t4 + t5) = 6200 uS, then
I believe this should be "us" or "usec".

+ /*
+ * Mutex for serialized access:
+ * Protect sensor module set pad format and start/stop streaming safely.
+ */
This is not really english.

+/* Read registers up to 2 at a time */
+static int imx219_read_reg(struct imx219 *imx219, u16 reg, u32 len, u32 *val)
+{
+ msgs[1].buf = &data_buf[4 - len];
+
+ ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
+ if (ret != ARRAY_SIZE(msgs))
+ return -EIO;
+
+ *val = get_unaligned_be32(data_buf);
That's really interesting piece of code. len is in bytes, but return
value is in 32 bit values, magic with be32...

+static int imx219_write_reg(struct imx219 *imx219, u16 reg, u32 len, u32 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&imx219->sd);
+ u8 buf[6];
+
+ if (len > 4)
+ return -EINVAL;
+
+ put_unaligned_be16(reg, buf);
+ put_unaligned_be32(val << (8 * (4 - len)), buf + 2);
Wow. When I thought above was interesting.... this is even more so.


+static int imx219_set_ctrl(struct v4l2_ctrl *ctrl)
+{
...
+ /*
+ * Applying V4L2 control value only happens
+ * when power is up for streaming
+ */
+ if (pm_runtime_get_if_in_use(&client->dev) == 0)
+ return 0;
Is this usual for other cameras? Will not it cause problems to
applications doing autogain?
Above check is to see if the camera is turned ON, so the application doing autogain should be fine.

+ switch (ctrl->id) {
...
+ case V4L2_CID_HFLIP:
+ case V4L2_CID_VFLIP:
+ ret = imx219_write_reg(imx219, IMX219_REG_ORIENTATION, 1,
+ imx219->hflip->val |
+ imx219->vflip->val << 1);
+ break;
ctrl->val is unused in this case?
Yes, for the H/V flip it depends on the format code set.

+ break;
+ default:
+ dev_info(&client->dev,
+ "ctrl(id:0x%x,val:0x%x) is not handled\n",
+ ctrl->id, ctrl->val);
+ ret = -EINVAL;
+ break;
+ }
Rate limit this as user can trigger these?
Yes can be triggered.

+static int imx219_set_stream(struct v4l2_subdev *sd, int enable)
+{
+ struct imx219 *imx219 = to_imx219(sd);
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ int ret = 0;
+
+ mutex_lock(&imx219->mutex);
+ if (imx219->streaming == enable) {
+ mutex_unlock(&imx219->mutex);
+ return 0;
+ }
+
+ if (enable) {
+ ret = pm_runtime_get_sync(&client->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(&client->dev);
+ goto err_unlock;
+ }
+
+ /*
+ * Apply default & customized values
+ * and then start streaming.
+ */
+ ret = imx219_start_streaming(imx219);
+ if (ret)
+ goto err_rpm_put;
Is it correct/vital that one error path uses put_noidle() and second
uses plain put()?
As per my reading https://patchwork.kernel.org/project/linux-omap/patch/20180518173008.73291-2-tony@atomide.com/ its OK.

+static int __maybe_unused imx219_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct imx219 *imx219 = to_imx219(sd);
+ int ret;
+
+ if (imx219->streaming) {
+ ret = imx219_start_streaming(imx219);
+ if (ret)
+ goto error;
+ }
+
+ return 0;
+
+error:
+ imx219_stop_streaming(imx219);
+ imx219->streaming = 0;
This error path will leave driver in inconsistent state. hflip/vflip
controls will be locked and pm_runtime_put() is not executed.
Good catch, this needs fixing in upstream.

+static int imx219_check_hwcfg(struct device *dev)
+{
+ struct v4l2_fwnode_endpoint *ep_cfg;
+ struct device_node *ep;
+ int ret = -EINVAL;
+
+ ep = of_graph_get_next_endpoint(dev->of_node, NULL);
+ if (!ep) {
+ dev_err(dev, "missing endpoint node\n");
+ return -EINVAL;
+ }
+
+ ep_cfg = v4l2_fwnode_endpoint_alloc_parse(of_fwnode_handle(ep));
+ if (IS_ERR(ep_cfg)) {
+ dev_err(dev, "could not parse endpoint\n");
+ goto error_out;
+ }
...
+error_out:
+ v4l2_fwnode_endpoint_free(ep_cfg);
Is it correct to call endpoint_free on error pointer?
Yes the core handles it.

+MODULE_AUTHOR("Dave Stevenson <dave.stevenson@raspberrypi.com");
Missing ">" at end of address.
Yep needs fixing as well.

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 14/40] media: i2c: imx219: Fix power sequence

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 09 March 2021 19:42
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek
<pavel@denx.de>; Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [PATCH 4.19.y-cip 14/40] media: i2c: imx219: Fix power sequence

Hi!

With this commit the sensor is able to enter LP-11 mode during power up,
as expected by some CSI-2 controllers.

[1] https://publiclab.org/system/images/photos/000/023/294/original/
RASPBERRY_PI_CAMERA_V2_DATASHEET_IMX219PQH5_7.0.0_Datasheet_XXX.PDF

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/media/i2c/imx219.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/drivers/media/i2c/imx219.c b/drivers/media/i2c/imx219.c
index c67b2cf5c32c..f1ae93569542 100644
--- a/drivers/media/i2c/imx219.c
+++ b/drivers/media/i2c/imx219.c
@@ -1224,6 +1224,23 @@ static int imx219_probe(struct i2c_client *client)
/* Set default mode to max resolution */
imx219->mode = &supported_modes[0];

+ /* sensor doesn't enter LP-11 state upon power up until and unless
+ * streaming is started, so upon power up switch the modes to:
+ * streaming -> standby
+ */
/*
* Sensor...

would be the usual commment style.
Agreed, will have to fix up-stream.

Cheers,
Prabhakar

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 12/40] media: dt-bindings: media: i2c: Add IMX219 CMOS sensor binding

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: 09 March 2021 18:52
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek
<pavel@denx.de>; Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [PATCH 4.19.y-cip 12/40] media: dt-bindings: media: i2c: Add IMX219 CMOS sensor binding

Hi!

From: Andrey Konovalov <andrey.konovalov@linaro.org>

commit 9d730f2cf4c0391785855dd231577d2de2594df9 upstream.

Add YAML device tree binding for IMX219 CMOS image sensor, and
the relevant MAINTAINERS entries.
+title: Sony 1/4.0-Inch 8Mpixel CMOS Digital Image Sensor
+
+maintainers:
+ - Dave Stevenson <dave.stevenson@raspberrypi.com>
+
+description: |-
+ The Sony imx219 is a 1/4.0-inch CMOS active pixel digital image sensor
I assume it is 0.25 inch sensor? 1/4 inch or 0.25 inch would be
understandable, but 1/4.0 is kind of strange.
Agree with you here, but looking at the document [1] its referred the same way "1/4.0".

[1] http://www.opensourceinstruments.com/Electronics/Data/IMX219PQ.pdf

Cheers,
Prabhakar

+ imx219: sensor@10 {
+ compatible = "sony,imx219";
+ reg = <0x10>;
+ clocks = <&imx219_clk>;
+ VANA-supply = <&imx219_vana>; /* 2.8v */
+ VDIG-supply = <&imx219_vdig>; /* 1.8v */
+ VDDL-supply = <&imx219_vddl>; /* 1.2v */
"V" should be uppercase in voltages.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 00/40] Renesas RZ/G2{E,H,M,N} add VIN, CSI2 support

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Lad Prabhakar [mailto:prabhakar.mahadev-lad.rj@bp.renesas.com]
Sent: Wednesday, March 10, 2021 1:36 AM
To: cip-dev@lists.cip-project.org; iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@toshiba.co.jp>; Pavel Machek <pavel@denx.de>
Cc: Biju Das <biju.das.jz@bp.renesas.com>
Subject: [PATCH 4.19.y-cip 00/40] Renesas RZ/G2{E,H,M,N} add VIN, CSI2 support

Hi All,

This patch series does the following:
* Drops unneeded regulator setup for OV5645 sensor
* Adds driver for IMX219 sensor
* Updates v4l2-async to accept endpoints for fwnode matching
* Various fixes for R-Car VIN driver
* Support to capture RAW format to VIN driver
* Support for RZ/G2{H,M,N,E} SoC's in VIN/CSI2 driver
* DTS changes for HiHope RZ/G2{H,M,N} and SI Linux RZ/G2E to
enable VIN, CSI2 modules and OV5645, IMX219 sensors.
I reviewed this series, I didn't see any major problems.
As Paval points out, the Renesas lab is now stopped.
If this recovers and the target hardware test is okay, I would apply this.
Cheers,
Prabhakar
Best regards,
Nobuhiro



Andrey Konovalov (1):
media: dt-bindings: media: i2c: Add IMX219 CMOS sensor binding

Biju Das (10):
media: dt-bindings: media: rcar_vin: Add r8a774a1 support
media: rcar-vin: Enable support for r8a774a1
media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
media: rcar-csi2: Enable support for r8a774a1
arm64: dts: renesas: r8a774a1: Add VIN and CSI-2 nodes
media: dt-bindings: rcar-vin: Add R8A774B1 support
media: rcar-vin: Enable support for R8A774B1
media: dt-bindings: rcar-csi2: Add R8A774B1 support
media: rcar-csi2: Enable support for R8A774B1
arm64: dts: renesas: r8a774b1: Add VIN and CSI-2 support

Dafna Hirschfeld (1):
media: i2c: imx219: Fix a bug in imx219_enum_frame_size

Dave Stevenson (1):
media: i2c: Add driver for Sony IMX219 sensor

Fabio Estevam (1):
media: ov5645: Remove unneeded regulator_set_voltage()

Hans Verkuil (2):
media: i2c: imx219: Selection compliance fixes
media: i2c: imx219: take lock in imx219_enum_mbus_code/frame_size

Jacopo Mondi (1):
media: i2c: imx219: Implement get_selection

Lad Prabhakar (16):
media: rcar-vin: Invalidate pipeline if conversion is not possible on
input formats
media: rcar-vin: Add support for MEDIA_BUS_FMT_SRGGB8_1X8 format
media: rcar-csi2: Add support for MEDIA_BUS_FMT_SRGGB8_1X8 format
media: i2c: imx219: Fix power sequence
media: i2c: imx219: Add support for RAW8 bit bayer format
media: i2c: imx219: Add support for cropped 640x480 resolution
arm64: dts: renesas: r8a774c0-cat874: Add support for AISTARVISION
MIPI Adapter V2.1
media: dt-bindings: media: renesas,vin: Add R8A774E1 support
media: rcar-vin: Enable support for R8A774E1
media: dt-bindings: media: renesas,csi2: Add R8A774E1 support
media: rcar-csi2: Enable support for R8A774E1
arm64: dts: renesas: r8a774e1: Add VIN and CSI-2 nodes
arm64: dts: renesas: aistarvision-mipi-adapter-2.1: Add parent macro
for each sensor
arm64: dts: renesas: Add support for MIPI Adapter V2.1 connected to
HiHope RZ/G2H
arm64: dts: renesas: Add support for MIPI Adapter V2.1 connected to
HiHope RZ/G2M
arm64: dts: renesas: Add support for MIPI Adapter V2.1 connected to
HiHope RZ/G2N

Laurent Pinchart (4):
media: device property: Add a function to test is a fwnode is a graph
endpoint
media: v4l2-async: Accept endpoints and devices for fwnode matching
media: v4l2-async: Pass notifier pointer to match functions
media: v4l2-async: Log message in case of heterogeneous fwnode match

Niklas Söderlund (2):
media: rcar-vin: fix wrong return value in rvin_set_channel_routing()
media: rcar-csi2: Update V3M and E3 start procedure

Sakari Ailus (1):
media: v4l: ctrl: Provide unlocked variant of v4l2_ctrl_grab

.../devicetree/bindings/media/i2c/imx219.yaml | 114 ++
.../devicetree/bindings/media/rcar_vin.txt | 3 +
.../bindings/media/renesas,rcar-csi2.txt | 3 +
MAINTAINERS | 8 +
arch/arm64/boot/dts/renesas/Makefile | 10 +-
.../aistarvision-mipi-adapter-2.1.dtsi | 96 +
...rzg2-ex-aistarvision-mipi-adapter-2.1.dtsi | 109 ++
.../r8a774a1-hihope-rzg2m-ex-mipi-2.1.dts | 29 +
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 367 ++++
.../r8a774b1-hihope-rzg2n-ex-mipi-2.1.dts | 16 +
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 366 ++++
.../dts/renesas/r8a774c0-ek874-mipi-2.1.dts | 73 +
.../r8a774e1-hihope-rzg2h-ex-mipi-2.1.dts | 16 +
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 334 ++++
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/imx219.c | 1582 +++++++++++++++++
drivers/media/i2c/ov5645.c | 28 -
drivers/media/platform/rcar-vin/rcar-core.c | 49 +
drivers/media/platform/rcar-vin/rcar-csi2.c | 23 +-
drivers/media/platform/rcar-vin/rcar-dma.c | 17 +-
drivers/media/platform/rcar-vin/rcar-v4l2.c | 4 +
drivers/media/v4l2-core/v4l2-async.c | 83 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 8 +-
include/linux/property.h | 5 +
include/media/v4l2-ctrls.h | 26 +-
26 files changed, 3330 insertions(+), 51 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/imx219.yaml
create mode 100644 arch/arm64/boot/dts/renesas/aistarvision-mipi-adapter-2.1.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/hihope-rzg2-ex-aistarvision-mipi-adapter-2.1.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-mipi-2.1.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a774b1-hihope-rzg2n-ex-mipi-2.1.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-mipi-2.1.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a774e1-hihope-rzg2h-ex-mipi-2.1.dts
create mode 100644 drivers/media/i2c/imx219.c

--
2.17.1

1181 - 1200 of 7462