Re: [PATCH 28/34] media: mx2_camera: remove mach/hardware.h inclusion
On Thu, Sep 27, 2012 at 04:36:56AM -0300, Mauro Carvalho Chehab wrote: I'm understanding that this patch will flow through arm tree[1]. So: Yes, it will go through arm-soc tree for 3.8. Acked-by: Mauro Carvalho Chehab mche...@redhat.com Thanks, Mauro. Shawn -- 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 27/34] media: mx2_camera: remove cpu_is_xxx by using platform_device_id
On Thu, Sep 27, 2012 at 04:03:21PM -0300, Mauro Carvalho Chehab wrote: It seems that it depends on some stuff that got merged via the arm tree. Not sure what would the better way to handle that, as applying it via -arm will likely generate conflicts when merging from both trees upstream. If this change is not urgent, maybe it would be better to apply it after the end of the merge window, via either one of the trees. That's the original plan, having it merged via arm-soc tree at the end of 3.7 merge window. But I was told by arm-soc folks that we already have enough conflicts to sort out for this window, and we do not want any more. And we have to postpone it to 3.8. I will publish a topic branch for this series after 3.7-rc1 comes out. Shawn -- 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] mt9v022: support required register settings in snapshot mode
Hi Guennadi,
On Fri, 28 Sep 2012 15:30:33 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Fri, 28 Sep 2012, Anatolij Gustschin wrote:
Hi Guennadi,
On Fri, 28 Sep 2012 14:33:34 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
...
@@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct v4l2_subdev
*sd, int enable)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9v022 *mt9v022 = to_mt9v022(client);
- if (enable)
+ if (enable) {
/* Switch to master normal mode */
mt9v022-chip_control = ~0x10;
- else
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Unset snapshot mode specific settings: clear
bit 9
+* and bit 2 in reg. 0x20 when in normal mode.
+*/
+ if (reg_clear(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ } else {
/* Switch to snapshot mode */
mt9v022-chip_control |= 0x10;
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Required settings for snapshot mode: set bit
9
+* (RST enable) and bit 2 (CR enable) in reg.
0x20
+* See TechNote TN0960 or TN-09-225.
+*/
+ if (reg_set(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ }
Do I understand it right, that now on mt9v022 rev.3 and mt9v024 you
unconditionally added using REG32 for leaving the snapshot mode on
streamon and entering it on streamoff. This should be ok in principle,
since that's also what we're trying to do, using the CHIP_CONTROL
register. But in your comment you say, that on some _systems_ you can
only
_operate_ in snapshot mode. I.e. the snapshot mode enabled during running
streaming, right? Then how does this patch help you with that?
Yes. But i.e. the driver calling the sub-device stream control function
on streamon knows that the normal mode is not supported and therefore it
calls this function with argument enable == 0, effectively setting the
snapshot mode.
Right, I thought you could be doing that... Well, on the one hand I should
be happy, that the problem is solved without driver modifications, OTOH
this isn't pretty... In fact this shouldn't work at all. After a
stream-off the buffer queue should be stopped too.
Why shouldn't it work? The buffer queue is handled by the host driver,
not by the sensor driver. And in my case the host driver stops the buffer
queue in its streamoff, as it should. It works without issues and doesn't
cause any problems for other mt9v022 users.
Thanks,
Anatolij
--
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 1/3] mt9v022: add v4l2 controls for blanking
Hi Guennadi, On Fri, 28 Sep 2012 00:03:45 +0200 Anatolij Gustschin ag...@denx.de wrote: Add controls for horizontal and vertical blanking. Also add an error message for case that the control handler init failed. Since setting the blanking registers is done by controls now, we shouldn't change these registers outside of the control function. Use v4l2_ctrl_s_ctrl() to set them. Signed-off-by: Anatolij Gustschin ag...@denx.de --- Changes since first version: - drop analog and reg32 setting controls - use more descriptive error message for handler init error - revise commit log - rebase on staging/for_v3.7 branch drivers/media/i2c/soc_camera/mt9v022.c | 49 +-- 1 files changed, 45 insertions(+), 4 deletions(-) Can these mt9v022 patches be queued for mainlining, please? Thanks, Anatolij -- 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 4/14] drivers/media/v4l2-core/videobuf2-core.c: fix error return code
Em Thu, 6 Sep 2012 17:23:57 +0200
Peter Senna Tschudin peter.se...@gmail.com escreveu:
From: Peter Senna Tschudin peter.se...@gmail.com
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
(
if@p1 (\(ret 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// /smpl
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
---
drivers/media/v4l2-core/videobuf2-core.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 4da3df6..f6bc240 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1876,8 +1876,10 @@ static int __vb2_init_fileio(struct vb2_queue *q, int
read)
*/
for (i = 0; i q-num_buffers; i++) {
fileio-bufs[i].vaddr = vb2_plane_vaddr(q-bufs[i], 0);
- if (fileio-bufs[i].vaddr == NULL)
+ if (fileio-bufs[i].vaddr == NULL) {
+ ret = -EFAULT;
goto err_reqbufs;
+ }
Had you test this patch? I suspect it breaks the driver, as there are failures
under
streaming handling that are acceptable, as it may indicate that userspace was
not
able to handle all queued frames in time. On such cases, what the Kernel does
is to
just discard the frame. Userspace is able to detect it, by looking inside the
timestamp
added on each frame.
fileio-bufs[i].size = vb2_plane_size(q-bufs[i], 0);
}
--
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
Cheers,
Mauro
--
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: How to add support for the em2765 webcam Speedlink VAD Laplace to the kernel ?
Em Sun, 23 Sep 2012 16:03:25 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Ping !
Sorry, too busy those days.
Am 26.08.2012 20:53, schrieb Frank Schäfer:
Sorry for the delayed reply, I got distracted by something with higher
prority.
Am 22.08.2012 20:15, schrieb Mauro Carvalho Chehab:
Em 22-08-2012 04:53, Frank Schäfer escreveu:
Am 21.08.2012 19:29, schrieb Mauro Carvalho Chehab:
Hmm... before reading the rest of this email... I found some doc saying
that
em2765 is UVC compliant. Doesn't the uvcdriver work with this device?
Yeah, I stumbled over that, too. :D
But this device is definitely not UVC compliant. Take a look at the
lsusb output.
Maybe they are using a different firmware or something like that, but I
have no idea why the hell they should make a UVC compliant device
non-UVC-compliant...
Another notable difference to the devices we've seen so far is the
em25xx-style EEPROM. Maybe there is a connection.
Btw, do we know any em25xx devices ???
No, I never heard about em25xx. It seems that there are some new em275xx
chips, but I don't have any technical data.
Maybe they changed the name and there was never a em2580/em2585.
But I assume this is an older chip design.
In the mean time I was told that em2580/em2585 devices really exists.
They are used for example in intraoral cameras for dentists.
The em2765 seems to be a kind of relabled em25xx.
Ok.
Both chips have two i2c busses and work only with 16 bit address
eeproms, which have to be connected to bus A.
The sensor read/write procedure used for this webcam is very likely the
standard method for accessing i2c bus B of these chips.
It COULD also be vendor specific procedure, but I don't think 3 other
slave addresses would be probed in that case...
AFAIKT, newer em28xx chips are using this concept. The em28xx-i2c code require
changes to support two I2C buses, and to handle 16 bit eeproms. We never cared
of doing that because we never needed, so far, to read anything from those
devices' eeproms.
snip
You'll see several supported devices using the secondary bus for TV and
demod. As, currently, the TV eeprom is not read on those devices, nobody
cared enough to add a separate I2C bus code for it, as all access used
by the driver happen just on the second bus.
Well, the same applies to this webcam. We do not really need to read the
EEPROM at the moment.
A proper mapping for it to use ov2640 driver is to create two i2c
buses, one used by eeprom access, and another one for sensor.
Sure.
Interestingly, the standard I2C reads are used, too, for reading the
EEPROM. So maybe there is a physical difference.
Proprietary is probably not the best name, but I don't have e better
one at the moment (suggestions ?).
It is just another bus: instead of using req 3/4 for read/write, it
uses
req 6 for both reads/writes at the i2c-like sensor bus.
- uses 16bit eeprom
- em25xx-eeprom with different layout
There are other supported chips with 16bit eeproms. Currently,
support for 16bit eeproms is disabled just because this weren't
needed so far, but I'm sure this is a need there.
Yes, I've read the comment in em28xx_i2c_eeprom():
...there is the risk that we could corrupt the eeprom (since a 16-bit
read call is interpreted as a write call by 8-bit eeproms)...
How can we know if a device uses an 8bit or 16bit EEPROM ? Can we
derive
that from the uses em27xx/28xx-chip ?
I don't know any other way to check it than to read the chip ID, at
register
0x0a. Those are the chip ID's that we currently know:
enum em28xx_chip_id {
CHIP_ID_EM2800 = 7,
CHIP_ID_EM2710 = 17,
CHIP_ID_EM2820 = 18,/* Also used by some em2710 */
CHIP_ID_EM2840 = 20,
CHIP_ID_EM2750 = 33,
CHIP_ID_EM2860 = 34,
CHIP_ID_EM2870 = 35,
CHIP_ID_EM2883 = 36,
CHIP_ID_EM2874 = 65,
CHIP_ID_EM2884 = 68,
CHIP_ID_EM28174 = 113,
};
Even if we add it as a separate driver, it is likely wise to re-use the
registers description at drivers/media/usb/em28xx/em28xx-reg.h, moving
it
to drivers/include/media, as em2765 likely uses the same registers.
It also makes sense to add a chip detection at the existing driver,
for it to bail out if it detects an em2765 (and the reverse on the new
driver).
em2765 has chip-id 0x36 = 54.
Do you want me to send a patch ?
Yes, please send it when you'll be ready for driver submission.
Will do that.
Do you really think the em28xx driver should always bail out when it
detects the em2765 ?
Well, having 2 drivers for the same chipset is a very bad idea. Either
one should use it.
Another option would be to have a generic em28xx dispatcher driver
that would handle all of them, probe the board, and then starting
either one, depending if the driver is webcam or not.
Sounds good.
Btw, this is on my
Re: [PULL] soc-camera 3.7 set 2
Hi Guennadi, Em Tue, 11 Sep 2012 11:08:58 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi Mauro The following changes since commit 79e8c7bebb467bbc3f2514d75bba669a3f354324: Next time, please use [GIT PULL] for the subject; I seek for _git_ string for the patch name on my queue during the merge windows, in order to speedup patches from driver maintainers when I got overloaded. This is the case of this merge window: I still have ~270 patches (or pull requests) to handle, and this is already our record in terms of number of patches: ~720 patches already sent, and there are already 67 new patches for the second part. Thanks! Mauro -- 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: [PATCHv9 19/25] v4l: vb2: add buffer exporting via dmabuf
On Tue October 2 2012 16:27:30 Tomasz Stanislawski wrote:
This patch adds extension to videobuf2-core. It allow to export a mmap buffer
as a file descriptor.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/videobuf2-core.c | 82
++
include/media/videobuf2-core.h |4 ++
2 files changed, 86 insertions(+)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 05da3b4..a97815b 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
snip
@@ -2455,6 +2528,15 @@ int vb2_ioctl_streamoff(struct file *file, void *priv,
enum v4l2_buf_type i)
}
EXPORT_SYMBOL_GPL(vb2_ioctl_streamoff);
+int vb2_ioctl_expbuf(struct file *file, void *priv, struct v4l2_exportbuffer
*p)
+{
+ struct video_device *vdev = video_devdata(file);
+
+ /* No need to call vb2_queue_is_busy(), anyone can export buffers. */
After thinking about this some more I'm not so sure we should allow this.
Exporting a buffer also means that the memory can't be freed as long as the
exported filehandle remains open.
That means that it is possible to make a malicious application that exports
the buffers and never frees them, which can cause havoc. I think that only
the filehandle that called REQBUFS/CREATE_BUFS should be allowed to export
buffers.
What do you think?
Regards,
Hans
+ return vb2_expbuf(vdev-queue, p);
+}
+EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf);
+
/* v4l2_file_operations helpers */
int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma)
--
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
omap3isp: no pixel rate control in subdev
I'm trying to get an mt9t001 sensor board working on a Gumstix Overo board using the latest omap3isp-omap3isp-stable branch from the linuxtv.org/media.git repository. When I 'modprobe omap-isp' I see: Linux media interface: v0.10 Linux video capture interface: v2.00 omap3isp omap3isp: Revision 15.0 found omap-iommu omap-iommu.0: isp: version 1.1 mt9t001 3-005d: Probing MT9T001 at address 0x5d mt9t001 3-005d: MT9T001 detected at address 0x5d I then do: media-ctl -r media-ctl -l 'mt9t001 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -V 'mt9t001 3-005d:0 [SGRBG10 2048x1536]' media-ctl -V 'OMAP3 ISP CCDC:1 [SGRBG10 2048x1536]' Followed by: yavta -p -f SGRBG10 -s 2048x1536 -n 4 --capture=1 /dev/video2 file=m.bin For which I get: Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG10 (30314142) 2048x1536 (stride 4096) buffer size 6291456 Video format: SGRBG10 (30314142) 2048x1536 (stride 4096) buffer size 6291456 4 buffers requested. length: 6291456 offset: 0 Buffer 0 mapped at address 0x40272000. length: 6291456 offset: 6291456 Buffer 1 mapped at address 0x4096b000. length: 6291456 offset: 12582912 Buffer 2 mapped at address 0x4102f000. length: 6291456 offset: 18874368 Buffer 3 mapped at address 0x416ac000. Press enter to start capture After pressing enter I get: omap3isp omap3isp: no pixel rate control in subdev mt9t001 3-005d Unable to start streaming: Invalid argument (22). 1 buffers released. Thinking it might be the mt9t001 code, I also tried the mt9v032 code as I have one of those sensors too. I got exactly the same error message. Is there a patch I have missed or have I not configured something I should have done? -- 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] mt2063: properly handle return error codes
Fix a series of warnings when compiled with W=1:
drivers/media/tuners/mt2063.c: In function 'mt2063_setreg':
drivers/media/tuners/mt2063.c:290:2: warning: comparison of unsigned expression
0 is always false [-Wtype-limits]
...
drivers/media/tuners/mt2063.c:2013:2: warning: comparison of unsigned
expression 0 is always false [-Wtype-limits]
drivers/media/tuners/mt2063.c:2271:14: warning: no previous prototype for
'tuner_MT2063_SoftwareShutdown' [-Wmissing-prototypes]
drivers/media/tuners/mt2063.c:2286:14: warning: no previous prototype for
'tuner_MT2063_ClearPowerMaskBits' [-Wmissing-prototypes]
Several of those warnings are real bugs: the error status code
used to be unsigned, but they're assigned to negative error
codes.
Fix it by using unsigned int.
While here, comment the two power management functions, while we
don't add a code there to properly handle tuner suspend/resume.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/tuners/mt2063.c | 36 ++--
drivers/media/tuners/mt2063.h | 4
2 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/media/tuners/mt2063.c b/drivers/media/tuners/mt2063.c
index 620c4fa..2e1a02e 100644
--- a/drivers/media/tuners/mt2063.c
+++ b/drivers/media/tuners/mt2063.c
@@ -245,7 +245,7 @@ struct mt2063_state {
/*
* mt2063_write - Write data into the I2C bus
*/
-static u32 mt2063_write(struct mt2063_state *state, u8 reg, u8 *data, u32 len)
+static int mt2063_write(struct mt2063_state *state, u8 reg, u8 *data, u32 len)
{
struct dvb_frontend *fe = state-frontend;
int ret;
@@ -277,9 +277,9 @@ static u32 mt2063_write(struct mt2063_state *state, u8 reg,
u8 *data, u32 len)
/*
* mt2063_write - Write register data into the I2C bus, caching the value
*/
-static u32 mt2063_setreg(struct mt2063_state *state, u8 reg, u8 val)
+static int mt2063_setreg(struct mt2063_state *state, u8 reg, u8 val)
{
- u32 status;
+ int status;
dprintk(2, \n);
@@ -298,10 +298,10 @@ static u32 mt2063_setreg(struct mt2063_state *state, u8
reg, u8 val)
/*
* mt2063_read - Read data from the I2C bus
*/
-static u32 mt2063_read(struct mt2063_state *state,
+static int mt2063_read(struct mt2063_state *state,
u8 subAddress, u8 *pData, u32 cnt)
{
- u32 status = 0; /* Status to be returned*/
+ int status = 0; /* Status to be returned*/
struct dvb_frontend *fe = state-frontend;
u32 i = 0;
@@ -816,7 +816,7 @@ static u32 IsSpurInBand(struct MT2063_AvoidSpursData_t
*pAS_Info,
*/
static u32 MT2063_AvoidSpurs(struct MT2063_AvoidSpursData_t *pAS_Info)
{
- u32 status = 0;
+ int status = 0;
u32 fm, fp; /* restricted range on LO's*/
pAS_Info-bSpurAvoided = 0;
pAS_Info-nSpursFound = 0;
@@ -935,14 +935,14 @@ static u32 MT2063_AvoidSpurs(struct
MT2063_AvoidSpursData_t *pAS_Info)
*
* This function returns 0, if no lock, 1 if locked and a value 1 if error
*/
-static unsigned int mt2063_lockStatus(struct mt2063_state *state)
+static int mt2063_lockStatus(struct mt2063_state *state)
{
const u32 nMaxWait = 100; /* wait a maximum of 100 msec */
const u32 nPollRate = 2;/* poll status bits every 2 ms */
const u32 nMaxLoops = nMaxWait / nPollRate;
const u8 LO1LK = 0x80;
u8 LO2LK = 0x08;
- u32 status;
+ int status;
u32 nDelays = 0;
dprintk(2, \n);
@@ -1069,7 +1069,7 @@ static u32 mt2063_get_dnc_output_enable(struct
mt2063_state *state,
static u32 mt2063_set_dnc_output_enable(struct mt2063_state *state,
enum MT2063_DNC_Output_Enable nValue)
{
- u32 status = 0; /* Status to be returned*/
+ int status = 0; /* Status to be returned*/
u8 val = 0;
dprintk(2, \n);
@@ -1203,7 +1203,7 @@ static u32 mt2063_set_dnc_output_enable(struct
mt2063_state *state,
static u32 MT2063_SetReceiverMode(struct mt2063_state *state,
enum mt2063_delivery_sys Mode)
{
- u32 status = 0; /* Status to be returned*/
+ int status = 0; /* Status to be returned*/
u8 val;
u32 longval;
@@ -1345,7 +1345,7 @@ static u32 MT2063_SetReceiverMode(struct mt2063_state
*state,
static u32 MT2063_ClearPowerMaskBits(struct mt2063_state *state,
enum MT2063_Mask_Bits Bits)
{
- u32 status = 0;
+ int status = 0;
dprintk(2, \n);
Bits = (enum MT2063_Mask_Bits)(Bits MT2063_ALL_SD); /* Only valid
bits for this tuner */
@@ -1374,7 +1374,7 @@ static u32 MT2063_ClearPowerMaskBits(struct mt2063_state
*state,
*/
static u32 MT2063_SoftwareShutdown(struct mt2063_state *state, u8 Shutdown)
{
- u32 status;
+ int status;
dprintk(2, \n);
if (Shutdown == 1)
@@
Re: [PATCH v2 27/34] media: mx2_camera: remove cpu_is_xxx by using platform_device_id
Em Sat, 6 Oct 2012 16:26:40 +0800 Shawn Guo shawn@linaro.org escreveu: On Thu, Sep 27, 2012 at 04:03:21PM -0300, Mauro Carvalho Chehab wrote: It seems that it depends on some stuff that got merged via the arm tree. Not sure what would the better way to handle that, as applying it via -arm will likely generate conflicts when merging from both trees upstream. If this change is not urgent, maybe it would be better to apply it after the end of the merge window, via either one of the trees. That's the original plan, having it merged via arm-soc tree at the end of 3.7 merge window. But I was told by arm-soc folks that we already have enough conflicts to sort out for this window, and we do not want any more. And we have to postpone it to 3.8. I will publish a topic branch for this series after 3.7-rc1 comes out. Ok. Btw, as expected, the patch doesn't apply cleanly anymore, due to the file renames. Waiting for 3.7-rc1 seems to be the right thing to do here. -- Regards, Mauro -- 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: How to add support for the em2765 webcam Speedlink VAD Laplace to the kernel ?
Em Sat, 6 Oct 2012 08:56:24 -0300 Mauro Carvalho Chehab mche...@redhat.com escreveu: Unfortunately, lots of changes to the ov2640 driver would be necessary use it. It starts with the init sequence and continues with a long sequence of sensor register writes at capturing start. My hope was, that the differences can be neglected, but unfortunately this is not the case. Given the amount of work, the fact that most of these registers are undocumented and the high risk to break things for other users of the driver, I think we should stay with the custom code for this webcam at least for the moment. Well, then do a new ov2640 i2c driver. We can later try to merge both, if we can get enough spec data. Just to be clearer here: we should only fork ov2640 if we can't find a way to re-use the existing driver. Forked drivers are always a maintenance headache. Cheers, Mauro -- 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
Fw: [PATCH] v4 Add support to Avermedia Twinstar double tuner in af9035
Antti,
Please review.
Thanks!
Mauro
Forwarded message:
Date: Sun, 23 Sep 2012 21:48:47 +0200
From: Jose Alberto Reguero jaregu...@telefonica.net
To: linux-media@vger.kernel.org
Cc: Antti Palosaari cr...@iki.fi
Subject: [PATCH] v4 Add support to Avermedia Twinstar double tuner in af9035
This patch add support to the Avermedia Twinstar double tuner in the af9035
driver. Version 4 of the patch. I split the patch as suggested by Antti. I send
the changes to mxl5007 driver in another patch.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -upr linux/drivers/media/dvb-frontends/af9033.c
linux.new/drivers/media/dvb-frontends/af9033.c
--- linux/drivers/media/dvb-frontends/af9033.c 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/dvb-frontends/af9033.c 2012-09-13
22:22:29.012301231 +0200
@@ -326,6 +326,18 @@ static int af9033_init(struct dvb_fronte
goto err;
}
+ if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL) {
+ ret = af9033_wr_reg_mask(state, 0x00d91c, 0x01, 0x01);
+ if (ret 0)
+ goto err;
+ ret = af9033_wr_reg_mask(state, 0x00d917, 0x00, 0x01);
+ if (ret 0)
+ goto err;
+ ret = af9033_wr_reg_mask(state, 0x00d916, 0x00, 0x01);
+ if (ret 0)
+ goto err;
+ }
+
state-bandwidth_hz = 0; /* force to program all parameters */
return 0;
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2012-08-16 05:45:24.0
+0200
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2012-09-23
21:32:10.313657063 +0200
@@ -209,10 +209,14 @@ static int af9035_i2c_master_xfer(struct
if (msg[0].len 40 || msg[1].len 40) {
/* TODO: correct limits 40 */
ret = -EOPNOTSUPP;
- } else if (msg[0].addr == state-af9033_config[0].i2c_addr) {
+ } else if ((msg[0].addr == state-af9033_config[0].i2c_addr) ||
+ (msg[0].addr == state-af9033_config[1].i2c_addr)) {
/* integrated demod */
u32 reg = msg[0].buf[0] 16 | msg[0].buf[1] 8 |
msg[0].buf[2];
+ if (state-af9033_config[1].i2c_addr
+ (msg[0].addr == state-af9033_config[1].i2c_addr))
+ reg |= 0x10;
ret = af9035_rd_regs(d, reg, msg[1].buf[0],
msg[1].len);
} else {
@@ -220,8 +224,9 @@ static int af9035_i2c_master_xfer(struct
u8 buf[5 + msg[0].len];
struct usb_req req = { CMD_I2C_RD, 0, sizeof(buf),
buf, msg[1].len, msg[1].buf };
+ req.mbox |= ((msg[0].addr 0x80)3);
buf[0] = msg[1].len;
- buf[1] = msg[0].addr 1;
+ buf[1] = (u8)(msg[0].addr 1);
buf[2] = 0x00; /* reg addr len */
buf[3] = 0x00; /* reg addr MSB */
buf[4] = 0x00; /* reg addr LSB */
@@ -232,10 +237,14 @@ static int af9035_i2c_master_xfer(struct
if (msg[0].len 40) {
/* TODO: correct limits 40 */
ret = -EOPNOTSUPP;
- } else if (msg[0].addr == state-af9033_config[0].i2c_addr) {
+ } else if ((msg[0].addr == state-af9033_config[0].i2c_addr) ||
+ (msg[0].addr == state-af9033_config[1].i2c_addr)) {
/* integrated demod */
u32 reg = msg[0].buf[0] 16 | msg[0].buf[1] 8 |
msg[0].buf[2];
+ if (state-af9033_config[1].i2c_addr
+ (msg[0].addr == state-af9033_config[1].i2c_addr))
+ reg |= 0x10;
ret = af9035_wr_regs(d, reg, msg[0].buf[3],
msg[0].len - 3);
} else {
@@ -243,8 +252,9 @@ static int af9035_i2c_master_xfer(struct
u8 buf[5 + msg[0].len];
struct usb_req req = { CMD_I2C_WR, 0, sizeof(buf), buf,
0, NULL };
+ req.mbox |= ((msg[0].addr 0x80)3);
buf[0] = msg[0].len;
- buf[1] = msg[0].addr 1;
+ buf[1] = (u8)(msg[0].addr 1);
buf[2] = 0x00; /* reg addr len */
buf[3] = 0x00; /* reg addr MSB */
buf[4] = 0x00; /* reg addr LSB */
@@ -283,9 +293,30 @@
Re: [PATCH 1/5] media: ov7670: add support for ov7675.
Em Thu, 27 Sep 2012 08:58:33 +0200
javier Martin javier.mar...@vista-silicon.com escreveu:
Hi Jonathan,
thank you for your time.
On 26 September 2012 18:40, Jonathan Corbet cor...@lwn.net wrote:
This is going to have to be quick, sorry...
On Wed, 26 Sep 2012 11:47:53 +0200
Javier Martin javier.mar...@vista-silicon.com wrote:
+static struct ov7670_win_size ov7670_win_sizes[2][4] = {
+ /* ov7670 */
I must confess I don't like this; now we've got constants in an array that
was automatically sized before and ov7670_win_sizes[info-model]
everywhere. I'd suggest a separate array for each device and an
ov7670_get_wsizes(model) function.
+ /* CIF - WARNING: not tested for ov7675 */
+ {
...and this is part of why I don't like it. My experience with this
particular sensor says that, if it's not tested, it hasn't yet seen the
magic-number tweaking required to actually make it work. Please don't
claim to support formats that you don't know actually work, or I'll get
stuck with the bug reports :)
Your concern makes a lot of sense. In fact, that was one of my doubts
whether to 'support' not tested formats or not.
Let me fix that in a new version.
Hi Javier,
I'm assuming that you'll be sending a new version of this entire changeset.
So, I'll just mark this entire series as changes_requested.
Cheers,
Mauro
--
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
Media_build broken by [PATCH RFC v3 5/5] m5mols: Implement .get_frame_desc subdev callback
On my ubuntu 10.4 system
Linux 2.6.32-43-generic-pae #97-Ubuntu SMP Wed Sep 5 16:59:17 UTC 2012
i686 GNU/Linux
this patch breaks compilation of media_build.
The constant SZ_1M is not defined in the includes on my system
Do you know what can be done about this ?
---
/home/jhh/dvb/media_build/v4l/m5mols_core.c: In function
'm5mols_set_frame_desc':
/home/jhh/dvb/media_build/v4l/m5mols_core.c:636: error: 'SZ_1M'
undeclared (first use in this function)
/home/jhh/dvb/media_build/v4l/m5mols_core.c:636: error: (Each undeclared
identifier is reported only once
/home/jhh/dvb/media_build/v4l/m5mols_core.c:636: error: for each
function it appears in.)
Sylwester Nawrocki wrote:
.get_frame_desc can be used by host interface driver to query
properties of captured frames, e.g. required memory buffer size.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/i2c/m5mols/m5mols.h | 9 ++
drivers/media/i2c/m5mols/m5mols_capture.c | 3 ++
drivers/media/i2c/m5mols/m5mols_core.c| 47
+++
drivers/media/i2c/m5mols/m5mols_reg.h | 1 +
4 files changed, 60 insertions(+)
diff --git a/drivers/media/i2c/m5mols/m5mols.h
b/drivers/media/i2c/m5mols/m5mols.h
index 15d3a4f..de3b755 100644
--- a/drivers/media/i2c/m5mols/m5mols.h
+++ b/drivers/media/i2c/m5mols/m5mols.h
@@ -19,6 +19,13 @@
#include media/v4l2-subdev.h
#include m5mols_reg.h
+
+/* An amount of data transmitted in addition to the value
+ * determined by CAPP_JPEG_SIZE_MAX register.
+ */
+#define M5MOLS_JPEG_TAGS_SIZE0x2
+#define M5MOLS_MAIN_JPEG_SIZE_MAX(5 * SZ_1M)
+
extern int m5mols_debug;
enum m5mols_restype {
@@ -67,12 +74,14 @@ struct m5mols_exif {
/**
* struct m5mols_capture - Structure for the capture capability
* @exif: EXIF information
+ * @buf_size: internal JPEG frame buffer size, in bytes
* @main: size in bytes of the main image
* @thumb: size in bytes of the thumb image, if it was accompanied
* @total: total size in bytes of the produced image
*/
struct m5mols_capture {
struct m5mols_exif exif;
+ unsigned int buf_size;
u32 main;
u32 thumb;
u32 total;
diff --git a/drivers/media/i2c/m5mols/m5mols_capture.c
b/drivers/media/i2c/m5mols/m5mols_capture.c
index cb243bd..ab34cce 100644
--- a/drivers/media/i2c/m5mols/m5mols_capture.c
+++ b/drivers/media/i2c/m5mols/m5mols_capture.c
@@ -105,6 +105,7 @@ static int m5mols_capture_info(struct m5mols_info *info)
int m5mols_start_capture(struct m5mols_info *info)
{
+ unsigned int framesize = info-cap.buf_size - M5MOLS_JPEG_TAGS_SIZE;
struct v4l2_subdev *sd = info-sd;
int ret;
@@ -121,6 +122,8 @@ int m5mols_start_capture(struct m5mols_info *info)
if (!ret)
ret = m5mols_write(sd, CAPP_MAIN_IMAGE_SIZE, info-resolution);
if (!ret)
+ ret = m5mols_write(sd, CAPP_JPEG_SIZE_MAX, framesize);
+ if (!ret)
ret = m5mols_set_mode(info, REG_CAPTURE);
if (!ret)
/* Wait until a frame is captured to ISP internal memory */
diff --git a/drivers/media/i2c/m5mols/m5mols_core.c
b/drivers/media/i2c/m5mols/m5mols_core.c
index 933014f..c780689 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -599,6 +599,51 @@ static int m5mols_set_fmt(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh,
return ret;
}
+static int m5mols_get_frame_desc(struct v4l2_subdev *sd, unsigned int pad,
+ struct v4l2_mbus_frame_desc *fd)
+{
+ struct m5mols_info *info = to_m5mols(sd);
+
+ if (pad != 0 || fd == NULL)
+ return -EINVAL;
+
+ mutex_lock(info-lock);
+ /*
+ * .get_frame_desc is only used for compressed formats,
+ * thus we always return the capture frame parameters here.
+ */
+ fd-entry[0].length = info-cap.buf_size;
+ fd-entry[0].pixelcode = info-ffmt[M5MOLS_RESTYPE_CAPTURE].code;
+ mutex_unlock(info-lock);
+
+ fd-entry[0].flags = V4L2_MBUS_FRAME_DESC_FL_LEN_MAX;
+ fd-num_entries = 1;
+
+ return 0;
+}
+
+static int m5mols_set_frame_desc(struct v4l2_subdev *sd, unsigned int pad,
+ struct v4l2_mbus_frame_desc *fd)
+{
+ struct m5mols_info *info = to_m5mols(sd);
+ struct v4l2_mbus_framefmt *mf = info-ffmt[M5MOLS_RESTYPE_CAPTURE];
+
+ if (pad != 0 || fd == NULL)
+ return -EINVAL;
+
+ fd-entry[0].flags = V4L2_MBUS_FRAME_DESC_FL_LEN_MAX;
+ fd-num_entries = 1;
+ fd-entry[0].length = clamp_t(u32, fd-entry[0].length,
+ mf-width * mf-height,
+ M5MOLS_MAIN_JPEG_SIZE_MAX);
+ mutex_lock(info-lock);
+ info-cap.buf_size = fd-entry[0].length;
+ mutex_unlock(info-lock);
+
+
Re: [PATCH] usb id addition for Terratec Cinergy T Stick Dual rev. 2
Em Mon, 01 Oct 2012 14:21:34 +0300 Antti Palosaari cr...@iki.fi escreveu: On 10/01/2012 02:15 PM, Mauro Carvalho Chehab wrote: Em Sun, 30 Sep 2012 19:36:50 +0200 Damien Bally bir...@free.fr escreveu: Le 29/09/2012 19:33, Mauro Carvalho Chehab a écrit : It seems that the it931x variant has bcdDevice equal to 2.00, from Damien's email: idVendor 0x0ccd TerraTec Electronic GmbH idProduct 0x0099 bcdDevice2.00 iManufacturer 1 ITE Technologies, Inc. iProduct2 DVB-T TV Stick iSerial 0 If the af9015 variant uses another bcdDevice, the fix should be simple. Alas, according to http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_T_USB_Dual_RC the af9015 variant appears to have the same bcdDevice. I join both lsusb outputs for comparison. Well, then the alternative is to let both drivers to handle this USB ID, and add a code there on each of them that will check if the device is the right one, perhaps by looking at iProduct string. If the driver doesn't recognize it, it should return -ENODEV at .probe() time. The USB core will call the second driver. It is the easiest solution, but there should be very careful. Those strings could change from device to device. I used earlier af9015 eeprom hash (those string as coming from the eeprom) to map TerraTec dual remote controller and git bug report quite soon as it didn't worked. After I looked the reason I found out they was changed some not meaningful value. Yeah, those strings can change, especially when vendors don't care enough to use a different USB ID/bcdDevice for different models. Yet, seems to be the cleaner approach, among the alternatives. Regards, Mauro t. Antti -- Regards, Mauro -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Oct 6 19:00:26 CEST 2012 git hash:947c48086623d9ca2207dd0434bd58458af4ba86 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: ERRORS linux-3.5-x86_64: ERRORS linux-3.6-x86_64: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: ERRORS linux-3.5-i686: ERRORS linux-3.6-i686: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
Re: Media_build broken by [PATCH RFC v3 5/5] m5mols: Implement .get_frame_desc subdev callback
Hello Jan, On 10/06/2012 05:24 PM, Jan Hoogenraad wrote: On my ubuntu 10.4 system Linux 2.6.32-43-generic-pae #97-Ubuntu SMP Wed Sep 5 16:59:17 UTC 2012 i686 GNU/Linux this patch breaks compilation of media_build. The constant SZ_1M is not defined in the includes on my system Do you know what can be done about this ? --- /home/jhh/dvb/media_build/v4l/m5mols_core.c: In function 'm5mols_set_frame_desc': /home/jhh/dvb/media_build/v4l/m5mols_core.c:636: error: 'SZ_1M' undeclared (first use in this function) /home/jhh/dvb/media_build/v4l/m5mols_core.c:636: error: (Each undeclared identifier is reported only once /home/jhh/dvb/media_build/v4l/m5mols_core.c:636: error: for each function it appears in.) Thanks for reporting this issue. You most likely don't need the M-5MOLS camera sensor driver on you system so one option is to just disable it at kernel config. Make sure CONFIG_VIDEO_M5MOLS is not set, it can be unselected at menuconfig - Device Drivers - Multimedia - Encoders, decoders, sensors and other helper chips Fujitsu M-5MOLS 8MP sensor support The below patch which is intended to fix this issue won't work for media drivers backport builds on kernels older than 3.6, so m5mols driver should not be built for kernel versions 3.6. 8--- From 3e138ea603c9e5102452554cb14e4b404ce306e0 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki sylvester.nawro...@gmail.com Date: Sat, 6 Oct 2012 20:04:40 +0200 Subject: [PATCH] m5mols: Add missing #include linux/sizes.h Include linux/sizes.h header that is missing after commit ab7ef22419927 [media] m5mols: Implement .get_frame_desc subdev callback. It prevents possible build errors due to undefined SZ_1M. Reported-by: Jan Hoogenraad jan-conceptro...@hoogenraad.net Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com --- drivers/media/i2c/m5mols/m5mols.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/i2c/m5mols/m5mols.h b/drivers/media/i2c/m5mols/m5mols.h index 4ab8b37..90a6c52 100644 --- a/drivers/media/i2c/m5mols/m5mols.h +++ b/drivers/media/i2c/m5mols/m5mols.h @@ -16,6 +16,7 @@ #ifndef M5MOLS_H #define M5MOLS_H +#include linux/sizes.h #include media/v4l2-subdev.h #include m5mols_reg.h -- 1.7.4.1 8--- -- Regards, Sylwester -- 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: Media_build broken by [PATCH RFC v3 5/5] m5mols: Implement .get_frame_desc subdev callback
Thanks. I see several drivers disabled for lower kernel versions in my Kconfig file. I am not sure how this is accomplished, but it would be helpful if the Fujitsu M-5MOLS 8MP sensor support is automatically disabled for kernel 3.6 I fixed it in my version by replacing SZ_1M by (1024*1024). I did not need the driver, but at least it compiled ... Sylwester Nawrocki wrote: Hello Jan, On 10/06/2012 05:24 PM, Jan Hoogenraad wrote: On my ubuntu 10.4 system Linux 2.6.32-43-generic-pae #97-Ubuntu SMP Wed Sep 5 16:59:17 UTC 2012 i686 GNU/Linux this patch breaks compilation of media_build. The constant SZ_1M is not defined in the includes on my system Do you know what can be done about this ? --- /home/jhh/dvb/media_build/v4l/m5mols_core.c: In function 'm5mols_set_frame_desc': /home/jhh/dvb/media_build/v4l/m5mols_core.c:636: error: 'SZ_1M' undeclared (first use in this function) /home/jhh/dvb/media_build/v4l/m5mols_core.c:636: error: (Each undeclared identifier is reported only once /home/jhh/dvb/media_build/v4l/m5mols_core.c:636: error: for each function it appears in.) Thanks for reporting this issue. You most likely don't need the M-5MOLS camera sensor driver on you system so one option is to just disable it at kernel config. Make sure CONFIG_VIDEO_M5MOLS is not set, it can be unselected at menuconfig - Device Drivers - Multimedia - Encoders, decoders, sensors and other helper chips Fujitsu M-5MOLS 8MP sensor support The below patch which is intended to fix this issue won't work for media drivers backport builds on kernels older than 3.6, so m5mols driver should not be built for kernel versions 3.6. 8--- From 3e138ea603c9e5102452554cb14e4b404ce306e0 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki sylvester.nawro...@gmail.com Date: Sat, 6 Oct 2012 20:04:40 +0200 Subject: [PATCH] m5mols: Add missing #include linux/sizes.h Include linux/sizes.h header that is missing after commit ab7ef22419927 [media] m5mols: Implement .get_frame_desc subdev callback. It prevents possible build errors due to undefined SZ_1M. Reported-by: Jan Hoogenraad jan-conceptro...@hoogenraad.net Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com --- drivers/media/i2c/m5mols/m5mols.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/i2c/m5mols/m5mols.h b/drivers/media/i2c/m5mols/m5mols.h index 4ab8b37..90a6c52 100644 --- a/drivers/media/i2c/m5mols/m5mols.h +++ b/drivers/media/i2c/m5mols/m5mols.h @@ -16,6 +16,7 @@ #ifndef M5MOLS_H #define M5MOLS_H +#include linux/sizes.h #include media/v4l2-subdev.h #include m5mols_reg.h -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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: Media_build broken by [PATCH RFC v3 5/5] m5mols: Implement .get_frame_desc subdev callback
On 10/06/2012 08:43 PM, Jan Hoogenraad wrote: Thanks. I see several drivers disabled for lower kernel versions in my Kconfig file. I am not sure how this is accomplished, but it would be helpful if the Fujitsu M-5MOLS 8MP sensor support is automatically disabled for kernel 3.6 I fixed it in my version by replacing SZ_1M by (1024*1024). I did not need the driver, but at least it compiled ... A patch for v4l/versions.txt is needed [1]. I'll see if I can prepare that. http://git.linuxtv.org/media_build.git/history/5d00dba6aaf0f91a742d90fd1e12e0fb2d36253e:/v4l/versions.txt -- 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: Media_build broken by [PATCH RFC v3 5/5] m5mols: Implement .get_frame_desc subdev callback
This patch changes versions.txt and disables VIDEO_M5MOLS which fixed the build for my 3.2 kernel but looking at the logs it looks like this is not the way to fix it as it's not just a 3.6+ problem as it does not build on 3.6 as well... So probably best to find why it doesn't build on the current kernel first. --- v4l/versions.txt |2 ++ 1 file changed, 2 insertions(+) diff --git a/v4l/versions.txt b/v4l/versions.txt index 328651e..349695c 100644 --- a/v4l/versions.txt +++ b/v4l/versions.txt @@ -4,6 +4,8 @@ [3.6.0] # needs devm_clk_get, clk_enable, clk_disable VIDEO_CODA +# broken add reason here +VIDEO_M5MOLS [3.4.0] # needs devm_regulator_bulk_get -- 1.7.9.5 On 10/06/2012 08:43 PM, Jan Hoogenraad wrote: Thanks. I see several drivers disabled for lower kernel versions in my Kconfig file. I am not sure how this is accomplished, but it would be helpful if the Fujitsu M-5MOLS 8MP sensor support is automatically disabled for kernel 3.6 I fixed it in my version by replacing SZ_1M by (1024*1024). I did not need the driver, but at least it compiled ... A patch for v4l/versions.txt is needed [1]. I'll see if I can prepare that. http://git.linuxtv.org/media_build.git/history/5d00dba6aaf0f91a742d90fd1e12e0fb2d36253e:/v4l/versions.txt
Re: How to add support for the em2765 webcam Speedlink VAD Laplace to the kernel ?
On Sat, Oct 6, 2012 at 7:56 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: AFAIKT, newer em28xx chips are using this concept. The em28xx-i2c code require changes to support two I2C buses, and to handle 16 bit eeproms. We never cared of doing that because we never needed, so far, to read anything from those devices' eeproms. I actually wrote the code to read the 16-bit eeprom from the em2874, but removed it before submitting it upstream because I was afraid well-intentioned em28xx users trying to add support for their boards would trash their eeprom. This is because performing a read against a 16-bit eeprom is equivalent to a write on an 8-bit eeprom. Hence if the user didn't know what he/she was doing, and used the 16-bit eeprom code against an older eeprom, the eeprom would get trashed (this actually happened to me once when I was doing the em2874 device support originally). If we really want that code back in the tree, I can dig it up -- but I won't be responsible for users killing their devices. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
