<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/media/i2c, branch linux-5.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.12.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.12.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-07-19T08:01:26Z</updated>
<entry>
<title>media: ccs: Fix the op_pll_multiplier address</title>
<updated>2021-07-19T08:01:26Z</updated>
<author>
<name>Bernhard Wimmer</name>
</author>
<published>2021-04-21T21:33:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b02785d85680cbff8afe109ce4117b9207d163f8'/>
<id>urn:sha1:b02785d85680cbff8afe109ce4117b9207d163f8</id>
<content type='text'>
commit 0e3e0c9369c822b7f1dd11504eeb98cfd4aabf24 upstream.

According to the CCS spec the op_pll_multiplier address is 0x030e,
not 0x031e.

Signed-off-by: Bernhard Wimmer &lt;be.wimm@gmail.com&gt;
Signed-off-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Cc: stable@vger.kernel.org
Fixes: 6493c4b777c2 ("media: smiapp: Import CCS definitions")
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: i2c: ccs-core: fix pm_runtime_get_sync() usage count</title>
<updated>2021-07-19T08:01:26Z</updated>
<author>
<name>Mauro Carvalho Chehab</name>
</author>
<published>2021-04-23T15:19:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=577fc6be05598cc8475aa0c67a856d1ebadc03be'/>
<id>urn:sha1:577fc6be05598cc8475aa0c67a856d1ebadc03be</id>
<content type='text'>
commit da3a1858c3a37c09446e1470c48352897d59d11b upstream.

The pm_runtime_get_sync() internally increments the
dev-&gt;power.usage_count without decrementing it, even on errors.

There is a bug at ccs_pm_get_init(): when this function returns
an error, the stream is not started, and RPM usage_count
should not be incremented. However, if the calls to
v4l2_ctrl_handler_setup() return errors, it will be kept
incremented.

At ccs_suspend() the best is to replace it by the new
pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter automatically,
in the case of errors.

Fixes: 96e3a6b92f23 ("media: smiapp: Avoid maintaining power state information")
Cc: stable@vger.kernel.org
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: subdev: disallow ioctl for saa6588/davinci</title>
<updated>2021-07-19T08:01:26Z</updated>
<author>
<name>Arnd Bergmann</name>
</author>
<published>2021-06-14T10:34:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=35781afaa4d7925bf7cfe7a6a0ea45cc5bc031bb'/>
<id>urn:sha1:35781afaa4d7925bf7cfe7a6a0ea45cc5bc031bb</id>
<content type='text'>
commit 0a7790be182d32b9b332a37cb4206e24fe94b728 upstream.

The saa6588_ioctl() function expects to get called from other kernel
functions with a 'saa6588_command' pointer, but I found nothing stops it
from getting called from user space instead, which seems rather dangerous.

The same thing happens in the davinci vpbe driver with its VENC_GET_FLD
command.

As a quick fix, add a separate .command() callback pointer for this
driver and change the two callers over to that.  This change can easily
get backported to stable kernels if necessary, but since there are only
two drivers, we may want to eventually replace this with a set of more
specialized callbacks in the long run.

Fixes: c3fda7f835b0 ("V4L/DVB (10537): saa6588: convert to v4l2_subdev.")
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: i2c: rdacm21: Power up OV10640 before OV490</title>
<updated>2021-07-14T14:59:35Z</updated>
<author>
<name>Jacopo Mondi</name>
</author>
<published>2021-06-16T12:46:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c10270efd31c698ce90003c16b34a48255ede7c6'/>
<id>urn:sha1:c10270efd31c698ce90003c16b34a48255ede7c6</id>
<content type='text'>
[ Upstream commit 2b821698dc73c00719e3dc367db712f727bbda85 ]

The current RDACM21 initialization routine powers up the OV10640 image
sensor after the OV490 ISP. The ISP is programmed with a firmware loaded
from an embedded serial flash that (most probably) tries to interact and
program also the image sensor connected to the ISP.

As described in commit "media: i2c: rdacm21: Fix OV10640 powerup" the
image sensor powerdown signal is kept high by an internal pull up
resistor and occasionally fails to startup correctly if the powerdown
line is not asserted explicitly. Failures in the OV10640 startup causes
the OV490 firmware to fail to boot correctly resulting in the camera
module initialization to fail consequentially.

