[PATCH] [media] test
From: valentine.bars...@cogentembedded.com test --- drivers/media/platform/soc_camera/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig index dddca60..6540847 100644 --- a/drivers/media/platform/soc_camera/Kconfig +++ b/drivers/media/platform/soc_camera/Kconfig @@ -43,12 +43,14 @@ config VIDEO_RCAR_VIN config VIDEO_SH_MOBILE_CSI2 tristate "SuperH Mobile MIPI CSI-2 Interface driver" depends on VIDEO_DEV && SOC_CAMERA && HAVE_CLK + depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST ---help--- This is a v4l2 driver for the SuperH MIPI CSI-2 Interface config VIDEO_SH_MOBILE_CEU tristate "SuperH Mobile CEU Interface driver" depends on VIDEO_DEV && SOC_CAMERA && HAS_DMA && HAVE_CLK + depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST select VIDEOBUF2_DMA_CONTIG select SOC_CAMERA_SCALE_CROP ---help--- -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: soc_camera: rcar_vin: Add support for 10-bit YUV cameras
On 02/24/2014 10:38 PM, Laurent Pinchart wrote:
Hi Phil,
Thank you for the patch.
On Monday 24 February 2014 15:49:05 Phil Edworthy wrote:
Signed-off-by: Phil Edworthy phil.edwor...@renesas.com
---
drivers/media/platform/soc_camera/rcar_vin.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c index 3b1c05a..9929375
100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -68,6 +68,8 @@
#define VNMC_YCAL (1 19)
#define VNMC_INF_YUV8_BT656 (0 16)
#define VNMC_INF_YUV8_BT601 (1 16)
+#define VNMC_INF_YUV10_BT656 (2 16)
+#define VNMC_INF_YUV10_BT601 (3 16)
#define VNMC_INF_YUV16(5 16)
#define VNMC_VUP (1 10)
#define VNMC_IM_ODD (0 3)
@@ -275,6 +277,10 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
vnmc |= priv-pdata-flags RCAR_VIN_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
Aren't you missing a break here ?
+ case V4L2_MBUS_FMT_YUYV10_2X10:
+ /* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
+ vnmc |= priv-pdata-flags RCAR_VIN_BT656 ?
+ VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
You should add one here as well. Although not strictly necessary, it would
help to avoid making the same mistake again.
The rest looks good to me, but I'm not familiar with the hardware, so I'll let
Valentine have the last word.
Thanks, looks good to me.
default:
break;
}
@@ -1003,6 +1009,7 @@ static int rcar_vin_get_formats(struct
soc_camera_device *icd, unsigned int idx, switch (code) {
case V4L2_MBUS_FMT_YUYV8_1X16:
case V4L2_MBUS_FMT_YUYV8_2X8:
+ case V4L2_MBUS_FMT_YUYV10_2X10:
if (cam-extra_fmt)
break;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: soc_camera: rcar_vin: Add preliminary R-Car M2 support
On 12/26/2013 06:18 PM, Laurent Pinchart wrote:
Hi Valentine,
Thank you for the patch.
On Tuesday 24 December 2013 00:28:06 Valentine Barshak wrote:
This adds R-Car M2 (R8A7791) VIN support.
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
---
drivers/media/platform/soc_camera/rcar_vin.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c index 6866bb4..8b79727
100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -106,6 +106,7 @@
#define VIN_MAX_HEIGHT2048
enum chip_id {
+ RCAR_M2,
RCAR_H2,
What about renaming RCAR_H2 to RCAR_GEN2 instead, and using RCAR_GEN2 for both
r8a7790 and r8a7791 (but keeping the r8a7790-vin and r8a7791-vin device
IDs as you've done below) ? They're identical so far (at least from what's
implemented in the driver, you might be aware of features specific to the H2
or M2 that are not yet supported but will be implemented in the near future).
Yes, the driver won't see any difference at this point.
The h/w (at least the input data formats supported) seems a bit different
though.
The M2 variant doesn't seem to support 4-bit data (AOT H2).
I'm not aware or any M2 or H2 specific features that need to be implemented in
the near future.
I've preferred to keep them separate just in case.
I wouldn't mind to use the same (GEN2) id for both but we may need to split
them in the future.
RCAR_H1,
RCAR_M1,
@@ -302,8 +303,8 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
dmr = 0;
break;
case V4L2_PIX_FMT_RGB32:
- if (priv-chip == RCAR_H2 || priv-chip == RCAR_H1 ||
- priv-chip == RCAR_E1) {
+ if (priv-chip == RCAR_M2 || priv-chip == RCAR_H2 ||
+ priv-chip == RCAR_H1 || priv-chip == RCAR_E1) {
dmr = VNDMR_EXRGB;
break;
}
@@ -1384,6 +1385,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops =
{ };
static struct platform_device_id rcar_vin_id_table[] = {
+ { r8a7791-vin, RCAR_M2 },
{ r8a7790-vin, RCAR_H2 },
{ r8a7779-vin, RCAR_H1 },
{ r8a7778-vin, RCAR_M1 },
Thanks,
Val.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] media: soc_camera: rcar_vin: Add preliminary R-Car M2 support
This adds R-Car M2 (R8A7791) VIN support. Both H2 and M2
variants look the same from the driver's point of view,
so use GEN2 id for both.
Changes in V2:
* Used the same (RCAR_GEN2) id for both H2 and M2 variants
since they are no different from the driver's point of view.
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
---
drivers/media/platform/soc_camera/rcar_vin.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 6866bb4..3b1c05a 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -106,7 +106,7 @@
#define VIN_MAX_HEIGHT 2048
enum chip_id {
- RCAR_H2,
+ RCAR_GEN2,
RCAR_H1,
RCAR_M1,
RCAR_E1,
@@ -302,7 +302,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
dmr = 0;
break;
case V4L2_PIX_FMT_RGB32:
- if (priv-chip == RCAR_H2 || priv-chip == RCAR_H1 ||
+ if (priv-chip == RCAR_GEN2 || priv-chip == RCAR_H1 ||
priv-chip == RCAR_E1) {
dmr = VNDMR_EXRGB;
break;
@@ -1384,7 +1384,8 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
};
static struct platform_device_id rcar_vin_id_table[] = {
- { r8a7790-vin, RCAR_H2 },
+ { r8a7791-vin, RCAR_GEN2 },
+ { r8a7790-vin, RCAR_GEN2 },
{ r8a7779-vin, RCAR_H1 },
{ r8a7778-vin, RCAR_M1 },
{ uPD35004-vin, RCAR_E1 },
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: soc_camera: rcar_vin: Add preliminary R-Car M2 support
This adds R-Car M2 (R8A7791) VIN support.
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
---
drivers/media/platform/soc_camera/rcar_vin.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 6866bb4..8b79727 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -106,6 +106,7 @@
#define VIN_MAX_HEIGHT 2048
enum chip_id {
+ RCAR_M2,
RCAR_H2,
RCAR_H1,
RCAR_M1,
@@ -302,8 +303,8 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
dmr = 0;
break;
case V4L2_PIX_FMT_RGB32:
- if (priv-chip == RCAR_H2 || priv-chip == RCAR_H1 ||
- priv-chip == RCAR_E1) {
+ if (priv-chip == RCAR_M2 || priv-chip == RCAR_H2 ||
+ priv-chip == RCAR_H1 || priv-chip == RCAR_E1) {
dmr = VNDMR_EXRGB;
break;
}
@@ -1384,6 +1385,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
};
static struct platform_device_id rcar_vin_id_table[] = {
+ { r8a7791-vin, RCAR_M2 },
{ r8a7790-vin, RCAR_H2 },
{ r8a7779-vin, RCAR_H1 },
{ r8a7778-vin, RCAR_M1 },
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] media: i2c: Add ADV761X support
On 11/29/2013 02:45 PM, Lars-Peter Clausen wrote: On 11/29/2013 11:37 AM, Linus Walleij wrote: On Wed, Nov 27, 2013 at 5:40 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: (CC'ing Linus Walleij, Wolfram Sang and LAKML) On Wednesday 27 November 2013 16:32:01 Valentine wrote: On 11/27/2013 04:14 PM, Hans Verkuil wrote: Yes, of course. Although the adv7604 has two interrupt lines, so if you would want to use the second, then that would still have to be specified through the platform data. In this case the GPIO should be configured as interrupt source in the platform code. But this doesn't seem to work with R-Car GPIO since it is initialized later, and the gpio_to_irq function returns an error. The simplest way seemed to use a GPIO number in the platform data to have the adv driver configure the pin and request the IRQ. I'm not sure how to easily defer I2C board info IRQ setup (and camera/subdevice probing) until GPIO driver is ready. Good question. This looks like a core problem to me, not specific to the adv761x driver. Linus, Wolfram, do you have a comment on that ? So we recently has a large-ish discussion involving me, Stephen Warren and Jean-Christophe, leading to the conclusion that the gpio_chip and irq_chip abstractions are orthogonal, and you should be able to request a GPIO or IRQ without interacting with the other subsystem. Specifically you should be able to request an IRQ from the irq_chip portions of the driver without first requesting the GPIO line. Some drivers already support this. We added an internal API to the gpiolib so that the lib, *internally* can be made aware that a certain GPIO line is used for IRQs, see commit d468bf9ecaabd3bf3a6134e5a369ced82b1d1ca1 gpio: add API to be strict about GPIO IRQ usage So I guess the answer to the question is something like, fix the GPIO driver to stop requiring the GPIO lines to be requested and configured before being used as IRQs, delete that code, and while you're at it add a call to gpiod_lock_as_irq() to your GPIO driver in the right spot: examples are on the mailing list and my mark-irqs branch in the GPIO tree. As far as I understand it this already works more or less with the driver. The problem is that the IRQ numbers are dynamically allocated, while the GPIO numbers apparently are not. So the board code knows the the GPIO number at compile time and can pass this to the diver which then does a gpio_to_irq to lookup the IRQ number. This is correct. This of course isn't really a problem with devicetree, but only with platform board code. I'm not sure what's the difference here and why it is not a problem with devicetree? The other problem with R-Car GPIO driver is that it apparently does not support level IRQs. - Lars Thanks, Val. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] media: i2c: Add ADV761X support
On 11/27/2013 12:21 PM, Hans Verkuil wrote:
On 11/26/2013 10:28 PM, Valentine wrote:
On 11/20/2013 07:53 PM, Valentine wrote:
On 11/20/2013 07:42 PM, Hans Verkuil wrote:
Hi Valentine,
Hi Hans,
Hi Hans,
Did you ever look at this adv7611 driver:
https://github.com/Xilinx/linux-xlnx/commit/610b9d5de22ae7c0047c65a07e4afa42af2daa12
No, I missed that one somehow, although I did search for the adv7611/7612
before implementing this one.
I'm going to look closer at the patch and test it.
I've tried the patch and I doubt that it was ever tested on adv7611.
I haven't been able to make it work so far. Here's the description of some of
the issues
I've encountered.
The patch does not apply cleanly so I had to make small adjustments just to
make it apply
without changing the functionality.
First of all the driver (adv7604_dummy_client function) does not set default
I2C slave addresses
in the I/O map in case they are not set in the platform data.
This is not needed for 7604, since the default addresses are already set in the
I/O map after chip reset.
However, the map is zeroed on 7611/7612 after power up, and we always have to
set it manually.
So, the platform data for the 7611/2 should always give i2c addresses. That
seems
reasonable.
Yes, but currently the comment in include/media/adv7604.h says
i2c addresses: 0 == use default, and this is true for 7604, but
it doesn't work for 7611.
Probably the recommended value from the docs should be set by
the driver in case an I2C address is zero in the platform data.
This will help us to keep the same approach across all 76xx chips.
I had to implement the IRQ handler since the soc_camera model does not use
interrupt_service_routine subdevice callback and R-Car VIN knows nothing about
adv7612
interrupt routed to a GPIO pin.
So I had to schedule a workqueue and call adv7604_isr from there in case an
interrupt happens.
For our systems the adv7604 interrupts is not always hooked up to a gpio irq,
instead
a register has to be read to figure out which device actually produced the irq.
So I
want to keep the interrupt_service_routine(). However, adding a gpio field to
the
platform_data that, if set, will tell the driver to request an irq and setup a
workqueue that calls interrupt_service_routine() would be fine with me. That
will
benefit a lot of people since using gpios is much more common.
The driver enables multiple interrupts on the chip, however, the adv7604_isr
callback doesn't
seem to handle them correctly.
According to the docs:
If an interrupt event occurs, and then a second interrupt event occurs before
the system controller
has cleared or masked the first interrupt event, the ADV7611 does not generate a
second interrupt signal.
However, the interrupt_service_routine doesn't account for that.
For example, in case fmt_change interrupt happens while fmt_change_digital
interrupt is being
processed by the adv7604_isr routine. If fmt_change status is set just before
we clear fmt_change_digital,
we never clear fmt_change. Thus, we end up with fmt_change interrupt missed and
therefore further interrupts disabled.
I've tried to call the adv7604_isr routine in a loop and return from the
worlqueue only when all interrupt status bits are cleared.
This did help a bit, but sometimes I started getting lots of I2C read/write
errors for some reason.
I'm not sure if there is much that can be done about this. The code reads the
interrupt status, then clears the interrupts right after. There is always a
race condition there since this isn't atomic ('read and clear'). Unless
Lars-Peter
has a better idea?
What can be improved, though, is to clear not just the interrupts that were
read, but all the interrupts that are unmasked. You are right, you could
loose an interrupt that way.
I'm also not sure how the dv_timing API should be used.
The internal adv7604 state-timings structure is used when getting mbus format.
However, the driver does not set the structure neither at start-up nor in the
interrupt service callback when format changes.
Is it supposed to be set by the upper level camera driver?
It would be nice if the adv7604 would set up an initial timings format. In our
case it is indeed the bridge driver that sets it up, but in the general case it
is better if the i2c driver also sets an initial timings struct. 720p60 is
generally a good initial value.
The irq certainly shouldn't change timings: changing timings will most likely
require changes in the video buffer sizes, which generally requires stopping
streaming, reconfiguring the pipeline and restarting streaming. That's not
something the i2c driver can do.
The confusion you have with mbus vs dv_timings is that soc_camera lacks
dv_timings
support. It was designed for sensors, although there is now some support for
SDTV
receivers (s/g_std ioctls), but dv_timings support has to be added there as well
along the lines of what is done for s/g_std. Basically it is just
Re: [PATCH V2] media: i2c: Add ADV761X support
On 11/27/2013 04:14 PM, Hans Verkuil wrote:
Hi Laurent,
On 11/27/13 12:39, Laurent Pinchart wrote:
Hi Hans,
On Wednesday 27 November 2013 09:21:22 Hans Verkuil wrote:
On 11/26/2013 10:28 PM, Valentine wrote:
On 11/20/2013 07:53 PM, Valentine wrote:
On 11/20/2013 07:42 PM, Hans Verkuil wrote:
Hi Valentine,
Hi Hans,
Did you ever look at this adv7611 driver:
https://github.com/Xilinx/linux-xlnx/commit/610b9d5de22ae7c0047c65a07e4a
fa42af2daa12
No, I missed that one somehow, although I did search for the adv7611/7612
before implementing this one. I'm going to look closer at the patch and
test it.
I've tried the patch and I doubt that it was ever tested on adv7611.
I haven't been able to make it work so far. Here's the description of some
of the issues I've encountered.
The patch does not apply cleanly so I had to make small adjustments just
to make it apply without changing the functionality.
First of all the driver (adv7604_dummy_client function) does not set
default I2C slave addresses in the I/O map in case they are not set in
the platform data.
This is not needed for 7604, since the default addresses are already set
in the I/O map after chip reset. However, the map is zeroed on 7611/7612
after power up, and we always have to set it manually.
So, the platform data for the 7611/2 should always give i2c addresses. That
seems reasonable.
I had to implement the IRQ handler since the soc_camera model does not use
interrupt_service_routine subdevice callback and R-Car VIN knows nothing
about adv7612 interrupt routed to a GPIO pin.
So I had to schedule a workqueue and call adv7604_isr from there in case
an interrupt happens.
For our systems the adv7604 interrupts is not always hooked up to a gpio
irq, instead a register has to be read to figure out which device actually
produced the irq.
Where is that register located ? Shouldn't it be modeled as an interrupt
controller ?
It's a PCIe interrupt whose handler needs to read several FPGA registers
in order to figure out which interrupt was actually triggered. I don't
know enough about interrupt controller to understand whether it can be
modeled as a 'standard' interrupt.
So I want to keep the interrupt_service_routine(). However, adding a gpio
field to the platform_data that, if set, will tell the driver to request an
irq and setup a workqueue that calls interrupt_service_routine() would be
fine with me. That will benefit a lot of people since using gpios is much
more common.
We should use the i2c_board_info.irq field for that, not a field in the
platform data structure. The IRQ line could be hooked up to a non-GPIO IRQ.
Yes, of course. Although the adv7604 has two interrupt lines, so if you
would want to use the second, then that would still have to be specified
through the platform data.
In this case the GPIO should be configured as interrupt source in the platform
code. But this doesn't seem to work with R-Car GPIO since it is initialized
later, and the gpio_to_irq function returns an error.
The simplest way seemed to use a GPIO number in the platform data
to have the adv driver configure the pin and request the IRQ.
I'm not sure how to easily defer I2C board info IRQ setup (and camera/subdevice
probing)
until GPIO driver is ready.
The driver enables multiple interrupts on the chip, however, the
adv7604_isr callback doesn't seem to handle them correctly.
According to the docs:
If an interrupt event occurs, and then a second interrupt event occurs
before the system controller has cleared or masked the first interrupt
event, the ADV7611 does not generate a second interrupt signal.
However, the interrupt_service_routine doesn't account for that.
For example, in case fmt_change interrupt happens while fmt_change_digital
interrupt is being processed by the adv7604_isr routine. If fmt_change
status is set just before we clear fmt_change_digital, we never clear
fmt_change. Thus, we end up with fmt_change interrupt missed and
therefore further interrupts disabled. I've tried to call the adv7604_isr
routine in a loop and return from the worlqueue only when all interrupt
status bits are cleared. This did help a bit, but sometimes I started
getting lots of I2C read/write errors for some reason.
I'm not sure if there is much that can be done about this. The code reads
the interrupt status, then clears the interrupts right after. There is
always a race condition there since this isn't atomic ('read and clear').
Unless Lars-Peter has a better idea?
What can be improved, though, is to clear not just the interrupts that were
read, but all the interrupts that are unmasked. You are right, you could
loose an interrupt that way.
Wouldn't level-trigerred interrupts fix the issue ?
In this case we need to disable the IRQ line in the IRQ handler and re-enable
it in the workqueue.
(we can't call the interrupt service routine from the interrupt context.)
This however didn't seem to work with R-Car GPIO.
Calling disable_irq_nosync(irq
Re: [PATCH V2] media: i2c: Add ADV761X support
On 11/27/2013 05:07 PM, Lars-Peter Clausen wrote: On 11/27/2013 01:32 PM, Valentine wrote: On 11/27/2013 04:14 PM, Hans Verkuil wrote: Hi Laurent, On 11/27/13 12:39, Laurent Pinchart wrote: Hi Hans, On Wednesday 27 November 2013 09:21:22 Hans Verkuil wrote: On 11/26/2013 10:28 PM, Valentine wrote: On 11/20/2013 07:53 PM, Valentine wrote: On 11/20/2013 07:42 PM, Hans Verkuil wrote: Hi Valentine, Hi Hans, Did you ever look at this adv7611 driver: https://github.com/Xilinx/linux-xlnx/commit/610b9d5de22ae7c0047c65a07e4a fa42af2daa12 No, I missed that one somehow, although I did search for the adv7611/7612 before implementing this one. I'm going to look closer at the patch and test it. I've tried the patch and I doubt that it was ever tested on adv7611. I haven't been able to make it work so far. Here's the description of some of the issues I've encountered. The patch does not apply cleanly so I had to make small adjustments just to make it apply without changing the functionality. First of all the driver (adv7604_dummy_client function) does not set default I2C slave addresses in the I/O map in case they are not set in the platform data. This is not needed for 7604, since the default addresses are already set in the I/O map after chip reset. However, the map is zeroed on 7611/7612 after power up, and we always have to set it manually. So, the platform data for the 7611/2 should always give i2c addresses. That seems reasonable. I had to implement the IRQ handler since the soc_camera model does not use interrupt_service_routine subdevice callback and R-Car VIN knows nothing about adv7612 interrupt routed to a GPIO pin. So I had to schedule a workqueue and call adv7604_isr from there in case an interrupt happens. For our systems the adv7604 interrupts is not always hooked up to a gpio irq, instead a register has to be read to figure out which device actually produced the irq. Where is that register located ? Shouldn't it be modeled as an interrupt controller ? It's a PCIe interrupt whose handler needs to read several FPGA registers in order to figure out which interrupt was actually triggered. I don't know enough about interrupt controller to understand whether it can be modeled as a 'standard' interrupt. So I want to keep the interrupt_service_routine(). However, adding a gpio field to the platform_data that, if set, will tell the driver to request an irq and setup a workqueue that calls interrupt_service_routine() would be fine with me. That will benefit a lot of people since using gpios is much more common. We should use the i2c_board_info.irq field for that, not a field in the platform data structure. The IRQ line could be hooked up to a non-GPIO IRQ. Yes, of course. Although the adv7604 has two interrupt lines, so if you would want to use the second, then that would still have to be specified through the platform data. In this case the GPIO should be configured as interrupt source in the platform code. But this doesn't seem to work with R-Car GPIO since it is initialized later, and the gpio_to_irq function returns an error. The simplest way seemed to use a GPIO number in the platform data to have the adv driver configure the pin and request the IRQ. I'm not sure how to easily defer I2C board info IRQ setup (and camera/subdevice probing) until GPIO driver is ready. The GPIO driver should set up the GPIO pin as a interrupt pin when the interrupt is requested. We should not have to add hacks to adv7604 driver to workaround a broken GPIO driver. The GPIO driver does set up the pin as IRQ when the interrupt is requested. The problem is that we can't get the IRQ number from the GPIO pin number until the GPIO driver is started, which happens after the I2C device is registered by the platform code. So, the platform (board) init can't set up the i2c board info IRQ. Using GPIO numbers in platform data seems a simple solution to that. Besides, the chip supports two IRQ lines (as Hans has mentioned), while the I2C board info has only one irq member. I'm not sure that gpio_to_irq is supposed to always work (even at early board initialization) and never return -EPROBE_DEFER. If it is, then it's a GPIO driver issue. Otherwise, this is a question of I2C slave deferred probing, I think, which is not that simple. The driver enables multiple interrupts on the chip, however, the adv7604_isr callback doesn't seem to handle them correctly. According to the docs: If an interrupt event occurs, and then a second interrupt event occurs before the system controller has cleared or masked the first interrupt event, the ADV7611 does not generate a second interrupt signal. However, the interrupt_service_routine doesn't account for that. For example, in case fmt_change interrupt happens while fmt_change_digital interrupt is being processed by the adv7604_isr routine. If fmt_change status is set just before we clear fmt_change_digital, we never clear fmt_change. Thus, we end up
Re: [PATCH V2] media: i2c: Add ADV761X support
On 11/20/2013 07:53 PM, Valentine wrote: On 11/20/2013 07:42 PM, Hans Verkuil wrote: Hi Valentine, Hi Hans, Did you ever look at this adv7611 driver: https://github.com/Xilinx/linux-xlnx/commit/610b9d5de22ae7c0047c65a07e4afa42af2daa12 No, I missed that one somehow, although I did search for the adv7611/7612 before implementing this one. I'm going to look closer at the patch and test it. I've tried the patch and I doubt that it was ever tested on adv7611. I haven't been able to make it work so far. Here's the description of some of the issues I've encountered. The patch does not apply cleanly so I had to make small adjustments just to make it apply without changing the functionality. First of all the driver (adv7604_dummy_client function) does not set default I2C slave addresses in the I/O map in case they are not set in the platform data. This is not needed for 7604, since the default addresses are already set in the I/O map after chip reset. However, the map is zeroed on 7611/7612 after power up, and we always have to set it manually. I had to implement the IRQ handler since the soc_camera model does not use interrupt_service_routine subdevice callback and R-Car VIN knows nothing about adv7612 interrupt routed to a GPIO pin. So I had to schedule a workqueue and call adv7604_isr from there in case an interrupt happens. The driver enables multiple interrupts on the chip, however, the adv7604_isr callback doesn't seem to handle them correctly. According to the docs: If an interrupt event occurs, and then a second interrupt event occurs before the system controller has cleared or masked the first interrupt event, the ADV7611 does not generate a second interrupt signal. However, the interrupt_service_routine doesn't account for that. For example, in case fmt_change interrupt happens while fmt_change_digital interrupt is being processed by the adv7604_isr routine. If fmt_change status is set just before we clear fmt_change_digital, we never clear fmt_change. Thus, we end up with fmt_change interrupt missed and therefore further interrupts disabled. I've tried to call the adv7604_isr routine in a loop and return from the worlqueue only when all interrupt status bits are cleared. This did help a bit, but sometimes I started getting lots of I2C read/write errors for some reason. I'm also not sure how the dv_timing API should be used. The internal adv7604 state-timings structure is used when getting mbus format. However, the driver does not set the structure neither at start-up nor in the interrupt service callback when format changes. Is it supposed to be set by the upper level camera driver? For example, when the camera driver receives v4l2_subdev_notify(sd, ADV7604_FMT_CHANGE, NULL); does it have to do the following: v4l2_subdev_call(sd, video, query_dv_timings, timings); v4l2_subdev_call(sd, video, s_dv_timings, timings);? I don't think that this is how it should work. Anyways, I've tried to call query_dv_timings to initialize state-timings from the interrupt service workqueue. I've been able to catch format change events though it looks very sloppy at the moment. BTW, the driver doesn't provide any locking for reading/writing the state-settings which I believe could cause some issues reading incomplete format when it changes asynchronously to the subdevice g_mbus_fmt operation. It adds adv761x support to the adv7604 in a pretty clean way. Doesn't seem that clean to me after having a look at it. It tries to handle both 7604 and 7611 chips in the same way, though, I'm not exactly sure if it's a good idea since 7611/12 is a pure HDMI receiver with no analog inputs. Thinking it over I prefer to use that code (although you will have to add the soc-camera hack for the time being) over your driver. Others need adv7611 support as well, but with all the dv_timings etc. features that are removed in your driver. So I am thinking that it is easier to merge the xilinx version and add whatever you need on top of that. To be honest I'm more inclined to drop non-soc camera support from my driver and move it to media/i2c/soc_camera/ the moment. That would be easier. I don't have any h/w I could test the xilinx version with non-SoC camera interface. Currently I'm trying to play with core settings since even though I've managed to glue adv7611 support and the R-Car VIN SoC camera driver I haven't been able to capture a frame. Thanks, Val. Regards, Hans Thanks, Val. On 11/20/13 13:24, Valentine wrote: On 11/20/2013 03:19 PM, Hans Verkuil wrote: Hi Valentine, Hi Hans, On 11/20/13 11:14, Valentine wrote: On 11/19/2013 01:50 PM, Hans Verkuil wrote: Hi Valentine, Hi Hans, thanks for your review. I don't entirely understand how you use this driver with soc-camera. Since soc-camera doesn't support FMT_CHANGE notifies it can't really act on it. Did you hack soc-camera to do this? I did not. The format is queried before reading the frame
Re: [PATCH V2] media: i2c: Add ADV761X support
On 11/27/2013 01:43 AM, Lars-Peter Clausen wrote: On 11/26/2013 10:28 PM, Valentine wrote: On 11/20/2013 07:53 PM, Valentine wrote: On 11/20/2013 07:42 PM, Hans Verkuil wrote: Hi Valentine, Hi Hans, Did you ever look at this adv7611 driver: https://github.com/Xilinx/linux-xlnx/commit/610b9d5de22ae7c0047c65a07e4afa42af2daa12 No, I missed that one somehow, although I did search for the adv7611/7612 before implementing this one. I'm going to look closer at the patch and test it. I've tried the patch and I doubt that it was ever tested on adv7611. It was and it works. That's good to hear. I haven't been able to make it work so far. Here's the description of some of the issues I've encountered. The patch does not apply cleanly so I had to make small adjustments just to make it apply without changing the functionality. I have an updated version of the patch, which I intend to submit soon. That's great, thanks! [...] I'd also appreciate your thoughts about the issues I've described, which have been replaced by [...] here. It adds adv761x support to the adv7604 in a pretty clean way. Doesn't seem that clean to me after having a look at it. It tries to handle both 7604 and 7611 chips in the same way, though, I'm not exactly sure if it's a good idea since 7611/12 is a pure HDMI receiver with no analog inputs. It is the same HDMI core (with minor modifications) though. So you end end up with largely the same code for the 7604 and the 7611. Yes, but that's about half of the code while 7611 doesn't really need the non-HDMI part. Just thought that we may end up with a bigger mess if we keep adding adv76xx support to 7604 driver. - Lars Thanks, Val. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] media: i2c: Add ADV761X support
On 11/19/2013 01:50 PM, Hans Verkuil wrote: Hi Valentine, Hi Hans, thanks for your review. I don't entirely understand how you use this driver with soc-camera. Since soc-camera doesn't support FMT_CHANGE notifies it can't really act on it. Did you hack soc-camera to do this? I did not. The format is queried before reading the frame by the user-space. I'm not sure if there's some kind of generic interface to notify the camera layer about format change events. Different subdevices use different FMT_CHANGE defines for that. I've implemented the format change notifier based on the adv7604 in hope that it may be useful later. The way it stands I would prefer to see a version of the driver without soc-camera support. I wouldn't have a problem merging that as this driver is a good base for further development. I've tried to implement the driver base good enough to work with both SoC and non-SoC cameras since I don't think having 2 separate drivers for different camera models is a good idea. The problem is that I'm using it with R-Car VIN SoC camera driver and don't have any other h/w. Having a platform data quirk for SoC camera in the subdevice driver seemed simple and clean enough. Hacking SoC camera to make it support both generic and SoC cam subdevices doesn't seem that straightforward to me. Re-implementing R-Car VIN as a non-SoC model seems quite a big task that involves a lot of regression testing with other R-Car boards that use different subdevices with VIN. What would you suggest? You do however have to add support for the V4L2_CID_DV_RX_POWER_PRESENT control. It's easy to implement and that way apps can be notified when the hotplug changes value. OK, thanks. Regards, Hans Thanks, Val. On 11/15/13 13:54, Valentine Barshak wrote: This adds ADV7611/ADV7612 Xpressview HDMI Receiver base support. Only one HDMI port is supported on ADV7612. The code is based on the ADV7604 driver, and ADV7612 patch by Shinobu Uehara shinobu.uehara...@renesas.com Changes in version 2: * Used platform data for I2C addresses setup. The driver should work with both SoC and non-SoC camera models. * Dropped unnecessary code and unsupported callbacks. * Implemented IRQ handling for format change detection. Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com --- drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/adv761x.c | 1009 +++ include/media/adv761x.h | 38 ++ 4 files changed, 1059 insertions(+) create mode 100644 drivers/media/i2c/adv761x.c create mode 100644 include/media/adv761x.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 75c8a03..2388642 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -206,6 +206,17 @@ config VIDEO_ADV7604 To compile this driver as a module, choose M here: the module will be called adv7604. +config VIDEO_ADV761X + tristate Analog Devices ADV761X decoder + depends on VIDEO_V4L2 I2C + ---help--- + Support for the Analog Devices ADV7611/ADV7612 video decoder. + + This is an Analog Devices Xpressview HDMI Receiver. + + To compile this driver as a module, choose M here: the + module will be called adv761x. + config VIDEO_ADV7842 tristate Analog Devices ADV7842 decoder depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index e03f177..d78d627 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o +obj-$(CONFIG_VIDEO_ADV761X) += adv761x.o obj-$(CONFIG_VIDEO_ADV7842) += adv7842.o obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o diff --git a/drivers/media/i2c/adv761x.c b/drivers/media/i2c/adv761x.c new file mode 100644 index 000..95939f5 --- /dev/null +++ b/drivers/media/i2c/adv761x.c @@ -0,0 +1,1009 @@ +/* + * adv761x Analog Devices ADV761X HDMI receiver driver + * + * Copyright (C) 2013 Cogent Embedded, Inc. + * Copyright (C) 2013 Renesas Electronics Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/errno.h +#include linux/gpio.h +#include linux/i2c.h +#include linux/init.h +#include linux/interrupt.h +#include linux/kernel.h +#include linux/module.h +#include linux
Re: [PATCH V2] media: i2c: Add ADV761X support
On 11/20/2013 03:19 PM, Hans Verkuil wrote: Hi Valentine, Hi Hans, On 11/20/13 11:14, Valentine wrote: On 11/19/2013 01:50 PM, Hans Verkuil wrote: Hi Valentine, Hi Hans, thanks for your review. I don't entirely understand how you use this driver with soc-camera. Since soc-camera doesn't support FMT_CHANGE notifies it can't really act on it. Did you hack soc-camera to do this? I did not. The format is queried before reading the frame by the user-space. I'm not sure if there's some kind of generic interface to notify the camera layer about format change events. Different subdevices use different FMT_CHANGE defines for that. I've implemented the format change notifier based on the adv7604 in hope that it may be useful later. Yes, I need to generalize the FMT_CHANGE event. But what happens if you are streaming and the HDMI connector is unplugged? Or plugged back in again, possibly with a larger resolution? I'm not sure if the soc_camera driver supports such scenarios. It doesn't. Currently it's up to the UI to poll the format and do the necessary changes. Otherwise the picture will be incorrect. The way it stands I would prefer to see a version of the driver without soc-camera support. I wouldn't have a problem merging that as this driver is a good base for further development. I've tried to implement the driver base good enough to work with both SoC and non-SoC cameras since I don't think having 2 separate drivers for different camera models is a good idea. The problem is that I'm using it with R-Car VIN SoC camera driver and don't have any other h/w. Having a platform data quirk for SoC camera in the subdevice driver seemed simple and clean enough. I hate it, but it isn't something you can do anything about. So it will have to do for now. Hacking SoC camera to make it support both generic and SoC cam subdevices doesn't seem that straightforward to me. Guennadi, what is the status of this? I'm getting really tired of soc-camera infecting sub-devices. Subdev drivers should be independent of any bridge driver using them, but soc-camera keeps breaking that. It's driving me nuts. I'll be honest, it's getting to the point that I want to just NACK any future subdev drivers that depend on soc-camera, just to force a solution. There is no technical reason for this dependency, it just takes some time to fix soc-camera. Re-implementing R-Car VIN as a non-SoC model seems quite a big task that involves a lot of regression testing with other R-Car boards that use different subdevices with VIN. What would you suggest? Let's leave it as-is for now :-( I'm not happy, but as I said, it's not your fault. OK, thanks. Once a better solution is available we can remove the quirk. Regards, Hans Thanks, Val. You do however have to add support for the V4L2_CID_DV_RX_POWER_PRESENT control. It's easy to implement and that way apps can be notified when the hotplug changes value. OK, thanks. Regards, Hans Thanks, Val. On 11/15/13 13:54, Valentine Barshak wrote: This adds ADV7611/ADV7612 Xpressview HDMI Receiver base support. Only one HDMI port is supported on ADV7612. The code is based on the ADV7604 driver, and ADV7612 patch by Shinobu Uehara shinobu.uehara...@renesas.com Changes in version 2: * Used platform data for I2C addresses setup. The driver should work with both SoC and non-SoC camera models. * Dropped unnecessary code and unsupported callbacks. * Implemented IRQ handling for format change detection. Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] media: i2c: Add ADV761X support
On 11/20/2013 07:42 PM, Hans Verkuil wrote: Hi Valentine, Did you ever look at this adv7611 driver: https://github.com/Xilinx/linux-xlnx/commit/610b9d5de22ae7c0047c65a07e4afa42af2daa12 No, I missed that one somehow, although I did search for the adv7611/7612 before implementing this one. I'm going to look closer at the patch and test it. It adds adv761x support to the adv7604 in a pretty clean way. Thinking it over I prefer to use that code (although you will have to add the soc-camera hack for the time being) over your driver. Others need adv7611 support as well, but with all the dv_timings etc. features that are removed in your driver. So I am thinking that it is easier to merge the xilinx version and add whatever you need on top of that. Thanks, Val. Regards, Hans On 11/20/13 13:24, Valentine wrote: On 11/20/2013 03:19 PM, Hans Verkuil wrote: Hi Valentine, Hi Hans, On 11/20/13 11:14, Valentine wrote: On 11/19/2013 01:50 PM, Hans Verkuil wrote: Hi Valentine, Hi Hans, thanks for your review. I don't entirely understand how you use this driver with soc-camera. Since soc-camera doesn't support FMT_CHANGE notifies it can't really act on it. Did you hack soc-camera to do this? I did not. The format is queried before reading the frame by the user-space. I'm not sure if there's some kind of generic interface to notify the camera layer about format change events. Different subdevices use different FMT_CHANGE defines for that. I've implemented the format change notifier based on the adv7604 in hope that it may be useful later. Yes, I need to generalize the FMT_CHANGE event. But what happens if you are streaming and the HDMI connector is unplugged? Or plugged back in again, possibly with a larger resolution? I'm not sure if the soc_camera driver supports such scenarios. It doesn't. Currently it's up to the UI to poll the format and do the necessary changes. Otherwise the picture will be incorrect. The way it stands I would prefer to see a version of the driver without soc-camera support. I wouldn't have a problem merging that as this driver is a good base for further development. I've tried to implement the driver base good enough to work with both SoC and non-SoC cameras since I don't think having 2 separate drivers for different camera models is a good idea. The problem is that I'm using it with R-Car VIN SoC camera driver and don't have any other h/w. Having a platform data quirk for SoC camera in the subdevice driver seemed simple and clean enough. I hate it, but it isn't something you can do anything about. So it will have to do for now. Hacking SoC camera to make it support both generic and SoC cam subdevices doesn't seem that straightforward to me. Guennadi, what is the status of this? I'm getting really tired of soc-camera infecting sub-devices. Subdev drivers should be independent of any bridge driver using them, but soc-camera keeps breaking that. It's driving me nuts. I'll be honest, it's getting to the point that I want to just NACK any future subdev drivers that depend on soc-camera, just to force a solution. There is no technical reason for this dependency, it just takes some time to fix soc-camera. Re-implementing R-Car VIN as a non-SoC model seems quite a big task that involves a lot of regression testing with other R-Car boards that use different subdevices with VIN. What would you suggest? Let's leave it as-is for now :-( I'm not happy, but as I said, it's not your fault. OK, thanks. Once a better solution is available we can remove the quirk. Regards, Hans Thanks, Val. You do however have to add support for the V4L2_CID_DV_RX_POWER_PRESENT control. It's easy to implement and that way apps can be notified when the hotplug changes value. OK, thanks. Regards, Hans Thanks, Val. On 11/15/13 13:54, Valentine Barshak wrote: This adds ADV7611/ADV7612 Xpressview HDMI Receiver base support. Only one HDMI port is supported on ADV7612. The code is based on the ADV7604 driver, and ADV7612 patch by Shinobu Uehara shinobu.uehara...@renesas.com Changes in version 2: * Used platform data for I2C addresses setup. The driver should work with both SoC and non-SoC camera models. * Dropped unnecessary code and unsupported callbacks. * Implemented IRQ handling for format change detection. Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] media: i2c: Add ADV761X support
This adds ADV7611/ADV7612 Xpressview HDMI Receiver base
support. Only one HDMI port is supported on ADV7612.
The code is based on the ADV7604 driver, and ADV7612 patch by
Shinobu Uehara shinobu.uehara...@renesas.com
Changes in version 2:
* Used platform data for I2C addresses setup. The driver
should work with both SoC and non-SoC camera models.
* Dropped unnecessary code and unsupported callbacks.
* Implemented IRQ handling for format change detection.
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
---
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/adv761x.c | 1009 +++
include/media/adv761x.h | 38 ++
4 files changed, 1059 insertions(+)
create mode 100644 drivers/media/i2c/adv761x.c
create mode 100644 include/media/adv761x.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 75c8a03..2388642 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -206,6 +206,17 @@ config VIDEO_ADV7604
To compile this driver as a module, choose M here: the
module will be called adv7604.
+config VIDEO_ADV761X
+ tristate Analog Devices ADV761X decoder
+ depends on VIDEO_V4L2 I2C
+ ---help---
+ Support for the Analog Devices ADV7611/ADV7612 video decoder.
+
+ This is an Analog Devices Xpressview HDMI Receiver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv761x.
+
config VIDEO_ADV7842
tristate Analog Devices ADV7842 decoder
depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index e03f177..d78d627 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
+obj-$(CONFIG_VIDEO_ADV761X) += adv761x.o
obj-$(CONFIG_VIDEO_ADV7842) += adv7842.o
obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o
diff --git a/drivers/media/i2c/adv761x.c b/drivers/media/i2c/adv761x.c
new file mode 100644
index 000..95939f5
--- /dev/null
+++ b/drivers/media/i2c/adv761x.c
@@ -0,0 +1,1009 @@
+/*
+ * adv761x Analog Devices ADV761X HDMI receiver driver
+ *
+ * Copyright (C) 2013 Cogent Embedded, Inc.
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/errno.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/rwsem.h
+#include linux/slab.h
+#include linux/videodev2.h
+#include media/adv761x.h
+#include media/soc_camera.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+
+#define ADV761X_DRIVER_NAME adv761x
+
+/* VERT_FILTER_LOCKED and DE_REGEN_FILTER_LOCKED flags */
+#define ADV761X_HDMI_F_LOCKED(v) (((v) 0xa0) == 0xa0)
+
+/* Maximum supported resolution */
+#define ADV761X_MAX_WIDTH 1920
+#define ADV761X_MAX_HEIGHT 1080
+
+/* Use SoC camera subdev desc private data for platform_data */
+#define ADV761X_SOC_CAM_QUIRK 0x1
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-2));
+
+struct adv761x_color_format {
+ enum v4l2_mbus_pixelcode code;
+ enum v4l2_colorspace colorspace;
+};
+
+/* Supported color format list */
+static const struct adv761x_color_format adv761x_cfmts[] = {
+ {
+ .code = V4L2_MBUS_FMT_RGB888_1X24,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ },
+};
+
+/* ADV761X descriptor structure */
+struct adv761x_state {
+ struct v4l2_subdev sd;
+ struct media_padpad;
+ struct v4l2_ctrl_handlerctrl_hdl;
+
+ u8 edid[256];
+ unsignededid_blocks;
+
+ struct rw_semaphore rwsem;
+ const struct adv761x_color_format *cfmt;
+ u32 width;
+ u32 height;
+ enum v4l2_field scanmode;
+ u32 status;
+
+ int gpio;
+ int
Re: [PATCH 0/3] media: Add SH-Mobile RCAR-H2 Lager board support
On 11/12/2013 03:42 AM, Laurent Pinchart wrote: Hi Valentine, On Tuesday 24 September 2013 17:38:33 Valentine Barshak wrote: The following patches add ADV7611/ADV7612 HDMI receiver I2C driver and add RCAR H2 SOC support along with ADV761x output format support to rcar_vin soc_camera driver. These changes are needed for SH-Mobile R8A7790 Lager board video input support. Do you plan to submit a v2 ? I need the ADV761x driver pretty soon and I'd like to avoid submitting a competing patch :-) Yes, I plan to submit v2 when it's ready. Currently it's a work in progress. Do you already have anything to submit for the ADV761x support? Thanks, Val. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] media: Add SH-Mobile RCAR-H2 Lager board support
On 10/04/2013 02:13 PM, Hans Verkuil wrote: On 09/24/2013 06:14 PM, Guennadi Liakhovetski wrote: Hi Valentine, Hi, Since patches 2 and 3 here are for soc-camera, I can offer to take all 3 via my tree after all comments to patch 1/3 are addressed and someone (Laurent?) has acked it. Alternatively I can ack the two patches and let all 3 go via another tree, or we can split this series too - no problem with me either way. I prefer to take these patches. 95% of the work is in the first patch adding the new adv driver, and I'm responsible for video receivers/transmitters. There is going to be a revision anyway, so let's wait for v2. Patch 2 doesn't really depend on the other ones. So I think it can be added separately. I'll resubmit it in a bit. The ADV related stuff will be reworked/submitted later. Regards, Hans Thanks, Val. Thanks Guennadi On Tue, 24 Sep 2013, Valentine Barshak wrote: The following patches add ADV7611/ADV7612 HDMI receiver I2C driver and add RCAR H2 SOC support along with ADV761x output format support to rcar_vin soc_camera driver. These changes are needed for SH-Mobile R8A7790 Lager board video input support. Valentine Barshak (3): media: i2c: Add ADV761X support media: rcar_vin: Add preliminary r8a7790 H2 support media: rcar_vin: Add RGB888_1X24 input format support drivers/media/i2c/Kconfig| 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/adv761x.c | 1060 ++ drivers/media/platform/soc_camera/rcar_vin.c | 17 +- include/media/adv761x.h | 28 + 5 files changed, 1114 insertions(+), 3 deletions(-) create mode 100644 drivers/media/i2c/adv761x.c create mode 100644 include/media/adv761x.h -- 1.8.3.1 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: rcar_vin: Add preliminary r8a7790 support
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
---
drivers/media/platform/soc_camera/rcar_vin.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index d02a7e0..b21f777 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -105,6 +105,7 @@
#define VIN_MAX_HEIGHT 2048
enum chip_id {
+ RCAR_H2,
RCAR_H1,
RCAR_M1,
RCAR_E1,
@@ -300,7 +301,8 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
dmr = 0;
break;
case V4L2_PIX_FMT_RGB32:
- if (priv-chip == RCAR_H1 || priv-chip == RCAR_E1) {
+ if (priv-chip == RCAR_H2 || priv-chip == RCAR_H1 ||
+ priv-chip == RCAR_E1) {
dmr = VNDMR_EXRGB;
break;
}
@@ -1381,6 +1383,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
};
static struct platform_device_id rcar_vin_id_table[] = {
+ { r8a7790-vin, RCAR_H2 },
{ r8a7779-vin, RCAR_H1 },
{ r8a7778-vin, RCAR_M1 },
{ uPD35004-vin, RCAR_E1 },
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] media: i2c: Add ADV761X support
On 09/24/2013 06:17 PM, Hans Verkuil wrote:
Hi Valentine,
Hi Hans,
On Tue 24 September 2013 15:38:34 Valentine Barshak wrote:
This adds ADV7611/ADV7612 Dual Port Xpressview
225 MHz HDMI Receiver support.
The code is based on the ADV7604 driver, and ADV7612 patch
by Shinobu Uehara shinobu.uehara...@renesas.com
Thanks for the patch!
I have a few review comments below:
Thanks for taking the time to look at it!
[]
diff --git a/drivers/media/i2c/adv761x.c b/drivers/media/i2c/adv761x.c
new file mode 100644
index 000..bc3dfc3
--- /dev/null
+++ b/drivers/media/i2c/adv761x.c
@@ -0,0 +1,1060 @@
+/*
+ * adv761x Analog Devices ADV761X HDMI receiver driver
+ *
+ * Copyright (C) 2013 Cogent Embedded, Inc.
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/errno.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/videodev2.h
+#include media/adv761x.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+
+#define ADV761X_DRIVER_NAME adv761x
+
+/* VERT_FILTER_LOCKED and DE_REGEN_FILTER_LOCKED flags */
+#define ADV761X_HDMI_F_LOCKED(v) (((v) 0xa0) == 0xa0)
+
+/* Maximum supported resolution */
+#define ADV761X_MAX_WIDTH 1920
+#define ADV761X_MAX_HEIGHT 1080
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-2));
+
+/* I2C map addresses */
+static u8 i2c_cec = 0x40;
+module_param(i2c_cec, byte, 0644);
+MODULE_PARM_DESC(i2c_cec, CEC map 7-bit I2C address (default: 0x40));
+
+static u8 i2c_inf = 0x3e;
+module_param(i2c_inf, byte, 0644);
+MODULE_PARM_DESC(i2c_inf, InfoFrame map 7-bit I2C address (default: 0x3e));
+
+static u8 i2c_dpll = 0x26;
+module_param(i2c_dpll, byte, 0644);
+MODULE_PARM_DESC(i2c_dpll, DPLL map 7-bit I2C address (default: 0x20));
+
+static u8 i2c_rep = 0x32;
+module_param(i2c_rep, byte, 0644);
+MODULE_PARM_DESC(i2c_rep, Repeater map 7-bit I2C address (default: 0x32));
+
+static u8 i2c_edid = 0x36;
+module_param(i2c_edid, byte, 0644);
+MODULE_PARM_DESC(i2c_edid, EDID map 7-bit I2C address (default: 0x36));
+
+static u8 i2c_hdmi = 0x34;
+module_param(i2c_hdmi, byte, 0644);
+MODULE_PARM_DESC(i2c_hdmi, HDMI map 7-bit I2C address (default: 0x34));
+
+static u8 i2c_cp = 0x22;
+module_param(i2c_cp, byte, 0644);
+MODULE_PARM_DESC(i2c_cp, CP map 7-bit I2C address (default: 0x22));
Don't use module options for the i2c addresses. Instead use platform_data.
Boards may have multiple adv761x devices behind e.g. a i2c muxer, so
relying on module options isn't the right method.
Yes, that doesn't look quite right, but I couldn't find a better
solution ATM.
The problem is that this subdevice is going to be used by a soc_camera
driver and the soc_camera interface uses its own platform data for all
I2C subdevices.
Thus, if I pass the I2C addresses in client-dev.platform_data here (as
in adv7604), It's doing to be overwritten by the soc_camera_i2c_init()
function with a soc_camera_subdev_desc data.
Not sure what the correct solution should be. Any suggestions are
greatly appreciated.
+
+struct adv761x_color_format {
+ enum v4l2_mbus_pixelcode code;
+ enum v4l2_colorspace colorspace;
+};
+
[]
+static int adv761x_g_input_status(struct v4l2_subdev *sd, u32 *status)
+{
+ int ret;
+
+ ret = hdmi_read(sd, 0x07);
+ if (ret 0)
+ return ret;
+
+ *status = ADV761X_HDMI_F_LOCKED(ret) ? 0 : V4L2_IN_ST_NO_SIGNAL;
+ return 0;
+}
+
+static int adv761x_cropcap(struct v4l2_subdev *sd, struct v4l2_cropcap *a)
+{
+ u8 progressive;
+ u32 width;
+ u32 height;
+ int ret;
+
+ /* cropping limits */
+ a-bounds.left = 0;
+ a-bounds.top= 0;
+
+ /* get video information */
+ ret = adv761x_get_vid_info(sd, progressive, width, height);
+ if (ret 0) {
+ a-bounds.width = ADV761X_MAX_WIDTH;
+ a-bounds.height = ADV761X_MAX_HEIGHT;
+ } else {
+ a-bounds.width = width;
+ a-bounds.height = height;
+ }
+
+ /* default cropping rectangle */
+ a-defrect
Re: [PATCH 1/3] media: i2c: Add ADV761X support
On 09/24/2013 07:54 PM, Guennadi Liakhovetski wrote: Hi Valentine, Hi Guennadi, On Tue, 24 Sep 2013, Valentine Barshak wrote: This adds ADV7611/ADV7612 Dual Port Xpressview 225 MHz HDMI Receiver support. The code is based on the ADV7604 driver, and ADV7612 patch by Shinobu Uehara shinobu.uehara...@renesas.com Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com IIRC, Laurent is reviewing all new media I2C drivers, I added him to cc. A couple of minor comments from me too, while at it. Thanks! --- drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/adv761x.c | 1060 +++ include/media/adv761x.h | 28 ++ 4 files changed, 1100 insertions(+) create mode 100644 drivers/media/i2c/adv761x.c create mode 100644 include/media/adv761x.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index d18be19..8eede00 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -206,6 +206,17 @@ config VIDEO_ADV7604 To compile this driver as a module, choose M here: the module will be called adv7604. +config VIDEO_ADV761X + tristate Analog Devices ADV761X decoder + depends on VIDEO_V4L2 I2C + ---help--- + Support for the Analog Devices ADV7611/ADV7612 video decoder. + + This is an Analog Devices Dual Port Xpressview HDMI Receiver. Are you sure this driver can handle all adv761x devices? One of the differences even between 7611 and 7612 is, that only 7612 is dual-port, 7611 is single-port. What about 7619? It doesn't claim to support 7619. The help message says that only 7611/7612 are supported. The driver doesn't support port B of the 7612 as it is not used on the h/w I have -- Just like the 7604 driver, this one is based on. This is a preliminary ADV761x support, and more functionality could be added later if needed (including 7619). + + To compile this driver as a module, choose M here: the + module will be called adv761x. + config VIDEO_ADV7842 tristate Analog Devices ADV7842 decoder depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 9f462df..393eb0c 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o +obj-$(CONFIG_VIDEO_ADV761X) += adv761x.o obj-$(CONFIG_VIDEO_ADV7842) += adv7842.o obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o diff --git a/drivers/media/i2c/adv761x.c b/drivers/media/i2c/adv761x.c new file mode 100644 index 000..bc3dfc3 --- /dev/null +++ b/drivers/media/i2c/adv761x.c @@ -0,0 +1,1060 @@ +/* + * adv761x Analog Devices ADV761X HDMI receiver driver + * + * Copyright (C) 2013 Cogent Embedded, Inc. + * Copyright (C) 2013 Renesas Electronics Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include linux/errno.h +#include linux/i2c.h +#include linux/init.h +#include linux/interrupt.h +#include linux/kernel.h +#include linux/module.h +#include linux/slab.h +#include linux/videodev2.h +#include media/adv761x.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-ioctl.h + +#define ADV761X_DRIVER_NAME adv761x + +/* VERT_FILTER_LOCKED and DE_REGEN_FILTER_LOCKED flags */ +#define ADV761X_HDMI_F_LOCKED(v) (((v) 0xa0) == 0xa0) + +/* Maximum supported resolution */ +#define ADV761X_MAX_WIDTH 1920 +#define ADV761X_MAX_HEIGHT 1080 + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, debug level (0-2)); + +/* I2C map addresses */ +static u8 i2c_cec = 0x40; +module_param(i2c_cec, byte, 0644); +MODULE_PARM_DESC(i2c_cec, CEC map 7-bit I2C address (default: 0x40)); + +static u8 i2c_inf = 0x3e; +module_param(i2c_inf, byte, 0644); +MODULE_PARM_DESC(i2c_inf, InfoFrame map 7-bit I2C address (default: 0x3e)); + +static u8 i2c_dpll = 0x26; +module_param(i2c_dpll, byte, 0644); +MODULE_PARM_DESC(i2c_dpll, DPLL map 7-bit I2C address (default: 0x20)); + +static u8 i2c_rep = 0x32; +module_param(i2c_rep, byte, 0644); +MODULE_PARM_DESC(i2c_rep, Repeater map 7-bit I2C
Re: [PATCH 1/3] media: i2c: Add ADV761X support
On 09/25/2013 06:08 PM, Guennadi Liakhovetski wrote: Hi Valentine, Hi Guennadi, On Wed, 25 Sep 2013, Valentine wrote: On 09/24/2013 07:54 PM, Guennadi Liakhovetski wrote: Hi Valentine, Hi Guennadi, On Tue, 24 Sep 2013, Valentine Barshak wrote: This adds ADV7611/ADV7612 Dual Port Xpressview 225 MHz HDMI Receiver support. The code is based on the ADV7604 driver, and ADV7612 patch by Shinobu Uehara shinobu.uehara...@renesas.com Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com IIRC, Laurent is reviewing all new media I2C drivers, I added him to cc. A couple of minor comments from me too, while at it. Thanks! --- drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/adv761x.c | 1060 +++ include/media/adv761x.h | 28 ++ 4 files changed, 1100 insertions(+) create mode 100644 drivers/media/i2c/adv761x.c create mode 100644 include/media/adv761x.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index d18be19..8eede00 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -206,6 +206,17 @@ config VIDEO_ADV7604 To compile this driver as a module, choose M here: the module will be called adv7604. +config VIDEO_ADV761X + tristate Analog Devices ADV761X decoder + depends on VIDEO_V4L2 I2C + ---help--- + Support for the Analog Devices ADV7611/ADV7612 video decoder. + + This is an Analog Devices Dual Port Xpressview HDMI Receiver. Are you sure this driver can handle all adv761x devices? One of the differences even between 7611 and 7612 is, that only 7612 is dual-port, 7611 is single-port. What about 7619? It doesn't claim to support 7619. The help message says that only 7611/7612 are supported. The driver doesn't support port B of the 7612 as it is not used on the h/w I have -- Just like the 7604 driver, this one is based on. This is a preliminary ADV761x support, and more functionality could be added later if needed (including 7619). What I meant, is that the name adv761x implicitly includes any device in the range adv7610-adv7619, which isn't what you support. Maybe it would be better to call the driver adv7611 (or adv7612) and just explain in comments, that you also support the other chip - if you really do. You really can handle single- and double-port cases as well as other differences between them? OK, I can rename it to adv7612. + + To compile this driver as a module, choose M here: the + module will be called adv761x. + config VIDEO_ADV7842 tristate Analog Devices ADV7842 decoder depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 9f462df..393eb0c 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o +obj-$(CONFIG_VIDEO_ADV761X) += adv761x.o obj-$(CONFIG_VIDEO_ADV7842) += adv7842.o obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o diff --git a/drivers/media/i2c/adv761x.c b/drivers/media/i2c/adv761x.c new file mode 100644 index 000..bc3dfc3 --- /dev/null +++ b/drivers/media/i2c/adv761x.c @@ -0,0 +1,1060 @@ +/* + * adv761x Analog Devices ADV761X HDMI receiver driver + * + * Copyright (C) 2013 Cogent Embedded, Inc. + * Copyright (C) 2013 Renesas Electronics Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include linux/errno.h +#include linux/i2c.h +#include linux/init.h +#include linux/interrupt.h +#include linux/kernel.h +#include linux/module.h +#include linux/slab.h +#include linux/videodev2.h +#include media/adv761x.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-ioctl.h + +#define ADV761X_DRIVER_NAME adv761x + +/* VERT_FILTER_LOCKED and DE_REGEN_FILTER_LOCKED flags */ +#define ADV761X_HDMI_F_LOCKED(v) (((v) 0xa0) == 0xa0) + +/* Maximum supported resolution */ +#define ADV761X_MAX_WIDTH 1920 +#define ADV761X_MAX_HEIGHT 1080 + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, debug level (0-2
Re: [PATCH 1/3] media: i2c: Add ADV761X support
On 09/25/2013 08:31 PM, Guennadi Liakhovetski wrote:
On Wed, 25 Sep 2013, Valentine wrote:
On 09/25/2013 06:08 PM, Guennadi Liakhovetski wrote:
[snip]
Using module parameters has a disadvantage, that all instances of this
driver will get the same values, and it is quite possible to have
several
HDMI receivers in a system, I believe? Wouldn't it be better to pass
these
addresses from the platform data / DT?
Yes, that doesn't look quite right, but I couldn't find a better solution
ATM.
The problem is that this subdevice is going to be used by a soc_camera
driver,
and the soc_camera interface uses its own platform data for all I2C
subdevices.
Thus, if I pass the I2C addresses in client-dev.platform_data here (as in
adv7604), it's doing to be overwritten by the soc_camera_i2c_init()
function
with a soc_camera_subdev_desc data.
Not sure what the correct solution should be. Any suggestions are greatly
appreciated.
You don't think, that soc-camera makes it impossible to pass
device-specific platform data to subdevices, right? For an example have a
look e.g. at mt9v022 and arch/arm/mach-pxa/pcm990-baseboard.c or at
mt9t111 and arch/arm/mach-shmobile/board-armadillo800eva.c.
Yes, but in this case adv761x.c has to be a soc_camera i2c subdevice driver.
Which means it will get its platform data from ssdd-drv_priv like mt9v022 AOT
client-dev.platform_data, like adv7604 does.
What if a non-soc_camera needs to use the adv7612 decoder?
IMHO, Looks like there's a conflict in the soc/non-soc camera driver subdevice
usage.
I don't think, that just using soc-camera platform data struct will make
it impossible for non-soc-camera bridge / video input drivers to use this
subdevice driver.
This is the only problem I can see at the moment.
Do you see any other issues?
As I've said earlier the driver is based much on the adv7604 which is
used for non-soc cameras.
I guess, implementing dv_timings and ISR for adv7612 will make it look
even closer.
Other subdevice drivers (like 7180) seem to work with both soc/non-soc
cameras.
Are you proposing to make it soc-cam-specific, move it to
i2c/soc_camera/ and deal with a non-soc variant later if needed?
In general several attempts have been made earlier to
finally make soc-camera originated subdevice drivers
soc-camera-independent. This hasn't been finalised due to a lack of a real
life use-case. As soon as one appears, finalising that work shouldn't be
too difficult.
For example, there's an adv7180 decoder on the Lager board, and its driver can
be successfully used with a soc_camera (rcar_vin) as well as
a PCI STA2X11 Video Input device. However, if the adv7180 needed a platform
data, there would be a conflict, since soc_camera uses
a different method of passing platform data to the subdevice driver.
I don't think that making adv7612 subdevice SOC-specific would be the way to
go here since it may lead us to code duplication for non-soc video devices
later.
+
+struct adv761x_color_format {
+ enum v4l2_mbus_pixelcode code;
+ enum v4l2_colorspace colorspace;
+};
+
+/* Supported color format list */
+static const struct adv761x_color_format adv761x_cfmts[] = {
+ {
+ .code = V4L2_MBUS_FMT_RGB888_1X24,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ },
+};
+
+/* ADV761X descriptor structure */
+struct adv761x_state {
+ struct v4l2_subdev sd;
+ struct media_padpad;
+ struct v4l2_ctrl_handlerctrl_hdl;
+
+ u8 edid[256];
+ unsignededid_blocks;
+ const struct adv761x_color_format *cfmt;
+ u32 width;
+ u32 height;
+ enum v4l2_field scanmode;
+
+ struct workqueue_struct *work_queue;
+ struct delayed_work enable_hotplug;
+
+ /* I2C clients */
+ struct i2c_client *i2c_cec;
+ struct i2c_client *i2c_infoframe;
+ struct i2c_client *i2c_dpll;
+ struct i2c_client *i2c_repeater;
+ struct i2c_client *i2c_edid;
+ struct i2c_client *i2c_hdmi;
+ struct i2c_client *i2c_cp;
+};
+
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct adv761x_state,
ctrl_hdl)-sd;
+}
+
+static inline struct adv761x_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct adv761x_state, sd);
+}
+
+/* I2C I/O operations */
+static s32 adv_smbus_read_byte_data(struct i2c_client *client, u8
command)
+{
+ s32 ret, i;
+
+ for (i = 0; i 3; i++) {
+ ret = i2c_smbus_read_byte_data(client, command);
Uhm, why do
Re: [PATCH 1/3] media: i2c: Add ADV761X support
On 09/25/2013 10:33 PM, Guennadi Liakhovetski wrote: Hi Valentine, On Wed, 25 Sep 2013, Valentine wrote: On 09/25/2013 08:31 PM, Guennadi Liakhovetski wrote: On Wed, 25 Sep 2013, Valentine wrote: On 09/25/2013 06:08 PM, Guennadi Liakhovetski wrote: [snip] Using module parameters has a disadvantage, that all instances of this driver will get the same values, and it is quite possible to have several HDMI receivers in a system, I believe? Wouldn't it be better to pass these addresses from the platform data / DT? Yes, that doesn't look quite right, but I couldn't find a better solution ATM. The problem is that this subdevice is going to be used by a soc_camera driver, and the soc_camera interface uses its own platform data for all I2C subdevices. Thus, if I pass the I2C addresses in client-dev.platform_data here (as in adv7604), it's doing to be overwritten by the soc_camera_i2c_init() function with a soc_camera_subdev_desc data. Not sure what the correct solution should be. Any suggestions are greatly appreciated. You don't think, that soc-camera makes it impossible to pass device-specific platform data to subdevices, right? For an example have a look e.g. at mt9v022 and arch/arm/mach-pxa/pcm990-baseboard.c or at mt9t111 and arch/arm/mach-shmobile/board-armadillo800eva.c. Yes, but in this case adv761x.c has to be a soc_camera i2c subdevice driver. Which means it will get its platform data from ssdd-drv_priv like mt9v022 AOT client-dev.platform_data, like adv7604 does. What if a non-soc_camera needs to use the adv7612 decoder? IMHO, Looks like there's a conflict in the soc/non-soc camera driver subdevice usage. I don't think, that just using soc-camera platform data struct will make it impossible for non-soc-camera bridge / video input drivers to use this subdevice driver. This is the only problem I can see at the moment. Do you see any other issues? As I've said earlier the driver is based much on the adv7604 which is used for non-soc cameras. I guess, implementing dv_timings and ISR for adv7612 will make it look even closer. Other subdevice drivers (like 7180) seem to work with both soc/non-soc cameras. Are you proposing to make it soc-cam-specific, move it to i2c/soc_camera/ and deal with a non-soc variant later if needed? I wouldn't call it soc-camera specific. It would just include an soc-camera header and use one soc-camera struct. It wouldn't even require loading the soc-camera core module, let alone using soc-camera driver binding schemes. So, it would be a very mild dependency. As for where you put it - I don't care that much either. OK, thanks. In fact, looking a bit more at the driver, I've got a couple more questions. 1. Hotplug handling: you've got comments like Pull down the hotplug pin, but I don't see any code that would actually pull the pin? Am I missing it or is it permanently low? It is supposed to be done by the camera driver that receives the hotplug notification. Hm, seems strange to me - that pin belongs to the HDMI interface AFAICS and the camera host / bridge driver knows nothing about HDMI... E.g. adv7842_delayed_work_enable_hotplug(), IIUC, does enable the hotplug detection pin itself. The adv7604 handling looks suspicious to me... BTW, the free ADV7612 datasheet with no register information and just a general description does mention hotplug control pins, so, I really think it should be a task of the HDMI decoder driver to control those. IIUC, these pins are supposed to be controlled by the camera or SOC-GPIO. 2. You're using an own work queue just to queue a work to notify users about the event. Wouldn't it suffice to just use the scheduler work queue? It probably would. I just didn't want to deviate much from the code that is already there (adv7604/adv7842/ad9389b/adv7511/cx25840). diff --git a/include/media/adv761x.h b/include/media/adv761x.h new file mode 100644 index 000..e6e6aea --- /dev/null +++ b/include/media/adv761x.h @@ -0,0 +1,28 @@ +/* + * adv761x Analog Devices ADV761X HDMI receiver driver + * + * Copyright (C) 2013 Cogent Embedded, Inc. + * Copyright (C) 2013 Renesas Electronics Corporation + * + * This program is free software; you may redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + * + */ + +#ifndef _ADV761X_H_ +#define _ADV761X_H_ + +/* notify events */ +#define ADV761X_HOTPLUG1
[PATCH 0/3] media: Add SH-Mobile RCAR-H2 Lager board support
The following patches add ADV7611/ADV7612 HDMI receiver I2C driver and add RCAR H2 SOC support along with ADV761x output format support to rcar_vin soc_camera driver. These changes are needed for SH-Mobile R8A7790 Lager board video input support. Valentine Barshak (3): media: i2c: Add ADV761X support media: rcar_vin: Add preliminary r8a7790 H2 support media: rcar_vin: Add RGB888_1X24 input format support drivers/media/i2c/Kconfig| 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/adv761x.c | 1060 ++ drivers/media/platform/soc_camera/rcar_vin.c | 17 +- include/media/adv761x.h | 28 + 5 files changed, 1114 insertions(+), 3 deletions(-) create mode 100644 drivers/media/i2c/adv761x.c create mode 100644 include/media/adv761x.h -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] media: i2c: Add ADV761X support
This adds ADV7611/ADV7612 Dual Port Xpressview
225 MHz HDMI Receiver support.
The code is based on the ADV7604 driver, and ADV7612 patch
by Shinobu Uehara shinobu.uehara...@renesas.com
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
---
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/adv761x.c | 1060 +++
include/media/adv761x.h | 28 ++
4 files changed, 1100 insertions(+)
create mode 100644 drivers/media/i2c/adv761x.c
create mode 100644 include/media/adv761x.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index d18be19..8eede00 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -206,6 +206,17 @@ config VIDEO_ADV7604
To compile this driver as a module, choose M here: the
module will be called adv7604.
+config VIDEO_ADV761X
+ tristate Analog Devices ADV761X decoder
+ depends on VIDEO_V4L2 I2C
+ ---help---
+ Support for the Analog Devices ADV7611/ADV7612 video decoder.
+
+ This is an Analog Devices Dual Port Xpressview HDMI Receiver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv761x.
+
config VIDEO_ADV7842
tristate Analog Devices ADV7842 decoder
depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 9f462df..393eb0c 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
+obj-$(CONFIG_VIDEO_ADV761X) += adv761x.o
obj-$(CONFIG_VIDEO_ADV7842) += adv7842.o
obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o
diff --git a/drivers/media/i2c/adv761x.c b/drivers/media/i2c/adv761x.c
new file mode 100644
index 000..bc3dfc3
--- /dev/null
+++ b/drivers/media/i2c/adv761x.c
@@ -0,0 +1,1060 @@
+/*
+ * adv761x Analog Devices ADV761X HDMI receiver driver
+ *
+ * Copyright (C) 2013 Cogent Embedded, Inc.
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/errno.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/videodev2.h
+#include media/adv761x.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+
+#define ADV761X_DRIVER_NAME adv761x
+
+/* VERT_FILTER_LOCKED and DE_REGEN_FILTER_LOCKED flags */
+#define ADV761X_HDMI_F_LOCKED(v) (((v) 0xa0) == 0xa0)
+
+/* Maximum supported resolution */
+#define ADV761X_MAX_WIDTH 1920
+#define ADV761X_MAX_HEIGHT 1080
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-2));
+
+/* I2C map addresses */
+static u8 i2c_cec = 0x40;
+module_param(i2c_cec, byte, 0644);
+MODULE_PARM_DESC(i2c_cec, CEC map 7-bit I2C address (default: 0x40));
+
+static u8 i2c_inf = 0x3e;
+module_param(i2c_inf, byte, 0644);
+MODULE_PARM_DESC(i2c_inf, InfoFrame map 7-bit I2C address (default: 0x3e));
+
+static u8 i2c_dpll = 0x26;
+module_param(i2c_dpll, byte, 0644);
+MODULE_PARM_DESC(i2c_dpll, DPLL map 7-bit I2C address (default: 0x20));
+
+static u8 i2c_rep = 0x32;
+module_param(i2c_rep, byte, 0644);
+MODULE_PARM_DESC(i2c_rep, Repeater map 7-bit I2C address (default: 0x32));
+
+static u8 i2c_edid = 0x36;
+module_param(i2c_edid, byte, 0644);
+MODULE_PARM_DESC(i2c_edid, EDID map 7-bit I2C address (default: 0x36));
+
+static u8 i2c_hdmi = 0x34;
+module_param(i2c_hdmi, byte, 0644);
+MODULE_PARM_DESC(i2c_hdmi, HDMI map 7-bit I2C address (default: 0x34));
+
+static u8 i2c_cp = 0x22;
+module_param(i2c_cp, byte, 0644);
+MODULE_PARM_DESC(i2c_cp, CP map 7-bit I2C address (default: 0x22));
+
+struct adv761x_color_format {
+ enum v4l2_mbus_pixelcode code;
+ enum v4l2_colorspace colorspace;
+};
+
+/* Supported color format list */
+static const struct adv761x_color_format adv761x_cfmts[] = {
+ {
+ .code = V4L2_MBUS_FMT_RGB888_1X24,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ },
+};
+
+/* ADV761X
[PATCH 2/3] media: rcar_vin: Add preliminary r8a7790 H2 support
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
---
drivers/media/platform/soc_camera/rcar_vin.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index d02a7e0..cf81e02 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -105,6 +105,7 @@
#define VIN_MAX_HEIGHT 2048
enum chip_id {
+ RCAR_H2,
RCAR_H1,
RCAR_M1,
RCAR_E1,
@@ -300,7 +301,8 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
dmr = 0;
break;
case V4L2_PIX_FMT_RGB32:
- if (priv-chip == RCAR_H1 || priv-chip == RCAR_E1) {
+ if (priv-chip == RCAR_H2 || priv-chip == RCAR_H1 ||
+ priv-chip == RCAR_E1) {
dmr = VNDMR_EXRGB;
break;
}
@@ -1381,6 +1383,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
};
static struct platform_device_id rcar_vin_id_table[] = {
+ { r8a7790-vin, RCAR_H2 },
{ r8a7779-vin, RCAR_H1 },
{ r8a7778-vin, RCAR_M1 },
{ uPD35004-vin, RCAR_E1 },
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] media: rcar_vin: Add RGB888_1X24 input format support
This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
which is used by the ADV7612 chip.
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
---
drivers/media/platform/soc_camera/rcar_vin.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index cf81e02..0f04cff 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -68,6 +68,7 @@
#define VNMC_INF_YUV8_BT656(0 16)
#define VNMC_INF_YUV8_BT601(1 16)
#define VNMC_INF_YUV16 (5 16)
+#define VNMC_INF_RGB888(6 16)
#define VNMC_VUP (1 10)
#define VNMC_IM_ODD(0 3)
#define VNMC_IM_ODD_EVEN (1 3)
@@ -235,7 +236,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
struct soc_camera_device *icd = priv-ici.icd;
struct rcar_vin_cam *cam = icd-host_priv;
u32 vnmc, dmr, interrupts;
- bool progressive = false, output_is_yuv = false;
+ bool progressive = false, output_is_yuv = false, input_is_yuv = false;
switch (priv-field) {
case V4L2_FIELD_TOP:
@@ -269,11 +270,17 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
case V4L2_MBUS_FMT_YUYV8_1X16:
/* BT.601/BT.1358 16bit YCbCr422 */
vnmc |= VNMC_INF_YUV16;
+ input_is_yuv = true;
break;
case V4L2_MBUS_FMT_YUYV8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
vnmc |= priv-pdata-flags RCAR_VIN_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
+ input_is_yuv = true;
+ break;
+ case V4L2_MBUS_FMT_RGB888_1X24:
+ vnmc |= VNMC_INF_RGB888;
+ break;
default:
break;
}
@@ -316,7 +323,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
vnmc |= VNMC_VUP;
/* If input and output use the same colorspace, use bypass mode */
- if (output_is_yuv)
+ if (input_is_yuv == output_is_yuv)
vnmc |= VNMC_BPS;
/* progressive or interlaced mode */
@@ -1002,6 +1009,7 @@ static int rcar_vin_get_formats(struct soc_camera_device
*icd, unsigned int idx,
switch (code) {
case V4L2_MBUS_FMT_YUYV8_1X16:
case V4L2_MBUS_FMT_YUYV8_2X8:
+ case V4L2_MBUS_FMT_RGB888_1X24:
if (cam-extra_fmt)
break;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
