Re: Current status report of mt9p031.
Hi Javier, On Friday 13 May 2011 08:45:28 javier Martin wrote: On 13 May 2011 07:02, Chris Rodley carlight...@yahoo.co.nz wrote: On 11/05/11 19:15, javier Martin wrote: On 11 May 2011 06:54, Chris Rodley carlight...@yahoo.co.nz wrote: Thanks, sorry I should have spotted that. Got some shots today. So I have caught up to where you were. Had a bit of messing around to do as my board connects power via gpio switches and I was porting other drivers from 2.6.32. How are you progressing Javier? I'm just waiting for Laurent to clarify an issue about format matching between mt9p031 and omap3isp. He claimed to help me this weekend or next week. I have no mt9p031 here, so I've tried an mt9v032 (752x480 10-bit raw bayer) with the latest OMAP3 ISP driver. I had to patch yavta to support 8-bit formats, the patch has been pushed to the repository. Running the following commands captured 4 frames successfully. ./media-ctl -r -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480 (1,5)/752x480], OMAP3 ISP CCDC:0[SGRBG8 752x480], OMAP3 ISP CCDC:1[SGRBG8 752x480]' ./yavta -p -f SGRBG8 -s 752x480 -n 4 --capture=4 --skip 3 -F `./media-ctl -e OMAP3 ISP CCDC output` -- Regards, Laurent Pinchart -- 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: Current status report of mt9p031.
Hi Javier,
On Wednesday 11 May 2011 09:15:29 javier Martin wrote:
On 11 May 2011 06:54, Chris Rodley carlight...@yahoo.co.nz wrote:
I am having a problem with these commands:
root@chris:/home# ./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CC
DC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
Resetting all links to inactive
Setting up link 16:0 - 5:0 [1]
Setting up link 5:1 - 6:0 [1]
root@chris:/home# ./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240],
OMAP3 ISP CCDC:1[SGRBG8 320x240]'
Unable to parse format
Hi Chris,
you have to add SGRBG8 and SGRBG12 formats to media-ctl with the following
patch:
diff --git a/src/main.c b/src/main.c
index 461dae1..fb1bfbe 100644
--- a/src/main.c
+++ b/src/main.c
@@ -52,8 +52,10 @@ static struct {
{ Y8, V4L2_MBUS_FMT_Y8_1X8},
{ YUYV, V4L2_MBUS_FMT_YUYV8_1X16 },
{ UYVY, V4L2_MBUS_FMT_UYVY8_1X16 },
+ { SGRBG8, V4L2_MBUS_FMT_SGRBG8_1X8 },
{ SGRBG10, V4L2_MBUS_FMT_SGRBG10_1X10 },
{ SGRBG10_DPCM8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 },
+ { SGRBG12, V4L2_MBUS_FMT_SGRBG12_1X12 },
};
static const char *pixelcode_to_string(enum v4l2_mbus_pixelcode code)
Thanks for the patch. I've committed it to the media-ctl repository (with
additional Bayer formats).
--
Regards,
Laurent Pinchart
--
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: Current status report of mt9p031.
On 5 May 2011 18:55, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:
Hi Javier,
Here's the review of 0002-mt9p031.patch.
[snip]
+static int mt9p031_probe(struct i2c_client *client,
+ const struct i2c_device_id *did)
+{
+ struct mt9p031 *mt9p031;
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct mt9p031_platform_data *pdata = client-dev.platform_data;
+ struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
+ int ret;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) {
+ dev_warn(adapter-dev,
+ I2C-Adapter doesn't support I2C_FUNC_SMBUS_WORD\n);
+ return -EIO;
+ }
+
+ mt9p031 = kzalloc(sizeof(struct mt9p031), GFP_KERNEL);
+ if (!mt9p031)
+ return -ENOMEM;
+
+ v4l2_i2c_subdev_init(mt9p031-subdev, client, mt9p031_subdev_ops);
+
+// struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+// isp_set_xclk(isp, 16*1000*1000, ISP_XCLK_A);
+
+ mt9p031-rect.left = 0/*MT9P031_COLUMN_SKIP*/;
+ mt9p031-rect.top = 0/*MT9P031_ROW_SKIP*/;
+ mt9p031-rect.width = MT9P031_MAX_WIDTH;
+ mt9p031-rect.height = MT9P031_MAX_HEIGHT;
+
+ switch (pdata-data_shift) {
+ case 2:
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG8_1X8;
+ break;
+ case 1:
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG10_1X10;
+ break;
+ case 0:
+ mt9p031-format.code = V4L2_MBUS_FMT_SBGGR12_1X12;
+ }
Why ? The sensor produces 12-bit data, you shouldn't fake other data widths.
Hi Laurent,
I was fixing all the issues you have pointed out when I ran into this.
It is true that mt9p031 produces 12-bit data only. However, when
connected to omap3isp it is possible to discard 4 least significant
bits (i.e. changing V4L2_MBUS_FMT_SGRBG12_1X12 into
V4L2_MBUS_FMT_SGRBG8_1X8).
The point is, if I just force mt9p031-format.code =
V4L2_MBUS_FMT_SGRBG12_1X12; then the following test will fail:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP
CCDC:1[SGRBG8 320x240]'
Unable to set format: Invalid argument (-22) ---
v4l2_subdev_set_format() fails which is quite logical since that
format is now not defined in mt9p031.c
And this test will fail too:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP
CCDC:1[SGRBG8 320x240]'
./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F
`./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000
Device /dev/video2 opened: OMAP3 ISP CCDC output (media).
Video format set: width: 320 height: 240 buffer size: 76800
Video format: GRBG (47425247) 320x240
4 buffers requested.
length: 76800 offset: 0
Buffer 0 mapped at address 0x40133000.
length: 76800 offset: 77824
Buffer 1 mapped at address 0x401e3000.
length: 76800 offset: 155648
Buffer 2 mapped at address 0x4021e000.
length: 76800 offset: 233472
Buffer 3 mapped at address 0x40368000.
Unable to start streaming: 22. --- ioctl(VIDIOC_STREAMON) fails
What is the clean way of doing this?
Thank you.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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: Current status report of mt9p031.
Hi Javier,
On Tuesday 10 May 2011 09:31:02 javier Martin wrote:
On 5 May 2011 18:55, Laurent Pinchart laurent.pinch...@ideasonboard.com
wrote:
Hi Javier,
Here's the review of 0002-mt9p031.patch.
[snip]
+static int mt9p031_probe(struct i2c_client *client,
+ const struct i2c_device_id *did)
+{
+ struct mt9p031 *mt9p031;
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct mt9p031_platform_data *pdata = client-dev.platform_data;
+ struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
+ int ret;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) {
+ dev_warn(adapter-dev,
+ I2C-Adapter doesn't support
I2C_FUNC_SMBUS_WORD\n); + return -EIO;
+ }
+
+ mt9p031 = kzalloc(sizeof(struct mt9p031), GFP_KERNEL);
+ if (!mt9p031)
+ return -ENOMEM;
+
+ v4l2_i2c_subdev_init(mt9p031-subdev, client,
mt9p031_subdev_ops); +
+// struct isp_device *isp =
v4l2_dev_to_isp_device(subdev-v4l2_dev); +// isp_set_xclk(isp,
16*1000*1000, ISP_XCLK_A);
+
+ mt9p031-rect.left = 0/*MT9P031_COLUMN_SKIP*/;
+ mt9p031-rect.top = 0/*MT9P031_ROW_SKIP*/;
+ mt9p031-rect.width = MT9P031_MAX_WIDTH;
+ mt9p031-rect.height= MT9P031_MAX_HEIGHT;
+
+ switch (pdata-data_shift) {
+ case 2:
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG8_1X8;
+ break;
+ case 1:
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG10_1X10;
+ break;
+ case 0:
+ mt9p031-format.code = V4L2_MBUS_FMT_SBGGR12_1X12;
+ }
Why ? The sensor produces 12-bit data, you shouldn't fake other data
widths.
Hi Laurent,
I was fixing all the issues you have pointed out when I ran into this.
It is true that mt9p031 produces 12-bit data only. However, when
connected to omap3isp it is possible to discard 4 least significant
bits (i.e. changing V4L2_MBUS_FMT_SGRBG12_1X12 into
V4L2_MBUS_FMT_SGRBG8_1X8).
The point is, if I just force mt9p031-format.code =
V4L2_MBUS_FMT_SGRBG12_1X12; then the following test will fail:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP
CCDC:1[SGRBG8 320x240]'
Unable to set format: Invalid argument (-22) ---
v4l2_subdev_set_format() fails which is quite logical since that
format is now not defined in mt9p031.c
And this test will fail too:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP
CCDC:1[SGRBG8 320x240]'
./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F
`./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000
Device /dev/video2 opened: OMAP3 ISP CCDC output (media).
Video format set: width: 320 height: 240 buffer size: 76800
Video format: GRBG (47425247) 320x240
4 buffers requested.
length: 76800 offset: 0
Buffer 0 mapped at address 0x40133000.
length: 76800 offset: 77824
Buffer 1 mapped at address 0x401e3000.
length: 76800 offset: 155648
Buffer 2 mapped at address 0x4021e000.
length: 76800 offset: 233472
Buffer 3 mapped at address 0x40368000.
Unable to start streaming: 22. --- ioctl(VIDIOC_STREAMON) fails
What is the clean way of doing this?
Please try replacing the media-ctl -f line with
./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], \
OMAP3 ISP CCDC:0[SGRBG8 320x240], \
OMAP3 ISP CCDC:1[SGRBG8 320x240]'
--
Regards,
Laurent Pinchart
--
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: Current status report of mt9p031.
Please try replacing the media-ctl -f line with ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], \ OMAP3 ISP CCDC:0[SGRBG8 320x240], \ OMAP3 ISP CCDC:1[SGRBG8 320x240]' -- Regards, Laurent Pinchart Hi Laurent, that didn't work either (Unable to start streaming: 32.) -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: Current status report of mt9p031.
On Tuesday 10 May 2011 11:49:10 javier Martin wrote: Please try replacing the media-ctl -f line with ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], \ OMAP3 ISP CCDC:0[SGRBG8 320x240], \ OMAP3 ISP CCDC:1[SGRBG8 320x240]' -- Regards, Laurent Pinchart Hi Laurent, that didn't work either (Unable to start streaming: 32.) With the latest 2.6.39-rc ? Lane-shifter support has been introduced very recently. Can you post the output of media-ctl -p after configuring formats on your pipeline ? -- Regards, Laurent Pinchart -- 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: Current status report of mt9p031.
On 10 May 2011 11:53, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Tuesday 10 May 2011 11:49:10 javier Martin wrote: Please try replacing the media-ctl -f line with ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], \ OMAP3 ISP CCDC:0[SGRBG8 320x240], \ OMAP3 ISP CCDC:1[SGRBG8 320x240]' -- Regards, Laurent Pinchart Hi Laurent, that didn't work either (Unable to start streaming: 32.) With the latest 2.6.39-rc ? Lane-shifter support has been introduced very recently. Can you post the output of media-ctl -p after configuring formats on your pipeline ? -- Regards, Laurent Pinchart Sure, this is the output you requested: root@beagleboard:~# ./media-ctl -p Opening media device /dev/media0 Enumerating entities Found 16 entities Enume rating pads and links Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCP2 input':pad0 [] pad1: Output [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Output - 'OMAP3 ISP CCP2':pad0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Input [SGRBG10 4096x4096] pad1: Output [SGRBG10 4096x4096] - 'OMAP3 ISP CSI2a output':pad0 [] - 'OMAP3 ISP CCDC':pad0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Input - 'OMAP3 ISP CSI2a':pad1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG8 320x240] - 'OMAP3 ISP CCP2':pad1 [] - 'OMAP3 ISP CSI2a':pad1 [] - 'mt9p031 2-0048':pad0 [ACTIVE] pad1: Output [SGRBG8 320x240] - 'OMAP3 ISP CCDC output':pad0 [ACTIVE] - 'OMAP3 ISP resizer':pad0 [] pad2: Output [SGRBG8 320x239] - 'OMAP3 ISP preview':pad0 [] - 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Input - 'OMAP3 ISP CCDC':pad1 [ACTIVE] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad2 [] - 'OMAP3 ISP preview input':pad0 [] pad1: Output [YUYV 4082x4088] - 'OMAP3 ISP preview output':pad0 [] - 'OMAP3 ISP resizer':pad0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Output - 'OMAP3 ISP preview':pad0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Input - 'OMAP3 ISP preview':pad1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Input [YUYV 4095x4095 (4,6)/4086x4082] - 'OMAP3 ISP CCDC':pad1 [] - 'OMAP3 ISP preview':pad1 [] - 'OMAP3 ISP resizer input':pad0 [] pad1: Output [YUYV 4096x4095] - 'OMAP3 ISP resizer output':pad0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Output - 'OMAP3 ISP resizer':pad0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Input - 'OMAP3 ISP resizer':pad1 [] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev7 pad0: Input -
Re: Current status report of mt9p031.
I almost forget, I am using 2.6.39-rc commit bd99337e95b6bba976e41a5f3cf65c1f04069156 -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: Current status report of mt9p031.
Hi Javier, On Tuesday 10 May 2011 13:05:35 javier Martin wrote: I almost forget, I am using 2.6.39-rc commit bd99337e95b6bba976e41a5f3cf65c1f04069156 There's no such commit in mainline. -- Regards, Laurent Pinchart -- 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: Current status report of mt9p031.
On 10 May 2011 14:25, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, On Tuesday 10 May 2011 13:05:35 javier Martin wrote: I almost forget, I am using 2.6.39-rc commit bd99337e95b6bba976e41a5f3cf65c1f04069156 There's no such commit in mainline. -- Regards, Laurent Pinchart Sorry Laurent, the commit is 5895198c56d131cc696556a45f7ff0ea99ac297b -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: Current status report of mt9p031.
Hi Laurent,
information for data lane shifter is passed through platform data:
/**
* struct isp_parallel_platform_data - Parallel interface platform data
* @data_lane_shift: Data lane shifter
* 0 - CAMEXT[13:0] - CAM[13:0]
* 1 - CAMEXT[13:2] - CAM[11:0]
* 2 - CAMEXT[13:4] - CAM[9:0]
* 3 - CAMEXT[13:6] - CAM[7:0]
* @clk_pol: Pixel clock polarity
* 0 - Non Inverted, 1 - Inverted
* @bridge: CCDC Bridge input control
* ISPCTRL_PAR_BRIDGE_DISABLE - Disable
* ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
* ISPCTRL_PAR_BRIDGE_BENDIAN - Big endian
*/
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
};
This way I am able to convert from 12bpp to 8bpp:
data_lane_shift = 2 and bridge = ISPCTRL_PAR_BRIDGE_DISABLE
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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: Current status report of mt9p031.
Hi Javier,
On Tuesday 10 May 2011 16:14:09 javier Martin wrote:
Hi Laurent,
information for data lane shifter is passed through platform data:
/**
* struct isp_parallel_platform_data - Parallel interface platform data
* @data_lane_shift: Data lane shifter
*0 - CAMEXT[13:0] - CAM[13:0]
*1 - CAMEXT[13:2] - CAM[11:0]
*2 - CAMEXT[13:4] - CAM[9:0]
*3 - CAMEXT[13:6] - CAM[7:0]
* @clk_pol: Pixel clock polarity
*0 - Non Inverted, 1 - Inverted
* @bridge: CCDC Bridge input control
*ISPCTRL_PAR_BRIDGE_DISABLE - Disable
*ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
*ISPCTRL_PAR_BRIDGE_BENDIAN - Big endian
*/
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
};
This way I am able to convert from 12bpp to 8bpp:
data_lane_shift = 2 and bridge = ISPCTRL_PAR_BRIDGE_DISABLE
That's usually used to define a static conversion, when sensor data lines 7-0
are connected to ISP data lines 11-3. Capturing 8-bit raw bayer data from a
12-bit raw bayer sensor should be done by dynamically configuring the
pipeline.
I'm not at home and don't have access to my OMAP3 hardware now, I'll try your
use case when I'll come back (end of the week or during the weekend).
--
Regards,
Laurent Pinchart
--
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: Current status report of mt9p031.
Hi Javier,
On Wednesday 04 May 2011 09:33:49 javier Martin wrote:
Hi,
for those interested on mt9p031 working on the Beagleboard xM. I
attach 2 patches here that must be applied to kernel-2.6.39-rc commit
e8dad69408a9812d6bb42d03e74d2c314534a4fa
These patches include a fix for the USB ethernet.
What currently works:
- Test suggested by Guennadi
(http://download.open-technology.de/BeagleBoard_xM-MT9P031/).
Known problems:
1. You might be required to create device node for the sensor manually:
mknod /dev/v4l-subdev8 c 81 15
chown root:video /dev/v4l-subdev8
2. Images captured seem to be too dull and dark. Values of pixels seem
always to low, it seems to me like MSB of each pixel were stuck at 0.
I hope someone can help here.
I've inline the patches for easier review, please send the inline next time.
First 0001-mt9p031.patch. As a general rule, please try to split your patches
properly. This one contains several unrelated changes. For instance the
drivers/media/video/Makefile modification should go in the patch that adds the
mt9p031 driver code.
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-
omap2/board-omap3beagle.c
index 33007fd..eba2235 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
[snip]
@@ -273,6 +274,44 @@ static struct regulator_consumer_supply
beagle_vsim_supply = {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
That's a weird name for a supply that is connected to a 1.8V regulator output.
What about renaming the supplies cam_dig and cam_io ?
+};
[snip]
@@ -309,6 +348,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+ * Power on camera interface - only on pre-production, not
+ * needed on production boards
+ */
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
There's already similar code in 2.6.39-rc6 (but the GPIO is called
DVI_LDO_EN).
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
[snip]
@@ -472,6 +522,7 @@ static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+// omap_register_i2c_bus(2, 100, NULL, 0);
Please don't add commented out code.
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
@@ -598,6 +649,34 @@ static const struct usbhs_omap_board_data usbhs_bdata
__initconst = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+// #if 0
Same here.
Does the boot loader leave the camera interface unconfigured ?
+ /* Camera - Parallel Data */
+ OMAP3_MUX(CAM_D0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D8, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D9, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D10, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D11, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* Camera - HS/VS signals */
+ OMAP3_MUX(CAM_HS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_VS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
What about pull-ups ont the HS/VS and PCLK signals ?
+
+ /* Camera - Reset GPIO 98 */
+ OMAP3_MUX(CAM_FLD, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+
+ /* Camera - XCLK */
+ OMAP3_MUX(CAM_XCLKA, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+// #endif
+// OMAP3_MUX(I2C2_SCL, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+// OMAP3_MUX(I2C2_SDA, OMAP_MUX_MODE0 | OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_INPUT_PULLUP),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -656,6 +735,8 @@ static void __init beagle_opp_init(void)
static void __init omap3_beagle_init(void)
{
+// u32 ctrl;
+
No commented code.
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
@@
Re: Current status report of mt9p031.
Hi Javier,
Here's the review of 0002-mt9p031.patch.
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c b/arch/arm/mach
-omap2/board-omap3beagle-camera.c
new file mode 100644
index 000..92389dd
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,158 @@
[snip]
(This is clearly proof of concept code given the amount of lines that are
commented out, so I'll skip the review.)
+module_init(beagle_camera_init);
+module_exit(beagle_camera_exit);
+
+MODULE_LICENSE(GPL v2);
The OMAP3 ISP isn't supposed to be registered in a loadable module. There have
been preliminary discussions regarding how to properly achieve this, but not
decision yet. For now it should be built-in, and you should use the
omap3_init_camera() function.
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..d42d783
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,884 @@
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+/*
+ * mt9p031 i2c address 0x5d (0xBA read, 0xBB write) same as mt9t031
+ * The platform has to define i2c_board_info and link to it from
+ * struct soc_camera_link
+ */
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#define MT9P031_ROW_START0x01
+#define MT9P031_COLUMN_START 0x02
+#define MT9P031_WINDOW_HEIGHT0x03
+#define MT9P031_WINDOW_WIDTH 0x04
+#define MT9P031_HORIZONTAL_BLANKING 0x05
+#define MT9P031_VERTICAL_BLANKING0x06
+#define MT9P031_OUTPUT_CONTROL 0x07
+#define MT9P031_SHUTTER_WIDTH_UPPER 0x08
+#define MT9P031_SHUTTER_WIDTH0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL 0x0a
+#define MT9P031_FRAME_RESTART0x0b
+#define MT9P031_SHUTTER_DELAY0x0c
+#define MT9P031_RESET0x0d
+#define MT9P031_READ_MODE_1 0x1e
+#define MT9P031_READ_MODE_2 0x20
+//#define MT9T031_READ_MODE_30x21 // NA readmode_2 is 2 bytes
No commented out code please, and C code should be commented with /* ... */ in
the Linux kernel.
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE 0x23
+#define MT9P031_GLOBAL_GAIN 0x35
+//#define MT9T031_CHIP_ENABLE0xF8 // PDN is pin signal. no
i2c
register
+
+#define MT9P031_MAX_HEIGHT 1944
+#define MT9P031_MAX_WIDTH2592
+#define MT9P031_MIN_HEIGHT 2
+#define MT9P031_MIN_WIDTH18
+#define MT9P031_HORIZONTAL_BLANK 0
+#define MT9P031_VERTICAL_BLANK 25
+#define MT9P031_COLUMN_SKIP 16
+#define MT9P031_ROW_SKIP 54
+
+#define MT9P031_CHIP_VERSION_VALUE 0x1801
Could you move those constants just below the register that uses them, and
make sure they have names that start with the register name ? Have a look at
http://git.linuxtv.org/pinchartl/media.git?a=commit;h=d3fd150967a90a99fadd24ad4f5b4c1cce833493
for an example.
+/*
+#define MT9T031_BUS_PARAM(SOCAM_PCLK_SAMPLE_RISING | \
+ SOCAM_PCLK_SAMPLE_FALLING | SOCAM_HSYNC_ACTIVE_HIGH | \
+ SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_HIGH | \
+ SOCAM_MASTER | SOCAM_DATAWIDTH_10)
+*/
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+struct media_pad pad;
s//\t/. Please run scripts/checkpatch.pl on your patches and fix the
reported warnings and errors.
+
+ struct v4l2_rect rect; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ int model; /* V4L2_IDENT_MT9P031* codes from v4l2-chip-ident.h */
+ u16 xskip;
+ u16 yskip;
+ struct regulator *reg_1v8, *reg_2v8;
+};
[snip]
+static int reg_set(struct i2c_client *client, const u8 reg,
+const u16 data)
+{
+ int ret;
+
+ ret = reg_read(client, reg);
+ if (ret 0)
+ return ret;
+ return reg_write(client, reg, ret | data);
To avoid an unnecessary I2C transaction, I would cache the register value in
the driver instead of reading it back from the device.
+}
[snip]
+static int set_shutter(struct i2c_client *client, const u32 data)
This function isn't used.
+{
+ int ret;
+
+ ret = reg_write(client, MT9P031_SHUTTER_WIDTH_UPPER, data 16);
+
+ if (ret = 0)
+ ret = reg_write(client, MT9P031_SHUTTER_WIDTH, data 0x);
+
+ return ret;
+}
+
+static int get_shutter(struct i2c_client *client, u32 *data)
And this one isn't used either.
+{
+ int ret;
+
+ ret = reg_read(client,
Current status report of mt9p031.
Hi,
for those interested on mt9p031 working on the Beagleboard xM. I
attach 2 patches here that must be applied to kernel-2.6.39-rc commit
e8dad69408a9812d6bb42d03e74d2c314534a4fa
These patches include a fix for the USB ethernet.
What currently works:
- Test suggested by Guennadi
(http://download.open-technology.de/BeagleBoard_xM-MT9P031/).
Known problems:
1. You might be required to create device node for the sensor manually:
mknod /dev/v4l-subdev8 c 81 15
chown root:video /dev/v4l-subdev8
2. Images captured seem to be too dull and dark. Values of pixels seem
always to low, it seems to me like MSB of each pixel were stuck at 0.
I hope someone can help here.
Thank you.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a45cd64..c437391 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -178,7 +178,7 @@ obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o
-obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \
+obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..eba2235 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -52,6 +52,7 @@
#include hsmmc.h
#include timer-gp.h
#include pm.h
+#include control.h
#define NAND_BLOCK_SIZE SZ_128K
@@ -273,6 +274,44 @@ static struct regulator_consumer_supply beagle_vsim_supply = {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct regulator_init_data beagle_vaux3 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux3_supply,
+};
+
+/* VAUX4 for CAM_2V8 */
+static struct regulator_init_data beagle_vaux4 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux4_supply,
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -309,6 +348,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+ * Power on camera interface - only on pre-production, not
+ * needed on production boards
+ */
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +499,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -472,6 +522,7 @@ static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+// omap_register_i2c_bus(2, 100, NULL, 0);
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom, ARRAY_SIZE(beagle_i2c_eeprom));
@@ -598,6 +649,34 @@ static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+// #if 0
+ /* Camera - Parallel Data */
+ OMAP3_MUX(CAM_D0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D8, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D9, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D10,
Re: Current status report of mt9p031.
Hello Javier, 2011/5/4 javier Martin javier.mar...@vista-silicon.com: Hi, for those interested on mt9p031 working on the Beagleboard xM. I attach 2 patches here that must be applied to kernel-2.6.39-rc commit e8dad69408a9812d6bb42d03e74d2c314534a4fa These patches include a fix for the USB ethernet. What currently works: - Test suggested by Guennadi (http://download.open-technology.de/BeagleBoard_xM-MT9P031/). Known problems: 1. You might be required to create device node for the sensor manually: mknod /dev/v4l-subdev8 c 81 15 chown root:video /dev/v4l-subdev8 2. Images captured seem to be too dull and dark. Values of pixels seem always to low, it seems to me like MSB of each pixel were stuck at 0. I hope someone can help here. I once had a similar problem and found out that I had configured the shifter in the device-setup wrong. So 2 bits were shifted out and I had a dark image. best regards, Bastian Hecht Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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