Fix this by powering up the OV10640 image sensor before testing the
OV490 firmware boot completion, by splitting the ov10640_initialize()
function in an ov10640_power_up() one and an ov10640_check_id() one.

Also make sure the OV10640 identification procedure gives enough time to
the image sensor to resume after the programming phase performed by the
OV490 firmware by repeating the ID read procedure.

This commit fixes a sporadic start-up error triggered by a failure to
detect the OV490 firmware boot completion:
rdacm21 8-0054: Timeout waiting for firmware boot

[hverkuil: fixed two typos in commit log]

Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module")
Signed-off-by: Jacopo Mondi &lt;jacopo+renesas@jmondi.org&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Reviewed-by: Kieran Bingham &lt;kieran.bingham+renesas@ideasonboard.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: i2c: rdacm21: Fix OV10640 powerup</title>
<updated>2021-07-14T14:59:35Z</updated>
<author>
<name>Jacopo Mondi</name>
</author>
<published>2021-06-16T12:46:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bb7636aa1e504b8cb305346e5670509efc56da1c'/>
<id>urn:sha1:bb7636aa1e504b8cb305346e5670509efc56da1c</id>
<content type='text'>
[ Upstream commit ff75332b260cd33cc19000fdb5d256d9db4470d1 ]

The OV10640 image sensor powerdown signal is controlled by the first
line of the OV490 GPIO pad #1, but the pad #0 identifier
OV490_GPIO_OUTPUT_VALUE0 was erroneously used. As a result the image
sensor powerdown signal was never asserted but was left floating and
kept high by an internal pull-up resistor, causing sporadic failures
during the image sensor startup phase.

Fix this by using the correct GPIO pad identifier and wait the mandatory
1.5 millisecond delay after the powerup lane is asserted. The reset
delay is not characterized in the chip manual if not as "255 XVCLK +
initialization". Wait for at least 3 milliseconds to guarantee the SCCB
bus is available.

While at it also fix the reset sequence, as the reset line was released
before the powerdown one, and the line was not cycled.

This commit fixes a sporadic start-up error triggered by a failure to
read the OV10640 chip ID:
rdacm21 8-0054: OV10640 ID mismatch: (0x01)

Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module")
Signed-off-by: Jacopo Mondi &lt;jacopo+renesas@jmondi.org&gt;
Reviewed-by: Kieran Bingham &lt;kieran.bingham+renesas@ideasonboard.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: tc358743: Fix error return code in tc358743_probe_of()</title>
<updated>2021-07-14T14:59:33Z</updated>
<author>
<name>Zhen Lei</name>
</author>
<published>2021-05-15T06:58:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a77934fe4a7e300f5aa0106955ae92469956bedd'/>
<id>urn:sha1:a77934fe4a7e300f5aa0106955ae92469956bedd</id>
<content type='text'>
[ Upstream commit a6b1e7093f0a099571fc8836ab4a589633f956a8 ]

When the CSI bps per lane is not in the valid range, an appropriate error
code -EINVAL should be returned. However, we currently do not explicitly
assign this error code to 'ret'. As a result, 0 was incorrectly returned.

Fixes: 256148246852 ("[media] tc358743: support probe from device tree")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Zhen Lei &lt;thunder.leizhen@huawei.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: rc: i2c: Fix an error message</title>
<updated>2021-07-14T14:59:32Z</updated>
<author>
<name>Christophe JAILLET</name>
</author>
<published>2021-05-06T05:38:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=96409164a6aceb71d02ea485398ec07a6e44f8d1'/>
<id>urn:sha1:96409164a6aceb71d02ea485398ec07a6e44f8d1</id>
<content type='text'>
[ Upstream commit 9c87ae1a0dbeb5794957421157fd266d38a869b4 ]

'ret' is known to be 1 here. In fact 'i' is expected instead.
Store the return value of 'i2c_master_recv()' in 'ret' so that the error
message print the correct error code.

