Re: [PATCH] uvcvideo: add quirk to force Phytec CAM 004H to GBRG
On Thu, 2018-08-16 at 19:39 +0300, Laurent Pinchart wrote:
> Hi Christoph,
>
> (Philipp, there's a question for you at the end)
>
> On Thursday, 16 August 2018 15:48:15 EEST Christoph Fritz wrote:
> > > On Wednesday, 21 February 2018 23:24:36 EEST Laurent Pinchart wrote:
> > >> On Wednesday, 21 February 2018 22:42:45 EET Christoph Fritz wrote:
> > >>>>> drivers/media/usb/uvc/uvc_driver.c | 16
> > >>>>> drivers/media/usb/uvc/uvcvideo.h | 1 +
> > >>>>> 2 files changed, 17 insertions(+)
> > >>>>>
> > >>>>> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > >>>>> b/drivers/media/usb/uvc/uvc_driver.c index cde43b6..8bfa40b 100644
> > >>>>> --- a/drivers/media/usb/uvc/uvc_driver.c
> > >>>>> +++ b/drivers/media/usb/uvc/uvc_driver.c
> > >>>>> @@ -406,6 +406,13 @@ static int uvc_parse_format(struct uvc_device
> > >>>>> *dev,
> > >>>>> width_multiplier = 2;
> > >>>>> }
> > >>>>> }
> > >>>>> + if (dev->quirks & UVC_QUIRK_FORCE_GBRG) {
> > >>>>> + if (format->fcc == V4L2_PIX_FMT_SGRBG8) {
> > >>>>> + strlcpy(format->name, "GBRG Bayer
> > >>>>> (GBRG)",
> > >>>>> + sizeof(format->name));
> > >>>>> + format->fcc = V4L2_PIX_FMT_SGBRG8;
> > >>>>> + }
> > >>>>> + }
> > >>>>>
> > >>>>> if (buffer[2] == UVC_VS_FORMAT_UNCOMPRESSED) {
> > >>>>> ftype = UVC_VS_FRAME_UNCOMPRESSED;
> > >>>>> @@ -2631,6 +2638,15 @@ static struct usb_device_id uvc_ids[] = {
> > >>>>> .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
> > >>>>> .bInterfaceSubClass = 1,
> > >>>>> .bInterfaceProtocol = 0 },
> > >>>>> + /* PHYTEC CAM 004H cameras */
> > >>>>> + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> > >>>>> + | USB_DEVICE_ID_MATCH_INT_INFO,
> > >>>>> + .idVendor = 0x199e,
> > >>>>> + .idProduct= 0x8302,
> > >>>>> + .bInterfaceClass = USB_CLASS_VIDEO,
> > >>>>> + .bInterfaceSubClass = 1,
> > >>>>> + .bInterfaceProtocol = 0,
> > >>>>> + .driver_info = UVC_QUIRK_FORCE_GBRG },
> > >>>>> /* Bodelin ProScopeHR */
> > >>>>> { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> > >>>>> | USB_DEVICE_ID_MATCH_DEV_HI
> > >>>>> diff --git a/drivers/media/usb/uvc/uvcvideo.h
> > >>>>> b/drivers/media/usb/uvc/uvcvideo.h index 7e4d3ee..ad51002 100644
> > >>>>> --- a/drivers/media/usb/uvc/uvcvideo.h
> > >>>>> +++ b/drivers/media/usb/uvc/uvcvideo.h
> > >>>>> @@ -164,6 +164,7 @@
> > >>>>> #define UVC_QUIRK_RESTRICT_FRAME_RATE0x0200
> > >>>>> #define UVC_QUIRK_RESTORE_CTRLS_ON_INIT 0x0400
> > >>>>> #define UVC_QUIRK_FORCE_Y8 0x0800
> > >>>>> +#define UVC_QUIRK_FORCE_GBRG 0x1000
> > >>>>
> > >>>> I don't think we should add a quirk flag for every format that needs
> > >>>> to be forced. Instead, now that we have a new way to store per-device
> > >>>> parameters since commit 3bc85817d798 ("media: uvcvideo: Add
> > >>>> extensible device information"), how about making use of it and adding
> > >>>> a field to the uvc_device_info structure to store the forced format ?
> >
> > you mean something like:
> >
> > struct uvc_device_info {
> > u32 quirks;
> > + u32 forced_color_format;
> > u32 meta_format;
> > };
> >
> > and
> >
> > +static const struct uvc_device_info uvc_forced_color_sgbrg8 = {
> > + .forced_color_format = V4L2_PIX_FMT_SGBRG8
Re: [PATCH] uvcvideo: add quirk to force Phytec CAM 004H to GBRG
Hi Laurent
> On Wednesday, 21 February 2018 23:24:36 EEST Laurent Pinchart wrote:
> > On Wednesday, 21 February 2018 22:42:45 EET Christoph Fritz wrote:
> > >>> drivers/media/usb/uvc/uvc_driver.c | 16
> > >>> drivers/media/usb/uvc/uvcvideo.h | 1 +
> > >>> 2 files changed, 17 insertions(+)
> > >>>
> > >>> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > >>> b/drivers/media/usb/uvc/uvc_driver.c index cde43b6..8bfa40b 100644
> > >>> --- a/drivers/media/usb/uvc/uvc_driver.c
> > >>> +++ b/drivers/media/usb/uvc/uvc_driver.c
> > >>> @@ -406,6 +406,13 @@ static int uvc_parse_format(struct uvc_device
> > >>> *dev,
> > >>> width_multiplier = 2;
> > >>> }
> > >>> }
> > >>> + if (dev->quirks & UVC_QUIRK_FORCE_GBRG) {
> > >>> + if (format->fcc == V4L2_PIX_FMT_SGRBG8) {
> > >>> + strlcpy(format->name, "GBRG Bayer
> > >>> (GBRG)",
> > >>> + sizeof(format->name));
> > >>> + format->fcc = V4L2_PIX_FMT_SGBRG8;
> > >>> + }
> > >>> + }
> > >>>
> > >>> if (buffer[2] == UVC_VS_FORMAT_UNCOMPRESSED) {
> > >>> ftype = UVC_VS_FRAME_UNCOMPRESSED;
> > >>> @@ -2631,6 +2638,15 @@ static struct usb_device_id uvc_ids[] = {
> > >>> .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
> > >>> .bInterfaceSubClass = 1,
> > >>> .bInterfaceProtocol = 0 },
> > >>> + /* PHYTEC CAM 004H cameras */
> > >>> + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> > >>> + | USB_DEVICE_ID_MATCH_INT_INFO,
> > >>> + .idVendor = 0x199e,
> > >>> + .idProduct= 0x8302,
> > >>> + .bInterfaceClass = USB_CLASS_VIDEO,
> > >>> + .bInterfaceSubClass = 1,
> > >>> + .bInterfaceProtocol = 0,
> > >>> + .driver_info = UVC_QUIRK_FORCE_GBRG },
> > >>> /* Bodelin ProScopeHR */
> > >>> { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> > >>> | USB_DEVICE_ID_MATCH_DEV_HI
> > >>> diff --git a/drivers/media/usb/uvc/uvcvideo.h
> > >>> b/drivers/media/usb/uvc/uvcvideo.h index 7e4d3ee..ad51002 100644
> > >>> --- a/drivers/media/usb/uvc/uvcvideo.h
> > >>> +++ b/drivers/media/usb/uvc/uvcvideo.h
> > >>> @@ -164,6 +164,7 @@
> > >>> #define UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200
> > >>> #define UVC_QUIRK_RESTORE_CTRLS_ON_INIT0x0400
> > >>> #define UVC_QUIRK_FORCE_Y8 0x0800
> > >>> +#define UVC_QUIRK_FORCE_GBRG 0x1000
> > >>
> > >> I don't think we should add a quirk flag for every format that needs to
> > >> be forced. Instead, now that we have a new way to store per-device
> > >> parameters since commit 3bc85817d798 ("media: uvcvideo: Add extensible
> > >> device information"), how about making use of it and adding a field to
> > >> the uvc_device_info structure to store the forced format ?
you mean something like:
struct uvc_device_info {
u32 quirks;
+ u32 forced_color_format;
u32 meta_format;
};
and
+static const struct uvc_device_info uvc_forced_color_sgbrg8 = {
+ .forced_color_format = V4L2_PIX_FMT_SGBRG8,
+};
and
@@ -2817,7 +2820,7 @@ static const struct usb_device_id uvc_ids[] = {
.bInterfaceClass = USB_CLASS_VENDOR_SPEC,
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
- .driver_info = (kernel_ulong_t)_quirk_force_y8 },
+ .driver_info = (kernel_ulong_t)_forced_color_y8 },
?
If yes:
- there would be a need for forced_color_format in struct uvc_device
- module-parameter quirk would not test force color format any more
- the actual force/quirk changes not only format->fcc:
if (dev->forced_color_format == V4L2_PIX_FMT_SGBRG8) {
strlcpy(format->name, "Greyscale 8-bit (Y8 )",
sizeof(format->name));
format->fcc = dev->forced_color_format;
format->bpp = 8;
width_multiplier = 2;
}
Is this the way you want me to go?
Thanks
-- Christoph
Re: [PATCH] uvcvideo: add quirk to force Phytec CAM 004H to GBRG
Hi Laurent
> Could you please send me the output of 'lsusb -d 199e:8302 -v' (if possible
> running as root) ?
please see bottom of this mail
> > Signed-off-by: Christoph Fritz <chf.fr...@googlemail.com>
> > Tested-by: Norbert Wesp <n.w...@phytec.de>
> > ---
> > drivers/media/usb/uvc/uvc_driver.c | 16
> > drivers/media/usb/uvc/uvcvideo.h | 1 +
> > 2 files changed, 17 insertions(+)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > b/drivers/media/usb/uvc/uvc_driver.c index cde43b6..8bfa40b 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -406,6 +406,13 @@ static int uvc_parse_format(struct uvc_device *dev,
> > width_multiplier = 2;
> > }
> > }
> > + if (dev->quirks & UVC_QUIRK_FORCE_GBRG) {
> > + if (format->fcc == V4L2_PIX_FMT_SGRBG8) {
> > + strlcpy(format->name, "GBRG Bayer (GBRG)",
> > + sizeof(format->name));
> > + format->fcc = V4L2_PIX_FMT_SGBRG8;
> > + }
> > + }
> >
> > if (buffer[2] == UVC_VS_FORMAT_UNCOMPRESSED) {
> > ftype = UVC_VS_FRAME_UNCOMPRESSED;
> > @@ -2631,6 +2638,15 @@ static struct usb_device_id uvc_ids[] = {
> > .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
> > .bInterfaceSubClass = 1,
> > .bInterfaceProtocol = 0 },
> > + /* PHYTEC CAM 004H cameras */
> > + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> > + | USB_DEVICE_ID_MATCH_INT_INFO,
> > + .idVendor = 0x199e,
> > + .idProduct= 0x8302,
> > + .bInterfaceClass = USB_CLASS_VIDEO,
> > + .bInterfaceSubClass = 1,
> > + .bInterfaceProtocol = 0,
> > + .driver_info = UVC_QUIRK_FORCE_GBRG },
> > /* Bodelin ProScopeHR */
> > { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> >
> > | USB_DEVICE_ID_MATCH_DEV_HI
> >
> > diff --git a/drivers/media/usb/uvc/uvcvideo.h
> > b/drivers/media/usb/uvc/uvcvideo.h index 7e4d3ee..ad51002 100644
> > --- a/drivers/media/usb/uvc/uvcvideo.h
> > +++ b/drivers/media/usb/uvc/uvcvideo.h
> > @@ -164,6 +164,7 @@
> > #define UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200
> > #define UVC_QUIRK_RESTORE_CTRLS_ON_INIT0x0400
> > #define UVC_QUIRK_FORCE_Y8 0x0800
> > +#define UVC_QUIRK_FORCE_GBRG 0x1000
>
> I don't think we should add a quirk flag for every format that needs to be
> forced. Instead, now that we have a new way to store per-device parameters
> since commit 3bc85817d798 ("media: uvcvideo: Add extensible device
> information"), how about making use of it and adding a field to the
> uvc_device_info structure to store the forced format ?
I'm currently stuck on kernel 4.9, but for mainline I'll use extensible
device information and send a v2 in the next weeks.
output of 'lsusb -d 199e:8302 -v':
Bus 001 Device 010: ID 199e:8302 The Imaging Source Europe GmbH
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x199e The Imaging Source Europe GmbH
idProduct 0x8302
bcdDevice8.13
iManufacturer 2 ?
iProduct1 ?
iSerial 3 ?
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 349
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 0
VideoControl
[PATCH] uvcvideo: add quirk to force Phytec CAM 004H to GBRG
This patch adds a quirk to force Phytec CAM 004H to format GBRG because
it is announcing its format wrong.
Signed-off-by: Christoph Fritz <chf.fr...@googlemail.com>
Tested-by: Norbert Wesp <n.w...@phytec.de>
---
drivers/media/usb/uvc/uvc_driver.c | 16
drivers/media/usb/uvc/uvcvideo.h | 1 +
2 files changed, 17 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index cde43b6..8bfa40b 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -406,6 +406,13 @@ static int uvc_parse_format(struct uvc_device *dev,
width_multiplier = 2;
}
}
+ if (dev->quirks & UVC_QUIRK_FORCE_GBRG) {
+ if (format->fcc == V4L2_PIX_FMT_SGRBG8) {
+ strlcpy(format->name, "GBRG Bayer (GBRG)",
+ sizeof(format->name));
+ format->fcc = V4L2_PIX_FMT_SGBRG8;
+ }
+ }
if (buffer[2] == UVC_VS_FORMAT_UNCOMPRESSED) {
ftype = UVC_VS_FRAME_UNCOMPRESSED;
@@ -2631,6 +2638,15 @@ static struct usb_device_id uvc_ids[] = {
.bInterfaceClass = USB_CLASS_VENDOR_SPEC,
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0 },
+ /* PHYTEC CAM 004H cameras */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x199e,
+ .idProduct= 0x8302,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_FORCE_GBRG },
/* Bodelin ProScopeHR */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_DEV_HI
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 7e4d3ee..ad51002 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -164,6 +164,7 @@
#define UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200
#define UVC_QUIRK_RESTORE_CTRLS_ON_INIT0x0400
#define UVC_QUIRK_FORCE_Y8 0x0800
+#define UVC_QUIRK_FORCE_GBRG 0x1000
/* Format flags */
#define UVC_FMT_FLAG_COMPRESSED0x0001
--
2.1.4
rockchip v4l support ?
Hi, is someone working on v4l (camera stack) support for rockchip SoCs? Currently, it lacks pretty much everything. So what is your guess in the amount of work at a rough estimate? Thanks -- chf -- 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: rockchip v4l support ?
Hi Alpha Lin, please see my question below. On Mon, 2015-07-13 at 09:54 +0200, Hans Verkuil wrote: Hi Christoph, On 07/13/2015 09:20 AM, Christoph Fritz wrote: Hi, is someone working on v4l (camera stack) support for rockchip SoCs? I'm not aware of any activity, you're the first to ask about this on the linux-media mailinglist. However, a quick google turns up this: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/DMCeSXLwoKY Currently, it lacks pretty much everything. So what is your guess in the amount of work at a rough estimate? Hard to tell since I do not know the hardware. Basically anything from a week to a year or more :-) It depends on whether there is any code out there for driving the camera stack that you can base your work on and whether you have datasheets and how complex the HW is. Could you please answer or comment some of the questions raised in the text above? Thanks -- chf -- 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: i.MX27 camera: fix picture source width
On Tue, 2013-03-12 at 08:58 +0100, Guennadi Liakhovetski wrote: On Thu, 7 Mar 2013, javier Martin wrote: What mbus format are you using? Could you please check if the s_width value that your sensor mt9m001 returns is correct? Remember it should be in pixels, not in bytes. Thanks for looking at this. But here's my question: for a pass-through mode mx2_camera uses a 16-bpp (RGB565) format. But what if it's actually an 8-bpp format, don't you then have to adjust line-width register settings? If you don't do that, the camera interface would expect a double number of bytes per line, so, it could get confused by HSYNC coming after half-line? To emphasize this: I'm using here a mt9m001 (monochrome) camera with an 8-bpp format. Thanks -- Christoph -- 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: i.MX27 camera: fix picture source width
While using a mt9m001 (monochrome) camera the final output falsely gets
horizontally divided into two pictures.
The issue was git bisected to commit f410991dcf1f
| [media] i.MX27 camera: add support for YUV420 format
|
| This patch uses channel 2 of the eMMa-PrP to convert
| format provided by the sensor to YUV420.
|
| This format is very useful since it is used by the
| internal H.264 encoder.
It sets PICTURE_X_SIZE in register PRP_SRC_FRAME_SIZE to its full width
while before that commit it was divided by two:
- writel(((bytesperline 1) 16) | icd-user_height,
+ writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_SRC_FRAME_SIZE);
i.mx27 reference manual (41.6.12 PrP Source Frame Size Register) says:
PICTURE_X_SIZE. These bits set the frame width to be
processed in number of pixels. In YUV 4:2:0 mode, Cb and
Cr widths are taken as PICTURE_X_SIZE/2 pixels. In YUV
4:2:0 mode, this value should be a multiple of 8-pixels.
In other modes (RGB, YUV 4:2:2 and YUV 4:4:4) it should
be a multiple of 4 pixels.
This patch reverts to PICTURE_X_SIZE/2 for channel 1.
Tested on Kernel 3.4, merged to 3.8rc.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
drivers/media/platform/soc_camera/mx2_camera.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 8bda2c9..795bd3f 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -778,11 +778,11 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
struct mx2_camera_dev *pcdev = ici-priv;
struct mx2_fmt_cfg *prp = pcdev-emma_prp;
- writel((pcdev-s_width 16) | pcdev-s_height,
- pcdev-base_emma + PRP_SRC_FRAME_SIZE);
writel(prp-cfg.src_pixel,
pcdev-base_emma + PRP_SRC_PIXEL_FORMAT_CNTL);
if (prp-cfg.channel == 1) {
+ writel(((bytesperline 1) 16) | pcdev-s_height,
+ pcdev-base_emma + PRP_SRC_FRAME_SIZE);
writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_CH1_OUT_IMAGE_SIZE);
writel(bytesperline,
@@ -790,6 +790,8 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
writel(prp-cfg.ch1_pixel,
pcdev-base_emma + PRP_CH1_PIXEL_FORMAT_CNTL);
} else { /* channel 2 */
+ writel((pcdev-s_width 16) | pcdev-s_height,
+ pcdev-base_emma + PRP_SRC_FRAME_SIZE);
writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_CH2_OUT_IMAGE_SIZE);
}
--
1.7.10.4
--
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: i.MX27 camera: fix picture source width
While using a mt9m001 (monochrome) camera the final output falsely gets
horizontally divided into two pictures.
The issue was git bisected to commit f410991dcf1f
| [media] i.MX27 camera: add support for YUV420 format
|
| This patch uses channel 2 of the eMMa-PrP to convert
| format provided by the sensor to YUV420.
|
| This format is very useful since it is used by the
| internal H.264 encoder.
It sets PICTURE_X_SIZE in register PRP_SRC_FRAME_SIZE to its full width
while before that commit it was divided by two:
- writel(((bytesperline 1) 16) | icd-user_height,
+ writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_SRC_FRAME_SIZE);
i.mx27 reference manual (41.6.12 PrP Source Frame Size Register) says:
PICTURE_X_SIZE. These bits set the frame width to be
processed in number of pixels. In YUV 4:2:0 mode, Cb and
Cr widths are taken as PICTURE_X_SIZE/2 pixels. In YUV
4:2:0 mode, this value should be a multiple of 8-pixels.
In other modes (RGB, YUV 4:2:2 and YUV 4:4:4) it should
be a multiple of 4 pixels.
This patch reverts to PICTURE_X_SIZE/2 for channel 1.
Tested on Kernel 3.4, merged to 3.8rc.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
drivers/media/platform/soc_camera/mx2_camera.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 8bda2c9..795bd3f 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -778,11 +778,11 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
struct mx2_camera_dev *pcdev = ici-priv;
struct mx2_fmt_cfg *prp = pcdev-emma_prp;
- writel((pcdev-s_width 16) | pcdev-s_height,
- pcdev-base_emma + PRP_SRC_FRAME_SIZE);
writel(prp-cfg.src_pixel,
pcdev-base_emma + PRP_SRC_PIXEL_FORMAT_CNTL);
if (prp-cfg.channel == 1) {
+ writel(((bytesperline 1) 16) | pcdev-s_height,
+ pcdev-base_emma + PRP_SRC_FRAME_SIZE);
writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_CH1_OUT_IMAGE_SIZE);
writel(bytesperline,
@@ -790,6 +790,8 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
writel(prp-cfg.ch1_pixel,
pcdev-base_emma + PRP_CH1_PIXEL_FORMAT_CNTL);
} else { /* channel 2 */
+ writel((pcdev-s_width 16) | pcdev-s_height,
+ pcdev-base_emma + PRP_SRC_FRAME_SIZE);
writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_CH2_OUT_IMAGE_SIZE);
}
--
1.7.10.4
--
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: hacking MT9P031 for i.mx
On Tue, Oct 16, 2012 at 11:04:36PM +0200, Benoît Thébaudeau wrote: On Tuesday, October 16, 2012 10:04:57 PM, Laurent Pinchart wrote: Is there a current (kernel ~3.6) git tree which shows how to add mt9p031 to platform code? Yes, at http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- sensors-board Thanks! I'm also curious if it's possible to glue mt9p031 to a freescale i.mx35 platform. As far as I can see, drivers/media/platform/soc_camera/mx3_camera.c would need v4l2_subdev support? I have not followed this thread, so I don't know exactly your issue, but FYI I have an MT9M131 (of which the driver should hopefully be close to the MT9P031's) working on i.MX35 with Linux 3.4. I have here a mt9p031-testing-board with an i.MX35 interface. So I'm pretty interested in soc_camera support for mt9p031. Laurent is already fixing this but haven't finished due to lack of time. When there is anything to test, I would be glad to do so. Best regards -- Christoph -- 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: hacking MT9P031 for i.mx
Hi On Mon, 2012-07-02 at 14:48 +0200, Laurent Pinchart wrote: On Thursday 28 June 2012 21:41:16 Chris MacGregor wrote: Where did you get the Aptina board code patch from ? From here: https://github.com/Aptina/BeagleBoard-xM That's definitely outdated, the code is based on a very old OMAP3 ISP driver that was more or less broken by design. Nowadays anything other than the mainline version isn't supported by the community. Is there a current (kernel ~3.6) git tree which shows how to add mt9p031 to platform code? I'm also curious if it's possible to glue mt9p031 to a freescale i.mx35 platform. As far as I can see, drivers/media/platform/soc_camera/mx3_camera.c would need v4l2_subdev support? Thanks -- Christoph -- 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] V4L/DVB: v4l2-ctrls: add inclusion of slab.h
This patch adds inclusion of slab.h to get kzalloc, kfree and kmalloc to work. Signed-off-by: Christoph Fritz chf.fr...@googlemail.com --- drivers/media/video/v4l2-ctrls.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c index 84c1a53..ea8d32c 100644 --- a/drivers/media/video/v4l2-ctrls.c +++ b/drivers/media/video/v4l2-ctrls.c @@ -19,6 +19,7 @@ */ #include linux/ctype.h +#include linux/slab.h #include media/v4l2-ioctl.h #include media/v4l2-device.h #include media/v4l2-ctrls.h -- 1.7.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] pwc Kconfig dependency fix
makes USB_PWC_INPUT_EVDEV to depend also on USB_PWC Signed-off-by: Christoph Fritz chf.fr...@googlemail.com --- drivers/media/video/pwc/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/pwc/Kconfig b/drivers/media/video/pwc/Kconfig index 340f954..11980db 100644 --- a/drivers/media/video/pwc/Kconfig +++ b/drivers/media/video/pwc/Kconfig @@ -39,7 +39,7 @@ config USB_PWC_DEBUG config USB_PWC_INPUT_EVDEV bool USB Philips Cameras input events device support default y - depends on USB_PWC=INPUT || INPUT=y + depends on USB_PWC (USB_PWC=INPUT || INPUT=y) ---help--- This option makes USB Philips cameras register the snapshot button as an input device to report button events. -- 1.5.6.5 -- 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