Fixes: acaa34bf06e9 ("media: rc: implement zilog transmitter")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: I2C: change 'RST' to "RSET" to fix multiple build errors</title>
<updated>2021-07-14T14:59:31Z</updated>
<author>
<name>Randy Dunlap</name>
</author>
<published>2021-04-30T20:19:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=73d6021a93fafde457a3460609e2e0f7e25a2efe'/>
<id>urn:sha1:73d6021a93fafde457a3460609e2e0f7e25a2efe</id>
<content type='text'>
[ Upstream commit 8edcb5049ac29aa3c8acc5ef15dd4036543d747e ]

The use of an enum named 'RST' conflicts with a #define macro
named 'RST' in arch/mips/include/asm/mach-rc32434/rb.h.

The MIPS use of RST was there first (AFAICT), so change the
media/i2c/ uses of RST to be named 'RSET'.
'git grep -w RSET' does not report any naming conflicts with the
new name.

This fixes multiple build errors:

arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
   15 | #define RST  (1 &lt;&lt; 15)
      |              ^
drivers/media/i2c/s5c73m3/s5c73m3.h:356:2: note: in expansion of macro 'RST'
  356 |  RST,
      |  ^~~

../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
   15 | #define RST  (1 &lt;&lt; 15)
      |              ^
../drivers/media/i2c/s5k6aa.c:180:2: note: in expansion of macro 'RST'
  180 |  RST,
      |  ^~~

../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
   15 | #define RST  (1 &lt;&lt; 15)
      |              ^
../drivers/media/i2c/s5k5baf.c:238:2: note: in expansion of macro 'RST'
  238 |  RST,
      |  ^~~

and some others that I have trimmed.

Fixes: cac47f1822fc ("[media] V4L: Add S5C73M3 camera driver")
Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")
Fixes: 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF camera sensor")
Fixes: bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX sensor")
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Cc: Shawn Guo &lt;shawnguo@kernel.org&gt;
Cc: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Cc: Pengutronix Kernel Team &lt;kernel@pengutronix.de&gt;
Cc: Fabio Estevam &lt;festevam@gmail.com&gt;
Cc: NXP Linux Team &lt;linux-imx@nxp.com&gt;
Cc: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
Cc: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Cc: Sylwester Nawrocki &lt;s.nawrocki@samsung.com&gt;
Cc: Sangwook Lee &lt;sangwook.lee@linaro.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: i2c: ccs-core: return the right error code at suspend</title>
<updated>2021-07-14T14:59:30Z</updated>
<author>
<name>Mauro Carvalho Chehab</name>
</author>
<published>2021-04-27T06:36:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=522911556ece3a1c04ba596c115d03590ab1d1bf'/>
<id>urn:sha1:522911556ece3a1c04ba596c115d03590ab1d1bf</id>
<content type='text'>
[ Upstream commit 6005a8e955e4e451e4bf6000affaab566d4cab5e ]

If pm_runtime resume logic fails, return the error code
provided by it, instead of -EAGAIN, as, depending on what
caused it to fail, it may not be something that would be
recovered.

Fixes: cbba45d43631 ("[media] smiapp: Use runtime PM")
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: i2c: ov2659: Use clk_{prepare_enable,disable_unprepare}() to set xvclk on/off</title>
<updated>2021-07-14T14:59:18Z</updated>
<author>
<name>Dillon Min</name>
</author>
<published>2021-05-04T05:09:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2e38d8c51aac20e8b038319ae21175400b3ad715'/>
<id>urn:sha1:2e38d8c51aac20e8b038319ae21175400b3ad715</id>
<content type='text'>
[ Upstream commit 24786ccd9c80fdb05494aa4d90fcb8f34295c193 ]

On some platform(imx6q), xvclk might not switch on in advance,
also for power save purpose, xvclk should not be always on.
so, add clk_prepare_enable(), clk_disable_unprepare() in driver
side to set xvclk on/off at proper stage.

Add following changes:
- add 'struct clk *clk;' in 'struct ov2659 {}'
- enable xvclk in ov2659_power_on()
- disable xvclk in ov2659_power_off()

Signed-off-by: Dillon Min &lt;dillon.minfei@gmail.com&gt;
Acked-by: Lad Prabhakar &lt;prabhakar.csengg@gmail.com&gt;
Signed-off-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
